性能优化----内存优化（3）

一、分析内存的常用工具：（工具很多，掌握原理方法，工具随便找两个能用就行）

1.top/procrank
2.meinfo
3.Procstats
4.DDMS
5.MAT
6.Finder-Activity
7.LeakCanary
8.LeakInspector

二、JAVA虚拟机

image.png

image.png

1.线程私有：
   1.1.程序计数器PC
          a:相当于一个执行代码的指示器，用来确认下一行执行的代码的地址
          b:每个线程都有一个
          c:没有OOM的区
   1.2.虚拟机栈
          a:我们平时说的栈就是这块区域
          b：java虚拟机规范中定义了outofmemory和stackoverflow异常
   1.3.本地方法栈
          a:java虚拟机规范中定义了outofmemory和stackoverflow异常
   1.4.在hotPostVM把虚拟机栈和本地方法栈合为一个栈区

2.共享数据区
  2.1、方法区
      2.1.1：ClassLoader加载类信息常量，静态变量 ，编译后的代码
      2.1.2：OOM
      2.1.3：运行时常量池： 
            a、字面量public satic final  java常量,
            b、符号引用    类，接口全名，方法名
  2.2、java堆
         2.2.1：虚拟机能管理的最大的一块内存 GC的主战场
         2.2.2：OOM
         2.2.3：对象实例  数组的内容

三、GC垃圾回收器

GC如何确定内存回收
1.引用计数算法
讲解：
Object o1=new Object(); 计数+1=1
Object o2;
o2=o1; 计数+1=2
o1=null; 计数为1 o1和o2都不会回收
缺点：互相引用容易出现计算器永不为0

2.可达分析算法

image.png

可作为FC ROOT的对象 ：虚拟机栈正在运行使用的应用 静态属性 常量 JNI引用的对象
GC是需要2次扫描才回收对象，所以我们可以用finalize去救活丢失引用的对象

3.回收也和引用类型有关系
3.1：强引用：Object obj=new Object();
3.2：软引用SoftReference：内存不足时回收，存放一些重要性不是很强又不能随便让清除的对象，比如图片切换到后台不需要马上显示了
3.3：弱引用WeakReference：第一次扫到了，就标记下来，第二次扫到直接回收
3.4：虚引用PhantomReference：幽灵 幻影引用 不对生存造成任何影响，用于跟踪GC的回收通知

四、内存泄漏

产生原因：产生的原因：一个长生命周期的对象持有一个短生命周期对象的引用
通俗讲就是该回收的对象，因为引用问题没有被回收，最终会产生OOM

1.android Profiler的使用：

1.Run菜单下的profile
2.在图型用户界面上选择要分析的一段内存，右键export出来
3.Allocations 动态分配对象个数
4.Deallocation 解除分配的对象格式
5.Total count：对象的总数
6.Shallow Size 对象本身占用的内存大小
7.、Retained Size GC回收能收走的内存大小

2.Mat工具的使用

转换profile文件格式 ：
步骤一、sdk/platform-tools/hprof-conv.exe
步骤二、转换命令 hprof-conv -z src dst
下载： https://www.eclipse.org/mat/downloads.php
打开软件 File菜单下Open Heap Dump... 打开转换好的文件
点击QQL按钮查找activity： select * from instanceof android.app.Activity

3.典型处理方案：

1.第三方SDK引发的问题处理
2.Android源码引发的问题处理（同样可以用在第三方库）
3.常见的错误代码引起的问题处理

五、内存抖动

image.png

1.内存频繁的分配与回收，（分配速度大于回收速度时）最终会产生OOM
2.回收算法：
2.1.标记清除算法Mark-Sweep
2.2.复制算法Copying
2.3.标记压缩算法Mark-Compact
2.4.分代收集算法

六、优化内存的良好编码习惯

1.数据类型：不要使用比需求更占空间的基本数据类型
2.循环尽量用foreach，少用iterator，自动装箱尽量少用
3.数据结构与算法的解度处理
   3.1.数组，链表，栈，树，图。。。。。。
   3.2.数据量千级以内可以使用Sparse数组(key为整数)，ArrayMap（key为对象）性能不如HashMap但节约内存
4.枚举优化
   缺点:
         4.1、每一个枚举值都是一个单例对象,在使用它时会增加额外的内存消耗,所以枚举相比与 Integer 和 String 会占用更多的内存
         4.2、每一个枚举值都是一个单例对象,在使用它时会增加额外的内存消耗,所以枚举相比与 Integer 和 String 会占用更多的内存
         4.3、较多的使用 Enum 会增加 DEX 文件的大小,会造成运行时更多的IO开销,使我们的应用需要更多的空间
         4.4、特别是分dex多的大型APP，枚举的初始化很容易导致ANR

  枚举可以进行改进：
           public enum SHAPE{
                   RECTANGLE,
                   TRIANGLE,
                   SQUARE,
                   CIRCLE
            }
           public class SHAPE{
              public static final int RECTANGLE=0;
              public static final int TRIANGLE=1;
              public static final int SQUARE=2;
              public static final int CIRCLE=3;
           }
5、static   staticfinal的问题
                   static会由编译器调用clinit方法进行初始化
                   static final不需要进行初始化工作，打包在dex文件中可以直接调用，并不会在类初始化申请内存
                   所以基本数据类型的成员，可以全写成static final
6、字符串的连接尽量少用加号(+)
7、重复申请内存的问题：同一个方法多次调用，如递归函数 ，回调函数中new对象,读流直接在循环中new对象等；不要在onMeause()  onLayout() onDraw()  中去刷新UI（requestLayout）
8、避免GC回收将来要重用的对象：内存设计模式对象沲+LRU算法
9、Activity组件泄漏
     9.1、非业务需要不要把activity的上下文做参数传递，可以传递application的上下文
     9.2、和Activity有关联的对象写成static   如private static Button btn;   private static Drawable drawable;
     9.3、非静态内部类和匿名内部内会持有activity引用,建议单独写一个文件并且传入的activity用WeakReference来处理activity应用
     9.4、单例模式持有activity引用
     9.5、handler.postDelayed()问题：
             a、如果开启的线程需要传入参数，用弱引接收可解决问题；
             b、handler记得清除removeCallbacksAndMessages(null)
10、尽量使用IntentService,而不是Service