Singleton on Chen

Swift 中的消息派发

Sun, 15 Sep 2019 20:56:50 +0000

什么是消息派发？

消息派发，英文名称 Method Dispatch，是指程序在运行过程中调用某个方法的时候决议使用哪个具体指令的过程。消息派发的行为在我们代码中时时刻刻的在发生。了解消息派发的机制对于我们日常写出相对高效的代码也是有利的，日常 Coding 的时候遇到一些派发相关的问题，也能做到心里有数。

对于编译型语言来讲，有主要三种类型的方法派发方式：Direct Dispatch，Table Dispatch 以及 Message Dispatch，前者也被称作 Static Dispatch，后两个为 Dynamic Dispatch。

方法派发类型

本质上来讲，派发的目的就是告诉 CPU，在某个特定方法被调用的时候去内存的哪个地址去读执行代码。下面我们先了解下这三种类型的派发形式，这三种可以说各有优劣。

Direct Dispatch

直接派发也叫静态派发。它是这三种形式中最快速的，不仅仅是底层翻译的汇编指令少，也是因为编译器可以针对这种情况做更多优化的事情，比如说函数内联等。C 语言就是这种的典型代表，然而，对于日渐复杂的编程场景来说，静态派发限制非常大，我们必须在代码运行之前把事情安排的明明白白的，这个极大的限制了代码书写的灵活性。一句话总结，编译器在编译期间就已经确定了的推断路径，运行期间按照既定路线走就行。

Table Dispatch

函数表派发这种是编译型语言中最常见的动态派发实现形式，编译器层面使用一个表格结构来存储类型声明中的每一个函数指针。C++ 语言把这种表格称作虚函数表（virtual table，简称 V-Table），而在 Swift 中，针对拥有继承的 Class 类型来说，依然采用了 V-Table 这种实现形式达到对多态的支持，而针对值类型由于 Protocol 产生的多态而采用了另外一种函数表派发形式，这个表格被称为协议目击表（Protocol Witness Table，简称 PWT），这个暂时略去不表。

V-Table

对于 V-Table 的应用场景下，每一个类都会维护一个函数表，里面记录着该类所有的函数指针，主要包含：

由父类继承而来的方法执行地址；
如果子类覆写了父类方法的话，表格里面就会保存被重载之后的函数。
子类新添加的函数会插入到这个表格的末尾

在程序运行期间会根据这个表去查询真正要调用的函数是哪一个。这种特性就极大的提升了代码的灵活性，也是 Java，C++ 等语言得以支持多态这种语言特性的基石。当然，相对于静态派发而言，表格派发则多了很多的隐式花销，因为函数调用不再是直接调用了，而是需要通过先行查表的形式找到真实的函数指针来执行，编译器也无法再进行诸如 inline 等编译期优化了。

我们以 WWDC 的某个例子来大概说明下 V-Table 的具体派发过程，如下代码，共有三个 Class，其中 Drawable 是基类，子类化的 Point 和 Line。

Protocol Extension

Thu, 08 Aug 2019 19:00:20 +0800

Protocol 作为 Swift 生态的最重要的组成部分（没有之一），其搭建起了整个语言生态的各个组成部分。

相对于继承而言，Protocol 的几个比较直观的优势：

无需必须去强制继承某个类；
通过协议可以改造已经存在的类型；
适用范围更大一些，使得 struct 和 enum 这些值类型也能够继承能力
Swift 语言本身是不支持多继承的，你需要花费精力去纠结继承哪个 class，一旦出现不同的能力分散在不同父类的情况，就更加纠结了，你甚至需要去修改原有的父类；
继承的话，还需要考虑 override 父类方法的问题，比如调用 super 方法的时机问题；

这篇文章想记录下 Protocol Extension 中的一点区别。

我们知道 Swift Protocol 中是没有 optional 关键字的，因此只要是在 Protocol 定义的方法，即为 Protocol Requirements，符合该协议的类型就必须实现，否则是不完整的。比如，我们自己实现了 TableView，定义了这么多 delegate 协议方法，要求调用方全都提供，就太不人道了😢

因此，我们会通过对 Protocol 进行扩展，给该协议方法增加缺省实现，剩余的方法则是你需要调用方必须实现的方法。

如果针对某个协议 P，我们扩展 P 给其增加某个协议方法有两种形式：

直接在 Protocol 定义里定义新方法，该方法成为实现该协议必须实现的方法；
为 Protocol 增加扩展方法，该方法并不一定要求符合该协议的类型进行实现；

这两者有什么区别呢？我们看代码

发现 s 调用的是我们为 S 结构体增加的扩展方法，而 s2 调用的是 P 协议的扩展方法，尽管实体对象的动态类型是 S，但是因为声明的静态类型不一样，调用结果也不同。

对于 1 中的方法，运行时进行动态派发，也就是真实根据其具体类型来做决议，2 中的方法是进行静态派发，也就是说你声明的该对象是什么类型，就调用该类型的方法。以上述的代码为例，s1 的静态类型由编译器推导为 S，而 s2 的静态类型声明为 P ，因此二者在调用扩展协议方法时候的表现不一致。

