我为什么放弃移动开发？
极客时间编辑部
讲述：丁婵大小：8.07M时长：05:53
你好，欢迎收听极客视点。
曾经作为一名移动开发者，尼克拉斯·克莱因（Niklas Klein）对 Android 和 iOS 非常感兴趣，然而几年前，他坚决地放弃了移动开发。最近克莱因分享了他关于 Android SDK 和 Flutter 的糟糕体验，其中某些要点也适用于 iOS SDK。InfoQ 对此进行了翻译，供你参考。
1. 设备的碎片化
对开发者而言，Android 开发的最大痛点，就是设备配置的巨大差异。我一直都未能理解为什么 SDK 中大部分功能（尤其是用户交互界面的部分）取决于设备，而不是我的应用。这从根本上导致我必须使用支持库，针对每个目标 API 级别调试我的应用。除此之外，我还经常遇到在仿真器或者测试设备上好好的代码，却在某个三星或者华为的设备上崩溃的情况。
2. Material Design
当我在 HackerNews 或者 Reddit 上读到关于谷歌的 Material Design 的评论时，某些时刻会感到我是唯一真正喜欢它的人。我觉得它在视觉上很具吸引力，我通常很享受这样的用户体验。官方的文档网站发展得很快，也非常成功，我觉得这是优秀文档的典范。当它被宣布用于 Android 时，我感到非常兴奋！
话虽如此，在 Android 平台上从 Holo 过渡到 Material Design 并非一帆风顺。因为它好像是被急匆匆发布出来似的。在接下来的几年之中，官方的 Material Design 支持库一直缺少一些非常基本的组件。虽然你有时可以在谷歌自有的应用上看到这些组件，但是它们并没有真正被纳入到支持库中。开发者不得不构建自己的组件，或者使用 GitHub 上质量无法保证的实现作为替代品。这次使用 Material Design 支持库的经历，再加上大量的不一致的视觉设计和实现错误，让我第一次停下来真正地思考和质疑这个生态系统。
3. 无效的设计模式和对抽象的注解（Annotation）
开发者很快就意识到，在 Android SDK 提供的抽象之上，构建一个真实世界的应用是不可能的。对此的解决方案是层出不穷的设计模式，甚至每周可能都会出现新的设计模式，而且由于无法使用普通的构造函数调用来管理依赖项，我们不得不在代码库的每个地方使用注解。
4. 从未利用过的平台优势
在某种程度上，原生 iOS 和 Android 开发都是作为平台在与网页端竞争。但 iOS 和 Android 拥有只属于一家企业的巨大的平台优势，相比之下，网页端有许多利益相关者，这些利益相关者都想要根据他们的需要来影响网页端的开发。
然而，网页端拥有更加活跃和创新的生态系统。只需要想想 React 的成功故事：基于组件的用户界面，是我们目前提出的最简洁的抽象方法，这是无可否认的。多年以来，Android 并不理会这一趋势，直到最近才宣布推出“Jetpack Compose”，但是这仍然仅支持在开发者预览模式下使用。同样的事情也出现在 iOS 开发中。
所以，现状是我们仍然需要继承 android.view.View 类，这个类有 1.5 万行代码，和数十个生命周期函数，但同时我们还要尝试注入自己的 merge XML 文件。iOS 和 Android 本来可以成为这个竞争中的引领者，但实际上，它们已经被远远甩在了后面。
5. 矢量图
在 Android 21（5.0）之前，Android 平台根本不支持正确的矢量图。这背后的原因是，多样的 Android 设备导致了多种不同的屏幕密度，这要求图像针对每种屏幕密度都做仔细的调整。务实的开发者自然而然地开发了转换矢量图的工具，最终谷歌也提供了 VectorDrawble 来支持部分可缩放矢量图形（SVG）。的确，这足够减轻当时的痛苦。但仍然令我困惑的是，一个以能够在任何设备配置上运行为优势的开发环境，是如何在这么长时间都不支持矢量图的情况下活下来的？
6. Flutter
当 Flutter 发布时，我非常激动。它承诺将解决一些主要的 Android SDK 的缺陷，同时无偿提供跨平台支持。所以在我上一份工作中，我们开始从原生 Android 迁移到 Flutter 上。我必须承认，Flutter 信守了它的承诺：
Flutter 内置的渲染流水线完全解决了 Android 的碎片化问题。
从一开始，它就提供了详尽的高质量的 Material Design 组件库。
热重载功能的灵活性也完全颠覆了我的认知。
你能获得前所未有的高质量界面外观的跨平台体验。
但不幸的是，它也不完美：
Dart 很糟糕：它还是一门相对年轻的语言，但它重蹈了不少它前辈的覆辙，比如错误的类型系统、Null、使用语句而不是表达式等等。
Flutter SDK 中让人不解的设计决策：它们本应创造一个更好的 React，但却创造了一个更糟糕的。本可以通过简单的函数调用解决的问题，往往需要通过有状态的面向对象编程（OOP）机制才能解决。
以上就是克莱因放弃移动开发的几个主要原因，你认为移动开发怎么样呢？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
贺超放弃移动开发，那转行去做什么？技术栈不一样，面试也是个很大问题15
钟意移动开发，狗都不学归属地：湖南
Chelizi移动开发早已成了昨日黄花，只有几个大厂有高级移动开发的需求。移动开发和产业互联网基本上也没啥关系。
收起评论