Ideaalne RAM-i hulk, mida telefonid sujuvaks multitegumtööks vajavad, on üsna vaieldav teema. Apple saab oma iPhone'ides hakkama väiksema suurusega, mis on sageli Androidi lahendustest paremini kasutatav. Samuti ei leia te iPhone'ist mingit RAM-i mäluhaldust, Androidil on selle jaoks aga oma spetsiaalne funktsioon.
Kui lähete näiteks Samsung Galaxy telefonidesse Seaded -> Seadme hooldus, leiate siit RAM-i indikaatori teabega, kui palju ruumi on vaba ja kui palju on hõivatud. Pärast menüül klõpsamist näete, kui palju mälu võtab iga rakendus, samuti on siin võimalus mälu tühjendada. Siin asub ka RAM Plus funktsioon. Selle tähendus on see, et see hammustab sisemälust teatud arvu GB, mida see virtuaalmälu jaoks kasutab. Kas suudate iOS-is midagi sellist ette kujutada?
Nutitelefonid toetuvad RAM-ile. See teenib neid operatsioonisüsteemi salvestamiseks, rakenduste käivitamiseks ja ka osa andmete salvestamiseks vahemällu ja puhvermällu. Seega tuleb RAM-i korraldada ja hallata nii, et rakendused saaksid tõrgeteta töötada, isegi kui need taustale visata ja mõne aja pärast uuesti avada.
Swift vs. Java
Kuid uue rakenduse käivitamisel peab selle laadimiseks ja käivitamiseks olema mälus vaba ruumi. Kui see nii ei ole, tuleb koht vabastada. Seetõttu lõpetab süsteem jõuliselt mõned töötavad protsessid, näiteks juba käivitatud rakendused. Kuid mõlemad süsteemid, st Android ja iOS, töötavad RAM-iga erinevalt.
iOS-i operatsioonisüsteem on kirjutatud Swiftis ja iPhone'id ei pea tegelikult suletud rakendustest kasutatud mälu süsteemi tagasi kasutama. See on tingitud iOS-i ülesehitusest, kuna Apple'il on selle üle täielik kontroll, kuna see töötab ainult oma iPhone'ides. Seevastu Android on kirjutatud Java keeles ja seda kasutatakse paljudes seadmetes, seega peab see olema universaalsem. Kui rakendus lõpetatakse, tagastatakse selle kasutatud ruum operatsioonisüsteemile.
Omakood vs. JVM
Kui arendaja kirjutab iOS-i rakenduse, kompileerib ta selle otse koodiks, mis saab töötada iPhone'i protsessoris. Seda koodi nimetatakse algkoodiks, kuna selle käitamiseks ei ole vaja tõlgendamist ega virtuaalset keskkonda. Android seevastu on erinev. Java koodi kompileerimisel teisendatakse see Java Bytecode vahekoodiks, mis on protsessorist sõltumatu. Seetõttu võib see töötada erinevate tootjate erinevatel protsessoritel. Sellel on platvormidevahelise ühilduvuse jaoks tohutud eelised.
Muidugi on sellel ka miinus. Iga operatsioonisüsteemi ja protsessori kombinatsioon vajab Java virtuaalmasina (JVM) nime all tuntud keskkonda. Kuid algkood toimib paremini kui JVM-i kaudu käivitatav kood, nii et JVM-i kasutamine suurendab lihtsalt rakenduse kasutatava RAM-i mahtu. Seega kasutavad iOS-i rakendused vähem mälu, keskmiselt 40%. See on ka põhjus, miks Apple ei pea oma iPhone'e varustama nii suure RAM-iga kui Android-seadmetega.
Ma pole just ekspert, kuid kirjeldan oma vaatenurka kasutaja vaatenurgast, kes on androidi kasutanud 15 aastat ja nüüd on iPhone 2 miniga 13 kuud möödas. 8 GB mäluga androidil (viimati Samsung S21, Flip3) naasesin tavaliselt teatud aja möödudes varem käivitatud rakenduse juurde ja see oli ikka veel RAM-i laaditud, nii et see ei alanud otsast peale ja sain sujuvalt sealt kätte saada. jäi pooleli. Seevastu isegi 8GB mäluga "tulistasin maha" kõik rakendused kord nädalas, et RAM tühjendada, sest täismäluga hakkas süsteem aeglustuma. Mul ei ole iPhone'i puhul probleemi aeglustumine, kuid teisest küljest pean ütlema, et peaaegu identseid rakendusi kasutades, vastupidi, minuga juhtub regulaarselt, et kui ma naasen varem käivitatud rakenduse juurde, see laeb uuesti täielikult ja ma ei saa sujuvalt jätkata sealt, kus pooleli jäin.
Kumb variant on parem? Raske öelda... Androidis rakenduste tapmine ja RAM-i tühjendamine on kahe klõpsuga. Kogu rakenduse uuesti iPhone'i laadimine ei ole nii aeganõudev, nii et see polegi nii oluline... Ideaalne oleks muidugi iPhone'is rohkem RAM-i ja multitasking nagu Androidil :-D
Kurat, see on jälle loll. Üks asi, Androidi pole Javas ammu tehtud, selleks on Kotlin. Prügikoguja vastutab mälu eest, mis on iOS-is kõige lihtsam, mis on olemas ka oma puudustega. Asi on selles, et iOS tapab rakendused kohe, kui need ekraanilt eemaldate. See vabastab mälu nagu Linuxis, kui sisestate protsessi kill pid. Seetõttu võtab brauseri avamine ja eelmise töö juurde naasmine nii kaua aega. See artikkel on sõna-sõnalt tõlge X-aastasest artiklist, mille on koostanud iOS-i fanaatik, kellel puuduvad programmeerimisalased teadmised. Jah, mälu haldamise eest vastutab muidugi peamiselt programmeerija, mida rakendus teeb. Kui ta selle peale köhib, on maailmas mäluleke ja pqk sul võib olla X Gb mälu ja see on ikka kasutu. Ja ajal, mil paljud rakendused on ainult WebView, on see väga lihtne, sest see sööb ise seda, mida saab. Artikkel on jama, prügi.
Android ei kasuta enam jvm-i, vaid dvm-i. Ja lisaks kompileerib see seejärel natiivseks käivitatavaks failiks
Java on endiselt Androidis.