Andrew Nodermann

Первый метод с использованием Intent отлично подходит, оптимизировать тут нечего, параметры парсятся за микросекунды.

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

Если хотите доделать игру и не забросить, детали такие как одежда оставьте на последнюю очередь. Когда вам покажется что игра завершена на 90%, на самом деле это будет 10%, значит можно выпускать, и остальное доделывать в процессе, оптимизации оставьте на последующие версии игры.

К примеру мы знаем что палка будет в рюкзаке, либо валяется на земле и их может быть сколько угодно.
Если игра трехмерная, то пусть для простоты координаты палки будут выглядеть как список из 3х точек XYZ

Каждая точка в зависимости от точности, занимает разное кол-во памяти:
float это 4 байта, для double 8 байт

Возьмем к примеру меньшую точность float, чтобы сэкономить память, тогда координаты одной палки займут:
XYZ *4 байта = 12 байт

У палки есть id, пусть он будет integer 2 байта от 0 до 65536 (256 byte * 256 byte) т.е. разновидностей предметов в игре у вас будет максимум 65536, это не мало.

Дано 100000 игроков
Размер рюкзака 0-255 (максимум 256 предметов)
Рюкзак это список предметов с их id, к примеру:
id 1 = палка
id 390 = лопата
id 27 = яблоко
будет выглядеть как: [1, 390, 27]

Если все палки лежат у игроков:
100000 * 256 * 2 байта (id палки) = чуть более 50 мегабайт

Если все палки лежат на земле:
100000 * 256 * 2 байта (id палки) * 12 байт (XYZ) = чуть более 600 мегабайт

Можно сделать хак и описать координаты палок как квадраты на местности, к примеру у вас есть карта:
16 * 16 километров = 256 км² (1000000 м²) каждый квадрат = 1 км²
1000000 / 256 = каждый квадрат 62.5 x 62.5 метров
/ 256 = каждый квадрат 3.9 x 3.9 метра, как туалет в макдоналдс
/ 256 = 20 x 20 см

В итоге чтобы запомнить в каком квадрате лежит палка мы уложились в 4 байта [255,255,255,255].
id первого квадрата = [0,0,0,0]
id последнего квадрата [255,255,255,255]
Расположить ее на оси Z, чтобы не хранить высоту уже дело техники.

Теперь если все игроки выкинут свои палки на землю, то это займет:
100000 * 256 * 2 байта (id палки) * 4 байта (квадрат) ~ 205 мегабайт, если все держать в памяти, то с этим справится любой сервер за $5.

Любые вопросы в комменты.

Проблема ООП это неочевидное поведение, пока не развернешь всю лапшу и унаследованные классы, не поймешь что и как работает, начтите с функции onStart

Этот кусок обновит какие-то данные о пользователе в приложении в двух неочевидных случаях:
1. если он уже зарегистрирован, то покажет к примеру его профиль
2. если не зарегистрирован, то тоже что-то обновит, но неизвестно что, к примеру ничего

FirebaseUser currentUser = mAuth.getCurrentUser();
updateUI(currentUser);

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

if (mVerificationInProgress && validatePhoneNumber()) {
    startPhoneNumberVerification(phone);
}

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

Log.d(TAG, "signInWithCredential:success");
FirebaseUser user = task.getResult().getUser();
// [START_EXCLUDE]
updateUI(STATE_SIGNIN_SUCCESS, user);
// [END_EXCLUDE]