咱们好我是黄林晴，也是图书《Android Jetpack开发：原了解析与应用实战》的作者。上一次在社区共享仍是在三年前的Android 11碰头会上，本次为咱们共享的主题是Compose Multiplatform和KMM。这儿是本次共享的文字版。
前语
上个月JetBrains 发布了 Compose Multiplatform for iOS Alpha 版别，这让许多热爱跨渠道的开发者喜不自禁。可是也有许多开发者或许还没有了解过Compose Multiplatform和KMM，那么本次共享将通过以下几点来介绍Compose Multiplatform 与KMM，让咱们一同体会Kotlin跨渠道的魅力。
- Compose Multiplatform 与 KMM的联系
- Compose Multiplatform 与 KMM的实践
- 开发者该怎么挑选
这儿需要先阐明的是，本次共享咱们只会从运用的视点去共享，作为一次跨渠道技能的普及，不会涉及跨渠道的底层原理，比方为什么能够跨渠道这些深奥的道理。为什么不讲这些呢？原因很复杂，简略的说便是我不会。
Compose Multiplatform 与 KMM的联系
要Compose Multiplatform 与 KMM的联系，咱们只要来别离了解Compose Multiplatform 与 KMM别离是什么就行了。
KMM是什么
KMM的全称是Kotlin Multiplatform Mobile，与之对应的是KMP—Kotlin Multiplatform Project，其实便是一个是Kotlin移动端跨渠道，一个是Kotlin跨渠道项目的集合。KMM更像是营销术语，咱们不必纠结Mobile这个词，你要知道的是，下文咱们所说的KMM便是指的Kotlin跨渠道不仅限于移动端就行了。
KMM能够简化多渠道应用程序的开发。通过KMM，开发者能够在 iOS 、 Android、Desktop与Web 应用程序之间共享事务逻辑的通用代码，在必要时也能够编写特定于渠道的代码。所以，KMM只担任跨渠道下的事务逻辑部分。
比方这张图中的数据层、网域层等都能够运用KMM来完结公共的事务逻辑。
在KMM前期推出来的时分，那个时分Compose Multiplatform还没有发布，所以咱们都觉KMM很鸡肋，由于90%的开发者认为移动端的主要工作都在编写UI上，跨渠道不能跨UI叫做哪门子的跨渠道？
可是，其实这种观点是不正确的，许多事务逻辑比方日志体系、埋点等事务运用KMM仍是十分有利的。
后来Compose Multiplatform的出现弥足了KMM的短板。那么Compose Multiplatform又是什么呢？
Compose Multiplatform是什么
Jetpack Compose是Android官方推出的声明式UI结构，Compose Multiplatform是由JetBrains保护的Compose跨渠道结构，专心于UI跨渠道，同样支撑iOS、Android、Web、Desktop等。
有了Compose跨渠道，便弥补了KMM的缺陷。
我一直觉得有一个为难的问题便是，要说Compose Multiplatform与KMM不是一个东西吧，他们的确不是一个东西，究竟版别的更新、保护者都不同。可是究竟Kotlin底层对Native、JS的支撑都是Compose Multiplatform的基础。所以我更希望有一天他们能够兼并，不管是版别的更新仍是插件的支撑都能够统一。所以我更喜欢直接称他们为Kotlin全渠道。
那么其实，你现在也现已知道了KMM与Compose Multiplatform的联系。接下来咱们来看Compose Multiplatform 与 KMM是怎么实践的。
Compose Multiplatform 与 KMM的实践
由于Compose Multiplatform 与 KMM一个复用UI一个复用事务逻辑，所以咱们别离来看是怎么实践的。
实践KMM
KMM用于完成事务逻辑部分，这儿咱们只以Android和iOS两头为例。这儿仍是要再次重申一下，Compose Multiplatform 与 KMM是能够独立运用的，也便是说在运用KMM的时分能够别离写Android、iOS的原生UI，在运用 Compose Multiplatform跨渠道的时分也能够别离完成其他端的事务逻辑。
创立项目
在Android Studio中咱们能够凭借Kotlin Multiplatform Mobile plugin插件来快速的创立支撑KMM的项目。
安装好插件后，翻开Android Studio咱们能够直接创立支撑KMM的项目。
创立的时分会让咱们填写模块的信息
创立好项目后，生成的项目目录结构是这个姿态的。
androidApp、iOSApp便是对应的Android、iOS各自的代码库，shared模块，即存放Android、iOS公共事务逻辑的部分。
KMM插件只为咱们创立了Android和iOS的源集，假如想创立其他渠道的能够自己创立文件夹然后指定目标渠道。
创立好项目之后咱们来看怎么处理公共的事务逻辑。
公共事务逻辑
双端彻底能够共用的逻辑咱们直接放在commonMain文件夹下即可。开源库的依托咱们写在commonMain目录下。
这儿增加网络恳求库Ktor和序列化的依托，由于是Kotlin跨渠道嘛，Ktor是Kotlin推出的网络恳求库，所以必定运用Ktor是最佳挑选。
这段代码呢，便是Ktor这个网络恳求结构的基本用法，咱们不做过多解释，在这儿咱们界说了一个getData办法，用于获取「鸿洋」大佬「wandroid」中的「每日一问数据」。
然后咱们各自在编写Android或者iOS的UI代码接纳数据即可。咱们这儿直接将回来展现展现在文本中，终究完成的程序是这个姿态的。
这个UI咱们将在后面的Compose Multiplatform 中完成。这样咱们就完成了双渠道一个简略的数据恳求的例子。
社区对KMM的支撑
目前官方许多库都现已支撑了跨渠道，比方咱们刚刚运用的网络恳求结构Ktor、依托注入Koin还有序列化组件等。
除此之外，对Android开发开发来说，最友爱的音讯是从上一年10月份开端Jetpack也开端支撑跨渠道了，不过其时Jetpack支撑的跨渠道组件只有三个：Annotations、Collections、DataStore。
当然还有一些比较有名的App也开源了一些组件比方Cash App开源了Paging分页库。
与AndroidX下的Paging设计相同，paging-common模块供给存储层、视图模型层；paging-runtim模块供给UI层。
最主要的是，paging-common中的API与AndroidX 下的API彻底相同，仅仅是将包从androidx.paging迁移到了app.cash.paging中，所以这部分的运用咱们直接依照AndroidX中的Paging运用即可。
可是在实践项目中，仅依托社区的支撑或许没办法满足一切事务。当然也有一些开源贡献者开源了一些组件，可是为了保证稳定性，咱们一般需要自己去单独完成各自的事务逻辑，那么咱们怎么保证运用同一套API呢？
expect与actual
咱们要依托Kotlin中的expect与actual关键字。expect是咱们期望完成的办法，actual是完成办法，有点相似接口与完成类。比方咱们现在要完成事务逻辑：翻开体系蓝牙。
首先咱们要在commonMain中运用expect界说这个接口
然后咱们在shares模块下的androidMain、iOSMain目录下各自完成翻开蓝牙的办法。
这样咱们就保证多渠道下运用同一API来调用，调用方不需要重视具体的完成。那么到这儿呢，KMM咱们就了解的差不多了，从上面的了解能够看出 其实KMM其时是能够运用在实践项目中的，不过咱们能够再等等，Kotlin的RoadMap中说本年会发布正式版别，咱们能够一同期待一下。接下来咱们再来一同实践Compose Multiplatform。
实践Compose Multiplatform
Compose Multiplatform 专心于UI复用，咱们前面提到过，有个为难的问题便是KMM与Compose Multiplatform 的版别和插件是不统一的。咱们能够凭借KMM插件在Android Studio中快速的创立KMM项目，可是其时假如咱们想快速创立Compose Multiplatform 项目只能凭借新版的IDEA。
创立项目
下载最新版别的IDEA，创立Compose Multiplatform项目，可是更为难的是，由于其时iOS还在alpha阶段，所以IDEA并不能创立iOS渠道的项目。
所以咱们咱们现在假如想运用Kotlin全渠道有两种办法：
- 运用IDEA创立项目，增加KMM依托装备
- 运用Andrioid Studio创立项目，增加Compose Multiplatform的装备
- 运用官方供给的模板项目
这儿我基于刚刚创立的KMM项目，在KMM的基础上增加Compose Multiplatform的装备。
项目装备好之后，咱们接着刚刚查询每日一问的功用来完成，当然在装备的时分必定踩了许多坑，这些我都记录在我的博客中了。
完成双端的网络数据显现
iOSApp.swift中的代码是这个姿态的。
Main_iosKt.MainViewController是通过新建在shared模块iOSMain目录下的main.ios.kt文件获取的，代码如下所示：
所以，咱们能够在shared模块中的commain目录下编写解析网络数据并现实的Compose办法，然后在Application下调用就行了。
这个代码咱们必定都能看懂，和Jetpack Compose是彻底一致的。通过Message办法将数据展现出来，这儿只将作者与标题内容显现出来，代码如下所示：
然后这样咱们就能够运转Android和iOS程序了，这儿要注意的是凭借KMM插件咱们能够直接运转iOS程序，可是有个前提便是依然要安装Xcode，Android和iOS作用如下图所示。
咱们能够看到页面作用是彻底一致的，并且就页面中这个功用来说，达到了事务逻辑和UI的百分之百复用。怎么样是不是泰酷辣！
Desktop与Web
咱们上面都是以Android和iOS为例，其实Desktop与Web端也是相同的，相对比来说我觉得Desktop现已比较成熟了，UI也是能够彻底复用Jetpack Compose。我又别离完成了Desktop与Web在此示例上的作用。
这儿对Web要多说一点，在前期的时分Compose for Web是运用Compose HTML来完成的，Compose HTML 是一个面向 Kotlin/JS 的库，它供给了用 HTML 和 CSS 创立 web 用户界面的 Composable 组件，所以分裂问题十分严重，不能说不能与Jetpack Compose复用，只能说和他毫无联系。
比方咱们完成图中的数据显现Compose HTML写法是这样的，其时看到这个是比较崩溃的。好在Kotlin在1.8.20版别中推出了Kotlin/Wasm，最新的Compose for Web 是基于Kotlin/Wasm的，其时处于试验阶段。页面能够彻底与Jetpack Compose复用，所以咱们注意一下Compose HTML的写法就不要再学习了。
官方给出了一些Compose Multiplatform的模版，也有Kotlin/Wasm的模板，可是唯一没有Compose Wasm for Web的模板，所以，我自己在github上开源了一个模板，感兴趣的咱们能够去运用。
和刚刚提到的组件问题相同，随着Compose Multiplatform技能的成熟，早晚官方会推出一个新的插件来一起支撑KMM和Compose Multiplatform。
与原生UI的互操作性
在运用Jetpack Compose开发Android的时分，有些场景下咱们或许需要让Jetpack Compose与XML 嵌套运用，那么在跨渠道中必定也会存在这种场景，在iOS中能够通过运用 UIKitView，在共享用户界面中嵌入复杂的特定于渠道的小部件，如地图、 Web 视图、媒体播放器和照相机等。
总之，这些必定都不会是阻止Compose Multiplatform跨渠道开展的要素。
开发者该怎么挑选
其时与Compose跨渠道竞赛的主要主力应该是Flutter，许多人总喜欢将他们进行比较，现在比较必定是Compose Multiplatform必定不如Flutter的，但这样比较也有点欺负Compose Multiplatform。究竟Compose Multiplatform还很年青。
当然这是一个十分敞开的话题，我只标明个人观点。Flutter永远都会存在语言壁垒的问题，可是KMM和Compose Multiplatform对Android开发者来说几乎是赠送的。当然了现在存在两拨人或许阻止他们运用KMM和Compose Multiplatform。
- 没有运用过Jetpack Compose
对于没有运用过Jetpack Compose的这部分人来说，其实我是能够彻底了解的，一些组件的支撑，比方地图、WebView等或许还需要必定的时刻，究竟现在运用XML是彻底没有问题的。还有一部分人呢是没有过Kotlin。
- 没有运用过Kotlin
扫除从事Farmework或偏低层的这部分人，其实我是彻底没有办法了解甚至是有些无语的。许多人告诉我的理由都是Java也能用啊、老板不让用啊、公司项目陈腐啊，其实这些放到现在都是借口了。
现已在运用Kotlin的，我建议能够学习下Jetpack Compose，一来这是一个趋势，二来它会扩展你的跨渠道技能。假如你想在未来几年内依然从事Android开发，我觉得是没有理由回绝的。
最终
最终，不破不立，这句话与咱们共勉。
好了。本次的共享到这儿就完毕了，咱们能够重视我的公众号《Android 技能圈》,我将持续共享跨渠道等Android领域的技能～，期待咱们下次再会！
