IOS on Chen

Stash 有了新主页

Thu, 08 Oct 2026 11:42:00 -0700

Stash 的新网站已上线，先看看这款正在开发中的应用如何收好复制的内容、提取有用的片段。

Keeps 1.4.3 已提交审核：切换货币后的滚动更流畅

Thu, 08 Oct 2026 11:00:00 -0700

Keeps 1.4.3（112）已提交 App Review，改善切换货币后的滚动性能，并修复物品详情和打孔日历的布局。

Keeps 1.4.0：每次使用，都有价值

Thu, 01 Oct 2026 12:00:00 -0700

Keeps 1.4.0 带来纸质价格标签、打孔卡目标、照片展示方式、改进的搜索和自动备份，支持 iPhone、iPad 和 Mac。

让物品在 Keeps 里自己记一笔

Sat, 26 Sep 2026 00:00:00 -0700

三条快捷指令自动化，不用打开 Keeps 就能记录一次使用：打开某个 App、水杯上的 NFC 标签、汽车蓝牙连接。

LiftCoach 适配 iPhone Duo

Fri, 25 Sep 2026 16:30:00 -0700

抢先看 LiftCoach 在 iPhone Duo 上的样子：展开后分成两页，半折后上半部分变成训练凳旁的一块屏幕，控件放进侧边栏，实时活动也适配了新的灵动岛。

LiftCoach 已上架 App Store

Wed, 23 Sep 2026 09:00:00 -0700

LiftCoach 1.0.0 已上架，支持 iPhone、iPad 和 Apple Watch。规划力量训练计划，记录每一组，看清训练的积累。

Keeps 已上架 App Store

Sun, 20 Sep 2026 00:00:00 -0700

Keeps 1.4.0 已在 iPhone、iPad 和 Mac 上架，带来纸质价签、打孔目标卡、六种主题，并可免费记录最多 30 件物品。

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"

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

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

UserDefaults and Keychain

Fri, 21 Dec 2018 14:30:50 +0000

Apple 提供了几种持久化方案，其中 UserDefaults 和 Keychain 是 App 开发过程中使用频率最高的方案，而且从以往和同事的探讨过程中发现对这两个概念中有一些细节还是理解不太透彻，因此本文会针对这二者展开讲一讲。

UserDefaults

首先，阅读完 Apple 关于 UserDefaults 一节的文档描述之后，我觉得有两个需要注意的点：

UserDefaults 的构成
UserDefaults 的目的

UserDefaults 构成

我们可以看看具体 UserDefaults 存储的地方，如下图，我们在应用中写入 Demo 数据：

打印 Library 路径，在 Finder 中打开路径:

如下展示内容，可以看到在 Preferences 目录中存在某个文件，例如该 App Library 目录下存放的文件为 app.chen.ios.PersistenceDemo.plist

该 plist 内容如图所示，即为我们之前在 App 中写入的 Key-Value。

所以这也证明了，我们针对 UserDefaults 的读写实质上是针对 plist 文件的读写。

iOS 系统会自动帮你做 plist 文件的读入以及 Cache，根据情况会把你在内存中所做的操作同步到 plist 文件（UserDefaults 同步到内存是同步的，同步到 Database 是异步的， iOS 8 开始，会有一个常驻进程 cfprefsd 来负责同步）。

如何制作 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 来进行登出操作：

Swift 中几种不同的依赖注入方式

Mon, 16 Jul 2018 13:57:24 +0000

原文：Different flavors of dependency injection in Swift

原作者 & Copyright @johnsundell

在之前的几篇博客中，我们已经了解了几种使用依赖注入方式使得某个 swift app 拥有一个更加解耦可测试的架构。比如在在 Swift 中使用工厂模式进行依赖注入中和工厂模式结合，以及在避免在 Swift 中使用单例中替换程序中的单例对象等方式进行依赖注入。

到目前为止，大部分我的博文以及例子中都使用了基于初始化的依赖注入方式。然而，就像大部分的编程技巧一样，还有很多 “口味” 的进行依赖注入的方式 ── 每一种都有其优缺点。这周，让我们来看看其中三种方式以及如何在 Swift 中使用它们。

基于初始化方法

让我们快速回顾一下用的最为广泛的依赖注入方式 ── initializer-based。这个想法是在某个类被初始化的时候传入其所需的依赖的方式。这种形式最大的好处就是，它保证了能够立即满足该类完成其功能所需要的所有东西。

让我们建一个类 ── FileLoader 来从磁盘加载文件。为了实现该 Loader 的功能，需要两个依赖项，系统所提供的实例对象 ── FileManager 和 Cache。使用基于初始化的依赖注入的执行代码如下所示：

class FileLoader {
 private let fileManager: FileManager
 private let cache: Cache

 init(fileManager: FileManager = .default,
 cache: Cache = .init()) {
 self.fileManager = fileManager
 self.cache = cache
 }
}

可以关注下初始化方法里默认参数的设置，其可以避免每次都需要自行创建的问题。这样能够简化我们在生产环境下使用 FileLoader 类创建文件加载器的工作，而且也能够能够传入 mock 数据或者我们的测试代码中的创建的实例进行测试。

基于属性

虽然前一种基于初始化的依赖注入形式常常给我们自定义类带来很多好处，但是有时候，当你不得不继承自某个系统类的时候会遇到一些困难。其中一个例子就是，当我们构建 view controller，尤其是你在使用 XIB 以及 Storyboard 类定义它们的时候，因为此时你不再能够掌控它们的初始化方法了。

对于这些情况，基于属性的依赖注入方式是一个更好的选择。相对于初始化的时候进行对象的依赖项注入，基于属性的形式可以在之后通过简单的赋值来做到，其能够让你减少模板代码的书写，尤其是在你确实没有必要进行注入的时候能够有更好的默认实现。

