1. Связанные понятия лага

визуальная концепция

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

2. Кадры фильма Частота кадров фильма (18-24), обычно 24 кадра. Время, необходимое для одного кадра фильма, составляет: 1000 мс/24≈41,67 мс. Частота кадров фильма является критическим моментом. Ниже этой частоты кадров человеческий глаз может почувствовать прерывистость изображения, то есть он будет чувствовать себя застрявшим.

Концепция Катона

1. Идеи Google Jank

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

Условия блокировки Google более строгие

2. Принцип застревания PerfDog

1. Если одновременно выполняются два следующих условия, это считается янком. a) Текущий кадр занимает>Среднее время, потраченное на первые три кадра2раз。 b) Текущий кадр занимает>два кадракадр Фильм требует времени (1000 мс/24*2=84 мс).
2. Если оба условия выполняются одновременно, BigJank считается сильно застрявшим. a) Текущий кадр занимает>Среднее время, потраченное на первые три кадра2раз。 b) Текущий кадр занимает>три кадракадр фильм требует времени (1000 мс/24*3=125 мс)

кадр фильма：Ниже этой частоты кадров,Человеческий глаз может обнаружить неоднородность изображения.,То есть я чувствую себя застрявшим.

Идеи расчета заикания：на основеPerfDog На основе Джанка, как только Джанк застрянет, наступит время, когда Джанк застрянет. время. Во время теста может быть несколько зависаний Jank, то есть может быть несколько раз зависаний Jank. время. Общая продолжительность теста — Время. PerfDog Заикание (скорость заикания) = ∑Jank time / Time

Недоразумение: Частота кадров не может напрямую отражать, отстает ли она!

Определение FPS：Частота кадров（1Среднее количество обновлений экрана в секунду）。

средняя частота кадров:Традиционно сказаноFPS,Среднее количество обновлений экрана в течение 1 секунды.

Высокая частота кадров в секунду не гарантирует плавного отклика или отсутствия задержек. Например: FPS составляет 50 кадров, один кадр визуализируется в течение первых 200 мс, а 49 кадров визуализируются в течение следующих 800 мс. Хотя частота кадров равна 50, она по-прежнему ощущается очень медленной. При этом низкая частота кадров FPS не означает лагов. Например, средний FPS при отсутствии лагов составляет 15 кадров. Поэтому средняя частота кадров FPS не имеет прямой связи с лагами) Как показано на картинке

Неравномерный рендеринг слева, хотя частота кадров и высокая, но выглядит более тормозной

2. Каковы причины отставания?

1. Прямая причина отставания

Затраты времени на одну точку

Больше времени уходит

Сложные или часто выполняемые

2. Косвенные причины отставания

1. Мастер выделяет слишком мало ЦП
2. Частый GC

3. Как устранить неполадки и обнаружить лаги?

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

Принцип: отслеживайте выполнение сообщений обработчика и регулярно записывайте стек.

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

1.2 Systrace/CPU Profiler(simpleperf)

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

Systrace:

simpleperf

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

комплексный анализ

Коэффициент использования основного процессора,Журнал ГХ,нитьчислокомплексный анализ, примеры в следующих случаях

4. Конкретные случаи и решения в Везинге

1. Эффект оптимизации

После версии 5.65 и 5.70 дважды оптимизация,Скорость задержки при входе в певческую комнату（PerfDogскорость задержки）оптимизациязакрывать50%

Метод испытания：локальная проверка,Процесс холодного запуска,Нажмите, чтобы начать вход в комнату,Оставайтесь в течение 8 секунд, пока пользовательский интерфейс комнаты не стабилизируется.

Тестовая модель：OnePlus 10 Pro,Android12

2. Перечень и анализ типичных случаев

2.1 Комплексный анализ задач, разборка и оптимизация.

Краткое содержание одним предложением: в одном сообщении делается слишком много вещей, и для оптимизации его необходимо разделить на несколько сообщений.

case1：Комната песен использует структуру микросервисов.,У каждого бизнеса есть независимая служба,Активность/фрагмент и жизненный цикл аудио и видео, отправляемые платформой.,Отдельная операция,По мере роста бизнеса,Все жизненные циклы создания и отправки сервисов выполняются в одном сообщении.,Вызывает серьезное отставание.

Схема архитектуры распределения жизненного цикла комнаты песен

а. Создание экземпляра микросервиса занимает до 312 мс.

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

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

Распространение b.handleGameTypeChanged занимает 40 мс.

вопросанализировать：此вопрос对应“Больше времени сцена типа "уходит",Распространение этого метода жизненного цикла требует обновления элементов интерфейса пользовательского интерфейса.,Поэтому невозможно переключиться на дочернюю нить для распространения обновлений.,Легко думать о Господенить Метод отложенного выполненияHandler.post(),Распределить текущую задачу на следующее сообщение для выполнения.

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

Дальнейший исходный коданализировать：здесьанализироватьHandlerИсходный код изученpostAtFontOfQueueМетод может поместить текущее сообщение в начало очереди.,Это может гарантировать, что задачи выполняются в первую очередь, насколько это возможно. Как показано ниже исходный код

Окончательный план оптимизации:

1. Разбивка задач：Отправьте отправку части службы следующему сообщению в очереди сообщений для запуска.,Разбивайте задачи внутри сообщения. Здесь, чтобы гарантировать, что проблемы синхронизации, вызванные задачами по разборке, максимально уменьшены.,Можно использоватьpostAtFontOfQueueвместоpost
2. оптимизация Уровень просмотра комнаты, сокращающий время создания
3. Инициализируйте представление по требованию или лениво инициализируйте его.

2.2. Оптимизация асинхронной загрузки подпотоков.

а. Войдите в певческую комнату для инициализации аудио и видео SDK 115 мс (Время работы: 27 мс)

b. Операция размытия фона растрового изображения 103 мс.

c. Основной поток анализирует файл json, настроенный wns.

……

План оптимизации:переключиться нанитьработа в бассейненить Процесс

2.3. Оптимизация предварительной загрузки.

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

Процесс загрузки класса

анализировать：проходитьанализироватьSystraceОбнаружено, что загрузка и проверка основного класса обслуживания занимают много времени.,Легко вызвать «Больше времени «удаление» вызывает задержку, а одноэлементная инфраструктура сети NetCore может вызвать «Затраты времени на одну точку”Застрял и остановился,Однако этими занятиями нужно воспользоваться сразу, как только вы войдете в комнату.,Поэтому отложенную загрузку использовать нельзя. Теперь измените свое мышление,Поместите класс в дочернюю нить для предварительной загрузки.

возможность：Поскольку предварительная загрузка классов приведет к Памятьзанимать,Итак, если он загружается для всех пользователей, как только вы заходите на домашнюю страницу,Может вызвать напряжение у пользователей, которые никогда раньше не присоединялись к комнате песен.,поэтому,здесь针对“время”и“космос”сделать баланс。Открыто только для пользователей, которые вошли в певческую комнату и установили переключатель оттенков серого.

конкретный план：

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

результат：线上针对进房服务и网络框架из预加载,Среднее время, необходимое для входа в комнату, сократилось на 250 мс.

2.4. Оптимизация ленивой загрузки.

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

Case2: конфигурация сопутствующей переменной, анализ отложенной загрузки

Случай 3: конструкция синтаксического анализа элементов управления переменными и отложенная загрузка.

Случай 4: Процесс входа в комнату заранее запускает дочерний процесс на 7,6 мс.

…..

Всего было исправлено более 20 подобных проблем с задержками. План оптимизации:

1. Kotlin предоставляет очень полезную функцию lazy. Использование lazy для инициализации позволяет легко преобразовать отложенную загрузку.

путем ленивого анализа исходного кода:

Вы можете видеть, что, хотя Lazy и прост в использовании, он имеет операцию блокировки. Таким образом, вы можете дополнительно оптимизировать и использовать lazy(LazyThreadSafetyMode.NONE) при подтверждении отсутствия проблем с безопасностью потоков. Например:

2. Должно выполняться в основном потоке с задержкой до выполнения следующего сообщения.

2.5. Иерархия макетов и оптимизация загрузки по требованию.

View.inflate требует трудоемких методов ввода-вывода, отражения и построения. Это старая проблема, избежать которой невозможно. Как показано на рисунке:

план: 1. Для представлений со многими уровнями используйте теги слияния и динамически добавляйте представления, чтобы уменьшить уровень и количество представлений, чтобы сократить время раздувания. 2. Оптимизировать метод построения и инициализацию переменных-членов для одного представления, создание которого занимает много времени. 3. Загружайте по требованию, используйте ViewStub для отложенной загрузки. Например, макет режима посетителя необходимо загружать только при наличии посетителей, и его не нужно загружать в другое время.

2.6. Оптимизация потребления времени блокировки.

case:wesingЖурналы FireEye, используемые проектами соответственно,Неправильный журнал,журнал WNS,Чтобы обеспечить безопасность внутри SDK,Все заблокировано,Вызывает множественные вызовы системы журналирования.,Очень легко вызвать задержку

местное воспроизводство

Онлайн-стек

план：Использовать отдельный журналнить,Создайте отдельный HandlerThread и переключитесь на отдельный HandlerThread, прежде чем SDK распечатает журнал.,решить проблему блокировки, отнимающую много времени

2.7. Оптимизация задачи склейки строк.

case:LogUtil.dВремя печати до18ms

анализировать：внутри сознанияLogUtil.dНе буду записывать в файл,但是我们很容易忽略了направление法参число里面из表达式是существоватьВыполняется при вызове методаиз,Он не запускается при выполнении определенного метода.,так,В проекте в логи вклеено большое количество параметров запроса.,Сериализация данных JSON и других операций,Вызвал много времени.

решать：集中将日志里面拼接из字符串进行оптимизация,LogUtil.dиз日志加上if(isDebug),LogUtil.d и выше оптимизируют и удаляют объединение журналов.

