Android memory optimization mainly includes the following aspects:
- Reasonably set the application's minSdkVersion and targetSdkVersion so that the application can run on more devices, which can improve memory utilization efficiency.
- Avoid doing too much work in the onCreate method of Application and Activity, which will consume too much memory. Unnecessary initialization work can be put into onStart or lazy loading.
- To avoid too much work in UI threads, you can use AsyncTask or Thread to perform time-consuming operations to avoid ANR problems.
- Reuse existing objects to avoid repeated creation of objects, which will generate a large number of garbage objects and increase the burden on GC. Objects can be reused using object pooling techniques.
- Optimize layout and reduce view levels, and you can reduce unnecessary ViewGroups through merge tags. Too many Views will increase memory usage.
- Avoid using too many large images, you can load pictures of appropriate sizes, and use image caching technology to load pictures only when the list slides to the visible area, which can reduce unnecessary image memory usage.
- To monitor and analyze memory usage, you can use ADB's dumpsys meminfo command to view application memory usage, and find modules with large memory usage based on reports for optimization. You can also use memory leak detection tools such as LeakCanary to monitor memory leaks.
- Release resources in time, and release resources in time in the onDestroy method of Activity and Fragment to avoid long-term memory occupancy. Call recycle methods on Bitmap and other resources for recycling.
- Storing data in a SQLite database instead of storing large numbers of objects in memory can greatly reduce memory usage. But you should also note that the database itself will also occupy a certain amount of memory.
- Optimize custom Views. Custom Views must also follow the above memory optimization principles, try to reuse resources, reduce the number of times you create objects, etc.
The main scenarios that are prone to memory leakage in Android development are:
- Static variables hold Activity instances. This will make the Activity unrecyclable, resulting in memory leaks. Static variables should be avoided to hold references to Activity instances.
- Non-static inner classes hold external class instances. Non-static inner classes will implicitly hold references to external classes, which will also cause external classes to be unable to recycle. Non-static inner classes should be avoided, or explicitly make references to inner classes weak references.
- The resource is not released while the thread is running. If an object is created during the thread running but is not released in time, the objects cannot be recycled after the thread ends, resulting in memory leakage. All resources should be released before the end of the thread.
- Non-needed object references are retained in the collection. If no longer needed object references are retained in the collection, these objects cannot be recycled. Unwanted object references should be removed from the collection in time.
- The recycle() method of Bitmap is not called. Bitmap is an object that occupies a large memory. If recycle() is not called to release, it will cause a large memory leakage. The recycle() method should be called when Bitmap is no longer needed.
- The broadcast receiver is registered but not unregister. The registered broadcast receiver will hold the registrant's reference. If unregister is not called, the reference cannot be recycled. Register when needed, and cancel the broadcast receiver when not needed.
- WebView does not remove JavascriptInterface or is released. WebView is also a memory-occupying component. If you keep WebView instances for a long time, it will cause memory leakage. You should remove JavascriptInterface and destroy the WebView when the WebView is not needed.
The key to avoiding memory leaks is to timely release resources that are no longer needed, especially resources with a longer life cycle. Release these resources in the life cycle methods of Activity and Fragment, such as the onDestroy() method, to avoid memory leakage due to the long life cycle of these resources.
At the same time, you can also use memory leak detection tools such as LeakCanary to monitor memory leaks, and regularly analyze and fix problems, which is also necessary during the development process.
This is the end of this article about common memory optimization and memory leak scenarios in Android. For more related content on Android memory optimization and leak scenarios, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!