关于内存泄漏的一些思考

今天是我注册简书的第一天,我是一个Android程序员。刚开始做这一行时就有很多前辈和我说,作为一个技术人员要坚持每天写博客,把自己工作中遇到的问题记下来。我曾经也在其他平台写过几篇,但都没有坚持下去。最近在工作中遇到的一些事情让我觉得很难过,在和同事讨论一个技术方案时发现在表达自己的观点时逻辑混乱,总是无法让同事理解我的想法。我曾经一度以为是同事的理解能力差,直到我遇到好几次这样的事情,才让我不得不思考是不是我自己的问题?越在职场中混迹越让我觉得表达自己的观点并且让别人理解是一种很重要的能力。为此我决定从今天开始重新开始写博客,既可以把自己在工作中遇到的事情记录下来,又可以锻炼自己的表达能力,如果同时能对别人有帮助就再好不过了。现在开始进入主题吧。

今天先来说说我关于内存泄漏的看法,在网上有很多介绍避免内存泄漏的方法,这里就不在赘述了。我想说的是,如果在我们的app中不幸发生了内存泄漏该怎么办呢?有没有什么办法补救呢?随着业务越来越复杂,代码越来越多,以及人员的更替,哪怕编程过程中再仔细,静态代码检查再严格,也总是有落网之鱼的。

在debug的App中绝大多数App都会使用LeakCanary来检测内存泄漏,它的实现原理是监听activity的生命周期,在activity的onDestory方法中创建一个虚引用指向这个activity对象。五分钟过后通过虚引用的get方法判断activity对象有没有被销毁掉,如果没有被销毁手动触发gc,再用同样的方式判断一下,如果还是没有被销毁就dump memory,并且发送内存泄漏通知。在我们的正式版的app中是否也可以用这种方试来监听内存泄漏呢?在发生内存泄漏时做点什么,让内存泄漏的造成的代价最小。对于一个activity而言最占用内存的部分就是它持有的view对象,因为view对象中可能包含很多图片作为背景或者其他的。还有就是业务相关的对象。那么在监听到某个activity发生内存泄漏后我们就可以释放activity持有的view对象以及其他的对象。可以通过反射,也可以通过创建一个接口,里面包含一个trimMemory之类的方法用于在发生内存泄漏时释放activity引用的对象。简单实现如下

MemoryLeak.kt

 class MemoryLeakAppliction : Application() {
    private val mHandler = Handler(Looper.getMainLooper())

    override fun onCreate() {
        super.onCreate()
        registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks {
            override fun onActivityPaused(p0: Activity) {
            }

            override fun onActivityStarted(p0: Activity) {
            }

            override fun onActivityDestroyed(p0: Activity) {
                val activityReference = WeakReference(p0)
                mHandler.postDelayed({
                    Looper.myQueue().addIdleHandler {
                        if (activityReference.get() == null) {
                            Log.i(TAG, "good!!! has not memory leak")
                            return@addIdleHandler false
                        }
                        Log.i(TAG, "may be memory leak!!, gc and check 3 seconds latter")
                        System.gc()
                        mHandler.postDelayed({
                            val activity = activityReference.get()
                            if (activity != null) {
                                Log.w(TAG, "memory leak!!! activity = ${activity.javaClass.name}")
                                if (activity is MemoryLeakCallbck) {
                                    activity.onMemoryLeak()
                                }
                            }
                        }, 3 * 1000)
                        return@addIdleHandler false
                    }
                }, 5 * 60 * 1000)
            }

            override fun onActivitySaveInstanceState(p0: Activity, p1: Bundle) {
            }

            override fun onActivityStopped(p0: Activity) {
            }

            override fun onActivityCreated(p0: Activity, p1: Bundle?) {
            }

            override fun onActivityResumed(p0: Activity) {
            }
        })
    }
}

interface MemoryLeakCallbck {
    fun onMemoryLeak()
}

MemoryLeakTestActivity.kt

package com.example.firstapp

import androidx.appcompat.app.AppCompatActivity

class MemoryLeakTestActivity: AppCompatActivity(), MemoryLeakCallbck {
    override fun onMemoryLeak() {
        //如果发生内存泄漏,释放activity引用的对象
        setContentView(null)
    }
}
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容