[發明專利]一種信息表文件的讀取系統及方法

在審

• 申請號: 201711316384.8
• 申請日: 2017-12-12
• 公開（公告）號: CN108108411A
• 公開（公告）日: 2018-06-01
• 發明（設計）人: 王禮春
• 申請（專利權）人: 蘇州蝸牛數字科技股份有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京德崇智捷知識產權代理有限公司 11467
• 代理人: 王金雙

一種信息表文件的讀取系統及方法，所述系統包括：信息表文件轉換模塊和文件對象讀取模塊，其中，所述信息表文件轉換模塊，其以列為單位對信息表文件中的內容分組聚合，并基于表頭信息對分組聚合的內容進行轉換；所述文件對象讀取模塊，其采用流式解壓算法，讀取轉換后的信息表文件；再基于解析指示，解析轉換后的信息表文件的文件內容。本發明還提供一種信息表文件的讀取方法，文件存儲本身更小；讀取時無解析消耗，使用的時候才有解析；不需要構建信息存儲容器結構；CPU開銷更小、更穩定，更節約內存，用戶讀取更快速且實時。

技術領域

本發明涉及文件讀取技術領域，特別是涉及一種信息表文件的讀取系統及方法。

背景技術

現在越來越多的公司都會將Unity作為游戲開發的首選工具，而Unity游戲多是以C#語言開發、堆內存分配與回收機制運行的。Unity的讀取信息表文件(例如游戲的配置文件)的方法有很多種，大多都是以Unity資源加載方式為主、工具類解析為輔的方式完成。

目前主流的方法是采用微軟自帶的XmlDocument、第三方的XmlParse、TbXml、Unity序列化等工具類去實現，此外還可以采用一些基于Sql數據庫的文件表讀取查詢系統等去實現。但這些工具或者系統在運行效率、使用復雜度上均存在諸多不足：

首先，這些工具或者系統大多數都使用Unity文件讀取，在資源加載時需要為文件分配內存。

其次，在使用XmlDocument、XmlParse或者TbXml等工具類時，存在許多問題，比如：遍歷時存在大量CPU耗時；讀取時存在大量、臨時的解析內存分配消耗。讀取時，需要先將文件數據對象先全部解析再存儲到使用者定義的容器結構列表中來，假如一個文件是2M，解析的時候，甚至可以達到10M的臨時內存的分配，存儲的結構占用的內存可能需要4M。

此外，解析時，CPU的穩定也受到影響，容易產生瞬間峰值導致降幀。

綜上所述，這類文件讀取工具或者系統在讀取過程中都存在著不同程度的性能開銷或者使用問題。鑒于此，Unity自身提供了一種以序列化的方式讀取文件的方案。此種Unity的方案是將解析的過程轉移給Native層解析，雖然消耗降低了，但是無法解決文件配置信息被一次性全部解析到.net存儲空間中的問題。并且，在.net中只要將文件內存數據轉換為對象數據或者填充到使用自定義的結構列表中，就會產生消耗。也就是說，這個解析的過程或者構建過程本身就是一個性能消耗的問題。因此，目前文件系統中基本存在以下3類問題：

1)文件存儲資源本身占據的內存；2)解析文件產生的臨時內存；3)構建文件存儲結構的開銷。

發明內容

為了解決現有技術存在的不足，本發明的目的在于提供一種信息表文件的讀取系統及方法，能夠采用流式讀(讀取文件為流式解縮進行讀取)、不全讀(使用到的時候讀取，不解析讀不到的內容)、不構建(查找遍歷直接在當前數據空間中操作)的方式，實現信息表文件的讀取。

為實現上述目的，本發明提供的信息表文件的讀取系統，包括：信息表文件轉換模塊和文件對象讀取模塊，其中，

所述信息表文件轉換模塊，用于以列為單位對信息表文件中的內容分組聚合，并基于表頭信息對分組聚合的內容進行轉換；

所述文件對象讀取模塊，采用流式解壓算法，讀取轉換后的信息表文件；再基于解析指示，解析轉換后的信息表文件的文件內容。

進一步地，所述表頭信息包括：表頭大小、信息表行數、信息表列數、關鍵列、各列名稱、各列類型、列缺省值、各列數值區起始地址、列存儲區信息和列分區映射信息。

進一步地，所述信息表文件轉換模塊，還用于對信息表文件進行預處理，所述預處理包括：

獲取信息表文件的列數；

確定信息表文件中每列的數據類型；