有不少朋友都问过我，怎样才能写出高性能的应用程序，如何避免程序出现OOM，或者当程序内存占用过高的时候该怎么样去排查。确实，一个优秀的应用程序，不仅仅要功能完成得好，性能问题也应该处理得恰到好处。为此，我也是阅读了不少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这个级别，一旦触发了之后就说明用户已经离开了我们的程序，那么此时就可以进行资源释放操作了，如下所示：

[java]view plaincopy

  1. @Override

  2. publicvoidonTrimMemory(intlevel){

  3. super.onTrimMemory(level);

  4. switch(level){

  5. caseTRIM_MEMORY_UI_HIDDEN:

  6. //进行资源释放操作

  7. break;

  8. }

  9. }

注意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高效加载大图、多图解决方案，有效避免程序OOM。

使用优化过的数据集合

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

知晓内存的开支情况

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

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

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

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

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

谨慎使用抽象编程

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

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

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

[java]view plaincopy

  1. classAndroidWayextendsActivity{

  2. TextViewname;

  3. ImageViewthumbnail;

  4. LocationManagerloc;

  5. Drawableicon;

  6. StringmyName;

  8. publicvoidonCreate(BundlesavedInstanceState){

  9. super.onCreate(savedInstanceState);

  10. setContentView(R.layout.main);

  11. name=(TextView)findViewById(R.id.name);

  12. thumbnail=(ImageView)findViewById(R.id.thumbnail);

  13. loc=(LocationManager)getSystemService(Activity.LOCATION_SERVICE);

  14. icon=getResources().getDrawable(R.drawable.icon);

  15. myName=getString(R.string.app_name);

  16. name.setText("Hello,"+myName);

  17. }

  18. }

简化成这样的一种写法：

[java]view plaincopy

  1. @ContentView(R.layout.main)

  2. classRoboWayextendsRoboActivity{

  3. @InjectView(R.id.name)TextViewname;

  4. @InjectView(R.id.thumbnail)ImageViewthumbnail;

  5. @InjectResource(R.drawable.icon)Drawableicon;

  6. @InjectResource(R.string.app_name)StringmyName;

  7. @InjectLocationManagerloc;

  9. publicvoidonCreate(BundlesavedInstanceState){

  10. super.onCreate(savedInstanceState);

  11. name.setText("Hello,"+myName);

  12. }

  13. }

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

使用ProGuard简化代码

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

使用多个进程

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

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

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

[java]view plaincopy

  1. <serviceandroid:name=".PlaybackService"

  2. android:process=":background"/>

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

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

[java]view plaincopy

  1. ActivityManagermanager=(ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);

  2. intheapSize=manager.getMemoryClass();

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

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


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


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

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

[plain]view plaincopy

  1. D/dalvikvm:<GC_Reason><Amount_freed>,<Heap_stats>,<Pause_time>

注意这里我仍然是以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中打印的日志：


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

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


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

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

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


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

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

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

[java]view plaincopy

  1. publicclassMainActivityextendsActionBarActivity{

  3. @Override

  4. protectedvoidonCreate(BundlesavedInstanceState){

  5. super.onCreate(savedInstanceState);

  6. setContentView(R.layout.activity_main);

  7. LeakClassleakClass=newLeakClass();

  8. }

  10. classLeakClass{

  12. }

  13. ......

  14. }

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

[java]view plaincopy

  1. publicclassMainActivityextendsActionBarActivity{

  3. @Override

  4. protectedvoidonCreate(BundlesavedInstanceState){

  5. super.onCreate(savedInstanceState);

  6. setContentView(R.layout.activity_main);

  7. LeakClassleakClass=newLeakClass();

  8. leakClass.start();

  9. }

  11. classLeakClassextendsThread{

  13. @Override

  14. publicvoidrun(){

  15. while(true){

  16. try{

  17. Thread.sleep(60*60*1000);

  18. }catch(InterruptedExceptione){

  19. e.printStackTrace();

  20. }

  21. }

  22. }

  23. }

  24. ......

  25. }

