Создание оптимизированной системы управления и мониторинга Watermelon Caton & ANR

задний план

Caton и ANR — это проблемы, которые сильно влияют на взаимодействие с пользователем в различных приложениях, и их анализ и управление всегда были общей темой. В прошлом расследование проблем Caton и ANR в основном основывалось на отчетах о стеке и файлах traceInfo, и с помощью этой информации восстанавливалась ситуация проблемы на месте. Однако на практике обнаруживается, что время захвата стека при существующем механизме мониторинга позже, чем возникает проблема.В большинстве случаев стек получен в определенный момент после возникновения проблемы.Случайность сильная, что невероятно и Отражая реальную локальную ситуацию проблемы, одна и та же проблема может быть агрегирована в разные стеки, и невозможно четко классифицировать и локализовать проблему, что заставляет многих разработчиков понимать принцип, но когда речь идет о конкретном случае, у них нет возможности начать, и расследование не имеет направления или даже из-за стека.Агрегация невероятна и попадает в неправильное направление расследования, что неэффективно. С другой стороны, большинство инструментов, которые могут точно измерить производительность, приведут к серьезным трудоемким проблемам и не могут использоваться в сети, а проблемы с производительностью в основном возникают в сложных онлайн-сценариях пользователей. Следовательно, как эффективно предотвращать и лечить Caton & ANR — это проблема, которую мы должны рассмотреть.

Статус управления Caton и ANR и болевые точки

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

Катон и статус ANR

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

В начале управления среднее недельное соотношение пользователей, страдающих заиканием, достигло около 10 ‰, а затронутые пользователи в среднем страдали заиканием 5 раз.Нормальный высокий уровень пользователей, затронутых ANR, оставался на уровне около 6 ‰, и средний ANR затронутых пользователей был в 2 раза Эти данные плохо оцениваются в основных приложениях компании.

Скрининг проблем показал, что проблемы сосредоточены в голове и разбросаны как единое целое. ТОП-2 проблемы составляют 30% от общего числа, а остальные проблемы разбросаны по 60 000 различных агрегаций стека. Наблюдайте за этими различными агрегациями стека. , ТОП 2 проблемы ложатся на системный стек, а многие мелкомасштабные агрегации не являются интуитивными трудоемкими точками.Эти явления доставили много хлопот нашей первоначальной работе по управлению, а ТОП проблемы, на долю которых приходится большая доля, даны приоритет.Высший уровень, но как вызвать, как оптимизировать, как вырезать проблему, разбросанную по 60000 агрегатов стека.

Кроме того, в течение длительного времени отсутствовали эффективные дополнительные возможности предотвращения и контроля проблем. На этапах разработки и тестирования нет специального тестирования, проблемы редко выявляются, а также отсутствуют планы непрерывного наблюдения и возможности позиционирования повторения проблемы. и только в случае новой агрегации стека Активировать аварийный сигнал В реальной работе обнаружено, что политика аварийных сигналов срабатывает редко и в большинстве случаев не может быть использована.

Механизм и проблемы обнаружения Caton и ANR

Во-первых, давайте взглянем на стековое представление ТОП-2 вопросов.

TOP 2 проблемы агрегированы в системных стеках nativePollOnce и nSyncAndDrawFrame, что составляет 20% и 10% соответственно.nativePollOnce — это функция распределения сообщений в рамках механизма сообщений основного потока, а nSyncAndDrawFrame — это базовая функция рисования страницы. это не проблема, поэтому мы провели ряд рутинных анализов и попыток на ранней стадии. Возьмите в качестве примера nativePollOnce из TOP 1. В первую очередь обычно подозревают, что сам метод трудоемкий, и анализируется логика выполнения метода на уровне Java и нативном уровне.

Видно, что на нативном уровне есть вызов epoll_wait, и никаких проблем не обнаружено при проверке методов, связанных с перехватчиками, на уровне C++. Затем мы создаем существующую idleTask на уровне Java, чтобы задача бездействия выполнялась без приостановки, когда очередь сообщений простаивает, и проверка показала, что проблема все еще существует. Посмотрите еще раз на логику уровня Java.

