一、前言

近年來，混合開發越來越流行，App 與 H5 的打通需求也越來越迫切。

那什么是 App 與 H5 打通呢？

所謂 “打通”，是指 H5 集成 JavaScript 數據采集 SDK 后，H5 觸發的事件不直接同步給服務端，而是先發給 App 端的數據采集 SDK，經 App 端數據采集 SDK 二次加工處理后存入本地緩存再進行同步。

本文的內容，主要是回答以下兩個問題：

• App 與 H5 為什么要打通？
• App 與 H5 該如何打通？

二、App 與 H5 打通原因

App 為什么要與 H5 打通呢？我們主要是從如下幾個角度考慮：

• 數據丟失率
• 數據準確性
• 用戶標識
• 基礎功能

下面分別為大家進行介紹。

2.1 數據丟失率

在業界，App 端采集數據的丟失率一般在 1% 左右，而 H5 采集數據的丟失率一般在 5% 左右（主要是因為緩存、網絡或切換頁面等原因）。

因此，如果 App 與 H5 打通，H5 觸發的所有事件都可以先發給 App 端數據采集 SDK，經過 App 端二次加工處理后存入本地緩存。在符合特定策略后再進行數據同步，即可把數據丟失率由 5% 降到 1% 左右。

2.2 數據準確性

眾所周知，H5 無法直接獲取設備的相關信息，只能通過解析 UserAgent 值獲取有限的信息，而解析 UserAgent 值，至少會面臨如下兩個問題：

有些信息通過解析 UserAgent 值根本獲取不到，如應用程序的版本號；

有些信息通過解析 UserAgent 值可以獲取到，但內容可能不正確。

如果 App 與 H5 打通，由 App 端數據采集 SDK 補充這些信息，即可確保事件信息的準確性和完整性。

2.3 用戶標識

對于用戶在 App 端注冊或登錄之前，我們一般都是使用匿名 ID 來標識用戶。而 App 與 H5 標識匿名用戶的規則不一樣（Android 一般使用 Android ID，H5 一般使用 Cookie），進而導致一個用戶出現兩個匿名 ID 的情況。

如果 App 與 H5 打通，就可以將兩個匿名 ID 做歸一化處理（以 App 端匿名 ID 為準）。

2.4 基礎功能

基于 App 與 H5 打通，可以實現諸如可視化全埋點等更加高級的功能。

介紹完打通的原因之后，我們來看下 App 與 H5 如何進行打通。

三、打通方案演進

在打通方面，神策積累了豐富的經驗，同時也踩了許多的坑。目前摸索出了三種打通方案，我們將按照技術演進的順序為大家一一介紹這幾種方式，并分析其背景、原理和不足。

3.1 早期版本（1.0）

3.1.1 背景和原理

上一節介紹了為什么要進行 H5 打通，其中有一個點非常關鍵，“App 與 H5 打通，就可以將兩個匿名 ID 做歸一化處理”，簡單而言就是使用 App 的用戶 ID 去標識 H5 的行為，即將 H5 傳到服務端的數據添加上 App 的用戶 ID，然后上傳到服務端，從而統一移動端的用戶行為。

本著讓 H5 產生的事件數據使用 App 的用戶 ID 的思路，首先想到的是將 App 的用戶信息發給 H5，神策的早期打通方案也確實是這么做的。

基本的原理是將 JSBridge 注入到，WebView（讀者可查看官方的 Building web apps in WebView[1] 了解 Android 和 H5 頁面相互調用的操作），JSBridge 中提供方法給 H5 中的 JS 調用，提供的方法會返回 is_login（標識客戶是否在 App 登錄）、distinct_id（用戶 ID）等信息。如圖 3-1 所示：

圖 3-1 早期版本的打通方案

圖 3-1 描述了早期版本的打通方案，就是將 App 的用戶信息通過 JSBridge 傳給 H5 ，然后由 H5 將用戶信息添加到事件中從而實現 App 和 H5 頁面的用戶標識的統一。此種方式對應的代碼片段如下：

注入 JSBridge

webView.addJavascriptInterface(new AppWebViewInterface(mContext, properties), "SensorsData_APP_JS_Bridge");

