本文为现代化 Android 开发系列文章第五篇。

完整目录为：

• 现代化 Android 开发：根底架构
• 现代化 Android 开发：数据类
• 现代化 Android 开发：逻辑层
• 现代化 Android 开发：组件化与模块化的挑选
• 现代化 Android 开发：多 Activity 多 Page 的 UI 架构（本文）
• 现代化 Android 开发：Jetpack Compose 最佳实践
• 现代化 Android 开发：功能监控

在古老的 Android 年代，基本上一个 Activity 就代表一个界面，所以开发不需求做挑选，但随着技术的迭代与结构的完善，Fragment 的运用成为主流，再进化为 Jetpack 的 navigation。再到如今越来越炽热的 Compose。同是 Android 开发，或许挑选的技术栈已经完全不一致了，所以入门学者也简略眼花缭乱。

纯 Activity 年代

Activity 作为最根底的四大组件之一，运用相对简略：

1. 在 AndroidManifest 注册
2. 经过 startActivity 或许 startActivityForResult 发动，现在也能够经过 LauncherForActivityResult 来发动
3. 经过 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 的方法，代码编写极端繁琐，所以又诞生了统一接口的路由结构，其主要解决以下几个问题：

1. 发动方法的大一统
2. Navagation 注册表的代码主动生成
3. 传参的大一统，Activity 运用 Intent添加参数， Fragment 运用 Bundle
4. 跨 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 呢？

1. 能够依据事务逻辑更好的做数据复用。举个比如，注册流程，或许分红数个界面，最中收集到全部数据，我的做法是用一个 RegActivity， 每一个环节用 RegUserNamePage、RegAvatarPage 等，数据放在 RegActivity 的 ViewModel 里供一切 Page 运用，就不必数据传来传去了。而注册成功后到新的 Activity， 毁掉 RegActivity。
2. 某些场景用单独的 Activity 更舒服：
   • 全屏。 假如会触及全屏切换，那单独出一个 Activity 就更友好。因为咱们设置全屏标志位是相对于 Activity 而言的。全屏界面跳转到非全屏界面，非全屏界面跳转全屏界面，假如用单 Activity 去保护，那是一件很苦楚的作业。
   • 需求用到 Activity 的 launchMode 的场景，例如播放器，需求 singleTask 之类的形式
   • 需求一次性毁掉多个 Page 的状况，例如前面注册流程的比如，我注册过程中，用户能够返回到上一个 Page， 可是当注册完成后，那就直接毁掉 RegActivity。
3. 现在 Compose 里嵌套 WebView，Navigation 转场动画作用有点差，所以我是挑选用 Activity 去承载。

总而言之，之所以把结构做得这么杂乱，便是希望开发能够仔细思考事务流程，要依据咱们的事务流程仔细的考虑咱们该以什么样的容器去承载咱们的界面更适宜。挑选正确，往往能取到事半功倍的作用。

现在而言，Emo Scheme 是一切路由结构中对这一块中支撑得最好的，详细运用方法能够前往官网了解。

之前也写过其作业原理的文章，可见 又撸了一个 Scheme 路由。

emo 本来的库房现在闭源了，新建了 emo-public 库房承载已开源的部分，以后计划开源的部分才会提交到这儿。

最后

世上没有最好的架构，只有最适合自己的。UI 往往是变动最频繁的事务，所以了解各个组件的优缺点，依据事务逻辑去选用最适合的，才是高效开发的捷径。不管怎样，都是有无数坑点的，趋利避害才是 UI 的归宿。UI 最好的经历便是知道各个组件有什么坑点，怎么避开。不然随便一个坑，就够开发加好一瞬间班了。