Android群  - 讨论区

标题:基于 android 数据备份恢复的一种实现

2010年10月18日 星期一 14:21

随着 3G 时代的到来,移动互联网的发展,手机的功能越来越强大,手机里的数据对每个用户来说都非常的重要,特别是通讯录、日程、短信息、邮件等数据,一旦手机丢 失、误删或其他意外使得数据无法正常使用,会给用户带来麻烦,数据备份与恢复这个应用可以帮助用户解决这个问题。

本文主要论述了基于 Android 平台所提供的开发框架和应用组件,并给出了一种数据备份恢复的设计与实现。

当前流行的智能手机操作系统有 Windows Mobile,Symbian,iPhone OS,Android 等。本文基于目前最热门的 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 =
           
            new
           
           IntentFilter(); 
     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 检查到输入参数不合法,会中断服务并通知客户端。

接口定义:

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. 网络备份恢复下载序列图
图 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. 网络备份恢复创建存储空间序列图
图 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. 网络备份恢复查询已上传部分序列图
图 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. 网络备份恢复持久化类设计图
图 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 系统将会在移动互联网有比较广泛的应用。

如下红色区域有误,请重新填写。

    你的回复:

    请 登录 后回复。还没有在Zeuux哲思注册吗?现在 注册 !

    Zeuux © 2024

    京ICP备05028076号