今天下载了Flex 4.6 SDK后，发现framework/flex-config.xml中的默认-swf-version的值变成了14，而-target-player则变成了11.1。

记得在Flash Player 11发布的时候，为了能正常的编译面向Flash Player 11的swf文件，需要将-swf-version的值设置为13。以此推算，14这个值应该是针对Flash Player 11.1的。

那么-swf-version和-target-player的对应关系如何？见下表：

上面的这份表格，是根据Targeting Flash Player versions整理出来的，但这个表格是不准确的。

因为，-swf-version的值能支持到那个程度，其实与Flex SDK并没有直接的关系，而是依赖于Flex SDK中的playerglobal.swc（位于frameworks/libs/player）。

打开Flex 4.6 SDK的frameworks/libs/player文件夹，可以看到其中只有一个11.1子文件夹，放置着针对Flash Player 11.1的playerglobal.swc。这个swc的作用有2个：

1. 在程序编写期间，Flash Builder使用它来提供自动完成功能。当然，如果直接用mxml编译器（比如我，就没有使用这个功能；
2. 在程序编译期间，mxmlc编译器需要调用它。

在每个新版本的Flash Player 11发布的时候，必须一起提供playerglobal.swc文件，也是这个原因。因为SDK的发布，和Flash Player的发布并非总是同步的。

在Flash 8时代，编译器和Flash Player是完全同步的。因为那时，只有Flash IDE可以生成swf文件。而Flex问世，以及MacroMedia被Adobe收购以后，Flash的发展就变得多样了，FlashIDE和Flex都可以生成swf文件，Flash Player的发展也更加独立。现在的情况，Flash CS，Flash Builder，Flex SDK，Flash Player的发布已经完全不同步了。尤其是当Adobe将Flex SDK交给Apache发展后，SDK的更新速度估计会更快。Adobe自己又会紧紧将Flash Player攥在手里，保持自己的步调来更新。（关于这段历史，我在Actionscript,AS3,MXML,Flex,Flex Builder,Flash Builder,Flash,AIR,Flash Player之关系一文中做了详述）

偏题了一会儿，现在回到正题：

Flex SDK可以和不同版本的Flash Player相配。即使是使用Flex SDK 3.6，同样也可以开发出Flash Player 11.1支持的swf程序。（当然，前提是不使用Flex frameworks提供的组件，仅仅使用Flash Player提供的API）。通过使用不同版本Flash Player提供的playerglobal.swc文件，就可以让旧的Flex SDK兼容新的-swf-version和 -target-player编译属性。当然，也可以让新的Flex SDK兼容旧的-swf-version和-target-player。

例如，目前Adobe官方提供的最新版（也是最终版）Flex SDK版本为4.6。根据Adobe的说法，这个版本的Flex SDK的最低支持的-target-player为11.1。这是因为frameworks/libs/player中仅仅提供了11.1版本的playerglobal.swc。我们可以将旧版本的playerglobal.swc复制到该目录下，并修改frameworks/flex-config.xml中的target-player标签，以改变Flex SDK默认编译的swf目标。当然，更方便和灵活的做法是在Flex项目的编译属性中设置-target-player属性。

这是我在知乎上的一个回答，原文：http://www.zhihu.com/question/19910415/answer/13337373

HTML5势不可挡，但Flash在视频、游戏方面依然有优势。

其实现在互联网上跟风叫嚣Flash烂的人，绝大多数都是没有深入过Flash开发的人。

Flash在技术上与HTML5+JS2+CSS3相比，目前还是有很多优势的：

1. 比较完善的开发和调试环境；
2. 统一的性能表现；
3. Socket连接的支持；
4. 优秀的摄像头和麦克风的支持；
5. 统一的平台语言；
6. 面向虚拟3D设备的编程。

但，Flash也有很多劣势：

1. 不适合企业开发。Flex是一个优秀的框架，但性能始终差强人意，开发过程太过缓慢；
2. 拥有大量不懂编程的“伪程序员和伪闪客”编写了大量影响浏览器性能的Flash小广告和小动画，影响了互联网上绝大多数不懂技术和不懂Flash编程技术的人对Flash技术的正确判断；
3. 不专业。上面两点影响了所有人的判断（包括我），认为一个用Flash技术制作的企业网站是不专业的；
4. 性能，还是性能。基于浏览器的性能和基于浏览器的插件的性能，谁可能做得更好？

当然，上面说的大多数的优势与劣势，都是基于桌面平台的。Flash技术在移动平台上可以说是完败。JAVA都做不到的事情，Flash也做不到。Sun做不到的事情，Adobe更不可能做到。

Adobe一开始就走错了路，搞了个不伦不类的Flash Lite，居然现在还开发到4.0！如果一开始就走原生程序的路，现在或许会好很多。

AIR是个不错的东西，但还是被Adobe那龟速的开发时间表所拖累，先是放弃了Linux平台的用户与开发者，然后到了3.0才加上原生插件支持，结果现在都脱不了“玩具”的帽子。

Adobe放弃支持移动平台Flash Player，是希望集中精力用AIR统一移动开发平台，至于结果如何，就只有拭目以待了。

• 转自：http://www.riadev.com/flex-thread-1820-1-1.html
• 译者：瑞研社区 郭少瑞
• 原文：http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html

这个问答对于Flex开发者非常重要：

在Adobe公布策略调整的这一周，我们知道，Flex社区围绕Adobe的Flex SDK的计划有很多疑问，我们尝试回答这些问题：

