1. 应用程序数据。在应用程序运行时,在类的静态变量中存储应用程序数据是否不好?目前,我将数据存储在我的“Application”类的实例变量中。然后需要数据的类可以从“Application”中获取数据。
2. Context等。将Context(例如对Activity或Application的引用)存储在静态字段中是否是一种糟糕的做法?这可用于需要LayoutInflater或资源的类。目前,我将Context作为参数传递给需要它们的方法。
可以,没问题。 :)
静态字段。过度使用静态字段存在很多问题。不仅它们访问速度较慢,而且容易在 Android 中被销毁,通常需要在各个地方检查其引用或在 getter/setter 中填充 if (sSomeStatic == null) { return new SomeStatic()}
。存储指向一个名为(例如)ApplicationData 的类的静态引用以存储一些值是可以的,我们每隔一段时间确实需要一些全局变量,但很容易滥用,所以每当我检查新的 Android 开发者源代码时,我都会皱眉。
是的,在单例模式中存储您的 Application 实例并使用它,但不要将 200 个静态字段添加到您的 Application 实现中,只因为您可以这样做 YOURAPP.getInstance().SomeLazyValueYouAddedHere();
那是不好的。它会导致不良的实践,并且比访问硬引用的好设计要慢。
我可以继续说下去,但有很多 StackOverflow 讨论(有些激烈!)关于此。如果您在这里,我假设您正在寻求经验;在不同的项目中我已经做了几年的 Android 开发,我的经验始终是,静态的越少,越好。
现在是上下文...哦,上下文。永远不要将 Context 存储为硬引用,否则会泄漏内存。Activity 有 View 和许多其他东西的引用。如果您存储了 Context,则存储了 Activity,从那里开始出问题。学习在上下文中传递,尽可能使用 Application 上下文,如果需要传递,请有非常好的理由。大多数情况下,应用程序上下文已足够获取资源、字符串等。
如果您能负担得起一本 Android 书籍,就请购买BNR的这本。即使 Android 偶尔发布新的 SDK,概念仍然完全有效,作者使用的模式是处理活动、上下文、片段等的正确方式。
更新:您的应用程序应如下所示:
public class YourApp extends Application {
private static YourApp sInstance;
public YourApp() {
super();
sInstance = this;
}
public static YourApp getInstance() {
return sInstance;
}
}
在这种情况下,是的,您将获得对同一应用程序上下文的相同静态引用。
ApplicationClass.getInstance()
ه’ŒanActivity.getApplication()
(وˆ‘ç›®ه‰چو£هœ¨ن½؟用çڑ„)وœ‰ن»€ن¹ˆن¸چهگŒهگ—ï¼ں - PurkkaKoodari
Application
实例存储为静态引用是完全可以的。 - Tobias