在 Swift Framework 中使用 C 文件的过程探索

Thu, 03 Jan 2019 21:19:24 +0000

问题描述

我们在开发线上诊断工具需求的时候，是以单个 Pod 的形式提供支持，并且代码文件中只有纯 Swift 文件，但是其中需要用到系统的 C 库的一些功能，本次就是使用了系统 C 库中 resolv.h 这个文件来进行 DNS 解析所用。

当后期 Pod 功能完善之后，在 Example 工程中也已经编译通过之后，接入主项目中之后遇到了下面这个编译错误：

具体文字错误信息如下：

/Users/chen/Repos/Work/ZHDiagnosisTool/ZHDiagnosisTool/Classes/Core/Network/ZHDiagnosisTool-Network-Header.h:8:10:
 Include of non-modular header inside framework module 'Diagnosis.ZHDiagnosisTool_Network_Header': '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk/usr/include/resolv.h'

大概的意思就是在 Umbrella Header 中加入的 Bridging header 指定了 include 一个 C 文件，而该 C 文件本身并不是 Modular Header，因此编译无法通过。这就涉及了目前 iOS 生态中普遍使用的 Modules 概念。

几个概念

Modules

Modules 的概念是 XCode 5 带到 iOS 开发者面前的，从那时起 LLVM 编译器就已经内在支持了，具体关于其历史在 WWDC 2013 Session笔记 - Xcode5和ObjC新特性这篇文章中已经讲解的非常详细了，不再赘述，总结一句话就是：

如何制作 Send to 2Do 的 Safari 书签

Mon, 26 Nov 2018 14:59:50 +0000

使用鼠标拖拽下面这个链接到你的 Favorites Bar 上，默认点击行为实际上是模拟在当前页面进行导航，而目标地址由 avascript:window.location 来指定，目标地址实际上就是各个 App 的 URL Scheme。你可以在 AppTalk查看各个主流 App 的 URL Scheme。

2Do

Send to 2Do

然后编辑地址，将其替换为如下：

javascript:window.location='twodo://x-callback-url/add?task='+encodeURIComponent(document.title)+'&note='+encodeURIComponent(window.location)+'&action=url:'+encodeURIComponent(window.location)

所以，本质上是执行了一段 JS 代码，结合当前文档的上下文信息，调用 URL Scheme，其中

document.title 为标题
window.location 为当前页面链接

Things

我们知道 Things 的 URL Scheme 的规则如下：

/// add a todo due when tomorrow
things:///add?title=iamtitle&notes=iamnotes&when=tomorrow

Add a todo to Things

比如你可以把链接内容改为支持 Send To Things：

javascript:window.location='things:///add?title='+encodeURIComponent(document.title)+'&notes='+encodeURIComponent(window.location)+'&when=today'

OmniFocus

同理，可以有 Send To OmniFocus ，如下：

javascript:window.location='omnifocus:///add?note='+encodeURIComponent(window.location)+'&name='+encodeURIComponent(document.title)

Add a todo to OmniFocus

或者直接去 OmniFocus 页面用相同方式把起已经设置好正确 Value 的链接拖到上方工具条上即可。

阅读流程

Tue, 16 Oct 2018 17:01:44 +0000

最近统一了一下自己的阅读流程，更新一下，具体用到的工具有

DEVONThink Pro
PDFExpert
MarginNote

其中 1 是输入和归档源，3 是输出源。大概就是如下所示：

采集素材

在平时浏览网页的时候，看到自己喜欢的文章之后，想进行一些标记或者做笔记，大概有几个选择：

印象笔记直接 clip 当前网页，之后在印象笔记里进行阅读或者标记
放进稍后读服务中，比如 Pocket 或者 Instapaper 等；
用 Safari 自带的 Save as PDF 之后再用单独的 PDF 工具查看；

而最近几个月，因为 MarginNote 3 的发布，由于其提供的大纲脑图的自动生成，给我提供了一种便利的拆书功能，因此会把平时看到的文章都归集到一处来看。

借助 DEVONthink 的 Clip To DEVONthink 的插件可以很方便的把文章归集到 DEONThink 中，最主要的是因为它能保存 WebArchive，即使后续文章被删除也没关系。

当按下 Cmmd + S 进行归档之后，DEVONThink 对应 Group 里就会把该原始页面保存起来。

由于 WebArchive 无法做 Highlight 标记，这时候就用到了 DEVONthink 提供的 OCR 功能，将 WebArchive 提取为 PDF 文件。

三个简单步骤让你测试使用系统单例的代码

Tue, 17 Jul 2018 17:09:57 +0000

原文：Testing Swift code that uses system singletons in 3 easy steps

原作者 @johnsundell

大部分在 Apple 平台开发的 App 都会依赖基于单例的 API。从 UIScreen 到 UIApplication，再到 NSBundle，而 Foundation，UIKit 以及 AppKit 里到处充斥着静态的 API。

