一、静态资源映射表
- 记录文件依赖、打包、url等信息的表结构，fis2中称之为map.json，但在fis3中默认不产出，对其做了优化。当某个文件包含字符__RESOURCE_MAP__时，就会用表结构数据替换此字符，就不再固定把表结构写入某一个特定文件，方便定制。
二、模块化开发 AMD/CMD,以及require.js、sea.js等前端模块化框架，主要给js提供模块化开发的支持，之后也增加了对css、前端模板的支持。这些框架就包含了组件依赖分析、保持加载并保持依赖顺序等功能。- fis中依赖本身在构建过程中就已经分析完成，并记录在静态资源列表中，那么对于线上运行时，模块化框架就可以省掉依赖分析这个步骤了。同事，js还需要有运行时支持，所以对于不同的前端模块化框架，在js代码中编译分析依赖增加了几种依赖函数的解析：define() / require(‘’) / require.aysnc(‘’) /require.aysnc([ ]).
- 考虑到不可能一个框架运用多个模块化框架（因为全都占用相同的全局函数，互斥），所以编译支持这块分成三个插件进行支持：
* fis-hook-commonjs
* fis-hook-amd
* fis-hook-cmd
* 在fis-config.js中： fis.hook('commonjs')；
- 但这个插件也只是对编译工具的扩展，支持前端模块化框架中的组件与组件之间依赖的函数，以及入口函数来标记生成到静态资源映射表中，另外一个功能时针对某些前端模块化框架的特性自动添加define。但如何把资源加载到页面上，需要额外的fis构建插件或方案支持。
- 如纯前端项目，依赖插件fis-postpackager-loader，这是一种基于构建工具的加载组件的方法，构建出的html已经包含了其使用到的组件以及依赖资源的引用：npm install -g fis3-postpackager-loader在配置中添加fis.match（‘::packager’, { postpackager: fis.plugin(‘loader’ , { }) }）.
- 为了方便、统一管理组件以及合并时便利，需要把组件统一放到某些文件夹下，并设置此目录下的资源都是组件资源。 fis.match(‘/widget/**.js’ , { isMod : true});
- 工具扩展、目录规范，前后端的前段工程项目都需要，其不同之处就在于静态资源管理这部分。
- 编译工具扩展–根据笔筒前端模块化框架，扩展声明依赖能力
- 静态资源管理–解析静态资源映射表加载页面用到的组件以及组件的依赖
- 目录规范： 设置某个文件夹下资源标记为依赖
三、资源映射表的模块化设计方案
四、解决方案封装
解决一系列特定问题的工具、规范、开发、上线支持的方案，被称之为解决方案。前端一般包括： 研发规范+模块化框架+测试套件+辅助开发工具。fis3就是把这些集成到一个工具中，一个解决方案就是继承自fis3并且支持特定模块化开发、特定模板语言、研发规范的构建工具。- 必要性：规范开发方便开发树立品牌
- 解决方案封装：
准备方案名、构建工具名字、模板语言、模块化框架选择、特定目录规范
目录规范： static–静态资源、page–页面、widget–组件，fis-config.js–配置文件
部署规范：template–所有的php模板，static–所有的静态资源
开发
五、基于smarty的解决方案
- fis3-smarty集成了fis-plus的目录规范以及处理插件，实现对smarty模板方案的工程构建工具支持。
- smarty本身就是php，同时提供了若干插件，当真正和后端分离是不需要有后盾支持就能用插件的方式解决静态资源管理这件事。
- 原理： 模板依赖某个组件（js。css。模板）不再直接引入，而是添加依赖，这些依赖在fis本地编译的时候会产出依赖树，我们一直都叫它静态资源映射表。
- fis本身是依赖某种js组件化加载规范，
六、基于PHP的解决方案 解决问题：安装php-cgi和java，把项目发布到apache等本地安装好的服务器目录下预览调试。支持模块化开发、组件开发、自动分析资源依赖关系、自动把js/css放在底部输出，提升页面渲染能力，收集组件中的内嵌样式或脚本。如何做：fis静态资源管理的核心是map表，