再看2017

2017

走出学校的第一年就在忙碌的工作中度过了。看了很多大佬总结了自己的2017，作为职场萌新也该好好总结下，自己的2017了。

工作

从实习转变到正式工作，再从一家换到另一家。一年的转变似乎并没有给自己留下很深的烙印。一切在自己看来似乎是顺利成章。

步入工作，再没有老师家长会告诉你，什么你该做什么你要做。无限的自由也带来了无限的无助。好在自己在和不少很棒的小伙伴聊过后，也决定了自己的方向。

转换工作的初始目的，是为了能够有更多的锻炼，以及一点待遇上的提升。到目前为止，两者似乎又在怂恿我继续寻找下一个目标了。

在一个初级开发迈向中级开发的，2017给我最大的迷茫是，没有很好的目标以及一个好的导师。前一个项目在内部斗争和大老板举棋不定的变成了牺牲品，在一降再降的KPI中混过了一个2017.现在的项目虽然经历五年的风风雨雨，但是依然存在着许多我看来不应该存在的问题。一个新，一个老，似乎最后的归宿都是一样的。在项目中，太难太难能碰到有价值的问题，更多是如何完成上线如何压榨时间。而在两个团队，都没有碰到一个能够hold一切的大神。许多问题，都是自己在思考许久后闭门造车出来的方案，好还是不好也无从评价。

工作不应该只为了生活的苟且，更应该去追寻梦想。

有了一个小小的打算，2018，去迎接新的挑战。

技术

2017依然在iOS开发的道路上狂奔。学了一点swift，但是没有成熟的项目时间。继续深化了react开发，试图在现在的项目中能够应用。学了一点node开发，了解了后端应用开发的基本知识。

学习swift和react开发，让自己打开了自己的思想。在之前，一个OOP似乎就是一切，甚至对OOP的思想也不甚了解。编程思想的创新不在于是耍酷，而是让自己在面对不同的问题的时候，能够去寻找最优解。

iOS开发进入了第三个年头，研究的方向开始走整个项目架构的设计了。如今的项目运行了五年，但在开始的时候并没有一个良好的架构设计。在来来往往不知道多少开发经手过后，变成了一个前有坑后有墙的项目。iOS开发不比其他web服务或后端应用，出现大型的应用也就是最近两三年。多数开发并没有或半路出家或碌碌无为，并没有考虑架构设计在iOS应用的落地。而自己，也希望能够在现在的项目上，投入时间和精力，打造一个合适的架构。

读书

2017年，投入了不少时间读书和读文章。kindle是一个好东西，每天中午和通勤路上都能让自己看和学不少东西。

读书的内容很杂，有小说，有金融，有技术。而文章多偏向技术方面。

大学的时候，很喜欢刷知乎和微博，觉得里面似乎有无穷无尽新奇的东西。但是工作后，发现，知乎和微博，只能拿来消遣。提升自己，只能取看书和深度的文章。读书和读文，更重要的是思考。好与坏，对与错，作者的论点和观点如何，一切都是自己取决于自己的思考。

旅行

2017去了两个地方：三亚和澳门。

不同多数人，我更喜欢去泡酒店，以及逛逛这座城市。三亚和澳门刚好满足了我两个爱好。

三亚是一个纯粹的旅游城市，非常适合跑酒店。而三亚酒店带给我的体验也是非常好的。旅游不应该是在马不停蹄走马观花中路过一个又一个景点，而是应该让自己的身心从劳烦的茶米油盐中解放出来。泡酒店，能够让自己不再去思考工作中那些劳烦的事情，随意打发的时间，不失为人生的一大享受。

澳门，我认为是不同于三亚的。作为前殖民地已经东西文化混杂的一个城市，在城区中瞎逛又有一番独特的乐趣。澳门在我眼里，看到的不是赌场，而是文化的交织，富贵与贫穷的交叉。或许，下次再去是N年之后，但是不失为一个有趣的地方。

健身和娱乐

2017年在家里购置了划船机和哑铃凳，不再出去跑步了。

健身和读书是贯穿人生最有价值的两件事情。

深圳的空气也不再和以往一样，经常灰蒙蒙的一片。看卡pm2.5，往往也是轻度污染状态。

周边的健身房已经突破6K半年了，想想不如购入一套简单的设备，维持基本的有氧和肌肉训练已经坐骨了。

steam的游戏突破了50，还有几个烂橘子的游戏。发现自己已经进入了买了不玩的状态，似乎是在弥补自己之前没钱买游戏的遗憾。2018应该节制一点了。好游戏如同一个艺术品，买了再家里不看不如不买。

钱

最后个标题，给了钱。

2017感受到了有钱的好和没钱的坏。

感受到有钱的好，比起小时候没有经济支配权，现在的工资可以自己支配，买了许多自己之前不敢买的东西（自然有很多是浪费的）。

感受到没钱的坏，恐怕就是在澳门赌场被有钱人支配的恐惧和深圳动辄数百万的房子了吧。

年底的时候被问了一个问题，什么叫财务自由。

『当你不再问这个问题的时候』

展开全文 >>

Disk---轻量级 swift 磁盘存储方案实现

日常开发，都会有一些简单的归档需求。在 iOS 上，常用的归档主要是userdefault和write to file两种。至于数据库，对于一些轻量级的需求来说未免牛刀杀鸡。在 swift 上，有一个开源库Disk用最少的代码对归档需求进行了封装整理。

支持类型

data

disk 支持data,image,codable-data类星体。

data是常用的二进制类型。通常可以为 Image，class object, text 等等

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
26
27
28
29
30
31
32
33
34
/// Save Data to disk
    ///
    /// - Parameters:
    ///   - value: Data to store to disk
    ///   - directory: user directory to store the file in
    ///   - path: file location to store the data (i.e. "Folder/file.mp4")
    /// - Throws: Error if there were any issues writing the given data to disk
    static func save(_ value: Data, to directory: Directory, as path: String) throws {
        do {
            let url = try createURL(for: path, in: directory)
            try createSubfoldersBeforeCreatingFile(at: url)
            try value.write(to: url, options: .atomic)
        } catch {
            throw error
        }
    }
    
    /// Retrieve data from disk
    ///
    /// - Parameters:
    ///   - path: path where data file is stored
    ///   - directory: user directory to retrieve the file from
    ///   - type: here for Swifty generics magic, use Data.self
    /// - Returns: Data retrieved from disk
    /// - Throws: Error if there were any issues retrieving the specified file's data
    static func retrieve(_ path: String, from directory: Directory, as type: Data.Type) throws -> Data {
        do {
            let url = try getExistingFileURL(for: path, in: directory)
            let data = try Data(contentsOf: url)
            return data
        } catch {
            throw error
        }
    }

image

image 存储是最常见的需求之一。disk 对 image 的存储实现也很简单

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
static func save(_ value: UIImage, to directory: Directory, as path: String) throws {
        do {
            var imageData: Data
            if path.suffix(4).lowercased() == ".png" {
                if let data = UIImagePNGRepresentation(value) {
                    imageData = data
                } else {
                    throw createError(
                        .serialization,
                        description: "Could not serialize UIImage to PNG.",
                        failureReason: "Data conversion failed.",
                        recoverySuggestion: "Try saving this image as a .jpg or without an extension at all."
                    )
                }
            } else if path.suffix(4).lowercased() == ".jpg" || path.suffix(5).lowercased() == ".jpeg" {
                if let data = UIImageJPEGRepresentation(value, 1) {
                    imageData = data
                } else {
                    throw createError(
                        .serialization,
                        description: "Could not serialize UIImage to JPEG.",
                        failureReason: "Data conversion failed.",
                        recoverySuggestion: "Try saving this image as a .png or without an extension at all."
                    )
                }
            } else {
                if let data = UIImagePNGRepresentation(value) {
                    imageData = data
                } else if let data = UIImageJPEGRepresentation(value, 1) {
                    imageData = data
                } else {
                    throw createError(
                        .serialization,
                        description: "Could not serialize UIImage to Data.",
                        failureReason: "UIImage could not serialize to PNG or JPEG data.",
                        recoverySuggestion: "Make sure image is not corrupt or try saving without an extension at all."
                    )
                }
            }
            let url = try createURL(for: path, in: directory)
            try createSubfoldersBeforeCreatingFile(at: url)
            try imageData.write(to: url, options: .atomic)
        } catch {
            throw error
        }
    }

    static func retrieve(_ path: String, from directory: Directory, as type: UIImage.Type) throws -> UIImage {
        do {
            let url = try getExistingFileURL(for: path, in: directory)
            let data = try Data(contentsOf: url)
            if let image = UIImage(data: data) {
                return image
            } else {
                throw createError(
                    .deserialization,
                    description: "Could not decode UIImage from \(url.path).",
                    failureReason: "A UIImage could not be created out of the data in \(url.path).",
                    recoverySuggestion: "Try deserializing \(url.path) manually after retrieving it as Data."
                )
            }
        } catch {
            throw error
        }
    }

可以看到， 对 Image 支持是有限制的，只支持 jpg/png 类型的图片，只是简单的转换为 imagedata 进行存储。

encodable-data

encodable-data 是 swift4新加入的特性。使 class/struct 支持Codable协议，实现的对应的方法可以将其转换成其他数据格式，如 JSON。

