春衣少年当酒歌,起舞四顾以笑和。这篇文章主要讲述Android内存泄漏的本质原因解决办法操作实例相关的知识,希望能为你提供帮助。
【Android内存泄漏的本质原因解决办法操作实例】
今年最后一个迭代终于结束了,把过程中碰到的不熟悉的东西拉出来学习总结一下
内存泄漏的本质是:【一个(巨大的)短生命周期对象的引用被一个长生命周期(异步生命周期)的对象持有】
这个东西分为两个部分
- 获得一个(巨大的)短生命周期的对象
- 这个【巨大的短生命周期的对象】在android中最有可能的就是【Activity】了
- 最容易无意识获得它的方式就是【非静态内部类隐式自动持有外部类的强引用】
- 把这个对象赋值给了一个长生命周期的对象
- 这个有一些常见的套路
- 套路一:直接赋值给了一个类的静态成员
- 这个静态成员的生命周期和应用的一样长,这就导致了该静态实例一直会持有该Activity的引用,导致Activity的内存资源不能正常回收
- 套路二:一个匿名内部handler的形式持有acitivity,然后message又持有handler,最后长生命周期的Looper持有了这个message
- Handler属于TLS(Thread Local Storage)变量,生命周期和Activity是不一致的
- 当Android应用启动的时候,会先创建一个UI主线程的Looper对象,Looper实现了一个简单的消息队列,一个一个的处理里面的Message对象。主线程Looper对象在整个应用生命周期中存在。
- 当在主线程中初始化Handler时,该Handler和Looper的消息队列关联,同时发送到消息队列的Message会引用发送该消息的Handler对象
- 只要Handler发送的Message尚未被处理,则该Message及发送它的Handler对象将被线程MessageQueue一直持有
- 当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息,而消息队列中的Message持有mHandler实例的引用,mHandler又持有Activity的引用,所以导致该Activity的内存资源无法及时回收,引发内存泄漏
- 套路三:一个匿名内部Runnable持有acitivity,然后这个Runnable有一个耗时任务,这个耗时任务的生命周期比acitivity长
- 异步任务AsyncTask和Runnable都是一个匿名内部类,因此它们对当前Activity都有一个隐式引用
- 线程产生的内存泄漏主要原因在于线程生命周期的不可控。比如线程是Activity的内部类,则线程对象中保存了Activity的一个引用,当线程的run函数耗时较长没有结束时,线程对象是不会被销毁的,因此它引用的老的Activity也不会被销毁,因此就出现了内存泄漏的问题
- java中的Thread有一个特点就是她们都是直接被GC Root所引用,也就是说Dalvik虚拟机对所有被激活状态的线程都是持有强引用,导致GC永远都无法回收掉这些线程对象,除非线程被手动停止并置为null或者用户直接kill进程操作。所以当使用线程时,一定要考虑在Activity退出时,及时将线程也停止并释放掉
- 套路四:把这个对象传入了一个异步线程
- 不要获得一个(巨大的)短生命周期的对象,假如不需要的时候
- 比如最容易无意识获得Activity的方式就是【非静态内部类隐式自动持有外部类的强引用】
- 为了不让内部类自动持有外部类的强引用,把原来的【非静态内部类或者是匿名内部类】重写为【静态内部类】就可以了,也就是独立出来加一个static
- 或者是不要使用内部类,抽出来成为一个外部类
- (这样做之后内部类里就无法直接使用外部环境了(调用外部类的变量和方法),如果要使用的话,就通过构造方法传进来)
- (这样就避免了内部类自动的无法控制的持有全部外部环境,只让内部类使用指定的外部环境的资源)
- 需要获得一个(巨大的)短生命周期的对象时,使用弱引用
- 如果一定要持有acitivty的引用,那就把这个引用改成弱引用
- 不过在【非静态内部类或者是匿名内部类】的情况下,需要先重写为【静态内部类】;因为得先把自动持有acitivity这东西废了,再通过构造方法把activity传进来,才能把acitivity的引用改为弱引用
- 不要赋值给了一个长生命周期的对象,假如可以的话
- 所以就是不需要使用静态变量的地方就不用
- 不过前面的hander和runnable就没有办法了,改不了
- 控制这个长生命周期的对象的生命周期,假如可以的话
- 比如静态变量,就可以在该清空的时候清空
- 把【(巨大的)短生命周期的对象】换成【(巨大的)长生命周期的对象】
- 套路一:单例持有外部引用
- 发生场景
- 网络访问库中VolleyCreator单例持有外部Context
- ToastUtil中Toast单例持有外部Context
- NewMsgReceiver单例中的成员变量observers存入了外部Activity引用
- 原因:
- 单例的静态特性使得单例的生命周期和应用的生命周期一样长
- 解决方法:
- 适合使用方法五
- 单例引用Context要注意Context的生命周期,一般的Context可以使用ApplicationContext,对于单例成员变量注意在onDestory移除引用,比如观察者模式取消注册。
- 或者直接在单例里取ApplicationContext就好了
- 套路一:activity的静态变量持有自己的引用
- 这是之前在场景 “一个acitivity杀掉前面的另一个acitivity” 时我们经常使用的方法
- 解决办法
- 可以使用方法四:在onDestroy的时候清空这个静态变量
- 或者不使用这种方法来杀activity,使用eventbus
- 套路一:使用非静态内部类创建静态实例
- 很容易理解,你这个对象持有context,然后把这个对象赋值给静态变量,那这个context就直接泄漏了
- 举例:在启动频繁的Activity中,为了避免重复创建相同的数据资源,会出现:
- 在Activity内部创建了一个非静态内部类的单例,每次启动Activity时都会使用该单例的数据,这样虽然避免了资源的重复创建,不过这种写法却会造成内存泄漏
-
- public class MainActivity extends AppCompatActivity {
- private static TestResource mResource = null;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- if(mResource == null){
- mResource = new TestResource();
- }
- //...
- }
- class TestResource {
- //...
- }
- }
- 这种必须要使用静态变量,同时不知道什么时候释放,解决方法就是方法一,直接把非静态内部类改成静态就好了
- 套路二:非静态Handler持有外部Context引用
- 这种情况由于handler需要持有activity,所以使用方法二
- 然后具体是:
- 创建一个静态Handler内部类,然后对Handler持有的对象使用弱引用,这样在回收时也可以回收Handler持有的对象
- 这样虽然避免了Activity泄漏,不过Looper线程的消息队列中还是可能会有待处理的消息,所以更好的做法是在Activity的Destroy时或者Stop时应该移除消息队列中的消息
- 另外,还可以使用开源库WeakHandler,一个防止内存泄漏的Handler,详见banner源码WeakHandler.java
-
- public class MainActivity extends AppCompatActivity {
- private MyHandler mHandler = new MyHandler(this);
- private TextView mTextView ;
- private static class MyHandler extends Handler {
- private WeakReference< Activity> reference;
- public MyHandler(Activity activity) {
- reference = new WeakReference< > (activity);
- }
- @Override
- public void handleMessage(Message msg) {
- if(reference != null & & reference.get() != null ){
- Activity activity = reference.get();
- activity.mTextView.setText("");
- }
- }
- }
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- mTextView = (TextView)findViewById(R.id.textview);
- loadData();
- }
- private void loadData() {
- //...request
- Message message = Message.obtain();
- mHandler.sendMessage(message);
- }
- @Override
- protected void onDestroy() {
- super.onDestroy();
- //使用mHandler.removeCallbacksAndMessages(null); 是为了移除消息队列中所有消息和所有的Runnable
- mHandler.removeCallbacksAndMessages(null);
- }
- }
- 套路三:线程造成的内存泄漏
- 比较常见,这两个示例可能每个人都写过:
-
- new AsyncTask< Void, Void, Void> () {
- @Override
- protected Void doInBackground(Void... params) {
- SystemClock.sleep(10000);
- return null;
- }
- }.execute();
- new Thread(new Runnable() {
- @Override
- public void run() {
- SystemClock.sleep(10000);
- }
- }).start();
- 如果任务可能执行很久,那就需要处理了,使用方法一或方法二就OK了
-
- //在Activity销毁时候也应该取消相应的任务AsyncTask.cancel(),避免任务在后台执行浪费资源
- static class MyAsyncTask extends AsyncTask< Void, Void, Void> {
- private WeakReference< Context> weakReference;
- public MyAsyncTask(Context context) {
- weakReference = new WeakReference< > (context);
- }
- @Override
- protected Void doInBackground(Void... params) {
- SystemClock.sleep(10000);
- return null;
- }
- @Override
- protected void onPostExecute(Void aVoid) {
- super.onPostExecute(aVoid);
- MainActivity activity = (MainActivity) weakReference.get();
- if (activity != null) {
- //...
- }
- }
- }
- static class MyRunnable implements Runnable{
- @Override
- public void run() {
- SystemClock.sleep(10000);
- }
- }
- //——————使用——————
- new Thread(new MyRunnable()).start();
- new MyAsyncTask(this).execute();
- MainActivity和HomeFragment EventBus没有反注册
- 解决方案: onDestory注意反注册
- 资源未关闭造成的内存泄漏
- 对于使用了BraodcastReceiver,ContentObserver,File,Cursor,Stream,Bitmap等资源的使用,应该在Activity销毁时及时关闭或者注销,否则这些资源将不会被回收,造成内存泄漏
- 有些代码并不造成内存泄露,但是它们,或是对没使用的内存没进行有效及时的释放,或是没有有效的利用已有的对象而是频繁的申请新内存
- Bitmap没调用recycle()
- Bitmap对象在不使用时,我们应该先调用recycle()释放内存,然后将它设置为null。因为加载Bitmap对象的内存空间,一部分是java的,一部分C的(因为Bitmap分配的底层是通过JNI调用的)。而这个recycle()就是针对C部分的内存释放
- ViewHolder
- 构造 Adapter 时,没有使用缓存的 convertView ,每次都在创建新的 converView。这里推荐使用ViewHolder
- 集合类
- 集合类如果仅仅有添加元素的方法,而没有相应的删除机制,导致内存被占用。如果这个集合类是全局性的变量(比如类中的静态属性,全局性的map等即有静态引用或final一直指向它),那么没有相应的删除机制,很可能导致集合所占用的内存只增不减
- 在activity的onDestroy方法中手动吧所有需要置为Null的静态变量置为null
- 不要在类初始时初始化静态成员。可以考虑lazy初始化
- 尽量不要在静态内部类中使用非静态外部成员变量,使用的话也用弱引用
- 在 Java 的实现过程中,也要考虑其对象释放,最好的方法是在不使用某对象时,显式地将此对象赋值为 null,比如使用完Bitmap后先调用 recycle(),再赋为null,清空对图片等资源有直接引用或者间接引用的数组(使用 array.clear() ; array = null)等,最好遵循谁创建谁释放的原则
- 这是个非常容易发生的情况,比如你随便new一个匿名内部类的时候就会发生,比如new一个clicklistener,new一个Runnable,new一个Handler,但是这种情况本身没有问题,问题是在搭配其他条件的时候发生的
- 这种情况说白了就是:非静态内部类的对象会持有外部对象的强引用
- 为什么会这样,很好理解: 因为内部类要能使用外部类的资源,就是通过这个引用实现的.
public static class MyHandler extends Handler //声明一个弱引用对象 WeakReference< MainActivity> mReference; MyHandler(MainActivity activity) //在构造器中传入Activity,创建弱引用对象 mReference = new WeakReference< MainActivity> (activity); } public void handleMessage(Message msg) //在使用activity之前先判空处理 if (mReference != null & & mReference.get() != null) mReference.get().text.setText(hello word); } }} |
- 场景
- 比如静态启动acitivity方法中传入上一个acitivity
- 把一些常用的或者公共方法放到一个工具类里,写成静态(static)的形式,如果这个方法需要传递一个参数(外部短生命周期对象的引用)的话
- 原因
- 要想造成内存泄漏,你的工具类对象本身要持有指向传入对象的引用才行!但是当你的业务方法调用工具类的静态方法时,会生产一个称为方法栈帧的东西(每次方法调用,JVM都会生成一个方法栈帧),当方法调用结束返回的时候,当前方法栈帧就已经被弹出了并且被释放掉了。 整个过程结束时,工具类对象本身并不会持有传入对象的引用。
- 把对象引用传递给静态方法(不是静态方法也是一样的),在调用结束时,工具类对象本身并不会引用传入的对象。所以就没有问题。
推荐阅读
- Android第二天
- Android第四天
- android笔记20170116
- Android自定义控件系列—Button七十二变
- 安卓刷机
- Android第一天
- Android LogCat
- Android自定义控件系列—icon+文字的多种效果实现
- Python字符串find()用法详细示例