正文

某开发者因4行代码让App崩溃 手把手教你写对Android编程实例分析

/0 浏览量
0825

某开发者因4行代码让App崩溃 手把手教你写对Android编程实例分析

那天深夜，我的手机突然”嗡”的一声，屏幕闪烁了一下——我的App又崩了。

打开日志一看，我差点从椅子上跳起来。就四行代码，就这么简简单单的四个”动作”，硬生生把一个正常运行了一周多的应用给干掉了。

别急着骂自己手抖，这种坑，十个人里至少八个踩过。今天咱们就坐下来，泡杯茶，慢慢把这四行代码扒开揉碎了看，看看它是怎么把你整得团团转的。

那四行”致命”代码长什么样

先来看看让我熬了半宿的罪魁祸首：

String userData = intent.getStringExtra("user_data");
User user = new Gson().fromJson(userData, User.class);
if (user.name.equals("admin")) {  // 第1行
    user.role = "super_admin";     // 第2行
    saveUser(user);                // 第3行
    navigateToHome();              // 第4行
}

就这四行。看起来人畜无害对吧？甚至觉得”就这么简单？”。

但问题恰恰就藏在这份”简单”里。

第一个地雷：NullPointerException 的温柔陷阱

user.name.equals("admin")——这一行就是压死骆驼的第一根稻草。

你以为拿到了 user 对象，就可以放心大胆地调用它的方法。但别忘了，fromJson 这个方法，它不是万能的神。

当我传入的 userData 为 null 的时候，user 就是 null。

而 null.name……你知道会发生什么。

java.lang.NullPointerException: 
Attempt to invoke virtual method 'java.lang.String java.lang.String.equals(java.lang.Object)' 
on a null object reference

这行错误日志，我盯了足足二十分钟。

为什么是二十分钟？因为我的直觉告诉我，fromJson 应该返回一个对象，怎么可能返回 null？

事实是，当 JSON 字符串为 null 时，Gson 确实会返回 null。这个行为在官方文档里写得清清楚楚，但我就是没注意到。

让我告诉你一个真实的故事。

去年有个开发者，在 Stack Overflow 上问了一个问题：”为什么我的 App 每次打开都会崩溃？”

他的代码里有一行：

String token = prefs.getString("token", null);
if (token.equals("")) { ... }  // 崩溃！

评论区里有人提醒他：”兄弟，token 可能是 null 啊。”

他的回复是：”getString 有默认值 null，应该不会是 null 吧？”

最后是他自己解决了问题——他在日志里看到了 NullPointerException，才恍然大悟。

这个故事告诉我们什么？

相信日志，不要相信你的直觉。

你的直觉可能是错的。

第二个地雷：空字符串 vs null 的混淆

再来看看这行代码：

if (user.name.equals("admin"))

假设 user 不为 null（你做了判空），但 user.name 可能是什么？

  • null
  • ""（空字符串）
  • "admin"
  • "admin "（有空格）
  • "Admin"（大小写不同）

如果你的业务逻辑里，”admin” 和 “Admin” 应该被视为同一个角色，那么 equals 就会漏掉情况。

更糟糕的是，如果 name 字段在 JSON 中根本不存在，Gson 不会报错，而是会把 name 设置为 null。

这时候，user.name.equals("admin") 还是会崩溃。

正确的写法：防御性编程的艺术

那么，正确的写法应该是什么样的？

String userData = intent.getStringExtra("user_data");

// 第一层防护：检查 JSON 字符串是否为 null 或空
if (TextUtils.isEmpty(userData)) {
    Log.e("UserManager", "userData is null or empty, cannot parse");
    // 跳转到登录页或者显示错误提示
    navigateToLogin();
    return;
}

// 第二层防护：解析 JSON，处理可能的格式错误
User user;
try {
    user = new Gson().fromJson(userData, User.class);
} catch (JsonSyntaxException e) {
    Log.e("UserManager", "Invalid JSON format: " + e.getMessage());
    // 清理错误数据，提示用户
    clearUserData();
    showError("数据解析失败，请重新登录");
    return;
}

// 第三层防护：检查解析后的对象是否为 null
if (user == null) {
    Log.e("UserManager", "User object is null after parsing");
    navigateToLogin();
    return;
}

