- Több mint 500 millió dollárt spórolt az AI a Microsoftnak
- Ismét 128 és 256 GB-os memóriaszetteket villantott a G.Skill
- Panorámás miditorony jött a Chieftec fémjelzésével
- Ráfordult a célegyenesre a SiPearl első szerverprocesszora
- A partnerektől függ, hogy lesz-e Arc csúcs-VGA az aktuális generációban
Új hozzászólás Aktív témák
-
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
-
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)
-
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
-
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).
Új hozzászólás Aktív témák
Hirdetés
- Jogász topic
- Call of Duty: Warzone
- Milyen TV-t vegyek?
- Crypto Trade
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- A Windows 11 lett az úr az asztali PC-k piacán
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Formula-1
- Kerékpárosok, bringások ide!
- Lakáshitel, lakásvásárlás
- További aktív témák...
- iPhone 12 Pro Max 128GB Újszerű Független/1-3 hónap gar./Akku 86%/p4360
- iPhone 13 128GB Újszerű Független/1-3 hónap gar./Akku 100%/p4359
- iPhone 13 Mini 128GB Független Használt/1-3 hónap gar./Akku 84%/p4357
- iPhone SE2 64GB fekete, gyönyörű újszerű állapotban, 3db van, 85% 92% és 100% akkuval
- iPhone SE2 64GB 82% piros, saját dobozzal
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi Redmi Note 12s 256GB, Kártyafüggetlen, 1 Év Garanciával
- 135 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090 (ELKELT)
- ASUS Radeon HD6950 DirectCU II 2GB 256bit GDDR5 EAH6950 DCII/2DI4S/2GD5 Videokártya eladó
- AKCIÓ! Apple MacBook PRO 15" 2018 i9 32GB 500GB 560X 4GB notebook garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest