Package Size Optimization: Large Resource Detection, Unused Assets Scanning, and Resource Size Gatekeeping for Mobile Apps

Introduction In the previous article "Soul Package Optimization – so Part" we discussed SO size governance. This continuation focuses on package size management from the perspective of resources, covering reduction of existing large assets and control of new additions.

Large Resource Optimization

When multiple teams collaborate on a componentized project, the challenge is quickly identifying large resources, locating the owning library and maintainer, and then coordinating optimization. To address this, we built a tool that automatically finds all qualifying large resources and their metadata for periodic batch optimization.

Large Resource Detection Tool

The tool aims to locate files in business libraries that exceed expected size thresholds, including images, videos, audio, and other assets, enabling each team to reduce their own resource footprints.

Traverse all files under the specified directory.

Check if the file type is in the target list (.png, .jpg, .jpeg, .webp, .gif, .JPG, .mp4, .mp3, .wav, .zip).

Determine whether the file qualifies as a large resource.

If it does, collect basic file information and Git metadata.

Store the results in a cache and sort by file size.

Export the cached results to a CSV file for easy extraction of key information.

Result Output The final CSV provides a clear view of resources that need attention, facilitating targeted optimization by the responsible teams.

Assets Unused Resource Scanning

While many reliable solutions exist for detecting unused resources under the res directory, detecting unused assets proved difficult. We therefore created a tool tailored to the usage patterns of assets.

Decompile the APK to obtain all code and resources.

Collect all asset file and folder names.

Search the decompiled code and resources for references to those asset names; absence indicates the asset is unused.

Traverse all AAR packages to locate which AAR contains the unused assets.

Result Output The resulting report allows module owners to delete the identified assets after confirmation, preventing accidental functional regressions.

New Resource Size Gate

During Soul App releases, each version requires manual inspection of package growth, consuming about half a day to analyze sources of increase and produce a report. Non‑compliant resources increase integration cost and delay development.

Specification

Tool Implementation

The solution consists of two steps: automatic hooksPath configuration and resource validation at commit time.

hooksPath Auto‑Setup

1. During local development, the build task runs. 2. The tool checks whether the local switch is enabled. 3. If enabled, it verifies whether a previous hooksPath exists; if the existing pre‑commit matches, no action is taken; otherwise the old file is removed and a fresh pre‑commit script is copied to the designated directory. If no prior configuration exists, the script is copied and hooksPath is set. 4. If the switch is disabled, any existing pre‑commit and hooksPath configuration are cleaned up.

Process Diagram

Commit Resource Validation

Technical Overview

1. Development reaches a commit point. 2. Because hooksPath is set, a pre‑commit script is automatically triggered. 3. The script runs git diff-index --cached HEAD to collect the set of resources being committed. 4. Each file’s size is checked against the defined limits. 5. If oversized resources are found, their paths and actual sizes are printed, warning the developer, and the commit proceeds. 6. If no violations are detected, the commit proceeds normally.

Process Diagram

Execution Result

Code Integration

Technical Overview

1. Jenkins triggers module build. 2. The current module’s Git branch information is retrieved. 3. git diff "current_branch" master --stat is executed. 4. The set of changed resources is obtained. 5. The changed resources are compiled and checked for size violations. 6. If violations exist, the build is aborted and integration fails, preventing the code from merging into master. 7. If no violations, the build continues and integration succeeds. 8. The integration result is reported to the user.

Process Diagram

Execution Result

Process Control

During long‑term iteration we found that third‑party SDKs are a major cause of sudden package size spikes. Because many development teams independently add SDKs based on business needs, uncontrolled integration leads to unmanageable package growth. We therefore established a dedicated SDK integration workflow that emphasizes size awareness rather than outright restriction.

Conclusion

Systematic resource governance not only reduces package size but also yields reusable tooling that keeps the app size under control over the long term. Soul App will continue to evolve its size‑management practices and share further insights in upcoming series.