Question

单例非活动类管理整个应用程序中的服务器API调用。如果通信失败，则经理类应启动登录活动（launchMode="singleTask"）。

manager类没有上下文，因此登录活动从应用程序上下文开始：

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和android contexts的SO文章，但是在阅读了很多之后，我仍然不确定这是否会带来任何风险。一些SO答案建议通过活动生命周期观察器保留上下文引用，但我想避免任何静态引用和潜在的内存泄漏。

我发现的唯一缺点是应用程序上下文是“非主题的”，但是活动看起来像预期的那样。所以这似乎不是问题吗？

这种方法有什么问题吗？

Answer 1

我发现的唯一缺点是应用程序上下文是“非主题的”，但是活动看起来像预期的那样。所以这似乎不是问题吗？

该活动具有自己的Context，它将与自己的主题相关联。 “不要为UI使用Application”规则更适用于扩大布局之类的事情-如果您处于活动中，请将该活动用于此类工作。

这种方法有什么问题吗？

我不是粉丝，不得不使用这种方法将应用程序维护一段时间：

这将使测试单例变得困难，尤其是使用对您的Application
除非您有其他方法可以使用户返回到她当时所在的位置，否则用户可能不希望您清除后背堆栈
这将使后台工作变得困难，因为您不应该突然冒出一个身份验证活动（直到在Android Q及更高版本上被禁止的程度）
这可能会在多窗口环境（分屏和自由格式）中引起额外的问题
从关注点分离的角度来看，这很丑陋（非UI单身人士不应做UI事情，例如显示UI）

因此，从技术上讲，它应该可以工作。我不会这样做（并且，如果我有德鲁特，我会淘汰必须维护的实施）。

从应用程序上下文开始活动时有风险吗？

1 个答案: