1. 程式人生 > >基於 android 資料備份恢復的一種實現

基於 android 資料備份恢復的一種實現

引言

隨著 3G 時代的到來,移動網際網路的發展,手機的功能越來越強大,手機裡的資料對每個使用者來說都非常的重要,特別是通訊錄、日程、簡訊息、郵件等資料,一旦手機丟失、誤刪或其他意外使得資料無法正常使用,會給使用者帶來麻煩,資料備份與恢復這個應用可以幫助使用者解決這個問題。

本文主要論述了基於 Android 平臺所提供的開發框架和應用元件,並給出了一種資料備份恢復的設計與實現。

當前流行的智慧手機作業系統有 Windows Mobile,Symbian,iPhone OS,Android 等。本文基於目前最熱門的 Android 系統平臺,該平臺具有開源、易用、開發方便、與個人電腦有較強的融合性等眾多優勢。


圖 1. Android 架構圖
圖 1. Android 架構圖 

Application:

Android 會與一個核心應用程式包一起釋出,如通訊錄、簡訊息、瀏覽器等,所有的應用使用 Java 語言所開發。

Application Framework:

Android 應用程式框架對於開發者也完全可以訪問核心應用程式所使用的 API 框架。該應用程式架構用來簡化元件軟體的重用;任何一個應用程式都可以釋出它的功能塊並且任何其它的應用程式都可以使用其所釋出的功能塊。該應用程式重用機制使得組建可以被使用者替換。

Libraries:

Android 程式庫包括一個被 Android 系統中各種不同元件所使用的 C/C++ 庫集。該庫通過 Android 應用程式框架為開發者提供服務。

Linux Kernel:

核心 Android 的核心繫統服務依賴於 Linux 2.6 核心,如安全性,記憶體管理,程序管理,網路協議棧和驅動模型。 Linux 核心也同時作為硬體和軟體堆疊之間的硬體抽象層。

備份的方式有本地備份、網路備份,本地備份是直接將資料備份到 SDcard 儲存介質中;網路備份是將資料備份到網路伺服器中。網路伺服器系統是基於 J2EE 架構,通過 HTTP(HTTPS)協議對終端提供服務,備份的應用的數目可以大於等於 1,這裡只備份通訊錄。系統體系結構圖如下所示:


圖 2. 資料備份與恢復體系結構圖
圖 2. 資料備份與恢復體系結構圖 

本地備份恢復客戶端的流程

使用者選擇本地 Backup 或 Restore,通過向 Contacts 傳送廣播訊號,如果 Contacts 準確收到廣播訊號後,開始執行 Backup 或 Restore 操作,完成後反饋操作結果。流程圖如下所示:


圖 3. 本地備份恢復流程圖
圖 3. 本地備份恢復流程圖 

本地備份恢復客戶端的序列圖:

在序列圖中,客戶端選擇本地備份或本地恢復後,傳送廣播訊息通知 Contacts 應用開始備份或恢復 (ContactsReceiver 根據訊號類別 : 執行備份或恢復操作 ),通過 FileInputStream 和 FileOutputStream 對資料庫檔案進行 read/write。

如果是本地備份則將自身的資料庫檔案寫到 SDCard;如果是本地恢復將 SDCard 中對應的檔案寫到 Contacts 應用對應的路徑下,用以覆蓋原始資料庫檔案。

用 Environment.getExternalStorageDirectory() 方法獲取 SD 卡的路徑 , 卡儲存空間大小及已佔用空間獲取方法 :

  /* 獲取儲存卡路徑 */ 
 File sdcardDir=Environment.getExternalStorageDirectory(); 
 /*StatFs 看檔案系統空間使用情況 */ 
 StatFs statFs=new StatFs(sdcardDir.getPath()); 
 /*Block 的 size*/ 
 Long blockSize=statFs.getBlockSize(); 
 /* 總 Block 數量 */ 
 Long totalBlocks=statFs.getBlockCount(); 
 /* 已使用的 Block 數量 */ 
 Long availableBlocks=statFs.getAvailableBlocks(); 

序列圖如下所示:


圖 4. 本地備份恢復序列圖
圖 4. 本地備份恢復序列圖 

本地備份恢復客戶端的實現:

如下圖給出了 BackupRestoreActivity 和 ContactsReceiver 的類圖,以及他們工作機制中涉及到的類的結構。


