⌛ Время подведения итогов

В своем последнем блоге я рассказывал о том, как я уменьшил размер своего приложения с 75 МБ до 34 МБ всего за 2 недели (Посмотреть!). Но это еще не все, я также улучшил общую производительность нашего приложения до 80% ?.

Давайте узнаем КАК !!

? Лор

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

• Главный злодей — весь пользовательский интерфейс приложения зависает при генерации ответа в реальном времени

• Побочный злодей — медленное время отклика и отсутствие частоты кадров

• Любовник злодея – слишком много звонков API

• The Undead Army — плохая обработка ошибок и сбои

• Страдания — увеличение загрузки ЦП и затрат на сервер

• Потускневший - Я !

Отсюда начинается безжизненная битва за воссоздание вселенной с надеждой на лучший мир.

План Таити (но на этот раз он работает)

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

1. ⚛️ Проклятие React

Мудрость и проклятие ReactJ — это состояния. По мере того, как мы становимся старше в React, мы понимаем, что чем меньше состояний, тем лучше приложение. Следовательно, в этом конкретном произведении искусства использовалось 22 (да, черт возьми, 22 useStates) на одном экране чата, где все, что вы можете сделать, это отправить сообщение и получить сообщение.

Вишенка на высоте!
Мы использовали реализацию событий на стороне сервера для получения данных с сервера по частям, что в данном случае было пословно. Итак, если у вас есть запрос, на который есть ответ из 100 слов (ЭТО НАИМЕНЬШИЙ ОТВЕТ). Фактически он получит 100 событий.

Итак, если вы знаете математику, 100*22 = 2200 повторных рендерингов каждый раз, когда мы получаем ответ.

Нужно ли мне что-то объяснять? ( НЕТ )

Итак, я начал воссоздавать весь экран и сократил число состояний до 6. С лучшей и плавной функциональностью, как и раньше.

Это на 72 % эффективнее по сравнению с предыдущим !!

2. ❄️ Ледяная пустыня

Теперь, увидев Радан React, мы можем легко сделать вывод, что приложение будет довольно часто зависать, верно ?

Теперь даже с 6 состояниями основная проблема остается той же: 100*6. Мы все еще висим, но состояний меньше.

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

Черт возьми, да!

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

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

Поэтому вместо обновления DOM 100 раз мы обновили DOM всего 3-4 раза.

Теперь посчитайте и рассчитайте повышение производительности для домашнего задания!

3. ? Будьте хорошим слушателем!

Мне не удалось найти девушку, но это определенно помогло сделать приложение намного лучше.

API — это отличный и приятный способ получения данных, но их разумное использование — это ваш собственный навык! Теперь это приложение использовало этот API для получения статуса пользователя из серверной части. Но самое приятное то, что он использовал его каждые 3 секунды !!

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

а) Извлечение

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

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

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

б) Поток данных

Теперь, после устранения этой внутренней DDOS-атаки, я обнаружил, что это приложение использовало множество API, данные которых терялись в воздухе (плохая обработка данных). Вместо того, чтобы кэшировать данные и использовать их снова в том же потоке, приложение снова вызывало API.

Я позаботился о том, чтобы данные кэшировались и передавались линейно в поток, а API вызывался только тогда, когда это необходимо для нового экземпляра.

На заметку!

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

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

3. ? Это не ошибка, если мы не признаем это!

Одним из важнейших моментов при работе с API являются ОШИБКИ. Утешить их журналами недостаточно, поскольку это делает опыт пользователя намного хуже, чем его хорошее использование.

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

4. ? Ее воспоминания

Попался, приятель! Она не вернется, но утечки памяти вернутся. Одна из главных вещей, о которых мы забываем при подключении любого прослушивателя или вызова API, — это удалить его экземпляр после закрытия этого действия.

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

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

5. Декларация производительности

Теперь основной способ использования любого ресурса — это импортировать его и использовать, верно?

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

import Profile from '../../profile'

Он создаст 5 экземпляров одного и того же объекта !

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

Следовательно, сокращение использования памяти до 4/5.

✅Вывод -

Ты хороший человек, Артор! (Извините, я только что завершил RDR2, и это была великолепная игра).

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

Рейтинг магазина поднялся с 3,5 до 4,1 всего за 1 неделю использования !!!

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

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

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