pingback系统的进化

所有的项目，只要到一定级别 都会涉及到此问题，它用来收集用户操作行为，统计用户的焦点点击，以及测试page到达率，相关业务的转化率等有着最重要的指标。公司都是根据此数据来做出决策，其实高层作出决策的最重要依据，也受各大领导关注最多的东西，重要性不多说。
现在，我想总结一下在我经历的过程中这个不是系统的东西变成系统的过程。
1.在APP 3.0版本之前 ，后端，前端都是发送最重要的统计数据，其只想当于一个上传接口，将一段json串串给后端，在VC中我门通过AFNetwork，ASI 直接去网络请求，没有架构，没有耦合，完全case to case处理 ，遇到一个处理一个

2.在APP 4.0版本 我们将这个单独出来成为一个库开出来几个接口，大家传入一些参数，然后这个模块来处理 缓存，上传时机 ，批处理等各种策略。这个时候的APP业务还是比较单一，相对来说 1.0 可以耦合复用 拉出来为库即可。

3.在APP5.0版本 整个移动业务 各个公司都受够了APP版本迭代慢的问题，开始出现平台化架构模式来满足千变万化的运营需求，内容编辑需求，甚至广告展示需求，在一个page内可以配置出尽量多的模版。由后端来决定前段展示的样式，这也就造就了要统计的东西爆发性的增长，由于页面都是动态的配置所以，所以发送时机需求的实时化 统计参数的直线增长，使得原有的接口已经完全无法适应当前的需求，那么重构随之而来。
这次重构主要解决两个问题：
1.发送时机可控制
2.demol依托后端数据结构，即后端可控
3.如何平滑过渡旧版本
4.性能

解决了此问题，感觉以后再也不用折腾了，然而变化太快了。

4.在6.0版本，伴随着公司收购，伴随着各个赚钱的业务均整合到移动端，随之而来的 统计系统有3到4个系统（各个业务以前都有自己的独立统计），初始的时候，各个业务都是以库的形势加入，这样能快速整合进工程享受基线带来巨大流量变现，但是随着业务加入的增多，导致工程中集合的统计库都有N个，并且各种发送时机，导致包一下大让人惊人，并且有些第三方库竟然重复N边，随着老大的强硬，这次整合也在所难免，这次重构主要解决的问题是：
1.整合各个业务线的统计系统，以后规整成一个
2.基线所有统计的库去重，
3.各个业务可自定义参数
4.提供改变固定参数接口，以适应特殊业务需求改变固定参数的需要。
5.提供平滑过渡方案。