前段時間，豆瓣將自己的混合開發(fā)框架Rexxar開源了。豆瓣可以說是在國內對HTML5實踐最早的一批公司，早在2013年的時候他們就應用了當時還顯得超前的Web Component概念開發(fā)了CardKit移動UI框架。在移動開發(fā)上，豆瓣也采用了混合開發(fā)的模式，Rexxar就是他們實踐和思考的結晶。我采訪了Rexxar的主要開發(fā)者之一郭麟，看看他們對混合開發(fā)的思考。

[[178034]]

豆瓣使用混合開發(fā)的原因，是因為他們需要同時提供iOS、Android、移動Web版本的頁面，相對于同時開發(fā)三個版本，使用混合開發(fā)顯然可以在代碼重用、開發(fā)成本和效率方面有很大的優(yōu)勢，在權衡性能體驗的前提下，使用混合開發(fā)是非?，F實的選擇。

Rexxar是什么

Rexxar是一個針對移動端的混合開發(fā)框架。支持Android、iOS和移動Web。

Rexxar主要由三部分組成：

• Rexxar-web：前端代碼庫。包括一套打包、調試、發(fā)布工具，以及公共前端組件，和對Rexxar Container實現的Widget的調用。
• Rexxar-Router：路由表，將每個頁面分配一個服務器端鏈接，以及一個本地URI，通過路由表來訪問頁面。
• Rexxar-container：增強版WebView，封裝了一些Native API支持，包括OAuth授權、圖片緩存等。

Rexxar目前已經開源，并且分為3個項目，你可以只使用其中某個項目來開發(fā)對應平臺的代碼：

https://github.com/douban/rexxar-web

https://github.com/douban/rexxar-android

https://github.com/douban/rexxar-ios

混合開發(fā)的注意點

對于混合開發(fā)，很多團隊都有過實踐，從大家分享的內容來看，重點無非以下幾類：

• 增強WebView：原生WebView基本是PC平臺瀏覽器內核的移植，但對于移動場景并不完全適合，各種硬件API得不到HTML5原生支持。因此對于WebView的種種Hack、增強應運而生，甚至出現了基于增強WebView提供第三方服務的。
• 路由：應用內跳轉由于加入了WebView而變得復雜起來，同時由于組件化、模塊化帶來的問題，路由也成為人們討論的重點。
• 緩存：移動網絡條件差，為了用戶體驗，必須要做資源緩存和預加載。
• 通信：即HTML5和Native之間的通信。利用系統(tǒng)提供的橋接API可以實現，不過在應用上還有著一些坑點和安全問題。

這些問題大部分已經有了最佳實踐，Rexxar就是其中一個解決方案。在混合開發(fā)中一般有兩種方案：純?yōu)g覽器方案、前端模板渲染容器方案，Rexxar則處于兩者之間。

Rexxar的設計者對于Rexxar使用場景有明確的定義：頁面是重度展示，并輕度交互的。所以，除了比較簡單的應用之外，如果對使用體驗有追求，大概很難僅僅用Rexxar，或者其他某種混合開發(fā)完成。

對于擴展功能，Rexxar留出了清晰易用的接口。項目中也提供了幾個擴展Rexxar功能的實例，文檔也較為完整。郭麟他們在豆瓣App中其實也使用相同的接口做了一些擴展，只是由于這些擴展和豆瓣App的業(yè)務綁定較深，就沒有放入Rexxar項目。

Rexxar在客戶端的實現其實就是一個定制了更多功能的WebView。而且，Rexxar使用的是系統(tǒng)的WebView。所以，它對App的體積沒有影響。但是，同時使用很多個WebView帶來的內存問題，Rexxar同樣也有，這是需要注意的。

Rexxar的Crash有兩種：

• 一種是JavaScript的錯誤，也就是應用邏輯的問題。這類錯誤他們在WebView中做了捕獲，然后通過App的日志系統(tǒng)發(fā)回服務器。
• 一種是WebView的Crash，這種錯誤WebView自己無法捕獲，現在是通過fabric，Umeng這種原生的Crash收集系統(tǒng)收集。

從上線了Rexxar之后，JavaScript，WebView相關錯誤日志和Crash報告是有增長的。所占的比例和Rexxar的頁面數量相關，一直在變化，但都未超過10%。但由于豆瓣App中主要還是原生頁面占大多數。所以，Rexxar帶來的Crash所占的比例并不大。

