美好时光

我从 2013 年开始接触 Android 开发，在当时 Android 4.4 还是热门的新事物。AsyncTasks 还是标准，还有 OttoEventBus 和其他令人讨厌的东西。我见证了架构演进的过程，从 MVC 到 MVP/MVI，然后转向 MVVM，最后是 MVVM 和 MVI 的混合。

我记得，当 RxJava 出现时，一切都突然变成了反应性的，变成了流。我记得，l33t Android Devs（Hi Jake Wharton）在谈论那个新出现的黑马 Kotlin。我记得，Kotlin 兴起并接管了 Android 行业。我记得，Coroutines 出现了，并且起初被认为是“RxJava”的杀手（嘿，你现在可以用同步方式编写所有异步代码了！不需要流了！）。这个理念很吸引人，但很快就被证明，那仅仅是一个好主意而已，因此，像 Channels 这样的底层异步原语成为 Kotlin 的 Rx-Way。不过事实证明，很多使用 Channels 的人都是自断双臂。不得已，精益冷流（Cold Streams）和热流（Hot Streams）的概念被重新引入，请允许我向你介绍：StateFlows 和 SharedFlows，最后，我们得到了一个轻量级的、支持 Coroutines 的 Kotlin 版 RxJava2。

我记得，我和同事 David 围绕状态和事件展开的所有有趣的对话，到底什么是状态，什么是事件？事件对状态有什么作用，反之亦然？我记得，在 Dagger 2 被 Koin 和 Dagger Hilt 取代之前的几年，我熬夜学习 Dagger 2。我还记得，第一次阅读 Uncle Bob 的《架构整洁之道》，这是我在 Android 开发生涯中最开阔眼界的时刻之一。现在，我能够设计和编写几乎所有应用程序，而不需要考虑 MVVM/MVP/MVC 或任何其他特定于平台的细节。我知道为什么测试很重要，我尝试了 TDD，对它是又爱又恨，我还学习了 DDD 和 BDD。

我的火车到达终点站了吗？

（我选择这个副标题是因为我现在正在从瑞士到德国的火车上写这篇文章。）

后来，我加入了保时捷和 IBM 等大企业的领导团队，这是一段很好的旅程，经过 6-7 年的经验积累，我达到了目标。我曾开发过复杂的应用程序，涉及大量的 E2E 加密、传感器通信、NFC 芯片、BLE Beacon、高流量聊天应用，还有非常有名的待办事项应用，等等。

大约 6 年后，我开始以首席 Android 开发人员的身份参与项目。我学会了识别所参与的大多数项目的核心技术问题（架构和团队成员对某些模式有不同的理解），我还学会了如何指导团队解决这些问题，以及如何成功地完成项目。对我而言，现在新东西仅仅是学习新的 API 变化 / 框架，目的是解决我们已经解决了很多年的问题，只是新的框架 /API 做了更好的处理（不用再手动处理生命周期、Fragment Transaction、XML 布局等）。

我以前的后端经验

很幸运，在过去的 4-5 年里，我在客户项目中从事后端工作（根据要求）。我花了很多时间去了解后端开发的来龙去脉，编写并发代码，创建分布式系统，纵向和横向扩展，处理分布式事务，编写可配置的代码，在不同阶段的环境表现出预期的效果。我研究了不同类型的数据库（图、关系、文档），以及什么样的数据应该使用什么样的数据库，我学习了 Docker 和 K8s，我用 Go 重构 Java EE 系统。看着由 Go 编译出来的二进制文件，它的内存使用率和几乎为零的内存占用，我明白了为什么 Go 如此令人惊叹。作为后端开发人员，我所解决的问题与我在 Android 开发中遇到的挑战无法相提并论（我很快就会讲到），作为后端开发者，我所解决的问题比在 Android 上推敲像素影响更大、更深远。

Android 真的就那样吗？

最终，我厌倦了与 UI/UX 设计师的所有会议，厌倦了向他们解释 Material Design 的基本原理，或者为什么我们不能触发应用程序 Y（不是我们开发的）中那样的行为 X，我记得，好几个小时的设计讨论都让我的大脑直接宕机了。不少项目都会出现这种情况，其中一些项目具有一定的复杂性，一旦团队理解了整洁架构和领域驱动开发，我们就能在很短的时间内写出领域数据层。一旦你向团队解释清楚了各种身份认证流程，恰当处理令牌刷新逻辑就变成小菜一碟了。主要的挑战几乎总是出现在 UI 层，由于框架 API 不断发展变化，UI 层也在不断变化。在很大程度上，UI 层受 UI/UX 设计师和 PO 影响。最近，几乎所有的项目都变成了日常工作，对工程的关注少，对业务、实施的关注多，几乎一直在摆弄 Android API。在最好的情况下，会有一个令人耳目一新的任务，如编写一个自定义视图，并使用一些线性代数的知识。但通常情况下，几乎总是一些无聊的事情，反思这一切，我问自己：这对我有什么好处？当然我赚了很多钱，但我马上就要 30 岁了，几年后，我将在哪里？

作为一名经验丰富的 Android 开发人员，我只适合 Android 职位。我所有的技能都是为了能开发出可维护的、整洁的、能在 Android 平台上正常工作的代码。有些代码会被垃圾收集器如期杀死，而有些代码能在垃圾收集器中存活下来，因为它本该如此。如果 Android 很快消失了怎么办？看着像 Flutter 这样优秀的技术，人们已经用它开发出了一些很棒的应用，我不会再把任何新项目作为单独的原生 iOS 和原生 Android 应用来启动。老实说，你的 Android 技能对于大多数公司的首席 / 资深软件工程师职位来说价值并不高。

Android 开发日薄西山

我成功地完成了自己的最后一个项目。现在是时候做一些改变了。我不想再花几天的时间讨论 CardView 的边框或反复出现的毫无意义的问题，比如是使用单选按钮还是复选框。我不想再为了更好地处理 Android 生命周期或导航而学习新的 Android 库，然后在未来 12 个多月内看它们再次被替换，在过去的 10 年里，这种事我已经做过好多次了。开发人员一代接一代，每一代中都会有人觉得自己有权力编写一个新的库来处理 UI 状态，或者编写一个新的导航库。测试？不，没有。可悲的是，有很多开发者会使用这些库。Android 开发正慢慢被吞噬 Web 开发的混乱所吞噬（你试过安装 create-react-app 吗？你会下载数以千计的库，包括一些易受攻击的库）。

幸运的是，在过去几年里，我曾在几个项目中从事后端工作，这使我有机会过渡到后端开发，彻底离开安卓，专注于开发每秒处理数十万用户请求的系统，这对我来说非常有吸引力。现在，路线图上有一些我作为 Android 开发者不了解的新东西：获得 K8s 认证，掌握多个云，深入学习特定数据库，深入理解 DevOps。我感觉，编程的神秘性再次激发了我，有复杂的工程问题需要处理，这让人兴奋。

让人难过的是，对于一个纯粹的 Android 开发者来说，架构师或首席 / 资深工程师的道路是封闭的。纯粹的 Android 开发人员根本不具备履行这些职位所需的技能。对我来说，这是一次很棒的旅程，但我再也不会以 Android 开发人员的身份参与项目了。