安卓源码系统service

⑴ 安卓原生系统是什么意思

原生安卓系统（android）是指Google公司发布，没有经过第三方修改的安卓系统，是操作系统最基层的也是最纯净的版本。

一般来说，主要是指各操作系统生产商最初建立的模型，各公司在模型的基础上再不断改进和优化，生产出不同的新版本。

(1)安卓源码系统service扩展阅读：

Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。

尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。Android操作系统最初由Andy Rubin开发，主要支持手机。

2005年8月由Google收购注资。2007年11月，Google与84家硬件制造商、软件开发商及电信营运商组建开放手机联盟共同研发改良Android系统。

随后Google以Apache开源许可证的授权方式，发布了Android的源代码。第一部Android智能手机发布于2008年10月。

Android逐渐扩展到平板电脑及其他领域上，如电视、数码相机、游戏机、智能手表等。2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。

2013年的第四季度，Android平台手机的全球市场份额已经达到78.1%。 2013年09月24日谷歌开发的操作系统Android在迎来了5岁生日，全世界采用这款系统的设备数量已经达到10亿台。

2014第一季度Android平台已占所有移动广告流量来源的42.8%，首度超越iOS。但运营收入不及iOS。

参考资料：网络---原生安卓

⑵ Android源码开发记录-自定义系统服务和jar包生成

创建文件 IMyApiService
文件路径 frameworks/base/core/java/android/os/

定义了一个计算和的方法。

在frameworks/base/Android.mk
LOCAL_SRC_FILES最后加入

创建文件 MyApiService.java
文件路径 frameworks/base/core/java/com/android/server/

实现aidl的接口，计算参数和。

（1）Context添加服务名
文件路径 frameworks/base/core/java/android/content/Context.java
添加

（2）添加启动服务
文件路径 frameworks/base/services/java/com/android/server/SystemServer.java
在startOtherServices方法中添加

创建 MyApiManager.java文件
文件路径 frameworks/base/core/java/android/app/

文件路径 frameworks/base/core/java/android/app/ContextImpl
添加registerService

记住make update-api
编译打包完成后，烧写新的固件。

jar主要为了在android studio编译环境中MyApiManager报错导致编译不通过问题。
也可以导入frameworks jar包或使用反射。

在源码目录packages/app下新建MyJar文件夹
并新建目录com/myapi/（包名）

在目录com/myapi/新建文件MyApi.java

具体Android.mk语法这里不做解释，可以自行查阅

在MyApi目录下直接运行mm编译命令（记得先source build/envsetup.sh）
待编译完成后，jar生成目录
out/target/common/obj/JAVA_LIBRARIES/Myapi_intermediates/javalib.jar
可更改为其他名称。

⑶ android中handler和service的区别是什么

任务、进程和线程
关于Android中的组件和应用，之前涉及，大都是静态的概念。而当一个应用运行起来，就难免会需要关心进程、线程这样的概念。在Android中，组件的动态运行，有一个最与众不同的概念，就是Task，翻译成任务，应该还是比较顺理成章的。
Task的介入，最主要的作用，是将组件之间的连接，从进程概念的细节中剥离出来，可以以一种不同模型的东西进行配置，在很多时候，能够简化上层开发人员的理解难度，帮助大家更好的进行开发和配置。

任务
在SDK中关于Task（guide/topics/fundamentals.html#acttask），有一个很好的比方，说，Task就相当于应用（application）的概念。在开发人员眼中，开发一个Android程序，是做一个个独门独户的组件，但对于一般用户而言，它们感知到的，只是一个运行起来的整体应用，这个整体背后，就是Task。
Task，简单的说，就是一组以栈的模式聚集在一起的Activity组件集合。它们有潜在的前后驱关联，新加入的Activity组件，位于栈顶，并仅有在栈顶的Activity，才会有机会与用户进行交互。而当栈顶的 Activity完成使命退出的时候，Task会将其退栈，并让下一个将跑到栈顶的Activity来于用户面对面，直至栈中再无更多 Activity，Task结束。

事件 Task栈
点开Email应用，进入收件箱（Activity A） A
选中一封邮件，点击查看详情（Activity B） AB
点击回复，开始写新邮件（Activity C） ABC
写了几行字，点击选择联系人，进入选择联系人界面（Activity D） ABCD
选择好了联系人，继续写邮件 ABC
写好邮件，发送完成，回到原始邮件 AB
点击返回，回到收件箱 A
退出Email程序 null

如上表所示，是一个实例。从用户从进入邮箱开始，到回复完成，退出应用整个过程的Task栈变化。这是一个标准的栈模式，对于大部分的状况，这样的Task 模型，足以应付，但是，涉及到实际的性能、开销等问题，就会变得残酷许多。比如，启动一个浏览器，在Android中是一个比较沉重的过程，它需要做很多初始化的工作，并且会有不小的内存开销。但与此同时，用浏览器打开一些内容，又是一般应用都会有的一个需求。设想一下，如果同时有十个运行着的应用（就会对应着是多个Task），都需要启动浏览器，这将是一个多么残酷的场面，十个Task栈都堆积着很雷同的浏览器Activity，是多么华丽的一种浪费啊。于是你会有这样一种设想，浏览器Activity，可不可以作为一个单独的Task而存在，不管是来自那个Task的请求，浏览器的Task，都不会归并过去。这样，虽然浏览器Activity本身需要维系的状态更多了，但整体的开销将大大的减少，这种舍小家为大家的行为，还是很值得歌颂的。
如此值得歌颂的行为，Android当然会举双手支持的。在Android中，每一个Activity的Task模式，都是可以由Activity提供方（通过配置文件...）和Activity使用方（通过Intent中的flag信息...）进行配置和选择。当然，使用方对Activity的控制力，是限定在提供方允许的范畴内进行，提供方明令禁止的模式，使用方是不能够越界使用的。
在SDK中（guide/topics/fundamentals.html#acttask），将两者实现Task模式配置的方式，写的非常清晰了，我再很絮叨挑选一些来解释一下（完整可配置项，一定要看SDK，下面只是其中常用的若干项...）。提供方对组件的配置，是通过配置文件（Manifest）<activity>项来进行的，而调用方，则是通过Intent对象的flag进行抉择的。相对于标准的Task栈的模式，配置的主要方向有两个：一则是破坏已有栈的进出规则，或样式；另一则是开辟新Task栈完成本应在同一Task栈中完成的任务。
对于应用开发人员而言，<activity>中的launchMode属性，是需要经常打交道的。它有四种模式："standard", "singleTop", "singleTask", "singleInstance"。
standard模式，是默认的也是标准的Task模式，在没有其他因素的影响下，使用此模式的Activity，会构造一个Activity的实例，加入到调用者的Task栈中去，对于使用频度一般开销一般什么都一般的Activity而言，standard模式无疑是最合适的，因为它逻辑简单条理清晰，所以是默认的选择。
而singleTop模式，基本上于standard一致，仅在请求的Activity正好位于栈顶时，有所区别。此时，配置成singleTop的Activity，不再会构造新的实例加入到Task栈中，而是将新来的Intent发送到栈顶Activity中，栈顶的Activity可以通过重载onNewIntent来处理新的Intent（当然，也可以无视...）。这个模式，降低了位于栈顶时的一些重复开销，更避免了一些奇异的行为（想象一下，如果在栈顶连续几个都是同样的Activity，再一级级退出的时候，这是怎么样的用户体验...），很适合一些会有更新的列表Activity展示。一个活生生的实例是，在 Android默认提供的应用中，浏览器（Browser）的书签Activity（BrowserBookmarkPage），就用的是singleTop。
singleTop模式，虽然破坏了原有栈的逻辑（复用了栈顶，而没有构造新元素进栈...），但并未开辟专属的Task。而singleTask，和singleInstance，则都采取的另辟Task的蹊径。标志为singleTask的Activity，最多仅有一个实例存在，并且，位于以它为根的Task中。所有对该Activity的请求，都会跳到该Activity的Task中展开进行。singleTask，很象概念中的单件模式，所有的修改都是基于一个实例，这通常用在构造成本很大，但切换成本较小的Activity中。在Android源码提供的应用中，该模式被广泛的采用，最典型的例子，还是浏览器应用的主Activity（名为Browser...），它是展示当前tab，当前页面内容的窗口。它的构造成本大，但页面的切换还是较快的，于 singleTask相配，还是挺天作之合的。
相比之下，singleInstance显得更为极端一些。在大部分时候singleInstance与singleTask完全一致，唯一的不同在于，singleInstance的Activity，是它所在栈中仅有的一个Activity，如果涉及到的其他Activity，都移交到其他Task中进行。这使得singleInstance的Activity，像一座孤岛，彻底的黑盒，它不关注请求来自何方，也不计较后续由谁执行。在Android默认的各个应用中，很少有这样的Activity，在我个人的工程实践中，曾尝试在有道词典的快速取词Activity中采用过，是因为我觉得快速取词入口足够方便（从notification中点选进入），并且会在各个场合使用，应该做得完全独立。
除了launchMode可以用来调配Task，<activity>的另一属性taskAffinity，也是常常被使用。taskAffinity，是一种物以类聚的思想，它倾向于将taskAffinity属性相同的Activity，扔进同一个Task中。不过，它的约束力，较之launchMode而言，弱了许多。只有当<activity>中的allowTaskReparen ting设置为true，抑或是调用方将Intent的flag添加FLAG_ACTIVITY_NEW_TASK属性时才会生效。如果有机会用到Android的Notification机制就能够知道，每一个由notification进行触发的Activity，都必须是一个设成FLAG_ACTIVITY_NEW_TASK的Intent来调用。这时候，开发者很可能需要妥善配置taskAffinity属性，使得调用起来的Activity，能够找到组织，在同一taskAffinity的Task中进行运行。

进程
在大多数其他平台的开发中，每个开发人员对自己应用的进程模型都有非常清晰的了解。比如，一个控制台程序，你可以想见它从main函数开始启动一个进程，到 main函数结束，进程执行完成退出；在UI程序中，往往是有一个消息循环在跑，当接受到Exit消息后，退出消息循环结束进程。在该程序运行过程中，启动了什么进程，和第三方进程进行通信等等操作，每个开发者都是心如明镜一本帐算得清清楚楚。进程边界，在这里，犹如国界一般，每一次穿越都会留下深深的印迹。
在Android程序中，开发人员可以直接感知的，往往是Task而已。倍感清晰的，是组件边界，而进程边界变得难以琢磨，甚至有了进程托管一说。Android中不但剥夺了手工锻造内存权力，连手工处置进程的权责，也毫不犹豫的独占了。
当然，Android隐藏进程细节，并不是刻意为之，而是自然而然水到渠成的。如果，我们把传统的应用称为面向进程的开发，那么，在Android中，我们做得就是面向组件的开发。从前面的内容可以知道，Android组件间的跳转和通信，都是在第三方介入的前提下进行，正由于这种介入，使得两个组件一般不会直接发生联系（于Service的通信，是不需要第三方介入的，因此Android把它全部假设成为穿越进程边界，统一基于RPC来通信，这样，也是为了掩盖进程细节...），其中是否穿越进程边界也就变得不重要。因此，如果这时候，还需要开发者关注进程，就会变得很奇怪，很费解，干脆，Android将所有的进程一并托管去了，上层无须知道进程的生死和通信细节。
在Android的底层，进程构造了底部的一个运行池，不仅仅是Task中的各个Activity组件，其他三大组件Service、Content Provider、Broadcast Receiver，都是寄宿在底层某个进程中，进行运转。在这里，进程更像一个资源池（概念形如线程池，上层要用的时候取一个出来就好，而不关注具体取了哪一个...），只是为了承载各个组件的运行，而各个组件直接的逻辑关系，它们并不关心。但我们可以想象，为了保证整体性，在默认情况下，Android肯定倾向于将同一Task、同一应用的各个组件扔进同一个进程内，但是当然，出于效率考虑，Android也是允许开发者进行配置。
在Android中，整体的<application>（将影响其中各个组件...）和底下各个组件，都可以设置<process>属性，相同<process>属性的组件将扔到同一个进程中运行。最常见的使用场景，是通过配置<application>的process属性，将不同的相关应用，塞进一个进程，使得它们可以同生共死。还有就是将经常和某个Service组件进行通信的组件，放入同一个进程，因为与Service通信是个密集操作，走的是RPC，开销不小，通过配置，可以变成进程内的直接引用，消耗颇小。
除了通过<process>属性，不同的组件还有一些特殊的配置项，以Content Provider为例（通过<provider>项进行配置...）。<provider>项有一个mutiprocess的属性，默认值为false，这意味着Content Provider，仅会在提供该组件的应用所在进程构造一个实例，第三方想使用就需要经由RPC传输数据。这种模式，对于构造开销大，数据传输开销小的场合是非常适用的，并且可能提高缓存的效果。但是，如果是数据传输很大，抑或是希望在此提高传输的效率，就需要将mutiprocess设置成true，这样，Content Provider就会在每一个调用它的进程中构造一个实例，避免进程通信的开销。
既然，是Android系统帮助开发人员托管了进程，那么就需要有一整套纷繁的算法去执行回收逻辑。Android中各个进程的生死，和运行在其中的各个组件有着密切的联系，进程们依照其上组件的特点，被排入一个优先级体系，在需要回收时，从低优先级到高优先级回收。Android进程共分为五类优先级，分别是：Foreground Process, Visible Process, Service Process, Background Process, Empty Process。顾名思义不难看出，这说明，越和用户操作紧密相连的，越是正与用户交互的，优先级越高，越难被回收。具体详情，参见：guide/topics/fundamentals.html#proclife。
有了优先级，还需要有良好的回收时机。回收太早，缓存命中概率低可能引起不断的创造进程销毁进程，池的优势荡然无存；回收的太晚，整体开销大，系统运行效率降低，好端端的法拉利可能被糟蹋成一枚QQ老爷车。Android的进程回收，最重要的是考量内存开销，以及电量等其他资源状况，此外每个进程承载的组件数量、单个应用开辟的进程数量等数量指标，也是作为衡量的一个重要标识。另外，一些运行时的时间开销，也被严格监控，启动慢的进程会很被强行kill掉。Android会定时检查上述参数，也会在一些很可能发生进程回收的时间点，比如某个组件执行完成后，来做回收的尝试。
从用户体验角度来看，Android的进程机制，会有很可喜的一面，有的程序启动速度很慢，但是在资源充沛的前提下，你反复的退出再使用，则启动变得极其快速（进程没死，只是从后台弄到了前台），这就是拜进程托管所赐的。当然，可喜的另一面就是可悲了，Android的托管算法，还时不时的展现其幼稚的一面，明明用户已经明显感觉到操作系统运行速度下降了，打开任务管理器一看，一票应用还生龙活虎的跳跃着，必须要手动帮助它们终结生命找到坟墓，这使得任务管理器基本成为Android的装机必备软件。
从开发角度上来看，Android这套进程机制，解放了开发者的手脚。开发人员不需要处心积虑的构造一个后台进程偷偷默默监听某个时间，并尝试用各种各样的守护手段，把自己的进程锻造的犹如不死鸟一辉一般，进程生死的问题，已经原理了普通开发人员需要管理的范畴内。但同时，于GC和人肉内存管理的争议一样，所有开发人员都不相信算法能比自己做得效率更高更出色。但我一直坚信一点，所有效率的优势都会随着算法的不断改良硬件的不断提升而消失殆尽，只有开发模式的简洁不会随时间而有任何变化。

组件生命周期
任何架构上的变化，都会引起上层开发模式的变化，Android的进程模型，虽然使开发者不再需要密切关注进程的创建和销毁的时机，但仍然需要关注这些时间点对组件的影响。比如，你可能需要在进程销毁之前，将写到内存上的内容，持久化到硬盘上，这就需要关注进程退出前发生的一些事件。
在Android中，把握这些时间点，就必须了解组件生命周期（Components Lifecycles）。所谓组件的生命在周期，就是在组件在前后台切换、被用户创建退出、被系统回收等等事件发生的时候，会有一些事件通知到对应组件上，开发人员可以选择性的处理这些事件在对应的时间点上来完成一些附加工作。
除Content Provider，其他组件都会有生命周期的概念，都需要依照这个模型定时定点处理一些状况，全部内容参见：guide/topics/fundamentals.html#lcycles。在这里，擒贼先擒王，还是拿Activity出来作楷模。

继续偷图，来自SDK。一个自然的Activity生命旅途，从onCreate开始，到onDestroy消亡。但月有阴晴圆缺组件有祸福旦夕，在系统需要的时候且组件位于后台时，所在的进程随时可能为国捐躯被回收，这就使得知道切入后台这个事情也变得很重要。
当组件进入栈顶，与用户开始交互，会调用onResume函数，类似，当退出栈顶，会有onPause函数被呼唤。onResume和onPause可以处理很多事情，最常规的，就是做一些文件或设置项的读写工作。因为，在该组件不再前台运行的时候，可能别的组件会需要读写同样一份文件和设置，如果不再onResume做刷新工作，用的可能就是一份脏数据了（当然，具体情况，还需要具体分析，如果文件不会被多头读写，可以放到onCreate里面去做读工作）。
除了前述切入后台会被其他组件骚扰的问题，另外，死无定因也是件很可怕的事情。在Android中，组件都有两种常见的死法，一种是自然消亡，比如，栈元素ABC，变成AB了，C组件就自然消亡了。这种死发轻如鸿毛，不需要额外关心。但另一种情况，就是被系统回收，那是死的重如泰山，为国捐躯嘛。
但这种捐躯的死法，对用户来说，比较费解。想象一下，一款游戏，不能存盘，你一直玩啊玩，三天三夜没合眼，这时候你mm打来电话鼓励一下，你精神抖擞的准备再接再厉，却发现你的游戏进程，在切入后台之后，被系统回收了，一夜回到解放前三天努力成为一场泡影，你会不会想杀做游戏的人，会不会会不会会不会，一定会嘛。这时候，如果没有Activity生命周期这码事，游戏程序员一定是被冤死的，成了Android的替罪羊。但是，Android的组件是有生命周期的， 如果真的发生这样情况，不要犹豫，去杀开发的程序员吧。
为了逃生，程序员们有一块免死金牌，那就是Android的state机制。所谓state，就是开发人员将一些当前运行的状态信息存放在一个Bundle对象里面，这是一个可序列化键值对集合。如果该Activity组件所处的进程需要回收，Android核心会将其上Activity组件的Bundle对象持久化到磁盘上，当用户回到该Activity时候，系统会重新构造该组件，并将持久化到磁盘上的Bundle对象恢复。有了这样的持久化的状态信息，开发人员可以很好的区分具体死法，并有机会的使得死而复生的Activity恢复到死前状态。开发者应该做的，是通过onSaveInstanceState函数把需要维系的状态信息（在默认的状态下，系统控件都会自己保存相关的状态信息，比如TextView，会保存当前的Text信息，这都不需要开发人员担心...），写入到Bundle对象，然后在onRestoreInstanceState函数中读取并恢复相关信息（onCreate，onStart，也都可以处理...）。

