一、單一手勢 應用程式的手勢操作是指在移動設備上使用手指或手勢進行與應用程式交互的方式。手勢操作可以包括點擊、滑動、雙擊、捏合等動作，用於實現不同的功能和操作。 HarmonyOS中常見的手勢操作及其功能： 1.點擊手勢（TapGesture） 點擊手勢（TapGesture）是指用戶在觸摸 ...
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 在應用沒有動態列表圖片載入的時候可以滿足載入圖片和記憶體兩者之間的平衡，如果瀑布流圖片較多，可考慮加入記憶體清理機制
大家有什麼觀點，歡迎共同探討
