一、背景

众所周知，Android 是一个开源的系统，从它诞生的那一刻起，Android 系统被逐步应用在了各种各样的硬件设备中。随着移动互联网和移动支付的兴起，传统 POS 机也开始逐渐被 Android 系统加持下的智能 POS 机所取代。

有赞，是一家商家服务公司。我们帮助每一位重视产品和服务的商家私有化顾客资产、拓展互联网客群、提高经营效率，全面助力商家成功。为了满足商家日益丰富的支付渠道，尤其对于刷卡能力的需求，有赞的多个 App 均对接了智能 POS 机这一硬件。

随着业务的快速发展，笔者所在的有赞美业共陆续对接了多个厂家的不同类型的智能 POS 机硬件。如何更好地接入各式各样的 POS SDK 成为一个摆在我们面前的问题。

本文将按照时间线的顺序，结合在对接过程中的思考与总结，回顾我们 POS SDK 对接方案的演进过程，希望能够带给大家一定的启发。

二、演进过程

2.1 阶段一：直接集成 POS SDK ，快速满足需求

在业务快速发展的早期阶段，快速上线满足需求是首要考虑目标，且当时也只有一台 POS 机对接的需求，因此我们选择直接在现有代码中集成 POS SDK 的方案。

2.1.1 项目结构

2.1.2 方案分析

首先这个方案的优势很明显，对接成本低，满足快速上线的需求。结合当时的背景情况，选择这个方案也是很自然而然的。

然后相对的，这个方案的问题也非常的明显：

• 业务代码与 SDK 逻辑耦合严重。
• 未能抽象设备能力，拓展能力差。
• 其他业务方无法复用对接逻辑，导致重复工作量。

试想一下如果这个时候又有台新设备需要对接，那工程代码中肯定会充斥着各种 if-else 判断来区分设备类型调用不同的SDK，这简直就是一种灾难！

所以，在此方案上线运营的同时，我们就开始着手改进方案以解决这些问题。

2.2 阶段二：抽象设备能力，组件化改造

要解决阶段一的问题，其实就是要解决两个关键问题：拓展能力和复用能力。

对于这两个问题，最简单的做法就是对设备的能力进行抽象，在此基础上针对不同 POS 设备进行实现，封装成一个公共硬件库，供有赞 App 共同使用，也就是进行组件化改造。

2.2.1 项目结构

2.2.2 方案分析

经过组件化的改造，整个对接方案的拓展能力和复用能力都得到了极大的提升，能够满足一段发布上线。

但其实这个方案存在一些很容易被忽视掉的问题：

• 随着接入设备越来越多，公共硬件库的体积将会急剧增加，进而导致业务 APK 的安装包也水涨船高。
• 对于 POS A 设备来说它只需要自身所需的 POS A SDK 即可，其他 POS 设备的 SDK 完全是无用或冗余的。
• 由于 POS SDK 之间实现的差异，很容易带来一些意想不到的问题，比如说依赖冲突、资源文件冲突等等。一定程度上影响业务 APK 的性能和稳定性。

针对这三个问题，我们开始寻找相应的解决方案。

2.3 阶段三：瘦身 + SDK 隔离，差异化打包

鉴于阶段二所存在的问题，当前阶段的改进方向已经很明确了：

• 安装包瘦身
• 将 POS SDK 相互隔离

众所周知，Android 原生就支持一种差异化打包方案： ProductFlavors

基于 ProductFlavors 方案，首先将硬件库的能力拆分开来，做到抽象能力与其实现分离，对于一台 POS 机来说其他 POS 机的实现不会再对自身造成影响，从而直接消除了性能和稳定性方面的影响，同时由于依赖的 SDK 变少了，业务 APK 安装包大小也得以显著减小。

关于 ProductFlavors 的基本使用和原理不在本文的讨论范围内，有兴趣的同学可自行查阅相关文档。

Android 官方文档

2.3.1 项目结构

2.3.2 方案分析

差异化打包方案很好地解决了阶段二所发现的问题，但实际上最终这个方案并未被采纳，因为这个方案在解决老问题的同时，却也带来了新的问题：

• 如果业务 APK 使用了热修复能力，那么此时将会存在多个热修复的基准包，在每次热修的时候就需要针对每个差异包生成对应的补丁文件，而且以后每对接一个新的硬件就会多再一份工作量，想一想还是很感人的。
• 很多第三方 SDK 初始化所需的 id 、key 等配置信息与包名绑定，所以如果你的差异化打包配置了不同的包名，那么还必须重新申请新的配置信息。如果你对接的服务还依赖后端服务，比如推送服务端，那么相应的后端也需要同步更新。

可以看到一旦采用了这个方案，那么后续的维护成本将成为一个不可回避的问题。因此我们迫切需要再找办法来解决后续的维护成本问题。

2.4 结局：分手快乐！

在寻找维护成本问题解决方法的同时，我们重新审视了前期对接方案以及线上版本的运营情况，观察到如下两个情况：

• 厂商提供的 POS SDK 很少有版本变更，基本是一个版本用到底
• 业务方一旦完成 POS SDK 对接，那么对接的核心逻辑也很少会有改动

以此为背景，那么既然 POS SDK 部分的后续变更几率很小，那么业务代码和 POS SDK 部分的代码如果能够独立开来进行维护，也就是说将 POS SDK 及其接入逻辑抽离出来，以独立 APK 的形式为业务 APK 提供能力，这样既能满足拓展能力、SDK 隔离等方面的需求，又没有了阶段三方案后期的维护之忧。

按照这个思路，我们将现有的工程拆分为两个独立的 APK ：

• 业务APK：包含业务代码
• 服务APK：包含POS SDK及其对接逻辑

