AoE（ AI on Edge , https://github.com/didi/AoE ） 是滴滴近期开源的终端侧 AI 集成运行时环境 ( IRE )。
随着人工智能技术快速发展，近几年涌现出了许多运行在终端的高性能推理框架，例如 TensorFlow Lite，在实时性、安全性上给开发者带来更多支持和选择，极大的优化了用户的使用体验，但当我们想要在终端侧落地一些具体的 AI 业务时，会发现有些不得不面对的问题：
除了要做推理框架选型，还需要关注数据预 / 后处理逻辑的稳定性，模型分发使用时的包大小、数据安全等问题。这也正是 AoE 的设计初衷，希望完善模型生产到落地应用链路上的各个环节，提供整套的工具支撑体系，帮助开发者在终端轻松部署 AI 模型。以下我们通过滴滴内部一个具体实例应用，介绍 AoE 如何搭档 TensorFlow Lite ，让终端侧 AI 开发变得更加简单。
滴滴普惠安全产品技术团队通过手机传感器数据的实时分析，建立了精准、可量化的驾驶行为识别能力，以此为基础刻画精细的安全画像，建立全方位的集驾驶安全、骑行安全、异常检测、流程化策略为一体的识别解决方案，为用户提供精准、便捷的安全应用体系。借助 Google 的深度学习框架 TensorFLow ，我们对算法进行改造优化，极大地提升模型的识别效率和准确率。
通过 TensorFlow 来搭建卷积神经网络（ Convolutional Neural Network，CNN ）流式处理手机传感器数据，实时识别司机危险驾驶行为。
基于手机传感器识别行车状态，有很多问题需要处理：
- 不同机型间数值差异
- 手机姿态变化导致的模型环境变化校准
- 晃动导致的模型误触发
- 实时数据量大，计算复杂度高
- ...
以数据差异校准为例，由于不同设备间传感器数据差异较大，会影响模型最终效果，需要对其进行校准，保证模型输入数据的一致性。
通过自研机型校准滤波算法的处理，不同的机型可以得到一致的数据表现。
稳定性考虑
如前面介绍，我们在数据交给 TensorFlow Lite 执行推理前后，有很多的数据处理逻辑，出于性能和算法保密性考虑，我们把滤波算法等处理逻辑放在 Native 层实现。
众所周知，Android 平台开发一个重要的问题是机型适配，一旦应用在某款机型上面崩溃，造成的体验损害是巨大的。有数据表明，因为性能问题，移动 App 每天流失的活跃用户占比 5 %，这些流失的用户，6 成的用户选择了沉默，不再使用应用，3 成用户改投竞品，剩下的用户会直接卸载应用。因此，对于一个用户群庞大的移动应用来说，保证任何时候App主流程的可用性是一件最基本、最重要的事情。让 Native 操作运行在独立进程中，同时保证了推理的稳定性和主进程的稳定性，即偶然性的崩溃不会影响后续的推理操作，且主进程任何时候不会崩溃。
安全性考虑
TensorFlow 训练出的 pb 模型文件和转换在 TensorFlow Lite 使用的 tflite 文件，可以比较方便的看到网络层信息，在终端侧分发应用时，无法有效保障数据资产安全。 AoE 提供了文件加密机制，方便对模型文件进行快速解密，同时支持自定义加解密算法，示意图如下：
数据加密方案
- 文件加密 首先自选数据加密方案对模型文件进行加密（AoE 内置 AES 加密），生成一个加密文件
- 生成头文件 AoE 对加密文件添加 21 byte 的文件头，分别表示文件加密方案的版本，加密文件的文件长度以及加密文件的 MD5
- 字节混淆 指定一个步长（如 1024 byte），从加密文件头进行遍历，将读取数据切片的特定位（通常是第一位）与文件头片段里的字节依次互换。以此混淆了文件原信息。
数据解密方案
与加密对应的解密模块，通过已知的步长、置换位索引、加密私钥等信息配套的对文件进行信息重建和解析，得到源文件，AoE 以内存态运行，直接将模型源文件装载进推理框架进行执行。
通过这样简单的文件加密规则，既能保障加密实现的高效运行，又能在不同场景下拓展支持多套算法方案。
基于 TensorFlow 的优化改造，大大降低了我们算法开发和维护的成本。模型集成 AoE 在滴滴乘客端、司机端上线应用后，没有出现一例因推理执行导致应用主进程崩溃的 Case，稳定支持了多个版本加密模型在 APP 中的集成使用。
我们团队会持续完善终端侧 AI 落地的工具支撑体系，特别是对被广泛使用的 TensorFlow 的支持，帮助开发者轻松部署模型，更好的赋能业务。
欢迎关注：https://github.com/didi/AoE
欢迎添加小助手微信进入AOE开源交流群！