让我们再来看一个例子，在这个例子中，我们在构建一个 PhotoEditorViewController ，这个视图控制器使得用户编辑它们照片库中的图片。为了达到这个功能，该视图控制器需要用到系统提供的 PHPhotoLibrary 类型的一个实例（该类本身是一个单例）以及我们自己实现的类 PhotoEditorEngine 的一个实例。那为了不通过自定义初始化方法进行依赖注入的话，我们可以创建一些具有默认值的可变属性，例如下面这样：

那些我恢复 Mac 系统之后要安装的 Apps

Wed, 11 Jul 2018 12:58:37 +0000

记录一下自己常用的 Mac Apps，每次重装之后到了用的时候发现忘记安装了(不是每次都用 TimeMachine 恢复)，而且强烈简易大家如果某个 App 有对应的独立安装版本的话，购买其独立安装版本为好，沙盒环境以及和 Apple ID 绑定的特性就使得功能性以及灵活度大减。

更新时间 2018-10-07 更换图床，更新图片

更新时间 2018-08-10 不久前，已经订阅了一年的 Setapp，发现上面好多 App 自己都之前买过了，Sigh！如果你使用 Ulysses 或者 MoneyWiz 3.0 的话，订阅 Setapp 就会非常的值得！

办公工具

离开这些工具，貌似无法办公的。

AirMail

下载地址

邮箱客户端，看中 AirMail 主要是因为其强大的第三方服务集成。

Slack

下载地址

公司的日常沟通交流主要战场，其实整个操作体验我是不太适应的，不过它强大在第三方服务的集成上，可以做很多自动化的事情。

Fantastical 2

下载地址

日历工具，查看满满的一屏幕日程，你会感觉很舒服的。

Tunnelblick

下载地址

公司需要使用该 App 来接入办公室网络。远程办公必备。

Office 三件套

微软的 Office 三件套，Word，Excel，PowerPoint。用的频率不高，但是用的时候得有。

GTD

日常 GTD 工具，基本就是各家评测常提起的几款 App。

2Do

下载地址

最近才完全转向 2Do，这个 GTD 工具是我最早买入的，但是后来因为其自动化太弱，被打入冷宫。最近几个月又开始捡起来了，吸引我的几个点：

What is LLVM

Tue, 10 Jul 2018 12:05:58 +0000

什么是 LLVM？隐藏在 Swift，Rust，Clang 等语言背后的奥秘

了解编译器是如何生成机器原生代码会使得倒腾新语言或者加强已经存在的编程语言变得比以往更加容易了。

新的编程语言，针对现存语言的优化如同雨后春笋般产生。 Mozilla 的 Rust， Apple 的 Swift，JetBrain 的 Kotlin等语言给开发者提供了在速度，安全性，便捷性，可移植性以及性能等方面更多的选择。

为什么是这个时间点呢？一个重大的原因是那些构建具体语言相关的新式工具的出现。在这一堆工具中，最重要的就是 LLVM，其全称是 Low-Level Virtual Machine，它是一个开源项目，其最早是由 Swift 语言的发明人 Chris Lattner 在伊利诺斯州州立大学期间的一个研究项目而来。

LLVM 不仅仅使得创建新式语言更加容易，也使得针对现存编程语言进行增强完善更加便捷。它提供了一堆工具使得创造语言的过程中需要的那些令人头疼的事情变得自动化：创建一个编译器，输出代码需要适配多平台和架构，编写代码处理语言当中通常都存在的那些比较晦涩的部分，比如异常。LLVM 的自由开发许可使得它可以被自由的作为一个软件组件或者被部署成服务来使用。

使用了 LLVM 的编程语言花名册种有很多熟悉的名字。Apple 的 Swift 语言使用 LLVM 作为其编译器框架，Rust 语言使用 LLVM 作为其工具链中的一个核心组件。同样，许多编译器也有其 LLVM 版本，例如 Clang，一个 C/C++ 编译器，它是和 LLVM 功能特别相近的一个项目。还有 Kotlin 语言，其名义上是一门 JVM 语言，也正在开发该语言的一个版本： Kotlin Native，其使用 LLVM 编译成机器原生代码。

LLVM 是什么

LLVM 最核心的功能就是，可以通过编码方式创造机器原生代码。一个开发者可以使用其 API 创造指令，该指令是一种 intermediate representation 格式，简称 IR。之后，LLVM 能够将 IR 编译成独立的二进制文件，或者对其执行即时编译以运行在另外一个程序，例如某编程语言的解释器的上下文中。

很多编程语言中很常见的结构体或者模式，LLVM 的 API 都提供了原始语义的支持。例如，几乎所有的语言都有函数或者全局变量的概念，LLVM 在其 IR 中把函数和全局变量作为独立元素定义出来，因此你不需要花太多时间和精力来重复造这些特定的轮子，你只需要使用 LLVM 的实现，专注于你的语言最需要关注的地方即可。

In App Purchase

Thu, 24 May 2018 10:40:39 +0000

对于在 App Store 中上架的应⽤来说，应⽤内购买(In-App Purchase，简称 IAP) 应该是一个避不开的话题，尤其是去年微信打赏和 Apple 之间的争执更让 IAP 火了一把，不仅仅大公司，作为个人开发者来讲，IAP 也是非常重要的，说不定就是你养家糊口的工具呢。

整个 IAP 的过程，在客户端的实现依赖于 StoreKit 这个框架，所有的支付相关操作都是交由 StoreKit 来完成的。

首先，我们先复习一下 IAP 的整个流程。

