Нет. Вы бы попали в ловушку преждевременной оптимизации .
Используйте обычные String объекты для хранения имени и тому подобное.
Если бы вы сами управляли текстом, вам нужно было бы узнать, что тип char устарел и может содержать менее половины из 137 000 символов, определенных Unicode. Таким образом, вам нужно будет научиться обрабатывать массив символов как UTF-16 , используя квадратные октеты вместо двойных октетов при представлении символов вне базовой плоскости 1016 * Диапазон символов. Таким образом, вы узнаете, как распознавать верхние и нижние значения суррогаты как отображение на другие кодовые точки. И даже если вам все это удастся, ваши char массивы не выиграют от таких инноваций, как JEP 254: компактные строки и JEP 280: Укажите последовательность строк , как обсуждалось в этой презентации .
Урок для изучения здесь: Не пытайтесь перехитрить команду Java и JVM , не будучи очень осведомленными о технических деталях и , имеющих доказанную потребность настолько серьезный, что требует такого вмешательства. Ваше приложение лучше всего обслуживается написанием простого кода с использованием очевидных классов и предоставлением компилятору и JVM возможности оптимизировать работу.
Современные реализации JVM оптимизированы на . Вам не нужно беспокоиться о бремени создания объектов, кроме как в самых экстремальных условиях.
И даже в этом случае вам нужно доказать и диагностировать проблему с помощью инструментов профилирования и отладки, прежде чем искать решение. Доказано, что даже самые яркие программисты плохо умеют предотвращать / решать предполагаемые проблемы с производительностью.
Кроме того, вы отметили свой вопрос как Android. У вас есть только один пользователь в приложении для Android, а не миллион. Если вы имели в виду кодирование на стороне сервера, когда вы получите миллион пользователей, у вас возникнут проблемы с длинным списком, которые могут вас беспокоить. String против char[] для имени пользователя не будет высоким в этом списке.