Diagnostics · 2 February 2026
When battery traces contradict frame time
A scroll can look buttery and still empty a cell before lunch. Frame time tells you whether the UI kept its budget. Battery traces tell you what the radio, CPU, and misplaced alarms were doing while the user thought they were “just browsing.” Those stories are allowed to disagree. The mistake is picking a favourite metric and calling the other one noise.
In Battery Drain Diagnostics we pair a historian dump with a radio capture from the same session. Learners must write two sentences: one that the frame histogram supports, one that only the battery trace supports. If the sentences are the same, the homework is incomplete. We have seen teams celebrate a jank fix that moved work onto a wakelock that kept the modem hot.
Mid-range chipsets matter here more than flagships. A device that throttles early will show frame pain; a device with a generous thermal envelope may only show battery pain. Our wall is biased toward what Thai retail actually sells, which is why Krit’s reservation on the reviews page still stings — we still do not stock every SKU a cohort wishes for.
Attribution language we accept in class: “this wake is radio retry under the Asok fixture,” or “this wake is a periodic sync that ignores app standby.” Attribution language we reject: “the OS is just like that.” If you cannot point at a thread or an alarm, you do not publish the cause.
Frame Timing for Product Teams covers the histogram side without requiring a profiler career. Engineers who need both ledgers usually sit Bench Lead and treat this note as pre-reading for module 04.