Feature Proposal: First-Boot Asset Extraction to Fix App Lag & High RAM Usage (Offline Version) #1102
Description
Issue Checklist
- I confirm that this feature request has not been previously suggested.
- I agree to follow the project's code of conduct.
- I have checked and verified that I am using the latest version of Code on the Go from GitHub or App Dev for All.
Additional terms
- I understand that feature requests are subject to evaluation and may not be implemented immediately.
- I agree to provide additional details if needed for a clearer understanding of the requested feature.
Feature description
Hello Ben sir, David sir, and the entire COTG team,
I am submitting this feature proposal regarding the performance and core architecture of the offline version. Since you are senior developers, I assume you might have already discussed this internally, but I wanted to share my perspective as a user testing the app.
The Core Problem:
Currently, the offline version is distributed as a monolithic APK of around 900MB. Because the SDK, NDK, and compilers are packed directly into the base APK, the Android OS treats it as an extremely heavy application. This results in the system allocating a massive amount of RAM just to keep the app open, causing UI lag, slow startup times, and device heating, even when a user is just typing code and not actively compiling.
The Proposed Architecture (First-Boot Asset Extraction):
Instead of forcing the OS to run a 900MB base application, COTG could use a "Bootstrap" or "Asset Unpacking" model.
The main APK can be a lightweight UI shell (around 50-100MB).
The heavy offline tools (Compilers, SDK, NDK) can be stored as a highly compressed archive inside the APK assets, or delivered as a separate Android Asset Pack (.obb).
Upon the first launch, the app shows a setup screen ("Configuring offline workspace...") and extracts these heavy toolchains directly into the device's internal app storage (e.g., /data/data/...).
Why this will fix the lag:
By separating the UI shell from the heavy compilers, the Android OS will only load the lightweight 100MB app into the active RAM. The heavy NDK/SDK tools will only be read from the local storage exactly when the user clicks the "Compile" or "Build" button. This will make the code editor UI incredibly smooth, prevent thermal throttling, and provide a much better coding experience, especially on low-end devices.
Thank you for your time, sir, and for building this amazing platform. I am just sharing my thoughts to help the project optimize its performance.
Use Case
Currently, the offline version of Code on the Go is shipped as a massive monolithic APK (~900MB). Because everything (SDK, NDK, Compilers) is packed directly inside the base APK, the Android OS treats it as an extremely heavy application. This results in high RAM consumption, slow app startup, and device heating, even when the user is just writing simple code and not actively compiling.
Benefits
The Solution (Bootstrap / Asset Unpacking):
Instead of forcing the app to run with a 900MB base footprint, the heavy offline tools (NDK, SDK, Compilers) can be compressed inside the APK or provided as an .obb (Asset Pack).
When the user opens the app for the very first time, we show a loading screen: "Setting up your offline workspace...". The app extracts these heavy tools silently into the phone's internal storage (like /data/data/... or a dedicated app folder).
Why this is a game-changer:
Lightning Fast App: Once extracted, the main COTG app only needs to be a lightweight UI shell (~50-100MB). The UI will run incredibly smooth without lagging.
Zero Heating/RAM Spikes: The Android OS will only load the 100MB app into RAM. The heavy NDK/SDK files will only be accessed from the storage when the user hits the "Compile" button.
Easier Updates: In the future, you can push small 20MB app updates for UI fixes, without forcing users to re-download the entire 900MB compiler package every single time.