In App Purchase 的整体流程

阶段 1

加载 In-App Identifier
客户端从 AppStore 中获取本地化的商品信息。
把 IAP 的购买界⾯面展示给⽤用户，⽤用户可以同意购买并点击购买按钮。
⽤用户授权购买，客户端向服务器器发送购买请求。
服务器器处理理购买请求，并把结果返回给 StoreKit。
如果购买请求验证通过，客户端此时解锁内容或者提供金币。
至此，整个交易易流程结束。

阶段 2

具体到和 Apple Store 打交道的话，如下所示：

阶段 3

如果涉及到自己 App 端 Server 的参与，基本如下图所示：

正常多出的几步：

获取 Product 标识列表；
客户端上传 Receipt 数据给 Server，Server 自行校验或者使用 Apple 的接口校验；
Server 端告知给客户端付费内容

注册商品

商品注册是通过 iTunes Connect 后台进行的，其中商品类型需要提前明确好。

模块化 Xcode 工程

Sun, 19 Nov 2017 18:17:15 +0000

原文：Modular Xcode projects

原作者 & Copyright @pepibumur

翻译：@OgreMergO

使用 Xcode 构建模块化的工程就需要对工程结构以及其基础概念有很好的理解才行。

我们平时不怎么关注工程结构本身，只有在工程逐渐变大，要添加更多依赖的时候才会注意的到。而即使到了这个时候，我们大多数的工程都会使用 CocoaPods 来设置那些依赖项，或者 Carthage, 后者虽然没有帮我们做依赖性的设置，但是使得我们会更容易的，通过在工程的 build phase 选项中添加一些内容，达到同样的目的。当配置项越来越复杂，我们就很容易产生困惑，这是因为我们并没有完全掌握 Xcode 工程中所涉及的所有元素。我经常被问到的问题如下：

我能不能在工程里同时使用 Carthage，Cocoapods 以及自己个人的依赖设置？
我添加了依赖，但是当模拟器打开 App 的时候 Crash 了。
为什么我需要只在某些 targets 里嵌入 framework？
我的 framework 应该是静态的还是动态的？

在这篇博文中，我会引导你遍历 Xcode Project 中的各个元素，指导你如何通过改变这些元素来模块化你的设置项。我希望下次你遇到上面这些问题的时候，你不需要再花大量时间取 Stack Overflow 上查这些确定的答案。

Elements ⚒

Target

工程（Projects）都是由多个更小的叫做 target 的单元组成的。这些 target 包含编译特定平台产品，比如 frameworks, libraries, apps, testing bundles, extensions 等所需要的配置。你可以在这里看到 target 所有可用的类型。 Target 可以相互依赖，当一个 target A 依赖另外一个 target B 的时候，target B 就会被先构建出来以便 target A 使用其产出。而 target 的配置项会涉及以下几个地方：

在 Swift 中使用工厂模式进行依赖注入

Sun, 19 Nov 2017 18:17:15 +0000

原文：Dependency injection using factories in Swift

原作者 & Copyright @johnsundell

依赖注入是一项使得代码更加可测试的关键工具。我们不需要持有某些对象，或者创建这些对象的自有依赖，或者通过单例来获取他们，而是尽可能使那些对象能够正常运转所必须的一切内容（其他对象）通过外界传入，这样做的好处在于，一方面能清晰的看得到某个对象的所有依赖项，另一方便也使得测试工作变得更为简单（因为我们可以模拟这些依赖项来捕获、验证状态以及值。）

然而，尽管依赖注入确实很有用，但是当在工程中广泛使用的时候还是会有一些痛点。随着某个对象的依赖项越来越多，初始化该对象就变得越来越蹩脚。虽然使得代码可测没毛病，但是如果像下面这种每次需要这样来写初始化方法，也太不爽了。

class UserManager {
 init(dataLoader: DataLoader, database: Database, cache: Cache,
 keychain: Keychain, tokenManager: TokenManager) {
 // ...
 }
}

所以，这周咱们来深入了解一下某种依赖注入的技巧，使得我们的代码不失去可测性，我们也不需要再强迫自己去写一团初始化方法或者复杂的依赖管理的代码。

传递依赖项

我们遇到上面代码 demo 中的问题，最主要的原因是我们需要把这么多依赖项传递给某个对象，以便之后来使用。举例来说，我们在构建一个消息收发的 App，这里有一个 view controller 需要展示某个用户所有的消息：

class MessageListViewController: UITableViewController {
 private let loader: MessageLoader

 init(loader: MessageLoader) {
 self.loader = loader
 super.init(nibName: nil, bundle: nil)
 }

 override func viewWillAppear(_ animated: Bool) {
 super.viewWillAppear(animated)

 loader.load { [weak self]() messages in
 self?.reloadTableView(with: messages)
 }
 }
}

如上代码能看到，我们给 MessageListViewController 传入某个依赖项 MessageLoader，之后其被用来加载数据。这里其实并没有太大的问题，因为仅仅只有一个依赖而已。然而，我们的列表视图并不是一个死气沉沉的展示而已，某些状态下还需要们进行导航到某视图控制器的工作。

处理 Swift 中非可选的可选值类型

Tue, 14 Nov 2017 21:53:52 +0000

原文：Handling non-optional optionals in Swift 原作者 & Copyright @johnsundell

可选值（optionals）无可争议的是 swift 语言中最重要的特性之一，也是和其他语言，例如 Objective-C 的最大区别。通过强制处理那些有可能出现 nil 的地方，我们就能写出更有预测性的以及更健壮的代码。

然而，有些时候可选值可能会致你于尴尬的境地，尤其是你作为开发者了解（甚至是有些猜测的成分在），有的特定变量始终是非空（non-nil）的，即使它是一个可选类型。例如，我们在一个视图控制器中处理视图的时候：

