Fresco.initializeDrawee()的过程
2016-04-30 10:47
369 查看
继续上篇博客的分析Fresco.initializeDrawee()
初始化了一个sDraweeControllerBuilderSupplier
将此sDraweeControllerBuilderSupplier用于初始化SimpleDraweeView
还是老的分析思路: 一步一步分析
构造方法,相互调用,总结过程
获取到了ImagePipelineFactory的实例,经过查看源码,只是将Fresco第一步初始化中的ImagePipelineFactory,获取到了这个实例,这里采用了单例的形式
获取到ImagePipleline,并且保存在这个Supplier中,这个里面代码看似只有这么几行,但是包涵的内容很多,还是先从广度看,然后再从深度看(这个方面作为遗留的Q2,一会儿再看)
*** ImagePipelineFactory.getImagePipeline()源码 ***
public ImagePipeline getImagePipeline() {
if (mImagePipeline == null) {
mImagePipeline =
new ImagePipeline(
getProducerSequenceFactory(),
mConfig.getRequestListeners(),
mConfig.getIsPrefetchEnabledSupplier(),
getBitmapMemoryCache(),
getEncodedMemoryCache(),
mConfig.getCacheKeyFactory());
}
return mImagePipeline;
}
在获取ImagePipeline()中,如果为空,创建了一个
创建了一个PipelineDraweeControllerFactory,并且保存到这个Supplier中
看到这里,我们先继续的广度分析,就是继续的分析SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier)的过程
在上面的分析,我们已经看到sDraweeControllerBuilderSupplier使用的是PipelineDraweeControllerBuilderSupplier
接下来,我们就看SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier)的过程
从下面的代码,我们看到sDraweeControllerBuilderSupplier保存在了SimpleDraweeView中,SimpleDraweeView能够很简单的使用,是因为Fresco帮助我们在这里初始化了很多东西
接着,以SimpleDraweeView的xml解析的方式来分析初始化的过程,我们发现,这里调用了我们的sDraweeControllerBuilderSupplier的get方法
*** SimpleDraweeView 的xml构造方式源码分析 ***
先别着急,我们再接着看,在使用xml解析的方式,我们还用到了一个setImageUri方法,再接着看这个方法,在setImageUri中,创建了一个DraweeController,然后设置给了自身,在构造DraweeController的时候,我们发现,调用了mSimpleDraweeControllerBuilder的build()方法
*** setImageURI(Uri)的源码分析 ***
到这里,我们先总结一下:
SimpleDraweeView中的sDraweeControllerBuilderSupplier是PipelineDraweeControllerBuilderSupplier
SimpleDraweeView中的controller是什么呢?那么这里就需要看看sDraweeControllerBuilderSupplier的get到什么ControllerBuilder?
对应的ControllerBuilder,build出什么controller
controller又是怎么样将提交请求的
遗留的Q2问题什么时候可以分析
看到这几个问题,我们发现,我们的分析,任重而道远
这里只是创建了一个PipelineDraweeControllerBuilder,并且这个builder保存了imagePipeline和mPipelineDraweeControllerFactory
*** PipelineDraweeControllerBuilder.get()分析 ***
@Override
public PipelineDraweeControllerBuilder get() {
return new PipelineDraweeControllerBuilder(
mContext,
mPipelineDraweeControllerFactory,
mImagePipeline,
mBoundControllerListeners);
}
*** PipelineDraweeControllerBuilder的构造方法 ***
在这里,我们看不到什么,那么就继续看build()方法吧
public PipelineDraweeControllerBuilder(
Context context,
PipelineDraweeControllerFactory pipelineDraweeControllerFactory,
ImagePipeline imagePipeline,
Set boundControllerListeners) {
super(context, boundControllerListeners);
mImagePipeline = imagePipeline;
mPipelineDraweeControllerFactory = pipelineDraweeControllerFactory;
}
查看build方法时,便已经看到了这个PipelineDraweeControllerBuilder的继承结构
AbstractDraweeControllerBuilder
--| VolleyDraweeControllerBuilder
--| PipelineDraweeControllerBuilder
Volley相关的我们就不看了,这个是和Vollery框架结合使用的,有兴趣可以自己研究下,大同小异
这次直接从方法调用来看即可,这次我们就要看到请求到底是如何产生的了
*** AbstractDraweeControllerBuilder.build()方法源码分析 ***
非核心代码,这次就忽略了,我们主要目的是要看到如何发送请求的,到后面请求如何反馈到前台,我们再详细分析其他代码
在build中,最关键的是buildController(),而在buildController中,最核心的是obtainController(),然后其他的是设置请求的一些信息,比如说设置请求的ImageRequest,其他的是设置重试等等
而在这里,发现obtainController()是抽象方法,那么就是找子类呗
*** PipelineDraweeControllerBuilder.obtainController()源码分析 ***
在获取controller的方法中,我们还是以第一次初始化为例,那么就是else的部分,这里就是用mPipelineDraweeControllerFactory创建了一个newController
@Override
protected PipelineDraweeController obtainController() {
DraweeController oldController = getOldController();
PipelineDraweeController controller;
if (oldController instanceof PipelineDraweeController) {
controller = (PipelineDraweeController) oldController;
controller.initialize(
obtainDataSourceSupplier(),
generateUniqueControllerId(),
getCallerContext());
} else {
controller = mPipelineDraweeControllerFactory.newController(
obtainDataSourceSupplier(),
generateUniqueControllerId(),
getCallerContext());
}
return controller;
}
这块要关键的分析了,因为已经到了重点了
我们一步一步看
obtainDataSourceSupplier()获取到了一个DataSourceSupplier
然后mPipelineDraweeControllerFactory类new了一个controller
这也没看出来什么,是吧,我们下节就得来点插叙,结合DraweeController和这里的获取Supplier直接的关系,那么基本的请求流程,我们算基本分析结束
sDraweeControllerBuilderSupplier = new PipelineDraweeControllerBuilderSupplier(context); SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier);
初始化了一个sDraweeControllerBuilderSupplier
将此sDraweeControllerBuilderSupplier用于初始化SimpleDraweeView
还是老的分析思路: 一步一步分析
4.2.1.2.1 sDraweeControllerBuilderSupplier初始化的过程
public PipelineDraweeControllerBuilderSupplier(Context context) { this(context, ImagePipelineFactory.getInstance()); } public PipelineDraweeControllerBuilderSupplier( Context context, ImagePipelineFactory imagePipelineFactory) { this(context, imagePipelineFactory, null); } public PipelineDraweeControllerBuilderSupplier( Context context, ImagePipelineFactory imagePipelineFactory, Set<ControllerListener> boundControllerListeners) { mContext = context; mImagePipeline = imagePipelineFactory.getImagePipeline(); mPipelineDraweeControllerFactory = new PipelineDraweeControllerFactory( context.getResources(), DeferredReleaser.getInstance(), imagePipelineFactory.getAnimatedDrawableFactory(), UiThreadImmediateExecutorService.getInstance()); mBoundControllerListeners = boundControllerListeners; }
构造方法,相互调用,总结过程
获取到了ImagePipelineFactory的实例,经过查看源码,只是将Fresco第一步初始化中的ImagePipelineFactory,获取到了这个实例,这里采用了单例的形式
获取到ImagePipleline,并且保存在这个Supplier中,这个里面代码看似只有这么几行,但是包涵的内容很多,还是先从广度看,然后再从深度看(这个方面作为遗留的Q2,一会儿再看)
*** ImagePipelineFactory.getImagePipeline()源码 ***
public ImagePipeline getImagePipeline() {
if (mImagePipeline == null) {
mImagePipeline =
new ImagePipeline(
getProducerSequenceFactory(),
mConfig.getRequestListeners(),
mConfig.getIsPrefetchEnabledSupplier(),
getBitmapMemoryCache(),
getEncodedMemoryCache(),
mConfig.getCacheKeyFactory());
}
return mImagePipeline;
}
在获取ImagePipeline()中,如果为空,创建了一个
创建了一个PipelineDraweeControllerFactory,并且保存到这个Supplier中
看到这里,我们先继续的广度分析,就是继续的分析SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier)的过程
4.2.1.2.2 SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier)的过程
在上面的分析,我们已经看到sDraweeControllerBuilderSupplier使用的是PipelineDraweeControllerBuilderSupplier接下来,我们就看SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier)的过程
从下面的代码,我们看到sDraweeControllerBuilderSupplier保存在了SimpleDraweeView中,SimpleDraweeView能够很简单的使用,是因为Fresco帮助我们在这里初始化了很多东西
private static Supplier<? extends SimpleDraweeControllerBuilder> sDraweeControllerBuilderSupplier; /** Initializes {@link SimpleDraweeView} with supplier of Drawee controller builders. */ public static void initialize( Supplier<? extends SimpleDraweeControllerBuilder> draweeControllerBuilderSupplier) { sDraweeControllerBuilderSupplier = draweeControllerBuilderSupplier; }
接着,以SimpleDraweeView的xml解析的方式来分析初始化的过程,我们发现,这里调用了我们的sDraweeControllerBuilderSupplier的get方法
*** SimpleDraweeView 的xml构造方式源码分析 ***
public SimpleDraweeView(Context context, AttributeSet attrs) { super(context, attrs); init(); } private void init() { if (isInEditMode()) { return; } Preconditions.checkNotNull( sDraweeControllerBuilderSupplier, "SimpleDraweeView was not initialized!"); mSimpleDraweeControllerBuilder = sDraweeControllerBuilderSupplier.get(); }
先别着急,我们再接着看,在使用xml解析的方式,我们还用到了一个setImageUri方法,再接着看这个方法,在setImageUri中,创建了一个DraweeController,然后设置给了自身,在构造DraweeController的时候,我们发现,调用了mSimpleDraweeControllerBuilder的build()方法
*** setImageURI(Uri)的源码分析 ***
/** * Displays an image given by the uri. * * @param uri uri of the image * @undeprecate */ @Override public void setImageURI(Uri uri) { setImageURI(uri, null); } /** * Displays an image given by the uri. * * @param uri uri of the image * @param callerContext caller context */ public void setImageURI(Uri uri, @Nullable Object callerContext) { DraweeController controller = mSimpleDraweeControllerBuilder .setCallerContext(callerContext) .setUri(uri) .setOldController(getController()) .build(); setController(controller); }
到这里,我们先总结一下:
SimpleDraweeView中的sDraweeControllerBuilderSupplier是PipelineDraweeControllerBuilderSupplier
SimpleDraweeView中的controller是什么呢?那么这里就需要看看sDraweeControllerBuilderSupplier的get到什么ControllerBuilder?
对应的ControllerBuilder,build出什么controller
controller又是怎么样将提交请求的
遗留的Q2问题什么时候可以分析
看到这几个问题,我们发现,我们的分析,任重而道远
4.2.1.2.3 PipelineDraweeControllerBuilderSupplier的get()分析
这里只是创建了一个PipelineDraweeControllerBuilder,并且这个builder保存了imagePipeline和mPipelineDraweeControllerFactory*** PipelineDraweeControllerBuilder.get()分析 ***
@Override
public PipelineDraweeControllerBuilder get() {
return new PipelineDraweeControllerBuilder(
mContext,
mPipelineDraweeControllerFactory,
mImagePipeline,
mBoundControllerListeners);
}
*** PipelineDraweeControllerBuilder的构造方法 ***
在这里,我们看不到什么,那么就继续看build()方法吧
public PipelineDraweeControllerBuilder(
Context context,
PipelineDraweeControllerFactory pipelineDraweeControllerFactory,
ImagePipeline imagePipeline,
Set boundControllerListeners) {
super(context, boundControllerListeners);
mImagePipeline = imagePipeline;
mPipelineDraweeControllerFactory = pipelineDraweeControllerFactory;
}
查看build方法时,便已经看到了这个PipelineDraweeControllerBuilder的继承结构
AbstractDraweeControllerBuilder
--| VolleyDraweeControllerBuilder
--| PipelineDraweeControllerBuilder
Volley相关的我们就不看了,这个是和Vollery框架结合使用的,有兴趣可以自己研究下,大同小异
这次直接从方法调用来看即可,这次我们就要看到请求到底是如何产生的了
*** AbstractDraweeControllerBuilder.build()方法源码分析 ***
非核心代码,这次就忽略了,我们主要目的是要看到如何发送请求的,到后面请求如何反馈到前台,我们再详细分析其他代码
在build中,最关键的是buildController(),而在buildController中,最核心的是obtainController(),然后其他的是设置请求的一些信息,比如说设置请求的ImageRequest,其他的是设置重试等等
/** Builds the specified controller. */ @Override public AbstractDraweeController build() { validate(); // if only a low-res request is specified, treat it as a final request. if (mImageRequest == null && mMultiImageRequests == null && mLowResImageRequest != null) { mImageRequest = mLowResImageRequest; mLowResImageRequest = null; } return buildController(); } /** Builds a regular controller. */ protected AbstractDraweeController buildController() { AbstractDraweeController controller = obtainController(); maybeBuildAndSetRetryManager(controller); maybeAttachListeners(controller); return controller; } /** Concrete builder classes should override this method to return a new controller. */ protected abstract AbstractDraweeController obtainController();
而在这里,发现obtainController()是抽象方法,那么就是找子类呗
*** PipelineDraweeControllerBuilder.obtainController()源码分析 ***
在获取controller的方法中,我们还是以第一次初始化为例,那么就是else的部分,这里就是用mPipelineDraweeControllerFactory创建了一个newController
@Override
protected PipelineDraweeController obtainController() {
DraweeController oldController = getOldController();
PipelineDraweeController controller;
if (oldController instanceof PipelineDraweeController) {
controller = (PipelineDraweeController) oldController;
controller.initialize(
obtainDataSourceSupplier(),
generateUniqueControllerId(),
getCallerContext());
} else {
controller = mPipelineDraweeControllerFactory.newController(
obtainDataSourceSupplier(),
generateUniqueControllerId(),
getCallerContext());
}
return controller;
}
这块要关键的分析了,因为已经到了重点了
controller = mPipelineDraweeControllerFactory.newController( obtainDataSourceSupplier(), generateUniqueControllerId(), getCallerContext());
我们一步一步看
obtainDataSourceSupplier()获取到了一个DataSourceSupplier
然后mPipelineDraweeControllerFactory类new了一个controller
这也没看出来什么,是吧,我们下节就得来点插叙,结合DraweeController和这里的获取Supplier直接的关系,那么基本的请求流程,我们算基本分析结束
相关文章推荐
- 单例模式(Singleton)的6种实现
- 等价类
- hdu1540 Tunnel Warfare(线段树区间合并详解)
- 深入浅出单实例Singleton设计模式
- json详解
- Fresco之客户端与服务端的交互
- 关于百度地图的心得
- 深入浅出单实例Singleton设计模式
- 博弈论(转)
- Actor模型和CSP模型的区别
- Singleton单例模式
- Eclipse上安装GIT插件EGit及使用
- 1006. 换个格式输出整数 (15)
- IMF传奇行动第84课:Spark Streaming第三课:StreamingContext、DStream、Receiver深度剖析
- HttpClient——Post请求
- Singleton单例模式
- HDU2176(Nim博弈)
- leetcode36:valid sudoku
- Eclipse:The resource 'project name'is not accessible for lauching
- 面试中的Singleton