Android开发中使用单例模式的一个小的注意点(在私有构造中做一些初始化的问题)

说在最前面：本篇文章不是讲单例模式有哪几种创建方式以及各自的利弊，也不说什么情况下单例模式失效以及内存泄漏等类似面试题，只说个人在应用中想要总结的一个小问题，如果冲着上面说的内容来的，那可以继续找其他的了[笑哭.gif]。

单例模式和其他设计模式一样，不是Android以及java所特有的设计模式，但估计是Android开发中使用最多的设计模式，且不说它全局只存在一个实例的特性可以减少不必要的对象创建这一点，单是它设计简单且是静态化调用等特性就让它被接受门槛变得相对较低了，当然这样说也不是说它"好欺负"，如果使用不当，也会造成不必要的麻烦，比如内存泄漏等，这里说一个"成也全局败也全局"的小问题。

我直接举个例子说明吧，下面这个例子不是特别的合适，真正开发中也没人这么写，但是能表达我想说的问题，你理解中间的思想就行，代码细节不要太过纠结[捂脸.gif]。还有一点，这个例子我是用java和kotlin混合开发的，第三张图的Activity中是kotlin，事先声明这一点，以免感觉莫名其妙。

图1.

如图1.创建了一个单例类，主要就是封装了Toast，create()方法里创建Toast对象，close里把对象置空，刚才说了，真正这样写的人应该没有，但是先别着急批判这个，继续往下看重点就行。

图2.

图2又是一个单例，这个单例主要就是封装上一个单例的方法(ps:其实真必要这么写，一会绕晕了[捂脸]，不过第一个单例如果是包内可见，不对外开放呢？只想开放第二个单例的话，这样写是不是就有点合理了?)，图2这个单例是我要说的重点所在，大家可以看到，我在它的私有构造方法中调用了SingletonDemo的create方法，目的就是为了让使用者免去自己调用的步骤，直接使用showToast就行了。

下面来到图3中：在Activity中使用图2单例封装的showToast方法，然后在onStop方法中调用close方法，就是把Toast对象置为空的操作，这样写是为了"模拟"一些类似资源释放，资源回收的操作。这样写看起来似乎有点合理，还知道页面退出的时候释放资源，不错哦。但是，重点来了，如果你没有退出应用杀死应用进程的话，再次进到这个页面时继续使用这个showToast方法，你就会发现没有反应。说到这里，估计一般人也知道怎么回事了，就是因为刚才你退出这个Activity的时候在onStop方法中调用了close，把Toast创建的对象回收了，而这个Toast创建的方法create()是在图2单例的私有构造中调用的，这个单例没有重新创建的话，这个create方法不会再次调用！想说的也就是这么一个问题。说得更明白一些就是：单例由于是静态化，它的生命周期和应用的生命周期一样长，应用没有退出(进程彻底杀死)的话，这个单例就一直存在，所以就一直不会重新创建，也就是私有构造不会再次调用，那么私有构造方法中执行的操作也都是"一次性"的了。

图3.

所以，像上面类似的close等释放资源的操作不要过早的执行，在程序退出的时候调用才合适，否则你要记得自己手动去执行图1单例中的create方法才行，但是如果像刚才说的，如果这个类是包内可见，你没有源码，只能访问图2单例的话，岂不是麻烦？

你会问，刚才也说了，正常人不会这么写Toast的使用，但是如果我们有的时候真需要在私有构造中提前执行一些逻辑并且给出释放资源的操作，这种类似的情况是不是会发生的？比如数据库的创建与关闭，socket的连接与关闭等，我如果想在整个应用运行过程中只建立一次socket连接，然后一直保持通信，只在退出应用时关闭连接释放资源，那我把连接的操作写在单例的私有构造中是不是也比较合理？所以，注意单例的这个"长生命周期"的问题就行了。

最后补充一点吧，单例好用，但是最简单的使用也会造成一些问题，比如内存泄漏：

图4.

比如把图2中的单例改写成需要外部传Context的样子，因为单例中Context使用范围太广了，单例中能用到Context一点不奇怪吧？如果我们传进来的是Activity或者Service类型的Context，那么Activity/Service退出的时候如果应用还在运行，那么由于单例的生命周期和应用一样长，那么它持有的刚才的Activity就回收不了了。虽然我们可以传Application这个生命周期长的Context，但是还是建议不要直接通过创建单例的时候传进来，哪怕你在Application中写一个静态的getContext(){...}呢？，然后使用Context的地方直接传它就行了呗，尽量别直接给单例了。