Adam Kos Mae'r swm delfrydol o RAM sydd ei angen ar ffonau ar gyfer amldasgio llyfn yn bwnc llosg. Mae Apple yn llwyddo gyda maint llai yn ei iPhones, sy'n aml yn fwy defnyddiadwy na datrysiadau Android. Ni fyddwch hefyd yn dod o hyd i unrhyw fath o reolaeth cof RAM ar yr iPhone, tra bod gan Android ei swyddogaeth benodol ei hun ar gyfer hyn.
Os ewch chi, er enghraifft, mewn ffonau Samsung Galaxy i Gosodiadau -> Gofal dyfais, fe welwch ddangosydd RAM yma gyda gwybodaeth ar faint o le sydd am ddim a faint sy'n cael ei feddiannu. Ar ôl clicio ar y ddewislen, gallwch weld faint o gof y mae pob cais yn ei gymryd, ac mae gennych hefyd yr opsiwn i glirio'r cof yma. Mae swyddogaeth RAM Plus hefyd wedi'i lleoli yma. Ei ystyr yw y bydd yn brathu nifer benodol o GB o'r storfa fewnol, y bydd yn ei ddefnyddio ar gyfer cof rhithwir. Allwch chi ddychmygu rhywbeth fel hyn ar iOS?
Photo Gallery
Mae ffonau clyfar yn dibynnu ar RAM. Mae'n eu gwasanaethu i storio'r system weithredu, i lansio ceisiadau a hefyd i storio rhywfaint o'u data yn y storfa a cof byffer. Felly, rhaid trefnu a rheoli RAM yn y fath fodd fel y gall cymwysiadau redeg yn esmwyth, hyd yn oed os byddwch chi'n eu gollwng i'r cefndir a'u hagor eto ar ôl ychydig.
Gallai fod o ddiddordeb i chi
Swift vs. Java
Ond wrth ddechrau cais newydd, mae angen i chi gael lle am ddim yn y cof i'w lwytho a'i redeg. Os nad yw hyn yn wir, rhaid gadael y lle. Felly bydd y system yn dod â rhai prosesau rhedeg i ben yn rymus, megis cymwysiadau sydd eisoes wedi dechrau. Fodd bynnag, mae'r ddwy system, h.y. Android ac iOS, yn gweithio'n wahanol gyda RAM.
Photo Gallery
Mae system weithredu iOS wedi'i hysgrifennu yn Swift, ac nid oes angen i iPhones ailgylchu cof ail-law o apiau caeedig yn ôl i'r system. Mae hyn oherwydd y ffordd y mae iOS yn cael ei adeiladu, oherwydd mae gan Apple reolaeth lawn drosto gan mai dim ond ar ei iPhones y mae'n rhedeg. Mewn cyferbyniad, mae Android wedi'i ysgrifennu yn Java ac fe'i defnyddir ar lawer o ddyfeisiau, felly mae'n rhaid iddo fod yn fwy cyffredinol. Pan ddaw'r cais i ben, caiff y gofod a gymerodd ei ddychwelyd i'r system weithredu.
Gallai fod o ddiddordeb i chi
Cod brodorol vs. JVM
Pan fydd datblygwr yn ysgrifennu app iOS, mae'n ei grynhoi'n uniongyrchol i god a all redeg ar brosesydd yr iPhone. Gelwir y cod hwn yn god brodorol oherwydd nid oes angen dehongliad nac amgylchedd rhithwir i'w redeg. Mae Android, ar y llaw arall, yn wahanol. Pan fydd cod Java yn cael ei lunio, caiff ei drawsnewid i god canolradd Java Bytecode, sy'n annibynnol ar brosesydd. Felly gall redeg ar wahanol broseswyr o wahanol wneuthurwyr. Mae gan hyn fanteision enfawr ar gyfer cydweddoldeb traws-lwyfan.
Wrth gwrs, mae yna anfantais hefyd. Mae angen amgylchedd o'r enw Peiriant Rhithwir Java (JVM) ar bob system weithredu a chyfuniad prosesydd. Ond mae cod brodorol yn perfformio'n well na chod a weithredir trwy'r JVM, felly mae defnyddio'r JVM yn syml yn cynyddu faint o RAM a ddefnyddir gan y rhaglen. Felly mae apps iOS yn defnyddio llai o gof, ar gyfartaledd 40%. Dyna hefyd pam nad oes rhaid i Apple arfogi ei iPhones â chymaint o RAM ag y mae gyda dyfeisiau Android.
Dydw i ddim yn arbenigwr yn union, ond byddaf yn disgrifio fy safbwynt o safbwynt defnyddiwr sydd wedi defnyddio android ers 15 mlynedd ac sydd bellach 2 fis i mewn i'r iPhone 13 mini. Ar android gyda chof 8GB (yn fwyaf diweddar Samsung S21, Flip3) fel arfer dychwelais ar ôl amser penodol i'r cymhwysiad a lansiwyd yn flaenorol ac roedd yn dal i gael ei lwytho mewn RAM, felly ni ddechreuodd eto a gallwn godi'n esmwyth lle rydw i chwith i ffwrdd. Ar y llaw arall, hyd yn oed gyda 8GB o gof, rwy'n "saethu i lawr" pob cais unwaith yr wythnos i glirio'r RAM, oherwydd dechreuodd y system arafu gyda chof llawn. Nid oes gennyf broblem gydag arafu ar yr iPhone, ond ar y llaw arall, mae'n rhaid i mi ddweud wrth ddefnyddio cymwysiadau sydd bron yn union yr un fath, i'r gwrthwyneb, mae'n digwydd i mi yn rheolaidd pan fyddaf yn dychwelyd i gais a lansiwyd yn flaenorol, mae'n llwytho'n gyfan gwbl eto ac ni allaf barhau'n esmwyth lle gadewais i ffwrdd .
Pa opsiwn sy'n well? Anodd dweud... Mae lladd apiau ar android a chlirio RAM yn fater o ddau glic. Nid yw llwytho'r rhaglen gyfan eto ar yr iPhone yn cymryd cymaint o amser, felly does dim ots cymaint... Wrth gwrs, byddai'n ddelfrydol cael mwy o RAM ar yr iPhone ac amldasgio fel ar Android :-D
Shit, mae'n dwp eto. Am un peth, nid yw Android wedi'i wneud yn Java ers amser maith, dyna beth yw pwrpas Kotlin. Mae casglwr sbwriel yn gyfrifol am y cof, sef y symlaf yn iOS, sy'n bodoli hyd yn oed gyda'i anfanteision. Yr holl beth yw bod iOS yn lladd apps cyn gynted ag y byddwch yn eu tynnu oddi ar y sgrin. Mae hyn yn rhyddhau cof yn union fel ar linux pan fyddwch chi'n teipio kill pid o broses. Dyna pam ei bod yn cymryd cymaint o amser i agor y porwr a dychwelyd i'r gwaith blaenorol. Mae'r erthygl hon yn gyfieithiad gair am air o erthygl X blwydd oed gan ffanatig iOS heb unrhyw wybodaeth rhaglennu. Ydy, wrth gwrs, cyfrifoldeb y rhaglennydd yn bennaf yw rheoli cof, yr hyn y mae'r cais yn ei wneud. Os yw'n pesychu arno, mae cof yn gollwng yn y byd a pqk gallwch chi gael X Gb o gof ac mae'n dal i fod yn ddiwerth. Ac ar adeg pan fo llawer o geisiadau yn WebView yn unig, mae hyn yn syml iawn, oherwydd ei fod ei hun yn bwyta'r hyn y gall. Mae'r erthygl yn nonsens, sothach.
Nid yw Android bellach yn defnyddio jvm, ond dvm. Ac yn ogystal, mae wedyn yn ei lunio yn weithredadwy brodorol
Mae Java yn dal i fod yn Android.