通过ContentProvider多进程共享SharedPreferences数据

「爱情、让人受尽委屈。」 2022-05-28 23:09 401阅读 0赞

# 通过ContentProvider多进程共享SharedPreferences数据 #

[ ][Link 1]

[十个雨点][Link 1]

2017.01.19 09:34\* 字数 1953 阅读 4997 评论 12 喜欢 21 赞赏 1

转载注明出处：[简书-十个雨点][Link 1]

开发一个多进程应用的时候，我们往往无法避免在多个进程之间共享数据。  
多进程共享数据的方法有很多种，在Android中常用的有：SharedPreferences(多进程模式)、广播、Socket、ContentProvider、Messenger、AIDL等。这些方法适用于不同的使用场景，又有各自的局限性。

本文即将介绍的是通过ContentProvider，结合SharedPreferences(以下简称SP)实现的进程间共享设置项的功能。这种方式主要适用于以下场景：在一个进程中进行一些设置，而需要在另一个进程实时读取设置，并根据这些设置来执行功能。

### 1.SharedPreferences在多进程共享下的局限 ###

有些同学可能会觉得奇怪：明明上面才说了SP(多进程模式)也是多进程共享数据的方法，为什么还需要通过ContentProvider来做呢。答案很简单，***因为SP其实并不能保证多进程间同步***，下图是关于MODE\_MULTI\_PROCESS的注释，我就不全文翻译了。

![700][]

MODE\_MULTI\_PROCESS模式的注释

我们都知道，SP其实是将key-value对保存在手机的data/data/you.package.name/shared\_prefs/目录下的文件中。为了减少IO造成的性能损失，SP使用了缓存的机制，会先把数据保存在内存中，在读取的时候直接从内存中读取，而写的时候才会保存到文件。也就是说普通SP是一次读取，多次写入的工作模式。所以如果多个进程中都使用了普通的SP，分别进行保存就会导致相互覆盖。而设置了MODE\_MULTI\_PROCESS之后，在多进程使用的时候，会在检测到文件变化的时候重新加载文件到内存中，这样虽然损失了一部分性能，但是却***部分***实现了多进程间同步。

为什么说是"部分"实现了多进程间同步呢？因为在频繁进行SP操作的时候，就还是会出现相互覆盖的问题。我初步估计是因为两个进程同时进行了文件的写操作，带着这个猜测我阅读了源码。

先看看对MODE\_MULTI\_PROCESS是如何处理的  
***ContextImpl的getSharedPreferences方法：***

@Override
    public SharedPreferences getSharedPreferences(File file, int mode) {
        checkMode(mode);
        SharedPreferencesImpl sp;
        synchronized (ContextImpl.class) {
            final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
            sp = cache.get(file);
            if (sp == null) {
                sp = new SharedPreferencesImpl(file, mode);
                cache.put(file, sp);
                return sp;
            }
        }
        if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
            getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
            // If somebody else (some other process) changed the prefs
            // file behind our back, we reload it.  This has been the
            // historical (if undocumented) behavior.
            sp.startReloadIfChangedUnexpectedly();
        }
        return sp;
    }

***其中SharedPreferencesImpl的startReloadIfChangedUnexpectedly方法：***

void startReloadIfChangedUnexpectedly() {
            synchronized (this) {
                // TODO: wait for any pending writes to disk?
                if (!hasFileChangedUnexpectedly()) {
                    return;
                }
                startLoadFromDisk();
            }
        }

可见遇到MODE\_MULTI\_PROCESS的时候，会强制让SP进行一次读取操作，从而保证数据是最新的。因此如果你在外部保存了一份SP的对象，反而会导致享受不到MODE\_MULTI\_PROCESS带来的同步效果了，而且从源码中可以看出ContextImpl中是对SP对象做了缓存的，每次重新getSharedPreferences并不会造成太大的性能损失。  
从getSharedPreferences的代码中看不出会造成多进程互相覆盖的问题，那我们看看Editor的commit方法，  
***EditorImpl的commit和相关方法：***

final class SharedPreferencesImpl implements SharedPreferences {
        ...
        public final class EditorImpl implements Editor {
            ...
            private MemoryCommitResult commitToMemory() {
                ...
            }
            public boolean commit() {
                MemoryCommitResult mcr = commitToMemory();
                SharedPreferencesImpl.this.enqueueDiskWrite(
                    mcr, null /* sync write on this thread okay */);
                try {
                    mcr.writtenToDiskLatch.await();
                } catch (InterruptedException e) {
                    return false;
                }
                notifyListeners(mcr);
                return mcr.writeToDiskResult;
            }
        }
    