问题1：Adobe公司还会致力于发展Flex吗 ？

答：是的。我们知道Flex为企业级开发提供了一套独特的解决方案，也知道应用开发领域的技术前景正在迅速改变，并且我们的客户希望更直接的控制他们所使用的技术。鉴于此，正如我们将收购Nitobi得到的PhoneGap贡献给Apache基金会那样，我们计划将Flex SDK贡献给一个开源组织。

这个项目的成员组成包括：一些来自Flex SDK工程团队的开发者，Flex社区的技术达人，还有一些成员来自于Spoon项目和一些已经使用Flex技术的企业。Flex SDK未来的开发将在新的领导模式下继续，Adobe也将为此作出积极贡献。

问题2：Adobe建议我们在企业级开发中应该使用Flex还是HTML5？

答：长期来看，我们相信HTML5将成为企业级开发的最好技术。我们也知道，目前来看，Flex在某些大型客户端项目上具备明显优势。

鉴于我们在Flex上的经验和创新能力，我们将为HTML5的发展和进步作出积极的贡献，这个将从移动应用开始。事实上，许多Flex SDK的工程师和产品经理将转移到我们的HTML方面努力工作。我们将继续作出显著的贡献，以开放的WebKit和jQuery的Web技术，推进PhoneGap发展，并创造新的工具来解决开发HTML5应用面临的挑战。!

问题3：之前宣布的Flex路线图会被实施吗？

答：Flex的路线图将由未来管理Flex的理事会决定。我们计划将之前为Flex制定的规划贡献给这个新项目（即由新的理事会管理的Flex）。

问题4：Adobe仍然会发展Flash Builder吗？

答：是的。Flash Builder将会继续发展，Adobe会努力确保Flex开发人员顺利使用这个工具，并支持未来的Flex SDK的新特性。

问题5：Adobe会继续支持已经使用Flex的客户吗？

答：是的。Adobe将继续履行现有的Flex支持合同。

因此，下一步是什么？

我们正在接近完成Flex 4.6 SDK的开发，将在2011年11月29日发布。在此之后，我们将开始转移到开放的开发模式，即上面所说的内容。

就个人而言，我们会和大家保持沟通，并承诺在未来几周和几个月内定期发布最新的消息。

我们相信，这将改变Flex SDK的发展模式，将确保更广泛的社区可以在今后的多年内直接使用Flex。

************ UPDATE – 11/15/11 ************

在上面的澄清之后，我们又收到了很多意见和反馈。在这里我们继续回答以下问题：

Adobe对Flex发展的未来规划是什么？

答：我们为Apache基金会提供了两个关于未来发展Flex SDK和Blaze DS的规划。

• 除了核心的Flex SDK（包含自动化和高级数据可视化组件），Adobe还计划捐赠以下内容：
• 已完成的，但还未公布的Spark组件，包括：ViewStack，Accordion，DateFiled，DateChooser和一个增强的DataGrid。
• BlazeDS部分，则是基于Java服务器的远程访问和网络通讯技术，使开发人员可以轻松连接到后端的分布式数据，或将实时数据推送到Flex应用程序。
• Falcon，下一代MXML和ActionScript编译器，目前正在开发中（有望于2012年完成）。
• Falcon JS，一个实验性的交叉编译器，将MXML和ActionScript编译到HTML和JavaScript。
• Flex测试工具，将继续沿用Adobe之前使用的，以确保可以继续高效的开发Flex应用。
• Adobe仍然有一个包含Flex SDK工程师的团队，来支持未来的新的Apache项目。Adobe已经开始做一些开发工作，包括其他的Spark组件。

是不是Adobe放弃了Flex，把它交给Apache，等死而已？

答：绝对不是。我们为实现了Flex而感到无比自豪，并且我们知道，它将在今后的很多年里仍然有显著的价值。我们期望从Apache社区中得到积极的，可持续的发展模式。需要澄清的是，我们将为这个项目提供可靠的支持，并且我们将和Flex社区一起工作，来让他们的贡献更有效。

从Flex 3 SDK开始，Flex已经被开源了。那么现在重新宣布的开源意味着什么？

答：在Flex 3 开源之后，用户主要使用Flex源代码来调试Flex框架中的基本问题，而不是开发新的功能或修复错误，和将他们的反馈体现到SDK。

正如周五宣布的，Adobe将不再是Flex正在进行的路线图的所有者。相反，该项目将在Apache基金会得到良好的规划和管理。在这种模式下，Apache社区成员提供该项目的领导。我们期望项目管理团队中包含Adobe工程师和关键的社区领袖。他们将一起协作，来规划未来版本的Flex SDK的新功能和特性增强。Apache的模式已经证明，这是一个充满活力的，可持续发展的模式。

新的开源项目如何展开？它在哪里托管？谁将管理这个项目？Adobe是否仍然控制了Flex的路线图？我如何提交贡献？

答：我们正积极努力的促使Flex SDK和Blaze DS项目成为Apache基金会的孵化器项目。我们期待在未来几周内取得进展并和大家分享信息。我们正积极联系Flex社区成员，以确保他们和Adobe的工程师一起参与项目的管理。

关于Flex应用程序将继续运行于Flash Player和AIR，Adobe有什么保证？

