GMTC 2018, который только что завершился в Пекине, следует рассматривать как одно из самых высококлассных (с самыми дорогими билетами) событий в последнее время в отечественном фронтенд-круге. Итак, что стоит упомянуть об этих двух днях обмена? Ниже небольшое резюме.
маршрутный счет
Мы вылетели из Сямыня в Пекин в среду вечером и приняли участие в двухдневном интенсивном обмене технологиями в четверг и пятницу на площадке рядом с птичьим гнездом. За исключением того, что все участники были в одном и том же месте в первое утро, содержание каждой подтемы объяснялось параллельно в разных под-местах. Поэтому один человек, очевидно, не может прослушать все темы, и мы также делаем некоторый выбор по темам, которые хотим услышать.
Тема, которую мы наконец выбрали для этой поездки, по-прежнему ориентирована на веб-интерфейс и охватывает такие темы, как гибридные приложения, графические приложения, Node, а также аудио- и видеоприложения. Хотя у нас было два одноклассника, темы, в которых мы участвовали в конце, на самом деле охватывали только около 70% от общего числа тем. Ниже мы попытаемся выделить некоторые моменты из этих тем и поделиться ими с вами XD
новые технологические тренды
На самом деле сама аббревиатура GMTC имеет прямое отношение не к «front-end», а к конференции по мобильной технике. Но в условиях нынешней волны «большого фронтенда» тема этой конференции в значительной степени смещена в сторону разработчиков веб-интерфейса/полного стека. У нас есть несколько тем для обмена, которые получили хороший отклик на сцене, и их содержательная ориентация также может подтвердить это:
Разработка гибридных приложений
В то время как Генеральная Ассамблея также имеет много высококачественных гибридных приложений RN / HTML5, но чтобы сказать об этой теме в самой теплой атмосфере обмена темой, следует не что иное, как не-Flutter. Поделитесь с другими общими темами «внутренняя настройка фрейма» и «эволюция бизнес-системы», которыми поделилась команда Google Flutter в Сяо, поэтому они внедрилиФреймворк с открытым исходным кодом, который приносит новый опыт разработки. Этот шеринг был явно тщательно подготовлен, с хорошим ритмом и изысканным интерактивным демо, а также вызвал волну аплодисментов со сцены~
Целью Flutter должно быть смешанное решение для разработки, такое как React Native и Weex, но разница в том, что Flutter не только использует язык программирования от Google, такой как Dart, но также заменяет решение по соединению собственных компонентов пользовательского интерфейса из RN в один на основе библиотеки OpenGL/Graphics, такие как Vulkan, обеспечивают кроссплатформенную стабильность. Удивительные вещи, принесенные живой демонстрацией, заключаются в следующем:
- Языковые механизмы Dart расширяют возможности разработки. Например, оптимизация производительности JIT во время отладки + AOT во время выполнения, оптимизация размера пакета Tree Shaking и т. д. А в демоверсии Hot Reload на основе Dart может сохранять состояние ошибки, а не только обновлять и сбрасывать при возникновении ошибки, как Web и RN. Это может значительно повысить эффективность отладки для сложных для повторного входа состояний страницы.
- Flutter не полагается на нативные компоненты и может легко запускать безголовые тесты из командной строки.
- Flutter использует Dart для перезаписи полного набора технологических стеков от низкоуровневого рисования, анимации, жестов до высокоуровневых компонентов пользовательского интерфейса и реализует полную компонентизацию. Таким образом, многие эффекты, требующие строгого контроля, могут быть реализованы непосредственно в экосистеме Dart, вместо того, чтобы полагаться на собственные библиотеки, такие как RN.
Что касается стоимости перехода на Flutter, основные проблемы связаны с кривой обучения Dart и интеграцией с Native-проектами. Оба они были фактически упомянуты в обмене практиками Flutter с Xianyu в тот день. Что касается первого, мы получили ответ, что Dart на самом деле близок к JS и Java, а его компоненты близки к React, поэтому кривая обучения не очень крутая. Что касается интеграции проекта Native, из сообщения команды Xianyu мы увидели, что есть еще много ям, которые можно обойти только на этом этапе, но, судя по поддержке команды Flutter, это должно быть возможно. ожидать постоянного улучшения и оптимизации.
На картинке ниже вы можете видеть, что когда команда Xianyu поделилась своей практикой Flutter, два босса команды Flutter, которые ели дыни в первом ряду, чтобы отпраздновать, их собственная работа привлекла всеобщее внимание, я должен быть очень счастлив XD
Миддл и бэк-офис и инжиниринг
Поскольку это «большой интерфейс», полный стек Node и соответствующая экосистема NPM являются незаменимой темой. Мы тоже используем Node в своем бизнесе, поэтому по-прежнему уделяем больше внимания этой теме.
Однако, если вы хотите оценить совместное использование Node и инженерных разработок, связанных с этим GMTC, мое личное понимание должно быть ближе к «стабильному». Большая часть обсуждения на этой конференции посвящена не выпуску новых инструментов, таких как Flutter, «от 0 до 1», а в основном сводке «от 100 до 1000», основанной на передовых технологиях для обеспечения развития бизнеса. Конечно, с точки зрения чистых инструментов этот вопрос не пуст. Например, руководитель команды Apollo подробно представил GraphQL и семейство корзин Apollo. Из-за отсутствия масштабируемости REST механизм сбора по запросу GraphQL проще в использовании; для вложенных сложных данных мы можем получать их по запросу без множественных вызовов, тем самым снижая нагрузку на сеть; при кэшировании и предварительной выборке На общем уровне оптимизации , уровень GraphQL также может обеспечить множество оптимизаций, которые прозрачны для бизнеса.
Хотя решение API Gateway следующего поколения, такое как GraphQL, всегда было очень популярным, нельзя отрицать, что оно еще не достигло такой популярности, как Vue в Китае. Затраты и преимущества перехода на GraphQL всегда стоит тщательно взвесить при выборе технологии. В связи с этим под платформой «Аполлон»,apollo-clientНастоятельно рекомендуется ряд представленных им инструментов GraphQL: если мы можем использовать серию связующего кода Redux / Saga или Vuex / MobX с кратким декларативным запросом GraphQL без внесения инвазивных изменений в замену серверной службы, может ли он решить некоторые из проблем? болевые точки стыковки данных? В разговоре с другими местными командами они также упомянули об изучении возможности объединения различных серверных интерфейсных сервисов в «уровень API, прозрачный для приложений». Например, команда Alibaba Node предложила концепцию BFF (Backend For Frontend), позволяющую микро В сервисной архитектуре больше возможностей для игры. Благодаря легкости BFF мы можем даже разработать API-шлюз для каждого бизнеса. Ждем от них еще результатов.
При накоплении и разработке некоторых промежуточных и серверных систем мы по-прежнему видели много практического обмена на этой конференции. Несколько крупных заводов внедрили системы для бизнес-мониторинга, проверки исключений, оповещения, обнаружения проблем и ведения журналов, а модель разработки с разделением клиентской и серверной частей и SSR также была достаточно зрелой. Возможно, именно из-за высокой степени зрелости совместное использование в этой области связано не столько с конкретным уровнем кода, сколько с обобщением некоторого «Дао» высокого уровня. Конечно, есть и темы, очень близкие к рекламе, поэтому я не буду здесь вдаваться в подробности. И, наконец, выложите в Твиттере фотографию сайта обмена инженерными разработками, чтобы вы могли понять атмосферу «Дао»:
Оптимизация производительности и мониторинг
Эта тема в основном является тем, где студенты Дачана демонстрируют свои мускулы: для основного бизнеса различных приложений национального уровня непрерывная полировка и оптимизация, а также большое количество систем поддержки, стоящих за ними, сложны для студентов, которые не сталкивались с проблемой такого масштаба. воображение. Мы часто можем думать, что оптимизация производительности была достигнута, пока применяются «методы оптимизации производительности внешнего интерфейса», которые обычно появляются в вопросах интервью. Но в этих обменах мы пересмотрели то, что мы считали «оптимизированным», и узнали больше о размерах проблем с производительностью.
Взяв в качестве примера расшаривание команды iQIYI, вообще для клиента, кроме частоты сбоев, разработчиков больше всего волнует беглость и скорость запуска первого экрана Практика расшаривания здесь отказывается от наших обычных заметок руководства. , обратиться кзапись экранаспособ сделать тест более точным и приближенным к реальности. Другой пример: потребление электроэнергии, как правило, не является заботой разработчиков приложений, а в реальном мире,Беглость часто прямо отрицательно связана с энергопотреблением. PowerMonitor, представленный в совместном использовании, может не только определять потребление энергии, но и количественно оценивать улучшение беглости до и после оптимизации. Для нашего привычного WebView это почти всегда является синонимом медленных приложений. Здесь мы увидели в совместном использовании, что набор решений «офлайн + асинхронность + кеширование» значительно улучшил скорость инициализации WebView.liteappПроект заслуживает внимания. Первоначально мы думали, что текущая популярная тенденция ИИ не имеет ничего общего с традиционной разработкой приложений, но неожиданно мы увидели технологию ИИ в совместном использовании.Автоматически повышать четкость видеоЧто касается приложения, мы должны восхищаться силой технической команды, которая следит за внедрением новых технологий. Наконец, по вопросу о фрагментации моделей Android мы также подтвердили вывод, что «кратчайшего пути нет» Наиболее эффективным способом на данный момент является покупка различных моделей и проведение полных тестов под каждой моделью.
Графика и аудио видео
Благодаря ауре г-на Винтера темам графики на этой конференции было уделено много дополнительного внимания:
Хотя это добыча для обмена математическими формулами и деталями кода, процесс обмена гораздо интереснее, чем воображать, это компьютерный ребенок. На самом деле, мы также столкнулись с некоторыми узкими местами DOM и Canvas, связанными с выразительностью, в базовом банке редактора, и эти узкие места должны быть преодолены с помощью более глубокого шейдера. На определенном уровне можно подумать, что у этих основ никогда нет времени. Тем не менее, кажется, что предыдущая очень хорошая передача Зимнего учителя наконец-то представлена.GCanvasа такжеG3DЭти два колеса (про Amway я вообще слышал на прошлогодней D2), лучше бы были новости о новых разработках.
Напротив, область разработки аудио и видео, которая также находится на более низком уровне графики, получила меньше внимания. По моему мнению, ведущий аудио- и видеоподпространства тоже сказал: «Каждый здесь, должно быть, стоит больших денег». В этой области есть свои плюсы и минусы, например, в сообщении Tencent Microvision упоминаются классические графические технологии, такие как многопроходный рендеринг и двусторонняя фильтрация. Эта часть контента уже относится к типичной категории разработки на стороне клиента.В краткосрочной перспективе управление аудио и видео учащимися переднего плана все еще может быть ограничено существующей системой среды браузера, и ее трудно совершить крупный прорыв.
Хорошей новостью является то, что на конференции был проведен внутренний обмен WASM, а некоторые приложения для видео спецэффектов, основанные на WASM, также были экспериментально реализованы во внешнем интерфейсе Интернета. Поскольку мы касались этой части контента ранее, мы также обменялись мнениями с лектором: На данном этапе у WASM действительно есть трудности и узкие места в отладке и построении, но, к счастью, из-за макротренда, сообщество стало популярным с тех пор, как Вторая половина прошлого года. Произошло значительное увеличение, и я надеюсь, что это может быть добавлено к нашему бизнесу, чтобы как можно скорее создать ценность~
Резюме и перспективы
Наконец, давайте перечислим некоторые мысли и комментарии участников в произвольном порядке:
- Начиная с Deep JS Conference в 2015 году и заканчивая GMTC в этом году, мы ясно ощущаем мощь стороны JS, которая очень хорошо отражена в Node.js: с самого начала внедрения фреймворков веб-сервисов, таких как koa, до Pandora Али. .js Управляемый, измеримый и отслеживаемый менеджер приложений Node.js, который, как нам кажется, является экологической эволюцией. Node.js только начинался в 2015 году, и все стремились внедрить серверную часть «jQuery» для удовлетворения основных потребностей бизнеса. Теперь все стремятся построить экосистему, ведь серверным сервисам нужен полный набор инфраструктуры для стабильной работы в течение длительного времени. Конечно, из-за ограничений самого Node.js фронтенд-студентам сложно углубиться в нижние уровни БД и даже ОС для полировки экологии.Также можно сказать, что фронтенд-студенты действительно не достаточно глубоко в заднем поле. Но это не значит, что мы не думаем о том, как сделать лучше.
- Есть еще много возможностей для оптимизации в управлении ритмом отечественных шелеров технологий, много шерингов может легко сделать атмосферу сцены скучной, и действительно есть немного «старого вина в новых бутылках». Иностранные лекторы, как правило, более опытные водители (что может быть связано с отсутствием ежедневного общения с отечественными техническими постами).
- Внутреннее внимание к фронтенд-инжинирингу по-прежнему сосредоточено главным образом на поддержке бизнес-приложений. По основам относительно "низкоуровневых" языков программирования, ВМ, игровых движков и т.д., кроме коммерческих продуктов, open source вещи пока не особо богаты.
- Для современных проектов постоянно растущего масштаба это уже не то, что можно сделать в одиночку или с помощью одного навыка. Для более длинных сервисных каналов нам нужна организация, которая может координировать общую ситуацию и быстро комбинировать различные возможности, чтобы контролировать сложность каждого узла на канале.
- Помимо основного выбора инструментов, системы технических команд, такие как Code Review / Case Study, также могут сильно повлиять на качество разработки команды и даже на атмосферу.В этом отношении еще предстоит пройти долгий путь.
- Независимо от того, как развиваются отношения между клиентом и веб-интерфейсом, компьютерная основа, стоящая за ними, относительно стабильна. По мере того, как мы «сжимаем» производительность, такие основы, как графика, могут стать более важными.
- По сравнению с D2, GMTC имеет значительно более сильную коммерческую атмосферу.