提到移动客户端的优化，大家首先想到的可能就是页面的流畅度，也就是CPU和GPU的渲染问题，以此来提升用户的体验，然而对于CPU和GPU渲染的优化又是APP优化的两把尖刀，让一个app提升用户量和体验度有较高的推动力。然而让我们无法预估的就是用户的实际操作，也就是已经发出去的版本，我们很难知道用户喜欢什么功能和他们想要什么功能以及他们习惯于什么样的操作姿势，包括用户安装、卸载不用的情况，并且对潜在的线上崩溃问题，作为一位开发者我们就很想知道错误出现的精确位置以及错误信息，这些对一个APP的成长来说将是一个关键的导向作用，其实这也算是APP的一个比较重要的优化方案。
对于以上出现的问题，开发者更关心APP的Crash问题，而对于产品来说，他们更关心用户的喜好、行为和需求，以便于产品设计出更好的需求解决方案，目前市场上也出现了专门的问题解决方案，比如友盟统计、bugly统计、小米统计等，对于一个小型方案我们可以采用第三方的统计方案，但对于一个日活百万乃至千万的APP来说用第三方的统计方案就会受限很多，于是拥有自己的一套统计方案就显的刻不容缓了，掌握市场的方向，我们就掌握了主动权，那么我们怎样去设计一套准确优良的统计方案。
一 、统计分类
1.1 传统的pc端统计
以老牌的pc上的web页面统计一般有PV.UV,和IP之分，对于crash问题，本身web页面就存在远程的服务器端，日志将会保存在服务器的目录，所以一般web项目开发者无需考虑收集Log的case,那么我们更care的就是上面说的行为统计，下面说说这三种统计区别。
2. 2、IP、PV和UV分别是什么意思?
IP，实际上也就是指独立IP,是独立IP数的意思。00:00—24:00时间内相同IP地址只记录一次。即使你有多台电PC，但是如果IP地址是一样的，那么也只能算是一个IP的访问,IP数据依然为1。当然多台pc的ip一般都不一样，除非你插上同一个网络端口然后换零一台连接，都是一样，同时连接多台，每台pc的IP就是不一样的。
PV, 指访问量，它的英文是PageView，具体是指网站的是页面总浏览量或者点击量，页面被刷新一次就计算一次。如果网站被刷新了10次，那么流量统计工具显示的PV就是10 。
UV，它是独立访客的意思，英文为Unique Visitor。具体指访问您网站的一个客户端(移动设备或者是电PC)为一个访客。00:00-24:00内相同的客户端（mac地址区分）只被计算一次。
3 . 3 IP、PV和UV之间的关系是什么?
1.3.1.IP和PV之间的关系
PV是和IP的数量是成正比的，因为页面被刷新一次那么PV就会被记录一次，所以IP越多，说明网站的PV数据也就随之增多。但是需要注意的是PV并不是网站的页面的访问者数量，而是网站被访问的页面数量。因为一个访问者可以多次刷新页面，增加PV数量。
1.3.2 .IP和UV之间的关系：
在记录网站流量统计数据时，运维有时候发现这样一种情况：有时候网站的IP数据大于UV数据，有时候UV的数据也会大于IP数据。为什么会出现这种现象呢?我们可以用一个例子来说明。比如，用同一个IP去访问我们的某个网站，但是一个是用的台式的电脑，一个是用的笔记本，那么网站流量统计工具显示的数据就会是2个UV，1个IP。这时UV的数据就会大于IP的数据。但是，再比如，只是用一个台式电脑访问我们的网站，但是一会拨一个号换一个IP，那么这时候网站流量统计工具显示的数据的UV就为1，但是IP的数据就会高于UV的数据。因此，IP和UV之间的数据并不一定存在比例关系，两者之间的数据也不是此消彼长的关系。
1.3.3.IP和PV之间的关系：
那么IP和PV的关系如何呢?如果一个IP刷新了网站100次，网站的PV就为100，所以从这点看二者之间没有多大关系。但是，我们可以通过IP和PV之间的数据差异，来更加深入的理解网站的流量数据。如果IP和PV的数据悬殊很大，比如，我们在查看网站流量数据时发现网站的PV是1000,IP为100，那么说明这个站点平均一个IP访问了网站内容10次，说明网站内容还是比较受欢迎的，所以访客才愿意在网站中停留那么久的时间，并浏览了那么多的网站页面内容。但是如果IP和PV的数据很接近，比如，网站的IP为100，PV为110，说明一个IP也就访问了网站内容大约1次，就说明网站内容的可读性太差，客户点击进去之后就离开了，没有有过多的停留。如果网站流量统计这样的数据过多的话，站长就需要对网站内容进行深入思考了，以便更好的提高网站的流量。
1.4 我们能从这边得到什么
鉴于已经很成熟的统计方案，我们在移动设备上（这里只说android）怎样实现一个完美的用户数据和行为统计，崩溃日志的套装方案呢。
二移动设备统计
那么我们的一个App，我们能做的那些方面呢
2.1 .1 用户数据（日活）
首先我们的可以加入ip，PV和UV统计模式，这样我们可以成功的get到app的日活，以及整体使用情况，
比如App启动了多少次，访问了多少h5页面，有多少个ip(设备)访问过，但是我们无法得native页面的信息（也就是Activity）服务端是是无法获取的，除非我们本地的页面有加载服务端数据的接口的功能，这种情况下服务是可以监控到本页面的数据流量的，但是在断网情况下，服务端是无法及时获取日活数据的，那么怎么解决呢，这里先不说，先看下个要解决的问题。
2.1.2 用户行为
获取到了APP整体流量后，怎么能知道某个功能受欢迎，或者某个本地页面经常被用户使用呢，则具体行为统计是app必须的， 目前一般由客户端和服务器端协商好一套自定义事件字典（也就是所谓的统计id对照表），当用户使用某个功能时，我们将对应的功能id发送到后台。这样服务端就有统计用户行为的能力了，那么这种只是一种初次尝试的想法，那么断网，或者功能多的情况子下，我们有如何采集用户行为呢
2.1.3 Log日志
那么对于线上的app版本，又是怎样收集carsh日志呢。一般我们在app崩溃的时候发送一条请求到服务端，是可以实现的，但没必要做，一般是将日志保存到本地，在某个时间或者case触发上报行为，
一般统计策略不会采用单一的方式进行上报，多采用组合的形式实现，服务器和客户端，有网和没网，实时和不定时。主动和被动的策略。
客户端请求接口是 统一包含特定的请求头，服务端的每个接口中可以去采集这些请求头 记录访问量 包括ip，PV,UV , 这样可以去捕获一定的用户数据。
服户端也可以采用推送的形式，让客户端去发送特定的采集好信息上报给服务器。
统计一般大多体现在客户端，我们可以将一个整体的app分解成多个模块，每个模块有多个功能，功能又分为用户主动和被动接受之分，给每个域分配一定的ID，那么在用户使用某个功能时 我们动态记录这个ID（比如登陆和注册一般属于用户中心（001）,登陆和注册输入两种功能，分别给03,04标记，登陆属于用户主动 那么可以给 01，注册被动跳转给02）, 最后写入到本地保存，那么用户打开用户中心登陆产生的的数据信息就0010201 ，这样服务器能知道，我们只要在某个时间点将文本数据上传即可，即使没网络情况下我们也不怕，等设备有网的情况下 我们偷偷上报即可，那么我们也可以在用户登陆的时候时侯同时就上传这些数据，这个策略视具体功而定。
一般一个APP统计有模块域 ，功能域，事件域，由大到小分配而来，也有按页面区分的，具体看实际的需求场景而定
对于我们的app crash 我们可以继承android自带的全局异常类（UncaughtExceptionHandler），来进行自我捕获异常，和用户行为一起上报。
也可以单独加个意见反馈功能，采集用户的吐槽和建议。
说了上面一大堆策略问题，对于开发而言很可能觉得很无聊，那么至于统计其实没什么技术含量（用户设备的唯一标识符除外），无非就是采集数据写到文件中，请求发送数据，最重要的还是一种策略的定义。
主流的多采用 时间戳，内存大小（日志积累到多大字节），次数（总计积累到多十条）等，
对于好的统计，我们可以检测网络，检测home建来触发我们的上报数据接口，也可以采用注册静态广播，用alarm 闹钟定时上报数据，然后这些技术也就是被大家玩透的功能而已，没必要再这里给大家补脑，但是注意的是
统计设备唯一标识符的确定， 这个以后再去分析.
统计上报接口采用分布式，不然所有数据都请求同一个接口，那么日活大的情况下，服务器挂了 不仅无法收到数据，反而影响客户端其他正常的功能