那么剩下的问题就是这两个 APK 要如何进行通信？

讲到这里，自然就要提到 Android 的进程间通信相关的知识了。

摘自互联网：

那么经过技术选型，AIDL 这种方式显然更加符合方案的需求，于是我们在此基础上进行尝试，AIDL 方案应运而生。

关于 AIDL 的基本使用和原理不在本文的讨论范围内，有需要的同学可执行查阅相关文档。

Android官方 AIDL 技术文档

2.4.1 方案图示

2.4.2 方案分析

2.4.2.1 方案说明

AIDL 是一种 C/S 结构的模型，在这个方案中，服务 APK 作为服务端向客户端也就是业务方 APK 提供能力，二者之间通信的关键枢纽就是自定义的 AIDL 通信协议。

而通信协议将会放在 support base 之中，同时提供给服务 APK 和 业务APK ，然后二者各自只需要关注的自己所负责的内容即可：

• 在服务 APK 中，将 POS SDK 能力按照通信协议封装为统一的对外接口。
• 在业务方 APK 中，也无需再关心当前POS硬件类型，只需要按照定义的通信协议使用相应的能力即可。

至此，业务代码与 POS SDK 彻底解耦，后期维护彻底分开，达到了方案预期的目的，同时得益于二者的独立，多业务方可以共用同一个服务 APK 所提供的能力，有效的避免了重复对接工作量，无缝对新的设备提供支持。

2.4.2.2 不同能力的调用时序差异

针对 POS 设备所提供的不同能力，从资金安全的角度出发，可以将 POS 能力划分为交易能力和其他能力。二者最主要的差别在于：

• 在使用交易能力的时候，调用结果不直接返回给业务 APK ，而是经由业务 APK 自行轮询得到后端支付状态变更。
• 在使用其他能力的时候，比如打印能力，由于其场景的低敏感度，调用结果直接通过回调告知业务 APK 。

2.4.2.3 全新的 POS 对接方式

与 POS 厂商或第三方进行过对接的同学可能都会有一个感受：我太难了！

• SDK 和文档是两个东西，来回的沟通和确认，效率极为低下
• 负责接入的同学死活运行出错，外部对接人员却表示反正他们没问题
• 负责接入的同学天天加班调试，外部对接人员不慌不忙

但是现在，得益于 AIDL 协议层的存在，这个方案提供了一种全新对接方式的可能：

1. 业务方提供 AIDL 协议层( support base )给 POS 厂家或第三方进行实现并完成调试
2. 设备中安装有赞 App 即可使用 POS 设备能力

想象下，如果能这样对接，它不香吗！

三、回顾与总结

没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。

回顾整个方案演进过程，可以看到我们每一个阶段的方案都是基于当时的业务现状进行设计，同时随业务发展需求逐步去改善的。

从技术角度来看，改进的基本思路都是围绕着耦合程度、拓展能力、接入成本、维护难度这四个维度进行的。

为了让不同阶段的方案能有一个更直观的对比，这里有个表格：

综合来看，无论从哪个维度来说 AIDL 都是目前最佳的实现方案。

1. 业务 APK 和服务 APK 独立，耦合程度极低，分别进行发布管理
   
   • App 安装包大小、性能及稳定性不会到受到 SDK 的影响
   • 业务方无需关心当前 POS 硬件，只需要按照统一的协议去使用能力
2. 拓展新设备无压力
   
   • 对于新设备的对接，只需实现其对应的服务APK即可
3. 接入成本相比更低
   
   • 一个业务方完成了对接，其他业务方均将受益
   • 全新的对接方式：由第三方或 POS 厂家实现
4. 维护难度：完成接入后的低维护成本
   
   • 专心维护业务 APK ，无需过多关心服务APK的维护
   • 不影响现有App现有基础能力，如热修复、推送等

四、探索与展望

4.1 动态加载技术和插件化方案可行分析

在 AIDL 方案中，业务方 APK 能够正常使用能力的前提是服务APK被同时安装在设备中。这就涉及到未安装和版本不符等版本管理的问题，而这些问题毫无疑问会大大增加商家的使用难度，影响商家的使用体验。

针对如上问题，大家可能会想到利用动态加载技术，动态加载 APK 或其他形式的插件，来实现服务 APK 免安装、动态下发替换的效果。

4.1.2 插件化方案流程图

4.1.3 终极解决方案？

单看这个流程图，这不就是一直以来追求的终极解决方案了吗？

桥豆麻袋！

诚然，从技术角度讲，插件化方案能够满足我们所有的需求，支持动态配置下发，看起来都是那么美好，但这里不得不先向你泼一盆冷水。

众所周知，自 Android 9.0 （P）版本起，Android系统将开始限制调用私有的系统API的行为，且这个限制还会随着后续版本更新逐步进行加强。

相关信息可以参考这篇官方文档：

针对非 SDK 接口的限制

很不巧，市面上耳熟能详的多个热门插件化框架或多或少均受到了影响。

为了验证可行性，笔者对多个插件化方案进行了实际调研，然后发现哪怕是其中宣称已适配了 Android 9.0+ 版本的插件化框架，在实际使用的时候依然是问题重重，比如：

• gradle 版本大多还停留在 3.x
• 基本都不支持 androidx
• 文档更新滞后， issues 页面无人应答， merge request 无人处理

因此目前并不建议采用使用插件化的对接方案，毕竟使用各种“黑科技”绕过官方限制的做法，终究是背道而行，是不得长久和不可持续的。

4.2 展望

在未来的规划里，我们将进一步地完善方案，尝试形成一个更加通用的接入方案，能够覆盖到POS机以外的其他硬件，降低整体的硬件能力接入成本，为商家提供更好的统一的使用体验。