正文

你的AndroidApp为什么总闪退实例分析常见错误与修复技巧

/0 浏览量
0903

Android App为什么总闪退？实例分析常见错误与修复技巧

做Android开发的朋友，谁没被闪退折磨过呢？那种在测试机上跑得好好的，一到线上就崩给用户看的尴尬场面，相信每个人都经历过。今天咱们就聊聊这个让人头疼的问题，我会用最直白的方式，把常见的崩溃类型、原因和修复方案说清楚，还会配上实际代码示例，让你看完就能用上。

先搞清楚：闪退到底是什么？

在Android里，”闪退”其实就是应用遭遇了未捕获的异常，系统不得不把进程杀掉。你能看到的”应用已停止运行”弹窗，就是系统的最后挣扎。但很多时候，你甚至看不到弹窗，应用直接就消失了，这种”静默崩溃”更让人抓狂——因为你根本不知道发生了什么。

理解这个基本机制很重要，因为不同的崩溃类型，处理方式完全不同。

空指针异常：那个永远绕不开的”老朋友”

如果说Android崩溃里有谁最能刷存在感，那必须是NullPointerException。这玩意儿几乎出现在每一个开发者身上，而且它的出现方式千奇百怪。

举个真实的例子。有个刚入行的朋友做了个用户资料页面，逻辑很简单：从服务器拿到用户数据，展示头像、昵称和签名。代码看起来没问题：

public class UserProfileActivity extends AppCompatActivity {
    
    private TextView tvNickname;
    private TextView tvSignature;
    private ImageView ivAvatar;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_user_profile);
        
        tvNickname = findViewById(R.id.tv_nickname);
        tvSignature = findViewById(R.id.tv_signature);
        ivAvatar = findViewById(R.id.iv_avatar);
        
        // 从Intent中获取用户数据
        User user = (User) getIntent().getSerializableExtra("user_data");
        
        // 问题就出在这里，没有判空就直接用
        tvNickname.setText(user.getNickname());
        tvSignature.setText(user.getSignature());
        
        // 头像加载也埋了雷
        Glide.with(this)
            .load(user.getAvatarUrl())
            .into(ivAvatar);
    }
}

表面上看，这段代码逻辑通顺，在测试环境下用模拟数据跑也完全正常。但一旦用户没有登录，或者网络请求返回的数据不完整，user对象可能就是null。这时候调用user.getNickname()，啪，闪退。

更隐蔽的是，即使user不为null，getAvatarUrl()返回的也可能是null。Glide其实对null值处理得比较好，不会崩，但如果你后面再对返回的字符串做任何操作，比如调用startsWith()或者拼接字符串，照样会炸。

修复这样的代码，正确的姿势是这样的：

public class UserProfileActivity extends AppCompatActivity {
    
    private TextView tvNickname;
    private TextView tvSignature;
    private ImageView ivAvatar;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_user_profile);
        
        tvNickname = findViewById(R.id.tv_nickname);
        tvSignature = findViewById(R.id.tv_signature);
        ivAvatar = findViewById(R.id.iv_avatar);
        
        // 先判空，这是基本素养
        User user = (User) getIntent().getSerializableExtra("user_data");
        if (user == null) {
            // 给出友好提示，而不是让应用直接挂掉
            showLoginPrompt();
            return;
        }
        
        // 对可能为null的字符串做安全处理
        String nickname = user.getNickname();
        tvNickname.setText(nickname != null ? nickname : "匿名用户");
        
        String signature = user.getSignature();
        tvSignature.setText(signature != null ? signature : "这个人很懒，什么都没写");
        
        // 头像URL同样要处理
        String avatarUrl = user.getAvatarUrl();
        if (avatarUrl != null && !avatarUrl.isEmpty()) {
            Glide.with(this)
                .load(avatarUrl)
                .placeholder(R.drawable.default_avatar)
                .error(R.drawable.error_avatar)
                .into(ivAvatar);
        } else {
            ivAvatar.setImageResource(R.drawable.default_avatar);
        }
    }
    
    private void showLoginPrompt() {
        new AlertDialog.Builder(this)
            .setTitle("提示")
            .setMessage("请先登录后查看个人资料")
            .setPositiveButton("去登录", (dialog, which) -> {
                startActivity(new Intent(this, LoginActivity.class));
            })
            .setCancelable(false)
            .show();
    }
}

你看，加了几个判空，应用就变得稳多了。但这只是基础，更聪明的做法是在整个项目里引入Kotlin，用它的空安全机制。同样的逻辑写成Kotlin：

class UserProfileActivity : AppCompatActivity() {
    
