Native client что это за плагин - TurboComputer.ru
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд (пока оценок нет)
Загрузка...

Native client что это за плагин

SomeDemo

Как видите, тут нет ничего сложного — при загрузке страницы сначала с помощью JavaScript производится проверка наличия модуля, и в случае успеха он загружается в контейнер с /> Рисунок 4. Файлы примера Как нетрудно догадаться, сценарий run.py запускает приложение, но нам это совсем не нужно. Вместо этого откроем в браузере html-страницу earth.html. и… получим то самое сообщение (см. рис. 5). Как же так? Ведь плагин мы установили? Рисунок 5. Модуль не загружен Дело в том, что, несмотря на наличие Native Сlient-плагина, модуль не грузится по той простой причине, что он не собран, не откомпилирован, а представлен только исходным кодом (файл earth.сс), на языке С++. Впрочем, в той же папке мы видим файл Makefile, и это позволяет надеяться, что ситуацию можно исправить. Сначала соберём и запустим Standalone-приложение: make debug run После этого запустится самостоятельное приложение, представляющее собой вращающееся изображение земного шара, а в папки примера появится исполняемый файл — earth_debug. Теперь соберём Native client-модуль: make release nacl Если все прошло нормально, появятся ещё два файла — earth.nexe и earth_release.nexe. Можно опять открыть earth.html в браузере, и теперь картинка должна быть совсем другой (см. рис. 6). Рисунок 6. Земля. Рассмотрим пример посложнее. В папке googleclient/native_client/tests/xaos находятся исходники и сценарий сборки известного фрактального конструктора Xaos. Правда, не исходники самого Xaos, их сборочный скрипт скачает отдельно. Собирать просто: ./xaos_tool.sh all И, раскрыв браузером xaos.html, наслаждаемся результатом (см. рис. 7). Рисунок 7. Редактируем фракталы На самом деле в этом и предыдущем примере мы выступаем в роли разработчика. Конечному пользователю приложения достаются уже откомпилированные модули, и всё, что ему нужно, — оснастить браузер Native client плагином. Ну а мы продолжим развлекаться. Теперь приступим к обещанной quake. Тут готового сценария нет, поэтому будем действовать вручную. Заходим в папку googleclient/native_client/tests/quake/ и скачиваем исходные коды игры: wget http://www.libsdl.org/projects/quake/src/sdlquake-1.0.9.tar.gz … wget http://www.libsdl.org/projects/quake/data/quakesw-1.0.6.tar.gz … Теперь их разархивируем: tar -x —strip-components=1 -f sdlquake-1.0.9.tar.gz … tar -x -f quakesw-1.0.6.tar.gz … Должно образоваться множество файлов — исходников и одна директория — /> Рисунок 8. Наши победят! И пока всё… Да, на этом, к сожалению, пока всё. К сожалению, технология пока действительно сырая, и автору не удалось последовательно написать с нуля и запустить Google Native Client-приложение ни на одной платформе. Более того, на данный момент времени NaCL отказывается собираться с Python 2.6.x, браузер с установленным NaCL-плагином неоднократно замечен в неадекватном поведении, некоторые тесты не запускаются под платформой Windows. С другой стороны, API NaCL открыт и документирован (/googleclient/native_client/scons-out/doc/html), поэтому для настоящего энтузиаста нет препятствий попробовать свои силы в написании приложений «невзирая на». Трудно сейчас сказать, насколько перспективным окажется это занятие, но интересным — наверняка. 1. Домашняя страница проекта — http://code.google.com/p/nativeclient. 2. Описания архитектуры GoogleNative Client (PDF) — http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf

Пользователи текущей стабильной версии Google Chrome могут заметить, что в списке установленных плагинов (на chrome:plugins) появился новый — Widevine Content Decryption Module. В Google Chrome OS он появился еще в 26 версии, а до браузера дошел только сейчас. Что это за зверь?

Плагин Widevine Content Decryption Module (Widevine CDM) добавлен в браузер для поддержки Encrypted Media Extensions (EME) API, который в свою очередь появился в спецификации HTML5 для работы с DRM (технические средства защиты авторских прав).

А теперь простыми словами.

Welcome to Native Client

Владельцы аудио- и видео-контента хотят транслировать его в сети средствами HTML5, но не хотят давать право его копировать. Для этого организация W3C добавила EME в спецификацию HTML5. А на стороне браузера поддержкой этого дела должен заниматься специальный плагин (в случае с Google Chrome, это Widevine CDM).

François Beaufort (ç — это французская буква, а не битый пиксель у вас на мониторе), евангелист проекта Chromium и сотрудник Google, объяснил поддержку EME следующим образом. Крупные компании, продвигающие идею защиты онлайн-контента от копирования, не отстанут (для поддержки DRM уже сейчас используют плагины Flash и Silverlight). А EME это хороший способ внедрить единый стандарт, который не потребует от пользователя самостоятельно устанавливать различные плагины.

Другого мнения придерживается Brendan Eich, создатель языка Javascript и технический директор Mozilla.