在这里，disk 支持的是将遵循Codable实例存储为json object 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
static func save<T: Encodable>(_ value: T, to directory: Directory, as path: String) throws {
       if path.hasSuffix("/") {
           throw createInvalidFileNameForStructsError()
       }
       do {
           let url = try createURL(for: path, in: directory)
           let encoder = JSONEncoder()
           let data = try encoder.encode(value)
           try createSubfoldersBeforeCreatingFile(at: url)
           try data.write(to: url, options: .atomic)
       } catch {
           throw error
       }
   }

对于需要追加文件，先将原有数据读出，在内存中追加数据在后面，再将整个写入。

空间大小

URLResourceValues通过 URL 得到，可以对标准资源文件的空间大小进行判断

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/// Volume’s total capacity in bytes.
  public static var totalCapacity: Int? {
      get {
          let resourceValues = getVolumeResourceValues(for: .volumeTotalCapacityKey)
          return resourceValues?.volumeTotalCapacity
      }
  }
  
  /// Volume’s available capacity in bytes.
  public static var availableCapacity: Int? {
      get {
          let resourceValues = getVolumeResourceValues(for: .volumeAvailableCapacityKey)
          return resourceValues?.volumeAvailableCapacity
      }
  }

注意以上特性都是在 iOS11之后特定的，需要加上@available(iOS 11.0, *)

展开全文 >>

Alamofire 阅读

Alamofire Swift 第一网络库

开头

Alamofire 是AFNetworking 的swift实现版本。相较于OC版本的AFNetwokring，swift简洁的语法和不再兼容connection方式，使得Alamofire的代码少了很多，同时Alamofire仍旧是swift平台上使用最多的移动端网络库。

代码结构

包含核心，特性，扩展，支持文件，对比兄弟OC的AFNetwokring可以说瘦身不少。

核心文件

根据文件名，不难看出每个文件的作用。主要包含了网络库的基本内容。

request

request是处理请求的部分。包含了三个协议protocol

requestAdapter 需要协议实现者实现将一个URLRequest处理成合适的方式
RequestRetrier 需要协议实现者实现是否需要将一个Request在完成回掉完成后发起重试
TaskConvertible 需要协议是实现者实现将输入的URLSession,输出URLSessionTask

之后实现了一个基类Request，对于网络请求的抽象

Request是对所有网络请求类型的抽象，其中包含一下类型

-w652

在初始化方法中，根据requestTask的类型，调用不同的taskDelegate 的初始化方法，初始化taskdelegate。在taskdelegate 中的 queue 中添加 operation

1
self.endTime = CFAbsoluteTimeGetCurrent()

下面的方法中大量使用@discardableResult来标记。@discardableResult的作用是告诉调用者可以忽略返回值。

authenticate 方法提供了 HTTP 基本的身份校验。默认

这两个方法都是返回 Self 的。对 Self 开始并不清楚，以下这段解释是我看的说的比较明白的

而在声明接口时，我们希望在接口中使用的类型就是实现这个接口本身的类型的话，就需要使用 Self 进行指代。

下面的三个方法实现了：恢复，挂起，取消

注意到，每次都用一个临时变量 task 去获取本地 task，这点很有意思。如果获取不到，就直接退出了，说明 task 已经结束或者不存在

接下来是实现了两个extension，都遵循CustomStringConvertible协议，自定义了description和debugDescription方法。其中description方法输出基本的请求信息，debugDescription则输出curl 方法

DataRequest 是 Request 的子类，用来管理URLSessionDataTask

上述方法实现了TaskConvertible协议，尝试将自身的 urlRequest 转义，然后同步到 queue 中执行。

这里有个知识点： as! as? as

as 是向上转型，as!和 as?都是向下转型

as!和 as?不同的是：

as!如果转型失败会抛出 runtime 错误

as?转型返回可选类型，需要用户自行解包。

response

response中前两个structs,分别为DefaultDataResponse和DataResponse，都实现了存储upload task的data存储。两者的区别是，DataResponse存储的是序列化后的data，DefaultDataResponse存储的是未序列化的data。

struct DefaultDownloadResponse实现的未序列化的download request的返回data。DownloadResponse存储的是序列化的download request的data。

对应的都实现了相关的extension，分别实现了CustomStringConvertible和CustomDebugStringConvertible两个协议。

其中，DataResponse和DownloadResponse中都有个result属性，这个属性也是Alamofire定义的。

Result

Result是一个enum枚举类型,分别有.success和.failure两个枚举值，以及关联值Value和Error。

值得注意的是，result 和 response一样，都通过 extension 实现了 map、flatMap 方法。提供这两个方法可以让外部通过闭包的形式对result进行处理

TaskDelegate

TaskDelegate是负责所有代理回调和处理添加到任务执行队列任务的地方。

注意到属性task里面有几个知识点

1
2
3
4
5
6
7
8
9
10
var task: URLSessionTask? {
        set {
            taskLock.lock(); defer { taskLock.unlock() }
            _task = newValue
        }
        get {
            taskLock.lock(); defer { taskLock.unlock() }
            return _task
        }
    }

首先set/get 时候用 Lock 进行加锁，原因是防止 task 在 读写的时候被其他线程进行了改动。其次，使用了 defer 字段包括了解锁部分的代码。defer 的作用是申明一段代码块无论如何都会执行。

A defer statement defers execution until the current scope is exited. This statement consists of the defer keyword and the statements to be executed later. The deferred statements may not contain any code that would transfer control out of the statements, such as a break or a return statement, or by throwing an error. Deferred actions are executed in the reverse of the order that they’re written in your source code. That is, the code in the first defer statement executes last, the code in the second defer statement executes second to last, and so on. The last defer statement in source code order executes first.

taskDelegate主要执行URLSession的回掉方法。

SessionDelegate

SessionDelegate是对Session delegate回掉的封装。主要的属性都是一个回调闭包。

其中有三个个属性：retrier和sessionManager，requests。

retrier是一个RequestRetrier类型的属性。

sessionManager是SessionManager类型的属性

requests是[Int:Request]类型的字典

重写了responds方法，对不同系统不同selector做出判断。

SessionDelegate 通过 extension声明遵守了 URLSessionDelegate ， URLSessionTaskDelegate，URLSessionDataDelegate,URLSessionDownloadDelegate,URLSessionStreamDelegate protocol，因此实现了对应的方法

SessionManager

sessionManager 可以说是 Alamofire 里面最重要的一部分了，主要负责管理 request 和其他在 URLSessionR下面的内容

对于 sessionManager，Alamofire 鼓励有且只有一个 sessionManager，除非如同 chrome safari这些浏览器一样需要有类似隐私模式

对于创建一个 queue，可以用以下的方式

1
DispatchQueue(label: "org.alamofire.session-manager." + UUID().uuidString)

这样在堆栈跟踪的时候可以方便追溯。

在Sessionmanager里面大量使用了闭包求值的方式

1
2
3
4
5
6
7
8
let alamofireVersion: String = {
                   guard
                       let afInfo = Bundle(for: SessionManager.self).infoDictionary,
                       let build = afInfo["CFBundleShortVersionString"]
                   else { return "Unknown" }

                   return "Alamofire/\(build)"
               }()

这种方式很有意思，用闭包初始化相较于普通属性初始化的好处在于可以更简单的初始化属性，特别是对于属性开始时需要一个默认的值。

但是使用闭包初始化的时候要注意，因为在闭包内部，有些值是不安全的

1
2
3
4
5
6
7
8
let helloWorldLbl:UILabel = {
    let lbl = UILabel()
    lbl.text = self.someFunctionToDetermineText() //Compiler error
    lbl.font = UIFont.preferredFontForTextStyle(UIFontTextStyleBody)
    lbl.textColor = self.myAppTheme.textColor() //Another error
    lbl.textAlignment = .Center
    return lbl
}()

代码中的self就是不安全的，因为self可能没有初始化，同时self可能会引起循环调用。

其他的主要是URLSession的调用方法封装。

AFError

AFError继承了Error，是Alamofire对error的封装。

没有太特别的东西，不过对于业务已经逻辑错误的封装，有很多可以学习的地方。

Notifications

封装了四种通知类型，提供一个扩展来提供一个key作为notification的userinfo的key

ParameterEncoding

ParameterEncoding也是整个工程中非常重要的一个环节。我们知道在发送httpRequest的时候需要根据header中的content-type来确定我们的请求参数用什么样的方式去encode编码。
ParameterEncoding就是用来对参数做encode的。

ParameterEncoding中总共提供了三个struct，对应URLEncoding,JSONEncoding，PropertyEncoding。每个struct都遵循ParameterEncodingprotocol，所以他们都需要实现对应的encoding方法

在对字符串的处理上有些小技巧很值得借鉴，后面可以单独抽出来学习。

MultipartFormData

MultipartFormData是为upload中multipart/form-data类型提供encode方法。相比较ParameterEncoding不同，需要一些特殊处理

Constructs multipart/form-data for uploads within an HTTP or HTTPS body. There are currently two ways to encode multipart form data. The first way is to encode the data directly in memory. This is very efficient, but can lead to memory issues if the dataset is too large. The second way is designed for larger datasets and will write all the
data to a single file on disk with all the proper boundary segmentation. The second approach MUST be used for larger datasets such as video content, otherwise your app may run out of memory when trying to encode the dataset.

