Android SDK 的 H5 打通方案演进 | 数据采集

一、前言

近年来，混合开发越来越流行，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 值，至少会面临如下两个问题：

1. 有些信息通过解析 UserAgent 值根本获取不到，如应用程序的版本号；

2. 有些信息通过解析 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 和 H