Portál AbcLinuxu, 2. května 2025 05:42
Operační systém Android se na trhu mobilních telefonů objevil teprve nedávno. Od té doby zaznamenal raketový růst a dnes je jedním z nejpoužívanějších operačních systémů pohánějících chytré telefony. Spolu s rozšířením systému roste také poptávka po zajímavých aplikacích. V krátkém seriálu si ukážeme základy programování aplikací pro Android.
V tomto dílu si nejprve krátce povíme něco o samotném systému, představíme si vývojové nástroje a řekneme si něco o principech, na jakých OS Android funguje.
Android je open source platforma pro mobilní zařízení, která je založená na pozměněném linuxovém jádře. Systém byl původně vyvíjen firmou Android Inc., kterou v roce 2005 koupil Google. V roce 2007 pak byla založena Open Handset Alliance skládající se z několika desítek firem – kromě Googlu jsou to převážně výrobci mobilních telefonů, polovodičových součástek a také mobilní operátoři. OHA zastřešuje vývoj otevřených standardů pro mobilní zařízení a má za úkol kooperovat vývoj operačního systému Android.
Platforma se kromě linuxového jádra skládá z řady C/C++ knihoven – např. systémová libc, knihovny pro práci s médii, knihovny enginu webového prohlížeče, knihovny grafického enginu, SQLite knihovny a mnoho dalších.
Systém dále obsahuje Dalvik Virtual Machine, který slouží pro vykonávání bytecodu, na kterém jsou postaveny vyšší vrstvy systému. Dalvik Virtual Machine ale není Java Virtual Machine a používaný bytecode není Java bytecode. Přesto, jak mnozí vědí, se pro Android programuje primárně v Javě. Jak to? Android SDK (které rozebírám dále) obsahuje nástroj dx pro převod Javovských .class souborů do Dalvikovských .dex souborů. Při převodu se mimo jiné konvertuje Java bytecode do Dalvik bytecode. Měl bych ještě zdůraznit, že převod není stoprocentní, ne vše z Javy lze použít na Androidu, aplikace se tedy neprogramují v plnohodnotné Javě.
Systémové aplikační rozhraní, které aplikacím zprostředkovává nejrůznější API, je pak už stavěno nad virtuálním strojem. Součástí platformy je také řada už hotových aplikací – např. správce kontaktů, prohlížeč nebo samotná aplikace pro telefonování.
Na oficiální vývojářské stránce na developer.android.com je pro vývoj dostupná řada nástrojů, dokumentace a další zdroje. Nejdůležitější je zde SDK, bez kterého nic nevytvoříte. Díky vřelému vztahu Googlu k Linuxu je dostupné pro všechny hlavní platformy – Linux, Mac i Windows. SDK v základu obsahuje pouze některé vývojové nástroje, další části se doinstalovávají jako komponenty. Jednotlivé komponenty a další nástroje obsažené v SDK si rozebereme dále.
Pro vývoj aplikací, jejichž odezva je kriticky důležitá (především pro hry), lze využít Android NDK, což je balík pro vývoj Android aplikací v C/C++. Vývoj aplikací využívajících NDK je pokročilejší téma a nebudeme se jím zde zabývat.
Kromě SDK a NDK si lze stáhnout oficiální ADT plugin pro Eclipse, který značně usnadňuje vývoj a ladění aplikací. Protože je Eclipse díky svému pluginu primárním IDE, ve kterém se pro Android vyvíjí, budu ho dále v průběhu seriálu používat při tvorbě kódu a některé popisy a screenshoty se k němu budou vztahovat.
Pokud ovšem nejste fanouškem tohoto IDE, jsou tu i jiná řešení. Pro NetBeans existuje plugin pro vývoj Android aplikací, více o něm naleznete na kenai.com. V Intellij IDEA je od verze 10 také možné vyvíjet aplikace pro Android, více informací naleznete na jetbrains.com.
Holé SDK obsahuje pouze několik programů v adresáři tools. Asi nejdůležitější položkou je program android, kterým se spouští Android SDK and AVD Manager. Přes něj se stahují jednotlivé komponenty SDK – různé verze platformy Android a další rozšíření.
Android SDK mimo jiné obsahuje emulátor androidích zařízení. Emulátor je samostatná desktopová aplikace umožňující testování aplikací bez mobilního zařízení. Pomocí Android SDK a AVD Manageru lze vytvářet a spouštět Android Virtual Devices – nakonfigurované instance emulátoru. Lze si tak velice přesně vymodelovat vlastnosti konkrétního zařízení. Pokud je to pro ladění potřeba, lze spouštět více instancí emulátoru zároveň, jednotlivá AVD ovšem nelze spustit vícekrát současně. Pro spouštění instancí emulátoru lze také použít příkaz emulator, který má širokou škálu parametrů sloužících k další úpravě konfigurace AVD.
Dalším důležitým programem v SDK je ddms, jenž spouští Dalvik Debug Monitor – nástroj, s jehož pomocí lze ladit aplikace. Program umí komunikovat jednak s běžícími instancemi emulátoru, ale také s připojenými telefony. Pro ladění aplikací přímo v telefonu je nutné v nastavení telefonu povolit ladění přes USB (přepínač naleznete v sekci Aplikace -> Vývoj). Dále je ještě nutné nastavit počítač, aby zařízení rozpoznal – konkrétně v Ubuntu je třeba:
/etc/udev/rules.d/51-android.rulesSUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"„18d1“ uveďte příslušné id výrobce telefonu - to zjistíte na počítači po připojení zařízení např. pomocí příkazu lsusb (hodnota „18d1“ je pro Google Nexus One)chmod a+r /etc/udev/rules.d/51-android.rulesJeště pro úplnost dodám, že aby bylo možné aplikaci ladit, je v ní třeba provést malou úpravu v manifestu, o kterém se zmíním později.
Dalvik Debug Monitor umí mimo jiné zobrazovat logy přicházející z celého systému, simulovat různé akce emulátoru nebo zobrazovat různé ladící informace z virtuálního stroje. Aplikaci lze také využít pro získání screenshotů obrazovky – pro nerootované telefony je to prakticky jediný způsob, jak je vytvořit.
Nejdůležitějšími komponentami v SDK jsou platformy Androidu. Ty odpovídají produkčním platformám běžícím na skutečných zařízeních. Momentálně jsou dostupné verze 1.5, 1.6, 2.1, 2.2, 2.3.1, 2.3.3 a nově také verze 3.0. Každá platforma obsahuje systémové knihovny, systémový obraz, skiny emulátoru, ukázky kódu a jiné zdroje specifické pro platformu.
Android SDK Platform-tools je balík obsahující další vývojové nástroje, důležitý je zde především program adb – Android Debug Bridge. S ním lze např. na zařízení nahrávat soubory nebo aplikace. Program aapt slouží k vytváření a modifikaci aplikačních balíků.
Dalšími komponentami jsou balíky Google API, jenž jsou dostupné pro každou verzi platformy a obsahují knihovny Google map, které jinak nejsou základní součástí platformy. Pokud chcete vyvinout aplikaci využívající interně Google Mapy, budete tyto balíky potřebovat.
Market Licensing package obsahuje License Verification Library – knihovnu umožňující ověřování licence aplikace. Knihovna umí kontrolovat, zda byla běžící aplikace zakoupena a nejedná se o černou kopii. V SDK je též k dispozici komponenta GALAXY Tab Addon – emulátor Samsung Galaxy Tabu.
Kromě oficiální stránky developer.android.com lze na webu najít spoustu dalších zdrojů. Nejnovější inoformace ohledně Androidu naleznete na oficiálním blogu android-developers.blogspot.com. A protože je Android open source, můžete si stáhnout i zdrojové soubory k celému systému na stránkách source.android.com.
Android aplikace jsou zkompilované zdrojové soubory, které jsou společně s dalšími resourcy zabalené do ZIP balíku s koncovkou .apk – takzvaného Android package. Ten slouží k distribuci aplikací a jejich instalaci na zařízení.
Jak už bylo zmíněno, Androidí aplikace se programují v „Javě“ a běží nad virtuálním strojem, který běží na linuxovém jádře. Každá spuštěná aplikace má svůj vlastní virtuální stroj.
Základní vlastností Androidu je možnost využít části jiných aplikací ve své aplikaci. Důvod k tomuto řešení byl prostý – zamezit opakovanému vytváření stejné funkcionality a usnadnit tak vývojářům práci. K tomuto účelu byly aplikace navrženy jako balíky několika komponent, které lze samostatně instanciovat. Existují čtyři typy komponent: activity, service, broadcast receiver a content provider, přičemž každá z těchto komponent slouží k jinému účelu. Postupně si je nyní projdeme.
Aktivita je základní vizuální komponenta – každá aktivita specifikuje jednu obrazovku aplikace. Představme si třeba e-mailového klienta, kde jedna aktivita zobrazuje seznam přijatých e-mailů, jiná aktivita zobrazuje obsah jednotlivých e-mailů a třetí slouží k jejich psaní. Samozřejmě by takovou aplikaci šlo také napsat jednou aktivitou s tím, že by se vždy kompletně změnil obsah. Takovou architekturu ale nelze doporučit, je to špatná a mnohem pracnější cesta. V čem je tedy kromě snazšího vývoje výhodná popisovaná struktura několika aktivit? Právě v možnosti jednotlivé kompenenty samostatně volat i z jiných aplikací. Například narazíme-li v prohlížeči na link odkazující nás na e-mailovou adresu, lze po kliku přejít do naší aktivity určené pro psaní e-mailů. K tomuto účelu stačí jen aktivitě předat požadovanou e-mailovou adresu.
Protože je aktivita vizuální komponentou, má okno, do kterého je možné kreslit. Okno aktivity typicky zaplňuje celou obrazovku, ale může být také menší – být jen plovoucím dialogem. Obsah okna je specifikován pomocí views. View je vizuální prvek, na obrazovce mu odpovídá obdélníkový prostor. View se řadí do hierarchické struktury – rodičovské prvky, nazývané layouty, organizují rozložení vnitřních prvků. Typ layoutu určuje, jakým způsobem budou jeho podřízené view rozloženy v dostupném prostoru. Příklad základních view je třeba tlačítko nebo obrázek.
Jiným typem komponenty je service (služba), která není uživatelsky viditelná a běží na pozadí. Příkladem je třeba komponenta určená k síťové komunikaci. V příkladu e-mailového klienta bychom mohli použít službu pro stahování a odesílání e-mailů na pozadí.
Tato komponenta slouží k „poslouchání“ broadcastových oznámení a k reakci na ně. Broadcast receivery nejsou, stejně jako služby, uživatelsky viditelné. Jako reakci na příchozí oznámení mohou například spustit jiné komponenty. Broadcasty mohou být jak systémové, tak uživatelské – aplikace si mohou vytvářet své vlastní broadcasty.
Jednoduchým příkladem může být receiver reagující na systémový broadcast oznamující nízký stav baterie. Reakcí naší aplikace může být například uložení aktualního stavu a ukončení aplikace. Dalšími příklady mohou být receivery reagující na odpojení nebo připojení sd karty. Jiným příkladem může být receiver reagující na příchozí textovou zprávu tím, že spustí další aktivitu, která danou zprávu zobrazí.
Poslední komponentou je content provider, který slouží ke zpřístupnění dat jiným aplikacím. Ty k datům přistupují pomocí instancí třídy ContentResolver. Data lze zpřístupnit ke čtení i k zápisu. Rozlišení toho, kdo může jen číst a kdo může i zapisovat, se provádí podle práv, jež aplikace mají a jež jsou vyžadována. Pomocí content resolveru lze přistupovat například k záznamům v adresáři telefonu, fotkám v galerii telefonu nebo záznamům o příchozích a odchozích hovorech.
Toto byly čtyři druhy stavebních kamenů aplikací určených pro operační systém Android. Aby mohlo vše fungovat jak má, je třeba nějak operačnímu systému sdělit, jaké komponenty jsou k dispozici. K tomu slouží Android manifest. Je to xml dokument, který specifikuje parametry aplikace – jednotlivé komponenty, požadovaná systémová práva a jiné požadavky na běh.
Jak už bylo zmíněno, jednotlivé komponenty aplikace mohou spouštět jiné komponenty, dokonce mohou spouštět i komponenty cizích aplikací. Všechny komponenty, mimo content providerů, se aktivují pomocí asynchronních zpráv tzv. intentů. Používání intentů je jednoduché, v příští části seriálu si ukážeme konkrétní příklady.
Nyní bych měl zmínit ještě jeden důležitý a možná trochu matoucí pojem, a to je task. Task je zásobník instancí aktivit, které byly postupně spuštěny. V momentě, kdy jedna aktivita spustí nějakou jinou aktivitu (může to být i aktivita z jiné aplikace), je tato nová aktivita instanciována a vložena na zásobník. Uživatel komunikuje s instancí na vrcholu zásobníku aktivního tasku.
Například pokud chceme ze své aplikace odeslat e-mail, můžeme pomocí intentu spustit aktivitu e-mailového klienta. Tato aktivita se tedy instanciuje a vloží na vrchol zásobníku. Ačkoli přecházíme mezi aktivitami různých aplikací, z uživatelského hlediska se zdá, že jsme stále v jedné aplikaci. Uživatel nyní může odeslat e-mail, po odeslání lze očekávat ukončení aktivity. Na vrchol zásobníku se tak dostává zpět aktivita, která předtím aktivitu e-mailového klienta spustila.
Pro pohyb na zásobníku také slouží tlačítko zpět. Pomocí něj je možné smazat vrchol zásobníku a přejít na předchozí aktivitu.
Tasků může být v systému samozřejmě více – nový task vzniká např. spuštěním aplikace z menu operačního systému. Task lze opustit, a pokud nebyly instance v něm ukončeny, tak se do něj lze také vrátit. Z uživatelského hlediska je tedy task aplikací.
V tomto díle jsme si řekli něco o tom, co je to Android, popsali si vývojové nástroje a zmínili základní principy a stavbu Androidích aplikací. Příště si ukážeme konkrétní ukázky kódu na jednodušší aplikaci.
Chceš se naplno pustit do vývoje skvělých aplikací pro Android? Pošli nám CV na chci.job@inmite.eu – v Inmite právě hledáme posily do našeho androidího týmu! Pokud nás chceš napřed poznat a nezávazně pokecat, určite se ukaž na Android Devcampu, na jehož organizaci se podílíme. Inmite je už od samého začátku českou jedničkou ve vývoji pro Android a s tvou pomocí bychom si pozici rádi upevnili :)
16.3.2011 01:16
David Watzke | skóre: 74
| blog: Blog...
| Praha
Hadejte - 600MHz ARM, nebo nekolikajadrove iBuhvikolik na 3+ GHz? :)To první v mobilním segmentu, to druhé v desktopovém.
lunch menu nabízí x86 build. Takže jsem možná kecal, večer to vyzkouším.
vbox_x86-eng se nezkompiluje, full_x86-eng ano. Chybí prebuilt jádro. generic_x86 a make installer_vdi dokonce vytvoří obraz disku pro VirtualBox, ale nedá se dostat přes GRUB. Předpokládám, že kdyby někdo chtěl, asi by to do bootovatelného stavu dostal, já k tomu nemám důvod.
Zajímalo by mne, jak se do AOSP dostávají věci. Honeycomb (Android 3.0) v AOSP pořád chybí (takže je efektivně closed-source), i když už se prodává v zařízeních (no, v jednom zařízení) a je k disposici SDKčko. Naopak x86 port už v AOSP je, ale podpora se do SDK Tools teprve začíná dostávat a na trhu to ještě není.
Dobrou noc.
)
Nechci emulator mobilniho zarizeni - chci dany system provozovat nativne.Pořád jste psal o x86. Pokud chcete Android nativně, poohlédněte se po nějakém mobilním telefonu.
Nehodlate snad tvrdit, ze emulace je v pripade x86 efektivnejsi, nez nativni behEmulace může být snadno efektivnější, než nativní běh. Zkuste si emulovat DOSové prostředí nebo třeba Amigu nebo Commodore.
ze nastroje, pouzite pri portu pro x86, jsou tak nizke kvality, ze tento nesmyslny paradox zpusobujiNástroje použité při portu (lidé) nemusí být nízké kvality, prostě jenom třeba zatím neměli dost času nebo chuť kvalitní port udělat.
Kvalitni port na jinou architekturu by melo zajistovat pouhe pouziti HLL (heh), a predpokladam, ze architektura x86 neni tak minoritni, nerozsirena a neznama, aby dostupne kompilatory nedovedly generovat alespon pseudooptimalniTipoval bych, že na rychlosti odezvy GUI bude mít kvalita kompilátoru minimální vliv. Daleko podstatnější je třeba forma multitaskingu a jeho podpora v hardware, zpracování událostí apod. A to vám žádný automat nevyřeší, to taky může znamenat třeba úplně změnit architekturu nějaké části systému. Vzpomeňte si třeba na problémy s vícejádrovými procesory, které občas mohou způsobit zpomalení proti témuž systému s jedním jádrem. S takovými problémy nebo jejich variantami se potýká i Linux – a kompilátor to nezachrání.
Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?To je jak do dubu... Android je OS pro mobilní zařízení. Na mobilních zařízeních má x86 minimální zastoupení. Takže ano, chceš toho celkem moc.
Emulace je vzdy maximalne STEJNE tak efektivni, jako nativni beh cehokoli, protoze je temi nativnimi instrukcemi v nejlepsim pripade 1:1 vykonavana (emulace plat. P na sobe same), jinak je VZDY pomalejsi vuci nativnimu vykonu host-platformy. Mrzi mne velmi, ze Vam toto musim vysvetlovat, a relevanci vasich argumentu to citelne snizuje.Zapomínáš na jednu důležitou věc - daná aplikace může být pro platformu výrazně hůře optimalizovaná, a tak se emulace může stát efektivnější.
16.3.2011 14:48
multi | skóre: 38
| blog: JaNejsemOdsut
Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?A já na nejrozšířenější hardwarové platformě chci provozovat Watsona nebo sekačku na trávu.
Emulace je vzdy maximalne STEJNE tak efektivni, jako nativni beh cehokoli, protoze je temi nativnimi instrukcemi v nejlepsim pripade 1:1 vykonavana (emulace plat. P na sobe same), jinak je VZDY pomalejsi vuci nativnimu vykonu host-platformy. Mrzi mne velmi, ze Vam toto musim vysvetlovat, a relevanci vasich argumentu to citelne snizuje.Zmínka o DOSu, Amize a Commodoru vás mohla varovat, abyste se takhle neztrapňoval. Pokud nativní platformě trvá zpracování jedné instrukce 1 s, a spustíte aplikaci na emulátoru, který k emulaci 1 emulované instrukce potřebuje 10 svých instrukcí, ale emulátor poběží na platformě, která zpracuje 1000 instrukcí za sekundu, poběží pod emulátorem program (co se týče počtu zpracovaných instrukcí) 100krát rychleji, než nativně.
Rychlost odezvy GUI uzce souvisi s portovanim, protoze predpokladam, ze zrovna rendering jeho prvku by mel byt resen i v necem tak hruznem, jako javisticko-dalvisticky android, nativnim volanim. Pokud tak reseno neni, TIM HURE.Vykreslování prvků tvoří jen menší část toho, co vnímáme jako odezvu GUI. Jinak zrovna to vykreslování může být něco, v čem samotný procesor x86 pokulhává za nativní platformou pro Android – protože v tom mobilu může být snadno schovaný nějaký čip na zpracování OpenGL, jehož práci musí v Qemu pracně suplovat procesor. Neříkám, že zrovna tohle a s těmito technologiemi je případ Androidu, pouze to uvádím jako možnost, jak může pomalejší specializovaná platforma zvítězit výkonem nad obecnou rychlou.
Koneckoncu, Dalvik je POUHA aplikace, jako jakakoli jina virtualni masina, a tedy nevidim duvod, proc by melo byt jeji portovani zrovna na x86 obtizne :)Já ten důvod také nevidím, a právě proto nechápu, proč se tak tvrdošíjně bráníte vyzkoušet Dalvik a nějakou omáčku okolo (emulátor z SDK), a místo toho neustále trváte na testování portovaného jádra, knihoven a celého systému (port celého systému Android). Neboli místo spuštění Dalviku nad Linuxem pořád spouštíte Dalvik nad portem Linuxu na mobilní procesory portovaným znova zpět na x86.
Jina vec je ovsem ta, ze jde opet jen o dalsi formu JITu javovskeho, byt transformovaneho, classfile, takze puvodce neefektivity muze nevidet jen clovek, co zil poslednich 15 let v jinem, paralelnim vesmiru...S rychlostí toho JIT nikdo problém nemá. Problém máte jen vy, když spouštíte ten JIT na jakémsi pochybném portu portu Linuxu. Nepřikloním se k vašemu způsobu uvažování a nebudu tvrdit, že je to chyba Linuxu, naopak mi z toho celkem jasně vychází, že je to chyba toho portu.
16.3.2011 16:01
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
snad se mi konecne splni sen a nekdo ze zastancu platformy Java mi osobne vysvetli, v cem tkvi jeji prinosPro vás v ničem.
snad se mi konecne splni sen a nekdo ze zastancu platformy Java mi osobne vysvetli, v cem tkvi jeji prinos :)
Její přínos je například v tom, že díky ní (a na ní navázané nepřeberné množství "nju technolodži" bullshitu) najde i takový exemplář "programátora", který sedí o kancelář vedle práci a nemusíš ho živit ze svejch daní...
16.3.2011 17:00
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Na telefónoch to chodí super, tam už sa ale neprekladá Java, ale beží bajtkód na virtuálnej mašine. Celá tá zbitočná hádka vznikla len o malicherné doťahovanie sa o rýchlosť a zabila diskusiu k článku. Čo asi vysvetluje pohľad od asembleristu
V asmeblery+C som pred veľa rokmi spravil prehrávač wav súborov, výkon vtedajších strojov ani nedovoloval iné riešenie. Java je multiplaformná, asembler nie. Poďalšie ako som písal, mne to androidie SDK ide výborne, v telefóne mi aplikácie makajú super, vo virtuále mi ide Android tiež výborne, tak úplne to na prd nemôže byť. Pre rýchly vývoj treba moderné jazyky, neviem si predstaviť vyvíjať programy pre mobilné telefóny v Asemblery. Osobne by som ale bor radšej keby to makalo pod C++ a QT, kvôli tomu ešte plánujem kúpu N900 na hranie
Ja se bavim o pouzivani androidu (na x86, protoze tuto platformu povazuji za majoritni)Android pro x86 v současné době v produkční verzi neexistuje. Mimochodem, v mobilních telefonech x86 majoritní není ani náhodou.
Pokud je ve vyvojovem emulatoru Dalvik x86-nativni, a bezi uspokojive, pak se ptam, jak je mozne, ze tentyz x86-nativni Dalvik v x86 portu bezi takto katastrofalne neuspokojive.Jak jste přišel na to, že jste spouštěl tentýž x86-nativni Dalvik? Podle toho, co jste tady psal, jste spouštěl bůhvíco na bůhvíčem v Qemu. S Androidem to asi mnoho společného nemělo – například androidí zařízení nepoužívají myš, tudíž nemají ukazatel myši. Vy jste ale psal o pomalém překreslování kurzoru myši – takže bůhví, co jste měl spuštěné.
Vase argumentace je tedy bud spatne, nebo uplne spatneMoje argumenty jsou možná nepřesné, ale ty vaše jsou totálně mimo – pokoušíte se argumentovat nějakou subjektivní rychlostí či pomalostí, přitom jste Android ještě ani jednou nespustil.
Budou spokojenejsi jak oni, tak zakaznik.Pokud je zákazník zaopatřovací ústav pro x86 assembleristy, pak ano. Pokud chce získat určitý výsledek za co nejnižší cenu, pak spokojen nebude – je mu k ničemu, že za milion Kč mu aplikace poběží o 1 % rychleji, když větší zrychlení může získat nákupem paměti za dva tisíce.
A ja se ptam, jak je mozne, ze vsechny pokusy o port na x86 dopadaji tak tragickyZ vašeho jednoho pokusu je myslím trochu brzo dělat závěr o všech. Každopádně to, jak dopadají nějaké pokusy o port, nevypovídá o platformě nic. Když nešikovný soused při pokusu o opravu totálně zničí Porsche, asi taky hned nebudete tvrdit, že Porsche jsou hrozná auta.
kdyz jedina vec, co se skutecne portuje (rozumej, jeji ceckovy source po nezbytnych upravach prejede jinak targetovanym cross-gcc) , je POUHA VM.A celý ten systém okolo se portuje sám od sebe, jako že odejdete na oběd, a když se vrátíte, najdete to naportované, nebo jak si to představujete?
Jednomu by uz skoro doslo, ze spolecny jemnovatel problemu je efektivni vykonavani javovskeho bytecode.Společný jmenovatel problému je, že jste ještě nezjistil, co znamená platforma Android, a nejspíš jste ještě žádnou Dalvik VM neměl spuštěnu.
Jak dlouho jeste bude moderni vyhazovat vykon (dnes celkem solidni) HW panubohu do oken? A z jakeho duvodu, proc vubec?Už navždy. Protože se většina zadavatelů chová ekonomicky, a když můžou něco vyřešit zaměstnáním dalších drahých programátorů a prodloužením projektu na straně jedné, nebo nákupem levného HW na straně druhé, zvolí si výhodnější druhou variantu. Paradoxně to pak může vést i k menší „spotřebě“ výkonu – přebytek HW výkonu umožňuje používat virtualizaci (z té se vám taky musí zvedat žaludek, takové plýtvání výkonem), která pak umožní seskládat na jeden hardware různou zátěž s odlišnými špičkami, takže pak nepotřebujete rezervu na špičkový výkon pro každou aplikaci zvlášť, ale můžete tu rezervu sdílet pro více aplikací.
No a ten Linux pod tim je vyvijen pro x86 primarne, tj. zadny port netreba.Jenže tam právě není vanilkové jádro, ale upravené a portované jádro a spousta dalších programů. Podívejte se na architekturu Androidu. Vy pořád píšete jenom o tom žlutém obdélníčku, ale portovat se musí celý červený, zelený a žlutý rámeček + něco z aplikačního frameworku. Přičemž třeba správa napájení je v Androidu řešena úplně jinak, než ve vanilkovém jádru. Kdyby nic jiného, je toho docela dost, takže portace bude nějakou dobu trvat. A hlavně je k tomu potřeba mít nějaký důvod – a zatím jediný důvod byl „schválně, jestli půjde Android spustit i na x86 PC“. Snad uznáte, že to moc silný důvod není, takže se té portaci asi nikdo moc nevěnoval. Teď s nástupem tablet PC se situace změnila, pokud někdo chce dělat tablety s Androidem na x86, bude ten port muset udělat. Teprve teď k tomu někdo má dobrý důvod. A i tak je otázka, zda takový port půjde spustit na běžném PC, nebo zda bude svázán s omezenou množinou HW, která se bude v tablet PC používat.
Pokud jde o port, tak "spodek" nabiha svizne, problem nastane jakmile nastartuje dalvik.Nevěřte všemu, co vám někdo vyprávěl. Opravdu je velmi jednoduché si to vyzkoušet, v obchodu s mobily určitě na nějaký s Androidem narazíte.
kolik ze je rozliseni zminovanych handheldu dnes a barevna hloubka? rekneme ne vic nez 256x512 64k ...800x480 a 16M? A to přišlo dotyčné zařízení na trh asi před rokem.
Jak moc je to špatně s dovolením přenechám ostatním diskutujícím, jen jsem v tomhle případě chtěl upřesnit současný stav věcí.
16.3.2011 19:00
pavlix | skóre: 54
| blog: pavlix
S dovolenim Vasi diskuzi ukazi zitra studentum, jako ukazku toho, kterak se katastrofalne ztraci jakekoli povedomi o strojove urovni fungovani HW.Na vašem místě bych ji studentům neukazoval, nebo ztratíte poslední zbytky autority, jestli ještě nějakou vůbec máte.
Jmenujete systemy, ktere jsou samostatne - narozdil od Androida, coz je jen spoustitko javovskych nesmyslu na mirne osekanem Linuxu. Tedy tak trosku nebe a dudy.iOS má v základu Darwin. Je to afaik podobný vztah jako Android a Linux.
16.3.2011 17:25
mkoubik | skóre: 5
| blog: lorem_ipsum
| Praha 8 - Bohnice
Chci system nativne provozovat na nejrozsirenejsi hardwarove platforme - chci tak mnoho?Průzkum jsem nedělal, ale myslím, že když sečtete všechny desktopy, servery, telefony, tablety, embedded zařízení, síťové prvky atd. Tak bude suveréně nejrozšířenější platformou právě ARM. To, že chcete mobilní OS provozovat na platformě, která je jakousi náhodou nejrozšířenější na desktopech a jinou náhodou je zoufale neefektivní - to už je váš problém.
Java je kvuli tomu znacne nepopularni.Zejména mezi uživateli, kteří Javu nikdy nespustili, nebo ji používají a neví o tom. Všechny ty vaše řeči o problémech s Dalvikem a s jeho výkonností poněkud kazí fakt, že jste v životě neběžel aplikaci běžící na Androidu. Z toho je bohužel evidentní, že jediný váš skutečný argument je „nemám rád Javu“. No tak nemějte, svět se kvůli tomu nezboří. Zůstaňte si u svého x86 assembleru, nemluvte do věcí, kterým nerozumíte, a všechno bude fajn.
16.3.2011 19:16
mkoubik | skóre: 5
| blog: lorem_ipsum
| Praha 8 - Bohnice
ale proc ho za to trestame tim, ze musi lopotne jitovat transformovanou javu?Protože kdyby Google vývojářům mobilních aplikací řekl ať je píší v Céčku nebo assembleru, tak by se android nikdy nerozšíril - o bezpečnosti ani nemluvě, nějaká abstraktní vrstva (bytecode v sandboxu) je prostě potřeba z praktických důvodů. Navíc mi nešlo o konkrétní vlastnosti architektur, ale o to, že jestli chcete provozovat android na nejrozšířenější platformě tak stačí navštívit nejbližší obchod s telefony.
17.3.2011 19:40
pavlix | skóre: 54
| blog: pavlix
Napsat "muj nazor neni reelvantni" by bylo kratsi, ve vasem pripade :P.Napsat "máte pravdu", by bylo kratší ve vašem :).
V prvom rade je dôležité opýtať sa, či dochádza kvôli Jave k nejakému úbytku výkonu a či je ten úbytok dosť veľký na to, aby malo zmysel sa ním zaoberať.
Androidové telefóny rozhodne problém s výkonom nemajú a nepotrebujú výkonnejší HW oproti iOS alebo WP7 telefónom. Nechápem čo riešiš.
(A poznámkou o nasaditeľnosti jedného z najrozšírenejších jazykov zo seba len robíš o niečo väčšieho blbca než doteraz)
23.3.2011 00:48
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
23.3.2011 10:26
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
23.3.2011 21:35
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
23.3.2011 23:42
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Python (a několik dalších jazyků) lze částečně použít přes Android Scripting Environment (ASE) (http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html, http://code.google.com/p/android-scripting/). ASE je ale určeno jen ke skriptování, s tím, že Pythonu zprostědkovává přístup k podmnožině API.
Jython použít nelze. U JVM jazyků vzniká problém v případě, že daný jazyk generuje bytecode za běhu (to tuším právě Jython dělá). Java bytecode se do dalvikovského konvertuje při vývoji. Pro použití takového jazyka by tedy bylo nutné, aby generoval přímo Dalvik bytecode.
16.3.2011 21:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
A s novymi verziami vyzera byt vyvoj cim dalej tym zaujimavejsi. Napr. "you can now build an entire Android application without writing a single line of Java".
Mozno trocha zamrzi, ze podpora pre vyssie spominane je az od Androidu 2.3. Na druhu stranu pre starsie verzie sa da pouzit port sdl.
22.3.2011 09:06
Ravensun | skóre: 11
| blog: Ravensun's blog
| Praha
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.