Android Studio 3.5 Canary lägger till "Apply Changes", en ersättning för Instant Run

Android Studio 3.5 introducerar Apply Changes, efterföljaren till Instant Run-funktionen i det populära apputvecklingsverktyget.

Android Studio 3.5 (för närvarande på Canary- och Dev-kanalerna) har nu ett nytt sätt att skicka kodändringar till din app och se deras effekter i farten utan att behöva starta om appen. Dubbad helt enkelt "Apply Changes", är det efterföljaren till "Instant Run"-funktionen i tidigare versioner av Android Studio.

Googles Blogg för Android-utvecklare säger följande om Apply Changes:

Apply Changes låter dig skjuta kod- och resursändringar till din löpande app utan att starta om appen – och i vissa fall utan att starta om den aktuella aktiviteten. Apply Changes ersätter Instant Run med en helt ny metod för byggoptimering. Istället för att skriva om bytekoden för din APK under byggtiden, omdefinierar Apply Changes klasser i farten genom att utnyttja runtime-instrumenteringen som stöds i Android 8.0 (API-nivå 26) eller högre.

Dessutom uppmanar Android Studio dig nu att bestämma om du vill starta om din app eller aktivitet när den upptäcker att ändringar inte är kompatibla med Apply Changes. Denna extra kontroll bör ge dig en mer konsekvent och förutsägbar upplevelse jämfört med beteendet hos Instant Run.

Blogginlägget fortsätter med att lista några begränsningar för den nya funktionen. Till exempel måste enheten du testar din app på åtminstone vara igång Android 8.0 Oreo (API nivå 26) och det finns vissa kodändringar som fortfarande kräver att din app startas om. Precis som med "Instant Run" tvingar "Apply Changes" din app att starta om om du:

  • Lägga till eller ta bort en klass, metod eller fält
  • Ändra manifestet
  • Ändra metodsignaturer
  • Ändra modifierare av metoder eller klasser
  • Byta namn på klasser
  • Byte av klassarv
  • Lägga till eller ta bort en resurs

Under "Kända problem" står det i blogginlägget att eftersom Google från början prioriterade stabilitet framför prestanda i den här nya funktionen, kommer "Apply Changes" ibland att köras långsammare än dess föregångare "Instant Run". Dessutom stöds inte x86_x64 emulatorbilder, och för felsökningsändamål är endast Android Pie (API Level 28) stöds. Du kan se hela listan över begränsningar och kända problem på källlänken nedan.

För en mer detaljerad beskrivning av skillnaden mellan "Apply Changes" och "Instant Run" hade en Google-anställd i Android Studio-teamet detta att säga på Reddit:

Det gör något väldigt, väldigt annorlunda. Instant Run hade en mycket specifik inverkan på byggandet, och instrumenterade var och en av dina klasser vid kompileringstillfället för att förbereda dem för att ersättas under körtiden med en ny version av klassen. Den delar också upp din APK i flera APK-filer för att ladda upp din app mer stegvis.

Apply Changes gör inget liknande. Din APK är i stort sett densamma oavsett om du använder Apply Changes eller inte. Istället förlitar den sig på nya runtime-instrumenteringsfunktioner hos ART VM för att dynamiskt ladda om klasser och ersätta dem medan appen körs. Det är därför det kräver mycket nyare versioner av Android.

"Apply Changes" förväntas så småningom ersätta "Instant Run" i Beta- och Stable-kanalerna när Google gör förbättringar av dess prestanda och stabilitet.


Källa: Android Developers Blog