oomandroid

『壹』 android線程超過多少會oom

首先要說一點，就是在Android中線程數超過一定量，也會拋出OOM，所以OOM不一定是內存不足了才會拋出OOM。
具體數量的問題，每個廠商、每個具體型號的手機最大數量都不太一樣，華為有些手機限制400多個，默認的話應該是1000多個。

『貳』 內存佔用與OOM相關的知識點干貨

本文作者友盟+ U-APM項目組 張方濤

Android內存優化至關重要，而避免內存溢出（OOM）是其核心。本篇將聚焦於內存佔用與OOM相關的關鍵知識點。

Android的內存管理機制包括運行時（ART）和Dalvik虛擬機的paging和memory-mapping。共享內存實現通過多種方式完成，分配與回收應用內存、限制應用內存、以及應用切換操作均需關注。內存監控是管理中的重要部分，主要指標包括內存佔用與OOM。

在了解內存佔用情況時，可通過命令行或Android Studio的Profiler工具進行查看。重要指標如內存佔用量需重點關注。OOM產生於待申請內存超過系統分配給應用的剩餘內存時。對於Android平台，產生OOM的原因主要涉及內存的不合理使用。

內存優化需從多個方面入手，包括優化大對象、減小新對象的內存佔用、選擇更高效的數據結構、優化Bitmap創建、合理復用對象以及避免系統資源的浪費。確保系統資源的高效利用，如使用LRU Cache緩存Bitmap，避免頻繁調用onDraw方法，以及及時回收Bitmap和監聽器，確保Cursor關閉。

內存泄漏會導致對象無法及時釋放，引發後續內存分配不足，進而產生OOM。活動泄漏、及時回收Bitmap、注銷監聽器、以及關閉Cursor都是避免內存泄漏的關鍵。友盟+ U-APM應用性能監控平台提供免費的Android OOM異常監控服務，通過輕量級集成即可使用，幫助開發者實時監控應用性能，優化內存管理。

更多關於內存管理、進程間內存分配、應用內存限制、以及使用內存性能分析器的知識，可參考官方文檔或相關教程，以深入理解並優化Android應用的內存使用。

『叄』 如何分析android的oom，與java靜態代碼分析工具

在Android平台上面，應用程序OOM異常永遠都是值得關注的問題。通常這一塊也是程序這中的重點之一。這下我就如何解決OOM作一點簡單的介紹。
首先，OOM就是內存溢出，即Out Of Memory。也就是說內存佔有量超過了VM所分配的最大。
怎麼解決OOM，通常OOM都發生在需要用到大量內存的情況下（創建或解析Bitmap，分配特大的數組等），在這樣的一種情況下，就可能出現OOM，據我現在了解到，多數OOM都是因為Bitmap太大。所以，這里我就專門針對如何解決Bitmap的OOM。其實最核發的就是只載入可見范圍內的Bitmap，試想這樣一種情況，在GridView或ListView中，數據量有5000，每一屏只顯示20個元素，那麼不可見的，我們是不需要保存Bitmap在內在中的。所以我們就是只把那麼可見的Bitmap保留在內存中，那些不可見的，就釋放掉。當元素滑出來時，再去載入Bitmap。
這里我有兩種方式，都可以避免OOM。
一，主動釋放Bitmap的內存
這種方式我簡單說一下，不太推薦，這也是我最開始使用的一種方法，但最後證明它不是最好的。（不推薦）
它的本質思路是：
1、只載入可見區域的Bitmap
2、滑動時不載入
3、停止滑動（Idle）後，開始重新載入可見區域的圖片
4、釋放滑出可見區域的Bitmap的內在。
它比較復雜：
1、我們需要監聽GridView/ListView的滑動事件，這個很簡單做到，AbsListView#setOnScrollListener(OnScrollListener l)
2、主動調用Bitmap#recycle()方法，它會導致一個問題，必須判斷這個Bitmap是否被一個View(ImageView等）所引用，如果被引用，我們不能簡單地調用recycle()方法，這樣會導致異常，說是View使用了一個已經被回收的Bitmap。
3，我們必須設計自己的線程來控制開始/暫停等，因為GridView/ListView的滑動狀態可能不斷地變化，也就是說滑動->停止->滑動，這種狀態可能不斷變化，這樣就會導致我們的線程中的run()方法裡面的邏輯比較復雜，一旦復雜，問題就可能就得更多。
基於以上幾點，這種方式不是最好的，所以不推薦。
二，設計Cache
這種方式，我覺得是比較好的一種，它首先利用了cache，我認為cache是一個很重要的東西，把Bitmap的內存單獨放在一個地方來管理，這個地方就是cache，它的容量是一定的，我們可能會不斷的向這個cache中添加元素，也可能不斷的移除元素。
為了更好的說明這種方式，先要介紹一下LruCache。
LruCache
1、這其實就是一個LinkedHashMap，任意時刻，當一個值被訪問時，它就會被移動到隊列的開始位置，所以這也是為什麼要用LinkedHashMap的原因，因為要頻繁的做移動操作，為了提高性能，所以要用LinkedHashMap。當cache滿了時，此時再向cache裡面添加一個值，那麼，在隊列最後的值就會從隊列裡面移除，這個值就有可能被GC回收掉。