如何在你的应用中正确使用Context
写在前面：
Context对象在我们的项目中实在是太常见了，启动Activity、Service、发送一个Broadcast，作为获取各种系统Resources的参数，Layout Inflation的参数，show a Dialog的参数等等。Context对象的使用不当，是可能造成内存泄漏的，当你的工程代码已经达到十几万行甚至是几十万行时，Context对象就对内存泄漏造成非常可观的影响了，所以我们应该对Context对象的使用，做到心中有数。
零：什么是Context
前两天刚刚对 Context 写了一篇比较长的博客，借鉴大牛们的经验，对 Context 进行了比较详细的整合与总结，花半个小时的时间耐心读一读吧！
一句话总结：
Context是为一个Android程序提供各种功能、资源、服务的一个环境， Context 的资源在系统中只有一套，因为它的子类（Application、Activity、Service）对这同一块资源处理方式的不同，让Context 对象在功能上表现出各自之间的差异。
一：Context对象之间的差异
相信如果你是一个初学者， Context 在你手里应该是胡乱传入的，哪里有 Context 就找哪里，各种this乱入，O(∩_∩)O哈哈，至少当时我是这样的，但是 Context 不同的对象在使用功能上是有区别的，比如以下代码：
在清单文件中做以下配置：
在界面中show a Dialog
点击按钮之后崩溃信息
当我使用Application的Context时，是无法弹出一个Dialog的，因为Dialog作为一个View，依附在Activity上，并且与Theme相关，当传入参数为Actvity的Context时，崩溃就解决了。
下面这张表展示出了Context对象之间使用上的差异：
二：Context相关的内存泄漏问题
在讨论内存泄漏之前，先简单的说说Android中内存的回收
Dalivik虚拟机扮演了常规的垃圾回收角色，为了GC能够从App中及时回收内存，我们需要时时刻刻在适当的时机来释放引用对象，Dalvik的GC会自动把离开活动线程的对象进行回收。
什么是Android内存泄漏：
虽然Android是一个自动管理内存的开发环境，但是垃圾回收器只会移除那些已经失去引用的、不可达的对象，在十几万、几十万行代码中，由于你的失误使得一个本应该被销毁的对象仍然被错误的持有，那么该对象就永远不会被释放掉，这些已经没有任何价值的对象，仍然占据聚集在你的堆内存中，GC就会被频繁触发，多说几句，如果手机不错，一次GC的时间70毫秒，不会对应用的性能产生什么影响，但是如果一个手机的性能不是那么出色，一次GC时间120毫秒，出现大量的GC操作，我相信用户就能感觉到了吧。这些无用的引用堆积在堆内存中，越积越多最终导致Crash，有关一些性能优化推荐给大家一个我总结的博客。
有些跑题了，我们赶紧来看看什么情况下Context会引发内存泄漏
- 错误的单例模式
我们来分析一下这个非线程安全的单例模式，假设你在Activity A去getInstance获得instance对象，顺手传了一个this，好了，现在一个常驻内存的Singleton保存了你传入Activity A的对象，并且一直持有Activity A的引用，这样即使你Activity被销毁掉，但是因为它的引用还存在于一个Singleton中，是不可能被GC掉的，这样就导致了内存泄漏。
- View持有Activity的引用
再来分析一下，有一个静态的Drawable对象，当我给ImageView设置这个Drawable时，ImageView像上面那个例子一样，保存了这个mDrawable的引用（大家可以点开源码705行去看，很多UI组件都是统一的操作，一直持有传入的对象），然而ImageView传入了this，也就是ImageView同样持有一个MainActivity的mContext。因为被static修饰的mDrawable是常驻内存的，MainActivity是它的间接引用，所以当MainActivity被销毁时，也不能被GC掉，所以也造成了内存泄漏。
三：使用Context的正确姿势
通俗一点说，Context造成的内存泄漏，几乎都是当Context销毁的时候，却还被各种不合理、无端地引用着。那么哪个Context对象是不会被销毁的呢？对了，Application的Context对象可以理解为随着进程存在的，所以当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context
调用一行代码：
LaucherApplication.getContext();
回头看看上面那张表格，显然Application的Context不是万能的，涉及UI加载操作时，似乎我们只能使用Activity的Context，所以你当你使用Activity的Context时，你要对持有Activity的对象心中有数，保证它能随着生命周期的销毁而被回收，慎用static关键字，不要因为方便访问就各种static乱入。
多说一点，上表中Layout Inflation中只能使用Activity的Context，而各种View在创建时，需要传入的Context参数也是Activity的，大家懂了吧，当解析XML文件的时候，传入的参数也就统一了，相信大家一定能想明白这点。
写在最后：
给大家推荐一个内存检测的自动化工具，LeakCanary，但是当你曾经写出的代码不规范不负责，已经达到十几万行，几十万行的时候，再去抽丝剥茧试图解开已经打上层层死结的引用关联，是非常难的。所以平时还是要注意下细节哈~
如果大家觉得喜欢有价值，就关注我，点下赞哈，你们的支持是我持续原创的动力。