单例非 Activity 类管理整个应用程序的服务器 API 调用。如果通信失败，管理器类应启动登录 Activity (launchMode="singleTask")。
管理器类不包含上下文，因此登录 Activity 是从应用程序上下文启动的:
Intent intent = new Intent(App.getInstance().getApplicationContext(), LoginActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_CLEAR_TASK | Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_NO_ANIMATION);
App.getInstance().getApplicationContext().startActivity(intent);
App.getInstance() 为此返回 MultiDexApplication 实例的单例。
这似乎有效。
现在，关于this topic的SO文章数不胜数。和 android contexts ，但看了很多之后，我仍然不确定这是否会带来任何风险。一些 SO 答案建议通过 Activity 生命周期观察器保留上下文引用，但我想避免任何静态引用和潜在的内存泄漏。
我发现的唯一缺点是应用程序上下文是“非主题的”，但 Activity 看起来符合预期。所以这似乎不是问题？
这种方法有什么问题吗？
最佳答案
The only drawback I found is that the app context is "non-themed", but the activity looks as expected. So that doesn't seem to be an issue?
Activity 有自己的 Context，将绑定(bind)到自己的主题。 “不要将 Application 用于 UI”规则更适用于展开布局之类的事情 — 如果您在 Activity 中，请将 Activity 用于此类工作。
Are there any issues with this approach?
我不是粉丝，我不得不维护一个采用这种方法的应用程序一段时间:
这将使测试单例变得困难，尤其是对您的
Application的硬编码引用
用户可能不喜欢你清除返回堆栈，除非你有其他方法让用户回到她当时所在的位置
这会使后台工作变得困难，因为您不应该突然弹出身份验证 Activity (以至于在 Android Q 和更高版本上被禁止)
在多窗口环境(分屏和自由格式)中可能会导致额外的问题
从关注点分离的角度来看，这很丑陋(非 UI 单例不应该做 UI 的事情，比如显示 UI)
因此，从技术上讲，它应该可以工作。我不会这样做(而且，如果我有勇气，我会删除我必须维护的那个实现)。
关于java - 从应用程序上下文启动 Activity 时的风险？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56266391/