现代化 Android 开发:多 Activity 多 Page 的 UI 架构

简介: 本文为现代化 Android 开发系列文章第四篇。

在古老的 Android 时代,基本上一个 Activity 就代表一个界面,所以开发不需要做选择,但随着技术的迭代与框架的完善,Fragment 的使用成为主流,再进化为 Jetpacknavigation。再到如今越来越火热的 Compose。同是 Android 开发,可能选择的技术栈已经完全不一致了,所以入门学者也容易眼花缭乱。

纯 Activity 时代


Activity 作为最基础的四大组件之一,使用相对简单:

1.在 AndroidManifest 注册

2.通过 startActivity 或者 startActivityForResult 启动,现在也可以通过 LauncherForActivityResult 来启动

3.通过 finish 结束 Activity


其主要的问题就是需要在 AndroidManifest 中注册,开发过程中容易忘记。若需要做 patch、插件化等功能,就必须搞一些 HolderActivity 预注册,也是相当麻烦的。


除此之外,它本身是一个很重的组件,启动一个 Activity 就会有跨进程的操作,比较耗时。除此之外,动画控制也不是那么的灵活。

Fragment 入场


Fragment 原本是为了给平板使用的,最简单的例子就是列表-详情,手机端是列表界面点击进入详情界面,而平板则可以左侧列表,右侧详情。


但随着 Fragment 的发展,因为其灵活性,它反而成了界面开发的主角,造就了单 ActivityFragment 架构。


ActivityFragment 架构。 Activity 就是一个承载 Fragment 的容器,所有的界面由 Fragment 承载,由于 Fragment 的事务型启动很繁琐,所以官方又出品了 Navigation 库来解决这个问题。但 Navigation 库需要创建并注册 Graph,也是一个繁琐的事情。

路由框架入场


ActivityFragment/Navigation 的启动新界面的方式各不相同, Navigation 还有一个创建 Graph 的方式,代码编写极其繁琐,所以又诞生了统一接口的路由框架,其主要解决以下几个问题:

1.启动方式的大一统

2.Navagation 注册表的代码自动生成

3.传参的大一统,Activity 使用 Intent添加参数, Fragment 使用 Bundle

4.跨 module 的界面启动(模块化需求)


由于官方没有出品,所以就是由各个业务职能部门创建,诸如:ARouterTheRouterQMUI SchemeEmo Scheme 等库。

ARouterTheRouter 偏向于模块化。


而个人开发的 QMUI SchemeEmo Scheme 则没有支持模块化,而是在多 ActivityPage 的支持上花费了很大工费。这里一个 Page 可以是Fragment 也可以是 Compose


ActivityPage 架构是指我们可以使用多个 Activity, 每个 Activity 都可以是多 Page 的存在, 具体是否要使用 Activity, 则由开发根据业务逻辑决定。

QMUI Scheme 支持了多 ActivtyFragment 架构。

Emo Scheme 支持了多 ActivityCompose 架构。


这是二者的差异,在 Emo Scheme 开发时,我觉得 Compose 诞生后,Fragment 就是一个积累的存在了,所以现在我就完全抛弃它了。


那为何要采取多 ActivityPage 呢?

1.可以根据业务逻辑更好的做数据复用。举个例子,注册流程,可能分成数个界面,最中收集到全部数据,我的做法是用一个 RegActivity, 每一个环节用 RegUserNamePageRegAvatarPage 等,数据放在 RegActivityViewModel 里供所有 Page 使用,就不用数据传来传去了。而注册成功后到新的 Activity, 销毁 RegActivity

2.某些场景用单独的 Activity 更舒服:

  • 全屏。 如果会涉及全屏切换,那单独出一个 Activity 就更友好。因为我们设置全屏标志位是相对于 Activity 而言的。全屏界面跳转到非全屏界面,非全屏界面跳
  • 转全屏界面,如果用单 Activity 去维护,那是一件很痛苦的事情。

  • 需要用到 ActivitylaunchMode 的场景,例如播放器,需要 singleTask 之类的模式

  • 需要一次性销毁多个 Page 的情况,例如前面注册流程的例子,我注册过程中,用户可以返回到上一个 Page, 但是当注册完成后,那就直接销毁 RegActivity

3.目前 Compose 里嵌套 WebViewNavigation 转场动画效果有点差,所以我是选择用 Activity 去承载。


