c、还有一种很常见的场景是一个页面多图的场景，明明每个图只需要加载一个100_100的，你却使用原始尺寸（1080_1980）or更大，而且你一下子还加载个几十张，扛得住么？所以了解一下inSampleSize，或者，如果图片归你们上传管理，你可以借助万象优图，他为你做了剪切好不同尺寸的图片，这样省得你在客户端做图片缩放了。
二 以上了解了一些性能问题，这里，简单的串一串导致这些性能问题的原因
1、人为在ui线程中做了轻微的耗时操作，导致ui线程卡顿
嗯，很多小伙伴不以为然，以为在onCreate中读一下pref算什么，解析下json数据算得了什么，可实际情况是并不是这样的，正确的做法是，将这些操作使用异步封装起来，小伙伴可以了解一下rxjava，现在最新版本已经是rxjava2了，如果不清楚使用方式，可以Google一下。
2、layout过于复杂，无法在16ms完成渲染
这个很多小伙伴深有体会了，这里简单的了解下，我们先简单的把渲染大概分为"layout","measure""draw"这么几个阶段，当然你不要以为实际情况也是如此，好，层级复杂，layout,measure可能就用到了不该用的时间，自然而然，留给draw的时间就可能不够了，自然而然就悲剧了。那么以前给出的很多建议是，使用RelativeLayout替换LinearLayout,说是可以减少布局层次，然鹅，现在请不要在建议别人使用RelativeLayout，因为ConstraintLayout才是一个更高性能的消灭布局层级的神器。ConstraintLayout 基于Cassowary算法，而Cassowary算法的优势是在于解决线性方程时有极高的效率，事实证明，线性方程组是非常适合用于定义用户界面元素的参数。由于人们对图形的敏感度非常高，所以UI的渲染速度显得非常重要。因此在2016年，iOS和Android都基于Cassowary算法来研发了属于自己的布局系统，这里是ConstraintLayout与传统布局RelativeLayout，LinearLayout实现时的性能对比，不过这里是老外的测试数据，原文可以参考这里。demo中也提供了测试的方法，感兴趣的小伙伴可以尝试一下咯。
测量/布局（单位：毫秒，100 帧的平均值）
3、同一时间执行的动画过多，导致CPU或者GPU负载过重
这里主要是因为动画一般会频繁变更view的属性，导致displayList失效，而需要重新创建一个新的displayList，如果动画过多，这个开销可想而知，如果你想了解得更加详细，推荐看这篇咯，知识点在第5节那里。
4、view过度绘制的问题。
view过度绘制的问题可以说是我们在写布局的时候遇到的一个最常见的问题之一，可以说写着写着一不留神就写出了一个过度绘制，通常发生在一个嵌套的viewgroup中，比如你给他设置了一个不必要的背景。这方面问题的排查不太难，我们可以通过手机设置里面的开发者选项，打开Show GPU Overdraw的选项，轻松发现这些问题，然后尽量往蓝色靠近。
5、gc过多的问题，这里就不在赘述了，上面已经讲的非常直接了。
6、资源加载导致执行缓慢。
有些时候避免不要加载一些资源，这里有两种解决的办法，使用的场景也不相同。
a、预加载，即还没有来到路径之前，就提前加载好，诶，好像x5内核就是酱紫哦。
b、实在是要等到用到的时候加载，请给一个进度条，不要让用户干等着，也不知道什么时候结束而造成不好的用户体验。
7、工作线程优先级设置不对，导致和ui线程抢占cpu时间。
使用Rxjava的小伙伴要注意这点，设置任务的执行线程可能会对你的性能产生较大的影响，没有使用的小伙伴也不能太过大意。
8、静态变量。
嘿嘿，大家一定有过在application中设置静态变量的经历，遥想当年，为了越过Intent只能传递1M以下数据的坑，我在application中设置了一个静态变量，用于两个activity“传递（共享）数据”，然而，一步小心，数据中，有着前一个activity的尾巴，因此泄露了。不光是这样的例子，随便举几个：
a、你用静态集合保存过数据吧？
b、某某单例的Manger，比如管理AudioManger遇到过吧？
三 既然遇到问题分析也有了，那么接下来，自然而然是如何使用各种刀棒棍剑来解决这些问题了
1、GPU过度绘制，定位过度绘制区域
这里直接在开发者选项，打开Show GPU Overdraw，就可以看到效果，轻松发现哪块需要优化，那么具体如何去优化