3

...我正在研究几种理论，但我很想听听其他意见。

这已经在三台不同的机器上得到验证，两个 Windows 另一个 linux。使用的编译器是flexbuild（大概是mxmlc）和ant with mxmlc。

我们将代码添加到一个小的独立单个 .as 文件项目中，编译后的 swf 文件大小减少了 20k，在 linux 机器上从 32k 减少到 12k。windows 盒子上略有不同，从 27k 到 8.5k。

通过自定义工具，我们验证了两个版本都使用原生 swf 压缩，没有大量额外的元数据，对 ant 构建脚本的唯一修改是在构建中添加一个 swc 文件。

没有删除代码（没有删除导入，没有删除变量，nada），只有添加并且非常简单，几个组件添加到阶段，启用，几个小功能等，没有修改循环，没有什么明显的将导致更少的代码。

使用源代码控制来构建旧版本仍然会导致文件更大，因此它似乎不是库或编译器中的更改。

没有代码使用 Flex 组件，只是直接“flash.etc...”类型导入。

有没有人见过这样的行为？您认为这可能是什么原因造成的？

4

4 回答 4

2

以前在 .NET 程序集中看到过这种行为。

我对这种行为（无论它发生在哪里）的猜测是，无论添加什么，编译器都可以进行比以前更多的优化。

为什么这可能需要比我更详细地了解编译器的内部工作原理（以及为什么会发生这种情况——如果这实际上是这里的原因——在你的情况下，Adobe 可能只能充分解释工程师）。

于 2008-10-27T19:30:54.720 回答
0

我只是在猜测，但是当涉及到这么小的文件时，也许您会看到硬盘驱动器扇区的松弛？

于 2008-10-27T19:34:18.457 回答
0

我的第一个预感是第一个 swf 是在调试模式下编译的，它添加了一堆信息。如果不是这种情况，那么我猜第二个是用 -optimize=true 编译的。

但是，如果两者都不是，那确实很有趣！

于 2008-10-27T20:20:27.740 回答
0

我以前也看到过同样的行为。我认为这是两个因素的组合：优化和压缩。您的新代码可能允许优化器以不同的方式做事（或者，不直观地，阻止了它之前所做的某种内联或循环展开）。我会说存在的附加数据更有可能使其成为更好的压缩候选者，因为所有闪存文件都被压缩，因此压缩它的效率更高。这两种理论都只是半知半解的猜测。

于 2008-10-27T20:58:45.027 回答