与片段上下文滑行 [英] Glide with Fragment Context

查看:105
本文介绍了与片段上下文滑行的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这与在应用程序上下文中加载滑行图像

我在一个Activity中托管了多个片段,当用户浏览应用程序时,片段会被另一个片段替换.

I have several Fragments hosted in an Activity, with a Fragment being replaced by another as the user navigates through the app.

我正在将RequestManager传递到MyFragment的RecyclerView适配器中,如下所示:

I'm passing a RequestManager into my MyFragment's RecyclerView adapter like so:

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
                            Bundle savedInstanceState) {
    ...

    MyAdapter adapter = new MyAdapter(Glide.with(this), listOfPhotos);
    recyclerView.setAdapter(adapter);

    ...
}

我的适配器:

public class MyAdapter
    extends RecyclerView.Adapter<MyAdapter.ViewHolder> {

    private RequestManager mGlide;

    ...

    // constructor
    public MyAdapter(RequestManager glide, List<MyStuff> listOfPhotos) {
        mGlide = glide;

        ...
    }

    ...

}

当我调试我的应用程序时,这就是我在对象mGlide中看到的内容:

When I debug my app, here's what I see in the object mGlide:

context似乎是我项目的ApplicationContext.现在我对Android上下文不是很熟悉,但这是对的吗?我以为会是com.MyFragment .....

The context seems to be my project's ApplicationContext. Now I'm not very familiar with Android contexts, but is this right? I assumed it will be something like com.MyFragment.....

还有,有没有一种简单的方法来检查滑行是否遵循片段的生命周期?

Also, is there a simple way to check if glide is following my fragments' lifecycles?

推荐答案

该问题更适合自述文件链接

This question would've been better suited for Glide's Google Group linked from the Readme.

您的用法看起来干净,高效,这就是我建议使用的方式.

Your usage looks clean and performant, and that's the way I suggest to go with.

上下文似乎是我项目的ApplicationContext.

The context seems to be my project's ApplicationContext.

Glide是单例,因此使用看到的第一个Activity对其进行初始化没有任何意义(请参阅Glide.get).如果检查RequestManager实际使用该Context的方式,您会看到它在各处传递,这将不再有用,并且会泄漏.在其他类中,它通常用于.getContentResolver并通过Glide.get(context)获取Glide单例.

Glide is a singleton, and hence it wouldn't make any sense to initialize it with the first Activity it sees (see Glide.get). If you check how RequestManager actually uses that Context you'll see it is passed all around the place, which again wouldn't be useful and would leak. It is mostly used for .getContentResolver and to acquire the Glide singleton via Glide.get(context) in those other classes.

我以为会是com.MyFragment ...

I assumed it will be something like com.MyFragment...

您要查找的内容可以在RequestManager的以下字段中找到:

What you're looking for can be found in the following fields of RequestManager:

private final Lifecycle lifecycle;
private final RequestManagerTreeNode treeNode;
private final RequestTracker requestTracker;

查看所有这些类型的子类/实现.还要检查Context.mActivityLifecycleCallbacks我认为这些是相同的对象.

See all child classes / implementations of those types. Also check the Context.mActivityLifecycleCallbacks I think those are the same objects.

是否有一种简单的方法来检查滑行是否遵循片段的生命周期?

Is there a simple way to check if glide is following my fragments' lifecycles?

您可以在上述类中放置断点,和/或检查是否通过堆转储释放了资源(由于缓存,最后一个可能很棘手).如果您想了解更多信息,可以尝试按照Wiki上的说明启用日志记录:调试和错误处理Wiki ,还编写了自己的监听器/目标记录器,就像我在

You can put breakpoints in the above mentioned classes, and/or check if the resources are freed via a heap dump (this last one may be tricky because of caching). If you want more insight you can try enabling logging as said on the Wiki: Debugging and Error Handling wiki and also write your own loggers for listener/target, like I did in glide-support/...utils.

这篇关于与片段上下文滑行的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