IOS 全埋点 ios数据埋点

本篇文章是基于 网易乐得无埋点数据SDK 总结而成。负责无埋点数据收集 SDK 的开发已经有半年多了，期间在组内进行过相关分享，现在觉得是时候拿出去和同行们交流下了。本篇主要讲一下SDK的整体实现思路以及关键的技术点。

自动的、动态可配的、全面且正确

SDK 已有的功能可以分为两大部分：

• 基本事件数据的收集：基本事件的收集是指应用冷启动事件、页面事件、用户点击事件、

ScrollView

• 滑动事件等，这部分全部都是自动完成的，实现思路会在第一节中介绍。
• 业务层数据的收集：业务层数据的收集是指对与业务功能相关的一些数据，例如：在用户点击提交订单按钮时，收集用户购买的物品以及订单总金额的数据。这种业务层数据的收集以往大多通过 代码埋点 的方式去做，本SDK则真正的实现了 

无埋点

SDK的整体实现思路

Runtime特性的 Method SwizzlingMethod Swizzling 来 hook 相应的方法。hook的方法大致可以分为3类：系统类的方法、系统类的Delegate方法、自定义类的方法。

系统类的方法

UIApplication、UIViewController等。SDK 在实现某些功能时，需要hook这些类的方法。例如在实现对页面事件的收集时，主要hook了 UIViewController 的生命周期的方法：viewDidLoad、viewDidAppear、viewDidDisappear、dealloc

系统类的 Delegate 方法

hook这些协议中的方法来完成的。例如在实现列表元素点击事件的收集时，主要 hook 了 UITableViewDelegate 中的 tableView:didSelectRowAtIndexPath:

自定义类的方法

hook 这些类的方法来实现。例如在SDK实现对手势操作的事件收集时，需要hook手势对象所指定的target 中的 action 方法，而 target 通常都是自定义类。其实hook系统类的 delegate 方法也可以看成是 hook 自定义类的方法，因为系统类的 delegate 方法大多都是需要在自定义类中实现。UIControlEventValueChanged事件、如何解决hook手势操作引起的性能问题等等。不过这部分内容并不是本篇文章的重点，因此这里不打算多说，之后会单独写一篇文章来讲述遇到的一些坑。

SDK的关键技术的实现

viewPath 及 viewId 的生成及优化

viewPath 与 viewId

1. viewPath 的组成

viewTree），树的根节点就是 UIWindow，树的枝干由UIViewController及UIView组成，树的叶节点都是由UIView组成。viewTree中用什么信息来表示其中任意一个 view 的位置呢？很容易想到的就是使用目标 view 到根之间的每个节点的深度（层次）组成一个路径，而节点的深度（层次）是指此节点在父节点中的 index。这样确实能够唯一的表示此 view 了，但是有一个缺点：它的可读性很差。因此在此基础上又增加了每个节点的名称，节点的名称由当前节点的 view 的类名来表示。viewTree 中，由一个 view 到根节点之间的每个节点的名称与深度（层次）共同组成的信息构成了此 view 的viewPath。另外，由于在做 view 的统计分析时，都是以页面为单位的，因此 SDK 在生成 viewPath 时，只到 view 所在的 UIViewController 级别，而非根部的 UIWindow。这样做也在一定程度上减少了viewPath

2. UITableViewCell/UICollectionCell 的深度表示

UITableView与UICollectionView。针对这种可复用视图，里面会包含很多 Cell，而且 Cell 个数也不确定，那么里面的每一个 Cell 应该怎么去表示其深度呢？答案是indexPath。虽然每个 Cell 都可能被复用，但是不同的 Cell 都对应一个唯一的indexPath，因此完全可以使用indexPath值来表示其深度。

3. viewPath 的表示形式与示例

viewPath就是由各节点的类名与深度组成，那么接下来就使用这些信息来表示出 viewPath。下面结合一个具体的示例来简单说一下，我随便从项目中找了一个：

路径中各个节点的类名是：

HYGHallSlideViewController-UIScrollView-HYGHallProductTableView-UITableViewWrapperView-HYGHallProductCell-UITableViewCellContentView-HYGHallProductView。

0-0-0-0-0:2-0-1viewPath，SDK 的表示方式如下：

