关于架构

所谓架构设计其实就是：

c++中类一样， 定义内部所需 属性， 外部交互接口， 内部实现的功能。然后 需要执行体，即线程 把这些对象串接起来，实现交互，完成任务。所以需要确定对象种类，多少个执行线程。

就像，selinux中那样，定义了domain即进程执行体，和任何object都是死物，都是看成被操作的文件。

另外很好的名言，任何问题都可以通过加入中间层解决。

另外就是确定交互的关系网络，m：n的链接关系，例如cs结构，client，server结构中，多个client汇聚到一个server上的m：1交互关系，有server作为代理集中处理。作为对下层的唯一操作者，很好控制管理。也方便后面的调试，因为唯一接口加log即可看到所有控制者。

另外写驱动时，先确定对下硬件是什么总线连接，多层应用暴露什么接口，即提供什么功能，用什么子系统提供功能，例如input子系统，网络子系统等等。确定后，一切就是抄袭相关例子了。

另外相似对象，归类后，提取相同行为后，这样就可以定义接口了，这样这些对象都从那接口派生出来，这样就可以通过此接口操作他们这些对象了，即通过此接口使用他们的相同行为。

c++设计模式，是你更好的设计架构。

所以，把一切归为 对象 和 他们之间的交互关系，交互网络， 找到其中的合理的方式，可扩展的，可靠的，可量化的对象，可量化的行为，那么就设计好架构了。

接×××互，包括输入参数对象，输出结果对象，和回调， 例如对注册的回调，和输入参数的回调。

如何用线程，几个线程把他们串起来。

c++告诉我们，一切都是对象，对象有属性和接口，以表达他有什么功能属性，能干什么。

linux操作系统告诉我们，一切都是文件对象，和执行体（即中断，线程，等）。执行体操作对象，把一切交互起来，串起来。神经网络告诉我们，一切都是m：n的连接关系，即一个输入连接n个输出，一个输出连接m个输入。一切都是交互。所谓作用正向训练与反作用反向教训纠正。

关键调用路径中加入Hook点，方便调试和改变行为，也是架构设计中常用的一种技巧。

注意何时分配，何时释放

主要协议交互的 分层概念， 交互相方的层层对应， 明白pdu头，和sdu内容即data的概念。

像android那样，设计了相应的middleware，每种功能提供相应的service统一处理，每个service有相应的manager来交互， 应用通过manger与service交互，而不是直接与service交互。manager提供给应用对应的控制接口，实现应用的控制，而且manager也实现了对应用权限的管理。服务是单独进程环境，manager是跑在另外一个环境，可以是应用本身环境，这样manager可以得到应用的id，进而自己控制权限或者通知service应用的pid、uid，然后service来控制权限。这样是个很好的M:N架构模式。M是多个应用，N是多个service，或者N是一个service管理下的多个设备。 HAL层是为service从具体硬件中剥离出来，定义更好的抽象接口。service作为此功能的集中管理者，集中入口，方便监控和管理。

从安全性考虑，为了防止接口串改，权限的控制，还是service来控制，而不是manager来控制，当然linux、selinux、seandroid还有额外的权限控制。

好的架构，不是想出来的，而是不断的 “学习、参考别人架构和代码、实践试验、测试扩展、思考总结” 出来的。

好的架构是尽量去耦合，尽量使各个模块之前交互只使用接口，而不是直接访问别的模块的变量。另外模块的功能尽量局限在自己本模块内，每个模块实现专门的功能。不要一个功能遍及多个模块。

好的架构就是尽量去藕合，通用化。但是越通用越性能低下，所以需要平衡折中。加入中间层也是为了去藕合。

把所有东西看成对象，对象间用接×××互，而不直接暴露属性，甚至交互的信息也是对象化，例如android的parcel对象。好的中间层需要实现应对上层m个，下层n个，的m：n交互关系组织起来。

架构上，功能一定要专人专管（即某个功能专归某个进程管，那么就统一由他管），其他进程可以通过请求方式（进程间通信）请求状态变化或者状态查询。即其他进程只能通过它来间接控制此功能，不能直接控制。 这种专人专管，好处就是好写代码，否则代码太分散，不好同步，不好控制。另外，尽量控制某个特定功能的有唯一入口函数。不要入口分散，导致以后不好hook了，也不好加log调试，也不好中间加层和监控，也不好以后功能扩展了。（就像设计模式的façade模式）例如屏幕亮度统一由BacklightDaemon控制。

架构上，本地的调用和返回，就像RPC调用的request/respond。本地的register callback function和callback，就像RPC的register listener和callback，即subscribe订阅和publish发布。

其实架构设计，来来去去就是这些各种设计模式。围绕如何“去耦合”实现。

详细的说明，请见：

链接: 提取码: un1h

另外我的相关培训视频请看：

欢迎观看我发布的各个课程：

另外我的免费的linux各种驱动开发课程如下：