的情况是这样的: 我有具有一个工具栏的活动,一个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.
我感觉RAM的使用情况是完全正常的,因为你也在下载图片。 – Nabin
有时候价值会上升到120或130 MB,但我想我终于可以解决它了。看来问题出在drawable上,它们太大了。我将继续分析以提供最终解决方案。 –