简化 Flex 项目环境

简化 Flex 项目环境
Company: Adobe

作为一名要加入新项目的软件工程师，我希望可以快速获得代码，然后构建代码并运行应用程序。

我不希望必须要浏览一个复杂的建立程序，阅读无数指引文件，或者学习应用程序的详细细节，然后才能启动。

另外，一旦环境建立起来并开始运行，我希望我可以始终：

提交所有修正文件，即便是项目配置文件（如，.project、.actionScriptProperties 和 .flexProperties 文件），同时不破坏其他人的环境。
检查出所有引入文件，并与存储库保持完全同步，而无需重新配置本地环境或者选择性地检查文件。
当采用 Flash Builder — 和 Eclipse（通常来讲）进行工作时，这个简单的任务可能会变得非常具挑战性。

在本指南中，您将会了解到很多有用的小建议，可以帮助您和您的团队最大效率地配置项目，降低建立和维护成本，并快速建立和运行新的开发程序。

要求
为了充分利用本文，您需要下列软件和文件：

Flash Builder 4

试用
购买
必备知识

需要了解 Flex 知识。

关于作者

Xavi 是 Adobe Professional Services 欧洲、中东和非洲区的技术建筑师。


本作品通过 Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License 许可。

避免配置文件中的硬编码路径
问题的一个常见来源是项目配置文件中的绝对路径。

可用通过多种方式在不注意的情况下创建一个绝对路径引用。

通常当您创建链接文件夹时，会将一个绝对路径引用添加到 .project 配置文件中；例如：

<linkedresources>
    <link />
    <name>linkedFolder</name>
    <type>2</type>      
    <br />       
    <location>/Users/youUser/path/to/hardcoded/folder</location>
</linkedresources>
当您链接一个存储在项目或工作空间文件夹层级之外的 SWC 库时，同样也会硬编码绝对路径。

在本案例中，.actionScriptProperties 文件将包含一个引用；例如：

<librarypathentry kind="3" linktype="1" path="/Users/youUser/path/to/hardcoded/lib.swc" usedefaultlinktype="false"></librarypathentry>
使用链接资源

那么我们该如何避免硬编码路径呢？

答案就是采用链接资源。

链接资源只不过是一个存储在 Eclipse 工作空间级别的路径变量。

您可以通过以下步骤确定定制变量：Window > 引用 > 常规 > 工作空间 > 链接资源。

如果您在此确定了一个 CUSTOM_PATH 变量，那么您就可以在项目配置文件中使用该变量；例如：

<linkedresources>   
    <link />      
    <name>linkedFolder</name>  
    <type>2</type>    
    <location><b>CUSTOM_PATH</b>/folder</location> 
</linkedresources>
<librarypathentry kind="3" linktype="1" path="${CUSTOM_PATH}/lib.swc" usedefaultlinktype="false"></librarypathentry>
请注意：.project 和 .actionScriptProperties 文件中的语法略有不同。

在 .project 文件中，您仅使用名称（CUSTOM_PATH）引用路径变量，而在 .actionScriptProperties 文件中，您还需要一个美元标志和大括号符号（${CUSTOM_PATH}）。

使用 ${flexlib} 链接框架库

在某些情况下，您可能希望将一个或多个 Flex SDK 库整个链接到您的项目中。

这种情况的一个典型例子就是使用自动化库进行工作时，其中您必须包括 automation.swc、automation_dmv.swc 和 automation_agent.swc。

这些 SWC 通常在您的项目所使用的 Flex SDK 的 libs 文件夹中。

为了将它们包含并链接到您的项目中，您通常需要将下列语句添加到“额外编译器参数”设置中：

-include-libraries /path/to/SDK3.0/libs/automation.swc
/path/to/SDK3.0/libs/automation_dmv.swc
/path/to/SDK3.0/libs/automation_agent.swc
如您所看到的，至 SDK 的路径再次被硬编码。

这在整个开发程序环境中不是容易的。

而且，如果您转至一个不同的 SDK 版本，这些链接库非常有可能不能随之更新，从而创建任意冲突和行为。

对此的一个可行解决方案是使用专门的 ${flexlib} 记号，这个记号会始终指向为项目配置的 SDK 文件夹。

如果您为了该项目或者您的工作空间而改变 SDK，您可以确定它也随之更新。

然后您可以使用：

-include-libraries ${flexlib}/libs/automation.swc
${flexlib}/libs/automation_dmv.swc ${flexlib}/libs/automation_agent.swc
将您的 bin 文件夹链接至一个网络文件夹

