史兆彥, 李 翔

(中遠海運科技股份有限公司，上海 200135)

0 引 言

移動硬件技術(shù)、移動通信技術(shù)和互聯(lián)網(wǎng)技術(shù)的迅猛發(fā)展使得移動應用得到迅速普及和快速發(fā)展。據(jù)統(tǒng)計[1]，截至2017年底，每個智能手機用戶的平均APP數(shù)量達到40個以上，平均每天花費在各類APP上的時間達到約4.2 h。因此，對于企業(yè)品牌的宣傳、產(chǎn)品的推廣和服務的擴展而言，除了開發(fā)傳統(tǒng)的管理系統(tǒng)和網(wǎng)站以外，移動用戶的接入是企業(yè)應用無法忽略的重要組成部分[2]。

然而，移動設備(特別是手機)操作系統(tǒng)的不同使得開發(fā)移動應用的技術(shù)不盡相同。對于企業(yè)而言，面對諸多的應用類型和開發(fā)技術(shù)，沒有現(xiàn)成的指導策略可供參考。因此，本文對移動應用的分類、開發(fā)模式、技術(shù)路線和開發(fā)團隊等因素進行相關(guān)探討，為企業(yè)移動應用開發(fā)技術(shù)選型提供策略參考。

1 移動應用開發(fā)技術(shù)的發(fā)展現(xiàn)狀

根據(jù)NETMAKETSHARE的統(tǒng)計數(shù)據(jù)[3]，Android和iOS已占據(jù)手機操作系統(tǒng)98%以上的市場。由于Android和iOS的開發(fā)技術(shù)完全不同，早期很多企業(yè)必須針對這2個平臺開發(fā)具有相同功能的APP，會耗費大量的人力和財力資源，增加開發(fā)和維護成本。

為解決該“不一致”帶來的問題，出現(xiàn)諸多跨平臺的移動應用開發(fā)技術(shù)，其中基于HTML5的移動開發(fā)技術(shù)得到廣泛認可，即開發(fā)一套移動Web頁面，用戶可通過瀏覽器訪問移動Web頁面，但系統(tǒng)的性能和用戶體驗與原生應用(Native APP)有本質(zhì)上的差別。在此情況下，基于HTML5的混合移動開發(fā)技術(shù)(Hybrid APP)開始出現(xiàn)，其本質(zhì)是將一個Web應用嵌入到Native APP中。然而，Hybrid APP的性能與Native APP依然有著不小的差距，“用戶體驗”的更高要求催生出新的跨平臺移動開發(fā)技術(shù)，以React Native技術(shù)為代表的基于JavaScript的Native開發(fā)技術(shù)應運而生，其本質(zhì)是在APP運行時通過JavaScript調(diào)用原生功能完成操作，性能幾乎與Native APP相同；同時，統(tǒng)一的開發(fā)語言、一次編寫、分別編譯和多端運行等特性使得跨平臺移動應用開發(fā)方面的問題幾乎能全部解決。

2 移動應用開發(fā)模式的分類比較

目前應用程序基本上分為4種模式，其中：第一種是需安裝的Native APP模式；第二種是借助手機瀏覽器運行的網(wǎng)頁應用(Web APP)模式；第三種是融合上述2種模式得到的混合模式(Hybrid APP)，這種APP雖然也需獨立安裝，但部分功能是借助內(nèi)置瀏覽器Web頁面運行的。近年來，隨著移動應用用戶的大量累積，有些移動應用本身轉(zhuǎn)變成了應用平臺，在此基礎上發(fā)展出基于特定應用擴展方式的寄生模式，即無需獨立安裝新的應用，依賴于特定的應用環(huán)境運行，如支付寶應用和微信小程序等。表1為這些移動應用類型的對比[4-6]。

3 移動應用開發(fā)技術(shù)棧的分類比較

