飞利浦案例研究: Building Connectivity with Kotlin Multiplatform

飞利浦是一家领先的健康技术公司,致力于改善人们的健康和生活质量,通过健康流程来实现更好的结果——从健康生活及预防,到诊断、治疗及家庭护理。飞利浦目标是到2030年每年改善25亿人的生活。

img

飞利浦拥有各种智能家居护理和个人健康的互联网产品,其应用程序适配了Android及iOS。一般情况下,这些产品通过低功耗蓝牙(Bluetooth Low Energy)或Wi-Fi在本地连接,同时还连接到Philips云以进行远程控制和数据分析。为此,Philips Innovation Services组织团队开发了一个互联互通平台,平台包括嵌入式硬件,固件,协议和用于创建移动应用程序的SDK。该互联互通SDK提供了用于发现,连接以及交互的组件。该SDK面向Android和iOS,而嵌入式Linux作为原生平台同样变得越来越重要。

飞利浦联网产品的移动应用安装基数

飞利浦联网产品的移动应用在App Store和Google Play上的安装总数超过100万。这些应用已在全球范围内被安装和使用,其中最大的市场是美国,欧洲和亚洲。

如何在产品中应用Kotlin Multiplatform Mobile?

我们SDK的组件之一是飞利浦云解决方案的客户端库:HealthSuite Digital Platform,简称HSDP。它让应用程序的开发人员可以轻松地与云基础架构进行交互,无需编写消息头以及数据复杂的HTTP请求。相反,开发人员可以调用高层级的函数,例如通过getBlob()来下载二进制文件,sendCommand()来远程控制与云连接的设备或createDataItem()来上传遥测数据。


访问Kotlin Multiplatform Mobile门户,使用Kotlin创建你的第一个跨平台应用程序!


使用Kotlin生成样板代码

所有HSDP的服务端均以OpenAPI(Swagger)YAML格式记录。通过这些定义,我们在构建过程中生成了大量的样板代码,以便能够与生产环境中的云服务“同步”。我们团队为流行的OpenAPI Generator创建了Kotlin代码生成模块,我们正在Github上为该模块做出贡献。我们由此生成的代码包括所有必要的数据传输对象和类,这些对象和类使用ktor进行HTTP请求/响应处理包装。这意味着我们可以专注于生成的代码编写业务逻辑,而不是浪费时间在基本的搭建上。当生产服务升级到新版本时,我们通过新的YAML文件为其重新生成代码,便能立即看到所做的变动。

为Java,Swift和Kotlin设计API

编写Kotlin Multiplatform SDK组件一个有趣的地方是API的设计。每种平台语言都有其自己的规范。例如,异步操作的处理方式略有不同。Java中,很自然地使用带有回调参数的异步方法来处理结果,例如:

img

而在Swift中,我们则习惯于在这种情况下使用completion handlers 。例如:

img

最后,对于Kotlin用户,我们想提供一个带有suspend关键字的API,以便他们可以能通过协程来调用。很快出现的一个问题是,API定义的多个方法签名将在各个平台上生成冗余的信息。例如,挂起函数已针对Java进行了转换,但是在低于24(不兼容Java 8语言特性)的Android SDK上,会生成了一个非常冗长的签名且难以使用。为了解决所有面向语言的这种情况,我们在外部API上添加了Java,Kotlin和Swift指定签名的功能。这些签名通过自定义的runAsync包装函数分装了suspend变体,该函数为实现挂起指定了合适的CoroutineScopeDispatcher@JvmSynthetic注解用于隐藏不兼容的Java变体。

img

这让我们能够为每个原生平台上提供方法签名最自然的API,同时将业务逻辑集中到一个实现上。

为什么选择Kotlin Multiplatform?

我们已经为Android和iOS构建SDK组件奋斗了一段时间,事实上没有任何代码得以在跨平台中重用,除了少量C代码,例如SSDP协议的实现。但是,由于很难在Java,Objective-C和C之间桥接,我们最终在每个平台上通过原生来重新实现了该协议。

这意味着当我们实现新功能时,开发团队也得分为两部分。 Kotlin Multiplatform的出现提供了一个难得的机会,不仅可以更快地实现新功能,而且还可以在Android和iOS开发人员之间进行更多的互动。

我们知道Kotlin Multiplatform仍在发展,但是能够一次编写,一次测试便能多端部署就足够吸引人了。

我们的经验

我们从这次经验中学到的一些东西是:

  • IDE(IntelliJ IDEA/Android Studio)中集成的Kotlin Multiplatform插件并非完美的,但是在每个发行版中,它都得到了改善。
  • 在代码重用和原生实现之间始终需要权衡取舍,但这对于每个跨平台解决方案都适用。你必须慎重考虑哪些类型的业务逻辑类似,哪些应该保持原生。
  • 在iOS上采用Kotlin/Native比在Android或JVM上使用它更难,尤其是IDE和调试方面。
  • 借助Kotlin Multiplatform,我们的开发团队能够更快地推出新功能,代码库更易于维护
  • Kotlin语言本身可以帮助我们以更少的精力编写更好的代码。
  • 我们已经看到,团队中Android和iOS开发人员之间的交互和知识共享有所增加。
  • 将生态系统留给社区可以让JetBrains专注于核心并发展得更快。

我们还计划纳入Linux端,因此将有很多机会来查看共享代码库是否有回报。对于考虑使用Kotlin Multiplatform的人,我的建议是查看代码库中不直接与特定平台的原生API或接口交互的部分。专注于平台之间有明显重叠的业务逻辑,因为这实际上是你可以获得最大收益的地方。

联系人

飞利浦创新服务部移动连接架构师Jeroen Brosens


访问Kotlin Multiplatform Mobile门户以找到有关跨平台开发的更多信息!

此条目发表在官方分类目录。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注