Сбой OutOfMemoryError
java.lang.OutOfMemoryError: Failed to allocate a 12960012 byte allocation with 5594672 free bytes and 5MB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.ja va:609)
at android.graphics.BitmapFactory.decodeResourceStream(BitmapFa ctory.java:444)
at android.graphics.drawable.Drawable.createFromResourceStream( Drawable.java:989)
at android.content.res.Resources.loadDrawableForCookie(Resource s.java:2643)
at android.content.res.Resources.loadDrawable(Resources.java:25 25)
at android.content.res.Resources.getDrawable(Resources.java:799 )
at android.content.Context.getDrawable(Context.java:406)
at android.widget.ImageView.resolveUri(ImageView.java:741)
at android.widget.ImageView.setImageResource(ImageView.java:397 )
at spsoft.passwordgenerator.Adapter.getView(Adapter.java:79)
at android.widget.AbsListView.obtainView(AbsListView.java:2344)
at android.widget.ListView.makeAndAddView(ListView.java:1864)
at android.widget.ListView.fillDown(ListView.java:698)
at android.widget.ListView.fillFromTop(ListView.java:759)
at android.widget.ListView.layoutChildren(ListView.java:1673)
at android.widget.AbsListView.onLayout(AbsListView.java:2148)
at android.view.View.layout(View.java:15686)
at android.view.ViewGroup.layout(ViewGroup.java:4967)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:5 73)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15686)
at android.view.ViewGroup.layout(ViewGroup.java:4967)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java: 1703)
at android.widget.LinearLayout.layoutVertical(LinearLayout.java :1557)
at android.widget.LinearLayout.onLayout(LinearLayout.java:1466)
at android.view.View.layout(View.java:15686)
at android.view.ViewGroup.layout(ViewGroup.java:4967)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:5 73)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15686)
at android.view.ViewGroup.layout(ViewGroup.java:4967)
at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:20 97)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.jav a:1854)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1067 )
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl .java:5814)
at android.view.Choreographer$CallbackRecord.run(Choreographer. java:767)
at android.view.Choreographer.doCallbacks(Choreographer.java:58 0)
at android.view.Choreographer.doFrame(Choreographer.java:550)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Cho reographer.java:753)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:211)
at android.app.ActivityThread.main(ActivityThread.java:5335)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(Z ygoteInit.java:1016)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:811)
Вот такой пришел сбой, как с ним бороться.
OutOfMemoryError
Приложение выдаёт такой лог, и перестаёт показывать изображения. Throwing OutOfMemoryError.
OutOfMemoryError
Всем привет. Ошибка заключается в следующем: protected void onCreate(Bundle.
Источник
Как решить проблему java.lang.OutOfMemoryError в Android
Хотя у меня очень маленькое изображение в папке с возможностью рисования, я получаю эту ошибку от пользователей. И я не использую функцию bitmap в коде. По крайней мере намеренно 🙂
В соответствии с этим stackTrace я получаю эту ошибку на этой строке («tv» – это textView):
В чем проблема? Если вам нужна другая информация о коде, я могу добавить ее. Благодаря!
Вы не можете увеличить размер кучи динамически, но вы можете попросить использовать больше с помощью.
В manifest.xml вы можете добавить в свой манифест эти строки, которые он работает для некоторых ситуаций.
Должны ли быть созданы процессы вашего приложения с большой кучей Dalvik. Это относится ко всем процессам, созданным для приложения. Он применяется только к первому приложению, загружаемому в процесс; Если вы используете общий идентификатор пользователя, чтобы позволить нескольким приложениям использовать процесс, все они должны использовать этот параметр последовательно или у них будут непредсказуемые результаты. Большинство приложений не должны этого нуждаться и вместо этого должны сосредоточиться на сокращении общего использования памяти для повышения производительности. Включение этого также не гарантирует фиксированного увеличения доступной памяти, поскольку некоторые устройства ограничены их общей доступной памятью.
Чтобы запросить доступный размер памяти во время выполнения, используйте методы getMemoryClass() или getLargeMemoryClass() .
Если все еще стоит проблема, тогда это также должно работать
Если установлено значение> 1, запрашивает декодер для подвыборки исходного изображения, возвращая меньшее изображение для сохранения памяти.
Это оптимальное использование BitmapFactory.Options.inSampleSize относительно скорости отображения изображения. В документации упоминаются значения, которые имеют мощность 2, поэтому я работаю с 2, 4, 8, 16 и т. Д.
Давайте углубимся в Image Sampling:
Например, не стоит загружать изображение с разрешением 1024×768 пикселей в память, если в конечном итоге оно будет отображаться в миниатюре размером 128×128 пикселей в ImageView .
Чтобы inSampleSize декодер для подвыражения изображения, загрузив меньшую версию в память, установите для inSampleSize значение true в свой объект BitmapFactory.Options . Например, изображение с разрешением 2100 x 1500 пикселей, которое декодируется с помощью параметра inSampleSize 4, создает растровое изображение приблизительно 512×384. Загрузка этого в память использует 0,75 МБ, а не 12 МБ для полного изображения (при условии конфигурации растрового изображения ARGB_8888 ). Ниже приведен метод вычисления значения размера выборки, который представляет собой мощность двух на основе ширины и высоты цели:
Примечание . Значение двух значений рассчитывается, потому что декодер использует конечное значение, округляя до ближайшей мощности в два, согласно документации inSampleSize .
Чтобы использовать этот метод, сначала inJustDecodeBounds декодирование с параметром inJustDecodeBounds установленным в true , передайте параметры и затем снова декодируйте, используя новое значение inJustDecodeBounds а inJustDecodeBounds – false :
Этот метод упрощает загрузку растрового изображения произвольно большого размера в ImageView который отображает миниатюру размером 100×100 пикселей, как показано в следующем примере кода:
Вы можете выполнить аналогичный процесс для декодирования растровых изображений из других источников, заменив соответствующий метод BitmapFactory.decode* мере необходимости.
Я нашел этот код интересным:
Как управлять памятью вашего приложения: ссылка
Не рекомендуется использовать android:largeHeap=»true» Вот выдержка из Google, которая объясняет это,
Однако возможность запросить большую кучу предназначена только для небольшого набора приложений, которые могут оправдать необходимость потреблять больше ОЗУ (например, большое приложение для редактирования фотографий). Никогда не запрашивайте большую кучу просто потому, что у вас закончилась нехватка памяти, и вам нужно быстрое исправление – вы должны использовать ее только тогда, когда вы точно знаете, где находится вся ваша память, и почему ее необходимо сохранить. Тем не менее, даже если вы уверены, что ваше приложение может оправдать большую кучу, вы должны избегать его запроса в любой возможной степени. Использование дополнительной памяти будет в большей степени нарушать общий пользовательский интерфейс, поскольку сбор мусора займет больше времени, а производительность системы может быть медленнее при переключении задач или выполнении других общих операций.
После работы excrutiatingly с out of memory errors я бы сказал, добавив это в манифест, чтобы избежать проблемы с oom, не является грехом
Проверка поведения приложения на Android Runtime (ART)
Время выполнения Android (ART) является средой исполнения по умолчанию для устройств под управлением Android 5.0 (API уровня 21) и выше. Эта среда исполнения предлагает ряд функций, которые повышают производительность и плавность платформы Android и приложений. Вы можете найти более подробную информацию о новых возможностях ART в представлении ART .
Однако некоторые методы, которые работают на Дальвике, не работают на АРТ. Этот документ позволяет вам узнать о том, что нужно посмотреть при переносе существующего приложения для совместимости с АРТ. Большинство приложений должны работать только при работе с АРТ.
Решение проблем сбора мусора (GC)
В Dalvik приложениям часто бывает полезно явно вызвать System.gc (), чтобы вызвать сборку мусора (GC). Это должно быть гораздо менее необходимо для АРТ, особенно если вы вызываете сборку мусора, чтобы предотвратить появление типа GC_FOR_ALLOC или уменьшить фрагментацию. Вы можете проверить, какая среда исполнения используется, вызывая System.getProperty («java.vm.version»). Если АРТ используется, значение свойства «2.0.0» или выше.
Кроме того, в Android Open Source Project (AOSP) разрабатывается компактный сборщик мусора для улучшения управления памятью. Из-за этого вам следует избегать использования методов, несовместимых с уплотнением GC (например, сохранение указателей на данные экземпляра объекта). Это особенно важно для приложений, которые используют интерфейс Java Native Interface (JNI). Дополнительные сведения см. В разделе Предупреждение проблем JNI.
Предотвращение проблем JNI
JNI от ART несколько более строг, чем у Dalvik’s. Особенно полезно использовать режим CheckJNI для обнаружения общих проблем. Если ваше приложение использует код C / C ++, вы должны просмотреть следующую статью:
Кроме того, вы можете использовать встроенную память ( NDK & JNI ), поэтому вы фактически обходите ограничение размера кучи.
Вот несколько сообщений об этом:
Как кэшировать растровые изображения в родной памяти
JNI, чтобы помочь избежать OOM при использовании больших изображений
И вот библиотека, созданная для него:
Вы должны реализовать диспетчер кэша LRU при работе с растровым изображением
Используйте библиотеку уровня, например Universal Image Loader:
Теперь, когда вы работаете с изображениями и большую часть времени с помощью растрового изображения, я использую Glide, который позволяет вам настроить модуль Glide и LRUCache
Я вижу только два варианта:
- У вас есть утечки памяти в приложении.
- У устройств недостаточно памяти при запуске приложения.
Источник
