Spørsmål:
Forbedre Android-emulatorytelsen på Windows 7 x64
mikywan
2011-04-07 08:49:25 UTC
view on stackexchange narkive permalink

Jeg kjører Eclipse Helios på Windows 7 x64. Jeg har en Core 2 Duo 2.0 Ghz med 4.0 GB, som jeg synes skal være nok, siden jeg aldri har hatt noen ytelsesproblemer med andre utviklingsverktøy.

Når jeg kjører min første app på Android Emulator ( både 2.3.3 og 3.0) tok det minst 5 minutter å laste inn operativsystemet, og først kjørte det ikke engang HelloAndroid-appen. Selv da jeg klarte å kjøre applikasjonen, var ytelsen uutholdelig.

Jeg har prøvd forskjellige ting for å forbedre ytelsen, men det vises ingen større forbedringer. Jeg tror jeg savner noe.

Ting jeg har prøvd:

På AVD Manager

  1. Enhetens RAM-størrelse til 512.
  2. Oppløsning til 640 x 480 .
  3. Øyeblikksbilde aktivert.

På prosjektinnstillinger \ Android

  1. \ Launch \ -cpu-delay 0 -no-boot- anim -cache ./cache -avd Android3

Ting jeg ikke kan prøve: - Implementering på en enhet (har ingen).

Forresten , Jeg har hatt det samme problemet på en MAC Mini 2,66 GHz 2 GB, men disse innstillingene gjorde forskjellen.

Hvem som helst kan gi noen tips for å forbedre denne lamme ytelsen ?.

Få en firekjerne med hypertråding @ 2,8 GHz og et vanvittig skjermkort. Heh. Men seriøst er emulatoren treg. Generelt sett er emulering alltid treg med mindre maskinvaren er en størrelsesorden kraftigere. Jeg tror ikke du kommer til å få det til å fungere mye bedre enn du allerede har.
Egentlig støtter ikke emulatoren flere kjerner (ennå). Så clockspeed betyr virkelig noe. Selv på min nye dev-maskin har jeg ytelsesproblemer, spesielt med honningkake. Jeg snakker om den nyeste i7 firekjernen, 8 GB minne og en solid state harddisk.
Ha, så min gamle 3.0 GHz Pentium 4 burde kjøre den bedre (med ingenting annet større i bakgrunnen)? Gal.
@Bryan Denny Selv om emulatoren ikke multiterer, gir den flere kjerner hjelper deg med å flytte arbeidsmengden til mindre brukte kjerner, men dette reduserer stabiliteten, noe som resulterer i periodiske krasj. Så det er en kompromiss med hastighet / stabilitet, men jeg foretrekker å bruke alle kjerner for hastighet.
Tre svar:
Flow
2011-11-28 16:54:59 UTC
view on stackexchange narkive permalink

Emulatoren er treg fordi det er en qemu som emulerer en helt annen CPU-arkitektur slik den brukes av forbruker-PCer: ARM (vs. x86 (_64) på ​​PC-en din)

Dette betyr at hver CPU-instruksjon på emulatorens ARM-CPU må emuleres, noe som i seg selv er treg . Også emulatoren er AFAIK en-trådet. Dette betyr at hastighet bare kan oppnås med raske CPU-kjerner - multikjerner hjelper ikke her - og en rimelig mengde RAM.

Å emulere en CPU har en tendens til å være treg, men telefonemulatoren etterligner også ARM, og den er mye raskere. Det er mer enn bare instruksjonssettene. Honeycomb ser ut til å være mye mer kompleks (og krever sannsynligvis en kraftigere ARM-prosessor). GoogleTV er x86, så jeg lurer på hvordan emulatorytelsen vil være ... (Enten de etterligner x86 eller kjører den som en naturlig prosess.)
Hallaghan
2011-08-30 14:01:55 UTC
view on stackexchange narkive permalink

Du kan prøve å bruke en tredjepartsemulator som etter min erfaring fungerer veldig bra. Jeg kommer ikke til å fortelle deg at den ikke vil lagre fra tid til annen, men ta prøveperioden, og du vil se hvor mye bedre kjører denne emulatoren.

Det er ikke et gratis program, men det er heller ikke dyrt. Du finner det på YouWave Android Emulator. Prøv prøveversjonen og kom tilbake til oss ;)

idbrii
2011-07-31 13:21:41 UTC
view on stackexchange narkive permalink

Honeycomb (3.0) er notorisk sakte i emulatoren. Du kan prøve å få mest mulig ut av funksjonaliteten din til å fungere for telefonen først, for å minimere bruk av Honeycomb.

Det er noen BIOS-innstillinger for å aktivere virtualiseringsstøtte i CPUen din. Jeg tror det kan øke hastigheten på emulatoren, men jeg er ikke sikker. (De eksakte navnene på systemet ditt vet jeg ikke, men de vil ha "virtualisering" eller "vt-x" eller noe i navnet.

Du kan også prøve å dedikere en prosessor til emulatoren. . Du kan endre "prosessoraffinitet" for prosesser i Windows ved hjelp av oppgavebehandling. Hvis du endrer den slik at emulatoren din foretrekker en prosessor, og de andre hovedoppgavene dine (som formørkelse) unngår prosessoren, kan du se noen gevinster. Hvis prosessoren din er hypertrådet, må du sørge for at du behandler de to virtuelle kjernene som en kjerne og tilordne emulatoren til å foretrekke begge virtuelle kjernene.

(Å finne prosessene kan være enklere med ProcessExplorer fordi du kan klikke på målknappen og deretter klikke på et vindu, og det viser deg prosessen for det vinduet.)

Oppdater: Se Bruke maskinvareakselerasjonsdelen i Android-dokumentene for å se hvordan du bruker GPU- og virtualiseringsstøtte i CPU-en din for å øke hastigheten på emulatoren.

Forbedrede CPU-instruksjonssett hjelper ikke med å øke hastigheten på emulatoren, fordi det i utgangspunktet er qemu som etterligner en ARM-CPU.
Med mindre de hjelper qemu med å behandle ARM-instruksjonene raskere. (Så det kan matche ARM-hastigheten.) Husk at Honeycomb kjører * tregere * på emulatoren enn på en ekte enhet. Si at ARM hadde SIMD-instruksjoner, men x86 ikke hadde det, og i stedet etterlignet det dem som serieoperasjoner. Å aktivere en SIMD CPU-utvidelse på x86 vil løse dette problemet. Når det er sagt, vet jeg ikke hva virtualiseringsstøtten gjør, bortsett fra at den er ment å forbedre ytelsen når du simulerer CPUer.
Virtualisering og emulering er ikke det samme.
@Lie: Sant, men det er utenfor poenget: Intel / AMDs virtualiseringsstøtte (teoretisk) gjør Android-emulatoren raskere. Noen er sannsynligvis upresise med navnene sine. (Jeg antar at CPU-støtten fungerer for både virtualisering og CPU-emulering, slik at CPU-leverandørene faktisk ikke er utenfor.) Pokker, bare fordi de ikke er de samme, betyr det ikke at de ikke kan kombineres i ett system: ["QEMU er en generisk og åpen kildekode maskinemulator og virtualiseringsapparat"] (http://wiki.qemu.org/Main_Page).


ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 2.0-lisensen den distribueres under.
Loading...