    private lateinit var tvNickname: TextView
    private lateinit var tvSignature: TextView
    private lateinit var ivAvatar: ImageView
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_user_profile)
        
        tvNickname = findViewById(R.id.tv_nickname)
        tvSignature = findViewById(R.id.tv_signature)
        ivAvatar = findViewById(R.id.iv_avatar)
        
        // Kotlin的 nullable type 会强制你处理空值
        val user = intent.getSerializableExtra("user_data") as? User
        if (user == null) {
            showLoginPrompt()
            return
        }
        
        // 用 ?: 运算符给默认值，代码更简洁
        tvNickname.text = user.nickname ?: "匿名用户"
        tvSignature.text = user.signature ?: "这个人很懒，什么都没写"
        
        // Glide 天然支持 null，不用额外处理
        Glide.with(this)
            .load(user.avatarUrl)
            .placeholder(R.drawable.default_avatar)
            .error(R.drawable.error_avatar)
            .into(ivAvatar)
    }
}

Kotlin的?:运算符和可空类型系统，能在编译阶段就拦截掉大量潜在的空指针问题，强烈推荐新项目直接用Kotlin。

数组越界：你以为边界检查过了，其实没有

这个错误特别适合坑新人。比如你从服务器拿到了一个用户列表，然后想在界面上展示前5个。代码看起来是这样：

public class UserListFragment extends Fragment {
    
    private List<User> userList;
    
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        View view = inflater.inflate(R.layout.fragment_user_list, container, false);
        
        // 从服务器获取数据
        userList = fetchUsersFromServer();
        
        // 取前5个展示
        for (int i = 0; i < 5; i++) {
            User user = userList.get(i);  // 崩在这里
            TextView tv = view.findViewById(R.id.tv_user_name);
            tv.setText(user.getName());
        }
        
        return view;
    }
}

这段代码有个致命问题：它假设服务器一定返回至少5个用户。但现实世界很残酷，可能服务器只返回了3个用户，或者接口异常导致返回空列表。这时候userList.get(4)就会抛出IndexOutOfBoundsException，应用直接闪退。

修复方法很简单，循环条件改成实际列表大小：

// 安全版本
int displayCount = Math.min(5, userList.size());
for (int i = 0; i < displayCount; i++) {
    User user = userList.get(i);
    // ...
}

但更深的问题是，你为什么要写死5这个数字？更好的做法是把列表交给RecyclerView来处理，它会自动处理数据边界问题。这也是为什么现在Android开发几乎都推荐用RecyclerView而不是ListView。

用RecyclerView的正确姿势：

class UserListFragment : Fragment() {
    
    private lateinit var recyclerView: RecyclerView
    private lateinit var userAdapter: UserAdapter
    
    override fun onCreateView(
        inflater: LayoutInflater, 
        container: ViewGroup?, 
        savedInstanceState: Bundle?
    ): View {
        val view = inflater.inflate(R.layout.fragment_user_list, container, false)
        
        recyclerView = view.findViewById(R.id.recycler_view)
        recyclerView.layoutManager = LinearLayoutManager(requireContext())
        
        userAdapter = UserAdapter(emptyList())
        recyclerView.adapter = userAdapter
        
        // 用协程或LiveData处理数据，避免在UI线程做网络请求
        viewModel.users.observe(viewLifecycleOwner) { users ->
            userAdapter.submitList(users)
        }
        
        return view
    }
}

资源文件找不到：build variant写错了

这个错误特别奇葩，新手遇到基本要怀疑人生。你以为代码没问题，运行起来直接崩，Logcat里写着：

java.lang.IllegalStateException: Could not find method xxxOnClick(View) in a parent or ancestor Context for the onClick attribute defined on view xxx

或者：

android.content.res.Resources$NotFoundException: String resource ID #0x0

这种时候，99%的情况是你的build variant配置有问题。比如你用了Flavor，定义了free和paid两个变体，然后在代码里引用资源：

<!-- res/values/strings.xml -->
<string name="app_name">我的应用</string>

然后在Activity里：

setTitle(R.string.app_name);

看起来没问题对吧？但如果某个Flavor下没有对应的资源文件，或者你用了@+id/xxx但对应的布局文件不存在，就会崩。

更常见的情况是，你在代码里用findViewById引用了一个View，但这个View只在某个布局文件里存在。比如：

// 你以为这个Button在布局里
Button btnPay = findViewById(R.id.btn_pay);
btnPay.setOnClickListener(v -> pay());

但实际的activity_main.xml里根本没有btn_pay这个Button。结果就是findViewById返回null，然后你调setOnClickListener，啪，NullPointerException。

这种问题的排查技巧是：

  1. 先看崩溃堆栈，找到是哪个findViewById返回了null
  2. 去对应的布局文件里搜索那个ID
  3. 检查布局文件是否属于正确的Flavor目录（比如res/layout-free/和res/layout-paid/）
  4. 确认build.gradle里的Flavor配置是否正确

多线程竞态：最隐形的崩溃杀手

这个错误是资深开发者都可能踩的坑。Android的UI操作必须在主线程进行，这是铁律。但如果你在子线程里做了UI操作，应用就会崩：

public class DataSyncService extends Service {
    
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        new Thread(() -> {
            // 模拟网络请求
            List<User> users = fetchUsersFromNetwork();
            
            // 错误！在子线程更新UI
            runOnUiThread(() -> {
                updateUserList(users);
            });
        }).start();
        
        return START_NOT_STICKY;
    }
}

代码看起来用了runOnUiThread，应该是安全的对吧？但如果fetchUsersFromNetwork()返回的是一个不可变的列表，然后在其他地方也操作这个列表，就会出现竞态条件。更糟的是，如果你直接持有这个列表的引用，在其他线程修改它，就会抛出ConcurrentModificationException。

真正的多线程安全做法是使用不可变数据或者线程安全的集合：

class DataSyncService : Service() {
    
    private val _userList = MutableLiveData<ImmutableList<User>>(ImmutableList())
    val userList: LiveData<ImmutableList<User>> get() = _userList
    
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        lifecycleScope.launch(Dispatchers.IO) {
            val users = fetchUsersFromNetwork()
            // 不可变列表，线程安全
            _userList.postValue(ImmutableList.copyOf(users))
        }
        return START_NOT_STICKY
    }
}

用Kotlin的协程配合LiveData和不可变集合，基本可以规避大部分多线程问题。

内存泄漏：不是直接闪退，但会让应用越来越卡

这个不属于直接闪退，但内存泄漏累积到一定程度，应用就会因为OOM（Out Of Memory）而崩溃。Android系统对每个应用的内存都有严格限制，超出就会杀进程。

最常见的内存泄漏场景是静态变量持有Activity引用：

public class ApiClient {
    
    // 大坑！静态持有Activity引用
    private static Activity activity;
    
    public static void init(Activity act) {
        activity = act;
    }
    
    public static void requestData(String url, Callback callback) {
        // 使用activity做一些操作...
        if (activity != null) {
            // 发起网络请求
        }
    }
}

这段代码的问题在于，ApiClient是静态的，生命周期和Application一样长。而它持有的activity引用，会导致Activity在应该被回收的时候无法被回收。每次用户打开这个Activity，内存就多占用一份，直到触发OOM。

正确的做法是用WeakReference：

public class ApiClient {
    
    private static WeakReference<Activity> activityRef;
    
    public static void init(Activity act) {
        activityRef = new WeakReference<>(act);
    }
    
    public static void requestData(String url, Callback callback) {
        Activity activity = activityRef.get();
        if (activity != null && !activity.isFinishing()) {
            // 安全使用activity
        }
    }
}

或者更简单，直接在ViewModel里处理网络请求，ViewModel的生命周期和Activity解耦：

class UserViewModel : ViewModel() {
    
    private val _users = MutableLiveData<List<User>>()
    val users: LiveData<List<User>> get() = _users
    
    fun loadUsers() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = apiService.getUsers()
            _users.postValue(result)
        }
    }
}

数据库操作在主线程：被ANR盯上的程序

Android有个保护机制：如果主线程阻塞超过一定时间（大约5秒），系统就会弹出ANR对话框，让用户强制关闭应用。数据库操作是典型的耗时操作，如果在主线程执行，轻则卡顿，重则ANR。

public class UserDatabaseHelper extends SQLiteOpenHelper {
    
    public UserDatabaseHelper(Context context) {
        super(context, "users.db", null, 1);
    }
    
    @Override
    public void onCreate(SQLiteDatabase db) {
        db.execSQL("CREATE TABLE users (_id INTEGER PRIMARY KEY, name TEXT, email TEXT)");
    }
    
    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        db.execSQL("DROP TABLE IF EXISTS users");
        onCreate(db);
    }
    
    // 这个方法是同步的，调用方必须自己处理线程问题
    public List<User> getAllUsers() {
        SQLiteDatabase db = this.getReadableDatabase();
        Cursor cursor = db.query("users", null, null, null, null, null, null);
        List<User> users = new ArrayList<>();
        while (cursor.moveToNext()) {
            User user = new User();
            user.id = cursor.getInt(cursor.getColumnIndexOrThrow("_id"));
            user.name = cursor.getString(cursor.getColumnIndexOrThrow("name"));
            user.email = cursor.getString(cursor.getColumnIndexOrThrow("email"));
            users.add(user);
        }
        cursor.close();
        return users;
    }
}

