一種移動端H5運營活動技術方案的設計與實現

張夢元

摘要：移動互聯網時代，H5線上活動是企業常用的營銷手段。這類型的活動特點是時效短、變化快、低時延。如何快速開發和發布并保證頁面的可靠性，對企業有重要的現實意義。該文采用開發JSSDK的方式，將活動業務需要的基礎接口進行封裝，并保其穩定性和跨平臺性，從而讓開發活動頁面時只需關注業務邏輯本身，達到提高質量和效率的目的。

關鍵詞：JSSDK;H5;跨平臺;營銷活動

中圖分類號：TP311? ? ? 文獻標識碼：A

文章編號：1009-3044（2021）18-0185-02

開放科學（資源服務）標識碼（OSID）：

1 背景

移動互聯網時代，H5線上活動是企業常用的營銷手段[1-2]，如抽獎、降價促銷等。這類型的活動特點是時效短、變化快、低時延[3]。H5能很好滿足以上要求，并具有成本低、傳播快等特點。因此，大多數活動采用H5頁面來實現。但由于客戶端市場的碎片化，給H5頁面造成了一定兼容性問題，這會導致體驗差異從而造成客戶流失[4]。另外，大多數活動需要客戶端提供一些本地接口（如振動）能力才能實現，或者提供一些接口來優化流程（如登錄信息）。最后，大部分公司都有多個不同App在線上運營，即使同一個應用也存在著Android和iOS版本。這樣一來，企業面臨同一H5頁面需要在不同端適配的問題。大流量型App企業通常會開發H5頁面發布平臺，并以此來創造廣告收入。但中小型，特別是非流量型App企業則不具備這樣的成本優勢。本文主要討論一種滿足跨平臺、跨應用、高復用、低成本和高效率發布H5活動技術方案，使得移動應用在發布H5活動時，能避免前文提到的痛點。

2 整體設計

本文重點分析實現JSSDK與JsBridge兩層。

3 JSSDK的分析與設計

JSSDK實現對前端核心接口的封裝，使得前端只需專注活動業務。需要滿足如下需求：包含常用的活動相關接口，大部分情況下無需擴展;足夠精簡，以便減少代碼量，減少非必要的依賴;引用簡單方便;穩定可靠、運行高效，同時向后兼容;可調試、可擴展;安全。

3.1 JSSDK引用形式

通過webpack將JSSDK構建為一個umd bundle，自動適配所有形式的模塊。提供CDN和NPM兩種引用方式，方便用戶集成開發。

3.2 JSSDK的接口設計

1）JSSDK配置接口

使用接口前需進行配置調用，詳細設計如下：

config（{

debug： true， // 開啟調試模式，客戶端會顯示完整的調試日志

appId： "123456"， // 頁面的唯一標識

digest： ""，//頁面hashcode

timestamp： "1617189094"，// 簽名的時間戳

signature： ""， // 應用簽名字符串

apiList： ["showToast"，"share"] // 頁面需用到的相關jssdk接口

}）;

2）通用回調接口

接口回調采用異步方式，當需要調用完native函數后，對頁面進行相應的更新，可以在調用參數對象中加入如下js函數：

success函接對象，如：

success： function（res） {

//res是json對象，包含native回傳參數信息，具體參數細節在不同接口中分別定義

}

其他函數回調包括fail，complete，cancel等使用方式同success。其中fail定義為接口調用失敗情況，complete定義為執行結束情況，cancel定義為調用取消的情況。

3）用戶接口

用戶接口包括獲取用戶登錄態，獲取用戶信息和跳轉登錄注冊等接口。頁面可以通過用戶登錄態接口獲取登錄態信息，這可避免在客戶端登錄的情況下，要求用戶在頁面進行二次登錄問題。如果客戶端沒有登錄，則可以直接在頁面跳轉到客戶端登錄頁面，從而使用戶的體驗變流暢。具體獲取登錄接口態如下

checkLogin（{

success： function （res） {

var isLogin = res.isLogin // 是否登錄

}

}）;

res為本地代碼回調參數。內容包括是否登錄、登錄用戶昵稱、性別、圖形等必要的用戶信息。跳轉登錄接口與獲取用戶信息類似，如果需要處理錯誤，則加上fail回調即可。

4）基礎接口

基礎接口包括獲取版本信息、獲取客戶端信息、判斷接口可用和配置擴展等。頁面端可以根據版本和客戶端信息設計不同業務流程。

5）設備接口

設備接口包括分享接口、掃碼接口、獲取設備信息接口、獲取網絡信息接口、振動與地理位置接口、上傳和下載圖片接口。這些接口包基本涵蓋H5活動需要接口，使H5頁面能夠實現大部分原生應用能夠實現的場景。

6）界面接口

界面接口包含關閉界面接口、顯示和隱藏菜單接口、顯示隱藏標題欄接口。這些接口使H5頁面能夠無感知地嵌入到客戶端頁面中。

3.3 JSSDK的安全驗證

