1-байтовый тип массива Android Heap очень большой - PullRequest
4 голосов
/ 14 января 2012

Итак, я работаю над игрой в Android, и я проверял кучу и распределение, чтобы увидеть, что-то не так с памятью, а что нет.Когда я попал в кучу, он сказал, что выделил 33 МБ для моей игры, а 31 МБ - для 1-байтовых типов массивов.Я пытался выяснить, почему он был таким большим, но мне не повезло, и я даже не знал, что искать.У кого-нибудь есть какие-либо идеи?Заранее спасибо!Дайте мне знать, если вам нужна дополнительная информация.

Будет

Редактировать:

Я не совсем понял, что происходит, извините, опоздал, когда я опубликовал это.

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

    public void onDraw(Canvas c)
    {
        c.drawColor(Color.BLACK);
        Point[] touchPlacesHolder = touchPlaces;
        for(int i = 0; i < touchPlacesHolder.length; i++)
        {
            c.drawCircle(touchPlacesHolder[i].x, touchPlacesHolder[i].y, 100, paint);
        }
    }

    public boolean onTouchEvent(MotionEvent event){
        touchPlaces = new Point[event.getPointerCount()];
        for (int i = 0; i < event.getPointerCount(); i++) 
        {
            touchPlaces[i] = new Point((int) event.getX(i), (int) event.getY(i));
        }
        return true;
    }

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

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    final Window win = getWindow();
    win.setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); 
    requestWindowFeature(Window.FEATURE_NO_TITLE);
    setContentView(R.layout.main);

    final Button newGame = (Button) findViewById(R.id.new_game_button);
    newGame.setOnClickListener(new OnClickListener() {
        public void onClick(View v) {
            // Perform action on clicks
            Intent intent = new Intent(v.getContext(), Platformer.class);
            startActivity(intent);
        }
    });
    final Button levelEditor = (Button) findViewById(R.id.level_editor);
    levelEditor.setOnClickListener(new OnClickListener() {
        public void onClick(View v) {
            Intent intent = new Intent(v.getContext(), LevelEditor.class);
            startActivity(intent);
        }
    });
}

Как вы можете видеть, к кнопкам прикреплено еще одно действиево втором фрагменте кода, который я показал, но я решил спросить о более простом примере, потому что они оба используют одинаковый объем памяти, даже если один использует растровые изображения, а другой - нет.

Итак, в основном мой вопрос таков: почему для чего-то такого простого, как это, требуется такая большая куча, и почему оно использует так много этого, когда что-то более сложное, например, отрезать веревку, составляет примерно половину размера.Спасибо!

Снова отредактируйте:

Я просто изменил манифест, чтобы начать с самого простого, и оставил главное меню и другое действие вне.Мультитач-тестер использовал около 12 МБ кучи в 13 МБ.Я сделал то же самое для меню, у него было выделено около 25 МБ, и я использовал большую его часть, а другой класс, который я не показывал, также использовал около 25.

Итак, я предполагаю, что из-за этого используется дополнительная память, удерживая меню в памяти, но я не уверен, почему он использует столько памяти для меню.Любая идея, как это исправить или исправить, как он держит его в памяти?

1 Ответ

1 голос
/ 22 апреля 2012

возможных оптимизаций для скорости и памяти:

1. Как насчет использования массива макс. Событий касания фиксированного размера и его обновления вместо создания нового каждый раз? это один поток, который обрабатывает оба, так что не о чем беспокоиться.

2. недействительными только те области, которые должны быть обновлены. это может улучшить скорость.

3. Обновите сенсорные события только до того, как узнаете, что хотите обновить.

4. Не уверен, что это за игра, но вы можете использовать растровое изображение фиксированного размера и записывать в него вместо сохранения сенсорных событий.

5. поскольку это игра, большая часть памяти, вероятно, используется для изображений, звуков и видео. попробуйте проверить, если это проблема. так как классы, которые вы проверили, являются 1-байтовыми массивами, это может быть случай изображений. для получения дополнительной информации о загрузке тяжелых ресурсов, проверьте: http://developer.android.com/training/displaying-bitmaps/index.html

большой размер кучи может указывать на то, что вы создаете много маленьких объектов или несколько больших объектов за короткое время, поскольку gc требуется некоторое время, чтобы что-то сделать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...