CNN手写数字识别APP开发：从模型训练到zip打包部署全流程

简介：基于CNN的手写数字识别完整项目，面向深度学习初学者、课程设计或毕业设计人员，涵盖从模型训练到桌面应用部署的全流程。压缩包共30个文件，主要包含Python源码、预编译pyc、训练好的模型参数pkl、界面截图png、Windows可执行exe及说明文档，整体约34MB。其中network.py、layers.py等实现卷积网络结构，deep_convnet_params.pkl可直接加载使用，wx_app.py与exe提供图形界面，MNIST_Download.py用于数据准备。已有150人学习下载，适合参考CNN图像识别流程、wxPython界面封装以及模型持久化方法，可快速跑通演示并在此基础上扩展调优。

1. 基于CNN的手写数字识别APP：从MNIST模型到可交付的zip包

打开压缩包之前，你很难判断里面装的是一个能跑的工程，还是把Jupyter Notebook里的训练代码连同模型文件一起塞进了zip。手写数字识别这个任务本身已经被MNIST数据集研究得很透彻，CNN模型在测试集上跑到99%以上准确率早已不是新闻，真正的分水岭在于模型之外的部分：训练脚本、推理接口、端侧部署、依赖声明，以及解压后能不能在另一台机器上一键跑起来。这篇博文就以一个典型的“基于CNN的手写数字识别APP.zip”为讨论对象，把CNN骨架设计、训练验证、模型导出、应用封装和zip交付这条链路拆开讲清楚。适合准备做课程设计、毕业设计打包交付，或者第一次尝试把训练好的模型做成可分发应用的读者。

2. CNN骨架设计：从输入层到全连接层的参数怎么定

2.1 输入为什么是28×28灰度图

手写数字识别的标准入口是MNIST数据集，每张图片固定为28×28像素，单通道灰度。这个尺寸来自数据本身的采集条件，但从模型角度看，28×28也是一个刻意保持低计算量的选择：在CPU上训练一个中等规模的CNN，几分钟就能跑完一个epoch；换成224×224的ImageNet输入，同样的卷积层设计推理耗时至少翻几十倍。APP端如果要调用摄像头或手写板采集用户笔迹，预处理的第一步就是把任意尺寸的输入缩放并居中到28×28，灰度化后再归一化到[0,1]区间。这个固定输入尺寸意味着模型的第一层永远写成Input(shape=(28, 28, 1))，不要写成(784,)——虽然全连接层可以把图像拉平，但卷积层需要保留二维空间结构，通道数1表示灰度，RGB输入则需要额外做降维或改用3通道。

2.2 卷积核尺寸与层数：LeNet-5是起点但不是终点

大多数手写数字识别CNN都会参照LeNet-5的骨架：两层卷积加池化，再接三层全连接。LeNet-5用的是5×5卷积核和sigmoid激活函数，这在1998年算先进，放在今天却有两个明显问题。sigmoid在深层网络中容易梯度饱和，ReLU及其变体收敛快得多；5×5卷积核的感受野大，但参数量也大，MNIST这种简单任务用3×3堆叠两层就能得到相近的局部感受野，参数量却少了一半以上。常见的做法是第一层用32个3×3卷积核，第二层用64个3×3卷积核，每层后面接2×2最大池化。为什么是32和64而不是16和128？主要是权衡了特征表达能力和过拟合风险，MNIST类别少、图像简单，16个卷积核也能跑，但误识别率会明显上升；128个卷积核在训练集上表现更好，验证集上的收益却非常有限，说明特征已经冗余。

2.2.1 要不要加BatchNormalization

在卷积层和激活函数之间插入BatchNormalization，能显著稳定训练过程，尤其当你把学习率调得偏高时。BN层的作用是对每批数据的特征图做归一化，再通过可学习的缩放和平移参数恢复表达力。手写数字识别这种浅层网络，BN不是必须的，但加上之后对学习率的敏感度大幅降低，默认lr=0.001也能稳定收敛。代价是模型文件稍大一点，推理时会多几个BN相关的张量计算，在移动端CPU上的耗时增加可以忽略。建议训练时加BN，导出时留意一下算子是否被端侧框架完整支持。

2.3 Keras构建一个可复现的CNN基线

