今年年初, 我去上海参加一个移动技术会议, 问了很多开发者最近在忙啥. 令我非常惊讶的是, 大家讲的最多的还是用户体验和应用质量. 特别是出海东南亚的同学, 面对一堆 512MB 内存的设备, 无处不在的弱网络流下了无助的眼泪.
除了内存优化, 弱网络优化, 想做一款高质量的应用还远远不止这些. 一方面, 我们面对的环境越来越复杂. 过去的 iOS 开发者可能做梦也想不到, 现在也要开始适配屏幕和双卡双待了, 更不用说 Android 那多如繁星的机型, 厂家和系统. 如果你的应用也要出海, 那么还要面对几十个国家不同的语言, 环境.
另一方面, 我们的代码跟业务也越来越复杂了. 先不说大量 "年久失修" 的历史代码, 业务越来越复杂, 如何管理好几十上百个模块? 还要面对 React Native,Flutter,TensorFlow 等各种语言跟框架堆积在一起的情况, 再加上复杂的环境和庞大的系统, 想想做一款高质量的应用真的不容易.
从应用交付的流程说起
既然打造一款高质量的应用那么困难, 我们可以先从哪里入手做些什么呢? 我的方法是把应用当成一件商品, 想象一下商品在流水线生产的过程, 那么怎样在每个步骤做好 "质检" 呢? 这就要从应用交付的流程说起.
在我看来, 一个应用至少会经过开发, 编译 CI, 测试, 灰度和发布这几个阶段. 每个阶段需要关注什么问题呢?
1, 开发阶段. 在面试的时候, 常常有人说自己熟练掌握各种开发工具. 但是, 我们真的懂吗? 就拿我们比较熟悉的耗时分析工具 Traceview 来说, 它背后的实现原理是什么? 能不能做一个完全没有性能损耗的 Traceview? 或者怎么样将它移植到线上使用?
2, 编译 CI 阶段. 如何防止代码不断地恶化? 怎样进一步优化性能? d8 与 ReDex 有什么神奇的黑科技? 如何利用好 Coverity,Infer 这些静态分析工具? 这部分可能需要一些编译原理的知识, 你会发现移动开发也有很多值得深入研究的东西.
3, 测试阶段. 我们常说敏捷开发, 用户是最好的测试. 遇到问题在线上反复试错, 对自己, 对用户都十分痛苦. 我们希望可以做到测试 "左移", 尽可能早地发现问题. 但是很多时候我们不是不想测试, 而是发现测不出什么问题. 那么怎样提升实验室发现问题的能力呢? 如何尽可能地模拟用户的操作路径? 做好测试并不容易, 自动化测试结合 AI 或许可以帮助我们解决一些痛点.
4, 灰度和发布阶段. 动态部署流行起来之后, 很多开发变得松懈起来. 有问题发补丁, 一个不行就两个, 两个不行就十个. 怎样去保证产品质量? 很多线上问题概率很低, 基本很难复现, 比如对于一个印度的用户, 我们希望有一个远程的听诊器, 而不需要把用户拉到我们的手术台上.
对照应用的交付流程, 我来介绍一下专栏的学习方法. 专栏 "高质量开发" 模块主要对应的是开发阶段, 你可以带着实践过程的困惑去深入学习开发需要的各种武器. 专栏 "高效开发" 模块主要对应编译 CI, 测试, 灰度和发布阶段, 你可以结合实际工作全面提升整个应用交付的效率. 另外, 我认为一个好的架构可以减少甚至避免团队出错, 也是打造一款高质量应用非常重要的一环, 因此我会在最后的 "架构演进" 模块和你聊聊如何设计一个好的架构, 以及架构该如何选型.
移动 APM 质量平台
请你思考一下, 在应用交付的这几个阶段中, 我们对高质量的目标和实现方式是否一样呢? 开发阶段有开发人员, 可能希望采集尽可能多的数据; 测试阶段有测试人员, 可能更针对实验室环境或与竞品对比进行测试; 灰度和发布阶段可能也有专门的运维人员, 策略会相对保守一些. 很明显, 不同阶段我们对高质量的目标跟手段可能不太一样.
一个公司有多套质量系统, 这在大公司是非常普遍的现象. 我们希望有一个统一的平台, 整合应用的人员和开发流程, 这就是我们常说 APM 质量平台.
APM 的全称是 "Application Performance Management", 即应用性能管理. 据我了解, 国内像阿里, 腾讯, 美团点评, 饿了么, 爱奇艺这些公司都在大力投入. Google 今年也发力 Android Vitals 监控, 新增了耗电, 权限管理模块. 那么 APM 质量平台究竟有着什么样的魅力呢?
1, 统一管理. A 同学写了一个耗时监控工具, B 同学写了一个内存监控工具, 它们在不同的仓库, 上报格式可能不太一样, 各自都搭了一个简单的页面. 如果想评估一个应用的质量, 总是要去几个系统汇总数据, 想想都费劲.
2, 统一三端. 一个公司可能有多个应用, 一个应用也可能有 H5,iOS,Android 多个端. 我们希望它们只是采集数据方式有所不同, 上报, 后台分析, 展示, 报警都是共用的. 随着技术的发展, 我们可能会增加 React Native,Flutter 这些新模块的监控, 这个平台应该是统一演进的. 当然我们非常希望业界有一套开源的方案, 大家可以一起优化.
那这个质量平台需要关注哪些问题呢? 这需要看我们用户关心什么问题. 有的问题可能是致命的, 像崩溃, 卡死, 白屏. 另一大类问题就是性能问题, 安装包大小, 启动, 耗时, 内存, 耗电, 流量都是这一个范畴. 在这个专栏里, 我并不会教你如何从头搭建一个 APM 平台, 我会更期待你掌握背后所需要的知识, 它们主要包括:
由于 Android 版本的碎片化和国内 Android 生态的乱象,"Android 开发者很苦, 国内的 Android 开发者更苦".11 月 16 日, 第一届安卓绿色联盟开发者大会在北京召开, 会议上推出了应用体验标准 V2.0, 里面也对应用的兼容性, 稳定性, 性能, 功能和安全做了详细的定义.
在极致性能的同时, 我们希望能更进一步地打造 "绿色应用". 在这个过程中, 一个全面而强大的 APM 质量平台会是我们坚实的后盾. 当然对于大多数中小开发者来说, 我们更建议选择成熟的第三方服务. 但深入了解它们背后的原理, 无论是对我们如何选择合适的服务, 还是日常开发工作都会有很大的帮助. 在学习完上面的这些内容之后, 你也会觉得其实 "性能优化" 并不是那么 "高不可攀", 我们也可以慢慢地迈向 "性能优化专家" 之路.
不过我们需要明确一点, 虽然移动 APM 质量平台可以帮助我们快速发现和定位问题, 但是监控并不能保证实现高质量, 这里最关键的永远是人, 而不是系统. 为什么呢? 我举两个小例子.
你在工作中可能总能遇到这样的场景, 我管它叫反馈问题三连击:"是我的问题吗?"" 能复现吗?""你的测试靠谱吗?". 虽然通过 APM 质量平台可以减少推卸责任, 但有些人的做法通常还是发现空指针加一个判空, 发现并发问题加一个锁. 这里的空指针真正原因是什么? 这里判空了后面的逻辑是否还会运行正常? 有没有更加好的方法或架构可以避免这个问题? 我们真正应该反问的是这三个问题, 把 "质量观" 深入骨髓, 真正去想要得到个人成长, 深挖背后的原因.
第二个例子是, 我发现许多人都在问题无法忍受, 或者说是老板无法忍受的时候才去开启各种优化专项, 但事后又不了了之. 我们很多时候都在用战术的勤奋掩盖战略的懒惰, 性能优化的关键在于如何解决存量问题, 同时快速发现增量问题. APM 质量平台只可以协助我们, 并不能解决组织内部的心态问题.
总结
看到这里可能你会有这样的疑问, 我们在小公司根本没有机会学习到这些东西呀? 确实如此, 个人与公司一起成长是最快速, 也是非常难得的事情, 但并不一定人人都会有这样的机会. 从我自己的经验来看, 在搜狗, 微信会遇到各种各样的疑难问题, 也可以有很多时间去研究, 让我在解决过程中获得成长.
幸运的是现在大家都更加乐于去分享, 在专栏和技术会议中, 我们可以看到很多成熟的解决问题的经验和思路, 在 GitHub 我们可以找到很多优秀的源代码. 在这个环境下, 我们需要耐得住寂寞, 多抠一些细节, 多深入研究, 多停下来总结.
我来分享一个我的故事, 2013 年初我去面试微信, 前面都不太理想, 最后还是通过了. 后来有一次跟面试官闲聊说起这个事情, 他们认为有一件事情打动了他们. 2012 年的时候, LeakCanary 还没开源, 我在使用 MAT 做内存泄漏分析的时候总觉得很不爽. 为什么不能做自动化? 为什么看不到 Bitmap 的图片? 我当时深入研究了内存文件 Hprof 的格式, 做了几个小创新:
实现内存的自动化测试. 在自动化测试后回到首页, 这个时候获取应用的内存快照. 自动分析内存中 Activity 实例, 正常情况应该只存在一个, 其他都认为是泄漏. 为了支持正式包, 还做了通过 mapping 文件反混淆 Hprof 文件的功能.
查看图片. 自动将内存中重复的图片, 比较大的图片转换成 PNG 格式输出到文件.
现在看起来这些功能并不是太难, 但如果放到六年前, 想到而且能做到的人相信并不多. 讲这个故事还是希望你能在工作和实践中多停下来思考, 多深入研究一些细节, 很多看似不经意的思考和创新, 可能在日后发挥更大的价值.
内容选自: 极客时间《Android 开发高手课》
来源: http://www.jianshu.com/p/802cbc29bd04