Pull to refresh
4
0

User

Send message
Аккумулятор внутри телефона, скорее всего, имеет напряжение 3,7 В, а зарядка выдаёт 5 В (в случае QuickCharge — 9 или 12), потери на преобразовании. Более долгая зарядка больше энергии успевает превратить в тепло. Но всё равно разница получается очень большая, может КПД преобразования напряжения сильно отличается, например? Не знаю чем ещё можно объяснить.
На официальном сайте на скриншотах – четвёртый андроид, пишут про поддержку аж 12 устройств многолетней давности, в новостях (последняя новость – август этого года) пишут про ожидание поддержки шестого андроида… Чисто внешне – они уже загнулись.
У OnePlus теперь своя ветка – OxygenOS, в т.ч. и для модели One, CyanogenOS вроде как уже не поддерживается (последние подписанные релизы – Android 6.0.1), а вот CyanogenMod – имеются и пользовательские сборки, и «официальные» сборки, причём как стабильные релизы, так и ночнушки.
Пришло обновление до версии 1.6.689.40 (Stable channel) (64 бит).
До сих пор явные косяки самостоятельного переключения раскладки при вводе адреса, дикие тормоза интерфейса при большом количестве вкладок, баг с открытием новой вкладки (по колёсику) в конце списка вкладок, во время загрузки некоторых тяжёлых сайтов (например) тормозит не только весь (!) интерфейс браузера, но даже мышка начинает дёргаться. Про какую-либо адекватную работу жестов при подобной нагрузке вообще молчу, так как обработка жестов (как и других пользовательских действий) привязана к процессу самой страницы, и всё тормозит, пока страница не проинициализируется до конца, и пока браузер не «отпустит».
Отписываюсь почти в каждом топике, но почти ничего не меняется, несмотря на идущие месяцы разработки. Ситуация с баг-репортингом та-же самая, я не собираюсь писать в пустоту, а строчить репорты на каждый глюк каждой версии, каждый раз спрашивая Shpankov про статус каждого – тоже не выход, мне кажется.

