【穿山甲系列】老司机的千里眼——穿山甲SDK

作者:邓曦

团队:腾讯移动品质中心TMQ

一、背景

APP发布后,在用户侧出现的问题统称为“线上问题”。如果“线上问题”出现了:

解决率低

存在时间长

的情况,那么对APP的口碑会有很大的负面影响。经过我们对2016年上半年手机QQ浏览器用户反馈分析,我们发现“线上问题”解决的主要困难来自于“对解决问题的关键信息获取困难”,统计数据如下:

图表——日志获取率和时间

大家可以看到:日志的获取率平均只有10%,平均一份日志获取时间至少30小时。那么有没有办法能够改善这种窘境呢?

二、解决方案

1、SDK架构

既然方向明确了,我们就来制造这个轮子。通过我们多轮迭代后,我们得到了如下的穿山甲SDK系统架构:

图表——穿山甲SDK架构

从架构图上,可以看出整个SDK分为两条线:以“日志数据”作为输入的“数据线”和以“Push Cmd/代码Cmd”作为输入的“控制线”。

这也是常用的系统设计思路,数据和控制分离的最佳实践。

下面将分开介绍。

2、数据线

从2-2的穿山甲SDK架构图中,我们可以看到“数据线”分为如下几个主要模块:

1)数据API

2)缓存模块

3)安全模块

4)扩展服务

(1)数据API

数据API就是打印日志的接口,和普通android打印日志基本一致。例子如下:

Logs.d(TAG, “key1=value1;key2=value2;…”);

在这里我们用了自己Logs类而不是android默认的Log。日志的内容,也是通过key=value的形式进行连接。这是为了将来对日志的智能分析做的规范性要求。

(2)缓存模块

缓存模块主要对日志写入SD卡前,做缓存管理提高性能。分为两个部分:

1)L1缓存

在Android中所有Log.d打印的日志首先都会进入L1缓存进行排队。等L1缓存达到临界值,管理逻辑才会把L1缓存中所有内容发送到L2缓存。

2)L2缓存

L2缓存是比较纯粹的写入缓冲区,负责写入SD卡前最后缓存。

至于为什么会有L1和L2两级缓存结构,我们将在后续讲解详细描述。

(3)安全模块

出于安全的考虑,日志内容需要进行压缩加密存储。这个地方就有一个问题:到底是先压缩在加密,还是先加密在压缩? 其实这和我们采取加密算法也有关系。

大家都知道,普通Zip加密算法基于“滑动窗口”。简而言之,在“滑动窗口”中出现的重复词越多,压缩比就越大。经过我们实践发现,很多加密算法加密后,重复的词明显比加密前要少。并且,越短的词在加密后,字符串也越短。

1)DES加密

针对原始日志,进行DES对称加密。但是这样做有个问题,加密和解密都是同一个秘钥A。秘钥A会记录在客户端SDK代码中,虽然SDK代码经过混淆,但是也有被破解的风险。所以,我们加入了第二层的RSA加密。

2) RSA加密

大家都知道,RSA非对称加密存在性能问题。为了规避性能损耗,我们只是用RSA来对DES的秘钥A进行加密,而不是对整个日志内容加。我们将DES中的秘钥A改为一个随机字符串,用RSA的公钥加密后,写入日志文件第一行。当日志传到server后,读取日志第一行,用RSA的私钥解密后,得到DES的秘钥A。在用秘钥A对剩下的日志进行解密,就能得到日志原文。

(4)扩展服务

扩展服务包括如下组件:

1)CPU监控

采集CPU占用率,用来监控APP中某个CPU超过阈值的场景。

2)FPS监控

采集FPS占用率,用来监控APP中某个FPS超过阈值的场景。

3)MEM监控

采集MEM占用率,用来监控APP中某个MEM超过阈值的场景。

4)基础信息采集

基础信息包括:机型、固件等软硬件信息。

3、控制线

从2-2的穿山甲SDK架构图中,我们可以看到“控制线”分为如下几个主要模块:

1)Cmd API

2)Cmd模块

3)基础服务

4)SDK工具

(1)数据API

通过代码调用Logs.upload就能立即上报日志。如果是通过Push通道,则需要符合SDK的协议字符串即可。

(2)Cmd模块

所有对SDK的控制操作,都被包装为CMD进行。

1)协议解析

通过Push的API接口,是需要进行协议解析的。例如:命令字符串c=3&date=20170424,就会被解析为:当前命令是“上报日志”,日志范围“2017年4月24日”的日志。

2)配置管理

对SDK固有设置进行云端控制和更新。例如:是否打开错误码上报,是否上报用户反馈日志等。

3)调度器

对所有命令进行统Task框架调度管理。

(3)基础服务

1)文件分片

我们的分片策略,是按照文件级别区分的。最早我们没有按照日志级别区分,所有debug、info、warn、error都输出在同一个日志文件。这样造成一个后果,如果只是需要debug日志,不需要其他级别。那么在终端做日志二次提取,必然浪费CPU和内存。所以,直接按照日志级别分片为不同日志文件,将来可以直接只上报debug级别日志。

2)淘汰策略

日志根据容量进行循环淘汰,这里需要预估在用户侧每日产生日志总体大小。

(4)SDK工具

1)ZipUtil

提供压缩打包服务,除了日志文件,还能将其他文件附件也打包上传。

2)UploadUtil

提供Http上传能力。

3)Task回调

提供Task回调机制,能在任务成功、失败等场景下实现不同的处理逻辑。

4、方案流程

图表——穿山甲SDK解决问题思路

(1)分析埋点

问题发生前埋点:就是在没有发生问题之前,对代码中关键位置进行埋点。例如:异常捕获、DB信息、函数输入输出、Server信息、分之条件、File信息等。

