如何设计C/S架构的Android SDK | 开篇:C/S架构的SDK包含哪些部分?

125 阅读3分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 2 月更文挑战」的第 5 天,点击查看活动详情

概述

当一款产品使用Android系统作为一个平台时,我们可以通过 接入各种硬件(例如:打印机、读卡器等)、魔改原生系统服务(例如:同时为多个应用提供访问相机的能力)、或者 增加一种全新的交互(例如:语音、手势操作),为第三方应用提供丰富的功能。

上述提到的能力,都是一种平台级的能力。想要实现一个平台级的能力,需要具备:

  • 一个实现这个能力、并能够有序地管理、协调、给其他应用提供这项能力的 服务
  • 第三方应用可以通过简洁、易用的 API接口 调用到这项能力
  • 服务和第三方应用本质上是两个应用,为了使它们相互调用,还得有一套支持跨进程通信的 通信层

API接口通信层服务 形成了一个典型的C/S架构,这也是这个小系列文章的主题:如何设计一个C/S结构的Android SDK。

本篇文章作为开篇,将首先介绍:C/S架构的SDK包含哪些部分?,之后的文章将分别介绍:

  1. 如何设计一套易用的API?
  2. 如何设计一个无感的通信层?
  3. 如何设计一个稳定的服务?

架构

我们以Android平台要新接入打印机为例。在服务端接入打印机提供商的SDK获取硬件能力,客户端通过调用API接口,经过通信层向服务端发出请求,间接获取硬件能力。

这样设计的好处是:

  • 接口统一
    客户端只需要关注平台提供的API即可,不需要关注平台究竟接入了哪家厂商的硬件设备,厂商的SDK由服务端进行适配。

  • 易于扩展
    若打印机厂商的SDK进行了升级,或者平台更换了新的打印机厂商,也只需要更新服务端,客户端将不受影响。

  • 安全稳定
    客户端不直接访问硬件资源,由服务端对硬件资源进行统一管理,避免客户端的错误操作,甚至crash导致硬件设备的访问异常。

C/S架构SDK结构图 C/S架构的SDK包含APIIPC服务端

  • API
    定义了SDK具备的功能,是客户端可以直接调用的接口,运行时与客户端同处于应用进程。

  • 通信层
    在Android平台上,客户端与服务端通过IPC通信,进行接口的请求与结果回复。这一部分对于客户端是透明的,在SDK内部通过Binder来实现。

    客户端 BinderProxy 运行于客户端进程,服务端 BBinder 运行于服务端进程。Binder是Android中最常用的IPC方式。Android为我们提供了AIDL和Messenger去实现Binder机制,本文介绍的IPC方式基于AIDL和Service的绑定来实现。

  • 服务端
    Service 负责接收客户端请求,并关联抽象层操作硬件设备执行具体的行为,再将结果返回给客户端。

    抽象层 为服务端定义了统一的操作接口和调用流程,服务端基于抽象层接口进行硬件操作即可。

    不同的 子模块 依赖不同厂商的SDK,基于抽象层实现具体的功能,为服务端提供对应硬件的控制能力。