Native | Hybrid | Web App選型及演進方案

Native | Hybrid | Web App選型及演進方案

目錄

  • App形態javascript

    • Web Appphp

    • Native Apphtml

    • Hybrid App前端

  • Web App模型方案和應用 (待完成)html5

    • SPA (Single Page Application) 單頁應用java

    • PWA (Progressive Web App) 漸進加強Web應用react

    • 模塊化單頁應用android

  • Hybrid App模型和實現原理ios

    • 現有的Hybrid形態git

    • Hybrid的實現原理

    • Codova實踐方案

    • React Native 實踐方案

  • Native App (待完成)

    • Native組件化&容器化

    • Native的粒度、切面和Business層的抽取

  • App的選型方案和演進路線

    • 各類不一樣類型App選型方案

    • 升級:ABTesting (待完成)

    • 升級:用戶事件收集 - 無埋點 vs 埋點方案 (待完成)

  • EJU Router方案(待完成)

App形態

Web App

DEFINITION 定義

A web application or web app is any software that runs in a web browser. It is created in a browser-supported programming language (such as the combination of JavaScript, HTML and CSS) and relies on a web browser to render the application.
Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions. --wiki

在瀏覽器端構建的基於HTML/CSS/JS進行開發,使用瀏覽器進行渲染的應用程序。

其特色體如今幾個方面

  1. update and maintain web applications without distributing and installing software 升級和維護不須要分發和安裝

  2. the inherent support for cross-platform compatibility 良好的跨平臺性

STORY 小故事 閱讀 視頻

The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps. And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today. --Steve Jobs

Jobs實際上是最先的web app的倡導者之一,在當時的構想中是沒有native app這種形式的,全部的app都是以web的形式存在的,可是當時的Jobs須要面對3個問題

  1. 移動網絡根本無力承擔這種變革

  2. 如何使webapp讓Apple盈利

  3. webapp運行的體驗很是糟糕