当您的应用程序需要将多个环境作为目标时，有一个很好的方法。

您可以为 build 目录确定一个链接资源，并指定一个共享网络驱动器。

然后，这个路径就象征性地链接至您在所有不同环境（开发、测试、试制和生产等）下的应用程序服务器。

这样，当您从您的 IDE 中构建，就可以立刻在所有这些环境中运行应用程序。

如果服务层团队需要重新启动一个特定的环境，您可以转至另一个环境继续开发。

缺点是拷贝至一个网络驱动器而非本地磁盘时，build 可能减速，但是如果一个大型项目被很好地构建到单独的库和模块或分应用程序中，这不是太明显。

配置编译器设置
这里有几个编辑器选项，您可以对其进行配置，简化您的 Flex 4 开发。

明确指定您的项目使用的 SDK 版本。

当一个项目没有与某一版本相关联时，Flash Builder 允许开发人员指定一个默认的 SDK 版本（Window > 引用 > Flash Builder > 已安装的 Flex SDK）。

如果项目没有指定一个特定的 SDK，将使用默认的 SDK。

下列情况非常常见：同一个团队里的不同开发人员安装不同的 SDK 版本，或者两个开发人员配置不同的默认 SDK。

如果您的项目被配置成使用默认 SDK，就意味着，不同的开发人员可能采用不同的 SDK 版本编译项目，结果经常会导致非常难以调试和隔离的意外行为和不可预知的错误。

如果您的项目包含 SDK 的动态补丁类，这些问题的发生几率将会大大提高。

设想开发人员 1 为 SDK 3.1 的 ClassA 打补丁。

开发人员 2 没有意识到这种情况，采用 SDK 3.0 编译项目。

因为 ClassA 是动态补丁类，因此将使用它，但是使用的框架类的剩余部分将来自 SDK 3.0。

发生这种情况时，您可能会遇到各种各样的运行时间错误和令人不快的行为。

为了避免这种情况，可以明确指定一个 SDK 版本：打开项目属性，选择“Flex 编译器”，然后选择“使用一个指定的 SDK”。

请勿在您的库中链接任何 SDK 类

无论您是一名库开发人员还是一个使用第三方库的开发人员，确认您使用的或产生的库没有链接至任何指定的 SDK 类非常重要。

如果这种情况是不可避免的，请确保您理解它可能对您的项目产生的影响。

设想您正在使用 SDK 3.5 研发一个 Flex 项目。

为了加速研发过程，您决定使用一个名为 badLibrary.swc 的第三方库。

该库是采用 SDK 3.1 创建的，因为某些原因在最终 SWC 中采用 “Merge Into Code” 选项（如，UIComponent 及其依赖关系）对不同的 SDK 类进行了链接。

当您在项目中使用 badLibrary.swc 时，因为编译优先，将使用在类途径 SWC 文件中发现的所有类，而非来自挑选的 Flex SDK 中的类。

这就意味着，您的项目将使用来自 SDK 3.1 （采用 badLibrary.swc 发布） 的 UIComponent 类进行编译，而非来自 SDK 3.5 的 UIComponent 类。

这可能会导致所有类型的任意和奇怪行为。

如果您是一名希望使用第三方库的应用程序开发人员，您可以使用 Flash Builder 检查库的内容，找到它是否链接至某个特定的 SDK 类。

在图 1 所示的例子中，MyComponent.as 是从 UIComponent 中继承的一个组件。

在库项目属性中，“Merge Into Code” 选项被选定作为框架链接类型。

这就意味着，任何所需 SDK 类都将被拷贝到结果 SWC 中。

MyProject 使用产生的 badLibrary.swc 文件。

如您在“Referenced Libraries”节点中所看到的，将引用和使用 mx.* 程序包上的数个类，而非 SDK 中的类。

避免使用包含任何 SDK 位和补丁的库非常重要，除非库已经过证明。

如果您是一名库开发人员，如果可能的话，请确保在发布库之前，使用“外部”作为框架链接类型。



图 1 库中的链接 SDK 类

使用 -load-config

在一个大型项目中，使用数个额外的编译器参数非常常见。

当使用条件编译、功能测试、定制元数据选项卡（和大多数现代应用程序框架一样）和国际化参数时，您的额外参数最终可能看起来如下：

