概述
其实我们写的App并不是一个完整的程序。我们写的只是一个套件组，就是一堆Activity，Service等等的组件。这个套件组给framework框架组合在一起才是一个完整的程序。在这里先说一个概念，也就是EIT模型。E是Engine发动机，I是Interface接口，T是tire轮胎。也就是发动机通过接口接上轮胎，然后车子才能跑。然后框架提供的就是E&I，一般框架都是提供发动机和接口，让我们来做轮胎，然后装上就可以跑起来了。（这里的I也可以理解为抽象函数，因为抽象函数就相当于接口嘛）抽象类也就是把发动机和接口，放在一个类里。像Activity，提供了一个接口函数（卡隼函数）onCreate（），我们写myActivity，就要重写onCreate（），Activity这个抽象类就是发动机，onCreate（）就是接口，myActivity就是轮胎。当框架要Activity运行的时候调onCreate（）方法，就带动了myActivity的运行。我们写在onCreate（）中的代码就得到了执行。
Android框架这样做的好处就是牢牢掌握控制权，要求开发者必须在我给你的接口中装填代码，我框架内容千变万化你都不用管，你老老实实在我给你的接口填代码就行了，整个生命周期都由我框架来掌控。试想，如果不通过这种模式，不是给App开发者提供接口，而是直接的函数调用，那框架就要受制于App开发者，这个函数用的人越多，函数改动的成本就越高。框架就被迫不能改变，慢慢也就死了。而通过EIT模型，提供给开发者的只是一个接口，框架对App开发者就是透明的，你只需要在接口中做事就行了，这样就更规范和灵活。关于什么时候new Activity的对象是由framework框架来控制的。Manifest文件里把Activity注册上，是因为framework框架要new Activity的时候知道去哪找这个子类。而且这个对象有什么初始值，比如响应什么样的intent。这样App的启动也就好理解了，点击桌面图标，由frameWork框架捕获这个事件，去找这个图标对应的App的Manifest里面找到要启动的第一个Activity，就是那个在Manifest里注明是main和luncher的。然后由framework框架new出这个myActivity对象。自然也就new出了基类Activity对象，然后framework框架调用Activity的onCreate（），实际对象是myActivity，执行的也就是myActivity的onCreate（）。这时候App就启动了。
由此可见，任何控制类程序都有一个入口，安卓应用程序同样也是。
Android framework包含三个小伙伴：服务端、客户端、linux驱动。