圖 5. 本地備份恢復類圖
圖 5. 本地備份恢復類圖 
  • Intent 在這裡起著一個媒體中介的作用,專門提供元件互相呼叫的相關資訊,實現呼叫者與被調 用者之間的解耦 .
  • 此處的 IntentFilter 起動態註冊 action, 使之用於接收同 action 的廣播訊息 IntentFilter
    commandFilter = newIntentFilter(); 
     commandFilter.addAction("signal"); 
     registerReceiver(BroadcastReceiver, commandFilter); 
     BroadcastReceiver 用來接收和響應廣播訊息
    
  • Handler 主要接受子執行緒傳送的資料 , 並用此資料配合主執行緒更新 UI.
  • ContactsReceiver 呼叫 Thread 開啟一個執行緒 , 用以接收由 BackupRestoreActivity 發出的備份 / 恢復訊號。
  • NetToolHandler(用於網路備份恢復)定義了一些用來和伺服器進行互動的方法;IHttpResponse 是在 NetToolHandler 中定義的一個內部介面,主要用來回調 NetToolHandler 中返回的資訊,根據返回的資訊進行下一步操作。

使用者選擇本地備份或者本地恢復,ContactsReceiver 則收到廣播訊息後,根據訊號判斷操作的類別是備份還是恢復,然後啟動一個執行緒,線上程中呼叫 Handler,通過 Handler 去處理讀寫資料。

伺服器端設計與實現

網路備份通過 WiFi 或者 GPRS 在手機端與伺服器進行連線,伺服器提供相應的介面,用於上傳或下載檔案。

伺服器端用例分析

1) 備份資料上傳:響應客戶端的 backup 功能。檔案通過 HTTP 請求提交到伺服器,伺服器接收檔案並儲存,序列圖表示如下:


圖 6. 網路備份恢復上傳序列圖
圖 6. 網路備份恢復上傳序列圖 

說明:如果 Servlet 檢查到輸入引數不合法,會中斷服務並通知客戶端。

介面定義:

URLhttps://<server>:<port>/upload?uuid=< 上傳檔案的 uuid>&name=< 真實檔名 >&md5= 8b1a9fbf5e111296a827abf8c47804d7&offset=< 偏移量 >&desc=< 檔案描述資訊 >&size=< 檔案大小 >&deviceid=< 終端的 id>,HTTP 正文為上傳的內容


表 1. 備份資料上傳引數表
提交項關鍵字作用格式
uuid uuid 方便上載失敗後斷點續傳 , 客戶端生成
檔名 name 上傳檔名
MD5 校驗碼 md5 用於對上載檔案作完整性校驗。 16 進位制格式,共 32 位長
偏移量 offset 斷點續傳的偏移量。 長整數,最小為 0,最大為檔案位元組數。
檔案描述資訊 desc 除使用者名稱外的檔案描述。 不能大於 256 個字元,否則丟擲 400 錯誤
檔案大小 size 用於斷點續傳功能建立檔案時使用。 長整數
裝置 id deviceid 用於一個使用者多個裝置進行網路備份恢復的依據

必須使用 POST 方式提交,且只允許上傳一個檔案

offset:客戶端應從 offset( 包含 offset) 開始上傳檔案。offset=0 時,忽略 offset 引數。

如果是續傳檔案,應先用 uploadquery 介面查詢檔案已上傳部分的大小,以獲取 offset 的值

表 2. 備份資料上傳返回值

成功

HTTP 頭HTTP Body
200

失敗(包含公共錯誤)

HTTP 頭錯誤碼HTTP Body (Xml 格式的錯誤訊息)
Code Message
400 MSG-1001 檔案上傳失敗

2) 備份資料下載:響應客戶端的網路恢復功能。根據檔名將使用者請求的檔案傳遞給客戶端。序列圖表示如下:


圖 7. 網路備份恢復下載序列圖
圖 7. 網路備份恢復下載序列圖 

流程描述如下:

  • 客戶端向伺服器傳送 requestDownload 請求,請求中包含檔案的 uuid 和斷點續傳的起始點。
  • Servlet 呼叫 downloadSavedFile 介面 , 傳遞檔案 uuid 和 range 引數。
  • 資料庫存取返回自 range 開始的位元組流,位元組流返回給前面的 servlet。

介面定義:

URLhttps://<server>:<port>/fileDownload? uuid=< 檔案標識 >&range=< 偏移量 > &deviceid=< 終端的 id>

引數含義同備份資料上傳;客戶端應從 range ( 包含 range) 開始下載,range =0 時,忽略 range 引數。

表 3. 備份資料下載返回值:

成功

HTTP 頭HTTP Body
200/201 要下載的檔案流 , 新下載返回的是 200 否則返回 201

失敗

HTTP 頭錯誤碼HTTP Body (Xml 格式的錯誤訊息)
Code Message
400 MSG-1002 無法下載

