在開發(fā)中，假如，A、B進程有部分信息需要同步，這個時候怎么處理呢？設(shè)想這么一個場景，有個業(yè)務(wù)復雜的Activity非常占用內(nèi)存，并引發(fā)OOM，所以，想要把這個Activity放到單獨進程，以保證OOM時主進程不崩潰。但是，兩個整個APP有些信息需要保持同步，比如登陸信息等，無論哪個進程登陸或者修改了相應信息，都要同步到另一個進程中去，這個時候怎么做呢？

• 第一種：一個進程里面的時候，經(jīng)常采用SharePreference來做，但是SharePreference不支持多進程，它基于單個文件的，默認是沒有考慮同步互斥，而且，APP對SP對象做了緩存，不好互斥同步，雖然可以通過FileLock來實現(xiàn)互斥，但同步仍然是一個問題。
• 第二種：基于Binder通信實現(xiàn)Service完成跨進程數(shù)據(jù)的共享，能夠保證單進程訪問數(shù)據(jù)，不會有互斥問題，可是同步的事情仍然需要開發(fā)者手動處理。
• 第三種：基于Android提供的ContentProvider來實現(xiàn)，ContentProvider同樣基于Binder，不存在進程間互斥問題，對于同步，也做了很好的封裝，不需要開發(fā)者額外實現(xiàn)。

因此，在Android開發(fā)中，如果需要多進程同步互斥，ContentProvider是一個很好的選擇，本文就來看看，它的這個技術(shù)究竟是怎么實現(xiàn)的。

概述

Content providers are one of the primary building blocks of Android applications, providing content to applications. They encapsulate data and provide it to applications through the single ContentResolver interface. A content provider is only required if you need to share data between multiple applications. For example, the contacts data is used by multiple applications and must be stored in a content provider. If you don't need to share data amongst multiple applications you can use a database directly via SQLiteDatabase.

ContentProvider為Android數(shù)據(jù)的存儲和獲取抽象了統(tǒng)一的接口，并支持在不同的應用程序之間共享數(shù)據(jù)，Android內(nèi)置的許多數(shù)據(jù)都是使用ContentProvider形式供開發(fā)者調(diào)用的 (如視頻，音頻，圖片，通訊錄等)，它采用索引表格的形式來組織數(shù)據(jù)，無論數(shù)據(jù)來源是什么，ContentProvider都會認為是一種表，這一點從ContentProvider提供的抽象接口就能看出。

class XXX ContentProvider extends ContentProvider{@Overridepublic boolean onCreate() {return false;}@Nullable@Overridepublic Cursor query(@NonNull Uri uri, @Nullable String[] projection, @Nullable String selection, @Nullable String[] selectionArgs, @Nullable String sortOrder) {return null;}@Nullable@Overridepublic String getType(@NonNull Uri uri) {return null;}@Nullable@Overridepublic Uri insert(@NonNull Uri uri, @Nullable ContentValues values) {return null;}@Overridepublic int delete(@NonNull Uri uri, @Nullable String selection, @Nullable String[] selectionArgs) {return 0;}@Overridepublic int update(@NonNull Uri uri, @Nullable ContentValues values, @Nullable String selection, @Nullable String[] selectionArgs) {return 0;} }復制代碼

可以看到每個ContentProvider都需要自己實現(xiàn)增、刪、改、查的功能，因此，可以將ContentProvider看做Android提供一個抽象接口層，用于訪問表格類的存儲媒介，表格只是一個抽象，至于底層存儲媒介到底如何組織，完全看用戶實現(xiàn)，也就是說ContentProvider自身是沒有數(shù)據(jù)更新及操作能力，它只是將這種操作進行了統(tǒng)一抽象。

ContentProvider抽象接口.jpg

了解了ContentProvider的概念及作用后，下面就從用法來看看ContentProvider是如何支持多進程同步通信的。

ContentProvider代理的同步獲取

