NodeOffersServiceFacade memory management

[HenrikJannsen]

I just saw the efforts for improving memory footprint in NodeOffersServiceFacade.

I think a better approach would be to just keep the offers in the facade for the selected market. We hardly can hide offers without causing confusion to the user, thus the max reduction is to only keep the number of offers per market. This should release enough the memory pressure if keeping all offers was causing issues. This would also reduce a lot of added complexity and delays.

If that is not enough we can inspect the models to see if we hold data not used or data which is redundant.
Please note that the data is anyway stored in the network layer and as long we avoid copying data but using references it does not add much to memory footprint.

Btw:
TRIM_MEMORY_COMPLETE, TRIM_MEMORY_MODERATE, TRIM_MEMORY_RUNNING_CRITICAL, TRIM_MEMORY_RUNNING_MODERATE and TRIM_MEMORY_RUNNING_LOW in ComponentCallbacks2 are deprecated (Apps are not notified of this level since API level 34). The only remaining are TRIM_MEMORY_BACKGROUND and TRIM_MEMORY_UI_HIDDEN which are not very useful for memory adjustment.

[rodvar]

yes I put substantial effort to improve this because the initial implementation for this was very poor in terms of memory and threading management

Just a few clarifications for further analysis:

Only selected market’s offers are kept in memory

• we are already doing this
• On channel/market selection, we clear the in‑memory offer map and the UI list, then observe only the selected channel’s chat messages.
• Other markets are represented by MarketListItem entries with a live “num offers” observer; we do not load or hold full offers for them.
• Memory control already present for the selected market: We batch new offers, avoid duplicate work, and throttle under pressure. We keep a map by offerId only for the selected market, clear it on switches, and trim it aggressively during critical memory pressure.
• we could apply capping selected‑market in‑memory offers to a reasonable N (what would be the reasonable N?)

The batching and lightweight pressure checks are there to prevent UI churn and allocation spikes when a channel has many offers. With “selected market only,” most of that complexity already targets just the visible list.

There are useful comments though:

1. it would be good to inspect the models for unused/redundant data (this is planned before working on new features after releasE)
2. you are correct on some emory enum values deprecated in earlier versions of Android, this was left on purpose because we still suppot API 33 as our min sdk. For newer I think the enums TRIM_MEMORY_UI_HIDDEN (20) or BACKGROUND (40) are mising, or even the whole thing could be scrapped I can investigate this post release

[HenrikJannsen]

I see number of offers always 0 at restarts and then it takes a while until its loaded. This is not expected as the offers are persisted in the local network DB and only at first start it takes a while to get all offers from the network.

[rodvar]

can't repro with the latest pre-release build. Maybe in your branch you've done some optimizations that makes the bootstrap faster and that un-covers that issue? Let me know when to test your branch.

Please have in mind that making a huge PR makes it more cumbersome to review and also let's likely to be merged - preferred targetted changes in small PRs please 🙏

[HenrikJannsen]

Cannot reproduce it either anymore...

Yes, I know but thats why I usually break it up into smaller ones, but that kind of work require dependent PRs as its a large area I am working on which cannot be easily isolated in independent PRs. We use that pattern in Bisq 2 often and as long no other dev work in the same area merge issues are not an issue. But the merge policy with squash makes that impossible without getting into merge hell....

[rodvar]

You are the only contributor to bisq-mobile that does chained PRs.
The benefits of using squash & merge outweight that drawback in particular because we hace only one dev needing chained PRs that is not even full time on mobile.
So don't worry, I will manage your chained PRs accordingly to avoid the merge hell (basically by reviewing the initial nodes of the chain without merging or merging them with a different policy, and working the changes in the last node on the chain PR)