2

的情况是这样的: 我有具有一个工具栏的活动,一个Tablayout和一个查看寻呼机(将含有5个片段)为什么我的android应用程序消耗太多内存?

第一片段我有一个布局意愿包含一个默认片段在其内部将有一个包含两列的Recycler View。其中的每一个元素都有一个从互联网上下载的图像(使用Glide并保存在缓存中),当用户点击持有者(列表的一个元素)时,会将'布局容器'中的默认片段更改为另一个将有一个新的Recycler View,并使用Glide从互联网上下载图像。类似于Instagram搜索页面。

我以为滑翔是问题,但我嘲笑所有代码,当我在模拟器上运行应用程序时,它会消耗更多或更少的89 MB RAM。

附加信息

  • 从使用排球在下载JSONArray上创建任何片段内的RView每个元素,我把请求MySingleton队列内,并定义上下文的getContext()(I应该使用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); 
    } 
  • 我不使用静态变量

  • 而且,我从回收站视图元素删除所有动画和仍然缓慢。

  • 我使用Android显示器和“跳转Java堆”选项来看看它是如何管理内存和主号码的字节[]

(我不使用这个工具理解)

非常感谢!

UPDATE 在我的日志,我总是得到这样的:

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. 
+0

我感觉RAM的使用情况是完全正常的,因为你也在下载图片。 – Nabin

+0

有时候价值会上升到120或130 MB,但我想我终于可以解决它了。看来问题出在drawable上,它们太大了。我将继续分析以提供最终解决方案。 –

回答

2

嗯,我想我找到了解决方案,我已经得出结论,这些东西:

  • 使用上可绘制.JPG格式或大于150kb的任何文件将使用内存。在我的情况下,我使用非常大的图像作为背景和回收器视图上的小图像,但大于200kb。那些杀害Ram。
  • 当调用Volley请求并将其放在MySingleton队列上时,最好使用片段的本地上下文(getContext())。
  • recyclerViews上的持有者应该是静态内部类,因为您要重新使用它们,这是保存内存的好方法。
  • 如果您在每个固定器上使用Glide下载图像,并且有一些链接为空,则应清洁ImageView:创建用于调用SharedPreferences的对象不是一个好主意。最好使用一个全局类,它使用一个上下文(包含所有片段的活动)并从那里调用SharedPreferences。是这样的:MyCallerClass.getInstance().getPrefsDataOfOuser();

所有这些都是我的结论,我得到了这些天......现在我的应用程序使用的内存与下载滑行和80MB或90MB最大的实时图片搜索50MB ...

+0

我有类似的问题,但我不使用任何大图像作为背景。我想你的解决方案最大的部分是关于使用较小的图像,其他建议有多大帮助? – Tony