技术奇异点

Mighty Mouse 上的小球是出名的容易脏。今天中午我的无线 Mighty Mouse 的小球是无论如何清洁都不能向下滚动了（办公室的 Mac Pro 的有线鼠几个月之前就已经如此了）。下午赶紧在 Apple Store 的网站上约了一个维修。心里还在盘算会怎么处理。这个鼠标买的比较早，可能已经过保了。也许打开清洁一下，或者干脆不给修了？

晚上去了 Apple Store，被告知只要有在保内的 Mac 就能保修鼠标。说是保修，其实也就是给换了一个新的。先前的那个用了一年多了，平时也没怎么保护（起码没像对 MacBook Pro 那样），使用痕迹还是很重的。想不到能很干脆的被换了一个新的。

只是不知道公司的那个有线鼠怎么才能通过层层官僚享受 Apple 的保修呢？（好多同事的小球不能用的 Mighty Mouse 都被 IT 换成 Dell 的鼠标了。不过似乎有人更喜欢 PC 的鼠标。）

另外，今天在店里用了一下最新的 Magic Mouse，觉得挺好用的。没发现有什么有悖人体工程的地方 —— 有人觉得作为鼠标 Magic Mouse 太扁了，其实 Magic Mouse 更像一个本身会移动的 Touch Pad，转换观点之后就不觉得有什么难用（有人会觉得自己的 Touch Pad 不够隆起吗？）。有人说 Magic Mouse 移动速度太慢，我在店里的 iMac 的配置上也没觉得，和我机器上的 Mighty Mouse 一样快（我机器上的鼠标配置一般都是比较快的）。看来我要攒钱在这个新 Mighty Mouse 的小球挂掉之前买个 Magic Mouse。

Apple 的 iPad 终于如期公布。不过和同事聊起这个东西，我们的第一感觉不约而同是『没什么用』：携带不方便，在随身负荷方面，MacBook (Pro) 和 iPhone 都没有挑战人们已有的习惯（相对计算能力而言），iPad 可谓又一次挑战（如果 Newton 算是一次失败的话），能成功吗？没有键盘的意义是什么呢？是为了没有键盘而没有键盘吗？键盘在我眼里仍然是人机接口里带宽最高的设备。要想超越键盘，除非对人脑的工作原理有更深一步的了解，让电脑直接越过手指理解用户的意图。

搁下这些问题，先忙其它俗务。今天和久不见面的亲戚聊了一晚上，发现话题格外多。先是聊到太空旅行的一个问题争论不下，用 iPhone 查到了资料然后再展开讨论了一番。然后给他在 iPhone 上看了最近写的几篇 blog。最后是一个智力休闲的 iPhone 游戏，不多的两三关花掉我们今晚最后的半个多小时。开车回家的时候我突然想到，如果 iPhone 的屏幕再大一些，对这次聚会来说绝对是一个完美的工具！只是屏幕再大一些，不要键盘，也不需要复杂的 content-creating 应用，我需要的就是这样一个大号 iPhone。如果有人觉得理由不够充分的话，可以想想是否在咖啡厅见到过两个人并排挤在一台电脑之前的情景，或者几个人把一台笔记本电脑傻里傻气地转来转去。

我和身边的人总是不约而同的说，iPhone 是应急计算的理想工具，比应急计算更复杂的任务则完全可以寻找应用笔记本电脑的工作环境。这是百分之百的真实感受 —— 只不过因为我们太习惯独处了。我们一贯的印象是电子设备和社交是互不相容的 —— 还记得大学的时候在宿舍看别人打游戏是多么傻气的行为，看别人在你面前写短信是多么讨厌。作为一个独处的用户，我们的第一反应是没人需要仅仅是屏幕大四倍的 iPhone。但是当生活不是独处的时候，iPad 让线下社交和网络拥有了一个合理的结合点。

看到电影里的微软 Surface 设备，我们都会觉得用它来进行任务布置是多么流畅，但是也毫不留情的嘲笑在现实生活中谁会花费如此不菲的价格，谁又能保证和朋友的所有聚会都在布置了 Surface 的私人沙龙里进行？iPad 正是 Apple 完美的回应。