不同的移動應用類型在實現(xiàn)方式上對應著不同的應用開發(fā)技術(shù)棧，主要包括傳統(tǒng)模式、Bridge模式和寄生模式等3種。

3.1 傳統(tǒng)模式的技術(shù)棧

與傳統(tǒng)PC應用開發(fā)模式類似，針對不同應用類型采取不同的開發(fā)方案。Native模式對應Native APP的開發(fā)，需針對不同的平臺使用不同的開發(fā)語言和工具,乃至設備。Web模式對應Web APP的開發(fā)，使用HTML5等Web開發(fā)技術(shù)實現(xiàn)，針對移動設備的特點，一般采用適于移動設備的前端Web框架或基礎組件庫。Hybrid模式對應Hybrid APP的開發(fā)，使用Web技術(shù)和少量的Native技術(shù)實現(xiàn)。國內(nèi)的AppCan框架是一個比較出色的Hybrid框架[10];Ionic是當前廣泛采用的Hybrid框架，通過Cordova將一個Web應用嵌入到Native APP中。

3.2 Bridge模式的技術(shù)棧

Bridge模式是使用第三方開發(fā)語言編寫Native APP的方式,本文為區(qū)分與Hybrid APP實現(xiàn)方式的差異，將其稱為Bridge模式。該模式的實現(xiàn)思想在Hybrid APP的設計中就已形成。在Hybrid APP中,Web頁面與Native之間存在一種稱為JSBridge的通信機制，可實現(xiàn)Web頁面與Native功能的互操作；Bridge模式將其進一步發(fā)展，摒棄使用Web View渲染的做法，改用Bridge的方式調(diào)用原生功能，使用一種語言編寫跨平臺APP，抽象出與平臺無關(guān)的業(yè)務代碼實現(xiàn)通用，基本上實現(xiàn)“一次編寫，分別編譯，多端運行”的開發(fā)部署模式。Bridge模式目前有2種代表性的實現(xiàn)方案，即基于C#的Xamarin方案和基于JavaScript的Native解決方案。

1) 基于C#的Xamarin跨平臺移動開發(fā)解決方案[7]由Mono發(fā)展而來，Xamarin包含Xamarin.Android、Xamarin.iOS和Xamarin.Forms，其本質(zhì)上是對原生API做一層C#的封裝。Xamarin的開發(fā)思路是使用C#完成通用的、與平臺無關(guān)的邏輯部分，針對不同平臺UI和交互方式，使用API訪問和操控Native組件，實現(xiàn)不同平臺的UI開發(fā)。

2) 基于JavaScript的Native開發(fā)技術(shù)是使用JavaScript,通過JSBridge調(diào)用原生組件。不同于Hybrid使用Web View,該模式的頁面代碼由JavaScript 引擎處理，并管理渲染Native視圖，調(diào)用原生 API 和用戶交互。該模式的代表是Facebook的React Native技術(shù)[8]。國內(nèi)阿里巴巴的Weex也采用這種技術(shù)路線[9]，其在頁面渲染上跳出瀏覽器環(huán)境, 既擁有原生Native的交互體驗，又能保持Web高效和靈活的特點，支持跨平臺,通過JavaScript調(diào)用原生平臺標準組件，使APP獲得平臺一致的效果和體驗，有著媲美Native的性能和流暢性。

表1 移動應用類型對比

3.3 寄生模式的技術(shù)棧

寄生模式主要實現(xiàn)基于宿主APP的功能擴展開發(fā)，依賴于宿主APP本身的功能。以微信公眾平臺[11]為例，分為微頁面模式和小程序模式，2種模式都是基于微信的跨平臺方案。

1) 微信服務號和訂閱號除了提供交互轉(zhuǎn)發(fā)服務以外，還提供頁面嵌入功能，在開發(fā)頁面時，可調(diào)用微信API實現(xiàn)部分原生功能，頁面代碼運行在微信內(nèi)置的瀏覽器中，這種方式可看作是基于微信的Hybrid模式。

