打磨APP

2016-09-09 本文已影响399人 shone

1. 为啥要打磨APP,为啥要性能优化?

为了省电,为了快!
安卓手机作为移动设备.它的电量比标准台式机或笔记本电脑少很多.为啥苹果手机体验好,很重要因素也是速度快,基于这些原因,我们有必要关心内存的消耗!
特别是在Android 5.0以前,你想避免触发垃圾回收器.结果就是Android运行时(runtime)有一个大约200ms的冻结期(freeze).
如果用户正在滚动一个list,那将会有一个很明显的延时.

2. 如何优化?

2.1 避免不必要的对象分配

竟量避免创造不必要的objects对象,尤其是在内存有限的情况下.竟可能的去复用对象objects.
创建不必要的objects,只会引起更为频繁的垃圾回收,于情于理都不应该.
例如在咱们的自定义View中,避免在循环体(loops)或者onDraw()方法里创建对象.

2.2 使用高效的数据结构

安卓提供了很多Sparse*Array的实现类,想一下下面这段代码

Map<Integer, String> map = new HashMap<Integer, String>();

数据结构	描述
SparseArray<E>	映射integers到Objects, 避免Integer objects的创建.
SparseBooleanArray	映射 integers 到 booleans.
SparseIntArray	映射 integers 到 integers

用这段代码的结果是不必要的Integer对象创建.
安卓为咱们提供了更高效的为了映射values到objects这样一种数据结构.
下表给出了SparseArrays的例子

数据结构	描述
SparseArray<E>	映射integers到Objects, 避免Integer objects的创建.
SparseBooleanArray	映射 integers 到 booleans.
SparseIntArray	映射 integers 到 integers

为了改进上面的代码,我更倾向下面的写法

SparseArray<String> map = new SparseArray<String>();
map.put(1, "Hello");

2.3 处理bitmaps

Bitmaps如果全尺寸加载需要分配大量的内存.推荐加载期望值大小的尺寸.假如你有
一个应用需要显示100x100dp的图片,你应当以这个精确的大小加载图片.

常规的方法是首先测量未加载的bitmap,通过传递一个标志给BitmapFactory.

// instruct BitmapFactory to only the bounds and type of the image
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);

// get width and height
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
// type of the image
String imageType = options.outMimeType;

后面,我们可以加载压缩过的图片.用下面的方法(来自于官方文档)以2为基数去计算缩放比例因子

public static Bitmap decodeBitmapWithGiveSizeFromResource(Resources res, int resId,
        int reqWidth, int reqHeight) {

    // First decode with inJustDecodeBounds=true to check dimensions
    final BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(res, resId, options);

    // Calculate inSampleSize
    options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);

    // Decode bitmap with inSampleSize set
    options.inJustDecodeBounds = false;
    return BitmapFactory.decodeResource(res, resId, options);
}

public static int calculateInSampleSize(
            BitmapFactory.Options options, int reqWidth, int reqHeight) {
    // Raw height and width of image
    final int height = options.outHeight;
    final int width = options.outWidth;
    int inSampleSize = 1;

    if (height > reqHeight || width > reqWidth) {

        final int halfHeight = height / 2;
        final int halfWidth = width / 2;

        // Calculate the largest inSampleSize value that is a power of 2 and keeps both
        // height and width larger than the requested height and width.
        while ((halfHeight / inSampleSize) > reqHeight
                && (halfWidth / inSampleSize) > reqWidth) {
            inSampleSize *= 2;
        }
    }

    return inSampleSize;
}

用下面的方法很方便地将图片显示到ImageView上面了,

viewWidth = imageView.getWidth();
viewHeight = imageView.getHeight();

imageView.setImageBitmap(
    decodeSampledBitmapFromResource(getResources(), R.id.myimage, viewWidth, viewHeight));

2.4 使用缓存

2.4.1 如何用缓存?

缓存允许重用对象,如果我们想把一个对象加载到内存,是否应该考虑把这个对象作一个缓存.例如,咱们从网络下载图片,然后把它显示到list里,那咱们应该保持它在内存里,以避免多次从网络下载.
很多场景,我们需要去回收一些对象,不然,app会OOM.最好的策略是,回收那些我们很长时间没有用过的对象.
Android平台为我们提供了LruCache类,从API-12(或者用support-v4 library),LruCache类提供了最近最少使用策略的实现.LRU记录了每个对象的使用情况,它有一个给定的大小,如果超过了这个大小,它将移除长时间没用的对象,特性图

下面的代码提供了一个LruCache的简单实现,用来缓存图片:

public class ImageCache extends LruCache<String, Bitmap> {
 
  public ImageCache( int maxSize ) {
    super( maxSize );
  }
 
  @Override
  protected int sizeOf( String key, Bitmap value ) {
    return value.getByteCount();
  }
 
  @Override
  protected void entryRemoved( boolean evicted, String key, Bitmap oldValue, Bitmap newValue ) {
    oldValue.recycle();
  }
 
}

用法很简单

LruCache<String, Bitmap> bitmapCache = new LruCache<String, Bitmap>();

为了确定缓存的初始化大小,最好的策略是基于设备的可用内存总大小,MemoryClass这个类
可以获得总大小,看下面的例子

int memClass = ( ( ActivityManager) activity.getSystemService( Context.ACTIVITY_SERVICE ) ).getMemoryClass();
int cacheSize = 1024 * 1024 * memClass / 8;
LruCache cache = new LruCache<String, Bitmap>( cacheSize );

2.4.2 清理缓存

从API-14,我们能重写onTrimMemory()方法,这个方法被调用的时候,说明系统正告诉你
需要清理内存了,安卓系统需要资源来维护前台进程.

@Override
public void onTrimMemory(int level) {
      super.onTrimMemory(level);
      switch (level){
          case TRIM_MEMORY_RUNNING_MODERATE:{//5
              break;
          }
          case TRIM_MEMORY_RUNNING_LOW:{//10
              break;
          }
          case TRIM_MEMORY_RUNNING_CRITICAL:{//15
              break;
          }
          case TRIM_MEMORY_UI_HIDDEN:{//20
              break;
          }
          case TRIM_MEMORY_BACKGROUND:{//40
              break;
          }
          case TRIM_MEMORY_MODERATE:{//60
              break;
          }
          case TRIM_MEMORY_COMPLETE:{//80
              break;
          }
      }
}

Android系统会根据不同等级的内存使用情况，调用这个函数，并传入对应的等级：

    TRIM_MEMORY_UI_HIDDEN 表示应用程序的 所有UI界面 被隐藏了，即用户点击了Home
键或者Back键导致应用的UI界面不可见．这时候应该释放一些资源．

    TRIM_MEMORY_UI_HIDDEN这个等级比较常用，和下面六个的关系不是很强，所以单独说．

下面三个等级是当我们的应用程序真正运行时的回调：

    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缓存列表的最边缘
位置，系统会最优先考虑杀掉我们的应用程序，在这个时候应当尽可能地把一切可以释放的东西都进行释放。

原文:
http://www.vogella.com/tutorials/AndroidApplicationOptimization/article.html