七年iOS工作经验的我为什么放弃了iOS而选择了Android

摘要

上周一我非常开心。因为我被允许为一个曾经工作过的客户开始开发一个新的 Progressive Web App 原型。

七年iOS工作经验的我为什么放弃了iOS而选择了Android

英文原文:Why I switched to Android after 7 years of iOS

上周一我非常开心。因为我被允许为一个曾经工作过的客户开始开发一个新的 Progressive Web App 原型。

我拿出一个常在我身边的用来开发的比较老式的 Android 手机。然后我从我的口袋里拿出精致的 iPhone 6S,它有着非常棒的界面设计和敏捷的操作系统。然而当我看着我的 iPhone 时我有一些沮丧。

我意识到外表光亮的苹果手机硬件作为一个平台有些不兼容 web 应用,而我那又脏又破的 Android 手机却可以。

就是这一点让我意识到我和 IOS 已经结束了。

因此,我没有打开我的文本编辑器而是下单买了一个 Nexus 6p Android 手机并且报名参加了 Google fi 手机服务课程(顺便提一下,这真的很棒!).

就这样,七年多以后,再见了 IOS。

什么!?IOS 有什么问题吗?

还记得当初 iPhone 的发布会吗?在发布会上乔布斯将这款令人吃惊的移动电话和音乐播放器和一个网络交流设备的组合介绍给了消费者。

我不知道你们是不是这样,但是在我的观念里有一个优秀的网页浏览器在我口袋里对我来说始终是一股巨大的诱惑力。

那种理念从未改变。

我当然不知道这背后的整个故事,但是可以肯定的是苹果公司的初衷是方便 iOS 第三方开发者能使用所有的 web 技术来开发 app。Safari (浏览器,是苹果计算机的最新操作系统 Mac OS X 中的浏览器)增加了对制作 web app 的支持,该 web app 可以作为一个图标添加到你的主屏上,并且通过在 web app 中添加少量能使用的具有魔力的元标签来制作出一个新的应用,这个应用可以安装到你的主屏上。然后,当你打开这个 app 时,它会以独立模式跑起来。

这个计划的这些内容在很多方面体现的就是最初的“Progressive Web App”,而这还是在 2009 年左右!

好好设想一下…

1. 它们可以在浏览器里打开,但是你可以稍微改进它们,让它们能在手机主屏状态下打开。

2. 当你在主屏上运行它们的时候,它们会以滑动屏幕的方式打开并且不需要任何可见的浏览器用户界面。

3. 你可以挑选一个加载屏幕显示方式和 app 图标。

4. 你甚至可以从几个不同的状态栏工具颜色里选择一款!

我不知道这种类型的 app 是否实际上是打算作为第三方开发者为 IOS 开发 app 的主要途径,但是不管怎样,这种方式已经走在了它所处时代的前面。

不幸的是,苹果公司的 Web 平台本身并没有完全准备好成为公众关注的焦点。它在某种程度上使创建的 web app 看上去和表现的像一个原生 app,这是六年前我用 David Kaneda 开发的很棒的 JQTouch 库准备做的事。好玩的是,我发布的一个老掉牙的演示视频,让我得到 David 的关注,他给我打了一个电话,这使我差点在 extjs 里获得一份工作,因为这时他们在重构 Sencha 并且开始编写 Sencha Touch 框架。但是电话断线使得一切成了泡影。

但是不管怎样,结果却是在 IOS 操作系统上的 web 的性能却不足以满足开发者对提高 IOS 上 web 性能的渴望。因此公司的开发者被留下来解决这个问题,他们常为解决优化 App 性能,使其在设备上能够自然地跑起来并且给它们更好的性能以及更高的 API 准入权限的问题而抓狂。

来看看 IOS SDKApp Store

苹果公司曾做出了一个被证明是一个非常聪明的商业决策:他们发布了一款 IOS SDK 和一个 App Store 和其余的部分。但是这个商业决策已经成为了历史。

首先,我对 app 很感兴趣,这种兴趣的程度看上去就和其他每一个人一样。当我们真正需要一直工作构建 app 时,我们就一直忘身心的忙于构建这种应用程序!谁知道呢?!;

