проверять байт код приложений

Отключение проверки байт-кода для ускорения работы ОС Android

Многие пользователи задаются вопросом увеличения производительности своего Android-гаджета, ведь это не просто «звонилка» в случае со смартфоном, и не просто медиаплеер, в случае, если это планшет.

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

otklyuchenie proverki bajt koda dlya uskoreniya raboty os android

Большинство пользователей Android-устройств слышали о таких понятиях, как одексированная и деодексированная прошивка. На данную тему мы уже составили отдельную статью. Так вот, отключение проверки байт-кода или disabling verify-bytecode, способно заметно улучшить производительность, особенно на аппаратах со сравнительно небольшим (256-512 Мбайт) объемом оперативной памяти. Изначально считалось, что данный твик актуален только для деодексированных прошивок, но практика показывает, что он полезен и для одексированных версий. Сразу отметим, что всегда перед проведением каких-либо манипуляций с программным обеспечением вашего устройства, настоятельно рекомендуется создавать резервные копии.

Для проведения данной операции нам потребуются, во-первых, Root-права и инсталлированный Root Explorer, а во-вторых, установленный терминал, например Android Terminal Emulator.

Итак, после создания полного бекапа всех данных, открываем терминал и прописываем в него последовательно следующие команды:

setprop dalvik.vm.verify-bytecode false

setprop dalvik.vm.dexopt-flags v=n, o=v

Далее, используя Root Explorer, находим файл build.prop, который находится в памяти устройства в директории system. Открываем его и добавляем туда следующие строки:

Внимание! Если какая-то из строчек уже присутствует в файле, достаточно изменить их значения на указанные выше, дубликатов быть не должно!

После этого снова открываем терминал, куда вводим следующие команды поочередно:

После чего производим перезагрузку устройства и радуемся полученному результату.

Если по какой-либо причине вдруг понадобится отключить действие данного твика, то есть обратно включить проверку байт-кода, то достаточно открыть терминал и ввести туда такие команды:

setprop dalvik.vm.verify-bytecode true

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

Источник

Отключаем проверку байт-кода или ускоряем работу android

category

Все про Android

4995 android proform faster

4995 android proform faster

ee8 c

В данной статье я опишу как отключить проверку байт-кода(disabling verify-bytecode).
Q: Зачем это делать?
A: Данный твик дает прирост производительности в деодексированной прошивке как при одексированной. Актуально на аппаратах с размером оперативной памяти 256-512мб!
Q: Опасно ли это?
A: Все зависит от прямоты ваших рук и желания делать бэкап.

Непосредственно инструкция:
Шаг 1
Делаем полный бэкап данных! Описывать как делать бэкап не буду. Если не умеете- учитесь. Инструкций море!

Шаг 2
Открываем эмулятор терминала на телефоне и вводим следующие команды:

В качестве иллюстрации:
766 terminal

Если какая-либо из строк уже есть в файле, то измените их на данные значения! Главное чтобы не было дубликатов!
В качестве иллюстрации:
4c2 build

Шаг 4
Открываем снова эмулятор терминал и вводим:

Отключение твика:
Если вы решили отключить данный твик, т.е. включить проверку байт-кода, тогда открываем терминал и вводим:

Итоги:
В итоге мы получим небольшой прирост оперативной памяти, прирост производительности, более плавное переключение приложений, быстрый повторный запуск приложений.
Но, стоит отметить, что возможна некорректная некоторых приложений(не заметил) и у некоторых наблюдаются зависания при вынимании/вставки sd-карты!

Источник

Что значит проверять байт код приложений доступных для отладки?

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

Вирусы

Главная угроза для каждой компьютерной системы – это атака вирусами. Если не считать социальные взаимодействия, когда пользователь сам выкладывает всю информацию. Телефоны играют очень большую роль в жизни человека и на них хранится много важной или конфиденциальной информации. От обычных контактов до данных платежей или карточек. Все это должно быть защищено, потому что первым делом стараются утащить именно это. b7813ab6a94a94a3496b0055226404db

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

Проверка байт кода приложений доступных для отладки

Проверка байт-кода гарантирует, что код не может делать такие вещи, как переинтерпретация int в качестве указателя и произвольный доступ к памяти. Это наиболее полезно, если вы пытаетесь запустить ненадежный код в песочнице Java. 240747 O

Если вы полностью доверяете всему коду, который вы запускаете, это менее полезно, так как в этом случае он просто поймает случайные ошибки. Также возможно, что информация о проверке поступает в оптимизатор – не уверен в этом, но оптимизатор в любом случае должен проверить код, чтобы выполнить какой-либо полезный статический анализ.

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

