[iOS] Flush layer pool after platform view dispose

[cbracken]

FlutterPlatformViewLayerPool is a pool of iOS layers used for rendering platform views on iOS. When layers are no longer needed, we currently mark them available for re-use but we never actually flush them and thus recover the memory associated with these layers once we know that the layers are no longer needed.

We now flush the layer pool on SubmitFrame. If a previously-used layer is no longer used in the current frame, it is removed. In theory, this could cause a performance regression in the case where an additional layer is needed every second or third frame, but we should keep it simple on the first pass and only complicate things later if warranted.

Fixes: flutter/flutter#152053

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[cbracken]

Taking a look at how to sneak a test in here.

[jonahwilliams]

Changes look reasonable to me, modulo a test.

[jason-simmons]

LGTM

[cbracken]

Added a test.

[jonahwilliams]

LGTM

[jmagman]

Is there a way to check this is actually released? Or is that not a concern? I know the __weak/@autoreleasepool pattern won't work with non-Obj-C objects.

[cbracken]

The pool holds these in std::shared_ptr<FlutterPlatformViewLayer> so they'll be cleaned up via RAII. If we templatized FlutterPlatformViewLayerPool we could stick in some other class and manipulate a count in the ctor/dtor that we could then test against, but that probably wouldn't give us much more benefit, since it still wouldn't show that the real FlutterPlatformView layer properly releases its memory -- it uses C++ smart pointers for all but the GrDirectContext so I trust it, but it's still not tested.

An integration test that looks at overall memory is probably the way to do something like that.

[jonahwilliams]

This led to a nice memory drop on a varierty of benchmarks:

https://flutter-flutter-perf.skia.org/e/?keys=Xe332d40e74211cccfea289ea6902dbd3&selected=commit%3D41690%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Dworst_gpu_memory_mb%252Ctest%253Dplatform_views_scroll_perf_ios__timeline_summary%252C&xbaroffset=41690

[jonahwilliams]

With a slight increase in some worst fame times (probably from re-creating the overlays):

https://flutter-flutter-perf.skia.org/e/?begin=1721766214&end=1721852614&keys=X92aaab43f15c18b8d4075492ea7c070d&selected=commit%3D41690%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253D90th_percentile_frame_rasterizer_time_millis%252Ctest%253Dplatform_views_scroll_perf_ios__timeline_summary%252C&xbaroffset=41690

[cbracken]

That seems reasonable. We could potentially tweak the pool clearing code to do some kind of back-off, but I worry that going down that path might lead to optimising a bit too much for a particular scenario.