我为什么放弃移动开发

作者: 站长SEO 日期: 2020-08-30 09:42:15 人气: - 标签: 为什么 放弃 移动 开发

科技速递:

当我还在上大学的时候,Android 和 iOS 还是新兴的平台,每个人都对这两项技术很感兴趣。如果你参加一些当时的编程研讨会,最后总会写一个小型的 Android 应用。这就是我向 Android 生态系统迈出的第一步,也可能是我随后成为了一名移动开发者的原因。

在这篇文章中,我想要分享我关于 Android SDK 和 Flutter 的糟糕体验。我提到的某些要点也适用于 iOS SDK。我已经在几年前放弃了移动开发的工作,希望后来许多事情已经在朝好的方向改进。但在当时,我发现移动生态系统是如此的令人感到困惑和挫败,以至于我选择了一条不同的职业路径。

本文由原作者发表在 medium.com,经原作者授权由 InfoQ 中文站翻译并分享

我为什么放弃移动开发

设备的碎片化

对开发者而言,Android 开发的最大痛点,就是设备配置的巨大差异。我一直都未能理解为什么 SDK 中大部分功能(尤其是用户交互界面的部分)取决于设备,而不是我的应用。这从根本上导致我必须使用支持库,针对每个目标 API 级别调试我的应用。除此之外,我还经常遇到在仿真器或者测试设备上好好的代码,却在某个三星或者华为的设备上崩溃的情况。

质感设计(Material Design)

当我在 HackerNews 或者 Reddit 上读到关于谷歌的 Material Design 的评论时,某些时刻会感到我是唯一真正喜欢它的人。我觉得它在视觉上很具吸引力,我通常很享受这样的用户体验。官方的文档网站发展得很快,也非常成功,我觉得这是优秀文档的典范。当它被宣布用于 Android 时,我感到非常兴奋!

话虽如此,在 Android 平台上从 Holo 过渡到 Material Design 并非一帆风顺。因为它好像是被急匆匆发布出来似的。在接下来的几年之中,官方的 Material Design 支持库一直缺少一些非常基本的组件。虽然你有时可以在谷歌自有的应用上看到这些组件,但是它们并没有真正被纳入到支持库中。开发者不得不构建自己的组件,或者使用 GitHub 上质量无法保证的实现作为替代品。这次使用 Material Design 支持库的经历,再加上大量的不一致的视觉设计和实现错误,让我第一次停下来真正地思考和质疑这个生态系统。

我为什么放弃移动开发

无人理会的最佳实践

构建一个可靠的 Android 应用,是一项充满挑战的任务。这主要是因为 SDK 对开发者并不友好。理论上,一个 Android 应用程序可以永远挂在后台不使用任何系统资源,然后在用户需要时立即回到先前的状态,这实在是令人惊讶。不过前提是开发者正确地实现了这个应用的状态和生命周期管理机制。

开发者:你好,互联网!我的应用在改变屏幕方向时崩溃了,该如何解决?互联网:这很简单!禁止改变屏幕方向即可。

——啊哦,不幸的是,这种回复很普遍。

你是否曾经使用过 Java 中的线程(Threads)?在可变变量随处可见的的命令式代码库中,这件事变得非常困难。但你猜怎么着?在 Android SDK 中使用线程更加困难。如果你想要在一个 Activity 中管理 Thread,那你就只能自求多福了。幸运的是,我们最终保留了 Fragments,这最终让这件事变得容易了一些。但代价是在一开始就需要使用 Fragments。

在我作为一名移动开发者的职业生涯中,我面试了一些高级 Android 开发者。他们几乎无一例外,都很难给出这些话题的正确答案。

我一直希望谷歌能更坦然地承认这些问题,并且和社区一起解决。这些问题可能随着 Kotlin 的发布有所改善,但 Android 生态系统的根基仍然存在很多潜在的问题。

无效的设计模式和对抽象的注解(Annotation)

开发者很快就意识到,在 Android SDK 提供的抽象之上,构建一个真实世界的应用是不可能的。对此的解决方案是层出不穷的设计模式,甚至每周可能都会出现新的设计模式,我记得的包括:MVC、MVP、MVVM 和 MVI。而且由于无法使用普通的构造函数调用来管理依赖项,我们不得不在代码库的每个地方使用注解。这些本来并没有必要。Java,甚至 Kotlin,本来就有足够的能力可以对这些东西建模,更何况是以一种透明而直接的方式。但 Android 更喜欢 XML 定义和反射式实例化,因此开发者不得不在代码中使用注解和各种设计模式。实话实说,我真的无法形容这到底有多麻烦。

