This content has been marked as final. Show 3 replies
Update on this (in case anyone has a similar issue) - I've dug a little deeper and think the problem isn't with GC, but with a Java routine called "*oracle.adfmf.assetunpacker.copyasseststree*", which is called by "*copyFARS*". According to the Monitor method profiler, it does lots of work during the first run of an app, and none on subsequent executions. It seems to copy stuff around by using Java InputStream and OutputStreams in 250k chunks, and will take longer as you add assets to your app. I have a number of data controls in my app and I have a feeling that's what killing it, as it copies the supporting files on to the device. I could be wrong, but that's what it looks like.
Anyone know if there's a way around this, or if it's being addressed?
You are correct in your analysis that it is copying the assets. This is a one-time step that is necessary only on Android (not iOS). This time is reduced when installing a release build of your app but the first time run will always perform this step. After that no copying of application assets is necessary. We're working to review this and see if we can optimize this in a later version.
Thanks for the reply. May I suggest that improving this should be a priority?
If the phone sleeps during the install, the installation fails. (The default Android sleep time is fairly short).
Whilst the installation is on-going, users will most likely assume the phone has hung and try to interrupt it, as no other apps they download behave this way.
You're no doubt already aware of this but it appears to be the number of files to copied rather than the total size. The "+SkinningDemo+" has a FARs directory of about 6Mb, 82 files, but starts up in less than 10 seconds. My project has a FARs directory of only 1.16Mb but has 411 files (mostly Data Control files), and this copy step takes upwards of 3 minutes. This is on a Samsung Galaxy S3, which is hardly a slouch.