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