can anybody tell me where to find the source code of Allocation Tracker, the memory trace tool in Android DDMS?(http://grepcode.com/file/repo1.maven.org/maven2/com.android.ddmlib/ddmlib/r16/com/android/ddmlib/Client.java#Client.requestAllocationDetails%28%29)
Or, are there any other ways to analysis the memory allocation and find out how much memory each class uses within an Android app/process?
Related
Nearby I noticed that my Android app often crash because of OOM.
I use Android Studio 3.2.3 Profiler, so I find that native heap are up to 300M.
I want to find the memeory use by every C++ so files, BUT I can not find a tool to accomplish my work.
Any advice is appreciated
adb shell dumpsys mypackage
App Summary
Pss(KB)
------
Java Heap: 11568
Native Heap: 202176
Code: 18576
Stack: 2716
Graphics: 84772
Private Other: 11300
System: 43414
TOTAL USS: 331108
TOTAL: 343727 TOTAL SWAP PSS: 30795
When using LLDB to debug an android project that uses native libraries, i'm unable to export the core dump.
I run my application and get a SIGSEGV in the debugger. Then I open the LLDB console in Android Studio and get the following when i try to export the core dump.
(lldb) process save-core ./core-20180730-174318
error: Failed to save core file for process: no ObjectFile plugins were able to save a core for this process
Currently SaveCore is only implemented for the MachO and PECOFF file formats, but not for ELF. Feel free to file a request for this with bugs.llvm.org and somebody will get around to it at some point. Or if you are interested in hacking on the debugger, you can have a go at implementing it yourself! The people on the lldb-dev (lldb-dev#lists.llvm.org) list would be more than happy to help you out if you want to try your hand at this.
I have been working on an music player app based on android-UniversalMusicPlayer sample. And I have had installed LeakCanary to detect memory leak issue and find out that there is indeed a memory leak issue. Please be noted that I did not make any changes except adding the memory leak detection.
Please refer to the following information for details:
In com.example.android.uamp:1.1:2.
com.example.android.uamp.ui.FullScreenPlayerActivity has leaked:
GC ROOT static android.os.UserManager.sInstance
references android.os.UserManager.mContext
references android.app.ContextImpl.mOuterContext
references com.example.android.uamp.MusicService.mConnections
references android.support.v4.util.ArrayMap.mArray
references array java.lang.Object[].[2]
references android.os.Handler$MessengerImpl.this$0
references android.support.v4.media.MediaBrowserCompat$CallbackHandler.mCallbackImpl
references android.support.v4.media.MediaBrowserCompat$MediaBrowserImplApi23.mBrowserObj
references android.media.browse.MediaBrowser.mContext
leaks com.example.android.uamp.ui.FullScreenPlayerActivity instance
Retaining: 631 KB.
Reference Key: 21cd0054-506d-4c6f-94d1-47090c16fbb0
Device: LGE google Nexus 5 hammerhead
Android Version: 6.0.1 API: 23 LeakCanary: 1.4-beta1 02804f3
Durations: watch=5024ms, gc=121ms, heap dump=6019ms, analysis=40029ms
You could also refer to the link for the dump hprof file. To me it seems that this is a Android system bug? In this case, is there workaround? This is a deadly serious issue to my app as I could stably crash my app by exiting the app and entering the app again with playback on. Any help will be greatly appreciated.
Just for these who are still wondering about the question, it has been fixed in 23.3.0 Android support Library. Please refer to this link for more details.
I wonder if ART is virtual machine. The dex2oat compiles dalvik byte code into the native (specific for platform) code, elf file. So as mentioned in android developer article it still has garbage collector. I don't understand how does it work, we have native compiled elf file, but it still runs in virtual machine environment ? How does GC work in this case ?
Please give a good reference to read about this or please explain this.
Thanks in advance.
GC is just a way the memory is managed. In any Java VM GC is the entity responsible for both memory allocation AND garbage collection. when you allocate an object GC check for available memory and collects garbage if there is no free space. You can implement the same algorithm in native language like C or C++. So it doesn't matter if you compile java to bytecode and then bytecode calls GC and GC runs inside JVM or you compile java to native code and link it with GC which may be a shared library. There was a VM from Miriad Group (ex Esmertec) which did it way before ART but for Java ME
i need to use a classifier J48 in android. But running into heapspace problems. Is there a way to fix the same? I get an error that states. Dalvik format failed: Failed to convert dex. PermGen space.
So you have a memory problem using J48 in Weka on android.
I would try to diagnose this in the following order:
How much memory does your program consume? See here and here for Weka memory consumption.
Add more memory to the JVM (also in the earlier links).
Try running this on a more affluent JVM - can this run on a desktop? Or is the problem unrelated to the OS resources?
Tune your algorithm - build a smaller tree or prune it more heavily.
Prune your dataset - remove unnecessary attributes.
Prune your dataset - use fewer instances.
Use a different algorithm.
If all else fails - implement your decision tree using a different library (scipy/Orange/KNIME/Rapid miner), or roll your own.