我发现在一些棘手的情况下，扩展Application类并使用它来保存引用和值是很有帮助的，否则在生命周期中很难通过配置更改来协调这些引用和值。
这样做真的有什么坏处吗?我不禁觉得这是一个"太容易"的修复，这意味着可能有一些主要的缺点，我没有考虑到。
我将把你的问题分解成两个子问题。
[在静态作用域中存储信息]是否有任何真正的缺点?
一些问题包括:
- 内存泄漏
线程安全，如果有多个线程可能达到静态值
内存泄漏处理N个可能的值，在您可能需要N个可能的值的情况下(例如，某些活动的多个实例，每个实例需要一个不同的值)
内存泄漏像保留的片段和
onRetainNonConfigurationInstance()一样，这个解决方案不能帮助进程终止和恢复最近的任务，而onSaveInstanceState()Bundle也可以帮助我提到内存泄漏了吗?
帮助缓解这些问题的常见模式包括:
-
考虑静态值是一个有限大小的缓存(例如，
LRUCache) -
使用事件总线代替自己的静态值
是否有任何真正的缺点[使用
Application作为静态作用域，而不是仅仅一个普通的static字段]?
只有一个Application实例。通常，与普通的static字段相比，它提供的价值不大。而且，由于各种库希望您使用它们的"特殊的雪花"Application基类，因此您尝试将自己的东西集中在那里的次数越少，将来遇到碰撞的可能性就越小。