iQIYI Mobile App Performance Optimization: Package Size, Startup Speed, Stability, and Toolchain Evolution

Introduction – Mobile applications are judged heavily on launch time. As iQIYI’s ecosystem grew, the engineering team continuously refined the app to keep the launch experience "instant" while adding more content.

The team collected performance and quality metrics across many iQIYI‑branded apps and built a toolbox to share optimization experience.

Optimization dimensions

Package size

Startup speed

Stability

Other dimensions

1. Package Size

iOS imposes a 60 MB limit on the __TEXT segment (iOS 8) and apps larger than 200 MB must be downloaded over Wi‑Fi. Binary size also directly affects launch time, and users often notice the app size on devices with limited storage.

Package‑size reduction consists of two major parts: resource size optimization and binary size optimization.

Resource size optimization

Resource compression – Xcode’s built‑in PNG compression (Compress PNG Files, Remove Text MetaData) is lossless and leaves images large.

Deletion of unused or duplicate resources – as features are deprecated, their assets linger; duplicate UI assets from different teams also accumulate.

Uploading resources to the cloud – lazy‑load assets from a CDN, reducing the bundle size and enabling dynamic skinning.

For PNG compression the team adopted pngquant to convert 32‑bit PNGs to 8‑bit where color depth loss is acceptable, then applied Zopfli for further compression, achieving roughly a 70 % size reduction. Care is taken with gradient backgrounds where color loss would be noticeable.

Binary size optimization

The team uses Xcode’s Link Map to compare referenced classes/methods (__objc_classrefs, __objc_selrefs) against the full binary, identifying unused classes and methods. Because Objective‑C’s dynamic nature generates many false positives, they cross‑check with code‑coverage data (gcno/gcda files parsed by lcov) to confirm truly dead code before removal.

2. Startup Speed

Launch time is the first user‑visible performance metric. iOS distinguishes cold launch (app not in memory) from hot launch (already resident). The focus is on cold‑start optimization.

Launch can be split into two phases: before main and after main . Both contain optimization opportunities.

Dylib loading time – System libraries are often pre‑loaded, but embedded frameworks require file verification, signature registration, and mmap of each segment. Merging multiple frameworks into a single binary reduces this overhead.

iQIYI originally used embedded frameworks to bypass the 60 MB __TEXT limit, but later switched back to static libraries because static linking reduced overall rebase/binding time.

Rebase/Binding & ObjC setup time – Since iOS 4.3, ASLR forces the loader to rebase pointers. Reducing the number of Objective‑C classes, methods, and C++ virtual functions cuts this cost.

Initializer time – The +load method of each class/category is invoked before main . Overuse of +load (up to 900 calls) caused significant delay. The team migrated logic to +initialize and introduced a swizzling‑based tool to record +load counts, durations, and originating libraries.

didFinishLaunchingWithOptions – After the UI is created, the goal is to generate the main view quickly, off‑load non‑essential work to background threads, and replace XIB/Storyboard with programmatic UI where possible. Since >80 % of launches display a splash‑screen ad, the team pre‑downloads ad assets, decodes them to bitmaps, and defers unrelated work.

3. Stability

Stability improvements target crash reduction through Category analysis, method‑swizzling checks, and static analysis.

Category analysis – Categories can cause name collisions either between business modules or with system/private APIs. Collisions increase binary size (duplicate code) and can cause runtime crashes. The team prefixes Category names and runs a tool that extracts all Category methods, compares them with public and private iOS APIs (the latter obtained via class‑dump), and flags duplicates.

Method swizzling analysis – Swizzling is useful but can break system behavior, e.g., when NSArray’s internal implementation changes for large collections. The team scans for method_exchangeImplementations usage, extracts the object files, and manually reviews each swizzled method before merging.

Static analysis – Xcode’s Analyze and Facebook’s Infer are used to detect unremoved observers, missing weak delegate references, and other unsafe patterns.

4. Other Dimensions

Private API detection – Use of private APIs or methods with identical names can cause App Store rejection. The team cross‑references extracted app symbols with a database of private iOS APIs, assigns severity levels, and maintains a whitelist for tolerated cases.

File I/O & decompression – Frequent read/write or unzip operations that coincide with user interactions (e.g., scrolling, video start) can drop frame rates. The toolbox logs the timing, thread, and user‑action context of such operations to decide whether to postpone them.

5. Toolbox Architecture Evolution

The toolbox started as a collection of ad‑hoc scripts (“Stone Age”). Later, scripts were grouped by analysis dimension, integrated into Jenkins for scheduled execution (“Industrial Age”). Finally, a front‑end dashboard with charts, alert emails, and automatic task assignment was added, turning the system into an “Automation Age”.

Conclusion

iQIYI’s app now integrates many business lines (e.g., 奇秀, 漫画, 票务) while keeping the install package under 200 MB, achieving “second‑open” launch times, >55 fps page transitions, and a crash rate below 0.2 %. Continuous performance and stability engineering, supported by the described toolbox, is the key to delivering a high‑quality video experience.