SDK 已经具备不需要代码埋点就能 自动的、动态可配的、全面且正确 的收集用户在使用 App 时的所有事件数据。除此之外，还单独开发了与之配合的圈选SDK，能够在 App 端完成对界面元素的圈配以及 KVC 配置的上传。而界面元素圈配的工作完全可以交给用研与产品人员来做，减轻了开发人员的工作量。
SDK 已有的功能可以分为两大部分：
基本事件数据的收集：基本事件的收集是指应用冷启动事件、页面事件、用户点击事件、ScrollView滑动事件等，这部分全部都是自动完成的，实现思路会在第一节中介绍。
业务层数据的收集：业务层数据的收集是指对与业务功能相关的一些数据，例如：在用户点击提交订单按钮时，收集用户购买的物品以及订单总金额的数据。这种业务层数据的收集以往大多通过 代码埋点 的方式去做，本SDK则真正的实现了 无埋点 的去获取这些想要的业务数据。这部分的实现会在本文的第二节详细介绍。
SDK的整体实现思路
SDK 整体采用了 AOP（Aspect-Oriented-Programming）即面向切面编程的思想，就是动态的在函数调用的前后插入数据收集的代码。在 Objective-C 中的实现是基于 Runtime 特性的 Method Swizzling 黑魔法。
SDK 的数据收集功能的实现主要通过 Method Swizzling 来 hook 相应的方法。hook的方法大致可以分为3类：系统类的方法、系统类的Delegate方法、自定义类的方法。
系统类的方法
系统类的方法是指系统框架中提供的基础类的方法，如 UIApplication、UIViewController 等。SDK 在实现某些功能时，需要hook这些类的方法。例如在实现对页面事件的收集时，主要hook了 UIViewController 的生命周期的方法：viewDidLoad、viewDidAppear、viewDidDisappear、dealloc
系统类的 Delegate 方法
系统类的 Delegate 方法主要指 UIKit 框架中提供的 Delegate 中的方法，如 UIScrollViewDelegate、UITableViewDelegate、UIWebViewDelegate 等。SDK 中的大多数功能都是通过hook这些协议中的方法来完成的。例如在实现列表元素点击事件的收集时，主要 hook 了 UITableViewDelegate 中的 tableView:didSelectRowAtIndexPath: 方法。
自定义类的方法
顾名思义，自定义类的方法是指开发人员在工程中自已定义的类，而非系统类的方法。SDK的一些功能是通过hook 这些类的方法来实现。例如在SDK实现对手势操作的事件收集时，需要hook手势对象所指定的target 中的 action 方法，而 target 通常都是自定义类。其实hook系统类的 delegate 方法也可以看成是 hook 自定义类的方法，因为系统类的 delegate 方法大多都是需要在自定义类中实现。
这部分看起来是借助于 AOP 来添加数据收集的代码，但是在真正做的时候，也并没有想的那么简单，涉及到很多细节上的问题，例如：如何将导航栏与系统弹窗的点击事件归属到合适页面中、如何区分UIControlEventValueChanged事件、如何解决hook手势操作引起的性能问题等等。不过这部分内容并不是本篇文章的重点，因此这里不打算多说，之后会单独写一篇文章来讲述遇到的一些坑。
SDK的关键技术的实现
viewPath 及 viewId 的生成及优化
为了对 APP 中某个页面的某个 view 进行数据收集、统计与分析，首先就需要能够唯一的标识与定位这个视图，这可以说是数据收集 SDK 的一个重要前提。那么怎样去唯一的标识 APP 中的某个 view 呢？SDK 中使用了 viewPath 与 viewId 来完成。
- viewPath 的组成
其实整个 APP 的视图结构可以看成是一颗树（viewTree），树的根节点就是 UIWindow，树的枝干由UIViewController及UIView组成，树的叶节点都是由UIView组成。
那么在viewTree中用什么信息来表示其中任意一个 view 的位置呢？很容易想到的就是使用目标 view 到根之间的每个节点的深度（层次）组成一个路径，而节点的深度（层次）是指此节点在父节点中的 index。这样确实能够唯一的表示此 view 了，但是有一个缺点：它的可读性很差。因此在此基础上又增加了每个节点的名称，节点的名称由当前节点的 view 的类名来表示。
因此，在 viewTree 中，由一个 view 到根节点之间的每个节点的名称与深度（层次）共同组成的信息构成了此 view 的viewPath。另外，由于在做 view 的统计分析时，都是以页面为单位的，因此 SDK 在生成 viewPath 时，只到 view 所在的 UIViewController 级别，而非根部的 UIWindow。这样做也在一定程度上减少了viewPath 的长度。 - UITableViewCell/UICollectionCell 的深度表示
在 App 开发中，最常用而且最重要的控件就是UITableView与UICollectionView。针对这种可复用视图，里面会包含很多 Cell，而且 Cell 个数也不确定，那么里面的每一个 Cell 应该怎么去表示其深度呢？答案是indexPath。虽然每个 Cell 都可能被复用，但是不同的 Cell 都对应一个唯一的indexPath，因此完全可以使用indexPath值来表示其深度。 - viewPath 的表示形式与示例
我们已经知道，viewPath就是由各节点的类名与深度组成，那么接下来就使用这些信息来表示出 viewPath。下面结合一个具体的示例来简单说一下，我随便从项目中找了一个：
路径中各个节点的类名是：
HYGHallSlideViewController-UIScrollView-HYGHallProductTableView-UITableViewWrapperView-HYGHallProductCell-UITableViewCellContentView-HYGHallProductView。
路径中各个节点的深度是：0-0-1-0-0:2-0-1
接下来就是将这两者放到一起来构成 viewPath，SDK 的表示方式如下：
viewPath：HYGHallSlideViewController-UIScrollView-HYGHallProductTableView-UITableViewWrapperVi
其实就是使用 & 连接符简单的拼接到一起。这样做可以方便将两者组合与分离开，便于后面的viewPath匹配。另外，网上还有一种类似于 xPath 的表示方式：
HYGHallSlideViewController[0]/UIScrollView[0]/HYGHallProductTableView[1]/UITableViewWrapper不过个人觉得xPath的方式稍微复杂了点，在组合以及拆分上都相对麻烦些。不过话说回来，viewPath的形式是次要的，大家可以按照各自喜欢的方式去表示就行，无须纠结于哪种形式更好。
4.针对 viewPath 的优化
4.1 优化节点的深度的计算方式
上面提到在计算各节点的深度时，是采用当前 view 位于其父 view 中的所有子 view 中的 index 值。不过在实际的开发中，viewTree 有时候会根据用户的操作有所变动。仍然举个栗子：
假设一个 UIView 中有三个子 view，先后加入的顺序是：label、button1、button2，按照之前的计算方式，这 3 个子 view 的深度依次是：0、1、2。这时候用户点击了一个按钮，label1 从父 view 中被移除了。此时 UIView 只有 2 个子view：button1、button2，而且深度变为了：0、1。如图所示：
可以看出仅仅由于其中一个子view 被移除，却导致其它子 view 的深度都发生了变化。因此，SDK 为了在新增/移除某一 view 时，尽量减少对已有 view 的深度的影响，调整了对节点的深度的计算方式：采用当前 view 位于其父 view 中的所有 同类型 子 view 中的index 值。
我们再看一下上面的这个例子，最初 label、button1、button2 的深度依次是：0、0、1。在 label 被移除后，button1、button2 的深度依次为：0、1。可以看出，在这个例子中，label 的移除并未对 button1、button2 的深度造成影响，这种调整后的计算方式在一定程度上增强了 viewPath 的抗干扰性。
另外，调整后的深度的计算方式是依赖于各节点的类型的，因此，此时必须要将各节点的名称放到viewPath中，而不再是仅仅为了增加可读性。
4.2 viewPath 针对 Swift 的优化
众所周知，Swift文件在获取其类名时，会自动添加此文件所在的Module名前缀：如果Swift文件在主工程中，则会添加工程的名字；如果是在某个组件中，并且项目开启了 use frameworks! 选项，则会添加组件的名字。总的来说，在含有swift 的项目中（包括纯 swift/OC 与 swift 混编），viewPath中会包含各 Swift 文件的ModuleName，那么在如下情况下：
某个 OC 文件被使用 Swift 重写了
某个 Swift 文件被从主工程移至某个组件库中，或者从组件库移至主工程中
主工程在引用组件库时，在开启与关闭use frameworks!之间进行切换
上述3种情况下，文件的类名都会由于ModuleName而发生变化，进而会导致 viewPath 的改变，工程文件在结构上的调整都可能会直接对viewPath造成影响。
实际开发中，特别是对于较老的OC项目，经常会对项目的OC文件使用Swift重写。因此 SDK 有必要去避免viewPath因为这类情况而发生变化。
其实这个问题的解决方案很简单，既然是由于类名中的ModuleName前缀的改变造成的，那么就干脆在生成viewPath时，去掉所有的Swift的ModuleName前缀。这种做法能够解决对viewPath的影响，但是细心的人可能会意识到另一个隐藏的问题：如果在不同的组件库中，两个不同的视图或控制器具有相同的名字（在Swift中是允许的，因为有Module进行区分），这种情况下，viewPath是否存在无法区分的情况？
其实经过仔细考虑，这个担忧有点多余，因为就算两个Module中的视图或控制器名字一样，但是他们里面的视图结构会有所不同，进而深度也不一样，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）。这种情况导致 viewPath 不可靠且无法保证唯一性。
SDK 为了解决上述情况，调整了 VC 的深度的计算：不再采用其 view 的深度，而是直接使用固定的0。因为 VC 已经是viewPath的根级别了，它的深度信息已经不重要了。
不过这种方案会引起另一个小问题，如果上述子 VC 的 VC1 和 VC2 是同一个类的不同实例，那么他们内部的视图结构是完全一样的，这时候如果使用固定的 VC 深度（0），通过viewPath就无法区分具体是哪个子 VC 的 view 了。针对这种同一类的不同实例，如果想进一步区分它们，SDK 采用了另一个方案：页面别名。
- viewId 的生成
viewPath 已经能够唯一标识某个 view 了，为何还需要viewId呢？其实主要原因是：viewPath 的长度不固定，而且一般都会比较长，不便于后台使用它作为 view 的唯一标识。因此 SDK 使用viewPath信息通过MD5加密生成一个固定长度的值作为viewId。 - viewPath 与 viewId 重复时的解决方案
经过对viewPath的优化，SDK 已经尽可能的保证了viewPath的稳定性。但是并不表示只依靠viewPath就能区分所有的点击事件。有时同一个viewPath的 view 具有不同的表现形式与作用，例如下面的情况：
同一个按钮在不同的状态下，显示不同的文字。例如：一个按钮在未添加商品前显示“添加”；添加了商品之后，立刻显示成“清除”
同一个view上具有多处点击事件，例如 SegmentControl、UISwitch、UIStepper等
上面的这2种情况，都是同一个viewPath对应多个事件，此时如果只使用viewPath无法区分出不同的状态或事件。
针对这类问题，SDK 的解决方案是：viewPath + “其它信息” 。这里的 “其它信息” 是视不同情况而定的，比如: 在上面的情况1中，“其它信息” 就是按钮的 title。在情况2中，“其它信息” 是 SegmentControl 的 selectedIndex 和 UISwitch 的 isOn 属性的值。SDK 在进行数据收集时，会上传 view 的这些信息，再结合圈选SDK就能让后台在做统计时区分出这些不同的事件了。
关于“其它信息”，再补充一点，除了 SDK 事先知道要获取的信息之外，还有一类就是业务数据。例如：有一个商品列表页，每一行显示一个商品，如果后台想统计的不是列表中每一行的点击，而是每个商品的点击，那么此时的“其它信息”就应该是productId 了。关于 SDK 对业务层数据的获取与上报请看下面的介绍。
SDK无埋点业务数据收集的实现
讲完了 viewPath 之后，接下来详细介绍下 SDK 的另一个关键技术：基于 viewPath 与 KVC 实现 SDK 的无埋点业务数据收集功能。首先，先简单分析一下传统的 代码埋点 存在的缺点，大致有以下几个：
埋点代码与业务逻辑代码混合在一起，增加了代码的维护成本；
埋点代码需要跟随APP版本一起发布，耽误数据的收集与统计；
埋点时存在错埋、漏埋等情况，无法动态更新及添加；
为了解决上述的 代码埋点 的缺陷，SDK 实现了真正意义上的 无埋点 来对业务数据进行收集。
- 无埋点的实现架构
SDK 的无埋点功能的实现主要依赖于 viewPath 与 KVC。viewPath前面已经介绍了，它主要用于标识viewTree中的某个 view。而KVC对于 iOS 开发者也不陌生，堪称 iOS 开发中的黑魔法之一。通过KVC我们能够通过 key 或 keyPath 直接访问对象的属性，而不需要调用明确的存取方法。关于KVC如果不太了解，请自行学习，这里不再过多阐述。
那么如何实现不需要代码埋点就能随意获取想要的业务数据呢？先看一下 SDK 的无埋点技术的整体架构图：
从上图可以看出，在实现 SDK 的无埋点数据收集时，主要分为3步：上传KVC配置、请求KVC配置、业务数据的收集与上报。
- 什么是 KVC 配置
在上图中出现了 KVC配置，那么下面先简单介绍下什么是KVC配置。其实 KVC配置 就是一些用来描述 App 应该在什么时机去收集什么数据的信息，包含的主要信息有：
appKey：用来标识是哪个应用
appVersion：用来标识应用的版本号
viewEvent：标识某个事件类型（收集时机），例如：ButtonClick、ListItemClick、ViewTap等
viewPath：目标 view 在viewTree中的信息
keyPath：目标 view 与要收集的业务数据间的关联路径，用于KVC取值
keyName：为要收集的业务数据定义一个key，最终组成 key-value 的形式上报。用于区分多个收集的数据
- KVC配置的上传与下发
上传KVC配置
利用 圈选SDK 上传 KVC配置 的操作对于用户是透明的，主要由开发人员进行上传与管理。此操作可以在任何时候进行，在想要收集某个或某些版本的 App 中的业务数据时，上传相应的KVC配置信息至后台即可，达到了根据需要动态可配的效果。
请求KVC配置
SDK 在初始化时会触发 KVC配置 的请求操作，从后台拉取 App 当前版本对应的所有KVC配置，并将请求结果缓存起来，以提供给下一步使用。
- 业务数据的收集与上报
这一部分是 SDK 无埋点技术的核心，接下来详细介绍这部分的实现逻辑。它的实现流程如下：
这个环节的核心是基于viewPath的 view 匹配，主要实现是通过循环遍历viewPath的每个节点的信息与当前 view 及其父view 依次进行匹配。因此这一步会产生一定的时间与性能消耗。为了尽可能减少这部分的操作，SDK 中使用了一些方式进行优化，其中一个就是基于缓存view的优化。
4.1 基于缓存view的优化
SDK 采用缓存上一次匹配成功的 view 信息的方式，来减少一些不必要的viewPath匹配操作。这里主要缓存的 view 信息有：
targetView：上一次通过viewPath匹配成功的 view 对象。
indexPath： 上一次通过viewPath匹配成功的 view 的indexPath，如果没有则为nil。
- viewEvent 匹配
第一步先进行事件类型的匹配。如果KVC配置信息指定的 viewEvent 是 ButtonClick，那么可以轻松的过滤掉 ListItemClick、ViewTap 等其它事件。这一步能够过滤一大部分事件，只有事件类型匹配成功才继续进行下一步。 - targetView 匹配
接下来就是将缓存的 targetView 与当前 view 进行比较。如果两者指向同一对象，则进行第3步，否则直接进入第4步 - 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步的结果一定正确。
因此，在第2步的基础上又增加了indexPath匹配。indexPath的匹配逻辑为：如果缓存的indexPath不为nil并且与当前view的indexPath不相等，则进入第4步；否则表明当前的 view 就是上次刚刚匹配成功的，也就没必要进行viewPath匹配，可以直接进入第5步。
- viewPath 匹配
这一步就是对当前的 view 及其父view 与KVC配置中的viewPath的各个节点进行逐个匹配。由于是一个循环操作，因此会有一定的时间消耗，其实在这部分的匹配中，也做了一些简单的优化。在真正进入循环匹配之前，先进行如下3步判断：
判断 view 类名是否相等；
判断 view 所在的 viewController 类名是否相等；
判断 view 所在的 window 类名是否相等；
上述的3个判断也能过滤很多不必要的匹配。只有这3个判断均通过后，才进行viewPath循环匹配。
- KVC 取值与上报
到了这一步，就已经验证了数据收集的时机是正确的。接下来就可以直接使用 KVC配置信息中的keyPath调用 valueForKeyPath: 方法获取对应的值。如果值不为nil，就与 keyName 组成一个键值对，放到当前的事件数据中一起上报上去。这样后台就可以通过key去查找到相应的业务数据了。
上面只是简要介绍了一下匹配时的逻辑，在实际开发中还会添加对 cell 的indexPath通配的情况的处理，由于文章篇幅这里不再详细讲解。 - 增加对 KVC 的异常处理
SDK 的无埋点功能的实现其实主要依赖于KVC，但是众所周知，KVC是非常危险的，很容易造成程序崩溃。例如一旦 key 或 keyPath 所对应的属性名不存在，立刻会导致程序抛出一个NSUndefinedKeyException异常，如果应用没有处理此异常，程序就会Crash。
因此，为了避免程序Crash，SDK 内部增加了对KVC异常的处理。具体实现是给 NSObject 增加一个 Category ，重写 valueForUndefinedKey: 方法，并在方法中return nil。
@implementation NSObject (KVCExceptionHandler) - (nullable id)valueForUndefinedKey:(NSString *)key { return nil; } @end其它关键技术
当然，SDK 的实现中还有很多关键技术点，比如：SDK 对 RN 页面的数据收集、页面别名方案的实现、Method Swizzling与Aspects的兼容等。由于本文的篇幅已经很长了，而且考虑到大家读文章的耐性都不会太长，所以这里就先不讲解了，后续会再写文章单独介绍。
END
文章写了这么多，其实主要介绍了 SDK 中的两个关键技术点，希望对你们能有一些参考价值。另外，如果有人对本文的方案有更好的建议，欢迎一起讨论学习。
最后，要特别感谢我的同事王佳乐，由于他对文章的排版与校对工作，才使得本文能更好的展示给大家。同时也要感谢组内的所有同事，在我开发遇到困难时，给予了我很多的帮助。
Q & A
关于对本文内容提出的一些问题，将全部记录在这里（简书评论里的除外），并进行统一解答。
Q1: SDK 都使用KVC配置获取业务数据，是否会增加维护KVC配置的工作？
A1: 会有对 KVC配置 的维护与管理工作，不过 SDK 也简化了这块的管理工作。
一般来说，上传的所有的 KVC配置 需要与 App 的版本相对应，因为 App 版本不同会直接导致keyPath可能不一样。所以与 KVC配置 相关的工作有如下2个：
针对当前 App 版本上传相应的 KVC配置，以获取想要的业务数据
当 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各自的点击量？
针对这种场景，SDK 的解决方案是：“关心位置” + “关心内容”。
“关心位置” 的意思是只使用当前的位置，具体表现是viewPath中不包含任何通配符；“关心内容” 的意思是指定一个想要统计的内容。
整个过程可以分解为如下3个环节：
圈选SDK上传“关心位置”的KVC配置。KVC配置中指定获取活动的url的keyPath。
数据SDK在活动发生点击时，收集当前活动对应的url，并跟随点击事件一起上报。
圈选SDK上传“关心位置” + “关心内容”的圈选配置，关心的内容指定为想要统计的活动的url值。
A2.2 同一内容显示在不同的位置
例子：App 首页有4个固定的入口，假设其中一个叫“热门推荐”，那么根据后台配置的顺序不同，“热门推荐”可能被显示在4个位置中的任何1个，即一段时间显示在第1个，过一段时间可能显示在第2个位置。这时如何统计出“热门推荐”的点击量？
针对这种场景，SDK 的解决方案是：“不关心位置” + “关心内容”。
“不关心位置” 是指viewPath中含有通配符，用于表示viewTree中的多个位置。例如想要匹配列表所有行时，则将viewPath中的indexPath替换为通配符。
这个问题的解决过程也分为如下3步：
圈选SDK上传“不关心位置”的KVC配置。KVC配置中指定获取入口的 title 的keyPath。
数据SDK在4个中任何一个入口被点击时，都去收集入口的 title，并跟随点击事件一起上报。
圈选SDK上传“不关心位置” + “关心内容”的圈选配置，关心的内容指定为“热门推荐”。
到这里，数据收集与圈选配置的工作都已经做完了，接下来就是后台的数据统计了。
上述2种情况对后台进行统计没有区别，都使用一个统计方案，这里也介绍一下后台大概的统计思路：
拿到第3步中上传的圈选配置，根据viewPath 与 “关心的内容” 生成一个正则表达式，然后从数据 SDK 上报的原始数据中进行正则匹配，进而统计出相应数据。