移动端SDK优化的特点与经验分享

摘要

结合极光的业务和自身开发经验，极光高级Android工程师为我们简单介绍移动SDK与APP的区别，以及在做架构设计、性能优化上的一些经验。

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下发的地址。然后写一些选择的策略，优先选择可用的，排除不可用的。

在接入服务这部分，会把当时的状况上报给服务器，让服务器根据这些上报的数据反馈做调整。

我的分享到此结束，谢谢大家！