旧酒新瓶——换个角度提升 App 性能与质量
主讲人：高亮亮 --- 饿了么移动技术部高级iOS工程师，负责饿了么商家版iOS APP开发，对架构和系统底层有深入研究，擅长移动性能分析，trouble shooting，iOS 逆向编程。
主讲时间：2017-05-26
主讲内容：
1、性能与质量概述：
2、“新”技术概念的介绍与实践：
3、违反常规的“真理”：
一、性能与质量概述：
• 应用分级以及与性能质量的关系
• 根据设备特点设计提升方案
• 结合主要业务场景制定优先级
回流(Reflow)/ 重绘(Repaint)
• 回流:流式布局下，由于参照元素布局框发生变化而导致的布局重新计算。
• 重绘:元素布局不发生变化的情况下，重新渲染视图。
案例重现：
• 单张订单视图作为重用的基本单元
• 视图层级复杂，且采用动布局技术
• 视图不固定，且存在强依赖关系
• 商品列表在滚动时产生严重回流
二、解决方案
• 调整视图关系，合理利用重用机制，避免滚动时回流
• ADK 方案，异步计算布局并缓存，细腻的线程控制
节流(Throttle)/ 防抖(Debounce)
案例重现
失败重试导致的 Self-DDoS
• 在保证服务前提下的自动重试，且固定重试频率
• 忽略错误类型，“一刀切”式的 DFF 设计
• 重试周期同步，从而导致恶性循环
解决方案：
• 指数回退 —— 固定重试间隔加倍
• 添加抖动 —— 随机抖动间隔，避免锁定同步周期
• 标记重试 —— 优先处理高重试请求
• “黄金”重试节流策
扩展运用
• 实时查询防抖 —— 减少网络请求
• 事件响应节流 —— 避免冗余资源消耗
• 界面渲染节流 —— 避免大量 CPU 消耗
渐进增强(PE)/ 优雅降级(GD)
案例重现：
基于三方服务的推送系统
• 同业务对推送的实时性、可靠性要求高且存在差异
---➡ 利用更优的组件作为首选，三方作为备选
• 三方服务不可控，且在实时性、可靠性上都存在不足
---➡ 操作的效率和速度随着失效部件的增加逐渐下降
解决方案：
Taco 混合推送框架
|
设备 |
平台 |
系统 |
前后台 |
发送数 |
发送成功数 |
接收消息数 |
到达率 |
|
红 Note3 |
Android |
MIUI 8 |
前台(锁 屏) |
300 |
297 |
267 |
89.9% |
|
锤 |
Android |
Smartisan OS 3.2.5 |
后台( 锁 屏) |
300 |
298 |
250 |
83.9% |
|
Nexus5 |
Android |
6.0 |
后台(锁 屏) |
300 |
296 |
234 |
79.1% |
|
iPhone 6 |
iOS |
iOS 9.1 |
前台( 锁 屏) |
300 |
299 |
299 |
100% |
|
iPhone 4s |
iOS |
iOS 8 |
前台( 锁 屏) |
300 |
296 |
178 |
60.1% |
稳 => 快 => 省，普适法则
• 0崩溃&0错误!=好
• 启动时间:main() 后 main() 前重要
• 包体积优化: 进制 > 资源
• 耗电优化:硬件 > 软件
0 崩溃 & 0 错误 != 好用
0 崩溃 & 0 错误 != 好用
启动时间:main() 后 main() 前重要
• main() 前优化点
‣ dylib loading —— 多为系统动态库，普遍使用静态库
‣ rebase / binding —— 占比低，减少 Class 等行为违反软件工程原则
‣ Objc Setup —— 受工程量影响，盲目优化违反工程原则
‣ Initializer —— + load 优化，影响工程设计
• main() 后优化点
‣ 屏渲染优化
‣ 避免主线程阻塞
‣ 关键路径线程优化
包体积优化: 二进制 > 资源 耗电优化:硬件 > 软件
耗电优化:硬件 > 软件
