Building and Optimizing a First‑Screen Performance Monitoring System for Android Apps (JD Mall Case Study)

With the rapid growth of mobile internet, users increasingly demand fast app performance, especially quick page opening; JD Mall found that 32% of user feedback related to performance and 68% of those complaints were about sluggish page loads.

The article defines first‑screen latency as the time from a user’s click or page switch to the completion of the first screen rendering.

To address the limitations of existing SDKs, JD Mall built a custom "Hurricane" monitoring system that can capture real user experience, multi‑tab switches, and business‑specific metrics, consisting of a strategy configuration module, a data collection module, and an aggregation analysis platform.

The strategy configuration module serves as the central console for defining which pages to monitor, user black/white lists, and gray‑release controls.

The data collection module hooks into Activity and Fragment lifecycle events using AOP; for example:

private static final String POINTCUT_PERF_INIT = "execution(* androidx.appcompat.app.AppCompatActivity+.onCreate(..))";
@Pointcut(POINTCUT_PERF_INIT)
public void onActivityOnCreate() {}
@Before("onActivityOnCreate()")
public void beforeActivityOnCreate(JoinPoint point){ /* record point 1 */ }
@After("onActivityOnCreate()")
public void afterActivityOnCreate(JoinPoint point){ /* record point 2 */ }

If the app moves to the background, a special observer records the last onPause timestamp:

ProcessLifecycleOwner.get().getLifecycle().addObserver(new LifecycleObserver(){
    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    public void onAppGoBackground(){
        Monitor.goBackground();
    }
});

Fragment page switches use the onAttached callback as the start point, with precautions for pre‑loading scenarios.

Network requests are also hooked via AOP or manual instrumentation, guided by a server‑side JSON configuration that lists which interfaces belong to a page’s first‑screen load:

{
  "com.demo.MainActivity": {"request": "home/config", "type": "activity"},
  "com.demo.CouponFragment": {"request": "coupon/list", "type": "fragment"}
}

Rendering completion is marked by explicit SDK calls (e.g., Monitor.onRender(context); ) to handle cases where a page’s cache or skeleton view finishes rendering.

Custom metrics are collected as (page, key, value) triples, where the page is the Activity/Fragment hash, key is a predefined identifier (key1‑key50), and value is the measured duration.

Gray‑control is implemented through three layers of switches—global, blacklist/whitelist, and per‑page—allowing staged roll‑outs without requiring client releases.

Data analysis aggregates four dimensions: lifecycle timings (onCreate, onStart, onResume), network request latency and parallelism, rendering latency, and custom business metrics.

Based on the collected data, JD Mall performed several optimizations:

Plugin pre‑loading reduced cold‑start overhead by 150 ms on average.

Network pre‑loading and caching minimized round‑trip counts.

Intelligent request parallelism lowered total first‑screen network time.

UI component loading was accelerated by replacing XML inflation with dynamic view creation, e.g.:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView/>
    <ImageView/>
    <Button/>
    <View/>
</LinearLayout>

Dynamic creation reduced inflation time from 7 ms to 2 ms:

LinearLayout linearLayout = new LinearLayout(this);
linearLayout.addView(new TextView(this));
linearLayout.addView(new ImageView(this));
linearLayout.addView(new Button(this));
linearLayout.addView(new View(this));

Further rendering optimizations included using ConstraintLayout, ViewStub, reducing over‑draw, and enabling hardware acceleration, which shifted rendering work to a dedicated RenderThread.

After a quarter of monitoring‑driven tuning, JD Mall achieved more than 30 % improvement in first‑screen rendering speed and a >20 % reduction in users abandoning pages due to slowness.

The article concludes that app performance optimization is an ongoing effort and invites readers to discuss additional techniques.