KSP+Kotlin compiler plugin

Transcript

1. KSP and Plugins. Optimizing Kotlin Multiplatform common code Anna Zharkova Lead Mobile developer
2. Introduction • Mobile developer since 2013 • Lead Mobile developer in «Usetech software» . • Native mobile development, iOS and Android (Swift/Objective-C, Kotlin/Java) cross-platform mobile development (Xamarin, Kotlin multiplatform) • Leading mobile team. Mentorship • Public speaking (Mobius Moscow 2020, AppsLive 2020) • Tutor in Otus (iOS advanced) • Writing articles about mobile development (especially iOS and KMM ) • Women Techmaker Ambassador since 2021 • Kotlin GDE (2021) 2
3. Goals. Today discuss: • Kotlin Multiplatform and its conception. • Kotlin Symbol Processing, how it works. • Simplify Dependency Injection. Using KSP with common code • Kotlin compile plugins. Plugins vs KSP 3
4. Kotlin Multiplatform 4 • SDK, not framework • JVM for Android and LLVM for iOS • Total sharing (almost)
5. Every platform needs its Kotlin 5 Kotlin Common Kotlin JVM Kotlin JS Kotlin Native
6. Multiplatform – DI. Manual dependency solution 6 Mulitplatform DI core (KMM) Android Native app iOS Native app Shared module KMM Multiplatform-DI solution https://github.com/anioutkazharkova/kmm-di-sample https://github.com/anioutkazharkova/di-multiplatform-lib
7. DI Solution 7 DIContainer -> Resolver Scopes define the conditions DIContainer Resolver Scope Scope Scope Resolve Reference<T> -> T? <T> ReferenceReg<T> MainScopeHolder
8. Manual dependency solution 8 What we get in start https://github.com/anioutkazharkova/kmm-di- sample https://github.com/anioutkazharkova/di- multiplatform-lib
9. Optimize code 9 • Generate common code with KSP • Modify existed files with Compiler plugins
10. Begin from KSP 10
11. Kotlin Symbol Processing 11 First experimental release in 2020 Announced by Google in 10 Feb 2021 Compatible with Kotlin (since 1.4.30) Stable since 1.5.31
12. Kotlin Symbol Processing. Purpose 12 • Build lightweight Kotlin compiler plugins • Create annotation processors
13. Annotation processing. Purpose 13 • Analyze code • Generate common code for some purposes • Simplify abstractions and etc
14. KAPT (Kotlin annotation processing tool) 2/3 14 Kotlin KAPT AST for JAVA stub Javac Java classes JSR 269
15. KAPT vs KSP 15 • KAPT generates Java code • Kotlin compiler has to generate Java stubs before the compilation. • More time • More code
16. Why KSP better 16 PURE FASTER COMPATIBILITY Read Kotlin AST No stubs Support Java code
17. Kotlin symbol processing. How it works 17 Annotation Processor -> Symbol processor
18. Kotlin symbol processing. How it works 18 Provider should be declared as resource
19. Kotlin symbol processing. How it works 19 Resolver – to get data for specific case
20. Kotlin symbol processing. How it works 20 KSP uses reflection to get info about types and components.
21. Kotlin symbol processing. How it works 21 1. Processors read and analyze source programs and resources. 2. Processors generate code or other forms of output. 3. Generated code is compiled together with sources.
22. Kotlin poet 22 Kotlin and Java API for generating .kt source files https://square.github.io/kotlinpoet/
23. Kotlin Symbol Processing. Limitations 23 • Processors cannot modify existed code • Generates new files • Not enough documentation for different cases
24. Create our own annotation processing 24
25. KSP DI Solution 25 KSP Compiler depends on symbol-processing-api
26. Dealing with KSP in multiplatform 26 :ksp-di-compiler :ksp-di-shared
27. KSP DI Solution 27 KSP Compiler depends on symbol-processing-api
28. KSP DI Solution 28 Don’t forget Kotlin Poet
29. KSP DI Solution 29 DI Code Symbol Processor Scanners (Visitors) Code generator Generated_data.kt Found data Search request Found and processed data (tree)
30. Custom DI Symbol provider 30
31. KSP Resolver 31 We need to get annotated symbols to analyze them
32. Generate file with Kotlin Poet 32 That’s ok to use hardcoded string in template
33. Generate file with Kotlin Poet 33 Put all your stuff in template
34. Let’s build! 34 Sample compilation output
35. Generated DI solution 35 What we got as result https://github.com/anioutkazharkova/ksp-di- playground
36. Generated DI solution 36 What we got as result https://github.com/anioutkazharko va/ksp-di-playground
37. Use it with code 37 Connect and check https://github.com/anioutkazharkova/ks p-di-playground
38. Use it with code 38 Connect and check https://github.com/anioutkazharkova/ks p-di-playground
39. Kotlin symbol processing. Main challenges 39 • Generated files are not used by default • Not to much documentation for purposes
40. Kotlin Compiler Plugin 40
41. Kotlin compile plugin vs KSP 41 • Analyze Abstract Syntax Tree • Modify existing code • Could be also used in Kotlin/Native
42. Plugin structure 42 Kmm-di-inject-gradle InjectDIGradlePlugin Kmm-di-inject-plugin InjectDIComponentRegistrar Kmm-di-inject-plugin InjectDIIrGenerationExtension @Container @Single Kmm-di-inject-plugin ContainerGenerationExtension InjectTransformer ContainerClassLoweringPass @InjectService
43. Register component 43 Compiler uses IR as a backend
44. Register extension 44 Compiler uses IR as a backend
45. DI cases 45 1. Injection 2. Add to container
46. Injection. Manual 46 What we need to automate
47. Injection. Manual 47 How we want to use
48. Plugin structure 48 Kmm-di-inject-gradle InjectDIGradlePlugin Kmm-di-inject-plugin InjectDIComponentRegistrar Kmm-di-inject-plugin InjectDIIrGenerationExtension InjectTransformer @InjectService
49. Transform the function 49
50. Injection. Transformer 50
51. Injection. Declare useful types 51
52. Injection. New body. Lazy field 52
53. Injection. New body. Lazy field 53
54. Injection. New body. Lazy field 54
55. Injection. New body. Lazy field 55
56. Injection. New body. Lazy field 56 Not exactly what we need
57. Injection. New body. Lazy field 57 Call the methods of other class directly Note: we need to use an entry to class
58. Injection. New body. Lazy field 58 Call the methods of other class directly Note: we need to use an entry to class
59. Dispatch receiver 59 Dispatch receiver – the host of method or field function
60. Dispatch receiver 60 Dispatch receiver – the host of method or field function ConfigurationApp fun<T> resolve(t: String):T? Parent class Fun getter() Field
61. Injection. @InjectionService 61 Apply and check
62. Check the dex for result! 62
63. Сheck the dex 63 Dex data in build is available after compilation
64. Injection. @InjectionService 64 Apply and check
65. What to do next? Automate service registration 65
66. Register services at start 66 We still use manual registration
67. Add to container 67 Automate registration
68. Add to container. The begin 68 Simplify registration
69. Add to container. The begin 69 Simplify registration Add to Scope Type: String (class name) Fabric: () -> T (Lambda
70. Plugin structure 70 Kmm-di-inject-gradle InjectDIGradlePlugin Kmm-di-inject-plugin InjectDIComponentRegistrar Kmm-di-inject-plugin InjectDIIrGenerationExtension @Container @Single Kmm-di-inject-plugin ContainerGenerationExtension InjectTransformer ContainerClassLoweringPass @InjectService
71. Register one more component 71 Add a registration for container
72. And it extension 72 Every logic needs it extension
73. Add to container. Class lowering 73
74. Prepare body. Lambda... 74
75. Work with lambda seems to be tricky 75
76. Struggling with Lambda 76
77. Struggling with Lambda 77
78. Struggling with Lambda 78
79. Setup @Single 79 Add annotations
80. Setup @Container 80 Remove boilerplate
81. Сheck the dex 81 Dex data in build is available after compilation
82. Сheck the dex 82 Dex data in build is available after compilation
83. Сheck the dex 83 Dex data in build is available after compilation
84. Check it on action 84 Connect and check https://github.com/anioutkazharkova/k mm-di-plugin
85. Kotlin Compiler plugins. Pro and cos 85 + Modify existed files + Lightweight - Not enough documentation - Still be not stable and experimental
86. Summary. 86 • KSP is faster than KAPT, better performance • KSP is stable, but still be developed. • Support Kotlin/Native and multiple round in future • Plugins could be lightweight and more flexible with multiplatform • Lack of documentation for plugins. Need to use others samples
87. Sources 87 • https://github.com/anioutkazharkova/ksp-di-playground • https://github.com/google/ksp#kotlin-symbol-processing-api • https://github.com/anioutkazharkova/ksp-library-template • https://github.com/anioutkazharkova/kmm-di-plugin • https://github.com/SeongUgJung/KspSample • https://github.com/bnorm/kotlin-ir-plugin-template • https://blog.bnorm.dev/writing-your-second-compiler-plugin-part-5 • https://github.com/sergeshustoff/dikt
88. Thanks for listening! 88 @anioutkajarkova azharkova prettygeeknotes