ios - 有没有一种方法可以在FMDB中“启动泵”，因此可以更快地进行操作

我们有一个sqlite数据库，我们的iOS应用程序将图像存储在blob列中。
我们使用FMDB将blob读取为NSData，然后转换为UIImage。代码如下所示。

-(UIImage*)getImageWithGuidNSString *)guid imageSizeKindImageSizeKind)imageSizeKind
    {
        FMDatabase *db = [self openFMDatabase];
        if (!db) {
            return nil;
        }

        NSData *imageData = nil;
        NSString *query = [NSString stringWithFormat"SELECT Image FROM images WHERE Guid = '%@' AND MediaType = %d limit 1", guid, imageSizeKind];

        FMResultSet *rs = [db executeQuery:query];

        if ([rs next])
        {
            imageData = [rs dataForColumn:imagesTable.image];
        }

        [rs close];
        [db close];

        if (!imageData) {
            NSLog(@"Image was not found in database '%@' using sql query '%@'", [self databasePath], query);
        }

        UIImage *image = [UIImage imageWithData:imageData];

        return image;
    }

上面这个方法的调用者接收图像，然后调整其大小。
在上述方法的调用方中，我有一些代码可以安排代码获取和调整大小的时间，并在调试控制台中收到以下输出...

23:31:17.084在4.208354秒内获得图像
23:31:17.086在0.001961秒内调整了图像的大小
23:31:17.115在0.028943秒内获得了图像
23:31:17.117在0.001891秒内调整图像大小
23:31:17.131在0.013373秒内获得图像
23:31:17.133在0.002036秒内调整图像大小
23:31:17.844在0.711072秒内获得图像
23:31:17.846在0.001634秒内调整了图像的大小
23:31:17.880在0.034076秒内获得了图像
23:31:17.882在0.001678秒内调整了图像的大小
23:31:17.910在0.028255秒内获得了图像
23:31:17.912在0.001652秒内调整图像大小
23:31:17.943在0.031323秒内获得图像
23:31:17.945在0.001783秒内调整图像大小
23:31:17.954在0.009396秒内获得了图像
23:31:17.956在0.001982秒内调整了图像的大小
23:31:17.986在0.029724秒内获得了图像
23:31:17.988在0.001977秒内调整了图像的大小
23:31:18.026在0.037283秒内获得了图像
23:31:18.027在0.001837秒内调整图像大小
23:31:18.051在0.023700秒内获得了图像
23:31:18.053在0.001947秒内调整图像大小
23:31:18.088在0.035087秒内获得了图像
23:31:18.090在0.001687秒内调整图像大小
23:31:18.136在0.045304秒内获得图像

请注意，第一张图像花了4.2秒才能获得，然后所有后续图像仅花了百分之一秒。

有什么办法可以让我“启动泵”，以使它节省4.2秒的时间，并使数据库准备好像其后所有图像一样工作。理想情况下，将某个后台线程的延迟时间缩短4秒，这样用户就不必在应用程序的其他位置上体验它，只需将最初的4秒移动到其他地方即可。

谢谢。

---

Best Answer-推荐答案

FMDB(或更准确地说，SQLite)不需要任何“启动”。我只是运行以下代码:

CFAbsoluteTime last = CFAbsoluteTimeGetCurrent();

for (NSInteger i = 0; i < 10; i++) {
    FMResultSet *rs = [database executeQuery"select image_data from images where guid = ?", @(i)];
    NSAssert(rs, @"select failed: %@", [database lastErrorMessage]);
    if ([rs next]) {
        CFAbsoluteTime current = CFAbsoluteTimeGetCurrent();
        NSData *data = [rs dataForColumnIndex:0];
        NSLog(@"%lu %0.3f", (unsigned long)[data length], current - last);
        last = current;
    }
    [rs close];
}

在iPhone 6+上，它报告:

2016-03-24 21:53:36.107 MyApp [3710:1262147] 1000000 0.010
2016-03-24 21:53:36.112 MyApp [3710:1262147] 1000000 0.004
2016-03-24 21:53:36.115 MyApp [3710:1262147] 1000000 0.004
2016-03-24 21:53:36.123 MyApp [3710:1262147] 1000000 0.008
2016-03-24 21:53:36.131 MyApp [3710:1262147] 1000000 0.008
2016-03-24 21:53:36.138 MyApp [3710:1262147] 1000000 0.007
2016-03-24 21:53:36.146 MyApp [3710:1262147] 1000000 0.007
2016-03-24 21:53:36.153 MyApp [3710:1262147] 1000000 0.007
2016-03-24 21:53:36.161 MyApp [3710:1262147] 1000000 0.007
2016-03-24 21:53:36.168 MyApp [3710:1262147] 1000000 0.007

从上面的日志中可以推断出，这是从数据库中检索10个1 mb BLOB的基准。

因此，存在两个可能的问题:

仔细检查您在哪里启动计时器。确保在启动计时器和开始检索图像之间没有其他代码。也许您的代码中还有其他东西在拖慢应用程序的速度。

我可能建议运行Instruments的“Time Profiler”，并准确确认造成您4秒钟延迟的原因。或者，稍微复杂一点，您有时可以通过在“系统跟踪”工具的“系统调用”中对“等待时间”进行排序来识别阻塞的调用。但是，最重要的是，确认SQLite实际上是4秒延迟的根源。

如果您对Instruments不满意，通常可以用老式的方式识别瓶颈，插入越来越多的时序声明，然后将范围缩小到一两个行，这就是造成您4秒钟延迟的原因。 (例如，是executeQuery还是step，还是图像调整大小而不是图像检索，或者也许数据库的第一次打开正在做一些从捆绑包到文档的昂贵复制，等等。)

如果问题确实出在SQLite上，我将确保您在guid上有一个索引(最好是唯一键)。不太可能引起此问题(尤其是如果您在打开下一行之前关闭数据库)，但是如果性能延迟确实在SQLite中，则可能会有所帮助。

另外，我注意到您在SQL语句中使用limit 1。真的有多个具有相同guid的条目(通常是唯一的)吗？也许时差与您获得第一把钥匙的比赛次数有关。

还请确保您没有其他尝试同时在同一SQLite数据库上工作的进程。我认为情况并非如此，因为您说过您允许应用程序在进行基准测试之前先安定下来，但我之所以提及此只是出于完整性的考虑。

对于Wolverine的观察，最好将图像存储在文件系统中，而仅将文件名存储在数据库中，这确实是正确的(如果我没记错的话，我上次进行基准测试时，从SQLite检索图像的速度要慢10％至20％而不是从SQLite获取文件名，然后直接从文件系统中检索图像)。过去的经验法则是，如果您的图像是缩略图大小，则将它们存储在SQLite中是可以的，但如果它们是兆字节大小(而不是10s KB)，那么将它们存储在文件系统中将开始产生实质性的性能改进。我认为这不能回答为什么您的第一次通话这么慢的问题，但是如果图像较大，则值得考虑。

如果您在Stack Overflow中搜索[sqlite] blob performance或执行类似的google搜索，您将看到许多有关在SQLite中存储非常大的BLOB对象的缺点的讨论。

话虽如此，我确实有一个与性能相关的观察:我不会每次都打开和关闭数据库。应用启动后打开数据库一次，并保持打开状态。这样只会节省10毫秒，因此不会解决您的4秒延迟问题，但是效率会更高。

但是，最重要的是，我无法重现您报告的性能延迟。如果您可以创建一个小的独立MCVE，那么我们可以帮助您进行诊断。但是我怀疑问题出在到目前为止与您共享给我们的代码段之外。

关于ios - 有没有一种方法可以在FMDB中“启动泵”，因此可以更快地进行操作，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36203482/