class TableViewController: UIViewController {
 var tableView: UITableView?

 override func viewDidLoad() {
 super.viewDidLoad()
 tableView = UITableView(frame: view.bounds)
 view.addSubview(tableView!)
 }

 func viewModelDidUpdate(_ viewModel: ViewModel) {
 tableView?.reloadData()
 }
}

这也是对于很多 Swift 程序员争论比较激烈的地方，程度不亚于讨论 tabs 和 spaces 的用法。有的人会说：

既然它是一个可选值，你就应该时刻使用 if let 或者 guard let 的方式进行解包。

然而另外一些人则采用完全相反，说：

既然你知道这个变量在使用的时候不会为 nil，使用 ! 强制解包多好。崩溃也要比让你的程序处于一个未知状态要好吧。

本质上来讲，我们这里讨论的是要不要采用防御性编程（defensive programming）的问题。我们是试图让程序从一个未知状态恢复还是简单的放弃，然后让它崩溃掉？

如果非得让我对这个问题给出一个答案的话，我更倾向于后者。未知状态真的很难追踪 bug，会导致执行很多不想执行的逻辑，采用防御性编程就会使得你的代码很难追踪，出现问题很难追踪。

但是，我不太喜欢给出一个二选一的答案。相反，我们可以寻找一些技术手法，用更精妙的方式的解决上面提到的问题。

它真的可选的吗？

那些可选类型的，但是被代码逻辑真实需要的变量和属性，实际上是架构瑕疵的一个体现。如果在某些地方确实需要它，但是它又不在，就会使得你的代码逻辑处于未知状态，那么它就不应该是可选类型的。

当然，在某些特定场景下，可选值确实很难避免（尤其是和特定的系统 API 交互的时候），那对于大部分这种情况，我们有一些技术来处理从而避免可选值。

lazy 要比非可选的可选值更好

某些属性的值需要在其父类创建之后再生成（比如视图控制器中的那些视图，应该在 loadView()或者 viewDidLoad()方法中被创建），对于这种属性要避免其可选类型的方法就是使用 lazy 属性。一个lazy属性是可以是非可选类型的，同时也不在其父类的初始化方法里被需要，它会在其第一次被获取的时候创建出来。

让我们改一下上面的代码，使用 lazy 来改造 tableView 属性：

理解响应者和响应链

Mon, 13 Nov 2017 21:22:44 +0000

Apps 是通过响应者（responder）对象来接收和处理事件的。一个响应者对象是 UIResponder 类的一个实例，我们常见的 UIView，UIViewController 以及 UIApplication 都是 UIResponder 的子类。 UIKit 自动帮你管理着这些 responder 相关的行为，包括事件是如何从一个 responder 传递给另一个 responder 的等等。当然，你也可以修改你的 app 中事件传递的默认行为。

UIKit 会把大部分的事件都传递给最适合的 responder 对象来处理。如果该 responder 无法处理该事件，UIKit 就会继续把该事件沿着当前的响应者链传递到下一个 responder。响应者链就是你的 App 中所有响应者的动态配置，也因为其是动态的，你的 App 中不可能只存在单一的响应者链。由于事件总是从特定的响应者那里流转到更通用的响应者那里，因此很容易确定某响应者链中下一个响应者是谁。举个例子，一个 view 的下一个响应者是其 superview 或者负责管理它的 view controller。事件就是这样在响应者链中传递直到其被处理掉。

下图展示了一个界面中包含了一个 Label，一个 TextField，一个 Button 以及两个容器 view 的 App 中响应链是什么样子的。如果 TextField 不处理某个事件，UIKit 就会把该事件发送给 TextField 的父级 UIView 对象，同样的，如果该对象依然处理不了，就会传递给该 view 对象的 window。如果 window 对象也依然无法处理该事件，UIKit 最终会把该事件传递给 UIApplication 对象，一般上该 UIApplication 对象是 App 的 delegate 对象并且是 UIResponder 实例，当然这个时候已经脱离了响应者链了。

Capturing objects in Swift closures

Sun, 12 Nov 2017 20:56:50 +0000

原文：Capturing objects in Swift closures 原作者 @johnsundell

自从 Block 在 iOS4 被引入 Objective-C 的世界之后就成为了 Apple 各平台上最时髦的 API 的重要组成部分了。当 Swift 语言出现的时候，blocks 的概念就摇身一变通过 closure 的形式引入，成为了目前我们可能每一天都在用的语言特性之一了。

Closure 目前已经被我们广泛的使用了，即使如此，我们在使用它的时候还是需要有很多需要注意的点，并且需要做很多额外的操作。这篇文章，我们来近距离的了解 closure，主要是了解其捕获变量的机制以及那些能够更好的让我们来处理变量捕获的技术。

伟大的 escape

Closure 有两种类型：escaping 和 non-escaping。当一个 closure 是 escaping（使用 @escaping 修饰闭包参数）的，也就意味着其会被以各种形式存储下来（无论是通过 property 还是被其他 closure 捕获）。相反，Non-Escaping 的　closure 意味着其不能被存储，而且在使用它的地方就必须直接被执行。

译者注：可以参见《@autoclosure && @escape》一文。

一个显而易见的例子就是当你在一个集合类型上使用函数式操作的时候，例如 forEach：

[1, 2, 3].forEach { number in
 ...
}

如上代码所示，closure 都直接作用于集合的每一个元素上，也就无需把该闭包变为 escaping 的。

而 escaping 的 closures 最常见的就是在那些异步 API 中，例如 DispatchQueue。例如，当你异步执行某 closure 的时候，这个 closure 就会 escape。

