在這個鉅變的時代，技術選型是個很難做決定的事情，而移動應用技術領域在幾個巨頭（Google，Facebook，Apple etc.）的帶動下更是日新月異。所以說要選擇一個適合業務需求並且匹配開發人員能力的技術方案並不是一件簡單的事情。我也只是在移動開發上做過一點微小的工作，此處僅能拋個磚，希望各位有玉的大神儘管砸過來。
做移動應用開發，說起來技術方案不外乎HTML5（沒錯，做Mobile Web其實也算是一種移動應用）、Native（在Android上不管是用Java、Kotlin還是Scala，iOS上不管是用Objective-C還是Swift）和使用原生UI，用JavaScript來實現邏輯的諸如React Native一類的方案。除此之外，還有結合HTML5和Native的Hybird混合方案。不同的技術方案有著不同的適應場景，至於具體如何選擇，接下來我簡單地談談自己的理解。
1、HTML5
也就是Web App的方案。這種方案最大的優點在於“Write Once, Run Everywhere”，不管你是Android還是iOS，都可以用一套程式碼搞定，在國內的話還能對接微信公眾號，給使用者提供一個方便快捷的入口，並且還有版本升級容易的優勢（畢竟伺服器是受自己控制的）。但是這種方案的缺點也很明顯——無法使用系統級API，只能做為一個臨時的入口，使用者很難留存，並且因為瀏覽器效能的原因，很難帶來很好的使用者體驗。
所以說Web App的主要適用場景還是在於作為對非核心業務在移動端的入口補足，或者是作為使用者輕量、低頻使用的體驗增強。
美團移動網站引導頁
美團移動網站首頁
美團的移動網頁就是很典型的例子，主要還是提供給不經常使用的使用者一個入口，網站內部還是在儘量引導使用者下載使用客戶端。
2、Hybird
Hybird是一種兼顧Native與HTML的開發模式，但根據實現的不同，還可以再細分為兩種實現方案：
- 在Native App中使用WebView載入遠端Web資源
- 使用Cordova/PhoneGap等框架通過WebView載入本地資源進行頁面渲染
第一種方案其實已經應用得非常普遍了，很多應用的展示頁面都是通過這種方式實現的。因為展示頁面需要的正是能夠輕易更換內容及佈局的格式，並且這種純展示的頁面也並不需要複雜的動畫與特效，使用Web頁面是一個非常合適的解決方案。
而第二種方案前一段時間非常火，因為它在跨平臺，在高效開發以及快速釋出上有著明顯的優勢，畢竟Web內容只需要開發一次就可以在各個平臺使用。而且將資源打包到本地也可以在一定程度上緩解從遠端載入靜態資源導致UI展示延遲的問題，並且還可以通過橋接Native和Web來呼叫一些Device的API。但其劣勢也很明顯，一是通過WebView執行程式碼效率較低，很難實現一些炫酷的效果，並且還存在不同裝置的相容性問題；二是如果想呼叫相關平臺的API，需要針對平臺單獨進行開發，如果在應用中用到了大量的Device API，那麼開發的效率將大大降低；三是很難應用到平臺相關的新特性，比較難做出有特色的產品。
使用HTML頁面來實現純展示頁面是非常推薦的一種方案。而Cordova/PhoneGap則更適用於對Mobile預算有限的公司、創業團隊，或者對App進行快速的上線驗證。
正好之前有個專案就用到了這種方案，為一家業務轉型的零售商提供了使用一套基本程式碼來完成Android和iOS兩個平臺的App和微信公眾號的相關頁面的技術方案。
零售商Android應用零售商微信端
3、React Native
把React Native單獨拿出來，是因為確實不能簡單的將它分到其它任意一種方案裡面去。React Native確實是最近最火的跨平臺App解決方案了。它脫胎於React，因為React基於Virtual DOM來進行介面渲染，所以用Native的View來替換掉原本React的HTML DOM就順理成章的引出了React Native的概念。
它與之前的跨平臺方案有一個本質的區別，在於：其它方案都在追求寫一次code解決所有平臺的問題，而React Native的理念在於“Learn Once, Write Anywhere”。雖然大部分程式碼是平臺無關的，但是平臺相關的程式碼都需要單獨實現，這雖然對跨平臺帶來了不便，但是引入的好處也是顯而易見的，View層的部分通過原生元件實現，效能比其他WebView的方案不知道高到哪去了。而且React Native整套的邏輯程式碼都通過JavaScript實現，這樣就讓跨平臺應用能夠方便的複用邏輯程式碼。另外雖然React Native沒有支援使用CSS來實現樣式，但是提供了類似CSS的樣式表支援，有過UI開發經驗的人都能夠非常快的上手。由於前端React也是非常的火，很多React社群的很多產出都可以在React Native上借鑑使用。
React Native對於沒有複雜動畫效果的一般應用來說不失為一個很好的解決方案。而且對於一些小型的企業級應用也是非常適用的。但是，React Native對於Android平臺的支援度是不如iOS平臺的，而且現有的非常成熟的應用也較少，所以說如果要在一些面向使用者量很大，講求使用者體驗的App中使用還是要慎重考慮的。
但是，其實Facebook已經在自家的App上用起來了，而且實測效果還是很好的。不過呢，人家畢竟是自家維護的，所以說真正要在專案上用可能還是得試了才知道效果。
facebook Androidfacebook iOS
4、原生應用
原生應用的開發真的是讓人又愛又恨。愛在於你可以在它上面施展拳腳、使用新特性、實現炫酷的效果。而恨則在於它跨平臺性幾乎為零，除了資源外幾乎沒有可重用的東西，即使是相似架構上的邏輯你也得再實現一遍。使用原生開發，能夠方便地新增動畫效果，呼叫底層硬體，所有的限制僅僅是來自平臺的限制。但是正常情況下需要對不同的平臺搭配不同的開發人員，而且如果要追求良好的使用者體驗，整個應用的設計還得滿足相應平臺的設計規範，這不僅是對Dev的考驗，也是對UX的考驗。不過如果真的對App的質量有很高的要求，我覺得這一切的付出也還是都是值得的。
如果針對的是要求硬體效能、講究動畫效果、追求使用者體驗的應用，還是建議分平臺單獨設計，並且都使用原生的技術方案來實現。其實這也是目前市面上大部分企業做出的選擇。
使用原生開發我個人還有一個觀點，就是設計上要儘量遵守原生應用的設計規範，如果想要一套設計通吃所有平臺，最終只會搞一個不倫不類的應用出來。知乎算是國內在這方面做得比較好的應用了，也取得了不錯的效果。
知乎
其實，在真正啟動專案之前，在進行技術選型時，除了要考慮更符合業務的架構外，還要考慮開發人員的能力及技術棧。畢竟最後App還是由Dev們開發的。如果僅僅考慮業務而不考慮開發人員的技術能力來選擇技術方案，不僅有一種欽定的感覺，而且最後往往坑到的還是自己。
我們常說：工具是死的，人是活的。考慮多種因素，在技術選型上做出更充分的考量，才是真正正確的選擇。所以說又回到那句老話上：“It depends…”