js合并的必要性分析
一、效率因素
一般来说，在一个web工程中，需要使用大量的js，这些js可能来自许多提供者。
而在页面访问时，每次访问资源都要发起一个http请求，因此，即使文件已经缓冲，也需要发出一次http请求来确认文件是否被改变过。如果js个数比较少，那么没有什么问题，但是当js文件数目比较多的时候，就会导致页面访问效率下降。如果能把所有的js都合并为一个文件，那么就可以节省几百毫秒，甚至几秒的时间，视网络状况而定。如果不需要做任何人为处理，就节省下来这些时间，无疑是相当有意义的。
二、js引入顺序问题
如果说，效率问题还只是用户体验的问题，而js引入顺序问题，就会导致你的页面是否可以执行的问题。我们知道，如果js如果有依赖其它js库，则被依赖的js库就要放在依赖的js库的前面，否则就会发生js错误。当引用的js库比较小的时候，问题当然不大，但是做企业应用的时候，要用到的js非常多，甚至在开发后期或维护期还会增加新的js，这时稍有不慎，就会出现js引入顺序问题。
为此，tiny框架提供了解决方案，可以把工程中所有引用的js资源都根据依赖关系，按顺序放在一个js引用当中，它可以保证js的引用顺序是正确的，同时由于所有的js都只放入一个文件，因此，只会发出一次http请求；第三提供了文件压缩传输功能，所以会保证网络传输量最小。
从下图中，可以看到，引入的js只有一个文件：uiengine.uijs，总共用时609ms
再次访问，可以看到，静态资源都已经是304，全部来自缓冲了，其中js用时58ms。
实际上这里面包含的js文件有许多个，串行用时5434ms：
第二次访问的时间：js文件都已经是在本地缓冲了，串行用时395ms
两下做下对比：
合并为一个文件时，首次加载用时609ms，未合并为一个文件时，首次加载串行用时5434，节省时间：4825ms，时间比率为1:8.92，也就是说只有原来的11%的时间。
合并为一个文件时，缓冲后加载用时58ms，未合并为一个文件时，缓冲后加载串行用时395ms，节省时间：337ms，时间比率为15.7，也就是说只有原来的15%。
单纯从js加载方面来看，效率提升明显！
加上压缩过滤器，看看情况如何？
可以看到，原本5m的传输量已经变为936kb，访问时间为352ms，较压缩之前访问时间，少了237ms，时间是的58%，因此，访问时间有一定提升，尤其是网络带宽只有原来的18%，这个提升还是非常显著的。
不同的访问，数据会有一些差异，会有一些变化，但是总体来看差异还是显著的。缓冲后再访问，加载的串行时间比率为 1:合并文件个数，也就是说与合并的文件个数成正比。
新又增加了css合并，解决了图片资源引用的问题，有图有真相：
从图中看到，css都已经被合并到uiengine.uicss文件中了。
下面还有一个css没有合并，是由于这个是皮肤样式，要用来动态切换的，如果把它也合并了，就没有办法进行皮肤动态切换了。