java 进程共享数据_SharedPreferences多进程共享数据爬坑之旅

SharedPreferences ContentProvider Application

1. 遇到的问题

05-23 16:11:15.871: E/AndroidRuntime(21899): java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.SharedPreferences android.content.Context.getSharedPreferences(java.lang.String, int)' on a null object reference

05-23 16:11:15.871: E/AndroidRuntime(21899): at com.csmijo.test.utils.SharedPrefUtil.getSharedPreferences(SharedPrefUtil.java:13)

05-23 16:11:15.871: E/AndroidRuntime(21899): at com.csmijo.test.utils.SharedPrefUtil.getValue(SharedPrefUtil.java:51)

写好的一个 SDK 在第三方集成使用时，发现了这样的bug。于是根据 trace 信息，查看代码发现封装类在操作 SharedPreferences 时并没有什么问题，但是为什么会出现 NullPointerException 的问题呢？？

于是沟通拿到测试 Apk 后，安装发现是因为 第三方APP在打开某个Activity时启动了新的进程，所以导致了上述的问题。

找到原因后，于是开始尝试解决。。。

2. 通过 SharedPreferences 实现多进程间的数据共享(不推荐)

因为之前的数据都是使用 SharedPreferences 进行存储，如果改用其他多进程的通信方式感觉改动的地方比较大，所以优先尝试使用修改 SharedPreferences 的方式进行。

通过查看 API 文档发现，在 API Level > 11 即 Android 3.0 可以通过 Context.MODE_MULTI_PROCESS 属性来实现多进程间的数据共享.

但是在 API 23 时该属性被废弃。官方文档中明确写明 This class does not support use across multiple processes. 即 SharedPreferences 不适用于多进程间共享数据，推荐使用 ContentProvider。

3. 更新(使用 ContentProvider 的一次尝试 )

之前自己尝试了一下使用 contentProvider + SharedPreferences 来实现，没有成功，还是水平太次啊。最近在逛掘金酱的时候发现很早之前就有人实现了这样的方式，这里贴一下我找的的博客及代码，以防误人子弟啊。

以下是我尝试失败的例子，这里记录一下。

3. 使用 ContentProvider 的一次尝试 (失败)

平时自定义 ContentProvider 时，都是和 Sqlite 配合使用，将数据存储在数据库中，于是突发奇想，能不能把 ContentProvider 和 SharedPreferences 联合使用，使用 SharedPreferences 来存储数据。

于是直接上手鼓捣了半天，最后在自定义 ContentProvider 的 query() 方法面前败下阵来。

这是因为 public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) 方法需要返回一个 Cursor 的对象。查看代码后发现 Cursor 是一个接口，于是想着实现一个自定义的接口即可。

结果一阵敲码完成之后，run一下，结果呵呵了，提示如下的bug：

Caused by: java.lang.ClassCastException: android.content.ContentResolver$CursorWrapperInner cannot be cast to csmijo.com.test.MyCursor

at csmijo.com.test.SharedPrefUtil.getValue(SharedPrefUtil.java:78)

于是开始找原因，发现在使用ContentResolver.query() 方法时发生了如下的调用：

contentSolver_query.png

而正常情况下返回 ContentResolver$CursorWrapperInner 类的一个实例，而这个类是一个 private final class，所以没有办法继承。该类的继承结构如下图所示：

ContentResolver_query_cursor.png

所以我们直接实现 Cursor 接口作为返回值的做法是错误的。

4. 使用 ContentProvider 完成多进程间数据共享

尝试之后失败，但是问题还是要解决的嘛，所以就乖乖使用 ContentProvider 和 Sqlite 的方案进行问题解决。 具体的 ContentProvider 使用方法可以参考 官方教程。

在调试 ContentProvider 的时候，使用了 Stetho， 它可以在 Chrome 中非常方便的查看数据库中的资源，还支持 SQL 查询，特别的方便，推荐一下。

5. 多进程 Application 的多次加载

通过上面的 ContentProvider 解决了 SharedPreferences 共享数据的问题，自己调试了一下，发现 Application 的初始化又有个坑。

因为使用了多进程，每个进程相当于一个单独的应用程序，所以每个进程启动时都会调用一次 Applicaiton.onCreate() 方法，这样就导致了我在 onCreate() 方法中进行的操作执行多遍。

解决方案是根据进程来分别进行初始化。

获取当前运行进程的名称：

方法一

public static String getProcessName(Context cxt, int pid) {

ActivityManager am = (ActivityManager) cxt.getSystemService(Context.ACTIVITY_SERVICE);

List runningApps = am.getRunningAppProcesses();

if (runningApps == null) {

return null;

}

for (RunningAppProcessInfo procInfo : runningApps) {

if (procInfo.pid == pid) {

return procInfo.processName;

}

}

return null;

}

这是目前网上主流的方法，但是没有方法二效率高

方法二

public static String getCurrentProcessName() {

FileInputStream in = null;

try {

String fn = "/proc/self/cmdline";

in = new FileInputStream(fn);

byte[] buffer = new byte[256];

int len = 0;

int b;

while ((b = in.read()) > 0 && len < buffer.length) {

buffer[len++] = (byte) b;

}

if (len > 0) {

return new String(buffer, 0, len, "UTF-8");

}

} catch (Throwable e) {

} finally {

try {

if (null != in) {

in.close();

}

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

return null;

}

6. 总结

以上就是这次多进程数据共享爬坑的过程，希望能够提供一些借鉴作用。