iOS 开发实践：如何构建一个网络层？

最新推荐文章于 2023-10-17 19:59:15 发布

历史上的今天

最新推荐文章于 2023-10-17 19:59:15 发布

阅读量731

点赞数

文章标签： iOS开发网络层

本文链接：https://blog.csdn.net/byeweiyang/article/details/80128061

版权

原文：How do I build a Network Layer
作者：Tomasz Szulc（@tomkowz），资深 iOS 软件工程师
译者：孙薇，欢迎技术投稿、约稿、给文章纠错，请发送邮件至 mobilehub@csdn.net。
版权声明：本文为作者授权 CSDN 翻译，未经允许，请勿转载。

【导语】本文作者 Tomasz Szulc 曾同时带领着两个项目的研发工作，由此为他提供了一次很好的对于应用架构进行深度尝试的机会，本文即是他根据实践经验所总结的网络层构建方法，大家或许有兴趣一读。

如今的移动应用大多是“客户端-服务器”模式，某个应用中很可能就包含或大或小的网络层结构。迄今为止笔者见过的许多实现均有一些缺陷，最新构建的这个或许仍有缺陷，但在手边的这两个项目中效果都很不错，而且测试覆盖率几乎达到100%。本文只讨论与单个后台通讯、发送 JSON 编码请求的网络层，这个网络层会与 AWS 通讯，发送一些文件，整体结构并不复杂，不过相应功能的扩展也应当十分简单。

思维流程

在构建相应网络层之前，我先提出一些问题：

将包含有后台 URL 相关内容的代码放在哪里？
将包含端点相关的代码放在哪里？
将包含如何构建请求信息的代码放在哪里？
将与为请求准备参数的相关代码放在哪里？
应当将身份验证 token 存在哪里？
如何执行请求？
何时、在何处执行请求？
是否关注取消请求的问题？
是否需要关注错误的后台响应或者一些后台 Bug？
是否需要使用第三方的框架？应当使用什么框架？
是否存在相关的Core Data？
如何测试解决方案？

存储后端 URL

首先，我们要了解后端 URL 应当放在哪里？系统的其它部分怎么知道向哪里发送请求？这里我们更偏好创建存储这类信息的 BackendConfiguration 类。

import Foundation
public final class BackendConfiguration {
    let baseURL: NSURL
    public init(baseURL: NSURL) {
        self.baseURL = baseURL
    }
    public static var shared: BackendConfiguration!
}

这种类易于测试，也易于配置，设定共享静态变量之后，我们就能从网络层的任意位置对其进行访问，不需将这个变量发送到其它位置。

let backendURL = NSURL(string: "https://szulctomasz.com")!
BackendConfiguration.shared = BackendConfiguration(baseURL: backendURL)

端点

在找到解决方案前，笔者在这个问题上做了颇有一阵子的实验，在配置 NSURLSession 时曾尝试对端点执行硬编码的方式，并尝试了一些了解端点、便于实例化与注入的虚拟资源类对象，但并未找到需要的方案。然后得出了设想：创建知道要接入哪个端点，使用什么方法，该是 GET、POST、PUT 还是其它什么的 *Request 对象，它要了解如何配置请求主体，以及要 pass 什么头文件。

于是我得出了这样的代码：

protocol BackendAPIRequest {
    var endpoint: String { get }
    var method: NetworkService.Method { get }
    var parameters: [String: AnyObject]? { get }
    var headers: [String: String]? { get }
}

实现这个协议的类能够提供构建请求所需的基本信息，NetworkService.Method 只是个带有 GET、POST、PUT、DELETE案例的enum函数。

映射一个端点的请求示例如下：

final class SignUpRequest: BackendAPIRequest {

    private let firstName: String
    private let lastName: String
    private let email: String
    private let password: String

    init(firstName: String, lastName: String, email: String, password: String) {
        self.firstName = firstName
        self.lastName = lastName
        self.email = email
        self.password = password
    }

    var endpoint: String {
        return "/users"
    }

    var method: NetworkService.Method {
        return .POST
    }

    var parameters: [String: AnyObject]? {
        return [
            "first_name": firstName,
            "last_name": lastName,
            "email": email,
            "password": password
        ]
    }

    var headers: [String: String]? {
        return ["Content-Type": "application/json"]
    }
}