从未利用过的平台优势

在某种程度上,原生 iOS 和 Android 开发都是作为平台在与网页端竞争。但 iOS 和 Android 拥有只属于一家企业的巨大的平台优势,相比之下,网页端有许多利益相关者,这些利益相关者都想要根据他们的需要来影响网页端的开发。

然而,网页端拥有更加活跃和创新的生态系统。只需要想想 React 的成功故事:基于组件的用户界面,是我们目前提出的最简洁的抽象方法,这是无可否认的。多年以来,Android 并不理会这一趋势,直到最近才宣布推出“Jetpack Compose”,但是这仍然仅支持在开发者预览模式下使用。同样的事情也出现在 iOS 开发中。

所以,现状是我们仍然需要继承 android.view.View 类,这个类有 1.5 万行代码,和数十个生命周期函数,但同时我们还要尝试注入自己的 merge XML 文件。iOS 和 Android 本来可以成为这个竞争中的引领者,但实际上,它们已经被远远甩在了后面。

请不要对 UI 开发抱以希望

一个精美的应用的关键在于用户界面(UI)。我在上文已经吐槽了不少关于组件的问题,但这些还不是最严重的。你是否曾经调试过网站上的故障?通常的操作是:打开浏览器的开发工具,点击有问题的元素,然后使用 CSS 和 HTML 的属性来调试。与此相比,Android 是一个无法访问的黑盒。老实说,我一直没有完全理解 Android 的主题和样式机制,并且与 Web 相比,Android 的工具显得毫无用处。

想要在这个框周围添加阴影吗?没问题,请使用这个奇怪的.9.png 文件,或者依靠 API Level 21,你就可以正确渲染阴影了(尽管只有凸形阴影)。不好意思,你忘记实现自定义视图四个构造函数的其中一个了。但我不会抛出编译错误,我只会在运行时崩溃!现在有支持超高屏幕密度的手机了。可以在应用里添加 xxxhpi 的 assets 吗?不行,不支持矢量图,我们做不了这个。——来自 Android SDK 的深夜独白

矢量图

在 Android 21(5.0)之前,Android 平台根本不支持正确的矢量图。这背后的原因是,多样的 Android 设备导致了多种不同的屏幕密度,这要求图像针对每种屏幕密度都做仔细的调整。务实的开发者自然而然地开发了转换矢量图的工具,将 logo.svg 转换成 ldpi/logo.png,mdpi/logo.png,hdpi/logo.png,xhdpi/logo.png,xxhdpi/logo.png 以及 xxxhdpi/logo.png。幸运的是,最终谷歌改变了它们的想法,并提供了 VectorDrawble 来支持部分可缩放矢量图形(SVG)。的确,这足够减轻当时的痛苦。但仍然令我困惑的是,一个以能够在任何设备配置上运行为优势的开发环境,是如何在这么长时间都不支持矢量图的情况下活下来的?

死局

这些年,我开始越来越担心我的知识会在不远的将来过时。我学到的大多数知识都是 Android 开发所特有的,很少适用于更广泛的软件开发领域。考虑到这些方面,我不认为原生的移动开发会一直存在,所以我开始担心所学到的技能的实用性。

Flutter

当 Flutter 发布时,我非常激动。它承诺将解决一些主要的 Android SDK 的缺陷,同时无偿提供跨平台支持。所以在我上一份工作中,我们开始从原生 Android 迁移到 Flutter 上。我必须承认,Flutter 信守了它的承诺:

  • Flutter 内置的渲染流水线完全解决了 Android 的碎片化问题。
  • 从一开始,它就提供了详尽的高质量的 Material Design 组件库。
  • 热重载功能的灵活性完全颠覆了我的认知。
  • 你能获得前所未有的高质量界面外观的跨平台体验。

但不幸的是,它也不完美。而且有点可惜的是,Flutter 遇到的问题本可以通过一个全新的项目轻松避免。

  • Dart 很糟糕:它还是一门相对年轻的语言,但它重蹈了不少它的前辈的覆辙(错误的类型系统,Null,使用语句而不是表达式,等等)。
  • Flutter SDK 中让人不解的设计决策:它们本应创造一个更好的 React,但却创造了一个更糟糕的。本可以通过简单的函数调用解决的问题,往往需要通过有状态的面向对象编程(OOP)机制才能解决。(我记得对话框的路由和处理在这个方面尤为痛苦)

结论

