来新公司,给公司的SDK review了一下。发现了不少小问题,在此总结一下。
(我下面说明问题可能是很简单,但是搞清楚某些问题还是花了些时间的,大家引以为戒吧)
先谈谈处理的问题:
1.某天QA说有游戏在iphone5 上测试,启动闪退。
我通过日志捕捉到,是因为用了openssl库,这个库包含了libcrypto.a, 这个库 和 老款的 iphone 处理器 架构冲突,导致crash。
我检查了openssl引入是为了做 https 的验证(为了验证服务器证书,其实是画蛇添足)。但是这部分 验证是完全没有必要的,细节就不说了,移除依赖解决了问题。
ps:当初面试时候,面试官说公司用的https时双向验证,我后来发现是 单向验证。:)
2.内存泄露问题
我通过leaks 检测,我们SDK 的 泄露是无处不在。因为用的是AFN框架,原开发人员也对其进行了封装。他们认为的单例封装。我给下伪代码:
ServerHttpManager.m
+ (instancetype)manager
{
ServerHttpManager *instance = [super manager];
return instance;
}
我只想说 WTF!
AFN建议需要自己用单例封装一下,不然会有泄露。但是,这样跟没封装一样。改为:
+ (instancetype)manager
{
static ServerHttpManager *instance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
instance = [super manager];
});
return instance;
}
网络请求泄露问题就解决了。当然还有其它一些block的泄露,伪代码:
__block XXViewController * weakSelf = self;
大兄弟估计是MRC那边还没有过渡到 ARC,SDK是用的ARC啊,因为这个也导致好几处的bug。
把__block 改成 __weak 就解决了。还有等等。。。
3. iOS8.x系统bug
由于项目里某些特殊的需求会出现以下伪代码:
[[Utils getCurrentVC] presentViewController:XXViewController animated:NO completion:^ {
[XXViewController dismissViewControllerAnimated:NO completion:^ {
DDViewController *vc = [DDViewController sharedInstance];
[[Utils getCurrentVC] presentViewController:vc animated:YES completion:nil];
}];
}];
在iOS8.x设备里会闪退,意思说你 presentViewController未完成就开始了dismissViewControllerAnimated 。不要问为什么会有这种逻辑,有时候你会用到其中一层嵌套。
修改后伪代码:
[[Utils getCurrentVC] presentViewController:XXViewController animated:NO completion:^ {
dispatch_after(0, dispatch_get_main_queue(), ^{
[XXViewController dismissViewControllerAnimated:NO completion:^ {
dispatch_after(0, dispatch_get_main_queue(), ^{
DDViewController *vc = [DDViewController sharedInstance];
[[Utils getCurrentVC] presentViewController:vc animated:YES completion:nil];
});
}];
});
}];
4.读info.plist 不当导致的问题
伪代码:
bool isDevMode = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"IS_DEV_MODE"] ;
然后在info.plist 里 配置 YES or NO ,但是读出得 总是true。
这个问题也是细节问题,通过代码review 才发现。
bool isDevMode = [[[[NSBundle mainBundle] infoDictionary] objectForKey:@"IS_DEV_MODE"] boolValue];
因为这个问题虽小,但导致我们某个功能无法使用。
5.检测网络连接状况
伪代码:
NSURL *baseURL = [NSURL URLWithString:[self getAPPBaseURL]];
AFHTTPSessionManager *manager = [[AFHTTPSessionManager alloc] initWithBaseURL:baseURL];
[manager.reachabilityManager setReachabilityStatusChangeBlock:^(AFNetworkReachabilityStatus status) {
switch (status) {
case AFNetworkReachabilityStatusReachableViaWWAN:
........
}
}];
其实这个URL传入一点作用没有,这样使用还会导致内存泄露,改成:
AFNetworkReachabilityManager * reachabilityManager = [AFNetworkReachabilityManager sharedManager];
[reachabilityManager setReachabilityStatusChangeBlock:^(AFNetworkReachabilityStatus status) {
switch (status) {
case AFNetworkReachabilityStatusReachableViaWWAN:
........
}
}];
6.苹果内支付的问题
通过代码review发现有3个地方有问题
问题a:SKPaymentTransactionStateRestored 没有处理(只是做了finish)。
问题a和 问题b同时存在都会出现丢单的问题,假如支付成功,在finish之前app意外情况crash或是没有网络了。重新登陆SKPaymentTransactionStateRestored 里仅仅finish了,没有其它处理,所以这个订单丢了,用户支付了,我们服务器还是未支付状态。
问题b:支付成功后,finish订单 和 请求服务器验证 同时处理。
跟a类似,订单finish 应该在 得到服务器验证处理结果 后,不然在服务器请求这段时间出问题,依然是用户付款了,但是服务器订单状态是未支付。
问题c:考虑到会有其它越狱渠道的支付,在支付服务器验证回来客户端处理优先处理sdk反馈的结果。
应该依赖服务器处理的结果,不能优先以sdk以及其它的处理。
另外,内支付的 各种错误码也是千奇百怪。很多苹果都是没有公开的,我不止一次跟苹果技术沟通一些特殊错误码的详情,但是他们一直不肯说明那些错误码代表什么。只是说是他们内部用的。哎。。。。下一篇文章我讲讨论一下千奇百怪的内支付错误码,以及可能出现的状况。
7.封装的sdk,多次调用会触发多次问题
一般我们用第三方不论是分享还是推送,你 [xxSDK initWithKey:@"xxxxxxx"]; 调用多次也是没有问题的,但是我们的SDK封装有点小问题,你调用多次,将会触发多次回调或是相关动作,修复倒是很简单就不提了。