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

王福朋發表於2015-09-06

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

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

 

相關文章