作者｜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 需要小心了。