Android进阶性能优化
1.App性能概览与平台化实践
1
2
3
//性能优化
性能优化:包括了启动，内存，布局，卡顿，网络，电量，瘦身，稳定性；
性能监测平台：外网：听云，内网：自检各种性能检测机制，统一上报；

一、背景介绍

性能优化有哪些难题？

1
2
3
4
5
6
7
8
9
10
11
12
1.性能表现差
	- App启动慢、卡顿、丢帧
	- 内存占用高、抖动频繁
	- 耗电、网络请求慢
	- 崩溃率、异常率高
2.线上问题无从追查
	- 如何保证异常感知灵敏度
	- 如何复原"案发"现场
	- 如何快速"止血"（修复）成功
3.性能优化的长期开销大
	- 如何扼杀问题于萌芽
	- 优化效果如何长期保持

相反的对性能优化要求

1
2
3
1.性能表现好
2.线上问题易追查
3.长期投入小

二、不同项目阶段，性能解决方案的演进

1
2
3
4
5
6
7
8
9
10
11
12
1.项目初期（快速开发阶段，快速占领市场的阶段）
	只关心崩溃率、不采集性能数据
  没有性能检测、优化方案
  没有排查问题手段
2.项目壮大期（项目的发展和用户的增多时，逐渐的开始重视性能优化）
	指标采集，不够全及深入
	接入成熟APM，排查手段单一
	线下检测、优化，方案不成型
3.项目成熟期（用户已达到数百万，重视性能优化）
	重点关注性能问题，数据丰富，手段多样化
	线上、线下一整套完善解决方案(重点)
	自建APM，新产品可快速接入

线上线下各一套解决方案的原因

1
2
3
1.误区:对线上不重视
2.侧重点:线下预防、线上监控
3.方案不同:线下可用黑科技

为什么自建APM(应用性能监控平台)

1
2
3
1.成熟APM通用，但不满足个性化需求
2.外部APM与内部系统难打通，带来的时间成本
3.数据必须掌握在自己手中

三、业界优秀的平台

1
2
3
1.Crash收集平台
2.APM平台
3.自建解决方案

Crash收集平台

1
2
3
4
Bugly为代表
- 数据采集、上报成功率高
- 包含Java、Native崩溃
- 建议项目初期接入

APM平台

1
2
3
听云为代表
 - 通用的性能解决方案，数据采集完善
 - 方便接入，但不满足个性化需求，数据隐患

自建解决方案

1
2
3
美团、携程、360等
 - 贴合自身业务特点，满足定制化需求
 - 数据安全

四、问题

1
2
3
4
5
6
7
8
9
10
11
1.你们为什么要做性能优化
 - 体验差影响核心指标
 - 线上问题追查困难
 - 降低性能优化的长期开销
2.介绍一下你们的性能平台
 - 交代背景
 - 具体讲解
3.你们为什么要自建APM
 - 需求层面
 - 效率层面
 - 数据安全