菜鸟博客

本篇博文理论知识储备： Otto源码解读 EventBus源码解析开篇 EventBus BackgroundPoster原理解析 在阅读本篇博文之前，请先阅读上面几篇博客，可以对EventBus的工作原理做一个系统的了解。 EventBus的在EventBus BackgroundPoster原理解析一文中详细的说明了ThreadModel.BACKGROUND 的工作原理、P...

EventBus相信大家都不陌生，所以这里偷个懒就不说具体用法了，不过在阅读本博客之前建议大家阅读博主的以下两篇博客，因为本篇是在这两篇的基础上写的： Otto源码解读 EventBus源码解析开篇 通过上面两篇博客，可以了解EventBus的工作原理，简单来说最核心就是： 1、收集应用中所有标注了@Subscribe的Method方法（当然这些方法都是属于具体的注册者对象(Subscri...

源码传送门：https：//github.com/square/otto最近工作不是很忙，就花了半天的时间阅读了奥托的源码，于是就有了这篇博文;自己写下的心得体会，算是个学习笔记。奥托的原理并不难，其源码阅读起来也很容易，其思想原理就是订阅和发布事件，实质是注解+技术反射而实现的观察者模式，但是呢从其实现设计上来看还是可以琢磨出一些东西出来。其使用也很简单：//事件生成的对象cl...

《Glide 4.x工作总体执行流程概述》 《Glide 4.x之请求网络图片数据流程解析》 《Glide 4.x之ModelLoader简单分析》 《Glide 4.x添加自定义组件原理》在《Glide 4.x工作总体执行流程概述》一篇博文中我们直到Glide加载图片的步骤主要由两个： 1、通过RequestBuilder对象创建Request对象 2、将Request对象交给R

Glide 4.x添加自定义组件

Glide ModelLoader

Glide HttpURLFetcher

Glide工作路程概述

Request简单分析通过《Picasso源码解析（一）》知道，在使用Picasso的load方法进行加载图片的时候实际上是创建了一个RequestCreator对象，这个RequestCreator对象，并且通过该对象创建了Request对象。 我们应该能猜想得到能灵活的决定某个或者某些图片（比如GridView里面的图片）是否需要进行缓存，这是图片加载库必实现的功能。在ImageLoader中

前段时间简单的分析了一下ImageLoader的源码，所以就想看看使用很火的一些其他的图片加载库的实现，跟ImageLoader对比起来有什么优缺点。所以本系列的几篇博文会时不时跟ImageLoader来个简单的对比来说明问题。闲言少叙，开始Picasso分析之旅吧。 其实既然是缓存，肯定核心也就是那么几点：memory cache,disk cache等等，总体上来说只是不同的库对它们处理的方

不知不觉的关于Imageloader的简单分析博客系列居然已经完成了6篇，今天将这一篇博客就把前几篇博客讲到的东东做一个系统的总结，然后就算完成了对ImgeLoader的分析。 参考资料如下(当然是博主之前的几篇文章了）： 《ImageLoader的简单分析》 《ImageLoader的简单分析（二）》 《ImageLoader的简单分析（三）》 《ImageLoader的简单分析（四）》

通过前面几篇的简单解析，基本上ImageLoader能讲解完的都讲解完了，不过还有一个知识点没有分析。就是ImageLoader的如下方法： 其实找几个重载方法执行的流程也很简单，博主在此就按照分析displayImage方法来展开此篇博文！（同样，博主也假设你已经读过了博主的ImageLoader的其他几篇博文） ImageLoader提供了两种方式的loadImage方法：没有返回值的l

虽然现在有好多图片缓存库，功能还很强大，但是本文还是继续对ImageLoader源码的解读。就算是以后不用ImageLoader这个库了，它的设计到实现还是有很多的地方值得去学习、钻研和琢磨的。思想有时候比具体的代码实现很重要。 前四篇关于ImageLoader的博客对ImageLoader的工作原理做了梳理，但是有一点我故意没有讲到—-ImageLoader的异步机制工作原理，下面就对此进行异步

之前通过三篇博客从实现原理上对ImageLoader的工作流程做了简单的梳理，本篇就ImageLoader的另外一个小知识点做一些总结—Handler的作用。 在进行正式开始之前先做个引言吧，我们知道在使用AsyncTask的时候可以通过onPostExecute对doInbackground方法执行完成后对UI进行更新，当然我们还知道android的UI更新只能在UI线程中去做，那么AsyncT

其实对于缓存的实现原理及其流程总的来说都很简单，无非就是先从网络加载相关资源，然后用内存缓存或者磁盘缓存把下载到的资源缓存起来；等再次加载相同的资源的时候如果内存缓存或者磁盘缓存还存在就用缓存里面的资源，否则仍然进行网络加载，重复此过程而已。严格说来也没什么可讲的，但是通过研读ImageLoader的源码倒是可以学到很多缓存之外的东西：学学别人的代码怎么设计，资源加载的异步处理机制的灵活使用等等，甚

对ImageViewLoader读取内存，并且怎么显示图片的过程做了简单说明

Imageloader的简单解析

简单分析ListView的回收机制

ListView 布局实现原理的简单总结

ImageLoader

Android-Universal-Image-Loader memory cache

LruDiscCache

Android-Universal-Image-Loader学习笔记

缓存 Callable

通过Gson的反射解析机制详解(1)和Gson的反射解析机制详解(2) 这两篇博文我们知道Gson的通过反射工作的原理其实就是一句话： 根据Type遍历Class的Field属性，然后调用Field.set(obj,value)方法为一个属性赋值，其中obj是一个javabean的对象实例。本篇就简单讲讲这个obj 在gson中是怎么初始化这个obj的。从中体会汲取Gson 优秀的设计理念...

Gson反射即系机制详解

通过前几篇的关于Gson的博客我们知道Gson的解析原理： 1）如果是通过GsonBuilder创建的Gson对象，那么就用自定义的TyperAdapter来完成json的解析 2）如果是通过new Gson()创建的Gson对象，那么就用Java反射机制来完成json的解析。 那么Gson在是怎么判断是上述两种方式的哪一种呢？查看Gson源码，并没有提供一个特殊的字段来辨别？ 其实很简单，

在 几篇关于Gson的文章中我们知道Gson解析成Java对象的实现原理是： 1)注册自定义的或者Gson自己定义的TypeAdapter 2)将TypeAdapter封装成TypeAdapterFactory,并把此Factory添加到Gson的factories（List)中 3)通过fromJson方法最终调用getAdapter,遍历factories，获取fromJson的第二个参数

胡乱写点东西

Gson TypeAdapter工作原理分析

Gson JsonDeserializer

JsonElement：该类是一个抽象类，代表着json串的某一个元素。这个元素可以是一个Json(JsonObject)、可以是一个数组(JsonArray)、可以是一个Java的基本类型(JsonPrimitive)、当然也可以为null(JsonNull);JsonObject,JsonArray,JsonPrimitive，JsonNull都是JsonElement这个抽象类的子类。J...