Читайте также:  кузница и пламя вальгалла баг

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

Источник

Путь к пониманию байт-кода V8

V8 — это JavaScript-движок Google с открытым кодом. Его используют Chrome, Node.js и многие другие приложения. Этот материал, подготовленный сотрудником Google Франциской Хинкельманн, посвящён описанию формата байт-кода V8. Байт-код довольно просто читать, если понять некоторые базовые вещи.

04ac08c9e48756beb3c9742485f0e6ea

Конвейер компиляции V8

image loader

Зажигание! Пуск! Интерпретатор Ignition, название которого можно перевести как «зажигание», является частью конвейера компиляции V8 с 2016-го года

Когда V8 компилирует JavaScript-код, парсер генерирует абстрактное синтаксическое дерево. Синтаксическое дерево — это древовидное представление синтаксической структуры JS-кода. Интерпретатор Ignition генерирует байт-код из этой структуры данных. Оптимизирующий компилятор TurboFan, в итоге, генерирует из байт-кода оптимизированный машинный код.

image loader

Конвейер компиляции V8

Если вы хотите узнать о том, почему V8 имеет два режима исполнения, взгляните на моё выступление с JSConfEU.

Основы байт-кода V8

Байт-код — это абстракция машинного кода. Компилировать байт-код в машинный код проще, если байт-код спроектирован с использованием той же вычислительной модели, которая применяется в физическом процессоре. Именно поэтому интерпретаторы часто являются регистровыми или стековыми машинами.

Интерпретатор Ignition — это регистровая машина с накопительным регистром.

image loader

Код слева удобен для людей. Код справа — для машин

Анализ байт-кода функции

Теперь, после того, как мы разобрали основные понятия, посмотрим на байт-код реальной функции.

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

Команда LdaSmi [1] загружает константу 1 в накопительный регистр.

image loader

image loader

LdaNamedProperty a0, [0], [4]

Теперь содержимое регистров выглядит следующим образом.

image loader

image loader

Обратите внимание на то, что байт-код, которому посвящён этот материал, используется в V8 версии 6.2, в Chrome 62 и в ещё не выпущенном Node 9. Мы, в Google, постоянно работаем над V8 в направлениях улучшения производительности и уменьшения потребления памяти. В других версиях V8 в байт-коде могут присутствовать некоторые отличия от того, что было описано здесь.

Итоги

На первый взгляд байт-код V8 может показаться довольно-таки загадочным, особенно когда он выводится с массой дополнительных сведений. Однако, как только вы узнаете о том, что Ignition — это регистровая машина с накопительным регистром, вы сможете понять назначение большинства байт-кодов.

Уважаемые читатели! Планируете ли вы анализировать байт-код ваших JS-программ?

Источник

Интерпретаторы байт-кодов своими руками

image loader

Виртуальные машины языков программирования в последние десятилетия получили весьма широкое распространение. С презентации Java Virtual Machine во второй половине 90-х прошло уже достаточно много времени, и можно с уверенностью сказать, что интерпретаторы байт-кодов — не будущее, а настоящее.

Но данная техника, на мой взгляд, практически универсальна, и понимание основных принципов разработки интерпретаторов пригодится не только создателю очередного претендента на звание «Язык года» по версии TIOBE, но вообще любому программисту.

Словом, если вам интересно узнать, как складывают числа наши любимые языки программирования, о чём до сих пор спорят разработчики виртуальных машин и как безболезненно сопоставлять строки и регулярные выражения, прошу под кат.

Предыстория

Одна из самописных систем отдела Business Intelligence нашей компании имеет интерфейс в виде несложного языка запросов. В первой версии системы язык этот интерпретировался на лету, без компиляции, непосредственно из входной строки с запросом. Вторая версия парсера будет работать уже с промежуточным байт-кодом, что позволит отделить язык запросов от их выполнения и сильно упростит код.

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

В первой из них представлено пять небольших (до сотни строк простенького кода на C) виртуальных машин(ок), каждая из которых раскрывает определённый аспект разработки таких интерпретаторов.

Откуда есть пошли байт-коды в языках программирования

Виртуальных машин, самых разнообразных виртуальных наборов инструкций за последние несколько десятков лет было придумано великое множество. Википедия утверждает, что первые языки программирования стали компилироваться в различные упрощённые промежуточные представления еще в 60-е годы прошлого века. Какие-то из этих первых байт-кодов преобразовывались в машинные коды и выполнялись реальными процессорами, другие — интерпретировались на лету процессорами виртуальными.

