初探百度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="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，它就會加載，不依賴的根本就不理會。並且，這一過程不影響文件的壓縮和合並（大讚！）

 1 {
 2     "res" : {
 3         "demo.css" : {
 4             "uri" : "/static/css/demo_7defa41.css",
 5             "type" : "css"
 6         },
 7         "demo.js" : {
 8             "uri" : "/static/js/demo_33c5143.js",
 9             "type" : "js",
10             "deps" : [ "demo.css" ]
11         },
12         "index.html" : {
13             "uri" : "/index.html",
14             "type" : "html",
15             "deps" : [ "demo.js", "demo.css" ]
16         }
17     },
18     "pkg" : {}
19 }

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富文本編輯器

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