WallpaperService Изображение Рисование Производительность - PullRequest
0 голосов
/ 29 октября 2018

Я работаю над livewallpaper для Android. Код работает, но у меня проблемы с производительностью. В основном я рисую растровые изображения и перемещаю их. С 15 маленькими изображениями все работает нормально. Но с 50 большими изображениями оно начинает отставать.

В моем движущемся объекте я создаю растровое изображение в конструкторе и отображаю его так:

public void drawFrame(Canvas canvas) {
    Position p = movingStrategy.move();
    Matrix matrix = new Matrix();
    matrix.postScale(scale, scale);
    matrix.postRotate(p.getRotation());
    matrix.postTranslate(p.getPositionX(), p.getPositionY());
    canvas.drawBitmap(bitmap, matrix, paint);
}

И в моей службе обоев я вызываю onDraw следующим образом:

 private void draw() {
        handler.removeCallbacks(drawRunner);
        SurfaceHolder holder = getSurfaceHolder();
        Canvas canvas = null;
        try {
            canvas = holder.lockCanvas();
            if (canvas != null) {
                canvas.save();
                canvas.drawColor(Color.BLACK);
                for (DrawElement element : elements) {
                    element.drawFrame(canvas);
                }
                canvas.restore();
            }
        } finally {
            if (canvas != null)
                holder.unlockCanvasAndPost(canvas);
        }
        if (visible) {
            handler.postDelayed(drawRunner, 1);
        }
    }

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

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

Спасибо

Edit:

Я проверил производительность между представлением и сервисом. Эта часть:

  long start = System.currentTimeMillis();
  for (DrawElement element : elements) {
       element.drawFrame(canvas);
  }
  Log.e("DrawingTime", Long.toString(System.currentTimeMillis()-start));

принимает в представлении 0-1 мс и в обслуживании от 50 до 300 мс.

1 Ответ

0 голосов
/ 07 ноября 2018

Производительность действительно зависит от того, насколько велики ваши растровые изображения, как вы их распределяете и связываете, какую конфигурацию растровых изображений вы используете и от какого API вы запускаете ваше приложение.

  1. Имейте в виду, что большие растровые изображения довольно дороги для загрузки процессора и потребляют много оперативной памяти. Попробуйте использовать точный размер по мере необходимости для текущей плотности экрана и разрешения. Избегайте выделения ненужного размера, который не может быть распознан из-за ограничений экрана устройства.
  2. Повторно используйте ваши растровые изображения, если это возможно. Выделение и освобождение памяти для каждого нового растрового изображения - действительно тяжелая операция. Если вы повторно используете свои растровые изображения, вы можете получить безумное увеличение производительности.
  3. Попробуйте использовать как можно более низкую конфигурацию для вашего растрового изображения. Конечно, если это несколько фотографий, необходимо сохранить весь их цветовой диапазон, но даже в этом случае есть некоторые конфиги, которые позволяют вам использовать вдвое меньше памяти при почти не заметной потере качества.
  4. В некоторых ранних версиях Android существует огромный проглм с растровыми изображениями из-за конкретной реализации dalvik. Нет сомнений в том, что на 24+ API ваше приложение может работать лучше. Я не говорю, что вам следует увеличить минимальную поддерживаемую версию SDK, но в любом случае вам, вероятно, следует проверить, как она работает во всем диапазоне поддерживаемых API.

Проверьте эту полезную информацию:

https://developer.android.com/topic/performance/graphics/ https://developer.android.com/topic/performance/graphics/manage-memory https://developer.android.com/topic/performance/graphics/cache-bitmap

...