Комментарии 34
По-моему, должен стрельнуть ANR.
Edit: юзер всё равно будет тыкать в экран, значит ANR :)
Если интересно, можешь лично проверить, но ANR не будет, так как мы просто блокируем main поток
Главный поинт, который хотел передать - блокировка не вызывает ANR. А вот необработанные входные события (клики) - вызывают
Вроде мелочь, но, как мне кажется, забавная)
Так работает любой GUI-фреймворк, сделанный за последние 30 лет. Если в очереди событий ничего нет, то и то, что её разгребание подвисло, никто не обнаружит. Другое дело, что на десктопах просто в силу их природы событий больше — например, есть события перемещения мыши. Поводил курсором над зависшим окном — уже забил ему очередь.
Палку кинули в колесо. Что произойдёт с телегой? Должен знать!
Ну, раз сначала комент, то понеслась:
Напутано с отступами. Любители фигурных скобок - они такие. На питон вас надо.
Несоответствие комментария и функции. "Пошоркать часики", так что-ли?
Ну если это всё-таки runBlocking, тогда это немного разрыв шаблона. Надо определиться, чего мы хотим - run или blocking? Но если и то и другое - наверняка run бесконечно вызывает вот эту хрень, что блокирует выполнение потока, а потом переключает асинхронный контекст и так до бесконечности. Только вот вопрос: зачем это делать в OnCreate?
Вот такие мысли об офигительном дизайне приходят на ум дилетанту, который яву брал в руки 12 лет назад, а писать для мобилок до сих пор желания нет.
хахах, да, за наблюдательность с комментарием лайк)
Понятно, что это вымышленный пример. Никто так делать не будет.
Просто все разработчики знают, что такое ANR, но даже тут можно ошибиться)
а runBlocking это из корутин штука, блокирует поток (если кратко)
Кажется, при вызове `runBlocking` стоит использовать 'delay()', вместо 'Thread.sleep()'?Поскольку `runBlocking`, `delay` это утилиты корутин, а мешать потоки и корректны - плохая практика)
Тут же как раз и надо заблочить поток. delay поток не блочит, он говорит машинерии в корутинах, что нужно пойти к другим корутинам на какое-то время
Насчет плохой практики — ну, блокировка main потока тоже плохая практика, тут же не про best practices статья
Почему то подумал что вопрос в том отрисуется или нет вью. И по идее не отрисуется, ибо хоть вью заинфлейтится и добавится, но насколько помню после этого только выставляются requestLayout и invalidate, а измерение, размещение и отрисовка уже на следующем шаге лупера выполнится.
З.Ы. А зачем runBlocking если Thread.sleep уже достаточно? А если уж runBlocking, тогда задачка была бы веселей если внутри delay вызвать вместо Thread.sleep, чтобы дополнительно запутать.
Я тут недавно с другой задачкой столкнулся,
Создаем функцию function без параметров, затем перегружаем ее но уже с параметром который имеет значение по умолчанию. Теперь вызываем функцию не передавая в нее параметры. Какая функция вызовется и почему.
ps
С наступающим кстати!
Для override же сигнатура совпадать должна. На уровне байткода если дефолтные параметры есть - несколько методов генерируется, мне кажется компилятор ошибку должен кидать.
А если речь просто про создание функций с одинаковым именем но разной сигнатурой (где в одном случае все параметры значение по умолчанию имеют, а в другом параметров нет) - то по идее на уровне байткода та что с дефолтными параметрами - эти самые параметры иметь все равно будет. В таком случае, кмк, либо компилятор ругнется, либо вызовет ту что на уровне байткода без параметров (ибо совместимость с java, все дела).
не ругнется, но кстати мне что то в голову не пришло декомпилировать в java код
ps
кстати в чистом котлине действительно будет вызываться всегда функция которая без параметров.а вот в Android Emulator, у меня изредка почему то вызывалась функция с параметрами. Но возможно это глюки именно эмулятора...
Странно конечно. На уровне байткода сигнатуры прям разные должны быть что в jvm обычных, что в dex. Так что поведение должно быть одинаковое при каждом запуске, смотря какую сигнатуру компилятор в месте вызова прописал. И прописывать он по идее должен сигнатуру без параметров.
Разве что jit странно отрабатывает... Но по идее опять же, в байткоде четко должен быть вызов без параметров. jit ничего сломать не должен.
тут же про overload а не override :)
Просто покажется белый экран. Layout активити отрисуется на следующем кадре после того, как таймаут закончится.
Задавая такой вопрос на собеседовании, что Вы хотите проверить у кандидата?
Видимо проверить факт "ты абсолютно нормальный человек, у тебя скорее всего много друзей, есть девушка и в целом в жизни все прекрасно" (с)
Например, чтобы не спрашивать "Что такое ANR?" можно привести этот пример с блокировкой
Даже если человек скажет, что ANR не будет, можно спросить - почему?
И если называет условие возникновения ANR, то он молодец. Это показывает, что человек умеет работать с деталями
Но я бы не судил уровень кандидата по такому вопросу) Это просто рубрика "Эксперименты"
Мне кажется, что будет справедливо добавить, что вот такой код вызовет ANR. И стоило бы побольше расписать момент, что в изначальном примере ANR не будет, потому что юай в целом не отобразится и юая не будет как такового, поэтому не будет возможности блокировать юай и соответственно вызвать ANR. Не сразу понял, в чем загвоздка. Неподготовленного разработчика это может ввести в заблуждение
Первое, что пришло в голову - ОС сочтёт, что приложение повисло и предложит его закрыть...
Вопрос из разряда "мне кажется, что я тут познал ньюансы, пострадаю-ка я хернёй на собеседовании за счёт конторы". Не познал, даже близко.
"Задержка на UI thread = падение приложения" это, для начала, альфа и омега любой мобильной оси по состоянию "десять лет назад". Никаких там пяти секунд, не надо терзаться. Сразу, иногда и без показа UI. То, что на какой-то оси теперь это по другому, никак не меняет простой основы: так делать нельзя. И это единственный правильный ответ.
Не надо филигранно направлять незаряженный 9мм на человека - потому что не заряжен он сегодня, а завтра очередной копатель в ньюансах решит, что нашел идеальный угол снятого предохранителя, при котором на него можно дунуть и он снимется, а так не, стрелять не будет. Ну, пока оппонент не чихнет.
Копания в нюансах подобного типа с начинающими приведет к тому, что они где-то решат "так не рухнет же сразу, использую". И потом ровно этот же собеседующий будет разгребать последствия в виде лапши, от которой падает очередной билд.
Умельцы работать с деталями, господь жги. А потом после таких умельцев двадцатилетний код, который надо вывести в асинхрон, бо он из-за "знания ньюансов" втыкает на каждом шагу, а умельцы сидят и рассказывают тебе, как же это теперь невыразимо сложно.
Где можно получить оффер, если я ответил правильно?
Простой вопрос по Android Core, на который даже сеньоры отвечают неправильно