性能优化难题

性能表现差

App启动慢,卡顿,丢帧
内存占用高,抖动频繁
耗电,网络请求慢
崩溃率,异常率(应用无法正常作出反馈)高

线上问题无从追查

如何保证异常感知灵敏度
如何复原“案发”现场
如何快速“止血”成功

性能优化的长期开销大

如何扼杀问题于萌芽
优化效果如何长期保持

总结

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

性能优化方案演进

项目初期

只关心崩溃率,不采集性能数据
没有性能检测,优化方案
没有排查问题手段

项目壮大期

指标采集,不够全及深入
接入成熟APM,排查手段单一
线下检测,优化,方案不成型

项目成熟期

重点关注性能问题,数据丰富,手段多样化
线上,线下一套完善解决方案
自建APM,新产品可快速接入

线上线下

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

为什么自建APM

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

业界优秀的平台化实践初步认知

Crash收集平台

Bugly为代表
1.数据采集,上报成功率高
2.包含java,native崩溃
3.建议项目初期接入

APM平台

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

自建解决方案

1.贴合自身业务特点,满足定制化需求
2.数据安全

面试套路

注意事项

面试不仅仅是技术点的考察
职业生涯上台阶不能只埋头做技术
大局观,视野,沟通技巧,语言表达能力,总结能力,深入思考能力,逻辑性,条理性

答题套路

找答案:立足项目整个周期
将案例:找普遍痛点,拉进距离感
超预期:体现你和别人的区别

具体问题

你们为什么要做性能优化
1.体验不好影响核心指标
2.线上问题追查困难
3.降低性能优化的长期开销(平台化,工具化)

介绍一下你们的性能优化平台
1.交代背景
2.具体讲解

你们为什么要自建APM
1.需求层面
2.效率层面
3.数据安全