这张表格代表的是,你Record这段时间之内创建的对象,点击一下第二列Allocations
,对创建的数量进行排序,找出创建次数最多的对象:
然后,点击排行第一的String之后,会在右方看到:
然后点击其中的一个,又会看到一个新的窗口:
到此为止,就找到了
创建对象
的元凶
,以这个为线索,找到你们自己包名下的类和方法,确定是我们自己的代码在不合理地创建对象.
再往后,就是根据各自的业务代码去做优化了,记住一个宗旨:不要让代码干多余的事。如果是我们调用了系统的api导致了不合理地大量对象的创建,那么就要考虑这个系统API为什么会这样创建对象,有没有其他方法避免吗,从业务代码层来合理使用这个api,实在不行再考虑自定义api或者换个系统api。
在我们做了一次优化之后,再profile运行一次app,再重复上面的过程。以此类推,直到内存抖动达到理想状态。
总结
优化内存抖动,核心就是防止频繁创建对象。常见的反面教材就是:循环中创建对象,大量调用的api中创建对象。而优化的主要手段,就是对象复用,常见的手段是:对象池,像是 Handler的Message 单链表池,Glide的bitmap池等。
检测以及处理内存泄漏
经典案例:处理
handler
异步任务导致的内存泄漏方法
- 在Activity的onDestroy中移除所有的任务
@Override
protected void onDestroy() {
super.onDestroy();
handler.removeCallbacksAndMessages(null);//移除所有任务
}
- 使用静态内部类 + Activity弱引用的方式
MyHandler handler = new MyHandler(this);
private static class MyHandler extends Handler {
WeakReference activityWeakReference;
MyHandler(Activity activity) {
activityWeakReference = new WeakReference<>(activity);
}
@Override
public void handleMessage(Message msg) {
//在执行任务的时候,判断弱引用所关联的对象是否为空,能在对象已经被回收的情况下,不去执行不必要的任务
switch (msg.what) {
case 1:
if (activityWeakReference.get() != null) {
//TODO
}
}
}
}
工具的使用
依然是profileApp
,先用profile
看出内存的变化情况。
- 问:如何判断内存泄漏?
答:内存泄漏是精细功夫,不能全盘观察,只能凭借profile的内存变化来推测。
比如,打开app之后内存一路飙升,直到超出app能够使用的最大内存,app崩溃,,这是最明显的。
又比如,你反复打开关闭某一个界面,发现内存的稳定线(内存稳定之后,内存占用值
)随着每一次的打开关闭,都在提高,这说明,这一个界面上存在泄漏,有对象无法被回收。
上一章节使用profile
最多是了解到 哪些对象的创建和回收引起了内存抖动,但是,涉及到泄漏,只通过profile尚且不能
知道是哪个类持有了希望被回收的对象的强引用
.
这里就要借助另外一款工具,他的名字叫做 Eclipse Mat
(自行百度)
先回到刚才的profile
,
点一下,然后再点一下,界面会自动跳转:
点击上面的保存按钮,将文件存到本地;
然后:
但是这个文件是无法直接在mat打开的。
找到SDK目录下的要hprof-conv.exe
:
使用cmd命令,对文件进行转换,命令为:
hprof-conv [源文件名] [目标文件名]
如hprof-conv 1.hprof 2.hprof
回车
将得到的2.hprof
利用刚才下载的Mat工具打开:
这里有很多指标,但是检查内存泄漏,我们只需要关注这个直方图按钮即可:
这个图中会列出你dump的这一段内存中的所有对象,包括framework层的,也包括我们自己代码创建的对象。
案例模拟
我模拟了一个经典案例,也就是前面提到的
Handler
延时任务导致Activity
不能被释放,核心代码如下:我就用一个非常普通的方式创建了一个
handler
对象,并且用它来执行一段延时任务,只不过,延时任务的延时时间是Integer
的最大值,也就是说,任务要很久以后才会执行。之后,我反复进出这一个Activity
,然后按照上面的方式dump
了一段hprof
,经过hprof-conv
转化,然后用Mat
打开:
结果如下:我填写过滤信息:
SecondActivity
回车:在我们最终退出
SecondActivity
之后,内存中依然保留了18
个无用的对象。
那么是不是我们这18个都是泄漏的呢?
不一定。
前文讲过,只有不合理的强引用,才会导致内存泄漏,所以我们要按照上面的方式排除软弱虚引用。
之后我们能看到下面的界面,把能展开的信息尽数展开:了解
Handler源码
的同志们应该一眼就看明白了,handler
引起了内存泄漏,是因为存在不合理地强引用链,
上图中可以看出,最终是callback对象持有了SecondActivity
对象。
callback
任务的延时时间太长了,还没有执行完,所以强引用不会给你释放掉,而callback
持有了Activity
,导致Activity
不能被释放。
如何优化内存泄漏
我们刚才已经看到了Handler的不合理使用导致了内存泄漏,那么如果在
onDestroy
中移除所有的任务:
执行同样的任务,dump下来的hprof 在mat:
触发了GC之后,
SecondActivity
数量变为了0,内存泄漏解决。
当然还有另一种做法,静态内部类+弱引用。
ps:静态内部类是为了防止内部类持有外部类的引用,弱引用是为了在GC触发之时,回收掉WeakRefrence中的对象。
public class SecondActivity extends AppCompatActivity {
Handler handler = new Handler();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_second);
handler.postDelayed(runnable, Integer.MAX_VALUE);//依然是那个延时很久的任务
}
Runnable runnable = new MyRunnable(this);
private static class MyRunnable implements Runnable {// 静态内部类
WeakReference activityWeakReference;//弱引用
MyRunnable(Activity activity) {
activityWeakReference = new WeakReference<>(activity);
}
@Override
public void run() {
}
}
}
最后
在这里小编整理了一份Android大厂常见面试题,和一些Android架构视频解析,都已整理成文档,全部都已打包好了,希望能够对大家有所帮助,在面试中能顺利通过。
喜欢本文的话,不妨顺手给我点个小赞、评论区留言或者转发支持一下呗
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!