Частый VMDebug.startGC() при создании bitmap?

Question

[Vladimir Abramov]

Мое приложение активно создает Bitmap из bytearray или встроенных ресурсов.

После тестов на разных девайсах обнаружил что производительность в разы различается на Lenovo IconTab и Samsung sgs3 или Tab 10.1


После запуска профилировщика с удивлением обнаружил что время вызова Bitmap.nativeCreate() различается в разы если на леново оно он находися глубоко внизу то на самсунгах на 3 месте. Более того 97% процессорного времени внутри него занимает VMDebug.startGC() которому в теории полагается быть фейковым. На леново я этого метода не вижу.


Пробовал запускать из Android Studio в дебаг и обычном режиме. Делал релизные сборки и заливал их руками. Все равно производительность одинаково ужасная.


Есть идеи куда тут можно копать и что смотреть?

Comments

[Evgenij_Popovich]

Быть может у Вас слишком много ресурсоемких изображений находятся в памяти одновременно? Или, быть может, Вы используете не оптимальные опции для декодирования изображений? Какой объем съеденной памяти показывает DDMS?

[Vladimir Abramov]

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Button button = (Button) findViewById(R.id.button);

        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                new AsyncTask<Integer, Integer, Integer>() {
                    @Override
                    protected Integer doInBackground(Integer... params) {
                        for(int i=1; i< 100;i++); {
                            Bitmap bmp = BitmapFactory.decodeResource(getResources(), R.drawable.image);
                        }

                        return 0;
                    }
                }.execute(1);
            }
        });
    }

Lenovo icontab 4.1.1



SGS3 4.1.2


SGS4 4.2.2


Как то странно похоже в самсунгах андрид собран

Answer 1

[Evgenij_Popovich]

1. Зачем декодировать сразу все 100 картинок и держать их в памяти, а не по мере появления их на экране?
2. Используйте опции декодирования, чтобы картинки не резервировали память на долго

final BitmapFactory.Options options = new BitmapFactory.Options();
 
// Decode bitmap with inSampleSize set
options.inJustDecodeBounds = false;
 
// #302 added to reduce amount of OutOfMemory errors
options.inDither = false; // Disable Dithering mode
options.inPurgeable = true; // Tell to gc that whether it needs
                            // free memory, the Bitmap can be
                            // cleared
options.inInputShareable = true; // Which kind of reference will
                                 // be used to recover the Bitmap
                                 // data after being clear, when
                                 // it will be used in the future
options.inTempStorage = new byte[32 * 1024];

3. Потребляемую память можно посмотреть на вкладке Heap view. На Ваших скринах этого не видно

Comments

[Vladimir Abramov]

Ну 100 картинок я гружу чисто для примера — чтобы выделить проблемное место. С памятью я проблем не испытываю.
А испытываю проблему со скоростью декодирования на некоторых устройствах. Это тайловый картографический движек.

[Evgenij_Popovich]

Я могу только предполагать, поскольку скриншотов с потреблением памяти Вы не выложили. Но если память заканчивается, то вполне закономерно что вызывается сборщик мусора, перед тем, как декодировать новое изображение.

[Evgenij_Popovich]

И еще, используйте LruCache для хранения изображений, он автоматически подчищается по мере достижения заданного лимита.

Answer 2

[Evgenij_Popovich]

промазал