很多工具类可能都需要用到 Context 上下文，如图片加载的时候
public void loadImage(Context context, String url, ImageView imageView) {
Glide.with(context)
.load(url)
.apply(mRequestOptions)
.into(imageView);
}
那么这时候这个 context 是在调用该方法时传入比较好呢，还是刚开始写一个set() 方法，用一个成员变量持有比较好?
private Context mContext;
public void setContext(Context context) {
this.mContext = context;
}
这样的话调用加载图片的时候可以少穿一个参数。
context 是在调用该方法时传入比较好
使用时传入比较好。使用成员变量这种方式，会存在一个对象引用，垃圾回收时，会延长对象回收的时间。
并没有太大的区别。本来就是activity里面的静态变量，一半不会删除的。
在程序运行时载入更好，这样可以节省资源
看了你的方法，这个应该是设计（专业点儿叫架构）问题（耦合）。
1、如果你在一个activity里面定义一个方法还要传递Context，不是不行那只能说明你心大/不细；对对象的生命周期要结合实际去运用
2、如果你是定义了一个lib模块或者一个utils模块里面定义一个公用方法，然后使用Context参数（方法or构造），那说明你开始懂得如何去切分软件架构，让程序更具健壮性和维护性
但是如上是一些经验只谈，但是如果你要混淆去用，也不是不行；毕竟成长都是分阶段的（实现、改良、重构）-》推倒重来（实现、改良、重构）
在使用时传入可以减少对context的持有时间，所以使用时传入会好点
如果不要求Context是Activity的话（比如你举得Glide的例子），可以在Application初始化时（如attachBaseContext方法中），把Application的Context保存在一个全局单例里，因为Application的Context在整个应用运行期间都存在，所以不会有内存泄漏问题。
当然每次都传Context也是一种方法，但是传入的Context要尽量保证是Application的Context，以避免Activity的泄露。
构造函数时带过来比较好，如果是函数形式传入可能会出现上下文不符导致指针飞掉的情况
看情况，像你这种glide加载图片，最好传activity，对生命周期进行绑定，要不然会内存泄漏
肯定是在程序运行的时候持有，一开始就持有的话，要消耗内存些。
六楼说的不错 主要还是看使用环境 本质上来说区别不是很大 持有context 和 传入contxt 都差不多 既然你是用到了context 一定要解绑 注意activity 生命周期变化 以及 异常的处理
当然看你的个人喜好 编程是千变万化的 简洁 高效 就好了
context 是在调用该方法时传入比较好，灵活性比较强，想要那个context就那个context
这样写会有内存泄漏的风险 , 当我们在工具类中新启线程 , 或者做耗时操作的时候 , activity 销毁了 , 工具类还持续引用context , 就会出现内存泄漏的风险, 把context获取为application对象 , 可以避免这个风险myapplication.getContext();
这个要看情况了，一般只是在对象的某个方法中临时使用，就在调用时传入比较好，如果对象中有多个方法用到，构造方法或者初始化传入，对象都会持有activity的实例，如果担心静态的activity实例不能被释放，可以使用Weakreference.
使用时传入吧，不然很容易会造成Activity泄漏
1.application 持有
2.activity service传入
这个要看情况， Glide加载图片是在activity中，他与生命周期是有关的，所以初始化时，就将Context传入；
如果要是在一个应用中对象是单例的，也可以在初始化的时候传入；
如果是工具类的静态方法，就要参数传入了。
尽量用applicationcontext