Android App 性能优化

快、稳、省、小

• 流程的操作体验
• 稳定
• 省电、省流量
• 安装包小

不好的体验

• 卡顿
• 内存泄露、崩溃
• 代码质量和逻辑差导致耗流量、耗电
• 安装包过大

快 怎么才能快？

影响卡顿的因素？

• UI的刷新、绘制
• 启动，冷启动、热启动、温启动
• 跳转、页面跳转、前后台切换
• 即时反馈、点击事件、滑动事件、系统事件等等

UI

UI绘制原理

• Android 显示过程可以简单概括为：Android 应用程序把经过测量,布局、绘制后的 surface 缓存数据，通过 SurfaceFlinger 把数据渲染到显示屏幕上， 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕上。

• 换一种方式说：Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。（注：FPS 表示每秒传递的帧数。）在理想情况下，60 FPS 就感觉不到卡，这意味着每个绘制时长应该在16 ms 左右。如果某个操作花费的时间是 24ms ，系统在得到 VSYNC 信号时就无法正常进行正常渲染，这样就发生了丢帧现象。也就是延迟了，这种现象在执行动画或滑动列表比较常见，还有可能是你的 Layout 太过复杂，层叠太多的绘制单元，无法在 16ms 完成渲染，最终引起刷新不及时.

布局优化

• 合理使用背景颜色
• 减少不必要的嵌套层
• 推荐使用Google的新布局：ConstraintLayout

绘制优化

• onDraw中不要创建新的布局对象
• onDraw方法中不要做耗时的任务
• 刷新，尽量减少不必要的刷新、减少刷新面积

启动优化

冷启动是指安装 apk 后首次启动应用程序，或者应用程序上次结束，进程被杀死后重新打开app

• Application的创建过程中，尽量较少耗时操作，比如之前onCreat方法中，做了太多事情，比如地图、友盟、Bugly、等SDK init的操作，那我们现在可以先把网络层初始化，把SDK的加载操作放在onResume方法中。
• 生命周期方法中减少耗时操作

稳

主线程优化

• 内存优化、避免内存泄漏

那些地方会引起内存泄露？

• 集合类泄露，集合list.add()之后，如果不用了尽量list.clear()之后再list = null

• 单例、静态变量 单例引起的内存泄漏，通常是由于引用的context是生命周期短造成的，也就是说生命周期长的持有了生命周期短的引用，造成了内存泄漏。比如Toast，我们传入的是MainActivity，但MainActivity没有用了，需要被销毁，但我们的Tost依然持有其引用导致无法回收，这就导致了内存泄漏。匿名内部类或非静态内部类导致的内存泄漏，这个我们可以采用合理使用JAVA的引用机制来解决，参考Android-强，软，弱，虚引用

• 匿名内部类、非静态内部类

资源未关闭造成的内存泄露

• 网络、文件等流忘记关闭
• 手动注册广播的时候，退出的时候忘记unregisterReceiver()
• Service执行完毕后，忘记stopSelf()
• EventBus等观察者模式的框架忘记手动解除注册
• Bitmap使用完毕，忘记及时Recycle()

小

哪些文件影响包大小？

• assets文件夹，不会生成ID，使用AssetManager类接口获取
• res 会生成ID并映射到R文件，访问的时候直接通过资源ID来
• META-INF 保存应用的签名信息，签名信息可以验证APK的完整性
• AndroidMainfest.xml 这个文件用来描述Android应用的配置信息，一些组件的注册信息，可使用权限等等
• classes.dex Dalvik 字节码程序，让 Dalvik 虚拟机可执行，一般情况下，Android 应用在打包时通过 Android SDK 中的 dx 工具将 Java 字节码转换为 Dalvik 字节码
• resources.arsc 记录着资源文件和资源ID之间的映射关系，用来根据资源ID寻找资源

减少APK包大小的方式

• 使用Studio自带的扫描分析工具lint删除无用资源
• 开启混淆，设置 shrinkResources true和 minifyEnabled true
• 借助第三方工具如 :乐固加固，360压缩
• 不要重复使用库
• 插件化，比如功能模块放在服务器上，按需下载

省

• 省电 谷歌推荐使用 JobScheduler，来调整任务优先级等策略来达到降低损耗的目的。JobScheduler 可以避免频繁的唤醒硬件模块，造成不必要的电量消耗。避免在不合适的时间(例如低电量情况下、弱网络或者移动网络情况下的)执行过多的任务消耗电量
• 省内存 图片压缩
• 图片尺寸压缩、图片质量压缩 Glide就是采用了 Lrucache 和 LruDiskCache 推荐使用
• 省 CPU 资源 线程的使用，这里我推荐使用线程池 https://www.jianshu.com/p/07eb2f7db0ee
• 序列化采用推荐的 Parcelable 代替 Serializable
• 集合如果是插入和删除用的多，建议使用 LinkList。如果修改用的多，建议 ArrayList
• 对常量使用 static final，适用于基本类型和 String 常量
• 使用增强的 for 循环语法（foreach)
• 避免使用浮点数,浮点数比 Android 设备上的整数慢约2倍
• 尽可能少用 wrap_content，wrap_content 会增加布局 measure 时计算成本
• 删除控件中无用的属性
• 合理使用动画，某些情况下可以用硬件加速方式来提供流畅度，或者采用自定义view代替动画，最后记得在Activity的ondestory()方法中调用Animation.cancle()进行动画停止
• 考虑 StringBuilder 代替 String
• 数据量比较大或者内存比较宽裕考虑 HashMap，其他建议使用 SpareArray