View Recycling
michaeleisel opened this issue · 3 comments
Because the consumer is interacting with elements, rather than the views backing them, view recycling could be done for the backing views with no changes in the public API. Each time an element needed a view, it could request it from a factory that doles out recycled views rather than creating its own.
The big questions are how to reclaim views and how to reset them for later use. The factory could maintain its own strong reference to all recyclable views, and then in the deinit method of an element, the element could notify the recycler that the view is now available to be reclaimed. The resetting part is less trivial but still doable.
Views are already reused between updates as long as it represents an element at the same location (path) in the hierarchy. That's also important for views like text fields – if they were discarded and rebuilt on every update, the keyboard / first responder behavior would be pretty broken.
Global recycling is a potential future enhancement, but honestly has not been an issue so far.
Are you asking for a specific enhancement, or were you just curious about how view recycling behavior works today?
This is asking for a specific enhancement, that of global recycling. Although I don’t know if it’s first thing to improve, many VC transitions drop frames, in my experience, due to the cost of view creation.
Closing this for now due to lack of activity. If we find performance to be an issue in a specific, reproducible way in the future we can re-open, but for now the added complexity of a global cache is a hard sell without a pressing need.