组件设计示意图

组件设计原则

1. 组件内部不能互相显式调用，上层组件可以依赖下层组件接口，不同组件之间可以隐式调用；
2. 一个组件实现一个功能；
3. 组件分类为通用组件、基础组件、业务组件、应用组件。

4. 组件下沉 比如业务组件的重复功能，可以抽象成为应用组件
5. 单独物理隔离 每个组件都可以单独编译，不能出现不编译某个组件编译报错的情况（个别基础组件除外）；
6. 保持兼容性 组件接口分为：兼容性接口，非兼容性接口两种，实际情况也是如此，很难做到所有接口兼容；但是原则上讲，尽量做成兼容接口；

平台适配

1. 硬件适配 对不同硬件的适配，通过增加一个软件抽象层实现，以C语言为标准，格式类似 manufacturer_sal_xx()，一般芯片厂商都提供了硬件抽象层manufacturer_hal_xx()，但是有些厂商的原厂SDK接口没有抽象hal层。所以如果是已经提供了manufacturer_hal_xx() 接口那么只需要再抽一个manufacturer_sal_xx.h头文件接口，如果芯片平台调用的原厂SDK没有提供hal层，那么需要新增两个文件作为软件适配层，分别是：manufacturer_sal_xx.h，manufacturer_sal_xx.c；manufacturer_sal_xx.h
2. 系统适配 由于目前很多WiFi芯片是基于RTOS进行应用开发，BT和ZigBee更多是基于裸机开发，那么跨平台组件就涉及到是否支持OS的适配问题，RTOS内核主要包括几大模块：线程管理，任务调度，线程通信，内存管理、时钟管理，中断管理；但是由于有些模块在裸机上实现比较复杂，考虑到当前业务场景的使用频率，暂时只实现部分OS接口适配，分为兼容性适配层和非兼容性适配层，其中裸机实现比较复杂的放到非兼容性适配层。针对OS和裸机接口需要再做一个适配层，这个适配层和上述硬件适配层的sal功能类似。
   兼容性适配层
   : 定时器定时器
   : 内存管理
   : 消息队列
   非兼容性适配层
   : 线程管理
   : 互斥锁
3. 通信适配 以C语言特性为例
   通信能力主要是指上下行数据，对于设备端而言，也就是指令接收和数据上报，不同芯片平台的上报接口也不同。由于三种芯片平台的通信能力不同，数据链路不同，数据格式也不同，为了抽象不同平台的通信能力，将数据上报抽象成句柄的方式，句柄包括WIFI，BT、ZigBee设备的上报能力；不同芯片平台只需要给句柄赋值，然后调用接口即可。不同芯片平台收到的数据也不同，那么对于组件而言，如何适配这些不同格式的数据？答案是：组件不适配。不同的芯片平台，数据格式不同，这些数据在业务逻辑层转换成组件支持的数据格式，比如收到的是压缩数据，就先将数据解压，然后才能被组件解析。
4. 功耗适配 关于低功耗实现，很多芯片是放在sdk上处理，如果应用上有显式调用就抽出来；平台有用到就抽出来，没用到就空函数。