回忆这个post enumerating several problems of using singletons 并且已经看到了几个使用单例模式的 Android 应用程序示例，我想知道使用单例而不是通过全局应用程序状态共享的单个实例是否是一个好主意（子类化 android.os.Application 并通过 context.getApplication() 获取它）。
这两种机制有什么优点/缺点？
老实说，我希望这篇文章Singleton pattern with Web application, Not a good idea! 得到相同的答案，但适用于 Android。我对么？ DalvikVM 有什么不同？
编辑：我想就所涉及的几个方面发表意见：
【问题讨论】：
标签： java android design-patterns singleton
我非常不同意 Dianne Hackborn 的回应。我们一点一点地从我们的项目中删除所有单例，以支持轻量级、任务范围的对象，这些对象可以在您实际需要时轻松地重新创建。
单例是测试的噩梦，如果延迟初始化，将引入带有微妙副作用的“状态不确定性”（当将调用 getInstance() 从一个范围转移到另一个范围时，可能会突然出现） .可见性是另一个问题，由于单例意味着“全局”（=随机）访问共享状态，因此在并发应用程序中未正确同步时可能会出现细微的错误。
我认为它是一种反模式，它是一种糟糕的面向对象风格，本质上相当于维护全局状态。
回到你的问题：
虽然应用上下文本身可以被认为是一个单例，但它是由框架管理的，并且具有明确定义的生命周期、范围和访问路径。因此，我相信如果你确实需要管理应用程序全局状态，它应该去这里，别无他处。对于其他任何事情，请重新考虑您是否真的需要一个单例对象，或者是否也可以重写您的单例类来实例化执行手头任务的小型、短暂的对象。 p>
【讨论】：
我非常推荐单身人士。如果你有一个需要上下文的单例，有：
MySingleton.getInstance(Context c) {
//
// ... needing to create ...
sInstance = new MySingleton(c.getApplicationContext());
}
我更喜欢单例而不是应用程序，因为它有助于使应用程序更有条理和模块化——而不是在一个地方需要维护整个应用程序的所有全局状态，每个单独的部分都可以自行处理。此外，单例延迟初始化（根据请求）而不是引导您在 Application.onCreate() 中预先进行所有初始化这一事实也很好。
使用单例没有本质上的错误。在有意义的时候正确使用它们。 Android 框架实际上有很多，用于维护加载资源的每个进程的缓存和其他类似的东西。
对于简单的应用程序，多线程也不会成为单例的问题，因为根据设计，应用程序的所有标准回调都在进程的主线程上分派，因此除非您明确引入多线程，否则不会发生多线程通过线程或通过将内容提供者或服务 IBinder 发布到其他进程隐式地发布。
请仔细考虑您正在做的事情。 :)
【讨论】：
发件人：Developer > reference - Application
通常不需要子类化应用程序。在大多数情况下， 静态单例可以以更模块化的方式提供相同的功能 大大地。如果您的单例需要全局上下文（例如注册 广播接收器），检索它的函数可以给出 上下文在内部使用 Context.getApplicationContext() 时 首先构造单例。
【讨论】：
应用和Singleton不一样。原因是：
【讨论】：
我也遇到了同样的问题：Singleton 还是创建一个子类 android.os.Application？
首先我尝试使用 Singleton，但我的应用有时会调用浏览器
Intent myIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com"));
问题是，如果手机没有足够的内存，你的大部分类（甚至单例）都会被清理以获取一些内存，所以当从浏览器返回到我的应用程序时，它每次都会崩溃。
解决方案：将所需的数据放在 Application 类的子类中。
【讨论】：
同时考虑两者：
此外，我建议您扩展 Context 以不仅包括对单例对象的访问，还包括一些需要全局访问的功能，例如：context.logOffUser()、context.readSavedData() 等。可能重命名Context to Facade 将是有意义的。
【讨论】：
它们实际上是一样的。 我可以看到一个区别。使用 Application 类，您可以在 Application.onCreate() 中初始化变量并在 Application.onTerminate() 中销毁它们。使用单例，您必须依赖 VM 初始化和销毁静态数据。
【讨论】：
出自马的口中……
在开发您的应用时，您可能会发现有必要在您的应用中全球共享数据、上下文或服务。例如，如果您的应用具有会话数据，例如当前登录的用户，您可能希望公开此信息。在 Android 中，解决此问题的模式是让您的 android.app.Application 实例拥有所有全局数据，然后将您的 Application 实例视为具有各种数据和服务的静态访问器的单例。
在编写 Android 应用程序时，保证您只有一个 android.app.Application 类的实例，因此将其视为单例是安全的（并且 Google Android 团队建议）。也就是说，您可以安全地将静态 getInstance() 方法添加到您的应用程序实现中。像这样：
public class AndroidApplication extends Application {
private static AndroidApplication sInstance;
public static AndroidApplication getInstance(){
return sInstance;
}
@Override
public void onCreate() {
super.onCreate();
sInstance = this;
}
}
【讨论】：
我的 2 美分：
我确实注意到，当我的活动被销毁时，一些单例/静态字段被重置。我在一些低端 2.3 设备上注意到了这一点。
我的情况很简单：我只有一个私有文件“init_done”和一个从activity.onCreate() 调用的静态方法“init”。我注意到方法 init 在重新创建活动时重新执行自身。
虽然我无法证明我的肯定，但这可能与单例/类首先创建/使用的时间有关。当活动被销毁/回收时，似乎只有这个活动引用的所有类也被回收了。
我将我的单例实例移动到应用程序的子类中。我从应用程序实例访问它们。并且，从那以后，再也没有注意到这个问题。
我希望这可以帮助某人。
【讨论】：
我的活动调用了 finish()（它不会立即完成，但最终会完成）并调用 Google Street Viewer。当我在 Eclipse 上调试它时，调用 Street Viewer 时我与应用程序的连接中断，我理解为（整个）应用程序被关闭，据说是为了释放内存（因为完成的单个活动不应该导致这种行为） .不过，我可以通过 onSaveInstanceState() 将状态保存在 Bundle 中，并在堆栈中下一个活动的 onCreate() 方法中恢复它。通过使用静态单例或子类化应用程序，我将面临应用程序关闭和丢失状态（除非我将其保存在 Bundle 中）。因此，根据我的经验，它们在国家保护方面是相同的。我注意到在 Android 4.1.2 和 4.2.2 中连接丢失，但在 4.0.7 或 3.2.4 中没有，据我了解，这表明内存恢复机制在某些时候发生了变化。
【讨论】：