Android Performance monitoring [Part 2]
In the last part, we talked about Memory monitor and how to use them, and this part is going to be focused on CPU monitors and how to optimise CPU usage so apps run smoother and without any hiccups. we’ll start from some very basic tools and then proceed further to more advance tools.
Systrace
While developing your application, you should check that user interactions are buttery smooth, running at a consistent 60 frames per second. If something goes wrong, and a frame gets dropped, the first step in fixing the problem is understanding what the system is doing.
The Systrace tool allows you to collect and inspect timing information across an entire Android device, which is called a trace. It shows where time and CPU cycles are being spent, displaying what each thread and process is doing at any given time. It also inpects the captured tracing information to highlight problems that it observes, from list item recycling to rendering content, and provide recommendations about how to fix them. for more details on how to capture systrace, refer Analyzing UI Performance with Systrace.
Hierarchy Viewer
This tool is used to optimise layouts. Layout is captured by hierarchy viewer and it generates a view tree with 3 attributes for each view with time taken, which are:
- Measure
- Layout
- Draw
all attributes are color coded based on performance , green ones are fine while red ones need to be optimized. Layouts should be as shallow as possible, and not nested. More info on how to capture a layout using hierarchy viewer and interpretation are available in Android Docs.
Method Tracer
It lets you view the call stack and timing information for your app. This information can help you optimize and debug your app.
It shows which method took how much CPU time during execution and on which thread. Which can be used to move heavy task off UI thread to make it jank free.
Please go through Performing a Method Trace in the CPU Monitor for detailed instructions on how capture a Method Trace.
So we have captured the method trace, now we observe it and try to optimize our code, we are still using the same app to be profiled which we used in part 1. i.e Popular Movies. The chart can be zoomed in using scroll buttons and dragged to pan around. There is also a search button on top right where we can search specific methods in the selected thread.
by digging around a bit I found that all the database calls were running in main thread. In the ideal case, this is a huge flaw and should never happen.
here, we can see that a single Database call is on UI thread which is taking 26ms wallclock time and to achieve 60 FPS in any app, we get 16ms to draw any frame, in this case 2 frames will be dropped which is a large performance hit, ideally this should have been in background. Thanks to Rxjava, we moved the call in background thread in a couple of seconds and hence fixed the UI lag.
e.g:
Method trace:
And we can see by thread its not executing in UI thread anymore and has been moved to background thread, we achieved 60 FPS again.
The main advantage of monitors is to show information without making changes to code, which makes code neat and clean by keeping only relevant stuff.
These deductions are based on my specific app and may vary, the main purpose of this article is to enable devs to monitor and improve their code based on the scenario, how you fix a problem is up to you.
Observing the output of these tools is not very easy but practice make a man perfect, you’ll get the hang of it if you do it quite often, made another good observation? be sure to let me know in the comments down below.
Thanks for reading, Next part will include CPU performance monitor and tools. Follow me and Mindorks so you’ll get notified when I write next part.
Check out all the Mindorks best articles here.
Thanks for reading this article. Be sure to click ❤ below to recommend this article if you found it helpful. It would let others get this article in search and spread the knowledge.
