Pull to refresh
5
0
Алексей Илларионов@lsillarionov

Пользователь

Send message

Kotlin позволяет писать кросплатформеннй код. Тем временем кросплатформенный код:

val versionFile = if (os.isWindows) {
  File("gradle\\\\libs.versions.toml")
} else {
  File("gradle/libs.versions.toml")
}

Прикольно. Вижу на видео, что в том числе и тесты с assertk генерируются.
А firebender не пробовали? И как вообще оплачиваете это?

А изменения в GC кто-нибудь переводит?
Из блока tschatzl:
+ Незначительные улучшения в Parallel GC и Serial GC в приложениях, активно использующих JNI
+ незначительные улучшения в G1 GC при сборке old gen
+ небольшой баг в G1GC с Transparent Huge Pages

а, List.getFirst(), уже классическая подстава от Kotlin. Хорошо, что она описана в официальных гайдах по обновлению, есть в youtrack jetbrains.

Под каким пивом и почему один?

Это как раз про стек activity. Ситуация, когда A,B - destroyed, а C - resumed точно возможна (без перезапусков процессов и прочего).
Ниже код, которым эту ситуацию можно воспроизвести. Суть: запускаем друг за другом 3 activity и в каждой фоном забиваем 3/4 свободной памяти:

val lowmemThreshold get() = 3 * Runtime.getRuntime().maxMemory() / 4
val Activity.activityNo get() = intent.getIntExtra("ACTIVITY_NO", 1)

class MainActivity : Activity() {
    val garbage: MutableList<ByteArray> = LinkedList()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        Log.i("MEMTEST", "onCreate: $activityNo")

        // Запускаем стек из activity 1-2-3
        if (activityNo < 3) {
            Handler(Looper.getMainLooper()).postDelayed({
                startActivity(Intent(this@MainActivity, MainActivity::class.java).apply {
                    putExtra("ACTIVITY_NO", activityNo + 1);
                })
            }, 5000)
        }

        // В каждой activity фоном медленно забиваем 3/4 памяти
        object : Thread() {
            override fun run() {
                sleep(1000)
                repeat(((lowmemThreshold + 1048575) / 1048576).toInt()) {
                    garbage += ByteArray(1048576)
                    sleep(10)
                }
            }
        }.start()
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.e("MEMTEST", "onDestroy: $activityNo")
    }
}

Если запустить, то в логах увидим следующее:

onCreate: 1
onCreate: 2
onDestroy: 1
onCreate: 3
onDestroy: 2

Т.е. activity 1,2 - destroyed, а 3 - resumed.
Статус стека activity также можно проверить через adb коммандой adb shell dumpsys activity -p <package_name> activities:

adb shell dumpsys activity -p testactivitybackgroundkill activities | grep -e 'Hist #' -e 'state='
* Hist #2: ActivityRecord{2ce6967 testactivitybackgroundkill/.MainActivity t45}
    state=RESUMED stopped=false delayedResume=false finishing=false
* Hist #1: ActivityRecord{cec9b87 testactivitybackgroundkill/.MainActivity t45}
    state=DESTROYED stopped=true delayedResume=false finishing=false
* Hist #0: ActivityRecord{bda9160 testactivitybackgroundkill/.MainActivity t45}
    state=DESTROYED stopped=true delayedResume=false finishing=false

А логах adb logcat буфера events можно отследить события срабатывания кода, уничтожающего activity:

adb logcat -b events | fgrep 'low-mem'
I wm_destroy_activity: [0,198873440,45,testactivitybackgroundkill/.MainActivity,low-mem]
I wm_destroy_activity: [0,216832903,45,testactivitybackgroundkill/.MainActivity,low-mem]





Выглядит как очень удобная штука. Может забрать на себя часть задач, решаемых при помощи async-profiler

Некоторые считают, что в Android нет механизмов освобождения памяти, которые останавливают фоновые Activity в пределах процесса при нехватке ресурсов. Т.е. механизмы освобождения памяти работают только между процессами. На самом деле, такие механизмы есть:

  • В настройках разработчика отладочная опция "Do not keep activities" включает уничтожение фоновых activity

  • Система может инициировать убийство фоновых Activity, если занято больше 3/4 от максимального разрешенного размера хипа (по этому пункту могу дать ссылку в исходном коде AOSP и пример, как я воспроизвел этот случай).

Ох и духота же с этими "можно называть MVI", "нельзя называть MVI"…
Хотелось бы теперь ещё статью про Redux и его отличие от MVI со своими именами.
Ну и про ELM vs всё остальное UDF-подобное.

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

А приложение на Android на React Native? Как оно ощущается, когда одновременно делаешь и сайт и приложения?

Там не UnknownHostException, а "Typically, an UnknownHostException or other socket-related IOException".
Сеть, судя по всему, просто на другом уровне отключается.

Меня забавляет, что Яндекс использует собщение через локалхост (стандартный механизм IPC для Unix систем) уже больше 7 лет, а обратили внемение на это только сейчас.
Не удивлюсь, если у них даже были публичные доклады на эту тему в русскоязычном сегменте

А фишки типа Settings Sync будут? И планируется ли выделять ресурсы на поддержку и постоянную актуализацию Android-плагина?

invokeDynamic, classLoader'ы — это всё интересно, но вы так и не рассказали, почему при первом тесте он так долго загружается

В Gradle для решения проблемы времени старта запускается Gradle Daemon.
Там достаточно сложный configuration cache и в реализации Gradle используются возможности, которые могут быть не совместими с CDT: свои ClassLoader'ы, измененный bootstrap classpath, свой instrumentation -javaagent.
Плюс в сборке типового проекта часто используются множество изолированных Classpath у разных плагинов и тасок, они очень часто часто меняются при обновлениях плагинов или просто кода сборки.
Актуален ли вообще с Gradle CDT, ACDT, или может AOT Class Loading из Java24?
И почему allprojects + options.forkOptions.executable? С JVM Toolchains не получится завести?
С fork очень сильно просядет производительность, сомнительно, что её удастся покрыть оптимизированным быстрым стартом

JDK-8343417 и JDK-8343823 в списке по моим репортам.
Приятно удивило, как быстро иногда исправляются ошибки в Java. Казалось, что это очень большой проект, в котором крайне сложно вносить любые изменения.

Сложно, наверное, ядро в паблике разрабатывать. Каждое твое незначительное, достаточно рядовое замечание, обсуждают всем миром

Не стоит называть Base64 шифрованием, дак и зачем он у вас, учитывая, что все протоколы бинарные.
Почему у vp9 63.5%, просто потому что это приоритетный используемый формат и его больше всего, или действительно самый проблемный?

1

Information

Rating
Does not participate
Location
Чебоксары, Чувашия, Россия
Date of birth
Registered
Activity

Specialization

Разработчик мобильных приложений