答：Adobe将继续支持未来版本的Flex构建的应用程序，包括允许于PC端的Flash Player之上的在线应用，和基于Adobe AIR的运行于iOS，Android，和RIM平板操作系统的移动应用程序。

你说的Adobe仍然致力于发展Flash Builder，是什么意思？是指在未来的Flex SDK的背景下？

答：未来版本的Adobe Flash Builder中，将继续提供代码编辑，编译，调试和分析Flex应用程序的支持。 Adobe将继续工作，以确保Flash Builder兼容Flex SDK未来的版本。此前路线图通报的功能，如增强的代码编辑，实时错误突出显示和编译型的支持，将继续提供给ActionScript和Flex开发人员。

Flex还可以作为现有或新项目的可行的技术方案吗？

答：当然可以。Flex SDK将作为一个开源项目继续得到发展和维护，Adobe公司会积极推动它的发展。

你说，“长期来看HTML是最合适的企业级应用的解决方案”，什么意思？

答：HTML5的相关技术（包括HTML，JavaScript和CSS）正变得越来越强大，包括：高级特性（Canvas），性能（在许多浏览器中的GPU加速），和应用程序相关的功能（包括离线存储，网络监测）。这样，我们完全有理由相信，它将继续以迅猛的速度发展。至于需要多长时间，取决于你的应用程序的要求，可能是3到5年。我们相信，HTML5可以支持现在Flex的大部分功能。

但是，Flex已经有多年发展，和HTML5相比在企业级开发上还是有很多优势，尤其是：

• Flex提供了跨平台的一致性
• Flex组件和编程模型来构建复杂的应用程序用户界面时非常高效
• ActionScript是一个成熟的语言，适用于大型应用程序开发
• 工具的支持（Adobe和第三方），包括代码编辑，测试和分析
• 我们打算在HTML相关的技术领域投资，来推动HTML5适合开发企业级应用程序。

Adobe是否提供迁移工具，把现有的Flex应用程序转换为HTML/JavaScript？

答：我们已经在这个领域进行了一些尝试性的工作，但目前仍不能确保将Flex内容转换为HTML的可行性。 Falcon JS交叉编译器，就是做这个的，这个项目仍然处于早期，将作为开源项目捐献。

接下来会发生什么？

答：我们正积极和Apache基金会协商开源事宜。一旦建议被接受，Adobe和社区贡献者就可以开始新的贡献。我们将积极和大家分享信息-希望在未来的几周内就可以确定。

我们将为您提供更详细的开源方面的信息，我们正在做的工作，您可以作出的贡献，以及未来我们HTML5的相关计划。

我们希望有机会和更多关注这个变化的Flex开发人员接触，为此，将由Adobe Flex技术传教士举办多个城市的国际巡回演讲，以便和大家直接交流。请继续关注更多的信息。

Andrew Shorten & Deepa Subramaniam
Group Product Managers, Adobe

在Vim调用Ant编译swf并自动调试一文中，我介绍了使用Vim来编译swf的方法，这半年来，我一直都用Vim+Ant+FlexSDK做AS开发，感觉总体效率上比Flash Builder要高许多。

不好的地方，其实也有许多。最大的不便就是没有代码提示，对于不熟悉的方法，必须要去查看Language Reference。还有个附带的不便就是必须自己手动导入包。不过这两个不便之处，又让我远离了Flash Builder中的哪些错误的代码提示（我被误导过好多次），以及让我更熟悉AS3的包结构。

今天说的不是这些，好了，进入正题把！

在Vim中，有许多为程序员着想的地方。比如碰到编译错误后会自动打开第一个出错的文件并跳转到出错行。改完这个错误后可以用 :cn 命令跳转到下一个出错处继续修改。这个特性降低了程序员在调试过程中对鼠标的依赖，提高了效率。

不过，在使用Vim+Ant+FlexSDK来编译AS的时候，虽然能够看到编译的出错信息，但是Vim会自动打开一个不存在的文件，无法使用上面的功能。

要了解出现这个问题原因，首先要知道Vim获取编译错误的原理。Vim通过分析编译器输出的错误信息文本，来得到自己能识别的出错信息，从而实现正确的跳转。但不同的编译器的输出信息千奇百怪，Vim默认的分析程序不能正确解析 Ant+mxmlc 编译器的输出信息，造成了无法正确跳转到错误文件。让我们看张图：

可以看出，Vim将错误文件路径前面的[mxmlc]前缀也当作了路径的一部分，然后打开这个不存在的文件，导致无法正常进行修改。

再看一张详细一点的错误信息：

那么，只要我们将错误信息的解析程序设置正确，就能正确解析这些信息了！

执行下面的代码，然后编译，如果有编译错误，就能正常的跳转到错误文件的对应位置：

:set errorformat=%E\ \ \ \ [mxmlc]%f(%l):\ 列:\ %c\ %m

需要注意一点的是，在ex模式或者在命令行模式中输入errorformat属性值的时候，必须对空格用反斜杠转义，否则Vim会不接受这些参数值。网上找的很多例子可能都忽略了这点。上面的例子中，已经进行了转义。

为什么例子中有个中文？因为编译器自动识别了我的语言，因此输出的错误信息是中文的，我也必须用中文来分析。如果编译器输出信息为英文，那么这里的 列 应为 col。

由于使用了中文，如果将这段代码写在vimrc中的话，就必须进行编码转换：

let &errorformat=iconv("%E\ \ \ \ [mxmlc]%f(%l):\ 列:\ %c\ %m", 'utf8', &enc)

