Why Your Android App Is Slow: Uncovering Hidden Network Bottlenecks with RUM

1. Overview of Mobile Network Performance Challenges

In the mobile‑Internet era, network request performance is a key factor for user experience; page load time directly impacts conversion rates, and most user complaints revolve around "slow loading" or "stuttering". Mobile environments differ from web in three ways:

Multiple network types (WiFi, 4G/5G, 3G, 2G) coexist.

Signal strength fluctuates and network switches frequently.

Regional and carrier network quality varies greatly.

Additional device‑level challenges include a wide range of Android brands and OS versions, as well as heterogeneous hardware performance, which together make precise performance analysis difficult.

2. Resource Event Data Model

2.1 Attribute Fields

The Resource event is the core data model for network request monitoring. It follows the HTTP protocol and the W3C Performance Timing API, ensuring consistent data across Web, iOS, Android, and HarmonyOS. The model provides contextual information such as request URL, method, status code, and timestamps.

2.2 Metric Fields

Beyond attributes, the event records fine‑grained performance metrics such as DNS duration, TCP connection time, SSL handshake time, request/response header and body durations, and total request time. These metrics are essential for pinpointing the exact stage that slows down a request.

2.3 Request Timing Stages

A complete HTTPS request consists of the following stages:

connectStart (TCP start)</code><code>↓</code><code>[TCP three‑way handshake]</code><code>↓</code><code>secureConnectStart (SSL start)</code><code>↓</code><code>[SSL/TLS handshake]</code><code>↓</code><code>secureConnectEnd (SSL end)</code><code>↓</code><code>connectEnd (connection established)

2.4 Calculation Rules

The total connection time, pure TCP time, and SSL time are derived from the timestamps:

totalConnectionTime = connectEnd - connectStart</code><code>pureTCPTime = secureConnectStart - connectStart</code><code>sslTime = secureConnectEnd - secureConnectStart

3. Real‑World Case Study

3.1 Background

An Android app received user complaints of “page loads taking more than a second”. Backend logs showed the server processing time was only ~400 ms, leaving a mysterious 800 ms gap. By enabling the RUM Android SDK, detailed timing data was collected.

3.2 Raw Timing Data

{
  "requestHeadersEnd":1560814315115219,
  "responseBodyStart":1560814719308917,
  "requestType":"OkHttp3",
  "connectionAcquired":1560814312934751,
  "connectionReleased":1560814721700948,
  "requestBodyEnd":1560814315850323,
  "responseHeadersEnd":1560814718722250,
  "requestHeadersStart":1560814312975011,
  "responseBodyEnd":1560814719441625,
  "requestBodyStart":1560814315146573,
  "callEnd":1560814721840948,
  "duration":1232825780,
  "callStart":1560813486615845,
  "responseHeadersStart":1560814718314125
}

3.3 Stage‑by‑Stage Analysis

Stage 1 – Connection‑Pool Wait

callStart → connectionAcquired
cost = (1560814312934751 - 1560813486615845) / 1_000_000 = 826.32 ms ⚠️

This accounts for 67 % of the total latency and indicates a long wait for a pooled connection.

Stage 2 – Send Request Headers

requestHeadersStart → requestHeadersEnd
cost = (1560814315115219 - 1560814312975011) / 1_000_000 = 2.14 ms ✅

Stage 3 – Send Request Body

requestBodyStart → requestBodyEnd
cost = (1560814315850323 - 1560814315146573) / 1_000_000 = 0.70 ms ✅

Stage 4 – Server Processing (TTFB)

requestBodyEnd → responseHeadersStart
cost = (1560814718314125 - 1560814315850323) / 1_000_000 = 402.46 ms

Matches the backend log (≈400 ms).

Stage 5 – Receive Response Headers

responseHeadersStart → responseHeadersEnd
cost = (1560814718722250 - 1560814718314125) / 1_000_000 = 0.41 ms ✅

Stage 6 – Receive Response Body

responseBodyStart → responseBodyEnd
cost = (1560814719441625 - 1560814719308917) / 1_000_000 = 0.13 ms ✅

Stage 7 – Release Connection

responseBodyEnd → connectionReleased
cost = (1560814721700948 - 1560814719441625) / 1_000_000 = 2.26 ms ✅

The analysis shows that the dominant bottleneck is the 826 ms wait for a connection from the pool.

4. Diagnosis and Optimization Steps

4.1 Verify Connection‑Pool Configuration

// Inspect current OkHttpClient pool settings
ConnectionPool pool = okHttpClient.connectionPool();
// Default: max 5 idle connections, keep‑alive 5 min

The app was using the default pool (5 idle connections), which proved insufficient for its concurrency level.

4.2 Monitor Concurrent Requests

SELECT COUNT(*) AS concurrent_requests
FROM rum_resource
WHERE timestamp BETWEEN :start AND :end
  AND resource.url LIKE 'https://api.example.com%'
GROUP BY timestamp
ORDER BY concurrent_requests DESC;

Identify periods when many requests target the same host.

4.3 Detect Connection Leaks

// Log active/idle connections at each request
interceptor.addInterceptor(chain -> {
    ConnectionPool pool = chain.connection().connectionPool();
    Log.d("Pool", "Active: " + pool.connectionCount() + ", Idle: " + pool.idleConnectionCount());
    return chain.proceed(chain.request());
});

Ensure every Response is closed:

Response response = client.newCall(request).execute();
try {
    String body = response.body().string();
    // process body
} finally {
    response.close(); // mandatory
}

4.4 Optimize the Pool

Increase idle connections for high‑concurrency apps: maxIdleConnections = 30‑50.

For typical apps: maxIdleConnections = 10‑20.

For low‑traffic apps: keep the default or 5‑10.

Adjust the per‑host request limit if needed:

new OkHttpClient.Builder()
    .dispatcher(new Dispatcher() {{ setMaxRequestsPerHost(10); }})
    .build();

4.5 Other Common Issues

DNS latency – use a custom DNS resolver or Alibaba HttpDNS.

SSL handshake time – enable SSL session reuse or increase keep‑alive.

TTFB – profile server load, database queries, and business logic.

5. Monitoring and Alerting Recommendations

RUM allows custom alerts. Example thresholds (based on RAIL and Web Vitals):

connectionAcquired – wait > 500 ms (P95) → alert.

dns_duration > 300 ms → alert.

ssl_duration > 1000 ms → alert.

first_byte_duration > 2000 ms → alert.

These alerts help catch performance regressions before users notice them.

6. Summary of Benefits

Fine‑grained visibility of DNS, TCP, SSL, and TTFB enables rapid bottleneck identification.

Connection‑pool analysis reveals hidden inefficiencies such as leaks or undersized pools.

Real‑user data across regions, carriers, and network types drives data‑driven optimization.

Clear before‑and‑after metrics validate the impact of configuration changes.

Custom alerting turns passive monitoring into proactive performance management.