Android 移动端发展的方向

1. Android应用层的开发早就趋于稳定，kotlin的出现，目前是在Java—>Kotlin的过渡时期，现在公司80%在使用Kotlin了吧（自己猜测的数据），但等全面替换还要经过一段时间。

2. 因为Android开发界面是XML的形式来完成，这也大大影响了开发的效率，因此谷歌这几年不懈余力在搞JatPack和Compose新一代界面工具包。

JatPack里面包含了很多经常使用的库，从而大大增加了android开发的效率，也包括对性能的一些提升、检测、提高的办法，使Android开发人员不再专注界面的内容，还要更注重性能的提升。

而Compose的工具包是声明式UI系统，不再使用繁琐的XML来完成界面的绘制了，速度大大提升，官方的控件基本已经满足了基本的日常开发需求，对modifier的熟练使用是提高开发的重点，Compose的到来也使得MVI的架构模式使用的越来越多，mvvm数据绑定更加方便便捷，基本可以提升几倍的开发效率。

当然Compose目前还存在一些问题，复杂列表的卡顿，不如RecyclerView流畅，网格和瀑布流的head还没有api等。不过最新的RecyclerView已经可以在Holder中使用Compose了，也是一个解决方案，xml和compose混合开发。

说了缺点，说一下优点，首先那肯定是开发速度快，使用modifier修改背景、颜色、边框、圆角等属性超级方便，动画运用简单，绘制也变的简单，ui抽取简单，更适合模块化开发，对话框、底部弹出窗等等都超方便。

当然Compose开发的进阶就是懂Compose的原理，尽量少的去recomposition，重新绘制太多会导致页面的卡顿，掉帧，检测recomposition的方法谷歌也有给出，使用打印日志的形式、还有就是用Layout Inspector的形式，最新的 Android Studio已经可以检测出recomposition的次数了，数据层使用viewModel和页面完美组合。

3. 再说说KMM(Kotlin Multiplatform Mobile)，kotlin的野心比较大，想一套UI跑全平台，目前的体验还远没有达到目标，现在可达的目标只是数据层面，UI还是要单独写，这样已经很强大了，2023年底不知是否可以发布正式版本，可以期待一下 一套代码统一天下的时候。我使用Compose开发了一个桌面程序，目前来看还没有对内存做优化，占用系统资源还是蛮高的。

4. flutter刚出来后就开始粗略学习了，并且做了一个wanAndroid的app，后面就搁置了，正是因为我想做一个剪切板桌面应用，用Compose来做的系统资源占用过多就放弃了这个方案，现在flutter已经支持全平台了，就使用flutter开发了一下剪切板，开发后运行资源占用和主流剪切板app差不多，所以突然对它感兴趣了。dev的第三方库也比较多，真的比较适合桌面的开发。没有深入使用，还不知道它有哪些缺点，总之它在跨平台目前还是比kmm有优势的，等kmm出正式版的时候可以再对比一波。

5. 目前移动端还是比较卷的，我已经卷到前端了，小程序 web，等KMM成熟了又可以卷一波IOS了，做程序员不易呀。大家加油