活动对象框架

为嵌入式应用设计一套Activity框架，做个记录，思路大量借鉴了QP框架，但逻辑不使用QML状态机。

一个Activity，就是对象维护的线程+接收事件的队列+一系列事件处理逻辑。

Activity收到事件后，对事件作出相应，执行相应操作。

系统的任意部分都可以产生事件，比如软中断处理函数、别的线程，但处理事件的只有activity。

目的

• 模块间解耦，以发送事件的方式代替直接call
• 实现异步执行，call的串行化变相地实现了锁（同一时刻只处理一个事件），简化模块内部处理多线程同步问题
• 一些操作可以invoke到目标activity中执行，可以将逻辑实现写在发送者这边，避免代码分散
• 方便实现全局事件，比如通知系统即将断电（模块需要保存一些信息）
• 方便实现发行-订阅机制，任意一个模块（不一定是activity）都可以发行事件，而activity拥有接收槽可以接收事件

功能点

• Activity的索引，小系统可以使用唯一编号，更大的系统用字符串似乎更好些
• 带优先级
• 延时执行，比如模块说“在xx秒后执行xxx函数”，比如方便做定时轮询、异步操作超时判断等，但时间太长会影响模块反初始化，所以得做被打断后的异常通知（在参数里传个）（不一定在这模块内实现）
• 为了方便做安全退出，activity需要有“即将反初始化禁止接收”的状态，以方便退出时清掉消息队列（可以查到这个状态以加速过程，比如异步执行的操作可能会很长时间）；需要退出时，禁止新数据接收，并向队列发发送一个“退出事件”，待

编程范式

• Activity间不共享内存资源
• Activity在处理事件时尽可能不阻塞

难点

内存管理

VxWorks的做法是把事件相关的数据全压进消息队列里，代价很高。

QP框架的做法是在框架内做一个公用的EventPool用来存放事件相关的内存：

事件的生产者从这里申请内存（初期可以用malloc实现），由于框架维护着Activity的线程，所以是能知道事件什么时候被处理完的，处理完后自动释放。

同时会有一些事件的参数很小，无需动态内存，这类事件得有一个静态内存的标记

当接收方不止一个时，这套管理方法就得加上引用计数器了，一开始不打算支持这功能。