《Android源码设计模式解析与实战（第2版）》是一本非常实用和富有实战性的书籍，作者通过详细解析Android源代码的设计模式，使读者能够深入了解面向对象的六大原则、主流的设计模式以及MVC和MVP模式，最重要的是，本书并不仅仅停留在理论层面，而是通过实战的方式帮助读者学以致用，并能够将所学的设计模式运用到自己的项目中，这使得读者在学习设计模式的同时也能够提升自己的实际开发能力，《Android源码设计模式解析与实战（第2版）》是一本不可多得的Android开发者必备参考书籍。
作者补充
想写一本Android设计模式的书的念头由来已久，也许是从我开始接触Android开发后就有了，于是很早就在自己的记事本上记录了一些相关学习心得。2014年4月我就在博客上连载了《Android源码分析之设计模式》系列，简单分析Android源码中的一些设计模式。到了2014年年底开始写一些开发框架相关的博客，并且在此期间发布了AndroidEventBus开源库，此后就一直活跃于Github、博客圈。2015年3月，我开始在Github上创建Android源码设计模式分析的开源项目，借助开源力量在一个月之内发布了十多篇Android源码中设计模式分析的文章，一经发布便得到了业界的普遍好评。
这些文章得到了业界的认可，让我又想起了最初出书的念头，虽说能力有限，水平一般，但由于这方面的资料缺乏，也就斗胆一试。原因很简单，Android是一个开源的系统，很多优秀的思想、架构、设计模式必然在它的源码中得以体现，而在开源社区发布的文章还不够深入。从学习“Hello World”开始，我们都是先从学习他人如何做，然后再到学着做，最后经过自己的理解与思考再到自己做，因此，学习这些优秀的实现正是我们每个开发人员成长过程中的重要一步。在学习Android源码的优秀设计之后，我们如何将设计模式运用在Android开发上成了至关重要的问题，正所谓学以致用。因此，设计模式在Android开发中的实战又成了第二个关键。恰好，这两个领域目前都没有相关的书籍，我和关爱民老师就考虑出版这样的一本书籍。一来是通过写书实现自我提升以及对知识的梳理，二来也希望本书能够让更多的Android开发人员了解设计模式，从而提升自己的代码质量。如此一来，也算是尽了我们的绵薄之力。
最后需要说明的一点是，编写任何一本书籍都难免会有一些错误或不准确甚至不正确的地方，本书的第一次印刷时这些问题相对较多，在此给出勘误地址 https://github.com/bboyfeiyu/dp-issues ，多谢大家的支持与理解！
内容介绍
本书专门介绍Android源代码的设计模式，主要讲解面向对象的六大原则、主流的设计模式以及MVC和MVP模式。本书的主要内容为：优化代码的第一步、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则、单例模式、Builder模式、原型模式、工厂方法模式、抽象工厂模式、策略模式、状态模式、责任链模式、解释器模式、命令模式、观察者模式、备忘录模式、迭代器模式、模板方法模式、访问者模式、中介者模式、代理模式、组合模式、适配器模式、装饰模式、享元模式、外观模式、桥接模式，以及MVC的介绍与实战和MVP应用架构模式。每个章节都对某个模式做了深入分析，并且会对模式相关的技术点进行深入拓展，让读者在掌握模式的同时学习到Android中的一些重要知识，通过实战帮助读者达到学以致用的目的，且能够将模式运用于项目中，开发出高质量的程序。
本书适合的读者为初、中、高级Android工程师，也可以作为大专院校相关师生的学习用书和培训学校的教材。
目录
- 内容提要
- 前言
- 第二版自序
- 自序一
- 自序二
- 致谢
- 第1章 走向灵活软件之路——面向对象的六大原则
- 第2章 应用最广的模式——单例模式
- 第3章 自由扩展你的项目——Builder模式
- 第4章 使程序运行更高效——原型模式
- 第5章 应用最广泛的模式——工厂方法模式
- 第6章 创建型设计模式——抽象工厂模式
- 第7章 时势造英雄——策略模式
- 第8章 随遇而安——状态模式
- 第9章 使编程更有灵活性——责任链模式
- 第10章 化繁为简的翻译机——解释器模式
- 第11章 让程序畅通执行——命令模式
- 第12章 解决解耦的钥匙——观察者模式
- 第13章 编程中的“后悔药”——备忘录模式
- 第14章 解决问题的“第三者”——迭代器模式
- 第15章 抓住问题核心——模板方法模式
- 第16章 访问者模式
- 第17章 “和事佬”——中介者模式
- 第18章 编程好帮手——代理模式
- 第19章 物以类聚——组合模式
- 第20章 得心应手的“粘合剂”——适配器模式
- 第21章 装饰模式
- 第22章 对象共享，避免创建多对象——享元模式
- 第23章 统一编程接口——外观模式
- 第24章 连接两地的交通枢钮——桥接模式
- 第25章 MVC的介绍与实战
- 第26章 MVP应用架构模式
- 第27章 MVVM应用浅析
- 第28章 易混淆的设计模式
database 层 考虑到sdk是允许跨进程访问的，因此model层采用ContentProvider作为通信层。由于在该模块中下发的所有配置数据类型是多种的，这说明在存在一个DBHelper中，必然需要管理多个Dao。所以这里面如何在配合多个Dao中，与contentprovider进行多个监听协同工作？所以这里面首先在模块中抽象一个BaseRole，数据操作角色的工作模板。 network 层 该模块网络请求层不打算依赖第三方，因此直接使用apache包作为底层http请求层。至于抽象是比较好理解的，首先请求目标对于模块层是不需要理会的，模块关心的只是请求时、请求结果。因此无论是https、http，只需要抽象一个Iprotocol，负责请求seesion同步、header处理、缓存处理等工作模块为请求目标服务即可。 process 层 首先，每个流程操作都是独立线性的，两个流程之间也是不能互相干扰的。例如A流程和B流程，A流程与B流程没有任何直接关系，并且需要保证A流程执行完成后才能进行B流程。因此，这里抽象成一个process工作流程。目前模块只需要两个流程，分别为配置下发process与鉴权process，考虑到以后的拓展性，当然不能“限死”在这两个里面了。
模型-视图-控制器（MVC）设计定义它们之间的相互作用。 Model：用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。Model有对数据直接访问的权力，例如对数据库的访问。Model不依赖于View和Controller，也就是说，Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。 View:能够实现数据有目的的显示（理论上，这不是必需的）。在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。 Controller：起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据 Model 上的改变。