Hirdetés

Keresés

Aktív témák

  • DarkByte
    addikt

    Ismet egy kalap ala vonod az asztali JVM-et a mobil kornyezettel. Harom nagy kulonbseg van ,es mindketto kritikus: 1) sokkal kevesebb RAM all rendelkezesre mobilon, ezt gondolom nem kell magyarazni; 2) asztalon az esetek nagy reszeben kulon JVM van Java alkalmazasonkent, aminek kovetkezteben egymast nem befolyasoljak (vo az Androidon egy VM-ben fut mindenki), valamint asztalon ott a swappeles lehetosege is; 3) asztalon a GC futasa fel se tunik ,mert eleg eros.

    Azert nem kell lebecsulni a G1 hardveret se, bar FPU nincs benne, 3D gyorsitas van. Az OpenGL ES hasznalja is. A baj nem is itt, hanem a tenyleges jateknal van - nem szabad se memoriat foglalni, se elengedni (nem szabad ingerelni a GC-t), ami azert nagyon durva poolingot es tervezest igenyel. Mas szoval felesleges szopast, csak es kizarolag a Java miatt.

    Szigorúan szvsz: 1) a programok nagy része SDK kód hívás amiből igen sok takar natív kód hívást, ezek a lib-ek pedig így is úgy is betöltődnek. Az alkalmazások külön memória igénye így szerintem relatíve kicsi (bár emulátoron ezt még nem néztem meg, csak tipp). Játékoknál maximum a sok adatfájl, textúra lehet a meghatározó, de ezekből az épp használatban lévőeket valószínűleg az OpenGL betölti a dedikált videó memóriába, ha van ilyen 2) Másolom az SDK -ból: "Each process has its own Java virtual machine (VM), so application code runs in isolation from the code of all other applications." [link] Pont ez a lényeg hogy mivel saját process -ben futnak, ki tudja használni a platform a Linux kernel folyamat izolációját (minden progi unique user ID -vel fut) és így nem kellett egy újabb biztonsági réteget betervezniük. 3) Szerintem ha egy progi jól van megírva akkor a GC relatíve ritkán fut, ha pedig memória szivárgás van (objektum referenciák bennragadtak) akkor már úgy is mindegy, előbb-utóbb úgy is elfogy a memória, előtte persze küzd egy jót a GC fokozatosan leölve az alkalmazást. :) Max. a játék folyamatosságát befolyásolja a GC, nem tudom hogyan van megoldva a Dalvik -ban, de tippre külön szálban, alacsony prioritással kerül rá sor x% threshold limit elérése után.

    Azért vonok párhuzamot az asztali JVM és az Android Dalvik JVM -je között, mert hasonló optimalizálási úton fog ez is végigmenni. Hotspot fordító ugyanígy nem volt az első JRE -kben. A Google -nak meg van az az előnye hogy tanulhat az asztali Java fejlesztéseiből és kapásból egy hatékony javítást tud rajta eszközölni.

    Mindezek ellenére tény hogy az Android -os Java jelenlegi állapotában nem nagy teljesítményű játékra termett, ezt a Google I/O -n is elmondta az egyik játéktervező aki egy platform játékot demonstrált első körben. De jön még kutyára teherautó :D

  • Karma
    félisten

    Ismet egy kalap ala vonod az asztali JVM-et a mobil kornyezettel. Harom nagy kulonbseg van ,es mindketto kritikus: 1) sokkal kevesebb RAM all rendelkezesre mobilon, ezt gondolom nem kell magyarazni; 2) asztalon az esetek nagy reszeben kulon JVM van Java alkalmazasonkent, aminek kovetkezteben egymast nem befolyasoljak (vo az Androidon egy VM-ben fut mindenki), valamint asztalon ott a swappeles lehetosege is; 3) asztalon a GC futasa fel se tunik ,mert eleg eros.

    Azert nem kell lebecsulni a G1 hardveret se, bar FPU nincs benne, 3D gyorsitas van. Az OpenGL ES hasznalja is. A baj nem is itt, hanem a tenyleges jateknal van - nem szabad se memoriat foglalni, se elengedni (nem szabad ingerelni a GC-t), ami azert nagyon durva poolingot es tervezest igenyel. Mas szoval felesleges szopast, csak es kizarolag a Java miatt.

    Az meg külön érdekes kérdés, hogy miért lesz a vessző-szóköz-ből mindig szóköz-vessző, ha nem figyelek oda, és tekerek vissza kijavítani... Ennyit a szövegbevitelről G1-en, pedig ez még csak nem is a virtuális billentyűzet volt. Lehet, hogy az Auto-Punctuate kavar be? :F

    Természetesen a "mindketto kritikus" valójában "mindhárom kritikus" akart volna lenni, csak utólag találtam ki a harmadikat :B

Aktív témák