ANR error while launching an adobe air app

[megajogos]

Testing our app on low end phones we found that it takes a long time for the app to actually load (before run our code). During this load time if the user is clicking on the screen the ANR happens.

Logs: airanr.txt

Tested with Adobe Air 33.1.1.743 and Air 33.1.1.795.

[ajwfrost]

Hi

Yes there seems to be a lot going on at start-up judging by all those threads ... but the main thread is currently processing the initial SWF file and still initialising everything.

This is a problem that we're hoping to eliminate in two ways:

1. support for AOT -> if we can compile the main SWF ahead of time then we will be able to accelerate a lot of the start-up/bootstrap code that's currently causing a bit of a delay during start-up

2. shifting the AS3 VM into a secondary thread -> we had tried this a while ago to try to reduce ANRs, but there are a significant number of changes that this needs.. I think it will be possible still, but this may mean that the application does officially respond to the events hence ANRs should decrease, although application reactivity won't change.

thanks

[megajogos]

Hi @ajwfrost,

Since we started working with Adobe Air we have had a lot of ANR issues. It's been a long time. It doesn't have to be the best option, just the fastest one that helps to reduce the ANRs.

Do you have a release date for this issue?

We are fully available to help you because we need this as soon as possible.

Thanks

[ajwfrost]

Hi

We've got a few other things we're also trying, specifically to help out with the start-up times:

• for any ANEs - or actually any SWCs that have been built with compc - they are likely to have each ActionScript class definition created in a different ABC block in the library SWF. This slows down the initial loading/parsing a considerable amount. We've just updated compc so that it merges all the blocks, like the mxmlc application compiler does, which should improve the start-up times a little.

• we're also currently adding a new capability to load extensions on demand, rather than them being loaded during application boot. This would mean that developers can choose to delay-load some extensions if they're not needed straight away (and it also opens up a possibility for new extensions to be added dynamically..)

• it seems that accessing files within the APK itself is something that's not very efficient, and has seemingly slowed down in recent Android versions (security?) - with more ANRs being found within an unzip-type extraction of the resources from within the APK. So we're starting to check if there's a newer/better way to access files from the APK. (I think previously, when you installed an application it would be extracted from the APK archive into the file storage; but now it appears to be kept as the archive and so the code by default is trying to extract it at runtime.. which would impact anything under File.applicationDirectory or app:/ urls)

Then in terms of those actions:

• we re-opened the investigation about moving things into a secondary thread. This is working for basic SWFs in CPU rendering mode currently, but we are having to see how we can make it work for direct/GPU rendering where we need to access the display context information (which Android doesn't allow from a background thread).

• the AOT work is also in progress but will probably come behind these other actions now..

There have been a few instances of real deadlocks that then caused valid ANRs, but those have tended to be audio-related and not at start-up. So all of the above are things that should improve the start-up time (other than the background thread, which just should mean that start-up delays don't then cause ANRs).

In terms of dates, the compiler change should be out soon, and the other updates would start to come in when we provide beta releases (there are a lot of changes involved in these!) starting within the next month or so for the extensions-on-demand and the apk-file-access, but still probably 2-3 months away for the secondary-thread and AOT work.

Hope that helps...

[megajogos]

Any updates on this?

[ajwfrost]

First one is done and coming into our next release in a few days; second one is done but coming in our major release (aiming to get a beta out at the end of the month). Third one we've started looking at and aiming for the same sort of timescale.

Then the big-ticket changes, are both in progress but likely to be a bit later still. We've been discussing further and I think the secondary thread approach is actually most likely to be of benefit, in that it will mean that regardless of start-up time, we shouldn't end up with ANRs (whereas the AOT approach should just speed things up - but if it was still too slow even after the speeding up, then the ANR risk remains).

thanks

[megajogos]

We appreciate your efforts. Thank you