Эта часть посвящена обработке барьеров синхронизации. Асинхронное обновление пользовательского интерфейса может вызвать многопоточность барьеров синхронизации и не может быть устранена. Эта возможность исключается после проверки. Расследование до сих пор не выявило четкой причины проблемы.Вторая по рангу проблема nSyncAndDrawFrame аналогична этой.После скрытого расследования ссылки на вызовы при многих проблемах nSyncAndDrawFrame не отнимают много времени.

На этом этапе давайте вернемся и посмотрим на текущий механизм мониторинга. Для обнаружения и анализа Caton и ANR мы долгое время полагались на возможности, предоставляемые инструментами NPTH. Для мониторинга застрявших сообщений используется процесс планирования перехвата сообщений, и время скрыто до того, как сообщение будет выполнено.Когда время, затрачиваемое на превышение порогового значения, оно считается застрявшим, и будут выполняться захват стека и отчетность. Мониторинг ANR осуществляется посредством регулярного опроса, взаимодействия с AMS каждые 500 мс в потоке и оценки того, происходит ли ANR, с помощью информации об ошибке AMS, и когда определяется, что ANR происходит, стек фиксируется, и информация сообщается.

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

Для застрявших, поскольку сообщение определяется как измерение, когда обнаруживается, что сообщение застряло, полученный стек представляет собой ссылку стека от начала сообщения до текущего выполнения метода. На самом деле, в сообщении могут выполняться тысячи методов, и времязатратный момент, скорее всего, будет длительным накоплением другого метода или нескольких методов в сообщении, что приводит к истечению времени ожидания сообщения, что мы не можем подтвердить. Таким образом, знание того, что сообщение занимает много времени, очень полезно для устранения проблемы, и мы все еще не можем найти конкретную точку, требующую много времени, которая может быть использована, что делает невозможным быстрое использование текущих застрявших данных.

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

На этой основе мы получаем доступ к диаграмме последовательности планирования, которая представляет собой выполнение сообщений в основном потоке MessageQueue, включая выполненные сообщения, текущие сообщения и ожидающие сообщения, о которых можно сообщать вместе при возникновении ANR. Давайте рассмотрим случай агрегации nativePollOnce с помощью диаграммы последовательности планирования:

Видно, что сообщение впереди занимает 42 с, а текущее сообщение в сообщенном стеке занимает очень мало времени, и ANR не имеет ничего общего с текущим сообщением.

Это проблема ANR, вызванная многократным накоплением времени, и текущее время сообщения также очень мало. С помощью диаграммы последовательности планирования мы можем сделать вывод, что такие проблемы, как nativePollOnce, скорее всего, не имеют ничего общего с текущим стеком. Агрегирование в nativePollOnce связано с тем, что планирование сообщений является функцией с наибольшей частотой выполнения. частота падения стека на nativePollOnce является самой высокой.Эта информация о стеке бесполезна для нас для решения проблемы, поэтому можем ли мы решить проблему с помощью диаграммы последовательности планирования?

К сожалению, ни то, ни другое не может. На диаграмме последовательности планирования показана ситуация, требующая много времени на уровне сообщения.Подобно остановке, даже если мы знаем, какое сообщение требует много времени, в сообщении выполняется много методов, и многие из них являются сообщениями системного уровня. Конкретные найти не можем, метод отнимает много времени. Кроме того, одноточечный стек не может локализовать проблему.В этом случае, независимо от того, занимает ли текущее сообщение много времени или нет, проблема не может быть обнаружена, потому что причина проблемы тесно связана с затратой времени. Сообщение, которое было выполнено.

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

Предотвращение и лечение дополнительных проблем

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

Что касается нарастающей проблемы, то ранее не существовало эффективных методов предотвращения и контроля, а единственные автономные тесты и онлайн-сигналы тревоги для новых проблем в оттенках серого/онлайн-проблем малоэффективны. Автономные тесты — это в основном функциональные тесты и серия автоматизированных тестов на этапе разработки и тестирования. Эти тесты не предназначены для решения проблем с производительностью, таких как Caton и ANR. Они не являются чувствительными и недостаточно озабочены сопутствующими проблемами. моделей и сценариев, которых они могут достичь, недостаточно, в результате чего выявляется мало проблем, отсутствуют необходимые аналитические возможности и инструменты, а информации на месте очень мало.

