├── README.html └── README.md /README.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Вопросы к собеседованию по Android 6 | 7 | 8 | 9 | 10 | 13 | 20 | 21 | 22 | 23 | 24 |

Вопросы к собеседованию по Android

25 | 41 |

Структуры данных

42 |

Java

43 | 61 |

Android

62 | 188 |

Архитектура

189 |

Библиотеки

190 |

Moxy

191 | 194 |

RxJava

195 | 205 | 206 | 207 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Вопросы к собеседованию по Android 2 | 3 | - [Java](#java) 4 | - [Android](#android) 5 | - [Activity](#activity) 6 | - [Fragments](#fragments) 7 | - [Content provider](#content-provider) 8 | - [Services](#services) 9 | - [Broadcasts](#broadcasts) 10 | - [Custom Views](#custom-views) 11 | - [ViewModel](#viewmodel) 12 | - [Другое](#%d0%94%d1%80%d1%83%d0%b3%d0%be%d0%b5) 13 | - [Kotlin](#kotlin) 14 | - [Inline-функции](#inline-%d1%84%d1%83%d0%bd%d0%ba%d1%86%d0%b8%d0%b8) 15 | - [Архитектура](#%d0%90%d1%80%d1%85%d0%b8%d1%82%d0%b5%d0%ba%d1%82%d1%83%d1%80%d0%b0) 16 | - [Библиотеки](#%d0%91%d0%b8%d0%b1%d0%bb%d0%b8%d0%be%d1%82%d0%b5%d0%ba%d0%b8) 17 | - [Moxy](#moxy) 18 | - [RxJava](#rxjava) 19 | 20 | # Java 21 | 22 | - Виды референсов: https://habr.com/ru/post/169883/ 23 | 1. **SoftReference** — если GC видит что объект доступен только через цепочку soft-ссылок, то он удалит его из памяти, если памяти будет не хватать. Удобно для кеширования. 24 | 2. **WeakReference** — если GC видит что объект доступен только через цепочку weak-ссылок, то он удалит его из памяти. Применение: WeakHashMap. Это реализация Map которая хранит ключ, используя weak-ссылку. И когда GC удаляет ключ с памяти, то удаляется вся запись с Map. 25 | Близкое к Андроиду применение [в разделе WeakReference этой статьи](https://xakep.ru/2016/06/01/android-multithreading-1/#toc09.). 26 | 3. **PhantomReference** — если GC видит что объект доступен только через цепочку phantom-ссылок, то он его удалит из памяти. После нескольких запусков GC. 27 | Особенностей у этого типа ссылок две. Первая это то, что метод **get() всегда возвращает null**. Именно из-за этого PhantomReference имеет смысл использовать только вместе с ReferenceQueue. Вторая особенность – в отличие от SoftReference и WeakReference, GC добавит phantom-ссылку в ReferenceQueue после того как выполнится метод finalize(). То есть фактически, в отличии от SoftReference и WeakReference, объект еще есть в памяти. 28 | 29 | - Volatile/Atomic 30 | - *volatile* помечает объект как доступный для нескольких тредов. Ожидаемо работает только для атомарных операций. Например, операция инкремента не атомарна, из-за чего процесс будет сбоить. 31 | - *Atomic*-классы использут compare and swap алгоритм: обновляет значение, только если предыдущее совпадает с ожидаемым old value. 32 | 33 | - Описать Handler 34 | - Handler - это механизм, который позволяет работать с очередью сообщений между потоками. Он привязан к конкретному потоку и работает с его очередью. Handler умеет помещать сообщения в очередь. При этом он ставит самого себя в качестве получателя этого сообщения. И когда приходит время, система достает сообщение из очереди и отправляет его адресату (т.е. в Handler) на обработку. 35 | 36 | - Абстрактные классы против интерфейсов 37 | - Переменные в интерфейсе по умолчанию final 38 | - В абстрактном классе могут использоваться модификаторы доступа, в интерфейсе по умолчанию всё public 39 | - Можно наследовать несколько интерфейсов, но только один класс 40 | 41 | # Android 42 | 43 | ## Activity 44 | 45 | - Жизненный цикл Activity 46 | - `OnCreate()` Создаётся view. 47 | - `OnStart()` Активити становится видно 48 | - `OnResume()` Активити становится доступным для ввода пользователя 49 | - `OnPause()` Активити видно, но недоступо для ввода пользователя (важно для многооконного режима) 50 | - `OnStop()` Активити больше не видно 51 | - `OnDestroy()` Активити уничтожается 52 | - `OnRestart()` Активити пересоздаётся, вызывается после уничтожения и перед созданием 53 | 54 | - Какие методы вызываются при переходе между активити 55 | - A: onCreate, onStart, onResume 56 | A: *(переход)* onPause 57 | B: onCreate, onStart, onResume 58 | A: onStop 59 | B: *(обратный переход)* onPause 60 | A: onRestart, onStart, onResume 61 | B: onStop, onDestroy 62 | ![иллюстрация процесса](https://lh5.googleusercontent.com/-MMX3o4pdsd0/ToybUtq-EFI/AAAAAAAAAbw/ri5MQ1Jg5sI/s800/20111005_L0024_L_TwoActSchema.jpg) 63 | 64 | - Когда `onDestroy()` вызывается без `onPause()` и `onStop()`? 65 | - Если активити закрывается через метод `finish()` до начала onStart и onResume. 66 | 67 | - Почему `setContentView()` располагают в `onCreate()` 68 | - Это тяжёлая операция, и выгоднее производить её только единожды, при создании активити. 69 | 70 | - Launch modes 71 | - **Standard** При вызове, активити создаётся заново. 72 | - **SingleTop** Активити создаётся заново, только если она не вверху активити-стека. 73 | - **SingleTask** Стек стирается до момента, пока эта активити не окажется наверху стека. 74 | - **SingleInstance** Похож на SingleTask, но при создании активити, она уйдёт в новый таск. 75 | 76 | - Как очистить бэкстек при создании активити 77 | - Использовать флаг `FLAG_ACTIVITY_CLEAR_TOP`. 78 | - Использовать `FLAG_ACTIVITY_CLEAR_TASK` и `FLAG_ACTIVITY_NEW_TASK` вместе. 79 | 80 | - Разница между `FLAG_ACTIVITY_CLEAR_TASK` и `FLAG_ACTIVITY_CLEAR_TOP` 81 | - Первый очистит всё, что есть в таске, второй — только до той же активити, что и запускаемая. 82 | 83 | - Как при пересоздании активити сохранить некоторый объект (кроме onSaveInstanceState) 84 | - Методы [onRetainCustomNonConfigurationInstance()](https://developer.android.com/reference/android/support/v4/app/FragmentActivity.html#onretaincustomnonconfigurationinstance) и 85 | [getLastCustomNonConfigurationInstance()](https://developer.android.com/reference/android/support/v4/app/FragmentActivity.html#getlastcustomnonconfigurationinstance) класса FragmentActivity (или AppCompatActivity) 86 | - Если активити — просто держатель для фрагментов, лучше в самих фрагментах делать `setRetainInstance(true)` 87 | 88 | ## Fragments 89 | 90 | - Жизненный цикл Fragment 91 | - ![Жизненный цикл фрагмента](https://i.stack.imgur.com/fRxIQ.png) 92 | 93 | - Отличия `commit()`, `commitNow()`, `commitAllowingStateLoss()` и `commitNowAllowingStateLoss()` 94 | - Если вызвать `commit()` после `onSaveInstanceState()`, система выкинет IllegalStateException ([подробнее о причинах и процессе](https://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html)). 95 | - `commitAllowingStateLoss()` в этом случае не вызовет исключения, но состояние менеджера фрагментов может быть потеряно. 96 | - `commit()` помещает транзакцию для выполнения, когда главный поток будет свободен. Для синхронного выполнения висящих транзакций можно использовать метод `executePendingTransactions()`. Альтернатива этому — метод `commitNow()`, который исполнит транзакцию сразу, однако не сможет поместить её в backstack ([подробнее](https://medium.com/@bherbst/the-many-flavors-of-commit-186608a015b1)). 97 | 98 | ## Content provider 99 | 100 | - Зачем нужен Content Provider 101 | - Позволяет передавать данные между приложениями и процессами. Используется в связке с `ContentResolver`. 102 | 103 | ## Services 104 | 105 | - Виды Service/IntentService 106 | - Часть приложения без UI 107 | - **Foreground** Выполняется в основном потоке. Во время исполнения показывает уведомление. Пример — аудиоплеер. 108 | - **Background** Выполняется в фоновом потоке. Начиная с API 26, приложения в фоне не могут создавать фоновые сервисы, решением в этом случае может быть `WorkManager`. 109 | - **Bound** Клиент-серверный подход: посылаем запросы, получаем результаты. 110 | - **IntentService** Создаёт и работает в собственном потоке, выполняет работу из метода `onHandleIntent()`, после чего останавливается. Операции в `onHandleIntent()` не могут быть прерваны, связь с основным потоком отсутствует. 111 | 112 | - Жизненный цикл сервисов 113 | ![иллюстрация](https://developer.android.com/images/service_lifecycle.png?hl=ru) 114 | 115 | - Метод `startService()` 116 | - startService не размножает экземпляры сервиса, а только создает очередь из заданий для него. И если IntentService просто выполнит все задания последовательно, одно за другим, то благодаря классу Service у нас появляется возможность запустить все задачи одновременно в независимых потоках. Достаточно в методе onStartCommand создавать новые потоки для каждой задачи. 117 | 118 | - Остановка сервиса 119 | - Сервис, создaнный с помощью одноименного класса, будет жить, пока его принудительно не остановят. Сделать это можно либо откуда-то снаружи методом stopService, с указанием интента, которым он был запущен, либо внутри самого сервиса методом stopSelf. 120 | - Как узнать, что сервис уже все сделал, особенно если мы поставили перед ним сразу несколько задач? В этом нам поможет параметр startId у метода onstartcommand — это порядковый номер каждого вызова сервиса, который увеличивается на единицу при каждом запуске. 121 | - Создав новый поток, разумно завeршать его методом stopSelf, указывая startId в качестве параметра. С таким параметром ОС не будет сразу завершать сервис, а сравнит переданный идентификатор с тем, который был выдан при последнем запуске onStartCommand. Если они не равны, значит, в очередь была добавлена новая задача и сервис остановлен не будет. 122 | 123 | - Перезапуск сервиса 124 | - Даже если ОС и внeштатно выгрузит сервис из памяти, есть возможность его запустить заново, кaк только появятся свободные ресурсы. 125 | - Метод onStartCommand возвращает переменную, указывaющую ОС, как следует поступить с сервисом, если он был принудительно остановлен. Существует три варианта того, как ОС может поступить с сервисом, если он был принудительно завершен: 126 | - `START_NOT_STICKY` — не будет перезапущен системой, и все останется так, как есть. Подходит для случая, когда он выпoлняет не самые важные задачи, и приложение может позже при необходимости самостоятельно его перезапустить. 127 | - `START_STICKY` — будет запущен заново, но в Intent, который ОС создаст для его запуска, не будет никаких параметров. Такой вариант работает с аудиоплеерами — он должен быть активным в фоне, но не обязательно при этом автоматически начинать проигрывать песни. 128 | - `START_REDELIVER_INTENT` — сервис будет запущен с теми же параметрами, которые были при его последнем старте. Это удобно, когда в фоне загружается большой файл и его загрузка была прервана. 129 | 130 | ## Broadcasts 131 | 132 | - Как обновить UI-поток из фонового сервиса 133 | - Использовать Local Broadcast. 134 | 135 | - BroadcastReceiver в Android 8 136 | 1. Apps that target Android 8.0 or higher can no longer register broadcast receivers for implicit broadcasts in their manifest. An implicit broadcast is a broadcast that does not target that app specifically. For example, ACTION_PACKAGE_REPLACED is an implicit broadcast, since it is sent to all registered listeners, letting them know that some package on the device was replaced. However, ACTION_MY_PACKAGE_REPLACED is not an implicit broadcast, since it is sent only to the app whose package was replaced, no matter how many other apps have registered listeners for that broadcast. 137 | 2. Apps can continue to register for explicit broadcasts in their manifests. 138 | 3. Apps can use Context.registerReceiver() at runtime to register a receiver for any broadcast, whether implicit or explicit. 139 | 4. Broadcasts that require a signature permission are exempted from this restriction, since these broadcasts are only sent to apps that are signed with the same certificate, not to all the apps on the device. 140 | 141 | ## Custom Views 142 | 143 | - onTouchEvent() 144 | - https://stfalcon.com/ru/blog/post/learning-android-gestures 145 | 146 | ## ViewModel 147 | - Краткое устройство ViewModel (AndroidX, [исходный код](https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/lifecycle/lifecycle-viewmodel/src/main/java/androidx/lifecycle?source=post_page---------------------------%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F&autodive=0%2F%2F%2F "исходный код")) 148 | [![Диаграмма классов](https://cdn.hashnode.com/res/hashnode/image/upload/v1585478386526/eh4VTpAqP.png?auto=format&q=60 "Диаграмма классов")](https://charlesmuchene.hashnode.dev/surviving-configuration-change-viewmodel-ck8cyte8u00nfxes1o6s76r1m "Диаграмма классов") 149 | - В активити мы получаем ссылку на ViewModel, используя 150 | ```java 151 | ViewModelProvider(this).get(ViewModel::class.java); 152 | ``` 153 | - `ViewModelProvider` создаёт вью-модель и сохраняет её во `ViewModelStore`. 154 | - Параметр, который мы передаём как `this` при получении `ViewModelProvider` имеет тип `ViewModelStoreOwner`, который как раз и хранит `ViewModelStore`. Если отследить, какие классы наследует наша активити, то видно, что она наследуется от [ComponentActivity](https://android.googlesource.com/platform/frameworks/support/+/8514bc0f4d930b5470435aa365719b2a6a3ad2f3/activity/src/main/java/androidx/activity/ComponentActivity.java "`ComponentActivity`"), которая реализует интерфейс `ViewModelStoreOwner`. 155 | - Когда активити пересоздаётся, она сохраняет текущий `ViewModelStore`, используя свои методы `onRetainNonConfigurationInstance()` и `getLastCustomNonConfigurationInstance()`, а также статический класс `NonConfigurationInstances`. 156 | - Также активити имеет `LifecycleEventObserver`, который слушает изменения жизненного цикла и, при уничтожении активити, вызывает `getViewModelStore().clear()`. 157 | 158 | ## Другое 159 | 160 | - Разница между Serializable и Parcelable 161 | - В первом используется рефлексия, довольно медленный процесс, однако разработчику нужно писать меньше кода. В Parcelable мы описываем только те вещи, которые нужно сериализовать, из-за чего кода становится больше. 162 | 163 | - Виды Intent-ов 164 | - **Implicit** (неявный) Вызываете системный интент: отправить СМС, позвонить, открыть карты и так далее 165 | - **Explicit** (явный) Вызов других активити внутри приложения 166 | - **Sticky** Интент, который остаётся после завершения бродкаста. Например, при подписке на `ACTION_BATTERY_CHANGED`, мы получим последний посланный интент. Поэтому, если нам нужно только текущее состояние батареи, слушать дальнейшие бродкасты не обязательно. 167 | - **Pending** Интент, который может быть исполнен в будущем на правах вашего приложения 168 | 169 | - Может ли приложение работать в разных процессах? Зачем это нужно? Как можно организовать межпроцессорное взаимодействие? 170 | - Может. Для частей приложения (активити, сервисы, бродкасты и контент провайдеры) надо указать флаг process. 171 | - +: Получаем больше памяти. Не всё приложение при недостатке памяти будет убито. 172 | - -: Поскольку каждый процесс живёт в отдельном инстансе Дальвика, делиться информацией сложно. Для этого используются AIDL, интенты, handler-ы, messenger-ы 173 | 174 | - Из-за чего возникает ошибка Application Not Responding (ANR) 175 | - Когда UI не отвечает несколько секунд. Случается обычно из-за блокированного главного треда. 176 | 177 | - Как обнаружить ANR? 178 | ```kotlin 179 | class App : Application() { 180 | 181 | var tick = 0 % Integer.MAX_VALUE 182 | 183 | override fun onCreate() { 184 | super.onCreate() 185 | 186 | val handler = Handler(mainLooper) 187 | 188 | thread { 189 | while (true) { 190 | val lastTick = tick + 1 191 | handler.post { tick += 1 } 192 | TimeUnit.SECONDS.sleep(5) 193 | 194 | if (lastTick != tick) 195 | Log.d("APP", "ANR") 196 | } 197 | } 198 | 199 | } 200 | } 201 | ``` 202 | 203 | # Kotlin 204 | 205 | ## Inline-функции 206 | - Здесь и далее основано на статье [ч.1](https://proandroiddev.com/dissecting-the-inline-keyword-in-kotlin-chapter-1-51735600d7), [ч.2](https://proandroiddev.com/dissecting-the-inline-keyword-in-kotlin-chapter-2-32f4bc0fcbf9). Примеры кода смотреть в них. 207 | 208 | - Зачем в котлине ключевое слово `inline` 209 | - В Котлине функции рассматриваются как любые другие значения: они могут быть переданы в и возвращены из методов, сохранены в переменные или в структуры данных. Чтобы поддержать это, Котлин использует семейство функциональных типов. Тогда, чтобы работать с *лямбдами*, Котлин создаёт объекты, реализующие интерфейсы `Function0`, `Function1` и так далее. 210 | - Когда в лямбде нет замыкания (грубо говоря: из лямбды не вызываются переменные и методы, которые не лежат внутри самой лямбды), для её реализации компялтор создаёт синглтон. Но для лямбды с замыканием компилятор вынужен создавать инстанс для каждого вызова лямбды. Если лямбда вызывается в цикле, это может даже привести к OOM (нехватке памяти). 211 | - В таком случае на помощь приходит ключевое слово `inline`: оно говорит компилятору, что содержимое лямбды нужно встроить в место её вызова, как будто мы написали код не внутри лямбды, а прямо в теле метода. 212 | - Для чего нужно ключевое слово `reified` 213 | - В Java существует такая концепция, как Type Erasure — стирание типов. Коротко говоря, это проблема, возникающая при работе с дженериками. Из-за неё, например, нельзя сделать проверку типа `new ArrayList() instanceof List`: в рантайме джава-машина не знает, какие конкретно типы лежат внутри дженерика. 214 | - Поскольку в Андроиде Котлин использует рантайм Джавы, проблема остаётся: мы не можем проверить, что `arrayListOf() is List`. 215 | - Но используя `inline` функции, мы можем избежать стирания типов с помощью применения модификатора `reified` к дженерику: 216 | ```kotlin 217 | inline fun myGenericFunction(value: T): T {...} 218 | ``` 219 | - `crossinline` и `noinline` 220 | - Поскольку мы встраиваем код лямбды на место вызова, `return`, написанный в лямбде, закончит выполнение не лямбды, а всей функции. Когда нам это не нужно, мы можем пометить лямбда-параметр функции как `crossinline`, что запретит нелокальные `return`ы. 221 | ```kotlin 222 | inline fun function(crossinline nonLocalReturnBlockedLambda: () -> Unit) {...} 223 | ``` 224 | - Порой в inline функции нам нужно не вызвать лямбду на месте, а передать дальше, в другой метод. Тогда лямбда-параметр можно пометить как `noinline`, и он не будет встраиваться в место вызова. 225 | ```kotlin 226 | inline fun parameterPassedToOtherInlineFunction(lambda1: () -> Unit, noinline lambda2: () -> Boolean) { 227 | // эта лямбда встроится 228 | lambda1.invoke() 229 | // а эта останется лямбдой и будет передана в другой метод 230 | someNonInlinedLambdaConsumingFunction(lambda2) 231 | } 232 | ``` 233 | 234 | # Архитектура 235 | 236 | **TBD** 237 | 238 | # Библиотеки 239 | 240 | ## Moxy 241 | 242 | - Moxy создаёт $$PresenterBinder, хранит хеш-мапы c биндерами в MoxyReflector 243 | 244 | ## RxJava 245 | 246 | - Subjects 247 | - Publish Subject: Излучает(emit) все последующие элементы наблюдаемого источника в момент подписки. 248 | - Replay Subject: Излучает(emit все элементы источника наблюдаемого(Observable), независимо от того, когда подписчик(subscriber) подписывается. 249 | - Behavior Subject: Он излучает(emit) совсем недавно созданый элемент и все последующие элементы наблюдаемого источника, когда наблюдатель(observer) присоединяется к нему. 250 | - Async Subject: Он выдает только последнее значение наблюдаемого источника(и только последнее). Чтоб его подписчики получили содержание, на сабджекте нужно вызвать onComplete 251 | 252 | - flatMap / switchMap / concatMap / concatMapEager 253 | - `flatMap` не следит за порядком получаемых значений. Для каждого из передаваемых ему значений он создаёт свой observable и может прийти в любом порядке. 254 | - `switchMap` когда новый объект появлятся из observable выше, он отписывается от остальных — получает только последнее из значений. 255 | - `concatMap` похож на `flatMap`, но сохраняет порядок значений. Но есть и минус: `concatMap` ждёт заверешения каждого observable перед переходом к следующему 256 | - `concatMapEager` похож на `concatMap`, но выполняет код observable асинхронно. Его недостаток: требует больше памяти, чем остальные методы, поэтому для больших стримов использовать аккуратно 257 | --------------------------------------------------------------------------------