Add ViewBinding pool to BaseFragment

[Luna712]

This is heavily experimental, and has a chance to cause as well.

[Luna712]

@fire-light42 wondering your thoughts on this direction? It still needs more work though to clear the pool under more circumstances then just themes and also to clear it for individual fragments.

I was also thinking it needs better memory management to prevent OOMs using onTrimMemory and make the pool smarter about what we clear when we need to free up memory. At least thats what I was thinking but I'm not certain either if we need to go there.

[fire-light42]

@fire-light42 wondering your thoughts on this direction? It still needs more work though to clear the pool under more circumstances then just themes and also to clear it for individual fragments.

I was also thinking it needs better memory management to prevent OOMs using onTrimMemory and make the pool smarter about what we clear when we need to free up memory. At least thats what I was thinking but I'm not certain either if we need to go there.

Yes, clearing on onTrimMemory should be fine. However I have not looked into the heap or what the gc cant clear due to reusing old bindings. Some profiling will be needed for both the CPU saved, and the memory used.

Right now the implementation looks very good, and I had no crashes or similar. It was a lot faster, unfortunately the most expensive fragment ResultFragmentPhone was not cached due not being a BaseFragment. We might need to clear the cache if the android context changes, but I am not entirely sure how that would looks like. However when testing I found several bugs on ResultFragmentTv due to assuming that it was inflated with the default values.

[fire-light42]

It might be of interest to recursively descend the binding to clear all listeners and images, or provide a clearBinding function.

[Luna712]

Right now the implementation looks very good, and I had no crashes or similar. It was a lot faster, unfortunately the most expensive fragment ResultFragmentPhone was not cached due not being a BaseFragment. We might need to clear the cache if the android context changes, but I am not entirely sure how that would looks like. However when testing I found several bugs on ResultFragmentTv due to assuming that it was inflated with the default values.

Yeah I've noticed bugs in ResultFragmentTv as well as home page where it messes up when the binding view changes like navigating to account select activity and back or running the setup and a few other things.

It might be of interest to recursively descend the binding to clear all listeners and images, or provide a clearBinding function.

@fire-light42

I thought about that but I couldn't really figure out the best way to do this.

[Luna712]

@fire-light42 I have a fix I will push for that here soon, but I'm on the fence of whether that method is a good idea. If its not I'll revert, but the method is basically adding prefixed key support with a max pool size per prefix of 3, then uses that prefixed per name and apiname of ResultFragmentTv to separate the cache. But it's probably not the best, but I couldn't really figure out a better way that wouldn't make it harder to maintain some things in the future. But if you ever a better idea (and very much could) that would also be appreciated and it can be changed.