而基於此的討論和考慮才逐步衍生出後來的Native App和`App Store

Chromium OS vs Firefox OS

頗有意思的一件事情是,不少年以後。有兩家公司實現了Jobs當年沒有實現的夢想,分別推出了基於瀏覽器操做系統的PC和手機。

基於Chromium OS的Google Chrome Book 官網 視頻

ChromeBook的推出,才逐漸讓市場上開始產生真正的Web App。至今咱們可以看到的不少出色產品,都是以此爲開端或者以此爲契機,其中很著名的有:trello | slack

基於FireFox OS移動端手機,不過很不幸2015年Q3開始,Mozilla宣佈中止對Firefox OS的開發,就如不少方興未艾的手機系統同樣,它還沒怎麼被認識,就壽終正寢了。視頻

CASE STUDY 案例

Native App

DIFINITION 定義

Apps are usually available through application distribution platforms, which began appearing in 2008 and are typically operated by the owner of the mobile operating system, such as the Apple App Store, Google Play, Windows Phone Store, and BlackBerry App World. Some apps are free, while others must be bought. Usually, they are downloaded from the platform to a target device, such as an iPhone, BlackBerry, Android phone or Windows Phone, but sometimes they can be downloaded to laptops or desktop computers. For apps with a price, generally a percentage, 20-30%, goes to the distribution provider (such as iTunes), and the rest goes to the producer of the app.[1] The same app can therefore cost the average Smartphone user a different price depending on whether they use iPhone, Android, or BlackBerry 10 devices. --wiki

基於手機操做系統的應用程序,使用其原生程序進行構建

其特色體如今幾個方面

  1. operated by the owner of the mobile operating system 在對應操做系統平臺進行應用程序的開發

  2. available through application distribution platforms 須要分發應用(下載)的市場 — 賣錢

CASE STUDY 案例

HYBRID APP

DEFINITION 定義

A hybrid mobile application (or hybrid mobile app) is a mobile application that runs inside of a native container and leverages the device’s web browser to display locally hosted HTML pages.[29] Hybrid mobile apps are composed mostly of HTML, JavaScript, and CSS. Device specific functionalities such as camera access, geolocation, and accelerometer readings are exposed through a JavaScript API. --wiki

其特色體如今幾個方面

  • runs inside of a native container 運行在原生的容器內

  • Device specific functionalities are exposed through a JavaScript API 經過JS API暴露底層的功能接口

優缺點

Pros

  • Hybrid mobile apps allow code reuse across platforms. Let the library or framework you are using take care of the platform specific differences and use the same JavaScript code on both platforms. 跨平臺的代碼複用 - 在不一樣的平臺使用相同的Javascript代碼

  • JavaScript is something that many developers are already familiar with where something like the iOS development tools are more specialized. It can be argued that there is less of a learning curve when developing hybrid mobile apps compared to native apps. Javascript使用的通用性解決了iOS開發者的專用屬性,開發hybrid mobile的學習曲線更簡單。

  • The app's interface and logic can be built and debugged in the web browser using an emulation framework. This could lower development costs depending on the tools required to develop native apps for the target platforms. app的ui和邏輯均可以在瀏覽器中構建和debug,減小在目標平臺上的花費。

  • The HTML5 application development with CSS3 gives the compelling structure to the interface of game app and this ensures pleasing user-interface. 使用CSS3讓用戶界面和遊戲開發更加生動。

Cons

  • Hybrid mobile apps are more susceptible to user interface lag due to the extra layers of abstraction.[29]
    Only a certain subset of native functionality is available which depends on the framework. All others native functions are accessible developing Plugins. 大部分native層的功能都須要經過plugin的方式進行調用。

  • As for native apps, the hybrid code base requires recompilation and resubmission to the distribution network where it is possible to instantly update a mobile web app’s codebase. 相對於web app來講,hybird需用從新編譯和分發才能完成更新

  • HTML5 in mobile devices H5在Web容器裏的兼容性問題

CASE STUDY 案例

選擇

WEB APP, HYBRID APP & NATIVE APP 選擇哪一種形態?

codeWEB APP/code, codeHYBRID APP/code & codeNATIVE APP/code 選擇哪一種形態?

決定哪一種模式以前須要問本身這些問題:

  1. App的體驗和開發週期何者爲先?

  2. APP的更新週期是否頻繁?

  3. 開發資源

  4. 應用平臺

Hybrid App模型和實現原理

現有的Hybrid形態

NativeWeb之間構建一層Bridge, 將底層的接口映射到JS API

  1. View的渲染依賴於瀏覽器自身的渲染引擎,即便遊戲也不須要去寫openGL

  2. Bridge在不一樣的平臺經過不一樣的native層實現,在各自平臺下完成編譯

  3. Business能夠實如今Web也能夠實如今Native

  4. Plugin構成了Bridge的擴展

現有平臺

案例

使用JS編寫通用的業務邏輯,使用Nodejs編譯不一樣平臺的Native app 視頻

  1. View經過Ti.UI進行調用Native實現,在不一樣的操做系統中調用不一樣的Native UI實現。Ti.UI能夠定義部分Native UI

  2. Business經過JS編寫最後編譯成Native代碼

  3. BridgeBuild工具進行了整合,理論上能夠跨全部平臺

現有平臺

  • Titanium

  • 在我寫這篇文章第一稿的時候,Facebook發佈了React Native,從Coding的思想上RN不同

案例

Hybrid App實現原理

Titanium嚴格來講不屬於Hybrid,由於其最終產生的仍然是Native App,過於牛B,不在本文知識範圍內。本文限於討論相似CordovaHybrid實現。

Native調用JS

  1. native經過string調用js

  2. webview調用js解釋器的eval方法將string轉化爲js方法

  3. webview調用js方法

JS調用Native

  1. javascript改變url,經過url傳遞調用的方法和參數

  2. webview監聽到了URL變化,而且探測到url中定義的方法和參數

  3. 尋找對應的映射表,找到native對應接口api進行調用

  4. 執行javascript調用方法時傳入的回調string並添加數據

  5. webview解析string轉化爲javascript進行調用

URL Schemes

爲了區別普通的http訪問的urlhybrid調用nativeurl,參考openurl的標準apple提出了url schema的方法

系統自定義了能夠被識別的協議和url,例如

  • mailto:frank@wwdcdemo.example.com

  • tel:1-408-555-5555

  • sms:1-408-555-1212

app自身能夠自定義url schema,而且把自定義的url註冊在調度中心, 例如

  • ctrip://wireless 打開攜程App

  • weixin:// 打開微信

閱讀

早期的Android採用了JavascriptInterface,可是這種方案存在注入的安全隱患,因此在Android 4.0以上的版本開始就支持了URL Schema方案。

閱讀

閱讀

Hybrid URL Schema在實現中的問題

  1. 存在短期內高併發的問題,例如:一次定位沒有完成期間,反覆調用定位

  2. 執行http的url訪問尚未返回就調用了新url schema,致使了前一次行爲沒有生效

  3. 在ios中native調用js是實時的,在Android中native調用js是異步的,在異步調用中出現alert這種阻塞進程的會直接crash app

關於這裏的實踐,須要讀Cordova的JS Bridge

Cordova實踐方案

Cordova誕生於PhoneGap,早起的PhoneGap是一個開源平臺,全部的代碼、編譯均可以使用PhoneGap平臺完成。在被Adobe收購Nitobi,同時把PhoneGap其中的核心層代碼進行了開源,新版本後的PhoneGap進入商業化。因此如今在PhoneGap平臺上若是是用它的編譯,須要付費。

但有了Cordova,咱們就能夠造一個新的PhoneGap~~不是嗎,因此有了Ionic

Cordova架構:

就如咱們前面說的,Cordova的方案就是放一個WebView全部的UI都是經過WebView進行呈現,經過JS Bridge調取Native方法。Cordova將JS Bridge作成了一種插件式的方式,便於擴展。

全部採用Cordova方案或者相似以WebView做爲呈現的Hybrid方案,在Android上遇到一個最大的問題,就是不一樣ROM中WebView的兼容性問題

以前華爲系統的webview內核有問題,只要有js交互,佔用內存無限上升;某次測試達到恐怖的380M,簡直嚇尿;因爲是webkit內核問題,無能爲力;咱們只能檢測到是華爲系統的這個特定版本的時候談個Toast,告訴用戶不要在頁面逗留太長時間。。(如今這個bug已經修復了,當時系統版本:NXT-TL00C 01B1 29SP02)— 知乎用戶

怎麼辦?! Crosswalk。這段視頻須要看一下視頻

下一個問題:若是用Crosswalk包太大怎麼破?用Crosswalk Lite或者只用Arm的包

React Native 實踐方案

就如前面的Titanium,RN裏面Javascript是用來寫業務的,UI是交給Native的,全部若是有不少的自定義View的話,其實開發量也不小~

React-Native系列Android——自定義View組件開發

我說RN和Titanium不同,爲何?由於CodePush,CodePush是Microsoft推出的React Native的熱部署方案。簡單來講就是業務層都使用JS來寫,把JS打包成Bundle,而後把Bundle文件下發下去。那麼不一樣在什麼地方?

Titanium是須要徹底編譯的,最終是否是把JS代碼都轉成了Java或者C的代碼不瞭解,可是有很大可能。像C和Java須要完整的編譯,在Runtime的時候打開去注入,實際上是很難的。可是RN把業務層抽到Bundle,這是一種Meta Programming的思想,這就意味着,隨着發展將來你只要推js代碼上去,RN就能夠完成更新。

蘋果向熱更新下達最後通牒,是什麼致使了此次事件?

App的選型方案和演進路線

各類不一樣類型App選型方案

兩個問題:

  • Native | Hybrid | Web 他們之間是否是非此即彼的關係?

  • 若是一個App初期選擇一個Native | Hybrid | Web中的一個,是否是意味着只能一條路走到黑?若是中間想加或者想轉其餘的形態須要多大的努力?

因此要回答這個問題,我先來講一個我過去作的案例

最先咱們在作豐趣海淘的時候,咱們大量的人力和時間都投入在PC站點、移動站點和後臺的搭建中,咱們還在嘗試其餘的商業模型,因此沒有人力投入在App的開發中。有一天下午,我和咱們大前端的負責人討論了一下以後,決定出一個App,放App Store和Google Play,而後大概2天左右時間,我把當時作的移動端站點扔進去,發佈了當時咱們第一個版本~~

上線以後,發現了一個讓人驚喜的數據:周復購xx%~~當時老闆大手一揮,作移動端。到今天,xx%以上的購買都從移動端來,歷時一年半。

因此咱們當時初期的架構就是純粹的Web,而後咱們就開始了演進。這個要說到咱們當時的前端架構,咱們用了CanJS,可是沒有作純粹的單頁應用。咱們作了模塊化的單頁應用,簡單的說,首頁我認爲它是一個模塊,我爲他單獨作一個單頁應用。全部單頁應用有個切面層,作服務端的簽名、csrftoken的處理等等。

而後咱們開始作原生化,爲何要作原生化,由於要讓用戶體驗有大的提供、由於要作用戶心智

因此基於一個個模塊,開始作,咱們原則是:

  • 下單主流程原生化,讓用戶最快速度的付錢

  • 產品化比較好的模塊先原生化

  • 常常變化而且變化很是大的模塊,不作原生化 - 用hybrid的方案走

Hybrid最開始咱們採用了Cordova的架構,可是後來放棄了,Cordova過重了,不必,咱們本身寫了JS Bridge經過URL Scheme的方式進行調用,封裝了調用堆棧,同時引入了Crosswalk解決華爲機的兼容性問題。

因此咱們總結一些通常的演進流程:

按照不一樣的App分類,作個簡單的建議

  • 電商類:70% Native + 10% Web + 20% Hybrid

  • 工具類:80% Native + 20% Hybrid

  • 社交類:50% Native + 20% Web + 30% Hybrid

  • 遊戲類:95% Native + 5% Web

EJU Router方案

router-android

router-iOS

相關文章
相關標籤/搜索