这部分展开了可以学习的太多了。这里主要了解是用来对上传encode就可以了。

NetworkReachabilityManager

NetworkReachabilityManager是Alamofire实现的网络状态管理工具方法。

通过SCNetworkReachabilitySetCallback回调监听系统网络变化。

1
2
3
4
5
6
7
8
let callbackEnabled = SCNetworkReachabilitySetCallback(
            reachability,
            { (_, flags, info) in
                let reachability = Unmanaged<NetworkReachabilityManager>.fromOpaque(info!).takeUnretainedValue()
                reachability.notifyListener(flags)
            },
            &context
        )

以上方法将取得一个NetworkReachabilityManager实例，调用notifyListener方法将flags传递给回调方法。

在NetworkReachabilityManager最重要的一点就是学习如何在swift中管理C指针和C对象。

在convenience init?中，我们看到

1
2
3
4
5
guard let reachability = withUnsafePointer(to: &address, { pointer in
            return pointer.withMemoryRebound(to: sockaddr.self, capacity: MemoryLayout<sockaddr>.size) {
                return SCNetworkReachabilityCreateWithAddress(nil, $0)
            }
        }) else { return nil }

这里将address作为指针传入，通过closure返回一个指针实例。pointer.withMemoryRebound是一次性绑定，将指针指定为指定的type.

ResponseSerialization

ResponseSerialization中定义和实现了response的序列化方法。

ServerTrustPolicy

ServerTrustPolicy实现的是服务器认证管理。

Timeline

Timeline用来管理请求生命周期中的时间节点。

validation

validation用来管理认证结果

展开全文 >>

iOSer该怎么做单测

本文是作者在项目组内推行单元测试的一些心得总结。

单元测试（Unit Test）是什么

针对方法/函数进行独立测试，验证结果是否符合编写预期。

TDD：测试驱动
BDD：行为驱动

原则

  • Fast — tests should be able to be executed often. 快速 – 应该随时和经常执行单测
  • Isolated — tests on their own cannot depend on external factors or on the result of another test. 独立 – 单测应该无需依赖外部实例或者依赖其他的测试结果
  • Repeatable — tests should have the same result every time we run them. 可重复 – 在不改动的情况下，多次执行应该返回相同的结果
  • Self-verifying — tests should include assertions; no human intervention needed. 自证 – 测试自身包括断言，无需人为干预
  • Timely — tests should be written along with the production code. 时效 – 单测应该随着开发进行伴随着成长

单元测试 测什么/不测什么

测什么

  1. 公开方法
  2. 依赖外部输入（网络请求、数据存储、交互操作）
  3. 工具方法

公开方法（public api）是提供给外部（其他实体/用户）使用的。理论上，调用者是不清楚API 内部的实现细节的。因此，对公开方法的单测能够保证其结果符合实现预期。同时，单测可以提供给调用者参考使用。

依赖外部输入的方法，需要确定是否处理了对应的异常，已经异步操作是否符合预期。如网络操作，我们需要考虑在网络异常造成的种种问题，通过单测来覆盖异常情况。同时，对于这些异步操作，可以轻松构造不同的input 来检查。

工具方法（until method）是常用方法，通常为 pure function，因此工具方法最适合也最需要用单测来覆盖。

不测什么

  1. 构造方法
  2. 私有方法

构造方法无需测试的原因是，构造函数本身不没有其他行为，仅仅将外部传入的参数进行赋值。除此外，单元测试应该和实现细节剥离，而构造函数本身我们应该清楚就是生成实例对象，因此无需测试构造方法。

单测本身重视的是结果，不是实现细节。因此，私有方法本身对外是封闭的，不可知的。在不知道函数定义和内部实现的时候，是无法编写单元测试的（这点肯定有争议）。

单元测试 怎么测

编写

  1. 分析函数行为
  2. 抽离外部依赖（mockstub spy）
  3. 编写用例，判断是否符合逾期

后续维护

  1. Find the test or tests that define the current behavior that you want to change. 找到测试方法是否已经不符合现在的逾期
  2. Modify those tests to expect the new desired behavior.修改为当下符合预期
  3. Run the tests and see if those modified tests fail. 测试，此时应该全部无法通过测试
  4. Update your code to make all tests pass again. 修改方法，通过测试

从单元测试能获得什么

  1. 提高代码质量
  2. 提供重构依据
  3. 提供用例

延伸 – 单测为什么难写

在写单测的时候，很多时候无从下手，原因是方法实现过于复杂，方法定义没有说明方法预期行为

1
- (void)updateRepaymentAccordingLastMonthBill:(BOOL)isUpdate card:(Card *)card

根据注释，这个方法根据传入的卡片和是否更新月账单来更新。 因此测试的时候，我们需要构造isUpdateLastestMonthBill就可以判断是行为了。

但是

  1. 这个方法返回是 void，那么是否就智能根据 aCardVo的属性来判断？如果这样，作为引用传参，aCardVo就被方法内部改变了
  2. CardVo 是个很复杂的类，在这里有什么要求？

再通过观察方法实现后发现

  1. 定义了isUpdate，这点依赖无法在外部构造，因此无法进行测试
  2. 依赖了isUpdate为NO 的时候直接返回了，这一点无法在方法定义上提现
  3. 更新还款状态，进行了数据库操作，但没有判断数据库操作行为，无法判断最终行为结果

综上，这个方法定义，如果根据原则，仅从方法定义上进行编写测试用例，是无法覆盖的。

因此，在遇到这些方法的时候，我们应该先抽离依赖，定义新的方法名，对新定义的方法名进行测试，然后将老的代码进行迁移。最后通过我们编写的测试。

用例

好的单测，本身是就是一个demo，一个说明，应该发生什么，不该发生什么。

测试用例本身就是具体业务的体现。如果业务过于复杂无法控制粒度，那么要如何在接口设计甚至整个业务模块上去做抽象拆分。

展开全文 >>

MVVM、MVC、VIPER，孰优孰劣

优秀的 iOS 应用架构：MVVM、MVC、VIPER，孰优孰劣？

英文原版

内容非常丰富的一篇讲应用架构的文章，花了挺多时间来看，还没看的很懂。

什么是好的软件架构

each object to have a specific, clear role

这句话我的理解是，每个对象拥有自己的特有的，清晰的定位。

这样的好处的是，每个对象之间职责清晰明确，模糊的边界几乎不存在。便于阅读，维护，组装。

同时，单向数据流也是被推崇的。单项数据流可以轻松的把握数据传递的路径，避免混乱的边界问题。

测试

topic这里讲述的方式是通过TDD。

这点国内和国外的最大不同在于，国外注重测试点，必须通过测试。

国内基本没有自动化的测试用例，依赖人工测试，快速迭代。

TDD不适用于敏捷开发，测试用例变动太大。

此外，由于大量业务逻辑混杂和耦合，无法明确边界，无法便于测试。

topic这里强调，如果开发者认为测试用例难以编写，说明架构已经出现了很大的问题（这里的确是）

什么是坏架构

第一点，每个执行文件的代码行数。

topic举了个例子，如果一个swift的viewcontroller行数多于3000行，或者专用的测试超过4000，这就是一个明显的信号。

global states and Up Delegate，这两个也是topic中提到的问题。

全局变量最大的问题我们无法明确值在哪里被改变了。

