Android开发艺术探索——第十五章：Android性能优化

这一章所介绍的是Android的性能优化方法和程序设计的一些思想，通过本章的内容，读者可以快速的掌握性能优化的方法

性能优化的一个很重要的问题就是内存泄漏，内存泄漏并不会导致程序功能异常，但是会导致你的应用内存暂用过大，而且比较难发现，所以一般会借助一些功能，所以我们会讲MAT的使用

在做程序设计的时候，除了要完成功能开发，提高程序的性能意外，还有一个就是代码的可维护性和可扩展，如果这个程序的维护和扩展性比较差，那就意味着后面的代码维护代价相当大，比如需要对某一个功能做调整，这可能会出现牵一发而动全身，另外添加新功能的时候也无从下手，看起来是一个很抽象的问题，但是它并不抽象，他可以通过一些合理的设计去完成。

一.Android的性能优化方法

主要介绍一下布局优化，绘制优化，内存泄漏优化，响应速度优化，ListView优化，Bitmap优化，线程优化以及性能建议

1.布局优化

布局优化的思路很简单，就是减少布局成熟，这就意味着绘制的工作少了，那么程序的性能自然就高了

如何进行布局优化，首先删除布局中的无用控件，其次选择性能较低的ViewGroup,比如RelativeLayout,如果布局中既可以使用LinearLayout,也可以使用RelativeLayout，那就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，他的布局需要花费CPU更多的时间，FrameLayout和LinearLayout一样都是简单高效的容器。

布局优化还有另外一种手段就是标签，标签和ViewStub,标签主要用于布局重用，标签一般是配置使用，它降低减少布局的层级，而ViewStub则提供了按需加载的功能

< include >标签

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <include layout="@layout/include_main_test"/>

</LinearLayout>

上面的带中，@layout/include_main_test就是指定了另外一个布局，通过这种方式不用把这个布局的内容重写，这就是的好处，< include >标签只支持android:layout开头的属性，比如高宽，其他的属性是不支持的，比如android:backgroup，当然id这个属性是个特例，如果< include >指定了这个id属性，同时被包含的不文件的根目录也指定了id属性，那么< include >指定的id属性为准，需要注意的是，如果< include >标签指定了一些属性，那么高宽是必须存在的

< merge >标签

< merge >标签一般和< include >一起使用从而减少布局的层级，比如上面的布局是一个竖直的线性布局，那么显然被包含的线性布局是多余的，通过
< merge >标签就可以去掉对于的一层线性布局。

<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="我是include_main_test" />

</merge>

ViewStub

ViewStub继承View,他非常轻量级且高宽都是0，因此它本身不参与任何的布局和绘制过程，ViewStub的意义在于按需加载所需的布局文件，在实际的开发中很多布局文件在正常的情况下不会显示，比如网络异常时的界面，这个时候没必要初始化的时候就加载，通过ViewStub就可以做到使用的时候加载

    <ViewStub
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout="@layout/include_main_test"
        android:inflatedId="@id/ll_include"
        android:id="@+id/stud_import"
        />

其中inflatedId加载的是 android:layout=”@layout/include_main_test”根布局的id，如何做到按需加载呢？可以按照下面的两种方式：

        findViewById(R.id.stud_import).setVisibility(View.VISIBLE);
        //
        ((ViewStub)findViewById(R.id.stud_import)).inflate()

当ViewStub通过setVisibility或者inflate方式加载后，ViewStub就会被他内部的布局替换掉，这个时候ViewStub就不再是布局结构的一部分了，目前ViewStub还不支持< merge >标签

2.绘制优化

绘制优化是指View的onDraw方法要避免执行大量的操作，这主要体现在两个方法

首先，onDraw中不要创建新的布局对象，这是因为onDraw方法可能会被频繁的调用，这样就会瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁的gc，降低了程序的执行效率。

另一方面呢，onDraw方法中不要做耗时的任务，也不能执行很多次的循环操作，尽管循环是很轻量级的，但是大量的循环仍然十分抢占CPU的时间片，这回造成View的绘制过程不流畅，按照Google官方的性能规范，view的绘制要保证60fps是最佳的，这就要求绘制时间不能超过16ms（16ns = 1000/60）

3.内存泄漏优化

