Partitioning Chrome's Code for Faster Launch Times on Android

Partitioning Chrome's Code for Faster Launch Times on Android
2021-11-17 02:00:00 Author: www.blogger.com(查看原文) 阅读量:16 收藏

tag:blogger.com,1999:blog-2471378914199150966.post-8813812264003041162021-11-16T09:00:00.047-08:002021-11-16T09:00:00.150-08:00Partitioning Chrome's Code for Faster Launch Times on Android<a href="https://1.bp.blogspot.com/-QI1QjcVLG6A/YZMUJSOVCcI/AAAAAAAABuI/MTRcWITRZMAX7wrq_cepzx7xN9FZPvm9QCLcBGAsYHQ/s640/image2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="266" data-original-width="640" height="278" src="https://1.bp.blogspot.com/-QI1QjcVLG6A/YZMUJSOVCcI/AAAAAAAABuI/MTRcWITRZMAX7wrq_cepzx7xN9FZPvm9QCLcBGAsYHQ/w668-h278/image2.png" width="668" /></a><br /><br /><i>Mobile devices are generally more resource constrained than laptops or desktops. Optimizing Chrome’s resource usage is critical to give mobile users a faster Chrome experience. As we’ve added features to Chrome on Android, the amount of Java code packaged in the app has continued to grow. In this <a href="https://blog.chromium.org/search/label/the%20fast%20and%20the%20curious">The Fast and the Curious</a> post we show how our team improved the speed and memory usage of Chrome on Android with Isolated Splits. With these improvements, Chrome on Android now <b>uses 5-7% less memory, and starts and loads pages even faster than before.</b></i><br /><br /><div><h1 style="text-align: left;">The Problem</h1>For Android apps (including Chrome on Android), compiled Java code is stored in <a href="https://source.android.com/devices/tech/dalvik/dex-format">.dex files</a>. The user's experience in Chrome on Android is particularly sensitive to increases in .dex size due to its <a href="https://developers.google.com/web/updates/2018/09/inside-browser-part1#browser-architecture">multi-process architecture</a>. On Android, Chrome will generally have 3+ processes running at all times: the browser process, the GPU process, and one or more renderer processes. The vast majority of Chrome’s Java code is used only in the browser process, but the performance and memory cost of loading the code is paid by all processes.</div><div>  <br /><h1 style="text-align: left;">Bundles and Feature Modules</h1>Ideally, we would load the smallest chunk of Java necessary for a process to run. We can get close to this by using <a href="https://developer.android.com/guide/app-bundle">Android App Bundles</a> and splitting code into <a href="https://developer.android.com/guide/playcore/feature-delivery">feature modules</a>. Feature modules allow splitting code, resources, and assets into distinct <a href="https://source.android.com/setup/start/glossary#apk">APKs</a> installed alongside the base APK, either on-demand or during app install.<br /><br />Now, it seems like we have exactly what we want: a feature module could be created for the browser process code, which could be loaded when needed. However, this is not how Android loads feature modules. By default, all installed feature modules are loaded on startup. For an app with a base module and three feature modules “a”, “b”, and “c”, this gives us an Android <a href="https://developer.android.com/reference/android/content/Context">Context</a> with a <a href="https://developer.android.com/reference/java/lang/ClassLoader">ClassLoader</a> that looks something like this:<br /><br /><br /><a href="https://1.bp.blogspot.com/-MY7g2r9Q-Fo/YZMUeakDMOI/AAAAAAAABuQ/ZDu0szR86es_l9vNW7MvPaB8gy2x4h3cwCLcBGAsYHQ/s1999/image1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="1329" data-original-width="1999" height="438" src="https://1.bp.blogspot.com/-MY7g2r9Q-Fo/YZMUeakDMOI/AAAAAAAABuQ/ZDu0szR86es_l9vNW7MvPaB8gy2x4h3cwCLcBGAsYHQ/w658-h438/image1.png" width="658" /></a><br /><br /><br />Having a small minimum set of installed modules that are all immediately loaded at startup is beneficial in some situations. For example, if an app has a large feature that is needed only for a subset of users, the app could avoid installing it entirely for users who don't need it. However, for more commonly used features, having to download a feature at runtime can introduce user friction -- for example, additional latency or challenges if mobile data is unavailable. Ideally we'd be able to have all of our standard modules installed ahead of time, but loaded only when they're actually needed.</div><div><br /><h1 style="text-align: left;">Isolated Splits to the Rescue</h1>A few days of spelunking in the Android source code led us to the <a href="https://developer.android.com/reference/android/R.attr#isolatedSplits">android:isolatedSplits</a> attribute. If this is set to “true”, each installed split APK will not be loaded during start-up, and instead must be loaded explicitly. This is exactly what we want to allow our processes to use less resources! The ClassLoader illustrated above now looks like this:<br /><br /><br /><a href="https://1.bp.blogspot.com/-3SoCvp5lokw/YZMUqEA7WpI/AAAAAAAABuU/5aGh9BhKU_IQJG1qpnyf_Z9WJihHUiRXwCLcBGAsYHQ/s1999/image3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="1329" data-original-width="1999" height="434" src="https://1.bp.blogspot.com/-3SoCvp5lokw/YZMUqEA7WpI/AAAAAAAABuU/5aGh9BhKU_IQJG1qpnyf_Z9WJihHUiRXwCLcBGAsYHQ/w652-h434/image3.png" width="652" /></a><br /><br /><br />In Chrome’s case, the small amount of code needed in the renderer and GPU processes can be kept in the base module, and the browser code and other expensive features can be split into feature modules to be loaded when needed. Using this method, we were able to reduce the .dex size loaded in child processes by 75% to ~2.5MB, making them start faster and use less memory.<br /><br />This architecture also enabled optimizations for the browser process. We were able to improve startup time by preloading the majority of the browser process code on a background thread while the Application initializes leading to a 7.6% faster load time. By the time an Activity or other component which needed the browser code was launched, it would already be loaded. By optimizing how features are allocated into feature modules, features can be loaded on-demand which saves the memory and loading cost until the feature is used.</div><div><br /><h1 style="text-align: left;">Results</h1>Since <a href="https://blog.chromium.org/2021/03/advanced-memory-management-and-more.html">Chrome shipped with isolated splits in M89</a> we now have several months of data from the field, and are pleased to share significant improvements in memory usage, startup time, page load speed, and stability for all Chrome on Android users running Android Oreo or later:<br /><ul style="text-align: left;"><li>Median total memory usage improved by 5.2%</li><li>Median renderer process memory usage improved by 7.9%</li><li>Median GPU process memory usage improved by 7.6%</li><li>Median browser process memory usage improved by 1.2%</li><li>95th percentile startup time improved by 7.6%</li><li>95th percentile page load speed improved by 2.3%</li><li>Large improvements in both browser crash rate and renderer hang rate</li></ul>Posted by Clark Duvall, Chrome Software Engineer<br /><br /><i>Data source for all statistics: <a href="https://www.google.com/chrome/privacy/whitepaper.html#usagestats">Real-world data</a> anonymously aggregated from Chrome clients.</i></div>Chromium Bloghttps://www.blogger.com/profile/06394244468194711527[email protected]

文章来源: http://www.blogger.com/feeds/2471378914199150966/posts/default/881381226400304116
如有侵权请联系:admin#unsafe.sh