Сколько вкладок можно открыть в браузере
Некоторые power-юзеры начинают день с дефолтного конфига в 40-50 открытых вкладок. В течение дня к этой группе может прибавиться ещё пару десятков, а то и сотня. Хотя это крайне нестандартный поведенческий паттерн, но некоторые именно так и работают. Любопытно посмотреть, как ведут себя браузеры в подобной нештатной ситуации. Один из разработчиков Firefox, аспирант Грегор Вагнер, решил провести тесты на последних сборках Chrome и Firefox.
Вагнер разрабатывает различные стратегии распределения памяти для Firefox. В последних версиях Firefox разработчики значительно оптимизировали браузер в этом отношении.
150 сайтов взяты из списка самых популярных сайтов. Хабрахабр туда не вошёл, потому что занимает лишь 462-е место в мире по популярности.
Для последнего билда Firefox Nightly (Firefox 8) получены следующие результаты:
real 6 мин 14,406 с
user 3 мин 55,302 с
sys 0 мин 49,366 с
Вот что показал canary-билд Chrome:
real 28 мин 55,573 с
user 21 мин 58,383 с
sys 14 мин 40,860 с
Как видим, разница просто огромная. Оказалось, что Chrome начинает с большим трудом открывать новые вкладки примерно после 70-й. На 150 сайтах Грегор даже не мог нормально скролить страничку. Firefox, в свою очередь, вёл себя вполне нормально, как будто и нет других открытых табов.
В чём же причина? Дело в том, что Firefox использует модель «один процесс — много ветвлений» (PDF), так что все 150 вкладок укладываются в 27 тредов и 2,02 ГБ RAM.
В Chrome используется противоположный подход, в котором задачи разбиваются по нескольким процессам. В результате процесс Google Chrome Renderer постоянно использует 100% CPU и занял 1,5 ГБ на 150 вкладках. Основной процесс Google Chrome использует 212 тредов и 1,3 ГБ. Есть ещё дополнительный процесс Helper с 200 МБ.
Вот результат выполнения бенчмарка V8 в Firefox на полной загрузке всех 150 страниц.
Сравните с результатом при одной открытой вкладке:
Попытка запустить тест V8 на Chrome не удалась: браузер остановил рендеринг, процесс Google Chrome не опускался ниже 100% CPU.
Вывод от Грегора Вагнера: если вам нужно много вкладок, используйте Firefox! (Пользователи Opera могут не согласиться с таким выводом, говорят, этот браузер на удивление хорошо работает с большим количеством вкладок)
Mozilla Firefox и Яндекс.Браузер умеют работать с десятками открытых вкладок. Эти браузеры сбрасывают в кэш содержимое открытых вкладок после определенного времени их неактивности, что снижает расход оперативной памяти. Если в Google Chrome открыть большое количество вкладок, программа начнет заметно подтормаживать, особенно на компьютерах с небольшим объемом оперативной памяти. Это будет заметно, например, в процессе воспроизведения анимации при работе с пользовательским интерфейсом, а также по задержкам перед выполнением тех или иных команд.
Преимущества и недостатки
В конце 2018 года в браузере Google Chrome появилась функция управления вкладками, но только в тестовой версии программы. Пользователям, которым необходимо открывать действительно большое количество веб-страниц, приходится решать проблему быстродействия с помощью специализированных расширений для браузера, среди которых выделяются OneTab и Great Suspender. Примечательно, что эта проблема актуальна как для компьютеров с 4 ГБ оперативной памяти (ОЗУ), так и для мощных, оснащённых 32 ГБ ОЗУ.
Основное преимущество большого количества открытых вкладок, если они действительно необходимы для работы, – быстрый доступ к нужной информации, различным сервисам. Недостатки:
- чем больше веб-страниц открыто в браузере, тем тяжелее в них сориентироваться, и отыскать нужную;
- каждая открытая веб-страница потребляет оперативную память, что отражается на производительности компьютера;
- люди плохо справляются с многозадачностью, и постоянное переключение между большим количеством веб-страниц в большинстве случаев отрицательно сказывается на эффективности работы
Психологи считают, что люди, открывающие одновременно большое количество сайтов, боятся потерять информацию, не попасть на нужную веб-страницу в другой раз. Еще одно мнение заключается в том, что хаос в браузере является следствием такого же беспорядка мыслей в голове.
Каждая вкладка расходует оперативную память – запускается в отдельном процессе. Последние можно замораживать для освобождения ОЗУ. На этой возможности и построена работа плагинов, предназначенных для ускорения работы браузера.
Как повысить удобство работы
В браузере Google Chrome есть экспериментальная функция для группировки вкладок, – «Tab Groups».
Другие экспериментальные функции: Scrollable TabStrip – если вкладки не помещаются в строку, появляется строка прокрутки вместо уменьшения размера вкладок на панели; Tab Hover Card Images – при наведении курсора мыши на название открытой вкладки всплывает миниатюра с ее содержимым.
Через контекстное меню названия открытой веб-страницы она добавляется в новую или уже существующую группу, которые идентифицируются по имени и цвету.
Способы ускорения работы браузера
Методов увеличения быстродействия браузера несколько.
Использование встроенного диспетчера задач
Для экономии оперативной памяти можно закрывать веб-страницы, которые потребляют много ресурсов. Это можно сделать с помощью диспетчера задач, встроенного в Google Chrome.
-
В главном меню разверните содержимое пункта «Дополнительные инструменты» и вызовите «Диспетчер задач» или воспользуйтесь клавиатурной комбинацией Shift + Esc.
То же самое можно проделать, отсортировав процессы по уровню использования ресурсов процессора.
Плагин Great Suspender
Данное расширение переводит неактивные вкладки в спящий режим – помещает их содержимое в кэш, благодаря чему освобождается оперативная память. После переключения на «спящую» веб-страницу придется дождаться ее обновления.
После этого откроется окно с настройками Great Suspender.
Осталось внести необходимые коррективы в работу плагина.
-
Укажите время, по истечению которого вкладка выгрузится в кэш.
В разделе «Горячие клавиши» можно задать клавиатурные комбинации для управления плагином.
-
Кликните по пункту «Изменить горячие клавиши», выберите действие и нажмите желаемую клавиатурную комбинацию.
Все изменения вступают в силу в режиме реального времени, дополнительно сохранять настройки не нужно.
Альтернатива плагину Great Suspender – Tab Wrangler, но он закрывает неиспользуемые на протяжении заданного времени вкладки и быстро открывает их в случае возникновения подобной необходимости. Данный плагин поддерживает дополнительные условия закрытия вкладок, а также список зафиксированных вкладок и сайтов, импорт и экспорт настроек.
Открывать действительно большое количество вкладок в Google Chrome можно и на компьютере или ноутбуке с 4 ГБ оперативной памяти, но для предотвращения снижения быстродействия браузера и использования всей свободной ОЗУ стоит воспользоваться расширением Great Suspender, Tab Wrangler или другим подобным решением. Также обязательно подумайте о том, насколько актуально одновременное открытие десятков веб-страниц.
Дайте знать, что вы думаете по этой теме статьи в комментариях. Мы крайне благодарны вам за ваши комментарии, лайки, отклики, дизлайки, подписки!
Пожалуйста, опубликуйте ваши комментарии по текущей теме материала. Мы очень благодарим вас за ваши комментарии, лайки, отклики, дизлайки, подписки!
Нередко люди жалуются на снижение скорости работы своего компьютера из-за большого количества одновременно открытых вкладок браузера. В такой ситуации можно винить браузер, использовать специальные расширения для работы с вкладками, а можно просто отучить себя от вредной привычки постоянно открывать огромное количество неиспользуемых веб-страниц.
Почему в браузере зачастую открыто много вкладок?
Люди часто оставляют вкладки браузера открытыми, чтобы дочитать статью, досмотреть видеоролик, сериал или фильм, а потом благополучно забывают об их существовании. У многих пользователей активировано автоматическое сохранение открытых вкладок браузера, а это означает, что после его закрытия и последующего запуска вкладки никуда не деваются, а остаются открытыми. Забыв о ранее открытых веб-страницах, пользователь, не задумываясь, открывает еще несколько сайтов и начинает заниматься своими делами.
Не все понимают, что забытые вкладки браузера продолжают быть активными и снижают производительность компьютера, особенно при использовании требовательных к объему оперативной памяти браузеров вроде Google Chrome. В связи с этим рекомендуется сохранять адреса интересных сайтов в закладки, а открытыми держать только те веб-страницы, которые действительно используются постоянно. Кроме того можно установить специальное расширение, которое временно замораживает ненужные вкладки.
Сколько вкладок браузера можно держать одновременно отрытыми?
Можно держать открытыми хоть 50 вкладок браузера, если при этом ваш компьютер продолжает работать без каких-либо «тормозов».
Однако существует сразу несколько причин, по которым этого делать не стоит. Во-первых, когда в браузере открыто слишком много вкладок, вы попросту перестаете видеть содержание каждой из них, переключаетесь наугад и тратите кучу времени на поиск нужной веб-страницы.
Во-вторых, гораздо удобнее добавлять нужные сайты в закладки или на экспресс-панель, чтобы в нужный момент вернуться к ним. Кроме того можно ориентироваться по истории посещений либо использовать веб-сервисы, предназначенные для создания и хранения заметок, наподобие Evernote.
В-третьих, рекомендуется держать открытыми не более 9 вкладок браузера, потому что подобный подход позволяет обеспечить удобную работу с горячими клавишами. С помощью клавиатурных комбинаций Ctrl + 1, 2, 3…9 вы сможете быстро перейти на нужную веб-страницу и при этом всегда будете видеть названия всех открытых вкладок.
Если вы используете ноутбук или компьютер с хорошими характеристиками и достаточным объемом ОЗУ (8 Гб и более), количество одновременно открытых вкладок браузера может быть неограниченные, весь вопрос в удобстве подобного подхода. Но на слабеньких ПК уже при 10 одновременно открытых веб-страницах пользовательское устройство начнет работать на порядок медленнее.
Что случится, если в браузере будет открыто слишком много вкладок?
Важно понимать, что для каждого открытого сайта запускается свой собственный процесс, который потребляет ресурсы, в основном оперативную память. Первым намеком на то, что неплохо бы уменьшить количество открытых вкладок браузера, будет появления тормозов при переходе с одной вкладки на другую. Когда выделенная для работы браузера оперативная память закончится, вкладки практически перестанут загружаться и производительность компьютера заметно снизится. Для обеспечения стабильной и быстрой работы ПК необходимо периодически следить за тем, чтобы показатели, демонстрируемые в диспетчере задач, не достигали пиковых значений.
Если ваш ноутбук обладает минимально допустимыми характеристиками или он уже «старый», то от большого количества одновременно открытых в браузере вкладок он может перегреться и просто отключиться без какого-либо предупреждения. Если помимо браузера пользователь работал еще в какой-то программе, после внезапного выключения, не сохраненные данные, могут быть утеряны.
Советы и выводы
Если у вас слабый ноутбук или ПК, в первую очередь стоит подобрать браузер, который потребляет меньше всего оперативной памяти. Самые популярные браузеры потребляют следующее количество оперативной памяти при 10-12 открытых вкладках:
- Google Chrome – 1020 Мб.
- Mozilla Firefox – 867 Мб.
- Opera – 744 Мб.
- Яндекс.Браузер – 639 Мб.
Из приведенных выше цифр понятно, что для слабых ПК Google Chrome не подойдет ввиду своей «прожорливости». Самыми экономичными вариантами в плане потребления оперативной памяти на сегодняшний день являются Opera и Яндекс.Браузер.
Если ваша деятельность не позволяет сократить количество одновременно открытых вкладок браузера, то для оптимизации работы можно использовать специальные программы. Например, для браузера Firefox доступно расширение OneTab. Достаточно установить данное дополнение, кликнуть по соответствующему значку в верхней панели справа, после чего все открытые вкладки браузера превратятся в активные ссылки и сгруппируются на одной странице.
Как показывает практика, подобный подход позволяет освободить сотни мегабайт оперативной памяти.
Пожалуйста, оставьте ваши комментарии по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, дизлайки, подписки, отклики, лайки!
Пожалуйста, оставьте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, подписки, лайки огромное вам спасибо!
У меня в браузере обычно — от 50 до 120. Иногда — 200, в другой раз — 15.
Это радикально упростило поиск и чтение статей. И даже волосы мои стали шелковистей. Ну т.е. стал продуктивней.
Откуда берется столько вкладок?
В основном они появляются из Inoreader, иногда из соц-сетей и других ресурсов.
Новые публикации просматриваю раз в неделю-две или реже. Что-то остается открытым, что-то отправляется на потом, но чаще остается открытым.
За раз получается просматривать много. Но одно из преимуществ такого подхода — это возможность получить более полную картину из разных точек зрения.
Кроме того, читать сразу несколько статей по одной тематике намного легче, чем каждую статью по отдельности.
Что делает расширение?
Демо-видео вместо тысячи слов.
Вкладки группируются по главному содержанию, используя ограниченный «мешок слов». Слова для мешка определяются по частоте упоминания плюс разные эвристики.
Чтобы вообще найти содержание страницы, используется адаптация Readability.js. Это версия библиотеки, которую Mozilla использует в Firefox, для показа страниц в режиме читателя.
К сожалению, Readability.js далеко не всегда находит содержание страниц. Поэтому для особо популярных ресурсов сделана отдельная предобработка.
Сейчас здесь: Reddit, HackerNews и YouTube.
Список точно не исчерпывающий. Если у кого-то появиться необходимость добавить новый ресурс, то это можно сделать через GitHub. Там же можно оставить и другую обратную связь, т.к. расширение не собирает какую либо аналитику.
Также есть отдельные ресурсы, страницы которых сортируются только по URL, если таких — больше одной. Это страницы GitHub и GitLab. Т.о. вы получите группировку в соответствии с файловой структурой проектов.
Сделано специально для umputun. Ну почти.
Алгоритм не сверхсложный, поэтому работает полностью локально без особой нагрузки. Бывает он приятно удивляет даже меня — разработчика, который постоянно прокручивает алгоритм в голове.
В одном случае, это были две статьи, которые совместно подсказали новую идею. Тематика у них была разная, но были общие ключевые слова, поэтому Smart TabS разместил их рядом.
В другом случае, это был браузер для рабочих вопросов. После некоторых подсказок Smart TabS разместил вкладки намного удачней, чем я ожидал, так что работать стало намного проще.
Да, бывают ситуации, когда вкладки размещаются не совсем так, как могли бы. Тогда их можно самостоятельно разместить там, где нужно. Они будут сохранять указанное расположение, пока вы так или иначе его не измените.
Также, в настройках расширения, можно указать домены, страницы которых не будут проверяться на схожесть. Это могут быть домены, для которых трудно определить главное содержание или их содержание слишком чувствительное.
Например, веб-приложения, почта, соц-сети. По умолчанию, сейчас сюда входят: Facebook, Netflix, Trello, Todoist, Inoreader, Feedly, Gmail и др. сервисы Google.
Если уж совсем нет желания, что-то показывать расширению, то в инкогнито-режиме его работа запрещена на уровне API браузера.
Поддержка браузерами
Расширение сейчас можно поставить для Firefox и Chrome.
Для Safari оно пока не доступно, не смотря на появление WebExtension API в 14-й версии. Там почему-то не добавили поддержку tabs.move(. ), чтобы можно было автоматически перемещать вкладки.
Другие браузеры особе не проверялись, хотя, по идее, для Chromium-based браузеров может быть возможность поставить пакет для Chrome.
В этом посте я хотел сосредоточиться на проблеме и ее решении с помощью Smart TabS, так сказать, на публичной стороне вопроса.
В следующей части планирую рассказать о том, что остается «за кулисами»: о развитии идеи, управлении проектами и деталях разработки.
… и опоздал на 3 года. В идеале должно быть так: пользователь запускает браузер, и браузер показывает то, что нужно пользователю. Но пока такого не реализовали приходится пользоваться поисковыми системами. В идеале должно быть так: пользователь открывает поисковую систему, вводит поисковый запрос, и она показывает то, что нужно пользователю. Но пока кнопка «I feel lucky» не так хорошо работает (хотя в последнее время ощутимо движение в этом направлении), приходится иногда переходить по нескольким адресам со страницы поисковой выдачи.
Сценарий использования поисковых систем у меня, видимо, закреплен исторически (когда интернет был медленный): попадая на страницу поисковой выдачи, я открывал несколько вкладок в фоновом режиме, и пока остальные загружались, вполне можно было уже прочитать первую вкладку. В случае, когда находил нужную информацию на одной из вкладок, остальные приходилось закрывать вручную. Если не закрыл сразу, вкладки оставались висеть, раздувая количество открытых вкладок в браузере, которые, как правило, редко после этого закрывались.
К тому же, если переходишь на странице по ссылкам, которые открываются в новом окне, создается несколько связанных между собой (логически) вкладок. Когда находишь нужную информацию, не всегда можно вспомнить какие вкладки связаны между собой, можешь закрыть не все, что также ведет к раздуванию количества открытых вкладок.
Мне всегда нужна была кнопка «Нашел», которая бы подчищала за мной последствия поиска (назовём её «I was lucky»). После того, как окунулся в мир расширений для браузеров, я подумал, что это то, что может помочь в данном случае. Так смутно начало появляться желание написать расширение, которое бы решало мои задачи.
Расскажу вам свою историю, рассказ буду вести в хронологическом порядке, выводы могут оказаться неожиданные.
Первый шаг на пути
Первым делом взялся за настройку инфраструктуры: webpack + babel. И сразу же мне не понравилось, что babel дублировал в каждом модуле код для своих хелперов. Можно было настроить, чтобы он использовал объект babelHelper , но тогда файл с кодом babelHelper нужно было подключать в конфигурации webpack. Хранить такой файл в проекте и указывать его в entry было некрасиво, я сделал плагин для вебпака, который выполнял это за меня автоматически. Потратив много сил на первый шаг и написав ещё немного кода для самого расширения, я немного притормозил.
Фундамент
Время шло, а в наличии был только плагин для вебпака, который никак не решал моих задач. И каждый раз, когда я что-то искал и не закрывал вкладки, была мысль: «Хорошо бы доделать то расширение. » Желание росло и росло, и вот, в один прекрасный день, количество переросло в качество.
При переходе на страницу могут быть различные варианты. Самый простой: один запрос — один ответ от сервера (200). Самый сложный: один запрос — несколько серверных перенаправлений (3xx), после чего клиентское перенаправление (с помощью или javascript), сверху ещё и history API. И комбинации между ними, как правило, большинство сайтов попадает в эту категорию.
Простой случай перехода:
Сложный случай перехода:
То есть сохранить адрес страницы и при переходе проверять только его не всегда достаточно. Поэтому нужно создать логический Переход, куда записывать все адреса, встретившиеся на пути, а потом проверять, что логический Переход содержит в себе сохраненный адрес. Задача понятна, но не все так прямолинейно в исполнении.
В Хроме есть два API, связанных с навигацией: webNavigation и webRequest — каждый со своими событиями. Первый — связывает переходы и UI браузера, последний — нижележащие сетевые запросы. Поэтому, если изменение адреса на странице произошло за счет history API, не будет никаких событий у последнего, а если во время сетевого запроса происходят перенаправления, то первый об этом никак не сообщает. Следовательно, нужно использовать оба АПИ, собирая по щепотке от каждого события каждого АПИ, формировать один логический Переход.
Как указано в документации, события для webNavigation (wN) выполняются в следующем порядке:
Интересующие события webRequest (wR):
Но между собой события wR и wN не имеют определенного порядка (на аналогичных стадиях запроса), т.е. в каких-то случаях wN.onBeforeNavigate может выполниться раньше wR.onBeforeRequest , в каких-то наоборот. Что немного усложняет логику работы.
Для этих АПИ нужно указывать соответствующие разрешения в манифесте расширения, а посему при установке расширения, пользователю будет выдаваться пугающий текст о возможностях расширения.
Развитие
… Вернемся к моменту, когда количество переросло в качество. С начала разработки до этого момента прошло существенное количество времени: браузеры стали поддерживать es6 модули, shadow DOM и другие современные фичи. Для сборки проект переехал на Rollup, плагин в этот раз писать не пришлось. После постройки фундамента — возможности получения информации о любом переходе в любой вкладке, осталось реализовать логику парсинга поддерживаемых СЕРПов и показа уведомлений на связанных страницах.
Первая задача достаточно примитивная: знаем адрес СЕРПа, лезем в содержимое страницы с помощью контент скрипта, получаем интересующие нас данные, сохраняем, ждем, когда пользователь перейдет на одну из страниц, чтобы показать ему уведомление с остальными страницами.
Для второй задачи нужна реализация самого уведомления, то что показывать на странице пользователю. И здесь тоже без контент скриптов не обойтись.
Изначально был только один обработчик (он же контроллер), отвечающий за логику при взаимодействии пользователя с поисковыми системами. После чего возникла идея почему бы не показывать уведомления на связанных вкладках, когда пользователь просто переходит по ссылкам, открываемых в новых вкладках. Пришлось переделать логику, сделав ее более универсальной. По аналогии с middleware React/Redux, можно подключать несколько обработчиков Переходов, что в будущем позволит реализовать возможность отключения/включения различных обработчиков в настройках расширения.
Приватность
Так как уведомление — это панель внизу экрана, и добавляется она в разметку страницы, то скрипт на странице может получить доступ к этому элементу так же, как и к любому другому элементу на этой странице. То есть теоретически страница могла бы узнать какой поисковый запрос вы использовали, в каком поисковике и какие другие страницы вам предложены, что не очень хорошо.
На помощь приходит технология под названием shadow DOM. В вебе не рекомендуется использовать closed mode при создании shadowRoot , потому что в этом нет большого смысла (все равно придется хранить ссылку на элемент shadowRoot где-нибудь, если хочется иметь к нему доступ программно; так же можно переопределить функцию attachShadow , чтобы она создавала shadowRoot в открытом режиме, и тогда скрипты подгруженные после переопределения уже будут пользоваться новой версией функции).
В случае же расширения это не так. Контент скрипты и скрипты страницы живут в параллельных мирах. Скрипты со страницы не имеют доступ к объектам, определенным в контент скриптах, контент скрипты же оперируют с нативной реализацией функций DOM объектов (переопределенная функция скриптом со страницы не имеет эффекта на функцию, с которой работает контент скрипт). Соединяя эти два условия, получаем, что можно создать элемент с закрытым shadowRoot , сохранив ссылку на него в переменной.
В этом случае скрипт со страницы сможет получить доступ только к элементу обертке, который для него будет пустой. Он не сможет получить текст запроса или предложенные страницы. Нужно внимательно следить, чтобы в сгенерированных событиях не отдать ссылку на какой-нибудь элемент внутри уведомления или открытый текст. Поэтому в расширении в событиях используются сгенерированные id, а уже background скрипт по этому id понимает что от него требуется. Для страницы же этот id достаточно бессмысленный.
Трудности перевода
Изначально расширение разрабатывалось только для Google Chrome, но так как WebExtensions API, где-то в голове держал возможность портирования в другие браузеры. А наличие webextension-polyfill вселяло уверенность. Но как бы не так. Полифил для этого расширения принес только возможность использования chrome API с промисами.
Firefox стал разочарованием года. Несоответствие chrome API в Фаерфоксе (Bug 1543647, Bug 1595621) оказалось критичным для работоспособности расширения, можно сказать оно в этом браузере не работает (как положено).
Vivaldi был наиболее близок, но также не обошлось. Событие wN.onCreatedNavigationTarget не возникает, когда пользователь открывает ссылку средней кнопкой мыши или через Shift|Ctrl + левая кнопка мыши, вместо этого в событии wN.onCommitted transitionType == 'start_page' , чего нет в chrome API, из-за этого не во всех случаях расширение работает правильно. Так же в Вивальди не работают горячие клавиши для расширений. Что является киллер-фичей в данном случае в Хроме, позволяет намного быстрее переходить по вкладкам и закрывать их, без необходимости использования для этого мышки.
Заключение
В ходе написания кода логика работы показа уведомлений менялась несколько раз, каждый раз упрощаясь. В итоге получилось так, что можно было не городить огород с логическими Переходами, а отлавливать «связанные переходы» пользователя (в событии wN.onCommitted есть флаг transitionType , который указывает из-за чего был переход, во многих случаях он равен «link», означающее что пользователь перешел по ссылке), что значительно бы упростило код и работало во многих случаях, но не во всех.
Так же, не находясь в теме, ожидал большей совместимости с точки зрения webExtensions API. Как всегда — хорошо жить в мире современных браузеров, когда не нужна поддержка старых версий. CSS анимации прекрасная вещь: то, для чего раньше нужно было использовать js библиотеку, теперь делается в несколько строк на css. В расширениях не работают Custom elements, зато работает shadow DOM, позволяющий воспользоваться всеми его возможностями.
Читайте также: