&&&&Android&源码设计模式解析与实战
电子书加价购
加价换购以下任意一件商品
请选择配送地址
钻石会员自营订单满49元(含)免运费
其他会员自营订单满59元(含)免运费
不足金额订单收取运费5元起
商品问答(%s条)
当当价:&27.80
版 次：1页 数：494字 数：441000印刷时间：开 本：16开纸 张：胶版纸印 次：1包 装：平装丛书名：国际标准书号ISBN：2所属分类：&&&
CSDN社区专家精心撰写、业界专家邓凡平、郭霖、任玉刚、徐宜生等鼎力推荐Android源码讲解设计模式的书
　　本书不仅分析了Android源代码的设计模式，更结合实例演示了如何使用这些设计模式。看这本书，既能学到如何分析、学习Android源代码，又能提高自己架构设计水平
　　书中的主人公小民就是那些不断追求技术进步，从而得以不断成长的IT技术人的代表，小民的成长过程基本上反映了我们现在程序员的成长经历，他的成功很值得我们学习和借鉴。
本书专门介绍Android源代码的设计模式，共26章，主要讲解面向对象的六大原则、主流的设计模式以及MVC和MVP模式。主要内容为：优化代码的首步、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则、单例模式、Builder模式、原型模式、工厂方法模式、抽象工厂模式、策略模式、状态模式、责任链模式、解释器模式、命令模式、观察者模式、备忘录模式、迭代器模式、模板方法模式、访问者模式、中介者模式、代理模式、组合模式、适配器模式、装饰模式、享元模式、外观模式、桥接模式，以及MVC的介绍与实战和MVP应用架构模式。每个章节都对某个模式做了深入的分析，并且会对模式相关的技术点进行深入拓展，让读者在掌握模式的同时学习到Android中的一些重要知识，通过实战帮助读者达到学以致用的目的，且能够将模式运用于项目中，开发出高质量的程序。
　　本书适合的读者为初、中、高级Android工程师，也可以作为大专院校相关师生的学习用书和培训学校的教材。
****旗下友盟的高级程序员，CSDN博客专家，在开源社区做了大量的工作，贡献了许多模式设计的技术。
第1章 走向灵活软件之路&&面向对象的六大原则
1.1 优化代码的第一步&&单一职责原则
1.2 让程序更稳定、更灵活&&开闭原则
1.3 构建扩展性更好的系统&&里氏替换原则
1.4 让项目拥有变化的能力&&依赖倒置原则
1.5 系统有更高的灵活性&&接口隔离原则
1.6 更好的可扩展性&&迪米特原则
第2章 应用最广的模式&&单例模式
2.1 单例模式介绍
2.2 单例模式的定义
2.3 单例模式的使用场景
2.4 单例模式UML类图
2.5 单例模式的简单示例
2.6 单例模式的其他实现方式
第1章 走向灵活软件之路&&面向对象的六大原则
& 1.1 优化代码的第一步&&单一职责原则
& 1.2 让程序更稳定、更灵活&&开闭原则
& 1.3 构建扩展性更好的系统&&里氏替换原则
& 1.4 让项目拥有变化的能力&&依赖倒置原则
& 1.5 系统有更高的灵活性&&接口隔离原则
& 1.6 更好的可扩展性&&迪米特原则
& 1.7 总结
第2章 应用最广的模式&&单例模式
& 2.1 单例模式介绍
& 2.2 单例模式的定义
& 2.3 单例模式的使用场景
& 2.4 单例模式UML类图
& 2.5 单例模式的简单示例
& 2.6 单例模式的其他实现方式
&&& 2.6.1 懒汉模式
&&& 2.6.2 Double CheckLock ( DCL )实现单例
&&& 2.6.3 静态内部类单例模式
&&& 2.6.4 枚举单例
&&& 2.6.5 使用容器实现单例模式
& 2.7 Android源码中的单例模式
& 2.8 无名英雄&&深入理解LayoutInflater
& 2.9 运用单例模式
& 2.10 总结
第3章 自由扩展你的项目&&Builder模式
& 3.1 Builder模式介绍
& 3.2 Builder模式的定义
& 3.3 Builder模式的使用场景
& 3.4 Builder模式的UML类图
& 3.5 Builder模式的简单实现
& 3.6 Android源码中的Builder模式实现
& 3.7 深入了解WindowManager
& 3.8 Builder模式实战
& 3.9 总结
第4章 使程序运行更高效&&原型模式
& 4.1 原型模式介绍
& 4.2 原型模式的定义
& 4.3 原型模式的使用场景
& 4.4 原型模式的UML类图
& 4.5 原型模式的简单实现
& 4.6 浅拷贝和深拷贝
& 4.7 Android源码中的原型模式实现
& 4.8 Intent的查找与匹配
&&& 4.8.1 App信息表的构建
&&& 4.8.2 精确匹配
& 4.9 原型模式实战
& 4.10 总结
第5章 应用最广泛的模式&&工厂方法模式
& 5.1 工厂方法模式介绍
& 5.2 工厂方法模式的定义
& 5.3 工厂方法模式的使用场景
& 5.4 工厂方法模式的UML类图
& 5.5 模式的简单实现
& 5.6 Android源码中的工厂方法模式实现
& 5.7 关于onCreate方法
& 5.8 工厂方法模式实战
& 5.9 总结
第6章 创建型设计模式&&抽象工厂模式
第7章 时势造英雄&&策略模式
第8章 随遇而安&&状态模式
第9章 使编程更有灵活性&&责任链模式
第10章 化繁为简的翻译机&&解释器模式
第11章 让程序畅通执行&&命令模式
第12章 解决、解耦的钥匙&&观察者模式
第13章 编程中的&后悔药&&&备忘录模式
第14章 解决问题的&第三者&&&迭代器模式
第15章 抓住问题核心&&模板方法模式
第16章 访问者模式
第17章 &和事佬&&&中介者模式
第18章 编程好帮手&&代理模式
第19章 物以类聚&&组合模式
第20章 得心应手的&粘合剂&&&适配器模式
第21章 装饰模式
第22章 对象共享，避免创建多对象&&享元模式
第23章 统一编程接口&&外观模式-
第24章 连接两地的交通枢钮&&桥接模式
第25章 MVC的介绍与实战
第26章 MVP应用架构模式
本书不仅仅分析了Android源代码的设计模式，更结合实例演示了如何使用这些设计模式。看这本书，既能学到如何分析、学习Android源代码，又能提高自己的架构设计水平，实在是一本难得的好书！
&&徐宜生 《Android群英传》作者
　　这本书独树一帜，将设计模式和Android源码中的设计思想融合到一起，我一定会认真阅读这本书。
&&任玉刚（singwhatiwanna） 百度Android资深工程师，《Android开发艺术探索》作者
　　当你做了许多年开发以后就会意识到，设计模式很重要，阅读源码也很重要，而这本书很好地将这两者结合起来，对于那些想要进阶的开发者们，这将是一本非常合适的书籍。
&&郭霖《第1行代码:Android》作者和LitePAL框架作者
书摘与插画
店铺收藏成功第十三章、备忘录模式备忘录模式是一种行为模式，该模式用于保存对象当前的状态，并且在之后可以再次恢复到此状态，有点像是我们平常说的&后悔药&。1.定义在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样，以后就可将该对象恢复到原先保存的状态。2.使用场景（1）需要保存一个对象在某一个时刻的状态或部分状态。（2）如果用一个接口来让其他对象得到这些状态，将会暴露对象的实现细节并破坏对象的封装性，一个对象不希望外界直接访问其内部状态，通过中间对象可以间接访问其内部状态。3.简单实现书中例子：以&使命召唤&游戏为例，用游戏中的存档功能来举例。首先是备忘录类/** * 备忘录类 */public class Memento {
public int mC//武器
public int mLiftV//生命
public String mW//关卡
public String toString() {
return &Memento [mCheckpoint=& + mCheckpoint + &,mLiftValue=&
+ mLiftValue + &,mWeapon=& + mWeapon + &]&;
}}游戏类，在该类可以通过createMemento函数来创建该用户的备忘录对象，外部可以通过restore函数将CallOfDuty 对象的状态从备忘录对象中恢复。/** *
* 简单模拟&使命召唤&游戏
*/public class CallOfDuty {
private int mCheckpoint = 1;
private int mLiftValue = 100;
private String mWeapon = &沙漠之鹰&;
public void play(){
System.out.println(&打游戏：&+String.format(&第%d关&, mCheckpoint) + &奋战杀敌中&);
mLiftValue -= 10;
System.out.println(&进度升级了&);
mCheckpoint++;
System.out.println(&到达& + String.format(&第%d关&, mCheckpoint));
//退出游戏
public void quit(){
System.out.println(&--------------&);
System.out.println(&退出前的游戏属性：& + this.toString());
System.out.println(&退出游戏&);
System.out.println(&--------------&);
*创建备忘录
public Memento createMemento(){
Memento memento = new Memento();
memento.mCheckpoint = mC
memento.mLiftValue = mLiftV
memento.mWeapon = mW
//恢复游戏
public void restore(Memento memento){
this.mCheckpoint = memento.mC
this.mLiftValue = memento.mLiftV
this.mWeapon = memento.mW
System.out.println(&恢复后的游戏属性：& + this.toString());
//省略getter和setter方法
public String toString() {
return &CallOfDuty [mCheckpoint=& + mCheckpoint + &,mLiftValue=&
+ mLiftValue + &,mWeapon=& + mWeapon + &]&;
}}备忘录操作类：/** * Caretaker，负责管理Memento */public class Caretaker {
Memento mM //备忘录
public void archive(Memento memento){
this.mMemento =
* 获取存档
public Memento getMemento(){
}}客户端使用代码：public class Client {
public static void main(String[] args) {
//构建游戏对象
CallOfDuty game = new CallOfDuty();
//1.打游戏
game.play();
Caretaker caretaker = new Caretaker();
//2.游戏存档
caretaker.archive(game.createMemento());
//3.退出游戏
game.quit();
//4.恢复游戏
CallOfDuty newGame = new CallOfDuty();
newGame.restore(caretaker.getMemento());
//5.再次打游戏(不存档)
game.play();
//6.恢复之前存档
newGame.restore(caretaker.getMemento());
}}结果：打游戏：第1关奋战杀敌中进度升级了到达第2关--------------退出前的游戏属性：CallOfDuty [mCheckpoint=2,mLiftValue=90,mWeapon=沙漠之鹰]退出游戏--------------恢复后的游戏属性：CallOfDuty [mCheckpoint=2,mLiftValue=90,mWeapon=沙漠之鹰]打游戏：第2关奋战杀敌中进度升级了到达第3关恢复后的游戏属性：CallOfDuty [mCheckpoint=2,mLiftValue=90,mWeapon=沙漠之鹰]上面的代码中，各个角色职责清晰、单一，代码也比较简单，即对外屏蔽了对CallOfDuty角色的直接访问，在满足了对象状态存取功能的同时也使得该模块的结构保持清晰、整洁。4.源码中的备忘录模式1.onSaveInstanceState和onRestoreInstanceState当Activity不是正常方式退出，且Activity在随后的时间内被杀死之前会调用这两个方法让开发人员可以有机会存储Activity相关信息，且在下次返回Activity时恢复这些数据。通过这两个函数。开发人员能够在某些特殊场景下储存与界面相关的信息，提升用户体验。5.总结1.优点（1）给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史状态。（2）实现了信息的封装，使用户不需要关心状态的保存细节。2.缺点消耗资源，如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。PS：这篇应该是今年的最后一篇了，《Android源码设计模式解析与实战》一共26章，这个月刚好看到了一半了，下个月继续努力。最后也祝大家元旦快乐，在新一年技术突飞猛进！！最后谢谢大家的支持，就这样！
您对本文章有什么意见或着疑问吗？请到您的关注和建议是我们前行的参考和动力&&1537人阅读
Note（25）
第二十六章、MVP应用构架模式
MVP模式是MVC模式的一个演化版本，MVP全称Model-View-Presenter。目前MVP在Android应用开发中越来越重要了。
在Android中，业务逻辑和数据存取是紧紧耦合的，很多缺乏经验的开发者很可能会将各种各样的业务逻辑塞进某个Activity、Fragment或者自定义View中，这样会使得这些组件的单个类型臃肿不堪。如果不将具体的业务逻辑抽离出来，当UI变化时，你就需要去原来的View中抽离具体业务逻辑，这必然会很麻烦并且易出错。
2.使用MVP的好处
（1）MVP模式会解除View与Model的耦合，有效的降低View的复杂性。同时又带来了良好的可扩展性、可测试性，保证系统的整洁性和灵活性。
（2）MVP模式可以分离显示层与逻辑层，它们之间通过接口进行通信，降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面，因为它们之间并不依赖与具体，而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，使之具有更广泛的适用性，保证了灵活度。
3.MVP模式的三个角色
（1）Presenter – 交互中间人：Presenter主要作为沟通View与Model的桥梁，它从Model层检索数据后，返回给View层，使得View与Model之间没有耦合，也将业务逻辑从View角色上抽离出来。
（2）View – 用户界面：View通常是指Activity、Fragment或者某个View控件，它含有一个Presenter成员变量。通常View需要实现一个逻辑接口，将View上的操作转交给Presenter进行实现，最后，Presenter 调用View逻辑接口将结果返回给View元素。
（3）Model – 数据的存取：Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据，Model就像一个数据仓库。更直白的说，Model是封装了数据库DAO或者网络获取数据的角色，或者两种数据方式获取的集合。
4.与MVC、MVVM的区别
1.与MVC的区别
从上图可以看出：MVC的耦合性还是较高的，View可以直接访问Model，导致3者之间构成了回路。所以两者的主要区别是，MVP中View不能直接访问Model，需要通过Presenter发出请求，View与Model不能直接通信。
2.与MVVM（Model-View-ViewModel）的区别
MVVM与MVP非常相似，唯一区别是View和Model进行双向绑定，两者之间有一方发生变化则会反应到另一方上。MVVM模式有点像ListView与Adapter、数据集的关系，当数据集发生变化时，调用Adapter的notifyDataSetChanged之后View就直接更新，同时它们之间又没有耦合，使得ListView变得更加灵活。
5.MVP简单实现
可以参考：
6.MVP 与Activity、Fragment的生命周期
由于Presenter 经常性的持有Activity 的强引用，如果在一些请求结束之前Activity 被销毁了，那么Presenter 一直持有Activity 对象，使得Activity 对象无法回收，此时就会发生内存泄露。
那么解决方法就是采用弱引用和Activity、Fragment的生命周期来解决这个问题。首先建立一个Presenter 抽象：
public abstract class BasePresenter&T& {
protected Reference&T& mViewR
public void attachView(T view){
mViewRef = new WeakReference&T&(view);
protected T getView(){
return mViewRef.get();
public boolean isViewAttached(){
return mViewRef != null && mViewRef.get() != null;
public void detachView(){
if(mViewRef != null){
mViewRef.clear();
mViewRef = null;
通常这个View类型应该就是实现了某个特定接口的Activity或者Fragment等类型。
创建一个MVPBaseActivity基类，通过这个基类声明周期函数来控制它与Presenter 的关系。代码如下：
public abstract class MVPBaseActivity&V, T extends BasePresenter&V&& extends Activity {
protected T mP
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mPresenter = createPresenter();
mPresenter.attachView((V)this);
protected void onDestroy() {
super.onDestroy();
mPresenter.detachView();
protected abstract T createPresenter();
MVPBaseActivity含有两个泛型，一个是View的接口类型，一个是Presenter的具体类型。
PS：到这里《Android源码设计模式解析与实战》读书笔记系列到此就结束了，这本书算算看了也有近2个月了，收获真是非常大，以后也会抽时间再看几遍，温故而知新嘛！在写这个读书笔记的过程中，很感谢大家的支持，评论中都是鼓励的声音真是给我了很多的信心。最让我激动的是这本书的作者之一何红辉也给了我鼓励，在这里也是再次感谢。
前一阵看到许多的博友都有写年度总结，看了之后我也是很有感触。那我也简单总结一下：其实做Android开发到现在也有一年半了，虽然称不上是什么高手、大神。但是工作上的问题基本也可以独立解决（毕竟有Google~，毕竟就我一人）同时我对我的工作和学习态度是肯定的。
谈谈写博客的初衷：写博客的时间是我做开发基本1年的时候，说来写博客也是一个机缘巧合，因为写博客之前我会经常看一些开源的项目，就比如Github的android-open-project，那么我每次都是先进Github在搜索android-open-project（我竟然连书签都懒得保存！），类似的还有很多。。。终于有一天我觉得真麻烦（你是有多迟钝），所以就把我经常用到的这些网址写了我的第一篇博客：Android开源与干货网站汇总，之后存一个书签。尝到了这种便捷的好处，就正式开始了CSDN博客之旅。
前几天碰巧看到一位大神的博客，看了下这位大神坚持写了近10年的博客，并且每月都有高质量的文章，涉及的知识也是方方面面的。真是震撼了我，那么向榜样学习，今年继续努力，既然开始了就坚持下去。
最后奉上读书笔记的所有Demo：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：58215次
积分：1213
积分：1213
排名：千里之外
原创：51篇
评论：53条
文章：27篇
阅读：31154
阅读：2030-------------
新增文件夹...
新增文件夹
(多个标签用逗号分隔)
《android源码设计模式解析与实战》样章.pdf
单一职责原则的英文名称是Single Responsibility Principle，缩写是SRP。SRP的定义是：就一
个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、
数据的封装。就像秦小波老师在《设计模式之禅》中说的：“这是一个备受争议却又及其重要的原
则。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的”。因为单一职责的划分界限
单一职责原则的英文名称是Single Responsibility Principle，缩写是SRP。SRP的定义是：就一
个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、
数据的封装。就像秦小波老师在《设计模式之禅》中说的：“这是一个备受争议却又及其重要的原
则。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的”。因为单一职责的划分界限
并不是总是那么清晰，很多时候都是需要靠个人经验来界定。当然，最大的问题就是对职责的定义，
什么是类的职责，以及怎么划分类的职责。&&
加载中...!如果长时间没有加载，请刷新页面
下载本文档需要登录，并付出相应积分（）。
文件大小:518.49 KB
所需积分:& 10
相关资讯 　—　
相关讨论话题 　—　
浏览：1604次&& 下载：0次
上传时间： 20:29:10
同类热门文档
37211次浏览 &19次下载
0次浏览 &54次下载
19556次浏览 &42次下载
21091次浏览 &21次下载
15812次浏览 &13次下载
10983次浏览 &8次下载
相关经验 -
& 0人评&71页
& 10人评&106页
& 2人评&29页
& 0人评&149页
& 5人评&66页
OPEN-OPEN, all rights reserved.《Android源码设计模式解析与实战》读书笔记（九）
第九章、责任链模式
责任链模式是行为型设计模式之一，它使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
2.使用场景
1.多个对象可以处理同一请求，但具体由哪个对象处理则在运行时动态决定。
2.在请求处理者不明确的情况下向多个对象中的一个提交请求。
3.需要动态指定一组对象处理请求。
3.简单实现
这个例子我觉得很贴切。我们在公司有各种原因需要报销费用，首先我们要找我们的上级领导去审批，报销额度如果在领导的权限范围内，那就审批通过，否则领导在找自己的上级去审批，以此类推。
抽象领导类
public abstract class Leader {
* 上级领导处理者
protected Leader nextH
* 处理报账请求
* @param money 能批复的报账额度
public final void handleRequest(int money){
System.out.println(getLeader());
if(money &=limit()){
handle(money);
System.out.println(&报账额度不足，提交领导&);
if(null != nextHandler){
nextHandler.handleRequest(money);
* 自身能批复的额度权限
* @return 额度
public abstract int limit();
* 处理报账行为
* @param money 具体金额
public abstract void handle(int money);
* 获取处理者
* @return 处理者
public abstract String getLeader();
组长（额度1000）：
public class GroupLeader extends Leader{
public int limit() {
return 1000;
public void handle(int money) {
System.out.println(&组长批复报销&+ money +&元&);
public String getLeader() {
return &当前是组长&;
主管（额度5000）：
public class Director extends Leader{
public int limit() {
return 5000;
public void handle(int money) {
System.out.println(&主管批复报销&+ money +&元&);
public String getLeader() {
return &当前是主管&;
经理（额度10000）：
public class Manager extends Leader{
public int limit() {
return 10000;
public void handle(int money) {
System.out.println(&经理批复报销&+ money +&元&);
public String getLeader() {
return &当前是经理&;
老板（额度&）:
public class Boss extends Leader{
public int limit() {
return Integer.MAX_VALUE;
public void handle(int money) {
System.out.println(&老板批复报销&+ money +&元&);
public String getLeader() {
return &当前是老板&;
发起申请：
public class Client {
public static void main(String[] args) {
//构造各个领导对象
GroupLeader groupLeader = new GroupLeader();
Director director = new Director();
Manager manager = new Manager();
Boss boss = new Boss();
//设置上级领导处理者对象
groupLeader.nextHandler =
director.nextHandler =
manager.nextHandler =
//发起报账申请
groupLeader.handleRequest(8000);
当前是组长
报账额度不足，提交领导
当前是主管
报账额度不足，提交领导
当前是经理
经理批复报销8000元
责任链模式非常灵活，请求的发起可以从责任链的任何一个节点开始，也可以改变内部的传递规则。比如主管不在，我们完全可以跨过主管直接从组长那里转到经理。
对于责任链中的一个处理者对象，有两个行为。一是处理请求，二是将请求传递到下一节点，不允许某个处理者对象在处理了请求后又将请求传送给上一个节点的情况。
对于一条责任链来说，一个请求最终只有两种情况。一是被某个处理对象所处理，另一个是所有对象均未对其处理，对于前一种情况我们称为纯的责任链模式，后一种为不纯的责任链。实际中大多为不纯的责任链。
4.源码中的责任链模式
1.View事件的分发处理
ViewGroup事件投递的递归调用就类似于一条责任链，一旦其寻找到责任者，那么将由责任者持有并消费掉该次事件，具体体现在View的onTouchEvent方法中返回值的设置，如果返回false，那么意味着当前的View不会是该次的责任人，将不会对其持有；如果返回true，此时View会持有该事件并不再向外传递。
可以对请求者和处理者的关系解耦，提高代码的灵活性。
每次都需要对链中请求处理者遍历，如果处理者太多那么遍历必定会影响性能，特别是在一些递归调用者中，要慎用。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'}