如果有人在主线程调用getAllUsers()，而数据库里有几万条数据，主线程就会被阻塞，ANR随即到来。

现代Android开发已经不推荐直接用SQLiteOpenHelper了，Room数据库库是更好的选择：

@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAllUsers(): Flow<List<User>>
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

class UserViewModel(private val database: AppDatabase) : ViewModel() {
    
    val users = database.userDao().getAllUsers()
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5000),
            initialValue = emptyList()
        )
}

Room+Coroutines+Flow的组合，自动处理线程切换，代码也更简洁。

权限问题：Android 10+的存储权限大变动

从Android 10开始，Google对存储权限做了很大改动。如果你的应用还在用旧的方式申请读写外部存储权限，在新设备上很可能会出问题。

// 旧写法，在Android 10+上可能崩溃
public class PhotoPickerActivity extends AppCompatActivity {
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        
        // 直接打开系统相机
        Intent cameraIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
        if (cameraIntent.resolveActivity(getPackageManager()) != null) {
            File photoFile = createImageFile();
            Uri photoURI = FileProvider.getUriForFile(
                this,
                "com.example.myapp.fileprovider",
                photoFile
            );
            cameraIntent.putExtra(MediaStore.EXTRA_OUTPUT, photoURI);
            startActivityForResult(cameraIntent, REQUEST_CAMERA);
        }
    }
    
    private File createImageFile() throws IOException {
        String imageName = "IMG_" + System.currentTimeMillis() + ".jpg";
        File storageDir = getExternalFilesDir(Environment.DIRECTORY_PICTURES);
        return File.createTempFile(imageName, ".jpg", storageDir);
    }
}

这段代码在Android 9及以下设备上运行良好，但在Android 10及以上，如果应用没有正确配置FileProvider，或者在AndroidManifest.xml里没有声明权限，就会崩溃。

更重要的是，Android 13引入了细粒度的照片权限，不再是一刀切的READ_EXTERNAL_STORAGE，而是分成了READ_MEDIA_IMAGES、READ_MEDIA_VIDEO和READ_MEDIA_AUDIO。如果你的目标SDK版本是33以上，却还在用旧权限，应用会在启动时直接崩溃。

正确的做法是：

<!-- AndroidManifest.xml -->
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" 
    android:maxSdkVersion="32" />
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />

// 运行时动态申请权限
class PhotoPickerActivity : AppCompatActivity() {
    
    private val requestPermissionLauncher = registerActivityResultLauncher(
        ActivityResultContracts.RequestPermission()
    ) { isGranted ->
        if (isGranted) {
            openCamera()
        } else {
            // 权限被拒绝，给出说明
            showPermissionExplanation()
        }
    }
    
    private fun checkPermissions() {
        when {
            Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU -> {
                // Android 13+ 用新权限
                requestPermissionLauncher.launch(
                    Manifest.permission.READ_MEDIA_IMAGES
                )
            }
            else -> {
                // Android 12及以下
                requestPermissionLauncher.launch(
                    Manifest.permission.READ_EXTERNAL_STORAGE
                )
            }
        }
    }
    
    private fun openCamera() {
        val cameraIntent = Intent(MediaStore.ACTION_IMAGE_CAPTURE)
        if (cameraIntent.resolveActivity(packageManager) != null) {
            val photoFile = createImageFile()
            val photoURI = FileProvider.getUriForFile(
                this,
                "${packageName}.fileprovider",
                photoFile
            )
            cameraIntent.putExtra(MediaStore.EXTRA_OUTPUT, photoURI)
            cameraIntent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
            cameraIntent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION)
            startActivityForResult(cameraIntent, REQUEST_CAMERA)
        }
    }
}

处理第三方SDK的崩溃

现在的项目很少没有第三方SDK了。广告SDK、推送SDK、分析SDK……这些第三方库的bug，往往会导致你的应用闪退，而且日志堆栈里会出现你不认识的包名，让人一头雾水。

比如一个广告SDK在初始化时抛出了未捕获的异常：

FATAL EXCEPTION: main
Process: com.example.myapp, PID: 12345
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.myapp/.MainActivity}
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3190)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3325)
    ...
Caused by: java.lang.NullPointerException: 
    at com.thirdparty.ad_sdk.AdManager.init(AdManager.java:45)
    at com.example.myapp.MainActivity.onCreate(MainActivity.java:23)

