Android应用性能优化01

Android应用性能优化

内存的优化

---

垃圾回收及内存调试工具的介绍

概要：

　　Android的Generational Heap Memory模型和几个内存调试工具：Memory Monitor、Allocation Tracker、Heap Viewer

　　Android性能优化典范：http://android.jobbole.com/80611/
　　此链接是根据谷歌官方推出的翻译总结版本，实在是强大。

---

Android的垃圾回收机制

　　java拥有一个方便的GC机制，让开发人员从繁重的对象分配回收工作中解放出来，专心于代码的高级实现。

　　Android相对原始JVM的GC机制进行了大幅优化，其内置了一个三级Generation的内存模型，最近分配的对象会存放在Young Generation（年轻代）区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到Old Generation（老年代），最后到Permanent Generation（永久代）区域。

　　每一个级别的内存区域都有固定的大小，此后不断有新的对象被分配到此区域，当这些对象总的大小快达到这一级别内存区域的阀值时，会触发GC的操作，以便腾出空间来存放其他新的对象。比如在Young Generation区中：

• 大多数新建的对象都位于Eden区。
• 当Eden区被对象填满时，就会执行Minor GC。并把所有存活下来的对象转移到其中一个survivor区。
• Minor GC同样会检查存活下来的对象，并把它们转移到另一个survivor区。这样在一段时间内，总会有一个空的survivor区。

内存泄漏

　　内存泄漏指的是那些程序不再使用的对象无法被GC识别，这样就导致这个对象一直留在内存当中，占用了宝贵的内存空间。显然，这还使得每级Generation的内存区域可用空间变小，GC就会更容易被触发，从而引起性能问题。

GC导致的性能问题

　　在GC操作中，所有的线程都会被暂停，而GC的处理时间随着Generation的老化而加长。

　　比如大量内存泄露导致Permanent Generation被占满，从而在此处进行了频繁的GC操作，并且此处的GC操作是相当费时的，显然会导致程序的其它命令无法顺利执行，最典型的表现为UI卡顿。

　　再比如在for循环中瞬间新建了大量对象，常常会导致Memory Churn（内存抖动），瞬间产生大量的对象会严重占用Young Generation的内存区域，当达到阀值，剩余空间不够的时候，也会触发GC。

　　内存抖动

为什么感受到了UI卡顿

　　来来来，动画专业的我给你们介绍下不同帧率对视觉的直观感受

　　帧率（FPS），全称Frames Per Second，我们制作3D动画一般30FPS足矣，电视剧25FPS，电影24FPS（所以以前有本杂志叫24格）。当然这些都是因为制作成本关系才保持在如此的帧率下，人眼最高能分辨的帧率大致在60FPS左右，这种顺滑如丝的视觉感受显然是人人都想要追求的，咱们程序员也一直为了这几帧的优化而愁眉苦脸。

　　要想达到每秒60帧，这意味着每一帧你只有16ms=1000/60的时间来处理所有的任务。并且Android也确实会每16ms自动刷新界面，如果没刷新，跳过了几帧，大多数可能是性能优化不够。

　　再科普下一个钟摆动画的制作

　　这段小动画里包含了动画原理中的“慢入“和”慢出”，按照12FPS的帧率将1-9这几个画面依次显示，并循环往复播放，即会出现一个可爱的钟摆动画，如果我们在每两张的中间插入一张“中间张”，并且以24FPS播放，即会出现一个更流畅的动画效果。

　　咳咳，扯多了。

---

内存诊断工具

1.Memory Monitor

一张图显示了前3个工具

　　此界面就是Memory Monitor，在常用的logcat边上，很多人早就接触到了这个工具，可以很方便地发现运行过程中的性能问题，比如内存抖动，比如CPU占用过多，比如网络链接频繁耗费流量等等。
　　
　　点击Initiate GC按钮后，即可手动启动垃圾回收操作。

2.Allocation Tracker

点击Start Allocation Tracking按钮后，经过一段想要记录的时间后，再次点击，即可生成一份alloc结尾的文件，此处我查看了自己的应用这个时间段产生的各种类的实例，点击Jump to Source，会跳转到对象所产生的类，而点击右侧圆形按钮，则会出现圆盘状图显示各个类的层级关系与所占大小。