        private void enqueueDiskWrite(final MemoryCommitResult mcr,
                                      final Runnable postWriteRunnable) {
            final Runnable writeToDiskRunnable = new Runnable() {
                    public void run() {
                        synchronized (mWritingToDiskLock) {
                            writeToFile(mcr);
                        }
                        synchronized (SharedPreferencesImpl.this) {
                            mDiskWritesInFlight--;
                        }
                        if (postWriteRunnable != null) {
                            postWriteRunnable.run();
                        }
                    }
                };
    
            final boolean isFromSyncCommit = (postWriteRunnable == null);
    
            // Typical #commit() path with fewer allocations, doing a write on
            // the current thread.
            if (isFromSyncCommit) {
                boolean wasEmpty = false;
                synchronized (SharedPreferencesImpl.this) {
                    wasEmpty = mDiskWritesInFlight == 1;
                }
                if (wasEmpty) {
                    writeToDiskRunnable.run();
                    return;
                }
            }
    
            QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
        }
    }

可见每次会先保存到内存，然后再写入文件，而写文件的操作又是在子线程中依次按顺序执行的(上面代码最后一行)。  
那么结论就出来了：

***当多个进程同时而又高频的调用commit方法时，就会导致文件被反复覆盖写入，而并没有被及时读取，所以造成进程间数据的不同步***

### 2.通过ContentProvider进行实现多进程共享SharedPreferences ###

既然SP有多进程不同步的隐患，那么我们怎么要怎么解决呢？  
多进程同步的方法中，ContentProvider、Messenger、AIDL等方式都是基于Binder实现的，所以本质上并没有太大差别，而ContentProvider又是Android提倡的数据提供组件，所以我选择它来实现多进程SP操作。

***具体怎么做呢？***  
SP本身的调用方式已经提供了较高的存取便利性，所以我们只要封装出一个SPHelper，去调用SPContentProvider，SPContentProvider用于保证跨进程的同步性，其内部再用SPHelperImpl来做真正的实现即可。

![429][]

对SP的封装结构

那怎么用SPContentProvider来实现数据存取操作呢？实现ContentProvider需要实现几个方法，这些方法分别对应了ContentResolver中的同名方法，我们可以通过ContentResolver来调用这些方法，达到传递数据和进行命令解析的目的。

![700 1][]

ContentProvider需要实现的方法

SP中的方法有sava，get，remove，clean，getAll这几种。那么我们可以用update或insert来实现save；用delete实现clean和remove，用getType或者query实现get和getAll。  
所以最终的调用方式如下如所示：

![700 2][]

SP调用getInt()的传递过程

下面看看代码中是如何处理的，还是以getInt()为例：

public class SPHelper {
        ...
    
        public static final String CONTENT="content://";
        public static final String AUTHORITY="com.pl.sphelper";
        public static final String SEPARATOR= "/";
        public static final String CONTENT_URI =CONTENT+AUTHORITY;
        public static final String TYPE_INT="int";
        public static final String NULL_STRING= "null";
    
        public static int getInt(String name, int defaultValue) {
            ContentResolver cr = context.getContentResolver();
            Uri uri = Uri.parse(CONTENT_URI + SEPARATOR + TYPE_INT + SEPARATOR + name);
            String rtn = cr.getType(uri);
            if (rtn == null || rtn.equals(NULL_STRING)) {
                return defaultValue;
            }
            return Integer.parseInt(rtn);
        }
        ...
    }
    
    public class SPContentProvider extends ContentProvider{
        ...
        public static final String SEPARATOR= "/";
    
        public String getType(Uri uri) {
            // 用这个来取数值
            String[] path= uri.getPath().split(SEPARATOR);
            String type=path[1];
            String key=path[2];
            return  ""+SPHelperImpl.get(getContext(),key,type);
        }
        ...
    }
    
    class SPHelperImpl {
        ...
    
        public static final String TYPE_INT="int";
    
        static String get(Context context, String name, String type) {
            if (type.equalsIgnoreCase(TYPE_STRING)) {
                return getString(context, name, null);
            } else if (type.equalsIgnoreCase(TYPE_BOOLEAN)) {
                return getBoolean(context, name, false);
            } else if (type.equalsIgnoreCase(TYPE_INT)) {
                return getInt(context, name, 0);
            } else if (type.equalsIgnoreCase(TYPE_LONG)) {
                return getLong(context, name, 0L);
            } else if (type.equalsIgnoreCase(TYPE_FLOAT)) {
                return getFloat(context, name, 0f);
            } else if (type.equalsIgnoreCase(TYPE_STRING_SET)) {
                return getString(context, name, null);
            }
            return null;
        }
    
        static int getInt(Context context, String name, int defaultValue) {
            SharedPreferences sp = getSP(context);
            if (sp == null) return defaultValue;
            return sp.getInt(name, defaultValue);
        }
        ...
    }

