Reflection ve vývoji aplikací — co to je, mechanismy reflexe a jak je používat

Co je to Reflection?

Reflection — schopnost programu pozorovat a měnit vlastní strukturu a chování za běhu. V objektově orientovaných jazycích to znamená získávání objektů Class, Method, Field a Constructor, které představují prvky programu jako data dostupná pro čtení a volání.

Termín „reflection” byl zaveden v komunitě umělé inteligence v roce 1982 (Brian Cantwell Smith) a implementován v jazyce Smalltalk. V mobilním vývoji se reflection poprvé objevil v Java ME a Objective-C (1986, NextStep). Dnes má každá velká mobilní platforma své vlastní reflection API: Java/Kotlin pro Android, Objective-C Runtime pro iOS, Swift Mirror API pro Swift.

Mechanismus reflection je založen na metadatech, která kompilátor ukládá do bajtkódu nebo binárního souboru. Android ukládá úplné informace o třídách do souborů DEX, iOS — do segmentu __objc_classlist v Mach-O. Runtime tato metadata načte do paměti a poskytuje API pro jejich procházení.

Jak funguje Reflection v Javě a Kotlinu

Java Reflection API je postaveno kolem třídy java.lang.Class. Jakýkoli objekt v Javě lze převést na Class přes .getClass() nebo Class.forName(). Z Class se získávají všechny metody, pole, konstruktory, anotace a nadtřídy. Kotlin dědí Java reflection a přidává vlastní KClass, KFunction, KProperty z balíčku kotlin.reflect.

import kotlin.reflect.full.declaredMemberFunctions

data class User(
    val name: String,
    val email: String
)

fun inspectClass() {
    val kClass = User::class
    val properties = kClass.declaredMemberProperties
    val functions = kClass.declaredMemberFunctions

    properties.forEach { prop ->
        println("Vlastnost: ${prop.name}, typ: ${prop.returnType}")
    }
}

V tomto příkladu KClass poskytuje metadata data class User. declaredMemberProperties vrací seznam vlastností s jejich typy a gettery. Reflection v Kotlinu je úzce integrován s korutinami: KFunction podporuje modifikátor suspend, což umožňuje volat asynchronní metody přes reflection.

Java Reflection: Class, Method, Field

Java reflection pracuje s Class<?>, Method.setAccessible() a Field.get(). setAccessible(true) vypíná kontrolu přístupu Java language access control pro private prvky. Je to mocný, ale nebezpečný mechanismus: na Androidu od API 28 může volání setAccessible na skrytých systémových metodách způsobit InaccessibleObjectException.

// Java reflection: volání soukromé metody
Class clazz = Class.forName("com.example.MyClass");
Object instance = clazz.getDeclaredConstructor().newInstance();
Method method = clazz.getDeclaredMethod("privateMethod", String.class);
method.setAccessible(true);
method.invoke(instance, "reflection test");

Kód demonstruje Class.forName() — dynamické načítání třídy podle řetězcového názvu. To je základ pluginových architektur: třída může být ve fázi kompilace neznámá, ale v runtime načtena a spuštěna přes reflection. getDeclaredMethod(„privateMethod”, ...) najde metodu podle názvu a typů parametrů a invoke ji spustí.

Objective-C Runtime: alternativní model reflexe

Objective-C runtime poskytuje funkce class_copyMethodList, class_copyPropertyList, objc_getAssociatedObject. Na rozdíl od Javy Objective-C standardně neskrývá soukromé metody — runtime vidí všechny metody třídy. To vysvětluje, proč method swizzling funguje bez setAccessible: runtime nemá zapouzdření na úrovni metadat.

Použití Reflection v mobilním vývoji

Reflection se používá v klíčových knihovnách mobilního vývoje. Serializace JSON (Gson, Moshi, Kotlinx.serialization) získává vlastnosti objektu přes reflection a přiřazuje je ke klíčům JSON. Dependency injection (Dagger, Koin, Swinject) analyzuje konstruktory a pole pro automatické vkládání závislostí. ORM knihovny (Room, Realm) používají reflection k mapování tříd na tabulky databáze.

• Serializace — Gson čte deklarovaná pole objektu přes Field.get() a vytváří JSON podle anotací @SerializedName.
• Dependency Injection — Dagger generuje kód přes annotation processing, Koin používá Kotlin reflection pro řešení závislostí v runtime.
• Testování — JUnit najde metody s @Test přes reflection a volá je; Mockito vytváří mocky přes dynamic proxy.
• Databáze — Room kontroluje pole Entity přes Class.getDeclaredFields() ve fázi kompilace (přes KAPT/KSP).
• Analytika a monitoring — Firebase Crashlytics získává stack trace přes Throwable.getStackTrace(), založený na reflection.

