Testing Power Consumption of Push SDK on Mobile Devices

Introduction: A product team reported excessive power and traffic consumption when using our push SDK, prompting an investigation into the root causes. This guide outlines the preparation, testing process, and analysis needed to evaluate the SDK's power usage.

Separating SDK Components: The push SDK includes our own component (A) and third‑party SDKs (B, C, D). Tests must isolate each SDK to identify which one contributes most to power consumption.

Operations That Cause Power Consumption: When running the demo, three main actions generate power usage: (1) periodic heartbeat communication with the push server, (2) real‑time data upload to qdas, and (3) receipt of push messages from the server.

How to Measure SDK Power Consumption: The example focuses on measuring network traffic (power can be obtained directly via ADB). The steps are: (1) obtain the app's process ID (procID), (2) retrieve the UID from the process ID, and (3) query the device's traffic statistics for that UID to get upstream (tcp_snd) and downstream (tcp_rcv) bytes.

Script Implementation: A script uses ADB commands to automate the above steps: it extracts the PID, maps it to UID, and then reads the corresponding traffic files to calculate total data usage. The resulting values are in bytes and should be converted to KB or MB for readability.

Testing Focus: The key metrics are: (1) traffic generated during heartbeat intervals, (2) changes in upstream and downstream traffic when push messages are received, (3) verification that upstream + downstream equals total app traffic, and (4) proper unit conversion.

Issues Encountered: Some devices block access to UID‑specific traffic directories, requiring testing on compatible phones (e.g., 360 phones). Heartbeat traffic is minimal (often only a few bytes), easy to overlook. Push messages sometimes show higher upstream than downstream because the SDK reports data to qdas, adding to upstream traffic. After killing the app or reinstalling, traffic appears unusually high because the UID persists and includes historical data.

Solutions: Restart the device before reinstalling to reset the UID, or programmatically subtract historical traffic values during analysis.

Conclusion: The guide summarizes practical knowledge gained from testing push‑related SDKs and invites readers to share their thoughts.