Hirdetés

Hozzászólok Aktív témák

  • prolad

    őstag

    Helyes, itt az ideje hogy rendszerinten támogassák és ne a gyártókta legyen bízva. Már csak az kell, hogy az alkalmazásfejlesztők is összekapják magukat. Hosszútávon jót fog tenni a tableteknek is.

  • elfelejtette

    veterán

    Gőzerővel optimalizálhatnának olyan tekintetben is, hogy a 16GB RAM ne vonzó legyen, hanem röhejes... :(((

    "Mint a leszakított haldokló virág, mint az ötmillió magyar, akit nem hall a nagyvilág" Ismerős Arcok - Nélküled ### Redmi 3s

  • stateman

    tag

    válasz elfelejtette #2 üzenetére

    Amíg az android VM-en fut (értsd: kb. örökké), addig ilyen lesz. + #1: a fejlesztő optimalizálhat, viszont ha rendszerszinten vannak rossz (nem hatékony / nem megfelelő) megoldások, akkor nem lesz szép az eredmény szinte sosem. Change my mind, de a natív fejlesztés híve vagyok (natít itt != "natív android", hanem natív == nem virtuális gépeken való futtatás, hanem natív kódra leforduló kód futtatása).

    "There are two rules for success: 1. Never tell everything you know." - Roger H. Lincoln

  • no1r

    őstag

    válasz stateman #3 üzenetére

    ez a legnagyobb rákfenéje az egész rendszernek. a VM.
    ezt csak igazán alapos memory handling processekkel és optimalizációval lehetne javítani valamelyest.

    a gúny a győztesek kiváltsága

  • moleculez

    veterán

    válasz no1r #4 üzenetére

    Ennyire nem ismerem a rendszereket, az iOS az natívan fut, vagy az is VM?

    A világ minden problémája az oktatás hiányára, vagy minőségére vezethető vissza.

  • no1r

    őstag

    válasz moleculez #5 üzenetére

    én úgy tudom az nem VM. de nem vagyok 100% biztos

    a gúny a győztesek kiváltsága

  • prolad

    őstag

    válasz stateman #3 üzenetére

    Oké, de attól még meg lehetne oldani, hogy pl az app kezelje a 2 kijelzőt egy telefonon belül és tudja, hogy az egyiknél így rendezze a dolgokat, a másiknál úgy. Vagy hogy X pixelnél szélesebb képernyőn legyen tabletes elrendezés (már ha az appnak van ilyen verziója).

  • stateman

    tag

    válasz no1r #4 üzenetére

    pontosan, végre valaki aki egyetért velem :D

    #5: iOS-es appok nem VM-ben, de sandbox-ban futnak. Androidon meg VM-ben és sandbox-ban, utóbbit szokták összekeverni a VM-mel

    #7: TL;DR: meg lehetne oldani, igen, programozással kapcsolatos dolgokra is igaz, hogy "minden megoldható, csak legyen pénz és idő."
    Kicsit hosszabban: az a helyzet, hogy a VM téma ennél sokkal mélyebb a dolog (én se értek mindent, sőt), és ezzel együtt sokkal "felszínközelibb" részeket is érint az Android (vagy bármelyik rendszer) architektúrája. Mondok egy konkrét példát, ami jól szemlélteti a problémát: adott egy use-case, a telefon elforgatása. Egyszerű, könnyen implementálható rész, a fejlesztőnek ezzel nem kell (nem kéne) foglalkoznia, hiszen az OS dönti el, hogy mikor forduljon el, OS szinten tiltható a funkció, stb. Nézzük meg, melyik platformon hogyan implementálták, ehhez nevezzünk egy képernyőnyi tartalmat Screen-nek (konkrétan ha valakit érdekel, iOS-en ez pl. a UIViewController, vagy újabban View, Androidon meg a nem-compose időkben Activity, de ezt a részletet most fedjük el a Screen névvel):
    - Android: az OS eldönti, hogy forgatni kell a Screen-t, ekkor a Screent megsemmisíti, és létrehozza ugyanazzal a tartalommal, immár elfordított helyzetben
    - iOS: az OS eldönti, hogy forgatni kell a Screen-t, ekkor a Screen kap egy jelzést viewWillAppear néven (egyszerűen fogalmazva persze), amire kirendereli a tartalmát elforgatva (meg animálva). A modell nem semmisül meg, nem kell drága erőforrással újra létrehozni egy komplex felépítésű Screent

    Mi lett az eredménye ennek az eltérésnek?
    - Androidon még az újabb eszközökön is (de a középkategóriásoknál biztosan, és hiába már-már alig észrevehető, a forgatás előtt mindig van egy kis delay, és persze minél erősebb a CPU, annál inkább erőből megoldja). Ez egy régi kód, amit nem tudtak kivenni a kódbázisból, mivel olyan sokan használják, hogy nem tudnak breaking change-t tenni a source kódba (olyan változtatást, mely eltöri a régi appok működését). Úgyhogy maradt ez a működés. A mostani Compose-t már nem ismerem, ez egy új layout rendszer, lehet, hogy ez már javít a helyzeten, de meglepődnék, ha kigyalulták volna az egész problémát
    - iOS-en meg vígan forog a képernyő oda, ahova akarod. A fentiek következménye, hogy egy Screent akár fokonként is lehet(ne) forgatni, nem kell folyton törölni - létrehozni a modellt, ami felesleges erőforráspazarlás

    + infó: iOS-ben is vannak rossz, elavult, nem hatékony megoldások, hiszen ott is emberek dolgoznak. Sőt, mivel nem open source, így szerintem több hiba is van benne. Viszont ha találnak egy hibát, akkor azt egyből ki tudják javítani úgy, hogy kívülről nézve nem változik semmi (ezt megtehetnék Android oldalról is, csak sok változtatás publikus apikat is érinthet, ami ilyenkor iOS-en mondjuk deprecated lesz). És még egy: iOS-en nem félnek publikus apit módosítani. Konkrét példa ismét: a DatePicker komponens (az a jól ismert kerék, amiről dátumot választhatsz) iOS 13 előtt keréknek nézett ki, és nem volt más opció. Viszont 13.4-től és 14.0-től újabb részek jöttek be, és default módon nem keréknek nézett ki, amivel így eltörtek a képernyők, komponensek, UI-ok. Emiatt ki kellett javítani ezeket a régi appokban is, és pl. a gmail jópár hónapig bugos volt, és nem lehetett időzített emailt küldeni, mert a UI szétesett a fenti miatt. Egyik se jobb rendszer, mint a másik, tanulni kell a másiktól, és fejlődni :)

    [ Szerkesztve ]

    "There are two rules for success: 1. Never tell everything you know." - Roger H. Lincoln

  • no1r

    őstag

    válasz stateman #8 üzenetére

    és az ilyen architekturális kérdéseken túl még idejön a nagyon különböző memóriafelhasználási logika is a két rendszer között.
    már régen foglalkoztam a témával, de ha jól emlékszem akkor iOS-en úgy működött a memóriakezelés, hogy nem volt valódi multitasking, az appot amit a háttérbe raktál (nyilván alapvető rendszerfolyamatoktól meg rendszerközeli appoktól eltekintve) azt "lefagyasztotta" és felszabadította az arra lefoglalt memóriát. Aztán amikor a felhasználó visszaváltott, akkor az app ismét megkapta a szükséges memóriát (elvéve mástól) és kijött a hibernált állapotból.
    Bár lehet, hogy a Windows Phone memóriakezelésével keverem (vagy mindkettő hasonló elven működött?).
    ezért (is) volt az, hogy gördülékenyebbnek tűnő rendszert kaptál egy olyan készülékben, amiben kevesebb volt a RAM.

    ezzel szemben az Android Dalvik (?) cache és memóriakezelése pont a fordítottja. a valódi multitasking reményében minél több rendelkezésre álló memóriát igyekszik felhasználni és az ún. garbage collection metódussal optimalizálni annak működését. azonban ez azt eredményezi, hogy a rendszernek folyamatosan monitorozni kell a háttérben futó appok memóriafelhasználását és az erőforrásokat úgy alakítani, hogy a prioritásoknak megfelelően a folyamatok (és appok) állandóan futni tudjanak amikor szükséges.
    ergo mondhatni akármennyi RAM-al is képes lesz idővel belassulni, ha a rendszer nem jól osztja ki az erőforrásokat.
    nyilván ennél sokkal mélyebb ez a téma is, csak most igy (este 11kor) ennyire futotta. meg hát azért én sem vagyok túl profi a témában. :)

    a gúny a győztesek kiváltsága

  • prolad

    őstag

    válasz no1r #9 üzenetére

    Nem úgy volt, hogy a Dalvikot Andorid 5/L-nél kivezették? Onnantól kezdtek el tényleg gyorsak éa fluidak lenni a telefonok még egy IOS/Windows Phone rendszerű telefon mellett is.
    A RAM kérdést meg komplikálja, hogy hiába raknak bele sok giga RAM-ot, ha a gyártó nem engedi ezt mind kihasználni és a szoftver X idő után szép lassan kilövi az appokat. Hiába van nálam is 12 GB RAM, 6.5 felett nem láttam még egyszer sem a használatot. Mondjuk annyi haszna lett a dolognak, hogy 50 ezer alatr is kapsz 4GB RAMos telefont, ami elég majdnem mindenre.

  • stateman

    tag

    válasz no1r #9 üzenetére

    Ahogy írod, pontosan!

    Emiatt teszteltem le nem olyan régen, hogy mennyit foglal egy háttérben “futó” app. Nagyságrendileg a rendes RAM használat harmada jött ki dev környezetben, ami release esetén leeshet mondjuk az eredeti ötödére-tizedére. Ezzel összefügg, hogy a háttérben csak nagyon korlátozott use case-ek futhatnak, pl. lokáció (ami engedélyköteles pl.), vagy zene. A többi erőforrást elveszi az OS az apptól.

    Az Androidot is jól írod kb., annyi, hogy a Dalviknak ehhez nincs köze igazából, a GC (garbage collection) pedig egy memóriafelszabadító módszer, szóval ez inkább amiatt fontos, hogy egy app által hátrahagyott memória mikor lesz újra használható. Egy baj van vele, hogy ilyen környezetben nem optimális :) a futását úgy kell elképzelni, hogy néha lefut (mondjuk x ms-onként), viszont amíg fut, addig az appnak egy helyben kell állnia (tehát ez egy runtime feature, azaz futási időben számol és számol). Vagyis addig nem tud mit csinálni. Persze, megintcsak ha bika a CPU, akkor izomból letolja a feladatot, csakhogy jövőre már nagyobb appok jönnek, több RAM-ot esznek, és kezdődik elölről. IOS-en is van ez a memóriafelszabadítás természetesen, viszont itt a referenciaszámlálást használják (ARC). Ez minimálisan több figyelmet vár el a programozótól, cserébe nincs runtime overheadje, mert fordítási időben csinálja meg a dolgát. Innen azt hiszem látható az előnye, hiszen futás közben nem kell számoljon, és az app nem kell “megálljon.”

    prolad: de, ahogy írod, és jött helyette az ART, és vele együtt az ahead-of-time fordítás, ami nagyon sokat spórolt a telefonok erőforrásából. Ettől függetlenül az ART mint “közvetítő réteg” megmaradt (vagyis bejött a Dalvik helyére), úgyhogy egyértelműen javult a helyzet, de ez azért az iOS-en megszokott (tényleg) natív kódtól odébb van.

    (Ha rosszul írtam valamit, bocsi, Android guruk javítsanak nyugodtan :D ma már iOS-re fejlesztek csak)

    [ Szerkesztve ]

    "There are two rules for success: 1. Never tell everything you know." - Roger H. Lincoln

  • no1r

    őstag

    igazatok van, utána rákerestem és valóban nincs már Dalvik, csak már nem volt türelmem javítani a posztot :R
    (ebből is látszik, hogy mennyire régen foglalkoztam a témával utoljára :D )

    [ Szerkesztve ]

    a gúny a győztesek kiváltsága

  • sokomst

    tag

    Kíváncsi leszek mekkora fellángolás lesz ez a hajlítható, két kijelzős konstrukció. Mindenesetre, ha rendszer szinten kerülnek bele ilyesmik abból valószínűleg a tabletek is nyerhetnek ami annak a piacnak nagyon nem ártana.

  • no1r

    őstag

    engem inkább a Fold / Moto Razr féle megoldás érdekelne, ha jobban elterjedne és nem kerülne 400ezerbe :D

    [ Szerkesztve ]

    a gúny a győztesek kiváltsága

  • sokomst

    tag

    válasz no1r #14 üzenetére

    Hát ezek a fejlesztések pont az elterjedést segítik mivel jobban kihasználhatóvá válnak, ezáltal keresettebbé ami szépen majd viheti le az árakat pár év múlva. Kérdés, hogy csak lufi ez az egész hajlítható technológia hullám.

  • Wesiz

    csendes újonc

    válasz stateman #8 üzenetére

    nagyon köszönöm ezt a kommentet, végre megértettem (nagyjából) hogy miért van az amit eddig csak tapasztalat alapján "tudtam" miszerint hogy egy iphone még ha régi és "gyenge" hardverű, a képernyő elforgatása egy régi iphone-on is simább, fluidabb mint egy csúcs androidon.

    a kommentedből azt látom hogy nem várható hogy androidon ezt a "problémát" orvosolják, de én abszolút nem látom át, miért nem megoldható ez. egy új android főverzió frissítéssel se lehetne áttérni az ios féle képernyő elforgatásra? miért olyan lehetetlen feladat ez?

    köszi ha válaszolsz! :)

  • stateman

    tag

    válasz Wesiz #16 üzenetére

    Nem várható sajnos. Előzőleg említettem, hogy volt a "régi" Android layout rendszer (Activity, Fragment, .xml fájlok), és van az "új" rendszer (Compose). Erre nem adtam egyértelmű választ, de kiderítettem, hogy maga az Activity logika megmaradt a Compose "alatt" ("a motorháztető alatt nem történt sok változás"), ami azt eredményezi, hogy a képernyő elforgatás működése ugyanúgy megvan a fancy, újabb layout rendszerben is.

    Ez viszonylag rossz hír, hiszen iOS-re is kb. ezzel egyidőben jött ki az új layout rendszer (SwiftUI), amit ground-up építettek fel, tehát az régi dolgokat bár supportálják, de a SwiftUI nem arra épít. Persze erre több erőforrást allokált az Apple, a Google-nek viszont nem központi része az Android, nem tud és szerintem nem is akar annyit rászánni, mint amire az Apple hajlandó. Vissza Androidhoz: ez azért nem jó hír, mert így az a bizonyos kód, ami ezt a működést eredményezi, ugyanúgy ott van a rendszerben, ugyanúgy arra építenek, így nem kerül(t) ki a kódbázisból.

    Azért nem magától értetődő ezt a "hibát" javítani, mert igazából nem tipikus hiba, hanem a rendszer működésének sajátossága, úgymond arhictekturális örökség. Természetesen javítható az egész, ennek a legegyszerűbb megközelítése az, ami a legtöbb munkát igényli:
    - fel kell térképezni a publikus apikat, amiket érint ez a dolog (publikus api az az, amit a programozó elér, és tud használni). Ha ezek változnak egy új Android verzióban, törik az egész app, crash-ek lesznek, ami természetesen nem kívánatos
    - ez a publikus api halmaz óriási kódmennyiséget jelenthet, hiszen ez egy core funkció, amire nagyon sok dolog épül
    - a publikus apit meg kell hagyni, és a benne lévő implementációt ki kell cserélni (kb. "meghagyjuk az autó külsejét, így a színe nem változik, de beleteszünk egy teljesen másik motort, váltót stb."). Ez óriási meló, és nagyon-nagyon nem triviális. Ezen belül először ki kell találni egy jó (jobb) architektúrát, amivel nincs ez a képernyő megsemmisítés és újra létrehozás. Ez nem olyan vészes, mivel ha egy az egyben lemásolják az iOS felépítését, akkor sokat nem hibázhatnak itt. A második része maga a kódolás, ami az egész projekt legnehezebb része: megfelelni egy publikus apinak úgy, hogy belül módosíthatsz ugyan bármit, de nagyon meg van kötve a kezed, azt nagyon nehéz megcsinálni, ha csak nem lehetetlen*.
    - release, és mindenki boldog :)

    Bonyolultabb megoldás, ami pedig összességében kevesebb szenvedést igényel, de kompatibilitási gondok lehetnek, egyéb dolgok merülhetnek fel:
    - a Compose-t ground-up felépíteni, Activity örökség nélkül. Ez sok munka, de nem annyira szenvedős, mint egy régi kódot turkálni.
    Sajnos a Google nem így csinálta már mikor kitalálta a Compose-t, úgyhogy az 99%, hogy ezt az utat nem akarja járni a Google. Marad az első, ha egyszer lesz valakinek elég ideje és türelme hozzá.

    *: nagyon leegyszerűsítve: tegyük fel, hogy van egy olyan függvény a mostani kódban, hogy rotateScreen() -> Screen, aminek az a jelentése, hogy "forgasd el a képernyőt, és add vissza az újonnan létrehozott képernyőt, hiszen a régit megsemmisítetted." Na most az új architektúra szerint ennek nincs értelme, pedig magának a függvény "fejlécének" meg kell maradnia, tehát ugyanúgy vissza kell adnia egy Screent. Mi az, hogy új képernyő? Hiszen az új rendszerben nem is lenne megsemmisítés. Ez csak egy nagyon leegyszerűsített, nem valós példa, az érthetőség miatt írtam le.

    Ahogy írtam, minden megoldható, csak idő és pénz függvénye, de itt van egy elég szoros kényszer: meg kell hagyni a publikus apikat, és csak a belsejét lehet módosítani. Emiatt egymásra hatások (dependenciák / függőségek) alakulnak ki, és olyan nagy a kódbázis, hogy ember legyen a talpán, aki megpróbálja ezt az egészet. Marad az a másodpercnek is törtrésznyi ideje delaynek elforgatáskor, és bízunk benne, hogy az újabb, egyre bikább CPU-k erőből elintézik :)

    "There are two rules for success: 1. Never tell everything you know." - Roger H. Lincoln

  • moleculez

    veterán

    válasz Wesiz #16 üzenetére

    Nagyjából olyasmi mint lecserélni a terítőt egy megterített asztalon.

    A világ minden problémája az oktatás hiányára, vagy minőségére vezethető vissza.

  • stateman

    tag

    válasz moleculez #18 üzenetére

    Minek írtam ennyit :D teljesen érthető, és szerintem jó példa

    "There are two rules for success: 1. Never tell everything you know." - Roger H. Lincoln

Hozzászólok Aktív témák

Hirdetés