应用程序打包

在Mac OS X中，一个典型的应用程序不是单一的可执行文件，而是一个包括单个或多个可执行二进制代码的文件包。一个应用程序既是一种类型的束--一个在系统中以分层结构存放可执行文件以及支持该代码资源的目录。同时应用程序也是一个文件包，一个Finder以文件形式呈现给用户的目录。

设计应用程序包（application package）的起因源自于认识到一个运行中的应用程序不仅仅只是已加载的可执行代码。这种内部结构具有以下优点：易于安装和卸载；包含多种本地化版本；支持多种体系结构和卷格式；单一的应用程序不用改动即可在Mac OS 9 和 Mac OS X上运行,并有良好的兼容性。

尽管应用程序在结构上是一个束，但一些束的组件主要（有时是仅仅）存在于应用程序中。用户很容易将帮助信息、参数预置、助理和插件等当作应用程序资源。虽然从技术上来说，没有什么理由可阻碍这些资源隶属于一个可加载的束，但往往都还是将它们与应用程序联系在一起。本章将重点介绍如何将这些资源打包在一个应用程序束中的方法。关于束的概括性描述，请参见“束”一章。

 

一个应用程序就是一个束

在Mac OS X中，应用程序被打包成一种类型的束。正如“束”一章中所定义的那样，束是指一个包含可执行代码以及支持该代码资源的目录。应用程序束以及可加载束（例如插件）都是文件包，是Finder以单一文件形式呈现给用户的目录。应用程序、框架、插件等类型的束和其它动态可加载代码和资源之间的主要区别在于可执行性。可执行应用程序一般是"自给自足的"的二进制代码，用户通常可通过双击鼠标从Finder中将其启动。各种应用程序可以包含（也可以不包含）二级束，例如插件，但总是需要包含它们的主束。

采用束带来了许多好处，有些是特别针对应用程序的，而有些则对大部分束都适用：

• 相同的(Carbon)应用程序束未作改动即可在Mac OS 9 和 Mac OS X上运行。
• 应用程序可以包括不同的本地化版本。应用程序可以自动地显示符合用户首选语言的本地化资源组（包括应用程序本身的文件名）。此外，您还可以在应用程序包中增加一个新的本地化版本，当用户重新启动该应用程序后就可以显示那些适合首选语言的资源。
• 客户端计算机可以在服务器上运行应用程序。
• 客户可以方便地通过网站下载或通过电子邮件得到应用程序。
• 应用程序易于安装和卸载，安装时用户只需用鼠标将应用程序包拖曳到某个卷上，卸载时则只需将其拖曳到垃圾箱里。（这一特性并不排斥进行更加复杂的安装。）
• 由于应用程序是文件包，所以用户不能通过移除或改变其重要的组成部分来破坏它，但可以改变应用程序的名字，这对应用程序并无影响。
• 应用程序可以支持多种体系结构和多种卷格式。

束的分层内部结构使得这些特性的实现成为可能。应用程序的不同片段位于应用程序包内特定的位置处。应用程序片段的这种标准内部结构可以使操作系统的相关部分，如Finder以及系统的资源查询和代码装载机制等发挥功能。例如，适用多平台（Mac OS 9 和 Mac OS X）的可执行文件被放置在具有标准名称的独立子目录下。对本地化资源、插件和私有及版本化框架也作同样处理。

Finder、Sherlock、导航服务和其它苹果所提供的用于浏览和检查文件系统的应用程序和服务都并不会进入到应用程序包中。当启动应用程序时，Finder将对双击应用程序包这一动作做出响应。 当它们和其它束一同运行时，苹果的开发工具支持新建应用程序包。

关于束的其它一般信息，请参见“束”一章。关于Finder的进一步信息及其涉及应用程序的作用，请参见“The Finder”一章。

 

应用程序框架、库和帮助

应用程序有时会带有一些不会被编译入可执行应用程序的附助代码模块，这些附助代码的表现形式可以是框架、共享库（CFM或其它）、插件、帮助应用程序或一些其它类型的软件。

