初探百度F.I.S — 由工具到解决方案

1. 前言

　　阅兵放假三天，我哪儿也没去，宅着看了一些东东：git命令行、svn命令以及下面的主角——百度FIS。对看过的git、svn的命令也做了一些总结，请参见：《git命令学习笔记》和《svn命令学习笔记》

　　另外，我是开源富文本编辑器 wangEditor 的作者，欢迎大家关注我的项目。下文也会结合我在开发该编辑器过程中的经历，来对比说百度FIS

　　在查看下文之前，可以先说一下我初探百度FIS，对它的一个总结——由工具到解决方案。不知道大家对“工具”和“解决方案”这两个词如何理解，以及它们之间的区别。如果你有兴趣，不妨跟随着我的文字，一起来认识一下百度FIS。

　　PS：本人刚刚学习百度FIS，有任何理解不到位的地方，还请各位多多指正！

　　本文主要针对各位web前端开发人员，对此无兴趣的请绕道

2. 什么鬼？

　　不知道百度FIS的同学，估计第一句话就是要问：“是什么鬼？”

　　不知道FIS无所谓，但是作为一名web前端开发人员，你至少要知道目前前端比较流程的“工程化”、“自动化”或者再高大上一些的“工业化”这些词吧？目前比较流行的工具有 grunt、gulp 等。如果这个都不知道，建议抓紧时间去恶补一下，亡羊补牢为时不晚，这种工具入门都很简单，推荐教程《用grunt搭建自动化的web前端开发环境》

　　至于为何web前端要用自动化、工程化，有什么好处，本文就不多说了，不是本文重点。总之它是很重要的。

　　百度FIS也是一个致力于web前端自动化的工具，而且它比常用的那些工具考虑的东西更多，因此实际上它就是一个web前端自动化的解决方案了。

　　了解了百度FIS的基本内容，现在虽然你还是什么都不知道，但是你仍然可以捕获到以下信息：

• 百度出品：百度是一个非常重视技术的公司，FIS由专业团队维护，应用于多个百度产品，这本身就是一种吸引力；
• 解决方案：小型项目中体现不出来，但是一旦到了大型项目，多人开发，解决方案的优势就体现出来了。所以，你做大型项目，可以考虑百度FIS；你不做大型项目，看看百度FIS至少能提高自己的眼界和高度。

3. 工具 VS 解决方案

　　看到这里，激动的你是不是着急要一个demo来见见庐山真面目？—— 别着急。

　　你着急要demo、要 quick start ，因为你觉得看看什么样子是最重要的。而我觉得比这个更加重要的是，我要用形象的语言给你描述出百度FIS的最强优势，即工具和解决方案的区别。

　　举一个栗子：excel是一款很强大的表格软件，里面有各种公式的计算，但是你能用它做一个很复杂的财务表格吗？但是一些专业财务软件则可以通过一些配置来生成出这样一个财务表格。同样是excel，同样是应用的那些公式。前者就是工具，后者就是解决方案。

　　grunt 和 gulp 都是很不错的平台，其下有N多个插件，但是这么多插件都是干什么用的，你的项目中应该用哪些，你一开始未必知道。想知道你就得花时间成本去研究，但可不是每个人都有、或者愿意拿出那么多时间去研究的。

　　而百度FIS恰巧解决了这个问题，它把常用的东西都集成起来，打包起来，任何流程和操作都变得一键化、傻瓜化、统一化，拿来就用。而且，你只需要根据它规定的这些操作来就行，不用考虑太多。

　　这样描述，想不想刚才说的excel和财务软件的关系？技术都是一样的，只不过应用的效果不一样。

　　解决方案的好处：

• 对于管理者：从项目管理上来说，减少了开发和管理的成本，因为不需要每一个开发人员都去弄懂那些插件、配置等等；从开发角度，有利于不同技术的集中和分组，让每个成员往专业方向发展，提高整体团队能力。
• 对于开发者：不想当厨子的司机不是好士兵，如果你是一个有心的开发者，接触FIS这样的框架，能提高你对系统架构和开发流程的认识。

4. 只有三个命令

　　PS：FIS文档页面 http://fex-team.github.io/fis-site/docs/beginning/getting-started.html

　　百度FIS首页给出的广告词：三条命令，满足所有前端开发需求。这三条命令分别是：

　　fis install　　

　　该命令可以安装一些项目中用到的公共组件，例如jquery、echarts等等，可参见组件仓库，这个主要是用来部署、初始化项目环境。

　　fis release

　　把当前的项目发布。release是一个很重要的过程，大家都知道，web前端的开发结构和最后发布的结构，大部分情况下是不一样的。例如会有文件路径的变化（img放在一起、css放在一起等），文件的合并和压缩、增加md5戳用以缓存，还有好多自定义的操作。

　　针对这些操作，FIS考虑的非常详细，都体现再它的文档中。你指需要参照文档，看看哪些是你需要的，你加上即可。哪些你不需要，你屏蔽掉即可。几乎所有你能想到的，文档中都有，几乎不需要再去查资料了。

　　（这就是解决方案的能力）

　　fis server

　　运行发布环境，测试用。grunt 和 gulp 都是没有集成 server 功能的，我在开发 wangEditor 时，一直用一个基于 nodejs 的 http-server 插件来提供静态服务。

　　大家想一下，web前端的开发过程中，怎么可能用不到 server ？FIS带有 server 功能，这是一个解决方案的正常体现，grunt 没有 server，这也是一个工具的正常体现。

　　还没完，FIS 的 server 不仅仅可以给前端提供服务，通过配置它还可以支持 java、php、nodejs 的后台，这对于日常的运行和测试，也是极为方便的。而我用的 http-server 就不行啦，不过好在 wangEditor 用不到后台语言。

　　

　　至此，你可以想一下，在实际开发过程中，除了以上说的 install release 和 server 之外，还有哪些东西你觉得应该有，而这里没包括？我第一次看到这三条命令的时候，我首先思考的就是这个问题，但是很遗憾我没有想出来。其实也不用想，FIS这三条命令既然能用于百度那么多项目，为何就不能满足自己的项目呢？

　　至于这三条命令如何使用，大家完全可以去文档页面大体看一下，或者自己花几分钟做一个demo，入门还是比较简单的。

　　PS：FIS文档页面 http://fex-team.github.io/fis-site/docs/beginning/getting-started.html

5. 三种语言能力

　　在上文的 fis release 命令提到，FIS 在发布一个项目时候，要对项目进行分析，例如文件目录的变化、文件的压缩合并、以及应对这些操作混合起来产生的结果。

　　开发时，index.html 引用了 a.css 和 b.css ，发布时，两个 css 整合成了 x.css ，那么 index.html 里面是不是应该引用 x.css ，这是必须的！

　　—— 其实，应对这么多情况，是一个很复杂的事情。

　　FIS 开发团队自己也承认，在这一过程中走了很多的弯路，但是最终它们总结出了能应对以上所有情况的三条技能（它们称之为“三种语言能力”）：

　　第一，资源定位

　　开发时，我们写静态资源一般都会用相对路径，如 src = '../a.js'，而发布时候如果静态资源变了位置，相对路径就无效了。所以，FIS要求自己必须有能力去定位一个资源的位置，无论怎么变，都能找到，并根据最新的位置，给出正确的相对路径。

　　第二，内容嵌入

　　最常见的就是css、js等静态文件的合并、img的合并（css sprite），以及把 img 转换为64位编码放在网页中。除了这些之后，你还可能希望将一个独立的 css、js 文件，直接把它的内容嵌入到 html 网页中，而不是引用。

　　以上这些，只要涉及到文件内容变化的，都算是资源嵌入。

　　做到这一点，FIS借助了一些成熟插件，如uglify；FIS也定义了自己的一些书写规则，如 <img title="百度logo" src="data:images/logo.gif?__inline"/> 发布之后，img就会变为64位编码形式（重点在“__inline”标识）。

　　第三，依赖声明

　　javascript模块定义有AMD、CMD、commonJS等规范，它们都有依赖这么一个概念，一般用 require() 函数描述。前端模块依赖的工具，一般都是 requirejs 和 seajs ，大家在项目中也比较常用。

