前言
Glide作为一个强大的图片加载框架,必然有着一套完整且优秀的缓存机制。本文将基于Glide-4.9.0版本,对Glide的缓存机制进行源码分析。
ThreadPoolExecutor是线程池的默认实现,在使用线程池的时候,如果没有特殊要求,则直接创建ThreadPoolExecutor。如果有特殊要求,则直接继承ThreadPoolExecutor,例如ScheduledThreadPoolExecutor,它是一个可以定时执行任务的线程池。
下面就通过分析ThreadPoolExecutor的源码来进一步了解线程池的原理。
ContentProvider是一种内容共享型组件,它通过Binder向其他组件或应用提供数据。
当ContentProvider所在进程启动时,ContentProvider会同时启动并被发布到AMS中。需要注意的是,这时ContentProvider的onCreate先于Application的onCreate执行。
外界无法直接访问ContentProvider,只能通过AMS根据Uri获取对应ContentProvider的Binder接口IContentProvider,然后再通过IContentProvider来访问ContentProvider中的数据源。
访问ContentProvider需要通过ContentResolver,ContentResolver是一个抽象类,通过Context的getContentResolver方法获取。真正实现是ApplicationContentResolver(ContextImpl的内部类)。当ContentProvider所在的进程未启动时,第一次访问ContentResolver的方法时,就会启动该进程和ContentProvider。
View是Android中视图的呈现方式,但是View不能单独存在,它必须依附在Window上。因此有视图的地方就有Window,像Activity、Dialog、Toast等视图都对应着一个Window。接下来将分析这些Window的创建过程,加深对Window的理解。
在实际使用中无法直接访问Window,对Window的访问必须通过WindowManager。
WindowManager是一个接口,它继承于ViewManager接口,ViewManager的定义如下:1
2
3
4
5
6public interface ViewManager
{
public void addView(View view, ViewGroup.LayoutParams params);
public void updateViewLayout(View view, ViewGroup.LayoutParams params);
public void removeView(View view);
}
这三个方法都是对View进行操作。这说明View才是Window存在的实体。
为了分析Window的内部机制,这里就从这三个方法开始,分别分析Window的添加、更新和删除过程。
这种方法主要用于实现不规则的效果。采用这种方式需要自己支持wrap_content,并且padding要自己处理。
这种方法主要用于实现自定义的布局。采用这种方式需要合适地处理ViewGroup的测量、布局两个过程,并同时处理子元素的测量和布局过程。
这种方法主要用于扩展某种已有View的功能。这种方法不需要自己支持wrap_content和padding。
一般来说,方法2能实现的效果方法4也能实现,主要差别在于方法2更接近View的底层。采用这种方法不需要自己处理ViewGroup的测量和布局。
View的工作流程主要是指measure、layout、draw这三大流程。其中measure确定View的测量宽高,layout确定View的最终宽高和四个顶点的位置,draw则将View绘制到屏幕上。
事件分发就是将MotionEvent事件分发给一个具体的View来处理的过程。本文将对Activity、ViewGroup和View的dispatchTouchEvent方法以及View的OnTouchEvent方法进行一些分析,以便更好理解事件分发的过程。下面的源码都是基于API26。
前面说过,Messenger不能跨进程调用方法。所以如果想要在客户端调用服务端的方法,可以使用AIDL。
在下面的例子中,将继续使用用AIDL来分析Binder的工作机制这篇文章的创建的项目,并给这个项目添加简单的功能。