Question

情况是这样的：我有一个Activity，它有一个工具栏，一个Tablayout和一个View Pager（包含5个片段）

在第一个片段中，我有一个布局，将包含一个默认片段，其中包含两列的Recycler View 。其中的每个元素都有一个从Internet下载的图像（使用Glide并保存在缓存中），当用户点击持有者（列表中的一个元素）时，将在＆＃39;布局容器中更改此默认片段＆＃39 ;另一个将使用Glide从互联网上下载图像的新的Recycler View。与Instagram搜索页面类似。

我认为Glide是问题所在，但我对所有代码进行了修改，当我在模拟器上运行应用程序时，它会消耗89 MB的RAM。

额外信息

任何片段内RView上的每个元素都是通过使用Volley下载JSONArray创建的，我将请求放在MySingleton队列中并将上下文定义为getContext（）（我应该使用getActivity（）。ApplicationContext（）而不是getContext（）当代码来自片段？）

（位于活动内部的视图寻呼机内的片段内）

MySingleton.getInstance(getContext()).addToRequestQueue(req);

然后它下载图片网址并使用Glide在视图上充电。

if(holder.publication.getPicture() != null ){
        Glide.with(holder.ctx).load(holder.publication.getPicture()).diskCacheStrategy(DiskCacheStrategy.ALL).centerCrop().into(holder.picture_imgView);
    }

我没有使用静态变量
此外，我从Recycler View元素中移除了所有动画，但仍然很慢。
我使用Android监视器和“跳跃Java堆”＃39;选项，看看它是如何管理内存的，主要数字是Byte []（我不明白使用这个工具）

非常感谢！

更新在我的日志中，我总是得到这个：

W/ViewRootImpl: Dropping event due to no window focus: KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0xc8, repeatCount=1, eventTime=18009881, downTime=18009352, deviceId=-1, source=0x101 }

I/Choreographer: Skipped 98 frames!  The application may be doing too much work on its main thread.

Answer 1

嗯，我想我找到了解决方案，并且我已经完成了这些事情：

使用.jpg格式的drawable或任何大于150kb的文件都将使用内存。在我的情况下，我使用非常大的图像作为背景和回收者视图上的小图像，但大于200kb。那些杀了Ram。
最好在调用Volley请求时使用片段的本地上下文（getContext（））并将其放在MySingleton队列中。
recyclerViews上的持有者应该是静态内部类，因为你将重新使用它们，这是节省内存的好方法。
如果你在每个Holder上使用Glide下载图片，并且有一些链接为空，你应该清理ImageView：Glide.clear(ImgView);
创建用于调用SharedPreferences的对象不是一个好主意。最好使用一个全局类，它使用一个上下文（包含所有片段的活动）并从那里调用SharedPreferences。类似于：MyCallerClass.getInstance().getPrefsDataOfOuser();

所有这些都是我最近得出的结论......现在我的应用程序使用50mb的内存下载带滑动的图像和80mb或90mb的实时搜索......

为什么我的Android应用程序消耗了太多内存？

1 个答案: