摘要：
1.本文将详细介绍享元模式的原理和实际代码中特别是Android系统代码中的应用。
纲要：
1. 引入享元模式
2. 享元模式的概念及优缺点介绍
3. 享元模式在Android源码中的应用
1.先来一个段子：
GG每天给MM至少发一条短信，而且每天入睡前是必有一条短信的，往往是一些琐事和一些比较肉麻的情话。开始的一个月，GG还对此是乐不可支，随着时间的推移，那些肉麻的话说了很多遍，自己也觉得厌烦了，而且更让人不可忍耐的是这些肉麻的情话每次都要重复的输入。GG把这一烦心事告诉了自己的好友K，K说，“你这个大傻瓜，怎么不把一些你常用的话存放在你的手机中，这样，要用的时候，直接拿来用就行了”，傻GG一听，顿时觉得醍醐灌顶，于是立即在手机中存放入了“宝贝儿，晚安喔”、“你是我天使”，“宝贝儿，我永远的爱你”等话语。（摘自Android大话设计模式）
2.享元模式介绍
2.1什么是享元模式？
为了节约内存资源，把具有重复性质的实例进行统一管理（结合Factory模式），使用时对象一般不创建新实例，只进行引用。Flyweight本是体育上的一个术语，用来表示轻量级。Flyweight，飞翔般的重量，说明使用它会使代码变得“轻”（指内存消耗方面）起来。
2.2享元模式有什么好处？
上面已经提到了，它最大也是唯一的好处就是：“轻”。享元能够节省重复实例的内存消耗。举两个最经典的例子。
1、26个英文字母的点阵显示数据。我们使用它们的时候，如果每次使用都创建新的字母实例，那内存浪费是很严重的。我们可以很容易的想到，将这26个点阵数据个创建一个实例，并专门用一个类管理起来。当用户需要使用的时候，给他们这些实例的引用，这样就能大大节省内存消耗了。
2、画画。假设我能画的图形是有限的（圆，长方形，棱形，梯形等），画画就是把这些图形不断的往上贴图。当我一幅画有上千个图案的时候，享元模式就成为了很好的减少内存消耗的解决方案。我们把固定的图形都只创建一个实例，等要画的时候，使用它们的引用“作画”即可。
不过这个画画的例子就有问题了：这些独立图形的位置，大小，颜色都不一样，而实例只有一个，这样画出来岂不是都挤一块去了？这里是享元模式的关键的地方：区分内蕴态和外蕴态。简单说就是：一部分（图形）共享（称为内部储存或内部状态），一部分（大小，位置，颜色）不公享（称为外部储存或外部状态）。把这个概念加进去，享元模式就灵活多了。
3.源码实战：
3.1String：
没想到吧！String用到了享元模式。其实我也没想到。就我个人理解，与其说String使用享元模式，不如说是用到了它的思想，毕竟它的实现不是通过活生生的Java代码。下面一起来看一下：
String s0=”abc”; String s1=”abc”; String s2=”a” + “bc”; System.out.println( s0==s1 ); System.out.println( s0==s2 );
结果为：
true true
我们都知道，String是一种对象（非基础类型，下同），对象的==比较的是和指向的内存有关的。如果两个对象指向的是同一个数据，那他们是相等的（Java语言是不支持重载的，所以没有例外情况）。
但上面的写法不应该是三个独立的数据段吗？这里就涉及到常量池。
常量池(constant pool)指的是在编译期被确定，并被保存在已编译的.class文件中的一些数据。它包括了关于类、方法、接口等中的常量，也包括字符串常量。 这些字符串对于编译器来说，都是同样的常量字符串，所以编译器把他们简化成了一条数据，从而优化了内存使用。这和享元模式的思想如出一辙。
如果我们这样写：
String s0=”abc”; String s1= new String(“abc”); System.out.println( s0==s1 );
结果为：
false
为什么会这样？因为s1等号右边不是常量字符串，而是实例化操作，人家编译器不认这种非静态的东西。这也说明了一点，享元需要专门的类来管理，否则就会出现上面那种不适用的情况。一般来说都是用Factory。
3.2SQLiteCompiledSql：
（参考Android设计模式系列(6)--SDK源码之享元模式 http://www.cnblogs.com/qianxudetianxia/archive/2011/08/10/2133659.html）
Android中SQLiteCompiledSql的使用，其实是很多数据库系统典型的实现。从应用启动，通过各种数据库操作，我们不知道进行了多少次的查询操作，而这些操作中又有相当一部分sql语句是相同的，这些编译后的sql编译对象其实是一样的，是可以共用共享的，其实就是缓存。SQLiteCompiledSql就是这样的一个需要共享的享元对象。
UML图：
其中SQLiteCompiledSql就是被管理享元对象，主要是内部状态sql语句：
class SQLiteCompiledSql {
private String mSqlStmt = null;
native_compile(sql);
native_finalize();
}
享元对象只是存放固定内容的实例，具体实现精华在管理享元对象的工厂中。
SqliteDatabase就是管理享元对象的工厂，它里面的mCompiledQuerie就是存放享元对象的容器。通常都是使用HashMap（HashTable的替代品，详细http://oznyang.iteye.com/blog/30690）进行储存。通过这种方式大大减少了sql编译对象的创建，提高了数据库操作的性能。
public class SQLiteDatabase{
Map<String, SQLiteCompiledSql> mCompiledQueries = Maps.newHashMap();
SQLiteCompiledSql getCompiledStatementForSql(String sql) {
SQLiteCompiledSql compiledStatement = null;
boolean cacheHit;
synchronized(mCompiledQueries) {
if (mMaxSqlCacheSize == 0) {
return null;
}
cacheHit = (compiledStatement = mCompiledQueries.get(sql)) != null;
}
if (cacheHit) {
mNumCacheHits++;
} else {
mNumCacheMisses++;
}
return compiledStatement;
}
private void deallocCachedSqlStatements() {
synchronized (mCompiledQueries) {
for (SQLiteCompiledSql compiledSql : mCompiledQueries.values()) {
compiledSql.releaseSqlStatement();
}
mCompiledQueries.clear();
}
}
void addToCompiledQueries(String sql, SQLiteCompiledSql compiledStatement) {
//省略具体代码
}
}
大体享元工厂都是这样一个结构：
HashMap：用作储存（就和String的常量池一样）
get方法：得到享元对象的引用
add方法：增加新的享元对象，用作初始化，一般使用者不会接触到。也有更灵活的享元模式使用会动态的增加HashMap没有的享元对象（设计模式是死的，人写出来的代码是活的，怎么用全凭大家）。
dealloc方法：释放所有的享元对象，Java有自己的内存回收机制，这个可选。
版权所有，转载请注明出处：