Hirdetés
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Befutott a Redmi Note 14 alapverzió is
- Jelentős fejlődést mutat a Xiaomi Redmi Note 14 Pro széria
- Az éj sötét és tele van Xiaomi 14T-vel
- Samsung Galaxy S23 Ultra - non plus ultra
- iPhone topik
- Aranyáron jött Európába a Xiaomi Mix Flip
- VoLTE/VoWiFi
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S21 FE 5G - utóirat
Hirdetés
-
54000 tonna
lo Olvasom félálomban a cikket a fukusimai atomerőműről a Portfólión. 54e tonna így hirtelen nem mondd semmit, kéne valami...
-
X200-as szériáját mutogatja a Vivo
ma Három hét múlva, várhatóan három készülékkel érkezik a Vivo 3 nm-es családja.
-
Játékos TWS headsettel gyarapodott a SteelSeries kínálata
ph Az Arctis szériás újdonság számos platformon működésre bírható, és konzolok szintjén van a Microsoft gépeihez való verziója is a Sony-t favorizáló mellett.
-
Mobilarena
Új hozzászólás Aktív témák
-
pzoley
őstag
válasz dozsabalint #37567 üzenetére
Szia, nem vitaindítónak szánom, de mivel minden 2. hsz-ben a garbage collectort említed, és bizonygatod, hogy nincs memory leak, én ezt az 5.1-es forráskóddal tudom cáfolni. Rengeteg memory leak van a kódban, a legtöbb tipikusan egy rutinba belépéskor lefoglalja a memóriát egy string-nek vagy bármilyen más típusú változónak, majd kilépéskor elfelejti felszabadítani, vagy ha a rutin végén ott a felszabadítás, akkor előtte egy feltételt figyelve simán return-nal kilép, de ott előtte már nem szabadítja fel a memóriát. Tudom, hogy ez nem egy nagy méret, de sok kicsi sokra megy. Na az ilyen programozási hibák ellen is csinálták a garbage collectort, amit bár mennyire is javítanak, fejlesztik, nem fogja a problémát megoldani!
A memory leak 2 részből állhat:
1. Törölt, de nem használható memória /nincs felszabadítva/, ez ritkábban fordul elő mivel ha már törli általában fel is szabadítja
2. Nem használt memória, amire van még élő hivatkozás ezért nincs felszabadítva, és ez fordul elő a legtöbbször
Az első esetben még hasznos lehet a garbage collector, de a második esetben már semmit nem tud tenni, hiszen ha van rá hivatkozás, soha nem fogja felszabadítani a memóriát !
Arról már nem is beszélve, hogy a garbage collector futása alatt folyamatosan figyelnie kell az objektumokat, ami elég komoly számítási teljesítményt igényel, és ráadásul teljesen feleslegesen csinálja, hiszen minden objektumnak meg van az élettartama tehát valamikor úgy is törlődni fog.
De hogy egy konkrét példát is megemlítsek, a WindowManagerService.java-ban, amikor kilépsz egy alkalmazásból, és egyből váltasz egy másikra, vagy kikapcsolod a kijelzőt, akkor csak a véletlenen múlik, hogy a bezárt program utolsó képernyőképe bent ragad-e a memóriában vagy nem, ugyanis a setAppVisibility rutin végére "elfelejtették" beleírni a felszabadító rutint, így ha a rendszer akkor kezdené felszabadítani a kilépett program képernyő által lefoglalt területét, amikor a kijelző ki van kapcsolva, úgy ott hagyja az egészet mint kutya a sz@rát, és ezek már több 10MB-os helyfoglalások !!
Én eddig az 5.0.2-ben 25-30 olyan programozói hibát javítottam, ami csak figyelmetlenség, nem a tudás hiánya, így nálam még full telepítés esetén sem ment a system által lefoglalt memória 350 MB fölé. Az 5.1-ben ebből 6-ot javított a google
Az biztos, ha a cégnél én is így programoznék, úgy kirúgnának, hogy a lábam sem érné a földet[ Szerkesztve ]
Új hozzászólás Aktív témák
A telefonhoz nem szervesen kapcsolódó témákat, észrevételeket a Nexus off topikban lehet kitárgyalni.
- Path of Exile (ARPG)
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- PlayStation 5
- Ukrajnai háború
- Kezdő fotósok digitális fényképei
- Apple notebookok
- Milyen légkondit a lakásba?
- Otthoni hálózat és internet megosztás
- World of Tanks - MMO
- Befutott a Redmi Note 14 alapverzió is
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen