總的來說，和JIT即時編譯機制有相通之處，就是一個創(chuàng)建時間的比較
首先要明白：客戶端的文件如果是最新的，那么創(chuàng)建時間肯定晚于服務(wù)器上文件的創(chuàng)建時間，反之客戶端的文件就是舊的需要更新了，但是為了提高更新效率，并不是一個個和服務(wù)器上的文件做對比
而是建立一個文件列表索引文件，里面記錄服務(wù)器上的“最新版”所有文件的創(chuàng)建時間，首先更新本地的索引文件，如果更新了，說明服務(wù)器上的文件列表有更新，然后和本地做對比，整理一份需要更新或新建的文件列表清單，然后主動連接服務(wù)器進行下載，全部完成以后，在索引文件進行記錄，更新完一個就記錄一個ok，這樣方便“斷點續(xù)傳”，所有都更新完成，全部是ok了，就證明本地都是最新的了，不過這里面有個小問題是值得注意的，本地文件的創(chuàng)建時間不能是本地計算機的時間，應(yīng)該下載完以后，修改成服務(wù)器的當(dāng)前時間，（比如如果本地時間設(shè)置到了一年以前）那本地的列表可能永遠(yuǎn)都是舊的，每次都要更新，這是可怕的。
通過這個文件列表索引，能大大提高更新效率，而且也能做好版本的控制。
另外，更新服務(wù)器一般和游戲服務(wù)器分離，大致思路就是這樣
打包和網(wǎng)絡(luò)傳輸方面，自己封裝一套序列化和反序列化的IO流協(xié)議就可以了，游戲里面這些都必須是最基本的功能了
當(dāng)然，這套思路還有一些不完善的地方，比如更新正在運行的exe或一些內(nèi)存保護的DLL，是比較麻煩的事情,需要盡量避免