近日，被波哥催稿，营业时间被迫提前，就翻了数十年来翻深不见的代码仓库，找到了多年前在移动端做长链接开发中的一种实践方法，可以让长链接的业务代码和短链接一样高效、简洁的小技巧，就拿来应付交个差。
此文并不会针对 TCP 做详尽的展开说明，也不会针对如何使用 Socket 库进行说明、协议格式定义、如何传输等都不在本文范围之内，本文关注的是移动端如何进行高效并简洁地编写基于 TCP 的业务代码，让长链接的业务代码和短链接的业务代码写起来一样高效。
先过一下基础知识：
记住重点：
正因为这种区别，TCP 在带来链路复用、主动推送、高效、快速等很多优势的同时也引入较多的复杂性，其中的问题之一就是基于 TCP 写业务代码比较繁琐。
本文会以 iOS 开发为例，对问题进行说明，其它语言同学们可以自行同理实现。
短链接例子
在 App 上进行一个短链接的操作十分常见，通过 block 的形式进行网络请求，比如广泛使用的 AFNetworking 库中是这样使用的：
NSString *url = @"http://api.xxx.com/method";
[[self shareAFNManager] GET:url parameters:nil progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) { NSLog(@"responseObject-->%@",responseObject); UpdateUI() } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) { NSLog(@"error-->%@",error);}];
复制代码
此处的 block 是 Objective-C 语言中的一种叫法，理解为函数指针即可，因为这种写法可以在对应的 block 中直接进行业务处理，比如：更新 UI 等，这种操作就给写业务带来了十分方便的作用，本质上也是因为短链接的形式满足 R:Q = N:N = 1 的关系
长链接
那么在长链接中要实现上面的功能就十分麻烦，除了 Socket 基本功能以外，响应数据更新 UI 就得处理网络线程切换 UI 线程，UI 生命周期和数据生命周期匹配，数据通知等诸多问题。
在 handle 或者 dispatch 方法的实现中，很多同学会陷入一个陷阱，要不就是实现的特别麻烦，要不然就是实现的漏洞百出，在不频繁的情况下可能会选择 notification 或者类似的简陋方案顶一下，即便这种写起来也会存在很多坑：通知的注册、管理、销毁等都是要小心应付的内容，这也是很多同学写不好长链接业务代码的问题所在。
方案
既然有了问题，本着「凡是痛苦的就是需求之所在」，按照短链接的思路进行简单地梳理：
提炼 request & respones，约定关系为：R:Q = N:N = 1
核心问题就这一条，只要能抽象出这个关系，那么长链接就可以像短链接一样方便，包括很多同学以为TCP 的缓存模块较难实现的问题也会变得非常之简单。
在 TCP 的协议定制中，约定 message{} & message_reply{} 对应处理一个网络请求，比如在 protobuf 中定义一个 ping 包
message ping{ string request_id = 1;}
message ping_reply{ string request_id = 1;}
复制代码
协议设计时按照这种约定就实现了 R:Q = N:N = 1 的问题
request_id
其中的 request_id 是一个较为「骚」的操作，引一个字段完美解决大问题。
过程中牢记短链接的特点，有来有回，有来必有回（不许抬杠，没有网络也会有超时或者网络未链接等错误返回）。
request_id 由 client 产生和维护，在发送请求中发给服务器，服务器将此值原封不动返回给 client，client 就可以根据此 request_id 找到对应的网络请求原始位置。
比如起一个名字叫 SendCore 来实现网络层，包含的主要结构如下：
typedef void (^SocketDidReadBlock)(NSError *__nullable error, id __nullable data);
@interface SendCore : NSObject+ (nullable SendCore *)sharedManager;
- (void) sendEnterChatRoom:(nullable EnterChatRoom *) data completion:(__nullable SocketDidReadBlock)callback;
- (void) CloseSocket;@end
复制代码
SocketDidReadBlock 约定函数指针的形式，必须满足简单、可扩展的要求。
以进入聊天室的函数为例:
- (void) sendEnterChatRoom:(nullable EnterChatRoom *) data completion:(__nullable SocketDidReadBlock)callback{ if (data == nil ) { return; } NSString * blockRequestID =[self createRequestID]; data.requestId = blockRequestID; if (callback) { [self addRequestIDToMap:blockRequestID block:callback]; } [self sendProtocolWithCmd:CmdType_Enter1V1MovieRoom withCmdData:[data data] completion:callback];}
复制代码
由 client 生成一个 request_id，并将 callback 存入 block_table 中，在服务器返回数据中解出 request_id，然后在 block_table 中找到对应的函数指针并执行。
-(void) handerProtocol:(CmdType) protocolID packet:(NSData *) packet{ NSError *error = nil; id reslutData = nil; NSString *requestId = nil; switch (protocolID) { case CmdType_Enter1V1MovieRoomReply: error = nil; syncObjInfo =[SyncObjInfo parseFromData:packet error:&error]; reslutData = syncObjInfo; requestId = syncObjInfo.requestId; didReadBlock = [self getBlockWith:requestId]; break; }
if (didReadBlock) { didReadBlock(error, reslutData); }
if (requestId != nil && requestId.length > 0) { [self removeRequestIDFormMap:requestId]; } }
复制代码
执行后记得清理相关内容和并发锁等信息。
到此，主要功能已经完成，效果如下：
[[SendCore sharedManager] sendEnterChatRoom:room completion:^(NSError * _Nullable error, id _Nullable data) { NSLog(@"%@", error);
if (error == nil) { NSLog(@"进入聊天室成功"); }}];
复制代码
这样长链接的业务代码就和短链接的业务代码一样的简洁方便。
超时
还有一些意外的情况需要处理，上面的例子只是在网络正常的情况下可以工作，比如超时，TCP 并不会有消息回来，所以在 SendCore 中还要在做多一些事情。
所以我们走入上面 addRequestIDToMap 函数：
- (void) addRequestIDToMap:(NSString *) requestID block:(nullable SocketDidReadBlock)callback withTime:(BOOL) timeout{
if (requestID == nil || requestID.length == 0) { return; } if (callback == nil) { return; } [self.requestsMapLock lock]; [self.requestsMap setObject:callback forKey:requestID]; if (timeout) { [self.requestsTimeMap setObject:[NSDate date] forKey:requestID]; } [self.requestsMapLock unlock];}
复制代码
其中有一个 requestsTimeMap，记录了 request_id 请求的发起时间，有了这个时间，就可以在本地做好超时错误的处理
-(void) checkRequestProcessTimeout{ NSError * Socket_WAIT_PROCESS_TIMEOUT_SECOND = [NSError errorWithDomain:@"_Socket_WAIT_PROCESS_TIMEOUT_SECOND_" code:408 userInfo:nil]; NSMutableArray * timeoutRequestIDs = [NSMutableArray array]; NSDate * now = [NSDate date];
for (NSString * requestID in [self.requestsTimeMap allKeys]) { if (requestID == nil || [requestID length] <= 0) { continue; } NSDate * fireDate = [self.requestsTimeMap objectForKey:requestID]; NSDate * timeOutTime = [NSDate dateWithTimeInterval:_Socket_WAIT_PROCESS_TIMEOUT_SECOND_ sinceDate:fireDate]; if ([timeOutTime compare:now] == NSOrderedAscending) { [timeoutRequestIDs addObject:requestID]; } }
for (NSString * requestID in timeoutRequestIDs) { if (requestID == nil || [requestID length] <= 0) { continue; } SocketDidReadBlock didReadBlock = [self getBlockWith:requestID]; didReadBlock(Socket_WAIT_PROCESS_TIMEOUT_SECOND, nil); [self removeRequestIDFormMap:requestID]; }}
复制代码
通过定时器，每秒执行 checkRequestProcessTimeout 函数，发现超时的请求就直接调整其 block，并返回 Socket_WAIT_PROCESS_TIMEOUT_SECOND 错误。
通过双 table 的形式就很好地解决了这个问题。
缓存
同理缓存也就比较容易实现了，参考 AFNetworking 库就可以实现一套好用的缓存功能。
request_id 的小妙用
request_id 由客户端产生并维护，一般这样产生就可以：
- (NSString *)createRequestID {
NSInteger timeInterval = [NSDate date].timeIntervalSince1970 * 1000000; NSString *randomRequestID = [NSString stringWithFormat:@"%ld%d", timeInterval, arc4random() % 100000];
return randomRequestID;}
复制代码
某种场景中存在一些固定的网络请求，或者为了配合缓存库，可以定义一些固定的或者特定格式的 id。
const USER_INFO_GET_REQUEST_ID = @“04e1c446-b918-40f7-9061-d06b569a9cf0”@“/大功能/小功能/xxx”
复制代码
request_id 的巧妙定义，会带来意想不到的效果，同学们可以自由发挥。
结束
到此，所有的功能就结束了，从业务代码上完全看不出这段代码是长链接还是短链接，很好地达到了预期的目的，在长链接的业务中业务代码效率和短链接一样简洁高效。
更多精彩请关注我们的公众号「百瓶技术」，有不定期福利呦！
评论