使用泛型构造一个聪明的 JSON 解析库

Jun 10, 2018

“Don’t Repeat Yourself” 在 Codable 出现之前，Swift 中把一个 JSON 字典转换成对象的时候，需要手动转换类型： self.address = dictionary["address"] as? String 即使使用了 SwiftyJSON 这样的库，只是方便了书写方式，仍然需要手动指定类型。 其实 self.address 已经在声明的时候指明类型了，提取 JSON 的时候指定类型，在信息上讲完全是冗余的。利用泛型，我们完全可以省略这一步骤： extension Dictionary { func mapValue<T&...

加快 CocoaPods 项目编译时间：Pod 预编译的傻瓜式解决方案

May 4, 2018

问题 CocoaPods 以源代码的形式集成第三方库，这些库在开发的过程中经常会重新编译。当引用的库数量很多的时候，这个编译时间就会非无法忽略变得非常讨厌。毫无意义，并且降低了工作效率。 加快编译的一个方式是把第三方库全部预编译好，再集成到工程里。但这个过程非常繁琐，要手动编译库建私有仓库，版本更新时又要重做。虽然已有一些方案来解决这个事情，但在前两个问题上处理的都不够好，无法完全做到自动化。 为什么不用 Carthage Carthage 可以集成二进制库，为什么不用呢？有以下几个原因： Pod 是一个简单的易用的组织文件\管理依赖的形式。它可以使用私有 Pod 或 本...

更友好的 warning 消除方案

Jan 6, 2018

对于编译型语言，开启编译器的「Treat Warnings as Errors」是非常有益的。它把 warning 当做错误，会中断编译，强制我们修复问题。在没有开启这个功能的时候，warning 会随着开发不断积累增多。当数量很多的时候，新增的 warning 不容易被发现，从而掩盖问题。 对于一个自律的独立开发者，这个问题是可以避免的，但多人协作的情况下，需要「Treat Warnings as Errors」这样强制的功能来保障。 但是它有一个问题: 对于开发和调试不太友好。在编译一些未完成的代码的时候非常容易出现 warning，而这些 warning 没有任何实际意义。比如...

如何动态更换 iOS App 图标

Jul 16, 2017

在 iOS 10.3 之前，App 图标是固定，只能通过发新版来更新。但现在有些 App 可以让用户自己选取图标，并及时生效。这是因为 10.3 里引入了一个新的 API，它允许在 App 运行的时候，通过代码为 app 更换 icon。 快速上手 虽然提供了更换的功能，但更换的 icon 是有限制的。它需要开发者提前预置在工程里，并做好相应配置。更改 icon 的时候，只能在有限的选项中进行选择。 具体方法很简单： 配置 info.plist 文件，添加对应的 alternate icons 的信息。 调用 UIApplication.setAlternateIconName...

文本对齐，如何像素般精确还原设计稿

Jun 27, 2017

问题 在工程师实现设计稿的时候，文本框的对齐是一个经常遇到且棘手的问题。明明已经遵照设计师的标注实现，但结果却与设计稿有很大差异。 「label 为什么有这么大的上下边距呢？」 「行距是 1.2 倍但是效果完全不一样！」 这时候只能靠手工一点一点试，而且由于 app 开发不能像 web 一样及时生效，很浪费时间，且不够精确。 我们的目标是: 只需按照标注 coding，即可像素般准确实现设计稿中的文字对齐与行间距样式。为了解决这个问题，我们需要先明确一些概念。 文本的度量 文字的排版不只是把方块字依次排列起来即可。对于拉丁字母，f 与 g 以什么方式上下对齐？为...