3) 新建手機備份儲存空間:當客戶端第一次訪問備份伺服器時,系統會返回找不到個人網路備份儲存空間錯誤,客戶端軟體提示使用者是否新建備份空間,使用者確認建立個人網路備份空間,系統才會為其建立儲存空間。伺服器會用 deviceid 為標識為對應的手機的分配固定大小的空間。伺服器端使用 adapter 模式來連線多種不同檔案儲存媒體。序列圖表示如下:


圖 8. 網路備份恢復建立儲存空間序列圖
圖 8. 網路備份恢復建立儲存空間序列圖 

介面定義:

URLhttps://<server>:<port>/createspace?deviceid=< 終端的 id>

引數含義同備份資料上傳。

表 4. 建立儲存空間返回值:

成功

HTTP 頭HTTP Body
200

失敗

HTTP 頭錯誤碼HTTP Body (Xml 格式的錯誤訊息)
Code Message
400 MSG-1003 備份空間已建立
400 MSG-1004 新建備份空間失敗

4) 查詢已上傳部分的大小:當檔案上傳中斷時,可以查詢已上傳部分的大小,然後斷點續傳餘下部分。序列圖表示如下:


圖 9. 網路備份恢復查詢已上傳部分序列圖
圖 9. 網路備份恢復查詢已上傳部分序列圖 

介面定義:

URLhttps://<server>:<port>/uploadquery?uuid=< 上傳檔案的 uuid>&deviceid=< 終端的 id>

引數含義同備份資料上傳。

表 5. 查詢檔案已上傳部分返回值:

成功

HTTP 頭HTTP Body
200 正整數(檔案已上傳部分的大小)

失敗(包含公共錯誤)

HTTP 頭錯誤碼HTTP Body (Xml 格式的錯誤訊息)
Code Message
400 MSG-1005 檔案已上傳完成

伺服器端的實現:

  1) 包檔案設計如下所示:

圖 10. 網路備份恢復包檔案設計圖

   

  • com.bakrestore.server.dao 下面主要存放 DAO 介面,DAO 主要用來解偶業務方法和資料來源,即在業務核心方法和具體資料來源之間再增加一層,用來連線業務方法和資料來源。
  • com.bakrestore.server.model 主要存放一些持久化類
  • com.bakrestore.server.service 主要存放業務邏輯類
  • com.bakrestore.server.web 主要用來存放介面類,用來響應手機終端。

在 spring 的配置檔案:applicationContext.xml 中,該檔案中定義了 Spring 要管理的所有的 Beans, 用 Beans 的形式來管理所有的物件以及他們之間的賦值依賴的。在此配置檔案中主要定義了 dao,model,service 下面的類。示例程式碼如下:


清單 1. spring 的配置檔案
				
 <bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean"> 
 <property name="configLocation" 
    value="classpath:com/bakrestore/server/dao/ibatis/sql/sql-map-config.xml" /> 
 <property name="dataSource" ref="dataSource" /> 
 <property name="lobHandler" ref="lobHandler" /> 
 </bean> 
 <bean id="userSpaceDAO" class="com.bakrestore.server.dao.ibatis.UserSpaceDAOImpl"> 
	 <property name="sqlMapClient" ref="sqlMapClient"/> 
 </bean> 
 <bean id="userFileDAO" class="com.bakrestore.server.dao.ibatis.UserFileDAOImpl"> 
	 <property name="sqlMapClient" ref="sqlMapClient"/> 
 </bean> 
 <bean id="adddbdao" class="com.bakrestore.server.dao.ibatis.AddDbDAOImpl"> 
	 <property name="sqlMapClient" ref="sqlMapClient"/> 
 </bean> 	
 <bean id="addDbService" class="com.bakrestore.server.service.impl.AddDbServiceImpl"> 
	 <property name="adddbdao" ref="adddbdao"/> 
	 <property name="fileContentService"  ref="fileContentService" /> 
 </bean> 	
 <bean id="fileService" class="com.bakrestore.server.service.impl.FileServiceImpl"> 
	 <property name="userSpaceDAO" ref="userSpaceDAO"/> 
	 <property name="userFileDAO" ref="userFileDAO"/> 
	 <property name="fileContentService"  ref="fileContentService" /> 
 </bean> 	
 <bean id="spaceService" class="com.bakrestore.server.service.impl.SpaceServiceImpl"> 
	 <property name="userSpaceDAO" ref="userSpaceDAO"/> 
	 <property name="fileContentService" ref="fileContentService" /> 
	 <property name="spaceMaxSize" value="${UserSpaceMaxSize}" /> 
 </bean> 

