Activity是Android负责与用户交互的实体。一个应用一般由多个Activity组成;一个Activity不仅可以打开应用内的Activity，也可以打开其他应用内的Activity，比如通过一个名为android.intent.action.VIEW的Intent事件可以打开浏览器；通过android.intent.action.DIAL可以向CALL发送拨号请求。一系列的Activity组合在一起（完成某个特定的“任务“）构成了一个任务（一个后进先出的队列，被称为back stack），而多个任务又构成了一个任务栈（后台可以有多个任务栈，但系统如需恢复内存，则会杀死部分应用，清空部分任务，以释放内存，因此长时间后应用状态会丢失）。以下图为例，图中的back stack一开始只有一个Activity1；接着在Activity1中启动Activity2，此时Activity2位于队列的顶部，而Activity1位于栈底（Activity1处于Stop状态），而Activity2又启动一个Activity3，同样，Activity3压入栈顶。如果此时通过回退键（Back）用户离开Activity3,则Activity3从栈中清除，被系统销毁，而Activity2则恢复到可见状态(resume)。

ANR即Application Not Responding, 应用无响应：当应用在某一个时间内无法及时响应用户请求时，系统会弹出一个对话框，告知用户应用无法响应。此时，用户可以选择关闭应用。对于Android应用来说，有一个UI线程(主线程）专门负责与用户交互，如果在此线程中进行耗时的操作，比如读取磁盘数据、从网络下载资源等IO操作，通常会导致UI线程阻塞，从而无法及时处理用户的输入请求，发生ANR。

Android是通过AMS跟WMS来监控应用响应状态的，一般有如下两种ANR情况：

• 应用在给定时间内没有对用户输入(按键或者触屏操作）做出响应，通常是5s;
• 广播接收者(BroadcastReceiver)没有在10s内处理完成；

对于输入无响应的情况，native监控到输入无响应时，则告知WMS，最后由WMS发送消息告诉AMS，某个应用发送了ANR，最后AMS会弹出Application Not Responding的对话框，请求用户关闭应用；对于广播无响应的情况是由AMS负责处理的，AMS对于每个发送出去给广播接收者的广播都有一个10s的定时，如果广播接收者在10s内尚未处理完，则视为无响应，因此也会弹出Application Not Responding。

在之前的一篇文章(Glide架构分析 )中介绍了Glide的具体原理。这篇文章，用一个下载图片的示例来说明Glide加载图片的整个过程。以下是用Glide从网络上加载一个图片的代码片段：

1
2
3
4
5
6
7
8
9

    
Glide
  .with(activity) // Activity
  .load(url)
  .centerCrop()
  .placeholder(R.drawable.loading_spinner)
  .crossFade()
  .into(myImageView);

大致说来，在Glide中图片的加载有如下几个过程：

• 产生一个图片加载的请求GenericRequest<T>;
• 将图片加载请求发送给资源引擎中心Engine,由其负责资源的加载以及数据解码任务的管理；
• EngineRunnable首先尝试从DISK加载资源，完成后进行回调，将数据加载到ImageView中；
• 磁盘中没有请求对应的资源，则尝试从网络端下载，并解码完成后回调，将数据加载到Target对象；

现在就来详细的看下Glide加载图片的整个过程。

与Java程序类似，Android应用程序框架层(Application Framework)以及APP运行在一个Dalvik Virtual Machine之上，那么，Android启动时框架层是如何初始化的，从何处初始化的？为此，Android在启动时会首先初始化一个专门的系统进程zygote来负责启动与初始化Java代码，比如系统服务进程system_server的启动，系统启动时各种Java服务的初始化，APP资源文件的加载，APP进程的创建与启动。这篇文章，主要讲zygote进程的两个问题：

• zygote进程如何初始化的；
• APP进程是如何通过zygote创建的？

Glide是BumpTech开发的一个同时可支持图片、GIF以及视频加载的Android开源库，同时Glide支持任何用户自定义的网络栈，其主要有以下几个特点：

• 支持GIF格式动画的解码；
• 支持本地视频加载解码；
• 加载大图之前，可预先加载一个小图片
• 自动管理资源加载请求的生命周期；
• 给定图片尺寸，可以对资源进行自由转换

Github：https://github.com/bumptech/glide

这里就来分析下Glide的具体架构以及介绍其主要特点，分如下几个方面：

• Glide代码架构及工作原理；
• Glide如何自动管理资源加载请求的生命周期的？
• Glide是如何进行图片的加载与转换的？

Picasso是SquareUp公司开源的专门为Android平台量身制作的图片加载库。通过Picasso，用户可以方便的将图片加载到特定的ImageView中，而不用关心图片是在一个文件夹里，还是在一个服务器上。那么，Picasso是如何何实现图片的快速加载了？

• 利用两级缓存机制对图片进行缓存: 加载一个图片时，首先从内存中查看是否存在；如果不存在，则查看外部存储是否有该图片。这时，如果还没有找到，则通过网络端下载图片；
• 利用OkHttp库进行图片下载，下载后保存到缓存，下次请求时无需从网络端下载；如果出现网络错误，会自动重试下载；

Android系统启动完成后，第一个启动的Activity就是主界面应用程序Launcher，相当于电脑的桌面。Launcher界面可以看到系统中安装的所有APP,点击APP即可启动该APP应用了。那么，Launcher到底是如何启动的以及如何自定义自己的Launcher了？这篇文章我们就来讲讲这两个问题。

前言

在上一篇文章里（http://sniffer.site/2016/11/29/Android-RILD%E8%AF%A6%E8%A7%A3/），简要介绍了Android RIL的架构。这一篇文章，就来看一看RILD（RIL Daemon)相关的内容。Android RIL在HAL(Hardware Abstract Layer)层（C++层）由三个部分组成：

• RILD是系统的守护进程，主要用于初始化LIBRIL以及启动厂商自定义的Vendor RIL；
• LIBRIL库被RILD初始化完成后，用于与Vendor RIL之间进行交互，负责接收、发送指令；
• Vendor RIL库是第三方厂商自定义的一个库，用于向Modem发送指令或者接收来自LIBRIL或者Modem的指令, Android有一个基于AT指令的默认参考实现(reference-ril)

前言

Android作为一个通用的移动平台，其首要的功能就是通话、短信以及上网等通信功能。那么，从系统的角度来看，Android究竟是怎么实现与网络的交互的了？ 这篇文章里，就来看一看Android中负责通信功能的Telephony中间层，通常也被称之为RIL(Radio Interface Layer)的具体实现原理与架构。

Android手机要实现与网络端的通信，需要跨越两个层：

• RIL Java(RILJ)：负责将上层APP的通信请求发送给HAL层；
• RIL C++(RILD)： 系统守护进程，负责将RILJ的请求命令发送给CP(Communication Processor)

Android系统是如何更新时间的了？Android提供了两种时间更新方式，NITZ和NTP,其中NITZ是基于移动基站通信更新的，与语音通话时相同的一个通道，而NTP则是通过数据通道（此时手机必须能上网）来更新的。这里，就来了解下这两种时间更新方式具体是如何工作的吧？