Android学习 - Android最佳性能实践

(一)合理管理内存

怎样才能写出高性能的应用程序，如何避免程序出现OOM，或者当程序内存占用过高的时候该怎么样去排查。确实，一个优秀的应用程序，不仅仅要功能完成得好，性能问题也应该处理得恰到好处。为此，我也是阅读了不少Android官方给出的高性能编程建议，把这些建议进行整理和分析，帮助大家能够写出更加出色的应用程序。

注意文章的内容基本源于AndroidDoc，如果想要阅读更加详细的关于性能方面的资料，可以直接去阅读Android官方文档。

内存(RAM)对于任何一个软件开发环境都是种非常珍贵的资源，而对于移动操作系统来讲的话，则会显得更加珍贵，因为手机的硬件条件相对于PC毕竟是比较落后的。尽管Android系统的虚拟机拥有自动回收垃圾的机制，但这并不代表我们就可以忽视应该在什么时候分配和释放内存。

为了使垃圾回收器可以正常释放程序所占用的内存，在编写代码的时候就一定要注意尽量避免出现内存泄漏的情况（通常都是由于全局成员变量持有对象引用所导致的），并且在适当的时候去释放对象引用。对于大多数的应用程序而言，后面其它的事情就可以都交给垃圾回收器去完成了，如果一个对象的引用不再被其它对象所持有，那么系统就会将这个对象所分配的内存进行回收。

我们在开发软件的时候应当自始至终都把内存的问题充分考虑进去，这样的话才能开发出更加高性能的软件。而内存问题也并不是无规律可行的，Android系统给我们提出了很多内存优化的建议技巧，只要按照这些技巧来编写程序，就可以让我们的程序在内存性能发面表现得相当不错，下面我们就来学习一下这些技巧。

节制地使用Service

如果应用程序当中需要使用Service来执行后台任务的话，请一定要注意只有当任务正在执行的时候才应该让Service运行起来。另外，当任务执行完之后去停止Service的时候，要小心Service停止失败导致内存泄漏的情况。

当我们启动一个Service时，系统会倾向于将这个Service所依赖的进程进行保留，这样就会导致这个进程变得非常消耗内存。并且，系统可以在LRU cache当中缓存的进程数量也会减少，导致切换应用程序的时候耗费更多性能。严重的话，甚至有可能会导致崩溃，因为系统在内存非常吃紧的时候可能已无法维护所有正在运行的Service所依赖的进程了。

为了能够控制Service的生命周期，Android官方推荐的最佳解决方案就是使用IntentService，这种Service的最大特点就是当后台任务执行结束后会自动停止，从而极大程度上避免了Service内存泄漏的可能性。

让一个Service在后台一直保持运行，即使它并不执行任何工作，这是编写Android程序时最糟糕的做法之一。所以Android官方极度建议开发人员们不要过于贪婪，让Service在后台一直运行，这不仅可能会导致手机和程序的性能非常低下，而且被用户发现了之后也有可能直接导致我们的软件被卸载。

当界面不可见时释放内存

当用户打开了另外一个程序，我们的程序界面已经不再可见的时候，我们应当将所有和界面相关的资源进行释放。在这种场景下释放资源可以让系统缓存后台进程的能力显著增加，因此也会让用户体验变得更好。

那么我们如何才能知道程序界面是不是已经不可见了呢？其实很简单，只需要在Activity中重写onTrimMemory()方法，然后在这个方法中监听TRIM_MEMORY_UI_HIDDEN这个级别，一旦触发了之后就说明用户已经离开了我们的程序，那么此时就可以进行资源释放操作了，如下所示：

@Override
public void onTrimMemory(int level) {
    super.onTrimMemory(level);
    switch (level) {
    case TRIM_MEMORY_UI_HIDDEN:
        // 进行资源释放操作
        break;
    }
}

注意onTrimMemory()方法中的TRIM_MEMORY_UI_HIDDEN回调只有当我们程序中的所有UI组件全部不可见的时候才会触发，这和onStop()方法还是有很大区别的，因为onStop()方法只是当一个Activity完全不可见的时候就会调用，比如说用户打开了我们程序中的另一个Activity。因此，我们可以在onStop()方法中去释放一些Activity相关的资源，比如说取消网络连接或者注销广播接收器等，但是像UI相关的资源应该一直要等到onTrimMemory(TRIM_MEMORY_UI_HIDDEN)这个回调之后才去释放，这样可以保证如果用户只是从我们程序的一个Activity回到了另外一个Activity，界面相关的资源都不需要重新加载，从而提升响应速度。

当内存紧张时释放内存

除了刚才讲的TRIM_MEMORY_UI_HIDDEN这个回调，onTrimMemory()方法还有很多种其它类型的回调，可以在手机内存降低的时候及时通知我们。我们应该根据回调中传入的级别来去决定如何释放应用程序的资源：

TRIM_MEMORY_RUNNING_MODERATE：表示应用程序正常运行，并且不会被杀掉。但是目前手机的内存已经有点低了，系统可能会开始根据LRU缓存规则来去杀死进程了。

TRIM_MEMORY_RUNNING_LOW：表示应用程序正常运行，并且不会被杀掉。但是目前手机的内存已经非常低了，我们应该去释放掉一些不必要的资源以提升系统的性能，同时这也会直接影响到我们应用程序的性能。

TRIM_MEMORY_RUNNING_CRITICAL：表示应用程序仍然正常运行，但是系统已经根据LRU缓存规则杀掉了大部分缓存的进程了。这个时候我们应当尽可能地去释放任何不必要的资源，不然的话系统可能会继续杀掉所有缓存中的进程，并且开始杀掉一些本来应当保持运行的进程，比如说后台运行的服务。

以上是当我们的应用程序正在运行时的回调，那么如果我们的程序目前是被缓存的，则会收到以下几种类型的回调：

TRIM_MEMORY_BACKGROUND：表示手机目前内存已经很低了，系统准备开始根据LRU缓存来清理进程。这个时候我们的程序在LRU缓存列表的最近位置，是不太可能被清理掉的，但这时去释放掉一些比较容易恢复的资源能够让手机的内存变得比较充足，从而让我们的程序更长时间地保留在缓存当中，这样当用户返回我们的程序时会感觉非常顺畅，而不是经历了一次重新启动的过程。

TRIM_MEMORY_MODERATE：表示手机目前内存已经很低了，并且我们的程序处于LRU缓存列表的中间位置，如果手机内存还得不到进一步释放的话，那么我们的程序就有被系统杀掉的风险了。

TRIM_MEMORY_COMPLETE：表示手机目前内存已经很低了，并且我们的程序处于LRU缓存列表的最边缘位置，系统会最优先考虑杀掉我们的应用程序，在这个时候应当尽可能地把一切可以释放的东西都进行释放。

避免在Bitmap上浪费内存

当我们读取一个Bitmap图片的时候，有一点一定要注意，就是千万不要去加载不需要的分辨率。在一个很小的ImageView上显示一张高分辨率的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存。需要仅记的一点是，将一张图片解析成一个Bitmap对象时所占用的内存并不是这个图片在硬盘中的大小，可能一张图片只有100k你觉得它并不大，但是读取到内存当中是按照像素点来算的，比如这张图片是1500*1000像素，使用的ARGB_8888颜色类型，那么每个像素点就会占用4个字节，总内存就是1500*1000*4字节，也就是5.7M，这个数据看起来就比较恐怖了。

使用优化过的数据集合

Android API当中提供了一些优化过后的数据集合工具类，如SparseArray、SparseBooleanArray以及LongSparseArray等，使用这些API可以让我们的程序更加高效。传统Java API中提供的HashMap工具类会相对比较低效，因为它需要为每一个键值对都提供一个对象入口，而SparseArray就避免掉了基本数据类型转换成对象数据类型的时间。

知晓内存的开支情况

我们还应当清楚我们所使用语言的内存开支和消耗情况，并且在整个软件的设计和开发当中都应该将这些信息考虑在内。可能有一些看起来无关痛痒的写法，结果却会导致很大一部分的内存开支，例如：

1、使用枚举通常会比使用静态常量要消耗两倍以上的内存，在Android开发当中我们应当尽可能地不使用枚举。

2、任何一个Java类，包括内部类、匿名类，都要占用大概500字节的内存空间。

3、任何一个类的实例要消耗12-16字节的内存开支，因此频繁创建实例也是会一定程序上影响内存的。

4、在使用HashMap时，即使你只设置了一个基本数据类型的键，比如说int，但是也会按照对象的大小来分配内存，大概是32字节，而不是4字节。因此最好的办法就是像上面所说的一样，使用优化过的数据集合。

谨慎使用抽象编程

许多程序员都喜欢各种使用抽象来编程，认为这是一种很好的编程习惯。当然，这一点不可否认，因为的抽象的编程方法更加面向对象，而且在代码的维护和可扩展性方面都会有所提高。但是，在Android上使用抽象会带来额外的内存开支，因为抽象的编程方法需要编写额外的代码，虽然这些代码根本执行不到，但是却也要映射到内存当中，不仅占用了更多的内存，在执行效率方面也会有所降低。当然这里我并不是提倡大家完全不使用抽象编程，而是谨慎使用抽象编程，不要认为这是一种很酷的编程方式而去肆意使用它，只在你认为有必要的情况下才去使用。

尽量避免使用依赖注入框架

现在有很多人都喜欢在Android工程当中使用依赖注入框架，比如说像Guice或者RoboGuice等，因为它们可以简化一些复杂的编码操作，比如可以将下面的一段代码：

class AndroidWay extends Activity {
    TextView name;
    ImageView thumbnail;
    LocationManager loc;
    Drawable icon;
    String myName;

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        name      = (TextView) findViewById(R.id.name);
        thumbnail = (ImageView) findViewById(R.id.thumbnail);
        loc       = (LocationManager) getSystemService(Activity.LOCATION_SERVICE);
        icon      = getResources().getDrawable(R.drawable.icon);
        myName    = getString(R.string.app_name);
        name.setText( "Hello, " + myName );
    }
}

简化成这样的一种写法：

@ContentView(R.layout.main)
class RoboWay extends RoboActivity {
    @InjectView(R.id.name)             TextView name;
    @InjectView(R.id.thumbnail)        ImageView thumbnail;
    @InjectResource(R.drawable.icon)   Drawable icon;
    @InjectResource(R.string.app_name) String myName;
    @Inject                            LocationManager loc;

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        name.setText( "Hello, " + myName );
    }
}

看上去确实十分诱人，我们甚至可以将findViewById()这一类的繁琐操作全部省去了。但是这些框架为了要搜寻代码中的注解，通常都需要经历较长的初始化过程，并且还可能将一些你用不到的对象也一并加载到内存当中。这些用不到的对象会一直占用着内存空间，可能要过很久之后才会得到释放，相较之下，也许多敲几行看似繁琐的代码才是更好的选择。

使用ProGuard简化代码

ProGuard相信大家都不会陌生，很多人都会使用这个工具来混淆代码，但是除了混淆之外，它还具有压缩和优化代码的功能。ProGuard会对我们的代码进行检索，删除一些无用的代码，并且会对类、字段、方法等进行重命名，重命名之后的类、字段和方法名都会比原来简短很多，这样的话也就对内存的占用变得更少了。

使用多个进程

这个技巧其实并不是非常建议使用，但它确实是一种可以帮助我们节省和管理内存的高级技巧。如果你要使用它的话一定要谨慎使用，因为绝大多数的应用程序都不应该在多个进程当中运行的，一旦使用不当，它甚至会增加额外的内存而不是帮我们节省内存。这个技巧比较适用于那些需要在后台去完成一项独立的任务，和前台的功能是可以完全区分开的场景。

这里举一个比较适合去使用多进程技巧的场景，比如说我们正在做一个音乐播放器软件，其中播放音乐的功能应该是一个独立的功能，它不需要和UI方面有任何关系，即使软件已经关闭了也应该可以正常播放音乐。如果此时我们只使用一个进程，那么即使用户关闭了软件，已经完全由Service来控制音乐播放了，系统仍然会将许多UI方面的内存进行保留。在这种场景下就非常适合使用两个进程，一个用于UI展示，另一个则用于在后台持续地播放音乐。

想要实现多进程的功能也非常简单，只需要在AndroidManifest文件的应用程序组件中声明一个android:process属性就可以了，比如说我们希望播放音乐的Service可以运行在一个单独的进程当中，就可以这样写：

这里指定的进程名是background，你也可以将它改成任意你喜欢的名字。需要注意的是，进程名的前面都应该加上一个冒号，表示该进程是一个当前应用程序的私有进程。

(二)分析内存的使用情况

由于Android是为移动设备开发的操作系统，我们在开发应用程序的时候应当始终把内存问题充分考虑在内。虽然Android系统拥有垃圾自动回收机制，但这并不意味着我们就可以完全忽略何时去分配或释放内存。即使我们全部按照上一篇文章中给出的编程建议来去编写程序，还是会很有可能出现内存泄露或其它类型的内存问题。所以，唯一能够解决问题的办法，就是尝试去分析应用程序的内存使用情况，那么本篇文章就会教大家如何进行分析。

虽说现在的手机内存都已经非常大了，但是我们大家都知道，系统是不可能将所有的内存都分配给我们的应用程序的。没错，每个程序都会有可使用的内存上限，这被称为堆大小（Heap Size）。不同的手机，堆大小也不尽相同，随着现在硬件设备不断提高，堆大小也已经由Nexus One时的32MB，变成了Nexus 5时的192MB。如果大家想要知道自己手机的堆大小是多少，可以调用如下代码：

ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getMemoryClass();

结果是以MB为单位进行返回的，我们在开发应用程序时所使用的内存不能超出这个限制，否则就会出现OutOfMemoryError。因此，比如说我们的程序中需要缓存一些数据，就可以根据堆大小来决定缓存数据的容量。

下面我们来讨论一下Android的GC操作，GC全称是GarbageCollection，也就是所谓的垃圾回收。Android系统会在适当的时机触发GC操作，一旦进行GC操作，就会将一些不再使用的对象进行回收。那么哪些对象会被认为是不再使用，并且可以被回收的呢？我们来看下面一张图：

上图当中，每个蓝色的圆圈就代表一个内存当中的对象，而圆圈之间的箭头就是它们的引用关系。这些对象有些是处于活动状态的，而有些就已经不再被使用了。那么GC操作会从一个叫作Roots的对象开始检查，所有它可以访问到的对象就说明还在使用当中，应该进行保留，而其它的对象就表示已经不再被使用了，如下图所示：

可以看到，目前所有黄色的对象仍然会被系统继续保留，而蓝色的对象就会在GC操作当中被系统回收掉了，这大概就是Android系统一次简单的GC流程。

那么什么时候会触发GC操作呢？这个通常都是由系统去决定的，我们一般情况下都不需要主动通知系统应该去GC了（虽然我们确实可以这么做，下面会讲到），但是我们仍然可以去监听系统的GC过程，以此来分析我们应用程序当前的内存状态。那么怎样才能去监听系统的GC过程呢？其实非常简单，系统每进行一次GC操作时，都会在LogCat中打印一条日志，我们只要去分析这条日志就可以了，日志的基本格式如下所示：

D/dalvikvm:  , ,  

注意这里我仍然是以dalvik虚拟机来进行说明，art情况下打印的内容也是基本类似的。

首先第一部分GC_Reason，这个是触发这次GC操作的原因，一般情况下一共有以下几种触发GC操作的原因：

GC_CONCURRENT：当我们应用程序的堆内存快要满的时候，系统会自动触发GC操作来释放内存。

GC_FOR_MALLOC：当我们的应用程序需要分配更多内存，可是现有内存已经不足的时候，系统会进行GC操作来释放内存。

GC_HPROF_DUMP_HEAP：当生成HPROF文件的时候，系统会进行GC操作，关于HPROF文件我们下面会讲到。

GC_EXPLICIT：这种情况就是我们刚才提到过的，主动通知系统去进行GC操作，比如调用System.gc()方法来通知系统。或者在DDMS中，通过工具按钮也是可以显式地告诉系统进行GC操作的。

接下来第二部分Amount_freed，表示系统通过这次GC操作释放了多少内存。

然后Heap_stats中会显示当前内存的空闲比例以及使用情况（活动对象所占内存/当前程序总内存）。

最后Pause_time表示这次GC操作导致应用程序暂停的时间。关于这个暂停的时间，Android在2.3的版本当中进行过一次优化，在2.3之前GC操作是不能并发进行的，也就是系统正在进行GC，那么应用程序就只能阻塞住等待GC结束。虽说这个阻塞的过程并不会很长，也就是几百毫秒，但是用户在使用我们的程序时还是有可能会感觉到略微的卡顿。而自2.3之后，GC操作改成了并发的方式进行，就是说GC的过程中不会影响到应用程序的正常运行，但是在GC操作的开始和结束的时候会短暂阻塞一段时间，不过优化到这种程度，用户已经是完全无法察觉到了。

下面是一次GC操作在LogCat中打印的日志：

dalvikvm(24699): GC_CONCURRENT freed 1033k, 13% free 15680k/17991k, paused 31ms+7ms

可以看出，和我们上面所介绍的格式是完全一致的，最后的暂停时间31ms+7ms，一次就是GC开始时的暂停时间，一次是结束时的暂停时间。另外可以根据进程id来区分这是哪个程序中进行的GC操作，那么从上图就可以看出这条GC日志是属于24699这个程序的。

那么这是使用dalvik运行环境时所打印的GC日志，而自Android 4.4版本之后加入了art运行环境，在art中打印GC日志基本和dalvik是相同的，如下所示：

I/art (1456): Explicit concurrent mark sweep GC freed 39818(2MB) AllocSpace objects, 0(0B) LOS objects, 39% free, 18MB/31MB, paused 798us total 26.387ms

相信没有什么难理解的地方吧，art中只是内容显示的格式有了稍许变化，打印的主体内容仍然是不变的。

通过日志的方式我们可以简单了解到系统的GC工作情况，但是如果我们想要更加清楚地实时知晓当前应用程序的内存使用情况，只通过日志就有些力不从心了，我们需要通过DDMS中提供的工具来实现。

打开DDMS界面，在左侧面板中选择你要观察的应用程序进程，然后点击UpdateHeap按钮，接着在右侧面板中点击Heap标签，之后不停地点击Cause GC按钮来实时地观察应用程序内存的使用情况即可，如下图所示：

接着继续操作我们的应用程序，然后继续点击Cause GC按钮，如果你发现反复操作某一功能会导致应用程序内存持续增高而不会下降的话，那么就说明这里很有可能发生内存泄漏了。

讨论完了GC，接下来我们讨论一下Android中内存泄漏的问题。大家需要知道的是Android中的垃圾回收机制并不能防止内存泄漏的出现，导致内存泄漏最主要的原因就是某些长存对象持有了一些其它应该被回收的对象的引用，导致垃圾回收器无法去回收掉这些对象，那也就出现内存泄漏了。比如说像Activity这样的系统组件，它又会包含很多的控件甚至是图片，如果它无法被垃圾回收器回收掉的话，那就算是比较严重的内存泄漏情况了。

下面我们来模拟一种Activity内存泄漏的场景，内部类相信大家都有用过，如果我们在一个类中又定义了一个非静态的内部类，那么这个内部类就会持有外部类的引用，如下所示：

public class MainActivity extends ActionBarActivity {

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

    class LeakClass {

    }
    ......
}

目前来看，代码还是没有问题的，因为虽然LeakClass这个内部类持有MainActivity的引用，但是只要它的存活时间不会长于MainActivity，就不会阻止MainActivity被垃圾回收器回收。那么现在我们来将代码进行如下修改：

