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方案(待完成)
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進行開發,使用瀏覽器進行渲染的應用程序。
其特色體如今幾個方面
update and maintain web applications without distributing and installing software 升級和維護不須要分發和安裝
the inherent support for cross-platform compatibility 良好的跨平臺性
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個問題
移動網絡根本無力承擔這種變革
如何使webapp讓Apple盈利
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 案例
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
基於手機操做系統的應用程序,使用其原生程序進行構建
其特色體如今幾個方面
operated by the owner of the mobile operating system 在對應操做系統平臺進行應用程序的開發
available through application distribution platforms 須要分發應用(下載)的市場 — 賣錢
CASE STUDY 案例
部落戰爭 在遊戲中大量採用OpenGL ES對於效果的開發很是有幫助,而WebGL的演進漫長
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 案例
街旁國內最先的Hybrid
模式的倡導者
WEB APP
, HYBRID APP
& NATIVE APP
選擇哪一種形態?
決定哪一種模式以前須要問本身這些問題:
App
的體驗和開發週期何者爲先?
APP
的更新週期是否頻繁?
開發資源
應用平臺
在Native
與Web
之間構建一層Bridge
, 將底層的接口映射到JS API
上
View
的渲染依賴於瀏覽器自身的渲染引擎,即便遊戲也不須要去寫openGL
Bridge
在不一樣的平臺經過不一樣的native
層實現,在各自平臺下完成編譯
Business
能夠實如今Web
也能夠實如今Native
Plugin
構成了Bridge
的擴展
現有平臺
案例
使用JS
編寫通用的業務邏輯,使用Nodejs編譯不一樣平臺的Native app
視頻
View
經過Ti.UI
進行調用Native
實現,在不一樣的操做系統中調用不一樣的Native UI
實現。Ti.UI
能夠定義部分Native UI
Business
經過JS
編寫最後編譯成Native
代碼
Bridge
和Build
工具進行了整合,理論上能夠跨全部平臺
現有平臺
在我寫這篇文章第一稿的時候,Facebook發佈了React Native,從Coding的思想上RN不同
案例
Titanium
嚴格來講不屬於Hybrid
,由於其最終產生的仍然是Native App
,過於牛B,不在本文知識範圍內。本文限於討論相似Cordova
的Hybrid
實現。
Native調用JS
native經過string調用js
webview調用js解釋器的eval方法將string轉化爲js方法
webview調用js方法
JS調用Native
javascript改變url,經過url傳遞調用的方法和參數
webview監聽到了URL變化,而且探測到url中定義的方法和參數
尋找對應的映射表,找到native對應接口api進行調用
執行javascript調用方法時傳入的回調string並添加數據
webview解析string轉化爲javascript進行調用
URL Schemes
爲了區別普通的http
訪問的url
與hybrid
調用native
的url
,參考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在實現中的問題
存在短期內高併發的問題,例如:一次定位沒有完成期間,反覆調用定位
執行http的url訪問尚未返回就調用了新url schema,致使了前一次行爲沒有生效
在ios中native調用js是實時的,在Android中native調用js是異步的,在異步調用中出現alert這種阻塞進程的會直接crash app
關於這裏的實踐,須要讀Cordova的JS Bridge
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 Lite或者只用Arm的包
就如前面的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就能夠完成更新。
兩個問題:
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