基于小程序框架的跨平臺開發(fā)研究和實踐

寧肖

（中海油信息科技有限公司數(shù)字技術(shù)中心 天津市 300452）

1 現(xiàn)有移動應(yīng)用開發(fā)模式分析

常見的開發(fā)模式包括原生開發(fā)、B/S 模式開發(fā)、跨平臺框架應(yīng)用開發(fā)。

1.1 原生開發(fā)

原生應(yīng)用開發(fā)模式，其特征是產(chǎn)出品可作為獨立可執(zhí)行的程序直接運行在操作系統(tǒng)上。由于客戶端應(yīng)用和操作系統(tǒng)銜接更為緊密，故一般流暢度較高，能獲得較好的用戶體驗，但通常需要采用操作系統(tǒng)支持的原生開發(fā)語言和框架來完成，原生開發(fā)方式為了提供各種強大能力一般都會比較復(fù)雜，學(xué)習(xí)曲線陡峭，且不同的操作系統(tǒng)提供的原生開發(fā)語言、框架都不盡相同，如：蘋果iOS 平臺采用 Objective-C 語言或Swift 語言進行開發(fā)，Android 平臺采用 Java 或 Kotlin 語言，PC 平臺可選擇的余地較多，如：C/C++/.NET/Java 等語言，界面框架涉及 Qt/Gtk/Win32/MFC/wxWidgets 等，且框架形式分為跨平臺及平臺專有[1]，因此為打造全平臺可用應(yīng)用，企業(yè)需組建一系列專業(yè)技術(shù)開發(fā)人員針對不同平臺編寫代碼，同時應(yīng)兼顧各平臺的體驗接近、邏輯一致，從而開發(fā)效率十分低下。在大型企業(yè)持續(xù)發(fā)展建設(shè)中，應(yīng)用數(shù)量多，需求變化快，若采用原生開發(fā)模式，投入的成本及時間也將隨之攀升[2]。

1.2 B/S模式應(yīng)用

B/S 架構(gòu)是指應(yīng)用界面部分采用 HTML/Javascript等語言開發(fā)，并運行在瀏覽器中的應(yīng)用。B/S 架構(gòu)發(fā)展至今，由于標準統(tǒng)一[1]，且各平臺的瀏覽器都能提供較好的支持，設(shè)計界面美觀，開發(fā)效率高，一次開發(fā)，多平臺適用，目前大部分企業(yè)桌面系統(tǒng)均會采用 B/S 架構(gòu)進行系統(tǒng)開發(fā)。然而B/S 架構(gòu)也存在明顯缺點，首先對于離線使用場景，由于緩存 API 未統(tǒng)一標準，無法支持所有平臺，且存在較多限制條件，比如使用空間大小限制，僅支持 GET 請求的緩存；其次，在移動終端用戶普遍適應(yīng)獨立應(yīng)用的使用方式，不習(xí)慣使用瀏覽器訪問應(yīng)用程序，且H5 性能在不同的終端上差異較大，對移動設(shè)備配置要求較高，利用 JS 實現(xiàn)過場動畫可能會出現(xiàn)卡幀、丟幀而造成用戶體驗較差的問題[3]。故B/S 架構(gòu)存在應(yīng)用場景受限的問題，如：在嵌入式設(shè)備上使用的工業(yè)應(yīng)用，有離線使用場景的閱讀、學(xué)習(xí)類移動應(yīng)用，需要離線編輯在線同步的郵件類應(yīng)用以及希望使用操作系統(tǒng)更多能力且獲得良好交互體驗的應(yīng)用等。

1.3 跨平臺框架

為了解決在不同平臺開發(fā)不同代碼的問題，一些公司推出了跨平臺框架的概念，目的是編寫一次代碼可實現(xiàn)在多個不同的平臺上發(fā)布程序，提升開發(fā)效率?？缙脚_框架主要包括中間語言編譯模式和基于H5 的混合開發(fā)模式。

1.3.1 中間語言編譯模式

