随着移动设备终端用户数逐渐增多, 基于云服务的应用也越来越多, 微信, 通讯录同步等. 云计算SAAS模式在未来会有广阔的发展空间, 最近做了个OTA项目, 包含三个子项目, 客户端升级程序, 服务端同步平台和升级包管理平台. 下面结合实际, 讲下OTA服务端同步平台的实现.
1. 先说下业务背景需求, OTA可以自动或手动升级, 需要支持FU(系统固件)和AU(应用程序)的升级.并且可以进行后期的数据统计, 如激活的终端设备数量, 哪些成功升级, 每个升级包的执行情况等等. 我们只讲和主题相关的业务, 先明确升级包的匹配策略, 每个机型会有不同的升级包, 硬件版本, 内核版本, 系统版本, IMEI等都是作为升级的判断依据, 以及如何找寻最新的升级包, 版本号的比较规则, 是否逐次升级, 等等很多因素, 都需要确立, 这样, 明确好整体方向之后, 就能少走些弯路.
2.进入开发, 对SYNCML协议的了解不一定要求很深入, 但必须得有个全面了解, 接触任何新技术都一样, 先要知道哪些该用, 哪些不该用, 明确方向, 开发起来就会比较顺手, 不要一头扎进细节中, 如果天黑摸路, 是存在很大风险.
3. 照搬引进一个框架是存在一定风险, 最好做到最小改动, 最大掌控, 所以funmbol, 只引用了其中的一部分代码, 集中在指令转换, 协议流程处理, 这些是规范, 可以直接照搬, 主要修改的是数据层和业务层的改造, 数据层ORM使用的是IBATIS, 除了协议要用到的, 大部分表都修改了.业务层并不复杂, 不像其他的项目, 分为很多功能, 这里主要是处理升级包的匹配, 执行统计和日志记录. 日志记录可以协助数据统计, 但funmbol没有提供详尽的日志功能, 日志的修改, 要切入很多地方, 会占据很多的开发时间.
一、接下来看看改造后的交互流程图, 项目中还有很多细节的处理, 如加密, 邮件通知,异常处理等, 这里列出的是主要的交互流程, 请看图1:
图1
从宏观角度来看, 主要分为四个流程: 初始化, 协议处理, 业务处理以及会话结束. 重点是在协议和业务处理中, 这里要用到缓存机制, 每次新的请求会建立一个缓存, 下次请求就能快速响应, 建立缓存的另外一个作用, 是用来标识交互所处的步骤, 是第几步, 第几次请求, 该返回怎样的数据给你, 因为移动终端是不稳定的, 可能网络中端, 系统崩溃, 死机, 异常等, 这些都需要有个很好的容错机制, 而把状态缓存, 就能很好的实现.
一次升级交互, 大致分为四次请求: 检查更新, 获取升级包, 响应执行结果, 握手结束. 如果第一次请求, 检查发现, 没有可用的更新, 则服务端会发送418指令给客户端, 同时结束会话. 发现可用的更新后, 服务端会把升级包的描述信息和下载地址发送给客户端, 客户端接收后, 再根据地址下载升级包, 下载成功后, 客户端会再次发送请求, 通知服务端下载成功,
服务端接收请求后, 返回Update执行指令给客户端, 客户端接收指令后, 再执行升级, 而不是下载完升级包后直接执行, 这样我们就能很清楚的掌握客户端的升级情况. 客户端正确升级后, 再发送200成功指令给服务端, 服务端再响应给客户端, 这样一次完整的交互就结束了.
二、知道整个处理流程&＃xff0c; 再看看是通过那些类实现的&＃xff0c; 彼此是怎样的一个关系&＃xff0c; 我把主要的一些类给画了出来&＃xff0c; 请看图2&＃xff1a;
图2
入口是一个servlet, 通过DMService调用SyncAdapter, 并建立缓存, 通过SESSIONHANDLER去处理每次交互的不同请求, DMSyncHandler是处理升级包信息的业务接口, 可以匹配获取FU/AU升级包, 这里是把所有的升级包信息缓存至内存, 根据实际业务, 可用的升级包数量不会很多, 而请求的客户端数量却会有很大的并发量, 如果每次都去查询数据库, 会有很大的压力, 影响效率, 所以, 做了相应的优化. 日志记录主要是记录交互步骤, 交互类型, 处理状态, 还有升级包的信息, 主要是为了做数据统计, 详尽的日志信息, 能够帮助你快速定位错误, 解决问题, 尽量考虑周全些, 把有价值的信息记录下来.
三、再看下数据库的设计&＃xff0c; 和funambol自带的数据库有很大的改动, 这里主要是以实际业务需求进行设计的, 看下主要的结构, 如图3所示:
图3
一个用户可以关联多个设备, 以用户和设备关联作为唯一标识, 展开业务关联, 升级包分为固件升级包和应用升级包, 固件升级包可单独作为一个实体, 应用升级包由两张表构成, 包含一对多的关系. 日志信息记录包含三张表, 分别记录设备的交互状态, 同步的升级包信息和交互错误信息, 可以满足数据统计和日常维护. 有些统计报表会比较复杂, 如设备的升级执行情况, 升级了哪些包, 还有哪些包没有升级, 升级包的完成率是多少, 还有哪些设备需要升级. 这些需要视图去解决, 设计的时候, 可以着重考虑下报表所需要的信息, 增加或改造表结构.
所有内容就介绍到这里, 有些东西并不复杂, 只要自己肯花功夫去研究, 接触理解之后, 就会觉得这一切都很简单.
基于SyncML的funambol dm开源项目的改造应用系列就已经讲完了, 如果转载, 请注明出处, 本文在CSDN首发, 谢谢!
如果需要详细资料可以申请加入开发者联盟群19310171
京公网安备 11010802041100号