1) OOM analysis
First of all, you have to understand that the Android system will create a Dalvik virtual machine instance for each application, then create a process and then create the main thread, thus forming an application. Then creating a virtual machine will take into account the allocation of memory DalvikHeap size for each virtual machine. The memory size of different performance mobile phones is different. In the early days, some machines allocated 16M and some were 24M. Of course, DalvikHeap size is an interval with its maximum threshold (usable The adb command is used to view the maximum allocated memory: adbshell getprop dalvik.vm.heapsize). When the memory occupied by the application exceeds this threshold, OutOfMemoryError (commonly known as OOM) is raised. OOM appears mainly because the application memory application accumulates more and more, and the gc future and recycling will exceed the maximum Heapsize threshold.
There are mainly the following situations:
1. The loaded image object is too large;
2. Too many resources, too late to load;
3. A large number of memory leaks have not been released.
Common solutions to avoid OOM:
1. If the image is too large when loading the image, adjust the image size appropriately for compression;
2. The image uses a low-memory encoding method: Bitmap.Config.ARGB_4444;
3. Load network images using level 2 cache, generally third parties have already packaged them;
4. A large number of local image memory references use soft references;
5. Listview's Adapter reuses the cache convertView passed to getView() to avoid repeated inflate, and uses ViewHolder mode to avoid unnecessary calls to findViewById to reduce memory consumption;
6. Try to avoid memory leaks (memory leaks are mostly placed below for detailed introduction);
7. Customize the heap memory allocation size and optimize the heap memory allocation of the Dalvik virtual machine;
2) Memory leak analysis
JAVA garbage collection (garbage collection, GC for short) handles the recovery of heap memory, but if the object has been referenced and cannot be recovered, it will waste memory and can no longer be used, causing a memory leak.
Common memory leaks:
1. The memory leak caused by the singleton is mainly because the Context of the Activity and Service are passed in as member variables to cause the memory leak. You can use context.getApplicationContext() to solve the memory leak;
2. Activity's non-static internal and anonymous classes, they all hold Activity references, which can easily lead to memory leaks. Typical Handler internal classes hold Activity references. You can use static internal class soft references to dereference the internal classes to Activity. So as to solve the memory leak;
3. Recycle() is not called after Bitmap is used, causing memory leaks, which can be solved by adding recycle() at the end;
4. The cursor of the database is not closed, it can be solved by closing it at the end;
5. Calling register to register does not unbind, it can be solved by calling unregister to unbind after the end;
6. Socket and IO are not closed, it can be solved by closing it after the end;
7. Webview is not destroyed after the end, it can be solved by destroying it after the end.
mWebViewContainer.removeView(mWebView);
mWebView.stopLoading();
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.removeAllViews();
mWebView.destroy();