что такое anr на андроид
Русские Блоги
Подробный ANR оптимизации приложений для Android
Чтобы облегчить чтение, меня пригласили перенести серию статей по оптимизации производительности Android-приложений в исходные Nuggets.
Новую функцию «Сборник» в Nuggets можно использовать для создания серии эссе.
Давайте поговорим сегодня об ANR.
1, сталкивались ли вы с ANR
Во время использования Приложения вы могли столкнуться с такой ситуацией:
Поздравляем, это легендарный ANR.
1.1 Что такое ANR
1.2 Почему генерируется ANR
В Android за быстродействием приложения следят системные службы Activity Manager и Window Manager. Как правило, диалоговое окно ANR появляется в следующих двух ситуациях:
1.3 Как избежать ANR
Зная причину ANR, очень просто избежать ANR, всего одно правило:
Не выполняйте тяжелых операций в основном потоке (потоке пользовательского интерфейса).
На самом деле это связано с двумя проблемами:
2, анализ ANR
2.1 Получите файл трассировки, созданный ANR
При генерации ANR система сгенерирует файл traces.txt и поместит его в / data / anr /. Вы можете передатьadbКоманда для локального экспорта:
2.2 Анализ traces.txt
2.2.1 ANR, вызванный обычной блокировкой
Полученный файл tracs.txt обычно выглядит следующим образом:
Следующим образомGithubAppВ качестве примера возьмем код: ANR, созданный потоком принудительного сна.
Получите трассировочную информацию, все легко сказать.
Как в приведенной выше информации о трассировкеДобавлен комментарий на китайском языкеОн в основном объяснил, как анализировать файл трассировки:
Вышеупомянутая трассировка ANR относительно проста, и возможно, что вы не выполнили слишком трудоемких операций в основном потоке, но это все еще ANR. Это могут быть следующие две ситуации:
2.2.2 Полная загрузка процессора
Информация трассировки, которую вы видите сейчас, может содержать такую информацию:
Последнее предложение указывает:
Анализируя стек вызовов метода в это время, обычно обнаруживается, что метод имеет частые операции чтения и записи файла или чтения и записи базы данных в основном потоке.
2.2.3 Причина памяти
Фактически, память может вызвать ANR. Например, если в Приложении осталось мало памяти из-за утечки памяти, мы нажимаем кнопку, чтобы запустить большое изображение в качестве фонового действия, и ANR может быть сгенерирован. В это время информация трассировки может быть такой:
Как видите, свободной памяти осталось не так много.
2.2 Обработка ANR
Для трех различных ситуаций общая обработка выглядит следующим образом
Основной поток заблокирован
Создайте отдельный подпоток для обработки длительных блокирующих транзакций.
ЦП полностью загружен, ввод-вывод заблокирован
Блокировка ввода-вывода обычно означает, что чтение и запись файла или операции с базой данных выполняются в основном потоке, а также могут выполняться асинхронно, открывая дочерние потоки.
Недостаточно памяти
Увеличьте память виртуальной машины, используйте атрибут largeHeap, проверьте наличие утечек памяти (это обсуждается в главе об оптимизации памяти) и т. Д.
3, иди глубже
Никто не хочет решать проблему после того, как она возникла.
Разница между мастером и новичком заключается в том, что мастер знает, как избежать проблемы с самого начала. Итак, для проблемы ANR, какой уровень работы нам нужно сделать, чтобы ее избежать?
3.1 Какие места выполняются в основном потоке
3.2 Как можно использовать дочерние потоки
3.2.1 Запуск режима резьбы
Именно так Java реализует многопоточность.Существует два метода реализации, наследующие Thread или реализующие интерфейс Runnable:
Наследовать тему
Реализуйте интерфейс Runnable
3.2.2 Использование AsyncTask
Это уникальный способ для Android. AsyncTask, как следует из названия, означает асинхронную задачу.
3.2.3 HandlerThread
Способ объединения обработчика и потока в Android. Перед ним облако. По умолчанию handleMessage обработчика выполняется в основном потоке, но если я передаю цикл дочернего потока этому обработчику, handleMessage будет выполняться в этом дочернем потоке. В HandlerThread есть как раз такая комбинация:
3.2.4 IntentService
Служба работает в основном потоке, но IntentService работает в дочернем потоке.
Фактически, IntentService реализует модель HandlerThread + ServiceHandler.
Пример кода вышеупомянутого HandlerThread также взят изИсходный код IntentService.
3.2.5 Loader
Загрузчик данных, представленный в Android 3.0, может использоваться в Activity / Fragment. Он поддерживает асинхронную загрузку данных и может отслеживать источник данных для получения новых результатов при изменении данных. CursorLoader обычно используется для загрузки данных из базы данных.
3.2.6 Особое внимание
При использовании Thread и HandlerThread, чтобы эффект был лучше, рекомендуется установить приоритет Thread немного ниже:
Потому что, если вы не устанавливаете какой-либо приоритет, вы знаете, что создаваемый поток по умолчанию имеет тот же приоритет, что и поток пользовательского интерфейса. Поток с таким же приоритетом, планирование ЦП может по-прежнему блокировать ваш поток пользовательского интерфейса, Причина ANR.
Вывод
Приложение отвечает: как мы уменьшили количество ANR-ошибок в шесть раз. Часть 1, про сбор данных
Пожалуй, одна из худших проблем, которая может случиться с вашим приложением, — ошибка ANR (Application Not Responding), когда приложение не отвечает. Если таких ошибок много, они могут негативно влиять не только на пользовательский опыт, но и на позицию в выдаче Google Play и фичеринг.
В начале прошлого года количество ANRs в приложении Badoo превышало порог “Bad Behaviour” в Google Play. Поэтому мы собрали команду для решения этой проблемы и потратили несколько месяцев, экспериментируя с разными подходами. В результате мы смогли уменьшить количество таких ошибок более чем в шесть раз.
В этой серии из двух статей я расскажу о том, как нам это удалось, что дало наибольший эффект и как вы можете использовать эти подходы в своём приложении.
В первой части мы поговорим об основах: что представляет собой ошибка ANR и как её лучше отслеживать. Если вы уже знакомы с этой темой, предлагаю перейти ко второй части, в которой я расскажу о наших способах решения этой проблемы.
Что такое ошибка ANR?
Обычно любое приложение с графическим интерфейсом выполняет все связанные с ним операции и отрисовку в отдельном UI-потоке исполнения. Android не исключение: здесь в главном потоке приложения выполняется цикл, отвечающий за все действия с интерфейсом:
При использовании этого цикла крайне важно не выполнять длительные операции, потому что это напрямую повлияет на отзывчивость приложения. Если в главном потоке выполнять слишком много действий, это может привести к снижению частоты кадров или даже к зависаниям интерфейса:
Чтобы как-то идентифицировать такие ситуации, в Android ввели понятие ANR, с помощью которого система сообщает, что приложение зависло. Вот что об этом говорится в официальной документации:
Когда UI-поток Android-приложения блокируется слишком долго, выдаётся ошибка Application Not Responding (ANR).
ANR выдаётся, когда приложение находится в одном из этих состояний:
— на переднем плане находится Activity, приложение в течение пяти секунд не отвечает на входящие события или BroadcastReceiver, например нажатия на кнопки или касания экрана;
— на переднем плане нет Activity, ваш BroadcastReceiver не закончил исполнение в течение длительного времени.
Если ANR случается, когда на переднем плане находится Activity вашего приложения, Android показывает диалоговое окно с предложением закрыть приложение или подождать.
Довольно легко принудительно вызвать ANR, написав Thread.sleep() в любом обработчике интерфейса, например обработчик нажатия кнопки. После нажатия на кнопку вы увидите примерно следующее:
Наличие ошибок ANR в вашем приложении не только влияет на опыт его использования, но и, согласно документации Google, может повлиять на позицию в поисковой выдаче и продвижение в Google Play.
Чтобы снизить вероятность возникновения ANR, нужно всего лишь избегать выполнения длительных операций в главном потоке. Звучит вроде бы просто, но иногда не так легко определить корневую проблему, которая приводит к таким ошибкам. Поэтому довольно важно иметь хорошую систему мониторинга и репортинга ANR-ошибок.
Давайте посмотрим, какие существуют способы отладки ANR-ошибок и какие инструменты могут быть в этом полезны.
Отслеживание ANR
Локальный анализ
Самый простой случай — если у вас есть возможность стабильно воспроизводить ANR-проблему локально. Существует довольно много инструментов, которые могут помочь вам быстро найти источник проблемы.
Первое, что можно сделать, — это проверить дамп стек-трейсов для всех потоков (thread dump). Когда приложение перестает отвечать, Android создаёт дамп всех текущих потоков, который может помочь в анализе проблемы. Обычно он находится в директории /data/anr/, точный путь можно найти в Logcat сразу после сообщения об ошибке ANR.
Дамп потоков содержит стек-трейсы: вы увидите, в каком состоянии был каждый поток (например, какая строка выполнялась в конкретный момент времени). По сути, это состояние приложения на момент создания дампа.
Чаще всего причина возникновения ANR обнаруживается в стек-трейсе главного потока скорее всего, код в этом месте выполняется слишком долго. Если информации из этого стек-трейса будет недостаточно, можно попробовать обратиться к довольно неплохой документации от Google, где описываются основные причины, способы диагностирования и решения проблемы ANR.
Отслеживание с помощью Google Play
Google Play автоматически отправляет отчёты об ошибках ANR, если у пользователя включена такая опция. В консоли Google Play есть несколько метрик и инструментов для анализа ANR.
Во-первых, можно увидеть агрегированные графики с общим количеством ANR-ошибок за день. Также есть такая метрика, как ANR rate — отношение количества сессий за день, в которых возникала хотя бы одна ANR-ошибка, к общему количеству сессий за сутки. Для этой метрики задан порог в 0,47%, превышение которого считается «неудовлетворительным поведением» (“Bad Behaviour”) и может плохо повлиять на позицию приложения в Google Play.
Во-вторых, можно открывать отдельные отчёты об ANR-ошибках, сгруппированные по схожести на основе стек-трейса. Основные группы находятся в разделе Android Vitals. И это, вероятно, наиболее полезный раздел для выявления самых частых причин возникновения ANR-ошибок в вашем приложении.
Если вы активно используете консоль Google Play, вы могли заметить некоторые её недостатки. Например, к отчётам нельзя прикрепить дополнительную информацию, такую как логи для отладки. Также невозможно настроить логику группировки отчётов. Иногда система помещает в одну группу ошибки, возникшие по разным причинам, а иногда раскидывает по разным группам ошибки, у которых причина одна.
Всё это иногда затрудняет определение основных ошибок и поиск изначальных проблем. Что же можно сделать для улучшения ситуации?
Скачивание данных из Google Play
Для решения проблемы с логикой группировки можно попробовать скачать сырые отчёты об ANR-ошибках из Google Play для последующего ручного анализа. Раньше была возможность выгрузить эти данные из Google Cloud Storage, но несколько лет назад Google перестала поддерживать этот функционал:
Однако всё ещё можно просматривать отдельные отчёты в консоли. Но как нам экспортировать тысячи отчётов, не потратив при этом кучу времени на рутинную работу?
Существует много способов автоматизировать сбор информации с сайтов. Самый правильный и простой — получение данных через API, но, к сожалению, Google не предоставляет публичный API для получения отчётов. Одно из решений — эмулировать пользовательское поведение, автоматически кликая на ссылки и кнопки в браузере и сохраняя отображающийся текст.
Веб-скрапер можно реализовать с помощью популярного инструмента Selenium, который предоставляет простой интерфейс для взаимодействия с веб-страницами. Изначально он предназначался для создания автоматизированных тестов для веб-приложений и доступен на разных языках, включая Java и Kotlin.
Мы реализовали скрапер на Selenium и получили сырые отчёты об ANR-ошибках для одного из релизов. Благодаря этому нам удалось проанализировать их так, как не получилось бы сделать с помощью встроенных в консоль Google Play инструментов. Например, просто поискав в отчётах по ключевым словам “Application.onCreate”, мы обнаружили, что около 60% ошибок произошло во время выполнения метода Application.onCreate. При этом в консоли Google Play нет возможности получить такую информацию, так как отчёты разбиты по группам.
Внутренняя аналитика
Другой способ сбора дополнительных данных и проведения расширенного анализа заключается в настройке собственного репортинга ANR-ошибок. В прошлом мы уже экспериментировали с решением похожих проблем, настраивая репортинг крашей. Для того чтобы проводить анализ падений приложения, мы создали внутренний инструмент Gelato.
Его функциональность схожа с возможностями других инструментов для краш-репортинга, таких как Firebase Crashlytics и App Center, но ещё и позволяет нам полностью контролировать сохраняемые данные, менять логику группировки и применять сложную фильтрацию:
Это не реальные данные приложения Bumble, иллюстрация сделана просто для примера
Мы решили отслеживать в Gelato ещё и ANR-ошибки в надежде, что это поможет нам в поиске их причин. Для этого нам нужно было знать, когда приложение перестаёт отвечать. В Android 11 появился новый API, предоставляющий информацию о недавних причинах завершения процесса, но у большинства наших пользователей установлены более ранние версии ОС, поэтому нам требовалось найти другое решение.
И мы нашли простой способ, который часто используется для отслеживания зависаний главного потока исполнения: запустить watchdog-поток, который периодически будет пытаться выполнить задачу в главном потоке. Если задача не выполняется за определённый промежуток времени, то можно сохранить дамп текущего состояния потоков и отправить его в наш инструмент для анализа отчётов о падениях:
Такую логику реализует, например, библиотека, которой мы воспользовались для реализации репортинга в Gelato. Это позволило нам проводить более глубокий анализ данных и лучше интегрировать этот инструмент в нашу инфраструктуру. Например, теперь мы можем сравнивать зависания главного потока в разных вариантах в ходе A/B-тестирования.
Вот пример отчёта в нашей системе:
Это не реальные данные приложения Bumble, иллюстрация сделана просто для примера
Полезный совет: собирайте и отправляйте вместе с отчётом лог событий аналитики. Иногда это даёт возможность буквально пошагово воспроизвести проблему.
Если у вас нет своего решения для сбора отчётов о падениях приложения, вы можете настроить репортинг и в сторонние инструменты. Например, можно отправлять ANR-ошибки в App Center или Firebase Crashlytics, так как они предоставляют API для отправки кастомных крашей.
Но помните, что все эти отчёты нельзя считать полной альтернативой ANR-отчётам в Google Play (как мы говорили выше, в Android немного другие правила определения таких ошибок). Но в любом случае это может помочь получить общее представление об основных проблемах. Вполне вероятно, что если генерируется много отчётов о зависании главного потока исполнения в какой-то части вашего приложения, то в ней происходят и ANR-ошибки.
В завершение
Мы обсудили, что представляют собой ANR-ошибки и как их можно отслеживать. Во второй части статьи я расскажу о наших подходах к снижению ANR rate и о том, что из этого получилось.
Мы нашли секретный способ управлять фоновыми процессами в телефоне. Показываем
Работа смартфона — весьма сложный процесс, который не прекращается ни на минуту даже ночью, когда телефон лежит у вас под подушкой. Большинство процессов в смартфоне продолжают свою работу незаметно для глаз пользователя и могут потреблять достаточно большое количество ресурсов.
Многие пользователи ошибочно считают, что оперативную память «съедают» те приложения, которые остаются свернутыми, и если их закрыть, можно таким образом освободить бОльшую часть памяти.
На самом деле это не так. Свернутые приложения, находящиеся в режиме ожидания — это лишь верхушка айсберга. По сути – это только кэшированные данные, которые позволяют вам вернуться в приложение без потери последних данных. Закрыв их, вы сможете лишь немного освободить оперативную память телефона. Основная же часть ресурсов приходится на процессы или службы приложений. Именно они потребляют оперативную память и расходуют заряд батареи даже тогда, когда приложение закрыто.
Не все из них одинаково полезны, но есть и те, которые могут отвечать за безопасность устройства и его стабильную работу. Тем не менее, если телефон стал слишком задумчивым и вы замечаете, что он потребляет заряд батареи, даже находясь в режиме ожидания, вам будет полезно узнать как ограничить работу фоновых процессов и тем самым освободить оперативную память устройства, а также повысить его быстродействие.
Как управлять фоновыми процессами
Получить расширенный контроль над фоновыми процессами можно с помощью специальных инструментов, встроенных в операционную систему. В смартфонах Android эта возможность реализована с помощью скрытого меню для разработчиков.
Как включить параметры разработчика
Для того, чтобы активировать режим разработчика, необходимо перейти в Настройки телефона, открыть пункт «Сведения о телефоне», затем «Сведения о ПО» и несколько раз подряд нажать на пункт «Номер Сборки» до появления системного уведомления о том, что режим разработчика активирован.
Затем нужно вернуться назад, в главные настройки. Если все было сделано правильно, вы увидите, что внизу появился новый пункт меню «Параметры разработчика».
Как управлять фоновыми процессами
Для того, чтобы управлять фоновыми процессами, в меню «Параметры разработчика» необходимо найти пункт «Приложения». Здесь находится несколько параметров, отвечающих за работу фоновых процессов. Например, параметр «Вытеснение фоновых Activity» позволяет принудительно останавливать действия приложений после их закрытия (не рекомендуем включать), а параметр ANR в фоновом режиме — отображать фоновые уведомление в случае, когда какой-то процесс не отвечает.
Больше всего нас здесь интересует параметр «Лимит фоновых процессов», который позволяет выбрать какое количество процессов будет использоваться вашим смартфоном в фоне. Данное ограничение затрагивает в основном сторонние приложения, установленные пользователем, поэтому можно не переживать за работающие системные службы.
По умолчанию здесь установлено значение «Стандартное ограничение».
Для слабых смартфонов с небольшим количеством оперативной памяти можно ограничиться значением «не более 1−2 процессов». Для устройств «пошустрее» можно установить лимит «не более 4 процессов».
Полное отключение фоновых процессов может повлиять на корректную работу некоторых приложений, поэтому мы не рекомендуем использовать данную функцию по максимуму, особенно если вы активно пользуетесь мессенджерами, почтой и другими приложениями, которые требуют проверки уведомлений.
Заключение
Теперь вы знаете, как, изменив лимит фоновых процессов, можно существенно снизить потребление оперативной памяти и повысить общее быстродействие смартфона. Но помните, что использовать меню разработчика стоит только в том случае, если у вас наблюдаются существенные проблемы в работе устройства и не пренебрегайте этим правилом без крайней необходимости, в противном случае есть риск навредить работе гаджета.
Русские Блоги
Введение в Android ANR
Когда операция выполняется в течение определенного периода времени, и система не может ее обработать, произойдет ANR. Появится соответствующее диалоговое окно, которое не отвечает.
Существует три основных типа ANR:
Период тайм-аута трансляции делится на FG и BG, которые составляют 10 секунд и 60 секунд соответственно. То же самое определено в ActivitManagerService.java.
Время ожидания службы составляет 20 секунд, определено в ActiveServices.java.
Большинство возникающих ошибок ANR относятся к типу KeyDispatchTimeout.
3. Как запускается KeyDispatchTimeout
Код этой части в основном находится в handleTargetsNotReadyLocked () в InputDispatcher.cpp
Когда applicationHandle == NULL и windowHandle == NULL, это означает, что система не была запущена. Установите статус INPUT_TARGET_WAIT_CAUSE_SYSTEM_NOT_READY
При запуске системы сначала получите время ожидания, это время определяется в AvtivityManagerservice.java.
Затем установите статус INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY и вычислите период ожидания.
Когда наступает следующее событие, снова нужно судить, не было ли превышено предельное время отсутствия ответа. Если он превышает, выполнять связанные операции без ответа.
4. Что сделал ActivityManagerservice, когда произошла ошибка ANR?
В основном appNotResponding () из ActivityManagerservice.java
В основном выгрузка связанной информации в файл трассировки File tracesFile = dumpStackTraces (true, firstPids, processCpuTracker, lastPids, NATIVE_STACKS_OF_INTEREST);
Вывод информации из основного журнала Slog.e (TAG, info.toString ());
Импортируйте информацию об ANR в каталог dropbox addErrorToDropBox («anr», app, app.processName, activity, parent, annotation, cpuInfo, tracesFile, null);
Наконец, в соответствии с условиями определите, следует ли открывать диалоговое окно, которое не отвечает.
4. Как анализировать ANR на основе журнала
4.1 Как правило, сначала необходимо проанализировать главный журнал.
A) Сначала найдите ключевое слово «ANR» в главном журнале, чтобы определить, действительно ли произошло ANR.
Б) Проверьте, возникло ли в системе JE (исключение Java) или NE (собственное исключение) до ANR. Иногда некоторые ошибки ANR вызываются JE или NE.
C) Проверьте соответствующую информацию журнала, где происходит ANR.
Приведенная выше информация журнала интерпретируется следующим образом:
Время, когда происходит ANR: 05-01 23: 03: 24.603.
Номер процесса ANR: PID: 3109.
Информация о процессоре после ANR:
Согласно имеющейся информации журнала, основная причина ANR не может быть определена. Необходимо дополнительно проанализировать соответствующий файл трассировки.
Формат вывода ANR в главном журнале примерно следующий
Иногда информация о ЦП в основном журнале может приблизительно определить причину ANR, например, JE, NE, CPU 100% и т. Д.
4.2 Анализ файлов трассировки
Файл трассировки, разные системы имеют отличия, формат примерно такой:
а) Соответствующая информация в файле трассировки должна соответствовать основному журналу, чтобы гарантировать ту же проблему.
Существует взаимно однозначное соответствие с mainlog, указывающее, что файл трассировки, соответствующий ANR, имеет место.
c) Конечно, необходимо интерпретировать соответствующую информацию в трассировке.
tid означает идентификатор потока, tid = 1 означает, что поток запущен
Родной выражается как состояние потока. Состояние потока определяется в Thread.cpp. Подробности следующие
Название группы потоков: group = «main»
sCount = 1, (suspend cound) означает, что количество раз, когда поток приостанавливается, равно 1
dsCount = 0, (счетчик приостановки отладки) означает, что количество раз, когда поток приостанавливается из-за отладки, равно 0
obj = 0x74a26ff8, это адрес java-объекта потока
self = 0xf5007800, это адрес самого потока
sysTid = 3109, поток получает идентификатор локального потока в системе Linux (sysTid и PID совпадают)
nice = 0, это приоритет планирования потока
cgrp = apps, это группа, к которой принадлежит планирование потоков.
sched = 0/0, стратегия планирования потоков
handle = 0xf7701ec8, адрес функции обработки.
state = S, это состояние планирования
schedstat = (0 0 0), это Читать из / proc / [pid] / task / [tid] / schedstat, Три значения соответственно представляют время выполнения потока на процессоре, время ожидания потока и длину отрезка времени выполнения потока. Некоторые версии ядра Android не поддерживают эту информацию, все три полученных значения равны 0
utm = 4101, значение времени, используемое в пользовательском режиме потока ( Единица мгновенная).
stm = 573, значение времени планирования в режиме ядра ( Единица очень быстро ）。
core = 0, порядковый номер чашки потока, который запускается последним, то есть ЦП с порядковым номером 0 запускает поток.
stack = 0xff6fa000-0xff6fc000, указывающий диапазон адресов стека потока
stackSize = 8MB, что означает, что размер стека потоков равен 8M. Вычисляется по (0xff6fc000-0xff6fa000 = 0x2000 = 8M)
г) Далее идет стек вызовов функции.
В этой части, иногда, когда вы дополнительно анализируете конкретные причины ANR, вам необходимо дополнительно изучить соответствующий исходный код. Соответствующие файлы и функции могут быть явно размещены через стек вызовов.
Указывает, что соответствующее имя пакета является функцией release () android.media.MediaPlayer.
Вообще говоря, поток в верхней части файла трассировки является виновником ANR. Вот только пример.
Конечно, причины ANR различны, и необходимо провести конкретный анализ в соответствии с конкретными проблемами.
Вместо того, чтобы решать проблему ANR позже, лучше уделить больше внимания в процессе разработки, чтобы избежать ANR.
Ниже приведены некоторые реализации, требующие внимания.
a) Основной поток пользовательского интерфейса пытается выполнять только работу, связанную с пользовательским интерфейсом.
б) трудоемкие операции, такие как ввод-вывод, сетевое соединение, помещают его в отдельный поток для обработки
c) Попробуйте использовать Handler для обработки взаимодействия между потоками пользовательского интерфейса и потоками, отличными от пользовательского интерфейса.
Интеллектуальная рекомендация
Генерация аудио PCM-данных в файлы WAV и MP3 с использованием FFMpeg
Справочник статей 1. Получить кодировщик и создать контекст декодера 2. Создайте аудио поток и выведите контекст обертки 3. Записать необработанные данные в файл Формат упаковки аудио WAV может хранит.
3. Wu Weida Machine Учебное примечание Полные сухие товары (глава 3: Линейный регрессионный обзор)
1053 Путь равного веса (30 очков)
1053 Путь равного веса (30 очков) Given a non-empty tree with root R, and with weight Wi assigned to each tree node Ti. The weight of a path from R to L&n.
1020 Tree Traversals
Главная мысль: Укажите количество узлов двоичного дерева, а также пост-порядок, результат прохождения среднего порядка и результат прохождения уровня. Идеи решения проблем: Подзадача о бинарном древе.
[OpenStack] Neenron Добавить ICMP и SSH правила (веб-интерфейс)
Вам нужно подготовить правила группы безопасности перед конфигурацией. Поскольку группа безопасности по умолчанию не позволяет Ping ICMP-пакеты и SSH удаленного входа в систему. Вам необходимо вручную.