android开发之Android应用性能评测调优

前言

在智能手机App竞争越来越激烈的今天，Android App各项性能如CPU、内存消耗等都是我们在开发测试中需要关注的指标，如何将App打造得更加“优雅”是我们需要不断追求探索的方向，下面我们从内存和流畅度两个维度来说说如何对Android App进行评测和调优。

一、内存

内存不是无限使用的，如果内存过大或泄露会出现OOM（Out Of Memory）、UI不流畅等问题，因此内存也是一个稀缺资源，我们应该保证没有内存泄露且对不需要使用的内存及时释放。一般内存测试或分析内存问题可以分为下面几步：

• 编译代码
• 选定测试场景（来自于经验&开发）
• 测试场景转换成用例
• 跑起工具Run用例
• 结合代码，分析，分析…

1.内存测试通用的方法

• DDMS（Heap&Allocation Tracker）

  • Heap查看堆的分配情况：

  

  主要关注两项数据：

  1. Heap Size堆的大小，当资源增加，当前堆的空余空间不够时，系统会增加堆的大小。
  2. Allocated堆中已分配的大小，这是应用程序实际占用的内存大小，资源回收后，此项数据会变小。

  注：如果进行反复操作或堆的大小一直增加，则有内存泄露的隐患。

  • Allocation Tracker跟踪内存分配情况：

  

• MAT（Memory Analyzer）

  Leak Suspects：内存泄露报告
  Top Components：吃货报告
  Histogram：每个Class占用内存
  Dominator Tree：列出哪些对象占用内存最多以及谁hold住这些对象

2.Android常见的内存问题

• 万恶的Static通常见到在单例模式

  static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。

  public class ClassName {  
       private static Context mContext;  
       //省略  
  }  

  以上的代码是很危险的，如果将Activity赋值到mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。

  举Android文档中的一个例子：

  private static Drawable sBackground;  
  
  @Override  
  protected void onCreate(Bundle state) {  
      super.onCreate(state);  
      TextView label = new TextView(this);  
      label.setText("Leaks are bad");  
      if (sBackground == null) {  
          sBackground = getDrawable(R.drawable.large_bitmap);  
      }  
      label.setBackgroundDrawable(sBackground);  
      setContentView(label);  
  }

  sBackground, 是一个静态的变量，但是我们发现，我们并没有显式的保存Context的引用，但是，当Drawable与View连接之后，Drawable就将View设置为一个回调，由于View中是包含Context的引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：Drawable->TextView->Context

  所以，最终该Context也没有得到释放，发生了内存泄露。

  下面就是一个例子，static变量占用过大的内存（7.1M），这里碰到该情况需要具体分析里面数据是否都是需要常驻的，不要把很多不相干的变量设为static属性。

  

  针对static的解决方案：

  • 第一、应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。
  • 第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。

  • 第三、使用WeakReference代替强引用。比如可以使用WeakReference< Context> mContextRef。

    该部分的详细内容也可以参考Android文档中Article部分。

• 多线程生命周期过长hold住本该释放资源

  线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。

  public class MyActivity extends Activity {  
      @Override  
      public void onCreate(Bundle savedInstanceState) {  
          super.onCreate(savedInstanceState);  
          setContentView(R.layout.main);  
          new MyThread().start();  
      }  
  
      private class MyThread extends Thread{  
          @Override  
          public void run() {  
              super.run();  
              //do somthing  
          }  
      }  
  }  

  这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一 般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。

  由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。

  有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。

  针对这种线程导致的内存泄露问题的解决方案：

  • 第一、将线程的内部类，改为静态内部类。
  • 第二、在线程内部采用弱引用保存Context引用。

• 大胖子Bitmap

  

  图上可以看到Bitmap占用内存很大（5.7M），利用MAT来找到他的outgoing和incoming引用：

  

  可以找到这块内存的引用关系，然后找代码。

  

  在遇到图片资源占用过大的情况，建议：

  1）及时调用recycle()进行销毁释放；
  2）设置一定的采样率；
  3）巧妙的运用软引用（SoftRefrence）；
  使用Bitmap后没有保留对它的引用,无法调用recycle(),这就得运用软引用,使得Bitmap在内存快不足的时候有效的释放

  SoftReference<String> soft = new SoftReference<String>(被软引用对象);
  soft.clear();

  4）进行压缩。
  

• Cursor
  Cursor用完记得关掉，如果实在不确定Cursor是否关闭，可以在onDestroy中关了。
  

喜欢的朋友，请来点点评…