架构篇-全局的设计考虑

要点：
架构师首先应该从用户的角度看软件的performance（表现）。在架构设计上，接口应该足够灵活，对软件的performance（性能）参数能够动态调整，以期达到一定自适应的效果。同时总体的架构设计应该考虑到移植性。
讨论：
优化绝对不是为了技术优化而优化。架构师首先要清楚软件所要达到的用户期望目标。这里以一个OMAP850（200MHZ ARM926EJ CPU）上的多媒体播放器为例。我们希望达到的目标是对300Kbps h.264 baseline+48kbps AAC+v1 可以做到audio流畅，video达到20-25fps（frames per second）。这是个基本目标。这个目标完全是从用户体验的角度来考虑的。用户可以接受video降低到15fps，但是不能容忍audio的停顿。用户可以接受video的quality降低，但是不能容忍audio，video的不同步。这些都是架构师要考虑的要点。在设计上，就要适当提高audio线程的优先级，要有丢帧的机制用于调整video的fps，对h.264，要有关闭deblock功能的机制，同样对于AAC+v1，要有SBR的开关。所有这些，都要求模块的接口要足够灵活，不仅能够在运行时动态调整性能，也能够扩展新的需求。另外在全局控制上，如线程优先级的调整，fps的控制，应该具有一定自适应的能力，
架构设计上的这种弹性正是为了保证软件的performance（表现）能够达到用户的心理期望值。设计的本质就是一种权衡，是各类相互制约的模块间的一种权衡。明白这一点，就要求架构设计上对各个模块应有灵活的控制，以保证用户期望目标为设计出发点，平衡各类资源的使用。
一个好的架构的概念是完整的，模块间的关系是清晰简洁，弱耦合的，模块的接口是抽象稳定的，模块的实现是强内聚和可扩展的。以这个播放器为例，如果移植到一个有color
Conversion硬件加速器的设备上，如果原先的color conversion模块的接口设计的好，就可以不用改动接口，或者只有一点简单的改动就可以将模块替换掉。
这里的问题好像转移倒可移植性去了，在嵌入式开发中，可移植性应该是架构师严肃思考的问题。面对不同的CPU，不同的OS，不同的硬件加速设备，架构的设计应该有足够的弹性去容纳这些变化。
可移植性强调了通用，而高效的优化是localize的。平衡这个矛盾需要良好的设计。上层模块不能依赖于下层实现，下层模块不能依赖于上层实现，上下层都要依赖于抽象，这就是设计中的依赖倒置原则(Dependency Inverse Principle)。总体的架构概念，或者说模块间的关系，模块的接口都是封闭的，固定的，而模块的实现是开放的，扩展的，这就是设计中的开闭原则（open/close principle）。这两个原则是保证软件的可移植性的基础。
可移植性主要包括CPU级移植和OS级移植。以这个播放器为例， codec 和color conversion模块基本上是CPU相关，而和OS无关。而上层控制模块，包括整个播放器的Framework，则主要是OS相关而与CPU无关。对单纯CPU相关的模块比较容易处理，在Item 15中我们会讨论这一类模块的移植问题。至于OS相关的部分，或者我们通常说的AP层，移植性的问题则需要非常仔细的考虑，和OS紧密相关的API如socket，thread，UI等
都要考虑增加一个adapter层，可以考虑定制使用第三方的跨平台类库。