总而言之,之所以把框架做得这么复杂,就是期望开发能够认真思考业务流程,要根据我们的业务流程认真的考虑我们该以什么样的容器去承载我们的界面更合适。选择正确,往往能取到事半功倍的效果。


目前而言,Emo Scheme 是所有路由框架中对这一块中支持得最好的,具体使用方法可以前往官网了解。


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

emo 原本的仓库现在闭源了,新建了 emo-public 仓库承载已开源的部分,以后打算开源的部分才会提交到这里。

最后


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

目录
相关文章
|
1天前
|
Kubernetes API 数据库
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第17天】 随着云计算的普及和容器化技术的成熟,微服务架构已成为企业软件开发的首选模式。该架构通过将大型应用程序拆分为一系列小型、自治的服务来提供灵活性和可扩展性。本文将探讨微服务架构的关键概念,包括服务的细粒度划分、独立部署、以及如何通过容器编排实现高可用性。同时,我们将讨论微服务实施的最佳实践和面临的挑战,为后端开发者提供构建和维护微服务系统的实用指南。
|
1天前
|
前端开发 Android开发
Android架构组件JetPack之DataBinding玩转MVVM开发实战(四)
Android架构组件JetPack之DataBinding玩转MVVM开发实战(四)
Android架构组件JetPack之DataBinding玩转MVVM开发实战(四)
|
1天前
|
架构师 网络协议 算法
Android高级架构师整理面试经历发现?(大厂面经+学习笔记(1)
Android高级架构师整理面试经历发现?(大厂面经+学习笔记(1)
|
1天前
|
Android开发
Android Jetpack架构开发组件化应用实战,字节跳动+阿里+华为+腾讯等大厂Android面试题
Android Jetpack架构开发组件化应用实战,字节跳动+阿里+华为+腾讯等大厂Android面试题
|
1天前
|
敏捷开发 Kubernetes API
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第17天】 随着现代应用需求的多样化和复杂化,传统的单体应用架构逐渐显得笨重且难以适应快速变化。微服务架构应运而生,它通过将大型应用拆分为一系列小型、自治的服务来提供灵活性和可扩展性。本文将深入探讨微服务的概念,解析其核心组件,并展示如何利用现代后端技术栈构建和维护一个高效的微服务系统。我们将讨论微服务的优势,包括敏捷开发、独立部署、技术多样性以及弹性设计,并分析在实施过程中可能遇到的挑战,如服务发现、数据一致性和网络延迟问题。最后,我们将提供一个实际案例研究,以说明如何在现实世界中应用这些原则。
|
2天前
|
算法 架构师 网络协议
对标腾讯T9架构师的 Android 面试题新鲜出炉,算法真的太重要了
对标腾讯T9架构师的 Android 面试题新鲜出炉,算法真的太重要了
|
2天前
|
Android开发 算法 架构师
android的基础ui组件,这些知识点你会吗
android的基础ui组件,这些知识点你会吗
android的基础ui组件,这些知识点你会吗
|
2天前
|
Android开发 缓存 双11
android的基础ui组件,Android开发社招面试经验
android的基础ui组件,Android开发社招面试经验
android的基础ui组件,Android开发社招面试经验
|
3天前
|
消息中间件 Java 持续交付
构建高效微服务架构:后端开发的新视角
【5月更文挑战第15天】在现代软件开发的浪潮中,微服务架构已成为推动技术创新和服务灵活性的关键因素。本文将探讨如何构建一个高效的微服务架构,包括关键的设计原则、技术栈选择以及持续集成与部署的最佳实践。通过分析微服务的优势和挑战,我们将为后端开发人员提供一个全面的指导,帮助他们在构建可扩展、容错且易于维护的系统时做出明智的决策。
|
3天前
|
监控 持续交付 API
构建高效微服务架构:后端开发的新范式
【5月更文挑战第15天】 随着现代软件开发的演进,微服务架构已经成为企业解决复杂系统问题的首选方案。本文将深入剖析微服务的核心概念、设计原则及其在后端开发中的应用。我们将探讨如何通过容器化、服务网格和持续集成/持续部署(CI/CD)等技术手段提升系统的可伸缩性、弹性和维护性,同时确保高可用性和故障隔离。文章还将提供一系列实践案例,展示如何在实际项目中实施微服务架构,以及如何解决常见的挑战和问题。
47 1