问题发生或埋点:出现了用户反馈后,在补充针对问题现象、相关逻辑、排除逻辑等代码位置进行埋点。

(2)数据收集

数据收集,利用“众测”(公测和正式版不收集),收集用户数据。这里收集标准有:错误码触发和用户主反馈。错误码触发:当一些已知问题发生时,收集程序日志进行上报。用户主动反馈:用户点击反馈论坛进行提交时,收集程序日志进行上报。

(3)数据分析

在数据分析过程中,采用正则表达式提取,针对同一类型日志关键信息进行提取。然后通过离群数据分析,找到“小众”部分数据,进行人工分析。

(4)问题解决

通过日志分析出根本原因,开发进行问题修改解决。

(5)线上验证

通过反馈平台和日志上报,验证问题修复后,线上用户验证是否已经OK。

三、实践效果

1、外部反馈数据

(1)反馈日志获取时间缩短80%。

以往获取一份用户反馈日志,平均需要30小时。采用SDK后,平均日志获取时间缩短为6小时不到。

(2)浏览器7类问题,比预期提前一个版本解决。

小说语音暂停、小说翻页翻不了、小说下载失败等问题比预期提前一个版本解决。

(3)广告过滤类问题,每条处理时间缩短3天,缩短59%。

之前广告过滤,联系用户效率特别低。通过穿山甲SDK把广告URL直接上传,大大节省了联系用户找到URL的时间。

2、内部反馈处理

大家都知道,来自内部的产品反馈,特别是老板的反馈,很难处理。究其原因:

老板记不清复现路径

老板手机不能借给你

按照之前经验,项目组只能按照“抓瞎”方式进行问题解决。平均每个问题至少需要一周时间,还必须厚着脸皮去“骚扰”老板才行。

现在我们有个穿山甲SDK,只需要让老板直接用。出了问题,一键上报日志即可,开发拿到日志后30分钟就能解决问题。节约研发流程时间5天/问题,效益非常明显。

3、H5游戏问题

(1)背景

图表——H5游戏打不开背景

有用户反馈,部分H5游戏无法进入,严重影响他们的游戏体验。也严重影响了H5游戏口碑。

(2)定位和解决

图表 ——H5游戏打不开-定位问题

针对H5游戏打不开时,用户网络状态进行埋点。我们通过“众测”发现:

1)排除网络原因

94%用户在H5游戏打不开的时候外部网络是通畅的,初步排除网络原因造成。

2)排除机型原因

对打不开的机型进行归类,通过本地无法复现,初步排除机型问题。

最后我们把目标定位到CP服务质量,也就是H5游戏服务器质量上。最后发现,由于大部分CP为了节约成本,没有把H5资源放在CDN服务器上,导致拉取失败概率增加。通过和CP沟通后解决了这个问题。

四、总结

(1)需求阶段

在需求评审阶段,测试人员可以开发约定必要的事前埋点。为提前发现问题做好准备。

(2)编码阶段

这个阶段测试人员,可以和开发人员结对编程,添加主要事前埋点。为接下来解决集成测试中问题,奠定良好的基础。

(3)众测

产品发布“众测”后,测试人员可以针对线上出现问题,添加解决问题事后埋点。精准的解决特定问题。

根据我们经验,良好的事前埋点,不仅能够解决线上问题。对于研发流程中问题解决,也能起到巨大的作用。结合穿山甲SDK的日志上报能力,为传统测试模式打开了一个新的方向与未来。

关注微信公众号:腾讯移动品质中心TMQ,获取更多测试干货!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算

用于增强数据治理能力与法规遵从性的容器

审计人员是如何评估当前分散存储基础设施的企业数据的使用情况的?简而言之,这其中困难重重!

1848
来自专栏PHP在线

说说大型高并发高负载网站的系统架构

转自:Just Do IT (http://www.toplee.com) 我在Cernet做过拨号接入平台的搭建,而后在 Yahoo3721负载搜索引擎前端平...

3225
来自专栏云计算D1net

灵活服务的五大部署技术

如果是为下一代大型移动应用的前端UI组件工作,那么谈论加快速度和破坏东西看上去还不错。当进入服务器领域时,就没有人希望看到破坏了。业务在飞速发展,但是如果后台基...

30612
来自专栏Alice

iOS 推送原理

APNs:Apple Push Notification server 苹果推送通知服务 苹果的APNs允许设备和苹果的推送通知服务器保持连接,支持开发者推送...

773
来自专栏程序员的SOD蜜

功能实现了软件就做好了吗?

    常常在问自己这样一个问题,也听到很多人都说“先实现功能”,也许在某种意义上不得不如此,但我认为这不是真正意义上的软件开发,实现功能重要,软件的维护更重要...

20610
来自专栏架构师之路

db如何快速回滚+恢复,DBA的神技能

如果人为执行了“删库”操作,命令会同步给其他从库,导致所有库上的数据全被删除,无法恢复,故这种方案是不行的。

1115
来自专栏葡萄城控件技术团队

渐进式Web应用程序的深入概述

如果您是Web开发人员,您可能已经了解渐进式Web应用程序(PWA)或已经实现了自己的应用程序。 如果您不熟悉,本文将深入概述渐进式Web应用程序的实现原理,以...

522
来自专栏Golang语言社区

高并发解决方案——提升高并发量服务器性能解决思路

一个小型的网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单。随着...

36610
来自专栏智能计算时代

「云计算」什么是不可变的基础设施?

在传统的可变服务器基础架构中,服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器,手动升级或降级软件包,逐个服务器地调整配...

903
来自专栏腾讯Bugly的专栏

Luakit的前世今生

最近发布了一个跨平台的app开发框架Luakit。那怎么会想到做这样一个东西呢?

2194

扫码关注云+社区