По его словам, решение поддержать EME подрывает открытость Web и ущемляет права пользователей. А еще он считает, что EME открывает дорогу для появления бесконечного числа нестандартизированных CDM-плагинов, которые по сути являются аналогами ActiveX и создаются под конкретные ОС.

Кстати, Widevine CDM не является частью проекта Chromium, а представляет из себя такой же закрытый плагин Google, как и Flash (PPAPI) и PDF Viewer. Т.е. встраивается исключительно в Chrome. В мобильную версию Google Chrome плагин встроить планируют в 32 версии.

Строго говоря, Google не позиционировало свою технологию Native Client как платформу для Rich Internet Applications, но по формальным признакам она вполне вписывается в этот класс ПО.

Ее суть — запуск в браузере модулей, написанных на нативном коде (увы, адекватного перевода на родной язык термина «native code» в голову не приходит) для архитектуры x86.

В отличие от JavaFX или Silverlight, в этой технологии нет компиляции в байт-код и какой-либо виртуальной машины. Была создана среда выполнения, позволяющая запускать обычные, «родные» для этой платформы программы в безопасном для данной системы окружении.

Отключаем плагины и ускоряем Google Chrome

Разработчики идеально выдержали модель «песочницы».

Во избежание взаимодействия Native Client непосредственно операционной системой весь код исполняется в отдельном, изолированном контейнере. Это позволяет модулю использовать системные ресурсы, но в то же время ограждает ОС от возможного случайного или злонамеренного повреждения.

В целом Native Client (NaCL) состоит из контейнера, играющего роль песочницы, и среды исполнения (runtime) нативного кода. Третьим элементом выступает плагин для веб-браузера. Для коммуникации между браузером и NaCL-модулем предоставлены два варианта: simple RPC-интерфейс (SRPC) и давно известный Netscape Plugin Application Programming Interface (NPAPI).

Писать модули для Google Native Client предполагается на любом компилируемом на данной системе языке программирования.

Native Client распространяется под лицензией BSD, имеет реализации для различных браузеров и платформ.

Еще несколько лет назад Native Client многими рассматривался как веб-платформа будущего. Сейчас новости об этой технологии занимают довольно скромное место на фоне известий о новых API HTML5, но Google от него отказываться явно не собирается. Так, начиная с 14-й версии браузера Google Chrome, Natve Client включен в состав обозревателя, и его пользователям больше не требуется устанавливать никаких дополнительных плагинов.

Вам также могут быть интересны следующие статьи:

Разработчики из проекта Chromium сообщают, что уже в 31 версии их браузера поддерживается Portable Native Client (PNaCl, произносится «pinnacle»). Что это за зверь такой, и в чем его отличия от простого NaCl вы можете прочитать дальше…

Для начала напомним, что такое обычный NaCl.

От браузера к ОС: что такое Native Client и чем он может быть полезен?

Это технология, которая позволяет браузеру исполнять нативный код, а разработчикам — писать свои веб-приложения, например, на C или C++. Применение NaCl позволяет добиться высокой производительности и низкоуровневого контроля за работой приложения. С применением NaCl созданы такие игры как Mini Ninjas и Bastion.

Можете, кстати, обратить внимание, что плагин NaCl встроен в браузер и отображается на странице chrome:plugins.

К сожалению, NaCl не дает возможность подготовить приложение, которое будет работать на любой платформе. В результате разработчики должны компилировать исполняемые nexe-модули под каждую архитектуру. Собрать по модулю на каждую платформу еще можно, но как их распространять? Особенно это актуально, если веб-приложения встроены в сайт, а не устанавливаются из того же Chrome Web Store.

PNaCl решает эту проблему и позволяет создавать действительно портативные и независимые от архитектур приложения. Как это происходит? Процесс компиляции разбивается на два этапа:

  • компиляция исходного кода в байткод, который не зависит от архитектуры;
  • перевод байткода в нативный код под каждую архитектуру.

В результате первого этапа разработчик получает специальный pexe-модуль, который можно использовать в приложениях также, как и любые другие HTML, JS и CSS вставки. Этот же компонент можно распространять через сайт.

А вот второй этап уже происходит в браузере. Chrome сам преобразовывает байткод в нативный код, который будет актуален для конкретной платформы и ОС.

В результате разработчик создает одно приложение, которое будет работать на x86, ARM и MIPS. А чтобы приложения, созданные на PNaCl, работали и в других браузерах, а не только в Chrome, можно использовать pepper.js.

Если вы разработчик, то добро пожаловать в документацию.

А если вы просто любопытный пользователь, то вот вам PNaCl-демки.

От браузера к ОС: что такое Native Client и чем он может быть полезен?