这样来划分应用程序代码有很多理由。其中的一个原因是效率：例如，软件开发者可能有一批像客户文件阅读器这样的应用程序，它们全部依赖于同一框架或利用同一个帮助应用程序。另一个原因在于性能：应用程序可以决定推迟加载一个模块（如插件）直到用户要求使用它为止。换言之，应用程序可以在最初阶段就被设计成可扩展的。

为保证应用程序的运行或至少保证其完整性，都需要应用程序包中的框架和共享库。然而，应用程序包中并不包括苹果所提供的与应用程序相链接的框架，这些框架被安装在标准的系统位置(/System/Library/Frameworks)。安装程序将不会在应用程序包中删除这些框架或将它们移至别处。

应用程序束有两个用于存放各类附助代码的目录：

Frameworks/
PlugIns/ 

本节的余下部分将说明前三个目录的用途以及与它们有关的问题。关于PlugIns 这个目录的描述，请参见“应用程序和可加载束”。

私有框架

Frameworks目录包含与应用程序紧密捆绑的框架（或共享库）。这些框架是应用程序私有的，只有应用程序自身才能使用这个目录中的框架，而包括处于同一"批"或源自同一开发者在内的其它应用程序都不能使用。这些私有框架的动态共享库不能被修改，也不会被任何其它版本所替代，即使是对操作系统有效的较新版本也不行。

列表 6-1 图解说明了一个典型的私有框架是如何被存储于应用程序束中的。

列表 6-1 应用程序私有框架的位置

FantasticApp.app/ 
     Contents/ 
          Info-macos.plist 
          MacOS/ 
          Resources/ 
          Frameworks/ 
               GoodStuff.framework/ 
          PlugIns/ 
          SharedSupport/ 

 

应用程序和可加载束

可加载束包含了应用程序在运行时可动态加载的代码和编程资源。插件是最常见的一类可加载束，另外还有如“Interface Builder调色板”等其它类型的可加载束。可加载束与框架有些不同，它可以与应用程序有着稍许不同的关系。

可加载束与应用程序包一样都是束。因此，它们可以包含应用程序可含有的所有东西，例如私有框架和其它附助代码，包括其它插件及其它可加载束。（另一方面，在其它差别中，框架是具有一个不同内部结构的“版本化”的束。关于框架的更多信息，请参见“框架”一章。）

根据对应用程序的重要程度，可将插件和其它可加载模块分成三类：

• 应用程序运行所必需要的插件或可加载模块。
• 对于程序执行不是必需的，但由于用户通常需要使用它们（例如工具板）而被认为是应用程序一部分的插件或可加载模块。
• 对上述两个标准都不满足，但提供了一些附加功能（经常由第三方开发者提供）的插件或可加载模块。

插件和其它满足上述前两条标准的可加载束应该被打包入应用程序束的PlugIns目录中。它们应该总与应用程序打包在一起，这样当用户将应用程序移动到另一个位置时它们也会随着移动。如果可加载束属于上述第三种类别，用户通常是将其安装在登录用户的本地或远程home目录中的Library/Application Support目录内。系统管理员或专家级用户可将这种可加载束安装到本地系统或网络域的Library/Application Support目录中，以便更广泛地加以利用。

无论插件或可加载束被存放于何处，应用程序都要负责提供一些人机界面机制，供用户以文件形式（而不是目录形式）选择它们。例如，应用程序可以显示一个列出所有可加载插件的对话框。

 

应用程序中的用户资源

一个应用程序可以与各种资源打包在一起。这些资源可以是那些与应用程序的执行代码紧密关联的资源，如声音文件和本地化字符串，以及那些更“外部”的资源，如应用程序帮助、参数预置、素材库等。资源通常都存放在应用程序束的Resources目录中。

然而，由于某些原因，应用程序资源也可能不存放在应用程序包中。分离存放的一个原因是为了使应用程序能在网络启动环境下运行。另一个原因是为了便于在文件系统中存取资源，以及将那些由第三方提供的资源与由应用程序开发人员提供的资源相分离。下面的部分将介绍几类资源的首选存储位置。

 

应用程序帮助

