I'm trying to figure why is my app stutter when a user is switching between activities and when a Dialog is created.
I dump my app performance in order to detect anomalies using Profiler and playing with the app for some time.
The only abnormality I managed to detect is the relatively huge number of "Native Size" of Bitmap, in comparison to to other objects:
But I don't really know if its abnormal and if so, how to investigate and solve it.
The app is pretty big so I think it would be best the share the whole repo for you to be able to view the code:
https://github.com/steingolditay/ezBalans
Open the activity which you think is lagging and in the logcat filter byword Choreographer, if you find
Skipped 60 frames!
in the logcat, it means that the application may be doing too much work on its main thread.
then you can optimize your calls and processing for that activity
I noticed in your memory screenshot there are four leaks detected by the memory profiler. Did you try clicking on the label to see what they are?
For debugging missed frames, use the CPU profiler to record a System Trace. See https://developer.android.com/studio/profile/cpu-profiler#frame-render. Once you locate red frames (longer than the 60 Hz threshold), look at your render/UI thread for long running trace events that might have contributed to the bottleneck. This video may be of help.
Related
So, I've a Service that is important for applications logic and thus needs to be alive all the time.
First thing is first, I created it as a foreground service.
Whenever user starts to run, Service starts to do a lot of heavy things. It uses FusedLocationAPI different type of sensors and do a lot of different calculations. At this point phone starts to heat up (CPU usage is high). When running stops, heating stops and CPU drops lower.
This makes me think that the main problem is whenever these sensors are used and calculations are made, but there's a lot of possibilities that could cause this and I wanted to understand, how can I deeply analyze batter usage in this case? I read that Battery Historian should be way to go, but the information there is complicated and do not give me much information. How can I use this data to understand which class/runnable/code part is held responsible for the CPU usage? Maybe there's better ways to solve this? Thanks in advance.
Detailed analysis on what's happening using CPU profiler (after suggestion).
Image. Application is opened and few different screens are switch to and from. Nothing special. Phone does not heat up and from CPU analysis everything also looks pretty okay.
2.User starts to run and enter heavy state. The yellow (light green) rectangle shows previously mentioned "important service" that bring important role to application. Called functions does not use too much time of CPU considering the % of whole running trip - which makes me think, I've to look somewhere else..
What I saw is that CPU increases heavily whenever I lock the phone (while service is running. From CPU Bottom Up analysis I cannot understand what is causing the problem (orange rectangle) - looks like a bunch of Android stuff is happening, but it does not give me any clue.
From CPU profiler I do understand that I have a serious problem considering CPU usage, but right now I do not understand what is causing it (which piece of code/class/function). I know for the fact that whenever my important service is created (on app start) I use PARTIAL_WAKE_LOCK to not allow CPU go to sleep and also make service to be alive at all times. As I understand I need to find different solution for this, because CPU drains too much of battery.
How could I found this using only profiler? I now this fact only for code and profiler stack does not tell me much about this (maybe Im not looking at the right place?)
I found out the root cause of high CPU usage.
I did detailed investigation on threads and found out that DefaultDispatcher threads are using A LOT of CPU.
Turns out the has been a bug in Kotlin-Coroutines library and latest version provides fixes. When I did tests I used version 1.3.1, but changing version number to 1.3.3 provided me with big improvements: from 40% usage to 10% CPU usage.
After playing my libgdx-game for some time, it just freezes. the game loop is not being executed anymore and it does not react to any input; the game can just be killed.
Logcat says this:
The memory graph shows:
(The freeze starts at about 8m30s. Before this time the game is running normally.)
The question: What is happing here? What do I have to do to avoid this game crash?
Could you post more logcat? It's hard do gather any information as to what is causing the problem just by looking at it saying it's suspending all threads.
This usually happens when you run out of memory. Do you have peices of code which load stuff into memory? You may want to take a look at that. Just a possibility, but maybe you are running out of memory. I know what the memory graph shows, but I had a similar problem and I fixed it by optimizing some asset loading.
(you may want to use asset manager to handle memory optimization)
https://github.com/libgdx/libgdx/wiki/Managing-your-assets
If that is not the case, please post some code. (or more logcat)
I have an app that is doing a lot of work related to Bluetooth connection and displaying graphs etc.
App is using many libraries as well. App has also a background service running all the time. Now I noticed that it is taking upto 500 Mbs of Memory Usage.
What I have done was commented out. Everything on app launch and just showed splash screen (custom made) and still footprints are 60-70 Mbs. That means something is taking too much memory without even using it.
One important thing is that Android Studio's Memory Monitor is showing me that app is using only 40-50 Mbs whereas my phone's Memory manager is showing upto 500 MBs. I have tested this on 3 phones. Result remains same.
Any help should be appreciable.
You are leaking alot of memory you can go to memory monitor in android studio and use garbage collector to have an estimation of the total amount of leak you're having.
Most of the time External libraries are main Issue for the memory leakage due to their differing implementations and are quite inefficient when used for work on mobile client.
Here is a great blog regarding memory leakage.
http://blog.nimbledroid.com/2016/05/23/memory-leaks.html
Use MAT Tool to find out memory leakage and resolve that.
Once started service, if it is no needed then stop the service using intent.
And also check you have started any timer thread and not stopped it.
I am using a native code to capture the framebuffer using the link below
http://www.pocketmagic.net/?p=1473.
But my problem is that I want continous capture. Hence I am using service in Android so that it runs in background.
But my problem is that it gives low memory and dies after some time.
Then I tried with single activity and tried to capture the sam window many a times.
This time there is no problem even after 1000 counts.
The problem arises when there is service used.
Please help.
It is hard to say without seeing your source code - you should always try to include the smallest possible application that exhibits the problem behaviour.
At a guess I would say that you have memory hungry resources that are not being cleaned up and this is happening because your memory allocation and release code is not perfectly aligned with the life-cycle of the service. You could confirm this in a couple of ways:
Log the explicit allocation and release of memory and make sure your service is actually executing those parts of the code.
Use a memory profiler to find allocations that are not being released. This might be more challenging with native code than it would be in Java.
I have an android app that is getting fairly large and complex now, and it seems to have intermittent performance problems. One time I will run the app and it's fine, another time it will struggle when switching views.
How can I detect the causes of the performance problem using debugging tools so that I may correct it?
Use the ddms tool which comes with the SDK. It has a nice feature called Allocation Tracker that allows you to see in real time how much memory your code is consuming and what specific line is causing that.
Most of the cases your app will slow down because of bad adapter implementations, poor layout inflation techniques or not using a cache system to decode Bitmaps (such as using SoftReference).
Take a look at this article for a brief explanation: Tracking Memory Allocations
In addition to the tool Cristian mentioned, Traceview is another helpful one. It's not very well documented but it can give you information about how often methods are being called, and which methods are taking a lot of time.
Another good memory tracking tool is MAT, here is a page that describes how to use it with Android: http://ttlnews.blogspot.com/2010/01/attacking-memory-problems-on-android.html
Both the tracing and the heap dumps can be done through the DDMS panel, if you prefer not to work with the command line. In Eclipse, in the devices panel, under the device/emulator you are using, click on your app (listed by package name), and you can then Start/Stop Method Profiling to get a trace and you can use Dump HPROF to get a heap dump. Note, the dumps need to be converted to work with the MAT plugin. The attacking-memory-problems-on-android above describes how to do that.