开发者社区> 云起君> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

为什么别人家的APP,上报日志就这么省流量?

简介: APP一般如何上报日志?使用类似于Google Analytics的第三方工具;自己制订私有协议进行上报;使用HTTP协议,通过GET参数传递需要上报的数据。
+关注继续查看

为了统计APP内用户行为,或者需要收集某些产品数据,APP往往需要进行日志上报,日志上报往往又非常费流量,大家的APP是怎么上报日志的呢?

画外音:用户流量的大头,是日志上报?


APP可不可以不上报日志,只从服务器日志统计用户的行为和产品数据?
不行,有些用户行为不会与服务器进行交互,例如“卡片切换”,服务器日志无法完成所有统计。


APP一般如何上报日志?
常用方法有这么几种。


(1)使用类似于Google Analytics第三方工具

优点:无需开发

缺点:不能做个性化统计


(2)自己制订私有协议进行上报;

优点:节省流量

缺点:开发成本高

画外音:例如,TCP二进制协议,可定制化,又省流量。


(3)使用HTTP协议,通过GET参数传递需要上报的数据。


如何通过HTTP协议进行上报?

可以在Web-Server下放置一个文件,APP发起HTTP请求访问这个文件,通过GET参数传递数据,并通过分析access日志来得到想要的数据。


如何通过GET参数传递数据?

一般又有两种方式:

(1)约定格式法;

(2)KV法。


什么是“约定格式法”?

约定格式法:约定分隔符,约定占位符,约定每个字段的含义,例如:

http://daojia.com/up?bj1939[login]


约定如下:

(1)被访问文件是up;

(2)分隔符是[];

(3)第一个字段[bj]代表城市,第二个字段代表日期,第三个字段代表时间,第四个字段代表用户id,第五个字段代表行为。


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


什么是“KV法”?

KV法:通过GET参数自解释的KV方式来上报数据。


上面的例子用KV法来上报,则上报形式为:

该方法的优点是:扩展性好

缺点是:上报数据量比较大,非常消耗流量


为什么会这么消耗流量呢?

之所以消耗流量,主要有这样一些原因:

(1)无效流量多,HTTP报文有很多无效数据;
(2)
URL冗余,每次都要上报URL;
(3)
KEY冗余,每次都要上报KEY;
(4)
上报频度高,用户每次操作都要日志上报的话,上报量很大。


有没有节省流量的方法呢?

针对上述1-4点,常见的优化方案有这样一些。


痛点1:HTTP请求内无效数据多。

解决方案:手动构造HTTP请求,尽可能多的去除HTTP中的无效数据。

画外音:

如果使用第三方库构造HTTP请求,可能会带上你并不需要的UA数据。

自己构造,则可以只保留GET /up HTTP/1.1和GET传递的必须数据;


痛点2:URL冗余。

解决方案:使用尽可能短的域名来接收上报的日志。

画外音:例如,s.daojia.cn/a


痛点3:KEY冗余。

解决方案:使用尽可能短的KEY来标识数据,日志收集方一定要统一规范好KEY。

画外音:例如,city=bj可以优化为c=bj

一个BAD CASE,由于没有规范,曾经某个部门上报用户ID,不同项目中重复埋点,上报了4次:

name=shenjian&user_id=123&uid=123&user_name=shenjian

而上述name、user_id、uid、user_name都属于重复上报。


痛点4:上报频率高。

解决方案:先将数据保存到APP本地存储,再定时上报,这类优化对于PV类,SUM类,AVG类统计尤为有效。


例如,要统计登录按钮的点击次数,三次点击,传统统计可能需要上报三次:优化后,增加了一个参数,只需要上报一次:


非实时上报,应该在什么时机进行日志上报呢?

如果进行合并上报,或者批量上报,数据的时效性会有一定的影响

画外音:如果策略合理,数据误差会非常小。


为了优化,会在这样的一些时间点进行上报:
(1)
特殊时间点上报:例如,APP打开,关闭,后台转入活跃时;
(2)
按时间批量上报:例如,每隔10分钟才上报一次;
(3)
按数据量批量上报:例如,每收集10条记录才上报一次;


还有其他什么优化方案?
批量上报,
数据压缩


希望,文章的逻辑是清晰的。

本文转自“架构师之路”公众号,58沈剑提供。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
无线APP日志上报优化实践
无线时代,APP流量敏感,为了统计APP内用户行为,或者需要收集某些产品数据,往往需要进行日志上报,日志上报往往又非常费流量,有没有一些好的节省流量的优化方法呢,这是本文将要讨论的问题。
289 0
《云原生时代下的App开发》电子版地址
2021年12月,阿里云携10+技术专家亮相年度顶级云原生开源技术峰会 ,并带来阿里云云原生专场,不仅汇聚行业发展方向的精彩主题演讲,在云基础设施、可观察性等云原生与开源技术等各大专题中,从阿里云真实业务场景中 走出来的云原生技术最佳实践也向全球开发者一一呈现。
0 0
交易所开发成品丨交易所系统开发(演示版)丨交易所APP源码设计
An exchange is an information platform for trading certain information and goods. A fixed place is called an exchange. The exchange, with the help of information platform, realizes the sharing of property rights information, long-distance trading, unified coordination, and balance of property right
0 0
数字藏品开发丨数字藏品APP系统开发(逻辑及方案)丨数字藏品源码功能及分析
 Digital collections are digital works,works of art and commodities that use blockchain technology to identify the ownership of rights and interests.Digital collections can mark their owners in the blockchain network and trace their subsequent circulation,including but not limited to digital picture
0 0
一对一直播app开发,直播间的搭建重点
一对一直播app开发,直播间的搭建重点
0 0
iOS开发:下架App的步骤
首先登陆你的 iTunes Connect
0 0
交易所APP开发功能丨交易所系统开发(成熟及案例)丨交易所系统源码平台
Web3.0的底层技术是分布式账本技术和分布式数据库技术,这就好比操作系统里的文档系统(Filing)和I/O(输出入系统),也像是区块链里的Layer-1数据处理结构。分布式存储就像是操作系统里的文档系统,分布式计算就像是操作系统里的CPU(中央处理器),分布式数据传输(分布式通信)也就好比I/O。CPU、文档系统和I/O都是操作系统的基本要素,类比到Web3.0的底层技术亦是如此。
0 0
要想相亲app开发得好,接口性能优化少不了
要想相亲app开发得好,接口性能优化少不了
0 0
2022 ios APP最新iOS开发上架测试教程
2022 ios APP最新iOS开发上架测试教程
0 0
[ios开发]-APP-上架流程
由于苹果的机制,在非越狱机器上安装必须通过官方的Appstore, 开发者开发好应用后上传Appstore,也需要通过审核等环节。 AppCan作为一个跨主流平台的一个开发平台,也对ipa包上传Appstore作了支持。 本文从三个流程来介绍如何实现AppCan在 线编译出ipa包,以及上传到苹果Appstore。
0 0
+关注
云起君
行到水穷处,坐看云起时!
文章
问答
来源圈子
更多
阿里云最有价值专家,简称 MVP(Most Valuable Professional),是专注于帮助他人充分了解和使用阿里云技术的意见领袖阿里云 MVP 奖项为我们提供了这样一个机会,向杰出的意见领袖表示感谢,更希望通过 MVP 将开发者的声音反映到我们的技术路线图上。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
移动App持续交付之路
立即下载
移动App研发加速—跨平台解决方案
立即下载
云原生时代下的App开发
立即下载