I recall from our previous investigations that a significant amount of the file size increase came from libxul. Past offenders include ICU a multi-MB internationalization file and WebRTC. What can we do to prevent platform code from pinning us in a place where we are unable to develop Firefox for Android effectively? Skipping around the release versions and using a varying number of releases between the 'interesting' releases you chose makes analysis of the numbers difficult.
Just using the numbers provided as is Fx 14 to 21 = 0.86 MB/release Fx 21 to 26 = 0.4 Fx 26 to 33 = 1.29 Fx 33 to 36 = 0.66 Fx 36 to 39 = 1 I don't see a specific number trend other than up. Trying to predict the date of the 50MB threshold seems fraught with problems. Though it is a significant concern. Having a better historical breakdown might be useful as well as the growth of libxul and other gecko bits vs the androidy bits. Though that sounds like quite a bit of work to me. Kevin On Sun, Mar 29, 2015 at 11:08 AM, Richard Newman <[email protected]> wrote: > Firefox 14, June 2012: 17MB. > Firefox 21, May 2013: 23MB. > Firefox 26, December 2013: 25MB. > Firefox 33, November 2014: 34MB. > Firefox 36, February 2015: 36MB. > Firefox 39 Nightly, today: 39MB. > > > Our current Gingerbread split APK saves 3MB on this. In other words, the > gains of months of build and releng work was wiped out in *one month* of > routine development. > > I think we need to get a handle on this. > > We are 80% of the way towards the largest possible APK (50MB), and we're > already large enough that Fennec is too big to install on a Shitphone® that > I bought off Amazon last year. > > We're growing about 10MB per year, so by *March 2016* we will hit that > hard limit. > > omni.ja is about 9MB. libxul is now 16MB. NSS is about 800KB. classes.dex > is about 5MB. The rest is assets; about 6MB on disk, most of which is > images, layout and preferences XML, and color definitions. > > > Introducing more APK splits — which, looking at these numbers, seems an > inevitability — is likely to save us no more than 3MB on each screen > density. That implies that we need to aggressively pursue additional > solutions. > > > - More aggressive ProGuarding might save us up to a meg. I don't see a > bug on file for this. > - Bug 1115004 (fine-grained Google Play Services libs) might help, but > IIRC we already ProGuard these. > - Continuing to chop away at omni.ja might save us another meg. (See > Bug 1044079). > - We ought to look at build flags that turn off features in libxul and > libnss that we don't use on Android. (Bug 1115000, Bug 611781, maybe > others.) > - At some point I'll disable reftests on Gingerbread and remove 5MB of > fonts from constrained builds. That doesn't help 95% of our users, though; > I think we're unwilling to rely on system fonts on all platforms. > - Eventually we should move on Bug 945123 to download locales, saving > us about 60KB per locale (which I think is over 3MB now!). > > > I'd be very happy to hear more ideas about how we can start to make Fennec > smaller, rather than growing significantly larger in each release. > > I'll also take this opportunity to remind y'all to think carefully about > space usage — both in our APK and on disk — as you build out features. We > cannot afford unbounded growth. Consider removing features if they don't > see significant use. This is a battle that will be won or lost on > aggregate, not on individual heroics. > > Thanks. > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
