User:Ben King/Temp/Sns sdk design.odt
SNS多帐号SDK设计方案
撰写人:方宁
时 间:2013年1月16日
一淘无线事业部-技术研发
修订记录
时间 | 版本 | 作者 | 修订内容 |
2013年1月16日 | V0.1 | 方宁(王斌) | 创建文本 |
- 概述
-
- 设计背景
本设计以一淘逛街项目需求为基础,综合考虑可扩展性和稳定性需求,以高内聚低耦合为要求,形成相对独立的SNS多帐号的SDK。
当前阶段考虑较多的是可扩展性,对于与已有SDK的接驳(如RichView等控件)尚未考虑。后续将在具体实现中加以优化。
-
- 需求分析
[[Image:]]
当前逛街项目只支持新浪微博账户与推推账户,且同一类型账户不能登陆多个帐号,故账号之间的关系相对简单,不需要做过多处理。
与上层界面之间的 DataLogic 、 RichView 之间的配合后期可通过适配层实现。
-
- 功能需求汇总
- 账号管理功能
- 功能需求汇总
- 新增账号
- 主账号管理
- 删除账号
- Token过期处理
-
-
- 登录功能
-
- OAuth登录
- SSO登录
-
-
- 任务队列功能
-
- 可定制的重试策略
- 任务优先级
-
-
- 缓存管理功能
-
- 分为缓存管理和持久化两方面需求
- 缓存管理方面,要求缓存策略可定制
- 持久化方面,要求可以动态扩容,可以保存到文件
- 概念
- 可插入式多账户支持
可扩展性主要考量的方面。当前的实现还不能实现运行时动态加载插件,但已经为这种功能留有余地。当前可以实现加入一种新的账户类型不需要修改SDK层及以上代码。
请参见类图类图。
-
- 缓存机制
缓存策略可定制,并实现简单的LRU策略
持久化方面相关需求
-
- 同步/异步接口
对于牵涉到网络的请求,提供同步和异步的接口供上层使用。
-
- 账号过期的全局Observe机制
提供全局的Observer机制,token过期、失效的全局通知
-
- 敏感信息的加密存储
目前以固定key简单加密。后续可考虑可运营的服务器提供动态KEY的方式加密敏感数据。
- 类图
- 账号管理相关
[[Image:]]
AccountManager是整个SDK实现中最核心的模块。它的主要功能有:
- 【API】添加账号;
- 【API】登录
- 【API】删除帐号
- 【API】设置主账号
- 【API】删除帐号
- 【API】获取已登录帐号信息
- 【API】获取主账号信息
- 管理Token有效期
- 通知账号状态变化(如账号被删除、账号token失效等)
-
- 新账户插件实现机制
[[Image:]]
如果要增加一种账号类型的支持,只需要实现以下几个抽象类即可。
- AccountHandler
- AccountLoginHelper
- AccountInfo(可选)
- UserInfo(可选)
- MessageHandler(可选,如有发消息功能则实现)
- ChainHandler(可选,如有关系链相关功能则实现之)
-
- 任务队列相关功能
[[Image:]]
这是一个通用任务队列的设计。
使用者将需要加入队列的工作封装进Task的run中,让后调用TaskQueue的addTask()接口,该任务便会自动被调度运行。也可以指定任务失败后的重试策略,任务失败后将按照该重试策略调度重试。
在任何时候,都可以通过Task的cancel()接口取消该任务(运行时打断需要Task的run()支持)。
-
- 缓存管理
[[Image:]]综合
-
- Timeline管理
基本同关系链管理。
- 主要功能时序图
- 登录过程
以微博账号登录为例:
[[Image:]]
当上层应用需要登录微博时,需要首先判断微博账户类型是否被支持,如果被支持的话,则调用AccountManager的login接口发起登录流程。此时WeiboAccountHandler会判断该手机是否已安装支持微博SSO的新浪微博客户端,如果有,则进入SSO登录流程,如果不支持则通过Webview显示网页OAuth版的登录界面,获取相关票据后返回,并回调通知调用者。
-
- 发微博过程
[[Image:]]
当应用需要广播微博消息时,先通过AccountManager获取已登录的账号列表,从中取得我们想用的账号信息,将该帐号信息传给MessageHelper,由MessageHelper选取合适的MessageHandler对象,具体操作发送该消息的过程,并将发送的结果(成功或失败)回调通知调用者。
-
- 获取粉丝列表过程
[[Image:]]
- 其它
- 安全机制
AccessToken等敏感信息本地通过SharedPreference保存,但需要进行加密。目前考虑的加密方式是,静态KEY的XOR加密,并通过BASE64编码后保存。
由于当前不考虑应用间账号共享的需求,故跨进程共享登录态暂时不做考虑。
-
- 性能机制
关系链和Timeline等信息,数据量较大,且一次返回数据条数有限,故需要统筹调度拉取请求,配合预取机制和Cache机制,以降低系统负载并提高响应速度。
-
- 鲁棒性相关考量
- 异常处理
- 鲁棒性相关考量
- 网络异常,回调通知上层调用者,并可配合自动重试策略。
- OAuth时,可能会面对各种异常,如页面错误,循环重定向等,需要做好防范。
- 所有的请求随时都可能遇到AccessToken失效的问题,需要及时处理。
-
-
- 运营需求
-
1,与UserTrack配合做好日志管理。