七年iOS工作經驗的我為什麼放棄了iOS而選擇了Android

本文由碼農網 – 唐李川原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

上週一我非常開心。因為我被允許為一個曾經工作過的客戶開始開發一個新的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,如果你想很好地告訴我我做錯的地方的話可以聯絡我。