Android 的 activity 是什么？

参考链接

https://developer.android.com/guide/components/activities/intro-activities?hl=zh-cn

移动应用体验与桌面设备体验的不同之处在于 用户与应用的互动并非总是从同一个位置开始。 相反，用户体验历程的开始往往是不确定的。 例如，如果您从主屏幕打开电子邮件应用，可能会看到 电子邮件列表。相比之下，如果你使用的是社交媒体应用 启动电子邮件应用后，您可以直接进入电子邮件应用的屏幕 撰写电子邮件。

Activity 类旨在促进这种范式。 当一个应用调用另一个应用时，发起调用的应用会调用另一个中的 activity 而不是将整个应用视为原子整体。这样，activity 就会充当 是应用与用户互动的入口点。您将实现 activity 作为 Activity 类的子类来实现。

activity 提供供应用进行绘制的窗口 界面此窗口通常会填满整个屏幕，但可能会小于 并浮动在其他窗口的上方。一般情况下，一个活动 在应用中实现一个屏幕例如，应用的某个 activity 可以 实现一个 Preferences 屏幕，而另一个 activity 实现了 选择照片屏幕。

大多数应用包含多个屏幕，这意味着它们包含多个屏幕 活动。通常，应用中的一个 Activity 会被指定为主 Activity activity，这是用户启动应用时显示的第一个屏幕。 然后，每个 activity 都可以启动另一个 activity，以便 执行不同的操作例如，一封简单电子邮件中的主活动 应用可以提供显示电子邮件收件箱的屏幕。在这里 activity 可能会启动其他 activity，为诸如此类的任务提供屏幕 分别撰写电子邮件和打开单独的电子邮件

尽管 activity 通过协同工作，在 应用，每个 activity 仅松散绑定到其他 activity；你有 通常是指应用中 activity 之间的依赖关系非常小。事实上 activity 通常会启动属于其他应用的 activity。例如： 浏览器应用可能会启动社交媒体应用的分享 activity。

类比解释

想象一个巨大的游乐园（这代表你的整个 Android 手机 📱）

在这个游乐园里，不是所有东西都挤在一起乱糟糟的。园区管理者（也就是 Android 操作系统）很有规划，把各种不同的娱乐项目放在了 独立的游乐棚 里。

• 每个 Activity 就相当于这样一个独立的游乐棚 🎪（或者你也可以理解为独立主题的小房间）。
  • 比如：有一个棚子叫 “过山车” (这相当于你应用的“游戏主界面 Activity”)。
  • 隔壁还有个棚子叫 “旋转木马” (这相当于你应用的“设置界面 Activity”)。
  • 再远点有一个 “小吃店” 棚子 (这相当于你应用中“用户个人资料 Activity”，或者甚至可能是另一个应用的“拍照分享 Activity”)。

这些游乐棚（Activity）的特点是什么呢？

1. 一个屏幕，一个空间： 每个棚子（Activity）都占据了一个清晰的、用户能看到的独立活动空间。就像你在一个棚子里玩过山车时，你专注于这个项目，屏幕通常会被这个棚子的内容（游戏的画面）填满。用户一次通常只在一个棚子里玩。
   • 对应技术点： Activity 提供一个窗口供应用绘制 UI，通常占据整个屏幕。
2. 功能独立，职责明确： 每个棚子都有自己的专属功能：
   • “过山车”棚子负责刺激体验。
   • “旋转木马”棚子负责浪漫转圈。
   • “小吃店”棚子负责提供食物补给。
   • 对应技术点： Activity 通常实现应用中的一个特定“屏幕”或功能模块（如登录屏、列表屏、详情屏、设置屏）。
3. 出入口设计： 每个棚子都有 入口（门）🚪 和 出口（门）。游乐园的管理员（操作系统） 负责：
   • 把游客引导到第一个棚子（比如刚开园时的“主广场”棚子 - 相当于应用的 主 Activity）。
   • 当游客在“过山车”棚子门口点了张“小吃券”代金券时，管理员会指引游客走到（或启动）那个“小吃店”棚子。
   • 游客可以在不同的棚子之间穿梭切换。比如从“旋转木马”直接走到“小吃店”。
   • 对应技术点： 系统（或应用自身）调用 startActivity() 来启动另一个 Activity（可以是本应用的，也可以是其他应用的）。
