建站
咨詢
售后
建站咨詢
新聞中心
在軟件開發(fā)過程中，獲取數(shù)據(jù)庫數(shù)據(jù)是非常常見的操作。然而，在實際的開發(fā)中，我們經常會遇到跨進程獲取數(shù)據(jù)庫數(shù)據(jù)的情況。這個時候，我們需要一些特殊的技巧來實現(xiàn)這個功能。本文將介紹如何跨進程獲取數(shù)據(jù)庫數(shù)據(jù)，讓讀者輕松掌握這個技巧。
之一步：使用ContentProvider
在Android中，ContentProvider是實現(xiàn)數(shù)據(jù)共享的主要方式。他能夠將應用程序中的數(shù)據(jù)集映射到標準的Android接口上，從而讓其他應用程序可以訪問到這些數(shù)據(jù)。ContentProvider是安卓四大組件之一，可以對數(shù)據(jù)庫進行操作。同時為其他APP跨進程訪問數(shù)據(jù)庫提供了良好的標準化API支持。
如果你的應用程序需要跨進程獲取數(shù)據(jù)庫數(shù)據(jù)，那么可以考慮使用ContentProvider。創(chuàng)建ContentProvider的方法有很多種，包括使用原生開發(fā)的方式，或者使用第三方框架。下面將以原生開發(fā)為例進行講解。
第二步：創(chuàng)建MetaData
ContentProvider需要元數(shù)據(jù)信息來描述他所映射的數(shù)據(jù)集信息。在Android中，MetaData是一種用于描述元數(shù)據(jù)信息的標記。通過MetaData標記，ContentProvider能夠了解到數(shù)據(jù)集的基本信息。
在創(chuàng)建ContentProvider時需要編寫一個MetaData類并在清單文件中注冊。這個類包含了數(shù)據(jù)庫的基本信息，如數(shù)據(jù)庫名稱、版本號以及表的名稱等信息。具體實現(xiàn)方法如下：
public class MyDatabaseMetaData implements BaseColumns {
// 這是Content Provider的基礎信息
public static final String AUTHORITY = “com.example.MyDataProvider”;
public static final String DATABASE_NAME = “mydatabase.db”;
public static final int DATABASE_VERSION = 1;
private MyDatabaseMetaData() {
}
// 表的名字以及字段的名字
public static final String TABLE_NAME = “mytable”;
public static final String COLUMN_NAME = “name”;
public static final String COLUMN_AGE = “age”;
// 其他的元數(shù)據(jù)信息
}
第三步：實現(xiàn)ContentProvider
在創(chuàng)建了MetaData之后，我們就可以開始實現(xiàn)ContentProvider了。在實現(xiàn)ContentProvider的過程中，我們需要注意以下幾點：
1、實現(xiàn)ContentProvider需要繼承ContentProvider基類，并實現(xiàn)其中的方法。
2、實現(xiàn)ContentProvider的方法需要非常小心，因為他們會在不同的線程中被調用。
3、ContentProvider必須在AndroidManifest.xml中注冊。
下面是一個實現(xiàn)ContentProvider的基本結構：
public class MyContentProvider extends ContentProvider {
// 這是ContentProvider的初始化方法
public boolean onenCreate() {
// 創(chuàng)建數(shù)據(jù)庫和表
return true;
}
// 查詢數(shù)據(jù)庫，并將數(shù)據(jù)返回給調用者
public Cursor query(Uri uri, String[] projection, String selection,
String[] selectionArgs, String sort) {
// 查詢數(shù)據(jù)庫并返回Cursor
return null;
}
// 插入數(shù)據(jù)到數(shù)據(jù)庫
public Uri insert(Uri uri, ContentValues values) {
// 將數(shù)據(jù)插入到數(shù)據(jù)庫
return null;
}
// 更新數(shù)據(jù)庫中的數(shù)據(jù)
public int update(Uri uri, ContentValues values, String selection,
String[] selectionArgs) {
// 更新數(shù)據(jù)庫中的數(shù)據(jù)
return 0;
}
// 刪除數(shù)據(jù)
public int delete(Uri uri, String selection, String[] selectionArgs) {
// 刪除數(shù)據(jù)庫中的數(shù)據(jù)
return 0;
}
// 返回指定URI所對應的MIME類型信息，讓外部應用程序可以得知你返回的數(shù)據(jù)類型
public String getType(Uri uri) {
// 返回指定URI所對應的MIME類型信息
return null;
}
}
第四步：使用ContentProvider來獲取數(shù)據(jù)
一旦實現(xiàn)了ContentProvider，我們就可以通過ContentResolver來調用這些方法獲取數(shù)據(jù)了。ContentResolver是Android中用來訪問ContentProvider的類。他提供了對ContentProvider操作的高層次抽象，并保證了其線程安全。下面是一個使用ContentResolver獲取數(shù)據(jù)的例子：
Cursor cursor = getContentResolver().query(Uri.parse(“content://com.example.MyDataProvider.mytable”), null, null, null, null);
如果查詢成功，我們就可以從返回的Cursor中獲取數(shù)據(jù)。
在這篇文章中，我們介紹了如何使用ContentProvider來跨進程獲取數(shù)據(jù)庫數(shù)據(jù)。具體實現(xiàn)包括創(chuàng)建MetaData、實現(xiàn)ContentProvider方法以及使用ContentResolver調用這些方法來獲取數(shù)據(jù)。我們希望讀者可以通過這些技巧輕松掌握跨進程獲取數(shù)據(jù)庫數(shù)據(jù)的方法，從而更好地完成Android應用程序的開發(fā)。
相關問題拓展閱讀：
- Android 開發(fā)中，有哪些坑需要注意
Android 開發(fā)中，有哪些坑需要注意
1. 為Activity聲明系統(tǒng)配置變更事件
系統(tǒng)配置變更事件是指轉屏，區(qū)域語言發(fā)生變化，屏幕尺寸發(fā)生變化等等，如果Activity沒有聲明處理這些事件，發(fā)生事件時，系統(tǒng)會把Activity殺掉然后重啟，并嘗試恢復狀態(tài)，Activity有機會通過onSaveInstanceState()保存一些基本數(shù)據(jù)到Bundle中，然后此Bundle會在Activity的onCreate()中傳遞過去。雖然這貌似正常，但是這會引發(fā)問題，因為很多其他的東西比如Dialog等是要依賴于具體Activity實例的。所以這種系統(tǒng)默認行為通常都不是我們想要的。
為了避免這些系統(tǒng)默認行為，就需要為Activity聲明這些配置，如下二個是每個Activity必須聲明的：
幾乎所有的Activity都要聲明如上，為什么Android不把它們變成Default的呢?
2. 盡量使用Android的API
這好像是廢話，在Android上面開發(fā)不用Android API用什么？因為Android幾乎支持Java SE所有的API，所以有很多地方Android API與Java SE的API會有重復的地方，比如說對于文件的操作更好使用Android里面Context封裝的API，而不要直接使用File對象：
Context.openFileOutput(String); // no File file = new File(String)
原因就是API里面會考慮到Android平臺本身的特性；再如，少用Thread，而多使用AsyncTask等。
3. 要考慮到Activity和進程被殺掉的情況
如了通常情況退出Activity外，還有Activity因其他原因被殺的情況，比如系統(tǒng)內存過低，系統(tǒng)配置變更，有異常等等，要考慮和測試這種情況，特別是Activity處理重要的數(shù)據(jù)時，做好的數(shù)據(jù)的保存。
4. 小心多語言
有些語言真的很啰嗦，中文或英文很簡短就能表達的事情到了其他語言就變的死長死長的，所以如果是wrap_content就可能把其他控制擠出可視范圍； 如果是指定長度就可能顯示不全。也要注意特殊語言比如那些從右向左讀的語言。
5. 不要用四大組件去實現(xiàn)接口
一是組件的對象都比較大，實現(xiàn)接口比較浪費，而且讓代碼更不易讀和理解； 另外更重要的是導致多方引用，可能會引發(fā)內存泄露。
6. 用getApplication()來取Context當參數(shù)
對于需要使用Context對象作為參數(shù)的函數(shù)，要使用getApplication()獲取Context對象當參數(shù)，而不要使用this，除非你需要特定的組件實例！getApplication()返回的Context是屬于Application的，它會在整個應用的生命周期內存在，遠大于某個組件的生命周期，所以即使某個引用長期持有Context對象也不會引發(fā)內存泄露。
7. 主線程只做UI控制和Frameworks回調相關的事。附屬線程只做費時的后臺操作。交互只通過Handler。這樣就可以避免大量的線程問題。
8. Frameworks的回調不要做太多事情僅做必要的初始化，其他不是很重要的事情可以放到其他線程中去做，或者用Handler Schedule到稍后再做。
9. 要考慮多分辨率
至少為hdpi, mdpi, ldpi準備圖片和布局。元素的單位也盡可能的使用dip而不要用px。
10. 利用Android手機的硬鍵
幾乎所有的Android手機都有BACK和MENU，它們的作用是返回和彈出菜單，所以就不要再在UI中設計返回按扭和菜單按扭。很多優(yōu)秀的應用如隨手記和微信都有返回鍵，他們之所以有是因為他們都是從iOS上移植過來的，為了保存體驗的一致，所以也有了返回和菜單。但這不夠Android化，一個純正的Android是沒有必須重復硬鍵的功能的。
1、不要排斥新技術和新工具。Android Studio 1.0 之后的版本，基本已經穩(wěn)定到可以支持正常的工作開發(fā)的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大于它和Gradle的學習成本。JetBrains的IDE，用過都說好。還有就是適當?shù)奶嵘齮argetSdkVersion到新版本。
2、代碼設計方面的問題，大部分都能在Android系統(tǒng)源碼里找到解決方案。當你想設計一個新模塊，或者實現(xiàn)一個新ui組件的時候，應該采用哪些設計模式、應該以哪種形式給外界提供接口之類的問題，大部分都可以參考Android系統(tǒng)的源碼，找到實現(xiàn)方式。Google為安卓程序員提供了一座現(xiàn)成的寶庫。
3、理解Android和Java內存管理方式，至少要理解垃圾回收和Java的引用。就好比學OC就要先理解黃金法則一樣，而java的內存管理，其實比OC要好理解多了。這可能會幫助你大大減少程序異步操作產生的空指針崩潰。也會幫助你理解為什么濫用單例模式會導致內存的臃腫。還會幫助你養(yǎng)成不用“+”去連接超大字符串的好習慣。
4、ContentProvider并不是只有在跨進程共享數(shù)據(jù)的才有用，把數(shù)據(jù)庫表映射到一個獨立的uri是Google鼓勵的實現(xiàn)方式。從設計上講，用uri（統(tǒng)一資源標識符）去描述數(shù)據(jù)，肯定比sql語句要理想。從效果上講，用CursorLoader讀取數(shù)據(jù)是讓iOS程序員都羨慕不已的事情，作為android程序員，何苦不用呢。
5、理解Activity任務棧。非Activity的Context對象如果直接啟動Activity會報錯，這只是一個表面現(xiàn)象，真正起作用的其實是Activity任務棧機制。理解Activity任務棧機制以及Activity的各種啟動方式，會幫助解決大部分頁面關系錯亂問題，以及應用互相掉起、任務欄進入應用后臺彈窗引起的各種問題。
6、對于一些奇葩的第三方ROM，調用其非主流api的時候，可以使用反射。
在適配一些第三方ROM的的時候，調用一些在開發(fā)環(huán)境中沒有，但在運行環(huán)境中有的方法時，可以使用反射。比方說，華為雙卡手機可能會提供獲取第二塊SIM卡信息的api，如果直接調用，在開發(fā)環(huán)境可能無法通過正常編譯，用反射就沒問題。這屬于不得已而用反射的一種情況。
7、SQLite的鎖，是數(shù)據(jù)庫級別的鎖，也就是說同一個數(shù)據(jù)庫的寫操作無法并發(fā)執(zhí)行。所以，在數(shù)據(jù)庫設計的時候，如果表太多，盡量將沒有關聯(lián)的表拆到多個數(shù)據(jù)庫文件中。
8、Bitmap的內存占用問題。這是一個困擾2.X時代android程序員的問題。
1、不要排斥新技術和新工具。Android Studio 1.0 之后的版本，基本已經穩(wěn)定到可以支持正常的工作開發(fā)的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大于它和Gradle的學習成本。JetBrains的IDE，用過都說好。還有就是適當?shù)奶嵘齮argetSdkVersion到新版本。
2、代碼設計方面的問題，大部分都能在Android系統(tǒng)源碼里找到解決方案。當你想設計一個新模塊，或者實現(xiàn)一個新ui組件的時候，應該采用哪些設計模式、應該以哪種形式給外界提供接口之類的問題，大部分都可以參考Android系統(tǒng)的源碼，找到實現(xiàn)方式。Google為安卓程序員提供了一座現(xiàn)成的寶庫。
3、理解Android和Java內存管理方式，至少要理解垃圾回收和Java的引用。就好比學OC就要先理解黃金法則一樣，而java的內存管理，其實比OC要好理解多了。這可能會幫助你大大減少程序異步操作產生的空指針崩潰。也會幫助你理解為什么濫用單例模式會導致內存的臃腫。還會幫助你養(yǎng)成不用“+”去連接超大字符串的好習慣。
4、ContentProvider并不是只有在跨進程共享數(shù)據(jù)的才有用，把數(shù)據(jù)庫表映射到一個獨立的uri是Google鼓勵的實現(xiàn)方式。從設計上講，用uri（統(tǒng)一資源標識符）去描述數(shù)據(jù)，肯定比sql語句要理想。從效果上講，用CursorLoader讀取數(shù)據(jù)是讓iOS程序員都羨慕不已的事情，作為android程序員，何苦不用呢。
5、理解Activity任務棧。非Activity的Context對象如果直接啟動Activity會報錯，這只是一個表面現(xiàn)象，真正起作用的其實是Activity任務棧機制。理解Activity任務棧機制以及Activity的各種啟動方式，會幫助解決大部分頁面關系錯亂問題，以及應用互相掉起、任務欄進入應用后臺彈窗引起的各種問題。
6、對于一些奇葩的第三方ROM，調用其非主流api的時候，可以使用反射。
在適配一些第三方ROM的的時候，調用一些在開發(fā)環(huán)境中沒有，但在運行環(huán)境中有的方法時，可以使用反射。比方說，華為雙卡手機可能會提供獲取第二塊SIM卡信息的api，如果直接調用，在開發(fā)環(huán)境可能無法通過正常編譯，用反射就沒問題。這屬于不得已而用反射的一種情況。
7、SQLite的鎖，是數(shù)據(jù)庫級別的鎖，也就是說同一個數(shù)據(jù)庫的寫操作無法并發(fā)執(zhí)行。所以，在數(shù)據(jù)庫設計的時候，如果表太多，盡量將沒有關聯(lián)的表拆到多個數(shù)據(jù)庫文件中。
8、Bitmap的內存占用問題。這是一個困擾2.X時代android程序員的問題。
參考如下
1、不要排斥新技術和新工具。
Android Studio 1.0 之后的版本，基本已經穩(wěn)定到可以支持正常的工作開發(fā)的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大于它和Gradle的學習成本。JetBrains的IDE，用過都說好。
還有就是適當?shù)奶嵘齮argetSdkVersion到新版本。
2、代碼設計方面的問題，大部分都能在Android系統(tǒng)源碼里找到解決方案。
當設計一個新模塊，或者實現(xiàn)一個新ui組件的時候，應該采用哪些設計模式、應該以哪種形式給外界提供接口之類的問題，大部分都可以參考Android系統(tǒng)的源碼，找到實現(xiàn)方式。Google為安卓程序員提供了一座現(xiàn)成的寶庫。
3、理解Android和Java內存管理方式，至少要理解垃圾回收和Java的引用。
就好比學OC就要先理解黃金法則一樣，而java的內存管理，其實比OC要好理解多了。
這可能會幫助大大減少程序異步操作產生的空指針崩潰。也會幫助理解為什么濫用單例模式會導致內存的臃腫。還會幫助養(yǎng)成不用“+”去連接超大字符串的好習慣。
4、ContentProvider并不是只有在跨進程共享數(shù)據(jù)的才有用，把數(shù)據(jù)庫表映射到一個獨立的uri是Google鼓勵的實現(xiàn)方式。
從設計上講，用uri（統(tǒng)一資源標識符）去描述數(shù)據(jù)，肯定比sql語句要理想。
從效果上講，用CursorLoader讀取數(shù)據(jù)是讓iOS程序員都羨慕不已的事情，作為android程序員，何苦不用呢。
5、理解Activity任務棧。
非Activity的Context對象如果直接啟動Activity會報錯，這只是一個表面現(xiàn)象，真正起作用的其實是Activity任務棧機制。
理解Activity任務棧機制以及Activity的各種啟動方式，會幫助解決大部分頁面關系錯亂問題，以及應用互相掉起、任務欄進入應用、后臺彈窗引起的各種問題。
6、對于一些奇葩的第三方ROM，調用其非主流api的時候，可以使用反射。
在適配一些第三方ROM的的時候，調用一些在開發(fā)環(huán)境中沒有，但在運行環(huán)境中有的方法時，可以使用反射。比方說，華為雙卡手機可能會提供獲取第二塊SIM卡信息的api，如果直接調用，在開發(fā)環(huán)境可能無法通過正常編譯，用反射就沒問題。這屬于不得已而用反射的一種情況。
7、SQLite的鎖，是數(shù)據(jù)庫級別的鎖，也就是說同一個數(shù)據(jù)庫的寫操作無法并發(fā)執(zhí)行。
所以，在數(shù)據(jù)庫設計的時候，如果表太多，盡量將沒有關聯(lián)的表拆到多個數(shù)據(jù)庫文件中。
8、Bitmap的內存占用問題。
這是一個困擾2.X時代android程序員的問題。
2.X時代Bitmap對象雖然存儲在堆內存中，但是用了一個byte數(shù)組存儲其像素信息。通過計數(shù)器來記錄該像素信息被引用的個數(shù)。有人認為這個byte數(shù)組在native堆中，但事實上它也在堆中。
只有在使用者調用recycle()后，Bitmap對象才會釋放像素信息，才會在失去引用后，被垃圾回收機制銷毀。再加上DVM的heap size有嚴格的閥值，所以在使用大量圖片資源的時候，及其容易發(fā)生OOM。
解決辦法一般都是，用一個哈希表存儲Bitmap對象的軟引用，作為內存緩存，并在適當時機掉用其recycle()。
3.0以上版本Bitmap對象可以通過垃圾回收機制完全銷毀，理論上不用再調用recycle()。
為Activity聲明系統(tǒng)配置變更事件
系統(tǒng)配置變更事件是指轉屏，區(qū)域語言發(fā)生變化，屏幕尺寸發(fā)生變化等等，如果Activity沒有聲明處理這些事件，發(fā)生事件時，系統(tǒng)會把Activity殺掉然后重啟，并嘗試恢復狀態(tài)，Activity有機會通過onSaveInstanceState()保存一些基本數(shù)據(jù)到Bundle中，然后此Bundle會在Activity的onCreate()中傳遞過去。雖然這貌似正常，但是這會引發(fā)問題，因為很多其他的東西比如Dialog等是要依賴于具體Activity實例的。所以這種系統(tǒng)默認行為通常都不是我們想要的。
為了避免這些系統(tǒng)默認行為，就需要為Activity聲明這些配置，如下二個是每個Activity必須聲明的：
幾乎所有的Activity都要聲明如上，為什么Android不把它們變成Default的呢?
2. 盡量使用Android的API
這好像是廢話，在Android上面開發(fā)不用Android API用什么？因為Android幾乎支持Java SE所有的API，所以有很多地方Android API與Java SE的API會有重復的地方，比如說對于文件的操作更好使用Android里面Context封裝的API，而不要直接使用File對象：
Context.openFileOutput(String); // no File file = new File(String)
原因就是API里面會考慮到Android平臺本身的特性；再如，少用Thread，而多使用AsyncTask等。
3. 要考慮到Activity和進程被殺掉的情況
如了通常情況退出Activity外，還有Activity因其他原因被殺的情況，比如系統(tǒng)內存過低，系統(tǒng)配置變更，有異常等等，要考慮和測試這種情況，特別是Activity處理重要的數(shù)據(jù)時，做好的數(shù)據(jù)的保存。
4. 小心多語言
有些語言真的很啰嗦，中文或英文很簡短就能表達的事情到了其他語言就變的死長死長的，所以如果是wrap_content就可能把其他控制擠出可視范圍； 如果是指定長度就可能顯示不全。也要注意特殊語言比如那些從右向左讀的語言。
5. 不要用四大組件去實現(xiàn)接口
一是組件的對象都比較大，實現(xiàn)接口比較浪費，而且讓代碼更不易讀和理解； 另外更重要的是導致多方引用，可能會引發(fā)內存泄露。
6. 用getApplication()來取Context當參數(shù)
對于需要使用Context對象作為參數(shù)的函數(shù)，要使用getApplication()獲取Context對象當參數(shù)，而不要使用this，除非你需要特定的組件實例！getApplication()返回的Context是屬于Application的，它會在整個應用的生命周期內存在，遠大于某個組件的生命周期，所以即使某個引用長期持有Context對象也不會引發(fā)內存泄露。
7. 主線程只做UI控制和Frameworks回調相關的事。附屬線程只做費時的后臺操作。交互只通過Handler。這樣就可以避免大量的線程問題。
8. Frameworks的回調不要做太多事情僅做必要的初始化，其他不是很重要的事情可以放到其他線程中去做，或者用Handler Schedule到稍后再做。
9. 要考慮多分辨率
至少為hdpi, mdpi, ldpi準備圖片和布局。元素的單位也盡可能的使用dip而不要用px。
10. 利用Android手機的硬鍵
幾乎所有的Android手機都有BACK和MENU，它們的作用是返回和彈出菜單，所以就不要再在UI中設計返回按扭和菜單按扭。很多優(yōu)秀的應用如隨手記和微信都有返回鍵，他們之所以有是因為他們都是從iOS上移植過來的，為了保存體驗的一致，所以也有了返回和菜單。但這不夠Android化，一個純正的Android是沒有必須重復硬鍵的功能的。
關于跨進程獲取數(shù)據(jù)庫的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。
香港服務器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務提供商,擁有超過10年的服務器租用、服務器托管、云服務器、虛擬主機、網(wǎng)站系統(tǒng)開發(fā)經驗。專業(yè)提供云主機、虛擬主機、域名注冊、VPS主機、云服務器、香港云服務器、免備案服務器等。
當前名稱：輕松掌握：如何跨進程獲取數(shù)據(jù)庫數(shù)據(jù)？(跨進程獲取數(shù)據(jù)庫)
本文鏈接：http://m.5511xx.com/article/cdshggi.html
