Android SDK开发随想录

之前有许多朋友都给我留言，让我提供一个搜索的功能，说想找公众号以前推送的文章太累了。不过这个我确实没有办法，因为微信公众号并没有提供搜索功能。但是为了大家方便查找以前的文章，我在这个双休对文章进行了一次比较细致的分类，提供了一个分类浏览的功能。现在大家只要点击公众号主页的 历史文章 -> 分类浏览 ，就能按照类别来查看之前推送过的文章了。

大家早上好，新的一周开始了！本篇来自 江湖人称小白哥 的投稿，阐述了他对SDK开发的见解。相信本文对那些对SDK开发感兴趣的朋友有很大帮助！

江湖人称小白哥 的博客地址：

http://blog.csdn.net/dd864140130

自从前段时间离职后,因为个人的事情一直没有选择再工作,也导致原有的文章并没有按时产出.最近个人的事情整理的也差不多了,恰好有不少朋友来问有关SDK开发方面的事情,在此就做个简单的梳理,希望能帮助各位.

目前更多开发者热衷于应用开发,极少数的开发者才有机会从事SDK开发工作,而市面上关于SDK开发介绍的文章少之又少,以至于让大家觉得SDK开发是相对比较难而且非常无聊的工作,今天我们就来简单的聊聊SDK开发的哪点事.

什么是SDK

在开始正文之前,首先来聊聊 SDK 是个啥玩意.

SDK 是 Software Development Kit 的缩写,译为”软件开发工具包”,通常是为辅助开发某类软件而编写的特定软件包,框架集合等,SDK 一般包含相关文档,范例和工具.

SDK 可以分为 系统SDK 和 应用SDK.所谓的 系统SDK 是为特定的软件包,软件框架,硬件平台,操作系统等简历应用时所使用的开发工具集合.而 应用SDK 则是基于 系统SDK 开发的独立于具体业务而具有特定功能的集合.

比如在进行 Android 应用开发时,我们使用 Google 提供的 系统SDK(Android SDK),而我们经常使用的 友盟SDK,极光SDK 则是基于 系统SDK 开发的.

明确 SDK 的概念之后,再来聊一聊这三个概念 :Library, API, Framework

什么是Library

Library 即我们所说的库,通常是一组或者几组类的集合,通常是应用中某些功能的具体实现或者对系统已有功能的增强或补充.对 Android 开发者而言,最常见的莫过于是 Support Library ,另外就是我们经常使用各种网络请求库( OkHttp , Volley ),数据库操作,图片加载库( Glide , ImageLoader )等.

什么是Framework

Framework 即我们所说的框架,通常是系统或者应用的骨架,很多时候,它表现为一组抽象的构建及构件实例间交互的方法.因此,可以认为,Framework 规定了应用的体系结构,阐明了整体设计,写作构件之间的依赖关系以及控制流程.注意自处的 Framework 并不完全等同于你所熟知的 Android Framework 框架,可以认为 Android Framework 中体现了 Framework 的思想,并进行了实现.

什么是API

API 是 Application Programming Interface ,又称为应用编程接口，是软件系统不同组成部分衔接的约定。更加通俗的说就 API 就是我们常见和编写的方法或函数.

小结

明确了上面提到的概念之后,现在就可以来描述这四者之间的关联:
SDK 主要包含 Framework , API 及 Library 的三部分.Framework 定义了 SDK 整体的可重用设计,规定了 SDK 各功能模块的职责以及依赖关系.其中个功能模块体现为 Library.模块之间的内部通信及 SDK 外部通信(SDK对外提供服务的接口)则通过 API 进行.

另外完整的 SDK 还应该包含大量的示例和其他工具.比如在 Android SDK 的 tools 目录下提供了大量的辅助开发工具.

对我们而言,大部分情况下是为某种具体的业务需求开发对应的 SDK,以便作为第三正提供给其他需求方使用.比如百度推送的 SDK 主要实现消息推送功能,需求方只需要集成百度推送的 SDK 便可以使自己应用具备推送功能.

到现在已经介绍了 SDK 的主要构成,接下来我们重点来介绍 SDK的实现目标 以及 在SDK架构中的一些核心点.

上面介绍了开发中常见的概念,现在来谈谈 SDK 的实现目标.任何应用都应具备:简洁易用,稳定,高效,轻量,SDK 作为一种特定应用当然也不例外.

简洁易用

按照”奥卡姆剃须刀”理论,一个好的产品对第三方使用者使用而言应该是简洁易用,不用改让使用者花费太长时间学习的.这对SDK同样适用—SDK不应该对宿主应用有过多的代码侵入,也不应该有复杂频繁的接入工作.比如当开发者需要使用SDK的服务时,只需要在缘由的代码中新增一行即可.常见的SDK初始化如下:

当我们需要使用该 SD K的服务时,通过一行代码便可启用 Ad.init(this,params)

要保证较少的代码侵入主要在对外提供服务时充分考虑到使用者的使用场景来设计出优良的API.一个 优良的API 在定义的时候应该满足绝大数开发者所预期的方式—语义上要求通俗易懂,使用上要求简单可靠.

一个优良的API首先是简单可靠的.在正常使用的情况下体现为稳定可靠的执行,在异常情况下体现为及时的告知使用者使用错误.初次之外,遵循一致的明明规则,并是所有的API呈现出一致的风格对开发而言无疑是个好消息.

稳定

站在 SDK 使用者角度来看,我们期望第三方的 SDK 服务应该是稳定高效的,体现在提供稳定可靠的服务,在不影响宿主稳定性的前提下足够的高效,这就要求我们 SDK 设计者在设计并实现 SDK 时要尽可能的做到以下几点:

• 对外提供稳定的API.SDK 的API一旦确定,如无非常严重情况不可更改.作为提供服务方,发生 API 变更所带来的变更成本非常大.

• 对外提供稳定的业务.在稳定的 API 后,必须要有稳定的业务来支撑.

• SDK 运行时的稳定,作为服务提供方,我们必须确保 SDK 自身运行的稳定,并且保证接入方不会因为我们的 SDK 产生不稳定的情况.

• 版本稳定更新.和面向普通用户的应用相比,SDK 版本的迭代是非常缓慢的.并且需要尽可能的对开发者屏蔽迭代过程,以免给开发者带来不必要的适配开销.

高效

无论是普通的应用开发还是SDK开发,都应该考虑到性能问题,SDK设计者应该着重考虑以下问题:

• 更少的内存占用.在不使用多进程的情况下,SDK 服务和宿主程序运行在同一进程中,这种情况下必须要求限制 SDK 内存的占用,不能因为说因为我们 SDK 占用太多的内存资源,导致应用的存活时间变短.

• 更少的内存抖动.在占用更少内存的前提下,SDK 设计者必须刻意的减少反复GC造成的内存抖动问题.

• 更少的电量消耗.尽管很多时候无法对电量消耗做一个很好的权衡,但是仍然有一些可以参考的做法,比如减少使用耗电模块的时间.比如在使用定位服务时,不要求非常高的精度下优先使用网络定位而不是GPS定位.

• 更少的流量消耗.

SDK 的架构实现决定了 SDK 后续的维护难度,因此有必要在此对 SDK 整体架构中的一些点做些简单的说明.

模块化开发

根据单一职责将系统拆分为不同的小模块，每个模块保持相对独立。

模块之间通过协议或接口通信，以减少相互之间的依赖耦合.模块内部按照设计的几大原则进行实现,以保证模块本身可以灵活实现

对于现代开发而言,模块化是常用的手段,从宏观角度来看,模块是系统最小的组成单元.

组件化开发

组件开发同样是个老生常提的概念,但从我个人的感受来说,组件是对逻辑的封装,并具备单个可移植性.比如可以把日志记录做成一个组件,之后它可以被轻松在应用在不同的项目中.对于 Android 开发者而言,Android 提供的每个UI 控件同样也是组件,比如 Button,TextView等.

在明确了组件这一概念之后,组件化开发也就不难理解:所谓的组件化就是将整个项目划分成多个模块,几个模块或者单个模块作为一个组件,开发过程中我们可以对每个组件进行并行开发,最后发布时通过依赖将组件合并成完整的应用.

那为什么要使用组件化呢?随着 Android 的逐渐成熟,现在的app业务越来越复杂,与此同时,Android工程也变得日益庞大,代码行数十几万已经是常态,此时有几个问题便会凸显出来:

• 工程任何一点改动都会造成整个工程的重新编译.记忆最深的就是早期在没有进行组件化的时候,庞大的工程动辄需要十几分钟的编译时间,一杯茶的时间就出来了,很多时候,不得不眼巴巴的等着,尽管现在可以使用 facebook 出品的 buck 以及来自阿里的 feeline 来加速编译过程,单仍然不够.

• 整个工程中充斥的大量重复或者冗余的子模块,业务耦合度非常高,牵一发而动全身.这就造成了”老人不敢改,新人无法改”,因为谁也不能预知在做修改之后,会产生什么影响.

• 协作开发基本上是不可能的,天知道彼此在做什么.代码合并的的时候更是令人痛苦.

• 不方便测试.高度耦合的业务和模块导致无法下手进行测试,只能草草了事.

通过引入组件化,上面遇到的问题便可迎刃而解.在 SDK 当中,根据实际情况对其进行组件化,比如我们将分享功能组件化,可以轻松的支持多种渠道的分享,在需要更新分享功能时,可以对其进行单独的编译和测试.

通过组件化,我们也可以轻松的实现 SDK 的定制功能,通过编写编译脚本,我们可以决定哪些组件被依赖,最终合并到完整的应用当中.比如友盟中的提供的可定制分享组件(如下图)的原理就是如此.

插件化开发

什么是插件化开发这里就不做介绍了,一方面插件化并不是个新概念,另外就是插件化到目前为止理论层次上已经非常成熟,不想15念开始研究的时候资料相对较少.

在 SDK 中为什么使用插件化呢?SDK 不同于普通应用,不能频繁的进行更新,以免让开发者觉得 SDK 不稳定或者让开发者频繁的集成.SDK 看起来变化较慢,实则变化频繁.就以以前做的 广告SDK 而言,有时候经常需要对某类机型进行数据采集或者及时更新反作弊模块,在没有使用插件化之前,解决该问题是非常麻烦的.但是在我们利用插件化之后,解决该问题就变得非常容易.

我们将 SDK整体 划分为两部分: 宿主 和 插件 . 宿主 只向开发者提供必要的服务接口,并提供了自定义插件加载器.而核心的逻辑则是存在于插件中.当需要采集数据的时候,只需要由开发人员开发好数据采集插件并下发到指定设备即可;当需要修复SDK缺陷时,同样也只需要下发新的插件包即可.

通过在 SDK 使用插件化方案,可以有效的对开发者屏蔽手动更新的过程.宿主相对稳定,一旦确定,一般不会变动,而后续的业务变化则只需要通过更新插件来支撑.

除了上面谈到的利用插件化解决动态更新之外,通过将整个工程分为宿主和插件可以实现宿主的并行开发和分开编译,并且能有效的解决方法数65535的限制.

SDK初始化

和应用开发不同,很多情况下 SDK 没有自身的上下文 Context,而必须要借助应用提供.SDK 初始化的常见做法: Ad.init(Context context,AdParams params) ,我们往往推荐开发者在应用 Application 组件中的 onCreate() 中去掉用该方法,这就意味着该初始化过程是同步的,假如 SDK 本身初始化时间较长,就会影响应用的启动速度.

在这种情况下,作为 SDK 的设计者必须着手解决该问题.通常将 SDK 服务进一步划分成核心服务和辅助服务,之后通过并行初始化和延迟初始化的手段来减少 SDK 初始化耗时.曾经在我所负责的广告 SDK 中,有开发者反馈我们的 SDK 启动较慢,通过对整个 SDK 启动流程进行分析后,我们将插件加载服务和云控服务并行初始化,而对于像日志服务则采用颜值初始化,通过该手段有效的减少了初始化耗时

云更新控制

云控服务作为一种服务端控制客户端的手段在SDK中开发中非常重要,现在的SDK开发可以不支持插件化,但是必须要提供云控服务,以便让服务端能控制 SDK,比如在不需要进行数据采集的时候,可以通过云控服务关闭 SDK 采集功能,在需要的时候在将其打开.

对本身是基于插件化开发的 SDK 而言,云控服务更是不可或缺.

从实现的角度而言,云控服务分为服务端主动和客户端主动.服务端主动是指服务端会将最新的云控开关的信息推送到 SDK,而客户端主动则是 SDK 在进行操作之前会首先请求云控信息.对有推送开发经验的同学而言,这非常容易理解,就是像是为了实现消息推送功能,我们可以通过客户端轮训也可以通过服务端保持长连接进行消息推送一样.

安全

SDK自身安全

为了区分接入者并增加 SDK 自身安全性,我们通常会为开发者分配 api key 和 api secret,SDK 会读取开发者配置的 api key 和 api secret,并用于随后的网络通信中.这是非常常见的做法,比如当你集成极光推送 SDK 的时候,它也许需要你提供 api key 和 api secret,如果没有则需要到官网进行申请.

核心逻辑采用C/C++

为了安全起见,数据加密类,模块算法类都都应该采用NDK开发,将其封装在so文件当中.有很多开发者不明白为什么这样会增强安全性.这里我们简单的做个说明.由于.so文件是通过c/c++编译出的文件,相对于Java的反编译文件来说,可读性更差,另外大部分的Android开发者并不具备较深的C/C++能力,因此一定程度上增加了被破解的能力.