今天,我想以局外人及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得小心了。
相关推荐
由于提供的文件【标题】和【描述】内容相同,仅包含“离职面谈:管理好离职员工远离诉讼员工离职相关资料.pdf”,但【部分内容】为OCR扫描结果,存在大量乱码和不完整信息,从中提取知识点变得非常困难。尽管如此,...
《离职面谈:管理好离职员工远离诉讼》 在IT行业中,人力资源管理是企业运营的重要环节,而离职面谈作为这个环节的一部分,对于维护企业稳定、预防法律风险具有至关重要的作用。离职面谈不仅是对员工离职原因的了解...
4. 团队文化:离职面谈能揭示团队文化是否健康,是否存在不利于员工留任的因素。良好的团队氛围有助于提升员工归属感,减少流失。 5. 沟通反馈:了解员工对上级领导、同事以及公司沟通机制的评价,及时发现并解决...
离职员工面谈记录表是企业人力资源管理中一个重要的环节,旨在了解员工离职的真实原因,收集反馈,以便改进工作环境和管理策略,降低员工流失率。以下是对这些提问中涉及的知识点的详细说明: 1. 离职原因:员工...
离职面谈:将员工的心永远留在公司_入职离职人事管理制度规范.doc
52_离职面谈:将员工的心永远留在公司_入职离职人事管理.doc
员工离职通知书是人事管理中的一种重要文件,它记录了员工离职的相关信息,包括员工的基本信息、离职原因、离职日期、离职流程等信息。员工离职通知书是人事管理中的一种重要手段,旨在规范员工离职的程序,保护企业...
在企业运营中,员工离职是常见的情况,而员工离职时的移交手续是非常关键的一个环节,它关乎到企业的正常运行和信息安全。"第八节 员工离职移交手续清单"就是一个详细指导这一过程的重要文档,旨在确保离职员工在...
员工离职预测是现代企业管理中的重要课题,通过建立预测模型,企业可以提前识别出有离职倾向的员工,从而采取措施保留关键人才,优化人力资源配置。本文使用RapidMiner这一数据挖掘工具,结合多种机器学习算法,如...
员工离职模板系列-离职申请表.doc 员工离职模板系列-离职申请表.doc是公司人事相关模板的一种,旨在规范员工离职流程,确保员工离职手续的完整性和合法性。以下是该模板中包含的知识点: 1. 员工基本信息:该部分...
在企业运营中,员工离职是常见的情况,但处理不当可能会带来诸多问题,如信息泄露、工作交接不畅等。因此,规范的员工离职手续流程至关重要,尤其在涉及集团税务信息化的背景下,确保离职过程的合规性和效率对于维护...
1. 离职申请:员工离职申请是员工向公司正式表达辞职意愿的书面文件,通常包括员工的基本信息、离职原因、期望离职日期和工作交接安排等内容。 2. 格式规范:离职申请通常包含礼貌的开头、主体内容(解释离职原因)...
在企业运营中,员工离职是常见的情况,而员工离职时的移交手续是非常关键的一个环节,它涉及到公司的资产保护、业务连续性以及离职员工的权益。本文将详细解析“员工离职移交手续清单”,并阐述其重要性和执行过程。...
标签为“教育”,这可能是因为在某些情况下,离职交接表是员工在职教育的一个部分,用于确保员工能够顺利地从公司带走自己的工作经验,并确保工作的连续性。 离职工作交接表是一份非常重要的文档,它涉及多个方面的...
《员工离职面谈问题清单与集团税务信息化》 员工离职面谈是企业了解员工离职原因、改善工作环境、提升组织效率的重要环节。以下是一些在离职面谈中可能涉及的关键问题,这些问题旨在全面评估员工离职的原因及公司的...
文档“员工离职物品移交清单.doc”主要关注的是员工离职时的工作交接流程,特别是涉及的实物资产和重要资料的转移。这个清单确保了员工在离职时能够完整地将所有公司财产交还,避免任何财产的丢失或遗漏。以下是相关...
这是员工离职因素数据集,包含了员工工作时长,KPI打分等等影响离职的因素,是博主博客决策树与随机森林所应用到的数据集
"参考资料-46_员工离职工作交接表.zip"是一个压缩包文件,其中包含了一份名为"46_员工离职工作交接表.doc"的文档,这通常是一份详细的模板,用于指导离职员工系统地进行工作交接。 这份交接表是离职管理的关键工具...
《员工离职流程及表格》是企业在人力资源管理中不可或缺的一部分,规范了员工离职的步骤和相关文档,确保企业资产安全和员工权益的保障。以下是详细的知识点解析: 1. **离职申请**: - 正式员工辞职需提前1个月...
离职证明是一种正式的文档,由员工的前雇主出具,确认该员工已经结束其在公司的雇佣关系。这份文档在员工寻找新工作或者办理相关社会福利时可能会被要求提供,以证明其就业状态的变化。以下是离职证明的主要内容和...