Новая стратегия оповещения о проблемах в оттенках серого/онлайн не очень точна и непригодна для использования. Тревога будет срабатывать только при возникновении новой агрегации стека.Из анализа текущей ситуации видно, что, кроме отдельных взаимоблокировок, циклических ожиданий и т. д., стеки в большинстве случаев имеют большую случайность, либо падают в nativePollOnce/nSyncAndDrawFrame и т. д. Потребляемый системный стек либо разбросан по разным другим бизнес-стекам, а информация, полученная аналитиками, в основном неправдоподобна, поэтому весьма вероятно возникновение следующих ситуаций:

Настоящая причина агрегации стека, которая вызывает тревогу, не нова.
Проблемы, вызванные новыми проблемами, не вызывают тревоги
Проблема не может быть поглощена

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

Наш призыв

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

Для задач с одной точкой реальный стек не может быть расположен.
Для проблем, требующих много времени, проблемная сцена не может быть восстановлена.
Не существует эффективных средств предотвращения и контроля возрастающих проблем.

Из-за неточности захвата стека существующий стек проблем на месте не имеет большого значения, будь то для одноточечного устранения неполадок или многоэтапного устранения неполадок, требующего много времени, и невозможно правильно восстановить информацию на месте, из-за чего наша работа по устранению неполадок и оптимизации продвигается медленно или даже отклоняется от нормального направления. Существующие инструменты, такие как Caton и диаграммы последовательности планирования, используют Message в качестве статистической детализации и не могут обеспечить действительно оптимизированное и требующее много времени позиционирование, в то время как существующие инструменты с Method в качестве статистической детализации могут работать только из-за проблем с производительностью и стабильностью в автономном режиме. С этой целью мы надеемся иметь набор инструментов трассировки методов, которые могут эффективно работать в режиме онлайн для обнаружения зависания и ANR.С учетом того, что метод занимает много времени, поскольку статистическая детализация, текущее и предыдущее выполнение метода пользователем при зависании/ANR Ситуация, отнимающая много времени, чтобы мы могли полностью представить время, когда возникла проблема, и ситуацию, отнимающую много времени при выполнении метода, в предыдущий период, а также эффективно и четко определить суть проблемы.

Для предотвращения и лечения дополнительных проблем, поскольку существующие возможности не могут определить, являются ли новые проблемы новыми, слишком много энергии тратится в неправильном направлении, а настоящие проблемы не могут быть найдены и переведены в онлайн.По этой причине нам необходимо создавать инкрементальный Система предотвращения и контроля проблем, десистематизированная и предварительно обработанная для завершения мониторинга дополнительных проблем, предоставления эффективной информации и распространения проблем. систематизация может быть более эффективной и всеобъемлющей Ограничьте обнаружение проблем и в то же время объедините создание системы предотвращения и контроля для дополнительных проблем с созданием возможностей мониторинга и решения проблем для создания полностью автоматизированной системы. , предварительно позиционированные, всеобъемлющие в обнаружении проблем, простые в использовании и своевременно распространяемые.

Построение системы мониторинга

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

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

В ответ на вышеуказанные болевые точки и требования мы реорганизовали наши идеи, сравнили преимущества и недостатки существующих решений и разработали высокопроизводительный онлайн-инструмент трассировки на основе метода. Исходя из этого, мы выполнили программную модернизацию и комплексное построение системы для ANR и Caton.

Введение в схему управления ANR на основе Sliver

Для ANR мы хотим получить запись стека некоторое время назад, когда происходит ANR, чтобы быстро определить появление стека вызовов метода, занимающего много времени.

Sliver использует выборку для регулярного получения стеков.Мы включаем возможность мониторинга Sliver при запуске приложения и вводим разные значения выборки в соответствии с разными моделями.Обычно значение выборки на недорогих машинах будет больше, а значение выборки компьютеры высокого класса будут меньше.Некоторые, чтобы свести к минимуму влияние получения самой трассировки на производительность, Sliver периодически захватывает стек и выполняет агрегирование и кэширование полученного стека, чтобы различать взаимосвязь между различными стеками. В то же время зарегистрируйте обратный вызов ANR через интерфейс NPTH.Когда происходит ANR, функция обратного вызова будет сбрасывать кешированный стек в файл и сообщать файл Sladar с другой информацией ANR, чтобы мы могли использовать точную анализ в случае анализа местонахождение проблемы с информацией о трассировке, на следующем рисунке показан общий рабочий процесс для ANR.

