移動應用開發技術選型策略

史兆彥, 李 翔

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

0 引 言

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

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

1 移動應用開發技術的發展現狀

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

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

2 移動應用開發模式的分類比較

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

3 移動應用開發技術棧的分類比較

不同的移動應用類型在實現方式上對應著不同的應用開發技術棧，主要包括傳統模式、Bridge模式和寄生模式等3種。

3.1 傳統模式的技術棧

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

3.2 Bridge模式的技術棧

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

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

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

表1 移動應用類型對比

3.3 寄生模式的技術棧

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

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

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

3.4 開發模式的技術棧比較

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

表2 移動開發模式的技術棧比較

4 移動應用開發技術選型策略

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

4.1 移動應用開發技術棧參考架構

移動應用開發技術棧主要是框架和組件庫的選型，架構師的主要工作已從原來的實現技術框架(加法)轉變為從海量技術中選擇最合適的技術組件(減法)。企業的移動開發團隊需對移動應用的類型和技術領域進行分析，結合團隊自身的技術積累和可能的投入總結出一套應對移動開發模式的技術棧。圖1為移動開發技術棧參考模型，針對不同類型的開發模式，給出相應的技術選擇域，對技術團隊建設具有指導意義。

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

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

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

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

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

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

4.2 選型策略參考模型

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

參考模型將應用類型、開發模式和實現技術結合起來，從高層級的應用類型分類到低層級實現技術，清晰展示了技術選型的路徑走向。

4.3 選型的綜合因素

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

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

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

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

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

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

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

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

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

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

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

5 結 語

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