内存泄漏在开发过程中需要很重视，但是由于内存泄漏问题对于开发者的经验和开发意思较强的要求，因此这也是开发人员最容易犯的错误之一，内存泄漏的优化分两个方面，一方面是在开发过程中避免写出内存泄露的代码，另一方面是通过一些分析工具比如MAT来找出潜在的问题

场景1 静态变量导致的内存泄漏

下面这种就是最简单的内存泄漏

Activity无法正常销毁，因为静态变量context引用了它

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainActivity";
    //内存泄漏
    private static Context mContext;

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

上面的代码也可以改造一下，mView是一个静态变量，他的内部持有了当前的Activity，所以Activity仍然无法释放

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainActivity";
    //内存泄漏
    private static View mView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mView = new View(this);
    }
}

场景2 单例模式导致的内存泄漏

静态变量导致的内存泄漏都太过于明显，相信读者都不会犯，而单例模式带来的就很容易忽视

public class TestManager {

    private List<OnDataArrivedListener> mOnDataArrivedListener = new ArrayList<OnDataArrivedListener>();

    private static class SingleHolder {
        public static final TestManager INSTANCE = new TestManager();
    }

    private TestManager() {

    }

    public static TestManager getInstance() {
        return SingleHolder.INSTANCE;
    }

    public synchronized void registerListener(OnDataArrivedListener listener) {
        if (mOnDataArrivedListener.contains(listener)) {
            mOnDataArrivedListener.add(listener);
        }
    }

    public synchronized void unregisterListener(OnDataArrivedListener listener) {
        mOnDataArrivedListener.remove(listener);
    }

    public interface OnDataArrivedListener {
        public void onDataArrived(Object data);
    }
}

接下来让Activity实现OnDataArrivedListener接口并向TestManager注册监听，如下所示，下面的代码由于缺少解注册的操作会引发内存泄漏，泄漏的原因是Activity的对象被单例模式的TestManager所持有，而单例模式的特点是生命周期和Application保持一致，所以Activity无法被释放

场景3：属性动画所导致的内存泄漏

从Android3.0开始，Google就提供了属性动画，属性动画中有一类无限循环的动画，如果在 Activity中播放此类动画且没有在 onDestroy中去停止动画，那么动画会一直播放下去，尽管已经无法在界面上看到动画效果了，并且这个时候 Activity的View会被动画持有，而View又持有了Activity，最终Activity无法释放。下面的动动画是无限动画，会泄露当前Activity，解决方法是在 Activity的 onDestroy中调用 animator. cancel来停止动画。

public class MainActivity extends AppCompatActivity  {

    private Button mButton;

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

        mButton = (Button) findViewById(R.id.mButton);
        ObjectAnimator animator = ObjectAnimator.ofFloat(mButton,"rotation",0,360).setDuration(2000);
        animator.setRepeatCount(ValueAnimator.INFINITE);
        animator.start();
        //animator.cancel();
    }
}

4.响应速度优化和ANR日志分析

响应速度优化的核心思想是避免在主线程中做耗时操作，但是有时候的确有很多耗时如果在开发过程中遇到了ANR，那么怎么定位问题呢?其实当一个进程发生ANR了以后。响应速度过慢更多地体现在Activity的启动速度上面，如果在主线程中做太多事情会导致Activity启动时出现黑屏现象，甚至出现ANR，Android规定，Activity如果5秒钟之内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR。系统会在 data/anr目录下创建一个文件 traces.txt，通过分析这个文件就能定位出ANR的原 10秒钟之内还未执行完操作也会出现ANR。下面模拟一个ANR的场景。下面的代码在 Activity的 oncreate中休眠30s，程序运行

public class MainActivity extends AppCompatActivity  {

    private Button mButton;

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

        SystemClock.sleep(30 * 1000);
    }
}

这里假定我们无法从代码中看出ANR，所以我们要看下traces文件，太长了就不贴出来了。路径在data/anr/traces.txt

5.ListView和Bitmap优化

ListView在12章就已经说过了，这里简单回顾一下，主要分为三个方面，采用ViewHolder并避免在getView中执行耗时操作，其次是根据列表的滑动状态来控制任务的执行频率，比如列表快速滑动的时候显然不太适合开启大量的异步任务，最后可以尝试开启硬件加速来使listview更加流畅

Bitmap也是同样说过，主要是裁剪，inSampleSzie参数，这里就不重复了

6.线程优化

采用线程池，避免存在大量的Thread，线程池可以重用内部的线程从而避免很多不必要的性能开销

7.一些性能的建议

避免创建过多的对象
不要过多使用枚举，枚举暂用的空间要比整型大
常量请使用static final来修饰
使用一些Android特有的数据结构，比如SparseArray和Pair等，他们都具有更好的性能
适当使用软引用和弱引用
采用内存缓存和磁盘缓存
尽量采用静态内部类，这样避免潜在的由于内部类导致的内存泄漏

二.内存泄漏分析之MAT工具

MTA的全称Eclipse Memory Analyzer

这里就不多说了，大家可以去搜索一下有关于MTA很多用法

三.提高程序的可维护性

本节所讲述的内容是 Android的程序设计思想，主自是如何提高代码的可维护性和可扩展性，而程序的可维护性本质上也包含可扩展性。本节的切入点为:代码风格、代码的层次性和单一职责原则、面向扩展编程程以及设计模式，下面围绕着它们分别展开。

可读性是代码可维护性的前提，一段别人很难读懂的代码的可维护性显然是极差的。而良好的代码风格在一定程度上可以提高程序的可读性。代码风格包含很多方面，比如命名规范、代码的排版以及是否写注释等。到底什么样的代码风格是良好的?这是个仁者见仁的问题，下面是笔者的一些看法

(1)命名要规范，要能正确地传达出变量或者方法的含义，少用缩写，关于变量的前缀可以参考Android源码的命名名方式式、比如私有成员以m开头，静态成员以s开头，常量则全部用大写字母表示，等等
(2)代码的排版上需要留出合理的空白来区分不同的代码块，其中同类变量的声明要放在一组，两类变量之间要留出一行空白作为区分
(3)仅为非常关键的代码添加注释，其他地方不写注释，这就对变量和方法的命名风格提出了很高的要求，一个合理的命名风格可以让读者阅读源码就像在阅读注释一样，因此根本不需要为代码额外写注释

代码的层次性是指代码要有分层的概念，对于一段业务逻辑，不要试图在一个方法或者一个类中去全部实现，而要将它分成几个子逻辑，然后每个子逻辑做自己的事情，这样既显得代码层次分明，又可以分解任务从而实现简化逻辑的效果。单一职责是和层次性相关联的，代码分层以后，每一层仅仅关注少量的逻辑，这样就做到了单一职责。代码的层次性和单一职责原则可以以公司的组织结构为例来说明，比如现在有一个复杂的需求来到了部门经理面前，如果部门经理需要给每个员工来安排具体的任务，那显然他会显得很累，因为他必须要了解每个员工的工作并最终收集每个员工的完成情况况，这个时候整个工作过程就缺少了层次性，并且也违背了单一职责的原则，毕竟经理的主要工作是管理团队而不是给员工安排任务。如果采用分层的思想要怎么做呢?首先经理可以将复杂的任务分成若千份，每一份交给一个主管处理，然后剩下的事情经理就不用管了，他只需要管理主管即可。对于主管来说，分配给他的任务相对于整个任务就简单了不少，这个时候他再拆解任
务给组员，这个时候真正到达组员手里的任务其实就没有那么复杂了，这其实类似于分治策略。这样一来整整个工作过程就具有了三层的结构，并且每一层有不同的职责，一且出现了错误也可以很方便地定位到具体的地方。

程序的扩展性标志着开发人员是否有足够的经验，很多时候在开发过程中我们无法保证已经做好的需求不在后面的版本发生变更，因此在写程序的过程中要时刻考虑到扩展考虑着如果这个逻辑后面发生了改变那么需要做哪些修改，以及怎么样才能降低修改的工作量，面向扩展编程会使程序具有很好的扩展性。

恰当地使用设计模式可以提高代码的可维护性和可扩展性，但是Android程序容易有性能瓶颈，因此要控制设计的度，设计不能太牵强，否则就是过度设计了。常见的设计模式有很多，比如单例模式、工厂模式以及观察者模式等，由于本书不是专门介绍设计模式的书，因此这里就不对设计模式进行详细的介绍了，读者可以参看(大话设计模式》和《Android源码设计模式解析与实战》这两本书，另外设计模式需要理解后灵活运用才能发挥更好的作用。

The End!

全书完！！！