- Milyen monitort vegyek?
- Sony MILC fényképezőgépcsalád
- TCL LCD és LED TV-k
- OLED TV topic
- Canon EOS DSLR topic
- Hogy is néznek ki a gépeink?
- Milyen asztali médialejátszót?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Visszafogott méretű, duplatornyos léghűtés a Thermaright receptje szerint
Hirdetés
-
Harold Halibut teszt
gp Tíz éven át készült bábfilm elevenedik meg a képernyőkön – egy bábfilm, egy leegyszerűsített kalandjáték, és mindenek felett egy mese a boldogság kereséséről.
-
Alig több, mint 100 ezer lett a Vivo V40 SE
ma A bemutató egy hónapja volt, árat akkor nem közöltek, most már viszont megvásárolható a készülék, egyelőre német nyelvterületen.
-
Kockáztatnak a bankok, ha AI-t használnak
it Felhívták a bankok figyelmét, hogy kockázatokra számíthatnak, ha AI-t és gépi tanulást kezdenek használni.
Új hozzászólás 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...
"Nagyon jó dolog fontosnak lenni, de még fontosabb dolog jónak lenni."
-
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 ]
-
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
(ebből is látszik, hogy mennyire régen foglalkoztam a témával utoljára )[ Szerkesztve ]
a gúny a győztesek kiváltsága - https://www.instagram.com/nimrodnyul/
-
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
[ Szerkesztve ]
a gúny a győztesek kiváltsága - https://www.instagram.com/nimrodnyul/
-
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 egyScreen
t. 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
-
Wesiz
tag
köszi szépen mindkettőtöknek!
-
aelod
veterán
Új hozzászólás Aktív témák
- Politika
- Redmi Note 9 Pro [joyeuse]
- BestBuy topik
- Milyen monitort vegyek?
- DIGI internet
- Feltörték a PROHARDVER!-es regisztrációmat! (vagy elvesztettem a belépési emailcímemet)
- Sony MILC fényképezőgépcsalád
- Tarr Kft. kábeltv, internet, telefon
- Autós topik
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- További aktív témák...
- Motorola Edge 40 8/256gb - Újszerű, akár beszámítással
- Xiaomi Poco X5 Pro 8/256gb - Újszerű akár beszámítással
- Apple iPhone 12 Pro 128gb Gold - Karcos, kis hiba, akku 85%, Yettel függő, akár beszámítással
- Új Motorola Edge 50 Pro 512/12GB Black 3év Garancia!
- Samsung Galaxy S23Ultra 8/256 független 3 év Samsung gyári garancia
- Samsung S21 Ultra (12/256GB) + Samsung Watch CSERE is Samsung S22 Ultra, S23 Ultra, Flip Z5-re!
- Xiaomi Redmi Note 13 Pro Plus 5G 12GB/512GB, garanciás, karcmentes, dobozos.
- (50+) KIEGÉSZÍTŐK, TARTOZÉKOK, ALKATRÉSZEK, Apple iPhone (5 - 8Plus), ÚJ!
- Teljesen új Xiaomi Redmi Note 12 Pro 5G 6/128GB DS (5G) Black eladó (bontatlan)
- XIAOMI REDMI NOTE 13 PRO 5G 8/256GB