在主打产品的世界里，有一个需求点是如何及时了解用户对于自己产品的使用习惯和感受。特别是在互联网产品中，依赖用户的主动反馈来了解他们的产品使用体验显然是非常被动的、延迟的。特别是在一些用户个性化明显的产品中，如何获取用户的使用特征是非常重要的。当然，为了获得最直接最优秀的产品迭代方向，几乎所有的互联网产品都有自己的方案，这种方案其实可以统一的称为：数据埋点。数据埋点最直接的表述就是在产品中埋下一些信息采集的功能。针对软件产品的话，就是在特定业务点、特定的代码段添加数据采集的逻辑代码。用户在使用产品的过程中，会触发预留的数据采集逻辑，客户端通过网络交互将数据发送给后端服务器，后端服务器收到数据后会通过算法分析出用户的个性特征或者使用习惯，从而可以顺着大部分用户喜好的方向进行产品的演进和迭代。
演进史针对于数据埋点方案，在安卓应用中，其实有很多已经很成熟的方案，当然，这些方案是随着产品经理和研发人员对于需求和技术持续深入的了解和创新来实现的。在最早的时候，大部分研发人员都是通过手动在对应的项目代码处添加埋点采集代码，这种方式实现简单暴力，缺点是需要研发人员对整个项目代码很熟悉，并且需要进行很多重复单一的埋点任务。为了解放软件开发人员的开发时间，市面上慢慢出现了很多以提供简洁高效的埋点方案的软件服务型企业。这些企业的产品提供以SDK的形式集成、支持一定采集能力。这在一定程度上，解放了应用开发者的工作时间，让他们可以把精力投入到产品自身功能的开发之中。然而在某些大型或者数据比较敏感的应用中，采用他方的埋点采集产品可能会造成自我产品数据的泄漏和用户数据的泄漏，这是很严重的问题。因此，埋点采集方案在各个公司内部，甚至是产品线内部都会有自我独特的实现方式，这也很大程度上促进了数据埋点技术的发展。在不长的演进历史中，慢慢出现了自动化埋点方案、无痕埋点方案、可视化埋点方案等优秀的埋点技术。这些埋点技术的核心目标都是为了解放软件开发者的双手，实现简单、高效、可配置的埋点方案。
分类在这些埋点方案中，从不同角度，他们可以被归属为不同的埋点类型，各自都有自己的优缺点。下面具体讨论一下。从埋点的范围来看，笔者将之分为：
全埋点
针对应用中所有可埋点的地方都进行埋点，通过一种配置文件来决定埋点是否触发采集和上报逻辑，这种配置可以使本地的，也可以是网络下发的。
它的缺点是对埋点的技术手段有较高的要求，可能会对应用的性能产生一定的影响；
它的优点是使用简单，灵活配置，可以实现线上制定策略、应用远端获取并使用的能力。灵活可配置是其最大的优势
定向埋点
只对应用中需要埋点的地方进行埋点，每个埋点都会触发采集和上报逻辑
它的缺点是需要软件开发者对自身应用的业务逻辑非常熟悉，才能准确的在对应地点添加采集逻辑，另外就是需要进行比较繁琐和单一的编码工作
它的优点是埋点范围较小，对应用性能的影响偏小
从实现埋点的技术方案来讲，可以分为侵入式埋点和非侵入式埋点：
侵入式埋点
侵入式埋点主要体现在需要软件开发者以某种方式在自身应用的业务代码中添加数据采集的逻辑代码
它的缺点是需要开发者手动的去在应用代码甚至是业务代码中进行埋点代码的插入
它的优点是埋点位置准确，效率较高
非侵入式埋点
与侵入式埋点正好相反，不需要开发者在自身应用的业务代码中添加任何的采集逻辑代码
它的缺点埋点位置可能不准确
它的优点是开发者无需进行额外的埋点代码插入
从可视化的角度来讲，可以分为可视化埋点和非可视化埋点
可视化埋点
这是一种比较高级的埋点方法，客户端通过一次初始化，将扫描到的应用视图层级以格式化的数据上传到服务端(当然还包括当前页面的截图)，前端管理模块将这种格式化的数据还原成页面，这样，就可以通过在前端页面进行配置操作来完成埋点配置的生成。
它的缺点是实现方案比较复杂，对客户端和前端的技术要求比较高
它的优点是用户体验非常好，埋点配置操作简单透明
非可视化埋点
不具备可视化埋点功能的方案都可以归属为非可视化埋点，也可以将传统的埋点方案归属为非可视化埋点。
它的缺点是相对可视化埋点而言的。用户体验较差。
它的优点是实现相对简单可靠
其实，数据埋点的技术方案有很多种，最简单暴力的定向埋点是由软件开发人员按照埋点业务需求来进行的编码插入。这是最基础的埋点方案，也是效率最低的埋点方案。反观近几年比较流行的全埋点方案，它的时间成本则小很多。这里也是主要讲解一下关于全埋点、无痕埋点、可视化埋点这几个比较高级的埋点方案的具体实施技巧。
关于全埋点全埋点需要解决一个很直观的问题，就是如何通过代码找到所有的埋点位置，比如说，针对一个安卓应用，如何对所有的触控事件进行埋点，这里的触控事件包括点击、滑动、文本输入、菜单选择等等。
通常来讲，这里是可以通过反射来处理的。在应用启动后，我们可以通过遍历当前页面的视图结构，找到支持触控的控件，对这些控件的监听器进行改造，在不影响原始业务逻辑的前提下，插入埋点的业务代码。当然这只是一种思路，在实际实现过程中，可能会遇到一些问题，比如：反射的api被系统限制、窗体外的视图处理、自定义控件的处理。这些都是比较棘手的问题。这里提供一种简单的处理方式，就是对控件的Touch事件进行拦截，然后包装原始的onTouch事件，这样既不影响原始的业务逻辑，也能获取到控件的触控信息。其中监听应用的页面变化，可以利用Application.ActivityLifecycleCallbacks来处理，这个接口能够将所有的Activtiy生命周期回调进来，从而可以对安卓中最主要的视图组件Activity进行改造。另外，对于视图中的控件处理，可以参照以下方式：
当然，对于当前窗体外的控件(主要是一些对话框)，需要针对系统的窗体管理器来获取到当前的窗体视图，从而对该视图进行处理。这里可以参照笔者另外一篇关于hook系统WMS的文章。
简而言之，这种全埋点方案的核心是对当前页面的视图树的遍历，对控件Touch事件的处理，实现起来比较容易。
所谓的无痕埋点就是不需要开发者在自身的应用中嵌入任何的埋点代码，通过某种注入或者自动化嵌入的方式来完成所有的埋点工作。无痕埋点所需要解决的问题就是在什么时刻注入埋点代码。你可以在java文件被编译为字节码文件后，对字节码文件进行处理；你也可以在字节码文件被编译为dex文件时进行处理。在不同时刻处理意味着需要采取不同的技术手段。
字节码文件注入这是一种面向切面的编程思想，利用业务项目已经生成的字节码文件，通过字节码注入手段(ASM等)，在应用打包流程中将埋点业务代码以字节码的形式注入到其中。这种方案可以借助字节码注入框架以及gradle插件来实现参照此处，大致思路是：
编写gradle插件，主要目的是获取项目打包流程中的字节码文件编写埋点逻辑代码，准备注入到业务应用中通过字节码工具框架，识别原始的字节码，将需要埋点的逻辑注入到对应的字节码位置 dex文件处理事实上，dex文件和字节码文件一样，都是一种格式严谨的紧凑型文件，字节码文件转换成dex文件时，是利用的dex.jar包里面的主要方法，因此，我们可以对该工具库进行本地化改造，添加我们的勾子方法，从而实现在生成dex文件的过程中注入我们的埋点逻辑，这种方式的难点在于对原始的dex.jar的改造，需要对字节码文件和dex文件的格式有深入的研究。
关于可视化埋点上文提到过，可视化埋点是一种用户体验极好的一种埋点方案。它的核心是客户端上报应用的视图结构和视图的截图，前端管理平台通过这些格式化的数据来还原应用的页面视图。这种方案中需要处理的细节处比较多，因为业务应用自身的视图结构，页面跳转逻辑都会对视图树获取产生一定的影响，所以说，客户端在获取视图树的时候需要很细致的处理。这里可能会包括控件的大小、控件的位置、控件的可见性等等。对于前端，如何利用这些收集到的视图树数据来还原视图，也是一种挑战。在移动设备上，屏幕大小的分布很广，屏幕的密度分布也不尽一样，这就造成了同一个页面在不同的设备上，显示效果可能不一样。而前端需要保证在管理页面中，所有的页面呈现出的样式都是一样的，并且控件的触控属性也是需要保持一致的。在这里面，其实还有一个问题：就是控件的标识。
对于控件的标识，有一种简单而又有效的方式。就是利用控件在整个视图树中的路径来表示。通过扁平化这种表示来标记控件的绝对位置。
在互联网这个浪潮中，每个领域可能都会细分出某种技术体系，就像对于数据埋点这个简单的需求，市场上就存在多种可供选择的技术方案。本文只是抛砖引玉，介绍了目前几种比较流行的技术方案，分析了他们的利弊。笔者相信，在以后的技术演进中，埋点方案肯定会产生新的技术实现，并且随着互联网技术体系的演进，对于如何去解决数据埋点的这些方案肯定是更加高效、更加简洁、更加可靠的。