App開發的新趨勢

移動開發這些年，移動開發者人數愈來愈多，相似的培訓公司發展也很快，不過伴隨着的是移動應用的需求這幾年發展更爲旺盛。要開發好的App，純原生開發確定是最佳選擇。可是這麼多年發展，原生開發的難度並無下降多少，特別是做爲一個須要長期運營的App，須要原生人員的長期跟進，人員成本很高。另外，從蘋果和Android的崛起開始，爲了支持大相徑庭的二個操做系統，至關於二套開發人員開發二個功能徹底的App，可想開發效率的低下。

一直以來，程序員對移動跨平臺的追求就沒有中止努力，跨平臺是爲了提升開發效率，隨着帶來的必然是性能的下降。但從軟件發展的歷史看，部分損失某一方面的性能來換取效率的提升仍是很是值得的。
就好像咱們用c語言替代彙編，損失了掉的那些運行效率基本是能夠忽略不計的，咱們換來的是開發效率大幅提升，相對於彙編語言而言C語言同時也部分解決了跨平臺跨設備的問題（至少不用再考慮對特定寄存器的編程了）。
一樣當歷史發展到大量用Java替代C語言開發的時候，咱們損失掉了c語言的Native設備的開發能力的同時，所換來的多線程開發、分佈式開發、跨平臺開發能力的加強，也徹底符合www時代發展的須要的。

自然的，移動開發的程序員首先想到的H5和Webview，這是最容易實現的跨平臺方案。在H5的路上移動開發者們作了不少努力。純原生開發咱們暫時不提，光從跨平臺來講，發展的歷程能夠大概分3個階段：

1. 純H5方式

因爲web應用已經在PC應用上佔了半壁江山，最先的時候你們想着直接使用手機的系統瀏覽器加載一個網址，這最容易實現，顯然問題不少，性能就不提了，其它方面，好比不一樣的瀏覽器適配很難，瀏覽器的安全性限制了大部分手機上的設備沒法使用，存儲本地都受限制。可是這種方式並無消亡，它有必定的適應範圍。特別是隨着微信的崛起，這種方式已經應用很廣了，微信承載了一個統一跨平臺的瀏覽器功能，並且能調用很多原生功能。不少想長期運營的App都會有微信的入口，並且一般是先作微信推廣，再作App。

以上的方式還有一個明顯的缺陷就是應用的差別性，桌面上沒有App的圖標，你們都從瀏覽器或微信入口，對於一個長期運營的想有必定知名度的應用來講確定沒法接受。
接下來移動開發者的想法就是用一個有本身圖標和入口的原生的App的殼加載一個原生的Webview組件，而後加載網頁，同時經過js和原生的橋接技術來實現html和原生功能的調用。這種技術的表明是phonegap技術，它影響了國內不少移動開發者和公司，有很多框架和技術都是基於或學習它。在它被更名以前，咱們也完整下載和研究過它的代碼。
這個時期的應用特色是：
＊ 整個核心就一個webview，裏面頁面的切換都是本地網頁或web網頁的跳轉
＊ 沒有任何原生ui的參與，全部ui都是靠webview的標籤。有一些簡單原生ui能夠以窗口的方式調用起來。
＊ 整個應用的邏輯都是靠html裏的js來驅動。
＊ 能調用原生的一些基礎功能，好比攝像頭，存儲，數據庫等等。

這種方式起初仍是有必定市場的，主要是開發效率很是高，不少已有的PC端的網站改吧改吧就出來一個跨Andoid和iOS的應用。可是這樣的應用只能說勉強能用，稍微複雜一點就連用都不能用了。性能和體驗問題是最主要的，更況且早期Android 2.x時代，iOS4.x，5.x時代手機的性能也不高。

2．H5和Native的混合 （Hybrid）
手機的性能愈來愈好，H5也愈來愈流暢，可是隨之而來的是好的原生App愈來愈多，H5在不少方面仍是沒法替代原生。因而愈來愈多的原生功能和H5混合在一塊兒，造成了Hybrid開發的模式。
這裏我要說跨平臺的發展分了二種思路或二個方向：
＊ 原生爲主，更多的加入H5的元素，咱們暫且稱之爲Native/H5
＊ H5爲主，更多的加入Native的元素, 咱們暫且稱之爲H5/Native

首先咱們看Native/H5，這種應用不少，並且是現有市場上的主流，特別是大型的優秀的之內容爲主的App，表明是微信，天貓，京東這些App。裏面都大量使用Webview加載大量網頁。由於原生的更新很麻煩，而那些須要大量內容更新的App必然會選擇Webview做爲內容承載。很顯然，這種方式並無下降多少成本，原生人員仍是須要二套，內容頁面還須要一套熟悉web技術等人員。

咱們再看H5/Native，國內的表明應該是Appcan，APICloud，wex5等移動開發平臺。這些框架的最先期就是我上面提到的純H5方式，慢慢加上更多的原生因素，好比一個webview改爲多個webview，頁面上加入很多原生的ui元素，好比頁面的titlebar使用原生的ui，還有不少，他們一直在努力解決體驗和性能的問題。也有不少App產出了。國外也有不少框架，很多是經過html實現一套和原生樣子很像的ui組件。可是相比Native/H5, 我以爲H5/Native的發展思路不對。
咱們來看看它們的區別，咱們先來看二個App的截圖：

