ART (Android Runtime) and Dalvik (units earlier than Android 5) are managed runtime environments that execute the DEX code of an software on Android units. Executing code in managed environments requires that the code has been verified. Verifying code will be delayed till runtime simply earlier than loading a category, which may have a adverse impression on runtime efficiency.
This weblog submit sheds mild on this subject and why you possibly can safely ignore it going ahead when utilizing R8 and D8, in the meantime having fun with that your app in all probability runs a bit quicker on older units. Our measurements present an enchancment between as much as 22 % on a Nexus 5X system working Api 23 on an actual world app.
Managed runtime environments on this context signifies that reminiscence is managed/abstracted such that objects will be created and rubbish collected dynamically, with out the developer worrying about allocation and deallocation. Managed additionally means direct indexing into reminiscence is prohibited not like native packages that run within the context of the working system.
To make sure that functions behave accurately and cling to the necessities of an ART/Dalvik VM, a verifier scans the code to make sure that packages are legitimate. Listed below are two examples of issues the verifier may discover:
1. an instruction makes an attempt to load register values exterior the scope of its technique
2. the code makes an attempt to create a brand new occasion of a category that doesn’t exist
The previous (1) is an instance of a tough verification error, and the latter (2) is an instance of a tender verification subject.
Earlier than diving into how D8 and R8 mitigates tender verification points we must always clearly describe the method of verification on system.
The DEX recordsdata that ship with an software will all the time be topic to verification earlier than the VM masses them. This occurs routinely when the appliance is put in or the primary time it runs on the system. Usually the verification course of occurs not directly by way of dex2oat — a program on the system that transforms DEX recordsdata into OAT recordsdata. You’ll be able to learn extra at Configuring ART | Android Open Supply Mission
The verifier traverses code bundled within the software. If a tough verification error happens the execution of the app is halted and output is pasted to logcat:
W/dalvikvm: VFY: dangerous arg 1 (into Lcom/instance/MainActivity;)
W/dalvikvm: VFY: rejecting name to Lcom/instance/MainActivity;foo(Lcom/instance/SomeClass;)V
W/dalvikvm: VFY: rejecting opcode 0x70 at 0x0004
…
The error may for instance be an invoke-virtual to a static technique. If a category has no errors will probably be marked as verified within the OAT file and the VM is aware of that it might probably load it immediately. Nonetheless, what occurs when the verifier can’t search for the focused class to see if a technique is digital or static?
The ART and Dalvik VM’s are class-path extendable that means that the definition of courses will be given at runtime. Consequently, the verifier can’t give a tough verification error primarily based on lacking references as a result of the references might be current when wanted. The verifier due to this fact delays the verification of a category with lacking references till runtime — that’s, simply earlier than the category is loaded by the VM — to see if it might probably go verification at that cut-off date. To point to the VM that this class must be runtime-verified it marks the category file to have standing RetryVerificationAtRuntime within the OAT file.
At this level you could be questioning why there are references to non-existing courses and strategies. The reason being that with each new Android model there are new APIs added. Older VMs won’t have these definitions on their boot classpath since they have been launched at a later time.
You’ll be able to examine your personal software for soft-verification points by pushing the APK to a tool (or an emulator) with an outdated API stage (for instance API stage 23) and run dex2oat with -verbose:verifier possibility set:
dex2oat - dex-file=/knowledge/app/com.google.firebase.quickstart.fcm-1/base.apk - oat-file=/knowledge/native/tmp/foo.oat - runtime-arg -verbose:verifier
All of the tender verification points are of the shape:
01–03 01:49:51.895 19821 19827 I dex2oat : Gentle verification failures in void com.instance.MainActivity.onCreate(android.os.Bundle)
You’ll in all probability be stunned what number of tender verification points seem. The verification runs on a class-by-class foundation and if a single technique or discipline fails verification with a tender verification error your entire class is marked for verification at runtime.
A chunk of code is value a hundreds phrases so let’s see an instance of a tender verification subject arising from a technique utilizing a guarded API name taken from the Firebase Cloud Messaging Quickstart venture:
class MainActivity : AppCompatActivity() {
...
override enjoyable onCreate(savedInstanceState: Bundle?) {
tremendous.onCreate(savedInstanceState)
val binding = ActivityMainBinding.inflate(layoutInflater)
setContentView(binding.root)if (Construct.VERSION.SDK_INT >= Construct.VERSION_CODES.O) {
// Create channel to indicate notifications.
val channelId = getString(R.string.default_notification_channel_id)
val channelName = getString(R.string.default_notification_channel_name)
val notificationManager = getSystemService(NotificationManager::class.java)
notificationManager?.createNotificationChannel(NotificationChannel(channelId,
channelName, NotificationManager.IMPORTANCE_LOW))
}
...
}
}
Within the onCreate operate there’s a conditional examine on the SDK_INT guarding that we don’t attempt to assemble a brand new notification channel object and invoke createNotificationChannel on the brand new occasion of NotificationManager since these APIs have been launched in API 26 (NotificationManager | Android Builders).
Putting in and executing the demo venture on an older system will present a warning:
dex2oat --dex-file=/knowledge/app/com.google.firebase.quickstart.fcm-1/base.apk --oat-file=/knowledge/native/tmp/foo.oat --runtime-arg -verbose:verifier 01-03 01:49:51.895 19821 19827 I dex2oat : Gentle verification failures in void com.google.firebase.quickstart.fcm.kotlin.MainActivity.onCreate(android.os.Bundle)
01-03 01:49:51.895 19821 19827 I dex2oat : void com.google.firebase.quickstart.fcm.kotlin.MainActivity.onCreate(android.os.Bundle): [0x47] could not discover technique android.app.NotificationManager.createNotificationChannel (Landroid/app/NotificationChannel;)V
The result’s due to this fact that MainActivity on units earlier than API stage 26 will delay verification of the category till it’s loaded. At that time it is going to fail to confirm so executing the code will probably be accomplished by decoding the code. Making an attempt to confirm after which executing the code by decoding it is going to decelerate efficiency.
Armed with the data above we are able to mitigate the efficiency penalty on older runtimes by shifting all directions concentrating on larger API ranges into different courses. This course of is named outlining (or out-of-line) and this strategy has been accomplished manually in each AndroidX and Chromium — see Class Verification Failures. The strategy is very simple and we principally simply create a static forwarding technique into the library taking the potential receiver and arguments and returning the returned worth from the library name.
Outlining the problematic directions permits verification and optimization of the courses that beforehand would have failed verification — by transferring the tender verification subject to the outlined code. If the outlined code is loaded by the VM at runtime, the penalty of verification will nonetheless happen. Outlining will due to this fact not take away the verification error, simply transfer it a layer out. As a result of the define is just invoked if the API is current (relying on the examine for SDK_INT being appropriate), the penalty won’t ever happen on older VMs as a result of the category containing the define will solely be loaded when the goal of the reference is current.
The code within the earlier part will generate two outlines. One for creating a brand new occasion of the NotificationChannel, and one for calling createNotificationChannel on the notificationManager:
.line 44
invoke-static {v0, v1, v3}, Landroidx/core/app/NotificationCompat$$ExternalSyntheticApiModelOutline0;->m(Ljava/lang/String;Ljava/lang/CharSequence;I)Landroid/app/NotificationChannel;move-result-object v0
invoke-static {v2, v0}, Landroidx/core/app/NotificationCompat$$ExternalSyntheticApiModelOutline1;->m(Landroid/app/NotificationManager;Landroid/app/NotificationChannel;)V
As a consequence, working dex2oat once more on the code will present that we have now certainly moved the tender verification errors to the outlines.
01-03 01:56:33.897 20311 20314 I dex2oat : Gentle verification failures in void androidx.core.app.NotificationCompat$$ExternalSyntheticApiModelOutline0.m(java.lang.String, java.lang.CharSequence, int)
01-03 01:56:33.897 20311 20314 I dex2oat : void androidx.core.app.NotificationCompat$$ExternalSyntheticApiModelOutline1.m(android.app.NotificationManager, android.app.NotificationChannel): [0x0] could not discover technique android.app.NotificationManager.createNotificationChannel (Landroid/app/NotificationChannel;)V
Outlining, as accomplished above, will transfer a number of tender verification points to non-visited code at runtime however there are instances the place outlining will not be enough to mitigate soft- and exhausting verification points. Utilizing unknown courses in exception handlers will trigger a tough verification error. Think about the next code:
attempt {
callPrivateMethod()
tryLogin()
} catch (android.app.AuthenticationRequiredException e) {
// deal with error
}
The exception class android.app.AuthenticationRequiredException was launched at API stage 26 and loading this class on an API stage 25 or much less system will trigger a tough verification error. Mitigating by outlining would require outlining your entire try-catch block which might be unimaginable if the code invokes any personal strategies.
To work round this subject one must do the next:
attempt {
callPrivateMethod()
tryLogin()
} catch (Exception e) {
If (e.getClass().getName().equals("android.app.AuthenticationRequiredException)") {
// deal with error
}
}
That is annoying to recollect and cumbersome to put in writing. R8 and D8 fixes this by creating small courses with the identical title for exceptions launched after the min-API stage. The category is just like the supply code under:
package deal android.app;public class AuthenticationRequiredException extends Exception {
static {
throw new NoClassDefFoundError();
}
}
We name such a category a stub since it’s not doing something. Utilizing this trick will allow builders to put in writing idiomatic try-catch code. On units the place the category is current, the category definition on the bootclasspath will take priority and be loaded. On older units the presence of the stub will permit verification to succeed. Accessing the stubbed class will throw an error on initialization. R8 and D8 may also stub library super-types of program courses if launched on later api ranges than min-API.
One caveat with this strategy is that direct lookup on courses for figuring out API stage may now trigger exceptions altering from java.lang.ClassNotFoundException to java.lang.NoClassDefFoundError. Nonetheless, we imagine that the good points in runtime efficiency far outweigh the adverse penalties when contemplating it’s suggested in opposition to utilizing exceptions to information API stage management circulation, and the unreliability of the exception kind that’s thrown when loading these courses on totally different Android VMs.
R8 is an optimizing compiler and to scale back the scale of the code R8 will each do inlining and sophistication merging. If R8 didn’t observe API ranges it may trigger tender verification points that have been manually outlined to be inlined once more. R8 began assigning API ranges to strategies — to forestall shifting tender verification points into code that might be executed at runtime — already in Android Studio Chipmunk (R8 model 3.3) to make sure higher efficiency stability. You’ll be able to learn extra about R8 at Shrink, obfuscate, and optimize your app | Android Builders.
We’ve examined api-modeling internally as effectively however for this weblog submit we’ve used an open supply and a demo venture to indicate the efficiency enhancements (and lack of efficiency regression).
No modifications have been made to the supply code of the app besides organising the venture in line with their particular person README’s. The messaging app was amended with the firebase json configuration and tivi was amended with trakt.television and TMDb keys.
Since api-modeling is baked into AGP we have now to manually allow/disable api-modeling to get dependable outcomes. To that finish we constructed two model of our compiler primarily based on model 8.0.19-dev:
Every of the above variations will be manually added to your venture by modifying the construct.gradle file:
pluginManagement {
buildscript {
repositories {
mavenCentral()
maven {
url = uri("https://storage.googleapis.com/r8-releases/uncooked/primary")
}
}
dependencies {
classpath("com.android.instruments:r8:<hash-from-above>")
}
}
}
The variations above ought to in all probability solely be used for benchmarking since these are canary variations and never official builds.
We then created the next apks for every venture:
- D8 with `Drive allow api-modeling for benchmark exams`
- D8 with `Disable api-modeling for benchmark exams`
- R8 with `Drive allow api-modeling for benchmark exams`
- R8 with `Disable api-modeling for benchmark exams`
We ran the apks on a Nexus 5X (api stage 23) and Pixel 2 system (api stage 26) and measured till the ActivityManager reported the primary exercise is displayed:
03-07 08:57:18.864 1184 1230 I ActivityManager: Displayed app.tivi/.residence.MainActivity: +281ms
We ran the experiments 5 instances with a calm down of 30 seconds from set up time to execution time to make sure the system wouldn’t overheat in the course of the experiments.
The common outcomes are within the tables under and all knowledge will be discovered right here:
The outcomes clearly present that enabling api outlining and stubbing has a major efficiency enchancment however the enchancment is particular person to every app relying on the usage of new apis. For Tivi, utilizing a D8 with api modeling has an enchancment on an api stage 23 system with 15 %. For R8 the advance is even greater percentage-wise when in comparison with no api modeling in any respect. When shifting to api stage 26 we see the enhancements deteriorate for D8 which is predicted for the reason that quantity of “new apis” are much less from an api stage 26 standpoint.
One other fascinating level is that utilizing R8 for compiling your app additionally provides a pleasant enchancment on the startup efficiency:
So should you actually care about startup efficiency you need to actually think about using R8.
Api modeling will trigger a rise in code measurement since D8 and R8 in comparison with no modeling. The desk under reveals the scale regressions in KB:
The rise is round 18 KB for D8 with modeling and round 10 KB for R8 with modeling. For each R8 and D8 the rise is lower than 0.3 %.
R8 has had api-modeling enabled for disallowing inlining and merging from Android Studio Electrical Eel (AGP 7.4 with R8 model 4.0) and enabled outlining and stubbing in Android Studio Flamingo (AGP 8.0 with R8 model 8.0).
D8 may have api-modeling with outlining and stubbing enabled from Android Studio Giraffe Beta (AGP 8.1 with D8 model 8.1).
It won’t be doable to show off api modeling in D8 and R8 going ahead. For many functions it is going to present a pleasant runtime efficiency on older units and subsequent to no penalty on newer units. Moreover, now that outlining has direct compiler help it permits AndroidX and different library builders to put in writing extra idiomatic code — and never use sources on handbook outlining.
When you discover errors or see vital runtime efficiency regressions we might be completely satisfied to listen to about them by creating a difficulty on our subject tracker.