至于语法的详细含义和用法，这里写的很清楚：:help errorformat

看过Ant and FCSH资源合集的童鞋应该都知道Flex Compiler SHell Server(后简称为FCSHServer)这个用VB开发的FCSH wrapper。本篇就介绍它的用法。

1. 下载FCSHServer并安装；
2. 设置环境变量FCSHServer={你的安装目录,例如：D:\FcshServer}。zrong强烈建议你安装的文件夹不要包含空格，貌似环境变量设置之后，只有重启Windows才能起作用；
3. 设置安装目录下server.ini中的sdk和java的值。sdk指向flex SDK文件夹，java指向JDK文件夹，例如：

    sdk=d:\flex_sdks\4.1.0
    java=d:\Java\jdk1.6.0_25

4. 配置Ant项目，直接看代码吧，有注释(这个项目会经常更新，最新的版本看这里)：

<project name="runtest" default="build">
 
    <property file="build.properties" />
    <!-- 取环境变量 -->
    <property environment="env"/>
    <!-- 设定一个默认的主文件，默认编译的是RunTest.as。
         若需要编译其他文件，可以调用ant -Dmain=Other，不需要扩展名 -->
    <property name="main" value="RunTest" />
    <!-- fcsh的编译地址 -->
    <taskdef name="fcsh" classname="fcsh" classpath="${env.FCSHServer}/fcsh.jar" />
 
    <target name="build" depends="init,compile,fdb" />
 
    <!-- 清理目录，复制没有嵌入的文件 -->
    <target name="init">
        <delete dir="${DEPLOY_DIR}/test_${main}.swf" />
        <delete dir="${DEPLOY_DIR}/assets" />
        <mkdir dir="${DEPLOY_DIR}/assets" />
        <copy todir="${DEPLOY_DIR}/assets">
            <fileset dir="${SRC_DIR}/assets" excludes="**/source/" />
        </copy>
    </target>
 
    <!-- 编译 -->
    <target name="compile">
        <fcsh consoleencoding="UTF8">
            <arg value="mxmlc ${SRC_DIR}/${main}.as"/>
            <arg value="-output=${DEPLOY_DIR}/test_${main}.swf"/>
            <!-- 这个参数其实可要可不要，因为编译的时候，默认会调用这个xml文件。-->
            <arg value="-load-config=${FLEX_HOME}/frameworks/flex-config.xml"/>
            <arg value="-source-path=${LIBS_DUDU}" /> 
            <arg value="-debug=true" />
            <arg value="-static-link-runtime-shared-libraries=true"/>
        </fcsh>
    </target>
 
    <!-- 打开调试器进行调试 -->
    <target name="fdb">
        <exec executable="cmd" spawn="true" osfamily="windows">
            <arg line="/K start fdb ${DEPLOY_DIR}/test_${main}.swf" />
        </exec>
    </target>
</project>

# 设置FLEX SDK的路径
FLEX_HOME=D:/flex_sdks/4.1.0
 
# 设置源文件路径
# {$basedir} 就是本文件所在的目录
SRC_DIR =${basedir}/src
 
# libs目录，一般用来放swc文件
LIBS_DIR =${basedir}/libs
 
# 这个就是Flash Builder建立的bin-debug
DEPLOY_DIR = ${basedir}/bin-debug
 
#自定义的几个类库源码
LIBS_DUDU = e:/works/duduw_as3lib/src

如果你和我一样，正在或者准备用纯Flex SDK开发SWF或AIR，那么你一定需要FCSH。

fcsh(the Flex compiler shell)是一个基于命令行的编译环境，你可以用它来编译应用程序,模块,和SWC库。它的工作方式与mxmlc和compc类似，但编译速度则要快很多。原因是fcsh会利用内存和缓存。想看更多的介绍，可以看看这里：Using fcsh, the Flex compiler shell

现在，你已经知道使用SDK编译程序比Flash Builder要慢许多的原因了（实际上，Flash Builder第一次编译程序也是很慢的，但编译之后，它就在后台运行了一个fcsh用来加速）

fcsh命令行的使用方法没有什么好说的，直接看上面的链接即可。fcsh是使用命令行来调用mxmlc的，而且fcsh必须始终保持运行，并总是使用这个进程进行编译，否则就没有优化效果。所以，现在有个问题：

如果你要用ant来编译程序，Ant无法保证fcsh始终在后台运行。因此就有许多网友开发了一些Wrapper程序来保证fcsh始终在后台运行。简单的说，这些Wrapper就是服务器，而Ant变成了客户端，将资源发送给服务器编译。

我将找到的这类资源整理成一个列表，如果你和我一样用纯Flex SDK的话，或许有用：

• fsch，Wrapper for Adobe Flex Compiler SHell + ant tasks. Visual Basic 6.0.
  你也看到了，这个是用VB开发的，所以只能运行在Windows平台上。
• FCSH Wrapper
  JAVA开发的Wrapper，理论上可以用于多平台。博客基于blogspot，所以大多数时候要翻墙才能访问。
• BigSource Zarkov
  Eclipse插件，功能很多。但如果使用独立版（非Eclipse版），则不支持FCSH

或许很少有人像我这么极端吧，放着好好的盗版XP和盗版Flash Builder不用，偏要去鼓捣什么Vim……

当然，在Vim下面，你可以自己写脚本调用Flex SDK的命令行编译器mxmlc进行编译，但我更愿意用Ant，原因如下：

