Improve Your App’s Performance With Profiler
Day nine of 100 days of code — performance matters
You, after working so hard on the application, don’t want to deliver a memory-intensive choppy app that heats up your user’s phone.
Before Android Studio 3.0, there were some monitoring tools available, along with the traditional logging. But, going through your code logging statements, and using the old tools, was not that helpful for the devs.
In comes the Android Profiler, which came with Android Studio 3.0. Developers can use it to monitor their CPU, memory, battery consumption, along with monitoring the network requests your app is making. And yes, you can still print log statements in the Logcat.
I was always busy learning and experimenting with the latest Android concepts and never got time to dig more into the Profiler. I knew it was there but always procrastinated to learn more about it, even though it’s such an important aspect of Android application development.
You can track the activity, the process that might be the root cause of the performance issues in your app.
Let’s See the Profiler
You need to have Android Studio 3.0 (at least) with the device (emulator works as well) with SDK level 26.
Once you launch your app, click on the Profiler tab on the bottom, which would be near Logcat. You will see a continuous chart like this, which is updated in real-time. It shows the activity running in the foreground on the top.
When you click on any of the graphs, you will see a detailed breakdown.
Running your app more, interacting, opening multiple activities, and doing network requests, you will observe these charts being updated which is really fun to watch.
And, if you are curious to understand and see which functions exactly are consuming more resources, you can even see that.
Click on the chart anywhere to see more details. Move your pointer on it to see a detailed breakdown of resource consumption.
We have just gotten started. Click again to see a more detailed screen.
Here, you will have the option to see the call stack, various classes invoked, threads involved, which might even get a little overwhelming for some. But it’s really a great tool once you get around it.
We’re not done yet. You can even record reading over time. After your record, Android Studio will present you with some really in-depth stats for memory consumption, down to every single byte. Amazing!
Make sure you have some interactions while you are recording the session as it does require data to generate the insights. Once you stop recording, the bottom side will burst with data.
It shows all the callers and their calls in a top-down manner. Method calls will have different calls for you to easily identify.
It reveals which methods took our device’s precious CPU time. It aggregates the same as call stacks, inverting the chart from the previous tab.
Shows method invocation in a top-down manner.
What You Can Conclude From These Graphs?
- If your memory graph is continuously growing, and no memory is being freed, there is only a limited memory that your Android OS will allocate to your app, after which your app will throw an
OutOfMemoryerror. (To see this in action, maybe create an infinitely growing list view. Kids don’t try this at home!) Then, maybe replace your list view with a recycler view to see if you have saved any memory after using recycler view.
- If your graph is fluctuating rapidly, it means that your memory is being consumed and the garbage collection is also freeing memory frequently, which will also cause an impact on UX.
The main object here should be to keep graphs as flat as possible in as low as possible readings. Don’t keep it flat at 800Mbs.
A Personal Example and What You Should Expect While Profiling
Today, while working on one of my projects, I looked into the Android Profiler and saw a huge spike in the application’s memory consumption and felt really surprised to see that huge spike of memory, even though the app was doing pretty much nothing at the start.
So, I wanted to compare my already ongoing app with a fresh new app which does nothing, so I created the default My Application Android Studio project and ran it on my Oppo Realme 2, running Android Oreo.
This is what the profiler looks like for the default new project:
Looking into the spike, it shows the breakdown of the memory being used.
So, then I tried running the same My Application on an emulated device, Nexus 6 running API 28, here is the profile look for that.
So, the Android device you are running your app on does affect your app’s performance, and might give you some shocking results like these!
The native memory consumption for the emulated device was 42MB while that of Oppo Realme 2 was 283.5MB. The very obvious conclusion is that I should not be using my phone to check the app’s performance in the Profiler.
This is just barely scratching the surface. In one of the future stories we will deep-dive to further explore its offerings and how we can leverage it to build beautiful, yet performant apps.
That’s for the eighth day folks! I hope you are learning along with me with this series. Let me know your thoughts, or share any feedback, so that I can bring more value to you. See you tomorrow!