我在瓣读中使用了Realm做数据的持久化存储，所以把自己的一些实践体验分享一下。
Realm 的身世，大家可以在官网上查看，当初我是看了一遍 Realm 官网上的介绍，就很快决定了选用它，它第一眼吸引的特点有以下几点：
1、原生就支持 Swift，有 RealmSwift
2、多平台、可视化支持，同时支持iOS和Androi**d，还有一个Realm Brower应用，可以查看数据库中的内容。
3、使用简单方便，它不是基于Sqlite的封装，而是完全自己开发了一个数据库，完全没有那些sqlite语句，基本上看一眼示例代码就知道怎么用了。
该文发布在少数派：为了更高效地在豆瓣写读书笔记，我开发了瓣读APP
瓣读APP是一款豆瓣读书笔记客户端，能帮你快速搜索、标记图书，更高效地写读书笔记，支持在笔记中插入原文、图片、设置笔记为仅自己可见，支持文字识别插入笔记、将笔记转成长图分享。
Swift 4最重大的一个变化就是增加了一个Codable协议，解决了在Swift中进行字典<->模型转换的问题。
在OC中，因为有runtime，我们能够比较方便的做字典转模型的操作，而在Swift中，没有了runtime，很难对字典转模型做自动操作，虽然网上现在也有一些第三方库，但要么使用繁琐，要么使用的是苹果不太推荐的做法。现在苹果推出了Codable协议，彻底解决了这个问题。
本文为《代码整洁之道（Clean Code）》一书的读书笔记。这本书是以Java开发为例，但一些基本的原则是通用的。
书中以Java为例，从命名、函数、类、注释、单元测试、格式、错误处理并发编程等各方面详细介绍了如何让代码变得整洁。整洁的代码有很多特征，其中最重要的，也是一眼能够看出来的，就是整洁的代码都是短小的。诚然短小的代码并不一定都整洁，但整洁的代码一定是短小的，它每份文件的代码量是短小的，每个类是短小的，每个函数是短小的，每个注释是短小的，每个单元测试同样也是短小的。
短小就意味着代码没有多余的内容，意味着代码结构清晰，意味着更好的可读性。
当然短小是有前提的，就是所有的代码命名都是有意义的，类名、函数名、变量名都是有意义的，要在有意义的前提下，尽量做到短小。
由于Swift是一门静态的、强类型的语言，因此Swift编译器能够在编译阶段就对代码做大量优化，本文将探讨Swift编译器会对代码做哪些优化，我们该如何利用编译器的优化特性写出更高效的Swift代码。
苹果为了保准UITableView视图的性能，使用了cell的重用机制，cell可以通过重用标示符（reusableIdentifier）进行复用，默认的注册cell和获取cell的方法中，需要传入一个字符串作重用标示符。但这种方式很容易出错，而且使用起来也相当别扭，一种普遍的解决方式，就是直接只用类名作为重用标示符:
1 | tableview.registerClass(UITableViewCell.self, forCellReuseIdentifier: String(describing: UITableViewCell.self)) |
但这种写法依然颇为繁琐，每次都要传入一个类，并把它转化成字符串。所幸，借助Swift的泛型特性，我们可以有更加优雅的实现方式。
在实际项目中，我们会碰到一个view需要有不同的布局样式的情况，这种情况，我们可能会分成几个view来写，或者在一个view中通过if...else..来适配不同的布局。前一种方式会造成代码浪费，后一种方式造成一堆if...else...，降低代码质量。在Swift中，通过使用协议和结构体，可以将一个view中的视图和布局功能解耦，让一个view可以便捷地使用不同的布局，一个布局可以便捷地运用到不同的view上。
当我们通过协议类型来创建一个变量时，这个变量会被包装到一个叫做存在容器的盒子里，这个存在容器除了变量本身的数据外，还会存储一些其它的数据，因此它占用的内存会变大，相应的也会损失些性能。
在Swift 2发布时，苹果将Swift定义为一门面向协议编程的语言，协议（Protocol）在Swift中被赋予了更加强大、灵活的功能。相比于Objective-C的协议，Swift的协议不仅可以被用做代理，也可以用作对接口的抽象，代码的复用。这里主要介绍下协议的扩展与协议的动态、静态派发。
近期在我厂的实际项目中发现，在iOS 8系统中，Tableview cell 的排版出现了错乱，特别是在执行reloadRows:方法后，cell不仅会出现一个动画，最后高度还会不对，详情看动图：
后来经过层层排查，基本可以确定是系统的一个bug，在Swift3 + iOS 8的情况下才会出现。