谷歌离职员工:谁能从谷歌手里偷走安卓?

点击上方“程序员大咖”,选择“置顶公众号”

关键时刻,第一时间送达!


一个人对前东家会恨到什么程度?看看 Steve Yegge 就知道了。曾经在 Google 干过 13 年的他不久前离开搜索巨头加盟了东南亚共享打车公司 Grab,并且通过一篇《为什么我要离开 Google》数落了前东家的种种不是。大概是嫌这还不够,最近他又写了这篇《Who will steal Android from Google?》,数落了 Android 原生开发的种种不是,分析谁可能会从 Google 手里抢走 Android 的控制权。


Android 也许是 Google 最重要的渠道——如果今天不是,那未来 10 年肯定是。他们无法承担失去对 Android 控制的损失。但是现在 Google 正面临三个维度的全方位打击:1)各种跨平台的开发框架2)想要取代 Play Store 的应用商店3)Facebook、微信等平台型 app 正在应用内直接做广告业务。遗憾的是,Google 对此似乎还没有清醒的认识。



今天,我想以局外人及 Android/iOS 开发爱好者的身份谈谈 Android。既然人人都知道你不可能连续两次都成为爆款,所以这篇文章很可能不会流传很广。今天就你我吧。


我总是惦记着 Android 是因为我们在招移动开发者,你一定认为这是很简单的任务对吧?但结果表明这是市面上最热门的商品之一。Grab 需要他们,每个人偶读需要他们,但是市面上找不到那么多人。这就好像想抓住一头独角兽一样。


为什么每个人都需要移动开发?因为 web 正在慢慢走向灭亡。我在 Google 的每个组织都有朋友——好吧,也许现在是前朋友了,他们会向我展现令人沮丧的图表,不管你怎么折腾,随着整个世界向移动转移,web 都在稳步地走下坡路。见鬼,你大概还记得8、9 年前 Facebook 从 web 优先向移动优先过渡的经历吧?那次 Facebook 差一点一命呜呼了。我的意思不是说一夜暴毙,但当这家公司意识到自己必须成为移动公司否则就要面临湮没时,他们经历的完全是一场生存危机。


他们设法渡过了这场危机,但这并不容易,因为 Android 的开发栈是全世界最大堆的狗屎三明治。


狗屎烹饪


在 Google 大多数工程师都很清高,他们认为做移动或者 web 编程是不入流的事。“我不做前端,”他们用最傲慢的语气说。这种现象我喜欢称之为“鄙视的 DAG,”DAG 的意思是有向无环图(Directed Acyclic Graph),有点像流程图。在鄙视链顶端是崇高的搜索工程师,他们用的是 C++ 语言,这门语言被认为比 Java 要更酷,而后者又比 Python 酷一点,然后后者又比 JavaScript 酷一点。而搜索又比广告(Ads)酷点,广告又比 App 酷点,App 又比工具酷点,工具又比前端酷点。诸如此类。程序员喜欢互相鄙视。如果你时一名 Google 移动工程师的话,那实在是太不幸了,因为你处在所有鄙视链的最底端。


但是,在我本人亲身经历过从系统编程到大规模数据工程、编译器设计、服务框架、游戏开发、web 开发以及移动开发之后,我向你保证,就算前端编程不比其他的编程工作难,也绝对不会比其他工作容易。后端的一切都干净整齐有序呈分布式或并行化;相对于依然跟 25 年前一样恶心混乱的 web 编程,后端简直就像天堂。但是跟移动编程(包括 iOS 在内)相比,web 编程就像一趟美好的巴里之旅,而前者就像一堆狗屎三明治。


Android 呢?是的,那是所有里面最大的狗屎三明治。Android 开发者是英雄,如果你原谅我的话里有话的话。为 Google Maps 或者 Facebook 或 Snapchat 这样的大型应用对 Android 进行编程就像……算了就算我说了你也不会相信我的。你修改了一行代码,然后坐下来等 20 分钟再看看会发生什么吧。而且你每改动一次,不管这次改动是如何的微小,80% 的可能是第一次都不成功,因为功能互用性矩阵是出奇的稀疏。当然,你可以使用X,也可以使用Y,但是X和Y同时用就不行,因为去你的,伙计。


得,我还没扯到设备兼容性问题。我在 Google Play 商店上面得到了一堆的 1 星评价,因为我的 Wyvern 游戏 app 偶尔无法在 LG 设备上正常运行,于是我被迫到 eBay 上买了台寒酸的 60 美元的 LG 设备(而不是一台寒酸的 600 美元的 LG 设备)来复制那个 bug,结果发现,嘿,他们有两个 Android API 来在列表框上获取鼠标点击事件,但其中一个 API 在 LG 上没法用。


我的意思是,想想看吧。


现在的情况是:大大小小有一堆的竞争对手都想出了自己对 Android 框架的替代。我说的不仅仅是缺失功能的支持库,尽管他们缺少了很多。不是。我说的是对 Google 的整个 Android 开发栈的完全替代。微软有 Xamarin,Adobe 有 Cordova,Facebook 有 React Native,我的意思是说这是个疯狂小镇。真的,好好看看吧。Framework7、Appcelerator Titanium、Onsen、Sencha、Kendo、XDK、Ionic、Mobile Angular、Unity,我的意思是,到底发生了什么事?


这就好像是但凡尝试过 Android 编程的人都已经放弃并且宣布:“这太糟糕了我要自己创业把它做得更好。”


不想被竞争对手超越的 Google 回应道:“哦是吗?你不可能跟我们争的,因为我们准备自己跟自己争!”然后他们推出了 Flutter,我绝不是乱讲——这是一款跟原生 Android 竞争的、100% 严肃的 Android 开发栈,Android 团队根本就不愿意承认它的存在。

活着真好啊。


对 Android 的袭击


这些开发框架意味着什么呢?意味着 Google 容易受到攻击。它们大都是跨平台的,这意味着你写一个 app 就能同时在 iOS 和 Android 上面运行。不管你是大公司还是小作坊,没人愿意给两支工程团队付钱去在不同的平台上去做一模一样的 app。所以迁移到跨平台的框架存在着庞大的经济压力因素。唯一阻止这变成大逃窜的事情是这些框架还没有像“原生”开发那么好。


但是其中已经有少数(尤其是 Facebook 的 React Native)非常非常接近了。如果它们中间的一个设法攫取足够大的市场分,则 Android 基本上就变成了开发者生态体系的管道,不再受 Google 的控制了。


这个看起来似乎并不是什么大生意,因为 Google 仍然由 Play Store 和 OEM、授权等手段。对于大多数家伙来说,他们可能似乎愿意舒服地坐在驾驶员座椅。但考虑到:如果所有的移动开发者都开始使用特定的跨平台框架X时,则任何其他的硬件/OS 制造商或联合体均可推出自己的竞争性硬件/OS 平台(比如 Windows)来直接支持框架X,所有的 app 都能在它上面跑(可能启动还更快),这样 Google 就被完全切断了。相信我吧,很多公司都想这么做。对不起,我的错,不是很多。时所有人。谁不想呢?


对此 Google 的反应是坚定立场。他们在“原生”(传统)Android 编程上加倍下注,为 Kotlin 语言提供官方支持,对于原生 Android 开发者来说这是一大进步。我喜欢 Kotlin;那是 Java 的未来。但我们得面对现实:移动市场的发展方向不是这个。大家编写跨平台框架有两大原因:首先,因为他们希望自己公司的 app 无需做两遍事情就能在两个平台上运行。其次,因为 Android 原生编程仍然非常痛苦,即便有了 Kotlin,许多公司仍然觉得自己应该抛弃 Android 用某个更容易的东西从头开始。


