Приложения для Android интерпретируются, а не компилируются. Делает ли это их медленнее, чем приложения iOS во время выполнения?
Приложения для Android интерпретируются, а не компилируются. Делает ли это их медленнее, чем приложения iOS во время выполнения?
Ответы:
Java не интерпретируется на Android. Приложения Android скомпилированы разработчиком в байт-код . Байт-код представляет собой компактное представление программы: он меньше исходного кода, написанного программистом, но все еще не исполняется непосредственно процессором. На этом этапе можно выполнить некоторые оптимизации, такие как удаление мертвого кода.
Когда вы загружаете приложение на устройство, JVM Dalvik компилирует байт-код в собственный исполняемый код, как только он собирается работать. Это сборник точно в срок . Это приводит к небольшому замедлению, пока программа ожидает компиляции, но после этого производительность не снижается, поскольку код был скомпилирован в собственный исполняемый код.
Есть некоторые преимущества в производительности, если вы делаете это таким образом, вместо того, чтобы предварительно компилировать его на компьютере разработчика. Приложение может быть скомпилировано для конкретного процессора на телефоне, используя его аппаратные функции и характеристики производительности. Например, он может использовать аппаратные операции с плавающей запятой, если его поддерживает ЦП. Кроме того, умный JIT-компилятор (по общему признанию, Dalvik не совсем такой умный) может следить за тем, как работает программа, и выполнять оптимизацию в зависимости от того, как программа используется в реальном использовании. Он может перекомпилировать код с лучшей подсказкой ветки, как только увидит, какие параметры включены и выключены в вашей среде на вашем телефоне. Открытый компилятор не имеет этой информации для использования.
Dalvik использует кеш Dalvik и другие методы, чтобы уменьшить недостатки компиляции JIT. Новая JVM для Android L и более поздних версий, ART, полностью заменяет JIT опережающим компилятором. Это компилирует байт-код в собственный исполняемый код, когда приложение установлено, чтобы получить большинство преимуществ JIT без задержки загрузки приложения.
Не забывайте, что приложения для Android не полностью состоят из Java. Разработчики имеют NDK для написания всех или части своих приложений на C или C ++ для критически важных частей приложения, особенно для игр. Специальные интерфейсы, такие как OpenGL и Renderscript, позволяют программистам использовать специальные аппаратные средства, такие как GPU и SIMD-сопроцессор, для некоторых видов вычислений.
Так что на самом деле, нет простого ответа на ваш вопрос. Использование JIT вместо предварительной компиляции делает некоторые вещи быстрее, некоторые медленнее. Это всего лишь часть общей производительности ОС.
Так как это широкий вопрос, вот широкий ответ.
«Являются ли приложения для iOS быстрее, чем приложения для Android, поскольку приложения для Android интерпретируются?»
Во-первых, приложения для iOS не «быстрее, чем» приложения для Android.
Во-вторых, что касается вопроса «Приложения для Android интерпретируются». Это то, что вы бы сказали о вычислительной технике, например «15 лет назад»: как вы можете видеть из приведенного выше обсуждения, сегодня ситуация намного сложнее; совершенно новые технологии вышли на первый план. Концепция "скомпилировано быстрее, чем интерпретируется!" было уместно сравнивать perl с машинным кодом 20 лет назад; Ситуация настолько изменилась, что сегодня эта проблема не может быть четко применена к «iOS V Android».
В-третьих, в мобильном программировании есть и другие проблемы, которые полностью перекрывают подобные соображения. Лишь один пример на местах, мобильные программисты не справляются с обработкой больших прокручиваемых списков изображений, отложенной загрузкой и аналогичными проблемами. То, как две ОС и различные популярные библиотеки решают эти критические проблемы, часто затопляет другие проблемы.
В-четвертых, еще одна серьезная проблема мобильных телефонов - это проблемы графического чипсета и различных сложных взаимосвязей этого с программным обеспечением, OpenGL и так далее. Например, Apple выпускает систему, которую они называют «Металл» в связи с этими проблемами, а Android выпускает собственную «штуку» в этой области. Эти проблемы, связанные с графическим конвейером, чрезвычайно важны для того, как приложения «чувствуют» себя в руке.
Очень краткий ответ на ваш вопрос «составленный V. интерпретированный» - это, по сути, устаревший вопрос для обсуждения, вы знаете?
(Кроме того, я не нахожу Note3 более «медленным», чем iPhone. Кроме того, отчасти это чистый артефакт - существуют недорогие телефоны Android: просто не производятся низкопроизводительные айфоны, поэтому некоторые люди могут ошибаться идеи из этого.)
Потому что интерпретируемые приложения не означают, что они всегда медленные. Иногда они более мощные и динамичные по сравнению с компилируемыми. Поскольку все коды в скомпилированном приложении компилируются один раз, а выходные данные сохраняются в виде библиотек или исполняемых файлов, в то время как на интерпретированном языке один раз можно произвольно изменить последовательность выполнения. Таким образом, я могу сказать, что это зависит от разработчика до разработчика и от способа программирования.
Однако Java (язык программирования Android) не интерпретируется, а компилируется JIT. Это означает, что программы для Android компилируются непосредственно перед тем, как вы их запускаете, обеспечивая производительность, аналогичную для iOS Objective C.
В последнее время Android ART Framework предварительно компилирует приложения, поэтому они запускаются так же, как приложения для iOS. Другими словами, следующая версия Android, вероятно, будет такой же быстрой, как и iOS.
Обновить
Языки программирования обычно делятся на две категории: скомпилированные или интерпретированные. В случае скомпилированного языка вводимый код сокращается до набора машинно-специфических инструкций перед сохранением в виде исполняемого файла. В интерпретированных языках код сохраняется в том же формате, в котором вы ввели. Скомпилированные программы обычно работают быстрее, чем интерпретируемые, потому что интерпретируемые программы должны быть сведены к машинным инструкциям во время выполнения. Однако с помощью интерпретируемого языка вы можете делать то, что нельзя делать на скомпилированном языке. Например, интерпретируемые программы могут изменять себя, добавляя или изменяя функции во время выполнения. Также обычно легче разрабатывать приложения в интерпретируемой среде, поскольку вам не нужно перекомпилировать приложение каждый раз, когда вы хотите протестировать небольшой раздел.