嗯。这是一个很大的课题，也有很多人在讲。最近几年接触的较多的一个领域，整理成文，方便自己复盘相关知识，也分享给需要的朋友。

从维度上来划分，可以将Andorid客户端涉及到的性能点分为如下图所示的几个方向，每个方向涉及到性能数据采集、数据分析、以及优化方案几个方面。系列文章将以每个性能维度为单位，介绍性能测试工具的使用以及其底层实现原理、如何进行针对性的性能优化、一些经典案例以及最佳实践。

Android性能维度.png

内存

工具篇

工欲善其事必先利其器

开篇将首先介绍如何分析内存问题。内存分析分为2个方向，包括内存泄漏的排查以及客户端占用内存资源大小。排查内存泄漏一般会用到如下几个工具：
1.DDMS
2.MAT
3.LeakCanary
4.自研内存资源监控工具
DDMS是android sdk提供的内存监控工具，可以在sdk的tools目录中找到。使用DDMS可以实时的看到应用进程对应的heap size以及对象数量等内存占用细节，同时DDMS可以方便的dump出内存的hprof文件以用于进一步的内存分析。
打开tools下的ddms.bat，可以看到debug模式下应用的进程列表，检测应用是否存在内存泄漏一般的操作步骤：
1）选中进程，点击图中3对应的按钮做GC操作;
2）点击同种1对应的按钮，此时DDMS会帮我们收集应用的内存信息；
3）在DDMS的右侧面板可以实时看到VM heap对应的情况；
4）执行几次GC操作，如果heap size持续增长，则说明有内存泄漏的风险，此时可以dump 出hprof文件做进一步分析；
5）点击2对应的按钮，dump出内存hprof文件。

DDMS.png

借助DDMS可以初步观察到应用进程对应的内存情况，但要进一步确定是否是内存泄漏，需要借助另一个内存分析利器MAT（ eclipse memory analyzer ）。MAT分为独立版以及AndroidStudio的内嵌版本，独立版本的MAT有更完备的功能，一般推荐使用独立版MAT分析内存泄漏问题。

Stand-alone MAT.png

DDMS dump出的hprof文件并不能被MAT直接识别，需要利用sdk里platform-tools文件夹下的hprof-conv工具做一次转换：

hprof-conv.png

转换后的result.hprof文件就能够被MAT打开了。

MAT.png

圆形比例图中列出了应用的内存占用情况，一般来说，主要有3个大户

android.content.res.Resources

指的是应用的res资源，主要是图片，可以通过对图片压缩来降低资源占用，无alpha通道的图片推荐使用jpg图片，有alpha通道的图片使用png并借助pngquant压缩工具对其进行无损压缩（pngquant — lossy PNG compressor）

android.graphics.Bitmap

Bitmap是占用内存的大户，对不用的Bitmap一定要手动释放掉。

Remainder

应用的heap可分配的内存，如果Remainder很少，则需要考虑对应用内存进一步优化了。

Histogram可以查看内存中实例的数量以及占用内存的大小。

Histogram.png

关于Shallow Heap以及Retained Heap的概念，可以参考这篇博文，有详细讲解（ http://bjyzxxds.iteye.com/blog/1532937），

Shallow Size 对象自身占用的内存大小，不包括它引用的对象。针对非数组类型的对象，它的大小就是对象与它所有的成员变量大小的总和。当然这里面还会包括一些java语言特性的数据存储单元。针对数组类型的对象，它的大小是数组元素对象的大小总和。
Retained Size Retained Size=当前对象大小+当前对象可直接或间接引用到的对象的大小总和。(间接引用的含义：A->B->C, C就是间接引用) 换句话说，Retained Size就是当前对象被GC后，从Heap上总共能释放掉的内存。不过，释放的时候还要排除被GC Roots直接或间接引用的对象。他们暂时不会被被当做Garbage。

Dominator Tree按照占用内存由大到小的顺序列举了对象列表情况。

Dominator Tree.png

右击选择“Path To GC Roots--->exclude weak/soft references”来查看对象到达GC Roots的路径，需要排除掉软引用以及弱引用，因为软引用以及弱引用是可以被直接GC掉的。借助引用路径去排查是否存在静态对象hold住对象导致的内存泄漏问题。

LeakCanary是通过代码集成到项目中用于检测内存泄漏的第三方库，关于LeakCanary的介绍这里不做过多的阐述了，更多详细信息可以参考Github上的wiki（FAQ · square/leakcanary Wiki · GitHub）

内存扩展知识