在 SpringDispatcher-servlet.xml 配置一個檢視解析器,其次將手機端的請求與相應的進行對映.以便程式在執行過程中可以依據對映找到所需 Controller,相應的 Controller 與 applicationContext.xml 所定義的 beans 進行互動。示例程式碼如下:


清單 2. 配置一個檢視解析器
				
 <bean id="createspace" name="/createspace" parent="pim" 
   class="com.bakrestore.server.web.CreateSpaceController"> 
 </bean> 
 <bean id="download" name="/download" parent="pim" 
   class="com.bakrestore.server.web.DownloadController" > 
 </bean> 
 <bean id="uploadquery" name="/uploadquery" parent="pim" 
   class="com.bakrestore.server.web.UploadQueryController"> 
 </bean> 
 <bean id="upload" name="/upload" parent="pim" 
    class="com.bakrestore.server.web.UploadController" > 
	 <property name="sizeMax" value="${UploadFileSizeMax}" /> 
	 <property name="uploadFileTempFolder" value="${UploadFileTempFolder}" /> 
 </bean> 

2) 持久化類設計如下所示:

在 com.bakrestore.server.model 資料夾中包含 FileNode, FolderNode,UserFile,DatabaseFileContent,FileSystemFileContent,UserFileContent,UserSpace 的一些類 , 他們的作用是:

  • DatabaseFileContent:用資料庫儲存檔案內容的檔案內容實體類
  • FileSystemFileContent:用檔案系統的儲存檔案內容 實體類
  • FileNode:檔案結點,與 FolderNode 一起構成了檔案目錄樹
  • FolderNode:目錄節點
  • UserFile:使用者檔案或資料夾實體類
  • UserFileContent:使用者檔案內容實體類 , 抽象類
  • UserSpace:使用者備份空間實體類

類圖以及他們工作機制如下所示:


圖 11. 網路備份恢復持久化類設計圖
圖 11. 網路備份恢復持久化類設計圖 

3) 應用類 :

應用類主要用來響應手機發出的 HTTP 請求訊號,在 com.bakrestore.server.web 資料夾主要包含 CreateSpaceController,DownloadController,ErrorCode,BaseController,RequestParamater,UploadController,UploadQueryController 等一些控制器,他們的作用分別是:

  • CreateSpaceController:建立使用者空間
  • DownloadController:用以檔案下載
  • ErrorCode:錯誤訊息封裝類
  • BaseController:備份恢復系統中 Controller 的公共類,定義了通用的變數和方法
  • RequestParamater:引數解析類
  • UploadController:檔案上傳服務類
  • UploadQueryController:查詢已上傳檔案部分的大小

以下是他們之間的工作機制:


圖 12. 網路備份恢復應用類設計圖
圖 12. 網路備份恢復應用類設計圖 

4) DAO 類

  在 dao 資料夾包含 PbsDataAccessException,UserFileContentDAO,UserFileDAO,

UserSpaceDAO 四個 interface,他們的作用分別是:

  • PbsDataAccessException:資料庫操作異常,所有對資料庫的操作都要丟擲此異常
  • UserFileContentDAO:對檔案內容存取的 DAO 介面
  • UserFileDAO:對檔案資訊存取的 DAO 介面
  • UserSpaceDAO:對備份空間資訊存取的 DAO 介面

 以下是他們之間的工作機制:


圖 13. 網路備份恢復 DAO 類設計圖
圖 13. 網路備份恢復 DAO 類設計圖 

5) 業務邏輯類

在 service 資料夾包含 FileContentService,FileService,SpaceService 三個 interface,他們的作用分別是:

  • FileContentService:對檔案內容進行操作的介面
  • FileService:對檔案進行操作維護的介面
  • SpaceService:對手機備份空間進行維護的介面

 以下是他們之間的工作機制:


圖 14. 網路備份恢復業務邏輯類設計圖
圖 14. 網路備份恢復業務邏輯類設計圖 

6) 資料庫層設計

資料庫層設計及相互關係表示如下:


圖 15. 資料庫關係圖
圖 15. 資料庫關係圖 

表 6. 使用者儲存空間表 UserSpace
欄位名型別描述備註
id Integer 儲存空間 ID 主鍵,系統生成
userID Integer 使用者 ID FK( 邏輯外來鍵 )
deviceID Varchar(16) 裝置 id FK
rootPath Varchar(256) 根資料夾 僅當檔案儲存在檔案系統時有效
spaceType Char(1) 型別 0- 裝置備份空間,1- 普通備份空間
maxSize Integer 最大空間大小
usedSize Integer 已使用空間大小
directionStruct LONGTEXT 目錄結構 xml
directionStructMD5 Char(32) 目錄結構 xml 的 MD5 驗證碼
createSystemTime DateTime 建立時間 系統生成


