我有自定义的sharedpreferences类,其中有很多getter和setter方法。我正在为共享偏好设置值,这是我在不同的类中访问。所以我的问题是当我在任何类中访问自定义共享首选项时,我首先创建它的对象。
UserSession session=new UserSession(getactivity,"customSharedpreferences");
每次我需要从共享偏好中获取价值并思考使其成为静态类时,我觉得创建对象的性能是明智的,但我不确定哪种赌注是基于性能的。
访问而不创建类UserSession.getEmailAddress();
的对象或先创建对象,然后session.getEmailAddress();
public class UserSession {
private SharedPreferences sharedPreferences;
private SharedPreferences.Editor editor;
public static final String TAG="USER SESSION######";
public UserSession(Context context,String preferenceFileName ){
sharedPreferences = context.getApplicationContext().getSharedPreferences(preferenceFileName, Context.MODE_PRIVATE);
}
// GETTER SETTER METHOD FOR SHARED PREFERENCES
}
答案 0 :(得分:1)
答案取决于您希望UserSession填充的角色。您是否希望UserSession成为SharedPreferences的简单包装器,还是希望它成为会话数据的单一事实来源?
如果你想让它只是作为一个包装器,那么我会把它变成一个静态类,它可以不存储上下文。只需将上下文和共享首选项传递给需要它的每个方法。
public String getUserName(Context ctx, String sharedPrefFileName) {...do your tedious shared preference editing here...}
如果您希望UserSession存储当前“会话”的状态,那么我建议将其设为单例。此单例可以存储共享首选项 filename 。它也可以存储对上下文的引用,但是你必须要小心如何构造这个单例。
您要小心不要泄露上下文引用。我不知道UserSession
的生命周期,但在将上下文传递给它时应该小心。
有几种不同的方法可以在单例中“存储”上下文。 Android documentation表示您可以创建一个自定义的Application类,它通过静态公共引用或...(来自android文档)公开自己
在大多数情况下,静态单例可以提供相同的效果 功能更加模块化。如果你的单身人士需要全球化 上下文(例如注册广播接收器),包括 Context.getApplicationContext()作为调用时的Context参数 你的单身人士的getInstance()方法。
我假设UserSession调用getSharedPreferences来获取对SharedPreferences的引用。此方法将始终返回相同的实例(每个文件名),因此您不必担心调用它,因为它不会创建新实例。
可以使单例我的自定义sharedpreferences类具有 大约100个getter和setter方法
您可以随时将这些方法分解为更小的模块化类,但不会改变应用程序的性能。单身人士的方法数量不应影响你的表现。
答案 1 :(得分:0)
如果您需要经常访问该对象,我认为使用单例模式非常有用。因为,如果每次都创建一个新对象,将经常调用垃圾收集器,应该避免使用。 Quoting form android documentation,
对象创建永远不会自由。具有用于临时对象的每线程分配池的分代垃圾收集器可以进行分配 更便宜,但分配内存总是比不贵 分配内存。
当您在应用中分配更多对象时,您将强制定期 垃圾收集,创造一点点"打嗝"在用户体验方面。 Android 2.3中引入的并发垃圾收集器有所帮助,但是 应始终避免不必要的工作。
答案 2 :(得分:-1)
直接从共享首选项中获取价值而不是创建类更好。但是如果您仍然希望创建一个类以便在各个活动中更容易使用,那么最好使用SQLite并创建DatabaseHelper类并使用类似的getter-setter方法。这比您的自定义共享首选项实现更有效
Here's关于SQLite的精彩教程