多進程對于ContentProvider的訪問請求最終都會按照隊列進入ContentProvider進程，而在單進程中，ContentProvider對于數(shù)據(jù)的訪問很容易做到多線程互斥，一個Sycronized關(guān)鍵字就能搞定，看一下基本用法：

ContentResolver contentResolver = AppProfile.getAppContext().getContentResolver();ContentValues contentValues = new ContentValues();contentValues.put(key, value);contentResolver.insert(FileContentProvider.CONTENT_URI, contentValues);contentResolver.notifyChange(FileContentProvider.CONTENT_URI, null);復制代碼

getContentResolver 其實獲取的是一個ApplicationContentResolver實例，定義在ContextImpl中，只有在真正操作數(shù)據(jù)的時候才會去獲取Provider， 詳細看一下插入操作：

public final @Nullable Uri insert(@NonNull Uri url, @Nullable ContentValues values) {<!--首先獲取Provider代理-->IContentProvider provider = acquireProvider(url);try {<!--利用IContentProvider代理插入數(shù)據(jù)-->Uri createdRow = provider.insert(mPackageName, url, values);return createdRow;} }@Overrideprotected IContentProvider acquireUnstableProvider(Context c, String auth) {return mMainThread.acquireProvider(c,ContentProvider.getAuthorityWithoutUserId(auth),resolveUserIdFromAuthority(auth), false);}復制代碼

這里是一個典型的基于Binder通信的AIDL實現(xiàn)，IContentProvider的Proxy與Stub分別是ContentProviderProxy與ContentProvider的內(nèi)部類

abstract public class ContentProviderNative extends Binder implements IContentProvider class Transport extends ContentProviderNative，復制代碼

首先看一下ActivityThread的acquireProvider，對于當前進程而言acquireProvider是一個同步的過程，如果ContentProvider所處的進程已經(jīng)啟動，那么acquireProvider可以直接獲取服務(wù)代理，如果未啟動，則等待ContentProvider進程啟動，再獲取代理。

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 {<!--關(guān)鍵點1 獲取Provider，如果沒有安裝，則等待安裝完畢-->holder = ActivityManagerNative.getDefault().getContentProvider(getApplicationThread(), auth, userId, stable);} catch (RemoteException ex) {}if (holder == null) {return null;}<!--關(guān)鍵點2 這里僅僅是增加計數(shù) ，Provider到這里其實已經(jīng)安裝完畢-->// Install provider will increment the reference count for us, and break// any ties in the race.holder = installProvider(c, holder, holder.info,true /*noisy*/, holder.noReleaseNeeded, stable);return holder.provider;}復制代碼

首先看一下關(guān)鍵點1，這里阻塞等待直到獲取Provider代理，如果Provider未啟動，則先啟動，直接看一下ActivityManagerService（其實Android四大組件都歸他管理），簡單看一下獲取流程（只描述個大概）：