Читайте также:  озера в чите где отдохнуть

Популярность виртуальных наборов инструкций в качестве промежуточного представления кода объясняется тремя причинами:

Давайте сделаем несколько простейших виртуальных машин на C и на этих примерах выделим основные технические аспекты реализации виртуальных машин.

Полные коды примеров выложены на GitHub. Примеры можно собрать любым относительно свежим GCC:

Все примеры имеют одинаковую структуру: сначала идёт код самой виртуальной машины, после — главная функция с assert-ами, проверяющими работу кода. Я старался внятно комментировать опкоды и ключевые места интерпретаторов. Надеюсь, статья будет понятна даже людям, ежедневно не пишущим на C.

Самый простой в мире интерпретатор байт-кода

Как я уже говорил, простейший интерпретатор сделать очень легко. Комментарии — сразу за листингом, а начнём непосредственно с кода:

Здесь меньше ста строк, но все характерные атрибуты виртуальной машины представлены. У машины единственный регистр ( vm.accumulator ), три операции (инкремент регистра, декремент регистра и завершение исполнения программы) и указатель на текущую инструкцию ( vm.ip ).

Операции передаются в функцию vm_interpret в виде массива байтов — байт-кода (англ. bytecode) — и последовательно выполняются до тех пор, пока в байт-коде не встретится операция завершения работы виртуальной машины ( OP_DONE ).

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

Некоторые исследователи (Virtual-machine Abstraction and Optimization Techniques, 2009) предлагают разделять виртуальные машины на высокоуровневые и низкоуровневые по близости семантики виртуальной машины к семантике физической машины, на которой будет выполняться байт-код.

В предельном случае байт-код низкоуровневых виртуальных машин может полностью повторять машинный код физической машины с имитацией оперативной памяти, полным набором регистров, инструкциями работы со стеком и так далее. Виртуальная машина Bochs, например, повторяет набор инструкций архитектуры x86.

И наоборот: операции высокоуровневых виртуальных машин близко отражают семантику компилируемого в байт-код специализированного языка программирования. Так работают, например, SQLite, Gawk и многочисленные версии Prolog.

Промежуточное положение занимают интерпретаторы языков программирования общего назначения, имеющие элементы как высокого, так и низкого уровней. В популярнейшей Java Virtual Machine есть как низкоуровневые инструкции для работы со стеком, так и встроенная поддержка объектно-ориентированного программирования с автоматическим выделением памяти.

Приведённый же код относится скорее к самым примитивным из низкоуровневых виртуальных машин: каждая виртуальная инструкция — обёртка над одной-двумя физическими инструкциями, виртуальный регистр же полностью соответствует одному регистру «железного» процессора.

Аргументы инструкций в байт-коде

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

Расширим пример, внеся инструкции (OP_ADDI, OP_SUBI), принимающие аргумент в виде байта, следующего непосредственно за опкодом:

Новые инструкции (см. функцию vm_interpret ) читают из байт-кода свой аргумент и прибавляют его к регистру / вычитают его из регистра.

Такой аргумент называется непосредственным аргументом (англ. immediate argument), поскольку он располагается прямо в массиве опкодов. Главное ограничение в нашей реализации заключается в том, что аргумент представляет собой один-единственный байт и может принимать только 256 значений.

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

Стековая машина

Инструкции в нашей несложной виртуальной машине всегда работают с одним регистром и никак не могут передавать друг другу данные. Кроме того, аргумент у инструкции может быть только непосредственный, а, скажем, операции сложения или умножения принимают два аргумента.

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

В этом примере операций уже больше, и почти все они работают только со стеком. OP_PUSHI помещает на стек свой непосредственный аргумент. Инструкции OP_ADD, OP_SUB, OP_DIV, OP_MUL извлекают по паре значений из стека, вычисляют результат и помещают его обратно на стек. OP_POP_RES снимает значение со стека и помещает его в регистр result, предназначенный для результатов работы виртуальной машины.

Для операции деления (OP_DIV) отлавливается ошибка деления на ноль, что останавливает работу виртуальной машины.

Возможности такой машины намного шире предыдущей с единственным регистром и позволяют, например, вычислять сложные арифметические выражения. Другим (и немаловажным!) преимуществом является простота компиляции языков программирования в байт-код стековой машины.

Регистровая машина

Благодаря своей простоте стековые виртуальные машины получили самое широкое распространение среди разработчиков языков программирования; те же JVM и Python VM используют именно их.

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

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

