Google brengt binnenkort 64-bitsversie Chrome voor Android uit

Google gaat van zijn Chrome-browser een 64-bitsversie maken die binnenkort de huidige 32-bitsversie moet vervangen. Vanaf Chrome 85 lijkt de software als 64-bitsvariant te worden aangeboden, zolang er op het apparaat Android 10 wordt gedraaid.

Dat ontdekte Android Police, die de informatie haalde van de Chromium-ontwikkelaarskanalen Dev en Canary. Daar worden momenteel Chrome 85 en 86 ontwikkeld, waarbij wordt aangegeven dat deze op 64 bit draaien. Chrome 83 en 84, die door Google al zijn uitgebracht, doen het nog met 32 bit. Waarschijnlijk komt Chrome 85 in augustus uit.

Android Police heeft de ontwikkelaarsversie van de 64-bitbrowser uitgeprobeerd en zag dat deze in benchmarks iets betere prestaties neerzet dan de voorgaande versie. Hoe dit zich vertaalt naar prestaties in gebruikssituaties is nog niet duidelijk.

De bedoeling is dat vanaf Chrome 85 Android-toestellen standaard op de 64-bitsversie van de browser gaan werken. Daarvoor is echter wel een apparaat nodig dat minimaal Android-versie 10 draait; er zijn nog maar weinig Android-toestellen die over deze versie van het besturingssysteem beschikken.

Door RoD

Forum Admin Mobile & FP PowerMod

04-07-2020 • 13:49

56

Submitter: TheVivaldi

Reacties (56)

56
51
35
4
0
7
Wijzig sortering
Voor degenen die de 64bit beta van Chrome84 willen installeren: er zijn niet alleen versies voor Android 10, maar ook voor Android 7+:

https://www.apkmirror.com...eta-84-0-4147-69-release/

Voor de 64bit developer release van Chrome 85 via de play store:
https://play.google.com/store/apps/details?id=com.chrome.dev

[Reactie gewijzigd door greenbat op 24 juli 2024 02:10]

Misschien een domme vraag, wat heb je aan 64 bit chrome tov 32 bit?
Ik denk de mogenlijkheid tot meer geheugen. (Open tabbladen.) Verder meer snelheid met 64bit getalsoperaties, en andere operaties die gebruik kunnen maken van grotere registers.

Dat laatste lijkt me het belangrijkst, bijvoorbeeld data kopieren of verplaatsen met 8 bytes tegelijk. (Hoewel geheugen bandbreedte een bottleneck is, kunnen de extra cycli worden gebruikt voor andere operaties.) Daarnaast werken binare operaties zoals XOR, NOT en AND sneller als ze op meer dan 4 bytes tegelijk kunnen. Hier vallen ook delen van crypto onder.
Ik vind het opmerkelijk dat Chrome nog steeds op 32 bits draait op Android. Ik had verwacht dat Google alle eigen apps wel 64 bits zou maken. Veelal veel stabieler.

Bij iOS zijn alle apps 64 bits dacht ik.

Iemand een idee waarom Google hiervoor kiest?
Het geheugengebruik van Chrome op Android op 64-bits lag ongeveer 15-20 procent hoger dan op de 32-bits versie, zonder een noemswaardig verschil in snelheid. Dat, samen met het feit dat een hoger geheugengebruik doorgaans minder ruimte over laat voor caches, had een negatieve impact op de laadtijd van webpagina's.

Houdt tevens in gedachten dat dit niet enkel invloed heeft op Chrome: ook WebView en Chrome Custom Tabs zien dit verschil. Het merendeel van applicaties op de Play Store gebruikt een WebView, vaak voor advertenties.

Het team heeft daar bijna twee jaar aan gewerkt, met talloze projecten zoals pointer compression en v8 lite om daarvoor te compenseren. Het verschil in geheugengebruik is teruggebracht tot een paar procent, met vergelijkbare snelheid, dus het moment is juist om dat uit te brengen :).
Onder Android 10 is WebView weer een aparte app.
In de Play Store—inderdaad. Zodra de app geïnstalleerd is wordt het iets ingewikkelder, en is het afhankelijk van de Android versie die je gebruikt. De Monochrome en Trichrome projecten (documentatie) zorgen er voor dat de gedeelde libraries die Chrome & WebView gebruiken niet meerdere keren op je telefoon opgeslagen hoeven te worden, en, belangrijker, niet meerdere keren in je geheugen geladen hoeven te worden bij normaal gebruik.
Waarom zou 64 bit stabieler zijn?
De toegenomen adresruimte van 64-bit software maakt maatregelen als ALSR effectiever.

Ook zitten er verbeteringen in de instructieset voor zowel ARM als x86 die efficiënter en sneller kan zijn.

Dit gaat dan weer ten koste van geheugenruimte omdat pointers langer zijn. Met de huidige smartphones moet dat niet zo'n heel groot probleem zijn denk ik. Smartphones met niet zoveel RAM hebben vaak ook geen 64-bitsupport dus ik denk niet dat er in de praktijk veel mensen last van hebben.
Veiliger (ALSR), efficïenter, sneller... ok, logisch, maar stabieler wordt er beweerd. Daar heb ik nog nooit van gehoord en is ook gewoon niet zo imo.
Nee, ik geloof niet dat er stabiliteitsvoordelen aan hangen.
Inderdaad niet een gegeven feit, maar ik neem aan dat 32 bit op Android ook op een max van 3.5GB aanspreekbaar geheugen zit.

Nou zou het op mobiel niet snel zoveel aan mogen tikken, maar toch.

Er zijn in de laatste releases van v8 ook geheugen beperkingen opgeheven m.b.t. webassembly etc, dus wellicht dat het vanuit de zelfde doos komt.

p.s. hier wat leuk leesvoer:

https://v8.dev/blog

[Reactie gewijzigd door DutchKevv op 24 juli 2024 02:10]

Als je de pricewatch gebruikt heeft ongeveer 1/3e van het aanbod aan Android telefoons meer dan 4Gb. Tel daarbij op dat ik meer dan alleen een browser op mijn telefoon gebruik en de effectieve hoeveelheid geheugen die ik overhoud voor een browser is een stuk minder. Ik neem aan dat Android telefoons geen swap gebruiken (kan iemand dat bevestigen), dus ik zie het nut van 64 bit voor het aanspreken van meer geheugen helemaal niet.
Het grootste voordeel is dat de 32-bits abstractie laag uit het OS gehaald kan worden en alleen 64-bit gesupport hoeft te worden. Net zoals dat ik hoop dat WoW64 uiteindelijk teniet gedaan wordt.
Bij iOS zijn alle apps 64 bits dacht ik.
Klopt. Sinds de iPhone 5s met iOS 7 (2013) hebben alle iPhones en iPads een 64-bits SoC, vanaf iOS 11 (2017) worden 32-bits apps niet meer ondersteund.
Iemand een idee waarom Google hiervoor kiest?
Er zijn nog teveel oude telefoons en tablets en Android versies die het niet ondersteunen.
Er zijn nog teveel oude telefoons en tablets en Android versies die het niet ondersteunen.
Ik denk eerder omdat Google verbeteringen moest toebrengen aan hun JIT engine eer ze voordeel uit de nieuwe instructieset konden halen zonder hun geheugenvoetafdruk te veel te verhogen. Binnen Google Play kun je per architectuur een APK uploaden, dus compatibility is niet zo'n heel groot probleem; 't is een kwestie van de app nog een keer compilen.

Ik moet zeggen dat ik ook wel benieuwd ben naar waarom dit zo lang duurde. Het is niet alsof A64 of AArch64 ineens uit de lucht is komen vallen ofzo. Misschien dat het puur komt doordat de oude standaard gewoon werkte zonder problemen?
Het werkt, niks doen is makkelijker dan iets doen.
Google doet genoeg, ik denk alleen dat 64-bits ondersteuning geen prioriteit heeft.
Ik weet niet waarom, maar als ik zou moeten gokken zou ik zeggen vanwege de Javascript JIT compiler, want die moet nu ineens code genereren voor AArch64 ipv AArch32.
Sinds eind vorig jaar moeten Android-apps in de Playstore ook volledig 64-bits compatibel zijn. Dus, tenzij een app al heel lang geen updates heeft gehad, kan je er vanuit gaan dat apps 64-bits kunnen draaien.
Veelal veel stabieler
Wat is je onderbouwing dat 64 bit stabieler is dan 32 bit?
Dat hangt voor zover ik weet af van de hoe de software geprogrammeerd is en niet van het feit of het 32 of 64 bits is.
Nou ik had verwacht dat het al lang 64 bit zou zijn voor de 64 bit apparaten. En waarom kan dit niet op android 9? Ik dacht dat android zelf al op 64bit loopt sinds android 6, in ieder geval mijn nexus 6p toendertijd was 64 bit dacht ik.

