native browser что это
От браузера к ОС: что такое Native Client и чем он может быть полезен?
Отметив в начале августа 20-летний юбилей, браузеры почти сразу перешагнули и ещё одну важную ступеньку: на прошлой неделе в бета-версии Google Chrome 14 был включён экспериментальный компонент Native Client (NaCl). Мне повезло рассказывать об этом уникальном проекте с самых первых его дней (см. Компьютерра #763) — и тем приятней констатировать сейчас, что цель, которую ставили перед собой авторы, в общем достигнута.
Чего не хватает веб-браузерам, не считая утопической стопроцентной совместимости? Увы, скоростей. Даже с учётом всех мыслимых инноваций и модификаций последних лет — революционных Javascript-движков, использования GPU, предварительного рендеринга страниц, новых протоколов (слышали про SPDY?) и прочего подобного — скорость исполнения веб-приложений на порядки медленней той, что обеспечивает любая нативная программа, выполняемая непосредственно микропроцессором. Вот здесь-то и вступает в игру NaCl.
Проект, ведомый уже три года по инициативе и под крылом Google, позволяет веб-программистам писать такие приложения, которые будут исполняться внутри браузера со скоростью, лишь слегка уступающей скорости программ в машинных кодах, но сохранят переносимость, присущую веб-приложениям.
Фокус объясняется просто: Native Client — это «песочница», внутри которой работают программы, написанные на C/C++ и других классических языках, компилируемых непосредственно в машинный код. Но замкнутые в своём участке памяти, NaCl-приложения общаются с внешним миром только через программный интерфейс, связывающий их с Javascript-движком браузера. Поэтому не имеет значения, в какой операционной системе идёт работа, важно лишь для какого процессора они скомпилированы (сейчас NaCl-программы могут быть в инструкциях x86 и ARM).
Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.
Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.
Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.
Важность текущего момента в том, что эксперименты завершены и начата практическая стадия. Native Client незримо присутствует в Chrome уже на протяжении нескольких версий — в виде тестовой опции, активировать которую необходимо вручную. Начиная с версии 14, стабильный релиз которой ожидается в сентябре, NaCl-среда будет активирована по умолчанию, что сразу же расширит список её пользователей с узкого круга разработчиков до минимум нескольких миллионов рядовых сетян (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, безусловно, большие оптимисты. И верить им или нет, решать вам. Но в любом случае новинку стоит оценить лично. Ведь если ожидания оправдаются, резко и необратимо изменятся не только браузеры, но и весь мир вычислительной техники: браузеры станут полным эквивалентом операционных систем и фундаментом для обновлённой софтверной индустрии.
Android Native Browser, дублирующий холст HTML5 (тонкий хром)
Это странная проблема, которую я испытываю только в родном браузере на Samsung Galaxy Tab 2 и Galaxy S2 в собственном браузере.
Это также было протестировано на других телефонах и планшетах Android, таких как Nexus 7 & Galaxy S4, но их родной браузер – хром, поэтому он выглядит отлично. Эта проблема также отсутствует в любых браузерах IOS, браузерах Windows Desktop или браузерах Mac Desktop.
Это почти так, потому что веб-страница загружается дважды поверх самой себя!
Поскольку существует дублированный элемент холста, который обновляется, как это делает основной холст.
Здесь он появляется, хотя это происходит только при повороте в ландшафтном режиме, но я верю, что в портретном режиме холст «отлично выравнивается сверху».
Что еще более странно, кнопка меню, которую вы видите, является кнопкой переключения, нажмите, чтобы открыть меню, нажмите, чтобы закрыть меню. На этом устройстве, когда вы нажимаете его, он открывается и закрывается мгновенно. То же самое происходит при переключении кнопки отключения звука.
Я полностью в недоумении.
Я сделал некоторые отладки javascript, бросая несколько предупреждений здесь и там, а функции инициализации, которые создают ссылки на холст и т. Д., Вызываются только один раз.
Я читал и слышал об аппаратном ускорении, вызывающем проблемы, но решения, которые я потенциально нашел, относятся только к созданию собственных приложений! А не веб-страницы холста HTML5.
Любое понимание этого может быть здорово! Заранее спасибо.
Я также добавил это тестовое alert(document.getElementsByTagName(‘canvas’).length); Чтобы увидеть, было ли 2 холста в DOM, но он возвращает 1!
Я столкнулся с этой проблемой. Я смог исправить это, выполнив следующий код после внесения изменений в мой холст:
Изменяя непрозрачность, это заставило холст перерисовать и удалить дубликаты. Это глупое исправление, но оно работает. Надеюсь, это помогает кому-то.
Для проблемы с двойным холстом существует ошибка, зарегистрированная в https://code.google.com/p/android/issues/detail?id=35474, которую вы можете проверить предлагаемые решения.
В моем случае эта проблема появилась только в том случае, если я включил рендеринг Force GPU.
Проблема обычно возникает, если у вас есть родительский элемент для холста с overflow: hidden CSS overflow: hidden
Удалить свойство переполнения со всех родительских холстов, возможно, нам не нужно это свойство на сенсорных устройствах:
От браузера к ОС: что такое Native Client и чем он может быть полезен?
Проект, ведомый уже три года по инициативе и под крылом Google, позволяет веб-программистам писать такие приложения, которые будут исполняться внутри браузера со скоростью, лишь слегка уступающей скорости программ в машинных кодах, но сохранят переносимость, присущую веб-приложениям.
Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.
Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.
Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.
Какими будут 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. Ожидается, что это произойдёт с участием создателей браузеров или без них (при помощи плагинов).
Мобильная разработка: Cross-platform или Native
Всем привет! Я Игорь Веденеев, руководитель мобильной разработки в AGIMA. Поговорим немного о нативной и кроссплатформенной разработке. Раньше я по большей части скептически относился ко второй: не устраивало качество конечных приложений в первую очередь. Однако за последний год темпы развития кроссплатформенных фреймворков уже не в первый раз заставляют пересмотреть свое мнение насчет такого подхода. Поэтому давайте еще раз сравним самые популярные кроссплатформенные решения и нативную разработку.
На всякий случай
Если вы не знаете, что такое нативная и кроссплатформенная разработка:
нативная разработка (2 независимых приложения на языках Swift и Kotlin);
кроссплатформенная разработка — общая кодовая база для iOS и Android (с применением фреймворков Flutter или React Native (далее RN)).
У каждого способа есть свои особенности, плюсы и минусы. Соответственно, под каждый конкретный проект и каждую конкретную цель подходит какой-то один из них. Сейчас объясню, как выбрать и на что обращать внимание.
Нативная разработка
Нативная разработка — это классический способ создания приложения для iOS и Android. Ведется она с использованием инструментов и языков программирования, предложенных вендорами — Apple и Google. Языки в данном случае — Swift (iOS) и Kotlin (Android), а инструментов для профилирования и отладки в нативной разработке очень много.
Однако мы должны понимать, что в данном случае мы делаем два независимых приложения. Разрабатываются они параллельно. Каждое приложение может реализовать фичу по-своему, и у каждого могут быть свои баги. И самое главное, нативная разработка никуда не денется: пока существуют iOS и Android, Apple и Google будут предоставлять инструментарий для создания приложений.
Нативная разработка позволяет создать самое качественное и функциональное приложение, но взамен придется разрабатывать и отлаживать всё 2 раза и следить, чтобы приложения соответствовали друг другу функционально.
Среди разработчиков это пока самый популярный способ создания приложений. Поэтому собрать команду, даже большую, в этом случае проще, чем для кроссплатформы. В первую очередь из-за количества предложений на рынке.
Плюсы и минусы нативной разработки
2 независимых приложения
Стоимость разработки и отладки
Меньше потребляемых ресурсов*
Богатый инструментарий для разработки
Широкий рынок разработчиков
Кроссплатформенная разработка
Кроссплатформенная разработка подразумевает, что мы используем один и тот же код и на iOS, и на Android. Вообще говоря, это всё такое же нативное приложение, но, запустив его, мы сразу проваливаемся в мир Flutter или RN, и всё происходит уже там. Стоит отметить, что разработка на Flutter/RN идет быстрее. Причем не только за счет того, что мы делаем 1 приложение вместо 2-х, а еще и за счет концепций создания приложений, в частности UI.
Но, увы, не всё так хорошо: кроссплатформа имеет ряд проблем, на которые стоит обратить внимание, прежде чем выбирать этот подход для своего приложения. React Native и Flutter всё же сторонние Open Source-решения. В них могут встречаться баги. Новые фишки iOS и Android там будут появляться не так быстро, как при нативных решениях. Может прекратиться поддержка, в конце концов.
Также, довольно часто придется полагаться на сторонние Open Source-библиотеки, что тоже несет в себе риски потенциальных проблем: например, совместимость версии Flutter/RN. Не исключен вариант, что нужной библиотеки не существует в природе, и тогда придется реализовывать всё с нуля самому. Также нельзя добавить расширения для iOS-приложений или, например, приложение на часы. Это касается и Flutter, и RN.
То есть для реализации определенных фич придется добавлять нативный код, что приведет к смешению технологий. Как минимум надо будет иметь в них компетенции. Как максимум — организовывать передачу данных из нативного кода в кроссплатформенный и наоборот.
Если в приложении много логики и есть необходимость сделать ее многопоточной, это тоже будет проблемой и во Flutter, и в RN. Это возможно, но, скажем, это не то, для чего были предназначены эти фреймворки. Также каждый из фреймворков имеет достаточно тяжелую исполнительную среду, что делает кроссплатформенные приложения более ресурсоемкими и требовательными к процессору/оперативке телефона.
Если приложение подразумевает обширное использование аппаратных возможностей телефона, взаимодействия с ОС, то я бы тоже не рекомендовал использовать кроссплатформу — есть риск, что в какой-то момент или код станет очень запутанным, или мы упремся в ограничения одной из платформ или самого фреймворка. Еще стоит учесть, что нам стоит использовать платформенно нейтральный UI, чтобы не создавать потенциальных проблем с различным поведением на платформах и в принципе не снижать на этом скорость разработки.
На картинке ниже представлены результаты теста с простым списком с изображениями: видим, что нативное приложение выигрывает вчистую. Да, на более новых моделях телефонов разница будет не такой значительной, но тенденцию можно видеть. Результаты остальных тестов тут.
Если проще, то кроссплатформа позволяет разработать приложение в кратчайшие сроки. Лучше всего подходит для приложений-витрин услуг или товаров среднего/малого объема без обширного использования платформенных возможностей. То есть снять фотку на аватар или отсканировать QR-код не составит больших проблем, но, если вы делаете приложение вокруг камеры, лучше рассмотреть нативную разработку.
Плюсы и минусы кроссплатформенной разработки
What is the engine of Android native browser?
What is the engine of Android native browser? Wiki says that Android used WebKit before 4.4 and Blink for 4.4 and further versions. Is it right statement? Thanks in advance.
2 Answers 2
The default browser on Android is Google Chrome. This uses the Blink layout engine. For AOSP installations without the Google Apps, the default browser is the old «Browser» app that uses Webkit.
other third party browsers like Firefox uses Gecko, Opera uses Blink, Dolphin uses Webkit, and there are probably others. Additionally, also Samsung and HTC install different (non-Chrome) browsers on their phones. I do not know what they are, or what engine they use.
similar question answered you can see here
I had a similar question. Below is what I found.
1. Wikipedia article
The web browser available in Android is based on the open-source Blink (previously WebKit) layout engine, coupled with Chromium’s V8 JavaScript engine. Then the WebKit-using Android Browser scored 100/100 on the Acid3 test on Android 4.0 ICS; the Blink-based browser currently has better standards support. The old web browser is variably known as ‘Android Browser’, ‘AOSP browser’, ‘stock browser’, ‘native browser’, and ‘default browser’ (from the time it was always the default). Starting with Android 4.4 KitKat, Google has begun licensing Google Chrome (a proprietary software) separately from Android, but usually bundled with (what most device vendors did). Since Android 5.0 Lollipop, the WebView browser that apps can use to display web content without leaving the app has been separated from the rest of the Android firmware in order to facilitate separate security updates by Google.
2. HTML5test’s slides
ANDROID 4 DEVICES ALSO COMMONLY SHIP WITH GOOGLE CHROME
DEPENDING ON YOUR DEVICE GOOGLE CHROME COULD BE
ANDROID 4.4 SHIPS WITH A NEW WEBVIEW BASED ON CHROMIUM 30
BUT NOT THE SAME AS GOOGLE CHROME
THE CHROMIUM BASED WEBVIEW WILL BE UPDATED REGULARLY
IN FACT ON ANDROID 5
THE WEBVIEW CAN BE UPDATED INDEPENTENTLY OF THE OS
3. Release Notes on WebView
Android 4.4 KitKat
Android 4.4 includes a completely new implementation of WebView that’s based on Chromium. The new Chromium WebView gives you the latest in standards support, performance, and compatibility to build and display your web-based content.
Chromium WebView provides broad support for HTML5, CSS3, and JavaScript. It supports most of the HTML5 features available in Chrome for Android 30. It also brings an updated version of the JavaScript Engine (V8) that delivers dramatically improved JavaScript performance.
In addition, the new Chromium WebView supports remote debugging using Chrome DevTools. For example, you can use Chrome DevTools on your development machine to inspect, debug, and analyze your WebView content live on a mobile device.
The new Chromium WebView is included on all compatible devices running Android 4.4 and higher. You can take advantage of the new WebView right away, and with minimum modifications to existing apps and content. In most cases, your content will migrate to the new implementation seamlessly.
Android 5.0 Lollipop
The initial release for Android 5.0 includes a version of Chromium for WebView based on the Chromium M37 release, adding support for WebRTC, WebAudio, and WebGL.
Chromium M37 also includes native support for all of the Web Components specifications: Custom Elements, Shadow DOM, HTML Imports, and Templates. This means you can use Polymer and its material design elements in a WebView without needing polyfills.
Although WebView has been based on Chromium since Android 4.4, the Chromium layer is now updatable from Google Play.
As new versions of Chromium become available, users can update from Google Play to ensure they get the latest enhancements and bug fixes for WebView, providing the latest web APIs and bug fixes for apps using WebView on Android 5.0 and higher.
Android 7.0 Nougat
Chrome + WebView, Together
Starting with Chrome version 51 on Android 7.0 and above, the Chrome APK on your device is used to provide and render Android System WebViews. This approach improves memory usage on the device itself and also reduces the bandwidth required to keep WebView up to date (as the standalone WebView APK will no longer be updated as long as Chrome remains enabled).
You can choose your WebView provider by enabling Developer Options and selecting WebView implementation. You can use any compatible Chrome version (Dev, Beta or Stable) that is installed on your device or the standalone Webview APK to act as the WebView implementation.
Multiprocess
Starting with Chrome version 51 in Android 7.0, WebView will run web content in a separate sandboxed process when the developer option «Multiprocess WebView» is enabled.