• 配置方便
  基于XML的配置文件，比命令行好读好写；
• JAVA原生
  Ant是JAVA写的，Flex SDK的编译器（mxmlc、compc、asdoc……）也是JAVA写的；
• 通用
  换用Linux或Mac，也一样用，顶多改改变量中的路径。

在Flash Builder下面，按F11后，就可以自动编译swf并打开Flash Player，并显示trace信息，以及调试断点。在Vim中也能这样么？

大部分可以。我们可以用fdb进行swf的调试工作，能看到trace信息，也能设置断点和进行调试，可惜没有Flash Builder那么直观。
但是！！！你可以用Vim写AS代码了！塞翁失马你有没有！！！！

那么，开始吧！

(注意，本文假定你了解Vim)

安装Ant

1. 到Ant下载页面下载最新版的Ant。我将它解压到D:\ant；
2. Ant需要安装JRE，但是如果你安装JDK的话，支持的task更多，所以现在下载JDK并安装，我将其安装到D:\Java\jdk1.6.0_25；
3. 设置环境变量JAVA_HOME到D:\Java\jdk1.6.0_25，设置环境变量ANT_HOME到D:\ant；
4. 将D:\Java\jdk1.6.0_25\bin和D:\ant\bin加入环境变量PATH。

Vim的设置

只需一步，将下面这句代码加入你的vimrc即可：

set makeprg=ant         "设置编译器为ant

Ant的设置

将下面两个文件复制到你的项目文件夹（即src文件夹的上层文件夹）这两个文件的最新版本在这里：https://gist.github.com/944712

# 设置FLEX SDK的路径
FLEX_HOME=c:/Program Files/Adobe/FlashBuilder4Plug-in/sdks/4.1.0
 
# 设置源文件路径
# {$basedir} 就是本文件所在的目录
SRC_DIR =${basedir}/src
 
# libs目录，一般用来放swc文件
LIBS_DIR =${basedir}/libs
 
# 这个就是Flash Builder建立的bin-debug
DEPLOY_DIR = ${basedir}/bin-debug
 
#自定义的类库源码
LIBS_DUDU = e:/works/duduw_as3lib/src

<project name="run_test" default="build">
 
	<!-- 载入配置文件 -->
	<property file="build.properties" />
 
	<!-- 确定flexTasks.jar的位置 -->
	<taskdef resource="flexTasks.tasks" classpath="${FLEX_HOME}/ant/lib/flexTasks.jar"/> 
 
	<target name="build" depends="init,compile,fdb" />
 
	<!-- 清理部署目录中的内容 -->
	<target name="init">
		<delete dir="${DEPLOY_DIR}/run_test.swf" />
		<delete dir="${DEPLOY_DIR}/assets" />
		<!-- 将资源目录复制到部署目录 -->
		<copy todir="${DEPLOY_DIR}/assets">
			<fileset dir="${SRC_DIR}/assets" />
		</copy>
	</target>
 
	<!-- 编译 -->
	<target name="compile">
		<mxmlc file="${SRC_DIR}/RunTest.as" output="${DEPLOY_DIR}/run_test.swf">
	        <load-config filename="${FLEX_HOME}/frameworks/flex-config.xml"/>
	        <source-path path-element="${LIBS_DUDU}" />
			<!-- 需要libs的时候解开注释
			<compiler.library-path dir="${basedir}" append="true">
				<include name="libs" />
			</compiler.library-path>
			-->
			<!-- 必须加上这行，如果不加，当使用[Embed]的标签的时候，就会出现VerifyError: Error #1014: 无法找到类 。 原因应该是没有将mx.core包编译进入。官方文档说这个属性默认是true， 不要相信它-->
			<static-link-runtime-shared-libraries>true</static-link-runtime-shared-libraries>
			<!-- 编译成可调试的版本 -->
			<compiler.debug>true</compiler.debug>			
		</mxmlc>
	</target>
 
	<!-- 打开调试器进行调试 -->
	<target name="fdb">
		<!-- 不能直接调用fdb，因为这样不会打开新的命令行窗口，必须使用/K或者/C参数，加上start来启动fdb -->
		<exec executable="cmd" spawn="true" osfamily="windows">
			<arg line="/K start fdb ${DEPLOY_DIR}/run_test.swf" />
		</exec>
	</target>
</project>

编译

这个就简单了，只需要在Vim下执行下面的语句：

:make

或者

:!ant

当然，也可以带参数。例如你的项目中有一个以上的主文件，你可以制作build_a.xml、build_b.xml等等，然后执行：

:make -f build_a.xml

看图片吧！

2011-05-06更新：加入SWF SWC SWZ部分

2011-09-19更新：smithfox推荐了一篇英文的，比我的更详细：Versions in the Flash Platform

这篇文章本来是我在9ria上对网友的回复，但最近询问此类问题的网友越来越多，就整理了一下，增加了一些东西。原贴见这里

ActionScript

ActionScript通常简称为AS，它是Flash平台的语言。AS编写的程序，最终可以编译成SWF、SWC。SWF就是我们常说的Flash动画。但是现在SWF已经不仅仅是动画，而是RIA的载体。

ActionScript有3个版本，分别是1.0版（AS1），2.0版（AS2）和3.0版（AS3）。只有Flash Player 9及以上播放器才支持AS3编译的SWF。这三个版本的差别非常大，现在最流行的版本是AS3。