up delegate(代理提升？）这个概念真的不清楚。

up delegate 会造成大量class关联在一起。

设计模式

SOLID principle 当然是最经典的。但是topic这里没有讲这个，而是一点人生经验。

topic这里提到，设计模式是为了解决一类问题的方法定式。多数人沉迷某一种模式，认为是万金油，其实这是不对。离开了特定的问题，设计模式是没有用处的。这里提到了单例，我认同这种观点。单例本身不是一个坏的设计模式，而是滥用造成了单例泛滥。单例的目的是为了解决资源竞争的问题。或者通过通用设定去访问数据库或者某些接口。而在ios里，许多使用单例仅仅是为了全局同步。

logger日志是一个很好的例子，为了打印一个日志，我们不必要将logger传入每一个类中。

即使用了单例，我们也不一定要在接口中暴露出来，尤其是swift。

Composition组合模式

topic认为，如果有一种模式值得推荐，那么就是组合模式。因为topic认为，如果遵循组合模式的准则，那么一切部分都是遵循single responsibility 单一职责

遵循组合模式可以很容易的去注入，方便测试。

unity引擎是一个很好的例子。

另外一种很好的模式是依赖注入（这里存疑，我不认为依赖注入是一种很好的模式）

topic认为，小的对象，为何需要硬编码，只需通过依赖注入而不需要专门创建接口。

流行架构模式

MVC

这里的MVC是传统的MVC。传统MVC适合WEB（传统的web）。

在apple的mvc中。viewcontroller承担者mediator这和controller的职责，和view的生命周期绑定非常紧密，因此vc非常容易变得非常臃肿。因为vc无法复用，因此view也极其难复用。

在vc中，会执行网络下载，数据处理，数据绑定，业务逻辑，因此非常非常难写测试用例。因此，绝大多数的vc是没有测试 用例的

Viper

相对于viper，MVC/APPLE MVC更像是UI 模式。viper是第一个考虑如何解决整个设计架构的。

在viper中，interactor负责业务逻辑，组合不同service。 Router负责管理跳转逻辑，管理uikit framework。Presenter负责和uiKit 无关的展示逻辑。

viper很棒，但是需要非常多的模板代码，因此很少人使用。

MVVM

topic认为，MVVM是现在最适合ios的架构。

MVVM可以非常容易去测试view model。view model 不包含UI kit，因此和view controller的生命周期无关。

不受用FRP（函数变成）也可以创建完整的MVVM模式，但是使用使用起来会更加好。

MVC只能完成30%的测试覆盖的话，MVVM可以提高到70%甚至更高。

虽然MVVM是最流行的架构之一，但是很多人误解了她的用法。MVVM的优势在于便于测试，可以不依赖view controller的生命周期来测试view model中的业务逻辑。

唯一无法解决的测试问题在于，VC生命周期中的绑定。

这里举了一个例子。

有一个view controller A，拥有一个依赖，这时候需要添加另外一个view controller，这个B需要观察数据，这个时候，A就需要拥有B的依赖了。如果这时候还需要添加其他的view controller，那么A就变成一大堆的view controller的池子（这比喻很有意思）

因此，MVVM中大量的优点被这个问题掩盖掉了。

怎么解决呢？

事实上，我们希望不相关的view model之间互不依赖。为了更简单的去测试VM，topic提出了MVVM+。MVVM+意味着 MVVM with flow coordinator。这里，topic提到了redux。

通过flow coordinator，将view controller作为一个黑盒来使用。例如一个用户设置页面，我们只需要关心save和cancel操作。

Flow Coordinato

Flow Coordinato 是管理view controller的地方，准确的来说是决定展示的内容的地方。controller不需要去关心是怎么配置的，甚至可以将一个view controller配置到不同的child controller下。

Flow Coordinato可以很好的消灭if判断

ReSwift

ReSwift是非常好的三方库，使用了redux的实现，非常利于测试。这点，在react的开发中我深刻感受到了。redux的设计非常利于状态的回放。由于状态的更改都是利用纯函数，因此利于测试。

Conclusion（总结）

这个topic真的非常长，提到的内容太多，一时很难消化。

事实上，没有最好的框架，正如topic一开始讲到的。一切框架都是为了解决特定的问题去实现的。i开了具体问题谈论框架是没有意义的。可以看到，viper和MVVM都有自己独特的优点。在可测试性上都有很强的提升。但是，viper大量的模板代码和MVVM难以解决的vc bind的问题，让很多开发者望而却步。

展开全文 >>

Do MVC like it’s 1979

Do MVC like it’s 1979

文章内容：链接

文章讲了1979年最开始提出 MVC概念时的观点和现在 iOS 流行的 MVC 对比

controller or editor

在最开始，controller 应该被称为 editor，负责去update view，到了后面才被称为 controller

流程改变

最早的MVC 架构如上，可见违反了一些我们共同认知的软件设计原则：

  • Single responsibility单一原则。controller 和 view 都能去改变 model
  • Loose coupling and high cohesion 松耦合和高内聚。由于model 依赖于 view 和 controller，所以如果修改接口，会影响其他的实体。

所以，最早的的MVC 模型是不适用的。

apple 提出的 MVC 模型如下

可见，apple 的 mvc 模型会导致大量的逻辑堆积在一个实体上，比如 controller。多数用户没能很好应用 model 去承载业务逻辑。

从 MVC 设计中学习

不把 MVC 仅当做一个架构，作为一种设计理念，可以学习到以下内容

分离。

MVC 定义了三个组件来承担逻辑。

Facade。（外观模式）

通常开发忽略了在 model中处理共用逻辑，而全部放在了 controller 中。因此造成了胖 controller 和 瘦 model 。facade 意味这一个对象隐藏了大量的逻辑实现。避免直接和 model 进行沟通。外观模式保证了 model 在增长的过程中不影响上层。

观察者

观察者是一种通用的来对 model 解耦的方法。通常的做法是，model 不关心谁需要知道状态变更，而是发出状态变更的通知。相关观察了 model 的实体会去接收通知，执行对应的逻辑。

通过观察者模式，可以讲 model layer设计成独立的服务。服务的生命周期等同于应用的声明周期。如网络服务，统计服务，聊天服务。

Mediator(传递者）

在 MVC中，controller 承担着 mediator 的责任。一个对象，依赖越多，承担的逻辑应该越少（这里应该认为，如果承担过多的逻辑，修改的成本很高）

controller 因此会承担很多浇水代码。

因为 controller 的胶水属性，尽可能避免在 controller 中保存状态值，以 model 的 computer interface 来计算出来

现代工程的 MVC

APPLE MVC

常见的 iOS 架构设计，苹果经典的 MVC。

viewController 同时担任了 view 和 controller的职责

缺点 controller 臃肿

MVP/MVVM

强调了单一原则。

VIPER/Riblets

和 MVX 的不同在于改变了形态，使用 Service/Repository/Storage
至少有两个 controller ，分别为 router(路由)，presenter(展示器)

学到了什么

  • 不要把 MVC 仅仅当做一种架构，而是一种架构设计的思想
  • 不仅仅能解释一种架构，而是理解每种架构解决的问题
  • apple 的MVC 解决了他们的问题，但不一定适合自己的问题
  • 避免过度设计，在不必要的时候无需拆分
  • 以用户更流畅的使用，而不是让开发者更轻松

展开全文 >>

再认识一次『锁』

基本概念

时间片轮转调度算法

系统给每个线程分配一个时间片(100ms)，当线程分配的时间片消耗完，会被移动到队列尾部。

原子操作

操作不可再分割，不可终端

临界区

访问临界资源的代码块。每次只允许一个进程进入临界区。

忙等

试图进入临界区的线程，占着CPU而不释放的状态

互斥锁

如果一个线程无法获取互斥量，这个线程将会被挂起。当其他线程释放互斥锁的时候，系统将会唤醒被挂起的线程。互斥锁会使得线程阻塞。阻塞有两个阶段。第一个阶段将空转，不停去尝试获取锁。第二个阶段将会进入 waiting 阶段，不再消耗 CPU资源，直到被系统唤醒。

自旋锁

自旋锁不会被挂起，将会不停消耗资源去获取锁。

NSLock && pthread_mutex_lock 互斥锁

NSLock 是 Objective-C 以对象的形式暴露给开发者的一种锁。

pthread_mutex_lock是POSIX互斥锁

NSLock比pthread_mutex_lock慢的原因是经过的方法调用（runtime）。但是 runtime 会对方法调用进行缓存，所以多次调用不会有性能影响。

NSRecursiveLock 递归锁

递归锁可以在同一个线程被多次获得，解锁的条件就是加锁的次数和解锁的次数一样多。

NSRecursiveLock 与 NSLock 的区别在于内部封装的 pthread_mutex_t 对象的类型不同，前者的类型为 PTHREAD_MUTEX_RECURSIVE

NSConditionLock && NSCondition

条件锁，看到用的地方不多。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@interface NSConditionLock : NSObject <NSLocking> {
@private
    void *_priv;
}

- (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;

@property (readonly) NSInteger condition;
- (void)lockWhenCondition:(NSInteger)condition;
- (BOOL)tryLock;
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;
- (BOOL)lockBeforeDate:(NSDate *)limit;
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;

@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));

@end

和 NSLock 类似，不同的地方是加锁和解锁只有在符合条件的时候。

根据白夜追凶，揭开iOS锁的秘密一文。

NSCondition的底层是通过条件变量(Condition variable) pthread_cond_t 来实现的。条件变量有点像信号量，提供了线程阻塞与信号机制，因此可以用来阻塞某个线程，并等待某个数据就绪，随后唤醒线程。其组成结构是

信号量可以一定程度上替代 Condition，但是互斥锁不行。在以上给出的生产者-消费者模式的代码中， pthread_cond_wait 方法的本质是锁的转移，消费者放弃锁，然后生产者获得锁，同理， pthread_cond_signal 则是一个锁从生产者到消费者转移的过程。

这样做存在的问题在于，在等待 another_lock 之前， 生产者有可能先执行代码， 从而释放了 another_lock。也就是说，我们无法保证释放锁和等待另一个锁这两个操作是原子性的，也就无法保证“先等待、后释放 another_lock” 这个顺序。

用信号量则不存在这个问题，因为信号量的等待和唤醒并不需要满足先后顺序，信号量只表示有多少个资源可用，因此不存在上述问题。然而与 pthread_cond_wait 保证的原子性锁转移相比，使用信号量似乎存在一定风险(暂时没有查到非原子性操作有何不妥)。

不过，使用 Condition 有一个好处，我们可以调用 pthread_cond_broadcast 方法通知所有等待中的消费者，这是使用信号量无法实现的。

NSCondition封装了互斥锁和信号量，将 lock/signal/wait 封装起来提供给开发者。

1
2
3
[condition wait];让当前线程处于等待状态

[condition signal];CPU发信号告诉线程不用在等待，可以继续执行

需要注意的是： NSCondition 的对象实际上作为一个锁和一个线程检查器，锁上之后其它线程也能上锁，而之后可以根据条件决定是否继续运行线程，即线程是否要进入 waiting 状态，经测试， NSCondition 并不会像上文的那些锁一样，先轮询，而是直接进入 waiting 状态，当其它线程中的该锁执行 signal 或者 broadcast 方法时，线程被唤醒，继续运行之后的方法。

NSCondition 信号只能发送，不能保存（如果没有线程在等待，则发送的信号会失效）

总结步骤如下

  1. 锁定条件对象
  2. 判断是否可以进入临界区
  3. 加入不可以进入，调用 wait/waitUntilDate:来阻塞线程。待方法返回时，继续检查是否可以执行下面的任务，直到可以进入或超时。
  4. 执行任务
  5. 释放条件对象

@synchronized

@synchronized是最常用一种加锁方式。传入一个对象作为锁定标记可以起到锁的作用。

@synchronized 将传入的对象地址的 hash 值作为 key,将SyncData作为 value。

传递给 @synchronized指令的对象是用于区分受保护块的唯一标识符。如果在两个不同的线程中执行上述方法，则在每个线程上为anObj参数传递一个不同的对象，每个线程都会锁定并继续处理而不被另一个线程阻塞。但是，如果在两种情况下传递相同的对象，则其中一个线程将首先获取锁，另一个会阻塞，直到第一个线程完成临界区。

需要注意的问题有几个

  1. 你调用 sychronized 的每个对象，Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。
  2. 如果在 sychronized 内部对象被释放或被设为 nil 看起来都 OK。不过这没在文档中说明，所以我不会再生产代码中依赖这条。注意不要向你的 sychronized block 传入 nil！这将会从代码中移走线程安全。你可以通过在 objc_sync_nil 上加断点来查看是否发生了这样的事情。

dispatch_semaphore

dispatch_semaphore 是 GCD用来实现同步的一种方式，即信号量。

1
2
3
dispatch_semaphore_create(long value);
dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);
dispatch_semaphore_signal(dispatch_semaphore_t dsema);

