From 9a62337534784fb0968efceec3645a9db17d0798 Mon Sep 17 00:00:00 2001 From: luoxiaoke Date: Fri, 30 Mar 2018 18:30:00 +0800 Subject: [PATCH] =?UTF-8?q?Update=20Android=E5=86=85=E5=AD=98=E6=B3=84?= =?UTF-8?q?=E6=BC=8F=E6=80=BB=E7=BB=93.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 标题 markdown语法错误修改 --- ...04\346\274\217\346\200\273\347\273\223.md" | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git "a/Part1/Android/Android\345\206\205\345\255\230\346\263\204\346\274\217\346\200\273\347\273\223.md" "b/Part1/Android/Android\345\206\205\345\255\230\346\263\204\346\274\217\346\200\273\347\273\223.md" index 445f397..4cea2cd 100644 --- "a/Part1/Android/Android\345\206\205\345\255\230\346\263\204\346\274\217\346\200\273\347\273\223.md" +++ "b/Part1/Android/Android\345\206\205\345\255\230\346\263\204\346\274\217\346\200\273\347\273\223.md" @@ -1,11 +1,11 @@ -#Android 内存泄漏总结 +# Android 内存泄漏总结 内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个 总结 沉淀下来跟大家一起分享和学习，也给自己一个警示，以后 coding 时怎么避免这些情况，提高应用的体验和质量。 我会从 java 内存泄漏的基础知识开始，并通过具体例子来说明 Android 引起内存泄漏的各种原因，以及如何利用工具来分析应用内存泄漏，最后再做总结。 -##Java 内存分配策略 +## Java 内存分配策略 Java 程序运行时的内存分配策略有三种,分别是静态分配,栈式分配,和堆式分配，对应的，三种存储策略使用的内存空间主要分别是静态存储区（也称方法区）、栈区和堆区。 @@ -15,7 +15,7 @@ Java 程序运行时的内存分配策略有三种,分别是静态分配,栈式 * 堆区 ： 又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存，也就是对象的实例。这部分内存在不使用时将会由 Java 垃圾回收器来负责回收。 -##栈与堆的区别： +## 栈与堆的区别： 在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被重新使用。 @@ -48,7 +48,7 @@ mSample3 指向的对象实体存放在堆上，包括这个对象的所有成 了解了 Java 的内存分配之后，我们再来看看 Java 是怎么管理内存的。 -##Java是如何管理内存 +## Java是如何管理内存 Java的内存管理就是对象的分配和释放问题。在 Java 中，程序员需要通过关键字 new 为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是 Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。 @@ -61,7 +61,7 @@ Java的内存管理就是对象的分配和释放问题。在 Java 中，程序 Java使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达的，那么GC也是可以回收它们的。这种方式的优点是管理内存的精度很高，但是效率较低。另外一种常用的内存管理技术是使用计数器，例如COM模型采用计数器方式管理构件，它与有向图相比，精度行低(很难处理循环引用的问题)，但执行效率很高。 -##什么是Java中的内存泄露 +## 什么是Java中的内存泄露 在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。 @@ -190,14 +190,14 @@ this.a=a; 显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况 -##Android中常见的内存泄漏汇总 +## Android中常见的内存泄漏汇总 --- -###集合类泄漏 +### 集合类泄漏 集合类如果仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。如果这个集合类是全局性的变量 (比如类中的静态属性，全局性的 map 等即有静态引用或 final 一直指向它)，那么没有相应的删除机制，很可能导致集合所占用的内存只增不减。比如上面的典型例子就是其中一种情况，当然实际上我们在项目中肯定不会写这么 2B 的代码，但稍不注意还是很容易出现这种情况，比如我们都喜欢通过 HashMap 做一些缓存之类的事，这种情况就要多留一些心眼。 -###单例造成的内存泄漏 +### 单例造成的内存泄漏 由于单例的静态特性使得其生命周期跟应用的生命周期一样长，所以如果使用不恰当的话，很容易造成内存泄漏。比如下面一个典型的例子， @@ -274,7 +274,7 @@ return instance; } ``` -###匿名内部类/非静态内部类和异步线程 +### 匿名内部类/非静态内部类和异步线程 非静态内部类创建静态实例造成的内存泄漏 @@ -305,7 +305,7 @@ return instance; 其中： NO1表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建 -###匿名内部类 +### 匿名内部类 android开发经常会继承实现Activity/Fragment/View，此时如果你使用了匿名类，并被异步线程持有了，那要小心了，如果没有任何措施这样一定会导致泄露 @@ -333,7 +333,7 @@ ref1和ref2的区别是，ref2使用了匿名内部类。我们来看看运行 this$0这个引用指向MainActivity.this，也就是说当前的MainActivity实例会被ref2持有，如果将这个引用再传入一个异步线程，此线程和此Acitivity生命周期不一致的时候，就造成了Activity的泄露。 -###Handler 造成的内存泄漏 +### Handler 造成的内存泄漏 Handler 的使用造成的内存泄漏问题应该说是最为常见了，很多时候我们为了避免 ANR 而不在主线程进行耗时操作，在处理网络任务或者封装一些请求回调等api都借助Handler来处理，但 Handler 不是万能的，对于 Handler 的使用代码编写一不规范即有可能造成内存泄漏。另外，我们知道 Handler、Message 和 MessageQueue 都是相互关联在一起的，万一 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将被线程 MessageQueue 一直持有。 @@ -464,7 +464,7 @@ public final void removeMessages(int what); public final void removeMessages(int what, Object object); ``` -###尽量避免使用 static 成员变量 +### 尽量避免使用 static 成员变量 如果成员变量被声明为 static，那我们都知道其生命周期将与整个app进程生命周期一样。 @@ -475,7 +475,7 @@ public final void removeMessages(int what, Object object); 不要在类初始时初始化静态成员。可以考虑lazy初始化。 架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。 -###避免 override finalize() +### 避免 override finalize() 1、finalize 方法被执行的时间不确定，不能依赖与它来释放紧缺的资源。时间不确定的原因是： 虚拟机调用GC的时间不确定 @@ -488,7 +488,7 @@ public final void removeMessages(int what, Object object); 3、含有Finalize方法的object需要至少经过两轮GC才有可能被释放。 -###资源未关闭造成的内存泄漏 +### 资源未关闭造成的内存泄漏 对于使用了BraodcastReceiver，ContentObserver，File，游标 Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。 @@ -500,7 +500,7 @@ public final void removeMessages(int what, Object object); Bitmap 没调用 recycle()方法，对于 Bitmap 对象在不使用时,我们应该先调用 recycle() 释放内存，然后才它设置为 null. 因为加载 Bitmap 对象的内存空间，一部分是 java 的，一部分 C 的（因为 Bitmap 分配的底层是通过 JNI 调用的 )。 而这个 recyle() 就是针对 C 部分的内存释放。 构造 Adapter 时，没有使用缓存的 convertView ,每次都在创建新的 converView。这里推荐使用 ViewHolder。 -##总结 +## 总结 对 Activity 等组件的引用应该控制在 Activity 的生命周期之内； 如果不能就考虑使用 getApplicationContext 或者 getApplication，以避免 Activity 被外部长生命周期的对象引用而泄露。