　　FIS 作为一个解决方案，难道是把 requirejs 或者 seajs 移植进来了？—— NO —— FIS有自己的思考（也有资料显示，FIS的这块思路是参考的facebook的技术，这里就不去纠结了）

　　requirejs 或者 seajs 能解决前端模块化，但是它们有些情况是应付不了的——要不然百度FIS（或者facebook）也不可能再重新造轮子。这种情况就是当网站结构变得相当复杂的时候：一来，requirejs 和 seajs 出现性能问题；二来，这时候光靠前端是解决不了所有问题的。

　　这段很有意思，下文另起一题继续。

6. 前后端结合的高效静态资源管理

　　首先，强烈建议大家看看这篇文章：http://fex-team.github.io/fis-site/docs/more/mapjson.html ，下文就是这篇文章的梗概。这篇文章很好理解，个人感觉也很有创造性。

　　这篇文章的大体意思就是：我们如果完全用传统的前后端分离模式，用传统的前端性能优化（压缩、合并、减少http）等，是无法最大程度的优化性能。最根本原因就是两个字——静态——对静态资源的管理是静态的。

　　解释一下，由于我们采用传统的前端性能优化模式，所有的css、js这些静态资源，都是压缩之后引用到网页上的。压缩之后就是一个大杂烩，有用的没用的，甚至是已经废弃的代码，都在这里面。如果只通过前端优化手段，我们只能做到这一点。那么 FIS 是如何解决这一问题的？

　　FIS 在 release 项目时候，会生成一个 map.json 的文件（代码如下），这个文件不是给前端用到，而是给后端（如 php）用的。php 拿到这个文件之后，会知道一个网页到底依赖于哪些css、js，它就会加载，不依赖的根本就不理会。而且，这一过程不影响文件的压缩和合并（大赞！）

 {
     "res" : {
         "demo.css" : {
             "uri" : "/static/css/demo_7defa41.css",
             "type" : "css"
         },
         "demo.js" : {
             "uri" : "/static/js/demo_33c5143.js",
             "type" : "js",
             "deps" : [ "demo.css" ]
         },
         "index.html" : {
             "uri" : "/index.html",
             "type" : "html",
             "deps" : [ "demo.js", "demo.css" ]
         }
     },
     "pkg" : {}
 }

map.json 示例

　　（不明白的同学，急需要看看上文给出的那个链接）

　　这一过程将消耗很小的后台性能，但是却大大提高了前端性能，项目越复杂，提高的就越明显。

7. 总结

　　首先，上文并没有写完 FIS 的所有东西，毕竟这不是 FIS 的文档。这里写的只是我认为 FIS 中非常重要的概念、FIS 给我留下印象最深的东西。

　　通过上面的描述，读者应该能发现，FIS 确实已经到了解决方案级别，它包含了项目的初始化、开发、发布、运行测试、最大程度的性能优化、以及我们本文没有提及的组件化，等等，这些你在小型、大型系统中用到的所有东西。相比之下，grunt 和 gulp 这类工具性的东西，就有些黯然失色，特别是在大型项目中。

　　另外，基于 FIS 还扩展了其他的解决方案，例如纯前端的 pure ，基于 java 的 jello ，基于 php 的 fis-Plus ，基于 nodejs 的 yog2，基于 go 的 gois ……

　　作为一个有理想的技术骚年，你是否已经被 FIS 所吸引？

　　我正在考虑我自己的开源项目 wangEditor 是否也应该切换到 FIS 平台，虽然 wangEditor 是一个很小的插件，哈哈。

-------------------------------------------------------------------------------------------------------------

欢迎关注我的教程：

《使用grunt搭建全自动web前端开发环境》《从设计到模式》《json2.js源码解读视频》

《深入理解javascript原型和闭包系列》《css知多少》《微软petshop4.0源码解读视频》

------------------------------------------------------------------------------------------------------------

也欢迎关注我的开源项目——wangEditor，轻量化web富文本编辑器

-------------------------------------------------------------------------------------------------------------