UIAbility第二弹：获取UIAbility拉起方的信息

今天我们来学习一个很重要的知识点：UIAbility 之间的信息传递。举一个生活中我们常用的场景：购票拉起微信支付。

一、场景还原：买电影票时的支付流程

1. 你在购票APP（比如“XX电影”）中选好电影票，点击“确认支付”
   此时，购票APP里的“订单确认页面”就是拉起方UIAbilityA。
2. 系统自动跳转到微信支付界面，让你输入密码或指纹支付
   微信里的“支付界面”就是被拉起方UIAbilityB。

二、UIAbilityA（购票APP）如何“告诉”UIAbilityB（微信支付）自己的信息？

当购票APP通过startAbility启动微信支付界面时，会在parameters参数里附带“身份信息包裹”，里面包含：

1. Pid（购票APP的进程ID）

• 作用：就像购票APP在手机里运行时的“临时身份证号”。
• 例子：假设系统给购票APP分配的Pid是“12345”，微信支付界面拿到这个Pid后，就能知道“哦，是进程号为12345的应用启动了我”，后续支付完成后能准确找到该进程返回支付结果。

2. BundleName（购票APP的包名）

• 作用：购票APP在系统里注册的“全名”，类似“com.xx.movie”。
• 例子：微信支付界面通过包名能确定“这是XX电影APP发起的支付请求”，避免被其他恶意应用伪造请求（就像快递员送货时要看收件人姓名是否正确）。

3. AbilityName（购票APP中启动支付的具体页面名称）

• 作用：说明是购票APP里的哪个页面发起的支付，比如“OrderConfirmAbility”（订单确认页）。
• 例子：假设你在“XX电影”APP的“我的订单”页面和“商品详情页”都能发起支付，微信支付界面通过AbilityName就能知道“用户是从哪个页面来的”，方便后续返回时跳转到正确的页面（比如支付成功后回到订单页显示“已支付”）。

三、微信支付界面（UIAbilityB）拿到信息后会做什么？

1. 验证身份：通过BundleName确认支付请求是否来自合法的购票APP，防止钓鱼攻击。
2. 记录来源：知道是哪个页面发起的支付，方便后续数据统计（比如“多少用户从订单页完成支付”）。
3. 返回结果：支付完成后，根据Pid和AbilityName，准确回到购票APP的对应页面，并显示支付结果（成功/失败）。

四、类比生活场景理解

这就像你去超市买东西结账：

• 购票APP的订单页（UIAbilityA） 相当于“拿着商品去收银台的你”，
• 微信支付界面（UIAbilityB） 相当于“收银员”。
• Pid、BundleName、AbilityName 相当于你手里的“购物小票”，上面写着“你的姓名（BundleName）、排队号（Pid）、买了什么商品（AbilityName）”。
• 收银员（UIAbilityB）通过小票信息知道“你是谁、该收多少钱”，结完账后你（UIAbilityA）才能拿着小票回到超市里（购票APP）继续操作~

技术关键点总结

购票APP（UIAbilityA） →[startAbility+parameters]→ 微信支付（UIAbilityB）
parameters中包含：
{
  "pid": 12345,          // 购票APP进程ID
  "bundleName": "com.xx.movie",  // 购票APP包名
  "abilityName": "OrderConfirmAbility"  // 发起页面名称
}

这样一来，两个应用的UIAbility就像“对暗号”一样，通过信息传递完成支付流程的衔接啦~

下一章我们将深入探讨基于Want的UIAbility间通信机制，实现跨应用支付功能的技术细节。若您在阅读中发现任何技术疏漏，欢迎提交Issue或参与社区讨论共同完善。