在古老的Android时代，基本上一个Activity就代表一个界面，所以开发不需要做选择，但随着技术的迭代与框架的完善，Fragment的使用成为主流，再进化为Jetpack的navigation。再到如今越来越火热的Compose。同是Android开发，可能选择的技术栈已经完全不一致了，所以入门学者也容易眼花缭乱。
纯 Activity 时代
Activity作为最基础的四大组件之一，使用相对简单：
在AndroidManifest注册通过startActivity或者startActivityForResult启动，现在也可以通过LauncherForActivityResult来启动通过finish结束Activity
其主要的问题就是需要在AndroidManifest中注册，开发过程中容易忘记。若需要做patch、插件化等功能，就必须搞一些HolderActivity预注册，也是相当麻烦的。
除此之外，它本身是一个很重的组件，启动一个Activity就会有跨进程的操作，比较耗时。除此之外，动画控制也不是那么的灵活。
Fragment 入场
Fragment原本是为了给平板使用的，最简单的例子就是列表-详情，手机端是列表界面点击进入详情界面，而平板则可以左侧列表，右侧详情。
但随着Fragment的发展，因为其灵活性，它反而成了界面开发的主角，造就了单Activity多Fragment架构。
单Activity多Fragment架构。Activity就是一个承载Fragment的容器，所有的界面由Fragment承载，由于Fragment的事务型启动很繁琐，所以官方又出品了Navigation库来解决这个问题。但Navigation库需要创建并注册Graph，也是一个繁琐的事情。
路由框架入场
Activity与Fragment/Navigation的启动新界面的方式各不相同，Navigation还有一个创建Graph的方式，代码编写极其繁琐，所以又诞生了统一接口的路由框架，其主要解决以下几个问题：
启动方式的大一统Navagation注册表的代码自动生成传参的大一统，Activity使用Intent添加参数，Fragment使用Bundle跨module的界面启动（模块化需求）
由于官方没有出品，所以就是由各个业务职能部门创建，诸如：ARouter、TheRouter、QMUI Scheme、Emo Scheme等库。
ARouter与TheRouter偏向于模块化。
而个人开发的QMUI Scheme与Emo Scheme则没有支持模块化，而是在多Activity多Page的支持上花费了很大工费。这里一个Page可以是Fragment也可以是Compose。
多Activity多Page架构是指我们可以使用多个Activity， 每个Activity都可以是多Page的存在， 具体是否要使用Activity， 则由开发根据业务逻辑决定。
QMUI Scheme支持了多Activty多Fragment架构。
Emo Scheme支持了多Activity多Compose架构。
这是二者的差异，在Emo Scheme开发时，我觉得Compose诞生后，Fragment就是一个积累的存在了，所以现在我就完全抛弃它了。
那为何要采取多Activity多Page呢？
可以根据业务逻辑更好的做数据复用。举个例子，注册流程，可能分成数个界面，最中收集到全部数据，我的做法是用一个RegActivity， 每一个环节用RegUserNamePage、RegAvatarPage等，数据放在RegActivity的ViewModel里供所有Page使用，就不用数据传来传去了。而注册成功后到新的Activity， 销毁RegActivity。某些场景用单独的Activity更舒服： 全屏。 如果会涉及全屏切换，那单独出一个Activity就更友好。因为我们设置全屏标志位是相对于Activity而言的。全屏界面跳转到非全屏界面，非全屏界面跳转全屏界面，如果用单Activity去维护，那是一件很痛苦的事情。需要用到Activity的launchMode的场景，例如播放器，需要singleTask之类的模式需要一次性销毁多个Page的情况，例如前面注册流程的例子，我注册过程中，用户可以返回到上一个Page， 但是当注册完成后，那就直接销毁RegActivity。 目前Compose里嵌套WebView，Navigation转场动画效果有点差，所以我是选择用Activity去承载。
总而言之，之所以把框架做得这么复杂，就是期望开发能够认真思考业务流程，要根据我们的业务流程认真的考虑我们该以什么样的容器去承载我们的界面更合适。选择正确，往往能取到事半功倍的效果。
目前而言，Emo Scheme是所有路由框架中对这一块中支持得最好的，具体使用方法可以前往官网了解。
最后
世上没有最好的架构，只有最适合自己的。UI往往是变动最频繁的业务，所以了解各个组件的优缺点，根据业务逻辑去选用最适合的，才是高效开发的捷径。不管怎样，都是有无数坑点的，趋利避害才是UI的归宿。UI最好的经验就是知道各个组件有什么坑点，如何避开。不然随便一个坑，就够开发加好一会儿班了。
文末
如果想要成为架构师或想突破20~30K薪资范畴，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。
如果你没有方向，这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》，帮大家将杂乱、零散、碎片化的知识进行体系化的整理，让大家系统而高效地掌握Android开发的各个知识点。
相对于我们平时看的碎片化内容，这份笔记的知识点更系统化，更容易理解和记忆，是严格按照知识体系编排的。
欢迎大家一键三连支持，若需要文中资料，直接扫描文末CSDN官方认证微信卡片免费领取↓↓↓
PS:群里还设有ChatGPT机器人，可以解答大家在工作上或者是技术上的问题
