无线APP日志上报优化实践
昨天，和大家讨论了无线APP时代如何进行DNS速度优化，今天和大家一起讨论一下无线时代的日志上报流量优化。
缘起：无线时代，APP流量敏感，为了统计APP内用户行为，或者需要收集某些产品数据，往往需要进行日志上报，日志上报往往又非常费流量，有没有一些好的节省流量的优化方法呢，这是本文将要讨论的问题。
一、APP可不可以不进行日志上报，而单纯从服务器日志统计用户的行为和产品数据？
答：不行，有些用户行为是不会与服务器进行交互的（例如TAB的点击），从服务器日志无法完成所有统计。
二、APP通常有一些什么方法来上报日志？
答：常用方法有三种：
1）利用类似于Google Analytics的第三方工具进行上报，优点是无需开发，缺点是不能做个性化统计
2）自己制订私有协议进行上报（例如TCP二进制协议），优点是节省流量，缺点是开发成本高
3）使用HTTP上报，例如通过GET参数传递需要上报的数据，这种方案使用最为广泛。
三、APP上报日志协议细节是怎么样的？
答：一般是在web-server下放置一个空文件，APP通过发起HTTP请求访问这个空文件，通过GET参数传递数据，通过分析access日志来得到想要的数据。GET协议一般又有两种方式，约定格式法 + KV法
1）约定格式法：约定分隔符，约定占位符，约定每个字段的含义，例如：
http://daojia.com/up?[bj][20151021][1939][1][login]
APP和server约定好，空白文件是up，分隔符是[]，第一个字段[bj]是城市，第二个字段[20151021]是日期，第三个字段[1939]是时间，第四个字段[1]是用户id，第五个字段[login]是行为
这个方法的缺点是，扩展性较差，有时候某些字段没有值，也必须在相应的位置保留占位符（因为每个字段是什么含义都是事先约定好的），要想新增统计项，只能在GET后面新增[]
2）KV法：通过自解释的kv方式来上报数据，上面的例子用KV法来上报，则上报形式为：
http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login
这个方法的优点是扩展性好（好太多了），缺点是上报数据量比较大，KEY其实是冗余的字符
笔者强烈建议使用第二种方法来上报数据，后文会简述一些流量的优化方法。
四、APP上报日志，流量很大，主要矛盾是什么？
答：笔者了解到的主要矛盾有：
1）无效的流量较多，HTTP请求内有很多无效数据
2）URL冗余，每次都要上报URL
3）KEY冗余，每次都要上报KEY
4）上报频度高，每当用户进行了一个操作都要日志上报的话，HTTP量还是很大的。
五、有什么优化的方法？
答：针对上述1）-4）的主要矛盾，逐一进行优化：
1）手动构造HTTP请求，尽可能多的去除HTTP中的无效数据，只保留GET /up HTTP/1.1和GET传递的数据
2）使用尽可能短的域名来接收上报的日志，例如s.daojia.cn/a
3）使用尽可能短的KEY来标识数据，例如city=bj可以优化为c=bj，日志收集方注意规范好KEY
4）批量非实时上报，先将数据保存到APP本地存储（例如sqlite中），定时上报，这类优化对于PV类，SUM类，AVG类统计尤为有效，例如，要统计登录按钮的点击次数，三次点击，传统统计可能需要上报三次
http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login
http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login
http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login
优化后，只需要上报一次（注意加了一个count=3的参数）
http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login&count=3
六、非实时上报，数据时效性怎么保证？在什么时机进行日志上报呢？
答：数据的时效性会有一定的影响，但问题不大。为了优化，会在这样的一些时间点进行上报：
1）特殊时间点：APP打开时，APP关闭时等
2）按时间上报：例如每隔10分钟上报一次
3）按数据量上报：例如每收集10条记录才上报一次
一般来说上述三种优化方法会结合进行。
七、还有其他什么优化方案？
答：数据压缩也是一种常见的优化方案。