最近,因為專案時間不緊的原因,就對專案的某些頁面進行了記憶體觀察,發現了兩處優化點.特意記錄下來
1.單例引發的記憶體泄漏
我在專案中涉及到的一個單例是這樣的
object LiveCenter {
......
var function: Function1<Boolean, Any>? = null
fun registerListener(function: Function1<Boolean, Any>?) {
this.function = function
}
......
}
LiveCenter 注冊了一個監聽.這個 Function1 是在 Fragment 中 new 了一個實體.這個時候 LiveCenter 就持有了 Fragment 的參考導致記憶體泄漏.所以需要寫一個 release 方法,在 release 方法中使 function = null 這個和常說的 Context 引發記憶體泄漏其實差不多.這個可以通過 Android Studio 自帶的 Android Profiler.具體用法自己搜吧
2.Fragment 作為 Listener 引發的記憶體泄漏
有的時候為了方便我們會這么寫
public class Instance {
public Instance(Listener listener) {
this.listener = listener;
}
}
public class FragmentA extends BaseFragment implements Listener {
}
這么寫很常見,如果只是 FragmentA 每 new 一次, Instance 也 new 一次.那么就沒啥問題.但如果 FragmentA 對應的 Activity 是 SingleTask 模式.也就是說 FragmentA 可能會多次整個重繪,導致了每次都 new Instance.每次 new 就多了一個參考導致記憶體泄漏.所以在這種情況下一定要注意把那個 listener 置為 null
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/3005.html
標籤：Java
下一篇：LeetCode–洗掉鏈表的節點