石家庄周边游,傲君夺爱,柜
前言
内存管理的目的就是让我们在开发过程中有效避免我们的应用程序出现内存泄露的问题。内存泄露相信大家都不陌生，我们可以这样理解：「没有用的对象无法回收的现象就是内存泄露」。
如果程序发生了内存泄露，则会带来以下这些问题
下面我们从基础说起
基础知识
java 的内存分配简述
java四种不同的引用类型
与 android 中的差异：在 2.3 以后版本中，即使内存够用，android 系统会优先将 softreference 的对象提前回收掉, 其他和 java 中是一样的。
因此谷歌官方建议用lrucache(least recentlly use 最少最近使用算法)。会将内存控制在一定的大小内, 超出最大值时会自动回收, 这个最大值开发者自己定。
什么是内存泄漏？
内存泄漏根本原因
长生命周期的对象持有短生命周期对象**强/软引用**,导致本应该被回收的短生命周期的对象却无法被正常回收。
例如在单例模式中，我们常常在获取单例对象时需要传一个 context 。单例对象是一个长生命周期的对象（应用程序结束时才终结），而如果我们传递的是某一个 activity 作为 context,那么这个 activity 就会因为引用被持有而无法销毁，从而导致内存泄漏。
内存泄漏的危害
内存泄漏的典型案例
永远的单例（singleton）
由于单例模式的静态特性，使得它的生命周期和我们的应用一样长，一不小心让单例无限制的持有 activity 的强引用就会导致内存泄漏。
解决方案
把传入的 context 改为同应用生命周期一样长的 application 中的 context。
通过重写 application，提供 getcontext 方法,那样就不需要在获取单例时传入 context。
我要评论
public class baseapplication extends application{
private static applicationcontext scontext;
@override
public void oncreate(){
super.oncreate();
scontext = getapplicationcontext();
}
public static context getapplicationcontext(){
return scontext;
}
}
handler引发的内存泄漏
由于 handler 属于 tls（thread local storage）变量，导致它的生命周期和 activity 不一致。因此通过 handler 来更新 ui 一般很难保证跟 view 或者 activity 的生命周期一致，故很容易导致无法正确释放。
例如：
public class handlerbadactivity extends appcompatactivity {
private final handler handler = new handler(){//非静态内部类，持有外部类的强引用
@override
public void handlemessage(message msg) {
super.handlemessage(msg);
}
};
@override
protected void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
setcontentview(r.layout.activity_handler_bad);
// 延迟 5min 发送一个消息
handler.postdelayed(new runnable() {
//内部会将该 runable 封装为一个 message 对象，同时将 message.target 赋值为 handler
@override
public void run() {
//do something
}
}, 1000 * 60 * 5);
this.finish();
}
}
上面的代码中发送了了一个延时 5 分钟执行的 message，当该 activity 退出的时候，延时任务（message）还在主线程的 messagequeue 中等待，此时的 message 持有 handler 的强引用（创建时通过 message.target 进行指定），并且由于 handler 是 handlerbadactivity 的非静态内部类，所以 handler 会持有一个指向 handlerbadactivity 的强引用，所以虽然此时 handlerbadactivity 调用了 finish 也无法进行内存回收，造成内存泄漏。
解决方法
将 handler 声明为静态内部类，但是要注意**如果用到 context 等外部类的 非static 对象，还是应该使用 applicationcontext 或者通过弱引用来持有这些外部对象**。
public class handlergoodactivity extends appcompatactivity {
private static final class myhandler extends handler{//声明为静态内部类（避免持有外部类的强引用）
private final weakreference<handlergoodactivity> mactivity;
public myhandler(handlergoodactivity activity){
this.mactivity = new weakreference<handlergoodactivity>(activity);//使用弱引用
}
@override
public void handlemessage(message msg) {
handlergoodactivity activity = mactivity.get();
if (activity == null || activity.isfinishing() || activity.isdestroyed()) {//判断 activity 是否为空，以及是否正在被销毁、或者已经被销毁
removecallbacksandmessages(null);
return;
}
// do something
}
}
private final myhandler myhandler = new myhandler(this);
}
慎用 static 成员变量
static 修饰的变量位于内存的方法区，其生命周期与 app 的生命周期一致。 这必然会导致一系列问题，如果你的 app 进程设计上是长驻内存的，那即使 app 切到后台，这部分内存也不会被释放。
解决方法
不要在类初始化时初始化静态成员，也就是可以考虑懒加载。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。
当然，application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 activity 的 context，对于application，service，activity三者的context的应用场景如下：
| 功能 | application | service | activity |
|---|---|---|---|
| start an activity | no1 | no1 | yes |
| show a dialog | no | no | yes |
| layout inflation | yes | yes | yes |
| start an service | yes | yes | yes |
| bind an service | yes | yes | yes |
| send a broadcast | yes | yes | yes |
| register broadcastreceiver | yes | yes | yes |
| load resource values | yes | yes | yes |
使用系统服务引发的内存泄漏
为了方便我们使用一些常见的系统服务，activity 做了一些封装。比如说，可以通过 getpackagemanager在 activtiy 中获取 packagemanagerservice，但是，里面实际上调用了 activity 对应的 contextimpl 中的 getpackagemanager 方法
contextwrapper#getpackagemanager
@override
public packagemanager getpackagemanager() {
return mbase.getpackagemanager();
}
contextimpl#getpackagemanager
@override
public packagemanager getpackagemanager() {
if (mpackagemanager != null) {
return mpackagemanager;
}
ipackagemanager pm = activitythread.getpackagemanager();
if (pm != null) {
// doesn't matter if we make more than one instance.
return (mpackagemanager = new applicationpackagemanager(this, pm));//创建 applicationpackagemanager
}
return null;
}
applicationpackagemanager#applicationpackagemanager
applicationpackagemanager(contextimpl context,
ipackagemanager pm) {
mcontext = context;//保存 contextimpl 的强引用
mpm = pm;
}
private usermanagerservice(context context, packagemanagerservice pm,
object packageslock, file datadir) {
mcontext = context;//持有外部 context 引用
mpm = pm;
//代码省略
}
packagemanagerservice#packagemanagerservice
public class packagemanagerservice extends ipackagemanager.stub {
static usermanagerservice susermanager;//持有 ums 静态引用
public packagemanagerservice(context context, installer installer,
boolean factorytest, boolean onlycore) {
susermanager = new usermanagerservice(context, this, mpackages);//初始化 ums
}
}
遇到的内存泄漏问题是因为在 activity 中调用了 getpackagemanger 方法获取 pms ，该方法调用的是 contextimpl，此时如果contextimpl 中 packagemanager 为 null，就会创建一个 packagemanger（contextimpl 会将自己传递进去，而 contextimpl 的 moutercontext 为 activity），创建 packagemanager 实际上会创建 packagemanagerservice（简称 pms），而 pms 的构造方法中会创建一个 usermanger（usermanger 初始化之后会持有 contextimpl 的强引用）。
只要 pms 的 class 未被销毁，那么就会一直引用着 usermanger ，进而导致其关联到的资源无法正常释放。
解决办法
将getpackagemanager()改为 getapplication()#getpackagemanager() 。这样引用的就是 application context，而非 activity 了。
远离非静态内部类和匿名类
因为使用非静态内部类和匿名类都会默认持有外部类的引用，如果生命周期不一致，就会导致内存泄漏。
public class nestedclassleakactivity extends appcompatactivity {
class innerclass {//非静态内部类
}
private static innerclass sinner;//指向非静态内部类的静态引用
@override
protected void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
setcontentview(r.layout.activity_nested_class);
if (sinner == null) {
sinner = new innerclass();//创建非静态内部类的实例
}
}
}
非静态内部类默认会持有外部类的引用，而外部类中又有一个该非静态内部类的静态实例，该静态实例的生命周期和应用的一样长，而静态实例又持有 activity 的引用，因此导致 activity 的内存资源不能正常回收。
解决方法
将该内部类设为静态内部类 也可以将该内部类抽取出来封装成一个单例
集合引发的内存泄漏
我们通常会把一些对象的引用加入到集合容器（比如arraylist）中，当我们不再需要该对象时（通常会调用 remove 方法），并没有把它的引用从集合中清理掉（其中的一种情况就是 remove 方法没有将不再需要的引用赋值为 null），下面以 arraylist 的 remove 方法为例
public e remove( int index) {
// 数组越界检查
rangecheck(index);
modcount++;
// 取出要删除位置的元素，供返回使用
e oldvalue = (e) elementdata[index];
// 计算数组要复制的数量
int nummoved = size - index - 1;
// 数组复制，就是将index之后的元素往前移动一个位置
if (nummoved > 0)
system. arraycopy(elementdata, index+1, elementdata, index,
nummoved);
// 将数组最后一个元素置空（因为删除了一个元素，然后index后面的元素都向前移动了，所以最后一个就没用了），好让gc尽快回收
elementdata[--size ] = null; // let gc do its work
return oldvalue;
}
webview 引发的内存泄漏
webview 解析网页时会申请native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。
由于占用的都是native 堆内存，所以实际占用的内存大小不会显示在常用的 ddms heap 工具中（ dms heap 工具看到的只是java虚拟机分配的内存，即使native堆内存已经占用了几百兆，这里显示的还只是几兆或十几兆）。只有使用 adb shell 中的一些命令比如 dumpsys meminfo 包名，或者在程序中使用 debug.getnativeheapsize()才能看到 native 堆内存信息。
据说由于 webview 的一个 bug，即使它所在的 activity(或者service) 结束也就是 ondestroy() 之后，或者直接调用 webview.destroy()之后，它所占用这些内存也不会被释放。
解决方法
把使用了 webview 的 activity (或者 service) 放在单独的进程里。
使用 webview 的页面（activity），在生命周期结束页面退出（ondestory）的时候，主动调用webview.onpause()==以及==webview.destory()以便让系统释放 webview 相关资源。
其他常见的引起内存泄漏原因
android 3.0 以下，bitmap 在不使用的时候没有使用 recycle() 释放内存。
非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如activity中的一些特殊handler等），则尽量使用静态类和弱引用来处理（譬如viewroot的实现）。
警惕线程未终止造成的内存泄露；譬如在 activity 中关联了一个生命周期超过 activity 的 thread，在退出 activity 时切记结束线程。
一个典型的例子就是 handlerthread 的 run 方法。该方法在这里是一个死循环，它不会自己结束，线程的生命周期超过了 activity 生命周期，我们必须手动在 activity 的销毁方法中中调用 thread.getlooper().quit() 才不会泄露。
对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
创建与关闭没有成对出现造成的泄露；譬如cursor资源必须手动关闭，webview必须手动销毁，流等对象必须手动关闭等。
避免代码设计模式的错误造成内存泄露；譬如循环引用，a 持有 b，b 持有 c，c 持有 a，这样的设计谁都得不到释放。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对移动技术网的支持。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Android studio 解决logcat无过滤工具栏的操作
Android Studio 恢复小窗口停靠模式(Docked Mode)
Android studio保存logcat日志到本地的操作
Android Studio快捷键生成TAG、Log.x日志输出介绍
网友评论