这一篇来聊一聊如何开发基于QP的应用程序，他可能和我们平时开发的应用程序所遵循的规则不太一样，其实规则一词有点别扭，不如说是套路，每个人开发软件都有自己的套路，每个套路都是你站在问题需求的一个角度上理解以后，产生的策略，问题需求的角度不同，你能产生的策略就不一样，不要站在一个套路的高度，尝试着把软件融入到另一种套路中，一切重新从需求出发，问题会变得更简单。
QP这本书提了两点要求我们必须遵守的准则，并且用了很大的篇幅去说服你一定要遵守这两条准则：
准则一、活动对象之间仅应该通过异步事件交换来相互作用，不应该共享内存或者其它资源。（通俗举例：取消全局变量）
准则二、活动对象不应该被阻塞或者在RTC处理中间忙等待事件。（通俗来讲：不太好讲，大概是活动对象内部处理代码不要有死等或者被挂起的操作）
知道这两条规则，你依旧是写不好QP的应用，就像是懂得了很多大道理却依旧过不好这一生（扯远了），规则的目的，不是让你仅仅停留在理解的阶段，而是要在今后的实战应用中，不断地实践，不断的进阶，才会获得更好的理解（莫要怕犯错，不犯错你就永远无法掌握它）。
这两条规则都在围绕着一个核心的主题来，也就是【活动对象】，他爹就是【状态机】，时代变了，很难靠状态机来打天下了，必须要披上一层QF的糖衣，这样生意就好做多了，QF提供了事件队列，内存池等等一系列的基础设施给状态机使用，同样，用上了这些高端货的状态机，已经不能叫做状态机了，于是，他有了另一个喜人的名字【活动对象】。
一个基于QP的应用程序，实际上是被分割成了多个【活动对象】，每个活动对象都为系统管理一部分【资源】，资源这个词很有意思，看到管理资源，第一时间可能想到的是管理内存，其实在活动对象看来，不光是一片内存叫资源，两个IO引脚，一个LED灯都可以叫做是资源，如何实现应用，其实就是靠管理这些资源协调运作，从而实现应用的功能。
又扯远了，【活动对象】的本职就是管理资源，他们高度的自治，就是我管的事情别人不可以插手，那么如何协调工作呢，那就需要一个叫做【事件】的邮件，你想改变某个资源，对不起，发邮件告诉我。什么？你很急？哦，那你赶紧写邮件啊（大家必须遵守规则，不然又回到了全局变量满地找的解放前）~！
整个应用程序功能可以很复杂，有可能很多活最终都分配给某个【活动对象】，其它的【活动对象】就很闲，是不是会让你想起ARM打天下的场景，嘿嘿~！这就要看作者的创作水平了，这个叫【某个】的【活动对象】变得很忙，其他人都在聊天打屁，还时不时给他发邮件，让他干这干那，他倒是任劳任怨，但是好多邮件到家门口的时候，他可能在忙，于是邮递员【QF】把邮件放到他家门口，敲门就走了，这货现在忙得跟孙子似的，根本没时间开门接邮件，结果一阵大风刮过，他开门的时候啥也没了。整个应用到这里就凌乱了。
为了解决这个问题，于是乎，QF就给每个【活动对象】在他们家门口都按了一个箱子，叫邮箱（这个邮箱是真实生活中的邮箱，可不是操作系统概念中的邮箱）【事件队列】，于是乎，这个问题仿佛得到了一部分解决，快递员每次来的时候，就把邮件放到你的邮箱里，然后敲门离开，当然也会遇到一种特殊情况，邮件太多，实在放不下了（一个合适大小的事件队列有多重要，只能等你实战的时候体会了），这时候，快递小哥只能把邮件放在门口，敲门离开，继续送信，小心大风~！
针对这个写的邮件【事件】，还有一个重要的方面没讲，也就是【活动对象】能处理的邮件的要求是受限，你不能写个邮件【事件】，内容是帮我造一颗原子弹，这时候【活动对象】可能懒得理你，也可能和警察【QF】报告抓你，为了防止恶作剧的存在，于是大家规定了一整套的【事件】类型的定义，叫做【信号】，通过枚举来完成，确保大家都不同。
到这里已经引出了本篇的所有主题，你要开发QP应用程序，就必须将他分解成多个【活动对象】，并用【事件】机制将他们串起来，这个复杂的机制又引入了【信号】、【事件队列】等等内容。
于是总结一下：
QP应用程序 = 多个【活动对象】+【信号】+【事件】+【事件队列】；
【活动对象】是可以展开的，展开就是状态机，如何基于状态机开发应用程序的专题我写了，所以这里就不展开了。
下一篇，教你如何分解成活动对象，基于一个官方的实例，从问题需求，到顺序图，到活动对象一条龙。再见~！