总之,我很快发现我自己在到处寻找最好的的 app 并且不管什么样的银行应用,什么样的社交网络应用,和什么样其他的服务型的应用,只要这种类型的应用里有最好的 IOS 应用我就会去寻找。我买了一本关于在 IOS 操作系统上开发应用的书而且还写了一两行简单的代码。我以前的同事 Ryan Youngman 制作了一个 iSaber 应用,这个应用能让你用你的手机在你的朋友面前晃动形成一个虚假的光剑。我认识的每一个开发者都在谈论 IOS 开发但是这种情形在某种程度上使得 IOS 所带来的所有乐趣渐渐消失。

要明白你不得不通过在 IOS 上开发 app 来跳到 IOS 这个坑似乎并不正确。

很快开发者放弃了完全开放的 web 空间而选择一个砖墙高树的城堡,在这个城堡里的最高统治者强迫每一个进来的人缴纳 30% 的税收。

因此,我决定专注于为 IOS 构建”可安装的 web app”而不是去选择那个城堡,因为我很肯定 web 应用将会追赶上来的。

然而,这一切却成为了不确定

尽管原生 app 很流行,然而最初可以在这些单机上安装 web app 的设想仍被新版本的 IOS 操作系统支持。但是,web app 它们并不适合苹果公司的商业模式!苹果公司的 App Store 形成了很庞大的商业,”app”一词正在成为主流,每一个商人突然觉得他们需要有他们自己的”app”,无论他们是有一些使用他们 app 的用户还是没有。

随着苹果公司的 app 生意风生水起这些性能非常清晰和非常快速地被优化,这在某种程度上一点也不使人惊讶。最终的结果是,我们这些仍然在试着为 IOS 创建可安装的 web app 的人在几乎每一个新的 IOS 版本发布一些主要功能时我们就面临着破产。

我要说的是 QA (质量保证)应该始终被抓牢,我要说的是如果在苹果公司工作的人是通过遵守这种标准来构建的 app,那么在它们发布之前这种情况就应该被他们注意到了。

一个曾死死拖住我而且信手拈来的例子是他们是如何在一个 web app 在单机模式下运行时破坏 webapp 链接到外部站点能力的。target=_blannk 是仍然长时间在用的,既不可能是 window.open 对象方法也不是其他我能想到的方式。现在我们独立的 app 没有一个 URL 地址栏或者后退按钮,它只能让用户停留在他们第一次点击时全屏显示的 web 视图里却没有办法回到 app 界面!唯一的办法是强行退出 app (希望用户知道如何这样做)。

我们同时运营着一个聊天的应用产品,因此我们知道当某时有人在聊天页面粘贴上来一个 URL 链接时,那其实是一个陷阱。

这些问题仍然在出现,发布了一个又一个。很快你就会明白,你可以在 IOS 上构建这些类型的 web app,但是你不能指望它们不会被 IOS 的下一次更新所打断。

通过这些事情你可以看到从苹果公司传达的信息清清楚楚:在 IOS 上 web app 是二等公民。

此时 Android 怎么样?

在那时我并没有过多的关注过它,但是在中间这所有的一切发生的时候,Android 也开始出现在了舞台上。Google 公司承诺 Android 作为一个手机平台将是一个更加开放的选择。Android 操作系统让几个大公司形成了一个联盟,他们的目的是从根本上打败那个水果公司(这里的水果公司指得是苹果公司)和它强大的乔式 App Store 而让 Android 生存下去继而占取绝大部分的市场份额。

联盟的效果很明显,Android 开始获得吸引力,但是在刚开始的时候 Android 的 web 性能让人感觉很差劲。

五年很快过去了,情况如何呢?…

1. 人们被手机应用程序弄得心力交瘁的。

2. 绝大部分的开发者构建出的原生 IOS app 甚至从来没有让他们回本过。我们知道这些事情发生在 2013 年。

3. 少量的手机游戏仍然能赚到钱,但是那得看你的人品和运气了。

4. 与此同时,在全球却有超过 14 亿的活跃 Android 用户。

5. Android 转而使用 Chrome (谷歌浏览器)作为 Android 手机的默认浏览器。

6. Chrome 浏览器和 Opera 浏览器和 Firefox 浏览器增加了一些功能,这些功能允许通过 Web 来构建真实的 app 体验。

于是此时我放弃了 IOS,开始在 Android 上弄开发。

为什么选择 Android?它不是更多的是一成不变吗?

确实是这样,老实说,Android 手机本身让我感觉到讨厌。因为它并没有什么非常新奇的或者令人兴奋功能。

