內存泄漏在Android應用開發中是一個常見問題，它發生在對象不再被使用時，但仍然被引用，導致垃圾回收器無法釋放其占用的內存。這會逐漸消耗應用可用內存，最終可能導致應用運行緩慢、崩潰或被系統終止。以下是一些常見的內存泄漏場景及解決方案：
1. 靜態變量持有Activity或Context
問題: 當靜態變量直接或間接地持有Activity或Application Context的引用時，即使Activity不再使用，也無法被回收。
解決方案:
盡量避免在靜態變量中存儲Activity或Context的引用。
如果必須存儲Context，可以考慮使用ApplicationContext代替Activity Context，因為Application Context的生命周期與整個應用相同，不會導致內存泄漏。
2. 內部類和匿名類
問題: 非靜態內部類和匿名類會隱式持有外部類的引用，如果這些內部類的生命周期長于外部類（如線程、監聽器等），就會導致外部類無法被回收。
解決方案:
使用靜態內部類，并將需要的外部類引用作為弱引用傳遞給靜態內部類。
或者使用匿名類時，確保在不再需要時能及時解除對外部類的引用。
3. Handler導致的內存泄漏
問題: Handler通常與主線程的MessageQueue關聯，如果Handler中發送了延時消息或者Runnable，而它們的執行時間超過Activity的生命周期，就會導致Activity泄漏。
解決方案:
在Activity的onDestroy()方法中移除所有消息和回調。
使用弱引用持有Activity的引用，如WeakReference<Activity>。
4. Bitmap未正確回收
問題: Bitmap是內存占用較大的對象，如果沒有正確地回收，會引發嚴重的內存泄漏。
解決方案:
使用Bitmap時，確保在不再需要時調用recycle()方法。
使用BitmapFactory.Options設置適當的inSampleSize來減小Bitmap的大小。
使用try-with-resources或finally塊確保Bitmap資源被釋放。
5. 注冊未注銷的監聽器和觀察者
問題: 如注冊廣播接收器、傳感器監聽器、ContentObserver等，如果沒有在Activity或Fragment銷毀時及時注銷，也會導致內存泄漏。
解決方案:
在Activity或Fragment的生命周期方法（如onStop()或onDestroy()）中注銷所有的監聽器和觀察者。
6. Cursor未關閉
問題: 數據庫查詢操作后，Cursor對象如果沒有及時關閉，也會引起內存泄漏。
解決方案:
確保在使用完Cursor后立即關閉它，最好在finally塊中進行。
7. 第三方庫使用不當
問題: 使用第三方庫時，如果不遵循最佳實踐，也可能引入內存泄漏。
解決方案:
仔細閱讀第三方庫的文檔，了解其內存管理機制，確保正確使用其API。
監控應用使用第三方庫時的內存行為，使用工具如LeakCanary進行檢測。
綜合解決方案
使用內存分析工具: 如Android Studio的Profiler或第三方庫LeakCanary，定期檢查應用是否存在內存泄漏。
代碼審查: 團隊內部應有代碼審查機制，關注可能導致內存泄漏的代碼模式。
教育和培訓: 提升團隊成員對內存管理重要性的認識，分享最佳實踐。
通過以上措施，可以有效識別并解決內存泄漏問題，提升應用性能和用戶體驗。

最常見的8個Android內存泄漏問題及解決方法
https://zhuanlan.zhihu.com/p/641405076

全民K歌內存篇3——native內存分析與監控
https://cloud.tencent.com/developer/article/1817357