这种情况下，你无法直接修复第三方SDK的源码，但可以做以下事情：

  1. 添加全局异常处理器，在崩溃前做一些善后工作：
class MyApplication : Application() {
    
    override fun onCreate() {
        super.onCreate()
        
        // 设置全局异常处理器
        Thread.setDefaultUncaughtExceptionHandler { thread, throwable ->
            // 记录崩溃日志
            Log.e("MyApp", "Uncaught exception in thread: ${thread.name}", throwable)
            
            // 上传崩溃报告到你的服务器
            CrashReporter.upload(throwable)
            
            // 退出应用
            android.os.Process.killProcess(android.os.Process.myPid())
            System.exit(1)
        }
    }
}
  1. 对第三方SDK的初始化进行保护：
fun safeInitThirdPartySdk() {
    try {
        AdManager.init(this)
    } catch (e: Exception) {
        Log.w("MyApp", "Failed to init AdManager, continuing without ads", e)
        // 广告SDK初始化失败，不影响主流程
    }
    
    try {
        PushManager.init(this)
    } catch (e: Exception) {
        Log.w("MyApp", "Failed to init PushManager", e)
    }
}
  1. 使用版本隔离，在build.gradle里配置SDK版本：
dependencies {
    // 锁定第三方SDK版本，避免自动升级引入新bug
    implementation 'com.thirdparty:ad-sdk:2.3.1'
    implementation 'com.thirdparty:push-sdk:1.8.0'
}

用工具提前发现问题

除了写代码时小心，还有很多工具可以帮你提前发现潜在问题：

1. LeakCanary - 自动检测内存泄漏

debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'

加这一行，LeakCanary会自动检测Activity和Fragment的内存泄漏，并在检测到泄漏时通知你。

2. Android Lint - 静态代码分析

在Android Studio里，点击Analyze > Inspect Code，Lint会检查代码中的各种问题，包括潜在的NPE、资源引用错误等。

3.StrictMode - 检测主线程违规

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .penaltyDeath()  // 检测到违规直接崩溃，方便调试
            .build()
    )
    StrictMode.setVmPolicy(
        StrictMode.VmPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build()
    )
}

注意penaltyDeath()只在Debug版本生效，线上版本不会有这个行为。

4. Crashlytics - 线上崩溃监控

implementation 'com.google.firebase:firebase-crashlytics:18.3.0'

配置好Crashlytics后，线上崩溃会自动上传到Firebase控制台，你可以看到崩溃的设备型号、系统版本、堆栈信息，甚至重现步骤。

崩溃日志怎么看

最后聊一个很实际的问题：崩溃日志到底怎么看？很多开发者看到一堆英文堆栈就头疼，但其实掌握几个技巧，大部分崩溃都能快速定位。

看崩溃日志的核心是找”Caused by”，这是真正抛出异常的地方。比如：

FATAL EXCEPTION: main
Process: com.example.myapp, PID: 8765
java.lang.NullPointerException: Attempt to invoke virtual method 
    'java.lang.String android.widget.TextView.getText()' on a null object reference
    at com.example.myapp.MainActivity.bindView(MainActivity.java:45)
    at com.example.myapp.MainActivity.onCreate(MainActivity.java:23)
    at android.app.Activity.performCreate(Activity.java:7802)
    ...
Caused by: java.lang.NullPointerException
    at com.example.myapp.MainActivity.bindView(MainActivity.java:45)

从这段日志你可以看到：

  • 崩溃在主线程发生
  • 是NullPointerException
  • 具体是在MainActivity.bindView()的第45行
  • 原因是尝试调用一个null对象的getText()方法

对应的代码可能是：

// 第45行
String text = tvName.getText().toString();  // tvName是null

而tvName为null，很可能是因为对应的布局文件里没有tv_name这个View，或者findViewById写错了ID。

总结几句

闪退这个问题，说难不难，说简单也不简单。核心就三点：

第一，判空要养成习惯。尤其是对从网络、数据库、Intent传来的数据，永远不要假设它们非空。

第二，线程问题要重视。UI操作必须回主线程，耗时操作必须放子线程，用协程、LiveData、ViewModel这些现代Android开发的标准工具，能避免80%的线程问题。

第三，善用工具。LeakCanary、Lint、StrictMode、Crashlytics，这些工具免费且强大，配置上花不了几分钟，但能帮你挡掉大量潜在问题。

开发这条路，没有人不踩坑。但每次崩溃都是一个学习机会，把问题搞清楚了，下次就不会再犯。共勉。

-- 展开阅读全文 --