廣告容易被植入惡意代碼[5]，因此JSSDK安全至關重要。客戶端通過域名、appId和簽名來識別接口調用合法性。如果用戶的域名沒有注冊，或者appId與簽名沒有通過客戶端安全效驗，則H5頁面無法調用本地接口。另外，H5調用JSSDK接口前，必須用全局對象調用config接口后才能調用接口列表中的接口。

3.4 JSSDK的版本兼容與接口擴展

JSSDK版本需向后兼容。JSSDK通過config接口新增擴展接口名。native根據接口規范，很容易通過原有JsBridge橋通訊協議實現擴展接口，中間JSSDK與JsBridge無需修改。

4 JsBridge

JsBridge是連接原生層和JavaScript的橋梁，是實現整個應用框架的基礎部分，它包含native與JS兩個方向調用。

JS調用native一般有四種通信方案：第一，在webview中對頁面請求進行攔截，執行按特定規則映射的native函數。第二，對webview的彈窗進行攔截，將彈窗參數按特定規則映射的native函數。第三，通過調用webview提供的函數進行上下文注入，如蘋果scriptMessageHandler函數、安卓addJavascriptInterface函數等。第四，攔截webview的console.log函數，按特定規則映射native函數。不論是那種方法，除方法三外，本質都是利用webview基礎接口去執行額外的代碼邏輯。通用的實現方式是設置字符串映射規則，如：jsapi：//group/method？params，將js函數映射到native函數，達到調用native方法目的。本文不限定使用哪種方式，只要能提供本地調用即可。這樣可以方便客戶端開發者基于公司的技術棧去選擇其中一種或者多種技術方案進行實現。

4.1 JsBridge設計

JsBridge要按照JSSDK定義的接口規范實現所有的接口，避免不同平臺調用結果不一致問題。但可以選擇使用任何一種JS調用native方式和任何一種native調用js方式，無論開發者面對的是否為同一應用或者同一平臺。但一般來說都會進過下面的流程。

1）JS調用native一般流程：

第一步：定義JS函數與native函數映射規則。

第二步：在入口處置入映射判斷邏輯，如果調用過程符合攔截規則，進入第三步，否則不處理。

第三步：編碼回調函數并將回調編碼和其他參數傳入本地函數調用。

第四步：實現本地函數執行，執行結果進行封裝。

第五步：執行回調流程。

2）native調用JS一般流程：

第一步：JSSDK給頁面注入通用回調函數callJS（Json json）。該步驟無需前端額外實現，在開發H5頁面時引入JSSDK即可實現該步驟。

第二步：native調用callJS函數，調用時需要回傳回調編碼。具體調用方法可以參照上文JS調用native方式。

第三步：解析回調參數，獲取回調函數編碼。

第四步：根據編碼執行相應的回調函數。

上述流程省略了接口安全性檢測邏輯，這部分內容在本文2.3接口安全驗證部分進行了比較詳細的描述。

5 關鍵技術

5.1 跨平臺

第一，通過JSSDK與JsBridge將抽象接口層與實現層分離，使得相同的接口在不同的客戶端能穩定使用，H5能保持不變。

充分發揮H5快速開發特點，同時保證不同端的體驗一致性。

第二，JsBridge提供統一跨進程通訊協議，使客戶端只需要對自己的平臺進行實現，無需處理中間調用邏輯。

5.2 輕量可擴展接口

接口只關注H5活動相關業務場景，并進行嚴格測試，保證核心邏輯代碼文檔，避免導致宿主程序的崩潰。同時減小JSSDK文件大小，保證加載和運行速度。

5.3 安全性

擴展H5能力后接口安全性非常關鍵，因此在JSSDK和JsBridge層需加入安全保護機制。通過驗證H5的域名信息和appId，過濾掉非法調用并進行上報追蹤，以保證用戶信息安全。

5.4 穩定可調試

整個接口得到集中測試，保證核心邏輯的穩定可靠。同時，增加JSSDK與JsBridge調試模式，使開發過程能輸出詳細的日志，定位開發問題。

6 結束語

本文分析了移動端H5活動發布遇到的相關問題，確定基于JSSDK實現方案，并完成JSSDK的接口設計與實現，同時給出JsBridge實現方式。通過使用JSSDK，開發H5活動變得更加簡單高效。同時，提升了用戶體驗，給中小企業提供了一種節約開發與發布成本方案。

參考文獻：

[1] 劉玎璇.H5廣告的傳播效果與發展策略分析[J].科技傳播，2019，11（1）：1-2，10.

[2] 陳瑩.探析新媒體廣告傳播模式運作[J].傳媒論壇，2021，4（2）：79-80.

[3] 周瑜嫄.移動端HTML5廣告的受眾體驗設計研究[D].無錫：江南大學，2016.

[4] Yao Y，Zhao W X，Wang Y，et al.Version-Aware Rating Prediction for Mobile App Recommendation[J].ACM Transactions on Information Systems，2017，35（4）：1-33.

[5] 王持恒，陳晶，蘇涵，等.基于宿主權限的移動廣告漏洞攻擊技術[J].軟件學報，2018，29（5）：1392-1409.

【通聯編輯：謝媛媛】