private final ContentProviderHolder getContentProviderImpl(IApplicationThread caller,String name, IBinder token, boolean stable, int userId) {ContentProviderRecord cpr;ContentProviderConnection conn = null;ProviderInfo cpi = null;synchronized(this) {...<!--關(guān)鍵點1 查看是否已有記錄-->// First check if this content provider has been published...cpr = mProviderMap.getProviderByName(name, userId);...boolean providerRunning = cpr != null;<!--如果有-->if (providerRunning) {cpi = cpr.info;String msg;<!--關(guān)鍵點2 是否允許調(diào)用進程自己實現(xiàn)ContentProvider-->if (r != null && cpr.canRunHere(r)) {// This provider has been published or is in the process// of being published... but it is also allowed to run// in the caller's process, so don't make a connection// and just let the caller instantiate its own instance.ContentProviderHolder holder = cpr.newHolder(null);// don't give caller the provider object, it needs// to make its own.holder.provider = null;return holder;}final long origId = Binder.clearCallingIdentity();<!--關(guān)鍵點3 使用ContentProvider進程中的ContentProvider，僅僅增加引用計數(shù)--> // In this case the provider instance already exists, so we can// return it right away.conn = incProviderCountLocked(r, cpr, token, stable);...}boolean singleton;<!--如果provider未啟動-->if (!providerRunning) {try {checkTime(startTime, "getContentProviderImpl: before resolveContentProvider");cpi = AppGlobals.getPackageManager().resolveContentProvider(name,STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS, userId);} catch (RemoteException ex) {}...ComponentName comp = new ComponentName(cpi.packageName, cpi.name);cpr = mProviderMap.getProviderByClass(comp, userId);...<!--查看目標進程是否啟動-->ProcessRecord proc = getProcessRecordLocked(cpi.processName, cpr.appInfo.uid, false);if (proc != null && proc.thread != null) {if (!proc.pubProviders.containsKey(cpi.name)) {proc.pubProviders.put(cpi.name, cpr);try {proc.thread.scheduleInstallProvider(cpi);} catch (RemoteException e) {}}} else {<!--如果未啟動，啟動進程，并安裝-->proc = startProcessLocked(cpi.processName,cpr.appInfo, false, 0, "content provider",new ComponentName(cpi.applicationInfo.packageName,cpi.name), false, false, false);checkTime(startTime, "getContentProviderImpl: after start process");if (proc == null) {return null;}}cpr.launchingApp = proc;mLaunchingProviders.add(cpr);} finally {...// 線程阻塞等待，直到provider啟動 published，Wait for the provider to be published...synchronized (cpr) {while (cpr.provider == null) {try {if (conn != null) {conn.waiting = true;}cpr.wait();} catch (InterruptedException ex) {} finally {if (conn != null) {conn.waiting = false;}}}}return cpr != null ? cpr.newHolder(conn) : null;}復制代碼

ContentProvider的啟動同Activity或者Service都是比較類似的，如果進程未啟動，就去啟動進程，在創(chuàng)建進程之后，調(diào)用ActivityThread的attach方法，通知AMS新的進程創(chuàng)建完畢,并初始化ProcessRecord，隨后，查詢所有和本進程相關(guān)的ContentProvider信息，并調(diào)用bindApplication方法，通知新進程安裝并啟動這些ContentProvider。ContentProvider有些不一樣的就是： ContentProvider調(diào)用端會一直阻塞，直到ContentProvider published才會繼續(xù)執(zhí)行，這一點從下面可以看出：

synchronized (cpr) {while (cpr.provider == null) { 復制代碼

其次，這里有個疑惑的地方，ContentProvider一般都是隨著進程啟動的，不過為什么會存在進程啟動，但是ContentProvider未published的問題呢？不太理解，難道是中間可能存在什么同步問題嗎？下面這部分代碼完全看不出為什么存在：

if (proc != null && proc.thread != null) {<!--如果進程啟動，發(fā)消息安裝Providers-->if (!proc.pubProviders.containsKey(cpi.name)) {proc.pubProviders.put(cpi.name, cpr);try {proc.thread.scheduleInstallProvider(cpi);} catch (RemoteException e) {}}} 復制代碼

ContentProvider數(shù)據(jù)的更新

通過ContentProvider對于數(shù)據(jù)的操作都是同步的，不過contentResolver.notifyChange通知是異步的

contentResolver.insert(FileContentProvider.CONTENT_URI, contentValues);contentResolver.notifyChange(FileContentProvider.CONTENT_URI, null);復制代碼

ContentProviderProxy會發(fā)消息給服務(wù)端，而服務(wù)端這里直接調(diào)用抽象的insert函數(shù)，如果需要insert操作是同步的，那么再實現(xiàn)ContentProvider的時候，就可以直接向數(shù)據(jù)庫寫數(shù)據(jù)，當然也可以實現(xiàn)Handler，自己做異步處理。

abstract public class ContentProviderNative extends Binder implements IContentProvider {@Overridepublic boolean onTransact(int code, Parcel data, Parcel reply, int flags)throws RemoteException {...case INSERT_TRANSACTION:{data.enforceInterface(IContentProvider.descriptor);String callingPkg = data.readString();Uri url = Uri.CREATOR.createFromParcel(data);ContentValues values = ContentValues.CREATOR.createFromParcel(data);Uri out = insert(callingPkg, url, values);reply.writeNoException();Uri.writeToParcel(reply, out);return true;}復制代碼

這里有一點要注意，Binder框架默認是不支持Stub端同步的，也就是說，即時基于ContentProvider，如果需要對一個文件進行完全互斥訪問，在單個進程內(nèi)同樣需要處理互斥操作，不過單進程互斥好處理，Sycronized關(guān)鍵字就可以了。

ContentProvider數(shù)據(jù)變更通知

ContentProvider支持多進程訪問，當一個進程操作ContentProvider變更數(shù)據(jù)之后，可能希望其他進程能收到通知，比如進程A往數(shù)據(jù)庫插入了一條聊天信息，希望在進程B的UI中展現(xiàn)出來，這個時候就需要一個通知機制，Android也是提供了支持，不過它是一個通用的數(shù)據(jù)變更同步通知：基于ContentService服務(wù)：

<!--1 注冊--> public static void registerObserver(ContentObserver contentObserver) {ContentResolver contentResolver = AppProfile.getAppContext().getContentResolver();contentResolver.registerContentObserver(FileContentProvider.CONTENT_URI, true, contentObserver); }<!--2 通知-->contentResolver.notifyChange(FileContentProvider.CONTENT_URI, null);復制代碼

上面的兩個可能在統(tǒng)一進程，也可能在不同進程，

public final void registerContentObserver(Uri uri, boolean notifyForDescendents,ContentObserver observer, int userHandle) {try {getContentService().registerContentObserver(uri, notifyForDescendents,observer.getContentObserver(), userHandle);} catch (RemoteException e) {} }復制代碼

其實這里跟ContentProvider的關(guān)系已經(jīng)不是很大，這里牽扯到另一個服務(wù)：ContentService，它是Android平臺中數(shù)據(jù)更新通知的執(zhí)行者，由SystemServer進程啟動，所有APP都能調(diào)用它發(fā)送數(shù)據(jù)變動通知，其實就是一個觀察者模式，牽扯到另一個服務(wù)，不過多講解。

android:multiprocess在ContentProvider中的作用

默認情況下是不指定android:process跟multiprocess的，它們的值默認為false，會隨著應用啟動的時候加載，如果對provider指定android:process和android:multiprocess，表現(xiàn)就會不一通了，如果設(shè)置android:process，那ContentProvider就不會隨著應用啟動，如果設(shè)置了android:multiprocess，則可能存在多個ContentProvider實例。

If the app runs in multiple processes, this attribute determines whether multiple instances of the content provder are created. If true, each of the app's processes has its own content provider object. If false, the app's processes share only one content provider object. The default value is false.
Setting this flag to true may improve performance by reducing the overhead of interprocess communication, but it also increases the memory footprint of each process.

android:multiprocess的作用是：是否允許在調(diào)用者的進程里實例化provider，如果android:multiprocess=false，則系統(tǒng)中只會存在一個provider實例，否則，可以存在多個，多個的話，可能會提高性能，因為它避免了跨進程通信，畢竟，對象就在自己的進程空間，可以直接訪問，但是，這會增加系統(tǒng)負擔，另外，對于單進程能夠保證的互斥問題，也會無效，如果APP需要數(shù)據(jù)更新，還是保持不開啟的好。

總結(jié)

• ContentProvider只是Android為了跨進程共享數(shù)據(jù)提供的一種機制，
• 本身基于Binder實現(xiàn)，
• 在操作數(shù)據(jù)上只是一種抽象，具體要自己實現(xiàn)
• ContentProvider只能保證進程間的互斥，無法保證進程內(nèi)，需要自己實現(xiàn)

作者：看書的小蝸牛
Android ContentProvider支持跨進程數(shù)據(jù)共享與"互斥、同步"

僅供參考，歡迎指正

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的Android ContentProvider支持跨进程数据共享与互斥、同步 杂谈的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。