Android开发：Intent传参与重复读文件哪种内存性能更优

优先选「应用启动时单次读取用户信息文件，后续通过Intent传递所需用户数据」的方案，每次布局加载时重复读文件的方案没有任何性能优势，反而会引入很多不必要的问题。

• 磁盘IO开销差距极大：文件读取是磁盘IO操作，耗时比直接读内存中的对象高2~3个数量级。每个页面加载布局时都触发文件读取，会在冷启动、页面切换环节平白增加耗时，低端机型上很容易触发掉帧、页面白屏，频繁IO还会额外增加设备耗电。如果你的用户信息文件体积稍大，这个卡顿问题会更明显。
• 数据稳定性差异：每次读文件都要处理文件不存在、文件损坏、读写冲突的异常——比如刚好赶上信息写入操作执行到一半触发读取，就会拿到脏数据甚至直接抛异常导致页面崩溃。而启动阶段单次读取时，你可以集中做一次数据合法性校验，校验通过后的数据存在内存里，后续使用时不会出现这类读写冲突问题。
• 内存占用的顾虑完全没必要：普通用户信息（用户ID、昵称、头像路径、权限标记、基础偏好设置）序列化后总大小通常只有几KB，远达不到会影响应用内存性能的程度，这点内存开销和频繁IO的性能代价比可以忽略。

• Intent传值不要塞全量大对象：Android的Binder事务缓冲区有1MB左右的大小限制，跨页面传Intent的时候不要把整个用户信息对象全塞进去，只传递当前页面需要的必要字段即可，避免出现TransactionTooLargeException崩溃。
• 可以搭配轻量内存容器做补充：如果觉得跨页面逐次传值容易遗漏，启动读取完合法的用户信息后，可以把数据存在全局单例、或者共享ViewModel里，调用起来比逐次Intent传值更灵活，同样不会产生额外IO开销。
• 做好数据变更同步：如果用户在应用内修改了个人信息，记得同步更新内存中持有的用户数据，再把新内容写入文件覆盖旧值，避免下次启动读取到过期数据。

补充：只有一种特殊情况需要考虑按需读取文件——就是你的用户信息文件会被其他进程实时修改，你必须拿到磁盘上的最新值。就算是这种场景，也应该用FileObserver监听文件变更事件，只有文件真的发生修改时才重新读取，而不是每次加载布局都无脑执行读文件操作。

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