Android studio что такое instant run

Instant Run: How Does it Work?!

An Android Tool Time Deep Dive

W hen something’s simple and helpful, most people are satisfied with that. But us engineers — we’re not normal people.

Take Instant Run. It’s a feature in Android Studio that uses ✨magic✨ to significantly reduce the build and deploy times for incremental code changes during your coding / testing / debugging lifecycle.

I say magic, because for the most part that’s how it looks. The first time you hit run or debug, it works like you’d expect — then each time you make a change and hit run or debug again (this time with a ⚡ on the icon), the changes are applied before I’ve had a chance to shift my attention to my phone.

Let’s save the magic for Sunday nights

I prefer my magic to come with a side-helping of dragons, political intrigue, and unexpected beheadings, so I got together with the Android Studio engineering team to get a peek behind the curtain, and learn how Instant Run actually works.

Start with this simple flow chart of a typical build cycle

The goals of Instant Run are really simple:

Remove as many of these steps as possible, and make whatever remains as fast as possible.

In practice that means:

• Build and deploy only the incremental changes.
• Don’t reinstall the app.
• Don’t restart the app.
• Don’t even restart the Activity.

Hot, Warm, and Cold Swaps aren’t references to games played during 70’s parties. As far as I know.

Hot Swap: Incremental code changes are applied and reflected in the app without needing to relaunch the app or even restart the current Activity. Can be used for most simple changes within method implementations.

Warm Swap: The Activity needs to be restarted before changes can be seen and used. Typically required for changes to resources.

Cold Swap: The app is restarted (but still not reinstalled). Required for any structural changes such as to inheritance or method signatures.

When you hit run or debug, something like this happens

Your manifest files are merged and packaged, along with your app’s resources, into an APK. Similarly, your source code .java files are compiled into bytecode, converted to .dex files, and they’re also included within your APK.

The first time you hit Run or Debug with Instant Run enabled, Gradle performs some additional tasks

Bytecode instrumentation is added to your .class files, and a new App Server class is injected into your app.

A new Application class definition is also added, which injects custom class loaders and will start the App Server. Accordingly, your manifest is modified to ensure your app uses it (if you’ve created your own Application class, the Instant Run version will proxy yours.)

Instant Run is now… running, so if your make code changes and hit run or debug again, Instant Run will try to shortcut as much of the full build process as possible using a Hot, Warm, or Cold swap.

Before applying Instant Run changes, Android Studio checks that there’s an open socket to an App Server running within an Instant Run enabled version of your app. It confirms the app is running in the foreground, and that its build ID is the version Android Studio expects.

Hot Swapping

Android Studio monitors which files are changed during development, and runs a custom Gradle task to generate .dex files for only the modified classes.

Those new .dex files are picked up by Android Studio, which deploys it to the App Server running within our app.

Because the original versions of our classes already exist in the running app instance — Gradle has transformed the “updated” versions such that they effectively override those pre-existing classes. Those transformed, updated classes are then loaded by the App Server using the custom class loaders.

From now on, each time a method gets called — anywhere within our app — the instrumentation injected into our original class files communicates with the App Server to see if they’ve been updated.

If so, execution is delegated to the new “override” classes and the new, modified, version of the method will execute instead.

Redirecting methods works well for changes to method implementations, but what about things that are loaded when the Activity starts?

Warm Swapping

A warm swap restarts the Activity. Resources are loaded when Activities are started, so modifying them requires an Activity restart to force a resource reload.

Currently, changes to any resource results in all of them being re-packaged and transmitted to your app — but we’re working on an incremental packager that will only package and deploy new or modified resources.

Note that a warm swap won’t work for changes to resources referenced within the Manifest — or changes to the manifest itself — because Manifest values are read when the APK is installed. Changes to the Manifest (or manifest-referenced resources) will trigger a full build and deploy.

Unfortunately, restarting the Activity won’t magically apply structural changes. Adding, removing, or changing annotations, fields, static or instance method signatures, or changing parent classes or static initializers will require a Cold Swap.

Cold Swaps

When deployed, your app and it’s sub-projects are divided into up to 10 slices, each its own dex file; classes are allocated to slices based on their package names. When applying a cold swap, a modified class will require all the other classes within the same slice to also be redexed before that slice is deployed to the target device.

This approach depends on the Android Runtime being capable of loading multiple .dex files, a feature introduced with ART, which is only guaranteed on Android 5.0 (API level 21) devices and higher.

For target devices running API level 20 or lower — and therefore possibly using the DALVIK runtime, Android Studio deploys a full APK.

Instant Run is clever, but it can’t turn back time

Code changes that might otherwise be applied through a Hot Swap, but which affect initializers that were run when the application was first run, you’ll need to restart your app for the changes to take effect.

Instant Run Tips and Tricks

Instant Run is controlled by Android Studio, so only start / restart your debug instance from the IDE — don’t start / restart your app from the device or things will get out of whack quickly.

A more detailed list of tips and tricks is available from the Android Documentation, but here’s a few bullet points to keep in mind.

• Tweak the resources you’re allocating to the Gradle process. If you have at least 2 gig assigned to the Gradle Daemon JVM via the jvmargs setting in the gradle.properties file, dex-in-process will be enabled, and will dramatically improve the speed of all builds — Instant Run and full / clean builds. You’ll want to experiment and observe the effect on your build times to find the value for you.
• The availability of ART in Android 21 means you’ll get the most out of Instant Run by setting your minSdkVersion to 21 or higher. You can create a new product flavor specifically for debugging that sets your minSDK to 21.
• Remember that changes to the manifest will trigger a full build and deploy cycle — so, if your build process automatically updates any part of the app manifest (for example automatically iterating versionCode or versionName) — you’ll want to disable that behavior in your debug build variants.
• Instant Run currently only instruments the main process, so if your app uses multiple processes, Hot and Warm swaps on the other processes will degrade to cold swaps — or full builds if you’re targeting an API Level less than 21.
• If you’re on Windows, Windows Defender Real-Time Protection might be causing Instant Run slowdowns. You can get around that by adding your project folder to the list of Windows Defender exclusions.
• As of this recording, Instant Run didn’t support the Jack compiler, Instrumentation Tests, or deploying to multiple devices simultaneously.

Instant Run is constantly evolving, with the team exploring new techniques to maximize the number of cases that allow for a hot swap, and minimizing the need for cold swaps or full builds.

For more Android Studio deep dives, protips, and release announcements Subscribe to Android Developers on YouTube, and tune in to Android Tool Time.

Источник

Bannikherafarm

Adrian Mitchell | Главный редактор | E-mail

Android Studio 2.0: мгновенный запуск

Сегодня я обновил свою Android Studio и запустил приложение, которое существовало с предыдущей версией. Когда я запускал приложение с предыдущей версией, приложение запускалось очень быстро, но когда я обновил студию Android и запустил то же приложение с обновленной версией, приложение заняло слишком много Я поискал в Google эту проблему и обнаружил, что если включен мгновенный запуск, отключите его, поэтому я сделал то же самое, и приложение запустилось так же быстро, как и было.

Теперь мой вопрос-

1. Что такое мгновенный запуск? Какие достоинства и недостатки его использования?
2. Почему приложение запускается слишком долго, когда был включен мгновенный запуск, а когда я отключил его, то почему оно запускало приложение так быстро, как было.

• Прочтите эту официальную документацию
• @Shashanth, да, я прочитал это, но не получил желаемой информации, которую хочу знать.

Мгновенный запуск поставляется с последней версией Android Studio. Но в некоторых случаях при его использовании он подключен.

Что такое мгновенный запуск?

При обычной сборке и запуске весь APK-файл обновляется и загружается на устройство. Но при использовании мгновенного запуска в устройстве заменяется только обновленная деталь. Instant Run отправляет обновленный код и ресурсы на подключенное устройство или эмулятор путем выполнения горячая замена, теплый обмен, или же холодная замена. Он автоматически определяет тип свопа, который нужно выполнить, в зависимости от типа внесенного вами изменения.

Плюсы

Это может быть быстрее, чем обычная сборка. Но для этого требуется, чтобы приложение работало во время сборки ниже API 21.

Минусы

Серьезно ощутил проблему неизменной установки. То есть при использовании мгновенного запуска иногда кажется, что приложение не обновляется. Он остается в своей предыдущей сборке. И иногда мне казалось, что это медленнее, чем обычная сборка.

Горячая замена:

Это самый быстрый тип обмена, который делает изменения заметными намного быстрее. Ваше приложение продолжает работать, и при следующем вызове метода будет использоваться метод-заглушка с новой реализацией.

Теплый обмен:

Этот обмен по-прежнему выполняется очень быстро, но Instant Run должен перезапустить текущее действие, когда он отправляет измененные ресурсы в ваше приложение.