viewPath：HYGHallSlideViewController-UIScrollView-HYGHallProductTableView-UITableViewWrapperView-HYGHallProductCell-UITableViewCellContentView-HYGHallProductView & 0-0-1-0-0:2-0-1

& 连接符简单的拼接到一起。这样做可以方便将两者组合与分离开，便于后面的viewPath匹配。另外，网上还有一种类似于 xPath

HYGHallSlideViewController[0]/UIScrollView[0]/HYGHallProductTableView[1]/UITableViewWrapperView[0]/HYGHallProductCell[0:2]/UITableViewCellContentView[0]/HYGHallProductView[1]

xPath的方式稍微复杂了点，在组合以及拆分上都相对麻烦些。不过话说回来，viewPath的形式是次要的，大家可以按照各自喜欢的方式去表示就行，无须纠结于哪种形式更好。

4.针对 viewPath 的优化

4.1 优化节点的深度的计算方式

viewTree

• 假设一个 UIView 中有三个子 view，先后加入的顺序是：label、button1、button2，按照之前的计算方式，这 3 个子 view 的深度依次是：0、1、2。这时候用户点击了一个按钮，label1 从父 view 中被移除了。此时 UIView 只有 2 个子view：button1、button2，而且深度变为了：0、1。如图所示：

同类型

viewPathviewPath中，而不再是仅仅为了增加可读性。

4.2 viewPath 针对 Swift 的优化

Swift文件在获取其类名时，会自动添加此文件所在的Module名前缀：如果Swift文件在主工程中，则会添加工程的名字；如果是在某个组件中，并且项目开启了 use frameworks! 选项，则会添加组件的名字。总的来说，在含有swift 的项目中（包括纯 swift/OC 与 swift 混编），viewPath中会包含各 Swift 文件的ModuleName，那么在如下情况下：

• 某个 OC 文件被使用 Swift 重写了
• 某个 Swift 文件被从主工程移至某个组件库中，或者从组件库移至主工程中
• 主工程在引用组件库时，在开启与关闭

use frameworks!

• 之间进行切换

ModuleName而发生变化，进而会导致 viewPath 的改变，工程文件在结构上的调整都可能会直接对viewPath造成影响。OC项目，经常会对项目的OC文件使用Swift重写。因此 SDK 有必要去避免viewPath因为这类情况而发生变化。ModuleName前缀的改变造成的，那么就干脆在生成viewPath时，去掉所有的Swift的ModuleName前缀。这种做法能够解决对viewPath的影响，但是细心的人可能会意识到另一个隐藏的问题：如果在不同的组件库中，两个不同的视图或控制器具有相同的名字（在Swift中是允许的，因为有Module进行区分），这种情况下，viewPath是否存在无法区分的情况？viewPath也不会完全相同。

4.3 在包含子VC时，优化VC的深度的计算

viewPath只表示到距离 view 最近的一个 VC，VC 的深度的计算也是此 VC 的 view 所在的父 view 的所有子 view 中的深度。在实际的 iOS 开发中，可能会经常使用addChildViewController:添加多个子 VC 来实现复杂的页面，但是在包含子 VC 时，VC 的深度计算就有可能会存在问题。还是举一个简单的栗子：

• 假设一个 containerVC 中包含4个子VC：VC1、VC2、VC3、VC4。在每个子VC首次被展示时，子VC会先被add进来，而子 VC 的 view 也会被 add 到一个scrollView 上。这时候这几个子VC首次的查看顺序的不同将会导致它们的深度的变化：如果查看顺序是：VC1、VC2、VC3、VC4，那么它们的深度依次为：VC1（0）、VC2（1）、VC3（2）、VC4（3）；如果查看顺序是：VC3、VC1、VC4、VC2，深度则变成了：VC1（1）、VC2（3）、VC3（0）、VC4（2）。这种情况导致 

viewPathviewPath的根级别了，它的深度信息已经不重要了。viewPath就无法区分具体是哪个子 VC 的 view 了。针对这种同一类的不同实例，如果想进一步区分它们，SDK 采用了另一个方案：页面别名。

5. viewId 的生成

viewPath 已经能够唯一标识某个 view 了，为何还需要viewId呢？其实主要原因是：viewPath 的长度不固定，而且一般都会比较长，不便于后台使用它作为 view 的唯一标识。因此 SDK 使用viewPath信息通过MD5加密生成一个固定长度的值作为viewId。

6. viewPath 与 viewId 重复时的解决方案

viewPath的优化，SDK 已经尽可能的保证了viewPath的稳定性。但是并不表示只依靠viewPath就能区分所有的点击事件。有时同一个viewPath的 view 具有不同的表现形式与作用，例如下面的情况：

• 同一个按钮在不同的状态下，显示不同的文字。例如：一个按钮在未添加商品前显示“添加”；添加了商品之后，立刻显示成“清除”
• 同一个view上具有多处点击事件，例如 SegmentControl、

UISwitch

• 、

UIStepper

• 等

viewPath对应多个事件，此时如果只使用viewPath无法区分出不同的状态或事件。viewPath

关于“其它信息”，再补充一点，除了 SDK 事先知道要获取的信息之外，还有一类就是业务数据。例如：有一个商品列表页，每一行显示一个商品，如果后台想统计的不是列表中每一行的点击，而是每个商品的点击，那么此时的“其它信息”就应该是productId 了。关于 SDK 对业务层数据的获取与上报请看下面的介绍。

SDK无埋点业务数据收集的实现

viewPath 之后，接下来详细介绍下 SDK 的另一个关键技术：基于 viewPath 与 KVC 实现 SDK 的无埋点业务数据收集功能。首先，先简单分析一下传统的 代码埋点

• 埋点代码与业务逻辑代码混合在一起，增加了代码的维护成本；
• 埋点代码需要跟随APP版本一起发布，耽误数据的收集与统计；
• 埋点时存在错埋、漏埋等情况，无法动态更新及添加；

代码埋点 的缺陷，SDK 实现了真正意义上的 无埋点

1. 无埋点的实现架构

viewPath 与 KVC。viewPath前面已经介绍了，它主要用于标识viewTree中的某个 view。而KVC对于 iOS 开发者也不陌生，堪称 iOS 开发中的黑魔法之一。通过KVC我们能够通过 key 或 keyPath 直接访问对象的属性，而不需要调用明确的存取方法。关于KVC如果不太了解，请自行学习，这里不再过多阐述。

那么如何实现不需要代码埋点就能随意获取想要的业务数据呢？先看一下 SDK 的无埋点技术的整体架构图：

从上图可以看出，在实现 SDK 的无埋点数据收集时，主要分为3步：上传KVC配置、请求KVC配置、业务数据的收集与上报。

2. 什么是 KVC 配置

在上图中出现了 KVC配置，那么下面先简单介绍下什么是KVC配置。其实 KVC配置 就是一些用来描述 App 应该在什么时机去收集什么数据的信息，包含的主要信息有：

• appKey：用来标识是哪个应用
• appVersion：用来标识应用的版本号
• viewEvent：标识某个事件类型（收集时机），例如：ButtonClick、ListItemClick、ViewTap等
• viewPath：目标 view 在

viewTree

• 中的信息
• keyPath：目标 view 与要收集的业务数据间的关联路径，用于KVC取值
• keyName：为要收集的业务数据定义一个key，最终组成 key-value 的形式上报。用于区分多个收集的数据

3. KVC配置的上传与下发

• 上传KVC配置

• 利用 圈选SDK 上传 KVC配置 的操作对于用户是透明的，主要由开发人员进行上传与管理。此操作可以在任何时候进行，在想要收集某个或某些版本的 App 中的业务数据时，上传相应的KVC配置信息至后台即可，达到了根据需要动态可配的效果。

• 请求KVC配置

• SDK 在初始化时会触发 KVC配置 的请求操作，从后台拉取 App 当前版本对应的所有KVC配置，并将请求结果缓存起来，以提供给下一步使用。

4. 业务数据的收集与上报

这一部分是 SDK 无埋点技术的核心，接下来详细介绍这部分的实现逻辑。它的实现流程如下：

viewPath的 view 匹配，主要实现是通过循环遍历viewPath的每个节点的信息与当前 view 及其父view 依次进行匹配。因此这一步会产生一定的时间与性能消耗。为了尽可能减少这部分的操作，SDK 中使用了一些方式进行优化，其中一个就是基于缓存view的优化。

