Dalvik (software)

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání
Dalvik
Vývojář Dan Bornstein
Operační systém Linux (jádro)
Platforma Android (operační systém)
Licence Apache Licence 2.0
Web http://source.android.com/devices/tech/dalvik/index.html
Dalvik Executable
Přípona souboru .dex

Dalvik je v informatice název virtuálního stroje od firmy Google, který v systému Android vytváří běhové prostředí pro aplikace napsané v programovacím jazyce Java. V systému Android 4.4 „KitKat“ byl v roce 2013 uveden jako ukázka Dalvikův nástupce Android Runtime (ART) a ve verzi Android 5.0 „Lollipop“ v roce 2014 již ART úplně nahradil původní virtuální stroj Dalvik.

Programy pro Android jsou převážně psané v programovacím jazyce Java. Jsou kompilovány do bajtkódu pro Java Virtual Machine. Ten je posléze přeložen do Dalvik bajtkódu a uložen v .dex (Dalvik EXecutable) a .odex (Optimized Dalvik EXecutable) souborech. Pojmy odex a de-odex se používají ve spojení s konverzí bajtkódu. Kompaktní formát Dalvik Executable je navržen pro systémy, které jsou omezeny paměťovou nebo výkonovou kapacitou.

Architektura[editovat | editovat zdroj]

Java Virtual Machine jsou zásobníkové počítače, naproti tomu Dalvik Virtual Machines používají architekturu založenou na registrech. Ta vyžaduje méně složitých instrukcí virtuálního stroje. Programy pro Dalvik jsou napsané v Javě s využitím Android API. Napsané aplikace jsou dále zkompilovány do Java bajtkódu a podle potřeby převedeny na Dalvik instrukce.

Nástroj zvaný dx se používá k převodu Java .class souborů do formátu .dex. Větší množství tříd je zahrnuto v jediném .dex souboru. Duplicitní řetězce a konstanty používané ve více třídách jsou ve výstupním .dex souboru obsaženy pouze jednou (pro úsporu místa). Java bajtkód je pak převeden do instrukční sady používané Dalvik Virtual Machines. Nekomprimované soubory .dex jsou typicky o pár procent menší než komprimované soubory .jar (Java ARchive) (při použití stejných .class souborů).[1]

Spustitelné soubory Dalvik (Dalvik Executable) mohou být při instalaci do mobilního zařízení znovu upravené a to s cílem dalších optimalizací.

Výkon[editovat | editovat zdroj]

Přínosy zásobníkových počítačů oproti registrovým počítačům jsou předmětem pokračující debaty.[2]

Zásobníkové počítače obecně musí použít instrukce k načtení dat do zásobníku a s těmi daty dále manipulují. Při implementaci vysokoúrovňového kódu to vyžaduje více instrukcí oproti použití registrových počítačů. Instrukce v registrových strojích bývají ovšem delší, protože musí kódovat zdrojové a cílové registry. Tento rozdíl je nejvíce důležitý kvůli interpretům Virtual Machines, pro které je vystavení operačního kódu velice drahou záležitostí. Podobně tomu je i u jiných faktorů, jako je just-in-time kompilace.

Testy provedené na ARM zařízeních v roce 2010 firmou Oracle (majitelem Java technologií) ukazují, že Java SE embedded (při použití standardních bezgrafických benchmarků) je dvakrát až třikrát rychlejší než Android 2.2 (v něm byl poprvé použit JIT kompilátor).[3]

V roce 2012, bylo akademicky prokázáno, že Dalvik je téměř 3× pomalejší než HotSpot, mimo jiné se ukázalo, že kód generovaný Dalvikem byl delší než kód generovaný HotSpotem.[4]

Kromě toho testy provedené na stejných Android zařízeních (březen 2014) ukazují, že nativní C aplikace mohou být až 30× rychlejší než aplikace spuštěné na Dalvik Virtual Machines.[5] Aplikace spuštěné interpretem z roku 2009 vykazují při použití jak Java Native Interface, tak nativního kódu zvýšení rychlosti.

Licence a patenty[editovat | editovat zdroj]

Dalvik je zveřejněn pod licencí Apache Licencí 2.0. Podle Google je Dalvik implementován jako clean-room, což by znamenalo, že nedědí licenci (její omezení), pod kterou je Java Runtime (standardní ani open-source edice).[6] Tento fakt je zdrojem pří, jež vyvolává hlavně Oracle.[7]

Reference[editovat | editovat zdroj]

V tomto článku byl použit překlad textu z článku Dalvik (software) na anglické Wikipedii.

  1. BORNSTEIN, Dan. Presentation of Dalvik VM Internals [PDF]. Google, 2008-05-29, [cit. 2010-08-16]. S. 22. [1]. (anglicky) 
  2. SHI, Yunhe; GREGG, David; BEATTY, Andrew. Virtual Machine Showdown: Stack Versus Registers [online]. 2005-06-11, [cit. 2009-12-22]. [2]. (anglicky) 
  3. VANDETTE, Bob. Java SE Embedded Performance Versus Android 2.2 [online]. Oracle Corporation, 2010-11-22, [cit. 2011-09-04]. The results show that although Androids new JIT is an improvement over its interpreter only implementation, Android is still lagging behind the performance of our Hotspot enabled Java SE Embedded. As you can see from the above results, Java SE Embedded can execute Java bytecodes from 2 to 3 times faster than Android 2.2. [3]. (anglicky) 
  4. Hyeong-Seok Oh, Beom-Jun Kim, Hyung-Kyu Choi, Soo-Mook Moon. Evaluation of Android Dalvik virtual machine [online]. Association for Computing Machinery, 2012, [cit. 2014-03-23]. In the JITC mode, however, Dakvik is slower than HotSpot by more than 2.9 times and its generated code size is not smaller than HotSpot's due to its worse code quality and trace-chaining code. [4]. (anglicky) 
  5. Top AndEBench Scores [online]. www.eembc.org, [cit. 2014-03-23]. [5]. (anglicky) 
  6. Stefano Mazzocchi. Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME [online]. 2016-10-01, [cit. 2010-08-16]. [6]. (anglicky) 
  7. Ed Bott. The real history of Java and Android, as told by Google [online]. ZDNet, September 8, 2011, [cit. 2011-11-27]. The definition of a “clean room” implementation is that the engineers writing the code have no direct exposure to the original, copyrighted material, including code, specifications, and other documentation. That’s a problem for Google, as I noted in yesterday’s post, because there is substantial evidence that the engineers working on the project had direct access to the copyrighted material. [7]. (anglicky)