《Android源代码设计模式解析与实战》读书笔记(二十二)

第二十二章、享元模式

享元模式是结构型设计模式之中的一个。是对对象池的一种实现。就像它的名字一样,共享对象。避免反复的创建。

我们经常使用的String 就是使用了共享模式。所以String类型的对象创建后就不可改变,假设当两个String对象所包括的内容同样时,JVM仅仅创建一个String对象相应这两个不同的对象引用。

1.定义

採用一个共享来避免大量拥有同样内容对象的开销。使用享元模式可有效支持大量的细粒度对象。

2.使用场景

(1)系统中存在大量的类似对象。

(2)细粒度的对象都具备较接近的外部状态,并且内部状态与环境不关,也就是说对象没有特定身份。

(3)须要缓冲池的场景。

PS:内部状态与外部状态:在享元对象内部并且不会随着环境改变而改变的共享部分。能够称之为享元对象的内部状态,反之随着环境改变而改变的。不可共享的状态称之为外部状态。

3.UML类图

享元模式分为单纯享元模式和复合享元模式,上图是复合享元模式。

(1)Flyweight:享元对象抽象基类或者接口。

(2)ConcreateFlyweight:详细的享元对象,假设有内部状态的话。必须负责为内部状态提供存储空间。

(3)UnsharadConcreateFlyweight:复合享元角色所代表的对象是不能够共享的,并且能够分解成为多个单纯享元对象的组合。

单纯享元模式没有此项,这也是两者在结构上的差别。

(4)FlyweightFactoiy:享元工厂,负责管理享元对象池和创建享元对象。

(5)Client:维护对全部享元对象的引用,并且还须要存储相应的外蕴状态。

4.简单实现

情景:过春节买火车票的时候,我们须要查询车票的情况。那么假设每次查询车票时都创建一个结果,那么必定会大量的创建出很多反复的对象。频繁的去销毁他们,使得GC任务繁重。那么这时我们能够使用享元模式,将这些对象缓存起来,查询时优先使用缓存,没有缓存在又一次创建。

首先是Ticket接口(Flyweight):

public interface Ticket {

    public void showTicketInfo(String bunk);

}

TrainTicket详细实现类(ConcreateFlyweight):

//火车票
public class TrainTicket implements Ticket{

    public String from; // 始发地
    public String to; // 目的地
    public String bunk; //铺位
    public int price; //价格

    public TrainTicket(String from, String to) {
        this.from = from;
        this.to = to;
    }

    @Override
    public void showTicketInfo(String bunk) {
        price = new Random().nextInt(300);
        System.out.println("购买 从 " + from + " 到 " + to + "的" + bunk + "火车票" + ", 价格:" + price);
    }

}

TicketFactory 管理查询火车票(FlyweightFactoiy):

public class TicketFactory {
    static Map<String, Ticket> sTicketMap = new ConcurrentHashMap<String, Ticket>(); 

    public static Ticket getTicket(String from ,String to){
        String key = from + "-" + to;
        if(sTicketMap.containsKey(key)){
            System.out.println("使用缓存 ==> " + key);
            return sTicketMap.get(key);
        }else{
            System.out.println("创建对象 ==> " + key);
            Ticket ticket = new TrainTicket(from, to);
            sTicketMap.put(key, ticket);
            return ticket;
        }

    }
}

查询:

final class Client {
    public static void main(String[] args) {
        Ticket ticket01 = TicketFactory.getTicket("北京", "青岛");
        ticket01.showTicketInfo("上铺");

        Ticket ticket02 = TicketFactory.getTicket("北京", "青岛");
        ticket02.showTicketInfo("下铺");

        Ticket ticket03 = TicketFactory.getTicket("北京", "西安");
        ticket03.showTicketInfo("坐票");
    }
}

结果

创建对象 ==> 北京-青岛
购买 从 北京 到 青岛的上铺火车票, 价格:71
使用缓存 ==> 北京-青岛
购买 从 北京 到 青岛的下铺火车票, 价格:32
创建对象 ==> 北京-西安
购买 从 北京 到 西安的坐票火车票, 价格:246

5.Android源代码中的实现

1.Message

由于Android是事件驱动的,因此假设通过new创建 Message 就会创建大量的 Message 对象,导致内存占用率高,频繁GC等问题。那么 Message 就採用了享元模式。

Message通过next成员变量保有对下一个Message的引用。最后一个可用Messagenext则为空。从而构成了一个Message链表

Message Pool就通过该链表的表头管理着全部闲置的Message,一个Message在使用完后能够通过recycle()方法进入Message Pool,并在须要时通过obtain静态方法从Message Pool获取。

Message 承担了享元模式中3个元素的职责,即是Flyweight抽象。又是ConcreateFlyweight角色。同一时候又承担了FlyweightFactoiy管理对象池的职责。

所以使用Message推荐obtain(),不要去new了。

//1。

使用new Message()
//Message mess = new Message();  

//2。使用Message.obtain()
Message mess = Message.obtain();
mess.what = 1;  

//Message mess = mHandler.obtainMessage(1);  与上两行的代码一样。能够參考源代码查看
mHandler.sendMessage(mess);  

6.总结

1.长处

(1)大大降低应用程序创建的对象,降低程序内存的占用。增强程序的性能。

(2)使用享元模式,能够让享元对象能够在不同的环境中被共享。

2.缺点

(1)使得系统更加复杂。为了使对象能够共享,须要将一些状态外部化。这使得程序的逻辑复杂化。

(2)享元模式将需、享元对象的状态外部化,而读取外部状态使得执行时间略微变长。

7.參考

1.深入浅出享元模式

时间: 2024-08-10 23:29:59

《Android源代码设计模式解析与实战》读书笔记(二十二)的相关文章