@autoclosure && @escape

Sun, 12 Nov 2017 20:01:54 +0000

我们知道在 swift 中，闭包（closure）是一等公民，因此可以被当作参数传递，在学习 swift 的过程中经常会看到某些关键字修饰该闭包，@autoclosure， @escape 就是其中比较常见的两种关键字。

@escape 和 @nonescape

当一个闭包被当作参数传递给一个函数，但是当该函数内容执行完毕返回之后，该闭包才会被执行，我们就称该闭包要 escape 某个函数，那 @escape 关键字就是用来表示该闭包是允许在函数返回之后被调用的。

我们用 swift 官方文档的例子来看，如下所示

var completionHandlers: [() -> Void] = []

func someFunctionWithEscapingClosure(completionHandler: @escaping () -> Void) {
 completionHandlers.append(completionHandler)
}

someFunctionWithEscapingClosure(_:) 的参数是一个闭包，函数内部会把传入的闭包存到之前声明的数组里以便之后进行调用，可以看到，在函数参数的声明部分添加了 @escaping 关键字，如果这里不添加的话，就会在编译的时候报错：

error: passing non-escaping parameter 'completionHandler' to function expecting an @escaping closure
 completionHandlers.append(completionHandler)

针对标记了 @escaping 关键字含义代表你必须在该闭包内部显式的使用 self 关键字，官方文档中又列举了另外一个例子，如下所示：

func someFunctionWithNonescapingClosure(closure: () -> Void) {
 closure()
}

class SomeClass {
 var x = 10
 func doSomething() {
 someFunctionWithEscapingClosure { self.x = 100 }
 someFunctionWithNonescapingClosure { x = 200 }
 }
}

let instance = SomeClass()
instance.doSomething()
print(instance.x)
// Prints "200"

completionHandlers.first?()
print(instance.x)
// Prints "100”

someFunctionWithEscapingClosure(_:) 是一个可逃逸的闭包，意味着你需要显示的调用 self 关键字，而 someFunctionWithNonescapingClosure(_:) 是非逃逸的闭包，意味着你可以隐式的调用 self。

关于 iOS10 Notification 的那些事儿

Sat, 20 May 2017 10:10:54 +0000

概览

推送通知我们大家都不陌生，可以说几乎每个使用智能手机的人每天都会被不同的通知打扰到，正式因为合适的推送是吸引用户注意力的利器，其成为了各 App 吸引用户，将用户带回到 App 本身，提升用户的活跃度的一种必要的方式。

当然，过度的推送本身则是一件对用户影响特别大的事情，毕竟注意力被打断，因此合适的推送时机也是各个 App 开发者所要注意的，否则他的 App 就会成为用户勿扰名单里的一员了。

之前刚开始学习 iOS 开发的时候还整理了下当时部署 iOS 远程推送的流程，详见：iOS 远端推送部署详解

接下来，我们大致回顾一下 iOS 平台关于推送都有哪些历程？

历史

<= iOS 6
- 远程推送通知（iOS 3）
- 本地通知（iOS 4）
iOS 7 参考
- 引入 Silent Remote Notifications
iOS 8 参考 WWDC 2014 Session 713
- 引入 Actionable Notifications
- 修改 Notification 的权限请求
iOS 9 参考 WWDC 2015 Session 720
- 引入 Text Input Action
- UIUserNotificationActionBehavior
iOS 10 参考 WWDC 707 Introduction to Notifications && WWDC 708 Advanced Notifications

如何使用UIBezierPath实现一个弹性视图动画

Wed, 02 Dec 2015 18:53:51 +0000

原文：Elastic view animation, or how I built DGElasticPullToRefresh 原作者 @gontovnik

DGElasticPullToRefresh 展示了如何实现一个弹性效果。效果如下图所示：

开发环境： Xcode 7 Swift 2.0

要求：开发者至少对 UIBezierPath 和 UIGestureRecognizer 有一定的了解.

理解业务逻辑

你可能从上面的效果图上可以看到一些端倪，这个动画中我们主要使用到了UIBezierPath来实现上面这种效果。我们首先创建一个贝塞尔曲线路径的CAShapeLayer，然后当你的手指在屏幕上移动的时候我们将移动所有的控制点来呈现动画。每一个控制点会使用一个可见的UIView来表示。下面有几张图来演示它们是如何工作的，我将所有的控制点标识成了红色：

第二章图片中将每个表示控制点的 View 的变量名称标记出来了，如L3，L2等。

当你的手指释放的时候，我们就播放Spring动画，让所有的控制点向其初始位置以一定的回弹效果移动。当所有的视图在动画播放过程中，我们需要时刻计算并我们的贝塞尔曲线（每一帧都进行计算）。因此，我们准备使用CADisplayLink，CADisplayLink在主循环中运行而且每一帧都会去执行指定的方法。

A CADisplayLink object is a timer object that allows your application to synchronize its drawing to the refresh rate of the display. - Apple doc

让我们开始Code吧~

Build

创建一个单视图控制器，然后将下面这些代码粘贴到viewController.swift文件的类声明中。

// MARK: -
// MARK: Vars

private let minimalHeight: CGFloat = 50.0
private let shapeLayer = CAShapeLayer()

// MARK: -

override func loadView() {
 super.loadView()

 shapeLayer.frame = CGRect(x: 0.0, y: 0.0, width: view.bounds.width, height: minimalHeight)
 shapeLayer.backgroundColor = UIColor(red: 57/255.0, green: 67/255.0, blue: 89/255.0, alpha: 1.0).CGColor
 view.layer.addSublayer(shapeLayer)

 view.addGestureRecognizer(UIPanGestureRecognizer(target: self, action: "panGestureDidMove:"))
}

