引入：

多数人为了调试目的，会吧css_fast_load设置为0 ，这样可以看到每个单独的css样式文件的加载，而在产品服务器上，为了提速，又会吧这个参数设置为1，这样多个css文件又会合并成单个，那么这其中的奥秘又如何呢？


调试分析：

趁着Sprint最后一天的空闲时间，我幸运的分析了Liferay源码，并且找到了其中的奥秘。


当请求为http://<host>:<port>/?css_fast_load=1的时候：

因为加载页面的css总是从各个模块的main.css加载的，所以，当我们加载的是platform-In-theme下的main.css时候，它会进入PortalImpl的getStaticResourceURL方法：

100614384.png


它先在第3515行从request对象中获取ThemeDisplay,再从ThemeDisplay中获取Theme和ColorTheme


然后，它就开始为我们的请求资源附加上各个参数了。


首先，它在3531-3532行加了一个问号(?)用来区分参数和前面的请求路径。

100753990.png


然后在3534-3541行加上browserId参数，这个是通过BrowserSnifferUtil工具类获得的，因为这不是我们的讨论重点，所以我们不展开。

100856354.png


然后在3543-3550行加上themeId参数。

100936769.png


然后在3552-2558行加上colorThemeId参数。

101015818.png


下面，最重要的，就是加上minifierType参数了。

101101448.png

从上面可以看到，要设置minifierType=css必须有2个条件，1是uri以css,jsp结尾，2是必须开启themeCssFastLoad.而设置minifierType=js必须满足开启themeJsFastLoad。


因为在我们的例子中，我们的请求最后带了css_fast_load=1,所以themeDisplay.isThemeCssFastLoad为true,所以我们的请求参数加上了minifierType=css.

101211133.png


所以，这里也可以看出，如果我们的请求是不带参数（这种情况下会使用portal.properties中的theme.css.fast.load默认值false）或者css_fast_load=0,那么这个themeDisplay.isThemeCssFastLoad为false.请求就不会加上minifierType=css.


接下来，第3594-3597行会加上languageId参数.

101317133.png


第3599-3602行会加上build number参数：

101354559.png


第3604-3620会加上timestamp参数：

101438898.png


所以最终把这些参数都拼接在原来的访问platform-In-theme/css/main.css的后面，就形成了最终的访问url.

101519663.png


当然了，我们这片文章主要的重点是cssfast load ,minifyType，

所以我们可以看到:

a.当请求url中有css_fast_load=1的时候，这个请求参数是有minifierType=css的，这也和页面上看到的一致（在另外一台机器上实验的）：

101650370.png

b.当请求url中css_fast_load=0或者没有这个参数时候，请求参数是没有minifierType=css的。

101752422.png


而这一切都发生在进入MinifyFilter过滤器之前。。接下来就看这个参数是到底怎么影响MinifyFilter的了。


因为不管如何后面参数如何，这个请求到底是个css请求，因为我们的请求是/platform-In-theme/css/main.css,所以它匹配Minifier Filter的url pattern

101940484.png


所以会去走MinifierFilter的processFilter（）方法，这方法会进而调用getMinifiedContent()方法：

102100302.png

这里可以看出它在第284行会去读取参数中的minifierType参数，因为我们的例子中是用的css_fast_load=1，所以这里的minifierType字符串就被为”css”,如果我们没有设置css_fast_load=1参数，那么这个minifierType字符串就为空。


而第290行可以看到，如果minifierType为空的话，那么就直接跳过这个getMinifiedContent方法的后面执行了。因为我们minifierType不为空，所以会继续走下去，一直走到第348行，

102911897.png

它判断如果资源文件是css扩展名，那么调用minifyCss方法，这个方法才是把多个css文件合并，去除段落空白，再用yui-compressor压缩合并。这个方法的细节可以在下面一篇文章中讲。


至少可以总结的是，如果css_fast_load为1，那么会调用minifyCss方法，如果css_fast_load=0,那么压根不会调用minifyCss方法。



总结：

从上面调试中，我们至少可以获得以下结论：

(1)在进入MinifyFilter过滤器之前，Liferay框架会给每个资源的请求附加上若干个参数，其中必定有的参数包含：browserId,themeId,languageId, build number,timestamp.

(2)minifyType这个参数是可选的，如果请求中带上了css_fast_load=1，或者你覆盖了portal.properties中的theme.css.fast.load=true,那么会附加参数minifyType=css. 如果请求是css_fast_load=0或者你用默认的portal.properties中的theme.css.fast.load配置，那么不会附加这个参数minifyType. 对于js资源也是一样。

(3)当请求css资源时候，它会进入Minifier Filter过滤器，这个过滤器会去检查minifyType=css|js参数。如果这个参数被设置了，比如说是minifyType=css,那么它会去调用minifyCss方法吧多个css合并，如果这个minifyType没有被设置，那么会跳过这个方法的下面执行，也就是不进行迷你化操作。