460      阿裏雲  技術社區[雲棲]

鳥巢如何更簡單更快的開發Native App

導讀：Native向左，HTML5向右，兩者都是為了解決移動應用的問題，各有優勢劣勢。為結合HTML5開發便利動態性強和Native體驗佳性能優的特點，讓未來趨勢和現實要求結合，鳥巢（Birdnest Native），一種全新的Native APP開發模式，應運而生。

背景：通過下麵這段文字向大家介紹一下鳥巢，以及簡單分析鳥巢的優勢和劣勢，鳥巢的適用場景和解答對鳥巢的疑問。歡迎大家參與討論。先通過一段簡單的視頻演示鳥巢的實現效果：

什麼是鳥巢

鳥巢（Birdnest native），一種通過前端技術擴展Native動態能力的解決方案。運用HTML5+CSS+JavaScript這些前端技術隻是為了降低接入門檻。鳥巢為Native APP，提供的是一套從前端到後端的整體方案。技術目標是：
1.將Native頁麵開發難度簡化為前端HTML5頁麵開發；
2.提供媲美傳統Native的用戶體驗；
3.將業務複雜度放在服務端，可以通過動態推送實現業務功能更新。

 +  +  -> 
圖1、運用前端技術進行鳥巢Native APP開發

有了鳥巢，開發Native APP頁麵和開發一個HTML5頁麵一樣簡單：

圖2、鳥巢頁麵代碼和Native效果

鳥巢的特點

動態能力是鳥巢的初衷，鳥巢打造了從前端到後端的整體動態能力輸出方案，形成了一個閉環，這是它最重要的特點。采用這種設計是為了，降低接入門檻，降低學習成本。

鳥巢參數

從支持平台（Android、iOS、Web），語言靈活度（私有 or 標準協議），布局方式能力（自定義 or CSS Layout）、擴展性（自定義 or Bridge+Native Module）和動態能力（自定義 or 純客戶端方案 or 客戶端服務端整體方案）五個角度分析方案的優缺點。每個角度分成3級，由內到外代表能力的從低到高。

鳥巢對比

圖3、業內方案對比

從實際情況看來，鳥巢無論是在係統支撐上（iOS5+支持，Android同步支持），入門門檻上（了解HTML5即可上手），還是整體配套上（客戶端服務端整體解決方案）都超出了其他幾種方案。鳥巢的整體解決方案，使應用方可以專注於UI開發，而無需考慮動態更新相關的客戶端和服務端改造。

鳥巢的產生

鳥巢的demo版有用過自定義協議，在經曆了私有協議的反複折磨後，最終果斷放棄。轉而選擇采用業界前端標準的子集。

• Layout的選擇：在2014年底確認采用CSS Layout和Flex Box來重新設計實現，讓Layout變得簡單起來，以前通過線性布局和水平垂直布局實現的種種問題，都迎刃而解。
• 腳本庫的選擇：在果斷放棄接受範圍窄的腳本庫後，我們選型了一個性能佳體積小的JS庫，iPhone和Android采用同一套JS庫，大大降低了鳥巢核心的開發成本，提供了一個穩定可控的鳥巢核心。
• 頁麵協議的選擇：選擇HTML5來做頁麵描述，遵守Chrome事實標準後，問題都消失了。如果選擇私有JSON頁麵協議，開發一個工具來編輯維護JSON頁麵，工作量巨大，效果也不佳。

鳥巢的優勢

依托前端開發技術，獲得Native用戶體驗；遵守行業標準，學習門檻低；客戶端服務端整體方案，改造接入簡單；重後端設計，減少客戶端升級依賴；

標準化

語法

以標準的HTML5、CSS和JavaScript語法為唯一標準語法，無私有語法協議；

私有協議，會讓開發者在最開始就望而生畏。協議本身，會不斷的隨著業務需求的驅動增加修改。團隊人員的變動和衡量標準的不一，會讓協議本身都會成為一種負擔。

實現效果

Chrome瀏覽器是衡量語法是否標準的唯一標杆，鳥巢展示效果保持和Chrome一致，無需關心多瀏覽器兼容性問題；

 √  ×
圖4、與Chrome展示效果保持一致

開發效率

上手快

Easy to learn：盡管鳥巢從實際需求及性能考量，隻實現了裏麵的一個子集，這帶來了一定的學習成本，但是成本很低。一個剛剛畢業的新人，一周以後就能夠高質量的做出各式滿足視覺要求的頁麵，培養成本遠遠低於一個Native開發工程師。

