Performance/Fenix: Difference between revisions

Jump to navigation Jump to search
→‎App start up: Convert section to list automated regression busting
(→‎Offense vs. defense: Delete section)
(→‎App start up: Convert section to list automated regression busting)
Line 36: Line 36:
## '''If you're doing this on a built-in API, you'll need to ban use of the old API e.g. with ktlint rule since it's harder to suppress'''
## '''If you're doing this on a built-in API, you'll need to ban use of the old API e.g. with ktlint rule since it's harder to suppress'''


== App start up ==
== Preventing regressions automatically ==
=== Defense ===
We use the following measures:
The FE perf team has the following measures in place to prevent regressions:
* Crash on main thread IO in debug builds using <code>StrictMode</code> ([https://github.com/mozilla-mobile/fenix/blob/13f33049122e0f06c026632812dee405360c53b0/app/src/main/java/org/mozilla/fenix/StrictModeManager.kt#L63-L69 code])
* Show long term start up trends with Nightly performance tests (note: these are not granular enough to practically identify & fix regressions)
* Use [https://searchfox.org/mozilla-mobile/rev/3af703be7790ff00f78d15465f3b8bb0fde0dccc/fenix/app/src/androidTest/java/org/mozilla/fenix/perf/StartupExcessiveResourceUseTest.kt#103 our StartupExcessiveResourceUseTest], for which we are Code Owners, to:
* Prevent main thread IO by:
** Avoid StrictMode suppressions
** Crashing on main thread IO in debug builds using <code>StrictMode</code> ([https://github.com/mozilla-mobile/fenix/blob/13f33049122e0f06c026632812dee405360c53b0/app/src/main/java/org/mozilla/fenix/StrictModeManager.kt#L63-L69 code])
** Avoid <code>runBlocking</code> calls
** Preventing <code>StrictMode</code> suppressions by running tests that assert for the current known suppression count. We are Code Owners for the tests so we will have a discussion if the count changes ([https://github.com/mozilla-mobile/fenix/blob/13f33049122e0f06c026632812dee405360c53b0/app/src/androidTest/java/org/mozilla/fenix/ui/StrictModeStartupSuppressionCountTest.kt#L48-L57 code])
** Avoid additional component initialization
* Code added to the start up path should be reviewed by the performance team:
** Avoid increasing the view hierarchy depth
** We are Code Owners for a few files
** Avoid having ConstraintLayout as a RecyclerView child
 
** Avoid increasing the number of inflations
==== WIP ====
* Use lint to avoid multiple ConstraintLayouts in the same file ([https://searchfox.org/mozilla-mobile/rev/3af703be7790ff00f78d15465f3b8bb0fde0dccc/fenix/mozilla-lint-rules/src/main/java/org/mozilla/fenix/lintrules/perf/ConstraintLayoutPerfDetector.kt code])
We're working on adding:
* Regression testing per master merge ([https://github.com/mozilla-mobile/perf-frontend-issues/issues/162 issue])
* Prevent main thread IO with:
** Static analysis to prevent <code>runBlocking</code>, which can circumvent <code>StrictMode</code> ([https://github.com/mozilla-mobile/fenix/issues/15278 issue])
* Code added to the start-up path should be reviewed by the performance team:
** We're investigating other files that can be separated so we can be code owners for the start up parts ([https://github.com/mozilla-mobile/fenix/issues/15274 issue])
* Minimize component initialization with:
** Avoid unnecessary initialization ([https://github.com/mozilla-mobile/fenix/issues/15279 issue])
* Prevent unnecessarily expensive UI with:
** NestedConstraintLayout static analysis ([https://github.com/mozilla-mobile/fenix/issues/15280 issue])
 
=== Offense ===
TODO: improve this section, if useful (let us know if it is)
 
We're keeping a list of the biggest known performance improvements we can make. Also, we have a startup improvement plan.


=={{#if:Glossary|<span id="Glossary"></span>|<span class="error">Error in {{tl|anchor}}: no anchor name has been specified.</span>}}<!--
=={{#if:Glossary|<span id="Glossary"></span>|<span class="error">Error in {{tl|anchor}}: no anchor name has been specified.</span>}}<!--
Confirmed users
975

edits

Navigation menu