🤔 Как происходит хранение данных в Android?

Данные хранятся в SharedPreferences, SQLite/Room, файлах, в базе данных на сервере, а также в DataStore, EncryptedSharedPreferences и KeyStore — в зависимости от нужной степени надёжности и структуры данных.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Через какой класс вызываются методы get, replace?

Методы get и replace в Kotlin относятся к работе с коллекциями, карты (Map) или к строкам. В зависимости от контекста, они вызываются через разные классы. Давайте разберем каждый случай отдельно.

🟠Методы `get` и `replace` для коллекций (`Map`)
В контексте работы с картами (Map), методы get и replace относятся к получению значений по ключу и замене существующих значений.
Метод get
Метод get используется для извлечения значения из карты по указанному ключу.

val map = mapOf("key1" to "value1", "key2" to "value2")
println(map.get("key1")) // value1
println(map["key2"])     // value2 (альтернатива `get`)

Метод replace используется для обновления значения, связанного с определённым ключом, если он существует. Этот метод доступен только для изменяемых карт (MutableMap).

val mutableMap = mutableMapOf("key1" to "value1", "key2" to "value2")
mutableMap.replace("key1", "newValue1")
println(mutableMap) // {key1=newValue1, key2=value2}

🟠Методы `get` и `replace` для строк
В контексте строк, методы get и replace работают с символами и подстроками.
Метод get используется для доступа к символу строки по индексу. Это альтернатива квадратным скобкам.

val text = "Kotlin"
println(text.get(0))  // K
println(text[1])      // o (альтернатива `get`)

Метод replace заменяет символы или подстроки в строке на заданные.

val text = "Kotlin is awesome"
val newText = text.replace("awesome", "powerful")
println(newText) // Kotlin is powerful

🟠Глобальные методы `get` и `replace` через пользовательские классы
Если вы пишете свои классы, вы можете переопределить оператор get и метод replace, чтобы использовать их для своих нужд.

class CustomList<T>(private val items: List<T>) {
    operator fun get(index: Int): T {
        return items[index]
    }
}

fun main() {
    val customList = CustomList(listOf(1, 2, 3))
    println(customList[0]) // 1
}

Пример с replace

class CustomMap<K, V>(private val map: MutableMap<K, V>) {
    fun replace(key: K, value: V) {
        if (map.containsKey(key)) {
            map[key] = value
        }
    }
}

fun main() {
    val customMap = CustomMap(mutableMapOf("key1" to "value1"))
    customMap.replace("key1", "newValue1")
    println(customMap) // {key1=newValue1}
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое UI thread и Worker thread?

1. UI thread:
- Основной поток приложения, где выполняются все операции с пользовательским интерфейсом.
- Долгие операции здесь могут привести к замораживанию приложения.
2. Worker thread:
- Фоновые потоки для выполнения долгих задач (например, обработки данных, запросов в сеть).
- Обновление UI из фонового потока невозможно.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В андроиде существуют мэпы, в которые можно положить примитивные типы?

Да! В Android есть специальные Map-коллекции, которые позволяют хранить примитивные типы (int, long, boolean и т. д.) без автоупаковки (autoboxing).

🚩Почему это важно?

Обычные HashMap<Int, Int> в Kotlin используют автоупаковку (Integer вместо int), что:
Увеличивает потребление памяти (из-за объектов Integer, Long и т. д.).
Замедляет работу (из-за ненужного создания объектов).

Решение? Использовать специализированные мэпы из android.util!

🚩`SparseArray` (замена `HashMap<Int, Any?>`)

Хранит пары Int → Any, но без автоупаковки.

import android.util.SparseArray

val sparseArray = SparseArray<String>()
sparseArray.put(1, "Привет")
sparseArray.put(2, "Мир")

println(sparseArray[1]) // Привет
println(sparseArray[2]) // Мир

🚩`SparseIntArray` (замена `HashMap<Int, Int>`)

Хранит пары Int → Int без автоупаковки.

import android.util.SparseIntArray

val sparseIntArray = SparseIntArray()
sparseIntArray.put(1, 100)
sparseIntArray.put(2, 200)

println(sparseIntArray[1]) // 100
println(sparseIntArray[2]) // 200

🚩`SparseBooleanArray` (замена `HashMap<Int, Boolean>`)

Оптимизирован для Int → Boolean пар.

import android.util.SparseBooleanArray

val sparseBooleanArray = SparseBooleanArray()
sparseBooleanArray.put(1, true)
sparseBooleanArray.put(2, false)

println(sparseBooleanArray[1]) // true
println(sparseBooleanArray[2]) // false

🚩`LongSparseArray<T>` (замена `HashMap<Long, T>`)

Оптимизирован для Long → Any?, аналог SparseArray, но с Long ключами.

import android.util.LongSparseArray

val longSparseArray = LongSparseArray<String>()
longSparseArray.put(10000000000L, "Длинный ключ")

println(longSparseArray[10000000000L]) // Длинный ключ

Ставь 👍 и забирай 📚 Базу знаний

🤔 В какой момент генерируется код при использовании SQLite (Room)?

Код генерируется на этапе компиляции, благодаря аннотациям (@Entity, @Dao, @Database).
Room использует аннотационный процессор, который создает вспомогательные классы для доступа к базе, проверяет запросы и формирует безопасный API.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как в Ретрофите добавить возможность возвращать типы Rxjava?

Чтобы Retrofit мог возвращать Observable, Single, Maybe или Flowable из RxJava, нужно добавить RxJava Adapter.

🚩Добавление зависимости

В build.gradle.kts (Kotlin DSL)

dependencies {
    implementation("com.squareup.retrofit2:adapter-rxjava3:2.9.0") // Адаптер для RxJava 3
    implementation("io.reactivex.rxjava3:rxjava:3.1.8") // RxJava 3
}

🚩Подключение `RxJava3CallAdapterFactory`

Добавляем адаптер в Retrofit.Builder

val retrofit = Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .addConverterFactory(GsonConverterFactory.create()) // Преобразование JSON
    .addCallAdapterFactory(RxJava3CallAdapterFactory.create()) // Поддержка RxJava
    .build()

🚩Использование RxJava в API

Теперь можно возвращать RxJava-объекты вместо Call<>.

interface ApiService {
    @GET("users/{id}")
    fun getUser(@Path("id") userId: Int): Single<User>
}

Пример с Observable<> (несколько данных или обновления)

interface ApiService {
    @GET("users")
    fun getUsers(): Observable<List<User>>
}

Пример с Flowable<> (если нужен Backpressure)

interface ApiService {
    @GET("posts")
    fun getPosts(): Flowable<List<Post>>
}

🚩Подписка и обработка результата

Пример подписки в ViewModel (RxJava 3 + LiveData)

class UserViewModel(private val apiService: ApiService) : ViewModel() {

    private val _userLiveData = MutableLiveData<User>()
    val userLiveData: LiveData<User> = _userLiveData

    fun fetchUser(userId: Int) {
        apiService.getUser(userId)
            .subscribeOn(Schedulers.io())  // Запрос в фоновом потоке
            .observeOn(AndroidSchedulers.mainThread()) // Обновление UI в главном потоке
            .subscribe({ user ->
                _userLiveData.value = user
            }, { error ->
                Log.e("UserViewModel", "Ошибка загрузки", error)
            })
    }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Когда начинает работать WorkManager?

WorkManager начинает выполнять задачу:
- Когда соблюдены все заданные условия (например, наличие сети, заряд батареи).
- После планирования задачи (enqueuing).
- Даже если приложение было перезапущено — WorkManager восстанавливает задачу.
- Если используется отложенная работа — срабатывает по расписанию или через заданный интервал.
Работает надёжно даже после перезагрузки устройства.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Может ли потеря state быть связанной с фрагментом?

Да, потеря состояния (state) может быть связана с фрагментами (Fragments) в Android. Это довольно распространённая проблема, особенно при работе с динамическими интерфейсами. Давайте разберёмся, почему она возникает, как её предотвратить и какие решения существуют.

🚩Почему происходит потеря состояния во фрагментах?

🟠Жизненный цикл фрагмента
Фрагменты имеют сложный жизненный цикл, который тесно связан с активностью. Основные этапы:
onCreate() — создаётся фрагмент, инициализируются объекты.
onViewCreated() — создаётся View (UI компоненты).
onStart() / onResume() — фрагмент становится видимым и активным.
onPause() / onStop() — фрагмент приостанавливается.
onDestroyView() — уничтожается только View (UI), но сам фрагмент всё ещё существует.
onDestroy() — полностью уничтожается фрагмент.
Фрагменты могут пересоздаваться системой, например, при смене ориентации экрана или нехватке памяти. Если разработчик неправильно сохраняет состояние фрагмента, оно может быть утеряно.

🟠Удаление View фрагмента системой
Когда фрагмент переходит в состояние onDestroyView(), его View уничтожается, но сам объект фрагмента сохраняется. Если пользователь вернётся к этому фрагменту, View будет пересоздана, и вы потеряете все изменения, сделанные ранее, если они не сохранены явно.

🟠Проблемы с менеджером фрагментов
Использование FragmentManager или FragmentTransaction с неправильными методами, такими как replace() или add(), без должного управления стэком (back stack), может привести к пересозданию или дублированию фрагментов, что вызывает потерю состояния.

🟠Проблемы с `savedInstanceState`
Фрагменты, как и активности, используют механизм сохранения состояния через Bundle (в onSaveInstanceState). Если состояние не сохранено правильно, данные могут быть потеряны.

🚩Как предотвратить потерю состояния во фрагментах?

🟠Сохранение данных в `onSaveInstanceState`
При уничтожении фрагмента система вызывает метод onSaveInstanceState(). Здесь вы можете сохранить важные данные в Bundle.

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("key_text", editText.text.toString())
}

При пересоздании фрагмента данные можно восстановить в onViewCreated()

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    val restoredText = savedInstanceState?.getString("key_text")
    editText.setText(restoredText)
}