对内存的优化遵循性能优化的基本套路，即性能数据采集-->分析-->优化。诸如BAT等大厂，一般都有团队自研的内存监控工具，开发这些监控工具用于Android性能优化的第一个环节，即数据采集阶段。监控工具可以是PC端的，也可以是一个App，PC端工具的优势在于不会影响到被测应用的运行环境，非注入式的监控。本文介绍下PC端监控内存工具的底层实现原理。

关于PSS 、USS、RSS、VSS

VSS- Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS- Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS- Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS- Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

这样说可能还是一脸懵逼，举个例子：对于一个app应用而言，USS对应着应用退出后会被释放的内存部分；RSS对应着该应用占用的物理内存+共享库占用的内存；PSS只计算了共享库的一定比例部分，比如：3个进程公用一个共享库（30KB），则每一个进程只算10KB到PSS中，当这个进程被Kill之后，10KB再平分给剩下的2个进程。这三个指标也是内存统计的关键指标。

在Android底层文件系统中会保存着进程对应的的PSS、USS、RSS信息，可以通过adb命令去获取基本的内存数据，经过简单的数据处理得到对应的PSS、USS、RSS数据。（前提是需要完全Root后的机器）

adb命令：adb shell cat /proc/process-id/smaps ，文件以page为单位去呈现Pss，Uss，RSS

以weex开源项目为例，详细操作路径如下：
1，通过包名获取进程的pid

获取包名对应的pid.png

2，通过pid读取对应的内存smap源数据

获取smaps内存信息.png

会得到对应的smap内存信息，一系列的如下图所示的page块：

smaps内存数据.png

那么如何从这些数据中得到app对应的PSS、RSS、USS数据呢，可以参照下面的计算公式：
RSS = Shared_Clean + Shared_Dirty+Private_Clean + Private_Dirty
PSS = Private_Clean + Private_Dirty+ Shared part / process num
USS = Private_Clean + Private_Dirty
通过上面的计算公式，对adb获取到的smaps数据的处理，从而得到app占用的内存的详细信息。其实大多PC端的内存监控都是遵循上述的原理，无外乎通过不同的脚本语言去做这样的事，例如你可以用Python去获取数据，上层通过C#做一个界面。

最佳实践

“A small leak will sink a great ship.” - Benjamin Franklin

内存泄漏准确的说不属于优化的范畴，是必须要解决的问题，否则OOM将会霸占你的Crash上报平台。在过往的开发经历中，也尝试去总结一些最佳实践，来防止内存泄漏的问题出现。

1.设置了监听器，退出后没有反注册
很好解决，在activity退出时记得removeListener即可；

2.内部类导致的内存泄漏
内部类经常涉及到需要访问外部类的对象，通过该对象引用外部类的属性或者方法，当该内部类被一个长生命周期的实例引用时，就会导致外部类也无法释放，这是导致内存泄漏的最主要原因。
由于内部类导致的内存泄漏有一套通用的解决方案：对外部类的对象使用弱引用，内部类static化。

public class MainActivity extends AppCompatActivity {   
 @Override   
 protected void onCreate(Bundle savedInstanceState) {  
      super.onCreate(savedInstanceState);      
      setContentView(R.layout.activity_main);    
  }    

 static class A {      
      WeakReference reference;       
      public A(MainActivity ref){        
          reference = new WeakReference(ref);     
      }      
      public void test(){            
          MainActivity activity = reference.get();          
          if(activity == null){            
                 return;          
          }      
      }   
  }
}

3.Dialog依附的Activity销毁了，但是忘记做dialog的dismiss操作。
记得在退出时，把依附于该Activity的Dialog销毁。

4.Webview导致的内存泄漏
在一些机型上会出现Webview相关的泄漏，即使调用webview的destroy也无法销毁，可以将webview相关的业务移至另一个进程，通过aidl完成通讯。其实这种新开进程的方案也适用于那些相对独立，并且需要耗费大内存的业务。

5.Handler导致的泄漏
-1：泄漏的路径为：Thread->Looper->MessageQueue -> Message ->handler->Activity
定义的Runnable对象会间接地引用定义它的Activity对象，而它会被提交到Handler的MessageQueue中，如果它在Activity销毁时还没有被处理，那就会导致内存泄漏了。
解决办法是：退出时remove掉消息队列中的message或者Runnable。
-2：泄漏路径为：Thread->Looper->MessageQueue ->mIdleHandlers ->handler->Activity
解决办法是：UI退出时主动调用 removeIdleHandler。

关于内存优化，其实远不止这些内容，更多内容后面再慢慢整理吧。本文简单介绍了下内存相关内容，后面有空会对其他性能优化的点做一些总结。

2016/12/6 于杭州

Android性能优化-工具原理、优化方法、最佳实践

内存

工具篇