Achja mijn asus had binnen een paar maanden na release android 10, dus kom maar door.
Daarvoor is echter wel een apparaat nodig dat minimaal Android-versie 10 draait; er zijn nog maar weinig Android-toestellen die over deze versie van het besturingssysteem beschikken.
Beetje een overstatement. 22% is niet bepaald weinig, en het stijgt gestaag. Het kan beter, uiteraard, maar we hebben het wel over miljoenen toestellen.
Ik ben bang dat chrome nog meer van je RAM pakt (indien je meer dan 4GB RAM hebt).
Mooi toch? Dat is het hele idee van RAM, je hebt het om te gebruiken. Op Android boeit het ook zo goed als niks, want apps worden automatisch gesloten wanneer er meer geheugen nodig is voor een nieuwe app. Er is absoluut geen reden om je druk te maken om geheugengebruik op Android, en mocht je merken dat apps te snel gesloten worden dan kun je altijd gewoon minder tabs open laten staan in Chrome.
Ram is idd om te gebruiken, maar als het actieve proces heel veel ram gebruikt worden alle achtergrondapplicaties gesloten. Dus ook beter ben je alsnog zuinig met ram zodat andere applicaties in het geheugen kunnen blijven.
Ja, maar dat heb je toch zelf in de hand. Het enige verschil tussen 32-bit en 64-bit Chrome op een Android telefoon is dat je meer tabs zou kunnen openen zonder dat oudere tabs stilgezet worden (waarmee ze niet meer in geheugen blijven, en bij focus opnieuw geladen worden).

Zolang je een beetje let op wat voor apps je downloadt zou je met een moderne Android telefoon (met 6GB geheugen of meer) nooit moeten ervaren dat je muziek stopt omdat je een andere app open hebt. Ik heb zelf een OnePlus 7T Pro met 8GB RAM, en de enige keer dat ik merk dat een app op de achtergrond gesloten wordt is als ik tussen 4-5 spelletjes schakel die allemaal hun assets inladen. Maar zelfs dan blijft Spotify gewoon doorspelen, omdat die een notificatie open houdt.

Wat ik wel vaak zie bij mensen die klagen over dat apps gesloten worden is dat ze meerdere verschillende apps hebben die een notificatie open houden, aangepaste lock screens, live achtegronden, RAM cleaners etc. Dat zijn allemaal dingen die er 'passief' voor zorgen dat je geheugen volloopt en Android niet zelf z'n werk kan doen. Dat je in Chrome een extra tabblad kan openen maakt daarin weinig verschil.
Ram cleaners, bestaan die? Dat verkloot het resource beheer van Android zelf, dat lijkt me zeer ongewenst!
Helaas wel ja, en helaas zijn er ook veel mensen die daar intrappen
Inderdaad jammer. De behoefte om een paar bytes op te ruimen bestaat al sinds Windows 3.1, en men is hier niet van af te brengen, ook niet met een OS dat het veel beter zelf kan.
Ik heb zelf sws energiebesparing aanstaan omdat ik de volle prestaties toch niet nodig heb, waardoor apps minder op de achtergrond draaien. Alsnog is het soms wat krap met 4GB omdat apps steeds meer geheugen innemen, net als het besturingssysteem, maar zolang je verder geen gekke dingen doet en niet zoals ik te lui bent om tabbladen af te sluiten, kan je 95% van de tijd alles draaien zonder dat er dingen worden afgesloten. Meerdere zware apps zul je niet kunnen draaien, maar dat hoeft ook niet iedereen gelukkig :). Ik hoop dat de nieuwe versie van Chrome niet al te zwaar is, aangezien ik graag Chrome gebruik en mijn apparaten op 4GB draaien (wat genoeg zou moeten zijn dacht ik). Ik zie wel, amders ga ik een alternatief zoeken
Je zult wel erg veel RAM moeten gebruiken voordat alle applicaties worden gesloten. Overigens wordt de staat (als de app zich een beetje gedraagt) opgeslagen naar je opslag dus het is niet alsof je opnieuw moet beginnen in je app, het duurt alleen iets langer om het scherm weer in te laden.

Overigens worden achtergrondapplicaties die de nodige maatregelen nemen (melding in de notificatiebalk etc.) niet zo snel afgesloten als de fabrikant niet loopt te rommelen met de memory manager. Als je daar wel last van hebt, kun je op https://dontkillmyapp.com/ lezen hoe je op je telefoon instelt hoe je voorkomt dat je geheugen verkeerd verdeeld wordt.
Precies dit, dan wordt ineens je muziekapp ofzo afgesloten.
Geen Android gebruiker, maar heb wel een paar (native) Android apps gemaakt en volgens mij is een muziekapp toch wel een slechte voorbeeld. Naar mijn weten zijn apps die op de lockscreen of notificatiecenter terecht komen 'Foreground Services' en reserveren zij ook de benodigde geheugen om later niet afgesloten te worden omdat een andere app meer geheugen nodig heeft.

