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 /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/); 

-》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<String,MyKeyWeakReference> 

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