3.Heap Viewer

　　Heap Viewer工具给我们提供了内存快照的功能，在手动GC之前进行快照，手动GC之后进行快照，如果发现该被回收的对象并没有被回收，那就是发生了内存泄漏，需要进行debug。
　　

4.LeakCanary

　　这个第三方工具，真是强大，只要稍加配置即可在手机中实时提示出现的内存泄漏现象。
　　github地址：leakcanary
　　6.0以上的虚拟机需要使用github中的最新版本。

　　
　　出现了内存泄漏就会在通知栏上显示这些
　　我们的MainActivity中的消息队列引用了此活动，导致活动不能被回收，于是内存泄漏了。
　　

---

实际操作

　　使用上文提到的工具，针对一个存在内存泄漏的工程下载地址，进行修改操作。
　　
　　开始分析：
　　1.首先打开AndroidManifest.xml文件，如图：

　　可以看到程序的主入口点是MainActivity，按住ctrl+鼠标左键直接点进去查看MainActivity的内容：
　　

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

 private static TextView sTextView;
 private Button mStartBButton;
 private Button mStartAllocationButton;

 Handler mHandler = new Handler(new Handler.Callback() {
     @Override
     public boolean handleMessage(Message msg) {
         return false;
     }
 });

 @Override
 protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_main);

     sTextView = (TextView) findViewById(R.id.tv_text);
     sTextView.setText("Hello World!");

     mStartBButton = (Button) findViewById(R.id.btn_start_b);
     mStartBButton.setOnClickListener(this);

     mStartAllocationButton = (Button) findViewById(R.id.btn_allocation);
     mStartAllocationButton.setOnClickListener(this);
 }

 @Override
 public void onClick(View v) {
     switch (v.getId()) {
         case R.id.btn_start_b:
             startB();
             break;
         case R.id.btn_allocation:
             startAllocationLargeNumbersOfObjects();
             break;
     }
 }

 private void startB() {
     finish();
     startActivity(new Intent(this, ActivityB.class));
     mHandler.postDelayed(new Runnable() {
         @Override
         public void run() {
             System.out.println("post delayed may leak");
         }
     }, 5000);
     Toast.makeText(this, "请注意查看通知栏LeakMemory", Toast.LENGTH_SHORT).show();
 }

 private void startAllocationLargeNumbersOfObjects() {
     Toast.makeText(this, "请注意查看MemoryMonitor 以及AllocationTracker", Toast.LENGTH_SHORT).show();
     for (int i = 0; i < 10000; i++) {
         Rect rect = new Rect(0, 0, 100, 100);
         System.out.println("-------: " + rect.width());
     }
 }

　　通过查看onClick的代码知道了程序的运行逻辑，startB()是开启一个新的Activity，startAllocationLargeNumbersOfObjects()是进行大量对象的创建，现在可以先运行一下程序查看运行效果，再配合工具进行分析了。
　　
　　2.运行模拟器，效果展示如下：
　　
　　
　　
　　看上去好像没什么问题，现在先来测试一下STARTACTIVITYB，看看点击之后会出现什么情况。
　　
　　通知栏里提示MainActivity已经发生了泄漏，我们点击进去查看详情会发现由于static类型的sTextView引用了mContext导致了MainActivity发生了内存泄漏，这就是LeakCanary工具的方便之处，直接把发生内存泄漏的地方明确的告诉你了，既然已经发现了一个内存泄漏的地方，我们先把它修复了再继续优化。
　　
　　回到代码，怎么修改呢？既然static有问题，那就直接把static去掉就好了，把sTextView变成非静态的，同时把sTextView改成mTextView，看上去一切好像都是那么简单，借助LeakCanary一切都变简单了，这就是工具带给我们的便利，但是这里面还存在一个不易被发现的内存泄漏行为：
　　

mHandler.postDelayed(new Runnable() {
         @Override
         public void run() {
             System.out.println("post delayed may leak");
         }
     }, 5000);

