App Performance Analysis with the Android Studio Profiler

hey guys and welcome back to a new video in this video I will show you how you can use the Android Studio profile in order to measure and analyze your apps performance because obviously before you can think of improving your apps performance you first of all need to know where you have potential performance bottle LS and to find these the Android Studio profile is just an excellent tool and even if you have used the Android Studio profile before I'm pretty sure in this video you will learn some new things you might have not known before and if you want to follow along you can open any of your Android Studio Projects ideally an app that has real behavior that maybe has Network request that does something that has something we can actually measure performance of I opened tasky for that which is the app participants of my 10we mentorship program built over the course of 10 weeks but it shouldn't be the focus of this video how we can build this app if you want to learn that then apply to that program down below the topic of this video is how we can now measure the performance of such an app and to do that we first of all need to attach the profile to our apps process so inside of Android Studio I already have that window here that little profile icon it's likely you don't have that in order to add that you need to go to view um tool windows and then make sure to click on profiler that will open the profiler and here you can then attach a session uh normally it does that automatically but we can also add one here by clicking on plus and then selecting our process and then you can already see three things here three categories in terms of performance on the one hand CPU memory and energy so CPU usage um as the name has just um tracks how much the CPU of your device is used um so that will go up for example if you have complex algorithms in your app if you have any difficult um processing logic whatever that might be then we have memory so how much memory your app actually allocate so if you have really huge objects saved in memory then this will go up you you can also see how much memory your app currently needs in this case it's 120 megabytes roughly and lastly we have the energy usage which tells us how much battery our app drain at a specific time there's also a network profiler which was previously also contained here in this Android Studio profile but that has been moved to a different tool window which I'll also show you in this video um but the three categories CPU memory and energy can be found here in this profile right now if we don't do anything then this of course won't look very special but we can change this by going into our app and just doing something for example we can add a little event so it's a simple task in the event management app like a Google Calendar clone kind of where we can add an event here and as soon as we do something you can see that we also see little spikes here so we can enter maybe an event title here um new event title I don't know just doing something that the app needs to process a little bit of um Behavior we can also add some photos which we can attach here to upload to the servers I know some random screenshots I have on my device here just selecting these and yeah then if we click save and then all these photos will be uploaded to our server and after that we can take a look in the profile and see what actually happened here there's our event but we can now go back and see first of all for the CPU usage we can for example click directly here on that Spike and then we get a detail view for that CPU usage because here we can just um here we have more functionality that we might be interested in when it comes to tracking RS performance if we scroll a little bit here in that window then you can see the profile is paused so it's not automatically moving anymore and we can then inspect our app and here we can now see at which given time frame our app was um used how much per of the CPU and for example how many threats we also used at that given time so in this case 69 threats were active by our app at that time here it were only um 30 uh 63 we can then also see where these threads actually came from so in this case just from the app itself but something interesting is that we can also for example Trace our Java and cin method calls so if we click this here and then we need to record a given um given time frame here in our application Again by just scrolling to the very end I think then it should start automatically again yes you can see we then click record and then it's currently recording our behavior and if I now go back in our app and maybe update that event you also notice that it's very laggy because um this recording is in progress but let's say we click edit we maybe I don't know remove one photo remove this here and then after that we hit save again to update that event if we do that then you can see event updated and we can then stop the recording and then you might see a little warning that the trace file is too large of course um the the longer the recording gets the longer the trace file will also become containing which method calls were actually executed in a given time frame but that can just be very helpful if you see you have huge spikes in your CPU usage in the profile and you want to inspect where these come from then you can make such a method Trace I will discard that here because we didn't really have any performance issues here but if you really have that if you notice okay there's actually um quite a spike then it makes a lot of sense to also Trace these method calls um to find out where that spike is coming from in case you're just not sure from where of course um if you're doing something and you know why a certain thing causes a spike then you don't need that method Trace then you probably already know where to look on the code and where to fix and work on that performance issue but so much about CPU if we go back let's take a look for memory we can also click on that and then we also get a little um a little categorized view here which or how much memory actually is used by which yeah kind of categories so by Java by the the native development kit by Graphics by the stack and by your code and that's something we could also record right now so for example we could capture a heap dump so we can see which objects actually um which objects are actually currently in memory if we click record and then wait a little moment it's fetching the results then we have a current Heap dump so just a list of all objects that are currently saved in memory in our Heap and we can take a look which objects actually require the most memory so in this case some kind of segment pool you can see on the right retain size is 164,000 bytes large but if we go down here you can also see some familiar names for example main activity and we can see okay main activity actually uses 3,600 bytes in memory so if you have issues with your apps memory usage then this is the place to look then make such an Heap dump to see which objects actually need a lot of memory and then work on these but of course only if that is an issue if you app run super fluently memory isn't an issue then you also don't need to optimize any performance things or we can then also go back to this view we could also for example record Java and cotent allocations um I'm not quite sure what the difference um to Heap dump right now is but let's click record and see what that gives us I think that just records um similar things but if we now use this app yes if I now click something I just clicked something then you can see how these new things are actually added to this list but um we can also just see how many memory allocations each type of object here needed um we can see the size of that as well so that is quite comparable to what we saw before if we now go back let's go to memory because I think yes let's quit that um because I think that was the important stuff that you need to know when it comes to tracking how much memory your app uses let's go one step further and go into battery usage so here in energy just click into that window and then here we can't really see a lot of extra information but we just get a more detailed view where our app actually used a lot of memory and also where that memory usage came from so here you can see um that memory usage or that Spike came from the CPU but not from the network or location because usually these are also the three things that um are the most battery draining so CPU networking and location tracking if we now scroll to the very right so tracking goes on and we make some kind of of network call for example by editing this event title something like this click save and click save then you will also notice that the app requires some battery here and here we can also then see that the network usage is light so in that case we of course had to make um a network hold and that is also reflected here in our uh battery profile also here on the top for these little red bubbles these indicate that at this point you made um a touch event so in my case I just clicked on some kind of UI event but that can help you to also indicate that this was a user action that triggered this battery Spike or it could also be that something in the background caused that battery Spike so if you have maybe a big spike and you're not sure if that was caused by yourself by you doing something in the app or by a background service then you can use these red bubbles to actually get a feeling for where that Spike might come from but I think everything else here in this energy window is pretty self-explanatory there's also not too much more we need to go into what's also relevant is here on the left for that active profiling session you can also see all these allocation records um this Heap dump Java cotlin method Trace so all these recordings we did you can also see here and save so here you can click on the save icon to also save these somewhere on your machine but the last thing that I want to get into is Network performance so if your app performs some kind of network request how you can track these and how you can see how much traffic there's actually going out of your app and coming into it and that actually was moved out of this profile where that was previously and it was moved into this app inspection window so in case you don't have that you can also open this with a view tool windows and then um where is it app inspection and open it that way that's also where you have that database inspector but that's not what we want want to go into right now we want to go into this network inspector and if we click on this it also starts running right now no Active network requests are firing but as soon as we change this for example by actually renaming this event again new save and as soon as we now click save then you will notice that there is a spike we see how many kilobytes megabytes per second we're currently sending and we can then use this here to inspect this if we scroll a little bit then it will stop to move and we can see at this spike it sent with um 11.6 kiloby a second oh no it actually received something so the response of that Network request with 11 kilobytes a second and it sent that with 1.5 kiloby a second that can be good to know but I think what's especially very interesting in this network profile is that we have something similar to the Chrome web developer tools so if you ever did something with web development then you know that in Chrome you can also inspect which network requests which HTTP requests are fired from website you can inspect the response so what kind of Json response was returned you can inspect the request you can inspect the HTTP headers what most people actually don't know is that Android studio also has such a tool which is this network inspector so here you can see all these requests that were fired since we started that Network inspector in this case it fired something here you can see to this URL task. PL coding event don't even try to send something through that end point you will need an API key which you only get in my mentoring program but if we click on this then we get something very similar as we know from Google Chrome so on the one hand we get the whole Json body that was returned from the server so quite some quite some lines of code here and that pretty much allows you to completely get rid of things like an a logging Interceptor for retrofit which logs all requests that are alloing and all the responses that are coming into your app because Android Studio already has that intern logging Interceptor for your network requests so there's really no need for you to add your own Interceptor where you then need to search for logs take a look and lock at filter these um so that's quite some effort to find out what what you sent to an API and what you received now here in this netork inspector you get that all in a little bit more readable format still not formatted I don't know why but you get all the details here so the request was sent to the event endpoint it was a put request uh status code was okay so 200 content type everything you need to know you can also go into the response tab here then here you get it as a form Json which is much more readable then you get in log hat with using a logging Interceptor you also see the request so what was sent to the server you can see the uh the headers so authorization what kind of token you attached and if we take a look under call stack then here we just see which calls have been made to perform that request you can see it went over a few interceptors on the one hand the JWT token Interceptor which it attach the token to the request in this case and the API key Interceptor which attached the API key to every request so whenever you have some kind of network related issues maybe you are getting a response but not the right data what you expect or you unsure if the correct data gets sent to the server then take a look in this network inspector because it tells you all that without needing to search and lock at so I hope this gave you a good introduction to how this profiler and measuring performance en Studio works of course it's always best to just try this out in your own project just play around with that a little bit and you quickly get a good feeling for what kind of functionality you often need in this profile and which is rather fancy for um specific use cases where you have a specific problem but what I showed you in this video is what you really need in 90 to 95% of the times and no matter if you have active performance issues in your app or not it definitely makes sense before you publish your app to just run the profile I want have a normal usage of your app because just because an app performs well on one device doesn't mean it needs to perform well on all devices out there so I hope this helped thanks so much for watching I wish you an amazing rest of your weekend I'll see you back in the next video bye-bye

Channel: Philipp Lackner

Views: 16,933

Keywords:

Id: CQc-QDTmCoQ

Length: 14min 48sec (888 seconds)

Published: Wed Jan 17 2024