Každé z těchto použití funguje právě v runtime — kód předem neví, s jakými třídami se setká. Reflection poskytuje univerzální mechanismus pro překonání této neznámé za cenu výkonu a bezpečnosti.

Výkon Reflection: cena dynamického přístupu

Reflection je 10–100krát pomalejší než přímé volání metod. Důvod — chybějící optimalizace JIT (devirtualization, inlining), kontrola typů při každém volání a balení parametrů do Object[]/varargs. ART na Androidu 14 nemůže inline-optimalizovat reflection volání, protože cílová metoda je neznámá až do okamžiku provedení.

Data byla získána na Google Pixel 8 (Android 14, ART). Výkon reflection se s každou verzí Androidu zlepšuje: na Androidu 9 bylo volání přes Method.invoke() 150krát pomalejší než přímé, na Androidu 14 — 40krát. ART používá vestavěné mechanismy method handle pro optimalizaci.

Pro kritické úseky z hlediska výkonu vývojáři nahrazují reflection kódogenerací: Dagger používá annotation processing místo hledání v runtime, Kotlinx.serialization generuje serializátory přes KSP, Moshi přizpůsobuje @JsonClass(generateAdapter = true) pro codegen ve fázi kompilace.

Alternativy k Reflection: anotace a code generation

Annotation processing (KAPT, KSP) a code generation — hlavní alternativy k reflection v mobilním vývoji. Přesouvají analýzu metadat z runtime do compile time: kód se generuje před spuštěním aplikace, což eliminuje režii reflection a zlepšuje výkon.

// KSP: code generation místo reflection
@Serializable
data class Config(
    val apiUrl: String,
    val timeout: Int
)

// KSP generuje ConfigSerializer bez reflection
fun loadConfig(json: String): Config {
    return Config.serializer().decodeFromString(json)
}

V tomto příkladu je @Serializable anotace Kotlinx.serialization. KSP (Kotlin Symbol Processing) analyzuje zdrojový kód ve fázi kompilace, najde všechny třídy @Serializable a generuje serializátory. Během provádění aplikace se reflection nepoužívá — serializátor je již zkompilován do strojového kódu.

Porovnání přístupů

Code generation poskytuje lepší výkon, typovou bezpečnost a menší velikost binárního souboru (dead code elimination odstraňuje nepoužívané reflection závislosti). Reflection zůstává nezbytný pro úlohy, kde jsou typy neznámé ve fázi kompilace: dynamické načítání pluginů, runtime-proxy, instrumentace testů. Podle Kotlinu je Kotlinx.serialization s KSP 3–5krát rychlejší než Gson založený na reflection.

Omezení Reflection na Androidu a iOS

Reflection na mobilních platformách má bezpečnostní a výkonnostní omezení. Android od API 28 (Pie) omezuje setAccessible pro non-SDK rozhraní — pokus o otevření skryté systémové metody vede k výjimce nebo varování. iOS se Swiftem nepodporuje reflection v klasickém smyslu: Swift Mirror API poskytuje pouze čtení vlastností (name, value) bez úprav nebo volání metod.

Google Play odmítá aplikace používající reflection k obcházení omezení platformy: náhrada systémových služeb, modifikace politik SELinux, čtení chráněných oprávnění. Apple také blokuje aplikace volající privátní API přes reflection — kontrola App Review skenuje binární soubor na řetězcové signatury objc_msgSend se známými privátními selektory.

ProGuard/R8 — další omezení. Obfuskace a minifikace kódu přejmenovává třídy a metody na krátké názvy (a, b, c). Pokud kód používá Class.forName(„com.example.MyClass”), po obfuskaci se rozbije. Řešení — keep pravidla v proguard-rules.pro:

// ProGuard keep pravidla pro reflection
-keep class com.example.** { *; }
-keep class * implements java.io.Serializable { *; }
-keepclassmembers class * {
    @com.google.gson.annotations.SerializedName ;
}
-keepattributes Signature, InnerClasses, EnclosingMethod

Pravidla -keep informují R8, aby nepřejmenovával třídy používané přes reflection. Bez těchto pravidel obfuskovaná aplikace spadne s ClassNotFoundException — runtime nenajde třídu podle řetězcového názvu, který se změnil.