游戏中会大量使用到配置文件，每个项目组根据自己不同的需求会选择不同的存储格式，比如使用Json或者SQLite来存储数据。此处我们只对使用SQLite的情况来做讨论。一般情况下会选择把它放在可读写目录里面，这样SQLite可以直接使用它原来的io API来对db文件进行读取。在PC或者iOS平台上这不是问题。但是如果在Android平台上，游戏安装后还是以一个apk文件的形式存在。如果我们的数据放在了db中，使用SQLite原来自带的io功能是不能进行读取的。这里有3种方式可以供选择：
- 在程序第一次启动时，把apk中的所有文件解压出来放到可读写目录中，这样存在的问题是第一次打开程序时会比较慢。
- 在需要的读取某个db的时候才把这个文件从apk中解压出来，这样的话可能会导致卡顿，或者使用协程等异步操作来完成，但是这样对于逻辑层的代码书写成本比较高。
- 对SQLite做一定的改动，使它可以读取apk中的db文件。
一般大家可能会选择第一种方法，这没有什么好说的。我们接下来看看第3种方法的可能性。
理论
为了实现上述的想法，我们需要两个条件：
- android提供对apk中单个文件的读取的能力。
- SQLite提供了对io层（不同平台）进行快速修改的能力，这就要求SQLite有比较好的抽象以较少的模块之间的耦合。
当然上述两个条件是满足的，下面我们来具体看看这两个条件。
Android对apk中单个文件的读取能力
1 Open a new file descriptor that can be used to read the asset data. If the start or length cannot be represented by a 32-bit number, it will be truncated. If the file is large, use AAsset_openFileDescriptor64 instead. 2 Returns < 0 if direct fd access is not possible (for example, if the asset is compressed). 3 int AAsset_openFileDescriptor (AAsset * asset, off_t * outStart, off_t * outLength )
从这个API可以看出，它可以返回一个用于读取当前asset的一个文件描述符。但是如果当前asset被压缩了，那么就回返回一个小于0的值。如果我们想要读取db的话，那么它必须是没有压缩过的。
示例代码大体如下所示:
1 AAsset* asset = AAssetManager_open(mgr, filename, AASSET_MODE_UNKNOWN); 2 if (NULL == asset) 3 { 4 //LOGD("file not found! Stop preload file: %s", filename); 5 return FILE_NOT_FOUND; 6 } 7 8 // open asset as file descriptor 9 int fd = AAsset_openFileDescriptor(asset, &start, &length); 10 assert(0 <= fd); 11 AAsset_close(Asset);
注意，这个fd返回的是整个apk的句柄，start代表这个文件在apk中的偏移，length代表长度，使用的时候要注意。
SQLite对于文件io层的支持
下图是 SQLite官方给出的架构图：
我们这里主要关注的就是OS Interface这一层，它使用了VFS这一对象来为不同系统之间的可移植性提供了保证，。具体细节可以参照官网对于VFS的介绍。SQLite目前提供了对类unix系统和windows系统的支持，分别在os_unix.c以及os_win.c中实现的。其中os_unix.c提供了对mac os、iOS、Android以及Linux的支持。如果读取想对这块有一个比较深入了了解可以看官方文档以及查看一些示例如test_demovfs.c等来深入了解。
实现
有了上面的理论支持，那么我们就可以着手可以写代码了。我们目前有两种方案可以选择：
- 单独为安卓实现一个VFS。
- 在os_unix.c的基础上进行修改。
第一种方案需要写的代码比较多，而且需要读者对SQLite有一个比较深入的了解。所以我们这里选择第二种方案。在原来的os_unix.c的基础上进行改动。
SQLite改造
通过分析os_unix.c文件，我们能得出它主要使用了open() read() write()等io操作。这跟我们上面Android NDK提供的AAsset_openFileDescriptor正好完美的结合起来。我们正好可以使用它返回的句柄进行类似的操作。只不过在Android的情况下特殊一点。
这样下来，我们基本上大体需要改的几个函数和结构体如下所示
- struct unixFile 我们需要在其中添加文件在apk中的偏移以及大小 。
- posixOpen 通过openFileDescriptor返回文件描述符。
- seekAndRead 读取时要加上文件偏移。
- unixFileSize 返回前面unixFile中记录的文件大小的值。
以上基本是需要改到的函数，当然根据实现的不同可能具体需要改动的函数不一样。这只是比较粗暴的改法。像我们需要支持从apk里面读取以及从一个散文件里面读取，所以跟上面的改动多少有一些不一样的地方，但是基本思想是通的。当然由于本人对SQLite不了 解，可能有需要改动的地方没有注意到，如果说的有错误希望能及时指正。方法已经说的比较明白了，这里也就不贴代码了。
上面的例子提到的AAssetManager_open在打开时需要一个AAssetManager的对象，这个对象只能从Java里面获取。如果你是直接使用Android开发那么这个对象就比较容易获取，那么如果你是使用Unity或者UE4开发怎么获取这个对象呢。
Unity实现细节
SQLite的修改跟上面是一样的，只是我们在Unity中如何获取这个对象呢。读者可以具体对照一下这个类AndroidJNI AndroidJNIHelper AndroidJavaClass AndroidJavaObject AndroidJavaProxy这几个类。
示例代码如下所示：
1 IntPtr cls_Activity = (IntPtr)AndroidJNI.FindClass("com/unity3d/player/UnityPlayer"); 2 IntPtr fid_Activity = AndroidJNI.GetStaticFieldID(cls_Activity, "currentActivity", "Landroid/app/Activity;"); 3 IntPtr obj_Activity = AndroidJNI.GetStaticObjectField(cls_Activity, fid_Activity); 4 IntPtr obj_cls = AndroidJNI.GetObjectClass(obj_Activity); 5 IntPtr asset_func = AndroidJNI.GetMethodID(obj_cls, "getAssets", "()Landroid/content/res/AssetManager;"); 6 jvalue[] asset_array = new jvalue[2]; // <- ? 7 IntPtr assetManager = AndroidJNI.CallObjectMethod(obj_Activity, asset_func, asset_array);
这样我们就得到了这个AssetManager，这个时候我们就可以通过C#把这个对象传递给SQLite库了。
UE4实现细节
UE4在C++中可以直接拿到AAssetManager对象，具体实现细节UE4已经帮我们做了，具体可以查看AndroidJNI.cpp中的代码。我们拿到AAssetManager这个对象并把它设置给SQLite就可以了。
总结
到此，我们对SQLite扩展读取apk中db的方法已经写完了。由于Android NDK返回了文件描述符以及SQLite提供的OS Interface层让我们很比较容易的实现了对SQLite扩展。由于作者对SQLite原来并没有了解，所以难免有错误之处，如果有错误请及时指正。如果读者想对SQLite有一个比较深入的认识，也可以看看参考文章6。