GPU分析办法：

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

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

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

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接近。