много экземпляров объектов проблема в Android? - PullRequest
Новая
       10

много экземпляров объектов проблема в Android?

0 голосов
/ 15 февраля 2011

Я планирую создать представление 2D (топографической) карты в Android (3.0) следующим образом

  • класс MapCoordinate, который является просто «структурой» и состоит изоткрытые атрибуты x, y типа int и представляют MapCoordinate
  • класс MapPoint (вероятно, не очень хорошее имя), который инкапсулирует методы для доступа и изменения данных точки на карте (для одной координаты карты))

  • класс Map, который имеет один экземпляр / карту (в моем приложении только один) и инкапсулирует карту, имея HashMap: 

    public class Map {
    HashMap<MapCoordinate, MapPoint> mapPoint = new HashMap<MapCoordinate, MapPoint>();
}

Итак, мой вопрос будет следующим: является ли критичным к производительности наличие множества (Java) экземпляров объектов на Android (целью моего приложения являются только планшетные ПК).Конечно, эта карта - лишь маленький фрагмент всего моего приложения.Карта может быть довольно большой.

Спасибо за ваш отзыв.

1 Ответ

2 голосов
/ 15 февраля 2011

Вы можете попытаться реализовать шаблон Fly Weight , если это возможно.Официальная документация рекомендует избегать создания объектов:

Избегать создания объектов

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

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

Таким образом, вам следует избегать создания экземпляров объектов, которые вам не нужны.Некоторые примеры вещей, которые могут помочь:

  • При извлечении строк из набора входных данных попробуйте вернуть подстроку исходных данных вместо создания копии.Вы создадите новый объект String, но он поделится char [] с данными.
  • Если у вас есть метод, возвращающий строку, и вы знаете, что его результат всегда будет добавлен в StringBuffer в любом случае,измените сигнатуру и реализацию так, чтобы функция добавлялась напрямую, вместо создания кратковременного временного объекта.

Несколько более радикальная идея состоит в том, чтобы разделить многомерные массивы на параллельные одно одномерныемассивы:

  • Массив целых чисел намного лучше, чем массив целых чисел, но это также обобщает тот факт, что два параллельных массива целых чисел также намного более эффективны, чем массив (int, int) объекты.То же самое касается любой комбинации примитивных типов.
  • Если вам нужно реализовать контейнер, в котором хранятся кортежи объектов (Foo, Bar), постарайтесь запомнить, что два параллельных массива Foo [] и Bar [] обычно являютсянамного лучше, чем отдельный массив пользовательских (Foo, Bar) объектов.(Исключением из этого, конечно, является ситуация, когда вы разрабатываете API для доступа к другому коду; в этих случаях обычно лучше поменять правильный дизайн API на небольшой удар по скорости. Но в вашем собственном внутреннем коде выдолжен стараться быть максимально эффективным.)

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

...