- Apple iPhone SE (3. generáció) - szélsebes múltidézés
- iPhone topik
- MIUI / HyperOS topik
- Ilyen lehet a Samsung Galaxy Watch7 Ultra
- Bivalyerős lett a Poco F6 és F6 Pro
- Mobil flották
- Samsung Galaxy S23 Ultra - non plus ultra
- Megérkezett a Google Pixel 7 és 7 Pro
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- Ezek a OnePlus 12 és 12R európai árai
Hirdetés
-
Közönségkedvenc Galaxy vált One UI 6.1-re
ma Ezen a héten sem tétlenkedett a Samsung szoftverfejlesztő csapata.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Olcsó és visszafogottan elegáns kompakt AIO jön az ID-Cooling berkeiből
ph Az előzetes tesztek alapján korrektül teljesítő modellnek nem kenyere a cicoma, és akár titkos favorit is válhat belőle a kategóriájában.
-
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.
- Azonnali informatikai kérdések órája
- Apple iPhone SE (3. generáció) - szélsebes múltidézés
- Renault, Dacia topik
- Xiaomi Pad 6 - kiapadhatatlan jóság
- Kerékpárosok, bringások ide!
- iPhone topik
- Kínai, és egyéb olcsó órák topikja
- Diablo IV
- Samus: Könnyűfém felni festése
- MIUI / HyperOS topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen