Android中的单身人士与应用程序上下文?

回顾这篇文章列举了使用单例的几个问题,并看到了几个Android应用程序使用单例模式的例子,我不知道是否是一个好主意,而不是通过全局应用程序状态共享单个实例(subclassing android.os.Application并获得它通过context.getApplication())。

这两种机制有什么优点/缺点?

说实话,我希望在这篇文章中有同样的答案与Web应用程序的单例模式,不是一个好主意! 但适用于Android。 我对么? DalvikVM有什么不同呢?

编辑:我想对涉及的几个方面有意见:

  • 同步
  • 可重用性
  • testing

10 Solutions collect form web for “Android中的单身人士与应用程序上下文?”

我非常不同意Dianne Hackborn的回应。 我们一点一点地从我们的项目中删除所有的单身人士,以支持轻量级的,任务范围的对象,当您真正需要时,可以很容易地重新创build这些对象。

单身是testing的噩梦,如果懒惰地初始化,会引入带有微妙副作用的“状态不确定性”(当从一个范围向另一个范围移动对getInstance()的调用时可能突然出现)。 可视性已被提及为另一个问题,由于单身意味着“全局”(随机)访问共享状态,所以在并发应用程序中没有正确同步时可能会出现细微的错误。

我认为这是一个反模式,这是一个糟糕的面向对象的风格,基本上等同于维护全局状态。

回到你的问题:尽pipe应用程序上下文本身可以被认为是一个单例,但它是框架pipe理的,并且有一个定义良好的生命周期,范围和访问path。 因此,我相信,如果您确实需要pipe理应用程序全局状态,则应该到此处,无处不在。 对于其他任何事情,重新思考一下是否真的需要一个单例对象,或者是否可以重写单例类来实例化实现手头任务的小型短暂对象。

我非常推荐单身人士。 如果你有一个需要上下文的单身人士,请:

MySingleton.getInstance(Context c) { // // ... needing to create ... sInstance = new MySingleton(c.getApplicationContext()); } 

我比单一的应用程序更喜欢它,因为它有助于保持应用程序更加有组织和模块化 – 而不是有一个地方应用程序中的所有全局状态需要维护,每个独立的部分可以自己照顾自己。 另外事实上,单身人士懒惰地初始化(在请求),而不是在Application.onCreate()中预先执行所有初始化的path是好的。

单身人士没有任何内在的错误。 只要正确使用它们,当它是有道理的。 Android框架实际上有很多,因为它保持每个进程的caching加载的资源和其他这样的东西。

同样对于简单的应用程序,multithreading并不会成为singleton的问题,因为通过devise,应用程序的所有标准callback都被分派到进程的主线程中,所以除非通过线程显式引入它,否则不会发生multithreading通过将内容提供者或服务IBinder发布到其他进程来隐式地进行。

只是想你在做什么。 🙂

来自: http : //developer.android.com/reference/android/app/Application.html

通常不需要子类Application。 在大多数情况下,静态单例可以以更模块化的方式提供相同的function。 如果你的单例需要一个全局上下文(例如注册广播接收者),那么检索它的函数可以被赋予一个Context,它在第一次构造单例时在内部使用Context.getApplicationContext()。

我有同样的问题:单身或build立一个子类android.os.Application?

首先我尝试了Singleton,但是我的应用程序在某个时候打电话给浏览器

 Intent myIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com")); 

问题是,如果手机没有足够的内存,你的大部分类(甚至是单身人士)都会被清理干净以获得一些内存,所以当从浏览器返回到我的应用时,它每次都会崩溃。

解决scheme:将所需的数据放入Application类的子类中。

应用程序与Singleton不一样,原因是:

  1. 应用程序的方法(如onCreate)在ui线程中调用;
  2. 单例的方法可以在任何线程中调用;
  3. 在Application的“onCreate”方法中,可以实例化Handler;
  4. 如果单例在非UI线程中执行,则不能实例化Handler;
  5. 应用程序具有pipe理应用程序中活动的生命周期的能力。它具有“注册活动生命周期callback”的方法,但是单例没有能力。

同时考虑:

  • 在类中有单例对象作为静态实例。
  • 具有一个通用的类(Context),它返回应用程序中所有singelton对象的单例实例,其优点是Context中的方法名将是有意义的,例如:context.getLoggedinUser()而不是User.getInstance()。

此外,我build议您扩展您的上下文不仅包括访问单例对象,但需要全局访问一些function,例如:context.logOffUser(),context.readSavedData()等可能重命名的上下文那么门面就有意义了。

他们实际上是一样的。 我可以看到一个区别。 使用Application类,您可以在Application.onCreate()中初始化您的variables并在Application.onTerminate()中销毁它们。 与单身你必须依靠虚拟机初始化和摧毁静态。

我的2美分:

我注意到当我的活动被破坏时,一些单身/静态字段被重置。 我在一些低端的2.3设备上注意到了这一点。

我的情况非常简单:我只是拥有一个私人的“init_done”和一个从activity.onCreate()调用的静态方法“init”。 我注意到init方法在重新创build活动时重新执行。

虽然我无法certificate我的肯定,但是可能与单独/单独创build/使用时相关。 当活动被破坏/回收时,似乎只有这个活动所涉及的所有类别都被回收了。

我把我的单例实例移到了一个Application类的子类中。 我从应用程序实例访问它们。 从此,再也没有注意到这个问题。

我希望这可以帮助别人。

我的活动调用完成()(这不会立即完成,但最终会),并调用Google街景浏览器。 当我在Eclipse上进行debugging时,当调用Street Viewer时,与应用程序的连接中断,我将其理解为正在closures的(整个)应用程序,应该释放内存(因为完成的单个活动不应导致此行为) 。 不过,我可以通过onSaveInstanceState()在Bundle中保存状态,并在堆栈中下一个活动的onCreate()方法中恢复它。 通过使用静态单例或子类化应用程序我面对应用程序closures和丢失状态(除非我将它保存在一个包中)。 所以从我的经验来看,他们在国家保护方面是一样的。 我注意到连接丢失在Android 4.1.2和4.2.2,但不是在4.0.7或3.2.4,据我的理解,这表明内存恢复机制已经改变了一些点。

从谚语的马嘴里

在开发应用程序时,您可能会发现需要在整个应用程序中全局共享数据,上下文或服务。 例如,如果您的应用程序具有会话数据(例如当前login的用户),则可能需要公开此信息。 在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 static void onCreate(){ super.onCreate() sInstance = this; } }