回顾这篇文章，列举了使用单例的几个问题， 并看到了几个使用单例模式的Android应用程序的示例，我想知道使用单例而不是通过全局应用程序状态共享的单个实例（将android.os.Application子类化并获取它）是否是一个好主意。通过context.getApplication（））。
两种机制都有哪些优点/缺点？
老实说，我希望在此后的Singleton模式与Web应用程序中得到相同的答案，这不是一个好主意！但适用于Android。我对么？否则DalvikVM有什么不同？
编辑：我想对涉及的几个方面有意见：
Answers:
我非常不同意Dianne Hackborn的回应。我们会逐步从项目中删除所有单例，以支持轻量级的任务范围对象，可以在您实际需要它们时轻松地重新创建它们。
单例是测试的噩梦，如果延迟初始化，则会引入“状态不确定性”，并带有细微的副作用（当将调用getInstance()从一个范围移到另一个范围时，可能会突然浮出水面）。可见性已被提及为另一个问题，并且由于单例意味着对共享状态的“全局”（=随机）访问，因此当在并发应用程序中未正确同步时，可能会出现细微的错误。
我认为这是一种反模式，这是一种糟糕的面向对象风格，从本质上讲相当于维持全局状态。
回到您的问题：
尽管应用程序上下文本身可以视为单例，但它是框架管理的，并且具有明确定义的生命周期，范围和访问路径。因此，我认为，如果您确实需要管理应用程序全局状态，则应该在这里，无处可去。对于其他任何事情，请重新考虑是否确实需要单例对象，或者是否有可能重写您的单例类以实例化执行手头任务的小型短期对象。
我非常推荐单身人士。如果您有需要上下文的单例，请执行以下操作：
MySingleton.getInstance(Context c) {
//
// ... needing to create ...
sInstance = new MySingleton(c.getApplicationContext());
}与应用程序相比，我更喜欢单例，因为它有助于使应用程序更加组织化和模块化-而不是在一个地方需要维护应用程序的所有全局状态，每个单独的地方都可以照顾好自己。同样，单身人士懒惰地初始化（应要求）而不是引导您沿着Application.onCreate（）进行所有初始化的路径这一事实也很好。
使用单例并没有本质上的错误。只要有意义，请正确使用它们。Android框架实际上有很多，因为它可以维护加载资源和其他类似东西的按进程缓存。
同样对于简单的应用程序，单例也不会出现多线程问题，因为通过设计，应用程序的所有标准回调都在进程的主线程上分派，因此除非您通过线程或线程明确引入多线程，否则不会发生多线程事件。通过将内容提供者或服务IBinder发布到其他进程来隐式地进行。
只要考虑一下自己在做什么。:)
来自：开发人员>参考-应用
通常不需要子类化Application。在大多数情况下，静态单例可以以更模块化的方式提供相同的功能。如果您的单身人士需要全局上下文（例如，注册广播接收者），则可以为该函数提供一个上下文，该上下文在首次构造单身人士时在内部使用Context.getApplicationContext（）。
申请与单身人士不同，原因如下：
我遇到了同样的问题：Singleton还是使子类成为android.os.Application？
首先，我尝试使用Singleton，但有时我的应用会调用浏览器
Intent myIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com"));问题是，如果手机没有足够的内存，则会清理大多数类（甚至是Singletons）以获取一些内存，因此，当从浏览器返回到我的应用程序时，它每次都崩溃。
解决方案：将所需的数据放入Application类的子类中。
它们实际上是相同的。我可以看到一个区别。使用Application类，可以在Application.onCreate（）中初始化变量，并在Application.onTerminate（）中销毁它们。使用Singleton，您必须依靠VM初始化和销毁静态数据。
从众所周知的马口中
开发应用程序时，您可能发现有必要在整个应用程序中全局共享数据，上下文或服务。例如，如果您的应用程序具有会话数据，例如当前登录的用户，则您可能希望公开此信息。在Android中，解决此问题的模式是让android.app.Application实例拥有所有全局数据，然后将您的Application实例视为具有对各种数据和服务的静态访问器的单例。
编写Android应用时，可以确保只有android.app.Application类的一个实例，因此可以安全地（并由Google Android团队推荐）将其视为单例。也就是说，您可以安全地将静态getInstance（）方法添加到Application实现中。像这样：
public class AndroidApplication extends Application {
private static AndroidApplication sInstance;
public static AndroidApplication getInstance(){
return sInstance;
}
@Override
public void onCreate() {
super.onCreate();
sInstance = this;
}
}我的活动调用了finish（）（不会立即完成，但最终会完成）并调用Google Street Viewer。当我在Eclipse上调试时，调用Street Viewer时，我与应用程序的连接断开，我理解为（整个）应用程序已关闭，以释放内存（因为完成一个活动不应导致此行为） 。不过，我能够通过onSaveInstanceState（）将状态保存在Bundle中，并在堆栈中下一个活动的onCreate（）方法中将其还原。通过使用静态单例或子类化Application，我将面临应用程序的关闭和丢失状态（除非我将其保存在Bundle中）。因此，根据我的经验，它们在国家保护方面是相同的。我注意到在Android 4.1.2和4.2.2中该连接丢失，但在4.0.7或3.2.4上却没有，