- Alsó-középkategóriás, PlayStation 5-be is helyezhető M.2 SSD-t virított a Klevv
- Antec kirakatház Lian Li zöngével és egy csavarral
- Újabb inteles VGA került elő a Biostar hátizsákjából
- Belépőszintű játékos headsetekkel bővült a Corsair kínálata
- Kétféle tájolással munkára fogható, ITX-es ház jött a Sharkoontól
- Melyik tápegységet vegyem?
- Fejhallgató erősítő és DAC topik
- Milyen CPU léghűtést vegyek?
- OLED TV topic
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Kétféle tájolással munkára fogható, ITX-es ház jött a Sharkoontól
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- Milyen billentyűzetet vegyek?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Steam Deck
Hirdetés
-
A TikTok Lite is igen káros lehet a gyerekekre
it 24 órát adott az EU a ByteDance-nek, hogy kockázatelemzést adjon ki a TikTok Lite kapcsán, mert az is káros lehet a gyerekekre.
-
Motorola Edge 50 Pro - több Moto-erő kéne bele
ma Érdekes egyveleg a középső Edge 50: a jó tulajdonságai közé becsúszott pár rossz, de vannak szerethető, egyedi megoldásai is.
-
Újabb inteles VGA került elő a Biostar hátizsákjából
ph Ezúttal egy 6 GB-os, helytakarékos modell lépett a színpadra.
Új hozzászólás Aktív témák
-
#2
elfelejtette
veterán
elfelejtette
veterán
Gőzerővel optimalizálhatnának olyan tekintetben is, hogy a 16GB RAM ne vonzó legyen, hanem röhejes...
"Nagyon jó dolog fontosnak lenni, de még fontosabb dolog jónak lenni."
-
#3
thiclyoon
aktív tag
elfelejtette
#2
thiclyoon
aktív 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).
-
prolad
őstag
-
thiclyoon
aktív tag
pontosan, végre valaki aki egyetért velem
#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ű ScreentMi 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 ]
-
no1r
őstag
é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 - https://www.instagram.com/nimrodnyul/
-
prolad
őstag
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. -
thiclyoon
aktív tag
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
ma már iOS-re fejlesztek csak)[ Szerkesztve ]
-
Wesiz
tag
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!
-
thiclyoon
aktív tag
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 boldogBonyolultabb 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 egyScreent. 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
-
#21
aelod
veterán
elfelejtette
#2
aelod
veterán
Új hozzászólás Aktív témák
ma Az Android 12.1 a Pixel Folddal együtt debütálhat, és egyre több a kézzelfogható információ.
- iPhone XS 64GB eladó
- BONTATLAN Új Iphone 15 és 15 Plus 128-512GB 1év APPLE garancia gyári független Deák AZONNAL Átvehető
- iPhone 15 Pro Max 256gb Fekete Titanium, bontatlan
- Eladó iPhone 7 Plus 256 GB Jet Black 100% akku, szép állapotú - 12 HÓ GARANCIA - R8039
- Samsung Galaxy S23Ultra 8/256 független 2026.08.31-ig arancia