前些天帮公司做了网络层的重构,当时就想做好了就分享给大家,后来接着做了新版本的需求,现在才有时间整理一下。
之前的网络层使用的是直接拖拽导入项目的方式导入了AF,然后还修改了大量的源码,时隔2年,AF已经更新换代很多次了,导致整个重构迁移非常的麻烦。不过看着前辈写的代码,肯定也是一个高人,许多思路和我的一样,但是实现方式又不同,给我很好的参考。
在做网络层架构的时候也参考了Casa大神的架构思想,但是还是有所不同。
本文没有太多的理论,没有太多的专业术语,一来是方便大家阅读,二来我的基础也没那么好,没有太多华丽的词汇,对于架构来说主要是思路,有思路在,具体的实现就没有问题了
本文主要介绍以下几点:
1.网络接口规范
2.多服务器多环境设置
3.网络层数据传递(请求和返回)
4.业务层对接方式
5.网络请求怎么自动取消
6.网络层错误处理
无Demo无文章 Demo下载
网络接口规范
demo里面的请求示例是在网上找的,不符合我说的这套规范,仅作示例用。
规范很重要,有合理的规范就可以精简很多代码逻辑,特别是接口的兼容,是最底层最基础的设计,把接口规范放在前面来说。
在做这次重构时,我提出了一些规范点,可以给大家参考
1.两层三部分数据结构
接口返回数据第一次为字典,分为两层三部分:code、msg、data
1 2 3 4 5 6 7 |
"code": 0, "msg": "", "data": { "upload_log": true, "has_update": false, "admin_id": "529ecfd64" } |
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 !defined YA_BUILD_FOR_DEVELOP |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
//手动环境切换设置 #ifdef YA_BUILD_FOR_RELEASE //优先宏定义正式环境 self.environmentType = EnvironmentTypeRelease; #else //手动切换环境后会把设置保存 NSNumber *type = [[NSUserDefaults standardUserDefaults] objectForKey:@"environmentType"]; if (type) { //优先读取手动切换设置 self.environmentType = (EnvironmentType)[type integerValue]; } else { #ifdef YA_BUILD_FOR_DEVELOP self.environmentType = EnvironmentTypeDevelop; #elif defined YA_BUILD_FOR_TEST self.environmentType = EnvironmentTypeTest; #elif defined YA_BUILD_FOR_PRERELEASE self.environmentType = EnvironmentTypePreRelease; #elif defined YA_BUILD_FOR_HOTFIX self.environmentType = EnvironmentTypeHotFix; #endif } #endif |
所以当宏定义正式环境
存在的时候是不能手动切换环境的,用于普通用户的发布版本,但是其他宏定义环境
时是可以切换到正式环境的。
半个坑
另外手动切换自定义的环境是在基类中实现的,而其他的环境配置是在协议中实现的,这就和其他环境地址的配置不统一了。
可以这样理解,这里的基类是为了提供已返回值,协议是为了返回值的灵活,既然自定义环境的地址配置不需要灵活性,自然是放在基类好。思路是大方向,实现是灵活的,如果非要放在协议中实现也无不可以,无非是赋值粘贴几次一样的代码,但是一模一样的代码是我最不喜欢看到的,所以就放在基类了。如果有更好的解决方案欢迎提供
2.扩展性
model提供的是高扩展性,针对不同的不服务器添加更多的配置,比如加密方法,比如数据解析方法…前面提到了,统一的规范有的时候不是一时半会就能做好的,兼容就成了需求,这个时候不同服务器的个性化设置就可以在协议中声明并实现了,基类提供返回值就好
网络层数据传递(请求和返回)
Client、BaseEngine/DataEngine、RequestDataModel数据传递
网络请求的发生在我理解中分两步,一步是数据的整理,一步是生成Request并发起请求,基于这个思想我拆分出了Client和Engine,然后又把URLRequestGenerator从Client中拆分出来,Engine拆分出了下层的BaseEngine和面向不同业务的DataEngine,
而从BaseEngine到Client,再到URLRequestGenerator是要做数据传递的,请求参数和返回参数,所以又有了RequestDataModel
RequestDataModel
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
@interface YAAPIBaseRequestDataModel : NSObject /** * 网络请求参数 */ @property (nonatomic, strong) NSString *apiMethodPath; //网络请求地址 @property (nonatomic, assign) YAServiceType serviceType; //服务器标识 @property (nonatomic, strong) NSDictionary *parameters; //请求参数 @property (nonatomic, assign) YAAPIManagerRequestType requestType; //网络请求方式 @property (nonatomic, copy) CompletionDataBlock responseBlock; //请求着陆回调 // upload // upload file @property (nonatomic, strong) NSString *dataFilePath; @property (nonatomic, strong) NSString *dataName; @property (nonatomic, strong) NSString *fileName; @property (nonatomic, -e ">NSString *fileName; @property (nonatomic, 式导入了AF,然后还修改了大量的源码,时隔2年,AF已经更新换代很多次了,导致整个重构迁移非常的麻烦。不过看着前辈写的代码,肯定也是一个高人,许多思路和我的一样,但是实现方式又不同,给我很好的参考。
在做网络层架构的时候也参考了Casa大神的架构思想,但是还是有所不同。 本文没有太多的理论,没有太多的专业术语,一来是方便大家阅读,二来我的基础也没那么好,没有太多华丽的词汇,对于架构来说主要是思路,有思路在,具体的实现就没有问题了 本文主要介绍以下几点: 无Demo无文章 Demo下载 网络接口规范demo里面的请求示例是在网上找的,不符合我说的这套规范,仅作示例用。 规范很重要,有合理的规范就可以精简很多代码逻辑,特别是接口的兼容,是最底层最基础的设计,把接口规范放在前面来说。 在做这次重构时,我提出了一些规范点,可以给大家参考 1.两层三部分数据结构 接口返回数据第一次为字典,分为两层三部分:code、msg、data
code:错误码,可以记录下来快速定位接口错误原因,可以定义一套错误码,比如200正常,1重新登录… 接口帮我们定义了code和msg,是不是我们就不需要做错误处理了?当然不是,服务端的错误逻辑毕竟是简单的,具体到data里面的数据处理可能还有错误,所以错误的处理是必不可少的,下面会单独对错误处理做介绍 2.网络请求参数上传方式统一 这里一般都能做到,也有额外的,比如我们的一个服务器接口做的比较早,当时POST接口使用的就不规范,普通的应用信息channelID、device_id使用的是拼接在字符串后面的方式,而真正的请求参数则需要转成json放在一个字段里面传递,就是接口GET、POST并存的方式,造成网络层需要做特殊处理 所以说标准的GET、POST请求方式是很有必要的 3.关于Null类型 大家都知道Null类型在iOS里面是很特殊的,我的建议是放在客户端来做,原因有很多: 多服务器多环境设置这部分基本上是照搬casa大神的设计,这里我延伸了一个多环境的设计,小的项目一般都是一个服务器,但是像淘宝之类的项目一个服务器显然是不可能的,多个服务器的设计还是非常普遍的。根据一个枚举变量通过ServerFactory单例生成获取对应的服务器配置 1.服务器环境 标准的APP是有4个环境的,开发、测试、预发、正式,特别是服务器的代码,不能说所有的代码更改都在正式环境下,应该从开发->测试->预发->正式做代码的更新,开发就是新需求和优化的时候的更改,测试就是提交给测试人员后的更改,这个时候更改是在一个新的分支上,完成后要和合并到测试分支上并合并到开发分支上,预发这时候的变动就比较小了,一般会在测试人员完成后发布给全公司的人来测试,有问题了才会更改,更改后同样合并到开发分支,正式则是线上发布版本的紧急BUG修复,修改完后同样合并到开发分支上。所以开发分支是一直都是最新的。在此基础上可能会有其他的环境,比如hotfix环境,自定义的h5/后台本地调试的环境。 在我的demo中提供了两套设置,一套是第一次安装应用的初始化环境(宏定义),另外是手动切换环境的设置(枚举EnvironmentType)。这里有一个比较绕的逻辑,宏定义的正式环境设置高于手动切换环境设置,手动切换环境设置高于宏定义其他环境
所以当
2.扩展性 model提供的是高扩展性,针对不同的不服务器添加更多的配置,比如加密方法,比如数据解析方法…前面提到了,统一的规范有的时候不是一时半会就能做好的,兼容就成了需求,这个时候不同服务器的个性化设置就可以在协议中声明并实现了,基类提供返回值就好 网络层数据传递(请求和返回)Client、BaseEngine/DataEngine、RequestDataModel数据传递网络请求的发生在我理解中分两步,一步是数据的整理,一步是生成Request并发起请求,基于这个思想我拆分出了Client和Engine,然后又把URLRequestGenerator从Client中拆分出来,Engine拆分出了下层的BaseEngine和面向不同业务的DataEngine, RequestDataModel
|