該文章來自於阿里巴巴技術協會（ATA）精選文章。

導讀：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效果

鳥巢的特點

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

鳥巢引數

方案	支援平臺	語言	佈局方式	擴充套件性	動態能力	體積
鳥巢	Web、iOS、android	HTML5+CSS+JavaScript	CSS Layout+Flex box	Bridge+Native Module	服務端客戶端整體動態方案	android:650K，iOS:800K

從支援平臺（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方法。同時，針對移動裝置本身的特點，嚴格選擇了協議的子集來實現，從而保證不會像瀏覽器那樣臃腫。