　　这里开启了一个延时的线程，5000ms似乎没有问题，LeakCanary也没有提示，把5000换成20000呢？事实证明会有如下的提示：

　　看提示似乎是由于匿名接口Runnable持有了对当前Activity的引用，那我们需要对Runnable和Handler同时进行修改，这时候我们要使用WeakReference来对代码进行修改，即实现弱引用，保证可以引用的对象可以被及时垃圾回收。
　　
　　直接在MainActivity中加入如下的代码：

public static final String POST="post delayed may leak";

public static class MyRunnable implements Runnable{
        WeakReference<MainActivity> mWeakReference;

        public MyRunnable(MainActivity activity) {
            mWeakReference = new WeakReference<MainActivity>(activity);
        }

        @Override
        public void run() {
            System.out.println(POST);
        }
    }

public static class MyHandler extends Handler{
        WeakReference<MainActivity> mWeakReference;

        public MyHandler (MainActivity activity){
            mWeakReference = new WeakReference<MainActivity>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    }

　　在MainActivity成员变量中添加：

public static final String WATCH="请注意查看通知栏LeakMemory";
private MyRunnable mRunnable;
private MyHandler mHandler;

　　修改StartB方法中删除原来的延时线程操作，加入如下代码：

mHandler = new MyHandler(MainActivity.this);
mMyRunnable=new MyRunnable(MainActivity.this);
mHandler.postDelayed(mMyRunnable,20000);
Toast.makeText(this, WATCH, Toast.LENGTH_SHORT).show();

　　重新运行，这次没有任何内存泄漏的提示了，看来由匿名内部类和Handler引起的内存泄漏问题解决了，我们接下来继续分析看看这个项目还存在什么问题。
　　
　　首先打开Monitor，再连续点击StartAllocation，会出现出现内存抖动现象，这个需要我们来处理一下。

　　使用Allocation Tracking工具进行分析抖动的位置，在内存抖动开始时点击按钮，在抖动结束后再点击一下结束探测。
　　

　　把Activity展开后会发现进行很多Rect和StringBuilder对象的创建，看来这就是问题所在。

private void startAllocationLargeNumbersOfObjects() {
        Toast.makeText(this, "请注意查看MemoryMonitor 以及AllocationTracker", Toast.LENGTH_SHORT).show();
        for (int i = 0; i < 10000; i++) {
            Rect rect = new Rect(0, 0, 100, 100);
            System.out.println("-------: " + rect.width());
        }

　　在for循环中一直在创建对象及字符串的拼接，改进方案是把Rect对象的创建放到成员变量中在onCreate中进行初始化，为了避免在logcat输出时产生大量的String对象，改进方案是在onCreate中把String对象创建好，这样就不会重复创建了，还要把里面的字符串提取出来，放到strings.xml中，有的要设置为static final类型的字符串资源，还有一点就是Toast的弹出过于频繁，可以对其弹出速度进行限制，不过这里就不做处理了，这个地方的问题基本上解决了，修改代码如下：

　　成员变量

    public static final String WATCHAGAIN="请注意查看MemoryMonitor 以及AllocationTracker";
    public Rect mRect;
    public StringBuilder mStringBuilder;

　　OnCreate

        mRect = new Rect(0, 0, 100, 100);
        mStringBuilder = new StringBuilder("-------: " + mRect.width());

　　startAllocationLargeNumbersOfObjects

private void startAllocationLargeNumbersOfObjects() {
        Toast.makeText(this, WATCHAGAIN, Toast.LENGTH_SHORT).show();
        for (int i = 0; i < 10000; i++) {
            System.out.println(mStringBuilder);
        }
    }

下面来寻找这个项目中最后的问题，由于在MainActivity的布局文件中使用了自定义的View，所以最后看看自定义View有没有什么问题：

　　MyView.java

智能的Android Studio已经发现了问题，不要在onDraw中创建对象，看来和上面的问题差不多嘛，修改如下：

　　成员变量

    private RectF rect = new RectF(0, 0, 100, 100);
    private Paint paint = new Paint();

把下面之前定义的删除即可，同时记得把变量名称修改，大功告成，所有的问题都解决了。