// MARK: -
// MARK: Methods

func panGestureDidMove(gesture: UIPanGestureRecognizer) {
 if gesture.state == .Ended || gesture.state == .Failed || gesture.state == .Cancelled {

 } else {
 shapeLayer.frame.size.height = minimalHeight + max(gesture.translationInView(view).y, 0)
 }
}

override func preferredStatusBarStyle() -> UIStatusBarStyle {
 return .LightContent
}

以上代码中，我们做的工作主要有以下几点：

Objective-C中Category的一点东西

Mon, 14 Sep 2015 15:36:07 +0000

Objective-C中的分类（category）是一种编译时的手段，其允许我们通过给某个已知类添加方法来扩充该类的一种方式。当然这其中是有限制的，就是不能给已知类添加新的实例变量。

如下代码展示：

类MyClass为一个简单的类，其中有实例方法 -print

#import <Foundation/Foundation.h>
@interface MyClass : NSObject

- (void)print;

@end

#import "MyClass.h"
@implementation MyClass

- (void)print
{
 NSLog(@"MyClass...");
}

@end

我们向为MyClass再添加一个方法Hello，那我们就可以用分类的方法实现，我们为其添加分类MyAddition1和MyAddition2，如下所示：

#import "MyClass.h"
@interface MyClass (MyAddition1)

@property (nonatomic, copy) NSString *name;
- (void)hello;
@end

#import "MyClass+MyAddition1.h"

@implementation MyClass (MyAddition1)

- (void)hello
{
 NSLog(@"hello!!!");
}

@end

其中MyAddition为分类的名称，而文件名字约定俗成用“类名+扩展名”的形式。这样，我们就能够为MyClass类添加hello方法了，如下调用：

#import "MyClass+MyAddition1.h"

int main() {
 //...
 MyClass my = [MyClass new];
 [my hello];
 //...
}

Category 的使用场景主要有以下几种：

需求变更，需要为已知类添加方法；
将类的不同模块实现划分: a)具体可以将类的实现分开到不同的文件里面； b)将不同功能的分类文件交由不同的开发者实现；
想为Apple基础类库添加自己需要的方法，实际上和1相似；

但是分类的使用目前也有需要注意的地方：

Category可以访问原有类的实例变量，但不能添加实例变量；
Category中实现和原有类中相同签名的方法时，会覆盖原有类的方法；

但是这两点均可以通过其他方式实现：

为分类添加实例变量

为分类添加实例变量主要通过关联对象的方法。如下所示：

#import "MyClass.h"
@interface MyClass (MyAddition1)

@property (nonatomic, copy) NSString *name;

@end

#import "MyClass+MyAddition1.h"
#import <objc/objc-runtime.h>

@implementation MyClass (MyAddition1)

- (void)setName:(NSString *)name {
 objc_setAssociatedObject(self, "key", name, OBJC_ASSOCIATION_COPY);
}

- (NSString *)name {
 NSString *name = objc_getAssociatedObject(self, "key");
 return name;
}

@end

如果调用被分类覆盖掉的原方法

实际上，通过查看Objc runtime源码可以获知，分类方法并不是绝对意义上的覆盖原有类的方法，只是在调用的时候调用顺序导致而已，这涉及到Objc runtime的一些内容。

理解Objective-C运行时

Mon, 07 Sep 2015 17:55:33 +0000

Objective-C 运行时对于刚刚踏入 Cocoa/Objective 世界的人是很容易忽略的 Objective-C 语言的特性之一。原因就是尽管 Objective-C 是一门几个小时之内入门的语言，但是投身 Cocoa 的新手们会花费大量时间在 Cocoa 框架中，试图搞清楚他到底是怎么工作的。我觉得每个开发者都应该对其有深入的了解，明白一些内部的实现细节，而不仅仅只知道代码 [target doMethodWith:var] 会被编译器转换成 objc_msgSend(target,@selector(doMethodWith:),var1); 而已。了解 Objective-C 运行时的原理有助于你对 Objective-C 语言有更深入的理解，清楚你得 App 是怎么运行的。我觉得这对无论是 Mac/iPhone 新手或者老手都会有所帮助。

[TOC]

Objective-C运行时是开源的

Objective-C 运行时是开源的，你可以随时从 Apple 获取到。实际上查看 Objective-C 运行时源码是我搞清楚这个语言是怎么运作的首选方法，而不是去查看和它相关的苹果文档。你可以到这里下载到运行时的源码（截止到译者翻译的时候，最新版本的文件是objc4-647.tar.gz）。

动态 Vs. 静态

Objective-C 是一门动态的面向对象语言，这意味着它可以将编译链接时决定的事情推迟到运行时进行。这就给了你很大的灵活性，你可以按照自己的需要重定向消息到适当的对象上，你甚至可以交换方法实现（译者注：method swizzling，方法调配，开发者常用此技术向原有实现中添加新功能）。而运行时可以使对象明白自己可以响应哪些消息，不能响应哪些消息（译者注：introspect 内省），并正确的派发消息。

译者注：内省（introspection）是面向对象语言和环境的一个强大特性，Objective-C和Cocoa在这个方面尤其的丰富。内省是对象揭示自己作为一个运行时对象的详细信息的一种能力。这些详细信息包括对象在继承树上的位置，对象是否遵循特定的协议，以及是否可以响应特定的消息。NSObject协议和类定义了很多内省方法，用于查询运行时信息，以便根据对象的特征进行识别。

参考: Objective-C 的 Introspection

