背景
新版本发布到线上后，随着用户的陆续升级，由于代码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;
}
最终效果图为：
通过这个工具页面，把用户反馈的出错截图一处理，请求名字、参数、返回、NSError对象、用户工号（截图可能经过转发）、版本、出错时间等信息应有尽有，定位错误又快又准！
结尾
我最喜欢从截图里提取完整日志的方案，如果是遇到接口异常，即使人不在电脑旁也能轻松定位错误转交给相应接口同学。此外，感觉也可以把完整错误日志写在截图的exif信息里，完整日志随着错误截图而来的感觉，非常爽。
我把图片二值化处理的页面做成了一个Demo，方便大家体验尝试，欢迎大家分享你们的错误定位方案~
