在這個巨變的時代，技術選型是個很難做決定的事情，而移動應用技術領域在幾個巨頭（Google，F(xiàn)acebook虚茶，Apple etc.）的帶動下更是日新月異。所以說要選擇一個適合業(yè)務需求并且匹配開發(fā)人員能力的技術方案并不是一件簡單的事情仇参。我也只是在移動開發(fā)上做過一點微小的工作嘹叫，此處僅能拋個磚，希望各位有玉的大神盡管砸過來诈乒。
做移動應用開發(fā)罩扇，說起來技術方案不外乎HTML5（沒錯，做Mobile Web其實也算是一種移動應用）、Native（在Android上不管是用Java喂饥、Kotlin還是Scala消约，iOS上不管是用Objective-C還是Swift）和使用原生UI，用JavaScript來實現(xiàn)邏輯的諸如React Native一類的方案员帮。除此之外或粮，還有結(jié)合HTML5和Native的Hybird混合方案。不同的技術方案有著不同的適應場景捞高，至于具體如何選擇氯材，接下來我簡單地談談自己的理解。
1硝岗、HTML5
也就是Web App的方案氢哮。這種方案最大的優(yōu)點在于“Write Once, Run Everywhere”，不管你是Android還是iOS型檀，都可以用一套代碼搞定冗尤，在國內(nèi)的話還能對接微信公眾號，給用戶提供一個方便快捷的入口贱除，并且還有版本升級容易的優(yōu)勢（畢竟服務器是受自己控制的）生闲。但是這種方案的缺點也很明顯——無法使用系統(tǒng)級API，只能做為一個臨時的入口月幌，用戶很難留存碍讯，并且因為瀏覽器性能的原因，很難帶來很好的用戶體驗扯躺。
所以說Web App的主要適用場景還是在于作為對非核心業(yè)務在移動端的入口補足捉兴，或者是作為用戶輕量、低頻使用的體驗增強录语。
美團移動網(wǎng)站引導頁
美團移動網(wǎng)站首頁
美團的移動網(wǎng)頁就是很典型的例子倍啥，主要還是提供給不經(jīng)常使用的用戶一個入口，網(wǎng)站內(nèi)部還是在盡量引導用戶下載使用客戶端澎埠。
2虽缕、Hybird
Hybird是一種兼顧Native與HTML的開發(fā)模式，但根據(jù)實現(xiàn)的不同蒲稳，還可以再細分為兩種實現(xiàn)方案：
- 在Native App中使用WebView加載遠端Web資源
- 使用Cordova/PhoneGap等框架通過WebView加載本地資源進行頁面渲染
第一種方案其實已經(jīng)應用得非常普遍了氮趋，很多應用的展示頁面都是通過這種方式實現(xiàn)的。因為展示頁面需要的正是能夠輕易更換內(nèi)容及布局的格式江耀，并且這種純展示的頁面也并不需要復雜的動畫與特效剩胁，使用Web頁面是一個非常合適的解決方案。
而第二種方案前一段時間非诚楣火昵观，因為它在跨平臺，在高效開發(fā)以及快速發(fā)布上有著明顯的優(yōu)勢，畢竟Web內(nèi)容只需要開發(fā)一次就可以在各個平臺使用啊犬。而且將資源打包到本地也可以在一定程度上緩解從遠端加載靜態(tài)資源導致UI展示延遲的問題灼擂，并且還可以通過橋接Native和Web來調(diào)用一些Device的API。但其劣勢也很明顯觉至，一是通過WebView執(zhí)行代碼效率較低缤至，很難實現(xiàn)一些炫酷的效果，并且還存在不同設備的兼容性問題康谆；二是如果想調(diào)用相關平臺的API，需要針對平臺單獨進行開發(fā)嫉到，如果在應用中用到了大量的Device API沃暗，那么開發(fā)的效率將大大降低；三是很難應用到平臺相關的新特性何恶，比較難做出有特色的產(chǎn)品孽锥。
使用HTML頁面來實現(xiàn)純展示頁面是非常推薦的一種方案。而Cordova/PhoneGap則更適用于對Mobile預算有限的公司细层、創(chuàng)業(yè)團隊惜辑，或者對App進行快速的上線驗證。
正好之前有個項目就用到了這種方案疫赎，為一家業(yè)務轉(zhuǎn)型的零售商提供了使用一套基本代碼來完成Android和iOS兩個平臺的App和微信公眾號的相關頁面的技術方案盛撑。
零售商Android應用零售商微信端
3、React Native
把React Native單獨拿出來捧搞，是因為確實不能簡單的將它分到其它任意一種方案里面去抵卫。React Native確實是最近最火的跨平臺App解決方案了。它脫胎于React胎撇，因為React基于Virtual DOM來進行界面渲染介粘，所以用Native的View來替換掉原本React的HTML DOM就順理成章的引出了React Native的概念。
它與之前的跨平臺方案有一個本質(zhì)的區(qū)別晚树，在于：其它方案都在追求寫一次code解決所有平臺的問題姻采，而React Native的理念在于“Learn Once, Write Anywhere”。雖然大部分代碼是平臺無關的爵憎，但是平臺相關的代碼都需要單獨實現(xiàn)慨亲，這雖然對跨平臺帶來了不便，但是引入的好處也是顯而易見的纲堵，View層的部分通過原生組件實現(xiàn)巡雨，性能比其他WebView的方案不知道高到哪去了。而且React Native整套的邏輯代碼都通過JavaScript實現(xiàn)席函，這樣就讓跨平臺應用能夠方便的復用邏輯代碼铐望。另外雖然React Native沒有支持使用CSS來實現(xiàn)樣式，但是提供了類似CSS的樣式表支持，有過UI開發(fā)經(jīng)驗的人都能夠非痴埽快的上手督弓。由于前端React也是非常的火，很多React社區(qū)的很多產(chǎn)出都可以在React Native上借鑒使用乒验。
React Native對于沒有復雜動畫效果的一般應用來說不失為一個很好的解決方案愚隧。而且對于一些小型的企業(yè)級應用也是非常適用的。但是锻全，React Native對于Android平臺的支持度是不如iOS平臺的狂塘，而且現(xiàn)有的非常成熟的應用也較少，所以說如果要在一些面向用戶量很大鳄厌，講求用戶體驗的App中使用還是要慎重考慮的荞胡。
但是，其實Facebook已經(jīng)在自家的App上用起來了了嚎，而且實測效果還是很好的泪漂。不過呢，人家畢竟是自家維護的歪泳，所以說真正要在項目上用可能還是得試了才知道效果萝勤。
facebook Androidfacebook iOS
4、原生應用
原生應用的開發(fā)真的是讓人又愛又恨呐伞。愛在于你可以在它上面施展拳腳敌卓、使用新特性、實現(xiàn)炫酷的效果荸哟。而恨則在于它跨平臺性幾乎為零假哎，除了資源外幾乎沒有可重用的東西，即使是相似架構(gòu)上的邏輯你也得再實現(xiàn)一遍鞍历。使用原生開發(fā)舵抹，能夠方便地添加動畫效果，調(diào)用底層硬件劣砍，所有的限制僅僅是來自平臺的限制惧蛹。但是正常情況下需要對不同的平臺搭配不同的開發(fā)人員，而且如果要追求良好的用戶體驗刑枝，整個應用的設計還得滿足相應平臺的設計規(guī)范香嗓，這不僅是對Dev的考驗，也是對UX的考驗装畅。不過如果真的對App的質(zhì)量有很高的要求靠娱，我覺得這一切的付出也還是都是值得的。
如果針對的是要求硬件性能掠兄、講究動畫效果像云、追求用戶體驗的應用锌雀，還是建議分平臺單獨設計，并且都使用原生的技術方案來實現(xiàn)迅诬。其實這也是目前市面上大部分企業(yè)做出的選擇腋逆。
使用原生開發(fā)我個人還有一個觀點，就是設計上要盡量遵守原生應用的設計規(guī)范侈贷，如果想要一套設計通吃所有平臺惩歉，最終只會搞一個不倫不類的應用出來。知乎算是國內(nèi)在這方面做得比較好的應用了俏蛮，也取得了不錯的效果撑蚌。
知乎
其實，在真正啟動項目之前搏屑，在進行技術選型時锨并，除了要考慮更符合業(yè)務的架構(gòu)外，還要考慮開發(fā)人員的能力及技術棧睬棚。畢竟最后App還是由Dev們開發(fā)的。如果僅僅考慮業(yè)務而不考慮開發(fā)人員的技術能力來選擇技術方案解幼，不僅有一種欽定的感覺抑党，而且最后往往坑到的還是自己。
我們常說：工具是死的撵摆，人是活的底靠。考慮多種因素特铝，在技術選型上做出更充分的考量暑中，才是真正正確的選擇。所以說又回到那句老話上：“It depends…”
