Reduce APK Size by Optimizing Drawable Resources

[mcliquid]

Problem / Observation

The current APK size in v63.0 is 102.4 MB.
According to Android Studio's APK Analyzer, resources account for 47.4% of the total size, making them the largest contributor.

For example:

• There are currently 308 drawable-xxhdpi images
• These alone sum up to roughly 14 MB

Initial tests using tools like Squoosh show that many of the larger JPG files can be reduced by ~50% or more without noticeable quality loss.

Proposed Idea

Run a batch optimization pass over drawable resources using the Squoosh CLI locally I hope this would likely cut multiple megabytes from the APK size with minimal runtime impact.

But before investing time into setting up a reproducible optimization workflow:
Is resource optimization of drawable assets desired for StreetComplete?

Specifically:

• Is size reduction a current priority?
• Are there concerns regarding image quality, maintenance, or reproducibility?
• Would such changes be welcome in a PR?

If the general direction is approved, I would prepare a small proof-of-concept PR with the optimized images for evaluation. Same later for SCEE of course.

[westnordost]

Hm, well, not really. In my opinion, if we do these kinds of optimizations, we should also have a source graphic for each graphic we downscaled in quality also in the repository (in res/). If we had that, and we had a workflow that would automatically create the xxx, xx, x, h and m dpi versions of these at a quality we can control, that would be optimal, because then if it turns out there is noticeable quality loss, we can just adjust a parameter (in the build script). But we don't have these right now.

Believe it or not, but for all jpeg graphics I added to the repo, I painstakingly looked at the preview for each and every graphic while adjusting the JPEG quality slider so that I could not see a quality loss opposed to the source graphic. The slider was usually at around 70-90%, depending on the specific picture. I figure it would be difficult for an automatic process to use a different JPEG quality for each picture depending on the visual quality of the result instead of just blanket use a certain JPEG quality setting. So, from my point of view, they are already somewhat optimized.

[westnordost]

However, if you find pictures with ridiculous JPEG quality setting which were forgotten to have their quality reduced, you are welcome to post a PR to correct that. I notice among the largest JPEG files, suspiciously many are from the same few quests. So maybe those were contributed by someone else and he forgot that.

[westnordost]

(I was just writing a second comment when you closed it)

[westnordost]

So there is two things that could be done. Both could be done, of course:

1. check for the biggest JPEGs: Have they been actually adapted in quality from the original image? If not, there's certainly some kilobytes that can be squeezed out of each of those without visually reducing the quality. (This is a bit of manual labor.) If they already have been reduced, but they could be reduced more, it would be better to start (again) from the source image, because reducing the quality twice is not a good idea.

2. Put all the source images (cropped to the image section we want) into the repository in /res/. Then, implement some kind of process that automatically reduces in size and in quality the images and puts them into the correct directories in .../drawable-.../. This has the advantage that it is going to be easier in the future to contribute quests with such images - no more manual scaling into 4 different directories. The (slight) downside is that for the same visual quality, the end result would likely be a bit bigger than now, because the target JPEG quality would be set statically for all images. On the other hand, that automatic process could conver the source graphics to WEBP, which apparently is slightly better for compression

[mcliquid]

Thanks for the reply. From my perspective, both proposals go beyond the scope of the original issue (which was mainly about investigating resource size impact). I would therefore suggest handling them as separate issues if they should be pursued.

Regarding the two options:

1. While technically valid, this would require manually locating the original source images, re-cropping them exactly, re-exporting them with controlled quality settings, and comparing results for potentially hundreds of files. Given that we are talking about ~300+ images, the effort seems disproportionately high compared to the likely APK size reduction.
   For that reason, I do not consider this approach worthwhile in practice.

2. Although this would be architecturally cleaner long-term, it is effectively a build-system and asset-pipeline redesign. As you already mentioned, it has trade-offs (static quality settings, potential size regressions depending on encoding). Additionally, implementing such a reproducible image processing pipeline (including format conversion, scaling, and CI integration) is outside my current technical expertise and would require significant setup effort.

Given that neither approach seems lightweight nor directly aligned with the original ticket’s intent, I suggest:

• Closing the original issue as “investigated”
• Opening separate, clearly scoped issues if either optimization strategy should be pursued in the future

[westnordost]

By the way, option 1 would open up the possibility to improve the UI: Imagine one could tap on the thumbnails and get displayed a larger variant of it in a popup, much like in the note image attachment form. But probably not worth the effort. Also, it would actually blow up APK size, by a lot, to a point where we'd need to think about alternative solutions, such as providing these images as downloadable resources, which are downloaded automatically on first start of the application or something.

[westnordost]

I changed the JPEG quality of the biggest files in xxhdpi a bit. There were exported to 100% JPEG quality.