(十二)ContentProvider數據庫
(1)ContentProvider是什麼?服務器
ContentProvider,簡稱CP。ide
作App開發的同窗,尤爲是電商類App,對CP並不熟悉,對這個概念的最大程度的瞭解,也僅僅是創建在書本上,它是Android四大組件中的一個。debug
作系統管理類的App,好比說手機助手這種,有機會頻繁使用CP。代理
而對於應用類App,數據一般存在服務器端,其它應用類App也想使用的時候,通常都是從服務器取數據,因此沒機會使用到CP。調試
有時候咱們會在本身的App中讀取通訊錄或者短信的數據,這時候就須要用到CP了。通訊錄或者短信的數據,是以CP的形式提供的,咱們在App這邊,是使用方。對象
對於作應用類App的同窗,不多有機會自定義CP供其它App使用。blog
咱們快速回顧一下在App中怎麼使用CP。進程
1)定義CP的App1:內存
在App1中定義一個CP的子類MyContentProvider,並在Manifest中聲明,爲此要在MyContentProvider中實現CP的增刪改查四個方法:
2)使用CP的App2:
在App2訪問App1中定義的CP,爲此,要使用到ContentResolver,它也提供了增刪改查4個方法,用於訪問App1中定義的CP:
首先咱們看一下ContentResolver的增刪改查這4個方法的底層實現,其實都是和AMS通訊,最終調用App1的CP的增刪改查4個方法,後面咱們會講到這個流程是怎麼樣的。
其次,URI是CP的身份證,惟一標識。
咱們在App1中爲CP聲明URI,也就是authorities的值爲baobao,那麼在App2中想使用它,就在ContentResolver的增刪改查4個方法中指定URI,格式爲:
uri = Uri.parse("content://baobao/");
接下來把兩個App都進入debug模式,就能夠從App2調試進入App1了,好比說,query操做。
(2)CP的本質
CP的本質是把數據存儲在SQLite數據庫中。
各類數據源,有各類格式,好比短信、通訊錄,它們在SQLite中就是不一樣的數據表,可是對外界的使用者而言,就須要封裝成統一的訪問方式,好比說對於數據集合而言,必需要提供增刪改查四個方法,因而咱們在SQLite之上封裝了一層,也就是CP。
(3)匿名共享內存(ASM)
CP讀取數據使用到了匿名共享內存,英文簡稱ASM,因此你看上面CP和AMS通訊忙的不亦樂乎,其實下面別有一番風景。
關於ASM的概念,它其實也是個Binder通訊,我畫個圖哦,大家就明白了:
什麼?還沒看懂?那我再畫一個類的交互關係圖:
這裏的CursorWindow就是匿名共享內存。
這個流程,簡單來講是這樣的:
1)Client內部有一個CursorWindow對象,發送請求的時候,把這個CursorWindow類型的對象傳過去,這個對象暫時爲空。
2)Server收到請求,蒐集數據,填充到這個CursorWindow對象。
3)Client讀取內部的這個CursorWindow對象,獲取到數據。
因而可知,這個CursorWindow對象,就是匿名共享內存,這是同一塊匿名內存。
舉個生活中的例子就是,你定牛奶,在你家門口放個箱子,送牛奶的人天天早上往這個箱子放一袋牛奶,你睡醒了去箱子裏取牛奶。這個牛奶箱就是匿名共享內存。
(4)CP與AMS的通訊流程
接下來咱們看一下CP是怎麼和AMS通訊的。
能堅持看到這裏的人,都不容易。我努力多貼圖,不貼代碼,即便有代碼,也是App開發人員能看懂的代碼。
仍是拿App2想訪問App1中定義的CP爲例子。咱們就看CP的insert方法。
上面這5行代碼,包括了啓動CP和執行CP方法兩部分,分水嶺在insert方法,insert方法的實現,前半部分仍然是在啓動CP,當CP啓動後獲取到CP的代理對象,後半部分是經過代理對象,調用insert方法。
總體的流程以下圖所示:
1)App2發送消息給AMS,想要訪問App1中的CP。
2)AMS檢查發現,App1中的CP沒啓動過,爲此新開一個進程,啓動App1,而後獲取到App1啓動的CP,把CP的代理對象返回給App2。
3)App2拿到CP的代理對象,也就是IContentProvider,就調用它的增刪改查4個方法了,接下來就是使用ASM來傳輸數據或者修改數據了,也就是上面提到的CursorWindow這個類,取得數據或者操做結果便可,做爲App的開發人員,不須要知道太多底層的詳細信息,用不上。
至此,關於CP的介紹就結束了。下一篇文章,咱們看一下App的安裝流程,也就PMS。