import tensorflow as tf from tensorflow.keras import layers, models model = models.Sequential([ layers.Input(shape=(28, 28, 1)), layers.Conv2D(32, (3, 3), padding='same'), layers.BatchNormalization(), layers.ReLU(), layers.MaxPooling2D((2, 2)), layers.Conv2D(64, (3, 3), padding='same'), layers.BatchNormalization(), layers.ReLU(), layers.MaxPooling2D((2, 2)), layers.Conv2D(128, (3, 3), padding='same'), layers.BatchNormalization(), layers.ReLU(), layers.GlobalAveragePooling2D(), layers.Dense(10, activation='softmax') ]) model.compile( optimizer=tf.keras.optimizers.Adam(learning_rate=1e-3), loss='sparse_categorical_crossentropy', metrics=['accuracy'] ) model.summary()

这里用了一层额外的3×3卷积，把网络加深到三个卷积块。GlobalAveragePooling2D替代了传统的Flatten加全连接层，直接对每个特征图求均值，输出形状从(batch, 7, 7, 128)变成(batch, 128)，参数量比Flatten加Dense(128)少很多，也天然降低了过拟合风险。最后接一个10分类的softmax层，对应数字0到9。sparse_categorical_crossentropy要求标签是整数编码而非one-hot，省去了手动转换。如果想复现LeNet-5那种更浅的结构，删掉第三个卷积块并把GlobalAveragePooling2D换成Flatten加Dense(128)即可，效果差异通常不超过0.2个百分点。

2.4 batch size、学习率与dropout的搭配

一个常见误区是盲目加大epoch数追求训练集准确率。训练到第10个epoch时，训练准确率可能已达99.8%，验证集却开始波动，说明模型开始记住训练集中的噪声。正确的做法是配合EarlyStopping，耐心值设为3~5个epoch，验证损失连续不下降就回滚到最佳权重。dropout和BN同时使用时，建议把dropout放在BN之后、激活之前，或者干脆把dropout只加在最后的Dense层之前，避免双重正则化导致欠拟合。

3. 训练与验证：手写体识别不是只有MNIST一种分布

3.1 数据增强的两个极端

MNIST本身是相当“干净”的数据集，数字居中、笔画规整、背景无噪声。但真实的手写输入不是这样：用户可能在画板边缘写字，笔画粗细不均，甚至带一点旋转。所以训练阶段就要通过数据增强模拟这种偏移。常用手段包括随机旋转15度以内、平移不超过2个像素、缩放0.9到1.1倍。过强的增强反而有害——MNIST的测试集本身也是规整的，旋转过大或加明显噪声会让验证准确率下降。实践中的做法是训练时用增强，验证时用原始数据，这样才能衡量模型真正的泛化能力。

datagen = tf.keras.preprocessing.image.ImageDataGenerator( rotation_range=10, width_shift_range=0.1, height_shift_range=0.1, zoom_range=0.1, rescale=1./255 ) # 注意：原始MNIST数据范围是0~255，需要先归一化 train_loader = datagen.flow(x_train, y_train, batch_size=64)

这里flow接收的是归一化前的数据，rescale=1./255在增强流程里顺带完成归一化，比训练前手动除以255更省事。rotation_range=10表示随机旋转范围是-10度到10度，width_shift_range=0.1表示水平平移最多10%的图片宽度（约2.8像素）。如果手写板采集到的笔画偏细，可以加一个brightness_range或者用形态学膨胀做预处理，但要注意增强后的数据分布必须贴近APP实际输入，否则模型学到的鲁棒性毫无意义。

3.2 验证策略：别只看整体准确率

MNIST分类准确率普遍在99%以上，一块混淆矩阵上没几个错分样本，但真正值得看的是哪些类别互相混淆。实践中经常出现3和8、4和9之间的错误，因为笔画结构太接近。打印混淆矩阵时建议按行归一化，观察每个类别的召回率——如果数字“8”的召回率明显低于“3”，说明卷积层对封闭圆环结构的特征表达不够，可能需要增加数据增强中弹性形变的比例，或者调整卷积核数量。

3.3 可直接运行的训练脚本骨架

