鸿蒙数据库开发：单例模式与RdbManager实践

1. 鸿蒙数据库开发痛点与解决方案

在鸿蒙应用开发中，数据库操作看似简单，实则暗藏诸多陷阱。许多开发者都曾遇到过这样的场景：应用运行一段时间后莫名卡顿，排查发现是数据库连接泄漏；或是应用升级后频繁闪退，原因是忘记处理旧版本数据迁移。这些问题往往在开发阶段难以察觉，直到上线后才暴露出来。

1.1 常见数据库管理误区

资源泄漏问题：频繁创建未关闭的数据库连接会导致内存和文件句柄耗尽。我曾在一个项目中接手过这样的代码：每个页面都独立创建RdbStore实例，结果应用在低端设备上运行30分钟后必然崩溃。

版本升级灾难：当应用新增表结构或字段时，若未正确处理旧版本数据迁移，用户更新应用后轻则数据丢失，重则直接闪退。去年某知名应用的大版本更新就因此收到大量差评。

线程安全隐患：多线程同时操作数据库时，若未做好同步控制，可能导致数据错乱。特别是在鸿蒙的分布式场景下，这个问题会被放大。

1.2 单例模式的必要性

单例模式是解决上述问题的银弹方案。通过确保全局只有一个数据库连接实例，我们可以：

• 避免重复创建连接的开销
• 集中管理资源释放
• 统一处理版本迁移
• 简化多线程同步控制

在鸿蒙的RdbStore实现中，底层SQLite连接本身是线程安全的，但应用层仍需保证对同一个RdbStore实例的访问有序性。我们的RdbManager单例封装正是为此而生。

2. RdbManager核心实现解析

2.1 单例生命周期管理

typescript复制// 精简后的核心单例实现
export class RdbManager {
  private static instance: RdbManager;
  private rdbStore: relationalStore.RdbStore | null = null;
  private context: common.UIAbilityContext | null = null;

  public static getInstance(): RdbManager {
    if (!RdbManager.instance) {
      RdbManager.instance = new RdbManager();
    }
    return RdbManager.instance;
  }

  public init(context: common.UIAbilityContext): void {
    this.context = context;
  }
}

这里有几个关键设计点：

1. 私有构造函数：防止外部通过new创建实例
2. 静态instance变量：持有唯一实例
3. 懒加载策略：首次调用getInstance()时才创建实例
4. 显式初始化：需要手动调用init()注入Context

提示：为什么不直接在getInstance()中初始化？因为Ability的context创建时机早于UI线程，分离初始化更符合鸿蒙生命周期。

2.2 数据库连接管理

typescript复制public async getRdbStore(): Promise<relationalStore.RdbStore> {
  // 已存在则直接返回
  if (this.rdbStore) return this.rdbStore; 
  
  // 检查上下文
  if (!this.context) throw new Error('Context未初始化');
  
  // 创建新连接
  const config: relationalStore.StoreConfig = {
    name: