First of all, I have seen other questions which might be a duplicate of mine. But none of them could provide me with solution.
There is too much memory consumption at the app startup compared to when it is reached in MainActivity.
At Application class , there is only analytic and facebook sdk initialization. Splash activity contains only logic to check whether user has login before or not. Any Idea what is behind this ? Thanks for paying attention.
You can use Android Studio's memory profiler to see what objects are being allocated and what causes these allocations. It can show you stacktrase of every object allocation. See the docs please.
Related
I've written an application, it's a big one and it has lots of features.
But I have a problem with it: in the phone battery usage it takes about 35 percent of battery and it's a huge problem even when I don't use it very much.
I've no services in my application and I really don't know where the problem is.
Is there any way that I can find out what is using my battery?
I am using PowerTutor for this purpose when i am testing my application performance and battery usage. Even i am using this application also https://developer.qualcomm.com/software/trepn-power-profiler. Please try this let me know if it helps you.
I'm currently investigating one of our Android applications for memory leaks and I found something that completely baffles me.
The DDMS heap monitor reports that the application is using 13mb/20mb heap memory, but a report pulled directly from the device is reporting that the application is using nearly 700mb!
Is this an issue with the device? Is DDMS wrong? How do I find out what is going into that 700mb?
It is part of the system software
The first screenshot is the output of adb shell dumpsys meminfo. The second screenshot looks like it is from procrank, which isn't part of standard Android; leastways, I can't find it quickly on Android 6.0.
(in the future, when somebody asks you 'what exactly is this "report"', feel free to cite actual commands)
Is this an issue with the device?
Probably not, though that's tough to say, since we do not know what the device is, what the app is, or much of anything outside of two digital camera photos.
Is DDMS wrong?
Probably not. Java code, whether running in Dalvik or ART, has a heap limit, and that's going to be well under 700MB.
How do I find out what is going into that 700mb?
~600MB of that will be coming from native code (NDK libraries), most likely.
So, start by finding out what in your app is using native code. That could be your code, or it could come from third-party libraries (e.g., Fresco). Your choices then are:
Call (or implement) logic in those libraries to cap how much heap space they use, or
Get rid of them, or
See if there's a way of hooking up Valgrind or something else to NDK code to determine where and how those libraries are using so much system RAM
Now my app has 2000 downloads and 180 daily users. I don't believe they all use Samsung devices only. I am confused - I don't have any samsung devices, please if you have one - could you please tell me how much RAM they normally allocate for android application? My app normally consumes 20-22mb +2mb per UI reload as memory leaks (but users normally don't do this more than 2-3 times so...)
I have added "LargeHeap" in last version (not in statistics yet).
Is this 46 OutOfMemory errors a lot for 14500 sessions? Or it is okay for android?
You are asking the wrong question. You should be trying to figure out how to make your application less memory-hungry, not trying to find workarounds for specific vendors/OEMs.
For some guidance, this article is particularly helpful: Managing Your App's Memory. Since you mentioned that you are attempting to use the largeHeap attribute in your manifest, you might want to read the following snippet from the article:
In very special situations, you can request a larger heap size by setting the largeHeap attribute to "true" in the manifest <application> tag. If you do so, you can call getLargeMemoryClass() to get an estimate of the large heap size.
However, the ability to request a large heap is intended only for a small set of apps that can justify the need to consume more RAM (such as a large photo editing app). Never request a large heap simply because you've run out of memory and you need a quick fix.
Now, I am aware that there is no such thing as "exiting" an app in Android. By this I mean that the process corresponding to an app is kept in memory even after all the activities in that app are destroyed. (For sake of simplicity, let's keep services and such out of the picture). The process is only killed when the system decides to do so in order to reclaim memory.
However, once all my activities have been destroyed, I would assume that the process corresponding to my app is no longer "active". By this I mean that since my app is not doing any work, I assume the process no longer performs allocations. Is this assumption correct?
I used the simple default HelloWorld example that Eclipse ADT gives me via the New Android Project Wizard and saw that this is not the case. Even after I close the app, I can still track allocations in DDMS. Can anyone explain the reason for this?
Allocation tracker has hints for you: columns Thread Id and Allocated in.
Watch these, and you'll learn which object and method did the allocation.
My inactive app shows allocations in DdmServer, which indicates that memory is used for DDMS service to work.
If you get other kind of allocations, check if your app has some outstanding threads, or other tasks that may be still running in background. If this is the case, make sure to do cleanup in Activity.onDestroy.
There is code running within the process because DDMS is attached to it. That code is the "remote" part of the remote debugging facility. Since there is code running there, that code will allocate memory and you will see those allocations.
If the debugger wasn't attached to the process, the OS could destroy the process if it wanted or needed to. However, because the debugger is attached, the process won't go away while you are watching it.
This is an example of the Observer effect, where you get unexpected results just because you are watching ;-)
I'm trying to find a leak in my app that make the device warms without intensive usage. Is there a way of seeing the number of times a method is called and the CPU time expent for it.
I'm asking that because I don't remember its name now, but for C there is a tool that after compile the app with some special parameters, gives that info
Have a look at Profiling with Traceview and dmtracedump. Link