🟠Использование `ViewModel`
Для хранения состояния, которое переживает уничтожение и пересоздание фрагмента, лучше использовать архитектурный компонент ViewModel.
1⃣Создайте ViewModel

class MyViewModel : ViewModel() {
    val textData = MutableLiveData<String>()
}

2⃣Используйте его во фрагменте

class MyFragment : Fragment() {
    private lateinit var viewModel: MyViewModel

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewModel = ViewModelProvider(this).get(MyViewModel::class.java)

        // Восстановление данных
        viewModel.textData.observe(viewLifecycleOwner) { text ->
            editText.setText(text)
        }

        // Сохранение данных при изменении
        editText.addTextChangedListener {
            viewModel.textData.value = it.toString()
        }
    }
}

🟠Использование `FragmentManager` правильно
При работе с фрагментами всегда добавляйте их в back stack, если вы хотите сохранить состояние.

val fragment = MyFragment()
parentFragmentManager.beginTransaction()
    .replace(R.id.fragment_container, fragment)
    .addToBackStack(null)
    .commit()

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как собираем код?

Через Gradle:
1. Компиляция исходников,
2. Обработка ресурсов,
3. Генерация R и BuildConfig,
4. Объединение в .apk или .aab,
5. Подпись и выравнивание.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В чем различие Default диспатчер и IO диспатчер?

В Kotlin Coroutines есть несколько диспетчеров (Dispatchers), но Default и IO используются чаще всего.

🚩Главное различие:

Dispatchers.Default — для тяжёлых вычислений (CPU-операции).
Dispatchers.IO — для операций ввода-вывода (сеть, файлы, БД).

🟠`Dispatchers.Default` – для сложных вычислений (CPU-bound)
Этот диспетчер используется, если код загружает процессор (например, сложные вычисления).

import kotlinx.coroutines.*

fun main() = runBlocking {
    launch(Dispatchers.Default) {
        val result = heavyComputation()
        println("Результат: $result")
    }
}

suspend fun heavyComputation(): Int {
    delay(1000)
    return (1..1_000_000).sum()
}

🟠`Dispatchers.IO` – для работы с файлами, сетью, БД (IO-bound)
Этот диспетчер оптимизирован для ввода-вывода (I/O): работа с файлами, сетью, БД.

import kotlinx.coroutines.*
import java.io.File

