I’ve always wanted to write a detailed article on Kotlin reflection, but the problem is that Kotlin reflection isn’t as enjoyable as using Java reflection directly.

You ask me why? So let’s talk about it briefly.

The conclusion of this paper is based on Kotlin 1.1.51, and it is believed that the problems mentioned in this paper will be solved in future versions.

1 A 2.5-mb JAR package

While Java reflection is built directly into the Java standard library, Kotlin’s reflection needs to be introduced separately for the simple reason that the Kotlin reflection library is a whopping 2.5M long. Not to be confused, these 2.5m class files will eventually be packaged into your application, which is a concern if your application happens to be volume sensitive. For Android, let’s do a simple experiment and use the reflection library to compile the debug package as follows:

If there is no reflector pack, as follows:

We see that the download size of classes.dex varies by 0.6 MB, although it will be smaller if we mix it up.

Let’s look at the same project, which contains the size of the reflection package after simply referring to the member of a class (this is to confuse the reflection package so that it does not get removed) :

The obfuscated size without reflection packets is:

Although the overall volume of the mix-up is smaller, the impact of Kotlin’s reflector pack is not much smaller.

2 Unsupported built-in Kotlin Types

If you try to access a String with Kotlin reflection, you’ll see Boom, your code crashes. What’s going on here?


      
    
       
  1. String: :class.memberFunctions
    2. 
      
Copy the code

The error message clearly states that the built-in Kotlin type is currently not fully supported.


      
    
       
  1. Exception in thread "main" kotlin.reflect.jvm.internal.KotlinReflectionInternalError: 
    2. 
       
    3. 
       
  3. Reflection on built-in Kotlin types is not yet fully supported. 
    4. 
       
    5. 
       
  5. No metadata found for public open val length: 
    6. 
       
  6. kotlin.Int defined in kotlin.String[DeserializedPropertyDescriptor@1018bde2]
    7. 
      
Copy the code

  • So what are Kotlin’s built-in types?

    In Kotlin, there are a number of types that are not real but are compile-time mapped, such as numeric types such as kotlin.int, which are actually mapped to primitive and boxing types in Java virtual machine types; Collection types such as Kotlin.collections.set, mapped either through compilation or directly through type aliases, also correspond to collections frameworks in Java Virtual machine types. Such types can be considered Kotlin’s built-in types.

  • So since it is not fully supported, which types have the above problems?

    String, Map, Set, Array, and so on all trigger this problem.

  • How do you use reflection for these classes?

    Given the special nature of these classes, which are Java native types, Java reflection is recommended until Kotlin reflection is not fully supported.

3 haven’t had time to optimize performance

In the official Kotlin forum, I have seen some developers complain that the Kotlin reflection API takes longer than The Java reflection API, and the official developer replies that there is not much effort being put into performance optimization of the Kotlin reflection framework.

So just how slow is Kotlin’s reflection? Let’s compare the time it takes for Java reflection to access properties, modify properties, call methods, construct objects, and get generic parameters as mentioned earlier (for reference only) :

Unit: microsecond μs

Construct object To access attributes Modify the properties A method is called
Java reflection 12.7 25.2 12.2 18.8
Kotlin reflection 14938.0 85247.5 1316.7 326.3

The above data is running on my MacBook Pro. The results vary depending on the device, but we can see that Java reflection is generally at the μs level, while Kotlin reflection is generally at the MS level.

4 summary

Overall, Kotlin reflection is still in its infancy and should be used with caution at this stage, both in terms of volume and performance. Of course, this shouldn’t be a reason to reject Kotlin, since the Kotlin standard library is very mature and most developers don’t use reflection.

Welcome to Kotlin on wechat