但是注意一个很重要的细节……

它是现在最好的手机 Web App 开发应用平台。

你什么意思?!苹果的 Safari 浏览器不是运行我的 JS 脚本更快吗?

很多人当他们谈到这个问题时都会提到 Jeff Atwood (又名 codinghorror)的帖子,这个帖子我写下了所有的原因来回应它并随后贴到了论坛,如果你感兴趣可以看看。

是的,Safari 浏览器确实能使我的 JS 脚本运行的更快,但是要知道的是……你的绝大部分用户并没有一个外表精致而且崭新的 iPhone 6s,并且像我之前所说的,在手机 Web 上押注类似电脑桌面的性能或者向一个手机设备发送庞大的框架像 Ember (JS 框架)也许并不是一个很好的注意。

而对于性能,有一种东西叫做”够用就好”。苹果公司的 Safari 浏览器即使是运行 JS 的速度比其它浏览器运行 JS 的速度快 50 倍也是毫无意义的!我看重的是在浏览器上我的 app 是否能够快速的被运行起来。作为一个手机用户,除此之外其它的我一点也不在意。

事实证明,编写的 web app 实际上是可以以 60 帧的速度运行在一个又破又烂的手机硬件上的。

但是将这一切放到一边,需要注意的是:我所说的”更好的 app 平台”不是指这个平台能以更短的时间更快的运行 JavaScript 脚本。

所以为什么不直接在 IOS 上用 Chrome 浏览器?!

于是我开始在 Twitter 上交流问题,我由最初的惊讶到最终意识到很多人并不知道能安装到 IOS 上的 Chrome 和 Opera 和 Firefox 在底层上使用的都是 WebKit web 视图。

然而实际上,包含了一个不同浏览器引擎的 app 是违法了苹果公司服务条款规定的。

那些浏览器只不过是在同一个浏览器引擎上使用了不同的 UI

那不会使 WebKit 越来越好吗?

是的,最近看上去它们有正在被拾起的势头。

但是在浏览器窗口中的变化之外它发生了更多的事情。我希望能在 IOS 操作系统上用 web 技术创造类似 app 的性能。

然而我可以直接告诉你在 IOS 上这方面的改进几乎没有。

让我们看看苹果公司和谷歌的 WebRTC

谷歌 WebRTC 简介链接地址: http://baike.sogou.com/v73305448.htm?fromTitle=WebRTC

几年前当我构建 SimpleWebRTC 和 Talky.io (一个浏览器组件)的第一个版本时。

我似乎成为了早期 web 极客中的一个,WebRTC 使我变得很开心(这项浏览器网页技术现在给谷歌的环聊提供了动力)。不管怎样,我努力的去解决怎样在 web 上构建第一个,或许是第一个多用户的,点对点的视频通话 WebRTC app,它可以在超过两个人之间工作并且能在 Chrome 浏览器和 FireFox 浏览器上运行。

Google Hangout 简介链接地址: http://labs.chinamobile.com/mblog/393695_200864

这是我第一次体会到苹果公司在实现新的 web API 方面的落后.虽然 Chrome 浏览器和 Firefox 浏览器对 WebRTC 都很热心而且努力地去实施它,但是苹果公司却对这一切装作毫不知情,哪怕瞧上一眼。苹果公司直到今天也没有在 IOS 里增加对 WebRTC 的支持。然而,苹果公司很明显正在雇佣 Safari 团队的 WebRTC 工程师。所以还是保持希望吧……。

他们那样做是有道理的,对吧?他们为什么要这样做呢?他们希望你使用 FaceTime,不是吗?

他们很乐意改善他们的浏览器引擎,但是他们似乎不愿意或者拖着去做任何涉及到把 web 的触角伸向他们手机操作系统的任何事情。

不管怎样,我们把 Talky.io 当做一个 web app 一样安装并在 Chrome 浏览器和 FireFox 浏览器上运行,而且最终@hjon 也用它构建了一个 IOS app.

现在充斥在我脑海里的是有这么一天当我在我的 Android 手机上下载下来 Chrome 浏览器,然后用它打开 Talky.io 时有这样的感觉:这个该死的东西果然运行了!(很高兴的意思。)

自从那时起我开始更加关注在移动端的 Chrome 浏览器上发生的事情,而且移动端的 Chrome 浏览器上发生的每一件事情令人印象深刻。

