前言

谈到移动APP开发的优化方案，开发者第一时间会想到关于GPU渲染和CPU优化问题，而这两大方案确实是优化app的两把尖刀，使APP提升用户量和体验度有较高的推动力。然而我们却会忽视一个比较简单而又难记住的方面，是对用户潜在行为的预估和把控，其实也属于APP业务优化范畴。
在无法预估的就是用户的实用操作欲望的情况下，针对已经发出去的版本，我们很难知道用户喜欢什么功能，和想要怎样的功能，包括用户卸载了，甚至安装不用的情况，并且对潜在线上崩溃的问题也想知道问题出在哪里等等，这些对于app的成长优化也有关键的导向作用，其实这也可以算是一种对app的优化方案。

对于上面存的问题，一般开发者所关心的是已发版的crash的问题，而产品更关心的是对一个用户行为体系的采集和预研，那么这种专门解决化方案出现了，第三方的统计化框架（SDK）, 比如市场的友盟，小米，百度等提供的统计sdk, 对于一个小型的项目，我们可以采取第三方来实现，那么对于一个成熟包括万级日活的应用，那么属于自己的一个日志统计体系是刻不容缓的，掌握了市场动向和用户行为，就能拥有了主动权，拥有客户就是拥有了市场，那么怎样去设计实现一种优良的行为统计方案？

统计分类

PC端统计

以经典的pc上的web页面统计一般有PV.UV和IP之分，对于crash问题，本身web页面就存在远程的服务器端，日志将会保存在服务器的特定目录，所以一般web项目开发者无需考虑收集Log的case,那么我们更care的就是上面说的行为统计，下面说说这三种统计区别。

IP、PV和UV含义

IP，实际上也就是指独立IP,是独立IP数的意思。一天24h内相同IP地址只记录一次。即使你有多台PC，如果IP地址是一样的，那么也只能算是一个IP的访问,IP数据依然为1。当然多台pc的ip一般都不一样，除非你插上同一个网络端口然后换零一台连接，都是一样，同时连接多台，每台pc的IP就是不一样的。

PV, 指访问量，它的英文是PageView，具体是指网站的是页面总浏览量或者点击量，页面被刷新一次就计算一次。如果网站被刷新了10次，那么流量统计工具显示的PV就是10 。

UV，它是独立访客的意思，英文为Unique Visitor。具体指访问您网站的一个客户端(移动设备或者是电PC)为一个访客。00:00-24:00内相同的客户端（mac地址区分）只被计算一次。

IP、PV和UV关系?

IP和PV之间的关系

PV是和IP的数量是成正比的，因为页面被刷新一次那么PV就会被记录一次，所以IP越多，说明网站的PV数据也就随之增多。但是需要注意的是PV并不是网站的页面的访问者数量，而是网站被访问的页面数量。因为一个访问者可以多次刷新页面，增加PV数量。

IP和UV之间的关系：

在记录网站流量统计数据时，运维有时候发现这样一种情况：有时候网站的IP数据大于UV数据，有时候UV的数据也会大于IP数据。为什么会出现这种现象呢?我们可以用一个例子来说明。比如，用同一个IP去访问我们的某个网站，但是一个是用的台式的电脑，一个是用的笔记本，那么网站流量统计工具显示的数据就会是2个UV，1个IP。这时UV的数据就会大于IP的数据。但是，再比如，只是用一个台式电脑访问我们的网站，但是一会拨一个号换一个IP，那么这时候网站流量统计工具显示的数据的UV就为1，但是IP的数据就会高于UV的数据。因此，IP和UV之间的数据并不一定存在比例关系，两者之间的数据也不是此消彼长的关系。

IP和PV之间的关系：

　那么IP和PV的关系如何呢? 如果一个IP刷新了某个网站1000次，网站的PV就为100，所以从这点看二者之间没有多大关系。但是，我们可以通过IP和PV之间的数据差异，来更加深入的理解网站的流量数据。如果IP和PV的数据悬殊很大，比如，我们在查看网站流量数据时发现网站的PV是1000,IP为300，那么说明这个站点平均一个IP访问了网站内容10次，说明网站内容还是比较受欢迎的，所以访客才愿意在网站中停留那么久的时间，并浏览了那么多的网站页面内容。但是如果IP和PV的数据很接近，比如，网站的IP为100，PV为110，说明一个IP也就访问了网站内容大约1次，就说明网站内容的可读性太差，客户点击进去之后就离开了，没有有过多的停留。如果网站流量统计这样的数据过多的话，产品就需要对网站内容和功能进行深入思考了，以便更好的提高网站的流量。