如果你是 Android 或 iOS 开发者,并且用过一段时间的 React Native(Facebook 做这个就是为了解决这些问题),在 30 秒钟内你就会意识到它要好多了,假设你写的不是游戏,如果是的话你大概会用 Unity。对于商业和生产力 app,React Native 提供了合理的性能,跨平台的兼容性,不可思议的工具(最好的出自微软。你好,欢迎回来!),以及得到极大改进的开发速度。记得前面我说过在正常的 Android 技术栈上改一行代码要 20 分钟才能看到结果吗?像 Nest 或者 Facebook 这样的最大 app 身上就有可能会发生这样的事情,但即便是中等规模的 app 也要2、3 分钟。而用 React Native 的话几乎是马上出结果。你做出改变,然后看到改变。


而这意味着你推出功能的速度可以快 10 倍,进而意味着推向市场的速度更快,进而拥有先发优势,然后就是胜利接着胜利。抛弃原生编程投向 React Native 这样的快周期的跨平台框架是致胜策略。


虽然没有证据,但我怀疑 Google 的 Android 团队不确定跨平台对他们究竟是好是坏,但他们的倾向是“坏”——否则的话他们会支持跨平台的 Flutter。我个人认为这对他们是好事,但是我有知道什么呢?


无论如何,他们目前正在努力聚焦于通过让原生体验不那么糟糕来保持领先上面。由于对 Snapchat 和 Instagram 这样的大应用来说 Android 是最糟糕的,他们主要想解决的是大型 app 的开发体验问题,而这个主要又取决于构建时间。


为了解决这个,Google 对“官方”Android 应用构建系统进行了惊人的大量工作,其基础又是已经非常复杂的 Gradle 系统,但然后 Google 又堆砌了一堆 Android 特性的东西。久而久之这套系统变得越来越复杂,以至于连构建工程师都无法理解其中的部分东西了。build type、product flavor 和 flavor dimension 之间有什么区别呢?只能助你好运了。但是他们一直在不断地堆砌复杂性,因为他们以为这些特性对大厂的大 app 很重要。


讽刺的是最大的公司正在积极地倒戈相向——抛弃 Google 的,转用 Facebook 的构建系统。Google 追逐的是一项濒死的战略。


所以尽管 Google 似乎知道自己有问题,但是加倍下注的却是一个没人喜欢的解决方案:一个原生的技术栈,加上一个复杂到令人抓狂的 Gradle 构建系统。他们正在失去开发者。第三方技术栈正在攫取市场份额。


侧面攻击


更糟的是,开发栈并不是 Android 遭遇的唯一袭击。从 Google 手中“偷”走 Android 还有其他办法。办法之一是建立一个更加成功的应用商店。Google 对 Android 最大的锁定是 Play Store,但是这个引起了很多的争议(无论是来自公司还是政府的),因为 Android 据称是开放系统,但 Play Store 却是 Google 100% 控制。微软和 Twitter 支持的 Cyanogen 是一招妙棋,尽管由于内讧而失败了,但它仍然是对 Play Store 进行割喉的第一次认真的尝试。


不过再猜猜谁又来在这场应用商店大战中插一杠?想不到吧:贝索斯,因为不从 Google 手里偷走 Android 的话你没法成为全球首位万亿富翁。好吧……不管怎样,我喜欢想象这一点会有所帮助。Amazon 的应用商店已经颇为令人印象深刻,而且几乎在所有 Amazon 与 Google 的面对面的竞争当中,Amazon 都是执行更好的那个。等着瞧吧!


如果这还不足以令 Google 感到担心的话,对 Android 还有第三波攻击,而且这个正是它的痛点:广告。Facebook 的 Android app 已经变得如此庞大(经过数万工程师数年的努力),以至于它已经发展成为为一个真正的平台,现在你可以直接在 Facebook app 里面植入广告。比方说《纽约时报》就可以在上面购买广告位置,所有的钱都直接从《纽约时报》转到 Facebook,而 Google 一分钱都拿不到。你可以想象一下他们是什么感觉。


中国的微信干的事情跟 Facebook 一模一样(编者注:其实应该是反过来好吧)。微信已经变成一个生机勃勃的平台,在它上面就可以搭建和部署其他 app(也包括广告)。这就好像整个市场都被嵌入到 app 里面了。Facebook 和微信移动 app 已经成为了独立的广告渠道。