2.8. Оптимизация проблем с памятью.

Памятькогда нервничаешь,Система будет часто выполнять GC.,причина"stop the world",Влияние на задержку нельзя недооценивать

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

case1: Краткий список проблем с утечкой памяти в руме

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

решатьплан：弹窗关播即动画不显示изчас候将动画停止并销毁

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

решатьплан：此类вопрос应существовать日常开发中сосредоточиться наAPMПлатформа мониторинга（Глаза огня,Багли) заявлено на ремонт; в ходе тестирования системы был проведен полный комплекс испытаний уровня воды на основном пути;,Систематические утечки решения Память

Случай 2: решение по оптимизации памяти

При входе в комнату с ограниченной памятью память может переполниться, и часто происходит сбор мусора, что приводит к задержкам. анализировать：直播间内使用изViewPager2作为上下滑动из框架,Поэтому, если вы можете ввести текущий элемент,Не загружать предварительную загрузку следующей прямой трансляции,Это позволяет избежать создания экземпляра объекта комнаты.,Можно ли оптимизировать больше Память,Уменьшить отставание

план：существовать Памятькогда нервничаешь Хоу,Установите для ViewPager2#setOffscreenPageLimit значение 1.,Отличие от ViewPager,Параметр ViewPager2 для setOffscreenPageLimit, равный 1, действителен.,Следующий элемент не будет предварительно загружен.

результат：После тестирования одноклассниками выяснилось, что Памятьоптимизация41M

Конструкция мониторинга ГХ:

Журналы GC могут помочь разработчикам просматривать и анализировать текущее использование памяти приложениями, обнаруживать утечки памяти, проблемы с дрожанием памяти и проблемы с задержкой, вызванные GC. Например, частота GC слишком высока, что может легко привести к задержкам. планодин：自定义один个对象使用弱引用包裹,Затем поместите его в пользовательскую очередь ссылок.,Открыть субтитры,Выполните цикл, чтобы проверить, был ли пользователь удален из очереди слабых ссылок. Аналогично мониторингу LeakCanary Принцип утечки Память

пландва：подражатьActivityThreadмониторGC,自定义один个弱引用对象,Реализуйте его Finalize(),Когда объект подлежит переработке,Указывает, что произошел сбор мусора,Распечатать некоторую информацию журнала в это время

Решение 2 простое и эффективное. Нет необходимости создавать новый поток прослушивания. Наконец, оно реализовано подробно.

2.9 Оптимизация задержек, вызванных проблемами с потоками.

Вопрос: В тесте производительности версии 5.68 было обнаружено, что было почти на 30 потоков больше, чем в предыдущей версии, 250 новых fds, а уровень лагов увеличился с 15% до 20%.

анализироватьи устранение неполадок：пройтиadbШаг устранения неполадок командынить,Было обнаружено, что добавленными именами были «.tencent.wesing» и «wesing-default-».,Нет очевидных особенностей именования,Выход из караоке-зала все равно не убавляется. Устранение неполадок с изменениями функций в новой версии,Найдено обновление trtc sdk, сравните и перепроверьте апк до и после обновления, он обязательно появится.

решать：поэтому Отправить вsdkнаправление,Вызвано введением нерелевантной для бизнеса функции. После ремонта все показатели в норме.

сомневаться：здесь新增изнить,Не имеет прямого отношения к главному герою,Почему это влияет на отставание?

进один步анализировать：проходитьperffto SQL проанализировал загрузку ЦП и обнаружил, что после обновления trtc поток DefaultDispatch занимал больше, чем основной поток и RenderThread.

в заключение： 1. Увеличение количества потоков влияет на интервал времени переключения ЦП основного потока, тем самым захватывая время основного потока, что приводит к задержке. 2. Добавление 30 новых потоков значительно увеличит память приложения и приведет к ненужному сбору мусора.

5. Краткое описание методов и опыта

Карта методов оптимизации

Краткое описание опыта

1. Используйте платформу APM для поиска проблем с задержкой и ANR.

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

2. проходитьProfiler发现Застрял и остановилсявопрос&Систематическийанализироватьвопрос

Метод, захватываемый CPU Profiler, вызывает трассировку, которая распределяется во временных рядах горизонтально. Он может захватывать трассировки одного этапа для горизонтального и вертикального анализа и оптимизации.

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

4. При анализе проблемы чрезмерной загрузки ЦП вы можете использовать Perftto для анализа времени ЦП потока.

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

5. Анализ количества потоков через команды adb

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

adb shell ps -T | grep xxx

6. Анализируйте проблемы необоснованного использования памяти.

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

7. Тест производительности версии

Студенты-испытатели будут проверять уровни производительности (ЦП, память, FD) во время тестирования системы, но колебания уровня воды являются лишь симптомом. Сами разработчики также должны проводить повторные тесты производительности на основном пути, а также проводить дальнейшее исследование и проверку на основе различий. при колебаниях уровня воды для подтверждения Ни одна рыба не выскользнула из сети.

8. Анализируйте проблемы систематически и всесторонне.

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