你最了解的 SharedPreference 和 ContentProvider 知多少?

在技术学习的道路上,往往最常见、用的最多地方,却有着容易忽略的技术细节。某个时间点蓦然回首,才发现最应该了解和掌握的技术基础,却由于缺少总结和记录、或者是因为常态思维固化缺少场景去思考,却显得那么陌生。

这篇文章将从作者自身的角度,去重新认识SharedPreference和ContentProvider这两个控件,并且以后也会在博客中有意识的记录类似的技术细节,防止这些基础的技术细节问题再次被遗忘和忽略。

SharedPreference和ContentProvider 细节知识加固

开始前,先来自述下作者对安卓系统这两个控件以往一般的认识。

SharedPreference

  • Android平台轻量级数据存储方式,底层系统封装了xml文件存储,基于key-value键值对数据。
  • SharedPreference提供了多种读取模式,可支持多进程读取,但是并不保证多进程并发读写安全。
  • 底层xml文件的初始化加载和Edit的apply方法是在子线程中进行。

ContentProvider

  • Android平台四大组件之一,数据共享控件,多用于多个进程间的数据传递。
  • 启动要优先于Application的OnCreat方法(查看Application初始化源码得之),尽量不要在App初次启动,(启动进程中)使用多个ContentProvider。
  • ContentProvider进程间IPC调用,用到了Binder获取文件描述符(FileDescriptor),通过文件描述符实现了高效的共享内存,使得进程间可传递大量数据(Binder接口有1M大小限制)。

一、SharedPreference 知识加固

SharedPreference文件保存在App私有目录中,可以在root手机或者调试模式run-as进入查看。

1、SharedPreference在多进程并发读取时,数据是不安全,那单进程多个线程并发情况呢?

平时遇到SharedPreference的数据读取问题,几乎都是多进程并发场景。多进程问题项目中,基本都是封装一层ContentProvider,将数据的读写共享到其他进程,来保证数据的正确性(当然也可以自定义SharedPref的实现类,去保证多进程并发逻辑)。

那单进程情况下SharedPref多线程的并发,却是容易忽略的地方(虽然很久之前,看过SharedPref的部分源码,但是还是忘了系统是有针对并发加锁的)。

其实简单分析下,平时没有遇到单线程的并发问题,也没有针对单线程的SharedPref读写做相关锁操作,理论上应该是线程安全的,那么我们深入源码看看系统到底是如何保证并发安全的~

从ContextImpl开始去获取一个SharedPref实例:


    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 || // 多进程模式去写,每次方法被调用时,会ReLoad一次xml文件。
                                                        // 这种机制在多进程并发严重时,数据是不安全的。
            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;
    }

系统中默认的SharedPref实现类是SharedPreferenceImpl,找到这个类相关读写方法,会看到系统已经针对并发加类锁机制。

    public Editor putLong(String key, long value) {
            synchronized (this) {
                mModified.put(key, value);
                return this;
            }
    }

    public long getLong(String key, long defValue) {
        synchronized (this) {
            awaitLoadedLocked();//注意:这里可能会wait
            Long v = (Long)mMap.get(key);
            return v != null ? v : defValue;
        }
    }

由此可见,虽然系统默认实现的SharedPreferencesImpl支持的多进程的去写模式,但并不保证数据安全。方法读取时,系统已经帮我们针对并发加类锁机制。

2、Xml文件的初始化加载和Edit的apply方法是在子线程中进行,那么是否意味着,我们可以不用考虑卡UI,去放心的加载大Shared文件和apply的频繁调用?

A、先来分析Xml的加载问题

还是从源码开始,上文中SharedPreferencesImpl的获取是从下面这段代码开始的:

    private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;//这里居然是静态的(为了读取速度)
    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;
            }
        }

    private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
      if (sSharedPrefsCache == null) {
        sSharedPrefsCache = new ArrayMap<>();
      }

      final String packageName = getPackageName();
      ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
        if (packagePrefs == null) {
        packagePrefs = new ArrayMap<>();
        sSharedPrefsCache.put(packageName, packagePrefs);
      }

    return packagePrefs;
    }

这里看到,系统为了快速读取已经加载到内存的SharedPref文件,会将读进来的文件保存在一个静态的Map中。这样空间换时间,虽然读取速度有了一定优化,但是读到内存的对象,不会被释放。