dispatch_semaphore 和 NSCondition 类似，都是一种基于信号的同步方式， dispatch_semaphore 能保存发送的信号。 dispatch_semaphore 的核心是 dispatch_semaphore_t 类型的信号量。

dispatch_semaphore_create(1)会创建一个dispatch_semaphore_t的信号量，初始值为1。这里必须传如非负数的，否则会返回 NULL。只有创建为1的时候才能作为锁，否则可能会有多个线程访问临界区。

dispatch_semaphore_wait (signal, overTime); 方法会判断 signal 的信号值是否大于 0。大于 0 不会阻塞线程，消耗掉一个信号，执行后续任务。如果信号值为 0，该线程会和 NSCondition 一样直接进入 waiting 状态，等待其他线程发送信号唤醒线程去执行后续任务，或者当 overTime 时限到了，也会执行后续任务。

dispatch_semaphore_signal(signal); 发送信号，如果没有等待的线程接受信号，则使 signal 信号值加一（做到对信号的保存）

总结一下

  1. 如果应用在递归场景的时候，我们有2种选择，一个是 NSRecursiveLock，另一个是 pthread_mutex(recursive)。追求高性能的话，优先选择 pthread_mutex，苹果已对 pthread_mutex进行过多次优化。
  2. 普通场景可以用@synchronized，但是加锁解锁效率最慢。建议是用dispatch_semaphore或者pthread_mutex

展开全文 >>

持久化学习系列2

PINCache

第二篇是关于最经典的KV缓存解决方案PINCache

客户端的存储

在正式讲解PINCache前，先来谈谈客户端什么时候需要做存储。

总所周知，现在的APP越来越依赖网络，在离开网络的情况下，绝大多数的APP都成了摆设。然而，优秀的APP已经有自己的一套设计，避免在无网或者弱网的情况下完全失去作用。例如微信这样的强网络要求的APP,在失去网络的情况依然能够浏览本地缓存的聊天信息和朋友圈记录。优秀的APP，应该根据自己的业务需求，选择合适的存储方案。对于一般体量的APP来说，利用KV形式的存储是最好不过的选择。

KV，即Key-Value形式的存储。通常客户端的信息是由后端给出的json解析的,使用Key-Value正是方便了这种格式。

PINCache

PINCache是脱胎于TMCache，解决了TMCache中的线程死锁问题。PINCache中依然设计了memoryCache和diskCache两种，分别解决了临时存储和长期持久化的问题。
在PINCache的github主页上，提出在iOS上如果没有特别的情况，尽可能使用diskCache，原因是每次iOS应用启动，都会造成memoryCache中的内容被清空。在下面，会对比下内存缓存和磁盘缓存的优缺点，以及PINCache是如何实现的，

文件结构

从图上可以看到，PINCache的实现并不复杂，除去PINCache本身实现对外的方法外，总共只有八个实现文件。

PINMemoryCache

PINMemoryCache为实现内存缓存的类。什么是内存缓存，我们可以理解为通过一个NSMutableDictionary来临时存储对象。实现一个内存缓存难度不大，通常需要完成以下几个事情：

  1. 选择合适的存储结构
  2. 选择和实现对应的读写方法
  3. 选择和实现淘汰方法
  4. 处理系统内存警告

了解了以上步骤，我们来看看PINMemoryCache是怎么解决上面的问题

  1. 选择NSMutableDictionary作为存储结构
  2. 采用NSMutableDictionary的读写方法
  3. 通过两个NSMutableDictionary分别记录date和cost,实现时间和内容的管理。
  4. 收到内存警告后，清空内存中所有的对象，清空缓存。

看上去不难？在笔者看来，实现内存缓存的难度主要是2，3点。在这里，PINMemoryCache主要考虑的是如何解决多线程安全的问题，以及缓存淘汰问题。

多线程安全

由于缓存的特殊性，读写必须考虑到多线程安全的问题。如果一个线程改变了缓存中的某个值，而别的线正好需要这个值，处理不好轻则造成数据出错，重则造成程序崩溃。

在PINMemoryCache中，使用了pthread_mutex_t来保证线程安全。

pthread_mutex_t为互斥锁，当锁上的时候，其他线程就无法访问被锁上的资源

使用pthread_mutex_t需要注意几点。

必须在dealloc方法中主动释放

1
2
3
4
5
6
7
8

- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self];

    __unused int result = pthread_mutex_destroy(&_mutex);
    NSCAssert(result == 0, @"Failed to destroy lock in PINMemoryCache %p. Code: %d", (void *)self, result);
}

单独使用pthread_mutex_t容易造成死锁，同时也坑你造成效率不高，可以通过实现对应的递归锁来避免

1
2
3
4
5
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&lock, &attr);
pthread_mutexattr_destroy(&attr);

在完成锁的初始化后，就需要考虑什么时候要加锁解锁了

为了避免data race的情况，在这里，PINMemoryCache选择了对所有读写操作都进行加锁。同时，采用副本的形式避免读取的数据被篡改。

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
- (__nullable id)objectForKey:(NSString *)key
{
    if (!key)
        return nil;
    
    NSDate *now = [[NSDate alloc] init];
    [self lock];
        id object = nil;
        // If the cache should behave like a TTL cache, then only fetch the object if there's a valid ageLimit and  the object is still alive
        if (!self->_ttlCache || self->_ageLimit <= 0 || fabs([[_dates objectForKey:key] timeIntervalSinceDate:now]) < self->_ageLimit) {
            object = _dictionary[key];
        }
    [self unlock];
        
    if (object) {
        [self lock];
            _dates[key] = now;
        [self unlock];
    }

    return object;
}


- (void)setObject:(id)object forKey:(NSString *)key withCost:(NSUInteger)cost
{
    if (!key || !object)
        return;
    
    [self lock];
        PINMemoryCacheObjectBlock willAddObjectBlock = _willAddObjectBlock;
        PINMemoryCacheObjectBlock didAddObjectBlock = _didAddObjectBlock;
        NSUInteger costLimit = _costLimit;
    [self unlock];
    
    if (willAddObjectBlock)
        willAddObjectBlock(self, key, object);
    
    [self lock];
        NSNumber* oldCost = _costs[key];
        if (oldCost)
            _totalCost -= [oldCost unsignedIntegerValue];

        _dictionary[key] = object;
        _dates[key] = [[NSDate alloc] init];
        _costs[key] = @(cost);
        
        _totalCost += cost;
    [self unlock];
    
    if (didAddObjectBlock)
        didAddObjectBlock(self, key, object);
    
    if (costLimit > 0)
        [self trimToCostByDate:costLimit];
}

通过这两个读写方法，我们发现，PINMemoryCache对任何涉及属性操作的地方都进行了锁操作，避免了data race的情况。

缓存淘汰

缓存淘汰，也就是第三点。如果保证缓存中数据有效性，保证缓存搞笑的利用是所有缓存应该考虑的问题。通常来讲，我们应该从缓存利用率上来着手，只保留常被使用的数据，淘汰长期不需要的数据。LRU就会常用的一种缓存淘汰算法。在这里，PINMemoryCache通过时间和空间来实现的LRU算法。

在上面贴出的读写中，读的时候，更新date中key对应的时间。在写的时候，记录或更新key对应时间。

当触发缓存删除操作的时候，优先删除占用空间大和使用时间靠前的的内容。