主要代表有：Facebook 公司推出的 ReactNative 框架，Google 公司推出的 Flutter,微軟公司的 Xamarin,NativeScript 等，其主要特點是不依賴 H5 技術(shù)，而是采用一種中間語言進行業(yè)務(wù)邏輯的開發(fā)，編譯打包為不同目標平臺的應(yīng)用，如 ReactNative 采用 Javascript，F(xiàn)lutter 采用了 Durt 語言，為了調(diào)用操作系統(tǒng)提供的能力也需要利用原生語言開發(fā)一些插件開放給中間語言調(diào)用。這些框架的出現(xiàn)減少了跨平臺開發(fā)的工作，對于需求簡單的場景，往往只需要編寫中間語言實現(xiàn)業(yè)務(wù)邏輯而無需考慮平臺間差異。然而也存在一些不足。首先，這些框架均為第三方公司產(chǎn)品，與原生開發(fā)之間存在著差異和滯后性，需伴隨原生平臺升級進行適配；其次，此類框架主要為移動平臺量身定制，對于桌面和 Web 端的開發(fā)支持能力有限，如果需要使用更多的原生功能或集成第三方的原生庫或組件，則仍然需要熟悉各個平臺的原生開發(fā)；再次，基于該類框架開發(fā)對開發(fā)生態(tài)依賴較重，插件大多來源于互聯(lián)網(wǎng)，很多插件的質(zhì)量難以保證，更新和版本沖突問題時有發(fā)生，將會對開發(fā)造成一定影響。

1.3.2 基于H5 的混合開發(fā)模式

混合開發(fā)是指在原生應(yīng)用的基礎(chǔ)上利用 H5 技術(shù)制作界面，利用原生開發(fā)模塊實現(xiàn)系統(tǒng)功能調(diào)用的開發(fā)模式。代表的框架有 Apache Codova 和 Adobe PhoneGap 等，混合開發(fā)的優(yōu)點是直接采用前端開發(fā)人員熟悉的 H5 技術(shù)來制作界面，繼承B/S 開發(fā)模式的大部分優(yōu)點，且無需學(xué)習(xí)，開發(fā)效率比中間語言模式還高。但仍存在以下不足，目前前框架大部分都采用了單頁應(yīng)用的模式[2]，頁面間的過場動畫由 H5 制作不能保證在低端設(shè)備上的交互體驗。另外平臺能力交互部分同樣需要原生插件的支持，且中間語言框架的生態(tài)問題它也同樣存在。

2 基于混合開發(fā)的企業(yè)內(nèi)部小程序平臺

原生開發(fā)、B/S 模式開發(fā)、跨平臺框架應(yīng)用開發(fā)側(cè)重不同、各有優(yōu)缺點，面對不同的應(yīng)用場景，選擇正確的開發(fā)方式十分重要。對于企業(yè)內(nèi)部應(yīng)用來說，大部分企業(yè)將開發(fā)成本、可維護性、靈活性、健壯性、是否覆蓋使用場景等因素作為重要指標。綜上分析可見，使用跨平臺框架，在開發(fā)效率、成本及用戶體驗方面均存在較好的表現(xiàn)，但使用第三方框架仍然存在潛在的風險：

（1）框架無法自主，個性化需求通過修改或擴展框架實現(xiàn)的可行性較低；

（2）使用權(quán)存在風險，修改開源協(xié)議事件易引發(fā)業(yè)界爭議[3]；

（3）原生交互依賴插件生態(tài)，開發(fā)質(zhì)量不可控。

為了解決上述問題，集團公司考慮對移動應(yīng)用建設(shè)進行統(tǒng)一管控，搭建自主可控的跨平臺移動應(yīng)用開發(fā)框架，在統(tǒng)一規(guī)劃、統(tǒng)一管控模式下，進行平臺基礎(chǔ)能力建設(shè)，各單位/業(yè)務(wù)基于平臺可專注業(yè)務(wù)邏輯實現(xiàn)高效快速建設(shè)，避免出現(xiàn)粗放式建設(shè)，為更好進行集團統(tǒng)一管理奠定技術(shù)基礎(chǔ)，提升企業(yè)資源整合及優(yōu)化。對比中間語言編譯模式框架和混合開發(fā)框架，可知混合開發(fā)可更好支撐集團型企業(yè)移動應(yīng)用建設(shè)需求，實現(xiàn)開發(fā)效率高、用戶體驗佳、資源統(tǒng)籌率高。

2.1 設(shè)計目標

我們把企業(yè)內(nèi)混合應(yīng)用開發(fā)的應(yīng)用稱為內(nèi)部小程序。小程序平臺的優(yōu)勢如下：

（1）支持跨平臺，目標平臺有：Android、iOS、Windows、Macos、Linux、Web，滿足辦公場景常用平臺需求；

（2）混合開發(fā)，允許使用現(xiàn)有 web 技術(shù)，不限定UI 框架；

（3）支持一個框架多個應(yīng)用的模式，小程序支持預(yù)置安裝和應(yīng)用商店下載；

（4）小程序可按需下載自動更新，版本升級簡單高效，節(jié)省流量，減少對用戶的打擾；

（5）支持多用戶模式，不同賬號使用的小程序版本可以不同；

（6）小程序之間支持互相調(diào)用通訊；

（7）支持后臺任務(wù)，支持離線使用；

（8）設(shè)計可參照主流互聯(lián)網(wǎng)應(yīng)用，提高用戶體驗。

2.2 架構(gòu)設(shè)計

小程序框架分為前臺應(yīng)用和后臺管理端兩部分，前臺由宿主應(yīng)用和SDK 組件組成，宿主應(yīng)用每個目標平臺需要有一個獨立實現(xiàn)，SDK 組件為 Javascript 模塊，被小程序打包引用作為小程序和宿主應(yīng)用的橋梁，小程序通過調(diào)用 SDK 提供的接口和宿主應(yīng)用以及其他小程序進行交互。后臺部分是小程序管理后臺并暴露接口給宿主應(yīng)用，提供小程序的發(fā)布、更新、權(quán)限管理等功能。整體架構(gòu)如圖1所示。

圖1：系統(tǒng)架構(gòu)

2.3 架構(gòu)和工作方式說明

2.3.1 原生外殼

小程序需要運行在原生外殼應(yīng)用中，對于不同的操作系統(tǒng)，平臺需要單獨開發(fā)不同的外殼應(yīng)用，對于移動應(yīng)用可以使用平臺提供的原生語言進行開發(fā)，對于 PC平臺和 Web 平臺，考慮代碼共用，可以采用 H5 技術(shù)制作界面的框架進行開發(fā)，比如 Electron 或基于 Rust 的Tauri 框架。外殼應(yīng)用使用原生系統(tǒng)的 WebView 加載小程序頁面，初始化階段會注入原生接口到頁面空間，一個應(yīng)用可以包含多個小程序，一個小程序可以包含多個頁面。頁面間導(dǎo)航由外殼應(yīng)用負責，可以保證過場動畫的流暢性。外殼程序可以打包若干預(yù)置的小程序，以滿足基本的使用，額外的小程序可以通過網(wǎng)絡(luò)接口下載后使用。

2.3.2 Web 端部署

小程序以 H5 技術(shù)為基礎(chǔ)實現(xiàn)，可以部署為 WEB應(yīng)用，利用 Electron 等桌面平臺開發(fā)避免使用前端頁面注入的方式添加對 SDK 接口的支持，需采用后臺生成頁面的方式將接口封裝后發(fā)送至前端，從而實現(xiàn) PC 和Web 平臺一套代碼，多端運行。

2.3.3 Javascript 橋接層接口

橋接層是原生系統(tǒng)模塊暴露給小程序頁面的調(diào)用入口，移動平臺一般由系統(tǒng) WebView 提供注入接口，在PC 和 Web 端可以使用遠程過程調(diào)用的方式注入接口。

2.3.4 SDK

SDK 封裝了對原生橋接層接口的調(diào)用，以及接口文檔的說明，橋接層接口往往各個平臺的實現(xiàn)不同，提供的調(diào)用方式偏底層，SDK 負責把調(diào)用統(tǒng)一化，文檔化，小程序開發(fā)者不需要了解底層實現(xiàn)，只需要引入 SDK并了解 SDK 提供的接口即可[4]。

2.3.5 管理后臺

管理后臺提供小程序的注冊、發(fā)布、版本升級和權(quán)限管理的功能，結(jié)合企業(yè)內(nèi)用戶賬號體系及權(quán)限體系，實現(xiàn)小程序訪問權(quán)限及版本升級管理。通過后臺管理配置實現(xiàn)小程序的發(fā)布主要功能，（包括但不限于）基本信息配置，包括配置應(yīng)用程序ID、小程序名稱、小程序標簽等小程序發(fā)布基本信息；版本管理配置，包括配置小程序進行版本升級；目標應(yīng)用配置，包括控制小程序上架及下架；小程序管理員配置，包括配置小程序管理員、機構(gòu)白名單配置、用戶白名單配置等。

2.3.6 設(shè)計原則

小程序設(shè)計風格應(yīng)貼近內(nèi)置應(yīng)用的設(shè)計，以不讓用戶啟動本應(yīng)用后存在突兀感為宜。由于小程序支持在移動端和 PC/Web 端使用，故界面設(shè)計應(yīng)盡量采用響應(yīng)式布局，同時支持小屏和大屏為宜。為了方便響應(yīng)式界面設(shè)計的調(diào)試，開發(fā)者可以使用桌面模擬器，來進行開發(fā)、測試。

2.3.7 實現(xiàn)示例

實現(xiàn)一個待辦事項小程序，這個小程序由三個界面組成，主界面顯示一個列表，記錄要完成的事項?？赏ㄟ^添加按鈕創(chuàng)建新的待辦，點擊添加會打開新建待辦界面，可以錄入待辦內(nèi)容（支持附件：拍照、錄像、錄音），在列表上直接點擊待辦條目，可以打開待辦詳情，如果待辦完成，在詳情頁面點擊完成，可以修改這個待辦的狀態(tài)為已完成。涉及到的接口有：窗口管理API、數(shù)據(jù)庫接口API、后臺任務(wù)API、HTTP 接口、拍照、錄像、錄音接口等。小程序支持庫，可以提供和本機交互獲取拍照、錄音、錄像的功能，可以通過簡單的調(diào)用 js 接口來實現(xiàn)基本需求，當然也可以通過調(diào)用 H5 的媒體 API來實現(xiàn)一些特定需求。針對后臺任務(wù)（數(shù)據(jù)庫初始化和數(shù)據(jù)同步），非必要不要使用后臺腳本，因為絕大多數(shù)業(yè)務(wù)在前臺頁面中就可以完成，只有很少數(shù)的需求會需要在后臺腳本中實現(xiàn)，比如離線數(shù)據(jù)同步等場景。實現(xiàn)新建待辦小程序示例如圖2所示。

圖2：新建待辦小程序示例

3 企業(yè)內(nèi)小程序開發(fā)平臺在某大型國企中的應(yīng)用

3.1 背景介紹

某能源企業(yè)建設(shè)的集團移動辦公應(yīng)用系統(tǒng)目標是作為移動辦公門戶，提供有即時通訊、業(yè)務(wù)審批、新聞資訊、會議中心等服務(wù)以及上百個業(yè)務(wù)系統(tǒng)的接入，為全集團用戶提供服務(wù)。系統(tǒng)從2016年開始建設(shè)，起步初期使用 ReactNative 開發(fā)移動應(yīng)用，快速搭建系統(tǒng)的雛形，并持續(xù)維護升級，隨著接入業(yè)務(wù)數(shù)量的增長，以及后續(xù)維護、集成工作的增多，ReactNative 的缺點逐漸暴露，最終決定遷移到混合開發(fā)模式并自主構(gòu)建小程序開發(fā)平臺。小程序平臺建設(shè)周期1年左右，提供了 iOS、Android、Web、Windows、Linux、MacOS 等多種終端應(yīng)用，完全覆蓋了用戶的全部使用場景。

3.2 小程序框架的意義及價值

在采用小程序平臺改造后，系統(tǒng)界面全面改版，用戶體驗大幅提升。該框架為企業(yè)自主研發(fā)，框架代碼自主可控，且與原生模塊集成的難度大幅降低。傳統(tǒng)混合開發(fā)模式，第三方系統(tǒng)采用標準接口或H5 接入，一方面無法滿足個性化需求，另一方面存在跨平臺開發(fā)難度搞，頁面設(shè)計不統(tǒng)一，性能較差問題?；谛〕绦蚱脚_，第三方業(yè)務(wù)系統(tǒng)基于該框架實現(xiàn)開發(fā)模式統(tǒng)一，且足夠靈活，可以滿足業(yè)務(wù)個性化需求，并可根據(jù)業(yè)務(wù)需求選擇集成到門戶應(yīng)用或行成獨立應(yīng)用單獨分發(fā)。經(jīng)測算，對比前后的接入方式，平均一個系統(tǒng)節(jié)省的時間和勞動力成本大約在50 萬元左右，極大的提升了經(jīng)濟效益。

4 結(jié)語

采用小程序平臺是企業(yè)開發(fā)內(nèi)部系統(tǒng)的有效手段，無論開發(fā)效率還是全平臺可用的特點，都極為適合企業(yè)辦公應(yīng)用，尤其是有移動辦公需求的業(yè)務(wù)建設(shè)，隨著工業(yè)互聯(lián)網(wǎng)的推進，更多的一線生產(chǎn)系統(tǒng)也存在大量的移動終端使用場景，利用小程序平臺來建設(shè)這些應(yīng)用無疑可以為企業(yè)節(jié)省大量資金，且更為靈活，適應(yīng)性強。小程序平臺還可結(jié)合低代碼平臺共同打造更為輕量、高效的開發(fā)平臺，未來還有很大的演進空間等待我們的探索?；谠撘苿討?yīng)用框架的研究，我們更好的將移動互聯(lián)網(wǎng)應(yīng)用于企業(yè)管理，加強管理信息化及生產(chǎn)信息化系統(tǒng)的移動應(yīng)用建設(shè)，提升辦公效率及用戶體驗，為集團數(shù)字化轉(zhuǎn)型奠定基礎(chǔ)。