打包策略 about fis HOT 4 CLOSED

@wentworthzheng

fis内置的插件，打包不支持重复文件。如果文件允许重复，读取map.json的那个框架的算法会很复杂，性能比较差。

from fis.

@wentworthzheng

举个例子，比如你有a、b、c、d、e、f这6个资源，打包方式是：

p0 : a+b+d
p1 : a+b+e+f

当我页面需要用 a、b、d、e的时候，可选的方案有：

方案1：p0 + e
方案2：p1 + d

都是两个请求，然后后端框架还要计算带宽量。

虽然理论上，可重复打包能进行更细致的打包结果控制，但这种策略有些算法上的缺陷，在运行时需要枚举所有可能的组合方案，是一个动态规划问题，fis曾经是这样的算法，后来发现这样做得不偿失，就放弃了，改用更简单的打包去重策略。

from fis.

@wentworthzheng

此外，可重复包通常因为这样类似的需求：

我有A、B两个页面，A页面用了a、b、c，B页面用了a、b、d。
我希望：
    A页面引用p0(a+b+c)包，B页面引用p1(a+b+c)包，这样每个页面都只有一个请求了。
    符合雅虎14条军规中关于减少http请求的要求。

这种说法具有一定的合理性，我们单独看A或者B页面，或许能得到这样的结论，如果A、B两个页面是完全没有联系，彼此没有任何可达性，这样的结论比较合理。但如果AB在一个网站内，并且相互可达（用户访问A或B页面之后，可能在短时间内再访问B或A页面），那么我们或许应该让AB页面共享a+b资源的浏览器缓存，而使用这样的打包策略：

p0 = a + b；
A页面 = p0 + c;
B页面 = p0 + d;

虽然每个页面都有两个请求，但用户在网站内浏览时，可以共享p0资源，而c、d每个页面单独下载，没有浪费的带宽。这个道理符合雅虎14条军规中的“使用缓存”相关要求。

from fis.

@wentworthzheng

综上所述，从资源管理算法到统计层面的缓存利用率，不重复打包策略具有简洁、高效的优势，所以fis比较倾向这种策略，虽然可能不是最完美的结果。

from fis.