Flex与MXML

因为在开发RIA的时候，需要很多常用的功能，例如控件（Button,ComboBox,List……）、布局（VGroup、VBox……）等等…… Adobe就开发了一套官方的框架集来实现这些功能，这套框架集就叫做Flex。

为了方便程序员快速编写RIA程序界面，Adobe又实现了一种基于XML语法的语言MXML，这套语言很像HTML，可以与AS混用，MXML最终也是编译成SWF或SWC。 Flex框架就是使用AS3与MXML两种语言写成的。但说白了，MXML 外加实现了MXML语法，如果你有兴趣，也可以自己实现这些。 Flash和Flex，都是用AS编写，使用swf体现。

Flash

现在Adobe已经将Flash其定义为一个平台（Flash Plantform），包括了Flash IDE、Flash Builder、AIR、Flash Player以及更多。但我们一般讲Flash，有两个意思，一个是指Flash动画（也就是网页上扩展名为swf的动画），另一个就是Flash IDE。

Flash（IDE）从4.0开始进入中国，前期一直在网页动画方面告诉发展，多被用来做网页小广告（让你CPU100%的罪魁祸首之一）和MV（showgood三国系列、小小系列、大学自习室……曾经风靡一时啊）。那时的“闪客”，主要是做动画，即使涉及到编程，也大多是用当时的AS1.0（后来Flash MX 2004升级为AS2.0）写一点stop、gotoAndPlay之类的东东了。Flash（IDE）发展到8.0版本以后，才开始大量用于编程，当时比较流行的就是“Flash留言本”等等。相关历史我做了一张图来表示，括号里的数字是年份。

Flash Builder/Flex Builder

AS发展到3.0之后，由于其语法和JAVA比较像，再加上增强的性能与强类型，可以完全脱离FLA文件，使用纯文本编码，受到了许多其他程序员（尤其是JAVA程序员）的青睐。由此得以高速发展，用AS开发程序的人也越来越多。AS在视频网站、游戏行业发展迅速。但是，Flash IDE虽然是一个很好的动画制作工具，却不是一个好的开发工具。于是，Adobe又发布了Flex Builder，一个基于Eclipse的IDE，并发布了Flex SDK，后来又开源了。

有了免费的编译器，Flex得以快速发展。用Flex Builder也可以开发纯AS项目（即所有的文件都是as文件，不包含MXML，也不包含FLA）。一个真正的程序猿，应该更愿意使用这种方式吧？Flex Builder从4.0开始，被Adobe改名为Flash Builder。

Flash Builder和Flash IDE不应该放在一起比较，它们不是一类软件。如果一定要比较一下的话，那么就是Flash IDE比较偏重于设计一点，用它做动画比较方便，当然也可以用它编写AS3程序。用Flash IDE编写的程序，会有一个FLA源文件，可能还包含多个as文件。Flash Builder偏重于程序，用它可以开发MXML（也就是Flex）项目。也可以用它编写纯AS项目。用Flash Builder编写的项目，都是纯文本文件（.as或者.mxml）。 对于程序流，当然偏爱Flash Builder，而设计流比较偏爱Flash IDE。

当然，IDE并非只有Adobe官方的东西，Flash Develop就是个免费的IDE。如果你愿意，用记事本做编辑器也没什么不好（比如说zrong就正在尝试VIM），因为SDK和编译器都是免费的。

Flash Player

swf动画需要在网页上显示出来，就需要安装Flash Player。Flash Player的不同版本，其实与Flash IDE也有一定的对应关系（从上图也能看出来）。但到了AS3时代后，这个对应关系就不那么明显了。Flash Player 9是能支持AS3 的最低版本（其实前面还有一个Flash Player 8.5，只是没普及就升级到9了），后面的Flash Player 都能支持AS3了。关于Flash Player，我写过一篇有史以来关于Flash Player的最详细说明，看这个就很清楚了。

AIR

Flash Player 再强大，也是运行在浏览器中，受浏览器约束。为了摆脱浏览器，Adobe又出奇招，发布了AIR。AIR其实就是一个Runtime，你可以把它理解成JVM。有了AIR，就可以用AS3开发桌面软件，而且开发出的软件可跨平台运行（这和JAVA的一次编译，随处运行不是如出一辙么！)。目前国内的AIR应用主要集中在网站的客户端方面，例如新浪微博AIR客户端等。

SWF SWC SWZ

SWF
swf是我们见到的最多的Flash平台文件了。是的，它就是Flash平台的最终表现形式。前面说到了，无论是Flex、Flash还是纯AS3，最终编译出来的文件都是swf格式，浏览器中的Flash Player插件和独立的Flash Player，也只能“打开”swf文件进行播放。前面说到的AIR，它的本质也就是运行时+swf而已。

其实并非所有的swf都能直接播放的。swf有3种：

1. 程序SWF(application swf)：可以直接在flash player中运行的swf；
2. 库SWF（library swf）：swc文件中的library.swf；
3. 模块SWF（module swf）：Flex Module产生的swf文件。

最终用户碰到的绝大多数都是“程序SWF”，而程序猿们碰到后面两种SWF的可能性就比较大。

SWC

SWC是一种库文件，通常用来发布非开源的类。程序猿们将源码编译成SWC文件，并发布API文档，我们就可以使用这些SWC提供的类库进行自己的开发。SWC并不是运行时共享的，而是在编译的时候直接加入了程序SWF中。最终的程序SWF可以脱离SWC运行。