4.1 基于缓存view的优化

viewPath匹配操作。这里主要缓存的 view 信息有：

• targetView：上一次通过

viewPath

• 匹配成功的 view 对象。
• indexPath： 上一次通过

viewPath

• 匹配成功的 view 的

indexPath

• ，如果没有则为nil。

1. viewEvent 匹配

第一步先进行事件类型的匹配。如果KVC配置信息指定的 viewEvent 是 ButtonClick，那么可以轻松的过滤掉 ListItemClick、ViewTap 等其它事件。这一步能够过滤一大部分事件，只有事件类型匹配成功才继续进行下一步。

2. targetView 匹配

接下来就是将缓存的 targetView 与当前 view 进行比较。如果两者指向同一对象，则进行第3步，否则直接进入第4步

3. indexPath 匹配

有人可能不明白为何要添加这一步呢？其实这一步也很重要，是对第2步的补充，主要是用来处理 Cell 可复用性的情况。

如果第2步中缓存的 targetView 是 Cell 或 Cell 中的某个 subview，那么第2步的匹配成功，并不能保证当前 view 就是我们真正想匹配的 view。这个可能不太容易理解，还是举个简单的例子来说明一下：

• 假如一个 Cell 中有一个 button，在第1行的 button 被点击时，通过

viewPath

• 匹配成功了，那么这时 targetView 缓存了第1行的 button 对象。接下来向下滑动列表，第一行被划出屏幕，第10行划入屏幕，同时第10行复用了第1行的 Cell，这时再点击 button 去匹配时，由于 Cell 复用的原因，targetView 与当前 button 肯定指向同一个对象，但是却不是我们真正想匹配的第1行的 button。可以看出：在有 Cell 复用的情况下，无法确定第2步的结果一定正确。

indexPath匹配。indexPath的匹配逻辑为：如果缓存的indexPath不为nil并且与当前view的indexPath不相等，则进入第4步；否则表明当前的 view 就是上次刚刚匹配成功的，也就没必要进行viewPath匹配，可以直接进入第5步。

4. viewPath 匹配

KVC配置中的viewPath的各个节点进行逐个匹配。由于是一个循环操作，因此会有一定的时间消耗，其实在这部分的匹配中，也做了一些简单的优化。在真正进入循环匹配之前，先进行如下3步判断：

• 判断 view 类名是否相等；
• 判断 view 所在的 viewController 类名是否相等；
• 判断 view 所在的 window 类名是否相等；

viewPath循环匹配。

5. KVC 取值与上报

keyPath调用 valueForKeyPath: 方法获取对应的值。如果值不为nil，就与 keyName 组成一个键值对，放到当前的事件数据中一起上报上去。这样后台就可以通过key去查找到相应的业务数据了。indexPath通配的情况的处理，由于文章篇幅这里不再详细讲解。

5. 增加对 KVC 的异常处理

KVC，但是众所周知，KVC是非常危险的，很容易造成程序崩溃。例如一旦 key 或 keyPath 所对应的属性名不存在，立刻会导致程序抛出一个NSUndefinedKeyException异常，如果应用没有处理此异常，程序就会Crash。KVC异常的处理。具体实现是给 NSObject 增加一个 Category ，重写 valueForUndefinedKey: 方法，并在方法中return nil。

@implementation NSObject (KVCExceptionHandler)
- (nullable id)valueForUndefinedKey:(NSString *)key
{
    return nil;
}
@end

其它关键技术

Method Swizzling与Aspects的兼容等。由于本文的篇幅已经很长了，而且考虑到大家读文章的耐性都不会太长，所以这里就先不讲解了，后续会再写文章单独介绍。

END

文章写了这么多，其实主要介绍了 SDK 中的两个关键技术点，希望对你们能有一些参考价值。另外，如果有人对本文的方案有更好的建议，欢迎一起讨论学习。

最后，要特别感谢我的同事王佳乐，由于他对文章的排版与校对工作，才使得本文能更好的展示给大家。同时也要感谢组内的所有同事，在我开发遇到困难时，给予了我很多的帮助。

Q & A

关于对本文内容提出的一些问题，将全部记录在这里（简书评论里的除外），并进行统一解答。

