认识达内从这里开始

关于软件性能优化的问题我们已经讨论过很多次了，今天我们就直接来了解和学习一下，性能优化的具体操作内容都有哪些吧。

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

这个是内存泄露监测的银弹，大家应该都使用过，需要提醒一下的是，要注意

引入方式，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耗时较多。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。