Apple版 - Snow Leopard：安装进度条背后的故事【连载3/23】 |
|---|
|
|
|
|
|
|
a****a
发帖数: 5763 | 1 Mac OS X 10.6即所谓的Snow Leopard操作系统已正式发售。一如既往，Apple产
品光鲜的外表下凝聚了太多艰辛的劳作。ArsTechnic的John Siracusa以其独特的、专
业的、全面的视角深入翔实地体验这款最新的操作系统。
Weiphone.com将对该综述进行翻译整理并独家连载。欢迎关注。
Apple宣称，新版操作系统Snow Leopard的安装进程“速度提高幅度最高可达45%
”。安装过程耗费的时间很大程度上取决于安装内容、目标磁盘碎片、光驱速度等等因
素。当然，大多数情况下用户只需安装一次操作系统，一般不会有人过多关注安装进程
。可是，既然Apple坚持标榜这一点，我想关注一下安装进程以及相关的细节是值得的
。
为了尽可能多地排除不确定因素，我选择了从一块硬盘向另一块空白硬盘安装
Leopard和Snow Leopard系统以示对比。需要注意的是，这样做显然屏蔽了Snow
Leopard安装进程中最重要的一项优化措施，即Snow Leopard在很大程度上减少和避免
了从光驱随机存取数据。
即便如此，Snow Leopard的安装工作仍旧比Leopard节省了大约20%的时间。当然
这比Apple宣称的“45%”要少一些，但是请注意关键点：Apple强调了其Snow Leopard
安装速度提高幅度“最高可达”45%。顺便，两款操作系统安装时间均小于30min。
然而，Snow Leopard安装进程中最引人注目的是，初始Spotlight索引进程究竟
有多快。在我的测试中，Snow Leopard较Leopard速度提高了174%(耗时：3'20" vs 5'
49")。当然不要忘记我的测试是向空白硬盘上安装，而这并非普遍情况。但是更快的
Spotlight索引速度是值得关注和赞誉的，因为这往往是很多用户最先体验到的：Snow
Leopard意味着高效率。
另一件值得关注的是，Rosetta并未作为默认安装项。Rosetta是一种二进制编译
程序，能够让PowerPC平台上开发的软件在Intel平台Mac上运行。或许从中我们可以窥
见Apple的意图，PowerPC正在逐渐淡出舞台。
但是默认选项不安装Rosetta？看起来似乎有点不可理喻。当那些升级至Snow
Leopard的用户双击了一款PowerPC程序的时候会发生什么呢？或许是如下这一幕：
这是当我试图在Snow Leopard上启动Disk Inventory X时遇到的，这是一款只支
持PowerPC的程序。当我点击了“Install”按钮时我满以为系统会提示我插入安装DVD
。结果Snow Leopard却连结到网络从Apple服务器下载并安装了Rosetta。
安装完成之后无需重启，Disk Inventory X顺利启动。这种“需要时安装(
Install-on-Demand)”以往在Mac OS X中并不普遍，但是这里Rosetta的安装进程却相
当完备。点击“Install”之后，会自动下载一个包含大量有用安装包的XML属性列表。
同样，在需要安装打印机驱动时，Snow Leopard也会采用相同的方法，省去了安装DVD
这一环节。希望这种技术在以后能有更广泛的应用。
关于磁盘空间
Apple宣称Snow Leopard“占用的硬盘空间比先前的版本小一半以上”，这确实
是事实。一个干净的默认Leopard安装占据16.8GB空间，而Snow Leopard只需5.9GB。
引用
Snow Leopard在系统占用磁盘空间的表述上暗藏玄机(译注：trick up one’s
sleeve袖子里有鬼把戏)。Snow Leopard系统的Finder认为1GB等于10^9字节，而
Leopard Finder——以及旧版本的Finder却认定1GB等于2^30字节。这样一来，在安装
了Snow Leopard之后你的硬盘仿佛瞬间变大了！例如，我的“1TB”硬盘在Leopard
Finder中显示容量为931.19GB，而在Snow Leopard中却显示为999.86GB。正如您猜测的
那样，硬盘制造商通常采用的是10进制系统。这一切看起来相当的混乱。尽管我个人坚
定地站在“二次幂体系”这一边，但是我也不愿责备Apple过分迎合磁盘制造商们确立
已久的容量测定标准，尽管这是相当愚蠢的(译注：作者原话“but still dumb”，非
译者观点)。
Snow LLeopard有几个减肥秘诀：第一个很明显，没有PowerPC支持，意味着没有
PowerPC可执行代码。让我们回想一下Leopard可执行文件的最大可能二进制载荷(
binary payload)：32-bit PowerPC, 64-bit PowerPC, x86, and x86_64。现在可以把
这份清单上一半的内容划掉了。Leopard系统中，几乎没有应用程序包含任何类型的64
位代码，但是无论如何划分，可执行文件的体积都缩减了50%。
当然，操作系统中并非只包含可执行文件，还包括数据文件，图形文件，音频文
件，甚至还有一些视频文件。但是大多数这种非可执行文件都有一个共同点：它们通常
都以压缩文件格式存储。图像通常是PNG或者JPEG文件，音频通常是AAC文件，视频通常
是MPEG-4文件，甚至预置文件(preference files)和其他属性列表都默认采用紧凑二进
制格式(compact binary format)而不是XML。
Snow Leopard中，一些其他类型的文件也走入了“压缩”的行列。举一个例子，
Snow Leopard中97%的可执行文件都是经过压缩的。压缩到什么程度呢？请看：
呵呵，相当的小，不是么？这真的是一个可执行文件么？来检验一下我们的猜测
。
看看！发生了什么？哦，我忘记告诉你了，上面这些命令是在Leopard系统上运
行的，来查看Snow Leopard磁盘。事实上，从先前版本的Mac OS X中浏览Snow Leopard
系统的压缩文件，都会显示占用字节数为零。(当然，如果启动进入Snow Leopard系统
，这些文件看起来就完全正常了，运行也很正常。)
那么，数据究竟去哪了呢？在上面ls输出结果中，权限字符串(permissions
string)末尾的小小的“@”为我们提供了一个线索。尽管Mail可执行文件的大小为零，
但是它确实具备一些扩展的属性：
呵呵，原来所有的数据都在这里。但是，为什么存储在资源分支(resource fork)
里呢？这不是在8年前就已被废止了么？确实如此… 您在这里目睹的是Apple系统中引
以为傲的一项技术，HFS+
早在若干年前Mac OS X推出伊始，Apple就添加了日志系统(journaling)、符号
链接(symbolic links)以及硬链接(hard links)。在Tiger系统中，扩展属性和访问控
制列表都是包括在内的。在Leopard系统中，HFS+支持目录的硬链接。而在Snow
Leopard系统中，HFS+学到了另一招：per-file compression(单文件压缩？)
com.apple.decmpfs属性的存在是该文件被压缩过的第一个迹象。当启动并登陆
Snow Leopard系统时，该属性事实上隐藏在xattr命令之后，但是它在Leopard系统中并
无特殊意义。
随Snow Leopard的推出而迅速更新的Mac OS X的hfsdebug程序帮助我们了解了更
多的信息。
正如我们看到的，资源分支(resource fork)确实包括了压缩数据。然而，这是
为什么呢？事实上这是Apple惯用的、明智的向后兼容策略的一部分。最近的一个例子
是，从Leopard及先前版本的Mac OS X系统中浏览时，目录的硬链接(hard links to
directories)出现的方式。
在HFS+压缩的例子中，Apple使Snow Leopard以前的系统无法读取压缩过的数据
，因为在先前的操作系统中，这些数据存储的位置和方式无法被识别。但是，与其让
Snow Leopard以前的系统上的应用程序(或用户)在运行这些压缩内容时遇到阻碍，
Apple的选择是，索性把这些压缩数据隐藏起来。
然而，将这样一些较大的文件的完整内容以这种方式隐藏起来，并使Snow
Leopard以前的系统仍旧可以找到并复制这些文件而不至丢失数据，这一切究竟如何实
现呢？当然答案就在资源分支(resource fork)里。当移动或复制文件时，Finder总是
正确而完整地保留Mac特有的元数据(metadata)、资源分支(resource fork)和数据分支
(data fork)。在Leopard系统中，即使cp和rsync这样低级别的命令亦如此。因此，从
Leopard系统中查看Snow Leopard磁盘时看到一大堆0 KB的文件，不必惊讶也不必担心
，即便您移动或者复制这些文件，丢失数据的几率也非常小。
资源分支(resource fork)并不是Apple藏匿压缩数据的唯一地点。对于小一些的
文件，hfsdebug结果如下：
这里，数据足够小可以完整地存贮为扩展属性，然后：
是的，整个文件的内容都以未压缩的形式存储为扩展属性了。在这样的标准
PkgInfo文件的例子中，这些内容则是4字节的经典Mac OS型和生成器代码(creator
codes)。
在先前的com.apple.decmpfs属性中仍然可以看到相同的“fpmc…”前导序列(
preamble)，但是在值的末尾，预期数据却清晰地出现：类型代码(type code)“APPL”
——意为应用程序application，以及生成器代码(creator code)“emal”——意为
Mail应用程序。
或许您会疑惑，如果这就是Snow Leopard压缩数据的方式，那么为什么存储8字
节的未压缩数据加上17字节的前导序列(preamble)就能够节省存储空间呢？答案就隐藏
在HFS+分配磁盘空间的方式里。在资源分支(resource fork)中存储信息时，HFS+会以
按照系统配置块大小(block size，默认4KB)的倍数分配空间。因此在传统存储方式中
，这些8字节的数据将占据至少4096字节的空间。但是如果以扩展属性的方式分配磁盘
空间，配置块大小(allocation block size)则不是倍数关系；数据将以更紧凑的方式
打包。最终，以扩展属性方式存储该25字节的数据，所节约的空间超过4000字节。
然而，压缩的目的并不仅仅是为了节省磁盘空间。这也是牺牲CPU周期(CPU
cycles)以降低I/O延迟和带宽的经典手段。在过去的几十年中，CPU性能的提升幅度远
远超过磁盘性能提升的幅度。现代的磁盘的寻道时间(seek time)和旋转延迟(
rotational delay)仍旧是毫秒数量级的。而在1毫秒的时间里，2GHz的CPU可以完成2百
万个周期。当然，还要考虑实际数据传输所需的时间。
当然，在操作系统和硬件工作过程中存在几个水平的缓冲或许能够淡化这类延迟
。但是这些数据需要从磁盘读取到缓存当中，而压缩就意味着更少的数据传输。 现代
多核Mac在正常使用过程中，从磁盘传输压缩载荷并通过CPU解压缩并放入内存所耗费的
总时间，仍旧远小于传输未压缩数据所需要的时间。
这就解释了传输少量数据所带来的潜在的性能提升。同样，以扩展属性的形式存
储文件事实上可以让速度更快。
当然，影响硬盘速度还有一个重要因素就是，磁头从磁盘的某个地方移动到另一
个地方所耗费的时间。磁头开始移动，停止，然后确保定位准确，然后等待磁盘将需要
的数据写入，每一个动作都需要耗费一定的时间。这些都是实际的物理动作，这些动作
则是硬盘等旋转存储设备性能的真正杀手。
HFS+卷格式在磁盘上存储了文件的全部信息：Catalog File存储了文件的数据、
权限、所有者以及一些其他信息；Attributes File则存储了“具名分支(named forks)
”。
HFS+中的扩展属性在Attributes File中作为具名分支(named forks)来使用。但
是与资源分支(resource forks)不同，HFS+中的扩展属性通常“线性”储存在
Attributes File中。在实际中，这就意味着单一属性的大小被限制在128字节以内。同
时这也意味着磁头不必为了获取实际数据而移动到其他位置。
正如您想象的那样，作为Catalog File和Attributes File的磁盘块(disk block
)的读写频率非常高，就像多数情况下的缓存区一样。所有的这些机制共同作用，使得
整个文件的存储性能显著提升。甚至，8字节的载荷激增到25字节也不值得忧虑，因为
它仍旧小于一般数据存储所需的配置块大小(allocation block size)。
当然还有其他一些重要的因素，也使得Snow Leopard存储耗费的磁盘空间显著降
低(诸如不必要的定位文件以及“designalbe.nib”文件等)。但是HFS+压缩技术无疑是
最重要的因素。
其他细节
此外，Apple还就Snow Leopard的安装进程提出了另外两点有趣的细节。
引用
Snow Leopard会检查您的应用程序以确保它们能够兼容，并且忽略(set aside)
所有已知不兼容的程序。一旦电源供应中断影响您的安装，您可以重新启动而不会丢失
任何数据。
忽略“已知的不兼容程序”无疑是对2年前一些Tiger用户升级到Leopard时遇到
的“蓝屏”问题作出的反应，该问题正是由不兼容程序引起的——亦可能是“非法的”
第三方系统扩展程序。对于这类问题，我很欣慰Apple采取了这样的手段来使其对用户
的影响降低到最小。
显然Apple不可能希求检测并阻止所有潜在的不兼容软件。我猜测或许只有最常
见或者高度风险的软件会被检测到。如果您是一位开发者，这个功能或许是一个很好的
途径，来检测您的“作品”是否在Apple的黑名单之上。
对于电源中断后继续安装，我并没有进行测试(我有UPS)。对于安装系统这类长
时间运行的进程，这种功能是不错的，特别是对手提电脑等电池供电的设备。
我之所以提到安装进程中的这两点细节，大抵是因为Apple开发者确实花功夫对
操作系统的各个方面进行了完善和润色，并对于这种可能发生的事件给予了足够的关注
。或许您会认为在2年左右的开发周期中，负责安装进程的小组或许经受了巨大的压力(
而无力顾及这样的细节)。显然并非如此，而用户也会从中得益。 |
|
|
|
|
|
|
