Эта статья призвана рассказать самые скучные базовые знания на самом популярном языке.
Старый утюг, который брал интервью у фронтенда, знает, что для фронтенда интервьюер любит сначала спрашивать о новых элементах и фичах HTML5, или js замыканиях, прототипах, или как реализовать вертикальное и горизонтальное центрирование CSS. , когда вы сможете ответить на эти подряд, у интервьюера появится странная улыбка на лице, затем погода станет пасмурной, и он сделает вид, что глубоко откашливается, и спросит:Каков процесс от ввода пользователем URL-адреса до отображения страницы в браузере?Если вы понимаете, Барабара ответил на кучу, и он продолжил спрашивать:Как именно отображается страница?Если вы все же поняли, и после кучи ответов Барабары, он продолжит спрашивать:Итак, какой у вас опыт оптимизации производительности веб-страниц?Когда вы сможете ответить на кучу бла-бла-бла-бла-бла-бла-бла-бла-бла, интервьюеру придется нелегко, и он будет спрашивать вас о таких вещах, как тети и тети, которые не имеют ничего общего с технологиями. Вы можете приветствовать Ваше предложение почти поступило.
Итак, вопросы, ваша очередь брать интервью Можете ли вы вернуться к этим вопросам красиво?
Что делает браузер после того, как пользователь вводит URL-адрес и нажимает Enter?
Каков полный процесс рендеринга страницы?
Какой у вас опыт оптимизации производительности переднего плана?
Если нет, то спускаемся вниз: (Некоторые люди могут задаться вопросом, не о фронтенде ли речь? Почему вы хотите говорить о TCP и DNS, которые не имеют отношения к фронтенду? Не паникуйте, просто следуйте статье, это безвредно, чтобы узнать больше !)
Схема статьи:
TCP
UDP
розетка розетка
HTTP-протокол
разрешение DNS
Инициация HTTP-запроса и ответ
Процесс рендеринга страницы
оптимизация производительности страницы
TCP-соединение
TCP: Протокол управления передачей, протокол управления передачей, является ориентированным на соединение, надежным протоколом связи транспортного уровня на основе потока байтов. Так профессионально, какая польза? Возьмем каштан Помните телефоны из бумажных стаканчиков, которые мы делали в детстве? Два бумажных стаканчика связаны между собой ниткой, каждый из них держит бумажный стаканчик, чтобы выпрямить линию, один говорит с бумажным стаканчиком, а другой слушает ухом бумажный стаканчик.
На самом деле это простейшее соединение связи.Они соединены линией, и звук передается от бумажного стаканчика с этой стороны к другому бумажному стаканчику и принимается по линии.То же самое верно и для стационарных телефонов, которые есть в каждом домашнем хозяйстве. Его общение также основано на взаимном принятии и доверии, например:
А берет трубку, набирает 0775-6532122 и начинает звонить Б.
B слышит телефонный звонок и берет трубку, в это время A получает звук о том, что B взял трубку
Обе стороны начали говорить.
Вернемся к нашему протоколу tcp, по сути, он похож на упомянутый выше телефонный протокол, за исключением того, что телефонный протокол предназначен для телефонной связи, а tcp — это протокол для сетевой связи.Также обе стороны связи устанавливают соединение tcp, также нужно пройти три шага (рукопожатие).
Клиент отправляет пакет синхронизации (syn=j) на сервер и переходит в состояние SYN_SEND, ожидая подтверждения от сервера.
Когда сервер получает пакет syn, он должен подтвердить SYN клиента (ack=j+1), и в то же время он также отправляет пакет SYN (syn=k), то есть пакет SYN+ACK. на этот раз сервер входит в состояние SYN_RECV.
Клиент получает пакет SYN+ACK от сервера и отправляет на сервер пакет подтверждения ACK (ack=k+1).После отправки пакета клиент и сервер переходят в состояние ESTABLISHED и завершают трехстороннее рукопожатие.
Приведенные выше несколько щебетаний и кривоватый английский выглядят немного запутанными, так что давайте переведем их: (Вам лучше запомнить эти коды состояния, которые часто используются при оптимизации производительности количества подключений к серверу)
SYN: синхронное установление соединения АСК: подтверждение Syn_sent: запросить соединение SYN_RECV: после пассивного открытия сервера он получает SYN клиента и отправляет ACK. После дальнейшего получения ACK от клиента он перейдет в состояние ESTABLISHED.
Стоит отметить, что:tcp не передает данные во время процесса рукопожатия (точно так же, как когда вы звоните в отель, чтобы сделать заказ, прежде чем подтвердить, что другая сторона является сотрудником службы поддержки клиентов отеля, вы не будете сразу сообщать ему идентификационный номер, верно?) , но три раза После завершения рукопожатия произойдет передача данных.
Что касается сценариев его применения, то он фактически зависит от его собственных характеристик, например, когда есть требования к качеству сетевой связи и необходимо обеспечить точность данных, необходимо использовать протокол TCP, такой как HTTP, ftp и другие. протоколы передачи файлов или Некоторые протоколы передачи почты (SMTP, pop и т. д.)
UDP-протокол
(Протокол UDP — это не то, на чем нужно сосредоточиться в этой статье, но когда дело доходит до TCP, как его дополняющего брата, вот краткий обзор.)
UDP: Протокол пользовательских дейтаграмм Протокол пользовательских дейтаграмм По сравнению с громоздкими этапами соединения TCP, ориентированного на установление соединения, которое требует повторного подтверждения, UDP представляет собой протокол, не ориентированный на установление соединения, с уникальным характером и сильной субъективностью.Использование протокола udp для частого обмена данными не требует установления соединения, это отвечает только за отправку данных.Отправка максимально быстрая, простая и грубая, и ненадежная, а на принимающей стороне UDP разбивает каждое сообщение в очередь, а программа принимающей стороны считывает данные из очереди.
Некоторые люди скажут, что протокол UDP такой ненадежный, зачем его до сих пор создают? Сказав это, в мире нет бесполезных людей, есть только люди, которых вы не знаете, как использовать.Хотя UDP ненадежен, он имеет высокую скорость передачи и высокую эффективность.В некоторых сценариях, которые не требуют высокой точности данных, UDP становится очень полезным, например, голос QQ, видео QQ.
розетка розетка
Зачем говорить вложенные слова? Это связано с тем, что, как было сказано ранее, TCP или UDP — это протокол, который представляет собой обмен данными в компьютерной сети на транспортном уровне протокола, проще говоря, является соглашением, таким же, как договор о сотрудничестве, тогда договор мертв, является только существенное действие для выполнения контракта, поэтому либо TCP, либо UDP, чтобы иметь эффект, нам нужно иметь фактическое поведение, чтобы отразить соглашение для выполнения роли, Так как же заключать эти соглашения? Это что касается сокетов.
socket: Также называемый вложенным словом, это набор интерфейсных API для реализации связи TCP/UDP, то есть, будь то TCP или UDP, через программные сокеты, может быть реализована связь TCP/UCP.Как дескриптор цепочки связи, он содержит 5 видов информации, необходимой для сетевой связи:
Протокол, используемый соединением
IP-адрес локального хоста
Порт протокола локального процесса
IP-адрес удаленного хоста
Порт протокола удаленного процесса
Видно, что сокет содержит ip и порт стороны связи и другой стороны, а также протокол (TCP/UDP), используемый для соединения. Одна из двух взаимодействующих сторон (предварительно называемая: клиент) инициирует запрос на соединение с другой стороной (предварительно называемой: сервером) через сокет (вложенное слово), и сервер прослушивает запрос в сети, и когда он получает запрос от клиента После этого, в соответствии с информацией, содержащейся в сокете, клиент находится, и соответствующий запрос отправляется клиенту, и описание сокета отправляется клиенту После подтверждения двух сторон устанавливается соединение . Таким образом, процесс соединения между сокетами состоит из трех этапов:
Мониторинг сервера: сервер отслеживает состояние сети в режиме реального времени и ожидает запроса на подключение, отправленного клиентом.
Запрос клиента: клиент инициирует запрос на подключение к удаленному хост-серверу на основе своего IP-адреса и порта протокола.
Подтверждение соединения: после того, как сервер получает запрос на соединение сокета, он отвечает на запрос и отправляет описание сокета сервера клиенту.После того, как клиент получает подтверждение, две стороны устанавливают соединение и проводят обмен данными.
Обычно сокетное соединение является TCP-соединением, поэтому, как только сокетное соединение установлено, две взаимодействующие стороны начинают отправлять данные друг другу до тех пор, пока одна или обе из них не отключатся.
Socket широко используется для обмена мгновенными сообщениями (QQ и другое программное обеспечение для чата) и других приложений.
HTTP-протокол
HTTP-протокол: Протокол передачи гипертекста, также известный как протокол передачи гипертекста, представляет собой протокол, основанный на стеке протоколов TCP/IP, на уровне представления и уровне приложений (протокол TCP на транспортном уровне).
TCP/IP — это протокол транспортного уровня, используемый для передачи данных в сети;
Протокол HTTP — это протокол прикладного уровня, основанный на протоколе TCP, который используется для упаковки данных, и программа использует его для связи, что позволяет просто и эффективно обрабатывать передачу и идентификацию данных при обмене данными.
Однако широко используемое соединение HTTP представляет собой конкретное приложение на прикладном уровне, основанное на протоколе HTTP. Как было сказано выше, после установления сокетного соединения состояние соединения сохраняется, а вот HTTP-соединение отличается: оно основано на коротком соединении протокола tcp, то есть клиент инициирует запрос, а после ответа сервера на запрос соединение будет автоматически разорвано и не будет поддерживаться вечно. .
URL
Я говорил о tcp, udp, http... и т. д., которые все являются точками знаний для конкретной проблемы, а именно:На чем основан принцип инициирования и ответа на запросы в разработанных нами веб-приложениях. Все мы знаем, что большинство веб-приложений запрашиваются через HTTP, а URL — это конкретная реализация HTTP для установления соединения и передачи данных, поэтому здесь мы кратко поговорим об URL.
URL: Унифицированный указатель ресурсов Унифицированный указатель ресурсов. Проще говоря, это адрес, используемый для идентификации определенного ресурса в сети и содержащий информацию для пользователей, чтобы найти ресурс HTTP использует его для передачи данных и установления соединений. URL-адрес состоит из следующих компонентов:
протокол
Адрес сервера (доменное имя или IP+порт)
дорожка
имя файла
Например: https://www.baidu.com/index.html в
https:// — это протокол. Конечно, HTTP и ftp — тоже.
www.baidu.com — это адрес сервера. Конечно, вы также можете узнать IP-адрес Baidu. Например, я использую команду ping, чтобы получить IP-адрес Baidu. 14.215.177.39, тогда я смогу открыть Baidu с помощью http://14.215.177.39
index.html содержит путь и имя файла.Конечно, обычно index.html можно не указывать, поэтому вы не увидите его при открытии Baidu.
DNS
DNS:Сервер доменных имен, сервер доменных имен. Это сервер, который преобразует доменное имя и соответствующий IP-адрес. Таблица доменных имен и соответствующих IP-адресов хранится в DNS для разрешения доменных имен сообщений. Когда мы обычно разрабатываем, адрес интерфейса, предоставляемый серверной частью, обычно состоит из IP-адреса и номера порта (8080 или что-то подобное), но когда мы публикуем веб-сайт, нам обычно нужно изменить IP на доменное имя. Зачем? Подумайте об этом, например, адрес Google — 89.12.21.221:9090, а адрес Baidu — 132.21.33.221:8766. . . То есть у вас совсем нет желания запоминать эти беспорядочные числа, верно? Но доменные имена разные, например, google.com от Google, baidu.com от Baidu, вы хоть раз помните? Следовательно, чтобы решить эту проблему, необходимо использовать доменное имя для сопоставления IP-адреса, чтобы его было легко запомнить и использовать.
Поэтому, когда пользователь вводит https://www.baidu.com в браузер, он выполняет следующие шаги:
Браузер ищет DNS-запись разрешения в собственном кеше по адресу, если есть, возвращает напрямую IP-адрес, в противном случае браузер проверит, есть ли DNS-запись разрешения для доменного имени в операционной системе. (файл hosts), и если да, то вернуть его.
Если нет записи разрешения DNS для доменного имени в кэше-кэше браузера и хостых системной системы, или если он истек, запрос будет отправлен на сервер доменного имени для разрешения доменного имени.
Запрос сначала LDNS (локальный сервер доменных именных имен), он пытается разрешить доменное имя, если LDN не будет разрешен, запрос напрямую для разрешения доменного имени корневого домена
Корневой сервер имен возвращает запрошенный адрес основного сервера имен (gTLDServer) в LDNS.
В этот момент LDNS инициирует запрос разрешения на сервер gTLD, возвращенный на предыдущем шаге.
После получения запроса на разрешение сервер gTLD ищет и возвращает адрес сервера доменных имен сервера имен, соответствующего этому доменному имени.Этот сервер имен обычно является зарегистрированным вами сервером доменных имен (например, Ali dns, Tencent dns и т. д.). )
Сервер доменных имен сервера имен будет запрашивать сохраненную таблицу отношений сопоставления между доменными именами и IP-адресами.Обычно целевые записи IP получаются в соответствии с именем домена и возвращаются на сервер доменных имен сервера DNS вместе со значением TTL.
Возвращает IP-адрес и значение TTL, соответствующие доменному имени. Локальный DNS-сервер кэширует соответствующую связь между доменным именем и IP-адресом. Время кэширования контролируется значением TTL.
Результат разрешения возвращается пользователю, и пользователь кэширует его в локальном системном кеше в соответствии со значением TTL, и процесс разрешения доменного имени завершается.
Инициация HTTP-запроса и ответ
Если тема этой статьи — сетевое общение, то на этом можно и закончить, но сегодня мы поговорим оИнициация и ответ на запросы в веб-приложениях и принципы рендеринга страниц, так что вышесказанное является лишь предзнаменованием. В разработке веб-программы, как правило, есть точки фронтенда и бэкенда.Фронтенд отвечает за запрос данных и отображение страниц из бэкэнда, а бэкенд отвечает за получение запросов и отправку ответы обратно на интерфейс.Мост сотрудничества между ними что? это API Что такое API? Разве это не просто URL? Что такое URL? Как упоминалось выше, это специфический носитель HTTP-соединения. следовательно, Будь то интерфейс или серверная часть, понимание HTTP, будь то ваше собственное понимание программирования или сотрудничество с коллегами, приносит большую пользу. Теперь, согласно пониманию изложенных выше пунктов знаний, разберем и решим первую упомянутую выше проблему: Каков процесс от ввода пользователем URL-адреса до браузера, отображающего страницу пользователю?
Пользователь вводит URL-адрес, и браузер получает URL-адрес.
Браузер (прикладной уровень) выполняет разрешение DNS (если вводом является IP-адрес, этот шаг пропускается)
В соответствии с проанализированным IP-адресом + портом, браузер (прикладной уровень) инициирует HTTP-запрос, который передается в запросе (заголовок запроса (который также может быть разделен на строку запроса и заголовок запроса), тело запроса),
Заголовок содержит:
Запрошенный метод (получить, опубликовать, поставить..)
Протокол (http, https, ftp, sftp...)
Целевой URL (конкретный путь запроса и имя файла)
Некоторая необходимая информация (кеш, куки и т.д.)
корпус содержит:
содержание запроса
Когда запрос поступает на транспортный уровень, протокол tcp обеспечивает надежный сервис передачи байтового потока для передаваемого сообщения, обеспечивая безопасность и надежность процесса передачи за счет трехэтапных рукопожатий и других средств. Обеспечивает портативную передачу больших объемов данных путем разделения больших блоков данных на сегменты.
На сетевом уровне сетевой уровень получает Mac-адрес получателя посредством адресации ARP, а протокол IP делит его на пакеты данных на транспортном уровне для передачи получателю.
Данные поступают на канальный уровень, и фаза запроса завершена.
После того, как приемник получает пакет данных на канальном уровне, он передается на уровень приложения уровень за уровнем, и прикладная программа приемника получает сообщение запроса.
После того, как получатель получает HTTP-запрос от отправителя, он ищет запрошенный файловый ресурс (например, HTML-страницу) и отвечает на сообщение.
После того как отправитель получит ответное сообщение, если код состояния в сообщении указывает на то, что запрос выполнен успешно, он принимает возвращенный ресурс (например, файл HTML) и отображает страницу.
Оказание страницы
Когда запрос инициирован и ответ завершен, браузер получит содержимое ответа, но браузер получит строку кодов или URL-ссылок, как преобразовать эти коды в удобочитаемый интерфейс. Это работа браузера. В настоящее время на рынке существует не менее 100 видов браузеров, и каждый браузер можно разделить на несколько категорий в зависимости от ядра.Каждый тип браузера имеет разные принципы и процессы рендеринга страниц.
Но в целом страницы рендеринга каждого браузера в основном следуют процессу, показанному на следующем рисунке:
На картинке есть несколько английских слов, которые могут быть трудными для понимания. Это не имеет значения. Позвольте мне сначала объяснить:
HTML parser: парсер HTML, его суть заключается в том, чтобы интерпретировать текст HTML в дерево DOM.
CSS parser: синтаксический анализатор CSS, его суть заключается в добавлении информации о стиле к каждому элементу объекта в DOM.
JavaScript-движок: виртуальная машина, которая специализируется на обработке JavaScript-скриптов. Суть ее заключается в разборе JS-кода и применении логики (операций HTML и CSS) к макету, чтобы представить соответствующие результаты в соответствии с требованиями программы.
DOM tree: Дерево объектной модели документа, то есть древовидная структура HTML и соответствующий интерфейс, сгенерированный браузером, анализирующим HTML-страницу с помощью HTMLparser.
render tree: дерево рендеринга, которое представляет собой древовидную структуру, созданную движком браузера с помощью дерева DOM и дерева правил CSS. В отличие от дерева dom, оно имеет только содержимое, которое должно быть окончательно представлено, например, или узлы с display:none не существуют в дерево рендеринга.
layout: Также называется перекомпоновкой, поведением при рендеринге. Когда геометрический размер любого узла в дереве рендеринга изменяется, дерево рендеринга будет перестроено.
repaint: Redraw, поведение при рендеринге. При изменении атрибута стиля любого элемента в дереве рендеринга (геометрический размер не изменился) дерево рендеринга будет перерисовано, например, изменение цвета шрифта, фона и т. д.
Следовательно, согласно интерпретации ключевых слов и последовательности действий блок-схемы, можно сделать вывод, что парсинг и рендеринг страницы браузером в основном включает следующие процессы:
Браузер HTMLParser основан на принципах глубинного обхода анализируемого в HTML дерева DOM.
Разобрать CSS в дерево правил CSS (дерево CSSOM).
Дерево рендеринга строится из дерева DOM и дерева CSSOM.
макет: Рассчитать положение всех узлов на экране в соответствии с полученным деревом рендеринга.
paint: пройдите по дереву рендеринга и вызовите аппаратный графический API для рисования каждого узла.
Оптимизация производительности интерфейса
Для рендеринга страницы это в основном процесс.После прочтения его, есть ли какой-то момент, который можно оптимизировать в реальном кодировании? нет? Поскольку многие детали не описаны, чтобы найти момент, который можно оптимизировать, вот несколько ключевых шагов в процессе рендеринга страницы:
1. Разбор HTML:
Как упоминалось выше, синтаксический анализ HTML заключается в том, что синтаксический анализатор HTML браузера анализирует HTML в дереве dom.В процессе синтаксического анализа браузер анализирует HTML сверху вниз в соответствии со структурой файла HTML.Элементы HTML анализируются в глубину образом, в то время как теги, такие как скрипт, ссылка и стиль, будут блокировать процесс синтаксического анализа. Ситуации блокировки включают:
Внешние стили блокируют выполнение внутренних скриптов.
Внешние стили загружаются параллельно с внешними скриптами, но внешние стили блокируют выполнение внешних скриптов.
Если внешний скрипт имеет атрибут async, внешний стиль не влияет на загрузку и выполнение внешнего скрипта.
Если тег ссылки создан динамически (сгенерирован js), загрузка и выполнение внешних скриптов не будут заблокированы независимо от атрибута async.
2. Разбор CSS:
Функция синтаксического анализа CSS заключается в объединении и анализе стилей во многих файлах CSS в правила стиля с древовидной структурой.В процессе анализа стиля селектор CSS по умолчанию анализируется справа налево. А почему справа налево, а не слева направо, а не слева налево... Вот, например, каштан: Если сейчас есть такой стиль:
Из сравнения двух рисунков можно увидеть несколько моментов:
Дерево справа менее сложно, чем дерево слева
Общий стиль дерева справа имеет меньшую степень перекрытия, чем стиль слева.
Дерево справа имеет меньше узлов от корня, чем дерево слева
Вы можете не увидеть никаких проблем, просто взглянув на эти точки, но вам нужно знать: парсер css в браузере отвечает за разбор css и вычисляет стиль для каждого узла, так что хотя парсеру css нечего делать, однако , каждый узел необходимо обходить и искать, а объем вычислений чрезвычайно велик, поэтому способ разбора является ключевым моментом, определяющим его производительность. подобно
1#parant .a{} 2和 3.a{}
Подсчитано, что большинство людей подумают, что производительность первого лучше, чем у второго, но на самом деле это не так. #paran .a{} означает, что синтаксический анализатор css должен сначала найти #parent, а затем найти узел, в котором находится .a под ним. Последний может быть непосредственно связан с .a{}, так что очевидно, какой путь лучше.
3. Выполнение скрипта:
Когда браузер парсит HTML, он сразу же парсит скрипт, когда встречает тег
оптимизация производительности
После разговора об этих степенях я считаю, что у каждого есть несколько точек зрения на оптимизацию производительности.Вот краткое изложение оптимизаций производительности, обычно используемых в ежедневном процессе разработки:
1. Для CSS:
Оптимизируйте путь селектора: хотя хороший селектор css может сделать разработку более понятной, это большая проблема с производительностью для синтаксического анализа css, поэтому он более склонен, чем .a .b .c{} Пишите .c{} для всех.
Сжатые файлы. Максимально сократите размер файлов CSS, чтобы уменьшить нагрузку на загрузку ресурсов.
Слияние селекторов: объедините ряд селекторов с общим содержимым атрибутов, что может сократить пространство и ресурсы.
Точный стиль: сведите к минимуму ненужные настройки свойств. Например, если вам нужно установить только значение {padding-left: 10px}, избегайте метода записи {padding: 0 0 0 10px}.
Карта спрайтов: объедините несколько небольших значков в одно изображение в разумном месте, чтобы всем изображениям требовался только один запрос, а затем получайте соответствующий значок путем позиционирования, что позволяет избежать траты ресурсов на один запрос значка.
Избегайте подстановочных знаков: селекторы .a .b *{}, подобные этому, в соответствии с порядком синтаксического анализа справа налево, сталкиваются с подстановочными знаками (*) во время синтаксического анализа и возвращаются для обхода всего dom, поэтому проблема производительности огромна.
Используйте меньше Float: Float требует много вычислений во время рендеринга, поэтому старайтесь использовать его как можно меньше.
Значение 0 к единице: для значения 0 старайтесь не добавлять единицу для повышения совместимости.
2. Для JavaScript:
Поместите тег сценария после тела, насколько это возможно, чтобы странице не приходилось ждать, пока DOM продолжит выполнение после выполнения js, и чтобы страница отображалась как можно скорее.
Включите код скрипта как можно больше,
Что может CSS, постарайтесь не использовать для этого JavaScript. В конце концов, синтаксический анализ и выполнение JavaScript слишком прямолинейны и грубы, а CSS более эффективен.
js максимально сжаты, чтобы уменьшить нагрузку на загрузку ресурсов.
Старайтесь не использовать стили DOM один за другим в js, максимально заранее определите стили CSS, а затем измените стили DOM, изменив имена стилей, чтобы централизованные операции могли уменьшить количество перекомпоновок или перерисовок.
Создавайте DOM как можно меньше в js, но заранее похороните его в HTML и используйте display:none, чтобы скрыть его, и вызывайте его в js по мере необходимости, чтобы уменьшить насильственную работу js с dom.
3. Для HTML:
Избегайте написания кода CSS непосредственно в HTML.
Используйте Viewport для ускорения рендеринга страницы.
Используйте семантические теги, чтобы уменьшить код CSS, повысить читабельность и SEO.
Уменьшите использование тегов, синтаксический анализ DOM - это процесс большого обхода, сокращение ненужных тегов, может уменьшить количество обходов.
Избегайте пустых значений для src, href и т.д.
Уменьшите количество DNS-запросов.
Выше приведено все содержание статьи. Как правило, вводная статья предназначена для того, чтобы помочь людям начать работу, а статья для продвинутых — для продвижения вперед. Так же, как в книгах по Java есть вводные и расширенные руководства, большой путь. Некоторые баллы знаний предназначены для того, чтобы дать читателям предвидение и общее понимание запроса страницы и презентации. Поскольку задействовано слишком много баллов знаний, каждый балл знаний может быть использован для написания книги, поэтому все используют эта статья в качестве руководства.Если вам нужно провести глубокое исследование определенного пункта знаний, то ищите соответствующие книги для изучения.Если вам это не нравится, не распыляйтесь.
Думаете, эта статья была вам полезна? пожалуйста, поделитесь с большим количеством людей Обратите внимание на «Безграничное программирование» и улучшите свои навыки принуждения.