Closed SponsorAds closed 2 years ago
Hi This one is fairly clear: from
#00 pc 000000000083f0fc /data/app/~~4Dlag7M4AySAueHoa1zZ8Q==/-txv0E7dXLQzxQdmhn_lBXg==/split_config.arm64_v8a.apk!libCore.so (???)
we find
83f0fc: 94000442 bl 840204 <_ZN4MMgc2GC5SweepEv>
So basically it's doing the "sweep" part of garbage collection. This means it's going through and cleaning up objects that are no longer used, executing all destructors, and generally tidying up. It can definitely cause glitches/stutters because it runs synchronously (the "mark" part of the GC process runs in small segments a little at a time, but "sweep" happens in one go..)
To try to minimize these: a) try to ensure everything is kept reference counted. So e.g. avoid circular loops of objects that are referencing each other but are no longer used by the application (e.g. event listeners!). b) try to trigger the sweep in advance when there's a "quiet" bit of the app, via https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/System.html#pauseForGCIfCollectionImminent()
You may be able to use Scout to spot things that can be improved: even if you don't see any ANRs, you may see that there are peaks in the frame times caused by garbage collection: if you then add in the memory profiling then you can see what sort of objects are being destroyed during this frame and can hopefully then work out a way to minimise that. Object pooling etc can also work sometimes... it depends a lot on what your application is doing and how it's doing it!
thanks
I would love to debug this in more detail, but I am not aware of a well made memory profiler. The memory tool that came with Flash Builder was great. It showed every object allocation and deallocation, and even showed the objects class names. Very easy to spot any possible memory leaks or disposes not being triggered, right to the class causing it.
With Scout you get 70%-90% "onEnterFrame" allocations, you can't see allocations and deallocation together. You only see a percentage, not a number of allocations (which makes it extremely easy to compare on e.g. a page transition if something did no deallocate). Unless I missed something with Scout, that makes it quite impossible to pinpoint any objects that might cause leaks.
I think with Scout you can see the number of allocations and the memory they've used, but yes I've tended to select a bunch of allocations and copy them into Excel, and then a bunch of deallocations and copy them as well, and then try to work out the difference there to see what's causing the most problem.
Would be nice if there was better object tracking here: the capabilities that the Flash Builder profiler had should still be built into the runtime so I don't know whether that tool itself is separate .. will dig out a machine with it on and have a look!
Would be surely nice to have, it helped me a lot years ago in my early AIR times.
I managed to get our ANR rate down to about 1.6%, with tendency towards 0.9%. The biggest issue was a very simple animation that had a big xml garbage collection that also somehow leaked over time. Exactly this addition was done by a freelancer so it wasn't on my radar. I pooled it and issue is gone.
I'm currently experimenting with staggering content fetching on app start as every sqlite query causes String gc actions and we need to load quite some content on app start. I hope this will get ANR rates down to <0.4%.
Sadly this did not affect our 5% crash rate (nearly all Signal 11). But I'll open another issue for them.
One more for you, maybe you can get an idea what might be causing this ANR. This ANR is happening on multiple apps (similar codebase) thousands of times (we are at 6% ANR rate). Sadly I can't reproduce it myself at all.
We are not using any sound or video through AIR, but use distriqts ANE for that.
AIR 33.1.1.743