public class MainActivity extends ActionBarActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        LeakClass leakClass = new LeakClass();
        leakClass.start();
    }

    class LeakClass extends Thread {
        @Override
        public void run() {
            while (true) {
                try {
                    Thread.sleep(60 * 60 * 1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
    ......
}

这下就有点不太一样了，我们让LeakClass继承自Thread，并且重写了run()方法，然后在MainActivity的onCreate()方法中去启动LeakClass这个线程。而LeakClass的run()方法中运行了一个死循环，也就是说这个线程永远都不会执行结束，那么LeakClass这个对象就一直不能得到释放，并且它持有的MainActivity也将无法得到释放，那么内存泄露就出现了。

现在我们可以将程序运行起来，然后不断地旋转手机让程序在横屏和竖屏之间切换，因为每切换一次Activity都会经历一个重新创建的过程，而前面创建的Activity又无法得到回收，那么长时间操作下我们的应用程序所占用的内存就会越来越高，最终出现OutOfMemoryError。

下面我贴出一张不断切换横竖屏时GC日志打印的结果图，如下所示：

可以看到，应用程序所占用的内存是在不断上升的。最可怕的是，这些内存一旦升上去了就永远不会再降下来，直到程序崩溃为止，因为这部分泄露的内存一直都无法被垃圾回收器回收掉。

那么通过上面学习的GC日志以及DDMS工具这两种方式，现在我们已经可以比较轻松地发现应用程序中是否存在内存泄露的现象了。但是如果真的出现了内存泄露，我们应该怎么定位到具体是哪里出的问题呢？这就需要借助一个内存分析工具了，叫做Eclipse Memory Analyzer（MAT）。我们需要先将这个工具下载下来，下载地址是：

http://eclipse.org/mat/downloads.php

这个工具分为Eclipse插件版和独立版两种，如果你是使用Eclipse开发的，那么可以使用插件版MAT，非常方便。如果你是使用Android Studio开发的，那么就只能使用独立版的MAT了。

下载好了之后下面我们开始学习如何去分析内存泄露的原因，首先还是进入到DDMS界面，然后在左侧面板选中我们要观察的应用程序进程，接着点击Dump HPROF file按钮，如下图所示：

点击这个按钮之后需要等待一段时间，然后会生成一个HPROF文件，这个文件记录着我们应用程序内部的所有数据。但是目前MAT还是无法打开这个文件的，我们还需要将这个HPROF文件从Dalvik格式转换成J2SE格式，使用hprof-conv命令就可以完成转换工作，如下所示：

hprof-conv dump.hprof converted-dump.hprof

hprof-conv命令文件存放于/platform-tools目录下面。另外如果你是使用的插件版的MAT，也可以直接在Eclipse中打开生成的HPROF文件，不用经过格式转换这一步。

接下来我们就可以来尝试使用MAT工具去分析内存泄漏的原因了，这里需要提醒大家的是，MAT并不会准确地告诉我们哪里发生了内存泄漏，而是会提供一大堆的数据和线索，我们需要自己去分析这些数据来去判断到底是不是真的发生了内存泄漏。那么现在运行MAT工具，然后选择打开转换过后的converted-dump.hprof文件，如下图所示：

MAT中提供了非常多的功能，这里我们只要学习几个最常用的就可以了。上图最中央的那个饼状图展示了最大的几个对象所占内存的比例，这张图中提供的内容并不多，我们可以忽略它。在这个饼状图的下方就有几个非常有用的工具了，我们来学习一下。

Histogram：可以列出内存中每个对象的名字、数量以及大小。

Dominator Tree：会将所有内存中的对象按大小进行排序，并且我们可以分析对象之间的引用结构。

一般最常用的就是以上两个功能了，那么我们先从Dominator Tree开始学起。

现在点击DominatorTree，结果如下图所示：

这张图包含的信息非常多，我来带着大家一起解析一下。首先Retained Heap表示这个对象以及它所持有的其它引用（包括直接和间接）所占的总内存，因此从上图中看，前两行的Retained Heap是最大的，我们分析内存泄漏时，内存最大的对象也是最应该去怀疑的。

另外大家应该可以注意到，在每一行的最左边都有一个文件型的图标，这些图标有的左下角带有一个红色的点，有的则没有。带有红点的对象就表示是可以被GC Roots访问到的，根据上面的讲解，可以被GC Root访问到的对象都是无法被回收的。那么这就说明所有带红色的对象都是泄漏的对象吗？当然不是，因为有些对象系统需要一直使用，本来就不应该被回收。我们可以注意到，上图当中所有带红点的对象最右边都有写一个System Class，说明这是一个由系统管理的对象，并不是由我们自己创建并导致内存泄漏的对象。

那么上图中就无法看出内存泄漏的原因了吗？确实，内存泄漏本来就不是这么容易找出的，我们还需要进一步进行分析。上图当中，除了带有System Class的行之外，最大的就是第二行的Bitmap对象了，虽然Bitmap对象现在不能被GC Roots访问到，但不代表着Bitmap所持有的其它引用也不会被GC Roots访问到。现在我们可以对着第二行点击右键 -> Path to GCRoots -> exclude weak references，为什么选择exclude weak references呢？因为弱引用是不会阻止对象被垃圾回收器回收的，所以我们这里直接把它排除掉，结果如下图所示：

可以看到，Bitmap对象经过层层引用之后，到了MainActivity$LeakClass这个对象，然后在图标的左下角有个红色的图标，就说明在这里可以被GCRoots访问到了，并且这是由我们自己创建的Thread，并不是SystemClass了，那么由于MainActivity$LeakClass能被GC Roots访问到导致不能被回收，导致它所持有的其它引用也无法被回收了，包括MainActivity，也包括MainActivity中所包含的图片。

通过这种方式，我们就成功地将内存泄漏的原因找出来了。这是Dominator Tree中比较常用的一种分析方式，即搜索大内存对象通向GC Roots的路径，因为内存占用越高的对象越值得怀疑。

接下来我们再来学习一下Histogram的用法，回到Overview界面，点击Histogram，结果如下图所示：

这里是把当前应用程序中所有的对象的名字、数量和大小全部都列出来了，需要注意的是，这里的对象都是只有Shallow Heap而没有Retained Heap的，那么Shallow Heap又是什么意思呢？就是当前对象自己所占内存的大小，不包含引用关系的，比如说上图当中，byte[]对象的ShallowHeap最高，说明我们应用程序中用了很多byte[]类型的数据，比如说图片。可以通过右键 -> List objects -> with incoming references来查看具体是谁在使用这些byte[]。

那么通过Histogram又怎么去分析内存泄漏的原因呢？当然其实也可以用和Dominator Tree中比较相似的方式，即分析大内存的对象，比如上图中byte[]对象内存占用很高，我们通过分析byte[]，最终也是能找到内存泄漏所在的，但是这里我准备使用另外一种更适合Histogram的方式。大家可以看到，Histogram中是可以显示对象的数量的，那么比如说我们现在怀疑MainActivity中有可能存在内存泄漏，就可以在第一行的正则表达式框中搜索“MainActivity”，如下所示：

可以看到，这里将包含“MainActivity”字样的所有对象全部列出了出来，其中第一行就是MainActivity的实例。但是大家有没有注意到，当前内存中是有11个MainActivity的实例的，这太不正常了，通过情况下一个Activity应该只有一个实例才对。其实这些对象就是由于我们刚才不断地横竖屏切换所产生的，因为横竖屏切换一次，Activity就会经历一个重新创建的过程，但是由于LeakClass的存在，之前的Activity又无法被系统回收，那么就出现这种一个Activity存在多个实例的情况了。

接下来对着MainActivity右键->List objects->withincoming references查看具体MainActivity实例，如下图所示：

如果想要查看内存泄漏的具体原因，可以对着任意一个MainActivity的实例右键 -> Path to GC Roots -> exclude weak references，结果如下图所示：

可以看到，我们再次找到了内存泄漏的原因，是因为MainActivity$LeakClass对象所导致的。

这大概就是MAT工具最常用的一些用法了，当然这里还要提醒大家一句，工具是死的，人是活的，MAT也没有办法保证一定可以将内存泄漏的原因找出来，还是需要我们对程序的代码有足够多的了解，知道有哪些对象是存活的，以及它们存活的原因，然后再结合MAT给出的数据来进行具体的分析，这样才有可能把一些隐藏得很深的问题原因给找出来。

(三)高性能编码优化

前面我们主要学习了Android内存方面的相关知识，包括如何合理地使用内存，以及当发生内存泄露时如何定位出问题的原因。那么关于内存的知识就讨论到这里，今天开始我们将学习一些性能编码优化的技巧。

这里先事先提醒大家一句，本篇文章中讨论的编码优化技巧都是属于一些“微优化”，也就是说即使我们都按照本篇文章的技巧来优化代码，在性能方面也是看不出有什么显著的提升的。使用合适的算法与数据结构将永远是你优化程序性能的最主要手段，但本篇文章中不会讨论这一块的内容。因此，这里我们即将学习的并不是什么灵丹妙药，而是大家应该把这些技巧当作一种好的编码规范，我们在平时写代码时就可以潜移默化地使用这些编码规范，不仅能够在微观层面提升程序一定的性能，也可以让我们的代码变得更加专业，下面就让我们来一起学习一下这些技巧。

避免创建不必要的对象

创建对象从来都不应该是一件随意的事情，因为创建一个对象就意味着垃圾回收器需要回收一个对象，而这两步操作都是需要消耗时间的。虽说创建一个对象的代价确实非常小，并且Android 2.3版本当中又增加了并发垃圾回收器机制，这让GC操作时的停顿时间也变得难以察觉，但是这些理由都不足以让我们可以肆意地创建对象，需要创建的对象我们自然要创建，但是不必要的对象我们就应该尽量避免创建。

下面来看一些我们可以避免创建对象的场景：

1、如果我们有一个需要拼接的字符串，那么可以优先考虑使用StringBuffer或者StringBuilder来进行拼接，而不是加号连接符，因为使用加号连接符会创建多余的对象，拼接的字符串越长，加号连接符的性能越低。

2、在没有特殊原因的情况下，尽量使用基本数据类来代替封装数据类型，int比Integer要更加高效，其它数据类型也是一样。

3、当一个方法的返回值是String的时候，通常可以去判断一下这个String的作用是什么，如果我们明确地知道调用方会将这个返回的String再进行拼接操作的话，可以考虑返回一个StringBuffer对象来代替，因为这样可以将一个对象的引用进行返回，而返回String的话就是创建了一个短生命周期的临时对象。

4、正如前面所说，基本数据类型要优于对象数据类型，类似地，基本数据类型的数组也要优于对象数据类型的数组。另外，两个平行的数组要比一个封装好的对象数组更加高效，举个例子，Foo[]和Bar[]这样的两个数组，使用起来要比Custom(Foo,Bar)[]这样的一个数组高效得多。

当然上面所说的只是一些代表性的例子，我们所要遵守的一个基本原则就是尽可能地少创建临时对象，越少的对象意味着越少的GC操作，同时也就意味着越好的程序性能和用户体验。

静态优于抽象

如果你并不需要访问一个对象中的某些字段，只是想调用它的某个方法来去完成一项通用的功能，那么可以将这个方法设置成静态方法，这会让调用的速度提升15%-20%，同时也不用为了调用这个方法而去专门创建对象了，这样还满足了上面的一条原则。另外这也是一种好的编程习惯，因为我们可以放心地调用静态方法，而不用担心调用这个方法后是否会改变对象的状态（静态方法内无法访问非静态字段）。

对常量使用static final修饰符

我们先来看一下在一个类的最顶部定义如下代码：

static int intVal = 42;
static String strVal = "Hello, world!";

编译器会为上述代码生成一个初始化方法，称为方法，该方法会在定义类第一次被使用的时候调用。然后这个方法会将42的值赋值到intVal当中，并从字符串常量表中提取一个引用赋值到strVal上。当赋值完成后，我们就可以通过字段搜寻的方式来去访问具体的值了。

但是我们还可以通过final关键字来对上述代码进行优化：

static final int intVal = 42;
static final String strVal = "Hello, world!";

经过这样修改之后，定义类就不再需要一个方法了，因为所有的常量都会在dex文件的初始化器当中进行初始化。当我们调用intVal时可以直接指向42的值，而调用strVal时会用一种相对轻量级的字符串常量方式，而不是字段搜寻的方式。

另外需要大家注意的是，这种优化方式只对基本数据类型以及String类型的常量有效，对于其它数据类型的常量是无效的。不过，对于任何常量都是用static final的关键字来进行声明仍然是一种非常好的习惯。

使用增强型for循环语法

增强型for循环（也被称为for-each循环）可以用于去遍历实现Iterable接口的集合以及数组，这是jdk 1.5中新增的一种循环模式。当然除了这种新增的循环模式之外，我们仍然还可以使用原有的普通循环模式，只不过它们之间是有效率区别的，我们来看下面一段代码：

static class Counter {
    int mCount;
}

Counter[] mArray = ...

public void zero() {
    int sum = 0;
    for (int i = 0; i < mArray.length; ++i) {
        sum += mArray[i].mCount;
    }
}

public void one() {
    int sum = 0;
    Counter[] localArray = mArray;
    int len = localArray.length;
    for (int i = 0; i < len; ++i) {
        sum += localArray[i].mCount;
    }
}

public void two() {
    int sum = 0;
    for (Counter a : mArray) {
        sum += a.mCount;
    }
}

可以看到，上述代码当中我们使用了三种不同的循环方式来对mArray中的所有元素进行求和。其中zero()方法是最慢的一种，因为它是把mArray.length写在循环当中的，也就是说每循环一次都需要重新计算一次mArray的长度。而one()方法则相对快得多，因为它使用了一个局部变量len来记录数组的长度，这样就省去了每次循环时字段搜寻的时间。two()方法在没有JIT（Just In Time Compiler）的设备上是运行最快的，而在有JIT的设备上运行效率和one()方法不相上下，唯一需要注意的是这种写法需要JDK 1.5之后才支持。

但是这里要跟大家提一个特殊情况，对于ArrayList这种集合，自己手写的循环要比增强型for循环更快，而其他的集合就没有这种情况。因此，对于我们来说，默认情况下可以都使用增强型for循环，而遍历ArrayList时就还是使用传统的循环方式吧。

多使用系统封装好的API

Java语言当中其实给我们提供了非常丰富的API接口，我们在编写程序时如果可以使用系统提供的API就应该尽量使用，系统提供的API完成不了我们需要的功能时才应该自己去写，因为使用系统的API在很多时候比我们自己写的代码要快得多，它们的很多功能都是通过底层的汇编模式执行的。

比如说String类当中提供的好多API都是拥有极高的效率的，像indexOf()方法和一些其它相关的API，虽说我们通过自己编写算法也能够完成同样的功能，但是效率方面会和这些方法差的比较远。这里举个例子，如果我们要实现一个数组拷贝的功能，使用循环的方式来对数组中的每一个元素一一进行赋值当然是可行的，但是如果我们直接使用系统中提供的System.arraycopy()方法将会让执行效率快9倍以上。

避免在内部调用Getters/Setters方法

我们平时写代码时都被告知，一定要使用面向对象的思维去写代码，而面向对象的三大特性我们都知道，封装、多态和继承。其中封装的基本思想就是不要把类内部的字段暴漏给外部，而是提供特定的方法来允许外部操作相应类的内部字段，从而在Java语言当中就出现了Getters/Setters这种封装技巧。

然而在Android上这个技巧就不再是那么的受推崇了，因为字段搜寻要比方法调用效率高得多，我们直接访问某个字段可能要比通过getters方法来去访问这个字段快3到7倍。不过我们肯定不能仅仅因为效率的原因就将封装这个技巧给抛弃了，编写代码还是要按照面向对象思维的，但是我们可以在能优化的地方进行优化，比如说避免在内部调用getters/setters方法。

那什么叫做在内部调用getters/setters方法呢？这里我举一个非常简单的例子：

public class Calculate {

    private int one = 1;

    private int two = 2;

    public int getOne() {
        return one;
    }

    public int getTwo() {
        return two;
    }

    public int getSum() {
        return getOne() + getTwo();
    }
}

可以看到，上面是一个Calculate类，这个类的功能非常简单，先将one和two这两个字段进行了封装，然后提供了getOne()方法获取one字段的值，提供了getTwo()方法获取two字段的值，还提供了一个getSum()方法用于获取总和的值。

这里我们注意到，getSum()方法当中的算法就是将one和two的值相加进行返回，但是它获取one和two的值的方式也是通过getters方法进行获取的，其实这是一种完全没有必要的方式，因为getSum()方法本身就是Calculate类内部的方法，它是可以直接访问到Calculate类中的封装字段的，因此这种写法在Android上是不推崇的，我们可以进行如下修改：

public class Calculate {

    private int one = 1;

    private int two = 2;

    ......

    public int getSum() {
        return one + two;
    }
}

改成这种写法之后，我们就避免了在内部调用getters/setters方法，而对于外部而言Calculate类仍然是具有很好的封装性的。

(四)布局优化技巧

前面我们学习了如何通过合理管理内存，以及高性能编码技巧的方式来提升应用程序的性能。然而实际上界面布局也会对应用程序的性能产生比较大的影响，如果布局写得糟糕的话，那么程序加载UI的速度就会非常慢，从而造成不好的用户体验。那么本篇文章我们就来学习一下，如何通过优化布局来提供应用程序的性能。

重用布局文件

Android系统中已经提供了非常多好用的控件，这让我们在编写布局的时候可以很轻松。但是有些时候我们可能需要反复利用某个已经写好的布局，如果你总是使用复制粘贴的方式来进行布局重用，这显然是一种很笨的做法。而Android当然也已经充分考虑到了布局重用的重要性，于是提供了和这两个非常有用的标签，下面我们就来逐个学习一下。

标签可以允许在一个布局当中引入另外一个布局，那么比如说我们程序的所有界面都有一个公共的部分，这个时候最好的做法就是将这个公共的部分提取到一个独立的布局文件当中，然后在每个界面的布局文件当中来引用这个公共的布局。

这里举个例子吧，我们应该都知道，目前几乎所有的软件都会有一个头布局，头布局中可以包含界面的标题、返回按钮、以及其它一些操作功能等。那这样的一个头布局，有些软件是使用ActionBar来实现的，但是由于ActionBar的灵活性不太好，因而也有很多软件会选择自己去编写实现。那如果自己去实现的话，由于这个头布局是在所有界面都要使用的，显然我们不可能在每个界面当中都去写一遍这个头布局的代码，因此这种情况下使用标签就非常合适了。这里为了给大家演示一下，我就编写一个非常简单的头布局，在res/layout文件夹中新建titlebar.xml作为头布局，代码如下所示：

可以看到，titlebar.xml中的布局非常简单，外层是一个RelativeLayout，里面只有两个Button和一个TextView，左边的Button用于实现返回功能，右边的Button用于实现完成功能，中间的TextView则可以用于显示当前界面的标题。我们可以来预览一下titlebar的样子，如下图所示：

那titlebar作为一个独立的布局现在我们已经编写完了，接下来的工作就非常简单了，无论任何界面需要加入titlebar这个功能，只需要在布局文件中引入titlebar.xml就可以了。那么比如说我们的程序当中有一个activity_main.xml文件，现在想要引入titlebar只需要这样写：

    

    ......

一行include语句就可以搞定了。标签当中可以指定一个layout属性，我们在这个layout属性中填写需要引入的布局名就可以了。而且使用这种引入的方式，以后如果titlebar的界面有所变更，我们只需要修改titlebar.xml这一个文件就可以了，而不是所有界面一个个地去修改。

现在如果你运行一下程序会发现出大问题了，虽然titlebar是成功引入了，但是我们activity_main.xml中本来的界面全部都不见了！出现这个问题是原因是因为titlebar的最外层布局是一个宽高都是match_parent的RelativeLayout，它会将整个布局都填充满，因而我们原本的布局也就看不见了。那既然问题的原因清楚了，相信你立刻就想到应该怎么修改了，将RelativeLayout的layout_height属性修改成wrap_content不就可以了嘛。没错，这样修改当然是没问题的，不过这种修改方式会让所有引用titlebar的界面都受到影响，而如何你只希望让activity_main.xml这一个界面受影响的话，那么可以使用覆写属性的方式。

在标签当中，我们是可以覆写所有layout属性的，即include中指定的layout属性将会覆盖掉titlebar中指定的layout属性。因此，这里我们希望将titlebar的高度设置成wrap_content，就可以这样写：

    

    ......

现在重新运行一下程序应该就可以一切正常了，如下图所示：

除了layout_height之外，我们还可以覆写titlebar中的任何一个layout属性，如layout_gravity、layout_margin等，而非layout属性则无法在标签当中进行覆写。另外需要注意的是，如果我们想要在标签当中覆写layout属性，必须要将layout_width和layout_height这两个属性也进行覆写，否则覆写效果将不会生效。

标签是作为标签的一种辅助扩展来使用的，它的主要作用是为了防止在引用布局文件时产生多余的布局嵌套。大家都知道，Android去解析和展示一个布局是需要消耗时间的，布局嵌套的越多，那么解析起来就越耗时，性能也就越差，因此我们在编写布局文件时应该让嵌套的层数越少越好。

在上面我们讲解标签的用法时主要介绍了它优点，但是它也存在着一个不好的地方，就是可能会导致产生多余的布局嵌套。这里还是通过举例的方式跟大家说明一下，比如说我们需要编写一个确定取消按钮的公共布局，这样任何一个界面需要确定和取消功能时就不用再单独编写了，新建ok_cancel_layout.xml，代码如下所示：

可以看到，这个界面也是非常简单，外层是一个垂直方向的LinearLayout，LinearLayout中包含了两个按钮，一个用于实现确定功能，一个用于实现取消功能。现在我们可以来预览一下这个界面，如下图所示：

好的，然后我们有一个profile.xml的界面需要编辑一些内容，那么这里就可以将ok_cancel_layout这个布局引入到profile.xml界面当中，如下所示：

在profile.xml当中有一个EditText控件用于编辑内容，然后下面使用了标签来将ok_cancel_layout布局进行引入，现在重新运行一下程序，界面效果如下图所示：

看上去效果非常不错对吗？可是在你毫无察觉的情况下，目前profile.xml这个界面当中其实已经存在着多余的布局嵌套了！感觉还没写几行代码呢，怎么这就已经有多余的布局嵌套了？不信的话我们可以通过View Hierarchy工具来查看一下，如下图所示：

可以看到，最外层首先是一个FrameLayout。然后FrameLayout中包含的是一个LinearLayout，这个就是我们在profile.xml中定义的最外层布局。接下来的部分就有问题了，在最外层的LinearLayout当中包含了两个元素，一个是EditText，另一个又是一个LinearLayout，然后在这个内部的LinearLayout当中才包含了确定和取消这两个按钮。

相信大家已经可以看出来了吧，这个内部的LinearLayout就是一个多余的布局嵌套，实际上并不需要这样一层，让两个按钮直接包含在外部的LinearLayout当中就可以了。而这个多余的布局嵌套其实就是由于布局引入所导致的，因为我们在ok_cancel_layout.xml中也定义了一个LinearLayout。那么应该怎样优化掉这个问题呢？当然就是使用标签来完成了，修改ok_cancel_layout.xml中的代码，如下所示：

可以看到，这里我们将ok_cancel_layout最外层的LinearLayout布局删除掉，换用了标签，这就表示当有任何一个地方去include这个布局时，会将标签内包含的内容直接填充到include的位置，不会再添加任何额外的布局结构。好的，的用法就是这么简单，现在重新运行一下程序，你会看到界面没有任何改变，然后我们再通过View Hierarchy工具来查看一下当前的View结构，如下图所示：

可以看到，现在EditText和两个按钮都直接包含在了LinearLayout下面，我们的profile.xml当中也就不存在多余的布局嵌套了。

仅在需要时才加载布局

有的时候我们会遇到这样的场景，就是某个布局当中的元素非常多，但并不是所有元素都一起显示出来的，而是普通情况下只显示部分常用的元素，而那些不常用的元素只有在用户进行特定操作的情况下才会显示出来。

这里举个大家都非常熟悉的例子，我们在添加联系人的时候其实可以编辑的字段真的非常多，姓名、电话、email、传真、住址、昵称等等，但其实基本上大家最常用的就是填一个姓名，填一个电话而已。那么将这么多繁杂的字段都一起显示在界面上其实并不是一种很好的做法，因为大多数人都是用不到这些字段的。比较聪明的做就是把最常用的姓名和电话显示在界面上，然后给用户提供一个添加更多字段的选项，当用户真的有需要去添加其它信息的时候，我们才将另外的元素显示到界面上。

说到实现这样一个功能，我相信大多数人的第一反应就是将不常用的元素使用INVISIBLE或者GONE进行隐藏，然后当用户需要使用这些元素的时候再把它们置成VISIBLE显示出来。使用这种方式肯定可以实现功能的，但是性能方面就表现得一般了，因为即使是将元素进行隐藏，它们其实还是在布局当中的，每个元素还拥有着自己的宽、高、背景等等属性，解析布局的时候也会将这些隐藏的元素一一解析出来。

那么我们如何才能让这些不常用的元素仅在需要时才去加载呢？Android为此提供了一种非常轻量级的控，ViewStub。ViewStub虽说也是View的一种，但是它没有大小，没有绘制功能，也不参与布局，资源消耗非常低，将它放置在布局当中基本可以认为是完全不会影响性能的。

下面我们就来学习一下如何使用ViewStub来完成仅在需要时才去加载布局的功能，目前profile.xml中只有一个EditText用于编辑信息，那么比如说我们还有另外三个不太常用的EditText，就可以将它们定义在另外一个布局文件当中。新建profile_extra.xml文件，代码如下所示：

可以看到，在profile_extra.xml这个布局文件当中定义了三个EditText，也就是用于编辑那些不常用信息的控件，现在我们可以来预览一下这个布局，如下图所示：

目前profile_extra.xml是一个独立的布局，和profile.xml这个布局文件是完全没有关系的。接下来我们修改profile.xml文件中的代码，如下所示：

可以看到，这里我们新增了一个MoreButton，这个按钮就是用于去加载那些不常用的元素的，然后在Button的下面定义了一个ViewStub。在ViewStub控件中，我们先是通过id属性给它指定了一个唯一标识，又通过layout属性将profile_extra布局传入进来，接着给ViewStub指定了一个宽高。注意，虽然ViewStub是不占用任何空间的，但是每个布局都必须要指定layout_width和layout_height属性，否则运行就会报错。

接着修改ProfileActivity中的代码，在Activity中添加More Button的点击事件，并在点击事件中进行如下逻辑处理：

private EditText editExtra1;
private EditText editExtra2;
private EditText editExtra3;

public void onMoreClick() {
    ViewStub viewStub = (ViewStub) findViewById(R.id.view_stub);
    if (viewStub != null) {
        View inflatedView = viewStub.inflate();
        editExtra1 = (EditText) inflatedView.findViewById(R.id.edit_extra1);
        editExtra2 = (EditText) inflatedView.findViewById(R.id.edit_extra2);
        editExtra3 = (EditText) inflatedView.findViewById(R.id.edit_extra3);
    }
}

当点击More Button之后我们首先会调用findViewById()方法将ViewStub的实例获取到，拿到ViewStub的实例之后就很简单了，调用inflate()方法或者setVisibility(View.VISIBLE)都可以将隐藏的布局给加载出来，而加载的这个布局就是刚才在XML当中配置的profile_extra布局。

调用inflate()方法之后会将加载出来的布局进行返回，之后我们就可以对这个布局进行任意的操作了，再次隐藏显示，或者获取子元素的实例等。注意这里我对ViewStub的实例进行了一个非空判断，这是因为ViewStub在XML中定义的id只在一开始有效，一旦ViewStub中指定的布局加载之后，这个id也就失败了，那么此时findViewById()得到的值也会是空。

现在我们重新运行一下程序，界面如下图所示：

可以看到，界面上只有一个More按钮，ViewStub是完全不占用任何空间的。然后点击一下More按钮，新的界面如下所示：

没有问题，profile_extra.xml中定义的布局已经加载出来了，而且显示的位置也是在More按钮和OK按钮之间，正是ViewStub控件定义的位置，说明我们确实已经将ViewStub成功使用起来了。

另外需要提醒大家一点，ViewStub所加载的布局是不可以使用标签的，因此这有可能导致加载出来的布局存在着多余的嵌套结构，具体如何去取舍就要根据各自的实际情况来决定了，对于那些隐藏的布局文件结构相当复杂的情况，使用ViewStub还是一种相当不错的选择的，即使增加了一层无用的布局结构，仍然还是利大于弊。