菜鸟教程小白 发表于 2022-12-13 15:30:05

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


                                            <p>我们有一个sqlite数据库,我们的iOS应用程序将图像存储在blob列中。<br>我们使用FMDB将blob读取为NSData,然后转换为UIImage。代码如下所示。<br><pre><code>-(UIImage*)getImageWithGuid:(NSString *)guid imageSizeKind:(ImageSizeKind)imageSizeKind
    {
      FMDatabase *db = ;
      if (!db) {
            return nil;
      }

      NSData *imageData = nil;
      NSString *query = ;

      FMResultSet *rs = ;

      if ()
      {
            imageData = ;
      }

      ;
      ;

      if (!imageData) {
            NSLog(@&#34;Image was not found in database &#39;%@&#39; using sql query &#39;%@&#39;&#34;, , query);
      }

      UIImage *image = ;

      return image;
    }
</code></pre><br>上面这个方法的调用者接收图像,然后调整其大小。<br>在上述方法的调用方中,我有一些代码可以安排代码获取和调整大小的时间,并在调试控制台中收到以下输出...<br><br>23:31:17.084在4.208354秒内获得图像<br>23:31:17.086在0.001961秒内调整了图像的大小<br>23:31:17.115在0.028943秒内获得了图像<br>23:31:17.117在0.001891秒内调整图像大小<br>23:31:17.131在0.013373秒内获得图像<br>23:31:17.133在0.002036秒内调整图像大小<br>23:31:17.844在0.711072秒内获得图像<br>23:31:17.846在0.001634秒内调整了图像的大小<br>23:31:17.880在0.034076秒内获得了图像<br>23:31:17.882在0.001678秒内调整了图像的大小<br>23:31:17.910在0.028255秒内获得了图像<br>23:31:17.912在0.001652秒内调整图像大小<br>23:31:17.943在0.031323秒内获得图像<br>23:31:17.945在0.001783秒内调整图像大小<br>23:31:17.954在0.009396秒内获得了图像<br>23:31:17.956在0.001982秒内调整了图像的大小<br>23:31:17.986在0.029724秒内获得了图像<br>23:31:17.988在0.001977秒内调整了图像的大小<br>23:31:18.026在0.037283秒内获得了图像<br>23:31:18.027在0.001837秒内调整图像大小<br>23:31:18.051在0.023700秒内获得了图像<br>23:31:18.053在0.001947秒内调整图像大小<br>23:31:18.088在0.035087秒内获得了图像<br>23:31:18.090在0.001687秒内调整图像大小<br>23:31:18.136在0.045304秒内获得图像<br><br>请注意,第一张图像花了4.2秒才能获得,然后所有后续图像仅花了百分之一秒。<br><br>有什么办法可以让我“启动泵”,以使它节省4.2秒的时间,并使数据库准备好像其后所有图像一样工作。理想情况下,将某个后台线程的延迟时间缩短4秒,这样用户就不必在应用程序的其他位置上体验它,只需将最初的4秒移动到其他地方即可。<br><br>谢谢。</p>
                                    <br><hr><h1><strong>Best Answer-推荐答案</ strong></h1><br>
                                            <p>FMDB(或更准确地说,SQLite)不需要任何“启动”。我只是运行以下代码:<br><pre><code>CFAbsoluteTime last = CFAbsoluteTimeGetCurrent();

for (NSInteger i = 0; i &lt; 10; i++) {
    FMResultSet *rs = ;
    NSAssert(rs, @&#34;select failed: %@&#34;, );
    if () {
      CFAbsoluteTime current = CFAbsoluteTimeGetCurrent();
      NSData *data = ;
      NSLog(@&#34;%lu %0.3f&#34;, (unsigned long), current - last);
      last = current;
    }
    ;
}
</code></pre><br>在iPhone 6+上,它报告:<br><br>2016-03-24 21:53:36.107 MyApp 1000000 0.010<br>2016-03-24 21:53:36.112 MyApp 1000000 0.004<br>2016-03-24 21:53:36.115 MyApp 1000000 0.004<br>2016-03-24 21:53:36.123 MyApp 1000000 0.008<br>2016-03-24 21:53:36.131 MyApp 1000000 0.008<br>2016-03-24 21:53:36.138 MyApp 1000000 0.007<br>2016-03-24 21:53:36.146 MyApp 1000000 0.007<br>2016-03-24 21:53:36.153 MyApp 1000000 0.007<br>2016-03-24 21:53:36.161 MyApp 1000000 0.007<br>2016-03-24 21:53:36.168 MyApp 1000000 0.007<br><br>从上面的日志中可以推断出,这是从数据库中检索10个1 mb BLOB的基准。<br><br>因此,存在两个可能的问题:<br><li>仔细检查您在哪里启动计时器。确保在启动计时器和开始检索图像之间没有其他代码。也许您的代码中还有其他东西在拖慢应用程序的速度。<br><br>我可能建议运行Instruments的“Time Profiler”,并准确确认造成您4秒钟延迟的原因。或者,稍微复杂一点,您有时可以通过在“系统跟踪”工具的“系统调用”中对“等待时间”进行排序来识别阻塞的调用。但是,最重要的是,确认SQLite实际上是4秒延迟的根源。<br><br>如果您对Instruments不满意,通常可以用老式的方式识别瓶颈,插入越来越多的时序声明,然后将范围缩小到一两个行,这就是造成您4秒钟延迟的原因。 (例如,是<code>executeQuery</code>还是<code>step</code>,还是图像调整大小而不是图像检索,或者也许数据库的第一次打开正在做一些从捆绑包到文档的昂贵复制,等等。)</li><li>如果问题确实出在SQLite上,我将确保您在<code>guid</code>上有一个索引(最好是唯一键)。不太可能引起此问题(尤其是如果您在打开下一行之前关闭数据库),但是如果性能延迟确实在SQLite中,则可能会有所帮助。<br><br>另外,我注意到您在SQL语句中使用<code>limit 1</code>。真的有多个具有相同<code>guid</code>的条目(通常是唯一的)吗?也许时差与您获得第一把钥匙的比赛次数有关。 </li><li>还请确保您没有其他尝试同时在同一SQLite数据库上工作的进程。我认为情况并非如此,因为您说过您允许应用程序在进行基准测试之前先安定下来,但我之所以提及此只是出于完整性的考虑。 </li><li>对于Wolverine的观察,最好将图像存储在文件系统中,而仅将文件名存储在数据库中,这确实是正确的(如果我没记错的话,我上次进行基准测试时,从SQLite检索图像的速度要慢10%至20%而不是从SQLite获取文件名,然后直接从文件系统中检索图像)。过去的经验法则是,如果您的图像是缩略图大小,则将它们存储在SQLite中是可以的,但如果它们是兆字节大小(而不是10s KB),那么将它们存储在文件系统中将开始产生实质性的性能改进。我认为这不能回答为什么您的第一次通话这么慢的问题,但是如果图像较大,则值得考虑。<br><br>如果您在Stack Overflow中搜索<code> blob performance</code>或执行类似的google搜索,您将看到许多有关在SQLite中存储非常大的BLOB对象的缺点的讨论。 </li><br>话虽如此,我确实有一个与性能相关的观察:我不会每次都打开和关闭数据库。应用启动后打开数据库一次,并保持打开状态。这样只会节省10毫秒,因此不会解决您的4秒延迟问题,但是效率会更高。<br><br>但是,最重要的是,我无法重现您报告的性能延迟。如果您可以创建一个小的独立<a href="https://stackoverflow.com/help/mcve" rel="noreferrer noopener nofollow">MCVE</a>,那么我们可以帮助您进行诊断。但是我怀疑问题出在到目前为止与您共享给我们的代码段之外。</p>
                                   
                                                <p style="font-size: 20px;">关于ios - 有没有一种方法可以在FMDB中“启动泵”,因此可以更快地进行操作,我们在Stack Overflow上找到一个类似的问题:
                                                        <a href="https://stackoverflow.com/questions/36203482/" rel="noreferrer noopener nofollow" style="color: red;">
                                                                https://stackoverflow.com/questions/36203482/
                                                        </a>
                                                </p>
                                       
页: [1]
查看完整版本: ios - 有没有一种方法可以在FMDB中“启动泵”,因此可以更快地进行操作