HASH GAME - Online Skill Game GET 300

　　Kotlin 与 Compose 是 Google 官方推荐的 Android 开发语言与 UI 框架，也是深受开发者喜爱的应用开发方案。与其他跨端方案相比，Kotlin Multiplatform 还具备高性能，与原生交互更灵活等优点。因此腾讯视频选择了 Compose Multiplatform 作为全跨端 App 的基础。当然，这套方案也存在不支持鸿蒙、iOS 平台混排能力受限、GC 性能表现一般等一系列问题，使得落地的过程充满了挑战。经过不懈努力，上述问题均已得到妥善解决，现在我们希望将这些解决方案开源，期待与全行业一同推动 Compose 跨端生态走向成熟。

　　本项目基于 Kotlin Multiplatform 技术，构建了一套跨平台原生资源管理解决方案，支持 Android、iOS 及 HarmonyOS 三大移动端平台。通过构建时同步生成类型安全的资源访问类（Resource Class），结合 Kotlin / Native（klib）/ Kotlin / Jvm（aar）的标准化资源封装机制，实现了多平台资源统一管理与编译器强校验，为开发者提供与 Android R 类相仿的资源调用体验。

　　屏蔽 Android / iOS / Harmony 系统平台差异，对外部统一提供常用的工具 api 集合作为业务开发的强力支撑。包括不限于 App 信息管理 (名称、版本号、安装时间、更新时间、包名等)、设备信息管理 (设备类型、品牌、制造商、系统版本、电池状态、亮度、内存信息等)、屏幕信息管理（宽度、高度、分辨率、是否亮屏、锁屏、屏幕旋转、状态栏、安全区域获取、全屏模式等）、传感器管理（重力、震动、陀螺仪、加速度）、前后台状态管理、音频及音频焦点管理、加解密管理 (3DES、RSA、AES)、字符编码（UTF-8、UTF-16、BASE64）、存储空间管理、网络状态监听、沙盒目录获取、监听分屏 / 浮窗等状态、图片保存相册能力。

　　kotlin 1.9 使用的 LLVM 11，kotlin 2.1 升级到 LLVM 16，但是鸿蒙平台能够支持的版本在 LLVM 12 ~ 15，苹果和鸿蒙都是基于公共版本的 LLVM 进行修改，增加了自己的特性优化，苹果相对好的点在于公共版本的 LLVM 中包含有苹果的 target，所以鸿蒙版本的 LLVM 既可以支持 iOS，又可以支持鸿蒙平台。（KukilyBase-Kotlin 当前基于 2.0.21 进行鸿蒙适配）

　　经技术架构分析，Compose Multiplatform 框架的协程调度机制深度依赖异常处理模型实现任务恢复与取消控制。其底层实现中，KN 运行时将异常处理桥接至 C++ 异常体系，该设计在运行时会产生显著性能损耗：当异常触发时，系统需沿调用栈进行逐级回溯以定位匹配的异常捕获点，其时间复杂度与调用栈深度呈正相关。更值得注意的是，该过程伴随大量 C++ 异常对象的动态构建与析构操作，频繁的内存分配与释放行为进一步加剧了执行时延，导致关键路径上的协程调度效率受限于异常处理机制的性能瓶颈。

　　在基于 UIKit 进行渲染的基础思路上，我们也发现了如 CALayer 重叠、未正确放置、无法复用等问题。对于 Android 来说，其是独立绘制架构，每个进程自己完成内容的绘制，所以画布是一整块，内容都绘制在其中，通过 Skia 的 PictureRecorder 命令录制功能进行命令的快速回放。但这种模式在 iOS 集中渲染架构上就不太适用了，需要有一个工具来进行差量处理绘制命令。所以我们设计了基于 iOS 的 PictureRecorder 局部更新架构。

　　我们优化的核心思路是，通过增量 hash 来减少 hash 的计算量。每一个 draw 函数执行的时候，都会对当前的 hash 和指令 id 进行一次合并。并计算出最终的 hash。这个 hash 记录了一次完整地使用。增量 hash 的目的是减少 diff 操作，这种方式可以有效地减少，两次指令相同的比较。在压力测试中还发现 OC 对象的创建和释放耗时也会被放大。这种情况在腾讯视频复杂页面回迁的过程中尤其明显，因此，这里还将原先由 OC 对象代表的指令，改为了非常简单的 C 结构体。之前的 OC 闭包也去掉了。