尽管单例非常方便，并且随时随地都可以很轻易的获取到特定的 API，但是当它们一旦要面临代码解耦和测试的时候就会出现挑战。单例同时也是平时遇到 Bug 里最常见的一种，在单例中状态会以共享的方式终结，那些针对状态做的变更并不能很好的广播到整个系统层面。

然而，尽管我们能够重构自己的代码，让它们只在真正需求的地方使用单例，我们针对系统 API 也做不了太多。但是，好消息是，这里有一些技巧让你使用系统单例的代码依然变得容易管理和测试。

让我们看一些使用了 URLSession.shared 单例的代码：

class DataLoader {
 enum Result {
 case data(Data)
 case error(Error)
 }

 func load(from url: URL, completionHandler: @escaping (Result) -> Void) {
 let task = URLSession.shared.dataTask(with: url) { (data, response, error) in
 if let error = error {
 return completionHandler(.error(error))
 }

 completionHandler(.data(data ?? Data()))
 }

 task.resume()
 }
}

上面这个 DataLoader 现在就变得很难测试，因为它内部会自主调用共享的 URL Session 来执行一个网络调用。这就需要我们为测试代码中增加一些等待和超时代码，然后很快这部分代码就会变得糟糕和不稳定。

抽象成一个协议

我们第一个任务就是把我们需要的 URLSession 的部分移到一个协议里，这样我们在测试中也能够很容易的进行 mock。在作者的一次 talk中作者建议尽可能的避免 mock，尽管它是一种很好的策略。但是当你和系统的单例打交道的时候，mock 就是一个增加可预测性的重要工具。

让我们创建一个 NetworkEngine 协议，然后让 URLSession 符合它:

避免在 Swift 中使用单例

Mon, 16 Jul 2018 17:34:36 +0000

原文：Avoiding singletons in Swift 原作者 & Copyright @johnsundell

“我知道单例不好，但是…”，这是开发者常常在讨论代码的时候会提到的。貌似社区大家有共识 ── 单例不好。但是同时，包括 Apple 和第三方的 Swift 开发者还是在 App 内部或者共享的 frameworks 里不断在用它们。

这周，让我们好好看一看单例的问题到底在哪里，探索更多的技巧以便我们日常能够避免使用它们。这就开始吧！

为什么单例这么流行？

首先一点我们要想的是问问自己，为什么单例这么流行？热过大多数开发者都认同，单例应该被避免的话，为什么它们还不断的出现呢？

我认为有两部分原因。

我觉得日常开发 Apple 平台上的 App 时候大量使用单例，最大的原因是苹果自己也在经常的用。作为第三方开发者来讲，我们常常会把 Apple 的做法作为最佳实践来用，任何 Apple 自己常常使用的模式在社区也会发展的很迅速。

这个谜题的第二个原因是单例非常方便。单例因为它可以在任何地方获取到，因而经常会扮演一个获取特定核心值或者对象的快捷方式。可以看下下面这个例子，在这个例子中，我们想在 ProfileViewController 中展示当前登录用户的名字，同时当某个按钮按下的时候，退登当前用户。

class ProfileViewController: UIViewController {
 private lazy var nameLabel = UILabel()
 override func viewDidLoad() {
 super.viewDidLoad()
 nameLabel.text = UserManager.shared.currentUser?.name
 }
 private func handleLogOutButtonTap() {
 UserManager.shared.logOut()
 }
}

按照上面这样，把一个 UserManager 单例的用户和账户处理的功能封装起来，确实很方便（而且很常见！），那这种模式的使用到底不好在哪里呢？

为什么单例会很糟糕？

当讨论类似模式和架构这些东西的时候，很容易陷入一个特别理论化的圈套。虽然让我们的代码理论上“正确”，遵循最佳实践和原则是很美好的，但是现实经常会很受打击，我们需要寻找一些中间方案。

所以，关于单例引起的实质性问题是什么呢？为什么它们要应该被避免呢？这里我倾向于三个原因：

这些单例是全局的可变的共享状态。它们的状态是在整个 App 里自动共享的，因此当其状态发生不可预期的变化的时候，Bug 也就可能开始发生了；
单例之间的关系以及依赖这些单例的代码常常不那么好定义。因为单例是如此方便和容易获得，大量的使用它们常常会导致很难维护面条式代码，这些代码中对象和对象之间没有清晰的隔离；
管理这些单例的生命周期非常的难。因为单例本身会在应用的整个生命周期内存活，管理它们就变得异常困难，因此常常会不得不依赖可选值来跟踪值的变化。这也使得依赖单例的代码变得很难测试，因为你没法在一个测试 case 里把状态重置。

在我们前面的 ProfileViewController 的例子中，我们已经看到了有这三个问题的信号出现。首先它依赖 UserManager 导致这二者关系很不清晰，其次，它不得不让 currentUser 作为可选值出现，因为我们没办法在编译期就能够确定视图控制器实际上出现的时候这个数据一定在。听起来就感觉要有 bug 发生的感觉 😬!

依赖注入

相对于使用 ProfileViewController 通过单例来获取它所需的依赖项，我们要在其初始化方法中将依赖项传入。这里我们是将当前的 User 作为非可选传入的，同样，传入一个 LogOutService 来进行登出操作：