前兩天在專案的測試過程中出現了不規律崩潰的情況，檢視堆疊資訊是OOM導致的崩潰，但是在程式碼中沒有載入大檔案之類的操作，所以懷疑是記憶體洩漏導致的 ；（關於如何檢視記憶體資訊和某一時刻記憶體中物件（資料）的方法將在下一篇部落格中介紹；）

在檢視記憶體資訊中發現了當退出音樂瀏覽部分的時候還有很多圖片資源（bitmap）沒有被釋放，而這些圖片資源正是來自音樂瀏覽介面的 ；

Glide是一個單例的物件，在向view中注入圖片的時候會有一個 .with(Context ctx) 的方法，這裡可以傳遞上下文，也可以傳遞Fragment，Activity，FragmentActivity，這裡也就是綁定了生命週期；

公司專案裡這部分使用的是fragment，要保留瀏覽介面的快照所以沒有銷燬fragment導致的glide認為fragment一直活動，所以圖片都在記憶體裡沒有被釋放掉；

這裡我想了一個比較取巧的方法，就是使用fragment的onHidden方法來判斷當前fragment是否可見，只要不可見就呼叫glide.clear(View view)來釋放掉圖片資源，列表控制元件則是在介面卡中建立了一個List(ImageView) 用來存放所有的需要用glide注入圖片的imageview，然後增加了一個自定義的公共方法clearGlideCache(),在這個方法裡遍歷所有列表裡面的ImageView然後clear掉他們 ;

這種方法同樣可以解決ViewPager和Fragment匹配時候的時候Glide導致的記憶體溢位的問題(因為在ViewPager隱藏起來的時候實際上沒有被銷燬 , 這時候記憶體中還有隱藏起來的fragment中的圖片) , 缺點是在介面重新顯示的時候需要重新載入一次網路圖片 , 與OOM比起來 , 這樣應該比較好吧 ;

關於Glide相關的問題 , 如果有朋友有比較好的意見 , 請務必提出 , 可以幫助大家少走一些彎路 ;