我们就直说了吧:Google 创建 Android 的唯一原因是因为这是个广告渠道。Google 是一家广告公司,全世界最大的广告公司,他们一直一直一直都在受到其他想要让你的注意力转移到自己的渠道而不是 Google 的渠道的公司的攻击。最后的分析里面谈到的对网络中立性的攻击就是这个。电信运营商和 ISP 希望塞广告给你,或者至少要从 Google 和 Facebook 赚的钱里面分一杯羹。


只要你看到像 Facebook、Google、Amazon 或者微软这样的公司神神秘秘地进入一个奇怪的新业务领域,你几乎可以打赌他们打的是渠道的主意。Google Chrome 是渠道,为的是控制对 Web 的访问。微软的 Xbox 是渠道,为的是针对 PlayStation,以防后者踢走 PC 坐上家庭上网渠道的位置。HBO/Amazon/Netflix 内容大战完全也是渠道之争。Amazon Echo 是渠道;你的家是当今渠道之争最激烈的战场。甚至 Google Maps 也是本地广告的渠道。一旦你留意观察,就会发现处处都是渠道。


归根结底,那些公司希望你通过他们而不是别人的渠道去观看喜爱的内容(书、电影、游戏、波特曼的性专栏),这样他们就能获得广告收入,或者至少能拿到它的小妹妹,订阅收入。


Android 也许是 Google 最重要的渠道——如果今天不是,那未来 10 年肯定是。他们无法承担失去对 Android 控制的损失。但是我们已经看到它至少面临着三种不同维度的协同攻击:开发者生态体系(React Native 等),应用商店(Amazon 的应用商店以及据传 Cyanogen 的后继者),以及轻量级的应用内市场(目前是微信和 Facebook)。目前为止 Google 对上述每一种威胁的反应是……好吧,就只是说我们还是领先。目前为止。


不过,话又说回来……


这一切似乎都是一堆没有用的夸张质疑,但它的确影响到了我们 Garb 下面的工作了,因为我们必须就我们的移动 app 采用什么样的技术栈做出重大决策,而我们的移动 app 就是我们面向世界的窗口——是我们面向乘客、司机、商家、代理等的渠道。


如果你认为 Google 有任何风险会失去对 Android 的控制的话,那你最好的办法就是使用跨平台框架,因为它可以通过可移植性改善来对冲风险。而如果你陷入到激烈的竞争当中需要发布得更快的话,你可能应该避开 Android Native。Android 仍然被 Gradle 拖累,这玩意儿永远也快不了,而这个很大程度上是因为 Android 设计上的遗留问题,这种问题是很难掩盖的。


在跨平台的选项当中,React Native 看起来似乎是获胜者。它对 web 开发者很有吸引力,而后者大概是全球最大的开发者受众。Grab 目前开始往 React Native 上面投资看看它是不是能够兑现它的承诺,目前为止情况似乎还相当不错。


概括一下本文的主要思想:跟其他人一样,Grab 需要移动开发,但那些人很难找因为 Android 编程非常令人讨厌,而且显然大家都知道这一点,除了 Google 自己,所以现在生态体系开始涌现了不少竞争对手,它们个个都想成为移动编程的唯一平台……而这又导致招聘开发者难上加难因为碎片化太严重了。


但不管你的选择是什么,现在是移动开发者的好时候。如果你是非移动开发者,应该考虑换一下工种了。从后端开发开始然后学习移动开发会让你成为“全栈开发者”,这在市场上可是更加稀有的独角兽。


现在是争夺对 Android 控制权的好时机,如果你要做这件事的话。见鬼,甚至连其他的 Google 团队也在做这件事。虽然我们会受到这件事结果的实质性影响,但 Grab 不会去做这件事。但是 Android 这条船周围有很多鲨鱼环伺。Google 得小心了。



  • 来源:36kr

  • http://36kr.com/p/5124836.html

  • 程序员大咖整理发布,转载请联系作者获得授权

【点击成为Java大神】

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值