我的第一种方法是访问文件属性并进行比较,但在线的一些地方提到了延迟方面的严重瓶颈.
我的第二选择是创建一个sqlite表来管理它. (使用fmdb)
我决定编写一个简单的延迟测试.在下一个测试中,我正在访问500个文件属性和500个sqlite记录:
- (void)latencyTest { NSMutableArray *arrayTest1 = [[NSMutableArray alloc]init]; NSMutableArray *arrayTest2 = [[NSMutableArray alloc]init]; FMResultSet *results = [_database executeQuery:@"SELECT * FROM `tb_media`"]; NSDateFormatter *formatter = [[NSDateFormatter alloc] init]; [formatter setDateFormat:@"dd-MM-yyyy HH:mm:ss:SSS"]; NSLog(@"Time1: %@",[formatter stringFromDate:[NSDate date]]); int i=1; while(i<501) { Nsstring *test = [Nsstring stringWithFormat:@"%@/_media/media/19/%d.jpg",_outputPath,i]; NSDictionary *attributes = [[NSFileManager defaultManager] attributesOfItemAtPath:test error:nil]; NSDate *dateX = [attributes fileModificationDate]; [arrayTest1 addobject:dateX]; i++; } NSLog(@"Time2: %@",[formatter stringFromDate:[NSDate date]]); while([results next]) { NSDate *myDate = [NSDate dateWithTimeIntervalSince1970:[results intForColumn:@"last_update"]]; [arrayTest2 addobject:myDate]; } NSLog(@"Time3: %@",[formatter stringFromDate:[NSDate date]]); }
结果:
//iPhone 5 (Actual Device) 500 Pics Files Start: 05-03-2014 09:31:20:375 Files End & sqlite start: 05-03-2014 09:31:20:491 sqlite end: 05-03-2014 09:31:20:507 Files Start: 05-03-2014 09:31:56:305 Files End & sqlite start: 05-03-2014 09:31:56:421 sqlite end: 05-03-2014 09:31:56:437 Files Start: 05-03-2014 09:32:19:053 Files End & sqlite start: 05-03-2014 09:32:19:170 sqlite end: 05-03-2014 09:32:19:187
如您所见,结果几乎相同.
我的问题是:
>我假设使用attributesOfItemAtPath一次访问一个文件
比sql花费更长的时间.我错过了什么吗?
> attributesOfItemAtPath是否真正访问文件或iOS
filesystem将所有属性保存在某种数据库中
容易接近?
>看到上述结果后,我决定选择
attributesOfItemAtPath方法.还有什么我不是
考虑传递sqlite?
解决方法
1)您没有纳入NSLog和while循环所花费的时间. 75%的时间是由他们承担的
而您只想比较intForColumn和attributesOfItemAtPath.执行此操作的正确方法是运行仪器Timer Profiler并比较检索单个记录的时间.
2)您已将FMDB用作文件管理器.内部FMDB序列化文件中的数据. FMDB / sql Lite的核心在于其数据结构,特别是您根本没有使用过的索引.
因此,即使您比较记录所花费的时间,您将观察FMDB所花费的时间比文件管理器多,因为以特定格式序列化数据需要额外的开销.
3)通过对磁盘(硬盘驱动器)而不是堆的访问次数来比较X个记录的访问时间.您正在做的是在两种情况下都对数据存储进行堆访问.因此,您将无法看到任何差异.
这是否意味着文件管理器比FMDB更好,绝对不是!!
以下是几个原因:
FMDB只有在配置完成后才能正常运行.
FMDB的核心在于分页(缓存到堆)和索引两个方面.
让我一次向你解释一下.
1)假设您正在尝试访问100张图像的时间戳.每个图像有1000个时间戳.这意味着您必须对数据存储进行100 * 1000 = 100,000访问.
如果图像很小,那么Filemanager会将文件加载到堆中,访问速度将比FMDB快,但如果没有足够的堆空间,应用程序将发出内存警告并从磁盘访问文件而不是缓存,这显然要慢得多.
所以它是一个二进制状态,要么全部来自堆,要么来自磁盘
FMDB优于此状态并根据可用堆空间检索部分记录.当您有大量记录时,这会使访问速度更快.
测试此场景的理想方法是为至少10,000个图像(不是时间戳)运行您的fumpntion latencyTest.这样,与总体时间相比,对数时间和迭代速度可以忽略不计.
2)索引结构,这可以追溯到sql Lite的基础知识.您可能希望添加额外的属性调用作为对图像的访问次数,并在其上编制索引.这将大大提高人均力量. Filemeanger不太可能.
我推荐的解决方案.
1)如果您的数据小于2 MB(图像加时间戳),请转到Filemenager
2)如果数据是> 2MB用于Core Data / FMDB.
核心数据针对多线程环境进行了额外的性能调整,还有许多其他功能,如无缝集成加密.