Android中构造函数持有Context是否会引发内存泄漏？

先针对你提到的两个场景分别拆解分析，再给出具体的优化方向：

一、WebViewClient场景：传getApplicationContext()确实欠妥，而且完全冗余 #

你之前提到的appContext变量确实没必要保留——正如@sajjad指出的，shouldOverrideUrlLoading里的view参数直接就能拿到Context（view.getContext()），而且这个Context是WebView所属的上下文（大概率是Activity），比全局ApplicationContext更灵活：

• 虽然Toast用ApplicationContext也能正常显示，但如果后续你需要做一些依赖Activity上下文的操作（比如启动新Activity、显示Dialog），用view.getContext()就能直接支持，不用再额外传参。
• 更重要的是，避免了不必要的Context持有，减少了潜在的内存泄漏风险（虽然ApplicationContext本身不会导致泄漏，但冗余的变量就是多余的复杂度）。

修改后的代码可以简化成这样：

public class NonInteractiveWebViewClient extends WebViewClient {
    public boolean canBrowse = false;

    @Override
    public boolean shouldOverrideKeyEvent (WebView view, KeyEvent event) {
        return true;
    }

    @Override
    public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {
        String host = Uri.parse(view.getUrl()).getHost();
        canBrowse = // 此处为判断是否允许导航的逻辑
        if (canBrowse) {
            return false;
        } else {
            Context context = view.getContext();
            Toast.makeText(context, context.getString(R.string.link_test_preview_only), Toast.LENGTH_SHORT).show();
            return true;
        }
    }
}

（顺便提一句：Java类名建议用大驼峰命名，比如NonInteractiveWebViewClient，符合编码规范）

二、通用工具类场景：你的模块化思路没问题，但要区分Context类型 #

对于那种供多Activity调用的独立工具类，存储Context来减少重复代码是合理的，但核心是必须存储ApplicationContext，而不是Activity Context：

• ApplicationContext的生命周期和整个App一致，不会因为某个Activity销毁而导致内存泄漏，是安全的全局上下文。
• 如果工具类的方法只需要全局资源（比如getString、Toast、SharedPreferences、获取系统服务），存储ApplicationContext完全没问题。

推荐的工具类实现方式 #

方式1：构造函数传入并存储ApplicationContext

public class AppUtility {
    private final Context appContext;

    // 调用者传入任意Context，我们内部只保留全局上下文
    public AppUtility(Context context) {
        this.appContext = context.getApplicationContext();
    }

    // 示例方法：显示全局Toast
    public void showPreviewRestrictedToast() {
        Toast.makeText(appContext, appContext.getString(R.string.link_test_preview_only), Toast.LENGTH_SHORT).show();
    }

    // 其他通用方法：比如获取全局资源、操作SharedPreferences等
    public String getAppString(int resId) {
        return appContext.getString(resId);
    }
}

调用时，每个Activity只需要初始化一次：

// 在Activity的onCreate里
AppUtility utility = new AppUtility(this);

后续调用方法就不用再传Context了，减少重复代码。

方式2：单例模式（适合全局唯一的工具类）

如果工具类是全局唯一的，可以做成单例，确保只初始化一次：

public class AppUtility {
    private static AppUtility instance;
    private final Context appContext;

    private AppUtility(Context context) {
        this.appContext = context.getApplicationContext();
    }

    // 初始化时传入任意Context，内部转为全局上下文
    public static synchronized AppUtility getInstance(Context context) {
        if (instance == null) {
            instance = new AppUtility(context);
        }
        return instance;
    }

    // 通用方法...
}

调用时，在Application类或者第一个启动的Activity里初始化一次，后续直接调用：

// 在Application的onCreate里
AppUtility.getInstance(this);

// 在任意Activity里调用
AppUtility.getInstance().showPreviewRestrictedToast();

需要注意的例外情况 #

如果工具类的某些方法必须依赖Activity上下文（比如启动Activity、显示Dialog、操作当前Activity的View），绝对不能把Activity Context存为成员变量——应该让调用者在调用该方法时传入对应的Activity Context，避免持有已销毁的Activity引用导致内存泄漏：

// 示例：需要Activity上下文的方法
public void showRestrictionDialog(Activity activity) {
    new AlertDialog.Builder(activity)
        .setTitle("预览模式")
        .setMessage("当前处于受限预览模式，无法继续导航")
        .setPositiveButton("确定", null)
        .show();
}

总结 #

你的模块化、减少重复代码的思路非常正确，只要注意以下两点就不会有问题：

1. 能通过现有参数（比如WebView的view）获取Context的场景，直接用参数里的Context，不要额外存储；
2. 必须存储Context的通用工具类，一定要存储ApplicationContext，避免持有Activity Context导致内存泄漏。

内容的提问来源于stack exchange，提问作者Fat Monk