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

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

我的分享到此结束,谢谢大家!

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2017-07-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小怪聊职场

爬虫课程(十三)|ajax分析法(雪球),通过获取api并破解api的反爬策略爬取数据

4569
来自专栏大史住在大前端

webpack4.0各个击破(10)—— Integration篇

webpack在工具链中的角色定位是非常清晰的,那么为了与其他流程进行合作,就需要使用任务管理工具来启动webpack,本文介绍两种常见的方法。

1033
来自专栏顶级程序员

千万千万不要运行的 Linux 命令

来源:Linux 中国 https://linux.cn/article-401-1.html 文中列出的命令绝对不可以运行,即使你觉得很好奇也不行,除非你是...

3688
来自专栏CSDN技术头条

【问底】徐汉彬:亿级Web系统搭建——单机到分布式集群

大规模流量的网站架构,从来都是慢慢“成长”而来。而这个过程中,会遇到很多问题,在不断解决问题的过程中,Web系统变得越来越大。并且,新的挑战又往往出现在旧的解决...

26310
来自专栏架构师小秘圈

高并发场景下缓存的常见问题

作者介绍: 丁浪,非著名架构师。关注高并发、高可用的架构设计,对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。 声明:版权...

4517
来自专栏携程技术中心

RN沙龙 | 携程是如何做React Native优化的

赵辛贵,携程无线开发高级技术经理,目前主要负责React Native框架在携程内部的使用推广和性能优化 React Native(下文简称RN)开源已经一年...

9829
来自专栏JAVA高级架构

大型网站技术架构

早期的网站为了节省成本一般会设计成集中式系统,应用程序、数据库等都部署在一台服务器上。 但随着业务的快速度发展,逐渐出现瓶颈,按一定原则**(应用拆分、服务拆分...

3866
来自专栏企鹅号快讯

千万千万不要运行的 Linux 命令

来源:Linux 中国 https://linux.cn/article-401-1.html 文中列出的命令绝对不可以运行,即使你觉得很好奇也不行,除非你是在...

3997
来自专栏IT大咖说

分布式内存数据库新架构,极速OLTP应用新利器

内容来源:2018 年 11 月 10 日,Oracle 数据库首席产品经理杨琳在“2018 SOUG年度数据库技术峰会”进行《Oracle TimesTen ...

2452
来自专栏Java后端技术栈

大型网站技术架构总结一二

早期的网站为了节省成本一般会设计成集中式系统,应用程序、数据库等都部署在一台服务器上。 但随着业务的快速度发展,逐渐出现瓶颈,按一定原则**(应用拆分、服务拆分...

1392

扫码关注云+社区

领取腾讯云代金券