至此，PINMemoryCache的内容基本就分析完了。内存缓存的实现，只要考虑清楚上面列的四个内容，我认为就不难做到，剩下的就是实现细节和性能的考量了。

PINDiskCache

PINDiskCache实现的磁盘缓存。我们知道，磁盘的读取速度要远小于内存读取。大量的磁盘I/O会降低程序的运行效率。虽然如此，面对大体量的数据以及需要长期存储的数据，我们只能考虑存储在磁盘上。同时，由于iOS系统的特殊性，选择存储在磁盘上往往是我们的第一选择。

和memory cache不同，磁盘I/O需要考虑的问题要更多一点，除了上面再memory cache讲到的几点外，还需要考虑一下几点。

  1. 实现方式。磁盘存储一般分为三种：文件读写，数据库，mmap文件内存映射。PINDiskCache使用的是文件读写的方式
  2. 存储位置。iOS文件系统不同位置建议存储的内容不同。是放在cache文件夹中还是temp文件中取决于开发者对存储文件的态度。
  3. 文件系统的细节。避免和其他文件产生冲突，必须考虑拥有自身的标记。
  4. 数据序列化

看上去磁盘缓存的实现的确要难上很多问题，在内存缓存的基础上依然要考虑这么多问题。

PINDiskCache在这四个问题上，充分考虑了oc语言已经iOS已经MAC OS系统的特性。首先采用文件读写的方式，依然考虑了数据的特性。文件读写的方式非常适合用于存储数据规模小的情况，同时实现方便，性能稳定也是选择的原因之一。但是使用文件存储也有不小的弱点：方便扩展、没有元数据、难以实现较好的淘汰算法、数据统计缓慢。

2，3，4点将在下面实现细节中会讲到。

实现细节

线程安全

线程安全依然是绕不过去的一个坎，在PINDiskCache里，除了需要对付一般的data race，还需要处理磁盘I/O带来的问题。

在这里，PINDiskCache使用的是NSConditionLock条件锁。在代码中有如下定义：

1
2
3
4
typedef NS_ENUM(NSUInteger, PINDiskCacheCondition) {
    PINDiskCacheConditionNotReady = 0,
    PINDiskCacheConditionReady = 1,
};

可见，条件锁中并不涉及到具体的实例对象，而是一个常量来作为锁的条件。在这里，个人认为直接用递归锁差别也不是很大，不知道为何这里选择使用了条件锁。（或许有一天知道了会回来补。

在使用中，所有对成员变量操作的地方都进行的锁操作。(实际上有些地方是不需要用的)

读写

磁盘读写如果不注意极其容易造成死锁。

写：

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
- (void)setObject:(id <NSCoding>)object forKey:(NSString *)key fileURL:(NSURL **)outFileURL
{
    if (!key || !object)
        return;
    
    #if TARGET_OS_IPHONE
      NSDataWritingOptions writeOptions = NSDataWritingAtomic | self.writingProtectionOption;
    #else
      NSDataWritingOptions writeOptions = NSDataWritingAtomic;
    #endif
  
    NSURL *fileURL = [self encodedFileURLForKey:key];
    
    [self lock];
        PINDiskCacheObjectBlock willAddObjectBlock = self->_willAddObjectBlock;
        if (willAddObjectBlock) {
            [self unlock];
                willAddObjectBlock(self, key, object);
            [self lock];
        }
    
        //We unlock here so that we're not locked while serializing.
        [self unlock];
            NSData *data = _serializer(object, key);
        [self lock];
    
        NSError *writeError = nil;
  
        BOOL written = [data writeToURL:fileURL options:writeOptions error:&writeError];
        PINDiskCacheError(writeError);
        
        if (written) {
            NSError *error = nil;
            NSDictionary *values = [fileURL resourceValuesForKeys:@[ NSURLContentModificationDateKey, NSURLTotalFileAllocatedSizeKey ] error:&error];
            PINDiskCacheError(error);
            
            NSNumber *diskFileSize = [values objectForKey:NSURLTotalFileAllocatedSizeKey];
            if (diskFileSize) {
                NSNumber *prevDiskFileSize = [self->_sizes objectForKey:key];
                if (prevDiskFileSize) {
                    self.byteCount = self->_byteCount - [prevDiskFileSize unsignedIntegerValue];
                }
                [self->_sizes setObject:diskFileSize forKey:key];
                self.byteCount = self->_byteCount + [diskFileSize unsignedIntegerValue]; // atomic
            }
            NSDate *date = [values objectForKey:NSURLContentModificationDateKey];
            if (date) {
                [self->_dates setObject:date forKey:key];
            }
            
            if (self->_byteLimit > 0 && self->_byteCount > self->_byteLimit)
                [self trimToSizeByDate:self->_byteLimit block:nil];
        } else {
            fileURL = nil;
        }
    
        PINDiskCacheObjectBlock didAddObjectBlock = self->_didAddObjectBlock;
        if (didAddObjectBlock) {
            [self unlock];
                didAddObjectBlock(self, key, object);
            [self lock];
        }
    [self unlock];
    
    if (outFileURL) {
        *outFileURL = fileURL;
    }
}

读：

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
- (__nullable id <NSCoding>)objectForKey:(NSString *)key fileURL:(NSURL **)outFileURL
{
    NSDate *now = [[NSDate alloc] init];
    
    if (!key)
        return nil;
    
    id <NSCoding> object = nil;
    NSURL *fileURL = [self encodedFileURLForKey:key];
    
    [self lock];
        if (!self->_ttlCache || self->_ageLimit <= 0 || fabs([[_dates objectForKey:key] timeIntervalSinceDate:now]) < self->_ageLimit) {
            // If the cache should behave like a TTL cache, then only fetch the object if there's a valid ageLimit and  the object is still alive
            NSData *objectData = [[NSData alloc] initWithContentsOfFile:[fileURL path]];
          
            if (objectData) {
              //Be careful with locking below. We unlock here so that we're not locked while deserializing, we re-lock after.
              [self unlock];
              @try {
                  object = _deserializer(objectData, key);
              }
              @catch (NSException *exception) {
                  NSError *error = nil;
                  [self lock];
                      [[NSFileManager defaultManager] removeItemAtPath:[fileURL path] error:&error];
                  [self unlock];
                  PINDiskCacheError(error);
              }
              [self lock];
            }
            if (object && !self->_ttlCache) {
                [self asynchronouslySetFileModificationDate:now forURL:fileURL];
            }
        }
    [self unlock];
    
    if (outFileURL) {
        *outFileURL = fileURL;
    }
    
    return object;
}

在序列化和反序列化的地方解锁，之后再上锁，目的是避免死锁问题(序列化失败等)。

在读写之后，改变文件的最后修改时间，作为一个参考依据。

在写入的时候，先尝试将数据写入到磁盘，然后读取写入的文件的信息，比较文件的大小是否和写入的数据大小相同

异步操作

在PINDiskCache中大量使用了异步操作。比如读取文件后修改文件时间：

1
2
3
4
5
6
7
8
9
10
11
12
- (void)asynchronouslySetFileModificationDate:(NSDate *)date forURL:(NSURL *)fileURL
{
    __weak PINDiskCache *weakSelf = self;
    [self.operationQueue addOperation:^{
        PINDiskCache *strongSelf = weakSelf;
        if (strongSelf) {
            [strongSelf lock];
                [strongSelf _locked_setFileModificationDate:date forURL:fileURL];
            [strongSelf unlock];
        }
    } withPriority:PINOperationQueuePriorityLow];
}

这里用的operationQueue就是在下面要讲到PINCache自己实现的一套异步方案

淘汰方法

PINDiskCache仍然根据文件大小和最近修改时间来作为淘汰的依据。

PINOperationQueue

PINOperationQueue是PINCache实现的一个并发控制方案。实现了最大并发数，取消，优先级管理。在PINDiskCache中大量使用了PINOperationQueue来达到并发行为的控制。

实现细节

PINOperationQueue是对外公开的操作，主要是通过下面方法添加操作

1
2
3
4
5
6
- (id <PINOperationReference>)addOperation:(PINOperationBlock)operation
                              withPriority:(PINOperationQueuePriority)priority
                                identifier:(NSString *)identifier
                            coalescingData:(nullable id)coalescingData
                      dataCoallescingBlock:(nullable PINOperationDataCoallescingBlock)dataCoallescingBlock
                                completion:(nullable dispatch_block_t)completion;

其中dataCoallescingBlock和coalescingData提供了联合数据处理的能力，例如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
- (void)trimToDate:(NSDate *)trimDate block:(PINDiskCacheBlock)block
{
    PINOperationBlock operation = ^(id data){
        [self trimToDate:(NSDate *)data];
    };
    
    dispatch_block_t completion = nil;
    if (block) {
        completion = ^{
            block(self);
        };
    }
    
    [self.operationQueue addOperation:operation
                         withPriority:PINOperationQueuePriorityLow
                           identifier:PINDiskCacheOperationIdentifierTrimToDate
                       coalescingData:trimDate
                  dataCoallescingBlock:PINDiskTrimmingDateCoallescingBlock
                           completion:completion];
}

