您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
七年iOS工作经验的我为什么放弃了iOS而选择了Android
 
翻译作者:唐李川 来自于:码农网 发布于 2016-10-14
  1436  次浏览      17
 

上周一我非常开心。因为我被允许为一个曾经工作过的客户开始开发一个新的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 SDK和App 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.

相关阅读查看:

Addy Osmani的Progressive Web App入门指南

在ServiceWorkers网页上有Mozilla的service worker实例

FlipKart发布的关于他们PWA的最初的技术

Jake Archibald的Offline Cookbook

Aditya Punjabi发布的关于他们是如何构建FlipKart lite移动端的文章

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

那意味着我们作为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,如果你想很好地告诉我我做错的地方的话可以联系我

   
1436 次浏览       17
 
相关文章

手机软件测试用例设计实践
手机客户端UI测试分析
iPhone消息推送机制实现与探讨
Android手机开发(一)
 
相关文档

Android_UI官方设计教程
手机开发平台介绍
android拍照及上传功能
Android讲义智能手机开发
相关课程

Android高级移动应用程序
Android系统开发
Android应用开发
手机软件测试
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]

android人机界面指南
Android手机开发(一)
Android手机开发(二)
Android手机开发(三)
Android手机开发(四)
iPhone消息推送机制实现探讨
手机软件测试用例设计实践
手机客户端UI测试分析
手机软件自动化测试研究报告
更多...   

Android高级移动应用程序
Android应用开发
Android系统开发
手机软件测试
嵌入式软件测试
Android软、硬、云整合

领先IT公司 android开发平台最佳实践
北京 Android开发技术进阶
某新能源领域企业 Android开发技术
某航天公司 Android、IOS应用软件开发
阿尔卡特 Linux内核驱动
艾默生 嵌入式软件架构设计
西门子 嵌入式架构设计
更多...