最近在公司裡面遇到一個尷尬的事情，一開始手機是用 Native 開發的，進度趕不上產品的需求，有人反饋用 H5 可以大大加快速度，老闆有點意思，但是又有人反饋用 H5 坑多，這下團隊不知道如何是好，怎麼選擇了。
為了解決這個問題，我結合一下自己的開發經驗，嘗試說明一下大前端如何進行技術選型。歡迎看官給我更多建議，大家一起討論。

名詞解釋

名詞	說明
大前端	手機，web，pc 等客戶端都包括在內
Native 開發	只用平臺原生的開發語言，開發框架來做應用
混合開發	用 js+h5 開發應用的技術，可以通過某種手段呼叫系統能力
其他 Native 開發	不是平臺原生的開發方式，但是可以生成 Native 程式碼，或者呼叫 native 介面的技術（想不到更好的名字，抱歉，暫時叫其他native開發）
開發效率	是指某一技術方案，開發的速度
執行效率	是指最終產品的體驗，執行速度
需要人員	是指需要的人力資源的多少，人員所需的知識的範圍

手機端

現在移動端的使用人數大於桌面端，所以先討論一下移動端，列舉一下我知道的現有的技術方案，只討論 android 和 iOS 系統

技術方案	代表方案	開發效率	執行效率	需要人員
Native開發	Android，iOS原生框架	高	高	兩套人馬，需要 Android，iOS 的知識
混合開發	Cordova，AppCan	極高，最新的語言和框架，one code base	低	一套人馬，需要web知識
其他Native	RN，WEEX，Xamarin	很高	比較高	一套人馬，需要相關技術框架知識（比如web），有一位專家解決和原生平臺相關的問題

注意點：

1. 混合開發不是隻開發一個 h5 webapp 就好了，h5 是需要呼叫本地介面的，所以需要部署在本地，如果把 h5 放在遠端，就只能顯示一些靜態資源，如果遠端呼叫本地介面，則是非常危險的事情。
2. 其他 Native 方案不一定是 Javascript 寫的，比如 Xamarin 就是用 C#，所以挑選自己團隊喜歡的方案很重要，需要有個人能罩得住，有一些和原生平臺相關的問題，需要技術專家去解決。
3. 其他 Native 方案實際上是牛逼團隊提出的方案，他們有原生平臺非常精通的人，也有其他領域精通的人（比如 Xamarin 就需要 C# 精通，Mono 虛擬機器有所瞭解和原生也懂的人。RN 需要對 React，JS，原生系統都很瞭解），所以人家能提出牛逼方案，如果你的團隊沒有能罩得住的人，則會在不斷挖坑填坑。
4. 業務非常著急的小團隊，還是比較適合技術棧不復雜，有很多成熟方案技術路線，所以原生開發比較合適，也好招人。
5. 業務非常著急，但是有錢，可以招牛人或者已經有幾位牛人的團隊，適合用“其他 Native 方案”。
6. 小白比較多的團隊，也適合使用原生開發。
7. 特別小的創業團隊，驗證商業邏輯的，可以使用混合開發，因為效能不是最重要的。
8. 如果使用了原生的開發方式，其實也還可以混合其他開發方式，當團隊發展壯大的時候，可以適當的切換。
9. 上面並沒有開發遊戲的方案，因為我還沒做過遊戲，遊戲和 APP 開發的原理也差別很多，遊戲裡面比較火的引擎，https://unity3d.com/cn，也是用 C#，JS 作為主要開發語言
10. 很多人會疑問為啥 Native 開發的效率也是高，那是因為開發效率是隻開發的速度，Native 一般都有比較成熟的框架，所以當然不會慢，只是需要兩套人馬，成本高。
11. Google 推出了一個框架 Flutter，據說是提供了一個引擎，所以你釋出的App的時候要帶上這個引擎，鹹魚有嘗試用，還不是很成熟。

總結一下，對公司來說，沒有最好的方案，只有最適合自己的方案。混合開發可以做到one code base，write once，run anywhere，其他native方案可以做到learn once, write anywhere，native開發方案最成熟，技術棧簡單，坑少

PC端

雖然現在網際網路產品 PC 端的產品比較少，不過我最近還是遇到過一些需求，需要在 Linux，Mac，和 Windows 上跑。相比較與手機，PC 的能力強大很多，所以在 PC 上，混合開發的模式比較流行。

我只在 windows 上使用過傳統的 native 開發方式，所以只能比較一下windows上傳統的開發方案和混合開發方案的優缺點。

