1.哔哩哔哩基于Kotlin-Native 的深度工程化实践-张忻正.pdf

《1.哔哩哔哩基于Kotlin-Native 的深度工程化实践-张忻正.pdf》由会员分享，可在线阅读，更多相关《1.哔哩哔哩基于Kotlin-Native 的深度工程化实践-张忻正.pdf（33页珍藏版）》请在三个皮匠报告上搜索。

1、哔哩哔哩基于 Kotlin-Native 的深度工程化实践从“跨平台”到“融平台”蚂蚁终端体验科技大会/01/02/03背景Kotlin2.2.x的现状哔哩哔哩的解决方案 业界基于KMP的方案比较Closed World VS Open World黑盒产物交付CInterop双向互交互编译速度其他Kotlin项目分层切面刨析Kotlin/Native的模块化通过并行编译，榨干CPU成果/01背景业界基于KMP的方案比较Closed World VS Open World国内KMP技术象限腾讯积极拥抱开源生态，在各个KMP的层级开源，在相同层级也有不同定位的框架开源，也是公开唯一可以开箱即用的鸿

2、蒙KMP的Fork版本。其他各厂多采样类似腾讯的技术方案，基于JB.Kotlin/Compose 进行Fork开发。哔哩哔哩采取Open World的方式仅仅只apply了Kotlin Compiler试图进行多技术栈之间的融合。国内KMP生态阵营九宫格哔哩哔哩在选择守序（不魔改）的前提下，通过与Kotlin官方相背的路径通过自建设/组织完整KMP生态达成纳入Kotlin生态的目的。尊重技术一定有他的生命周期。版本不是一成不变的。开放世界有助激发研发的热情及碰撞，有助于软件工程多样化（注：多样化不代表更稳定）技术是有共性的，必然可以取己之长补他之短。Closed World技术生命周期短于软件

3、（产品）生命周期。专制简化管理，可集中力量办大事。有助简化软件工程复杂度（注：单一化也不代表更稳定）保护核心竞争力壁垒。图图Open WorldMonorepo&模块化（Modular）/02Kotlin2.2.x的现状黑盒产物交付CInterop双向互交互编译速度其他黑盒产物交付-加深团队隔阂常作中频繁的WAIT点会下上的持续产盾双向互交互-Kotlin call C看上去很美好，但是我们好像没有套可以在KGP知道哪些头件是需要被binding的机制双向互交互-C call Kotlin模块，应该依赖的是模块。模块依赖产物（配置）的话违反了模块的所有的例如SRP原则编译速度-并发度编译速度-

4、间接依赖变更传播叠加盒产物集成，这个依赖变更传播就是灾难！个典型的模块依赖树我们预期会导致C系rebuild的模块MISC1.Kotlin语义是超出ObjC的，在重载、命名空间上都会存在很多问题（特别是Interface）2.Kotlin-Native原缺省对ArkTs的NAPI binding能 3.Debug-Info的还原能导致的Code断点问题 4.KSP2的能缺失 5./03哔哩哔哩的解决方案 Kotlin项目分层切面刨析Kotlin/Native的模块化通过并行编译，榨干CPU成果Overview全研发命周期0效配置0阻塞点Preview Driven Development库组装

5、 编译平台标配置分离 功能特性配置分离（CInterop、KSP、.）0胶水/配置组装任意语言模块任意业务范围的APP/持续低成本更近新版本简化BUILD DSL以及模块化Kotlin研发体验Kotlin生态的分层实际实现中部分环节是优化减掉的，图示把路径还原只是便于理解基于Bazel组织Kotlin研发生态为什么要大费周章的去拆掉Gradle这层建设？我们必须创造个公平的互相之间没有的构建系统=我们得找个作为构建系统能最强的=我们得找个为了构建的语starlark=starlark前最好的实现就是Bazel模块化-iOS为每个Kotlin模块，编译仅仅属于他的kfun/objc adapte

6、r.o/objc.h模块化-Harmony通过kotlin-native实现napi_binding 从在KT/Native闭环模块化（implementation_deps）KotlinIR(KLIB)KSP ObjectHEADERimpl_deps Kotlin态对于间接依赖传播的容忍性模块化-原子产物的编译方式包管理（Prebuild）-Harmony在外挂态下，尽量优雅的，补充鸿蒙的平台实现Full View模块化、并发编译、98%Final Artifacts编译