WebAPPGeneralLifeCycle

This page tries to create a general model to describe life cycle of all APPs. With this model, we have a well defined and shared set of terminologies to describe performance characters of an APP, and to define a framework for APPs. With terminologies and framework, APPs can be monitored in a stable way, and be continuously improved.

Stages of Life Cycle

• Launch the App
  • The user touches the homescreen.
  • Request a child process to handle it.
• Document loading
  • This stage include parsing the first page and javascript, and running javascript for initialization.
    • Keep execution time of scripts here as short as possible.
    • Suggest to put only setTimeout() in |onload| to postpone initialization code until next stage.
    • Load JS files at next stage if possible.
  • The first picture will be showed at end of this stage.
    • Show only minimal static content.
    • No l10n content, or it is showed as empty if there is. (l10n would contribute to the latency of the first picture.)
    • No dynamic content, or is showed with a default state.
    • All content, or icons, are showed if only they don't change their sizes and positions later.
    • An CSS animation on the first picture during data loading may give a better UX; for example, fan-in.
• Data loading
  • After the completion of document loading.
  • This should be moved out of |onload| event to avoid its callback block rendering of first page. For example, |setTimeout()|.
  • Read data from storage, remote servers, .... etc.
• Prepare UI
  • Compute with data from the previous stage.
    • Transform, summarize, translate, ... etc.
  • Update the DOM tree to create a picture (frame) to the user.
• Visual loaded

Load data and Prepare UI could be intermixed.

Gecko Hack

Apps has various launch time depending on it's content and background tasks. System app would expect an app goes to ready between 600ms~700ms depending on devices. If system app put the launched app in front of homescreen to make it visible, but with opacity near 0; for example, 0.01, the content of the launched app would be rendered and send to compositor at chrome process. If the launched app has prepared an CSS animation and the system app make the app opaque where opacity == 1 on 700ms, the animation of the launched app would be played exactly at 700ms. One problem of this approach is the animation may start at 600ms, or 650ms. So, a part of at head may not visible for the user. The user will see the animation begin from the middle. The solution is Gecko use opacity <= 0 as an hint for a new/cold launched app. It don't play animation until the opacity is changed to some value X > 0.01. So that, for the user, he saw the animation of the launched app is played immediately after the animation of homescreen or system app.