Beike iOS App Startup Optimization: Measurement, Analysis, and Governance Practices

Introduction: Startup speed is a core performance metric affecting user experience, acquisition, retention, and conversion. The article presents Beike's iOS startup optimization work, covering online startup speed measurement, offline performance analysis, and startup speed governance practices.

Online Startup Speed Measurement: Two schemes exist—official (MetricKit) and self‑researched. Beike adopts a self‑researched phased collection approach. MetricKit (iOS13+) defines startup from process creation to first frame after launch screen dismissal, splitting into System Interface, Runtime Init, UIKit Init, Application Init, First Frame Render, and Extended phases.

Self‑researched Phased Collection: Startup divided into T1 (fork to main, corresponding to System Interface + Runtime Init), T2 (main to application:didFinishLaunchingWithOptions end, corresponding to UIKit Init + Application Init), and T3 (didFinishLaunchingWithOptions end to homepage viewDidAppear). T1 uses sysctl to get process creation timestamp; T2/T3 rely on method swizzling to capture key timestamps with minimal intrusion, validated via online A/B testing.

Offline Startup Performance Analysis: Instruments’ Time Profiler and System Trace (or the combined App Launch tool in Xcode 11+) are used, but suffer from slow startup and lack of temporal order. Beike built BKTimeProfiler, an in‑app performance analysis tool covering T1‑T3, counting +load/static initializer numbers and time, recording function execution order, time, call count, stack traces, and highlighting functions exceeding time or percentage thresholds, plus logging all HTTPS requests during startup.

BKTimeProfiler Features: Zero‑cost, non‑intrusive integration; detects 80%+ of startup time issues; highly extensible for automated test data collection and anti‑degradation monitoring.

Key Technical Details of BKTimeProfiler: (1) Dynamic detection of +load via a custom dylib with constructor hooking and Mach‑O section scanning (__objc_nlclslist, __objc_nlcatlis). (2) Hooking objc_msgSend with fishhook to record call info, timestamps, and stack depth, then reconstructing stacks that meet depth and time thresholds. (3) Dependency injection using weak/strong symbols (e.g., default view controller name, stack depth, thresholds) combined with method swizzling to allow business‑side overrides without linking the tool.

Unified Offline Test Environment: Use release builds on real devices matching the online 50th‑percentile startup latency; ensure normal temperature, battery, and logged out of iCloud. Test conditions: kill process, wait 2‑3 min, relaunch (T2/T3); or full cold start: power‑off device, wait 2‑3 min, power on, launch app. BKTimeProfiler can be used to view real‑time function‑stack timing.

Startup Speed Governance Practices: Beike’s app aggregates multiple businesses; optimization prioritizes issues by impact and team capacity. Main T2/T3 bottlenecks include local/network image loading, synchronous file I/O, large data serialization/deserialization, and slow APIs.

Governance of +load Methods: Reduce unnecessary +load work (lazy load/defer) using section() to place data in __DATA segment; control new +load via a black‑white list enforced in CI by grepping LinkMap for +load symbols and comparing to the whitelist, promoting necessary additions or blacklisting others.

Reducing Useless Code: Although Xcode’s Dead Code Stripping removes unused C/C++ code, Objective‑C runtime requires deep cleanup. Work split into Pod governance (using poddotify to find unused pods, merge duplicate functionality), zero‑PV page cleanup (using LinkMap and PV data to delete never‑viewed pages), and unused class removal (Mach‑O __objc_classlist minus refs, verified via LinkMap before deletion).

Startup Item Optimization: Startup items (exception monitoring, analytics, network init, router, business modules) are ordered by business priority (high‑priority sync, low‑priority async/deferred) and internal latency is treated by eliminating synchronous I/O, large data serialization, and blocking async callbacks, plus optimizing low‑level APIs like dladdr() and CNCopySupportedInterfaces().

Performance Improvements: Splash‑screen image loading optimized by synchronous file read (small cost) followed by GPU decoding to avoid CPU image decode; local image loading improved via pre‑fetching UIImage imageNamed: batches and caching theme‑based default images drawn with CPU to reduce repeated drawing. Other optimizations: async file I/O and data serialization, deduplicating/network request splitting, and mitigating heavy dladdr() calls via caching in base libraries.

Binary Reordering: Based on locality, collect startup function call traces via SanitizerCoverage (__sanitizer_cov_trace_pc_guard) to generate an order file, then apply via Xcode’s Link‑>Order File setting. Effective on low‑end devices and iOS 13 (where TEXT‑page decryption cost removed) and benefits from larger 16 KB pages on iPhone 6s+.

Summary: Startup optimization pursues global optimum, not isolated speed gains; it synergizes with app size reduction, page load performance, and feature availability. The cultivated performance tools (e.g., BKTimeProfiler) also aid page‑load analysis and code‑size work. Collaboration with product/marketing teams ensures external link handling, advertisement splash, banner, and feed improvements boost new‑user conversion and lower marketing cost, while performance gains support rapid business iteration and growth.