3 Replies Latest reply: Apr 18, 2013 5:29 AM by Richard Childe RSS

    ADF Mobile - GC During First Time App Startup

    Richard Childe
      Hello,

      I've been trying to find out why my app takes so long to start up on Android the first time after it's been re-deployed. I've been testing it by deploying it to androVM, and using the SDK Monitor "LogCat" tool to try and see what's going on. It appears as though during the first-time run of the app,the garbage collector is working very hard:
      04-16 17:04:48.693: D/dalvikvm(3207): GC_CONCURRENT freed 129K, 4% free 6859K/7111K, paused 11ms+0ms, total 15ms
      04-16 17:04:48.721: D/dalvikvm(3207): GC_CONCURRENT freed 110K, 4% free 7133K/7367K, paused 10ms+1ms, total 15ms
      ...
      <tons of these, until>
      ...
      04-16 17:05:15.425: D/dalvikvm(3207): GC_CONCURRENT freed 3133K, 30% free 11790K/16775K, paused 11ms+1ms, total 28ms
      ...so about 27 seconds.
      Kill the app (or switch the phone off), and the next startup looks like:
      04-16 17:00:37.833: D/dalvikvm(2768): GC_CONCURRENT freed 160K, 4% free 7723K/8007K, paused 12ms+0ms, total 34ms
      04-16 17:00:37.965: D/dalvikvm(2768): GC_CONCURRENT freed 141K, 4% free 8062K/8327K, paused 12ms+0ms, total 47ms
      <snip>
      ...
      04-16 17:00:39.477: D/dalvikvm(2768): GC_FOR_ALLOC freed 1217K, 26% free 12141K/16391K, paused 13ms, total 13ms
      ...so about 2 seconds. On the actual device, this 27 seconds seems to end up being nearly 2 minutes. The messages are mainly a mixture of GC_FOR_ALLOC and GC_CONCURRENT events.

      Does anyone have any ideas about why this memory allocation is happening, and if anything can be done? Is anyone else seeing the same issue?
      Any help is much appreciated.

      Thanks,
      Rich.
        • 1. Re: ADF Mobile - GC During First Time App Startup
          Richard Childe
          Hi,

          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?

          Thanks, Rich.
          • 2. Re: ADF Mobile - GC During First Time App Startup
            Denis T
            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.
            • 3. Re: ADF Mobile - GC During First Time App Startup
              Richard Childe
              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.

              Rich.