移动开发我们能从这边得到什么

鉴于已经很成熟的WEB统计方案，我们在移动设备上（这里只说Android）实现一个完美的用户数据和行为统计，崩溃日志的套装方案该怎样做？

stat.jpg

移动设备统计

一款App，我们在通过上面的情况又该做的哪些呢

用户数据（日活）

首先我们的可以加入IP，PV和UV统计模式，这样我们可以成功的get到app的日活，以及整体使用情况，
列入App启动了多少次，访问了多少h5页面，有多少个ip(设备)访问过，但是我们无法得native页面的信息（一般都是Activity），服务端是无法获取的，除非我们本地的页面有加载服务端数据的接口的功能，在某个接口（API）中捞数据，这种情况下服务是可以监控到本页面的数据流量的，但是在断网情况下，服务端是无法及时获取日活数据的，那么怎么解决呢？。

用户行为

获取到了APP整体流量后，怎么知道某个功能受欢迎，或者本地某个页面经常被用户使用，则针对这种需求，app实现具体行为统计是必须的，目前一般由客户端和服务器端协商好一套自定义事件字典（也就是所谓的统计id）当用户使用某个功能时，我们将对应的功能id发送到后台。这样服务端就有统计用户行为的能力了，那么这种只是一种初次尝试的想法，那么断网，或者功能复杂的情况子下，我们又如何采集用户行为？

Log日志

那么对于线上的app版本，又是怎样收集carsh日志呢。常规做法在app崩溃的时候发送一条请求到服务端，是可以实现的，但没必要这样做，一般是将日志保存到本地，在某个时间或者case来触发数据上报行为

统计

综合方式

业界的统计策略不会采用单一的方式进行上报，大多采用组合的形式实现，服务器和客户端，有网和没网，实时和不定时，主动触发和被动接受之分

Server

客户端请求接口是统一包含特定的请求头，服务端的每个接口中可以去采集这些请求头用来记录访问量包括ip，PV,UV , 这样可以去捕获一定的用户数据。

web端也可以采用推送的形式，在需要数据的时候让客户端发送特定采集好的信息上报给服务器。

Client

移动端统计一般大部分体现在客户端，我们可以将一个整体的app分解成多个模块，每个模块还可能有多个功能，功能又分为用户主动使用和被动接受之分，开发者给每个域分配一定的ID，那么在用户使用某个功能时我们动态记录这个ID（比如登陆和注册一般属于用户中心（用户中心的功能域001）, 登陆和注册属于两种功能，则分别给03,04标记作为事件域，登陆属于用户主动操作，那么可以给 01，注册被动跳转给02）, 最后写入数据保存本地，那么用户打开用户中心登陆整个流程产生的数据信息则为0010201 ，这样服务器能知道完整搜集此条用户操作，只要在某个时间点将文本数据上传即可，即使没网络情况下我们也不用担心，等设备有网的情况下我们偷偷上报即可，也可以在用户启动APP的时侯就上传这些数据，这个策略视具体功而定。

一般一个APP统计有模块域，功能域，事件域，由大到小分配而来，也有按页面（Activity）区分的，具体看实际的需求场景而定

对于APP 的crash 开发者可以继承android自带的全局异常类（UncaughtExceptionHandler）来进行自我捕获异常，或者读取系统log和用户行为一起上报

同时也可单独加个意见反馈功能，采集用户的吐槽和建议。

介绍了上面一大堆策略问题，对于开发而言很可能觉得很无聊，但是事实上至于统计其实没什么技术含量（用户设备的唯一标识符除外），无非就是采集数据写到文件中，请求发送数据而已，最重要的还是一种策略的定义。

何时上报
主流的多采用时间戳，内存大小（日志积累到多大字节），次数（总计积累到多十条）等，

