iOS网络层架构设计分享.docx

iOS网络层架构设计分享前言前些天帮公司做了网络层的重构，当时就想做好了就分享给大家，后来接着做了新版本的需求，现在才有时间整理一下。之前的网络层使用的是直接拖拽导入项目的方式导入了AF，然后还修改了大量的源码，时隔2年，AF已经更新换代很多次了，导致整个重构迁移非常的麻烦。不过看着前辈写的代码，肯定也是一个高人，许多思路和我的一样，但是实现方式又不同，给我很好的参考。在做网络层架构的时候也参考了Casa大神的架构思想，但是还是有所不同。本文没有太多的理论，没有太多的专业术语，一来是方便大家阅读，二来我的基础也没那么好，没有太多华丽的词汇，对于架构来说主要是思路，有思路在，具体的实现就没有问题了。本文主要介绍以下几点：1.网络接口规范2.多服务器多环境设置3.网络层数据传递（请求和返回）4.业务层对接方式5.网络请求怎么自动取消6.网络层错误处理无Demo无文章，Demo下载：/SummertimSadness/NetWorkingDemo网络接口规范demo里面的请求示例是在网上找的，不符合我说的这套规范，仅作示例用规范很重要，有合理的规范就可以精简很多代码逻辑，特别是接口的兼容，是最底层最基础的设计，把接口规范放在前面来说在做这次重构时，我提出了一些规范点，可以给大家参考1.两层三部分数据结构接口返回数据第一次为字典，分为两层三部分：code、msg、data1. code:0,2. msg:,3. data:4. upload_log:true,5. has_update:false,6. admin_id:529ecfd647. code：错误码，可以记录下来快速定位接口错误原因，可以定义一套错误码，比如200正常，1重新登录. msg：接口文案提示，包括错误提示，用来直接显示给用户，所以这一套错误提示就不能是什么一串英文错误了 data：需要返回的数据，可以是字典，可以是数组接口帮我们定义了code和msg，是不是我们就不需要做错误处理了？当然不是，服务端的错误逻辑毕竟是简单的，具体到data里面的数据处理可能还有错误，所以错误的处理是必不可少的，下面会单独对错误处理做介绍2.网络请求参数上传方式统一这里一般都能做到，也有额外的，比如我们的一个服务器接口做的比较早，当时POST接口使用的就不规范，普通的应用信息channelID、device_id使用的是拼接在字符串后面的方式，而真正的请求参数则需要转成json放在一个字段里面传递，就是接口GET、POST并存的方式，造成网络层需要做特殊处理所以说标准的GET、POST请求方式是很有必要的3.关于Null类型大家都知道Null类型在iOS里面是很特殊的，我的建议是放在客户端来做，原因有很多：1）接口的规范定义并不是每个公司都是从一开始就能定义好的，老接口如果要把Null字段去掉的改动非常大2）客户端用过一个接口过滤也可以解决，一劳永逸，不用再担心因为某天接口的问题出现崩溃，而且通过一些Model的第三方库也可以很好的解决这个问题。这里不得说下swift的类型检测真是太方便了，之前一个项目用swift写的，代码规范一点，根本不会出现因为参数类型问题引起崩溃多服务器多环境设置这部分基本上是照搬casa大神的设计，这里我延伸了一个多环境的设计，小的项目一般都是一个服务器，但是像淘宝之类的项目一个服务器显然是不可能的，多个服务器的设计还是非常普遍的。根据一个枚举变量通过ServerFactory单例生成获取对应的服务器配置1.服务器环境标准的APP是有4个环境的，开发、测试、预发、正式，特别是服务器的代码，不能说所有的代码更改都在正式环境下，应该从开发-测试-预发-正式做代码的更新，开发就是新需求和优化的时候的更改，测试就是提交给测试人员后的更改，这个时候更改是在一个新的分支上，完成后要和合并到测试分支上并合并到开发分支上，预发这时候的变动就比较小了，一般会在测试人员完成后发布给全公司的人来测试，有问题了才会更改，更改后同样合并到开发分支，正式则是线上发布版本的紧急BUG修复，修改完后同样合并到开发分支上。所以开发分支是一直都是最新的。在此基础上可能会有其他的环境，比如hotfix环境，自定义的h5/后台本地调试的环境。客户端同样存在这些环境，并且要提供切换的入口。在我的demo中提供了两套设置，一套是第一次安装应用的初始化环境（宏定义），另外是手动切换环境的设置(枚举EnvironmentType)。这里有一个比较绕的逻辑，宏定义的正式环境设置高于手动切换环境设置，手动切换环境设置高于宏定义其他环境1. /宏定义环境设置2. #if!definedYA_BUILD_FOR_DEVELOP&!definedYA_BUILD_FOR_TEST&!definedYA_BUILD_FOR_RELEASE&!definedYA_BUILD_FOR_PRERELEASE3. #defineYA_BUILD_FOR_DEVELOP4. /#defineYA_BUILD_FOR_TEST5. /#defineYA_BUILD_FOR_PRERELEASE6. /#defineYA_BUILD_FOR_HOTFIX7. /#defineYA_BUILD_FOR_RELEASE/该环境的优先级最高8. #endif9. /手动环境切换设置10. #ifdefYA_BUILD_FOR_RELEASE11. /优先宏定义正式环境12. self.environmentType=EnvironmentTypeRelease;13. #else14. /手动切换环境后会把设置保存15. NSNumber*type=NSUserDefaultsstandardUserDefaultsobjectForKey:environmentType;16. if(type)17. /优先读取手动切换设置18. self.environmentType=(EnvironmentType)typeintegerValue;19. else20. #ifdefYA_BUILD_FOR_DEVELOP21. self.environmentType=EnvironmentTypeDevelop;22. #elifdefinedYA_BUILD_FOR_TEST23. self.environmentType=EnvironmentTypeTest;24. #elifdefinedYA_BUILD_FOR_PRERELEASE25. self.environmentType=EnvironmentTypePreRelease;26. #elifdefinedYA_BUILD_FOR_HOTFIX27. self.environmentType=EnvironmentTypeHotFix;28. #endif29. 30. #endif所以当宏定义正式环境存在的时候是不能手动切换环境的，用于普通用户的发布版本，但是其他宏定义环境时是可以切换到正式环境的。半个坑另外手动切换自定义的环境是在基类中实现的，而其他的环境配置是在协议中实现的，这就和其他环境地址的配置不统一了。可以这样理解，这里的基类是为了提供已返回值，协议是为了返回值的灵活，既然自定义环境的地址配置不需要灵活性，自然是放在基类好。思路是大方向，实现是灵活的，如果非要放在协议中实现也无不可以，无非是赋值粘贴几次一样的代码，但是一模一样的代码是我最不喜欢看到的，所以就放在基类了。如果有更好的解决方案欢迎提供2.扩展性model提供的是高扩展性，针对不同的不服务器添加更多的配置，比如加密方法，比如数据解析方法.前面提到了，统一的规范有的时候不是一时半会就能做好的，兼容就成了需求，这个时候不同服务器的个性化设置就可以在协议中声明并实现了，基类提供返回值就好网络层数据传递（请求和返回）网络层数据传递Client、BaseEngine/DataEngine、RequestDataModel数据传递网络请求的发生在我理解中分两步，一步是数据的整理，一步是生成Request并发起请求，基于这个思想我拆分出了Client和Engine，然后又把URLRequestGenerator从Client中拆分出来，Engine拆分出了下层的BaseEngine和面向不同业务的DataEngine，而从BaseEngine到Client，再到URLRequestGenerator是要做数据传递的，请求参数和返回参数，所以又有了RequestDataModelRequestDataModel1. interfaceYAAPIBaseRequestDataModel:NSObject2. /*3. *网络请求参数4. */5. property(nonatomic,strong)NSString*apiMethodPath;/网络请求地址6. property(nonatomic,assign)YAServiceTypeserviceType;/服务器标识7. property(nonatomic,strong)NSDictionary*parameters;/请求参数8. property(nonatomic,assign)YAAPIManagerRequestTyperequestType;/网络请求方式9. property(nonatomic,copy)CompletionDataBlockresponseBlock;/请求着陆回调10. /upload11. /uploadfile12. property(nonatomic,strong)NSString*dataFilePath;13. property(nonatomic,strong)NSString*dataName;14. property(nonatomic,strong)NSString*fileName;15. property(nonatomic,strong)NSString*mimeType;16. /download17. /downloadfile18. /progressBlock19. property(nonatomic,copy)ProgressBlockuploadProgressBlock;20. property(nonatomic,copy)ProgressBlockdownloadProgressBlock;21. end可以看出来RequestDataModel属性都是网络请求发起和返回的必要参数，这样做的好处真的是太大了，不知道大家有没有这样的场景：因为请求参数的不同做了好多方法接口暴露出去，最后调起的还是同一个方法，而且一旦方法写的多了，最后连应该调用哪个方法都不知道了。我就遇到过，所以现在我的网络请求调起是这样的：1. /没有回调，没有其他的参数，只有一个dataModel，节省了你所有的方法2. YAAPIClientsharedInstancecallRequestWithRequestModel:dataModel;生成NSURLRequest是这样的：1. NSURLRequest*request=YAAPIURLRequestGeneratorsharedInstancegenerateWithYAAPIRequestWithRequestDataModel:requestModel;可以看到我的demo里面的YAAPIClient类和YAAPIURLRequestGenerator类方法至少，方法少就意味着逻辑简单明了，方便阅读，两个类的代码行数都是120行，120行实现了网络请求的发起和着陆，你能想象吗另外RequestDataModel带来的另外一个好处就是高扩展性，你有没有遇到网络层需要添加删除一个参数导致调用方法修改了，然后很多地方都要修改方法？用RequestDataModel只需要添加删除参数就行了，只需要改方法体，这个改方法体和同时改方法名方法体是完全两个工作量。哈哈，有点卖虎皮膏药的感觉。这个的确是我的得意创新点ClientClient做两个操作，一个是生成NSURLRequest，一个是生成NSURLSessionDataTask并发起，另外还要暴露取消操作给Engine，URLRequestGenerator是生成NSURLRequest，URLRequestGenerator会对dataModel进行加工解析，生成对应服务器的NSURLRequest然后Client通过NSURLRequest生成NSURLSessionDataTaskClient和URLRequestGenerator都是单例1. -(void)callRequestWithRequestModel:(YAAPIBaseRequestDataModel*)requestModel2. NSURLRequest*request=YAAPIURLRequestGeneratorsharedInstance3. generateWithRequestDataModel:requestModel;4. AFURLSessionManager*sessionManager=self.sessionManager;5. NSURLSessionDataTask*task=sessionManager6. dataTaskWithRequest:request7. uploadProgress:requestModel.uploadProgressBlock8. downloadProgress:requestModel.downloadProgressBlock9. completionHandler:(NSURLResponse*_Nonnullresponse,10. id_NullableresponseObject,11. NSError*_Nullableerror)12. 13. /请求着陆14. ;15. taskresume;16. 取消接口参考了casa大神的设计，使用NSNumber *requestID来做task的绑定，就不多做介绍了BaseEngine/DataEngineEngine或者说是APIManager在我的设计中既不是离散的也不是集约的casa大神的理论集约型API调用其实就是所有API的调用只有一个类，然后这个类接收API名字，API参数，以及回调着陆点（可以是target-action，或者block，或者delegate等各种模式的着陆点）作为参数。然后执行类似startRequest这样的方法，它就会去根据这些参数起飞去调用API了，然后获得API数据之后再根据指定的着陆点去着陆。比如这样：1. APIRequeststartRequestWithApiName:itemList.v1params:paramssuccess:selector(success:)fail:selector(fail:)target:self;离散型API调用是这样的，一个API对应于一个APIManager，然后这个APIManager只需要提供参数就能起飞，API名字、着陆方式都已经集成入APIManager中。比如这样：1. property(nonatomic,strong)ItemListAPIManager*itemListAPIManager;2. /getter3. -(ItemListAPIManager*)itemListAPIManager4. 5. if(_itemListAPIManager=nil)6. _itemListAPIManager=ItemListAPIManagerallocinit;7. _itemListAPIManager.delegate=self;8. 9. return_itemListAPIManager;10. 11. /使用的时候就这么写：12. self.itemListAPIManagerloadDataWithParams:params;各自的优点就不说了，但是由此延伸出几个问题：1.参数的传递使用字典对于网络层来说是不可知的，而且业务层需要去关注接口字段的变化，其实是没有必要的2.离散型API会造成Manager大爆炸3.集约型会造成取消操作不方便4.取消操作并不是每个接口必须的，如果写成部分离散的部分集约的，代码的整体结构.我是个有强迫症的人，看不得这样的代码所以我的设计主要就解决了上面的这些问题1.面向业务层的DataEngine只传递必要的参数进来，不使用字典,比如1. interfaceSearchDataEngine:NSObject2. +(YABaseDataEngine*)control:(NSObject*)control3. searchKey:(NSString*)searchKey4. complete:(CompletionDataBlock)responseBlock;5. endcontrol暂时先不管，是做自动取消的，后面再介绍。searchKey就是搜索的关键字在调用的时候就是这样1. self.searchDataEngine=SearchDataEnginecontrol:selfsearchKey:关键字complete:(iddata,NSError*error)2. if(error)3. NSLog(%,error.localizedDescription);4. else5. NSLog(%,data);6. 7. ;2.我按业务层来划分DataEngine，比如BBSDataEngine、ShopDataEngine、UserInforDataEngine.每个DataEngine里面包含各自业务的所有网络请求接口，这样就不会出现DataEngine大爆炸，像我们的项目有300多个接口，拆分后有十几个DataEngine，如果使用离散型API设计，那画面太美我不敢看?3.BaseEngine提供取消操作每个接口生成一个BaseEngine实例，持有Client返回的requestID，所以就可以做取消操作，简单的使用场景1. #importViewController.h2. #importSearchDataEngine.h3. interfaceViewController()4. property(nonatomic,strong)YABaseDataEngine*searchDataEngine;5. end6. implementationViewController7. -(void)viewDidLoad8. superviewDidLoad;9. /Doanyadditionalsetupafterloadingtheview,typicallyfromanib.10. self.searchDataEnginecancelRequest;11. self.searchDataEngine=SearchDataEnginecontrol:selfsearchKey:关键字complete:(iddata,NSError*error)12. if(error)13. NSLog(%,error.localizedDescription);14. else15. NSLog(%,data);16. 17. ;18. 19. end4.返回的YABaseDataEngine实例ViewController不是必须持有的，当有需要取消操作的时候再去持有就行了这样的设计就集成了集约型和离散型的有点，又解决了集约型和离散型的缺点网络请求怎么自动取消当一个页面的请求正在天上飞的时候，用户等了好久不耐烦了，小手点了个back，然后ViewController被pop被回收。此时请求的着陆点就没了。这是很危险的情况，着陆点要是没了，就很容易crash的。casa大神说在BaseDataEngine的dealloc里面做取消网络请求操作，我也是这样想的，但是casa大神说要把BaseDataEngine绑定给ViewController，当ViewController销毁时BaseDataEngine也就跟着销毁了，这样我也是同意的，但是要让我不管什么情况都要给ViewController添加BaseDataEngine变量来保存BaseDataEngine这是我万万不能接受的，而且有的ViewController会发起两三种网络请求，难道要我添加两三个变量？代码入侵太大，所以这里偷偷使用了一个巧，使用了runtime，给ViewController添加一个字典，来保存requestID和BaseDataEngine，这样对于ViewController来说就不是必须要写变量来持有BaseDataEngine了，所以就出现了上面的DataEngine里面要把control传递进来的样子在发起请求的时候进行绑定1. workingAutoCancelRequestssetEngine:selfrequestID:self.requestID;在请求完成的时候进行删除1. weakCworkingAutoCancelRequestsremoveEngineWithRequestID:engine.requestID;公司上个大神的做法虽然使用control的做法很方便，但是如果说要把现在已有的接口都添加一个control字段的工作量也是很大的，如果已有的接口是使用字典传递给DataEngine的，这里给大家一个公司上个大神的做法，使用内存地址，将内存地址添加到字典中去，用内存地址做key绑定，也是可以的。如果是像我这样直接把关键参数传递过来的，不是用的字典，就不行了。1. NSString*memoryAddress=NSStringstringWithFormat:%p,self;网络层错误处理说实话，错误处理该放在按个地方我也是纠结了好久，也和公司同事讨论了好久，最终定下来了一套方案，仅供大家参考。我们将错误处理分为两个步骤，一个是错误解析，一个是错误的UI展示大家可以看到我设计的接口返回数据是标准的id data, NSError *error,所以我的想法是Client就把error处理好，不管你是网络超时错误也好，或者是数据格式不正确也好，都error解析完整，把code错误码定义好，上层根据需要通过code来做具体的UI展示，因为有的界面的错误需要用户的点击确认，有的页面的错误只是一闪而过的提示框，把error交给BaseEngine或者DataEngine来处理errorUI，所以我定义了一套errorUI的枚举，当BaseEngine拿到error的时候就去做错误的展示总结架构的设计更多的是思路，我希望的是大家能通过我们提供的思路取其精华去其糟粕，总会设计会最适合你的项目的架构的另外我的这套设计存在的争议的点可能会有很多，有一部分我已经在文中提到了，如果大家有什么其他的想法我们再讨论1.关于block对于block和delegate的选择，我更倾向于block，只有一个原因，因为block的结构更方便阅读，