Effective C++读书笔记之十二:复制对象时勿忘其每一个成分

Item 12:Copy all parts of an object 如果你声明自己的copying函数,意思就是告诉编译器你并不喜欢缺省显示中的某些行为.而编译器会对"你自己写出copying函数"做出一种复仇的行为:既然你拒绝它们为你写出copying函数,如果你的代码不完全,它们也不会告诉你.结论很明显:如果你为class添加一个成员变量,你必须同时修改copying函数.如果你忘记,编译器不太可能提醒你. 一下提供一种正确的模版: class Date{...}; class

Hadoop读书笔记(十二)MapReduce自定义排序

Hadoop读书笔记系列文章:http://blog.csdn.net/caicongyang/article/category/2166855 1.说明: 对给出的两列数据首先按照第一列升序排列,当第一列相同时,第二列升序排列 数据格式: 3 3 3 2 3 1 2 2 2 1 1 1 2.代码 SortApp.java package sort; import java.io.DataInput; import java.io.DataOutput; import java.io.IOExc

《Android源码设计模式解析与实战》读书笔记(十二)

第十二章.观察者模式 观察者模式是一个使用率非常高的模式,它最常用在GUI系统.订阅–发布系统.因为这个模式的一个重要作用就是解耦,将被观察者和观察者解耦,使得它们之间的依赖性更小,甚至做到毫无依赖.比如安卓的开源项目EventBus.Otto.AndroidEventBus等事件总线类的和RxJava响应式编程其核心都是使用观察者模式. 1.定义 观察者模式是一种行为类模式,它定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新. 2.使用场景

《Linux内核设计与实现》读书笔记(十二)- 内存管理

内核的内存使用不像用户空间那样随意,内核的内存出现错误时也只有靠自己来解决(用户空间的内存错误可以抛给内核来解决). 所有内核的内存管理必须要简洁而且高效. 主要内容: 内存的管理单元 获取内存的方法 获取高端内存 内核内存的分配方式 总结 1. 内存的管理单元 内存最基本的管理单元是页,同时按照内存地址的大小,大致分为3个区. 1.1 页 页的大小与体系结构有关,在 x86 结构中一般是 4KB或者8KB. 可以通过 getconf 命令来查看系统的page的大小: [[email prote

《APUE》读书笔记第十二章-线程控制

本章中,主要是介绍控制线程行为方面的内容,同时介绍了在同一进程中的多个线程之间如何保持数据的私有性以及基于进程的系统调用如何与线程进行交互. 一.线程属性 我们在创建线程的时候可以通过修改pthread_attr_t结构的值来修改线程的属性,将这些属性与创建的线程联系起来.调用pthread_attr_init以后,pthread_attr_t结构所包含的内容就是操作系统实现支持的线程所有属性. #include <pthread.h> int pthread_attr_init(pthrea

java编程思想读书笔记 第十二章 通过异常处理错误(下)

1.异常的限制 当覆盖方法的时候,只能抛出在基类方法的异常说明里列出的那些异常.这意味着,当基类使用的代码应用到其派生类对象的时候,一样能够工资,异常也不例外. 下面的例子是在编译时施加在异常上面的限制: public class BaseBallException extends Exception {} public class Foul extends BaseBallException{} public class Strike extends BaseBallException{} p

C primer plus 读书笔记第十二章

C的强大功能之一在于它允许我们控制程序的细节.C的内存管理系统正是这种控制能力的例子.它通过让我们决定哪些函数知道哪些变量以及一个变量在程序中存在多长时间来实现这些控制. 1.存储类及其说明符 主要的定义:作用域.链接以及存储时间.其他编程语言也有类似的概念.C语言通过这三个概念定义了5中存储类.其说明符分别为auto.register.static.extern和typedef. 2.存储类和函数 函数也分为外部的和静态的.关键字是extern和static.默认情况下是外部的. 3.mall

《Programming in Lua 3》读书笔记(二十二)

日期:2014.8.6 PartⅣ The C API 26 Extending Your Application 使用Lua很重要的一点是用来做配置语言.配合主语言做一些功能的配置. 26.1 The Basics 有的时候程序需要配置一些功能信息,很多时候可能有许多别的方法比用lua做配置要更简单:如使用环境变量或者读取文件,读取文件涉及到文件的解析.如果使用Lua进行配置的话,相当于用lua文件替代了要读取的如csv.txt文件等. 使用Lua进行配置的时候,就需要使用Lua API去控制

《android开发艺术探索》读书笔记(十五)--Android性能优化

接上篇<android开发艺术探索>读书笔记(十四)--JNI和NDK编程 No1: 如果<include>制定了这个id属性,同时被包含的布局文件的根元素也制定了id属性,那么以<include>指定的id属性为准 No2: 绘制优化 1)onDraw中不要创建新的局部对象 2)onDraw方法中不要做耗时的任务 No3: 内存泄露优化 场景一:静态变量导致的内存泄露: 如果静态变量持有了一个Activity,会导致Activity无法及时释放. 解决办法:1使用Ap

42. 蛤蟆的数据结构笔记之四十二图的遍历之广度优先

42. 蛤蟆的数据结构笔记之四十二图的遍历之广度优先 本篇名言:"生活真象这杯浓酒 ,不经三番五次的提炼呵 , 就不会这样一来可口 ! -- 郭小川" 继续看下广度优先的遍历,上篇我们看了深度遍历是每次一个节点的链表是走到底的. 欢迎转载,转载请标明出处:http://write.blog.csdn.net/postedit/47029275 1.  原理 首先,从图的某个顶点v0出发,访问了v0之后,依次访问与v0相邻的未被访问的顶点,然后分别从这些顶点出发,广度优先遍历,直至所有的