Understanding and Optimizing Time To Interactive (TTI) on the Kuaishou Android App

Background – After a cold start, Kuaishou experiences a noticeable freeze before the UI becomes smooth. This is not a bug but a known issue caused by high CPU load and tasks concentrated at the "cold‑start‑completed" moment, which led to the introduction of the TTI metric.

Definition of TTI – TTI (Time To Interactive) is the duration from the first frame displayed after cold start to the point where the app feels fluid to the user. Because user interaction timing is hard to define for short‑video apps, Kuaishou simplifies the definition: once the UI reaches a predefined visual smoothness without obvious stutter, it is considered interactive.

Why FPS is insufficient – FPS cannot reflect real stalls: two scenarios with the same average FPS (50) can feel completely different if one contains a single long‑lasting frame. FPS also has a coarse 1‑second granularity, making it unsuitable for precise TTI measurement.

Adopting FrameTime – FrameTime measures the time between consecutive frame renders. Kuaishou uses FrameTime to define TTI: TTI Start = timestamp of first frame , TTI End = timestamp of the first frame in a continuous 400‑frame window where each frame takes less than 83 ms , and TTI = End – Start . The 83 ms threshold follows industry guidance (e.g., PerfDog).

Information‑collection scheme – Data is gathered via Systrace instrumentation (framework hooks) and manual AspectJ insertion for app‑level code. Offline collection uses Systrace dumps; online collection relies on a custom Chronos flame‑graph service and real‑time FrameTime charts built with Xposed/Frida hooks.

Performance Lab – A daily automated job runs on each version, captures TTI and stack traces, and alerts when TTI degrades beyond a threshold. It also records long‑duration tasks, aggregates them, and provides dashboards for root‑cause analysis.

Governance measures – Tasks are classified into four priority groups (high‑priority‑low‑cost, high‑priority‑high‑cost, low‑priority‑low‑cost, low‑priority‑high‑cost) and scheduled during idle time or after TTI ends. Work‑thread tasks are dispatched via a HandlerThread with intervals derived from observed average FrameTime.

Data reporting – Three reporting streams are used: (1) task‑scheduling metrics (count, latency, cost), (2) TTI results per run, and (3) long‑task (≥ 83 ms) identifiers with stack traces. This enables precise attribution of performance regressions.

Handling long vs. short tasks – Long tasks (> 83 ms) are mitigated through async execution, coroutines, or splitting. Short tasks, when densely queued, can also cause stutter; they are addressed by asynchronous insertion and better scheduling.

Library/API and scroll‑framework optimization – High‑frequency library calls and scroll‑related work are singled out for optimization because they heavily impact TTI.

Summary and outlook – Future work includes strengthening the TTI scheduling framework, improving review and degradation‑prevention mechanisms, optimizing scroll and player pipelines, and expanding online long‑task extraction to enhance root‑cause analysis.

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