微信号:frontshow

介绍:InfoQ大前端技术社群:囊括前端、移动、Node全栈一线技术,紧跟业界发展步伐。

开发者吐槽:Android开发就像“大便三明治”

2018-03-19 17:32 大愚若智 译
作者|Steve Yegge
策划|覃云
本文简要剖析 Android 生态系统在开发栈方面的现状,告诉你原生Android开发是多么的恶心,以及不同竞争对手围绕 Android,从开发体验、应用商店、广告渠道三大领域与 Google 展开的战争。

作者声明:本文纯属个人观点,其中很多可能并不正确,所有言论与前端之巅无关,请用批判的思维阅读本文。

我来了,又一次,正在飞往雅加达的航班上撰写这篇文章,这似乎已经成了我的习惯。

至今我依然不能完全肯定,当初那篇“我为何从 Google 离职”博客文章怎么就引起了那么大的关注。基本上我只是表达了“我就是一个喜欢频繁换工作的普通人”之类的观点。可就这么一篇文章被翻译成了大概 80 种语言,甚至变得比娜塔莉·波特曼的两性专栏更火,老实说,她的专栏内容可有趣多了。

也许可能那一周没有其他更劲爆的新闻了吧,或者只是因为 Medium 的用户数又再攀新高?Medium 是个很棒的平台,回首以前写博客的日子,我还曾期待着 Google 能提供一种类似的创新式产品呢,不过……后来,你懂的。

今天,我想谈谈 Android,作为局外人兼业余 Android/iOS 开发者,我自己对 Android 的看法。考虑到“麦芒落进针尖里”这种事不可能连着发生两次,我也可以放心假设本文不会像上次那样突然就火到不行,今天,这件事,我只说给你听。

最近我们要招募移动开发者,所以又开始考虑 Android 的各种事宜。你也许觉得招聘开发者是个再简单不过的事,但实际上开发者是目前市面上最抢手的资源。Grab (我的公司)需要开发者,每个人都需要开发者,可开发者的数量严重不足。看谁运气好能抢到吧。

为什么每个人都需要移动开发者?因为 Web 正在慢慢死去(编者注:这里指PC Web)。我的一些友人(也许是“前友人”)就职于 Google 的几乎每个部门,他们经常向我展示一些结果很悲观的图表,无论怎么切片查看,随着整个世界愈加移动化,Web 都在稳步衰退中。

见鬼,你也许还记得 Facebook 从 Web 为先向移动为先的转换过程,这事是什么时候开始的?八年还是九年前?Facebook 可是差点就挂了。我是说,虽然并没有一夜之间突然完蛋,但当这家公司意识到自己必须转型成移动公司,否则必然被历史遗忘时,他们就开始面临严重的生存焦虑。

他们设法做到了,但毫无疑问这个过程异常困难,因为 Android 开发栈是全世界最大的“大便三明治”。

便便烹饪法

Google 的大部分工程师在移动或 Web 编程方面实在是太自大了。“我不做前端”,他们用自傲的声音高声宣告着。这其中甚至存在一种我称之为“DAG 蔑视(DAG of Disdain)”的现象,DAG 是指有向无环图(Directed Acyclic Graph),有点类似于流程图的东西。

在这个鄙视链中,使用 C++ 写代码的,崇高的搜索工程师位居最顶部,人们认为 C++ 比 Java 酷,而 Java 又比 Python 酷,Python 则比 JavaScript 酷。而搜索无疑要比广告酷,广告要比应用酷,应用则比工具酷,工具比前端酷。以此类推。

程序员们喜欢互相鄙视。

如果你倒了八辈子霉成为 Google 的移动工程师,就只能跌落鄙视链的最底端,其他所有人都位居你的上位,大家都在俯视你。

但当我一个人亲自逐一完成所有这些工作,从系统编程到大规模数据工程,再从编译器设计到服务框架开发,从游戏开发到 Web 开发再到移动开发,我可以向你保证前端编程哪怕不会更难,至少也和其他工作一样难。

后端的一切都显得那么美观、简洁、有序、分布式、可并行;尽管已经过了 25 年,但相比乱七八糟的 Web 开发,后端开发依然美好如天堂。如果再和包括 iOS 在内的移动编程那种“大便三明治”相比,哪怕 Web 编程也会显得犹如巴厘岛度假那般美好。

Android 呢?没错,Android 就是最大的“大便三明治”。如果你不介意的话,完全可以说 Android 开发者都是英雄。为 Android 开发诸如 Google Maps、Facebook 或 Snapchat 这样的大型应用,说起来,你绝不会相信我的看法:哪怕只修改了一行代码,也要坐等 20 分钟才能知道结果。

