对于项目来说都会有业务打点，传统的业务打点是：创建一个工具类，将打点的相关请求操作封装，业务方在需要打点的业务界面使用该工具类进行打点记录。这样做的缺点是：高耦合、工作量大、复用性差、引用脏代码等一系列问题。为了解决这一问题，我们可以通过hook的方式进行改善，同时将打点页面的相关信息配置到plist文件中，用plist进行管理和维护打点记录，同时加之以单元测试。三管齐下，让我的业务打点变得可维护、易更改、降低出错的概率等。
常规的交互有两种：1、页面统计，包括页面停留时间、页面进入次数；2、交互事件统计，包括单击、双击、手势交互等。
1、运用运行时埋点，在viewWillAppear方法中插入需要执行的打点代码段，用plist文件配置对应页面的pageId等打点信息，字典的key值可以用对应的类名来标识。
2、对于交互埋点，（控件点击、手势交互点击等），控件打点可以在UIControl的- (void)sendAction:(SEL)action to:(nullable id)target forEvent:(nullable UIEvent *)event;注入打点代码，也可以用plist文件来管理打点方法名和交互事件ID。
单元测试之前在项目中没有用到过，现在觉得真的是一本万利的一个方法，有了单元测试可以根据测试用例来快速验证项目中的一些改动可能会引起的bug。比如上面的打点需求，如果某个页面的类名或者事件打点方法名发生了变化，对应的plist文件如果没用对应的更改的话，打点记录就会失效。除非每次改动时你都没有忘记更改plist文件，对于多人合作的项目而言，这样的风险会更大，所以测试用例的单元测试是非常有必要的。
但是这样的应用虽然管理起来方便，也规解决了传统方式打点的缺点，但是还是有一些应用限制的，比如对于打点如果传递的参数不仅仅只是事件ID，还有其他业务耦合度很高的记录数据（比如用户对“打电话”按钮操作，可能会传递对方的电话号码等）这种方式还是会有问题的。
*************************
刚又想到了对应的解决方案，可以设置一个打点配置协议，在打点事件触发前，从协议中获取所需的业务打点参数。（对应的demo会在空闲时间给出）
综上：利用运行时打点是首选的推荐方案。