JSBridge 類

class AppWebViewInterface {private static final String TAG = "SA.AppWebViewInterface";private Context mContext;private JSONObject properties;AppWebViewInterface(Context c, JSONObject p) {this.mContext = c;this.properties = p;}@JavascriptInterfacepublic String sensorsdata_call_app() {try {if (properties == null) {properties = new JSONObject();}properties.put("type", "Android");String loginId = SensorsDataAPI.sharedInstance(mContext).getLoginId();if (!TextUtils.isEmpty(loginId)) {properties.put("distinct_id", loginId);properties.put("is_login", true);} else {properties.put("distinct_id", SensorsDataAPI.sharedInstance(mContext).getAnonymousId());properties.put("is_login", false);}return properties.toString();} catch (JSONException e) {SALog.i(TAG, e.getMessage());}return null;} }

3.1.2 方案缺陷

在了解了這種打通方案后，你可能會注意到這種方式是 H5 直接將數據發送到服務端，跟我們在第一章中介紹的 “進行 H5 打通可以降低數據丟失率” 正好相反；同時你也可能注意到一旦將 WebView 注入了 JSBridge 對象后，那么這個 WebView 加載的所有 H5（這里特指集成了神策 Web JS SDK 的頁面） 都會使用 App 提供的 is_login 和 distinct_id 字段。

假如 WebView 加載了另外一家集成了神策 Web JS SDK 的 H5 頁面就會出現很大的問題，因為 App 提供的信息添加在了另外一家客戶的 H5 里，這樣就會給另外一家客戶帶來很大的麻煩。

注意：

神策 Web JS SDK 提供了是否打通的標志位，可以選擇性的對部分 H5 頁面進行打通，這一點在上面的流程圖中沒有體現，本篇文章默認 H5 的標志位都是打通的。

3.2 中期版本（2.0）

3.2.1 背景和原理

1.0 方案介紹了 H5 打通的早期版本的實現方式以及存在的兩個問題：一是數據是通過 H5 頁面發送的；二是無差別的對待方式會給其他客戶的 H5 帶來很大的麻煩。為了解決這兩個問題，我們修改了 1.0 方案。

首先我們將 H5 頁面產生的數據發送到 App，接著 App 端提供校驗標識位，用來判斷是否校驗 H5 數據的數據接收地址和 App 端的數據接收地址。修改上面的流程圖，如圖 3-2 所示：

圖 3-2 中期版本的打通方案

圖 3-2 描述了 2.0 版本的邏輯，首先 JSBridge 對象提供了 boolean sensorsdata_verify(String event) 方法用來接收和校驗 H5 數據，注意這個方法的返回值，true 表示校驗通過，數據會通過 App 發送；false 表示校驗未通過，數據會通過 H5 發送。

通過這種方式解決了客戶自己的 H5 數據可以通過 App 發送，對于其他集成了神策 Web JS SDK 的 H5 頁面，因為校驗 server_url 不通過，H5 自己發送數據。

了解了原理以后，我們來看一下代碼實現：

注入 JSBridge

webView.addJavascriptInterface(new AppWebViewInterface(mContext, enableVerify), "SensorsData_APP_JS_Bridge");

此處代碼是給 WebView 注入 JSBridge 對象，注意 AppWebViewInterface 構造方法中有一個 enableVerify 參數，作用是 App 端控制是否需要校驗，我們再看 AppWebViewInterface 的代碼：

AppWebViewInterface 類

class AppWebViewInterface {private static final String TAG = "SA.AppWebViewInterface";private Context mContext;private boolean enableVerify;AppWebViewInterface(Context c, boolean b) {this.mContext = c;this.enableVerify = b;}@JavascriptInterfacepublic boolean sensorsdata_verify(String event) {try {if (!enableVerify) {sensorsdata_track(event);return true;}return SensorsDataAPI.sharedInstance(mContext)._trackEventFromH5(event);} catch (Exception e) {SALog.printStackTrace(e);return false;}} }

這里要注意的是 sensorsdata_verify 方法，當 enableVerify 為 false 的時候表示不校驗。