Мы запускаем этот набор процессов, собираем соответствующие дела и сравниваем соответствующую информацию в одном и том же деле.

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

В настоящее время программа была нормально открыта в автономном режиме, в оттенках серого и в общедоступных каналах тестирования, и эффект очевиден, как показано ниже:

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

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

Решения проблемы Катона

В отличие от проблемы ANR, стандарт проблемы заикания определяется нами. Заикание и наложение нескольких заиканий являются основными элементами, вызывающими ANR и влияющими на производительность. Существующий мониторинг заикания может получить только одну ссылку стека. невозможно полностью восстановить текущую сцену застрявшего поколения, исходя из этого, мы разработали систему мониторинга залипания на основе Sliver trace.

Сначала посмотрите на общую блок-схему:

В основном включает два аспекта:

Схема обнаружения

При мониторинге замораживания вам сначала необходимо включить возможности записи Trace Щелевицы. Образцы Щетки и записывает информацию о выполнении трассировки и выполняет агрегацию разной и кэширования захваченного стека.

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

стратегия агрегации стека

Когда происходит заморозка, нам нужно подготовить данные для заморозки.Эта часть работы выполняется в подпотоке на терминале, в основном выгружая трассировку в файл и фильтруя стек для отчета агрегации. Делится на следующие этапы:

Получите кэшированную информацию о трассировке основного потока и выгрузите ее в файл.
Затем прочитать информацию трассировки из файла, выполнить трассировку из ближайшего стека методов в соответствии с форматом данных, найти всю информацию трассировки, содержащуюся в текущем сообщении, записать полную трассировку текущего сообщения в файл трассировки для загрузки и удалить оставшуюся информацию следов.
Пройдите текущую трассировку сообщения, отфильтруйте самую продолжительную по времени функцию каждого уровня стека вызовов функций в соответствии с условием (время выполнения метода > пороговое значение времени выполнения метода и время выполнения метода является самым трудоемким на этом уровне стек) и, наконец, сообщить об этом. Таким образом, каждый шаг в стеке функций занимает больше всего времени, а самый нижний метод — это последний метод, время которого превышает пороговое значение.

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

После выхода в интернет мы сравнили эффект с оригинальной системой Caton:

Приведенные выше три рисунка представляют собой исходный список заиканий, текущий список заиканий и трассировку для проблемы размытия по Гауссу. В исходном списке отчетов о заиканиях проблемы были разбросаны по разным стекам. Это связано со случайным захватом стека при возникновении заиканий, но текущий список заиканий объединяется в одну ссылку стека. Это потому, что мы берем каждый слой Функции которые занимают больше всего времени в стеке, объединяются в стек функций, и достоверность стека функций также может быть проверена с помощью трассировки, которая может более точно определить причину проблемы. В то же время трассировка подробно показывает цепочку вызовов функций, предоставляя возможность глубоко проанализировать проблему.

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

В настоящее время система обнаружения зависаний нормально работает при общедоступном тестировании и автономной автоматизации, и все выходные данные представляют собой онлайн-проблемы.

Наращивание потенциала до обнаружения

Решения для обнаружения Caton и ANR, основанные на возможностях Sliver, могут значительно повысить эффективность решения проблем. Далее нам нужно подумать, как использовать эти две возможности в обычном режиме для решения наших ежедневных проблем с запасами и дополнительных проблем. Особенно важно уменьшить влияние на пользователей, особенно для продвижения стадии экспозиции проблемы. С этой целью мы осуществляли строительство по следующим направлениям.

Офлайн-стресс-тест

В настоящее время тестовая платформа предоставляет несколько автоматизированных тестовых заданий.Большинство из этих заданий автоматически проверяют функции приложения обходным способом.Для всех функций с одинаковым приоритетом мы интегрируем и упаковываем наши возможности обнаружения ANR и возможности обнаружения зависаний.Триггер автоматизированные задания для создания связанных киосков и случаев ANR.