Q1: SDK 都使用KVC配置获取业务数据，是否会增加维护KVC配置的工作？

A1: 肯定会有对 KVC配置 的维护与管理工作

keyPath可能不一样。所以与 KVC配置 相关的工作有如下2个：

1. 针对当前 App 版本上传相应的 KVC配置，以获取想要的业务数据
2. 当 App 新版本发布时，需要对之前版本上的 KVC配置 逐一验证，是否仍然适用于新版本。如果仍然适用，则直接在管理后台上把新的版本号添加到此 KVC配置；如果不再适用，则对新版本再上传一个新的KVC配置。

从上面可以看出，在 App 版本不断迭代的过程中，KVC配置 会越来越多，相应的维护与管理工作也相当繁琐。

为了解决这个痛点，SDK 中增加了一种方案来避免这种重复且繁琐的工作。具体的方案是：

• 在上传 KVC 配置时，指定某个区间的版本，或者不指定具体的版本（即应用到当前所有版本上）；
• SDK 在使用KVC配置获取业务数据失败时，添加相关的错误日志，并上报上去。其中错误日志里包含了

appKey

• 、

appVersion

• 、

keyPath

• 等信息，这样就能在后台清晰的看到哪些 KVC配置 在哪个 App 版本上存在问题；
• 使用脚本监控与

KVC

• 相关的错误日志。如果监控到有错误日志上报，则发送邮件通知给相关人员；

因此，SDK 采用此方案优化之后，KVC配置 的管理工作就只有1个了：

• 根据Log信息快速找到对应的 KVC配置，并上传一个针对新版本的 KVC配置

Q2: 对于 “内容与位置” 可能会随时间而变动时，如何实现数据收集与统计？

A2: 使用圈选SDK与数据SDK共同完成动态数据的收集与统计

这个问题在实际产品中也比较常见，比如 App 首页的内容大多是通过后台配置的。
这个问题其实可以转化或分解成如下的2个情况：

• 同一位置会显示不同的内容
• 同一内容会显示在不同的位置

注意，这2个并非同一个，它们分别对应于不同的场景，同时数据收集的方案也有所不同。

viewPath中的通配符位置不同。

A2.1 同一位置显示不同的内容

例子：在 App 首页有一个展示最近活动的位置，先展示活动1的图片，过一段时间运营人员又配成活动2的图片。如何统计活动1、活动2各自的点击量？

“关心位置” + “关心内容”。

“关心位置” 的意思是只使用当前的位置，具体表现是viewPath中不包含任何通配符；“关心内容”

整个过程可以分解为如下3个环节：

• 圈选SDK上传“关心位置”的KVC配置。KVC配置中指定获取活动的

url

• 的

keyPath

• 。
• 数据SDK在活动发生点击时，收集当前活动对应的

url

• ，并跟随点击事件一起上报。
• 圈选SDK上传“关心位置” + “关心内容”的圈选配置，关心的内容指定为想要统计的活动的

url

• 值。

A2.2 同一内容显示在不同的位置

例子：App 首页有4个固定的入口，假设其中一个叫“热门推荐”，那么根据后台配置的顺序不同，“热门推荐”可能被显示在4个位置中的任何1个，即一段时间显示在第1个，过一段时间可能显示在第2个位置。这时如何统计出“热门推荐”的点击量？

“不关心位置” + “关心内容”。

“不关心位置” 是指viewPath中含有通配符，用于表示viewTree中的多个位置。例如想要匹配列表所有行时，则将viewPath中的indexPath替换为通配符。

这个问题的解决过程也分为如下3步：

• 圈选SDK上传“不关心位置”的KVC配置。KVC配置中指定获取入口的 title 的

keyPath

• 。
• 数据SDK在4个中任何一个入口被点击时，都去收集入口的 title，并跟随点击事件一起上报。
• 圈选SDK上传“不关心位置” + “关心内容”的圈选配置，关心的内容指定为“热门推荐”。

到这里，数据收集与圈选配置的工作都已经做完了，接下来就是后台的数据统计了。
上述2种情况对后台进行统计没有区别，都使用一个统计方案，这里也介绍一下后台大概的统计思路：

• 拿到第3步中上传的圈选配置，根据

viewPath

•  与 “关心的内容”