因此只要是 H5 發過來的任何數據都通過 App 發送，并且 H5 調用這個方法得到的返回值為 true，表示數據已經在 App 端處理了，H5 將不會再發送此條數據；如果 enableVerify 為 true 的時候，App 會校驗 H5 發送數據的 server_url 和 App 的 server_url 是否相同。

如果相同也會返回 true 表示 App 處理此條數據，如果不同會返回 false，表示校驗失敗，數據還是通過 H5 端去發送。

3.2.2 方案缺陷

通過上一節的原理介紹和代碼展示可以發現幾個問題：

• 假如 App 端調用如下代碼為 WebView 注入 JSBridge：

webView.addJavascriptInterface(new AppWebViewInterface(mContext, false), "SensorsData_APP_JS_Bridge");

其中，enableVerify 總是設置為 false，那么還是會存在其他客戶集成神策 Web JS SDK 的 H5 數據發送到 App 上，造成其他客戶數據的丟失以及當前客戶臟數據的增多；

• 假如客戶的 App 中有很多 WebView 需要打通，那么我們就需要給每一個 WebView 調用上面這段代碼，顯得不夠優雅；
• 還有一個原因使得我們必須去改善，那就是我們的可視化全埋點功能依賴于打通功能，或者說就算不打通也希望能做到客戶使用可視化全埋點功能的時候可以提示客戶去打通。關于可視化全埋點功能可以參考我們官網的『可視化全埋點介紹』[2]。

3.3 成熟版本（3.0）

3.3.1 背景和原理

我們可以看到 2.0 版本是對 1.0 版本缺陷的一個改善，但是并沒有解決當客戶不校驗數據時產生的 “其他客戶集成有神策 Web JS SDK 的 H5 頁面發送到 App 上，造成其他客戶數據的丟失以及當前客戶臟數據的增多” 問題。

如果 App 中 WebView 有很多，不得不為每一個 WebView 都注入 JSBridge，使得客戶的工作量會很大。同時，也需要為可視化全埋點功能做好技術準備。那么為了解決這些問題，神策對 2.0 版本進行了升級，具體方案分兩步：

為每個 WebView 建立一個通道。通道注入 AppWebViewInterfaceBridge，還可以注入其他的 JSBridge，例如可視化全埋點功能需要的 JSBridge;

更改數據校驗規則。2.0 版本是將校驗放在 App 端，現在將校驗放在 H5 端，由 H5 端來判斷是否需要將數據發送到 App，而 App 只提供 H5 端用于校驗的 server_url，server_url 是服務端地址，采集的數據會發往該地址。

此方案的流程如圖 3-3 所示：

圖 3-3 成熟版本的打通方案

方案的第一步是建立通道，這需要用到神策 SDK 插件[3]從字節碼層面上去實現。具體原理是插件掃描 class 文件中的方法，方法中如果有類似 webview.loadUrl(String url)，這樣的方法，我們會用將其替換成 SensorsDataAutoTrackHelper.loadUrl(webview, url) ，這個方法就是我們建立的通道，代碼如下：

SensorsDataAutoTrackHelper

public static void loadUrl(View webView, String url) { //webView 可能是原生的 Android WebView 也可能是騰訊 X5WebView，這里設置類型為 View，是為了做兼容if (webView == null) {throw new NullPointerException("WebView has not initialized.");}setupH5Bridge(webView); //設置 JSBridge//... 其他類型的 JSBridgeinvokeWebViewLoad(webView, "loadUrl", new Object[]{url}, new Class[]{String.class});//通過反射調用 webview.loadUrl }private static void setupH5Bridge(View webView) {if (SensorsDataAPI.sharedInstance() instanceof SensorsDataAPIEmptyImplementation) {return;}if (isSupportJellyBean() && SensorsDataAPI.sharedInstance().getConfigOptions() != null && SensorsDataAPI.sharedInstance().getConfigOptions().isAutoTrackWebView) {setupWebView(webView);}if (isSupportJellyBean()) {addWebViewVisualInterface(webView);}}private static void invokeWebViewLoad(View webView, String methodName, Object[] params, Class[] paramTypes) {try {Class<?> clazz = webView.getClass();Method loadMethod = clazz.getMethod(methodName, paramTypes);loadMethod.invoke(webView, params);} catch (Exception e) {SALog.printStackTrace(e);}}

上面的代碼是神策 Android SDK 中 SensorsDataAutoTrackHelper 類的代碼片段。當集成了神策 Android SDK 插件后，插件會將如下的代碼替換掉：

H5Activity

class H5Activity : BaseActivity() {private val TAG: String = "H5Activity"override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)setContentView(R.layout.activity_h5)androidWebView.loadUrl("https://www.sensorsdata.cn") 此處的代碼將會被插件替換成 SensorsDataAutoTrackHelper.loadUrl(androidWebView, "https://www.sensorsdata.cn")} }

