写点什么

我为什么放弃移动开发

  • 2020-06-22
  • 本文字数:3480 字

    阅读完需:约 11 分钟

我为什么放弃移动开发

当我还在上大学的时候,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。


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


原文链接:


9 reasons why I gave up on being a Mobile Developer


2020-06-22 10:0010057

评论 5 条评论

发布
用户头像
已转行
2020-07-21 15:43
回复
用户头像
做了6年的android工程师,从个人的经历来讲,好的移动开发要适应项目,甚至是公司。例如我在上一家产品研发型公司,我能把app页面流畅度做到秒开,内存做到实时的回收等,但是现在这一家产品+项目性公司,甲方的要求就是坨屎也得跟他实现的情况,抱歉,牺牲是在所难免的。但是大家都高兴了(当然我是希望能够做的更好一些)。
2020-06-30 22:30
回复
用户头像
作者的含义是用H5比较好?看下 www.appkuang.com
2020-06-28 09:47
回复
用户头像
“老实说,我一直没有完全理解 Android 的主题和样式机制”--同感
2020-06-26 21:14
回复
用户头像
有道理的。
2020-06-24 10:19
回复
没有更多了
发现更多内容

从架构上详解技术(SLB,Redis,Mysql,Kafka,Clickhouse)的各类热点问题

利志分享

架构 #热点问题

带你了解什么是DHCP,为什么要用DHCP?

乌龟哥哥

DHCP 4月月更

详解动静态缓存各种方式

穿过生命散发芬芳

4月月更

逐向双碳:绿色计算的误区与正确打开方式

脑极体

redis中报too many connections错误的解决

杨彦星

redis

Android C++系列:JNI开发准则

轻口味

c++ android 4月月更

在线标准程序员计算器

入门小站

工具

在线CSV转TSV工具

入门小站

工具

论语音社交视频直播平台与 Apache DolphinScheduler 的适配度有多高

Apache DolphinScheduler

分布式shiro权限验证

Rubble

4月日更

cdr2022订阅版本安装包

茶色酒

cdr2022

压力如同下雨一样具有存在的必要性,我和你交个朋友吧。

叶小鍵

【直播预告】优化器及 Flink CDC + OceanBase 全增量一体化数据集成方案

OceanBase 数据库

OceanBase 社区版

动态压测模型让工作更轻松

FunTester

探索内存原理的内存映射文件(图文详解)

Linux爱好者

内存管理 Linux内核 进程管理 驱动开发 嵌入式开发

渗透测试系列之靶机渗透

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

[Day13]-[动态规划]爬楼梯

方勇(gopher)

LeetCode 数据结构和算法

Web3 和区块链技术:数字资产所有权如何颠覆当前的商业模式

CECBC

什么是中国企业信息化

秋去冬来春未远

数字化信息化中国文化

SeekTiger通证STI即将上线Gate.io

石头财经

架构训练营-作业八

默光

消息队列 训练营

阿里云PolarDB开源数据库社区与 Tapdata 联合共建开放数据技术生态

阿里云数据库开源

数据库 阿里云 polarDB PolarDB-X

linux之chsh命令

入门小站

Linux

多模块项目 mybatis mapper bean 找不到问题

Z冰红茶

宜搭小技巧|自动计算日期时长,3个公式帮你搞定!

钉钉宜搭低代码

低代码 数字化 钉钉宜搭 宜搭

react源码解析10.commit阶段

buchila11

React

jackson学习之八:常用方法注解

程序员欣宸

4月月更

智能风控中台设计与落地

第四范式开发者社区

人工智能 自动化 金融 中台架构 风险控制

开启 JSON 和多模,让生态更多可能 | OceanBase 社区版 3.1.3 发版

OceanBase 数据库

OceanBase 社区版

SeekTiger迎来新征程,STI即将登录Gate.io

BlockChain先知

盘点春招跳槽涨薪必备技能Linux内核技术(含学习路线)

Linux爱好者

内存管理 Linux内核 进程管理 嵌入式开发 设备驱动

我为什么放弃移动开发_移动_Niklas Klein_InfoQ精选文章