1. 配置管理层
这层在有多个功能入口时就很重要了，不然配置、或解析函数得copy多份。最好可以做成动态库。
WEB | APP |
无线功能或USB等功能模块配置 | |
消息处理层 | 消息的统一接口，接收、分发 |
功能配置 / 模块的控制接口 | |
模块 | 具体的功能生效、调用 |
其中绿色的部分（配置管理、控制接口、模块），应为具体的模块开发应提供的基础， 在后续开发中，如果需要增加这个模块的特性，则依次都要扩充。
（1）纯消息机制，CGI层直接构造消息给 消息处理层， 然后再从消息处理层GET 状态信息。
（2）保存值、发送控制消息机制。
（3）一个进程的方式。BRCM 4.12的SDK属于这种，页面下发值、保存配置、功能接口调用，都在Http中完成，但如果需要起进程、则发消息给SMD进程拉起。
1、3 这两种，页面延迟反应时间长、体验不好。
2 的方式、响应较快，但功能状态必然有延时。
功能耦合处理： 目前采用了通知链，单向依赖（模块基础，层叠，上面的依赖下面的，不能相互依赖），来处理。
但是，如果 A 、B这 2 个功能互斥（只能开一个），刚建议把这个处理放到 模块配置接口中（业务逻辑），不要放到配置管理、或CGI中，并记录相应的日志提示。（好像产品经理喜欢把这种提示直接放在WEB页面中）
需要各种机制来保证、或是解决这种耦合问题，否则接收到消息、控制处理的进程会非常乱。
2. 大平台 OR 小平台
大平台：适合做定制项目，小修小改，平台大而全，比较适合于业务变化小，功能一致较高。后续的产品规划稳定、无较大变化。
好处：
开发周期短、一起维护一个平台、有利于技术积累， OEM快速定制即可这样理解。
坏处：
需要专人维护、积累经验很重要。
包罗万象是致命的缺点，不得于维护，估计太大了就做死了（共进之前的平台就是这样）。太多的产品宏、芯片宏、功能宏。
小平台 ：做公共部分，适配多种产品把功能、性能做稳定，主要包括：平台框架、通信机制、基础模块（如日志、系统、必要模块）。
好处：
让平台脱离业务逻辑，专注做好基础。
缺点：
平台作用减弱、公司利润或营收减少了，首当被裁。
如下引用大平台参考图片