SWC本质就是一个zip文档，其中包含一个library.swf文件和一个用于描述的xml文件，你可以用zip管理器打开它查看。

SWZ

你可能会发现，从TLF出现以来，Flex SDK中多了一个flashx包，这个包中的功能，就是用SWZ实现的。SWZ是在运行时共享的库，你可以将其看作一个可以放在外部的SWC。而且SWZ的共享是平台级别的（Moudle SWF的共享是浏览器级别），存在于操作系统缓存中（Module SWF的存在浏览器缓存），只要下载过一次SWZ，你的操作系统中所有用到这些SWZ中的地方（无论是IE、FF、Chrome还是AIR）都不用重新下载。

对于程序猿，这里的关于SWC和SWZ的信息肯定是不够的，所以建议看一下smithfox的swf swc swz RSLs ant，本文的这个部分也是参照它写成的。

全文完

今天在论坛上回复了一篇帖子，记下来：

小弟以前是做java 程序员的 ，接触flex 也有一年了 从之前的flex3 到现在的flex4 ，在公司的项目中，我也经常使用flex的各种组件，但我个人对flex游戏制作方面很有兴趣，所以想请教下有flex游戏开发经验的各位达人，小弟现在欠缺的是什么？

转自：http://bigt.javaeye.com/blog/764430

英文原文：http://www.billdwhite.com/wordpress/?p=296

“elements”是一个关键性的问题。elements是何物？它同child是否是一回事？刚开始的时候我曾武断的认为elements不过是children的另一种说法。通过反复梳理组件中所有的elements和children，我发觉在新的容器类（也包括一些经过改良的传统容器）某些似乎是理所当然应该具备的方法消失了。如果没有getElements()，我该如何获取elements的数目呢？我能否把getChildren() 的返回结果作为IVisualElement来对待。这令我十分纠结。

困扰的我于是开始认真阅读学习API文档，Flex的源码以及相关的博客文章。我也曾尝试解读一些博主发布的关于Flex4新特性的幻灯片。然而事实证明脱离讲解而孤立的看幻灯片作用相当有限。

最后，我拼凑了一些言简意赅的示例。这些示例将带领我了解有关elements的全新知识，告诉我那些在新的Spark容器背后发生的故事。

言归正传，首先从问题开始。问题一，“应该如何获得Spark 容器的全部elements？”我曾想当然的认为是通过一个类似Flex3中的getChildren() 的方法。然而实际上我们需要通过两个Property来达到这个目的：numElements & numChildren 。可以通过对numElements计数的循环语句配合getElementAt() 来实现遍历容器elements或特定访问。这种方式还比较直观。问题二，“element和child的区别何在？”，让我们来看看两者的差异。

语义上，element简单的说就是实现了IVisualElement接口的任意型别。child是指扩展了DisplayObject类的任意型别。判断某个组件是element还是child亦或两者都是的关键在于以下几点。UIComponent(所有Flex组件的基类：译者注)是由DisplayObject扩展而来，故所有UIComponent都是DisplayObject，也就是说UIComponent都是children。UIComponent同时也实现了IVisualElement接口，因而所有的UIComponent也可以被作为elements看待。但这并不是说所有的DisplayObjects（文中所言的DisplayObject一般指扩展于DisplayObject的子类，译者注）都是elements。容器中的DisplayObject对象是该无疑是容器的child。而只有当此DisplayObject对象同时也实现了IVisualElement接口时它才是容器的element。那么对容器而言，DisplayObject什么情况下是child，什么情况下又是element？通过示例来认识这个问题。

在首个示例中，我们使用了传统的Halo容器（这里我们使用的Panel）。Panel扩展与DisplayObject类，所以它可以使用addChild() 方法。进一步而言，Panel也是Container类的子类（mx.core.Container实现了IVisualElementContainer接口），它具有addElement() 方法。Container类的IVisualElementContainer接口实现只是基于显示列表API的门面，所以理论上它和同样实现了IVisualElementContainer接口的新式Spark容器具有相同的方法集合。

于是看起来我们可以任意添加children或element到容器中了。事实却不是这样。并非任意型别的element都能被添加（此处element泛指实现了IVisualElement接口的类）容器中。视觉元素（VisualElements）和图形元素（GraphicElements）有一些区别视觉元素（VisualElements）实现了IVisualElement接口，而图形元素（GraphicElements）实现的是IVisualElement接口的子接口IGraphicElement。IGraphicElement接口扩展的新特性为容器获取信息提供了额外渠道。某些elements（图形元素是其中之一）无法直接添加至Halo的Panel编译器会告知“这样的对象需事先包装进一个Group容器中”（实际上错误提示应该是在运行时出现，不关编译器什么事：译者注）。原因马上揭晓。

接下来的示例中，Panel中有若干个UIComponent，其中包括另一个Halo Panel，一个Spark Panel，几个Halo Button和几个Spark Button，以及一个包含有子组件的SkinnableContainer（注意: 包含于SkinnableContainer的组件是只属于SkinnableContainer的children，不是上级容器Panel的children）。所有组件都继承于DisplayObject，所以它们都是“children”。点击“show children”后可以清楚的了解这一点。进一步而言，所有的组件也都是“element”，因为UIComponent实现了IVisualElement接口。