这个方法中，DiskCache会去清除指定时间的数据，在这里，添加到PINOperationQueue的时候，将trimDate作为联合数据传入。这里的联合数据，可以认为是block之外的一个负载。

初始化

通过初始化可以得知，PINOperationQueue是怎么实现上述功能的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
pthread_mutex_t _lock;
 //increments with every operation to allow cancelation
 NSUInteger _operationReferenceCount;
 NSUInteger _maxConcurrentOperations;
 
 dispatch_group_t _group;
 
 dispatch_queue_t _serialQueue;
 BOOL _serialQueueBusy;
 
 dispatch_semaphore_t _concurrentSemaphore;
 dispatch_queue_t _concurrentQueue;
 dispatch_queue_t _semaphoreQueue;
 
 NSMutableOrderedSet<PINOperation *> *_queuedOperations;
 NSMutableOrderedSet<PINOperation *> *_lowPriorityOperations;
 NSMutableOrderedSet<PINOperation *> *_defaultPriorityOperations;
 NSMutableOrderedSet<PINOperation *> *_highPriorityOperations;
 
 NSMapTable<id<PINOperationReference>, PINOperation *> *_referenceToOperations;
 NSMapTable<NSString *, PINOperation *> *_identifierToOperations;

通过PINOperationQueue的成员变量，可以得知：

  1. 通过dispatch_semaphore_t来实现并发数控制。dispatch_semaphore_t是信号量
  2. 通过NSMutableOrderedSet实现了优先级和顺序管理。NSMutableOrderedSet是具有排序功能的集合类。
  3. 通过NSMapTable实现了绑定id和操作。NSMapTable类似NSdictionry，区别在于NSMapTable是可变的，同时键值可以为弱引用，当任何一项为nil的时候将这一项移除。同时，NSMapTable可以存储任意指针，通过指针来进行相等性和散列校验

初始化代码如下：

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
26
27
28
29
30
31
32
33
- (instancetype)initWithMaxConcurrentOperations:(NSUInteger)maxConcurrentOperations concurrentQueue:(dispatch_queue_t)concurrentQueue
{
  if (self = [super init]) {
    NSAssert(maxConcurrentOperations > 1, @"Max concurrent operations must be greater than 1. If it's one, just use a serial queue!");
    _maxConcurrentOperations = maxConcurrentOperations;
    _operationReferenceCount = 0;
    
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    //mutex must be recursive to allow scheduling of operations from within operations
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
    pthread_mutex_init(&_lock, &attr);
    
    _group = dispatch_group_create();
    
    _serialQueue = dispatch_queue_create("PINOperationQueue Serial Queue", DISPATCH_QUEUE_SERIAL);
    
    _concurrentQueue = concurrentQueue;
    
    //Create a queue with max - 1 because this plus the serial queue add up to max.
    _concurrentSemaphore = dispatch_semaphore_create(_maxConcurrentOperations - 1);
    _semaphoreQueue = dispatch_queue_create("PINOperationQueue Serial Semaphore Queue", DISPATCH_QUEUE_SERIAL);
    
    _queuedOperations = [[NSMutableOrderedSet alloc] init];
    _lowPriorityOperations = [[NSMutableOrderedSet alloc] init];
    _defaultPriorityOperations = [[NSMutableOrderedSet alloc] init];
    _highPriorityOperations = [[NSMutableOrderedSet alloc] init];
    
    _referenceToOperations = [NSMapTable weakToWeakObjectsMapTable];
    _identifierToOperations = [NSMapTable weakToWeakObjectsMapTable];
  }
  return self;
}

在这里，实现了一个递归锁。递归锁允许在未释放锁的时候反复的上锁，当解锁次数和等于上锁的次数的时候才PINOperationQueue可能在一个多次加锁。

并发

PINOperationQueue最大特色就是实现了并发管理操作，提供cancel，wait, Priority的功能，通过实现来看看怎么做到的。

- (void)scheduleNextOperations:(BOOL)onlyCheckSerial方法为派发operation的地方私有方法。

scheduleNextOperations执行的分为两块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[self lock];
  //get next available operation in order, ignoring priority and run it on the serial queue
  if (_serialQueueBusy == NO) {
    PINOperation *operation = [self locked_nextOperationByQueue];
    if (operation) {
      _serialQueueBusy = YES;
      dispatch_async(_serialQueue, ^{
        operation.block(operation.data);
        for (dispatch_block_t completion in operation.completions) {
          completion();
        }
        dispatch_group_leave(_group);
        
        [self lock];
          _serialQueueBusy = NO;
        [self unlock];
        
        //see if there are any other operations
        [self scheduleNextOperations:YES];
      });
    }
  }
[self unlock];

在这里，locked_nextOperationByQueue从_queuedOperations取出第一个operation，然后异步派发到_serialQueue中执行。可以看出，这里本质是串行取出operation然后再派发到_serialQueue异步执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
dispatch_async(_semaphoreQueue, ^{
    dispatch_semaphore_wait(_concurrentSemaphore, DISPATCH_TIME_FOREVER);
    [self lock];
      PINOperation *operation = [self locked_nextOperationByPriority];
    [self unlock];
  
    if (operation) {
      dispatch_async(_concurrentQueue, ^{
        operation.block(operation.data);
        for (dispatch_block_t completion in operation.completions) {
          completion();
        }
        dispatch_group_leave(_group);
        dispatch_semaphore_signal(_concurrentSemaphore);
      });
    } else {
      dispatch_semaphore_signal(_concurrentSemaphore);
    }
});

在这里，实现了并发，从locked_nextOperationByPriority方法中根据优先级获得一个operation，异步派发到_concurrentQueue中执行。这里通过信号量来管理并发数，当信号量为0的时候就会一直等待。

locked_nextOperationByPriority中从_highPriorityOperations取，取不到的情况下就从下一个优先级的set中取。

看懂了scheduleNextOperations，再看locked_cancelOperation就不难了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- (BOOL)locked_cancelOperation:(id <PINOperationReference>)operationReference
{
  BOOL success = NO;
  PINOperation *operation = [_referenceToOperations objectForKey:operationReference];
  if (operation) {
    NSMutableOrderedSet *queue = [self operationQueueWithPriority:operation.priority];
    if ([queue containsObject:operation]) {
      success = YES;
      [queue removeObject:operation];
      [_queuedOperations removeObject:operation];
      dispatch_group_leave(_group);
    }
  }
  return success;
}

取消操作，主要根据operationRef来取出操作，然后从所在的优先级队列中删除对应的operation。注意到，如果这个operation已经被派发到执行队列上了，就无法取消了。

PINOperationGroup是在PINOperationQueue之上再实现的包装。

PINOperationQueue和PINOperationGroup可以看做是PINCache使用的GCD实现一套与NSOperation相似的功能。通过学习阅读这一块，可以加深对GCD异步处理的理解。

尾声

PINCache是这个系列的第二篇，个人感觉收获很大，对整个key-value缓存实现的一个思路有了更清楚的认识。

下一篇，打算看看YYCache,主要关注点是如何实现缓存淘汰算法和优化性能的。

展开全文 >>

持久化学习系列1

SPTPersistentCache是spotify开源的一套持久化框架。SPTPersistentCache主要解决NSData存储到文件系统的过程。

亮点

  • 基于LRU
  • 线程安全
  • 可视化工具
  • 类HTTP设计

成员分析

先从Public Api来进行分析

SPTPersistentCache是核心，同比为manager的角色。
SPTPersistentCacheOptions是配置选项，
SPTPersistentCacheHeader是SPTPersistentCache的一大设计的特色，数据表头
SPTPersistentCacheRecord为数据单元。
SPTPersistentCacheResponse为操纵数据的基本单位。

这次分析打算从下往上，先从基本的数据单元开始

SPTPersistentCacheRecord

SPTPersistentCacheRecord中除了data之外还定义三个辅助数据

  • refCount 引用计数
  • ttl 生存时间
  • key

可以从SPTPersistentCacheRecord看出SPTPersistent依照引用次数和时间来管理缓存对象

SPTPersistentCacheResponse

SPTPersistentCacheResponse是对SPTPersistentCacheRecord的再一层包装。新增了对外属性

  • SPTPersistentCacheResponseCode
  • NSError

从SPTPersistentCacheResponseCode可以看出这一层与读写操作相关了。

SPTPersistentCacheRecord

SPTPersistentCacheRecord并不是一个类，而是一个结构体。在这里，可以将SPTPersistentCacheRecord与HTTP中的header进行类比。

关键点：crc，flags

crc：循环冗余校验 在数据写入前通过计算生成32位整数，拼接在数据后面。在读取的时候进行校验，确认数据是否完整。SPTPersistentCache使用的是CRC-64-ISO

flags: 判断数据是否在上次写入的时候没能完成。这个更多是逻辑而不是一个错误。

SPTPersistentCacheOptions

SPTPersistentCacheOptions是cache的配置相关的内容。从配置中够可以看出SPTPersistentCache的一些特性

identifierForQueue作为唯一队列标识，可以预知每一个cache拥有唯一的队列

cacheIdentifier作为配置对应的cache唯一标识

优先级设定中分别定义了并发操作数，读写删的优先级

