MozillaWiki

Firefox OS/Performance/App Performance Validation: Difference between revisions

Page Discussion

Firefox OS/Performance/App Performance Validation (view source)

Revision as of 13:59, 1 February 2015

703 bytes added ,  1 February 2015
m
Lakrits moved page FirefoxOS/Performance/App Performance Validation to Firefox OS/Performance/App Performance Validation: The official spelling of "Firefox OS" leaves a space between the two parts of the name. It's easier to find a page if the...
m (Lakrits moved page FirefoxOS/Performance/App Performance Validation to Firefox OS/Performance/App Performance Validation: The official spelling of "Firefox OS" leaves a space between the two parts of the name. It's easier to find a page if the...)
 
(5 intermediate revisions by 5 users not shown)
Line 1: Line 1:
'''Note: This page has now been edited published on MDN, as part of the App Center performance section — see https://developer.mozilla.org/en-US/Apps/Build/Performance/App_performance_validation. Any further changes should be made there. Talk to Chris Mills for more details.'''
This page outlines a simple process for manually auditing and improving the performance of an app.
This page outlines a simple process for manually auditing and improving the performance of an app.


Line 77: Line 79:
The duration, in millisecond, required to load the app.  This is usually pretty difficult to measure because the definition of "load the app" varies from app to app.  Generally though, we're talking about the time between the user launching the app and the '''visible''' UI being fully drawn and responsive.  I put an emphasis on the visible UI because many apps require lots of computation and/or I/O to initialize their state enough to draw the full UI for the initial app screen.  If every app waited until it was fully initialized before drawing the UI, they would all appear to be very slow and unresponsive.
The duration, in millisecond, required to load the app.  This is usually pretty difficult to measure because the definition of "load the app" varies from app to app.  Generally though, we're talking about the time between the user launching the app and the '''visible''' UI being fully drawn and responsive.  I put an emphasis on the visible UI because many apps require lots of computation and/or I/O to initialize their state enough to draw the full UI for the initial app screen.  If every app waited until it was fully initialized before drawing the UI, they would all appear to be very slow and unresponsive.


The trick to getting a fast load time is to as little as possible before putting up the '''visible''' part of the UI.  All long term calculations and I/O should be delayed into an idle timer callback if possible.  Apps that load to list UIs (e.g. contacts, sms, email) should only load enough data to display the UI that is initially visible to the user.  The rest of the list can then be loaded in an idle timer callback.
The trick to getting a fast load time is to do as little as possible before putting up the '''visible''' part of the UI.  All long term calculations and I/O should be delayed into an idle timer callback if possible.  Apps that load to list UIs (e.g. contacts, sms, email) should only load enough data to display the UI that is initially visible to the user.  The rest of the list can then be loaded in an idle timer callback.


The real key here is to make sure that the UI is drawn as early as possible.  Preferably, show a UI that isn't going to have a lot of box size re-adjustments due to reflows.  Having a bunch of box resizes during load makes the app feel like web page rather than a native app.  The goal here is to provide a native app experience using web technologies.
The real key here is to make sure that the UI is drawn as early as possible.  Preferably, show a UI that isn't going to have a lot of box size re-adjustments due to reflows.  Having a bunch of box resizes during load makes the app feel like web page rather than a native app.  The goal here is to provide a native app experience using web technologies.
Line 98: Line 100:
'''What does it mean''':  
'''What does it mean''':  


Having a good layer tree means we can most changes without having to repaint the page. Think of a cartoons on the television like The Simpsons: Most cartoons will divide their scene into a few layer and will move the layers themselves instead of redrawing the scene for every frame of the cartoon. Using layers to perform animations means we can avoid redrawing the page every frame and can simple move these layers around.
Having a good layer tree means we can perform most changes without having to repaint the page. Think of a cartoon on the television like The Simpsons: Most cartoons will divide their scene into a few layer and will move the layers themselves instead of redrawing the scene for every frame of the cartoon. Using layers to perform animations means we can avoid redrawing the page every frame and can simple move these layers around.




Line 124: Line 126:
'''Debugging''':
'''Debugging''':
* Attach with the App Manager and tweak the structure and styles of the page to trigger the desired behavior.
* Attach with the App Manager and tweak the structure and styles of the page to trigger the desired behavior.
and
* Get a display list dump. Build b2g with 'export B2G_DUMP_PAINTING=1' in your .userconfig (note: if you have a debug build, you don't need this). Set the preference 'user_pref("layout.display-list.dump", true);'.
* Look for the display list dump for the particularly process at the moment of interest. It will contains a list of display items and their mappings between layers and their original frames.


'''Creating/Destroying layers''':
'''Creating/Destroying layers''':
Lakrits
3,860

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/959486...1052483"