先讨论一下单例再延伸到内存泄露。
0x00 Fragment不需要单例
有时候看到别人的代码中试图在启动Fragment的时候使用单例：
getSupportFragmentManager().beginTransaction().replace(R.id.main_container, HomeFragment.getInstance()).commit();
这是不对的，Fragment是不能用单例的。
我们知道单例的关键就是把类的构造方法设置成private，让类在外部无法被别人实例化；别人请求的时候，直接返回一个已经创建好的instance就好了。这个instance可以是在请求的时候创建的，也可以是在类创建是就建立好的：
private static final Singleton1 single = null; //请求时候再判断要不要新建
private static final Singleton1 single = new Singleton1(); //类创建时就建立好
第一种的话，在getInstance的时候需要注意线程安全，最简单的就是给getInstance()加上synchronized。
如果尝试在Fragment里面新建一个私有构造函数，sdk会提醒你默认构造器必须是public。这样就没办法使用单例了。
默认构造器必须是public的
另外，所有非默认构造函数都不能出现在fragment里面。
单例的初衷是为了避免不一致的状态，用在比如端口、线程池、缓存等需要资源管理的对象上。
Android解释说：「每个fragment都必须有一个空构造函数，这样它才能在恢复它所在的activity的state的时候被实例化。强烈建议子类不要有其他带参数构造函数，因为这些构造函数在fragment被重新实例化的时候不会被调用；可以通过
setArguments(Bundle)和getArguments()传递参数。」
正确使用Fragment的姿势
传递参数
前面说如果你通过构造函数给fragment传参数，这参数在fragment重新创建的时候（比如横竖屏切换）就会丢失。
不可以getInstance但是可以newInstance，比如传一个drunkpiano进去:
if (savedInstanceState == null) {
getSupportFragmentManager().beginTransaction()
.replace(R.id.fl_main, FragmentOne.newInstance("drunkpiano").commit();}
newInstance就是真的new了一个Instance啊，忘掉单例吧。只不过多了一个加入参数的步骤：
//FragmentOne中的newInstance函数
public static FragmentOne newInstance(String text){
FragmentOne fragmentOne = new FragmentOne();
Bundle bundle = new Bundle();
bundle.putString("name", text);//传参
fragmentOne.setArguments(bundle);
return fragmentOne;
}
这样一来就保存起来了，在Fragment onCreateView 的时候用getArguments读一下有没有参数，有就读出来，这样每次Fragment每次重建的时候都能恢复set进来的参数了。为什么能保存？Fragment的生命周期依赖Activity，
如果activity stopped,其中所有的fragment都不能start;
如果activity destroyed, 其中所有的fragment都会被destroyed.
只有activity在resumed状态下,fragment的生命周期可以独立改变,否则它被activity控制.
Activity的onCreate()中有恢复fragment的state的操作：
//Activity的oncCreate的片段
mFragments .restoreAllState(p, mLastNonConfigurationInstances != null
? mLastNonConfigurationInstances .fragments : null);
最终在Fragment.initiate方法中会通过反射启动fragment，如果有argument就重新还给它：
//Fragment.initiate()方法片段
Fragment f = (Fragment)clazz.newInstance();
if (args != null) {
args.setClassLoader(f.getClass().getClassLoader());
f. mArguments = args;
}
这就是为什么能保存argument。
保存数据
Fragment就应该是可复用(reuse)的组件，不应该使用单例。应该使用Fragment.SaveState()或者覆写onSavedInstanceState保存数据。
0x01 内存泄露
前面构造单例的时候，如果你这样写：
static HomeFragment mFragmentInstance = null;
IDE会提示：不要把Android context放到静态field里面去。因为static field will leak contexts.
Java/Android中，静态变量/常量不会被垃圾回收。当classloader创建它们所在的类的时候，它们就一直存在，直到进程退出。一个app里面所有的classloader都是同一个，它持有所有类的静态引用。classloader不会消失所以static变量/常量不会被垃圾回收。
单例内存泄露和context内存泄露
单例的instance必然是static的，这是单例的特性，保证实例在进程生命周期内一直存在，不用重新创建。
单例的问题在于持有一个static的instance，所以instance所在的类一直不会被回收，
public class Util {
private Context mContext;
private static Util sInstance;
private Util(Context context) {
this.mContext = context;
}
public static Util getInstance(Context context) {
if (sInstance == null) {
sInstance = new Util(context);
}
return sInstance;
}
//other methods
}
比如一个Activity启动上面的Util类：
Util.getInstance(this);，这时候Activity生命周期结束了，GC想要回收Activity占用的内存，但是由于sInstance是静态的，一直持有Activity的引用，Activity占用的内存就一直不能被回收。使用finish()之后，destroy回调函数执行了也不行。这样的话比如说Util里面定义了一张图片，这图片占用的内存也不会被回收，很严重。
解决的办法是：
- 用全局context：
getApplicationContext()。
因为这个context实例是在app生命周期内一直存在的。就像我们的工程里面的RunningContext里的sAppContext就是getApplicationContext()得到的。 - 弱引用。
把上面的sInstance用WeakReference包起来。
需要用的时候，用wr.get()。GC线程扫描到弱引用对象的时候会立刻回收它的内存。
为什么IDE会提示不要把context放到静态区域里去
再回到前面的问题，为什么这样写：
static HomeFragment mFragmentInstance = null;
IDE会提示：static field will leak contexts. ？
仔细看的话，IDE会告诉你这个类里面存在了哪些不该存在的变量。它发现里面有不该存在的变量。比如HomeFragment里面，包含了ImageView，SwipeRefreshLayout这两个组件。如果我把这两个组件注释掉，就不会有上面的警告了。有Button什么的也不会警告。上面的Util类，会提示你这个类里面有Context所以不应该写成static。我们知道Context是不能定义成static的。
但是有个问题，为什么都是继承自View，Button、TextView之类的View就不会被提示「不要把Android context放到静态field里面去」？同举说好像是ImageView里面包含Context的回调。
References:
[1]http://www.jianshu.com/p/73503a9a0df8
[2]http://stackoverflow.com/questions/11908039/android-static-fields-and-memory-leaks
网友评论