Разработка ждёт балета – Telegram
Разработка ждёт балета
1.65K subscribers
506 photos
4 videos
15 files
1.53K links
What I cannot create, I do not understand.

DM: @alexey_mileev
PeerLab: https://news.1rj.ru/str/+e2ND1tAa0lU2ZTli
Download Telegram
Слушайте, это и смешно и грустно. Google убивает свой сокращатель ссылок goo.gl. У меня одного в последние несколько месяцев от новостей о Google остаётся ощущение, что в консерватории что-то не так?

#google #url #shortener
https://developers.googleblog.com/2018/03/transitioning-google-url-shortener.html
Слушайте, тут в статье чувак пишет, что билд из терминала у него на слабой машинке работает сильно быстрее (прямо очень сильно быстрее), чем билд из студии. Кто может объяснить, почему так? Разве студия выполняет какие-то лишние gradle таски?

#build #gradle #studio
https://android.jlelse.eu/how-i-reduced-my-android-build-times-by-89-4242e51ce946
Если тебе хотя бы раз приходилось разбирать APK, пропущенный через ProGuard, ты наверняка замечал, что новые имена он выбирает по принципу столбцов в Excel (a, b, …, aa, ab, …). Это действительно так, но можно задавать эти словари самому. Можно их строить случайным образом и даже так, чтобы Windows был недоволен распакованными файлами. Подробности - по ссылке.

#proguard #build #obfuscation
https://proandroiddev.com/improving-proguard-name-obfuscation-83b27b34c52a
Довольно интересная статья про Activity lifecycle. Автор предлагает интересный подход к тому, что именно писать в onCreate, onStart и т.п. методах. В принципе, ничего особенно нового в статье нет, но освежить в памяти хорошо забытое старое всегда полезно.

#activity #lifecycle
https://www.techyourchance.com/android-activity-life-cycle-for-professional-developers/
Интересный оффтоп. Замечательная статья, в которой очень подробно описан каждый шаг boot процесса для Linux: от power-кнопки до готовой к работе системы.

#linux #boot #kernel
https://www.ibm.com/developerworks/library/l-linuxboot/
Статья уровня “для начинающих”, но мне почему-то дико зашло. Чувак очень элегантно скрестил logger с Kotlin-фишками и кусочком Timber, который позволяет достать имя класса, из которого был вызван метод logger.

#kotlin #log
https://www.varvet.com/blog/logger/
Небольшой обзор новых View в 28-й support library. В целом, всё как обычно. Добавили несколько View, которые все уже написали сами. Всё равно приятно, если работать это будет нормально, разумеется. Мне особо понравились изменения в кнопках - видно, что Material не стоит на месте и потихоньку меняется в лучшую сторону.

#material #supportlib
https://medium.com/exploring-android/exploring-the-v28-android-design-support-library-2c96c6031ae8
Ребята из Uber написали о том, как они на программном уровне улучшили GPS (и не только, куда же без GLONASS) позиционирование. Жаль только, что работать это будет не во всех городах и не на всех девайсах.

#gps #location
https://eng.uber.com/rethinking-gps/
В статье разбирается, какие методы обычно используются в приложениях, чтобы понять, что они бегут на эмуляторе, и как эти проверки обойти.

#emulator #cybersec
http://www.juanurs.com/Bypassing-Android-Anti-Emulation-Part-I/
Неплохую статью прислал @duglasher. В блоге Instagram Engineering вышла статья про то, как они пилили type mode (a.k.a. лень фотографировать, просто разукрашу текст) на iOS и Android. Часть про адаптацию размера текста довольно простая, а вот часть про Span мне понравилась, есть интересные советы, которые много где могут пригодиться.

#instagram #text #span
https://instagram-engineering.com/building-type-mode-for-stories-on-ios-and-android-8804e927feba
Ребята из Uber показали свой доморощенный method tracing tool. И вот знаете, с одной стороны, богатая идея, а с другой, немножко пугает: они решили измерять с уровня системы, т.е. их тул это форк AOSP, который умеет бенчмаркать. Такие дела.

#performance #benchmarks #methodtracing
https://eng.uber.com/nanoscope
Ну, вы знаете, на днях закончился Google I/O. Мне не удалось на нём побывать, но иметь материал где-то на подкорке хочется. Я думаю, что не один в таком положении. Поэтому я буду потихоньку смотреть записи всех сессий, что мне показались интересными, и закидывать сюда поинты из каждого видео, которые меня заинтересуют. Не в каждый нюанс я буду погружаться достаточно глубоко, поэтому, если где-то ошибусь, feel free to написать мне, что я мудак и объяснить, в чём именно :) Итак, первый пошёл…
Есть проблема. Я её, например, ощущаю на себе: все приложения соответствуют Material Design и почти все выглядят одинаково скучно. Размывается индивидуальность бренда. На выбор компании остаются только цвет да иконки (не всегда, но часто). И, хотя Google-guys с самого начала говорили, что material - это рекомендация, а не жёсткие рамки, почти все всё равно лепили по material-лекалам одно и то же безобразие. Ну, Google поняли, что имеют дело со стадом хомячков, и решили добавить нам степеней свободы. Посредством Material Theming нам дают свободу (и тулзы, чтобы эту свободу держать в узде - сочетай цвета, мать твою) в выборе цветов, шрифтов и форм для элементов на экране.
Появился Sketch-плагин, который позволит переложить работу дизайнера в стили для Material Components - пачки написанных для нас View.
Ещё мне очень понравился момент с формой контролов (см. картинку выше), который даёт дополнительное понимание z-level’а компонентов.

#talk #material #design
https://youtu.be/3VUMl_l-_fI
Цитата, близкая к оригиналу: "On Pixel 2 we've got 7 hardware layers, but on the Pixel 2XL we use 2 of them to draw the rounded corners. So, basically, you've got only 5."
¯\_(ツ)_/¯
Выступление Chet Haase и Romain Guy. Тут ты должен был стать заинтригован.
В докладе описывается весь Android Rendering Pipeline, но поскольку вместить это в 40 минут не получится, доклад выглядит как быстрое набрасывание названий разных классов и модулей. Тем не менее, вдумчиво его посмотреть я бы скорее советовал.
Наброшу несколько названий из доклада, чтобы ты понимал, о чём речь: Choreographer, VSync, UI Thread, RenderThread, SurfaceFlinger, BufferQueue, Hardware Composer (HWC).
Теперь несколько интересных фактов из сессии:
1. Начиная с Android Oreo можно использовать Bitmap.Config.HARDWARE, чтобы аллоцировать Bitmap напрямую на GPU и не тратить время на копирование. Недостаток: если серьёзно разойтись, можно получить пачку совершенно невнятных крашей из глубин фреймворка
2. Кусочек хинта (почему так - см. видео) - чем меньше Window объектов на экране, тем лучше
3. Метод invalidate(left, top, right, bottom) можно больше не дрочить - система уже умеет неплохо оптимизировать этот момент, а багов от его использования уйма
4. “RecyclerView is now able to do prefetching of items ahead of time”
5. Graphika app on Github - пачка примеров с использованием SurfaceFlinger, Surface, SurfaceView, media encoder, virtual displays.
6. adb shell dumpsys SurfaceFlinger лучше выполнять, когда что-то анимируется/меняется на экране, иначе можно получить не совсем точные данные из-за дополнительных оптимизаций
Подробности обо всём этом найдёшь по ссылке.

#rendering #window #surface #gpu
https://youtu.be/zdQRIYOST64