Android Performance

Android Perfetto Series 10: Binder Scheduling and Lock Contention

2025-11-16T07:33:30.000Z

The tenth article in the Perfetto series focuses on Binder, Android’s core Inter-Process Communication (IPC) mechanism. Binder carries most interactions between system services and apps, and is often where latency and jank originate. This article uses signals from linux.ftrace (binder tracepoints + sched), thread_state, and ART Java monitor contention (via atrace dalvik) to provide a practical workflow for diagnosing transaction latency, thread-pool pressure, and lock contention.

Perfetto Series Catalog
Binder Basics
Perfetto Setup and Data Sources
- Other Binder Analysis Tools
Binder Analysis Workflow
Case Studies
- Case 1: Window Management Delay
- Case 2: Binder Thread Pool Saturation
Platform Features and Best Practices
Summary
References
Attachments
About the Author & Blog

Perfetto Series Catalog

Binder Basics

For readers encountering Binder for the first time, understanding its role and participants is crucial. You can roughly understand Binder as “cross-process function calls”: you write code in one process that looks like calling a local interface, while Binder handles the actual call and data transfer. Overall, it is Android’s primary Inter-Process Communication (IPC) mechanism, consisting of four core components:

Client: Application threads initiate calls through IBinder.transact(), writing Parcel-serialized data to the kernel.
Service (Server): Usually runs in SystemServer or other processes, reading Parcel and executing business logic through Binder.onTransact().
Binder Driver: The kernel module /dev/binder responsible for thread pool scheduling, buffer management, priority inheritance, etc., serving as the “messenger” connecting both parties.
Thread Pool: The server typically maintains a set of Binder threads. Note that the thread pool is not created full from the start, but is created on demand. The Java layer defaults to approximately 15 Binder worker threads (excluding the main thread), and the Native layer can also configure the maximum thread count via ProcessState (default value is usually also 15). When all Binder threads are busy, new requests will queue in the driver layer waiting for idle threads.

Why is Binder needed?

Android adopts a multi-process architecture to isolate applications, improve security, and stability. Each APK runs in an independent user space. When it needs to access system capabilities (camera, location, notifications, etc.), it must cross-process call the Framework or SystemServer.

Limitations of traditional IPC solutions:

IPC Method	Problem
Socket	High overhead, lacks identity verification
Pipe	Only supports parent-child processes, one-way communication
Shared Memory	Needs additional synchronization mechanisms, lacks access control

Binder solves these problems at the kernel layer, providing three key capabilities: first, identity and permission (based on UID/PID verification to ensure the caller is legitimate); second, synchronous and asynchronous calls (in synchronous mode, the Client waits for the Server to return, which is the most common mode, while in asynchronous mode, the Client returns immediately after sending, suitable for scenarios like notifications and status reporting); third, priority inheritance (when a high-priority Client calls a low-priority Server, the Server temporarily elevates its priority to avoid priority inversion problems).

Therefore, when an app process calls IActivityManager#attachApplication() during startup, Binder is the channel that safely and reliably delivers that request to system_server.

Case from App Developer’s Perspective

Suppose the trace contains AIDL::java::IActivityManager::attachApplication::server. This corresponds to a synchronous Binder call to IActivityManager#attachApplication(...), handled by ActivityManagerService in system_server. The path is: on the Proxy side, app code gets IActivityManager via ActivityManager.getService(); the proxy serializes arguments into a Parcel and calls transact(); the Binder driver queues the transaction and wakes an idle system_server Binder thread (for example Binder:1460_5); on the Stub side, ActivityManagerService processes attachApplication; finally, the reply is marshaled back and the app thread resumes from waitForResponse().

In Perfetto, this appears as one transaction on Android Binder / Transactions (if AIDL info is decoded, the slice name is often AIDL::java::IActivityManager::attachApplication::client/server, or SQL shows aidl_name=IActivityManager, method_name=attachApplication); the app thread stays in S (Sleeping) with blocked_function often at binder_thread_read / epoll_wait / ioctl(BINDER_WRITE_READ); a system_server Binder thread runs; and Flow arrows connect client and server work.

Perfetto Setup and Data Sources

To diagnose Binder in Perfetto, you need to prepare the data sources and Trace configuration in advance.

Data Sources and Track Overview

Binder analysis needs to connect transaction events with scheduling, blocking, and lock signals. In practice, recording is mainly based on linux.ftrace (binder tracepoints + sched + optional atrace categories), plus lightweight process/thread metadata.

linux.ftrace (kernel + atrace) is the baseline and works across Android versions. It captures kernel events like binder_transaction (transaction start), binder_transaction_received (server receives transaction), and binder_transaction_alloc_buf (buffer allocation, useful for TransactionTooLarge diagnostics). Combined with sched_switch / sched_waking, it reconstructs the full chain: client call → server wakeup → server handling → reply.
You can also enable atrace categories inside linux.ftrace: binder_driver / am / wm for framework context, and dalvik for ART monitor contention (synchronized lock waits), which powers Thread / Lock contention tracks in UI.

linux.process_stats (metadata) maps PID/TID to process/thread names for easier filtering in UI/SQL, with negligible overhead.

Note: Perfetto UI tracks such as Android Binder / Transactions, Android Binder / Oneway Calls, and SQL stdlib modules like android.binder / android.monitor_contention are parser-side derived views over raw trace events; they are not separate recording data sources.

Recommended Trace Config

The following configuration balances compatibility with new features and is recommended as a standard Binder analysis template. Save the configuration as binder_config.pbtx for use:

# ============================================================
# Perfetto configuration dedicated to Binder analysis
# Applicable scope: Android 10+ (Android 12+ is generally easier operationally)
# ============================================================

# --- Buffer and duration settings ---
buffers {
  size_kb: 65536          # 64MB buffer, suitable for medium complexity scenarios
  fill_policy: RING_BUFFER
}
duration_ms: 15000        # 15 second capture duration, adjustable as needed

# --- Data source 1: linux.ftrace (kernel + atrace) ---
# Baseline source: Binder tracepoints + sched events + optional atrace categories
data_sources {
  config {
    name: "linux.ftrace"
    ftrace_config {
      # Binder core events
      ftrace_events: "binder/binder_transaction"           # Transaction start
      ftrace_events: "binder/binder_transaction_received"  # Server received transaction
      ftrace_events: "binder/binder_transaction_alloc_buf" # Buffer allocation (diagnose TransactionTooLarge)
      ftrace_events: "binder/binder_set_priority"          # Priority inheritance
      ftrace_events: "binder/binder_lock"                  # Kernel lock (usually can be omitted)
      ftrace_events: "binder/binder_locked"
      ftrace_events: "binder/binder_unlock"

      # Scheduling events (connect Client/Server threads)
      ftrace_events: "sched/sched_switch"
      ftrace_events: "sched/sched_waking"
      ftrace_events: "sched/sched_wakeup"
      ftrace_events: "sched/sched_blocked_reason"          # Blocking reason

      # Optional: Application layer trace points (need atrace)
      atrace_categories: "binder_driver"   # Binder driver layer
      atrace_categories: "sched"           # Scheduling
      atrace_categories: "am"              # ActivityManager
      atrace_categories: "wm"              # WindowManager
      atrace_categories: "dalvik"          # Java Monitor Contention
      # atrace_categories: "view"          # Enable if analyzing UI

      # To capture app-side atrace slices (e.g. doFrame / custom trace), you can set:
      # atrace_apps: "your.app.package"
      # Or capture all apps (larger trace):
      # atrace_apps: "*"

      # Symbolize kernel call stack
      symbolize_ksyms: true

      # Optimize scheduling event storage, reduce Trace size
      compact_sched {
        enabled: true
      }
    }
  }
}

# --- Data source 2: linux.process_stats (process information) ---
# Provide basic information like process name, PID
data_sources {
  config {
    name: "linux.process_stats"
    process_stats_config {
      scan_all_processes_on_start: true
    }
  }
}

Configuration Item Description

Data Source	Purpose	Android Version Requirement	Overhead
`linux.ftrace` (binder/*)	Kernel-layer Binder events	All versions	Low
`linux.ftrace` (sched/*)	Scheduling events, connecting thread wakeups	All versions	Medium
`linux.ftrace` (atrace: dalvik/…)	Framework slices + Java Monitor Contention	All versions (fields evolve by release)	Low-Medium
`linux.process_stats`	Process name and PID mapping	All versions	Very low

Tip: This workflow only depends on linux.ftrace (binder tracepoints + sched + dalvik), so the approach is largely consistent on Android 12/13/14+. UI field names can vary by version; use SQL stdlib for normalization when needed.

Quick Start: 3 Steps to Capture and View Binder Trace

Capture Trace:

# Push configuration
adb push binder_config.pbtx /data/local/tmp/

# Start capture
adb shell perfetto --txt -c /data/local/tmp/binder_config.pbtx \
    -o /data/misc/perfetto-traces/trace.pftrace

# ... operate phone to reproduce lag ...

# Pull file out
adb pull /data/misc/perfetto-traces/trace.pftrace .

Open Trace: Visit ui.perfetto.dev, drag in the trace file.
Add Key Tracks:
- Left side click Tracks → Add new track
- Search “Binder”, add Android Binder / Transactions and Android Binder / Oneway Calls
- Search “Lock”, add Thread / Lock contention (if data available)

Other Binder Analysis Tools

Besides Perfetto, two tools are often useful: am trace-ipc (built in) and binder-trace (open source, stronger content inspection but higher setup cost).

am trace-ipc: Java Layer Binder Call Tracking

am trace-ipc tracks Java-layer Binder call stacks. It enables Binder stack tracking in target processes (BinderProxy.transact() path) and exports aggregated stacks on stop. It is zero-config and does not require root.

Basic usage is very simple, just three steps: “start → operate → stop and export”:

# 1. Start tracking (records Binder calls for eligible processes, usually debuggable ones)
adb shell am trace-ipc start

# 2. Execute the operation you want to analyze on the phone (like starting an app, triggering lag scenarios, etc.)

# 3. Stop tracking and export results to file
adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt

# 4. Pull the result file to computer to view
adb pull /data/local/tmp/ipc-trace.txt

The output is plain text, for example:

Traces for process: com.example.app
Count: 15
java.lang.Throwable
    at android.os.BinderProxy.transact(BinderProxy.java:xxx)
    at android.app.IActivityManager$Stub$Proxy.startActivity(...)
    at android.app.Instrumentation.execStartActivity(...)
    ...

It groups stacks by process and counts occurrences, which quickly answers: “which services were called, and how often”.

Using with Perfetto: Perfetto provides timing, scheduling, and flow context; trace-ipc tells you exactly which Java call sites initiated Binder traffic.

Best for: validating frequent IPC as ANR/jank cause, and pinpointing Java-origin call sites.

binder-trace: Real-time Binder Message Parsing

binder-trace can intercept and parse Binder messages in real time, often described as “Wireshark for Binder”.

It relies on Frida dynamic instrumentation, so you typically need root (or emulator), frida-server on device, and Python 3.9+ locally. Example:

1 2	# Track Binder communication for a specific app (-d specifies device, -n specifies process name, -a specifies Android version) binder-trace -d emulator-5554 -n com.example.app -a 11

It supports filtering by interface/method/transaction type and is best for security and reverse-engineering workflows where payload semantics matter. For routine performance triage, Perfetto + am trace-ipc is usually enough.

Binder Analysis Workflow

After getting the Trace, don’t just fish in the ocean. It’s recommended to proceed in the order of “find target → look at latency → check threads → find locks”.

Step 1: Identify Transaction Latency

The first step is finding the transaction you care about. In Perfetto, common entry points are: find your app as Client on the Transactions track; search with / by interface/method (for example IActivityManager / attachApplication) or full slice name (for example AIDL::java::IActivityManager::attachApplication::server); or start from long S segments on UI-thread thread_state when diagnosing jank.

After selecting a Transaction slice, the Details panel shows client/server threads, timestamps, and durations. UI fields vary by version, so use SQL android_binder_txns as the stable baseline:

client_dur: end-to-end client duration (for sync calls, roughly “time waiting for Binder return”)
server_dur: server wall-clock duration from handling start to reply
dispatch_dur = server_ts - client_ts: delay before server actually starts handling (often queueing/scheduling pressure)

Run this in Perfetto SQL to list slow synchronous transactions:

INCLUDE PERFETTO MODULE android.binder;

SELECT
  aidl_name,
  method_name,
  client_process,
  client_thread,
  client_dur / 1e6 AS client_ms,
  server_process,
  server_thread,
  server_dur / 1e6 AS server_ms,
  (server_ts - client_ts) / 1e6 AS dispatch_ms
FROM android_binder_txns
WHERE is_sync
ORDER BY client_dur DESC
LIMIT 20;

These relationships determine next steps: if client_dur is long but server_dur is short, the bottleneck is likely dispatch/queueing; if server_dur itself is long, inspect what the server Binder thread is doing (business logic, lock wait, or I/O).

Step 2: Evaluate Thread Pool and Oneway Queue

If Step 1 analysis finds that latency is mainly not in server-side processing, but in “queuing”, then you need to further check the status of the Binder thread pool. Before deep analysis, first answer a frequently asked question: “approximately how many Binder threads does each process have? What’s the scale of system_server’s Binder thread pool? Under what circumstances will it be ‘exhausted’?”

SystemServer’s Binder Thread Pool Scale

In upstream AOSP (Android 14/15), the Binder thread pool design philosophy is: grow on demand, configurable, no single fixed number.

Thread pool grows on demand: Each server process maintains a thread pool in the Binder driver, where the actual number of threads increases or decreases according to load on demand, with the upper limit jointly determined by the max_threads field in the kernel and user-space configurations like ProcessState#setThreadPoolMaxThreadCount().
Typical upper limit depends on process role: app processes are usually around 15 Binder workers (libbinder default), while system_server raises the cap explicitly at boot; current AOSP sets it to 31.
Some vendor ROMs or custom kernels will adjust the upper limit up or down based on their own load models (for example, adjusting to dozens of threads), so when you see specific numbers through ps -T system_server, top -H, or counting Binder: threads in Perfetto on different devices, there may be differences.
Take actual observation as standard, not memorizing a number: In Perfetto, a more recommended approach is to directly expand a process and see how many Binder:xxx_y thread tracks there are, and their activity level during the Trace capture, to evaluate the thread pool’s “scale” and “busyness”.

Binder Thread Count, Buffer, and “Binder Exhaustion”

In performance analysis, when people mention “Binder count”, they often confuse three different types of resource limits:

Binder thread-pool exhaustion means all Binder workers in a process are busy (Running / D / S), with no idle thread available for new transactions. You’ll often see client threads stuck in S at ioctl(BINDER_WRITE_READ) / epoll_wait, and many transactions with large dispatch_dur (server_ts - client_ts) in SQL. In system_server, this can quickly amplify into global jank or ANR.

Binder transaction buffer exhaustion involves a shared buffer of limited size (typical value about 1MB magnitude) that each process has in the Binder driver, used to carry Parcel data being transmitted. Typical scenarios include one transaction transmitting an object that’s too large (like a large Bitmap, extra long string, large array, etc.), and a large number of concurrent transactions not yet consumed, causing too many unreleased Parcels to pile up in the buffer. Possible results include kernel logs showing binder_transaction_alloc_buf failures, Java layer throwing TransactionTooLargeException, and subsequent transactions queuing for a long time or even failing in the driver layer (looks like “Binder is used up”). The solution to such problems is not to “open more threads”, but to control the data amount per transmission (split packets, paging, streaming protocols), and prioritize using SharedMemory / files / ParcelFileDescriptor and other mechanisms for large block data.

Binder reference table / object count: The Binder driver maintains reference tables and node objects for each process, and these also have upper limits, but in most actual scenarios, they rarely hit this first. Common risk is holding a large number of Binder references for a long time without releasing, more manifesting as memory/stability issues, not UI lag.

When analyzing in Perfetto, you can carry a judgment framework:
“Is the current slowness because the thread pool is full, or because transactions are too large/buffer is used up?”
The former mainly looks at Binder thread count and thread_state, plus dispatch_dur; the latter focuses on transaction size, concurrency, and TransactionTooLargeException / binder_transaction_alloc_buf signs.

Now return to the analysis scenario:

Thread-pool pressure directly limits service-side concurrency. For sync transactions, if server Binder threads stay busy (Running / D) for long periods, new requests queue and clients block at ioctl(BINDER_WRITE_READ) / epoll_wait; on UI, this is often visible as long S segments.

In Perfetto, prioritize two signals: whether Binder threads are persistently saturated, and whether dispatch_dur is consistently larger than server_dur (same criterion as Step 1).

Identifying Oneway calls in Perfetto: sync calls block client threads (thread_state shows S) and typically show transaction → reply flow; oneway calls return immediately, have one-way flow only, and can be filtered with android_binder_txns.is_sync = 0 in SQL.

When analyzing Oneway-related issues, focus on two things: first, the server-side queue depth (if Oneway requests on the same IBinder object pile up, the actual execution timing of subsequent requests will be continuously delayed); second, whether there’s a batch sending pattern (a large number of Oneway calls in a short time will form “spikes”, appearing as densely arranged short Slices on server-side Binder threads in Perfetto).

It’s worth mentioning that SystemServer’s Binder threads not only need to handle requests from various Apps, but also handle system internal calls (like AMS calling WMS, WMS calling SurfaceFlinger, etc.). If a “misbehaving” App frantically sends Oneway requests in a short time, it might fill up a certain system service’s Oneway queue, further affecting other Apps’ asynchronous callback latency, causing a global lag feeling.

Step 3: Investigate Lock Contention

If you jump to the server-side Binder thread and find it stays in S (Sleeping) or D (Disk Sleep / Uninterruptible Sleep) state for a long time while processing your request, it usually means it’s waiting for some resource – either waiting for a lock or waiting for IO. Lock contention is a very common source of performance bottlenecks in SystemServer, because SystemServer runs a large number of services that share a lot of global state, and this state is often protected by synchronized locks.

Java locks (Monitor Contention) is the most common situation. There are quite a few global locks in SystemServer, like WindowManagerService’s mGlobalLock, some internal locks of ActivityManagerService, etc. When multiple threads simultaneously need to access resources protected by these locks, contention occurs. In Perfetto, if you see a Binder thread state as S, and the blocked_function field contains symbols related to futex (like futex_wait), you can basically be sure it’s waiting for a Java lock. To further confirm which lock it’s waiting for and who’s holding it, you can check the Lock contention track. Perfetto will visualize the lock contention relationship: marking the Owner (thread holding the lock, like the android.display thread) and Waiter (thread waiting for the lock, like the Binder:123_1 processing your request) with connection lines. Clicking the Contention Slice, you can also see the lock object’s class name (like com.android.server.wm.WindowManagerGlobalLock) in the Details panel, which is very helpful for understanding the root cause of the problem.

Native locks (Mutex / RwLock) situations are relatively rarer, but can be encountered in some scenarios. Manifestations are similar: thread state is D or S, but the call stack shows symbols from the Native layer like __mutex_lock, pthread_mutex_lock, rwsem, not Java’s futex_wait. Analyzing such problems usually needs to combine sched_blocked_reason events to see what the thread is specifically waiting for, belonging to relatively advanced content, so we won’t expand on it here.

SQL for Java Monitor Contention in `system_server` (Optional)

Perfetto stdlib provides parsed android_monitor_contention; use it directly instead of manually parsing slice names:

INCLUDE PERFETTO MODULE android.monitor_contention;

SELECT
  process_name,
  blocked_thread_name AS waiter_thread,
  blocking_thread_name AS owner_thread,
  (dur / 1e6) AS dur_ms,
  (waiter_count + 1) AS waiter_threads,
  short_blocked_method,
  short_blocking_method,
  blocked_src,
  blocking_src
FROM android_monitor_contention
WHERE process_name = 'system_server'
ORDER BY dur DESC
LIMIT 50;

Tip: if this returns nothing, make sure atrace_categories includes dalvik and contention actually occurred during capture.

Case Study: Window Management Delay

A real case to demonstrate the workflow: startup animation stutter.

1. Discover Anomaly

On the app UI Thread, one doFrame takes 30ms (vs. 16.6ms budget at 60Hz). The corresponding thread_state shows the main thread in S for 18ms, meaning it is mostly waiting.

2. Track Binder Call

The 18ms S segment shows a call to IActivityTaskManager.startActivity. Flow points to system_server thread Binder:1605_2, which handles the request.

3. Server-side Analysis

On Binder:1605_2, execution lasts about 15ms and Lock contention shows a clear wait segment.

4. Pin Down the Culprit

Details show the thread waits on com.android.server.wm.WindowManagerGlobalLock, owned by android.anim, for about 12ms.

Conclusion: startActivity is blocked by WindowManagerGlobalLock on the server side, which expands into a user-visible jank frame.

Optimization direction: hard to fully fix from app side, but you can reduce startup IPC and avoid complex window operations during animation-heavy windows.

Case Study: Binder Thread Pool Saturation

Another case: multiple apps start simultaneously and the whole system feels sluggish.

1. Discover Anomaly

Multiple app main threads stay in S during the same interval and are all waiting for Binder returns, matching user-reported global responsiveness drops.

2. Check SystemServer’s Thread Pool Status

In system_server, almost all Binder: threads remain busy with little idle gap, indicating thread-pool saturation.

3. Analyze Queuing

Reuse the Step-1 criterion: if many transactions show dispatch_dur much larger than server_dur, latency is mainly queueing, not per-call server work.

4. Locate Root Cause

Transaction breakdown shows one background app issuing hundreds of IPackageManager queries in a short burst. Each call is short (~5ms), but the volume is enough to saturate the pool.

Conclusion: bursty batch Binder calls can crowd out system_server capacity and amplify into system-wide lag.

Optimization direction: avoid looped IPC; prefer batch APIs (for example getPackagesForUid) plus throttling/batching. System-side options include service rate-limits and hotspot optimization.

Platform Features and Best Practices

As Android evolves, Binder keeps improving in performance and stability. These features help explain Perfetto behavior and guide practical tuning.

Binder Freeze (Android 12+): a frozen cached process gets almost no CPU. Synchronous (non-oneway) Binder calls to it are rejected and may lead to target-process kill; asynchronous (oneway) transactions are typically buffered until thaw.

Frozen-callee callback policy (common on Android 14+): use RemoteCallbackList frozen-callee policies (DROP, ENQUEUE_MOST_RECENT, ENQUEUE_ALL) to control callback buildup while the target process is frozen.

Binder Heavy Hitter Watcher: identifies Binder hotspots with unusually high short-window call share. Enablement, thresholds, and outputs depend on build/version/device configuration.

Some suggestions for developers:

About Oneway: use it only when no return value or completion timing is required (for example logging, fire-and-forget signals). Replacing sync calls with oneway just to “unblock UI” often shifts backlog to server queues and introduces ordering issues.

About large payloads: avoid sending large objects (especially Bitmaps) over Binder. Per-process Binder buffer is ~1MB and can trigger TransactionTooLargeException; use SharedMemory, files, or ParcelFileDescriptor instead.

About main-thread Binder calls: avoid calling services with unpredictable latency on UI thread; if unavoidable, offload to background threads and post results back.

Summary

Perfetto is one of the most effective tools for Binder diagnostics. The practical method is: capture binder/sched/dalvik signals with linux.ftrace, follow Flow links from client to server, and use client_dur / server_dur / dispatch_dur + thread states + lock contention to separate “queueing slow”, “server processing slow”, and “lock wait”.

For unexplained jank/ANR, use the sequence: “is UI waiting on Binder?” → “is server queued, slow, or lock-blocked?”. Combined with CPU/scheduling/rendering signals, this usually leads to root cause quickly.

References

Attachments

Download Perfetto Trace (SystemServer Binder Case)
(Trace data contains sensitive information, please keep it confidential after downloading.)

About the Author & Blog

“If you want to go fast, go alone. If you want to go far, go together.”

Android Perfetto Series 9: CPU Information Interpretation

2025-11-12T02:00:00.000Z

This is the ninth article in the Perfetto series, focusing on CPU information analysis in Perfetto. Perfetto provides far superior data visualization and analysis capabilities compared to Systrace. Understanding CPU-related information is the foundation for locating performance bottlenecks and analyzing power consumption issues.

The goal of this series is to examine the overall operation of the Android system from a brand new graphical perspective through the Perfetto tool, while also providing a new way to learn the Framework. Perhaps you’ve read many source code analysis articles but always feel confused by the complex call chains or can’t remember specific execution flows. Through Perfetto, by visualizing these processes, you may gain a deeper and more intuitive understanding of the system.

Perfetto Series Articles
CPU Information Overview in Perfetto
Trace Config Required for Capturing CPU Information
CPU Core Architecture: big.LITTLE
CPU Scheduling
CPU Frequency Deep Dive
Linux Kernel Scheduling Strategy: Core Selection and Migration
Practice and SQL
Summary

Perfetto Series Articles

CPU Information Overview in Perfetto

In the Perfetto UI, CPU-related information is usually grouped at the top and is the starting point for performance analysis. It mainly includes the following three core tracks:

CPU Scheduling: Shows which thread is executing on each CPU core at each time point.
CPU Frequency: Shows the frequency changes of each CPU core or core cluster.
CPU Idle: Shows the low-power states (C-States) entered by each CPU core.

By analyzing CPU-related information, you can answer the following key performance questions or perform competitive analysis:

Why isn’t the application main thread executing? Is it being preempted by other threads?
What’s the reason for a task executing slowly? Was it scheduled to a low-performance core?
In specific scenarios, is the CPU frequency limited?
When the application is in the background, does the CPU effectively enter deep sleep state?

Trace Config Required for Capturing CPU Information

To collect all CPU data needed for analysis in this article, you need a correct TraceConfig. Incorrect configuration will cause certain tracks (such as CPU frequency) or certain kernel events (such as wakeup events) to be missing. Below is the Perfetto official documentation’s recommended configuration for general CPU analysis. You can add it to your Perfetto Config and use it when capturing traces.

data_sources {
  config {
    name: "linux.ftrace"
    ftrace_config {
      ftrace_events: "sched/sched_process_exit"
      ftrace_events: "sched/sched_process_free"
      ftrace_events: "task/task_newtask"
      ftrace_events: "task/task_rename"
      ftrace_events: "sched/sched_switch"
      ftrace_events: "power/suspend_resume"
      ftrace_events: "sched/sched_blocked_reason"
      ftrace_events: "sched/sched_wakeup"
      ftrace_events: "sched/sched_wakeup_new"
      ftrace_events: "sched/sched_waking"
      ftrace_events: "sched/sched_process_exit"
      ftrace_events: "sched/sched_process_free"
      ftrace_events: "task/task_newtask"
      ftrace_events: "task/task_rename"
      ftrace_events: "power/cpu_frequency"
      ftrace_events: "power/cpu_idle"
      ftrace_events: "power/suspend_resume"
      symbolize_ksyms: true
      disable_generic_events: true
    }
  }
}
data_sources {
  config {
    name: "linux.process_stats"
    process_stats_config {
      scan_all_processes_on_start: true
    }
  }
}
data_sources {
  config {
    name: "linux.sys_stats"
    sys_stats_config {
      cpufreq_period_ms: 250
    }
  }
}

This configuration enables key ftrace events including sched (scheduling), power (frequency and idle), and task (task lifecycle), which are the foundation for deep CPU analysis.

CPU Core Architecture: big.LITTLE

Before diving into analysis, you must understand the CPU core architecture of modern mobile SoCs. Currently, mainstream mobile processors generally adopt the big.LITTLE heterogeneous multi-core architecture, or its variants, such as big.Medium.LITTLE (big-medium-small cores).

LITTLE cores: Designed for low power consumption, with lower frequencies, used for background tasks and lightweight computing to ensure battery life.
Big cores: Designed for high performance, with higher frequencies and greater power consumption, used for user interaction, gaming, app launches, and other heavy load scenarios.
Prime Core: Some flagship chips have an extremely high-frequency prime core for the most demanding single-core performance challenges.

In Perfetto’s CPU tracks, cores are usually numbered starting from 0. For example, in a typical octa-core processor, CPU 0-3 might be LITTLE cores, CPU 4-6 big cores, and CPU 7 the prime core. Identifying core types is crucial for performance analysis: if a compute-intensive task runs on a LITTLE core for an extended period, its execution time will far exceed expectations. During analysis, you need to match the thread’s running core with its task attributes to judge whether the scheduler’s behavior meets expectations.

Below is a typical 4+4 CPU:

Below is a typical 4+3+1 CPU (MTK Dimensity 9500, 9400, and Qualcomm Snapdragon high-end series):

Below is a 5+2 CPU (Qualcomm 8Elite 1 lite version; the standard 8Elite 1 has cores 0-5 as LITTLE cores and 6-7 as big cores, so I won’t include that image here):

Generally, you can find out the big-medium-small core architecture by checking the CPU spec, or by cat-ing the corresponding CPU nodes. I won’t elaborate further here.

CPU Scheduling

The CPU Scheduling track is the most commonly used and most important part. It visualizes the decision-making process of the Linux kernel scheduler. Its data source is the sched/sched_switch event in kernel ftrace.

Each CPU core corresponds to an independent track row. Different colored blocks on the track represent specific threads running on that CPU core during that time slice.

UI details: Clicking a CPU slice, the details panel will show the cpu, end_state, priority, associated process/thread, etc. for that scheduling; expanding the process downward also shows each thread’s independent track, facilitating tracking of a single thread’s state evolution (refer to official documentation).

Thread State Deep Dive

Understanding Linux thread states is a prerequisite for performance optimization. In Perfetto, selecting a thread, the Current State panel below will show its current state. This state information comes from Perfetto’s parsed thread_state/thread_state_slice tables.

Running (Green)

State Definition: Green represents the thread is executing code on the CPU. This is the only state truly consuming CPU resources for computation.

Analysis Points:

Execution Duration: Excessively long Running states, especially on critical threads, usually mean intensive computational tasks, such as complex algorithms or loops. This increases task duration and may block other threads’ execution.
Running Core: Analyze in combination with the CPU’s core architecture (e.g., big.LITTLE). Whether a compute-intensive task is scheduled to the expected performance core (big core) is an important basis for evaluating whether the scheduling strategy is reasonable.
Running Frequency: The thread’s actual execution speed is also affected by CPU frequency. Even if the thread runs on a big core, if frequency is reduced due to thermal throttling or other reasons, its performance will decline. Therefore, comprehensive analysis is needed in combination with the CPU Frequency track.

R (Runnable)

State Definition: The thread has all conditions for running and is waiting for the scheduler to assign a CPU core. In Perfetto’s thread private track, the Runnable state is usually displayed as light green or white bars.

Analysis Points:

Runnable and Jank: For threads sensitive to response time like UI threads, long periods in Runnable state are a direct cause of jank. It means the thread cannot get CPU time in time to handle tasks (such as UI drawing), leading to frame drops.

Three Types of Runnable:
Careful observation reveals that the “predecessor” of threads entering Runnable state varies. Based on the kernel’s scheduling timing, we can divide it into three situations:

Wake-up from Sleep: This is the most common type. The thread is awakened from S or D state because the resource it was waiting for (such as lock, I/O, Binder reply) is ready, enters Runnable state, waiting to be selected by the scheduler for execution.
User Preemption: Refers to the thread’s running time slice expiring, or a higher priority task appearing, causing the scheduler to decide to swap out the current thread when returning from kernel mode to user mode (such as after system call, interrupt return). At this time, the swapped-out thread changes from Running to Runnable. In the underlying sched_switch trace, its prev_state is marked as R.
Kernel Preemption: Refers to a higher priority task or interrupt “forcibly” interrupting the current thread while it’s executing kernel mode code, making it yield the CPU. This situation usually means a more urgent scheduling. At this time, the swapped-out thread changes from Running to Runnable (Preempted). In the underlying trace, its prev_state is marked as R+, which Perfetto parses and displays accordingly.

Understanding the differences between these three types helps more precisely judge the causes of scheduling delays. For example, a large number of Runnable (Preempted) may suggest the system has frequent, high-priority wakeup sources, causing critical threads to be frequently interrupted in kernel mode, or the CPU is already fully loaded (a more common situation). At this time, lower priority Tasks are easily preempted by higher priority Tasks and forced to yield the CPU. If your critical Task is always being preempted, you need to adjust priorities.

S (Sleep / Interruptible Sleep)

State Definition: The thread enters sleep while waiting for an event and can be interrupted by signals. This is the most common sleep state and is usually benign because it doesn’t consume CPU resources while waiting.

Analysis Points:

Waiting Resources: If critical threads (such as UI thread) sleep for too long, it will also cause performance issues. Common waiting reasons include:
- Lock Contention: Waiting to acquire a mutex (Java lock or native futex).
- Binder Communication: Waiting for another process to return results through Binder call.
- I/O Operations: Waiting for network socket data (epoll_wait).
- Explicit Sleep: Code called Thread.sleep() or Object.wait().
Dependency Analysis: In Perfetto, selecting a Task that is Running in the CPU area will show UI indicating which Task on which CPU woke it up. This helps quickly locate inter-thread dependencies. Combined with function call stacks, you can further locate the specific code causing sleep.

D (Uninterruptible Sleep)

State Definition: The thread is waiting for hardware I/O operations to complete and cannot be interrupted by any signal during this period. This state is designed to protect data consistency during process-device interactions. In Perfetto, this state is usually displayed as orange or red and is a signal requiring key attention.

Analysis Points:

Serious Performance Bottleneck: Long periods in D state mean the thread is completely blocked and cannot respond to any events. If it occurs on the UI thread, it easily leads to ANR.
Common Causes:
1. Disk I/O: Frequent or single large file read/write operations.
2. Memory Pressure: Insufficient system physical memory, leading to frequent page swap in/out, which is essentially high-frequency disk I/O.
3. Kernel Driver Issues: Implementation defects in some kernel drivers may also cause threads to fall into D state.
Investigation Direction: In the Current State panel, if D state is accompanied by (iowait) marking, it clearly indicates waiting for I/O. You need to check the application’s I/O patterns, evaluate their reasonableness, such as whether time-consuming I/O operations are placed on the main thread, or whether there’s room for optimization (such as reducing I/O frequency and data volume).

Wakeup Relationship Analysis

Inter-thread dependencies are a difficult point in performance analysis. For a thread sleeping for a long time, the key is finding out “who it’s waiting for”. Perfetto provides powerful wakeup relationship visualization functionality.

UI Operation: In Perfetto’s CPU area, left-click to select a thread Task in Running state. Perfetto will automatically draw a dependency arrow from “waker” to “wakee” and highlight the thread slice where the wakeup source is located.
Underlying Principle: This functionality depends on the kernel’s sched_wakeup ftrace event. When thread T1 releases a resource (such as unlocking, completing Binder call), and thread T2 is waiting for that resource, the kernel marks T2 as Runnable state and records this T1 -> T2 wakeup event. Perfetto parses these events to build the dependency chain between threads.

Through wakeup analysis, you can clearly track complex call chains, for example: UI thread waits for a Binder call -> Binder thread executes task -> Binder thread waits for another lock -> Lock-holding thread releases lock and wakes Binder thread -> Binder thread completes task and wakes UI thread. Bottleneck points in the entire process will be clear at a glance.

Scheduling Wakeup and Latency Analysis

When thread A suspends on wait(), it enters S (Sleeping) and is removed from the CPU run queue. After thread B calls notify(), the kernel converts thread A to R (Runnable). At this time thread A is “eligible” to be put back into some CPU’s run queue, but this doesn’t mean “immediate” running.

Common waiting reasons include:

All CPUs are busy: Thread A needs to wait for a queue slot to open up (or currently running threads have higher priority).
There’s an idle CPU, but migration takes time: The load balancer needs a certain time window to migrate the thread to another CPU.

Unless using real-time priority, most Linux scheduler configurations are not strictly “work-conserving”. The scheduler sometimes “waits” for the current CPU thread to naturally idle to avoid extra overhead and power consumption from cross-CPU migration. This forms observable “queuing delay” in R state. Combined with sched_waking/sched_wakeup_new, you can more precisely characterize the time period from “being awakened” to “actually queued/running” (refer to official documentation: differences and applicable scenarios of sched_waking / sched_wakeup).

In the target thread’s thread_state track, filter state=R slices as direct evidence of “scheduling delay”.
Synchronously compare other heavy-load threads and IRQ/SoftIRQ traces on the same CPU to verify whether there’s time overlap of preemption or high-priority suppression.
If frequently queuing in R state and ending with end_state=R+, view as serious involuntary preemption, need to evaluate priority, placement, and load balancing strategies.

Differences Between sched_waking and sched_wakeup and Non-strict Work-conserving

sched_waking is issued when a thread is marked as runnable (R), sched_wakeup is related to cross-CPU wakeup and may be recorded on source or destination CPU; for most latency analysis, only sched_waking is sufficient (see official explanation).
Most Linux scheduling configurations under general priority are not strictly “work-conserving”. The scheduler sometimes “waits for current CPU to idle” to avoid extra overhead and power consumption from cross-core migration. This causes waiting time in R state (queuing delay) which is not abnormal but a result of trade-offs (see Perfetto CPU Scheduling).

User Mode and Kernel Mode: sys_* Slices Locate Empty Flame Graphs

Not all green Running slices are application code busy. If a thread falls into a single long system call like sys_read, sys_futex, user mode sampling flame graphs may be almost empty.
If a UI thread’s某段 sched_slice is very long, but CPU flame graph hotspots are few or almost none:
1. Open that thread’s slice view, check if there are long sys_* slices;
2. If exists: Bottleneck is mostly in I/O or synchronization primitives, prioritize checking I/O paths, lock granularity, and access patterns;
3. If not exists: Return to flame graph, continue profiling user mode hotspot functions.
Suggestions: Merge I/O, switch to async, optimize lock contention, reduce system call frequency and single data volume.

CPU Time and Wall Time

Wall is the real-world time from slice start to end, CPU is the time actually running on CPU.
Relationship: Wall = CPU + Runnable + Sleep.
1. Select target slice (e.g., Choreographer#doFrame), compare Wall with CPU;
2. If Wall ≈ CPU, it’s computation-heavy, use flame graph to locate hotspots;
3. If Wall >> CPU, it’s scheduling or dependency waiting, check thread_state‘s R/S/D distribution and wakeup chain.

CPU Frequency Deep Dive

CPU frequency directly affects code execution speed and is also positively correlated with power consumption. The CPU Frequency track shows each core’s operating frequency (scaling_cur_freq) at specific times. But more importantly, understanding the limiting factors behind it:

Core Factors Affecting CPU Frequency

Task Utilization: This is the main driving factor. Modern Android systems mostly use schedutil as the cpufreq frequency scaling policy. It directly associates with the Scheduler, deciding frequency based on thread “busyness” (utilization). A high-load thread (high util) will prompt schedutil to request higher frequency, and vice versa.
Scenario Policy (Power HAL): Android Framework passes the current system state, i.e., “scenario”, to the lower layer through Power HAL. For example, during app launch, gaming, or screen touch, Power HAL requests higher performance from the kernel, usually by raising the CPU’s floor frequency (scaling_min_freq) and/or ceiling frequency (scaling_max_freq), ensuring the CPU can respond quickly.
Thermal Throttling: This has the highest priority limitation. When device temperature (from battery, CPU, NPU, and other sensors) exceeds preset thresholds, the thermal control system forcibly lowers the CPU’s ceiling frequency to reduce heat and protect hardware. At this time, even with high-load tasks, CPU frequency cannot increase, a common external cause of game frame drops and app jank.
Power Limitation and Power Saving Mode: In low battery or power saving mode enabled, the system similarly limits maximum performance output by lowering ceiling frequency to extend battery life.

Therefore, when finding a heavy task running with CPU frequency not increasing, you should not only look at current frequency but also pay attention to whether scaling_max_freq is limited. This usually means the root cause of the performance bottleneck is not in the application code itself but in the system’s thermal or power consumption policy.

The above image is a marker diagram of the CPU frequency area. Hovering the mouse over it shows the current frequency. CPU frequency changes very quickly. In the image, CPU has colored and non-colored parts. Colored parts indicate the current CPU has Tasks running, non-colored parts indicate the current CPU is empty with no Tasks.

Frequency Data Collection and Platform Differences

Two acquisition methods:
- Event-driven: Enable power/cpu_frequency, record events when kernel cpufreq driver changes frequency. Not all platforms support it, reliable on most ARM SoCs, often no data on many modern Intel platforms.
- Polling sampling: Enable linux.sys_stats and set cpufreq_period_ms > 0, periodically read /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq, works on both ARM/Intel. Recommended to combine with event-driven to fill “initial frequency snapshot”.
Android devices often scale frequency by “cluster”, common phenomenon is multiple CPUs within the same cluster synchronously changing frequency.
Known issues:
- Events only generate when frequency changes, short Traces or stable scenarios may have left-side “blanks”. At this time, rely on polling to fill.
- Some UI versions don’t render cpufreq track when Idle state not captured, but data can still be obtained through queries.
- Reference: CPU frequency and idle states official explanation.

big.LITTLE: Same Frequency Doesn’t Equal Same Performance or Power Consumption

On heterogeneous CPUs, both at 2.0GHz, LITTLE cores and big cores’ actual computing power and energy consumption are not equivalent. Frequency must be understood in combination with core type.
Core capacity and IPC: Big cores usually have wider out-of-order execution, more execution ports, larger cache, and more aggressive prefetch/branch prediction, higher instructions per cycle (IPC); at the same frequency, big cores need less time and energy to complete the same work.
Cluster-level DVFS: Mobile SoCs mostly scale frequency by “cluster”. LITTLE core cluster’s high frequency doesn’t equal big core cluster’s medium frequency performance output; different clusters have different voltage-frequency-energy curves, same frequency point cannot be horizontally compared for “performance per watt”.
Memory/cache/interconnect bottleneck: If hotspot is constrained by memory bandwidth, LLC hit rate, or system interconnect (NoC), simply raising LITTLE core frequency has limited benefit; big cores’ larger cache/stronger prefetch can significantly reduce same task’s memory access waiting, reflecting “same frequency different effect”.
Energy efficiency curve is non-linear: LITTLE cores approaching maximum frequency often enter energy efficiency steep decline zone (voltage elevation causes marginal energy consumption surge), while big cores at medium frequency points may achieve “higher unit energy efficiency”. Same frequency comparison ignores “voltage-frequency-energy” three-dimensional trade-off.

P-States and governor

CPU frequency is not a continuous value but discrete performance states P-States. Common governor is schedutil, selecting appropriate P-State based on task utilization and other signals, coordinating voltage adjustment.
Frequency changes in UI are essentially governor switching between different P-States. High frequency doesn’t necessarily mean faster or more power-efficient, needs to be understood in combination with core cluster type and current upper/lower limit constraints.
Verification steps:
1. In CPU Frequency, observe whether frequency upper/lower limits are raised/lowered (such as scenario policy/thermal throttling limiting scaling_max_freq).
2. In CPU Scheduling, check which type of core critical threads run on (combined with device’s core number division).
3. If “high frequency + LITTLE core + still slow”, prioritize considering core selection/memory access bottleneck, not simply “frequency insufficient”.
Recommend combining Power HAL scenarios, thermal management, and task profile (CPU intensive or memory access intensive) for comprehensive optimization, avoid simply using frequency as tuning target. Reference official documentation: Perfetto CPU Scheduling.

Linux Kernel Scheduling Strategy: Core Selection and Migration

After understanding thread states and frequency, we also need to deeply understand two core behaviors of the Linux kernel scheduler (mainly EAS - Energy Aware Scheduling in Android): how to select a CPU core for tasks, and why to migrate tasks from one core to another.

Core Selection Logic (Task Placement)

When a thread is awakened from Sleep state, or a new thread is created, the EAS scheduler needs to select the most suitable CPU core for it. Its core goal is to minimize system power consumption while meeting task performance requirements. The decision-making process is roughly as follows:

Evaluate Task Load (Task Utilization): The scheduler evaluates the thread’s util, i.e., how much computing resources it needs. This is a dynamically adjusted value reflecting the thread’s historical busyness.
Find “Sufficient” Core: The scheduler traverses all available CPU cores, comparing task’s util with each core’s capacity (capacity/maximum computing ability). Big cores’ capacity is far higher than LITTLE cores. The scheduler looks for cores where capacity > util, i.e., cores that can “accommodate” this task.
Find “Most Energy-Efficient” Core: Among all cores meeting capacity requirements, the scheduler uses the “Energy Model” preset in the kernel for calculation. This model knows each core’s power consumption at each frequency. The scheduler selects a CPU core that makes the entire system (including the task itself and other running tasks) have the lowest total power consumption as the final choice.

In short: EAS’s goal is not to find the fastest core for a task, but to find a core that’s “just enough” and “most power-efficient”.

Core Migration Logic (Task Migration)

Moving tasks from one CPU core to another is a key means for the scheduler to perform dynamic tuning. It mainly occurs in the following situations:

Load Balancing: This is the most common migration reason. The scheduler periodically checks whether the system is in a “load imbalance” state. For example, CPU-1 (LITTLE core) is packed with high-load tasks causing its utilization to saturate, while CPU-7 (big core) is very idle. At this time, the scheduler judges the system is imbalanced and will “pull” a high-load task from CPU-1 to CPU-7 to run, to restore balance and improve performance.
Wake-up Migration: When a thread wakes up, the scheduler re-evaluates its best core. If this thread’s util changed during sleep (for example, a background download thread suddenly receives a large file download task, util spikes), or the core it was running on is now very busy, the scheduler may directly select a more suitable new core for it at wake-up, rather than letting it queue in the original place.

Understanding core selection and migration logic helps us judge whether the scheduler’s behavior is “abnormal”. For example, an obvious foreground UI thread being unreasonably restricted to LITTLE cores for a long time, or “bouncing back and forth” too frequently between big and LITTLE cores, may suggest problems with system scheduling strategy or task priority settings.

Of course, currently Android manufacturers have made a lot of customizations to the scheduler. Critical Tasks usually occupy more CPU and are more likely to get on big cores. There are also many core binding strategies and core signing strategies, causing phenomena seen by each manufacturer to be different. This is also each manufacturer’s core competitiveness (such as Oppo’s Hummingbird Engine).

Practice and SQL

Using SQL for Quantitative Analysis

Perfetto’s built-in SQL query engine is one of its powerful features, allowing developers to perform precise aggregation, filtering, and analysis on Trace data. Below are some commonly used CPU analysis queries.

1. Calculate Total CPU Time for Each Process

This query counts each process’s total running time on all CPUs, sorted in descending order, used to quickly locate processes consuming the most CPU resources.

SELECT
  process.name,
  sum(dur) / 1e9 AS total_cpu_time_s
FROM sched
JOIN thread ON sched.utid = thread.utid
JOIN process ON thread.upid = process.upid
GROUP BY process.name
ORDER BY total_cpu_time_s DESC;

2. Analyze Single Thread’s Time State Distribution

This query based on the thread_state table can be used to analyze a specific thread’s (example surfaceflinger) time distribution in various states, thus judging its main bottleneck.

SELECT
  CASE state
    WHEN 'Running' THEN 'Running'
    WHEN 'R' THEN 'Runnable'
    WHEN 'S' THEN 'Interruptible Sleep'
    WHEN 'D' THEN 'Uninterruptible Sleep'
    ELSE state
  END AS human_state,
  sum(dur) / 1e6 AS total_time_ms
FROM thread_state
WHERE utid = (SELECT utid FROM thread WHERE name = 'surfaceflinger' LIMIT 1)
GROUP BY human_state
ORDER BY total_time_ms DESC;

3. Find Threads with Highest CPU Consumption in Specific Time Period

This query is used to analyze threads consuming the longest CPU time in specific scenarios (such as 2-5s time period during app launch).

SELECT
  thread.name,
  sum(dur) / 1e9 AS cpu_time_s
FROM sched
JOIN thread ON sched.utid = thread.utid
-- Timestamp unit is nanoseconds, you can add WHERE ts > 2e9 AND ts < 5e9 to get a certain time period
GROUP BY thread.name
ORDER BY cpu_time_s DESC
LIMIT 20;

4. View Thread’s Running Time Distribution on Each CPU Core

This query helps understand a thread’s CPU affinity and whether it runs on expected big/LITTLE cores.

SELECT
  cpu,
  sum(dur) / 1e6 AS time_on_cpu_ms
FROM sched
WHERE utid = (SELECT utid FROM thread WHERE name = 'system_server' LIMIT 1)
GROUP BY cpu
ORDER BY cpu;

5. Calculate CPU Utilization for Each Process

This query calculates each process’s CPU utilization within the entire Trace time range.

SELECT
  process.name AS process_name,
  100 * sum(dur) / CAST(TRACE_END() - TRACE_START() AS REAL) AS cpu_utilization_percent
FROM sched
JOIN thread ON thread.utid = sched.utid
JOIN process ON process.upid = thread.upid
GROUP BY process.name
ORDER BY cpu_utilization_percent DESC;

Summary

Proficient analysis of CPU information in Perfetto is a key skill for Android performance optimization. By deeply understanding core architecture, thread states, wakeup relationships, frequency limitations, and C-State, combined with powerful SQL queries for quantitative analysis, developers can precisely locate and solve various performance and power consumption issues.

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with you all. When three people walk together, one of them can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for support~

One person can go faster, a group of people can go further

Android Perfetto Series 8: Understanding Vsync Mechanism and Performance Analysis

2025-08-05T02:15:30.000Z

This is the eighth article in the Perfetto series, providing an in-depth introduction to the Vsync mechanism in Android and its representation in Perfetto. The article will analyze how the Android system performs frame rendering and composition based on Vsync signals from Perfetto’s perspective, covering core concepts such as Vsync, Vsync-app, Vsync-sf, and VsyncWorkDuration.

With the popularization of high refresh rate screens, understanding the Vsync mechanism has become increasingly important. This article uses 120Hz refresh rate as the main narrative thread to help developers understand the working principles of Vsync in modern Android devices, and how to observe and analyze Vsync-related performance issues in Perfetto.

Note: This article is based on the public evolution from Android 13 to Android 16. Code snippets are aligned to AOSP main signatures, with ... used in a few places to omit non-critical branches. Always verify against your target branch.

Series Catalog
What is Vsync
Basic Working Principles of Vsync in Android
Observing Vsync in Perfetto
How Android App Frames Work Based on Vsync
References
About Me && Blog

Series Catalog

If you haven’t read the Systrace series yet, here are the links:

Systrace Series Catalog: A systematic introduction to Systrace, Perfetto’s predecessor, and learning about Android performance optimization and Android system operation basics through Systrace.
Personal Blog: My personal blog, mainly Android-related content, with some life and work-related content as well.

Welcome to join the WeChat group or community on the About Me page to discuss your questions, what you’d most like to see about Perfetto, and all Android development-related topics with fellow group members.

What is Vsync

Vsync (Vertical Synchronization) is the core mechanism of the Android graphics system. Its existence is to solve a fundamental problem: how to keep the software rendering rhythm synchronized with the hardware display rhythm.

Before the Vsync mechanism existed, the common problem was Screen Tearing. When the display reads the framebuffer while the GPU writes the next frame, the same refresh will show inconsistent top and bottom parts of the image.

What Problems Does Vsync Solve?

The core idea of the Vsync mechanism is very simple: make all rendering work proceed according to the display’s refresh beat. Specifically:

Synchronization Signal: The display emits a Vsync signal every time it starts a new refresh cycle.
Frame Beat and Production: On the application side, when Vsync arrives, Choreographer drives the production of a frame (Input/Animation/Traversal); after the CPU submits rendering commands, the GPU executes asynchronously in a pipeline. On the SurfaceFlinger side, when Vsync arrives, Buffer composition operations are performed.
Buffering Mechanism: Using double buffering or triple buffering technology ensures the display always reads complete frame data.

This way, frame production and display are aligned with Vsync as the beat. Taking 120Hz as an example, there’s a display opportunity every 8.333ms; the application needs to submit a compositable Buffer to SurfaceFlinger before this window. The key constraint is the timing of queueBuffer/acquire_fence/present_fence; if it doesn’t catch up with this cycle, it will be delayed to the next cycle for display.

Basic Working Principles of Vsync in Android

Android system’s Vsync implementation is much more complex than the basic concept, needing to consider multiple different rendering components and their coordinated work.

Layered Architecture of Vsync Signals

In the Android system, there isn’t just one simple Vsync signal. In fact, the system maintains multiple Vsync signals for different purposes:

Hardware Vsync (HW Vsync):
This is the lowest-level Vsync signal, generated by the display hardware (HWC, Hardware Composer). Its frequency strictly corresponds to the display’s refresh rate, for example, a 60Hz display generates HW Vsync every 16.67ms, and a 120Hz display generates one every 8.333ms. (Hardware Vsync callbacks are managed by HWC/SurfaceFlinger, see frameworks/native/services/surfaceflinger related implementation)

However, HW Vsync is not always on. Since frequent hardware interrupts consume considerable power, the Android system adopts an intelligent strategy: only enabling HW Vsync when precise synchronization is needed, and using software prediction to generate Vsync signals most of the time.

Vsync-app (Application Vsync):
This is a Vsync signal specifically used to drive application layer rendering. When an application needs to perform UI updates (such as user touch, animation running, interface scrolling, etc.), the application will request to receive Vsync-app signals from the system.

// frameworks/base/core/java/android/view/Choreographer.java
private void scheduleFrameLocked(long now) {
    if (!mFrameScheduled) {
        mFrameScheduled = true;
        if (USE_VSYNC) {
            // Request next Vsync signal from system
            mDisplayEventReceiver.scheduleVsync();
        }
    }
}

Vsync-app is requested on-demand. If the application interface is static with no animations or user interaction, the application won’t request Vsync-app signals, and the system won’t generate Vsync events for this application.

Vsync-sf (SurfaceFlinger Vsync):
This is a Vsync signal specifically used to drive SurfaceFlinger for layer composition. SurfaceFlinger is the service in the Android system responsible for compositing all application layers into the final image.

Vsync-appSf (Application-SurfaceFlinger Vsync):
A new signal type introduced in Android 13. To eliminate the timing ambiguity brought by the old design where the sf EventThread both woke up SurfaceFlinger and served some Choreographer clients, the system separated the two responsibilities: vsync-sf focuses on waking up SurfaceFlinger, while vsync-appSf faces clients that need to synchronize with SurfaceFlinger.

Observing Vsync in Perfetto

Perfetto traces contain multiple Vsync-related Tracks. Understanding the meaning of these Tracks helps analyze performance issues.

In the SurfaceFlinger Process:

vsync-app
Displays application Vsync signal status, with values changing between 0 and 1. Each value change represents a Vsync signal.
vsync-sf
Displays SurfaceFlinger Vsync signal status. When there’s no Vsync Offset, it changes synchronously with vsync-app.
vsync-appSf
Added in Android 13+, serves special Choreographer clients that need to synchronize with SurfaceFlinger.
HW_VSYNC
Displays hardware Vsync enabled status. Value of 1 means enabled, value of 0 means disabled. To save power, hardware Vsync is only enabled when precise synchronization is needed.

In the Application Process:

FrameDisplayEventReceiver.onVsync Slice Track:
Displays the time point when the application receives Vsync signals. The connection is established through Binder, while events are delivered through BitTube/Looper channels, so timing may be slightly later than vsync-app in SurfaceFlinger.

UI Thread Slice Track:
Contains Choreographer#doFrame and related Input, Animation, Traversal, etc. Slices. Each doFrame corresponds to one frame’s processing work.

RenderThread Slice Track:
Contains DrawFrame, syncAndDrawFrame, queueBuffer, etc. Slices, corresponding to render thread work.

How Android App Frames Work Based on Vsync

Each frame of an Android application completes the entire process from rendering to display based on the Vsync mechanism, involving multiple key steps.

Process Overview (In Order)

Trigger Redraw/Input: View.invalidate(), animation, data change, or input event triggers → ViewRootImpl.scheduleTraversals() → Choreographer.postCallback(TRAVERSAL)
Request Vsync: Choreographer requests next Vsync (app phase) through DisplayEventReceiver.scheduleVsync()
Receive Vsync: After DisplayEventReceiver.onVsync() receives Vsync, it posts an asynchronous message to the main thread message queue
Main Thread Frame Processing: Choreographer.doFrame() executes five types of callbacks in order: INPUT → ANIMATION → INSETS_ANIMATION → TRAVERSAL → COMMIT
Rendering Submission: RenderThread executes syncAndDrawFrame/DrawFrame, CPU records GPU commands, queueBuffer submits to BufferQueue
Composition Display: SurfaceFlinger composites (GPU/or HWC) when vsync-sf arrives, generates present_fence, outputs to display
Frame Completion Measurement: Determines whether displayed on schedule through FrameTimeline (PresentType/JankType) and acquire/present_fence

Below we’ll expand on each step’s key implementation and Perfetto observation points.

When Does App Request Vsync Signals

Applications don’t request Vsync signals all the time. Vsync signals are requested on-demand, only in the following situations will applications request the next Vsync from the system:

Scenarios Triggering Vsync Request:

UI Update Needs: When View calls invalidate()
Animation Execution: When ValueAnimator, ObjectAnimator, and other animations start
User Interaction: Touch events, key events, etc. requiring UI response
Data Changes: RecyclerView data updates, TextView text changes, etc.

Complete Process of App Requesting Vsync

When an application needs to update UI, it requests Vsync signals through the following process:

// 1. UI component requests redraw
// frameworks/base/core/java/android/view/View.java
public void invalidate() {
    // Mark as needing redraw, but don't execute immediately
    mPrivateFlags |= PFLAG_DIRTY;
    
    if (mParent != null && mAttachInfo != null) {
        // Request redraw from parent container
        mParent.invalidateChild(this, null);
    }
}

// 2. ViewRootImpl schedules traversal
// frameworks/base/core/java/android/view/ViewRootImpl.java
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        // Key: Register callback with Choreographer, wait for next Vsync
        mChoreographer.postCallback(
            Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

// 3. Choreographer requests Vsync
// frameworks/base/core/java/android/view/Choreographer.java
private void postCallbackDelayedInternal(int callbackType,
        Object action, Object token, long delayMillis) {
    final long now = SystemClock.uptimeMillis();
    final long dueTime = now + delayMillis;
    mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

    // Important: not only TRAVERSAL; any due callback can trigger next-frame scheduling
    if (dueTime <= now) {
        scheduleFrameLocked(now);
    }
}

private void scheduleFrameLocked(long now) {
    if (!mFrameScheduled) {
        mFrameScheduled = true;
        if (isRunningOnLooperThreadLocked()) {
            scheduleVsyncLocked();
        } else {
            Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
            msg.setAsynchronous(true);
            mHandler.sendMessageAtFrontOfQueue(msg);
        }
    }
}

TRAVERSAL is still the most common trigger, but in AOSP main it is not the only path that requests Vsync.

How Main Thread Listens for Vsync Signals

The application main thread listens for Vsync signals through DisplayEventReceiver. This process involves several key steps:

1. Establish Connection:

// frameworks/base/core/java/android/view/Choreographer.java
private final class FrameDisplayEventReceiver extends DisplayEventReceiver
        implements Runnable {
    
    public FrameDisplayEventReceiver(Looper looper, int vsyncSource, long layerHandle) {
        super(looper, vsyncSource, /* eventRegistration */ 0, layerHandle);
        // Establish connection with SurfaceFlinger during construction
    }
}

2. Receive Vsync Signal:

@Override
public void onVsync(long timestampNanos, long physicalDisplayId, int frame,
        VsyncEventData vsyncEventData) {
    // Received Vsync signal, but note: doFrame is not executed directly here
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    mLastVsyncEventData.copyFrom(vsyncEventData);
    
    // Key: Post work to main thread's MessageQueue
    Message msg = Message.obtain(mHandler, this);
    msg.setAsynchronous(true);  // Set as asynchronous message, priority processing
    mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}

@Override
public void run() {
    // This is where the work for one frame actually begins
    doFrame(mTimestampNanos, mFrame, mLastVsyncEventData);
}

Several Remaining Questions

Q1: Why not execute doFrame() directly in onVsync()?

Thread boundary: In the Choreographer path, onVsync() runs on the bound Looper (usually the main thread). Routing work through the message queue before doFrame() keeps frame scheduling unified and ordered.
Scheduling control: Precisely align execution moment through sendMessageAtTime()
Queue semantics: Enter main thread MessageQueue, ensure coordination with other high-priority tasks

Q2: If Vsync message arrives but main thread is busy, will it be lost?

Not strictly “no loss”. A single scheduleVsync() is a one-shot request. If the main thread stays busy, multiple hardware beats may be skipped and only a newer frame gets processed. Use FrameTimeline to decide whether this became visible jank.
AOSP DisplayEventDispatcher::processPendingEvents explicitly overwrites older vsync events with newer ones (only the most recent one is dispatched).

Q3: Must CPU/GPU complete within a single Vsync cycle? If any link exceeds 1 vsync, will it cause frame drops?

Modern Android systems use multi-buffering (usually triple buffering) mechanism:
- Application side: Front Buffer (displaying) + Back Buffer (rendering) + possible third Buffer
- SurfaceFlinger side: Also has similar buffering mechanism
- This means even if one application frame exceeds the Vsync cycle, it won’t necessarily drop frames immediately.
GPU asynchronous pipeline; the key is whether queueBuffer catches up with SF composition window. Multi-buffering can mask single frame delays but may introduce additional latency. As shown in the figure below, both App-side BufferQueue and SurfaceFlinger-side Buffers are sufficient with redundancy, so no frames are dropped.
However, if the App hasn’t accumulated Buffers before, frame drops will still occur.

Q5: How do GPU and CPU coordinate?:

GPU rendering is asynchronous, bringing additional complexity:
- CPU works normally, GPU becomes bottleneck: Even if application main thread completes work within Vsync cycle, excessive GPU rendering time will still cause frame drops
- GPU Fence mechanism: In the latch stage, the critical sync point is usually acquire fence (when the Buffer is safe to read). present fence is more about when the frame is actually presented on display. With the system Latch Unsignaled Buffers strategy, SurfaceFlinger can move forward first under certain conditions, then wait on fence only when needed, hiding part of the latency.

Q6: What is the real role of Vsync Phase (phase difference)?:

Improve touch responsiveness: By adjusting sf vsync’s phase difference, the time from when an application starts drawing to displaying on screen can be shortened from 3 Vsync cycles to 2 Vsync cycles. This is very important for interaction scenarios like touch response.
Solve application drawing timeout issues: When application drawing times out, a reasonable sf phase difference can buy more processing time for the application, avoiding frame drops due to improper timing.
VsyncWorkDuration is closer to scheduling budget visualization (workDuration/readyDuration) and is not a 1:1 mapping to a single app offset value. Correlate it with vsync-app/sf and FrameTimeline.
The time period shown in the figure below is the app offset (13.3ms) configured on my phone

Technical Implementation of Vsync Offset / WorkDuration

In current AOSP main, the entry point is the VsyncConfiguration abstraction, which returns a VsyncConfigSet organized by scenario. Implementation-wise, PhaseOffsets is the legacy path, while WorkDuration is one of the common paths in newer systems:

// frameworks/native/services/surfaceflinger/Scheduler/VsyncConfiguration.h
class VsyncConfiguration {
public:
    virtual ~VsyncConfiguration() = default;
    virtual VsyncConfigSet getCurrentConfigs() const = 0;
    virtual VsyncConfigSet getConfigsForRefreshRate(Fps fps) const = 0;
    virtual void setRefreshRateFps(Fps fps) = 0;
    virtual void reset() = 0;
};

class WorkDuration : public VsyncConfiguration {
public:
    explicit WorkDuration(Fps currentRefreshRate);
    // Internally constructs offset configs from sf/app work durations
};

Key Concepts:

workDuration/readyDuration: scheduling budget and lead time used to compute callback wakeup
app/sf offset: still useful as an analysis lens, but it is an outcome of config sets plus scheduler model
In common practice, “app/sf offset delta” means their phase gap (often viewed as |sfOffset - appOffset|; sign conventions depend on device implementation and metric definition)

Actual Optimization Effects

Taking a 120Hz device as an example, the effect of configuring 3ms Offset:

Without Offset (Traditional Method):

T0: Application and SurfaceFlinger receive Vsync simultaneously
T0+3ms: Application completes rendering
T0+8.333ms: Next Vsync, SurfaceFlinger starts composition
T0+16.666ms: User sees the image (total latency 16.666ms)

With Offset (Optimized Method):

T0+1ms: Application receives Vsync-app, starts rendering
T0+3ms: Application completes rendering, submits Buffer
T0+4ms: SurfaceFlinger receives Vsync-sf, immediately starts composition
T0+6ms: SurfaceFlinger completes composition
T0+8.333ms: User sees the image (total latency 8.333ms)

Through reasonable Offset configuration, latency can be reduced from 16.666ms to 8.333ms, doubling response performance.

Actual Time Budget Allocation:

Taking a 120Hz device as an example (8.333ms cycle):

Ideal case: Application 4ms + SurfaceFlinger 2ms + buffer 2.333ms
But actually acceptable: Application 6ms + SurfaceFlinger 3ms (if there’s enough Buffer buffering)
GPU limitation: On low-end devices, GPU rendering may need 10-15ms, becoming the real bottleneck

Real Causes of Frame Drops:

Application timeout + Buffer exhaustion: Continuous multiple frame timeouts lead to no available Buffers in BufferQueue
GPU rendering timeout: Even if CPU work is normal, GPU rendering timeout will still cause frame drops
SurfaceFlinger timeout: System-level composition timeout affects all applications
System resource competition: CPU/GPU/memory and other resources occupied by other processes

Complete Code Flow of Vsync Signals

The complete chain of Vsync signals from hardware to application layer is as follows.

Key Code Paths Aligned with AOSP main (Condensed Excerpts)

The snippets below are aligned with current AOSP main method signatures, with non-essential branches/logging omitted.

1) Choreographer requests the next Vsync (Java)

// frameworks/base/core/java/android/view/Choreographer.java
private void scheduleFrameLocked(long now) {
    if (!mFrameScheduled) {
        mFrameScheduled = true;
        if (USE_VSYNC) {
            if (isRunningOnLooperThreadLocked()) {
                scheduleVsyncLocked();
            } else {
                Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
                msg.setAsynchronous(true);
                mHandler.sendMessageAtFrontOfQueue(msg);
            }
        }
    }
}

private void scheduleVsyncLocked() {
    mDisplayEventReceiver.scheduleVsync();
}

2) Choreographer receives Vsync (Java)

// frameworks/base/core/java/android/view/Choreographer.java
// TODO(b/116025192): physicalDisplayId is ignored because SF only emits VSYNC
// for the internal display and scheduleVsync only allows requesting internal VSYNC.
@Override
public void onVsync(long timestampNanos, long physicalDisplayId, int frame,
        VsyncEventData vsyncEventData) {
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    mLastVsyncEventData.copyFrom(vsyncEventData);
    Message msg = Message.obtain(mHandler, this);
    msg.setAsynchronous(true);
    mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}

@Override
public void run() {
    mHavePendingVsync = false;
    doFrame(mTimestampNanos, mFrame, mLastVsyncEventData);
}

3) JNI bridge: DisplayEventDispatcher (C++)

// frameworks/base/core/jni/android_view_DisplayEventReceiver.cpp
class NativeDisplayEventReceiver : public DisplayEventDispatcher {
public:
    NativeDisplayEventReceiver(JNIEnv* env, jobject receiverWeak, jobject vsyncEventDataWeak,
            const sp& messageQueue, jint vsyncSource,
            jint eventRegistration, jlong layerHandle);

private:
    void dispatchVsync(nsecs_t timestamp, PhysicalDisplayId displayId, uint32_t count,
            VsyncEventData vsyncEventData) override;
    void dispatchHotplug(nsecs_t timestamp, PhysicalDisplayId displayId, bool connected) override;
};

4) Native transport: DisplayEventReceiver + BitTube (C++)

// frameworks/native/libs/gui/DisplayEventReceiver.cpp
DisplayEventReceiver::DisplayEventReceiver(gui::ISurfaceComposer::VsyncSource vsyncSource,
        EventRegistrationFlags eventRegistration, const sp& layerHandle) {
    sf->createDisplayEventConnection(vsyncSource, ..., layerHandle, &mEventConnection);
    mDataChannel = std::make_unique();
    mEventConnection->stealReceiveChannel(mDataChannel.get());
}

status_t DisplayEventReceiver::requestNextVsync() {
    mEventConnection->requestNextVsync();
    return NO_ERROR;
}

ssize_t DisplayEventReceiver::getEvents(Event* events, size_t count) {
    return gui::BitTube::recvObjects(mDataChannel.get(), events, count);
}

5) SurfaceFlinger scheduling and distribution (C++)

1
2
3

// frameworks/native/services/surfaceflinger/Scheduler/VSyncDispatch.h
virtual std::optional schedule(
        CallbackToken token, ScheduleTiming scheduleTiming) = 0;

// frameworks/native/services/surfaceflinger/Scheduler/EventThread.cpp
void EventThread::onVsync(nsecs_t vsyncTime, nsecs_t wakeupTime, nsecs_t readyTime) {
    mPendingEvents.push_back(makeVSync(mVsyncSchedule->getPhysicalDisplayId(), wakeupTime,
            ++mVSyncState->count, vsyncTime, readyTime));
}

void EventThread::threadMain(std::unique_lock& lock) {
    ...
    const auto scheduleResult = mVsyncRegistration.schedule({
            .workDuration = mWorkDuration.get().count(),
            .readyDuration = mReadyDuration.count(),
            .lastVsync = mLastVsyncCallbackTime.ns(),
            .committedVsyncOpt = mLastCommittedVsyncTime.ns()});
    LOG_ALWAYS_FATAL_IF(!scheduleResult, "Error scheduling callback");
    ...
}

Key Timing Point Analysis

Through the above code flow, we can see the complete timing chain:

HWC emits hardware Vsync → SurfaceFlinger Scheduler captures display cadence
Scheduler computes wakeup window → VSyncDispatch::schedule(...)
EventThread creates/distributes events → DisplayEventReceiver::Event via BitTube
App-side Native receives event → DisplayEventDispatcher::dispatchVsync(...)
Java FrameDisplayEventReceiver callback → async message enters Looper queue
Choreographer#doFrame(...) executes → Input/Animation/Traversal/Commit

Each link has different responsibilities and optimization points. Understanding the complete process helps analyze Vsync-related performance issues in Perfetto.

FrameTimeline

Both App and SurfaceFlinger have FrameTimeline

Tracks: Expected Timeline, Actual Timeline
PresentType/JankType:
- PresentType indicates how this frame was presented (e.g., On-time, Late), JankType indicates jank type source
- Common JankType: AppDeadlineMissed, BufferStuffing, SfCpuDeadlineMissed, SfGpuDeadlineMissed, etc.
Operation Steps (Perfetto UI):
1. Select target Surface/Layer in application process or filter using FrameToken
2. Align Expected with Actual, view offset and color coding
3. Drill up: Choreographer#doFrame, RenderThread, queueBuffer, acquire/present_fence
Avoiding Misjudgment:
- Judging frame drops solely by doFrame duration is unreliable; use FrameTimeline’s PresentType/JankType as standard
- Multi-buffering may mask single frame timeout, need to look at consecutive frames and Buffer availability

Impact of Refresh Rate/Display Mode/VRR on Vsync and Offset/Prediction

Mode Switching: Refresh rate changes will reconfigure VsyncConfiguration, affecting app/sf Offset and prediction model;
- Perfetto: Check display mode change events and subsequent vsync interval changes
VRR (Variable Refresh Rate): Target cycle is not constant, software prediction relies more on present_fence feedback calibration;
- Perfetto: Observe vsync interval distribution and present_fence deviation
Multi-display/External Display: Hardware can report vsync per physicalDisplayId; however, app-side Choreographer usually still follows internal/pacesetter timing (details vary by branch and version). Confirm whether you’re reading HWC/SF tracks or app tracks before drawing conclusions;
- Version difference: official docs state per-display VSYNC was not supported on Android 10 and below; this limitation is removed at the framework/HWC capability level on Android 11+, but app-side Choreographer request paths still need branch-specific verification (AOSP main still has internal-display related notes)
- Perfetto: Filter related Counter/Slice by display ID

Perfetto Practice Checklist (Recommended Viewing Order)

Vsync Signal and Cycle
- Whether vsync-app / vsync-sf / vsync-appSf intervals are stable (60/90/120Hz corresponding cycles)
- Whether there are abnormally dense/sparse Vsyncs (prediction jitter)
Vsync Phase Difference Configuration
- Whether VsyncWorkDuration matches device’s expected app/sf Offset
- Whether app and sf sequence matches “draw first then composite” strategy
FrameTimeline Interpretation
- First look at PresentType, then JankType; confirm whether it’s app or SF/GPU side issue
- Select target Surface/FrameToken to locate specific frame
Application Main Thread and Render Thread
- Choreographer#doFrame each stage duration (Input/Animation/Traversal)
- Whether RenderThread‘s syncAndDrawFrame/DrawFrame duration is abnormal
BufferQueue and Fence
- Producer: After RenderThread queueBuffer, the Buffer enters the consumable queue. Whether SF can latch it immediately still depends on acquire fence. present fence is mainly for confirming when the frame is actually presented. Newer versions may advance with unsignaled buffers under specific policy, then wait later when needed.
- Consumer SF and BufferTX: At each composition beat, SF tries to fetch the latest available Buffer for a target layer. If BufferTX for a layer is 0, that layer usually has no new Buffer, so SF keeps composing with old content. For that app, this appears as visual stall/jank, but SF does not globally “stop composing.”
Composition Strategy and Display
- Whether SF frequently goes ClientComposition; whether HWC validate/present is abnormal
- Whether there’s obvious prediction deviation during multi-display/mode switching/VRR
Resources and Other Interference
- CPU competition (big core occupation), GPU busy, IO/memory jitter (GC/compaction)
- Whether other foreground apps/system services occupy key resources

References

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with you all. When three people walk together, one of them can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for support~

One person can go faster, a group of people can go further

Android Perfetto Series 7: MainThread and RenderThread Deep Dive

2025-08-02T02:11:45.000Z

This is the seventh article in the Perfetto series, focusing on MainThread (UI Thread) and RenderThread, the two most critical threads in any Android application. This article will examine the workflow of MainThread and RenderThread from Perfetto’s perspective, covering topics such as jank, software rendering, and frame drop calculations.

As Google officially promotes Perfetto as the replacement for Systrace, Perfetto has become the mainstream choice in performance analysis. This article combines specific Perfetto trace information to help readers understand the complete workflow of MainThread and RenderThread, enabling you to:

Accurately identify key trace tags: Understand the roles of critical threads like UI Thread and RenderThread
Understand the complete frame rendering process: Every step from Vsync signal to screen display
Locate performance bottlenecks: Quickly find the root cause of jank and performance issues through trace information

Series Catalog
Rendering Flow Analysis Based on Perfetto
Evolution of Dual-Thread Rendering Architecture
Main Thread Creation Process
ActivityThread Functionality
RenderThread Creation and Development
Performance
Perfetto’s Unique FrameTimeline Feature
Vsync Signals in Perfetto
References
Attachments
About Me && Blog

Series Catalog

If you haven’t read the Systrace series yet, here are the links:

Systrace Series Catalog: A systematic introduction to Systrace, Perfetto’s predecessor, and learning about Android performance optimization and Android system operation basics through Systrace.
Personal Blog: My personal blog, mainly Android-related content, with some life and work-related content as well.

The trace files used in this article have been uploaded to Github: https://github.com/Gracker/SystraceForBlog/tree/master/Android_Perfetto/demo_app_aosp_scroll.perfetto-trace, feel free to download them.

Note: This article is based on Android 16’s latest rendering architecture

Rendering Flow Analysis Based on Perfetto

Using a scrolling list as an example, we’ll capture the workflow of the main thread and render thread for one frame through Perfetto (each frame follows this process, though some frames have more work to do than others). In the Perfetto UI, focus on observing the activities of the “UI Thread” and “RenderThread” threads.

Frame Concept and Basic Parameters

Before analyzing Perfetto traces, you need to understand the basic concept of frames. The Android system refreshes screen content at fixed time intervals:

60Hz devices: Refresh every 16.67ms, 60 frames per second
90Hz devices: Refresh every 11.11ms, 90 frames per second
120Hz devices: Refresh every 8.33ms, 120 frames per second

When analyzing rendering performance in Perfetto, focus on these two threads:

UI Thread: The application main thread, handling user input, business logic, and layout calculations
RenderThread: The rendering thread, executing GPU rendering commands and interacting with SurfaceFlinger

Main Thread and RenderThread Workflow

Through the Perfetto screenshot above, you can see the complete rendering process for one frame. We can imagine the Perfetto diagram as a river: the main thread handles logic upstream, and the render thread executes drawing downstream. The river flows from left to right, with each segment representing a step.

Important Note: Not every frame executes all steps. Input, Animation, and Insets Animation are all on-demand. Traversal (measure, layout, draw) is also on-demand: only when requestLayout, invalidate, window attribute changes, or visibility changes happen will scheduleTraversals() post CALLBACK_TRAVERSAL. In continuous scrolling/animation scenarios, it often looks like it runs every frame.

Try to “play” this complete process in your mind through the following description:

1. Main Thread Waits for Vsync Signal

Perfetto trace: Main thread in Sleep state (shown as idle block)
Process description: Main thread waits for the vertical sync signal (Vsync) to arrive, ensuring rendering synchronizes with screen refresh rate to avoid screen tearing

2. Vsync-app Signal Delivery Process

Perfetto trace: vsync-app related events, SurfaceFlinger app thread activity
Process description: When hardware generates a Vsync signal, it’s first delivered to SurfaceFlinger. SurfaceFlinger’s app thread is awakened, responsible for managing and distributing Vsync signals to applications that need to render. This intermediary layer design allows for system-level Vsync scheduling and optimization

Important Notes:

Vsync-app is requested on-demand: Apps only receive vsync-app signals when actively requested; no request means no signal
Multi-app sharing mechanism: Multiple apps may request vsync-app signals simultaneously
Signal attribution issue: The vsync-app signal in SurfaceFlinger may be requested by other apps; if the currently analyzed app hasn’t requested it, there will be no frame output, which is normal

3. SurfaceFlinger Wakes Up App Main Thread

Perfetto trace: FrameDisplayEventReceiver.onVsync
Process description: SurfaceFlinger sends the Vsync signal to registered apps through the FrameDisplayEventReceiver mechanism. The app’s Choreographer receives the signal and begins the frame drawing process

4. Processing Input Events (Input)

Perfetto trace: Input block
Process description: Only executes when there are input events, mainly handling touch, scroll, and other user interactions
Trigger conditions:
- Has Input callback: When finger presses and slides on screen (like list scrolling, page dragging)
- No Input callback: During inertial scrolling after finger lift, static state
Note: Input callback is determined by the previous frame’s user interaction behavior to decide whether to execute in the current frame

5. Processing Animations (Animation)

Perfetto trace: Animation block
Process description: Only executes when animations need updating, updates animation state and current frame’s animation values
Trigger conditions:
- Has Animation callback: During inertial scrolling, property animations running, list item creation and content changes, page transition animations, etc.
- No Animation callback: Interface static state, pure Input interaction phase (when no animation effects)
Note: Animation callback is also determined by callbacks posted in the previous frame to decide whether to execute in the current frame

6. Processing Insets Animations

Perfetto trace: Insets Animation block
Process description: Only executes when window inset changes occur, handles window boundary animations
Trigger conditions:
- Has Insets Animation callback: Keyboard show/hide, status bar show/hide, navigation bar changes, etc.
- No Insets Animation callback: Window boundary stable state, most common interaction scenarios

7. Traversal (Measure, Layout, Draw Preparation)

Perfetto trace: performTraversals, measure, layout, draw
Process description: These are the three core UI rendering stages, but they do not run as a complete set on every Vsync. Execution depends on whether the current frame has layout/draw requests.

7.1 Measure Phase

Purpose: Determine the size of each View
Process: Starting from the root View, recursively measure the width and height of all child Views
Key concepts:
- MeasureSpec: Encapsulates parent container’s size requirements for child Views (EXACTLY, AT_MOST, UNSPECIFIED)
- onMeasure(): Each View overrides this method to implement its own measurement logic
Perfetto representation: measure event, duration depends on View hierarchy complexity

7.2 Layout Phase

Purpose: Determine each View’s position coordinates in the parent container
Process: Based on Measure phase results, assign actual display positions to each View
Key concepts:
- layout(left, top, right, bottom): Set View’s four boundary coordinates
- onLayout(): ViewGroup overrides this method to determine child View positions
Perfetto representation: layout event, usually faster than measure

7.3 Draw Phase

Purpose: Draw View content onto canvas
Modern implementation: Doesn’t directly draw pixels, but builds DisplayList (drawing instruction list)
Key process:
- draw(Canvas): Draw View’s own content
- onDraw(Canvas): Subclass overrides to implement specific drawing logic
- dispatchDraw(Canvas): ViewGroup uses this to draw child Views
Perfetto representation: draw event, mainly builds DisplayList under hardware acceleration

ViewRootImpl.performTraversals Core Code

// frameworks/base/core/java/android/view/ViewRootImpl.java
void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

private void performTraversals() {
    // ... a lot of window/relayout/visibility/sync logic
    boolean layoutRequested = mLayoutRequested && (!mStopped || mReportNextDraw);
    if (layoutRequested) {
        // may trigger measureHierarchy / performMeasure
    }

    final boolean didLayout = layoutRequested && (!mStopped || mReportNextDraw);
    if (didLayout) {
        performLayout(lp, mWidth, mHeight);
    }

    // draw only when conditions are met; canceled draws will reschedule traversal
    performDraw(mActiveSurfaceSyncGroup);
}

Note: In latest AOSP, performTraversals is much more complex (relayout, surface changes, sync groups, canceled draws, visibility, etc.). The snippet keeps only the flow directly related to Measure/Layout/Draw.

Execution conditions for the three phases:

Measure: Runs on first draw and when layout/configuration/insets/window changes require it, not fixed every frame
Layout: Runs when layoutRequested is true and the app is in a drawable state
Draw: Runs only when draw conditions are satisfied; canceled/pre-draw-blocked cases reschedule traversal

8. Sync DisplayList to Render Thread

Perfetto trace: syncAndDrawFrame, visible “sync” or “syncAndDrawFrame” event (usually shown as data transfer point from main thread to render thread)
Process description: Main thread syncs current-frame RenderNode/DisplayList state to RenderThread through syncAndDrawFrame. This is not pure fire-and-forget async: UI thread waits briefly for a key sync point (DrawFrameTask::postAndWait) and is then unblocked as early as possible; it does not wait until the frame is actually presented.

9. Render Thread Acquires Buffer

Perfetto trace: You can often observe DequeueBufferDuration / QueueBufferDuration related data (exact tags vary by Android version and OEM).
Process description: During draw submission, RenderThread goes through the ANativeWindow/RenderPipeline path for buffer acquire/swap. Whether it waits, and how long it waits, directly affects deadline miss risk.

10. Process Rendering Instructions and Flush to GPU

Perfetto trace: drawing related blocks
Process description: RenderThread (CPU side) processes the RenderNode tree synced from UI thread via HardwareRenderer/CanvasContext, builds GPU commands, and submits them. GPU executes asynchronously and produces fences for downstream composition sync.

11. Submit Buffer (Possibly Unsignaled)

Perfetto trace: queueBuffer (can observe acquireFence state)
Process description: Frame submission enters SurfaceFlinger through BufferQueue/BLAST. In some scenarios, unsignaled-fence behavior appears (policy-controlled), aiming to reduce end-to-end latency.

12. Trigger Transaction to SurfaceFlinger

Perfetto trace: TransactionQueue or BLAST transaction events, generally after queueBuffer, some traces don’t have this tag
Process description: App side associates buffer and layer-property updates via BLAST/SurfaceControl transactions and submits them to SurfaceFlinger. SurfaceFlinger then decides latch timing based on LatchUnsignaledConfig and related policies, composes, and presents.

Identifying different rendering modes in Perfetto:

During finger sliding: Each frame has complete Input → Traversal → RenderThread chain
During inertial scrolling: Each frame has Animation → Traversal → RenderThread, no Input
In static state: Occasionally appears Animation → Traversal → RenderThread, no Input

Software Drawing vs Hardware Acceleration

Although hardware-accelerated rendering is now basically standard, understanding the differences between the two rendering modes still helps understand Perfetto traces:

Aspect	Software Drawing	Hardware Acceleration
Drawing Thread	Main thread	RenderThread
Drawing Engine	Skia (CPU)	OpenGL/Vulkan (GPU)
Perfetto Characteristics	Main thread has large `draw` events	Main thread completes quickly, RenderThread handles drawing
Performance Impact	May block main thread	Asynchronous rendering, better performance

The above introduces the basic rendering process. For more detailed Choreographer principles, refer to Android Perfetto Series 5: Android App Rendering Flow Based on Choreographer.

Next, we’ll focus on in-depth content about the main thread and render thread:

Main thread development
Main thread creation
Render thread creation
Division of labor between main thread and render thread

Evolution of Dual-Thread Rendering Architecture

Android’s rendering system has undergone an important evolution from single-thread to dual-thread.

Single-Thread Era (Before Android 4.4)

In early Android versions, all UI-related work was executed on the main thread:

Processing user input events
Executing measure, layout, draw
Calling OpenGL for actual drawing
Interacting with SurfaceFlinger

Problems with this design:

Poor responsiveness: Main thread overloaded, prone to ANR
Performance bottleneck: CPU and GPU cannot work in parallel
Unstable frame rate: Complex interfaces easily cause frame drops

Dual-Thread Era (Starting from Android 5.0 Lollipop)

Android 5.0 introduced RenderThread, implementing separation of rendering work:

Main Thread Responsibilities:

Processing user input and business logic
Executing View’s measure, layout, draw
Building DisplayList (drawing instruction list)
Synchronizing data with render thread

Render Thread Responsibilities:

Receiving and processing DisplayList
Executing OpenGL/Vulkan rendering commands
Managing textures and rendering resources
Interacting with SurfaceFlinger

Advantages of this architecture:

Parallel processing: Main thread can process next frame while render thread works
Improved responsiveness: Main thread no longer blocked by rendering
Performance optimization: Better utilization of GPU resources

Main Thread Creation Process

Android App processes are Linux-based, and their management is also based on Linux process management mechanisms, so their creation also calls the fork function

frameworks/base/core/jni/com_android_internal_os_Zygote.cpp

1	pid_t pid = fork();

The forked process, we can consider it as the main thread here, but this thread hasn’t connected with Android yet, so it cannot handle Android App Messages; since Android App threads run based on the message mechanism, this forked main thread needs to bind with Android’s Message messaging to handle various Android App Messages.

This introduces ActivityThread. To be precise, ActivityThread should be named ProcessThread more appropriately. ActivityThread connects the forked process with App Messages, and their cooperation forms what we know as the Android App main thread. So ActivityThread is actually not a Thread, but it initializes the MessageQueue, Looper, and Handler required by the Message mechanism, and its Handler handles most Message messages, so we habitually think ActivityThread is the main thread, but it’s actually just a logical processing unit of the main thread.

ActivityThread Creation

After app process fork, the main path is:
ZygoteConnection.handleChildProc → ZygoteInit.zygoteInit → RuntimeInit.applicationInit → ActivityThread.main

com/android/internal/os/ZygoteConnection.java

private Runnable handleChildProc(ZygoteArguments parsedArgs, FileDescriptor pipeFd,
        boolean isZygote) {
    // ... omitted
    if (!isZygote) {
        return ZygoteInit.zygoteInit(parsedArgs.mTargetSdkVersion,
                parsedArgs.mDisabledCompatChanges,
                parsedArgs.mRemainingArgs, null /* classLoader */);
    } else {
        return ZygoteInit.childZygoteInit(parsedArgs.mRemainingArgs);
    }
}

For regular app processes, this goes through zygoteInit and eventually reaches ActivityThread.main. childZygoteInit is for child-zygote flow, not the normal app path.

android/app/ActivityThread.java

public static void main(String[] args) {
    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
    
    // 1. Initialize Looper, MessageQueue
    Looper.prepareMainLooper();
    
    // 2. Initialize ActivityThread
    long startSeq = 0;
    if (args != null) {
        for (int i = args.length - 1; i >= 0; --i) {
            if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
                startSeq = Long.parseLong(
                        args[i].substring(PROC_START_SEQ_IDENT.length()));
            }
        }
    }
    ActivityThread thread = new ActivityThread();
    
    // 3. Mainly calls AMS.attachApplicationLocked, syncs process info, does some initialization
    thread.attach(false, startSeq);
    
    // 4. Get main thread's Handler, which is H, basically all App Messages are processed in this Handler
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    
    // 5. Initialization complete, Looper starts working
    Looper.loop();
    
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

The comments are very clear, so I won’t elaborate here. After the main function finishes processing, the main thread is officially online and starts working.

ActivityThread Functionality

Also, what we often say is that Android’s four major components all run on the main thread. This is actually easy to understand by looking at ActivityThread’s Handler Messages

class H extends Handler { // Excerpt of some, based on Android 16 latest implementation
    public static final int BIND_APPLICATION        = 110; // Application startup
    public static final int CREATE_SERVICE          = 114; // Create Service
    public static final int BIND_SERVICE            = 121; // Bind Service
    public static final int RECEIVER                = 113; // Broadcast reception
    // ... and other four major component related message types
}

You can see that process creation, Activity startup, Service management, Receiver management, and Provider management are all handled here, then proceed to specific handleXXX

RenderThread Creation and Development

After discussing the main thread, let’s talk about the render thread, which is RenderThread. The earliest Android versions didn’t have a render thread; rendering work was all done on the main thread using CPU, calling the libSkia library. RenderThread was a new component added in Android Lollipop, responsible for taking on part of the main thread’s previous rendering work, reducing the main thread’s burden.

Software Drawing

What we generally refer to as hardware acceleration means GPU acceleration, which can be understood as using RenderThread to call GPU for rendering acceleration. Hardware acceleration is enabled by default in current Android, so if we don’t set anything, our processes will have both main thread and render thread by default (with visible content). If we add this to the Application tag in the App’s AndroidManifest:

1	android:hardwareAccelerated="false"

We can disable hardware acceleration. When the system detects that your App has disabled hardware acceleration, it won’t initialize RenderThread and will directly use CPU to call libSkia for rendering. Its Trace tracking performance is as follows (resources are older, using Systrace diagram)

Compared with the Perfetto diagram with hardware acceleration enabled at the beginning of this article, you can see that the main thread takes longer to execute because it needs to perform rendering work, making it more prone to jank. At the same time, the idle interval between frames becomes shorter, compressing the execution time of other Messages. In Perfetto, this difference can be clearly observed through the length and density of thread activity.

Hardware-Accelerated Drawing

Under normal circumstances, hardware acceleration is enabled. Main thread draw mainly builds/updates DisplayList (RenderNode tree), then syncs via syncAndDrawFrame. UI thread waits briefly on key sync path, returns quickly to process messages, and RenderThread continues rendering/submission.

Render Thread Initialization

Render thread initialization occurs when content actually needs to be drawn. Generally, when we start an Activity, during the first draw execution, it checks whether the render thread is initialized; if not, it proceeds with initialization

android/view/ViewRootImpl.java

// Render thread initialization
mAttachInfo.mThreadedRenderer.initializeIfNeeded(
        mWidth, mHeight, mAttachInfo, mSurface, surfaceInsets);

// Initialize BlastBufferQueue - App-side buffer manager
if (mBlastBufferQueue == null) {
    mBlastBufferQueue = new BLASTBufferQueue(mTag, mSurfaceControl,
        mSurfaceSize.x, mSurfaceSize.y,
        mWindowAttributes.format);
    mBlastBufferQueue.update(mSurfaceControl, 
        mSurfaceSize.x, mSurfaceSize.y, mWindowAttributes.format);
}

The BlastBufferQueue created here will play a key role in subsequent rendering processes:

Provides efficient Buffer management for RenderThread
Supports batch Transaction submission, reducing interaction overhead with SurfaceFlinger
QueuedBuffer metric changes can be observed in Perfetto

Subsequently, draw is called directly

android/view/ThreadedRenderer.java

mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {
    final Choreographer choreographer = attachInfo.mViewRootImpl.mChoreographer;
    choreographer.mFrameInfo.markDrawStart();

    // Update RootDisplayList, build RenderNode tree
    updateRootDisplayList(view, callbacks);

    // Process animated RenderNodes
    if (attachInfo.mPendingAnimatingRenderNodes != null) {
        final int count = attachInfo.mPendingAnimatingRenderNodes.size();
        for (int i = 0; i < count; i++) {
            registerAnimatingRenderNode(
                    attachInfo.mPendingAnimatingRenderNodes.get(i));
        }
        attachInfo.mPendingAnimatingRenderNodes.clear();
        attachInfo.mPendingAnimatingRenderNodes = null;
    }

    // Sync and draw frame, this triggers RenderThread work
    int syncResult = syncAndDrawFrame(choreographer.mFrameInfo);
    
    // Handle various result states
    if ((syncResult & SYNC_LOST_SURFACE_REWARD_IF_FOUND) != 0) {
        setEnabled(false);
        attachInfo.mViewRootImpl.mSurface.release();
        attachInfo.mViewRootImpl.invalidate();
    }
    if ((syncResult & SYNC_REDRAW_REQUESTED) != 0) {
        attachInfo.mViewRootImpl.invalidate();
    }
}

The draw above updates DisplayList first, then calls syncAndDrawFrame for the key UI Thread to RenderThread sync stage.

UI Thread and RenderThread DisplayList Synchronization Mechanism

In the syncAndDrawFrame key function, the following important synchronization operations occur:

// frameworks/base/libs/hwui/renderthread/RenderProxy.cpp
int RenderProxy::syncAndDrawFrame() {
    // 1. Sync UI Thread's DisplayList to RenderThread
    // This passes the RenderNode tree built by main thread to render thread
    return mDrawFrameTask.drawFrame();
}

syncAndDrawFrame is not fully non-blocking. In latest AOSP, DrawFrameTask::drawFrame() calls postAndWait(): it posts work to RenderThread queue and then waits on a condition variable; RenderThread unblocks UI at an appropriate sync point. So this is “wait a bit, unblock UI as early as possible”, not “UI never waits”.

// frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp
int DrawFrameTask::drawFrame() {
    mSyncResult = SyncResult::OK;
    mSyncQueued = systemTime(SYSTEM_TIME_MONOTONIC);
    postAndWait();   // key: UI waits here
    return mSyncResult;
}

void DrawFrameTask::postAndWait() {
    AutoMutex _lock(mLock);
    mRenderThread->queue().post([this]() { run(); });
    mSignal.wait(mLock);
}

The specific synchronization process includes:

RenderNode tree transfer: The RenderNode tree (containing DisplayList) built by the main thread during the draw process is passed to RenderThread
Property synchronization: View’s transformation matrices, transparency, clipping regions, and other properties are synchronized together
Resource sharing: Drawing resources like textures, Paths, and Paints establish sharing mechanisms between the two threads
Rendering state transfer: Rendering state information needed for the current frame is passed to RenderThread

This synchronization process is the core of Android hardware-accelerated rendering. It implements a division of labor where UI Thread focuses on logic processing and RenderThread focuses on rendering.

The core implementation of the render thread is in the libhwui library, with code located at frameworks/base/libs/hwui

RenderThread and BlastBufferQueue Interaction Flow

After RenderThread receives the synced DisplayList, it begins actual rendering work. During this process, it interacts closely with BlastBufferQueue:

// frameworks/base/libs/hwui/renderthread/CanvasContext.cpp
void CanvasContext::draw(bool solelyTextureViewUpdates) {
    // 1. calculate dirty region and prepare frame
    // 2. generate draw commands via mRenderPipeline->draw(...)
    // 3. submit via mRenderPipeline->swapBuffers(...)
    // 4. record dequeue/queue durations in FrameInfo
}

Note: The old intuitive flow (dequeueBuffer/queueBuffer/flushTransaction) is still useful as a mental model, but in latest mainline these details are consolidated into RenderPipeline/ANativeWindow path, and CanvasContext::draw() is no longer in the old shape.

Key Features of BlastBufferQueue:

App-side management: Unlike traditional BufferQueue created by SurfaceFlinger, BlastBufferQueue is created and managed by the App side
Reduced sync waiting: Through producer-consumer model, reduces RenderThread’s wait time during dequeueBuffer
Efficient buffer rotation: Supports smarter buffer management strategies, especially adapted for high refresh rate displays
Asynchronous submission: Asynchronously submits completed frames to SurfaceFlinger through transaction mechanism
Supports unsignaled buffer: Cooperating with SurfaceFlinger unsignaled-latch policies can reduce end-to-end latency in specific scenarios

In-depth Discussion on Latching Unsignaled Buffers

Modern Android systems have fine-grained control over presentFence handling, not always waiting. This mechanism is called “Latching Unsignaled Buffers” (capturing unready buffers).

Traditional mode: SurfaceFlinger must wait for App’s presentFence to be signaled by GPU before it can “latch” (capture) this Buffer for composition. This ensures safety but increases latency.
Latch Unsignaled mode: In this mode, SurfaceFlinger can immediately latch a Buffer that GPU hasn’t finished rendering (i.e., fence unsignaled) and start partial composition work early. When it needs to actually use this Buffer’s content, it waits for presentFence internally. This further hides GPU rendering latency through pipelining, crucial for reducing input latency in fullscreen apps like games and videos.

Control Switch and Policy (Android 13+):

This behavior can be globally debugged through system property debug.sf.auto_latch_unsignaled, but more importantly, it’s controlled by a layered policy called LatchUnsignaledConfig. A typical policy is AutoSingleLayer:

When only a single layer on screen is updating (like fullscreen games or videos), the system automatically enables Latch Unsignaled mode, as there are no complex layer dependencies at this time, lowest risk, maximum benefit.
When multiple layers are updating, the system falls back to safer traditional waiting mode to avoid potential visual errors.

Therefore, SurfaceFlinger doesn’t always blindly wait for presentFence, but decides whether to “jump the gun” based on precise policies, achieving a balance between stability and ultimate performance.

Division of Labor Between Main Thread and Render Thread

The main thread handles process Messages, Input events, Animation logic, Measure, Layout, Draw, and updates DisplayList, but doesn’t directly interact with SurfaceFlinger; the render thread handles rendering-related work, including interaction with BlastBufferQueue, GPU rendering command execution, and final interaction with SurfaceFlinger.

When hardware acceleration is enabled, in the Draw phase of Measure, Layout, Draw, Android uses DisplayList for drawing rather than directly using CPU to draw each frame. DisplayList is a record of a series of drawing operations, abstracted as the RenderNode class. The advantages of this indirect drawing operation are as follows:

DisplayList can be drawn multiple times on demand without interacting with business logic
Specific drawing operations (like translation, scale, etc.) can be applied to the entire DisplayList without redistributing drawing operations
When all drawing operations are known, they can be optimized: for example, all text can be drawn together at once
Processing of DisplayList can be transferred to another thread (i.e., RenderThread)
After sync ends, the main thread can process other Messages without waiting for RenderThread to finish
Through BlastBufferQueue, achieve more efficient buffer management, reducing rendering latency and main thread blocking

BlastBufferQueue Working Principle

BlastBufferQueue is a key component in modern Android rendering architecture, changing traditional buffer management methods:

Traditional BufferQueue vs BlastBufferQueue:

Different creation entities:
- Traditional BufferQueue: Created and managed by SurfaceFlinger
- BlastBufferQueue: Created and managed by App side (ViewRootImpl)
Buffer acquisition mechanism:
- Traditional method: RenderThread needs to request Buffer from SurfaceFlinger through Binder call, may block if no available Buffer
- BlastBufferQueue: App side pre-manages buffer pool, RenderThread can acquire Buffer more efficiently
Submission mechanism:
- Traditional method: Directly submits to SurfaceFlinger through queueBuffer
- BlastBufferQueue: Batch submits through transaction mechanism, reducing Binder call overhead

Observing BlastBufferQueue in Perfetto:

In Perfetto traces, BlastBufferQueue state is displayed through the following key metrics:

App-side QueuedBuffer Metric

Perfetto display: QueuedBuffer value track
AOSP definition (BLASTBufferQueue): QueuedBuffer = mNumFrameAvailable + mNumAcquired - mPendingRelease.size()
How to read it: This is a composite state metric, not a fixed-offset formula
Practical use: Focus on trend and duration, not one instantaneous value

QueuedBuffer Value Change Timing

QueuedBuffer +1 timing:

Common trigger: New buffer arrives into BLAST and becomes pending/processable
Perfetto representation: QueuedBuffer track rises
Meaning: Frame pressure between app side and SF side increases

QueuedBuffer -1 timing:

Trigger condition: Receives SurfaceFlinger’s releaseBufferCallback
Perfetto representation: Can observe releaseBuffer related events
Meaning: A buffer is consumed/handled and released, queue pressure drops

SurfaceFlinger-side BufferTX Metric

Perfetto display: BufferTX value track in SurfaceFlinger process
AOSP definition (Layer): This tracks per-layer mPendingBuffers; it increases when buffers arrive server-side and decreases when buffers are latched or dropped
Trigger condition: Depends on transaction and buffer lifecycle together; do not reduce it to “transaction received => +1”
Note: It is not a universal fixed-max-3 metric; behavior depends on layer type, producer-consumer pacing, and system policy

Collaboration Flow Between App Side and SF Side

App side: after frame submission, QueuedBuffer often rises
Cross-process: BLAST/SurfaceControl transaction associates updates with frameNumber and enters SF-side processing
SF side: BufferTX changes with pending-buffer lifecycle (arrive +, latch/drop -)
Backflow: releaseBufferCallback reaches app side and QueuedBuffer falls

Key Performance Observation Points

When analyzing performance, focus on:

App-side QueuedBuffer trend: Continuous rise without fallback often means producer-consumer mismatch; correlate with main-thread performTraversals and RenderThread DrawFrames to localize bottleneck
SurfaceFlinger-side BufferTX trend: Persistently high often indicates consumer-side pressure; persistently low while app keeps missing deadlines often points to producer-side starvation

Performance

If the main thread needs to handle all tasks, executing time-consuming operations (e.g., network access or database queries) will block the entire UI thread. Once blocked, the thread cannot dispatch any events, including drawing events. Main thread execution timeout typically brings two problems:

Jank: If main thread + render thread execution for each frame exceeds 8.33ms (in 120fps case), frame drops may occur (saying “may” because in some cases frames won’t actually drop, due to app duration, buffer accumulation, etc.).
Freeze: If the UI thread is blocked for more than a few seconds (this threshold varies depending on the component), users will see an “Application Not Responding“ (ANR) dialog (some manufacturers block this dialog and will directly crash to desktop)

For users, both situations are undesirable, so for App developers, both issues must be resolved before release. ANR is relatively easy to locate due to detailed call stacks; but intermittent jank may require tools for analysis: Perfetto + Trace View (already integrated in Android Studio). Therefore, understanding the relationship between main thread and render thread and their working principles is very important, which is also an original intention of this series.

Perfetto’s Unique FrameTimeline Feature

An important advantage of Perfetto over Systrace is providing the FrameTimeline feature, which allows you to see jank locations at a glance.

Note: FrameTimeline requires Android 12(S) or higher version support

Core Concepts of FrameTimeline

According to Perfetto official documentation, jank occurs when a frame’s actual presentation time on screen doesn’t match the scheduler’s expected presentation time. FrameTimeline adds two new tracks for each application with frames displayed on screen:

1. Expected Timeline

Purpose: Shows the rendering time window allocated by the system to the application
Start time: When Choreographer callback is scheduled to run
Meaning: To avoid system jank, the application needs to complete work within this time range

2. Actual Timeline

Purpose: Shows the actual time the application completed the frame (including GPU work)
Start time: When Choreographer#doFrame or AChoreographer_vsyncCallback starts running
End time: max(GPU time, Post time), where Post time is when the frame was submitted to SurfaceFlinger

When you click on a trace in Actual Timeline, it will show the specific consumption time for this frame (can see latency).

Color Coding System

FrameTimeline uses intuitive colors to identify different frame states:

Color	Meaning	Description
Green	Normal frame	No jank observed, ideal state
Light green	High latency state	Stable frame rate but delayed frame presentation, causing increased input latency
Red	Jank frame	Jank caused by current process
Yellow	App-blameless jank	Frame has jank but app is not the cause, jank caused by SurfaceFlinger
Blue	Dropped frame	SurfaceFlinger discarded this frame, chose newer frame

Clicking different colored ActualTimeline shows the following description in the info bar, telling you the cause of jank:

Jank Type Analysis

FrameTimeline can identify multiple jank types:

App-side jank:

AppDeadlineMissed: App runtime exceeded expectations
BufferStuffing: App sends new frame before previous frame presents, causing Buffer queue accumulation

SurfaceFlinger jank:

SurfaceFlingerCpuDeadlineMissed: SurfaceFlinger main thread timeout
SurfaceFlingerGpuDeadlineMissed: GPU composition time timeout
DisplayHAL: HAL layer presentation delay
PredictionError: Scheduler prediction deviation

Configuring FrameTimeline

Enable FrameTimeline in Perfetto configuration:

data_sources {
    config {
        name: "android.surfaceflinger.frametimeline"
    }
}

Vsync Signals in Perfetto

In Perfetto, Vsync signals are displayed using Counter type, which differs from many people’s intuitive understanding:

0 → 1 change: Represents a Vsync signal
1 → 0 change: Also represents a Vsync signal
Incorrect understanding: Many people mistakenly think only becoming 1 is a Vsync signal

Correct Vsync Signal Identification

In the diagram below, time points 1, 2, 3, 4 are all Vsync signal arrivals

Key points:

Each value change is a Vsync: Whether 0→1 or 1→0
Signal frequency: On 120Hz devices, there’s approximately one change every 8.33ms (actual may vary slightly due to system scheduling, referring to continuous frame output scenarios)
Multi-app scenario: Counter may remain active due to other apps’ requests

Analysis Techniques

Determining if App received Vsync:

Correct method: Check if there’s a corresponding FrameDisplayEventReceiver.onVsync event in the App process
Incorrect method: Judging solely by vsync-app counter changes in SurfaceFlinger

References

Attachments

The Perfetto trace files involved in this article have also been uploaded. You can download and open them in Perfetto UI (https://ui.perfetto.dev/) for analysis

Click this link to download the Perfetto trace files involved in this article

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with you all. When three people walk together, one of them can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for support~

One person can go faster, a group of people can go further

Android Perfetto Series 6: Why 120Hz? Advantages and Challenges

2025-04-26T06:13:38.000Z

This is the sixth article in the Android Perfetto series, mainly introducing knowledge related to 120Hz refresh rate on Android devices. Nowadays, 120Hz has become standard configuration for flagship Android phones. This article will discuss the advantages and challenges brought by high refresh rates, and analyze the working principle of 120Hz from a system perspective.

Over the past few years, the refresh rate of mobile device screens has evolved from 60Hz to 90Hz, and then to the now common 120Hz. This improvement not only brings smoother visual experience, but also puts forward new requirements for system architecture and application development. Through the Perfetto tool, we can more intuitively understand the process and performance of frame rendering on high refresh rate devices.

Perfetto Series Catalog
Basic Concepts
System Implementation and Principles
Advantages and Challenges of 120Hz
Thoughts and Future Outlook
Conclusion
About Me && Blog

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

Welcome everyone to join the WeChat group or Planet on the About Me page to discuss your problems, the parts about Perfetto you most want to see, and discuss all Android development related content with group friends.

Basic Concepts

What is Screen Refresh Rate?

Screen refresh rate is a hardware concept, referring to the number of times the screen refreshes the display content per second, in Hertz (Hz).

60Hz screen: Refresh 60 times per second, each refresh interval is about 16.67ms
90Hz screen: Refresh 90 times per second, each refresh interval is about 11.11ms
120Hz screen: Refresh 120 times per second, each refresh interval is about 8.33ms

The screen refresh rate determines the highest frame rate that the display device can display, but the screen is only responsible for displaying content at a fixed frequency, and the specific content displayed is determined by the software system.

What is FPS?

FPS (Frames Per Second) is a software concept, referring to how many frames of content the system generates per second for the screen to display.

60FPS: The system generates 60 frames of content per second, with about 16.67ms processing time per frame
90FPS: The system generates 90 frames of content per second, with about 11.11ms processing time per frame
120FPS: The system generates 120 frames of content per second, with about 8.33ms processing time per frame

To get the best visual experience, ideally FPS should match the screen refresh rate, but the actual experience is closely related to the content type and user perception:

Content Type Difference:
- Video Content: Movies (24fps) or videos (30fps) look smooth even on 120Hz screens because video content contains natural motion blur and matches viewer expectations for the medium.
- Interactive Interface: Scrolling lists, animations, and other interactive scenarios have higher requirements for frame rate. Dropping from 120fps to 110fps may be perceived as stuttering by users.
Frame Rate Stability: Stable low frame rate (such as stable 60fps) usually has a better experience than unstable high frame rate (such as fluctuating between 90-120fps).
System Behavior:
- When FPS is lower than the refresh rate, the display system will reuse frames or insert black frames.
- When FPS is higher than the refresh rate, excess frames will be discarded, causing waste of computing resources.

Different application scenarios have different smoothness standards, and developers need to choose appropriate optimization strategies according to the application type.

What is Vsync?

Vsync (Vertical Synchronization) is a mechanism that synchronizes software frame rate with screen refresh rate, aiming to avoid screen tearing phenomena. In Android systems, Vsync signals are used to trigger the timing for applications to render a new frame, ensuring that the rendering process remains consistent with the screen refresh cycle.

Why 120Hz Became the New Standard?

The evolution of the market from 60Hz to 90Hz and then to 120Hz has clear technical and user experience driving factors:

Higher Smoothness: 120Hz provides twice the visual information of 60Hz, making scrolling, animation, and other interactions feel more fluid and natural.
Reduced Latency: The delay from input event to display result is reduced from 16.67ms at 60Hz to 8.33ms at 120Hz, making user operation feedback more timely.
Mature Hardware Support: Modern mobile processors (such as Qualcomm Snapdragon 8 series, MediaTek Dimensity series) have enough performance to support stable operation of 120Hz.
Battery Technology Progress: More efficient battery and power management technologies alleviate the power consumption pressure brought by high refresh rates.
Variable Refresh Rate Technology: Adaptive refresh rate technologies like LTPO allow devices to intelligently switch refresh rates in different scenarios, balancing smoothness and power consumption.

Nowadays, 120Hz is not only standard for Android flagship models, but even iOS devices (iPhone 13 Pro and above) also support 120Hz ProMotion technology, marking that high refresh rate has become a basic feature of high-end mobile devices.

System Implementation and Principles

120Hz Rendering Process from Perfetto’s Perspective

At 120Hz refresh rate, the rendering process of the Android system has not changed fundamentally. The main difference is that the time budget for each frame is shortened from 16.67ms to 8.33ms (Of course, App duration is not discussed here. If App Duration configuration is greater than 8.33ms, then it is acceptable for App’s UI + Render to be completed within the App duration interval. Note that App Duration configuration varies by machine). The specific rendering Perfetto trace of the application in 120Hz environment is shown below:

On 120Hz devices, we can see:

Vsync Interval: VSYNC signal triggers once every 8.33ms
Frame Processing Flow: Processing of each frame still follows the order of Input → Animation → Traversal
Time Compression: All processing steps must be completed in a shorter time, placing higher demands on system and application performance

Two Buffer-related Traces appear in the figure above. Here is a brief explanation:

QueuedBuffer: (e.g., QueuedBuffer - VRI[ImproveSnsTimelineUI]#748BLAST#748)
- This Trace Tag is printed in the App Process
- Indicates that the application has finished rendering one frame and put the rendered Buffer into the queue preparing to submit to SurfaceFlinger
- In systems using BlastBufferQueue, this moment marks that RenderThread completes rendering and is ready to transmit the result to system service
BufferTX: (e.g., BufferTX - com.tencent.mm/com.tencent.mm.plugin.sns.ui.improve.ImproveSnsTimelineUI#47974)
- This Trace Tag is printed in the SurfaceFlinger Process
- Indicates the moment SurfaceFlinger receives the Buffer transmitted from the application and starts processing
- TX stands for “Transfer/Transmission”, implying the transmission process of the buffer

The correct process should be:

App’s RenderThread calls queueBuffer. At this time, the App considers itself to have handed over a Buffer, so QueuedBuffer +1.
The Buffer is transmitted to SF. After SF receives (latch/acquire) it, BufferTX +1.
SF uses this Buffer to complete composition and display on screen in a future Vsync cycle.
When SF no longer needs this Buffer (for example, it has been replaced by a new frame, or has been stably displayed for enough time), SF will release this Buffer.
After SF releases the Buffer, BufferTX -1. At the same time, the App will receive a callback that the Buffer has been released. At this time, the App side’s QueuedBuffer will only -1, indicating that this Buffer has successfully returned to the buffer pool and can be used again.

Perfetto also provides Buffer tracking function. Click Actual Timeline above App (this part of knowledge can be seen at Actual Timeline Introduction), and you can see the whole process of this Buffer from production to consumption.

System Architecture Optimization Supporting 120Hz

To support 120Hz high refresh rate smoothly, Android system architecture has made many adjustments and improvements. These changes involve multiple components, covering important optimizations of the entire rendering pipeline. Let’s look at several key technical points in detail:

Adaptive Refresh Rate Technology

Modern Android devices adopt multi-level refresh rate management strategies:

Hardware Layer Support: LTPO (Low Temperature Polycrystalline Oxide) display technology allows the screen to precisely adjust refresh rate within the range of 1Hz to 120Hz, rather than switching between fixed gears.
Content Perception Algorithm: The system automatically adjusts refresh rate by analyzing screen content types:
- Static content (reading, picture browsing): Drop to 10-30Hz
- Video playback: Match video source frame rate (usually 24-60Hz)
- Scrolling and interaction: Increase to 90-120Hz
- Games: Dynamically adjust according to game engine output frame rate
API Support: Android provides Surface.setFrameRate() API, allowing applications to explicitly specify their preferred frame rate, and the system will try its best to meet this request.

1 2	// Application can specify preferred frame rate and refresh rate behavior surface.setFrameRate(60.0f, Surface.FRAME_RATE_COMPATIBILITY_DEFAULT);

Advantages and Challenges of 120Hz

Experience Improvements Brought by 120Hz

When I got my first 120Hz mobile phone, the most intuitive feeling was:

Everything becomes smoother: From desktop sliding, application switching to browsing Weibo, screen updates are more frequent, and content follows finger movement more accurately. Especially when quickly sliding Moments or Weibo feed stream, the text is still clear and distinguishable, rather than a blur.
Game experience greatly improved: When playing competitive games like “Honor of Kings” or “Peacekeeper Elite”, the improvement in screen smoothness also improves my operation accuracy. In fierce confrontation, being able to see enemy actions 8ms earlier, although the time is short, does bring advantages.
Reduced eye fatigue: This may be a personal feeling, but staring at a 120Hz screen for a long time is indeed more comfortable than 60Hz, especially when reading and sliding content, the burden on eyes tracking content is reduced.
More precise touch experience: 120Hz is not only fast display update, but touch sampling rate usually also increases, making operation response more timely, whether typing or fine control is more accurate.

Practical Problems Faced by 120Hz

Of course, high refresh screens also bring a series of technical challenges:

Power consumption problem: In actual measurement, the same mobile phone consumes about 15-20% more power in 120Hz mode than in 60Hz. For the already tight mobile phone battery life, this is not a small pressure.
Increased development threshold: Applications that could barely run in 60Hz environment may appear stuck when reaching 120Hz. Each frame has only 8.33ms processing time, which puts higher requirements on developer’s code efficiency.
Increased heating: Running high frame rate games for a long time, mobile phone heating is significantly more serious than 60Hz, which not only affects experience but may also lead to performance throttling.
Application adaptation is not perfect: Many applications have not been optimized for high brush. Even on 120Hz screens, the actual output frame rate may still be 60fps, wasting screen potential.

Thoughts and Future Outlook

On-Demand Adjustment: Intelligent Management of Refresh Rate from ProMotion

As 120Hz high refresh rate gradually becomes standard for flagship mobile phones, a question worth thinking about is: Do we really need to maintain 120Hz refresh rate in all scenarios?

Apple’s ProMotion technology actually gives a more reasonable answer: Activate high refresh rate only in animation scenarios with high perception, while appropriately reducing refresh rate in other scenarios to save power.

From the figure above, we can see that Apple provides very detailed ProMotion frame rate recommended configurations for different types of animation scenarios in iOS developer documentation:

High-impact animations:
- Applicable scenarios: Full screen transition (such as expanding when clicking thumbnail in Photos app), first-person games, Sheet popup display, etc.
- Recommended frame rate: 80-120Hz, preferred 120Hz (CAFrameRateRange(minimum:80, maximum:120, preferred:120))
- Usage suggestion: Use with caution, apply only in key interaction scenarios to reduce power consumption
Opacity/Color transition and micro movement:
- Applicable scenarios: Switch state change, progress indicator rotation, background blur effect, etc.
- Recommended frame rate: Use system default frame rate range (CAFrameRateRange.default)
- Usage suggestion: These animations do not need excessively high frame rate, visual effect difference is not big
Low speed small animation:
- Applicable scenarios: Clock pointer movement, slow progress bar, etc.
- Recommended frame rate: Depending on animation speed, choose 8-15Hz, 15-24Hz or 30-48Hz, etc.
- Usage suggestion: Low frame rate visual effect is good enough in these scenarios, and can significantly save power
All other cases:
- Recommended using system default frame rate

This refined frame rate management strategy not only allows the system to achieve the best balance between user experience and battery life, but also provides clear guidance for developers. Compared with simply and crudely using 120Hz globally, this targeted frame rate adjustment scheme is obviously more scientific and efficient.

Trade-off Between Power and Experience

Tests show that reducing refresh rate from 120Hz to 60Hz can save about 10-15% of power. Intelligently controlling refresh rate can significantly extend battery life while maintaining good user experience.

The main value of 120Hz lies in improving interaction smoothness and response speed, rather than always maintaining high refresh rate. A smarter approach is to dynamically adjust according to actual needs: Use high refresh rate in scenarios sensitive to user perception, and reduce refresh rate in scenarios insensitive to user perception.

Developer’s Adaptation Strategy

App developers should realize that not all content needs to be rendered at the highest frame rate. Through APIs provided by Android (such as Surface.setFrameRate()), appropriate frame rates can be specified for different content types, cooperating with the system’s adaptive refresh rate mechanism to achieve the best balance of performance and power.

In short, the future development direction of high refresh rate technology should be more intelligent and refined adaptive adjustment, rather than simply pursuing higher numbers. True technological progress is finding the best balance point between experience and energy efficiency without user perception.

Conclusion

Looking back at the development of high refresh screens in the past few years, I think 120Hz is indeed an important leap in mobile phone interaction experience. Although it brings challenges such as power consumption and development complexity, the benefits are obvious: smoother experience, lower input latency, and more natural animation effects.

For developers, tools like Perfetto allow us to see performance problems under 120Hz clearly and carry out targeted optimization. Although the budget reduction from 16ms to 8ms sounds tight, in fact mainstream processors already have enough ability to cope with this challenge. As long as UI complexity is planned reasonably and main thread blocking is avoided, smooth 120fps experience is completely achievable.

From the trend point of view, I don’t think mobile phone screen refresh rate will climb indefinitely. 120Hz may become the standard for a long time, and the future focus will be more on how to intelligently adjust refresh rate to find the best balance between experience and power consumption in different scenarios. After all, what we pursue is not high numbers, but good actual experience.

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
This Blog Content Navigation: A navigation of personal blog content.
Personal Collection of Excellent Blog Articles - Android Performance Optimization Must-Know: Welcome everyone to recommend themselves and others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

One person can go faster, a group of people can go further

Android Perfetto Series 5: Choreographer-based Rendering Flow

2025-03-26T10:55:11.000Z

This article introduces Choreographer, a class that App developers may not frequently encounter but is critically important in the Android Framework rendering pipeline. We will cover the background of its introduction, a brief overview, partial source code analysis, its interaction with MessageQueue, its application in APM (Application Performance Monitoring), and some optimization ideas for Choreographer by mobile phone manufacturers.

The introduction of Choreographer is mainly to cooperate with Vsync to provide a stable Message processing timing for upper-layer application rendering. When the Vsync signal arrives, the system controls the timing of each frame’s drawing operation by adjusting the Vsync signal cycle. Currently, the screen refresh rate of mainstream mobile phones has reached 120Hz, which means refreshing once every 8.3ms. The system adjusts the Vsync cycle accordingly to match the screen refresh frequency. When each Vsync cycle arrives, the Vsync signal wakes up the Choreographer to execute the application’s drawing operation. This is the main purpose of introducing Choreographer. Understanding Choreographer can also help application developers deeply understand the operating principle of each frame, and at the same time deepen their understanding of core components such as Message, Handler, Looper, MessageQueue, Input, Animation, Measure, Layout, and Draw. Many APM (Application Performance Monitoring) tools also utilize the combination mechanisms of Choreographer (via FrameCallback), FrameMetrics/gfxinfo framestats (internally backed by FrameInfo), MessageQueue (via IdleHandler), and Looper (via custom MessageLogging) for performance monitoring. After deeply understanding these mechanisms, developers can conduct performance optimization more specifically and form systematic optimization ideas.

Perfetto Series Catalog
The Essence of Main Thread Execution
Introduction to Choreographer
Source Code Analysis
MessageQueue and Choreographer
APM and Choreographer
Manufacturer Optimizations
Reference Materials
Zhihu Address
About Me & Blog

This is the fifth article in the Perfetto series, mainly giving a brief introduction to Choreographer in Perfetto.

The purpose of this series is to view the overall operation of the Android system from another perspective through the Perfetto tool, and also to learn about the Framework from a different angle. Maybe you have read many articles about the Framework, but always can’t remember the code, or are not clear about its running process. Perhaps from the graphical perspective of Perfetto, you can understand it more deeply.

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduces the use of Systrace, the predecessor of Perfetto, and learns and understands the basic rules of Android performance optimization and Android system operation through Systrace.
Systrace version of this article: Detailed Explanation of Android Choreographer-based Rendering Mechanism
Personal Blog: Personal blog, mainly Android-related content, also contains some life and work-related content.

Everyone is welcome to join the WeChat group or Planet on the About Me page to discuss your questions, the parts of Perfetto you most want to see, and discuss all Android development-related content with other group members.

The Essence of Main Thread Execution

Before discussing Choreographer, let’s first clarify the essence of Android’s main thread operation, which is actually the processing process of Messages. Our various operations, including the rendering operations of each frame, are sent to the MessageQueue of the main thread in the form of Messages. The MessageQueue continues to wait for the next message after processing the current one, as shown in the figure below.

MethodTrace Illustration

Perfetto Illustration

Evolution

In Android versions before the introduction of Vsync, there was no interval between Messages related to rendering a frame. As soon as the previous frame was drawn, the Message for the next frame began to be processed immediately. The problem with this was that the frame rate was unstable, potentially high or low, as shown below:

MethodTrace Illustration

Trace Illustration (Resource is relatively old, using Systrace illustration)

It can be seen that the bottleneck at this time was in dequeueBuffer. Because the screen has a refresh cycle, the speed at which FB consumes the Front Buffer is constant, so the speed at which SF consumes the App Buffer is also constant. Therefore, the App would get stuck at dequeueBuffer. This would lead to unstable acquisition of the App Buffer, easily causing stuttering and dropped frames.

For users, a stable frame rate is a good experience. For example, when playing Honor of Kings, compared to frequent fluctuations between 60 and 40 fps, users feel better when it is stable at 50 fps.

Therefore, in the evolution of Android, the mechanism of Vsync + TripleBuffer + Choreographer was initially introduced. Later, starting from Android R (Android 11), BlastBufferQueue was introduced and then continuously refined, jointly forming the modern Android stable frame rate output mechanism, allowing the software layer and hardware layer to work together at a common frequency.

Introducing Choreographer

Of course, the refresh rate of mainstream flagship mobile phones has reached 120Hz, and the Vsync cycle has been shortened to 8.3ms. The operations in the above figure must be completed in a shorter time, and the performance requirements are getting higher and higher. For details, please refer to the article New Smooth Experience, 90Hz Rambling (although the article discusses 90Hz, the same principle applies to 120Hz).

Introduction to Choreographer

Choreographer plays a connecting role in the Android rendering pipeline.

Upstream connection: Responsible for receiving and processing various update messages and callbacks from the App, and processing them uniformly when Vsync arrives. For example, centralized processing of Input (mainly processing of Input events), Animation (animation related), Traversal (including measure, layout, draw, etc. operations), judging stuck frames and dropped frames, recording Callback time consumption, etc.
Downstream connection: Responsible for requesting and receiving Vsync signals. Receive Vsync event callbacks (via FrameDisplayEventReceiver.onVsync); Request Vsync (FrameDisplayEventReceiver.scheduleVsync).

From the above, it can be seen that Choreographer plays a key coordinator role in the Android rendering pipeline. Its importance lies in ensuring that Android applications can run at a stable frame rate (60 fps, 90 fps, or 120 fps) through the complete rendering mechanism of Choreographer + SurfaceFlinger + Vsync + BlastBufferQueue, effectively reducing visual discomfort caused by frame rate fluctuations.

Understanding Choreographer can also help application developers deeply understand the operating principle of each frame, and at the same time deepen their understanding of core components such as Message, Handler, Looper, MessageQueue, Input, Animation, Measure, Layout, and Draw. Many APM (Application Performance Monitoring) tools also utilize the combination mechanisms of Choreographer (via FrameCallback), FrameMetrics/gfxinfo framestats (internally backed by FrameInfo), MessageQueue (via IdleHandler), and Looper (via custom MessageLogging) for performance monitoring. After deeply understanding these mechanisms, developers can conduct performance optimization more specifically and form systematic optimization ideas.

In addition, although charts are an effective way to explain processes, this article will rely more on the visual output of Perfetto and MethodTrace tools. Perfetto displays the operating status of the entire system in a timeline manner (from left to right), covering the activities of key components such as CPU, SurfaceFlinger, SystemServer, and application processes. Using Perfetto and MethodTrace can intuitively display key execution processes. Once you are familiar with the system code, Perfetto’s output can be directly mapped to the actual running status of the device. Therefore, in addition to citing a small number of network charts, this article mainly relies on Perfetto to display analysis results.

Choreographer’s Workflow from the Perspective of Perfetto

The figure below uses sliding the settings interface as an example. Let’s first look at a complete preview of the settings interface from top to bottom. It can be seen that in Perfetto, from left to right, each green frame represents a frame, representing the picture we can finally see on the phone.

The interval of each VSYNC-app value in the figure is a Vsync time, corresponding to the refresh rate of the current device, such as 16.6ms at 60Hz and 8.3ms at 120Hz. The rising edge or falling edge is the arrival time of Vsync.
Processing flow of each frame: Receive Vsync signal callback -> UI Thread –> RenderThread –> SurfaceFlinger
UI Thread and RenderThread can complete one App frame. In Android 11 and above, the rendered buffer is submitted via the BlastBufferQueue path to SurfaceFlinger for composition, and then we can see the frame on screen.
It can be seen that the time consumption of each frame of Settings sliding is very short (Ui Thread time consumption + RenderThread time consumption), but due to the existence of Vsync, each frame will wait until Vsync to be processed.

With the overall concept above, let’s zoom in on each frame of the UI Thread to see the position of the Choreographer and how the Choreographer organizes each frame.

Choreographer’s Workflow

Choreographer Initialization
Initialize FrameHandler, bind Looper
Initialize FrameDisplayEventReceiver, establish communication with SurfaceFlinger for receiving and requesting Vsync
Initialize CallBackQueues
SurfaceFlinger’s appEventThread wakes up and sends Vsync, Choreographer callbacks FrameDisplayEventReceiver.onVsync, entering Choreographer’s main processing function doFrame
Choreographer.doFrame calculates frame drop logic
Choreographer.doFrame processes Choreographer’s first callback: input
Choreographer.doFrame processes Choreographer’s second callback: animation
Choreographer.doFrame processes Choreographer’s third callback: insets animation
Choreographer.doFrame processes Choreographer’s fourth callback: traversal
UIThread and RenderThread synchronize data in traversal-draw
Choreographer.doFrame processes Choreographer’s fifth callback: commit
RenderThread processes drawing commands
In Android 11 and above, RenderThread submits drawing content to SurfaceFlinger through BlastBufferQueue (with implementation details evolving across releases)
BlastBufferQueue is created and managed by the App side
Works through producer (BBQ_BufferQueue_Producer) and consumer (BufferQueue_Consumer) models
The probability and duration of UI-thread waiting are usually reduced, so the next frame can often be prepared earlier (still depends on concrete sync points)

After the first step of initialization is completed, subsequent steps will loop between steps 2-10

Also attached is the MethodTrace corresponding to this frame (just a preview here, there will be a detailed large picture below)

Interaction between Choreographer, RenderThread and BlastBufferQueue

Starting from Android R (Android 11), the interaction between RenderThread and SurfaceFlinger underwent important changes, with BlastBufferQueue and its subsequent evolution at the core. Let’s see how this mechanism works.

BlastBufferQueue Working Principle

BlastBufferQueue is a BufferQueue variant optimized for UI rendering. It replaces the BufferQueue strictly created by SurfaceFlinger and is instead created and managed by the App side, used for buffer management between App and SurfaceFlinger.

More efficient buffer management
In the traditional BufferQueue, the App needs to get an available buffer through dequeueBuffer, then render content, and finally submit the buffer to SurfaceFlinger through queueBuffer. In this process, if there is no available buffer, the App needs to wait, which leads to blocking.
BlastBufferQueue reduces this waiting through smarter buffer management, especially on high refresh rate devices, the effect is more obvious.
Decoupling of RenderThread and UI Thread
In older implementations, the UI thread and the buffer submission path were more tightly coupled, so the main thread was more likely to wait at key synchronization points. After BlastBufferQueue and later refinements, the UI thread can usually finish Java-side work earlier and move to next-frame preparation sooner, reducing main-thread blocking risk (still scenario-dependent).

Creation Mechanism
BlastBufferQueue is created during the relayoutWindow process of ViewRootImpl:

// Example code for creating BBQ
if (mBlastBufferQueue == null) {
    mBlastBufferQueue = new BLASTBufferQueue(mTag, mSurfaceControl,
        mSurfaceSize.x, mSurfaceSize.y,
        mWindowAttributes.format);
}

Cooperation with Choreographer
Choreographer is still the core that coordinates all this. When the Vsync signal arrives, Choreographer will trigger doFrame and execute various callbacks, among which CALLBACK_TRAVERSAL will trigger ViewRootImpl‘s performTraversals(), eventually going to the draw process.
In the draw process, through BlastBufferQueue, RenderThread can work more independently, and the UI thread can return earlier to process other tasks.

Below we will look at the specific implementation from the perspective of source code.

Source Code Analysis

Below is a brief look from the source code perspective. The source code only excerpts some important logic, other logic is removed. In addition, the Native part interacting with SurfaceFlinger is not included, which is not the focus of this article. Those interested can follow it themselves. The following source code is based on AOSP mainline (frameworks/base HEAD, verified in 2026-02). Details may vary across Android releases.

Choreographer Initialization

Choreographer Singleton Initialization

// Thread local storage for the choreographer.
private static final ThreadLocal sThreadInstance =
        new ThreadLocal() {
    @Override
    protected Choreographer initialValue() {
        // Get Looper of current thread
        Looper looper = Looper.myLooper();
        if (looper == null) {
            throw new IllegalStateException("The current thread must have a looper!");
        }
        // Construct Choreographer object, use VSYNC_SOURCE_APP as Vsync source
        Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
        if (looper == Looper.getMainLooper()) {
            mMainInstance = choreographer;
        }
        return choreographer;
    }
};

Choreographer Constructor

private Choreographer(Looper looper, int vsyncSource) {
    mLooper = looper;
    // 1. Initialize FrameHandler
    mHandler = new FrameHandler(looper);
    // 2. Initialize DisplayEventReceiver
    mDisplayEventReceiver = USE_VSYNC
            ? new FrameDisplayEventReceiver(looper, vsyncSource)
            : null;
    mLastFrameTimeNanos = Long.MIN_VALUE;
    mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
    //3. Initialize CallbacksQueues
    mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
    for (int i = 0; i <= CALLBACK_LAST; i++) {
        mCallbackQueues[i] = new CallbackQueue();
    }
    ......
}

FrameHandler

private final class FrameHandler extends Handler {
    ......
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_DO_FRAME:// Start operation for the next frame
                doFrame(System.nanoTime(), 0);
                break;
            case MSG_DO_SCHEDULE_VSYNC:// Request Vsync 
                doScheduleVsync();
                break;
            case MSG_DO_SCHEDULE_CALLBACK:// Handle Callback
                doScheduleCallback(msg.arg1);
                break;
        }
    }
}

Choreographer Initialization Chain

During the Activity startup process, after onResume is executed, Activity.makeVisible() is called, and then addView() is called. The calls layer by layer enter the following method:

ActivityThread.handleResumeActivity(IBinder, boolean, boolean, String) (android.app) 
-->WindowManagerImpl.addView(View, LayoutParams) (android.view) 
  -->WindowManagerGlobal.addView(View, LayoutParams, Display, Window) (android.view) 
    -->ViewRootImpl.ViewRootImpl(Context, Display) (android.view) 
    public ViewRootImpl(Context context, Display display) {
        ......
        mChoreographer = Choreographer.getInstance();
        ......
    }

Introduction to FrameDisplayEventReceiver

Vsync registration, application, and reception are all done through the FrameDisplayEventReceiver class, so let’s introduce it simply first. FrameDisplayEventReceiver inherits from DisplayEventReceiver and has three important methods:

onVsync – Vsync signal callback
run – Execute doFrame
scheduleVsync – Request Vsync signal

private final class FrameDisplayEventReceiver extends DisplayEventReceiver implements Runnable {
    ......
    @Override
    public void onVsync(long timestampNanos, long physicalDisplayId, int frame, VsyncEventData eventData) {
        ......
        mTimestampNanos = timestampNanos;
        mFrame = frame;
        // VsyncEventData already existed in Android 13/14; newer versions further expanded fields
        mVsyncEventData = eventData;
        Message msg = Message.obtain(mHandler, this);
        msg.setAsynchronous(true);
        mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
    }
    @Override
    public void run() {
        mHavePendingVsync = false;
        doFrame(mTimestampNanos, mFrame, mVsyncEventData);
    }
    
    public void scheduleVsync() {
        ......  
        nativeScheduleVsync(mReceiverPtr);
        ......
    }
}

Vsync Registration in Choreographer

From the function call stack below, we can see that Choreographer‘s inner class FrameDisplayEventReceiver.onVsync is responsible for receiving Vsync callbacks and notifying UIThread to process data.

So how does FrameDisplayEventReceiver callback onVsync when the Vsync signal arrives? The answer is that during the initialization of FrameDisplayEventReceiver, it finally listens to the file handle. The corresponding initialization process is as follows:

android/view/Choreographer.java

private Choreographer(Looper looper, int vsyncSource) {
    mLooper = looper;
    mDisplayEventReceiver = USE_VSYNC
            ? new FrameDisplayEventReceiver(looper, vsyncSource)
            : null;
    ......
}

android/view/Choreographer.java

1
2
3

public FrameDisplayEventReceiver(Looper looper, int vsyncSource) {
    super(looper, vsyncSource);
}

android/view/DisplayEventReceiver.java

public DisplayEventReceiver(Looper looper, int vsyncSource) {
    ......
    mMessageQueue = looper.getQueue();
    mReceiverPtr = nativeInit(new WeakReference(this), mMessageQueue,
            vsyncSource);
}

Simply put, during the initialization of FrameDisplayEventReceiver, Vsync events are passed and requested through BitTube (essentially a socket pair). After SurfaceFlinger receives the Vsync event, it passes this event to DisplayEventDispatcher through BitTube via appEventThread. After DisplayEventDispatcher listens to the Vsync event through the receiver end of BitTube, it callbacks Choreographer.FrameDisplayEventReceiver.onVsync, triggering the start of frame drawing, as shown in the figure below:

DisplayEventReceiver Communication Details with SurfaceFlinger

In the Android system, DisplayEventReceiver calls the nativeInit method via JNI to establish a communication channel with the SurfaceFlinger service. This process involves several key steps:

Create NativeDisplayEventReceiver Object: After calling nativeInit in the Java layer, JNI creates a NativeDisplayEventReceiver instance for receiving Vsync signals.
Get IDisplayEventConnection: Get IDisplayEventConnection via ISurfaceComposer interface. This is a Binder interface used to communicate with the SurfaceFlinger service.
Establish BitTube Connection: BitTube is a communication mechanism based on socket pair, designed for high-frequency, small-data-volume cross-process communication. It creates an efficient communication channel between the App process and the SurfaceFlinger process.
File Descriptor Listening: Listen to the file descriptor of BitTube via Looper. When a Vsync signal arrives, Looper will notify DisplayEventDispatcher to process the event.

The entire communication flow is as follows:

App Process                                    SurfaceFlinger Process
  |                                             |
  |-- Create DisplayEventReceiver ------------->|
  |                                             |
  |<- Return IDisplayEventConnection (Binder)---|
  |                                             |
  |-- Create BitTube -------------------------->|
  |                                             |
  |<- File Descriptor Exchange -----------------|
  |                                             |
  |-- Register File Descriptor to Looper -------|
  |                                             |
  |-- Request Vsync (requestNextVsync) -------->|
  |                                             |
  |<- Send Vsync Event Data --------------------|
  |                                             |
  |-- Looper Notify -> handleEvent -------------|
  |                                             |
  |-- Callback Java Layer onVsync --------------|
  |                                             |

The advantage of this design is that it avoids using Binder to pass high-frequency Vsync event data, improving performance and real-time performance through direct socket communication, which is crucial for ensuring smooth UI rendering. At the same time, since BitTube uses file descriptors, it can be seamlessly integrated into Android’s Looper mechanism, enabling the entire system to work in an event-driven manner.

Logic of Choreographer Processing a Frame

The core of Choreographer’s drawing logic is in the Choreographer.doFrame function. As can be seen from the figure below, FrameDisplayEventReceiver.onVsync posts itself, and its run method directly calls doFrame to start the logic processing of a frame.

android/view/Choreographer.java

public void onVsync(long timestampNanos, long physicalDisplayId, int frame, VsyncEventData eventData) {
    ......
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    mVsyncEventData = eventData;
    Message msg = Message.obtain(mHandler, this);
    msg.setAsynchronous(true);
    mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
public void run() {
    mHavePendingVsync = false;
    doFrame(mTimestampNanos, mFrame, mVsyncEventData);
}

The doFrame function mainly does the following specific things:

Calculate frame drop logic
Record frame drawing info
Execute CALLBACK_INPUT, CALLBACK_ANIMATION, CALLBACK_INSETS_ANIMATION, CALLBACK_TRAVERSAL, CALLBACK_COMMIT

Recording Frame Drawing Info

FrameInfo in Choreographer is responsible for recording the drawing information of the frame. When doFrame is executed, the drawing time of each key node will be recorded down, which we can see using dumpsys gfxinfo. Of course, Choreographer only records a part, and the rest is recorded in hwui.

From these FrameInfo flags, we can see the recorded content. Later when we look at dumpsys gfxinfo, the data is arranged according to this.


public @interface FrameInfoFlags {}

    public static final int FRAME_TIMELINE_VSYNC_ID = 1;

    // The intended vsync time, unadjusted by jitter
    public static final int INTENDED_VSYNC = 2;

    // Jitter-adjusted vsync time, this is what was used as input into the
    // animation & drawing system
    public static final int VSYNC = 3;

    // The id of the input event that caused the current frame
    public static final int INPUT_EVENT_ID = 4;

    // When input event handling started
    public static final int HANDLE_INPUT_START = 5;

    // When animation evaluations started
    public static final int ANIMATION_START = 6;

    // When ViewRootImpl#performTraversals() started
    public static final int PERFORM_TRAVERSALS_START = 7;

    // When View:draw() started
    public static final int DRAW_START = 8;

    // When the frame needs to be ready by
    public static final int FRAME_DEADLINE = 9;

    // When frame actually started.
    public static final int FRAME_START_TIME = 10;

    // Interval between two consecutive frames
    public static final int FRAME_INTERVAL = 11;

The doFrame function records the time from Vsync time to markPerformTraversalsStart.

void doFrame(long frameTimeNanos, int frame, VsyncEventData eventData) {
    ......
    mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);
    // Handle CALLBACK_INPUT Callbacks 
    mFrameInfo.markInputHandlingStart();
    // Handle CALLBACK_ANIMATION Callbacks
    mFrameInfo.markAnimationsStart();
    // Handle CALLBACK_INSETS_ANIMATION Callbacks
    // Handle CALLBACK_TRAVERSAL Callbacks
    mFrameInfo.markPerformTraversalsStart();
    // Handle CALLBACK_COMMIT Callbacks
    ......
}

Executing Callbacks

void doFrame(long frameTimeNanos, int frame, VsyncEventData eventData) {
    ......
    // Handle CALLBACK_INPUT Callbacks 
    doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
    // Handle CALLBACK_ANIMATION Callbacks
    doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
    // Handle CALLBACK_INSETS_ANIMATION Callbacks
    doCallbacks(Choreographer.CALLBACK_INSETS_ANIMATION, frameTimeNanos);
    // Handle CALLBACK_TRAVERSAL Callbacks
    doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
    // Handle CALLBACK_COMMIT Callbacks
    doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
    ......
}

Input Callback Call Stack

input callback generally executes ViewRootImpl.ConsumeBatchedInputRunnable

android/view/ViewRootImpl.java

final class ConsumeBatchedInputRunnable implements Runnable {
    @Override
    public void run() {
        doConsumeBatchedInput(mChoreographer.getFrameTimeNanos());
    }
}
void doConsumeBatchedInput(long frameTimeNanos) {
    if (mConsumeBatchedInputScheduled) {
        mConsumeBatchedInputScheduled = false;
        if (mInputEventReceiver != null) {
            if (mInputEventReceiver.consumeBatchedInputEvents(frameTimeNanos)
                    && frameTimeNanos != -1) {
                scheduleConsumeBatchedInput();
            }
        }
        doProcessInputEvents();
    }
}

Input events are processed and finally passed to DecorView‘s dispatchTouchEvent, which leads to the familiar Input event dispatching.

Animation Callback Call Stack

Generally, when we call View.postOnAnimation frequently, CALLBACK_ANIMATION is used.

public void postOnAnimation(Runnable action) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        attachInfo.mViewRootImpl.mChoreographer.postCallback(
                Choreographer.CALLBACK_ANIMATION, action, null);
    } else {
        // Postpone the runnable until we know
        // on which thread it needs to run.
        getRunQueue().post(action);
    }
}

So when is View.postOnAnimation generally used? I took a screenshot, you can check it yourself. The most contacted should be operations like startScroll, Fling.

Its call stack depends on what it posts. Below is the fling animation after releasing the hand.

In addition, our Choreographer‘s FrameCallback also uses CALLBACK_ANIMATION.

public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {
    if (callback == null) {
        throw new IllegalArgumentException("callback must not be null");
    }

    postCallbackDelayedInternal(CALLBACK_ANIMATION,
            callback, FRAME_CALLBACK_TOKEN, delayMillis);
}

Traversal Call Stack

void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        // In order to increase priority, postSyncBarrier first
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
        // Really start executing measure, layout, draw
        doTraversal();
    }
}
void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        // removing SyncBarrier here
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
        // Really start
        performTraversals();
    }
}
private void performTraversals() {
      // measure operation
      if (focusChangedDueToTouchMode || mWidth != host.getMeasuredWidth() || mHeight != host.getMeasuredHeight() || contentInsetsChanged || updatedConfiguration) {
            performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
      }
      // layout operation
      if (didLayout) {
          performLayout(lp, mWidth, mHeight);
      }
      // draw operation
      if (!cancelDraw && !newSurface) {
          performDraw();
      }
}

TraceView Example of doTraversal

Next Frame Vsync Request

Due to the existence of operations such as animation, sliding, and Fling, we need a continuous and stable frame rate output mechanism. This involves the request logic of Vsync. In continuous operations, such as animation, sliding, and Fling, doFrame of each frame will trigger the application for the next Vsync according to the situation, so that we can obtain continuous Vsync signals.

See the call stack of scheduleTraversals below (scheduleTraversals will trigger Vsync request)

We are familiar with invalidate and requestLayout triggering Vsync signal requests.

Let’s take Animation as an example to see how Animation drives the next Vsync to continuously update the screen.

ObjectAnimator Animation Driving Logic

android/animation/ObjectAnimator.java

1
2
3

public void start() {
    super.start();
}

android/animation/ValueAnimator.java

private void start(boolean playBackwards) {
    ......
    addAnimationCallback(0); // Add Animation Callback when animation starts
    ......
}
private void addAnimationCallback(long delay) {
    ......
    getAnimationHandler().addAnimationFrameCallback(this, delay);
}

android/animation/AnimationHandler.java

public void addAnimationFrameCallback(final AnimationFrameCallback callback, long delay) {
    if (mAnimationCallbacks.size() == 0) {
        // post FrameCallback
        getProvider().postFrameCallback(mFrameCallback);
    }
    ......
}

// mFrameCallback here callbacks doFrame, inside posts itself
private final Choreographer.FrameCallback mFrameCallback = new Choreographer.FrameCallback() {
    @Override
    public void doFrame(long frameTimeNanos) {
        doAnimationFrame(getProvider().getFrameTime());
        if (mAnimationCallbacks.size() > 0) {
            // post itself
            getProvider().postFrameCallback(this);
        }
    }
};

Calling postFrameCallback will go to mChoreographer.postFrameCallback, where the Vsync request logic of Choreographer will be triggered.

android/animation/AnimationHandler.java

1
2
3

public void postFrameCallback(Choreographer.FrameCallback callback) {
    mChoreographer.postFrameCallback(callback);
}

android/view/Choreographer.java

private void postCallbackDelayedInternal(int callbackType,
        Object action, Object token, long delayMillis) {
    synchronized (mLock) {
        final long now = SystemClock.uptimeMillis();
        final long dueTime = now + delayMillis;
        mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

        if (dueTime <= now) {
            // Request Vsync scheduleFrameLocked ->scheduleVsyncLocked-> mDisplayEventReceiver.scheduleVsync ->nativeScheduleVsync
            scheduleFrameLocked(now);
        } else {
            Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
            msg.arg1 = callbackType;
            msg.setAsynchronous(true);
            mHandler.sendMessageAtTime(msg, dueTime);
        }
    }
}

Through the Animation.start setting above, the Choreographer.FrameCallback interface is used to request the next Vsync every frame.
TraceView Example of a Frame During Animation

Source Code Summary

Choreographer is designed using a thread singleton mode and is strongly coupled with Looper. Each thread can only has one Choreographer instance, and it must be bound to a valid Looper object because its internal Handler relies on Looper for message dispatching. In applications, it is usually bound to the main thread’s Looper to ensure thread safety of UI operations.
DisplayEventReceiver is an abstract base class, and its JNI implementation creates an IDisplayEventConnection object as a listener for Vsync signals. Through this mechanism, the Vsync interrupt signal sent by AppEventThread of SurfaceFlinger can be accurately delivered to the Choreographer instance. When the Vsync signal arrives, the system callbacks onVsync method of DisplayEventReceiver, triggering the rendering process.
DisplayEventReceiver provides scheduleVsync method for requesting Vsync signals. When the application needs to update the UI, it first requests the next Vsync interrupt through this method, and then executes the actual drawing logic in the onVsync callback, ensuring that rendering is synchronized with the screen refresh.
Choreographer defines the FrameCallback interface, and its doFrame method is called every time Vsync arrives. This design is of great significance to the Android animation system, enabling animations to be accurately synchronized with the screen refresh rate, providing a smoother and more power-saving animation experience compared to early self-timing implementations.
Choreographer‘s core function is to receive Vsync signals and trigger callback functions registered through postCallback. The framework defines five types of callbacks, sorted by execution priority:
1. CALLBACK_INPUT: Handle input events, such as touch, key presses, etc.
2. CALLBACK_ANIMATION: Handle various animation calculations and updates
3. CALLBACK_INSETS_ANIMATION: Handle system inset animations, such as soft keyboard, status bar animations, etc.
4. CALLBACK_TRAVERSAL: Handle measurement, layout, and drawing of the view tree
5. CALLBACK_COMMIT: Perform post-draw finishing work, and adjust frame time when needed for better delay/jitter accounting
ListView and RecyclerView‘s Item reuse mechanism (ViewHolder pattern) specific implementation at the framework level will involve CALLBACK_INPUT and CALLBACK_ANIMATION stages. When sliding or scrolling quickly, Item initialization, measurement, and drawing may be triggered in the Input callback (such as directly responding to touch events), or may be executed in the Animation callback (such as inertial sliding or automatic scrolling). RecyclerView, through a more efficient reuse mechanism and Prefetch strategy, can intelligently prepare ViewHolder in these two stages, reducing main thread blocking, performing especially well on high refresh rate devices.
CALLBACK_INPUT and CALLBACK_ANIMATION will modify various properties of View (such as position, transparency, transformation matrix, etc.) during execution, so they must be executed before CALLBACK_TRAVERSAL to ensure that all state updates can be correctly applied during the measurement, layout, and drawing process of the current frame. This strict execution order guarantees the consistency and predictability of Android UI rendering.

APM and Choreographer

Due to Choreographer’s position in the rendering path, many performance monitoring methods are built around it. Note that FrameInfo itself is an internal Framework structure (@hide); app-side monitoring usually relies on FrameCallback, FrameMetrics, dumpsys gfxinfo framestats, Perfetto, and related tooling.

Use doFrame callback of FrameCallback
Use FrameMetrics API
Use framestats (internally backed by FrameInfo): adb shell dumpsys gfxinfo framestats
Use SurfaceFlinger latency: adb shell dumpsys SurfaceFlinger --latency
Use SurfaceFlinger PageFlip mechanism: adb service call SurfaceFlinger 1013 (system permission required)
Choreographer’s own dropped-frame calculation logic
BlockCanary performance monitoring based on Looper
Perfetto’s monitoring capabilities
1. Perfetto is already Android’s mainline tracing infrastructure (Android 10+ largely replaced the old systrace.py workflow)
2. Perfetto can capture more detailed system performance data, including Choreographer details
3. Perfetto UI enables visual analysis of frame rendering

Use Perfetto for Advanced Monitoring

Perfetto is Android’s main system-tracing solution. It provides more powerful functionality than legacy Systrace workflows:

Comparison of comprehensive performance data collection
Perfetto can collect multi-dimensional data such as CPU, memory, graphics rendering, system services, etc. at the same time
Lower overhead
Using efficient tracking engine, less impact on system performance
Better Choreographer tracking
Can track Choreographer’s work process in detail, including:
- Reception and processing of Vsync signals
- Execution details of doFrame method
- Execution time of various callbacks
- The collaboration process between UI thread and RenderThread
Tracking BlastBufferQueue-related paths
Can track BlastBufferQueue behavior, helping developers understand buffer management

Use Perfetto to Track Choreographer

# Start recording Perfetto trace (example: 15s with common categories)
adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto-trace -t 15s \
    sched freq idle am wm gfx view binder_driver hal

# Get trace file after completion
adb pull /data/misc/perfetto-traces/trace.perfetto-trace

# Analyze in Perfetto UI (https://ui.perfetto.dev/)

In Perfetto UI, you can find the event named “Choreographer#doFrame”, which shows the processing time and details of each frame. You can also check the collaboration relationship between the UI thread and RenderThread, and the interaction with SurfaceFlinger.

Use framestats (internally backed by FrameInfo) for Monitoring

adb shell dumpsys gfxinfo framestats

Window: StatusBar
Stats since: 17990256398ns
Total frames rendered: 1562
Janky frames: 361 (23.11%)
50th percentile: 6ms
90th percentile: 23ms
95th percentile: 36ms
99th percentile: 101ms
Number Missed Vsync: 33
Number High input latency: 683
Number Slow UI thread: 273
Number Slow bitmap uploads: 8
Number Slow issue draw commands: 18
Number Frame deadline missed: 287
HISTOGRAM: 5ms=670 6ms=128 7ms=84 8ms=63 9ms=38 10ms=23 11ms=21 12ms=20 13ms=25 14ms=39 15ms=65 16ms=36 17ms=51 18ms=37 19ms=41 20ms=20 21ms=19 22ms=18 23ms=15 24ms=14 25ms=8 26ms=4 27ms=6 28ms=3 29ms=4 30ms=2 31ms=2 32ms=6 34ms=12 36ms=10 38ms=9 40ms=3 42ms=4 44ms=5 46ms=8 48ms=6 53ms=6 57ms=4 61ms=1 65ms=0 69ms=2 73ms=2 77ms=3 81ms=4 85ms=1 89ms=2 93ms=0 97ms=2 101ms=1 105ms=1 109ms=1 113ms=1 117ms=1 121ms=2 125ms=1 129ms=0 133ms=1 150ms=2 200ms=3 250ms=0 300ms=1 350ms=1 400ms=0 450ms=0 500ms=0 550ms=0 600ms=0 650ms=0 

---PROFILEDATA---
Flags,IntendedVsync,Vsync,OldestInputEvent,NewestInputEvent,HandleInputStart,AnimationStart,PerformTraversalsStart,DrawStart,SyncQueued,SyncStart,IssueDrawCommandsStart,SwapBuffers,FrameCompleted,DequeueBufferDuration,QueueBufferDuration,
0,10158314881426,10158314881426,9223372036854775807,0,10158315693363,10158315760759,10158315769821,10158316032165,10158316627842,10158316838988,10158318055915,10158320387269,10158321770654,428000,773000,
0,10158332036261,10158332036261,9223372036854775807,0,10158332799196,10158332868519,10158332877269,10158333137738,10158333780654,10158333993206,10158335078467,10158337689561,10158339307061,474000,885000,
0,10158348665353,10158348665353,9223372036854775807,0,10158349710238,10158349773102,10158349780863,10158350405863,10158351135967,10158351360446,10158352300863,10158354305654,10158355814509,471000,836000,
0,10158365296729,10158365296729,9223372036854775807,0,10158365782373,10158365821019,10158365825238,10158365975290,10158366547946,10158366687217,10158367240706,10158368429248,10158369291852,269000,476000,

Use SurfaceFlinger for Monitoring

Command explanation:

The unit of data is nanoseconds, and the time starts from the boot time
Each command will get 128 lines of frame-related data

Data:

The first line of data indicates the refresh interval refresh_period
Column 1: This part of the data indicates the time point when the application draws the image
Column 2: The vertical sync time before SF (software) submits the frame to H/W (hardware) for drawing, that is, the timestamp submitted to hardware after each frame is drawn. This column is the vertical sync timestamp.
Column 3: The time point when SF submits the frame to H/W, which is regarded as the time point when H/W finishes receiving data from SF, and the time point when drawing is completed.

Frame Drop (Jank) Calculation

Each line can get a value through the following formula, which is a standard we call jankflag. If the jankflag of the current line changes compared to the jankflag of the previous line, it is called a dropped frame.

ceil((C - A) / refresh-period)

Use SurfaceFlinger PageFlip Mechanism for Monitoring

Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
    data.writeInterfaceToken("android.ui.ISurfaceComposer");
mFlinger.transact(1013, data, reply, 0);
final int pageFlipCount = reply.readInt();

final long now = System.nanoTime();
final int frames = pageFlipCount - mLastPageFlipCount;
final long duration = now - mLastUpdateTime;
mFps = (float) (frames * 1e9 / duration);
mLastPageFlipCount = pageFlipCount;
mLastUpdateTime = now;
reply.recycle();
data.recycle();

Choreographer’s Own Dropped Frame Calculation Logic

SKIPPED_FRAME_WARNING_LIMIT is 30 by default, controlled by the property debug.choreographer.skipwarning.

if (jitterNanos >= mFrameIntervalNanos) {
    final long skippedFrames = jitterNanos / mFrameIntervalNanos;
    if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
        Log.i(TAG, "Skipped " + skippedFrames + " frames!  "
                + "The application may be doing too much work on its main thread.");
    }
}

BlockCanary

BlockCanary uses Looper’s message mechanism for performance monitoring. It achieves the purpose of monitoring performance by recording before and after each Message in the MessageQueue.

android/os/Looper.java

public static void loop() {
    ...
    for (;;) {
        ...
        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        msg.target.dispatchMessage(msg);
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }
        ...
    }
}

MessageQueue and Choreographer

In the Android message mechanism, asynchronous messages have special processing priority. The system can insert a barrier (Barrier) into the message queue through the enqueueBarrier method, so that all synchronous messages after the barrier cannot be executed temporarily until removeBarrier method is called to remove the barrier. Messages marked as asynchronous are not affected by the barrier and can be processed normally.

Messages are synchronous by default. Only by using the setAsynchronous method of Message (this method is a hidden API) can the message be set to asynchronous. When initializing Handler, specific parameters can be passed to specify that all messages sent by this Handler are asynchronous. In this case, the enqueueMessage method of Handler will automatically call the setAsynchronous method of Message.

The core value of asynchronous messages lies in being able to bypass message barriers to proceed execution. If there is no barrier set, asynchronous messages are processed in exactly the same way as synchronous messages. The removeSyncBarrier method can be used to remove the previously set barrier.

An Example of SyncBarrier Used in Choreographer

postSyncBarrier is called when scheduleTraversals.

void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        // In order to increase priority, postSyncBarrier first
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

removeSyncBarrier is called when doTraversal.

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        // Remove SyncBarrier here
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
        // Really start
        performTraversals();
    }
}

When Choreographer posts a Message, it sets these messages as Asynchronous, so the priority of these Messages in Choreographer will be relatively high.

Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);

Manufacturer Optimizations

Since system manufacturers can directly modify the source code, they also take advantage of this to do some functions and optimizations. However, due to confidentiality issues, the code will not be put up directly. I can roughly talk about the ideas. Those interested can discuss privately.

Input Event Optimization

Choreographer itself does not have input messages, but after modifying the source code, input messages can be directly given to Choreographer. With these Input messages, Choreographer can do some things, such as responding in advance without waiting for Vsync.

Background Animation Optimization

When an Android application retreats to the background, if it is not terminated by the system, it may still continue to execute various operations. In some cases, the application will continue to call Animation Callback in Choreographer. Even if these animations are invisible to the user, the execution of these Callbacks is completely meaningless, but it will cause high CPU resource usage.

Therefore, system manufacturers will optimize for this situation in Choreographer, restricting background applications that do not meet the conditions from continuing to execute meaningless animation callbacks through a series of strategies, effectively reducing system resource usage.

Frame Drawing Optimization

Like input event optimization, since we have Input event information, in some scenarios we can notify SurfaceFlinger not to wait for Vsync to do composition operations directly.

App Launch Optimization

We said earlier that all operations of the main thread are based on Message. If an operation, a non-important Message, is arranged at the back of the queue, it will affect this operation; by rearranging MessageQueue, when the application starts, important startup Messages are placed in front of the queue to speed up the startup speed.

Animation Callback Front-loading

After the main thread of the previous frame is finished, there is actually a period of idle time before the next Vsync. This period of time can actually be used to prepare for the next frame. Then we can advance the animation callback of the next frame to do it here, which can effectively use the idle time of the CPU and reduce dropped frames.

Frame Interpolation

Like Animation callback front-loading, after the main thread of the previous frame is finished, there is actually a period of idle time before the next Vsync. This period of time can actually be used to prepare for the next frame. It’s just that here we directly generate a new frame: that is, execute doFrame twice in one Vsync. Frame interpolation is equivalent to preparing the data of the next few frames in advance, so that when encountering a truly time-consuming frame, there will be no stuttering.

Frame interpolation implementation is mainly in sliding scenarios, used on sliding components that implement OverScroller, such as ListView, RecyclerView. Because if OverScroller is used, we will know the sliding time and distance when touch up, and we can do tricks (frame interpolation) in the middle, equivalent to drawing the content of the next few VSyncs in one Vsync.

High Refresh Rate Optimization

The high refresh rate (120 Hz) on modern Android devices shortens the Vsync interval from 16.6 ms to 8.3 ms, which brings huge performance and power consumption challenges. How to complete the necessary operations for rendering in one frame is a place that mobile phone manufacturers must think about and optimize:

Performance performance and optimization of Super App
Game high frame rate cooperation
Logic of mutual switching between 120 fps, 90 fps and 60 fps

Reference Materials

Zhihu Address

Since blog comments are inconvenient, if you want to like or communicate, please move to the Zhihu page of this article
Zhihu - Detailed Explanation of Android Choreographer-based Rendering Mechanism - Perfetto Version
Juejin - Detailed Explanation of Android Choreographer-based Rendering Mechanism - Perfetto Version

About Me & Blog

Below is a personal introduction and related links. I look forward to communicating with you all!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for support~

One person can go faster, a group of people can go further

Android Perfetto Series 4: Opening Large Traces via Command Line

2025-02-08T09:53:03.000Z

This is the fourth article in the Perfetto series, explaining how to use trace_processor_shell to open large files exceeding 2GB locally. In actual problem analysis, we often encounter very large Trace files (greater than 2GB) that cannot be opened by directly dragging them into ui.perfetto.dev due to browser memory limitations. In this case, we need to use the trace_processor_shell tool provided by the official to open large files locally.

With Google announcing the deprecation of the Systrace tool and the release of Perfetto, Perfetto has basically replaced Systrace in my daily work. At the same time, major manufacturers like OPPO and Vivo have also switched from Systrace to Perfetto. Many friends who are new to Android performance optimization feel a headache when facing the dazzling interface and complex functions of Perfetto. They hope that I can present those previous Systrace articles using Perfetto.

Perfetto Series Catalog
0. trace_processor_shell Tool Download
1. Using trace_processor_shell to Open Large Trace Files
2. Difference Between Command Line Startup and Direct UI Opening
3. Mac Permission Issues
Reference Documents
About Me && Blog

Paul Graham said: “Either give a lot of people something they kind of want, or give a small number of people something they really want.“ Perfetto is actually something that a small number of people really want, so let’s start writing. I welcome everyone to exchange and communicate. If you find errors or inaccurate descriptions, please inform me in time, and I will modify them in time to avoid misleading others.

This series aims to examine the overall operation of the Android system from a new perspective through the tool Perfetto. In addition, it also aims to provide a different angle to learn key modules such as App, Framework, and Linux. Although you may have read many articles about Android Framework, App, and performance optimization, you may still feel confused because it is difficult to remember the code or understand its running process. Through the graphical tool Perfetto, you may gain a deeper understanding.

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

0. trace_processor_shell Tool Download

Official download address: https://github.com/google/perfetto/releases , find the latest release version, and choose your own platform to download:

After downloading, there will be the trace_processor_shell tool inside (taking Mac platform as an example)

trace_processor_shell is one of the core tools of the Perfetto open source project, providing high-performance local Trace parsing services. After starting the HTTP server via the –httpd parameter, it allows:

Local native acceleration: Bypass the performance limitations of the browser WASM and directly call the parsing engine implemented in C++. Based on the parsing engine implemented by Rust/C++ mixing, it optimizes memory layout and parallel processing, and supports flow parsing of ultra-large trace files.
Interactive analysis: Deeply integrated with Perfetto UI to support dynamic queries and visualization.
Offline debugging: No need to upload trace to the cloud, protect privacy and support intranet environment.

Other parameters

Parameter	Function	Example Value
`--http-port`	Specify listening port	`--httpd :8080`
`--preload`	Preload common data tables	`--preload sched`
`--num-threads`	Set parsing thread count (default is CPU core count)	`--num-threads 8`

1. Using trace_processor_shell to Open Large Trace Files

1	./trace_processor_shell --httpd ../jank-HangLVZongHeng-TrainTicket-ScrollSuperJank.perfetto-trace

At this time, open https://ui.perfetto.dev on the web page, and there will be the following pop-up box

The detailed functions of the pop-up options are as follows

1. `YES, use loaded trace`

Function: Directly reuse the trace file state currently loaded by Trace Processor (that is, ../jank-HangLVZongHeng-TrainTicket-ScrollSuperJank.perfetto-trace specified in the command line).
Applicable Scenario:
If you have already loaded the trace file via trace_processor_shell --httpd and hope that the UI directly uses the parsing state of the current process (including executed SQL queries, filtering conditions, etc.), choose this option.
Advantage:
Avoid re-parsing files to save time and memory.

2. `YES, but reset state`

Function: Force reset the Trace Processor state and reload the current trace file (or load a new file).
Applicable Scenario:
- Need to clear all states of the current Trace Processor (such as temporary query results, filters, etc.) and start analysis again.
- Want to load another trace file through the same port (need to stop the current process or change the port first).
Equivalent Operation:
Equivalent to closing the current trace_processor_shell process and re-executing the command.

3. `NO, Use builtin WASM`

Function: Completely bypass the local Trace Processor service and use the browser’s built-in WebAssembly (WASM) engine to parse the trace file instead.
Applicable Scenario:
- The local Trace Processor service is unavailable or has compatibility issues.
- Need to support WASM mode exclusive functions such as sharing links and downloading modified trace files.
Cost:
Parsing speed of large files (such as >100MB) drops significantly, and may crash due to browser memory limitations.

If you choose YES, use loaded trace, after opening Trace, the following functions are unavailable

2. Difference Between Command Line Startup and Direct UI Opening

Startup via Command Line (`trace_processor_shell --httpd`)

Core Mechanism:
Start a high-performance C++ Trace Processor service locally (listening on 127.0.0.1:9001) to provide native accelerated trace parsing capabilities.
Advantage:
- Performance: Native code parsing speed far exceeds WASM, especially suitable for large trace files (such as >100MB).
- Function Scalability: Support advanced functions such as SQL query and custom metric calculation.
- State Retention: The parsing state of Trace Processor (such as SQL temporary tables) can be retained across page sessions.
Limitation:
- Cannot directly share trace file links or download modified files via UI.
- Only one browser tab is allowed to use the acceleration service at the same time.

Directly Open UI Web Page (`ui.perfetto.dev`)

Core Mechanism:
Completely rely on the browser’s built-in WebAssembly engine to parse trace files, with no local service participation.
Advantage:
- Convenience: No need to install or start local tools, suitable for quickly viewing small traces.
- Function Completeness: Support collaboration functions such as sharing links and downloading modified trace files.
Disadvantage:
- Performance Bottleneck: WASM parsing speed is slow, and large files may cause the browser to freeze or crash.
- Function Limitation: Does not support some advanced SQL queries and custom analysis functions.

Summary and Suggestions

Prioritize Command Line Startup: When processing large traces or requiring complex analysis, use trace_processor_shell --httpd to improve performance.
Temporary Lightweight Analysis: Directly uploading to ui.perfetto.dev is more convenient, but pay attention to file size limits.

3. Mac Permission Issues

Running ./trace_processor_shell --httpd directly on Mac will verify the following error

You need to click Allow in Settings - Privacy & Security to continue running

Reference Documents

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
This Blog Content Navigation: A navigation of personal blog content.
Personal Collection of Excellent Blog Articles - Android Performance Optimization Must-Know: Welcome everyone to recommend themselves and others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

One person can go faster, a group of people can go further

Android ANR Series 3 - ANR Case Studies

2025-02-08T08:29:30.000Z

This is the third article in the Android App ANR series, focusing on real-world ANR cases. The series includes:

ANR (Application Not Responding) is a simple definition that covers many Android system design philosophies.
First, ANR belongs to the application scope. This differs from SNR (System Not Responding), which reflects issues in the system process (system_server). SNR is managed by the Watchdog mechanism, while ANR is managed by the message handling mechanism at the system layer through message scheduling and timeout handling.
Second, the ANR mechanism is primarily implemented in the system layer. All ANR-related messages are scheduled by system_server and dispatched to the application process. The system uses various timeout limits to track message processing. If an app fails to respond within these limits, the system collects diagnostics (CPU/IO usage, thread stacks) and reports that the process is not responding.
Third, ANR is essentially a performance issue. The mechanism limits the app’s main thread, requiring it to handle common operations (starting services, processing broadcasts, input) within fixed timeframes. Time-consuming operations in the main thread (heavy calculations, heavy I/O, complex layouts) reduce responsiveness.
Finally, some ANR issues are very difficult to analyze. System-level issues like Linux kernel bugs, memory fragmentation, or hardware failures can cause message scheduling failures that are hard to reproduce and diagnose.
– From duanqz

Common Causes of ANR

When investigating ANR reasons, usually we must follow the rule: Boldly hypothesize, carefully verify. After extracting the abnormal parts, first hypothesize that the problem is caused here, and then use this hypothesis as a starting point to check the Logs before and after to see if they can support your hypothesis. If not, then switch to another point.

Issues Within the Current Process

Deadlocks.
Main thread calls thread.join(), sleep(), wait(), or waits for a thread lock.
Main thread is blocked in nSyncDraw (waiting for RenderThread).
Time-consuming operations on the main thread, such as complex layouts, massive for loops, IO, etc.
Main thread is blocked by a sub-thread’s synchronized lock.
Main thread times out waiting for a sub-thread.
Main thread Activity lifecycle method execution timeout.
Main thread Service lifecycle method execution timeout.
Main thread Broadcast.onReceive function execution timeout (even if goAsync is called).
RenderThread is time-consuming.
Time-consuming network access.
Application reads and writes a large amount of data.
Database operations.
Hardware operations (such as Camera).
The number of service binders reaches the upper limit.
Other threads terminate or crash, causing the main thread to wait indefinitely.
Dump memory operations.
A large number of SharedPreference reads and writes at the same time.

Issues in Remote Processes or the System

Binder communication with SystemServer, and SystemServer execution is time-consuming.
1. The method itself takes a long time to execute causing timeout.
2. Too much lock contention in SystemServer, resulting in lock wait timeout.
Timeout waiting for other processes to return, such as getting data from other processes’ ContentProvider.
Window state confusion leading to Input dispatch timeout.
Frequent crashes of the process corresponding to the ContentProvider will also kill the current process.
System-wide low memory.
System-wide high CPU usage.
System-wide high IO usage.
SurfaceFlinger timeout.
Bug in system freezing function.
WatchDog ANR in System Server.
The device triggers thermal control frequency limitation.

ANR Case Studies

ANR Case: Toutiao - Deadlock

The main operation is frequently pulling out Toutiao from the sidebar for split-screen operations. After multiple operations, the application experienced an ANR, which caused the phone to briefly black screen and freeze in the application interface in the split-screen bar. However, it returned to normal after 4-5 seconds.

The reason for the application ANR is that its own main thread is blocked.

"main"prio=5tid=1Blocked
| group="main"sCount=1dsCount=0obj=0x74f9bbe8self=0xe7084400
| sysTid=28210nice=0cgrp=defaultsched=0/0handle=0xe9dcd534
| state=S schedstat=(13454428309928953492) utm=121stm=13core=3HZ=100
| stack=0xff3b6000-0xff3b8000stackSize=8MB
| held mutexes=
at com.ss.android.common.applog.LogReaper.insertCrashLog(SourceFile:98)
- waiting to lock <0x0d3fbd00> (a com.ss.android.common.applog.LogReaper) held by thread34
at com.ss.android.common.applog.AppLog.uncaughtException(SourceFile:1408
at u.aly.n.uncaughtException(SourceFile:34)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1063)

Key Information:

1	waiting to lock <0x0d3fbd00> (a com.ss.android.common.applog.LogReaper) held by thread34

Therefore, in the ANR log below, search for tid==34:

"LogReaper"prio=5tid=34TimedWaiting
| group="main"sCount=1dsCount=0obj=0x12fcaba0self=0xcb226e00
| sysTid=28274nice=0cgrp=defaultsched=0/0handle=0xc9f9b920
| state=S schedstat=(77341565269270880) utm=7stm=0core=5HZ=100
| stack=0xc9e99000-0xc9e9b000stackSize=1038KB
| held mutexes=
at java.lang.Object.wait!(Native method)
- waiting on <0x00fc7065> (a java.util.concurrent.atomic.AtomicInteger)
at java.lang.Object.wait(Object.java:407)
at com.ss.android.action.b.d.a(SourceFile:216)
at com.ss.android.newmedia.b.onLogSessionBatchEvent(SourceFile:468)
at com.ss.android.common.applog.DBHelper.batchSession(SourceFile:616)
- locked <0x0d4ff1c4> (a com.ss.android.common.applog.DBHelper)
at com.ss.android.common.applog.LogReaper.switchSession(SourceFile:175)
at com.ss.android.common.applog.LogReaper.switchSession(SourceFile:153)
at com.ss.android.common.applog.LogReaper.processItem(SourceFile:122)
- locked <0x0d3fbd00> (a com.ss.android.common.applog.LogReaper)
at com.ss.android.common.applog.LogReaper.run(SourceFile:632)

Key Information:

1	waiting on <0x00fc7065> (a java.util.concurrent.atomic.AtomicInteger)

Caused by code blocking within the app.

ANR Case: ANR caused by Freezing

Search for am_anr to view the time when the ANR occurred.

05-0100:51:39.594 1449 5234I am_anr  : [0,2169,com.xxx.weather2,820526660,Input dispatching timed out (Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it.  Outbound queue length: 0.  Wait queue length: 1.)]

From the ANR description, it can be seen that the current Window timed out while processing the previous Input event, causing the new event not to be processed in time, so an ANR occurred.

Search for ANR in to view the CPU information at that time.

05-0100:51:53.974 1449 5234E ActivityManager: ANR in com.xxx.weather2 (com.xxx.weather2/com.xxx.weather.xxxMainActivity)
05-0100:51:53.974 1449 5234E ActivityManager: PID:2169
05-0100:51:53.974 1449 5234E ActivityManager: Reason:Input dispatching timed out (Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it.  Outbound queue length: 0.  Wait queue length: 1.)
05-01 00:51:53.974  1449  5234 E ActivityManager: Parent: com.xxx.weather2/com.xxx.weather.xxxMainActivity
05-01 00:51:53.974  1449  5234 E ActivityManager: Load: 29.89 / 31.82 / 32.27
05-01 00:51:53.974  1449  5234 E ActivityManager: CPU usage from 4583ms to 12043ms later (2020-05-01 00:51:44.177 to 2020-05-01 00:51:51.637):
05-01 00:51:53.974  1449  5234 E ActivityManager:   18% 1449/system_server: 9.1% user + 9.3% kernel / faults: 7819 minor 1 major
05-01 00:51:53.974  1449  5234 E ActivityManager:   10% 720/surfaceflinger: 6.2% user + 4.4% kernel / faults: 734 minor 26 major
05-01 00:51:53.974  1449  5234 E ActivityManager:   10% 651/android.hardware.audio@5.0-service-mediatek: 9.5% user + 0.8% kernel / faults: 1 minor 4 major

It can be seen that the CPU was not busy at that time, so it was not an ANR caused by system load. Therefore, subsequent analysis needs to extract corresponding information from the Log to analyze what the system was doing before and after the timeout input event occurred.

The analysis process is as follows:

Find the specific time when the ANR occurred: 00:51:39.594.
Start looking from the Log 5s ago and find useful information: 00:51:34.478.
It was found that there was nothing abnormal at this time point, only that the application did not respond to key_back_down, causing an ANR reported 5s later.
From the Log after ANR, it is found that xxxHansManager : unfreeze uid: 10182 package: com.xxx.weather2 reason: Signal. This Log indicates that com.xxx.weather2 was in a frozen state before and was unfrozen here. So we can verify the bold guess: was com.xxx.weather2 unable to respond to events after being frozen, causing the issue?
Search for the freezing Log. It can be seen that at 00:51:04.000, the system froze com.xxx.weather2: xxxHansManager : freeze uid: 10182 package: com.xxx.weather2 reason: LcdOff.
This requires the system team to check if there is a problem with the logic of freezing.

// Due to LcdOff, initiate freezing, weather2 is frozen: com.xxx.weather2 reason: LcdOff
05-01 00:51:03.994  1449  2187 I xxxHansManager : freeze uid: 10245 package: com.tencent.mm reason: LcdOff
05-01 00:51:03.994  1449  2187 D xxxListManagerImpl: com.tencent.mm in autoStart list!
05-01 00:51:03.998  1449  2187 I xxxHansManager : freeze uid: 10246 package: com.xunmeng.pinduoduo reason: LcdOff
05-01 00:51:03.998  1449  2187 D xxxListManagerImpl: com.xunmeng.pinduoduo in autoStart list!
05-01 00:51:04.000  1449  2187 I xxxHansManager : freeze uid: 10182 package: com.xxx.weather2 reason: LcdOff
05-01 00:51:04.002   645 30914 I netd    : firewallSetUidRule(4, 10182, 2) <0.09ms>
05-01 00:51:04.005  1449  2187 I xxxHansManager : freeze uid: 10187 package: com.heytap.yoli reason: LcdOff
05-01 00:51:04.005  1449  2187 D xxxListManagerImpl: com.heytap.yoli in autoStart list!
05-01 00:51:04.005  1449  2187 I xxxHansManager : isHansImportantCase uid: 10196 pkg: cn.kuwo.player reason: audiofocus
05-01 00:51:04.007  1449  2187 I xxxHansManager : freeze uid: 10234 package: com.tencent.mobileqq reason: LcdOff
05-01 00:51:04.008  1449  2187 D xxxListManagerImpl: com.tencent.mobileqq in autoStart list!
05-01 00:51:04.014  1449  2187 I xxxHansManager : freeze uid: 10235 package: com.tencent.qqlive reason: LcdOff

// weather2 Received KEYCODE_BACK ACTION_DOWN
05-01 00:51:04.471  1449  9842 D xxxPhoneWindowManager: interceptKeyBeforeQueueing:KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x8, repeatCount=0, eventTime=38812125, downTime=38812125, deviceId=-1, source=0x101, displayId=0 }
05-01 00:51:04.471  1449  9842 I sysui_multi_action: [757,803,799,key_back_down,802,1]
05-01 00:51:04.477  1449  1620 D xxxPhoneWindowManager: interceptKeyBeforeDispatching key: win=Window{1b36ae8 u0 com.xxx.weather2/com.xxx.weather.xxxMainActivity}  event = KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x8, repeatCount=0, eventTime=38812125, downTime=38812125, deviceId=-1, source=0x101, displayId=0 }
05-01 00:51:04.477  1449  1620 D xxxPhoneWindowManager: interceptKeyBeforeDispatching newEvent keyCode = 4

// weather2 Received KEYCODE_BACK ACTION_UP
05-01 00:51:34.478  1449  1620 D xxxPhoneWindowManager: interceptKeyBeforeDispatching key: win=Window{1b36ae8 u0 com.xxx.weather2/com.xxx.weather.xxxMainActivity}  event = KeyEvent { action=ACTION_UP, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x8, repeatCount=0, eventTime=38842126, downTime=38842126, deviceId=-1, source=0x101, displayId=0 }
05-01 00:51:34.478  1449  1620 D xxxPhoneWindowManager: interceptKeyBeforeDispatching newEvent keyCode = 4

// KEYCODE_BACK ACTION_UP did not respond for 5s, triggering ANR
05-01 00:51:39.484  1449  1620 I WindowManager: Input event dispatching timed out sending to com.xxx.weather2/com.xxx.weather.xxxMainActivity.  Reason: Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it.  Outbound queue length: 0.  Wait queue length: 1.
05-01 00:51:39.484  2256  5518 I QUALITY-TOTAL: exp: anr
05-01 00:51:39.594  1449  5234 I am_anr  : [0,2169,com.xxx.weather2,820526660,Input dispatching timed out (Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it.  Outbound queue length: 0.  Wait queue length: 1.)]
05-01 00:51:39.593  1449  1620 D ActivityManager:  ANR post Runnable for ProcessRecord{ae0c833 2169:com.xxx.weather2/u0a182} to deal with anr happend at 38847248@#@2169
05-01 00:51:39.593  1449  1620 D ActivityManager:  ANR caller(2) = com.android.server.am.ActivityManagerService$LocalService.inputDispatchingTimedOut:19872 com.android.server.wm.ActivityRecord.keyDispatchingTimedOut:2641 com.android.server.wm.AppWindowToken.keyDispatchingTimedOut:2007 com.android.server.wm.InputManagerCallback.notifyANR:111 com.android.server.input.InputManagerService.notifyANR:1822   

// The system sends Signal 3 to weather2 (SIGNAL_QUIT = 3, given to the Signal Catcher thread to output Trace)
05-01 00:51:40.868  2169  2202 I oloros.weather: Thread[7,tid=2202,WaitingInMainSignalCatcherLoop,Thread*=0xd9878400,peer=0x138c0250,"Signal Catcher"]: reacting to signal

// The system detected the Signal given to weather2, so unfreeze com.xxx.weather2
05-01 00:51:40.869  1449  9811 I xxxHansManager : unfreeze uid: 10182 package: com.xxx.weather2 reason: Signal
05-01 00:51:40.869  2169  2202 I oloros.weather:
05-01 00:51:40.869  2169  2169 W ViewRootImpl[xxxMainActivity]: Dropping event due to no window focus: KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x8, repeatCount=0, eventTime=38812125, downTime=38812125, deviceId=-1, source=0x101, displayId=0 }, hasFocus:true, mStopped:true, mPausedForTransition:false
05-01 00:51:40.869  2169  2169 W ViewRootImpl[xxxMainActivity]: Cancelling event due to no window focus: KeyEvent { action=ACTION_UP, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x28, repeatCount=0, eventTime=38847249, downTime=38812125, deviceId=-1, source=0x101, displayId=0 }, hasFocus:true, mStopped:true, mPausedForTransition:false

// You can see here that weather2 was stuck for 36391.9ms, which is the time from 00:51:04.471 (KEYCODE_BACK sent) to 00:51:40.869 (current time)
05-01 00:51:40.869  1449  1620 I InputDispatcher: Window '1b36ae8 com.xxx.weather2/com.xxx.weather.xxxMainActivity (server)' spent 36391.9ms processing the last input event: KeyEvent
05-01 00:51:40.869  2169  2169 V ViewRootImpl[xxxMainActivity]: Sending input event to IME: KeyEvent { action=ACTION_UP, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x28, repeatCount=0, eventTime=38847249, downTime=38812125, deviceId=-1, source=0x101, displayId=0 }
05-01 00:51:40.870  2169  2169 I Choreographer: Skipped 2212 frames!  The application may be doing too much work on its main thread.

ANR Case: Broadcast Timeout causing ANR

Logs for this case are missing, but specifically, the user was performing a migration. The BroadcastReceiver‘s onReceive started a thread to handle it, and eventually reported a BroadcastReceiver ANR.

1
2

04-0717:03:17.174435 1448 1476V WindowManager: Lookingforfocus: Window{efa2a4f u0 正在升级数据库，数据量较大，请耐心等待}, flags=25296898, canReceive=true1
04-0717:03:17.174459 1448 1476V WindowManager: findFocusedWindow: Foundnewfocus @ Window{efa2a4f u0 正在升级数据库，数据量较大，请耐心等待}2

Analysis is as follows:

The reason for the calendar background broadcast ANR is that onReceive execution timed out. Previously, it wasn’t obvious because the time-consuming operation in onReceive used new Thread, so it was thought that doing time-consuming operations in a sub-thread would not affect the execution of subsequent broadcasts.
Later it was found that PendingResult result = goAsync(); was called in onReceive. This statement allows time-consuming operations to be performed in a sub-thread during the execution of an ordered broadcast receiver, without affecting the receiver’s lifecycle. This method is very simple, returning mPendingResult and setting it to null.
If we call this method in onReceive, it means the broadcast processing flow is interrupted. When onReceive finishes execution, since mPendingResult is null, AMS.finishReceiver will not be called immediately. And because goAsync returns a PendingResult, we can call PendingResult.finish at any time and on any thread to callback AMS. This is equivalent to turning a synchronous callback into an asynchronous callback. During this asynchronous callback process, we can start a new thread to perform some time-consuming IO operations, etc. Simply put, goAsync provides a mechanism that allows us to process broadcast messages in an asynchronous thread to prevent the main thread from being blocked.
In this case, although a thread was used to handle the time-consuming task in onReceive, since goAsync was called, the timeout is still calculated. If it is not completed within the specified time, even if it is in a sub-thread, it will trigger an ANR for the BroadcastReceiver.

You can look at the official comments for the goAsync method:

/**
 * This can be called by an application in {@link #onReceive} to allow
 * it to keep the broadcast active after returning from that function.
 * This does not change the expectation of being relatively
 * responsive to the broadcast, but does allow
 * the implementation to move work related to it over to another thread
 * to avoid glitching the main UI thread due to disk IO.
 *
 * As a general rule, broadcast receivers are allowed to run for up to 10 seconds
 * before they system will consider them non-responsive and ANR the app.  Since these usually
 * execute on the app's main thread, they are already bound by the ~5 second time limit
 * of various operations that can happen there (not to mention just avoiding UI jank), so
 * the receive limit is generally not of concern.  However, once you use {@code goAsync}, though
 * able to be off the main thread, the broadcast execution limit still applies, and that
 * includes the time spent between calling this method and ultimately
 * {@link PendingResult#finish() PendingResult.finish()}.
 *
 * If you are taking advantage of this method to have more time to execute, it is useful
 * to know that the available time can be longer in certain situations.  In particular, if
 * the broadcast you are receiving is not a foreground broadcast (that is, the sender has not
 * used {@link Intent#FLAG_RECEIVER_FOREGROUND}), then more time is allowed for the receivers
 * to run, allowing them to execute for 30 seconds or even a bit more.  This is something that
 * receivers should rarely take advantage of (long work should be punted to another system
 * facility such as {@link android.app.job.JobScheduler}, {@link android.app.Service}, or
 * see especially {@link android.support.v4.app.JobIntentService}), but can be useful in
 * certain rare cases where it is necessary to do some work as soon as the broadcast is
 * delivered.  Keep in mind that the work you do here will block further broadcasts until
 * it completes, so taking advantage of this at all excessively can be counter-productive
 * and cause later events to be received more slowly.
 *
 * @return Returns a {@link PendingResult} representing the result of
 * the active broadcast.  The BroadcastRecord itself is no longer active;
 * all data and other interaction must go through {@link PendingResult}
 * APIs.  The {@link PendingResult#finish PendingResult.finish()} method
 * must be called once processing of the broadcast is done.
 */
public final PendingResult goAsync(){
    PendingResult res = mPendingResult;
    mPendingResult =null;
    return res;
}

Its usage is as follows:

@Override
public void onReceive(final Context context, final Intent intent){
    final PendingResult result = goAsync();
    Runnable worker = new Runnable() {
       @Override
       public void run(){
            onReceiveAsync(context, intent);
            result.finish();
        }
    };
    mAsyncHandler.post(worker);
}

ANR Case: Launcher - Input ANR

Search am_anr to find the time point when ANR occurred.

It belongs to input dispatch anr.
It belongs to application processing input event timeout (instead of no focus window).

19:44:56.815  2515 25056 I am_anr  : [0,3365,com.xxx.launcher,819478085,Input dispatching timed out (Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it.  Outbound queue length: 0.  Wait queue length: 9.)]

Search ANR in to find CPU usage.

From Load : 0.02 / 0.01 / 0.0, the overall load of the device is not high, so it is likely an ANR caused by logic.
The CPU usage of logd and SurfaceFlinger is slightly high, which can be regarded as suspicious objects for focused observation.

1-0119:45:07.753 251525056E ActivityManager: ANR in com.xxx.launcher (com.xxx.launcher/.Launcher)
 19:45:07.753 251525056E ActivityManager: PID:3365
 19:45:07.753 251525056E ActivityManager: Reason: Input dispatching timed out (Waiting to send key event because the focused window hasnotfinished processing all of the input events that were previously delivered to it.  Outbound queue length:0.  Wait queue length:9.)
 19:45:07.753 251525056E ActivityManager: Parent: com.xxx.launcher/.Launcher
 19:45:07.753 251525056E ActivityManager: Load:0.02/0.01/0.0
 19:45:07.753 251525056E ActivityManager: CPU usage from0ms to10936ms later (2020- 19:44:56.751to2020- 19:45:07.688):
 19:45:07.753 251525056E ActivityManager:   97%546/logd:97% user +0.2% kernel / faults:12minor
 19:45:07.753 251525056E ActivityManager:   25%956/surfaceflinger:11% user +13% kernel / faults:151minor17major
 19:45:07.753 251525056E ActivityManager:   1.4%1664/media.codec:0.9% user +0.5% kernel / faults:28729minor4major
 19:45:07.753 251525056E ActivityManager:   7.5%2515/system_server:2.9% user +4.6% kernel / faults:1818minor8major
 19:45:07.753 251525056E ActivityManager:   3.2%3365/com.xxx.launcher:2.1% user +1% kernel / faults:3535minor29major
 19:45:07.753 251525056E ActivityManager:   2%3620/com.xxx.persist.system:1.2% user +0.7% kernel / faults:870minor

Analyze trace.txt to see if there is any useful information. First look at the Launcher’s main thread stack.

"main"prio=5tid=1Native
  | group="main"sCount=1dsCount=0flags=1obj=0x72a50cd0self=0x6f7ae10800
  | sysTid=3365nice=-10cgrp=defaultsched=0/0handle=0x700123bed8
  | state=S schedstat=(37451337214473599138010494263) utm=26967stm=10484core=0HZ=100
  |stack=0x7fc0270000-0x7fc0272000stackSize=8192KB
  | held mutexes=
  kernel: (couldn't read /proc/self/task/3365/stack)
  native: #00pc0000000000071a8c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
  native: #01pc0000000000075710  /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex(voidvolatile*,bool,int,bool, timespecconst*)+140)
  native: #02pc00000000000d9744  /apex/com.android.runtime/lib64/bionic/libc.so (pthread_cond_wait+60)
  native: #03pc00000000002bf5e8  /system/lib64/libhwui.so (android::uirenderer::renderthread::DrawFrameTask::postAndWait()+168)
  native: #04pc00000000002bf510  /system/lib64/libhwui.so (android::uirenderer::renderthread::DrawFrameTask::drawFrame()+44)12
  at android.graphics.HardwareRenderer.nSyncAndDrawFrame(Native method)
  at android.graphics.HardwareRenderer.syncAndDrawFrame(HardwareRenderer.java:422)
  at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:671)
  at android.view.ViewRootImpl.draw(ViewRootImpl.java:3983)
  - locked <0x030694da> (a java.lang.Object)
  at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:3782)
  at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3085)
  at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1994)
  at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8201)
  at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1085)
  at android.view.Choreographer.doCallbacks(Choreographer.java:908)
  at android.view.Choreographer.doFrame(Choreographer.java:835)
  at android.view.Choreographer$FrameHandler.handleMessage(Choreographer.java:1013)
  at android.os.Handler.dispatchMessage(Handler.java:107)
  at android.os.Looper.loop(Looper.java:238)
  at android.app.ActivityThread.main(ActivityThread.java:7798)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:995)

It can be seen that the main thread is blocked waiting for RenderThread to return, so continue to check the RenderThread stack.

"RenderThread"daemon prio=7tid=25Native
  | group="main"sCount=1dsCount=0flags=1obj=0x13100b00self=0x6f0c698c00
  | sysTid=3616nice=-10cgrp=defaultsched=0/0handle=0x6f072e0d50
  | state=S schedstat=(35808915205059629728352628704) utm=29226stm=6582core=3HZ=100
  |stack=0x6f071ea000-0x6f071ec000stackSize=991KB
  | held mutexes=
  kernel: (couldn't read /proc/self/task/3616/stack)
  native: #00pc00000000000c49f4  /apex/com.android.runtime/lib64/bionic/libc.so (__ioctl+4)
  native: #01pc000000000007d518  /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+132)
  native: #02pc0000000000059e58  /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+244)
  native: #03pc000000000005ad94  /system/lib64/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*,int*)+60
  native: #04pc000000000005ab38  /system/lib64/libbinder.so (android::IPCThreadState::transact(int,unsignedint, android::Parcelconst&, android::Parcel*,unsignedint)+180)
  native: #05pc000000000004f000  /system/lib64/libbinder.so (android::BpBinder::transact(unsignedint, android::Parcelconst&, android::Parcel*,unsignedint)+228)
  native: #06pc000000000007fef8  /system/lib64/libgui.so (android::BpGraphicBufferProducer::dequeueBuffer(int*, android::sp*,unsignedint,unsignedint,int,unsignedlong,unsignedlong*, android::FrameEventHistoryDelta*)+224)
  native: #07pc00000000000b9880  /system/lib64/libgui.so (android::Surface::dequeueBuffer(ANativeWindowBuffer**,int*)+392)
  native: #08pc0000000000380540  /system/lib64/libhwui.so (android::uirenderer::renderthread::ReliableSurface::hook_dequeueBuffer(ANativeWindow*, ANativeWindowBuffer**,int*)+104)
  native: #09pc000000000000989c  /vendor/lib64/egl/eglSubDriverAndroid.so (???)
  native: #10pc0000000000009388  /vendor/lib64/egl/eglSubDriverAndroid.so (???)
  native: #11pc000000000022cd2c  /vendor/lib64/egl/libGLESv2_adreno.so (???)
  native: #12pc0000000000212b8c  /vendor/lib64/egl/libGLESv2_adreno.so (???)
  native: #13pc0000000000020838  /system/lib64/libEGL.so (android::eglQuerySurfaceImpl(void*,void*,int,int*)+248)
  native: #14pc00000000002c6794  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::beginFrame(void*)+224)
  native: #15pc00000000002d414c  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+236)
  native: #16pc00000000002d34e8  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+380)
  native: #17pc00000000002de044  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+228)
  native: #18pc00000000002ddd24  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+576)
  native: #19pc0000000000013654  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+328)
  native: #20pc00000000000da200  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
  native: #21pc00000000000769d4  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

It can be seen that RenderThread is stuck on binder communication, calling the method dequeueBuffer, waiting for the dequeueBuffer return result. Normally, the main thread does not wait for dequeueBuffer; it continues to execute after nSyncAndDrawFrame returns. It is stuck here because it is waiting for the previous draw task of RenderThread to complete, that is, the previous draw task is stuck in dequeueBuffer, causing the main thread of this frame to be stuck and timeout.

If you are familiar with the frame rendering process, you should know that the peer of dequeueBuffer is SurfaceFlinger. At this time, you need to check whether SurfaceFlinger has any problems (here if there is binder info, you can directly see which thread RenderThread is communicating with in SurfaceFlinger. Binder info can see the details of binder communication, for example, we should be able to see this case (since the binder info is not dumped, the following is just an example).

// 956 is SurfaceFlinger, here is the incoming binder information of SurfaceFlinger
proc956：
incoming transaction28350131:0000000000000000from3365:3616to956:1357code2flags10pri0:110r1 node28346208size112:0data0000000000000000

// 3365 is Launcher, 3365:3616 => 956:1356 means from Launcher (3365) rendering thread (3616) to SurfaceFlinger (956) Binder: 956_4 (1357)
proc3365：
outgoing transaction28350131:0000000000000000from3365:3616to956:1357code2flags10pri0:110r1

Here we search for dequeueBuffer to see which Binder thread in SurfaceFlinger that RenderThread is communicating with, and found that it is Binder:956_4.

Corresponding sysTid=1357

"Binder:956_4"sysTid=1357
    #00pc0000000000071a8c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId:340eb42dd36c6541aec54c306eb4d0ee)
    #01pc0000000000075710  /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex(voidvolatile*,bool,int,bool, timespecconst*)+140) (BuildId:340eb42dd36c6541aec54c306eb4d0ee)
    #02pc00000000000d97e8  /apex/com.android.runtime/lib64/bionic/libc.so (pthread_cond_timedwait+120) (BuildId:340eb42dd36c6541aec54c306eb4d0ee)
    #03pc0000000000072df0  /system/lib64/libc++.so (_ZNSt3__118condition_variable15__do_timed_waitERNS_11unique_lockINS_5mutexEEENS_6chrono10time_pointINS5_12system_clockENS5_8durationIxNS_5ratioILl1ELl1000000000EEEEEEE+108) (BuildId:5aad1075509f6e517eb78db32da8fbf6)
    #04pc000000000006f9d8  /system/lib64/libgui.so (android::BufferQueueProducer::waitForFreeSlotThenRelock(android::BufferQueueProducer::FreeSlotCaller, std::__1::unique_lock&,int*)const+788) (BuildId: e017958f19275814d1f2d55ce8b10bfa)
    #05pc000000000006fd8c  /system/lib64/libgui.so (android::BufferQueueProducer::dequeueBuffer(int*, android::sp*,unsignedint,unsignedint,int,unsignedlong,unsignedlong*, android::FrameEventHistoryDelta*)+776) (BuildId: e017958f19275814d1f2d55ce8b10bfa)
    #06pc000000000007f0a8  /system/lib64/libgui.so (android::BnGraphicBufferProducer::onTransact(unsignedint, android::Parcelconst&, android::Parcel*,unsignedint)+3580) (BuildId: e017958f19275814d1f2d55ce8b10bfa)
    #07pc000000000004d67c  /system/lib64/libbinder.so (android::BBinder::transact(unsignedint, android::Parcelconst&, android::Parcel*,unsignedint)+136) (BuildId: bb7ca5d12323a310f26473506cf070ed)
    #08pc000000000005a55c  /system/lib64/libbinder.so (android::IPCThreadState::executeCommand(int)+1008) (BuildId: bb7ca5d12323a310f26473506cf070ed)
    #09pc000000000005a0b8  /system/lib64/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+156) (BuildId: bb7ca5d12323a310f26473506cf070ed)
    #10pc000000000005a898  /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+220) (BuildId: bb7ca5d12323a310f26473506cf070ed)
    #11pc000000000008093c  /system/lib64/libbinder.so (android::PoolThread::threadLoop()+24) (BuildId: bb7ca5d12323a310f26473506cf070ed)
    #12pc0000000000013654  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+328) (BuildId:594f10db565bb0b9cf0223c7a1990ce5)
    #13pc00000000000da200  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36) (BuildId:340eb42dd36c6541aec54c306eb4d0ee)
    #14pc00000000000769d4  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId:340eb42dd36c6541aec54c306eb4d0ee)

It can be seen that it is stuck in waitForFreeSlotThenRelock, and its code logic is in frameworks/native/libs/gui/BufferQueueProducer.cpp. Those interested can check it out themselves.

Being stuck in waitForFreeSlotThenRelock means that there are not enough Buffers, because the number of Buffers corresponding to each Layer is fixed (2 or 3 or 4, generally 3 or 4). If all 4 Buffers are in use, then the application calls dequeueBuffer to apply for a free Buffer will not be successful, and it needs to wait. Here, wait for free buffer times out, resulting in the application’s ANR.

The SurfaceFlinger and hwui parts of the Log also frequently print prompts for problem points.

// SurfaceFlinger Log prompts that the number of available buffers is insufficient
  19:44:42.371   956   956 E BufferQueueConsumer: [com.xxx.launcher/com.xxx.launcher.Launcher#0] acquireBuffer: max acquired buffer count reached: 2 (max 1)
  19:44:42.371   956   956 E BufferLayerConsumer: [com.xxx.launcher/com.xxx.launcher.Launcher#0] updateTexImage: acquire failed: Function not implemented (-38)

// Prompt is dequeueBuffer failed
  19:45:45.127  3365  3616 W OpenGLRenderer: dequeueBuffer failed, error = -110; switching to fallback

  19:45:45.138  3365  3616 I OpenGLRenderer: Davey! duration=4015ms; Flags=0, IntendedVsync=21148991192817, Vsync=21148991192817, OldestInputEvent=9223372036854775807, NewestInputEvent=0, HandleInputStart=21148991206202, AnimationStart=21148991249587, PerformTraversalsStart=21148991252765, DrawStart=21148991798858, SyncQueued=21148991974796, SyncStart=21152137782451, IssueDrawCommandsStart=21152138724534, SwapBuffers=21156150646824, FrameCompleted=21156152280366, DequeueBufferDuration=0, QueueBufferDuration=0,

// MessageQueue information identifies which Message blocks
  19:45:45.142  3365  3365 E ANR_LOG : >>> msg's executing time is too long
  19:45:45.142  3365  3365 E ANR_LOG : Blocked msg = { when=-4s2ms what=0 target=android.view.Choreographer$FrameHandler callback=android.view.Choreographer$FrameDisplayEventReceiver } , cost  = 4002 ms
  19:45:45.142  3365  3365 E ANR_LOG : >>>Current msg List is:
  19:45:45.142  3365  3365 E ANR_LOG : Current msg <1>  = { when=-4s5ms what=13 target=android.view.ViewRootImpl$ViewRootHandler }
  19:45:45.142  3365  3365 E ANR_LOG : Current msg <2>  = { when=-4s1ms what=0 target=android.view.ViewRootImpl$ViewRootHandler callback=com.android.launcher3.util.ViewOnDrawExecutor }
  19:45:45.143  3365  3365 E ANR_LOG : Current msg <3>  = { when=-4s1ms what=0 target=android.view.ViewRootImpl$ViewRootHandler callback=android.widget.Editor$1 }
  19:45:45.143  3365  3365 E ANR_LOG : Current msg <4>  = { when=-3s23ms what=0 target=android.view.ViewRootImpl$ViewRootHandler callback=android.widget.ViewFlipper$2 }
  19:45:45.143  3365  3365 E ANR_LOG : Current msg <5>  = { when=-1s502ms what=6 target=android.view.inputmethod.InputMethodManager$H arg1=74627 obj=android.view.inputmethod.InputMethodManager$PendingEvent@561bec9 }
  19:45:45.143  3365  3365 E ANR_LOG : Current msg <6>  = { when=+14s859ms what=0 target=android.os.Handler callback=xxxUIEngineProguard.i.b$b }
  19:45:45.143  3365  3365 E ANR_LOG : Current msg <7>  = { when=+24d20h30m18s414ms what=0 target=android.view.ViewRootImpl$ViewRootHandler callback=android.widget.ViewFlipper$2 }
  19:45:45.143  3365  3365 E ANR_LOG : >>>CURRENT MSG DUMP OVER<<<

This kind of problem is generally a SurfaceFlinger problem, which can be transferred to the corresponding person in charge for further analysis.

Anomalous Log Examples

Main Thread Database Operation

"main" prio=5 tid=1 Native
held mutexes=
kernel: (couldn't read /proc/self/task/11003/stack)
native: #00 pc 000492a4 /system/lib/libc.so (nanosleep+12)
native: #01 pc 0002dc21 /system/lib/libc.so (usleep+52)
native: #02 pc 00009cab /system/lib/libsqlite.so (???)
native: #03 pc 00011119 /system/lib/libsqlite.so (???)
native: #04 pc 00016455 /system/lib/libsqlite.so (???)
native: #16 pc 0000fa29 /system/lib/libsqlite.so (???)
native: #17 pc 0000fad7 /system/lib/libsqlite.so (sqlite3_prepare16_v2+14)
native: #18 pc 0007f671 /system/lib/libandroid_runtime.so (???)
native: #19 pc 002b4721 /system/framework/arm/boot-framework.oat (Java_android_database_sqlite_SQLiteConnection_nativePrepareStatement__JLjava_lang_String_2+116)
at android.database.sqlite.SQLiteConnection.setWalModeFromConfiguration(SQLiteConnection.java:294)
at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:215)
at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:193)
at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked(SQLiteConnectionPool.java:463)
at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:185)
at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:177)
at android.database.sqlite.SQLiteDatabase.openInner(SQLiteDatabase.java:808)
locked <0x0db193bf> (a java.lang.Object)
at android.database.sqlite.SQLiteDatabase.open(SQLiteDatabase.java:793)
at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:696)
at android.app.ContextImpl.openOrCreateDatabase(ContextImpl.java:690)
at android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:299)
at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:223)
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:163)
locked <0x045a4a8c> (a com.xxxx.video.common.data.DataBaseHelper)
at com.xxxx.video.common.data.DataBaseORM.(DataBaseORM.java:46)
at com.xxxx.video.common.data.DataBaseORM.getInstance(DataBaseORM.java:53)
locked <0x017095d5> (a java.lang.Class)

Large Binder Payloads

07-2104:43:21.573 1000 148812756E Binder  : Unreasonably large binder replybuffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling1size388568(data:1,32,7274595)
07-2104:43:21.573 1000 148812756E Binder  : android.util.Log$TerribleFailure: Unreasonably large binder replybuffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling1size388568(data:1,32,7274595)
07-2104:43:21.607 1000 1488 2951E Binder  : Unreasonably large binder replybuffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling1size211848(data:1,23,7274595)
07-2104:43:21.607 1000 1488 2951E Binder  : android.util.Log$TerribleFailure: Unreasonably large binder replybuffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling1size211848(data:1,23,7274595)
07-2104:43:21.662 1000 1488 6258E Binder  : Unreasonably large binder replybuffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling1size259300(data:1,33,7274595)

Binder Communication Failure

07-2106:04:35.580<6>[32837.690321] binder:1698:2362transaction failed29189/-3,size100-0line3042
07-2106:04:35.594<6>[32837.704042] binder:1765:4071transaction failed29189/-3,size76-0line3042
07-2106:04:35.899<6>[32838.009132] binder:1765:4067transaction failed29189/-3,size224-8line3042
07-2106:04:36.018<6>[32838.128903] binder:1765:2397transaction failed29189/-22,size348-0line2916

Reference

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with you all!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for support~

One person can go faster, a group of people can go further

Android ANR Series 2: ANR Analysis Methodology and Key Logs

2025-02-08T08:29:09.000Z

This is the second article in the Android App ANR series, focusing on ANR analysis methodology and key logs. The series includes:

ANR (Application Not Responding) - a simple definition that encompasses much of Android’s system design philosophy.
First, ANR falls within the application domain. This differs from SNR (System Not Responding), which reflects issues where the system process (system_server) loses responsiveness, while ANR explicitly confines the problem to applications. SNR is ensured by the Watchdog mechanism (details can be found in Watchdog mechanism and problem analysis); ANR is ensured by the message handling mechanism. Android implements a sophisticated mechanism at the system layer to detect ANR, with the core principle being message scheduling and timeout handling.
Second, the ANR mechanism is primarily implemented at the system layer. All ANR-related messages are scheduled by the system process (system_server) and then dispatched to application processes for actual processing. Simultaneously, the system process designs different timeout limits to track message processing. Once an application mishandles a message, the timeout limit takes effect: it collects system states such as CPU/IO usage, process function call stacks, and reports to the user that a process is not responding (ANR dialog; some ROMs don’t display the ANR dialog but directly crash to the home screen).
Third, ANR issues are essentially performance problems. The ANR mechanism actually imposes restrictions on the application’s main thread, requiring it to complete the most common operations (starting services, processing broadcasts, handling input) within specified time limits. If processing times out, the main thread is considered to have lost the ability to respond to other operations. Time-consuming operations on the main thread, such as intensive CPU computations, heavy I/O, complex UI layouts, etc., all reduce the application’s responsiveness.
Finally, some ANR problems are very difficult to analyze. Sometimes due to underlying system influences, message scheduling fails, and the problematic scenario is hard to reproduce. Such ANR issues often require significant time to understand system behaviors, going beyond the scope of the ANR mechanism itself. Some ANR problems are hard to investigate because there are many factors causing system instability, such as memory fragmentation caused by Linux Kernel bugs, hardware damage, etc. Such low-level causes often leave ANR problems untraceable, and these aren’t application issues at all, wasting much time for application developers. If you’ve worked on entire system development and maintenance, you’ll deeply understand this. Therefore, I cannot guarantee that understanding all content in this chapter will solve every ANR problem. If you encounter very difficult ANR issues, I suggest talking to friends working on Framework, drivers, and kernel, or if the problem is just a one-in-a-hundred-thousand phenomenon that doesn’t affect normal program operation, I’d suggest ignoring it.
– From duanqz

ANR Analysis Methodology

ANR problems mainly stem from two causes: application-side issues and system-side anomalies. When analyzing ANR problems, the most important task is to determine which cause is responsible (though there are some gray areas, such as poorly written code that doesn’t manifest under normal conditions but quickly surfaces when the system has problems).

General ANR Analysis Steps:

Check EventLog for specific ANR time (search for am_anr) to see if it matches the ANR log, determining whether the ANR log is valid. If the ANR log is valid, analyze it to extract useful information: pid, tid, deadlocks, etc. When facing ANR problems, we need to question whether the trace before us is the original crime scene. If there is a lot of information output when ANR occurs, and CPU and I/O resources were tight at that time, the log output timestamp might be delayed by 10 to 20 seconds. So we sometimes need to be vigilant. However, normally, the am_anr output time in EventLog is the earliest and closest to the actual ANR time.
Check MainLog (Android Log) or SystemLog for ANR details (search for “ANR in”), extracting effective information:
1. Time when ANR occurred
2. Process that printed the ANR log
3. Process where ANR occurred
4. Reason for ANR
5. CPU load
6. Memory load
7. CPU usage statistics time period
8. CPU usage rate of each process
  1. Total CPU usage rate
  2. Page fault counts
    1. xxx minor indicates page faults in cache, which can be understood as the process performing memory access
    2. xxx major indicates page faults in memory, which can be understood as the process performing I/O operations
9. CPU usage summary
Combine MainLog (Android Log) and EventLog to extract all useful information within the CPU start and end time points into a file:
1. Collect key operations, such as unlock, app installation, screen on/off, app launch, etc.
2. Collect exceptions and system key logs:
  1. System slowdown: such as Slow operation, Slow dispatch, Slow delivery, dvm_lock_sample
  2. Process changes: am_kill, am_proc_died, lowmemorykiller, ANR, app launch relationships, etc.
  3. System information: cpu info, meminfo, binder info (whether full), iowait (whether too high)
3. Collect all key thread running conditions and thread priorities of the ANR process
4. Based on the key information file extracted in step 4, further understand the system’s situation and state at that time (recommend using vscode or notepad++ with global search for clues), such as:
  1. Was it in low memory frequently killing processes?
  2. First unlock after reboot with system busy?
  3. Multiple app launches in short time causing system busy?
  4. Or application’s own logic waiting?
If still unclear, add logs to reproduce.

Distinguishing Between Application Problems and System Problems

First, Analyze Whether It’s an Application Problem

The key to analyzing application problems is to understand what the user was doing at that time and what role the application played during this user operation, then proceed with further analysis:

Analyze whether there are time-consuming operations in key component lifecycles that might not be exposed normally but surface when system load increases (suggest adding corresponding logs in key lifecycle functions for easier debugging).
Analyze whether extreme situations occurred causing application logic to be time-consuming, such as large amounts of data processing or import, too many threads running simultaneously, etc. (check application’s CPU / IO usage).
Analyze whether deadlocks exist.
Analyze whether waiting for binder return.
Analyze whether MainThread and RenderThread have abnormalities in Trace files.
Analyze whether MainThread and WorkerThread have waiting relationships in Trace files.

Analyze System State

Check CPU usage (CPU usage rate and CPU load), see if system-related processes or threads like SystemServer, lowmemorykiller, HeapTaskDeamon, Audio, SurfaceFlinger occupy high resources.
Check whether significant IO situations exist, check IO load:
1. faults: 118172 minor (page faults in cache).
2. major (page faults in memory).
Check whether system is in low memory:
1. Check dumpsys meminfo results to see if in low memory.
2. Check kernel log for frequent lowmemorykiller.
3. Check event log for frequent applications killed by system low memory policy.
4. Check kswapd0.
Whether application is frozen: Application in D state, ANR occurs. If the last operation is refriger, then the application was frozen. Normally caused by power optimization; check if there are xxxHansManager : unfreeze logs around; or in Systrace’s Kernel Callstack containing: {kernel callsite when blocked:: "\_\_refrigerator+0xe4/0x198"}.
Check for system anomalies: For instance, custom features causing system business, failing to respond to application Binder requests in time. This requires analyzing SystemServer logs in the Log to see if there are abnormal log outputs.

Continue Analysis: Can Application Resolve It or System Resolve It?

If the ANR problem is transferred to the system side, there is a high probability it’s unsolvable by the app.
If the application code is normal, and there are no extreme usage scenarios or data processing, purely caused by the system or other Apps, then it can be considered a system issue.
If the application code itself has certain issues, which are not exposed in non-extreme scenarios or non-system anomalies, then the application needs to consider mitigation plans.

ANR Log Content

Logs can be captured via test tools, obtained from online platforms, or captured manually:

1	adb bugreport log.zip

ANR Trace Log contains the following content:

Thread Details

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72c8bbf8 self=0xb400007b0ec10800
  | sysTid=5991 nice=-10 cgrp=default sched=0/0 handle=0x7b95f61500
  | state=S schedstat=( 807053249 267562324 1494 ) utm=63 stm=17 core=3 HZ=100
  | stack=0x7fcccd9000-0x7fcccdb000 stackSize=8192KB
  | held mutexes=
  native: #00 pc 00000000000c6418  /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
  native: #01 pc 0000000000019a9c  /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
  native: #02 pc 000000000001997c  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
  native: #03 pc 0000000000114310  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:339)
  at android.os.Looper.loop(Looper.java:198)
  at android.app.ActivityThread.main(ActivityThread.java:8142)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

Ideally, the meaning of some fields in the Trace above:

Thread Stack

Below is the call stack corresponding to the thread:

native: #00 pc 00000000000c6418 /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
native: #01 pc 0000000000019a9c /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
native: #02 pc 000000000001997c /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
native: #03 pc 0000000000114310 /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
at android.os.MessageQueue.nativePollOnce(Native method)
at android.os.MessageQueue.next(MessageQueue.java:339)
at android.os.Looper.loop(Looper.java:198)
at android.app.ActivityThread.main(ActivityThread.java:8142)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

Divided into Java and Native. Generally speaking, nativePollOnce is waiting for a Message, which is normal.

Thread State

There is a correspondence between the state in Thread.java and the state in Thread.cpp. It can be seen that the former is more generalized and easier to understand, oriented towards Java users; while the latter is more detailed, oriented towards the internal environment of the virtual machine. The thread states displayed in traces.txt are defined in Thread.cpp. The complete correspondence is as follows:

art/runtime/thread_state.h

// State stored in our C++ class Thread.
// When we refer to "a suspended state", or when function names mention "ToSuspended" or
// "FromSuspended", we mean any state other than kRunnable, i.e. any state in which the thread is
// guaranteed not to access the Java heap. The kSuspended state is merely one of these.
enum ThreadState {
  //                                   Java
  //                                   Thread.State   JDWP state
  kTerminated = 66,                 // TERMINATED     TS_ZOMBIE    Thread.run has returned, but Thread* still around
  kRunnable,                        // RUNNABLE       TS_RUNNING   runnable
  kTimedWaiting,                    // TIMED_WAITING  TS_WAIT      in Object.wait() with a timeout
  kSleeping,                        // TIMED_WAITING  TS_SLEEPING  in Thread.sleep()
  kBlocked,                         // BLOCKED        TS_MONITOR   blocked on a monitor
  kWaiting,                         // WAITING        TS_WAIT      in Object.wait()
  kWaitingForLockInflation,         // WAITING        TS_WAIT      blocked inflating a thin-lock
  kWaitingForTaskProcessor,         // WAITING        TS_WAIT      blocked waiting for taskProcessor
  kWaitingForGcToComplete,          // WAITING        TS_WAIT      blocked waiting for GC
  kWaitingForCheckPointsToRun,      // WAITING        TS_WAIT      GC waiting for checkpoints to run
  kWaitingPerformingGc,             // WAITING        TS_WAIT      performing GC
  kWaitingForDebuggerSend,          // WAITING        TS_WAIT      blocked waiting for events to be sent
  kWaitingForDebuggerToAttach,      // WAITING        TS_WAIT      blocked waiting for debugger to attach
  kWaitingInMainDebuggerLoop,       // WAITING        TS_WAIT      blocking/reading/processing debugger events
  kWaitingForDebuggerSuspension,    // WAITING        TS_WAIT      waiting for debugger suspend all
  kWaitingForJniOnLoad,             // WAITING        TS_WAIT      waiting for execution of dlopen and JNI on load code
  kWaitingForSignalCatcherOutput,   // WAITING        TS_WAIT      waiting for signal catcher IO to complete
  kWaitingInMainSignalCatcherLoop,  // WAITING        TS_WAIT      blocking/reading/processing signals
  kWaitingForDeoptimization,        // WAITING        TS_WAIT      waiting for deoptimization suspend all
  kWaitingForMethodTracingStart,    // WAITING        TS_WAIT      waiting for method tracing to start
  kWaitingForVisitObjects,          // WAITING        TS_WAIT      waiting for visiting objects
  kWaitingForGetObjectsAllocated,   // WAITING        TS_WAIT      waiting for getting the number of allocated objects
  kWaitingWeakGcRootRead,           // WAITING        TS_WAIT      waiting on the GC to read a weak root
  kWaitingForGcThreadFlip,          // WAITING        TS_WAIT      waiting on the GC thread flip (CC collector) to finish
  kNativeForAbort,                  // WAITING        TS_WAIT      checking other threads are not run on abort.
  kStarting,                        // NEW            TS_WAIT      native thread started, not yet ready to run managed code
  kNative,                          // RUNNABLE       TS_RUNNING   running in a JNI native method
  kSuspended,                       // RUNNABLE       TS_RUNNING   suspended by GC or debugger
};

In the Trace file, the last line of the thread name identifies the current state of the thread.

Normal Main Thread Trace

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72c8bbf8 self=0xb400007b0ec10800
  | sysTid=5991 nice=-10 cgrp=default sched=0/0 handle=0x7b95f61500
  | state=S schedstat=( 807053249 267562324 1494 ) utm=63 stm=17 core=3 HZ=100
  | stack=0x7fcccd9000-0x7fcccdb000 stackSize=8192KB
  | held mutexes=
  native: #00 pc 00000000000c6418  /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
  native: #01 pc 0000000000019a9c  /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
  native: #02 pc 000000000001997c  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
  native: #03 pc 0000000000114310  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:339)
  at android.os.Looper.loop(Looper.java:198)
  at android.app.ActivityThread.main(ActivityThread.java:8142)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

Abnormal Main Thread Trace

"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x70f65400 self=0xe28dae00
  | sysTid=22002 nice=-10 cgrp=default sched=0/0 handle=0xe9674474
  | state=S schedstat=( 1943159901 290647362 1661 ) utm=159 stm=34 core=7 HZ=100
  | stack=0xff041000-0xff043000 stackSize=8192KB
  | held mutexes=
  at com.facebook.cache.disk.DiskStorageCache.e(DiskStorageCache.java:3)
  - waiting to lock <0x0e57c91f> (a java.lang.Object) held by thread 89
  at com.xxx.community.util.imageloader.FrescoImageLoader.a(FrescoImageLoader.java:18)
  at com.xxx.community.util.imageloader.FrescoImageLoader$2$1.run(FrescoImageLoader.java:2)
  at android.os.Handler.handleCallback(Handler.java:938)
  at android.os.Handler.dispatchMessage(Handler.java:99)
  at android.os.Looper.loop(Looper.java:254)
  at android.app.ActivityThread.main(ActivityThread.java:8142)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1006)

CPU Usage Analysis

Searching for the keyword ANR in reveals the CPU usage within a period of time before the ANR. The parsing is as follows:

ActivityManager: ANR in com.xxx.launcher (com.xxx.launcher/.Launcher)(Process Name)
ActivityManager: PID: 5991(Process PID)
ActivityManager: Reason: Input dispatching timed out (6a6083a com.xxx.launcher/com.xxx.launcher.Launcher (server) is not responding. Waited 5001ms for FocusEvent(hasFocus=true))(Reason)
ActivityManager: Parent: com.xxx.launcher/.Launcher
ActivityManager: Load: 15.29 / 5.19 / 1.87(Load indicates CPU load for 1 min, 5 min, 15 min)
ActivityManager: ----- Output from /proc/pressure/memory -----(Memory Pressure)
ActivityManager: somavg10=1.35 avg60=0.31 avg300=0.06 total=346727
ActivityManager: full avg10=0.00 avg60=0.00 avg300=0.00 total=34803
ActivityManager: ----- End output from /proc/pressure/memory -----

// CPU usage within 13s
ActivityManager: CPU usage from 0ms to 13135ms later (2020-09-09 02:09:54.942 to 2020-09-09 02:10:08.077):
ActivityManager:   191%(Total CPU Usage) 1948/system_server: 72%(User Space Usage) user + 119%(Kernel Space Usage) kernel / faults: 78816 minor 9 major
ActivityManager:     10% 2218/android.bg: 3.6% user + 6.6% kernel
ActivityManager:   30% 5991/com.xxx.launcher: 23% user + 6.4% kernel / faults: 118172 minor(Minor page faults) 2 major(Major Page faults)
ActivityManager:     16% 6174/launcher-loader: 13% user + 2.8% kernel
ActivityManager:     3.9% 5991/m.xxx.launcher: 3.1% user + 0.8% kernel
ActivityManager:   20% 6549/com.xxx.xxx: 16% user + 3.7% kernel / faults: 3541 minor
ActivityManager:     10% 6889/DBCacheManager: 8.7% user + 1.2% kernel
ActivityManager:     9.4% 6942/DefaultDispatch: 7.1% user + 2.2% kernel

// CPU usage of each thread of each process within 1s
ActivityManager: CPU usage from 246ms to 1271ms later (2020-09-09 02:09:55.188 to 2020-09-09 02:09:56.213):
ActivityManager:   290% 1948/system_server: 114% user + 176% kernel / faults: 9353 minor
ActivityManager:     32% 5159/LockSettingsSer: 29% user + 2.9% kernel
ActivityManager:     25% 8661/AnrConsumer: 8.8% user + 16% kernel
ActivityManager:   44% 5991/com.xxx.launcher: 37% user + 7.4% kernel / faults: 5756 minor
ActivityManager:     16% 6174/launcher-loader: 13% user + 3.7% kernel
ActivityManager:     14% 5991/m.xxx.launcher: 14% user + 0% kernel
ActivityManager:   37% 6549/com.xxx.xxx: 28% user + 9.3% kernel / faults: 153 minor
ActivityManager:     37% 6942/DefaultDispatch: 28% user + 9.3% kernel
ActivityManager:   20% 5962/com.android.phone: 14% user + 5.5% kernel / faults: 1345 minor
ActivityManager:     11% 5962/m.android.phone: 7.4% user + 3.7% kernel

CPU Load

1	ActivityManager: Load: 15.29 / 5.19 / 1.871

The three numbers after Load mean the average system load in 1 minute, 5 minutes, and 15 minutes respectively. When the CPU is completely idle, the average load is 0; when the CPU workload is saturated, the average load is 1. The Load helps to judge whether the system load is too heavy.

There is a vivid metaphor: Imagine the CPU as a bridge with only one lane. All vehicles must pass through this lane. A system load of 0 means there are no cars on the bridge. A system load of 0.5 means half of the bridge section has cars. A system load of 1.0 means all sections of the bridge have cars, that is, the bridge is already “full”. A system load of 2.0 means there are too many vehicles, the bridge is already full (100%), and there are clearly as many vehicles waiting to get on the bridge. The traffic capacity of the bridge is the maximum workload of the CPU; the vehicles on the bridge are the waiting processes.

The rule of thumb is:

When the system load is consistently greater than 0.7, you must verify it, where is the problem, to prevent the situation from getting worse.
When the system load is consistently greater than 1.0, you must find a solution to bring this value down.
When the system load reaches 5.0, it indicates that your system has serious problems.

Modern mobile phones use multi-core CPU architectures. Eight cores are common, meaning the CPU processing capacity is multiplied by 8. The running time of each core can be obtained from the following file: /sys/devices/system/cpu/cpu%d/cpufreq/stats/time_in_state, where %d represents the CPU core. The file records the running time of the CPU at various frequencies from boot to reading the file, unit: 10 ms.

Memory Load

ActivityManager: ----- Output from /proc/pressure/memory -----(Memory Pressure)
ActivityManager: somavg10=1.35 avg60=0.31 avg300=0.06 total=346727
ActivityManager: full avg10=0.00 avg60=0.00 avg300=0.00 total=34803
ActivityManager: ----- End output from /proc/pressure/memory -----

Memory load is obtained from /proc/pressure/memory.

avg10, avg60, avg300 represent the percentage of blocking time within the time period of 10s, 60s, and 300s respectively. total is the total accumulated time in milliseconds.

The some line represents the percentage of time that at least one task is blocked on a certain resource. The full line represents the percentage of time that all non-idle tasks are blocked at the same time. During this period, the CPU is completely wasted, which will bring serious performance problems. Let’s take IO some and full as an example. Suppose that in a 60-second time period, the system has two tasks. The running status within the 60-second cycle is shown in the figure below:

The red shaded part indicates that the task enters the blocked state due to waiting for IO resources. The part where Task A and Task B are blocked at the same time is full, accounting for 16.66%; the part where at least one task is blocked (including the part where only Task B is blocked) is some, accounting for 50%.

some and full are the sum of the proportion of blocking time within a certain period of time. The blocking time is not necessarily continuous, as shown in the figure below:

For details, please refer to the article by Kernel Craftsman: https://blog.csdn.net/feelabclihu/article/details/105534140

IO Load

1	ActivityManager: 30% 5991/com.xxx.launcher: 23% user + 6.4% kernel / faults: 118172 minor(cache page faults) 2 major(memory page faults)

Minor: Page faults in high-speed cache, referring to Minor Page Fault (MnPF). When disk data is loaded into memory, the kernel will issue an MnPF message when reading it again. When a file is read and written for the first time, there will be many MPFs. After being cached into memory, accessing MPF again will be very few, and MnPF will increase instead. This is the result of the caching technology adopted by the kernel to reduce inefficient disk I/O operations. It can be understood as the process performing memory access.
Major: Page faults in memory, referring to Major Page Fault (MPF). When the kernel reads data, it will search the CPU’s high-speed cache and physical memory successively. If not found, it will issue an MPF message requesting to load data into memory. It can be understood as the process performing IO operations.

If there are a large number of major, it means that the IO operation load was relatively high at that time.

Process Load

1	ActivityManager: 30% 5991/com.xxx.launcher: 23% user + 6.4% kernel / faults: 118172 minor(Minor page faults) 2 major(Major Page faults)

23% user: cpu usage in user mode
6.4% kernel: cpu usage in kernel mode

CPU Anomalous Process

SystemServer cpu usage is high: the overall system operation will be slow.
kswapd0 cpu usage is high: the overall system operation will be slow, causing various ANRs. Transfer the problem to “Memory Optimization” and ask them to optimize.
logd CPU usage is high: causes system lag and ANR because the operation of each process outputting LOG is blocked and executes extremely slowly.
Vold CPU usage is too high: causes system lag and ANR, please verify with the colleague responsible for storage first.
Application itself CPU usage is high: high probability of the application’s own problem.
Application is in D state, ANR occurs: If the last operation is refriger, then the application is frozen. Normally, it is caused by power consumption optimization. You can check whether there is a Log like xxxHansManager : unfreeze before and after; or in Systrace, the Kernel Callstack shows: {kernel callsite when blocked:: "__refrigerator+0xe4/0x198"}.
“+” before CPU usage rate: Some processes have a “+” sign before their CPU usage rate, such as cat and zygote64, indicating that these processes did not exist in the last CPU statistics time slice, but ran in this CPU statistics time slice. Similarly, there is a “-“ sign, indicating that these processes died during the two CPU statistics time slices.

Key System Log Introduction

Application Freezing

1	xxxHansManager : freeze uid: 10245 package: com.tencent.mm reason: LcdOff

If the freezing logic has a Bug, it will also cause the application to generate an ANR. This line of Log is relatively simple, mainly the frozen process information and the reason for freezing.

ActivityManager : Slow operation

When AMS performs key tasks, if the task takes longer than 50 ms, it will print the corresponding Log.

frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

void checkTime(long startTime, String where) {
    long now = SystemClock.uptimeMillis();
    if ((now-startTime) > 50) {
        // If we are taking more than 50ms, log about it.
        Slog.w(TAG, "Slow operation: " + (now-startTime) + "ms so far, now at " + where);
    }
}

The corresponding Log is as follows. If such Logs are printed frequently in the system, it means that the system is currently in a relatively stuck state, and system factors must be considered during analysis.

1
2
3

ActivityManager: Slow operation: 138ms so far, now at startProcess: done updating battery stats
ActivityManager: Slow operation: 138ms so far, now at startProcess: building log message
ActivityManager: Slow operation: 138ms so far, now at startProcess: starting to update pids map

Looper : Slow dispatch

1	Looper : Slow dispatch took 418ms main h=android.app.ActivityThread$H c=android.app.-$$Lambda$LoadedApk$ReceiverDispatcher$Args$_BumDX2UKsnxLVrE6UJsJZkotuA@e68bdc4 m=0

Looper : Slow delivery

1	Looper : Slow delivery took 361ms android.ui h=com.android.server.am.ActivityManagerService$UiHandler c=null m=53

Looper：Slow Looper

W/Looper: Slow Looper main: Activity com.androidperformance.memoryfix/.MainActivity is 439ms late (wall=0ms running=0ms ClientTransaction{ callbacks=[android.app.servertransaction.TopResumedActivityChangeItem] }) because of 3 msg, msg 2 took 268ms (seq=2 running=207ms runnable=15ms late=1ms h=android.app.ActivityThread$H w=110), msg 3 took 171ms (seq=3 running=140ms runnable=5ms io=1ms late=268ms h=android.app.ActivityThread$H w=159)

onTrimMemory

1	ClockTag AlarmClockApplication: onTrimMemory: 80

dvm_lock_sample

When the blocked time of a thread waiting for a lock exceeds the threshold (for example: 500ms), the current lock holding status is output.

1	dvm_lock_sample：[system_server,1,Binder_9,1500,ActivityManagerService.java,6403,-,1448,0]

system_server: Binder_9 executes to line 6403 of ActivityManagerService.java, and has been waiting for the AMS lock.
“-“ means that the lock is held by the same file, that is, the lock is held by line 1448 of the same file code, causing the Binder_9 thread to be blocked for 1500ms.

binder_sample

binder_sample: Monitors the binder transaction duration of the main thread of each process. When it exceeds the threshold (for example: 500ms), the corresponding target call information is output.

1	6628 6628 I binder_sample: [android.view.accessibility.IAccessibilityManager,6,2010,com.xxx.community,100]

The process is 6628, main thread 6628
Executing android.view.accessibility.IAccessibilityManager interface
The corresponding method code = 6 (i.e., TRANSACTION_addAccessibilityInteractionConnection)
The time spent is 2010 ms
The package where the block is located is com.xxx.community
The last parameter is the sample ratio

Find the corresponding interface function, such as which function corresponds to Code = 6 in IAccessibilityManager in the above example. You can search for FIRST_CALL_TRANSACTION in cs.android.com, click call, and then view the corresponding IAccessibilityManager file in the out directory (scroll all the way down until you can search for IAccessibilityManager).

Among them, the corresponding static final int TRANSACTION_addAccessibilityInteractionConnection = (android.os.IBinder.FIRST_CALL_TRANSACTION + 5)

Long monitor contention

16809 14216 W system_server: Long monitor contention with owner InputDispatcher (17039) at android.content.res.Configuration com.android.server.wm.ActivityTaskManagerService.getGlobalConfigurationForPid(int)(ActivityTaskManagerService.java:1066) waiters=0 in boolean com.android.server.wm.WindowProcessController.hasActivities() for 141ms

art/runtime/monitor.cc

std::string Monitor::PrettyContentionInfo(const std::string& owner_name,
                                          pid_t owner_tid,
                                          ArtMethod* owners_method,
                                          uint32_t owners_dex_pc,
                                          size_t num_waiters) {
  Locks::mutator_lock_->AssertSharedHeld(Thread::Current());
  const char* owners_filename;
  int32_t owners_line_number = 0;
  if (owners_method != nullptr) {
    TranslateLocation(owners_method, owners_dex_pc, &owners_filename, &owners_line_number);
  }
  std::ostringstream oss;
  oss << "monitor contention with owner " << owner_name << " (" << owner_tid << ")";
  if (owners_method != nullptr) {
    oss << " at " << owners_method->PrettyMethod();
    oss << "(" << owners_filename << ":" << owners_line_number << ")";
  }
  oss << " waiters=" << num_waiters;
  return oss.str();
}

Binder Thread

When the thread pool of processes such as system_server is used up and there are no idle threads, binder communication is in a starvation state. If the starvation state exceeds a certain threshold, information is output.

1	E IPCThreadState: binder thread pool (31 threads) starved for 120 ms

am_kill

1	am_kill : [0,18555,com.sina.weibo.image,945,remove task]1

In the sentence above, remove task refers to the reason why this application was killed.

The following are the Reasons corresponding to various killed situations. Sometimes we need to see the reason why the application was killed to judge whether the system is normal or the user’s operation steps:

force-stop

Abnormal Process Kill

Active Process Kill

Schedueled Process Kill

Other Process Kill

All the process kills introduced above call the ProcessRecord.kill() method, which inevitably outputs the corresponding EventLog. So what other scenarios of killing processes will not output log?

Process.killProcess(int pid) // Can kill any specified process, or send signal directly
adb shell kill -9 pid // Can kill any specified process
Killed by lmk directly

That is to say, if a process is killed without log output, it may be killed by directly calling kill or sending a signal, or perhaps killed by lmk.

am_proc_died

1	am_proc_died: [0,13210,com.xxx.gallery3d,935,19]

am_anr

1	am_anr : [0,8769,com.android.updater,952680005,Broadcast of Intent { act=android.intent.action.BOOT_COMPLETED flg=0x9000010 cmp=com.android.updater/.BootCompletedReceiver (has extras) }]

Process pid: 8769
Process name: com.android.updater
The type of ANR occurred is: Specific class or reason for BroadcastTimeout: { act=android.intent.action.BOOT_COMPLETED flg=0x9000010 cmp=com.android.updater/.BootCompletedReceiver (has extras) }

Lowmemorykiller

The log of lowmemorykiller is in the kernel log.

1 2	lowmemorykiller: Kill 'com.heytap.themestore' (15545), uid 10136, oom_adj 995 to free 105068kB lowmemorykiller: Reclaimed 105068kB at oom_adj 606

Killing applications through the lowmemorykiller mechanism:

com.heytap.themestore process name
15545: PID
10136: UID
995: oom_adj
105068kB: released memory
606: min_adj

Blocked msg

Internally added Log, when the execution time of Message exceeds 1.5s, the following Log will be printed. From the following Log, we can see:

The Message that timed out, and the execution time of this Message
The Message blocked by this Message

From this Log, you can observe whether your Message execution blocked other Messages or your Message was blocked by other Messages.

E ANR_LOG : >>> msg's executing time is too long
E ANR_LOG : Blocked msg = { when=-32s683ms what=110 target=android.app.ActivityThread$H obj=AppBindData{appInfo=ApplicationInfo{bd8d51e com.android.contacts}} } , cost  = 32436 ms
E ANR_LOG : >>>Current msg List is:
E ANR_LOG : Current msg <1>  = { when=-32s672ms what=140 target=android.app.ActivityThread$H arg1=5 }
E ANR_LOG : Current msg <2>  = { when=-32s671ms what=114 target=android.app.ActivityThread$H obj=CreateServiceData{token=android.os.BinderProxy@f7611ff className=com.android.contacts.xxxAppServicesManagerClient packageName=com.android.contacts intent=null} }
E ANR_LOG : Current msg <3>  = { when=-32s671ms what=121 target=android.app.ActivityThread$H obj=BindServiceData{token=android.os.BinderProxy@f7611ff intent=Intent { cmp=com.android.contacts/.xxxAppServicesManagerClient }} }
E ANR_LOG : Current msg <4>  = { when=-31s658ms what=1 target=android.os.AsyncTask$InternalHandler obj=android.os.AsyncTask$AsyncTaskResult@75e517c }
E ANR_LOG : Current msg <5>  = { when=-29s750ms what=140 target=android.app.ActivityThread$H arg1=10 }
E ANR_LOG : Current msg <6>  = { when=-29s103ms what=118 target=android.app.ActivityThread$H obj={1.0 460mcc3mnc [zh_CN] ldltr sw360dp w360dp h622dp 480dpi nrml long port finger -keyb/v/h -nav/h appBounds=Rect(0, 0 - 1080, 1920) s.10mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0}
E ANR_LOG : Current msg <7>  = { when=-28s370ms what=118 target=android.app.ActivityThread$H obj={1.0 460mcc11mnc [zh_CN] ldltr sw360dp w360dp h622dp 480dpi nrml long port finger -keyb/v/h -nav/h appBounds=Rect(0, 0 - 1080, 1920) s.11mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0} }
E ANR_LOG : Current msg <8>  = { when=-27s821ms what=122 target=android.app.ActivityThread$H obj=BindServiceData{token=android.os.BinderProxy@f7611ff intent=Intent { cmp=com.android.contacts/.xxxAppServicesManagerClient }} }
E ANR_LOG : Current msg <9>  = { when=-27s821ms what=116 target=android.app.ActivityThread$H obj=android.os.BinderProxy@f7611ff }
E ANR_LOG : Current msg <10>  = { when=-27s654ms what=114 target=android.app.ActivityThread$H obj=CreateServiceData{token=android.os.BinderProxy@e23cf1b className=com.android.contacts.xxxAppServicesManagerClient packageName=com.android.contacts intent=null} }
E ANR_LOG : >>>CURRENT MSG DUMP OVER<<<

Common Scenario Logs Introduction

Screen Off Log

The key is power_screen_broadcast_done, screen_toggled and power_screen_state.

1810  2470 I intercept_power: [ACTION_DOWN,1,0]
1810  2470 I intercept_power: [ACTION_UP,0,0]
1810  2470 I power_sleep_requested: 0

1810  1810 I power_screen_state: [0,2,0,0,1254]
1810  1810 I screen_toggled: 0 // 0 means screen off, 1 means screen on
1810  1810 I power_screen_broadcast_send: 1
1810  1825 I wm_set_keyguard_shown: [1,0,0,setKeyguardShown] // (keyguardShowing|1),(aodShowing|1),(keyguardGoingAway|1),(Reason|3)

2768  2768 I sysui_status_bar_state: [1,1,0,0,0,1]

1810  1810 I power_screen_broadcast_done: [0,611,1] // 0 means screen off, 611 is screen off time

Screen On Log

The key is power_screen_broadcast_done, screen_toggled and power_screen_state.

Where power_screen_state:

offOrOn|1|5
becauseOfUser|1|5
totalTouchDownTime|2|3
touchCycles|1|1
latency|1|3

1810  2470 I intercept_power: [ACTION_DOWN,1,0]
1810  2470 I intercept_power: [ACTION_UP,1,0]
1810  1810 I screen_toggled: 1 // 1 means screen on
1810  1810 I power_screen_broadcast_send: 1
1810  1810 I power_screen_state: [1,0,0,0,319]
1810  1810 I power_screen_broadcast_done: [1,633,1] // 1 means screen on, 633 is screen on time

Unlock Complete Log

Values of wm_set_keyguard_shown:

(keyguardShowing|1): Whether Keyguard is showing
(aodShowing|1): Whether aodShowing is showing
(keyguardGoingAway|1): Keyguard disappearing
(Reason|3): Reason

 1810  5711 I wm_set_keyguard_shown: [1,0,1,keyguardGoingAway]
// Launcher Resume
 1810  5711 I wm_set_resumed_activity: [0,com.xxx.launcher/.Launcher,resumeTopActivityInnerLocked]
 1810  5711 I wm_resume_activity: [0,93093883,63,com.xxx.launcher/.Launcher]
20615 20615 I wm_on_restart_called: [93093883,com.xxx.launcher.Launcher,performRestartActivity]
20615 20615 I wm_on_start_called: [93093883,com.xxx.launcher.Launcher,handleStartActivity]
20615 20615 I wm_on_resume_called: [93093883,com.xxx.launcher.Launcher,RESUME_ACTIVITY]
20615 20615 I wm_on_top_resumed_gained_called: [93093883,com.xxx.launcher.Launcher,topWhenResuming]

 1810  5711 I wm_set_keyguard_shown: [0,0,1,setKeyguardShown] // keyguard not showing, aod not showing, keyguardGoingAway, reason is called setKeyguardShown to show desktop

Notification Panel Pull Down Log

2768  2768 I sysui_multi_action: [757,803,799,panel_open,802,1]
2768  2768 I sysui_multi_action: [757,1328,758,4,1326,29,1327,0,1329,0]
1810  3004 I notification_visibility: [-1|android|55|null|1000,1,457483196,457483196,0,4]
1810  3004 I notification_visibility: [0|com.android.systemui|10005|null|10132,1,97168545,97168545,0,2]
1810  3004 I notification_visibility: [0|com.android.systemui|2147483647|ranker_group|10132|ranker_group,1,97168236,97168236,0,1]
1810  3004 I notification_visibility: [-1|com.android.systemui|10006|null|10132,1,82586063,82586063,0,0]

Notification Panel Collapse Log

2768  2768 I sysui_multi_action: [757,111,758,2]
1810  5473 I notification_visibility: [-1|android|55|null|1000,0,457546516,457546516,0,4]
1810  5473 I notification_visibility: [0|com.android.systemui|10005|null|10132,0,97231865,97231865,0,2]
1810  5473 I notification_visibility: [0|com.android.systemui|2147483647|ranker_group|10132|ranker_group,0,97231557,97231557,0,1]
1810  5473 I notification_visibility: [-1|com.android.systemui|10006|null|10132,0,82649384,82649384,0,0]

App Launch Log

// Create Task
1810  5473 I wm_task_created: [100,-1]
1810  5473 I wm_stack_created: 100
1810  5473 I wm_create_task: [0,100]

// Create Activity
1810  5473 I wm_create_activity: [0,231348670,100,com.androidperformance.memoryfix/.MainActivity,android.intent.action.MAIN,NULL,NULL,270532608]

// Launcher goes through pause flow
1810  5473 I wm_pause_activity: [0,93093883,com.xxx.launcher/.Launcher,userLeaving=true]
0615 20615 I wm_on_top_resumed_lost_called: [93093883,com.xxx.launcher.Launcher,topStateChangedWhenResumed]
0615 20615 I wm_on_paused_called: [93093883,com.xxx.launcher.Launcher,performPause]
1810  3720 I wm_add_to_stopping: [0,93093883,com.xxx.launcher/.Launcher,makeInvisible]

// Start Activity
1810  2045 I am_proc_start: [0,18803,10263,com.androidperformance.memoryfix,pre-top-activity,{com.androidperformance.memoryfix/com.androidperformance.memoryfix.MainActivity}]
1810  3428 I am_proc_bound: [0,18803,com.androidperformance.memoryfix]
1810  3428 I wm_restart_activity: [0,231348670,100,com.androidperformance.memoryfix/.MainActivity]
1810  3428 I wm_set_resumed_activity: [0,com.androidperformance.memoryfix/.MainActivity,minimalResumeActivityLocked]
8803 18803 I wm_on_create_called: [231348670,com.androidperformance.memoryfix.MainActivity,performCreate]
8803 18803 I wm_on_start_called: [231348670,com.androidperformance.memoryfix.MainActivity,handleStartActivity]
8803 18803 I wm_on_resume_called: [231348670,com.androidperformance.memoryfix.MainActivity,RESUME_ACTIVITY]
8803 18803 I wm_on_top_resumed_gained_called: [231348670,com.androidperformance.memoryfix.MainActivity,topStateChangedWhenResumed]
1810  2034 I wm_activity_launch_time: [0,231348670,com.androidperformance.memoryfix/.MainActivity,471]

// Launcher goes through stop flow
1810  1978 I wm_stop_activity: [0,93093883,com.xxx.launcher/.Launcher]
0615 20615 I wm_on_stop_called: [93093883,com.xxx.launcher.Launcher,STOP_ACTIVITY_ITEM]

// App launch from Launcher, focus change: Launcher => null => App
WindowManager: Changing focus from Window{b0416d7 u0 com.xxx.launcher/com.xxx.launcher.Launcher} to null,diplayid=0
WindowManager: Changing focus from null to Window{10f5145 u0 com.android.settings/com.android.settings.Settings},diplayid=0

// Return to Launcher from App, focus change: App => null => Launcher
WindowManager: Changing focus from Window{10f5145 u0 com.android.settings/com.android.settings.Settings} to null,diplayid=0
WindowManager: Changing focus from null to Window{b0416d7 u0 com.xxx.launcher/com.xxx.launcher.Launcher},diplayid=0

// Enter Lockscreen from App interface: focus change: App => null => Lockscreen
WindowManager: Changing focus from Window{10f5145 u0 com.android.settings/com.android.settings.Settings} to null,diplayid=0
WindowManager: Changing focus from null to Window{82e5f30 u0 NotificationShade},diplayid=0

// Unlock from Lockscreen interface to App, focus change: Lockscreen => App
WindowManager: Changing focus from Window{82e5f30 u0 NotificationShade} to Window{10f5145 u0 com.android.settings/com.android.settings.Settings},diplayid=0

Reference

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with you all!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Excellent Blog Articles Collected and Organized by Individuals - Must-Know for Android Performance Optimization: Welcome everyone to recommend yourself and recommend (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for support~

One person can go faster, a group of people can go further

Android ANR Series 1: Understanding Android ANR Design Philosophy

2025-02-08T08:28:17.000Z

This is the first article in the Android App ANR series, mainly analyzing the design philosophy of Android ANR from a system perspective. The series directory is as follows:

1. Universality and Complexity of ANR

In the Android ecosystem, Application Not Responding (ANR) is not only a common challenge for developers but also a core embodiment of system design philosophy. Although ANR is often simplified as a synonym for “time-consuming operations on the main thread,” this superficial understanding is far from enough to reveal the essence of the problem. In fact, the root cause of ANR lies in the complex synergy between Android’s multi-process architecture, event distribution, and resource scheduling mechanisms. Its essence is a comprehensive manifestation of strict constraints and monitoring imposed by the system on application behavior.

Android explicitly characterizes ANR as an application-layer problem, which is in sharp contrast to SNR (System Not Responding). SNR refers to the loss of responsiveness of system processes (such as system_server), usually relying on the Watchdog mechanism to monitor the status of key system threads; while ANR relies on the message scheduling mechanism, where the system process uses a carefully designed timeout model to track the responsiveness of the application’s main thread. This distinction reflects the governance strategies adopted by the system for problems at different levels:

SNR focuses on ensuring the survival of core system services, adopting an active polling monitoring method;
ANR focuses on the real-time response of application processes, judging through an event-driven asynchronous detection mechanism.

From the perspective of system architecture, the ANR mechanism is mainly implemented at the system layer (i.e., in the system_server process). Its core lies in building a cross-process event monitoring system. When an application process initiates an operation request (such as starting Activity, processing application broadcasts, etc.) to system services through Binder, the system will synchronize the start of a timeout timer; and for asynchronous operations such as input events, InputDispatcher will establish an event channel with the window through socket, and start timeout detection after the event is dispatched. This layered monitoring design fully reflects the differentiated processing strategies adopted by Android for different task types.

The deep significance of the ANR mechanism lies in balancing openness and system controllability. As an open platform, Android allows applications to freely apply for hardware resources (such as CPU, IO, memory, etc.), but strict rules must be used to prevent the abnormal behavior of a single application from spreading to the entire system. When a timeout event is detected, the system initiates a multi-dimensional circuit breaker mechanism: first, force-terminate the problematic process to release key system resources (such as preventing it from occupying the Binder thread pool or file descriptors), thereby avoiding cascading failures; at the same time, the system will freeze the process state and collect key information such as CPU usage, thread stacks, and memory snapshots, writing this data to /data/anr/traces.txt to preserve the scene for subsequent problem analysis. Even more cleverly, the system hands over the final operation right to the user through a user-visible pop-up window, which not only avoids the risk of misjudgment caused by automated processing but also maintains the continuity of human-computer interaction. This design combining “fault isolation - scene protection - user decision” fully demonstrates Android’s wisdom in balancing technical rigor and user experience friendliness.

2. Core Design Philosophy of ANR

Essence of ANR: System-Level Monitoring and Mandatory Intervention

The ANR mechanism constitutes a deep-seated stability defense system in the Android system architecture. Its core lies in building a global safety net independent of application status through cross-layer collaborative monitoring and asynchronous decision isolation. This design is far from simple timeout detection, but is deeply rooted in the organic combination of the Linux process sandbox mechanism and the Android component architecture. System processes (such as system_server) conduct comprehensive monitoring of component lifecycles and input event flows through two core modules: ActivityManagerService (AMS) and InputManagerService (IMS). Due to this layered architecture, monitoring logic is decoupled from business logic. Even if the main thread of the target application is completely blocked, the system can still rely on independent threads for timeout adjudication, fundamentally avoiding the risk of “monitor being dragged down by the monitored object.”

At the implementation level, ANR fully embodies the essence of event-driven system design. For example, in component-type ANR scenarios, when AMS dispatches cross-process tasks to application processes through Binder, the system synchronizes the start of a countdown timer (such as a 20-second threshold for Service startup). This “bomb planting” mechanism essentially transforms asynchronous tasks into synchronous contracts with timeout constraints. After the application process completes the task, it must actively “defuse the bomb” through the Binder callback. Otherwise, the system will intervene to collect scene information (such as main thread stacks) and trigger user interaction. The entire process is dominated by the system process, and the application only exists as an event responder, ensuring the absolute authority of monitoring.

Task dispatch relies on Binder synchronous calls to ensure atomicity. At the same time, AMS pushes timeout detection messages into the message queue through a dedicated Handler, thereby monitoring the execution of tasks within the specified time. This design not only ensures the integrity of tasks during cross-process communication but also quickly triggers circuit breaker processing after timeouts.

Component-Class ANR: Global Protection Logic for Asynchronous Tasks

The monitoring logic of component-class ANR revolves around ActivityManagerService (AMS). Its essence is to realize full-link tracking of the asynchronous task lifecycle through the three-stage model of task dispatch – callback – circuit breaker. When the system dispatches a task to an application via Binder cross-process communication (such as starting a Service), AMS synchronizes the start of a timeout detection mechanism: using MainHandler to send delayed messages for precise timing. Taking Service startup as an example, when AMS calls scheduleCreateService() of IApplicationThread, it starts the corresponding timeout monitoring (default 20 seconds). If the application does not notify AMS via the serviceDoneExecuting() callback within the specific time, an ANR determination is triggered.

Developers need to pay special attention to the timing trap of cross-process callbacks: even if the asynchronous task is completed in a sub-thread, if the Binder callback is delayed due to main thread message queue blocking (such as excessive calls to runOnUiThread), the system will still judge it as ANR.

ProcessStateRecord introduced in Android 14+ has made a finer division of process states. It not only records the status of main thread message processing in detail but also monitors background tasks and suspended states in real-time, thereby reducing the false positive rate and providing developers with richer debugging information.

The key to this design lies in the decoupling of synchronous transactions and asynchronous circuit breaking. Task dispatch relies on Binder synchronous calls to ensure atomicity, while timeout detection executes asynchronously via the Handler message mechanism, avoiding blocking the system main thread.

When ANR is triggered, the system executes a multi-dimensional circuit breaker strategy:

Scene Collection
The system collects key data such as main thread stack information, CPU usage, and process status, and writes this data to the /data/anr/traces.txt file. At the same time, the system uses ProcessCpuTracker to record detailed CPU usage statistics, providing a basis for subsequent problem analysis.
Resource Isolation
The system ensures the real-time nature of circuit breaker decisions through the scheduling priority adjustment mechanism of ProcessRecord, ensuring that ANR processing flows can be executed in a timely manner even under high system load.
Diagnostic Data Collection
The system provides the ApplicationExitInfo API, allowing developers to query historical ANR records, including occurrence time, process status, exception stacks, and other detailed information. These data are extremely important for problem reproduction and root cause analysis.

It is worth sensing that Android 15 imposes stricter constraints on background services: foreground services must complete initialization and call startForeground() within 3 seconds, otherwise the system will directly trigger ANR. Specifically, the system manages this timeout mechanism via internal attributes (such as persist.sys.fgs_timeout) and API parameters (such as AMS internal parameters controlling foreground service startup timeouts). Developers can refer to the latest API documentation to understand these changes, ensuring that strictly response time limits are met when designing services.

The system also provides a variety of tools to support the diagnosis and analysis of ANR problems:

System Log Collection: Developers can obtain ANR stack information and system reports via adb commands, which contain detailed system status at the time of the problem.
Performance Analysis Tools: Android Studio’s CPU Profiler can monitor application performance in real-time, helping developers discover potential performance issues.
System-Level Analysis: Perfetto provides powerful system-level performance analysis capabilities to help developers understand complex performance issues.

Through this multi-level monitoring and protection mechanism, the Android system ensures the reliability of application response performance and provides developers with a complete problem diagnosis toolchain. Developers need to deeply understand these mechanisms, fully consider performance factors in application design, follow system lifecycle contracts, reasonably manage main thread load, and ensure timely response of key callbacks.

This design philosophy reflects the Android platform’s strict requirements for application quality: promoting developers to build more reliable and responsive applications through clear timeout limits and perfect monitoring mechanisms. At the same time, rich diagnostic tools also provide necessary support for developers, helping them quickly locate and solve problems when they encounter them.

Input-Class ANR: Dynamic Circuit Breaker System for Event Distribution

The monitoring mechanism for input-class ANR is more complex. Its core challenge lies in balancing high real-time requirements and resource efficiency. From hardware event generation to application main thread processing, the input system builds an efficient and controllable event distribution link through three major components: EventHub, InputReader, and InputDispatcher.

Event Reading Layer (EventHub)
EventHub uses Linux’s epoll mechanism to listen to /dev/input device nodes, supporting concurrent listening of multiple devices, and implementing zero idle CPU consumption through an event-driven model (rather than polling). When a hardware interrupt is triggered, the system receives raw input data via inotify and encapsulates it as a RawEvent.
Event Preprocessing (InputReader)
InputReader performs device-related preprocessing (such as touch calibration) on raw data through specific InputMappers and converts it into standard input events (such as MotionEvent or KeyEvent). At the same time, necessary event filtering is performed based on device type and configuration to ensure data quality.
Event Distribution Layer (InputDispatcher)
The core responsibility of InputDispatcher is to determine the current focus window and push events to the application process through InputChannel based on Unix Domain Socket. It uses a multiplexing mechanism to efficiently manage multiple InputChannels and relies on WindowManagerService to obtain the latest window focus information, ensuring events are accurately delivered to the target window.

The input ANR mechanism relies on continuous tracking and timeout determination of event status. Its core lies in the design of queue status management and cross-thread collaboration capability:

inboundQueue: Stores events to be distributed received from InputReader
outboundQueues: Output queues maintained for each connection, tracking events that have been distributed but have not received completion responses via waitQueue
waitQueue: Records events that have been distributed but have not yet received processing confirmation from the application side.

After an event is distributed, the system tracks its processing status through the MonitoredTimeout mechanism. The default timeout includes 5000 milliseconds (adjustable via system properties). Timeout detection adopts an event-driven mode, triggered when new events arrive, application callbacks complete, or periodic heartbeat checks occur. Once a timeout is detected, the system notifies ActivityManagerService via WindowManagerService and collects diagnostic data including InputDispatcher status and application process information, subsequently potentially triggering ANR pop-ups and process restart flows.

The entire input system adopts an optimized thread model design:

InputReaderThread focuses on event reading and preprocessing
InputDispatcherThread is responsible for event distribution and timeout monitoring

The two achieve efficient inter-thread communication through lock-free queues, ensuring that even if the main thread of an application process is blocked, system-level input processing can still operate normally, thereby effectively preventing problem spread.

For developers, special attention should be paid to the responsiveness of the main thread to avoid performing time-consuming operations in input event processing callbacks. At the same time, understanding the layered design of the input system helps to improve the efficiency of the event processing link from a holistic perspective during performance optimization.

No Focused Window Class ANR

No Focused Window ANR is another important unresponsive scenario in the input system. Its essence lies in the abnormal window focus state, leading to the correct distribution of input events being impossible. Unlike regular input timeouts, this type of ANR reflects coordination issues between the WindowManager subsystem and the input system.

In the design of WindowManagerService (WMS), window focus management is an independent and complex subsystem. When the user interface changes (such as Activity switching or dialog popping up), the system triggers a series of window transaction operations: first execute relayoutWindow on the old window to remove the focus flag, then execute addWindow for the new window and grant focus. These state changes are synchronized in real-time via WindowManagerPolicy to InputDispatcher, ensuring input events can be routed to the current focus window.

Acquisition and loss of focus are triggered by various system behaviors. For example:

Focus Acquisition: New Activity finishes starting and displays the first frame, Dialog or PopupWindow pops up, touching window area in split-screen mode, restoring application from background task switcher, foreground application resumes after unlocking.
Focus Loss: Activity covered by full-screen Activity, user presses Home key, system pops up key level Dialog such as permission request, application enters background, device lock screen, etc.

No Focused Window ANR is often related to abnormal window lifecycle management. The most common situation is that during Activity switching, due to the delayed execution of handleResumeActivity of the target Activity, the system cannot determine a legal focus window within a certain period of time. Unlike input timeout ANR, input timeout means the target window exists but fails to process the event in time, while No Focused Window ANR means the system cannot find a suitable event receiver. Based on this difference, the system adopts different protection strategies for these two situations: for input timeout, the system triggers ANR after a default of 5 seconds; for no focus window situations, if the target window cannot be found after consecutive event distributions, the system will start the ANR process faster.

From the perspective of application development, the code paths affecting focus switching are relatively limited, mainly involving links such as Activity lifecycle callbacks, window addition/removal, and input event processing. Even if problems occur in these links (such as main thread blocking), they usually trigger regular ANR rather than No Focused Window ANR. Therefore, when encountering such problems, more attention should be paid to system-level indicators such as overall system resource usage status, CPU load of the system_server process, and Binder call delays between system services, rather than purely focusing on code optimization of a certain application. This is also the fundamental reason why No Focused Window ANR is often regarded as a system performance problem rather than an application quality problem.

Unifying Principles of System Design

Whether it is component-class ANR or Input-class ANR, their monitoring mechanisms follow the following core principles:

State Traceability
Precisely track task progress through queues (such as waitQueue) and timers (such as Handler in AMS), ensuring the system always grasps the latest status of application behavior.
Fault Isolation
Terminate the problematic process quickly after timeout to prevent local faults from spreading into system-level avalanches.
User Control Fallback
Ensure users always have the final right of operation through pop-up prompts and process termination mechanisms, even if the application internals are completely out of control.
Developer Constraint
Mandate that the main thread remains lightweight and asynchronous in design, promoting application architecture that fits the system design philosophy better.

From an architectural perspective, the ANR mechanism is the Android system’s final answer to controllability of an open ecosystem—it allows developers to innovate freely while defining behavioral boundaries through rigid rules. This balance is not only reflected in technical implementation but also profoundly affects the performance optimization culture of the entire Android application.

Global Resolution and Active Defense of ANR Problems

The complexity of ANR problems requires us to have both technical depth and system global view within the analysis framework, and use progressive logic to transform fragmented phenomena into an evolvable cognitive system. This method is not just simple directory layering, but uses cross-validation of multi-dimensional perspectives to establish a complete mapping relationship from microscopic code defects to macroscopic system constraints.

From Phenomenon to Root Cause: Dissecting ANR Problems Layer by Layer

Building a vertical analysis path follows the chain logic of “Phenomenon → Mechanism → Support → Resource”. Its goal is to clarify the complete chain from the ANR pop-up seen by users to hardware resource problems:

Mechanism Appearance (ANR Pop-up)
As the outermost phenomenon visible to users, the ANR pop-up is actually the system’s final judgment on the fault—it does not reveal specific root causes, but only displays results. Developers often stop at the level of viewing stack logs and looking for main thread blocking points, but this is like only observing volcanic eruptions while ignoring the fundamental driving factors of crustal movement.
System Implementation (AMS/InputDispatcher)
Delving into the system service layer, hidden behind the ANR pop-up is AMS’s appNotResponding trigger flow. AMS tracks component lifecycles through the Binder transaction state machine, while InputDispatcher monitors input response using socket event streams. Analysis at this layer reveals the difference in timeout determination logic: AMS adopts synchronous blocking detection (e.g., BroadcastQueue timeout calculation), while InputDispatcher utilizes an asynchronous non-blocking model based on epoll to implement event loop monitoring.
Underlying Support (Binder/Scheduler)
Efficient operation of system services relies on core mechanisms of the Linux kernel. The Binder driver implements cross-process communication through memory mapping, and its thread pool scheduling strategy (e.g., BINDER_MAX_POOL_THREADS threshold limit) directly affects transaction processing capability; while the system’s fair scheduling mechanism determines whether the main thread can obtain execution resources in time through dynamic allocation of CPU time slices. The key at this layer is to analyze the contradiction between fairness and real-time performance of resource allocation—for example, to ensure fairness of multi-tasking, the system may allow CPU-intensive tasks of background processes to preempt the response time of foreground applications.
Hardware Resources (CPU/IO/Memory)
Ultimately, all software behaviors are limited by physical hardware. The out-of-order execution of the CPU may lead to randomness in lock contention problems; disk I/O latency will amplify main thread blocking during SharedPreferences writing; memory bandwidth contention may prevent RenderThread from obtaining texture data in time. This layer requires establishing an association model between hardware indicators and software behaviors, such as using the perf tool to analyze the correlation between CPU cache hit rate and ANR trigger frequency.

This vertical deepening is not linear progression, but a process of cyclic verification: when hardware layer analysis finds memory bandwidth bottlenecks, it is necessary to backtrack to the Binder driver layer to check if frequent cross-process communication causes memory copy storms, and finally optimize data transmission mechanisms at the system service layer.

From Passive Response to Active Defense: Three Steps for ANR Governance

The evolution path of methodology—**”Diagnosis → Tracking → Prediction → Design”** reflects the transition of technical cognitive maturity. Specific steps include:

Stack Analysis
Traditional ANR analysis relies on thread stacks in traces.txt, which is essentially a static snapshot when a fault occurs. When a problem is caused by sporadic race conditions (such as instantaneous saturation of the Binder thread pool), the stack may show a normal NativePollOnce state and cannot reveal the true resource contention process. At this time, multi-time point stack comparison technology needs to be introduced to identify thread state migration patterns by comparing stack changes within 5 seconds before and after ANR.
Dynamic Tracking
Using millisecond-level event tracking capabilities provided by tools such as systrace and perfetto, one can monitor the event processing cycle of the main thread Looper and quantify the execution time of dispatchMessage; combined with binder_transaction events in the Binder driver, heat maps of cross-process calls can be drawn. The core value of dynamic tracking lies in revealing hidden time correlations, such as discovering that input event delays often follow immediately after SharedPreferences disk write operations.
Machine Learning Prediction
When the root cause of ANR involves interaction of multiple subsystems (such as coupling effects of CPU scheduling, memory reclamation, and I/O load), traditional methods struggle to handle high-dimensional data. By collecting over 20 indicators such as thread status, Binder interaction data, and CPU contention situations, and using machine learning algorithms to build analysis models, ANR types (such as main thread blocking, IPC deadlocks, or resource contention) can be automatically identified. Google has applied similar technology in Android Vitals to achieve cloud-based aggregated analysis of ANR root causes.
Architectural Preventive Design
The ultimate goal is to internalize system constraints from the code design stage, for example:
- Communication Topology Constraints: Limit cross-process call levels, avoid chain calls of A → B → C, and use event bus broadcast patterns instead.
- Resource Budget Management: Allocate Binder transaction quotas for each business module, and automatically downgrade when exceeding thresholds.
- Asynchronous Boundary Reinforcement: Use HandlerThread and Executor to strictly isolate synchronous and asynchronous operations to prevent thread model confusion.

This evolutionary path from passive response to active defense not only provides effective strategies for preventing ANR from the root cause but also provides developers with rich diagnostic tools and optimization ideas.

References

About Me && Blog

Below are personal introduction and related links. I hope to communicate more with everyone in the industry. If three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: There are personal WeChat and WeChat group links inside.
This Blog Content Navigation: A navigation of personal blog content.
Excellent blog articles organized and collected by individuals - A must-know for Android efficiency optimization: Everyone is welcome to recommend themselves and recommend others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for your support~

One person can go faster, a group of people can go further

Android Perfetto Series 3: Familiarizing with the Perfetto View

2024-05-20T23:30:23.000Z

This is the third article in the Perfetto series. The first two articles introduced what Perfetto is and how to capture Perfetto Trace. This article simply introduces how to look at the complex Perfetto information after opening Perfetto Trace on the web side.

Perfetto Series Catalog
Perfetto View Interface
Perfetto Trace Interface
Basic Operations
Perfetto Usage Tips
Summary
About Me && Blog

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

Perfetto View Interface

After capturing the Perfetto Trace, it is generally opened in ui.perfetto.dev (if you use the script provided by the official, it will open automatically on this website after capturing, you can check the source code of the script if you want to see how to implement it). The interface after opening is as follows:

You can open Trace by Open trace file or dragging Perfetto Trace directly to the white area.

Perfetto Trace Interface

The interface after opening Perfetto Trace is as follows:

Roughly, the Perfetto Trace interface can be divided into four areas:

The rightmost operation area: The most important thing here is the few under the Current Trace column that will be used frequently.
1. Show timeline: Display current Trace, after switching to other interfaces, click this again to return to the Trace View interface
2. Query: Place to write SQL query statements and view execution results
3. Metrics: Some analysis results written by the official by default, you can choose to open directly
4. Info and stats: Some information about the current Trace and mobile App
Information and operation area at the top: The most important thing is to look at the time.
Trace content area in the middle: The area with the most operations. Trace content is all in this part. The top few parts are divided into an area from the perspective of function, such as CPU area (can view which core the current Task is running on, what is the frequency, how long it runs, who woke it up), Ftrace event area, etc.; the following part is displayed in units of App Process (including App’s various threads, Input events, Binder Call, Memory, Buffer and other information).
Information area at the bottom: This area mainly displays various information. After we select a certain Task segment, the information related to this Task will be displayed here (if you add Log, Log will also be displayed here; ftrace event is similar).

When viewing the Perfetto interface at first, it will feel very messy and flashy, but after getting used to it, it is really delicious ~

Basic Operations

The operation of the Perfetto Trace interface is very smooth, which is a huge advantage compared to Systrace. Systrace will be laggy when opening a slightly larger Trace, but Perfetto Trace is still very smooth when opening a 500Mb Trace.

The shortcut keys for watching Trace are very similar to Systrace. w/s is to zoom in/zoom out, a/d is to move left/right, and mouse click is to select. The official document in the lower left corner has detailed operation instructions. If you forget, you can check it at any time. Practice makes perfect:

Among other shortcut keys, the more confusing ones are:

f is to zoom in on the selection
m is to temporarily Mark an area (same as Systrace), used to look at time up and down, look at other process information, etc. Temporary means that if you press m to mark another area, the Mark area marked by the previous m will disappear. Exit temporary selection: esc, or select other Slice and press m, the selection effect of this currently Slice will disappear
shift + m is to continuously Mark an area (if you don’t click, it won’t disappear), mainly used to Mark a piece of information for a long time. For example, if you Mark all the frame drop points in a Trace, you can use shift + m, so that it will not be lost.
Click on the small flag to see the execution information within this interval
Delete continuous Mark
1. Click on the triangle at the top of the Slice you selected
2. Select Tab below: Current Selection
3. Click Remove on the far right, and you can Remove it
q: Hide and show the information Tab. Since Perfetto occupies the screen very much, it is very important to use the q key proficiently. Open it quickly when watching, and close it quickly after watching.
Flagging: Perfetto can also use the method of inserting flags to make marks on Trace. Perfetto supports you to put the mouse on the top of Trace, and a flag will appear. Click the left button to insert a flag on it, which is convenient for us to mark the occurrence of an event, or a certain time point

Cancel the inserted flag: Same as exiting continuous selection, click the flag, there is a Remove in the lower right corner, click to kill this flag, I won’t insert the picture.

Perfetto Usage Tips

Check Wakeup Source

We can check the wake-up source of a Task to understand the operation process of App and Framework. Both Systrace and Perfetto can check the wake-up source, but Perfetto is smoother in this regard.

In the article Android Systrace Response Speed Practice 3: Response Speed Extended Knowledge, I talked about how Systrace checks the wake-up source. In fact, it is still a bit troublesome. Checking the wake-up source in Perfetto is very convenient and the operation is very smooth:

For example, if we want to see who woke up RenderThread in the details below, we can have several methods:

Click Runnable Status

Like the Systrace operation, click Runnable directly in front of Running, and you can see Related thread states in the information area below:

Waker: Wake-up source
Previous state: The previous state of this Task
Next state: The next state of this Task

Click the Running status above it to view continuous wake-up information:

Or we can click the Running status, click the small arrow to jump directly to the corresponding CPU Info area, where more detailed information can be seen. You can also click Task continuously to trace the wake-up source, and jump back and forth between the CPU Info area and the Task area through the small arrow in the information area.

Click the Running status above RenderThread to jump to the CPU Info area via the small arrow

RenderThread is woken up by MainThread

Click MainThread again to see that it is woken up by SurfaceFlinger. There is also a corresponding wake-up delay analysis in the information area below.

Check Critical Path (Task)

Critical Task refers to the Task that has a dependency relationship with the Task currently selected by us. For example, if our Task is e, e can only be executed after d is executed, d has to wait for c, c has to wait for b, and b has to wait for a, then the Critical Task of e is a, b, c, d.

Perfetto can verify the Critical Task of a certain Task. Given that Critical path lite is a subset of Critical path, we only introduce Critical path here:

Click Running status, and then click Critical path in the information area below.

Wait for a moment to see the Critical path corresponding to the MainThread we selected:

Zooming in, checking at the edge of the MainThread we selected, the first Critical Task is the app thread of sf that woke him up

Looking to the left, the app thread of sf is woken up by the TimerDispatch thread of sf, which is not posted here.

In fact, it can be seen that the Critical Path provided by Perfetto actually gathers consecutive wake-up Tasks together, which is convenient for us to see the relationship between various Tasks.

Pin (Fix to Top)

On the far left of each Thread, there is a button like a thumbtack. After clicking, this Thread will be fixed to the top, which is convenient for us to put the Threads we are most concerned about together.

For example, the following is the flow chart from App to SF that I Pin. It will be much clearer if put together, and it will be more convenient to watch frame drops.

CPU Info Area Task Highlight

In the CPU Info area, if you put the mouse on a certain Task, other Tasks of the Thread corresponding to this Task will be highlighted.

We often use this method to preliminarily check the core placement information of certain Threads.

Check Buffer Consumption Stats

The Buffer consumer of App is SurfaceFlinger. Through the Actual Timeline line on the App Process side, we can see specifically which frame of SurfaceFlinger consumed the Buffer.

Quickly Check App Execution Timeout

Due to the existence of Android’s multi-Buffer mechanism, App execution timeout does not necessarily cause stuttering, but timeout requires our attention.

Through the Expected Timeline and Actual Timeline provided by Perfetto, we can clearly see where execution times out.

Click the red section of Actial Timeline, and the information bar at the bottom will display the reason for the frame drop:

View Log on Perfetto

Switch to the Android Logs Tab on the information bar. If you put the mouse on a certain line, Perfetto will pull a straight line on the corresponding Timeline, and you can see the time corresponding to this Log.

Similarly, switching to the Ftrace events tab allows you to check corresponding ftrace event and corresponding timeline.

Analyze Running Information of Thread

You can select a section of area for analysis by holding down the left mouse button and sliding. For example, if you select the CPU State column, you can see the proportion of Running, Runnable, Sleep, and Uninterruptible Sleep corresponding to this period of time.

This is often used when analyzing App startup.

Summary

The basic interface and operations of Perfetto are shared above, as well as some relatively commonly used Perfetto tips. Google is currently actively promoting and maintaining Perfetto. Many new functions may pop up someday. I will update them if I think they are useful.

The basic chapter of Perfetto ends here. The follow-up is to understand the basic process of Android system operation through the tool Perfetto, and use Perfetto and Perfetto SQL to analyze the problems encountered such as performance and power consumption.

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
This Blog Content Navigation: A navigation of personal blog content.
Personal Collection of Excellent Blog Articles - Android Performance Optimization Must-Know: Welcome everyone to recommend themselves and others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

One person can go faster, a group of people can go further

Android Perfetto Series 2: Capturing Perfetto Traces

2024-05-20T23:29:41.000Z

The previous article Android Perfetto Series 1: Introduction to Perfetto introduced what Perfetto is. This article provides a brief introduction to Perfetto capture.

Perfetto Series Catalog
Main Content
1. Using Command Line to Capture Perfetto (Recommended)
2. Using Official Script to Capture
3. Using On-Device Developer Tools to Capture
4. Using Web Interface to Capture
Reference Documents
About Me && Blog

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

Main Content

The steps for using Perfetto to analyze problems are the same as using Systrace:

First you need to capture the Perfetto file
Open the Trace file in ui.perfetto.dev for analysis or use the command line for analysis

This article simply introduces the method of using Perfetto to capture Trace files. Personally, I recommend using the command line to capture. Whether it is a command line configured by yourself or an official command line tool, it is very practical.

1. Using Command Line to Capture Perfetto (Recommended)

Basic Command - adb shell perfetto

For friends who have always used the Systrace tool, capturing Trace via command line is very convenient. Similarly, Perfetto also provides a simple command line to capture, and the simplest usage method is basically consistent with Systrace. You can directly connect to your Android device and use the /system/bin/perfetto command to start tracing. For example:

// 1. First execute the command
adb shell perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace -t 20s \
 sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

// 2. Operate the phone to reproduce the scene, such as sliding or launching etc.

// 3. Pull the trace file to the local
adb pull /data/misc/perfetto-traces/trace_file.perfetto-trace

This command will start a 20-second trace, collect user-specified data source information, and save the trace file to /data/misc/perfetto-traces/trace_file.perfetto-trace.

Execute the adb pull command to pull the trace out, and you can open it directly on ui.perfetto.dev.

Advanced Command - adb shell perfetto with config file

This is where Perfetto differs from Systrace. Perfetto can capture a lot of information, and its data sources are also very diverse. It is very inconvenient to add a lot of configurations with the command line every time. At this time, we can use a separate Configuration File (Config) to store this information. Each time we capture, we can just specify this configuration file.

For passing Perfetto configuration files on versions before and after Android 12, here are detailed guides and corresponding command line examples.

On Android 12 and later devices

Starting from Android 12, you can directly use the /data/misc/perfetto-configs directory to store configuration files, so you don’t need to pass the configuration file through stdin. The specific command is as follows:

1 2	adb push config.pbtx /data/misc/perfetto-configs/config.pbtx adb shell perfetto --txt -c /data/misc/perfetto-configs/config.pbtx -o /data/misc/perfetto-traces/trace.perfetto-trace

In this example, first push the configuration file config.pbtx to the /data/misc/perfetto-configs directory. Then, start tracing directly in the Perfetto command by specifying the path of the configuration file via the -c option.

On devices before Android 12

Due to strict SELinux rules, passing the configuration file directly through the file path will fail on non-root devices. Therefore, you need to use standard input (stdin) to pass the configuration file. This can be achieved by cating the contents of the configuration file to the Perfetto command. The specific command is as follows:

1 2	adb push config.pbtx /data/local/tmp/config.pbtx adb shell 'cat /data/local/tmp/config.pbtx \| perfetto -c - -o /data/misc/perfetto-traces/trace.perfetto-trace'

Here, config.pbtx is your Perfetto configuration file. First use the adb push command to push it to the temporary directory of the device. Then, use the cat command to pass the contents of the configuration file to the Perfetto command.

Source of Config

For Config, I suggest using Record new trace on ui.perfetto.dev to select and customize, and then save it to a local file. Different scenarios just load different Configs. The last part of the article talks about this in detail, you can take a look if you are interested.

The official also provides a share button. You can share your own config with others, which is very convenient. At the same time, I will also create a Github library for everyone to share (in progress).

The official code repository also has some configured ones, you can download and use them yourself: https://cs.android.com/android/platform/superproject/main/+/main:external/perfetto/test/configs/

Precautions

Ensure adb is normal: Before using these commands, please make sure your device has USB debugging enabled and has been correctly connected via the adb devices command.
Ctrl+C Interrupt: When using the adb shell perfetto command, if you try to use Ctrl+C to end the trace early, this signal will not be propagated through ADB. If you need to end tracking early, it is recommended to use an interactive PTY-based session to run adb shell.
SELinux Restrictions: On non-root devices before Android 12, due to strict SELinux rules, configuration files can only be passed via cat config | adb shell perfetto -c - (where -c - means read configuration from standard input). Starting from Android 12, the /data/misc/perfetto-configs path can be used to store configuration files.
On versions before Android 10, adb cannot directly pull /data/misc/perfetto-traces out. You can use adb shell cat /data/misc/perfetto-traces/trace > trace instead.

2. Using Perfetto Official Script to Capture (Strongly Recommended)

The Perfetto team also provides a convenient script tools/record_android_trace that simplifies the process of recording traces from the command line. This script automatically handles path issues, pulls the trace file automatically after tracking is completed, and opens it in the browser. Essentially, this script still uses the adb shell perfetto command, but the official helped you encapsulate it. Usage example:

On Linux and Mac：

curl -O https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace
chmod u+x record_android_trace
./record_android_trace -o trace_file.perfetto-trace -t 10s -b 64mb \
 sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

On Windows:

1
2
3

curl -O https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace
python3 record_android_trace -o trace_file.perfetto-trace -t 10s -b 64mb \
sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

Similarly, you can also specify the configuration file via -c here, for example:

curl -O https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace
chmod u+x record_android_trace
./record_android_trace -c config.pbtx -o trace_file.perfetto-trace -t 10s -b 64mb \
 sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory

This will record a 10-second trace and save the output file as trace_file.perfetto-trace.

After execution, it will automatically capture the Trace and automatically open it in the browser, which is very convenient.

The script content can be viewed directly by visiting: https://raw.githubusercontent.com/google/perfetto/master/tools/record_android_trace

3. Using On-Device Developer Tools to Capture

Of course, sometimes there is no way to connect to a computer, or the test content cannot correct USB. At this time, you can use the built-in system tracing application (System Tracing App) on Android to capture Trace. This application is built into the developer options and allows you to configure and start performance tracking in a few simple steps.

Start System Tracing Application

Enable Developer Options: First, make sure your device has enabled developer options. If there is no developer option in your settings, you need to find the compilation number in About Phone, and then click 7 times continuously to open the developer options.
Open Developer Options: Find and open developer options in the Settings menu.
Start System Tracing: Scroll down in the developer options until you find “System Trace” or similar options. Click it and the system tracking application will open.

It looks roughly like this (each phone may have differences in interface or text, but the function is the same)

The system trace application provides a series of configuration options, including but not limited to:

Trace Duration: You can specify the duration of the trace, such as 10 seconds or longer.
Data Source: Select the source from which you want to collect data. This may include multiple different data sources such as CPU, memory, network, etc.
Output File Location: Specify the location where the trace file is saved.

Start and Stop Tracing

After configuring all the required parameters, you can start tracking by clicking the “Record trace” button. Click the “Record trace” button again to end the capture. After the capture is completed, there will usually be a prompt telling you that the capture has been completed and providing options to view or share the trace file. You can export the trace file to a computer and use the Perfetto web UI for deeper analysis.

4. Using Web Interface to Capture

The capture function on the web side is relatively confusing. Many times you will fail to capture, for example, adb cannot be connected, or it says you need to execute kill after connecting. So I recommend everyone to use the configured command line to capture. The web side is more suitable for Config configuration.

Perfetto also provides a powerful Web Tool (ui.perfetto.dev), allowing developers to configure and start tracking through the browser. You just need to visit the website, click “Record new trace”, and then select data sources and configuration parameters as needed. Make sure your device is connected to the computer via ADB, and select “Add ADB device” on the web page. After that, click “Start Recording” to start collecting tracking data.

After selecting the information source you want to capture here, you can click Recording command to view it. Here you can see the specific content of the Config you selected. You can share it or save it to a local file for use when capturing with the command line.

When selecting Config, it is recommended to check Atrace userspace annotations, Event log (logcat), and Frame timeline in the Android apps column (command + a)

In addition, if you want to see the call stack, you can check Callstack sampling in Stack Samples (note that the latest version of Android is required, and the debugged process must be debuggable)

As for the use of others, you can explore it yourself. Subsequent Perfetto articles will also introduce each part and its presentation on Trace to help everyone get started with Perfetto faster.

Extracting Parameters from Web Interface

As mentioned earlier, the graphical selection of Config on the web side is very convenient. After selection, click Recording command, and you can see the selected Config. When saving, remember to remove the following lines:

Reference Documents

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
This Blog Content Navigation: A navigation of personal blog content.
Personal Collection of Excellent Blog Articles - Android Performance Optimization Must-Know: Welcome everyone to recommend themselves and others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

One person can go faster, a group of people can go further

Android Perfetto Series 1: Introduction to Perfetto

2024-05-20T23:29:22.000Z

This is the first article in the Perfetto series. It mainly provides a brief introduction to the Perfetto tool, including its history, development, and what Perfetto can do.

Perfetto Series Catalog
Main Content
Why Performance Analysis Needs a God’s View
Introduction to Perfetto
Where it’s not as good as Systrace
Reference Documents
About Me && Blog

Perfetto Series Catalog

If you haven’t seen the Systrace series yet, here is the portal:

Systrace Series Catalog: Systematically introduced the use of Systrace, the predecessor of Perfetto, and used Systrace to learn and understand the basic rules of Android performance optimization and Android system operation.
Personal Blog: Personal blog, mainly content related to Android, and also put some content related to life and work.

Main Content

I started writing the Systrace series in 2019, and wrote more than 20 articles one after another, from basic usage to the presentation of various modules on Systrace, to practical combat such as startup speed and fluency. It basically met the needs of junior system developers and App developers for the Systrace tool. Through the blog, I also added many like-minded friends, and there are 6 exchange groups just for communication. Thank you all very much for your support.

So there is this series, and I also wrote a few reasons in the Planet why I want to update the Perfetto series (I used to think that the Systrace series was enough):

Currently, mobile phone manufacturers such as OPPO and Vivo have switched to Perfetto internally. Whether it is capturing Trace or viewing Trace, they are using Perfetto. Many newcomers are exposed to Perfetto instead of Systrace. Keeping the previous old Systrace series will lose this part of the readers.
The Code corresponding to the previous Systrace series is relatively old. The brand new Perfetto series can use Android 14 Code for updates.
My personal use of Perfetto is not very deep, and some advanced functions are currently only tasted casually. I can strengthen this part of the content by rewriting the Perfetto series.
Perfetto is a very powerful tool. Behind it is the entire Android + Linux system. So when writing this series, the focus should be on the Android + Linux behind it, rather than just being limited to the Perfetto tool. Tools are just our way of observing Android + Linux. Understanding the laws of the entire Android system operation, thinking about its operating principles, discovering problems through tools, and thinking about the essence through problems are meaningful to developers.
Perfetto’s official documentation still does not cover many contents related to Android system operation. I can supplement this part; in addition, the official documentation is in English, and Chinese blogs can supplement this aspect.
Perfetto can be used as a speech content at Google Dev Best ~.

Why Performance Analysis Needs a God’s View

Before introducing Perfetto, we need to understand why performance analysis needs tools like Systrace and Perfetto: Taking the Android system as an example, there are many factors affecting performance: the quality of the App itself, the performance of various system modules, the performance of Linux, hardware performance, plus the strategies of various manufacturers, customized functions by manufacturers, the load of the system itself, low memory, heating, differences in various Android versions, user usage habits, etc. The reason cannot be known by analyzing a certain App or a certain module. We need a God’s perspective to look at the operation of the Android system from a higher dimension.

The Perfetto tool provides such a God’s perspective. Through the God’s perspective, we can see various details of the Android system during operation, such as:

How Input events flow
How every frame of the App you are using goes from generation to screen display
Real-time frequency, load, core placement, wake-up of cpu, etc.
How various Apps in the system are running
….

App developers and Android system developers will also add Trace points at important code logic. After turning on some Debug options, very detailed information can be obtained. Even why a Task is placed on a certain cpu will be recorded in detail. Through the info displayed on Perfetto, we can preliminarily analyze the cause of performance problems, and subsequent analysis will be targeted.

Also, to illustrate the complexity of performance optimization, you can look at the description of performance in the book <**System Performance**>, specifically the methodology, which fits the theme of this article very well. I also strongly recommend that all students engaged in performance optimization keep this book as a frequent reading methodology book: System performance engineering is a challenging field due to many reasons, including the fact that system performance is subjective, complex, and often multi-problem.

Performance is Subjective

Technical disciplines are often objective; too many people in the industry view problems as black and white. When troubleshooting software, determining whether a bug exists or whether a bug is fixed is like this. The appearance of a bug is always accompanied by an error message. The error message is usually easy to interpret, and then you understand why the error appeared.
Unlike this, performance is often subjective. When starting to address performance issues, the judgment of whether the problem exists may be vague. The same is true when the problem is fixed. Performance considered “bad” by one user may be considered “good” by another user.

The System is Complex

In addition to subjectivity, performance engineering, as a challenging discipline, is not only because of the complexity of the system, but also because we often lack a clear starting point for analysis regarding performance. Sometimes we just start with guessing, for example, blaming the network, and performance analysis must verify whether this is a correct direction.
Performance problems may arise from complex interconnections between subsystems, even if these subsystems perform well in isolation. It may also be due to cascading failure, which refers to a faulty component causing performance problems in other components. To understand these problems, you must clarify the relationship between components and understand how they cooperate.
Bottlenecks are often complex and interconnected in unexpected ways. Fixing a problem may just push the bottleneck to other places in the system, resulting in the overall performance of the system not improving as expected.
In addition to the complexity of the system, the complex nature of the production environment load may also lead to performance problems. It is difficult to reproduce such situations in a laboratory environment, or they can only be reproduced intermittently.
Solving complex performance problems often requires a holistic approach. The entire system—including its internal and external interactions—may need to be investigated. This work requires a very wide range of skills, which is generally unlikely to be concentrated in one person, which drives performance engineering to become a varied and intellectually challenging job.

Multiple Problems May Coexist

Finding a performance problem point is often not the problem itself. In complex software, there are usually multiple problems.
Another difficulty in performance analysis: the real task is not to find the problem, but to identify the problem or identify which problems are the most important.
To do this, performance analysis must quantify the importance of the problem. Some performance problems may not apply to your workload or only apply to a very small extent. Ideally, you should not only quantify the problem, but also estimate the speed increase brought by each problem fix. This information is especially useful when management reviews the reasons for engineering or operation and maintenance resource overhead.
There is an indicator that is very suitable for quantifying performance, that is, latency.

Introduction to Perfetto

Perfetto is an advanced open-source tool designed for performance monitoring and analysis. It is equipped with a complete set of services and libraries capable of capturing and recording system-level and application-level activity data. In addition, Perfetto also provides memory analysis tools, suitable for both native applications and Java environments. One of its powerful features is that it can analyze trace data through a SQL query library, allowing you to deeply understand the details behind performance data. To better handle and understand large-scale datasets, Perfetto also provides a web-based user interface that allows you to intuitively visualize and explore multi-GB trace files. In short, Perfetto is a comprehensive solution designed to help developers and performance engineers analyze and optimize software performance with unprecedented depth and clarity.

Google started the first submission in 2017. In the following 6 years (as of 2024), a total of more than 100 developers have submitted nearly 37,000 submissions. There are PR and Merge operations almost every day. It is a quite active project. In addition to its powerful functions, its ambition is also very big. The official website claims that it is the next generation of cross-platform Trace/Metric data capture and analysis tools. Usually, it is widely used. In addition to the Perfetto website, Windows Performance Tool and Android Studio, as well as Huawei’s GraphicProfiler also support the visualization and analysis of Perfetto data. We believe that Google will continue to invest resources in the Perfetto project. It can be said that it should be the next generation of performance analysis tools and will completely replace Systrace.

If you are accustomed to using Systrace, switching to Perfetto will be very smooth because Perfetto is fully compatible with Systrace. The Systrace files you captured before can be opened directly in the Perfetto Viewer website. If you have not adapted to Perfetto, you can also open Systrace with one click from Perfetto Viewer.

The figure below is the architecture diagram of Perfetto. It can be seen that Perfetto contains three major blocks:

Record traces: The data capture module. It can be seen that the captured content and sources are very rich, involving Java, Native, and Linux, which is much richer than Systrace.
Analyze traces: Mainly the trace analysis module, including Trace parsing, SQL query, Metrics analysis, etc. This part has a dedicated command line tool provided, which is convenient for everyone to call directly or call in the tool chain.
Visualize Traces: Trace presentation, capture, etc.

These modules will be introduced in detail in subsequent articles in the series.

Perfetto’s Core Advantages and Highlights:

Through long-term use and comparison, as well as watching various sharing, here is a summary of Perfetto’s core advantages and functional highlights:

Support for Long-Term Data Capture:
- Perfetto supports long-time data capture through background services, using Protobuf encoding to store data.
Data Sources and Compatibility:
- Based on the Linux kernel’s Ftrace mechanism, recording key events in user space and kernel space.
- Compatible with Systrace functions and is expected to eventually replace it.
Comprehensive Data Support:
- Support Trace, Metric and Log type data.
- Provide multiple data capture methods, including web pages, command line tools, developer options, and Perfetto Trigger API.
Efficient Data Analysis:
- Provide data visualization web pages, support large file rendering, superior to Systrace.
- Trace files can be converted to SQLite database files, supporting SQL query and script execution.
- Provide Python API, allowing data to be exported to DataFrame format, providing convenience for in-depth analysis.
- Support function call stack display.
- Support memory heap stack display.
- Support pinning the rows you are interested in to the top, without having to scroll up and down all the time (can automatically pin upon opening via script).
- Support visualization of Binder calls and jumps.
- Support very convenient query of wake-up sources.
- Support Visual query of Critical Task.
Google’s Continuous Updates:
- Google’s tool team is continuously updating Perfetto. Version Release and Bugfix are very timely. You can observe on Github.

Here, I specifically mention SQL. Perfetto can use SQL, which is a huge improvement. When parsing Trace files, many SQL tables and views are built-in, which facilitates querying using SQL statements. For example, the following queries are very practical (Image from Kernel Artisan).

In addition, in its official documentation, when introducing the corresponding part, it will also paste the corresponding SQL and query result examples.

With this, you no longer have to be afraid of your boss saying you have no data. Find it out in minutes with SQL, convert the table to a chart, and a high-quality Report comes out: after optimization, the xxx indicator dropped by xx%, which is really very convenient.

Where it’s not as good as Systrace

Vsync-App is not so intuitive

Vsync-App is relatively less intuitive in Perfetto. For example, if you are used to the vertical line of Vsync-App running through the entire Trace in Systrace, you will feel weird when you look at Perfetto without this:

In Perfetto, you can Pin Vsync-App to the top to see Vsync information

In Systrace, Vsync runs through the entire Trace in the form of a vertical line, which is easy to identify:

Of course, Perfetto also has reasons for canceling this: Vsync-App actually cannot explain that the App has performance problems. Perfetto uses another way to display it. If you use the Perfetto command to grab the Trace, there will be the following information, recording the Expected Timeline and Actual Timeline of an App frame. Compared with Vsync-App, these two indicators can better explain the problem: Original document

Expected Timeline: Each slice represents the time the application uses to render the frame. To avoid system stuttering, the application needs to complete within this timeframe. The start time is the time when the Choreographer callback is scheduled.
Actual Timeline: These slices represent the actual time the application completes the frame (including GPU work) and sends it to SurfaceFlinger for composition. The start time is the time the application starts running. The end time of the slice here represents when the application’s frame is published to SurfaceFlinger.

By looking at the difference between Expected Timeline and Actual Timeline, we can quickly locate the point of stuttering (the red marked Actual Timeline frame is the stutter)

Its calculation method is as follows. Looking at the picture, you will know why these two are more accurate (including GPU execution time)

Correspondingly, SurfaceFlinger also has these two indicators.

Folding function is relatively bad, wasteful of screen

If you have a normal widescreen, open Perfetto and randomly Pin a few key threads to the top, the operating space below you is very small. If you encounter a key thread stack that is relatively long, it is even more torturous, and this stack cannot be folded (Systrace can).

Solution:

Pin fewer key threads (Then what’s the fun)
Stand the monitor up (Width is discounted)

Finally, we found the perfect solution: switch to LG’s “Rubik’s Cube” screen (DualUp), 16:18, watching Perfetto is simply a perfect match (The office has already been recommended 3 units by me)

Not short of money: LG 28MQ780 - 3599
Flat replacement: Innocn 28C1Q - 2999

Reference Documents

About Me && Blog

Here is a personal introduction and related links. I hope to communicate more with my peers. When three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: Contains personal WeChat and WeChat group links.
This Blog Content Navigation: A navigation of personal blog content.
Personal Collection of Excellent Blog Articles - Android Performance Optimization Must-Know: Welcome everyone to recommend themselves and others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

One person can go faster, a group of people can go further

Android Perfetto Series Catalog

2024-03-27T14:29:31.000Z

With Google announcing the deprecation of Systrace in favor of Perfetto, Perfetto has essentially replaced Systrace in my daily workflow. Major manufacturers like OPPO and vivo have also transitioned to Perfetto. Many developers new to Android performance optimization find Perfetto’s complex interface and features overwhelming, which is why I’ve decided to re-present my previous Systrace articles using Perfetto.

This series was born from a few key reasons I shared in my Knowledge Planet (I previously thought the Systrace series was sufficient):

Industry Transition: Manufacturers like OPPO and vivo have already switched to Perfetto for both capturing and analyzing traces. Many new developers are starting with Perfetto, and keeping only the old Systrace series would leave them behind.
Modern Codebase: The previous Systrace series was based on older code. This new Perfetto series is updated using Android 14 source code.
Personal Growth: I haven’t fully mastered all of Perfetto’s high-level features myself. Re-writing this series helps me reinforce my own understanding.
System-Level Focus: Perfetto is a powerful tool backed by the entire Android and Linux ecosystem. This series focuses on the underlying system principles rather than just the tool itself. Mastery lies in understanding how Android works and using tools to uncover the essence of performance issues.
Knowledge Gap: Official Perfetto documentation still misses many nuances of Android system operation. This series aims to fill those gaps and provide high-quality Chinese technical content.
Community Sharing: This content will also serve as material for future technical presentations like Google DevFest.

Paul Graham once said: “Either provide something most people want a little, or something a few people want a lot.“ Perfetto is exactly what a dedicated minority “wants a lot.” Let’s begin. Please feel free to share feedback or point out errors so I can keep this as accurate as possible.

This series aims to provide a fresh perspective on Android system operation through Perfetto. It offers a unique angle to study App, Framework, and Linux internals. Even if you’ve read many articles on performance optimization, you might still feel confused because it’s hard to visualize the flow or remember the code. Through graphical tools like Perfetto, you may gain much deeper insights.

Perfetto Series Catalog

Systrace Series

Although Systrace is no longer updated, the core content of the previous Systrace series remains relevant. Many companies still use Systrace to analyze system issues. It is a powerful tool for visualizing system operation and learning the Android Framework.

About Me & My Blog

Here is a quick introduction and relevant links. I welcome communication with fellow developers!

Author Introduction: Includes my WeChat and community links.
Blog Content Map: A navigation guide to this blog.
Android Performance Optimization Skills and Tools: A curated collection of excellent articles.
Android Performance Knowledge Planet: Join our community for deeper discussions.

“If you want to go fast, go alone. If you want to go far, go together.”

Reflections on 2023: Health, Career, and the Future

2023-12-31T16:08:53.000Z

I’m taking the easy way out this year and using a template to look back at the past year through several lenses: Health/Fitness, Work/Career, Friendship/Social, Personal Life/Family, Learning/Knowledge Management, Travel/Culture, Interests/Creativity, Emotions/Mental State, and Finances.

This post is more of a personal record for 2023 than a formal summary, and my writing isn’t anything special. But as I’ve realized, if you don’t record things, they slowly fade away. I hope that whenever I look back at this post, I’ll remember 2023 as a vibrant year—filled with unforgettable moments, low points, visits from distant friends, and journeys through mountains and rivers. I also want to remember the things I did poorly so I can do better next time, and to remind myself to fight the laziness that often prevents me from following through on what I know is right.

For those reading, just enjoy the ride!

Health / Fitness

This year was dominated by cycling, thanks to a company-wide competition and the completion of the Chengdu Green Belt last year. I bought a used Merida Reacto 4000 on Xianyu at the start of the year and committed to riding. My goal was to complete one loop (97km) in under 3 hours, with a stretch goal of 2 hours 50 minutes. I’m proud to say I met both (35 loops total, with a personal best of 2h 47min), and even took first place in the company competition. I even managed to get my wife into the sport!

My chronic issues—asthma and rhinitis—didn’t see much improvement. However, the best news came at the end of the year: after being hospitalized for 4 days due to pneumonia and the flu, the IV treatment actually cured the loss of taste caused by my rhinitis! My blood oxygen also returned to 96% (it was consistently below 94%, which was causing me significant anxiety). Chengdu’s air quality is… challenging, to say the least; even doctors at Huaxi Hospital shook their heads at it. Something to consider if you’re thinking of moving here.

For the new year, I’m targeting both cycling and running. I’ve signed up for a half-marathon in Dujiangyan and hope to finish. Weight loss remains a priority—watching what I eat and getting moving. Stay hungry before bed!

Work / Career

Work was a bit rocky this year. I was involved in many disparate things, and several projects didn’t reach a final landing. Looking back, I think it was a lack of planning and execution on my part. Still, I gained a lot of knowledge, researched many technical solutions, and collaborated with customers on several projects. The company is full of “hidden dragons and crouching tigers,” and I need to stay humble and learn from everyone.

AI was obviously the big story this year. AI has integrated into both company and personal workflows—boosting productivity and creating new tools. While it hasn’t completely disrupted our industry yet, we all know that day is coming fast.

“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.” —— Stewart Brand

The most significant social event was traveling from Chengdu to Shenzhen for the GDG DevFest. I caught up with old friends, met people from my online groups, and indulged in my favorite claypot porridge and beef hotpot. Hearing the keynote speeches from various GDEs was incredibly rewarding.

The rest of my social life was mostly cycling with colleagues. Nothing gets you pushing through the Green Belt at midnight on a Friday like the promise of hotpot or spicy skewers afterward. Big shoutout to the cycling crew—let’s keep pushing each other in the new year!

Congratulations to the new parents in the group, and to those who finally got their new homes (even if they’re still single!).

Most of my daily communication happens in my WeChat groups, mostly with Android App and System developers. We have about 2,000 members across 5 groups (though 90% are dedicated lurkers). I’ve met many industry experts through these groups. The mobile world is small—every friend is a connection. It’s a reminder that there’s always someone better out there, so I just need to keep learning.

My biggest takeaway: communicating with people on the same “frequency” saves a lot of effort.

Personal Life / Family

Little Orange is almost three now, and her mom has moved to a new team doing the same work as me: system performance optimization. My biggest wish is for my family to stay happy, healthy, and safe. Due to various reasons, I didn’t spend as much time with my family as I wanted this year, and several travel plans were shelved. In the new year, I need to be more efficient so I can dedicate more time to them.

I read a blog post recently that really resonated with me regarding the ultimate goal of life:

I want to enrich my experiences, do things I’ve never done, and see sights I’ve never seen. I hope one day I can spend my time on myself, not on work, and not on unimportant people or things. More specifically, I hope my family is healthy and safe, with love and companionship. I hope to travel all of China and the world, eat food I’ve never tasted, and see scenes I’ve never envisioned.
Thinking about this brings me clarity. I know what I’m pursuing in this life; the rest isn’t that important. So, how do I get there? I need time, and I need money.
From now on, everything I do revolves around this goal. As long as something moves me toward my ultimate life goal, no matter how hard it is, I must do it. Yes, must. No room for negotiation.

Learning / Knowledge Management

Learning was a bit of a failure this year. My English studies stalled until I picked them up again this month. Technical learning was mostly passive reading without enough writing or deep reflection. I have many unread books on my shelf. I only posted a few blog articles. I know the Feynman technique—using output to drive input—but I haven’t overcome my procrastination yet.

I did develop a good habit at work: using Typora to record daily work, technical projects, research, and bugs. As I switch to Microsoft Loop, I plan to be even more detailed in my logs and reflections and share more with my team to foster a better technical atmosphere.

From my own experience, there are three obstacles to learning:

Finding High-Quality Input: In the age of information overload, finding good sources is key. You need to curate a list of great blogs, GitHub repos, newsletters, and tech teams. (My article Android Performance Optimization Must-Knows is my attempt at this; feel free to recommend others!)
Focusing and Diving Deep: Short-form content is destroying our attention spans. Sitting down to read and think through a deep article or book is becoming harder. We have to train ourselves to step away from social media and regain our focus.
Overcoming Procrastination: We often say we know the “how” but aren’t doing it. Procrastination is a major factor. I recently saw a tip on fighting procrastination: The key is that we procrastinate because something is unfamiliar and we want to avoid it, which creates fear and anxiety. The way to defeat it is to mentally walk through the task first—visualize the steps and details—to get your neurons firing, then act immediately.

I also want to share a few points from a video I saw early in the year called “Life is a Journey, and I too am a Traveler”:

Don’t limit yourself; move quickly into industries with more potential.
Learn aggressively from the best in the field.
Expand your horizons and perspective.
Embrace change, or even seek it out.
Keep doing the work to build a long-term reputation.
Improve your “fault tolerance.”

Travel / Culture

I visited four places this year: Siguniang Mountain, Xiamen, Yantai+Weihai, and Leshan.

Xiamen: A team trip. We saw the sea, ate satay noodles, and ginger duck. The weather there is enviable.
Yantai + Weihai: Attended a wedding, visited my alma mater, and met with former teachers and classmates. The coastal road is still beautiful, and the sunset at the school beach was stunning.
Siguniang Mountain: Drove all day to Western Sichuan. We crossed a pass at 4,800m. My wife and baby had altitude sickness, so we didn’t stay long. But the snow-covered scenery the next morning was breathtaking. I have a video of it here: https://www.bilibili.com/video/BV1H84y1Q7oM. It’s definitely worth another visit.
Leshan: Visited the Giant Buddha and enjoyed the local snacks (sweet-skinned duck and fried skewers are amazing).

Traveling with a baby is a lot of work but so worth it. They see new things, make new friends, and try new foods. We’ll keep doing it in 2024.

Interests / Creativity

Finally, something lighthearted! My main interest this year was cycling. I bought a DJI Action 4 to record my rides. I’m no pro—it’s mostly just continuous shots. Creativity is definitely a talent!

Emotions / Mental State

I’m doing well, though I have some minor anxiety. Much of my well-being comes from my family’s support—having my parents help with the baby and having a spouse who also works in IT and supports my decisions. Chengdu is a great place to live—lots of food, culture, and nature within reach (except for the smog, which is a big negative).

I’ll keep this mindset in 2024: stay positive and get enough sleep.

Finances

We still have a significant mortgage, and most of our salary goes to the bank. We don’t have much income beyond our day jobs, which is a source of anxiety for me—any job loss would create immediate financial pressure. My goal is to manage our money better and control spending. I recently read a breakdown of the financial habits of the poor, the middle class, and the wealthy:

The poor struggle to make ends meet, with income consumed by basic needs.
The middle class are stuck in the “rat race,” working for decades to pay off bills and loans.
The wealthy acquire and hold onto quality assets, creating a “money → asset → money” cycle.

Ultimately, you need to hold quality assets—whether that’s real estate or knowledge. Given my situation, I’ve decided to restart my Knowledge Planet (intro here: The Performance Knowledge Planet Intro). I’m not advertising it; it’s just on the blog. I believe the Feynman and Public Learning techniques are the best ways to learn, and the Knowledge Planet lets me share my daily thoughts, cases, progress, and tools. If that knowledge helps someone else, it’s worth it.

The Final Three

Proudest Achievement

Teaching for three days at the University of Electronic Science and Technology of China (UESTC). It was part of a company partnership, but the process was a huge challenge: from getting the assignment to preparing the slides and finally delivering the lectures. It was my first time, and I’m glad it went well.

I’ll be doing it again this year, and I won’t be as nervous! I need to update the content and optimize the delivery. Explaining Android from top to bottom is never easy.

Greatest Challenge

Beyond work, my biggest challenge is English speaking. There were several times this year where I struggled, which has motivated me to double down on learning. This is a top priority for 2024.

Goals and Wishes for Next Year

Spend more time with family, do new things, and visit new places.
Do a public presentation at a Google DevFest-level event.
Travel abroad once.
Grow the Knowledge Planet community.
Keep fit and complete a marathon.
Read more books.
Update the blog every 2 weeks and finish the Perfetto series.
Record more videos.

My writing is limited, but I’ll close with a quote:

I hope you can figure out “what kind of life you want to live.” Once you have that standard, every decision you make will become incredibly easy.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

Introduction to The Android Performance Knowledge Planet

2023-12-30T00:59:18.000Z

Currently, the “Knowledge Planet” (ZSXQ) is a paid community. The income mainly goes towards blog server costs and buying cat food for my cat, Douzi. It also serves as my motivation to keep updating the blog. If you find the content helpful, consider joining to support the work! Thank you very much!

The community is named The Performance, a circle for sharing Android performance optimization. I am the host—an Android performance developer at a top-tier smartphone manufacturer in China with years of experience in performance, power consumption analysis, and case studies. This community provides a one-stop-shop for performance knowledge, covering fundamentals, methodologies, tools, and valuable real-world case analyses.

As Android evolves, performance optimization has become a top priority for both smartphone manufacturers and app developers. However, performance is a broad topic, involving everything from the Kernel to the Framework and Apps. Each layer requires deep knowledge. Our team established this technical circle to provide high-quality sharing and systematic learning for Android performance optimization.

All members are welcome to share knowledge and cases, ask or answer questions, and grow together. We focus on the following topics:

The current content plan (labels marked with ##) is as follows:

Trace Analysis — 1v1 Trace teaching and analysis (Systrace, Perfetto, SimplePerf, etc., by appointment) and various real-world case analyses.
#The Performance# — Early access to chapters of the “Android Performance Optimization - Systematic Course“ e-book. While there are many high-quality resources available, we aim to provide a truly complete and systematic guide covering principles, tools, and practices for both App and System developers.
#Performance Tools# — Sharing performance analysis tools and usage methods used in Android development. Straightforward 1v1 video guidance for Systrace/Perfetto is also provided.
#Case Analysis# — Summarizing typical case analysis logic and discussing cases provided by community members. Real-world cases are the best path to learning. (Sensitive information will be masked).
#Classic Interpretation# — Deep dives into classic solutions, library analyses, and reviews of top-tier courses like “Android Development Master Class.”
#Knowledge Sharing# — Curated excellent articles, blogs, and open-source tools from industry experts.
#Knowledge Accumulation# — Highlights from WeChat group chats, Q&As, and blog discussions.
#Performance Interviews# — Collection and analysis of Android performance-related interview questions.
#Programming Languages# — Sharing tips and techniques for relevant programming languages.
#Efficiency Improvement# — Methods and tools to improve developer productivity and engineering efficiency.
#Industry Trends# — First-hand interpretations of new performance technologies, including:
- Reports from industry and academic summits.
- New papers, books, and videos.
- Performance updates in major Android versions.
- Performance content related to new Android hardware.
- Deep dives into performance-related open-source projects.
#Expert Sharing# — Regular experience sharing and case sessions with industry experts.
#Job Referrals# — Internal referral opportunities at major tech companies.

Paid Planet QR Code

Scan with WeChat to join (iOS users should use WeChat):

Free Planet QR Code

We also have a free version focused on general knowledge sharing:

WeChat Official Account

Follow the WeChat account for more updates:

WeChat Group

A new communication group for real-time discussion on Android performance topics (Responsiveness, Smoothness, ANR, Crash, Memory, Power, etc.).

Please keep discussions relevant to the themes. Avoid off-topic chatter or vendor debates to maintain the group quality.

We also have groups for casual chat, running, reading, and GPT. You can message me privately to join.

If the group is full (over 200) or the code expires, add me on WeChat (ID: 553000664).

Other Information

Blog: https://www.androidperformance.com/en/
Free Knowledge Planet: https://t.zsxq.com/ZZ337Am
Paid Knowledge Planet: https://t.zsxq.com/Fuvvf6y
Zhihu: https://www.zhihu.com/people/gracker
Jike: https://okjk.co/pJbjFa
Android Weekly (CN): https://androidweekly.zhubai.love/
WeChat Account: AndroidPerformance
Juejin: https://juejin.cn/user/1816846860560749

Performance Considerations in Operating System Design

2023-08-21T10:30:48.000Z

[!NOTE]
This article was originally written by Yingyun for my Knowledge Planet. Since the Planet has closed, I am publishing this series on OS performance design here.
Yingyun is a veteran performance optimization expert with deep insights into system-level tuning, having worked at several major smartphone manufacturers. He is currently active in our community. If you have any questions or feedback, feel free to join our WeChat group.

1. The Genesis

This starts a new series exploring the various considerations in OS architectural design. In reality, these principles apply to the design of any large-scale software.

These views are my own and carry a subjective perspective. I welcome different viewpoints and hope that through their collision, we can all reach a deeper understanding of the field.

From an OS perspective, I believe the core differences between Android and iOS manifest in four areas:

IPC Mechanisms between applications and core services.
Platform Development Environment: programming languages, IDEs, and developer ecosystems.
Application Lifecycle Management: mechanisms and strategies.
Runtime Organization of the kernel and core services.

Why did they make such different strategic decisions? It all boils to the constraints and goals present during their architectural infancy. A software architecture is a collection of decisions made to be the most “correct” for the present and foreseeable future. There is no absolute right or wrong—only choices made under different pressures. If you swapped the contexts of two equally skilled architects, they would likely end up with very similar designs. Architecture is an engineering craft; it follows predictable patterns.

The challenge lies in accurately understanding the organization’s environment and anticipating which factors—testability, release efficiency, security, reliability, performance, or scalability—must be prioritized. An experienced architect knows when to be rigid and when to compromise. Because of the law of diminishing marginal utility, these trade-offs continue throughout the software’s entire lifecycle.

Key takeaways:

Software architecture design varies across different projects based on phase and constraints.
Design decisions are fluid and happen continuously throughout the product lifecycle.

Interestingly, optimization goals often conflict. For example, increasing developer efficiency often comes at the cost of runtime performance. What were the priorities for the original designers of Android and iOS? To answer that, we must first define the relationship between the OS, the application, and the kernel.

2. Mechanism vs. Strategy

An Operating System is part of the software stack built on top of hardware. Together with applications, it forms the complete software environment that leverages hardware to serve the user.

From the hardware’s perspective, both the OS and the app are just software. The OS just has higher privileges (CPU supervisor mode) to interact directly with hardware or handle interrupts. From a developer’s perspective, however, they are worlds apart. The app uses the OS’s capabilities to fulfill business logic or access hardware (e.g., playing audio, storing data).

From a user experience (UX) perspective, the hardware, OS, and app are a single entity. If they fail to collaborate, the device feels broken. All three have an obligation to cooperate to satisfy the consumer.

Most modern OSs consist of a Kernel and System Services:

macOS/iOS: The kernel is Darwin (comprising XNU and MACH microkernels). System services are a collection of daemons providing APIs for data management, UI, etc.
Android: The kernel is Linux. System services include C++ daemons (like SurfaceFlinger) and Java daemons (like SystemServer), providing APIs for rendering, resource management, etc.

While many OSs use similar foundations, the way they are deployed matters. Running an OS is not the same as running it well.

A classic OS design principle is the separation of Mechanism and Strategy:

Mechanism: Provides the capability (the “How”).
Strategy: Decides how to use that capability (the “What”).

In Linux, memory management, process management, and VFS are mechanisms. The specific memory allocator, the process scheduler, and the specific filesystem are strategies.

Furthermore, a system service identifying which processes are user-facing vs. background tasks and syncing that to the scheduler is a strategy built on top of the process management mechanism. Similarly, Dynamic Voltage and Frequency Scaling (DVFS) is a strategy for hardware power management mechanisms.

Mechanisms might be similar across OSs, but strategies vary wildly. This depends on the designer’s understanding of the target service. Early Android followed a desktop-like architecture. Over years of “aggressive” modification by Chinese manufacturers, it has become more iOS-like—aligning better with what a mobile device actually needs.

3. Perspective Decisions

Apple’s OSs (macOS, iOS, watchOS, etc.) share underlying mechanisms but have radically different strategies. iOS uses a “restricted multitasking” strategy for power/performance reasons, while macOS is true multitasking. This wasn’t a technical limitation for iOS; it was a deliberate design choice.

Android is an open-source project (AOSP). Manufacturers take AOSP, add hardware-specific code and their own services. Since manufacturers have different business models and user bases, they modify AOSP differently. The market ultimately judges which modification is superior.

Technically, AOSP provides many mechanisms but lacks cohesive “consumer” strategies. Google implements those strategies in its proprietary GMS (Google Mobile Services). Manufacturers (especially in China) have filled this “strategy gap” by tailoring AOSP to local consumer needs.

The Origin Story

In Becoming Steve Jobs, it’s noted that Jobs initially opposed third-party apps on the iPhone due to power and security concerns. He wanted a device with a “perfect” user experience. He preferred a closed system where Apple controlled every variable to ensure elegance. Because the iPhone used a macOS kernel (XNU), which is resource-heavy, letting third-party code run freely on 2007 hardware was unthinkable.

Eventually, the VP team convinced him that the success of the iTunes + App Store model was too great to ignore. Even then, Apple built its own OS, its own IDE (Xcode), and its own store to define what a “best app” should look like.

Contrast this with Android. Andy Rubin’s goal was a truly open system to balance the interests of developers, manufacturers, and carriers. This required using off-the-shelf components to deploy quickly. There was no time for the same level of polishing because they were in a race for survival.

Android chose Java because it was the most popular language at the time. While Java’s overhead was high for 2007 mobile hardware, it offered portability and a massive developer pool. To make it work, they built a specialized VM (Dalvik/ART). Luckily, Android hit the “golden decade” of exploding mobile CPU performance, which helped it hide its architectural weight compared to iOS.

The Power of the IDE

Apple’s dominance in its ecosystem is largely due to Xcode. It integrates performance analysis, debugging, and distribution so seamlessly that developers can find bottlenecks with minimal learning. LLVM, Swift, and SwiftUI are all tools designed to help developers write software that fits the system’s needs perfectly.

Designing an OS is a means to an end (profit). To achieve that, you must help developers write good code. Many OSs provide the capability but leave the quality to the developer. Apple’s approach is: “I’ll give you limits, but I’ll also give you the solution to work within them.”

4. Strategy: Overload Protection

The biggest constraint of mobile devices is the battery and passive cooling. As transistor density nears physical limits and we pack more features into chips, heat is the enemy.

Mobile OS design naturally necessitates resource limits. Unlike servers, you cannot just let an app run wild. The more constrained the device (like a smartwatch), the stricter the limits.

Android: Primarily uses OOM (Out of Memory) management. It has some basic CPU detection for Java threads, but it’s relatively primitive.
iOS: Has a massive suite of protections. An app is terminated if:
- The device overheats.
- VoIP apps wake the CPU too often.
- BackgroundTask time/CPU usage exceeds thresholds.
- Disk I/O writes exceed limits.
- Memory usage spikes.
- The system suffers from “PageCache Thrashing.”

Google’s “looser” design left room for manufacturers to innovate. However, because these manufacturer-specific “kill” strategies aren’t always documented, developers often resort to “black magic” (keep-alive tricks) to stay running. This leads to a cat-and-mouse game where the user loses.

5. Strategy: Lifecycle Management

In desktop OSs, an app’s lifecycle is controlled by the app itself. The OS tries to give it as much power as possible.

On mobile, the OS decides who lives and dies. Android’s design was initially “loose” (desktop-like). iOS was “strict”—apps entering the background have about 5 seconds to finish work before being suspended.

Manufacturers have implemented “suspension” or “freezing” mechanisms in AOSP, but because they aren’t native core mechanisms, they are often inconsistent. If an app is suspended in iOS, how does it do background work? It uses BackgroundTask APIs. The OS controls when the work happens based on system load and power levels.

This requires a centralized control point, which for Apple is the App Store. It validates that an app’s requested background permissions match its functionality. Without a unified store or GMS in some regions, the Android ecosystem has become “disfigured,” with apps using aggressive tactics to stay alive just to receive notifications.

6. Designing for the Future

The history of electronics is a move toward specialized hardware replacing general CPU tasks (DSA - Domain Specific Architecture). As we hit the end of the “CPU performance dividend,” the next decade belongs to specialized silicon, compilers, and architectures.

Apple’s M1 is the perfect example. It’s not just a faster CPU; it’s a collection of specialized engines (video, media, neural) that outperform general-purpose chips by a massive margin in specific scenarios.

To provide a premium experience, you need an Optimization Matrix: the OS, the IDE, cloud coordination, and specialized hardware working together. It’s no longer just about the code; it’s about the entire loop.

About Me && Blog

(Links and introduction)

Can an App Really Do Whatever It Wants With System Permissions?

2023-05-14T12:15:17.000Z

A while ago, a certain App became very popular because it exploited Android system vulnerabilities to gain system permissions and did a lot of things. I wanted to see what these Apps did after gaining system permissions by exploiting system vulnerabilities, hence this article. Due to hasty preparation, some Code was not looked at carefully. Interested students can research it themselves and discuss more. The corresponding articles and Code links are below:

Regarding how this App obtained these system permissions, History of Android Deserialization Vulnerability Attack and Defense explains it very clearly, so I won’t repeat it here. I am not a security expert either, but I suggest everyone read this article a few times.

Serialization and deserialization refer to the process of converting memory data structures into byte streams for network transmission or saving to disk, and then restoring the byte streams to memory objects. In the field of Web security, there have been many deserialization vulnerabilities, such as PHP deserialization, Java deserialization, etc. Because unexpected program logic is triggered during the deserialization process, attackers can use carefully constructed byte streams to trigger and exploit vulnerabilities to ultimately achieve goals such as arbitrary code execution.

This article mainly looks at the Dex provided in the XXX apk embedded privilege escalation code and dynamic delivery dex analysis repository to see what information the App actually wants to know about the user? generally speaking, after the App obtains system permissions, it mainly does the following things (things that normal Apps cannot or are hard to do), treating users with no respect.

Modifications related to auto-start and associated start, secretly opening or opening by default: Wits and courage battle with mobile phone manufacturers.
Enable notification permissions.
Listen to notification content.
Obtain user’s mobile phone usage information, including installed Apps, usage duration, user ID, user name, etc.
Modify system settings.
Make some system permission tools for its own use.

In addition, it can also be seen that this App has quite deep research on various mobile phone manufacturers, and has specialized processing for terminal manufacturers such as Huawei, Oppo, Vivo, Xiaomi, etc. This is also worth reverse research and defense by mobile phone manufacturers.

Finally, I also added user comments after this article was published on the WeChat official account, as well as the comment section of the Zhihu answer (the question has been deleted, but I can see it: How to evaluate Pinduoduo suspected of using vulnerabilities to attack user mobile phones, steal competitor software data, and prevent itself from being uninstalled? - Gracker’s answer - Zhihu https://www.zhihu.com/question/587624599/answer/2927765317, 2471 likes so far) which can be said to be mind-opening (regarding how Apps can do evil).

0. Dex File Information

The dex files studied in this article were obtained from the XXX apk embedded privilege escalation code and dynamic delivery dex analysis repository. There are a total of 37 Dex files, not many, and not large, let’s look at them slowly. These files are dynamically delivered through the backend server and then dynamically loaded when the App starts. It can be said to be very hidden. However, after all, Android is open source software. It is still very simple to capture the behavior of an App. These Dex files were captured by packet capture, so it can be said that the stolen goods are all there.

Since they are dex files, just use the decompilation tool of the https://github.com/tp7309/TTDeDroid library to open them directly. For example, after I configure it, use the showjar command directly.

showjar 95cd95ab4d694ad8bdf49f07e3599fb3.dex

It is opened with jadx by default, and you can see the decompiled content. We just need to focus on the code logic inside the Executor.

After opening, you can see the specific functional logic. You can see that a dex generally only does one thing, so we just need to focus on the core implementation part of this thing.

1.1 Obtain Xiaomi Mobile Phone Notification Content

File: 95cd95ab4d694ad8bdf49f07e3599fb3.dex
Function: Get the user’s Active notifications
Class Name: com.google.android.sd.biz_dynamic_dex.xm_ntf_info.XMGetNtfInfoExecutor

1. Reflectively get ServiceManager

Generally, we get the system Service through the getService method of ServiceManager, and then make a remote call.

2. Get detailed content of notifications through NotificationManagerService

After getting NotificationManager by passing in NotificationManagerService through getService, you can call the getActiveNotifications method, and then specifically get the following fields of the Notification:

Title of the notification
Package name of the App that generated the notification
Notification sending time
key
channelID: the id of the channel this notification posts to.

Maybe some people don’t know what this thing is. The picture below shows a typical notification.

Its code is as follows

You can see that the getActiveNotifications method is System-only. Ordinary Apps cannot read Notifications casually, but this App can obtain them because it has permission.

Of course, WeChat’s anti-revoke plugin generally uses another method, such as accessibility services. This thing is compliant, but I still recommend that everyone avoid using it if possible. If it can help you prevent revocation, it can obtain the content of the notification, including what you know and what you don’t know.

1.2. Open Notification Permissions on Xiaomi Phones (Push)

File: 0fc0e98ac2e54bc29401efaddfc8ad7f.dex
Function: Sometimes Xiaomi users may turn off App notifications. The App wants to know if the user has turned off notifications. If it is turned off, it will be turned on secretly.
Class Name: com.google.android.sd.biz_dynamic_dex.xm_permission.XMPermissionExecutor

It seems that this should be quite practical. You naughty user, I send notifications for your own good, how can you bear to turn me off? Let me turn it on for you secretly.

The App calls setNotificationsEnabledForPackage of NotificationManagerService to set notifications, which can force notifications to open.
frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

Then check the setNotificationsEnabledForPackage method of NotificationManagerService to see if the user has opened it successfully.
frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

And there is separate processing for leb~ Detailed!

1.3. Open Notification Permissions on Vivo Phones (Push)

File: 2eb20dc580aaa5186ee4a4ceb2374669.dex
Function: Vivo users will turn off App notifications, so that the App cannot receive notifications on Vivo photos. That won’t do, it must be turned on secretly.
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_open_push.VivoOpenPushExecutor

The core is the same as the one above, except that this one is specifically for vivo phones.

1.4 Open Notification Permissions on Oppo Phones

File: 67c9e686004f45158e94002e8e781192.dex
Class Name: com.google.android.sd.biz_dynamic_dex.oppo_notification_ut.OppoNotificationUTExecutor

It was not decompiled. Looking at the approximate logic, it should be to open the notification permission of the App on oppo phones.

1.5 Notification Listener

File: ab8ed4c3482c42a1b8baef558ee79deb.dex
Class Name: com.google.android.sd.biz_dynamic_dex.ud_notification_listener.UdNotificationListenerExecutor

This is a bit powerful. It is listening to the sending of App Notifications, and then conducting statistics.

Core code for listening

I don’t understand this very well either. It’s time to ask my wife who has been doing SystemUI and Launcher for many years for help…. @ShiGong

1.6 App Notification Listener

File: 4f260398-e9d1-4390-bbb9-eeb49c07bf3c.dex
Class Name: com.google.android.sd.biz_dynamic_dex.notification_listener.NotificationListenerExecutor

The one above is UdNotificationListenerExecutor, this one is NotificationListenerExecutor. What is UD?

The setNotificationListenerAccessGranted called by reflection is a SystemAPI, gaining the right to use notifications. Sure enough, with permission, you can do whatever you want.

1.7 Open Notification Listener permissions on Huawei Phones

File: a3937709-b9cc-48fd-8918-163c9cb7c2df.dex
Class Name: com.google.android.sd.biz_dynamic_dex.hw_notification_listener.HWNotificationListenerExecutor

Huawei cannot be spared either, hahaha

1.8 Open Notification permissions on Huawei Phones

File: 257682c986ab449ab9e7c8ae7682fa61.dex
Class Name: com.google.android.sd.biz_dynamic_dex.hw_permission.HwPermissionExecutor

2. Backup Status

File: 6932a923-9f13-4624-bfea-1249ddfd5505.dex
Function: Backup Related

After watching this for a long time, it should be specifically for Huawei phones. After receiving the IBackupSessionCallback callback, execute the PackageManagerEx.startBackupSession method.

I checked the function of this method, start backup or restore session.

File: 8c34f5dc-f04c-40ba-98d4-7aa7c364b65c.dex
Function: Backup Related

3.1 Obtain SLog and SharedPreferences Content on Huawei Phones

File: da03be2689cc463f901806b5b417c9f5.dex
Class Name: com.google.android.sd.biz_dynamic_dex.hw_get_input.HwGetInputExecutor

What do you want this for? Take it for data analysis?

Get SharedPreferences

Get slog

4. User Data

4.1 Obtain data of user using mobile phone

File: 35604479f8854b5d90bc800e912034fc.dex
Function: You know it is to get the data of the user using the mobile phone just by looking at the name
Class Name: com.google.android.sd.biz_dynamic_dex.usage_event_all.UsageEventAllExecutor

Looking at the core logic, it is the same as the usagestates service to obtain data on users using mobile phones. No wonder they know exactly what Apps I have installed on my phone and how long I have used them.

So what data can it get? Everything one could wish for~, including but not limited to App startup, exit, suspension, Service changes, Configuration changes, screen on/off, power on/off, etc. Interested parties can take a look:

frameworks/base/core/java/android/app/usage/UsageEvents.java
    private static String eventToString(int eventType) {
        switch (eventType) {
            case Event.NONE:
                return "NONE";
            case Event.ACTIVITY_PAUSED:
                return "ACTIVITY_PAUSED";
            case Event.ACTIVITY_RESUMED:
                return "ACTIVITY_RESUMED";
            case Event.FOREGROUND_SERVICE_START:
                return "FOREGROUND_SERVICE_START";
            case Event.FOREGROUND_SERVICE_STOP:
                return "FOREGROUND_SERVICE_STOP";
            case Event.ACTIVITY_STOPPED:
                return "ACTIVITY_STOPPED";
            case Event.END_OF_DAY:
                return "END_OF_DAY";
            case Event.ROLLOVER_FOREGROUND_SERVICE:
                return "ROLLOVER_FOREGROUND_SERVICE";
            case Event.CONTINUE_PREVIOUS_DAY:
                return "CONTINUE_PREVIOUS_DAY";
            case Event.CONTINUING_FOREGROUND_SERVICE:
                return "CONTINUING_FOREGROUND_SERVICE";
            case Event.CONFIGURATION_CHANGE:
                return "CONFIGURATION_CHANGE";
            case Event.SYSTEM_INTERACTION:
                return "SYSTEM_INTERACTION";
            case Event.USER_INTERACTION:
                return "USER_INTERACTION";
            case Event.SHORTCUT_INVOCATION:
                return "SHORTCUT_INVOCATION";
            case Event.CHOOSER_ACTION:
                return "CHOOSER_ACTION";
            case Event.NOTIFICATION_SEEN:
                return "NOTIFICATION_SEEN";
            case Event.STANDBY_BUCKET_CHANGED:
                return "STANDBY_BUCKET_CHANGED";
            case Event.NOTIFICATION_INTERRUPTION:
                return "NOTIFICATION_INTERRUPTION";
            case Event.SLICE_PINNED:
                return "SLICE_PINNED";
            case Event.SLICE_PINNED_PRIV:
                return "SLICE_PINNED_PRIV";
            case Event.SCREEN_INTERACTIVE:
                return "SCREEN_INTERACTIVE";
            case Event.SCREEN_NON_INTERACTIVE:
                return "SCREEN_NON_INTERACTIVE";
            case Event.KEYGUARD_SHOWN:
                return "KEYGUARD_SHOWN";
            case Event.KEYGUARD_HIDDEN:
                return "KEYGUARD_HIDDEN";
            case Event.DEVICE_SHUTDOWN:
                return "DEVICE_SHUTDOWN";
            case Event.DEVICE_STARTUP:
                return "DEVICE_STARTUP";
            case Event.USER_UNLOCKED:
                return "USER_UNLOCKED";
            case Event.USER_STOPPED:
                return "USER_STOPPED";
            case Event.LOCUS_ID_SET:
                return "LOCUS_ID_SET";
            case Event.APP_COMPONENT_USED:
                return "APP_COMPONENT_USED";
            default:
                return "UNKNOWN_TYPE_" + eventType;
        }
    }

4.2 Obtain User Usage Data

File: b50477f70bd14479a50e6fa34e18b2a0.dex
Class Name: com.google.android.sd.biz_dynamic_dex.usage_event.UsageEventExecutor

The one above is UsageEventAllExecutor, and this one is UsageEventExecutor, which mainly gets data related to user usage of Apps, such as when to open a certain App, when to close a certain App. It is very clever, truly malignant.

4.3 Obtain User Usage Data

File: 1a68d982e02fc22b464693a06f528fac.dex
Class Name: com.google.android.sd.biz_dynamic_dex.app_usage_observer.AppUsageObserver

It looks like the permissions for App Usage are registered, but the specific Code has not come out, so it is hard to analyze.

According to reminders from onlookers, the App can forge an icon through Widget. When the user long-presses the icon to uninstall the App, you think you have uninstalled it, but in fact you have deleted the Widget it forged, and the real App is still there (But I haven’t encountered it. Doing this is really mind-opening, and doesn’t treat Android users as humans).

File: f9b6b139-4516-4ac2-896d-8bc3eb1f2d03.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_widget.VivoAddWidgetExecutor

This is relatively easy to understand, adding a Widget on Vivo phones.

File: da60112a4b2848adba2ac11f412cccc7.dex
Class Name: com.google.android.sd.biz_dynamic_dex.get_icon_info.GetIconInfoExecutor

This is easy to understand. Obtain icon related information, such as which row and column on Launcher, whether it is in a folder. The question is what is this for??? Puzzle.

File: 75dcc8ea-d0f9-4222-b8dd-2a83444f9cd6.dex
Class Name: com.google.android.sd.biz_dynamic_dex.oppoaddwidget.OppoAddWidgetExecutor

5.4 Update icon on Xiaomi Phones?

File: 5d372522-b6a4-4c1b-a0b4-8114d342e6c0.dex
Class Name: com.google.android.sd.biz_dynamic_dex.xm_akasha.XmAkashaExecutor

Desktop icon, shortcut related operations on Xiaomi phones. Xiaomi students come to claim.

6.1 Open Auto-start on Oppo Phones

File: e723d560-c2ee-461e-b2a1-96f85b614f2b.dex
Class Name: com.google.android.sd.biz_dynamic_dex.oppo_boot_perm.OppoBootPermExecutor

Looking at the pile below, you know it is related to auto-start. careful. It seems that auto-start permission is a pain for every App.

6.2 Open Vivo Associated Start Permission

File: 8b56d820-cac2-4ca0-8a3a-1083c5cca7ae.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_association_start.VivoAssociationStartExecutor

Look at the name and you know it is permission related to associated start. Vivo students come to claim it.

Directly wrote a node into it

6.3 Turn off Huawei Power Consumption Wizard

File: 7c6e6702-e461-4315-8631-eee246aeba95.dex
Class Name: com.google.android.sd.biz_dynamic_dex.hw_hide_power_window.HidePowerWindowExecutor

Looking at the name and implementation, it should be related to Huawei’s power consumption wizard. Huawei students can take a look.

File: 7877ec6850344e7aad5fdd57f6abf238.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_get_loc.VivoGetLocExecutor

Guessing it is related to keep alive. Vivo students can come and claim it.

7.1 Vivo Phone Rollback Uninstallation

File: d643e0f9a68342bc8403a69e7ee877a7.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_rollback_uninstall.VivoRollbackUninstallExecutor

This looks like rolling back to the preset version after the user uninstalls the App. Well, this is a routine operation.

7.2 Vivo Phone App Uninstallation

File: be7a2b643d7e8543f49994ffeb0ee0b6.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_official_uninstall.OfficialUntiUninstallV3

Looking at the name and implementation, it is also related to uninstallation rollback.

File: 183bb87aa7d744a195741ce524577dd0.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_official_uninstall.VivoOfficialUninstallExecutor

Same as above

Others

SyncExecutor

File: f4247da0-6274-44eb-859a-b4c35ec0dd71.dex
Class Name: com.google.android.sd.biz_dynamic_dex.sync.SyncExecutor

I didn’t understand what it does. The core should be Utils.updateSid, but I didn’t see where it is implemented.

UdParseNotifyMessageExecutor

File: f35735a5cbf445c785237797138d246a.dex
Class Name: com.google.android.sd.biz_dynamic_dex.ud_parse_nmessage.UdParseNotifyMessageExecutor

Looking at the name, it should be parsing Notify Message sent from the remote end. Specific function unknown.

6.3 TDLogcatExecutor

File
1. 8aeb045fad9343acbbd1a26998b6485a.dex
2. 2aa151e2cfa04acb8fb96e523807ca6b.dex
Class Name
1. com.google.android.sd.biz_dynamic_dex.td.logcat.TDLogcatExecutor
2. com.google.android.sd.biz_dynamic_dex.td.logcat.TDLogcatExecutor

I didn’t quite understand what this is for. It looks like keep alive but not like it. I will analyze it slowly when I have time later.

6.4 QueryLBSInfoExecutor

File: 74168acd-14b4-4ff8-842e-f92b794d7abf.dex
Class Name: com.google.android.sd.biz_dynamic_dex.query_lbs_info.QueryLBSInfoExecutor

Get LBS Info

6.5 WriteSettingsExecutor

File: 6afc90e406bf46e4a29956aabcdfe004.dex
Class Name: com.google.android.sd.biz_dynamic_dex.write_settings.WriteSettingsExecutor

Looking at the name, it should be a utility class for writing Settings fields. As for what fields to write, it should be dynamically delivered.

6.6 OppoSettingExecutor

File: 61517b68-7c09-4021-9aaa-cdebeb9549f2.dex
Class Name: com.google.android.sd.biz_dynamic_dex.opposettingproxy.OppoSettingExecutor

Setting proxy?? Didn’t understand what it does. Oppo students come to claim. Could it be another form of keep alive?

6.7 CheckAsterExecutor

File: 561341f5f7976e13efce7491887f1306.dex
Class Name: com.google.android.sd.biz_dynamic_dex.check_aster.CheckAsterExecutor

Check aster? Not very understandable.

6.8 OppoCommunityIdExecutor

File: 538278f3-9f68-4fce-be10-12635b9640b2.dex
Class Name: com.google.android.sd.biz_dynamic_dex.oppo_community_id.OppoCommunityIdExecutor

Get Oppo user’s ID? What do you want this for?

6.9 GetSettingsUsernameExecutor

File: 4569a29c-b5a8-4dcf-a3a6-0a2f0bfdd493.dex
Class Name: com.google.android.sd.biz_dynamic_dex.oppo_get_settings_username.GetSettingsUsernameExecutor

Get the username of the Oppo phone user. Say, what do you need this for?

6.10 LogcatExecutor

File: 218a37ea-710d-49cb-b872-2a47a1115c69.dex
Class Name: com.google.android.sd.biz_dynamic_dex.logcat.LogcatExecutor

Configure Log parameters

6.11 VivoBrowserSettingsExecutor

File: 136d4651-df47-41b4-bb80-2ec0ab1bc775.dex
Class Name: com.google.android.sd.biz_dynamic_dex.vivo_browser_settings.VivoBrowserSettingsExecutor

Vivo browser related settings, don’t quite understand what it wants to do.

Comments area is more exciting than the article

WeChat Official Account Comment Area

Zhihu Comment Area

The Zhihu answer has been deleted. I can see it through the homepage, but clicking in shows it has been deleted: How to evaluate Pinduoduo suspected of using vulnerabilities to attack user mobile phones, steal competitor software data, and prevent itself from being uninstalled? - Gracker’s answer - Zhihu https://www.zhihu.com/question/587624599/answer/2927765317

Which is more secure, iOS or Android?

Here I will paste the comment of security big shot sunwear

About Me && Blog

Below are personal introduction and related links. I hope to communicate more with everyone in the industry. If three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: There are personal WeChat and WeChat group links inside.
This Blog Content Navigation: A navigation of personal blog content.
Excellent blog articles organized and collected by individuals - A must-know for Android efficiency optimization: Everyone is welcome to recommend themselves and recommend others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for your support~

One person can go faster, a group of people can go further

The Performance Community Tea Talk - Episode 1

2022-03-27T15:46:37.000Z

On Friday, March 25, 2022, at 9 PM, “The Performance” Knowledge Planet held its first online “Tea Talk.” We were joined by 3 planet hosts, 5 guest experts, and over 50 members. Thank you all for coming!

While we expected to wrap up in an hour, we ended up chatting for over two and a half hours—our introductions alone took an hour! Our community spans the entire Android ecosystem: from App-tier experts to System-level gurus at major smartphone manufacturers, silicon companies, and EV startups. Each introduction naturally evolved into deep dives into industry trends and company-specific insights.

We plan to hold these regularly with clearer themes and more guests. To protect the privacy of our members, we did not record the session. The following text is a reconstructed summary of our discussion.

On Career Development

“I’m a new grad and the vastness of the performance field is overwhelming.”

Shift Your Mindset: University and professional work are different. In school, you have a textbook and a final exam. In the field, the “curriculum” never ends.
Learn from What’s at Hand: Master the problems on your desk first. Aim for 100% or even 110% proficiency in your daily tasks while building a foundation for broader knowledge. Doing your current job exceptionally well earns you the reputation and the opportunity to touch new, more complex things. Don’t jump to a new field until you’ve mastered (or explicitly rejected) your current one.
Problem-Oriented Programming: Your primary value to an employer is your ability to solve problems. Use an economic lens: maximize your output-to-input ratio (marginal utility).
Climbing the Mountain: If you only stare at the peak, you’ll feel defeated. Keep your head down, take one step at a time, and check your map (and current career path) occasionally.

“I just switched from App development to System Performance. Where do I start?”

Follow Company Projects: If you have a mentor, follow them closely. This is the fastest way to learn.
Self-Drive: The more you learn on your own, the more opportunities you’ll be able to seize. Masters of performance aren’t just given tasks; they identify them.
Don’t Limit Yourself: Knowledge is interconnected. Don’t stay in your “one-acre plot.” Performance spans App, Framework, Kernel, and Hardware. Aim for a state of “knowing what you don’t know.” The worst state is “not knowing that you don’t know” and thinking there’s nothing left to optimize.
Systematize Knowledge: Performance is a broad field. When analyzing problems, take notes, summarize, and categorize. Don’t expect instant mastery; it’s a marathon of accumulation.
Leverage Resources: Use this community, engineering blogs from major tech companies, and technical papers. Ask questions, no matter how “basic” they seem.

On Asking Questions

This community is a powerful platform, but its value depends on your ability to ask precise questions. Asking a good question is a technical skill in itself.
Recommended Reading: How to Ask Questions?
- “A well-put question is half the solution.”
- Einstein once said: “If I had an hour to save the world, I would spend 55 minutes defining the problem and 5 minutes solving it.”
- Great questions inspire masters to teach. It is a bridge to the best minds.
Use Google: The quality difference between Google and local search engines can be vast for niche technical issues. Don’t discriminate between Chinese and English resources—if it solves your problem, it’s a gold mine.
Log Sharing:
- If you need help and your logs contain sensitive info (like package names in a Systrace), use a text editor like VSCode to find-and-replace them.
- Never share trade secrets.
The Perfect Feedback Loop: Ask a question -> Analyze together -> Try solutions -> Verify with data -> Share the result with the community.

On Interviews

It’s healthy to interview occasionally with competitors or companies in new industries, even if you aren’t planning to quit. The goal is to gauge your “market value” and understand how the industry is evolving.

Distinguish between your profession and your job. “Software Engineer” is your profession; “Working on Module X at Company A” is your job. Recognizing this difference allows you to remain calm during corporate restructuring. Ideally, pursue a profession you find exciting, as you’ll spend most of your life doing it.

On Corporate Environments

Different companies have different strategies based on their industry and competition. Your manager’s style and your colleagues’ expertise define your immediate environment.

Some organizations reward “top 5% technical excellence,” while others only care that “the bug is fixed” regardless of how. Understand the game you are playing. Either challenge the environment or adapt to it, but don’t fall into the trap of self-doubt.

On Learning New Tech

Performance optimization has underlying logic that stays constant regardless of the tech stack. Focus on these “immutable” principles. Once you see the patterns, you can apply them to any new technology.

If you optimize deep enough, you eventually hit the bottom: Compilers, Hardware features, and Hardware integration. These are the ultimate gatekeepers of speed.

On GPU

GPU Architectures: Each generation and manufacturer (Adreno, Mali, PowerVR) differs, but they share fundamental principles.
Wait, if I’m new to Graphics, should I start with Vulkan?
No, start with OpenGL. While Vulkan is the future, its API is extremely low-level and difficult for beginners. The underlying GPU mechanisms are the same. Mastering OpenGL makes Vulkan much easier to digest.
Why Vulkan?
Check out Apple’s Bringing OpenGL Apps to Metal. (Metal and Vulkan share many design philosophies).

Final Tip: Learning graphics and GPU internal counters (via tools like DS5 Streamline or Snapdragon Profiler) is a marathon. Be patient and keep practicing.

Recommended Resources

Articles

“Ten-Year Founder Shares Thoughts on Hiring”: categorizes talent into S, A, B, and C tiers. Worth reflecting on which tier you occupy.

Books

“The Self-Cultivation of a Programmer” (俞甲子): Deep dive into compilation, linking, and runtime mechanics.
“Software Debugging (2nd Ed)” (张银奎): The “Encyclopedia” of debugging.
- Vol 1: Hardware Foundations (CPU/GPU/Debug infrastructure).
- Vol 2: Windows Platform.
- Vol 3: (Upcoming) Linux Platform.

About The Performance Community

“The Performance” is a hub for Android performance experts from major mobile manufacturers. We offer case studies, methodologies, and tool guides. You can find us on Knowledge Planet (The Performance).

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

Systrace Thread CPU State Analysis Tips - Sleep and Uninterruptible Sleep

2022-03-13T00:38:12.000Z

This is the third article in the “Systrace Thread CPU State Analysis Tips” series. It focuses on the Sleep and Uninterruptible Sleep states in Systrace—their causes, troubleshooting, and optimization. These states are major performance inhibitors and are often difficult to diagnose without a systematic approach.

The goal of this series is to use Systrace to view the Android system from a different perspective and to learn the Framework through visualization. While reading Framework source code can be difficult to remember, seeing the flow in Systrace can lead to deeper understanding. You can find the complete Systrace Basics and Action Series here.

What are Sleep States in Linux?
Analyzing the Sleep State
Analyzing the Uninterruptible Sleep State
Appendix
About Me && Blog

What are Sleep States in Linux?

TASK_INTERRUPTIBLE vs. TASK_UNINTERRUPTIBLE

If a thread’s state is neither Running nor Runnable, it is in a “Sleep” state (strictly speaking, there are other states like STOP or Trace, but these are rare in performance analysis).

In Linux, Sleep states are categorized into three:

TASK_INTERRUPTIBLE
TASK_UNINTERRUPTIBLE
TASK_KILLABLE (equivalent to TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)

In Systrace/Perfetto, “Sleep” refers to TASK_INTERRUPTIBLE (visualized in white). “Uninterruptible Sleep” refers to TASK_UNINTERRUPTIBLE (visualized in orange).

Both indicate a sleeping state where the thread receives no CPU time slices. It only transitions to “Runnable” (blue) and then “Running” (green) when specific conditions are met.

The core difference: TASK_INTERRUPTIBLE can process signals, while TASK_UNINTERRUPTIBLE cannot—even Kill signals. Consequently, uninterruptible threads cannot be woken by any method except the specific resource they are waiting for. TASK_WAKEKILL is a variant that can process Kill signals.

Android’s Looper, Java/Native lock waits, and most app logic reside in TASK_INTERRUPTIBLE (Sleep). Looking at a Systrace, you’ll see vast white segments representing these idle periods.

The Purpose of TASK_UNINTERRUPTIBLE

Why do we need an uninterruptible state?

Interrupts come from hardware (signals to the CPU) or software (signals like softirq or Signal). A process can usually handle these at any time using its own context. However, some critical paths—like hardware driver interactions, IO waits, or networking—must not be disturbed.

Tasking a thread as uninterruptible ensures logic doesn’t enter an uncontrollable state. Similarly, the Linux kernel temporarily disables the interrupt controller during hardware scheduling or disables preemption during core scheduling to maintain control. While these states are usually brief, they can severely impact performance under system stress.

Kernel Reference: TASK_UNINTERRUPTIBLE

Typical scenarios include Swap reads, semaphores, mutex locks, and slow-path memory reclamation.

Analysis Philosophy

TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE are normal. However, if their cumulative percentage is high, especially on a critical path, investigation is required. Master these two points:

Troubleshooting Methodology
Optimization Methodology

You must identify if a sleep is active or passive. If active, is the logic sound? If passive, what is the source? This requires deep system knowledge and experience.

Note: I’ll use “Sleep” for TASK_INTERRUPTIBLE and “UninterruptibleSleep” for TASK_UNINTERRUPTIBLE to match Systrace terminology.

Initial confusion is normal and stems from system complexity. There is no single “magic” tool that explains every logic chain. Even Systrace’s wakeup_from data can be inaccurate. You must combine system theory with Trace tools to pinpoint root causes.

This article covers common types and cases. Use these diagnostic methods and source code analysis to navigate unique problems.

Visualization in Trace

Analyzing the Sleep State

Diagnostic Methods

Use `wakeup from tid: ***` to Find Waking Threads

Sleep usually results from a program actively waiting for an event (like a lock), meaning there is a clear “waking source.” Figure 1 shows UIThread waiting for RenderThread. While you can infer this from code, it requires mastery of the Android graphics stack.

A simpler method is tracing wakeup from tid: ***. As discussed in the Runnable article, any thread must pass through “Runnable” before “Running.”

There are two ways to enter Runnable:

A “Running” task is preempted.
Another thread wakes a “Sleep” task.

In Systrace, the latter is visualized as wakeup from tid: ***, while preemption is visualized as Running Instead.

Warning: wakeup from data is tied to specific tracepoints and can sometimes be inaccurate. Verify before proceeding.

Other Methods

Simpleperf: Reconstruct code execution flow. See Simpleperf Analysis 1: Visualizing Data with Firefox Profiler.
Aligning Timeframes: Look for simultaneous events across different threads/processes in Systrace. This is error-prone but can provide clues.

Common Causes for Long Sleep

Binder Operations: Enable Binder tracing to see the remote execution thread. Analyze the remote side—is it lock contention? CPU starvation?
Java/Futex Lock Contention: Very common, especially under high load in SystemServer. This is a side effect of Binder’s parallel or preemptive resource usage.
Active Wait: Thread waiting for another, like a semaphore. Check if the logic is essential.
GPU Wait: Waiting for a GPU fence. Caused by heavy rendering, weak GPU, or low GPU frequency. Optimization: Increase GPU frequency, simplify Shaders, reduce resolution/texture quality, etc.

Analyzing the Uninterruptible Sleep State

Diagnostic Methods

UninterruptibleSleep is a type of sleep, so general methods apply. It has two unique attributes:

Categorized into IOWait and Non-IOWait
Provides a Block Reason

IOWait vs. Non-IOWait

IO Wait occurs when a program initiates an IO operation (e.g., fetching data not in PageCache). Memory is orders of magnitude faster than disk; frequent disk reads decimate performance.

Non-IO Wait typically indicates a kernel-level lock wait or a driver-enforced wait. For example, Binder driver lock contention can become a bottleneck under heavy loads.

Block Reason

Around 2015, Google’s Riley Andrews added a kernel tracepoint to record IO wait status and calling functions during UninterruptibleSleep. This powers Systrace’s IOWait and BlockReason fields. (Check your kernel if this patch is missing, as it’s not in the main Linux upstream).

1 2	# Sched blocked tracepoint commit snippet sched: add sched blocked tracepoint which dumps out context of sleep.

In ftrace, it appears as:

1	sched_blocked_reason: pid=30235 iowait=0 caller=get_user_pages_fast+0x34/0x70

Systrace Visualization:

The get_user_pages_fast reason is a Linux kernel function name. To understand the wait, you must look at its implementation:

/* get_user_pages_fast() implementation snippet */
int get_user_pages_fast(...) {
  ...
  /* Attempt to pin pages without taking mm->mmap_lock.
   * If not successful, fall back to taking the lock... */
  ...
}

This function tries to pin pages locklessly. If it fails, it must take the lock and follow the “slow path.” If the lock is held elsewhere, it enters UninterruptibleSleep. Use the Sleep diagnosis method to find the locker.

UninterruptibleSleep is complex because it involves kernel implementation. It could be a kernel bug or improper app usage. You must correlate system-wide behavior.

Common Causes for IOWait and Optimizations

1. Active IO Operations

Frequent/large read/write operations.
Multiple apps stressing the disk simultaneously.
Poor hardware IO performance (check with an IO Benchmark). Causes: Fragmentation, aging, low free space (notorious on low-end devices), read/write amplification.
File system internal overhead.
Swap data reads.

Optimization Methods:

Tune Readahead mechanisms.
Use PinFile (pinning files to PageCache).
Adjust PageCache reclamation policies.
Optimize junk file cleanup.

2. High IO due to Low Memory

OS design treats memory as a disk cache. If memory is ample, most operations are in RAM. If memory is critically low, almost all IO hit the physical disk, causing severe lag.

The fix is ensuring enough memory or refining cache eviction algorithms.

Optimization Methods:

Reduce IO operations on critical paths.
Leverage Readahead.
Group hot data to increase Readahead hit rates.
Reduce massive memory allocations and waste.

Apps that use memory recklessly force the system to suppress them, eventually hurting their own performance.

Common Causes for Non-IOWait

Memory Reclamation Wait: OS reclaiming pages for other apps/cache during low memory.
Binder Wait: High frequency of Binder operations.
Various Kernel Locks: Use the “Diagnostic Methods” above to pinpoint.

System Scheduling and UninterruptibleSleep Coupling

An interesting phenomenon occurs when a thread is in UninterruptibleSleep (kernel lock), but the holder of that lock is stuck in a “Runnable” state due to CPU scheduling. Even if the wait is for a fast operation, it appears elongated because the dependency isn’t being prioritized by the scheduler.

Resolving this requires sophisticated scheduler tuning—a true test of a manufacturer’s technical depth.

Appendix

Linux Thread State Definitions

Thread State	Description
S	SLEEPING
R, R+	RUNNABLE
D	UNINTR_SLEEP
T	STOPPED
t	DEBUG
Z	ZOMBIE
X	EXIT_DEAD
x	TASK_DEAD
K	WAKE_KILL
W	WAKING

Case: Waiting for Swap Data

Case: `mmap` Contention Across Multiple Threads

Threads sharing the same mm_struct compete for the lock during mmap() syscalls.

/* mmap lock area snippet */
if (mmap_write_lock_killable(mm))
  return -EINTR;
ret = do_mmap(...);
mmap_write_unlock(mm);

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Systrace Thread CPU State Analysis Tips - Running

2022-03-13T00:38:04.000Z

This is the second article in the “Systrace Thread CPU State Analysis Tips” series. It analyzes the causes of the “Running” state in Systrace and provides optimization strategies for when Running segments are excessively long.

Causes for Long Running States
About Me && Blog

Long Running Duration

Visualization

In Trace, a green segment indicates the thread is in the Running state.

Cause 1: High Code Complexity and Execution Time

This is the most common cause. While rare, platform bugs can occur if manufacturers add heavy logic to high-frequency core functions in libc or system calls, prolonging execution time.

Optimization Suggestions: Optimize logic and algorithms to reduce complexity. To pinpoint which specific function is time-consuming, use the AS CPU Profiler, simpleperf, or add custom trace points via the Trace.begin/end() API.

Cause 2: Interpreted Code Execution

The keyword “Compiling” in a Trace might indicate interpreted execution. This frequently occurs with newly installed Apps that haven’t undergone odex optimization.

Optimization Suggestions: Test with a dex2oat optimized version. Low performance under interpreted execution can only be improved by running dex2oat or optimizing the code itself.

Additionally, certain language features like frequent JNI calls or repetitive reflection can slow down execution. Beyond experience, use CPU Profiler or simpleperf for diagnosis.

Cause 3: Thread Running on Small Cores

For CPU-bound operations, Small Cores may not meet performance needs as they are designed for non-UX-critical threads. However, Android cannot always guarantee optimal scheduling, and tasks may be assigned to Small Cores.

Optimization Suggestions: Use Thread Affinity (Core Binding) or SchedBoost to ensure threads run on cores with higher compute power, like Big Cores. If migrating cores doesn’t help, check if the frequency is being scaled properly (see Cause 4).

Cause 4: Big Cores Running at Low Frequencies

Optimization Suggestions:

Optimize code logic to reduce load, allowing smooth execution even at lower frequencies.
Adjust scheduler frequency-scaling parameters for more aggressive scaling based on load.
Use platform-provided APIs to lock the CPU at a specific frequency (commonly known as “locking frequency”).

Cause 5: Thermal Throttling: Core Shutdown and Frequency Capping

Optimization Suggestions:

Due to structural heat dissipation limits or aggressive thermal parameters, almost all manufacturers will cap CPU frequency or shut down cores to prevent overheating and burns. The first step is identifying the heat trigger.

Distinguish between external and internal factors. External factors include ambient heat (sunlight, heaters), which is worse in summer.

Internal factors are primarily driven by the CPU, Modem, camera module, or other power-intensive components. For the CPU, if a background thread is saturating a core, resolve it first. If a foreground app’s high load causes high current draw, reduce that load. For other components, check for unnecessary operation, then optimize business logic.

If thermal parameters are overly aggressive, compare with competitors to tune the parameters for a better balance.

Cause 6: Weak CPU Compute Power

Optimization Suggestions:

ARM processors with the same frequency can vary significantly in performance due to microarchitecture configurations. L1/L2 Cache capacity also heavily impacts MIPS (Million Instructions Per Second).

Two optimization paths:

Compiler Parameters: Difficult for most App developers. System vendors (like Huawei with the Ark Compiler) optimize JNI and code efficiency to boost performance without changing App source code.
Code Logic Optimization: Use tools like simpleperf to find hot spots or observe CPU behavior:
- High Cache Miss Rate: Optimize memory access patterns.
- Excessive Complex Instructions: Refactor code to reduce complexity.
- Caching: Design robust business caches to improve hit rates and avoid “churn” (repeated allocation/deallocation).

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Systrace Thread CPU State Analysis Tips - Runnable

2022-01-21T02:40:18.000Z

This is the first article in the “Systrace Thread CPU State Analysis Tips” series. It analyzes the causes of the “Runnable” state in Systrace and provides optimization strategies for when Runnable segments are excessively long.

Runnable State Explanation
Causes for Long Runnable States and Optimization Strategies
About Me && Blog

Runnable State Explanation

Visualizing Runnable in Trace

The article Systrace Thread CPU State Analysis Tips - Running discusses why the “Running” state might take a long time. This section focuses on the principles of the “Runnable” state and corresponding troubleshooting. In Systrace, it appears as a blue segment, indicating that the thread is in a Runnable state, waiting to be scheduled by the CPU.

As shown in Figure 2, a CPU core can only execute one thread at any given moment. Therefore, all tasks waiting for execution are queued in a “runnable queue” (or “run queue”), with one queue per CPU core. A thread in this queue has already acquired all necessary resources (IO, locks, semaphores, etc.) except for the CPU itself. In this state, the thread is marked as RUNNABLE, which appears as the blue segments in Systrace.

The Linux kernel achieves multitasking by giving threads time slices and rotating them. When a “Running” thread’s time slice (typically in milliseconds) expires, it is set to “Runnable” to wait for its next turn. A special case is “preemption,” where a high-priority thread interrupts a running thread before its time slice expires.

Multi-core CPUs can execute multiple threads simultaneously, so it’s not always necessary for everyone to wait on the same core. The Linux scheduler manages “load balancing” by migrating threads across cores based on load. It uses “Schedule Classes” to manage priorities:

SCHED_RR, SCHED_FIFO: Real-time classes with higher priority than NORMAL.
SCHED_NORMAL: Common class, currently using the CFS (Completely Fair Scheduler).

Real-time priorities outrank normal priorities; high-priority tasks can preempt low-priority ones, and low-priority tasks must wait for high-priority ones to finish. Usually, Runnable durations are very short, but anomalies can prevent critical tasks from finishing within deadlines.

This often involves multiple threads, especially for UI tasks. In AOSP, a typical frame flows through UI Thread → Render Thread → SurfaceFlinger → HWC (Figure 3). If any thread in this chain is blocked in a Runnable state and misses the rendering deadline, jank (frame drop) occurs.

Causes of Long Runnable States and Optimization Strategies

We categorize common causes into 5 major groups. Most are system-level, but App logic can also cause long Runnable states.

Cause 1: Incorrect Priority Settings

App priority too high: Preempts other tasks, making them appear lower priority and causing them to wait.
App priority too low: If the thread is on a “critical path,” it has a higher chance of being stuck as Runnable, leading to jank.
System Bugs: Framework incorrectly assigning very high or low priorities.

Optimization Strategies:

Adjust thread priority based on the scenario; identify which thread is preempting yours in the Trace.
System-level: Set critical threads to the FIFO scheduling policy.

In practice, many Apps become more laggy after setting custom priorities because their strategy might work on one device but clash with the custom scheduler of another manufacturer. Generally, third-party developers should avoid direct priority APIs to prevent counterproductive results.

A more reliable long-term approach is designing a proper task model—never put time-sensitive tasks on generic worker threads.

Cause 2: Improper CPU Affinity (Core Binding)

To speed up execution, developers often bind threads to “Big Cores.” While this helps the “Running” phase, it must be done cautiously. Binding a thread to a specific core prevents it from running anywhere else, even if other cores are idle. If too many threads are bound to the same core, that core becomes a bottleneck, leading to long “Runnable” queues.

Core Binding Tips:

Don’t bind to a single core: This has zero fault tolerance. If that core is preempted, the thread must wait. Bind to a “CPU Cluster” (e.g., Big Cores 4-7) instead.
Avoid cluster overcrowding: On platforms with only 2 big cores, binding too many threads to them quickly leads to saturation, making binding a “negative optimization.”
Identify cores correctly: Core indices vary. 4-7 aren’t always Big Cores; some platforms use 0-3 as Big Cores.
Respected CPUSETS: Binding only works within the process’s allowed cpuset. Attempting to bind a thread to cores 4-7 when the process is restricted to 0-3 will fail or cause errors.

Cause 3: Poor Software Architecture Design

Runnable represents time spent in a CPU queue. Common sense says the longer the queue or more frequent the queuing, the higher the risk. Complex tasks spanning many threads (e.g., rendering) are more vulnerable because each thread transition adds a potential queuing delay.

If your programming model requires heavy orchestration between many threads (A hands off to B, A waits for B, B wakes A), any CPU congestion will amplify the “Runnable” wait at every handoff.

Optimization Strategies:

Adjust priorities (see Cause 1).
Optimize architecture to minimize cross-thread handoffs/wakes. Use Trace to visualize thread dependencies and CPU Profiler to inspect logic.
Platform-level: Modify the scheduler to identify “thread groups” with dependency chains and prioritize them together.

Cause 4: High Application or System Load

If massive numbers of tasks are forced into a single core’s run queue, lower-priority tasks will inevitably wait longer.

In Perfetto/Systrace, check the CPU core view. If you see a dense, gapless sequence of tasks even after zooming in, the system load is likely high (CPU usage $>90%$). Select an interval and sort tasks by duration to see what is consuming the CPU.

Two main sources of high load:

1. High App-Specific Load

The App itself saturates the CPU by spawning dozens of threads simultaneously.

Optimization Suggestions:

Identify high-usage threads and check for abnormal behavior.
Optimize the load of the thread itself using simpleperf.
Use a higher-priority scheduler (e.g., RT), but use caution as this introduces new risks.
Separate critical and non-critical threads. Bind non-critical threads to Small Cores or set low priorities; set high priorities for rendering threads. Assume a harsh environment—Android doesn’t guarantee your App exclusive resources.

2. High System Service Load

Some manufacturer ROMs have inefficient background services that consume excessive resources. Additionally, poor management might allow “rogue apps” to stay active in the background for sync/keep-alive operations.

3. Manufacturer “Magic” Technologies

Manufacturers can optimize resource allocation to favor foreground Apps:

CPUSETS: Group threads by priority and restrict them to specific clusters. AOSP has this but with flaws:
- Many background tasks can still saturate all cores.
- Doesn’t always respect process states (Music, Navigation, etc.).
- Doesn’t manage sub-processes forked from Java processes well.
CPUCTL: Set resource quotas (e.g., cap CPU usage for rogue or background processes).
Freezing Technology: Freeze background processes to deny them CPU entirely (similar to iOS). Challenges include handling IPC, process relations, and compatibility.
On-demand Startup: Tight control over system and background auto-starts.

Cause 5: CPU Capacity Limits, Throttling, and State Anomalies

Just like a queue at a clinic—fewer windows mean longer waits. Weak CPU power, core shutdowns, or frequency capping increase Runnable probability.

Scenario-Based Control
- Different frequency/core policies for different modes.
- Locking frequencies/cores due to high temperature.
Low Power Mode: e.g., Qualcomm’s LPM.
C-State Transitions: Latency when switching from deep sleep (C2/C1) to active (C0).
Hardware Failure: Rare but possible.
Low-End Devices: Cheap CPUs with low compute power.

Observations:

Scenario Control: This tests a manufacturer’s tuning. Apps should aim for lower load to avoid triggering platform restrictions. Manufacturers must balance power and performance per scenario.
Thermal Throttling: See “Cause 5: Thermal Throttling” in Systrace Thread CPU State Analysis Tips - Running.
Low-End Devices: Truly weak CPUs simply can’t process tasks as fast as flagship chips, leading to more queuing.

Cause 6: Scheduler Anomalies

While rare, scheduler bugs or misconfigured “governors” can cause tasks to pile up on a few cores while others are idle.

System developers should build robust “observability” to diagnose these fleeting issues that are difficult to reproduce.

Cause 7: 32-bit vs. 64-bit Process Handling

Transitionary chips (like Snapdragon 8 Gen 1 or Dimensity 9000) have strange restrictions. 32-bit Apps might be restricted to specific microarchitectures, while 64-bit Apps run freely. If your App is still 32-bit, its tasks might be forced onto a subset of cores, increasing Runnable congestion.

App Developers: Upgrade to 64-bit immediately.
System Developers: Identify legacy Apps and optimize background management to reduce their load.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

Techniques, Philosophy, and Tools for Android Performance Optimization

2022-01-06T16:42:03.000Z

In his book Hackers & Painters, Paul Graham asserted, “The disparity in the efficiency of languages is becoming more pronounced, hence the rising importance of profilers. Currently, performance analysis isn’t given the attention it deserves. Many still seem to hold onto the belief that the key to accelerating program execution lies in developing compilers that generate faster code. As the gap between code efficiency and machine performance widens, it will become increasingly apparent that enhancing the execution speed of application software hinges on having a good profiler to guide program development.” by Paul Graham, Hackers & Painters

A Google search for “Android optimization tools” yields an abundance of related content. The issue with these results is that they either contain highly repetitive content or directly explain usage methods. Rarely do they introduce a holistic architecture, inadvertently instilling a misguided belief of “one tool fixes all”. Drawing from the extensive experience of my team, I can assert that in the realm of performance analysis, no such magic bullet tool exists. Tools evolve, old problems re-emerge in new forms, and without mastering core logic, one remains on the technological surface.

This article first systematically untangles the observability technology in performance analysis, encompassing data types, capture methods, and analysis techniques. Subsequently, we introduce the “big three” analysis tools provided by Google. The aim is to impart immutable theoretical knowledge and corresponding tools available in the Android environment to the reader. This wealth of information can facilitate a more direct application of predecessors’ experiences, circumventing unnecessary detours.

It’s crucial to note that there are certainly more than these three tools available for performance optimization. However, these three are our “go-to first-hand tools”. Prior to delving into further analysis, you’ll find yourself dependent on these three tools for bottleneck identification. Subsequent analyses, tailored to distinct domain characteristics, should then leverage corresponding tools.

1 Observability Techniques in Performance Analysis

Has this operation been executed? How long did it take?
Why is there a significant difference between two versions?
What operations is the system executing when CPU usage is high?
Why has the startup speed slowed down?
Why does this page always stutter when scrolling?

You’ve likely been asked similar questions by colleagues or bosses more than once. The most primitive idea might be to obtain the relevant logs and analyze them one by one. Based on past experience, one would search for clues by looking for keywords. If the desired information is not available, the next step is to add logs and attempt to reproduce the issue locally. This approach is not only time-consuming and laborious, but also wastes developmental resources. Have you ever wondered if there is a more efficient method in the industry? A method that can improve efficiency by an order of magnitude, allowing us to spend our time solving problems instead of on mundane, repetitive physical tasks?

Of course, there is (otherwise this article wouldn’t exist)—we refer to it as observability techniques.

As the computer industry has evolved, pioneers in computing have devised a category known as “observability techniques.” It involves utilizing tools to observe the intricate details of complex systems’ operations—the more detailed, the better. Mobile operating systems evolved from embedded systems. Nowadays, the computing power of mid-to-high-end Android phones can catch up with a mainframe from two decades ago, and the resulting software complexity is also immense.

Employing a well-designed and smoothly operating observability technique can significantly accelerate software development efficiency. This is because, despite using a variety of preemptive static code detection and manual code reviews, it is impossible to block software issues 100%. Problems only become apparent after the software is run in a real environment, which might be an automated test case of yours. Even then, you still need to sift through your logs and re-read code to identify the problem. For these reasons, every engineering team needs a fully functional observability tool as one of their fundamental infrastructures.

Observability is a systematic engineering effort that allows you to delve deeper into occurrences within the software. It can be used to understand the internal operational processes of software systems (especially complex business logic or interactive systems), troubleshoot, and even optimize the program by identifying bottlenecks. For complex systems, understanding the entire operational process through code reading can be challenging. A more efficient approach is to utilize observability tools to obtain the software’s operational status most intuitively.

We will explore data types, data acquisition methods, and analysis methods to help you understand observability techniques in the sections below.

1.1 Data Types

Logs can be in the form of key-value pairs, JSON, CSV, relational databases, or any other formats. We recreate the entire state of the system at the time it was running through logs to solve a specific issue, observe the operation of a module, or even depict the behavioral patterns of system users. In observability technology, log types are classified into Log, Metric, and Trace types.

Log Type

Logs are the most rudimentary form of data recording, typically noting what happened at what time in which module, whether the log level is a warning or an error. Nearly all systems, whether embedded devices or computers in cars, utilize this form of log. It is the simplest, most direct, and easiest to implement. Almost all Log types are stored as strings, presenting data in lines of text. Logs are the most basic type, and through conversion, can be turned into Metric or Trace types, though the conversion process can become a bottleneck when dealing with massive amounts of data.

Different log types are usually distinguished by error, warning, and debug levels. Naturally, error logs are your primary concern. However, in practice, this classification is not always strict, as many engineers do not differentiate between them, possibly due to a lack of classification analysis for different log levels in their engineering development environment. In summary, you can grade Log types according to your objectives. It acts like an index, enhancing the efficiency of problem analysis and target information location.

Metric Type

Metric types are more focused compared to Log types, recording numerical changes in a particular dimension. Key points are the “dimension” and “numerical change.” Dimensions could be CPU usage, CPU Cluster operation frequency, or context switch counts. Numerical changes can be instant values at the time of sampling (snapshot type), the difference from the previous sampling, or aggregated statistical values over a period. Statistics are often used in practice, such as when wanting to observe the average CPU usage five minutes before an issue occurred. In this case, an arithmetic mean or weighted average calculation of all values within these five minutes is required.

Aggregation is a useful tool because it’s not possible for a person to analyze all Metric values individually. Determining the existence of a problem through aggregation before conducting detailed analysis is a more economical and efficient method.

Another benefit of the Metric type is its fixed content format, allowing data storage through pre-encoding, utilizing space more compactly and occupying less disk space. The most straightforward application is data format storage; Metric types, using integers or floating numbers of fixed byte data, are more space-efficient than Log types, which generally use ASCII encoding.

In addition to specific values, enumeration values can also be stored (to some extent, their essence is numerical). Different enumeration values represent different meanings, possibly indicating on and off statuses, or different event types.

Trace Type

Trace types indicate the time, name, and duration of an event. Relationships among multiple events identify parent-child or sibling connections. Trace types are the most convenient data analysis method when dissecting complex call relationships across multiple threads.

Trace types are particularly suitable for Android application and system-level analysis scenarios because they can diagnose:

Function call chains
Binder call chains during invocation
Cross-process event stream tracing

In the design of Android’s application running environment, an application can’t perform all functionalities independently; it requires extensive interaction with the SystemServer. Communication with the SystemServer is facilitated through Binder, a communication method detailed later in this article. For now, understand that it involves cross-process calling. Accurate restoration of call relationships requires data from both ends, making Trace the optimal information recording method.

You can manually add starting and ending points for Trace types and insert multiple intervals within a function. With pre-compilation technology or language features, Trace intervals can automatically be instrumented at the beginning and end of functions. In an ideal scenario, the latter is the best approach as it allows for understanding what functions are running in the system, their execution conditions, and call relationships. This information can identify the most frequently called (hottest) functions and the most time-consuming ones. Understandably, this method incurs a significant performance loss due to the frequency and magnitude of function calls, especially in complex systems.

An alternative approach involves approximating the above effect by sampling call stacks. Shorter sampling intervals more closely approximate real call relationships and durations, but they can’t be too short, as obtaining stack operations itself becomes a load due to increased frequency. This method, known as a Profiler in the industry, is the basis for most programming language Profiler tools.

1.2 Data Acquisition Methods

Static Code and Dynamic Tracing

Static code collection is the most primitive method. It’s straightforward to implement but requires recompiling and reinstalling the program each time new content is added. If the information you need to diagnose a problem isn’t available, you have no choice but to repeat the entire process. A more advanced approach is to pre-install data collection points at all potential areas of interest, and use dynamic switches to control their output. This technique balances performance impacts and allows dynamic enabling of logs as needed, albeit at a high cost.

Dynamic tracing technology has always been available but is often considered the “holy grail” in the debugging and tracing field due to its steep learning curve. It demands a deep understanding of low-level technologies, especially in areas like compilation, ELF format, the kernel, and programming languages associated with pre-set probes and dynamic tracing. Indeed, dynamic tracing even has its own set of programming languages to cater to the dynamic implementation needs of developers. This approach balances performance and flexibility and enables dynamic retrieval of desired information even in live versions.

In Android application development and system-level development, dynamic tracing is rarely used and is occasionally employed in kernel development. Typically, only specialized performance analysts might utilize these tools. Two critical elements of dynamic tracing are probes and dynamic languages. The program’s execution permission must be handed over to the dynamic tracing framework at specific probe points during runtime. The logic executed by the framework is written by developers using dynamic languages.

Therefore, your program must first have probes. Linux kernel and other frameworks have embedded corresponding probe points, but Android application layers lack these. Currently, dynamic frameworks like eBPF on Android are mainly used by kernel developers.

Unconditional and Conditional Capture

Unconditional capture is straightforward: data is continuously captured after triggering, regardless of any conditions. The drawback is that when the observed object generates a large volume of data, it could significantly impact the system. In such cases, reducing the volume of data captured can mitigate the impact, striking a balance between meeting requirements and minimizing performance loss.

Conditional capture is often employed in scenarios where anomalies can be identified. For instance, capturing logs is triggered when a specific observed value exceeds a pre-set threshold and continues for a certain duration or until another threshold is reached. This method is a slight improvement over unconditional capture as it only impacts the system when an issue arises, leaving it unaffected at other times. However, it requires the capability to identify anomalies, and those anomalies should not necessitate historical data preceding the occurrence. Lowering the threshold can increase the probability of triggering data capture, leading to the same issues faced with unconditional capture, and requiring a balance of performance loss.

Disk Write Strategy

Continuous disk writing involves storing all data captured during the entire data capture process, which can strain storage resources. If the trigger point, such as an anomaly, can be identified, selective disk writing becomes an option. To ensure the validity of historical data, logs are temporarily stored in a RingBuffer and only written to disk upon receiving a disk write command. This method balances performance and storage pressure but at the cost of runtime memory consumption and the accuracy of the trigger.

1.3 Analysis Methods

Data Visualization Analysis

As the complexity of problem analysis increases, especially with the need to address performance issues arising from the interactions among multiple modules, data visualization analysis methods have emerged. These methods visualize events on respective lanes with time as the horizontal axis, facilitating a clear understanding of when specific events occur and their interactions with other systems. In Android, tools like Systrace/Perfetto and, earlier, KernelShark, are fundamentally of this type. The “Trace Type” mentioned in “Data Types” often employs this kind of visualization.

Systrace’s visualization framework is built on a Chrome subproject called Catapult. The Trace Event Format outlines the data formats supported by Catapult. If you have Trace type data, you can use this framework for data visualization. AOSP build systems and the Android app compilation process also output corresponding Trace files, with visualization effects based on Catapult.

Database Analysis

For extensive data analysis, formatting data and converting it into two-dimensional data tables enables efficient query operations using SQL. In the server domain, technology stacks like ELK offer flexible formatted search and statistical functions. With databases and Python, you can even create an automated data diagnostic toolchain.

From the discussion above, it’s evident that text analysis and database analysis serve different analytical purposes. Text analysis is sufficient for evaluating the time consumption of a single module, visualization tools are needed for interactions among multiple systems, and SQL tools are required for complex database analysis. Regardless of the analysis method, the core is data analysis. In practice, we often convert data using other tools to support different analysis methods, such as transitioning from text analysis to database analysis.

Choosing the right analysis method according to your objectives can make your work highly efficient.

For Android developers, Google provides several essential performance analysis tools to assist both system and app developers in optimizing their programs.

2 Google’s Android Performance Analysis Tools

Based on practical experience, the most commonly used tools are Systrace, Perfetto, and the Profiler tool in Android Studio. Only after identifying the main bottlenecks using these tools would you need to resort to other domain-specific tools. Therefore, we will focus on the application scenarios, advantages, and basic usage of these three tools. For a horizontal comparison between the tools, please refer to the content in the next chapter, “Comprehensive Comparison.”

2.1 First Generation System Performance Analysis Tool - Systrace

Systrace is a visualization analysis tool for the Trace type and represents the first generation of system-level performance analysis tools. It supports all the features facilitated by the Trace type. Before the emergence of Perfetto, Systrace was essentially the only performance analysis tool available. It presents the operating information of both the Android system and apps graphically. Compared to logs, Systrace’s graphical representation is more intuitive; and compared to TraceView, the performance overhead of capturing Systrace can be virtually ignored, minimizing the impact of the observer effect to the greatest extent.

Systrace Design Philosophy

Systrace embeds information similar to logs, known as TracePoints (essentially Ftrace information), at key system operations (such as Touch operations, Power button actions, sliding operations, etc.), system mechanisms (including input distribution, View drawing, inter-process communication, process management mechanisms, etc.), and software and hardware information (covering CPU frequency information, CPU scheduling information, disk information, memory information, etc.). These TracePoints depict the execution time of core operation processes and the values of certain variables. The Android system collects these TracePoints scattered across various processes and writes them into a file. After exporting this file, Systrace analyzes the information from these TracePoints to obtain the system’s operational information over a specific period.

In the Android system, some essential modules have default inserted TracePoints, classified by TraceTag, with information sources as follows:

TracePoints in the Framework Java layer are implemented through the android.os.Trace class.
TracePoints in the Framework Native layer are executed using the ATrace macro.
App developers can customize Trace through the android.os.Trace class.

Consequently, Systrace can collect and display all information from both upper and lower layers of Android. For Android developers, Systrace’s most significant benefit is turning the entire Android system’s operational status from a black box into a white box. Its global nature and visualization make Systrace the first choice for Android developers when analyzing complex performance issues.

Practical Applications

The parsed Systrace, rich in system information, is naturally suited for analyzing the performance issues of both Android Apps and the Android system. Android app developers, system developers, and kernel developers can all use Systrace to diagnose performance problems.

From a Technical Perspective:
Systrace can cover major categories involved in performance, such as response speed, frame drops or janks, and ANR (Application Not Responding) issues.
From a User Perspective:
Systrace can analyze various performance issues encountered by users, including but not limited to:
- Application Launch Speed Issues: Including cold start, warm start, and hot start.
- Slow Interface Transitions: Including slow transitions and janky animations.
- Slow Non-Transition Click Operations: Such as toggles, pop-ups, long presses, selections, etc.
- Slow Screen Brightness Adjustment Speed: Including slow on/off speed, slow unlocking, slow face recognition, etc.
- List Scrolling Jankiness:
- Window Animation Lag:
- Interface Loading Jankiness:
- Overall System Lag:
- App Unresponsiveness: Including freeze and crash issues.

When encountering the above problems, various methods can be employed to capture Systrace. The parsed file can then be opened in Chrome for analysis.

The ability to trace and visualize these issues makes Systrace an invaluable tool for developers aiming to optimize the performance of Android applications and the system itself. By analyzing the data collected, developers can identify bottlenecks and problematic areas, formulate solutions, and effectively improve the performance and responsiveness of apps and the Android operating system.

2.2 The Next-Generation Performance Analysis Full Stack Tool - Perfetto

Google initiated the first submission in 2017, and over the next four years (up until Dec 2021), over 100 developers made close to 37,000 commits. There are PRs and merges almost daily, marking it as an exceptionally active project. Besides its powerful features, its ambition is significant. The official website claims it to be the next-generation cross-platform tool for Trace/Metric data capture and analysis. Its application is also quite extensive; apart from the Perfetto website, Windows Performance Tool, Android Studio, and Huawei’s GraphicProfiler also support the visualization and analysis of Perfetto data. We believe Google will continue investing resources in the Perfetto project. It is poised to be the next-generation performance analysis tool, wholly replacing Systrace.

Highlighted Features

The most significant improvement of Perfetto over Systrace is its ability to support long-duration data capture. This is made possible by a service that runs in the background, enabling the encoding of collected data using Protobuf and saving it to disk. From the perspective of data sourcing, the core principle is consistent with Systrace, both based on the Linux kernel’s Ftrace mechanism for recording key events in both user and kernel spaces (ATRACE, CPU scheduling). Perfetto supports all functionalities provided by Systrace, hence the anticipation of Systrace being replaced by Perfetto entirely.

Perfetto’s support for data types, acquisition methods, and analysis approaches is unprecedentedly comprehensive. It supports virtually all types and methods. ATRACE enables the support for Trace type, a customizable node reading mechanism supports Metric type, and in UserDebug versions, Log type support is realized by obtaining Logd data.

You can manually trigger capture and termination via the Perfetto.dev webpage or command-line tools, initiate long-duration capture via the developer options in the settings, or dynamically start data capture via the Perfetto Trigger API integrated within the framework. This covers all scenarios one might encounter in a project.

In terms of data analysis, Perfetto offers a data visualization analysis webpage similar to Systrace, but with an entirely different underlying implementation. The biggest advantage is its ability to render ultra-large files, a feat Systrace cannot achieve (it might crash or become extremely laggy with files over 300M). On this visualization webpage, one can view various processed data, execute SQL query commands, and even view logcat content. Perfetto Trace files can be converted into SQLite-based database files, enabling on-the-spot SQL execution or running pre-written SQL scripts. You can even import it into data science tool stacks like Jupyter to share your analysis strategies with colleagues.

For example, if you want to calculate the total CPU consumption of the SurfaceFlinger thread, or identify which threads are running on large cores, etc., you can collaborate with domain experts to translate their experiences into SQL commands. If that still does not meet your requirements, Perfetto also offers a Python API, converting data into DataFrame format, enabling virtually any desired data analysis effect.

With all these offerings, developers have abundant aspects to explore. From our team’s practical experience, it can almost cover every aspect from feature development, function testing, CI/CD, to online monitoring and expert systems. In the subsequent series of articles on our planet, we will focus on Perfetto’s powerful features and the expert systems developed based on it, aiding you in pinpointing performance bottlenecks with a single click.

Practical Application

Perfetto has become the primary tool used in performance analysis, with Systrace’s usage dwindling. Hence, the tool you should master first is Perfetto, learning its usage and the metrics it provides.

However, Perfetto has its boundaries. Although it offers high flexibility, it essentially remains a static data collector and not a dynamic tracing tool, fundamentally different from eBPF. The runtime cost is relatively high because it involves converting Ftrace data to Perfetto data on the mobile device. Lastly, it doesn’t offer text analysis methods; additional analyses can only be performed via webpage visualization or operating SQLite. In summary, Perfetto is powerful, covering almost every aspect of observability technology, but also has a relatively high learning curve. The knowledge points worth exploring and learning are plentiful, and we will focus on this part in our upcoming articles.

2.3 Android Studio Profiler Tool

The integrated development environment for Android application development (officially recommended) is Android Studio (previously it was Eclipse, but that has been phased out). It naturally needs to integrate development and performance optimization. Fortunately, with the iterations and evolution of Android Studio, it now has its own performance analysis tool, Android Profiler. This is a collective tool integrating several performance analysis utilities, allowing developers to optimize performance without downloading additional tools while developing applications in Android Studio.

Currently, Android Studio Profiler has integrated four types of performance analysis tools: CPU, Memory, Network, and Battery. The CPU-related performance analysis tool is the CPU Profiler, the star of this chapter. It integrates all CPU-related performance analysis tools, allowing developers to choose based on their needs. Many people might know that Google has developed some independent CPU performance analysis tools, like Perfetto, Simpleperf, and Java Method Trace. CPU Profiler does not reinvent the wheel; it gathers data from these known tools and parses it into a desired style, presenting it through a unified interface.

Highlighted Features

CPU Profiler integrates performance analysis tools: Perfetto, Simpleperf, and Java Method Trace. It naturally possesses all or part of the functionalities of these tools, such as:

System Trace Recording: Information captured with Perfetto, useful for analyzing process function duration, scheduling, rendering, etc. However, it’s a simplified version, only displaying process-strongly related information and filtering out short-duration events. It’s recommended to export the Trace file for analysis on https://ui.perfetto.dev/.
Java Method Trace Recording: It gathers function call stack information from the virtual machine, used for analyzing Java function calls and duration.
C/C++ Function Trace: Information captured with Simpleperf. Simpleperf gathers data from the CPU’s performance monitoring unit (PMU) hardware component. C/C++ Method Trace has only partial functionalities of Simpleperf, used for analyzing C/C++ function calls and durations.

Practical Application

Application performance issues are mainly divided into two categories: slow response and lack of smoothness.

Slow response issues include slow app startup, slow page transitions, slow list loading, slow button responses, etc.
Lack of smoothness issues include unsmooth list scrolling, page sliding not following hand movements, animation judders, etc.

How to use CPU Profiler in these scenarios? The basic approach is to capture a System Trace first, analyze and locate the issue with System Trace. If the issue can’t be pinpointed, further analysis and location should be done with Java Method Trace or C/C++ Function Trace.

Taking an extremely poor-performing application as an example, suppose Systrace TracePoint is inserted at the system’s critical positions and the code is unfamiliar. How do you identify the performance bottleneck? First, run the application and record a System Trace with CPU Profiler (the tool usage will be introduced in later articles), as shown below:

From the above Trace, it’s evident that the onDrawFrame operation in the egl_core thread is time-consuming. If the issue isn’t apparent, it’s advised to export it to https://ui.perfetto.dev/ for further analysis. By looking into the source code, we find that onDrawFrame is the duration of the Java function onDrawFrame. To analyze the duration of the Java function, we need to record a Java Method Trace, as follows:

From the above Trace, it’s easy to see that a native function called Utils.onDraw is time-consuming. Because it involves C/C++ code, another C/C++ Function Trace needs to be recorded for further analysis, as shown below:

It becomes clear that the code executed a sleep function within the native Java_com_gl_shader_Utils_onDraw, pinpointing the culprit for the poor performance!

The greatest advantage of CPU Profiler in AS is the integration of various sub-tools, enabling all operations in one place. It’s incredibly convenient for application developers. However, system developers might not be so lucky.

2.4 Comparative Analysis

Tool Name	Application Scenario	Data Type	Data Acquisition Method	Analysis Method
Systrace	Android System & App Performance Analysis	Trace Type	Unconditional Capture, Continuous Logging	Visual Analysis
Perfetto	Android System & App Performance Analysis	Metric Type, Trace Type	Unconditional Capture, Continuous Logging	Visual Analysis, Database Analysis
AS Profiler	Android System & App Performance Analysis	Trace Type	Unconditional Capture, Continuous Logging	Visual Analysis
SimplePerf	Java/C++ Function Execution Time Analysis, PMU Counters	Trace Type	Unconditional Capture, Continuous Logging	Visual Analysis, Text Analysis
Snapdragon Profiler Tools & Resources	Primarily for Qualcomm GPU Performance Analyzer	Trace Type, Metric Type	Unconditional Capture, Continuous Logging	Visual Analysis
Mali Graphics Debugger	ARM GPU Analyzer (for MTK, Kirin chips)	Trace Type, Metric Type	Unconditional Capture, Continuous Logging	Visual Analysis
Android Log/dumpsys	Comprehensive Analysis	Log Type	Conditional Capture, Continuous Capture but not Logging	Text Analysis
AGI (Android GPU Inspector)	Android GPU Analyzer	Trace Type, Metric Type	Unconditional Capture, Continuous Logging	Visual Analysis
eBPF	Dynamic Tracing of Linux Kernel Behavior	Metric Type	Dynamic Tracing, Conditional Capture, Continuous Capture but not Logging	Text Analysis
FTrace	Linux Kernel Tracing	Log Type	Static Code, Conditional Capture, Continuous Capture but not Logging	Text Analysis

3 On “Instruments, Techniques, Philosophy”

Technical revolutions and improvements are often reflected at the “instruments” level. The development direction of tools by the Linux community and Google is towards enhancing the integration of tools so that necessary information can be easily found in one place, or towards the collection of more information. In summary, the development trajectory at the instruments level is traceable and developmental rules can be summarized. We need to accurately understand their capabilities and application scenarios during rapid iterations of tools, aiming to improve problem-solving efficiency rather than spending time learning new tools.

The “techniques” level depends on specific business knowledge, understanding how a frame is rendered, how the CPU selects processes for scheduling, how IO is dispatched, etc. Only with an understanding of business knowledge can one choose the right tools and correctly interpret the information provided by these tools. With rich experience, sometimes you can spot clues even without looking at the detailed information provided by tools. This is a capability that arises when your business knowledge is enriched to a certain extent, and your brain forms complex associative information, elevating you above the tools.

At the “philosophy” level, considerations are about the nature of the problem that needs to be solved. What is the essence of the problem? What extent should be achieved, and what cost should be incurred to achieve what effect? For solving a problem, which path has the highest “input-output ratio”? What is the overall strategy? To accomplish something, what should be done first and what should be done next, and what is the logical dependency relationship?

In subsequent articles, explanations will be provided in the “instruments, techniques, philosophy” manner for a technology or a feature. We aim not only to let you learn a knowledge point but also to stimulate your ability to extrapolate. When faced with similar tools or problems, or even completely different systems, you can handle them with ease. Firmly grasping the essence, you can choose the appropriate tools or information through evaluating the “input-output ratio” and solve problems efficiently.

About Me && Blog

About Me: I am eager to interact and progress together with everyone.
Follow me on Twitter
Blog Content Navigation
Record of Excellent Blog Articles - Essential Skills and Tools for Android Performance Optimization

An individual can move faster, a group can go further.

Android Performance Optimization: Techniques, Methods, and Tools

2022-01-06T16:42:03.000Z

In his book , Paul Graham states: “The execution efficiency gap between different programming languages is becoming increasingly large, so profilers are becoming more important. Currently, performance profiling is not receiving enough attention. Many people still believe that the key to improving program running speed is developing compilers that can generate faster code. The gap between code efficiency and machine performance is continuously increasing, and we will increasingly clearly see that the key to improving application software running speed is having a good performance profiler to guide program development.”

By Paul Graham — Hackers and Painters

If you Google search “Android optimization tools,” you’ll find many related contents. Their problem is that content is highly repetitive, or they directly explain usage methods. They rarely introduce overall architecture, which can easily make you form the erroneous cognition of “one tool handles everything.” Based on my team’s years of experience, in the performance profiling field, such a silver bullet-level tool does not exist. Tools are evolving, old problems will appear in new forms. If you don’t master the core logic, you’ll always float on the surface of technology.

This article will systematically organize observable technologies in performance profiling, covering three parts of content: data types, capture methods, and analysis methods. After that, we’ll introduce Google’s “Big Three” analysis tools. The goal is to let you understand immutable theoretical knowledge and corresponding tools available in the Android environment, so you can take fewer detours and directly reuse predecessors’ experience.

It’s important to note that for performance optimization, there are certainly more than just these three tools available, but these three are the “first-tier tools” we usually use. Before conducting further analysis, you’ll need to rely on these three tools for bottleneck positioning, and then choose corresponding tools for deep-dive analysis based on different domain characteristics.

1 Observable Technologies in Performance Profiling

Was this operation actually executed? How long did execution take?
Why is there such a huge difference between two versions?
What operations is the system executing when CPU usage becomes high?
Why did startup speed become slower?
Why does this page always stutter for a moment?

I believe everyone has been asked similar questions by colleagues or bosses. The most primitive thought should be to first get relevant logs and analyze them line by line. Based on past experience, find clues by searching for keywords. If you can’t find the information you want, then add logs and try to reproduce locally. This is time-consuming to say the least, and also consumes R&D resources. But have you ever thought whether there’s a more efficient method in the industry? One that can improve your efficiency by a magnitude, letting you spend your time on problem-solving rather than boring repetitive physical labor?

The answer of course is yes (otherwise there wouldn’t be this article). We call it Observable Technologies.

Computer industry development to date, predecessors of the field have捣鼓 out what are called “observable technologies.” It studies how to use tools to observe detailed execution of complex systems. The more detailed the content, the better. Before mobile operating systems, there were embedded systems. Current high-end Android phones’ computational power can catch up to the computational power of a main computer from twenty years ago. On this computational foundation, the software complexity brought by mobile phones is also very huge.

If your program deploys a well-designed and good-performing observable technology, it can greatly accelerate R&D software efficiency. Because even if we use various upfront static code checking and manual code reviews, we can’t 100% intercept software problems. Only after running in real environment do you know whether problems actually occurred. Even if this environment might be an automated test case of yours. Even so, you still need to read through your logs and reread code to find problems. For these reasons, every engineering team needs to have a functionally complete observable technology as one of their infrastructure.

Observable technology is a systematic engineering project that allows you to more deeply understand what’s happening inside the software system. It can be used to understand the internal execution process of software systems (especially for business logic or systems with complex interaction relationships), troubleshoot problems or even find bottleneck points to optimize the program itself. For complex systems, understanding the entire execution process through reading code is actually quite difficult. A more efficient method is to use such tools to obtain the software system’s running state in the most intuitive way.

The following will help you understand observable technologies from three themes: data types, data acquisition methods, and analysis methods.

1.1 Data Types

Log forms might be key-value pairs (key=Value), JSON, CSV, relational databases, or any other format. Secondly, we restore the system’s entire running state at that time through logs, with the goal being to solve a certain problem, observe the running mode of a certain module, or even characterize system user behavior patterns. In observable technology, we classify log types into Log types, Metric types, and Trace types.

Log Type

Log is the most primitive data recording method. It generally records what module did what thing at what time, and whether log level is warning or error. The vast majority of systems, whether embedded devices or computers in cars, the log form they use is almost always of this type. This is the simplest, most direct, and also best-implemented method. Almost all Log types are stored through string type. Data presentation format is a single text data line. Log is the most basic type. Therefore, through transformation, Log type can be converted to Metric or Trace types. Of course, the cost is the transformation process. When data volume is very large, this might become a bottleneck.

To identify different log type levels, error, warning, and debug levels are commonly used to categorize log levels. Obviously, error-type is the primary log level you need to focus on. However, in practice, people won’t strictly categorize according to this method. This might be related to their engineering development environments not doing good categorized analysis on different log levels. In summary, you can categorize Log types by level based on your purpose. It’s like an index, which can further improve the efficiency of analyzing problems and locating target information.

Metric Type

Metric type is more focused in purpose compared to Log type. It records the numerical changes of a certain dimension. The knowledge point is “dimension” vs. “numerical value.” A dimension might be CPU usage rate, CPU Cluster scheduling frequency, or context switch count. Numerical value changes can be instantaneous values at sampling time (becoming snapshot-type), or difference from previous sampling (increment or decrement), or statistical aggregated values over a certain time period. In practice, aggregated values are often used, for example, if I want to see the average CPU usage in the 5 minutes before a problem occurred. At this time, I need to calculate a simple average or weighted average of all values within these five minutes (for example, samples closer to the occurrence point get higher weight). Log type can of course achieve Metric type effects, but the operation is quite troublesome and its performance loss might not be small.

Aggregation is a very useful tool because it’s impossible for humans to analyze all Metric values one by one. Therefore, using aggregation to determine whether there’s a problem before conducting detailed analysis is a more cost-effective method.

Another benefit of Metric type is that its content format is relatively fixed, so it can use pre-encoding for data storage. Space utilization is more compact, and thus disk space occupied is also less. The simplest application is storing in data format. If you use Log type, it’s generally ASCII encoding. While Metric type uses integers or floating point and other fixed byte array data. When storing larger numerical values, obviously ASCII encoding requires more byte count than numerical-type data. And during data processing, you can directly use Metric data without needing to convert Log’s ASCII to numerical format before conversion.

Besides specific numerical values, it can also store enumeration values (essentially, their essence is also numerical). Different enumeration values represent different meanings. It could be on and off, or different event types.

Trace Type

Trace type identifies the time, name, and duration of event occurrences. Multiple events identify whether it’s parent-child or sibling relationships through relationships. When analyzing complex calling relationships between multiple threads, Trace type is the most convenient data analysis method.

Trace type is particularly suitable for Android application and system-level analysis scenarios because it can diagnose:

Function call chains
Binder invocation chains
Cross-process event flow tracking

In the design of Android application runtime environments, an application cannot complete all functions independently. It needs to interact extensively with SystemServer to complete many of its functions. Communication with SystemServer is completed through Binder. Its communication method will be introduced in detail in later articles. For now, you just need to know that its communication relationship is cross-process calls. This requires combining client-side and server-side data to accurately restore the calling relationship. Trace type is the best way to complete this kind of information recording.

Trace type can be added with manually set start and end points. Within one function, you can add multiple such intervals. Through pre-compilation technology or programming language features, you can automatically insert Trace intervals at function’s header and end. Ideally, the latter is the best solution because you can know which functions in the system are which, their execution situations, and what the calling relationships are. You can use this information to count which functions have the most call counts (hottest points), and which functions are the most time-consuming. It’s imaginable that this approach brings huge performance loss because the frequency and magnitude of function calls are very large. The more complex the system magnitude, the larger it is.

Therefore, there’s a workaround method: that’s using sampling to obtain call stack to approximately fit the above effect. The shorter the sampling interval, the better it can fit the real calling relationships and duration. But the interval also shouldn’t be too small because the operation of taking stack itself becomes very high because the number of times increases. This method is called Profiler in the industry. The vast majority of profilers for programming languages you’ve seen are implemented based on this principle.

1.2 Data Acquisition Methods

Static Instrumentation and Dynamic Tracing

Static code acquisition methods are the most primitive approach. The advantage is simple implementation, but the disadvantage is that you need to recompile and install programs every time you add new content. When you encounter a problem later, if the information you want to see happens to not have been logged in advance, there’s no way to further locate problems. You can only start over the entire process again.

A more progressive approach is to pre-add data acquisition points at all possible places you might need, and choose whether to output through dynamic judgment of switches. This can both control performance impact and be able to dynamically turn on logs when needed. However, the cost of this method is very high.

Dynamic tracing technology has actually always existed, but its learning cost is relatively high. It’s hailed as the dragon-slaying sword in the debugging field. It requires you to understand relatively deep technical knowledge, especially compilation, ELF format, kernels, and being familiar with predefined probes and dynamic language-対応 programming languages in code. To you, if you’re wrong, this kind of technology even has its own set of programming languages for “dynamic” implementation developer requirements. This approach combines performance and flexibility. You can even dynamically view the information you want when encountering exceptions in online versions. It兼具 performance and flexibility, and you can even see what’s happening in your code in a very short time after exceptions occur. It’s very powerful for online troubleshooting and problem reproduction.

Unconditional and Conditional Capture

Unconditional capture is relatively easy to understand. After triggering capture, no matter what happens, it will continuously capture data. The disadvantage is that when the data volume generated by observed object is very large, it might cause relatively large impact on the system. In such cases, you can only mitigate by reducing the data volume. You need to achieve meeting requirements while performance loss isn’t too large.

Conditional capture is often used for scenarios where identifiable anomalies can be detected. For example, when a certain observed value of the system exceeds a preset threshold, at this point, capture is triggered and continues for a period or reaches another threshold before ending capture. This is slightly more progressive than the previous method because it only impacts the system when problems occur, and has no impact points at other times. But it requires you to be able to identify anomalies, and such anomalies shouldn’t require pre-occurrence historical data. Of course, you can make it easier to reach trigger points by lowering the threshold, which can increase the probability of triggering data capture. At this time, you’ll encounter the same problems encountered by unconditional capture above, requiring you to balance performance loss.

Dumping Strategy

Continuous dumping is storing all data generated during the entire data capture process. The cost is storage pressure. If you can identify the trigger point, for example, being able to detect anomalies, you can then choose to dump selectively. To ensure historical data’s effectiveness, you therefore first temporarily store logs to a RingBuffer, and only proceed to persistent storage after accepting a dump command. This approach balances performance and storage pressure, but the cost is runtime memory loss and trigger’s accuracy.

From the above discussion, you can know that from the most primitive to the most progressive, there are different advantages and costs. As your program gets more mature, you first need to have probes. Fortunately, in Linux kernels and other frameworks, corresponding probe points are already laid out. But in the Android application layer, there aren’t ready-made ones. So currently, dynamic frameworks available on Android, such as eBPF-based frameworks, are all used by kernel developers. Therefore, you can use dynamic frameworks such as eBPF on Android apps. Only professional and full-time performance analysis personnel might use such tools. It has two key points: probes and dynamic language. During program execution, corresponding probe points need to hand over program execution permissions to dynamic tracing frameworks. Framework execution logic is what developers write using dynamic languages.

So your program should first have probes. Fortunately, Linux kernel and other frameworks have laid out corresponding probe points. But in the Android application layer, there aren’t ready-made ones. So currently, frameworks you can use on Android, such as eBPF frameworks, are all used by kernel developers. Therefore, you can use dynamic frameworks on Android apps, but only professional and full-time performance analysis personnel might use this category of tools. It has two key points: probes and dynamic language. During program execution, corresponding probe points need to hand over program execution permissions to dynamic tracing frameworks. Framework execution logic is what developers write using dynamic languages.

1.3 Analysis Methods

Data Visualization Analysis

With increasing complexity of problem analysis, there’s a need to address performance issues involving multiple module interactions. In the industry, data visualization analysis methods have emerged that take time as the horizontal axis and put corresponding events in their respective lanes. This can conveniently see when events of concern occur, interaction information with other systems, etc. In Android, we commonly use Systrace/Perfetto, as well as earlier KernelShark and other tools—essentially all are tools of this category. The “Trace type” mentioned in “Data Types” often employs this visualization analysis method.

Systrace’s visualization framework is built based on Catapult, a sub-project of Chrome. Trace Event Format describes the data formats supported by Catapult. If you have Trace-type data, you can use this framework to display visualized data. AOSP compilation system, Android application compilation process, also has corresponding Trace file outputs. They all implemented visualization effects based on Catapult.

Database Analysis

When facing massive data analysis needs, by formatting data and converting them into two-dimensional tables, using SQL language can achieve efficient query operations. In the server field, ELK and similar technology stacks can achieve more flexible formatted search and statistical functions. With the help of databases and Python, you can even implement an automated data diagnosis toolchain.

From the above discussion, we can know that from text analysis to database analysis, the analysis purposes they face are different. Text analysis is sufficient for just looking at a module’s time consumption with log analysis. For interactions between multiple systems, we need to use visualization tools. For complex database analysis, we need to use SQL tools. Regardless of which analysis method, they’re all essentially data analysis. In practice, we frequently use other tools to transform data to support different analysis methods, for example, converting from text analysis to database analysis.

Choose the appropriate analysis method according to your purpose, and it will make your work twice as effective.

For Android developers, Google has provided several very important performance analysis tools to help system and application developers optimize their programs.

2 Google-Provided Android Performance Analysis Tools

Based on practical experience, the most commonly used tools are Systrace, Perfetto, and Profiler tools in Android Studio. After positioning main bottlenecks through them, you only need to use other domain-related tools. Therefore, we’ll focus on introduction of these three tools’ application scenarios, their advantages, and basic usage methods. For lateral comparison between tools, please refer to the “Comprehensive Comparison” section content in the next chapter.

2.1 First-Generation System Performance Analysis Tool — Systrace

Systrace is a Trace-type visualized analysis tool, a first-generation system-level performance analysis tool. All features supported by Trace type are supported by it. Before Perfetto appeared, it was basically the only performance analysis tool. It displays Android system and app’s running information in a graphical way. Compared to logs, Systrace’s image-based presentation is more intuitive. Compared to TraceView, its performance overhead when capturing Systrace is basically negligible, minimizing the impact on observers to the greatest extent.

Systrace’s Design Philosophy

At critical system operations (such as Touch operations, Power button presses, swipe operations, etc.), system mechanisms (input distribution, View hierarchy, inter-process communication, process management mechanisms, etc.), and hardware/software information (CPU frequency information, CPU scheduler information, disk information, memory information, etc.), we insert log-like information at key processes, which we call TracePoint (essentially ftrace information), and use these TracePoints to display execution time of a core operation process, certain variable values, etc. The Android system then collects these TracePoints scattered in various processes, writes them to a file. After exporting this file, Systrace parses these TracePoints’ information to obtain the entire system’s running information over a period.

In the Android system, some important modules have already inserted some TracePoints by default, classified through TraceTags. The information sources are as follows:

Framework Java layer’s TracePoints are completed through the android.os.Trace class
Framework Native layer’s TracePoints are completed through the ATrace class
App developers can customize TracePoints through the android.os.Trace class

In this way, Systrace can collect and centrally display all information of the Android upper layer, turning the entire Android system’s running state from a black box to a white box for Android developers and system developers. Global and visualization make Systrace the first choice for Android developers and system developers when analyzing complex performance problems.

Practical Application Scenarios

The parsed Systrace, having massive system information, is naturally suitable for analyzing Android App and Android system performance problems. Android’s app developers, system developers, and kernel developers can all use Systrace to analyze performance problems.

From a technical perspective, Systrace can cover the response speed, stuttering and dropped frames, and ANR these major categories.

From a user perspective, Systrace can analyze user-encountered performance problems, including but not limited to:

Application startup speed issues, including cold startup, hot startup, warm startup
Screen transition speed slow, screen-to-screen animation stuttering
Other non-transition click operations slow (toggles, popups, long presses, selections, etc.)
Screen lock/unlock speed slow, phone unlock slow
Face recognition slow
List scrolling stuttering
Screen animation stuttering
Screen loading stuttering
Overall stuttering
App click unresponsive, stuck, crashes

After encountering the above problems, you can use various methods to capture Systrace, open the parsed file in Chrome for analysis.

2.2 New-Generation Performance Analysis Tool Stack — Perfetto

Google made its first commit in 2017, and in the subsequent 4 years (up to December 2021), there were over 100 developers submitting nearly 3.7W commits, almost with PR and Merge operations every day, which is a quite active project. Besides powerful functionality, its ambition is also very large. Officially, it claims to be the next-generation cross-platform Trace/Metric data capture and analysis tool. Application is quite widespread. Besides Perfetto website, Windows Performance Tool and Android Studio, as well as Huawei’s GraphicProfiler also support Perfetto data’s visualization and analysis. We believe Google will continue investing resources into the Perfetto project, so it should be the next-generation performance analysis tool and will completely replace Systrace.

Highlighted Features

The biggest improvement of Perfetto compared to Systrace is support for long-duration data capture. This is thanks to having a service that can run in the background, implementing protobuf encoding and storage for incoming data. In terms of data sources, core principle is consistent with Systrace, also based on Linux kernel’s ftrace mechanism implementing user-space and kernel-space key event recording (ATRACE, CPU scheduler, etc.). All features supported by Systrace are also supported by Perfetto. That’s why it’s said Systrace will ultimately be replaced by Perfetto.

Perfetto supports the data types, acquisition methods, and analysis methods provided by it—unprecedentedly comprehensive. It almost supports all types and methods. In terms of data types, it implements Trace-type support through ATRACE, implements Metric-type support through a configurable node reading mechanism, and implements Log-type support through obtaining logcat data in UserDebug builds.

You can manually trigger capture and end through the perfetto.dev website, command-line tools, or even dynamically trigger capture through Developer Options in settings. It basically covers all scenarios you can encounter on your projects.

In terms of data analysis, Perfetto provides data visualization analysis webpages similar to Systrace operations, but the underlying implementation mechanism is completely different. The biggest benefit is it can support rendering of super-large files (exceeding 300M), which is what Systrace can’t do (it might crash when over 300M, or become very sluggish). In this visualization webpage, you can see various secondary processing data, can execute SQL queries, and even see logcat contents. Perfetto trace files can be converted into SQLite-based database files, which can both be executed on-site by writing SQL or execute pre-written SQL files. You can even import them into Jupyter and other data science tool stacks, sharing your analysis ideas with other partners.

For example, if you want to calculate the total CPU time consumption of SurfaceFlinger thread, or which threads are running in the kernel, etc., you can collaborate with domain experts to translate their experience into SQL commands. If this still doesn’t meet your needs, Perfetto also provides Python APIs to export data in nearly DataFrame format, almost achieving any data analysis effect you want.

This entire suite of developer-mineable points is quite extensive. From my team’s practical experience, it can cover function development, function testing, CI/CD, online monitoring, and expert system aspects and more. The subsequent articles in this star series will also focus on Perfetto’s powerful features and expert systems developed based on it, helping you “one-click answer” performance bottlenecks.

Practical Application Scenarios

The first tool used in performance analysis should be Perfetto, and scenarios using Systrace are becoming fewer. Therefore, the tool you should primarily master should be Perfetto, learn its usage and the indicators it provides.

However, Perfetto also has some limitations. First, although it provides relatively high flexibility, it’s essentially still a static data collector, not a dynamic tracing tool. There’s still a fundamental difference from eBPF. Secondly, runtime cost is relatively high because it involves converting Ftrace data to Perfetto data on the phone. Finally, it doesn’t provide text analysis methods, can only conduct additional analysis through webpage visualization or operating SQLite. In summary, Perfetto is functionally powerful, covering almost all aspects of observable technology, but the usage barrier is also relatively high. There are quite a few knowledge points worth digging and learning. Our subsequent articles will also focus on Perfetto’s powerful features and what can be developed based on it.

2.3 Android Studio Profiler Tools

Android’s application development integration environment (officially recommended) is Android Studio (previously Eclipse, but it’s been淘汰). It naturally also needs to integrate development and performance tuning together. Very fortunately, with the iteration and evolution of Android Studio, it now has its own performance analysis tool Android Profiler, which is a collection integrating multiple performance analysis tools into one, letting developers complete performance tuning work within Android Studio without needing to download other tools.

Currently, Android Studio Profiler has integrated 4 types of performance analysis tools: CPU, Memory, Network, Battery, of which CPU-related performance analysis tools are CPU Profiler, also the protagonist of this chapter. It integrates all CPU-related performance analysis tools together, and developers can choose which one to use based on their needs. Many people probably know that Google has already developed some independent CPU performance analysis tools, such as Perfetto, Simpleperf, Java Method Trace, etc. Now there’s another CPU Profiler, it’s obviously impossible to reinvent the wheel. CPU Profiler’s current approach is: obtain data from these known tools, then parse the data into the style you want, and display it through a unified interface.

Highlighted Features

CPU Profiler integrates performance analysis tools: Perfetto, Simpleperf, Java Method Trace, naturally possessing all or some of these tools’ functions, as follows:

System Trace Recording, which uses Perfetto-captured information and can be used to analyze process function duration, scheduling, rendering, etc., but it’s a streamlined version, can only display process-related information and filters out short-duration events. It’s recommended to export Trace to file and analyze it on https://ui.perfetto.dev/.
Java Method Trace Recording, which obtains function call stack information from the virtual machine for analyzing Java function calls and duration.
C/C++ Function Trace, which uses Simpleperf-captured information. Simpleperf is a CPU performance monitoring component of the PMU hardware module obtaining data. C/C++ Function Trace only has partial features of Simpleperf, used for analyzing C/C++ function calls and duration.

Practical Application Scenarios

Application performance problems are mainly divided into two categories: slow response and non-smooth.

Slow response problems often include: slow application startup, slow page transitions, slow list loading, slow button response, etc.
Non-smooth problems often include: non-smooth list scrolling, non-following finger swipes, animation stuttering, etc.

How should CPU Profiler be used in these scenarios? The basic approach is: first capture a System Trace, analyze with System Trace first, position the problem. If you can’t position the problem, then further analyze using Java Method Trace or C/C++ Function Trace.

Take a very poor performance application as an example, we inserted a Systrace TracePoint at a key location in the system. If you’re not familiar with the code, how do you find the performance bottleneck? First, let’s run the application, record a System Trace through CPU Profiler (later articles will introduce tool usage methods), as follows:

From the above Trace, you can know that it’s the onDrawFrame operation in the egl_core thread that’s time-consuming. If you don’t find a problem, it’s recommended to export to https://ui.perfetto.dev/ for further analysis. You can look up source code to see what onDrawFrame is. We found through searching that onDrawFrame is a Java function’s onDrawFrame, and we need to analyze Java function time consumption. we need to record a Java Method Trace, as follows:

Through the above Trace, it’s easy to discover it’s a native function called Utils.onDraw that’s time-consuming. Since it involves C/C++ code, we need to record a C/C++ Function Trace to further analyze, as follows:

You can discover now that the native function’s java_com_gl_shader_Utils_onDraw executes sleep, which is the culprit causing performance low!

The biggest advantage of CPU Profiler in AS is integrating various sub-tools. In one place, you can operate everything, which is very convenient for application developers. However, it might not be that lucky for system developers.

2.4 Comprehensive Comparison

Tool Name	Application Scenarios	Data Type	Acquisition Method	Analysis Method
Systrace	Android system and app performance analysis	Trace type	Unconditional capture continuous dumping	Visualized analysis
Perfetto	Android system and app performance analysis	Metric type Trace type	Unconditional capture continuous dumping	Visualized analysis Database analysis
AS Profiler	Android system and app performance analysis	Trace type	Unconditional capture continuous dumping	Visualized analysis
SimplePerf	Java/C++ function execution duration analysis PMU counters	Trace type	Unconditional capture continuous dumping	Visualized analysis Text analysis
Snapdragon Profiler Tools & Resources	Mainly Qualcomm GPU performance analyzer	Trace type Metric type	Unconditional capture continuous dumping	Visualized analysis
Mali Graphics Debugger	ARM GPU analyzer (MediaTek, Kirin chips)	Trace type Metric type	Unconditional capture continuous dumping	Visualized analysis
Android Log/dumpsys	Comprehensive analysis	Log type	Conditional capture Continuous capture without dumping	Text analysis
AGI(Android GPU Inspector)	Android GPU analyzer	Trace type Metric type	Unconditional capture continuous dumping	Visualized analysis
eBPF	Linux kernel behavior dynamic tracking	Metric type	Dynamic tracing with conditional capture continuous capture without dumping	Text analysis
Ftrace	Linux kernel instrumentation	Log type	Static code with conditional capture continuous capture without dumping	Text analysis

3 About “Techniques, Methods, and Tools”

Technical changes and improvements are more embodied at the “Tool” level. The development trajectory of Linux communities and Google’s tools development direction is moving toward improving tool integration, making it convenient to find needed information in one place, or toward obtaining more information. In summary, their development trajectory is traceable and development patterns can be summarized. We need to accurately recognize their capabilities and application scenarios during rapid tool iteration. Their purpose is to improve problem-solving efficiency, not to spend time learning new tools.

The “Methods” level depends on specific business knowledge. Knowing how a frame is rendered, how CPU chooses process scheduling, how IO is dispatched, etc. Only by understanding business knowledge can you correctly choose tools and correctly interpret information provided by tools. As experience enriches, sometimes you don’t even need to see detailed information provided by tools, and you can find clues. This is a kind of ability that forms complex associative information in your brain after your business knowledge becomes rich to a certain extent. Then you navigate above tools—a capability formed when your business knowledge is rich to a certain level.

The “Tao” (Way) level considers what problem to solve, what’s the essence of the problem? What degree to achieve and what cost to invest to achieve what effect. To solve a problem, what path has the highest “input-output ratio”? What’s the overall strategy? To complete one thing, what do you do first, what do you do next, and what’s the dependency logic between front and back?

In subsequent articles, we will explain a technique, a feature according to the “Techniques, Methods, and Tools” approach. We don’t just want you to learn a knowledge point, but more want to spark your ability to think comprehensively by three aspects. When encountering similar tools or similar problems, even if they’re completely different systems, you can cope calmly. Firmly grasp the essence, evaluate the “input-output ratio” to choose appropriate tools or information, efficiently solve problems.

4 About “The Performance Knowledge Planet”

To better communicate and output high-quality articles, we created a knowledge planet named “The Performance”, mainly maintained by three first-tier developers from domestic phone manufacturers in the performance optimization field, with many years of work experience in performance-related domains. It provides Android performance-related one-stop knowledge services, covering basics, methodology, tool usage, and most valuable case analyses.

Currently, the planet’s content planning is as follows (## between different sections are tags, and related topics will all have corresponding tags, making it convenient for everyone to click interested tags to view corresponding knowledge)

#ThePerformance# — You can read ahead the electronic book “Android Performance Optimization - Systematic Course” which will be releasing written chapters every week. “Android Performance Optimization - Systematic Course” is an Android performance optimization electronic book we’re planning. Currently, there are quite a few high-quality performance optimization theoretical knowledge articles and practice articles and open source libraries in the developer community, but currently there’s a lack of a complete, systematic book covering performance optimization principles, tools, and practices, oriented toward beginner and intermediate developers, app developers and system developers, and continuously updated. The book’s outline (tentative) is basically ready, and it’s expected to take about a year to complete. In the planet, written chapters will be released, letting everyone see them in advance.
Part 1: → Performance Engineering
Part 2: → Analyzing Android Interaction and Core Systems from a Performance Perspective
Part 3: → Analyzing Linux Kernel Core Subsystem Design and Implementation
Part 4: → Problem Scenario Analysis Approach
Part 5: → Analysis and Debugging Tools
Part 6: → Quality Guardianship — Performance Monitoring Methods and Tools
#PerformanceTools# — Sharing performance analysis tools used in Android development and their usage methods, also providing 1v1 video guidance for Systrace, Perfetto, and other performance tools. Tool usage is better demonstrated through video—it’s more intuitive. Articles are static and many places are hard to explain clearly. 1v1 video conference guidance is also a learning method.
#CaseAnalysis# — Classic case analysis approach summaries, planet friend-provided case analyses and discussions. Case analysis is a very important learning approach. Reading many actual performance cases is very helpful for your own analysis and performance problem solving later. At the same time, everyone is welcome to provide cases and solutions. If you’re worried about leaking information, we’ll mask key information.
#ClassicReinterpretation# — Classic solutions, course re-readings. For example, in-depth analysis of third-party library analysis, Android expert masterclass re-readings, etc. We can conduct in-depth analysis of solutions, lateral comparisons, etc.; for Android expert masterclass re-readings and leak fixing.
#KnowledgeShare# — Excellent articles, blogs, tool sharing. There are many excellent blogs in the industry, source solutions that have stood actual business tests, various performance tools, etc. We’ll look for these excellent contents and share them with everyone.
#KnowledgeDeposition# — WeChat group chat精华, WeChat Q&A, blog comment answers, etc.
#PerformanceInterview# — Collection and answers to Android performance-related interview questions. It’s considered a necessity, right?
#ProgrammingLanguage# — Programming language usage technique sharing.
#EfficiencyImprovement# — Efficiency improvement sharing, including developer efficiency, work efficiency improvement methods, engineering efficiency, tool recommendations, etc. Not misusing a sword to chop firewood.
#IndustryDynamics# — First-time interpretation reports of new performance-related technologies, including but not limited to the following content:
- Industry summits, academic summit new concept interpretation reports
- Papers, industry, books, video introductions
- Android large version performance-related content introduction
- Android new hardware performance-related content introduction
- Android performance-related open source project interpretations
#BigNameSharing# — Monthly invitations to industry experts for experience sharing, case analyses

Note: iOS phone users should not directly pay in the planet. Long-press the image in WeChat interface to join via QR code scan. Otherwise, Apple will charge expensive subscription fees.

5 Appendix

Perfetto Project Address
- Official usage documentation: https://perfetto.dev/docs/
- Github code library: https://github.com/google/perfetto, where you can report bugs or feature requests, and of course can submit PR contributions to contribute your strength.
Android GPU Inspector
- Official usage documentation: https://developer.android.com/agi
Other Major Manufacturers’ Performance Analysis Tools
- Windows Performance Toolkit

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with colleagues in the same field. When three walk together, there must be my teacher!

Blogger Personal Introduction: Inside are personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Personally Organized and Collected Excellent Blog Articles - Essential Skills and Tools for Android Performance Optimization: Everyone is welcome to self-recommend and recommend (private WeChat chat is fine).
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

“An individual can move faster, a group can go further.”

2021 Year in Review: Baby, Career, and Growth

2022-01-03T15:25:35.000Z

2021 has passed. Taking advantage of the New Year holiday, I’d like to look back at the year. This will be a casual review—writing whatever comes to mind. 2021 for me was marked by becoming a father, changing jobs (including a boring period of working from home), and making new friends. Overall, it was a pretty good year.

However, in terms of personal growth, I feel like I might have stagnated or even regressed, which is a bit alarming. Learning is like rowing upstream; if you don’t move forward, you fall back. 2022 needs to be a year of deep cultivation. I hope to progress together with everyone reading this.

I’ve also tallied some data related to my technical sharing, shared my income from these platforms, and listed some hardware and software I recommend. Feel free to take a look.

2021’s Greatest Achievement: “Little Orange”

The highlight of my year was definitely the addition of “Little Orange” to our family. Experiencing fatherhood has been incredible—our duo became a trio. She’s almost ten months old now and is an absolute angel. We don’t ask for much; just that she grows up healthy and happy. Mom and Dad will always be your strongest support.

Blog Data

I added 8 new articles to the blog in 2021. The Systrace series is finally complete with 18 articles total! (Go ahead and read those while I prepare the Perfetto version…)

Writing only 8 articles is a far cry from my initial goal of one per week. That was a bit ridiculous in hindsight. I won’t set such a high bar for 2022—perhaps two per month is more realistic.

I also maintained an Android Weekly column on Zhihu. Feel free to subscribe: https://www.zhihu.com/column/c_1278963991947780096

The blog AndroidPerformance uses Google Analytics. Comparing 2021 to 2020, the numbers are looking good:

Active Users grew by 38.9% compared to 2020. (The obvious dips are the New Year, May Day, and National Day holidays—good to see people aren’t “grinding” during breaks!)

Most Visited Pages are still primarily from the Android Systrace series.

WeChat Official Account Data

Followers for the AndroidPerformance account currently stand at 7,364. Since I don’t post many original articles and have many reposts, growth is slow. Most active users are long-time followers. Data for individual posts doesn’t mean much in the closed WeChat environment, so I won’t list it. I hope to break 10,000 in 2022.

Writing on WeChat is convenient for readers but unfriendly for creators—mostly because you can’t include external links. It feels like turning the internet into a local area network.

Zhihu

I have over 20,000 followers on Zhihu, but the platform seems to care less about technical content these days, so I haven’t been very active. Most articles I see are just reposts. I find myself spending more time on Jike and Twitter, where real developer activity is higher.

Juejin

Juejin still has a strong technical atmosphere. I browse it often, although it feels like it’s missing “something.” I’ll continue syncing my articles there, otherwise, others will just do it for me (and change the author!).

Jike

Fellow “Jiyou” (Jike users) can add me:

Other Platforms

CSDN: …can be ignored.
Weibo: …can be ignored.
Twitter: I follow many domestic and international tech gurus. The technical vibe is quite good.

Making Money? Just Making Friends

I listened to Happy Xiao’s podcast recently, where he shared that his technical sharing earned him about 2,500 RMB a month. Looking at my own 2021 income in this area… it’s quite humble.

Blog Income: 0. Actually negative, if you count domain and server costs.
WeChat Account: I don’t use mid-article ads, so ad revenue is negligible. It’s mostly donations from readers, which totaled 1,039 RMB.
Patreon/Columns: Totaled 560 RMB.

So, total income was 1,039 + 560 = 1,596 RMB. That’s an average of 133 RMB per month. Clearly not a gold mine! As the saying goes, “just making friends.” But I truly appreciate the donations—they pay for the extra egg in my breakfast! (If you’d like to support, you can scan the code at the end of any of my original articles.)

Speaking of friends, I did add many new tech peers this year. We started four WeChat groups. My general feeling there is: “Everyone’s a master except me.” It makes me realize how much I still need to learn. My goal for 2022 is to solidify my foundations and systematize my knowledge to keep up with their discussions.

If you find my content helpful, you can “buy me a chicken leg” below:

2022 Plans

New Year goals are a cliché, but here they are anyway. Hopefully, I can break them down into weekly actions:

Fitness: Walking to work, basketball, running, rowing machine, and home gym equipment (holding “Little Orange” counts too!).
Improve English Reading/Listening: Listening to English podcasts, watching tech videos, and reading English books/articles. Using iPad split-screen with Youdao Dictionary is a great workflow.
Systematize Knowledge: Read and write more code, read more books, and write a performance-related ebook.
Update the Blog More Frequently: Goal set above.
Grow [The Performance Knowledge Planet] with the team: One person is too small. We’ve started a paid community with a small team to provide better service and put some “pressure” on ourselves.
Try New Content: Podcasts, video, Vlogs, photography.
Efficient Work: More thinking, summarizing, and sharing. Use tools to boost productivity.

2021 Software Recommendations

The software that brought me the most joy in 2021:

Notion: For notes and planning. https://www.notion.so/
Typora: The tool I used to write this very blog. https://typora.io/
GitHub Copilot: Your AI coding companion. https://copilot.github.com/
flomo: For recording fleeting thoughts. https://flomoapp.com/
DeepL: The world’s most accurate translator. https://www.deepl.com/

2021 Hardware Recommendations

Hardware I’ve tinkered with and highly recommend:

NAS (Personal Cloud): Essential for data management.
Electrostatic Capacity Keyboard: A godsend for programmers and writers.
Xiaomi 27-inch 4K Monitor: Great value for the price.
Apple TV 4K: If you have a NAS, 4K TV, and the right network setup, the experience is unbeatable.
JOY25 Electric Standing Desk: 1.8m width is amazing. Switching between sitting and standing is a health game-changer.

What Do I Want Most in 2022?

I feel my M1 Mac Mini is already starting to feel slow compared to the M1 Max MacBook Pro… Cook must be practicing remote magic.

Regardless of “wants,” I need to be a rational consumer!

Also, this chair looks amazing! (https://item.taobao.com/item.htm?id=614505490996)

And of course, who would say no to the latest iPhone 13 Pro Max?

Conclusion

2021 was a bit underwhelming professionally, but family life with “Little Orange” brought a lot of joy. Personal growth felt stagnant, which comes down to my own lack of self-discipline.

I hope 2022 can be a year of breakthrough for me and everyone reading this. Let’s work hard together!

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

What Should Be in a Book About Android Smoothness?

2021-10-27T07:21:31.000Z

Recently, I read a new book: Building Smooth Android Apps (JD link: https://item.jd.com/10035215362170.html). I bought it because of the title, and after reading it, I felt it was necessary to write an article so that colleagues who haven’t bought it yet can understand what it’s about.

My personal suggestion is: if you are an experienced developer, I don’t recommend buying it. This book doesn’t go into much depth on principles and doesn’t offer a comprehensive overview of Android smoothness. If you are a beginner, it’s decent for broadening your horizons and identifying gaps in your knowledge, but it’s still a bit lacking for a deep understanding of Android smoothness.

I say this because the book doesn’t focus much on performance or smoothness. It lacks deep theoretical parts. Instead, a large portion is dedicated to static code analysis, using Android Studio Profiler, App architecture, app stay-alive techniques, network performance optimization, APK size optimization, app power consumption, etc. These topics are covered briefly and at a shallow level.

Content Overview

Here is a brief introduction to the book’s content and chapters:

Overview: Briefly introduces why performance optimization is needed and how to configure Android Studio.
Static Code Analysis: Covers various static analysis tools in detail, such as Android Lint, CheckStyle, SpotBugs, PMD, etc. Except for Lint, I hadn’t used the others much, so this was a good refresher.
Performance Optimization with Android Profiler: Focuses on the CPU, Memory, and Network Profilers within the AS Profiler tool. The emphasis is on tool usage, with high-level introductions.
High-Quality Apps Start with Architecture: Discusses architectural principles like MVC, MVP, and MVVM.
Elegant App Stay-Alive Techniques: A brief introduction to techniques for keeping apps running in the background.
Network Performance Optimization: Covers network interaction, multi-threading, and large-scale data transfer optimization.
Optimizing APK Size: The usual topics: multi-channel packaging, resource optimization, and code obfuscation.
App Power Consumption and Crash Experience Optimization: A brief overview of these areas.

As you can see from the chapter titles, there is relatively little content specifically about “smoothness.” The topics are quite diverse. If you’re interested, you can buy a copy to take a look.

What Do I Think a Book on Smoothness Should Contain?

While I couldn’t write such a book myself—I have great respect for technical authors—I can certainly offer my “armchair” opinions. If I were to write this book, I would include the following content to ensure readers gain a deep understanding of Android smoothness principles and become proficient in using various tools to analyze issues.

In Android performance discussions, Jank (Smoothness), Responsiveness, and ANR are usually grouped together because their causes are similar. They are essentially categorized by severity: jank, slow response, and ANR. We can define Smoothness in a broad sense as encompassing all three. Most user complaints about “lag” or “stuttering” refer to this broad definition.

Here is my proposed chapter structure:

Chapter 1: Overview of Android Smoothness: Concepts from the perspectives of users, developers, testers, AOSP, and hardware. It’s important not to limit your thinking to just one role.
Chapter 2: Overview of Android Runtime Mechanisms: Essential knowledge for analyzing smoothness. Once you master these, you’ll have a mental model of how user actions trigger system feedback and where potential bottlenecks lie:
- App Main Thread Principles (Main Thread vs. Render Thread)
- Message, Handler, MessageQueue, and Looper mechanisms
- Screen Refresh Mechanism and Vsync
- Choreographer mechanism
- Buffer and SurfaceFlinger workflows
- Input handling flow
- Design philosophy of ANRs
Chapter 3: Performance Analysis Tools: A craftsman is only as good as his tools. This chapter would go beyond simple introductions, explaining regular performance analysis tools in the context of system mechanisms: Systrace (Perfetto), AS Profiler, SimplePerf, MAT, Log tools (analysis and principles), Command-line tools (dumpsys for meminfo, gfxinfo, cpuinfo, SurfaceFlinger, activity, input, window, etc.), and Third-party libraries (Koom, Matrix, Profilo, BlockCanary, LeakCanary, Tailor/Raphael, etc.).
Chapter 4: Deep Dive into Android Jank: Practical strategies for identifying causes, workflows for analysis, case studies, and coding best practices.
Chapter 5: Deep Dive into Android Responsiveness: Similar to the above, but focused on responsiveness issues.
Chapter 6: Deep Dive into Android ANR: Understanding the design, types, causes, and analysis workflows for ANRs, along with case studies and best practices. (Likely a very detailed chapter).
Chapter 7: Deep Dive into Android Memory Issues: Memory is a critical performance metric. This chapter would cover app memory footprint, analysis tools, memory leaks, and continuous growth analysis.
Chapter 8: Performance Testing: Smoothness from a testing perspective: retrieving metrics (intrusive vs. non-intrusive), setting standards, competitor analysis, bug reporting flows, full-device testing, third-party standards (Master Lu, Umeng, Bugly, etc.), and tool development (Matrix, Koom, Fastbot, etc.). Also covers soft skills: distinguishing between system and app issues and communicating with PMs and devs.
Chapter 9: Online Performance Monitoring: Unlike offline testing, online monitoring must reflect real user experience with minimal impact while ensuring timely data reporting.
Chapter 10: Introduction to System Performance Optimization: How do Android system developers (AOSP, Qualcomm, MTK, OEMs) optimize performance?
Chapter 11: High-Efficiency Work Guide:
- Necessity and process of compiling AOSP code.
- Tips for reading AOSP code (cs.android.com, importing into AS/VS Code, flowcharts).
- Recommended dev environments (Windows, Linux, Mac) and command-line configurations.
- Work habits: writing, recording, summarizing, and sharing.

That’s my “armchair” outline. Everything is ready—just waiting for an expert to fill in the content!

What Other Performance Books Are Available?

Many books on the market are a bit dated. However, the Juejin community has a wealth of articles on Android performance, and many large companies open-source their internal tools. Let’s keep moving forward on the shoulders of giants.

Here are a few books I’ve read:

Evaluation and Optimization of Mobile App Performance by Tencent TMQ: Published in 2016, very professional and practical. (Available on WeChat Reading).
Understanding Android: Java Virtual Machine ART by Deng Fanheng: A massive tome on the ART VM, helpful for understanding “black tech” involving the VM. (Available on WeChat Reading).
High-Performance Android Apps by Doug Sillars: Published in 2016, an early comprehensive guide.
Best Practices for Android App Performance Optimization by Tencent developers: Published in 2017. (Available on WeChat Reading).
BPF Performance Tools by Brendan Gregg: Chinese edition published in 2020. A fundamental tool for system performance.
Systems Performance: Enterprise and the Cloud by Brendan Gregg: Chinese edition published in 2020. A must-have for anyone doing performance work. (Available on WeChat Reading).
Android Development Master Class by Zhang Shaowen (Geek Time column): A true master’s perspective.
Linux Performance Optimization by Ni Pengfei.

Final Thoughts

Feel free to share your own recommendations for Android performance books, blogs, videos, or tutorials.
What do you think should be included in a book about Android smoothness?
This article is for sharing only, with no promotional links.
Feedback is welcome on my Zhihu or WeChat accounts.

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android System Development Series (1): Downloading, Compiling, and Flashing Android 12

2021-10-26T03:49:33.000Z

Android 12 has been officially released, and the source code is now available on the AOSP website. This article will guide you through the process of downloading and compiling the latest Android 12 code.

Compiling the code locally offers several advantages:

Direct Debugging: You can flash the build onto a physical device for local debugging and import the code into Android Studio.
Userdebug Builds: You can compile a userdebug version, which allows for root and remount access. This is invaluable for debugging both the system and apps, as it reveals information hidden in standard user builds—useful for competitive analysis and behavioral studies.
Deep Learning: It facilitates a deeper understanding of Android source code by allowing you to enable system-level debug logs, add your own logs, or even modify system workflows.

If you don’t need to compile or debug and just want to browse the code, I recommend using cs.android.com. For those who want to dive deep into the Android system, I suggest the following hardware setup:

A used, unlocked Google Pixel 3 or newer (Android 12 supports Pixel 3 and up).
A Linux desktop (preferably Ubuntu) with a large SSD, at least 32GB of RAM (or equivalent swap space), and a decent CPU to minimize compilation time.

1. Downloading the Code

Due to network restrictions in some regions, downloading directly from Google’s official site can be slow. This tutorial uses a domestic mirror as an example. If you have unrestricted internet access, you can follow the Official Google Tutorial.

USTC AOSP Mirror: https://mirrors.ustc.edu.cn/help/aosp.html

The following steps can be run on Ubuntu, WSL, WSL2, or macOS. However, since the actual compilation requires Linux, I strongly recommend using a Linux system like Ubuntu for the entire process.

1.1 Step 1: Download the Repo Tool

mkdir ~/bin
PATH=~/bin:$PATH
curl -sSL 'https://gerrit-googlesource.proxy.ustclug.org/git-repo/+/master/repo?format=TEXT' | base64 -d > ~/bin/repo
chmod a+x ~/bin/repo

1.2 Step 2: Configure Personal Information

If you haven’t installed Git yet, do so first. then configure your identity:

1 2	git config --global user.name "Your Name" git config --global user.email "you@example.com"

1.3 Step 3: Create a Working Directory

1 2	mkdir Android_12_AOSP cd Android_12_AOSP

1.4 Step 4: Initialize the Repository

There are two ways to initialize: downloading everything (the master branch) or targeting a specific Tag. Note: Your choice here will affect which driver you need to download later.

1.4.1 Option A: Download All (Recommended)

This downloads the entire source tree, defaulting to the master branch. Use this if disk space is not a major concern.

1	repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest

If you encounter connection issues with gerrit.googlesource.com, edit ~/bin/repo or your shell configuration (.bashrc or .zshrc) to set:
REPO_URL="https://gerrit-googlesource.proxy.ustclug.org/git-repo"

1.4.2 Option B: Download a Specific Tag

This is faster as it only downloads code for a single Tag. You can find a list of Build Numbers and Tags here. For example, for my Pixel 3 XL, the relevant Android 12 Tags are android-12.0.0_r3 and android-12.0.0_r1.

1	repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest -b android-12.0.0_r3

1.5 Step 5: Sync the Code

After initialization, download the actual files. It’s recommended to use -j4 to avoid overwhelming mirror connections.

1	repo sync -j4

Since syncing can fail due to network hiccups, you can use a simple loop script:

#!/bin/bash
repo sync -j4
while [ $? -ne 0 ]
do
    echo "====== sync failed, retrying ======"
    sleep 3
    repo sync -j4
done

2. Downloading Drivers (Proprietary Binaries)

Before compiling for a physical device, you must download proprietary driver files. Refer to the Official Documentation.

The driver you need depends on whether you synced the master branch or a specific Tag.

2.1 Drivers for the Master Branch

If you synced from master, download drivers from the AOSP Preview Page.

2.2 Drivers for a Specific Tag

If you used the -b flag with a Tag like android-12.0.0_r3, you must find the driver matching that Tag’s Build ID (e.g., SP1A.210812.016.A1). Download them from the Full Driver Page.

2.3 Extracting Drivers

Extract the downloaded files into your source root. You will get two .sh scripts. Run them, scroll through the license (using D), and type I ACCEPT.

1
2
3

# Example for Pixel 3 XL
./extract-google_devices-crosshatch.sh
./extract-qcom-crosshatch.sh

3. Compiling the Code

Now that the source and drivers are ready, let’s start the build. As a reminder, macOS is no longer supported for building newer Android versions; use Ubuntu.

3.1 Initializing the Build Environment

Run this on Ubuntu 18.04+:

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

3.2 Setting Up the Shell Environment

Every time you open a new terminal, you must run:

1	source build/envsetup.sh

3.3 Selecting a Target

lunch

Select the target corresponding to your device. For Pixel 3 XL, the codename is crosshatch. Choose aosp_crosshatch-userdebug.

3.4 Starting the Build

Use m to build the entire system. It automatically handles parallel tasks, though you can specify them with -jN.

m droid: Standard build.
m all: Builds everything, including modules not marked for the device image.
m clean: Deletes all output and intermediate files (same as rm -rf out/).

Wait for the build to finish. Total time depends on your CPU and RAM (32GB+ is highly recommended). Once completed, you’ll see a success message.

4. Flashing the Device

A local userdebug build is perfect for debugging the Framework or apps. To flash your device (using Pixel 3 XL as an example):

adb reboot fastboot

# Once in fastboot mode
fastboot flashall -w

# After flashing
fastboot reboot

The device will reboot into your custom Android 12 build. Note that the AOSP Launcher is quite basic compared to the official Pixel Launcher because it lacks Google’s proprietary enhancements.

If you encounter issues during flashing, you can always restore your device using Official Google Factory Images.

5. What’s Next?

This guide focused on downloading, compiling, and flashing. I will cover how to import code into an IDE, modify modules, and debug in a follow-up article.

About Me && Blog

Below are my personal details and links. I look forward to connecting and sharing knowledge with fellow developers!

About Me: Includes my WeChat and WeChat group links.
Blog Navigation: A guide to the content on this blog.
Curated Android Performance Articles: A collection of must-read performance optimization articles. Self-nominations/recommendations are welcome!
Android Performance Knowledge Planet: Join our community for more insights.

“If you want to go fast, go alone. If you want to go far, go together.”

Android Systrace Responsiveness in Action 3 - Extended Knowledge on Responsiveness

2021-09-13T02:46:47.000Z

When discussing Android performance, Jank, Responsiveness, and ANR are usually grouped together because their causes are similar. They are simply categorized based on severity: Jank, Slow Response, and ANR. We can define “Broad Jank” to include all three. If a user reports that a phone or App is “stuttering,” they are likely referring to Broad Jank, and we must identify which specific issue is occurring.

If it’s stuttering during animation or list scrolling, we define it as Narrow Jank (referred to as Jank). If it’s slow app startup, slow screen wake-up, or slow scene switching, we define it as Slow Responsiveness (referred to as Slow). If it’s an ANR, it’s an Application Not Responding issue. Each situation requires different analysis and resolution methods.

Furthermore, within Apps or manufacturers, Jank, Responsiveness, and ANR have individual metrics like Frame Drop Rate, Startup Speed, and ANR Rate. Mastering the analysis and optimization of these issues is crucial for developers.

This is the third article in the Responsiveness series, focusing on extended knowledge when using Systrace to analyze app responsiveness, including startup speed testing, log interpretation, state analysis, and third-party startup libraries.

1. Interpretation of the Three Process States in Systrace
2. Using TraceView for Responsiveness Analysis
3. Using SimplePerf for Startup Speed Analysis
4. Locating Other Component Startups in Systrace
5. Can AppStartup Optimize Startup Speed?
6. Using IdleHandler in App Startup Scenarios
Series Articles
References
About Me && Blog

If you are not familiar with the basic use of Systrace (Perfetto), please catch up on the Systrace Basics Series first. This article assumes you are already familiar with using Systrace (Perfetto).

Systrace Series Articles:

1. Interpretation of the Three Process States in Systrace

In Systrace, a process task typically exhibits three states: Sleep, Running, and Runnable. These are color-coded at the top of the task trace:

Green: Running
Blue: Runnable
White: Sleep

1.1 Analyzing the Sleep State

White (Sleep) segments are either active or passive.

Active Sleep (e.g., nativePoll): The app has no more messages to process and is sleeping while waiting for a new Message. This is normal and usually ignored (e.g., segments between frames).
Passive Sleep: Triggered by user code sleep() or Binder communication with other processes. This is common and critical for performance analysis.

As shown below, long sleep periods during startup often correlate with Binder communication. Frequent Binder calls prolong response times.

You can click the binder transaction marker at the bottom of the task to view details:

If Binder info is missing but the task is woken by another thread, check the Wakeup info to find the dependency.

Zooming into the Runnable marker from the previous image:

1.2 Analyzing the Running State

The Running state indicates the task is currently executing on a CPU core. If a Running segment is unexpectedly long, consider:

Increased App logic/complexity.
Core scheduling anomalies (e.g., running on the wrong core).

On some Android devices, UI and Render threads are prioritized for Big Cores when the app is in the foreground.

1.3 Analyzing the Runnable State

A task must transition from Sleep to Runnable before entering the Running state:

Systrace representation:

Normally, a task enters Running almost immediately after becoming Runnable. In a congested system with saturated CPUs, tasks must wait in Runnable for an available core.

If startup shows heavy Runnable segments, check the overall system load.

2. Using TraceView for Responsiveness Analysis

“TraceView” refers to the CPU profiling visualization within the Android Studio Profiler.

2.1 Capturing TraceView During Startup

Use the following command to profile a cold start (replace package/activity names with your own):

adb shell am start -n com.aboback.wanandroidjetpack/.splash.SplashActivity --start-profiler /data/local/tmp/traceview.trace --sampling 1 && sleep 10 && adb shell am profile stop com.aboback.wanandroidjetpack && adb pull /data/local/tmp/traceview.trace .

Or execute steps individually:

# 1. Start App with 1ms sampling
adb shell am start -n com.aboback.wanandroidjetpack/.splash.SplashActivity --start-profiler /data/local/tmp/traceview.trace --sampling 1

# 2. End profiling after full load
adb shell am profile stop com.aboback.wanandroidjetpack

# 3. Pull the trace
adb pull /data/local/tmp/traceview.trace .

# 4. Open in Android Studio

2.2 Interpreting TraceView

Green markers denote App functions; yellow markers denote System functions.

Application.onCreate

Activity.onCreate

doFrame

WebView Initialization

2.3 Pros and Cons

TraceView uses high-frequency sampling, introducing significant performance overhead. Consequently, the execution times of individual methods are NOT accurate and should not be used as a real-time reference. Use it exclusively to visualize call stacks and pair it with Systrace for timing data.

3. Using SimplePerf for Startup Speed Analysis

SimplePerf captures both Java and Native stack traces.

To profile com.aboback.wanandroidjetpack (refer to SimplePerf Documentation):

1	python app_profiler.py -p com.aboback.wanandroidjetpack

Manually launch and then terminate the app:

$ python app_profiler.py -p com.aboback.wanandroidjetpack  
INFO:root:prepare profiling                                
INFO:root:start profiling1
INFO:root:run adb cmd: ['adb', 'shell', '/data/local/tmp/simpleperf', 'record', '-o', '/data/local/tmp/perf.data', '-e task-clock:u -f 1000 -g --duration 10', '--log', 'info', '--app', 'com.aboback.wanandroidjetpack']
simpleperf I environment.cpp:601] Waiting for process of app com.aboback.wanandroidjetpack
simpleperf I environment.cpp:593] Got process 32112 for package com.aboback.wanandroidjetpack

Generate the HTML report:

1	python report_html.py

Result:

SimplePerf captures both Java and Native stacks. For advanced usage, see:

4. Locating Other Component Startups in Systrace

4.1 Service Startup

public final void scheduleCreateService(...) {
    ...
    sendMessage(H.CREATE_SERVICE, s);
}

public final void scheduleBindService(...) {
    ...
    sendMessage(H.BIND_SERVICE, s);
}

Service operations are sent as Messages to the H Handler. They don’t execute immediately but are processed in the order defined by the MessageQueue.

Execution typically follows the first frame (after the queue catches up). Subsequent messages represent custom App logic, Service starts, and BroadcastReceivers.

4.2 Custom Messages

Custom App Messages in Systrace:

4.3 Service Startup Visualized

4.4 BroadcastReceiver Execution

Receiver execution in Systrace:

Dynamic registration (usually in lifecycle functions) executes where registered.

4.5 ContentProvider Startup Timing

5. Can AppStartup Optimize Startup Speed?

Third-Party Library Initialization

Many libraries require Application context for initialization. Some libraries initialize “stealthily” using a ContentProvider. By defining a provider and calling initialization in its onCreate, the library ensures it’s ready without explicit developer action, as the system calls onCreate for all registered providers during App startup.

Facebook, Firebase, and WorkManager commonly use this trick.

Provider initialization timing:

However, this leads to:

Too many ContentProviders during startup.
Loss of control over initialization timing for developers.
Inability to manage library dependencies.

AppStartup Library

Google introduced AppStartup to address this:

Shared ContentProvider: Consolidates initialization into a single provider.
Explicit Sequence: Defines exact initialization order.
Lazy Loading: Optionally removes automatic initialization to manually trigger it later, optimizing startup speed.

Measurements show AppStartup doesn’t significantly speed up startup unless you have many (e.g., 50+) ContentProviders.

If an SDK’s provider slows you down, consider removing it from the merge and manually initializing it:

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data android:name="com.example.ExampleLoggerInitializer"
              tools:node="remove" />
provider>

Summary

Purpose: Solves “ContentProvider Bloat” from multiple libraries.
Benefit: Minor. Usually $< 20$ms even with 20-30 libraries.
Best Use Scenarios:
- APK has excessive ContentProviders.
- Individual Providers are heavy but not critical for startup (can be lazy-loaded).
- Deep control over initialization order is required.

Action Items for App Developers:

Check the merged manifest for ContentProvider count ( AS -> src\main\AndroidManifest.xml -> Merged Manifest tab).
Measure initialization time for each.
Identify lazy-loading candidates.
Integrate AppStartup if needed.

6. Using IdleHandler in App Startup Scenarios

IdleHandler executes tasks when the MessageQueue is idle.

Usage scenarios:

Lazy Loading: Add an IdleHandler in Activity.onCreate to run non-critical tasks once the queue is clear.
Accurate Startup Metrics: Call activity.reportFullyDrawn() once the first page list/content is stable.
Systrace reflects this:
This records a meaningful cold start time:

Some system features also rely on FullyDrawn reports; they are highly recommended.

Series Articles

References

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Responsiveness in Action 2 - Responsiveness Analysis - Using App Startup as an Example

2021-09-13T02:46:44.000Z

This is the second article in the Responsiveness series, using Android App Cold Start as an example to explain how to use Systrace for analysis.

1. Preparation
2. Analysis of Android App Cold Start Flow
End
Series Articles
References
About Me && Blog

If you are not familiar with the basic use of Systrace (Perfetto), please catch up on the Systrace Basics Series first. This article assumes you are already familiar with using Systrace (Perfetto).

Systrace Series Articles:

1. Preparation

This case study and the corresponding Systrace are engineering-focused and omit many details, as App startup involves a vast range of knowledge. For an extremely detailed breakdown, I recommend: Complete Analysis of Android App Startup Flow.

We will use Systrace as our main thread to explain the high-level workflow of key modules during startup. After understanding the overview, you can dive into specific areas of interest. Here is a mapping of Systrace segments to phone screenshots (this blog uses Perfetto and Systrace interchangeably):

To more effectively analyze cold starts, perform these preparations:

Enable Binder Debugging: This displays Binder function names in Trace (requires Root).
1. Start IPC Debug: adb shell am trace-ipc start
2. Stop and dump: adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
Add the irq Tag: Default Trace commands don’t include irq. Adding it reveals interrupt details. Example command:
python systrace.py gfx input view webview wm am sm rs bionic power pm ss database network adb idle pdx sched irq freq idle disk workq binder_driver binder_lock -a com.xxx.xxx (replace com.xxx.xxx with your package name or omit -a for global).
Recommended Tool: If the App is buildable (your own project), integrate the TraceFix library (see Gracker/TraceFix). It uses code instrumentation to insert Trace points into every function, providing deep visibility into App logic.
1. Without the plugin: You only see Framework-level Trace points.
2. With the plugin: Trace data is significantly enriched with App-specific logic (note: only App logic is instrumented, not Framework code).

2. Analysis of Android App Cold Start Flow

This case covers cold starting an Android App from the Launcher. The flow spans from the first screen touch to the final UI display, involving:

Touchscreen interrupt handling.
InputReader and InputDispatcher event processing.
Launcher input handling.
SystemServer startup event processing.
Startup animations.
App internal startup and logic.

As noted in Part 1, the Start is the input event, and the End is the App being fully interactive for the user.

We’ll trace this through Systrace’s key stages:

2.1 Touchscreen Interrupt Handling

When a finger touches the screen, the touchscreen triggers an interrupt. The earliest trace in Systrace appears here:

Corresponding cpu ss zone and Interrupt zone (visible with irq tag):

Typically, a touch triggers several interrupts. The touchscreen driver updates these coordinates into EventHub for InputReader and InputDispatcher. Manufacturers focus on tuning this step.

2.2 InputReader and InputDispatcher Stage

These Native threads in SystemServer handle input events. See Input Explained for details.

For an icon click, the reported events include Input_Down, several Input_Move, and one Input_Up, forming a complete click sequence.

Since Launcher is in the foreground and visible, it receives these events. Tracing their flow through SystemServer and App is detailed in Input Explained; here are the core visualizations:

2.2.1 Event Flow in SystemServer

2.2.2 Event Flow in Launcher

2.3 Launcher Input Handling Stage

Launcher handling is a key segment of response time, involving two metrics:

Click to Launcher First Frame Response: Launcher usually dims the App icon upon receiving Down (or plays a shrink animation) to confirm receipt.
First Frame Response to App Launch: Time from processing the icon click to receiving Up and deciding to launch.

Note: Desktop Swipe Response Time (from finger movement to desktop’s first frame of movement, measured via high-speed camera) is also a critical system metric targeted for optimization.

In a cold start, Launcher receives Up, completes its logic, and hands off to AMS (returning to the SystemServer process).

This stage is usually of interest to system engineers. In recent versions, startup animations are collaborated on by Launcher and SystemServer to ensure visual continuity. Icons can now have layers or custom animations and dynamics that were impossible with pure SystemServer animations.

2.4 SystemServer StartActivity Stage

SystemServer handles:

Processing the launch command.
Notifying Launcher to Pause.
Forking the new process.

Processing the Launch Command

The Binder call in SystemServer is triggered by Launcher via ActivityTaskManager.getService().startActivity.

If the App process isn’t running, SystemServer must first start the process, then the Activity. This is the hallmark of a cold start. It forks from Zygote64 (or Zygote32 for some Apps).

Zygote 64 Executing Fork

App Process Appearance

Corresponding code: the App now enters its own process logic.

After startup, SystemServer records the time from startActivity to the first frame display. In Systrace, this is marked as shown below (Note: this ends at the first frame. If your App flow is SplashActivity -> MainActivity, this only covers SplashActivity).

2.5 App Process Startup Stage

Large-scale Apps typically categorize cold start into three parts. Each step slows down the overall speed. Define your “End” point clearly with testers (usually where the UI is stable).

Process Start to SplashActivity First Frame (or directly to MainActivity if no Splash).
SplashActivity First Frame to MainActivity First Frame.
MainActivity First Frame to Fully Loaded.

Analysis details for each:

Process Start to SplashActivity First Frame

Post-fork, the App must execute bindApplication (the core differentiator for cold vs hot starts). Once the environment is ready, it starts components (Activities here; Services, Broadcasts, or Providers would pre-empt Activity if they triggered the process).

Activity lifecycle functions (onStart, onCreate, onResume) execute, followed by one Choreographer#doFrame (measure/layout/draw), RenderThread initialization, and the final SurfaceFlinger Vsync cycle composition. The first frame then physically displays (at the finishDrawing marker). See MainThread and RenderThread Explained.

SplashActivity to MainActivity

Many Apps use a SplashActivity for ads. This involves another Activity creation cycle, business logic, WebView initialization, etc., leading to the MainActivity first frame.

MainActivity First Frame to Fully Loaded

A MainActivity often takes multiple frames to load fully as resources (like images) are asynchronously fetched. The first frame might just be a wireframe. Systrace alone is hard for defining the “Fully Loaded” point unless you use a custom Systrace Tag (e.g., in a View’s onDraw or when a List finishes and item count $> 0$).

Demonstration using a Systrace + Screenshot hybrid (from an open-source WanAndroid client):

End

This article focuses on visualizing the complete cold start flow in Systrace to help you locate bottlenecks and perform competitive analysis.

For “How to Analyze,” see the routine in Understanding Responsiveness Principles.
For “How to Optimize,” see Complete Record of Android App Startup Optimization. Optimization techniques evolve; I’ll maintain that article. If you find new techniques, leave a comment or contact me via WeChat (553000664).

Series Articles

References

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Responsiveness in Action 1 - Understanding Responsiveness Principles

2021-09-13T02:46:22.000Z

This is the first article in the Responsiveness series, focusing on theoretical knowledge, including an overview of performance engineering, key responsiveness concepts, and analysis methodologies.

Performance Engineering
Responsiveness Overview
Methodology for Analyzing Responsiveness Issues
Series Articles
References
About Me && Blog

For articles on Jank, refer to Systrace Smoothness in Action 1: Understanding Jank Principles. ANR articles will follow. This article focuses on the basic principles of responsiveness.

If you are not familiar with the basic use of Systrace (Perfetto), please catch up on the Systrace Basics Series first. This article assumes you are already familiar with using Systrace (Perfetto).

Performance Engineering

Before introducing responsiveness principles, here is a passage from the book “Systems Performance” regarding performance. This methodology aligns perfectly with our topic and is highly recommended as a handbook for performance optimization engineers:

Performance is Challenging
Systems performance engineering is a challenging field for many reasons, including the facts that system performance is subjective, complex, and often characterized by multiple concurrent issues.
Performance is Subjective
Technical disciplines are often objective; many in the industry view problems as black or white. In software troubleshooting, deciding whether a bug exists or is fixed is usually clear-cut. Bugs are accompanied by error messages that are often easy to interpret, leading you to understand why the error occurred.
In contrast, performance is often subjective. When starting on a performance issue, judging whether a problem even exists can be ambiguous, and the same applies when it is fixed. What one user considers “poor” performance, another might consider “good.”
Systems are Complex
Besides subjectivity, performance engineering is challenging because systems are complex and often lack a clear starting point for analysis. We often begin with guesses—blaming the network, for example—and performance analysis must determine if that is a correct direction.
Performance issues can arise from complex interconnections between subsystems, even when those subsystems perform well in isolation. They can also result from cascading failures, where one failing component causes performance issues in others. To understand these, you must untangle component relationships and how they collaborate.
Bottlenecks are often complex and interconnected in unexpected ways. Fixing one issue might simply push the bottleneck elsewhere, resulting in no overall performance gain.
Additionally, the complexity of production workloads can cause issues that are difficult to reproduce in a lab or occur only intermittently.
Solving complex performance problems often requires a holistic approach. The entire system—including internal and external interactions—may need investigation. This work demands a broad skill set, rarely found in one person, making performance engineering a dynamic and intellectually challenging endeavor.
Multiple Issues May Coexist
Finding a single performance issue is often not the end; complex software usually has multiple problems.
Another difficulty: the real task isn’t just finding problems, but identifying which ones are the most significant.
To do this, performance analysis must quantify the importance of issues. Some problems may not apply to your workload or only to a small degree. Ideally, you should not only quantify the problem but also estimate the speedup expected after fixing it. This information is especially useful when management reviews engineering or operations resource allocation.
One metric is particularly well-suited for quantifying performance: latency.
– Excerpts from “Systems Performance: Enterprise and the Cloud” (paraphrased)

Systrace Series Articles:

Responsiveness Overview

Responsiveness is a critical metric for App performance. Poor responsiveness typically manifests as delayed click effects, operation wait times, or prolonged white screens. Primary scenarios include:

App startup scenarios: Cold start, hot start, warm start, etc.
Interface transition scenarios: Page jumps within an App, or between different Apps.
Non-transition click scenarios: Toggles, pop-ups, long presses, control selections, single/double clicks, etc.
Screen wake/sleep, power on/off, unlocking, facial recognition, camera, video loading, etc.

Principle-wise, responsiveness scenarios are often triggered by an input event (as a Message to the processing UI thread) and end with the completion of one or more Messages, usually involving critical UI drawing. We measure responsiveness from the trigger event to the completion of processing; this duration is called the Response Time.

As shown below, responsiveness issues occur when one or more of these Messages take longer than expected (subjective), resulting in a completion time exceeding what the user anticipates.

Since responsiveness is subjective (unlike jank, which is binary), different roles have different criteria. For example, system developers, app developers, and testers have different view on App Cold Start boundaries:

System Developers: Observe from the input interrupt, often ending at the app’s first frame (easy to calculate) or complete loading (subjective and harder to measure without standardized tools). They focus on holistic optimization (input delivery, SystemServer, SurfaceFlinger, Kernel, Launcher, etc.).
App Developers: Observe from Application onCreate or attachContext, usually ending at a fully loaded or interactive state. They can add custom markers in their code and focus on improving their own app’s logic. Most “startup optimization” tutorials focus here.
Testers: Focus on the real user experience. The start is the icon highlight upon clicking the launcher; the end is complete content loading. They usually use high-speed cameras + automation with robotic arms and image recognition to standardize measurements.

Methodology for Analyzing Responsiveness Issues

Define the Start and End Points

The most important step is finding the start and end points. As noted, these vary by role and are subjective. Standardize these boundaries and metrics with all stakeholders using these methods:

Competitor Analysis: Use a baseline competitor device or App. Under identical conditions, how long does the competitor take from click to response?
Regression Analysis: Compare against previous system or App versions to ensure no regression.

The start point is usually easy (click or trigger event). The end point is trickier—e.g., when is a complex App like Taobao “fully loaded”? Systrace’s first frame, Displayed log, or onWindowFocusChange are often inaccurate. High-speed cameras with image recognition is the current industry standard.

Common Responsiveness Issues

Android System Issues Causing Slowness

These relate to the device’s hardware performance and system tuning. The weaker the device, the more likely these occur. Key signatures in App-side Systrace:

Insufficient CPU Frequency
- App Signature: UI Thread is “Running,” but execution time is longer.
CPU Core Scheduling: Critical tasks on Small Cores
- App Signature: UI Thread is “Running” in Systrace, but execution is slow.
Busy SystemServer, affecting:
1. Binder call processing latency.
  - App Signature: UI Thread is “Sleep,” waiting for Binder return.
2. Startup logic processing delay.
  - App Signature: UI Thread is “Sleep,” waiting for Binder return.
Busy SurfaceFlinger, affecting Render Thread dequeueBuffer/queueBuffer
- App Signature: Render Thread is in a Binder wait state during buffer operations.
Low Memory, which often triggers these issues affecting both SystemServer and Apps:
1. Frequent app killing and restarting. Startup is a heavy operation that consumes CPU, delaying the foreground App.
  - App Signature: UI Thread has more “Runnable” states and less “Running,” increasing total function time.
2. Frequent Garbage Collection (GC). HeapTaskDeamon and kswapd0 tasks for memory reclamation are frequent.
  - App Signature: More “Runnable,” less “Running,” increased function time.
3. Increased Disk IO. Disk IO is slow; the UI Thread may spend significant time in Uninterruptible Sleep.
  - App Signature: UI Thread has more “Uninterruptible Sleep” and “Uninterruptible Sleep - IO” states.
Thermal Throttling: CPU max frequency capped due to heat
- App Signature: UI Thread is “Running,” but execution is slow.
Overall System Load: Multiple heavy processes or one 100% CPU process
- App Signature: CPU zone is saturated. UI and Render threads are mostly “Runnable” or frequently switching between “Runnable” and “Running.”

App-Specific Issues

Primarily component, View, and data initialization during startup:

Application.onCreate: App logic + Third-party SDK initialization.
Activity Lifecycle: onStart, onCreate, onResume timeouts.
Service Lifecycle timeouts.
Broadcast onReceive timeouts.
ContentProvider initialization (often abused).
Layout initialization: measure, layout, draw delays.
Render Thread initialization: setSurface, queueBuffer, dequeueBuffer, Textureupload, etc.
Activity Jump: Time from SplashActivity to MainActivity.
Heavy Messages posted to the UI thread.
UI/Render thread waiting for worker thread data.
UI/Render thread waiting for sub-process data.
UI/Render thread waiting for network data.
Binder call timeouts.
WebView initialization.
First-run JIT (Just-In-Time) compilation.

Analysis Routine (Mainly Systrace)

Confirm prerequisites (device aging, data volume, downloads), steps, and phenomena. Reproduce locally.
Define metrics:
1. What is the start time?
2. What is the end time?
Capture logs (Systrace, standard logs, etc.).
Use Systrace to pinpoint differences:
1. Compare App bottleneck sections against a baseline device. Segment the startup phase:
  1. Application Creation
  2. Activity Creation
  3. First doFrame
  4. Subsequent Content Loading
  5. Custom App Messages
2. Analyze specific bottlenecks:
  1. Function execution is slow (Running) –> App Issue
  2. Long “Running” periods without stacks –> App Issue; add TraceTags or use TraceView
  3. Long Binder wait (Sleep) –> Check Binder Server/SystemServer
  4. Waiting for worker thread (Sleep) –> App Issue; check “Wakeup” info for the thread
  5. Waiting for sub-process/provider (Sleep) –> App Issue; check “Wakeup” for the process/provider
  6. Excessive “Runnable” –> System Issue; CPU is saturated
  7. Excessive IO wait (Uninterruptible Sleep | WakeKill - Block I/O) –> System Low Memory
  8. RenderThread dequeueBuffer/queueBuffer delays –> Check SurfaceFlinger
3. If it’s a system issue, check relevant system zones (reference common causes above):
  1. Kernel Zone
    1. Critical tasks on Small Cores (e.g., 0-3).
    2. Frequencies not capped at max (e.g., 1.8GHz vs 2.8GHz).
    3. CPU saturation (no gaps between tasks on 8 cores).
    4. Low Memory Indicators: Frequent Uninterruptible Sleep, HeapTaskDeamon, or kswapd0.
  2. SystemServer Zone
    1. Input reading/dispatch anomalies (rare).
    2. Binder logic timeouts.
    3. AM/WM lock contention (use Wakeup info to trace lockers).
    4. Frequent process starts/kills (check startProcess or Event Log).
  3. SurfaceFlinger Zone
    1. Binder processing delays for buffer calls.
    2. Main thread busy with unrelated tasks.
  4. Launcher Zone (Startup scenarios)
    1. Input event handling delay.
    2. onPause delay.
    3. Startup animation jank.
Post-initial analysis:
1. If it’s a system issue, can the App avoid it? If not, escalate to the system team.
2. If it’s an App issue, use TraceView (Android Studio Profiler), SimplePerf, or the TraceFix Plugin for detailed function traces and comparison.
Address multiple causes:
1. Optimize the major bottlenecks first. Ignore minor ones initially.
2. Some require system/App co-optimization (e.g., App vendors using phone manufacturer SDKs like those from Oppo, Huawei, Vivo).
3. If minor or unsolvable, document and communicate with Test teams.
4. Check if it’s a duplicate or platform-specific cross-issue in the Bug database.

This article provides a foundation for responsiveness knowledge. It involves significant system-level details; please review the Systrace Basics Series for depth.

Series Articles

References

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Smoothness in Action 3 - FAQs During Jank Analysis

2021-04-24T11:55:12.000Z

Different people have different understandings of smoothness (jank/dropped frames) and different perceptions of jitter thresholds. Therefore, before starting this series, it is necessary to clarify the content to avoid misunderstandings. Here are some basic explanations:

For mobile users, jank encompasses many scenarios: dropped frames when scrolling lists, excessive white screen during app startup, slow screen wake-up when pressing the power button, unresponsive interface followed by a crash, no response when clicking an icon, incoherent window animations, lagging touch response, or stuttering when entering the desktop after a reboot. These scenarios differ slightly from what developers understand as “jank.” Developers categorize these more finely, which is a cognitive gap between developers and users that must be noted when handling feedback from users or testers.
For developers, the above scenarios fall into three major categories: Smoothness (dropped frames in lists, incoherent animations, stuttering desktop entry), Responsiveness (long startup white screens, slow screen wake-up, lagging touch), and Stability (unresponsive interface/crashes, no response to icon clicks). This classification is used because each category requires different analysis methods and steps. Quickly identifying the category is crucial.
Technically, Smoothness, Responsiveness, and Stability (ANR) all feel like “jank” to users because their underlying principles are identical: the main thread’s Message exceeds its processing deadline. They are simply categorized by different timeout thresholds. Understanding these problems requires knowledge of basic system operation mechanisms, which this article will introduce.
This series primarily analyzes smoothness-related issues. Responsiveness and stability will be covered in dedicated articles. Understanding smoothness first will make analyzing responsiveness and stability much easier.
This series focuses on using Systrace (Perfetto) for analysis. Systrace is our entry point because many factors affect smoothness—some within the app itself and others within the system. Systrace (Perfetto) provides a holistic view of the system’s operation during the problem, helping us initially pinpoint the root cause.

What Do the Frame Colors in Systrace Mean?
No Red Frame Means No Dropped Frame?
Why Does the Main Thread Wait for the Render Thread?
Why Doesn’t It Jank When Swiping Without Releasing?
If It Doesn’t Jank, How Do We Measure Performance?
Why Can’t I See Jank in Screen Recordings?
Series Articles
Attachments
About Me && Blog

Systrace Series Articles:

If you are not familiar with the basic use of Systrace (Perfetto), please catch up on the Systrace Basics Series first. This article assumes you are already familiar with using Systrace (Perfetto).

What Do the Frame Colors in Systrace Mean?

Frame markers are the circles found on the app’s UI thread area. There are three colors, each indicating the time spent on that frame.

Clicking a circle highlights the corresponding UI and Render thread tasks (graying out everything else).

Green Frame

The most common, indicating the frame finished within a single Vsync cycle.

Yellow Frame

Indicates the frame took longer than 1 Vsync cycle but less than 2. Yellow frames suggest potential performance issues that might lead to user-perceived jank.

Red Frame

Indicates the frame took longer than 2 Vsync cycles. Red frames strongly suggest performance issues that are very likely to cause visible jank.

No Red Frame Means No Dropped Frame?

Not necessarily. Judging actual jank requires looking at SurfaceFlinger, not the App traces. This requires the foundational knowledge from Triple Buffer Explained.

Yellow Frame Without Jank

As noted, yellow frames mean the frame exceeded a cycle. However, thanks to Triple Buffering (and even more buffers on modern high-refresh devices), an App-side delay doesn’t always translate to an SF-side jank.

Yellow Frame With Jank

In the Mi Launcher case analyzed in Part 2, there were only yellow frames. Two consecutive yellow frames occurred; the first caused a visible jank, while the second did not.

Why Does the Main Thread Wait for the Render Thread?

Looking at the two yellow frames from the Mi trace, notice the UI Thread in the second yellow frame spent a lot of time waiting. Don’t mistake this for a UI thread bottleneck; it was in a “Sleep” state.

As explained in MainThread and RenderThread Explained, the UI thread must wait for the Render thread to finish syncFrameState before it is unblocked. In this case, the previous frame’s Render thread timeout caused the current frame’s Render thread task to queue, which in turn kept the UI thread waiting.

Why Doesn’t It Jank When Swiping Without Releasing?

In the desktop swipe scenario, jank occurred only after the finger was released. Swiping while holding never janked. Why?

If you don’t release, the CPU maintains a continuous Boost state, and RenderThread tasks are scheduled on Big Cores (CPUs 4-6) rather than Small Cores. Naturally, no jank occurs.

This PerfLock Boost timeout is typically 120ms (varies by model).

If It Doesn’t Jank, How Do We Measure Performance?

If a scenario feels smooth on both devices, how do we compare performance?

Use adb shell dumpsys gfxinfo as follows:

Identify the package and prepare the app.
Run adb shell dumpsys gfxinfo framestats reset 2-3 times to clear history.
Perform the operation (e.g., swiping).
Run adb shell dumpsys gfxinfo framestats.
Focus on:
1. Janky frames: Number of frames exceeding a cycle (not always perceived as jank).
2. 95th percentile: Frame time at the 95th percentile.
3. HISTOGRAM: Distribution of frame times.
4. PROFILEDATA: Raw details for every frame.

Comparing Mi 10 Pro vs. Oppo Reno 5 Pro (both at 90 fps target):

Mi 10 Pro - 90 fps

Oppo Reno 5 - 90 fps

Comparisons show Mi 10 Pro performance is actually weaker in this specific scenario:

Janky frames:
- Mi: 27 (35.53%)
- Oppo: 1 (1.11%)
95th percentile:
- Mi: 18ms
- Oppo: 5ms

Interestingly, while the Mi 10 Pro has a much stronger GPU (Snapdragon 865), its GPU stats are better, confirming the bottleneck in this scenario is CPU, not GPU.

Why Can’t I See Jank in Screen Recordings?

Several reasons:

If you record a 90Hz screen at 60Hz, the recording will appear smooth even if 90Hz jank occurs (this applies to external camera recordings too).
If you record at 90Hz but playback on a 60Hz device (e.g., viewing an Mi recording on a standard PC/phone), the player downsamples to 60Hz, hiding the jank.

Series Articles

Attachments

Attachments are on GitHub: https://github.com/Gracker/SystraceForBlog/tree/master/Android_Systrace_Smooth_In_Action

xiaomi_launcher.zip: Main analysis trace.
xiaomi_launcher_scroll_all_the_time.zip: Continuous scrolling trace.
oppo_launcher_scroll.zip: Comparison trace.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Smoothness in Action 2 - Case Analysis - MIUI Launcher Scroll Jank Analysis

2021-04-24T11:55:07.000Z

For mobile users, jank encompasses many scenarios: dropped frames when scrolling lists, excessive white screen during app startup, slow screen wake-up when pressing the power button, unresponsive interface followed by a crash, no response when clicking an icon, incoherent window animations, lagging touch response, or stuttering when entering the desktop after a reboot. These scenarios differ slightly from what developers understand as “jank.” Developers categorize these more finely, which is a cognitive gap between developers and users that must be noted when handling feedback from users or testers.
For developers, the above scenarios fall into three major categories: Smoothness (dropped frames in lists, incoherent animations, stuttering desktop entry), Responsiveness (long startup white screens, slow screen wake-up, lagging touch), and Stability (unresponsive interface/crashes, no response to icon clicks). This classification is used because each category requires different analysis methods and steps. Quickly identifying the category is crucial.
Technically, Smoothness, Responsiveness, and Stability (ANR) all feel like “jank” to users because their underlying principles are identical: the main thread’s Message exceeds its processing deadline. They are simply categorized by different timeout thresholds. Understanding these problems requires knowledge of basic system operation mechanisms, which this article will introduce.
This series primarily analyzes smoothness-related issues. Responsiveness and stability will be covered in dedicated articles. Understanding smoothness first will make analyzing responsiveness and stability much easier.
This series focuses on using Systrace (Perfetto) for analysis. Systrace is our entry point because many factors affect smoothness—some within the app itself and others within the system. Systrace (Perfetto) provides a holistic view of the system’s operation during the problem, helping us initially pinpoint the root cause.

The Routine for Analyzing Jank with Systrace
Case Study: Analyzing Jank with Systrace
Case Description
What Role Does Triple Buffer Play in This Scenario?
Series Articles
Attachments
About Me && Blog

Systrace Series Articles:

If you are not familiar with the basic use of Systrace (Perfetto), please catch up on the Systrace Basics Series first. This article assumes you are already familiar with using Systrace (Perfetto).

The Routine for Analyzing Jank with Systrace

The general workflow for using Systrace to analyze jank is as follows:

Reproduce the jank scenario and capture a Systrace using shell or built-in tools.
Open the captured trace.html directly in Chrome.
1. If it doesn’t open directly, type chrome://tracing/ in Chrome and drag the file onto the page.
2. Alternatively, use Perfetto View and select “Open With Legacy UI.”
Understand the context of the problem to improve analysis efficiency.
1. User (or tester) operation steps.
2. Reproduction probability.
3. Whether competitor devices exhibit the same jank.
Before or during analysis, check the Systrace for basic info:
1. CPU frequency, architecture, Boost info, etc.
2. Thermal throttling: Manifests as suppressed CPU frequencies.
3. High load scenarios: Manifests as very dense tasks in CPU zones.
4. Low memory scenarios: Manifests as busy lmkd, slow HeapTaskDeamon in the App process, or many Block IOs.
Locate the App process in Systrace.
1. The first thing to look at is the App process, specifically the UI thread and Render thread. Find time-consuming frames. E.g., the red box below shows a UI Thread taking 110ms—clearly abnormal (from a Bilibili list scroll jank case).
2. In fact, any doFrame that exceeds a Vsync cycle (Yellow and Red frames) needs checking for actual jank. Even without jank, look for reasons. E.g.:
3. Vsync cycle vs. Refresh rate:
  1. 60fps: 16.6ms cycle.
  2. 90fps: 11.1ms cycle.
  3. 120fps: 8.3ms cycle.
Analyze the SurfaceFlinger process’s Main thread and Binder thread.
1. Due to multiple buffer mechanisms, the App main/render threads might exceed a cycle without causing jank. Check SurfaceFlinger‘s Main thread to confirm. E.g., for the 110ms app frame above, the SF Main thread looks like this:
2. The App’s Buffer count in the SF process area is also empty:
System-wide and Binder call analysis (optional).
1. In the Bilibili case, the bottleneck is clearly within the App itself. Optimizing the relevant View or logic would suffice.
2. Sometimes the App UI thread is slow due to excessive Runnable states or Binder call timeouts, which requires system-wide analysis to find the root cause.

After following this routine, cross-reference data across processes to infer the most likely cause.

App frame drops have many causes. Refer to these articles; different causes have distinct Systrace signatures:

Case Study: Analyzing Jank with Systrace

Systrace is the primary tool for analyzing jank, providing a global view to determine if jank is system-driven or app-specific.

However, for deeper analysis, Systrace can be limited. It often needs to be paired with TraceView and source code to pinpoint and solve issues, and then verified again with Systrace.

This article focuses on discovery and analysis. Solutions (like optimizing logic, scheduling, or layout) must be tailored to findings.

Case Description

On my Mi 10 Pro, I often felt a stutter during the common gesture of swiping the desktop. Since the Mi 10 Pro has a 90Hz screen and 90 FPS target, jank is very noticeable. After upgrading to MIUI 12.5, the issue remained, so I decided to investigate.

The captured Systrace revealed a perfect case study for smoothness analysis.

I recommend downloading the attached Systrace and following along with the article.

Because many factors affect jank, I’ll clarify the hardware and software versions first. Findings apply to the attached Systrace even if the scenario is optimized later.
Hardware: Mi 10 Pro
Software: MIUI 12.5.3 Stable
Launcher Version: RELEASE-4.21.11.2922-03151646

Starting with Input events

In the captured Systrace, I performed only one swipe, making it easy to locate. The input sequence consists of one Input Down, several Input Moves, and one Input Up.

In Systrace, we see InputDispatcher and InputReader threads in SystemServer, but we primarily focus on the App UI thread.

As shown above, deliverInputEvent on the App UI thread marks input processing. After “Input Up,” the “Fling” phase begins. Basics:

Analyzing the UI Thread

Since this jank mostly occurred after releasing the finger, we focus on the segment after “Input Up.”

UI thread frames are color-coded: Green, Yellow, Red. In this trace, there are no red frames, only green and yellow. Is a yellow frame always a jank? Not necessarily. We can’t confirm jank from the UI thread alone.

Identifying three suspicious points, we move to the RenderThread.

Analyzing the Render Thread

Zooming into the first suspicious point: total frame time is 19ms, with RenderThread taking 16ms. The RenderThread CPU state is “Running” (green). This delay is likely due to:

RenderThread is busy with heavy tasks.
RenderThread performance is bottlenecked by the CPU (low frequency or small cores).

Before looking at the CPU, we check SurfaceFlinger to confirm actual jank.

Analyzing SurfaceFlinger

For basics on SF trace reading, see SurfaceFlinger Explained.

We focus on two points:

Buffer status in the App’s BufferQueue. Does SurfaceFlinger have a buffer available from the app?
SurfaceFlinger Main thread composition. If SF-vsync arrives and composition occurs, was it for our app?

Criteria for Judging Jank:

If SF has no composition task and the App worked during that cycle but provided no Buffer to BufferQueue, jank occurred.
(Matches the first suspicious point).
If SF performs composition but our App’s BufferQueue is empty, jank still occurred for our App. SF likely composited other layers.
If SF performs composition and our App has a Buffer available, everything is normal.
(Provided for comparison).

At the first suspicious point, SF confirms a frame was dropped because the App didn’t provide a Buffer. Why?

Back to the Render Thread

The 19ms total frame time (16ms in RenderThread) is unusual for a low-load scenario like desktop scrolling, especially since the previous frame was 3x faster. This isn’t a task load issue.

Check the RenderThread CPU info:

Since it’s “Running,” we check the Kernel area for scheduling details.

Analyzing CPU Info

See CPU Info Explained and Prerequisites for Systrace.

In this case, the RenderThread is mostly on CPUs 0 and 2—the Small Cores of the Snapdragon 865 (which has 4 Small, 3 Big, and 1 Prime core).

The frequency is capped at 1.8GHz (Small core max).

And there’s no CPU Boost active.

Hypothesis: Small cores even at max frequency can’t finish the task in time. Validation steps:

Are normal frames also on small cores? (If yes without jank, the hypothesis is wrong).
Are other janky frames also caused by small core scheduling?

Analysis reveals:

Normal frames are NOT on small cores. After a jank, the scheduler immediately moves RenderThread back to big cores.
Every janky frame was caused by RenderThread being scheduled on small cores which lacked the performance to finish on time.

Cause found: RenderThread being scheduled on Small Cores.

Scheduling is controlled by complexity algorithms based on task load. Optimizations:

Adjust core migration thresholds or scheduler algorithms.
Compare competitor strategies and scheduling indicators in similar scenarios.

What Role Does Triple Buffer Play in This Scenario?

In Triple Buffer Explained, we noted it helps:

Mitigate jank.
Reduce wait times.
Lower bottlenecks.

However, in this Mi Launcher case, it sometimes had a negative impact, worsening the perceived jank:

See the Mitigating Jank principle:

In the Mi Launcher trace, the BufferQueue sometimes dropped from 2 available buffers to 0, effectively discarding a buffer:

If a subsequent RenderThread timeout occurs during a Fling, no spare buffer is left to cushion it, resulting in an immediate jank. Triple buffering’s mitigation effect is lost.

Furthermore, since Fling offsets are pre-calculated, discarding a frame buffer causes a visual “jump”:

Example with scrolling offsets:

Normal: 2→4→6→8→10→12
Dropped (cushioned): 2→4→6→6→8→10→12 (Frame “8” delayed, user sees “6” twice—smooth decay).
Discarded: 2→4→6→6→10→12 (Frame “8” discarded, jumps from “6” to “10”—feels like a jank + a jump).

Series Articles

Attachments

Attachments are on GitHub: https://github.com/Gracker/SystraceForBlog/tree/master/Android_Systrace_Smooth_In_Action

xiaomi_launcher.zip: Main analysis trace.
xiaomi_launcher_scroll_all_the_time.zip: Continuous scrolling trace.
oppo_launcher_scroll.zip: Comparison trace.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Smoothness in Action 1 - Understanding Jank Principles

2021-04-24T11:55:02.000Z

For mobile users, jank encompasses many scenarios: dropped frames when scrolling lists, excessive white screen during app startup, slow screen wake-up when pressing the power button, unresponsive interface followed by a crash, no response when clicking an icon, incoherent window animations, lagging touch response, or stuttering when entering the desktop after a reboot. These scenarios differ slightly from what developers understand as “jank.” Developers categorize these more finely, which is a cognitive gap between developers and users that must be noted when handling feedback from users or testers.
For developers, the above scenarios fall into three major categories: Smoothness (dropped frames in lists, incoherent animations, stuttering desktop entry), Responsiveness (long startup white screens, slow screen wake-up, lagging touch), and Stability (unresponsive interface/crashes, no response to icon clicks). This classification is used because each category requires different analysis methods and steps. Quickly identifying the category is crucial.
Technically, Smoothness, Responsiveness, and Stability (ANR) all feel like “jank” to users because their underlying principles are identical: the main thread’s Message exceeds its processing deadline. They are simply categorized by different timeout thresholds. Understanding these problems requires knowledge of basic system operation mechanisms, which this article will introduce.
This series primarily analyzes smoothness-related issues. Responsiveness and stability will be covered in dedicated articles. Understanding smoothness first will make analyzing responsiveness and stability much easier.
This series focuses on using Systrace (Perfetto) for analysis. Systrace is our entry point because many factors affect smoothness—some within the app itself and others within the system. Systrace (Perfetto) provides a holistic view of the system’s operation during the problem, helping us initially pinpoint the root cause.

Understanding Jank Principles
System Operation Mechanism Overview
Series Articles
Attachments
About Me && Blog

Systrace Series Articles:

If you are not familiar with the basic use of Systrace (Perfetto), please catch up on the Systrace Basics Series first. This article assumes you are already familiar with using Systrace (Perfetto).

Understanding Jank Principles

Jank Phenomena and Impact

As stated at the beginning, this article focuses on smoothness issues. Smoothness is a qualitative definition, but we often use fps (Frames Per Second) to quantify it. For example, 60 fps means the screen updates 60 times per second; 120 fps means 120 times. On a 120 fps system, if the screen only updates 110 times in a second (during continuous animation), we call this a dropped frame, which manifests as jank. The fps drops from 120 to 110, which can be accurately monitored.

Dropped frames have many causes: app-specific issues, system-driven jank, hardware bottlenecks, or overall system lag. Refer to these four articles:

Jank is what users notice first:

Occasional minor jank degrades user experience, like a stutter when scrolling Weibo or returning to the desktop.
Severe system-wide jank makes the phone unusable.
In the high-refresh-rate era, if users are accustomed to 120 fps and the system suddenly switches to 60 fps in an easily perceptible scenario, they will immediately notice and feel it as jank.

Therefore, both apps and systems should aim to avoid jank. Identified jank issues should be prioritized for resolution.

Jank Definition

Overall App Frame Rendering Flow

To understand why jank occurs, we must know how the app’s main thread processes a frame.

From the Perspective of Execution Order

The flow starts when Choreographer receives Vsync and ends when SurfaceFlinger/HWC composites a frame (followed by physical display hardware, which isn’t listed here).

From the Perspective of Systrace

The flow is more intuitive when visualized in Systrace (Perfetto):

A timeout at any step in this overall flow can lead to jank. Therefore, analyzing jank requires looking at multiple levels: App main thread, Render thread, SystemServer process, SurfaceFlinger process, Linux kernel areas, etc.

Jank Definition

My definition of jank is: One or more frames fail to be drawn during a stable frame rate output. Corresponding terms: Smooth VS Jank.

For instance, in the image below, if an App’s main thread is drawing normally (usually during animation or scrolling) but one frame is not drawn, we consider that frame as potentially causing jank (potentially, because Triple Buffering might prevent actual frame drops).

We define jank from three perspectives:

From a Phenomenological perspective: During continuous app animation or finger scrolling (continuity is key), if the app’s screen content doesn’t change for 2 or more consecutive frames, we consider it jank.
From the SurfaceFlinger perspective: During continuous app animation or scrolling, if a Vsync arrives and the App has no Buffer available for composition, SurfaceFlinger will skip composition for that app layer (or composite other layers) during that Vsync cycle. The screen will continue to display the App’s previous frame. We consider this a jank.
From the App perspective: If the Render thread fails to queueBuffer to the App’s BufferQueue within SurfaceFlinger during a Vsync cycle, we consider it a jank.

The App main thread isn’t mentioned directly because its timeouts usually indirectly delay the Render thread, increasing the risk of Render thread execution timeouts and thus causing jank. Most app-driven jank is caused by main thread timeouts.

It’s also important to distinguish Logical Jank. Logical jank occurs when the rendering flow itself is fine, and a Buffer is provided to SurfaceFlinger for composition, but the content of that Buffer is identical (or nearly identical and imperceptible) to the previous Buffer. To the user, it appears as identical content for two consecutive frames. This is still considered jank (depending on context) and is caused by the app’s own code logic.

System Operation Mechanism Overview

Because there are many causes for jank, analyzing it requires an understanding of Android’s system mechanisms. Here is a brief introduction:

App Main Thread Operation Principles
Message, Handler, MessageQueue, and Looper Mechanisms
Screen Refresh Mechanism and Vsync
Choreographer Mechanism
Buffer Flow and TripleBuffer
Input Flow

System Mechanism - App Main Thread Operation Principles

When an App process is created and Fork completes, ActivityThread.main() is called to initialize the main thread.

// frameworks/base/core/java/android/app/ActivityThread.java
public static void main(String[] args) {
     ......
     // Create Looper, Handler, MessageQueue
     Looper.prepareMainLooper();
     ......
     ActivityThread thread = new ActivityThread();
     thread.attach(false, startSeq);

     if (sMainThreadHandler == null) {
         sMainThreadHandler = thread.getHandler();
     }
     ......
     // Start listening for messages
     Looper.loop();
}

// frameworks/base/core/java/android/os/Looper.java
public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

// frameworks/base/core/java/android/os/Looper.java
private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

// frameworks/base/core/java/android/os/Looper.java
private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

Once initialized, the main thread has its own Looper, MessageQueue, and Handler. The ActivityThread Handler then processes Messages, including lifecycle functions for Application, Activity, ContentProvider, Service, and Broadcast, which are processed sequentially on the main thread as Messages. Here are some examples:

// frameworks/base/core/java/android/app/ActivityThread.java
class H extends Handler {
    public static final int BIND_APPLICATION        = 110;
    public static final int EXIT_APPLICATION        = 111;
    public static final int RECEIVER                = 113;
    public static final int CREATE_SERVICE          = 114;
    public static final int SERVICE_ARGS            = 115;
    public static final int STOP_SERVICE            = 116;

    public void handleMessage(Message msg) {
        switch (msg.what) {
            case BIND_APPLICATION:
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
                AppBindData data = (AppBindData)msg.obj;
                handleBindApplication(data);
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                break;
        }
    }
}

For more, see Android Systrace Basics - MainThread and RenderThread Explained.

System Mechanism - Message Mechanism

As described above, once the main thread is initialized, it enters a blocked state waiting for Messages. When a Message arrives, it wakes up, processes it, and returns to sleep if no other Messages are pending.

The core of the Android Message mechanism consists of: Handler, Looper, MessageQueue, and Message.

Many code-level analyses exist, so here is a brief overview of the components:

Handler: Primarily handles Messages. Apps can create Handlers in any thread by specifying a Looper. If omitted, it defaults to the current thread’s Looper.
Looper: An infinite loop. After its loop() method starts, it continuously retrieves Messages from the MessageQueue, delivers/dispatches them, and sends them to the corresponding Handler. Apps can insert their own printers before and after message processing, making Looper a common entry point for performance monitoring (e.g., Tencent-Matrix and BlockCanary).
MessageQueue: A Message manager. It holds Messages in a queue. When empty, it uses Linux’s nativePoll mechanism to block and wait until a Message enters the queue.
Message: The object used to pass information, containing content like what, arg, and callback.

ActivityThread uses this mechanism to handle all App and component lifecycle functions.

System Mechanism - Screen Refresh and Vsync

First, understand Screen Refresh Rate. A hardware concept, it refers to how often the screen hardware refreshes the image. E.g., a 60Hz rate means the screen refreshes its display 60 times per second; 90Hz means 90 times.

In contrast, FPS (Frames Per Second) is a software concept and refers to how many frames the software system produces per second. E.g., 60FPS means the software generates 60 frames per second; 90FPS means 90 frames.

VSync (Vertical Synchronization) synchronizes your FPS with the monitor’s refresh rate to prevent “tearing.”

In a 60 fps system, 60 frames must be generated per second, meaning drawing a frame must take at most 16.67ms (1/60) to avoid dropped frames (FrameMiss).
In a 90 fps system, 90 frames must be generated per second, meaning drawing a frame must take at most 11.11ms (1/90) to avoid dropped frames.

Typically, the screen hardware controls the refresh rate, while Vsync controls the FPS. In practice, they are usually identical. See:

System Mechanism - Choreographer

As mentioned, Vsync controls FPS. It does this through Choreographer.

Choreographer coordinates with Vsync to provide a stable Message processing timing for App-level rendering. When Vsync arrives, the system adjusts the Vsync signal period to control the timing of drawing operations for each frame. Vsync typically uses a 16.6ms (60 fps) period to match 60Hz screens. Every 16.6ms, Vsync wakes Choreographer to perform app drawing. If the app renders within this window every cycle, it achieves 60 fps, appearing very smooth.

Choreographer bridges the rendering pipeline:

Upper side: Receives and processes app update messages and callbacks (Input, Animation, Traversal - measure/layout/draw), handles them collectively when Vsync arrives, detects frame drops, and records callback durations.
Lower side: Requests and receives Vsync signals (via FrameDisplayEventReceiver.onVsync and FrameDisplayEventReceiver.scheduleVsync).

The following image shows Choreographer‘s frame drawing workflow via the Message mechanism when Vsync arrives. Details: Detailed Explanation of Android Rendering Mechanism Based on Choreographer.

System Mechanism - Buffer Flow and TripleBuffer

BufferQueue uses a Producer-Consumer model. Typically, the Consumer creates and owns the BufferQueue data structure, while the Producer exists in a separate process.

In app rendering, the App is the Producer and SurfaceFlinger is the Consumer:

App calls dequeueBuffer() to request a buffer.
App renders (via CPU or GPU) and calls queueBuffer() to return it. (Gpu-rendered buffers aren’t immediately available until GPU work finishes).
SurfaceFlinger receives a Vsync signal, calls acquireBuffer() to take the buffer, and performs composition.
SurfaceFlinger calls releaseBuffer() to return it after composition.

Most current systems use three alternating buffers (Triple Buffering) to prevent jank caused by buffer shortages if one step in the flow takes too long.

Comparison of double vs. triple buffering:

Benefits of Triple Buffering:

Mitigating Jank: Triple buffering helps reduce frame drop frequency during consecutive main thread timeouts (reducing two drops to one). Main thread timeouts don’t always result in user-visible jank because Triple Buffering can cushion GPU-induced delays.
Reducing Wait Times: In double buffering, the main thread sometimes waits for SF to release a buffer, delaying its start time since most phones send SF and App Vsync signals simultaneously.
Lowering GPU and SurfaceFlinger Bottlenecks: High SF load or GPU timeouts easily prevent double-buffered frames from compositing on time. Triple buffering lets buffers enter the queue for GPU rendering earlier, reducing wait times and bottlenecks.

The downside is increased memory usage. Details: Android Systrace Basics - Triple Buffer Explained.

System Mechanism - Input Flow

Android is event-driven, and input events (clicks, scrolls, long presses) are handled via InputReader and InputDispatcher. These are two Native threads in SystemServer.

InputReader reads events from EventHub and passes them to InputDispatcher.
InputDispatcher wraps and dispatches them to the relevant app connection.
OutboundQueue holds events about to be sent to an app.
WaitQueue holds events sent to an app but not yet acknowledged.
PendingInputEventQueue holds events pending in the app process.
deliverInputEvent marks the App UI Thread being woken by an Input event.
InputResponse marks the processing phase for an Input sequence (Down + Move + Up).
App Input Response: E.g., scrolling then releasing (Fling). The desktop updates along with the finger and continues via Fling after release.

Systrace representation:

Details: Android Systrace Basics - Input Explained.

Series Articles

Attachments

Attachments are on GitHub: https://github.com/Gracker/SystraceForBlog/tree/master/Android_Systrace_Smooth_In_Action

xiaomi_launcher.zip: Systrace for launcher scroll jank (main analysis case).
xiaomi_launcher_scroll_all_the_time.zip: Systrace for continuous launcher scrolling.
oppo_launcher_scroll.zip: Comparison trace.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Why is the Weibo Experience Better on Huawei? A Technical Analysis and Reflection

2020-08-20T05:17:26.000Z

A fellow developer shared a Weibo post (https://weibo.com/1808884742/IApbpEVQr) where blogger @王波粒 noticed a peculiar phenomenon on the Mate 30 Pro. I highly recommend watching the video first.

The video’s description and some of the comments aren’t quite technically accurate. Here’s a summary of what’s actually happening: On Huawei phones, the Weibo app continues to load images smoothly while scrolling the main feed. However, the exact same version of the Weibo client on other phones waits until scrolling completely stops before it begins loading images.

This post looks at this phenomenon from a technical perspective, explores why it happens, and discusses what we can learn from it.

What makes this so special?

Technical Standard: Waiting for a scroll to finish before loading images is a classic optimization for list performance. Most mainstream apps do this to prevent “scrolling jank.” If an app tries to load every photo or video it encounters mid-scroll, it wastes resources and can delay the loading of content the user actually stops to look at. The fact that the same APK behaves differently on Huawei suggests a deep, device-specific optimization—likely a joint effort between Weibo and Huawei.
User Experience: Loading images during the scroll allows users to see content sooner, reducing the time spent looking at blank placeholders even if they are just flicking through.
The “Fling” Curve: If you look closely, the deceleration curve (the “fling”) on Huawei phones is different. It’s smoother, gentler, and lacks the abrupt stops common in standard Android implementations. It feels more organic, similar to how iOS handles inertial scrolling.

This collaboration between Huawei and Weibo is a great case study for head-tier app optimization. It shows a level of attention to detail that is rare in the Android ecosystem.

Contextual Notes

Server-Side Control: The “load images during scroll” feature is controlled by Weibo’s server and can be toggled on or off. The observation that other phones “wait for stop” was true when the feature was disabled for non-optimized devices.
Current State (Aug 2020): Weibo has since enabled this feature for more devices. However, Huawei’s PerfSDK still provides a superior experience by optimizing the deceleration curve itself, ensuring the phone stays smooth even under the increased load of mid-scroll image fetching.
Analyzed Version: Weibo v10.8.1.

The Verdict

The “smooth image loading during scroll” on Huawei is the result of a joint optimization. The key technical points are:

Velocity Monitoring: Huawei provides a lightweight PerfSDK to Weibo. This allows the app to listen for the precise velocity of the list in real-time.
Dynamic Loading Logic: Weibo uses this velocity data to decide when to fetch images. If the velocity is below a certain threshold (meaning the user is slow-scrolling or the fling is nearing its end), image loading is enabled. If it’s too fast, loading is paused to prioritize UI responsiveness.
Custom Fling Curves: When Huawei detects an app using this SDK, it applies a specialized system-level fling curve to the app’s scrollable containers, making the inertial movement look and feel premium.

How the Optimization Works

Phenomenon Analysis

A scroll operation generally has three phases:

SCROLL_STATE_TOUCH_SCROLL: Finger is on the screen, actively moving the list.
SCROLL_STATE_FLING: Finger leaves the screen with speed; the list moves by inertia.
SCROLL_STATE_IDLE: The list has come to a complete stop.

The Huawei/Weibo optimization targets Phase 1 and Phase 2.

Phase 1 Optimization

Before: Image loading is paused whenever a finger is on the screen to prevent frame drops during touch interaction.
After: Since touch-scrolling is generally slower than a full fling, image loading is kept active, allowing content to appear immediately as it enters the viewport.

Phase 2 Optimization (Fling)

Smart Image Loading:
- High Velocity: Image loading is paused to ensure the GPU/CPU can stay at 60Hz (or 90/120Hz) while the list renders at high speed.
- Low Velocity: Once the fling slows down to a manageable speed, image loading resumes before the list fully stops.
Inertial Smoothing:
- Huawei replaces the default Android fling curve (which can feel linear or jerky) with a custom, “soft” curve that lasts longer and stops gracefully.

Technical Deep Dive (Reverse Engineering)

Analysis of Weibo v10.8.1 reveals that during initialization, the app checks for the presence of Huawei’s PerfSDK.

Monitoring Velocity

Weibo registers a HwPerfVelocityCallback on its main ListView. It listens for two key events:

HwPerfonVelocityDownToThreshold: Velocity dropped below the safe limit; resume image loading.
HwPerfonVelocityUpToThreshold: Velocity exceeds the limit; pause loading to save frames.

The Fling Curve (Framework Layer)

In Huawei’s modified OverScroller.java, we can see custom logic for distance and velocity calculations when specific vendor flags are set.

This results in a scroll feel that is closer to iOS—where the list takes a long time to come to a very gradual halt—rather than the “abrupt stop” often seen in vanilla Android.

Handling Other Manufacturers

If the app detects it’s not on a Huawei device (HwPerfUtil.a returns false), it falls back to a global server-side feature flag: feed_scroll_loadimage_enable. While this allows other phones to load images during scroll, it often lacks the “velocity-aware” precision and smooth fling curves provided by the Huawei SDK.

The “Scroll-to-Click” Challenge

One side effect of a long, “soft” fling curve (like iOS or optimized Huawei) is that the list stays in the FLING state for much longer. In standard Android, clicking an item while it’s flinging will stop the list but won’t trigger the item’s onClick event. The user has to click twice: once to stop, once to open.

This requires a delicate balance. If the fling is too long, it becomes an annoyance. Modern implementations (like MIUI 12 or optimized Huawei firmware) allow “click-through” logic where if the velocity is very low (e.g., the last 5% of the scroll), a tap will both stop the list and trigger the item action simultaneously.

Extended Reading

Performance Considerations

Why pause loading during fast scrolls?

Efficiency: If a user is flicking through hundreds of posts to find a specific one, loading every intermediate image is a waste of data and battery.
Latency: If 50 images are in the load queue, the one image the user actually stops to look at will have to wait for the previous 49 to finish (or be canceled), leading to “placeholder lag.”

Scroll State Cheat Sheet

For developers using AbsListView.OnScrollListener:

SCROLL_STATE_IDLE: Not moving.
SCROLL_STATE_TOUCH_SCROLL: Finger is touching and moving the list.
SCROLL_STATE_FLING: Finger released; moving by inertia.

Conclusion

This “Weibo + Huawei” collaboration is more than just a marketing gimmick. It’s a pragmatic way to solve the “smoothness vs. data” trade-off. As Android users demand higher fluidity, we can expect more apps to seek these kinds of vendor-level integrations.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

An Incident Caused by a 'Leap' Month - Analysis of Samsung System Reboots

2020-05-25T16:56:05.000Z

Around 1:30 AM on May 23, 2020, a large number of Samsung phone users in China experienced severe issues including freezes, infinite reboots, and forced entries into Recovery Mode. Improper handling by users led to data loss, and the incident quickly became a trending topic on social media platforms like Zhihu, with service centers overwhelmed.

Social media responses ranged from frustration to anger, with some comparing the incident to the Note 7 battery disaster, “charging-gate,” or “green-screen-gate.” Some predicted Samsung would be forced out of the Chinese market. People lost job offers due to missed calls, others lost valuable data, and some even resorted to smashing their devices in frustration.

As an Android developer, I am not here to pile on Samsung. My goal is to uncover the root cause of this incident and see what we can learn from it. Since it’s a technical failure in the Android system, it’s essential to analyze it from a technical perspective.

Even display units in shopping malls were bricked:

Conclusion

For those who prefer the bottom line, here is the summary of the investigation:

The incident was caused by a critical system service repeatedly crashing, which triggered the system’s self-rescue mechanism and forced phones into Recovery Mode. The culprit was Samsung’s SystemUI process, specifically during the initialization of the Always On Display (AOD) plugin. Because AOD is a core part of the system interface, its failure caused SystemUI to crash loop. After a certain number of crashes, Android automatically enters Recovery Mode to protect the device (see image below).

AOD stands for Always On Display, a feature on high-end models that displays the time, weather, and patterns on the screen while the device is locked.

The crash occurred because May 23, 2020, marked the beginning of a “Leap 4th Month” in the Chinese lunar calendar. When AOD tried to render the lunar date, it hit a rare code branch for leap months. This branch attempted to retrieve a string resource called common_date_leap_month. Due to a bug in the build process of specific AOD versions, this field was missing from the resource files. This triggered a FATAL EXCEPTION, causing the process to restart. Upon restarting, it hit the same missing field, crashed again, and ultimately triggered the system’s jump to Recovery Mode.

This explains why the issue was localized to Chinese users: only they required the lunar “Leap” (闰) character to be displayed. It wasn’t the “Year 2000 bug” (Y2K), nor a server hack, nor a malicious move by Samsung. It was a build-time bug that remained hidden until a rare leap month occurred. In such cases, one simply has to admit the failure and apologize sincerely.

Analysis

For interested Android developers, let’s dive deeper into the technical analysis.

For Samsung’s engineers, analyzing this crash was likely trivial—they just needed to pull the logs from their monitoring systems. In fact, the problem was quickly identified and had technically been fixed in newer versions for about six months. However, for outside developers, we need to use a few tools to piece the story together.

1. Starting from the Symptoms

As mentioned, a frequent crash in a persist process triggers a system self-rescue into Recovery Mode. Most user screenshots reflected this:

Some users, however, saw an interface with specific error messages (presumably a custom Samsung diagnostic feature), which provided the essential clues:

This stack trace is all an Android developer needs. During a frame rendering flow, AOD’s LocalDataView failed during initialization. Specifically, the getLunarCalendarInChina method threw an error while trying to find the common_date_leap_month string resource.

The investigation then focused on two points:

The code logic surrounding the common_date_leap_month field.
Why the string field was missing despite being referenced by the code.

2. Code Analysis

To analyze the logic, we need to decompile the AOD APK. A highly recommended tool for this is TTDeDroid.

We can find the AOD APK on sites like APKMirror. Looking at the version history, Samsung updates AOD frequently. Feedback suggests that not all users were affected, and updating to the latest version resolved the issue. This implies the bug resided in older versions (likely around V4.0).

Normal Version (V5.2.05)

The latest version works correctly. The logic in this version is:

1	String month = shouldShowLeapMonth(locale) ? context.getResources().getString(R.string.common_date_leap_month) + months[convertMonth] : months[convertMonth];

If it is a leap month, it fetches common_date_leap_month. A global search reveals this field is correctly defined in this version’s R.java and strings.xml.

This confirms the logic: The code only attempts to access common_date_leap_month when a leap month needs to be displayed. For 99.9% of the time, this code branch is never hit.

Affected Version (V4.1.70)

In the versions that crashed on May 23, a global search for common_date_leap_month shows it is referenced in the code, but there is no corresponding entry in R.java or strings.xml. The code uses the field, but it is neither defined nor assigned a value.

The problematic code matches the stack trace exactly:

private String getLunarCalendarInChina(Context context) {
    if (sSolarLunarConverter == null) {
        sSolarLunarConverter = SECCalendarFeatures.getInstance().getSolarLunarConverter();
        if (sSolarLunarConverter == null) {
            return "";
        }
    }
    Time time = new Time();
    time.set(Calendar.getInstance().getTimeInMillis());
    sSolarLunarConverter.convertSolarToLunar(time.getYear(), time.getMonth(), time.getMonthDay());
    String[] months = context.getResources().getStringArray(R.array.common_LunarMonth);
    String[] days = context.getResources().getStringArray(R.array.common_LunarDay);
    int convertMonth = sSolarLunarConverter.getMonth();
    int convertDay = sSolarLunarConverter.getDay() - 1;
    ACLog.d(TAG, "Lunar month and day : " + convertMonth + ", " + convertDay);
    if (convertMonth < 0 || convertMonth >= months.length || convertDay < 0 || convertDay >= days.length) {
        ACLog.e(TAG, "getLunarCalendarInChina, array out of bound month = " + months.length + ", days = " + days.length);
        return "";
    }
    // The crash happens here because R.string.common_date_leap_month is missing
    String chinaLunar = (sSolarLunarConverter.isLeapMonth() ? context.getResources().getString(R.string.common_date_leap_month) + months[convertMonth] : months[convertMonth]) + days[convertDay];
    return chinaLunar;
}

3. When did the bug appear?

Investigation shows the field disappeared when AOD was upgraded from V3.3.18 to V4.0.57 (October 2018). It remained missing until V4.2.44 was released in June 2019.

Timeline Recap:

October 24, 2018: Bug introduced in V4.0.57.
June 24, 2019: Bug fixed in V4.2.44.

Devices built with and never updated beyond those two dates were silent “time bombs,” waiting for the next leap month on May 23, 2020, to crash.

4. The Build Issue

A critical question remains: How did it compile?
Usually, if you reference R.string.some_field in code without defining it in strings.xml, the compiler will fail immediately.

Possible explanations for this compiled APK existing:

Inter-library conflict: Different versions of the same library were used during compilation versus runtime.
Maven/Dependency Sync: The project used one version of a resource package during compilation, but a different version was packaged into the final APK.

It’s likely the second case: the main project and its sub-modules had mismatched dependencies. The code successfully found the field at compile time from one module, but the field was missing in the resource package included in the final APK, leading to the runtime NoSuchFieldError.

Summary

This incident was a perfect storm: a build-time dependency error meeting a once-in-a-decade lunar leap month.

Lessons Learned:

Feature Testing: Specialized functions like lunar calendars often go untested because they aren’t “daily” features. High-risk, rare-occurrence code paths must be meticulously validated, ideally by subject-matter experts.
Dependency Management: In projects with complex dependencies, ensure absolute consistency between compile-time and runtime environments.
UI Stability: Modules like SystemUI (lock screen, status bar, AOD) and the Launcher are critical to user perception. A failure here is catastrophic. Engineers in these areas must balance innovation with extreme stability.
Updates: Users should be encouraged to stay current with system and core app updates, as these often contain critical fixes that aren’t advertised as flashy features.
Curiosity and Humility: For developers, curiosity helps look past symptoms to find the essence of a bug. Humility reminds us that the Android ecosystem is vast, and our knowledge is but a drop in the ocean.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

Analysis of Android App Chain Wakeups

2020-05-07T15:16:20.000Z

The release of MIUI 12 brought a long-standing battle between App developers and ROM developers into the public eye, revealing the intricate details of this technical tug-of-war. As the saying goes, “While the demon rises a foot, the path rises ten feet.” ROM developers, with their higher system-level permissions, generally hold the upper hand. App developers, however, are not easily deterred, employing various “black technologies” for background persistence and cross-app wakeups. Even Google has stepped in to mediate, establishing rules to regulate behavior for both parties. This competition is arguably healthy; a total victory by either side would inevitably lead to stagnation or the loss of useful functionality.

However, the victims of this struggle are undoubtedly the consumers. If App developers succeed, phones become cluttered with persistent background processes that hog CPU and memory. Conversely, if ROM developers are too aggressive, the app experience suffer—a pain well-known to many Android developers.

As discussed later in this article, most smartphone manufacturers have developed their own strategies to handle auto-starts and associated starts. Beyond the technical struggle, there’s the issue of privacy. Baidu’s Robin Li once remarked that “Chinese people are more open about privacy and relatively less sensitive. If they can trade privacy for convenience, safety, or efficiency, they are willing to do so in many cases.” Consider the convenience of copying a phrase in WeChat and having Taobao automatically open to the corresponding item. It’s helpful, isn’t it? But do we really want every app peering into our clipboards?

Privacy should not be dismissed lightly. Technology is a double-edged sword. If privacy falls into the wrong hands, the consequences can be severe. This is exactly why the EU implemented the General Data Protection Regulation (GDPR). For example, many domestic manufacturers now differentiate their products for the EU market, disabling various data collection features to avoid massive fines. In other markets, data collection often remains unchecked.

This article does not delve into the ethics of privacy—I unconditionally support privacy protection. Instead, I will analyze the technical aspects of “Auto-start” and “Chain Wakeup” as highlighted by MIUI 12.

Note: You may not see some of these behaviors on your own phone because I am using AOSP code based on Android 10. Most domestic ROMs have already blocked these activities.

Technical Terminology Explained

First, let’s define a few key terms to establish a common understanding.

Process Startup

In Android, an app is composed of six potential parts: the Process (Mandatory), Activity (Optional), BroadcastReceiver (Optional), Service (Optional), ContentProvider (Optional), and Sub-processes (Optional).

While the last four are the well-known “Four Major Components,” they are special because each can be started independently. However, before any component starts, the system checks if its corresponding process exists. If not, the system must first launch the process before starting the component. When you tap an app icon on the home screen, you are launching an Activity. The system creates the process, starts the Activity, and then you see the interface.

Typically, auto-starts and chain wakeups avoid launching Activities because they are visible to the user. Mysteriously popping up a window from the background is a quick way to get uninstalled. Instead, these “silent” startups usually target BroadcastReceiver, Service, or ContentProvider.

Auto-start (Self-starting)

Auto-start refers to an app launching its own process without the help of other apps, typically by listening for system events (like booting or network changes) or file modifications using system mechanisms.

Associated Start (Link-starting / Chain Wakeup)

This involves one app leveraging another to launch itself. For example, opening a reading app might trigger the background launch of a writer’s assistant, a telecom app, or a language learning tool.

Startup Blocking

Also known as “Wakeup Interception,” ROM developers insert logic at the component startup point. Only components meeting specific criteria are allowed to launch their process. If the criteria aren’t met, the request is discarded, effectively blocking the startup.

This is a delicate task. ROM developers must judge work states and the “reasonableness” of a launch. Incorrect blocking can break legitimate user flows—for instance, if a user attempts to pay via Alipay from within another app but the ROM blocks Alipay’s payment component, the resulting UX failure will surely frustrate the user.

Analysis Methods

Monkey

To analyze app startups, you need to install a large number of apps and run Monkey to force most processes into action. The command I used is:

1	adb shell monkey --kill-process-after-error --ignore-security-exceptions --ignore-crashes --pct-appswitch 90 --pct-touch 10 --throttle 10000 --ignore-timeouts --ignore-native-crashes 100000000

EventLog

EventLog provides a truthful record of process starts and deaths. I use the following filter:

1	adb logcat -b events \| egrep "am_proc_died\|am_proc_start"

Dumpsys

dumpsys activity is invaluable for analyzing the details of a process’s components.

1	adb shell dumpsys activity

Technical Analysis of Auto-starts

Auto-starts rely on system mechanisms to wake up a process. Common events include booting, network changes, and media library scans.

Boot Completed

After a phone restarts, the system broadcasts a “Boot Completed” signal to all apps registered for it. These apps can then wake themselves up to start background tasks (or launch even more processes). The broadcast is:

1	android.intent.action.BOOT_COMPLETED

Apps use this to continue tasks like photo backups, contact syncing, checking for updates, or pushing news. This is a primary method for auto-starting.

Case Study: Tencent News

In the logs, com.tencent.news.system.BootBroadcastReceiver received the BOOT_COMPLETED broadcast and spent 7 seconds processing it. To do this, the system first had to launch the com.tencent.news process to execute the onReceive method. This is a classic auto-start case.

Network Changes

This includes connecting/disconnecting to the internet or switching between Wi-Fi and mobile data. The broadcast is:

1	android.net.conn.CONNECTIVITY_CHANGE

Apps listen to this to adjust behavior—for example, a live streaming app might warn a user if they switch from Wi-Fi to 4G to prevent data overages. However, it is also frequently used for silent auto-starts.

Examples

Here are some broadcast receivers triggered by network changes (there were over 200 in my test):

DingTalk (com.alibaba.android.rimet): com.xiaomi.push.service.receivers.NetworkStatusReceiver
Learning Strong Nation (cn.xuexi.android): com.xiaomi.push.service.receivers.NetworkStatusReceiver
Weibo (com.sina.weibo): com.xiaomi.push.service.receivers.NetworkStatusReceiver
DiDi (com.sdu.didi.psnger): com.didi.sdk.push.PushNetReceiver
Inke (com.meelive.ingkee): com.network_optimization.NetWorkStateReceiver

Other similar broadcasts include android.net.wifi.STATE_CHANGE:

Media Library Scanning

The system notifies apps when files change or storage is mounted.

1
2
3

android.intent.action.MEDIA_SCANNER_STARTED
android.intent.action.MEDIA_SCANNER_FINISHED
android.intent.action.MEDIA_EJECT

Case Study: JD Finance

com.jd.jrapp.library.longconnection.receiver.BootReceiver listens for MEDIA_SCANNER_STARTED to trigger a process launch.

Third-Party SDKs (e.g., GeTui)

GeTui is a popular push notification SDK. It integrates multiple auto-start methods, including BOOT_COMPLETED, CONNECTIVITY_CHANGE, and USER_PRESENT. Developers often customize a service inheriting from com.igexin.sdk.PushService. Using :pushservice as a process name suffix is a common indicator.

Looking at GeTui’s configuration documentation:

<service
    android:name="com.igexin.sdk.PushService"
    android:permission="android.permission.BIND_JOB_SERVICE"
    android:exported="false"
    android:label="NotificationCenter"
    android:process=":pushservice"/>
<receiver android:name="com.igexin.sdk.PushReceiver" >
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
        <action android:name="android.intent.action.USER_PRESENT" />
        
        <action android:name="android.intent.action.MEDIA_MOUNTED" />
        <action android:name="android.intent.action.ACTION_POWER_CONNECTED" />
        <action android:name="android.intent.action.ACTION_POWER_DISCONNECTED" />
    intent-filter>
receiver>

Technical Analysis of Associated Starts (Chain Wakeups)

Associated starts occur when multiple apps use the same SDK. When you launch one app, that SDK can then launch other apps that use it. This happens within large app families (like those of BAT) or through shared third-party SDKs like JPush.

Let’s look at an EventLog entry:

1	[0,19428,10195,com.qq.reader,service,{com.qq.reader/cn.jpush.android.service.DaemonService}]

Process Started: com.qq.reader (QQ Reader)
PID: 19428
Component: cn.jpush.android.service.DaemonService
Type: Service

Case Study: Qidian Launching QQ Reader via JPush

After forcing QQ Reader to stop, I observed the EventLog. QQ Reader’s process was awakened by the launch of the DaemonService component. While EventLog doesn’t show who requested the launch, dumpsys activity reveals the caller in the ServiceRecord‘s Connections field: it was com.qidian.QDReader:pushcore.

Xiaomi’s MIUI 12 would display this as: “Qidian Reading launched QQ Reader at 8:48 AM.” JPush’s official documentation explicitly provides features for waking up other apps and being awakened by them.

JPush Wakeup Configuration

OEM Responses

Process management is the most contested area in Android. MIUI chose to show this battle to users, but other manufacturers do the same quietly behind the scenes. Without these controls, phones would be unusable. On my test Pixel, processes are constantly killed by the Low Memory Killer (LMK) due to low RAM, only to be immediately restarted, draining the battery and causing severe lag.

The official documentation for push SDKs often lists the settings paths for various OEMs. It’s worth checking these lists to remove apps from white-lists that you don’t want running in the background.

GeTui White-list Configurations

EMUI OS (Huawei)

Auto-start Management: Apps must be added to the “Auto-start” list, or they won’t launch after being killed or at boot.
Background App Protection: Apps must be manually added to this list to survive device sleep.
Notification Management: Settings include Prompt, Allow, and Prohibit.

Flyme OS (Meizu)

Auto-start Management: Requires manual inclusion in the list.
Notification Push: Disabling notifications hides all messages.

Funtouch OS (VIVO)

Auto-start Management: Managed via “iManager.” Force-killing an app manually prevents auto-restart even if it’s on the list.

Color OS (OPPO)

Frozen App Management: Apps must be added to “Pure Background” to receive messages during lock screen.
Auto-start Management: Requires inclusion in the list and “locking” the process in the recent apps/running view.

MIUI OS (Xiaomi)

Auto-start Management: Requires manual inclusion.
Battery Saver: Must be disabled for the app, or network access will be restricted after a few minutes in the background.

About Me && Blog

Below are my personal details and links. I look forward to connecting and sharing knowledge with fellow developers!

About Me: Includes my WeChat and WeChat group links.
Blog Navigation: A guide to the content on this blog.
Curated Android Performance Articles: A collection of must-read performance optimization articles. Self-nominations/recommendations are welcome!
Android Performance Knowledge Planet: Join our community for more insights.

“If you want to go fast, go alone. If you want to go far, go together.”

Android Systrace Basics - SurfaceFlinger Explained

2020-02-14T02:25:45.000Z

This is the fifth article in the Systrace series, primarily providing a brief introduction to the workflow of SurfaceFlinger. It covers several important threads within SurfaceFlinger, including Vsync signal interpretation, app buffer display, and jank detection. Since Vsync has already been covered in Systrace Basics - Vsync Explained and Detailed Explanation of Android Rendering Mechanism Based on Choreographer, it won’t be discussed in detail here.

The purpose of this series is to view the overall operation of the Android system from a different perspective using Systrace, while also providing an alternative angle for learning the Framework. Perhaps you’ve read many articles about the Framework but can never remember the code, or you’re unclear about the execution flow. Maybe from Systrace’s graphical perspective, you can gain a deeper understanding.

Series Article Index
Main Content
App Section
BufferQueue Section
SurfaceFlinger Section
HWComposer Section
References
About Me && Blog

Series Article Index

Main Content

Here is the official definition of SurfaceFlinger:

Most apps display three layers on the screen: a status bar at the top, a navigation bar at the bottom or side, and the app interface itself. Some apps may have more or fewer layers (e.g., the default home screen app has a dedicated wallpaper layer, while a fullscreen game might hide the status bar). Each layer can be updated independently. The status bar and navigation bar are rendered by system processes, while the app layer is rendered by the app, with no coordination between them.
Device displays refresh at a fixed rate, typically 60 fps on phones and tablets. If content updates during a refresh, tearing occurs; therefore, it’s essential to update content only between cycles. The system receives a signal from the display device when it’s safe to update content. For historical reasons, we call this the VSYNC signal.
Refresh rates may change over time; for example, some mobile devices range between 58 fps and 62 fps depending on current conditions. For HDMI-connected TVs, the rate can theoretically drop to 24 Hz or 48 Hz to match video. Since each refresh cycle can only update the screen once, submitting buffers at 200 fps is wasteful as most frames will be discarded. SurfaceFlinger doesn’t act every time an app submits a buffer; instead, it wakes up only when the display device is ready for a new buffer.
When a VSYNC signal arrives, SurfaceFlinger traverses its layer list searching for new buffers. If found, it acquires them; otherwise, it continues using previously acquired buffers. SurfaceFlinger must always display content, so it retains one buffer. If a layer lacks a submitted buffer, it is ignored.
After collecting all buffers for visible layers, SurfaceFlinger consults the Hardware Composer on how to perform composition.

— Cited from SurfaceFlinger and Hardware Composer

Below is the flowchart corresponding to this process. Simply put, SurfaceFlinger‘s primary function is: it accepts data buffers from multiple sources, composites them, and sends them to the display device.

In Systrace, we focus on the parts corresponding to this diagram:

App Section
BufferQueue Section
SurfaceFlinger Section
HWComposer Section

These four parts appear in Systrace in chronological order: 1, 2, 3, then 4. Let’s examine the rendering flow from these four perspectives.

App Section

The App section is detailed in Systrace Basics - MainThread and RenderThread Explained. The primary flow is shown below:

From SurfaceFlinger‘s perspective, the App section is responsible for producing the Surfaces needed for composition.

The interaction between an App and SurfaceFlinger centers on three points:

Vsync signal reception and processing.
RenderThread‘s dequeueBuffer.
RenderThread‘s queueBuffer.

Vsync Signal Reception and Processing

This is covered in Android Based on Choreographer Rendering Mechanism Explained. The first item in the diagram marks the Vsync-App signal arriving from SurfaceFlinger. Upon receiving this, the app begins preparing its frame.

RenderThread’s dequeueBuffer

dequeueBuffer means requesting a buffer from the BufferQueue within SurfaceFlinger. Before rendering begins, the app makes a Binder call to obtain a buffer:

App-side Systrace:

SurfaceFlinger-side Systrace:

RenderThread’s queueBuffer

queueBuffer puts the buffer back into the BufferQueue after the app finishes processing (writing drawcalls). This follows the eglSwapBuffersWithDamageKHR -> queueBuffer flow:

App-side Systrace:

SurfaceFlinger-side Systrace:

Through these three parts, you should have a clear understanding of the flow depicted below:

BufferQueue Section

BufferQueue is discussed in Systrace Basics - Triple Buffer Explained. Each process with a display interface has a corresponding BufferQueue. The consumer creates and owns the data structure, which can exist in a different process from the producer. The flow is:

In this example, the App is the producer (filling buffers), and SurfaceFlinger is the consumer (compositing buffers).

dequeue (initiated by producer): When the producer needs a buffer, it calls dequeueBuffer(), specifying width, height, pixel format, and flags.
queue (initiated by producer): After filling the buffer, the producer calls queueBuffer() to return it to the queue.
acquire (initiated by consumer): The consumer calls acquireBuffer() to take the buffer and use its content.
release (initiated by consumer): Once finished, the consumer calls releaseBuffer() to return the buffer to the queue.

SurfaceFlinger Section

Workflow

As mentioned, SurfaceFlinger‘s main job is composition:

When a VSYNC signal arrives, SurfaceFlinger traverses its layer list searching for new buffers. If found, it acquires them; otherwise, it continues using previously acquired buffers… It then asks the Hardware Composer how to perform composition.

In Systrace, the main thread starts working upon receiving the Vsync signal:

The corresponding code handles two main messages:

MessageQueue::INVALIDATE — executes handleMessageTransaction and handleMessageInvalidate.
MessageQueue::REFRESH — executes handleMessageRefresh.

frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp

void SurfaceFlinger::onMessageReceived(int32_t what) NO_THREAD_SAFETY_ANALYSIS {
    ATRACE_CALL();
    switch (what) {
        case MessageQueue::INVALIDATE: {
            ......
            bool refreshNeeded = handleMessageTransaction();
            refreshNeeded |= handleMessageInvalidate();
            ......
            break;
        }
        case MessageQueue::REFRESH: {
            handleMessageRefresh();
            break;
        }
    }
}

// handleMessageInvalidate implementation:
bool SurfaceFlinger::handleMessageInvalidate() {
    ATRACE_CALL();
    bool refreshNeeded = handlePageFlip();

    if (mVisibleRegionsDirty) {
        computeLayerBounds();
        if (mTracingEnabled) {
            mTracing.notify("visibleRegionsDirty");
        }
    }

    for (auto& layer : mLayersPendingRefresh) {
        Region visibleReg;
        visibleReg.set(layer->getScreenBounds());
        invalidateLayerStack(layer, visibleReg);
    }
    mLayersPendingRefresh.clear();
    return refreshNeeded;
}

// handleMessageRefresh implementation; most SF work starts here:
void SurfaceFlinger::handleMessageRefresh() {
    ATRACE_CALL();

    mRefreshPending = false;

    const bool repaintEverything = mRepaintEverything.exchange(false);
    preComposition();
    rebuildLayerStacks();
    calculateWorkingSet();
    for (const auto& [token, display] : mDisplays) {
        beginFrame(display);
        prepareFrame(display);
        doDebugFlashRegions(display, repaintEverything);
        doComposition(display, repaintEverything);
    }

    logLayerStats();

    postFrame();
    postComposition();

    mHadClientComposition = false;
    mHadDeviceComposition = false;
    for (const auto& [token, displayDevice] : mDisplays) {
        auto display = displayDevice->getCompositionDisplay();
        const auto displayId = display->getId();
        mHadClientComposition =
                mHadClientComposition || getHwComposer().hasClientComposition(displayId);
        mHadDeviceComposition =
                mHadDeviceComposition || getHwComposer().hasDeviceComposition(displayId);
    }

    mVsyncModulator.onRefreshed(mHadClientComposition);

    mLayersWithQueuedFrames.clear();
}

Major functional categories in handleMessageRefresh:

Preparation
1. preComposition()
2. rebuildLayerStacks()
3. calculateWorkingSet()
Composition
1. beginFrame(display)
2. prepareFrame(display)
3. doDebugFlashRegions(display, repaintEverything)
4. doComposition(display, repaintEverything)
Cleanup
1. logLayerStats()
2. postFrame()
3. postComposition()

Given the display system’s complexity, we won’t cover every detail. If your work involves this area, familiarize yourself with all flows; otherwise, understanding the high-level logic is enough.

Dropped Frames (Jank)

To determine if an app is dropping frames in Systrace, look at SurfaceFlinger:

Does the SurfaceFlinger main thread skip composition at each Vsync-SF?
If it skips, find the reason:
1. No available buffers?
2. Occuppied by other tasks (screenshot, HWC, etc.)?
3. Waiting for presentFence?
4. Waiting for GPU fence?
If composition occurs, check if your app’s available buffer count is normal. If it’s 0, investigate why the app didn’t queueBuffer in time (likely an app-side issue), as the composition might have been triggered by other processes having available buffers.

For more details on reading this in Systrace, see Systrace Basics - Triple Buffer Explained - Jank Detection.

HWComposer Section

Refer to the official introduction for Hardware Composer HAL (HWC):

HWC determines the most efficient way to composite buffers using available hardware. As a HAL, its implementation is device-specific and typically provided by the display hardware OEM.
Overlay planes composite multiple buffers in hardware rather than the GPU. For example, a portrait phone screen with a status bar, navigation bar, and app content can use:
1. Render app content to a temporary buffer, then render the status and navigation bars on top, then send that buffer to display hardware.
2. Send all three buffers to display hardware and instruct it to read different screen parts from different buffers. This is significantly more efficient.
Display processor capabilities vary. HWC performs these calculations to achieve optimal performance:
1. SurfaceFlinger provides a layer list and asks, “How do you want to handle these?”
2. HWC marks each layer as either an overlay or GLES composition.
3. SurfaceFlinger handles GLES composition, sends the output buffer to HWC, and lets HWC handle the rest.
When screen content doesn’t change, overlays can be less efficient than GL composition, especially with transparent pixels. HWC may opt for GLES composition in such cases to save battery during idle.
Android 4.4+ devices typically support 4 overlay planes. Exceeding this triggers GLES composition for some layers, significantly affecting energy and performance.

— Cited from SurfaceFlinger and Hardware Composer

Continuing with the SurfaceFlinger main thread, here is the communication with HWC (step 3 above):

This corresponds to the latter part of the earlier diagram:

Details are extensive. HWC’s performance critical; issues like insufficient performance or slow interrupts can cause jank, as noted in Overview of Jank Causes in Android - System Side.

For more HWC knowledge, see Android P Display System (1): Hardware Composition HWC2 and the related series.

References

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Developer Learning Path (2020 Edition)

2020-02-02T16:06:25.000Z

On Medium, @MindOrks published a 2020 Android Developer Learning Path. Given that some readers may have difficulty accessing the original content, I am sharing it here combined with my own 2020 learning plan for your reference.

The original article is quite simple, mostly listing knowledge points without much explanation. I have added brief introductions for each point and included some additional topics based on my own understanding. This is for your reference only.

This article is primarily for Android developers. If you are a beginner, it will help you find a learning path. If you are an experienced developer, it can help you identify gaps in your knowledge. If you have any other suggestions, feel free to leave a message.

Programming

Java

Java is the default language for Android App development and the Android Framework. Mastering Java is a mandatory skill for Android developers.

For those who want to dive deeper into the Java Virtual Machine, I recommend:

Zhou Zhiming’s “Understanding the Java Virtual Machine (3rd Edition)”
Deng Fanheng’s “Understanding Android Java VM: ART”

Kotlin

Google shifted to a “Kotlin First” strategy several years ago. Most official documentation and demos now use Kotlin by default. Its importance is self-evident.

Google also provides a “Refactoring to Kotlin” tutorial:

This codelab is for any developer who uses Java and is considering migrating their project to Kotlin. We will start with several Java classes and guide you through converting them to Kotlin using the IDE. Then, we look at the converted code and research how to improve it, make it more idiomatic, and avoid common pitfalls.

Flutter

As Google’s “favorite son,” Flutter receives significant official support. Flutter recently released v1.12.13_hotfix.7, which fixed several critical bugs. As mentioned in Flutter 1.12 latest hotfix and 2020 Roadmap: “The v1.12.13+hotfix.7 release mainly resolves three major issues: reportFullyDrawn exception, crashes on Huawei phones, and cursor/keyboard input anomalies.” You can also check out their 2020 Roadmap released on January 30th.

For the development of Flutter, you can refer to Gityuan’s Flutter Cross-Platform Evolution and Architecture. Currently, several Bytedance apps have integrated Flutter for hybrid development. Personally, I believe it’s no longer a time to wait and see on Flutter in 2020; readers can decide whether to start learning based on their own technical plans.

Android Studio

Android Studio IDE Overview

As the default Android development tool, recent updates have resolved many performance issues. While hardware requirements remain high, it is a very powerful tool once you get used to it.

Key areas to master:

AS Shortcuts
AS Plugins
AS Profiler (Memory, CPU, IO, Network)

Project Structure — Java/Kotlin/Flutter, XML, .gradle files

Familiarize yourself with project directory structures, resource files, and Gradle files.

Android Basics

Core Components

These are the foundations of Android development:

Activity — Activity Lifecycle, Tasks & Back Stack
Service
Broadcast Receiver
Content Provider

Intents

Types of Intent - Implicit, Explicit
Intent Filter

Static User Interface

View — Button, ImageView, TextView, EditText, etc.: Common components used to build complex layouts.
ViewGroup - LinearLayout, RelativeLayout, FrameLayout: The three traditional layouts.
ConstraintLayout: Google’s recommended layout, which has largely replaced RelativeLayout as the default for apps. Refer to the Official Documentation.

Dynamic User Interface

RecyclerView - The preferred widget for lists, offering better performance and more features than ListView.
ViewPager
Spinner

CustomView

When default layouts don’t meet design requirements, you need to customize Views. Master the following:

Canvas
Bitmap
Paint

UI Resources

Using resource files instead of hardcoding improves maintainability.

Drawables
Strings
Styles

Fragments

Many advocate for a Single Activity + Multiple Fragments architecture. Managing Fragments is an art in itself, and you’ll encounter various “gotchas” in practice.

Fragment Lifecycle
Fragment Manager

Support User Interface

Common functional components:

ProgressBar
Dialogs
Toast & Snackbar

Storage

App development inevitably involves file handling.

Shared Preferences - Best for key-value pairs.
File Systems - File-based storage.
Database — RoomDB - Google’s recommended database solution (part of AndroidX). Refer to the Official Documentation.

Build

Android apps use Gradle by default. Familiarize yourself with Gradle, build configurations (Debug/Release), multi-channel packaging, and bytecode manipulation tools like ASM.

Gradle
Debug / Release Configuration
Multi-channel Packaging
ASM

Threading

Understanding Threading is crucial. Efficiently switching between the main thread and worker threads is key.

Threads
Handler / Looper / Message / MessageQueue
AIDL / Binder (for inter-process communication)

Debugging

Essential debugging tools and techniques:

Memory profiling - MAT, AS Memory Profiler
Logging - Logs provide rich information to reconstruct issues.
Systrace - A tool to view the running state of system processes. Refer to my Systrace Series.
Exceptions - Handling various exceptions to ensure robustness.
Error Handling - Resolving Errors that cause app crashes.

Memory Leak

A major topic involving both Java and Native memory leaks. Java leaks are generally easier to detect and fix with tools like LeakCanary or Matrix, while Native leaks can be more challenging.

Detecting and Fixing Memory Leaks
Context - Improper use of Context is a common cause of leaks.
Native Memory Leaks

3rd Party Libraries

Classic libraries that significantly save development time:

Image Loading - Glide, Picasso
Dependency Injection - Dagger
Networking - Retrofit, OkHttp
MultiThreading - RxJava, Coroutines

Data Formats

Common data serialization formats:

JSON — GSON, Moshi
FlatBuffers
Protocol Buffers (Protobuf)

Android Jetpack

Jetpack is a suite of libraries, tools, and guidance to help developers write high-quality apps more easily.

Foundation Components — AppCompat, Android KTX, Multidex
Architecture Components — LiveData, ViewModel, DataBinding, Paging, WorkManager, Navigation
Behavior Components - DownloadManager, MediaPlayback, Notifications, Permissions, Preferences, Sharing, Slices
UI Components - Animation & Transition, Emoji, Palette

Architecture

Understand the common architectural patterns and choose what fits your project:

MVVM - Model-View-ViewModel, separates UI state and logic.
MVI - Model-View-Intent.
MVP - Model-View-Presenter, where the Presenter handles logic and the Model provides data.

Testing

Local Unit Testing
Instrumentation Testing

Firebase

Useful for global apps:

FCM (Firebase Cloud Messaging)
Crashlytics
Analytics
Remote Config
App Indexing
Dynamic Links

Security

Security is paramount, especially regarding user data.

Encryption / Decryption
Proguard
R8

App Release

.keystore files
App Bundle
Play Store
Multi-channel Packaging
Pluginization

Keep Learning and Improving

As an aspiring Android developer, having your own technical stack and roadmap is vital for competitiveness. Set clear goals for 2020. Keep Learning and Improving!

If you are looking for better time management, I recommend this video on How I Make Weekly Plans | Productivity | My Method.

“Plan ahead, or fail.” Annual plans are too long, and daily plans are too short. Managing time by the week is often the most practical way to maintain consistency over the long term.

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

My 2020 Reading List

2020-01-28T11:06:29.000Z

Below is my 2020 reading list. Everything recorded here has been finished - technical books are not included since it’s hard to define when they’re “finished.”

I prefer reading history-related books. Among them, The Siege of Kaifeng was very uncomfortable to read - the weak have no diplomacy, it’s truly realistic; Bad Kids lives up to its name, personally I feel it’s much better than the TV series; Rework 2 and Rework 3 are work-related, covering remote work and work methods, consistent with the 2020 trend of working from home - recommended for white-collar programmers; My Last Diet Book systematically and professionally discusses weight loss knowledge, very useful for someone like me who’s trying to lose weight; finally, Blades of the Guardians is already a classic in Chinese comics - I’ll definitely buy a physical set for collection once it’s complete (same for Attack on Titan).

Didn’t read much in 2020. Need to invest more in this area in 2021. Read + Record + Summarize - reading notes will be added later.

Current Reading List:

Lessons from Ming Dynasty History
The Siege of Kaifeng: Diplomacy, War, and People in Late Northern Song
Android Efficient Progress: From Data to AI
A Turbulent Hundred Years
Remote: More Simple and Efficient Remote Work
Shark’s Fin and Sichuan Pepper
Rework 2
Born a Crime
Low IQ Crime
Rework 3
The Long Night
Bad Kids
Fifteen Days Between Two Capitals
Permanent Record
My Last Diet Book
Blades of the Guardians
Journey Through the Middle East

Lessons from Ming Dynasty History

First, let me introduce the author, so readers can have some context:

Wu Han, original name Wu Chunhan, courtesy name Chenbo. Historian and educator. From Yiwu, Zhejiang. Joined the Communist Party of China in 1957. Graduated from Tsinghua University in 1934. Later served as professor at Yunnan University, Southwest Associated University, and Tsinghua University, where he was department head and dean of the School of Liberal Arts. In 1943, he joined the China Democratic League and was actively involved in the democracy movement. After the founding of the PRC, he successively served as Deputy Mayor of Beijing, Vice Chairman of the 1st through 4th Beijing CPPCC, and member of the Philosophy and Social Sciences Division of the Chinese Academy of Sciences. Elected Vice Chairman of the Central Committee of the China Democratic League in 1958. Was a deputy to the 1st through 3rd National People’s Congress, member of the 1st National CPPCC, and standing committee member of the 2nd and 3rd National CPPCC. His life’s work was research on Chinese-Canadian ancient history, with particular achievements in Ming Dynasty history. Authored “Biography of Zhu Yuanzhang” and the historical play “Hai Rui Dismissed from Office.” After the “Cultural Revolution” began, Wu Han was brutally persecuted both mentally and physically. He was arrested and imprisoned in March 1968 and persecuted to death on October 11, 1969. His unjust case was only vindicated after the “Cultural Revolution” ended.

This “Lessons from Ming Dynasty History” is a collection of essays covering Zhu Yuanzhang’s ruling methods, internal contradictions of the ruling class, the Eastern and Western Depots and Jinyiwei, civilian life, factional strife, peasants, slaves and mutinies, the official class, bandits, etc. If “Those Things in the Ming Dynasty” tells the stories of great figures throughout the dynasty, this book takes us from another angle to understand the various chaotic phenomena from the ruling class to the ruled class in the Ming Dynasty. Many chapters are independent yet interconnected. It can be said that the internal troubles and external threats of the late Ming period were not simply the Qing invasion and the rise of bandits - the dynasty had rotted from top to bottom, and one or two people couldn’t save it.

This book is available on WeRead, recommended.

The Siege of Kaifeng: Diplomacy, War, and People in Late Northern Song

You’ve surely heard of the “Shame of Jingkang.” This book details the causes and consequences of the Jingkang Incident. Honestly, I didn’t have a detailed understanding of this period of history before reading it. After reading, I felt that calling it the “Shame of Jingkang” is absolutely right - especially how the army collapsed at first contact, the treachery in negotiations, and the repeated plundering of the capital Kaifeng during the siege that lasted most of a year. Reading it made me both angry and helpless. Without strength, you will be bullied - this eternal truth has been proven repeatedly throughout history. It only took three years from prosperity to destruction… There’s a passage in the book I really like: “It reminds us to be vigilant in peacetime. At any moment, crisis and prosperity are just one step apart. Peace is not inevitable - it requires us to view the world with humility, learning from the world’s strengths while avoiding arrogance and pride. More importantly, we must consciously avoid war. Humility is not wrong - misjudging the situation is the most terrifying thing, because all situations are interconnected. Once you take the first step, you cannot turn back, nor can you control the future direction.“

This book traces the complete historical details of the Jingkang Incident at the end of Northern Song, narrating the peace and war among Song, Liao, and Jin, focusing on the critical moments of the great historical turning point of Northern Song, and the causes and consequences of the comprehensive eruption of crisis from within and without the empire. During the Xuanhe years of Northern Song, the empire appeared prosperous, but hidden dangers lurked beneath the prosperity. Internal crises such as fiscal difficulties, military ailments, and vicious factional strife, combined with external crises like military threats from Liao and Jin in the north, gradually put the empire in a precarious situation. To “recover” the Sixteen Prefectures of Yan and Yun as a strategic buffer, Emperor Huizong decided to ally with Jin to destroy Liao. Although the Song-Jin alliance gradually consumed Liao, Jin saw through Northern Song’s weakness, and combined with complex interest disputes between the two countries, Jin turned south to attack Song. In the first year of Jingkang (1126), Jin’s army besieged Kaifeng for the second time, and the city fell in November. Northern Song collapsed, taking only three years from prosperity to destruction. Based on historical records considering the positions of Song, Liao, and Jin, the author uses accessible narrative style to recreate the historical process of the Jingkang Incident, exploring the deep causes behind Northern Song’s rise and fall, and its timeless significance as a mirror.

This book is available on WeRead, recommended.

Android Efficient Progress: From Data to AI

“Android Efficient Progress: From Data to AI” is a book combining Android advanced technology with practical application, organized into 3 main areas. First, Android engineering system practice and advancement, including mobile data technology, tool infrastructure advancement, efficiency advancement, as well as tool application advancement and engineering construction advancement; second, exploration of current mobile frontend technologies, including container technology, large frontend technology, and AI technology; third, mobile application security attack and defense technology and advanced design pattern practice. The book is comprehensive, focusing on practical experience and advanced skills. Through this book, you can not only learn the latest mobile technologies and knowledge combining advanced technology with practical applications, but more importantly, comprehend the author’s spirit of technical research and thinking methods, helping Android developers progress efficiently.

“Android Efficient Progress: From Data to AI” is suitable for mobile application developers, Android system developers, Android system security engineers, and mobile technology leaders in the Android field.

From the book’s content, the author is an experienced developer. Many topics have fairly detailed architecture implementations that readers can use to build their own systems. It’s a rare book of experience, available on WeRead.

A Turbulent Hundred Years

Author Wu Xiaobo presents China’s development over the past hundred years from a commercial perspective. The author mentions three phenomena in development: first, the interference of ideological debates on modernization; second, the central authority concept’s catalysis of national commercialism; third, the influence of traditional anti-commerce and official-commerce culture on the emerging entrepreneur class. Sadly, in the multiple economic reform movements after the Westernization Movement, these three themes haunted like ghosts, impossible to shake off.

My personal feeling after reading: national stability is too important for commercial development. China’s political situation in modern times was very unstable, and commercial development always rose and fell with political changes; commerce before the Reform and Opening was basically stagnant. It can be said that China’s commercial and technological development started basically from zero after the Reform and Opening. The gap with the United States, which had over a hundred years of stable development, is enormous. This is my biggest takeaway from this book. Although technology sharing and technological explosion exist, our country still masters too few core technologies.

In these 100+ years, suffering has given us the opportunity to focus and reflect, learning many things. It has allowed the Chinese to carefully examine their experiences and more harshly observe their thousand-year history. Without humiliation, we might not have paid attention at all, still immersed in the illusion of being a great nation.
Since the Opium War of 1840, one phrase has covered all themes, becoming the lifelong ideal of countless patriotic Chinese: “Strong Nation.” The urgency of “Strong Nation” made the country incredibly anxious, sometimes even impatient, willing to take risks before thoroughly investigating a path. At many sensitive critical moments, gradualist thinking was often seen as “reactionary,” and revolutionary upheaval, even bloody violence, became the choice of the entire nation. A hundred years of spring and autumn, with farces, tragedies, and comedies interweaving on stage.
In this 100 years driven by the “Strong Nation Dream,” China’s revival began at a dark and desperate moment of awakening. Commercial evolution has always been an important direction for national progress and national redemption. It is precisely in this process that the emerging entrepreneur class rose as an independent force. Their tortuous fate intertwined with the political changes and national choices of this country, sometimes united, sometimes split, but mostly in a discordant state. Over the past century, China’s economic problems can ultimately be summarized as adjustments in three interest relationships: first, adjustment between government interests and public interests; second, adjustment between central government and local government interests; third, adjustment between wealthy public and poor public interests. As representatives of the wealthy public, the entrepreneur group has never reached principled and constructive consensus in relationships with the government (including central and local), intellectuals, and the poor public. This has become one of the important reasons why Chinese commercial progress is always interrupted by various events.

Remote: A More Simple and Efficient Way of Remote Work

This book is called Remote. The Chinese translation calling it “Rework 2” is a terrible translation.

The authors are the two founders of 37Signals. The book covers all aspects of remote work, including the advantages of remote work, how to collaborate remotely, side effects of remote work, employee management in remote work, and self-management in remote work. The 2020 COVID-19 pandemic made most companies try remote work, and many things mentioned in this book were encountered in actual remote work.

Here are some excerpts to ponder:

What really matters is getting the work done well, not rigidly sticking to work hours.

The luxury of the new era is breaking free from the mental shackle of “enjoy life later” and doing what you love now, alongside work. Why waste time on daydreams like “how wonderful life will be when I retire”? Drawing a line between work and retirement is actually quite arbitrary. Your life no longer needs to follow such rules. You can mix the two together, having both fun and income - designing a better lifestyle that makes work enjoyable, because work isn’t the only thing in life. Those golden handcuffs prevent you from living the life you truly want to live. Break free from that resentment!

When you can’t watch someone all day, the only criterion for judgment is work results. A whole bunch of other trivial standards disappear. You just look at work results. Therefore, you don’t need to ask remote workers “what did you do today” - just say “show me today’s results.”

When meetings become the norm, become essential tools for discussion and debate, used to solve any problem, they’re being abused, and everyone becomes numb. Meetings should be like salt, carefully sprinkled on dishes for flavor, not poured on by the spoonful. Too much salt ruins the dish; too many meetings lower morale and enthusiasm.

If you don’t manage the balance between life and work well, the freedom of remote work becomes slavery. This is possible because when you break free from the 9-to-5 job, you can easily fall into the shackles of working all day.

Remote work lifts the veil, letting people see a fact that has always existed but isn’t always acknowledged or seen: excellent remote workers are simply excellent workers. It’s that simple.

Internal motivation: Programmers write open source software generally because they love doing it, not for money. Money often comes along, but it’s rarely the source of motivation. That is, when you’re solving a particularly interesting, exciting problem, you don’t need managers constantly peering over your shoulder to check if you’re working.
Everything public: Most open source software is coordinated through mailing lists and code tracking systems like GitHub. As long as someone wants to help, they can, because all information is public. You can volunteer to participate, and the person most expert in a particular area can easily jump in.

Shark’s Fin and Sichuan Pepper

Author Fuchsia Dunlop grew up in Oxford and earned a Bachelor’s degree in English Literature from Cambridge University, then obtained a Master’s degree in Chinese Studies with distinction from SOAS, University of London. In 1994, after receiving a British Council scholarship, Fuchsia went to study at Sichuan University for a year; she then received three months of professional chef training at the Sichuan Institute of Higher Cuisine, becoming the first foreign student there.

I originally approached this “Shark’s Fin and Sichuan Pepper” with a relaxed mood. The first half of the book indeed has a very relaxed and pleasant atmosphere, following the author through the streets and alleys of Chengdu looking for home-cooked food, with a recipe for a home-cooked dish after each section. The author’s description of Chengdu life also makes one feel content:

The slow, languid feeling of this place also subtly influences you. In Chengdu, forget about realizing plans - even making plans is completely impossible. Since the Tang Dynasty, this place has been famous for its comfortable and leisurely life. The climate is suitable, and the soil is legendarily fertile. Chengdu people don’t have to work particularly hard to eat well and have fun. The city has a bit of a southern feel, even somewhat Mediterranean. Chengdu people walk slower than Beijing or Shanghai people. They sit in teahouses for an entire afternoon and evening, playing mahjong, playing cards, joking and bickering in the slow-paced, sweet-toned Sichuan dialect with drawn-out vowels and cute erhua endings. They call this “bai long men zhen” - Sichuan’s unique way of chatting about everything. And the most vivid Sichuan phrase is “hao shua” (particularly fun). They say it in a lazy voice, grinning, with bamboo chairs creaking in the background. “Those coastal people,” a taxi driver chatted with me about Cantonese and Fujianese people, “they have big ambitions and work hard, so they got rich first. We Sichuan people, as long as we make enough money to eat well and drink spicy food, that’s enough.”

The dishes described in the book include Chengdu home-cooked dishes, Hong Kong Cantonese cuisine, Hunan cuisine, and Yangzhou Jiangsu-Zhejiang cuisine. However, since the author stayed in Sichuan longer, Sichuan cuisine and Sichuan life appear more frequently. Each region’s cuisine has its own characteristics, and just reading the author’s descriptions, you can almost smell the fragrant aromas.

However, the latter half of the book also discusses food safety issues, eating wild game, eating protected animals, and some things about Chinese officialdom. The more I read, the heavier it became, yet there was nothing I could do. The city is changing, society is changing, people are changing, things are changing. The author came to the greatly changed Chengdu again, recording these changes as an observer:

On one hand, such demolition is truly a tragedy - my personal tragedy: falling in love with a place that is disappearing so rapidly. My research into cooking and food originally intended to record a vibrant city. Only later did I understand that from many perspectives, I was writing the “epitaph” of old Chengdu. I feel this is also a tragedy for Chengdu people, though they don’t realize it. This city was so charming, so unique, now being replaced by a city that exists everywhere in China - a terrible waste, sad and lamentable.

On the other hand, 1990s China seemed to overflow with vitality and optimism. The previous utilitarianism, asceticism, and monotonous blandness disappeared. The whole country was moving, 1.2 billion people united, moving forward together. In England, even demolishing a dilapidated old building would make us sad and distressed. But in Sichuan, they swung hammers all the way, flattening the entire city! This reckless confidence was admirable. They firmly believed the future would be better than the past.

So, even though my heart still ached passing through those leveled streets, I was also stirred and agitated by this vibrant optimism. I too was in an unstable state, my life was also changing. I was tapping into potential creativity, making great friends, slowly shedding skin like a snake.

Born a Crime

You don’t choose where you’re born, but you can choose your life

Because of the Daily Show, I started following Trevor Noah. This book is Trevor Noah’s autobiography. The title is confusing - what does “born a crime” mean? I hadn’t paid much attention to African history before. After reading this book, I learned that “born a crime” refers to the apartheid era in Africa when blacks and whites couldn’t be together, let alone have children. But Trevor is the son of a white father and black mother, so he was born a criminal.

Two major themes run through the article: one is racial segregation, one is racial identity. During white rule in Africa, apartheid was implemented. This segregation wasn’t just segregation of people, but also included language segregation, cultural segregation, ideological segregation, and even segregation between black tribes. The other is racial identity. In local terms, Trevor belongs to the colored race - the kind that wasn’t accepted by either the black community or the white community. Indians and Chinese would also group together. For a child at that time, who to hang out with (gaining acceptance from which group) was very important. From childhood, Trevor was isolated by various groups, but through his mother and knowledge, he found a way to survive among various races and groups, eventually becoming a successful comedian, talk show host, and TV/radio host.

Apartheid represented a police state, a system of laws and surveillance that kept black people under absolute control. If all the laws could be written down and stacked together, it would take over three thousand sheets of paper, weighing up to five kilograms. But the essence of South African apartheid is very easy for Americans to understand. Three things happened in American history: driving Native Americans to reservations, black slavery, and segregation. Imagine these three things happening to the same group of people at the same time - that’s apartheid.

I found my place. Since I didn’t belong to any small circle, I could move between different circles. I was still a chameleon, a cultural chameleon. I knew how to blend in. I could exercise with athletic kids, discuss computers with nerds. I could jump into crowds and dance with small-town boys. I could have brief intersections with everyone, studying together, chatting, telling jokes, delivering food.

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with peers - when three people walk together, there must be a teacher among them!

Blogger’s Personal Introduction: Contains my WeChat and WeChat group links.
Blog Content Navigation: A navigation guide for my blog content.
Personally Curated Excellent Blog Posts - Android Performance Optimization Must-Knows: Recommendations and self-recommendations welcome (just WeChat message me)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for the support~

One person can walk faster, a group can walk further

Android Systrace Basics - CPU Info Interpretation

2019-12-21T07:16:26.000Z

This is the twelfth article in the Systrace series, primarily providing a brief introduction to the CPU information area (Kernel) in Systrace. It covers how to view CPU-related information output by the Kernel module, including CPU frequency, scheduling, frequency locking, and core locking.

Series Article Index
CPU Area Legend
Core Architecture
Core Binding (Pinning)
Frequency Locking
CPU States
Detailed Information in Systrace
References
About Me && Blog

Series Article Index

CPU Area Legend

Below is the CPU Info area in the Kernel of a Systrace captured from a Qualcomm Snapdragon 845 device (we’re focusing on Kernel CPU info here, skipping lower sections).

The CPU Info in Systrace is generally at the top, and commonly used information includes:

CPU frequency changes
Task execution status
Scheduling across large and small cores
CPU Boost scheduling

In general, Kernel CPU Info in Systrace is used to examine task scheduling and determine if frequency or scheduling is causing performance issues for the current task. For example:

A task runs slowly in a certain scenario; was it scheduled to a small core?
A task runs slowly; is the current CPU frequency insufficient?
For special tasks like fingerprint unlocking, can it be pinned to a large core?
For high-CPU-demand scenarios, can we limit the minimum CPU frequency while it’s running?

Detailed explanations related to CPU execution can be found in the article Android Systrace Basics - Prerequisites for Analyzing Systrace.

Core Architecture

Briefly, modern mobile CPUs can be categorized into three types based on core count and architecture:

Non-big.LITTLE architecture
big.LITTLE architecture
Big-Medium-Small core architecture

Most current CPUs use big.LITTLE, while some (like Snapdragon 855/865) use the Big-Medium-Small core architecture. A small number of CPUs use a uniform architecture.

Let’s discuss the differences to help interpret Systrace:

Non-big.LITTLE Architecture

Older devices with dual or quad cores typically had uniform core architectures, meaning all cores were isomorphic—same frequency, same power consumption, enabling or disabling together. Some entry-level Qualcomm processors also use isomorphic octa-core processors, like Snapdragon 636.

Most modern devices no longer use this architecture.

big.LITTLE Architecture

Modern CPUs generally use 8 cores. CPU 0-3 are typically small cores, while CPU 4-7 are large cores, as arranged in Systrace.

Small cores generally have lower clock speeds and power consumption, typically using the ARM A5x series. For example, the Snapdragon 845 small cores consist of four A55 cores (up to 1.8GHz).

Large cores have higher maximum frequencies and power consumption, typically using the ARM A7x series. For example, the Snapdragon 845 large cores consist of four A75 cores (up to 2.8GHz).

Here is the Snapdragon 845 CPU:

Variations exist, such as Snapdragon 636 (4 small + 2 large) or Snapdragon 710 (6 small + 2 large). The principle remains: large cores support high-load scenarios, and small cores handle daily use. Performance depends on the device’s tier; as the saying goes, “you get what you pay for.”

Parameters for mainstream Qualcomm big.LITTLE processors:

Big-Medium-Small Core Architecture

Some CPUs utilize a Big-Medium-Small architecture, such as:

Snapdragon 855: 8 cores (1 x A76 Big + 3 x A76 Medium + 4 x A55 Small)
MTK X30: 10 cores (2 x A73 Big + 4 x A53 Medium + 4 x A35 Small)
Kirin 980: 8 cores (2 x A76 Big + 2 x A76 Medium + 4 x A55 Small)

Compared to big.LITTLE, the “Big” core here is often a “Prime” core (Qualcomm calls it Gold+), usually numbering only 1 or 2. It has very high clock speeds and power consumption, designed for highly demanding tasks.

Comparison of 855, 845, and Kirin 980:

Notably, the Snapdragon 865 continues the Big-Medium-Small architecture, using the A77 architecture for big and medium cores and A55 for small cores. The Prime and medium cores have different maximum frequencies; there is only one Prime core, clocked at 2.8GHz.

Core Binding (Pinning)

Core binding involves pinning a specific task to a certain core or set of cores to meet its performance requirements:

A high-load task needs large cores to meet timing requirements.
A task shouldn’t be frequently context-switched and needs to stay on one core.
An unimportant task with low timing requirements can be restricted to small cores.

In Android, binding is generally handled by the system using three common methods:

Configuring CPUsets

The CPUset subsystem limits specific types of tasks to specific CPUs or CPU groups. Android defines default groups that manufacturers can customize:

system-background: Low-priority tasks, restricted to small cores.
foreground: Foreground processes.
top-app: Processes currently interacting with the user.
background: Background processes.
foreground/boost: Previously used to migrate all foreground processes during app launch; now largely inactive.

CPUset configurations vary by architecture and manufacturer. Here is the Google default:

// Default Official Configuration
write /dev/cpuset/top-app/cpus 0-7
write /dev/cpuset/foreground/cpus 0-7
write /dev/cpuset/foreground/boost/cpus 4-7
write /dev/cpuset/background/cpus 0-7
write /dev/cpuset/system-background/cpus 0-3

// Check your own
adb shell cat /dev/cpuset/top-app/cpus
0-7

You can view tasks in each group via the tasks node:

$ adb shell cat /dev/cpuset/top-app/tasks
1687
1689
1690
3559

Placement is dynamic and can be changed by authorized processes. Some processes are configured at startup, such as lmkd, which places itself in system-background:

service lmkd /system/bin/lmkd
    class core
    user lmkd
    group lmkd system readproc
    capabilities DAC_OVERRIDE KILL IPC_LOCK SYS_NICE SYS_RESOURCE BLOCK_SUSPEND
    critical
    socket lmkd seqpacket 0660 system system
    writepid /dev/cpuset/system-background/tasks

Most App processes change groups dynamically. Detailed definitions are in the Process class:

android/os/Process.java

public static final int THREAD_GROUP_DEFAULT = -1;
public static final int THREAD_GROUP_BG_NONINTERACTIVE = 0;
private static final int THREAD_GROUP_FOREGROUND = 1;
public static final int THREAD_GROUP_SYSTEM = 2;
public static final int THREAD_GROUP_AUDIO_APP = 3;
public static final int THREAD_GROUP_AUDIO_SYS = 4;
public static final int THREAD_GROUP_TOP_APP = 5;
public static final int THREAD_GROUP_RT_APP = 6;
public static final int THREAD_GROUP_RESTRICTED = 7;

OomAdjuster dynamically modifies CPUsets based on process state (check computeOomAdjLocked, updateOomAdjLocked, and applyOomAdjLocked in Android 10).

Configuring Affinity

affinity sets which core a task runs on using the taskset system call.

Usage of taskset

Display CPU for a process:

1	taskset -p pid

The returned value is hexadecimal. When converted to binary, each bit corresponds to a logical CPU (lowest bit is CPU 0). A ‘1’ indicates the process is bound to that CPU. For example, 0101 means binding to CPU 0 and 3.

Binding setup:

1 2	taskset -pc 3 pid # Bind process PID to the 3rd core taskset -c 3 command # Execute command and bind its process to the 3rd core

Android can use this call to pin tasks. Older kernels lacking CPUset support often used taskset.

Scheduling Algorithms

Modifying scheduling logic within the Linux scheduler can also pin tasks to specific cores. Some manufacturers use this for “core scheduling optimization.”

Frequency Locking

Normally, CPU scheduling satisfies daily use, but some Android scenarios require more performance than the default scheduler provides. For app launches, relying solely on the scheduler to ramp up frequency and migrate cores might be too slow. A task might start on a small core, find it insufficient, ramp up frequency, find it still lacking, and eventually migrate through medium to large cores. This process wastes time.

To address this, the system “forcefully” ramps up hardware resources (CPU, GPU, IO, BUS, etc.) to maximum for specific scenarios. Conversely, it might limit resources—for example, capping maximum CPU frequency to cool down a device.

Android typically locks frequencies in these scenarios:

App launches
App installation
Screen rotation
Window animations
List Flinging
Gaming

On Qualcomm platforms, frequency locking is visible in CPU Info:

CPU States

CPU Info also shows CPU states. As seen below, there are states 0, 1, 2, and 3:

While older CPUs supported hot-unplugging (shutting down when idle), modern CPUs use C-States.

Below are power states for a processor supporting C0-C4 (Android performance varies by platform):

C0 State (Active): Max work state, receiving instructions and processing data. Required by all modern processors.
C1 State (Halt): Entered via the HLT instruction. Ultra-fast wakeup (as fast as 10 nanoseconds!). Saves 70% CPU power. Required by all modern processors.
C2 State (Stop-Clock): Processor clock and I/O buffers are stopped. Saves 70% CPU and platform energy. Wakeup takes over 100 nanoseconds.
C3 State (Deep Sleep): Bus clock and PLLs are locked. Cache is invalidated in multi-core systems. In single-core systems, memory is off but cache remains valid. Saves 70% CPU power. Wakeup takes around 50 microseconds.

Detailed Information in Systrace

While Systrace is usually viewed graphically in Chrome, it can be opened as text to see raw details.

Here is a CPU scheduling message:

1	appEventThread-8193 [001] d..2 1638545.400415: sched_switch: prev_comm=appEventThread prev_pid=8193 prev_prio=97 prev_state=S ==> next_comm=swapper/1 next_pid=0 next_prio=120

Breakdown:

appEventThread-8193: TASK-PID identification.
[001]: CPU number (CPU 1 here).
d..2: Four bits for irqs-off, need-resched, hardirq/softirq, and preempt-depth.
1638545.400415: Delay TIMESTAMP.
sched_switch ...: Info area containing previous task description, PID, and priority, and current task info.

Other interesting outputs:

sched_waking: comm=kworker/u16:4 pid=17373 prio=120 target_cpu=003
sched_blocked_reason: pid=17373 iowait=0 caller=rpmh_write_batch+0x638/0x7d0
cpu_idle: state=0 cpu_id=3
softirq_raise: vec=6 [action=TASKLET]
cpu_frequency_limits: min=1555200 max=1785600 cpu_id=0
cpu_frequency_limits: min=710400 max=2419200 cpu_id=4
cpu_frequency_limits: min=825600 max=2841600 cpu_id=7

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

References

Spring Bamboo Shoots

I took a photo and thought it was quite nice, sharing it with everyone.

Android Systrace Basics - Triple Buffer Explained

2019-12-15T15:31:20.000Z

This is the eleventh article in the Systrace series, providing a brief introduction to Triple Buffer within Systrace. It covers how to identify jank in Systrace, perform preliminary localization and analysis, and explains the impact of Triple Buffer on performance.

Series Article Index
How to Define Dropped Frames (Jank)?
BufferQueue and Triple Buffer
The Role of Triple Buffer
Debugging Triple Buffer
References
Attachments
About Me && Blog

Series Article Index

How to Define Dropped Frames (Jank)?

Systrace displays app frame drops. While it’s common to say jank occurs if the main thread exceeds 16.6 ms, this isn’t always true due to Triple Buffer (explained later). Generally, jank in Systrace should be judged by looking at both the App side and the SurfaceFlinger side.

Judging Jank on the App Side

Theoretically, the app in the following trace appears to drop a frame because its main thread drawing time exceeds 16.6ms. However, this isn’t necessarily a jank. Due to BufferQueue and Triple Buffer, SurfaceFlinger might already have a prepared buffer from a previous frame to composite.

Therefore, you cannot definitively judge jank from the App-side trace alone; you must check the SurfaceFlinger-side trace.

Judging Jank on the SurfaceFlinger Side

In SurfaceFlinger, you can see the main thread’s composition status and the buffer count in the app’s corresponding BufferQueue. The image above shows a clear jank: the app didn’t render in time, and the BufferQueue was empty, so SurfaceFlinger didn’t composite the app’s layer for that frame.

In the first image, where we said it’s hard to tell from the App side, the corresponding SurfaceFlinger trace is shown below. Thanks to Triple Buffer, SF has a buffer available from the app, so even though the app’s frame took over 16.6ms, SF still composited a buffer, and no jank occurred.

Logical Jank

While the rendering-related jank above is easily spotted in Systrace, logical jank also exists.

Logical jank occurs when the app’s code logic results in non-uniform or jerky visual updates, even if rendering and composition happen in time. Systrace won’t show this, but users will feel it.

For example, when scrolling a list, a perfect experience has the list advancing along a smooth, decaying curve after release. If the list jumps 20 pixels, then 10, then 30, it will feel jittery even if every frame completes within 16.6ms. Android optimizes for this in android/view/animation/AnimationUtils.java; specifically, check these methods:

1
2
3

public static void lockAnimationClock(long vsyncMillis)
public static void unlockAnimationClock()
public static long currentAnimationTimeMillis()

System animations rarely have this issue, but developers might inadvertently write such code—for instance, calculating animation properties based on real-time clock instead of the Vsync arrival time. In such cases, any rendering delay leads to uneven animation steps.

Dropped frames have many causes. Refer to these three articles:

BufferQueue and Triple Buffer

BufferQueue

BufferQueue uses a Producer-Consumer model. Typically, the Consumer creates and owns the BufferQueue data structure, while the Producer exists in a different process.

Operating logic:

When a Producer needs a buffer, it calls dequeueBuffer(), specifying dimensions and format, to request a buffer from BufferQueue.
The Producer fills the buffer and calls queueBuffer() to return it to the queue.
The Consumer calls acquireBuffer() to take and consume the content.
Once finished, the Consumer calls releaseBuffer() to return it to the queue.

Android uses Vsync to control these flows. For details, see:

In app rendering, the App is the Producer and SurfaceFlinger is the Consumer:

App calls dequeueBuffer() to request a buffer.
App renders (via CPU or GPU) and calls queueBuffer() to return it.
SurfaceFlinger receives a Vsync signal, calls acquireBuffer() to take the buffer, and performs composition.
SurfaceFlinger calls releaseBuffer() to return it after composition.

The number of buffers in the BufferQueue significantly affects performance. Let’s analyze single, double, and triple buffering.

Single Buffer

With only one buffer, it must be used for both composition and rendering simultaneously.

Ideally, this could work with Vsync-Offset:

App receives Vsync and starts rendering.
After Vsync-Offset, SurfaceFlinger receives Vsync and composites.
Screen refreshes to show the frame.

However, if rendering or composition isn’t finished before the refresh, the user sees an incomplete buffer—manifesting as screen tearing.

Single buffering is no longer used; this is purely illustrative.

Double Buffer

Double buffering provides two alternately rotating buffers. While the Consumer uses one, the Producer can use the spare.

Ideal double buffering workflow:

However, if an app’s production consistently exceeds Vsync cycles (missing SF’s composition window), jank occurs:

Triple Buffer

Triple buffering adds a BackBuffer, allowing three buffers to rotate. While FrontBuffer is in use, the app has two idle buffers. Even if the GPU times out, the CPU can still take a fresh buffer for production (SF consumes FrontBuffer, GPU uses one BackBuffer, CPU uses another BackBuffer).

Triple buffering solves the jank caused by buffer shortages in double buffering:

Comparison (Double Buffer janks twice; Triple Buffer janks once):

The Role of Triple Buffer

Mitigating Jank

As shown in the comparison, triple buffering helps reduce the frequency of jank during consecutive main thread timeouts (reducing two janks to one). This is why an app-side timeout doesn’t always result in a user-perceived jank in SurfaceFlinger.

Reducing Wait Times

In Double Buffering, the app’s main thread must sometimes wait for SurfaceFlinger to release a buffer before it can start production. Since most phones receive Vsync signals for SF and App simultaneously, this delay shortens the available time for the main thread:

In Systrace, this appears as:

With Triple Buffering, this wait rarely occurs. The rendering thread can smoothly dequeueBuffer and begin work immediately.

Lowering GPU and SurfaceFlinger Bottlenecks

In double buffering, any GPU timeout easily prevents SurfaceFlinger from compositing in time, causing jank. Triple buffering allows app buffers to enter the queue earlier for GPU rendering (without waiting), effectively lowering thresholds. It also reduces dequeueBuffer wait times when SurfaceFlinger itself is heavily loaded.

Below are traces showing Double Buffering jank caused by high SurfaceFlinger load and delayed dequeueBuffer responses. These issues mostly disappear with Triple Buffering.

Debugging Triple Buffer

Dumpsys SurfaceFlinger

dumpsys SurfaceFlinger provides status, performance metrics, buffer states, and layer info. Below is a snippet showing buffer usage; apps under different loads use Triple Buffering differently:

Disabling Triple Buffer

Properties vary across Android versions (a logic bug fixed in Android 10).

Android Version <= Android P

1
2
3

// Logic
property_get("ro.sf.disable_triple_buffer", value, "1");
mLayerTripleBufferingDisabled = atoi(value);

Modify and restart Framework (requires Root):

1
2
3

adb root
adb shell setprop ro.sf.disable_triple_buffer 0
adb shell stop && adb shell start

Android Version > Android P

1
2
3

// Logic
property_get("ro.sf.disable_triple_buffer", value, "0");
mLayerTripleBufferingDisabled = atoi(value);

Modify and restart Framework (requires Root):

1
2
3

adb root
adb shell setprop ro.sf.disable_triple_buffer 1
adb shell stop && adb shell start

References

Android Graphics

Attachments

Systrace attachments are available for download. Extract and open in Chrome:
Download Systrace attachments for this article

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Basics - Binder and Lock Contention Explained

2019-12-06T11:12:34.000Z

This is the tenth article in the Systrace series, primarily providing a brief introduction to Binder and lock information in Systrace. It covers the basic situation of Binder, the representation of Binder communication in Systrace, how to view Binder information, and analysis of lock contention in SystemServer.

Series Article Index
Binder Overview
Binder Call Diagram
Lock Information in Systrace
Waiting for Lock Analysis
Related Code
References
Attachments
About Me && Blog

Series Article Index

Binder Overview

Most inter-process communication in Android uses Binder. I won’t provide an over-explanation of Binder here. If you want a deep understanding of Binder’s implementation, I recommend reading these three articles:

The reason for discussing Binder and locks in Systrace separately is that many jank and responsiveness issues stem from cross-process Binder communication. Lock contention can extend Binder communication time, affecting the calling end. A classic example is when an app’s rendering thread calls dequeueBuffer, and the SurfaceFlinger main thread is blocked, causing the dequeueBuffer to take longer and resulting in app jank. Another example is when AMS or WMS methods in SystemServer are holding locks, causing long wait times for app calls.

Here is a Binder architecture diagram from an article. This piece focuses on Systrace, so we’ll cover how Binder appears in Systrace without diving into its internal implementation.

Binder Call Diagram

Binder is primarily used for cross-process communication. The diagram below simply shows how Binder communication is displayed in Systrace:

In the diagram, the SystemServer process is communicating with Qualcomm’s perf process. Enabling Flow Events in the ViewOptions in the top right corner of Systrace will reveal Binder information.

Clicking on a Binder event reveals detailed information. Some of this data is useful during problem analysis, but we won’t go into detail here.

For Binder, this section focuses on how to view lock information and lock waiting in Systrace. Analyzing many jank and responsiveness issues depends on interpreting this information. Ultimately, you’ll need to return to the code: once an issue is identified, read the source code to understand the logic and perform appropriate optimizations.

Lock Information in Systrace

monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733) waiters=2 blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)

Let’s break the above message into two parts, using blocking as the dividing line.

Part 1 Interpretation

monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733) waiters=2

Monitor refers to the current pool for the lock object. In Java, every object has two pools: a lock (monitor) pool and a wait pool.

Lock Pool (Synchronized Queue): Suppose thread A already owns the lock of an object (not a class). Other threads wanting to call a synchronized method (or block) on this object must first acquire ownership of that object’s lock. Since thread A currently owns it, these other threads enter the object’s lock pool.

The word contention is used here, meaning there’s a struggle because the object’s lock is currently held by another object (Owner), so ownership cannot be acquired, and the thread enters the lock pool.

Owner: The object currently possessing the lock for this object. Here, it’s Binder:1605_B, with thread ID 4667.

at: Describes what the Owner thread is currently doing. Here, it’s executing the void com.android.server.wm.ActivityTaskManagerService.activityPaused method. The code location is ActivityTaskManagerService.java:1733. The corresponding code is:

com/android/server/wm/ActivityTaskManagerService.java

@Override
public final void activityPaused(IBinder token) {
    final long origId = Binder.clearCallingIdentity();
    synchronized (mGlobalLock) { // Line 1733 is here
        ActivityStack stack = ActivityRecord.getStackLocked(token);
        if (stack != null) {
            stack.activityPausedLocked(token, false);
        }
    }
    Binder.restoreCallingIdentity(origId);
}

We can see synchronized (mGlobalLock) acquires the ownership of the mGlobalLock lock. Until it releases the lock, any other place calling synchronized (mGlobalLock) must wait in the lock pool.

waiters: The number of operations currently waiting in the lock pool for the object’s lock. waiters=2 indicates there’s already one operation waiting for the lock, so adding this one makes a total of three.

Part 2 Interpretation

blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)

The second part is simpler: it identifies the method currently being blocked while waiting for the lock. Here, ActivityManager‘s getFocusedStackInfo is blocked. The corresponding code is:

com/android/server/wm/ActivityTaskManagerService.java

@Override
public ActivityManager.StackInfo getFocusedStackInfo() throws RemoteException {
    enforceCallerIsRecentsOrHasPermission(MANAGE_ACTIVITY_STACKS, "getStackInfo()");
    long ident = Binder.clearCallingIdentity();
    try {
        synchronized (mGlobalLock) { // Line 2064 is here 
            ActivityStack focusedStack = getTopDisplayFocusedStack();
            if (focusedStack != null) {
                return mRootActivityContainer.getStackInfo(focusedStack.mStackId);
            }
            return null;
        }
    } finally {
        Binder.restoreCallingIdentity(ident);
    }
}

This also calls synchronized (mGlobalLock) (Note: The original text might have varied between mGlobalLock and ActivityManagerService.this due to Android versions, but the principle is the same), requiring wait for the ownership of the object’s lock.

Summary

The above message translates to:

The getFocusedStackInfo method of ActivityTaskManagerService was blocked during execution because it couldn’t acquire ownership of the synchronization object’s lock when executing a synchronized block. It must wait until another method, ActivityTaskManagerService.activityPaused, which currently owns the lock, finishes execution before it can acquire ownership and continue.

Compare with the original text:

monitor contention with owner Binder:1605_B (4667)
at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733)
waiters=2
blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)

Waiting for Lock Analysis

In the same Systrace, the Binder info shows waiters=2, meaning two operations preceded this one in waiting for the lock release. This sums to three operations waiting for Binder:1605_B (4667) to release the lock. Let’s look at the execution of Binder:1605_B:

The diagram shows Binder:1605_B executing activityPaused, with some other Binder operations in between, before finally releasing the lock upon completion.

Now let’s trace the execution order, including the two waiters:

Lock Waiting

The diagram illustrates the contention for the mGlobalLock object lock:

Binder_1605_B first begins executing activityPaused, which requires the mGlobalLock lock. Since there’s no current contention, activityPaused acquires the lock and starts.
The android.display thread starts executing the checkVisibility method, which also needs the mGlobalLock lock. Since Binder_1605_B holds it, checkVisibility waits and enters a sleep state.
The android.anim thread starts executing relayoutWindow, also needing the mGlobalLock lock. Since Binder_1605_B holds it, it also waits and enters sleep.
The android.bg thread starts getFocusedStackInfo, also needing the lock. It also waits and sleeps.

After these four steps, Binder_1605_B is running while the other three threads failed to acquire the mGlobalLock lock and are sleeping, waiting for Binder_1605_B to finish and release the lock.

Lock Release

This diagram shows the lock release and subsequent flow:

Binder_1605_B‘s activityPaused finishes, and the mGlobalLock lock is released.
The first waiting thread, android.display, starts executing checkVisibility. Its wakeup info shows it was woken by Binder_1605_B (4667).
checkVisibility finishes, and the lock is released.
The second waiting thread, android.anim, starts relayoutWindow. Its wakeup info shows it was woken by android.display (1683).
relayoutWindow finishes, and the lock is released.
The third waiting thread, android.bg, starts getFocusedStackInfo. It was woken by android.anim (1684).

After these 6 steps, this round of lock waiting caused by mGlobalLock concludes. This is a simple example; in practice, Binder lock waiting in SystemServer can be very severe, with waiters often reaching 7-10—quite alarming, as seen below:

This explains why the system can become laggy after many apps are installed or after prolonged use. A brief period of this can also occur after a reboot.

If you’re unsure how to view wakeup information, refer to this article: Analyzing Process Wakeup Information in Systrace.

Monitor Info

art/runtime/monitor.cc

std::string Monitor::PrettyContentionInfo(const std::string& owner_name,
                                          pid_t owner_tid,
                                          ArtMethod* owners_method,
                                          uint32_t owners_dex_pc,
                                          size_t num_waiters) {
  Locks::mutator_lock_->AssertSharedHeld(Thread::Current());
  const char* owners_filename;
  int32_t owners_line_number = 0;
  if (owners_method != nullptr) {
    TranslateLocation(owners_method, owners_dex_pc, &owners_filename, &owners_line_number);
  }
  std::ostringstream oss;
  oss << "monitor contention with owner " << owner_name << " (" << owner_tid << ")";
  if (owners_method != nullptr) {
    oss << " at " << owners_method->PrettyMethod();
    oss << "(" << owners_filename << ":" << owners_line_number << ")";
  }
  oss << " waiters=" << num_waiters;
  return oss.str();
}

Block Info

art/runtime/monitor.cc

if (ATRACE_ENABLED()) {
  if (owner_ != nullptr) {  // Did the owner_ give the lock up?
    std::ostringstream oss;
    std::string name;
    owner_->GetThreadName(name);
    oss << PrettyContentionInfo(name,
                                owner_->GetTid(),
                                owners_method,
                                owners_dex_pc,
                                num_waiters);
    // Add info for contending thread.
    uint32_t pc;
    ArtMethod* m = self->GetCurrentMethod(&pc);
    const char* filename;
    int32_t line_number;
    TranslateLocation(m, pc, &filename, &line_number);
    oss << " blocking from "
        << ArtMethod::PrettyMethod(m) << "(" << (filename != nullptr ? filename : "null")
        << ":" << line_number << ")";
    ATRACE_BEGIN(oss.str().c_str());
    started_trace = true;
  }
}

References

Attachments

The attachments involved in this article have been uploaded. Download, extract, and open them in Chrome:
Click here to download the Systrace attachments related to the article

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

[Sticky] Blog Article Directory

2019-11-30T23:38:21.000Z

The content of this blog mainly focuses on Android development and optimization-related topics, including the use of performance tools, Android App optimization knowledge, Android Framework explanations, and performance theory. Here is an organized directory for your reference. You can choose the parts you are interested in. This directory includes not only blog content but also some of my answers on Zhihu or the Knowledge Planet - The Performance. This directory lists my original blog posts. Additionally, I have collected some excellent articles in Must-Knows for Android Performance Optimization, which I update periodically.

This directory will be updated with every blog post for easy reference. I will try my best to update weekly. Learning is endless; let’s encourage each other. If there is anything you want to know or if there are any inadequacies in the blog, please leave a message on the blog, Zhihu, Weibo, or WeChat. I will actively correct them.

Theoretical Knowledge

Perfetto Series

As Google announced the discontinuation of the Systrace tool and introduced Perfetto, Perfetto has basically replaced Systrace in my daily work. At the same time, major manufacturers like Oppo and Vivo have also switched from Systrace to Perfetto. Many developers new to Android performance optimization find Perfetto’s dazzling interface and complex functions overwhelming. I hope to present those previous Systrace articles using Perfetto.

Note: Perfetto and Systrace can be converted to each other, so use whichever is more convenient:
Both Perfetto Trace and Systrace can be opened at https://ui.perfetto.dev/
After opening a Perfetto Trace at https://ui.perfetto.dev/, you can click the toolbar: Convert trace -> Switch to legacy UI to open it in the legacy systrace interface.

Systrace Series

The Systrace tool is a powerful tool for analyzing Android performance issues. It can show the operation of the entire machine from a graphical perspective. The Systrace tool can not only analyze performance issues but is also excellent for learning the Framework, which is one reason I wrote this series.

Note: Perfetto and Systrace can be converted to each other, so use whichever is more convenient:
Both Perfetto Trace and Systrace can be opened at https://ui.perfetto.dev/
After opening a Perfetto Trace at https://ui.perfetto.dev/, you can click the toolbar: Convert trace -> Switch to legacy UI to open it in the legacy systrace interface.

Smoothness

Smoothness refers to jank and dropped frames, often discussed as Smooth vs Jank.

Responsiveness

Responsiveness mainly refers to App cold and warm start, interface navigation speed, screen on/off speed, etc., often discussed as Fast vs Slow.

ANR

Articles related to Android ANR.

Memory

Articles related to Android memory optimization and its impact on the system.

Framework Knowledge

Framework-related content, including operating principles, problem-solving ideas, and optimization methods.

App Development

Articles related to App development. Since they were written early, you can just take a quick look.

Personal Summary and Recommendations

Not related to technology, but can improve happiness and work efficiency.

Reading Notes

Performance Optimization Patterns and Tips

Performance Optimization Patterns is a series of short videos by Google (6 seasons). I originally wanted to accompany each with an article. Android Tips are translations from another blogger.

Zhihu Q&A

Some articles are from Zhihu columns. Here are some top-voted answers.

Android Weekly

Juejin Column: Android Weekly
Zhihu Column: Android Weekly

Android Weekly Articles:

Personal Page

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Personal Blog: Where I write
Blogger Intro: Includes personal WeChat and WeChat group links.
Curated Performance Articles: Welcome to recommend projects/articles.
Android Performance Knowledge Planet: Welcome to join and thank you for your support~
WeChat Official Account
Zhihu: https://www.zhihu.com/people/gracker
Email Subscription: https://androidweekly.zhubai.love/
Juejin: https://juejin.cn/user/1816846860560749

Presentations and Training PPTs

This section will be released after some organization. As you know, PPTs don’t contain too much detail, mostly just an outline.

Knowledge Planet

The Knowledge Planet is named The Performance, a community for sharing performance optimization-related knowledge in the Android development field. The moderator is the blogger himself, a senior developer in performance optimization at a top-tier domestic mobile phone manufacturer. He has years of accumulated knowledge and experience in performance-related fields and can provide one-stop services for performance and power analysis knowledge, covering basics, methodology, tool usage, and the most valuable case studies.

Android Systrace Basics - Vsync Explained

2019-11-30T22:38:21.000Z

This is the seventh article in the Systrace series, primarily introducing the Vsync mechanism in Android. This article examines the display of each frame in the Android system from the perspective of Systrace. Vsync is a critical mechanism in Systrace. Although invisible and intangible when operating a phone, we can see in Systrace how the Android system, guided by Vsync signals, orderly performs rendering and composition for each frame, ensuring stable frame rates.

Series Article Index
Main Content
Android Graphics Data Flow
Graphic Data Flow in Systrace
Vsync Offset
HW_Vsync
Other Addresses for This Article
References
About Me && Blog

Series Article Index

Main Content

Vsync signals can be generated by hardware or simulated via software, though hardware generation is now standard. The Hardware Composer (HWC) produces VSYNC events and sends them to SurfaceFlinger via callbacks. DispSync then generates VSYNC_APP and VSYNC_SF signals from these for use by Choreographer and SurfaceFlinger.

In the article Detailed Explanation of Android Rendering Mechanism Based on Choreographer, we mentioned that Choreographer coordinates with Vsync to provide a stable Message processing timing for App-level rendering. When Vsync arrives, the system adjusts the signal period to control when each frame is drawn. Most current phones have a 60Hz refresh rate (16.6ms). To match this, the system sets the Vsync period to 16.6ms, waking Choreographer every period to perform app drawing—this is the primary purpose of Choreographer.

While Choreographer handles Vsync for the rendering layer (App), SurfaceFlinger handles it for the composition layer. SurfaceFlinger composites all prepared Surfaces when Vsync arrives.

The diagram below shows VSYNC_APP and VSYNC_SF within the SurfaceFlinger process in Systrace.

Android Graphics Data Flow

First, we must understand the high-level direction of graphics data. From app drawing to screen display, the process consists of several stages:

Stage 1: Upon receiving Vsync-App, the App performs measure, layout, and draw (constructing a DisplayList containing OpenGL commands and data) on the main thread. This corresponds to the doFrame operation in Systrace’s main thread.
Stage 2: The CPU uploads data (via sharing or copying) to the GPU. On ARM devices, CPU and GPU usually share memory. This corresponds to the flush drawing commands operation in Systrace’s rendering thread.
Stage 3: Notify the GPU to render. Real devices typically don’t block waiting for GPU completion; the CPU returns to other tasks immediately. The Fence mechanism is used for synchronization.
Stage 4: swapBuffers and notification to SurfaceFlinger for layer composition. This corresponds to the eglSwapBuffersWithDamageKHR operation in Systrace’s rendering thread.
Stage 5: SurfaceFlinger starts composition. If previous GPU tasks aren’t finished, it waits (Fence mechanism). Composition still relies on the GPU, but as a subsequent task. This corresponds to onMessageReceived (including handleTransaction, handleMessageInvalidate, handleMessageRefresh) in SurfaceFlinger‘s main thread. SurfaceFlinger delegates some work to the Hardware Composer to offload the GPU; only layers HWC can’t handle (or those explicitly assigned to OpenGL) use OpenGL.
Stage 6: Final composited data is placed in the Frame Buffer and becomes visible upon refresh.

The following official diagram shows how frame data flows across processes from left to right:

Graphic Data Flow in Systrace

By mapping the abstract data flow above to Systrace, we get this:

The diagram above includes SurfaceFlinger, App, and hwc processes. Let’s follow the numbers:

First Vsync signal arrives; SurfaceFlinger and App receive it simultaneously.
SurfaceFlinger receives Vsync-sf and begins compositing the App’s previous frame buffer.
App receives Vsync-app and begins rendering the current frame buffer (stages 1-4 above).
Second Vsync signal arrives. SurfaceFlinger retrieves the buffer the App rendered in step 2 and begins composition (stage 5). Simultaneously, the App receives Vsync-app and starts rendering the next frame buffer (stages 1-4).

Vsync Offset

As mentioned, HWC produces hardware Vsync, which DispSync converts into VSYNC_APP and VSYNC_SF.

Both app and sf signals have offsets relative to hw_vsync_0, namely phase-app and phase-sf:

Vsync Offset refers to the difference between VSYNC_APP and VSYNC_SF (i.e., phase-sf - phase-app), which manufacturers can configure. If the offset is non-zero, the App and SurfaceFlinger don’t receive the signal simultaneously; they receive it separated by the Offset (usually 0-16.6ms).

Most manufacturers leave this at 0, so App and SurfaceFlinger receive signals simultaneously.

Check the values using Dumpsys SurfaceFlinger:

Offset = 0: (sf phase - app phase = 0)

Sync configuration: [using: EGL_ANDROID_native_fence_sync EGL_KHR_wait_sync]
DispSync configuration: 
          app phase 1000000 ns,              sf phase 1000000 ns 
    early app phase 1000000 ns,        early sf phase 1000000 ns 
 early app gl phase 1000000 ns,     early sf gl phase 1000000 ns 
      present offset 0 ns                      refresh 16666666 ns

Offset ≠ 0 (SF phase - app phase = 4 ms)

Sync configuration: [using: EGL_ANDROID_native_fence_sync EGL_KHR_wait_sync]

VSYNC configuration:
         app phase:   2000000 ns         SF phase:   6000000 ns
   early app phase:   2000000 ns   early SF phase:   6000000 ns
GL early app phase:   2000000 nsGL early SF phase:   6000000 ns
    present offset:         0 ns     VSYNC period:  16666666 ns

Now let’s see how Offset looks in Systrace.

Offset = 0

When Offset is 0, App and SurfaceFlinger receive Vsync simultaneously:

As shown, the App-rendered buffer must wait until the next Vsync-SF for composition, causing a ~16.6ms delay. You might wonder: if SurfaceFlinger could start composition immediately after the App swaps the buffer into BufferQueue, could we save those 0-16.6ms?

Yes, that’s exactly what the Offset mechanism does. The App receives Vsync first, performs rendering, and after the Offset delay, SurfaceFlinger receives Vsync and begins composition. If the app’s buffer is ready, SurfaceFlinger can include it in the current composition, allowing the user to see it sooner.

Offset ≠ 0

Below is an example with a 4ms Offset: SurfaceFlinger receives Vsync 4ms after the App does.

Pros and Cons of Offset

The challenge is determining the optimal Offset—one reason many manufacturers don’t configure it. Its effectiveness depends on device performance and usage scenarios.

If Offset is too short: The app might not finish rendering before SurfaceFlinger starts composition. If no previous buffers are ready, SurfaceFlinger‘s current composition won’t include the new frame, delaying it until the next Vsync-SF. The delay effectively becomes Vsync period + Offset instead of the expected Offset.
If Offset is too long: It loses its purpose.

HW_Vsync

Note that hardware Vsync isn’t requested every time. It’s only requested from HWC if the last composition was more than 500ms ago.

Using Launcher scrolling as an example, you can see the HW_VSYNC state in the SurfaceFlinger process trace.

Subsequent Vsync requests from Apps can occur either with or without HW_VSYNC.

Without HW_VSYNC

With HW_VSYNC

HW_VSYNC primarily uses recent hardware Vsync timestamps for prediction (usually 3-32, minimum 6). DispSync calculates SW_VSYNC after receiving 6 timestamps. As long as incoming Present Fence errors remain within threshold, hardware Vsync is turned off; otherwise it remains active to recalibrate SW_VSYNC. For details, see Generation and Transmission of SW-VSYNC. Here is their conclusion:

SurfaceFlinger implements the HWC2::ComposerCallback interface to receive hardware VSYNC callbacks and pass them to DispSync. DispSync records these timestamps. After collecting enough (currently ≥6), it calculates the SW-VSYNC offset mPeriod. This is used by DispSyncThread to periodically wake and notify listeners—SurfaceFlinger and all apps needing to render. Listeners register via Connection objects in EventThread, which is linked to DispSyncThread through DispSyncSource. When SW-VSYNC arrives, EventThread notifies connections, triggering SurfaceFlinger composition and App frame drawing. Once enough hardware VSYNCs are received and errors are within tolerance, hardware VSYNC is disabled via EventControlThread.

References

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Complete Guide to Android App Startup Optimization

2019-11-18T15:02:46.000Z

This article compiles most current Android app startup optimization solutions. If you need optimization guidance, simply reference this article to review others’ approaches and identify gaps. Many solutions require business-specific adjustments, so this article doesn’t detail every method—when you need a particular solution, search online for its specific implementation. This serves as a comprehensive reference.

I’ve also included some system manufacturer optimizations related to startup, though I’ve only listed those I’m aware of. Some manufacturers have proprietary technologies not discussed here. Understanding manufacturer practices may help you—for example, contacting manufacturers for whitelisting or integrating their SDKs.

App Startup Overview

General App Startup Flow

From tapping the app icon on the home screen to having the main interface ready for user interaction, app startup generally follows this flow:

During app startup, the two most critical processes are SystemServer and App Process. Their responsibilities are divided as follows:

SystemServer handles app startup flow scheduling, process creation and management, window creation and management (StartingWindow and AppWindow), etc.
After being created by SystemServer, the app process performs a series of process initializations, component initializations (Activity, Service, ContentProvider, Broadcast), main interface construction, content population, etc.

Cold Start vs. Hot Start

We also need to introduce the concepts of cold start and hot start, which we frequently encounter:

Cold Start: When starting an app with no existing process in the background, the system creates a new process for the app, then launches the corresponding process components based on startup parameters.
Hot Start: When starting an app with an existing process in the background (e.g., after pressing back/home—the app exits but its process remains in the background, visible in the task list), the startup reuses the existing process to launch the corresponding components.

Measuring Startup Speed

Different companies have their own measurement methods. The key challenge is defining the endpoint of startup—some apps are easy to measure, while others are too complex for direct measurement. Methods like adb are fine for personal experimentation but useless in production; screen recording itself introduces performance overhead…

I recommend learning from the measurement approach mentioned in “历时1年，上百万行代码！首次揭秘手淘全链路性能优化（上）”: automated, stable, and integrated into CI/CD.

Extract text information from images using OCR as key features. This algorithm’s advantages: 1. App pages typically contain text; OCR can recognize text on images—text appearance indicates image loading completion, aligning with user perception. 2. Using text as features filters out much noise from image features, reducing algorithm debugging effort. Additionally, Alibaba Group has mature, excellent OCR services—“读光” with over 99.7% document recognition rate. Using the OCR service encapsulated by the Waterdrop platform enables quick integration. The final recognition solution is based on OCR.

App-Level Optimizations

Startup Window Optimization

The startup window, also called the launch page, SplashWindow, or StartingWindow, refers to the preview window displayed during app startup. iOS apps mandatorily have a launch screen—after users tap the app icon, the system immediately shows this launch window, then displays the main page once ready. Android has a similar mechanism (the startup window is system-provided) but also provides an interface for developers to set whether to show this startup window (default is show). Some developers disable the system-provided startup window and implement their own.

However, displaying a custom window takes longer than showing the system’s startup window, causing user-perceived delay—tapping the icon results in a pause before the window animation enters the app. We should avoid this:

Don’t disable the system’s default startup window: i.e., don’t set android:windowDisablePreview to true in the theme.
Customize startup window content: e.g., set the splash page theme background to the splash image, or尽量使闪屏页面的主题和主页一致 (make the splash page theme consistent with the main page). Reference practices from Zhihu and TikTok.
Merge splash and main page Activities: WeChat’s approach. However, since WeChat sets android:windowDisablePreview and is on most manufacturers’ whitelists (rarely killed), cold starts are infrequent. Still, it’s worth considering.

Thread Optimization

Thread optimization primarily reduces CPU scheduling fluctuations, making startup times more stable. Too many threads launching simultaneously puts significant pressure on the CPU, especially on lower-end devices. Excessive concurrent threads increase the main thread’s Sleep and Runnable states, slowing app startup. During optimization, note:

Control thread count—use thread pools.
Check inter-thread locks to prevent dependency waits.
Use reasonable startup architectures:
- mmkernel (used internally by WeChat)
- Alibaba’s Alpha

System Scheduling Optimization

During app startup, if the main thread handles too much work, it becomes overly busy. Note these system scheduling-related points:

Reduce system calls during startup, avoiding lock competition with AMS and WMS. During startup, AMS and WMS already handle much work, and many AMS/WMS operations are locked. If the app makes excessive Binder calls to communicate with AMS/WMS, SystemServer experiences大量锁等待 (significant lock waits), blocking critical operations.
Don’t launch child processes during startup. If multiple processes start simultaneously, system load doubles, and SystemServer becomes busier.
Be cautious launching components other than Activity during startup. Since all four major components launch on the main thread, slow component startup占用Message通道 (occupies the Message channel), affecting app startup speed.
Asynchronously initialize certain code in Application and main Activity’s onCreate.

Busy CPU during startup:

Busy SystemServer during startup:

GC Optimization

Reduce GC frequency during startup:

Avoid大量字符串操作 (extensive string operations), especially serialization/deserialization.
Consider reusing frequently created objects.
Move implementations to Native.

Reference: “支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」”

IO Optimization

Startup负载比较高 (load is relatively high), with many system IOs occurring simultaneously. IO performance declines rapidly during this period, making app IO operations slower than usual, especially on lower-performance devices.

IO分为网络IO和磁盘IO (IO分为网络IO和磁盘IO). Avoid network IO during startup. For disk IO, scrutinize carefully—as mentioned in the expert course:

Understand exactly what files are read during startup: how many bytes, buffer size, duration, thread, etc.
Monitor IO during startup. WeChat discovered users with 500MB database files during IO monitoring.

The image below shows significant IO waits on the main thread during app startup under low memory (UI Thread column, orange代表IO等待 (represents IO wait)):

Resource Reordering

Leverage Linux’s IO reading策略 (strategies), PageCache, and ReadAhead mechanisms. Reorder resources according to read sequence to reduce disk IO次数 (count). For具体操作 (specific operations), reference “支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能”.

Between the底层文件系统 (underlying filesystem) VFS and app processes lies a pagecache layer composed of physical pages in memory, whose content corresponds to blocks on disk. Pagecache size changes dynamically—it can expand or shrink under memory pressure. Cached storage devices are called backing store. A page typically contains multiple blocks, which aren’t necessarily contiguous.

Combining file re-layout with the Pagecache mechanism reduces actual IO次数 (count) during startup. Simply put, file re-layout arranges files needed during startup phase together within the APK,尽可能利用pagecache机制 (maximizing use of the pagecache mechanism), reading as many startup-phase files as possible with minimal disk IO, reducing IO overhead to improve startup performance.

Class Reordering

Class reordering adjusts class arrangement within Dex files using ReDex’s Interdex. Interdex optimization doesn’t require analyzing class references—it simply reorders classes within Dex, placing startup-required classes sequentially in the main dex. We can implement this entirely during compilation. This optimization improves startup speed, with Facebook’s data showing significant效果 (effectiveness) and high cost-effectiveness. For具体实现 (specific implementation), reference “Redex 初探与 Interdex：Andorid 冷启动优化”.

Main Page Layout Optimization

Main interface layout optimization is a common topic. Combined approaches无非就是下面两点 (essentially boil down to these two points), requiring optimization based on specific interface layouts. Plenty of online resources exist:

Reduce view hierarchy by eliminating冗余或者嵌套布局 (redundant or nested layouts).
Replace UI controls not needed during startup with ViewStub.
Use custom Views instead of complex View stacking.

Idle Calls

IdleHandler: Called only when the Handler is idle. If返回true (returns true), it continues executing; if返回false (returns false), it executes once then removes itself from the message queue. For example, we can place server token fetching in a delayed IdleHandler, or load less important Views via IdleHandler.

Class Loading Optimization

You can see the verifyClass process in systrace-generated files. Since it需要校验方法的每一个指令 (needs to verify every instruction of each method), it’s a relatively time-consuming operation.

App Thinning (App 瘦身)

App thinning includes both code and resource optimization. Common practices include:

Inspect Code: Use Android Studio’s built-in code inspection tool, which embeds Lint for static analysis.
Code Obfuscation: Use ProGuard/R8 to remove unused code and shrink the APK size.
Image Format Selection: If image quality requirements are not critical, consider using RGB_565 format instead of ARGB_8888.
Resource Obfuscation: Implement resource name obfuscation to reduce APK size.
Reduce Dex Count: Minimize the number of Dex files to improve class loading performance.

Choosing the Right Startup Framework (选择合适的启动框架)

Startup optimization requires systematic process organization. We introduce the concept of a Directed Acyclic Graph (DAG) to structure the startup flow. The entire startup process is organized into a DAG structure, with tasks loaded sequentially.

In the startup phase, we first load essential startup items using a multi-process approach, controlled by the DAG. Non-essential items can be deferred for later loading. The DAG-based sequential loading also considers process requirements, determining which items should load in the main process versus other processes.

This approach draws inspiration from Spark’s DAGScheduler, which employs Stage-Oriented Scheduling: dividing applications into stages and arranging tasks within those stages. By building a DAG, task dependencies are clearly organized. Stage-based execution allows concentrating resources to complete stage one before moving to stage two, controlling congestion while ensuring proper sequencing and enabling concurrent execution to maximize device performance.

For reference, see Taobao’s full-link optimization case: “历时1年，上百万行代码！首次揭秘手淘全链路性能优化（上）”

Startup Network Optimization (启动网络链路优化)

Problems and Optimization Points

Send/Receive Processing Stage: Network library bindService affects the first few requests; image concurrency limits cause thread queuing in image libraries.
Network Latency: Some requests have large response sizes, including SO files, cache resources, and large original images.
Response Processing: Complex JSON parsing for certain data gateway requests causes severe delays (up to 3s), compounded by inappropriate historical thread queue designs.
UI Blocking: Callbacks to the UI thread get blocked, causing severe main thread stutter. High-end devices experience ~1s delays, while low-end devices worsen to 3s+.
Callback Blocking: Some business callbacks execute slowly, blocking either the main thread or callback threads.

Optimization Strategies

Request Consolidation: Business teams must consolidate duplicate requests and reduce non-essential ones.
Large Data Requests: Defer or cancel non-essential large requests like resource files and SO libraries during startup.
Callback Optimization: Business teams must optimize callbacks that block the main thread. For smooth 60fps operation, each frame must complete within 16ms. Push teams whose callbacks exceed 16ms on the main thread to optimize their execution.
JSON Parsing Optimization: Overly complex JSON structures cause severe parsing delays. Since network concurrency threads are limited, lengthy parsing occupies MTOP threads, affecting other critical requests. Encourage business teams to use custom threads for parsing or simplify JSON structures.

Preloading (预加载)

Preload data before the Activity opens, then display the preloaded data once the UI layout initializes, significantly reducing startup time. Reference implementation: PreLoader

Keep-Alive (保活)

Keep-alive is both a nightmare for app developers and a focus area for Android manufacturers. From a startup perspective, if an app process isn’t killed, startup naturally becomes faster (hot start). However, we don’t recommend using “black magic” techniques like mutual wake-up or notification bombing.

Instead, provide genuine functionality that makes users feel your background presence is reasonable and acceptable. When in the background, release all possible resources, avoid power-hungry operations, stop unnecessary services, and disable animations.

While this may seem idealistic given current manufacturer practices (aggressively killing background apps), it’s the right direction. Google is working on both standardizing app background behavior and regulating manufacturer app handling. Improving Android’s ecosystem requires collaboration between app developers and manufacturers.

Another approach is collaborating with manufacturers: optimize background memory usage, eliminate duplicate wake-ups, remove aggressive logic, and respond promptly to low-memory warnings. After implementing these improvements, contact system manufacturers to discuss feasibility for whitelisting in both kill lists and auto-start lists.

Business Organization (业务梳理)

This involves specific business logic unique to each app, though the approach remains consistent. As mentioned in the expert course:

Audit Every Module: Clearly identify which modules are absolutely necessary during startup, which can be eliminated, and which can be lazily loaded.
Different Launch Modes: Determine different startup patterns based on various business scenarios.
Prevent Centralization: Implement lazy loading to avoid resource concentration.

Business logic can be categorized into four dimensions:

Essential & Time-Consuming: Startup initialization - consider using threads for initialization.
Essential & Fast: Homepage rendering.
Non-Essential but Time-Consuming: Data reporting, plugin initialization.
Non-Essential & Fast: Remove entirely; load only when needed.

Then optimize loading based on these categories.

Business Optimization (业务优化)

Optimize Code Efficiency: Focus on obvious bottlenecks first, then gradually optimize other areas.
Address Technical Debt: Refactor historical code; don’t let it accumulate indefinitely.

Specific businesses have specific optimization scenarios. Reference this article for optimization processes and items: https://www.jianshu.com/p/f5514b1a826c

Move database and IO operations to worker threads with THREAD_PRIORITY_BACKGROUND priority (maximum 10% CPU time slice), ensuring main thread execution priority.
Process Organization & Deferred Execution: Most effective for startup acceleration. Through process analysis, discover issues like:
Update operations called before first screen display, causing resource competition.
Calls to iOS-specific switches (for App Store review avoidance) causing dense network requests.
Custom statistics creating fixed 5-thread pools in Application, causing resource competition.
Modify ad splash logic to take effect next time.
Remove unused legacy code still being executed.
Remove development-only code executed in production.
Eliminate duplicate logic execution.
Remove excess code in third-party SDKs or demos.
Information Caching: Cache commonly used information; fetch only once, then retrieve from cache.
Multi-process Architecture: Execute Application.onCreate() only in the main process.

The StartingWindow is created and displayed immediately after user taps the app icon (provided the app hasn’t disabled StartingWindow). When the AppWindow is ready, the StartingWindow disappears, and the AppWindow displays.

Default App Startup Window Flow

1 2	StartingWindow(SystemWindow) -> MainActivity(AppWindow)

Most Third-Party App Startup Flow

1
2
3

StartingWindow(SystemWindow) 
  -> SplashActivity(AppWindow)
    -> MainActivity(AppWindow)

Worse Startup Flow

StartingWindow(SystemWindow) 
  -> MainActivity(AppWindow) 
    -> SplashActivity(AppWindow)
      -> MainActivity(AppWindow)

Even Worse: Disabled StartingWindow

1 2	SplashActivity(AppWindow) -> MainActivity(AppWindow)

For users, the first flow is best, involving only one window transition. Some apps use the second flow due to ad page requirements. However, avoid the third and fourth flows as they provide poor user experience.

Manufacturer Optimizations (厂商优化)

Beyond app-level optimizations, Android frameworks also focus heavily on application startup, implementing numerous optimizations. Different manufacturers have varying strategies, but most include these approaches:

Startup Acceleration

During app launch, the system heavily prioritizes resources (CPU, IO, GPU) for the launching app. Capture a Systrace to see this - whether in frequency or scheduling algorithms, the launching app receives VIP treatment.

Some manufacturers provide resource scheduling SDKs that apps can integrate to request resources directly when needed.

PreFork

Android Q introduced the PreFork mechanism, which forks several empty processes in advance. When an app launches, it can directly reuse these pre-forked processes instead of forking anew.

Message Reordering

Reorganizing messages during startup to prioritize launch-related operations.

Main Thread & Render Thread Acceleration

Some manufacturers give special treatment to the app’s main and render threads during startup, such as forcing them onto big cores while moving less important threads to little cores.

Startup Prediction

Some scenarios learn user habits - when, where, and in what context users typically open their phones. The system predicts which app you’ll launch and pre-warms it in the background, making your tap result in a hot start.

Background Keep-Alive

Systems may specially handle certain apps to improve user experience, including: process/thread priority adjustment, kill whitelisting, user frequent app recording, etc. Appropriate background keep-alive ensures the next launch is a hot start.

Background Restart

Systems may specially handle important apps that shouldn’t be killed. Some manufacturers perform seamless restarts when such apps go to the background. For example, if an app exceeds memory limits or crashes continuously, background restart effectively addresses this, ensuring the next user launch is a hot start.

Memory Optimization

Some apps require substantial memory during startup (e.g., modern camera apps). Without sufficient memory, the system must kill many apps and release caches to make room, causing these memory-intensive apps to perform frequent memory operations during startup, slowing them down.

Some manufacturers monitor such memory-intensive app launches and perform memory reclamation in advance, ensuring sufficient memory is available when the app starts.

Optimizing Startup Logic

Android system updates also optimize app startup speed, such as the aforementioned Pre-Fork mechanism and simplifying doFrame counts.

OEM-Level Optimizations

System manufacturers also optimize for startup:

Resource Tipping: During an app launch, the system tilts CPU, IO, and GPU resources toward that process (VIP treatment).
Pre-Fork (Android Q+): Forking empty processes in advance to save time when an app starts.
Message Reordering: Prioritizing startup-related messages in the queue.
Big Core Allocation: Forcing the app’s main and render threads onto high-performance CPU cores.
Startup Prediction: Learning user habits to pre-warm apps in the background.

References

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Introduction : Contains personal WeChat and WeChat group links.
Blog Content Navigation : A navigation guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows : Welcome self-recommendations and recommendations (WeChat private chat is fine).
Android Performance Optimization Knowledge Planet : Welcome to join, thanks for your support!

One walks faster alone, but a group walks further together.

Comprehensive Record of Android App Startup Optimization

2019-11-18T15:02:46.000Z

This article summarizes major Android app startup optimization strategies available today. If you need to optimize your app’s launch performance, use this as a checklist to identify gaps in your current implementation. Since many solutions depend on specific business requirements, I focus on presenting the options rather than deep-diving into every implementation detail. You can easily find specific technical guides for each method online.

I’ve also included some optimizations performed by system manufacturers. Understanding what happens at the OS level can help you make better decisions, such as requesting whitelisting or integrating manufacturer SDKs.

Application Startup Overview

General Startup Workflow

The journey from tapping an app icon to the main interface becoming interactive follows this general flow:

The two most critical processes during startup are SystemServer and the App Process.

SystemServer: Handles startup scheduling, process creation/management, and window creation/management (StartingWindow and AppWindow).
App Process: Once created, it performs process initialization, component initialization (Activity, Service, ContentProvider, Broadcast), main UI construction, and content inflation.

Cold vs. Hot Startup

These are two fundamental concepts in performance optimization:

Cold Startup: Starting an app when its process isn’t running in the background. The system must create a new process and initialize components from scratch.
Hot Startup: Starting an app when its process is already alive in the background (e.g., after the user pressed Back or Home). The system simply brings the existing process to the foreground and restarts the activity.

Measuring Startup Speed

While every team has its own method, the challenge lies in defining the “end point” of a startup. Simple tools like adb shell am start -W are fun but unsuitable for production. Screen recording introduces performance overhead.

I recommend the methodology used by the Mobile Taobao team: Automated, Stable, and CI-integrated. They use OCR to extract text from screenshots as key features. When text appears, the image is considered “loaded,” which aligns with actual user perception.

App-Level Optimizations

1. Startup Window Optimization

The StartingWindow (also known as SplashWindow or Preview Window) is shown immediately by the system when the user taps the icon.

Do not disable the system’s default preview window: Avoid setting android:windowDisablePreview to true in your theme. Disabling it causes a jarring lag between the icon tap and the first frame of your app.
Customize the StartingWindow: Set the splash theme’s background to match your app’s primary color or brand logo.
Merge Splash and Main Activity: This reduces one activity transition, though it requires careful management of internal state.

2. Thread Optimization

Excessive concurrent threads during startup strain the CPU, especially on low-end devices. This leads to more Sleep and Runnable states for the main thread, slowing down the launch.

Control thread counts using thread pools.
Audit locks to prevent dependency deadlocks.
Use a structured startup framework (e.g., mmkernel, Alpha).

3. System Schedule Optimization

Avoid making the main thread too busy.

Minimize system calls: Avoid excessive communication with AMS/WMS during launch to prevent lock competition in SystemServer.
Avoid starting sub-processes: Multiplying processes during startup doubles the system burden.
Be cautious with other components: Activity, Service, ContentProvider, and BroadcastReceiver initializations all happen on the main thread.
Asynchronously initialize non-critical code in Application and MainActivity.

4. GC Optimization

Reduce the number of GC cycles during startup.

Avoid heavy string manipulations, especially serialization/deserialization.
Reuse frequently created objects.
Move logic to Native code if possible.

5. IO Optimization

IO performance drops significantly under the high load of startup.

Monitor exactly which files are read, the buffer sizes used, and on which threads.
Avoid network IO during initial launch.
Optimize disk IO, especially for large database files.

6. Resource Reordering

Use Linux’s PageCache and ReadAhead mechanisms. By reordering files in the APK to match their read sequence during startup, you can minimize disk seeks and improve performance.

7. Class Reordering

Use tools like ReDex (Interdex) to adjust the order of classes within the Dex file. Moving classes needed during startup to the primary Dex file can provide a noticeable speed boost.

8. Layout Optimization

Decrease view hierarchy depth.
Use ViewStub for UI elements not needed immediately.
Use custom Views instead of complex nested layouts.

9. IdleHandler Usage

Use IdleHandler to execute non-critical tasks (like fetching push tokens or loading secondary UI) only when the message queue is idle.

10. Class Loading Optimization

Watch for verifyClass in Systrace. This verification process can be time-consuming as the system checks every instruction.

11. App Thinning

Use Inspect Code (Lint) for cleanup.
Use ProGuard/R8 for obfuscation and shrinking.
Prefer RGB_565 for images where high quality isn’t critical.
Use resource obfuscators and reduce the number of Dex files.

12. Startup Frameworks

Structure your startup tasks using a Directed Acyclic Graph (DAG). This allows you to manage dependencies clearly and execute independent tasks in parallel across multiple stages, maximizing hardware utilization while preventing congestion.

13. Networking Optimization

Batch requests to reduce the number of individual connections.
Defer non-essential data and resource downloads.
Optimize JSON parsing; complex strings can block the main thread for seconds on low-end devices.

14. Pre-loading

Load data before the Activity is even created, and show it once the UI is ready.

15. Process Preservation (Keep-Alive)

While controversial, if a process isn’t killed, the “startup” becomes a hot start. Instead of “black magic” (which OEMs target), focus on being a “good citizen”: release resources in the background, stop unnecessary services/animations, and respond to low-memory warnings. This builds trust and might help you get on an OEM’s Whitelist.

16. Business Component Review

Audit every module initialized at startup. Use these 4 categories:

Essential & Time-Consuming: Move to a background thread.
Essential & Fast: Keep on the main thread.
Non-Essential but Time-Consuming: Defer or use lazy loading.
Non-Essential & Fast: Remove or load on demand.

17. Activity Jump Hierarchy

Always prefer: StartingWindow -> MainActivity.
Avoid: StartingWindow -> SplashActivity -> MainActivity if possible, as every transition adds latency.

OEM-Level Optimizations

System manufacturers also optimize for startup:

Resource Tipping: During an app launch, the system tilts CPU, IO, and GPU resources toward that process (VIP treatment).
Pre-Fork (Android Q+): Forking empty processes in advance to save time when an app starts.
Message Reordering: Prioritizing startup-related messages in the queue.
Big Core Allocation: Forcing the app’s main and render threads onto high-performance CPU cores.
Startup Prediction: Learning user habits to pre-warm apps in the background.

References

(List of references in original article)

About Me && Blog

(Links and introduction)

Android Systrace Basics - MainThread and RenderThread Explained

2019-11-06T09:11:45.000Z

This is the ninth article in the Systrace series, primarily introducing the MainThread and RenderThread in Android Apps—commonly known as the Main Thread and Rendering Thread. This article examines their workflows from the perspective of Systrace and covers related topics: jank, software rendering, and dropped frame calculation.

Series Article Index
Main Content
Creation of the Main Thread
Creation and Evolution of the Render Thread
Division of Labor: Main Thread vs. Render Thread
Main Thread and Render Thread in Games
Main Thread and Render Thread in Flutter
Performance
References
Attachments
Other Addresses
About Me && Blog

Series Article Index

Main Content

Using list scrolling as an example, we intercept the workflow of a single frame for the main thread and rendering thread (every frame follows this process, though some involve more work than others). Pay special attention to the “UI Thread” and RenderThread rows.

The workflow corresponding to this diagram is as follows:

The main thread is in a Sleep state, waiting for the Vsync signal.
Vsync arrived, and the main thread is woken up. Choreographer callbacks FrameDisplayEventReceiver.onVsync to start drawing a frame.
Process the App’s Input events for this frame (if any).
Process the App’s Animation events for this frame (if any).
Process the App’s Traversal events for this frame (if any).
The main thread synchronizes rendering data with the rendering thread. Once synchronization is finished, the main thread completes its drawing for the frame. It can then process the next Message (if any, IdleHandler will also be triggered if not empty) or return to Sleep to wait for the next Vsync.
The rendering thread first takes a Buffer from the BufferQueue (dequeueBuffer). After processing data and calling OpenGL-related functions for the actual rendering, it returns the rendered Buffer to the BufferQueue (queueBuffer). Once Vsync-SF arrives, SurfaceFlinger takes all prepared Buffers for composition (this process is mentioned in the SurfaceFlinger section).

The above process is detailed in the article Detailed Explanation of Android Rendering Mechanism Based on Choreographer, including what doFrame does in each frame, jank calculation principles, and APM. I recommend checking that article if you haven’t yet.

In this article, we’ll dive into several points not covered in that previous piece to help you better understand the main and rendering threads:

Evolution of the Main Thread
Creation of the Main Thread
Creation of the Render Thread
Division of Labor: Main Thread vs. Render Thread
Main Thread and Render Thread in Games
Main Thread and Render Thread in Flutter

Creation of the Main Thread

An Android App process is based on Linux, and its management follows Linux process management mechanisms. Thus, its creation involves the fork function:

frameworks/base/core/jni/com_android_internal_os_Zygote.cpp

1	pid_t pid = fork();

The forked process can be seen as the main thread, but it’s not yet connected to Android and cannot handle Android App Messages. Since Android App execution is message-driven, this forked main thread must be bound to the Android Message mechanism to handle various Messages.

This is where ActivityThread comes in. More accurately, it could be called ProcessThread. ActivityThread connects the forked process with the App’s Messages. Their cooperation forms what we know as the Android App main thread. ActivityThread isn’t literally a thread; it initializes the MessageQueue, Looper, and Handler required for the Message mechanism. Since its Handler processes most Messages, we typically refer to ActivityThread as the main thread, though it’s actually a logic processing unit for the main thread.

Creation of ActivityThread

After the App process is forked, control returns to the App process to find the main function of ActivityThread:

com/android/internal/os/ZygoteInit.java

static final Runnable childZygoteInit(
        int targetSdkVersion, String[] argv, ClassLoader classLoader) {
    RuntimeInit.Arguments args = new RuntimeInit.Arguments(argv);
    return RuntimeInit.findStaticMain(args.startClass, args.startArgs, classLoader);
}

Here, startClass is ActivityThread. Once found and called, the logic moves to the main function of ActivityThread:

android/app/ActivityThread.java

public static void main(String[] args) {
    // 1. Initialize Looper and MessageQueue
    Looper.prepareMainLooper();
    // 2. Initialize ActivityThread
    ActivityThread thread = new ActivityThread();
    // 3. Primarily calls AMS.attachApplicationLocked to sync process info and perform initialization
    thread.attach(false, startSeq);
    // 4. Get the main thread Handler (H), where most App Messages are handled 
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    // 5. Initialization complete, Looper starts working
    Looper.loop();
}

The comments are clear. Once main finishes, the main thread is officially online. Its Systrace flow looks like this:

Functions of ActivityThread

We often say Android’s four components run on the main thread. This is easily understood by looking at the ActivityThread‘s Handler Messages:

class H extends Handler { // Snippet
    public static final int BIND_APPLICATION        = 110;
    public static final int EXIT_APPLICATION        = 111;
    public static final int RECEIVER                = 113;
    public static final int CREATE_SERVICE          = 114;
    public static final int STOP_SERVICE            = 116;
    public static final int BIND_SERVICE            = 121;
    public static final int UNBIND_SERVICE          = 122;
    public static final int DUMP_SERVICE            = 123;
    public static final int REMOVE_PROVIDER         = 131;
    public static final int DISPATCH_PACKAGE_BROADCAST = 133;
    public static final int DUMP_PROVIDER           = 141;
    public static final int UNSTABLE_PROVIDER_DIED  = 142;
    public static final int INSTALL_PROVIDER        = 145;
    public static final int ON_NEW_ACTIVITY_OPTIONS = 146;
}

As shown, process creation, Activity launch, and management of Services, Receivers, and Providers are all handled here, leading into specific handleXXX methods.

Creation and Evolution of the Render Thread

Now for the rendering thread, or RenderThread. Early Android versions didn’t have a dedicated rendering thread; all rendering was done on the main thread using the CPU via the libSkia library. RenderThread was introduced in Android Lollipop to take over some of the main thread’s rendering workload, reducing its burden.

Software Rendering

“Hardware acceleration” usually refers to GPU acceleration—using RenderThread to call the GPU for faster rendering. In current Android versions, hardware acceleration is enabled by default. Thus, processes with visible content will have both a main thread and a rendering thread by default. If we disable it in the Application tag of the AndroidManifest via:

1	android:hardwareAccelerated="false"

The system will detect this and forgo initializing RenderThread, using the CPU via libSkia for direct rendering. Its Systrace looks like this:

Compared to the hardware-accelerated version at the start, the main thread’s execution time increases significantly because it must handle rendering, making jank more likely and reducing the idle intervals for other Messages.

Hardware-Accelerated Rendering

With hardware acceleration on, the main thread’s draw function doesn’t perform the actual drawCall. Instead, it records the content to a DisplayList, which is then synced to the RenderThread. Once synced, the main thread is freed to handle other tasks while the RenderThread continues rendering.

Rendering Thread Initialization

RenderThread is initialized when drawing content is required. Typically, when starting an Activity, the first draw execution checks if the rendering thread is initialized and performs the initialization if not.

android/view/ViewRootImpl.java

1 2	mAttachInfo.mThreadedRenderer.initializeIfNeeded( mWidth, mHeight, mAttachInfo, mSurface, surfaceInsets);

Subsequently, draw is called directly:

android/graphics/HardwareRenderer.java

mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);
void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {
    final Choreographer choreographer = attachInfo.mViewRootImpl.mChoreographer;
    choreographer.mFrameInfo.markDrawStart();

    updateRootDisplayList(view, callbacks);

    // ... handle pending animating nodes ...

    int syncResult = syncAndDrawFrame(choreographer.mFrameInfo);
    // ... handle sync results ...
}

The draw here only updates the DisplayList. Afterward, syncAndDrawFrame is called to notify the rendering thread to start work while releasing the main thread. Core implementation of RenderThread is in the libhwui library (frameworks/base/libs/hwui).

frameworks/base/libs/hwui/renderthread/RenderProxy.cpp

1
2
3

int RenderProxy::syncAndDrawFrame() {
    return mDrawFrameTask.drawFrame();
}

I won’t detail the full RenderThread workflow here, as it warrants its own article. Many excellent resources on hwui exist, which you can consult alongside the source code. Its core flow in Systrace looks like this:

Division of Labor: Main Thread vs. Render Thread

The main thread handles process Messages, Input events, Animation logic, Measure, Layout, Draw, and updates the DisplayList, but it doesn’t interact directly with SurfaceFlinger. The rendering thread handles rendering-related work, partly via the CPU and partly by calling OpenGL functions.

With hardware acceleration, Android uses DisplayList instead of direct CPU drawing for each frame during the Draw phase. DisplayList is a record of drawing operations, abstracted as the RenderNode class. This indirect approach offers several advantages:

DisplayList can be drawn multiple times as needed without re-interacting with business logic.
Specific operations (like translation or scaling) can apply to the entire DisplayList without redistributing draw commands.
Once all draw operations are known, they can be optimized (e.g., drawing all text together).
DisplayList processing can be offloaded to another thread (RenderThread).
The main thread can handle other Messages once sync is finished, without waiting for RenderThread to complete.

Detailed RenderThread flow can be found here: http://www.cocoachina.com/articles/35302

Main Thread and Render Thread in Games

Most games use a separate rendering thread with its own Surface and interact directly with SurfaceFlinger. The main thread plays a minimal role, as most logic is implemented within the custom rendering thread.

Check the Systrace for “Honor of Kings” (Honor of Kings), focusing on the application process and SurfaceFlinger process (30fps):

The main thread’s primary job is simply passing Input events to Unity’s rendering thread. The rendering thread then handles logic processing and screen updates.

Main Thread and Render Thread in Flutter

Flutter Apps also show distinct patterns in Systrace. Since Flutter rendering is based on libSkia, it doesn’t use the standard RenderThread. Instead, it builds its own RenderEngine. Flutter’s two most important threads are the UI thread and the GPU thread, corresponding to the Framework and Engine layers mentioned below:

Flutter also listens for Vsync signals. Its VsyncView uses postFrameCallback to monitor doFrame callbacks, then calls nativeOnVsync to pass information to the Flutter UI thread to begin a frame’s drawing.

Flutter’s approach is similar to game development: it doesn’t depend on the specific platform, builds its own rendering pipeline, and offers fast updates and cross-platform advantages.

Flutter SDK includes the Skia library, enabling the latest Skia features without waiting for OS updates. Google has optimized Skia heavily, claiming performance comparable to native apps.

Flutter’s framework is divided into Framework (Dart) and Engine (C++) layers. Apps are built on the Framework, which handles Build, Layout, Paint, and layer generation. The Engine combines those layers, generates textures, and submits data to the GPU via OpenGL.

When the UI needs updating, the Framework notifies the Engine. The Engine waits for the next Vsync, notifies the Framework, which then performs animations, build, layout, compositing, and paint to generate a layer for the Engine. The Engine combines the layers and submits them to the GPU.

Performance

If the main thread handles all tasks, long-running operations (like network access or database queries) will block the entire UI thread. A blocked thread cannot dispatch events, including draw events. Overloading the main thread leads to two major issues:

Jank: If the combined work of the main and rendering threads exceeds 16.6ms (at 60fps), dropped frames occur.
Freeze: If the UI thread is blocked for several seconds (thresholds vary by component), users see the “Application Not Responding“ (ANR) dialog (though some manufacturers skip the dialog and crash to desktop).

These are undesirable for users, so App developers must address them before release. ANR is relatively easy to locate via call stacks, but intermittent jank often requires tools like Systrace + TraceView. Understanding the relationship and mechanics of the main and rendering threads is crucial—this is the primary motivation for this series.

Regarding jank, consult these three articles. A janky App isn’t always the App’s fault; it could be the system. Regardless, you must first know how to analyze it.

References

Attachments

Attachments for this article have been uploaded. Extract and open in Chrome:

Download Systrace attachments for this article

Other Addresses

Please visit the Zhihu or Juejin pages for this article for comments or likes:
Juejin - Systrace Basics - MainThread and RenderThread Explained

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Basics - Input Interpretation

2019-11-04T01:38:29.000Z

This is the sixth article in the Systrace series, primarily providing a brief introduction to Input in Systrace. It covers the Input workflow, how Input information is represented in Systrace, and how to combine Input info to analyze related performance issues.

Series Article Index
Main Content
Input in Systrace
InputDown Event Workflow in SystemServer
InputDown Event Workflow in App
Key Knowledge Points and Processes
Input Refresh and Vsync
Input Debug Information
References
Attachments
Other Addresses
About Me && Blog

Series Article Index

Main Content

In the article Detailed Explanation of Android Rendering Mechanism Based on Choreographer, I mentioned that the execution of an Android App’s main thread is essentially driven by Messages. These Messages can be looping animations, timed tasks, or wake-ups from other threads. However, the most common is the Input Message. Input here refers to the category under InputReader, which includes not only touch events (Down, Up, Move) but also Key events (Home Key, Back Key). In this article, we focus on touch events.

Because the Android system has added Trace points along the Input chain, and these are quite comprehensive, some manufacturers might add their own. However, we’ll focus on standard Trace points here to ensure the information remains consistent across different devices.

Input holds a vital position in Android. Most app scrolling and transitions are driven by Input events. I will eventually write a dedicated article on Android’s Input-based operation mechanism. Here, we look at Input from the perspective of Systrace. Before diving into the flow, keep this general handling process in mind:

The touch screen scans every few milliseconds; if a touch event occurs, it reports it to the corresponding driver.
InputReader reads the touch event and hands it to InputDispatcher for dispatching.
InputDispatcher sends the touch event to the App that registered for Input events.
Once the App receives the event, it performs event distribution. If the App’s UI changes during this process, it requests Vsync, leading to a frame redraw.

Also, when viewing Systrace, remember that time flows from left to right. A vertical line drawn on the Systrace means events to the left always happen before those to the right—this is a cornerstone of our analysis. I hope that after reading these Systrace-based analyses, you’ll have a 3D, graphical flowchart in your mind to quickly locate where your code execution stands.

Input in Systrace

Below is an overview diagram using launcher scrolling as an example (launcher scrolling includes one Input_Down event + several Input_Move events + one Input_Up event, all represented in Systrace, serving as a key entry point for analysis). The main modules involved are SystemServer and the App. Blue identifies event flow information, while red represents auxiliary data.

InputReader and InputDispatcher are two Native threads running within SystemServer, responsible for reading and dispatching Input events. Our Systrace analysis begins here. Below is a brief explanation of the marked numbers in the diagram:

InputReader: Reads Input events from EventHub and passes them to InputDispatcher.
InputDispatcher: Processes events received from InputReader (packaging and dispatching them to the corresponding app).
OutboundQueue: Contains events about to be dispatched to the corresponding AppConnection.
WaitQueue: Records events dispatched to an AppConnection that the App has not yet acknowledged as successfully processed.
PendingInputEventQueue: Records Input events that the App needs to process (now within the application process).
deliverInputEvent: Marks the App UI Thread being woken up by an Input event.
InputResponse: Marks the Input event region, covering the processing stages of Input_Down, Input_Move (multiple), and Input_Up.
App Response to Input Event: This shows the scrolling and subsequent release (fling) actions. Launcher updates the screen as the finger moves and triggers Fling after release; the entire flow is visible in Systrace.

Next, we’ll detail the workflow for the first Input_Down event. Processing for Move and Up events is similar (with minor differences that don’t affect the big picture).

InputDown Event Workflow in SystemServer

Magnifying the SystemServer section reveals the workflow (blue). Launcher scrolling includes Input_Down + several Input_Move + Input_Up; we are looking at the Input_Down event here.

InputDown Event Workflow in App

Upon receiving an Input event, the App may process it immediately (if no Vsync is present) or wait for a Vsync signal. Here, the Input_Down event directly wakes the main thread for processing. Its Systrace is relatively simple: an Input event queue at the top, with the main thread handling it.

App’s Pending Queue

Main Thread Processing Input Events

The main thread processing Input events is a familiar concept. From the call stack below, we see the Input event passed to ViewRootImpl, eventually reaching DecorView, followed by the familiar Input event distribution mechanism.

Key Knowledge Points and Processes

Based on the Systrace above, the basic Input event flow is as follows:

InputReader reads the Input event.
InputReader places the read Input event into the InboundQueue.
InputDispatcher takes the event from InboundQueue and dispatches it to the OutBoundQueue of various Apps (connections).
Simultaneously, the event is recorded in each App’s WaitQueue.
The App receives the Input event, records it in PendingInputEventQueue, and handles its distribution.
After processing, the App calls back InputManagerService to remove the corresponding Input from the WaitQueue.

Through this process, a single Input event is consumed (this is the normal case; many exceptions and details exist). This section explains several important knowledge points from this critical flow (some processes and diagrams reference Gityuan’s blog, linked in the References section).

InputReader

InputReader is a Native thread running in the SystemServer process. Its core functions are reading events from EventHub, processing them, and sending them to InputDispatcher.

The InputReader Loop flow is:

getEvents: Reads events from EventHub (monitoring /dev/input), places them into mEventBuffer (size 256), and converts input_event to RawEvent.
processEventsLocked: Processes events, converting RawEvent -> NotifyKeyArgs (or other NotifyArgs).
QueuedListener->flush: Sends events to the InputDispatcher thread, converting NotifyKeyArgs -> KeyEntry (or EventEntry).

The core loopOnce processing flow is:

Logic of InputReader::loopOnce:

void InputReader::loopOnce() {
    int32_t oldGeneration;
    int32_t timeoutMillis;
    bool inputDevicesChanged = false;
    std::vector inputDevices;
    { // acquire lock
    // ...
    // Get input events and device add/remove events; count is the event number
    size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);
    {
    // ...
        if (count) { // Process events
            processEventsLocked(mEventBuffer, count);
        }
    }
    // ...
    mQueuedListener->flush(); // Send events to InputDispatcher
}

InputDispatcher

After InputReader calls mQueuedListener->flush, Input events are added to InputDispatcher‘s mInboundQueue, waking it up. Systrace shows the InputDispatch thread being woken by InputReader.

Core logic of InputDispatcher:

dispatchOnceInnerLocked(): Takes EventEntry from mInboundQueue. The start time of this method (currentTime) becomes the deliveryTime for subsequent dispatchEntry.
dispatchKeyLocked(): May add doInterceptKeyBeforeDispatchingLockedInterruptible under certain conditions.
enqueueDispatchEntryLocked(): Generates DispatchEntry and adds it to the connection’s outbound queue.
startDispatchCycleLocked(): Takes DispatchEntry from outboundQueue and moves it to the connection’s waitQueue.
InputChannel.sendMessage: Sends the message to the remote process via socket.
runCommandsLockedInterruptible(): Iteratively processes all commands in mCommandQueue (added via postCommandLocked()).

Core processing in dispatchOnceInnerLocked:

void InputDispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {
    if (!mPendingEvent) {
        if (mInboundQueue.isEmpty()) {
            // ...
        } else {
            mPendingEvent = mInboundQueue.dequeueAtHead();
            traceInboundQueueLengthLocked();
        }

        if (mPendingEvent->policyFlags & POLICY_FLAG_PASS_TO_USER) {
            pokeUserActivityLocked(mPendingEvent);
        }

        resetANRTimeoutsLocked();
    }
    case EventEntry::TYPE_MOTION: {
        done = dispatchMotionLocked(currentTime, typedEntry, &dropReason, nextWakeupTime);
        break;
    }

    if (done) {
        if (dropReason != DROP_REASON_NOT_DROPPED) {
            dropInboundEventLocked(mPendingEvent, dropReason);
        }
        mLastDropReason = dropReason;
        releasePendingEventLocked();
        *nextWakeupTime = LONG_LONG_MIN; // force next poll to wake up immediately
    }
}

InboundQueue

When InputDispatcher executes notifyKey, it encapsulates the Input event and places it in InboundQueue. InputDispatcher then retrieves events from here during its processing loop.

OutboundQueue

“Outbound” refers to events leaving for App processing. Each App (Connection) has an OutboundQueue. Events enter InboundQueue and are then dispatched by InputDispatcher to each App’s OutboundQueue.

WaitQueue

Once InputDispatcher dispatches an event, it moves the DispatchEntry from outboundQueue to WaitQueue. When the published event is “finished,” InputManagerService receives a reply and removes the event from WaitQueue. In Systrace, you’ll see the App’s WaitQueue length decrease.

If the main thread is janky, Input events aren’t consumed in time, which manifests in the WaitQueue:

Overall Logic

Diagram from Gityuan’s Blog

Input Refresh and Vsync

Input refresh depends on touch screen sampling. Many screens now use 120Hz or 160Hz, sampling every 8ms or 6.25ms. Let’s see how this looks in Systrace:

In the diagram, InputReader reads data every 6.25ms and hands it to InputDispatcher for dispatching. Is a higher sampling rate always better? Not necessarily. As shown, even if data is read every 6.25ms, the WaitQueue shows the App isn’t consuming it. Why?

The reason is that Apps consume Input events when the Vsync signal arrives. For a 60Hz screen, Vsync intervals are 16.6ms. If two or three Input events occur in that span, only the latest one is usually taken. Therefore:

If screen refresh rate and system FPS are 60, blindly increasing sampling rate has little effect. It might even cause uneven event groups (two vs. three events per Vsync), leading to UI jitter.
At 60Hz/60FPS, a 120Hz sampling rate is sufficient.
At 90Hz/90FPS, 120Hz sampling isn’t enough; a 180Hz sampling rate should be used.

Input Debug Information

Dumpsys Input is primarily for debugging. We can check key information here if issues arise. Command:

1	adb shell dumpsys input

The output is extensive; we’ll focus on Device info, InputReader, and InputDispatcher.

Device Info

Lists currently connected devices; below is a touch-related snippet:

3: main_touch
  Classes: 0x00000015
  Path: /dev/input/event6
  Enabled: true
  Descriptor: 4055b8a032ccf50ef66dbe2ff99f3b2474e9eab5
  Location: main_touch/input0
  ControllerNumber: 0
  UniqueId: 
  Identifier: bus=0x0000, vendor=0xbeef, product=0xdead, version=0x28bb
  KeyLayoutFile: /system/usr/keylayout/main_touch.kl
  KeyCharacterMapFile: /system/usr/keychars/Generic.kcm
  ConfigurationFile: 
  HaveKeyboardLayoutOverlay: false

Input Reader Status

Current Input event display:

Device 3: main_touch
   Generation: 24
   IsExternal: false
   HasMic:     false
   Sources: 0x00005103
   KeyboardType: 1
   Motion Ranges:
     X: source=0x00005002, min=0.000, max=1079.000, flat=0.000, fuzz=0.000, resolution=0.000
     Y: source=0x00005002, min=0.000, max=2231.000, flat=0.000, fuzz=0.000, resolution=0.000
     PRESSURE: source=0x00005002, min=0.000, max=1.000, flat=0.000, fuzz=0.000, resolution=0.000
     SIZE: source=0x00005002, min=0.000, max=1.000, flat=0.000, fuzz=0.000, resolution=0.000
   Keyboard Input Mapper:
     Parameters:
       HasAssociatedDisplay: false
       OrientationAware: false
       HandlesKeyRepeat: false
     KeyboardType: 1
     Orientation: 0
     KeyDowns: 0 keys currently down
     MetaState: 0x0
     DownTime: 521271703875000
   Touch Input Mapper (mode - direct):
     Parameters:
       GestureMode: multi-touch
       DeviceType: touchScreen
       AssociatedDisplay: hasAssociatedDisplay=true, isExternal=false, displayId=''
       OrientationAware: true
     Raw Touch Axes:
       X: min=0, max=1080, flat=0, fuzz=0, resolution=0
       Y: min=0, max=2232, flat=0, fuzz=0, resolution=0
     Viewport: displayId=0, orientation=0, logicalFrame=[0, 0, 1080, 2232], physicalFrame=[0, 0, 1080, 2232], deviceSize=[1080, 2232]
     Last Raw Touch: pointerCount=1
       [0]: id=0, x=660, y=1338, pressure=44, ...
     Last Cooked Touch: pointerCount=1
       [0]: id=0, x=659.389, y=1337.401, ...

InputDispatcher Status

Key InputDispatch information includes:

FocusedApplication: App currently in focus.
FocusedWindow: Window currently in focus.
TouchStatesByDisplay
Windows: All Windows.
MonitoringChannels: Channels corresponding to Windows.
Connections: All connections.
AppSwitch: pending status.
Configuration

Input Dispatcher State:
  DispatchEnabled: 1
  DispatchFrozen: 0
  FocusedApplication: name='AppWindowToken{... Launcher}', dispatchingTimeout=5000.000ms
  FocusedWindow: name='Window{... Launcher}'
  TouchStatesByDisplay:
    0: down=true, split=true, deviceId=3, source=0x00005002
      Windows:
        0: name='Window{... Launcher}', pointerIds=0x80000000, targetFlags=0x105
  Windows:
    9: name='Window{... Launcher}', displayId=0, paused=false, hasFocus=true, visible=true, ...
  MonitoringChannels:
    0: 'WindowManager (server)'
  Connections:
    12: channelName='3c007ad launcher (server)', windowName='Window{... Launcher}', status=NORMAL, ...
      OutboundQueue: 
      WaitQueue: length=3
        MotionEvent(..., action=MOVE, age=17.4ms, wait=16.8ms
        MotionEvent(..., action=MOVE, age=11.1ms, wait=10.4ms
        MotionEvent(..., action=MOVE, age=5.2ms, wait=4.6ms
  AppSwitch: not pending
  Configuration:
    KeyRepeatDelay: 50.0ms
    KeyRepeatTimeout: 500.0ms

References

Portions of this article reference Gityuan’s blog. These articles provide deep dives into code details for those interested after finishing this piece.

Attachments

Attachments for this article have been uploaded. Extract and open in Chrome:
Download Systrace attachments for this article

Other Addresses

For comments or likes, please visit the Zhihu or Juejin pages for this article:
Juejin - Systrace Basics - Input Interpretation

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Analysis of 'Zombie Animations' in the Android Background

2019-10-24T00:27:34.000Z

When an Android app moves to the background, it’s not unusual for it to keep performing work as long as the process isn’t killed—that’s just the nature of Android. However, some apps continue to run “zombie animations”—animations that are completely invisible to the user yet consume precious CPU cycles and battery. When users discover this, the result is often a manual kill, an OS-level background restriction, or an outright uninstallation.

Most developers never notice this issue. However, if you use Systrace regularly, you can easily spot it. If you open several apps, return to the home screen, and capture a trace while swiping between launcher pages, you’ll often see background apps still firing animation callbacks.

“Zombie animations” occur when an app, despite being invisible, continues to push CALLBACK_ANIMATION requests to the Choreographer. Every app is different, but the root cause is usually a missing pause or stop call.

Let’s look at two real-world examples to understand the technical cause and the fix. If you are a developer, I highly recommend checking your app for this behavior—fix it if it’s there, celebrate if it’s not.

Case 1: NetEase News

After using NetEase News and returning to the home screen, we captured a Systrace while swiping. Even in the background, the app is consistently firing doFrame operations (see the red box below).

Zooming in on a single doFrame, we see that while input and traversal (layout/draw) are skipped, the animation callback is executing every single frame.

Analysis of the CPU usage shows that the NetEase News process is one of the top consumers of the foreground CPU budget while in the background. This is a clear case of battery drain.

Further inspection using Method Trace reveals that the issue stems from the Lottie animation library by Airbnb. The animation was set to loop but was never paused when the view became invisible, causing it to trigger onAnimationUpdate indefinitely.

Case 2: QQ Music

Opening QQ Music and then returning to the home screen yields similar results in Systrace and Method Trace.

The Method Trace for QQ Music shows three separate Lottie animations that fail to stop in the background—a slightly more severe case than NetEase News.

Zoomed-in view:

It’s worth noting that this isn’t exclusively a Lottie issue; any standard Android animation can suffer from this if it isn’t properly cleaned up.

Root Cause

The fundamental problem is that the app fails to pause animations when it becomes invisible. Because the app is backgrounded, the system optimizes away input and draw callbacks, but CALLBACK_ANIMATION continues to fire. Since no actual drawing occurs, the CPU cycles spent calculating animation frames are entirely wasted.

Development Recommendation

This issue has been discussed in the Lottie GitHub issues.

Problem Summary from GitHub:

“I noticed quite some CPU usage when the app is in the background… It seems looping animations do not pause/stop when the LottieAnimationView is off screen or the Activity is paused. This is likely due to cleanup code only being in onDetachedFromWindow(), which isn’t always called when an Activity sleeps or when a view’s visibility changes to GONE or INVISIBLE.”

The Solution:
Override onVisibilityChanged in your view or listen to life-cycle events in your Activity/Fragment to explicitly pause animations.

@Override
protected void onVisibilityChanged(@NonNull View changedView, int visibility) {
    super.onVisibilityChanged(changedView, visibility);
    if (visibility == VISIBLE && wasAnimatingWhenVisibilityChanged) {
        resumeAnimation();
    } else {
        if (isAnimating()) {
            wasAnimatingWhenVisibilityChanged = true;
            pauseAnimation();
        } else {
            wasAnimatingWhenVisibilityChanged = false;
        }
    }
}

In short: When your app is invisible, call pauseAnimation() on everything!!

About Me && Blog

(Links and introduction)

Detailed Explanation of Android Rendering Mechanism Based on Choreographer

2019-10-22T10:55:11.000Z

This article introduces Choreographer, a class that app developers rarely encounter but is crucial in the Android Framework rendering pipeline. It covers the background of Choreographer‘s introduction, an overview, source code analysis, its relationship with MessageQueue, its use in APM, and optimization ideas from mobile manufacturers.

Choreographer was introduced to coordinate with Vsync, providing a stable timing for handling Messages in app rendering. When Vsync arrives, the system adjusts the Vsync signal period to control the timing of drawing operations for each frame. Most phones currently have a 60Hz refresh rate (16.6ms). To match this, the system sets the Vsync period to 16.6ms, waking Choreographer every period to perform app drawing—this is its primary role. Understanding Choreographer also helps developers grasp the principles of frame execution and deepens knowledge of Message, Handler, Looper, MessageQueue, Measure, Layout, and Draw.

This is the eighth article in the Systrace series, providing a brief introduction to Choreographer within Systrace.

The purpose of this series is to view the overall operation of the Android system from a different perspective using Systrace, while also providing an alternative angle for learning the Framework. Perhaps you’ve read many articles about the Framework but can never remember the code, or you’re unclear about the execution flow. Maybe from Systrace’s graphical perspective, you can gain a deeper understanding.

Series Article Index

Essence of the Main Thread Mechanism

Before discussing Choreographer, let’s clarify the essence of the Android main thread: it’s effectively a Message processing loop. All operations, including frame rendering, are sent as Messages to the main thread’s MessageQueue. The queue processes a message and waits for the next, as shown:

MethodTrace Illustration

Systrace Illustration

Evolution

In Android versions before Vsync, Messages for rendering frames had no gaps; as soon as one frame finished drawing, the next frame’s Message was processed. This led to unstable frame rates that fluctuated unpredictably:

MethodTrace Illustration

Systrace Illustration

The bottleneck here was dequeueBuffer. Because screens have a fixed refresh cycle and SurfaceFlinger (SF) consumes Front Buffer at a constant rate, SF also consumes App Buffers at a constant rate. Apps would get stuck at dequeueBuffer, resulting in unstable buffer acquisition and frequent jank.

For users, a stable frame rate is a better experience. For example, a stable 50 fps feels smoother than one that fluctuates wildly between 60 and 40 fps.

Android’s evolution introduced Vsync + TripleBuffer + Choreographer, aiming to provide a stable frame rate mechanism that allows software and hardware to operate at a synchronized frequency.

Introducing Choreographer

Choreographer coordinates with Vsync to provide a stable Message processing timing. When Vsync arrives, the system adjusts the signal period to control when each frame is drawn. Vsync typically uses a 16.6ms (60 fps) period to match the 60Hz refresh rate of most phone screens. Every 16.6ms, the Vsync signal wakes Choreographer to perform app drawing. If the app renders within this window every cycle, it achieves 60 fps, appearing very smooth.

With 90Hz screens becoming common, the Vsync period has dropped from 16.6ms to 11.1ms, requiring faster task completion and higher performance. See: A New Smooth Experience: A Talk on 90Hz.

Choreographer Overview

Choreographer acts as a bridge in the Android rendering pipeline:

Upper side: It receives and processes app update messages and callbacks, handling them collectively when Vsync arrives. This includes Input events, Animation logic, and Traversal (measure, layout, draw), while also detecting dropped frames and recording callback durations.
Lower side: It requests and receives Vsync signals, handling event callbacks (via FrameDisplayEventReceiver.onVsync) and scheduling Vsync (FrameDisplayEventReceiver.scheduleVsync).

Choreographer is a vital “utility player.” The Choreographer + SurfaceFlinger + Vsync + TripleBuffer stack ensures Android apps run at a stable frame rate (20, 90, or 60 fps), reducing the discomfort of frame fluctuations.

Understanding Choreographer also clarifies the fundamentals of frame execution and deepens knowledge of Message, Handler, Looper, MessageQueue, Input, Animation, Measure, Layout, and Draw. Many APM tools combine Choreographer (using FrameCallback + FrameInfo) + MessageQueue (using IdleHandler) + Looper (with custom MessageLogging) to optimize performance monitoring.

While diagrams are helpful, I prefer using Systrace and MethodTrace to show system operations (CPU, SurfaceFlinger, SystemServer, Apps) from left to right. Familiarity with the code allows you to map Systrace directly to actual phone behavior. This article will primarily use Systrace.

Choreographer Workflow from a Systrace Perspective

Using Launcher scrolling as an example, here is a complete preview of the App process. Each green frame represents a frame that finally appears on the screen.

Each gray and white bar is a Vsync period (16.6ms).
Frame processing flow: Vsync signal callback -> UI Thread -> RenderThread -> SurfaceFlinger (not shown).
UI Thread and RenderThread together complete an app’s frame rendering. The rendered buffer is sent to SurfaceFlinger for composition, then displayed.
Launcher scrolling frames are very short (Ui Thread + RenderThread time), but still wait for the next Vsync to begin processing.

Zooming into the UI Thread for a single frame, we see Choreogrepher‘s position and how it organizes the frame:

Choreographer Workflow

Initialize Choreographer
1. Initialize FrameHandler, binding it to the Looper.
2. Initialize FrameDisplayEventReceiver to communicate with SurfaceFlinger for Vsync.
3. Initialize CallBackQueues.
SurfaceFlinger’s appEventThread sends Vsync; Choreographer calls FrameDisplayEventReceiver.onVsync, entering the main processing function doFrame.
Choreographer.doFrame calculates dropped frames.
Processes the first callback: input.
Processes the second callback: animation.
Processes the third callback: insets animation.
Processes the fourth callback: traversal.
1. traversal-draw synchronizes UIThread and RenderThread data.
Processes the fifth callback: commit?
RenderThread processes draw commands and sends them to the GPU.
Calls swapBuffer to submit to SurfaceFlinger for composition. (The buffer isn’t truly finished until the CPU completes; newer Systrace versions use GPU fences to mark this).

After step 1, the system loops through steps 2-9.

Here is the corresponding MethodTrace (detailed view following):

Now, let’s examine the implementation via source code.

Source Code Analysis

The following analysis covers important logic, omitting less relevant parts like Native interactions with SurfaceFlinger.

Choreographer Initialization

Singleton Initialization

// Thread local storage for the choreographer.
private static final ThreadLocal sThreadInstance =
        new ThreadLocal() {
    @Override
    protected Choreographer initialValue() {
        // Get current thread Looper
        Looper looper = Looper.myLooper();
        ......
        // Construct Choreographer object
        Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
        if (looper == Looper.getMainLooper()) {
            mMainInstance = choreographer;
        }
        return choreographer;
    }
};

Choreographer Constructor

private Choreographer(Looper looper, int vsyncSource) {
    mLooper = looper;
    // 1. Initialize FrameHandler
    mHandler = new FrameHandler(looper);
    // 2. Initialize DisplayEventReceiver
    mDisplayEventReceiver = USE_VSYNC
            ? new FrameDisplayEventReceiver(looper, vsyncSource)
            : null;
    mLastFrameTimeNanos = Long.MIN_VALUE;
    mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
    // 3. Initialize CallbacksQueues
    mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
    for (int i = 0; i <= CALLBACK_LAST; i++) {
        mCallbackQueues[i] = new CallbackQueue();
    }
    ......
}

FrameHandler

private final class FrameHandler extends Handler {
    ......
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case MSG_DO_FRAME: // Start rendering the next frame
                doFrame(System.nanoTime(), 0);
                break;
            case MSG_DO_SCHEDULE_VSYNC: // Request Vsync 
                doScheduleVsync();
                break;
            case MSG_DO_SCHEDULE_CALLBACK: // Process Callback
                doScheduleCallback(msg.arg1);
                break;
        }
    }
}

Choreographer Initialization Chain

During Activity startup, after onResume, Activity.makeVisible() is called, then addView(), eventually calling:

ActivityThread.handleResumeActivity(IBinder, boolean, boolean, String) (android.app) 
-->WindowManagerImpl.addView(View, LayoutParams) (android.view) 
  -->WindowManagerGlobal.addView(View, LayoutParams, Display, Window) (android.view) 
    -->ViewRootImpl.ViewRootImpl(Context, Display) (android.view) 
    public ViewRootImpl(Context context, Display display) {
        ......
        mChoreographer = Choreographer.getInstance();
        ......
    }

FrameDisplayEventReceiver Overview

FrameDisplayEventReceiver handles Vsync registration, requests, and reception. It inherits from DisplayEventReceiver and has three key methods:

onVsync – Vsync signal callback
run – Executes doFrame
scheduleVsync – Requests the Vsync signal

private final class FrameDisplayEventReceiver extends DisplayEventReceiver implements Runnable {
    ......
    @Override
    public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
        ......
        mTimestampNanos = timestampNanos;
        mFrame = frame;
        Message msg = Message.obtain(mHandler, this);
        msg.setAsynchronous(true);
        mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
    }
    @Override
    public void run() {
        mHavePendingVsync = false;
        doFrame(mTimestampNanos, mFrame);
    }
    
    public void scheduleVsync() {
        ......  
        nativeScheduleVsync(mReceiverPtr);
        ......
    }
}

Vsync Registration in Choreographer

The FrameDisplayEventReceiver.onVsync inner class receives Vsync callbacks and notifies the UIThread. It achieves this by listening to file descriptors initialized as follows:

android/view/Choreographer.java

private Choreographer(Looper looper, int vsyncSource) {
    mLooper = looper;
    mDisplayEventReceiver = USE_VSYNC
            ? new FrameDisplayEventReceiver(looper, vsyncSource)
            : null;
    ......
}

android/view/Choreographer.java

1
2
3

public FrameDisplayEventReceiver(Looper looper, int vsyncSource) {
    super(looper, vsyncSource);
}

android/view/DisplayEventReceiver.java

public DisplayEventReceiver(Looper looper, int vsyncSource) {
    ......
    mMessageQueue = looper.getQueue();
    mReceiverPtr = nativeInit(new WeakReference(this), mMessageQueue,
            vsyncSource);
}

nativeInit uses a BitTube (essentially a socket pair) to pass and request Vsync events. When SurfaceFlinger receives Vsync, its appEventThread sends the event through BitTube to DisplayEventDispatcher, which then triggers Choreographer.FrameDisplayEventReceiver.onVsync, starting frame drawing:

Logic for Processing One Frame

The core logic resides in Choreographer.doFrame. FrameDisplayEventReceiver.onVsync posts itself, and its run method calls doFrame:

android/view/Choreographer.java

public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
    ......
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    Message msg = Message.obtain(mHandler, this);
    msg.setAsynchronous(true);
    mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}
public void run() {
    mHavePendingVsync = false;
    doFrame(mTimestampNanos, mFrame);
}

doFrame performs three main tasks:

Calculates dropped frame logic.
Records frame drawing information.
Executes CALLBACK_INPUT, CALLBACK_ANIMATION, CALLBACK_INSETS_ANIMATION, CALLBACK_TRAVERSAL, and CALLBACK_COMMIT.

Dropped Frame Logic

void doFrame(long frameTimeNanos, int frame) {
    final long startNanos;
    synchronized (mLock) {
        ......
        long intendedFrameTimeNanos = frameTimeNanos;
        startNanos = System.nanoTime();
        final long jitterNanos = startNanos - frameTimeNanos;
        if (jitterNanos >= mFrameIntervalNanos) {
            final long skippedFrames = jitterNanos / mFrameIntervalNanos;
            if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
                Log.i(TAG, "Skipped " + skippedFrames + " frames!  "
                        + "The application may be doing too much work on its main thread.");
            }
        }
        ......
    }
    ......
}

Dropped frame detection uses the difference between when Vsync was supposed to arrive (start_time) and when doFrame actually executes (end_time). This jitter represents the delay, or dropped frames:

Actual Systrace example of dropped frames:

Note: This method calculates jitter for the previous frame, meaning some dropped frames might be missed.

Recording Frame Drawing Info

FrameInfo records key node times (visible via dumpsys gfxinfo). hwui records the remaining parts.

// Various flags set to provide extra metadata about the current frame
private static final int FLAGS = 0;

// Is this the first-draw following a window layout?
public static final long FLAG_WINDOW_LAYOUT_CHANGED = 1;

// A renderer associated with just a Surface, not with a ViewRootImpl instance.
public static final long FLAG_SURFACE_CANVAS = 1 << 2;

@LongDef(flag = true, value = {
        FLAG_WINDOW_LAYOUT_CHANGED, FLAG_SURFACE_CANVAS })
@Retention(RetentionPolicy.SOURCE)
public @interface FrameInfoFlags {}

// The intended vsync time, unadjusted by jitter
private static final int INTENDED_VSYNC = 1;

// Jitter-adjusted vsync time, this is what was used as input into the
// animation & drawing system
private static final int VSYNC = 2;

// The time of the oldest input event
private static final int OLDEST_INPUT_EVENT = 3;

// The time of the newest input event
private static final int NEWEST_INPUT_EVENT = 4;

// When input event handling started
private static final int HANDLE_INPUT_START = 5;

// When animation evaluations started
private static final int ANIMATION_START = 6;

// When ViewRootImpl#performTraversals() started
private static final int PERFORM_TRAVERSALS_START = 7;

// When View:draw() started
private static final int DRAW_START = 8;

doFrame records times from Vsync to markPerformTraversalsStart:

void doFrame(long frameTimeNanos, int frame) {
    ......
    mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);
    // Process CALLBACK_INPUT Callbacks 
    mFrameInfo.markInputHandlingStart();
    // Process CALLBACK_ANIMATION Callbacks
    mFrameInfo.markAnimationsStart();
    // Process CALLBACK_INSETS_ANIMATION Callbacks
    // Process CALLBACK_TRAVERSAL Callbacks
    mFrameInfo.markPerformTraversalsStart();
    // Process CALLBACK_COMMIT Callbacks
    ......
}

Executing Callbacks

void doFrame(long frameTimeNanos, int frame) {
    ......
    // Process CALLBACK_INPUT Callbacks 
    doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
    // Process CALLBACK_ANIMATION Callbacks
    doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
    // Process CALLBACK_INSETS_ANIMATION Callbacks
    doCallbacks(Choreographer.CALLBACK_INSETS_ANIMATION, frameTimeNanos);
    // Process CALLBACK_TRAVERSAL Callbacks
    doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
    // Process CALLBACK_COMMIT Callbacks
    doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
    ......
}

Input Callback Stack

input callback typically executes ViewRootImpl.ConsumeBatchedInputRunnable:

android/view/ViewRootImpl.java

final class ConsumeBatchedInputRunnable implements Runnable {
    @Override
    public void run() {
        doConsumeBatchedInput(mChoreographer.getFrameTimeNanos());
    }
}
void doConsumeBatchedInput(long frameTimeNanos) {
    if (mConsumeBatchedInputScheduled) {
        mConsumeBatchedInputScheduled = false;
        if (mInputEventReceiver != null) {
            if (mInputEventReceiver.consumeBatchedInputEvents(frameTimeNanos)
                    && frameTimeNanos != -1) {
                scheduleConsumeBatchedInput();
            }
        }
        doProcessInputEvents();
    }
}

Input events eventually reach DecorView.dispatchTouchEvent for standard event distribution:

Animation Callback Stack

Commonly used via View.postOnAnimation:

public void postOnAnimation(Runnable action) {
    final AttachInfo attachInfo = mAttachInfo;
    if (attachInfo != null) {
        attachInfo.mViewRootImpl.mChoreographer.postCallback(
                Choreographer.CALLBACK_ANIMATION, action, null);
    } else {
        getRunQueue().post(action);
    }
}

Used for operations like startScroll and Fling:

Here is a fling animation stack:

FrameCallback also uses CALLBACK_ANIMATION:

public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {
    if (callback == null) {
        throw new IllegalArgumentException("callback must not be null");
    }

    postCallbackDelayedInternal(CALLBACK_ANIMATION,
            callback, FRAME_CALLBACK_TOKEN, delayMillis);
}

Traversal Stack

void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        // Post SyncBarrier to prioritize
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
        // Start measure, layout, draw
        doTraversal();
    }
}
void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        // Remove SyncBarrier
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
        performTraversals();
    }
}
private void performTraversals() {
      // measure
      if (focusChangedDueToTouchMode || mWidth != host.getMeasuredWidth() || mHeight != host.getMeasuredHeight() || contentInsetsChanged || updatedConfiguration) {
            performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
      }
      // layout
      if (didLayout) {
          performLayout(lp, mWidth, mHeight);
      }
      // draw
      if (!cancelDraw && !newSurface) {
          performDraw();
      }
}

doTraversal TraceView Example

Requesting the Next Frame’s Vsync

Continuous operations like animations or scrolling need a stable frame output. Every doFrame triggers another Vsync request as needed. invalidate and requestLayout also trigger requests.

ObjectAnimator Animation Logic

android/animation/ObjectAnimator.java

1
2
3

public void start() {
    super.start();
}

android/animation/ValueAnimator.java

private void start(boolean playBackwards) {
    ......
    addAnimationCallback(0); 
    ......
}
private void addAnimationCallback(long delay) {
    ......
    getAnimationHandler().addAnimationFrameCallback(this, delay);
}

android/animation/AnimationHandler.java

public void addAnimationFrameCallback(final AnimationFrameCallback callback, long delay) {
    if (mAnimationCallbacks.size() == 0) {
        getProvider().postFrameCallback(mFrameCallback);
    }
    ......
}

private final Choreographer.FrameCallback mFrameCallback = new Choreographer.FrameCallback() {
    @Override
    public void doFrame(long frameTimeNanos) {
        doAnimationFrame(getProvider().getFrameTime());
        if (mAnimationCallbacks.size() > 0) {
            getProvider().postFrameCallback(this);
        }
    }
};

Animation uses the FrameCallback interface to request the next Vsync for every frame:

Source Code Summary

Choreographer is a thread singleton bound to a Looper (usually the app’s main thread).
DisplayEventReceiver is an abstract class whose JNI part creates an IDisplayEventConnection. Vsync signals from AppEventThread are passed to onVsync.
DisplayEventReceiver.scheduleVsync requests a Vsync interrupt before drawing UI.
Choreographer.FrameCallback is called every Vsync, greatly assisting animation implementation by providing fixed timing.
Choreographer invokes callbacks set via postCallback when Vsync arrives. Five types are defined:
1. CALLBACK_INPUT: Input events.
2. CALLBACK_ANIMATION: Animation logic.
3. CALLBACK_INSETS_ANIMATION: Insets animation.
4. CALLBACK_TRAVERSAL: Measure, layout, draw.
5. CALLBACK_COMMIT: trimMemory and frame monitoring.
ListView item initialization happens within input or animation depending on context.
CALLBACK_INPUT and CALLBACK_ANIMATION execute before CALLBACK_TRAVERSAL because they modify view properties.

APM and Choreographer

Given its position, Choreographer is central to performance monitoring. Analysts use its FrameCallback and FrameInfo interfaces:

FrameCallback.doFrame callbacks.
FrameInfo monitoring (adb shell dumpsys gfxinfo framestats).
SurfaceFlinger monitoring (adb shell dumpsys SurfaceFlinger --latency).
SurfaceFlinger PageFlip mechanism (adb service call SurfaceFlinger 1013).
Choreographer‘s dropped frame calculation.
BlockCanary based on Looper.

Using FrameCallback.doFrame

1
2
3

public interface FrameCallback {
    public void doFrame(long frameTimeNanos);
}

Usage:

1	Choreographer.getInstance().postFrameCallback(youOwnFrameCallback );

TinyDancer uses this to calculate FPS.

Using FrameInfo

adb shell dumpsys gfxinfo framestats output example:

Window: StatusBar
Total frames rendered: 1562
Janky frames: 361 (23.11%)
...
---PROFILEDATA---
Flags,IntendedVsync,Vsync,OldestInputEvent,NewestInputEvent,HandleInputStart,AnimationStart,PerformTraversalsStart,DrawStart,SyncQueued,SyncStart,IssueDrawCommandsStart,SwapBuffers,FrameCompleted,DequeueBufferDuration,QueueBufferDuration,
0,10158314881426,10158314881426,9223372036854775807,0,10158315693363,10158315760759,10158315769821,10158316032165,10158316627842,10158316838988,10158318055915,10158320387269,10158321770654,428000,773000,

Using SurfaceFlinger

Data is in nanoseconds since boot. Each command returns 128 lines of frame data:

Refresh period.
Col 1: App drawing time.
Col 2: Vsync timestamp before submission to hardware.
Col 3: Hardware acceptance time (completion).

Jank is calculated when the jankflag (based on ceil((C - A) / refresh-period)) changes between lines.

Using SurfaceFlinger PageFlip

Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken("android.ui.ISurfaceComposer");
mFlinger.transact(1013, data, reply, 0);
final int pageFlipCount = reply.readInt();
...
mFps = (float) (frames * 1e9 / duration);

BlockCanary

Monitors performance by recording time before and after every Looper message:

public static void loop() {
    ...
    for (;;) {
        ...
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        msg.target.dispatchMessage(msg);
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }
        ...
    }
}

MessageQueue and Choreographer

Asynchronous messages can bypass SyncBarriers. A Barrier blocks all subsequent synchronous messages until removed. This is used in Choreographer to prioritize Traversal messages:

SyncBarrier Example in Choreographer

scheduleTraversals posts a SyncBarrier:

void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    }
}

doTraversal removes it:

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
        performTraversals();
    }
}

Overview of Jank and Frame Drops in Android - Low Memory

2019-09-18T15:21:26.000Z

In the Overview of Jank and Frame Drops in Android - System Layer article, we touched upon jank cases caused by low system memory. Since low memory has a significant impact on overall device performance, I’m dedicating this article to exploring those effects in depth.

As Android versions evolve and apps become more feature-heavy, their memory requirements increase. However, many devices with 4GB of RAM or less are still in use. These users are prone to low memory situations, especially after major system updates or as they install more apps.

Low memory triggers performance issues categorized by slow responsiveness and jank. Examples include longer app launch times, more frame drops in scrolling, more frequent cold starts as background processes are killed, and increased device temperature. Below, I’ll outline the causes, debugging methods, and potential optimizations for these issues.

Identifying Low Memory

Meminfo Data

The simplest way is using dumpsys meminfo:

adb shell dumpsys meminfo
...
Total RAM: 7,658,060K (status moderate)
 Free RAM:   550,200K ...
 Used RAM: 7,718,091K ...
 ZRAM:     ...

Signs of low memory:

Free RAM is very low, while Used RAM is very high.
ZRAM usage is high (if enabled).

LMK and kswapd Activity

During low memory, the Low Memory Killer Daemon (LMKD) becomes active. You’ll see kill messages in the Kernel Log:

1
2
3

[kswapd0] lowmemorykiller: Killing 'u.mzsyncservice' (15609) (tgid 15609), adj 906,
to free 28864kB on behalf of 'kswapd0' ...
cache 258652kB is below limit 261272kB for oom score 906

This means kswapd0 killed a process because memory fell below the threshold for an OOM score of 900.

`/proc/meminfo`

This is how the Linux kernel exposes memory stats. When memory is low, MemFree and MemAvailable will be minimal.

System-wide Lag & Slow Response

When the system is in a low memory state, the entire device feels much more sluggish compared to normal memory conditions. Clicking on apps or launching applications will feel unresponsive or slow.

Impact of Low Memory on Performance

Main Thread I/O Latency

Low memory causes significant I/O issues.

In a Systrace, this appears as many yellow/orange thread states: Uninterruptible Sleep | WakeKill - Block I/O.
Block sites usually look like: wait_on_page_bit_killable+0x78/0x88.

The Linux page cache chain sometimes contains pages that aren’t ready (content hasn’t been fully read from disk). If a user accesses such a page, it blocks on wait_on_page_locked_killable. Under heavy I/O, these I/O operations queue up, leading to long block durations.

When I/O is heavy, app operations involving disk access (loading views, reading files, configs, or odex files) trigger Uninterruptible Sleep, significantly slowing down the app.

CPU Contention

Low memory forces the Low Memory Killer to scan and kill processes frequently. kswapd0 (a kernel worker thread) wakes up to perform memory reclamation. If memory sticks near low levels, kswapd0 remains active, consuming CPU cycles and generating heat.

If kswapd0 or HeapTaskDaemon (which handles JVM memory operations) hogs a big core (e.g., CPU 7), the foreground app’s main thread might compete for that core, leading to missed Vsync.

HeapTaskDaemon also typically runs at high frequency during low memory conditions.

, performing memory-related operations.

Process Death-Restart Cycles

As LMK kills “Cached” processes, their parent processes or other apps often immediately restart them, leading to a “death-restart” cycle. This puts immense strain on CPU, Memory, and I/O.

For example, below is the result after a Monkey test, where QQ is frequently killed and restarted in a short period:

07-23 14:32:16.932  1435  1510 I am_proc_start: [0,30387,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:16.969  1435  3420 I am_proc_bound: [0,30387,com.tencent.mobileqq]
07-23 14:32:16.979  1435  3420 I am_kill : [0,30387,com.tencent.mobileqq,901,empty #3]
07-23 14:32:16.996  1435  3420 I am_proc_died: [0,30387,com.tencent.mobileqq,901,18]
07-23 14:32:17.028  1435  1510 I am_proc_start: [0,30400,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.054  1435  3420 I am_proc_bound: [0,30400,com.tencent.mobileqq]
07-23 14:32:17.064  1435  3420 I am_kill : [0,30400,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.082  1435  3420 I am_proc_died: [0,30400,com.tencent.mobileqq,901,18]
07-23 14:32:17.114  1435  1510 I am_proc_start: [0,30413,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.139  1435  3420 I am_proc_bound: [0,30413,com.tencent.mobileqq]
07-23 14:32:17.149  1435  3420 I am_kill : [0,30413,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.166  1435  3420 I am_proc_died: [0,30413,com.tencent.mobileqq,901,18]
07-23 14:32:17.202  1435  1510 I am_proc_start: [0,30427,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.216  1435  3420 I am_proc_bound: [0,30427,com.tencent.mobileqq]
07-23 14:32:17.226  1435  3420 I am_kill : [0,30427,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.249  1435  3420 I am_proc_died: [0,30427,com.tencent.mobileqq,901,18]
07-23 14:32:17.278  1435  1510 I am_proc_start: [0,30440,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.299  1435  3420 I am_proc_bound: [0,30440,com.tencent.mobileqq]
07-23 14:32:17.309  1435  3420 I am_kill : [0,30440,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.329  1435  2116 I am_proc_died: [0,30440,com.tencent.mobileqq,901,18]
07-23 14:32:17.362  1435  1510 I am_proc_start: [0,30453,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.387  1435  2116 I am_proc_bound: [0,30453,com.tencent.mobileqq]
07-23 14:32:17.398  1435  2116 I am_kill : [0,30453,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.420  1435  2116 I am_proc_died: [0,30453,com.tencent.mobileqq,901,18]
07-23 14:32:17.447  1435  1510 I am_proc_start: [0,30466,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.474  1435  2116 I am_proc_bound: [0,30466,com.tencent.mobileqq]
07-23 14:32:17.484  1435  2116 I am_kill : [0,30466,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.507  1435  2116 I am_proc_died: [0,30466,com.tencent.mobileqq,901,18]
07-23 14:32:17.533  1435  1510 I am_proc_start: [0,30479,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.556  1435  2116 I am_proc_bound: [0,30479,com.tencent.mobileqq]
07-23 14:32:17.566  1435  2116 I am_kill : [0,30479,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.587  1435  2116 I am_proc_died: [0,30479,com.tencent.mobileqq,901,18]
07-23 14:32:17.613  1435  1510 I am_proc_start: [0,30492,10145,com.tencent.mobileqq,restart,com.tencent.mobileqq]
07-23 14:32:17.636  1435  2116 I am_proc_bound: [0,30492,com.tencent.mobileqq]
07-23 14:32:17.646  1435  2116 I am_kill : [0,30492,com.tencent.mobileqq,901,empty #3]
07-23 14:32:17.667  1435  2116 I am_proc_died: [0,30492,com.tencent.mobileqq,901,18]

The corresponding Systrace - SystemServer shows AM (Activity Manager) frequently killing and restarting QQ:

The Kernel section of this trace also shows busy CPU activity:

Memory Reclamation and I/O Triggers

When operations slow down over time, it’s often due to memory reclamation (Fast Path, kswapd, Direct Reclaim, LMK).

Reclaiming anonymous pages involves swapping them out.
Reclaiming file-backed pages involves writing back and clearing them.
Both actions, especially those involving files, increase the probability of block I/O.

A common scenario: reopening a recent app feels slow because of a do_page_fault. If the memory was swapped out, it must be swapped in. If it was a regular file, it must be read into the page cache from disk.

do_page_fault → lock_page_or_retry → wait_on_page_bit_killable checks if the page has the PG_locked flag set. If set, it blocks until PG_locked is cleared. The PG_locked flag is cleared only when writeback starts or I/O read completes. The readahead to pagecache functionality also affects block I/O - if too large, it increases blocking probability.

Case Study: App Startup Under Low Memory

Below is a trace of an app’s cold start under low memory, from bindApplication to the first frame (total 2s).

Low Memory Startup

Total time: 2s.
Uninterruptible Sleep (I/O block) took ~750ms (vs ~130ms normally).
Running time was ~600ms (similar to normal).
CPU activity: Many kworker and kswapd0 threads were active alongside the app.

Normal Memory Startup

Total time: 1.22s.
Uninterruptible Sleep totaled only 130ms.
CPU activity: Very few memory/IO-related threads beyond HeapTaskDaemon.

Looking at CPU usage during this period, besides HeapTaskDaemon running more frequently, very few other memory and I/O related processes are active.

Optimization Strategies

Optimizing for low memory requires balancing system control and user experience. Managing third-party apps—many of which use aggressive keep-alive and background services—is crucial.

Tune extra_free_kbytes: Increase the threshold for memory reclamation.
Increase Disk I/O Speeds: Use UFS 3.0 or better storage hardware.
Optimize read_ahead_kb: Avoid excessively high values that increase block probability.
Cgroup blkio: Use cgroups to limit background I/O, prioritizing foreground responsiveness.
Proactive Reclamation: Reclaim memory before the user interacts with the app.
LMK Efficiency: Ensure LMK kills the most effective targets to avoid “death-restart” loops.
Refine swappiness: Balance anonymous page swapping vs. file cache clearing.
OEM Policies: Implement more aggressive process management on low-RAM devices.
User Education: Suggest restarting the phone or clearing background apps when memory is critically low.
Strategy: Alert users (or not alert users) to kill unnecessary background processes when memory is insufficient
Strategy: Prompt users to restart the phone when memory is severely insufficient and cannot recover

References

About Me && Blog

Below are personal introductions and related links. Looking forward to exchanging ideas with fellow professionals - when three people walk together, one must be my teacher!

Blogger’s Personal Introduction: Contains personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Personally Organized and Collected Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome self-recommendations and recommendations (private WeChat chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support!

One person can walk faster, but a group of people can walk farther

Case Study: Debugging the Android Launcher Kill Problem

2019-09-17T10:58:11.000Z

This article was inspired by a real-world bug I encountered. While the issue itself wasn’t particularly “hard,” the analysis process—the tools used, the investigative logic, and some clever tips I learned from a colleague—made it a perfect candidate for a case study.

I’ve used a variety of tools mentioned in my Android Performance Optimization Methodology, including:

Reproduction Video
Event Log
AS Source/Debug
AS Profiler
Systrace
Dumpsys
Unix ps utility

My goal is to document this process for myself and to share a universal troubleshooting workflow that might help others. If you have your own debugging tips, feel free to join our discussion group!

The Phenomenon

Testing reported a classic performance bug: “Slow loading of icons when returning to the home screen.” They provided a video, logs, and a Systrace.

The Analysis

1. Zeroing in on the Time

Reproduction Video: I watched the video to find the exact minute the issue occurred.
Event Log: I cross-referenced the video time with the Event Log to find the precise second.
Operation Reconstruction: By reading the Event and Main logs, I reconstructed the user’s actions. Every time the app com.jx.cmcc.ict.ibelieve was launched, the Launcher was killed.

EventLog Snippet:
// App Launch: com.jx.cmcc.ict.ibelieve
09-10 10:14:48.877 ... I am_set_resumed_activity: [0,com.jx.cmcc.ict.ibelieve/.ui.MainTabActivity,...]

// LAUNCHER IS KILLED HERE
09-10 10:14:48.903 ... I am_kill : [0,13509,com.meizu.flyme.launcher,600,kill background]

// Returning to Launcher
09-10 10:14:51.990 ... I am_pause_activity: [0, ...MainTabActivity]

// Re-creating Launcher Process
09-10 10:14:52.025 ... I am_proc_start: [0,14013,10021,com.meizu.flyme.launcher,activity,...]
09-10 10:14:52.437 ... I am_activity_launch_time: [0, ...Launcher,413,413]

Initial Conclusion: The “slow loading” reported by testing is because the Launcher process was killed in the background. When the user returns to the home screen, the Launcher has to perform a cold start. While the log says 413ms for the Activity launch, the total time until icons appear is much longer (~2s) because it has to reload all content from the database.

2. Investigating the Kill Reason

The log says: am_kill : [..., kill background].
In the AOSP source code, kill background as a reason is issued specifically in AMS.killBackgroundProcesses.

// ActivityManagerService.java
public void killBackgroundProcesses(final String packageName, int userId) {
    synchronized (this) {
        killPackageProcessesLocked(packageName, appId, targetUserId,
                ProcessList.SERVICE_ADJ, false, true, true, false, "kill background");
    }
}

This method is exposed to third-party apps via ActivityManager.killBackgroundProcesses(packageName).

3. Debugging SystemServer

We need to catch which app is calling this method. I set a breakpoint in ActivityManagerService.killBackgroundProcesses inside the system_process process.

Attach the debugger to system_process.
Launch the suspicious app.
The breakpoint hits! I use the expression evaluator to find the caller PID: getRealCallingPid().
- Result: 29771.
Checking ps -A | grep 29771: It’s com.jx.cmcc.ict.ibelieve.

4. Debugging the App

To confirm, I attached a debugger to the app process itself. Since I don’t have its source, I placed a breakpoint in the public SDK method android.app.ActivityManager.killBackgroundProcesses.

Every time I log into the app and go back to the home screen, the breakpoint hits. The app is actively killing the background environment.

5. Identifying the Root Code using AS Profiler

Using the Android Studio Profiler (CPU -> Trace Java Methods), I recorded a trace while the app was running. After stopping the record, I searched the call stack for killBackgroundProcesses.

The trace showed that inside its loadComplete callback, the app explicitly calls its own killBackground utility method. (This is where the app developer would go to fix the bug).

6. Permission Analysis

killBackgroundProcesses requires the Manifest.permission.KILL_BACKGROUND_PROCESSES permission.
Checking dumpsys package com.jx.cmcc.ict.ibelieve:

1 2	install permissions: android.permission.KILL_BACKGROUND_PROCESSES: granted=true

This is a “normal” level permission. This means any app can request it in the manifest and the system will grant it automatically without a user prompt. In this case, a developer used it—either accidentally or over-zealously—to “clean up” memory, but accidentally nuked the launcher in the process.

7. Can Systrace find the Culprit?

Yes. If you trace the killProcessGroup event in the system_server process, you can look for the “Waking From” thread.

Find killProcessGroup in system_server.
Follow the wakeup chain back.
It leads back to a Binder thread in system_server, which was triggered by the main thread of PID 7289 (com.jx.cmcc.ict.ibelieve).

Conclusion

This issue was caused by an app requesting a powerful permission and using it incorrectly. It shows that even a “simple” app can severely degrade the OS experience if it plays loose with system-level APIs.

Interestingly, Google allows the KILL_BACKGROUND_PROCESSES permission at the “normal” level. Given it affects the lifecycle of other apps, one might argue it should be a more restricted permission.

About Me && Blog

(Links and introduction)

Overview of Jank and Frame Drops in Android - Application Layer

2019-09-05T12:35:42.000Z

In the Overview of Jank and Frame Drops in Android - System Layer article, we listed causes of jank originating from the system. In this article, we focus on causes stemming from the App itself. When you encounter lag, before blaming the phone manufacturer, consider if it’s the App’s own inefficiency.

Jank issues are a top priority for both phone manufacturers and app developers, often handled by dedicated “Performance” or “Stability” teams. Third-party tools like Tencent’s Matrix are excellent, but manufacturers often have proprietary solutions with deeper system access through source code modification.

Smoothness refers to frame drops. If the screen fails to refresh at 60 FPS (or the target refresh rate) and only hits 55, the user perceives this as jank. Frame rate fluctuations are especially noticeable.

This series includes:
0. Overview of Jank and Frame Drops in Android - Methodology

Application-Side Performance Issues

As noted in the system-layer article, many of these cases can be identified using Systrace. If you’re unfamiliar, see the Systrace Series. Systrace provides a global view of the system’s operating state.

1. App Main Thread Execution Overhead

Operations like Input processing, Animation execution, Measure, Layout, Draw, and decodeBitmap on the main thread can cause jank if they exceed the frame budget.

Measure / Layout Overhead

If the view hierarchy is too complex, onMeasure and onLayout can take a significant amount of time, delaying the frame.

Draw Overhead

Complex custom drawing or heavy canvas operations contribute to main thread latency.

Animation Callback Overhead

Long-running logic within Animation callbacks or Choreographer frames will delay the start of the rendering pipeline.

View Initialization Overhead (PlayStore Example)

Inflating complex XML layouts on the main thread is a common source of jank during navigation.

List Item Initialization Overhead (WeChat Example)

Inefficient getView or onBindViewHolder implementations in lists lead to stutter during scrolling.

decodeBitmap Overhead

Decoding large images on the main thread is a classic performance anti-pattern.

2. uploadBitmap Overhead

This refers to uploading a bitmap to the GPU (texture upload). Large bitmaps or textures that change every frame increase RenderThread workload significantly.

3. BuildDrawingCache Overhead

Frequent calls to buildDrawingCache can cause the main thread to exceed the Vsync period. WeChat’s dynamic stickers sometimes suffer from this.

4. Software Rendering vs. Hardware Rendering

If an Activity explicitly disables hardware acceleration, drawing falls back to Skia on the CPU. This significantly increases UI Thread load and almost always results in lag. For more, see Detailed Explanation of Hardware Layer in Android.

5. Main Thread Binder Latency

During Activity Resume, communicating with AMS requires the AMS lock. If the background is busy, waiting for this lock can cause delays, especially during multi-tasking gestures.

6. Uneven Game Content Drawing (SurfaceView)

In games, even if SF is ready, the game engine might deliver frames unevenly. If a game frame misses the SF Vsync window, it will be dropped.

7. WebView Inefficiency

Complex web pages in a WebView often exhibit poor performance since the WebView’s rendering can be heavier than native components.

8. Refresh Rate Mismatch

A mismatch between the screen’s refresh rate and the content’s FPS can cause a lack of fluidity, such as 60 FPS animations on a 90 Hz screen.

9. Incompatibility with High Refresh Rates

Apps designed for 60 FPS machines (16.6ms budget) might struggle on 90 Hz or 120 Hz screens (11.1ms or 8.3ms budget). If drawing takes 14ms, it’s fine for 60Hz but will stutter on 90Hz.

10. Main Thread I/O Operations

Classic issues include performing database queries or using SharedPreferences.commit() (which is synchronous) instead of apply() on the main thread.

11. WebView/Main Thread Interaction

Synchronization issues or heavy JS-to-Native bridges between a WebView and the main thread can cause freezing.

12. RenderThread Overhead

If the RenderThread itself is overloaded (too many GPU commands), the total frame time will exceed the Vsync interval. This also blocks the main thread’s next sync operation.

13. Multiple RenderThreads Synchronization

Some apps spawn multiple RenderThreads. Synchronizing these threads can sometimes incur significant overhead, blocking the main thread.

Summary

Android is an evolving platform, but its openness means app quality varies wildly. Unlike the tightly controlled App Store, Android apps come from many sources with varying levels of quality control.

Large companies usually prioritize performance, but feature bloat (like WeChat’s memory footprint or QQ’s increasing complexity) still leads to issues. Smaller devs might lack the resources for deep optimization. Furthermore, “black tech” tactics like aggressive keep-alive, mutual wake-ups, and heavy background tasks degrade the overall user experience.

When we find app-specific performance flaws that persist across different hardware, we often reach out to the developers to collaborate on a fix.

For more details on what OEMs do, see: What do phone manufacturers actually do when they say they are optimizing Android?

This series includes:
0. Overview of Jank and Frame Drops in Android - Methodology

About Me && Blog

(Links and introduction)

Overview of Jank and Frame Drops in Android - System Layer

2019-09-05T12:35:35.000Z

In the Overview of Jank and Frame Drops in Android - Application Layer article, we listed causes of jank originating from the app itself. In this article, we focus on causes stemming from the Android platform. Due to differences in hardware performance, feature implementations, and engineering capabilities among Android OEMs, system quality varies significantly. Here, we’ll categorize performance issues caused by system hardware and software.

This series includes:
0. Overview of Jank and Frame Drops in Android - Methodology

System-Level Performance Case Studies

Below are actual cases of jank caused by Android platform issues. Some issues are caught during development, while others only emerge after long-term use or in specific scenarios.

Many of these cases are visible in Systrace. If you’re unfamiliar, see the Systrace Series. Systrace provides a global view of the system’s operating state.

1. SurfaceFlinger Main Thread Overhead

SurfaceFlinger handles surface composition. If its main thread exceeds the timing threshold, frame drops occur. This also delays HWC Service and CRTC, and blocks app Binder calls like dequeueBuffer and queueBuffer.

(Example Systraces show SF main thread timeouts leading to yellow/dropped frames in apps).

2. Under-Screen Ambient Light Sensor Screenshots

Some phones use under-screen sensors. If the implementation requires frequent screenshots to distinguish light changes, the screenshot operation can block the SurfaceFlinger main thread, causing jank.

3. HWC Service Execution Overhead

If the HWC Service is slow, SurfaceFlinger might fail to compose the next frame, blocking app dequeueBuffer and setTransactionState calls.

4. CRTC Execution Overhead

Slow CRTC (Display Controller) execution similarly prevents SurfaceFlinger composition and blocks app Binder returns.

5. CPU Scheduling Issues

Critical Tasks on Small Cores

If RenderThread is scheduled on a small core with lower performance, execution time increases, causing jank.

Low Priority and Slice Delays

Tasks that are low priority to the Linux scheduler might be critical to the user (e.g., interacting with the app’s main thread). Delay in getting CPU time leads to lag.

Preemption by RT Processes

App MainThread or RenderThread being preempted by Real-Time (RT) processes causes responsiveness issues. Google has considered making App threads RT during startup, but this can actually slow down startup due to system contention.

Core Binding and Migration

Issues occur when tasks that need big cores run on small ones, or vice versa. Incorrectly binding a task to a specific busy core can also cause failure (e.g., CTS failures due to core 7 being hogged by RenderThread).

6. Thermal Throttling

Thermal protection is a hardware-level safety measure. Overheating triggers CPU/GPU frequency caps to cool down the device, which inevitably impacts smoothness. If your phone is hot and laggy, it’s a protection mechanism.

7. High Background Activity

Too many background processes hog CPU, I/O, and Memory, making the system “busy.”

CPU Saturation

dumpsys cpuinfo reveals high overall usage.

Runnable Thread States

If a thread is in Runnable state but the scheduler can’t find time for it, it misses Vsync, causing jank.

Irrelevant Active Processes

Processes unrelated to the current foreground app (system or third-party) compete for resources and delay App MainThread scheduling.

Memory Reclamation Overhead

When memory is low, HeapTaskDaemon and kswapd0 hog CPU to reclaim memory, starving other processes.

System Lock Contention

system_server AMS and WMS locks can become massive bottlenecks. If these locks are held too long, app Binder requests enter a wait state, causing jank in animations and interactions.

8. Excessive Layers

In Android P+, Layer computation happens in the SF main thread. If there are too many background layers, rebuildLayerStacks takes too long, slowing down SurfaceFlinger. Clearing background tasks helps.

9. Uneven Input Reporting

If input events (touch/gestures) are reported unevenly or not at all, the main thread won’t draw, appearing as jank in scrolling.

10. LMK Resource Competition

Low Memory Killer (LMK) activity consumes resources. Processes being killed and immediately restarted by their parent create a “death-restart cycle” that drains CPU. Frequent GCs and heavy I/O (swapping) further deteriorate performance.

11. Low Memory I/O Latency

Low memory leads to increased disk I/O (swapping/paging). Since disk I/O is slow, main threads often enter “Uninterruptible Sleep” (State D), causing jank in list scrolling and app startup.

12. GPU Composition Overhead

When SurfaceFlinger falls back to GPU composition, its main thread execution time spikes, potentially missing Vsync.

13. KSWAPD on Big Cores

Under heavy memory pressure, kswapd might hog big cores, causing thermal throttling or preempting critical app threads.

14. Uneven SurfaceFlinger Vsync

If the interval between SF Vsyncs becomes inconsistent (due to SF or HWC bugs), the user perceives uneven, stuttery motion.

15. Accessibility Services

Third-party apps using Accessibility Services to monitor input events can disrupt InputDispatcher behavior, delaying event delivery to the app’s main thread.

Summary

Android is a constantly evolving system. Each version solves many performance issues but might introduce new ones. OEMs add substantial custom code, which further impacts performance.

The cases above are just the tip of the iceberg. This is why manufacturers are investing heavily in optimization—from hardware/kernel levels to dynamic system policies and AI-driven behavior learning. Those who neglect quality for pure design often lose their market share.

For more details on what OEMs do, see: What do phone manufacturers actually do when they say they are optimizing Android?

This series continues:
0. Overview of Jank and Frame Drops in Android - Methodology

About Me && Blog

(Links and introduction)

Overview of Jank and Frame Drops in Android - Methodology

2019-09-05T04:56:42.000Z

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.

About Me && Blog

(Links and introduction)

A Detailed Guide to Activity Launch Modes in Android

2019-09-01T04:37:47.000Z

Android Activities have several critical launch modes: standard, singleTop, singleTask, and singleInstance. Each serves a specific architectural purpose. In this post, I’ll demonstrate their behaviors using a demo and visualizing the Activity Stack at each step.

An Activity Stack is a Last-In-First-Out (LIFO) data structure. Paying attention to the “Stack Content” column in the examples below will help you grasp how these modes differ in practice.

The demo code is available on GitLab: AndroidLaunchModeTest.

standard Mode

1	android:launchMode="standard"

The default mode. A new instance of the Activity is created every time it is started.

Test Trace:

Launch MainActivity
- Stack: MainActivity
Launch StandardActivity
- Stack: StandardActivity -> MainActivity
Launch StandardActivity again
- Stack: StandardActivity (new) -> StandardActivity -> MainActivity

singleTop Mode

1	android:launchMode="singleTop"

If an instance of the Activity already exists at the top of the current stack, the system routes the intent to that instance via onNewIntent(). Otherwise, a new instance is created.

Test 1: singleTopActivity is NOT at the top

MainActivity -> StandardActivity
- Stack: StandardAntivity, MainActivity
Launch singleTopActivity
- Stack: singleTopActivity, StandardActivity, MainActivity
Launch StandardActivity
- Stack: StandardActivity, singleTopActivity, StandardActivity, MainActivity
Launch singleTopActivity
- Stack: singleTopActivity (new), StandardActivity, singleTopActivity, StandardActivity, MainActivity
- Note: Because StandardActivity was at the top, a new instance was created.

Test 2: singleTopActivity IS at the top

Stack: singleTopActivity, StandardActivity, MainActivity
Launch singleTopActivity again
- Stack: singleTopActivity (reused), StandardActivity, MainActivity
- Note: am_new_intent is triggered instead of onCreate.

singleTask Mode

1	android:launchMode="singleTask"

Task Reuse: If an instance exists anywhere in the task, the system brings it to the front and calls onNewIntent().
Clear-Top: All Activities sitting on top of the reused singleTask Activity are destroyed.
Affinity: By default, it stays in the same task. If taskAffinity is specified, it might start in a new task.

Test 1: singleTask (Default Affinity)

Stack: StandardActivity, singleTaskActivity, StandardActivity, MainActivity
Launch singleTaskActivity
- Stack: singleTaskActivity (reused), StandardActivity, MainActivity
- Note: The intermediate StandardActivity was cleared.

Test 2: singleTask (With taskAffinity)
If android:taskAffinity="" is set, singleTask will launch into a new task.

Launch singleTaskWithAffinity
- Task 1: singleTaskWithAffinity
- Task 0: StandardActivity, MainActivity
Launch StandardActivity (from Task 1)
- Task 1: StandardActivity, singleTaskWithAffinity
Launch singleTaskWithAffinity again
- Task 1: singleTaskWithAffinity (reused)
- Note: Both activities exist in separate stacks/tasks in the Recent Apps view.

singleInstance Mode

1	android:launchMode="singleInstance"

As the name suggests, this is a truly unique instance. The system creates a dedicated task for this Activity, and it is the only Activity in that task.

Test 1: singleInstance (Default Affinity)

Stack 0: StandardActivity, MainActivity
Launch singleInstanceActivity
- Stack 1: singleInstanceActivity
- Stack 0: StandardActivity, MainActivity
Launch StandardActivity (from Stack 1)
- Stack 1: singleInstanceActivity
- Stack 0: StandardActivity (new), StandardActivity, MainActivity
- Note: The new Activity is pushed back to the previous “home” task, leaving singleInstanceActivity alone in its task.

Summary:

singleInstance creates a new task but doesn’t necessarily show up as a separate item in “Recents” unless a unique taskAffinity is also set.
It is globally unique.

Key Concepts

TaskAffinity

The task an Activity “prefers” to belong to. Activities with the same affinity belong to the same parent task. Defaults to the package name. Used with singleTask or allowTaskReparenting.

Relationships: ActivityRecord, TaskRecord, ActivityStack

ActivityRecord: Represents a single Activity instance. One Activity defined in XML can have multiple ActivityRecords if started multiple times.
TaskRecord: A “task” or “stack” of ActivityRecords (LIFO).
ActivityStack: Manages multiple TaskRecords. Usually, a system has a “Home Stack” and an “App Stack.”

Activity Types

ACTIVITY_TYPE_STANDARD: Your typical app Activity.
ACTIVITY_TYPE_HOME: The Launcher.
ACTIVITY_TYPE_RECENTS: The Overview screen.
ACTIVITY_TYPE_ASSISTANT: Voice assistants.

About Me && Blog

(Links and introduction)

A Deep Dive into Hardware Layers in Android

2019-07-27T06:09:13.000Z

Hardware Acceleration vs. Software Acceleration

Many people confuse “hardware acceleration” with “Hardware Layer” in Android, assuming that enabling hardware acceleration means enabling Hardware Layer. So before we talk about Hardware Layer, let’s first talk about hardware acceleration.

For more detailed articles about hardware acceleration, I recommend these three:

Hardware acceleration should actually be called GPU acceleration. The main difference between software and hardware acceleration is whether the graphics rendering is handled by the GPU or CPU. If it’s handled by the GPU, it’s considered hardware-accelerated rendering; otherwise, it’s software rendering.

In current Android versions, hardware acceleration is enabled by default. If your app doesn’t explicitly declare otherwise, hardware acceleration is turned on by default.

The three articles above introduce hardware acceleration in detail at both the code level and principle level. Here, I’ll show you from the perspective of Systrace the differences between hardware-accelerated and software-accelerated app rendering.

Hardware-Accelerated App Performance

Since hardware acceleration is enabled by default, let’s take the most common scenario of scrolling the home screen as an example to see how a hardware-accelerated app appears in Systrace.

In hardware-accelerated mode, the app has both a main thread and a render thread. A frame’s rendering is executed cooperatively by the main thread and the render thread.

Let’s zoom in on the Systrace to see how the main thread and render thread work together for each frame, and when the GPU actually intervenes to implement “acceleration.”

The GPU’s actual intervention occurs during certain operations in the RenderThread.

Software-Accelerated App Performance

Correspondingly, let’s find an app for software-accelerated demonstration: Yun Shan Fu (Cloud Flash Pay).

First, let’s look at a panoramic view. You can see that under software rendering, there’s only a main thread and no render thread. All rendering work is completed on the main thread. At the same time, you can see that under software rendering, the execution time of each frame is very long, exceeding one Vsync period, so when scrolling, it stutters frame by frame, which is very uncomfortable. Download Systrace

Let’s zoom in on the Systrace to see how the main thread works for each frame.

Summary

From the comparison above and by reading the three recommended articles, you should have a clear understanding of the difference between hardware rendering and software rendering. Let’s summarize here:

In hardware rendering mode, the app has both a main thread and a render thread; in software rendering mode, the app has only a main thread and no render thread.
In hardware rendering mode, the app’s final rendering is implemented with the help of the GPU; in software rendering mode, the app’s final rendering is implemented using the CPU (calling the Skia library).
In hardware rendering mode, the app’s performance is superior to software rendering.
Since some APIs are not supported by hardware rendering, they can only use software rendering. When doing app development, you should try to avoid using such APIs (you can check the support status directly in Android official documentation: https://developer.android.google.cn/guide/topics/graphics/hardware-accel)

Software Layer vs. Hardware Layer

After finishing with hardware rendering, let’s talk about Software Layer and Hardware Layer. These two concepts mainly refer to Views and are not directly related to whether the app is using hardware rendering or software rendering at this time (though there is a dependency relationship, which will be discussed later).

A View’s layerType has three states (the English text is from official documentation, let’s read the English first and then I’ll explain):

LAYER_TYPE_NONE: Indicates that the view does not have a layer.
LAYER_TYPE_SOFTWARE: Indicates that the view has a software layer. A software layer is backed by a Bitmap and causes the view to be rendered using Android’s software rendering pipeline, even if hardware acceleration is enabled.
LAYER_TYPE_HARDWARE: Indicates that the view has a hardware layer. A hardware layer is backed by a hardware-specific texture (generally Frame Buffer Objects or FBO on OpenGL hardware) and causes the view to be rendered using Android’s hardware rendering pipeline, but only if hardware acceleration is turned on for the view hierarchy. When hardware acceleration is turned off, hardware layers behave exactly as LAYER_TYPE_SOFTWARE.

LAYER_TYPE_NONE

By default, all Views have this layerType. In this case, the View doesn’t receive any special handling and goes through the normal rendering pipeline.

LAYER_TYPE_SOFTWARE

Software layerType indicates that this View has a software-implemented Layer. How is it implemented in software? Essentially, this View is converted into a Bitmap object based on certain conditions.

1
2
3

android/view/View.java
Bitmap bitmap = createBitmap(mResources.getDisplayMetrics(),
    width, height, quality);

The role of Software layer:

When the application is not using hardware acceleration, a software layer is useful to apply a specific color filter and/or blending mode and/or alpha to a view and all its children.
When the application is using hardware acceleration, a software layer is useful to render drawing primitives not supported by the hardware-accelerated pipeline. It can also be used to cache a complex view tree into a texture and reduce the complexity of drawing operations. For instance, when animating a complex view tree with a translation, a software layer can be used to render the view tree only once.
Software layers should be avoided when the affected view tree updates often. Every update will require re-rendering the software layer, which can potentially be slow (particularly when hardware acceleration is turned on since the layer will have to be uploaded into a hardware texture after every update).

LAYER_TYPE_HARDWARE

Hardware layerType indicates that this View has a hardware-implemented Layer. From the first section, we know that “hardware” here refers to the GPU, so the hardware-implemented Layer is implemented through the GPU, typically Frame Buffer Objects (FBO) on OpenGL hardware (off-screen rendering buffer).

Note: Here, Hardware layerType depends on hardware acceleration. If hardware acceleration is enabled, then there will be FBO or frame buffer; if hardware acceleration is disabled, then even if you set a View’s LayerType to Hardware Layer, it will be processed as a Software Layer.

The role of Hardware layer:

A hardware layer is useful to apply a specific color filter and/or blending mode and/or alpha to a view and all its children.
A hardware layer can be used to cache a complex view tree into a texture and reduce the complexity of drawing operations. For instance, when animating a complex view tree with a translation, a hardware layer can be used to render the view tree only once (this is the most important point).
A hardware layer can also be used to increase rendering quality when rotation transformations are applied on a view. It can also be used to prevent potential clipping issues when applying 3D transforms on a view.

Setting Hardware Layer is helpful for the performance of alpha, translation, scale, and rotation property animations (similarly, setting Software Layer has the same effect, and the following examples will have detailed explanations). Specific usage is as follows:

Before the animation starts, set the LayerType to LAYER_TYPE_HARDWARE (the code is from the official example).

1 2	view.setLayerType(View.LAYER_TYPE_HARDWARE, null); ObjectAnimator.ofFloat(view, "rotationY", 180).start();

When the animation ends, reset it to LAYER_TYPE_NONE (the code is from the official example):

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator anim = ObjectAnimator.ofFloat(view, "rotationY", 180);
anim.addListener(new AnimatorListenerAdapter() {
    @Override
    public void onAnimationEnd(Animator animation) {
        view.setLayerType(View.LAYER_TYPE_NONE, null);
    }
});
anim.start();

Due to the characteristics of Hardware Layer, during the property animation (alpha, translation, scale, rotation), only the View’s properties are updated, without destroying and rebuilding the FBO every frame, so its animation performance will be greatly improved. Of course, note that during the property animation (for example, in the AnimationUpdate callback), you should not do other things besides the above property updates, such as adding/removing child Views, modifying the View’s display content, etc., as this will make the FBO ineffective and instead make the performance worse.

Summary

From the description of Hardware Layer and Software Layer above, we can see that Software Layer is a supplement to Hardware Layer. If the app is in a situation where it cannot use Hardware Layer, then Software Layer will come into play. Implementations of APIs not supported by Hardware Layer also need to use Software Layer to achieve.
Both Software Layer and Hardware Layer can perform operations on Views, such as color filters, blending modes, etc.
Both Software Layer and Hardware Layer are helpful for the performance of alpha, translation, scale, rotation, and pivot property animations. This is also the most frequent optimization for Software Layer and Hardware Layer use (which is what we commonly say: when doing the above animations, set this View’s LayerType to LAYER_TYPE_HARDWARE before the animation starts, and reset the layerType to LAYER_TYPE_NONE after the animation ends. The reason for setting it back is that Hardware Layer uses Video Memory, and after setting it to NONE, this part of the memory used will be reclaimed).

Performance Problem Cases Caused by Incorrect LayerType Usage

Performance Problems Caused by Incorrect Software Layer Usage

When looking at Trace, this situation often appears. We know that the Software Layer generation process essentially creates a Bitmap Cache. The generation of this Cache is very time-consuming. From the Trace below, you can also see that every frame takes longer than one Vsync period.

The reason why every frame in the Trace below calls buildDrawingCache/SW is that during every frame process, the View’s content was updated, causing the Cache to become invalid. So every frame triggers the destruction of the Cache and rebuilding of the Cache, causing the interface scrolling to stutter.

The Trace below is the situation of scrolling large images in WeChat Moments. Trace can be downloaded on GitHub

Let’s zoom in to see. Every frame is doing a buildDrawingCache operation, indicating that every frame’s cache has become invalid and is being destroyed and rebuilt. The performance is extremely poor, and the stuttering sensation during scrolling is very severe.

Code Flow

Let’s briefly look at the code flow of LAYER_TYPE_HARDWARE. For a detailed flow, you can look at the recommended articles above.

buildLayer -> buildDrawingCache -> buildDrawingCacheImpl

public void buildLayer() {
    if (mLayerType == LAYER_TYPE_NONE) return;
    ......
    switch (mLayerType) {
        case LAYER_TYPE_HARDWARE:  // Hardware rendering
            updateDisplayListIfDirty();
            if (attachInfo.mThreadedRenderer != null && mRenderNode.isValid()) {
                attachInfo.mThreadedRenderer.buildLayer(mRenderNode);
            }
            break;
        case LAYER_TYPE_SOFTWARE:
            buildDrawingCache(true);  // Software rendering
            break;
    }
}

The implementation of buildDrawingCache can be seen where the corresponding Trace is printed:

public void buildDrawingCache(boolean autoScale) {
    if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0 || (autoScale ?
            mDrawingCache == null : mUnscaledDrawingCache == null)) {
        if (Trace.isTagEnabled(Trace.TRACE_TAG_VIEW)) {
            Trace.traceBegin(Trace.TRACE_TAG_VIEW,
                    "buildDrawingCache/SW Layer for " + getClass().getSimpleName());
        }
        try {
            buildDrawingCacheImpl(autoScale);
        } finally {
            Trace.traceEnd(Trace.TRACE_TAG_VIEW);
        }
    }
}

Performance Problems Caused by Incorrect Hardware Layer Usage

Incorrect use of Hardware Layer and incorrect use of Software Layer can cause the same performance problems. For example, in the following scenario (desktop opening a folder), due to implementation issues by the developer, multiple folder icons were all set to the Hardware LayerType, causing the RenderThread to be very time-consuming. Moreover, because the content in each frame was changing, every frame’s Hardware Layer became invalid, was destroyed and then rebuilt. So this resulted in the situation shown in the Systrace below.

Trace can be downloaded on GitHub

Let’s zoom in on one frame of the RenderThread to look at.

Debugging Tools

We can use the tool in Settings - Accessibility - Developer Options - Show hardware layers updates to track performance problems caused by hardware layer updates.

When a View renders a Hardware Layer, the entire interface will flash green. Under normal circumstances, it should flash green once when the animation starts (that is, when the Layer rendering is initialized), and there should be no green appearance during subsequent animations. If your View stays green continuously during the entire animation, this is a continuous cache invalidation problem.

You can also discover the same problem by looking at the Systrace. The two tools can be used together to discover animation performance problems early.

Summary

Remember the usage scenarios for LayerType: View doing alpha, translation, scale, rotation property animations.
When doing animations, if possible, try to use Hardware Layer more. Remember to set it to None after use. Only consider using Software Layer if there are APIs that the hardware layer doesn’t support.
If you use setAlpha(), AlphaAnimation, or ObjectAnimator to set the View’s transparency, it will go through an off-screen buffer by default. So if the View you’re operating on is relatively large, you can also set this View’s Type to LAYER_TYPE_HARDWARE (official suggestion).
In some cases, Hardware Layer might actually need to do a lot of work, not just rendering the view. Caching a layer takes time because this step is divided into two processes: first, the view is rendered into a layer on the GPU, and then, the GPU renders that layer to the window. If the View’s rendering is very simple (for example, a solid color), then setting up a Hardware Layer during initialization might add unnecessary overhead.
For all caches, there’s a possibility of cache invalidation. When the animation is running, if some place calls View.invalidate(), then the Layer will have to be rendered again from scratch. If it’s continuously invalidated, your Hardware Layer will actually perform worse than not adding any Layer at all (the example below can verify this), because Hardware Layer adds overhead when setting up the cache. If you continuously re-cache the Layer, it will cause a huge burden on performance (the more complex the View doing the animation, the heavier the burden).

Examples of LayerType’s Impact on Animation Performance

Example

Code

To illustrate the situation mentioned above, let’s use a small example to demonstrate the performance performance under various situations. The code is very simple (code project address: https://github.com/Gracker/Android_HardwareLayer_Example). The project’s Systrace folder contains all the examples involved in this article (these are good things, worth collecting).

Two TextViews: one responsible for starting the animation, one responsible for doing the animation.
Animation types include TRANSLATION_X, ALPHA, TRANSLATION_Y, SCALE_X, SCALE_Y.
We will control AnimatorListener and AnimatorUpdateListener to make the animation implementation different:
1. In onAnimationStart and onAnimationEnd, mainly set whether to enable LAYER_TYPE_HARDWARE or LAYER_TYPE_SOFTWARE.
2. In onAnimationUpdate, mainly demonstrate what impact it causes if the View’s content is changed during the animation process.

// Set up animation
animatorSet = new AnimatorSet();
objectAnimator1 = ObjectAnimator.ofFloat(animationText, View.TRANSLATION_X, 150);
objectAnimator2 = ObjectAnimator.ofFloat(animationText, View.ALPHA, 0);
objectAnimator3 = ObjectAnimator.ofFloat(animationText, View.TRANSLATION_Y, 150);
objectAnimator4 = ObjectAnimator.ofFloat(animationText, View.SCALE_X, 150);
objectAnimator5 = ObjectAnimator.ofFloat(animationText, View.SCALE_Y, 150);
animatorSet.playTogether(objectAnimator1, objectAnimator2, objectAnimator3, objectAnimator4, objectAnimator5);
animatorSet.setDuration(500);

// Add animation listener
objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_HARDWARE, null);
        // animationText.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
    }

    @Override
    public void onAnimationEnd(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_NONE, null);
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
        // text.setText(String.format("%s%d", text.getText().toString(), i));
        // i++;
    }
});
// Start animation
startText.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        animatorSet.start();
    }
});

Statistics Tool: GFXInfo

To get accurate data, we use the data obtained from gfxinfo for comparison (adb shell dumpsys gfxinfo).

The gfxInfo records the duration of each frame. We focus on the following indicators:

Janky Frames: Number of frames exceeding 16ms (exceeding 16ms doesn’t necessarily cause stuttering, but it increases the risk of stuttering situations occurring).
Duration frame statistics: You can see the intervals of most frames, as well as the maximum duration.

Case 1: Normal Layer + No Dynamic View Content Update

Code

AnimatorListener and AnimatorUpdateListener are not overridden, as follows, everything inside the functions is commented out.

objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
    }

    @Override
    public void onAnimationEnd(Animator animator) {
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
    }
});

Systrace Phenomenon

You can see that there are some yellow frames, and the flush commands method in the render thread executes for a relatively long time. Download Systrace

gfxInfo Data

You can see that the Janky Frames ratio is 46%, 99th percentile: 32ms, indicating that the performance is relatively poor. At the same time, Number High input latency = 30, indicating that the main thread’s load is relatively high.

Total frames rendered: 30
Janky frames: 14 (46.67%)
50th percentile: 16ms
90th percentile: 29ms
95th percentile: 32ms
99th percentile: 32ms
Number Missed Vsync: 0
Number High input latency: 30
Number Slow UI thread: 0
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0
Number Frame deadline missed: 0
HISTOGRAM: 5ms=0 6ms=0 7ms=0 8ms=0 9ms=0 10ms=2 11ms=2 12ms=5 13ms=1 14ms=2 15ms=1 16ms=3 17ms=2 18ms=0 19ms=0 20ms=0 21ms=1 22ms=1 23ms=1 24ms=1 25ms=2 26ms=2 27ms=0 28ms=1 29ms=1 30ms=0 31ms=0 32ms=2 34ms=0 36ms=0 38ms=0 40ms=0

Case 2: Software Layer + No Dynamic View Content Update

Code

objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
    }

    @Override
    public void onAnimationEnd(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_NONE, null);
        i = 0;
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
    }
});

Systrace Phenomenon

The first frame executes buildDrawingCache/SW Layer for AppCompatTextView, and in the subsequent property animations, this method is not executed anymore. You can see that all frames during the animation are green, indicating that the performance is very good. Download Systrace

gfxInfo Data

You can see that the Janky Frames ratio is 3%, 99th percentile: 16ms, indicating that the performance is very good. At the same time, Number High input latency = 0, indicating that the main thread’s load is relatively low.

Total frames rendered: 31
Janky frames: 1 (3.23%)
50th percentile: 9ms
90th percentile: 12ms
95th percentile: 16ms
99th percentile: 16ms
Number Missed Vsync: 0
Number High input latency: 0
Number Slow UI thread: 1
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0
Number Frame deadline missed: 1
HISTOGRAM: 5ms=2 6ms=2 7ms=4 8ms=3 9ms=5 10ms=11 11ms=0 12ms=1 13ms=0 14ms=1 15ms=0 16ms=2 17ms=0 18ms=0 19ms=0 20ms=0 21ms=0 22ms=0 23ms=0 24ms=0 25ms=0 26ms=0 27ms=0 28ms=0 29ms=0 30ms=0 31ms=0 32ms=0 34ms=0 36ms=0 38ms=0 40ms=0

Case 3: Hardware Layer + No Dynamic View Content Update

Code

objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_HARDWARE, null);
    }

    @Override
    public void onAnimationEnd(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_NONE, null);
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
    }
});

Systrace Phenomenon

You can see that during the animation process, all frames are green, indicating that the performance is very good. Download Systrace

gfxInfo Data

You can see that the Janky Frames ratio is 0%, 99th percentile: 14ms, indicating that the performance is very good. At the same time, Number High input latency = 0, indicating that the main thread’s load is very low.

Total frames rendered: 31
Janky frames: 0 (0.00%)
50th percentile: 7ms
90th percentile: 9ms
95th percentile: 12ms
99th percentile: 14ms
Number Missed Vsync: 0
Number High input latency: 0
Number Slow UI thread: 0
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0
Number Frame deadline missed: 0
HISTOGRAM: 5ms=3 6ms=2 7ms=15 8ms=7 9ms=2 10ms=0 11ms=0 12ms=1 13ms=0 14ms=1 15ms=0 16ms=0 17ms=0 18ms=0 19ms=0 20ms=0 21ms=0 22ms=0 23ms=0 24ms=0 25ms=0 26ms=0 27ms=0 28ms=0 29ms=0 30ms=0 31ms=0 32ms=0 34ms=0 36ms=0 38ms=0 40ms=0

Case 4: Normal Layer + Dynamic View Content Update

Code

objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
    }

    @Override
    public void onAnimationEnd(Animator animator) {
        i = 0;
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
        animationText.setText(String.format("%s%d", animationText.getText().toString(), i));
        i++;
    }
});

Systrace Phenomenon

You can see that during the animation process, there are some yellow frames, and some frames’ Animation, measure, layout, draw are relatively time-consuming. Download Systrace

gfxInfo Data

You can see that the Janky Frames ratio is 38%, 99th percentile: 29ms, indicating that the performance is relatively poor. At the same time, Number High input latency = 31, indicating that the main thread’s load is relatively high.

Total frames rendered: 31
Janky frames: 12 (38.71%)
50th percentile: 14ms
90th percentile: 25ms
95th percentile: 29ms
99th percentile: 29ms
Number Missed Vsync: 0
Number High input latency: 31
Number Slow UI thread: 0
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0
Number Frame deadline missed: 0
HISTOGRAM: 5ms=0 6ms=0 7ms=1 8ms=2 9ms=4 10ms=1 11ms=1 12ms=4 13ms=2 14ms=1 15ms=2 16ms=2 17ms=1 18ms=2 19ms=0 20ms=2 21ms=1 22ms=0 23ms=0 24ms=1 25ms=1 26ms=1 27ms=0 28ms=0 29ms=2 30ms=0 31ms=0 32ms=0 34ms=0 36ms=0 38ms=0 40ms=0

Case 5: Software Layer + Dynamic View Content Update

Code

objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
    }

    @Override
    public void onAnimationEnd(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_NONE, null);
        i = 0;
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
        animationText.setText(String.format("%s%d", animationText.getText().toString(), i));
        i++;
    }
});

Systrace Phenomenon

Since the content is updated every frame, the Bitmap generated by buildDrawingCache every frame is destroyed and rebuilt. At this point, the bottleneck is all in the main thread. Because buildDrawingCache is executed every frame, the execution times for Animation and Draw are both very long. Download Systrace

gfxInfo Data

You can see that the Janky Frames ratio is 41%, 99th percentile: 32ms, indicating that the performance is relatively poor. At the same time, Number High input latency = 18, indicating that the main thread’s load is relatively high.

Total frames rendered: 29
Janky frames: 12 (41.38%)
50th percentile: 14ms
90th percentile: 30ms
95th percentile: 31ms
99th percentile: 32ms
Number Missed Vsync: 0
Number High input latency: 18
Number Slow UI thread: 4
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0
Number Frame deadline missed: 4
HISTOGRAM: 5ms=0 6ms=1 7ms=0 8ms=0 9ms=0 10ms=1 11ms=6 12ms=3 13ms=2 14ms=3 15ms=0 16ms=1 17ms=1 18ms=1 19ms=2 20ms=0 21ms=1 22ms=0 23ms=0 24ms=2 25ms=1 26ms=0 27ms=1 28ms=0 29ms=0 30ms=1 31ms=1 32ms=1 34ms=0 36ms=0 38ms=0 40ms=0

Case 6: Hardware Layer + Dynamic View Content Update

Code

objectAnimator1.addListener(new Animator.AnimatorListener() {
    @Override
    public void onAnimationStart(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_HARDWARE, null);
    }

    @Override
    public void onAnimationEnd(Animator animator) {
        animationText.setLayerType(View.LAYER_TYPE_NONE, null);
        i = 0;
    }
});

objectAnimator1.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
    @Override
    public void onAnimationUpdate(ValueAnimator valueAnimator) {
        animationText.setText(String.format("%s%d", animationText.getText().toString(), i));
        i++;
    }
});

Systrace Phenomenon

Similar to the Software Layer situation, since the content is updated every frame, the Buffer generated by drawLayer every frame is destroyed and rebuilt. At this point, the bottleneck is in both the main thread and the render thread. Because the content is updated every frame and the Buffer is destroyed and rebuilt, the execution times of both the main thread and the render thread are very long, and the performance is relatively poor. Download Systrace

gfxInfo Data

Total frames rendered: 30
Janky frames: 14 (46.67%)
50th percentile: 16ms
90th percentile: 29ms
95th percentile: 32ms
99th percentile: 32ms
Number Missed Vsync: 0
Number High input latency: 30
Number Slow UI thread: 0
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0
Number Frame deadline missed: 0
HISTOGRAM: 5ms=0 6ms=0 7ms=0 8ms=0 9ms=0 10ms=2 11ms=2 12ms=5 13ms=1 14ms=2 15ms=1 16ms=3 17ms=2 18ms=0 19ms=0 20ms=0 21ms=1 22ms=1 23ms=1 24ms=1 25ms=2 26ms=2 27ms=0 28ms=1 29ms=1 30ms=0 31ms=0 32ms=2 34ms=0 36ms=0 38ms=0 40ms=0

Summary

From the six cases above, you can see that for the same animation, under different LayerTypes, the performance performance varies greatly. This is just simple property animations; if you encounter more complex animations, the performance difference will be even greater.

Let’s do a simple summary of the above cases and the performance data they show:

If you’re just doing animation without dynamically modifying the View’s content, then the performance is: Hardware Layer >= Software Layer > Normal Layer.
If you’re doing animation while simultaneously dynamically modifying the View’s content, then the performance is: Normal Layer > Software Layer = Hardware Layer.
Hardware Layer indeed provides a huge improvement for animation performance, but if you use it poorly, it’s even worse than not using it.
If through Systrace you discover that every frame during your animation is doing buildDrawingCache/SW (main thread) or buildLayer (render thread), then please check your code’s logic.
In some cases, it’s due to system reasons, such as images being larger than Cache, invalidate logic problems. You can contact the phone manufacturer to modify it together.

Zhihu Article Address

Since blog message communication is inconvenient, for likes or communication, you can move to this article’s Zhihu page.

Zhihu - A Deep Dive into Hardware Layers in Android

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with colleagues in the same field. When three walk together, there must be my teacher!

Blogger Personal Introduction: Inside are personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Personally Organized and Collected Excellent Blog Articles - Android Performance Optimization Must Know: Everyone is welcome to recommend and self-recommend (private WeChat chat is fine).
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

“If you want to go fast, go alone. If you want to go far, go together.”

Detailed Explanation of Hardware Layer in Android

2019-07-27T06:09:13.000Z

Hardware Acceleration vs Software Acceleration

Many people confuse hardware acceleration and Hardware Layer in Android, thinking that enabling hardware acceleration means enabling Hardware Layer. So before discussing Hardware Layer, let’s first talk about hardware acceleration.

For more detailed articles about hardware acceleration, I recommend these three:

Hardware acceleration, actually should be called GPU acceleration. The difference between hardware and software acceleration mainly lies in whether graphics drawing is handled by GPU or CPU. If by GPU, it’s considered hardware accelerated drawing; otherwise, it’s software drawing.

Current Android versions have hardware acceleration enabled by default. If your App doesn’t have special declarations, hardware acceleration is enabled by default.

The above three articles provide deeper explanations at code and principle levels. Here I’ll demonstrate the difference between App drawing under hardware acceleration and software acceleration from a Systrace perspective.

Hardware Accelerated App Performance

Since hardware acceleration is default, let’s take the most common desktop scrolling as an example to see how a hardware accelerated App performs in Systrace.

Under hardware acceleration, the App has both main thread and render thread; one frame’s drawing is executed cooperatively by both threads.

Let’s zoom in on Systrace to see how each frame’s main thread and render thread work, and when GPU intervenes to achieve “acceleration.”

GPU’s actual intervention occurs in some operations within the RenderThread.

Software Accelerated App Performance

Correspondingly, let’s find an App for software acceleration demonstration: China UnionPay.

First, a panoramic view shows that under software rendering, there’s only main thread, no render thread; all rendering work completes on the main thread. Also visible is that under software rendering, each frame’s execution time is very long, exceeding one Vsync cycle, so scrolling feels jerky and uncomfortable. Systrace Download

Let’s zoom in on Systrace to see how each frame’s main thread works.

Summary

Through the above comparison and reading the recommended three articles, you should clearly understand the difference between hardware rendering and software rendering. Here’s a summary:

Under hardware rendering, the app has both main thread and render thread; under software rendering, the app only has main thread, no render thread.
Under hardware rendering, the app’s final drawing is achieved with GPU assistance; under software rendering, the app’s final drawing is achieved using CPU (calling skia library).
Under hardware rendering, App performance is superior to software rendering.
Since some APIs don’t support hardware rendering, only software rendering can be used. When developing Apps, such APIs should be avoided as much as possible (support status can be directly checked in Android official documentation: https://developer.android.google.cn/guide/topics/graphics/hardware-accel).

Software Layer VS Hardware Layer

Having discussed hardware rendering, let’s talk about Software Layer and Hardware Layer. These two concepts mainly refer to Views and have no direct relationship with whether the App is hardware or software rendered at that moment (but there is dependency, explained later).

A View’s layerType has three states (English below is official documentation; read English first, then I’ll explain):

LAYER_TYPE_NONE: Indicates that the view does not have a layer.
LAYER_TYPE_SOFTWARE: Indicates that the view has a software layer. A software layer is backed by a and causes the view to be rendered using Android’s software rendering pipeline, even if hardware acceleration is enabled.
LAYER_TYPE_HARDWARE: Indicates that the view has a hardware layer. A hardware layer is backed by a hardware specific texture (generally Frame Buffer Objects or FBO on OpenGL hardware) and causes the view to be rendered using Android’s hardware rendering pipeline, but only if hardware acceleration is turned on for the view hierarchy. When hardware acceleration is turned off, hardware layers behave exactly as LAYER_TYPE_SOFTWARE.

LAYER_TYPE_NONE

By default, all Views have this layerType. In this case, this View doesn’t undergo any special processing; it proceeds as usual.

LAYER_TYPE_SOFTWARE

Software layerType indicates this View has a software-implemented Layer. How is it software-implemented? Essentially, it converts this View into a Bitmap object under certain conditions.

1
2
3

android/view/View.java
 Bitmap bitmap = createBitmap(mResources.getDisplayMetrics(),
        width, height, quality);

Software layer functions:

When the application is not using hardware acceleration, a software layer is useful to apply a specific color filter and/or blending mode and/or translucency to a view and all its children. (When the application is not using hardware acceleration, Software layer can be used to apply specific color filters, blending modes, or translucency to View and all its child Views.)
When the application is using hardware acceleration, a software layer is useful to render drawing primitives not supported by the hardware accelerated pipeline. It can also be used to cache a complex view tree into a texture and reduce the complexity of drawing operations. For instance, when animating a complex view tree with a translation, a software layer can be used to render the view tree only once. (When the application is using hardware acceleration, software layer can be used to render drawing primitives not supported by hardware accelerated pipeline. It can also cache complex view trees into textures, reducing drawing operation complexity. For example, when animating complex view trees with translation, software layer can render the view tree only once.)
Software layers should be avoided when the affected view tree updates often. Every update will require to re-render the software layer, which can potentially be slow (particularly when hardware acceleration is turned on since the layer will have to be uploaded into a hardware texture after every update). (When affected view trees update frequently, software layers should be avoided. Each update requires re-rendering the software layer, which can be slow (especially when hardware acceleration is enabled, as the layer must be uploaded to hardware texture after each update).)

LAYER_TYPE_HARDWARE

Hardware layerType indicates this View has a hardware-implemented Layer. From the first section, we know “hardware” here refers to GPU, so hardware-implemented Layer, as the name suggests, is implemented via GPU, typically Frame Buffer Objects or FBO (off-screen rendering Buffer) on OpenGL hardware.

Note: Hardware layerType depends on hardware acceleration. If hardware acceleration is enabled, then FBO or frame buffer exists; if hardware acceleration is disabled, even if you set a View’s LayerType as Hardware Layer, it will be processed as Software Layer.

Hardware layer functions:

A hardware layer is useful to apply a specific color filter and/or blending mode and/or translucency to a view and all its children. (Hardware layer can be used to apply specific color filters and/or blending modes and/or translucency to view and all its child views.)
A hardware layer can be used to cache a complex view tree into a texture and reduce the complexity of drawing operations. For instance, when animating a complex view tree with a translation, a hardware layer can be used to render the view tree only once. (Hardware layer can be used to cache complex view trees into textures, reducing drawing operation complexity. For example, when animating complex view trees with translation, hardware layer can render the view tree only once; this is the main point.)
A hardware layer can also be used to increase the rendering quality when rotation transformations are applied on a view. It can also be used to prevent potential clipping issues when applying 3D transforms on a view. (When rotation transformations are applied on a view, hardware layer can also improve rendering quality. It can also prevent potential clipping issues when applying 3D transforms on a view.)

Setting Hardware Layer helps performance for alpha, translation, scale, rotation property animations (similarly, setting Software Layer has the same effect; detailed explanation in following small example section). Specific usage as follows:

Before animation starts, set LayerType to LAYER_TYPE_HARDWARE (code from official example):

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);ObjectAnimator.ofFloat(view, "rotationY", 180).start();

Android Systrace Basics - Prerequisites for Analyzing Systrace

2019-07-23T14:09:59.000Z

This is the second article in the Systrace series, primarily explaining the prerequisites for analyzing Systrace. With these prerequisites, analyzing Systrace will be more effective, allowing you to identify issues faster and more efficiently.

This article introduces how to view thread states in Systrace, how to analyze thread wakeup information, how to interpret data in the information panel, and common shortcuts. By studying this article, you will gain an understanding of process and thread-related information and know how to extract key information from complex Systrace traces.

Series Article Index
Main Content
Viewing Thread States
Analyzing Thread Wakeup Information
Data Parsing in Information Panel
Using Shortcuts
Zhihu Article Link
About Me && Blog

Series Article Index

Main Content

Viewing Thread States

Systrace uses different colors to identify different thread states. Above each method, there will be a corresponding thread state indicator showing the current status of the thread. By viewing the thread state, we can identify current bottlenecks: whether the CPU execution is slow, if it’s due to a Binder call, IO operations, or waiting for CPU time slices.

Main thread states include:

Green: Running

Only threads in this state can run on the CPU. Multiple threads may be in an executable state at the same time, and their task_struct structures are placed in the executable queue of the corresponding CPU (a thread can appear in only one CPU’s executable queue at a time). The scheduler’s task is to select a thread from each CPU’s executable queue to run on that CPU.

Observation Purpose: We frequently check Running threads to compare their execution time with competitors and analyze reasons for speed or slowness:

Is the frequency insufficient?
Is it running on a small core?
Does it switch frequently between Running and Runnable? Why?
Does it switch frequently between Running and Sleep? Why?
Is it running on the wrong core? For example, an unimportant thread occupying a super-large core.

Blue: Runnable

The thread is ready to run but currently not scheduled, waiting for CPU scheduling.

Observation Purpose: The longer a thread stays in the Runnable state, the busier the CPU scheduling is, indicating it hasn’t handled the task promptly:

Are there too many background tasks running?
Is the lack of prompt handling due to low frequency?
Is it restricted to a specific cpuset while the CPU is full?
What is the currently Running task? Why?

White: Sleep

The thread has no work to do, possibly because it’s blocked on a mutex.

Observation Purpose: Generally waiting for event-driven triggers.

Orange: Uninterruptible Sleep - IO Block

The thread is blocked on I/O or waiting for disk operations to complete. The bottom line usually identifies the callsite: wait_on_page_locked_killable.

Observation Purpose: This generally indicates slow I/O operations. If a large number of orange Uninterruptible Sleep states appear, it’s often due to low memory status, triggering pageFault during memory allocation. In the Linux system’s page cache list, some pages may not be ready yet (i.e., not fully read from disk), leading to wait_on_page_locked_killable blocking when a user accesses that page. This is highly likely to occur with long blocking durations when the system I/O is very busy and operations are queued.

Purple: Uninterruptible Sleep

The thread is blocked on another kernel operation (usually memory management).

Observation Purpose: Generally trapped in kernel mode. This can be normal in some cases and abnormal in others, requiring specific analysis.

Analyzing Thread Wakeup Information

Systrace identifies a very useful piece of information that helps us analyze thread calls and wait relationships.

Thread wakeup information is crucial. Knowing who waked up a thread tells us the call-wait relationship between them. If a thread sleeps for a long time and then wakes up, we can investigate who woke it up and check the waker’s information to see why they woke it so late.

A common scenario: An application’s main thread uses Binder to communicate with AMS in SystemServer, but the AMS function is waiting for a lock release (or the function itself takes a long time). The app’s main thread then has to wait a long time, leading to performance issues like slow response or jank. This is a primary reason why system performance decreases after running Monkey or when many background processes are active.

Another scenario: The application’s main thread is waiting for results from another thread in the same app. Wakeup information can analyze which thread is blocking the main thread. For example, in the following scenario, a doFrame took 152ms—a clear abnormality—but most of the time was spent in sleep.

Zooming in reveals segmental wakeups. Clicking on the runnable section displays wakeup information in the panel below, allowing you to trace what the thread was doing.

The thread 20424 is RenderHeartbeat, which involves the App’s own code logic. The App needs to analyze what RenderHeartbeat was doing.

Systrace can label this because a task enters the Runnable state before entering Running, and Systrace marks this state (very short, needs zooming to see).

Scrolling to the top to check task info on the corresponding CPU identifies the task’s state before being waked up:

Common Linux process states:

D: Uninterruptible sleep (usually IO processes).
R: In the runnable queue waiting for scheduling.
S: Sleeping.
T: Stopped or traced.
W: Paging (invalid since kernel 2.6).
X: Dead process (very rare).
Z: Zombie process.
<: High-priority process.
N: Low-priority process.
L: Pages locked into memory.
s: Session leader (has child processes).
l: Multi-threaded (using CLONE_THREAD, like NPTL pthreads).
+: Process group in foreground.

Data Parsing in Information Panel

Thread State Interpretation

Function Slice Interpretation

Counter Sample Interpretation

Async Slice Interpretation

CPU Slice Interpretation

User Expectation Interpretation

Located at the very top of Systrace, identifying Rendering Response and Input Response.

Using Shortcuts

Shortcuts can speed up Systrace viewing. Here are common ones:

W: Zoom in for local details.
S: Zoom out for the overview.
A: Move left.
D: Move right.
M: Highlight the currently clicked segment (very useful for identifying boundaries and duration).

Mouse mode switching: Switch experimental modes for the mouse. Default is 1 (Selection mode). Direct shortcut switching is much more efficient than clicking.

Number 1: Switch to Selection mode. Click segments for details. Most commonly used.
Number 2: Switch to Pan mode. Long-press to drag left/right.
Number 3: Switch to Zoom mode. Long-press to zoom.
Number 4: Switch to Timing mode. Measure time between a selected start and end point.

Zhihu Article Link

Since blog comments are less convenient, feel free to visit the Zhihu or Juejin pages for this article to like or exchange ideas:
Zhihu - Android Systrace Basics - Prerequisites for Analyzing Systrace
Juejin - Android Systrace Basics - Prerequisites for Analyzing Systrace

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Basics - SystemServer Explained

2019-06-29T09:52:52.000Z

This is the fourth article in the Systrace series, primarily providing a brief introduction to SystemServer. It covers several important threads within SystemServer. Since Input and Binder are particularly critical, they are discussed separately and won’t be covered in detail here.

Series Article Index
Main Content
Window Animations
ActivityManagerService
WindowManagerService
Input
Binder
HandlerThreads
About Me && Blog

Series Article Index

Main Content

Window Animations

A critical part of SystemServer in Systrace is window animations. Since SystemServer manages windows, it also handles window animations centrally. This involves two key threads: android.anim and android.anim.lf (further explained below).

Using App Startup as an example, we can see how animations switch between these threads. In Android P, an app’s startup animation consists of the Launcher’s part and the App’s first frame. Previously handled entirely in SystemServer, multitasking animations have partly moved to the Launcher for better performance.

When you click an icon, the Launcher first starts a StartingWindow while the App is still launching. Once the App’s first frame is ready, it switches to the App’s window animation.

Launcher Animation:

Correspondingly, the App is starting:

As shown above, after the App’s first frame is prepared, SystemServer switches to the App’s window animation.

ActivityManagerService

AMS and WMS are the busiest services in SystemServer. Trace points related to AMS typically use the TRACE_TAG_ACTIVITY_MANAGER tag, appearing as ActivityManager in Systrace.

Below is the AMS output when launching a new process:

Various scenarios for processes and the four components have corresponding Trace points, such as ActivityStart, ActivityResume, and activityStop. Some reside in the application process and others in SystemServer, so analyzing Activity logic requires toggling between both processes to understand state changes and SystemServer‘s role.

WindowManagerService

WMS-related Trace points typically use the TRACE_TAG_WINDOW_MANAGER tag. WindowManagerService often appears within Binder threads in SystemServer. For example, here’s the relayoutWindow output during app startup:

Various Window scenarios have Trace points like relayoutWindow, performLayout, and prepareToDisplay.

Input

Input is a vital part of SystemServer, primarily consisting of the Native threads InputReader and InputDispatcher. This is detailed in Systrace Basics - Input Interpretation and won’t be repeated here.

Binder

Since SystemServer provides numerous base services, inter-process communication (IPC) is heavy, and most of it uses Binder. Its role is critical; with many background apps, SystemServer can suffer from Binder communication overhead and lock contention, leading to system or app jank. This is detailed in Binder and Lock Contention Explained.

HandlerThread

BackgroundThread

com/android/internal/os/BackgroundThread.java

1
2
3

private BackgroundThread() {
    super("android.bg", android.os.Process.THREAD_PRIORITY_BACKGROUND);
}

BackgroundThread in Systrace:

BackgroundThread is widely used for non-performance-critical tasks.

ServiceThread

ServiceThread inherits from HandlerThread. Several worker threads mentioned below inherit from ServiceThread, performing different functions with varying priorities: UiThread, IoThread, DisplayThread, AnimationThread, FgThread, and SurfaceAnimationThread.

Each thread has its own Looper, Thread, and MessageQueue to avoid interference. Android uses specific threads for specific functional tasks.

UiThread

com/android/server/UiThread.java

1
2
3

private UiThread() {
    super("android.ui", Process.THREAD_PRIORITY_FOREGROUND, false /*allowIo*/);
}

UiThread in Systrace:

Common uses for UiThread can be found in the source by searching for UiThread.get().

IoThread

com/android/server/IoThread.java

1
2
3

private IoThread() {
    super("android.io", android.os.Process.THREAD_PRIORITY_DEFAULT, true /*allowIo*/);
}

Uses for IoThread can be found via IoThread.get().

DisplayThread

com/android/server/DisplayThread.java

private DisplayThread() {
    // DisplayThread runs important stuff, but these are not as important as things running in
    // AnimationThread. Thus, set the priority to one lower.
    super("android.display", Process.THREAD_PRIORITY_DISPLAY + 1, false /*allowIo*/);
}

DisplayThread in Systrace:

AnimationThread

com/android/server/AnimationThread.java

1
2
3

private AnimationThread() {
    super("android.anim", THREAD_PRIORITY_DISPLAY, false /*allowIo*/);
}

AnimationThread in Systrace:

Uses in source show that WindowAnimator executions happen here. Android P added SurfaceAnimationThread to offload work and improve WindowAnimation performance.

FgThread

com/android/server/FgThread.java

1
2
3

private FgThread() {
    super("android.fg", android.os.Process.THREAD_PRIORITY_DEFAULT, true /*allowIo*/);
}

FgThread in Systrace:

Example of FgThread usage:

FgThread.getHandler().post(() -> {
    synchronized (mLock) {
        if (mStartedUsers.get(userIdToLockF) != null) {
            Slog.w(TAG, "User was restarted, skipping key eviction");
            return;
        }
    }
    try {
        mInjector.getStorageManager().lockUserKey(userIdToLockF);
    } catch (RemoteException re) {
        throw re.rethrowAsRuntimeException();
    }
    if (userIdToLockF == userId) {
        for (final KeyEvictedCallback callback : keyEvictedCallbacks) {
            callback.keyEvicted(userId);
        }
    }
});

SurfaceAnimationThread

com/android/server/wm/SurfaceAnimationThread.java
private SurfaceAnimationThread() {
    super("android.anim.lf", THREAD_PRIORITY_DISPLAY, false /*allowIo*/);
}

SurfaceAnimationThread in Systrace (named android.anim.lf):

This thread primarily executes window animations to offload android.anim, reducing jank caused by locks. See: Android P——LockFreeAnimation.

SurfaceAnimationRunner(@Nullable AnimationFrameCallbackProvider callbackProvider,
        AnimatorFactory animatorFactory, Transaction frameTransaction,
        PowerManagerInternal powerManagerInternal) {
    SurfaceAnimationThread.getHandler().runWithScissors(() -> mChoreographer = getSfInstance(),
            0 /* timeout */);
    mFrameTransaction = frameTransaction;
    mAnimationHandler = new AnimationHandler();
    mAnimationHandler.setProvider(callbackProvider != null
            ? callbackProvider
            : new SfVsyncFrameCallbackProvider(mChoreographer));
    mAnimatorFactory = animatorFactory != null
            ? animatorFactory
            : SfValueAnimator::new;
    mPowerManagerInternal = powerManagerInternal;
}

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Basics - Introduction to Systrace

2019-05-28T08:58:00.000Z

This is the first article in the Systrace series, primarily providing a brief introduction to Systrace, its basic usage, how to interpret Systrace traces, and how to analyze phenomena in Systrace in conjunction with other tools.

Perfetto Series Article Index
Systrace Series Article Index
Main Content
Simple Usage of Systrace
Capturing Systrace with Command-Line Tools
Viewing Supported TAGs
About Me && Blog

Perfetto Series Article Index

2025-4-17 Update

Google has discontinued maintenance for the Systrace tool. If you are new to this, it is recommended to use Perfetto to capture traces. For detailed usage, refer to the Perfetto Series on this blog.
The latest version of platform-tools has removed the Systrace tool. Google recommends using Perfetto to capture traces. If you need the Systrace tool, please download an older version of platform-tools.
Choosing between Systrace and Perfetto: My personal recommendation is that you can use both; use whichever feels most comfortable. However, Google eventually plans to replace Systrace with Perfetto, so you might consider switching your default trace viewing tool to Perfetto UI.
Advantages of Perfetto:
1. The most significant improvement of Perfetto over Systrace is its support for long-duration data capture. This is thanks to a background service that encodes collected data into Protobuf format and saves it to disk. In terms of data sources, the core principle is consistent with Systrace—both rely on the Linux kernel’s Ftrace mechanism to record key events in both user and kernel space (ATRACE, CPU scheduling). Perfetto supports all features provided by Systrace, which is why Systrace will eventually be replaced.
2. Perfetto’s supported data types, acquisition methods, and analysis techniques are unprecedentedly comprehensive. It supports trace types via ATRACE, metric types through customizable node reading, and log types on UserDebug versions by acquiring logd data.
3. You can manually trigger capture and termination through the Perfetto.dev website or command-line tools, trigger long-duration captures via Developer Options in Settings, or even dynamically enable capture using the Perfetto Trigger API provided in the framework. This covers nearly all scenarios encountered in projects.
4. On the data analysis side, Perfetto provides a web-based visualization tool similar to Systrace but with a entirely different underlying implementation. The biggest benefit is support for rendering extremely large files—something Systrace cannot do (it may crash or become extremely laggy with files over 300M). This visualization site allows you to see various post-processed data, execute SQL queries, and even view logcat content. Perfetto Trace files can be converted into SQLite-based database files, allowing you to run pre-written SQL files or write queries on the fly. You can even import data into data science stacks like Jupyter and share your analytical insights with colleagues.
5. For example, if you want to calculate the total CPU consumption of the SurfaceFlinger thread or identify which threads are running on the large cores, you can collaborate with domain experts to translate their experience into SQL commands. If that’s not enough, Perfetto also provides a Python API to export data into DataFrame format, enabling almost any custom data analysis effect you desire.
6. You can find introductions to and comparisons of various tools in the article Techniques, Philosophy, and Tools for Android Performance Optimization.

I will continue to update the Perfetto series, and all future illustrations will use Perfetto. The underlying knowledge points are common between Systrace and Perfetto, so don’t worry about which one to use—you can learn from both series.

Perfetto Series Article Index

Systrace Series Article Index

Main Content

Systrace is a performance data sampling and analysis tool introduced in Android 4.1. It helps developers collect execution information from key Android subsystems (such as SurfaceFlinger, SystemServer, Kernel, Input, Display, and other critical framework modules, services, and the View system), allowing for a more intuitive analysis of system bottlenecks and performance improvements.

Systrace’s capabilities include tracking system I/O operations, kernel workqueues, CPU load, and the health of various Android subsystems. On the Android platform, it’s composed of three main parts:

Kernel Space: Systrace leverages the ftrace feature in the Linux Kernel. Therefore, to use Systrace, the relevant ftrace modules in the kernel must be enabled.
Data Collection: Android defines a Trace class that applications can use to output statistical information to ftrace. Additionally, the atrace program in Android reads statistical info from ftrace and passes it to data analysis tools.
Data Analysis Tools: Android provides systrace.py (a Python script located in Android SDK directory/platform-tools/systrace that calls atrace internally) to configure data collection (such as tags, output filename, etc.), collect ftrace statistics, and generate a resulting HTML file for user viewing. Essentially, Systrace is a wrapper around the Linux Kernel’s ftrace. Applications need to utilize the Trace class provided by Android to use Systrace.

Official documentation and usage for Systrace can be found here: Systrace

Design Philosophy of Systrace

Key flows in the system (such as Touch operations, Power button presses, scrolling), system mechanisms (input dispatching, View rendering, IPC, process management), and hardware/software status (CPU frequency, CPU scheduling, disk info, memory info) have Log-like info inserted, known as TracePoints (essentially Ftrace info). These TracePoints demonstrate the execution time of core operations and the values of specific variables. The Android system then collects these TracePoints scattered across various processes and writes them into a file. After exporting this file, Systrace parses the data to provide an overview of system operation over a period of time.

Important modules in Android have TracePoints inserted by default, categorized by TraceTag:

Framework Java-level TracePoints use the android.os.Trace class.
Framework Native-level TracePoints use ATrace macros.
App developers can define custom traces using the android.os.Trace class.

Consequently, Systrace can collect and centrally display all information from both upper and lower layers of Android. For Android developers, Systrace’s greatest value is transforming the internal state of the Android system from a black box to a white box. Its global perspective and visualization make it the preferred choice for analyzing complex performance issues.

Practical Applications

Because it contains a wealth of system info, parsed Systrace files are naturally suited for analyzing performance issues in both Android Apps and the system itself. App developers, system developers, and Kernel developers can all use Systrace for performance analysis.

From a technical standpoint, Systrace covers major performance categories: Responsiveness, Jank/Dropped Frames, and ANR.
From a user perspective, Systrace can analyze issues including but not limited to:
1. App startup speed (cold, hot, and warm start).
2. Slow UI navigation or janky transitions.
3. Sluggishness in non-navigation actions (toggles, popups, long-presses, selection, etc.).
4. Slow screen on/off, power on/off, unlocking, or face recognition.
5. List scrolling jank.
6. Window animation jank.
7. Content loading jank.
8. System-wide sluggishness.
9. App unresponsiveness (ANR), freezes, or crashes.

When encountering these issues, you can capture a Systrace using various methods, open the parsed file in Chrome, and begin analysis.

Simple Usage of Systrace

Before using Systrace, understand how to use it on various platforms. Given the widespread use of Eclipse and Android Studio, I’ll quote the official usage methods, although the process is the same regardless of the tool:

Prepare the UI you want to trace on the phone.
Click to start capturing (or execute the command in the CLI).
Perform operations on the phone (don’t take too long).
Once the preset time is up, a Trace.html file will be generated. Open this file in Chrome for analysis.

A typically captured Systrace file looks like this:

Capturing Systrace with Command-Line Tools

The command-line approach is more flexible and faster. Once configured, you can get results quickly (highly recommended).
The Systrace tool is located in platform-tools within the Android-SDK directory (Note: The latest platform-tools versions have removed the systrace tool. You need to download version 33 or older, available here: https://androidsdkmanager.azurewebsites.net/Platformtools). Below is the basic usage:

1 2	$ cd android-sdk/platform-tools/systrace $ python systrace.py

Configuring the path and an Alias in your Bash profile can make this very efficient. Also, traces from User builds contain less information than Eng or Userdebug builds. It’s recommended to use a Userdebug device for debugging to ensure both performance and detailed output.

After capturing, a Trace.html file is generated, which must be opened in Chrome. We’ll cover how to analyze the file in later sections. Regardless of the tool used, you can select parameters before capturing. Here’s what they mean:

-a appname      enable app-level tracing for a comma separated list of cmdlines; * is a wildcard matching any process
-b N            use a trace buffer size of N KB
-c              trace into a circular buffer
-f filename     use the categories written in a file as space-separated
                  values in a line
-k fname,...    trace the listed kernel functions
-n              ignore signals
-s N            sleep for N seconds before tracing [default 0]
-t N            trace for N seconds [default 5]
-z              compress the trace dump
--async_start   start circular trace and return immediately
--async_dump    dump the current contents of circular trace buffer
--async_stop    stop tracing and dump the current contents of circular
                  trace buffer
--stream        stream trace to stdout as it enters the trace buffer
                  Note: this can take significant CPU time, and is best
                  used for measuring things that are not affected by
                  CPU performance, like pagecache usage.
--list_categories
                list the available tracing categories
-o filename      write the trace to the specified file instead
                  of stdout.

While there are many parameters, you usually don’t need to worry about most of them when using tools—just check the boxes. In the CLI, we typically alias the command. For example:

1
2

alias st-start='python /path-to-sdk/platform-tools/systrace/systrace.py'  
alias st-start-gfx-trace='st-start -t 8 am,binder_driver,camera,dalvik,freq,gfx,hal,idle,input,memory,memreclaim,res,sched,sync,view,webview,wm,workq,binder'

This allows you to simply type st-start to begin. Of course, to distinguish and save files, add -o filename.html. You don’t need to understand every parameter immediately; they will become familiar during the analysis process.

Commonly used parameters:

-o: Specifies the output file path and name.
-t: Capture duration (you can press Enter to stop early in newer versions).
-b: Specifies the buffer size (default is usually enough; increase it for longer traces).
-a: Specifies the app package name (required for debugging custom TracePoints).

Viewing Supported TAGs

The default TAGs supported by Systrace can be viewed with the following command. Different manufacturers may have various configurations; you can choose and configure TAGs based on your needs. Selecting fewer TAGs results in smaller Trace files but less content. Large Trace files can impact Chrome’s performance during analysis, so choose wisely.

Using my Android 12 device as an example, it supports the following tags (tag name on the left, description on the right):

$ adb shell atrace --list_categories
         gfx - Graphics
       input - Input
        view - View System
      webview - WebView
           wm - Window Manager
           am - Activity Manager
           sm - Sync Manager
        audio - Audio
        video - Video
       camera - Camera
          hal - Hardware Modules
          res - Resource Loading
       dalvik - Dalvik VM
           rs - RenderScript
       bionic - Bionic C Library
        power - Power Management
           pm - Package Manager
           ss - System Server
     database - Database
      network - Network
          adb - ADB
     vibrator - Vibrator
         aidl - AIDL calls
        nnapi - NNAPI
          rro - Runtime Resource Overlay
          pdx - PDX services
        sched - CPU Scheduling
          irq - IRQ Events
          i2c - I2C Events
         freq - CPU Frequency
         idle - CPU Idle
         disk - Disk I/O
         sync - Synchronization
        workq - Kernel Workqueues
   memreclaim - Kernel Memory Reclaim
   regulators - Voltage and Current Regulators
   binder_driver - Binder Kernel driver
   binder_lock - Binder global lock trace
    pagecache - Page cache
       memory - Memory
      thermal - Thermal event
         freq - CPU Frequency and System Clock (HAL)
          gfx - Graphics (HAL)
          ion - ION Allocation (HAL)
       memory - Memory (HAL)
        sched - CPU Scheduling and Trustzone (HAL)
   thermal_tj - Tj power limits and frequency (HAL)

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace Basics - Why 60 FPS?

2019-05-27T08:58:00.000Z

This is the third article in the Systrace series, explaining why 60 FPS is constantly emphasized. 60 FPS is a software concept, distinct from the 60Hz mentioned in screen refresh rates. For further context, refer to: A New Smooth Experience: A Talk on 90Hz.

Series Article Index

Main Content

Today, let’s discuss why we start with 60 FPS when talking about smoothness.

First, let’s clarify some basic concepts:

60 FPS means the screen updates 60 times per second.
These 60 updates must be uniform. If it’s fast one moment and slow the next, it won’t feel smooth visually.
60 times per second means one update every 1/60 ~= 16.67 ms.

With these basic concepts understood, let’s return to Android. Why is Android’s current rendering mechanism based on 60 FPS? This relates primarily to the screen refresh rate.

Basic Concepts

The 60 FPS we referred to is software-based; we generally call it FPS.
Screen Refresh Rate is hardware-based. Most current mobile screens maintain a refresh rate of 60 Hz. Mobile devices typically use 60 Hz because they have higher power requirements. Increasing the refresh rate causes logic power consumption to increase linearly. Additionally, higher refresh rates mean shorter TFT data writing times, making screen design more challenging.
A 60 Hz refresh rate is sufficient and serves as the optimal solution currently. However, high-refresh-rate screens are undoubtedly the future (as of 2023, 120Hz is standard for Android and has even arrived on iOS). I believe this shift depends on breakthroughs in:
1. Battery technology
2. Software technology
3. Hardware capabilities

In current conditions:

At 60 FPS: Android’s rendering draws every 16.67 ms, and a 60 Hz screen refreshes every 16.67 ms.
At 120 FPS: Android’s rendering draws every 8.33 ms, and a 120 Hz screen refreshes every 8.33 ms.

Performance Gains

To improve performance, both software and hardware must advance together. Upgrading only one is largely ineffective. If your screen is 75 Hz but the software is 60 FPS, the screen refreshes 75 times while the software only renders 60—resulting in wasted power for duplicate frames. Conversely, if your screen is 30 Hz but the software is 60 FPS, half the software-rendered frames are discarded before display.

If you want to experience a 120 Hz screen, I suggest trying an iPad Pro. You’ll notice that 60 Hz screens definitely have room for improvement.

This is a brief introduction. For deeper knowledge, you can search Google. Google also released a short video explaining “Why 60 FPS”:

The diagram below shows the tasks an Android app must complete within a single frame; we’ll discuss this in detail later:

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

Android Systrace -- Series Article Index

2019-05-26T08:54:34.000Z

As Systrace becomes increasingly feature-rich, combined with Android version iterations, the previous Systrace series tutorials have become somewhat outdated. Additionally, as my own skills have improved, I’ve been able to extract more information from Systrace, which has been very helpful in solving various performance issues. I need to document these skills to enhance my summarization and organization abilities, and if it helps those who read these articles, that would be excellent.

As Google announced the deprecation of the Systrace tool and introduced Perfetto, Perfetto has essentially replaced Systrace in my daily work. Meanwhile, major manufacturers like OPPO and Vivo have also switched from Systrace to Perfetto. Many newcomers to Android performance optimization find Perfetto’s dazzling interface and complex features overwhelming, and they’ve been hoping I could present the previous Systrace articles using Perfetto.

This series aims to examine the overall operation of the Android system from a new perspective using Perfetto. Additionally, it provides a different angle for learning key modules such as App, Framework, and Linux. Although you may have read many articles about Android Framework, App development, and performance optimization, you might still feel confused because you can’t remember the code or don’t understand the execution flow. Through Perfetto, this graphical tool, you may gain a deeper understanding.

Perfetto Series Index

Systrace Series Article Index

This article serves as an index. After subsequent articles are updated, they will be aggregated here. The content is as follows:

2023-10 update:

Starting to prepare the Perfetto series

Target Audience

This series of articles is suitable for both application developers and system developers. I will consider both perspectives when writing. As a system developer, here are roughly my advantages:

Access to system source code, making it convenient to debug and modify code, and see results on the phone at any time
Certain understanding of the system framework
Certain understanding of system tuning

Based on these points, I will leverage these advantages in my writing to bring you something different:

Learning Android Framework through Systrace
Modifying certain system configurations to show everyone the results: for example, the impact of Buffer count on applications
Introducing considerations and trade-offs that system manufacturers make when building systems
Introducing important but often overlooked points during application development

Update Log

The plan is to update one article per week, giving myself a goal and accountability.

2018-03-30 Index update: Systrace Series Article Index
2018-04-01 Article update: Systrace Basics - Why 60 fps?
2019-07-23 Article update: Systrace Basics - Systrace Prerequisites
2019-10-22 Article update: Systrace Basics - Vsync-App: Detailed Explanation of Choreographer-Based Rendering Mechanism
2019-11-04 Article update: Systrace Basics - Input Explained
2019-11-06 Article update: Systrace Basics - MainThread and RenderThread Explained
2019-12-01 Article update: Systrace Basics - Vsync Explained
2019-12-06 Article update: Systrace Basics - Binder and Lock Contention Explained
2019-12-15 Article update: Systrace Basics - Triple Buffer Explained
2019-12-21 Article update: Systrace Basics - CPU Info Explained
2020-02-04 Article update: Systrace Basics - SystemServer Explained
2020-02-14 Article update: Systrace Basics - SurfaceFlinger Explained
2021-04-24 Article update: Systrace Smoothness Practice 1: Understanding Jank Principles
2021-04-24 Article update: Systrace Smoothness Practice 2: Case Analysis - MIUI Launcher Scroll Jank Analysis
2021-04-24 Article update: Systrace Smoothness Practice 3: Questions During Jank Analysis
2021-10-28 Article update: Systrace Response Speed Practice 1: Understanding Response Speed Principles
2021-10-28 Article update: Systrace Response Speed Practice 2: Response Speed Analysis - Using App Startup as an Example
2021-10-28 Article update: Systrace Response Speed Practice 3: Extended Knowledge on Response Speed

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. When three walk together, one can always be my teacher!

Blogger Introduction: Contains my personal WeChat and WeChat group links.
Blog Content Navigation: A navigation guide for my blog content.
Curated Collection of Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend articles (via WeChat private message)
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

One person can walk faster, but a group can walk further

A New Era of Smoothness: Thoughts on 90Hz on Android

2019-05-15T09:57:53.000Z

High-refresh-rate screens have been common on PCs for years, but they’ve only recently made their way to Android. While the Razer Phone introduced a 120Hz screen last year to a quiet reception, I believe the 90Hz screens on the Nubia Red Magic 3 and OnePlus 7 Pro represent the current “sweet spot” for Android. They offer a tangible, immediate boost to the user experience. If you’ve never used a high-refresh-rate mobile screen, I highly recommend visiting an Apple Store to try out the 120Hz ProMotion display on the iPad Pro.

Terminology Explained

What is Screen Refresh Rate?

This is a hardware specification. It refers to how often the display panel refreshes the image on the screen.

A 60Hz refresh rate means the screen refreshes 60 times per second; 90Hz means 90 refreshes per second. The screen doesn’t care what it’s displaying; it just pulls data from its buffer and shows it at the defined frequency.

What is FPS?

FPS (Frames Per Second) is a software metric. It refers to how many unique frames the operating system and apps generate every second. While the screen refreshes at a constant rate, the software might produce frames at varying speeds.

What is Vsync?

Vsync (Vertical Synchronization) is the mechanism that syncs the software’s FPS with the hardware’s Refresh Rate. Its primary job is to prevent “tearing.”

60Hz System: One frame must be generated every 16.67ms (1/60s).
90Hz System: One frame must be generated every 11.11ms (1/90s) to avoid a “FrameMiss.”

What is the Input Scanning Cycle?

Most modern phones have an input scanning cycle around 8ms. Since Android’s display system is Vsync-driven, input events are typically processed at the start of each Vsync pulse.

In a 16.67ms Vsync window, there’s comfortably room for 2 input points.
In an 11.11ms Vsync window, you might get 2 points, but often only 1. This can sometimes lead to a slightly “uneven” input feel if not handled correctly.

The 90Hz User Experience

The best experience occurs when the Hardware Refresh Rate matches the Software FPS. Currently, 90Hz hardware + 90 FPS software is the ideal combo.

90Hz screen running 60 FPS software: The screen refreshes, but the content isn’t ready, so it displays the previous frame again (judder).
60Hz screen running 90 FPS software: The software prepares frames faster than the screen can show them, leading to wasted CPU/GPU cycles and dropped frames.

While 120Hz is the ultimate goal (as seen on iPad Pro), current Android architecture and hardware are still catching up to that 8.3ms-per-frame requirement. We’ll likely see mature 120Hz Android flagships in 2020.

Check out this comparison video: 90Hz vs. 60Hz Screen Comparison

How 90 FPS Works (Platform Perspective)

The Android rendering pipeline follows these basic steps:

Event Trigger: User taps an icon or scrolls a list.
Dispatch: System sends the event to the app.
App Logic: The app processes the event (e.g., updating list state).
Choreography: If UI changed, the app runs measure, layout, and draw. Hardware acceleration uses the RenderThread.
Composition: The completed buffer is sent to SurfaceFlinger, which composites all layers and sends them to the display hardware.

The process for 90 FPS is the same as 60 FPS—it just has to happen faster.

App Rendering Flow at 90 FPS

SurfaceFlinger Flow at 90 FPS

Advantages and Challenges

Advantages

Unmatched Fluidity: Human eyes are highly sensitive to motion. Once you get used to the smoothness of 90 frames per second, 60 FPS begins to look stuttery and disconnected.
Irreversible Change: High refresh rate is a “one-way street.” Once you adapt to it, going back to a lower refresh rate feels like a downgrade.
Future-Proofing: As we keep our phones longer, buying a device with a top-tier screen, SoC, and UFS 3.0 storage is a wise investment.

Challenges

Performance:
- App and System components must shrink their processing windows from 16.6ms to 11.11ms.
- This requires far more aggressive hardware (Snapdragon 855+, UFS 3.0). This explains why the Razer Phone struggled at 120Hz—the hardware simply weren’t ready for 8.3ms frames.
Power Consumption: 90Hz screens consume significantly more battery, especially at high resolutions. Manufacturers must optimize power usage or allow dynamic switching to 60Hz in static scenarios.
App & Game Adaptation:
- Standard apps usually run fine, but their fluidity depends on code quality.
- Games must be specifically optimized by developers to support and maintain a stable 90 FPS.
- View types like WebView or SurfaceView require content-aware adjustments.

About Me && Blog

(Links and introduction)

Sharp Tools - Efficient Tool Recommendations

2019-04-07T08:22:32.000Z

I’ve been following the Sharp Tools Community Program for a long time. I’ve learned a lot from everyone’s sharing. As stated in the beginning: “Both tools and inspiration are sharp tools. When tools and inspiration from different fields and creators collide, more possibilities arise.“ Below are my simple answers to the six questions of the Sharp Tools Community Program. I hope some parts will be helpful to you.

Introduce yourself and the work you do.

I am an Android System Development Engineer working in the system R&D department of a smartphone manufacturer. My work mainly involves Android system-related tasks, such as performance, power consumption, stability, and framework maintenance. It’s quite varied—I often call myself a “jack-of-all-trades.”

As for hobbies, I enjoy basketball, running, and gaming—essential skills for any programmer. I also appreciate more “artistic” pursuits like reading, raising cats, and drinking tea. In my spare time, I like browsing Bilibili and YouTube. When I have time, I try to finish pending articles for my blog. Currently, I’m obsessed with losing weight and fighting a life-and-death struggle against my belly.

What hardware are you using?

Computers: I primarily use three. A MacBook Pro for writing, developing my own small apps, and photo processing. A desktop provided by my company running Ubuntu, mainly for work and essential for compiling Android source code. A self-built desktop mainly for gaming and compiling AOSP code.

Phones: I also have three. My main device is an iPhone X—I’m satisfied with everything except the battery life. My backup is a OnePlus 6, an Android flagship; as an Android engineer, I must have a solid Android device. The third one is a Pixel, used mainly for running my own compiled AOSP code—a must-have for studying the framework.

Other Hardware: Apple ecosystem products like the Watch, iPad Pro, and AirPods. Sony’s WH-1000XM3 wireless headphones. A Kindle Voyage specifically for e-books.

What about software?

Things 3: Primarily for scheduling daily work and recording tasks.
MWeb: Dedicated to writing—this article was written using MWeb.
Keep: A great fitness helper. I just follow the courses; it’s great for tracking progress and setting goals, especially during HIIT sessions on the treadmill.
Holphin Accounting: A bookkeeping app for basic needs.
Kindle && WeChat Read: Reading apps; the two libraries complement each other. E-books are very convenient, especially on the iPad Pro.
YouTube && Bilibili: My main sources for learning and entertainment.
ShadowSocks && Wingy: I use ShadowSocks on Android and Mac, and Wingy on iPhone/iPad. The widget makes it very convenient to toggle.
Geek Time && Deodao: Knowledge-sharing platforms. I find that hearing what others are doing and how they do it is very helpful for self-improvement and avoiding pitfalls.
Google Photos: Almost all my photos are stored here. I’d be devastated if I ever lost access…
Reeder: I once maintained a Feed list for developers, and I use Reeder to keep up with it.
Android Studio && VS Code: Productivity software; one for Framework Java code and the other for C/C++ code.
RescueTime: Used to track working hours across all platforms. It’s eye-opening (and sometimes depressing) to see where those 10+ hours go every day.
Shimo Docs: For daily/weekly reports and research notes. It’s cross-platform, syncs perfectly, and is great for collaboration. The web version is excellent.
Nutstore (JianGuoYun): A cross-platform cloud drive. I never fear losing data once it’s uploaded. (The Ubuntu support is a huge plus for programmers.)
Evernote: Used to be for notes, but now it’s more of a collection center for interesting articles I find. I use Shimo Docs for daily work records.

What is your ideal working environment?

My ideal working environment is Work-Life Balance. As mentioned in the popular 996.ICU project, my current workload is similar to that. Therefore, I prefer the environment described in the 955.WLB project.

The biggest pressure of a 996 schedule is the lack of personal time for self-improvement. Working until 10 or 11 PM every day leaves no time for fitness, reading, or learning. As an article once said, “The most hidden way to ruin a person is to make them too busy to grow.”

If a person only learns from their work, this single way of learning will inevitably lead to a decreasing marginal contribution to growth. You must give yourself time to grow every day through diverse learning methods outside of work. Continuous growth is essential for a rising career path.

In summary, my ideal working environment includes like-minded colleagues, work I love, and the time/space for personal growth.

How do you usually get inspiration for your work?

One way is through reading—extracting the essence of others’ thoughts to see if I can apply, improve, or expand upon them. Another is thinking and recording—drawing flowcharts while thinking and capturing sparks of ideas.

Admittedly, it’s not always easy. When busy, there’s little time left for deep reading and reflection. I’m always open to advice on this.

Instead of hardware or software, I want to recommend a learning method: Record - Summarize - Output. These three steps are closely linked:

Record: As the saying goes, “The palest ink is better than the best memory.” In today’s information explosion, having your own recording method is crucial. To-do lists, random ideas, problems encountered, solutions found, great articles, blog ideas, or YouTube tutorials—recording keeps you organized.

Summarize: Summarizing helps organize scattered thoughts or knowledge. A clear structure helps you see the big picture. Project summaries help avoid repeating mistakes, and knowledge summaries deepen your understanding of a specific topic.

Output: Output can be private notes, blogs, or videos. Output reinforces your own knowledge by explaining it to others. To explain something clearly, you must know it thoroughly. Discussions following your output further strengthen your understanding. It also helps others while building your reputation—if you’re good, you should let others know it too.

Conclusion

I recently visited Japan during the cherry blossom season. Let’s end with a photo of the blossoms.

This article is part of the “Sharp Tools Community Program.” Discover more creators and their tools at: http://liqi.io/community/

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

Liqi - High-Efficiency Tools Recommendation

2019-04-07T08:22:32.000Z

I saw the Liqi Community Project a long time ago. I learned a lot from everyone’s sharing. As stated in the beginning: “Tools and inspiration are both Liqi. When tools and inspiration from different fields collide with each other, more possibilities will emerge.“ Below are my simple answers to the 6 questions from the Liqi Community Project. I hope this can help everyone in some way.

Introduce Yourself and Your Work?

I am an Android system development engineer, working in the system R&D department of a certain phone manufacturer. My work mainly involves Android system-related tasks, such as performance, power consumption, stability, framework maintenance, etc. The work is quite diverse, dealing with various miscellaneous tasks.

As for hobbies, basketball, running, and gaming - these essential skills for programmers - naturally cannot be lacking; reading, raising cats, drinking tea - these artsy hobbies for young people also must not be neglected; in my spare time, I like to browse Bilibili and YouTube; when I have time, I complete unfinished articles I left behind; currently I’m obsessed with weight loss, fighting a desperate battle with my belly.

What Hardware Are You Using?

Computers: I mainly have three computers. One MacBook Pro for coding, writing my small apps, and processing photos; one company-configured desktop, Ubuntu system, mainly used for work, essential for compiling Android source code; one self-configured desktop, mainly used for gaming and compiling AOSP code.

Phones: I have three phones. My main device is iPhone X, and I’m satisfied with everything except the battery life. My backup device is a OnePlus 6, an Android flagship - as an Android engineer, I still need to have one usable Android machine. Another one is a Pixel, mainly used to run the AOSP code I compiled myself - essential for amateur framework learning.

Other Hardware: Apple family’s Watch, iPad Pro, AirPods; Sony’s large noise-canceling wireless headphones MDR-1000X; Kindle Voyage, dedicated for reading e-books.

What About Software?

Things3: Mainly used for arranging daily work and recording things to do
MWeb: Coding专用, this article is written with MWeb
Keep: A good fitness assistant, some courses can be followed, mainly for recording. Sometimes there’s a goal, it’s better to persist than without a goal, especially when running (I recommend the HIT treadmill for running training)
Dolphin Ledger: An accounting app, basically necessary.
Kindle && WeChat Reading: Reading apps. The two book libraries can complement each other. E-books are quite convenient, especially when reading on iPad Pro.
YouTube && Bilibili: Learning and entertainment, basically rely on them.
ShadowSocks && Wingy, Basically using ShadowSocks on Android and Mac. Using Wingy on phone and iPad. What’s convenient is having a small plugin. Sometimes the software gets killed, and the small plugin switch is very convenient.
Dedao Time && Get: Knowledge payment apps. Three people walking together, there must be my teacher. I personally think that listening to what others are doing, what they’ve done, how they did it - it’s quite beneficial for my own improvement. It saves me from taking many detours.
Google Photos: Basically all my photos are here. I’m really afraid that one day I won’t be able to access them. I’ll probably cry to death…
Reeder: I previously maintained a developer’s RSS feed list, and I personally use Reeder3 to read it.
Android Studio && VS Code: Productivity software. One is used to view Framework Java code, one is used to view C\C++ code.
RescueTime: Mainly used to record work time. I can check where I spent my time every day after coming back. It supports all platforms (though on iOS you can only view, not record; on Mac you can record; on Android, Ubuntu, and Windows you can both record and view). Sometimes when I look at my work time of a few hours, it makes me want to cry…
Shimo Docs: Recording my daily reports, weekly reports, and some research content. Supports all platforms, synchronization is very convenient, and multi-person collaboration efficiency is also high. The web client is best to use.
Jianguo Cloud: Cloud storage supporting all platforms. Upload materials once, never worry about losing them again (direct Ubuntu support is too friendly to programmers).
Yinxiang Notes: Previously used for recording, now more used as a collection center. When I encounter good articles, I usually record them here, then organize and review them later. Daily work recording is all handed over to Shimo Docs now.

What’s Your Ideal Work Environment?

The ideal work environment is Work Life Balance, just like what the recently popular 996 project describes. My current work situation is about the same, so I hope my work environment is what’s described in the 955.WLB project: work-life balance.

The greatest pressure 996 gives people is having no time of their own to improve themselves. They’re busy until 10 or 11 PM every day. Going back to take a shower and go to sleep. There’s simply no time for fitness, reading, learning, etc. As this article The most subtle way to destroy a person is to keep them so busy they have no time to grow says:

If a person only learns from the work process, then this single learning method will inevitably lead to its marginal contribution to growth becoming increasingly low.

You must make yourself have time to grow every day. Actually, this is to let you expand other growth methods beyond work. The more diversified your learning methods are, the higher the marginal contribution to growth will be. The faster you will grow.

A person must have continuous incremental growth in their career.

To sum up, my ideal work environment: having colleagues who share the same aspirations, having work that I love, having space and time for my own growth.

What Are Your Ways to Get Work Inspiration?

One is reading, extracting the essence from others’ thoughts to see if they can be used by me or improved or carried forward; the other is thinking and recording, drawing flow diagrams while thinking, recording the spark of certain thoughts.

However, no matter how good the effect is, when I get busy, I rarely have time to read and think. I ask all the great gods for guidance.

What I most want to recommend to everyone is not a certain hardware or software, but a learning method: Record-Summarize-Output. These three links form a loop:

Recording: We always say, good memory is worse than a bad pen, especially in this era of information explosion. Having your own recording method appears especially important. To-do items, occasional strange ideas that pop up, problems encountered and solution methods, good articles seen on certain websites, Blog posts to be updated, tutorial videos on YouTube, etc. - recording will make you appear organized.

Summarizing: Summarizing can gather previously scattered thoughts or knowledge together. Clear outlines help to look at a certain period or certain knowledge from an overall perspective. For example, project summaries can let us avoid the pitfalls in that project in future projects; summaries of certain knowledge points can let us understand this knowledge from points to surfaces, deepening the impression of this knowledge.

Outputting: Outputting can be private notes, Blogs, videos. Outputting is more about strengthening yourself by explaining to others. To explain clearly to others, you must be very familiar with the points you’re outputting; everyone’s discussion about your output will also strengthen your understanding of this knowledge point; outputting also helps others, while improving your own fame. If you’re strong, you have to let others know you’re strong too.

Finally

I recently went to Japan, catching the cherry blossom season. Let me end with a photo of cherry blossoms.

This article participated in “Liqi Community Plan”. Discover more creators and their tools: http://liqi.io/community/

About Me && Blog

Below is a personal introduction and related links. I look forward to communicating with colleagues in the same field. When three walk together, there must be my teacher!

Blogger Personal Introduction: Inside are personal WeChat and WeChat group links.
Blog Content Navigation: A navigation of personal blog content.
Personally Organized and Collected Excellent Blog Articles - Android Performance Optimization Must Know: Everyone is welcome to self-recommend and recommend (private WeChat chat is fine).
Android Performance Optimization Knowledge Planet: Welcome to join, thank you for your support~

“If you want to go fast, go alone. If you want to go far, go together.”

Case Analysis of System-wide Stutter Caused by Android Accessibility Service

2019-01-20T16:22:22.000Z

Phenomenon

Some users reported that while scrolling on the phone, the list would jitter. This happens when scrolling on the desktop or settings (as long as it is scrollable), but this is not reproducible for everyone; it appears for some users, but not for others.

Onlookers can scroll directly to the bottom to see The Culprit and Self-Check. Those interested in analyzing the problem can read the analysis process.

Systrace Analysis

There is a reproducible device for local testing. After analyzing it, it was found that sliding the desktop or settings with a finger will inevitably cause stuttering. From the Trace, it looks like this:

The red arrow indicates where the frame drop occurred. From the Buffer count above, it can be seen that the reason SF did not draw is that Launcher did not submit a Buffer.

The corresponding Launcher Trace is as follows. It can be seen that the reason Launcher did not draw is that no Input event was passed up. So the Launcher’s screen was not updated, causing frame drops.

The fact that no event came up is problematic in itself. Our finger slides across the screen continuously, so the event reporting should be continuous. We suspect there is a problem with the screen reporting points, but before checking the hardware, let’s first see if the InputReader and InputDispatcher threads are working properly.

From the figure, it can be seen that the InputReader thread is working properly, but the InputDispatcher thread has problems. You can see the correspondence between these two threads under normal circumstances:

Returning to the problematic figure, if you look closely, you will find that the cycle of the InputDispatcher thread is the same as Vsync. That is to say, the wake-up logic of InputDispatcher has changed from being woken up by InputReader to being woken up by Vsync.

If you look more closely, clicking on the cpu state of the InputDispatcher thread shows that the InputDispatcher thread waking up to execute tasks is not woken up by the InputReader thread, but by the UI Thread of System_Server.

So next, we need to look at why InputReader did not wake up InputDispatcher from the code perspective.

Code Analysis

The logic for InputReader to wake up the InputDispatcher thread is as follows (taking the Move gesture in this example accurately).

frameworks/native/services/inputflinger/InputDispatcher.cpp

void InputDispatcher::notifyMotion(const NotifyMotionArgs* args) {

    if (!validateMotionEvent(args->action, args->actionButton,
                args->pointerCount, args->pointerProperties)) {
        return;
    }

    uint32_t policyFlags = args->policyFlags;
    policyFlags |= POLICY_FLAG_TRUSTED;

    android::base::Timer t;
    mPolicy->interceptMotionBeforeQueueing(args->eventTime, /*byref*/ policyFlags);
    if (t.duration() > SLOW_INTERCEPTION_THRESHOLD) {
        ALOGW("Excessive delay in interceptMotionBeforeQueueing; took %s ms",
                std::to_string(t.duration().count()).c_str());
    }

    bool needWake; // Whether to wake up
    { // acquire lock
        mLock.lock();

        if (shouldSendMotionToInputFilterLocked(args)) {
            mLock.unlock();

            MotionEvent event;
            event.initialize(args->deviceId, args->source, args->action, args->actionButton,
                    args->flags, args->edgeFlags, args->metaState, args->buttonState,
                    0, 0, args->xPrecision, args->yPrecision,
                    args->downTime, args->eventTime,
                    args->pointerCount, args->pointerProperties, args->pointerCoords);

            policyFlags |= POLICY_FLAG_FILTERED;
            // SystemServer upper layer needs to filter events
            if (!mPolicy->filterInputEvent(&event, policyFlags)) {
                return; // event was consumed by the filter
            }

            mLock.lock();
        }

        // Just enqueue a new motion event.
        MotionEntry* newEntry = new MotionEntry(args->eventTime,
                args->deviceId, args->source, policyFlags,
                args->action, args->actionButton, args->flags,
                args->metaState, args->buttonState,
                args->edgeFlags, args->xPrecision, args->yPrecision, args->downTime,
                args->displayId,
                args->pointerCount, args->pointerProperties, args->pointerCoords, 0, 0);

        needWake = enqueueInboundEventLocked(newEntry); 
        mLock.unlock();
    } // release lock

    if (needWake) {
        mLooper->wake();
    }
}

Note here that mPolicy->filterInputEvent returns directly, which means if it returns false here, it returns directly and does not continue to execute the following steps.

Continue to look at mPolicy->filterInputEvent

frameworks/base/services/core/jni/com_android_server_input_InputManagerService.cpp

bool NativeInputManager::filterInputEvent(const InputEvent* inputEvent, uint32_t policyFlags) {
    ATRACE_CALL();
    jobject inputEventObj;

    JNIEnv* env = jniEnv();
    switch (inputEvent->getType()) {
    case AINPUT_EVENT_TYPE_KEY:
        inputEventObj = android_view_KeyEvent_fromNative(env,
                static_cast<const KeyEvent*>(inputEvent));
        break;
    case AINPUT_EVENT_TYPE_MOTION:
        inputEventObj = android_view_MotionEvent_obtainAsCopy(env,
                static_cast<const MotionEvent*>(inputEvent));
        break;
    default:
        return true; // dispatch the event normally
    }

     
    
    // The callee is responsible for recycling the event.
    jboolean pass = env->CallBooleanMethod(mServiceObj, gServiceClassInfo.filterInputEvent,
            inputEventObj, policyFlags);
    if (checkAndClearExceptionFromCallback(env, "filterInputEvent")) {
        pass = true;
    }
    env->DeleteLocalRef(inputEventObj);
    return pass;
}

Here it calls back from jni to the java layer, which is the filterInputEvent method of InputManagerService.

com/android/server/input/InputManagerService.java

// Native callback.
final boolean filterInputEvent(InputEvent event, int policyFlags) {
    synchronized (mInputFilterLock) {
        if (mInputFilter != null) {
            try {
                mInputFilter.filterInputEvent(event, policyFlags);
            } catch (RemoteException e) {
                /* ignore */
            }
            return false;
        }
    }
    event.recycle();
    return true;
}

Following the code flow, it is found that this mInputFilter is an instance of AccessibilityInputFilter. When the switch is turned on in Accessibility, the updateInputFilter method of AccessibilityManagerService is called to set the InputFilter.

android/view/InputFilter.java

final public void filterInputEvent(InputEvent event, int policyFlags) {
    mH.obtainMessage(MSG_INPUT_EVENT, policyFlags, 0, event).sendToTarget();
}

case MSG_INPUT_EVENT: {
    final InputEvent event = (InputEvent)msg.obj;
    try {
        if (mInboundInputEventConsistencyVerifier != null) {
            mInboundInputEventConsistencyVerifier.onInputEvent(event, 0);
        }
        onInputEvent(event, msg.arg1);
    } finally {
        event.recycle();
    }
    break;
}

Continue to look at onInputEvent(event, msg.arg1);
com/android/server/accessibility/AccessibilityInputFilter.java

@Override
public void onInputEvent(InputEvent event, int policyFlags) {
    if (mEventHandler == null) {
        if (DEBUG) Slog.d(TAG, "mEventHandler == null for event " + event);
        super.onInputEvent(event, policyFlags);
        return;
    }

    EventStreamState state = getEventStreamState(event);
    if (state == null) {
        super.onInputEvent(event, policyFlags);
        return;
    }

    int eventSource = event.getSource();
    if ((policyFlags & WindowManagerPolicy.FLAG_PASS_TO_USER) == 0) {
        state.reset();
        mEventHandler.clearEvents(eventSource);
        super.onInputEvent(event, policyFlags);
        return;
    }

    if (state.updateDeviceId(event.getDeviceId())) {
        mEventHandler.clearEvents(eventSource);
    }

    if (!state.deviceIdValid()) {
        super.onInputEvent(event, policyFlags);
        return;
    }

    if (event instanceof MotionEvent) {
        if ((mEnabledFeatures & FEATURES_AFFECTING_MOTION_EVENTS) != 0) {
            MotionEvent motionEvent = (MotionEvent) event;
            processMotionEvent(state, motionEvent, policyFlags);
            return;
        } else {
            super.onInputEvent(event, policyFlags);
        }
    } else if (event instanceof KeyEvent) {
        KeyEvent keyEvent = (KeyEvent) event;
        processKeyEvent(state, keyEvent, policyFlags);
    }
}

Continue to look at processMotionEvent

private void processMotionEvent(EventStreamState state, MotionEvent event, int policyFlags) {
    if (!state.shouldProcessScroll() && event.getActionMasked() == MotionEvent.ACTION_SCROLL) {
        super.onInputEvent(event, policyFlags);
        return;
    }

    if (!state.shouldProcessMotionEvent(event)) {
        return;
    }

    batchMotionEvent(event, policyFlags);
}

Continue to look at batchMotionEvent

private void batchMotionEvent(MotionEvent event, int policyFlags) {
    if (DEBUG) {
        Slog.i(TAG, "Batching event: " + event + ", policyFlags: " + policyFlags);
    }
    if (mEventQueue == null) {
        mEventQueue = MotionEventHolder.obtain(event, policyFlags);
        scheduleProcessBatchedEvents();
        return;
    }
    if (mEventQueue.event.addBatch(event)) {
        return;
    }
    MotionEventHolder holder = MotionEventHolder.obtain(event, policyFlags);
    holder.next = mEventQueue;
    mEventQueue.previous = holder;
    mEventQueue = holder;
}

Continue to look at scheduleProcessBatchedEvents

private void scheduleProcessBatchedEvents() {
    mChoreographer.postCallback(Choreographer.CALLBACK_INPUT,
            mProcessBatchedEventsRunnable, null);
}

mProcessBatchedEventsRunnable will be executed in the next Vsync cycle, which is Choreographer.CALLBACK_INPUT. Students familiar with Choregrapher should know what is happening here.

private final Runnable mProcessBatchedEventsRunnable = new Runnable() {
    @Override
    public void run() {
        final long frameTimeNanos = mChoreographer.getFrameTimeNanos();
        }
        processBatchedEvents(frameTimeNanos);
        if (mEventQueue != null) {
            scheduleProcessBatchedEvents();
        }
    }
};

So the code is relatively clear here. It is because of the existence of AccessibilityInputFilter that the InputDispatcher thread was not woken up, but the event processing was put into the next Vsync for processing.
Conclusion

The problem lies in this Runnable. Normally, if AccessibilityInputFilter is not turned on, the upper layer will not intercept Input events at all. Once there is AccessibilityInputFilter, the logic above will be followed. At this time, InputDispatcher will not follow the rhythm of InputReader, but follow the rhythm of Vsync. This can also be seen from the Trace;

So where does this AccessibilityInputFilter come from? The answer is the Accessibility service, also known as the barrier-free service.

The Culprit

Through the above analysis, we know that the cause of the problem is the Accessibility service. The essence of the Accessibility service is to serve those users who are inconvenient to operate, such as blind people. However, in order to implement specific functions, some Apps have also added their own Accessibility services, such as the “one-click installation” function of major mobile phone markets. It is convenient for users, but if not used well, it will also have negative effects, such as this case, causing the user’s mobile phone to stutter. Users who don’t know may want to return the phone.

So who is the culprit? Currently two have been found, one is iFlytek Input Method and the other is Yingyongbao. Open Settings - System - Accessibility, you can see that various software inside are involved, but this is turned off by default. Many applications will guide users to turn it on, and many users turn it on confusedly.

The Accessibility service page is as follows:

As for how awesome the Accessibility service is, everyone can look at the pop-up box below. This thing can detect your credit card number and password. As for SMS content and WeChat chat content, those are small cases.

As for what caused the whole machine to stutter in this example, it is the following listener “Perform Gesture”. Once an application listens to this, the InputDispatcher thread will follow the cycle of Vsync, resulting in untimely report processing, causing the sliding object to think that no event entered this frame, so there is no content change, and the page will not be updated, resulting in stuttering.

Self-Check

If you are using an Android phone, it is strongly recommended that you turn off all Accessibility services (if you don’t need them). Functions like automatic application installation are not worth the huge risk you pay for them. This is a native Android problem, and we have found this problem on Pixel and other third-party phones.

Close path: Settings - System - Accessibility, go in and close all the ones you have opened.
Strongly recommend Yingyongbao, iFlytek Input Method, do not listen to gesture events.

Zhihu Address of this article

Since blog message communication is inconvenient, for likes or communication, please move to the Zhihu interface of this article
Zhihu - Analysis of Global Stutter Caused by Accessibility Services of Yingyongbao and iFlytek Input Method on Android Platform

About Me && Blog

Below are personal introduction and related links. I hope to communicate more with everyone in the industry. If three people walk together, there must be one who can be my teacher!

Blogger Personal Introduction: There are personal WeChat and WeChat group links inside.
This Blog Content Navigation: A navigation of personal blog content.
Excellent blog articles organized and collected by individuals - A must-know for Android efficiency optimization: Everyone is welcome to recommend themselves and recommend others (WeChat private chat is fine)
Android Performance Optimization Knowledge Planet: Welcome to join, thanks for your support~

One person can go faster, a group of people can go further

2018 Best Items Recommendations - A Reward for Your Hard Work

2019-01-12T02:51:05.000Z

At the beginning of 2018, I wrote 2017 Best Items Recommendations. Recently, some people asked if I’d do one for 2018. Although 2018 was a tough year, there were still some great things worth recommending to everyone.

Just like in 2017, I’ll share things that I found helpful for work or life. The recommendations include apps, hardware, books, blogs, and columns. I hope they provide value to you in 2019.

Recommended Apps

RescueTime

RescueTime is a time-tracking software that accurately records how you spend your day (requires a local client).

If you are a programmer and want to track your productivity, RescueTime is an absolute must. You can clearly see where your time goes. For instance, I spend most of my time in Android Studio, VS Code, and Terminator. Below is a screenshot from January 15th:

Detailed Programming Info:

With this data, you know exactly how much time you’re actually spending on the computer. It supports almost all platforms, including Linux (though on iOS, it can only view data, not record it).

Shimo Docs

In 2018, I switched my daily work logging from MWeb to Shimo Docs. The main reason is its multi-platform support (Mac, iOS, Android, WeChat Mini Programs). More importantly, the web version is excellent. I can record and view notes in real-time, and sharing is seamless with read-only or collaborative permissions.

Another reason: A good web-based note app should respect programmers by handling Ctrl+S. Evernote often fails at this, while Shimo Docs correctly saves content.

Nutstore (Jianguoyun)

Nutstore is a reliable cloud sync service for teams and individuals. Finding a good folder-syncing software in China is tough, but I eventually settled on Nutstore because it supports Linux. When working in Linux, I just drop files into the sync folder, and they are immediately available on all my other devices.

Recommended Technical Books

Understanding Android Architecture (2nd Edition)

A classic for system developers. This year saw the second edition with new content. Whether you’re an app engineer or a system engineer, understanding Android’s architecture is crucial for deepening your knowledge. Given how fast Android evolves, I recommend reading this alongside the latest Android source code.

“Understanding Android Internals” covers Android 4.3 and above. It analyzes core technologies like processes/threads, memory management, Binder, GUI, multimedia, and input systems. Most knowledge points come from real-world R&D projects.

Douban: https://book.douban.com/subject/25921329/

Android Advanced Decryption

This book targets Android 8.0 source code combined with practical application knowledge. It covers system source code, JNI, ClassLoader, JVM, DVM/ART, Hook techniques, Hot-fixing, and performance optimizations (draw and memory). It builds a comprehensive knowledge system for developers.

JD: https://item.jd.com/12447229.html

Running Linux Kernel

Essential for Android system engineers. Based on Linux 4.x, it covers memory management, process management, concurrency, and interrupts. Each section poses a problem to solve through source code analysis, making it highly practical for embedded and Android low-level developers.

Douban: https://book.douban.com/subject/27108677/

Recommended Non-Technical Books

Blades of the Guardians (Biaoren)

A top-tier Chinese manhua (comic) set in the Sui and Tang dynasties with a 8.3 Douban rating. It follows a skilled escort, Dao Ma, across the Western deserts as he takes on a high-stakes mission to the capital, Chang’an. Available on WeChat Read.

Great Defeats 2 (Dabaiju 2)

After reading the first volume, I was hooked. As a Douban review states: “High-level reality. In the tide of the times, entrepreneurs and founders are no different from gamblers. Those with ambition get lost in the halo of success, only to see themselves clearly after a crushing defeat.” Volume 2 analyzes the downfall of nine famous Chinese enterprises.

The Passionate Programmer: From Good to Great

A companion to “The Productive Programmer,” featuring essays from the Coding Horror blog by Jeff Atwood. It covers time management, coding methods, testing, and tech reading. It’s a great guide for developers at all stages to refocus on the human aspect of software development.

My reading notes:

Recommended WeChat Accounts

hongyangAndroid
Google_Developers
guolin_blog
googdev
LinuxDev
hencoder
androidperf (Android Performance Optimization)
nanchen_android
flutter-io
Tencent Bugly

Software Services

WeChat Read (Memberships)

The most valuable subscription I paid for this year. The annual membership covers almost all paid publications and audiobooks. I’ve read over 20 books here this year, including “The Three-Body Problem,” “Hacker and Painters,” and “The Grain Brain.”

Recommended Consumer Goods

12.9” iPad Pro

The 2018 iPad Pro is incredible in every way. It can almost replace a laptop for reading, taking notes, and watching videos. The 120Hz ProMotion display is a pure joy to use.

Recommended Online Columns

Geek Time: Android Development Masterclass

A custom course for Android developers covering complex topics like crashes, memory, jank, startup, I/O, storage, network, power, and UI. Highly recommended for any serious Android engineer.

Geek Time: Linux Performance Optimization in Action

Recommended for Linux and Android low-level developers. Taught by a senior Microsoft Azure engineer, it uses a case-driven approach to teach underlying principles and professional optimization techniques.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
Android Performance Optimization Knowledge Planet

One walks faster alone, but a group walks further together.

Setting Up the Android System Development Environment

2018-11-01T11:40:16.000Z

Whether you are an Android App developer or a System developer, having a foundational understanding of the Android system is extremely beneficial. I recently set up a development environment at home and decided to share the process for anyone interested.

The general steps involved are as follows:

Installing Ubuntu
Configuring Ubuntu
Installing Essential Software
Configuring a VPN (Optional)
Downloading AOSP Code
Setting Up the Build Environment and Compiling Pixel Code
Flashing the Device
Modifying and Compiling Framework, Services, and Res

Recommended Hardware

While not strictly required, having the following makes the process much smoother:

A PC or Laptop
A 512GB SSD
A Pixel device

1. Installing Ubuntu

For Linux development, I recommend using Ubuntu as your primary OS rather than a virtual machine. Installing it directly on your hardware provides better performance. The current recommended LTS version is 18.04. The installation process is fairly straightforward:

Download Ubuntu 18.04: ubuntu 18.04
Create a bootable USB drive using the tool recommended by Ubuntu.
Install Ubuntu using the USB drive.

2. Configuring Ubuntu

Install an input method (e.g., Sogou Pinyin).
Install vim: sudo apt install vim
Install adb
Install fastboot

3. Installing Essential Software

VS Code
Android Studio
Meld (for diffing)
Wine
WPS Office

4. Configuring a VPN (Optional)

ShadowSocks

5. Downloading AOSP Code

If you cannot access Google servers directly, I recommend using the Tsinghua University mirror: https://mirror.tuna.tsinghua.edu.cn/help/AOSP/

Download repo

mkdir ~/bin
PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

Create Working Directory

1 2	mkdir WORKING_DIRECTORY cd WORKING_DIRECTORY

Initialize the Repository

1	repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest

Sync the Code

(Using -c --no-tags downloads less data, speeding up the process)

1	repo sync -c --no-tags

6. Setting Up the Build Environment and Compiling Pixel Code

Install JDK

1 2	sudo apt-get update sudo apt-get install openjdk-8-jdk

Install Dependencies

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev libxml2-utils xsltproc unzip

Download Pixel Drivers

When compiling code for the Android Master branch (or specific versions), you need to download the drivers corresponding to your device. You can find them here:
https://developers.google.cn/android/blobs-preview

Extracting drivers image

The extracted files should look like this:

Compile the Pixel System Image

Run the following at the root of your source directory:

1	source build/envsetup.sh

Next, use the lunch command to select your device model and build type (user, userdebug, eng):

lunch

After making your selection, type the corresponding number and start the compilation with make. You can use the -j flag to specify the number of threads (e.g., -j8 for 8 threads). Adjust based on your CPU performance:

make -j8

Successful Compilation

The out directory will contain the generated images.

7. Flashing the Device

From the root of your source directory, run the following command to flash the system onto your device:

1	fastboot flashall

8. Modifying and Compiling Framework, Services, and Res

Run the following commands from the root of your source directory.

Recommended IDEs

Java Code: Use Android Studio for opening and editing.
C/C++ Code: Use SourceInsight, Eclipse, or VS Code.

Compiling Framework

1	mmm frameworks/base

Compiling Services

1	mmm frameworks/base/services

Compiling Res

1	mmm frameworks/base/core/res

Root and Remount

Push Changes

Once you have root and remount access, you can adb push the modified framework, services, or res files to the device. Restarting the shell or the device will apply the changes. Alternatively, use adb sync system. This synchronizes the system directory from your out folder to the device, which is extremely convenient.

Example:

1	adb root && adb remount && adb shell stop && adb sync system && adb shell start

About Me && Blog

Below are my personal details and links. I look forward to connecting and sharing knowledge with fellow developers!

About Me: Includes my WeChat and WeChat group links.
Blog Navigation: A guide to the content on this blog.
Curated Android Performance Articles: A collection of must-read performance optimization articles. Self-nominations/recommendations are welcome!
Android Performance Knowledge Planet: Join our community for more insights.

“If you want to go fast, go alone. If you want to go far, go together.”

Lu Qi: Besides Good Code, What Makes an Engineer Excellent?

2018-10-25T02:37:34.000Z

Reposted from: Baidu Family, based on Lu Qi’s internal sharing at Baidu in July 2017. It is highly worth learning and pondering for technical personnel.

I personally admire Lu Qi. “Lu Qi is known for his incredible energy. He typically wakes up at 4 AM, checks emails, and then runs 4 miles on a treadmill while listening to classical music or watching news. He arrives at the office between 5 AM and 6 AM, using that time to prepare for the day undisturbed, and usually works until 10 PM, sometimes sending emails to colleagues at midnight. LinkedIn CEO Jeff Weiner, who worked with Lu Qi at Yahoo for years, initially thought this schedule was unsustainable but eventually said: ‘Lu Qi is indeed the most driven person I have ever met.’ Former Yahoo engineer Amit Kumar also praised Lu’s popularity. Lu says: ‘I don’t feel tired; I love my job every day.’ Lu Qi holds 20 US patents.”

The core ideas of Lu Qi’s speech can be summarized into the following five points. I have posted them on my study wall to remind myself constantly.

“We must have an unwavering and profound belief that the entire world is ultimately driven by technology.”
“Has anyone else already solved this problem? If so, put your time into better innovation.”
“Whatever you do, aim to be the best, to be the strongest in the industry.”
“I imagine myself as a piece of software, a piece of code. Today’s version must be better than yesterday’s, and tomorrow’s will surely be better than today’s.”
“If you see a problem, don’t just ask others—Fix it.”

Believe in Technology

First, believe in technology. As I mentioned, for our industry, and especially for companies like Baidu, a steady and unwavering belief in technology is vital.

I’d also like to share that Bill Gates mentioned Microsoft’s mission as: writing software represents the future of the world.

Why? Because any industry in the future will become a software industry. Gates was right because the degree of automation in any industry will keep increasing, and ultimately, what you process is information and knowledge.

But the way software works has moved forward again. In the age of AI, it’s not just about writing code; you must understand algorithms, hardware, and data. The entire AI development process has advanced significantly. However, technology—especially the technology represented by our industry—will always be at the forefront of any future industry.

Therefore, we must have an unwavering and profound belief that the entire world is ultimately driven by technology.

Innovate on the Shoulders of Giants

If we look at Silicon Valley in the US or China, whether it’s an internet startup or a large corporation, the starting point for everyone is getting higher. Why is the speed of innovation so fast now? Mainly because the starting point is high. The code modules and service capabilities we can use have greatly improved.

Internally, I want to emphasize this. Many large companies, including Microsoft, have rewritten internal code countless times.

My requirement now is: Every time you write a new line of code, the first thing to do is think about whether that line is worth writing. Has someone else already done the same work, perhaps even better? Has anyone else already solved this problem? Then you can put your time into better innovation.

Especially in large companies, there is too much repeated or nearly repeated code, wasting too many resources. This isn’t good for anyone’s career.

Again, within a large company, think before you write code: Do I need to write this? Does someone else already have it? Stand on the shoulders of others to do this.

Pursue Engineering Excellence

Another thing I want to emphasize is Engineering Excellence—the technical excellence and capability in engineering.

Competition in any market is like war. It depends on the physical strength and quality of your troops, the level of training for each soldier, and the weapons you give them—machine guns, tanks, or something else.

Engineering Excellence is analogous to this. We want to build the world’s strongest force. Every soldier, every leader, everyone’s capability and training are top-notch, and the tools and weapons we provide are first-class.

Therefore, Engineering Excellence is a collective pursuit of individual and team capability, alongside innovation in tool platforms. Combined, they bring us long-term core competitiveness and create value for society—ultimately for every user, enterprise, and society as a whole.

I also want to emphasize here: Relentless pursuit of excellence—a never-ending, continuous pursuit.

We either don’t do it, or we do it best. This is my requirement for everyone. Whether it’s a database, a large platform, or big data, whatever we decide to do, we must be determined. Aim to be the best, to be the strongest in the industry.

Learn Every Day

Learning every day is perhaps the most important thing for everyone.

Today, I’ll share how I think about myself. It’s a simple concept: I imagine myself as a piece of software, a piece of code. Today’s version must be better than yesterday’s, and tomorrow’s will surely be better than today’s, because even if I make a mistake, I have an if statement inside that says: If I see this error again, never repeat it.

In English, there is a saying: “Life is too short, don’t live the same day twice.” Every day should be different, and every day should be better. Today’s version must be better than yesterday’s. Every outstanding engineer and technical leader must maintain the ability to learn, especially the scope of their learning.

To expand on this, if you only study Computer Science, it’s certainly not enough. For example, you must study Economics. Why? Computer Science has a major limitation: it assumes that once you have an input, you get an output. This problem-solving approach has its benefits but also its limitations.

Take map navigation as an example. If you use a purely technical approach, you just move people from one congested area to another. Economics models problems differently. It starts by assuming an overall ecosystem where one person’s input is another person’s output. To describe a navigation problem through economics, you calculate an Equilibrium. Markets work the same way.

If you want to truly understand Deep Learning, you must relearn Physics, look at Biology, and study Evolutionary Theory. Because Deep Learning is closely related to these fields. You can’t figure it out on your own; to understand it thoroughly, you must study.

Also, study Product. I’ve always told engineers: if you don’t understand the product, you can’t be a top engineer. To truly be a world-class engineer, you need to understand not just the product but also the entire business and ecosystem. Your responsibility is to see the future—to project technology into future needs and prepare your platform, development flow, and team for that future. So, learning is incredibly important.

Ownership

Finally, it starts with me.

Our company has a grand mission: to simplify a complex world with technology. The world is very, very complex. Essentially, what humans do is “Reduce entropy.”

According to the Second Law of Thermodynamics, the world tends to become more chaotic. What we want to do is make it simpler and make our lives better.

Specifically, we can use AI technology to “awaken all things.” But all of this is built on the accumulated actions of every individual—starting with me. Then there is Ownership: if you see an opportunity, don’t ask others—just do it. If you see a problem, don’t ask others—Fix it.

Treat our mission and our company as your own personal career. I can tell you honestly: if you treat the company’s mission and business as your own and “Own everything,” your career will certainly move the fastest. Start with yourself, start with everything around you.

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One walks faster alone, but a group walks further together.

The Programmer's Apprenticeship - 08: The Beauty of Reading

2018-10-01T06:34:15.000Z

This is the eighth post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

I will excerpt some wonderful remarks from the book and sometimes add my own insights or experiences. The outline of the reading notes is consistent with the outline of the book itself. This is also a method I learned from another source and have been using: “How to Read a Book”. I record it for my own frequent review and for readers’ reference. Below is the The Programmer’s Apprenticeship reading note series:

Not Reading, Whose Fault Is It?

(Based on Jeff Atwood’s Programmers Don’t Read Books – But You Should)

There’s a saying: “Programmers don’t read books.” Jeff explores why this might be true. Often, technical books are dry, outdated by the time they are printed, or just plain boring. The Internet has replaced the reference book for many of us.

However, Jeff argues that we are missing out. Deep knowledge often requires the long-form structure that only a book (or a very long series of articles) can provide. Reading code is important, but reading about code—the philosophy, the architecture, the “why”—is equally vital.

We can’t just blame the industry or the medium. If we don’t read, it’s our own fault. We stagnate. We miss the wisdom of the “giants” upon whose shoulders we stand. Books like The Pragmatic Programmer, Code Complete, and The Mythical Man-Month are timeless for a reason.

Heaven Helps Those Who Help Themselves

(Based on Jeff Atwood’s How To Ask Questions The Smart Way and What have you tried?)

This section echoes the core philosophy of Stack Overflow: Self-reliance.

Before you ask for help, you must demonstrate that you have tried to help yourself. “Heaven helps those who help themselves” implies that you shouldn’t expect others to solve your problems if you haven’t put in the effort first.

Jeff famously asks: “What have you tried?”

If you encounter a bug, don’t just post the error message. Tell us:

What you expected to happen.
What actually happened.
What you have already done to try to fix it.

This isn’t just about etiquette; it’s about being a better engineer. The act of formulating the question and documenting your attempts often leads you to the answer before you even ask it (Rubber Duck Debugging).

History and Status Quo of Computer Crime

(Based on Jeff Atwood’s Computer Crime, Then and Now and I Was a Teenage Hacker)

In “I Was a Teenage Hacker,” Jeff recounts his own minor brush with the dark side of computing—writing a wardialer script in his youth. He uses this anecdote to discuss the evolution of computer crime.

Decades ago, hacking was often about curiosity or notoriety. Today, it is a massive, organized criminal industry. But interestingly, the techniques haven’t changed that much. Social engineering, weak passwords, and unpatched vulnerabilities are still the primary vectors.

What has changed is the scale and the stakes. We are now “digital by default,” meaning a breach isn’t just an annoyance; it’s a threat to our identity, our finances, and our infrastructure. Understanding the history of computer crime helps us realize that security isn’t a product you buy; it’s a process you practice providing.

How to Communicate with People

(Based on Jeff Atwood’s The Art of Speaking and Communication Skills)

Ideally, code would speak for itself. In reality, communication is the most important skill for a programmer.

You can be the best coder in the world, but if you can’t explain your ideas to your team, persuade your manager, or understand your users, you will fail. Jeff emphasizes the importance of writing clearly (blogging helps with this!) and speaking confidently.

Soft skills are hard. They require empathy, patience, and practice. But they are force multipliers for your technical skills.

Practice Basic Skills Diligently

(Based on Jeff Atwood’s The Ten Commandments of Egoless Programming and Practice Makes Perfect)

Finally, there are no shortcuts. To be awesome, you must practice.

But “practice” doesn’t just mean typing code for 10 hours a day. It means:

Deliberate Practice: Working on things you are bad at, not just things you are good at.
Code Katas: Small exercises to keep your skills sharp.
Reading Code: Reading other people’s code to learn new patterns.

Excellence is a habit. It comes from the daily discipline of trying to suck a little less than you did yesterday.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

The Programmer's Apprenticeship - 07: Games and Programming

2018-09-30T06:34:15.000Z

This is the seventh post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

My Programming Career Started with BASIC

(Based on Jeff Atwood’s About Me and Please Don’t Learn to Code)

Jeff Atwood frequently mentions that his programming journey began with BASIC. His first computer was a Texas Instruments TI-99/4a, and like many microcomputers of that era, it booted directly into a BASIC interpreter. This immediacy—turn on the machine, type a few lines of code, and see something happen—was crucial.

He argues that this low barrier to entry is something we’ve lost. In the “good old days,” the machine invited you to program it. Today, layers of abstraction and complex tooling can make the first step daunting.

However, he also famously wrote “Please Don’t Learn to Code,” arguing that not everyone needs to be a programmer. But for those who are drawn to it, that initial spark of creation—often fueled by simple tools like BASIC—is irreplaceable. It’s about the joy of building.

If You Want to Play a Game, Write It Yourself

(Based on Jeff Atwood’s Coding Horror: The Game and related thoughts)

There is no better way to understand how software works than to try to build a game. Games are complex systems that require mastering loops, logic, graphics, and user interaction.

Jeff encourages aspiring programmers to try their hand at game development, not necessarily to become professional game developers, but to understand the mechanics of engagement. If you can build a game that is fun to play, you have learned valuable lessons about user experience (UX) and performance that apply to all software development.

“The best way to learn is by doing. And the most fun thing to ‘do’ is a game.”

Metamorphosis from Gamer to Programmer

(Based on Jeff Atwood’s The Gamer / Programmer and The PC Weenies)

There is a huge overlap between gamers and programmers. Many of us got into this field because we wanted to understand how our favorite games worked—or because we wanted to mod them.

Jeff discusses how this background influences our mindset. Gamers are used to:

Problem Solving: Every game is a series of puzzles to be solved.
Perseverance: We are used to failing (dying) and trying again until we succeed.
Optimization: We are always looking for the “min-max” strategy to get the best result with the least effort.

Transformation comes when we stop just consuming the content and start creating it. We peek behind the curtain. We realize that the “magic” is just code, and that we can wield that magic ourselves. The passion that drives a gamer to master a level is the same passion that drives a programmer to master a new language or framework.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

The Programmer's Apprenticeship - 06: All About the Internet

2018-09-29T06:34:15.000Z

This is the sixth post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

Saving the Internet, Preserving All Memories

(Based on Jeff Atwood’s Preserving The Internet… and Everything Else)

In “Preserving Our Digital Pre-History”, Jeff nominated Jason Scott to be our generation’s digital historian in residence. It looks like a few people must have agreed, because in March 2011, he officially became an archivist at the Internet Archive.

Jason recently invited Jeff to visit the Internet Archive, and he walked away profoundly impressed with their mission. The Internet Archive is the beginning of a cure – the beginning of complete, detailed, accessible, searchable memory for society.

One of the most immediate benefits is curing linkrot. We’ve all experienced the frustration of clicking a link that’s dead. It’s a “digital heart attack.” The Internet Archive’s Wayback Machine allows us to travel back in time to see the web as it was.

But it goes beyond just web pages. They are archiving everything: books, audio, video, and even software. As Jeff notes:

“If you care about the history of the Internet – and you should, because it’s the history of us – then you should support the Internet Archive.”

The Importance of Net Neutrality

(Based on Jeff Atwood’s The Importance of Net Neutrality)

Net neutrality is “the most important public policy you’ve probably never heard of.” It refers to the principle that Internet service providers should treat all data on the Internet the same, not discriminating or charging differentially by user, content, website, platform, application, type of attached equipment, or method of communication.

Jeff admits he didn’t fully understand its importance until reading Lawrence Lessig and Tim Wu. The core argument is simple: innovation depends on a neutral network.

If the network owners can pick winners and losers (by throttling traffic or charging extra for fast lanes), then the next Google, Netflix, or Facebook might never get off the ground. The Internet was designed to be a dumb network that moves bits without prejudice. Keeping it that way is essential for the future of free speech and innovation.

“The internet is the first medium that can truly compete with the broadcast monopolies of television and radio. It is the first medium that allows anyone to be a broadcaster. But that freedom is threatened if the network itself is not neutral.”

Copyright Protection on YouTube

(Based on Jeff Atwood’s YouTube vs. Fair Use and YouTube: The Big Copyright Lie)

YouTube is a massive repository of human creativity, but it’s also a battlefield for copyright. Jeff points out the “Big Copyright Lie” of YouTube: the vast majority of its most popular content is not 100% original. It’s remixes, clips, and mashups of existing copyrighted material.

This brings us to the concept of Fair Use. Fair use is a legal doctrine that permits limited use of copyrighted material without acquiring permission from the rights holders. It includes commentary, criticism, news reporting, research, teaching, or scholarship.

However, YouTube’s automated Content ID system often ignores Fair Use. It flags content based on digital fingerprints, regardless of context. This creates a “guilty until proven innocent” system where creators have to fight to get their lawful content reinstated.

Jeff argues that we need a better balance. We need to protect the rights of copyright holders, but we also need to protect the rights of creators to build upon culture. The current system is heavily weighted in favor of big media companies, often at the expense of individual creativity.

“Culture is a remix. Everything is a remix. If we can’t build on what came before us, we stop progressing.”

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

The Programmer's Apprenticeship - 05: Know Your Users

2018-09-28T03:57:02.000Z

This is the fifth post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

The Controversy of “homo logicus”

Among all the “bad habits” of software developers, the most serious one is probably: We think we are typical users. However, what most developers don’t realize is that we are actually outliers. We are by no means ordinary people — we are margin dwellers.

The author mentions the concepts of “homo logicus” (Logical Man) and “homo sapiens” (Modern Wise Man/Ordinary User):

Logical Man: Logical people desire to control things that interest them, and those things are complex deterministic systems. Humans are complex, but they are not like machines; their behavior is not logical or predictable. The best machine is digital because it can become most complex and sophisticated, and can be easily changed by programmers.
Homo Sapiens: Ordinary users who just want to use things simply, not control them.

For logical people, control is their goal, and complexity is the price they are willing to pay. For ordinary people, simplicity is their goal, and losing control is the price they are willing to pay. Logical people are driven by an irresistible cognitive desire for how things work, while homo sapiens desire success.

Alan Cooper listed some typical characteristics of logical people. You can see if you fit:

Willing to sacrifice simplicity for control.
Willing to fail in exchange for cognition.
Do not let go of any possibility.
Behave like sports students (treating technology as a competitive sport).

Another sentence software engineers need to remember: Anyone can make a complex software that no one will use; it’s not hard! Making software simple and easy to use is the real skill. You must stop thinking like a logical person and learn to think like a homo sapiens.

Ivory Tower Development

Ivory tower development refers to: development teams locked in a “high tower” all year round, bent on making magical software. Because of the lack of strong evidence, developers assume everyone else is a developer, which is dangerous.

The author suggests: Throughout the project cycle, try your best to expose your developers to users: attend user meetings, participate in usability testing and acceptance testing, communicate with users, and analyze user data and behavior.

The “mutual trust relationship” proposed by Eric: When people buy software from you, they have many expectations for the present and the future:

They trust that your product works properly on their machines.
They trust that if they encounter problems, you will help them.
They trust that you will persistently improve the product.
They trust that you will provide them with improved versions at a fair and reasonable price.
They trust that your company will not go bankrupt in a short time.

Consequences of Letting Programmers Design Interfaces

Excellent programmers know themselves well and know what they can do and what they cannot do. They either copy existing excellent designs directly; or stick to coding and leave the interface design work to other experts.

If you are a friend, don’t let your friend create an interface that only programmers would use.

Protect “The Intermediates”

Experts and novices are only a small part of the population. Most users with similar levels belong to the “intermediates.” You should value these intermediates. The number of intermediate users is so huge and dominant that you can give up on novice and expert users if needed.

To cater to the few novices and experts, you spend a lot of time in the software development process, ultimately just making the product worse, and neglecting the core user group.

Every User Lies

Users’ wishes and reality are almost always contradictory. We advocate observing users’ actual behavior rather than listening to their narration of what they did, because of this deviation. Observation is a powerful skill. Learn to judge by people’s behavior, not take what they say as truth.

The author mentioned the concept of “active user paradox”: The active user paradox is a contradiction because if users know a little more about the system, it will save time in the long run. But in the real world, people’s behavior patterns are not like that. Therefore, we cannot tolerate engineers developing products for idealized users, because people in reality are irrational. We must design products based on users’ actual behavior patterns.

Every user lies. Expecting to ask users if they like your software – they will certainly say they like it, because saying to your face how terrible your software is would be rude – you should follow Gregory House: Observe whether they use your software and how they use it. Design your software based on behavioral data, not on the “lies” users tell (no matter how well-intentioned those lies are).

Don’t Make Product Launch the Goal

A standard for measuring whether a programmer is successful is to see how much code they have released, but just releasing is not enough. How many users are using your software is the ultimate goal of measuring success.

Smart software developers know that their work is far more than writing code and releasing products; their work is to develop software that people really want to use. This certainly includes coding, but there are also a large number of other global things, such as writing technical documentation, interaction design, cultivating community users, and even product vision. These are crucial to the overall success of the software. If you don’t even understand this, then what kind of code you wrote doesn’t matter.

Don’t Ask, Observe

What users say they want to do is often vastly different from what they actually do. From a usability perspective, asking users what they want is futile for this reason – you must observe what they are doing. In terms of usability, you cannot act on guesses; you must observe how users use your software. There is no other way.

When designing, wouldn’t it be more reasonable if decisions could be made based on how users actually use your software? Whether you are observing users in a “low-fidelity usability test” or collecting user behavior data and observing users invisibly, the purpose is the same: Don’t ask, observe.

Is More Features Better?

Software relies on new features to drive sales, but over time, those added features are precisely the culprits that make the software worse. That subtle “feature creep” that is slowly breeding – it will destroy people’s favorite software.

A bad trend is: software companies set the priority of fixing bugs in existing software relatively low, while regarding the development of new features for the next version as particularly important. The result is that the quality of the software goes from bad to worse. (Like Flyme and MIUI).

Perhaps we shouldn’t blindly measure software as a pile of features – People always have a “capacity” limit, just like at a buffet, can you eat all that food? We should be result-oriented, measuring the productivity or effectiveness of software in helping us complete tasks.

Living Things Will Do As They Please

The author believes that social engineering is at best an inexact science, even in the cyberspace prototype. Someone once said, “In the most carefully prepared experiment,” even if conditions are strictly controlled, living things will do as they please.

When building social software, people are the root of all problems, but solving problems ultimately depends on those people.

For a Little Ribbon

The author summarized his work at Stack Exchange: What I do, what I am best at, and what I love most and more than anything else in the world, is designing large massive multiplayer games for people who like to write a few paragraphs to each other. I guide their obsession to something positive; they can learn from it and create some reusable beautiful works for the whole world — this is still what I desire, because I still retain a steady stream of obsession.

The author proposed “10 Terrible Ideas”:

Fundamentally lower the barrier to participation.
Trust users.
Life is the world’s largest massive multiplayer online role-playing game.
Bad things always happen.
Preference over money.
Rules can be fun and social.
All modern websites are designed like games.
Thoughtful game design fosters sustainable communities.
The community’s point of view is not necessarily right.
Some mediation is needed.

If you want to learn something online, you must design your software well, guide people’s innate social group impulses, and refocus them on valuable things.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

The Programmer's Apprenticeship - 04: Reflections on Testing

2018-09-27T00:50:32.000Z

This is the fourth post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

Unit Testing Is Necessary

The real value of unit testing is that it forces you to stop and think about testing. Most developers don’t test! They just input some numbers at random, click a few buttons, and if no unhandled exceptions are found during this process, they feel the code is good enough to be delivered to the testing team.

Unit testing forces you to think about a series of difficult but unavoidable questions for the code you just wrote:

How should I test this code?
What kind of tests should I perform?
What is the normal situation?
What are the possible exceptions?
How many external dependencies do I have?
What system failures might I encounter?

Sometimes It’s a Hardware Problem

In this section, the author mainly gave an example they actually encountered, a bug caused by hardware. Investigating directly was extremely difficult, but if the right tools were used, it would be twice the result with half the effort.

Although software is unreliable, we can’t always point the finger at software. Sometimes, what you are facing is indeed a hardware problem.

Exception-Driven Development

As a developer, you shouldn’t let users point out errors. You should be more familiar with your system than your users. So you need to establish an exception and error reporting mechanism. You need to focus on handling all errors in one place. This place is something all developers in your team are very familiar with and come into contact with every day. For example, Stack Overflow uses ELMAH.

One thought on “Test-Driven Development” is the return on time investment: If you fix a bug that real users will never encounter, what is the value of your fix?

The author suggests everyone use “Exception-Driven Development”:

Release your software and let as many users as possible use it.
Then focus on studying the error logs they generate, use those exception logs to find the root cause of the problem, and focus on the problematic areas in your code.
Re-architect and refactor the code to eliminate the 3 most serious problems.
Iterate quickly, deploy, and repeat.

This data-driven feedback mechanism is very effective. After a few iterations, your program will be very stable and solid as a rock.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

The Programmer's Apprenticeship - 03: Web Design Principles

2018-09-26T07:39:25.000Z

This is the third post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

Criteria for Judging Websites

When the author was a judge for websites, he only had 30 seconds for each participating website. Regarding this: “Judging in 30 seconds is completely unfair, but it accurately reflects the situation in the real world.”

The author offered some suggestions to the contestants. Your website homepage needs to give people a “wow” feeling at first sight:

Loading speed must be fast, especially in the mobile Internet era. If it exceeds 1s, users will lose patience.
What on earth is this? Don’t leave incoming users in a fog. Let users know what this webpage is for as soon as they enter.
Show me an example.
Clearly tell me what to do, and clear away obstacles.
Embrace your audience, even if it means excluding other audiences.

In any Web application, the basic sketch of the homepage design is the first thing you should do, because it is the crucial initial design draft and your vision statement.

Pursue Simplicity

Pursuing simplicity lies more in carrying simple through to the end. Comparing the Yahoo homepage and Google homepage over the years, Google has achieved very restrained simplicity on the homepage, while Yahoo’s homepage has become increasingly complex with more and more information. Looking at it now, this is simply a “disaster” for portal websites.

Google’s simplicity puts complex things behind the scenes, instead of dumping them all on the user.

Will Apps Replace Websites?

We should start with simple design and scale up proportionately when necessary, rather than making things complicated from the start and then being forced to shrink. This is similar to the current Mobile-First design philosophy.

Why are apps better than websites?

Faster running speed
Use simple native UI controls
Better use of screen space
More suitable for mobile environments, even offline situations

Why are websites better than apps?

Websites can run on any device’s browser
Websites do not need installation
Websites do not need manual upgrades
Websites provide a unified user experience

From the comparison above, essentially each has its pros and cons. However, looking at subsequent developments, webpages and Apps will become closer and closer. Their development languages and running environments are becoming more consistent. Various cross-platform frameworks make the development of Apps and webpages no longer hugely different. With the popularity of mobile Internet, any App and webpage will be developed from a mobile-first perspective.

The boundary between webpages and Apps will be very blurred, and finally unified.

Remember Not to Stick to Conventions

We need to adopt the “right” way of doing things, not the “standard” way:

Fully understand the current specification and the reasons for its formation (Know what and also know why).
Deviation from this specification requires justification.
Collect user usage data during the experiment (A/B Test).
Make decisions based on data.

Doing Android system optimization is best done following the steps above: first understand the code logic, then understand why the code is written this way, then think about how to optimize. During this period, you need to find bottlenecks, make changes, get user data, and compare user data to choose the optimal solution.

Weird Single-Button Design

The iPhone’s single Home button setting has always been controversial because it makes the “back” operation more complicated. It’s okay on machines with smaller screens where you can use gestures, but on large-screen machines, backing up to the previous page is very inconvenient, and you have to use another hand to operate.

Usability Is Not Just Highbrow Art

If no one in your project cares about usability, then remember that the project is doomed to fail.

Usability testing is one of the most effective measures people can take to improve a website.
Since most organizations have the financial resources to hire professionals to engage in routine testing work, everyone should learn to do usability testing themselves.

The author recommends a book: Web Usability involves Eye Tracking (presumably referring to something like Eye Tracking Web Usability). Those interested can buy a copy to read.

The Other Side of Fitts’s Law

Fitts’s Law: The larger an object is and the closer it is to the cursor, the easier it is to click.

The author summarized the core idea of an article “Visualizing Fitts’s Law”:

Place commonly used UI elements at the edge of the screen, because the cursor automatically stops at the edge of the screen, so those UI elements will be easier to click.
Make the clickable area as large as possible. The larger the target, the easier it is to click.

Similarly, if there are necessary buttons that you do not want users to click, then making them smaller is never wrong. Make infrequently used or dangerous UI elements difficult to click.

Usability and Learnability

Website writing should adopt the “inverted pyramid” style: Tell the reader the conclusion at the beginning of the article, then write the most important supporting information, and finally introduce the relevant background.

Undoubtedly, you should try to put the most important information at the top, whether you are making a webpage, writing a program, writing an email, or making a resume, etc.

In addition, the author recommended a book UI Design Guidelines for Programmers (possibly User Interface Design for Programmers by Joel Spolsky). Those interested can take a look.

Just One More

If you want to add another UI element, please be sure that the UI element you add is not the last straw that breaks the camel’s back.

Dare to Say No

Innovation is not about accepting everything, but about saying no to everything except key features.

User Interface is Hard

This primarily talks about how when programmers create user interfaces, they are often rough and not user-friendly. However, from current developments, user interface design is no longer that difficult, and various beautiful interface frameworks can be applied very easily.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

The Programmer's Apprenticeship - 02: The Way of Programming

2018-09-20T06:09:01.000Z

This is the second post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

Remember Not to Be One-Track Minded

Excellent programmers are good at programming. The way to become a more excellent programmer is to put aside programming. You must cultivate enthusiasm for everything surrounding programming.

Bill Gates mentioned in an interview in 2005: “The essence of work is not working behind closed doors. The most scarce talents are those who have super comprehension of engineering technology, can establish good relationships with core developers, and can act as a bridge between customers, marketing, etc.”

The wider your interests, the more competent you will be in your job.

The Broken Windows Theory

The Broken Windows Theory: If a window in a building is broken and left unrepaired, other windows in the building will soon be broken. A broken window that has not been repaired for a long time sends a signal that “no one cares,” which makes people feel that even if they break more windows, they will not pay any price.

From a programming perspective, the broken windows theory also exists, and you need to take timely measures: do not let “broken windows” (poor design, wrong decisions, or terrible code) go unchecked. Once discovered, they must be repaired as soon as possible. If there isn’t enough time, isolate them first. You can comment out these unpleasant codes, or display a “not yet implemented” message, or use fake data instead.

Programming pays great attention to detail! If you cannot master these details, you will have a feeling of losing control, and it is only a matter of time before your project goes out of control. Perhaps we should be cautious.

Love It or Leave It

The most outstanding programmers I know have a lifelong passion for what they do. They will never switch to other things because of a slight economic fluctuation.

For programming: Love it or leave it.

The Beauty of Simplicity

In the field of programming and development, it is easy for people to fall into the mindset of “newer is better” and forget that “ideas are often more important than code.”

The evolution of Forth points out the guiding principles Charles had when inventing and implementing the Forth language:

Stay firm
Don’t speculate
Do it yourself

Charles believes: Simplicity must be enforced, not just as an optional goal. In reality, many developers find it difficult to keep programs simple because they don’t say “no” when they need to make tough decisions. Instead, promising everything and compromising everywhere is much easier.

Many people look down on OPPO (phones), but OPPO’s system maintains the beauty of simplicity in design, so the system feels very light and comfortable to use. Even after long-term use, there are rarely stutters. Its performance on low-end devices is also much better than competing products. This also fits OPPO’s development philosophy: prioritize basic experience (fast, power-saving, stable).

Be Happy to Delete Code

If there is a piece of code you no longer need, please truly delete it instead of leaving it idle. The main reason is to remove noise and uncertainty. One of the most difficult things developers face is the noise or uncertainty of the code flow, because this will affect their future work efficiency. Useless code will trigger other developers to think:

Why was this code written like this before?
Why is this new code better?
Will we reuse the old code in the future?
What are our criteria for judgment?

In the current era where Git is rampant, you should not keep useless old code. If you want to see the previous writing, it’s just a few lines of Git commands. If you can’t have a good reason not to delete it, then deleting it is reasonable.

Are You Cut Out to Be a Programmer?

This section mentions that not everyone is suitable for programming. In fact, most people cannot learn programming. The deciding factor is their attitude towards meaningless things.

Formal logical proof, expressed in a formal system called a programming language, yields results by performing specific calculations. This is actually completely meaningless. To write a computer program, you must compromise and give the program some meaning, but no matter what you want the program to do, the computer will run according to these meaningless rules and get some meaningless results. In tests, those with stable mental models showed innate acceptance in this regard. They all have the ability to see the mathematical calculation problems behind the rules, and follow those rules no matter what. On the other hand, those without stable mental models always can’t find a clue.

Do You Follow the Rules?

I feel the title of this section isn’t great. “Xun Gui Dao Ju” (Follow the rules): Originally meant sticking to the rules and not daring to violate them. Now it also refers to sticking to old standards and not daring to make any changes. But the text talks about whether you follow basic rules.

This section can be interpreted as: Many things, including software development, have certain routines or basic rules. These routines or basic rules have been verified by everyone. When you want to do something, it is best to follow these routines or basic rules. For example, the author lists 12 steps to writing better code from a blog post:

Do you use a source control system?
Can you complete a software build in one step?
Do you release a build every day?
Do you have a bug tracking database?
Do you fix bugs before writing new code?
Do you have an up-to-date software development schedule?
Do you have product specification documents?
Do programmers have a quiet working environment?
Are you using the best commercial tools?
Do you have testers?
During the interview process, do you ask candidates to write code?
Do you do usability testing?

Although the above are all questions, the answers should be yes.

Core’s Law: Stick to One Goal

Core’s Law: Stick to one goal. This law is reflected in several core principles of modern human settlement development:

Don’t Repeat Yourself (DRY)
Once And Only Once (OAOO)
Single Point Of Truth (SPOT)

Core’s Law also tells us to consciously choose what your code doesn’t do.

The Most Awesome Coding Routine

Contrary to what you believe, simply burying your head in work every day is not true exercise – attending meetings does not exercise your interpersonal skills; replying to emails does not improve your typing skills. You must set aside time regularly for concentrated exercise so that you can do things better.

The above theory is also emphasized in two books I highly recommend, Deep Work and Peak: Secrets from the New Science of Expertise (if you haven’t read these two books, I suggest you take a look): Ten thousand hours is not repeating one hour ten thousand times, but putting your heart and soul into learning, thinking deeply, and summarizing every hour.

In addition, the author also mentioned “study hard”: constantly challenge things beyond your own ability. The main value of learning and training lies in discovering weaknesses and improving them specifically. “Studying hard” means often dealing with problems that are just at the limit of your ability, that is, things that have a high probability of failure for you. If you don’t experience some failure, you may not grow. You must constantly challenge yourself and exceed your limits.

The author listed some routines (those that can truly be implemented. Some are long, but I still copied all the items because I want to implement them myself):

Write your own resume. List all your relevant skills, and then mark those that will still be useful in 100 years. Score each skill, out of 10.
List the programmers you admire. Try to include those you work with, because you will gain some skills from them at work. Record 1 or 2 shining points about them, which are the areas you hope to improve.
Check the “Computer Science” section on Wikipedia, find the “Pioneers in Logic and Computing” category, pick a person from this list, read about their deeds, and open any links you are interested in while reading.
Spend 20 minutes reading other people’s code. Reading excellent code and reading terrible code are both beneficial. Read both, switching in turns. If you can’t feel the difference between them, you can ask a programmer you respect to show you what excellent code is and what terrible code is. Show the code you have read to others and ask for their opinions.
List your 10 favorite programming tools—those you think you use the most and can’t live without. Randomly pick one tool and spend an hour reading its documentation. In this hour, try hard to learn a new function of this tool that you were not aware of, or discover a new way of using it.
Think about it, what are you best at besides programming? Think again, how did you become so skilled and professional through exercise? What inspiration does this have for your programming work? (How to apply these experiences to programming?)
Take out a stack of resumes and stay in the same room with a group of interviewers for an hour. Ensure that each resume is read by at least 3 interviewers and given a score of 1 to 3. Discuss resumes where judges’ judgments differ widely.
Participate in a phone interview. Write down your feedback afterwards, throw out your views, and then chat with the person hosting the phone interview to see if you reached a consistent conclusion.
Conduct a technical interview, and the interviewee should be an expert in a field you are not very familiar with. Ask them to assume the audience knows nothing about that field, so ask them to start from the basics. Try hard to understand what they say, and ask some questions if necessary.
Have the opportunity to participate in other people’s technical interviews. During the process, simply listen carefully and learn seriously. While the candidate tries to solve technical problems, try to solve these problems in your own mind.
Find someone who can exchange practical problems with you. Every other week, exchange programming problems with each other. Spend 10 to 15 minutes trying to solve these problems, and then spend 10 to 15 minutes discussing (whether solved or not).
When you hear any interview question that you cannot solve immediately, hurry back to your seat and email the question to yourself as a reminder for the future. Find some time during that week to solve it in your favorite programming language.

In addition, the author also mentioned some suggestions listed by Peter Norvig:

Communication with other programmers. Read other people’s code. This is more important than any book or training course.
Write programs! The best way to learn is to learn by doing.
Take programming courses during undergraduate or graduate studies.
Find some projects to do, and cooperate with other programmers to form a team. During the project, learn to distinguish the best programmers and the worst programmers.
Work with other programmers on projects, understand how to maintain code not written by you, and learn how to write code that is easy for others to maintain.
Learn many different programming languages, especially those with different worldviews and programming models from the languages you are currently familiar with.
Understand the impact of hardware on software. Know how long it takes for your computer to execute an instruction, how long it takes to fetch a word from memory (with or without cache), how long it takes to transmit data over Ethernet (or the Internet), how long it takes to read continuous data from disk or jump to another location on disk, etc.

Finally, the author also expounded his own programming routine:

Write a blog. I started the CodingHorror.com blog in early 2004 as a form of my own effort to learn. It was humble at first, and later became one of the most important things I have done in my career. So, you should also write a blog. The people who finally “become famous” are often those who can write and communicate effectively. Their voices are the loudest; they are setting the rules of the game and leading the trends of the world.
Actively participate in famous open source projects. All the high-flown talk sounds good, but are you a brag or a doer? Don’t just talk, do it. This is very important because people will measure you by your actions, not your words. Try hard to leave something tangible and useful in front of the public, so you can say, “I contributed to that project.”

When you can write wonderful code and explain that code to the world with wonderful words, then I will feel that you have mastered the most awesome coding routine!

Being Alone is Shameful

I think the harm of programming alone expounded in “Creating My Own Personal Hell” cited by the author in this section is worth pondering:

Some people declare that “working alone” provides an excellent opportunity to establish their own workflow. However, in my experience, there is no process when the team has only one person. Nothing prevents you from being overwhelmed by a flood of work. When your code is too eager for success, no one corrects your mistakes. No one checks your code. No one guarantees that your code can be submitted on time, tagged well, and subjected to routine unit testing. No one guarantees that you follow a certain coding standard. No one urges you to fix defects in the code in time. No one checks whether you have marked an existing problem as “unable to reproduce”. No one reviews your estimates, or drags you back when you neglect your duty.

No one takes over your work when you are sick or on a business trip. No one helps you when your work is heavy. When you are deeply trapped in harassment calls, boring meetings, and trivial tasks thrown at the last minute (but need to be solved immediately), no one can give you a hand. No one suddenly has a bright idea to help you out of trouble. No one cooperates with you on design, architecture, or technology. You work in a vacuum; in a vacuum, no one can hear your desperate screams.

If you read this content, please take it as a warning. If a company only recruits you as the only developer, please think twice before agreeing. That is simply another kind of hell. If there is a chance, please choose those positions where you can work with other developers, so that you can at least get guidance in the process of working with others, which helps you develop your own skills and keep up with the times in technology.

If you can’t show it to others, what’s the point of beautiful coding skills? If you don’t contact other programmers’ different viewpoints, different methods, and different technologies, how can you learn more skills? Who can check your code and tell you that there is a simpler solution to that problem? If you are serious about programming, you should ask to work with partners.

Individual ability is always limited, it determines that you can only go so far in this field. Find some other smart programmers and work with them. Try to keep yourself humble and low-key, and then you will soon discover that software development is actually a social activity—its social nature is much greater than most people imagine. You can learn a lot from those introverted companions.

Just as we often say, one person can walk faster, but a group can walk further.

Do You Want a Programming Partner?

Under the influence of a healthy software engineering culture, team members improve their work quality and productivity through pair programming. They understand that the time they spend checking colleagues’ work will always be rewarded when others check their own deliverables in turn.

The author even gave data to illustrate the role of Code Review (a bit subversive to my cognition):

In terms of average defect discovery rate, unit testing can only reach 25%, functional testing can reach 35%, and integration testing is only 45%. In contrast, the average efficacy of design and code review can reach 55% and 60%.

There is a lot of fun in programming, one of which is: “You don’t have to do it alone.” So, who is your programming partner?

Software Apprenticeship

Many companies will assign a mentor to new employees. Through this 1-on-1 guidance, new employees can integrate into the company as soon as possible, which is similar to the apprenticeship system.

Studying theory at night and programming during the day — this combination is particularly effective.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”

Blogger Intro: Includes personal WeChat and WeChat group links.
Blog Content Navigation: A guide for my blog content.
Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
Android Performance Optimization Knowledge Planet: Welcome to join and thank you for your support~

One person can walk faster, a group can walk further

Android Performance

Android Perfetto Series 10: Binder Scheduling and Lock Contention

Table of Contents

Perfetto Series Catalog

Binder Basics

Case from App Developer’s Perspective

Perfetto Setup and Data Sources

Data Sources and Track Overview

Recommended Trace Config

Configuration Item Description

Quick Start: 3 Steps to Capture and View Binder Trace

Other Binder Analysis Tools

am trace-ipc: Java Layer Binder Call Tracking

binder-trace: Real-time Binder Message Parsing

Binder Analysis Workflow

Step 1: Identify Transaction Latency

Step 2: Evaluate Thread Pool and Oneway Queue

SystemServer’s Binder Thread Pool Scale

Binder Thread Count, Buffer, and “Binder Exhaustion”

Step 3: Investigate Lock Contention

SQL for Java Monitor Contention in system_server (Optional)

Case Study: Window Management Delay

Case Study: Binder Thread Pool Saturation

Platform Features and Best Practices

Summary

References

Attachments

About the Author & Blog

Android Perfetto Series 9: CPU Information Interpretation

Table of Contents

Perfetto Series Articles

CPU Information Overview in Perfetto

Trace Config Required for Capturing CPU Information

CPU Core Architecture: big.LITTLE

CPU Scheduling

Thread State Deep Dive

Running (Green)

R (Runnable)

S (Sleep / Interruptible Sleep)

D (Uninterruptible Sleep)

Wakeup Relationship Analysis

Scheduling Wakeup and Latency Analysis

Differences Between sched_waking and sched_wakeup and Non-strict Work-conserving

User Mode and Kernel Mode: sys_* Slices Locate Empty Flame Graphs

CPU Time and Wall Time

CPU Frequency Deep Dive

Core Factors Affecting CPU Frequency

Frequency Data Collection and Platform Differences

big.LITTLE: Same Frequency Doesn’t Equal Same Performance or Power Consumption

P-States and governor

Linux Kernel Scheduling Strategy: Core Selection and Migration

Core Selection Logic (Task Placement)

Core Migration Logic (Task Migration)

Practice and SQL

Using SQL for Quantitative Analysis

1. Calculate Total CPU Time for Each Process

2. Analyze Single Thread’s Time State Distribution

3. Find Threads with Highest CPU Consumption in Specific Time Period

4. View Thread’s Running Time Distribution on Each CPU Core

5. Calculate CPU Utilization for Each Process

Summary

About Me && Blog

Android Perfetto Series 8: Understanding Vsync Mechanism and Performance Analysis

Table of Contents

Series Catalog

What is Vsync

What Problems Does Vsync Solve?

Basic Working Principles of Vsync in Android

Layered Architecture of Vsync Signals

Observing Vsync in Perfetto

How Android App Frames Work Based on Vsync

Process Overview (In Order)

When Does App Request Vsync Signals

Complete Process of App Requesting Vsync

How Main Thread Listens for Vsync Signals

Several Remaining Questions

Technical Implementation of Vsync Offset / WorkDuration

Actual Optimization Effects

Complete Code Flow of Vsync Signals

Key Code Paths Aligned with AOSP main (Condensed Excerpts)

SQL for Java Monitor Contention in `system_server` (Optional)