android 源码编译原理-从源码角度看Android

也想出现在这里？点击联系我~

立即下单

进入商城

进不了网站？换个网络试试！

今天推荐的是魅族MIUI系统工程师YogiAi开设的免费专栏《从源码角度看Android》。

关于专栏介绍，作者是这样写的：

从源码的角度看Android，关注本专栏，你将可以和我一起畅游源码的无尽乐趣世界。 阅读源码的重要性我就不细说了，大家都知道。 但你可以想象一下，有一天，通过你自己对AOSP源代码的理解，你会非常兴奋地让你口袋里的手机运行你自己更改和编译的系统:-)

以下是目前发表的九篇《从源代码角度看Android》的文章标题和介绍

1.Android SharedPreferences源码透视

SharedPreferences是Android中最常用的数据持久化方法。 其原理是通过读写shared_prefs目录下的xml文件来访问数据。 这个网上有很多文章，我就不重复了。 简单引用一下我自己画的时序图和一些我的使用建议，最后总结一下容易出现的ANR。

2、从源码来看，traces.txt是如何生成的

traces.txt位于Android系统的/data/anr目录下。 当系统中的应用程序发生ANR时，框架会弹出Dialog，同时转储各个线程的堆栈状态android 源码编译原理，方便开发者分析ANR的根本原因。

ANR 是应用程序未响应的缩写。 简而言之，它是Android系统提示用户应用程序界面没有响应的外部机制。 它用于防止应用程序界面仍然冻结并增加系统的用户友好性。

引起ANR的原因有很多，都是由于在主线程执行任务时阻塞界面更新时间过长造成的，主要有以下几类：

广播超时：前台广播执行超过10s，后台广播执行超过60s（需要注意的是，只有串行广播才有超时机制，并行广播不会超时，即如果广播是动态注册的，直接调用sendBroadcast触发，如果主线程Looper前面的消息不会触发超时机制，那么即使广播是前台广播，系统也绝对不会弹出框提示用户超时）

服务超时：前台服务星超过20s，后台服务星超过200s

Provider Timeout：内容提供者，发布超过10s

输入超时：按钮触摸干扰分布超过5秒

能够导致ANR的前提是该任务是在主线程上执行的。 执行什么样的任务主要有以下几点：

执行耗时任务，如文件读取或存储、网络访问获取文件时间过长

线程阻塞时间过长，或者只是死锁

线程饥饿，比如一共有16个Binder线程，其中1个被Binder主线程占用，剩下的15个工作线程全部被占用

CPU饥饿，负载值过大，虽然代码正常，但任务还没有来得及执行

那么回到traces.txt文件，它包含哪些信息可以帮助开发者找到ANR问题的症结呢？

在本文中，我从一个traces.txt的日志示例开始，然后通过跟踪源代码来解释traces.txt是如何生成的。

3、如何从源码层解析ContentService来实现数据变更窃听

ContentService是ContentResolver的服务器端，运行在system_server进程中，为所有应用程序提供对ContentProvider数据套接字的访问。 同时ContentService还提供了用于窃听数据变化的socket。 本文将从源码角度分析registerContentObserver和unregisterContentObserver的流程。

4.从源码角度看各种类型的Context

做应用开发的人对Context的熟悉程度应该仅次于Activity和Service。 Context，英文名称为context scene，代表对当前运行场景中各种信息的封装。 例如，如果需要调用四大组件来工作，就必须调用Context。 同时还可以通过Context获取Resource、Display、Theme、AssetManager、WallPaperManager等资源对象。

5、从源码角度看AMS.startProcessLocked

众所周知，Android系统是中国联通基于Linux内核的操作系统。 而Linux则使用fork来复制进程。 复制时，它仅创建轻量级操作，例如唯一标识符。 真正利用资源的是使用写时复制机制（copy-on-write）。 Linux世界中进程和线程的概念只是资源上的不同。 本质上，它们的内核实现都使用相同的task_struct结构，并且它们都有自己的PID和PPID。

在Android自己的底层框架的世界里，进程的概念在经过层层封装后早已变得模糊。 基础开发者只需要熟悉Activity、BroadcastReceiver、Service等四大组件的功能和使用场景即可完成开发流程。 结合上网、数据存储、UI绘制等业务逻辑就可以完成一个非常好的应用。

不过，研究Android的进程启动时序和实现原理，对进阶学习大有裨益。 不仅可以学到工艺线程的心智知识，还可以向设计大师学习包装的秘密。 Android应用进程的创建是通过fork Zygote进程来实现的，所以所有应用进程的PPID都是Zygote的PID。 复制Zygote实例后，您将获得一个虚拟机实例。 另外，新创建的进程会得到一个消息循环、Binder的进程通信池和一个Binder主线程。

在这篇文章中，我将详细分析Android进程的创建过程。

6.从源码角度看Binder.linkToDeath

Binder消息传递在Android系统中无处不在，从运行一个新的应用程序到发送常见的TIME PICK广播，再到注册一个ContentObserver来窃听电子邮件数据的变化，这些功能都需要使用Binder通信。 就像《人人必死》一样，system_server进程其实只要手机开机就存在，但无论普通应用程序的优先级有多高，当系统显存不足时，用户就会自动杀掉该应用程序进程，或者应用程序有无法解决的Bug，直接强制关闭。 此时，由于作为进程通信服务器的应用程序已死，因此无需保存相应客户端的相应服务器所保存的数据。 否则，如果手机不崩溃，system_server还活着，没有清除应用生死过程中死亡进程遗留下来的信息，那么使用这样的手机系统就会导致显存泄漏，并且系统资源会逐渐耗尽，直到用户可以感知到系统出现滞后。

因此，Binder进程通信必须有死亡反弹机制。 当通信服务器挂掉时，可以通知客户端进行相关的清理工作。 Android已经实现了一套DeathRecipient机制。 只要客户端实现死亡反弹binderDied方法但调用linkToDeath方法，当服务器死亡时就会调用binderDied。

7、从源码角度查看CPU相关日志

在Android系统中，普通开发者经常会遇到ANR（Application Not Responding）问题，即应用程序主线程没有响应。 根本原因在于Android框架的特殊设置，将用户能够敏锐感知的UI相关操作放到了一个专门的线程——主线程中。 一旦线程在规定时间内没有完成某项任务，比如广播onReceive、Activity跳转、bindApplication，框架就会形成所谓的ANR，弹出一个对话框，让用户选择继续等待或杀死尚未完成任务进程的应用程序。

通俗的说法就是开发者在主线程中进行了历时操作，导致任务执行时间过长。 此类问题一般都很容易定位和解决。 通常，错误报告（ANR 的根本原因）会被揭露。 不管有多糟糕android 源码编译原理，我们都不会。可以通过LOG定位耗时点。

今天我们要说的是另一种常见的情况。 这种情况往往是由于CPU硬件设备落后以及CPU底层控制策略不当造成的。 这种问题很烦人。 显然，按照常理，绝对不会有出现时长的地方，因为同样会导致ANR、卡顿，给用户带来非常糟糕的体验。

8、从源码角度看广播

几乎每个 Android 应用程序都不可避免地使用广播。 比如窃听WIFI的开启状态、获取时间，甚至我们最常用的闹钟功能都是通过AlarmManager与广播相结合来实现的。 了解广播注册、发送、接收的源码会让我们越来越了解Android系统。 同时，基于对广播的了解，我们也可以快速掌握AMS中其他组件的实现原理。

9、从源码角度看Activity生命周期

Activity是几乎所有中级Android程序员必须学习的知识点。 我们都知道Android最大的特点就是可以呈现用户界面，以便用户可以与应用程序进行交互。 最重要的基础类是每个Activity。 然而，很多Android开发者认为自己熟悉Activity生命周期、launchMode等知识点，并认为自己了解。 然而，事实上，情况并非如此。 Android源代码中埋藏着极其复杂的逻辑来支持Activity生命周期的变化。

最后，欢迎您关注编程迷公众号编程迷：