Читайте также:  код тн вэд 6203191000

Альтернатива стековым машинам — регистровые виртуальные машины. У них более сложный байт-код: в каждой инструкции явно закодированы номер регистров-аргументов и номер регистра-результата. Соответственно, вместо стека в качестве хранилища промежуточных значений используется расширенный набор регистров.

В примере показана регистровая машина на 16 регистров. Инструкции занимают по 16 бит каждая и кодируются тремя способами:

У нашей небольшой виртуальной машины совсем мало операций, поэтому четырёх бит (или 16 возможных операций) на опкод вполне достаточно. Операция определяет, что именно представляют оставшиеся биты инструкции.

Первый вид кодирования (4 + 4 + 8) нужен для загрузки данных в регистры операцией OP_LOADI. Второй вид (4 + 4 + 4 + 4) используется для арифметических операций, которые должны знать, где брать пару аргументов и куда складывать результат вычисления. И, наконец, последний вид (4 + 4 + 8 ненужных бит) используется для инструкций с единственным регистром в качестве аргумента, в нашем случае это OP_MOV_RES.

Для кодирования и декодирования инструкций теперь нужна специальная логика (функция decode ). С другой стороны, логика инструкций благодаря явному указанию на расположение аргументов становится проще — исчезают операции со стеком.

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

Надо заметить, что на практике в регистровых виртуальных машинах обычно есть и стек, куда помещаются, например, аргументы функций; регистры же используются для вычисления отдельных выражений. Даже если явного стека нет, то для построения стека используется массив, играющий ту же роль, что оперативная память в физических машинах.

Стековые и регистровые машины, сравнение

Есть интересное исследование (Virtual machine showdown: Stack versus registers, 2008), оказавшее большое влияние на все последующие разработки в области виртуальных машин для языков программирования. Его авторы предложили способ прямой трансляции из стекового кода стандартной JVM в регистровый код и сравнили производительность.

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

Как уже упоминалось выше, у этой эффективности есть вполне осязаемая цена: компилятор должен сам аллоцировать регистры и дополнительно желательно наличие развитого оптимизатора.

Спор о том, какая же архитектура лучше, всё ещё не закончен. Если говорить о компиляторах Java, то байт-код Dalvik VM, до недавних пор работавший в каждом Android-устройстве, был регистровым; но титульная JVM сохранила стековый набор инструкций. Виртуальная машина Lua использует регистровую машину, но Python VM — по-прежнему стековая. И так далее.

Байт-код в интерпретаторах регулярных выражений

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

Главная инструкция — OP_CHAR. Она берёт свой непосредственный аргумент и сравнивает его с текущим символом в строке ( char *sp ). В случае совпадения ожидаемого и текущего символов в строке происходит переход к следующей инструкции и следующему символу.

Машина также понимает операцию перехода (OP_JUMP), принимающую единственный непосредственный аргумент. Аргумент означает абсолютное смещение в байт-коде, откуда следует продолжать вычисление.

Последняя важная операция — OP_OR. Она принимает два смещения, пробуя применить сначала код по первому из них, потом, в случае ошибки, второму. Делает она это при помощи рекурсивного вызова, то есть инструкция делает обход в глубину дерева всех возможных вариантов регулярного выражения.

Удивительно, но четырёх опкодов и семидесяти строк кода достаточно, чтобы выразить регулярные выражения вида «abc», «a?bc», «(ab|bc)d», «a*bc». В этой виртуальной машине даже нет явного состояния, так как всё необходимое — указатели на начало потока инструкций, текущую инструкцию и текущий символ — передаётся аргументами рекурсивной функции.

Если вам интересны детали работы движков регулярных выражений, для начала можете ознакомиться с серией статей Расса Кокса (англ. Russ Cox), автора движка для работы с регулярными выражениями от Google RE2.

Итоги

Давайте подведём итоги.

Для языков программирования общего назначения используются, как правило, две архитектуры: стековая и регистровая.

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

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

С другой стороны, в популярных виртуальных машинах большую роль играют и высокоуровневые инструкции. В Java, например, это инструкции полиморфных вызовов функций, аллокация объектов и сборка мусора.

Чисто высокоуровневые виртуальные машины — к примеру, интерпретаторы байт-кодов языков с развитой и далёкой от железа семантикой — большую часть времени проводят не в диспетчере или декодере, а в телах инструкций и, соответственно, относительно эффективны.

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

Источник

Поделиться с друзьями
admin
Здоровый образ жизни: советы и рекомендации
Adblock
detector