收集日志并进行统计分析可以帮助改善产品甚至发现新的商机。但是移动APP的日志收集与Web应用不同。Web应用直接从服务器上拿访问日志就可以拿到很多东西，而APP不是一直连接网络的，所以日志的收集是需要另外设计一种可行的方案的。
基本的思路就是APP在需要收集日志的地方请求API，从而达到收集日志的目的。
由于APP平台并不唯一，主流的有IOS和Android，那么为了统一服务器端的API，为多个平台定义一个统一的数据格式甚至接口是个不错的主意。建议将发送日志的代码封装为SDK的形式。
- 网络环境 手机连接网络有多种方式，WIFI、2G、3G等等，各有特点，速度上有快慢，收费上有贵贱。需要在用户的流量费用和收集日志的需求之间找个平衡点：既不能让用户为了对他们没啥用的日志数据买单，也不能一直不发日志。需要在几种网络条件下做个配比，既确保日志能持续发送不至于长期积压，又不能消耗太多用户的流量。特别注意：不要只是在WIFI环境下才发，那样如果用户一直都不连WIFI的话那么日志就发不出来。这种情况看起来似乎有点极端，但不得不防。
- 数据压缩 为了减少网络IO的流量，对数据进行压缩传输是必要的。一个经济实惠的方式是：http的gzip压缩。这种方式实现简单，效果显著。
- 发送频率 如果每次产生日志都发送，那么服务器的压力似乎大了些。其实没必要这么高频率，可以考虑设定一个更慢的频率，比如半天发一次，毕竟对日志数据的实时性要求一般都没那么大。
- 完整性 虽然这只是日志，但是考虑到IT江湖险恶，为避免被人半路篡改，对数据做完整性校验不是件坏事。检查数据完整性的方案有很多，常见做法是__密钥 + Hash算法__，只要发送端和接收端保持一致，那么半路篡改的数据将无所遁形。
- 安全性 日志里面可能包含了很多重要的数据，为了保障用户隐私，安全性是必须考虑的。最基本的做法是：__HTTPS + 数据加密__这样从网络层和应用层都加了锁，大大提高了安全性。
日志的存储上限。在发送之前，日志是存储在用户手机本地的。那么最多该存储多少呢？无论是数据条数还是文件大小方面，都应该有个上限，并设定一个详细的策略来解决日志数据达到上限之后的问题。比如删除最久远的数据，比如数据压缩，比如归档等等。
移动设备的日志收集看起来很简单，当真的要做的时候发现其实问题还蛮多的，要想做的好着实要费些脑筋啊。