SharedPreferencesImpl构造器中会开始加载目标file,如下:

    private void startLoadFromDisk() {
        synchronized (this) {
            mLoaded = false;//是否加载完成的标记
        }
        new Thread("SharedPreferencesImpl-load") {
            public void run() {
                loadFromDisk();//   异步加载
            }
        }.start();
    }

这里主要看mloaded标记,用来标记文件是否已经加载完成,主要用在awaitLoadedLocked()方法中。

    private void awaitLoadedLocked() {
        ~~~
        ···
        while (!mLoaded) {
            try {
                wait();
            } catch (InterruptedException unused) {
            }
        }
    }

而awaitLoadedLocked()方法会在每次读和保存时调用,以为着在加载过程中,如果主线程有读写操作,依然会卡UI。

So,Xml的加载本身虽然不卡UI,但是读取操作会等待加载过程,依然有可能卡UI的。并且SharedPref尽量分类去保存,避免一次加载很大的无用文件到内存(可能引起GC,依然会卡UI),耗时又耗内存。

B、Apply方法是否会引起卡顿?

Show me the code

    public void apply() {
            final MemoryCommitResult mcr = commitToMemory();
            final Runnable awaitCommit = new Runnable() {
                    public void run() {
                        try {
                            mcr.writtenToDiskLatch.await();
                        } catch (InterruptedException ignored) {
                        }
                    }
                };

            QueuedWork.add(awaitCommit);//关键:新加一个任务到队列

            Runnable postWriteRunnable = new Runnable() {
                    public void run() {
                        awaitCommit.run();
                        QueuedWork.remove(awaitCommit);//当保存任务执行后会从队列中移除
                    }
                };

            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);//在线程中执行

            // Okay to notify the listeners before it's hit disk
            // because the listeners should always get the same
            // SharedPreferences instance back, which has the
            // changes reflected in memory.
            notifyListeners(mcr);
        }

    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);//单线程池中执行
    }

然后只到发现Activity的一段代码(思路及代码参考见这里

  private void handleStopActivity(IBinder token, boolean show, int configChanges, int seq) {
    ···
    // Make sure any pending writes are now committed.
    if (!r.isPreHoneycomb()) {
        QueuedWork.waitToFinish();
    }
    ···
  }

  public static void waitToFinish() {
    Runnable toFinish;
    while ((toFinish = sPendingWorkFinishers.poll()) != null) {
        toFinish.run();
    }
}

如果Activity在stop时,apply到QueuedWork中任务未执行完,就会在引起主线的等待造成卡顿。

所以,尽量不要频繁的调用apply,可以将多个提交合成一个apply,并且注意规避activity stop时候的SharedPref保存逻辑,避免卡顿。

二、ContentProvider 知识加固

1、ContentProvider为多进程数据的读取提供类机制,那么单进程下使用ContentProvider,能保证线程并发安全吗?

平时项目中常用到ContentProvider的地方见的最多的可能就是DB的和SharedPreference的数据封装类,由于Sqlite和SharedPref都是自身可以支持线程并发问题的,并没有注意到ContentProvider自身方法的并发特性。

提高ContentProvider,工程中更多的注意力放在类多进程的交互方式上,而忽略了自身方法调用的细节问题。

    ContentResolver resolver = content.getContentResolver();

通常,在使用ContentProvider时,会通过以上代码去获取ContentResolver引用,然后调用相关接口方法。

    private final ApplicationContentResolver mContentResolver;

   
    public ContentResolver getContentResolver() {
        return mContentResolver;
    }

同样,接口方法依然在ContextImpl中,可以看到ContentResolver的实现类是ApplicationContentResolver。
这里以query方法为例,深入分析下:

     public final Cursor query(final.Read Uri uri,
            String[] projection, String selection,
            String[] selectionArgs, String sortOrder,
            CancellationSignal cancellationSignal) {
        IContentProvider unstableProvider = acquireUnstableProvider(uri);//抽象方法,ApplicationContentResolver中实现
        if (unstableProvider == null) {
            return null;
        }
        IContentProvider stableProvider = null;
        Cursor qCursor = null;
        try {
            long startTime = SystemClock.uptimeMillis();

            ICancellationSignal remoteCancellationSignal = null;
            if (cancellationSignal != null) {
                cancellationSignal.throwIfCanceled();
                remoteCancellationSignal = unstableProvider.createCancellationSignal();
                cancellationSignal.setRemote(remoteCancellationSignal);
            }
            try {
                qCursor = unstableProvider.query(mPackageName, uri, projection,//缓存Binder处理
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            } catch (DeadObjectException e) {
                // The remote process has died...  but we only hold an unstable
                // reference though, so we might recover!!!  Let's try!!!!
                // This is exciting!!1!!1!!!!1
                unstableProviderDied(unstableProvider);//Provider进程死掉逻辑处理
                stableProvider = acquireProvider(uri);//抽象方法,ApplicationContentResolver中实现
                if (stableProvider == null) {
                    return null;
                }
                qCursor = stableProvider.query(mPackageName, uri, projection,//再次query
                        selection, selectionArgs, sortOrder, remoteCancellationSignal);
            }
            if (qCursor == null) {
                return null;
            }

            return wrapper;
        } catch (RemoteException e) {
            // Arbitrary and not worth documenting, as Activity
            // Manager will kill this process shortly anyway.
            return null;
        } finally {
           //···
        }
    }

主要跟踪下IContentProvider接口如何在acquireProvideracquireUnstableProvider中的实现,最终会委托给ActivityThread的acquireProvider方法,如下:

    public final IContentProvider acquireProvider(
        Context c, String auth, int userId, boolean stable) {
        final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable);//缓存中读取
        if (provider != null) {
        return provider;
        }

        IActivityManager.ContentProviderHolder holder = null;
        try {
        holder = ActivityManagerNative.getDefault().getContentProvider(
                getApplicationThread(), auth, userId, stable);//缓存没有读到,则跨进程AMS中读取
            } catch (RemoteException ex) {
        }
        if (holder == null) {
        Slog.e(TAG, "Failed to find provider info for " + auth);
        return null;
        }

        holder = installProvider(c, holder, holder.info,
            true /*noisy*/, holder.noReleaseNeeded, stable);//安装
        return holder.provider;
    }

方法的最后一个参数stable代表着ContentProvider能否可靠拿到一个进程存活的Provider。首先调用了acquireExistingProvider,去mProviderMap中获取一次接口。

    public final IContentProvider acquireExistingProvider(
            Context c, String auth, int userId, boolean stable) {
        synchronized (mProviderMap) {
            final ProviderKey key = new ProviderKey(auth, userId);
            final ProviderClientRecord pr = mProviderMap.get(key);//从缓存中先读取
            if (pr == null) {
                return null;
            }

            IContentProvider provider = pr.mProvider;
            IBinder jBinder = provider.asBinder();
            if (!jBinder.isBinderAlive()) {
                // The hosting process of the provider has died; we can't
                // use this one.
                Log.i(TAG, "Acquiring provider " + auth + " for user " + userId
                        + ": existing object's process dead");
                handleUnstableProviderDiedLocked(jBinder, true);
                return null;
            }

            // Only increment the ref count if we have one.  If we don't then the
            // provider is not reference counted and never needs to be released.
            ProviderRefCount prc = mProviderRefCountMap.get(jBinder);
            if (prc != null) {
                incProviderRefLocked(prc, stable);
            }
            return provider;
        }
    }

mProviderMap中,这个map的类型是ArrayMap,那么mProviderMap中的数据是哪里的呢?

查下mProvider的put方法,只有installProviderAuthoritiesLocked中调用,并且它是在又是在installProvider的调用的,那么重的分析下installProvider方法。

installProvider方法主要会在handleBindApplicationacquireProvider方法中调用,意味着:本进程和AMS获取到的Provider都会调用installProvider最后会放到mProviderMap缓存中,

    private IActivityManager.ContentProviderHolder installProvider(Context context,
            IActivityManager.ContentProviderHolder holder, ProviderInfo info,
            boolean noisy, boolean noReleaseNeeded, boolean stable) {
        ContentProvider localProvider = null;
        IContentProvider provider;
        if (holder == null || holder.provider == null) {
            //本地进程provider安装
            try {
                final java.lang.ClassLoader cl = c.getClassLoader();
                localProvider = (ContentProvider)cl.
                    loadClass(info.name).newInstance();
                provider = localProvider.getIContentProvider();
                if (provider == null) {
                    Slog.e(TAG, "Failed to instantiate class " +
                          info.name + " from sourceDir " +
                          info.applicationInfo.sourceDir);
                    return null;
                }

                localProvider.attachInfo(c, info);
            } catch (java.lang.Exception e) {

                return null;
            }
        } else {
            provider = holder.provider;
            //跨进程
        }

        IActivityManager.ContentProviderHolder retHolder;

        synchronized (mProviderMap) {
            //获取可跨进程的Binder对象
            IBinder jBinder = provider.asBinder();
            if (localProvider != null) {
                ComponentName cname = new ComponentName(info.packageName, info.name);
                ProviderClientRecord pr = mLocalProvidersByName.get(cname);
                if (pr != null) {

                    provider = pr.mProvider;
                } else {
                    holder = new IActivityManager.ContentProviderHolder(info);
                    holder.provider = provider;
                    holder.noReleaseNeeded = true;
                    pr = installProviderAuthoritiesLocked(provider, localProvider, holder);
                    mLocalProviders.put(jBinder, pr);
                    mLocalProvidersByName.put(cname, pr);
                }
                retHolder = pr.mHolder;
            } else {
                ProviderRefCount prc = mProviderRefCountMap.get(jBinder);
                if (prc != null) {
                    if (!noReleaseNeeded) {
                        incProviderRefLocked(prc, stable);
                        try {
                            ActivityManagerNative.getDefault().removeContentProvider(
                                    holder.connection, stable);
                        } catch (RemoteException e) {
                            //do nothing content provider object is dead any way
                        }
                    }
                } else {
                    ProviderClientRecord client = installProviderAuthoritiesLocked(
                            provider, localProvider, holder);
                    if (noReleaseNeeded) {
                        prc = new ProviderRefCount(holder, client, 1000, 1000);
                    } else {
                        prc = stable
                                ? new ProviderRefCount(holder, client, 1, 0)
                                : new ProviderRefCount(holder, client, 0, 1);
                    }
                    mProviderRefCountMap.put(jBinder, prc);
                }
                retHolder = prc.holder;
            }
        }

        return retHolder;
    }

分析到这里可以看出,如何Provider是在同一个进程,会通过Binder进口先查下本地对象,然后返回本地Provider实例。

回到起初的query方法,就是直接调用目标对象的query,然后系统对query方法的调用并没有做并发处理,所以可得出结论,ContentProvider的方法调用是非并发安全的。

2、ContentProvider启动时机?

上文分析中在App进程启动时,通过thread.attach()方法会调用到handleBindApplication,方法内初始化当前进程的application和provider。

  private void handleBindApplication(AppBindData data) {
  //···
        final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
        try {
            // If the app is being launched for full backup or restore, bring it up in
            // a restricted environment with the base application class.
            Application app = data.info.makeApplication(data.restrictedBackupMode, null);//注:这里第二个参数是null,意味着Application只会调用attachBaseContext方法
            mInitialApplication = app;

            // don't bring up providers in restricted mode; they may depend on the
            // app's custom Application class
            if (!data.restrictedBackupMode) {
                if (!ArrayUtils.isEmpty(data.providers)) {
                    installContentProviders(app, data.providers); //本进程内Provider的启动安装
                    // For process that contains content providers, we want to
                    // ensure that the JIT is enabled "at some point".
                    mH.sendEmptyMessageDelayed(H.ENABLE_JIT, 10*1000);
                }
            }

            try {
                mInstrumentation.callApplicationOnCreate(app);// Provider启动后才会继续回调Application的onCreate
            } catch (Exception e) {

            }
        } finally {
            StrictMode.setThreadPolicy(savedPolicy);
        }
  }

由此可见,本进程的Provider的安装是在Application初始化调用attact方法后,调用onCreate前启动。所以在App启动时注意规避本进程内的Provider,避免启动耗时。

三、总结

技术成长的道路上,不要忽略基础知识的积累,特别是一些细节问题,是不同阶段程序员修炼内功需要坚持的习惯,也是深入技术研究的基础之路。

© 著作权归作者所有
这个作品真棒,我要支持一下!
长期处于安卓业务层开发,而没有技术路线的规划提升,会让自己技术处于“还行”的二半吊子状态。此专栏主要记录作者在技术...
0条评论
top Created with Sketch.