表 7. 使用者上傳的檔案表 UserFile
欄位名型別描述備註
id Varchar(32) 檔案 ID 主鍵,系統生成
userSpaceID Integer 儲存空間 ID FK, 使用者儲存空間表的主鍵
fileName Varchar(128) 檔名
createSystemTime DateTime 建立時間 系統生成
modifySystemTime DateTime 修改時間
fileType Char(1) 型別 0 - 資料夾 1- 檔案
MD5 Char(32) Md5 驗證碼 fileType =1 時有效
fileSize Integer 檔案大小 fileType =1 時有效
storageName Varchar(128) 檔案在磁碟上的名稱
fileDesc Varchar(512) 檔案描述
uploadState Char(1) 上傳狀態 0:未完成 1:已完成 
fileType =1 時有效
uploadedSize Integer 已上傳部分大小 fileType =1 時有效
Content MEDIUMBLOB 檔案內容 fileType =1 時有效

網路備份與恢復客戶端設計與實現

1) 網路備份恢復客戶端的流程

網路備份恢復客戶端流程圖與圖 3 類似,所不同的是使用者選擇網路 Backup 或 Restore,讓後向 Contacts 傳送廣播訊號,如果 Contacts 準確收到廣播訊號後,開始執行 Backup 或 Restore 操作,完成後反饋操作結果。

2) 網路備份恢復客戶端的序列圖:

在序列圖中,客戶端選擇網路備份或恢復後,傳送廣播訊息通知 Contacts 應用開始備份或恢復 (ContactsReceiver 根據訊號類別 : 備份 / 恢復進行操作 ),如果是網路備份則將自身的資料庫檔案上傳到網路備份伺服器;如果是網路恢復將網路伺服器中使用者對應的檔案寫到 Contacts 應用對應的路徑下,用以覆蓋原始資料庫檔案。


圖 16. 網路備份恢復客戶端時序圖
圖 16. 網路備份恢復客戶端時序圖 

3) 網路備份與恢復客戶端的實現

網路備份與恢復客戶端的實現部分見圖 5。使用者選擇網路備份或網路恢復,ContactsReceiver 則收到廣播訊息後,根據訊號判斷操作的類別是備份還是恢復,然後啟動一個執行緒,線上程中呼叫 Handler,在 Handler 呼叫服務端介面,操作完成後根據返回的 HTTP 頭資訊,如果等於 200 提示使用者操作成功;如果大於 200,根據 Code 中的 MSG 轉態碼 ( 見表 2,3,4,5) 提示相應的失敗資訊。

總結與展望

資料備份恢復的設計與實現,詳細講解了一種備份恢復通訊錄中資料庫檔案的方法,儲存方式有兩種,一種是直接儲存在本地,另一種是通過與伺服器的互動,儲存在網路伺服器中;備份到 SDcard 或網路伺服器中的通訊錄檔案,由於每次備份時都會自動建立一個以日期時間命名的資料夾,所以可以備份 n 次而不會覆蓋。

但是這些還不夠完善。從廣度來說,如果能做到隨意新增需要備份的 android 應用;如果資料能以 VCARD 格式儲存,以方便將資料匯出到 PC 中;如果能管理已備份的檔案,比如更改備份檔名稱、刪除已備份檔案等。從深度來說如果能實現資料的增量備份,可以有效改善由於儲存容量有限所帶來的問題;如果能通過加密解密實現網路備份資料共享,從而實現不同手機之間下載資料,例如日程應用在對方允許的情況下獲知對方密匙後,下載另一使用者的日程,這樣就可以更加方便的瞭解對方,那功能將會更完善。

移動網際網路是一個剛剛興起的市場,越來越多的公司和開發人員把 PC 時代的網際網路產品引入到手持裝置上來。嵌入式硬體效能的不斷提升,以及軟體平臺的層出不窮,更是為這個新領域的發展奠定了基礎。Android 系統就是在這樣的條件下出現的,它完全開源免費,允許生產商隨意定製自己的作業系統和軟體商店,搭建自己的平臺,將每個公司自己的互動理念推向使用者,力求用極致的使用者體驗來搶佔市場。雲端計算是當下很流行的一種服務模式,該模式在移動網際網路領域將會有很大的發展,因為它徹底解放了手持裝置,讓手持裝置的資源有限、電量有限等特點不再成為阻礙其發展的短板。作者認為 Android 系統將會在移動網際網路有比較廣泛的應用。