Плюсы и минусы реактивной технологии

внешний интерфейс Android iOS React.js

предисловие

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

После почти года предварительных исследований коллеги мы полностью приступили к реконструкции проекта в 2017 году. Бегая к горячим обновлениям и «Напиши один раз, беги везде», я с этого момента отправился в путешествие по заполнению ям RN.

Начиная с ES6, css-layout, redux

Я работал над разработкой для iOS, используя язык OC, и знакомство с ES6 — довольно новое дело. Языковой стиль и языки семейства C — это совсем не один и тот же стиль. Обратитесь к учебнику Ruan Yifeng.es6.ruanyifeng.com/#docs/intro  RN использует макет интерфейса с вкладками, называемый css-layout, который в основном такой же, как CSS. Хотя это первый раз, когда вы используете этот метод для разметки интерфейса, он очень удобен после его использования, объем кода небольшой, и он очень прямой.  Для части чата мы используем архитектуру redux, которая представляет собой конечный автомат в JavaScript. Ссылаться наwww.redux.org.cn/index.html

Преимущества РН

  • Легко отлаживать После установки ipa нет необходимости часто компилировать, достаточно перезагрузить и загрузить код js с облачного сервера, чтобы показать эффект от изменения кода. Более того, RN поддерживает hotReload, что очень удобно при отладке интерфейса.После модификации кода и сохранения интерфейс изменится автоматически.Это действительно круто при отладке, но иногда немного тормозит и требует перезагрузки. Онлайн-отладка Chrome тоже неплохая, можно ломать точки и смотреть логи. Хотя он не так интегрирован, как xcode или Android Studio, он также очень мощный инструмент отладки для языков сценариев.

  • css-макет макета Для фронтенд-программистов это значительно снижает затраты на обучение и значительно сокращает объем кода. Но разработчики iOS или Android, когда они впервые вступают в контакт, должны принять некоторые идеологические изменения.

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

  • Горячее обновление Вероятно, это основная причина, по которой большинство компаний предпочитают использовать RN. Частые обновления приложений раздражают пользователей, а проверка Apple доставляет массу хлопот. Сейчас многие крупные приложения используют RN, ведь каждый раз проходить аудит APP из-за многочисленных бизнес-итераций — кошмар.

  • иметь хорошего папу Я считаю, что при поддержке Facebook он будет развиваться очень хорошо.

недостатки РН

Позвольте мне плюнуть, слишком много недостатков, и по сравнению с нативным опытом разработки это огромная разница. Последняя версия RN — 0.46, а мы используем в нашем проекте 0.42, ведь до 1.0 она еще не дошла.  Уберите субъективные эмоции, вот несколько несовершенных моментов:

  • Общий опыт разработки.  Несмотря на то, что синтаксис js очень гибкий, это все-таки скриптовый язык, поэтому его все равно неудобно отлаживать, а находить ошибки непросто. Мы используем редактор vscode с лучшей производительностью, и он кажется очень неудобным для различных прыжков, и мы должны искать глобально на каждом шагу.Может, это привычка Xcode. Язык сценариев также будет постепенно привыкать к этому.

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

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

  • Неполный контроль Это на самом деле довольно много.В самом простом ListView есть недостающие функции и много ям. Текст не поддерживает форматированный текст, анимацию, жесты, ScrollView и т.д. и т.п. Не могу перечислить их все. В качестве программного обеспечения для чата функция форматированного текста должна быть реализована для смешанного отображения выражений смайликов и текста. Я был вынужден сам создать набор планов реализации, и сейчас есть еще небольшие баги. Ссылка на конкретную реализациюblog.CSDN.net/just 5440439…

  • Обновление версии RN требует больших усилий Недавно мы обновили версию RN с оригинальной версии 0.42 до последней версии 0.50. Это действительно хлопотно. В новой версии PropTyps убраны из React, поэтому прежний эталонный метод приходится менять, и все файлы проверяются один за другим. Используемые ранее сторонние библиотеки, некоторые из которых связаны с PropTypes, необходимо обновлять одну за другой. В прежней раскладке интерфейса на изображение были вынесены некоторые другие элементы управления, после обновления будет сообщаться об ошибке, а затем корректироваться по одному.

  • Для создания качественного приложения требуется много рабочей силы и времени на полировку. Кроссплатформенность на самом деле не снижает затраты на разработку, получается, что у нас по три человека на Android и iOS, и каждая итерация выполняется упорядоченно. Однако после смены РН на ней все 6 человек, что утомительно, итерация медленная, багов много.

Суммировать

FaceBook также хочет предоставить разработчикам набор кроссплатформенных, динамически обновляемых фреймворков Javascript под лозунгом: «Узнай один раз, пиши где угодно: создавайте мобильные приложения с помощью React». Я думаю, это великий сон.

Когда он был впервые выпущен в 2015 году, он был полон ожиданий и споров. До сих пор РН также постепенно улучшается. Некоторое время назад электронное письмо с предупреждением от Apple вызвало у всех панику, но, на мой взгляд, RN все еще в безопасности. С точки зрения политики проверки Apple разрешена динамическая загрузка кода, работающего на JavascriptCore, и он не использует частные методы других людей. Более того, сейчас довольно много крупных компаний используют RN, хотя Apple гордится тем, что если они хотят запретить RN, им все равно придется взвесить мнение этих крупных компаний.

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

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

Для кого предназначена РН?

  • Функция горячего обновления крайне необходима
  • Готов инвестировать человеческие и финансовые ресурсы в RN

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

Адрес оригинала: https://blog.csdn.net/gang544043963/article/details/77507940 , при перепечатке указывать оригинал

技术+职场
Добро пожаловать, чтобы учиться и обмениваться технологиями со мной