Отметив в начале августа 20-летний юбилей, браузеры почти сразу перешагнули и ещё одну важную ступеньку: на прошлой неделе в бета-версии Google Chrome 14 был включён экспериментальный компонент Native Client (NaCl). Мне повезло рассказывать об этом уникальном проекте с самых первых его дней (см. Компьютерра #763) – и тем приятней констатировать сейчас, что цель, которую ставили перед собой авторы, в общем достигнута.

Чего не хватает веб-браузерам, не считая утопической стопроцентной совместимости? Увы, скоростей. Даже с учётом всех мыслимых инноваций и модификаций последних лет – революционных Javascript-движков, использования GPU, предварительного рендеринга страниц, новых протоколов (слышали про SPDY?) и прочего подобного – скорость исполнения веб-приложений на порядки медленней той, что обеспечивает любая нативная программа, выполняемая непосредственно микропроцессором. Вот здесь-то и вступает в игру NaCl.

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

Читайте также:  Что делать если пропала панель управления Nvidia

Фокус объясняется просто: Native Client – это “песочница”, внутри которой работают программы, написанные на C/C++ и других классических языках, компилируемых непосредственно в машинный код. Но замкнутые в своём участке памяти, NaCl-приложения общаются с внешним миром только через программный интерфейс, связывающий их с Javascript-движком браузера. Поэтому не имеет значения, в какой операционной системе идёт работа, важно лишь для какого процессора они скомпилированы (сейчас NaCl-программы могут быть в инструкциях x86 и ARM).

Native Client часто сравнивают с ActiveX, ставшей настоящим кошмаром IT. Но тот, кто знаком с новым проектом не понаслышке, утверждают, что правильной аналогией будет не ActiveX или Java, а скорее VMware в браузере: для NaCl нет нужды писать новые приложения – можно адаптировать уже существующие!

Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.

Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.

Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.

Важность текущего момента в том, что эксперименты завершены и начата практическая стадия. Native Client незримо присутствует в Chrome уже на протяжении нескольких версий – в виде тестовой опции, активировать которую необходимо вручную. Начиная с версии 14, стабильный релиз которой ожидается в сентябре, NaCl-среда будет активирована по умолчанию, что сразу же расширит список её пользователей с узкого круга разработчиков до минимум нескольких миллионов рядовых сетян (Chrome сейчас третий по популярности браузер в мире).

Помимо прочего, Native Client стал ещё и бесспорно уникальной функцией браузера Chrome. В условиях жесточайшей конкуренции, когда наткнуться на оригинальную идею – счастье, этот факт трудно переоценить

Какими будут NaCl-программы? Теоретически, на их плечи лучше всего взвалить обязанности, для которых требуется обработка больших объёмов данных в кратчайшее время. Вот почему ожидается, что основными областями применения будут мультимедийные функции браузеров и игры (к примеру, Google реализовала так встроенный в Chrome PDF-вьюер).

Однако по факту самым востребованным свойством Native Client стала его независимость от операционных систем. NaCl-программа без модификаций и настройки работает в MS Windows, Mac OS X, Linux и Chrome OS. Правда, список приложений пока невелик (см. официальный сайт), но уже есть интересные сторонние разработки (например, NaClBox, позволяющий запускать DOS-игры в браузере).

Ближайшее будущее Native Client связывается с двумя тенденциями. Первую должны сформировать разработчики прикладного софта, которые с помощью NaCl могут сравнительно легко переносить имеющиеся наработки в Сеть и таким образом наделять их кроссплатформенностью. Подать пример собирается лично Google, где надеются со временем превратить сам браузер Chrome в приложение NaCl (а значит и уменьшить хлопоты по адаптации к разным ОС, и усилить защиту, поскольку браузер будет работать в закрытой “песочнице”).

Другую тенденцию сформируют пользователи, требуя поддержки NaCl-приложений в браузерах, конкурирующих с Chrome. Поскольку исходники открыты, ничто кроме идеологических соображений не должно помешать проникновению Native Client в Firefox, Safari, Opera и Internet Explorer. Ожидается, что это произойдёт с участием создателей браузеров или без них (при помощи плагинов).

Наконец, в отдалённой перспективе Native Client может сыграть важную роль в становлении облачной Chrome OS – где отныне возможен запуск приложений, едва ли хоть в чём-то уступающих программам для классических операционных систем. И здесь скрыт самый жирный плюс этой оригинальной разработки. Да, сторонники Native Client, безусловно, большие оптимисты. И верить им или нет, решать вам. Но в любом случае новинку стоит оценить лично. Ведь если ожидания оправдаются, резко и необратимо изменятся не только браузеры, но и весь мир вычислительной техники: браузеры станут полным эквивалентом операционных систем и фундаментом для обновлённой софтверной индустрии

Google Native Client

Содержание статьи

Наша жизнь все больше перемещается в Сеть. Браузер стал главной программой на ПК, а Гугл вовсю штампует ноутбуки с Chrome вместо полноценной ОС. Казалось бы, в этих условиях перспективы обычных, не веб-ориентированных языков программирования крайне сомнительны. И тем не менее нас, старых добрых хардкорных программистов на си приплюснутом, еще рано списывать на свалку истории — мы все еще получаем кучу денег :), потому что без нормального машинного кода до сих пор никто не обходится.

