android sensor 框架分析---sensor 总结

7 总结

Sensor总的框架图如下,

形象一点讲，整个Sensor的软件架构就像是水泵抽水灌溉。Service扮演电机的角色，它不断的产生抽水的动力，

并将水输送至目的地（APP），驱动扮演泵的角色，它负责完成抽水的必要准备并抽水，HAL则很像是连接电机和泵的管道。

driver可以逻辑上分为三部分，一部分支持它本身的功能，i2c读写，中断或者轮询处理。第二部分为sysfs文件节点，

接受HAL层传递下来的操作，通过i2c读写完成任务。第三部分为input子系统（注意，该处为Linux内核的input子系统，

并不是Android的input系统），负责数据上报。

HAL层的作用一是屏蔽硬件差异，二是传递控制和数据。

SensorService本身就是一个线程（Thread为其父类），循环地执行threadLoop（Android的机制），

该函数一方面负责poll数据，一方面得到数据后处理，通过管道发送。

 

分析的关键路线有2条,从上到下的控制流,从下到上的数据流。

控制流主要包括一些参数的设置,打开sensor,设置sensor频率等等，典型的从上往下。控制从APP注册监听器开始，

是一个观察者设计模式。注册监听器的直接操作就是enable和setDelay两个操作（unregisterListener则对应disable操作），

Service与APP并不是执行在同一个进程内的，Framework传递来的控制需要通过进程通信传递至Service，

使用的就是Binder机制。Service是唯一的，APP可以有无限个，Service为它们服务。

这样设计的原因显而易见——保证单一控制：硬件是唯一的（比如某一个加速度Sensor），对它的控制也应该是唯一的，

不应该由各APP单独控制。比如enable操作，如果已经有APP打开了设备，那么只需要将引用计数增加1即可，

并不会真正的触发驱动的操作；disable操作，如果引用计数大于1，说明当前除了该APP，还有其他使用者，

那么也不会触发驱动的操作。Service与HAL层属于同一个进程，Service调用HAL层的函数，HAL找到对应的文件节点，

根据不同的目的写入不同的值来触发驱动的操作。驱动根据得到的指令，读写设定好的寄存器控制流就得到了最终的落实。

   驱动负责收集数据（中断或者轮询模式），通过input子系统（也有部分厂商选择使用IIO）上报数据。HAL层使用poll监控input节点，

数据到来后poll返回，然后读取数据。Service部分有一个线程，该线程可以理解为一个循环，不断地poll HAL层的数据。

收到数据后，Service会做一些处理（比如计算虚拟Sensor的数据），之后则通过socket将数据发送至APP进程。

APP收到数据后，遍历当前已经注册的listener，通知它们，观察者模式完成。与控制流相同，数据流依然是一个

Service对应多个APP，Service会将数据发送到多个APP。

    最后说明一下,数据从服务端到客户端的跨进程并没有使用binder机制,因为Sensor数据量比较大，binder实现比较困难。