[Android] Is it recommended to use runtimeInBackgroundThread ? Any additional details?

[2jfw]

There are only a few information available for runtimeInBackgroundThread but some people seem to rely on it.

• Is it actually a recommended setting and what exactly does it do / why is it "preventing ANR issues"?
• Will the app have any other benefits, like performance improvements?
• Should I use as it as default setting for my Android app in the case it does not interfere with ANE's?

Quote from docs:

runtimeInBackgroundThread
If true, this causes the AIR runtime to be launched in a separate, background thread rather than in the main Android UI thread. This should help prevent ANR (Application Not Responding) issues, but may require some updates in other Android Java code (i.e. from AIR Native Extensions that may need some of their code to run on the UI thread). Default is false.

https://airsdk.dev/docs/building/application-descriptor-files/elements/android#runtimeinbackgroundthread

[ajwfrost]

Yes, I have mixed feelings about this feature ... the intention was to disassociate the Android UI thread from the AIR rendering thread, so that the UI could remain "responsive" to the Android event loop, which would then mean we don't get any ANRs if AIR takes a long time to respond to anything.

So that was the theory: just make that change and we shouldn't get any ANRs because from the OS perspective, events would be handled immediately (and internally, posted onto a queue for the runtime to then pick up).

In practice, where it falls down is where there are interactions with UI elements that need to be on the 'main' UI thread from the Android OS perspective. Which is mostly around StageText and StageWebView interactions, but also we're finding a number of points where e.g. an event comes in from the OS in the 'main' thread and is then being passed into the runtime - but then being handled in the main thread rather than the runtime thread, it can lead to deadlocks or pauses which then are a cause of ANRs themselves! So, it's not been as straightforward as we'd hoped.

A problem that this causes is where a UI interaction needs a synchronous reaction from the AIR runtime. Such as for a normal AS3 TextField: if you long-click on the stage somewhere, Android doesn't know about the text field, so it's up to us to check and determine whether you did that in a position covered by a text field - and hence triggering the Android context menu for text - or whether you did it in a normal area resulting perhaps in an AS3 context menu. And other such things, where we can't actually get the immediate results that Android may want in terms of the event handling, which means some functionality doesn't work. A recent example, which I think we have a workaround for, is drawing StageText contents to a bitmap: the call originates in the runtime thread but we can't actually draw the StageText object (a native Android UI element) in that thread, so we cannot provide the bitmap straight away... (the workaround is to block the runtime thread until the UI thread has finished, it seems to be okay this way round, but blocking the UI thread until the Android thread has finished something is what often leads to deadlock...)

Anyway: one of the larger changes that we are planning to apply on Android soon is to switch the whole thing over to using the more mainstream classes for OpenGL views, rather than the current mechanism that uses EGL with a SurfaceView holder. And with that mechanism, you provide a separate rendering object which runs in its own thread - so then we would have the AIR runtime in a "RenderThread" and the main Android UI still in its own thread. It's TBC whether a slow render thread would then trigger an ANR...

Hope that helps a little. A lot of people get by without this feature and without having ANRs, but if you do suffer from a high ANR rate then it may help; if you also use StageText and StageWebView then there's a "use with caution, and a lot of testing" caveat..

And going back to your actual questions:

• Is it actually a recommended setting and what exactly does it do / why is it "preventing ANR issues"?
  ** Not really "recommended" but it's an option. See above..

• Will the app have any other benefits, like performance improvements?
  ** No, it just moves things into a different thread, but there's then no difference internally in the performance or threading models.

• Should I use as it as default setting for my Android app in the case it does not interfere with ANE's?
  ** I would say, only if you are finding a lot of ANRs, and then be prepared to find other ANRs (which we are hopefully slowly eliminating)

thanks

[2jfw]

Many thanks for the insight and details on this, this definitely lightens up runtimeInBackgroundThread !