它们实际上是一样的。 我能看出一点不同。使用Application类，你可以在Application. oncreate()中初始化你的变量，并在Application. onterminate()中销毁它们。对于单例，你必须依赖VM初始化和销毁静态数据。

同时考虑这两者:

将单例对象作为类中的静态实例。 拥有一个公共类(Context)，它为应用程序中的所有单例对象返回单例实例，这样做的好处是Context中的方法名将是有意义的，例如:Context . getloggedinuser()而不是User.getInstance()。

此外，我建议您扩展上下文，不仅包括对单例对象的访问，还包括需要全局访问的一些功能，例如:Context . logoffuser ()， Context . readsaveddata()等。也许将Context重命名为Facade会有意义。

应用程序与单例不一样。原因如下:

应用程序的方法(如onCreate)在ui线程中调用; Singleton的方法可以在任何线程中调用; 在Application的onCreate方法中，可以实例化Handler; 如果单例是在无ui线程中执行的，则不能 实例化处理程序; 应用程序具有管理的生命周期的能力 activity。它有方法 “registerActivityLifecycleCallbacks”。但是单身人士没有 能力。

My activity calls finish() (which doesn't make it finish immediately, but will do eventually) and calls Google Street Viewer. When I debug it on Eclipse, my connection to the app breaks when Street Viewer is called, which I understand as the (whole) application being closed, supposedly to free up memory (as a single activity being finished shouldn't cause this behavior). Nevertheless, I'm able to save state in a Bundle via onSaveInstanceState() and restore it in the onCreate() method of the next activity in the stack. Either by using a static singleton or subclassing Application I face the application closing and losing state (unless I save it in a Bundle). So from my experience they are the same with regards to state preservation. I noticed that the connection is lost in Android 4.1.2 and 4.2.2 but not on 4.0.7 or 3.2.4, which in my understanding suggests that the memory recovery mechanism has changed at some point.

从众所周知的马的嘴…

在开发你的应用程序时，你可能会发现有必要在整个应用程序中共享数据、上下文或服务。例如，如果你的应用程序有会话数据，比如当前登录的用户，你可能会想要公开这些信息。在Android中，解决这个问题的模式是让你的Android .app.Application实例拥有所有的全局数据，然后把你的Application实例当作一个具有各种数据和服务的静态访问器的单例。

当编写一个Android应用程序时，你保证只有一个Android .app. application类的实例，所以它是安全的(谷歌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;
    }
}

我非常不同意Dianne Hackborn的回答。我们一点一点地从我们的项目中移除所有的单例对象，以支持轻量级的、任务范围的对象，当你真正需要它们时，它们可以很容易地重新创建。

单例是测试的噩梦，如果延迟初始化，将引入带有微妙副作用的“状态不确定性”(当将对getInstance()的调用从一个作用域移动到另一个作用域时，可能会突然出现)。可见性是另一个问题，由于单例意味着对共享状态的“全局”(=随机)访问，在并发应用程序中没有正确同步时，可能会出现微妙的错误。

我认为这是一种反模式，它是一种糟糕的面向对象风格，本质上相当于维护全局状态。

回到你的问题:

虽然应用程序上下文本身可以被认为是一个单例，但它是由框架管理的，并且具有定义良好的生命周期、作用域和访问路径。因此，我认为如果你确实需要管理app-global状态，它应该放在这里，而不是其他地方。对于其他任何事情，重新考虑是否真的需要一个单例对象，或者是否也可以重写单例类来实例化执行手头任务的小型、短期对象。