volatile 是 java 中一个非常常见,功能非常强大的一个关键字,大家用的最多的地方可能就是单例模式的双重检查锁的写法中。提到 volatile ,不得不提 synchronized , synchronized 是一个重量级锁,那么 volatile 是一个轻量级锁吗?并不是, volatile 是一个轻量级的同步关键字,那么 volatile 的语义到底是什么呢?这就是这篇文章要介绍的内容。
干货集中营 Android 版 --- MVP、RxJava、Retrofit 综合实践
干货集中营 分享一些技术圈儿的干货,有意思的视频图片和文章,还偶尔会推荐些靠谱的公司。
MVP 、 RxJava 、 Retrofit 是 Android 开发最流行,最酷的技术,秉着学习的态度,我使用干货集中营 API 开发了一款 Android 端应用,主要使用到的技术有 MVP 、 RxJava 、 Retrofit 等。对于 RxJava 不熟悉的同学可以看看给 Android 开发者的 RxJava 详解 学习。本篇文章将介绍这款应用的架构、涉及到的技术要点、MVP、RxJava、Retrofit 的综合实践等。
设计模式之23种设计模式总结
经过一个多月的时间,终于将经典的23种设计模式结合 Android 源码学习了一遍,虽然这次集中学习设计模式的时间只有一个月不到,但是在之前,从第一次接触设计模式到看各种设计模式的书籍、看各种大牛的博客,已经一年有余。设计模式初看一般理解起来都不难,但是要把设计模式用好,学会却不容易,这也是有人说设计模式用出不大的原因。但是我却不是这样认为,我觉得要学好设计模式,学会设计模式,首先得熟悉设计模式,这是基础,只有打好了这个基础,无论是阅读 Android 源码还是阅读经典库的源码时才会有所收获,才能理解设计模式的好处。
设计模式之桥接模式
在正式介绍桥接模式之前,我先跟大家谈谈两种常见文具的区别,它们是毛笔和蜡笔。假如我们需要大中小 3 种型号的画笔,能够绘制 12 种不同的颜色,如果使用蜡笔,需要准备 3×12 = 36 支,但如果使用毛笔的话,只需要提供 3 种型号的毛笔,外加 12 个颜料盒即可,涉及到的对象个数仅为 3 + 12 = 15,远小于36,却能实现与 36 支蜡笔同样的功能。如果增加一种新型号的画笔,并且也需要具有 12 种颜色,对应的蜡笔需增加 12 支,而毛笔只需增加一支。为什么会这样呢?通过分析我们可以得知:在蜡笔中,颜色和 型号两个不同的变化维度(即两个不同的变化原因)融合在一起,无论是对颜色进行扩展还是对型号进行扩展都势必会影响另一个维度;但在毛笔中,颜色和型号实现了分离,增加新的颜色或者型号对另一方都没有任何影响。如果使用软件工程中的术语,我们可以认为在蜡笔中颜色和型号之间存在较强的耦合性,而毛笔很好地将二者解耦,使用起来非常灵活,扩展也更为方便 。在软件开发中,我们也提供了一种设计模式来处理与画笔类似的具有多变化维度的情况,即本章将要介绍的桥接模式。
设计模式之适配器模式
作为 Android 开发者,适配器模式的使用率非常高,无论是 ListView 还是 RecyclerView 都需要 Adapter ,上一篇博客设计模式之代理模式 开篇有一句话:软件开发中遇到的所有问题,都可以通过增加一层抽象而得以解决,如果不行就再加一层(开个玩笑)。这句话也适用于我们今天要学习的适配器模式,其中对象的适配器模式就是代理模式的应用。这篇文章将介绍适配器模式的概念、类的适配器、对象的适配器、适配器的简单实现以及 Android 源码中的适配器模式。
设计模式之代理模式
可以说代理模式是 23 种设计模式中最重要的设计模式之一了,代理模式也是非常常用的一种设计模式了,有句很有名的话:软件开发中遇到的所有问题,都可以通过增加一层抽象而得以解决,如果不行就再加一层(开个玩笑)。在 Android 开发中我们都会使用到图片加载框架,图片加载框架也是层出不穷,比较有名的有: UniversalImageLoader 、 Picasso 、 Glide 、 Fresco 等。这么多图片加载框架,我们到底应该用那个呢,这不是我们要讨论的问题。现在假设我们选择了 UniversalImageLoader 作为我们的图片加载库,但是过了一段时间我们发现 UniversalImageLoader 不能满足我们的需求,我们需要切换为 Glide 了,如果我们之前所有用到图片加载的地方都是直接调用 UniversalImageLoader 的 API 的,那么可想而知,这个切换图片加载库的工作量是非常大的,这里就是我们代理模式的用武之地了,我们可以在图片加载库可我们的业务逻辑代码层之间封装一层,也就是所谓的代理层,如果有了代理层,我们再切换图片加载库就只需要修改代理层的代码,这个工作量就会小很多。可以看到代理模式使得客户端和被代理对象之间耦合性降低,程序的扩展性更强了。
设计模式之观察者模式
毫不夸张的说,观察者模式是最常用的设计模式之一了,通过使用观察者模式可以极大的解耦。 Android 四大组件之一的 BroadcastReceiver 就是一个耦合性非常低的观察者模式,最近大热的 RxJava 也是观察者模式的具体应用,所以我们学好观察者模式是非常有必要的,这篇博客将简要介绍观察者模式的概念、使用场景、优缺点,最后还会介绍 Android 源码中对于观察者模式的应用。
设计模式之命令模式
命令模式将一个请求封装成一个对象,命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。
设计模式之策略模式
策略模式属于对象的行为模式,其用意是针对一组算法,将每一个算法封装到具有共同接口的独立类中,从而使得他们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。这样在客户端就可以通过注入不同的算法类对象进行算法的动态替换,这种模式的可扩展性和可维护性也就更高。
设计模式之 Builder 模式
Builder 模式是一步一步创建一个复杂对象的创建型模式,它允许用户在不知道内部构建细节的情况下,可以更精确的控制对象的构造流程。该模式是为了将构建复杂对象的过程和它的部件解耦,使得构建过程和部件的表示隔离开来。本文将简要介绍 Builder 模式的概念、使用场景、以及 Android 源码中 Builder 模式的应用。