所以说，什么人类不应该习惯垂直显示，什么指向设备和屏幕 cursor 分离，在我看来都不是使用平板电脑的迫切理由。而 Apple 的 iPad 发布演示也忽略了线下社交这个情景，可能老乔太喜欢唱独角戏了（不过他演示 iSight 的时候和部下们合作过一次），也可能线下社交的热闹场景拿到演示台上太过风格诡异。总之，我们太喜欢面对屏幕通过网线交流，或者面对面为一个能两秒钟就 Google 出来的问题争论一个小时和因为一个没法记起来的细节而中断话题。互联网要么是我们的隔阂，要么是遥不相及的东西。iPad 是一个改变我们生活方式的机会，是真正让互联网回归帮助而非阻碍人们交流的角色。只是把 iPhone 扩大到四倍，就是改变生活的工具。

这个啤酒挺劲！照片也挺有意思。

通常，OS X 应用程序的主菜单位置是让刚刚接触 Mac 的 Windows 用户感到新奇的一个地方。主菜单不从属于任何一个窗口。所有应用程序的主菜单都在整个屏幕的最上方显示，同一时刻不可能有多于一个应用程序的菜单显示。所以 active 程序切换的时候会产生 Windows 上没有的菜单切换现象。

对于顶置主菜单与窗口主菜单的优劣，Apple 的 Bruce Tognazzini 从用户交互的效率和速度为 Mac 的风格做出了辩护。当然也有人进行了针锋相对的驳斥。在我看来，在这场围绕 Fitt’s Law（或者说指向设备 —— 即鼠标的操作速度和效率）的争论中，双方至多算打了一个平手。我自己将近三年的 Mac 开发和使用得到的感觉是：主菜单和窗口的逻辑关系要比鼠标的指向速度重要的多得多。

至少有三个原因让我认为主菜单应该和窗口分离。第一，主菜单重在一个『主』字。基本上应用程序能完成的所有功能都应该在主菜单中能够找到对应项。所以，主菜单中必然包含非针对某个窗口（窗口无关的）或者针对多个窗口的操作。最为典型的是『 Windows 』菜单 —— 列出所有打开的窗口，控制窗口的排列。让主菜单这样的 UI 元素从属于某个窗口 —— 一个后果就是每个窗口都有一个 『 Windows 』菜单 —— 从逻辑上说是十分怪异的。第二，在 93 年左右或者更早接触过电脑的人一定知道当年著名的 MDI 模式。也就是 Word 5.0 那种模式 —— 一个大的窗口包含所有的文档窗口。这似乎是 Microsoft 在不违反 Windows 本身的主菜单必须依附于窗口的前提下，尝试让主菜单脱离文档窗口的一种尝试（当然这不是 MDI 的唯一目的，但是我认为从逻辑上看这种考虑是有的）。遗憾的是，MDI 的大窗口带来的用户体验似乎是很糟糕的，让 Microsoft 不得不放弃尝试让 MDI 作为主流。随之而来的是几种不成功的尝试：Visual Basic 6.0 把主菜单做成单独的窗口（也为 Delphi 和某些版本的 Photoshop 采用）；Visual Studio 把所有窗口用 dock tab 来实现（UltraEdit 类似）。前者类似 Mac 的风格，但是在处理主菜单的显示上明显没有 Mac 的置顶方式简洁，基本可以认为是 Mac 风格的胜利。而后者并非完美的方案，因为在有了 tab 的情况下用户往往仍然需要窗口级别的组织才能更好的同时处理更多文档。

第三，今天的程序往往很多功能并不体现在窗口上，所以很多程序有了一个特殊的状态 —— 没有任何窗口打开，但是程序仍然保持后台功能的运行。这个状态可以叫做 stealth 模式。MSN、Adobe Bridge、很多浏览器、播放器都有这种状态。但是如何从 stealth 模式恢复成普通模式？当主菜单依附于窗口的时候，进入了没有窗口的 stealth 模式时主菜单对于返回普通模式就无能为力了。在 Windows 下，开发者必须编写支持托盘图标（Tray Icon）的代码来支持 stealth mode。而在 Mac 上，几乎任何程序都天然的拥有 stealth 模式，无需一行特别代码来实现 —— 没有编写的代码就是 bug 最少的代码，也是最快的代码。Mac 程序在 stealth 模式下仍然可以拥有一个全功能的菜单（当然不合理的菜单项会 disable），而不是托盘图标提供的一个粗陋的菜单。Mac 的菜单切换也变成了在 stealth 模式下更好的隐藏程序从而不影响用户使用其它应用的一个优势，这是前面说的那种 Visual Basic 风格的独立窗口主菜单不具备的。

