在过去，我已经将Application子类化，以维护应用程序的活动数据库连接。但是，根据UI线程中的this SO answer Application运行，这让我觉得我绝对不应该将它用于数据库访问。此外，根据Xamarin Application docs（和Android专有的）：
通常不需要子类Application。在大多数情况下，静态单例可以以更模块化的方式提供相同的功能。如果你的单例需要一个全局上下文（例如注册广播接收器），那么检索它的函数可以被赋予
Context，它在第一次构造单例时在内部使用Context.ApplicationContext。
我认为我理解Context可以用来维护对应用程序资源的某种静态访问，但是文档中没有示例，我之前没有遇到过这种情况。是否有人能够解释上述说明并说明他们如何使用Context来维护应用程序资源（除非我完全忽略了这一点）？链接或直接举例将不胜感激。
答案 0 :(得分：-1)
我相信我找到了我正在寻找的机器人答案。
Dave Smith提供了simple example的“静态单身人士”，如上文所述：
this public class CustomManager {
private static CustomManager sInstance;
public static CustomManager getInstance(Context context) {
if (sInstance == null) {
//Always pass in the Application Context
sInstance = new CustomManager(context.getApplicationContext());
}
return sInstance;
}
private Context mContext;
private CustomManager(Context context) {
mContext = context;
}
}
本身对Context的寿命没有贡献 - 它的存在仅仅是由于静态单身本身的本质。 CustomManager（Xamarin Context）提供的context.getApplicationContext()只是一个访问应用程序Context.ApplicationContext的方法，如果单身人士需要它。
话虽如此，正如this SO question and its top two answers详细阐述的那样，真正的问题并非如此，但您希望全局应用程序数据如何成为单例 - 作为框架提供的扩展{{1单身，或作为你创建的另外一个单独的单身，可以使用或不使用前者。
就我而言，我认为我满足于简单地继承Context。直观地将应用程序数据存储在Application类的某些变体中更有意义。此外，我对一般的单身人士有一定的OOP疑虑，因此我觉得使用已经存在的单身人士比制作自己的人更安全。这个单例是由框架管理的，所以虽然这并不能保证安全性不受基本归结为全局变量（boo hiss）的典型困境的影响，但至少它比滚动自己更安全。
P.S。 - re：使用在UI线程中运行的Application，似乎使用静态单例并没有给我任何额外的好处 - 再次，因为无论如何都使用Application。我想我可能会遵循提供的建议here并利用Application来处理大量的操作。