App Size Metrics - Continuous monitoring of App Size, Part 3
In Part 2, we finished our GHA workflow which generates apk size diff report and then adds it as a comment to the PR. In this post we’re going to implement the same workflow but using a plugin called Ruler and also look at some of it’s additional features.
Let’s rewind a bit to the Part 1, where we discussed about when we want to reduce the apk size we try to look at the size contribution by each high level categories (i.e. .dex files, resources, assets, JNI libs). An even more advanced stage in this “Apk Size Reduction” exercise is to understand the contribution by the 3rd party SDKs (which is not a trivial task by any means 😅). One of the way to calculate it can be to generate two apks with and without the SDK and then calculate the difference. But this is very time consuming and manual process.
This is where Spotify’s Ruler plugin comes in very handy as it provides insights into how much size is contributed by each module and dependencies present in your app 😲. You can check the sample report generated with the help of Ruler plugin in the below screenshot.
One problem that I faced while using Ruler plugin is that it’s not compatible with configuration-cache. But it should not be a blocker as you can always disable configuration-cache setting via passing “ — no-configuration-cache” flag while running the Ruler’s gradle tasks.
Integrating this plugin is very straightforward and doesn’t require much effort. Once this plugin is integrated it’ll expose analyze{BUILD_VARIANT}Bundle gradle tasks. For an app with no custom build variant it should expose two tasks i.e. analyzeDebugBundle & analyzeReleaseBundle. One important feature of this plugin apart from showing the size contribution, is showing ownership of different modules of your app. I highly suggest to give it a try as well.
Once you run this analyze gradle task then it should generate two files i.e. an HTML report and a json file. HTML report is a more human readable which you can use to visually inspect the size contribution. You can see the sample report for the same below:
The file that we’re more interested in is the json report. As we can process the contents of this json file to further generate the data in the format that we want. The json file content looks as shown in below screenshot:
So our goal here is to process the json file content and generate the same kind of report that we generated previously. The final result should look like below:
We’re going to create new workflow which is very similar to the one we created earlier.
This workflow is also divided into three jobs:
- Generate html+json reports for both base branch and a merge branch (i.e. head branch + base branch)
- Generate the size diff report (using custom python script)
- Add the size diff report as a PR comment (same as previous workflow)
Creating Python Script (to parse json report)
The main difference in this script compared to previous one is the contents of get_apk_components function. Here we no longer have to use apkanalyzer tool and just need to iterate through the json_data (parsed from reading the json report generated by using Ruler plugin) and update the content of components dictionary.
Ruler report workflow
This workflow is also very similar to the earlier one with some minor tweaks in build job (instead of executing assembleRelease task and uploading the apks we’re going to execute the analyzeReleaseBundle tasks and upload the html & json reports) & size_report job (using the updated python script which doesn’t require apkanalyzer tool). The final pr_comment job stays same in both workflows as the input file is still going to be ruler_diff_report.html file and we’re going to use it’s content to add a comment on the PR.
Conclusion
The result of both size_metrics.yml & ruler_report.yml workflows is same except the fact that the later one also exposes html report which allows us to do some granular/deeper level investigation into size contribution visually.
