glide是一款非常優秀的圖片載入框架，目前很多專案在使用。提供了非常方法，在此，筆者就不一一列舉了，可以到官網查詢。
目前專案在做記憶體排查，因為是車機專案，之前開發的時候沒有注意記憶體方面的問題（車機專案你懂的），現在ota期間系統提出讓我們最佳化記憶體，說出現過應用記憶體一直增加的情況。
一臉懵逼，第一想法是系統在甩鍋，哥可不接。後來自己偷偷的排查下，是有些需要最佳化的地方。特此記錄如下。
第一想法是，車機專案載入了很多背景圖，有些都在200k~~400k，和UI溝通，無法再壓縮，會糊。
第二是排查程式碼，一頓操作，各種點選，發現原生代碼有需要最佳化的地方。靜態內部類，弱引用搞起。
最後發現是報了glide記憶體洩漏，話不多說上圖
點進去一個
RequestManager是glide內部一個類，查詢使用方法
從view 到application都可以傳，傳哪個就和哪個生命週期繫結
看了程式碼，當前我在fragment和adapter中傳入的都是activity,修改寫法，在activity中使用傳入activity在fragment中使用傳入fragment這也是官方推薦的使用方式。
AndroidStudio profiler 觀察下記憶體情況
heap dump檔案
點開其中一個
阿西吧，明明已經按照官方方法呼叫了，但是還是報了記憶體洩漏風險。我想靜靜。。。
moment later
我有到設定中去切換白天黑夜模式，看了下日誌切換白天黑夜模式的時候並沒有銷燬activity，而是再次點選進入應用是才呼叫了ondestroy方法，是因為這個原因？
抱著這種想法，我多次切換白天黑夜模式，並且退出進入應用，沒有報多個activity例項，一直都是2個，嗯...大概是這個原因了，這時候我想如果我進入應用中
這時候例項中activity應該只有一個例項了吧。然並卵，手動gc釋放，沒有變化。後來和後面一大佬聊天，被告知，androidstudio 手動gc並不能回收activity例項，
它是系統記憶體不足時被AMS回收的。如果這樣的話那就能解釋的通了。
後來我想如果傳入application呢，上家公司做瀑布流列表我依稀記得是全域性封裝的application,說幹就幹。一頓操作
heap dump檔案
androidtudio peofiler沒有再報溢位，差不多時間兩種方式記憶體佔用趨勢也基本一致，最後記憶體也大體相同。
得出結論：
1.glide能很好的管理內部，引用。profiler雖然提醒了記憶體溢位，但是這只是有風險，並不一定會報
2.glide傳入application 在應用沒有動態列表圖片載入的時候可以滿足載入圖片和記憶體兩者之間的平衡，如果瀑布流圖片較多，可考慮加入記憶體清理機制
大家有什麼觀點，歡迎共同探討