1
2
3
4
5
6
7
@property (nonatomic) NSInteger maxConcurrentOperations;
@property (nonatomic) NSOperationQueuePriority writePriority;
@property (nonatomic) NSOperationQueuePriority readPriority;
@property (nonatomic) NSOperationQueuePriority deletePriority;
@property (nonatomic) NSQualityOfService writeQualityOfService;
@property (nonatomic) NSQualityOfService readQualityOfService;
@property (nonatomic) NSQualityOfService deleteQualityOfService;

GC设定中对GC的配置进行设定

garbageCollectionInterval决定了GC的间隔

defaultExpirationPeriod 决定默认过期时间

sizeConstraintBytes 设定了缓存空间的限制

garbageCollectionPriority设定GC操作的优先级

garbageCollectionQualityOfService设定GC服务的QOS

从option中可以窥探出，在开发过程中可能会有多个cache，每个cache之间的配置独立，拥有独立的优先级和GC管理

SPTPersistentCache

SPTPersistentCache是整个持久化库的核心类，包含了读，写，查，删，锁等操作

读操作中，对外公开的两个API最后会归集到下面这个方法中

1
2
3
- (void)loadDataForKeySync:(NSString *)key
              withCallback:(SPTPersistentCacheResponseCallback)callback
                   onQueue:(dispatch_queue_t)queue

方法并不是很复杂，具体的流程简单描述如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
首先，根据key去查找是否有对应的文件，木有的话就抛错 (1)

如果找到了文件，读取data，如果读取失败，认为文件损坏了，抛错(2)

从文件中读出了数据，根据headerSize取出head。如果不能正确的拼装出header，即认为此文件无法继续操作，抛错(3)

拼装了header后，进行校验，校验不通过，抛错(4)

与本地header做比较，如果不一致，抛错(5)

将读出的payload(负载数据)组装成`SPTPersistentCacheRecord`，再将`SPTPersistentCacheRecord`组装成`SPTPersistentCacheResponse`

将访问数据相关写回磁盘

将response通过block回调给开发者。

可以看到，总共有5步抛错的地方，都是对数据完整性的校验。

相对于读，写的难度就小了很多，不太复杂。写方法主要是在

1
2
3
4
5
6
- (NSError *)storeDataSync:(NSData *)data
                    forKey:(NSString *)key
                       ttl:(NSUInteger)ttl
                    locked:(BOOL)isLocked
              withCallback:(SPTPersistentCacheResponseCallback)callback
                   onQueue:(dispatch_queue_t)queue

将Header与data拼装后组成rowData，然后写入磁盘，注意判断是否写入成功。之后通过block将response回调给开发者

GC和LRU实现

LRU是Least Recently Used 近期最少使用算法。

在最近的面试中，经常会谈到一些缓存库的实现，比如最常见的SDWebImageCache。对此我常会提出一个疑问，如何设计高效的缓存。几乎没人能够谈谈缓存调度算法。LRU其实就是最常用的一种缓存调度算法，目的就是尽力保证缓存中的数据是常用的。

这里谈谈SPTPersistentCache中是如何实现GC和LRU算法的。

在上文SPTPersistentCacheRecord的简介中，我们看到了两个关键的属性：TTL && refcount。我们可以猜测到，SPTPersistentCache是通过实践和引用值来判断是数据的有效性的。

GC的核心是👇这个方法

1
- (void)collectGarbageForceExpire:(BOOL)forceExpire forceLocked:(BOOL)forceLocked

传参分别是强制过期和强制加锁。

过程不复杂，通过NSDirectoryEnumerator迭代器从self.fileManager中取出所有文件。

判断是否过期是通过下面这个方法

1
2
3
4
- (SPTPersistentCacheResponse *)alterHeaderForFileAtPath:(NSString *)filePath
                                               withBlock:(SPTPersistentCacheRecordHeaderGetCallbackType)modifyBlock
                                               writeBack:(BOOL)needWriteBack
                                                complain:(BOOL)needComplains

这个方法是唯一去访问文件header的方法。

传入modifyBlock将改变header。

回到GC的过程中，可以看到通过传入modifyBlock来获取header。在modifyBlock中，通过header中的refcount来判断是否需要移除。

那么什么情况会触发refcount的变化呢？

在lockDataForKeys方法中，可以看到这样一行代码

1
2
3
4
5
6
 // Satisfy Req.#1.2
 if ([self isDataExpiredWithHeader:header]) {
 expired = YES;
 return;                                                                        }
++header->refCount;
// Do not update access time since file is locked

可知，当执行lock的时候，如果数据本身没过期，会使引用计数+1。

同理，当unlock的时候，会使引用计数-1。

可见，refcount只有1和0两个值。

而TTL（存活时间）则是数据的的生命周期。如果没有forceExpire和forceLocked的话，则当[self isDataExpiredWithHeader:header] && header->refCount == 0的时候删除数据。

总结

github上实现二进制缓存的cache库不多，SPTPersistentCache是其中的佼佼者。原因在于spotify本身做在线音乐服务，在二进制缓存上有比较强的需求。

SPTPersistentCache的实现我认为参考了HTTP协议，通过一个Header来为数据添加metedata，同时实现了GC。可以SPTPersistentCache的实现方式非常值得学习，在阅读SPTPersistentCache的过程中学习了不少二进制文件操作的方法，收益良多，也为这个系列开了一个好头。

展开全文 >>

2016，注定不平凡

2016年，注定是一个不一样的年份。年头到年尾，世界上发生了太多历史性的进程。一个英国脱欧，一个特朗普当选就足以让世人谈论上许多年。对于我个人，也是一个不同寻常的年份：今年我毕业了。

毕业了，我想谈谈教育

从上学第一天开始，我就想什么时候会结束这一段历程，想不到到来后却一点感觉没有。结束了学生身份，最大的感触就是：不再会有人照顾你了。

16年的求学经历，改变了一个人多少，每个人都会有自己的看法。在我看来，学生时代养成的习惯是永远改不掉的。很幸运的是，自己能够从小学一路顺利得读完大学。相比较许多无缘能够进入学校学习的人来说，能够接受完整系统的知识教育，是一件太幸福的事情。

在经历了完整的中国教育系统设计的教育体系后，感觉并没有网络以及他人所说的那么不堪。的确，中国某些体系原因造成了教育系统多变的情况，我也是几乎踏准了每次教育改革的门槛。但是我并不认为，这些改革最后改变了什么，甚至我不认为教授的内容会对人有什么影响。到目前为止，我认为，学校教育带给我最大的好处，就是学会系统逻辑的思考以及自学能力。

大多人批判中国教育为填鸭式教育。其实，在我看来，这只是一种迫不得已的手段。只有在严酷的训练下，才有悟的可能。绝不同于网络小说的主人公，我们不会在一天突然灵光一闪然后打通了任督二脉因此学贯中西。我们只能在不停地残酷的训练中总结，直到有一天明白知识的相通性。很遗憾的是，太多人麻木在重复高强度的训练中，只有少数人能够参透。我也是在大学最后，才明白过来，为时已晚。

教育，最大的目的是授人以渔。学会学习才是学习最大的目的。

读书，不是为了考试

上了大学后，除了少数的专业书籍，几乎怎么看书了。就这样浑浑噩噩过了两年，不仅专业并没有多大的提升，眼界和思维也是停滞不前。所幸的是这两年又捡回了读书的习惯。如果只依靠考试来鞭笞自己读书，恐怕也无法在未来走的更远吧。

在这里简单列下书单，也算推荐一些书籍

16年因为毕业，没能完成自己在年初定下的读书计划。17年不该再有借口。读书，应该是一辈子的事情。

技术

作为程序员，年终总结怎么能不写技术呢？不过，我不打算在这里写很多技术内容，只想谈谈对编程技术的一些思考。

编程技术，总的来说我认为也属于工程技术的一种，而且是属于门槛较低的部分。君不见满街40天培训Android，iOS，web月薪过万。然而，只有潮退了才知道谁在裸泳。16年的资本寒冬也影响到了炙手可热的互联网产业。一批批创业公司倒下使初级开发严重过剩。一个iOS岗位一周几百上千封简历不是夸张。作为一名刚毕业进入工作岗位的开发，说没有担心那是假的。究竟在几年后如何保持一定的竞争力？这些个一直在思考这些问题。

广义上的信息技术发展已经有几十个年头了，而新概念还在层出不穷。机器学习，AR,VR,大数据等等名字容易让新进行业的人头晕眼花。不能不承认，APP时代已经开始拉下帷幕了，未来究竟在哪，谁也给不出一个准确的答案。跟着行业走的技术也只能跟着行业的兴衰。作为技术，不能只着眼一处，保持学习，才能永远不被拉下。

17年，路在哪里

絮叨半天，发现自己的行文依旧这么烂（逃。年终总结，不就是应该给未来的自己避免踩上同一个坑吗。17年会怎么样，我不知道。但是我想我应该让自己知道17该怎么样。

读书依旧是不可少的，保持一个月一本的节奏。

技术上，本职上的iOS客户端开发要深挖下去，不能停留在表面的应用了。初次之外，学学数据处理分析相关的技术吧。

锻炼，16年的断断续续的，没能保持一定惯性。锻炼是最考验一个人意志力的行为。17年要保持，只有一个好身体才能应付一切。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

很惭愧<br><br>只做了一点微小的工作<br>谢谢大家