Change size monitoring to point at Monochrome Bundle rather than Monochrome apk |
|||||||||||
Issue descriptionWhat needs to be switched: * Android perf bots: * https://cs.chromium.org/chromium/build/scripts/slave/recipes/android/builder.py * android-binary-size trybot: * https://cs.chromium.org/chromium/src/tools/binary_size/trybot_commit_size_checker.py * diagnose_bloat.py: * https://cs.chromium.org/chromium/src/tools/binary_size/diagnose_bloat.py * Per-milestone supersize archives: * https://cs.chromium.org/chromium/src/tools/binary_size/libsupersize/generate_milestone_report.py * Official build supersize diffs: * https://cs.chromium.org/chromium/src/tools/binary_size/generate_official_build_report.py * ^^ Need to update the official_buildbot.sh that calls this script. Normalized APK size also needs to be update to remove local-related adjustments when dealing with bundle modules. * Either have the script detect that the apk is a module somehow, or * Add a --module flag to resource_sizes.py. * Also need to update metric description: * https://cs.chromium.org/chromium/src/docs/speed/binary_size/metrics.md While it would be nice to track size info for all modules, I think we should start with just looking at the base module. The steps to manually look at the base module: cd out/Release ninja monochrome_bundle bin/monochrome_bundle build-bundle-apks unzip apks/Monochrome.apks ../../build/android/resource_sizes.py apks/splits/base-master.apk Rather than updating recipes & scripts to run build-bundle-apks & extract the base apk, it would probably be easier to create a custom GN action() that did so.
,
Aug 13
I don't think this is required for initial launch. I'd guess all we'd want to do is build the .apks, then point supersize at them. Even so, we could probably get by with just continuing to measure monochrome.apk
,
Aug 13
Ok, reducing priority. IIUC, it is possible to have DFMs that will always be installed. Only tracking the Monochrome APK may not be sufficient. I think the plan is also to deprecate the monochrome APK (or point that target to the base module inside the bundle) once we have fully switched to bundles.
,
Aug 13
Yeah, there's certainly something to figure out here. It's likely that most of what we'll care about is the base module though (and maybe the size of a single locale?)
,
Aug 13
Yeah, agreed. For VR (and AR I believe) we have a custom bot that shows the size impact of those features. It would be cool if supersize would analyze the whole bundle and we had a size graph for each module automatically. cc bsheedy@ who worked on the custom VR/AR size bot.
,
Oct 24
Issue 877499 has been merged into this issue.
,
Oct 24
,
Oct 24
The bots use https://cs.chromium.org/chromium/src/build/android/diff_resource_sizes.py to measure binary size impact, which in turn uses resource_sizes.py. Is supersize more or less a drop-in replacement for resource_sizes.py?
,
Oct 25
Not exactly - supersize is a more complex/heavyweight tool and takes much longer to run. We've been looking at adding normalized apk size to supersize but have no immediate plans to get rid of resource_sizes.py. So we'd probably want to teach resource_sizes.py how to understand bundles as well.
,
Oct 26
Good point. Updated the bug title to reflect that.
,
Oct 30
,
Jan 3
,
Jan 14
,
Jan 14
,
Jan 14
,
Yesterday
(42 hours ago)
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by tiborg@chromium.org
, Aug 13