对于一款好的统计方案，我们可以检测网络，检测home建来触发我们的上报数据接口，也可以采用注册静态广播，用alarm 闹钟定时上报数据(客户端轮询），然后这些技术已经是被大家玩透的功能而已，没必要再这里给大家补脑，但是注意的是，鉴于设备多样化统计设备唯一标识符很难确定，
统计上报接口采用分布式，不然所有数据都请求同一个接口，那么日活大的情况下，服务器挂了不仅不能收到统计数据，反而影响客户端其他功能的正常使用。

20160319155945072.png

接下来给大家带来一款自定义的统计SDK :TcStatInterface

TcStatInterface

Android StaticFrameWork

自定义统计SDK, 完全放弃第三方平台，让app拥有自主的数据统计功能

支持页面统计
自定义事件统计
APP启动退出统计
不同渠道统计
多版本多机型多区域统计
多时段，多场景上报

客户端SDK功能概述

在使用统计服务前，开发者先要拿到本身APPID。其中AppId是客户端的身份标识，在客户端SDK初始化时使用。然后下载最新Library的SDK压缩包，其中包括了Android SDK和AndroidDemo。Android版SDK以Module形式提供，你的APP只需要添加少量代码和配置，即可完成接入TcInterface统计服务。

统计服务Android

SDK所有的接口都封装在TcStatInterface抽象类的静态方法中，主要功能接口请参考GitHub ReadMe。应用在启动时，需要调用initialize方法来初始化统计服务，之后便可按照统计的业务需求，调用统计数据上报接口上报统计打点。
SDK提供了接口给开发者来设置向统计统计服务器上报统计数据的策略，开发者可以在任意时候调用修改策略。客户端SDK上报的数据包括默认事件统计、应用全局(AppAction)统计（用于统计app的唤醒、打开关闭频率、使用时长等）、页面访问统计(Page)和自定义事件(Event)统计。

统计SDK提供app的崩溃日志收集功能（统计SDK2.0 将会新增）。功能开启后，对于app在使用过程中的崩溃，SDK将自动采集崩溃日志，并上传到统计后台；统计后台会根据app版本，对崩溃进行聚合、展示。开发者可以根据app实际情况情况，将该崩溃标记成已处理或者忽略状态。

注意
由于是自我的统计服务，目前服务端代码需要开发者自我实现，数据结结构按客户端数据结构实现即可。

华丽的结尾

你的统计SDK你作主，是时候和第三方统计说再见了

Github:
https://github.com/NeglectedByBoss/TcStatInterface

原文链接：http://www.jianshu.com/p/cd83e81b78aa

App打造自定义的统计SDK相关推荐

App打造自定义的统计SDK, 是时候和友盟说分手了
转: App打造自定义的统计SDK, 是时候和友盟说分手了前言谈到移动APP开发的优化方案,开发者第一时间会想到关于GPU渲染和CPU优化问题,而这两大方案确实是优化app的两把尖刀,使APP提升 ...
android 统计app使用时间,android开发之app在线时长统计sdk开发
引言: 很多app的在线时长统计都是通过在activity的生命周期中埋点来完成的.我这里既然是封装成sdk,当然就不能这样来了.封装sdk的规则,我想大家都清楚,入参尽量少,回调尽量全,权限尽量不要 ...
Android开发-在Android项目里集成友盟统计SDK进行对移动APP统计的实现
前言友盟(Umeng),2010年4月在北京成立,是中国最专业.最有数据凝聚力的移动开发者服务平台.友盟以移动应用统计分析为产品起点,发展成为提供从基础设置搭建-开发-运营服务的整合服务平台,致力 ...
App全渠道推广统计方案解析
在移动端,渠道推广的形式有多复杂?你可以在微信.抖音.微博等第三方App投放线上广告,也可以通过地推.地铁.公交车等线下渠道引流,还可以与其他App换量.鼓励用户邀请好友.短信邮件推广等,甚至可以跟专 ...
App全渠道推广统计方案
做过 App 运营岗位,肯定提过类似的需求: 自然新增渠道:自然新增的用户,想知道他们都是从哪下载了 App,以为初步分析下载原因,好在后续提供个性化推荐等服务. H5 推广渠道:开展活动需要分发大量 ...
自定义考勤统计日历(一)
在APP中实现日历的操作对于很多人来说或许都不太容易,因为根据要求的不同,日历的样式和显示的功能也不太一样,特别是对于一些初写代码,不太熟练写自定义接口的朋友,比如说我. 我们也会在网上经常看到一些日 ...
APP接入友盟统计，不上报数据问题
官方文档接入的流程大致如下: 主目录Build.gradle中buildscript .allprojects都加入仓库地址: maven { url 'https://dl.bintray.com/ ...
自定义自动统计字数EditText控件
自定义自动统计字数控件EditText 1.设置XML布局 <LinearLayout xmlns:android="http://schemas.android.com/apk/re ...
app应用市场下载统计攻略
目前安卓主流的应用市场有应用宝.360手机助手.百度手机助手.华为应用市场.小米应用商店.vivo应用商店.三星应用商店.阿里分发市场.安智市场,91助手 .当我们开发一款应用时同时需要上架这些市场 ...

App打造自定义的统计SDK

前言