背景
新版本发布到线上后,随着用户的陆续升级,由于代码bug、接口报错、用户网络问题、脏数据等原因,会陆续收到一些问题反馈。我们开发拿到的信息,可能是复现步骤的描述、错误时的截图等,如何快速定位问题,是我们每一个开发需要思考的。阿里数据iOS端的线上错误定位方案,大致经历了如下三个步骤:
纯人工排查
这是最苦逼的阶段。拿到干瘪的问题描述后,我们的第一招是去复现这个问题,首先从表里跑一遍sql取到用户的操作系统、APP版本信息,然后模拟用户的操作系统、APP版本、网络状态(设置-开发者-Network Link Conditioner)、操作路径、权限状态等去试图复现,如果复现成功就大功告成可以开始修复,如果不行就再试几次...
APP上线前一般已经经过比较完整的测试,很容易复现的bug不多见,很可能我们难以复现用户反馈的这个错误。此时第二招是开始分析代码,根据错误结果对着代码开始倒推错误前经历了什么,试图找出不合适的处理逻辑、不够健壮的代码或不按预期返回数据的接口,此法效率低耗时不可控,甚至可能无法推断出最终原因。
如果能拿到出错的设备且在用户手机上容易复现,那就有兜底方案了,我们阿里数据因为是内部APP,大部分情况都能拿到用户设备,去借用户手机连Xcode再Open Console的事我们干过不少,日志无法定位的我们就只能无奈地Debug了...
用Tlog获取线上用户日志
准备阶段
我们知道,发生错误时经常伴随着请求异常,捕捉请求的错误信息是很关键的。受够了第一阶段的苦逼过程,我们对APP做了全面的梳理,将所有的网络请求分成了三类:
- 请求失败界面将无内容的请求:如果失败界面上会展示一个全屏的错误提醒视图,展示错误原因和提供一个重试的按钮,这个错误原因一般是后台返回的。如请求报表数据。效果如下:
- 用户交互触发的请求:如果失败则将错误原因Toast提示出来。如用户关注报表。
- 辅助信息获取类的请求:如果失败则打印日志。如获取报表的关注状态。
前面两种类型的请求,网络请求管理类内部会将错误提示出来,一是告知用户当前发生的问题,二来也辅助我们开发定位原因。同时,为了方便从日志里找到问题,我们对所有请求的发起、成功都做了简要的日志打印,对请求的失败则做了详细的日志打印,包括请求API、参数、NSError对象、服务端返回内容。
在Tlog后台拉取日志
为了提升定位效率和减少对用户的打扰,我们接入了集团的远程日志调试工具Tlog,将必要的日志换成用Tlog来打印。有了Tlog后,如果碰到用户有问题,第一招就是去Tlog后台捞一把日志,有了丰富的日志后基本都能定位到问题原因。
但Tlog也有不完美的地方,如用户必须登录成功有utdid,若用户还未成功登陆则无法拉取日志。且用户必须有可用的Accs长连接通道,如用户出错后退出了APP,则必须等用户下次再打开APP才能拿到日志。
客户端主动上传日志
如何解决用户登录失败无utdid或用户退出APP的问题?因为用户退出了APP我们曾钉钉过用户再打开下APP...但这明显对用户是不友好的,需要改进下。
我于是咨询了负责Tlog接入的同学,询问是否有客户端主动上报的功能,没想到真有了!我们第一批准备了这5个重要场景,立马做了接入:
/// Tlog日志主动上报的类型
typedef enum : NSUInteger {
TlogUploadTypeCrash = 0, /// 崩溃
TlogUploadTypeLoginFailure, /// 登录失败
TlogUploadTypeAlilangLogout, /// 阿里郎登出
TlogUploadTypeFeedback, /// 意见反馈
TlogUploadTypeScreenshot, /// 用户截屏
} TlogUploadType;
非常好,再也不怕干巴巴的意见反馈和截图了。有了客户端主动上传日志功能后,Tlog的威力更大了,只剩下最后一个未攻克场景:用户不在WIFI环境下...(非WIFI环境不上传日志)
/**
* 在某些场景或异常流程下,业务方主动调用,能够直接上传TLog日志,默认上传当天的日志,如果当时客户端的网站环境是非wifi,
* 会把上传指令存成离线任务。等待切换到wifi再上传。
*
* appendParamDict 上传成功后附带的业务参数,由调用方自定义传入:
*
* @param appendParamDict @{@"反馈标题":,@"反馈内容":,@"分类名称":,@"昵称":,@"utdid":}
*/
+ (void)uploadTLogAction:(NSDictionary*)appendParamDict;
腾讯的bugly也有记录日志并上传到后台的功能,不过可惜只能在崩溃时随堆栈一起上传,如果能加入后台主动拉取和客户端主动触发上传的功能就好了~
从截图里提取完整日志
如何攻克这最后一个场景呢....
那需要用户反馈的信息里就自带完整日志,从用户的复现步骤描述里自然是不可能了,那从错误截图里有戏吗?答案是真的有戏!最近在内网看到某个同学的分享:《基于图像分割的errorCode辨识方法(图像识别技术应用测试一)》,方案是在展示错误信息时把给开发看的错误日志也"显示"出来,但是只比背景色深1个rgb值,肉眼几乎不可见,但是以文字颜色为阈值对图片做二值化处理后就能很清楚了。发现这思路好赞啊,正好可以应用上!赶紧试试看:
- 改造网络请求管理类,在向页面抛出错误时,将希望在截图里看到的日志塞到NSError对象的userInfo里:
// 构造新的错误对象,把调试用错误信息也塞到userInfo里去
- (NSError *)getNewErrorWithError:(NSError *)error param:(DTConnectionParam *)param responseDict:(NSDictionary *)responseDict {
NSMutableDictionary *newUserInfo = [NSMutableDictionary dictionary];
if (error.userInfo && error.userInfo.count) {
[newUserInfo addEntriesFromDictionary:error.userInfo];
}
NSMutableString *debugTopMessage = [NSMutableString stringWithString:@"方法名:"];
[debugTopMessage appendString:param.method];
[debugTopMessage appendString:@" 错误:"];
[debugTopMessage appendString:error.description];
newUserInfo[@"debugTopMessage"] = debugTopMessage;
NSMutableString *debugBottomMessage = [NSMutableString stringWithString:@"参数:"];
[debugBottomMessage appendString:[param.params mj_JSONString]];
[debugBottomMessage appendString:[NSString stringWithFormat:@" 返回:%@", [responseDict mj_JSONString]]];
newUserInfo[@"debugBottomMessage"] = debugBottomMessage;
NSError *newError = [NSError errorWithDomain:error.domain code:error.code userInfo:newUserInfo];
return newError;
}
- 改造全屏展示的错误提示视图,在上下两个区域新增两个UILabel展示给开发看的完整日志,文字颜色(235)比背景色(236)深1个rgb值:
- (void)setError:(NSError *)error {
_error = error;
// 展示给用户看的错误原因
self.messageLabel.text = error.localizedDescription;
// 调试用基础信息:工号、版本、时间等
NSMutableString *debugBaseMessage = [NSMutableString string];
[debugBaseMessage appendString:[NSString stringWithFormat:@" 工号:%@", [DTLogin loginInstance].alilangWorkId]];
[debugBaseMessage appendString:[NSString stringWithFormat:@" 版本:%@", APP_VERSION]];
NSString *dateTime = [CommonTools getTimeStrBytimeStamp:[[NSDate date] timeIntervalSince1970] dateFormat:@"YYYY-MM-dd HH:mm:ss SSS"];
[debugBaseMessage appendString:[NSString stringWithFormat:@" 时间:%@", dateTime]];
// 显示调试用信息
self.debugTopMessageLabel.text = [error.userInfo valueForKey:@"debugTopMessage"];
NSMutableString *debugBottomMessage = [NSMutableString stringWithString:[error.userInfo valueForKey:@"debugBottomMessage"]];
[debugBottomMessage appendString:debugBaseMessage];
self.debugBottomMessageLabel.text = debugBottomMessage;
}
- 在Debug包里用OpenCV实现图片二值化处理的功能和页面,通过以文本颜色235为阈值对截图做二值化处理,将调试用完整日志显示出来:
- (UIImage *)getBinarizationImage:(UIImage *)soucreImage {
cv::Mat matImage = [self cvMatFromUIImage:soucreImage];
cv::Mat matGrey;
cv::cvtColor(matImage, matGrey, CV_BGR2GRAY);
int threshold = [[self.textFiled.text stringByReplacingOccurrencesOfString:@"阈值:" withString:@""] intValue];
cv::Mat matBinary;
cv::threshold(matGrey, matBinary, threshold, 255, cv::THRESH_BINARY);
UIImage *image = [self UIImageFromCVMat:matBinary];
return image;
}
最终效果图为:
图片二值化效果图.png通过这个工具页面,把用户反馈的出错截图一处理,请求名字、参数、返回、NSError对象、用户工号(截图可能经过转发)、版本、出错时间等信息应有尽有,定位错误又快又准!
结尾
我最喜欢从截图里提取完整日志的方案,如果是遇到接口异常,即使人不在电脑旁也能轻松定位错误转交给相应接口同学。此外,感觉也可以把完整错误日志写在截图的exif信息里,完整日志随着错误截图而来的感觉,非常爽。
我把图片二值化处理的页面做成了一个Demo,方便大家体验尝试,欢迎大家分享你们的错误定位方案~
网友评论