使用那种方式集成
先使用kmp 统一 一部分业务逻辑，后期慢慢统一全部业务逻辑。
根据Compose Multiplatform 的发展进度再决定UI层是否统一。
所以目前业务集成的方式如下图所示。
为什么选用这种集成方式。
由于工程代码比较多有些代码比较久，有些基础库代码使用kmm集成会有未知的坑。所以先使用kmm统一部分逻辑。为什么UI层面不使用CMP统一，因为目前我们UI 使用自定义的控件比较多，外加CMP 在ios 平台中还处于alpha版本，所以UI层面全部使用原生控件也有更好的性能。
在双端的集成使用
工具和版本配置
Android stuio
建议Android studio 使用最新的版本 我目前使用的版本是 Android Studio Iguana | 2023.2.1 Beta 2。
Plugin
在Android studio 设置页面 plugins 中marketplace 中搜索Kotlin Multiplatform Mobile 然后点击下载安装。
在install 页面查看Kotlin plugin 是否安装，如果没有安装需要安装Kotlin plugin 组件。
Xcode
建议安装当前系统支持的最新版本。
JDK
目前我安装的是jdk 17，建议使用这个版本。
Cocoapods
分为几个步骤
安装Homebrew
安装Ruby ，我目前安装的版本。ruby 可能会有utf-8的问题，网上搜一下配置一下环境变量解决。
最后安装 Cocoapods。
Kdoctor
前面几步配置好了，使用Homebrew 安装Kdoctor。
Kdoctor 是配置环境检测工具。运行Kdoctor 最终显示如下。
如果都显示的是绿色的对号，证明环境配置已经没有问题了。
创建KMM工程
不要使用 Kotlin Multiplatform wizard 这个网站创建工程，直接使用Android studio 创建工程。
在创建工程时配置 ios时依赖选择 cocoapods dependency manager。
为什么使用这个选项？
我们ios项目中使用的库绝大部分是用pod来进行管理的。如果我们需要使用这些库，需要依pod的方式添加进来。
最终工程结构
最终工程目录如上所示。
我们所有的业务逻辑都写在shared 目录。commonMain 目录写Android 和 ios 平台无关的业务代码，只能使用kotlin 语言实现。androidMain 目录写平台相关代码，kotlin 语言 java 语言都可以实现，不过还是建议kotlin语言。
iosMain目录写平台相关代码 使用kotlin 语言，不可以使用java语言。
androidApp目录
壳工程 应用程序的入口，用于调试调用shared工程的代码。
iosAPP目录
壳工程 应用程序的入口，用于调试调用shared工程的代码。
commonMain目录
写通用的业务逻辑，不涉及平台相关的代码。
androidMain目录
写commonMain 里面具体涉及到Android平台API的实现。
iosMain目录
写commonMain 里面具体涉及到iOS平台API的实现。
关于gradle 和工程配置问题
此处是关于 kotlin 版本和 agp 版本 gradle 版本配置问题。
gradle 版本
其他配置
如果新建的项目不能正常运行，可以参考我配置的版本，我这边本地可以正常运行。
引入和使用三方库
通过以上的配置我们的工程可以正常在Android 手机和ios 手机上跑起来了。
如果要依赖三方库，我们还需要一些配置。我们根据不同三方库的类型来分别讲解。
已经适配完成的跨端库
这种类型的库已经完成了跨端适配，只需要在commonMain 里添加依赖就可以。
成功引入第三方库后我们就可以在commonMain目录的代码里使用这个库了，其他目录里无法使用。
Android和iOS原生的三方库
这种类型的库就是原生开发最常用的库，没有进行跨端适配。所以不能在commonMain中引入，只能分平台引入。
Android 引入
在androidMain 中进行配置就可以。
成功引入第三方库后我们就可以在androidMain 目录的代码里使用这个库了，其他目录里无法使用。
iOS 引入
由于我们创建工程时ios 依赖配置是由cocoapods 管理，所以引入依赖文件也需要在cocoapods 里配置。
pod 依赖方式按照以上方式进行依赖，如果需要更多的依赖方式参考示例 github.com/Kotlin/kmm-...
成功引入第三方库后我们就可以在iosMain 目录的代码里使用这个库了，其他目录里无法使用。
注意我们引入的是ios的原生库，但在iosMain目录代码里我们是依kotlin代码的方式使用的ios原生库。
具体是怎么实现的可以参考 kotlinlang.org/docs/native...
proandroiddev.com/kotlin-nati...
使用引入的三方库
androidMain 代码直接使用就可以，正常的导入包。
iosMain 代码因为使用的C interop 工具转入的，所以按照一下方式导包。
业务出包集成到原生工程中
经过以上的配置我们已经可以正常开发业务需求了。但是我们的目的是使用这个工程给Android 和 iOS 原生工程出依赖包。
Android 端出依赖包
执行shared 下的gradle task，正常出包就行。
注意出的包只包含 commonMain 中的依赖，不包含androidMain中的依赖，所以如果在原生工程中使用依赖的包需要把androidMain中的依赖添加到原生工程中。
iOS端出依赖包
执行shared 下的gradle task。
执行红圈的task 就行，不同选项对应的不同配置，可以按照自己的需求进行出包。
执行完后出的包在 shared/build/bin 目录下。
把shared.framework 目录整体拷贝到ios 工程目录下。
放到这个目录下。
注意shared.framework 目录下只包含commonMain 的代码和依赖，不包含上面提到的cocoapods 配置的依赖。
如果要在ios原生工程中使用这个framework，需要把cocoapods 配置的依赖也配置到原生工程中。不然会提示编译报错。
ios 原生工程可以直接使用我们导出库的逻辑。
结尾
至此，我们已经跑通了全部的业务逻辑。
虽然我们已经跑通了整体逻辑，但是如果cocoapods 有其他依赖的方式我们还需要探讨，还有工程化自动打包配置都需要考虑。更深入的部分可以参考一下链接。
kotlin.liying-cn.net/docs/refere...
kotlin.liying-cn.net/docs/refere...