工作以来一直负责自己公司的账户平台的开发与维护,也接入过谷歌,Facebook,微信,QQ,微博,360各家平台的账户SDK,现在记录下账户平台应该实现的功能模块,大致思路,以及遇到的坑
主要内容
- 登录方式考虑:支持多种方式登录 单点登录,授权方式登录,默认方式登录
- 对外接口设计考虑:接口简单,易于理解
- 第三方接入考虑:接入方式简单,便于操作
- 日志打印,定位问题
- 遇到的坑
登录方式考虑:
单点登录必须牵扯多进程数据交互,通常考虑通过aidl,startActivityForResult,ContentProvider,settings数据库等方式中的一种或者多种来实现
- aidl 推荐使用该方式,第三方集成账户SDK的应用通过aidl接口访问账户服务调用相关接口来实现单端登录 (账户服务可以是一个或者多个,一个的话集成账户SDK的应用固定的调用一个包名中的服务去获取数据,如果是多个可以通过某种算法(数据写入实现,最近更新时间等方式)固定每次选择到同一个包名中的服务来获取相关该数据)我觉得百度现在应该通过多个应用中都有账户服务的方案来实现的,他没有一个用户量很大的应用,并且每次登录时会告诉你 你的账号信息是从哪个应用读取来的
- startActivityForResult 通过startActivityForResult方式拉起账户应用,来获取相关的数据实现单点登录,实现效果类似于QQ登录 通过startActivityForResult的方式,在onActivityResult中获取返回的数据
- 通过ContentProvider对外提供数据,第三方集成账户SDK的应用可以获取到数据
- 通过settings数据库实现,第三方集成账户SDK的应用需要登录账号时先去看下setting数据库中有没有相关的数据,有的话就去使用该数据去进行相应的操作,需要注意读写权限的控制,哪些应用具有写权限,哪些应用具有读权限 最简单的实现方式 最不推荐的实现方式,Android6.0以后setting数据库权限控制的比较严了,存在应用卸载安装后账户数据依旧存在的问题(有的设备厂商还正需要该功能)
对外接口设计考虑:
- 接口设计必须做到少而精 见名知义
- 主要接口设计考虑
- 内部应用登录使用login(Activity,Bundle,Handle,OnListener()),接口中所有的操作对外不可见,读取本地登录票据数据,校验本地登录票据合法性,使用系统票据生成本地票据等操作,一把完成登录所有流程
- 外部应用使用getAuthCode(Activity,Bundle,Handle,OnListener()),外部应用一般走Oauth2协议,获取到临时授权码,再通过服务器获取票据
- 其余接口设计考虑
- Token合法性校验
- 用户信息获取
- 支付相关业务
第三方接入考虑
- 现在对外提供SDK一般有三种方式
- aar 最新 最好 最简单的方式 但是好多应用因为历史原因,不能使用aar的SDK 新版本SDK建议使用该方式 别人集成简单呀 权限,Activity,广播啥都不需要声明 直接调用接口就行
- lib工程的方式 资源放在res目录 重要代码写成jar放在lib工程的lib目录下,其余代码可以在src中 不牵扯到代码保密的话也可以
- jar包的方式 如果提供的SDK有界面 需要将界面资源 字符串资源 图片资源特殊处理 流程比较复杂 第三方应用还需要在自己的AndroidManifest中声明相关东西,但是不需要对外提供任何代码 保密性比较好,总之不推荐使用
日志打印,定位问题
这是所有应用必须考虑的问题,好的日志打印应该满足一下要求
- 错误日志需要打印出上下文 不是告诉你程序在这里错了 需要通过日志可以看出为什么错了
- 日志在于精,并且不能多,打出有用日志
- 日志的格式进程号,线程号,代码执行的行数 (TAG,”[parameter1 : “+parameter1+”][parameter2 : “+parameter+”] methodname result : (result1,result2,result3)”)
遇到的坑
- 接口设计 界面相关的必须用Activity不能用Context 坑坑坑啊~
- 票据分类 不同票据访问权限控制 根票据 应用票据 临时票据 临时授权码
- AndroidManifest配置检查 有的第三方不按照文档声明Activity 广播 权限 需要做声明检查 将问题在开发阶段就暴露出来
- 需要使用任何第三方库 v4 httpclient eventbus等 你用了其中的东西 有的第三方应用不使用,使用的是自己修改后的,使用的跟你的版本不一致;存在很多未知问题