2) 微信小程序使用JSBridge,通過微信調(diào)用本地資源，在體驗上優(yōu)于訂閱號和服務號，具有Native APP體驗。小程序開發(fā)框架提供有視圖層描述語言WXML和WXSS及基于JavaScript的邏輯層框架，并在視圖層與邏輯層之間提供有數(shù)據(jù)傳輸和事件系統(tǒng)，這種方式可看作是基于微信的Bridge模式。

3.4 開發(fā)模式的技術(shù)棧比較

開發(fā)模式并沒有優(yōu)劣之分，選擇哪種開發(fā)模式與企業(yè)產(chǎn)品的要求、產(chǎn)品定位、開發(fā)周期和團隊技術(shù)人員的技術(shù)積累有很大關(guān)系。企業(yè)需根據(jù)自身條件進行選擇，表2為移動開發(fā)模式的技術(shù)棧比較。

表2 移動開發(fā)模式的技術(shù)棧比較

4 移動應用開發(fā)技術(shù)選型策略

移動應用的類型選擇確定了其開發(fā)模式，開發(fā)模式的確定影響著技術(shù)棧的選擇，技術(shù)棧的選擇影響著開發(fā)團隊的建設；反之，開發(fā)團隊的技術(shù)積累會影響技術(shù)選型和開發(fā)模式，進而影響移動應用的類型選擇。

4.1 移動應用開發(fā)技術(shù)棧參考架構(gòu)

移動應用開發(fā)技術(shù)棧主要是框架和組件庫的選型，架構(gòu)師的主要工作已從原來的實現(xiàn)技術(shù)框架(加法)轉(zhuǎn)變?yōu)閺暮Ａ考夹g(shù)中選擇最合適的技術(shù)組件(減法)。企業(yè)的移動開發(fā)團隊需對移動應用的類型和技術(shù)領域進行分析，結(jié)合團隊自身的技術(shù)積累和可能的投入總結(jié)出一套應對移動開發(fā)模式的技術(shù)棧。圖1為移動開發(fā)技術(shù)棧參考模型，針對不同類型的開發(fā)模式，給出相應的技術(shù)選擇域，對技術(shù)團隊建設具有指導意義。

技術(shù)棧模型選擇以React Native技術(shù)為核心，同時融合HTML5的移動前端解決方案，兼顧微信平臺的開發(fā)，具有以下特點：

1) React Native采用JavaScript語言，前端開發(fā)人員可通過培訓快速投入開發(fā)；

2) 跨移動平臺適配能力，基于React Native，通過封裝或引入基礎組件形成基礎組件庫，實現(xiàn)“一次編寫，分別編譯，多端運行”的跨平臺目標；

3) React Native的機制能實現(xiàn)與Native APP的集成和代碼混編，為集成歷史組件和應對性能需求提供實現(xiàn)方式；

4) 為應對快速變化的場景，參照Hybrid APP的思想提出RN Bridge的思路，融合前端開發(fā)技術(shù)，使用基于React Native的Web View渲染可變更界面，UI混搭取長補短，發(fā)揮Native和HTML5各自的優(yōu)勢應對功能頻繁變更的需求；

5) 微信平臺的開發(fā)依賴于微信的接口，經(jīng)過適配，訂閱號和服務號的開發(fā)可共用RN Bridge的Web頁面。

4.2 選型策略參考模型

針對移動開發(fā)諸多的模式選擇和技術(shù)棧，如何找到最適合本企業(yè)的開發(fā)技術(shù)是移動開發(fā)團隊最關(guān)心的問題。圖2為選型策略參考模型，使用決策樹模式展示。企業(yè)可根據(jù)自身團隊的特點和技術(shù)積累，參照參考模型選擇技術(shù)棧。圖2中，箭頭上的條件決定著選擇路徑的走向。參考模型中并未囊括所有的選擇可能和開發(fā)技術(shù)，可根據(jù)實際條件和技術(shù)偏好添加或移除相關(guān)分支。

