《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
完整开源地址：https://docs.qq.com/doc/DSkNLaERkbnFoS0ZF
有些时候避免不要加载一些资源，这里有两种解决的办法，使用的场景也不相同。
a、预加载，即还没有来到路径之前，就提前加载好，诶，好像x5内核就是酱紫哦。
b、实在是要等到用到的时候加载，请给一个进度条，不要让用户干等着，也不知道什么时候结束而造成不好的用户体验。
7、工作线程优先级设置不对，导致和ui线程抢占cpu时间。
使用Rxjava的小伙伴要注意这点，设置任务的执行线程可能会对你的性能产生较大的影响，没有使用的小伙伴也不能太过大意。
8、静态变量。
嘿嘿，大家一定有过在application中设置静态变量的经历，遥想当年，为了越过Intent只能传递1M以下数据的坑，我在application中设置了一个静态变量，用于两个activity“传递（共享）数据”，然而，一步小心，数据中，有着前一个activity的尾巴，因此泄露了。不光是这样的例子，随便举几个：
a、你用静态集合保存过数据吧？
b、某某单例的Manger，比如管理AudioManger遇到过吧？
三 既然遇到问题分析也有了，那么接下来，自然而然是如何使用各种刀棒棍剑来解决这些问题了
1、GPU过度绘制，定位过度绘制区域
这里直接在开发者选项，打开Show GPU Overdraw，就可以看到效果，轻松发现哪块需要优化，那么具体如何去优化
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的局部刷新。
b、对于较为复杂的页面，个人建议不要写在一个activity中，建议使用几个fragment进行组装，这样一来，module的变更可以只刷新某一个具体的fragment，而不用整个页面都走刷新逻辑。但是问题来了，fragment之间如何共享数据呢？好，看我怎么操作。
Activity将数据这部分抽象成一个LiveData，交个LiveDataManger数据进行管理，然后各个Fragment通过Activity的这个context从LiveDataManger中拿到LiveData,进行操作，通知activity数据变更等等。哈哈，你没有看错，这个确实和Google的那个LiveData有点像，当然，如果你想使用Google的那个，也自然没问题，只不过，这个是简化版的。项目的引入
‘com.tencent.tip:simple_live_data:1.0.1-SNAPSHOT’
10、动画优化
这里主要是想说使用硬件加速来做优化，不过要注意，动画做完之后，关闭硬件加速，因为开启硬件加速本身就是一种消耗。下面有一幅图，第二幅对比第一幅是说开启硬件加速和没开启的时候做动画的效果对比，可以看到开启后的渲染速度明显快不少，开启硬件加速就一定万事大吉么？第三幅图实际上就说明，如果你的这个view不断的失效的话，也会出现性能问题，第三图中可以看到蓝色的部曲线图有了一定的起色，这说明，displaylist不断的失效并重现创建，如果你想了解的更加详细，可以查看这里
11耗电优化
这里仅仅只是建议；
a、在定位精度要求不高的情况下，使用wifi或移动网络进行定位，没有必要开启GPS定位。
b、先验证网络的可用性，在发送网络请求，比如，当用户处于2G状态下，而此时的操作是查看一张大图，下载下来可能都200多K甚至更大，我们没必要去发送这个请求，让用户一直等待那个菊花吧。
四 接下来的一些内容就比较轻松了，是关于一些代码的建议
这里不一一细讲了，仅仅挑标记的部分说下。
pb->model这里的优化就不在赘述，前面有讲如何优化。
然后建议使用SparseArray代替HashMap,这里是Google建议的，因为SparseArray比HashMap更省内存，在某些条件下性能更好，主要是因为它避免了对key的自动装箱比如（int转为Integer类型），它内部则是通过两个数组来进行数据存储的，一个存储key，另外一个存储value，为了优化性能，它内部对数据还采取了压缩的方式来表示稀疏数组的数据，从而节约内存空间。
不到不得已，不要使用wrap_content,推荐使用match_parent,或者固定尺寸，配合gravity=“center”，哈哈，你应该懂了的。
那么为什么说这样会比较好。
因为 在测量过程中，match_parent和固定宽高度对应EXACTLY ,而wrap_content对应AT_MOST,这两者对比AT_MOST耗时较多。
五 总结
这是以上关于我在工作中遇到的性能问题的及处理的一些总结，性能优化设计的方方面面实在是太多太多，本文不可能将全部的性能问题全部总结的清清楚楚，或许还多多少少存在一些纰漏之处，有不对的地方欢迎指出补充。
另外本人也自己工作七八年来总结的学习资料一起分享出来，希望能帮到有需要的朋友；
Android架构视频+BAT面试专题PDF+学习笔记
性能优化是Android高工的一个分水岭，搞清楚这块对技术和薪资的提升很关键。
来，希望能帮到有需要的朋友；
Android架构视频+BAT面试专题PDF+学习笔记
性能优化是Android高工的一个分水岭，搞清楚这块对技术和薪资的提升很关键。
134
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