看下一个示例。这次我们探讨的容器上Spark Group。与前Halo Panel类似，Group继承于DisplayObjectContainer，它具有addChild() 方法，它同时也实现了IVisualElement接口，所以我们可以用addElement() 方法来IVisualElement对象（elements）。而且Group也接受图形元素（GraphicElements）,比如spark.primitives.Rect。要知道Rect是无法直接添加到Halo Panel中的。Group是怎么做到这一点的？原因就在于Group知道如何使用一种优化的方式来呈现图形元素（GraphicElements）。什么意思？往下读。

相对于典型的视觉元素（VisualElements），图形元素（GraphicElements）与容器的关系更为紧密。其关键在于IGraphicElement接口。上面曾经提到，这个扩展于IVisualElement的接口（此即图形元素（GraphicElements）可以通过Group的addElement() 方法来添加至其上的原因所在）。然而由于图形元素（GraphicElements）不是DisplayObject，所以他们在被“投映”到某个作为他父对象的DisplayObject前是无法被显示出来的。基于这个原因，当添加一个“Rectangle”到Group时，需要有DisplayObject来绘制这个Rectangle。更有效率一点的做法是Group尽可能的复用同一个DisplayObject来绘制多个图形元素（GraphicElements）。容器可以使用任何实现了ISharedDisplayObject接口的DisplayObject来绘制图形元素（GraphicElements）。第一个示例中的Halo Panel无法使用这种方式来绘制图形元素（GraphicElements），编译器会报错：“必须将其包装至一个合适的容器中”。而Group支持这种优化方式，所以能添加图形元素（GraphicElements）。

另外需要注意的一点是，有些图形元素（GraphicElements）的绘制由Group提供DisplayObject来完成，也有的是自行创建专属的DisplayObject来完成绘制。IGraphicElement接口甚至允许把对象自己创建的DisplayObject交由容器管理（换而言之就是以child形态添加的DisplayObject会以IGraphicElement的面貌来绘制自己）。

这意味着什么？这意味着在接下来的示例中，children的数目和elements的数目是不一样的。这个示例使用了与第一个示例相同的组件集合外，还增加了4个矩形图形元素（GraphicElements）。所有子对象皆为IVisualElement，但不是都可以称为children。几个矩形是图形元素（GraphicElements），它们并不继承于DisplayObject。Group不在乎这点，它知道添加DisplayObject来绘制这些图形元素（GraphicElements）。由于几个矩形的尺寸和角度有所不同，所以Group会创建2个新的DisplayObject来绘制这4个矩形。很酷吧！

现在来看示例三。我们用一个SkinnableContainer替换先前的Group。SkinnableContainer有和先前相同的子组件集，它还能利用Skin来增强视觉效果。Skin是SkinnableContainer唯一的child。SkinnableContainer的默认Skin类由一个矩形和一个被称为ContentGroup的Group组成。该Group的作用在于规划出容器内组件的添加位置。

这个示例证明了这样的事实，即使SkinnableContainer拥有10个elements，但它只有唯一的child：它自己的Skin。而且这个Skin也只有唯一的child：名为ContentGroup的Group组件。你也许会感到奇怪：为什么Skin的children不是2个：其一是ContentGroup，另一个是用于绘制作为边框的Rectangle的DisplayObject？这是因为Skin类继承自Group类，而Group只在它确实需要绘制其包容的图形元素（GraphicElements）时才会添加DisplayObject，目前的情况下不需要。Skin类具备直接在其上绘制Rect图形元素（GraphicElements）的能力，这归功于Skin类的上级类Group实现了ISharedDisplayObject接口。这意味着它在需要时能作为共享的DisplayObject来绘制图形元素（GraphicElements）。Skin负责管理用于呈现图形元素（GraphicElements）的DisplayObject，在当前示例中，Skin自己就是用于绘制的DisplayObject！如果你的自定义Skin中有其它的Rectangle，并将该Skin赋予SkinnableContainer，这种情况下Skin会判断是否需要更多的DisplayObject来绘制额外的Rectangle。这时你可能会发现在Skin的children列表中有更多的child。

值得注意的是，示例中SkinnableContainer，它的Skin以及Skin的ContentGroup这三者的element列表的数目是相同的。通过SkinnableContainer的源码可以知道，numElement的值实际上来源于与之对应的CurrentContentGroup的numElement。所以基本上对SkinnableContainer的elements的检索是被重定向到它的ContentGroup上的。SkinnableContainer的Skin也有类似行为。它继承于Group，Group的numElement的值取自其内部的mxmlContent属性。该属性是一个保存了Group可视内容children的数组。这两个属性与Panel的RawChildren属性十分相似，它用于返回Panel上的所有children而不是getChildren()方法返回的仅仅你添加到Panel上的那些。

通过以上阅读，也许起不到拨云见日的效果。但可以让你明白厘清以下七个类/接口的继承结构和相互关系是十分有必要的：
1. DisplayObject
2. UIComponent
3. Container
4. IVisualElement
5. IGraphicElement
6. IVisualElementContainer
7. ISharedDisplayObject

一旦你掌握它们之间的关系，你就能明白elements 和children的不同。可以肯定的是我在某些问题的认识和阐述上存在很多谬误之处。如果你发现了这样的问题望不吝赐教，在评论处写下您的正确观点吧。

访问下面的链接可以获得关于本文探讨及其相关的主题的更多内容。

Gumbo DOM Tree API（关于本话题的详实细节）
关于了解组件的owner和parent之间差异的极好的示例