Design and Implementation of a Non‑Intrusive UI Thread Lag Monitoring SDK for Android

1. Overall Overview

1.1 Background

The Platform Technology Group builds the Avatar Open Platform, providing one‑stop technical solutions for business development and exporting JD Mobile's accumulated capabilities across JD systems. Performance monitoring, especially UI‑thread lag collection, is a core part of this effort.

Large Android projects often suffer from severe UI lag due to complex business scenarios, rapid version iteration, massive legacy code, and numerous third‑party libraries.

When an app experiences lag, locating the exact problematic code among thousands of lines becomes extremely difficult, leading to a vicious cycle of worsening performance.

1.2 Lag Factors

Common causes of UI lag include:

Time‑consuming operations on the UI thread

Complex or unreasonable layouts and over‑draw

Abnormal memory usage causing frequent GC

Incorrect asynchronous implementations

The primary cause is time‑consuming operations on the UI thread. The goal is to build a monitoring system that can capture user‑side stalls, upload data, aggregate results, and automatically generate work orders for the responsible module owners.

1.3 Desired Effects

Non‑intrusive: no scattered instrumentation that harms code elegance

Precise定位: pinpoint the exact line of code

No impact on app performance

1.4 System Architecture

The system consists of four parts:

Main‑thread lag collection SDK

Performance data reporting SDK

Server‑side data aggregation

Automatic work‑order generation and dispatch

Architecture diagram:

2. Main‑Thread Lag Collection SDK Implementation

2.1 Monitoring Principle

1. The main thread has a single Looper.

Looper.java defines a static sMainLooper ; regardless of how many Handlers exist, there is only one Looper, and all code on the main thread eventually returns to loop() .

Key snippet of Looper.loop() :

public static void loop() {
    for (;;) {
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target);
        }
        msg.target.dispatchMessage(msg);
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target);
        }
    }
    ...
}

The mLogging printer is invoked before and after each message dispatch; a long‑running operation in dispatchMessage causes UI lag.

2. Replace the main‑thread Printer .

Google provides an interface for this; even without it, reflection can replace the printer.

Replacement code:

Looper.getMainLooper().setMessageLogging(printer);

3. Lag condition: endTime - startTime > threshold .

Because the printer is called in pairs, we can measure the execution time of each message and flag it as a stall when it exceeds the configured threshold.

4. Sampling.

A separate sampling thread periodically captures the main‑thread stack, CPU usage, etc. It sleeps briefly before each sample to avoid interfering with short‑lived messages and to minimize CPU contention.

Sampling illustration:

2.2 Core Flow Diagram

Sampling thread: periodically creates samples, uses a lightweight object pool (implemented with a linked list) to limit temporary object creation.

Main thread: when a lag is detected, extracts stack information from the sampling pool for the time window T1‑T2 and stores it in a cache pool.

Cache pool: a memory cache with a timer that checks upload conditions at fixed intervals and triggers data reporting when appropriate.

2.3 Data Processing

1. Data is classified into two categories:

Confirmed lag : consecutive samples have identical stack traces, indicating the function has not returned within the interval.

Suspected lag : stack traces differ, requiring further analysis.

2. Stack pre‑processing:

Initial aggregation: identical consecutive stacks are merged with a count field, reducing duplicate storage and network traffic.

Key lines: filter stacks for frames containing JD package names (e.g., jd. or jingdong. ) and mark them as key lines for aggregation.

3. Collection strategy and presentation:

Configurable dimensions: app version, build number, Android OS version, rollout percentage, network type (2G/3G/4G/Wi‑Fi), real‑time upload flag, etc.

Precise targeting: enable the feature for specific users (e.g., users who reported frequent stalls).

Visualization: aggregated results are displayed in dashboards (see image below).

2.4 Issues Encountered During Development

1. Printer replacement conflicts: other modules (e.g., WebView) may overwrite the main‑thread printer via setWebContentsDebuggingEnabled() . The solution is to provide a hidden “backdoor” that only enables the WebView printer when H5 developers explicitly need it.

2. Obtaining the current printer: Looper does not expose a getter. Reflection is used to retrieve the private mLogging field:

/**
 * Reflectively obtain the main‑thread Printer object
 */
private static Printer getMainPrinter() {
    try {
        Field privatePrinterField = Looper.class.getDeclaredField("mLogging");
        privatePrinterField.setAccessible(true);
        Looper mainLooper = Looper.getMainLooper();
        Printer oldPrinter = (Printer) privatePrinterField.get(mainLooper); // obtain private field value
        if (oldPrinter != null) {
            return oldPrinter;
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

3. Conclusion

The lag‑collection component is a vital part of JD Mobile's APM system. It now receives millions of stall records daily, enabling precise user‑level lag localization and root‑cause analysis. Combined with big‑data aggregation, it provides a clear view of lag trends across app versions.

However, data collection is only the first step; QA, testing, and development teams must collaborate to optimize the code and truly reduce the overall lag rate.

Source: JD Mobile Technology Team