在移動開發這片熱土上，除了原生之外，也有一些公司在嘗試着新技術、新模式，這是混合開發誕生和延續意義以及價值。
原生開發和混合開發的優缺點也已經是一個老生常談的事兒了，在這裡我就簡單來說一下：
原生開發優點：靈活、主流、成熟、解決問題成本等優點；
混合開發技術：開發效率快，上手難度低，跨平台（一套代碼可以運作在ios/android）上；
缺點就不用多說了，他們本身的優點也是牽制對方的缺點。
進入主題
而我們本文重點要說的是我們在将近3年的實踐當中，對與混合開發的一些思考與總結，希望可以幫助一些公司在混合開發技術架構選型上少走一些彎路，當然本文所述的所有資訊都是我對于這些技術一些自己的了解，對你隻是有參考作用，不能完全替代和幫助架構師對于技術的選型，俗話說的好：“明白了很多道理，依然過不好這一生.”，有些坑還是要自己踩的，不然也不會懂得什麼叫“刻骨銘心”！
架構進階之路
我們這三年的時間，做的是一款綜合類app，裡面主要的功能有：新聞、工具（十餘款）、聊天、朋友圈，功能可以說比較多。
而我們使用的混合開發架構有：
- DCloud
- DeviceOne
- Xamarin
- React Native
下來我們說這四款架構的優缺點；
1、DCloud
DCloud作為我們最早（2015年）使用的WebApp架構，可以說讓我們用的非常的不舒服，DCloud是我們精心選擇的第一款混合開發架構，對比了同類的webapp架構還算優秀，有自己的開發工具HBuilder，有很好的模闆和Demo讓我們能很快的上手寫代碼，配合官方MUI（DCloud的UI解決方案），咋一看用起來還可以，然而在我們的實踐中還暴露了很多問題，下面我來列舉一下：
優點：
- 門檻比較低（懂Js和Html的程式員對照着api很快能夠上手）；
- 有一整套的解決方案，開發工具+UI庫；
缺點：
- 使用的是傳統H5技術，在性能上尤其是低端android機上有瓶頸，高端機操作上也有明顯的延遲；
- 打包是線上打包，伺服器經常挂，至少2015年是這樣，結果你着急上東西，卻遲遲打不出來app，有一定的制約和風險性；
- 文檔不是很全，有些東西不太好找；
- 頁面生命周期執行函數存在機率事件，這個事情當時糾結了很久，官方的回複也是有一定的幾率執行或者不執行，2015年是這樣，現在的情況不明；
總體來說：DCloud看起來入門很容易，但是想要寫好需要很好的js功底，普通水準的js寫出來的app使用者體驗非常有局限性，基于上面的問題，我們決定換掉它。
2、DeviceOne
DeviceOne（下文簡稱do）是我們國内北京的一個公司做的，他也有自己的開發工具，是基于eclipse改的，編譯器可以說很不好用，不時的需要重新啟動一下，而do和DCloud的最大差別是，do不是webapp，是以在性能上do是遠遠勝于DCloud的，do在UI上采用的是“元件商店”的概念，在說這個概念之前先要說說do的基本原理，do開發使用的是js語言，是标準的js函數，而js方法調用的元件，全部是用原生封裝好的，是以你使用的每個元件：第一、可以在開發工具上拖拉拽；第二、官方開發了他們開發元件的接口每個人都可以給他們寫元件，下來具體說說他們的優缺點：
- 開發效率極高，元件拖拉拽就可以；
- 開發門檻低，會js即可；
- 執行效率高；
- 開發品質、開發的功能，受元件的制約，元件有bug你寫出來的app就有bug，元件沒有的功能，你app也實作不了；
- deviceone的打包次數和下載下傳次數有限制，超出的需要收取費用；
- 使用的是線上打包，伺服器偶爾也會挂；
- 有些元件有問題，找官方處理，他們會讓你寫錯誤示例的demo，剛開始寫一個兩個還好，最後給do寫錯誤demo成了工作的一部分了，影響工作效率；
- 使用的人不多，網上的資料/替代方案相對匮乏；
總體來說：do性能和模式都是ok的，隻是開發app受外界因素影響比較多，資料比較少，替代方案幾乎沒有。
3、Xamarin
經曆了兩次架構更換之後，我們把希望寄托給了微軟的Xamarin，用它的一個好處是可以使用C#開發，對于C#出身的程式員來說，簡直是夢寐以求的事情，在一個好處就是他有一個“好粑粑”，以之前我們對于C#的信任，讓我們對于Xamarin的技術，也不自覺的産生了好感，以至于我們錯誤了低估了他能帶給我們的“麻煩”。
- 可以使用C#語言開發；
- 本地打包，不在受其他平台伺服器的制約；
- 調試友善，vs開發工具打斷點容易；
- 國内資料少，資料都是國外的；
- 應用群體少，成熟解決方案少，很多第三方元件不支援，我們在綁定三方的元件比如：極光推送、相冊選擇、友盟統計、百度地圖等ios綁定上耗費了大量的時間和經曆；
- 開發成本高，C#程式員也來越少也越來越難招；
- ios意外的閃退比較多，而且原因不好找；
總體來說：開發成本相對于之前兩款架構來說，耗費的成本要高很多，Xamarin本身的功能也有限，使用的人數少，導緻資料和解決方案少，開發成本和解決問題的成本很高，有很多元件沒有很好的封裝，內建起來也相對麻煩很多。
4、React Native
我們目前正在使用的架構，Facebook和JD的開發架構，在混合開發技術領域屬于正統的，主流的架構，網上的資料多，基于React技術JSX技術相對成熟，開發成本低會js稍加學習一下JSX的文法即可，基于npm生态系統，所有nodejs可以使用的三方包，都可以使用，可以使用es5/es6/es7的文法開發app，非常舒服，第三方元件和綁定原生庫都非常的簡單友善，網上的資料也非常多。
- 開發門檻低（會js稍加學習jsx文法即可）；
- 資料多，解決問題成本低；
- 開發效率高，第三方內建元件多；
- 有好的開發生态圈，性能好，背靠npm有萬級以上的優秀開源三方元件支援；
- 初學者，配置較多，開發環境配置不是很友善；
- Facebook的更新頻率比較快，版本存在一定的差異，有些老的資料可能并不适用于現在的版本；
總體來說：React Native對于混合開發來說應該是一個不錯的選擇。
總結
所有的經曆，到最後都會變為經驗，擁抱變化，不斷的嘗試和學習新的技能，會讓你收益匪淺，墨守成規已經不在适應這個物競天擇的世界。成長的道路上會遇到很多坎坷和挫折，但不管這些試錯成本有多大，他最後産生的價值，要遠遠大于固步自封與墨守成規帶來的後果。
關注下面二維碼，訂閱更多精彩内容。
關注公衆号（加好友）：
作者：
王磊的部落格
出處：
http://vipstone.cnblogs.com/