Android性能分析

• Android内存优化之一：MAT使用入门 · Android Performance

• Android内存优化之二：MAT使用进阶 · Android Performance

• Android内存优化之三：打开MAT中的Bitmap原图 · Android Performance

查看MAT中的Bitmap

使用ImageMagick 更方便 convert -size 'width'x'height' -depth 8 filename.rgba filename.png

MAC安装ImageMagick

• 【腾讯WeTest干货分享】我这样减少了26.5M java内存！

• Android OOM案例分析 -

• Adapter最佳实践 - 掘金

• 爱奇艺Android移动客户端app瘦身经验

  把枚举替换成注解 Enum替换成Annotation

• Android 性能优化必知必会

• Android应用内存泄露分析、改善经验总结

• Android开发者选项-GPU呈现模式分析

每种颜色代表每一帧渲染过程中需要完成的某一件事情，因为6.0之前的三种颜色不大能够清晰地帮助我们定位性能问题的具体原因，所以从6.0开始，将每一帧的渲染过程拆分成了8个步骤，每个步骤一种颜色，每种颜色的意义如下：

image.png

1. Swap Buffers：表示处理任务的时间，也可以说是CPU等待GPU完成任务的时间，线条越高，表示GPU做的事情越多；
2. Command Issue：表示执行任务的时间，这部分主要是Android进行2D渲染显示列表的时间，为了将内容绘制到屏幕上，Android需要使用Open GL ES的API接口来绘制显示列表，红色线条越高表示需要绘制的视图更多；
3. Sync & Upload：表示的是准备当前界面上有待绘制的图片所耗费的时间，为了减少该段区域的执行时间，我们可以减少屏幕上的图片数量或者是缩小图片的大小；
4. Draw：表示测量和绘制视图列表所需要的时间，蓝色线条越高表示每一帧需要更新很多视图，或者View的onDraw方法中做了耗时操作；
5. Measure/Layout：表示布局的onMeasure与onLayout所花费的时间，一旦时间过长，就需要仔细检查自己的布局是不是存在严重的性能问题；
6. Animation：表示计算执行动画所需要花费的时间，包含的动画有ObjectAnimator，ViewPropertyAnimator，Transition等等。一旦这里的执行时间过长，就需要检查是不是使用了非官方的动画工具或者是检查动画执行的过程中是不是触发了读写操作等等；
7. Input Handling：表示系统处理输入事件所耗费的时间，粗略等于对事件处理方法所执行的时间。一旦执行时间过长，意味着在处理用户的输入事件的地方执行了复杂的操作；
8. Misc Time/Vsync Delay：表示在主线程执行了太多的任务，导致UI渲染跟不上vSync的信号而出现掉帧的情况；

• Android 内存优化总结 & 实践

尽管现在已经有比较先进的图片加载组件类似Glide，Facebook Freso, 或者老牌Universal-Image-Loader，但是有时就是需要手动拿到一个bitmap或者drawable，特别是在一些可能会频繁调用的场景(比如ListView的getView)，怎样尽可能对bitmap进行复用呢？这里首先需要明确的是对同样的图片，要 尽可能复用，我们可以简单自己用WeakReference做一个bitmap缓存池，也可以用类似图片加载库写一个通用的bitmap缓存池，可以参考 GlideBitmapPool[8]的实现。
我们也来看看系统是怎么做的，对于类似在xml里面直接通过android:background或者android:src设置的背景图片，以ImageView为例，最终会调用Resource.java里的loadDrawable:

{
   // Next, check preloaded drawables. These may contain unresolved theme
   // attributes.
   final ConstantState cs;
   if (isColorDrawable)
   {
       cs = sPreloadedColorDrawables.get(key);
   }else{
       cs = sPreloadedDrawables[mConfiguration.getLayoutDirection()].get(key);
   }

   Drawable dr;
   if (cs != null) {
       dr = cs.newDrawable(this);
   } else if (isColorDrawable) {
       dr = new ColorDrawable(value.data);
   } else {
       dr = loadDrawableForCookie(value, id, null);
   }

   ...
   
   return dr;
}

可以看到实际上系统也是有一份全局的缓存，sPreloadedDrawables, 对于不同的drawable，如果图片时一样的，那么最终只会有一份bitmap(享元模式)，存放于BitmapState中，获取drawable时，系统会从缓存中取出这个bitmap然后构造drawable。而通过BitmapFactory.decodeResource()则每次都会重新解码返回bitmap。所以其实我们可以通过context.getResources().getDrawable再从drawable里获取bitmap，从而复用bitmap，然而这里也有一些坑，比如我们获取到的这份bitmap，假如我们执行了recycle之类的操作，但是假如在其他地方再使用它是那么就会有”Canvas: trying to use a recycled bitmap android.graphics.Bitmap”异常。