以金山界面库（openkui）为例思考和分析界面库的设计和实现——资源读取模块分析

        为了表述方便，我们将以KUI自带的例子工程Sample1为例。在该项目的res目录下，我们看到一个名字为sample1.kui的文件。

        从这个特殊的后缀名.kui可以猜测出，这个文件是一个压缩文件。

        除了“读取String”、“读取Image”和“读取字体”资源外，我们可能比较难以猜测到其他过程做了什么。如果按照我前一篇的思路，“预处理资源文件”可能对应于“读取指定资源”，“打开资源文件”可能对应于“将压缩包文件解压”，是不是如此呢们拭目以待。在解读之后的代码之前，我有个疑问，这些操作如果有一步没有成功，还有必要继续往下走么么就没一个判断/strong>放下这个问题，我们看之后的代码。

        我们先看

        到12行，都是在Exe文件所在目录拼接出与Exe文件同名，但是后缀为kui的资源文件。比如我的电脑上，调试文件目录是D:快盘Code ProjectopenkuiSamplesSample1DebugSample1.exe，得到的pathRes对应的目录是D:快盘Code ProjectopenkuiSamplesSample1DebugSample1.kui。如果该资源文件独立存在于Exe目录下，则使用该文件做后续操作。如果该文件不存在，则从PE文件资源中，读取出类型为“SKIN”、名字为“kuires.data”的资源，并保存在memZipRes（一段内存中）中。

        这个流程，我们可以看出来，其大体思路和我之前猜测的一致，只是它增加了优先对独立的压缩包资源文件的处理。于是我们可以得出：Kui的界面描述文件，可以放在：
        1 Exe文件所在的目录下，名字和Exe相同的、后缀为kui的文件（以后简称界面文件包）中
        2 PE文件资源类型为“SKIN”、名字为“kuires.dat”的资源（以后简称界面内存块）中
        其中1的优先级要高于2。
        这种设计方案还是很有意思的。因为这个流程可以实现换肤功能。比如我们下载了A.kui、B.kui、C.kui和D.kui四套皮肤。如果用户选择了A皮肤，则我们可以将A.kui拷贝到Exe所在目录，并将其命名为与Exe同名、后缀为kui的名字。这样就实现了换肤。即使这套外置皮肤坏了，或者被删了，我们还可以使用资源中的那套皮肤。

        虽然想法很好，但是代码中的逻辑却存在一定的编码缺陷和设计缺陷，我们先说编码缺陷：

        这步，可以用来判断一个文件是否存在么实不可以。因为如果我新建一个与压缩包同名的“文件夹”，GetFileAttributesW将返回FILE_ATTRIBUTE_DIRECTORY，这将导致这个错误的逻辑认为该文件夹是一个压缩文件，从而导致之后的逻辑出现处理异常。该函数应该写成
        其中还有个设计缺陷。假如我们是使用这个库的开发者，我们在调试过程中，难免会修改界面描述文件。那么难道我们每修改一次，都要将描述文件压缩成一个包么样不是很难调用觉得，可以在PrepareRes函数中，新增一段对debug情况的处理：在debug情况下我们应该获取工程res目录下一个特定的文件夹，该文件夹保存了未压缩的各个文件。这样我们就可以不用每次修改资源后都要打个资源包了。
        我们在KAppRes类私有成员中增加
        在PrepareRes的pathRes.RemoveExtension();之前新增