I want to ask a question about the iPhone. I am writing a program which can add the record to the iPhone build-in Contacts. However, I don't know that how many users can store in the iPhone Contacts. Is there some limitation (e.g. iPhone build-in Contacts only support 2000 record). of the size of the contacts?
我想问一个关于iPhone的问题。我正在编写一个程序,可以将记录添加到iPhone内置联系人。但是,我不知道有多少用户可以存储在iPhone Contacts中。是否有一些限制(例如iPhone内置联系人仅支持2000记录)。联系人的大小?
Besides, Can the size of the iPhone (e.g. 32GB, 64GB) or other elements affect the size of the contacts book? Thank you.
此外,iPhone的大小(例如32GB,64GB)或其他元素是否会影响通讯录的大小?谢谢。
1 个解决方案
#1
1
The contacts are stored in a pair of SQLite databases on the phone, so the only limits are limits imposed by SQLite and the processing power of the device.
联系人存储在手机上的一对SQLite数据库中,因此唯一的限制是SQLite强加的限制和设备的处理能力。
The short answer is: you're not likely to run into a problem unless you're trying to do something extremely large scale, like write a company directory app for the ~1.6M Indian Railway employees or capture all of the ~200M US registered voters. I've created a database with all US zip codes and another with multiple mappings to all English, German, French and Spanish words from the standard Linux spelling dictionaries and have not run into problems. The latter had a table with more than 3 million records and runs fine on an original iPhone.
简短的回答是:除非您尝试做一些非常大规模的事情,否则您不太可能遇到问题,例如为~160万印度铁路员工编写公司目录应用程序或捕获所有约200M美国注册选民。我创建了一个包含所有美国邮政编码的数据库,另一个包含来自标准Linux拼写词典的所有英语,德语,法语和西班牙语单词的多个映射,并且没有遇到问题。后者拥有超过300万条记录的表格,在原版iPhone上运行良好。
You're more likely to run into machine performance limits before an absolute limit on the number of records. For example, consider this from the SQLite site:
在绝对限制记录数之前,您更有可能遇到机器性能限制。例如,从SQLite站点考虑这个:
When you start a transaction in SQLite (which happens automatically before any write operation that is not within an explicit BEGIN...COMMIT) the engine has to allocate a bitmap of dirty pages in the disk file to help it manage its rollback journal. SQLite needs 256 bytes of RAM for every 1MB of database. For smaller databases, the amount of memory required is not a problem, but when databases begin to grow into the multi-gigabyte range, the size of the bitmap can get quite large. If you need to store and modify more than a few dozen GB of data, you should consider using a different database engine.
当您在SQLite中启动事务(在任何不在显式BEGIN ... COMMIT中的写操作之前自动发生)时,引擎必须在磁盘文件中分配脏页的位图以帮助它管理其回滚日志。 SQLite每1MB数据库需要256个字节的RAM。对于较小的数据库,所需的内存量不是问题,但是当数据库开始增长到数千兆字节范围时,位图的大小可能会变得非常大。如果需要存储和修改超过几十GB的数据,则应考虑使用其他数据库引擎。
So, (if my math is right) a 30G database would require 7.5M of space for the bitmaps during an INSERT. This may be hard on a first gen iPhone (only had 64M RAM and 16G Flash, besides), but maybe OK on later models with more memory. That said, before you get to this many records, updating the indexes or asking the AddressBook.app to display them may result in unacceptable performance.
所以,(如果我的数学是正确的)30G数据库在INSERT期间需要7.5M的空间用于位图。对于第一代iPhone来说这可能很难(除此之外只有64M RAM和16G闪存),但在具有更多内存的后续型号上也许可以。也就是说,在你得到这么多记录之前,更新索引或要求AddressBook.app显示它们可能会导致不可接受的性能。
If you want to explore the AddressBook schema, create a single contact in the simulator, then in a Terminal window:
如果要浏览AddressBook架构,请在模拟器中创建单个联系人,然后在终端窗口中:
% cd "~/Library/Applications Support/iPhone Simulator/4.0.2/Library/AddressBook"
% sqlite AddressBook.sqlitedb
sqlite> .schema
This is, however, an excellent example of why you must test your app on a real device before submitting it to the store. Such an app will run without issue in the simulator's 3.0GHz, multi-core, 4GB RAM environment, but not so well in on a 1/2 GHz 2nd gen iPod Touch.
但是,这是一个很好的例子,说明为什么必须在将应用程序提交到商店之前在真实设备上测试它。这样的应用程序在模拟器的3.0GHz,多核,4GB RAM环境中运行没有问题,但在1/2 GHz第二代iPod Touch上运行不太好。
#1
1
The contacts are stored in a pair of SQLite databases on the phone, so the only limits are limits imposed by SQLite and the processing power of the device.
联系人存储在手机上的一对SQLite数据库中,因此唯一的限制是SQLite强加的限制和设备的处理能力。
The short answer is: you're not likely to run into a problem unless you're trying to do something extremely large scale, like write a company directory app for the ~1.6M Indian Railway employees or capture all of the ~200M US registered voters. I've created a database with all US zip codes and another with multiple mappings to all English, German, French and Spanish words from the standard Linux spelling dictionaries and have not run into problems. The latter had a table with more than 3 million records and runs fine on an original iPhone.
简短的回答是:除非您尝试做一些非常大规模的事情,否则您不太可能遇到问题,例如为~160万印度铁路员工编写公司目录应用程序或捕获所有约200M美国注册选民。我创建了一个包含所有美国邮政编码的数据库,另一个包含来自标准Linux拼写词典的所有英语,德语,法语和西班牙语单词的多个映射,并且没有遇到问题。后者拥有超过300万条记录的表格,在原版iPhone上运行良好。
You're more likely to run into machine performance limits before an absolute limit on the number of records. For example, consider this from the SQLite site:
在绝对限制记录数之前,您更有可能遇到机器性能限制。例如,从SQLite站点考虑这个:
When you start a transaction in SQLite (which happens automatically before any write operation that is not within an explicit BEGIN...COMMIT) the engine has to allocate a bitmap of dirty pages in the disk file to help it manage its rollback journal. SQLite needs 256 bytes of RAM for every 1MB of database. For smaller databases, the amount of memory required is not a problem, but when databases begin to grow into the multi-gigabyte range, the size of the bitmap can get quite large. If you need to store and modify more than a few dozen GB of data, you should consider using a different database engine.
当您在SQLite中启动事务(在任何不在显式BEGIN ... COMMIT中的写操作之前自动发生)时,引擎必须在磁盘文件中分配脏页的位图以帮助它管理其回滚日志。 SQLite每1MB数据库需要256个字节的RAM。对于较小的数据库,所需的内存量不是问题,但是当数据库开始增长到数千兆字节范围时,位图的大小可能会变得非常大。如果需要存储和修改超过几十GB的数据,则应考虑使用其他数据库引擎。
So, (if my math is right) a 30G database would require 7.5M of space for the bitmaps during an INSERT. This may be hard on a first gen iPhone (only had 64M RAM and 16G Flash, besides), but maybe OK on later models with more memory. That said, before you get to this many records, updating the indexes or asking the AddressBook.app to display them may result in unacceptable performance.
所以,(如果我的数学是正确的)30G数据库在INSERT期间需要7.5M的空间用于位图。对于第一代iPhone来说这可能很难(除此之外只有64M RAM和16G闪存),但在具有更多内存的后续型号上也许可以。也就是说,在你得到这么多记录之前,更新索引或要求AddressBook.app显示它们可能会导致不可接受的性能。
If you want to explore the AddressBook schema, create a single contact in the simulator, then in a Terminal window:
如果要浏览AddressBook架构,请在模拟器中创建单个联系人,然后在终端窗口中:
% cd "~/Library/Applications Support/iPhone Simulator/4.0.2/Library/AddressBook"
% sqlite AddressBook.sqlitedb
sqlite> .schema
This is, however, an excellent example of why you must test your app on a real device before submitting it to the store. Such an app will run without issue in the simulator's 3.0GHz, multi-core, 4GB RAM environment, but not so well in on a 1/2 GHz 2nd gen iPod Touch.
但是,这是一个很好的例子,说明为什么必须在将应用程序提交到商店之前在真实设备上测试它。这样的应用程序在模拟器的3.0GHz,多核,4GB RAM环境中运行没有问题,但在1/2 GHz第二代iPod Touch上运行不太好。