fun main() = runBlocking {
    launch(Dispatchers.IO) {
        val text = File("data.txt").readText()
        println("Файл прочитан: $text")
    }
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему необходимо использовать @Binds вместо @Provide?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как называется лейаут в котором объекты могут наслаиваться друг на друга?

В Android для наложения (перекрытия) элементов друг на друга используется FrameLayout или Box (в Jetpack Compose).

🚩FrameLayout (в XML и View)

FrameLayout — это контейнер, в котором все вложенные элементы располагаются в левом верхнем углу, но при этом могут накладываться друг на друга.

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <ImageView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:src="@drawable/background" />

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Наложенный текст"
        android:textSize="24sp"
        android:textColor="#FFFFFF"
        android:layout_gravity="center"/>
</FrameLayout>

🚩Box (в Jetpack Compose)

В Jetpack Compose аналогом FrameLayout является Box. Он также позволяет располагать элементы друг над другом.

Box(
    modifier = Modifier.fillMaxSize()
) {
    Image(
        painter = painterResource(id = R.drawable.background),
        contentDenoscription = "Фон",
        modifier = Modifier.fillMaxSize()
    )

    Text(
        text = "Наложенный текст",
        fontSize = 24.sp,
        color = Color.White,
        modifier = Modifier.align(Alignment.Center)
    )
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как работает SOLID-принцип SRP?

Принцип единственной ответственности (Single Responsibility Principle) гласит, что класс должен иметь одну, и только одну, причину для изменения. Это означает:
1. Класс должен выполнять только одну задачу или отвечать за один аспект функциональности.
2. Изменения в одной части функционала не должны влиять на другие аспекты.
3. Это упрощает сопровождение, тестирование и повторное использование кода.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как определить изменение скорости работы программы после наших действий?

🟠Profile GPU Rendering
Этот инструмент показывает время, затраченное на отрисовку каждого кадра. Использование этого инструмента позволяет выявить "тяжелые" кадры и измерить улучшения после оптимизации.

1⃣Включите режим разработчика на устройстве.
2⃣Перейдите в "Настройки" -> "Для разработчиков".
3⃣Включите опцию "Profile GPU Rendering" и выберите "On screen as bars".
4⃣Запустите ваше приложение и наблюдайте за графиками. Зеленые линии указывают на время отрисовки, и ваша цель - оставаться ниже 16 мс (для 60 кадров в секунду).

🟠Android Profiler
Предоставляет набор инструментов для анализа производительности приложения.

1⃣ Откройте Android Studio и запустите ваше приложение.
2⃣Перейдите в "View" -> "Tool Windows" -> "Profiler".
3⃣Выберите ваше устройство и запущенное приложение.
4⃣Используйте вкладки CPU, Memory, Network и Energy для анализа различных аспектов производительности.
5⃣Сравните данные до и после оптимизации.

🟠Benchmarking
Создание и использование тестов производительности помогает количественно оценить улучшения. Вы можете использовать библиотеку Jetpack Benchmark для создания и выполнения тестов производительности.

🚩Пример использования Jetpack Benchmark:

1⃣Добавьте зависимости в build.gradle:

dependencies {
    androidTestImplementation "androidx.benchmark:benchmark-junit4:1.1.0"
    androidTestImplementation "androidx.test:runner:1.3.0"
    androidTestImplementation "androidx.test:rules:1.3.0"
}

2⃣Создайте класс теста:

import androidx.benchmark.junit4.BenchmarkRule
import androidx.test.ext.junit.runners.AndroidJUnit4
import org.junit.Rule
import org.junit.Test
import org.junit.runner.RunWith

@RunWith(AndroidJUnit4::class)
class ExampleBenchmark {
    @get:Rule
    val benchmarkRule = BenchmarkRule()

    @Test
    fun myFunctionBenchmark() {
        benchmarkRule.measureRepeated {
            // Вызов вашей функции или кода для тестирования производительности
            myFunction()
        }
    }
}

🟠Logcat
Используйте журналирование для измерения времени выполнения определенных операций.

val startTime = System.currentTimeMillis()
// Ваш код
val endTime = System.currentTimeMillis()
Log.d("Performance", "Время выполнения: ${endTime - startTime} мс")

🟠StrictMode
StrictMode помогает обнаружить операции, которые могут замедлить работу приложения, такие как работа с сетью или базой данных в главном потоке.

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build()
    )
    StrictMode.setVmPolicy(
        StrictMode.VmPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build()
    )
}

🟠Systrace
Systrace позволяет собирать и анализировать трассировки производительности системы, предоставляя детализированные данные о времени выполнения различных операций.

1⃣Включите режим разработчика на устройстве.
2⃣В "Настройки" -> "Для разработчиков" включите "Enable GPU Debug Layers".
3⃣Запустите команду adb shell am broadcast -a com.android.systemui.screenshot.ScreenshotService.ACTION_SYSTRACE.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как бороться с проблемой backpressure в RxJava?

Проблема решается использованием Flowable вместо Observable, поскольку Flowable поддерживает стратегию управления нагрузкой. Также применяются операторы onBackpressureBuffer, onBackpressureDrop, onBackpressureLatest и управление запросами вручную.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 В чём отличие Dalvik Virtual Machine и ART(Android Run Time)?

Dalvik Virtual Machine (DVM) и Android Runtime (ART) — это две среды выполнения для запуска Android-приложений. DVM использовалась в ранних версиях Android, в то время как ART пришла на замену DVM, начиная с Android 5.0 (Lollipop). Основное различие между ними заключается в способе выполнения кода и производительности.

🚩Основные отличия между Dalvik и ART

🟠Тип выполнения кода
Dalvik Virtual Machine (DVM): Just-In-Time (JIT) компиляция
Dalvik использует JIT-компиляцию (Just-In-Time), что означает, что код приложения компилируется в машинный код во время выполнения (runtime).
Когда приложение запускается, DVM интерпретирует байт-код (.dex-файлы), а при необходимости компилирует часть кода "на лету" для повышения производительности.
Этот подход требует дополнительных ресурсов во время работы приложения, что увеличивает задержки (лаг) при запуске и потребляет больше CPU и батареи.
ART использует AOT-компиляцию (Ahead-Of-Time), которая компилирует весь код приложения в машинный код заранее — во время установки приложения.
Это устраняет необходимость интерпретации и JIT-компиляции во время работы приложения, что снижает нагрузку на процессор и улучшает производительность.

🟠Производительность
Dalvik (DVM):
Поскольку JIT-компиляция происходит во время работы приложения, это создает дополнительную нагрузку на процессор и замедляет выполнение.
Производительность ниже из-за частой интерпретации кода.
ART:
Благодаря AOT-компиляции приложения запускаются быстрее и работают плавнее.
Потребление ресурсов (CPU, батарея) значительно ниже, поскольку интерпретация и компиляция кода уже выполнены на этапе установки.

🟠Ускорение запуска приложений
Dalvik (DVM):
Приложения запускаются медленнее, так как DVM интерпретирует код во время каждого запуска.
ART:
Приложения запускаются быстрее, так как код уже компилирован в машинный код на этапе установки.

🟠Потребление батареи
Dalvik (DVM):
Потребляет больше батареи из-за того, что JIT-компиляция выполняется постоянно во время работы приложения.
ART:
Более энергоэффективен, так как большая часть работы выполнена заранее, и процессор не нагружается так сильно.

🟠Время установки приложения
Dalvik (DVM):
Приложения устанавливаются быстрее, так как код не компилируется заранее.
ART:
Приложения устанавливаются медленнее, так как на этапе установки выполняется AOT-компиляция.
Например, установка приложения в ART может занимать больше времени, чем в DVM, из-за компиляции кода.

🟠Память
Dalvik (DVM):
DVM использует меньше памяти на устройстве, так как код компилируется только во время работы приложения, и машинный код не сохраняется.
ART:
AOT-компиляция увеличивает размер приложения, так как компилированный машинный код сохраняется на устройстве. Это требует больше места в памяти.

🟠Отладка и инструменты
Dalvik (DVM):
Ограниченные возможности отладки, так как JIT-компиляция не предоставляет доступа к заранее оптимизированному коду.
ART:
ART позволяет разработчикам использовать более продвинутые инструменты отладки (например, профилирование исполнения) и лучше анализировать производительность приложений.

🟠Совместимость
Dalvik (DVM):
Dalvik был изначально разработан для устройств с ограниченными ресурсами (медленные процессоры, малый объем оперативной памяти).
Приложения работали в основном в условиях ограниченного оборудования.
ART:
ART ориентирован на современные устройства с мощными процессорами и большим объемом памяти.
Он лучше справляется с современными требованиями приложений.

🚩Пример различий

🟠На Dalvik (DVM):
- Установка быстрая.
- При запуске приложения DVM интерпретирует и компилирует код. Это требует времени и ресурсов.
- Приложение может работать медленно из-за интерпретации кода в реальном времени.
🟠На ART:
- Установка занимает больше времени, так как код компилируется сразу.
- Запуск приложения быстрый, потому что код уже готов к исполнению.
- Приложение работает плавно, так как отсутствует необходимость компиляции во время выполнения.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем array отличается от list?

В Kotlin `array` представляет собой фиксированный набор элементов одного типа, размер которого задается при создании. `List` может быть изменяемым (MutableList) или неизменяемым, и его размер может изменяться динамически. `List` предоставляет больше функциональности для работы с коллекциями данных.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Расскажи о контрактах equals и hashCode

