a、减少布局层级，上面有提到过，使用ConstraintLayout替换传统的布局方式。如果你对ConstraintLayout不了解，没有关系，这篇文章教你15分钟了解如何使用ConstraintLayout。
b、检查是否有多余的背景色设置，我们通常会犯一些低级错误--对被覆盖的父view设置背景，多数情况下这些背景是没有必要的。
2、主线程耗时操作排查。
a、开启strictmode,这样一来，主线程的耗时操作都将以告警的形式呈现到logcat当中。
b、直接对怀疑的对象加@DebugLog，查看方法执行耗时。DebugLog注解需要引入插件hugo，这个是Android之神JakeWharton的早期作品，对于监控函数执行时间非常方便，直接在函数上加入注解就可以实现，但是有一个缺点，就是JakeWharton发布的最后一个版本没有支持release版本用空方法替代监控代码，因此，我这里发布了一个到公司的maven仓库，引用的方式和官网类似，只不过，地址是：'com.tencent.tip:hugo-plugin:2.0.0-SNAPSHOT'。
3、对于measure，layout耗时过多的问题
一般这类问题是优于布局过于复杂的原因导致，现在因为有ConstraintLayout，所以，强烈建议使用ConstraintLayout减少布局层级，问题一般得以解决，如果发现还存在性能问题，可以使用traceView观察方法耗时，来定位下具体原因。
4、leakcany
这个是内存泄露监测的银弹，大家应该都使用过，需要提醒一下的是，要注意
dependencies {
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.5.4'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'
}
引入方式，releaseImplementation保证在发布包中移除监控代码，否则，他自生不停的catch内存快照，本身也影响性能。
5、onDraw里面写代码需要注意
onDraw优于大概每16ms都会被执行一次，因此本身就相当于一个forloop，如果你在里面new对象的话，不知不觉中就满足了短时间内大量对象创建并释放，于是频繁GC就发生了，嗯，内存抖动，于是，卡了。因此，正确的做法是将对象放在外面new出来。
6、json反序列化问题
json反序列化是指将json字符串转变为对象，这里如果数据量比较多，特别是有相当多的string的时候，解析起来不仅耗时，而且还很吃内存。解决的方式是：
a、精简字段，与后台协商，相关接口剔除不必要的字段。保证最小可用原则。
b、使用流解析，之前我考虑过json解析优化，在Stack Overflow上搜索到这个。于是了解到Gson.fromJson是可以这样玩的，可以提升25%的解析效率。
7、viewStub&merge的使用。
这里merge和viewStub想必是大家非常了解的两个布局组件了，对于只有在某些条件下才展示出来的组件，建议使用viewStub包裹起来，同样的道理，include 某布局如果其根布局和引入他的父布局一致，建议使用merge包裹起来，如果你担心preview效果问题，这里完全没有必要，因为你可以
tools:showIn=""属性，这样就可以正常展示preview了。
8、加载优化
这里并没有过多的技术点在里面，无非就是将耗时的操作封装到异步中去了，但是，有一点不得不提的是，要注意多进程的问题，如果你的应用是多进程，你应该认识到你的application的oncreate方法会被执行多次，你一定不希望资源加载多次吧，于是你只在主进程加载，如是有些坑就出现了，有可能其他进程需要那某份资源，然后他这个进程缺没有加载相应的资源，然后就嗝屁了。
9、刷新优化。
这点在我之前的文章中有提到过，这里举两个例子吧。
a、对于列表的中的item的操作，比如对item点赞，此时不应该让整个列表刷新，而是应该只刷新这个item，相比对于熟练使用recyclerView的你，应该明白如何操作了,不懂请看这里，你将会明白什么叫做recyclerView的局部刷新。