架构设计的演变历程

1、无框架结构,直接调用底层API
以往是底层平台(操作系统)提供API让上层APP去调用。
这样的软件控制权在APP上。举例 APP调用了平台的函数 Fun1,那么平台要对Fun1进行维护不敢随意改变这个函数,系统的更新成本大,上层APP越多,维护成本越大,导致到平台被局限。

2、单层框架结构
为了让系统开发者取得控制权,后来架构师们建造了一种框架结构。
APP开发者在这个框架的结构基础上开发自己的APP。
单层结构的模型是下图所示:

除了一部分平台的API仍然是由APP所调用外,更多是由框架反向调用APP来驱动整个APP的运行,框架定义出接口与基类,APP基础基类写出具象类,框架通过调用接口来实现对APP的反向调用,这也是IoC原理的核心。

3、复合型框架
为了满足更多元化的软件业务需求的开发,从单层框架基础上延伸除了复合型框架,
大框架和平台是系统开发者来开发,小框架可以系统开发者或者第三方厂商开发,比如游戏引擎,小框架是可以根据不同业务来选型,APP在这种大小框架结合的情境下开发大大的降低了开发难度,加快了开发速度。

4、双层框架
为了进一步完善框架,即平衡APP的开发速度也要提高APP的运行速度。
那么结合Java和C++两种语言的特性来构建这个框架,Java是应用层级与APP开发者最亲近,它是负责简化APP开发来设计的,从语言特性来说Java是更简单,容易被APP开发者所使用,C++是更运行性能高效,是负责性能担当,它与平台更亲近。
两者结合,使得APP的开发速度快,且运行速度快。

5、Android的框架
Android的框架就是采用上面的双层复合型框架的方式来构建的。其实现在很多框架都采用这种方式来构建。

举例个例子来了解下Android的底层框架原理。
1、Android的四大组件,Activity、service、BroadcastReceiver、ContentProvider。

他们的作为基类是由框架所定义的,APP的开发者想要用组件的功能只能是写子类来继承使用。如定义 myActivity,由框架所调用 new myActivity 创建出对象并被调用 onCreate方法来创建窗体页面。
模拟一下框架的实现:
Activity object = new myActivity();
object.onCreate();
哪有人会疑惑,框架的代码是在这个APP开发之前就有了,那么框架代码怎么会有myActivity这个类,myActivity这个类明明是APP开发者来写的,这个名称系统开发者不可能提前知道。
这就归功于 AndroidManifest.xml文档,Mani文档里面要求开发者把自己定义的Activity的名称写上。
在APP执行阶段(run-time)Android框架就会读取开发者所写的Mani的内容,从而得知到开发者所写子类的名称,就能创建出这些应用子类的对象。
如下图所示:

2、组件与组件之间的沟通:
从上面大家知道组件的子类虽然由APP开发者所写,但却由框架所创建,
同样,组件中的通信也是由框架所负责,框架是组件间沟通的桥梁。而沟通的介质是intent,中文翻译过来是意图,实际是跟信封一个道理。
你给远在他方的女朋友寄一封信,你只要按照邮局规定的格式来写这封信,比如写好寄信人信息,收信人信息,和信的内容,最后投递到邮局,最终通过邮局来把这一封信寄到你女朋友手里。
同样APP开发者只需要按照格式写好Intent交给框架,而至于框架怎么把Intent交给对方你就不需要关注。

如下图所示:

原文地址:https://www.cnblogs.com/zhuojun/p/5793253.html