在某一时刻,我清楚的意识到,我不想在这种技术上倾注心血了。我向自己许诺,绝不再在移动平台上编程。一个设计精美的、响应式的网站在今天已经可以给你足够好的体验,所以这是我的不二之选。只需要一个代码库,它就能适用于每个客户端。如果我还是不得不构建一个移动应用程序,我仍然会选择 Flutter,甚至是在我仅针对 Android 的情况下。我绝对不会再使用 Android SDK。

话虽如此,但要澄清一点,我还是非常喜爱和欣赏精心制作的原生应用的(无论是在移动设备上还是桌面上)。我对那些使用现有工具就能创建出这样的应用的开发者,致以崇高的敬意。只是,我不想再成为他们中的一员。

关注我并转发此篇文章,私信我“领取资料”,即可免费获得InfoQ价值4999元迷你书!

网友评论:

呆瓜茄子 :同时接触过安卓与ios与前端开发的人,都会觉得安卓的开发是一件多么糟糕的事情。甚至我觉得安卓是所有现代化ui编程中最差的存在,但也不可否认安卓的成功!

Aegena :你注定要被淘汰,你只看到这些,很多工作不是ui,编译步骤插桩,aop,内核原理,多线程,电量优化,热修复,路由,编译时注解,等等,技术很多,就看你方向,局限ui,碎片化有什么意思?真的就让你做md,又能怎么样?\n根基打的好,即使做其他的你也会觉得容易入手,你去做前端,做后台,用的人多,真的就技术深了吗?

星星夜谭 :安卓开发有职业生涯吗?已经暂时放弃了。在我看来安卓就是崩了,需要重来。混乱的生态系统和开发框架。作为安卓程序员你说实话,你写的代码质量高吗?优雅吗?可维护吗?

巴黎Only欧莱雅 :建议去github上看一下telegram的安卓端代码 如果吃透了 我觉得对于整个安卓开发生涯来讲都是一个很正要的提升

逍遥派高手 :简单来讲,没一个统一的底层或统一设计架构,如c语言可以避这种CPU和那种CPU的干扰,专心做二进制设计

骂勒布朗的是孤儿哦 :rn也可以哇

天空三生晴 :Hybrid搞定一切

舞动的代码 :Android为啥如日中天?不还是因为它的碎片化,遍地开花,遍地结果,跟winsows一个道理,兼容的东西很多,受众广。mac ios不否认它的优秀,但它终究还是小众寡头。只跟自己玩没朋友圈![酷拽][酷拽][酷拽][酷拽]

zzz1622 :哪有十全十美的平台,安卓已经做的非常好了,现在的安卓已经足够成熟,开发效率相比十年前有了质的飞跃。现在安卓还没解决的问题,都是一些根深蒂固的问题,解决这些问题也是研发新系统的目标所在。

苦闷语气词 :我最近非常烦恼,做了三年多android了,但是我的写出来的东西有很多bug,虽然我也一直在学新东西,但是老跟不上技术潮流,我的技术很垃圾,我觉得最恶心的是json解析,必须要定义一个固定的数据类型,但是后端往往返回的数据类型很随意,我后悔做安卓了,想转前端。最近我发现kotlin比起java来是真的香,对于开发安卓

MilsDu :转行回家种地吧

拔丝光年6 :咋没一个说用qt的?

玄道尊 :Android只有系统开发才能做的长久,应用开发注定只有少数人才能涉及到真正高端的电量优化,内存优化等,大多数一般的应用开发很难比混合开发更有优势

家国农民 :移动的未来注定不是app的

秦月心驰 :delphi移动开发很完美

斗茶网一程序猿卖茶叶 :web app才是未来吧[我想静静]

杰哥158415551 :做ui的也是程序员?

剑气纵横4 :正准备入坑flutter……

陳小萌128562099 :移动开发特么现在10几岁的小孩都会,还想靠这个吃饭…那只能逐步沦为蓝领码农了~[酷拽][酷拽][酷拽]

不爱留辫的前朝遗民 :我的看法恰恰相反,本来想用Flutter,但发现Flutter现在并不成熟,不得已还是用Android和iOS,线程注意好调度和管理其实也不难。成熟的东西查资料也方便,我们是做产品,讲究的是稳定、准确不出错,而不是去赶新潮

文章来源:https://www.toutiao.com/group/6841115437632061960/

Copyright © 2009-2020 水淼软件技术 Inc. 保留所有权利。粤ICP备16013086号 霏凡软件站 转载文章如有侵权请联系删除