Холодная замена (уровень API 21 или выше):

Этот своп выполняется немного медленнее, потому что, хотя новый файл APK не требуется, Instant Run должен перезапускать все приложение, когда оно подталкивает изменения структурного кода.

Отключение мгновенного запуска: Файл => Настройки => Сборка, выполнение и развертывание => Мгновенный запуск => Снимите флажок включить мгновенный запуск для горячей замены

Видеть это документация.

• @DkThakur Может из-за холодной замены
• Это очищает мою первую точку, но не мою вторую точку, я все еще ищу свою вторую точку, и теперь я принимаю это как ответ, но помните, что это не ответ моего второго пункта. Если у кого-то есть ответ на мой второй пункт, оставьте комментарий.

Мгновенный запуск = инкрементная сборка + горячая, теплая или холодная замена

Без мгновенного запуска:

С мгновенным запуском:

Мгновенный запуск:

Это функция в Android Studio, которая использует магию для значительного сокращения времени сборки и развертывания для дополнительных изменений кода во время жизненного цикла кодирования / тестирования / отладки.

Это нормально и является частью Instant Run характерная черта. Теоретически последующие загрузки должны быть быстрее.

Вы должны попробовать повторно включить его и понаблюдать за последующими запусками, вы увидите результаты.

Instant Run позволяет вносить изменения в код без создания нового APK.

Источник

Instant Run Your Android App | Android Studio

Android Studio 2.3 and above has a feature called Instant Run which significantly reduces the time taken to update your app with code and resource changes. Once the app is deployed to a target device which is running Android 5.0 (API level 21) or higher, all you have to do is click on the button which says Apply Changes . This will push certain code and resource changes to your running app without building a new APK—and, in some cases, without even restarting the current activity.

Whenever, you want to push the changes and force your app to restart, the Run and Debug buttons are always there for you.

However, you may find that using the Apply Changes button provides a faster workflow for most incremental changes to your app.

Tip: You can also press Control + F10 (or Control + Command + R on Mac) to apply changes with Instant Run.

The Apply Changes action is available only when you meet the following conditions:

• Build your app using a debug build variant.
• Use Android plugin for Gradle version 2.3.0 or higher.
• Set minSdkVersion to 15 or higher in your app’s module-level build.gradle file.
• Deploy your app to a target device running Android 5.0 (API level 21) and higher.

Instant Run pushes your changes by performing a hot swap, warm swap, or cold swap—the type of swap it performs depends on the type of change you made. Instant Run automatically determines the best option to push your changes to the target device, when you click Apply Changes after making a code or resource change to your running app.

HOT SWAP
Code Change: Implementation of the code change for existing methods.
Apply Change Behavior: The fastest type of swap and makes changes visible much more quickly. Your application keeps running and a stub method with the new implementation is used the next time the method is called. Using apply change behavior type of swap the objects are not re-initialized in the running app. To see certain updates, we may need to restart the current activity, either by selecting Run > Restart Activity, or restart your app, by clicking Run (or Debug ). Android Studio default behavior is to restart the current activity after performing a hot swap. If we do not want this behavior, we can disable automatic activity restarts.

WARM SWAP
Code Change: Change or Remove an existing resource.
Apply Change Behavior: This swap is still very fast, but Instant Run must restart the current activity when it pushes the changed resources to your app. Your app keeps running, but a small flicker may appear on the screen as the activity restarts—this is normal.

COLD SWAP
Code Change:
Structural code changes, such as:

• Add, remove, or change:
  • an annotation
  • an instance field
  • a static field
  • a static method signature
  • an instance method signature
• Change which parent class the current class inherits from
• Change the list of implemented interfaces
• Change a class’s static initializer
• Reorder layout elements that use dynamic resource IDs

Apply Change Behavior: This swap is a bit slower because, although a new APK is not required, Instant Run must restart the whole app when it pushes structural code changes.

Disable automatic activity restart

When performing a hot swap, your app keeps running but Android Studio automatically restarts the current activity. To disable this default setting:

1. Open the Settings or Preferences dialog:
   • On Windows or Linux, select File >Settings from the menu bar.
   • On Mac OSX, select Android Studio >Preferences from the menu bar.
2. Navigate to Build, Execution, Deployment >Instant Run.
3. Uncheck the box next to Restart activity on code changes.

If automatic activity restart is disabled, you can manually restart the current activity from the menu bar by selecting Run > Restart Activity.

Источник