技術方案	代表方案	開發效率	執行效率	需要人員
Native	MFC	聽過這個名詞的，都是老人，開發效率不做評價	高	需要 CPP 和windows 的大牛才能 handle 此 framework，是微軟大又笨的代表
Native	WTL	去掉 MFC 框架，使用 windows API 的一個輕量框架，CPP 開發	高	CPP 大牛，windows 大牛
Native	win-form	.net 平臺，效率高	高	C#，.Net，windows 平臺知識
Native	wpf	.net 平臺，效率高，代替winform	高	C#，.Net，windows平臺知識

上面的技術都不能跨平臺，當然C#有一個跨平臺的虛擬機器mono，mono 上以前有一個公司 Xamarin，可以做 Mac 上的開發，現已被微軟收購。

這些技術已經都不是我的菜，現在比較一下跨平臺方案

技術方案	代表方案	開發效率	執行效率	需要人員
Native	QT	有 QML，JS 介面，高	高	CPP 大牛，各個系統平臺大牛
混合開發	electron	web技術開發，高	尚可，複雜動畫不行	web 大牛，需要一些平臺知識

很明顯，如果不是做遊戲，electron 是一個很好的方案了，我們常用的開發工具vs code，就是用electron開發的。

總結一下，跨PC平臺的開發，electron可以做到one code base，write once，run anywhere

“其他 Native 開發”和 Web 開發的關係

其他 Native 開發現在比較火的 ReactNative 和 Weex（不知道火不火，據說手淘在用），都使用了一些 web 端的框架和知識，所以有必要說明一些他們和web開發的關係。

下圖以React Native舉例說明

React Native 和 React 開發 web 使用的是同樣的框架，不同點一個生成 DOM 在瀏覽器中渲染，一個是最後還是呼叫 native 介面。這樣我們學習了 React 的知識以後，就可以在不同的平臺下使用，做到學習一次，可以在各個平臺上寫程式碼，做到了人力資源的複用。

既然 React Native 是需要呼叫平臺原生的介面，那麼他和混合開發模式有什麼區別呢，我們看下圖，下圖向我們說明，每一個 UI 元素，對應的都是 Natvie 的控制元件，所以 UI 渲染也是 Native 的，只是我們用 JS 去寫而已。其實 Xamarin 也是類似原理。

作為對比，我們看一下混合開發的架構，在下圖的混合開發架構中，我們看到渲染介面是用 HTML 開發的，所以最影響使用者體驗的 UI，我們交給了 WebView，所以他的表現目前來說是沒有 Native UI 好的。

electron 架構

在 PC 上混合開發的模式和手機比較像，electron 更近一步的是使用了瀏覽器的多程式架構，所以你開發的應用等於是一個瀏覽器加上網頁。手機裡面沒有使用的原因是因為不是所有的 APP 都需要這種複雜的架構，只需要呼叫 native 介面就好。

electron 牛逼的地方在於，主程式有 Node 環境， 但是渲染程式也有 Node 環境，只是被閹割放在容器裡面了。大部分 electron 使用 H5 渲染介面，但是選單等和系統相關的 UI，是在 Main Process 裡面使用 native ui 完成的。

React Native 是否能做到不寫平臺相關的程式碼

這個問題，我特別諮詢了一位前同事，他用react native寫過幾個專案，他給我的答案是大部分可以做到，他採用的方案是儘量使用兩個平臺都支援的控制元件。

1. 50%使用 ant design moblie，
2. 30%使用其他跨平臺開源控制元件
3. 20%自己開發跨平臺開源控制元件
4. 一些和原生相關的問題，一些坑，由自己解決，其他都可以招 web 開發工程師。
5. 採用這套方案後，還可以相容微信小程式。
6. 他的產品主要是銀行產品，工具屬性比較重。
7. 可以一套人馬打天下，測試的時候，也可以減少人力，因為邏輯程式碼也是一套。

其他方案

當然，還有一些更小眾的方案，比如用 C# 開發，Xamarin 可以瞭解以下。C++ 開發可以瞭解以下 QT，也可以使用 C++ 開發邏輯，這樣也能跨平臺，這樣的團隊可能不多了。

總結

我們可以看到，使用“混合開發方案”和“其他 Native 開發方案”可以複用程式碼，確實整體效率高了，但是這些技術方案由於增加了技術棧，可能會導致一些坑，影響開發，所以，選擇每個方案前，一定要清楚技術上能不能把握住。

由於時間關係，很多東西只是草草網上找個圖，所以沒有深入探討，等以後深入到程式碼，再總結總結。

參考資料

React Native Architecture : Explained!