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

桂林seo半杯酒博客

一、背景

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的日志上报能力,为传统测试模式打开了一个新的方向与未来。