Проанализировав и сравнив эти случаи, выяснилось, что ТОП-проблемы, о которых сообщается в оффлайне, сильно отличаются от онлайн-проблем, которые не соответствуют реальным сценариям использования пользователями. Некоторые крупномасштабные случаи, обнаруженные в автономном режиме, имеют очень небольшую величину в онлайн-сценариях и затрагивают небольшое количество пользователей, в то время как некоторые онлайн-случаи, затрагивающие большее количество пользователей, редко регистрируются в автономном режиме. Анализ Это связано с тем, что схема обходного тестирования не соответствует реальному поведению пользователя, что заставит нас дать неправильный приоритет в продвижении решения проблемы и не может правильно определить те проблемы, которые действительно велики по масштабу, затрагивают многих пользователей, и имеют высокий приоритет Общий оптимизированный ритм.

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

В то же время, используя интерфейс тестовой платформы, мы построили полностью автоматизированный механизм тестирования: на основе ветки последнего релиза платформа упаковки периодически запускается для упаковки -> настроить канал как выделенный канал для тестирования производительности -> выполнить автоматические тесты для генерации данных после успеха.

Онлайн (beta_version и оттенки серого)

Ведь автономное автоматизированное тестирование ограничено моделями, сценариями и другими условиями, и найти какие-то проблемы с персонализацией пользователей непросто. Поэтому онлайн-обнаружение проблем особенно важно. И beta_version, и оттенки серого — это настоящие пользовательские каналы, которые могут охватывать различные сценарии, но они разные, у beta_version меньше пользователей, но они более активны. Для этого мы интегрировали схему сбора данных Caton и ANR в канал beta_version. В то же время из-за большого количества пользователей канал в градациях серого может предоставить более полные сценарии и пользователей.Мы также интегрировали решение ANR в канал в градациях серого.Однако из-за относительно высокой частоты зависаний, учитывая характеристики многие пользователи оттенков серого, мы еще не открыли стоп-кадр каналов оттенков серого.

Наращивание динамической емкости

Много раз вам нужно динамически исследовать проблемы, с которыми вы сталкиваетесь с онлайн-пользователями.Хотя соответствующие возможности исследования полны, это не принимает во внимание множество соображений. Для таких проблем необходимо иметь исправление, но относительно легкое решение, которое может динамически выдавать возможности мобильному телефону пользователя.

Чтобы улучшить возможности динамического исследования клиента Watermelon для Android, все общие возможности инкапсулированы в модуль, планирование и распределение событий выполняются через унифицированный интерфейс в сочетании с возможностью доставки и загрузки подключаемых модулей для достижения точной доставки. возможностей расследования на любой мобильный телефон.

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

Его можно разделить на три части: хост, плагин и компонент:

Хост-контроллер выполняет извлечение конфигурации, инициализацию подключаемого модуля, предварительно встраивает интерфейс для вызова хостом и передает инструкции распространителю подключаемого модуля в соответствии с вызовом и отражением динамической конфигурации.
Диспетчер подключаемых модулей получает инструкции хоста, соответственно загружает различные компоненты и выполняет различные операции.
Компоненты — это независимые модули, которые обеспечивают определенные реализации возможностей и выполняют определенные функции.

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

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

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

Построение связи потребления данных Caton

Вышеупомянутые части использовались всесторонне с точки зрения онлайн-, офлайн- и динамических возможностей в сочетании с решением Caton & ANR, создавая данные, которые легко использовать и потреблять Далее нам необходимо улучшить процесс потребления и повысить эффективность решения проблем.

Для вывода данных наши услуги обработки данных по свету, согласно APM_OPEN Открыть интерфейсы, мы можем получить задание соответствующую списку данных CATON & ANR, пройти список, соответствующую информацию для каждого случая строчки, особенно CATON The Trace File Link, Предотвращение недостатков длинной ссылки на загрузку файлов, снижение оптимизации затрат, после чего информация будет распределена с соответствующей последующей группой. Между тем, в модифицированном Sladar укажите модуль владельца или владельца в соответствии с соответствующим кодом для последующей необходимости. Эффект следующий:

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

В целом, от разработки базовых инструментов до оптимизации схемы Caton & ANR, создания онлайн- и офлайн-возможностей динамического предварительного обнаружения и ссылки на конечное потребление, Xigua завершает весь процесс Caton & ANR. система мониторинга Замкнутый цикл играет важную роль в решении существующих проблем, предотвращении и контроле дополнительных проблем, отслеживании единичных проблем и общем управлении производительностью.

