花花鞋1、架构中常见的专业术语
想深入学习框架方面的知识，我们首先得明白框架中常见的名词有哪些，以及它们含义和区别是什么。
框架中常见的名词有：系统和子系统，模块和组件，框架和架构
2、术语解释
2.1、系统
维基百科解释：
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。
特征解析：
关联：也就是系统必须得是一些有关联的个体组成的，例如我们在搭建一个系统的时候会去发现该系统应该由哪些个体组成，不相干的个体我们是不会考虑进来的。以Android 操作系统为例，如下图：
Android操作系统是有一些软件组成的，包括：应用程序层，应用程序框架层，系统库，Android运行时，linux内核。但是IOS的运行时和这些是没有关联的，所以它就不是Android操作系统的一部分。
规则：系统内的个体按照某种规则运作，以Android为例，系统中每一层都有自己的职责，每一层都为它的上一层提供服务。例如Linux内核为其上面的系统库提供了操作硬件的能力，而系统库为应用程序框架层提供了基础的网络，存储，媒体等功能，同时应用程序框架层为应用程序层里丰富多样的程序提供了所需的基础的服务。正因为Android规定了这样的系统内个体的分工和协作方式，才能让应用程序能够在系统上正常的运行。
不能单独完成的工作：在Android系统出来之前，蓝牙，摄像头，linux都早已存在，这些个体有着自己不可替代的能力，但是Android系统将它们有序的组织在一起，它们产生了新的能力，而这个能力的确是每个个体所无法完成的。
2.2、子系统
子系统顾名思义，它也是一个系统，也就是说仍然是完整的实体。系统和子系统的概念是相对的，当作为另一个系统的一部分时，系统就成为一个子系统。
在Android中我们也经常提到子系统，例如：输入子系统，图形子系统。以图形子系统为例，它也是一个完整的实体，但它是Android系统的一部分，所以它是Android系统的子系统：
2.3、模块和组件
模块和组件非常容易混淆，我总结就是从逻辑角度拆分得到的单元是模块，从技术角度（物理角度）拆分得到的单元是组件。可能比较抽象，依然举Android框架的例子，它的Framework应用程序框架层，从整体Framework的逻辑拆分，它应该包含包管理（PackageManager），资源管理（ResourceManager），位置管理（LocationManager），消息管理（NotificationManager）等模块，换言之逻辑角度少了某一块这个Framework都不是完整逻辑上的Framework，模块拆分（也叫逻辑拆分）保证了一个系统能完整的被拆解。
然后再来说组件，组件是我们再模块拆分之后，指导我们技术开发的拆分方法，例如我们在做设计时经常提到要功能复用，其实就是要做出一个功能可以复用的组件。以Android框架为例，Framework应用程序框架层，从技术角度（物理角度）又有注明的四大组件：Activity，Service，BroadcastReceiver，ContentProvider。这四大组件在Framework的各个模块里面都是可以复用的，例如包管理模块的PackageManagerService.java，WindowManagerService.java。也许你会说我看到这些Service虽然名字叫service，但是他们并没有继承Service呀，其实继承Service的方式主要在应用程序层使用，并通过在Manifest里面配置注册到系统中，而对于框架层他们使用下面这样一种方式：
|
1 2 3 4 5 6 7 |
public static final IPackageManager main(Context context, Installer installer, boolean factoryTest, boolean onlyCore) { PackageManagerService m = new PackageManagerService(context, installer, factoryTest, onlyCore); ServiceManager.addService("package", m); return m; } |
2.4、框架与架构
框架和架构也比较相似，同样总结一句话就是框架是遵照一个业内的规范，并实现规范要求的基础功能的产品。而架构描述的是一个系统的结构。
2.4.1、框架
以阿里的开源框架ATLAS为例，从它的官方描述我们知道，它以业界的OSGI规范（OSGi(Open Service Gateway Initiative)技术是Java动态化模块化系统的一系列规范）为参考，并提供了解耦化、组件化、动态性的支持。
2.4.2、架构
架构是一个系统的结构，我们经常看到有些文章在描述一个系统的架构的时候使用到了不同种类的图，这是因为我们无法用一张图来完整的设计一个系统的架构。这就引入了另一个概念——“4+1视图”
我们看下软件架构的定义：
软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改：
软件架构 ＝ {元素，形式，关系/约束}
软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图 1）：
- 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
- 过程视图（Process View），捕捉设计的并发和同步特征。
- 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
- 开发视图（Development View），描述了在开发环境中软件的静态组织结构。
架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来。
3、总结
通过这篇文章我们明白了在做一个系统架构时所需要知道的专业术语，这样可以让我们更清晰的了解如何去分析和指导我们如何设计一个系统的架构。我的一个体会是，不会在盲目的相信其他人对某一个系统的分析了，看似很酷的架构图，可能不符合架构设计的某些要求，这样的一个后果是这个架构图不能指导我们实际的开发工作，不能全面的识别一个系统所面临的风险和所需要的关联资源。所以架构师是一个很关键的岗位，它的最终设计会影响到该产品后续发展的形态和研发技术方向的决策。