为了避免给每个 header 创建 dictionary，我们可以为 BackendAPIRequest 定义扩展。

extension BackendAPIRequest {

    func defaultJSONHeaders() -> [String: String] {
        return ["Content-Type": "application/json"]
    }
}

*Request 类利用所需参数成功创建了请求。我们要始终确保至少所需的参数都能 pass，否则就无法创建请求对象。定义端点非常简单，如果要将对象的id包括在端点中，添加起来也是超级简单的，因为这些id在属性中有存储。

private let id: String

init(id: String, ...) {
  self.id = id
}

var endpoint: String {
  return "/users/\(id)"
}

请求的方法从未变过，参数的body和header的构成与维护都很简单，整个代码测试起来也很容易。

执行请求

与后台通讯是否需要第三方框架？

有人在 Swift 中使用 AFNetworking(Objective-C) 和 Alamofire，这种方式很常见，不过由于 NSURLSession 也可以很好地完成工作，有时候不需要任何的第三方框架，否则只会让应用框架更为复杂。

目前的解决方案包含两个类—— NetworkService和 BackendService：

NetworkService：允许执行 HTTP 请求，包含 NSURLSession。每项网络服务每次都只能执行一个请求，请求可以取消，成功和失败都有回馈。
BackendService：负责接收与后台相关的请求，包含 NetworkService。在目前使用的版本中，系统尝试利用 NSJSONSerializer 将响应数据序列化为 JSON。

class NetworkService {

    private var task: NSURLSessionDataTask?
    private var successCodes: Range<Int> = 200..<299
    private var failureCodes: Range<Int> = 400..<499

    enum Method: String {
        case GET, POST, PUT, DELETE
    }

    func request(url url: NSURL, method: Method,
                 params: [String: AnyObject]? = nil,
                 headers: [String: String]? = nil,
                 success: (NSData? -> Void)? = nil,
                 failure: ((data: NSData?, error: NSError?, responseCode: Int) -> Void)? = nil) {

        let mutableRequest = NSMutableURLRequest(URL: url, cachePolicy: .ReloadIgnoringLocalAndRemoteCacheData,
                                                 timeoutInterval: 10.0)
        mutableRequest.allHTTPHeaderFields = headers
        mutableRequest.HTTPMethod = method.rawValue
        if let params = params {
            mutableRequest.HTTPBody = try! NSJSONSerialization.dataWithJSONObject(params, options: [])
        }

        let session = NSURLSession.sharedSession()
        task = session.dataTaskWithRequest(mutableRequest, completionHandler: { data, response, error in
            // Decide whether the response is success or failure and call
            // proper callback.
        })

        task?.resume()
    }

    func cancel() {
        task?.cancel()
    }
}

class BackendService {

    private let conf: BackendConfiguration
    private let service: NetworkService!

    init(_ conf: BackendConfiguration) {
        self.conf = conf
        self.service = NetworkService()
    }

    func request(request: BackendAPIRequest,
                 success: (AnyObject? -> Void)? = nil,
                 failure: (NSError -> Void)? = nil) {

        let url = conf.baseURL.URLByAppendingPathComponent(request.endpoint)

        var headers = request.headers
        // Set authentication token if available.
        headers?["X-Api-Auth-Token"] = BackendAuth.shared.token

        service.request(url: url, method: request.method, params: request.parameters, headers: headers, success: { data in
            var json: AnyObject? = nil
            if let data = data {
                json = try? NSJSONSerialization.JSONObjectWithData(data, options: [])
            }
            success?(json)

            }, failure: { data, error, statusCode in
                // Do stuff you need, and call failure block.
        })
    }

    func cancel() {
        service.cancel()
    }
}

大家都知道，BackendService 是可以在头文件中设置验证 token 的，BackendAuth 对象只是简单的存储，将 token 存在 NSUserDefaults 中，如果必要的话，可以将 token 存在 Keychain 中。

BackendService 将 BackendAPIRequest 作为请求的一个参数，从请求对象处提取必要的信息。由于封装的很好，后台服务只管使用就行了。

public final class BackendAuth {

    private let key = "BackendAuthToken"
    private let defaults: NSUserDefaults

    public static var shared: BackendAuth!

    public init(defaults: NSUserDefaults) {
        self.defaults = defaults
    }

