......我正在研究几种理论，但我很想听听其他意见。
这已经在三台不同的机器上验证过了，另外两台是linux。使用的编译器是flexbuild（推测mxmlc）和ant与mxmlc。
我们将代码添加到一个小的独立单个.as文件项目中，编译后的swf文件大小减少了20k，从linux盒子上的32k减少到12k。窗户盒子略有不同，从27k到8.5k。
使用自定义工具，我们已经验证两个版本都使用本机swf压缩，没有大量的额外元数据，对ant构建脚本的唯一修改是将 swc文件添加到构建中。
没有删除代码（没有导入删除，没有可变删除，虚无），只有添加和非常简单，添加到舞台上的几个组件，启用，几个小函数等，没有修改循环，没有什么可以导致更少的代码。
使用源代码控制来构建旧版本仍会产生更大的文件，因此它似乎不是库或编译器的更改。
没有任何代码使用Flex组件，只是直接“flash.etc ...”类型导入。
有没有人见过这样的行为？您认为这会导致什么？
答案 0 :(得分：2)
之前在.NET程序集中已经看到过这种行为。
我对这种行为的猜测（无论它发生在哪里）是无论添加什么都允许编译器进行比以前更多的优化。
为什么这可能需要比我更详细的编译器内部工作知识（以及为什么会发生这种情况 - 如果这实际上是这里的原因 - 在你的情况下可能只能充分解释由Adobe工程师）。
答案 1 :(得分：0)
我只是在猜测，但是当涉及文件这么小时，也许你看到硬盘驱动器部门的松弛？
答案 2 :(得分：0)
我的第一个预感是第一个swf是在调试模式下编译的，它增加了一堆信息。如果情况并非如此，那么我猜第二个是用-optimize = true编译的。
但如果两者都不是这样，那确实非常有趣！
答案 3 :(得分：0)
我之前也见过同样的行为。我认为它是两个因素的组合：优化和压缩。您的新代码可能允许优化器以不同的方式执行操作（或者，非直观地，阻止某种内联或循环展开它以前执行的操作）。我认为现有的附加数据更有可能使其成为更好的压缩候选者，因为所有的Flash文件都是压缩的，因此压缩它的效率更高。这两种理论都只是半教育的猜测。