怎样优化IM即时通讯移动端APP的日志上报机制

Posted 2022-07-15 wecloud1314

当前的移动互联网时代，移动端应用的流量昂贵和敏感，为了统计APP内用户行为，或者需要收集某些产品数据，往往需要进行日志上报。日志上报往往又非常费流量，有没有一些好的节省流量的优化方法呢，这是本文将要讨论的问题。

 

APP可不可以不进行日志上报，而单纯从服务器日志统计用户的行为和产品数据？

答：不行，有些用户行为是不会与服务器进行交互的（例如TAB的点击），从服务器日志无法完成所有统计。

APP通常有一些什么方法来上报日志？

答：常用方法有三种：

1）利用类似于Google Analytics的第三方工具进行上报，优点是无需开发，缺点是不能做个性化统计

2）自己制订私有协议进行上报（例如TCP二进制协议），优点是节省流量，缺点是开发成本高

3）使用HTTP上报，例如通过GET参数传递需要上报的数据，这种方案使用最为广泛

APP上报日志协议细节是怎么样的？

答：一般是在web-server下放置一个空文件，APP通过发起HTTP请求访问这个空文件，通过GET参数传递数据，通过分析access日志来得到想要的数据。GET协议一般又有两种方式，约定格式法 + KV法。

1）约定格式法：约定分隔符，约定占位符，约定每个字段的含义，例如：

APP和server约定好，空白文件是up，分隔符是[]，第一个字段[bj]是城市，第二个字段[20151021]是日期，第三个字段[1939]是时间，第四个字段[1]是用户id，第五个字段[login]是行为

这个方法的缺点是，扩展性较差，有时候某些字段没有值，也必须在相应的位置保留占位符（因为每个字段是什么含义都是事先约定好的），要想新增统计项，只能在GET后面新增[]

2）KV法：通过自解释的kv方式来上报数据，上面的例子用KV法来上报，则上报形式为：

这个方法的优点是扩展性好（好太多了），缺点是上报数据量比较大，KEY其实是冗余的字符。

笔者强烈建议使用第二种方法来上报数据，后文会简述一些流量的优化方法

APP上报日志，流量很大，主要矛盾是什么？即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

答：笔者了解到的主要矛盾有：

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中），定

非实时上报，数据时效性怎么保证？在什么时机进行日志上报呢？

答：数据的时效性会有一定的影响，但问题不大。为了优化，会在这样的一些时间点进行上报：

1）特殊时间点：APP打开时，APP关闭时等

2）按时间上报：例如每隔10分钟上报一次

3）按数据量上报：例如每收集10条记录才上报一次

一般来说上述三种优化方法会结合进行。