其中SPContentProvider必须在AndroidManifest中声明，并设置android:authorities="com.pl.sphelper"。

### 3.优化性能和内存 ###

本来以为做完上面的工作就算完了，但是在实际使用的过程中，发现一个问题，就是内存消耗比较大。tracking后发现是由于生成的SharedPreferences.Editor对象占用了大量内存，这是因为我的应用场景中，会频繁的将运行过程中的几个数据存储到SP中，所以导致大量生成Editor对象。但是实际上，很多保存的值是相同的，此时可以考虑使用缓存机制，而不用重复写入，代码如下：

private static SoftReference<Map<String, Object>> sCacheMap;
    
    private static Object getCachedValue(String name) {
        if (sCacheMap != null) {
            Map<String, Object> map = sCacheMap.get();
            if (map != null) {
                return map.get(name);
            }
        }
        return null;
    }
    
    private static void setValueToCached(String name, Object value) {
        Map<String, Object> map;
        if (sCacheMap == null) {
            map = new HashMap<>();
            sCacheMap = new SoftReference<Map<String, Object>>(map);
        } else {
            map = sCacheMap.get();
            if (map == null) {
                map = new HashMap<>();
                sCacheMap = new SoftReference<Map<String, Object>>(map);
            }
        }
        map.put(name, value);
    }
    synchronized static <T> void save(Context context, String name, T t) {
        SharedPreferences sp = getSP(context);
        if (sp == null) return;
    
        if (t.equals(getCachedValue(name))) {
            return;
        }
        SharedPreferences.Editor editor = sp.edit();
        if (t instanceof Boolean) {
            editor.putBoolean(name, (Boolean) t);
        }
        if (t instanceof String) {
            editor.putString(name, (String) t);
        }
        if (t instanceof Integer) {
            editor.putInt(name, (Integer) t);
        }
        if (t instanceof Long) {
            editor.putLong(name, (Long) t);
        }
        if (t instanceof Float) {
            editor.putFloat(name, (Float) t);
        }
        editor.commit();
        setValueToCached(name, t);
    }

实测内存使用量下降80%（这么大比例的原因有一部分是因为我一原先消耗的内存太多了），改进效果还是比较明显的。

### 4.还没有完，SPHelper会造成多大的性能损失呢？ ###

既然是多进程间的交互，肯定会造成一定的性能损失，那么具体是多少呢？我用以下代码测试了一下：

@RunWith(AndroidJUnit4.class)
    public class ExampleInstrumentedTest {
        @Test
        public void useAppContext() throws Exception {
            Context appContext = InstrumentationRegistry.getTargetContext();
            SPHelper.init((Application) appContext.getApplicationContext());
            Random random = new Random();
            long start = System.currentTimeMillis();
            for (int i = 0; i < 100; i++) {
                SPHelper.save("key" + random.nextInt(200), i);
            }
            long end = System.currentTimeMillis();
            Log.e("ExampleInstrumentedTest", "SPHelper takes " + (end - start) + "millis");
    
            start = System.currentTimeMillis();
            for (int i = 0; i < 100; i++) {
                SharedPreferences sp = appContext.getSharedPreferences("text", Context.MODE_PRIVATE);
                SharedPreferences.Editor editor = sp.edit();
                editor.putInt("key" + random.nextInt(200), i);
                editor.commit();
            }
            end = System.currentTimeMillis();
            Log.e("ExampleInstrumentedTest", "SharedPreferences takes " + (end - start) + "millis");
        }
    }

代码中是SPHelper和系统默认的SharedPreferences ，进行了100次的SP储存操作，输出消耗的时间（单位：毫秒）。

当调用方和SPContentProvider在***相同***的进程中时，性能如下：

<table> 
 <thead> 
  <tr> 
   <th style="text-align:center;">调用方式</th> 
   <th style="text-align:center;">第一次</th> 
   <th style="text-align:center;">第二次</th> 
   <th style="text-align:center;">第三次</th> 
   <th style="text-align:center;">第四次</th> 
   <th style="text-align:center;">第五次</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:center;">SPHelper</td> 
   <td style="text-align:center;">966</td> 
   <td style="text-align:center;">903</td> 
   <td style="text-align:center;">944</td> 
   <td style="text-align:center;">987</td> 
   <td style="text-align:center;">951</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;">SharedPreferences</td> 
   <td style="text-align:center;">850</td> 
   <td style="text-align:center;">836</td> 
   <td style="text-align:center;">904</td> 
   <td style="text-align:center;">844</td> 
   <td style="text-align:center;">838</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;">性能差距</td> 
   <td style="text-align:center;"><strong>0.14</strong></td> 
   <td style="text-align:center;"><strong>0.08</strong></td> 
   <td style="text-align:center;"><strong>0.04</strong></td> 
   <td style="text-align:center;"><strong>0.17</strong></td> 
   <td style="text-align:center;"><strong>0.13</strong></td> 
  </tr> 
 </tbody> 
</table>

***可见性能损失并不大，大概10%左右***。这是因为Binder的工作方式，当在两者同一个进程中是，只是相当于函数调用，不会引起太大的消耗，具体的可以阅读Binder源码。所以这10%的差距基本上都是由于对数据的包装和解包装所产生的。

那么进程间通信的消耗到底有多大呢，下表是调用方和SPContentProvider在***不同***的进程中时的结果：

<table> 
 <thead> 
  <tr> 
   <th style="text-align:center;">调用方式</th> 
   <th style="text-align:center;">第一次</th> 
   <th style="text-align:center;">第二次</th> 
   <th style="text-align:center;">第三次</th> 
   <th style="text-align:center;">第四次</th> 
   <th style="text-align:center;">第五次</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:center;">SPHelper</td> 
   <td style="text-align:center;">1374</td> 
   <td style="text-align:center;">1283</td> 
   <td style="text-align:center;">1366</td> 
   <td style="text-align:center;">1286</td> 
   <td style="text-align:center;">1296</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;">SharedPreferences</td> 
   <td style="text-align:center;">829</td> 
   <td style="text-align:center;">850</td> 
   <td style="text-align:center;">861</td> 
   <td style="text-align:center;">886</td> 
   <td style="text-align:center;">869</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;">性能差距</td> 
   <td style="text-align:center;"><strong>0.66</strong></td> 
   <td style="text-align:center;"><strong>0.51</strong></td> 
   <td style="text-align:center;"><strong>0.59</strong></td> 
   <td style="text-align:center;"><strong>0.45</strong></td> 
   <td style="text-align:center;"><strong>0.49</strong></td> 
  </tr> 
 </tbody> 
</table>

***可见通过三次函数就行转发调用，再加上进程间通信，造成的性能损失还是比较可观的，达到50%以上。***

###### 需要注意的是，如果SPContentProvider所在的进程只有这个ContentProvider而没有其他组件的话，第一次调用时才会启动进程，所以会耗费大约50ms以上的时间，而且调用完以后一段时间，这个进程就会自动消耗，所以使用的时候，最好把SPContentProvider放到最常用SP的进程中，这样才能保证性能消耗最小。 ######

### 5.源码和Demo ###

源码，demo和测试用例都在Github上：[SPHelper][]  
如果对你有帮助的话，可以给我star！

[Link 1]: https://www.jianshu.com/u/28ea7fb50a09
[700]: /images/20220529/efdc96d2f9674f4c9a54cc9e4071a48e.png
[429]: /images/20220529/19ba7a019ca246369e5e9af8b0584edb.png
[700 1]: /images/20220529/eb1326159f924df49d76e8c4a95cd3d3.png
[700 2]: /images/20220529/d8751c778bfd4859b0042843c4e16a64.png
[SPHelper]: https://link.jianshu.com?t=https://github.com/l465659833/SPHelper