与此同时在 Android 上发生的事情

在过去的几年中,一些非常聪明,非常有耐心的理想主义开发者(他们中的很多人在 Google 公司工作)相信 web 会成为潮流并为推动 web 的发展努力工作,他们实行了新的 web 标准来弥补原生应用程序和 web 应用程序之间的差距。

难以置信的是一些非常酷的东西被开发了出来,像:

.WebBluetooth (是的,从一个网站的网页上运行编写好的 JS 程序能与蓝牙设备对话)。

.WebNFC (NFC 是一种短距离的点对点式的交互技术,这里是其在 Web 上的应用技术)也被开发了出来,很明显这些新奇的技术正在掀开物联网的面纱(但是这完全是另一篇发表的博客的内容)。

在 Android 上的 Chrome 的地址栏里输入 chrome://flags,然后看看上面现在在准备开发的东西。那上面的东西太令人吃惊了!

不管怎样,在过去的几年里, ServiceWorker 技术和 Progressive Web App 的概念构建起了一种特色,这种特色使我比以前我使用过的任何 web 技术更让我开心,而且这种开心的心情会持续很久很久。

ServiceWorker 介绍链接: http://html5online.com.cn/articles/2015051201.html

Progressive Web App 介绍链接: http://blog.csdn.net/ejinxian/article/details/50082889

我相信在 Android 里引入 ServiceWorker 技术和 Progressive Web app 技术是自从苹果公司 CEO 乔布斯首次把 iPhone 手机介绍给用户以来在移动 web 平台上发生的最重要的事情。

为什么这样说呢?!因为,这是第一次我们拥有一个有着庞大用户基础的移动平台,这个平台让我构建的每一个 web app 被当做了一等公民看待!

(注意:是的,我知道还有其他的平台试图这样做的,但是它们中没有一个是有着 14 亿活跃用户的。)

这些新技术最终给了我们开发者一个平台,在这个平台上每一个 web app 都是一等公民!

而且需要说清楚的是,我不仅仅是在谈论一种将一个美化的标记贴到主屏上的方法!

我正在谈论的是能使我们构建的 web app 与原生的 app 别无二致的方法。

这些各种类型的 app 所遵循的唯一条款是”Progressive Web App”条款。

事实上,我认为 Progressive Web App (简称 PWA)实际上对原生 app 有着巨大的帮助,因为你可以立即开始使用它们。你不需要登录电脑搜索界面,然后由搜索界面跳转到一个 app 商店,再然后等上一两分钟直到一些庞大的二进制包被下载下来。它们就是 web app,它们有 URL,它们可以被构建加载的超快。因为……我们已经在 web 上优化加载时间的性能很长时间了。

用户仅仅需要很少的磨合时间就可以开始使用它们。而用户需要考虑的是它们如何来处理你的转换数据!

由于在 Android 行业中经验的增加,我敢肯定企业针对他们的 Android 用户有着这样强烈的疑问:他们有必要构建原生 Android app 吗?

那么到底什么是 Progressive Web App 呢?

出于某种原因 Google 公司已经在设法教一代的开发者什么是 Polymer 框架和 Angular 框架。不幸的是,现今我遇到的和交谈的绝大部分 web 开发者对什么是 ServiceWorkers 或者什么是 Progressive Web App

还是零的概念。

Polymer 框架简介链接: http://www.linuxidc.com/wap.aspx?nid=102184&cid=10&sp=1348

Angular 框架简介链接: http://www.jb51.net/article/60494.htm

一些人产生上面问题的原因是因为 Progressive Web App 完全是崭新的东西,而最近产生上面问题的人数在减少,情况得到了改善……上帝啊……我希望这种改变。

你可以这样想象一个 progressive web app:

它是用 HTML,CSS 和 JS 脚本编写的一个 app,而且它完全可以被当成一个原生的 app.

这包括:

1. 在手机主屏上运行。

2. 在 Android 的 app 切换器上作为一个单独的 app (不是作为浏览器 App 的一部分)运行。

3. 正真的离线行为…这意味着当你用手指点击 app 图标时……不管它是否是在当前网络状态它都会打开。

4. 即使当 app 和浏览器关闭时,它仍然能在后台运行并触发操作系统级的消息通知。