    public func setToken(token: String) {
        defaults.setValue(token, forKey: key)
    }

    public var token: String? {
        return defaults.valueForKey(key) as? String
    }

    public func deleteToken() {
        defaults.removeObjectForKey(key)
    }
}

NetworkService、BackendService 和 BackendAuth 测试维护起来都很容易。

队列请求

这里涵盖的问题包括：我们想用什么方式来执行网络请求？如果想要一次执行多个请求，要怎样操作？一般来说，要以什么方式获得请求成功或失败的通知？

我们决定采用 NSOperationQueue 以及 NSOperations 来执行网络请求，因此在将 NSOperation 归入子类之后，将其异步属性覆盖，以返回 true。

public class NetworkOperation: NSOperation {

    private var _ready: Bool
    public override var ready: Bool {
        get { return _ready }
        set { update({ self._ready = newValue }, key: "isReady") }
    }

    private var _executing: Bool
    public override var executing: Bool {
        get { return _executing }
        set { update({ self._executing = newValue }, key: "isExecuting") }
    }

    private var _finished: Bool
    public override var finished: Bool {
        get { return _finished }
        set { update({ self._finished = newValue }, key: "isFinished") }
    }

    private var _cancelled: Bool
    public override var cancelled: Bool {
        get { return _cancelled }
        set { update({ self._cancelled = newValue }, key: "isCancelled") }
    }

    private func update(change: Void -> Void, key: String) {
        willChangeValueForKey(key)
        change()
        didChangeValueForKey(key)
    }

    override init() {
        _ready = true
        _executing = false
        _finished = false
        _cancelled = false
        super.init()
        name = "Network Operation"
    }

    public override var asynchronous: Bool {
        return true
    }

    public override func start() {
        if self.executing == false {
            self.ready = false
            self.executing = true
            self.finished = false
            self.cancelled = false
        }
    }

    /// Used only by subclasses. Externally you should use `cancel`.
    func finish() {
        self.executing = false
        self.finished = true
    }

    public override func cancel() {
        self.executing = false
        self.cancelled = true
    }
}

之后，由于希望通过 BackendService执行网络调用，笔者将 NetworkOperation 归入子类，并创建了 ServiceOperation。

public class ServiceOperation: NetworkOperation {

    let service: BackendService

    public override init() {
        self.service = BackendService(BackendConfiguration.shared)
        super.init()
    }

    public override func cancel() {
        service.cancel()
        super.cancel()
    }
}

由于类中内部生成 BackendService，就无需在每个子类中分别创建了。

下面列出了登录操作的示例代码：

public class SignInOperation: ServiceOperation {

    private let request: SignInRequest

    public var success: (SignInItem -> Void)?
    public var failure: (NSError -> Void)?

    public init(email: String, password: String) {
        request = SignInRequest(email: email, password: password)
        super.init()
    }

    public override func start() {
        super.start()
        service.request(request, success: handleSuccess, failure: handleFailure)
    }

    private func handleSuccess(response: AnyObject?) {
        do {
            let item = try SignInResponseMapper.process(response)
            self.success?(item)
            self.finish()
        } catch {
            handleFailure(NSError.cannotParseResponse())
        }
    }

    private func handleFailure(error: NSError) {
        self.failure?(error)
        self.finish()
    }
}

在 start 方法中，服务会执行操作的构造函数内部生成的请求，将 handleSuccess 与 handleFailure 方法作为服务的 request(_:success:failure:) 方法，发送回调函数。这样代码更干净，并且仍保有可读性。

系统会将操作单独发送给 NetworkQueue 对象，并分别插入队列。我们令其尽可能简单化：

public class NetworkQueue {
    public static var shared: NetworkQueue!
    let queue = NSOperationQueue()
    public init() {}
    public func addOperation(op: NSOperation) {
        queue.addOperation(op)
    }
}

在同一个地方执行操作的优点是什么？

所有的网络操作取消起来都很简单；
在提供应用的基础体验时，如果网络较差，可以取消包括下载图片或其他请求数据的联网操作。比如，当用户的网络较差时，我们会希望避免下载图片；
可以构建优先队列，优先执行某些请求，以便快速响应。

解决 Core Data 的问题

这是这个版本不得不延迟发布的原因：在之前版本的网络层中，操作返回 Core Data 对象，回应收到后会被解析转化为 Core Data 对象，这个解决方案非常不理想。

操作必须知道Core Data是什么，由于针对不同的框架，使用的模型也不同，网络层都在不同的框架中，因此网络框架也必须知道模型的框架。
每个操作必须采取额外的 NSManagedObjectContext 参数，才能知道应当执行哪部分内容。
每次在收到回应并成功调用前，都必须先找出对象，或者找到要获取对象的磁盘。这是一个很大的缺陷——我们并不是每次都想创建Core Data对象。

因此，新的设想是完全从网络层中获取Core Data。首先我们创建了对象创建的中间层，以便解析响应。

解析与创建对象的速度很快，不需要涉及请求磁盘的操作；
无需将 NSManagedObjectContext 发送给操作；
在成功后，再使用解析项和创建操作时存储的Core Data对象引用来更新Core Data对象——这就是大多数情况下，将操作添加到队列之后的情况。

映射操作

响应映射的概念在于将解析逻辑与将JSON映射到有用项目这两点分开。我们能够区别这两类解析器：第一种只返回特定类型的单个对象，第二种是解析这类项目数组的解析器。

首先定义所有项目的公共协议：

public protocol ParsedItem {}

现在有一些对象是映射的结果：

public struct SignInItem: ParsedItem {

    public let token: String
    public let uniqueId: String
}

public struct UserItem: ParsedItem {

    public let uniqueId: String
    public let firstName: String
    public let lastName: String
    public let email: String
    public let phoneNumber: String?
}

我们定义一下解析出错时会抛出的错误类型。

internal enum ResponseMapperError: ErrorType {
    case Invalid
    case MissingAttribute
}

Invalid：当 JSON 为 nil 或不为 nil 时，或者当是一组对象而不是单个对象的 JSON 时抛出。
MissingAttribute——顾名思义，就是 JSON 中有漏 key，或者解析后的值为或应为 nil 时。

ResponseMapper 可能会像下面这样：

class ResponseMapper<A: ParsedItem> {

    static func process(obj: AnyObject?, parse: (json: [String: AnyObject]) -> A?) throws -> A {
        guard let json = obj as? [String: AnyObject] else { throw ResponseMapperError.Invalid }
        if let item = parse(json: json) {
            return item
        } else {
            L.log("Mapper failure (\(self)). Missing attribute.")
            throw ResponseMapperError.MissingAttribute
        }
    }
}

后台返回一个 obj ——在本例中是一个 JSON，以及消费这个 obj 的解析方式，并返回一个符合 ParsedItem 的对象。

现在，有了这个通用型的 mapper 之后，我们就能创建具体的 mapper 了。我们先来看一下回应登录操作解析的 mapper。

protocol ResponseMapperProtocol {
    associatedtype Item
    static func process(obj: AnyObject?) throws -> Item
}

final class SignInResponseMapper: ResponseMapper<SignInItem>, ResponseMapperProtocol {

    static func process(obj: AnyObject?) throws -> SignInItem {
        return try process(obj, parse: { json in
            let token = json["token"] as? String
            let uniqueId = json["unique_id"] as? String
            if let token = token, let uniqueId = uniqueId {
                return SignInItem(token: token, uniqueId: uniqueId)
            }
            return nil
        })
    }
}

ResponseMapperProtocol 是由具体 mapper 所实现的协议，因此解析回应的方法一致。

在成功的操作模块中，我们也会使用这样的 mapper，可使用特定类型的具体对象来代替 dictionary。这样的对象容易使用，也容易测试。

最后是解析数组的响应 mapper。

final class ArrayResponseMapper<A: ParsedItem> {

    static func process(obj: AnyObject?, mapper: (AnyObject? throws -> A)) throws -> [A] {
        guard let json = obj as? [[String: AnyObject]] else { throw ResponseMapperError.Invalid }

        var items = [A]()
        for jsonNode in json {
            let item = try mapper(jsonNode)
            items.append(item)
        }
        return items
    }
}

这串代码负责接收 mapping 函数，如果一切解析正常的话，就会返回数组。如果有单独的内容无法解析，或者更甚之返回空数组的话，可以根据情况抛出错误。mapper 会希望这个对象（从后台获取回应）是一个 JSON 元素的数组。

下面的图表展示了网络层结构：