以金山界面库（openkui）为例思考和分析界面库的设计和实现——资源读取模块分析
按照软件的执行流程，我们首先遇到《以金山界面库（openkui）为例思考和分析界面库的设计和实现——问题》中提出的最后一个问题：界面描述文件的放置位置。我们曾提出一种方案：将界面描述文件打包后放在资源文件中；在使用时，解析并读取资源文件。实际上Kui也是按照我们这个思路在做的，只是做得比我们要精巧。在阅读这部分代码的过程中，我发现其存在一定的编码缺陷以及设计缺陷。我会在文中适时指出问题并提出修正及改进的方案。（转载请指明出于breaksoftware的csdn博客）
为了表述方便，我们将以KUI自带的例子工程Sample1为例。在该项目的res目录下，我们看到一个名字为sample1.kui的文件。
在Sample1工程的资源文件中，上图中sample1.kui将作为一个类型为“SKIN”，名字为“KUIRED.DAT”的资源。
从这个特殊的后缀名.kui可以猜测出，这个文件是一个压缩文件。
这样，我们心里有了底，同时为我们阅读Kui的资源管理代码提供了视觉上的参考。
在openkui\KUILib\kscbase\src下有个文件kscres.cpp。它定义了资源文件处理逻辑。
首先，我们查看这段代码
KAppRes& KAppRes::Instance()
{
static KAppRes _singleton;
return _singleton;
}
可以看出，这是个单例类。因为界面描述数据只需要读取和解析一次，所以这儿设计成单例类。以后使用它的地方，就不用重复读取和解析了。
我们再看下作为私有函数的构造函数，它显示该类执行的脉络
KAppRes::KAppRes() : m_hTempRes(INVALID_HANDLE_VALUE)
{
PrepareRes();
OpenResPack();
LoadStringRes();
LoadImageRes();
LoadXmlRes();
LoadFontRes();
}
粗略看了函数名。可以得出如下流程
除了“读取String”、“读取Image”和“读取字体”资源外，我们可能比较难以猜测到其他过程做了什么。如果按照我前一篇的思路，“预处理资源文件”可能对应于“读取指定资源”，“打开资源文件”可能对应于“将压缩包文件解压”，是不是如此呢？我们拭目以待。在解读之后的代码之前，我有个疑问，这些操作如果有一步没有成功，还有必要继续往下走么？怎么就没一个判断？放下这个问题，我们看之后的代码。
我们先看
bool KAppRes::PrepareRes()
{
bool retval = false;
KFilePath pathRes = KFilePath::GetFilePath(g_hInstance);
HRSRC hResInfo = NULL;
HGLOBAL hResDat = NULL;
PVOID pResBuffer = NULL;
DWORD dwResBuffer;
wchar_t szTempPath[MAX_PATH] = { 0 };
wchar_t szTempFilePath[MAX_PATH] = { 0 };
pathRes.RemoveExtension();
pathRes.AddExtension(L"kui");
if (GetFileAttributesW(pathRes) != INVALID_FILE_ATTRIBUTES)
{
m_strResPackPath = pathRes.value();
}
else
{
hResInfo = FindResourceW(_ModulePtr->GetResourceInstance(), L"kuires.dat", L"SKIN");
if (!hResInfo)
goto clean0;
hResDat = LoadResource(_ModulePtr->GetResourceInstance(), hResInfo);
if (!hResDat)
goto clean0;
pResBuffer = LockResource(hResDat);
if (!pResBuffer)
goto clean0;
dwResBuffer = SizeofResource(_ModulePtr->GetResourceInstance(), hResInfo);
m_memZipRes.SetData(pResBuffer, dwResBuffer);
}
retval = true;
clean0:
return retval;
}
到12行，都是在Exe文件所在目录拼接出与Exe文件同名，但是后缀为kui的资源文件。比如我的电脑上，调试文件目录是D:\快盘\Code Project\openkui\Samples\Sample1\Debug\Sample1.exe，得到的pathRes对应的目录是D:\快盘\Code Project\openkui\Samples\Sample1\Debug\Sample1.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的名字。这样就实现了换肤。即使这套外置皮肤坏了，或者被删了，我们还可以使用资源中的那套皮肤。
虽然想法很好，但是代码中的逻辑却存在一定的编码缺陷和设计缺陷，我们先说编码缺陷：
if (GetFileAttributesW(pathRes) != INVALID_FILE_ATTRIBUTES)
{
m_strResPackPath = pathRes.value();
}
这步，可以用来判断一个文件是否存在么？其实不可以。因为如果我新建一个与压缩包同名的“文件夹”，GetFileAttributesW将返回FILE_ATTRIBUTE_DIRECTORY，这将导致这个错误的逻辑认为该文件夹是一个压缩文件，从而导致之后的逻辑出现处理异常。该函数应该写成
if ( PathFileExists(pathRes) &&
0 == ( GetFileAttributesW(pathRes) & FILE_ATTRIBUTE_DIRECTORY ) )
{
m_strResPackPath = pathRes.value();
}
其中
还有个设计缺陷。假如我们是使用这个库的开发者，我们在调试过程中，难免会修改界面描述文件。那么难道我们每修改一次，都要将描述文件压缩成一个包么？这样不是很难调用？我觉得，可以在PrepareRes函数中，
新增一段对debug情况的处理：在debug情况下我们应该获取工程res目录下一个特定的文件夹，该文件夹保存了未压缩的各个文件。这样我们就可以不用每次修改资源后都要打个资源包了。
我们在KAppRes类私有成员中增加
#ifdef DEBUG
// 保存debug环境下界面描述文件文件夹目录
std::wstring m_strResFloderPath;
#endif
在PrepareRes的pathRes.RemoveExtension();之前新增
#ifdef DEBUG
pathRes.RemoveFileSpec();
pathRes.RemoveFileSpec();
pathRes.AddBackslash();
pathRes.Append(L"res");
pathRes.AddBackslash();
pathRes.Append(L"skin");
pathRes.AddBackslash();
if ( PathFileExists(pathRes) && GetFileAttributesW(pathRes) & FILE_ATTRIBUTE_DIRECTORY )
{
m_strResFloderPath = pathRes.value();
return true;
}
else
{
_ASSERT_EXPR(FALSE, L"Debug环境下要求res目录下skin目录保存界面描述文件");
return false;
}
#endif
这样我们将方便我们调试工作。
接下来我们看OpenResPack这个函数。在PrepareRes中，我们可能会得到界面文件包或者界面内存块。OpenResPack将先后尝试从这两个位置获取界面信息。在这个函数中，我们将看到，如何使用开源的Zlib代码去获取压缩包（内存）中文件的信息。
bool KAppRes::OpenResPack()
{
bool retval = false;
zlib_filefunc_def zip_funcs;
std::string strPathAnsi;
int nRetCode;
HRSRC hResInfo = NULL;
HGLOBAL hResDat = NULL;
PVOID pResBuffer = NULL;
DWORD dwResBuffer = 0;
fill_win32_filefunc(&zip_funcs);
strPathAnsi = UnicodeToAnsi(m_strResPackPath);
m_pResPackData = unzOpen2(strPathAnsi.c_str(), &zip_funcs);
if (m_pResPackData)
goto UNZRESPACKDATA;
这段代码是尝试预处理界面文件包。我们注意下
这儿使用了fill_win32_filefunc填充了zlib_filefunc_def结构体，还要注意下我们对unzOpen2传入了界面文件包的路径。我们接着看，预处理之后的流程
UNZRESPACKDATA:
nRetCode = unzGoToFirstFile(m_pResPackData);
while (UNZ_OK == nRetCode)
{
char szCurrentFile[260];
unz_file_info fileInfo;
uLong dwSeekPos;
uLong dwSize;
nRetCode = unzGetCurrentFileInfo(
m_pResPackData,
&fileInfo,
szCurrentFile,
sizeof(szCurrentFile),
NULL,
0,
NULL,
0
);
if (nRetCode != UNZ_OK)
goto clean0;
dwSeekPos = unzGetOffset(m_pResPackData);
dwSize = fileInfo.uncompressed_size;
m_mapResOffset.insert(KResOffset::value_type(szCurrentFile, KResInfo(dwSeekPos, dwSize)));
nRetCode = unzGoToNextFile(m_pResPackData);
}
这段代码，大致可以看出来，这种遍历方式和VC中遍历文件的一种方法——FindFirstFile、FindNextFile很相似。
如此，便将压缩包中的文件信息保存到Map结构体对象m_mapResOffset中。其中信息包括文件的相对目录，文件的相对偏移和大小。
有了这组信息，我们之后读取单个文件，将变得非常方便了。
以上我们讨论了如何使用Zlib获取界面压缩包中文件信息的方法。现在我们再看下如何使用Zlib从界面内存块中获取压缩后的文件信息。
是否还记得，之前我着重提到一点“使用了fill_win32_filefunc填充了zlib_filefunc_def结构体”。之所以着重，是因为我们现在解析界面内存块的信息时，将要自己填充zlib_filefunc_def结构体中各个回调函数。我们先看fill_win32_filefunc内部的实现
void fill_win32_filefunc (pzlib_filefunc_def)
zlib_filefunc_def* pzlib_filefunc_def;
{
pzlib_filefunc_def->zopen_file = win32_open_file_func;
pzlib_filefunc_def->zread_file = win32_read_file_func;
pzlib_filefunc_def->zwrite_file = win32_write_file_func;
pzlib_filefunc_def->ztell_file = win32_tell_file_func;
pzlib_filefunc_def->zseek_file = win32_seek_file_func;
pzlib_filefunc_def->zclose_file = win32_close_file_func;
pzlib_filefunc_def->zerror_file = win32_error_file_func;
pzlib_filefunc_def->opaque=NULL;
}
可以见得，它传递了“打开文件”、“读取文件”、“写入文件”、“移动读标识”和“关闭文件”等操作的函数地址。我粗略看下这些函数的实现，它们只是对CreateFile、ReadFile和WriteFile等文件操作的封装。对应的，对于不在磁盘上的文件，我们可以封装相应的操作内存的函数，然后将这些函数地址传递给该结构体对象。
zip_funcs.zopen_file = ZipOpenFunc; zip_funcs.zread_file = ZipReadFunc; zip_funcs.zwrite_file = ZipWriteFunc; zip_funcs.ztell_file = ZipTellFunc; zip_funcs.zseek_file = ZipSeekFunc; zip_funcs.zclose_file = ZipCloseFunc; zip_funcs.zerror_file = ZipErrorFunc; zip_funcs.opaque=NULL; m_pResPackData = unzOpen2((const char*)&m_memZipRes, &zip_funcs); if (!m_pResPackData) goto clean0;我们 注意下unzOpen2函数，该函数在声明时指明其是一个文件路径，而我们却将资源的内存块首地址传递进去了。那么unzOpen2可以正确处理么？我们看下ZipOpenFunc函数的实现，就知道这个问题是如何巧妙的解决掉的。
void* ZipOpenFunc(void* opaque, const char* filename, int mode)
{
return (void*)filename;
}
看，它直接将filename返回了。可以想象ZipOpenFunc就是为了打开文件，并定位到首地址。既然传进来的就是内存块首地址，那么直接返回之就行了。而其他函数的实现，也是很简单的，和操作文件一样。比如
long ZipSeekFunc (void* opaque, void* stream, uLong offset, int origin)
{
uLong ret = -1;
CMemFile* pMemFile = (CMemFile*)stream;
DWORD dwRetCode;
if (!pMemFile)
goto clean0;
dwRetCode = pMemFile->SetFilePointer(offset, NULL, origin);
if (INVALID_SET_FILE_POINTER == dwRetCode)
goto clean0;
ret = 0;
clean0:
return ret;
}
在调用解析界面内存块的函数前。OpenResPack还多了一个判断：判断已读取的m_memZipRes是否为空，如果为空，则再从资源文件中读取界面描述块到内存中。
if (strlen((const char*)&m_memZipRes) == 0)
{//防止.kui格式错误导致unzOpen2返回空的m_pResPackData
hResInfo = FindResourceW(_ModulePtr->GetResourceInstance(), L"kuires.dat", L"SKIN");
if (!hResInfo)
goto clean0;
hResDat = LoadResource(_ModulePtr->GetResourceInstance(), hResInfo);
if (!hResDat)
goto clean0;
pResBuffer = LockResource(hResDat);
if (!pResBuffer)
goto clean0;
dwResBuffer = SizeofResource(_ModulePtr->GetResourceInstance(), hResInfo);
m_memZipRes.SetData(pResBuffer, dwResBuffer);
}
这个代码一开始判断m_memZipRes是否为空，存在一定的漏洞：假如资源文件的第一个字符就是\0，则就会认为这段读取的数据为空了。当然，一般不存在这样的问题，因为目前压缩包文件的第一个字符肯定不是\0。但是从代码的严谨性上来说，应该给openkui\KUILib\Include\kscbase下kscmemfile.h中的CMemFile新增一个共有函数
BOOL IsEmpty()
{
return m_buffer.GetCount() == 0 ? TRUE : FALSE;
}
然后那个判断应该改成
If( m_memZipRes.IsEmpty())
{
……
}
还有，这个if中的逻辑PrepareRes中读取资源逻辑一样。应该将其提炼出来，这样可以不会让代码看着十分冗余。我在之后附加的工程中，会将这个函数提炼到一个名字为 GetResInResfile的函数中。
我们接着看之后对数据的读取和保存。
LoadStringRes(); LoadImageRes(); LoadXmlRes(); LoadFontRes();中前三个函数对应于
KUI提供的例子中，都没有LoadFontRes对应的fonts.xml文件存在。所以我们可以先忽略字体处理这块逻辑。
我们以LoadXmlRes为例，讲解其执行过程。
bool KAppRes::LoadXmlRes()
{
bool retval = false;
void* pBuffer = NULL;
unsigned long dwBuffer = 0;
TiXmlDocument xmlDoc;
const TiXmlElement* pXmlChild = NULL;
const TiXmlElement* pXmlItem = NULL;
if (!GetRawDataFromRes("xmls.xml", &pBuffer, dwBuffer))
goto clean0;
if (!xmlDoc.LoadBuffer((char*)pBuffer, (long)dwBuffer, TIXML_ENCODING_UTF8))
goto clean0;
pXmlChild = xmlDoc.FirstChildElement("xmls");
if (!pXmlChild)
goto clean0;
pXmlItem = pXmlChild->FirstChildElement("xml");
while (pXmlItem)
{
std::string strId;
std::string strPath;
strId = pXmlItem->Attribute("id");
strPath = pXmlItem->Attribute("path");
if (strId.length() && strPath.length())
{
m_mapXmlTable[strId] = strPath;
}
pXmlItem = pXmlItem->NextSiblingElement("xml");
}
retval = true;
clean0:
if (pBuffer)
{
FreeRawData(pBuffer);
}
return retval;
} 第10行的GetRawDataFromRes是我们特别需要注意的一个函数。该函数传入一个文件相对路径、用于保存该文件内容的内存块首地址和该内存块的大小。
bool KAppRes::GetRawDataFromRes(
const std::string& strId,
void** ppBuffer,
unsigned long& dwSize
)
{
bool retval = false;
KResStore::iterator store;
KResOffset::iterator offset;
unsigned long dwOffset;
int nRetCode;
if (!ppBuffer)
goto clean0;
offset = m_mapResOffset.find(strId);
if (offset == m_mapResOffset.end())
goto clean0;
dwOffset = offset->second.first;
dwSize = offset->second.second;
*ppBuffer = new unsigned char[dwSize+1];
if (!*ppBuffer)
goto clean0;
nRetCode = unzSetOffset(m_pResPackData, dwOffset);
if (nRetCode != UNZ_OK)
goto clean0;
nRetCode = unzOpenCurrentFile(m_pResPackData);
if (nRetCode != UNZ_OK)
goto clean0;
nRetCode = unzReadCurrentFile(m_pResPackData, *ppBuffer, dwSize);
if (0 == nRetCode)
goto clean0;
retval = true;
clean0:
if (!retval)
{
if (ppBuffer)
{
if (*ppBuffer)
{
delete[] (*ppBuffer);
*ppBuffer = NULL;
}
}
}
return retval;
}
该函数先在保存文件信息的map中寻找传入的相对路径对应的文件信息，然后动态分配一段大小合适的空间（如果成功，则在函数外部释放，否则在函数内部释放），再使用unzSetOffset将压缩包读取位置设置到相应的偏移处，通过unzReadCurrentFile将指定文件读到内存中。是否还记得，我曾提出，这个库在设计时存在一定的缺陷：没有考虑debug情况下会经常修改界面文件的问题。我们之前在PrepareRes函数中获取了保存界面描述文件（非压缩）的路径。这样，我们可以对该函数做段修改，入参都不用改，我们只是让该函数读取指定文件的内容。
#ifdef DEBUG
if ( ReadResFile(strId, ppBuffer, dwSize) ) {
return true;
}
else {
// _ASSERT_EXPR(FALSE, L"debug下从界面描述目录读取文件失败");
return false;
}
#endif
我封装了一个读取文件的函数ReadResFile
#define NEWBUFFERSIZE 0x100
bool KAppRes::ReadResFile(
const std::string& strId,
void** ppBuffer,
unsigned long& dwSize )
{
std::string strFilePath = CW2A(m_strResFloderPath.c_str());
strFilePath += strId;
HANDLE hFile = CreateFileA(strFilePath.c_str(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL );
if ( NULL == hFile ) {
return false;
}
// 先分配读取的数据空间
DWORD dwTotalSize = NEWBUFFERSIZE; // 总空间
char* pchReadBuffer = new char[dwTotalSize];
memset(pchReadBuffer, 0, NEWBUFFERSIZE);
DWORD dwFreeSize = dwTotalSize; // 闲置空间
bool bSuc = false;
do {
char chTmpReadBuffer[NEWBUFFERSIZE] = {0};
DWORD dwbytesRead = 0;
// 用于控制读取偏移
OVERLAPPED Overlapped;
memset(&Overlapped, 0, sizeof(OVERLAPPED) );
while (true) {
// 清空缓存
memset(chTmpReadBuffer, 0, NEWBUFFERSIZE);
// 读取管道
BOOL bRead = ReadFile( hFile, chTmpReadBuffer, NEWBUFFERSIZE, &dwbytesRead, &Overlapped );
DWORD dwLastError = GetLastError();
if ( bRead ) {
if ( dwFreeSize >= dwbytesRead ) {
// 空闲空间足够的情况下，将读取的信息拷贝到剩下的空间中
memcpy_s( pchReadBuffer + Overlapped.Offset, dwFreeSize, chTmpReadBuffer, dwbytesRead );
// 重新计算新空间的空闲空间
dwFreeSize -= dwbytesRead;
}
else {
// 计算要申请的空间大小
DWORD dwAddSize = ( 1 + dwbytesRead / NEWBUFFERSIZE ) * NEWBUFFERSIZE;
// 计算新空间大小
DWORD dwNewTotalSize = dwTotalSize + dwAddSize;
// 计算新空间的空闲大小
dwFreeSize += dwAddSize;
// 新分配合适大小的空间
char* pTempBuffer = new char[dwNewTotalSize];
// 清空新分配的空间
memset( pTempBuffer, 0, dwNewTotalSize );
// 将原空间数据拷贝过来
memcpy_s( pTempBuffer, dwNewTotalSize, pchReadBuffer, dwTotalSize );
// 保存新的空间大小
dwTotalSize = dwNewTotalSize;
// 将读取的信息保存到新的空间中
memcpy_s( pTempBuffer + Overlapped.Offset, dwFreeSize, chTmpReadBuffer, dwbytesRead );
// 重新计算新空间的空闲空间
dwFreeSize -= dwbytesRead;
// 将原空间释放掉
delete [] pchReadBuffer;
// 将原空间指针指向新空间地址
pchReadBuffer = pTempBuffer;
}
// 读取成功，则继续读取，设置偏移
Overlapped.Offset += dwbytesRead;
}
else{
if ( ERROR_HANDLE_EOF == dwLastError ) {
bSuc = TRUE;
}
break;
}
}
if ( bSuc ) {
*ppBuffer = pchReadBuffer;
dwSize = dwTotalSize - dwFreeSize;
}
else {
if ( NULL != pchReadBuffer ) {
delete [] pchReadBuffer;
pchReadBuffer = NULL;
}
}
} while (0);
if ( NULL != hFile ) {
CloseHandle(hFile);
hFile = NULL;
}
return bSuc;
}
这样，我们只要在res下新建一个skin文件夹，然后将我们的界面描述文件放在这个目录下即可。
我们看一下xmls.xml文件内容
<?xml version="1.0" encoding="utf-8" standalone="yes" ?> <xmls> <xml id="IDR_KSC_SKIN" path="res/def_skin.xml" /> <xml id="IDR_KSC_STYLE" path="res/def_style.xml" /> <xml id="IDR_KSC_STRING" path="res/def_string.xml" /> <xml id="IDR_DLG_MAIN" path="res/dlg_main.xml" /> </xmls>可以见到其中对应的文件是
在使用KUI库的程序中，我们将使用到这些id。
我们看下最终的读取结果
我们注意到res目录下三个文件这个时候并没有加载。为什么不加载，我们之后会在探索《以金山界面库（openkui）为例思考和分析界面库的设计和实现——问题》中“如何读取保存界面元素属性”问题时，对这个问题作出解释。
总体来说，KUI这套资源管理逻辑存在以下问题：
1 部分代码不严谨
2 设计缺乏对debug环境下的优化
3 读取资源代码容余，应该封装下
bool KAppRes::GetResInResfile()
{
bool retval = false;
HRSRC hResInfo = NULL;
HGLOBAL hResDat = NULL;
PVOID pResBuffer = NULL;
DWORD dwResBuffer;
hResInfo = FindResourceW(_ModulePtr->GetResourceInstance(), L"kuires.dat", L"SKIN");
if (!hResInfo)
goto clean0;
hResDat = LoadResource(_ModulePtr->GetResourceInstance(), hResInfo);
if (!hResDat)
goto clean0;
pResBuffer = LockResource(hResDat);
if (!pResBuffer)
goto clean0;
dwResBuffer = SizeofResource(_ModulePtr->GetResourceInstance(), hResInfo);
m_memZipRes.SetData(pResBuffer, dwResBuffer);
retval = true;
clean0:
return retval;
} 也有其出彩的地方：
1 CMemFile类的编写
2 从内存中解压文件