而且，今天的应用程序更多的把主菜单作为一种完备性的体现而不是用户体验的主要组成部分。快捷键，工具条，拖放，图标，右键菜单（context menu），乃至于 multi-touch pad 的 gesture；这些才是用户体验的集中体现。所以，主菜单的设置合理更多的在于逻辑关系的正确和清晰，主菜单是用户发现功能的场所，而不是使用功能的主要场所。不是 Fitt’s Law 体现的速度和效率的主要舞台。所以，即使在 Fitt’s Law 方面各执一词，在菜单切换现象上略有劣势，我仍然有理由认为 Mac 的菜单风格胜出。

最近 Ryan Gordon 终止了在 Linux 上实现 Fat Binary 技术的努力。这让我和甫鸼展开了一场对 Universal Binary 技术的讨论。

Universal Binary 的鼓吹者一般认为在连接器和操作系统底层直接加入对多 CPU 架构的支持（ multi-arch support ）可以大大简化开发者的负担和提高最终用户感受到的易用性。反对者则可以反驳说把能放在 build 脚本和 installer 中的 policy 不必要地塞到底层违反了 Unix 的原则。

抵触最大的恐怕是 Open Source 社区。毕竟这次 Ryan Gordon 放弃的直接原因就是 Linux 社区对其努力的冷落。Open Source 的发布方式可以戏称为 Universal Source —— 程序的大部分由 CPU 架构无关的源代码构成，少部分 CPU 构架相关的代码由条件编译构成或者由 build 脚本根据执行 build 的平台条件来引用不同的源文件。经由 Open Source 的安装三部曲（configure-make-make install），就能安装好一个适合目标硬件的精炼的无冗余的程序。这样的发布是完美的 —— 除了不能兼容非 Open Source 的商业模式。

要应对多 CPU 架构，就必需在程序的发布或者运行中实现应对这种架构的智能。Open Source 模式的优势在于它的发布形式能够完整的体现开发者在编写代码时就考虑到的一切应对 multi-arch 的智能，然后在安装过程中（也就是 build 过程中）由编译器、连接器和 build 脚本的强大智能来完成部署。非 Open Source 的发布模式则必须另辟蹊径。在所有面对 multi-arch 这个难题的企业中，Apple 当年的问题最为紧迫。由于要完成从 Power PC 到 Intel x86 的迁移，Apple 必须在一个时期之内能给开发者和用户一个足够简单（甚至傻瓜化）的解决方案。尽管如 Linux 社区大力主张把 multi-arch 的智能放到 build 脚本和 installer（Linux 的 package manager）为正途，而 Mac OS X 在很多方面也确实遵循 Unix 的文化，最终 Apple 还是选择了 Universal Binary 。因为我每日都在 OS X 上开发，已经习惯 Universal Binary，到了有所偏爱的程度。

为了比较各种方案的差异，设定一个例子。有一个工程，在单一 CPU 架构的时候生成四个可执行文件，六个数据文件，一共十个文件，为其增加 multi-arch 支持。假设我们拥有一个不支持 Universal Binary 的操作系统。当然相应的编译器和连接器也就不会支持 Universal Binary。但是我们仍然假设编译器和连接器的交叉编译功能很方便，只要一个 Option 就能切换目标文件的 CPU 种类。也就是说支持不同 arch 的基础能力具备，只是没有对 Universal Binary 的支持。那么，为了服务使用不同 CPU 架构的用户，我们就必须面临几种选择。第一是我们使用一套标准的工程文件，针对需要支持的每种 CPU 架构，用相应的编译器 Option 编译一次。假设有三个 CPU 构架。因为是采用完全相同的工程文件，仅仅是一个编译目标的 Option 不同，所以我们会生成 30 个文件（三个版本，每个版本十个文件）。使用不同 CPU 的用户可以选择不同的版本安装。这样的方案，build 过程中对六个数据文件（假设是平台无关的格式）的生成就是冗余的。对于拥有多于一种 CPU 架构的机器的用户来说，需要下载相应的多个版本，所以重复下载了六个数据文件（重复的次数由用户拥有的 CPU 种类决定）。

