引言

---

Context大家都不陌生，最先接触的使用应该就是startActivity。当有些代码需要复用抽离出来作为工具类方法的时候，Context从哪里来呢？（这里并不是讲Activity、Context、ApplicationContext等等这个家族之间剪不断理还乱的暧昧关系所以统称Context）
在Activity中获取Context的方法

Activity中的Context

在Fragment中获取context的方法

Fragment中的Context
Fragment中的Activity
工具类中的Context可以通过参数传递过来，这种场景适用于需要通过当前的上下文情景做某些事情，例如：特定Activity的场景切换（触发登录）、权限申请（回调监听）等。
还有一种情况就是不需要情景，单纯获取数据资源的情况，例如我碰到的：获取系统屏幕px/dp的比率（命名为dpTopx）。

此时传递Activity、Fragment的Context是完全没问题的，以前我的做法是将dpTopx写到BaseActivity和BaseFragment中。
这次我单独将它写到工具类，通过Application的Context来计算。有没有嗅到优化的气息！！
于是问题就来了，Kotlin中怎么写？

正文

---

熟悉java的应该都不会陌生，且大多项目应该都是这么写的（如果不是请一定要教我）。

java的Application

分析一下：

• 继承自Application
• 静态内部变量
• 赋值
• 公共方法

于是照猫画虎

kotlin的Application

由于kotlin静态的声明放在了companion object块中最初还真不舒服。

这里讲讲警告和!!

警告

1、编译器提醒不可以将Context声明为静态变量，这样会导致内存泄漏。
讲解一下：如果有A（main）、B、C三个Activity它们都有自己的静态变量Context，A启动了B，此时B.context被分配内存并赋值，B再启动C，C.context被分配内存并赋值，按返回，到了B，C应该被GC，但由于context为静态变量且对C有引用，所以C在内存中常驻，再返回，到了A，B同样应该被GC，但context为静态变量，所以B也赖在内存，因此产生了内存泄露。除非kill app，否则B、C都被引用无法释放。

2、至于!!，用的真是妙，虽然永远都不会NullPointerException（去这里看笔记）

Kotlin学习中触碰到的知识点
http://www.jianshu.com/p/7cb426ee324c

忍不住了！
缘，妙不可言

忘了上图了，补一个

补的