飛利浦是一家領先的健康技術公司，致力於改善人們的健康和生活質量，透過健康流程來實現更好的結果——從健康生活及預防，到診斷、治療及家庭護理。飛利浦目標是到2030年每年改善25億人的生活。
飛利浦擁有各種智慧家居護理和個人健康的網際網路產品，其應用程式適配了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中，很自然地使用帶有回撥引數的非同步方法來處理結果，例如：
而在Swift中，我們則習慣於在這種情況下使用completion handlers 。例如：
最後，對於Kotlin使用者，我們想提供一個帶有suspend關鍵字的API，以便他們可以能透過協程來呼叫。很快出現的一個問題是，API定義的多個方法簽名將在各個平臺上生成冗餘的資訊。例如，掛起函式已針對Java進行了轉換，但是在低於24(不相容Java 8語言特性)的Android SDK上，會生成了一個非常冗長的簽名且難以使用。為了解決所有面向語言的這種情況，我們在外部API上新增了Java，Kotlin和Swift指定簽名的功能。這些簽名透過自定義的runAsync包裝函式分裝了suspend變體，該函式為實現掛起指定了合適的CoroutineScope和Dispatcher。 @JvmSynthetic註解用於隱藏不相容的Java變體。
這讓我們能夠為每個原生平臺上提供方法簽名最自然的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門戶以找到有關跨平臺開發的更多資訊！