在技术学习的道路上，往往最常见、用的最多地方，却有着容易忽略的技术细节。某个时间点蓦然回首，才发现最应该了解和掌握的技术基础，却由于缺少总结和记录、或者是因为常态思维固化缺少场景去思考，却显得那么陌生。
这篇文章将从作者自身的角度，去重新认识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进入查看。
Path
1、SharedPreference在多进程并发读取时，数据是不安全，那单进程多个线程并发情况呢？
平时遇到SharedPreference的数据读取问题，几乎都是多进程并发场景。多进程问题项目中，基本都是封装一层ContentProvider，将数据的读写共享到其他进程，来保证数据的正确性（当然也可以自定义SharedPref的实现类，去保证多进程并发逻辑）。
那单进程情况下SharedPref多线程的并发，却是容易忽略的地方（虽然很久之前，看过SharedPref的部分源码，但是还是忘了系统是有针对并发加锁的）。
其实简单分析下，平时没有遇到单线程的并发问题，也没有针对单线程的SharedPref读写做相关锁操作，理论上应该是线程安全的，那么我们深入源码看看系统到底是如何保证并发安全的～
从ContextImpl开始去获取一个SharedPref实例：
@Override
public SharedPreferences getSharedPreferences(File file, int mode) {
checkMode(mode);
SharedPreferencesImpl sp; //真正的系统默认实现类
synchronized (ContextImpl.class) {
final ArrayMap 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> sSharedPrefsCache;//这里居然是静态的（为了读取速度）
synchronized (ContextImpl.class) {
final ArrayMap cache = getSharedPreferencesCacheLocked();//入口
sp = cache.get(file);
if (sp == null) {
sp = new SharedPreferencesImpl(file, mode);//开始加载
cache.put(file, sp);
return sp;
}
}
private ArrayMap getSharedPreferencesCacheLocked() {
if (sSharedPrefsCache == null) {
sSharedPrefsCache = new ArrayMap<>();
}
final String packageName = getPackageName();
ArrayMap 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;
@Override
public ContentResolver getContentResolver() {
return mContentResolver;
}
同样，接口方法依然在ContextImpl中，可以看到ContentResolver的实现类是ApplicationContentResolver。
这里以query方法为例，深入分析下：
public final @Nullable Cursor query(final @RequiresPermission.Read @NonNull Uri uri,
@Nullable String[] projection, @Nullable String selection,
@Nullable String[] selectionArgs, @Nullable String sortOrder,
@Nullable 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接口如何在acquireProvider和acquireUnstableProvider中的实现，最终会委托给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方法主要会在handleBindApplication和acquireProvider方法中调用，意味着：本进程和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，避免启动耗时。
三、总结
技术成长的道路上，不要忽略基础知识的积累，特别是一些细节问题，是不同阶段程序员修炼内功需要坚持的习惯，也是深入技术研究的基础之路。
欢迎转载，请标明出处：常兴E站 canking.win