每次在Android开发中点击按钮跳转页面时，我总想起去年同事老张因为没处理好空指针异常，导致整个购物车模块崩溃的惨案。就像炒菜时忘记关煤气灶，稍有不慎就会引发灾难。今天就带大家摸透Activity跳转时的那些"煤气阀门"该怎么关。

一、那些年我们踩过的跳转坑

记得第一次实现用户资料编辑页时，我在onCreate里直接调用了startActivity，结果遇到设备旋转就崩溃。后来才发现，就像快递员送包裹前要确认地址是否有效，跳转前必须检查这三件事：

• 目标Activity是否在清单文件注册
• Intent携带的数据是否超过1MB限制
• 隐式跳转时是否存在匹配的Activity

错误类型	典型表现	参考解决方案	数据来源
ActivityNotFoundException	应用闪退	try-catch包裹startActivity	Android官方文档
TransactionTooLargeException	页面卡死	使用Bundle分页加载	《Android开发艺术探索》
SecurityException	权限拒绝	动态权限申请	Google开发者指南

1.1 隐式跳转的温柔陷阱

上周实习生小王用隐式Intent打开浏览器，结果用户设备没安装任何浏览器应用，直接导致崩溃。这就好比用钥匙开锁，总得准备备用钥匙：

Intent intent = new Intent(Intent.ACTION_VIEW);
if (intent.resolveActivity(getPackageManager) != null) {
startActivity(intent);
} else {
Toast.makeText(this,"未找到可用应用",Toast.LENGTH_SHORT).show;
}

二、数据传递中的暗礁

去年双十一大促时，我们的商品详情页因为传递的Bitmap过大，导致低端机上频繁崩溃。后来改用Glide异步加载，就像把大象装冰箱不能硬塞，要拆分成小块：

• 使用ApplicationContext传递全局数据
• 复杂对象实现Parcelable接口
• 大图文件采用URI路径传递

2.1 回调地狱的救赎

当需要从子Activity获取结果时，传统的onActivityResult就像在迷宫里找出口。去年我们改用Activity Result API后，代码清爽得像刚整理过的衣柜：

ActivityResultLauncher launcher = registerForActivityResult(
new ActivityResultContracts.StartActivityForResult,
result -> {
if (result.getResultCode == RESULT_OK) {
// 处理返回数据
});

三、生命周期引发的蝴蝶效应

有次用户快速切换页面导致数据丢失，就像快餐店服务员记错了订单。后来我们引入ViewModel+LiveData的方案，保证数据在配置变更时依然存活：

方案	适用场景	内存占用	实现难度
onSaveInstanceState	简单数据存储	低	★☆☆
ViewModel	复杂数据保持	中	★★☆
数据库存储	持久化数据	高	★★★

窗外的夕阳把办公室染成橘红色，键盘敲击声渐渐稀疏。想起上周用Navigation Component重构跳转逻辑后，那些曾经让我们加班到凌晨的页面跳转问题，现在都乖乖待在框架的保险箱里。或许这就是Android开发的魅力——总能在解决问题的过程中，遇见更好的自己。