最近除了忙各種各樣的期末考試、去西班牙的簽證，就是公司的那個韓國項目了。

　　我的任務基本完成——將原本單屏的遊戲改成三屏，完善整個 GUI系統 以及“劫持”了原遊戲中的一些邏輯，比如滾軸的排列可以任意控制等。由於原代碼中的GUI系統沒有文本編輯框，我還得自己寫一個。然而我對於IME的操作、GDI和DX的結合不是非常熟悉，所以還是參照了一下 ShowLong 所修改的微妙的平衡給HGE寫的中文解決方案。

　　完成了以上的任務之後，由於我的考試以及簽證問題以及我本身的任務差不多了，就把這個攤子就扔回公司去了。在交接的時候，老大給我派了一個任務，讓我來寫這個遊戲資源包的代碼。

　　原版遊戲代碼中有資源包代碼，但是寫得非常亂，於是需要我來寫一個新的文件結構、新的加密算法，然後仍然是“劫持”掉原代碼中的資源包加載函數。

　　在此之前，我拜讀了雲風的《遊戲資源的壓縮、打包與補丁更新》，有了點靈感。

　　最主要的就是其刪除這一塊。爲了讓用戶在更新的時候減少大量的文件IO操作，做法就是減少文件內容的大幅度移動。

　　而我便是參考了雲風大大的這個思想來寫我的文件包。首先因爲在遊戲中需要實時讀取，所以文件沒有壓縮，只是做了兩層加密處理，密鑰也是通過哈希得到的，所以每個文件的密鑰是不同的。

　　然後在文件索引的時候，我這裏是分了兩種索引：文件索引以及空塊索引。

　　所謂空塊索引就是：在文件包中刪除某一個文件的時候，不把後面的文件內容全部往前挪以覆蓋這一塊的內容、導致整個文件包在刪除文件之後的信息全部往前挪而產生的大量IO操作，而是對這一塊內容不作任何處理、把這一塊內容的索引從文件索引中移除並附加到空塊索引中以供以後新文件加入時所用，這樣就只產生了一點對於索引的文件IO更新，不過索引的更新充其量也就那麼點，相對於文件的操作來說只是九牛一毛，當然前提是這個索引是在整個文件包的最後。而在有新文件插入的時候，先在空塊索引中找有比新文件大的空塊，如果有的話就直接把這個文件插入到那個空塊中，然後更新一下文件索引以及空塊索引即可，這裏又少掉了一些IO操作。

　　正如雲風所說：

如果新增加的文件較之小，就重複利用這個空間。如果利用不上，就浪費在那裏。這有點像內存管理算法，時間久了，資源包內會有一些空洞，但也是可以接受的。

　　接着就是資源包在遊戲中的使用了。在原先的遊戲代碼中是有判斷重複加載的代碼，也就是說把已加載的資源存到node裏，在之後再次需要加載這個資源（通過文件名判斷）就直接從node中去，這樣就少了很多內存開銷，尤其是當我把單屏改爲三屏之後，這樣的優化效果更爲明顯（否則相同的資源要加載三次，等於消耗了三倍的內存）。不得贊一下這05年開發的代碼，雖然是棒子。不過原遊戲代碼中的高耦合度讓我蛋疼。

　　想到以後這個資源包類要用到以後的一些項目，於是我自己也寫了一個Cache機制。就是在一個包中，當加載某個資源的時候，順便把這個資源的Buffer加到一個Cache中，當下次再需要用到這個資源的時候就直接從Cache中取就好了，實際上這就還是之前的代碼實現的功能，只不過我自己在這基礎上精簡了一下。最後寫一個ClearCache的函數能清除Cache，我這個資源包類就算完成了。

　　還有在獲取資源的時候，爲了防止內存突增，我的Buffer是一段一段獲取的，類似於Socket中的獲取消息一直到消息結束爲止。當然，每一段Buffer的大小是可以自己傳進去的。我這種以時間換空間的做法還沒自己實際測試過效果如何，只不過是自己想想可能會比較優罷了，因爲最近實在是太慢，這篇日誌還是考完了概率然後摸着黑地寫的。

　　我對文件系統本身不是非常瞭解，操作系統還沒考呢。所以我現在僅僅做到的是雲風九年前的一種設計，然後加上了原先代碼有的Cache機制而已。不過寫下這篇日誌來記錄我自己成長的足跡罷了。