Problem
APKEditor/ARSCLib appears to process many large APK workloads mostly sequentially.
On modern multi-core systems, heavy operations such as resource decoding/encoding, DEX handling, smali disassembly/assembly, and large file scanning/writing do not seem to utilize available CPU cores effectively. This can make processing large applications significantly slower than necessary.
Affected operations
This is noticeable during operations such as:
- merge
- decompile
- compile / rebuild
- resource decode / encode
- DEX and smali processing
- large directory scans
- archive entry extraction / writing
Example workload
Environment:
- APKEditor: 1.4.9
- Input: large APKM with many split APKs, resources, and
classes*.dex files
- JVM example:
java -Xmx8g -jar APKEditor.jar d -i app.apk -o out
java -Xmx8g -jar APKEditor.jar b -i out -o rebuilt.apk
During these operations, CPU usage remains mostly limited instead of scaling across available CPU cores.
Expected behavior
Independent workloads should be processed in parallel where possible, for example:
- multiple resource files
- multiple DEX files
- multiple smali directories or files
- independent archive entries
- independent filesystem scan/write tasks
A CLI option to control the worker count would be useful, for example:
Example usage:
java -Xmx8g -jar APKEditor.jar d -i app.apk -o out -jobs 8
java -Xmx8g -jar APKEditor.jar b -i out -o rebuilt.apk -jobs 8
Using -jobs 1 could preserve the current single-threaded behavior for compatibility, debugging, or deterministic testing.
Suggested behavior
- Default behavior could remain unchanged, or use a conservative default such as available processors.
-jobs 1 should force single-threaded processing.- Parallelization should be applied only to independent tasks where output order and correctness are not affected.
- Archive output ordering could remain deterministic even if processing is done in parallel.
Impact
Large APK processing is much slower than it could be on multi-core systems. This is especially noticeable for apps with many resource files, split APKs, and multiple DEX files.
Adding controlled parallel processing would improve performance for large workloads while still allowing users to preserve single-threaded behavior when needed.
Problem
APKEditor/ARSCLib appears to process many large APK workloads mostly sequentially.
On modern multi-core systems, heavy operations such as resource decoding/encoding, DEX handling, smali disassembly/assembly, and large file scanning/writing do not seem to utilize available CPU cores effectively. This can make processing large applications significantly slower than necessary.
Affected operations
This is noticeable during operations such as:
Example workload
Environment:
classes*.dexfilesDuring these operations, CPU usage remains mostly limited instead of scaling across available CPU cores.
Expected behavior
Independent workloads should be processed in parallel where possible, for example:
A CLI option to control the worker count would be useful, for example:
Example usage:
Using
-jobs 1could preserve the current single-threaded behavior for compatibility, debugging, or deterministic testing.Suggested behavior
-jobs 1should force single-threaded processing.Impact
Large APK processing is much slower than it could be on multi-core systems. This is especially noticeable for apps with many resource files, split APKs, and multiple DEX files.
Adding controlled parallel processing would improve performance for large workloads while still allowing users to preserve single-threaded behavior when needed.