Я предполагаю, что вы читаете эту страницу: https://developer.android.com/training/articles/perf-tips
Идея, стоящая за тем, что они говорят, заключается в том, что каждый экземпляр объекта требует небольшого объема памяти.Следовательно, один массив из множества Tuple объектов, каждый из которых содержит один Foo и один Bar, будет содержать больше служебных данных, чем два массива (один из Foo объектов и один из Bar объектов).
Это увеличение потребления памяти может привести к более частому запуску сборщика мусора, и каждое действие по сбору мусора будет приостанавливать работу вашего приложения (хотя оно будет приостанавливать его только на крошечные доли секунды).
Однако имейте в виду, что эта статья очень старая.Вы можете получить представление о том, сколько ему лет, по этой строке (выделено мое):
Параллельный сборщик мусора, представленный в Android 2.3 , помогает
Эти соображения производительности имели большее значение , когда аппаратное обеспечение Android было слабым и медленным.Теперь, когда мы работаем над аппаратными средствами, которые на несколько порядков мощнее, практическое влияние таких вещей значительно уменьшилось.
В общем, я бы очень рекомендовал против , взяв эту статьюсовет.Один массив из Tuple объектов на намного проще рассуждать и значительно упростит поддержку вашего приложения в долгосрочной перспективе.Если вы не провели конкретное и явное измерение производительности и не обнаружили вне тени сомнения, что ваше приложение слишком часто собирает мусор, просто игнорируйте эти «советы».
На самом деле, даже эта статья говорит вам, что вы должнывероятно, игнорируйте его, если вы не знаете у вас есть проблема:
Выбор правильных алгоритмов и структур данных всегда должен быть вашим приоритетом
и
Всегда измеряйте
Перед началом оптимизации убедитесь, что у вас есть проблема, которую вам необходимо решить.Убедитесь, что вы можете точно измерить существующую производительность, иначе вы не сможете оценить выгоду от альтернатив, которые вы пробуете.