Android项目Activity间传参：传模型对象还是传ID更优？

你当前的业务场景是3个填写页、单页7个表单项，最终通过Retrofit提交数据到服务端，下面先逐一分析你提到的两种实现的优缺点，再给出实践建议。

方案1：Intent直接传递Serializable实体对象 #

优点 #

• 开发成本极低，不需要额外设计存储逻辑，构造完对象直接塞进Intent就能在目标页取值，代码链路短，写起来最快
• 取值时不需要额外IO操作，直接从内存中拿到反序列化后的对象，没有额外查询开销
• 不存在多数据源导致的一致性问题，跳转时传的是什么，目标页拿到的就是什么，不会被其他线程的操作修改

缺点 #

• 存在硬崩溃风险：Android系统的Binder事务缓冲区有固定大小限制（通常约1MB，是全局共享的，不是单Intent独占），如果后续业务迭代给AutoDados加字段、或者对象嵌套了大字符串、Bitmap等内容，很容易触发TransactionTooLargeException，这类崩溃线上排查难度很高
• 序列化性能差：Serializable是Java原生序列化方案，依赖反射实现，序列化/反序列化的速度比Android专门优化的Parcelable慢一个数量级，字段多的时候会拖慢页面跳转速度，甚至造成跳转动画掉帧
• 多页场景维护成本高：因为Intent传值是拷贝传递，你在第二个页面修改了表单内容，必须把修改后的新对象重新塞到Intent里再传给第三个页面，只要有一次漏传，后面的页面拿到的就是旧数据，表单页越多越容易出这类低级bug
• 进程重启场景容错差：如果应用在后台被系统回收，用户从最近任务列表返回页面时，Bundle里的自定义Serializable对象如果做了字段修改、序列化兼容没做好，很容易出现反序列化失败、拿不到数据的问题，用户填了一半的内容直接丢失

方案2：Intent仅传递主键ID，各页面从SQLite查询完整数据 #

优点 #

• 完全规避Intent传值的体积限制：不管表单项加多少、哪怕存了大段输入文本、图片本地路径，Intent里永远只传一个int类型的主键，永远不会触发传值过大的崩溃
• 多页数据一致性更好：用户每填完一页，就把当前页的内容更新到数据库对应ID的记录里，下一页打开时直接查数据库拿最新的全量数据，不需要层层传递修改后的对象，从根源上避免漏传导致的数据不一致问题
• 天然支持草稿容错：哪怕应用在后台被系统杀死、或者用户填到一半主动退出应用，下次打开时只要拿到对应的表单ID，就能从数据库里把之前填的所有内容恢复出来，不需要用户从头填写，用户体验好很多
• 性能开销完全可控：基于主键的SQLite查询是毫秒级操作，只要不把数据库操作放在主线程做重逻辑，这点开销用户完全感知不到；现在Room等ORM框架已经把数据库增删改查的逻辑封装得非常简便，实际开发的代码量并不会比直接传对象高多少

缺点 #

• 初期开发多了一步存储逻辑：需要提前设计表单对应的表结构，跳转前要先把当前页的输入内容落库，页面初始化时多一步查询操作，相比直接传对象要多写几行代码
• 需要维护临时数据的生命周期：表单提交成功后要记得把本地对应的草稿记录删掉，不然长时间使用会在本地积累无用的临时表单数据
• 如果不做数据库操作的线程切换，直接在主线程查库可能会造成卡顿，但只要按规范用协程/异步线程处理就完全可以避免

针对你当前的多步表单场景，传ID+本地数据库存草稿的方案是更优的开发实践，核心优势刚好匹配这类场景的需求：既不会出现传值过大的崩溃，又天然支持草稿暂存，还能减少多页传对象带来的维护成本，长期迭代的稳定性远好于直接传Serializable对象的方案。

除了上面两种方案，还可以根据你的项目架构选更适配的实现：

• 同Activity下的多Fragment表单：直接用Activity级别的ViewModel持有全量表单数据，Fragment之间不需要做任何数据传递，直接从ViewModel读取、修改数据即可，没有序列化开销、没有IO开销，是单Activity多Fragment架构下的首选方案
• 确实需要Intent传对象的场景：用Parcelable代替Serializable，通过Android官方的序列化方案大幅降低性能开销，但依然要严格控制传递对象的大小，不要超过Binder缓冲区的限制
• 轻量临时数据场景：可以用内存缓存（比如基于LruCache的临时数据仓库）持有表单数据，跳转时只传缓存对应的key，页面从内存取数，性能比查数据库更好，但要注意配合本地存储做兜底，避免应用被回收后内存数据清空导致内容丢失
• 页面状态恢复场景：配合Jetpack的SavedStateHandle保存轻量状态，在页面被系统重建时可以自动恢复数据，比普通Intent传值的容错性更好

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