的情況是這樣的: 我有具有一個工具欄的活動,一個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上,它們太大了。我將繼續分析以提供最終解決方案。 –