Android 开发之路

因负责团队的管理工作，日常中也会接触面试工作，深切地感受到这两年移动开发潮的落幕，几个知名的培训机构（厦门，甚至福州）不再对移动开发招生，另外需求方也在减少，从原生的开发转向其他渠道分流。无论是准备入行或刚刚入行，还是比较资深的开发者，对于移动开发职业的未来，都有一些迷茫、一些焦虑。怀疑的声音渐渐大起来，“现在学习移动开发还有前景吗？”“移动开发还有什么可以研究的？”。

一、引言

移动互联网的发展不知不觉已经十多年了，“移动开发” 也已经变成了 “人工智能（AI）”。移动开发的光环和溢价开始慢慢消失，已经不再是“风口上的猪”，并且正在向 AI、区块链等新的领域转移。可以说，国内移动互联网的红利期已经过去了，现在是增量下降、存量厮杀，从争夺用户到争夺时长。比较明显的是手机厂商纷纷互联网化，与传统互联网企业直接竞争。另外一方面，过去渠道的打法失灵，小程序、快应用等新兴渠道崛起，无论是手机厂商，还是各大 APP 都把出海摆到了战略的位置。

从技术的角度来看，去年（2018）移动端的技术变革也有点缓慢。大前端的概念虽然说了很久也很多，但 RN（React Native）、H5 的效果依然不尽人意。在插件化热潮之后，前年的 Kotlin 之后，去年讲得比较多的还是 Flutter。

从市场看，移动开发的前景不明朗，再加上竞争激烈以及技术变革放缓，我们感到迷茫、焦虑似乎就不难理解了。

二、发展方向

或许是移动互联网这个大环境变了，推动我们不得不跟着转变。移动端的招聘量变少，但中高端的职位却没少，这说明行业只是变得成熟规范起来了。竞争激烈，但产品质量与留存变得更加重要，我们进入了技术赋能业务的时代。大前端正在跨平台，移动开发者的未来更可能是跨终端，产品、运营、数据分析、后端等。

移动开发还可以做些什么？整体来说，主要包括以下三个部分 （注：60% 是 Android 相关的，40% 是可以跨平台的）。

• 高质量开发。在如今的竞争态势下，保证产品的基础用户体验尤为重要。最近各大公司，对 APM 性能监控系统也越来越重视。如崩溃、内存、卡顿、启动、I/O、存储、网络、耗电、渲染、安装包体积等比较常见的关键点

• 高效开发。持续交付近年在国内非常火热，我们都在寻找内部突破，提升效率。一个应用从想法到成品，需要经历开发、编译 CI、测试、灰度、发布等多个阶段，那怎样提升各个阶段的效率，也是大家比较关心的话题。跨平台开发可能是解决开发阶段的一个答案，动态部署可能是发布阶段的一个答案

• 架构演进。“君有疾在腠理，不治将恐深”，对于一个应用来说，架构一定是核心中的核心。还有 App Bundle、虚拟机、耗电等，也有移动网络架构的一些选择，跨平台开发、动态化实践等热点知识

如今的移动开发开始冷下来了，或者有人说开始进入移动互联网的下半场了。其实，对于我们开发人员来说，不管是下半场还是上半场，我们重要的是要把技术做好做精做深。是的，现在移动开发已经不再是风口，但是，这并不是说移动开发已经被淘汰，而是说移动开发的发展进入了成熟期。

如果说现在，还只是能做好产品给过来的“需求”，这是远远不够的。作为一个移动开发工程师，你我都需要深耕细作，都需要有工匠精神，把已有的事情从好做到更好。因为在迈向更好的过程中，你必然需要学习底层原理，你必然需要拓展知识面，你必然需要结合其他的技术，有了这么多必然，你也必然会变得更强。

我认为，移动开发不等于 APP 开发，所有新的技术浪潮其实都可以融入到移动开发的体系里，比如 IoT、音视频、边缘计算、VR/AR等。我们要做的，只是打好基础，随时准备战斗。其次，从心态上，我觉得我们千万不要把时间浪费在纠结问题上，而是应该放在解决问题上。拥抱变化，才能拥有未来！

三、户体验和应用质量

对于如今的移动开发，大家讲的最多的还是用户体验和应用质量。除了内存优化、弱网络优化，想做一款高质量的应用还远远不止这些。

• 我们面对的环境越来越复杂。过去的 iOS 开发者可能做梦也想不到，现在也要开始适配屏幕和双卡双待了，更不用说 Android 那多如繁星的机型、厂家和系统。
• 我们的代码跟业务也越来越复杂了。先不说大量 “年久失修” 的历史代码，业务越来越复杂，如何管理好几十上百个模块？还要面对 React Native、Flutter、TensorFlow 等各种语言跟框架堆积在一起的情况，再加上复杂的环境和庞大的系统，想想做一款高质量的应用真的不容易。

3.1 从应用交付的流程说起