你的每次改动,无论多么微不足道,都有 80% 的可能首次尝试就无法生效,因为 Android 的特征互操作性矩阵简陋到让人吃惊。你当然可以使用 X,也可以使用 Y,但你就是不能同时使用 X 和 Y,反正就是不行。

设备兼容性这事更是没法说。我的作品在 Google Play Store 有很多愤怒的一颗星评论,因为我开发的 Wyvern 游戏就是会随机地无法在 LG 的设备上运行,为了重现 Bug,不得已的我只能去 eBay 买了个售价 60 美元的低端 LG 设备(而不是 600 美元的高端货),然后发现,获取鼠标点击事件的 Android API 有两个,而其中一个就是不能在 LG 的设备上使用。

事情实际是这样的:很多厂商,无论规模大小,都会用自己的框架替换 Android 框架。这种做法不光发生在缺少的功能对应的支持库上,而是普遍存在的情况。甚至有些厂商会全面替换 Google 的整个 Android 开发栈。微软有 Xamarin,Adobe 有 Cordova,Facebook 有 React Native,这简直是疯了。再仔细看看,还有 Framework7、Appcelerator Titanium、Onsen、Sencha、Kendo、XDK、Ionic、Mobile Angular、Unity……讲真,这到底是要闹哪样?

就好像每个尝试过 Android 开发的人都会在放弃之后说一句:“局面太糟糕了,我要自己成立一家创业公司,创造更美好的明天。”

而 Google 呢,也没比他的竞争对手好多少,对此问题只是说:“是吗?但你是没法战胜我们的,因为我们自己都在左右互搏!”,然后 Google 就发布了 Flutter,这是一种专为与原生 Android 竞争而生的 Android 开发栈(这说法可不是我编造的),而 Android 团队甚至拒绝承认它的存在

袭击 Android

上面这些开发框架的问题在于,会让 Google 对 Android 的控制变得非常脆弱。大部分此类框架都是跨平台的,这意味着写一个应用就可以同时在 iOS 和 Android 上运行。无论大公司或小作坊,没人愿意支付两份薪水,组建两个开发团队,只为了针对不同平台开发完全相同的应用。巨大的经济压力迫使很多公司转为使用跨平台框架。唯一拖后腿的地方在于,目前这些框架不如“原生”开发框架那么棒。

但很多此类框架(尤其是 Facebook 的 React Native)距离这个目标已经非常非常近了。如果其中某个框架有幸占据了足够大的市场份额,那么基本上 Android 就等于变成了开发者生态系统中的一环,并且是不再被 Google 控制的一环。

这似乎并不是什么大不了的事情,因为 Google 依然控制着 Play Store、OEM 厂商以及技术授权之类的东西。对大部分人来说,他们也许很舒适地坐在驾驶位上,不过别忘了:如果所有移动开发者都开始使用某一个特定的跨平台框架 X,那么基本上任何其他硬件/操作系统厂商或联盟都会开始提出自己能直接兼容框架 X 的竞争性硬件/操作系统平台(例如,假设就说 Windows 吧),而所有应用都将能在这个平台上运行(也许启动速度还能更快),这会将 Google 彻底淘汰。相信我,想做这种事的公司有很多。好吧,不该这样说,并非所有公司都想。其实不管哪个公司,谁会不想呢?

面对这种情况,Google 的回应是继续坚持自己的立场。他们开始加倍下注自己的“原生”(传统)Android 编程,为 Kotlin 语言提供官方支持,对于原生 Android 程序员来说,这已经是一步很大的举措了。我喜欢 Kotlin,它代表着 Java 的未来,但必须承认:它已经不是移动市场的未来方向了

人们使用跨平台框架开发程序,主要出于两大原因:首先,他们希望工作量不翻倍的情况下,就能让自己的应用在两个平台上运行;其次,由于 Android 原生编程至今依然让人感觉痛苦,虽然有了 Kotlin,很多公司依然(无可非议地)认为应该彻底推翻原有的一切,换一种更简单的方式从零开始。

如果你是 Android 或 iOS 开发者,并且花了一些时间尝试过 React Native(Facebook 正是为了解决上述问题而发明了它),不到 30 秒你就会意识到,这果然是一种更好的方法,不过前提是你开发的不是游戏,否则你可能更愿意使用 Unity。

对于业务应用和生产力应用,React Native 提供了合理的性能、跨平台兼容性、极为方便的工具(最棒的工具来自微软!上文刚提过他家的产品),以及大幅提高的开发速度。还记得上文说过的吗,常规 Android 开发栈中,哪怕修改一行代码,也要等 20 分钟才能看到效果。诸如 Nest 或 Facebook 等最大型的应用中,这种问题已经司空见惯,对于中等规模的应用,通常等待 2-3 分钟就够了。但如果使用 React Native,立刻就能看到结果。更改代码,改动立即生效。

