How Kuaishou Optimizes Android TTI: From Definition to Real‑Time Monitoring

Background

This article introduces the concept of Time To Interactive (TTI) for Kuaishou’s main Android client, explains why cold‑start lag occurs, and aims to provide reference solutions for handling post‑cold‑start jank.

Definition of TTI

TTI is the interval from the first frame displayed after cold start to the moment the app becomes smoothly usable. The article discusses the difficulty of quantifying TTI, the decision to ignore user interaction and use visual smoothness (frame‑time) as the criterion, and the final metric definition:

TTI Start Time – timestamp of the first frame on the home page.

TTI End Time – timestamp of the first frame where 400 consecutive frames each have a frame‑time < 83 ms.

TTI = End − Start.

Why FPS Is Not Sufficient

Two major defects of FPS are highlighted: it cannot reflect real jank and its measurement granularity is only 1 s, which hides short‑duration stalls.

Examples show that two scenarios with the same average FPS (50) can feel completely different because one contains a 200 ms stall.

FrameTime as the Replacement Metric

FrameTime (the time between two rendered frames) better captures perceived smoothness. The article adopts FrameTime‑based monitoring to replace FPS in the TTI calculation.

Information‑Collection Scheme

Offline : Systrace instrumentation, AspectJ byte‑code injection, and manual trace points for critical paths such as EventBus or RxJava.

Online : Feature flags to enable FrameTime monitoring, automatic stack capture when FrameTime exceeds the 83 ms threshold, and aggregation of long‑task MD5 hashes for server‑side analysis.

TTI Performance Lab

A daily scheduled job runs at 00:00 and 12:00 to detect commits that degrade TTI, reports alarms, and uses flame‑graphs to locate the responsible functions. The lab also filters out feed‑type content and splash ads to reduce noise.

Governance Measures

Identified sources of main‑thread work include postponed startup tasks, EventBus/RxJava callbacks, layout & scroll handling, player logic, and other business code. The proposed two‑step solution is to build a task‑scheduling framework and then migrate tasks into it.

TTI Scheduling Framework

Tasks are classified as high‑priority/low‑priority and high‑cost/low‑cost, placed into separate queues, and dispatched during idle periods. High‑cost tasks are only executed after the TTI phase ends. Work‑thread tasks are handled by a HandlerThread with a delay based on the average online task cost.

Data Reporting

Three reporting streams are defined: (1) internal task‑scheduling metrics, (2) calculated TTI values, and (3) long‑task identifiers with stack traces. All data are uploaded to the backend for dashboards and root‑cause analysis.

Long‑ and Short‑Task Governance

Long tasks (> 83 ms) are mitigated by async, coroutine, or task‑splitting techniques. Short tasks can cause jank when many accumulate; they are handled by asynchronous insertion or framework‑driven scheduling.

Basic Library / API Optimisation

Massive calls to common libraries or APIs are profiled and optimised to reduce cumulative cost.

Up/Down‑Scroll Framework

Because scroll actions are frequent and tightly linked to TTI, a dedicated framework isolates and optimises scroll‑related work.

Summary & Outlook

The article outlines future work: improving the robustness and intelligence of the TTI framework, strengthening review and degradation‑prevention mechanisms, optimising scroll and player tasks, and expanding online long‑task extraction cases.

Related Links

https://perfdog.qq.com/article_detail?id=10162&issue_id=0&plat_id=1