端末側オープンビットAI統合ランタイム環境（IRE） - のAoE（エッジON AI）。深い学習アルゴリズムに開発者を支援することができ、設計の原則として「安定性、使いやすさ、安全保障」のAoEを容易に効率的な端末の実装の異なるフレームワークに展開されます。
フレームの2枚は、そのようなランタイムを行うには理由が理由があります：
- まず、人工知能の急速な発展に伴い、過去2年間は、開発者に多くの選択肢を与えて、推論の枠組みを実行している多くの端末がありましたが、また、AI端子を展開するコストが増大し、
- 第二に、どのように安定性の問題を保護するために動的ライブラリのアクセス、リソースの読み込み、前処理と後処理、リソースの解放、モデルのアップグレードなどを含むより複雑なAI推論フレームワークプロセスによる直接アクセス。
報告によると、現在、8回の主流の推論の枠組み端子の実行が次のとおりです。
本質的には、どんなに推論の枠組みを早期に、前処理、実行推理、後処理、リリースされたすべてのリソースを含まなければならないものをその5つのプロセス、のAoEの様々なサポートこれらの抽象的な推論、推論の枠組み基盤。現在のAoEは、推論の枠組みNCNNとTensorFlowライトの両方のサポートを実装しました。
具体的には、基本的なAoEを統合操作環境は、抽象的推論操作で依存性逆転のデザインを通じて、ビジネスは、実装のためのアクセス、特定の推論の枠組みを気にすることなく、抽象化のAoEの上層にのみ依存します。この設計の最大の利点は、ビジネスの発展とのAoE SDKは完全に切り離さ開発するように、開発者は常に、達成するためのフレームワークを変更することなく、推論のための新たな枠組みを追加できるということです。
AoEをSDKでこの抽象であります：
- InterpreterComponent：、初期モデルを扱う実装し、推論リリースリソースへ。
- コンバータ：治療のためのモデル出力モデル入力の処理前後。
次のようにInterpreterComponent具体的な実装は次のとおりです。
/**
* 模型翻译组件
*/
interface InterpreterComponent<TInput, TOutput> extends Component {
/**
* 初始化，推理框架加载模型资源
*
* @param context 上下文，用与服务绑定
* @param modelOptions 模型配置列表
* @return 推理框架加载
*/
boolean init(@NonNull Context context, @NonNull List<AoeModelOption> modelOptions);
/**
* 执行推理操作
*
* @param input 业务输入数据
* @return 业务输出数据
*/
@Nullable
TOutput run(@NonNull TInput input);
/**
* 释放资源
*/
void release();
/**
* 模型是否正确加载完成
*
* @return true，模型正确加载
*/
boolean isReady();
}
次のようにコンバータの特定の実装では、次のとおりです。
interface Convertor<TInput, TOutput, TModelInput, TModelOutput> {
/**
* 数据预处理，将输入数据转换成模型输入数据
*
* @param input 业务输入数据
* @return 模型输入数据
*/
@Nullable
TModelInput preProcess(@NonNull TInput input);
/**
* 数据后处理，将模型输出数据转换成业务输出数据
*
* @param modelOutput 模型输出数据
* @return
*/
@Nullable
TOutput postProcess(@Nullable TModelOutput modelOutput);
}
AoE 还有另一个特性是具有稳定性保障。众所周知，Android 平台开发的一个重要的问题是机型适配，尤其是包含大量 Native 操作的场景，机型适配的问题尤其重要，一旦应用在某款机型上面崩溃，造成的体验损害是巨大的。
有数据表明，因为性能问题，移动 App 每天流失的活跃用户占比 5%，这些流失的用户，6 成的用户选择了沉默，不再使用应用，3 成用户改投竞品，剩下的用户会直接卸载应用。因此，对于一个用户群庞大的移动应用来说，保证任何时候 App 主流程的可用性是一件最基本、最重要的事。
结合 AI 推理过程来看，不可避免地，会有大量的操作发生在 Native 过程中，不仅仅是推理操作，还有一些前处理和资源回收的操作也比较容易出现兼容问题。为此，AoE 运行时环境 SDK 为 Android 平台上开发了独立进程的机制，让 Native 操作运行在独立进程中，同时保证了推理的稳定性（偶然性的崩溃不会影响后续的推理操作）和主进程的稳定性（主进程任何时候不会崩溃）。
具体实现过程主要有三个部分：注册独立进程、异常重新绑定进程以及跨进程通信优化。
第一个部分，注册独立进程，在 Manifest 中增加一个 RemoteService 组件，代码如下：
<application>
<service
android:name=".AoeProcessService"
android:exported="false"
android:process=":aoeProcessor" />
</application>
第二个部分，异常重新绑定独立进程，在推理时，如果发现 RemoteService 终止了，执行 “bindService()” 方法，重新启动 RemoteService。
@Override
public Object run(@NonNull Object input) {
if (isServiceRunning()) {
...(代码省略)//执行推理
} else {
bindService();//重启独立进程
}
return null;
}
第三个部分，跨进程通信优化，因为独立进程，必然涉及到跨进程通信，在跨进程通信里最大的问题是耗时损失，这里，有两个因素造成了耗时损失：
- 传输耗时
- 序列化/反序列化耗时
相比较使用 binder 机制的传输耗时，序列化/反序列化占了整个通信耗时的 90%。由此可见，对序列化/反序列化的优化是跨进程通信优化的重点。对比了当下主流的序列化/反序列化工具，最终 AoE 集成运行环境使用了 kryo 库进行序列化/反序列。以下是对比结果，数据参考《各种 Java 的序列化库的性能比较测试结果》。
目前 AoE SDK 已经在滴滴银行卡 OCR 上应用使用，想更加清晰地理解 AoE 和推理框架、宿主 App 的关系，可以通过下面的业务集成示意图来了解它：
已经开源的运行时环境 SDK 包括 Android 和 iOS 平台，此外 Linux 平台运行时环境 SDK 正在紧锣密鼓地开发中，预计在 9 月底也会释出。
详情查看：