线程
读取数据，后台处理，这些猥琐的伙计，自然少不了线程的参与。在Android核心的调度层面，是不屑于考量线程的，它关注的只有进程，每一个组件的构造和处理，都是在进程的主线程上做的，这样可以保证逻辑的足够简单。多线程，往往都是开发人员需要做的。
Android的线程，也是通过派生Java的Thread对象，实现Run方法来实现的。但当用户需要跑一个具有消息循环的线程的时候，Android有更好的支持，来自于Handler和Looper。Handler做的是消息的传送和分发，派生其handleMessage函数，可以处理各种收到的消息，和win开发无异。Looper的任务，则是构造循环，等候退出或其他消息的来临。在Looper的SDK页面，有一个消息循环线程实现的标准范例，当然，更为标准的方式也许是构造一个HandlerThread线程，将它的Looper传递给Handler。
在Android中，Content Provider的使用，往往和线程挂钩，谁让它和数据相关呢。在前面提到过，Content Provider为了保持更多的灵活性，本身只提供了同步调用的接口，而由于异步对Content Provider进行增删改查是一个常做操作，Android通过AsyncQueryHandler对象，提供了异步接口。这是一个Handler的子类，开发人员可以调用startXXX方法发起操作，通过派生onXXXComplete方法，等待执行完毕后的回调，从而完成整个异步调用的流程，十分的简约明了。

实现
整个任务、进程管理的核心实现，尽在ActivityManagerService中。上一篇说到，Intent解析，就是这个ActivityManagerService来负责的，其实，它是一个很名不副实的类，因为虽然名为Activity的Manager Service，但它管辖的范围，不只是Activity，还有其他三类组件，和它们所在的进程。
在ActivityManagerService中，有两类数据结构最为醒目，一个是ArrayList，另一个是HashMap。 ActivityManagerService有大量的ArrayList，每一个组件，会有多个ArrayList来分状态存放。调度工作，往往就是从一个ArrayList里面拿出来，找个方法调一调，然后扔到另一个ArrayList里面去，当这个组件没对应的ArrayList放着的时候，说明它离死不远了。HashMap，是因为有组件是需要用名字或Intent信息做定位的，比如Content Provider，它的查找，都是依据Uri，有了HashMap，一切都顺理成章了。
ActivityManagerService用一些名曰xxxRecord的数据结构，来表达各个存活的组件。于是就有了，HistoryRecord（保存Activity信息的，之所以叫History，是相对Task栈而言的...），ServiceRecord，BroadcastRecord，ContentProviderRecord，TaskRecord，ProcessRecord，等等。
值得注意的，是TaskRecord，我们一直再说，Task栈这样的概念，其实，真实的底层，并不会在TaskRecord中，维系一个Activity 的栈。在ActivityManagerService中，各个任务的Activity，都以HistoryRecord的形式，集中存放在一个 ArrayList中，每个HistoryRecord，会存放它所在TaskRecord的引用。当有一个Activity，执行完成，从概念上的 Task栈中退出，Android是通过从当前HistoryRecord位置往前扫描同一个TaskRecord的HistoryRecord来完成的。这个设计，使得上层很多看上去逻辑很复杂的Task体系，在实现变得很统一而简明，值得称道。
ProcessRecord，是整个进程托管实现的核心，它存放有运行在这个进程上，所有组件的信息，根据这些信息，系统有一整套的算法来决议如何处置这个进程，如果对回收算法感兴趣，可以从ActivityManagerService的trimApplications函数入手来看。
对于开发者来说，去了解这部分实现，主要是可以帮助理解整个进程和任务的概念，如果觉得这块理解的清晰了，就不用去碰ActivityManagerService这个庞然大物了。

================
这是转载的 ，感觉比一楼说的好

=============
一下是自己的

服务（Service）需要配置 才能使用
线程 使用就不说了
hanler ，是用来进行消息队列的一个东东，handler 可以用来更新控件的显示 ，以及线程之间的通信，
service只能启动后台，属于应用组件之一

⑷ android怎么修改源码

1、通过 ubuntu 软件中心安装 wine；
2、通过 ubuntu 软件中心安装 winetricks;
3、通过 winetricks 在 shell中输入： winetricks mfc42