我们将这些特征和C语言进行对比来看，在C中，你从main()函数开始，然后按顺序从上往下写你的代码逻辑或者执行函数方法。C结构体是无法将请求转发到其他目标对象来执行方法的。你很可能写了如下类似的代码：

#include < stdio.h >

int main(int argc, const char **argv[]) {
 printf("Hello World!");
 return 0;
}

编译器解析、优化然后将优化后的代码转换成如下的汇编语言：

.text
 .align 4,0x90
 .globl _main
_main:
Leh_func_begin1:
 pushq %rbp
Llabel1:
 movq %rsp, %rbp
Llabel2:
 subq $16, %rsp
Llabel3:
 movq %rsi, %rax
 movl %edi, %ecx
 movl %ecx, -8(%rbp)
 movq %rax, -16(%rbp)
 xorb %al, %al
 leaq LC(%rip), %rcx
 movq %rcx, %rdi
 call _printf
 movl $0, -4(%rbp)
 movl -4(%rbp), %eax
 addq $16, %rsp
 popq %rbp
 ret
Leh_func_end1:
 .cstring
LC:
 .asciz "Hello World!"

然后将其和C库链接生成可执行文件。相比之下，Objective-C语言整个过程和上面类似，不过代码的产生依赖Objective-C运行时的具体表现（译者注：运行时按照不同情况，生成不同的代码吧）。当我们刚接触Objective-C语言的时候，我们可能被告知像如下代码

我们是如何创建iOS版的Guillotine菜单动画的

Tue, 01 Sep 2015 15:52:07 +0000

原文：How We Created Guillotine Menu Animation for iOS 原作者 @johnsundell

你是否曾经有过这样的疑问？为什么app中几乎是清一色的侧边栏（sidebar），为什么不把它做成topBar或者bottomBar，甚至cornerBar呢？

本文将要谈到的就是当前导航条动画的一个新趋势。

动画很有趣，但更重要的是能发挥很大的作用，它们可以改变你思考问题的方式，使得你的产品更好用并提升的app整体的用户体验。接下来我们将要展示的是设计师Vitaly Rubtsov的一个非常棒的点子：

“每个设计师都有那么一刻感到无聊。因为几乎所有（对动画）的完善修补、裁剪以及规格设定都给他们留下了很少发挥想象的余地。而每当这些时候，我就会驱使自己打开Adobe After Effects软件然后创作一些比较有趣的东西。

当我开始想我要创建一个什么东西的时候，我突然有个想法，通常侧边栏都从屏幕左侧划出，同时将所有的内容都移动到右侧位置。这种传统侧边栏的实现方式太过无聊了。那如果我们将侧边栏变成上边栏会怎么样呢？它从页面的上方掉落然后以一种特别的方式呈现，听起来很棒不是吗？“

Vitaly设计的topBar动画由我们的iOS开发工程师Maksym Lazebnyi使用swift语言实现，并且开发者给了它一个很有趣的名字—— Guillotine Menu。

by Makssym Lazebnyi

实际上，我们的iOS团队见到过很多实现这种动画效果的方法。我们选择了其中一种方式实现，这种方式允许开发者在Storyboard中以任何方式自定义菜单。

为了实现我们的转场动画（transitioning animation），我们创建了一个UIStoryboardSegue的子类和一个自定义动画管理器（custom animation controller）。基本上这就是你实现该动画所需要做的全部工作，除非你想让它更炫酷。当然我们也确实想这样做，因此还创建了一些辅助的类。

整体上，你需要三个类以及一个UIView的扩展类来创建这个动画，如下所示：

GuillotineMenuSegue. 该类是继承自UIStoryboardSegue类。我们使用它来模态显示菜单，并实现由 GuillotineMenuTransitionAnimation类控制的呈现动画。 GuillotineMenuSegue允许你为菜单添加透明度，当然本文并没有做这个工作。
GuillotineMenuTransitionAnimation. 该类是为了自定义呈现 GuillotineMenuViewController 类中视图的动画所用。
GuillotineMenuViewController. 该类是一个UIViewController的子类，存放菜单视图所用。

除此之外，我们还为UIView添加了扩展方法以便能为子视图添加约束来更好的适应父视图。

接下来，我们逐一对每一个类进行阐述。

GuillotineMenuSegue

这个类中没有什么特别的地方，我只提及一些关键点。

在该类重载的init方法中，我们检查目标视图控制器（destination view controller）是否遵守GuillotineAnimationProtocol 协议（该协议我们后面会讲到）。在重载的perform方法中我们将self设置成一个过渡动画的代理。

在代理方法 animationControllerForPresentedController 中我们使用关联对象将GuillotineMenuSegue的实例对象（self）关联到具体的将要呈现的视图控制器中，这样当menu view controller呈现在屏幕上的时候，segue实例不会被销毁。（译者注：代码如下）

- (id <UIViewControllerAnimatedTransitioning>)animationControllerForPresentedController:(UIViewController *)presented presentingController:(UIViewController *)presenting sourceController:(UIViewController *)source
{
 // 将segue示例self关联到将要呈现的试图控制器presented中，这样确保presented生命周期内segue实例不会被释放
 objc_setAssociatedObject(presented, &key, self, OBJC_ASSOCIATION_RETAIN_NONATOMIC);

 return [[GuillotineTransitionAnimation alloc] initWithMode:AnimationModePresentation];
}

GuillotineMenuTransitionAnimation

所有的动画处理逻辑都在这个类中实现。

起初我们考虑使用 animateWithDuration usingSpringWithDamping & initialSprintVelocity方法，但是当我们认真考虑这个动画之后我们改变了主意。我们需要实现的菜单动画中，当菜单从上方掉落之后，需要和父视图的左侧边界发生碰撞，产生碰撞效果。而上面方法中的回弹效果会穿过左边界（spring through the border of the superview），因此我们放弃了这个实现方式，转而采用了UIDynamicAnimator。