import tensorflow as tf from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint, ReduceLROnPlateau (x_train, y_train), (x_test, y_test) = tf.keras.datasets.mnist.load_data() x_train = x_train.reshape(-1, 28, 28, 1).astype('float32') x_test = x_test.reshape(-1, 28, 28, 1).astype('float32') callbacks = [ EarlyStopping(monitor='val_loss', patience=4, restore_best_weights=True), ReduceLROnPlateau(monitor='val_loss', factor=0.5, patience=2, min_lr=1e-5), ModelCheckpoint('best_model.h5', monitor='val_accuracy', save_best_only=True) ] history = model.fit( datagen.flow(x_train, y_train, batch_size=64), validation_data=(x_test, y_test), epochs=30, callbacks=callbacks )

reshape(-1, 28, 28, 1)把原始的一维数组还原成四维张量，-1表示自动推导batch维度，最后的1表示灰度通道。astype('float32')是必须的，默认读入的uint8数据不能直接喂给TensorFlow的浮点卷积核。三个callback各司其职：EarlyStopping防止过拟合，ReduceLROnPlateau在验证损失停滞时把学习率减半，ModelCheckpoint只保存验证集上最好的权重。注意save_best_only=True配合restore_best_weights=True时，EarlyStopping结束后模型会自动恢复到最佳状态，不需要手动加载权重文件。

3.4 验证损失不降反升时先看什么

训练过程中如果验证损失在第5个epoch后开始反弹，优先检查是不是学习率过大。Adam虽然自适应调整步长，但初始学习率偏高时一样会跳过最优点。其次看BatchNormalization是否在使用validation_data时保持训练模式——这里用model.fit时框架会自动管理BN的推理模式，但如果你手工写训练循环，忘记切换model.trainable = False会导致验证时BN仍在使用训练统计量。最后检查数据增强是否泄漏到了验证集，fit里的validation_data参数不会经过datagen，但如果你错误地使用了datagen.flow(x_test, y_test)作为验证数据，增强变换会污染验证集的分布，造成验证准确率虚高或忽高忽低。

4. APP封装与zip打包：模型导出、依赖收录、解压即用

4.1 模型导出格式怎么选：H5、SavedModel、TFLite、ONNX

训练保存的best_model.h5适合继续训练和调试，但直接塞进APP有三个问题：文件大（一般20~80MB）、依赖TensorFlow完整环境、移动端无法直接加载。常见做法是导出成两种格式各留一份。Android端用TFLite量化模型，文件可压缩到1MB以内；桌面端用ONNX Runtime加载，避免安装整套TensorFlow。转换时最常踩的坑是自定义层和算子不被转换器支持，所以训练时尽量只用标准的Conv2D、BatchNormalization、ReLU、MaxPooling、Dense，不要在模型里塞Lambda自定义函数。

# 导出TFLite converter = tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations = [tf.lite.Optimize.DEFAULT] tflite_model = converter.convert() with open('model/digits.tflite', 'wb') as f: f.write(tflite_model) # 导出ONNX import tf2onnx import onnx spec = (tf.TensorSpec((None, 28, 28, 1), tf.float32, name="input")) onnx_model, _ = tf2onnx.convert.from_keras_model(model, input_signature=spec) onnx.save(onnx_model, "model/digits.onnx")

TFLite的Optimize.DEFAULT会尝试把权重从float32量化为float16，28×28输入这种小模型几乎无损。如果你需要更激进地把权重压缩到int8，转换时要提供代表性数据集做校准，否则量化后的准确率可能掉1~2个百分点。ONNX导出的input_signature必须和训练时的输入张量形状一致，批量维度写None表示动态batch，推理时可以一次喂多张图。

4.2 Android端TFLite推理的最小流程

val interpreter = Interpreter(loadModelFile(context, "digits.tflite")) val input = Array(1) { Array(28) { Array(28) { FloatArray(1) } } } val output = Array(1) { FloatArray(10) } interpreter.run(input, output) val result = output[0].indices.maxByOrNull { output[0][it] }

这段代码里，input的四维数组对应模型的(batch, height, width, channels)。真实手写板的输入分辨率可能是600×600，需要先在原生层缩放并居中到28×28，再做灰度化和归一化。缩放时用Matrix做仿射变换而不是简单resize，可以保持笔画比例不变。interpreter.run是同步阻塞调用，实测在低端Android机上单次推理耗时约5~15ms，完全够用。若使用InterpreterAPI的异步接口则在连续手写场景下更流畅，但注意TFLite 2.5以下版本对多线程支持不完整，容易出现无法解释的crash。

