步态识别在Android设备上能否稳定工作，不能只看模型在公开数据集上的表现，更要看真实采集链路中传感器噪声、放置姿态和行走习惯带来的波动。测试的目标是确认系统在注册与验证阶段的数据分布是否一致，并评估分类器在不同时间、不同场景下对同一用户的识别能力。整个链路可以拆成三部分：传感器原始数据采集、步态特征提取、模型训练与推理。下面从工程角度把每一环的测试要点展开。

传感器数据采集与预处理

Android端通常使用加速度计和陀螺仪作为步态信号来源。加速度计反映直线运动的加速度变化，陀螺仪补充旋转角速度，二者组合可以刻画腿部摆动和躯干晃动的周期特征。测试时首先要确认采样率是否稳定，建议使用SENSOR_DELAY_GAME或SENSOR_DELAY_FASTEST，实际输出一般在50Hz到200Hz之间。如果采样率波动过大，后续按时间切分窗口时会出现长度不一致的问题，需要在缓冲队列中做时间戳对齐。

采集时手机应固定在同一位置，例如裤兜、腰间或手持，不同位置会导致坐标系方向变化明显。建议在数据预处理阶段将加速度计的三轴信号转换为模长，减少方向依赖。同时使用截止频率3Hz到5Hz的巴特沃斯低通滤波器去除高频抖动，保留步态主频成分。下面是一段Kotlin传感器监听代码，演示如何同时注册加速度计和陀螺仪并缓存带时间戳的数据。

class GaitSensorManager(context: Context) : SensorEventListener {
    private val sensorManager = context.getSystemService(Context.SENSOR_SERVICE) as SensorManager
    private val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    private val gyroscope = sensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE)
    private val buffer = ArrayList<FloatArray>()
    fun start() {
        sensorManager.registerListener(this, accelerometer, SensorManager.SENSOR_DELAY_GAME)
        sensorManager.registerListener(this, gyroscope, SensorManager.SENSOR_DELAY_GAME)
    }
    fun stop() {
        sensorManager.unregisterListener(this)
    }
    override fun onSensorChanged(event: SensorEvent) {
        val timestamp = System.currentTimeMillis().toFloat()
        when (event.sensor.type) {
            Sensor.TYPE_ACCELEROMETER -> {
                buffer.add(floatArrayOf(event.values[0], event.values[1], event.values[2], timestamp))
            }
            Sensor.TYPE_GYROSCOPE -> {
                // 可与加速度计按时间戳对齐后写入同一滑动窗口
            }
        }
    }
    override fun onAccuracyChanged(sensor: Sensor?, accuracy: Int) {}
}

预处理还包括去除重力分量。加速度计读数包含静态重力约9.8m/s²，通常用高通滤波器分离线性加速度，或者直接减去三轴滑动均值。对于步态识别，保留重力方向的分量有时也有用，例如手机在裤兜中的姿态变化能提供辅助信息。测试时可以对比仅用线性加速度、仅用模长以及三轴全量的效果，选择对位置变化更鲁棒的输入。

步态周期切分与特征选择

步态信号具有周期性，直接对固定长度窗口提取特征会遗漏相位信息。更合理的方式是先检测步态周期，例如根据加速度模长的波峰或过零点进行切分，再对每个周期提取统计量。常见特征包括均值、标准差、最大值、最小值、能量、过零率、主频率以及各轴相关系数。频域特征对噪声更敏感，但能较好区分步频差异。

特征提取可以在Android端实时完成，也可以把原始窗口上传到服务端处理。端侧推理通常倾向于轻量特征集，避免浮点开销过大。下面给出Python版本的窗口特征提取示例，便于离线训练时快速评估不同特征组合的效果。

import numpy as np
from scipy.fft import rfft, rfftfreq
def extract_features(window, fs=50.0):
    magnitude = np.sqrt(window[:, 0] ** 2 + window[:, 1] ** 2 + window[:, 2] ** 2)
    features = {}
    features['mean'] = np.mean(magnitude)
    features['std'] = np.std(magnitude)
    features['max'] = np.max(magnitude)
    features['min'] = np.min(magnitude)
    features['energy'] = np.sum(np.square(magnitude))
    features['zero_crossing'] = np.sum(np.diff(np.signbit(magnitude)))
    spectrum = np.abs(rfft(magnitude))
    freqs = rfftfreq(len(magnitude), d=1.0 / fs)
    if len(freqs) > 0:
        features['dominant_freq'] = freqs[np.argmax(spectrum)]
        features['spectral_centroid'] = np.sum(freqs * spectrum) / (np.sum(spectrum) + 1e-8)
    return features