-locale en_US -include-libraries ${flexlib}/libs/automation.swc
${flex_lib}/libs/automation_dmv.swc
${flexlib}/libs/automation_agent.swc ${RIA_TEST}/RIATestAgent.swc
-define=CONFIG::debugging,true
-define=CONFIG::formsRefactor,false
-keep-as3-metadata=ArrayElementType,Translate,Translator,ManagedEvents,Answer,AnswersGroup
包含所有这些额外编译器设置可能会有几个缺点：

由 Flash Builder 提供的用于读取、修正和管理这些参数的 UI 不是为大量数据而设计的。在该长字符串中进行寻找和编辑可能会有困难，而且容易出错。
这些参数将被存储在 .actionScriptProperties 文件中。因为它不是结构化信息，采用您的版本控制系统进行识别和合并任何改变时应该非常谨慎。
如果您进行任何改变（如，添加一个用于保存的新元数据选项卡），非常有可能您的持续集成环境将不再同步，因为它可能使用一个不同的配置源，并采用 Ant 或 Maven 运行 build。
避免这种情况的一个方法是使用 -load-config 参数，将一个引用传给一个编译器配置文件。例如：

-load-config+=additionalCompilerParameters.xml
在本案例中，additionalCompilerParameters.xml 将包含下列内容：

<flex-config> 
   <compiler>   
      <include-libraries>  
         <library>${flexlib}/libs/datavisualization.swc</library>      
         <library>${flexlib}/libs/flash-integration.swc</library>    
      </include-libraries>        
      <keep-as3-metadata>         
         <name>ArrayElementType</name>   
         <name>Translate</name>       
         <name>Translator</name>       
         <name>ManagedEvents</name>    
         <name>Answer</name>        
         <name>AnswersGroup</name>  
      </keep-as3-metadata>   
      <define>        
         <name>CONFIG::debugging</name>     
         <value>true</value>     
      </define>       
      <define>        
         <name>CONFIG::formsRefactor</name>           
         <value>false</value>       
      </define>  
   </compiler>
</flex-config>
如果您在为某一编译器参数寻找正确的 XML 语法时存在困难，您可以和 -dump-config=config.xml 选项一起将参数添加为一个额外的编译器设置。

这将产生一个包含所有指定参数的编译器配置文件。

然后，您可以使用这个生成的文件作为一个引用。

了解这里文件的语法的另一种方法是使用 SDK/frameworks/flex-config.xml 作为引用。

将所有的编译器配置保存在一个外部 XML 文件中也是确定您的“持续集成”环境始终同步以及避免必须维护庞大的单独 Ant 任务的一个好方法。

您可以将一个简单的 Ant 任务指向该编译器配置 XML 文件。

将来自所有源路径的所有类包含在库项目中

在 Flash Builder 4 中，从您的库项目中选择“包含来自所有源路径的所有类”。

该选项是 Flash Builder 4 中的新功能，可以在“Flex 库 Build 属性”目录下“类”选项卡中的项目属性中找到。

该选项最大的优势是：在创建一个新类，并将其移动到另一个项目中，或者拷贝到其他地方时，您无须特意指定必须将其包含在被编译的 SWC 中。

由于您或者其他人忘记修正或者提交 .flexLibProperties 文件，您不得不几次重新编译您的项目？

可能有些人会认为这个选项会使您将不必要的类链接至 SWC 文件中，但是仅将那些需要编译到库中的类存储到库源文件夹中是最佳实践。

使用多个源路径文件夹
在很多种情况下，使用多个源路径文件夹有意义，其中包括使用动态补丁类时或者部件测试期间。

为动态补丁类创建单独的源路径文件夹

如果动态补丁类和它们的相关文件被作为项目特定类存储在同一个源文件夹中，可能会使开发人员感到困惑。

创建一个 flexSDK 源文件夹，并将所有补丁类和相关的资源放在其中是个不错的主意。

如果您因为某个缺陷而对 SDK 打动态补丁，为每个缺陷补丁创建不同的源文件夹也会有帮助。

例如，您可以创建一个名为 flexSDK-123 的文件夹（参看图 2），其中123是 http://bugs.adobe.com 上报告的缺陷编号。

当您在 Jira 上记录一个缺陷并跟踪其进程时，非常有可能在后面的阶段将发布一个官方修复。

您获得官方修复后，仅需移动与该缺陷相关的源文件夹，而无需在您的项目中保留任何不使用的资源。

为每个补丁类添加一个 readme.txt 文件，解释补丁的细节也会有帮助。