Потребность в запуске нативного кода в браузере появилась не на пустом месте. Как бы ни старались разработчики JavaScript и HTML 5 движков, производительность их творений не выдерживает конкуренции с обычным кодом на C или C++. Если нам нужно показать крутую графику или поразить окружающих высококачественным звуком, то типичными инструментами веб-разработчика подобное реализовать затруднительно. Именно это и стало одной из основных причин для появления технологии Native Client от Google.

Что такое Native Client

Ребята из Гугла начали свой нелегкий труд над NaCl в далеком 2008 году. Задачи, которые они ставили перед собой, были сложны и амбициозны. Первым делом надо было обеспечить легкую переносимость legacy кода в NaCl. Это была фактически первопричина всей этой затеи. Если у нас есть куча старого и не очень кода на плюсах, который работал сугубо на десктопах, и мы вдруг решили, что пора осваивать веб, то нам не надо учить новые языки программирования и технологии, а достаточно лишь портировать имеющийся код на Native Client платформу.

Но даже если мы и готовы переписать все с нуля на незнакомых нам языках, не факт, что у нас выйдет то, что мы ожидали. Показывать качественную 2D- и 3D-графику, использовать многопоточность, да и вообще быть ближе к железу у нас ну никак не выйдет. Это была вторая цель, которую преследовала Google. Кроме того, как я уже сказал, никто не отменял относительно низкую производительность скриптовых языков в браузере.

Ко всему прочему, умные парни из Google подумали и о безопасности пользователей. Весь нативный код выполняется в двойной (!) песочнице, что позволяет блондинкам и прочим продвинутым личностям не бояться забагованных приложений и атак злых вирусов.

Ну и на десерт у нас платформонезависимость. Да-да! Мы можем написать плюсовый код, и он будет работать на Windows, OS X и даже, не побоюсь этого слова, Linux. А вишенкой на этом десерте будет поддержка x86- и ARM-архитектур.

В 2011-м Гуглец включил поддержку NaCl в Chrome. Другие браузеры, к сожалению, пока не поддержали инициативу интернет-гиганта. Старожилам интернета в голову невольно могут прийти воспоминания об ActiveX, который и ныне здравствует (в кругу любителей IE), но, в отличие от технологии Майкрософт, Native Client распространяется с открытым исходным кодом под новой лицензией BSD. Да и над безопасностью в NaCl подумали лучше.

Для чего можно использовать Native Client

На практике Native Client можно использовать в первую очередь для запуска игрушек в браузере. Собственно, первый опыт уже есть — под Google NaCl портировали Quake. Да, да, ту самую кваку 1996 года выпуска, в которой ты провел столько лет, разрубая жирных огров саперной лопаткой (если ты не знаешь, как зарубить лопатой вооруженного гранатометом и бензопилой огра, напиши мне) и разрывая в клочья зомби из рокетлаунчера.

Исполнение машинного кода в браузере отлично поможет разгрузить сервер. Например, если у нас есть онлайн-сервис для конвертации видео в разные форматы, то алгоритм работы с ним должен выглядеть примерно так: пользователь загружает видео на сервер, долго ждет, пока наш мощный CPU перелопатит файл, выбрасывая в атмосферу много калорий тепла, а потом счастливый юзер скачивает результат с нашего сервера. Но если мы перенесем конвертор с сервера на клиент, то мы сразу уберем нагрузку с нашего железа и нехило расчистим интернет-канал, который за «умеренную» плату предоставил нам хостер. Да и пользователь будет доволен — в среднем конвертация должна пройти быстрее, так как сотни мегабайт туда-обратно по сети не гоняются. А для юзеров с паранойей можно с гордостью заявить, что их драгоценные personal data целиком обрабатываются только на их ПК. Это, кстати, актуально и для корпоративного сектора.

Как это работает

Native Client — это общее название для набора разнообразных программных компонентов, которые работают вместе для обеспечения безопасного функционирования C++ кода в вебе. На высоком уровне NaCl состоит из тулчейна (компилятора, линкера и так далее) и рантайм-библиотек, которые встроены в браузер и позволяют нативному коду безопасно работать с нужными API.

Для переносимости приложений между разными архитектурами существует расширение Portable Native Client (PNaCl). Отличие его заключается в том, что при компиляции код транслируется в промежуточное представление, а уже после запуска на той или иной платформе браузер переводит это представление в машинный код.

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

Читайте также:  Что значит сброс DRM на андроиде

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

Кроме того, NaCl-модули всегда запускаются в процессах с ограниченными правами. Эти меры предосторожности позволяют говорить о двойной песочнице для нативного кода, работающего в браузере.

C++ код может общаться с JavaScript посредством специальных сообщений. Сообщения пересылаются асинхронно, то есть не надо ждать, пока другая сторона получит его.

Пишем Hello NaCl

Теперь у нас есть представление о Native Client, и нужно пробовать написать что-нибудь полезное. или не очень. Мы будем делать Hello World, ну или Hello NaCl.