// 第四层防护：检查关键字段是否为 null
if (TextUtils.isEmpty(user.name)) {
    Log.e("UserManager", "User name is null or empty");
    navigateToLogin();
    return;
}

// 第五层防护：使用安全的字符串比较
// 把常量放在前面，避免 NPE
if ("admin".equals(user.name.toLowerCase().trim())) {
    user.role = "super_admin";
    saveUser(user);
    navigateToHome();
} else {
    navigateToHome();  // 普通用户也放行
}

看到了吗？这已经不是四行代码了，这是十几行。

但每多一行，都是多一层保护。

为什么要这么啰嗦？

你可能会说：”至于吗？就这么几行代码，搞这么复杂？”

让我问你一个问题：你的 App，有多少用户？

如果你的 App 有 100 个用户，其中 1 个人触发了这个崩溃，崩溃率是 1%。

如果你的 App 有 100 万个用户，其中 1000 个人触发了崩溃，崩溃率还是 0.1%。

但 Google Play 的崩溃率红线是 2.5%。

一旦超过这个线，你的 App 会被降权，甚至被下架。

所以，每一行代码，都是在为你的用户负责。

Kotlin 的简洁与强大

如果你是 Kotlin 开发者，好消息是，Kotlin 内置了很多空安全机制。

同样的逻辑，Kotlin 代码可以这样写：

val userData = intent.getStringExtra("user_data")

// 使用?.和?:操作符，简洁又安全
val user = userData?.let { 
    runCatching { 
        Gson().fromJson(it, User::class.java) 
    }.getOrNull() 
} ?: run {
    Log.e("UserManager", "userData is null or parsing failed")
    navigateToLogin()
    return@let
}

// 安全调用运算符?.，避免NPE
if (user.name?.equals("admin", ignoreCase = true) == true) {
    user.role = "super_admin"
    saveUser(user)
    navigateToHome()
} else {
    navigateToHome()
}

注意 runCatching 这个操作，它会把可能抛出异常的代码包起来，不会让异常逃逸到外层。

而 ?.equals("admin", ignoreCase = true) == true 这个写法：

  • ?. 保证 name 为 null 时不崩溃
  • ignoreCase = true 让比较不区分大小写
  • == true 确保只有确实是 true 时才进入 if 块

这就是 Kotlin 的空安全设计哲学：宁可编译不过，也不要运行时崩溃。

更深层的问题：为什么我们会写出这种代码？

说实话，写出这种”致命四行”的人，不只是新手。

我见过很多有经验的开发者，也会写出这种代码。

原因是什么？

过度自信。

当我们对自己的代码太熟悉时，就会不自觉地把一些”假设”当成”事实”。

比如：

  • “fromJson 不可能返回 null”（其实会）
  • “这个字段一定有值”（其实不一定）
  • “用户不可能传空数据进来”（其实会）

另一种原因是：赶时间。

项目上线在即，领导催着要，产品经理说”先跑通再说”。

于是，”先跑通再说”变成了”先上线再说”，”先上线再说”变成了”用户反馈了再说”。

但等到用户反馈，那就不是四行代码的问题了。

一个真实的案例：某知名App的崩溃

2023年，某知名社交 App 更新后，大量用户反馈闪退。

工程师花了三天时间排查，最后发现：

// 这是一个加载用户头像的代码
ImageView avatar = findViewById(R.id.avatar);
String url = userInfo.getAvatarUrl();  // 可能为 null
Glide.with(context).load(url).into(avatar);  // 崩溃！

当用户的头像 URL 为 null 时，Glide 会尝试加载 null，然后崩溃。

修复方案很简单：

String url = userInfo.getAvatarUrl();
if (!TextUtils.isEmpty(url)) {
    Glide.with(context).load(url).into(avatar);
} else {
    avatar.setImageResource(R.drawable.default_avatar);
}

但这个简单的修复，却花了三天。

为什么？因为崩溃只发生在特定场景：新用户，还没有设置头像。

这个场景很难在测试环境中复现，因为测试人员都是老用户，都有头像。

这就是为什么防御性编程这么重要。

手把手教你写对代码：五个检查清单

