Optimizing First-Page Rendering Performance in the Hello Travel iOS App

Background: Hello Travel (哈啰出行) covers many business scenarios. The app’s home page is the first screen users see, and its first‑screen rendering speed is crucial for overall user experience.

Definition of first‑screen rendering time: the interval from the moment a user taps the app icon to the moment the home page’s first screen is fully rendered and visible.

Optimization phases: rapid product iteration has accumulated technical debt. The performance impact is divided into three stages – startup/pre‑task items, home‑page framework and business logic, and module load performance.

Optimization path: (1) data collection, (2) problem analysis, (3) targeted solutions, (4) continuous monitoring and visualization.

Data collection focuses on the full launch chain, including process initialization, pre‑task execution, and home‑page load. Example code used to obtain the process start time is shown below:

+ (BOOL)processInfoForPID:(int)pid procInfo:(struct kinfo_proc *)procInfo {
int cmd[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
size_t size = sizeof(*procInfo);
return sysctl(cmd, sizeof(cmd)/sizeof(*cmd), procInfo, &size, NULL, 0) == 0;
}
+ (NSTimeInterval)processStartTime {
struct kinfo_proc kProcInfo;
if ([self processInfoForPID:[[NSProcessInfo processInfo] processIdentifier] procInfo:&kProcInfo]) {
return kProcInfo.kp_proc.p_un.__p_starttime.tv_sec * 1000.0 + kProcInfo.kp_proc.p_un.__p_starttime.tv_usec / 1000.0;
} else {
return 0;
}
}

Startup task timing is collected via the internal CocoaService framework, which registers tasks in four phases: AppInitialize, CoreModuleMountedAfter, InstantModulesMountedAfter, and AppLaunchedAfter. A task‑loading sequence diagram is provided in the original document.

Module load time is split into two phases – data loading and UI rendering. The analysis shows that many modules consume significant main‑thread time, especially during the UI rendering stage.

Problem analysis uses Xcode Instruments’ Time Profiler. The profiler samples at 1 ms intervals, which is coarse‑grained; high‑frequency sampling and kernel call‑stack recording are suggested for more accurate measurements. The analysis revealed CPU saturation during startup and home‑page loading, with over 69 startup tasks and more than 30 threads competing for resources.

Key optimizations applied:

Startup‑task optimization: performance profiling, establishing a standardized task‑management process, scheduling tasks in stages, and adding APM‑based monitoring.

Lottie framework improvements: added a second‑level (disk) cache inspired by SDWebImage, handled large key‑frame assets on background queues, and mitigated crashes caused by malformed JSON layers.

Image resource loading: introduced a two‑level cache (memory + disk) to avoid gray placeholders during cold starts and to keep rendering within a single run‑loop.

Runtime +load misuse reduction: limited heavy logic in +load , avoided improper method swizzling, and minimized runtime hooks that block the main thread.

First‑frame rendering definition: aligned the rendering endpoint with viewDidAppear and Apple’s MetricsKit definition (first CA::Transaction::commit() ).

Optimization results: before optimization, first‑screen rendering exceeded 1 s for all users; after optimization, 90 % of users experience rendering under 1 s, with many under 0.5 s – a 40 % performance improvement. Animated GIF comparisons illustrate the visual difference.

Future plans include full‑chain monitoring, cloud‑native containerization of the home page, and continued performance enhancements. The team is recruiting; interested engineers can contact [email protected].