Для начала нужно скачать и установить Native Client SDK. Ссылку на страницу загрузки ты найдешь во врезке. Там же будет и инструкция по установке. Скажу лишь, что обязательно будет нужен Python 2.7 и make.

Вместе с SDK идет простой веб-сервер, который может хостить приложения на localhost. Самый простой путь запустить его — это выполнить следующие команды:
$ cd pepper_$(VERSION)/getting_started
$ make serve
SDK может содержать в себе несколько разных версий, правильную нужно подставить вместо $(VERSION). Также можно использовать любой другой веб-сервер. PNaCl включен по умолчанию в версии хрома 31 и старше. Но нужно следить, чтобы выбранная версия SDK поддерживалась установленной версией Chrome.

Великий и могучий Гугл любит преданных разработчиков и потому любезно предоставил пример с минимальным кодом для создания NaCl-модуля. Лежит этот код в папке pepper_$(VERSION)/getting_started/part1 и состоит из нескольких файлов. Первый — это index.html. В нем находится HTMLLayout и JS-код для взаимодействия с плюсовым модулем. Если внимательно присмотреться, то можно заметить файл с расширением nmf, а точнее, hello_tutorial.nmf. Это манифест, который указывает на нашу HTML, NaCl-модуль и служит вместилищем дополнительных настроек для тонкого тюнинга.

Далее идет hello_tutorial.cc, он и является исходником на C++, который потом можно собрать с помощью Makefile. Сделать это до безобразия просто:
$ cd pepper_$(VERSION)/getting_started/part1
$ make
Если мы использовали веб-сервер, идущий вместе с SDK, то после сборки в хроме достаточно вбить такой URL: http://localhost:5103/part1, и ты станешь свидетелем чуда — текст на открывшейся странице изменится с LOADING. на SUCCESS. Впечатляет, не правда ли?

Так как мы собирались делать Hello NaCl, то нам придется немного изменить код. Для этого заглянем в файл index.html и найдем там JavaScript-функцию moduleDidLoad. Кстати, сейчас самое время пробежаться по всему коду HTML-файла и остановиться на непонятных вещах, благо все они щедро сдобрены комментариями. В функции moduleDidLoad происходит загрузка нашего NaCl-модуля hello_tutorial и вывод того самого текста SUCCESS, который мы успели лицезреть при переходе по линку /part1. Теперь пошлем нативному модулю слово hello, для этого достаточно вызвать функцию postMessage у переменной модуля. В коде это будет выглядеть примерно так:
function moduleDidLoad() <
HelloTutorialModule = document.getElementById(‘hello_tutorial’);
updateStatus(‘SUCCESS’);
// Посылаем сообщение Native Client модулю
HelloTutorialModule.postMessage(‘hello’);
>
Сообщение послали, теперь надо его получить. Для этого надо реализовать член-функцию HandleMessage в файле hello_tutorial.cc. В файле содержится TODO, которое недвусмысленно намекает на то, что нужно делать. В обработчике сообщения мы будем отправлять браузеру ответ с помощью функции PostMessage, но перед этим выполним пару проверок.
virtual void HandleMessage(const pp::Var& var_message) <
if (!var_message.is_string())
return;
std::string message = var_message.AsString();
pp::Var var_reply;
if (message == “hello”) <
var_reply = pp::Var(“hello from NaCl”);
PostMessage(var_reply);
>
>
Как видно из кода, мы первым делом проверяем, пришла ли нам строка, а не что-то другое. Класс Var служит оберткой со счетчиком ссылок для сырых переменных C++. Именно объекты этого класса пересылаются между веб-страницей и нативным модулем. Далее мы проверяем, что нам пришло именно hello, и отправляем ответ, предварительно обернув его объектом класса Var.

В index.html уже есть обработчик сообщений от NaCl-модуля. Он просто выведет JS alert с полученной строкой:
function handleMessage(message_event) <
alert(message_event.data);
>
После того как мы сделали нужные изменения, можно пересобирать модуль и обновлять страницу http://localhost:5103/part1. Увидев message box с заветной строкой hello from NaCl, мы можем с гордостью заявить, что освоили новую технологию.

Заключение

Гугл придумал полезную штуку. Жаль, что пока никто, кроме «корпорации добра», не поддержал Native Client платформу. Достаточно высокая производительность является преимуществом по сравнению с Java, апплеты которой также могут выполняться в браузере, а высокий уровень безопасности уделывает ActiveX от Microsoft. Будем ждать, пока Chrome захватит мир или другие разработчики браузеров внедрят в свои творения Native Client.

Как ускорить браузер Google Chrome и отключить плагины

Статья отредактирована 19.022018 г.

Приветствую Вас, дорогие читатели! Сегодня речь пойдет о том, как ускорить браузер Google Chrome. Первый способ- это отключить не нужные плагины браузера google chrome. Но для этого сначала определимся , какие плагины установлены в вашем браузере и отключим те, которые вам не нужны.

Не беспокойтесь, вы всегда сможете их включить, если что обратно.

Данная статья написана про плагины браузера Google Chrome. Возможно, что вы пользуетесь другими браузерами. Плагины есть во всех браузерах. Возможно, что есть и те, которые вам не нужны. В следующей своей статье мы поговорим об этом.

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

Давайте разберемся в самом термине. Плагин- это английское слово(plugin), от plug in то есть подключать какую то дополнительную функцию или приложение. Это отдельный программный модуль(часть программы), он позволит отобразить содержание страницы в интернете, которое не может отобразить браузер. К таким относятся: видео файлы, аудио записи, всякого рода онлайн игры, презентации и многое другое.

Плагины создаются и распространяются разработчиками для удобства работы в интернете. Приведу такой пример, сейчас большой популярностью пользуются плагины: Adobe Flash, Quicktime, Silverlight и их еще много всяких.

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

Чтобы попасть и найти плагины браузера, нам нужно в адресной строке браузера набрать такой адрес: chrome://plugins/ и нажать клавишу enter.

И вот перед нами страничка с плагинами. Предупреждаю, что у каждого они могут быть в большем или меньшем количестве. Это все зависит от того, какие вы расширения и приложения устанавливали и что используете на данный момент. Для каждого пользователя это индивидуально. Тем не менее, прочитав мои рекомендации, каждый найдет для себя, что то полезное. Самое главное, знать, какие плагины у вас работают и нужны ли они вам? А может быть они у вас просто для «мебели»?

Так вот, от ненужной «мебели» нужно избавляться. Я знаю, что вы поняли, о чем я сейчас пишу.

А теперь разберемся, что будем отключать.

Эта ссылка https://support.google.com/chrome/answer/142064?hl=ru&rd=1 здесь все о плагинах браузера Google Chrome, какие бывают и все о них.

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

  • Widevine Content Decryption Module – этот плагин позволяет правообладателю запрещать копирование аудио/видео контента через HTML5. О нем почитайте здесь. Я этот плагин отключила, так как не хочу себя ограничивать.
  • Native Client – это плагин поддержки графики, звука высокого качества в приложениях. Об этом тут более подробно я дала ссылку выше. Если не нужен смело отключайте. Я оставила.
  • Adobe Flash Player – этот плагин поддержки Flash. Мне он очень нужен и я его периодически обновляю. Значит оставлю.

У меня как показано в скриншоте плагинов не много. Ниже я еще напишу пару строк о некоторых, которые могут у вас быть.

  • Google Earth (GEPlugin) – плагин интеграции с приложением Google Earth, с помощью его просматривают карты в 3D. Мне он пока не нужен.
  • Chrome Remote Desktop Viewer – это плагин для приложения которое помогает подключаться к удаленным компьютерам и предоставлять им безопасный доступ к вашему компьютеру. Решайте сами. Мне пока не нужен.
  • Java ™ – плагин поддержки Java, прошу не путать с JavaScript. Я таким не пользуюсь и уже давно отключила.
  • Chrome PDF Viewer – плагин, который обеспечивает просмотр PDF документов в браузере. Был отключила. Мне хватает у меня на компьютере программы Acrobat Reader для просмотра таких файлов.
  • Google Update – плагин для обновления ПО Google. Скажу одно это очень назойливая штука. Если она у вас есть, не трогайте. У меня ее нет. Это просто для информации.
  • Adobe Reader – плагин для просмотра PDF файлов в браузере. Я выше написала, это что то подобное. Мне не понравилось, что постоянно вылазят окна и предлагают обновления. Давно избавилась и вам советую.
  • VLC Web Plugin – этот плагин обычно используют для проигрывателя VLC. Обычно при его помощи прослушивают и просматривают аудио и видео файлов в браузере. Мне лично он без надобности, поэтому даже не устанавливала.
  • Windows Presentation Foundation – этот плагин подсистемы из .NET Framework (начиная с версии 3.0). Если хотите подробней забете название в поиск. Это плагин для Firefox . Кому нужен, оставляйте.

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

А у меня сегодня все. Спасибо, что читаете мой блог.

Native Client – Rich Internet Applications от Google

Архив номеров / 2009 / Выпуск №2 (75) / Native Client – Rich Internet Applications от Google

Читайте также:  Как пользоваться YouTube

Кирилл Сухов

Native Client – Rich Internet Applications от Google

Rich Internet Applications – что это такое и где применяется? Мы этим уже пользуемся или это только туманное будущее? Попытаемся разобраться в данных вопросах, рассмотрев концепцию RIA на различных примерах. Сегодня мы установим и опробуем Google Native Client.

Что такое Rich Internet Applications? Если честно, так и хочется ляпнуть что-то вроде «очередной маркетинговый термин», но в данном случае я погрешу против истины. RIA – это приложения, работающие через сеть и предоставляющие клиенту ресурсы веб-сервера, но обладающие функциональностью полноценных настольных приложений. Это определение не страдает академичностью. Я его только что выдумал, но (по моему мнению) оно не хуже любого другого. По сути Rich Internet Applications (RIA) – это следующая ступень эволюции: от страничек, сайтов, через веб-приложения к чему-то далёкому и полнофункциональному.

