java.lang.OutOfMemoryError: размер растрового изображения превышает бюджет виртуальной машины - android - на сколько изображений?

Question

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

Вопрос в том, сколько изображений или сколько килобайт в изображениях или сколько макетов / изображений я могу иметь одновременно на экране.

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

Спасибо

Daniel

---

Edit:

Я только что нашел это на сайте разработчика Android (http://developer.android.com/resources/articles/future-proofing.html)

Техника, которую следует избегать, # 3: перебор с макетами

Из-за изменений в инфраструктуре рендеринга View, неоправданно глубоких (более 10 или более) или широких (более 30) иерархий View в макетах теперь могут возникать сбои. Это всегда было риском для чрезмерно сложных макетов, но вы можете думать, что Android 1.5 лучше, чем 1.1, разоблачает эту проблему. Большинству разработчиков не нужно беспокоиться об этом, но если ваше приложение имеет очень сложные макеты, вам нужно будет поставить его на диету. Вы можете упростить макеты, используя более продвинутые классы макетов, такие как FrameLayout и TableLayout.

Полагаю, это может быть моей проблемой.

Когда он говорит «широкий», он говорит на последнем уровне?

Спасибо

Daniel

Answer 1

Одна из самых распространенных ошибок, которые я обнаружил при разработке Android-приложений, -

java.lang.OutOfMemoryError: Bitmap Size Exceeds VM Budget ошибка.

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

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

Сначала установите атрибут id в родительском представлении макета XML:

    <?xml version="1.0" encoding="utf-8"?>
    <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
     android:layout_width="fill_parent"
     android:layout_height="fill_parent"
     android:id="@+id/RootView"
     >
     ...

Затем в методе onDestroy() вашей Activity вызовите метод unbindDrawables (), передав ссылку на родительский View, а затем выполните System.gc ()

    @Override
    protected void onDestroy() {
    super.onDestroy();

    unbindDrawables(findViewById(R.id.RootView));
    System.gc();
    }

    private void unbindDrawables(View view) {
        if (view.getBackground() != null) {
        view.getBackground().setCallback(null);
        }
        if (view instanceof ViewGroup) {
            for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
            unbindDrawables(((ViewGroup) view).getChildAt(i));
            }
        ((ViewGroup) view).removeAllViews();
        }
    }

Этот метод unbindDrawables () рекурсивно исследует дерево представлений и:

• Удаляет обратные вызовы на всех фоновых рисунках
• Удаляет дочерние элементы в каждой группе просмотра

Answer 2

Этот ответ состоит из 2 частей

1) дело не в том, сколько изображений на экране, а в тщательности очистки всего при завершении упражнения

2) (Future-Proofing Your App)

Техника, которую следует избегать, # 3: перебор с макетами

Из-за изменений в инфраструктуре рендеринга View, неоправданно глубоких (более 10 или более) или широких (более 30) иерархий View в макетах теперь могут возникать сбои. Это всегда было риском для чрезмерно сложных макетов, но вы можете думать, что Android 1.5 лучше, чем 1.1, разоблачает эту проблему. Большинству разработчиков не нужно беспокоиться об этом, но если ваше приложение имеет очень сложные макеты, вам нужно будет поставить его на диету. Вы можете упростить макеты, используя более продвинутые классы макетов, такие как FrameLayout и TableLayout.

Daniel

Answer 3

Эта вещь зависит от размера кучи телефона. поэтому, если ваше приложение получит больше кучи, чем телефон, это может создать проблему.

Android-устройства нового поколения содержат. Вот список некоторых

HTC Wildfire (2.2.1) = 16 МБ.
HTC Wildfire S (2.3.5) = 20 МБ.
HTC Salsa (2.3.3) = 20 МБ.
HTC Desire (2.3.3) = 32 МБ.
HTC Desire S (2.3.5) = 32 МБ.
Samsung Galaxy S GT-I9000 (2.2) = 48 МБ.
Samsung Galaxy R GT-I9103 (2.3.5) = 64 МБ.
Samsung Galaxy Y GT-S5360 (2.3.5) = 64 МБ

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

ЕСЛИ вы используете эмулятор, то вы можете создать устройство, которое будет иметь больший размер кучи, чтобы добавить новую дополнительную конфигурацию оборудования в диспетчере AVD при размере кучи виртуальной машины = 32 или выше.

Answer 4

Объем памяти варьируется от устройства к устройству, а количество, с которым вы должны играть, зависит от того, что еще делает система в данный момент. Лучше всего даже не приближаться к запуску системы из памяти, если вы можете ей помочь. Что вы делаете, что вам нужно столько изображений на экране?