这下就有点不太一样了，我们让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命令就可以完成转换工作，如下所示：

[plain]view plaincopy

  1. hprof-convdump.hprofconverted-dump.hprof

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

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


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

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

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

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

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


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

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

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


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

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

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


这里是把当前应用程序中所有的对象的名字、数量和大小全部都列出来了，需要注意的是，这里的对象都是只有Shallow Heap而没有Retained Heap的，那么Shallow Heap又是什么意思呢？就是当前对象自己所占内存的大小，不包含引用关系的，比如说上图当中，byte[]对象的Shallow Heap最高，说明我们应用程序中用了很多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 -> with incoming references查看具体MainActivity实例，如下图所示：


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


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

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

我们在平时写代码时还要注意一些编码规范，这样不仅能够在微观层面提升程序一定的性能，也可以让我们的代码变得更加专业，下面就让我们来一起学习一下这些技巧。

避免创建不必要的对象

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

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

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

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

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

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

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

静态优于抽象

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

对常量使用static final修饰符

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

[java]view plaincopy

  1. staticintintVal=42;

  2. staticStringstrVal="Hello,world!";

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

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

[java]view plaincopy

  1. staticfinalintintVal=42;

  2. staticfinalStringstrVal="Hello,world!";

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

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

使用增强型for循环语法

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

[java]view plaincopy

  1. staticclassCounter{

  2. intmCount;

  3. }

  5. Counter[]mArray=...

  7. publicvoidzero(){

  8. intsum=0;

  9. for(inti=0;i<mArray.length;++i){

  10. sum+=mArray[i].mCount;

  11. }

  12. }

  14. publicvoidone(){

  15. intsum=0;

  16. Counter[]localArray=mArray;

  17. intlen=localArray.length;

  18. for(inti=0;i<len;++i){

  19. sum+=localArray[i].mCount;

  20. }

  21. }

  23. publicvoidtwo(){

  24. intsum=0;

  25. for(Countera:mArray){

  26. sum+=a.mCount;

  27. }

  28. }

可以看到，上述代码当中我们使用了三种不同的循环方式来对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方法呢？这里我举一个非常简单的例子：

[java]view plaincopy

  1. publicclassCalculate{

  3. privateintone=1;

  5. privateinttwo=2;

  7. publicintgetOne(){

  8. returnone;

  9. }

  11. publicintgetTwo(){

  12. returntwo;

  13. }

  15. publicintgetSum(){

  16. returngetOne()+getTwo();

  17. }

  18. }

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

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

[java]view plaincopy

  1. publicclassCalculate{

  3. privateintone=1;

  5. privateinttwo=2;

  7. ......

  9. publicintgetSum(){

  10. returnone+two;

  11. }

  12. }

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


更多相关文章

  1. android基础部分再学习--AIDL
  2. Service与Android系统实现（1）-- 应用程序里的Service（二）
  3. Android几种Service常驻内存的小思路
  4. Android(安卓)studio 3.6 NDK开发 基本流程入门了解
  5. Android(安卓)数据持久化（一）之简单数据持久化
  6. android 4.0以上WebView不能全屏播放视频的解决办法
  7. 如何在Android实现桌面清理内存简单Widget小控件
  8. Android常见的八种导致 APP 内存泄漏的问题
  9. android中使用startActivityForResult回传数据

随机推荐

  1. 推荐文章1
  2. Android之解析Json数据
  3. Android 项目接入Flutter
  4. Android Studio NDk调试(基于gradle-expe
  5. Android 4.0为Launcher主界面所有应用程
  6. 72、android状态栏一体化，状态栏改变颜色
  7. Android：Android(安卓)Studio 优化
  8. Android OPenCV 环境配置
  9. Android建立对话框基本的几种方法
  10. Android获取签名信息命令