写在前面
公司一些方案,在Andoird P上架构必须要修改成HIDL,不然会遇到一系列的Selinux的问题,所以决定还是按照标准的Android HIDL的架构重新写了方案(因为比较机密,所以不透露具体方案代码)。但是我们的这个模块对性能的要求非常高,不然咱们的设备怎么能打败竞争对手呢,怎么屹立在世界500强呢,对吧。_
因为我们做的工业设备,对实时性要求比较高,但是HIDL的设计毕竟是需要进程间通信来调用到比较low level的接口的,肯定会有一些性能损失,但是好在还有一些别的机制来挽回损失,本文就来探讨一下这个问题,以及对不同的方式做一下性能的比对。
几种不同的方式对比
我们的需求是,应用层需要调用一些接口到kernel中的驱动,有一个HAL层封装了对驱动的操作,应用层去调用HAL层接口,其实就跟标准的AOSP的模块类似。那么问题就来了,以前是直接调用HAL接口,然后通过open/read/write/ioctl来跟驱动通信就好了,比较关心性能损耗就是系统调用到kernel中的时间损耗,其他都还好。但是一旦改成HIDL接口的写法,应用层就变成了HIDL的client端,调用到HAL的server端是用过binder/hwbinder进程间通信完成的,会有一些性能的损耗,我们就来测一下这个损耗是多少,因为我们的应用场景对这个时间比较关心,所以需要做这些分析,而且应用层会频繁的调用HAL接口。
如果比较难理解的话,我们来举个例子:
这个例子是在Android Camera开发过程中可能遇到的,在camera预览过程中,上层app需要实时的获取camera采集的图像数据,这个数据量是很大的&#