测试时要注意窗口长度和步态周期长度是否匹配。成人正常步行一步大约0.8到1.2秒，如果设置固定窗口2秒，一个窗口内可能包含一个完整周期加半个周期，会造成特征偏移。建议先做步态检测，再进行变长窗口聚合。端侧实现可以用滑动窗口加峰值检测，将检测到的每一步作为独立样本，也可以用固定步数聚合来平衡样本数量。

模型训练与端侧推理

分类器可以选择SVM、随机森林或轻量神经网络。对于小规模用户集，统计特征加SVM通常表现稳定；用户数增加后，神经网络配合嵌入向量更适合开集识别。训练时必须按用户划分训练集和测试集，不能用随机打乱的方式，否则同一用户的相邻步态片段会同时出现在两方，导致准确率虚高。评估时还应增加跨会话测试，例如第一天采集注册数据，第二天再采集验证数据，观察时间间隔对性能的影响。

Android端部署模型通常使用TensorFlow Lite。训练完成后转换为.tflite文件，放入assets目录，推理时加载到Interpreter。输入张量按要求填充归一化特征，输出为各个候选用户的概率或距离。下面给出一个简化的端侧推理代码。

import org.tensorflow.lite.Interpreter
import java.io.FileInputStream
import java.nio.MappedByteBuffer
import java.nio.channels.FileChannel
fun loadModelFile(context: Context, modelName: String): MappedByteBuffer {
    val assetFileDescriptor = context.assets.openFd(modelName)
    val inputStream = FileInputStream(assetFileDescriptor.fileDescriptor)
    val fileChannel = inputStream.channel
    val startOffset = assetFileDescriptor.startOffset
    val declaredLength = assetFileDescriptor.declaredLength
    return fileChannel.map(FileChannel.MapMode.READ_ONLY, startOffset, declaredLength)
}
fun runInference(context: Context, features: FloatArray): Int {
    val tflite = Interpreter(loadModelFile(context, "gait_model.tflite"))
    val input = Array(1) { Array(features.size) { FloatArray(1) } }
    for (i in features.indices) {
        input[0][i][0] = features[i]
    }
    val output = Array(1) { FloatArray(NUM_CLASSES) }
    tflite.run(input, output)
    return output[0].indices.maxByOrNull { output[0][it] } ?: -1
}

测试时要把归一化参数固化到模型中或保存到配置文件。如果训练时用标准分数归一化，端侧必须使用同一套均值和标准差，否则输入分布偏移会导致准确率骤降。除了普通分类准确率，还应关注等错误率，即调节阈值使误拒率与误接受率相等时的值。实机测试建议采集至少20名用户、每人多天多场景的数据，否则样本量太小无法暴露过拟合问题。

常见误区与工程优化

第一个误区是只测理想条件下的识别率。手机放在口袋且用户按固定速度行走时，步态识别准确率可以很高，但一旦换成手持、背包或慢跑，模型可能迅速退化。测试必须覆盖不同放置位置和行走速度，最好在训练集中加入位置标签或做数据增强。第二个误区是忽略传感器校准。不同设备的加速度计零偏和灵敏度不同，换一台设备后特征值整体偏移，因此跨设备测试前应做简单的零点校准。

工程优化方面，可以在注册阶段采集多段步态数据并做聚类，剔除异常片段，保留最能代表用户步态模式的模板。推理时采用滑动窗口连续判断，当连续多个窗口都指向同一用户时才给出认证结果，降低单次误判。若部署在低端设备上，可以用Sensor.TYPE_LINEAR_ACCELERATION替代原始加速度计，减少重力过滤计算，但要注意部分设备该虚拟传感器输出噪声更大。最终系统上线前还应加入重放攻击测试，确认模型不会被提前录制的步态信号欺骗。

综合来看，Android步态识别测试的核心不是把模型跑通，而是建立一套可控的采集、切分、评估和抗干扰验证流程。只有把传感器数据质量、用户独立性划分和跨场景泛化都纳入测试指标，才能判断步态识别是否真的适合作为移动端生物认证的一种补充方案。