21 September 2011
AIR 3 (目前是 Adobe Labs 上的发布候选版) 具有新的用于移动和桌面设备的AIR运行时和AIR应用的部署与安装选项。
新的绑定运行时 (captive runtime ) 选项支持在不单独安装AIR运行时的条件下将AIR应用安装在Android设备上。
在桌面系统中,新的自定义安装功能可以在不需要管理员权限的情况下完成包括直接运行(run in place)、安装以及更新等在内的AIR应用开发工作。
综上所述,这两个特色意味着针对AIR开发者的安装与部署选项得到了显著改善。
在AIR 3之前,AIR的运行时一般需要独立安装,有别于那些依赖其运行的各种应用。在桌面系统中,一个统一的安装UI看似就可以完成一次安装,但实际上并不是这 样。例如,当完成这样一个安装过程后,AIR可以单独地被从计算机上卸载,却使那些留下的依赖其运行的应用无法使用。
当开始用AIR 3时,发布者可以选择将运行时的一份副本绑定在他们的应用安装程序包中。这份副本可专门为相关的应用所使用,并永远作为应用本身的一部分被安装或卸载。
绑定运行时副本有很多好处:
与共享安装不同,绑定的运行时只有在应用本身被更新的时候才会被更新。尽管Adobe在升级更新AIR时尽可能地完善其兼容性,但这种方法还是降低了AIR在更新时破坏已部署完毕的应用的风险。
这很大程度上是针对桌面平台而言的,通过统一安装UI,在Android上没有统一安装UI。通过绑定运行时免去了用户下载并将AIR作为一个独立的应用来安装的麻烦。
当一个Android应用被部署给多个应用商店(比如,Google Android Market和Amazon App Store),必须在必要时将用户转到同一个商店下载AIR。为了实现上述操作,必须给每一个应用商店上传一个配置有正确下载URL的应用副本。由于免去了下载的需求,也就不需要制作自定义安装包了。
绑定运行时选项对需要在桌面平台上自定义安装的应用是必须的。下面具体展开解释:
使用绑定运行时必须知道它有两个缺点:
由于一份完整的运行时被包含在你的应用中,应用程序包的尺寸会相应地增加。
当应用在设备上使用共享的AIR安装时,他们可以依靠AIR的自动更新机制来确保运行时保持最新。但是自动更新机制并不适用于绑定运行时。如果你使用绑定 运行时,每当需要采用新版本的AIR时,你都需要升级并重新封装你的应用。因为新发布的版本总是包括安全性更新,我们鼓励应用开发者在AIR发布更新时及 时更新他们的应用。
要创建一个带有绑定运行时的Android应用,只需在adt packaging命令中将你的目标(target)选项从apk改成
apk to apk-captive-runtime :
adt -package -target apk-captive-runtime ...
注意:要在iOS中使用AIR,绑定运行时是唯一可用的选择。由于iOS不支持共享运行时模式,所以绑定模式是该平台唯一的选择。
要在桌面系统的应用中使用绑定运行时,要用到将在下一个部分介绍的自定义安装 选项。
最初AIR应用都被部署在AIR文件中,AIR文件是基于ZIP格式的跨平台文件包。在AIR 2中,开发者可以选择使用本地安装包来部署他们的应用:在Windows中是一个自解压可执行程序,而在Mac OS X上是一个DMG文件。这两种选项涵盖了许多种使用情况,但不是所有的。
在AIR 3中,开发者还可以选择针对他们的应用创建自己的安装程序包。这些安装程序包类似于在AIR 2中加入的本地安装包,它们会生成一个以extended desktop方式运行并能使用NativeProcess API和本地扩展的应用。只是这些安装程序包是由AIR封包工具adt直接生成的。
adt通过创建安装包创建过程所需的一系列文件来支持这个新选项的。借鉴Mac OS X中的术语,我们称这一系列文件为一“卷”(bundle),让它作为一个新的adt目标:
adt -package -target bundle ...
生成的一系列文件是一个完整的AIR应用,包括绑定的AIR运行时的一份副本。然后就可以用不同的方法封包为一个安装程序包了。
最简单的方法不需要任何额外的操作。因为AIR应用卷不需要额外的设置,应用可以直接运行。在Mac OS X上,应用卷本身就是一个程序包,只需双击就能运行该应用。(在Finder中,它会显示为一个独立的文件,与其他所有Mac OS X应用一样。)仍然可以通过将其拖放到应用程序文件夹的方式来安装它。
在Windows中,通过运行文件卷根目录中的可执行文件来执行应用。你不能转移与其它文件相关联的可执行文件,但是你可以将目录中的其它文件标记为隐藏来简化该应用在浏览器中的视图便于他人浏览。
对于Mac OS X和Windows,这种功能可用来创建能在CD,闪存或者其他媒介上直接运行的应用。你需要做的全部就是保持文件目录和文件权限的完整。
注意绑定运行时是完成上述所有工作的关键:因为它被嵌入在应用中,所以它总是可用的。不需要考虑单独安装、下载运行时库,或确保它是最新的。
尽管直接运行很有用,但有时在安装部署时采用一些封包或是逻辑控制却是很适宜的。
在Mac OS X中,通常使用发布应用镜像文件时用到的DMG文件形式。需要指出的是,除了其它方面的考虑,这样做的原因之一是即使当应用被复制到非Mac OS X系统上时,组成应用的目录结构、符号链接(symbolic link)以及文件权限都会被保留下来。这就是DMG文件为何被用作发布Mac OS X应用程序的原因。
你可以通过磁盘工具手动建立一个DMG文件,或者使用hdiutil命令行工具编写一个。不管用哪种方法,只要将你的应用卷包含在你的DMG文件中就行了。
在Windows中,应用程序通常以MSI文件的形式发布,可以通过Windows Installer安装和管理它。你可以使用各种各样的商业工具,例如InstallShield,来建立一个MSI文件。一个叫做WiX的开源 Windows Installer XML工具集也是值得一试的选择。
注意: 你可以 在封包前修改卷中的内容。当然,某些改动会使应用遭到破坏。比如,如果你移除了主SWF文件,应用就无法运行。而另一方面,当你想在Mac OS X中修改一个应用的Info.plist条目或者做其它类似的调整时,这就非常的有用了。
有这样一些情况,安装时要处理更多的需求:可能要同时安装另一份软件,修改注册表项或者安装服务等等。AIR安装卷又可以与平台安装技术结合起来。
在Mac OS X中,高级安装可以由PackageMaker工具来创建。它支持同时安装多份软件、在安装时运行脚本等等。AIR应用可以被直接整合进包含其它文件和软件的更大的程序包中。或者,他们可以被装进各自的程序包中,然后一次完成多程序包安装。
在Windows中,其它的文件和软件可以被整合到应用的MSI文件中。也可以把AIR应用放在MSI merge modules (MSM)中。MSM文件可以被发布给其他团队建立产品安装包并合并进最终的MSI程序包中。最后,可以通过一个叫“bootstrapper”的程序来 实现单次安装多个MSI文件,甚至是自定义安装逻辑控制。“Bootstrapper”是一个使用Windows Installer来安装程序的应用程序。
设计一个安装程序时,你可以选择是否需要管理员权限。比如,在Mac OS X中的拖放安装就不需要特殊的权限,用户可以随时将应用复制到他们拥有相应权限的应用文件夹中。另一方面,如果必须要在Windows注册表中针对计算机的部分写入注册表键值,那么就需要管理员权限来安装这个应用。
AIR直接支持这两种安装程序的方式,AIR文件和本地安装程序总是需要管理员权限。采取这个设计上的决策部分原因是为了简化AIR安装的实施:如果拥有管理员权限可以更改注册表什么的,那么安装就是可行的。还有一个原因,也是许多企业所期望的,就是:管理员可以通过设置权限来控制软件的安装。
同样,有些时候我们希望甚至是需要在没有管理员权限的条件下就可以进行安装。现在可以通过自定义安装程序来实现它,你只需编制一个只需正常用户权限就可以运行的安装程序。实际这很容易实现,只要通过复制安装到一个可以写入的位置(也就是用户自己的文件夹)就行了。假如你要配置一个更复杂的安装程序,你必须要记得在安装过程添加某个操作很有可能会重新引入对管理员权限的要求。
由于封装成卷的AIR应用不需要额外的安装时支持,这可能会导致两个需要改动注册表项的功能无法工作:文件扩展名注册和开机启动项注册。
如果你的应用程序需要这些功能,可以通过向自建的安装程序中添加适当的设置来获得等效的功能(尽管不是内置的API支持)。多数的安装程序创建工具都会专门支持这几项功能的,或者至少有一种允许创建这些功能所需要的注册表项的逃逸机制(escape mechanism)存在。可以在微软的文档中查阅需要添加的注册表项。
你同样可以将你的应用与系统以不被AIR创建的安装程序所支持的方式整合起来。例如,你的安装程序可以将一个自定义的URL表注册到你的应用中,若换作AIR这是不能实现的。(当一个应用被以这种方式调用时,它会收到一个InvokeEvent ,那么你的安装程序通常就会需要管理员权限。
如上所述,考虑下你该把这样的设置写进注册表的哪个部分。如果你把它们写进针对机器的部分(HKLM)而不是当前用户部分(HKCU),那么你的安装程序通常就会需要管理员权限。
当使用卷来配置你的应用时,你有责任更新你的应用 及其所包含的AIR运行时副本。由于AIR的更新总是会增强它的安全性,我们鼓励你每当AIR本身更新的时候都更新并重新封装你的应用。
注意这并不一定意味着你需要使用自己的自动更新机制。如果你使用一个商业工具来创建你的安装程序,它可能包含有可用的自动更新机制。另一方面,如果你确实需要编写你自己的更新机制,你需要找到相应的URL流、文件以及本地进程API集。
注意: AIR仍然给部署为AIR文件的应用提供自动更新功能。但是,自动更新机制必须在事先知道安装机制已经启用的情况才能发挥作用。但是如果选择自定义安装就意味着AIR无法获取上述信息,因此这两种方法依然是不兼容的。
当考虑是否使用自定义安装选项时,回顾前面所讲到的绑定运行时方法的利与弊。使用自定义安装就需要使用运行时绑定,而AIR文件和本地安装都可以使用共享运行时安装。
如果你要利用一个现有应用的自定义安装程序,你还需要考虑如何在两种方式之间转换。这是目前以AIR文件发布的应用所面临的主要问题:它们可以下载一个自定义安装程序,却不能自动运行它。在大多数这样的事例中,最好再以AIR文件的方式发布至少一个或多个更新,其中包含必要的逻辑判定和UI来指导用户完成转换。(对于使用本地安装的应用来说问题就不太严重,因为那些应用可以直接运行一个经由本地进程API下载的安装程序。)
最后,想想你的用户的初始安装体验。当使用AIR文件时,你可以用AIR的基于浏览器的API (“无缝安装(badge install)”)来直接从网页中启动安装。这项功能对于本地安装和自定义安装是不可用的,它们通常需要使用常规的浏览器下载机制。并且,不像AIR文 件和本地安装,基于浏览器的API不能检测或者启动一个通过自定义安装方式安装的应用。
AIR包含对创建应用安装的内置支持。经过最近的几个版本,AIR已经可以为移动设备创建安装包并为桌面系统增加了新的安装方式。
使用新的绑定运行时功能,应用中可以包含一份自身的AIR运行时。不说其它的好处,这样就不需要单独安装AIR,并且可以在桌面系统中创建自定义安装程序包了。
使用新的自定义安装选项,开发者可以为桌面应用编制它们自身的安装程序。它涵盖下至在闪存上直接运行或者通过复制运行,上至包括注册表操作、自定义安装脚本以及嵌入并行安装顺序等从简单到复杂的各种情况。
综上所述,这些选项为AIR应用的安装以及部署带来了近乎无限的灵活性。
本产品经 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 许可。Adobe 提供超出该许可范围、与本产品包含的代码示例相关的权限。
Tutorials and samples |
AIR blogs |
More |
AIR Cookbooks |
More |