伙计们,这就意味着产品发布速度可以提高 10 倍,产品上市速度可以变得更快,意味着你可以更好地发挥先行者优势,意味着你会不断地赢得竞争。放弃原生编程框架,转为使用诸如 React Native 这种节奏更快地跨平台框架,这才是制胜之道

我怀疑,在没有证据的情况下,Google 的 Android 团队并不能明确跨平台对他们而言是好是坏,但他们正倾向于认为是“坏”,否则他们就会为跨平台的 Flutter 提供更多支持。个人而言我觉得这对他们是有好处的,但我又懂啥呢。

无论如何,Google 目前正在努力改善原生体验,试图借此维持自己的统治地位。原生开发体验对诸如 Snapchat 以及 Instagram 这样的大型应用会显得最不友好,而 Google 的主要目标恰恰是改善大型应用的开发体验,而这主要是由构建所需的时间决定的。

为此,Google 正在通过大量努力改善“官方”的 Android 应用程序构建系统,而这套系统自身是基于本就非常复杂的 Gradle 系统实现的,Google 只不过是在这基础上塞入了一堆乱糟糟的 Android 规范。导致这个系统变得越来越复杂,以至于甚至构建工程师都无法完全理解其中的组件。构建类型(Build type)、产品风格(Product flavor)以及风格维度(Flavor dimension)之间有什么区别?你猜!而 Google 还在不断让水变得更浑浊,因为他们觉得这些特征对开发大型应用的大型公司很重要。

讽刺之处在于,大部分大型公司正在积极转为使用 Facebook 的 Android 构建系统:Buck,Google 在这方面似乎已经陷入了死胡同。

尽管 Google 已经意识到问题所在,但他们下重注提出的解决方案却没人喜欢:原生开发栈,以及复杂程度进一步暴增的 Gradle 构建系统。开发者正在远离,第三方技术栈正在攻城略地

侧翼袭击

更糟的是,围绕 Android 的袭击不光发生在开发栈方面,他人还可以通过其他方式将 Android 从 Google 手中“盗走”。例如创建一个更成功的应用商店。Play Store 是 Google 对 Android 加以控制的主要方式之一,但在这方面已经产生了大量争议(企业层面以及管控层面),因为 Android 据称是一个开放的系统,但 Play Store 完全由 Google 控制。由微软和 Twitter 支持的 Cyanogen 曾被视作推翻这一现状的重大举措,虽然由于内部权力争斗最终失败,但也曾首次给予 Play Store 一记重拳。

另外也请猜猜看还有谁在应用商店方面下狠手了?没错:Jeff Bezos(译注:Amazon 的 CEO)。Amazon 的应用商店已经发展得很好了,而 Amazon 与 Google 的每次面对面竞争中,长期来看 Amazon 的成绩都很棒。当心啦!

如果这些还不足以让 Google 开始担心,那么围绕 Android 还有第三场袭击,这场袭击无异于在 Google 的伤口上撒盐:在线广告。Facebook 的 Android 应用已经变得无比庞大(数以百计的工程师多年辛苦工作的结果),以至于这个应用本身已经发展成为一个真正的平台,现在,企业可以直接将自己的广告投放到 Facebook 应用中。例如纽约时报可以购买广告位,而他们支付的费用将全部直接进入 Facebook 的口袋,一分钱都不会给 Google。你觉得 Google 对此会有何感受。

在中国,微信也在做着完全相同的事情。微信应用也已成为一个繁荣的平台,我们可以在此基础上开发并部署其他应用(以及广告),就好像这个应用内部就直接嵌入了一个完整的生态一样。Facebook 和微信的移动应用已经成为了独立的广告发布渠道。

需要明确的是:Google 创造 Android 的唯一原因在于,对它而言 Android 是个广告渠道。Google 是一家广告公司,全球最大的广告公司,而他们始终会面临其他希望借助 Google 之外的其他渠道,将广告投放到用户面前的企业无休止的攻击。从财务角度来看,这与围绕网络中立性的很多争议几乎如出一辙。电信运营商和 ISP 希望由他们提供你所看到的广告,或者希望至少能从 Google 和 Facebook 的口中分一杯羹。

不管什么时候,当你看到诸如 Facebook、Google、Amazon 或微软这样的公司突然很莫名其妙地开始涉足某个全新的、奇怪的业务领域,那么你就可以确定:渠道争夺战又开动了。Google Chrome 是控制 Web 访问的渠道战产物;微软的 Xbox 曾是对抗 PlayStation 的渠道战产物,然而却又威胁到了 PC 在家庭在线娱乐渠道中的地位;YouTube 曾是渠道战的产物;Instagram 和 WhatsApp 也是类似产物;HBO/Amazon/Netflix 的内容战争实际上也都是渠道战的产物。Amazon Echo 也是如此,每个人的家庭已成为当今渠道争夺战最大的战场。对地方性的广告公司来说,就算 Google Maps 也是渠道战的产物。仔细看看,渠道无处不在。

