引入:
現在我們接著上文章討論來解決疑問3:對於快取檔案已經存在和不存在的情況有什麼特別處理。
分析:
現在我們先來看下如果快取檔案已經存在時候的處理方式:
因為我們開始已經建立了一個快取檔案,它的base名字為$CATALINA_TMPDIR/liferay/css/portal/6476841388170400461
650) this.width=650;" src="http://img1.51cto.com/attachment/201308/160623788.png" title="31.png" />
假定我們上次訪問的路徑是main.css檔案,那麼這次當我們再訪問main.css檔案的時候,我們就發現它走了第120行。它會先判斷快取檔案的最後修改時間戳記(cacheDataFile.lastModified())和原始檔案的最後修改時間戳記file.lastModified()),如果前者偏大,則說明快取檔案是最新的,那麼它就124行直接把快取檔案的內容類型檔案的contentType讀取出來,然後
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1126114417-1.png" title="32.png" />
第126行吧httpServletResponse的傳回型別設定為這個快取檔案內容類型回想以前曾說過,第一次設定時候這個值應該是text/css),最後吧緩衝的資料檔案放到輸出資料流中。
然後在第DynamicCSSFilter中第217行用
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/112611IQ-2.png" title="33.png" />
使用ServletResponseUtil 讀取這個快取檔案中的內容並且輸出到用戶端。
所以用戶端就可以獲得最新版本的解析後的普通css資源檔並且使用了。這個過程中並沒有JRuby解析Sass產生css,所以減少好多IO操作,效率提高了很多)
下面我們再來看下緩衝不存在,從頭產生這些檔案的例子:
假如我們清空了tomcat的temp目錄吧這些快取檔案都清空,那麼顯然,它沒辦法走緩衝路線也就是不走if(cacheDataFile.exists()分支),所以它會去產生新的。
讓我們回到原始的討論,如下所示,在142行是從原始的帶Sass的樣式檔案中讀取的css檔案,存放到content中
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1126115507-3.png" title="34.png" />
然後第144行解析Sass檔案擷取的普通css檔案存放到dynamicContent中,我們可以比較看出明顯不同.
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1126115225-4.png" title="35.png" />
尤其是在@import這種文法後,轉為的新的都加了很多參數。
這時候,調用第149行的FileUtil.write(cacheContentTypeFile, ContentTypes.TEXT_CSS)會寫入內容類型檔案:
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1126113P1-5.png" title="37.png" />
從伺服器看,目前的目錄下只有一個檔案<baseName>_E_CONTENT_TYPE,這是合乎情理的,因為資料檔案還沒建立呢,才剛剛寫內容類型檔案,而且寫的時間也和當前的時間戳記吻合,說明是剛才才寫入的這個檔案,並且這個檔案內容只有text/css,所以這個檔案很小,只有8個位元組。
然後第193行,就會吧產生的普通css檔案內容也就是存放在dynamicContent變數中)寫入到資料檔案中,調用是第193行FileUtil.write(cacheDataFile.dynamicContent);
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1126115539-6.png" title="38.png" />
我們看下伺服器目錄,果然現在產生了<baseName>_E_DATA檔案:
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1126113015-7.png" title="39.png" />
這個檔案從時間戳記看比剛才的內容檔案晚5分鐘,這也合乎常理,因為我在調試,要單步走,並且還有,寫文章,所以確信,這正是調試驗所執行到時候建立的檔案,並且檔案大小是874位元組,這個也剛好和我們的dynamicContent的大小一樣,如:
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/11261121T-8.png" title="40.png" />
一切都是那麼吻合和完美。
結論:
(1)當請求的資源檔已經在Liferay的緩衝中也就是在$CATALINA_TMPDIR/liferay/css/folder/<hashcode>時候,伺服器會去比較緩衝中的資源檔的最近使用時間戳和原始資源檔的最近使用時間戳,如果緩衝的時間戳記比較新,那麼就直接從緩衝中讀取內容類型資訊和被解析後的普通css檔案,然後構造輸出資料流輸出到用戶端。
(2)當請求的資源檔沒有在Liferay緩衝中,那麼Liferay架構會自己在緩衝目錄中構建相應的目錄和檔案,並且先是寫內容類型檔案,再寫快取資料檔案Sass解析後得到的普通css檔案),最終把這些內容通過輸出資料流輸出到用戶端。
本文出自 “平行線的凝聚” 部落格,請務必保留此出處http://supercharles888.blog.51cto.com/609344/1282865