There is enough documentation as to how to collect the trace data, load it in TraceView etc. This post is just about the analysis of the collected trace data for CPU based operations. The data in this case is for AOSP browser running Google home page on an API 19 based emulator. The web page for most part was static except for the animating google doodle.
TraceView's snapshot over a period of 45 seconds looked like this. Clearly the main thread is the most active thread and the top level accounts for 38 seconds of CPU usage.
Clicking on the top level expands the functions called from here. The handler in this case accounts for 17 seconds worth of operation.
TraceView's snapshot over a period of 45 seconds looked like this. Clearly the main thread is the most active thread and the top level accounts for 38 seconds of CPU usage.
Clicking on the top level expands the functions called from here. The handler in this case accounts for 17 seconds worth of operation.
Clicking on the handler expands the next set of functions in the stack frame.
The handler is basically processing a callback for most of the time,
And its basically a callback corresponding to Choregrapher's FrameDisplayEventReceiver. Clicking further exposes few more stack frames with their time info. In this case, its due to a UI invalidations caused by the animation of the Google doodle.
No comments:
Post a Comment