来新公司，给公司的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封装有点小问题，你调用多次，将会触发多次回调或是相关动作，修复倒是很简单就不提了。