Question

在Android应用程序的开发中，我已经找到了一些实用程序类型的方法，我将它放入静态类中。所有这些方法都用于多个活动，并且大多数活动不需要来自调用活动的任何信息。

但是，我现在有一些方法需要Activity的Context和一个需要Activity本身的方法。让我举例说明其中一些：

getDeviceNaturalOrientation（） - 使用Activity getWindow（）。getWindowManager（）。getDefaultDisplay（）来访问显示旋转，宽度和高度以确定设备自然定位。
getDeviceOrientation（） - 与上面类似，但要获得最新信息取向
createFile（） - 使用Context来访问某些资源（字符串）和创建并展示一些Toast

现在，关于这个Utils类的重要问题是：

到目前为止，每个函数都接受一个Context参数，我从我所使用的Activity中传递，但是可以在Utils类中创建静态Context或Activity变量并在每个Activity的开头设置它（喜欢在onCreate）？此变量将用于需要Context或Activity实例的任何函数。
假设不建议使用上述内容，是否可以将Activity参数传递给方法，或者是否有理由仅将Activity作为Context传递？我上面用于设备方向函数的方法特定于Activity对象，而不是Context，因此要么作为Activity传递，要么作为Context传递并转换为Activity（后者听起来像一个可怕的想法）。

另外，我非常乐观地认为这个Util类可能不适合需要Context / Activity的这些方法，所以我欢迎那些仍然会阻止在每个activity类中复制这些方法的替代方法使用它们。

Answer 1

1）到上下文的静态链接可能会导致内存泄漏。这意味着对Activity的引用将在静态变量中保留，即使在它被销毁之后，因此活动的所有内存及其所有视图都将保持有效并且不被gc清除。你可以这样做，但是你必须小心在完成后将变量清零。最好避免它。

2）将活动作为活动传递有点尴尬，但没有技术理由不这样做。那时我们正在争论代码清洁/可维护性。有时，非清洁解决方案更容易。当然，在上面的情况中，我宁愿将orientation / display / Resources对象传递给函数，而不是传递整个上下文或创建特殊的访问器。

Answer 2

我认为从Activity

调用时，以下设计应该没问题

MyUtility utility=new MyUtility();
utility.getDeviceNaturalOrientation(this);
utility.getFile(this);

你可以定义这些功能，如

public int getDeviceNaturalOrientation(Activity activity){
 //code
return some_oreientation
}

并且喜欢这个

public File getFile(Context context){
 //code
//return file handler
}

Activity是Context的子类，因此您甚至可以将设计更改为以下

MyUtility utility=new MyUtility(this); //this refer to Activity
utility.getDeviceNaturalOrientation();
utility.getFile();

只要您通过活动就可以了，但如果您从活动中做到以下操作，您将从第一次方法调用中收到错误

MyUtility utility=new MyUtility(getApplicationContext());
utility.getDeviceNaturalOrientation(); //will throw exception
utility.getFile();

并且，是的，首先想法不是推荐的方式。

Answer 3

我建议您发送WeakReference of your Activity或getApplicationContext()（对于那些可以使用它的作品）并且不要使用static method，因为会导致记忆泄漏即可。 Read Developer blog也是