前言

本文将会介绍一些Android的性能优化的方法，主要内容包括布局优化、绘制优化、内存泄露、响应速度优化、ListView优化、Bitmap优化、线程优化以及一些性能优化的建议。

布局优化

不具优化的思想很简单，就是尽量减少布局文件的层级，这个道理是很简单的，布局中的层级少了，这就意味着Android绘制时的工作量减少了，那么程序的性能自然就提高了。

那么如何进行布局优化了，首先就是删除那些无用的控件很层级，其次有选择性的是有那些性能比较低的ViewGroup，比如RelativeLayout、如果布局中RelativeLayout也可以被替换成LinearLayout的话，那就使用LinearLayout。这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间，FrameLayout和LinearLayout都是一种简单高效的ViewGroup，因此可以考虑使用它们。但是有很多时候单纯通过一个LinearLayout或者FrameLayout是无法实现想要的效果的，需要通过多层嵌套的方式来完成，这种情况下还是建议采用RelativeLayout。因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。

布局优化的另外一种采用标签、标签和ViewStub。标签主要用于布局重用，标签一般配合标签来使用，它可以降低减少布局的层级，而ViewStub控件则提供了按需加载的功能。当需要的时候才会将ViewStub中的布局加载到内存，这提高了程序的初始化效率。

通过标签可以指定一个布局文件，这样就可以不用重复把这个布局的内容在输入一遍了，在你想要使用的layout文件里面就可以直接使用了。标签一般和标签一起使用来减少布局的层级，比如说当前布局已经是一个竖直方向的LinearLayout，而这个时候如果被包含的布局文件中也采用了竖直方向的LinearLayout，那么显现这个LinearLayout是多余的，通过标签就可以去掉这个多余的层级了。

接下来来讲解一下ViewStub，它继承了View，它非常轻量级，宽和高都是0，因此它本身不参与任何的布局和绘制过程。ViewStub的意义在于按需加载所需要的布局文件，在实际开发中，有很多布局在正常情况下是不会心事的，比如网络异常时的界面，这个时候就没有必要在这边改革界面初始化的时候将其加载进来，而通过ViewStub就可以做到在使用的时候再加载，提高了程序初始化的性能。

// 在布局文件中，你就当做普通 View 使用即可


    

    



//两种加载方式
findViewById(R.id.vs).setVisibility(View.VISIBLE);

View view = (findViewById(R.id.vs).inflate());

绘制优化

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

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

另一方面，onDraw方法中不要做耗时的任务，也不能执行成千上万次的循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占CPU的时间片，者会造成View的绘制过程不流畅，按照Google官方给出的行优化典范中的标准，View的绘制帧率保证60fps是最佳的，这就要求每帧的绘制时间不操作16ms（16ms = 1000 / 60），虽然程序很难保证这个事件，尽量降低onDraw方法的复杂度是切实有效的。

内存泄露优化

内存泄露在开发过冲中是一个需要重视的问题，但是由于内存泄露问题对开发人员的经验和开发意识有较高的要求，因为这也是最容易犯的错误之一，内存泄漏的优化分为两个方面，一方面是在开发过程中避免写出有内存泄露的代码，另一方面就是通过一些分析工具比如MAT来找出潜在的内存泄露继而解决，这里主要介绍下在开发过程中有可能会出现内存泄漏的几个场景。

静态变量导致的内存泄露

//场景1
public class MainActivity extends AppCompatActivity {

    private  static Context context;


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

//场景2
public class MainActivity extends AppCompatActivity {

    private  static View view;


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

代码很简单，因为是一个静态变量，而且内部持有了Activity，所以会导致Activity无法释放，就会造成内存泄漏了。

单例模式导致的内存泄露

单例模式一般引起内存泄露的原因单例模式的对象持有对Activity的引用，而单例模式的特点就是其生命周期和Application是保持一致的，因为这个特点，所以会导致Activity对象无法被及时的释放，从而导致内存泄露。

属性动画导致的内存泄露

从Android 3.0开始，Google提供了属性动画，属性动画中有一类是无限循环的动画，如果在Activity中播放此类动画且没有在onDestroy()中去停止动画，那么动画将会一直播放下去，尽管已经无法在界面上看到播放效果了，而且这个时候Activity的View会被动画持有，而View又持有了Activity，这样就会导致Activity无法被最终释放，引起内存泄露。解决办法就是在Activity的onDestroy()调用animator.cancel()来停止动画。

响应速度优化

响应速度优化的核心思想就是避免在主线程中做耗时操作，比如网络请求之类的，但是有时候的确有很多好吃操作，怎么办呢，可以将这些好吃操作放在主线程中执行，即采用异步的方式去进行耗时操作。响应速度过慢更多的体现在Activity的启动速度上面，如果在主线程中做太多事情，会导致Activity启动时出现黑屏现象，甚至出现ANR（Android Not Responding），就是应用程序无响应。Android规定，Activity如果在5秒钟之类无法响应屏幕触摸事件或者键盘输入的话就会出现ANR，而BroadcastReceiver如果10秒钟之类还未执行完操作的话也会出现ANR。那么怎么定位问题呢？其实，当ANR发生了之后，系统会在/data/anr 目录下创建一个文件traces.txt，通过分析这个文件就能定位ANR的原因了，具体怎么分析，以后单独写一篇文章进行讲解。

ListView和Bitmap优化

ListView的优化主要是3个方面，首先就是采用ViewHolder并避免在getView中执行耗时操作，其次要根据列表的滑动状态来控制任务的执行·频率，比如当列表快速滑动时显然是不太适合开启大量的异步任务的。最后可以尝试一下开始硬件加速来让LIstView更加流畅，这里的优化策略也完全适用GridView。

Bitmap的优化主要通过BitmapFactory.OPtions来根据需要对图片进行采样，采样过程中主要用到了BitmapFactory.Options的inSampleSize参数，具体的优化以后会单独写一篇文章讲解。

线程优化

线程优化的思想就是采用线程池，避免程序中存在大量的Thread，线程池可以重用内部的线程，从而避免线程的创建和销毁所带来的性能开销，同时线程池还能有效控制线程池的最大并发数，避免大量的线程因互相抢占系统资源从而导致阻塞现象的发生。因此在实际开发中，我们要尽量采用线程池，而不是每次都要创建一个Thread对象。

一些性能优化建议

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

参考

[任玉刚]Android开发艺术探索

Android日记之性能优化

前言