版权声明：该博客为博主原创,转载请标明出处! https://blog.csdn.net/DJH2717/article/details/83017174
其实说白了, 性能优化主要就是围绕如下四个方面去进行扩展和探索:
1, 快 --- 速度快
2, 稳 --- 稳定, 不动不动就 crash
3, 省 --- 省内存, 省电量,流量
4, 小 --- APK小
于是乎, 本文也围绕如上 四个 方向, 从三个方面入手, 总结看过的书籍和博客中所说到的性能优化的手段.
1, 布局优化
- 尽可能减少布局嵌套, 布局树不要超过 10 层, 其系统已经嵌套了 3 层 (DecorView一层, DecorView 的 子 view 是一个 垂直的 LinearLayout 一层, 然后是摆放我们的 xml 文件的 contentLayout 一层).
- 使用 google 最新的 约束布局, 性能比 相对布局高 40%(官方描述), 有效减少布局层级.
- 使用 <include> 标签实现布局复用 ,注意: 如果被 include 的布局指定了 id, 同时 include 标签也指定了 id, 以 include 标签为准.
- 配合 <merge> 使用, 用来去除重复的布局嵌套.
- 使用 viewStub 来进行延时加载, 其效率要比 gone 高, gone 仅仅是 view 不显示也不占用大小, 但是依然会得到初始化, viewStub 就不会.
2, 绘制优化
- 在设置中打开过渡绘制显示, 屏幕上面会显示出不同的颜色, 无色没有过渡绘制, 蓝色-- 1, 绿色 -- 2, 浅红色 -- 3, 深红色 -- 4, 要尽量减少红色区域, 使蓝色区域最大化.
- 不要在 onDraw 方法中创建局部变量, 不要执行上千次循环, 不要耗时!!
- 关于如何减少过渡绘制, 主要的思路是, 如果一个 view 设置了一些需要绘制的属性, 比如 viewGroup 的背景, 但是却又看不到时, 比如子 view 全屏显示, 那么就无需设置 viewGroup 的背景从而导致不必要的绘制.
3, 内存优化
- 常量设置为 static.
- 在必要的场景可以使用多进程开发.
- 在 onTrimMemory 方法中获取到进程 UI 隐藏时的信息, 从而释放掉一部分 UI 占用的内存.
- 内存泄露问题, 常见的有动画播放, 匿名内部类, 通过静态字段持有 activity 的 context 等方面, 都会导致内存泄露.
- 慎用 枚举 , 但是在必要的场景也可以使用, 比如一组相互关联的常量. 对于其他情况, 可使用常量和自定义注解来替换枚举.
- 对于 recyclerView 这类可能会展示较多 bitmap 的组件, 合理的使用缓存机制, 或者使用较为成熟的图片加载框架, 如 Glide.
- 可以通过重写 activity 的 onTrimMemory 方法来获取当前进程的内存状态, 我们可以根据系统传入的状态数据, 来判断进程是否很有可能被杀死, 如果可能, 我们可以尽量释放不是必须的内存占用, 减少内存消耗, 从而提高不被杀死的几率.
3, 其他优化
- 使用 ProGuard 来剔除不需要的代码.
- 使用 zipAlign 来对 APK 进行 4 字节对其, 能够稍微减少 apk 体积.
- 不要创建大量的 services, 如果 services 任务执行完成后要及时 destroy, 较好的手段是使用 intentServices.
- 使用 Android 中特有的数据结构如 SparseArray, 其在某些场景下可以替换 HashMap, 其实现原理是关联数组, 取消了对基本数据类型的装箱和拆箱的过程, 因此效率较高.
- 使用过的 File , Cursor 等其他资源都要及时关闭.
- 对于不必要设置成 private 的字段可以直接 暴露, 避免多次不必要的函数调用开销.
对于电量, 流量方面的优化, 有待后续研究....