Kotlin开发Android原生项目必须用Jetpack Compose吗？用XML是否可行

• 不存在“所有Kotlin编写的Android原生项目必须用Jetpack Compose”的强制要求，继续用传统XML布局做开发完全合规、完全可行，至今仍是官方正式支持的开发方案，没有任何合规性风险。
• Compose和XML是两个并行支持的UI技术路线，选哪个完全看项目实际场景，没有绝对的对错。

• 从零启动的全新项目，团队Kotlin基础扎实，没有历史UI包袱：Compose的声明式写法能砍掉大量视图绑定的样板代码，和协程、Flow的状态联动逻辑非常顺畅，写复杂动画、自定义绘制的代码量比XML少一大截，长期迭代的效率优势很明显。
• 项目需要快速跟进Material You动态配色、多端UI复用等新需求：现在Google官方新出的UI组件、特性更新，第一适配优先级都是Compose，XML侧的新特性跟进节奏确实相对更慢。

• 已经迭代多年的存量成熟项目：这类项目一般都积累了大量成熟的XML自定义控件、业务UI组件库、屏幕适配逻辑，要是硬把现有全量页面改成Compose，投入的时间成本极高，还容易平白引入适配bug，完全可以老页面继续保留XML，新增页面按需评估要不要混写就行。
• 团队没有Compose技术储备、项目排期紧张：Compose有不算低的学习门槛，刚上手的时候很容易踩不必要重组、状态管理混乱的性能坑，要是没提前做技术预研就硬上，反而会拖慢开发节奏。
• 项目重度依赖大量未提供Compose适配的老旧第三方UI库，没必要为了追技术热点花额外成本重构依赖。

别信网上“XML已经被废弃”的不实说法：目前Android Studio仍然完整支持XML布局的预览、代码提示、Lint检查，整个View体系的API没有任何被标记为废弃的标识，每个Android大版本更新都会持续兼容View体系的渲染逻辑，未来很多年内XML都不会失去官方支持。

另外补充：Compose和XML从来不是互斥关系，你可以在XML布局里通过ComposeView嵌入Compose内容，也可以在Compose代码里通过AndroidView加载传统View控件，完全支持渐进式迁移，根本不需要搞非此即彼的一刀切。技术选型本质是为业务交付服务的，哪个方案能帮你更稳、更快做完需求，就选哪个，完全没必要有“用XML就是技术落后”的焦虑。

内容的提问来源于stack exchange，提问作者ade bayu s