我使用了Android的開發者模式，能夠看到原生UI組件的邊框。咱們能夠看到他們的差異
＊ 天貓App的主要／主體頁面是純原生的頁面，頁面上全部大大小小的元素都是原生的UI組件。而下面的截圖主體部分都是Webview組件，可是加入一些原生UI。
Native/H5的App全部核心的主要的界面都是純原生，就像一棵樹同樣，一般只有到末端的內容頁面是網頁。頁面的跳轉都是原生效果。H5/Native主要的框架界面也是Webview加載Html，很顯然，體驗上和性能上來講H5/Native要差不少。

＊ Native/H5的主要邏輯都是靠原生來驅動。H5只是負責簡單的頁面展現和不多的邏輯處理。H5/Native全部的邏輯處理都是靠Webview裏的html裏的js來處理。這一塊，性能相比又差了不少。另外複雜度上高了不少，webview只是原生衆多組件中的一個，由它來支撐和控制整個App基本上很難，不少開發中的坑沒法解決。

＊ 從成本上來講，Native/H5只是稍微下降了一點成本，由於仍是須要多套人馬。H5/Native的成本就下降了不少了，由於只須要一套web開發人員。

3.JS/Lua和Native的混合

從上面咱們能夠看到Native/H5 和H5/Native 中間咱們還須要再努力努力再尋求一箇中間狀態，就是儘量的不犧牲性能的基礎上再下降效率和成本。這幾年證實經過webview和H5的方式已經沒法再優化了。

從Facebook的React Native開始，一種新的趨勢已經逐漸冒出來，他們的思路是從Native/H5爲源頭，可是拋棄webview，保留js。Facebook本身至關於從新設計了一套相似H5的規範，並設計相似一個webview的組件來解析這套規範，包括ui和js代碼。可是這裏的標籤對應的都是可擴展的純原生的組件。
包括國內的阿里推出的weex和LuaViewSDK，思想上和React Native相似的。

他們的思路就是從原生開發人員的角度出發，儘可能擴大跨平臺的範圍，可是又不帶來體驗的降低。這種趨勢應該是正確的發展方向。

不過這幾個技術如今都是一個SDK，也就是並不能實現真正的跨平臺，作不到一套開發人員，一套代碼就能發佈多個平臺。就像React Native的口號是Learn Once，Write Anyway。

我要重點介紹一下國內一個移動開發平臺Deviceone。Deviceone的發展走過我上面提過的全部階段，它經歷是差很少4年，在內部已經有5個大版本的迭代了。整體來講，也是長期追求效率和性能的最優化的一個結果。

Deviceone的特色是：
 deviceone有一個核心框架，能夠理解爲相似React Native同樣的SDK，能夠解析自定義的ui標籤和js／lua 代碼的功能。差異就是，deviceone定義的ui並非相似h5，而是把ui代碼和js/lua代碼徹底分開成不一樣的文件。Ui文件經過IDE的拖拽功能來實現，而後經過屬性設置的方式，固然也支持js/lua代碼訪問。咱們直觀的看看IDE裏可視化ui的圖。

 deviceone並不僅是一個能實現跨平臺的原生SDK，在這個框架的基礎上，deviceone對android，ios，windows的移動基礎框架作了抽象，包括移動系統基礎元素Activity，UIViewCotroller之類的，也標準化了事件機制，存儲管理，綁定機制，同步異步等等基礎結構。目標就是App開發者無需瞭解Android，iOS技術的細節，用一套代碼實現真正的跨平臺，write once，run anyway。

 deviceone並無脫離原生開發，只不過把原生開發和App開發者分離了，原生開發者只負責開發和業務無關的組件，好比Button，VideoView之類的。而App開發者不須要理解操做系統的差別，只須要參考組件的一套JS／Lua的API，而後專心整理本身App的業務需求，就能搭建出跨平臺的App。

 deviceone最大的價值就是提供了一套組件重用的規範和標準，並且是跨平臺的組件。咱們日常用原生開發不少都是最基礎的代碼重用，組件重用也僅限於單個平臺。而deviceone的組件商店已經積累了快100個跨平臺的原生組件了，是由deviceone官方和一些我的原生開發者開發的，有不少都開源了，你們能夠參考。目前正在以收費組件的方式吸引更多原生開發者參與。

 deviceone在現有的不少第三方組件基礎上由實現了跨平臺的封裝。大量的第三方平臺提供了優質的服務，一般原生開發人員只須要集成android和ios都sdk就可使用，大大簡化了開發人員的。咱們在這個基礎上又簡化了一步，一套js的sdk就可使用。咱們已經集成了不少經常使用的好比百度地圖，極光推送，幾個經常使用的支付，分享等等。

 deviceone提供了強大的可配置組件雲打包系統，開發者能夠在100個組件裏勾選本身須要的組件，而後打包成調試App和發佈App。另外提供了不少配置項，儘可能簡化開發者的工做。

 deviceone對外正式發佈半年多，已經積累了不少企業應用，最近幾個月逐漸開始積累很多我的應用，感興趣的能夠去蘋果的商店和android的市場上搜索一下「慧影時間流」，「納豆－點餐」，「愛搶劵」，「易經造命」體驗一下。這一個月應該又有很多上線應用，請多關注。

介紹了很多，感興趣能夠去多關注國內這個優秀的產品，我相信很多移動開發者被國內各類框架的「折磨」失去了對國內移動開發平臺的信心，可是這個平臺值得你花一點時間去研究和體驗。