易複用

Write once，run anywhere。這是很多程序員的夢想。由於采用Chrome標準，因此在iPhone上實現的頁麵，放在Android上也是完全ok的。隻是在實際工作中，不同平台視覺要求可能會有差異，其中一個平台可能需要在另一個平台的頁麵基礎上進行二次開發，但是效率也已經提升了很多。從鳥巢實際情況看，開發效率提升到了原有的1.5~2倍。

使用成本低

改造成本

鳥巢對原有APP方案的侵入性很低：鳥巢是為了替代Native APP中的動態部分，並不是為了替代Native APP本身。應用方根據自身的不同需求，可以選擇整個APP、APP中的部分頁麵或APP中頁麵的部分進行托管。

維護成本

鳥巢是一套整體解決方案，客戶端解決頁麵問題，服務端解決頁麵的動態維護管理問題。使用方無需單獨考慮頁麵的維護管理。

圖6、APP使用鳥巢的調用關係圖

穩定可靠性

鳥巢這種方式目前已經接入了：支付、線下、搜索、服務窗等業務，鳥巢的原型版本在過去的一年裏，托管了整個支付寶手機端的多個頁麵，每天有億級的Native頁麵通過這種方式支撐。

圖7、接入的應用場景

鳥巢的適用場景

鳥巢並不是一個萬能的事物，而是在有動態需求的地方，可以很方便簡單的解決這個需求。在缺乏客戶端開發資源的情況下，可以通過前端技術獲得Native體驗。鳥巢本身不是為了做一個APP，而是為了解放APP本身的限製。

全業務托管

整個APP的所有頁麵全部托管給鳥巢，鳥巢負責全部頁麵的渲染、管理、更新、緩存。如：支付寶錢包支付采用了這個方式接入鳥巢。這個方案的好處就是：通過業務服務端發布和鳥巢頁麵管理，整個APP都處於可控狀態，隨時可以進行業務上新、業務變更和bug修複，業務可控性達到最佳。

圖8、全業務托管樣例

全屏頁麵托管

整個APP中，隻有有動態變化需求的部分頁麵，才托管給鳥巢。鳥巢負責這部分頁麵的渲染、管理、更新、緩存。如：支付寶全局搜索采用這個方式接入了鳥巢。這個方案的好處是：在原有APP基礎架構上，隻用針對性的接入鳥巢，就可以把變更頻繁的業務沉澱到服務端，降低業務變更對APP升級的依賴性。

圖9、全屏頁麵托管樣例

頁麵部分托管

整個APP中，在一個框架相對穩定的頁麵裏，隻有頁麵的一部分區域是需要動態變化的。鳥巢負責這個頁麵部分的渲染、管理、更新、緩存。如：支付寶線下采用這個方式接入了鳥巢。

對鳥巢的疑問

有很多同學問我，鳥巢是不是這樣的，或者這樣的？這裏統一解答一下。

平台無關性

理論上，以鳥巢的方案實現了iPhone的頁麵，Android在展現上也是OK的，多平台共用一套模板也是鳥巢鼓勵的方向。但並不強製，如果視覺風格本身兩個平台有差異，其中一個平台就可以在另外一個平台的模板基礎上進行二次開發。總的來說，開發速度是可以提升為原來的1.5~2倍。

鳥巢絕不是另一個的瀏覽器

鳥巢絕不是另一個的瀏覽器！鳥巢與Webview沒有任何關係。鳥巢不會發展H5應用，更不會在此基礎上形成應用生態。隻是用低門檻的方式，適應界麵布局和有限流程的變化需求。
隻是借鑒使用了HTML及CSS的語法，整體的Layout及DOM結構與瀏覽器的方案和策略完全不同，每一個標簽最終都會映射到一個Native控件上，引入了一個完整的JS庫，通過Bridge將Native代碼與JS進行橋接。

如何保障性能

鳥巢采用H5標準的子集，並拋棄了瀏覽器的DOM渲染模式，自行設計了一套Layout方法。同時，針對移動設備本身的特點，嚴格選擇了協議的子集來實現，從而保證不會像瀏覽器那樣臃腫。

最後更新：2017-04-01 13:37:09

  上一篇： 你應該知道的RPC原理

  下一篇： 如何健壯你的後端服務？