oom监测及LeakCanary原理

oom监测及LeakCanary原理,第1张

oom监测及LeakCanary原理

Dalvik:

Linear Alloc: 匿名共享内存

Zygote Space:

Alloc Space :每个进程 独占 

ART:

Non Moving Space 

Zygote Space 

Alloc Space 

Image Space : 预加载的类信息

Large Obj Space :大对象 bitmap

MAT 主要用到了

incoming references 查找引用对象

outgoing references 查找被谁引用

浅堆与深堆

Shallow Heap 代表自己占用内存大小

Retained Heap 代表自己和引用的一共大小

深堆如果释放掉,会释放自己及所引用的总大小

mat排除软弱虚引用后,在查看没释放的大对象

常用的内存调优分析命令:

1. dumpsys meminfo

2. procrank

3. cat /proc/meminfo

4. free

5. showmap

6. vmstat

7. top -n 1

LeakCanary原理:

在ActivityThread.java 里面handleBindApplication(appBindData data)方法中 有一句

installcontentProviders(app,data.providers); 这里会调用contentProvider的onCreate方法

app 为创建好的Appilcation对象

方法里面执行 installProvider(context, null, cpi,false , true , true ); 

-》localProvider.attachInfo(c, info); -》 ContentProvider.this.onCreate();

registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks{

override fun onActivityDestroyed(activity: Activity?) {

refWatcher.watch(activity)

            }

})

下面接着执行

Instrumentation.callApplicationOnCreate(app); 

里面调用app的onCreate方法

Watch方法讲解

ReferenceQueue 队列

在于Reference对象所引用的对象被GC回收时,该Reference对象将会被加入引用队列中

2个map 放观察对象和怀疑对象

MutableMap 

watch的时候

0、移除队列中将要被gc的引用

1、生成一个唯一的key

2、初始化弱引用队列,放入观察对象和key,引用队列

3、通过key 绑定到观察列表上

4、启动线程5s后观察

1、首先去队列中找,

poll() ==null

没有则没有释放,把观察对象(remove)放入到怀疑map中,暂时标记为泄漏。haha可达性分析

poll()!=null

已释放,从弱引用中拿到key,根据key清理观察map,remove为空,表明在怀疑map中,清理

activity监测内存不足的2个方法

onTrimMemory(int level) 内存不够-分等级

onLowMemory() 低内存,马上就会oom

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5583634.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-14
下一篇 2022-12-14

发表评论

登录后才能评论

评论列表(0条)

保存