4. 松散联系，并非固死： 虽然这些棚子都在同一个游乐园（你的手机）里，但它们之间没有硬性的物理管道或固定连接。“过山车”棚子知道隔壁是“旋转木马”，但“过山车”棚子内部发生的事情，“旋转木马”棚子一般不需要操心（反之亦然）。它们之间主要通过“管理员引导”（Intent 消息）或者“传递代金券”（简单数据传递）来合作。
   • 对应技术点： Activity 之间是松耦合的。一个 Activity 知道如何启动另一个，但它们的内部状态通常是独立的（管理好状态共享是开发者的事）。
5. 使用说明手册： 为了能让管理员（操作系统）知道有这个棚子存在并能管理它，每个棚子必须提前在“园区管理处”（AndroidManifest.xml）注册登记，说明自己的名字、适合谁玩、怎么开灯、怎么关灯、有什么特殊要求等等。
   • 对应技术点： Activity 必须在应用的 AndroidManifest.xml 文件中声明。
6. 生命周期管理： 管理员（系统）非常关心每个棚子的资源使用效率：
   • 开门迎客 (onCreate)： 当你第一次进入一个棚子，管理员会给你灯光、音乐、道具都准备好（创建界面，初始化资源）。
   • 正式开放 (onStart / onResume)： 棚子正常运转，你在里面开心玩耍（Activity 在屏幕最前面，用户可见可交互）。
   • 暂停接待 (onPause)： 你可能被临时叫出去接个电话（另一个 Activity 部分盖住了它），管理员会暂时降低棚子的音量（暂停一些操作）。
   • 暂时关闭 (onStop)： 你完全走出这个棚子去另一个很远的棚子玩了（Activity 完全不可见），管理员可能会关掉部分灯和设备节省电力（释放部分资源）。
   • 彻底拆除？(onDestroy)： 如果管理员决定这个棚子长时间没人玩，或者手机内存实在紧张，管理员可能会把这个棚子彻底拆掉回收材料（销毁实例）。当然，如果你只是临时出去接个电话，管理员会保持棚子的灯光和低音量（暂停状态），等会你回来它还在原状等着你继续玩（恢复）。
   • 对应技术点： Activity 有严格的生命周期回调（onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy()），开发者需要在这些回调里做相应的资源管理，确保应用流畅高效。

总结类比：

• Android 系统 = 游乐园管理员 (管理一切，启动程序)
• 你的整个应用 (App) = 游乐园的一个主题区域 (比如“冒险岛”)
• Activity = 一个独立的游乐棚/功能房间 (主题项目) (如“过山车棚”、“小吃店”、“旋转木马房”)
• 主 Activity = 你进入“冒险岛”区域后第一个看到的标志性项目棚子
• 启动另一个 Activity = 从当前棚子走到另一个棚子去玩
• 生命周期回调 = 管理员根据棚子使用情况调整灯光设备、开关门的过程
• AndroidManifest.xml = 所有棚子在“园区管理处”的登记注册手册
• 无 main() 函数 = 游乐园没有唯一的“总开关”，每个棚子都是独立入口

🌐 跨园区协作：一个游乐园的棚子 (Activity) 可以启动另一个完全独立游乐园的棚子 (Activity)

继续咱们的游乐园比喻：

1. 你不是被困在一个园区里！

   • 想象你的“冒险岛”主题区域（你的 应用 A）里有一个叫“纪念品照片打印”的棚子（Activity）。
   • 在这个棚子里，游客（用户）拍好照片后想立刻分享到社交媒体。
   • 你的“冒险岛”园区本身没有大型社交媒体基地（比如“脸书乐园”、“推特小镇”）。