他們也正在研究，在移動環(huán)境下如何定位Rexxar頁面的錯誤，如何調試，如何修正這些錯誤，并將其加入基礎設施里面。

為什么不用PhonGap/Cordova

在混合開發(fā)中早已有了很成熟的方案，就是PhoneGap和它的后繼者Cordoba. 為什么豆瓣還要造自己的輪子呢?

郭麟說，如果Hybrid方案定義為前端和原生技術的混合使用，那他們認為PhoneGap/Cordova嚴格來說不算是Hybrid方案，因為它的目標是全面使用前端技術開發(fā)移動應用，而不是前端和原生技術混合使用。但是，包括Cordova，還可以加上React Native，以及Rexxar的目標是一致的：使用前端技術來開發(fā)移動應用，提高工程效率。

豆瓣實際上使用PhoneGap開發(fā)過一款移動App，并在AppStore上架了，這個應用叫豆瓣音樂人，因此，其實豆瓣對PhoneGap/Cordova已經有一定了解和使用經驗。為何在開發(fā)豆瓣App時又造了一個叫Rexxar的“輪子”呢?這是因為，他們對PhoneGap/Cordova這個項目的理念并不完全贊同，Rexxar的出發(fā)點和PhoneGap/Cordova并不一樣。

PhoneGap/Cordova這個項目極具野心。它希望完全使用前端技術完成移動開發(fā)。所以，可以看到它盡力讓前端技術完成盡量多的開發(fā)工作，只在前端無法直接調用的原生系統(tǒng)功能方面提供了前端可用的接口。主流的PhoneGap/Cordova項目將業(yè)務邏輯都實現在一個WebView中，目標是，讓開發(fā)者只使用前端技術就可以完成一個移動應用的所有開發(fā)工作。這種做法需要有一個前提：前端技術可以解決移動開發(fā)的所有需求。他們認為PhoneGap/Cordova這個理念在現階段有些過于理想化了，或者說過于激進了。

Rexxar則相對實際，或者說保守一些。郭麟表示，他們仍然認為，現階段，甚至在相當遙遠的未來，移動開發(fā)中前端技術都不太可能完全代替原生技術。但同時也承認，移動開發(fā)中總是存在部分功能是適合使用前端技術完成的。在他們的認識中，前端技術和原生技術應該是共存的。移動開發(fā)中，前端技術不會完全代替原生技術;而有了前端技術的加入，移動開發(fā)的效率會提高?；谶@種認識，豆瓣開發(fā)了Rexxar。

可以看到，Rexxar立足于在一個原生項目使用前端技術，而不是整個項目都使用前端技術實現。他們甚至提供一個頁面部分使用Rexxar完成，部分使用原生技術實現的方案。豆瓣希望借助前端技術優(yōu)秀的排版能力、開發(fā)速度、通用性，來彌補原生開發(fā)在這方面的不足。在微信作為主要內容分享渠道的今天，這樣做還帶來了一個額外的好處，Rexxar頁面可以平滑的使用在微信中。

總結而言，如果Rexxar和PhoneGap/Cordova比較的話，大目標是一致的：使用前端技術開發(fā)移動應用。實現技術棧差不多：使用WebView，提供調用原生功能的接口。但是，出發(fā)點不一樣。PhoneGap/Cordova致力于完全使用前端技術進行移動開發(fā);Rexxar致力于在移動項目中部分使用前端技術。

移動開發(fā)者要學習前端技術

目前，豆瓣移動團隊大約有十多位客戶端工程師，其中 iOS 和 Android 各一半。另有一位優(yōu)秀的前端工程師專門支持豆瓣App中的混合開發(fā)，他負責Rexxar Web的開發(fā)，提供基礎設施。同時如果有一些較復雜的業(yè)務要用Rexxar實現，他也會參與和指導業(yè)務開發(fā)。

使用Rexxar這類混合開發(fā)技術，使得團隊開發(fā)的技術棧向前端技術偏斜了。所以，較理想的配置是團隊中加入較優(yōu)秀的前端工程師，由他來處理基礎設施的開發(fā)，和疑難問題的解決。同時，整個團隊需要理解混合開發(fā)所帶來的優(yōu)勢，認可這個開發(fā)方式的轉變，并且愿意學習和調整自己的技術棧。

在項目中，在合適的場景中，豆瓣會優(yōu)先使用Rexxar。在團隊中，他們鼓勵非前端工程師學習和使用前端技術。為此，他們專門組織了關于前端技術內部培訓，讓有意愿的非前端工程師具有了可以使用前端技術進行日常開發(fā)的基本能力。在豆瓣App的日常開發(fā)中，大部分Rexxar頁面都由客戶端工程師完成，前端工程師會幫忙做Code Review和解決疑難問題。

Rexxar與React Native

豆瓣在實際使用Rexxar的時候，使用React作為前端框架。對此郭麟解釋道，Rexxar本身對前端框架的選擇沒有要求，只是他們選擇了React來實現業(yè)務層，而當時React Native并未發(fā)布，經過對RN的了解后，他們并未否定使用RN的可能性。

在他們看來，React Native同樣是一種使用前端技術開發(fā)移動應用的技術方案，這和他們開發(fā)Rexxar的目的是一致的。只是，Rexxar仍然在停留在瀏覽器引擎中，而Facebook激進地脫離了沉重的瀏覽器引擎，架設了他們自己的Web通向Native的橋梁，這是一個很大膽的方案。

在React Native發(fā)布后，他們馬上就組織研究，并做了小范圍的實踐，也與同行做了交流。結論是，現階段，React Native還稍顯稚嫩。對于一些技術棧比較特別的團隊，比如Web經驗特別豐富，前端工程師特別優(yōu)秀，但又缺乏客戶端工程師的情況，React Native是一個快速切入移動應用市場的技術選擇。但就豆瓣App的情況和React Native的現狀而言，使用前端技術進行移動應用開發(fā)方面，他們還堅持留在WebView中，不會使用React Native。

當然，React Native一直在發(fā)展和進步。如果，有一天React Native和React可以在代碼級別移植，他們也許會嘗試從WebView遷移到React Native。畢竟WebView的性能仍然弱于原生。

總結與展望

豆瓣App和研發(fā)團隊都經歷了從小到大的發(fā)展過程。Rexxar是這個發(fā)展過程中，解決工程效率的一個方案。在豆瓣移動開發(fā)中使用Rexxar，確實在一定程度上提高了他們的開發(fā)效率。以前一個頁面需要 iOS 和 Android 兩位工程師各開發(fā)一遍，現在只需要一位工程師寫一次前端代碼，甚至還可以應用到移動 Web 站上去。前端技術開發(fā)界面方面開發(fā)方面也有效率上的優(yōu)勢。熱部署能力，使他們規(guī)避了發(fā)布移動應用的審核過程，也讓bug修復過程更便利。

豆瓣將Rexxar這個項目開源，一方面，是因為提高移動開發(fā)的工程效率是一個普遍問題，而他們的實踐結果也證明Rexxar確實幫助改善了工程效率。所以，他們認為Rexxar應該能給大家提供一些借鑒的方向。另一方面，是為了提高項目本身的質量，沒有方案是完美的，Rexxar也還存在不少問題。開源這個項目，促使他們提高了整個項目的代碼質量。同時，也更容易聽到大家的意見和建議。

雖然Rexxar仍然存在一些問題和使用上的限制。但是在有限的使用中，豆瓣App團隊仍然收獲不少。在未來他們會持續(xù)推動Rexxar在豆瓣移動開發(fā)中的使用。郭麟表示，對于Rexxar未來的發(fā)展，他們主要關注兩個方面：

• 一方面是基礎設施，比如，如何在產品中，更好地監(jiān)控Rexxar頁面出現的問題，如何調試和解決Rexxar頁面出現的bug。如果希望在大型項目中使用Rexxar，這些基礎設施是應該配備的;
• 另一方面是性能，Rexxar仍然跑在瀏覽器引擎中。瀏覽器引擎這個中間層提高了工程效率，但也因為性能問題局限了其使用范圍。所以，他們會花一些精力提高Rexxar的運行效率。比如，Rexxar的iOS版一直在關注從UIWebView遷移到WKWebView的可能性。

參考文章：

豆瓣混合開發(fā)實踐 http://lincode.github.io/Hybrid-Rexxar

豆瓣的混合開發(fā)框架Rexxar http://lincode.github.io/Rexxar-OpenSource

豆瓣App的模塊化實踐 http://mp.weixin.qq.com/s?__biz=MzA3ODg4MDk0Ng==&mid=2651112821&idx=1&sn=2987ba2c9d68e3982e795d9eeb15f82b

《CardKit & DOMO UI - 移動時代技術與設計的十字路口》技術篇 https://www.douban.com/note/347692465/

豆瓣音樂人app的PhoneGap實踐 http://www.infoq.com/cn/news/2013/10/douban-artist-PhoneGap-practice