在Mac OS X中， 应用程序Help Viewer（苹果帮助产品的一部分）给出了应用程序帮助信息以及更为常规的帮助。用户应该将应用程序帮助文件存放在应用程序Resource目录的适当位置处。您可将文件放入“帮助手册”（也是Mac OS 9中的一种用于帮助的标准格式）。通过对帮助手册的内容（文本和图像）进行本地化，并将它们存放在应用程序束Resource目录的lproj目录中使帮助手册国际化。其中的文本文件必须满足HTML 3.2格式，另外还要符合苹果帮助手册的规范。关于准备和索引帮助文件的使用说明，请参看“Inside Carbon: Providing User Assistance With Apple Help”（“深入Carbon：苹果帮助为用户提供助手”）。

应用程序的信息属性列表（Info.plist）必须包含一个名为CFBundleHelpBookFolder的键，该键的值通常是一个字符串，由它指定应用程序Resources目录中的帮助手册目录名。如果名为CFBundleHelpBookName的键也存在于信息属性列表中，它的键值字符串是帮助手册的苹果标题（AppleTitle）标签，当用户选定帮助菜单选项时，Help Viewer就可以自动地处理帮助手册的显示。请注意，不管是否本地化，每个帮助手册目录名都必须与CFBundleHelpBookFolder的键值相一致，即目录名不应本地化。您的应用程序也可以控制怎样打开和显示帮助文件。苹果帮助应用编程接口（Apple Help APIs）提供给应用程序几个与帮助有关的选项，例如使用标题来打开帮助手册、使用完整的目录路径来打开帮助文件，以及进行对特定术语或关键词（anchor）的查询等。更多的信息请参看“Inside Carbon: Providing User Assistance With Apple Help”（“深入Carbon：苹果帮助为用户提供助手”）

尽管苹果大力推荐您将应用程序帮助放入应用程序束中，但您也可以将应用程序帮助和其它更常规性的帮助都放在应用程序包外面。这样的帮助应该被安置在一个用于存放第三方帮助的标准位置处，包括/Library/Documentation/Help和用户个人目录下的Library/Documentation/Help。当用户从Finder中启动“帮助中心”时，Help Viewer会扫描这些位置并显示一个应用程序帮助的链接。如果您的应用程序帮助安置在一个存放帮助的标准位置处，那么您不需要指定任何应用程序信息属性列表中的特殊键值对，Help Viewer会自动处理。

 

应用程序参数预置

在应用程序安装时，应用程序通常采用一套缺省的预置参数，用户也可以根据自己的工作习惯来改变这些预置参数。任何应用程序都有部分代码专用于显示预置参数的选项、接受用户选择和将这些选择写入参数预置系统。（参看“软件配置”一章中的“参数预置系统”）

您的应用程序不会将用户做出的选择写进应用程序包中。预置参数被存放在用户登录帐户（本地机或网络）的Library/Preferences目录中，或者被存放在本地机或网络域中的同一位置。您不应将预置数据直接写进这些位置，而应使用由Core Foundation参数预置服务 (CFPreferences)提供的应用编程接口，或对于Cocoa应用程序，则可使用NSUserDefaults。将用户预置和应用程序包相分离的部分原因是可使应用程序在网络启动环境中运行。

 

文档资源

像文字处理软件、电子数据表软件、绘图软件等以文档为中心的应用程序经常包括一些资源，如模板、素材库、教程及助理等。这些资源既可被打包到应用程序束中，也可被打包到应用程序包以外的位置。我们通常采用与存放插件和其它可加载束相同的经验方法来决定将这种资源放在哪里。（参见 “应用程序和可加载束”）：

• 如果这些资源是由该应用程序的开发者所提供的，它们应被存放在应用程序束的SharedSupport目录中。
• 如果这些资源是由第三方所提供的，则它们应被存放在应用程序资源的标准目录位置内，例如：用户个人目录中的Library/Application Support 文件夹中。

当使用可加载束时，应用程序应该提供某种资源浏览器，用于显示应用程序资源（包括应用程序包内部和外部的），并允许用户从中进行选择。但资源浏览器不应显露应用程序包的内部结构。

 

[ 返回 ]