參考模型將應用類型、開發(fā)模式和實現(xiàn)技術(shù)結(jié)合起來，從高層級的應用類型分類到低層級實現(xiàn)技術(shù)，清晰展示了技術(shù)選型的路徑走向。

4.3 選型的綜合因素

技術(shù)因素與技術(shù)團隊的建設互為影響，技術(shù)選型影響著開發(fā)團隊的技術(shù)組成和技術(shù)積累，同時團隊現(xiàn)有的技術(shù)積累和人員配置又影響著技術(shù)選型。企業(yè)在做移動應用時，通常需同時考慮用戶對應用的功能性和非功能性需求指標, 而非單純的技術(shù)因素，下面對一些影響選型的限制因素進行分析。

1) 平臺要求：應用運行的目標平臺確定針對平臺差異采取的應對策略，確定是選擇使用針對平臺的差異化開發(fā)的原生技術(shù)還是跨平臺技術(shù)。

2) 性能要求：性能要求越高，對硬件的利用和操控能力的要求越高，調(diào)用底層的中間步驟就要越少?？缙脚_的解決方案幾乎都是以損失性能換取的，但跨平臺的優(yōu)勢同樣非常明顯。

3) UI交互模式：對于不同的操作系統(tǒng)，UI交互的特點不完全一致，需考慮在交互模式上是采用多平臺一致的模式還是采用契合不同平臺的交互特點的方式。

4) 投入成本：采用不同的技術(shù)實現(xiàn)同樣的功能所需的人力成本和時間成本是不同的。

5) 研發(fā)周期：時間因素是項目的一個重要影響因素，研發(fā)周期越長，越有時間研究，但大多數(shù)項目都是盡量壓縮工期。因此，在保證其他因素盡量不受影響的前提下,采用最快的開發(fā)模式是第一選擇。

6) 變更頻度：Native程序很難實現(xiàn)在線更新，應用變更越頻繁，越傾向選擇能在線更新的開發(fā)模式,甚至是Web方式。

7) 業(yè)務類型：業(yè)務類型不同，應用的受眾不同，推廣模式也不相同，若非必要，用戶更傾向于不安裝新的APP。因此，若要快速推廣，借助現(xiàn)有的微信公眾平臺或支付寶擴展程序是可行的。

8) 團隊技術(shù)儲備：現(xiàn)有開發(fā)人員的技術(shù)儲備往往影響著應用實現(xiàn)技術(shù)的選擇，前端開發(fā)人員會選擇與前端開發(fā)相近的技術(shù)。同樣，技術(shù)的選擇影響著團隊人才隊伍的建設。

9) 社區(qū)資源：遇到的問題能否通過社區(qū)資源得到解決，一般流行程度越高的框架，獲得答案的可能性越大。

這些影響選型的因素可歸類為目標環(huán)境(平臺、性能和UI交互)、成本約束(成本、研發(fā)周期)、業(yè)務需求(業(yè)務類型、更新頻度)和技術(shù)儲備(團隊儲備、社區(qū)資源)等，開發(fā)團隊需根據(jù)需求識別出核心的影響因素，選定應用類型，進而綜合考慮其他因素，參照選型策略參考模型選擇開發(fā)模式和具體的實現(xiàn)技術(shù)。

5 結(jié) 語

本文基于“沒有最好的技術(shù)，只有最適合的技術(shù)”的思路，給出一種選型策略參考模型。移動應用開發(fā)技術(shù)的選型是一個多因素權(quán)衡的過程，本文僅提供一種基于開發(fā)技術(shù)的選型思路。面對眾多的開源組件和框架，開發(fā)人員需有效識別需求，選擇最適合的開發(fā)技術(shù)，完成開發(fā)模式和技術(shù)棧選型。