事件驱动框架

为了使程序解耦和，去学习了面向对象的设计模式，其中发布订阅模式就是一个非常好的框架。但是发布订阅模式也有弊端。

1.需要额外的空间去存储订阅者的回掉函数

2.当一个订阅者需要多种事件完成一件事情时，意味着需要写多个订阅回掉函数。这意味着别人看你的程序会更加的吃力。

在学习开发nrf52832的蓝牙的时候，他的工程中全是底层向上层抛出事件，然后你需要根据他的事件去处理一些事情，也就意味着我们需要在他的事件里面调用自己写的函数。这样就能很好的解决发布订阅模式以上两个弊端。这种事件驱动框架我把它叫做显式事件处理，而发布订阅是隐式事件处理。

在一个系统中，可以把模块分为两类：事件产生者， 事件消费者。

事件产生者：只管往外抛出事件，这个时候需要运用队列，事件产生后加入到队列中（比如按键状态），然后我们只要出队，将这些事件抛出，这个时候事件产生者的工作就完成了，至于谁关心，那就需要事件消费者去订阅这个事件。

事件消费者：消费者在系统中会有很多，而且可能这些消费者需要订阅大量的信息来控制自己，如何管理这些状态也是很头痛的事情。

        比如有一个LED消费者，他需要知道按键是不是按下了，如果安心他就亮起来，同时她还要知道这个时候是不是低电量，如果低电量还要闪烁。

        比如系统低功耗休眠也是事件消费者，我开发的一个低功耗产品，需要多种状态控制低功耗，目前设计的就很差，休眠函数全部分散在了各个模块中，如果别人维护起来比较难。

随着开发的深入，慢慢发现一些在裸机中需要处理的消息，事件问题，在freertos中，其中就花了很多的篇幅去处理这个问题，队列，二值信号量，计数信号量，互斥信号量，事件标志组。

freertos的队列不就是用于开发中类似按键这样一直抛状态的事件处理吗

二值信号量：某个标志位置位，然后清除。有了二值信号量，就不要清楚这个动作了，我只需要关系队列是否有数据就可以。

事件标志组：就是我们需要同时满足多个条件，然后才会处理某件事情