我花了很多时间研究我们设备上的一些性能问题，并注意到我们有相当多的应用程序都在进行数据库读/写。
我开始使用 Contacts API 来插入新的联系人和数据行，但速度非常慢。 1 分 18 秒插入大约 1500 行(250 个原始联系人和 1250 个数据行)..
我曾在另一个应用程序中使用插入助手进行性能插入，并决定编写一个测试应用程序，该应用程序将写入带有单独插入方法的单独数据库。
每个数据库都有一个表，每个表有 4 列: _ID、名称、时间和 Blob(均为“字符串”类型)——就像联系人提供者定义数据列一样。
_ID 是自动递增的 pk，Name 只是插入相同的东西 '1234567890'，time 只是以 milis 为单位的当前系统时间，而 BLob 是一个长度为 6400 且充满字母 'A' 的字符串...
我首先检查了批量插入，但它所做的只是循环遍历您定义的所有插入，并且与单独插入一样慢(或者对性能的影响可以忽略不计)。
我测试了 3 种不同的插入方法: ContentValues w/db.insert 方法: SQLiteStatement w/statement.execute() (在事务中完成)。 带事务的 SqliteInsertHelper。
我可以提供一些代码，但我从 InsertHelper 获得了最佳性能，并且想知道为什么它被弃用了:
插入 100 条记录的时间 ContentValues:7.778 秒(写入 82 个字节/毫秒) SQLiteStatement:1.311 秒(写入 489 字节/毫秒) SqliteInsertHElper:0.292 秒(写入 2197 字节/毫秒)
有什么想法吗？
最佳答案
如果不查看确实弃用它的实际提交，就很难获得关于为什么弃用 InsertHelper 的任何信息。弃用 InsertHelper 的工程师给出了以下原因:
This class does not offer any advantages over SQLiteStatement and just makes code more complex and error-prone.
从 InsertHelper 重构为 SQLiteStatement 后，我同意。一个异常(exception)是空安全绑定(bind)函数。 InsertHelper 会自动为您调用 bindNull()，而 SQLiteStatement 会在您传递例如 null String 时崩溃，并且您必须在调用 bindString() 之前执行自己的 null 检查。
参见: https://android.googlesource.com/platform/frameworks/base/+/b33eb4e%5E!/
关于android - 为什么不推荐使用 InsertHelper？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15302271/