内容来源:2017年5月25日,极光高级Android工程师王可为在“极光开发者沙龙”进行《移动端SDK优化的特点与经验分享》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。
阅读字数:2098 | 4分钟阅读
SDK和APP的差别
重复造轮子
我们做APP开发的有这样一句话:“不要重复造轮子。”意思就是希望快速迭代,每个APP有自己独有的功能。基础业务可以直接用别人已经做好的框架或第三方的包导入进来,但业务代码一定要做自己独有的。
在体积大小上,SDK和APP就有明显差异。APP的核心代码只需做上面一小块,但这样做的结果是一个APP本身大小有几十兆甚至一百多兆,用户可以接受。而SDK需要做得小,体积在几百K以内,才是开发者能接受的。
所以SDK不能直接用别人的“轮子”。做基础业务的话,像网络、数据库可以用Android原生的API来做,这样能把体积控制在较小的范围内,APP开发者才会用较小的包去做他们的业务。它的好处就是保持代码的精简,并且内部可见,方便调试和修改。
为了体积,以及优化架构和性能上,我们要“重复造轮子”。
配置
APP只需要开发者根据自己的需求写一份配置列表。
SDK的权限则是交给开发者,开发者具体用的什么权限或版本,我们是无法控制的,只能通过指引说明的形式告诉他们如何配置。
所以我们要考虑配置做到尽量简便、友好、灵活。
升级
一个APP如果要升级,开发新版本上架到应用商场把它替换下来,或是推送更新通知,保证用户较快地用到新版本,同时在线版本范围比较小,老版本占有率慢慢降低。
而SDK不是直接上架市场,是需要开发者主动去拿文件,集成到自己的工程,再上架到市场。有些开发者几个月之后才做更新,甚至有的从不更新,这个情况导致同时存在很多个历史久远的老版本,这个问题会要求我们做很多兼容性的考虑,所以可靠性和性能考虑的份量是比新功能要重的。
极光SDK的架构优化
旧架构
2016年之前极光推的主要是两个SDK,一个是Jpush,一个是JMessage。
旧架构的推送跟IM是两个独立的SDK,存在很多种冗余代码。缺点是占用空间大,有重复操作,占用了通道和线程资源,还有就是冗余代码的升级管理非常麻烦。
新架构
我们在拓展业务后还新增了统计和分享,针对多条业务线的考虑,我们做了架构调整,把业务跟核心做了分层。
JCore负责核心通用的功能,上层SDK各自在JCore之上运行自有业务,使结构更加清晰,利于拓展共享资源,减少重复动作,针对性做基础优化更加方便。
实际开发中需要考虑的
在和服务器通信的时候,从协议的制定上要考虑兼容不同的组件和同时在线的不同版本。在代码设计上涉及到的策略类要采取策略模式,方便替换更优策略。
核心组件和上层的组件拆分成两个,针对升级不同步的问题需要有更多的接口,要简洁,适应变化。
以及关于各个组件之间的通信,通过命令模式,把动作抽象成为可传出的对象,实现分发和缓冲。
在Android开发的工程设计中,由于被拆分为两个包,一些接口难免会暴露出来,但是为了起到保护代码的作用,又不能完全暴露。所以在方便和保护之间要做取舍权衡。
因为引入了很多组件,在打包、编译脚本的时候可以用到Jenkins+Gradle,编写脚本,做集成,可以自动打出多个包。
极光SDK的性能优化
多进程与多线程
多线程是语言的基本功,通常情况业务是在主线程执行,但是在移动端主线程任务过重会卡顿影响到用户体验,要尽量克制。所以在占用资源比较多、耗时的情况下要另外多开一个线程。
在Android应用的设计理念上,进程是非常宝贵的资源,它尽量不把进程管理交给开发者,而是让系统去处理。
如果是单进程的应用,做的任务很多,内存占用数高,派多个进程可以分担上面的一部分任务资源到另一个进程,避免占用资源太高被回收。另外一个好处是,在后台跑的主进程因为一些无法预测的原因被系统回收掉了,在主进程的任务依然可以继续执行下去。
开了多进程以后内存空间是独立的,可能在主进程是初始化的,但在子进程上未被初始化。写代码的时候没有意识到,在运行的时候就出乎意料了。这就是数据不同步会造成的问题。
数据不同步是主进程和线进程都能遇到的问题,如何巧妙利用它的性能又不出错,我个人经常用双重检查锁,看上去代码更复杂,但有利于性能更好地运行,并且不容易出现数据不同步的问题。
由于变量在多进程时是不同步的,所以跨进程共享的变量,需要通过进程间通信的机制,把变量的读和写均放到同一个进程中,虽然会带来一点性能损耗,但是这样才能保证数据正确性。
储存方式
同一个进程下,可以做一次读取多次使用。
写的操作可以批量提交。
使用内存级别储存,响应更快。
跨进程的批量读取和提交。
拆分存储区。
长链接优化
我们做极光推送,推送主要的任务都是在长链接里。客户端和服务器进行通讯,先要进行接入服务。
我们有一个SIS服务,就是另外开辟服务器去找当时的设备,它介入哪一个IP,接入哪个端口有更快的响应,我们会下发一个列表给客户端,让它们自己去尝试。
要做性能优化,可以先把列表缓存在本地,如果失败了再用SIS下发的地址。然后写一些选择的策略,优先选择可用的,排除不可用的。
在接入服务这部分,会把当时的状况上报给服务器,让服务器根据这些上报的数据反馈做调整。
我的分享到此结束,谢谢大家!
编者:IT大咖说,欢迎关注“itdakashuo”,@IT大咖说 ,转载请标明版权和出处。