下次写代码的时候，问自己五个问题：

1. 这个变量可能为 null 吗？

不只是对象，字符串、数字包装类、集合，都可能为 null。

// ❌ 危险
int count = data.getCount();
if (count > 0) { ... }

// ✅ 安全
Integer count = data.getCount();
if (count != null && count > 0) { ... }

2. 这个字符串可能为空吗？

空字符串 "" 和 null 是两个不同的概念，但都会导致问题。

// ❌ 不够健壮
if (name.equals("admin")) { ... }

// ✅ 更安全
if ("admin".equals(name)) { ... }
// 或者用 TextUtils
if (TextUtils.equals(name, "admin")) { ... }

3. 这个解析可能失败吗？

JSON、XML、文件读取、网络请求——任何外部输入都可能失败。

// ❌ 假设解析永远成功
User user = gson.fromJson(json, User.class);

// ✅ 处理解析失败
User user = null;
try {
    user = gson.fromJson(json, User.class);
} catch (JsonSyntaxException e) {
    Log.e(TAG, "JSON parsing failed", e);
}

4. 这个索引可能越界吗？

// ❌ 假设列表非空
String firstItem = items.get(0);

// ✅ 检查大小
if (items != null && items.size() > 0) {
    String firstItem = items.get(0);
}

5. 这个线程操作安全吗？

// ❌ 可能触发 ConcurrentModificationException
for (String item : items) {
    items.remove(item);  // 遍历过程中修改集合
}

// ✅ 使用迭代器
Iterator<String> iterator = items.iterator();
while (iterator.hasNext()) {
    String item = iterator.next();
    iterator.remove();
}

单元测试：最后的防线

防御性编程是第一步，但还不够。

单元测试是第二道防线。

让我们为上面的代码写几个测试用例：

@RunWith(MockitoJUnitRunner.class)
public class UserManagerTest {

    @Test
    public void testParseNullUserData() {
        // 测试 null 输入
        UserManager manager = new UserManager();
        manager.handleUserData(null);
        // 验证是否跳转登录页
        verify(mockActivity).navigateToLogin();
    }

    @Test
    public void testParseEmptyUserData() {
        // 测试空字符串
        UserManager manager = new UserManager();
        manager.handleUserData("");
        verify(mockActivity).navigateToLogin();
    }

    @Test
    public void testParseInvalidJson() {
        // 测试无效 JSON
        UserManager manager = new UserManager();
        manager.handleUserData("{invalid json");
        verify(mockActivity).navigateToLogin();
    }

    @Test
    public void testParseAdminUser() {
        // 测试正常 admin 用户
        String validJson = "{\"name\":\"admin\",\"age\":25}";
        UserManager manager = new UserManager();
        manager.handleUserData(validJson);
        verify(mockActivity).navigateToHome();
    }

    @Test
    public void testParseUserWithNullName() {
        // 测试 name 为 null 的情况
        String validJson = "{\"age\":25}";
        UserManager manager = new UserManager();
        manager.handleUserData(validJson);
        verify(mockActivity).navigateToLogin();
    }
}

这些测试用例覆盖了所有可能导致崩溃的场景。

每多一个测试用例，就是多一层保险。

代码审查：让队友帮你找坑

除了单元测试，代码审查也是必不可少的一环。

当你的队友 review 你的代码时，他们会问你一些你没想到过的问题：

  • “如果这个接口返回空怎么办？”
  • “如果网络超时了怎么办？”
  • “如果用户快速点击两次怎么办？”

这些问题，你自己可能不会想到，但队友会。

所以，不要害羞，主动寻求 review。

最后：从这四行代码学到的事

回到最初的那四行代码。

如果当初写的时候，多问自己一句：”如果 userData 是 null 怎么办？”

这四行代码，可能就会变成四十几行。

但正是这四十几行，保护了成百上千的用户，避免了几百次崩溃。

编程不是写最少的代码，而是写最可靠的代码。

四行代码和四十几行代码，执行速度相差无几，但可靠性天差地别。

希望这篇文章能帮你避坑。

如果你曾经也被类似的坑坑过，欢迎在评论区分享你的故事。

我们一起，把代码写得更稳。

-- 展开阅读全文 --