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

iOS网络层架构设计分享 前言 前些天帮公司做了网络层的重构，当时就想做好了就分享给大家，后来接着做了新版本的需求，现在才有时间整理一下。 之前的网络层使用的是直接拖拽导入项目的方式导入了AF，然后还修改了大量的源码，时隔2年，AF已经更新换代很多次了，导致整个重构迁移非常的麻烦。不过看着前辈写的代码，肯定也是一个高人，许多思路和我的一样，但是实现方式又不同，给我很好的参考。 在做网络层架构的时候也参考了Casa大神的架构思想，但是还是有所不同。 本文没有太多的理论，没有太多的专业术语，一来是方便大家阅读，二来我的基础也没那么好，没有太多华丽的词汇，对于架构来说主要是思路，有思路在，具体的实现就没有问题了。 本文主要介绍以下几点： 1.网络接口规范 2.多服务器多环境设置 3.网络层数据传递（请求和返回） 4.业务层对接方式 5.网络请求怎么自动取消 6.网络层错误处理 无Demo无文章，Demo下载：/SummertimSadness/NetWorkingDemo 网络接口规范 demo里面的请求示例是在网上找的，不符合我说的这套规范，仅作示例用 规范很重要，有合理的规范就可以精简很多代码逻辑，特别是接口的兼容，是最底层最基础的设计，把接口规范放在前面来说 在做这次重构时，我提出了一些规范点，可以给大家参考 1.两层三部分数据结构 接口返回数据第一次为字典，分为两层三部分：code、msg、data 1. code:?0,? 2. msg:?,? 3. data:?{? 4. ????upload_log:?true,? 5. ????has_update:?false,? 6. ????admin_id:?529ecfd64? 7. }? ? 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. //宏定义环境设