android 开启离屏缓存,Android性能优化笔记（持续更新帖）

GPU分析办法：java

先定位问题缘由、后寻找解决办法、最后验证多种办法的解决效果。卡顿问题快速定位的方法：linux

1. 打开开发者模式中GPU呈现模式分析，查看是那种颜色条高： android

2. 若是是蓝色偏高，说明是单位消息里CPU太耗时，得把方法的执行都打出来看看哪一个耗时。canvas

3. 若是红色偏高，说明GPU忙不过来。优化过渡绘制，使用离屏缓存来优化。缓存

4. 黄色偏高，说明半透明GPU不只在忙着绘制你的window也还忙着绘制别的，可能的状况为透明window叠加多了，window里的contentView有多个且相对复杂，或者GPU降频了等等，想具体分析须要查看GPU的trace。性能

图片列表优化思路：优化

内存图片缓存仍是有三级：一级是bitmap列表，一级是LRU强引用，一级是弱引用。加载图片时，先在弱引用缓存和LRU强引用中查找没有被释放的bitmap，若是存在并知足复用条件，则不建立bitmap，而使用该图片内存，以后将其从弱引用或者LRU中移出放入bitmap列表强引用中。bitmap列表强引用保存了该图片依赖的直接控件。当view的onDetachedFromWindow被调用则从bitmap列表中移除只有依赖该view的对象到LRU强应用中。若是LRU强引用满了则放到弱引用中。动画

Service保活思路：对象

先从老式最基础的开始：1.使用startService方式启动一个独立进程的服务，这样系统会在service意外死亡后自动重启。2. 使用RTC定时闹钟每5分钟检测一下(4.0以上基本无效)3.启动linux守护进程，每几分钟检测一下进程是否存在，不存在就startService(5.0如下除MIUI和华为外有效) 4. 5.0以上使用JobScheduler代替闹钟定时检测启动 5. 启动隐藏的前台通知。但这些措施都不能100%保活。进程

关于软件离屏缓存和硬件离屏缓存

系统默认全部的绘制都在一个内存块进行，经过canvas的matrix栈来控制绘制每一个View的绘制区域，让系统再次建立一个内存块来绘制的方法有View的setLayerType()，能够在内存或者是GPU上建立一块内存，先绘制到该内存上，而后绘制到系统的那个内存上。

setLayerType(View.LAYER_TYPE_SOFTWARE, null); 启动软件离屏缓存

setLayerType(View.LAYER_TYPE_HARDWARE, null); 启动硬件离屏缓存(硬件加速)

内存上Bitmap绘制比硬件加速下绘制慢了30倍

因此若是多个bitmap是在一个View的onDraw方法绘制的，那么只须要在View的构造方法里添加setLayerType(View.LAYER_TYPE_HARDWARE, null);可大大提高绘制效率。

通常使用离屏缓冲是为了节省GPU执行录制的绘制命令的时间，好比你的绘制操做不少，并且执行这些绘制时缓冲是有效的，好比平移整个listView。

若是你看到你的GPU柱状条中的红色很高，这时能够考虑使用硬件离屏缓冲

通常在建立硬件离屏缓冲的时候，建立的那一帧是比较耗时的，因此你的动画里有个条线比较高，但能够规避让其不影响动画性能。好比在动画开始以前开启离屏缓存。

关于软引用的梗

在android低版本上，SoftwareRefrence是遵循java标准的GC回收流程，即只有触发GC的状况为内存不足时，才会去检查SoftReference，但在高版本上，SoftReference被检查的更频繁了，即不是只有内存不足时才去检查，其存在的几率与WeakReference接近。