Android Room：单例Repository与静态方法实现的优劣对比

先明确：你贴的第一个代码是基础实例类，实际开发中开发者通常会把它改成单例模式（避免重复初始化），这也是你提到的“单例方案”的常见形态。下面对比两种方案的优缺点，并说明适用场景。

方案1：实例化/单例Repository（优化后避免内存泄漏） #

通常开发者会改成单例，并强制使用ApplicationContext：

public class GameRepository {
    private static volatile GameRepository instance;
    private final GamesDao gamesDao;

    private GameRepository(Context context) {
        // 核心：用ApplicationContext，避免持有Activity/Fragment的Context
        gamesDao = RoomDatabase.getInstance(context.getApplicationContext()).getGamesDao();
    }

    // 双重校验锁实现线程安全的单例
    public static GameRepository getInstance(Context context) {
        if (instance == null) {
            synchronized (GameRepository.class) {
                if (instance == null) {
                    instance = new GameRepository(context);
                }
            }
        }
        return instance;
    }

    public Game getGameForIndex(String game) {
        return gamesDao.getGameById(game);
    }
}

优点 #

• 性能高效：仅初始化一次RoomDatabase和GamesDao，后续调用直接复用，避免重复的实例校验和获取操作。
• 代码简洁：仅在首次获取单例时传一次Context，后续调用数据库方法无需重复传参。
• 扩展性强：能轻松添加缓存、网络请求等额外逻辑，类结构清晰，便于维护多个数据库操作方法。
• 测试友好：支持构造方法注入GamesDao，单元测试时可传入Mock实现，无需依赖真实数据库。
• 符合OOP设计：封装数据库操作逻辑，遵循单一职责，代码可读性更高。

缺点 #

• 需注意内存泄漏：如果错误持有Activity/Fragment的Context（而非ApplicationContext），会导致Context无法回收。但这个问题完全可控——只要在初始化时强制使用context.getApplicationContext()即可避免。
• 单例的微小代价：全局实例生命周期与应用一致，会占用少量内存，但对于Repository来说这个开销可以忽略。

方案2：静态方法按需传Context #

就是你贴的第二个实现：

public class GameRepository {
    public static Game getGameForIndex(String game, Context context) {
        return RoomDatabase.getInstance(context).getGamesDao().getGameById(game);
    }
}

优点 #

• 零内存泄漏风险：每次调用才传入Context，方法执行完毕后Context无长期引用，彻底避免泄漏问题。
• 实现简单：无需维护实例状态，代码量极少，适合极简单的场景。

缺点 #

• 性能冗余：每次调用都要重复获取RoomDatabase和GamesDao，即使Room本身是单例，也会有重复的校验开销。
• 代码繁琐：每个数据库方法都要传入Context参数，多处调用时重复传参很麻烦。
• 扩展性差：后续添加新方法都要加Context参数；若要引入缓存、依赖其他服务，代码会迅速臃肿。
• 测试困难：静态方法无法Mock，单元测试只能用真实数据库，效率极低。

哪种方案更合适？ #

优先选择方案1（单例Repository+ApplicationContext），原因如下：

1. 内存泄漏风险完全可控，只要规范使用ApplicationContext就不会有问题。
2. 性能、代码简洁性、扩展性的优势在实际项目中价值远大于静态方案，尤其是在数据库操作频繁、方法较多的场景下。
3. 符合Android主流架构（如MVVM）的设计规范，便于和ViewModel、Dependency Injection等框架配合使用。

方案2仅适合极简场景：比如整个App只调用一两次该数据库方法，此时静态方法的简单性可以抵消其缺点，但绝大多数实际项目中，方案1是更优选择。

内容的提问来源于stack exchange，提问作者Nexussim Lements