SharedPreferences 的 MODE_MULTI_PROCESS 不起作用 [英] MODE_MULTI_PROCESS for SharedPreferences isn't working

查看:29
本文介绍了SharedPreferences 的 MODE_MULTI_PROCESS 不起作用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 SyncAdapter 在独立于主应用程序进程的自己的进程上运行.

I have a SyncAdapter running on its own process separately from the main app process.

我在我的 SharedPreferences 周围使用了一个静态包装类,它在进程负载(应用程序的 onCreate)上创建一个静态对象,如下所示:

I'm using a static wrapper class around my SharedPreferences that creates a static object on process load (Application's onCreate) like so:

myPrefs = context.getSharedPreferences(MY_FILE_NAME, Context.MODE_MULTI_PROCESS | Context.MODE_PRIVATE);

包装器具有 get 和 set 方法,如下所示:

The wrapper has get and set methods, like so:

public static String getSomeString() {
    return myPrefs.getString(SOME_KEY, null);
}

public static void setSomeString(String str) {
    myPrefs.edit().putString(SOME_KEY, str).commit();
}

SyncAdapter 和应用程序都使用这个包装类来编辑和获取首选项,这有时有效,但很多时候我看到 SyncAdapter 变旧/缺少首选项在访问首选项时,主应用程序可以正确查看最近的更改.

Both SyncAdapter and app uses this wrapper class to edit and get from the prefs, this works sometimes but a lot of times I see the SyncAdapter getting old/missing prefs on accesses to the prefs, while the main app sees the recent changes properly.

根据文档,我认为 MODE_MULTI_PROCESS 标志应该像我期望的那样工作,允许两个进程看到最新的更改,但它不起作用.

According to the docs I think the MODE_MULTI_PROCESS flag should work as I expect it to, allowing both processes to see latest changes, but it doesn't work.

更新:

根据 x90 的建议,我尝试避免使用静态 SharedPreferences 对象,而是在每个 get/set 上调用 getSharedPreferences方法.这导致了一个新问题,即 prefs 文件在多进程同时访问时被删除 (!!!).即我在 logcat 中看到:

Per x90's suggestion, I've tried refraining from using a static SharedPreferences object and instead calling getSharedPreferences on each get/set method. This caused a new issue, where the prefs file gets deleted (!!!) on multi-process simultaneous access. i.e. I see in the logcat:

(process 1): getName => "Name"
(process 2): getName => null
(process 1): getName => null

从那时起,所有保存在 SharedPreferences 对象上的首选项都被删除了.

and from that point all the prefs saved on the SharedPreferences object were deleted.

这可能是我在日志中看到的另一个警告的结果:

This is probably a result of another warning I see in the log:

W/FileUtils(21552): Failed to chmod(/data/data/com.my_company/shared_prefs/prefs_filename.xml): libcore.io.ErrnoException: chmod failed: ENOENT (No such file or directory)

P.S 这不是一个确定性问题,我在发生崩溃后看到了上面的日志,但还无法在同一设备上重新创建,直到现在它似乎还没有在其他设备上发生.

P.S this is not a deterministic issue, I saw the above logs after a crash happened, but couldn't recreate yet on the same device, and until now it didn't seem to happen on other devices.

另一个更新:

我已经为此提交了一个错误报告,在编写了一个小测试方法以确认这确实是一个 Android 问题后,将其标记为 https://code.google.com/p/android/issues/detail?id=66625

I've filed a bug report on this, after writing a small testing method to confirm this is indeed an Android issue, star it at https://code.google.com/p/android/issues/detail?id=66625

推荐答案

遇到了完全相同的问题,我的解决方案是为 SharedPreferences 编写基于 ContentProvider 的替换.它可以 100% 多进程运行.

Had exactly the same problem and my solution was to write a ContentProvider based replacement for the SharedPreferences. It works 100% multiprocess.

我把它变成了我们所有人的图书馆.结果如下:https://github.com/grandcentrix/tray

I made it a library for all of us. Here is the result: https://github.com/grandcentrix/tray

这篇关于SharedPreferences 的 MODE_MULTI_PROCESS 不起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