打造一款高质量的应用很难，我们可以先从哪里入手做些什么呢？怎样在每个步骤做好“质检”呢？这就要从应用交付的流程说起。在我看来，一个应用至少会经过开发、编译 CI、测试、灰度和发布这几个阶段。每个阶段需要关注什么问题呢？

• 开发阶段。在面试的时候，常常有人说自己熟练掌握各种开发工具。但是，我们真的懂吗？它背后的实现原理是什么？
• 编译 CI 阶段。如何防止代码不断地恶化？怎样进一步优化性能？d8 与 ReDex 有什么神奇的黑科技？
• 测试阶段。我们常说敏捷开发，用户是最好的测试。遇到问题在线上反复试错，对自己、对用户都十分痛苦。我们希望可以做到测试“左移”，尽可能早地发现问题。但是很多时候我们不是不想测试，而是发现测不出什么问题。那么怎样提升实验室发现问题的能力呢？如何尽可能地模拟用户的操作路径？做好测试并不容易，自动化测试结合 AI 或许可以帮助我们解决一些痛点。
• 灰度和发布阶段。动态部署流行起来之后，很多开发变得松懈起来。有问题发补丁，一个不行就两个，两个不行就十个。怎样去保证产品质量？很多线上问题概率很低，基本很难复现。

3.2 移动 APM 质量平台

在应用交付的这几个阶段中，我们对高质量的目标和实现方式是否一样呢？开发阶段有开发人员，可能希望采集尽可能多的数据；测试阶段有测试人员，可能更针对实验室环境或与竞品对比进行测试；灰度和发布阶段可能也有人跟进，策略会相对保守一些。很明显，不同阶段我们对高质量的目标跟手段可能不太一样。

APM 的全称是“Application Performance Management”，即应用性能管理。大厂一般都有这个流程且投入还不少，但小厂就比较少人去关注，一般只关注项目周期。不过对于开发人员来讲，我们依然要关注这些技术点，Google也发力 Android Vitals 监控，新增了耗电、权限管理模块。年一过，平台上有几个应用因为权限（电话的权限问题）被平台移除。

那么 APM 质量平台究竟有着什么样的魅力呢？

• 统一管理。A 同学写了一个耗时监控工具，B 同学写了一个内存监控工具，它们在不同的仓库，上报格式可能不太一样，各自都搭了一个简单的页面。如果想评估一个应用的质量，总是要去几个系统汇总数据，想想都费劲。
• 统一三端。一个公司可能有多个应用，一个应用也可能有 H5、iOS、Android 多个端。我们希望它们只是采集数据方式有所不同，上报、后台分析、展示、报警都是共用的。随着技术的发展，我们可能会增加 React Native、Flutter 这些新模块的监控，这个平台应该是统一演进的。当然我们非常希望业界有一套开源的方案，大家可以一起优化。

那这个质量平台需要关注哪些问题呢？这需要看我们用户关心什么问题。有的问题可能是致命的，像崩溃、卡死、白屏。另一大类问题就是性能问题，安装包大小、启动、耗时、内存、耗电、流量都是这一个范畴。由于 Android 版本的碎片化和国内 Android 生态的乱象，或者换句话说，“Android 开发者很苦，国内的 Android 开发者更苦”。

一个全面而强大的 APM 质量平台会是我们坚实的后盾。当然对于大多数中小开发者来说，建议还是选择成熟的第三方服务。不过我们需要明确一点，虽然移动 APM 质量平台可以帮助我们快速发现和定位问题，但是监控并不能保证实现高质量，这里最关键的永远是人，而不是系统。

第一个例子

在工作中可能总能遇到这样的场景，反馈问题三连击：“是我的问题吗？”“能复现吗？”“你的测试靠谱吗？”。虽然通过 APM 质量平台可以减少推卸责任，但有些人的做法通常还是发现空指针加一个判空，发现并发问题加一个锁。这里的空指针真正原因是什么？这里判空了后面的逻辑是否还会运行正常？有没有更加好的方法或架构可以避免这个问题？我们真正应该反问的是这三个问题，把 “质量观” 深入骨髓，真正去想要得到个人成长，深挖背后的原因。

第二个例子

现在许多人都对问题无法忍受，或者说是老板无法忍受的时候才去开启各种优化专项，但事后又不了了之。我们很多时候都在用战术的勤奋掩盖战略的懒惰，性能优化的关键在于如何解决存量问题，同时快速发现增量问题。APM 质量平台只可以协助我们，并不能解决组织内部的心态问题。

四、总结

实话讲，我们在小公司很少有机会学习这些东西，确实如此，个人与公司一起成长是最快速，也是非常难得的事情，但并不一定人人都会有这样的机会。自已也可以花时间去研究，让我们在解决问题的过程中获得成长。

关于我

更多信息可以点击关于我 , 非常希望和大家一起交流 , 共同进步