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

• App Launch
  • 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.
• UI preparing
  • 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

Data loading and UI preparing could be intermixed.

Gecko Hack

Apps has various launch time depending on it's content and background tasks. So, it is not easy to join transition of system app and splash of a just launched app well since we are not sure of the exact time of the splash being ready, and the non-deterministic of process scheduling makes the problem even harder. If we know the longest time required by a just launched app to set a splash, we could do some hack in Gecko to join the transition of system app and the splash animation of a just launched app seamless.

For example, a given platform is with 700ms of longest time required by apps, or suggested by the platform. Then, the apps should set a splash by 700ms. System would play a transition in 700ms, and expect the splash is played immediately once the transition is stopped. It is not easy to an app to start a splash exactly at 700ms. The solution is to set a splash by 700ms, and Gecko does not play it until it is at 700ms. Once the transition is stopped, Gecko would start playing the splash.

What to change:

• Determine how long is enough for cold launched app preparing its first page and animation. Let's say 700ms.
• Apps prepare a splash screen, or animation, as it's first picture/frame, before the end of the |onload| event handler.
• System App plays a transition of 700ms, and make new launched app foreground and visible when the transition is end.
• Gecko always paint the content of a new launched app, and send the layer tree from content process to chrome process even if the app is not visible.
• Compositor keeps the layer tree and info. attached on layers of a new launch app, but not show it and not play animations until it is foreground or visible.
• Animations of a new launched app are started at the time being foreground or visible.
• A new launched app is a content process never being foreground or visible since it was created.

Result: The transition of homescreen and app's splash would be connected together seamless.