架构设计的演变
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交给对方你就不需要关注。
如下图所示：
