Module on Chen

Alamofire 和 RxSwift 中的 .af 以及 .rx 扩展是怎么实现的

Sun, 29 Sep 2019 10:30:30 +0800

今天继续来一篇水文，关于 Alamofire 和 RxSwift 两个组件中扩展后缀 .af 以及 .rx 是怎么实现的。相信用过的 (￣ω￣(￣ω￣〃 (￣ω￣〃)ゝ都看过了。我这里权当自己的记录流水账了。

先来看 Alamofire 中关于 af 扩展的实现：

使用 Alamofire 扩展的方式如下：

struct Demo {}
extension Demo: AlamofireExtended {}
extension AlamofireExtension where ExtendedType == Demo {
 func printSomething() {
 print("Something arrived.")
 }
}
let d = Demo()
d.af.printSomething()

这里主要有两点：

为将要使用的类 Demo 扩展 AlamofireExtended 协议，也就是增加 af 扩展属性，其返回的是一个封装对象 AlamofireExtension；
为 AlamofireExtension 对象（1 中返回的封装类型）扩展专属于 Demo 这个类型的方法；

说实话，这里用来封装元类型信息的结构体名称和扩展协议名称一样，我初次看的时候确实是蒙的。相对于 Alamofire 的命名来说，个人更喜欢 RxSwift 的命名。

接下来是 RxSwift 中 Rx 扩展的实现：

可以看到，整个使用方式上是完全相同的。仅仅是各项名字不同。

所以我们可以总结这种方式的使用路径，如何为我们自己开发的组件扩充命名空间，具体有三个地方：

声明扩展属性

为了能够支持实例变量和类型两者，需要分别增加两个计算属性：

一个是 static 的，提供给类型使用；
一个是实例变量，提供给单个实例来用；

封装元类型信息

为了能够使得 .af/.rx 这些扩展属性也能够获得当前实例或者类型的元信息，不约而同的使用了结构体封装的形式，通过泛型类型实现。我们知道这个封装对象内部就是记录的就是 self

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 ，因此二者在调用扩展协议方法时候的表现不一致。

Codable && Tuple

Mon, 10 Jun 2019 23:50:54 +0800

While learning Swift, I keep finding interesting things. Codable is one of them.

Today, I defined a model with a tuple type, then Xcode gave me an error. The code might look like this:

You may want Xcode to automatically complete all the codable stuff. However, life is hard. Code like this cannot even be compiled. Xcode will tell you that it cannot synthesize Codable for Person because of FullName.

一道 Swift Quiz

Tue, 14 May 2019 16:01:54 +0800

这两天在 Twitter 上看到一道题目，主要是考察 overload 和 type(of:) 的知识点，本文仅做记录，关于 MetaType 会单独写一篇文章来总结。

// Swift Quiz

class View {}
class A: View {}
class B: View {}

func add(_ v: View) { print(type(of: v)) }
func add(_ v: A) { print(type(of: v)) }
func add(_ v: B) { print(type(of: v)) }

func build() -> View { return B() }
add(build())

// What is the output?
- "View"
- "A"
- "B"

答案的分布说明，大家对这个输出结果还是有一定的疑惑🤔

Mac 平台上那些 Dockless 的 App 都是如何实现的？

Wed, 13 Mar 2019 17:29:54 +0800

Menu Only 算是 Cocoa App 中最常见的一项，它使得 App 不占用你的 Dock 栏，在多 workspace 的时候也不影响正常使用，随时都可以在屏幕的菜单栏中执行快捷操作。尤其是针对一些需要便捷性要求比较高的应用来讲，Menu bar 的功能必不可少。本文就简单介绍一下关于 Menu App 中关键的几个开发步骤。

介绍

以 Shimo 这个 App 举例，

在其设置选项卡中能看到 Show Shimo in 的选项菜单，其中有三项：

Menubar only
Dock only
Menubar & Dock

这也是常见的 Cocoa 应用的模式支持，很多常见的 App 都支持，比如 DayOne，Dash，Todoist 等。

其实核心功能有两点：

可以显示或者隐藏 Dock 图标；
可以显示或者隐藏 Menu 菜单这两者的组合。

核心步骤

Dock

普通的 Cocoa Application 创建之后，默认都是 Dock 上展示的，如果想隐藏 Dock 图标，首先它需要有这个能力，这个能力是通过 info.plist 文件中的 Key 来指定的，这个 Key 就是 LSUIElement，我们将其值设置为 true

为 NSView 增加 backgroundColor

Mon, 11 Mar 2019 15:19:49 +0800

NSView 作为 Cocoa 中最基本的构成元素，是构成整个 Mac App 视图体系的基础，和 UIView 在 iOS 世界中的位置一样重要，可是在 UIView 里司空见惯的背景色设置，在 NSView 中却不见身影。

在 iOS 中，设置 UIView 的背景色很简单。

import UIKit

let frame = CGRect(origin: .zero, size: CGSize(width: 100, height: 100))
let view = UIView(frame: frame)

view.backgroundColor = .blue

而在 macOS 上，使用 NSView 背景色需要如下设置：

import Cocoa

let frame = CGRect(origin: .zero, size: CGSize(width: 100, height: 100))
let view = NSView(frame: frame)

view.wantsLayer = true
view.layer?.backgroundColor = NSColor.blue.cgColor

UIView 自身有一个 backgroundColor 的属性，而在 NSView 中是没有的，你需要做的是设置 View 所包含的 layer 的背景色。而且 layer 是 Optional 的，也就意味着 NSView 默认是不包含 layer 的，所以你还需要设置 wantsLayer 为 true 让 NSView 创建 layer 出来。

在 Apple 的官方文档有针对 wantsLayer 的一些说明

RxSwift 中的几种 Subject

Tue, 26 Feb 2019 10:24:38 +0800

文中所用插图均出自书籍《RxSwift - Reactive Programming with Swift》

Subject 在 Rx 的世界里是这么一种存在，其既可以作为观测者，也可以作为被观测者。自然而然想到的是 Subject 本身就可以作为一种过渡桥接信号的手段，它订阅某个信号，一旦信号收到序列，转头它就又把信号散发给自己的观测者了。

在 RxSwift 的世界里涉及几种 Subject，这里先行做个记录：

PublishSubject
BehaviorSubject
ReplaySubject
Variable （预计在 5.0 废弃）

PublishSubject

PublishSubject 只给订阅者发送新元素，也就是订阅者只能接受到订阅之后发出的信号。一图胜千言，看👇

其中第一排是某个作为 Observable 角色的 Subject，自左至右为严格时间线， 2 和 3 排均为订阅了该 Subject 的观测者，向上的虚线表明订阅的时机，可以看到观测者只能接收到订阅之后由 Subject 新发射出的信号。

BehaviorSubject

BehaviorSubject 会在订阅者订阅之后发送最新的一个信号元素，自然需要你在初始化该对象的时候给其设定初始化值（否则对于第一次订阅的观测者来说，哪来的最新发射的元素呢？）。如果初始化的时候无法提供默认值，那可能你就需要用到上面的 PublishSubject 了。其中常用的 Variable 和 BehaviorRelay 都是对其的封装。

从图中可以看到和上方 Publish 区别的是其在观测者订阅之后会收到最新的最后一个信号。

ReplaySubject

顾名思义，ReplaySubject 会重新发射在订阅者订阅之间发出的信号，具体发多少是由 bufferSize 决定的，其指定需要 cache 多少个信号，如下图中所示，Buffer Size 为 2，因此当第二个订阅者订阅 Subject 之后，其会收到最新的 1 和 2 两个信号。

/// 指定发射多少最新信号
let subject = ReplaySubject<String>.create(bufferSize: 2)

Apple Event Sandboxing

Thu, 21 Feb 2019 23:25:38 +0800

问题背景

最近在修改某个 Mac 应用，其原理就是通过执行一段 AppleScript 获取 OmniFocus 的信息，然后进行可视化展示，但是总取不到数据。

原因

关键数据获取阶段执行的 AppleScript 的时候总是取不到数据。

set theProgressDetail to ""

tell application "OmniFocus"
 tell front document
 set theModifiedProjects to every flattened project
 repeat with a from 1 to length of theModifiedProjects
 set theCompletedTasks to (every flattened task of (item a of theModifiedProjects) where its number of tasks = 0)
 if theCompletedTasks is not equal to {} then
 repeat with b from 1 to length of theCompletedTasks
 set theProgressDetail to theProgressDetail & completion date of (item b of theCompletedTasks) & return
 end repeat
 end if
 end repeat

 set theInboxCompletedTasks to (every inbox task where its number of tasks = 0)

 repeat with d from 1 to length of theInboxCompletedTasks
 set theProgressDetail to theProgressDetail & completion date of (item d of theInboxCompletedTasks) & return
 end repeat
 end tell
end tell

display dialog theProgressDetail

return theProgressDetail

在 Cocoa 中是通过执行如下代码执行：

let myAppleScript = "I am a piece of applescript"
if let scriptObject = NSAppleScript(source: myAppleScript) {
 var error: NSDictionary?
 let output = scriptObject.executeAndReturnError(&error)
}

进行 Debug 启动 App 或者 Archive 安装包执行可执行文件，均无法正常获取执行结果，直接报错。具体错误原因：

"NSAppleScriptErrorMessage" : "Not authorized to send Apple events to OmniFocus."

很显然，没有权限执行该脚本来发送 Apple Event 给 OmniFocus 从而执行对应操作。

关于一次 SS 流量丢失的过程记录

Mon, 28 Jan 2019 17:51:35 +0000

2019-01-29 更新

早上一到办公室连接上公司网络，网速直接就飚到了 600KB/s，果不其然，还是 com.apple.Safari.SafeBrowsing.Service 这个服务进程。这就尴尬了，看来并不是说你不用 Safari 就不会触发。

直接把 Surge 规则中的 Rule 由 Direct 改成了 Reject。

问题追踪

在 2018 年 12 月底的时候，偶然间登录 AgentNEO 查看刚买的流量使用情况。但是发现，刚在前几天购买的 SS 流量在短短的 4 天之内就耗了将近 95GB，就在 1 月 1 日元旦当天就耗了接近 75GB，要知道，我平时的月均流量也就维持在 10 GB 不到，毕竟平时在公司办公，业余时间 Youtube 也看的相对少。

在最初看到这个统计数据之后，我一度怀疑是他们网站的流量统计有问题。

后续几天，我实际上对流量耗损比较关注，有一天注意到，Surge 的流量监控速率一直持续不断的显示达五六百 KB/s 的下载流量，但是我知道自己当时并没有下载任何东西。

打开 Surge Dashboard，看到如下的情形：

可以看到当时在持续不断的进行下载动作的进程名称是 com.apple.Safari.SafeBrowsing.Service，看请求地址是 safebrowsing.googleapis.com。

从进程名字来看应该是 Safari 和安全流量相关的服务，通过 Snitch 的数据库查到对其的说明：

Safari has built-in support for Google’s Safe Browsing service to identify fraudulent and unsafe websites. Right before Safari navigates to a certain website, the website gets checked for possible security concerns using Google’s Safe Browsing online database. Accessing the online database requires connections to Google servers.

在 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新特性这篇文章中已经讲解的非常详细了，不再赘述，总结一句话就是：