23、Android设计模式---（对象共享、避免创建多对象）享元模式

又称 FlyWeight，代表轻量级的意思，结构型设计模式。

东源ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！

享元模式是对象池的一种实现。类似于线程池，线程池可以避免不停的创建和销毁多个对象，消耗性能。享元模式也是为了减少内存的使用，避免出现大量重复的创建销毁对象的场景。

享元模式用在一批相同或相似的对象上，这些对象有可以共享的内部状态和各自不同的外部状态。

享元模式中会有一个工厂，工厂维护着一个容器，容器以键值对的方式存储，键是对象的内部状态，也就是共享的部分，值就是对象本身。客户端从这个工厂获取对象，如果容器中存在这个对象就直接返回，不存在再创建新的对象并存入容器，避免了大量重复创建对象。

使用共享对象有效的支持大量的细粒度对象的复用。

系统中存在大量的 相似对象。

细粒度的对象都具备较接近的外部状态，且内部状态与环境无关，即对象没有特定身份。

需要 缓冲池 的场景。

例1. 过年回家买火车票，无数人在客户端上订票 (有多次购票、刷票的情况)，即不断向服务端发送请求。

而每次查询，服务器必须做出回应，具体地，用户查询输入出发地和目的地，查询结构返回值只有一趟列车的车票。而数以万计的人有同样需求，即不间断请求数据，每次重新创建一个查询的车票结果，即造成大量重复对象创建、销毁，使得服务器压力加重。

享元模式正好适合解决该情形的问题，例如 A 到 B 地的车辆是有限的，车上铺位分硬卧、软卧和坐票三种，将这些可公用的对象缓存起来。用户查询时优先使用缓存，反之则重新创建。

我们知道 Java 中 String 是存在于常量池中，即一个 String 被定义之后它就被缓存到了常量池中，当其他地方使用同样的字符串，则直接使用缓存，而非创建。

享元模式的优缺点

优点 - 大幅度地降低内存中对象的数量。

缺点-1) 为了使对象可共享，需将一些状态外部化，使程序的逻辑复杂化

如何理解android中的上下文对象（Context对象）？

Context，中文直译为“上下文”，SDK中对其说明如下：

Interface to global information about an application environment. This is an abstract class whose implementation

is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls

for application-level operations such as launching activities, broadcasting and receiving intents, etc。

从上可知一下三点,即：

1、它描述的是一个应用程序环境的信息，即上下文。

2、该类是一个抽象(abstract class)类，Android提供了该抽象类的具体实现类(后面我们会讲到是ContextIml类)。

3、通过它我们可以获取应用程序的资源和类，也包括一些应用级别操作，例如：启动一个Activity，发送广播，接受Intent信息等。

Android SharedPreferences对象的获取

Android中主要提供了三种方法用于获取SharedPreferences对象

getSharedPreferences()方法接收两个参数，第一个参数为创建的文件名称SharedPreferences文件存放在/data/data/packagename/share_preds目录下。第二个参数为指定的操作模式，目前只能选择MODE_PRIVATE这一种模式，MODE_PRIVATE为默认模式，和直接传入0的效果是相同的，表示只有当前的应用程序才能对这个SharedPreferences文件进行读写（可参考Context的枚举属性）。

该方法和Context类中的getSharedPreferences()方法相似，不过它只接收操作模式一个参数，因为使用该方法时系统会自动把当前活动的类名作为SharedPreferences的文件名。

getDefaultSharePreferences()方法为静态方法，它接收一个Context参数，并自动使用当前应用程序包名作为前缀来命名SharedPreferences文件。

自己关于Android上下文对象的理解

Android中有个我们熟悉又陌生的对象Context(上下文)，当我们启动Activity的时候需要上下文，当我们使用dialog的时候我们需要上下文，但是上下文对象到底是个什么东西呢？

在Android api当中是这样描述context对象的。

"Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc."

“是一个用于实现关于应用环境的整体信息的一个接口。这是一个由安卓系统提供的抽象类并且系统有对他进行实现。它允许访问到应用特殊的资源和类，同时它也可以实现到应用级别的操作，例如：Activity的启动，广播的实现和接受intent等。”

一、Context的主要实现和继续理解

知道了context的大概描述，我们可以再继续理解Context这个神秘的对象了，首先，作为基类，肯定有其它类去实现它，主要实现了context类的类是Activity，Service，Application。他们三个类虽然都是Context的子类，但是具体的继承关系却有些不大一样：

Activity的继承关系：

Service和Application的继承关系：

可以看出我们的Context其实就是我们熟知的Activity，Service，Application。

在这3个类中，Activity的context对象和Application的context对象最容易弄混淆。

二、Context中的主要方法

知道了Context的大概描述和他的一些继承关系，我们对Context这个类有了一个大致的了解。现在可以看看在context中的一些方法，来加深对context的一个理解，有很多我们使用过的方法其实都是从Context这个类中实现而来。

我们从Android api中查看Context类，这里出现了一个非常熟悉的方法：startActivity，可以看到其实Activity中的StartActivity方法是重写了Context中的方法。

abstract void startActivity ( Intent intent)

Same as startActivity(Intent, Bundle) with no options specified.

abstract void startActivity ( Intent intent, Bundle options)

Launch a new activity.

同时context还可以访问到资源文件，获得资源文件中的信息。

abstract Resources getResources ()

Return a Resources instance for your application's package.

abstract SharedPreferences getSharedPreferences ( String name, int mode)

Retrieve and hold the contents of the preferences file 'name', returning a SharedPreferences through which you can retrieve and modify its values.

final String getString (int resId)

Return a localized string from the application's package's default string table.

final String getString (int resId, Object... formatArgs)

Return a localized formatted string from the application's package's default string table, substituting the format arguments as defined in Formatter and format(String, Object...) .

同时context不但可以开启一个activity，同时还可以开启或者关闭一个Service。

abstract ComponentName startService ( Intent service)

Request that a given application service be started.

abstract boolean stopService ( Intent service)

Request that a given application service be stopped.

访问Android Api 或者查看源码可以看到，Context中还有很多访问资源文件和程序之间互相通信的方法。

可以看出context其实就是一个应用之中的手脚，可以通过他来拿取资源文件中的资源，还可以通过他来处理Activity和Service中的一些操作，这个类就是整个程序的枢纽，负责管理整个程序的通畅运行。

我们可以通过分析一个Toast通知的源码去分析context的去向和使用，来了解context到底做了些神马操作：

public static Toast makeText(Context context, CharSequence text, int duration) {

Toast result = new Toast(context);

LayoutInflater inflate = (LayoutInflater)

context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);

TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);

tv.setText(text);

result.mNextView = v;

result.mDuration = duration;

return result;

}

可以看到makeText方法接受的context被用于

context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);

这是用于获取XML中定义的View的方法，可以看到通过外部传入的Context，在这里获得了一个View布局用于显示Toast。

public Toast(Context context) {

mContext = context;

mTN = new TN();

mTN.mY = context.getResources().getDimensionPixelSize(

com.android.internal.R.dimen.toast_y_offset);

mTN.mGravity = context.getResources().getInteger(

com.android.internal.R.integer.config_toastDefaultGravity);

}

这一行中可以看出在context又被用来获取资源文件，可以看出Toast的显示和布局都是通过context去调用系统写好的资源文件来进行实现的。

三、Activity context和Application context的区别

Activity的context和Application的context的区别在于生命周期的区别，Activity的context是依附在着Activity的生命周期的，而Application的Context的生命周期是依附在整个应用之上的。

当前名称：android对象,android面向对象
本文URL：http://abwzjs.com/article/phseho.html