底线在于,很多公司希望你能通过他们,而非别人的渠道欣赏自己喜欢的内容(书籍、电影、游戏、Natalie Portman 的两性专栏),这样他们才能通过广告获得收益,或者最起码也能通过你为所订阅服务支付的费用获益。

Android 可能是 Google 最重要的渠道,就算目前还不是,未来十年内肯定也会是。Google 无法承担失去这个渠道的后果。但我们目前已知的,围绕这个渠道已经在三个不同领域产生了至少三场多方配合的攻击:开发者生态体系(以 React Native 为首的团伙)、应用商店(Amazon 的应用商店以及传说中 Cyanogen 即将上线的商店),以及轻量级的应用内市场(目前以 Facebook 和微信为主攻)。截止目前,Google 对这三处攻击的应对措施……额,姑且算是小有成果吧。但这只是暂时的。

所有这一切看起来都像是一系列没什么用处的夸张猜测(其实原本就是),但最终却对 Grab 这样的公司产生了切实影响,因为对于为自己的移动应用使用哪种技术栈,我们需要做出重要的决策,毕竟应用(具体来说其实是渠道)才是我们通向世界的窗口,对乘客、司机、商家、代理人员等无外乎于此。

如果你认为 Google 确实有可能失去对 Android 的控制权,哪怕只有一丢丢的风险,那么最好选择使用跨平台的框架,因为可移植性能够为你提供必要的保护。而如果你(像 Grab 一样)陷入了激烈的竞争态势中并且需要加快产品的发布速度,那么你可能至少要放弃 Android Native 方法。Android 依然在 Gradle 的道上闷头朝前走,这条路怎么走都不会快的,而这主要是因为 Android 在设计方面有很多严重,并且难以解决的遗留问题。

在众多跨平台技术中,React Native 似乎将成为最后的赢家。它还吸引着广大 Web 开发者,而他们可能是全世界最大的开发者群体,这一点毋庸置疑。Grab 最近也开始评估 React Native,我们想知道它能否实现自己的全部承诺,现阶段我们的结论很乐观。

距离 Grab 彻底放弃原生 Android 和 iOS 应用的那一天还很远,因为移植工作需要花费不少时间。我们有 React Native 的工作,有 Android Kotlin 的工作,还有 iOS Swift 的工作,其实全球各地对这些工作岗位都还有着巨大的需求。如果你得不到老东家的赏识,不妨打量一下周围的其他机会。过去三年来,这个领域发生的变动实在是太多了。

本文的中心思想可总结如下:和每个人一样,Grab 也需要移动开发者,但很难招到理想的人员,因为 Android 编程实在是太烦人了,而且除了 Google 每个人都有类似的感受。因此目前整个生态中开始出现越来越多的竞争对手,他们都希望自己提出的方法最终将成为移动编程的唯一方法……而这也导致移动开发者更难招了,因为整个生态是如此的碎片化!

无论你倾向于哪种技术,现在都是成为移动开发者的最好时机。如果你还不是移动开发者,那么应该考虑一下涉足这个领域体验看看。你可以从后端体验着手,随后学习移动开发,进而让自己成为“全栈开发者”,这可是一种更稀缺,也更有市场的独角兽。

当然,现在也是通过竞争夺取 Android 控制权的好时机,如果你真想这样做的话。正在做这事的公司可不少呢,鬼知道为什么,就连 Google 内部的其他团队也正在这样做。越来越多的鲨鱼正在登上 Android 这艘船,Google 需要小心了。

  原文链接

https://medium.com/@steve.yegge/who-will-steal-android-from-google-af3622b6252e

 前端之巅

「前端之巅」是 InfoQ 旗下关注大前端技术的垂直社群。紧跟时代潮流,共享一线技术,欢迎关注。

  活动推荐

PWA、小程序、RN...大前端的下一站在哪里?前端工程师的价值和成长路径是什么?GMTC2018上,来自Google、Facebook、BAT等60+国内外一线前端大牛,将与你面对面探讨大前端领域最新技术趋势和实践,想要升职加薪就快来吧!扫描下方二维码或点击“阅读原文”了解更多大会详情!

目前大会最低价6折售票火热进行中,团购更优惠,购票咨询:18514549229(同微信)

 
猜您喜欢 第二波赠书活动持续进行中~ Spark+AI Summit 2018:当 Spark 遇上 AI R中的向量化计算 如果想将咖啡豆磨成代码,那就去买台“程序员”好了 分布式网游服务器架构中的对象管理