我为什么放弃做一名移动开发人员

回到我上大学的时候，Android和iOS还是相当新的平台，每个人都对它们感到兴奋。当有某种类型的编码研讨会时，几乎可以肯定的是，您最终构建了一个小型Android应用程序。这就是我在Android生态系统中迈出的第一步，可能也是我在之后立即成为一名移动开发人员的原因。

在这篇文章中，我想分享我使用Android SDK和Ffltter的令人沮丧的经历。我提到的一些要点也适用于iOS SDK。几年前，我停止了移动开发人员的工作，希望很多事情都变得更好了。但即使在那时，我也发现移动生态系统被误导了，我不得不寻找另一条职业道路。

对于每个Android开发人员来说，最大的痛点是设备配置的巨大多样性。我从来不太明白为什么SDK的更好的部分(特别是UI部分)不是我的应用程序的依赖项，而是嵌入到设备中。这基本上迫使我使用支持库，并针对每个目标API级别调试我的应用程序。除此之外，我经常遇到随机的三星或华为设备崩溃的情况，而这些代码在Emulator或我的测试设备上运行得很好。

当我在HackerNews或Reddit上看到关于谷歌材料设计的评论时，有时我觉得自己是唯一真正喜欢它的人。我觉得它在视觉上很吸引人，总体上很享受用户体验。官方文档网站走了很长一段路，我认为它是优秀文档的一个典型例子。当Android宣布的时候，我超级兴奋！话虽如此，在Android平台上从Holo过渡到Material Design并不是一帆风顺的。感觉释放得太匆忙了。在接下来的几年里，官方的Material Design Support库中将缺少非常基本的小部件。尽管有时你可以在谷歌自己的应用程序中欣赏它们，但它们并没有进入支持库。开发人员被迫在质量有问题的GitHub上构建自己的实现或获取替代实现。伴随着相当多的视觉不一致和实现错误，Material Design support库体验可能是我第一次停下来真正思考和质疑生态系统。

构建一个坚如磐石的Android应用程序是一项具有挑战性的任务。这在很大程度上是因为SDK对开发人员不友好。令人惊讶的是，从理论上讲，Android应用程序可以在后台无限期地空闲，不消耗系统资源，并且可以在用户需要时直接弹回以前的状态。如果开发人员成功地实现了状态和生命周期管理，那么至少是这样。

开发人员您好互联网，我的应用程序在方向改变时崩溃，我如何解决这个问题？互联网很简单，只需禁用方向更改。

您使用过Java中的线程吗？在到处都是可变变量的命令性代码库中，这些东西是非常困难的。好吧，你猜怎么着：使用Android SDK就更难了。如果您想从一个活动中管理一个线程，那么您基本上是在自找麻烦。幸运的是，我们最终得到了保留的片段，这使得这变得稍微容易一些。但代价是首先得到碎片。

在我作为一名移动开发人员的职业生涯中，我采访了相当多的Android高级开发人员，除了极少数例外，他们都很难把这些话题搞清楚。

我一直希望谷歌做更多的事情来承认这些问题，并与社区合作解决它们。Kotlin的情况可能有所改善，但Android生态系统的可疑基础仍然潜伏在下面。

开发人员很快意识到，在Android SDK提供的抽象之上构建现实世界的应用程序是不可能的。解决方案是新的设计模式，这些模式可能每周都会出现：MVC、MVP、MVVM和MVI都是我记得的。因为我们不能使用普通的构造函数调用来管理依赖项，所以我们不得不在代码库中散布注释。这一切本不应该是必要的。Java，尤其是Kotlin，具有足够的表现力，能够以透明和直接的方式对所有这些东西进行建模。但是Android更喜欢庞大的XML定义和反射实例化，所以开发人员不得不用注释和可疑的设计模式来混淆他们的代码。老实说，我无法用语言来表达这件事有多糟糕。

