Hirdetés

Aktív témák

  • DarkByte

    addikt

    válasz Karma #277 üzenetére

    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

Aktív témák