Netflix技术博客 译者
核子可乐 策划
田晓旭
过去几年以来，Netflix一直在开发Prodicle移动应用，借此在电视节目与电影制作领域推进创新。时至今日，实体生产的具体方式可谓日新月异，不同国家、地区甚至是不同生产体系之间都存在着巨大的方法与需求层面的差异。工作性质的变化，意味着我们需要在分布式环境中的设备上开发出高写入强度软件，其中约三分之一用户的网络连接条件并不稳定，容错能力也相当有限。作为一支小型工程团队，我们意识到必须对可靠性及产品交付速度进行优化，才能满足不断变化的客户需求。
由于网络连接的可靠性不高，因此我们更倾向于推出移动解决方案，借此实现强大的客户端持久性与脱机支持能力。为了快速交付产品，我们决定使用一套多平台架构。现在，我们使用KotlinMultiplatform编写平台中立性业务逻辑，并通过Kotlin/Native将其编译为分别面向Android的Kotlin库与面向iOS的原生通用框架。
KotlinMultiplatformKotlinMultiplatform允许我们在iOS与Android应用程序的业务逻辑中使用同一套代码库。您只需在必要时编写特定于平台的代码即可，例如实现原生UI或者使用特定于平台的API时。
KotlinMultiplatform与以往各类知名跨平台移动开发技术有所区别。其它技术主要以抽象化或者全面取代平台特定开发方法作为主要诉求，并致力于替换掉一切特定平台应用开发方兴未艾。与之相反，KotlinMultiplatform是对当前平台特定技术的补充，致力于替代各类平台中立性业务逻辑。换言之，KotlinMultiplatform的诉求在于为解决方案库带来新工具，而非取代整个解决方案库。
事实证明，新方案效果不错，具体表现为：
我们的Android与iOSstudio应用获得了共享架构，且能够在两套平台上编写相似甚至完全相同的业务逻辑。
在我们的Android与iOS应用当中，近50%的生产代码与底层平台保持解耦。
我们能够灵活探索不同平台（AndroidJetpackCompose、SwiftUI等）上提供的最新技术，再无任何后顾之忧。
那么，我们是如何使用KotlinMultiplatform的？
体验管理如前所述，用户在不同产品中的实际需求存在巨大差异。具体而言，这些差异将转化为大量应用程序配置，要求我们切换可用功能并优化每款产品的应用内体验。而将应用当中负责管理这些配置的代码解耦出来，将有助于降低应用程序的复杂性。我们对代码共享的首次探索，是为内部体验管理工具Hendrix建立移动SDK。
Hendrix的核心是一自足简单的解释语言，用于表示如何计算配置值。这些表达式将配合当前应用会话上下文进行评估，并能够访问A/B测试分配、位置、设备属性等数据。在我们的用例中，具体配置范围包括生产可用性、版本以及特定区域应用功能集等。
糟糕的网络连接以及用户活动响应配置中的频繁值变更，意味着我们有必要将规则评估从服务器端迁移至更灵活的用户设备端。
为此，我们需要构建轻量化Hendrix移动SDK——在这方面，KotlinMultiplatform凭借着强大的业务逻辑与全面的平台中立性脱颖而出。
实现为了简便起见，这里我们不再介绍Hendrix中的特定细节，主要讲解使用KotlinMultiplatform替代Kotlin/Swift中的一些差异。
构建对于Android，一切照常运行，不受太多影响。HendrixMultiplatformSDK通过gradle以Android库项目依赖项的形式进行导入。而在iOS方面，原生二进制文件将作为通用框架被包含在Xcode项目当中。
面向开发者的人体工程学KotlinMultiplatform源代码可以进行编辑、重新编译，并能够在AndroidStudio与Xcode中配合一款带有断点的调试器（包括lldb支持）。AndroidStudio可实现开箱即用，在Xcode中则需要通过TouchLabs的xcode-kotlin插件使用。
通过Xcode调试Kotlin源代码
网络Hendrix解释规则集（即远程可配置文件）已被下载至设备。这里我们使用Ktor的MultiplatformHttpClient将网络代码嵌入至SDK当中。
磁盘缓存当然，有时候网络连接的可用性将无法保证，因此需要将下载的规则集缓存到磁盘当中。为此，我们使用SQLDelight及其Android与原生数据库驱动程序实现Multiplatform的持久存储。
总结过去几年以来，我们一直密切