Запустил Оперу – как глоток свежего воздуха. Быстро работающий интерфейс, отсутствие тормозов интерфейса в зависимости от содержимого страницы, отсутствие насильного переключения раскладки (хотя общие косяки с самостоятельным переключением раскладки при создании новой вкладки тоже присутствуют), вкладки создаются именно там где ожидаешь. Не хватает лишь переключения вкладок через ПКМ+колёсико, надо будет опять через 1 и 2 переключаться. Встроенное окно Веб-инспектора, поддержка симуляции мобильных устройств в этом инспекторе, плюс рабочая синхронизация закладок. Похоже, что-то пошло не так при создании данного велосипеда, увы…
Подтверждаю, тоже воспроизводится проблема, только сегодня заметил. Vivaldi 1.5.658.44 (Stable channel) (64 бит), OS X. Вот прямо на этой странице, копирую только домен с протоколом (https://habrahabr.ru – набрал руками), но получаю в буфере «https://habrahabr.ru/company/vivaldi/blog/316196/#comment_9939194».

Если хоть один символ от начала адреса не выделить, то копируется только выделенное.
С выделением в другую сторону (до конца адреса) бага не воспроизводится.

Включена опция «Отображать полный адрес», отключение ничего не меняет.
Зато вот активация опции «Копировать и вставлять с кодировкой» исправляет проблему, копируется только выделенная часть. Кстати, совсем не понятен смысл опции по её названию, кодировка нестандартных URL-адресов сохраняется при её активации или наоборот?
извиняюсь, ответил не автору ветки, исправил.
Да ладно восстановление, до сих пор иногда новые вкладки (по колёсику) открываются в конце списка, несмотря на настройки. Достаточно её закрыть, и повторно открыть ссылку – тогда откроется уже именно где надо.
Вообще, странно: явная вещь, которая достаточно стабильно воспроизводится, которая дико бесит, которая уже даже исправлена «независимым тестировщиком», и не попала в релиз спустя почти три месяца с момента выхода предыдущей версии? Вы издеваетесь там, что-ли?
Жесты по переключению вкладок по ПКМ+колёсико перестают работать после длительного аптайма, явные проблемы с фокусом браузера, и прочие сложности – и это считается рабочим продуктом???
«Open link in New Tab» из инспектора до сих пор открывает две вкладки гарантированно.
Переход по ссылке из других приложений не активирует фокус Vivaldi.
Активация менеджера паролей 1Password переносит фокус на окно 1Password, и даже нажатие на окно браузера активирует Vivaldi обратно, но окно остаётся не в фокусе. Страница скроллится, но эффекты наведения не работают, а ссылки и прочие события срабатывают лишь по двойному клику – исправляется только переключением на другое приложение и обратно.
Половина видео в вконтакте не воспроизводится (привет HTML5, не знаю с чем связано, но тормоза во время инициализации на десяток секунд, в течение которых висит весь браузер), аудио (вк, гугломузыка) глючит, до сих пор на многих сайтах не работает звук (хотя всё работает в других хромообразных браузерах).
До сих пор не работают жесты на служебных страницах (например, история), но внезапно работают в настройках, если настроено «показывать во вкладке».
Жесты на странице не работают до загрузки и полной инициализации страницы, я уже привык сидеть и ждать загрузки страницы перед тем как переключиться на другую или что-либо сделать с текущей – иначе по ПКМ открывается меню, в котором случайно можно выбрать что-то лишнее, например, отправить страницу на печать.
До сих пор нельзя отменить окно предложения скачивания файла кнопкой Esc.
Устал бороться с раскладками клавиатуры на OS X: частично это проблема системы, но со стороны браузера тоже сделано криво: разные элементы ввода браузера имеют разные раскладки, в итоге не раз получал даже такое, что при фокусе в поле адреса (например, после создания вкладки) и начале вводе адреса, первый символ вводится на английском, затем раскладка зачем-то переключается на русский, и вводится на русском. Если ещё учесть особенности тормозной автоподстановки адресов и заголовков(!) сайтов, то вообще «весело» становится.
Если причина – патрон e14 (точнее, его размеры, где не получается разместить нужную электронику), то вариант использовать лампы с e27 через соответствующий переходник.
Автоподстановка удобна, когда она не мешает — то есть когда предлагает варианты лишь во время набора текста (но не во время удаления), или если предложения не вставляются сами (их сначала надо «принять»). А то уже бесит, когда при попытке удаления адреса текущей страницы он тут же вставляется обратно, и в результате открывается та же страница.
Если в линии 12В постоянного тока – зачем там транс, который на постоянке вообще не работает?
В том-то и профит, что реактовый DOM синхронизируется с реальным представлением (DOM в браузере, View в «нативной» разработке) средствами реакта, используя набор ухищрений для ускорения: это происходит асинхронно, если это не в браузере – то в отдельном потоке, к тому же используется дифференциальный метод – применяется минимально необходимый набор обновлений (патч) для приведения вида к требуемому. Ну и набор всяких хаков для ускорения там неимоверный. Если мы говорим о «нативной» разработке браузера, то наверняка используется react-native или что-то подобное, то тут и вовсе нет DOM'а, вместо него – реальные окна, элементы View, на каждой платформе свои. Причём это всё постоянно развивается, ускоряется, так что самое медленное место by design – это сам JS и то как его используют (известно, можно написать тормозящее г. на любом языке программирования).
Вообще, внутри используется React – там свой DOM, и нет HTML в явном виде. Это упрощает кросс-платформенную разработку, делая её чем-то проще, а чем-то и сложнее, просто проблемы другого уровня. Не думаю, что с этого пути свернут, учитывая количество сделанной работы. Но оптимизировать, надеюсь, всегда есть куда. В целом, скорость работы на нормальном железе неплохая, но вот плавающие баги и дёрганность интерфейса сильно напрягают, конечно.
Так всё равно удивительно, почему нештатный тестировщик исправляет явные баги браузера, которые должны исправлять сами разработчики, причём сразу же как только о них стало известно. Ладно кодировка, безопасность, все дела (хотя все браузеры как-то решили проблему, даже Safari научился), но легко воспроизводящиеся ситуации с вкладками, почему разработчики до сих пор не исправили это, учитывая наличие готового кода для исправления? Как разработчик, я понимаю, что не получится просто взять и вставить чужой код, но ведь проходят месяцы…
Если пойти дальше, то по факту он вообще не существует в гугловой реализации, надо искать сторонние библиотеки, на сайте Material Design – лишь рекомендация по варианту навигации. До сих пор чаще используются вкладки, листаемые или фиксированные. В Google+, например, вообще всё вместе: и нижний TabBar, и вкладки, и гамбургер.
Открывать жиру не будем, альтернативные списки (типа issues на гитхабе) вести не будем, уведомлять авторов об изменениях багов не будем, и это называется «лицом к аудитории»? Месяц за месяцем, год за годом ничего не меняется. На хабре не мамочки собрались, чтобы потрещать об браузере без конкретики, а технические специалисты, которые не видят вашего лица.
Многие баги не правятся месяцами, при этом человек со стороны даже сделал сайт, где можно скачать патченный bundle.js с нужными исправлениями, например, фикс открытия старой страницы по жесту мыши «создать вкладку», или фикс открытия вкладки в конце списка при нажатии на ссылку колёсиком, если до этого была закрыта вкладка, или фикс отображения национальных доменов (хотя пару раз уже чинили, потом опять почему-то сломали). То есть авторы браузера не могут сделать, а сторонний человек взял и сделал.
Гугл уже изобрёл свой TabBar для нижней навигации в Material Design, который вполне может заменить бургер-меню, или быть базовым элементом навигации в дополнение к бургеру.
Ага, только в том же Nexus 5X при всей его 64-битности (а нативные библиотеки присутствуют в системе в обоих вариантах: /system/lib + /system/lib64) лишь 2GB RAM + 0,5GB swap, чего ему явно маловато.
Всё хорошо, но если есть дизайнеры, прорабатывается UI и прочее, то это уже явно не уровень HelloWorld, о котором говорится в статье. Про работу фрагментов, про единые гайдлайны, про фоллбеки для старых систем, и прочее в сапорт-либах знаю, просто если мы про HelloWorld или другое тестовое приложение «для себя», то обычно незачем увеличивать размер выходного файла на полтора мегабайта лишь ради «единого дизайна». Новички, делая HelloWorld'ы ещё могут не знать как собирается и из чего состоит приложение (иначе эта статья бы не появилась), но при этом они получают в нагрузку много либ, непонятные неймспейсы в xml, кучу файлов в ресурсах и на выходе (если заглянут в итоговую сборку apk). К тому же, из-за переопределения стилей в support-либе меняется описание тех же стилей и некоторых элементов (например, android:showAsAction vs app:showAsAction в описаниях menu), что может создавать дополнительную путаницу для начинающих.
В IDE удобно писать код, но в текущих версиях android tools сборка происходит средствами сборщика – android build tools, gradle, maven-зависимости и вот это всё. Даже Android Studio просто запускает это внутри себя. Но никто не мешает запускать сборку из консоли через готовый gradle wrapper (./gradlew), или её же, но из той же IDE как gradle task. Зачастую это даже удобнее, так как виден результат выполнения процесса, а не просто один прогресс-бар, скрывающий за собой вызовы десятков команд.
Если таргетить приложение хотя бы на 4.0 и выше, то часто support libs не нужны, если не требуются различные фишки MaterialDesign и пр. Сам стиль Material легко вешается на приложение через обычные стили (в values-v21/styles.xml), и будет работать только на соответствующей платформе. При этом без библиотек совместимости размер итогового приложения действительно не будет превышать и сотни килобайт.

Information

Rating
Does not participate
Registered
Activity