Closed Bug 1043657 Opened 10 years ago Closed 7 years ago

Publish Relaunch time for Core Apps

Categories

(Firefox OS Graveyard :: Performance, defect, P2)

Product:
Firefox OS Graveyard
Component:
Performance
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(tracking-b2g:-)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g -

People

(Reporter: rdandu, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=progress p= s= u=])

User Story

As an FxOS App developer, I want to see the relaunch time of my app, so that I can continue to reduce it to improve user engagement, and fix issues as they happen.

As a user of FxOS devices, I expect to be able to interact with an app 
which I've previously launched in < 500 msec, so that I feel my device is responsive to my requests.
Publish Relaunch time for Core Apps. This is the time in seconds it takes to subsequently launch of an app after the first time launch. The goal is this should be < 0.5 second for core apps. To be able to Drive this to goal, the results must be published. Core Apps are currently the list: Gallery, Camera, Maps, Contacts, Music, Browser, Email, SMS, Settings, Home screen.
User Story: (updated)
Keywords: perf
User Story: (updated)
Priority: -- → P2
Whiteboard: [c=progress p= s= u=]
according to raptor launched, raptor provides functionality for this bug. See bug 1088108.
tracking-b2g: --- → -
See Also: → 1088108
We need a little clarification on this one. Does this mean the same thing as a warm launch, i.e. are we re-opening the app after it has been backgrounded? Or does this mean subsequent cold launches after the initial first-time launch?
Blocks: 1198632
We discussed this pretty well in Whistler and determined that something like this isn't really possible right now. Applications do not receive an indication that they have been backgrounded, and generally don't do any processing in the background-to-foreground process. Any latency for re-displaying the app probably lies solely in the System and as such shouldn't be something to count against applications. Because of this, measuring individual applications for this has no meaning.
Thanks, Eli. I remember our conclusion and I see your point. I get this back is just because trying to manage old bug. However, I get request from TAM team. TAM learned something from Android device compatibility test suite (CTS), and want to build Mozilla CTS (MCTS). Any vendor want to get Android device shipping out. They should pass CTS in house. The warm launch time is part of criteria. I am still wondering how to make this happen. As performance perspective, it has no meaning. But as compatibility, it probably a test we can do.
It actually will start meaning something quite soon. One of the goals of NGA is to make it possible for the system/platform to free pieces of the app (like piece of backend, or some views) without shutting down the whole app. So a scenario I can imagine is that when you minimize the app for long enough, we'd kill all views but the most recent one and kill the background service. When you bring the app to the foreground, we launch the backend service and present the view (which has been in memory for the whole time). In that scenario warm-launch becomes meaningful.
@gandalf will there be any markers we can put in the System/app at these moments so we can capture the metrics?
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.