2. 呼叫外援：

   • 但作为“冒险岛”的管理者（开发者），你非常聪明！你不需要在自己园区里重建整个“推特小镇”，也不需要拥有它。
   • 你只需要在游客点击“分享照片”按钮时，告诉游乐园的中央调度中心（Android 系统）：“嗨！请帮我启动‘推特小镇’里的那个‘发布新动态’棚子（Activity）！”
   • 你的请求中还夹着一张小纸条（Intent），上面写着：“这张照片，请分享”（包含要分享的图片的 URI 或者二进制数据）。

3. 中央调度系统的作用（Android 系统）：

   • 中央调度中心认识所有注册在案的游乐园（所有安装的应用）。它知道“推特小镇”（Twitter 应用）在哪里。
   • 它也知道“推特小镇”里有个专门用来发布内容的棚子（Activity），并且这个棚子愿意接受这类“分享照片”的请求（因为 Twitter 应用在其 AndroidManifest.xml 中声明了这个 Activity 可以处理 ACTION_SEND 这样的 Intent）。
   • 调度中心拿着你的小纸条 (Intent)，精确地引导游客（用户界面焦点）无缝衔接地从“冒险岛”的“照片打印”棚子，跳转到“推特小镇”的“发布新动态”棚子！

4. 游客（用户）的体验：

   • 游客几乎感觉不到自己从一个公司的园区（应用 A）瞬间切换到了另一个公司的园区（应用 B）。
   • 在“推特小镇”的发布棚子里，游客看到了刚才在“冒险岛”拍的照片已经准备好发布。
   • 游客可以在“推特小镇”棚子里编辑文字、选择好友，然后点击“发布”。
   • 发布完成后，游客可以选择按“返回键”，然后调度中心又会把他送回到“冒险岛”的“照片打印”棚子（或者按“主页键”回到乐园中心广场 - 桌面）。

这个机制为什么厉害？

• 开发者（园区建设者）省心省力： 应用 A 的开发者不需要在自己的应用中实现复杂的分享、拍照、地图选择等功能。他们只需要专注于自己的核心功能（“冒险岛”的特色项目）。
• 功能复用： 众多优秀的应用（Twitter, Facebook, Google Photos, 地图应用等）已经实现了大量常用功能（如分享、拍照、选择地点）。通过 Activity，任何应用都可以轻松复用这些强大的功能。
• 用户体验流畅： 对用户来说，虽然跨越了不同的应用，但感觉是在完成一个连贯的任务（拍完照->分享）。系统提供了统一、连贯的导航体验（如返回堆栈）。
• 组件化生态： Android 系统通过 Activity 和其他组件 (Service, BroadcastReceiver, ContentProvider)，构建了一个高度组件化的生态系统。应用不是孤立的高墙花园，而是可以互相协作的模块。
• 权限控制： 安全性依然有保障。应用 A 调用应用 B 的Activity时，应用 B 负责执行相关操作。例如，Twitter 应用(应用B)的“发布”Activity如果需要访问网络或手机存储，它必须自己声明这些权限并获得用户授权。应用 A(“冒险岛”)通常不需要也不需要声明这些权限（除非它还要做其他相关操作）。

核心概念回顾

• 启动者： 应用 A 中的一个 Activity。
• 被启动者： 应用 B 中的一个 Activity。
• 通信媒介： Intent (意图) 对象。它就像一个包含了 请求类型（Action） （如ACTION_VIEW, ACTION_SEND）和 所需数据（如网页 URL、图片 URI、文本）的请求包。调度中心(系统)会根据Intent找到能处理它的Activity（可能在同一应用内，也可能在其他应用中）。
• 执行者： Android 系统，它充当了中央调度员的角色，解析 Intent，找到合适的 Activity 并启动它。

总结一句话： Android 的 Activity 设计允许你的应用“冒险岛”中的某个“游乐棚” (比如分享功能)，直接调用另一个独立应用“推特小镇”里的“游乐棚” (分享发布功能)，系统作为中央调度员 (Intent) 在背后协调整个跳转过程，为用户提供流畅的跨应用协作体验。这正是 Android 应用模型区别于传统 main() 启动方式的关键优势之一！ 🎉🤝