1、通过 wine windows 的方式启动代理服务器
2、设置浏览器代理服务器
3、设置shell代理服务器：
在shell中输入 sudo gedit /etc/bash.bashrc
在文件 /etc/bash.bashrc 中添加

通过shell安装如下的组件：
1、sudo apt-get install bison g++-multilib git gperf libxml2-utils
2、新建一个存放源码的目录，如：mkdir ~/andorid/source
3、在源码目录中输入命令：repo init -u -b android-4.0.1_r1
其中： android-4.0.1_r1是android源码的版本，更多的版本可以通过下面的方式查询：

4、修改source/.repo/manifest/default.xml 文件中的 fetch 的值为：
git://Android.git.linaro.org/

通过如下的指令来设置邮箱和用户名
git config --global user.name "<your name>" ----修改用户名git config --global user.email "<your email>" ----修改email
5、在source目录下输入指令：repo sync
便开始了代码的下载
方便他人亦是方便自己，如果觉得还行就点下下边的投票吧，这样可以帮助其他人更快的找到解决问题的方法；有疑问的也可留言哦， 谢谢！

⑸ 最近在看android音乐播放器的源码，发现播放音乐等操作都是用service来进行的，这样做有什么好处求解

首先service的启动方式有两种,Context.startService()方式启动和Context.bindService()方式启动.前者如果你的程序退出时不停止Service,它会在后台一直运行.后者是跟你的程序绑定了,你的程序退出时Service也停止了.详细的你去查一下.用Service的好处就是当你的程序进入后台时,不影响音乐的播放.如果没有把播放音乐写在Service中当你的播放器进入后台或者退出时音乐就停止了.

⑹ Android源码解析Window系列第（一）篇---Window的基本认识和Activity的加载流程

您可能听说过View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道这几个类是什么关系，干嘛用的。概括的来说，View是放在Window中的，Window是一个抽象类，它的具体实现是PhoneWindow，PhoneWindow还有个内部类DecorView，WindowManager是一个interface，继承自ViewManager，它是外界访问Window的入口，，提供了add/remove/updata的方法操作View，WindowManager与WindowManagerSerice是个跨进程的过程，WindowManagerService的职责是对系统中的所有窗口进行管理。如果您不太清楚，建议往下看，否则就不要看了。

Android系统的Window有很多种，大体上来说，Framework定义了三种窗口类型；

这就是Framework定义了三种窗口类型，这三种类型定义在WindowManager的内部类LayoutParams中，WindowManager讲这三种类型 进行了细化，把每一种类型都用一个int常量来表示，这些常量代表窗口所在的层，WindowManagerService在进行窗口叠加的时候，会按照常量的大小分配不同的层，常量值越大，代表位置越靠上面， 所以我们可以猜想一下，应用程序Window的层值常量要小于子Window的层值常量，子Window的层值常量要小于系统Window的层值常量。 Window的层级关系如下所示。

上面说了Window分为三种，用Window的type区分，在搞清楚Window的创建之前，我们需要知道怎么去描述一个Window，我们就把Window当做一个实体类，给我的感觉，它必须要下面几个字段。

实际上WindowManager.LayoutParams对Window有很详细的定义。

提取几个重要的参数

Window是一个是一个抽象的概念，千万不要认为我们所看到的就是Window,我们平时所看到的是视图，每一个Window都对应着一个View，View和Window通过ViewRootImpl来建立联系。有了View，Window的存在意义在哪里呢，因为View不能单独存在，它必须依附着Window，所以有视图的地方就有Window,比如Activity,一个Dialog,一个PopWindow,一个菜单，一个Toast等等。

通过上面我们知道视图和Window的关系，那么有一个问题，是先有视图，还是先有Window。这个答案只有在源码中找了。应用程序的入口类是ActivityThread，在ActivityThread中有performLaunchActivity来启动Activity，这个performLaunchActivity方法内部会创建一个Activity。

如果activity不为null,就会调用attach,在attach方法中通过PolicyManager创建了Window对象，并且给Window设置了回调接口。

PolicyManager的实现类是Policy

这样Window就创建出来了， 所以先有Window，后有视图，视图依赖Window存在 ，再说一说视图（Activity）为Window设置的回调接口。

Activity实现了这个回调接口，当Window的状态发生变化的时候，就会回调Activity中实现的这些接口，有些回调接口我们还是熟悉的，dispatchTouchEvent，onAttachedToWindow，onDetachedFromWindow等。

下面分析view是如何附属到window上的，通过上面可以看到，在attach之后就要执行callActivityOnCreate，在onCreate中我们会调用setContentView方法。

getWindow获取了Window对象，Window的具体实现类是PhoneWindow,所以要看PhoneWindow的setContentView方法。

这里涉及到一个mContentParent变量，他是一个DecorView的一部分，DecorView是PhoneWindow的一个内部类，我先介绍一下关于DecorView的知识。

