|
|
# 导读 | 如何打造高质量的应用？
|
|
|
|
|
|
今年年初，我去上海参加一个移动技术会议，问了很多开发者最近在忙啥。令我非常惊讶的是，大家讲的最多的还是用户体验和应用质量。特别是出海东南亚的同学，面对一堆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月举办的Android绿色联盟开发者大会上推出的应用体验标准，有对应用的兼容性、稳定性、性能、功能和安全做了详细的定义。我贴张图，你可以看下。
|
|
|
|
|
|
|
|
|
|
|
|
在极致性能的同时，我们希望能更进一步地打造“绿色应用”。在这个过程中，一个全面而强大的APM质量平台会是我们坚实的后盾。当然对于大多数中小开发者来说，我们更建议选择成熟的第三方服务。但深入了解它们背后的原理，无论是对我们如何选择合适的服务，还是日常开发工作都会有很大的帮助。在学习完上面的这些内容之后，你也会觉得其实“性能优化”并不是那么“高不可攀”，我们也可以慢慢地迈向“性能优化专家”之路。
|
|
|
|
|
|
不过我们需要明确一点，虽然移动APM质量平台可以帮助我们快速发现和定位问题，但是监控并不能保证实现高质量，这里最关键的永远是人，而不是系统。为什么呢？我举两个小例子。
|
|
|
|
|
|
你在工作中可能总能遇到这样的场景，我管它叫反馈问题三连击：“是我的问题吗？”“能复现吗？”“你的测试靠谱吗？”。虽然通过APM质量平台可以减少推卸责任，但有些人的做法通常还是发现空指针加一个判空，发现并发问题加一个锁。这里的空指针真正原因是什么？这里判空了后面的逻辑是否还会运行正常？有没有更加好的方法或架构可以避免这个问题？我们真正应该反问的是这三个问题，把“质量观”深入骨髓，真正去想要得到个人成长，深挖背后的原因。
|
|
|
|
|
|
第二个例子是，我发现许多人都在问题无法忍受，或者说是老板无法忍受的时候才去开启各种优化专项，但事后又不了了之。我们很多时候都在用战术的勤奋掩盖战略的懒惰，性能优化的关键在于**如何解决存量问题，同时快速发现增量问题**。APM质量平台只可以协助我们，并不能解决组织内部的心态问题。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
看到这里可能你会有这样的疑问，我们在小公司根本没有机会学习到这些东西呀？确实如此，个人与公司一起成长是最快速，也是非常难得的事情，但并不一定人人都会有这样的机会。从我自己的经验来看，在搜狗、微信会遇到各种各样的疑难问题，也可以有很多时间去研究，让我在解决问题的过程中获得成长。
|
|
|
|
|
|
幸运的是现在大家都更加乐于去分享，在专栏和技术会议中，我们可以看到很多成熟的解决问题的经验和思路，在GitHub我们可以找到很多优秀的源代码。在这个环境下，我们需要耐得住寂寞，多抠一些细节，多深入研究，多停下来总结。
|
|
|
|
|
|
我来分享一个我的故事，2013年初我去面试微信，前面都不太理想，最后还是通过了。后来有一次跟面试官闲聊说起这个事情，他们认为有一件事情打动了他们。2012年的时候，LeakCanary还没开源，我在使用MAT做内存泄漏分析的时候总觉得很不爽。为什么不能做自动化？为什么看不到Bitmap的图片？我当时深入研究了内存文件Hprof的格式，做了几个小创新：
|
|
|
|
|
|
1.实现内存的自动化测试。在自动化测试后回到首页，这个时候获取应用的内存快照。自动分析内存中Activity实例，正常情况应该只存在一个，其他都认为是泄漏。为了支持正式包，还做了通过mapping文件反混淆Hprof文件的功能。
|
|
|
|
|
|
2.查看图片。自动将内存中重复的图片、比较大的图片转换成PNG格式输出到文件。
|
|
|
|
|
|
现在看起来这些功能并不是太难，但如果放到六年前，想到而且能做到的人相信并不多。讲这个故事还是希望你能在工作和实践中多停下来思考，多深入研究一些细节，很多看似不经意的思考和创新，可能在日后发挥更大的价值。
|
|
|
|
|
|
## 课后作业
|
|
|
|
|
|
“纸上得来终觉浅，绝知此事要躬行”，只有通过实践，运用到自己的项目里面，才会对知识有更深入地理解。
|
|
|
|
|
|
我为专栏的“课后作业”环节专门设计了可供你操作实践的Sample，并在GitHub新建了专栏的[Group](https://github.com/AndroidAdvanceWithGeektime)，后面会陆续将这些Sample放到上面。课后作业主要是根据Sample进行操作，需要你理解实现原理，并在极客时间App专栏文章下面的留言区提交你的学习总结和思考。我和极客时间为认真提交作业的同学准备了丰厚的学习加油礼包，里面包含我推荐的经典图书、极客时间周历、专栏阅码等礼品。我还会选出坚持参与学习并分享心得的同学，在专栏模块一、模块三结束时，分别送出2张2019年GMTC大会的门票。
|
|
|
|
|
|
**为了更好地给同学们答疑，我邀请了我的朋友孙鹏飞作为课程的“学习委员”，他将不定期讲解我们Sample的实现原理**。鹏飞是Android资深开发工程师，现在负责某知名网约车平台司机端的业务开发、性能优化等工作。我们的学习委员对系统框架、虚拟机、性能优化等都有很深入的理解，实战经验也很丰富，相信鹏飞的加入可以更好地帮助你掌握课程的要点，并能解决实践中的问题。
|
|
|
|
|
|
**今天是课程导读，也正式开启了我们接下来3个多月的学习之旅，所以最后特别邀请你在留言区也做个自我介绍，介绍下自己，聊聊目前的工作、学习情况，或者说说遇到的具体问题和困惑，也可以写写自己对这个课程的期待，让我们彼此有更多了解。**
|
|
|
|
|
|
希望你能够积极参与进来，咱们教学相长，共同进步。
|
|
|
|
|
|
欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。
|
|
|
|
|
|
|
|
|
|