OpenHarmony 4.0蓝牙代码结构简析

OpenHarmony 4.0蓝牙代码结构简析前言

OpenHarmony 4.0上蓝牙仓和目录结构进行一次较大整改，本文基于4.0以上版本对蓝牙代码进行分析，便于读者快速了解和学习OpenHarmony蓝牙模块

代码仓和目录结构

当前蓝牙完整的代码涉及多个代码仓

代码路径

说明

应用接口https://gitee.com/openharmony/interface_sdk-js/tree/master/api当前所有应用层接口统一归并到interface仓；api 10中蓝牙接口按照profile拆分了多个d.ts文件
框架层https://gitee.com/openharmony/communication_bluetooth该仓之前包含框架层和系统服务层代码；架构拆分后只保留框架层代码
系统服务层https://gitee.com/openharmony/communication_bluetooth_service
驱动https://gitee.com/openharmony/drivers_peripheral/bluetoothIDL模式，蓝牙驱动接口实现；接口定义在https://gitee.com/openharmony/drivers_interface/bluetooth；完整的代码还应该包括vendor(蓝牙芯片)代码，如dayu200的vendor代码在https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568

系统服务层代码仓目录相对较多，目录划分原则和功能描述如下

架构及进程部署

1、蓝牙模块按照OpenHarmony系统架构分层原则进行分层

2、框架层分为JSAPI和NativeAPI，JSAPI用于用户APP调用；NativeAPI生成btframework.so，供其它系统服务（net_manager...）调用；部署在调用者进程

3、系统服务层内部分为5层，分别对应目录结构中描述的5个目录；部署在蓝牙系统服务进程

4、驱动进程中部署Hdi和Vendor模块；和蓝牙芯片对接，在蓝牙系统服务进程和蓝牙芯片间处理报文收发

版本间差异

1、原来蓝牙框架层和系统服务层都在bluetooth代码仓，现在拆分成了bluetooth和bluetooth_service两个仓；主要理念是考虑可以方便替换或升级蓝牙系统服务层的实现；比如厂商可以使用私有的蓝牙协议实现，只需要框架层接口保持一致即可

2、为了减少应用程序的运行内存和程序加载速度，JSAPI按照profile拆分出了多个so；应用程序可以按需最小引用蓝牙模块功能

总结

本文基于OpenHarmony 4.0版本对蓝牙代码架构/目录分层原则做了简单分析，同时分析了4.0版本的重要改动点