4.3 桌面端用ONNX Runtime跑推理

import onnxruntime as ort import numpy as np sess = ort.InferenceSession("model/digits.onnx", providers=["CPUExecutionProvider"]) def predict(img: np.ndarray) -> int: img = img.reshape(1, 28, 28, 1).astype(np.float32) / 255.0 outputs = sess.run(None, {"input": img})[0] return int(np.argmax(outputs[0]))

ONNX Runtime部署的核心优势是省掉了TensorFlow的依赖，pip install onnxruntime就能跑。sess.run的第一个参数传None表示输出全部节点，如果明确知道输出张量名，传输出名能省一次图遍历。CPUExecutionProvider可以显式指定，避免在无GPU机器上尝试加载CUDA provider而报错。没有装tf2onnx的环境，导出的ONNX就无法在这个Python脚本之外复用；所以zip包里除了模型文件，务必备一份requirements.txt。

4.4 zip包的目录结构、体积控制与解压坑

HandwrittenDigitsApp/ ├── android/ # Android Studio工程 │ ├── app/src/main/java/ │ └── app/src/main/assets/digits.tflite ├── desktop/ # Python桌面端 │ ├── main.py │ ├── requirements.txt │ └── model/digits.onnx ├── train/ # 训练脚本与数据说明 │ ├── train.py │ └── README.md └── docs/应用说明.pdf

zip打包最常见的两类问题：一是打包时把外层目录也包含进去，解压后变成HandwrittenDigitsApp/HandwrittenDigitsApp/android/...，用户运行脚本时路径就对不上；二是依赖文件缺失，只给了requirements.txt却没有onnxruntime的安装说明，换一台机器直接报ModuleNotFoundError。建议在根目录放一个README.txt，把Python版本、Android Studio版本、各依赖的安装命令写到前三行。压缩时在Windows上注意不要勾选“包含文件夹本身”，在Linux或macOS上用zip -r HandwrittenDigitsApp.zip HandwrittenDigitsApp/即可。体积控制上，TFLite量化模型通常不到1MB，ONNX模型约10~20MB，两个都放也不会让zip超过50MB，可放心同时保留。

5. 解压后冒烟测试：五步验证一个zip的可用性

5.1 检查模型文件路径与工程配置是否一致

解压后先在命令行进入根目录执行tree或列出目录结构，确认没有多套一层目录。然后检查Android工程的assets目录中确有一份tflite文件，且没有改过名字——main.py里如果写死了"model/digits.onnx"，文件放错位置会在启动时静默失败或抛FileNotFoundException。桌面端直接运行一次推理脚本，用下面这行命令生成一张测试图并预测：

python -c "import numpy as np, onnxruntime as ort; \ sess = ort.InferenceSession('model/digits.onnx'); \ x = np.zeros((1,28,28,1), dtype=np.float32); x[0,10:18,8:20,0]=1; \ print(np.argmax(sess.run(None, {'input': x})[0]))"

这段命令手写了一个近似的数字“0”形状，如果输出不是0，说明模型在训练和导出之间出了偏差，需要回到train.py检查预处理是否匹配。

5.2 核对依赖清单并准备一键安装脚本

zip交付后，用户大概率不会手动逐条安装依赖。常见的做法是在desktop目录下放一个setup.sh（Windows对应setup.bat），内容包含创建虚拟环境、安装requirements、启动GUI三个步骤。注意pine编写脚本时不要让路径带空格，如果用户解压到C:\Program Files，Python脚本里的相对路径会因含空格而异常。验证依赖的最快方式是pip install -r requirements.txt --dry-run，它只检查包是否可安装而不实际下载，几秒钟就能暴露包的版本兼容问题。

5.3 结论性检查（阅读用）

最终交付前，把zip解压到一个全新的目录，确保该机器上没有训练时的Python环境，只装README里指定的依赖，然后运行冒烟命令。这条验证路线能覆盖绝大多数交付失效场景：路径问题在第一步暴露，依赖问题在第二步暴露，模型导出问题在第三步被数字识别错误暴露。等到这五步全部通过，这个zip才算真正达到了“解压即用”的标准。

本文还有配套的精品资源，点击获取