隐藏在Mac系统中的12个彩蛋 你知道几个?

　　苹果现在面临着一个抉择：继续维护浑身“补丁”早已过了“而立之年”的 HFS+ 文件系统，还是全新开发一套文件系统。显然，相比于前者高昂的维护成本，后者来得更划算一些。

　　在去年的 WWDC 上，苹果在深思熟虑之后做出了这个抉择，发布了全新设计的文件系统：APFS（ Apple File System ），这意味着使用了 20 年的 HFS+ 文件系统将被逐步替代。我们知道，HFS 的历史已经有30多年，诞生在软盘和机械硬盘时代，很多特性已经不适用如今大多数企业和用户所需要的一些基本功能，比如：纳秒级时间戳、校验、稀疏文件等。从 Snow Leopard 开始，Apple 就有转向 ZFS（最为先进的文件系统之一）的想法。但是由于后来 Sun 被 Oracle 收购，该项目后来就搁置了。直到今年，Apple 终于又将新的文件系统提上日程。

　　下面，小编从开发者的角度，通过 Sierra 中的一些文档、开发者网站中提供的资料和一些实例，来与大家聊一聊 APFS 存在的意义和它与 HFS+ 的区别。这篇文章主要面向对于 macOS 内部文件系统机制感兴趣的朋友们，对于 Mac 新手和无硬件基础的读者们来说可能不是很友好。

　　对于一部我们手中完整的 Mac 产品来说，它的组成部分大致可以分成三层：1、处在最底层的 Hardware 层；2、底层之上的 Core OS “ Darwin ” 层；3、顶层图形用户界面的 GUI 部分，即 “ Aqua ” 层。就上面提到的这几部分的层级关系，我们可以画一张图表示一下：

　　我们要讨论的APFS 和 HFS+ 文件格式属于第二层，即 “ Darwin ” 核心系统层中最底部 Mach 层嵌套的 BSD 系统中的 File Systems 部分。

　　这套类 Unix 的 BSD 系统由加州大学伯克利分校在 1977 年至 1995 年开发，在之前 NeXT 公司成功开发了由 Mach3 、BSD 以及 I/O Kit 的混合内核之后，Apple 将其很好地移植到了 macOS 上，这部分从 2000 年的 Mac OS X 和 iOS 的基础 “ Darwin ” 发布后就一直沿用至今。

　　对于 File System ，我们知道它向上服务 Application 和 Users ，向下服务 Storage Device Diver 和 Device 。正是这样的层级关系，差评君在试图寻找系统目录下的 File System 描述文件时，无意间发现了这个 apfs.fs 的彩蛋包（ path :: /System/Library/Filesystems/apfs.fs ），通过创建时间我们可以知道它是在 2017 年 6 月 21 日被添加进来的。

　　当然，我们按常理也可以判断出来：新文件格式的开发一定不会脱离旧有的文件格式环境。换句话说，APFS 的开发是要依赖于 HFS+ 的文件格式下才可以实现的。正是因为这种原因，APFS 一定会继承 HFS+ 的全部功能。

　　打开文件包，我们可以从 Resource 文件夹下看到有关 APFS 格式的一些指令现在已经封装好已经可以通过 Terminal 调用了。我们尝试打开一个 newfs_apfs.fs ，可以发现其中的概述部分还处于缺失状态，可见截止到 2017 年 6 月 21 日，这个文件系统从去年开始就一直处在紧锣密鼓地开发之中，至少这个文件呈现给用户的就是这个样子。

　　我们接着这个文件，还可以从中窥见一些端倪：新的 APFS 格式可以为文件添加密码。作为文件系统安全性保障的加密功能是 WWDC 上特别强调的，同时也是不同于 HFS+ 格式的一大改动。相较于 HFS+ 的全盘加密，APFS 则提供了统一密钥加密，针对敏感元数据单独密钥加密和多密钥加密的功能，这样哪怕用户设备物理安全受到威胁，依然可以保障数据的完整性。

　　下面小编就简单地说一说经过半天的测试，这套 APFS 文件系统的表现。

　　首先我们需要创建一个 APFS 文件格式环境，由于在 10.12.6 版本下似乎关闭了 disktuil 后 createContainer 指令的调用，所以现在网上的方法都已经失效了。不过，通过浏览开发者文档，小编发现可以通过 Terminal 结合 hdiutil 相关命令来进行环境的创建，这里创建的过程就不赘述了。最终我们生成了一个 30GB 大小的 Apple 稀疏磁盘映像 Media ，挂载到了外置优盘中。通过 diskutil 相关命令，我们可以检验到的确生成了 APFS 的 Container 和一个名称为 I_am_APFS 的 APFS 卷宗。

　　我们通过 diskutil apfs list 命令列出当前系统中所有的APFS 卷宗信息：

　　可以看到的是，这里与目前普通 HFS+ 宗卷不太相同。首先，一个 GPT 分区，如 disk4 被标示为一个 APFS Container，这其实是将整个分区作为一个逻辑分区区域。通过 APFS Physical Store 也可以看到这一点。然后，该分区上有一个名为 I_am_APFS 的宗卷，设备名称为 disk4s1。

　　采用控制变量的方法，在同一块优盘中同时生成了 APFS 和 HFS+ 两种格式的 Container 。下面我们用一部1.5 GB 的 mkv 文件进行数据传输速度测试：

　　通过测试，这部视频拷贝至 APFS 格式系统内和 HFS+ 格式系统内分别用了 20 秒和 10 秒。为什么 HFS+ 速度反而会比 APFS 快了一倍？由于我们使用的是第三方外置存储设备，对于 APFS 的支持不是很好，这也说明了另一个问题：iPhone新的文件系统如何被第三方厂商支持，这种转型一定是需要时间的，而时间的长短或许取决于在 APFS 正式推出后对用户体验的改善情况的好坏。

　　由于改变了存储逻辑，在复制文件时无论多少份都几乎只占用一份的空间大小。新复制的文件通过地址索引链接的方法指向原始文件，或者说它们更像是一种并行的关系。比如在 APFS 格式下将 1.5 GB 的电影复制十份，占用的大小依旧是 1.5 GB 。这种机制更像是现在网盘厂商在维护硬盘空间时常用的查重机制，而 APFS 或许使用了一种与网盘厂商校验 MD5 不同的方法来进行查重。

　　我们通过开发者文档可以了解到，这套 APFS 文件系统对大小写敏感。这也就意味着有许多软件在新文件系统下将无法安装使用，典型代表就是 Adobe 全系列软件。

　　另外，由于APFS 不支持目录硬链接，所以它现在不兼容 Time Machine 功能，希望以后能够针对 Time Machine 提供更高效的序列化机制。

　　总结一下，现在这套脱胎换骨的 APFS 已经具备与 BSD HAMMER、Linux btrfs，或 OpenZFS 等现代化文件系统不相上下的功能和特性。对于 APFS 在下一个系统版本 “ High Sierra ” 中的表现，让我们拭目以待。

　　其实不止 macOS ，下一版本的 iOS 11 也很有可能搭载 APFS 文件系统，这对使用小容量存储设备的用户来说是一个利好消息。