Знакомство с типичными случаями

Случай ошибки агрегации стека

Для задачи nativePollOnce из TOP 1 для анализа было собрано несколько образцов трассировки.Производительность стека выглядит следующим образом:

проблема с базой данных

По трассировке видно, что основной поток фактически выполняет операции с базой данных и быстро продвигает решение.

проблема с dex2oat

Из трассировки видно, что это на самом деле ClassLoader.Он выполнялся более 20 с. Глядя на исходный код, выясняется, что это ссылка вызова типа PluginClassLoader.->....dex2oat.. ..->Выполнение.exec.

Основываясь на приведенном выше стеке, мы знаем, что проблема вызвана запуском операции dex2oat основного потока, когда файл oat не проверяется при загрузке плагина. Поэтому мы заранее оцениваем, является ли файл oat допустимым, когда инициализируется экземпляр подключаемого модуля.Если он недействителен, конечный автомат подключаемого модуля будет прерван, установлен в состояние недоступности, а продукт dex2oat будет регенерирован асинхронно.

Живые вопросы

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

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

С этой целью мы оптимизировали с двух сторон:

На уровне хоста определите время двух типов плагинов, избегайте преждевременного и бессмысленного подтягивания плагинов и загружайте их по запросу.
Продвигайте бизнес-сторону и существенно оптимизируйте время инициализации.

Нестандартный случай

Проблема с копированием JSON

Есть класс таких проблем, посмотрите в стеке когда JSONObject clone = new JSONObject(origin.toString), в котором конвертируется тип float.

Увидев первое впечатление от этого стека заключается в том, что метод не является трудоемким, компенсацией стека, а затем можно увидеть соответствующую трассировку, это действительно очень много времени.

Глядя на нижний слой трассировки, все это повторяющиеся битовые вычисления.Предполагается, что операция, вызванная сверхдлинным номером типа double, слишком длинная.Соберите соответствующий json в оттенках серого и обнаружите, что таких данных нет. Когда предполагается, что это toString, он преобразует сохраненные двойные данные в строку, а затем преобразует строку в двойную, когда она новая.Эти два преобразования могут вызвать проблемы с точностью, в результате чего значение двойного становится очень длинным числом, таким как 1.9999999999999999999999, а потом вычисление занимает очень много времени, в результате получается ANR.

С этой целью вышеприведенная логика JSONObject clone = new JSONObject(origin.toString) изменена для обхода содержимого источника для копирования и копирования, и эта проблема исчезает после проверки.

Проблема с хэш-картой

О классе проблем сообщается в стеке в методе HashMap.remove.

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

Из трассировки ясно видно, что он действительно застрял в HashMap.remove более чем на 40 сек. В сочетании с нагрузкой на процессор это не вызвано отсутствием планирования.

深入分析，发现在多线程操作 HashMap 时，若发生扩容，可能会产生循环链表，进而触发死循环，最终采用 ConcurrentHashMap 后解决该问题。 Смотрите также:Woohoo.Краткое описание.com/afraid/from 72Afan 03AB…

Дело Катона

проблема с анимацией

Есть проблема типа анимации.Сама анимация представляет собой простую flash-анимацию без сложной логики внутри.Есть сомнения в достоверности ее трудоемкости,но с помощью графика трассировки мы можем увидеть:

Действительно, в анимации есть серьезная трудоемкая ситуация, и моменты затрат времени четко отображаются. На этом этапе посмотрите на эффект агрегации стека исходного мониторинга заикания и текущего мониторинга заикания:

На двух приведенных выше рисунках соответственно показан эффект агрегации стека исходного мониторинга заикания и текущего мониторинга заикания.Можно видеть, что стек исходного мониторинга заикания агрегирован в несколько разных ссылок стека, что также связано со случайностью его захват стека. Это отвлечет нас и сделает невозможным определение реальной причины проблемы. В нашей существующей зависшей системе стек очень точно агрегируется в уникальную ссылку стека. С помощью трассировочной информации точность стека тоже можно проверить. На основании этого мы можем точно определить и проанализировать проблему.