通過這種操作，我們將原始加載頁面的方法替換為通道方法，并且在通道方法中通過反射的方式去調用原本加載頁面的邏輯。當然，我們不光可以在通道中注入打通的 JSBridge，還可以注入其他業務需要的 JSBridge，而且不需要客戶再去寫代碼來實現了。

上面介紹了建立通道的方案，那么如何實現在 H5 端進行校驗呢，這個比較容易實現了，看一下我們的 JSBridge 類的代碼：

AppWebViewInterface

class AppWebViewInterface {private static final String TAG = "SA.AppWebViewInterface";AppWebViewInterface() {}//提供給 H5 端調用，用來獲取 App 配置的 server_url@JavascriptInterfacepublic String sensorsdata_get_server_url() {return SensorsDataAPI.sharedInstance().getConfigOptions().isAutoTrackWebView ? SensorsDataAPI.sharedInstance().getServerUrl() : "";} }

可以看到我們只提供了一個 sensorsdata_get_server_url 方法，H5 會調用此方法獲取 App 的 server_url，然后與自己的白名單列表對比。

如果白名單中存在此 server_url，就認為校驗通過，數據會發往 App；如果 App 的 server_url 為空或者跟自己的白名單不匹配就認為校驗失敗，H5 直接發送數據。通過這種方式把校驗的主動權放在了 H5 端，解決了 “其他客戶集成有神策 Web JS SDK 的 H5 頁面發送到 App 上，造成其他客戶數據的丟失以及當前客戶臟數據的增多” 這個問題。關于神策 Web JS SDK 的信息可以參考技術指南[4]。

3.3.2 方案缺陷

從上一節的介紹能夠知道神策 Android 插件需要掃描方法里的代碼，這增加了插件編譯的時間，不過目前沒有更好的辦法。后面會將更多需要在 SDK 端完成的配置通過插件來完成，盡量讓客戶不寫代碼或者盡量少些代碼就能使用我們的 SDK 功能。

四、總結

神策 Android SDK 的 H5 打通方案演進可以說是建立在業務驅動和需求的基礎上不斷發展的，現在到了 3.0 版本。從目前來看，此版本的思路更好、擴展性也更好。未來有沒有更好的方案還是要看具體的業務需要，我們也會持續探索，看看有沒有更好的方案。讀者如果有更好的想法，也希望能加入開源社區與我們分享。

參考文獻：

[1]https://developer.android.com/guide/webapps/webview

[2]https://manual.sensorsdata.cn/sa/latest/%E5%8F%AF%E8%A7%86%E5%8C%96%E5%85%A8%E5%9F%8B%E7%82%B9-7541326.html

[3]https://github.com/sensorsdata/sa-sdk-android-plugin2

[4]https://manual.sensorsdata.cn/sa/latest/tech_sdk_client_web-7548149.html

本文作者

張偉

神策數據 | Android 研發工程師

我是張偉，神策數據 Android 研發工程師，主要從事神策 Android SDK 和 Android Plugin 的開發工作，希望通過開源社區這個平臺與大家共同學習進步。生活中熱愛籃球、看書、旅游，希望我們相聚神策，一起維護神策開源社區和打籃球。

總結

以上是生活随笔為你收集整理的android h5使用缓存_Android SDK 的 H5 打通方案演进 | 数据采集的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。