Как правило, RIA-приложения кроссплатформенны, запускаются в браузере и не требуют какой-либо дополнительной установки программного обеспечения на стороне клиента. В качестве примера веб-приложений, близких по идеологии к RIA, можно привести Google Maps, GMail или ролики YouTube.

Впервые этот термин прозвучал из уст маркетологов компании Macromedia теперь уже в далёком 2001 году. С тех пор появилось немало технологий и реализаций данной концепции. Наиболее известные из них: Adope Air, Alchemy, Flex, JavaFX, Microsoft Silverlight, XULRunner от Mozilla Foundation и только что появившийся Google Native Client.

При всём разнообразии подходов технологии RIA имеют некоторые общие черты, и самая главная из них – концепция песочницы (sandbox). Как правило, любое RIA выполняется в локальной, изолированной среде, и хотя использует ресурсы компьютера-клиента, не может фатально влиять на его систему.

Обычно RIA-приложения взаимодействуют с сервером асинхронно, не прерывая работу пользователя для получения ответа. Они имеют богатый пользовательский интерфейс и не предъявляют каких-либо особых требований к компьютерам-клиентам.

Google Native Client – Quake в браузере и другие

Понятно, что такой гигант, как Google, не мог стоять в стороне от тенденции, которую сам же и создал. Первый шаг в этом направлении, замечательный инструментарий Google Gears, был выпущен ещё в конце весны 2008 года, а в декабре 2008 года компания представила свою RIA-технологию – Google Native Client. Её суть – запуск в браузере модулей, написанных на нативном коде (увы, адекватного перевода термина «native code» в голову не приходит) для архитектуры x86.

В отличие от JavaFX или Silverlight в этой технологии нет компиляции в байт-код и какой-либо виртуальной машины. Была создана среда выполнения, позволяющая запускать обычные, «родные» для этой платформы программы в безопасном для данной системы окружении. Разработчики идеально выдержали модель «песочницы».

Во избежание взаимодействия Native Client непосредственно с операционной системой весь код исполняется в отдельном, изолированном контейнере. Это позволяет модулю использовать системные ресурсы, но в то же время ограждает ОС от возможного случайного или злонамеренного повреждения [2].

В целом Native Client (NaCL) состоит из контейнера, играющего роль песочницы, и среды исполнения (runtime) нативного кода. Третьим элементом выступает плагин для веб-браузера. Для коммуникации между браузером и NaCL-модулем предоставляет два варианта: simple RPC-интерфейс (SRPC) и давно известный Netscape Plugin Application Programming Interface (NPAPI).

Писать модули для Google Native Client предполагается на любом компилирующемся на данной системе языке программирования.

В настоящий момент Google Native Client рассматривается как экспериментальная технология, но разве это мешает нам попробовать её в деле прямо сейчас?

Сразу хочу заметить, что хотя технология и позиционируется как кроссплатформенная (представлены сборки SDK для Linux, Windows и Mac, а также исходный код приложения), чтобы в полной мере её опробовать, пользователям ОС Windows придется выполнить несколько больше телодвижений, а именно установить интерпретатор Python и возможно cygwin. Причём Pyhton (это уже касается пользователей любой операционной системы) должен быть версии 2.4.x-2.5.x (на момент написания этой статьи работа с Python 2.6 давала ошибки).

Полученный архив распаковываем в любое удобное место и рассматриваем полученный результат. На рис. 1 показана структура Native Client SDK.

Рисунок 1. Структура Google Native Client

