Android Room 数据库底层是有 SQLite 实现的，所以对于 Room 的 Journal mode的分析其实是要基于 SQLite 的 Journal mode 分析。
首先要明白 Journal mode 是什么？它是一个重要的数据库设置，用于控制 SQLite 如何记录事务日志来确保数据完整性和恢复能力。日志模式主要决定了在进行数据修改（如插入、更新和删除操作）时，这些变更是如何被记录到数据库中的。以下是 SQLite 支持的几种常见的日志模式：
-
DELETE
这是 SQLite 的默认日志模式。在这种模式下，所有的变更都会先被记录到一个单独的日志文件（通常名为 *-journal 的文件）。当事务提交时，这些变更会被写入到主数据库文件中。如果发生崩溃或电源故障，SQLite 可以使用这个日志来恢复到最后一次一致的状态。当事务提交之后， *-journal 文件会被删除，所以被称为 DELETE。 -
TRUNCATE
与 DELETE 模式相似，TRUNCATE 模式也会在单独的日志文件中记录数据变更。不同之处在于，当事务提交后，SQLite 不是删除日志文件，而是将其大小截断为零。这种方法可以减少文件系统的操作，可能提高某些情况下的性能。 -
PERSIST
在 PERSIST 模式下，日志文件在事务结束后不会被删除或截断，而是保留下来，并在下次事务开始时重用。这种模式下，日志文件的内容会在事务提交时被写入数据库，但文件本身仅在开始新的事务时被清空，这可以减少文件系统的操作。 -
MEMORY
在 MEMORY 模式下，事务日志被保持在内存中而不是写入到磁盘。这意味着，如果数据库崩溃或电源失效，所有未提交的事务数据将丢失。这种模式可能在对持久性要求不高但需要快速执行事务的应用中有用。 -
WAL (Write-Ahead Logging)
WAL 是一种高效的日志模式，它允许读和写操作并发执行。在 WAL 模式下，所有变更首先被写入到一个名为 WAL 文件的日志中，主数据库文件在事务提交时不会立即更新。相反，这些变更会在特定的时刻被“检查点”操作从 WAL 文件中移动到主数据库文件。这种模式提高了多任务环境中的并发性能，并且常被推荐用于多线程应用。
那么如何设置 Journal Mode 呢？
要设置 SQLite 的日志模式，可以在连接到数据库时，或者通过 SQL 命令动态改变。例如，设置为 WAL 模式的 SQL 命令是：
PRAGMA journal_mode = WAL;
至于选择正确的日志模式，是需要根据应用场景的具体需求（性能、数据安全性、恢复能力等等）来优化数据库操作。
我们对 SQLite 的 Journal mode 有了相当的了解之后，然后来看 Room 数据库的 Journal mode，我们会发现，它就三种:
- AUTOMATIC
- TRUNCATE
- WRITE_AHEAD_LOGGING
Room 这么做的道理，估计是为了简化 API 的使用，同时也能满足大多数应用的需要。
对于 AUTOMATIC, 它是默认选择的模式。其实就是按照特定的策略选中 TRUNCATE 或者 WRITE_AHEAD_LOGGING .上面已经解释了TRUNCATE 和 WRITE_AHEAD_LOGGING 的区别，相信大家都能理解。
当然，对于如何设置 Journal mode的设置：
Room.databaseBuilder(context, AppDatabase.class, "database-name").setJournalMode(RoomDatabase.JournalMode.WRITE_AHEAD_LOGGING).build();
