arXiv:2606.23512v1 [cs.SE] 22 Jun 2026
Source-Free Detection and Impact Analysis of Compiler Optimization Problems in Mobile Applications Han Hu
Xiaoheng Xie
Bo Sun
Independent Researcher China [email protected]
Independent Researcher China [email protected]
Independent Researcher China [email protected]
Jian Gu
Gang Fan
Li Li
Monash University Australia [email protected]
Independent Researcher China [email protected]
Beihang University China [email protected]
Abstract
1
Mobile apps frequently suffer from performance issues such as frame drops, overheating, and excessive power consumption. While developers optimize algorithms and debug code, a critical bottleneck often goes unnoticed: native libraries compiled with low optimization levels (O0/O1 instead of O2/O3). Because these libraries execute without functional errors, the resulting performance degradation remains hidden in production apps, affecting millions of users. We present OptDetect, a source-free framework that detects compiler optimization problems directly from app binaries without requiring source code or build metadata. OptDetect handles mixed optimization levels within a single binary through a pipeline of binary disassembly, chunk-level classification, and weighted score aggregation, achieving 93.0% accuracy on controlled datasets and 81.9% on real-world datasets. Applying OptDetect to 21,972 native libraries from 830 top-ranked Google Play apps, we find that 30.5% of libraries use low optimization levels, affecting 91.7% of apps. Through case studies on 12 production apps (6 commercial, 6 open-source), we demonstrate that fixing detected issues reduces CPU instructions by 10-63% (median: 20.5%) for commercial apps and 15-58% (median: 32%) for open-source apps, with performance complaints decreasing by a median of 42% and ratings increasing by a median of 0.14 points. Further investigation reveals a previously overlooked root cause: widely-used third-party libraries are themselves distributed at low optimization levels, with 49.7% of 1,073 libraries in a major repository exhibiting this problem. These findings highlight the need for automated detection tools and industry-wide optimization standards.
Mobile applications (apps) have become ubiquitous computing platforms, with over 7.2 billion devices worldwide [43] executing performance-critical native code. Performance degradation in mobile apps, including frame drops, excessive energy consumption, and thermal throttling, directly impacts user experience: nearly 90% of users abandon apps due to poor performance [1], and over 50% of apps are uninstalled within 30 days, with performance being a leading cause [4]. While such issues are commonly attributed to inefficient code or hardware constraints, our analysis of real-world cases reveals a previously neglected factor: inappropriate compiler optimization levels applied to native libraries (.so files). We first encountered this issue while debugging performance issues in a popular mobile game (referred to as Game A, with over one million active users). Game A comprises 106 native libraries (.so files). User feedback consistently reported that the HarmonyOS [19] version exhibited poorer performance than the Android version, including noticeable lag and decreased responsiveness. Together with the Game A development team, we confirmed that both versions shared the same app logic and native code. We conducted runtime profiling to investigate this discrepancy and found that the HarmonyOS version executed approximately 60 percent more CPU instructions than its Android counterpart in certain functionalities. Further analysis revealed that the primary difference came from compiler optimization settings: some native libraries in the HarmonyOS version were compiled with lower optimization levels (O0 and O1), whereas the Android version used higher levels (O2 and O3). Figure 1 illustrates how such optimization differences can arise both across app versions and across platform builds, propagating through the build pipeline to affect runtime performance. This case reflects a broader challenge in modern mobile development. Although compiler optimization is a well-established concept, enforcing consistent and appropriate settings across all binary components remains challenging. Native libraries are often developed and compiled independently by multiple teams or third-party vendors. As a result, fragmented build pipelines, legacy code maintenance, unintentional misconfigurations, and poor communication can lead to mismatched optimization levels. Identifying these optimization problems in deployed apps presents technical challenges that existing performance analysis tools cannot address [45, 49]. Existing profilers expose runtime symptoms,
CCS Concepts • Software and its engineering → Compilers; Software performance; Software testing and debugging; • Computer systems organization → Mobile computing.
Keywords Mobile App Performance, Compiler Optimization, Empirical Software Engineering, Performance Analysis, Native Library
Introduction
ASE ’26, 2026,
Hu et al. Impact of Compiler Optimization Levels on Mobile App Performance
weighted score aggregation, representing the first such framework designed for large-scale mobile app analysis without source code. • The first large-scale empirical study of compiler optimization levels in mobile apps, covering 21,972 native libraries from 830 top-ranked Google Play apps. • The first multi-dimensional impact analysis of compiler optimization fixes, spanning technical performance (CPU instructions, binary size, power), user-perceived quality (app store ratings and feedback), and ecosystem-level root cause investigation.
Native Libraries (.so files)
Executed on Device
App V1 (Android)
Low CPU Load
High App Performance
Excuted on Device
Same Codebase
App V2 (Android)
Suboptimally Compiled Library
Excuted on Device
High CPU Load
Low App Performance
App V2 (HarmonyOS)
Figure 1: Impact of compiler optimization levels on mobile app performance. From the same codebase, App V1 (Android) packages high-optimization libraries (O2/O3), resulting in low CPU load and high performance. App V2 (Android) and App V2 (HarmonyOS) package low-optimization libraries (O0/O1), leading to high CPU load and degraded user experience.
but they do not identify the compiler optimization level of native libraries, and prior binary classifiers such as BinEye [48] do not target mixed-optimization mobile libraries distributed through app stores. App stores distribute only compiled binaries without source code or build metadata, so optimization-level detection must work directly from machine code. Moreover, modern .so files often contain code compiled with mixed optimization levels, due to linking static libraries or incorporating third-party components built with different settings. Manually inspecting each library requires deep compiler expertise, making it impractical at scale. To address these challenges, we present OptDetect, an automated end-to-end source-free framework for detecting compiler optimization problems in mobile apps. OptDetect extracts native libraries from app packages and operates through a pipeline of binary disassembly, instruction chunk-level optimization classification, and weighted score aggregation to derive library-level assessments. We apply OptDetect at scale to conduct a multi-dimensional study, addressing three research questions: (1) How accurate and efficient is our detection framework? (2) How widespread is the problem of low compiler optimization in modern mobile apps? (3) What are the impacts of addressing detected optimization problems in production apps? For RQ1, OptDetect achieves 93.0% accuracy on controlled datasets and 81.9% on real-world datasets. For RQ2, we analyze 21,972 native libraries from 830 top-ranked Google Play apps and find that 30.5% of native libraries use low optimization levels, affecting 91.7% of apps. For RQ3, fixing detected issues in 12 production apps (6 commercial, 6 open-source) reduces CPU instructions by 1063% for commercial and 15-58% for open-source apps. Root cause analysis identifies library repositories as a major source, where third-party libraries are distributed already compiled at low optimization levels. In summary, the main contributions of this paper are: • A source-free detection framework, OptDetect, that identifies compiler optimization problems directly from app binaries through a pipeline of chunk-level classification and
2
Background
Mobile apps rely on native libraries (.so files) for performancecritical functionality. These libraries are compiled by GCC [12] or Clang [39] at different optimization levels that control how aggressively the compiler transforms source code [31]. O0 disables optimization entirely for easier debugging. O1 applies basic optimizations such as constant folding and dead code elimination. O2 enables more aggressive optimizations including loop unrolling and improved register allocation. O3 adds further techniques such as aggressive inlining and vectorization. Os optimizes for binary size rather than speed. Among these, O0 and O1 are generally considered low optimization levels, while O2 and O3 are considered high optimization levels [31]. The optimization level choice has a direct impact on app performance. Code compiled at O0 can require substantially more CPU instructions than the same code at O3 [31]. However, optimization settings are easily overlooked in practice. Standard profiling tools (Systrace [14], Perfetto [13], DevEco Profiler [18]) can identify CPU hotspots and memory leaks, but cannot determine whether poor performance stems from algorithmic inefficiency or inappropriate compilation settings. This gap is especially problematic for precompiled third-party libraries, where developers lack access to source code or build configurations to verify optimization levels.
3 RQ1: Detection Framework and Validation 3.1 Framework Design Since native libraries typically contain code compiled with mixed optimization levels, accurate library-level assessment requires decomposing the analysis into (1) fine-grained chunk-level classification and (2) weighted aggregation. We realize this in OptDetect through a six-stage pipeline shown in Figure 2. Native Library Extraction. We unpack application packages and extract embedded native libraries (.so files) for analysis. We apply filtering criteria to exclude unsuitable binaries such as stubs, encrypted content, and heavily obfuscated binaries. Binary Disassembly. We extract executable code segments from native libraries for analysis. The disassembly process focuses on the .text section, which contains the main executable code. For libraries with malformed headers, we employ full binary scanning to recover instruction sequences. Instruction Chunking and Feature Extraction. To address the challenge of mixed optimization levels within libraries, we partition the .text section into fixed-size byte windows of 𝑊 bytes with a configurable stride 𝑆. Each chunk 𝐶𝑖 is a contiguous byte
Source-Free Detection and Impact Analysis of Compiler Optimization Problems in Mobile Applications
(1)
Mobile Application
(2)
Native libraries
(3)
Disassembled Binary (.text)
(4)
Instruction Chunks
DL Classifier
ASE ’26, 2026,
O0
O3
O2
Os
Classified Chunks
(5)
(6)
Prediction Aggregation Optimization-labeled libraries
Figure 2: Overview of the OptDetect detection framework. The six-stage pipeline consists of native library extraction, binary disassembly, instruction chunking and feature extraction, deep learning-based classification, prediction aggregation, and optimization level assignment.
sequence: 𝐶𝑖 = {𝑏𝑖 ·𝑆 , 𝑏𝑖 ·𝑆+1, . . . , 𝑏𝑖 ·𝑆+𝑊 −1 } where 𝑏 𝑗 is the 𝑗-th byte in the .text section, yielding 𝑚 = ⌊(𝑁 − 𝑊 )/𝑆⌋ + 1 chunks for a section of 𝑁 bytes. On fixed-width Instruction Set Architectures (ISAs) such as AArch64 (4-byte instructions), each 𝑊 -byte window maps directly to 𝑊 /4 instructions, preserving instruction-level semantics. For each chunk 𝐶𝑖 , the classifier learns a latent feature representation f𝑖 ∈ R𝑑 that captures four categories of optimization characteristics:
we directly classify the library as that dominant level (e.g., O0dominant or O3-dominant). For mixed libraries where no single level dominates, the continuous score Scorelib ∈ [0, 1] captures their position on the optimization spectrum. We partition this range into four transition zones using empirically determined thresholds, reflecting the boundaries between adjacent optimization levels (e.g., O0/O1 mixed, O1/O2 mixed). These labels reflect a library’s current optimization composition on a continuous scale, not a binary high/low judgment. The specific threshold values and their geometric justification are reported in Section 3.3.
f𝑖 = [𝑓opcode, 𝑓register, 𝑓control, 𝑓structure ] where 𝑓opcode encodes instruction distribution patterns, 𝑓register captures register allocation strategies, 𝑓control reflects control flow structures, and 𝑓structure represents code layout characteristics such as alignment and padding. These features are not hand-crafted but implicitly learned by the neural network from raw byte sequences. The specific values of 𝑊 and 𝑆 are reported in Section 3.3. Deep Learning Classification. We employ a deep learning classifier to predict optimization levels at the chunk level. For each chunk 𝐶𝑖 with learned feature representation f𝑖 , the classifier produces a probability distribution over five optimization levels: 𝑃 (𝑦𝑖 |f𝑖 ) = softmax(ℎ(f𝑖 )) where 𝑦𝑖 ∈ {𝑂0, 𝑂1, 𝑂2, 𝑂3, 𝑂𝑠} represents the predicted optimization level for chunk 𝐶𝑖 , and ℎ(·) is the neural network function that maps learned representations to logits. Prediction Aggregation. We aggregate chunk-level predictions to compute a unified library-level optimization score: Í4 𝑗=0 𝑤 𝑗 · Chunks 𝑗 Scorelib = Total Chunks where 𝑤 𝑗 represents the weight assigned to optimization level 𝑗 (reflecting its relative runtime performance, with higher optimization levels receiving higher weights), and Chunks 𝑗 denotes the number of code chunks classified as level 𝑗. The specific weight values are reported in Section 3.3. We also compute a confidence measure based on prediction consistency: Entropy(p) Confidence = 1 − log2 (5) where p is the normalized distribution of chunk predictions across the five optimization levels. Optimization Level Assignment. We assign discrete optimization levels to libraries using a hybrid approach. For libraries where a single optimization level accounts for more than 𝜏𝑑 of all chunks,
3.2
Validation Setup
We train and validate our framework using two publicly available datasets. The Optimization-Detector dataset [38] contains approximately 17,000 .so files compiled with five optimization levels (O0, O1, O2, O3, Os) across seven architectures using GCC and Clang. The Assemblage dataset [26] contains real-world libraries compiled from GitHub repositories with known compiler flags, and each binary is distributed with its ground-truth optimization level label (O0, O1, O2, O3). Because Assemblage sources code from diverse real projects with varying coding styles, build systems, and complexity, it serves as a more challenging validation benchmark than synthetically compiled datasets. To prevent data leakage, we perform the 80/20 train/test split at the project level: all .so files derived from the same source project are assigned exclusively to either the training or test set, ensuring that the model cannot memorize project-specific code patterns. The dataset spans 7 architectures (x86_64, AArch64, RISC-V, PowerPC, SPARC, MIPS, ARM32). Among them, x86_64 and AArch64 constitute the two largest subsets (4,071 and 3,399 samples respectively), consistent with their prevalence in mobile platforms. We use 80% for training and 20% (approximately 3,000 samples) for testing.
3.3
Implementation
We implement OptDetect using Python with LIEF [40] for binary parsing and .text section extraction, Capstone [41] for disassembly, and PyTorch [35] for the deep learning classifier. The classifier uses a bidirectional LSTM architecture that takes raw byte sequences as input and predicts chunk-level optimization levels. For the experiments reported in this paper, we set 𝑊 = 2048 bytes and 𝑆 = 2048 bytes (non-overlapping windows). On AArch64, each 2048-byte
ASE ’26, 2026,
Hu et al.
window corresponds to 512 instructions, providing sufficient context for the model to capture local optimization patterns. Libraries with fewer than 5 valid chunks are excluded from analysis. We train a single unified model across all seven ISAs, as optimizationlevel signatures are largely architecture-agnostic despite differences in specific opcodes. The training set contains 17,062 libraries across 7 ISAs, with AArch64 and ARM32 as the two largest subsets. We train using cross-entropy loss with Adam optimizer (learning rate = 0.001, batch size = 32) for 100 epochs with early stopping. We use standard classification metrics: accuracy, precision, recall, F1-score, and false positive rate. The aggregation weights are 𝑤 O0 = 0.0, 𝑤 O1 = 0.25, 𝑤 O2 = 0.75, 𝑤 O3 = 1.0, and 𝑤 Os = 0.5. Os is assigned 0.5 because it optimizes for binary size rather than speed, and empirical validation shows its runtime performance falls between O1 and O2. All weight values were determined through iterative empirical analysis on our validation set. For optimization level assignment, the dominance threshold is 90%, and the score boundaries for the four transition zones are 0.15, 0.35, and 0.65, corresponding to Near-O0 mixed [0, 0.15), O0/O1 mixed [0.15, 0.35), O1/O2 mixed [0.35, 0.65), and O2/O3 mixed [0.65, 1.0). These thresholds are calibrated to maximize separation between low-optimization (O0/O1) and high-optimization (O2/O3) libraries. The prevalence thresholds used in RQ2 and RQ3 are derived from these transition zones.
3.4
Validation Results
We evaluate our framework on both the Optimization-Detector dataset (artificially compiled data) and the Assemblage dataset (realworld data). Table 1 presents the comparative results. Table 1: Performance evaluation of optimization level classification. Assemblage (Binary: Low vs High) represents binary classification accuracy for distinguishing Low-Optimization Libraries (O0/O1) from High-Optimization Libraries (O2/O3) on the Assemblage dataset. Dataset
Level
Prec.
Rec.
Acc.
F1
Opt-Detector
O0 O1 O2 O3 Os
95.8% 89.2% 93.1% 94.6% 92.5%
94.2% 87.6% 92.8% 93.8% 91.7%
95.1% 88.8% 92.9% 94.3% 92.4%
95.0% 88.4% 93.0% 94.2% 92.1%
Assemblage
O0 O1 O2 O3
85.3% 76.8% 82.1% 83.9%
83.7% 74.4% 81.5% 82.6%
84.9% 76.1% 81.7% 83.5%
84.5% 75.6% 81.8% 83.2%
Opt-Detector (Macro) Opt-Detector (Weighted) Assemblage (Macro) Assemblage (Weighted)
93.0% 92.0% 92.7% 92.5% 93.2% 92.9% 93.0% 93.1% 82.0% 80.6% 81.6% 81.3% 82.5% 81.1% 81.9% 81.8%
Assemblage (Binary: Low vs High)
91.0%
90.5%
90.8%
90.7%
Table 1 shows that our framework achieves 93.0% weighted accuracy and 93.1% weighted F1 on the Optimization-Detector test set and 81.9% weighted accuracy and 81.8% weighted F1 on the realworld Assemblage dataset. At the per-level granularity, O0 achieves the highest accuracy on both datasets (95.1% on Opt-Detector, 84.9% on Assemblage) due to its distinct unoptimized instruction patterns.
O3 performs second best (94.3% / 83.5%). O1 shows the lowest performance (88.8% / 76.1%) due to overlap with adjacent levels, particularly on Assemblage where mixed optimization makes level boundaries ambiguous. O2 (92.9% / 81.7%) and Os (92.4%) perform consistently across both datasets. Generalization analysis. The approximately 11% accuracy drop from controlled (93.0%) to real-world (81.9%) reflects the difference between libraries with single optimization levels and those containing mixed optimization chunks. Intermediate levels (O1, O2) remain the most challenging due to similar instruction patterns, while extreme levels (O0, O3) are more distinguishable. Baseline scope. No existing method directly matches our target setting of source-free analysis for mixed-optimization mobile libraries. BinEye [48] is the closest prior binary-level classifier, but its evaluation setting differs from ours and it does not target mixedoptimization libraries at app scale. We therefore use a rule-based baseline for direct empirical comparison and discuss BinEye qualitatively in Related Work. Comparison with rule-based baseline. We implemented a rule-based baseline that exploits known binary-level signatures of optimization levels, including instruction density, opcode distribution (O2/O3 emits more SIMD (Single Instruction, Multiple Data) and pipeline-filling instructions), presence of frame pointers and debug sections, and .text-to-symbol-count ratio. We evaluate both methods on two regimes using the same test splits. On single-optimization-level libraries from the Opt-Detector test set (20%), the rule-based baseline achieves 79.8% binary classification accuracy, while OptDetect achieves 93.0% (5-class), confirming that both approaches can detect optimization levels when libraries are compiled uniformly. On 100 mixed-optimization libraries randomly sampled from the Assemblage test set, whose ground truth was established through developer confirmation, build scripts, and source code inspection, the rule-based baseline drops to 68.7% (a decline of 11.1 percentage points) because global statistics average across locally-varying chunks and cannot resolve mixed optimization patterns. OptDetect maintains 86.0% accuracy on the same set, slightly above its 81.9% on the full Assemblage test set. This comparison validates the core design choice. Chunk-level decomposition is essential for the mixed-optimization scenario that dominates real-world mobile libraries. Binary classification performance. While five-class classification achieves 81.9% on the Assemblage dataset, the binary task of distinguishing Low-Optimization Libraries (O0/O1) from HighOptimization Libraries (O2/O3) achieves 90.8% accuracy and 91.0% precision. This confirms the framework’s applicability for identifying libraries that need optimization correction in production apps, where the practical objective is to detect optimization problems rather than pinpoint exact levels. Computational efficiency. Our classifier processes an average of 847 instruction chunks per second on commodity hardware. The average classification time per library is 0.23 seconds, making the framework suitable for large-scale analysis.
Source-Free Detection and Impact Analysis of Compiler Optimization Problems in Mobile Applications
Answer to RQ1: Our optimization detection framework achieves high accuracy (93.0%) on controlled datasets with single optimization levels and maintains reasonable generalization (81.9%) on real-world datasets with mixed optimization levels. More importantly, for the core task of distinguishing Low-Optimization Libraries from High-Optimization Libraries, the framework achieves 90.8% accuracy and 91.0% precision on real-world data, validating its practical effectiveness for identifying optimization problems in production apps.
4
RQ2: Prevalence of Low Optimization in Real World Apps
To investigate how widespread low compiler optimization practices are in modern mobile software, we conduct a large-scale empirical study on real-world top-ranked mobile apps. This investigation consists of data collection, prevalence analysis, analysis of reused libraries, and case study analysis.
4.1
Data Collection and Methodology
We collected 830 available top-ranked apps from Google Play Store (July 2025) across six categories: grossing apps, free apps, grossing games, free games, grossing wearable apps, and free wearable apps. We extracted and analyzed 21,972 native libraries from these apps. During extraction, we applied filtering criteria to exclude libraries unsuitable for optimization analysis: stub libraries (containing only symbol redirects with no executable code), encrypted or packed binaries (where the .text section is obfuscated), and heavily obfuscated binaries where Capstone failed to disassemble more than 50% of the .text section. These exclusion criteria were applied uniformly across all app categories.
4.2
show similar optimization patterns, with 24.3% and 28.4% of .so files exhibiting low optimization scores and average optimization scores of 0.565 and 0.548, respectively. Notably, high-optimization libraries are rare across all categories, with only 4.1% of total libraries classified as high-optimization (score ≥ 0.80). Mobile games demonstrate markedly worse optimization practices, with average optimization scores of 0.510–0.520 and 32.7%–36.5% of .so files classified as low-optimization. Wearable applications exhibit intermediate optimization patterns, with grossing wears and free wears showing 31.2% and 34.2% low-optimization ratios respectively, and average optimization scores of 0.525 and 0.511. This positions wearable apps between regular apps and games in terms of optimization quality, confirming a consistent trend across all app types. Overall, 30.5% of all analyzed native libraries use low optimization levels, affecting 91.7% of apps, indicating that optimization issues are systemic rather than isolated. The disparity between categories is notable. Games typically demand high performance yet show the worst optimization practices (32.7%–36.5% low-optimization), while wearable apps with constrained hardware resources perform better than games but worse than regular apps (31.2%–34.2% vs. 24.3%–28.4%). Detailed Optimization Level Analysis. To gain deeper insights into optimization practices, we analyze the distribution of optimization levels at the code chunk granularity. Table 3 presents the detailed breakdown of optimization level chunks across application categories. Table 3: Distribution of Optimization Level Chunks Across Application Categories (Including Wearables). Chunks represent code segments identified by our classifier. Category
O0 Chunks
O1 Chunks
O2 Chunks
O3 Chunks
Os Chunks
Total Chunks
Grossing Apps
404,919 (16.1%)
216,900 (8.6%)
726,524 (29.0%)
490,291 (19.5%)
669,277 (26.7%)
2,507,911
Top Free Apps
285,563 (15.3%)
175,680 (9.4%)
578,810 (31.0%)
379,772 (20.3%)
448,620 (24.0%)
1,868,445
Grossing Games
794,023 (27.1%)
189,877 (6.5%)
825,067 (28.1%)
621,328 (21.2%)
503,977 (17.2%)
2,934,272
Top Free Games
671,109 (29.5%)
151,955 (6.7%)
620,904 (27.3%)
433,099 (19.0%)
399,799 (17.6%)
2,276,866
Grossing Wears
165,915 (18.3%)
94,710 (10.5%)
268,596 (29.7%)
153,181 (16.9%)
222,409 (24.6%)
904,811
Top Free Wears
205,666 (18.1%)
108,495 (9.6%)
348,875 (30.8%)
219,941 (19.4%)
250,191 (22.1%)
1,133,168
Total
2,527,195 (21.7%)
937,617 (8.1%)
3,368,776 (29.0%)
2,297,612 (19.8%)
2,494,273 (21.5%)
11,625,473
Prevalence Analysis
Table 2 presents the distribution of optimization levels across our dataset. For all prevalence analyses in this paper (RQ2 and RQ3), we define two score-based categories derived directly from the transition zones established in Section 3.3: a library is low-optimization if its score falls below 0.50 (midpoint of the O1/O2 transition zone), and high-optimization if its score reaches 0.80 or above (upper O2/O3 zone). Our analysis reveals that low compiler optimizations are widespread in real-world mobile apps. Table 2: Distribution of Optimization Levels Across Application Categories (Including Wearables) Category
.so Files
Avg. Opt. Score
Low Opt. Files
Low Opt. High Opt. Ratio Files
High Opt. Ratio
Grossing Apps Top Free Apps Grossing Games Top Free Games Grossing Wears Top Free Wears
5,100 4,566 3,084 3,884 2,592 2,746
0.565 0.548 0.520 0.510 0.525 0.511
1,238 1,299 1,009 1,416 809 938
24.3% 28.4% 32.7% 36.5% 31.2% 34.2%
243 242 125 86 96 103
4.8% 5.3% 4.1% 2.2% 3.7% 3.8%
Total
21,972
0.534
6,709
30.5%
895
4.1%
Note: Thresholds defined in Section 4: Low optimization = score < 0.50; High optimization = score ≥ 0.80.
The results demonstrate significant variation across application categories. Among regular apps, both grossing apps and free apps
ASE ’26, 2026,
The chunk-level analysis shows consistent patterns across categories. Across all 11,625,473 analyzed chunks, O0 accounts for 21.7% and O1 for only 8.1%, while high-optimization chunks (O2+O3) total 48.7% and Os accounts for 21.5%. At the category level, games have the worst distribution: grossing games contain 27.1% O0 chunks and 49.3% high-optimization (O2+O3) chunks, compared to regular apps at 15.3–16.1% O0 and 48.5–51.3% high-optimization. Free games show slightly worse values at 29.5% O0 and 46.3% highoptimization. Wearable applications fall in between at 18.1–18.3% O0 and 46.6–50.2% high-optimization chunks. Os (size-optimized) chunk prevalence varies from 17.2% in grossing games to 26.7% in
ASE ’26, 2026,
Hu et al.
grossing apps, with wearables at 22.1–24.6%. Notably, O1 chunks are consistently the smallest proportion across all categories (6.5%– 10.5%). This suggests that libraries tend to be either debug builds (O0) inadvertently shipped in release packages, or properly optimized release builds (O2/O3). O1 is rarely a deliberate choice in practice.
(1) technical performance improvements, (2) user-perceived quality improvements, and (3) the underlying sources of optimization problems. We conduct an in-depth analysis of 12 production apps: 6 top-ranked commercial apps and 6 open-source apps published on Google Play Store.
5.1 4.3
Analysis of Reused Libraries
Table 4 presents the most frequently reused native libraries that consistently exhibit low optimization scores (average score below 0.50), each appearing in at least 10 apps. Table 4: Most Common Low-Optimization Native Libraries Library Name
Occs. Avg. Opt. Low Opt. Score Ratio
libcrashlytics-trampoline.so libmain.so libil2cpp.so libtobEmbedPagEncrypt.so libdatastore_shared_counter.so libbuffer.so libsentry-android.so libsurface_util_jni.so libbugsnag-root-detection.so libsqlite3.so
146 145 141 95 71 57 41 36 28 27
0.023 0.218 0.317 0.427 0.218 0.363 0.351 0.258 0.071 0.496
96.6% 61.4% 80.9% 72.6% 100.0% 94.7% 85.4% 91.7% 92.9% 33.3%
Example Apps Firebase Crashlytics, Unity Games Various Unity Apps, Native Games Unity Games, C# Mobile Apps Chinese Apps, Security SDKs Google Play Services, Analytics Media Apps, Buffer Management Error Tracking, Crash Reporting Graphics Apps, Surface Rendering Security Apps, Root Detection Database Apps, Local Storage
The most concerning finding is libcrashlytics-trampoline.so, a crash reporting library that appears in 146 apps with an average optimization score of only 0.023. This library exemplifies the widespread impact of third-party SDK optimization issues, as crash reporting is critical for application stability yet performs poorly due to low-optimization compilation. Similarly problematic is libil2cpp.so, Unity’s IL2CPP runtime library found in 141 applications (primarily games) with an optimization score of 0.317. Given Unity’s dominance in mobile game development, this represents a significant performance bottleneck affecting millions of users. These findings reveal two primary sources of optimization problems: (1) third-party SDKs distributed as precompiled binaries with poor optimization settings, and (2) widely-used development frameworks (e.g., Unity) that may not prioritize optimization in their default build configurations. Answer to RQ2: Low compiler optimizations are widespread, affecting 30.5% of 21,972 analyzed native libraries across 830 apps, with 91.7% of apps containing at least one low-optimization library. Only 4.1% of libraries achieve high optimization levels. Games show the worst optimization practices (32.7%–36.5% lowoptimization), followed by wearable apps (31.2%–34.2%), with regular apps performing best (24.3%–28.4%). Frequently reused third-party SDKs and development framework libraries are a primary source of the problem.
5
RQ3: Multi-dimensional Impacts of Optimization Fixes
To understand the real-world impacts of addressing compiler optimization problems, we investigate RQ3: What are the multidimensional impacts of fixing optimization problems in production apps? This research question examines three dimensions:
Research Design and Methodology
Case Selection. We select 12 production apps: 6 top-ranked commercial apps and 6 open-source apps. Selection criteria include app popularity (millions of active users), presence of native libraries with identified optimization issues, and feasibility of collaboration. Commercial apps include Payment App A (payment platform), Video App B (video streaming), Social App C (social media), Card Game X (strategy game), FPS Game B (first-person shooter), and MOBA Game C (multiplayer battle arena), anonymized per confidentiality agreements. Open-source apps additionally require accessible source code and complete build systems: VLC, Kodi, Firefox, Termux, Signal, and Telegram. Table 5: Case Study Apps: Commercial and Open-Source Commercial Apps (Case Set 1)
Open-Source Apps (Case Set 2)
App
Description
App
Description
Payment App A
Leading mobile payment platform with QR code scanning
VLC
Video App B
Video streaming and content cre- Kodi ation platform Social media and content sharing Firefox app Strategy card game with complex Termux rendering
Multimedia player with FFmpeg codecs (2.5K+ stars, 100M+ downloads) Media center with native rendering (16K+ stars, 50M+ downloads) Web browser with Gecko engine (1.2K+ stars, 500M+ downloads) Terminal emulator with native execution (25K+ stars, 10M+ downloads) Encrypted messaging with crypto libraries (42K+ stars, 100M+ downloads) Messaging app with native libraries (25K+ stars, 1B+ downloads)
Social App C Card Game X
FPS Game B
First-person shooter with inten- Signal sive graphics
MOBA Game C
Multiplayer battle arena using Unity3D
5.2
Telegram
RQ3.1: Technical Performance Improvements
Methodology. For each commercial app we: (1) identify low-optimization libraries using OptDetect, (2) recompile affected libraries at O2 for general code and O3 for computationally intensive components, (3) measure retired CPU instructions via hardware Performance Monitoring Units (PMU) on a flagship Android device (Snapdragon 8 Gen 3, Android 14) using Android Studio Profiler with kernellevel PMU access for precise non-sampled counting, and (4) validate correctness with partner test suites (unit, integration, functional), with specific checks for floating-point stability, timing-sensitive code, and constant-time crypto. Both original and optimized builds are measured on the same device under identical workloads, so hardware variation cancels in the relative reduction. We report means over 5–10 runs per configuration (standard deviation, SD < 1.5% across all metrics). Metric Justification. We use CPU retired instruction count as the primary performance indicator because it directly quantifies computational work and correlates strongly with execution time and energy consumption [16, 32]. Retired instructions are those that complete execution and produce committed results, excluding speculative or flushed instructions, making the count a stable and reproducible measure of actual work performed. As described
Source-Free Detection and Impact Analysis of Compiler Optimization Problems in Mobile Applications
above, all measurements are conducted on the same device under identical workloads, so the percentage reduction reflects only the optimization-level change. This approach is widely used in compiler optimization research [5, 31]. CPU instruction reduction is therefore our primary cross-app comparable metric. Supplementary user-facing metrics (startup latency, frame rate, binary size, etc.) are reported as secondary evidence where partner confidentiality agreements and data access permit, and consequently vary across apps. Results. Table 6 summarizes results for all six commercial apps. CPU instruction reductions range from 10% to 63% (median: 20.5%). The variation reflects two factors: the number of libraries successfully optimized and their execution frequency, as libraries on the critical path yield the largest gains. Payment App A contained 98 unoptimized libraries, of which 6 were successfully optimized under collaboration constraints, while other apps had more focused interventions (1–10 libraries). Payment App A achieves 22% reduction. Card Game X achieves 63% reduction with 40% power consumption reduction and 15 FPS gain. Video App B achieves 25% reduction with 15% streaming latency reduction and 30% frame-drop reduction. Social App C achieves 19% reduction across 8 of 17 libraries with improvements in feed scrolling and image loading. FPS Game B achieves 10% reduction with thermal throttling mitigation. MOBA Game C achieves 13% reduction alongside 65% binary size reduction (37MB→13MB) and 35% load-time reduction. Table 6: Performance Improvements for Commercial Apps (Case Set 1). All apps deployed to production. App
Optimized Libraries (Fixed/Total)
libqrscanner.so, libimageproc.so Payment App A (6/98)
Additional Metrics (Disclosed)
CPU Reduc.
Cold start: -200ms QR init: -60%, Binary: -22%
22%
Video App B
libbroadcast-client.so, libstream.so (2/3)
Streaming: -15% latency Frame drops: -30%
25%
Social App C
libsocial-log.so, libnetwork.so, ... (8/17)
Feed scrolling: smoother Image loading: faster
19%
Card Game X
librender.so, libgame-engine.so (2/2)
Power: -40% Frame rate: +15 FPS
63%
FPS Game B
10 O0 libs (graphics, physics, audio) Latency: -8% (10/10) Thermal throttling: reduced
10%
MOBA Game C
il2cpp.so, Unity 3D (1/1)
13%
Binary: -65% (37→13MB) Load time: -35%
Case Study: Payment App A. Payment App A (100M+ QR scans/day) had persistent user complaints about slow QR scanning despite months of manual code optimization by the development team. OptDetect identified that 6 QR-module libraries (libqrscanner.so, libimageproc.so, libcamera-util.so, etc.) were compiled at O0. Investigation revealed that app development, maintenance, and release were handled by separate teams, and during one release cycle a release team had accidentally packaged debug-version libraries into the production app, a mistake that persisted undetected across multiple releases. Recompiling at O2/O3 achieved 22% CPU instruction reduction, 60% camera initialization speedup (800ms→320ms), 200ms cold-start improvement, and 22% binary size reduction (321MB→249MB).
5.3
ASE ’26, 2026,
RQ3.2: User-Perceived Quality Improvements
We analyze app store reviews to test whether technical improvements translate to user-perceived quality changes. We collect 13,156 reviews from multiple app stores across all of 2025 for the 6 commercial apps. Reviews are filtered to the five most frequent languages (English, Simplified Chinese, Traditional Chinese, Korean, Japanese), covering over 92% of all reviews. Performance-related keywords cover four categories with equivalent terms in all five languages: performance symptoms (e.g., “lag”, “freeze”), resource complaints (e.g., “battery drain”, “overheat”), loading issues (e.g., “slow startup”), and rendering issues (e.g., “frame drop”, “jank”). We compare monthly keyword frequency and average rating for the optimization month vs. the following month. A one-tailed Wilcoxon signed-rank test across the six apps yields 𝑝 = 0.031 (𝛼 = 0.05), confirming statistically significant keyword reduction. Note that keyword reduction is associated with, but not solely caused by, the optimization fix, as concurrent app updates may also contribute. Potential confounds are discussed in Threats to Validity. Results. Figure 3 and Table 7 show the results. Performancerelated keyword frequency decreases in 5 of 6 apps (21%–76%, median: 42%) and ratings improve in 5 of 6 apps (+0.09 to +0.21 stars, median: +0.14). Payment App A achieves the most dramatic improvement (– 76% keyword reduction, from 74 to 18), directly corresponding to its 22% CPU instruction reduction and 60% QR initialization speedup. FPS Game B shows similarly strong results (–73%, from 22 to 6) despite the lowest CPU reduction (10%), suggesting that even modest improvements on user-interactive features translate to substantial user perception gains. Card Game X shows a delayed but sustained decline (6→4→0 over three months), ultimately eliminating all performance-related complaints after the largest CPU reduction (63%) in the set takes full effect. Video App B shows balanced improvement (–29% keywords, +0.21 stars), with the highest rating increase among all apps. MOBA Game C achieves a moderate keyword reduction (–21%) despite the largest binary size reduction (65%), with the persistently high keyword volume reflecting the competitive gaming context where users are highly sensitive to any performance variation. Social App C is the only exception, showing keyword reduction (–55%) but a rating drop (–0.46 stars). Because aggregate star ratings are influenced by many factors beyond performance, we consider performance-symptom keyword frequency the more precise signal for evaluating optimization impact. Table 7: User Perception Changes for Commercial Apps After .so Optimization (2025 Data). (Opt → Next) indicates comparison between the optimization deployment month and the following month. App Payment App A Video App B Social App C Card Game X FPS Game B MOBA Game C Median
Optimization Date
Keywords (Opt → Next)
Keyword Change
Rating (Opt → Next)
Rating Change
2025-06 2025-09 2025-08 2025-09 2025-08 2025-07
74 → 18 70 → 50 66 → 30 6→6→4→0 22 → 6 111 → 88
-76% -29% -55% 0% -73% -21%
1.75 → 1.84 2.42 → 2.63 2.63 → 2.17 1.00 → 1.12 3.70 → 3.85 2.16 → 2.36
+0.09 +0.21 -0.46 +0.12 +0.15 +0.20
-
-
-42%
-
+0.14
ASE ’26, 2026,
Hu et al.
Figure 3: Monthly rating (blue, left y-axis) and performance-related keyword frequency (red, right y-axis) trends for six commercial apps throughout 2025. Red dashed lines and star markers indicate .so optimization intervention dates. Five apps show immediate keyword reductions in the month following optimization, while Card Game X shows delayed but sustained decline over three months (6→4→0).
5.4
Open-Source App Results and Root Cause Analysis
Unlike commercial apps where source code is inaccessible, opensource apps allow us to trace each low-optimization library to its origin through build script and source dependency analysis. For each of the six open-source apps, we examine whether lowoptimization libraries are compiled from the project’s own source code or included as third-party pre-compiled binaries. Across 314 native libraries in these six apps, we identify 25 lowoptimization libraries (8.0%). Table 8 presents the per-app tracing results. The findings are clear: 24 out of 25 libraries (96.0%) originate from third-party pre-compiled binaries distributed by external vendors or upstream repositories. The single exception is Telegram’s libtmessages.49.so, which is traced to an app-level build configuration error. Kodi alone accounts for 15 low-optimization libraries, all from the PyCryptodome Python crypto extension shipped as pre-compiled .so modules. Using the same measurement protocol as RQ3.1, CPU instruction reductions after fixing these libraries range from 15% to 58% (median: 32%). Developer Interviews. From the development and maintenance teams of all 12 apps, we recruit 18 developers who meet our criteria (≥3 years of mobile development experience with direct knowledge of build systems and release pipelines) and agree to participate
Table 8: Root Cause Tracing for Open-Source Apps (Case Set 2). Each low-optimization library is traced to its origin via build script and source dependency analysis. App
Low-Opt Count
VLC
Identified Libraries
Traced Origin
1
libvlcjni.so
Third-party (FFmpeg binding)
35%
Firefox
2
libclearkey.so, libsoftokn3.so
Third-party (NSS crypto)
23%
Signal
4
libsqlcipher.so, Third-party (crypto and libaesgcm.so, libim- media processing) age_processing_util_jni.so
28%
Termux
2
libtermux-bootstrap.so, libproot-loader.so
Third-party (system tools)
42%
Kodi
15
PyCryptodome modules (15 Third-party (Python .so files) crypto extension)
58%
Telegram
1
libtmessages.49.so
15%
Build config error
CPU Reduc.
in semi-structured interviews. Based on their responses, we identify four systemic challenges that contribute to low-optimization libraries persisting in production. (1) SDK vendor practices: vendors often ship debug builds to facilitate crash debugging, and requesting optimized builds takes a median of 3–6 months when successful. (2) Dependency chain complexity: transitive dependencies are largely invisible to app developers, making it difficult to audit optimization levels across the full dependency tree. (3) Process issues: debug builds are accidentally released to production due to separated development and release teams. (4) Lack of detection tools: prior to
Source-Free Detection and Impact Analysis of Compiler Optimization Problems in Mobile Applications
this work, no tooling existed to identify optimization problems in production app binaries, so the issue went undetected regardless of severity.
5.5
Ecosystem-Level Investigation
The interview findings above indicate that developers lack both the tools and the process visibility to audit optimization levels of third-party libraries. In practice, given the complexity of modern app build pipelines and the absence of detection tooling, developers have no choice but to assume that libraries from official repositories are properly optimized. To investigate whether this assumption holds, we conduct an ecosystem-level analysis of one such major repository. We investigate the official third-party library repository of a major mobile platform, which is the primary distribution channel for native libraries used by apps on that platform. Per our confidentiality agreement with the repository maintainers, we anonymize the repository identity. We analyze all 1,073 native libraries available in this repository as of December 2025. Applying the same score threshold defined in Section 4 (score < 0.50), our analysis reveals that 49.7% of libraries (533 out of 1,073) exhibit low optimization levels. The majority are classified as O0-dominant (467) or O1-dominant (35) by the tool’s dominance criterion (>90% of chunks at that level), indicating nearly pure low-optimization compilation. The remaining 31 have mixed-level scores in the O1/O2 transition zone (0.35–0.50). The snapshot is included in our artifact for reproducibility. Table 9 presents the functional breakdown of the 502 O0- and O1-dominant libraries. Table 9: Functional Distribution of Low-Optimization Libraries in Repository Function Category
Count
% of Low-Opt
System Utilities & FFI Multimedia/Codec Cryptography Networking Location/Map Image Processing Data Compression Speech/Audio
420 26 22 16 7 5 5 1
83.7% 5.2% 4.4% 3.2% 1.4% 1.0% 1.0% 0.2%
Total
502
100%
System utilities and FFI interfaces constitute the majority (83.7%, 420 libraries), including general-purpose utilities (libentry.so, liblibrary.so), logging frameworks (libaliyunlog.so, 5.2 MB), location services (liblocsdk8b.so), and HTTP servers (libmongoose.so). While individual utilities may not be hotspots, the cumulative effect of numerous low-optimization libraries is significant as modern apps integrate dozens of them. Multimedia codecs rank second (26 libraries, 5.2%), including large video players (libHJPlayer.so, 23.41 MB) and FFmpeg-based decoders (libwlffmpeg.so, 18.57 MB). This is particularly concerning because multimedia processing is a performance-critical hotspot in mobile applications. Poorly optimized codecs directly impact video playback, audio quality, and media loading, making their optimization gaps more severe in practice. Affected libraries span a wide size range from 3.96 KB to 25.39 MB (average: 712.76 KB,
ASE ’26, 2026,
median: 4.64 KB), with the largest files representing the most severe bottlenecks due to high instruction overhead and memory footprint. Cryptography libraries (4.4%) and networking libraries (3.2%) are also noteworthy, as both are frequently invoked during core operations such as authentication, data encryption, and API communication. Low optimization in these categories can degrade responsiveness in latency-sensitive user workflows. Repository Acknowledgement. We disclosed our findings to the repository maintainers. They explained that the repository does not compile most libraries itself but instead accepts pre-compiled binaries submitted by library developers, trusting that submitted artifacts are production-ready. Without batch-level optimization detection tools, the repository had no mechanism to verify the optimization quality of incoming submissions. After multiple rounds of communication and presentation of our detection evidence, the maintainers formally acknowledged that a significant number of libraries in the repository were distributed with debug-level compilation configurations, and are working with affected library developers to address the issue. Answer to RQ3: Fixing compiler optimization problems in production apps yields substantial and measurable impacts. CPU instruction reductions range from 10%–63% (median: 20.5%) for 6 commercial apps and 15%–58% (median: 32%) for 6 open-source apps. Performance-symptom keyword frequency in app store reviews decreases in 5 of 6 commercial apps (median: –42%, 𝑝 = 0.031), providing a more targeted signal of optimization impact than aggregate star ratings. Root cause tracing in opensource apps shows that 96% (24/25) of low-optimization libraries originate from third-party pre-compiled binaries. An ecosystemlevel investigation of a major library repository confirms the systemic nature of this problem: 49.7% of 1,073 libraries exhibit low optimization levels, with the repository maintainers formally acknowledging the issue after reviewing our evidence.
6
Threats to Validity
Confidence Score Usage. Our framework computes an entropybased confidence score for each library classification and reports it as a supplementary diagnostic output rather than using it for automated filtering. Confidence-weighted prevalence estimation is left to future work. Framework Generalizability. Our framework’s accuracy depends on training data representativeness. The chunk window size (𝑊 = 2048 bytes) was selected empirically, and we did not exhaustively ablate this hyperparameter. We adopt a unified cross-ISA model because optimization-level signatures are largely architectureagnostic and a unified model benefits from a larger combined training set, while per-ISA ablations remain future work. We use BiLSTM due to its strong sequence modeling and low training cost, and alternative architectures such as CNNs or Transformers remain future work. The aggregation weights and prevalence thresholds were empirically tuned on the validation set. Although we use both Optimization-Detector and Assemblage, they may not cover all compiler versions and build configurations. Our framework may also face challenges with heavily obfuscated or packed binaries that obscure optimization patterns.
ASE ’26, 2026,
Dataset Sampling. Our dataset comprises 830 top-ranked apps from Google Play Store in July 2025. Top-ranked apps may have better optimization practices than average apps, potentially underestimating the ecosystem-wide problem. However, these apps collectively account for the vast majority of user installations and interactions, making optimization issues in this set highly relevant for real-world user impact. User Perception Analysis. Our user perception analysis uses correlational evidence from app store reviews. Keyword selection may not capture all performance-related feedback, and confounding factors such as new feature releases, bug fixes, or public events may influence rating changes independently of optimization fixes. Metric Limitations. We use CPU instruction count as our primary performance metric, which provides a reliable and scalable proxy but does not capture all performance dimensions such as cache behavior and memory bandwidth. Additionally, our RQ2 prevalence analysis counts all libraries and chunks statically without weighting by runtime hotness: a low-optimization library that is rarely invoked contributes less actual performance overhead than one on the critical path. While RQ3 demonstrates real-world impact through deployment case studies, the static counts in RQ2 may overestimate ecosystem-wide performance waste for libraries that are infrequently called. Additionally, standard compiler optimization transitions (O0/O1 to O2/O3) may introduce edge-case risks in floating-point rounding, timing-sensitive code, or cryptographic routines requiring constant-time execution. Our validation across 12 apps mitigates but does not eliminate these concerns.
7
Related Work
Compiler Optimization Detection and Binary Analysis. Research on compiler optimization detection has primarily focused on desktop and server environments. Previous work has explored optimization level identification through static analysis of assembly code patterns [2], performance counter analysis [3], and compiler fingerprinting techniques. Recent advances include binary-level optimization detection using deep learning [9, 42] and transparent compiler optimization frameworks [30]. Binary analysis techniques have been extensively developed for malware detection [29], vulnerability analysis, and reverse engineering [25, 36]. Static and dynamic methods analyze instruction patterns or runtime behavior [17, 46], and large-scale studies have explored code size optimization for native apps [27]. However, these techniques typically focus on code behaviors rather than inferring compilation settings from binary characteristics. BinEye [48] reports high accuracy for single-optimization binaries, but does not target mixed-optimization libraries or library-level aggregation at production mobile app scale. Existing methods also rely on source access or controlled settings, which limits third-party app analysis. This distinction matters because app stores expose only packaged binaries, so practical diagnosis must work sourcefree while handling mixed libraries reused across many production apps. Our work provides binary-only detection with weighted aggregation and ecosystem-scale measurement. Mobile App Performance Analysis. Existing mobile app performance analysis primarily focuses on high-level factors such as UI responsiveness, memory leaks, and network latency [24, 47].
Hu et al.
Tools like Android Profiler concentrate on runtime profiling of Java/Kotlin code and detecting memory bottlenecks [45, 49]. Recent research has explored energy consumption analysis [11, 15, 22], energy-aware design patterns [6], and power modeling tools [10]. Other studies have investigated automated GUI testing [44], energy issue detection [23], and device-specific behaviors [8]. These tools and techniques primarily operate at the application or system level, analyzing runtime metrics and resource usage patterns without examining the underlying compilation configurations that fundamentally determine code efficiency. These approaches largely overlook compiler optimization levels in native libraries. Unlike existing work that focuses on applicationlevel optimizations, our study provides the first large-scale empirical investigation of compiler-level inefficiencies in production apps. Compiler Optimization Impact Studies. Studies on compiler optimization impact have traditionally focused on controlled benchmark environments and synthetic workloads [20, 33]. Research has quantified the effects of various optimization techniques on CPU performance metrics and explored trade-offs between optimization levels and compilation time [28]. These studies typically measure performance improvements in isolation, using standard benchmark suites or custom test programs compiled with known optimization settings, which limits their applicability to understanding realworld production scenarios. These studies are typically conducted in controlled settings and do not address prevalence in production apps, third-party root causes, or end-user perception. Remediation Techniques and Complementary Tools. Once optimization problems are detected, several techniques can remediate them. Profile-guided optimization (PGO) [37], post-link optimization with BOLT [34], and link-time optimization (LTO) [21] improve generated or linked binaries, while recent LLM-based compiler tools further expand automated remediation [7]. These approaches are complementary to OptDetect, which identifies low-optimization libraries and serves as a detection front-end for downstream remediation pipelines.
8
Conclusion
This paper presents a large-scale empirical study of compiler optimization problems in mobile applications. We reveal that 30.5% of 21,972 native libraries in top-ranked apps are compiled with low optimization levels, affecting 91.7% of apps. Our automated detection framework achieves 93.0% accuracy on controlled datasets and 81.9% on real-world binaries. Across 12 production apps, fixing detected issues achieves CPU instruction reductions of 10-63% (median: 20.5%) for commercial apps and 15-58% (median: 32%) for open-source apps, performancerelated complaint reductions of a median of 42%, and rating improvements of a median of 0.14 stars (for 5 out of 6 commercial apps). Root cause analysis reveals that the majority of optimization problems originate from third-party libraries, with our ecosystem investigation confirming that 49.7% of 1,073 libraries in a major repository exhibit low optimization levels. Future work includes extending detection to additional architectures and validating with end-to-end runtime energy measurements. In practice, OptDetect can serve as a CI/CD build gate
Source-Free Detection and Impact Analysis of Compiler Optimization Problems in Mobile Applications
and support pre-publication vetting in SDK repositories to prevent low-optimization libraries from entering production ecosystems.
Acknowledgments The authors used large language model (LLM)-based writing assistance tools to improve language clarity in portions of this paper. All technical content, analysis, and conclusions are solely the work of the authors.
9
Data Availability
Our artifact is available at: https://doi.org/10.5281/zenodo.19228823. It includes the OptDetect executable tool (opt-detector.exe), README tutorial, sample .so files, RQ2 analysis results (830 apps, 21,972 libraries), RQ3 third-party library repository analysis results, and analysis scripts. RQ1 uses the public Optimization-Detector [38] and Assemblage [26] datasets (not redistributed). Raw app binaries are excluded due to app store terms, and commercial app names are anonymized under confidentiality agreements. All optimization scores and statistical results are disclosed.
References [1] AppDynamics and University of London Institute of Management Studies, Goldsmiths. 2014. The App Attention Span Study. https://www.apmdigest.com/ nearly-90-percent-surveyed-stop-using-apps-due-to-poor-performance Nearly 90 percent surveyed stop using apps due to poor performance. [2] Abhijeet Banerjee, Lee Kee Chong, Sudipta Chattopadhyay, and Abhik Roychoudhury. 2014. Detecting energy bugs and hotspots in mobile apps. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (Hong Kong, China) (FSE 2014). Association for Computing Machinery, New York, NY, USA, 588–598. doi:10.1145/2635868.2635871 [3] Shaiful Alam Chowdhury and Abram Hindle. 2016. GreenOracle: estimating software energy consumption with energy measurement corpora. In Proceedings of the 13th International Conference on Mining Software Repositories (Austin, Texas) (MSR ’16). Association for Computing Machinery, New York, NY, USA, 49–60. doi:10.1145/2901739.2901763 [4] CleverTap. 2019. App Uninstalls: Why They Happen and How to Fix Them. https://clevertap.com/blog/app-uninstalls/ More than 1 in every 2 apps are uninstalled within 30 days of being downloaded. [5] Keith D Cooper and Linda Torczon. 2011. Engineering a Compiler (2nd ed.). Elsevier. Modern approach to compiler construction with emphasis on optimization techniques. [6] Luis Cruz and Rui Abreu. 2019. Catalog of energy patterns for mobile applications. Empirical Softw. Engg. 24, 4 (Aug. 2019), 2209–2235. doi:10.1007/s10664-01909682-0 [7] Chris Cummins, Volker Seeker, Dejan Grubisic, Mostafa Elhoushi, Youwei Liang, Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Kim Hazelwood, Gabriel Synnaeve, and Hugh Leather. 2023. Large Language Models for Compiler Optimization. arXiv preprint arXiv:2309.07062 (2023). [8] Zikan Dong, Yanjie Zhao, Tianming Liu, Chao Wang, Guosheng Xu, Guoai Xu, and Haoyu Wang. 2024. Same App, Different Behaviors: Uncovering Devicespecific Behaviors in Android Apps. arXiv preprint arXiv:2406.09807 (2024). https://arxiv.org/abs/2406.09807 [9] Yue Duan, Xuezixiang Li, Jinghan Wang, and Heng Yin. 2020. DeepBinDiff: Learning Program-Wide Code Representations for Binary Diffing. In Network and Distributed System Security Symposium (NDSS). https://www.ndss-symposium.org/ndss-paper/deepbindiff-learning-programwide-code-representations-for-binary-diffing/ [10] Guillaume Fieni, Daniel Romero Acero, Pierre Rust, and Romain Rouvoy. 2024. PowerAPI: A Python framework for building software-defined power meters. Journal of Open Source Software 9, 98 (2024), 6670. doi:10.21105/joss.06670 [11] Daniel Flores-Martin, Sergio Laso, and Juan Luis Herrera. 2024. Enhancing Smartphone Battery Life: A Deep Learning Model Based on User-Specific Application and Network Behavior. Electronics 13, 24 (2024). doi:10.3390/electronics13244897 [12] Free Software Foundation. 2024. GNU Compiler Collection. https://gcc.gnu.org/. [13] Google. 2024. Perfetto. https://perfetto.dev/. [14] Google. 2024. Systrace. https://developer.android.com/topic/performance/tracing. [15] Shuai Hao, Ding Li, William G. J. Halfond, and Ramesh Govindan. 2013. Estimating mobile application energy consumption using program analysis. In
ASE ’26, 2026,
2013 35th International Conference on Software Engineering (ICSE). 92–101. doi:10.1109/ICSE.2013.6606555 [16] Christian Herglotz and André Kaup. 2017. Video decoding energy estimation using processor events. In 2017 IEEE International Conference on Image Processing (ICIP). 2493–2497. doi:10.1109/ICIP.2017.8296731 [17] Abram Hindle. 2015. Green mining: a methodology of relating software change and configuration to power consumption. Empirical Softw. Engg. 20, 2 (April 2015), 374–409. doi:10.1007/s10664-013-9276-6 [18] Huawei. 2024. DevEco Studio. https://developer.harmonyos.com/en/develop/devecostudio/. [19] Ltd. Huawei Technologies Co. 2024. HarmonyOS: Next-Generation Distributed Operating System. https://developer.harmonyos.com/en/ Official documentation and developer resources for HarmonyOS distributed operating system. [20] Reyhaneh Jabbarvand and Sam Malek. 2017. µDroid: an energy-aware mutation testing framework for Android. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (Paderborn, Germany) (ESEC/FSE 2017). Association for Computing Machinery, New York, NY, USA, 208–219. doi:10. 1145/3106237.3106244 [21] Chris Lattner and Vikram Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In International Symposium on Code Generation and Optimization (CGO). IEEE, 75–86. [22] Ding Li, Shuai Hao, William G. J. Halfond, and Ramesh Govindan. 2013. Calculating source line level energy information for Android applications. In Proceedings of the 2013 International Symposium on Software Testing and Analysis (Lugano, Switzerland) (ISSTA 2013). Association for Computing Machinery, New York, NY, USA, 78–89. doi:10.1145/2483760.2483780 [23] Xueliang Li, Yuming Yang, Yepang Liu, John P. Gallagher, and Kaishun Wu. 2020. Detecting and Diagnosing Energy Issues for Mobile Applications. In Proceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 127–140. doi:10.1145/3395363.3397350 [24] Dianshu Liao, Shidong Pan, Siyuan Yang, Yanjie Zhao, Zhenchang Xing, and Xiaoyu Sun. 2024. A Comparative Study of Android Performance Issues in Real-world Applications and Literature. arXiv preprint arXiv:2407.05090 (2024). [25] Mario Linares-Vásquez, Gabriele Bavota, Carlos Bernal-Cárdenas, Rocco Oliveto, Massimiliano Di Penta, and Denys Poshyvanyk. 2014. Mining energy-greedy API usage patterns in Android apps: an empirical study. In Proceedings of the 11th Working Conference on Mining Software Repositories (Hyderabad, India) (MSR 2014). Association for Computing Machinery, New York, NY, USA, 2–11. doi:10.1145/2597073.2597085 [26] Chang Liu, Rebecca Saul, Yihao Sun, Edward Raff, Maya Fuchs, Townsend Southard Pantano, James Holt, and Kristopher Micinski. 2024. Assemblage: Automatic binary dataset construction for machine learning. Advances in Neural Information Processing Systems 37 (2024), 58698–58715. [27] Gai Liu, Umar Farooq, Chengyan Zhao, Xia Liu, and Nian Sun. 2023. Linker Code Size Optimization for Native Mobile Applications. In Proceedings of the 32nd ACM SIGPLAN International Conference on Compiler Construction (CC). 1–12. doi:10.1145/3578360.3580256 [28] Irene Manotas, Lori Pollock, and James Clause. 2014. SEEDS: a software engineer’s energy-optimization decision support framework. In Proceedings of the 36th International Conference on Software Engineering (Hyderabad, India) (ICSE 2014). Association for Computing Machinery, New York, NY, USA, 503–514. doi:10. 1145/2568225.2568297 [29] Andrea Mcintosh, Safwat Hassan, and Abram Hindle. 2019. What can Android mobile app developers do about the energy consumption of machine learning? Empirical Softw. Engg. 24, 2 (April 2019), 562–601. doi:10.1007/s10664-018-9629-2 [30] Paschalis Mpeis, Pavlos Petoumenos, Kim Hazelwood, and Hugh Leather. 2021. Developer and User-Transparent Compiler Optimization for Interactive Applications. In Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation (PLDI). 268–281. doi:10.1145/3453483.3454043 [31] Steven S Muchnick. 1997. Advanced Compiler Design and Implementation. Morgan Kaufmann. Comprehensive reference on compiler optimization techniques and implementation strategies. [32] Kris Nikov, Kyriakos Georgiou, Zbigniew Chamski, Kerstin Eder, and Jose NunezYanez. 2022. Accurate Energy Modelling on the Cortex-M0 Processor for Profiling and Static Analysis. In 2022 29th IEEE International Conference on Electronics, Circuits and Systems (ICECS). 1–4. doi:10.1109/ICECS202256217.2022.9971086 [33] Fabio Palomba, Dario Di Nucci, Annibale Panichella, Andy Zaidman, and Andrea De Lucia. 2019. On the impact of code smells on the energy consumption of mobile applications. Information and Software Technology 105 (2019), 43–55. doi:10.1016/j.infsof.2018.08.004 [34] Maksim Panchenko, Rafael Auler, Bill Nell, and Guilherme Ottoni. 2019. BOLT: A Practical Binary Optimizer for Data Centers and Beyond. In Proceedings of the IEEE/ACM International Symposium on Code Generation and Optimization (CGO). 100–116. [35] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, et al. 2019. PyTorch: An imperative style, high-performance deep learning library. In
ASE ’26, 2026,
Advances in neural information processing systems. 8026–8037. [36] Abhinav Pathak, Abhilash Jindal, Y. Charlie Hu, and Samuel P. Midkiff. 2012. What is keeping my phone awake? characterizing and detecting no-sleep energy bugs in smartphone apps. In Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services (Low Wood Bay, Lake District, UK) (MobiSys ’12). Association for Computing Machinery, New York, NY, USA, 267–280. doi:10.1145/2307636.2307661 [37] Karl Pettis and Robert C Hansen. 1990. Profile guided code positioning. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). ACM, 16–27. [38] Davide Pizzolotto and Katsuro Inoue. 2021. Identifying Compiler and Optimization Level in Binary Code From Multiple Architectures. IEEE Access 9 (2021), 163461–163475. doi:10.1109/ACCESS.2021.3132950 [39] LLVM Project. 2024. Clang: a C language family frontend for LLVM. https://clang.llvm.org/. [40] Quarkslab. [n. d.]. LIEF - Library to Instrument Executable Formats. https: //lief.quarkslab.com/. Accessed: 2026-01-28. [41] Nguyen Anh Quynh. 2014. Capstone: Next-Gen Disassembly Framework. In Black Hat USA. https://www.capstone-engine.org/. [42] Xiaolei Ren, Michael Ho, Jiang Ming, Yu Lei, and Li Li. 2021. Unleashing the Hidden Power of Compiler Optimization on Binary Code Difference: An Empirical Study. In Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation (PLDI). ACM, 142–157. [43] Statista. 2024. Number of smartphone users worldwide from 2016 to 2025. https://www.statista.com/statistics/330695/number-of-smartphone-users-
Hu et al.
worldwide/. Accessed 2025-07-19. [44] Ting Su, Jue Wang, and Zhendong Su. 2021. Benchmarking Automated GUI Testing for Android against Real-World Bugs. In Proceedings of the 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 1552–1564. doi:10.1145/3468264.3468620 [45] Yutian Tang, Haoyu Wang, Xian Zhan, Xiapu Luo, Yajin Zhou, Hao Zhou, Qiben Yan, Yulei Sui, and Jacky Keung. 2022. A Systematical Study on Application Performance Management Libraries for Apps. IEEE Trans. Softw. Eng. 48, 8 (Aug. 2022), 3044–3065. doi:10.1109/TSE.2021.3077654 [46] Mian Wan, Yuchen Jin, Ding Li, and William G. J. Halfond. 2015. Detecting Display Energy Hotspots in Android Apps. In 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST). 1–10. doi:10.1109/ICST.2015. 7102585 [47] Paweł Weichbroth. 2025. Usability Issues With Mobile Applications: Insights From Practitioners and Future Research Directions. arXiv preprint arXiv:2502.05120 (2025). [48] Shouguo Yang, Zhiqiang Shi, Guodong Zhang, Mingxuan Li, Yuan Ma, and Limin Sun. 2019. Understand Code Style: Efficient CNN-Based Compiler Optimization Recognition System. In IEEE International Conference on Communications (ICC). IEEE, 1–6. doi:10.1109/ICC.2019.8761073 [49] Shengqian Yang, Dacong Yan, Haowei Wu, Yan Wang, and Atanas Rountev. 2015. Static control-flow analysis of user-driven callbacks in Android applications. In Proceedings of the 37th International Conference on Software Engineering - Volume 1 (Florence, Italy) (ICSE ’15). IEEE Press, 89–99.