Директории common/ и tests/ содержат исходные коды примеров и тестов, директории scons-out/, site_scons/ и ite_scons_general/ содержат файлы, имеющие отношение к сборке Native Client-приложений. В поддиректории scons-out/*/staging находятся скомпилированные примеры для тестирования Native Client-плагина браузера.

Файлы Sconstruct, scons.bat и scons предназначены для сборки самой программы Native Client, а также примеров и тестов в различных операционных системах.

В директориях include/, intermodule_comm/, ncv/, nonnacl_util/, npapi_plugin/ и service_runtime/ содержится исходный код ядра Native Client, в частности npapi_plugin/ содержит исходники плагина для браузера.

В tools/ находятся исходные коды Native Client SDK.

В gtest/ – Open Source-фрэймворк для юнит-тестирования от Google.

В директориях third-party/ и native_client/third-party/ содержатся, как это понятно из названия, инструменты не гугловского происхождения, в частности gcc и imagemagick и собранная версия Native Client SDK. В директории documentation/ – документация (какая неожиданность!).

Теперь, сориентировавшись, можно опробовать работоспособность Native Client. Для этого отправимся в директорию googleclient/native_client/tests/, выбираем там, к примеру, папку /life, набираем в консоли команду:

И наслаждаемся результатом (см. рис. 2).

Рисунок 2. Native Client приложение «life»

В общем, всё работает, но не затем мы всё это разворачивали, чтобы увидеть ту же «жизнь» в браузере. Попытка открыть файл life.html приведёт к выдаче сообщения о незагруженном плагине. Что и разумно – мы пока ничего не ставили. Немедленно исправим эту ситуацию, тем более что в директории tests/ среди других призывно маячит папка quake/.

Устанавливаем Native Client-плагин

Сначала закроем все экземпляры браузера, который мы хотим пропачтить (в данном случае это рекомендуемый руководством Firefox 3).

Затем отправляемся в директорию googleclient/native_client/ и запускаем команду:

./scons –prebuilt firefox_install

Скрипт установки, проверив систему, разок спросит нас, продолжать ли, установит плагин и закончит свою работу сообщением вроде:

* You have successfully installed the NaCl Firefox plugin.

* As a self-test, please confirm you can run

* from a shell/command prompt. With no args you should see

* No nacl file specified

* on Linux or Mac and no output on Windows.

* To test this installation also try the test links on the page

scons: done building targets.

Согласно документации установка плагина на платформе Windows происходит идентично, команда установки выглядит как:

.scons –prebuilt firefox_install

но, несмотря на все усилия, мне так и не удалось добиться нормального выполнения этой команды. Но можно пойти другим путём – необходимо скопировать из папки naclgoogleclientnative_clientscons-outopt-winstaging в папку C:Program FilesMozilla Firefoxplugins следующие 3 файла: inpGoogleNaClPlugin.dll, SDL.dll, sel_ldr.exe и перезапустить браузер.

Теперь проверим установленный плагин. Зайдём в директорию googleclient/native_client/scons-out/nacl/staging и раскроем браузером файл index.html. Мы получим доступ к различным тестам, представляющими собой html-странички с внедрёнными скомпилированными приложениями Google Native Client (см. рис. 3).

Рисунок 3. Тестируем плагин

Если посмотреть исходный код такого html-файла, мы увидим примерно следующую конструкцию:

SomeDemo

Земля в иллюминаторе

Возвращаемся в директорию /googleclient/native_client/tests в папку earth/ (см. рис. 4).

Рисунок 4. Файлы примера

Как нетрудно догадаться, сценарий run.py запускает приложение, но нам это совсем не нужно. Вместо этого откроем в браузере html-страницу earth.html. и. получим то самое сообщение (см. рис. 5). Как же так? Ведь плагин мы установили?

Рисунок 5. Модуль не загружен

Дело в том, что, несмотря на наличие Native Сlient-плагина, модуль не грузится по той простой причине, что он не собран, не откомпилирован, а представлен только исходным кодом (файл earth.сс), на языке С++. Впрочем, в той же папке мы видим файл Makefile, и это позволяет надеяться, что ситуацию можно исправить. Сначала соберём и запустим Standalone-приложение:

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

Теперь соберём Native client- модуль :

make release nacl

Если все прошло нормально, появятся ещё два файла – earth.nexe и earth_release.nexe. Можно опять открыть earth.html в браузере, и теперь картинка должна быть совсем другой (см. рис. 6).

Рисунок 6 . Земля.

Рассмотрим пример посложнее. В папке googleclient/native_client/tests/xaos находятся исходники и сценарий сборки известного фрактального конструктора Xaos. Правда, не исходники самого Xaos, их сборочный скрипт скачает отдельно. Собирать просто:

И, раскрыв браузером xaos.html, наслаждаемся результатом (см. рис. 7).

Рисунок 7. Редактируем фракталы

На самом деле в этом и предыдущем примере мы выступаем в роли разработчика. Конечному пользователю приложения достаются уже откомпилированные модули, и всё, что ему нужно, – оснастить браузер Native client плагином.

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

Заходим в папку googleclient/native_client/tests/quake/ и скачиваем исходные коды игры:

Теперь их разархивируем :

tar -x –strip-components=1 -f sdlquake-1.0.9.tar.gz

tar -x -f quakesw-1.0.6.tar.gz

Должно образоваться множество файлов – исходников и одна директория – id1/.

Следующим шагом наложим необходимый патч из native Client:

Всё, теперь можно приступать к сборке:

make clean nacl

make debug nacl

make release nacl

Осталось открыть в браузере файл quake.html, и можно гонять монстров (см. рис. 8).

Рисунок 8. Наши победят!

Да, на этом, к сожалению, пока всё. К сожалению, технология пока действительно сырая, и автору не удалось последовательно написать с нуля и запустить Google Native Client-приложение ни на одной платформе. Более того, на данный момент времени NaCL отказывается собираться с Python 2.6.x, браузер с установленным NaCL-плагином неоднократно замечен в неадекватном поведении, некоторые тесты не запускаются под платформой Windows.

С другой стороны, API NaCL открыт и документирован (/googleclient/native_client/scons-out/doc/html), поэтому для настоящего энтузиаста нет препятствий попробовать свои силы в написании приложений «невзирая на». Трудно сейчас сказать, насколько перспективным окажется это занятие, но интересным – наверняка.

Ссылка на основную публикацию
Adblock
detector
Рубрика: Острый угол / Острый угол