Android startActivity跳转时Bundle是否会自动堆叠传递？

C页面无法直接获取A页面传入的firstBundle数据。
原因很简单：B跳转C时使用的是全新创建的i2实例，和A跳转B的i1完全独立，你仅给i2传入了包含Key2的secondBundle，没有携带任何A页面传入的数据，C页面getIntent()拿到的只有B页面塞的内容。另外你C页面取值时用的key是"firstKey"，和A页面存储时用的"Key1"根本不一致，就算数据透传过来了也会取到null。

• 手动透传（最直接无依赖）：B页面在跳转C前，从自身的Intent里取出A传来的数据，手动塞进新的Intent中即可：

// B页面跳转C的代码修改
Intent i2 = new Intent(B.this, C.class);
Bundle secondBundle = new Bundle();
secondBundle.putString("Key2", "Value2");
// 取出A传来的值，塞入跳转C的Bundle
String valueFromA = getIntent().getStringExtra("Key1");
secondBundle.putString("Key1", valueFromA);
i2.putExtras(secondBundle);
startActivity(i2);

如果要透传整个Bundle对象，也可以直接把A传来的Bundle整体作为序列化对象存入新Bundle：secondBundle.putBundle("a_page_bundle", getIntent().getExtras());，到C页面后调用getBundle("a_page_bundle")即可拿到A传的全量数据。

• 全局存储透传：如果传递的是全局通用数据（比如用户信息、全局配置），不需要走Intent层层传递，直接存入Application类的全局成员变量、MMKV/SharedPreferences等可全局访问的存储介质中，C页面直接从对应位置读取即可，注意做好内存泄漏防控。

Bundle基于Android专属的Parcelable序列化机制实现，序列化/反序列化效率远高于Java原生序列化，只要传递的是基础类型、小尺寸实体对象，哪怕跨多个页面透传，性能开销也几乎可以忽略。
但要注意：Android Binder传输缓冲区有固定大小限制（通常为1MB左右），如果传递超大Bitmap、超长字符串、大列表这类MB级别的数据，会直接触发TransactionTooLargeException崩溃，这类数据绝对不能走Intent传递。
另外这种层层手动传值的方式维护成本很高：如果跳转链路新增页面、或者需要传递的字段有增减，每个中转页面都要手动修改传值代码，漏传、key写错的问题非常容易出现。

根据场景选方案即可：

• 跳转链路短（2-3个页面）、传递字段少的场景：直接用手动透传的方式就行，代码最直观，没有额外依赖，出问题排查成本低。建议把所有传值用的key抽成静态常量统一管理，避免硬编码写错key。
• 跳转链路长、传递字段多的场景：
  • 可以把需要跨页面传递的公共字段封装成实现Parcelable接口的实体类，上游页面直接传入整个实体，中转页面透传时不需要逐个字段put，直接传入整个实体即可，减少重复代码。
  • 接入成熟的路由框架，支持参数自动注入、跨页面批量传参，不需要中转页面手动写取值、传值的样板代码，维护成本更低。
• 大尺寸数据场景：不要直接传数据本身，只传数据的唯一标识（比如文件路径、数据库主键），下游页面拿到标识后自行到本地存储、内存缓存中读取对应数据；单Activity架构下也可以通过作用域为Application级别的ViewModel存储共享数据，注意在页面销毁时及时清理引用避免内存泄漏。

内容的提问来源于stack exchange，提问作者Kelven Lim