DecorView是Activity的顶级VIew，DecorView继承自FrameLayout,在DecorView中有上下两个部分，上面是标题栏，下面是内容栏，我们通过PhoneWindow的setContentView所设置的布局文件是加到内容栏（mContentParent）里面的，View层的事件都是先经过DecorView在传递给我们的View的。

OK在回到setContentView的源码分析，我们可以得到Activity的Window创建需要三步。

- 1、 如果没有DecorView，在installDecor中创建DecorView。

- 2、将View添加到decorview中的mContentParent中。

- 3、回调Activity的onContentChanged接口。

先看看第一步，installDecor的源码

installDecor中调用了generateDecor，继续看

直接给new一个DecorView，有了DecorView之后，就可以加载具体的布局文件到DecorView中了，具体的布局文件和系统和主题有关系。

在看第二步，将View添加到decorview中的mContentParent中。

直接将Activity视图加到DecorView的mContentParent中，最后一步，回调Activity的onContentChanged接口。在Activity中寻找onContentChanged方法，它是个空实现，我们可以在子Activity中处理。

到此DecorView被创建完毕，我们一开始从Thread中的handleLaunchActivity方法开始分析，首先加载Activity的字节码文件，利用反射的方式创建一个Activity对象，调用Activity对象的attach方法，在attach方法中，创建系统需要的Window并为设置回调，这个回调定义在Window之中，由Activity实现，当Window的状态发生变化的时候，就会回调Activity实现的这些回调方法。调用attach方法之后，Window被创建完成，这时候需要关联我们的视图，在handleLaunchActivity中的attach执行之后就要执行handleLaunchActivity中的callActivityOnCreate，在onCreate中我们会调用setContentView方法。通过setContentView，创建了Activity的顶级View---DecorView,DecorView的内容栏（mContentParent）用来显示我们的布局。 这个是我们上面分析得到了一个大致流程，走到这里，这只是添加的过程，还要有一个显示的过程，显示的过程就要调用handleLaunchActivity中的handleResumeActivity方法了。最后会调用makeVisible方法。

这里面首先拿到WindowManager对象，用tWindowManager 的父接口ViewManager接收，ViewManager可以
最后调用 mDecor.setVisibility(View.VISIBLE)设置mDecor可见。到此，我们终于明白一个Activity是怎么显示在我们的面前了。
参考链接：
http://blog.csdn.net/feiclear_up/article/details/49201357

⑺ Android Service启动Activity

Android Service 基础知识点

我们都知道Activity中启动Activity，只需要startActivity，如果在Service中启动Activity呢？

在Service中启动Activity，很多人说在非Activity中启动Activity需要加FLAG_ACTIVITY_NEW_TASK flag，如果我不加会怎么样呢？

并没有出现异常和崩溃，跳转也是正常的，但是与之前所说的会崩溃报出异常不符合啊？！难道是与版本有关吗？大友于是我使用了Android 23去测试果然抛出了异常

ContextImpl在Android studio中属于隐藏源码，在IDE中可能看不到，那就需要在SDK中去找 我的是：D:\AndroidSdk\sources\android-23\android\app\ContextImpl.java

可以看到只是判断条件不同而已，android-23中发现没有Intent.FLAG_ACTIVITY_NEW_TASK会直接抛出异常，而android-26中我们在非 Activity 调用 startActivity() 的时候，我们这个 options 通常是 null 的，所以在 26 之间的时候，误把判断条件 options == null 写成了 options != null 导致进不去 if，从而不会抛出异常

附加：在android 24-android 27（即android N-android O）之间出现了bug，也就是说即使没有加Intent.FLAG_ACTIVITY_NEW_TASK也会正常跳转激仿销

可以很明显看到判断条件targetSdkVersion <明游 Build.VERSION_CODES.N || targetSdkVersion >= Build.VERSION_CODES.P 即在24-27

看Activity中启动Activity的源码

Activity.startActivity() ->startActivityForResult()->mInstrumentation.execStartActivity() ...最终还是Ams去启动Activity 也就是Activity中重写了startActivity()方法所以不会出现这个异常

其实直观很好理解，如果不是在Activity中启动的，那就可以看做不是用户主动的行为，也就说这个界面可能出现在任何APP之上，如果不用Intent.FLAG_ACTIVITY_NEW_TASK将其限制在自己的Task中，那用户可能会认为该Activity是当前可见APP的页面，这是不合理的。举个例子：我们在听音乐，这个时候如果邮件Service突然要打开一个Activity，如果不用Intent.FLAG_ACTIVITY_NEW_TASK做限制，那用户可能认为这个Activity是属于音乐APP的，因为用户点击返回的时候，可能会回到音乐，而不是邮件（如果邮件之前就有界面）

