QuickTime X：平滑过渡，缓称王【6/23】# Apple - 家有苹果
a*a
1 楼
http://bbs.weiphone.com/read-htm-tid-498907.html
Mac OS X 10.6即所谓的Snow Leopard操作系统已正式发售。一如既往，Apple
产品光鲜的外表下凝聚了太多艰辛的劳作。ArsTechnic的John Siracusa以其独特的、
专业的、全面的视角深入翔实地体验这款最新的操作系统。
Weiphone.com将对该综述进行翻译整理并独家连载。欢迎关注。
QuickTime X
回顾Leopard时代，Apple的一些举动让人们多少感觉有些异样，譬如，Apple并没
有将基于C语言的QuickTime API移植至64位。在当时看来，此举似乎没有什么。Mac OS
X向64位平台的过渡已经历了比较长的一段时期。不难想象，或许当时并没有轮到
QuickTime。
事实证明，当初我做出的简要而不失悲观的预测是相当准确的：QuickTime“遭遇
”了Carbon的境遇。和Carbon类似，广受推崇的QuickTime API将不会过渡到64位，永
远不会。
当然，无论是QuickTime品牌还是QuickTime技术本身，绝大多数都会迈上64位的道
路，抛在身后的只有1991年就已推出的基于C语言的API。在Snow Leopard中，取代
QuickTime的则是QuickTime X，这一点或许从命名上我们就可以窥见一丝端倪。
QuickTime X中的“X”，和Mac OS X中的“X”一样，念作“ten(译注：X是罗马数
字10)”。当然，在诸多诡异的相似之处中，这只是其中一项：
旨在与先前的版本决裂；
基于原本为其他平台设计开发的技术；
与其先前的版本具有较好的兼容性；
承诺具有更好的表现和更具现代感的整体构架；
最初发布时缺乏很多重要的功能。
让我们逐一进行分析。首先，为什么要“决裂”？简单而言，QuickTime已经太老
了。1991年推出的QuickTime中，只有邮票大小的方形视频区域被看作是一项技术上的
突破(tour de force)。
18年前，最先进的Macintosh也只具备25MHz的CPU。下图可以清晰地展示这一点。
然而，不是我们不明白，这世界变化快。技术领域的飞跃注定了它的没落。对于
QuickTime这种“长寿”的、具备向后兼容性的API来说，尤为如此。
18年前，能够在个人电脑上播放视频是一项巨大的成功，也就不难理解为什么
QuickTime API能够风行如此长的时间。时光荏苒沧海桑田，18年后的今天一切都变了,
QuickTime却拖着陈旧的步履迈入了2009年，正如协同多任务处理(cooperative
multitasking)和无保护内存(unprotected memory)。(译注：计算机中，多任务/多线
程处理是指多个任务或线程分享共有的系统资源，譬如CPU。对于只具有一个CPU的计算
机来说，在任一个时间点上只能运行一个任务。多任务处理通过合理安排任务和进程解
决了这个问题。CPU从执行一个任务转移到另一个任务，这个再分配过程称为进程的关
联切换(Context Switch)。当进程切换的频率足够高时，便可造成“同时执行”的假象
。早在1960s便出现了所谓的多程序处理系统(Multiprogramming)，不同的程序成批地
加载到内存中并依次运行。然而，随着计算机的使用从批处理模式(batch mode)逐步发
展为交互模式(interactive mode)，多程序处理系统(Multiprogramming)不再适用。所
有用户都希望自己的程序高效运行，就像计算机上只有自己的程序在运行一样。于是，
所谓的分时处理(time-sharing)或协同多任务处理(cooperative multitasking)应运而
生。许多大型系统都支持协同多任务处理，如Windows 9x和早期的Leopard PowerPC。
由于协同多任务处理需要每一个线程为其他线程定期分配运行时间，因此设计不好的程
序可能会引起整个系统运行缓慢。更多信息请参考Wikipedia。内存保护(Memory
protection)是一种控制内存读取权限的方式，广泛应用于现代操作系统当中。内存保
护的目的在于防止进程中的相互影响或对操作系统本身的影响。更多信息请参考
widipedia。)
最初为iPhone编写视频处理代码时，当时最新的QuickTime 7还无法胜任此任务，
以其过于臃肿和低效率运行，并缺乏移动设备的GPU加速视频回放所必需的视频编解码
器(video codecs)。因此，Apple推出了更为高效的GPU友好型的视频回放引擎，以适应
iPhone的Ram和CPU的需要。
确实，老旧的桌面视频API需要更新了。然而Apple通过“过渡”将这些点连成了线
，而这正是Apple所惯用的伎俩。QuickTime本身已经可以在三种不同的CPU构架和三种
完全不同的操作系统上运行。
切换到64位正是另一个拐点(尽管拐点前后斜率变化不大^_^)。通过Snow Leopard
中的QTKit Objective-C Framework，Apple在QuickTime 7和QuickTime X之间划出一道
分界线。
QTKit的新秩序
QTKit并不是什么新鲜事物。QTKit诞生于2005年，为Cocoa程序提供了感觉更自然
的QuickTime 7界面。而其他的更为抽象的层面，则是向QuickTime X的过渡的关键。无
论QuickTime 7还是QuickTime X，QTKit都是面向对象的(Object-oriented)。和以往一
样，使用QTKit的程序会根据不同的需要来选择QuickTime 7或者QuickTime X。
那么，既然QuickTime X这么高级，为什么QTKit不在所有情形下使用它呢？答案就
在于，QuickTime X在最初发布时功能上有很多限制。譬如，尽管QuickTime X支持回放
，截屏和导出，但是其并不支持一些很基本的视频编缉功能。同时，QuickTime X只支
持一些比较“现代”的视频格式——基本上就是能够在iPod，iPhone和Apple TV上播放
的。当然视频编解码器(codecs)就更不要指望了，QuickTime X也不支持。
然而对于那些QuickTime X无法胜任的工作，QuickTime 7都可以完成。诸如，对视
频片断的剪切(cutting)，拷贝(copying)和粘贴(pasting)，从影片中提取独立的音轨
，播放Apple手持设备不支持的视频格式，等等。甚至通过插件来扩展QuickTime的编解
码支持，QuickTime 7也支持。
但是问题又来了。QTKit是64位应用程序使用QuickTime的唯一途径，QTKit在幕后
为QuickTime 7和QuickTime X提供了连接的纽带，而QuickTime 7是32位的——Mac OS
X并不支持“混合模式”来处理32位和64位代码——那么，如果一个64位进程需要在后
台作一些需要QuickTime 7的任务，该如何是好呢？
为了探究这个问题，我们来打开这个新的64位QuickTime Player，然后打开一个需
要QuickTime 7支持的电影文件，看看会发生什么。这个电影文件需要Sorenson Video
Codec。当然，播放得很顺利流畅。但是在Activity Monitor中搜索“QuickTime”则会
看到这一幕：
答案揭晓。当使用QTKit的64位程序需要在后台调用32位的QuickTime 7服务时，
QTKit会启用一个单独的32位QTKitServer进程来完成此任务，并将结果反馈给最初的64
位进程。如果您在使用新的QuickTime Player程序时持续观察Activity Monitor窗口，
您可以看到QTKitServer进程在需要的时候出现和结束。显然这些都是由QTKit
Framework来操纵的，应用程序本身并不需要趟这潭浑水。
或许，QuickTime 7淡出Mac OS X的舞台还有很长一段时间，但是趋势是很明显的
。随着新版本的Mac OS X的推出，QuickTime X的功能不断拓展，QuickTime 7的用武之
地将越来越小。我个人猜测，或许在Mac OS X 10.7里会支持插件，而Mac OS X 10.8中
QuickTime X可能将支持视频编缉。所有这一切将在QTKit的后面默默地发展，直到
QuickTime 7能够被完全取代。
同时，令人惊讶的是，QuickTime X中存在的一些局限性实际上却标榜了其独有的
一些优点，并且预示了QTKit API的发展方向。Apple并没有直接向开发者提供所需的在
后台使用QuickTime X的QTKit。关键之处在于QTKit API，强调了“意图(intent)”的
概念。
从QuickTime 1到QuickTime 7，对于所有的媒体资源都使用一个Movie对象(Movie
object)，其中包含组成影片文件的每个独立音轨的信息，每个音轨的采样列表(Sample
Tables)，等等。这些都是QuickTime管理和控制媒体文件所需的信息。
听起来不错对吧？然而当您意识到一切针对QuickTime媒体资源的操作都需要构建
这个繁杂的Movie对象的时候，或许您就不会觉得不错了。譬如，在QuickTime里播放一
个MP3文件，在播放前QuickTime需要为该MP3文件创建一个内部的Movie对象。不幸的是
，MP3文件很少包括复杂的音轨结构信息。通常只是简单的媒体流。QuickTime需要辛辛
苦苦地扫描并分析整个音频流来创建完整的Movie对象。
QuickTime 7和先前版本的QuickTime通过在后台扫描和分析来使这一过程不那么繁
琐。在很多基于QuickTime的播放器程序中都可以看到这种形式的进度条。下图显示了
在Leopard版的QuickTime Player上播放一个63MB的Podcast的情景。时间线的阴影部分
从左到右缓慢地充满整个区域。
尽管在点击媒体文件之后播放器差不多可以立刻开始播放，但是有必要回过头来想
想这期间究竟发生了什么。QuickTime正在创建适合其一切操作的Movie对象：编辑，音
轨提取或添加，导出，等等等等。但是，如果您并不想搞那么多飞机只想简单地播放这
个文件呢？
麻烦之处在于，QuickTime 7 API缺乏用来表达此类意图的方式。您无法跟
QuickTime 7发号施令：“不要搞那么多飞机，我只想简简单单地播放这个文件！不要
费劲地读取并分析文件的每一个字节，当我需要编辑或者导出的时候再来做这些工作也
不迟！blah blah blah…(译注：此处略去若干美国式的碎碎念。)”
Snow Leopard中的QTKit API却真正具备了这种能力。事实上，QuickTime X可以清
晰地表达了您的意图，即，不要在后台做任何不需要的工作。而且，对于一切事先表达
的意图以外的操作，QTKit都会引发异常(raise an exception)。
这种“意图”机制同时也是QuickTime X展示的新功能的方式，例如，非同步加载
较大的文件或者非本地存储文件(包括网络状况不良的网络文件等)而不阻塞应用程序主
线程中UI的运行(译注：原文the ability to asynchronously load large or
distantly located movie files without blocking the UI running on the main
thread of the application)。
确实，从很多方面来看，登上QuickTime X的列车都是很有道理的。对于其支持的
媒体格式，在播放时QuickTime X所占用的CPU要小于QuickTime 7。同时，QuickTime X
也支持H.264回放的GPU加速技术，但是在最初推出的版本中，只支持配备NVIDIA 9400M
GPU的Mac。最终，QuickTime X也包含了期待已久的ColorSync支持。
未知因素
当然，这只是QuickTime X征程的起步，但是看起来这一切仿佛并不完美。
QuickTime引擎不支持编辑？不支持插件？发布这种功能很不完善的版本看起来好像是
件比较荒谬的事情。但是近几年来Apple对于这种方式似乎乐此不疲，那就是稳定而慎
重的进步。
和众多开发者一样，我们迫切期求一个全功能的、64位的引擎，而Apple自己却胸
中有丘壑——他们拥有Final Cut Studio。而截止到现在，它还停留在32位的阶段。所
以说，Apple在推广QuickTime X方面显得沉稳而低调。
无论如何，Apple永远不会贸然推进。Apple不会在一夜之间从一个持续发展了18年
之久的API平台上复制已成熟的功能。在很多重要的Mac OS X程序升级到完美操控QTKit
之前，Apple的步伐不会加快。
Mac OS X 10.6即所谓的Snow Leopard操作系统已正式发售。一如既往，Apple
产品光鲜的外表下凝聚了太多艰辛的劳作。ArsTechnic的John Siracusa以其独特的、
专业的、全面的视角深入翔实地体验这款最新的操作系统。
Weiphone.com将对该综述进行翻译整理并独家连载。欢迎关注。
QuickTime X
回顾Leopard时代，Apple的一些举动让人们多少感觉有些异样，譬如，Apple并没
有将基于C语言的QuickTime API移植至64位。在当时看来，此举似乎没有什么。Mac OS
X向64位平台的过渡已经历了比较长的一段时期。不难想象，或许当时并没有轮到
QuickTime。
事实证明，当初我做出的简要而不失悲观的预测是相当准确的：QuickTime“遭遇
”了Carbon的境遇。和Carbon类似，广受推崇的QuickTime API将不会过渡到64位，永
远不会。
当然，无论是QuickTime品牌还是QuickTime技术本身，绝大多数都会迈上64位的道
路，抛在身后的只有1991年就已推出的基于C语言的API。在Snow Leopard中，取代
QuickTime的则是QuickTime X，这一点或许从命名上我们就可以窥见一丝端倪。
QuickTime X中的“X”，和Mac OS X中的“X”一样，念作“ten(译注：X是罗马数
字10)”。当然，在诸多诡异的相似之处中，这只是其中一项：
旨在与先前的版本决裂；
基于原本为其他平台设计开发的技术；
与其先前的版本具有较好的兼容性；
承诺具有更好的表现和更具现代感的整体构架；
最初发布时缺乏很多重要的功能。
让我们逐一进行分析。首先，为什么要“决裂”？简单而言，QuickTime已经太老
了。1991年推出的QuickTime中，只有邮票大小的方形视频区域被看作是一项技术上的
突破(tour de force)。
18年前，最先进的Macintosh也只具备25MHz的CPU。下图可以清晰地展示这一点。
然而，不是我们不明白，这世界变化快。技术领域的飞跃注定了它的没落。对于
QuickTime这种“长寿”的、具备向后兼容性的API来说，尤为如此。
18年前，能够在个人电脑上播放视频是一项巨大的成功，也就不难理解为什么
QuickTime API能够风行如此长的时间。时光荏苒沧海桑田，18年后的今天一切都变了,
QuickTime却拖着陈旧的步履迈入了2009年，正如协同多任务处理(cooperative
multitasking)和无保护内存(unprotected memory)。(译注：计算机中，多任务/多线
程处理是指多个任务或线程分享共有的系统资源，譬如CPU。对于只具有一个CPU的计算
机来说，在任一个时间点上只能运行一个任务。多任务处理通过合理安排任务和进程解
决了这个问题。CPU从执行一个任务转移到另一个任务，这个再分配过程称为进程的关
联切换(Context Switch)。当进程切换的频率足够高时，便可造成“同时执行”的假象
。早在1960s便出现了所谓的多程序处理系统(Multiprogramming)，不同的程序成批地
加载到内存中并依次运行。然而，随着计算机的使用从批处理模式(batch mode)逐步发
展为交互模式(interactive mode)，多程序处理系统(Multiprogramming)不再适用。所
有用户都希望自己的程序高效运行，就像计算机上只有自己的程序在运行一样。于是，
所谓的分时处理(time-sharing)或协同多任务处理(cooperative multitasking)应运而
生。许多大型系统都支持协同多任务处理，如Windows 9x和早期的Leopard PowerPC。
由于协同多任务处理需要每一个线程为其他线程定期分配运行时间，因此设计不好的程
序可能会引起整个系统运行缓慢。更多信息请参考Wikipedia。内存保护(Memory
protection)是一种控制内存读取权限的方式，广泛应用于现代操作系统当中。内存保
护的目的在于防止进程中的相互影响或对操作系统本身的影响。更多信息请参考
widipedia。)
最初为iPhone编写视频处理代码时，当时最新的QuickTime 7还无法胜任此任务，
以其过于臃肿和低效率运行，并缺乏移动设备的GPU加速视频回放所必需的视频编解码
器(video codecs)。因此，Apple推出了更为高效的GPU友好型的视频回放引擎，以适应
iPhone的Ram和CPU的需要。
确实，老旧的桌面视频API需要更新了。然而Apple通过“过渡”将这些点连成了线
，而这正是Apple所惯用的伎俩。QuickTime本身已经可以在三种不同的CPU构架和三种
完全不同的操作系统上运行。
切换到64位正是另一个拐点(尽管拐点前后斜率变化不大^_^)。通过Snow Leopard
中的QTKit Objective-C Framework，Apple在QuickTime 7和QuickTime X之间划出一道
分界线。
QTKit的新秩序
QTKit并不是什么新鲜事物。QTKit诞生于2005年，为Cocoa程序提供了感觉更自然
的QuickTime 7界面。而其他的更为抽象的层面，则是向QuickTime X的过渡的关键。无
论QuickTime 7还是QuickTime X，QTKit都是面向对象的(Object-oriented)。和以往一
样，使用QTKit的程序会根据不同的需要来选择QuickTime 7或者QuickTime X。
那么，既然QuickTime X这么高级，为什么QTKit不在所有情形下使用它呢？答案就
在于，QuickTime X在最初发布时功能上有很多限制。譬如，尽管QuickTime X支持回放
，截屏和导出，但是其并不支持一些很基本的视频编缉功能。同时，QuickTime X只支
持一些比较“现代”的视频格式——基本上就是能够在iPod，iPhone和Apple TV上播放
的。当然视频编解码器(codecs)就更不要指望了，QuickTime X也不支持。
然而对于那些QuickTime X无法胜任的工作，QuickTime 7都可以完成。诸如，对视
频片断的剪切(cutting)，拷贝(copying)和粘贴(pasting)，从影片中提取独立的音轨
，播放Apple手持设备不支持的视频格式，等等。甚至通过插件来扩展QuickTime的编解
码支持，QuickTime 7也支持。
但是问题又来了。QTKit是64位应用程序使用QuickTime的唯一途径，QTKit在幕后
为QuickTime 7和QuickTime X提供了连接的纽带，而QuickTime 7是32位的——Mac OS
X并不支持“混合模式”来处理32位和64位代码——那么，如果一个64位进程需要在后
台作一些需要QuickTime 7的任务，该如何是好呢？
为了探究这个问题，我们来打开这个新的64位QuickTime Player，然后打开一个需
要QuickTime 7支持的电影文件，看看会发生什么。这个电影文件需要Sorenson Video
Codec。当然，播放得很顺利流畅。但是在Activity Monitor中搜索“QuickTime”则会
看到这一幕：
答案揭晓。当使用QTKit的64位程序需要在后台调用32位的QuickTime 7服务时，
QTKit会启用一个单独的32位QTKitServer进程来完成此任务，并将结果反馈给最初的64
位进程。如果您在使用新的QuickTime Player程序时持续观察Activity Monitor窗口，
您可以看到QTKitServer进程在需要的时候出现和结束。显然这些都是由QTKit
Framework来操纵的，应用程序本身并不需要趟这潭浑水。
或许，QuickTime 7淡出Mac OS X的舞台还有很长一段时间，但是趋势是很明显的
。随着新版本的Mac OS X的推出，QuickTime X的功能不断拓展，QuickTime 7的用武之
地将越来越小。我个人猜测，或许在Mac OS X 10.7里会支持插件，而Mac OS X 10.8中
QuickTime X可能将支持视频编缉。所有这一切将在QTKit的后面默默地发展，直到
QuickTime 7能够被完全取代。
同时，令人惊讶的是，QuickTime X中存在的一些局限性实际上却标榜了其独有的
一些优点，并且预示了QTKit API的发展方向。Apple并没有直接向开发者提供所需的在
后台使用QuickTime X的QTKit。关键之处在于QTKit API，强调了“意图(intent)”的
概念。
从QuickTime 1到QuickTime 7，对于所有的媒体资源都使用一个Movie对象(Movie
object)，其中包含组成影片文件的每个独立音轨的信息，每个音轨的采样列表(Sample
Tables)，等等。这些都是QuickTime管理和控制媒体文件所需的信息。
听起来不错对吧？然而当您意识到一切针对QuickTime媒体资源的操作都需要构建
这个繁杂的Movie对象的时候，或许您就不会觉得不错了。譬如，在QuickTime里播放一
个MP3文件，在播放前QuickTime需要为该MP3文件创建一个内部的Movie对象。不幸的是
，MP3文件很少包括复杂的音轨结构信息。通常只是简单的媒体流。QuickTime需要辛辛
苦苦地扫描并分析整个音频流来创建完整的Movie对象。
QuickTime 7和先前版本的QuickTime通过在后台扫描和分析来使这一过程不那么繁
琐。在很多基于QuickTime的播放器程序中都可以看到这种形式的进度条。下图显示了
在Leopard版的QuickTime Player上播放一个63MB的Podcast的情景。时间线的阴影部分
从左到右缓慢地充满整个区域。
尽管在点击媒体文件之后播放器差不多可以立刻开始播放，但是有必要回过头来想
想这期间究竟发生了什么。QuickTime正在创建适合其一切操作的Movie对象：编辑，音
轨提取或添加，导出，等等等等。但是，如果您并不想搞那么多飞机只想简单地播放这
个文件呢？
麻烦之处在于，QuickTime 7 API缺乏用来表达此类意图的方式。您无法跟
QuickTime 7发号施令：“不要搞那么多飞机，我只想简简单单地播放这个文件！不要
费劲地读取并分析文件的每一个字节，当我需要编辑或者导出的时候再来做这些工作也
不迟！blah blah blah…(译注：此处略去若干美国式的碎碎念。)”
Snow Leopard中的QTKit API却真正具备了这种能力。事实上，QuickTime X可以清
晰地表达了您的意图，即，不要在后台做任何不需要的工作。而且，对于一切事先表达
的意图以外的操作，QTKit都会引发异常(raise an exception)。
这种“意图”机制同时也是QuickTime X展示的新功能的方式，例如，非同步加载
较大的文件或者非本地存储文件(包括网络状况不良的网络文件等)而不阻塞应用程序主
线程中UI的运行(译注：原文the ability to asynchronously load large or
distantly located movie files without blocking the UI running on the main
thread of the application)。
确实，从很多方面来看，登上QuickTime X的列车都是很有道理的。对于其支持的
媒体格式，在播放时QuickTime X所占用的CPU要小于QuickTime 7。同时，QuickTime X
也支持H.264回放的GPU加速技术，但是在最初推出的版本中，只支持配备NVIDIA 9400M
GPU的Mac。最终，QuickTime X也包含了期待已久的ColorSync支持。
未知因素
当然，这只是QuickTime X征程的起步，但是看起来这一切仿佛并不完美。
QuickTime引擎不支持编辑？不支持插件？发布这种功能很不完善的版本看起来好像是
件比较荒谬的事情。但是近几年来Apple对于这种方式似乎乐此不疲，那就是稳定而慎
重的进步。
和众多开发者一样，我们迫切期求一个全功能的、64位的引擎，而Apple自己却胸
中有丘壑——他们拥有Final Cut Studio。而截止到现在，它还停留在32位的阶段。所
以说，Apple在推广QuickTime X方面显得沉稳而低调。
无论如何，Apple永远不会贸然推进。Apple不会在一夜之间从一个持续发展了18年
之久的API平台上复制已成熟的功能。在很多重要的Mac OS X程序升级到完美操控QTKit
之前，Apple的步伐不会加快。