на каком браузере можно выполнять задания с окружением android native browser в проекте серп
Сравнительный обзор Android-браузеров
Привет, Хабр. Мы подготовили для вас сравнительный обзор 10 браузеров под Android, оцениваемых по функциональности, производительности, дизайну. Уместно отметить, что мобильных браузеров гораздо больше десяти. Их слишком много, чтобы сделать полноценный Топ 2014 года в масштабах одной публикации. Вместо того, чтобы полагаться только на популярность (или скорость работы), в шорт-лист вошли приложения, который представляет весь спектр реализуемых в мобильных браузерах технологий, включая новичков, ещё не собравших большую аудиторию пользователей (по материалам статьи The best Android browsers, 2014 edition: design, features, and performance)
Интерфейс и дизайн
В популярных тестах мобильных браузеров для Android акцент сделан на скорость. В этом был смысл, когда большинство смартфонов не могли похвастаться высокой производительностью. Теперь всё по-другому, и даже самые дешевые устройства обеспечивают достаточную скорость работы, чтобы сосредоточиться в другом направлении – на дизайне интерфейса и юзабилити.
В этой сфере создатели браузеров отличаются повышенной «ленивостью». Мы видим, что мобильные браузеры крайне редко меняются внешне и, по большей части, являются миниверсиями наших настольных браузеров. У всех адресная строка расположена сверху, вкладки располагаются точь-в-точь как на десктопной версии, область отображения страниц идентична у всех приложений. Это странно, но из всех протестированных браузеров (даже тех, которые не попали в шорт-лист этой статьи), только у Habit Browser адресная строка сбежала с привычного месторасположения и оказалась в нижней части дисплея. Мы не считаем, что такая реализация совершенна, но на среднем Android смартфоне дисплей сейчас в опасной близости к 5-дюймовым размерам, и добраться до верхней адресной строки становится всё сложнее.
Chrome 
Chrome от Google знаком большинству пользователей, ведь на многих телефонах приложение установлено по умолчанию. Интерфейс Chrome приятный в использовании, но он совершенно ничем не выделяется. Типичный подход Google, зарекомендовавший себя с положительной стороны, ведь нет никаких проблем со скоростью работы и взаимодействием с интерфейсом. Прокрутка страниц, масштабирование, всё работает быстро и плавно, независимо от того, насколько «тяжёлые» страницы вы просматриваете (конечно, если у вас современный смартфон).
Firefox 
Отрицать богатый опыт компании Mozilla невозможно. Firefox – один из самых популярных браузеров для ПК и один из самых лучших браузеров для Android. Работает он довольно быстро, поддерживает синхронизацию вкладок и закладок в мобильной версии с настольной версией браузера. Как и его ПК-версия обладает упрощенным интерфейсом, хотя и не таким изящно-лёгким, как у Chrome.
Opera 
Opera является третьим и последним Android-браузером в этом списке, который может похвастаться родственными связями со «взрослой» настольной версией. Как и конкуренты выше по списку, Opera предлагает упрощенный, хоть и немного устаревший, дизайн. К счастью, следование «старой школе» означает лишь удобную работу с навигацией и отличные показатели по скорости, даже когда речь идет о работе с очень «тяжёлыми» сайтами.
Dolphin 
Это уже совершенно другая лига. Перед нами один из самых старых мобильных браузеров, доступных для Android, и из года в год он остаётся хорошей альтернативой популярному трио. Dolphin может похвастаться продуманным дизайном. Он остаётся одним из немногих браузеров, играющим с цветовым оформлением интерфейса (зелёный – цвет жизни). Он более многофункциональный, чем большинство конкурентов, но к счастью поддержка разных жестов, интеграция с социальными сетями, наличие синхронизации не только между разными устройствами, но и между разными браузерами, не сказываются в худшую сторону на скорости его работы.
UC Browser 
Как и Dolphin, UC Browser имеет более спокойный интерфейс. UI браузера хорошо проработана, элементы интерфейса расположены эргономично, что облегчает навигацию. По скорости работы к браузеру также нет нареканий.
CM Browser 
CM Browser новичок на Android, но ему уже есть чем похвастаться. У приложения самый минималистичный интерфейс, но реализован он со вкусом. CM Browser можно начать пользоваться мгновенно, не тратя время на изучение «функционала».
Javelin 
Этот браузер показался нам наиболее визуально-привлекательным. Он просто сделан красиво и воспринимается чуть лучше, чем просто инструмент для работы. В нём нет никаких излишеств, интерфейс прост, навигация осуществляется легче лёгкого.
Puffin 
Многие могут удивиться, почему Puffin вообще появился в этом списке, особенно учитывая его малопривлекательный дизайн. Действительно, Puffin можно считать худшим браузером в нашем обзоре, в нём есть серьёзные недостатки. Например, работа с пользовательским интерфейсом сопровождается длительными зависаниями даже на топовых устройствах. То же самое касается работы с веб-страницами. Прокрутка, масштабирование, работа с панорамным видом – всё это оставляет желать лучшего. Так что же забыл в статье «Лучшие Android браузеры» этот «отщепенец»? Об этом мы расскажем чуть позже.
Next Browser 
Красочный и в тоже время минималистичный интерфейс. Можно заметить задержку во время просмотра изображения на некоторых страницах, не всё гладко и с прокруткой, масштабированием.
Lightning Browser 
Chrome от Google. Интерфейс без излишеств, дополнительный функционал спрятан туда, где вы не сразу сможете его найти. Что касается навигации, интерфейс достаточно прост, работает с небольшими фризами.
Особенности
После того как вы познакомились с внешним видом представленных браузеров, вам, естественно, хочется узнать больше о поддерживаемом функционале. Некоторые из браузеров (Firefox, UC Browser, Dolphin) поддерживают расширения, но описать их все разом просто невозможно. Кроме того, средний пользователь никогда не будет пользоваться чем-то, что не работает сразу по принципу «установился и действует как мне нужно».
Так что же нам действительно нужно от браузера? Синхронизация. К сожалению, не все браузеры в нашем списке поддерживают эту функцию. Анонимность. Режим инкогнито стал своего рода стандартом, но и его предлагают не все браузеры. Наконец, сжатие данных всё ещё остаётся достаточно интересной функцией. Мы собрали все популярные функции и проверили, как наши браузеры справятся с ними.
* Adblocker Dolphin требуется JetPack (на Android 4.3-4.4). Flash поддерживается только через аддон.
* Puffin поддерживает flash всего 7 дней. После этого – угадайте что.
* Firefox поддерживает Flash только при установленном плагине.
Как вы можете заметить, UC Browser и Dolphin оказались наиболее многофункциональными. С другой стороны, Dolphin имеет ряд других, довольно уникальных особенностей (например, поддержка жестов).
Производительность
Даже самый визуально-привлекательных браузер не проживёт долго на вашем смартфоне, если он не обладает хорошей скоростью работы.
Конечно, синтетические тесты и реальный мир, это не одно и то же. Тесты не всегда рисуют репрезентативную картину реальной производительности. С другой стороны, некоторые тесты не только измеряют скорость работы в «попугаях», но и пытаются имитировать сценарии реальных действий пользователей.
Синтетические тесты
1. SunSpider
Разработанный Apple ещё в 2007 году, SunSpider остаётся частью стандартного набора тестов для браузеров. SunSpider анализирует способность браузера обрабатывать код JavaScript.
А вот и единственная причина по которой Puffin попал в список лучших браузеров. Puffin отлично справляется за счёт использования облачных вычислений. Что касается остальных, мы рады отметить успехи новичков, обогнавших даже Chrome от Google.
2. Mozilla Kraken
Как и SunSpider, Mozilla Kraken пытается измерить эффективность работы браузеров с JavaScript. Однако этот тест, если можно так выразиться, более хардкорный.
Неудивительно, что Puffin снова у руля, а вот Firefox неожиданно «слился», хоть браузер создан с Kraken в одной компании. Dolphin второй раз уверенно занимает последнее место.
3. Browsermark
Этот бенчмарк анализирует общую производительность браузеров (и стремится к тому, чтобы показать её реальной).
Снова Puffin оказывается впереди конкурентов, Chrome восстанавливает утраченные позиции, а Dolphin продолжает разочаровывать.
(*чем больше, тем лучше)
4. Peacekeeper
Peacekeeper (созданный финнами из компании Futuremark) также пытается измерить реальную производительность браузеров.
Да, ваши глаза не врут, Puffin снова показывает удивительный результат. Firefox неожиданно отстаёт.
(*чем больше, тем лучше)
Peacekeeper может также проверить браузеры на предмет их совместимости со стандартом HTML5. Учитывая, что отрасль считает HTML5 следующим логичным шагом развития, важно понять, способен ли ваш браузер обработать новый код.
Firefox показывает один из самых достойных результатов (наряду с UC Browser). Остальные браузеры нельзя назвать полностью HTML5-совместимыми.
(*чем больше, тем лучше)
Время загрузки страницы
Мы будем смотреть на скорость загрузки в двух различных состояниях – с новой страницей и ранее открытой. Важное правило: браузеры должны загрузить все содержимое страницы.
1. «Горячая загрузка» (загрузка страниц, которые вы уже посещали)
Синтетические тесты не лгут – Puffin действительно король, когда дело доходит до времени загрузки (горячей) страниц. Chrome, который всё равно открывает страницу быстро, всё же отстаёт.
К сожалению, Firefox и Dolphin (Opera тоже) отстают сильно от лидеров.
2. «Горячая загрузка» (мобильная версия сайта)
3. «Холодная загрузка»
Насколько хорошо ваш браузер обрабатывает страницы, которые вы посещаете впервые?
Ого, Puffin впервые потерял звание «самого быстрого». Однако это был единичный случай и на других страницах этот странный браузер вернул себе пальму первенства.
Что касается остальных, мы видим довольно схожие результаты, хотя Firefox и Javelin работают хуже. Dolphin, наконец, удалось всплыть со дна, и занять место середнячка. CM Browser показал очень достойный результат, а Chrome заслуженно всех победил.
4. «Холодная загрузка» (мобильная версия сайта)
Расход памяти
В последнем испытании мы проверили, как наши браузеры справляются с использованием памяти. В большинстве современных смартфонах есть как минимум 1 Гб оперативной памяти, однако всё ещё много людей пользуются и другими телефонами, в которых, к примеру, 512 мегабайт. Для этих устройств «съедание» памяти – это последнее, что им нужно.
(*в мегабайтах; чем меньше, тем лучше)
Как вы можете видеть, за исключением Firefox, Puffin, Chrome, и Opera, остальные показали схожий результат с Lightning Browser, оказавшемся самым «лёгким» из всех. Другими словами, если вашему устройству нахватает памяти, то Lightning Browser будет неплохим выбором — это простой, многофункциональный и быстрый браузер.
* Примечание: имейте в виду, что потребление памяти варьируется в зависимости от устройства.
Заключение
Мы использовали смартфон OnePlus One для тестирования всех браузеров.
Если исключить такие аномалии, как Puffin, мы увидим примерно средние результаты для всех браузеров. Да, можно сказать, что Dolphin, Opera, и Firefox, как правило, медленнее, чем остальные, а Chrome и CM Browser проявили себя как одни из самых быстрых. CM Browser порадовал простотой и скоростью работы. С другой стороны, Dolphin, несмотря на его проблемы в скорости работы, предлагает весьма интересный функционал.
Самое большое разочарование в этом тесте – Puffin. Разработчики явно сосредоточились не на том, а могли сделать один из лучших мобильных браузеров в мире.
В целом, мы можем заявить, что самые популярные – не означает самые лучшие. Если вы не желаете тратить время на выбор Android-браузера, ни один браузер в нашем списке вас не разочарует (мы серьезно, возможно вам даже Puffin понравится).
Две стороны WebView: о быстром запуске проектов и краже персональных данных
Меня зовут Евгений, я Full Stack JS разработчик, текущий стек Node.js + React + React Native. В разработке я более 10 лет. В мобильной разработке пробовал разные инструменты от Cordova до React Native. Получив опыт работы с Cardova, я понял, что мне хотелось бы создавать нативные интерфейсы, на мой взгляд WebView не должно быть всем приложением. Но это не значит, что его не надо использовать вовсе.
По приглашению коллег из Сбербанка, в этом посте хочу рассказать про гибридные мобильные приложения. При правильном подходе, это отличный способ быстро реализовать идею в виде хорошо работающего продукта, достаточного для первого запуска вашего стартапа.
Источник: srishta.com
Также немного расскажу о том, как вы можете использовать WebView и как его могут использовать против вас злоумышленники. Примеры в статье будут показаны с использованием фреймворка React Native, но те же идеи можно реализовать и без него.
Немного про стартапы
Начну с принципиальных отличий в запуске стартапов у нас и на Западе, расскажу, как здесь может помочь WebView, дам рабочие примеры взаимодействия веб и нативных элементов, а также советы по технике безопасности при взаимодействии со сторонними приложениями.
Как правило, чтобы стартап стал успешным, ему нужно быстро запуститься. Потеряешь время – и конкуренты тебя обойдут. Это понимают и у нас, и на Западе. Но российский подход к запуску, как правило, гораздо основательнее — в плохом смысле этого слова.
Все неудачные российские стартапы начинаются и развиваются примерно по одному сценарию. Наиболее частые ошибки связаны со стратегическим планированием развития программного продукта. Руководство думает, что запуск возможен только после 110%-ной реализации всей функциональности и всех нюансов. При таком подходе быстро возникает дефицит бюджета, поскольку расходы на разработку высокие, а доходов от стартапа еще нет. Поиск дополнительных инвестиций, бесконечный круг утверждений и переработок занимает кучу времени, продукт появляется у конкурента. Все, марафон проигран.
Европейские и американские стартапы действуют иначе. Для начала они ограничиваются только мобильной веб-версией с минимально достаточной функциональной частью. Ее можно смотреть и с десктопов, и с мобильных устройств. И на этом этапе проект готов к запуску! После запуска для мобильных устройств делается приложение.
Как правило, по основным возможностям приложение не отличается от веб-версии. Оно расширяет возможности взаимодействия с пользователем, например посредствам пуш-уведомлений. Такой подход обеспечивает выполнение основного условия — быстрый запуск, быстрое получение первой прибыли. Доходы с первого этапа можно инвестировать в развитие. В дальнейшем проект может масштабироваться и развиваться как угодно без дефицита бюджета, бесконечно выполняя итерационный подход для добавления нового функционала и развития пользовательского интерфейса.
Предлагаю подробнее рассмотреть тот этап, когда уже есть мобильная версия сайта и нужно разрабатывать приложение для мобильных устройств. Итак, мы сделали сайт, а значит занимались разработкой серверного API, интерфейса и бизнес-логики. Два из трех компонентов –
— интерфейс и логика — присутствуют и в мобильном приложении. Согласитесь, не хочется писать их заново.
Объединяем лучшее от нативных и веб-приложений
Есть инструменты, ориентированные на разработку нативных приложений. Другие предназначены для веба. Преимущество нативных приложений в том, что они могут использовать весь функциональный потенциал телефона. Но разрабатывать их по сравнению с веб-приложениями довольно сложно. Веб дает возможность простого старта, но сильно ограничивает возможности приложения.
* для уменьшения тавтологии веб-приложениями я назову мобильные приложения, основная часть логики и интерфейса которых реализована на стороне браузера
Объединить все достоинства нативных приложений и веба позволяют гибридные приложения, которые создают с помощью компонента WebView. Конечно, найдутся дотошные разработчики, которые категорически против WebView в любых его проявлениях. Они аргументируют это тем, что приложение должно сразу быть полностью нативным, чтобы можно было использовать все возможности мобильного устройства, а также обеспечить комфортную производительность пользовательского интерфейса. Но во многих случаях, когда возможностей мобильной версии сайта вполне достаточно, можно сократить время первого запуска, сделав гибридное приложение, и заменять его на нативное постепенно.
Гибридные приложения — это не всегда что-то плохое и не расширяемое. Они могут быть удобными и производительными. При грамотном использовании такой подход помогает получить достаточное время на разработку качественного приложения, а не выпускать нативное приложение на скорую руку.
Есть несколько ситуаций, в которых целесообразно использовать гибридные приложения. Они хороши в качестве временной заглушки для быстрого старта — когда у нас готова мобильная версия сайта, а мобильное приложение нужно было «вчера». Такое приложение можно создать за несколько часов, запустить в продакшн. Пользователи получат возможность работать с мобильным приложением, а вы — возможность работать над более полноценной версией в менее жестких временных рамках (если это нужно).
Вот пример. Недавно коллегам срочно понадобилось мобильное приложение. В веб-версии у него было восемь пунктов меню, и мы их отобразили через WebView. А потом по одному пункту заменяли. Так получилось выпустить приложение не через месяц-три, а буквально за несколько дней. После постепенно переводили его на натив.
Гибридное решение не всегда временное. Его возможности позволяют переиспользовать в приложении кодовую базу, созданную ранее для веб-версии. К примеру специфичные анимации уже созданные на Canvas. Также WebView удобен, когда используется какой-то сторонний сервис. Еще один вариант – когда у вас есть сложный интерфейс, который проще подключить через WebView.
Как использовать WebView
Возьмем популярный сценарий. Мы хотим использовать мобильную версию сайта и нативное меню. Мы создаем нативное приложение с меню, но вместо контента подключаем мобильную версию сайта через WebView (пока что без каких либо изменений).
На гифке можно увидеть 2 меню. Правое меню является частью сайта, реализованное на веб, слева нативное меню, реализованное внутри мобильного приложения. Чтобы получить первое приближение к нативному приложению, нам достаточно просто скрыть то меню, которое реализовано на веб. Вот сколько кода нужно, чтобы через WebView отобразить веб-версию внутри приложения:
Следующий пример – о том, как нативная часть может взаимодействовать с вебом.
Робот нарисован на Canvas, это часть веб-сайта. А переключатель к нему построен на нативном UI. На разных телефонах он будет выглядеть по-разному. Мы можем управлять движениями робота при помощи переключателя. Можно и наоборот – какими-то элементами веб-интерфейса влиять на приложение. В React Native для этого предусмотрено специальный API для взаимодействия между вебом и нативной частью.
Ниже код для использования этой анимации. Layout — все пространство. Picker — нативная часть, которая может выбирать из dropdown варианты состояния робота. WebView — контейнер для отображения веба, внутри которого отрисовывается робот.
Подобные кейсы возникают часто. Например, мы сделали приложение для тестирования и аттестации стоматологов. Для каждого варианта ответа в тесте внутри вопросов рисовалась анимация, реализованная посредствам Canvas на вебе. Задача состояла в том, чтобы создать мобильное приложение, с этим тестированием. Использовав WebView, мы смогли отображать анимации из веба, тогда как остальной интерфейс мы построили нативно. Анимация отлично работала даже на старых смартфонах.
Как делаются инъекции
До 2013 года браузер Opera использовал собственный движок Presto, но потом его перевели на движок Blink от Google. Многих пользователей это очень расстроило. Свет на причины этого перехода проливает видео «Зачем опере вебкит». Главные виновники — большие корпорации типа Google или Facebook, которые не тестировали код своих продуктов в Opera и запрещали отображение страниц в этом браузере, ссылаясь на то, что он не достаточно популярен у пользователей.
Например, заходишь на Gmail через Opera и видишь: «Ошибка JavaScript». Пишешь в саппорт, получаешь ответ: «Opera у нас не поддерживается, мы не будем писать под нее код». Сначала компания Opera нанимала разработчиков, чтобы писать инъекции – специальный код, который встраивался в Gmail и позволял ему работать в Opera. Но постепенно таких сайтов, как Gmail, становилось все больше. Opera сдалась и сменила движок.
Так о чем это я? Ах да самое время поговорить об инъекциях:
На гифке – пример инъекции, которая изменяет поведение сайтов. Допустим, у нас есть чужой сайт, и мы делаем инъекцию стилей – скрываем правое меню и слайдер, выезжающий справа. Это – инъекция стилей. Логика работы сайта не меняется, только отображение.
Код, написанный зеленым, — инъекция. Она скрывает элементы, на них нельзя нажать, с ними нельзя взаимодействовать. С виду получается полностью нативное приложение, без веб-элементов управления.
Следующая инъекция интереснее. Допустим, у нас есть мобильное приложение, а в нем — встроенный мобильный браузер.
Человек переходит по ссылке, и мы запросто подставляем ему страничку Фейсбука, в которой нужно ввести логин и пароль. Если человек его вводит – приложение его перехватывает. Вот код:
Такой код называется инъекцией логики. Обычно он сложнее, но не намного. То есть утащить пароль проще, чем скрыть элементы управления.
Минутка паранойи: браузеры, встроенные в приложения
Как известно, во многих приложениях есть встроенные браузеры (WebView) — например, ВКонтакте, Telegram, Gmail, WhatsApp и так далее. Крупным компаниям мы можем доверять, но WebView используется и огромным количеством приложений с малым количеством звезд и сомнительными авторами — к примеру QR-ридерами, файловыми менеджерами, оболочками для камер и т.п… Устанавливаешь приложение, читаешь через него код, нажимаешь на ссылку, вводишь конфиденциальные данные — и у приложения, как показано в предыдущем примере, появляется доступ к ним. А потом уже не отследишь, куда эти данные утекают. Поэтому для открытия ссылок пользуйтесь только браузерами, которым доверяете.
Есть сайты, которые запрашивают логин и пароль каждый раз. А есть такие, которые делают это редко — раз в месяц, раз в год. Как ни странно, второй вариант безопаснее с точки зрения утечки данных через WebView. Например, ты заходишь на сайт с какого-то левого браузера. Сайт требует логин и пароль, и тебе не кажется это странным – он всегда так делает. А в случае, когда авторизация требуется редко, это заставит насторожиться.
Интересно, что двухфакторная авторизация от такой атаки не защищает – только от кражи пароля. Дело в том, что после подтверждения тебе в ответ возвращается токен, который, в свою очередь, двухфакторной авторизации уже не имеет, и его легко перехватить. То есть если ты ввел логин и код с СМС один раз, то браузер получает токен, который можно использовать многократно. С этим подтвержденным токеном он может делать что хочет, в течение времени, пока токен остается актуальным. В общем, не стоит слишком доверять встроенным браузерам.
Познакомиться с примерами из этого поста можно через демо-приложения. На ОС Android нужно скачать Expo Project — инструмент для работы с JavaScript и React Native. После установки Expo останется только считать QR-код:
С устройствами под iOS сложнее: компания Apple запретила распространять приложения таким образом. Так что любопытствующим придется собрать приложение из исходников на GitHub. Спасибо за внимание!