Android教程網 >> Android系統教程 >> 系統備份 >> android 數據備份恢復（二）

android 數據備份恢復（二）

編輯：系統備份

網絡備份恢復

服務器端設計與實現

網絡備份通過 WiFi 或者 GPRS 在手機端與服務器進行連接，服務器提供相應的接口，用於上傳或下載文件。

服務器端用例分析

1) 備份數據上傳：響應客戶端的 backup 功能。文件通過 HTTP 請求提交到服務器，服務器接收文件並保存，序列圖表示如下：

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

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

接口定義：

URL：https://<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. 網絡備份恢復下載序列圖

流程描述如下：

客戶端向服務器發送 requestDownload 請求，請求中包含文件的 uuid 和斷點續傳的起始點。
Servlet 調用 downloadSavedFile 接口 , 傳遞文件 uuid 和 range 參數。
數據庫存取返回自 range 開始的字節流，字節流返回給前面的 servlet。

接口定義：

URL：https://<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. 網絡備份恢復創建存儲空間序列圖

接口定義：

URL：https://<server>:<port>/createspace?deviceid=< 終端的 id>

參數含義同備份數據上傳。

表 4. 創建存儲空間返回值：

成功

HTTP 頭 HTTP Body 200 空

失敗

HTTP 頭錯誤碼 HTTP Body （XML 格式的錯誤消息） Code Message 400 MSG-1003 備份空間已建立 400 MSG-1004 新建備份空間失敗

4) 查詢已上傳部分的大小：當文件上傳中斷時，可以查詢已上傳部分的大小，然後斷點續傳余下部分。序列圖表示如下：

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

接口定義：

URL：https://<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. 網絡備份恢復持久化類設計圖

3) 應用類 :

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

CreateSpaceController：創建用戶空間
DownloadController：用以文件下載
ErrorCode：錯誤消息封裝類
BaseController：備份恢復系統中 Controller 的公共類，定義了通用的變量和方法
RequestParamater：參數解析類
UploadController：文件上傳服務類
UploadQueryController：查詢已上傳文件部分的大小

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

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

4) DAO 類

　　在 dao 文件夾包含 PbsDataAccessException，UserFileContentDAO，UserFileDAO，

UserSpaceDAO 四個 interface，他們的作用分別是：

PbsDataAccessException：數據庫操作異常，所有對數據庫的操作都要拋出此異常
UserFileContentDAO：對文件內容存取的 DAO 接口
UserFileDAO：對文件信息存取的 DAO 接口
UserSpaceDAO：對備份空間信息存取的 DAO 接口

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

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

5) 業務邏輯類

在 service 文件夾包含 FileContentService，FileService，SpaceService 三個 interface，他們的作用分別是：

FileContentService：對文件內容進行操作的接口
FileService：對文件進行操作維護的接口
SpaceService：對手機備份空間進行維護的接口

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

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

6) 數據庫層設計

數據庫層設計及相互關系表示如下：

圖 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) 上傳狀態０：未完成１：已完成
fileType =1 時有效 uploadedSize Integer 已上傳部分大小 fileType =1 時有效 Content MEDIUMBLOB 文件內容 fileType =1 時有效

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

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

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

2) 網絡備份恢復客戶端的序列圖：

在序列圖中，客戶端選擇網絡備份或恢復後，發送廣播消息通知 Contacts 應用開始備份或恢復 (ContactsReceiver 根據信號類別 : 備份 / 恢復進行操作 )，如果是網絡備份則將自身的數據庫文件上傳到網絡備份服務器；如果是網絡恢復將網絡服務器中用戶對應的文件寫到 Contacts 應用對應的路徑下，用以覆蓋原始數據庫文件。

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

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

網絡備份與恢復客戶端的實現部分見圖 5。用戶選擇網絡備份或網絡恢復，ContactsReceiver 則收到廣播消息後，根據信號判斷操作的類別是備份還是恢復，然後啟動一個線程，在線程中調用 Handler，在 Handler 調用服務端接口，操作完成後根據返回的 HTTP 頭信息，如果等於 200 提示用戶操作成功；如果大於 200，根據 Code 中的 MSG 轉態碼 ( 見表 2,3,4,5) 提示相應的失敗信息。

總結與展望

數據備份恢復的設計與實現，詳細講解了一種備份恢復通訊錄中數據庫文件的方法，存儲方式有兩種，一種是直接存儲在本地，另一種是通過與服務器的交互，存儲在網絡服務器中；備份到 SDcard 或網絡服務器中的通訊錄文件，由於每次備份時都會自動創建一個以日期時間命名的文件夾，所以可以備份 n 次而不會覆蓋。

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

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

上一頁:android 數據備份恢復（一）
下一頁:Recovery備份安卓系統教程

系統備份

Android開發教程 Android手機系統教程 Android教程綜合系統備份系統故障安卓省電與加速

相關文章