всем по офферу

Кстати, судя по упоминанию трейтов кто-то тут знаком со скалой? :)

Это же с дивана вставать надо ещё

@bvitaliyg оффер

Ну тут да, много кто

Dmitriy оффер

и мне оффер всем по офферу

Я на ней не писал, просто встречал трейты как сущности в ООП

@andremacareno Мы поняли, можешь не продолжать :)

я и не собирался :D

Интересно было бы пообщаться с кем-нибудь, кто запилил в продакшен что-нибудь на Scala под андроид)

Вроде бы в году так 2013-м ею многие увлекались

И писали, особенно на аутсорсе

Даже в глубинках, в Ростове точно

Просто интересно, а стоит ли оно вообще того?)

https://youtu.be/MYaoSELIC_U

оно ж всё в один байткод компилируется

оно ж всё в один байткод компилируется

Нет

но зато там есть из коробки акторы

Да это-то понятно)

Множество команд одно и то же, а сами команды разные

мозг сломался на этой фразе

Обычно все жаловались на то, что из-за скалы и её stdlib сразу количество методов зашкаливает

мозг сломался на этой фразе

В Котлине есть nullable types. fun test(a: A) { System.out.println(a); } Как ты думаешь, какой код сгенерирует Котлин?

В Котлине есть nullable types. fun test(a: A) { System.out.println(a); } Как ты думаешь, какой код сгенерирует Котлин?

assert добавит?

Он сгенерирует примерно такое: void test(A a) { Utils.checkNotNull(a, "a"); System.out.println(a); }

Ага

Причем, Котлин ещё относительно быстрый язык

Я думаю, речь шла о том, что все скомпилится в 100% JVM-совместимый байткод

Там даже инлайн лямбд из соображений производительности сделали

Я думаю, речь шла о том, что все скомпилится в 100% JVM-совместимый байткод

именно

Собственно, на jpoint слушал доклад чувака из jetbrains, где он подробно все разжевал

Как тот или иной синтаксический сахар котлина выглядит при декомпиляции обратно в java-код

и типа смысл получается такой же, как и от библиотек - стало удобнее, но добавился оверхед?

Он там бенчмарки показывал, по итогу - да

Стало намного удобнее, но есть оверхед

В подавляющем большинстве случаем весьма незначительный

Именно так

Причем у них, повторюсь, не сильно большой ешё оверхэд

ну, процессоры нынче такие, что его никто не заметит, скорее всего

Лол

Заметит

И да, инлайн лямбд - по-моему это единственная фича, из-за которой котлин может выиграть у джавы

Попадет такой код в onDraw() — и будет тебе веселье

И да, инлайн лямбд - по-моему это единственная фича, из-за которой котлин может выиграть у джавы

Вроде бы да

Во всех остальных бенчмарках было либо полное равенство, либо небольшая просадка у котлина)

Другого я пока не видел

Попадет такой код в onDraw() — и будет тебе веселье

если там объекты не порождаются, то не будет, не?

А ты так часто думаешь, что они не порождаются? drawableList.forEach { it.draw(c) }

А учитывая, что Scala дает намного больше возможностей, чем котлин, мне вдвойне интересно как ее код распепячивается обратно в джаву))

я просто котлин/скалу/кложур/етц не смотрел :)

А так, конечно, на скале писать в андроиде - это от лукавого

Пусть лучше котлин развивают)

я вот хочу научиться по максимуму в натив запихивать

Зря хочешь

Нативный вызов это тоже оверхэд

Нельзя их по каждому чиху делать

А это из технических соображений, или из соображений т.н. job security? :)

спортивный интерес

Понятно)

Вообще, по поводу натива

ну раз уж речь об оверхеде пошла: да, это я понимаю - ну так давайте смотреть, в каких ситуациях он плох

Я недавно ради интереса взял один из самых быстрых нативных парсеров и написал к нему обертку в jni

я уж не говорю о том, что часть вещей в Android SDK и JDK сами их используют

Интерфейсно такую же, как в org.json

Разница в 8-9 раз

если мы работаем в нативе, у нас же еще GC спит, так ведь?

ERROR: S client not available

+ оно не держит все древо в куче

если мы работаем в нативе, у нас же еще GC спит, так ведь?

Нет, может вызываться

Но в самом нативе его нет, да

в любом случае, объектов собирать-то меньше

Ага

Вообще, кстати, приходилось слышать, что иногда джавовский код ухитряется работать быстрее нативного за счет JIT

В таком случае, получается, что в натив имеет смысл выносить то, что: 1) будет использоваться где-то ещё (то есть с целью кроссплатформенности) 2) порождает в яве миллион объектов при своей работе, хотя нужен, допустим, всего один какой-то еще варианты есть?

Может, если нужно кэшировать что-нибудь тяжелое за пределами JVM-heap

1) с кросслпатформенностью у натива, наоборот, все хуже. 2) да, но это частный случай.

а, ну и еще забыл третий пример, навеянный кодом телеграма когда нужно бэкпортировать иммутабельные битмапы или какие-то кодеки на старые версии андроида

Главный смысл — делать тяжелую работу, которую нельзя делать в джаве

Например, кодеки

Помнится, какая-то из попсовых либ для работы с картинками (fresco, кажется) такими делами грешила

Или сильное шифрование

Помнится, какая-то из попсовых либ для работы с картинками (fresco, кажется) такими делами грешила

Да, очень крутая фича

Никаких GC_FOR_ALLOC на 4.X

1) с кросслпатформенностью у натива, наоборот, все хуже. 2) да, но это частный случай.

я имею в виду ситуации, когда кусок приложения будет еще переиспользован на другой ОС

Типа айоса?

например

Тогда да, но обертку для jni все равно будешь сам писать

ну это понятно, надо же как-то в интерфейс прокидывать всё равно

Немного оффтоп, но помню однажды видел в одном iOS-проекте часть кода, для работы с крипто про

Это адище работало на голых сях и вызывало методы WinAPI

Уж не знаю как, но извращенцы из криптопро протащили винапишные либы на iOS

К слову о кросплатформенности :)

забавный пример :) я, конечно, не то имел в виду - просто, допустим, пишешь с stdlib и какими-то еще кроссплатформенными библиотеками, и приложение на какой-то десктопной ОС напрямую с этим работает, для андроида еще дописываешь враппер - и готово

Никаких GC_FOR_ALLOC на 4.X

вот, кстати, по этому поводу уточню, раз уж упомянули речь ведь идет о переиспользовании Bitmap'ов за счет киткатовских библиотек?

Я вот об этом говорил http://frescolib.org/docs/caching.html

Первый пункт. Они до 5-ого андроида битмапки кэшировали во внешней куче

к знатокам Camera API, пока что легаси: есть переключение между фото и видео, если я правильно понимаю, за это время должно произойти следующее: 1) останавливаем превью 2) пересчитываем размеры превью 3) снова показываем превью так вот: всё убрано в фоновые потоки, но всё равно есть заметный пролаг в 200 мс, есть мысли, как его убрать?

важно open вызывать с фонового потока, и не просто фонового, а с хэндлером, насколько помню

у меня конкурсное вроде не лагало