Методы equals() и hashCode() используются для сравнения объектов и их корректной работы в коллекциях (Set, Map).

🚩Контракт `equals()`

Метод equals() должен:
Рефлексивность: a.equals(a) → true (объект равен самому себе).
Симметричность: a.equals(b) == b.equals(a).
Транзитивность: если a == b и b == c, то a == c.
Согласованность: если a == b, то a.equals(b) всегда возвращает одно и то же, пока объект не изменится.
Сравнение с null всегда даёт false: a.equals(null) == false.

class User(val name: String, val age: Int) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true  // Проверка на ссылочное равенство
        if (other !is User) return false  // Проверка типа

        return name == other.name && age == other.age  // Сравнение полей
    }
}

val user1 = User("Alice", 25)
val user2 = User("Alice", 25)
println(user1 == user2)  // true (потому что переопределён equals)

🚩Контракт `hashCode()`

Метод hashCode() должен:
Согласованность с equals(): если a == b, то a.hashCode() == b.hashCode().
Но обратное не обязательно: два разных объекта могут иметь одинаковый hashCode().
Хеш-код не должен меняться, если объект не изменился.

class User(val name: String, val age: Int) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is User) return false
        return name == other.name && age == other.age
    }

    override fun hashCode(): Int {
        return name.hashCode() * 31 + age  // 31 - стандартный коэффициент
    }
}

val userSet = HashSet<User>()
userSet.add(User("Alice", 25))
println(userSet.contains(User("Alice", 25)))  // true

🚩Автоматическая генерация в Kotlin

Чтобы не писать equals() и hashCode() вручную, можно использовать data class:

data class User(val name: String, val age: Int)

data class автоматически создаёт equals(), hashCode(), а также copy() и toString().

val user1 = User("Alice", 25)
val user2 = User("Alice", 25)
println(user1 == user2)  // true (equals)
println(user1.hashCode() == user2.hashCode())  // true

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое Dagger?

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

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какие стратегии бранчинга знаешь, расскажи про их плюсы и минусы?

Бранчинг (ветвление) — это способ управления кодом в Git, когда разработчики работают в отдельных ветках (branches).
Основные стратегии бранчинга
Git Flow
GitHub Flow
GitLab Flow
Trunk-Based Development

🚩Git Flow – классическая модель с `develop` и `release`

Основные ветки:
main (стабильная версия, релизы).
develop (основная ветка разработки).
Временные ветки:
feature/* (новые фичи, мерджатся в develop).
release/* (готовится релиз, тестирование, фикс багов).
hotfix/* (критические фиксы в main).
Схема Git Flow:

main ──── hotfix ─▶️ merge ────▶️ main
 │  
 ├── develop ─▶️ release ─▶️ merge ─▶️ main
 │      │
 ├── feature/1
 ├── feature/2

🚩GitHub Flow – упрощённый процесс для CI/CD

Только две основные ветки:
main (всегда стабильная версия).
Фичи разрабатываются в feature/* и сразу мерджатся в main.
Деплой возможен сразу после мерджа в main.
Схема GitHub Flow

main ────▶️ feature/1 ─▶️ merge ─▶️ main ─▶️ deploy
        └── feature/2 ─▶️ merge ─▶️ main ─▶️ deploy

🚩GitLab Flow – баланс между Git Flow и GitHub Flow

main – стабильная ветка (готовая к продакшену).
develop (опционально) – если нужно тестирование перед main.
feature/* – для разработки новых фич.
production, staging – если нужно разделение сред.
hotfix/* – фиксы продакшена.

main ────▶️ production
 │
 ├── staging ───▶️ merge ─▶️ main
 │
 ├── feature/1 ─▶️ merge ─▶️ staging
 ├── feature/2 ─▶️ merge ─▶️ staging

🚩Trunk-Based Development – одна ветка (`main`)

Разработчики работают прямо в main, без feature/* веток.
- Коммиты в main маленькие и частые.
- Используются Feature Flags (фичи включаются/выключаются динамически).
Схема Trunk-Based

main ────▶️ commit ─▶️ commit ─▶️ commit ─▶️ deploy

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие есть аналоги библиотеки Hilt?

Основные альтернативы — Dagger (ручная конфигурация), Koin (написан на Kotlin, декларативный), Kodein (устаревающий), Service Locator. Выбор зависит от предпочтений и архитектуры проекта.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний