Overview of Jank and Frame Drops in Android - Methodology

Word count: 904Reading time: 5 min

 2019/09/05

Jank issues in Android are taken very seriously by both smartphone manufacturers and app developers. Internal teams, often called “Performance” or “Stability” groups, are typically dedicated to optimizing these experiences.

Currently, excellent third-party performance monitoring tools like Tencent’s Matrix are available. Phone manufacturers also have proprietary solutions. Since they can modify source code and bypass certain permission hurdles, manufacturers can access deeper system data, making analysis more efficient.

When we talk about smoothness, we are essentially talking about frame drops during operation. If a screen needs to refresh at 60 frames per second (FPS) but only manages 55, the user perceives this as a “jank” or “stutter.” Sudden fluctuations in frame rate are particularly noticeable. Reasons for frame drops range from hardware and system software issues to inefficiencies within the app itself.

This series is divided into four articles to explore these causes:

1. Overview of Smoothness Work

As a member of a manufacturer’s optimization group, I should briefly describe our workflow. Many factors can cause jank in Android, but testing and users experience it most directly as dropped frames in the foreground app. Since they often can’t pinpoint the root cause, they report it to us as a general bug. We act as “jank interfaces,” analyzing the cause and assigning the bug to the relevant team: Framework, App, Multimedia, Display, BSP, etc.

We rarely solve the technical bug ourselves. Instead, we use specialized tools combined with source code to locate issues. Our primary tools include:

Systrace/strace/ftrace: For a global system-level overview.
MethodTrace: For a detailed view of per-process function call stacks.
Android Studio Profiler.
MAT: For analyzing memory issues.
Logs: Comprehensive log reports including Main, System, Event, Kernel, and Crash logs, as well as proprietary Power/Performance logs and incident recordings (screenshots/videos).
Reproduction Videos.
Local Reproductions.

Identifying the root cause requires proficiency in App development, Android Framework, Display systems, and Linux Kernel, along with mastery of the corresponding tools and scenarios.

2. Analysis Tools and Workflows

When data hooks are incomplete, we rely heavily on Systrace for a global perspective:

Systrace Analysis
- Identify the target App.
- Use the App Main Thread and SurfaceFlinger Main Thread info to locate the “scene of the jank.”
- Deep dive into Systrace. This requires knowing how Systrace modules correspond to user-perceived lag, understanding inter-module interaction, Binder calls, and Kernel info (see the Systrace Series).
- If the App Main Thread is heavy, analyze the app logic.
- If it’s a System issue, analyze system_server, SurfaceFlinger, HWC, CRTC, CPU, etc.
MethodTrace + Source Code
- After identifying the cause with Systrace, use MethodTrace to see per-process function stacks and map them back to the code.
- Use Android Studio for breakpoint debugging in App or Framework code to verify if behavior matches expectations.
Log Analysis
- Even if logs don’t directly show the “jank,” they are crucial for system context:
- Screenshots to confirm timing and UI state.
- dumpsys meminfo and dumpsys cpuinfo.
- “Slow dispatch” and “Slow delivery” Looper warnings.
- EventLog to reconstruct user operations leading to the event.
Local Reproduction
- High-speed video recording to observe fine details.
- Filtering logs for anomalies.
- Capturing multiple Systraces to confirm consistency.
System-wide State Check
- adb shell dumpsys activity oom
- adb shell dumpsys meminfo
- adb shell cat /proc/buddyinfo (Memory fragmentation)
- adb shell dumpsys cpuinfo
- adb shell dumpsys input
- adb shell dumpsys window

3. Data-Driven Analysis

Due to the unreliability of user reports and the limits of internal testing, system/app performance hooks are vital. They allow for large-scale trend analysis without active user participation.

Most major Chinese phone and app manufacturers have their own APM (Application Performance Management) platforms. For example, Tencent’s Matrix monitors various metrics that other app developers can integrate.

Manufacturers, with their source code access, collect even deeper data: CPU load, I/O load, Memory pressure, FSync times, Exception monitoring, Thermal monitoring, and Storage health. Each category might have dozens of sub-metrics. Analyzing this high-dimensional data requires experienced teams to define metrics and derive actionable insights.

The subsequent optimization work tests a company’s R&D strength. High-tier manufacturers optimize at the hardware-software boundary (resource allocation), while others focus on scenario-based resource policies.

4. Summary

This has been a high-level overview of analysis methodologies for smoothness issues, primarily from a Framework/App perspective. Kernel teams likely have a different, deeper vantage point.

Android phone manufacturers can be categorized by their technical depth:

Apple: Inhouse chips, OS, and ecosystem. They have the tightest control from hardware to app layers.
Samsung & Huawei: Inhouse chips/core components but sharing the Android OS/ecosystem. They can perform Chip-to-OS integration.
Other Top Android OEMs: Rely on different SoCs (Qualcomm, MediaTek). Their optimizations are often software-policy-based since they don’t always control the deepest chip layers.

This is just the first part of our smoothness series. Stay tuned for more.