Zie ook de eerste zin hier:
A foreground service is a service that the user is actively aware of and isn't a candidate for the system to kill when low on memory.
Ook foreground services kunnen wel gesloten worden (weet ik als developper).
Ik gebruik Android al 10 jaar op een boel apparaten en ik heb nog nooit meegemaakt dat een muziek/media app vanwege geheugengebruik afgesloten werd.
Chrome kan al meer dan 4GB RAM pakken (en doet dat ook graag) omdat dat limiet voor elke proces geld en elke tab en extension die je draait een los proces is
En dat is een goed iets. Je hebt ram niet om leeg te laten.

Als een ander proces het nodig heeft dan wordt het vrijgegeven.
Dat is een goed iets als je niets anders hebt draaien... :P
Ja, net zoals Microsoft ooit voor Internet Explorer adverteerde dat het 100% van je CPU gebruikte.
Beter gaan ze een keer werken aan Chrome voor MacOS. Dat is zo enorm traag.
Chrome op Mac is wel écht slecht inderdaad. Niet alleen traag maar het verbruikt zoveel geheugen en processorkracht. Op mijn 15 inch pro gaat de accu ook letterlijk 2 keer sneller leeg als ik Chrome ipv Safari gebruik.
Probeer eens Edge. Is ook gebouwd met Chromium maar die heeft minder energie nodig dan Chrome. Verder werken ook alle Chrome extensies
Ga het proberen. Voelt toch een beetje "vies" een browser van MS installeren haha. Brave is trouwens ook traag bij mij.

[EDIT]
Geïnstalleerd. Lijkt vooralsnog prima te werken. Wel erg jammer dat de context menus in Windows stijl zijn.

[Reactie gewijzigd door bento1 op 24 juli 2024 02:10]

Voor mij voelt iets van google vies.
Best vreemd, want Edge gaat als een tierelier.
Edge werkt prima. Sinds de Chromium Edge Beta gebruik ik geen Chrome meer, en dat is goed voor de accuduur.
Maar werkt het ook beter of veiliger Safari? Is de accuduur dan ook net zo lang?

Ik ben een beetje terughoudend met software van Microsoft, vaak een gatenkaas wat betreft beveiliging en afwerking. Eerlijk is eerlijk, op browser-vlak hebben ze niet de meest glorieuze geschiedenis...
Beter gaan ze een keer werken aan Chrome voor MacOS. Dat is zo enorm traag.
Geen last van. Ik gebruik Edge, wel Chromium, geen overbodige Google processen.
Ik gebruik zelf Samsung Internet. Ook op chromium, maar gebruikt niet zoveel ram.
Daarvoor is echter wel een apparaat nodig dat minimaal Android-versie 10 draait; er zijn nog maar weinig Android-toestellen die over deze versie van het besturingssysteem beschikken.
Daar ben ik het mee oneens. Als je kijkt in de Pricewatch van Tweakers en filtert op toestellen die in het afgelopen jaar beschikbaar zijn gekomen (vanaf 1 juli 2019), dan vind je 232 producten:
https://tweakers.net/smar...XUsBdlKV4HUNhTfops4bbv-w8

Als je vervolgens filter op Android 10, dan vind je 81 producten:
https://tweakers.net/smar...VUsNelLV4LUBhT-Uoss3P7fsf

Dat is 81 van de 232 is 35% van de toestellen. Dat is aanzienlijk! Tevens een aanzienlijk deel van de consumenten koopt een nieuw toestel en een recent model (bewering zonder bron).

Als je het filter nog een jaar terug schuift, dus verkrijgbaar vanaf 1 juli 2018, dan vind je 95 van de 709 is 13% van de toestellen.

Als ik in Android Studio een nieuw project start, dan kan ik kiezen voor de minimaal ondersteunde Androidversie. Als ik die op Android 10 zet, dan is op dit moment 8,2% van de toestellen geschikt. Niet gebruikers, maar toestellen. Wereldwijd zijn er dus meer Androidtoestellen met Androidversie < 10 dan op de Tweakers Pricewatch beschikbaar sinds de afgelopen 2 jaar.

Volgens https://gs.statcounter.co...e/mobile-tablet/worldwide zit al 22% van gebruikers op Android 10. Wederom: niet weinig en niet zeldzaam. In Nederland zit zelfs 40% van de Androidgebruikers op Android 10, in juni 2020: https://gs.statcounter.co...mobile-tablet/netherlands.

Kortom: heel veel gebruikers, alleen al miljoenen in Nederland, komen in aanmerking voor de 64-bitsversie van Chrome. Niet. Weinig.

Op dit item kan niet meer gereageerd worden.