先看一张图
我们需要什么？
- Kotlin 开发工程师
- Android studio
版本>=4.1，并添加Kotlin Multiplatform Mobile插件 - Xcode
版本>=11.3（意味需要 macOS 环境）
跨平台开发姿势
官方推荐有三种不同的方法来组织团队在多平台库上的工作方式：
- Android团队实现了Android应用程序和Multiplatform模块，iOS开发人员直接使用。
- Android和iOS开发人员同时在Multiplatform库上工作。
- 分配了一个专门的团队来处理Multiplatform库，Android和iOS开发人员都将其用作黑匣子。
我觉得 1 比较适合，当然大公司 3 也适合，毕竟跨平台的共享模块是 kotlin 语言开发的。
目录结构
-
上帝视角
-
Android 视角
-
iOS 视角
Multiplatform共用模块在哪？
在我们的 shared 里面，当然这个名字是我自己起的，androidApp 和 iosApp 也是可以自己起。我们看看新建一个 KMM 工程是什么样子。
-
我们先要创建一个 KMM 工程，如图，如果你的 Android studio 没有 KMM Application 这个选项，请确保你的 Android studio 是添加了 KMM 插件，
这里就是最后一步了，不过值得注意的是，
这三个名字不能一致，否则你会发现你创建出来的工程，Android，iOS 和共享模块是空的~
Finish 就可以看到我们上述的文件界面了。
运行效果
KMM 的好处
兜底好，共享模块也可以使用所有iOS和Android功能，当无法让两端达成一致的情况下或希望使用特定的双端的功能时，比如图中的系统平台版本，都可以使用无缝的在KMM 模块写Android 或者 iOS特定的代码。
性能问题– 用Kotlin编写的共享代码针对不同的目标被编译成不同的输出格式：针对Android的Java bytecode 和iOS的native binaries文件。所以在各端上执行此代码的时候，没有额外的运行时开销，并且性能可与原生应用程序一样，实际上就是原生的！
在老项目兼容，无论项目有多大多劳，老代码不会影响集成KMM。我们可以随时开始编写 KMM代码，并将其作为依赖项 放到到iOS和Android 项目中，也可以使用 Android 已经编写的代码，只需对其进行修改下与iOS兼容一些问题。
小结
感觉还是不错的，而且和 flutter 和 RN 走的路线也不太一样。KMM 的当前的方式更多的是可以将一些逻辑层统一，比如 MVP 中的 M和 P 层，V 层还是可以让各端实现，当然如果强行在 KMM模块实现也是可以的。
但是现在 KMM 还不够成熟，也存在一些未知问题，不过我决定开始大胆在项目中使用。