Проблема со страницей сведений

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

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

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

Последующее планирование Caton и ANR

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

Проблемы Caton и ANR часто не являются независимыми и тесно связаны с вводом-выводом, памятью, нагрузкой и другими факторами самого мобильного телефона.В настоящее время мы не добавили статус самого мобильного телефона в систему мониторинга.
Проблемы CATON & ANR часто вызываются дочерней резьбой, в ожидании Binder ждать и т. Д., И наши возможности мониторинга не могут эффективно охватывать их в настоящее время.
По мере того, как в проекте запускается все больше и больше нативного кода, влияние также увеличивается.В настоящее время наш механизм мониторинга можно отследить только до уровня java, а ссылку на проблему на нативном уровне невозможно эффективно найти.Проблемы класса по-прежнему недостаточно обеспеченными ресурсами и неэффективными.
По мере того, как динамические возможности APP становятся все сильнее и сильнее, увеличивается количество различных динамических неперцептивных онлайн-сценариев, и связанные с ними проблемы трудно найти в автономном режиме или в оттенках серого, что ставит перед нами новые задачи.Во-первых, построение конфиденциальности данных, своевременное обнаружение проблем , во-вторых, создать возможность атрибутировать онлайн-проблемы, которые можно отнести к конкретным онлайн-причинам, а также к конкретным сценариям и причинам проблем.

Основываясь на этих все еще существующих проблемах, далее мы рассматриваем возможность выполнения следующей работы:

Улучшайте мониторинг и управление важной информацией о состоянии, такой как ввод-вывод, память и загрузка мобильного телефона, выявляйте часто повторяющиеся, трудоемкие и ненормальные операции ввода-вывода, памяти и загрузки, а также косвенно оптимизируйте зависания и ANR, оптимизируя эти базовые состояния. .
Объединив возможность мониторинга зависания с вводом-выводом, памятью и нагрузкой мобильного телефона, разделите совокупность проблем на измерения ввода-вывода, памяти и нагрузки и проясните состояние системы мобильного телефона и работу самого Метода.
Улучшите систему мониторинга для многопоточности и проверки вызовов Binder, попытайтесь получить часть потока, используемого для помощи в обнаружении проблем с трассировкой поля, и вызовов для тестирования Binder, того же типа Binder для оптимизации операций высокочастотного извлечения.
Попытки назвать нативным кодом для обнаружения, для мониторинга ссылки нельзя заполнить до короткой контактной пластины нативный слой, для повышения эффективности и емкости местоположения неисправности.
Создайте возможности обнаружения колебаний данных в Интернете, повысьте чувствительность и эффективность обнаружения колебаний данных, создайте возможности проверки атрибуции для динамических онлайн-функций, отсеивайте динамические онлайн-функции в пределах определенного диапазона колебаний данных, сузьте область исследования и повысьте эффективность. Также используйте нашу динамическую структуру и набор инструментов для более подробной атрибуции.

Суммировать

Выше мы представили построение системы и управление приложением «Арбуз» в целом за прошедший период, полностью продемонстрировали наше мышление и построение различных недостатков и успешно использовали их для оптимизации практики и предотвращения обычных проблем.Более 80 % Проблемы с зависанием и ANR могут точно восстановить информацию на сайте, а проблемы, которые серьезно влияют на работу пользователей в Интернете, были значительно уменьшены.

Присоединяйтесь к нам

Добро пожаловать в Bytedance Watermelon Video Client Client Compare. Мы сосредоточены на строительстве разработки и основных технологий Applemelon Video App и вложили в клиентскую архитектуру, производительность, стабильность, компиляцию и конструкцию, а также инструменты R & D. Если вы также хотите преодолеть технические проблемы и встречаться с большими техническими проблемами вместе, добро пожаловать на нас!

Команда клиента видео арбуза набирает архитекторов Android и iOS и инженеров по исследованиям и разработкам.Самая приятная рабочая атмосфера и возможности роста, различные преимущества и возможности, есть вакансии в Пекине, Ханчжоу, Шанхае и Сямыне.Добро пожаловать, чтобы отправить свое резюме! Почта для связи:liaojinxing@bytedance.com; Тема письма: Имя-Арбуз-Годы работы-Место работы.