另一种选择是我们写一套特殊的工程文件。一次生成支持三个 CPU 的 12 个可执行文件（每个架构四个），而对于平台无关的六个数据文件只生成一套。所有的结果都打入一个 package。相应的，installer（或者说 unpackager）必须针对用户安装时的平台提取正确的可执行文件版本和数据文件。这种方案的缺点是必须自己在 build 脚本和 installer 里编写处理 multi-arch 的智能。Universal Binary 的反对者会说这些智能并不复杂，Build 脚本和 installer 正是实现它们的好地方。但是，实际上每个工程实现这些智能的方式都会有些微的区别。这就意味着，用户从一个产品得到的知识并不能用到另一个产品里 —— 比如检查该产品支持的所有架构，如果是 Universal Binary 的话可以用统一的命令查询。开发者从一个工程转向另一个工程也必须通过文档或者别人的描述才能熟悉这个工程特有的 multi-arch 处理。

对于上述的工程例子，支持 Universal Binary 的系统则是一次生成十个文件，只在四个可执行文件中同时包含三种 CPU 架构的代码（用 ELF 的术语来说是三个 section ）。这种方式为反对者诟病之处在于，安装好的系统存在冗余 —— 磁盘上会有用不到的机器码，提高了连接器和操作系统的复杂度，违反了 Unix 的 Mechanism, not policy 的原则。不过，任何稍稍违背这一原则的做法都会带来一个好处 —— 标准化带来的统一性。在《C++与垃圾回收》一文中我曾经说过，正是因为 C++ 把各种高级内存管理策略放到了库而不是语言级别，才让这些高级策略不能得到强制统一而形同虚设。所以，mechanism-not-policy 需要灵活的「道」来处理而不能一味的极端化。

Universal Binary 其实可以看作一种次优的方案。它的冗余度没有达到最优（与定制编写 build 脚本和 instaler 相比），但是大大低于第一种方案。即使存在冗余度，冗余的粒度也很小，属于次文件级别（ELF 格式为例，即 section 级别）。而且这个冗余度也带来了一些智能 installer 方案不具备的好处，就是安装之后的程序可以在不同架构的 CPU 的机器之间自由拷贝（前提是程序具备这种在任意位置运行的能力，而 Mac OS X 的 Single-File Application 恰恰是这种风格）。Universal Binary 还是一个非强制性使用的功能。连接器和操作系统只是提供支持 multi-arch 的能力，选择打入哪些 CPU 架构的执行码完全由开发者自己决定。从这个角度来说，Universal Binary 并不是真的违背 mechanism-not-policy 的原则。Universal Binary 产生于 Mac 的特殊历史，也与其文化相辅相成 —— Single-File Application，也就是 installer 完全零智能；无中央化的包管理（通过 Guide 来保证用户体验的一致）；相当数量的用户（由于 transition 阶段的存在）拥有或者在一段时间拥有基于不同 CPU 架构的多台机器，需要程序能够在机器之间自由拷贝并保持工作（由于 Single-File Application 的文化）。

Universal Binary 是一个能提供有别其它方案的独特优势的方案，当然也引入了自身的代价。综合考虑，这些代价在 Mac 特有的文化中是完全可以接受的，也就是说 Universal Binary 在 Mac 的发展中是最好的选择。至于这种收益代价的比例在其它操作系统上如何还有待考验。不过我认为其它系统应该保持一种开放的态度。

这几天实在是太忙了，这种状态还要持续一段时间，不过也不会很长。没时间写长的东西。

今天无意发现 OS X 里面 MacBook Pro 的图标很精细（也就是在我的 MacBook Pro 上表示本机的图标）。似乎是严格按照 15 寸的 MacBook Pro 外观设计的。不知道在 17 寸的机器上表示本机（或者在网络上表示 17 寸 MacBook Pro）的图标是否会体现出机型之间的细微差异（还有在网络上能否识别对方是 17 寸的机器）。