在某种程度上，原生iOS和Android开发作为一个平台与网络竞争。然而，他们拥有属于一家公司的巨大优势，而网络有许多利益相关者，他们希望根据自己的需求影响其发展。然而，网络是一个更生动、更具创新性的生态系统。看看Reaction的成功案例就知道了：不可否认的是，基于组件的用户界面方法是我们到目前为止提出的最明智的抽象。Android多年来一直在这一趋势中沉睡，直到最终宣布了“Jetpack Compose”，它仍然只提供给开发者预览版。在iOS世界中也发生了几乎同样的事情。因此，我们现在仍然继承自一个15k的LOC android.view.View类，该类具有几十个生命周期方法，同时试图以某种方式注入我们的合并XML文件。iOS和Android本可以成为这一领域真正的开拓者和驱动力，但相反，竞争已经完全把它们甩在了后面。

制作精美的应用程序的关键是用户界面。现在，我已经在上面的小节中抱怨了很多关于组件仍然不存在的问题，但是这个主题还有更多的内容。你有没有在网站上调试过故障？打开浏览器的开发工具，单击受影响的元素并使用CSS和HTML属性，直到一切正常。与此相比，Android是一个无法接近的黑匣子。老实说，我从来没有完全摸索过Android的主题和样式机制，与网络的可访问性相比，围绕它的工具似乎总是一文不值。

想要在这个盒子周围画下阴影吗？当然，可以使用这个古怪的.9.png文件，或者使用API21级，在那里您可以正确地渲染阴影(仅限通过😀渲染凸形)。

抱歉，您忘记在自定义视图中实现四个构造函数中的一个。但是我不会用编译错误来阻止您，我宁愿在运行时崩溃！

现在有这种超高密度的手机。请将各自的xxxhpi资产添加到您的应用程序中，好吗？不，不支持矢量图形，我们这里不做这个。

在Android 21(5.0)之前，完全不支持正确的矢量图形。这背后的理由是，Android设备的多样性需要经过仔细调整的显卡，以适应每种密度水平的需求。当然，务实的开发人员会创建工具，将我的logo.svg转换为ldpi/logo.png、mdpi/logo.png、hdpi/logo.png、xhdpi/logo.png、xxhdpi/logo.png，当然还有xxxhdpi/logo.png。幸运的是，谷歌最终改变了主意，给我们带来了VectorDrawable，它支持SVG的一个子集，向后兼容性很差。诚然，这足以缓解当时的痛苦。然而，它仍然让我感到困惑，一个以运行在任意设备配置上为荣的开发环境怎么会在没有向量支持的情况下存在这么长时间。

多年来，我开始越来越担心我的知识在可预见的将来会过时。我学到的大多数东西都是针对Android的，很少适用于更大的软件开发领域。考虑到它的怪癖，我不相信本地移动开发会长期存在，所以我开始担心我学到的技能是否有用。

当Ffltter宣布的时候，我立刻兴奋起来。它承诺解决Android SDK的一些主要缺陷，同时免费为我提供跨平台支持。因此，我们实际上在我之前的工作中开始将我们的原生Android应用程序迁移到Ffltter。我不得不说：Ffltter信守诺言。

从一开始，它就有一个详尽的高质量材质设计小部件库。

但不幸的是，情况并不都很好。令人遗憾的是，FLUTH遭受的问题本可以通过绿地项目轻松避免。

DART很糟糕：它是一种相对年轻的语言，但它重复了它年长前辈的许多错误(糟糕的类型系统、NULL、语句而不是表达式、…)。

颤动SDK中有问题的设计决策：他们非但没有创造出更好的反应，反而让事情变得更糟。本来可以是简单的函数调用往往可以由有状态的OOP机制来解决(我在这里回想起对话小部件的路由和处理特别痛苦)。

在某种程度上，对我来说很明显，这不是我想要花费时间的那种技术。我向自己保证，我再也不会为移动平台编程了。如今，一个设计良好、响应迅速的网站会让你走得相当远，所以这是我的默认选择。它是一个单一的代码库，只能在每个客户端上运行。如果我一定要创建一款移动应用程序，我仍然会选择Ffltter，即使我只针对Android。使用Android SDK对我来说是不可能的。

话虽如此，我要澄清的是，我非常欣赏和欣赏一个精心制作的原生应用程序(无论是在移动设备上还是在台式机上)。我非常尊重那些使用可用的工具创建这些内容的开发人员。我只是不想再成为他们中的一员。