Android应用指纹识别约百次后崩溃，涉及SQLite读取操作

听起来你遇到了一个典型的资源泄漏问题——毕竟循环100次才崩溃，这种渐进式的崩溃几乎都是未正确释放资源导致的。我来帮你拆解可能的原因和修复方向：

一、优先排查指纹SDK的资源泄漏 #

每次调用morphoDatabase.identify后，你大概率没释放本次识别产生的Native资源或临时对象：

• 很多指纹SDK在识别过程中会生成指纹捕获数据、模板对象或会话资源，这些资源往往是Native层面的，Java/Kotlin的GC无法自动回收。如果每次循环都不手动释放，内存会持续累积，到一定次数就触发崩溃。
• 检查SDK文档，找到识别完成后对应的释放方法，比如releaseCapture()、closeSession()或者销毁本次识别的结果对象。一定要把释放逻辑放在finally块里，确保即使识别出错也能执行。

示例代码（假设是Java环境）：

public void restartIdentification() {
    FingerprintResult result = null;
    try {
        result = morphoDatabase.identify();
        if (result.isSuccess()) {
            // 获取employeeId、查询SQLite、展示问候
            String employeeId = result.getEmployeeId();
            Employee emp = getEmployeeFromSQLite(employeeId);
            showGreeting(emp);
        }
    } catch (Exception e) {
        Log.e("Fingerprint", "识别失败", e);
    } finally {
        // 关键：释放本次识别的资源
        if (result != null) {
            result.release(); // 按SDK文档调用对应释放方法
        }
        // 重启识别流程
        restartIdentification();
    }
}

二、检查SQLite的连接与Cursor是否正确关闭 #

每次查询员工详情时，如果没妥善处理数据库连接和Cursor，也会导致内存堆积：

• 不要每次查询都新建SQLiteDatabase实例，建议用单例的DatabaseHelper复用连接；
• 无论查询成功与否，必须关闭Cursor——这是最容易被忽略的点，未关闭的Cursor会持续占用内存；
• 如果是临时打开的数据库连接，查询完成后要调用db.close()（单例Helper则不需要，由Helper管理连接池）。

示例优化后的SQLite查询：

private Employee getEmployeeFromSQLite(String employeeId) {
    Employee emp = null;
    Cursor cursor = null;
    SQLiteDatabase db = databaseHelper.getReadableDatabase();
    try {
        cursor = db.query("employees", 
                          new String[]{"id", "name", "dept"}, 
                          "id=?", 
                          new String[]{employeeId}, 
                          null, null, null);
        if (cursor.moveToFirst()) {
            emp = new Employee();
            emp.setId(cursor.getString(0));
            emp.setName(cursor.getString(1));
        }
    } catch (Exception e) {
        Log.e("SQLite", "查询员工失败", e);
    } finally {
        // 必须关闭Cursor
        if (cursor != null) {
            cursor.close();
        }
        // 单例Helper的话不需要关闭db，否则要调用db.close()
    }
    return emp;
}

三、排查循环逻辑中的内存泄漏 #

如果每次识别后展示问候的UI组件（比如弹窗、新View）没有被正确销毁，也会导致内存增长：

• 避免用匿名内部类持有外部Activity/Fragment的强引用，比如在问候弹窗的回调里，改用弱引用或者静态内部类；
• 如果是重复创建的临时UI对象，确保展示完成后及时从父容器移除或调用destroy()方法。

关键排查步骤 #

1. 看崩溃日志的堆栈信息：这是最直接的线索——如果是OutOfMemoryError，区分是Java堆还是Native内存不足；如果是Native崩溃（比如SIGSEGV），基本可以锁定是指纹SDK的资源没释放。
2. 用内存分析工具：比如Android Studio的Profiler或者Java的jmap，捕获崩溃前的内存快照，查看哪些对象在持续增长，定位泄漏点。

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