Firefox OS/Performance/Memory acceptance criteria

This page intends to define the criteria by which we say "memory management is good enough to ship", and test plans we can use to check those criteria.

Terminology

Foreground. For an application X, part of X's user interface is visible onscreen.

Perceivable. For an application X, no part of X's user interface is visible onscreen, but a user can perceive effects of X. For example, a music player that runs while its user interface is not visible is perceivable.

Background. For an application X, no part of X's user interface is visible onscreen, and it is not perceivable.

System message. A notification generated by Gecko which is dispatched to a certified application X that has registered to listen to the message. If application X is not running when a system message is sent to it, X is launched. For example, an incoming telephone generates a system message that the Dialer application listens for.

Activity. A request generated by a user as part of an interaction with an application X. Activities target an application Y. If Y is not running when an activity targets it, Y is launched. Y may send back data to X as part of the activity. For example, choosing an avatar for a contact generates an activity which may be targeted at the Camera, Gallery, or many other applications.

Criteria

These criteria are only defined for "core Gaia applications" (TODO: enumerate these). Firefox OS developers have no direct control over third-party applications.

MANDATORY: Users' explicit launch of every application X (tap X's icon on homescreen) results in X being loaded and its user interface brought to the foreground.

MANDATORY: Every application X launched by a system message results in X being loaded and provides X the opportunity to display a user interface.

MANDATORY: For every activity initiated by a user in application X that

1. Launches application Y
2. Is "one-way", that is, application Y does not return data to X

application Y must be loaded and its user interface brought to the foreground.

MANDATORY: For every "activity" initiated by a user in application X that

1. Launches application Y
2. Is "two-way", that is, application Y must return data to X

application Y must be loaded and its user interface brought to the foreground. Application X must remain loaded while Y is in the foreground. When application Y returns data to X, X's user interface must be brought to the foreground.

MANDATORY: A foreground application is never killed due to memory pressure while a perceivable or background application is alive.

MANDATORY: A perceivable application is never killed due to memory pressure while a background application is alive.

QoS: We will strive to maximize the number of perceivable and background applications that stay alive over the workloads defined below, while meeting the mandatory criteria above. We should reject builds which regress the number of apps that stay alive under our workloads.

(TODO: define if or to what extent third-party code can affect these criteria

Constraints on user data

This section defines the extremes of user data that are considered within the scope of the conformance requirements in this document.

(TODO)

Gallery

• 1000 images? at what max size?
• max image size?

Workloads

This section defines the workloads by which the criteria above are evaluated. Along with each workload, the acceptance status is listed for the given commit IDs below.

Gecko Gaia

(TODO)

In-flight improvements

See bug 797189 for the latest list.