对比源码发现，在我们非 Activity 调用 startActivity() 的时候，我们这个 options 通常是 null 的，所以在 24~27 之间的时候，误把判断条件 options == null 写成了 options != null 导致进不去 if，从而不会抛出异常，如此我们使用 Context.startActivity() 的时候是一定要加上 FLAG_ACTIVITY_NEW_TASK 的，但是在 Android N 到 O-MR1，即 24~27 之间却出现了 bug，即使没有加也会正确跳转

结语：感谢各位大佬的分享，对此有疑问的可以去运行跑一下，看一下相关的源码，如有错误的需要改进的地方，请留言评论指出，谢谢！

参考文章：

⑻ 怎样评价罗升阳的android系统源代码分析

我干了3年Android sdk开发，觉得到了瓶劲没法更进一步，于是花了一年多点时间，大概摸到点门径。根据前辈的经验，Android底层完全入门需要两年。 先说下我的入门过程： 第零步，下载源码，我下的4.2的，框架层源码10G，内核2G多，ctags给框架层建的标签文件都有600M，当时让我有点震撼，用的vim+ctags+cscope来阅读，还算不错，架构挺清晰的。 第一步，我找到了一本好书《Android的设计与实现 第一卷》它讲了Android框架层的启动，初始化，服务框架初始化，Binder，消息循环，PackageManagerService，ActivityManagerService。据作者说后面会出讲UI子系统的第二卷，拭目以待。其实这本书看了几十页我就发现需要第二步的知识，否则看不下去，于是跳去第二步。 第二步，学习Linux系统编程，在看《Android的设计与实现》的时候我发现，框架层的Native部分，全是Linux编程。为了掌握这部分知识，我花了4个月学习了《Linux系统编程手册》（TLPI）这本1000多页的书，我以前是搞WIndows文件系统这块的，所以C语言还比较熟，TLPI的习题很有意思，量也比较大，坚持下来还是收获很多。 第三步，花了4个月学习了一些Linux内核的知识，看了LKD，PLKA看了一半多。越学越没底，觉得不懂得越来越多，不过这个也正常，只有靠慢慢磨，估计以后要不断的磨这块。 第四步，回头看Android源码，这次一口气看完了《Android的设计与实现 第一卷》，终于对框架层有了谱。同时真的数次把我看晕，前面看Linux内核源码都没这么晕，不断在Java层和Native层之间跳有点磨脑浆。其中我又觉得Java的基础没有打太牢，回去补了一个月的《Core Java》第八版。但是这书没有涉及UI子系统，于是又看了《Android内核剖析》 第五步，《Android内核剖析》（这本书实际上是讲框架层的，作者也是个搞嵌入式的，所以他在写框架层的时候文笔不太好，很罗嗦，不过还是有很多看点，到他后来写做ROM，玩开发板时估计是说到了他的本行，一下子遛起来了看得出还是挺有水平的，这本书知识有点旧毕竟讲的是2.3很多代码已经过时，但是作者很多点子很有参考价值）这本书讲UI子系统和按键/触摸消息处理系统还是很有分量的，尤其13章View绘制那里，结合源码研究很有收获。而后面他讲编译框架和ROM相关的东西都是挺宝贵的资料。 第六步，为了再补一下其他诸如电源管理模块等子系统的知识看了，《深入理解android》系列，个人认为这个系列看起来有点不太舒服，不过作为补充印证还是比较有价值。 第七步，《Android系统源代码情景分析》，罗升阳的源码分析大作，比《Android的设计与实现》分析得更细致，但缺点是涉及到模块比较少，选用的源码也比《Android的设计与实现》更旧一点。看完书后需要去研究作者的博客，东西挺多的，一定让你满意。 第八步，买块开发板自己玩。这步我还没走到，原因是我觉得我还差点准备知识。可能要再几个月，到时准备入块6410或者树莓派。 最后，由于我11年以前都是搞Windows这块的，所以对Linux知识不是很了解，不得已看了这么些书，如果是一直做Linux的人，很多步骤估计可以省掉了。直接上源码才是正道。 我本身做着移动GIS开发的工作，学框架层全是因为兴趣，但招聘平台Android框架层开发人员还是蛮有竞争力的有不少定制ROM，智能电视的工作都处于人才难求状态，毕竟有一定的门槛，现在各种ios培训，让奔着钱干开发的人纷纷涌入，而ios只能干sdk开发的缺点就暴露出来了，一堆新手老手，菜鸟大牛全挤在SDK开发这块，我觉得不太妙。 反观Android这边，虽然入门菜鸟没有搞ios来钱，但是可持续性很好，从sdk-》框架》驱动》内核这样干下去。干着干着发现自己渐渐变成了Linux开发者/嵌入式开发者的人也不少，新人，老手，菜鸟大牛各居其位，层次性很好。 转载