[257] Binary Tree Paths

Tue, 18 Aug 2015 16:28:26 +0000

题目：257. Binary Tree Paths

Given a binary tree, return all root-to-leaf paths. For example, given the following binary tree: 1 /
2 3
5 All root-to-leaf paths are: [“1->2->5”, “1->3”]

题意：

难度不大，考察树的遍历

解法：

C++版本实现方法：

 /**
 * Definition for a binary tree node.
 * struct TreeNode {
 * int val;
 * TreeNode *left;
 * TreeNode *right;
 * TreeNode(int x) : val(x), left(NULL), right(NULL) {}
 * };
 */
 class Solution {
 public:
 vector<string> binaryTreePaths(TreeNode* root)
 {
 vector<string> results;
 visitTreeNode(root, "", results);
 return results;
 }

 private:
 void visitTreeNode(TreeNode* node, string path, vector<string>& result)
 {
 if(node == nullptr) return;
 if (!path.empty())
 {
 path += "->";
 }
 path += int2Str(node->val);

 if (node->left == nullptr && node->right == nullptr)
 {
 result.push_back(path);
 }
 else
 {
 if (node->left != nullptr)
 {
 visitTreeNode(node->left, path, result);
 }
 if (node->right != nullptr)
 {
 visitTreeNode(node->right, path, result);
 }
 }
 }

 std::string int2Str(int nValue)
 {
 ostringstream ss;
 ss << nValue;
 return ss.str();
 }
 }

[018] Length Of Last Word

Tue, 18 Aug 2015 16:13:44 +0000

题目：

Given a string s consists of upper/lower-case alphabets and empty space characters ’ ‘, return the length of last word in the string. If the last word does not exist, return 0. Note: A word is defined as a character sequence consists of non-space characters only. For example, Given s = “Hello World”, return 5.

题意：

难度不大，考虑所有边界情况即可。

解法：

C++版本实现方法1：

 // 从右往左依次遍历即可
 class Solution {
 public:
 int lengthOfLastWord(string s) {
 int length = 0;
 for (int index = s.length() - 1; index >= 0; index--){
 char c = s.at(index);
 if (c != ' '){
 length++;
 }
 else if (c == ' ' && length != 0){
 return length;
 }
 }
 return length;
 }
 }

leetCode Oj系统评判结果如下图所示：

iOS 远端推送部署详解

Thu, 30 Jul 2015 14:30:00 +0000

最近几天被iOS的推送部署给搞懵了，现在特地整理下和大家进行分享。

iOS远端推送机制

APNS，全称为Apple Push Notification service，是苹果通知推送服务中最重要的一环。它是苹果通知推送服务器，为所有iOS设备以及OS X设备提供强大并且可靠的推送通知服务。每个注册通知服务的设备都会和该服务器进行长连接，从而实时获取推送通知。即使当前APP不在运行状态，当通知到达的时候也会有提示发生，最常见的就是短信服务。

每一个App必须向APNs注册通知服务，APNs会返回给设备一个DeviceToken，该Token为APNs上针对该设备的唯一标示符。App需要将该DeviceToken返给自身的Server端保存后续使用，如下所示。

当App开发者的server需要向特定设备推送通知时，就使用DeviceToken和固定格式数据（Push payload）发给APNs，然后APNs就会向DeviceToken指定的设备推送通知了，具体流程如下所示，单一推送

或者多方通知，APNs都能一一对应，靠的就是之前我们提供给它的DeviceToken。

本地推送证书配置

打开你mac的钥匙串访问，然后点击钥匙串访问

随后它会弹出一个窗口用户电子邮件信息

就填写你苹果开发者账号的名称即可（应该是一个邮件名称），点击保存到磁盘的选项，点击继续，点击存储，文件名为：CertificateSigningRequest.certSigningRequest。

然后我们打开苹果开发者中心进入 Member Center

然后点击左侧列表中任意一项进入详情页面，

APP ID

首先我们需要为我们要开发的APP建立身份信息，就是AppID，如图所示，点击左侧

点击添加按钮进入注册页面，我们需要输入App Id的名字以及BundleID，其中BundleID不能有通配符，否则无法具备推送功能，然后在下面的APP Service中勾选Push Notification一项

点击下一步，然后确认提交即可，大家注意到Push Notification一项为Configurable，这是因为我们还没有为该AppID生成推送证书，等推送证书生成完毕之后可以再回来查看该AppID 的状态。

Certificates

其次，我们需要生成开发者证书和推送证书，如下图所示，点击左侧Cerifications列表，选择添加进入下一页面，

如果您的页面如图所示为灰色不可选，说明您已经拥有了开发者证书。就不需要再次生成了，如果可选就选择该选项，

接下来进入以下界面，选择你之前添加的AppID，之后点击Continue即可，

然后选择之前我们保存在本地的CSR文件CertificateSigningRequest.certSigningRequest，点击Generate就生成了开发者的证书。

同理我们需要生成推送测试证书，生成流程和开发者证书类似，只是在证书类型页面，选择的证书类型换成了Apple Push Notification service SSL。

当我们生成好推送证书之后再回头看我们之前创建的AppId，能够看Push Notifications一项已经为Enabled了。当然发布推送证书配置完毕之后，Distribution一项也显示为Enable。

Provisioning Profiles

第三步，需要生成Provisioning Profiles，该文件其实就是以上的证书、AppId以及设备信息的打包集合，我们只要在不同的场景下生成不同类型Provisioning Profiles即可，它会在后续打包ipa文件的时候被嵌入安装包内。