这些 app 作为一个标签开始生存和运行在你的浏览器里,而不是作为一个无用的网页上面写着”请按照我们的 app”标语开始的。然后渐渐地它们会被更多的安装直到最终成为操作系统的一部分。

起初,它和你访问的其他网站没有什么不同。但是,然后你如果在你的浏览器里再次访问同一个站点或者 app,你的浏览器会巧妙地问用户是否愿意把它添加到他们的桌面。

从这一刻开始它对用户来说就变得与原生 app 一样了。

并且,如果你正确的构建它们,通常用户根本不需要下载它们或者浪费时间等待下载。这也就意味着把它添加到主屏幕上,app 会立即生效,这中间的安装过程会很短。另外,设想一下它会为你的转换做些什么?是吗?(不,我不是加拿大人)(大概加拿大人精于计算).

幸运的是,我们不必去完全猜测它们的商业影响。我们实际上从印度一家名叫 FlipKart 价值 200 亿美元的在线零售商那里获得了一些真实的数据,这家在线零售商上线了一个 PWA 并且他们共享了他们的一些数据。

从 FlipKart 的数据中筛选出的关键重点:

  • 40% 的回头客户周而复始的访问他们的在线零售网站。
  • 63% 的转换是来自用户的主屏访问。
  • 用户在 FlipKart Lite (移动端)上花费 3 倍的时间。

这些数据来自 Alex Russel 最近就手机的下一步是什么的主题发表的流利演讲。我支持你去看看并且在你所在的公司里把它和你的产品经理和你的领导分享分享。那很好解释了什么是 Progressive WebApp 和为什么选择 Progressive Web App.

相关阅读查看:

那么这对我们意味着什么呢?

那意味着我们作为 web 开发者最终能构建快速流畅的完全可以离线的并且用户隐私可以得到保护的 app,而且 app 可以在交叉平台上运行而不用向苹果公司缴纳任何该死地 App Store 税收,不再需要等待审批过程,用户不再会伴随着”在使用这项服务之前请安装我的 app”的声音而被拒之门外。

那么关于 IOS 的支持呢?

很好,它妙就妙在即使 service worker 在 IOS 上的支持不存在,IOS 用户仍然可以使用你的 web app.

他们只是没有获得额外的功能,比如离线功能和推送消息功能。

但是你也可以把 Cordova 捆绑进你的 app 而且还可以使用 Service Worker 插件,理论上这将使你用同样的代码去做这些事情,但是它们捆绑到一起后就可以看做是一个 IOS app 了。

Cordova 介绍链接: http://www.cnblogs.com/luoguoqiang1985/p/3574738.html

我为什么要关注?React Native 现在出现了并且可以用来解决同样的问题。

React Native 介绍链接: http://blog.csdn.net/u011068702/article/details/49431211

就我个人而言,我实际上有些希望像 React Native 的工具不存在的。耐心些听我解释。React Native 是一个令人既吃惊又印象深刻的工具,它使我们可以使用我们的 JS 编程技巧来编写原生的 IOSapp.

但是就像我一直所说的……我不认为我们应该构建原生的 app,除非我们完全需要这么做。

React Native 产生的最终结果是因为它的存在和因为它主要针对的是 web 开发者,我们现在有 web 开发者涌向开发原生 app,因为有了这个框架他们有能力开发原生 app 了!

我怕这种变化在无形中破坏我们使用我们集体讨价还价的力量来促使苹果公司实现在 IOS 中对 Progressive Web App 支持的能力。

需要澄清的是,我完全理解它为什么会被创建出来,而且我也非常的尊重它所代表的技术成就和尊重它背后的开发商。

我仅仅是不想让我们停止去促使苹果公司改善在 IOS 中对 web 的支持。

总结

因此,这也就是说,作为一个消费者这些事情最终让我能用的唯一投票权是……我掏出兜里的钱然后离开。

我不认为这是我转变到 Android 平台弄开发工作,我只是切换到当今可用的移动 web app 平台中最好的那个。

Web 是我们所能获得的唯一真正开放的平台。它是最接近我们需要的公平竞争环境。

这就是为什么我集中我所有的努力来构建 Progressive Web App…….我希望你们也做同样的事情。

在 twitter 上我的名字是@HenrikJoreteg,如果你想很好地告诉我我做错的地方的话可以联系我。

-

译文链接:http://www.codeceo.com/article/why-giveup-ios-choose-android.html

翻译作者:码农网 – 唐李川

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: