我的应用程序遇到了iOS 5的主要性能问题，有人可以帮助我从仪器中理解这个速度测试日志吗？ [英] My app is suffering from major performance issues with iOS 5, can someone help me make sense of this speed test log from instruments?

问题描述

我有一个简单的阅读应用程序，它使用fmdb与数据库通信，然后用文本填充UIWebview。自从ios 5的辉煌出现以来它运行得非常糟糕......

I have a simple reading app that uses fmdb to talk to the database and then fill up a UIWebview with text. Since the glorious advent of ios 5 it runs very poorly...

当我通过segmentedControl轻触我书中的章节时。在ios 4.3中，它速度非常快。现在，如下所示，它不是：

When I am change chapters in my book via a segmentedControl tap. In ios 4.3, it was SUPER fast. Now, as you can see below, it isn't:

所以显然事情正在加载缓慢，但我不知道如何阅读速度测试的结果。哪种方法是罪魁祸首？我需要做些什么才能优化应用？还有什么我可以做的，以了解挂断的确切位置是什么？

So obviously things are loading slow, but I don't know how to read the results of the speed test. Which method is the main culprit? What do I need to do to optimize the app? Is there anything else I can do to understand where exactly the hang-ups are?

我正在用fmdb和ios 5度过这么艰难的时间，我正在考虑其他选择。我应该废弃fmdb吗？并选择直接的ios sqlite db方法？

I am having such a hard time with fmdb and ios 5 that I am considering other options. Should I just scrap fmdb? And go for the direct ios sqlite db approach?

我发现仪器工具很有用，但很难理解和使用。

I am finding the instruments tool to be useful, but very hard to understand and use.

UPDATE

以下是更改章节方法：

- (IBAction) changeChapter:(id)sender {
if ([prevNext selectedSegmentIndex] == 0) {
    //previous
    [self setCurrentChapter:(currentChapter-1)];
} else {
    //next
    [self setCurrentChapter:(currentChapter+1)];
}
[self refreshUI];
}

更新2：

这是仪器告诉我的代码是问题。它是fmdb用于迭代FMResultSet的下一个方法：

Here is the code that instruments is telling me is the problem. It is the next method that fmdb uses to iterate through the FMResultSet:

- (BOOL) next {

int rc;
BOOL retry;
int numberOfRetries = 0;
do {
    retry = NO;

    rc = sqlite3_step(statement.statement); //Instruments says this is 100% the problem

    if (SQLITE_BUSY == rc) {
        // this will happen if the db is locked, like if we are doing an update or insert.
        // in that case, retry the step... and maybe wait just 10 milliseconds.
        retry = YES;
        usleep(20);

        if ([parentDB busyRetryTimeout] && (numberOfRetries++ > [parentDB busyRetryTimeout])) {

            NSLog(@"%s:%d Database busy (%@)", __FUNCTION__, __LINE__, [parentDB databasePath]);
            NSLog(@"Database busy");
            break;
        }
    }
    else if (SQLITE_DONE == rc || SQLITE_ROW == rc) {
        // all is well, let's return.
    }
    else if (SQLITE_ERROR == rc) {
        NSLog(@"Error calling sqlite3_step (%d: %s) rs", rc, sqlite3_errmsg([parentDB sqliteHandle]));
        break;
    } 
    else if (SQLITE_MISUSE == rc) {
        // uh oh.
        NSLog(@"Error calling sqlite3_step (%d: %s) rs", rc, sqlite3_errmsg([parentDB sqliteHandle]));
        break;
    }
    else {
        // wtf?
        NSLog(@"Unknown error calling sqlite3_step (%d: %s) rs", rc, sqlite3_errmsg([parentDB sqliteHandle]));
        break;
    }

} while (retry);


if (rc != SQLITE_ROW) {
    [self close];
}

return (rc == SQLITE_ROW);
}

就sqlite而言，FMDB是我所知道的，是吗？甚至值得吗？我应该废弃它并转移到可可触摸sqlite api吗？

FMDB is all I've ever known as far as sqlite goes, is it even worth it? Should I just scrap it and move to the cocoa-touch sqlite api's?

推荐答案

好的我实际上能够从中获取此信息有人在FMDB邮件列表上。他建议我为经常调用的db表添加一个索引，然后修复它！

Ok I was actually able to get this information from someone on the FMDB mailing list. He suggested that I add an index to my db tables that were being called frequently, and that fixed it!

显然Apple改变了iOS 5中的sqlite版本。

Apparently Apple changed the version of sqlite in iOS 5.

来自FMDB帖子：

在sqlite中创建索引很简单 - 请参阅sqlite.org了解语法。
诀窍在于确定要创建的索引。
在我的情况下，我有一个查询：
从x中选择a，b，c，其中sid = somevalue;
sid不是表的主键，因此没有
的索引。在sid上添加索引使得查询更快，因为索引
允许它快速查找元组。请注意，索引可以减慢表上的
更新，插入和删除速度，因此不要随意向表中添加
索引。查看您的查询，并查看查询的where子句中使用的
列。

Creating an index in sqlite is easy - see sqlite.org for the syntax. The trick is figuring out what index(es) to create. In my case I had a query like: select a,b,c from x where sid=somevalue; sid was not the primary key for the table so there wasn't an index on it. Adding an index on sid made that query much faster since the index allows it to quickly find tuples. Note that indexes can slow down updates, inserts, and deletes on the table so don't just randomly add indexes to your tables. Look at your queries and see what columns are used in the where clause of your queries.

这篇关于我的应用程序遇到了iOS 5的主要性能问题，有人可以帮助我从仪器中理解这个速度测试日志吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！