2015-10-26 3 views
-2

Я знаю, что это общий вопрос, но я не нашел подходящего ответа на мою проблему в других потоках.Ошибка памяти при использовании растрового изображения

Я использую растровые изображения в своем приложении для отображения фотографий профиля пользователей.
Кроме того, приложение похоже на Instagram, поэтому есть страница, в которой отображаются изображения из базы данных.
Проблема заключается в том, что я перенаправляю между действиями, часто получаю - «к сожалению приложение остановилось».

В журнале я обнаружил ошибку «из памяти».
Я думаю, это потому, что я должен очистить память, переработав растровые изображения.

Я не знаю, почему это не работает.
Пожалуйста, помогите мне, как использовать растровые изображения таким образом, чтобы не создавать ошибок.

Вот часть страницы, где я печатаю растровые изображения. У меня есть строки в базе данных.
Я использую while и запускаю все строки.
Я создаю новые ImageViews, TextViews, и я печатаю их все, как это делает Instagram.

Здесь вы видите, как я напечатать изображение каждой строки:

ImageView v = new ImageView(this); 
b2 = BitmapFactory.decodeByteArray(res4.getBlob(1), 0, res4.getBlob(1).length); 
v.setImageBitmap(b2); 
v.setId(count + 1); 
p = new RelativeLayout.LayoutParams(RelativeLayout.LayoutParams.WRAP_CONTENT, RelativeLayout.LayoutParams.WRAP_CONTENT); 
p.addRule(RelativeLayout.ALIGN_PARENT_RIGHT); 
p.width = width; 
p.setMargins(0, 0, 0, 20); 
p.addRule(RelativeLayout.BELOW, count); 
rl.addView(v, p); 

, где я должен переработать растровое изображение? Это решение? здесь является частью журнала, который показывает «ошибка ООМ»:

10-05 18:53:31.184 16093-16093/com.example.user.instamath2 W/CursorWindow﹕ Window is full: requested allocation 1423987 bytes, free space 1241748 bytes, window size 2097152 bytes 
10-05 18:53:31.201 16093-16093/com.example.user.instamath2 D/dalvikvm﹕ between the previous GC alloc 4461K 
10-05 18:53:31.227 16093-16093/com.example.user.instamath2 I/dalvikvm-heap﹕ Clamp target GC heap from 132.368MB to 128.000MB 
10-05 18:53:31.227 16093-16093/com.example.user.instamath2 D/dalvikvm﹕ GC_FOR_ALLOC freed 1229K (1749), 3% free 126908K/130816K, paused 25ms, total 25ms 
10-05 18:53:31.227 16093-16093/com.example.user.instamath2 I/dalvikvm-heap﹕ Forcing collection of SoftReferences for 3149840-byte allocation 
10-05 18:53:31.227 16093-16093/com.example.user.instamath2 D/dalvikvm﹕ between the previous GC alloc 0K 
10-05 18:53:31.257 16093-16093/com.example.user.instamath2 I/dalvikvm-heap﹕ Clamp target GC heap from 132.360MB to 128.000MB 
10-05 18:53:31.257 16093-16093/com.example.user.instamath2 D/dalvikvm﹕ GC_BEFORE_OOM freed 9K (44), 3% free 126899K/130816K, paused 31ms, total 31ms 
10-05 18:53:31.257 16093-16093/com.example.user.instamath2 E/dalvikvm-heap﹕ Out of memory on a 3149840-byte allocation. 
10-05 18:53:31.258 16093-16093/com.example.user.instamath2 I/dalvikvm﹕ "main" prio=5 tid=1 RUNNABLE 
10-05 18:53:31.258 16093-16093/com.example.user.instamath2 I/dalvikvm﹕ | group="main" sCount=0 dsCount=0 obj=0x41d00de0 self=0x41cee638 
10-05 18:53:31.258 16093-16093/com.example.user.instamath2 I/dalvikvm﹕ | sysTid=16093 nice=0 sched=0/0 cgrp=default handle=1074549128 
10-05 18:53:31.258 16093-16093/com.example.user.instamath2 I/dalvikvm﹕ | state=R schedstat=(2032092377 14250700 588) utm=164 stm=39 core=2 
10-05 18:53:31.258 16093-16093/com.example.user.instamath2 I/dalvikvm﹕ at android.graphics.BitmapFactory.nativeDecodeByteArray(Native Method) 
10-05 18:53:31.258 16093-16093/com.example.user.instamath2 I/dalvikvm﹕ at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:529) 
+0

Я верю Это потому, что ваш res4 является слишком большим, чтобы выделить, проверить эту страницу http://developer.android.com/training/displaying-bitmaps/load-bitmap.html может помочь;) – iGoDa

+0

HTTP://developer.android.com/training/displaying-bitmaps/load-bitmap.html – thumbmunkeys

+1

Вы пытались найти существующий ответ, прежде чем публиковать этот вопрос? есть много ранее существовавших вопросов, которые затрагивают эту проблему, и многие сайты (включая официальные сайты android), которые также затрагивают это. –

ответ

1

Так, по документации, recycle() не нужно назвать нормально, потому что, если ваша ссылка выходит из области видимости виртуальная машина будет перерабатывать его в любом случае ,

Освободите родной объект, связанный с этим растровым изображением, и очистите ссылку на данные пикселя. Это не освобождает данные пикселя синхронно; он просто позволяет собирать мусор, если нет других ссылок. Растровое изображение отмечено как «мертвое», что означает, что оно выдает исключение, если вызывается getPixels() или setPixels(), и ничего не рисует. Эта операция не может быть отменена, поэтому ее следует вызывать, только если вы уверены, что для растрового изображения больше не используются. Это расширенный вызов и, как правило, не нужно вызывать, так как обычный процесс GC освободит эту память, если больше нет ссылок на это растровое изображение.

Но в фрагменте кода вы поделились с нами, что неясно, если b2 когда-либо выходит из области видимости, поэтому JVM, вероятно, никогда не мусор собирает его. Где в жизненном цикле действия вы выделяете растровое изображение? Что вы делаете с b2?

Если вы хотите явно переработать растровое изображение, я бы сделал это как часть события lifecycle stop() или destroy(). Просто убедитесь, что вы выделяете соответствующее событие жизненного цикла (то есть start() или create() соответственно).

+0

Вероятно, он просто остается в памяти и медленно протекает, а WeakReference должен помочь определить проблему – Shark

+1

или загруженное растровое изображение слишком велико или в памяти уже много растровых изображений. эта проблема была рассмотрена много раз здесь в SO, и общий подход заключается в том, чтобы знать, как использовать растровые изображения в android. это включает выборку размера растрового изображения с параметрами, а затем с использованием размера выборки при загрузке. –

 Смежные вопросы

  • Нет связанных вопросов^_^