1. 环境准备：从零搭建Arm开发板OCR部署基础
第一次在Arm开发板上部署OCR模型时，我踩过最深的坑就是环境配置。当时用RK3399开发板折腾了整整三天，现在回想起来，其实只要掌握几个关键点就能事半功倍。咱们先从最基础的硬件软件准备说起。
硬件需求方面，你需要准备：
- 一台x86架构的Ubuntu主机（建议18.04或20.04版本），这是我们的交叉编译环境
- Arm架构的开发板（比如RK3328/RK3399树莓派等），内存建议不小于1GB
- 稳定的串口调试工具或SSH连接
软件工具链的选择很有讲究。我强烈推荐使用开发板厂商提供的原生工具链，比如瑞芯微的RK3328工具链就包含在官方SDK里。这样能避免90%的兼容性问题。具体路径通常在prebuilts/gcc/linux-x86/aarch64目录下，记下这个路径，后续编译会用到。
提示：如果开发板没有提供专用工具链，可以尝试Linaro官方发布的aarch64-linux-gnu工具链，但要注意glibc版本匹配问题
安装基础依赖项时，这几个包必不可少：
sudo apt-get install -y git cmake wget unzip \ libopencv-dev protobuf-compiler libblas-dev2. Paddle-Lite预测库的获取与验证
获取Paddle-Lite预测库有两种主流方式，我两种都试过，下面说说实际体验。
预编译库下载是最快捷的方式。Paddle官方提供了各版本的预编译库，关键要看清这几个标签组合：
armv8（对应64位Arm处理器）with_extra=ON（包含完整算子支持）with_cv=ON（启用OpenCV扩展）
下载解压后会得到两个关键目录：
cxx/：包含头文件和动态库demo/：示例代码
源码编译虽然耗时但更灵活。我推荐用Docker容器来保持环境纯净：
git clone https://github.com/PaddlePaddle/Paddle-Lite.git cd Paddle-Lite git checkout release/v2.9 # 选择稳定分支 ./lite/tools/build.sh \ --arch=armv8 \ --with_cv=ON \ --with_extra=ON \ build_armlinux实测发现源码编译时最容易卡在OpenCV链接环节。有个小技巧：提前设置-DOPENCV_ROOT参数指向本地OpenCV安装路径，能节省大量排查时间。
3. 项目工程化：让OCR跑起来的完整流程
拿到预测库后，真正的挑战才开始。我们需要把PaddleOCR的Lite部署代码、模型文件和预测库有机整合。下面是我总结的最佳实践：
目录结构设计直接影响后续维护成本。建议采用这样的布局：
paddle_lite_ocr/ ├── cxx/ # Paddle-Lite预测库 ├── models/ # 模型文件 │ ├── det_opt.nb # 检测模型 │ ├── rec_opt.nb # 识别模型 │ └── keys.txt # 字典文件 ├── thirdparty/ # 第三方依赖 ├── CMakeLists.txt # 构建配置 └── src/ # 源代码模型优化是很多人忽略的关键步骤。PaddleOCR提供的原始模型需要经过opt工具转换：
./opt --model_file=ch_ppocr_mobile_v2.0_det_infer/model \ --param_file=ch_ppocr_mobile_v2.0_det_infer/params \ --optimize_out=det_opt \ --valid_targets=arm在编写CMakeLists.txt时，这几个参数必须准确设置：
set(ARMLINUX_ARCH_ABI armv8) # 与工具链架构一致 set(LITE_DIR "${CMAKE_SOURCE_DIR}/cxx") include_directories(${LITE_DIR}/include) link_directories(${LITE_DIR}/lib)4. 开发板实战：部署与性能调优
把编译好的可执行文件通过adb push到开发板后，先别急着运行。这几个依赖项必须提前部署：
- OpenCV共享库：将交叉编译好的libopencv_*.so放入/usr/lib
- Paddle-Lite运行时：拷贝libpaddle_light_api_shared.so到板端
- 模型文件：确保路径与程序参数一致
运行测试时建议先用静态图片验证：
./ocr_system ./models/det_opt.nb \ ./models/rec_opt.nb \ test_image.jpg \ ./models/keys.txt性能优化方面，我在RK3328上实测得出这些经验：
- 启用OpenMP多线程能提升30%速度
- 调整检测模型阈值可平衡准确率与误检率
- 输入图像resize到640x640时性价比最高
遇到内存不足时，可以尝试修改config.txt中的这两个参数：
max_side_len 960 # 减小输入尺寸 use_mkldnn 0 # 关闭MKLDNN加速最后说说真实场景下的表现：在RK3328上处理一张1080p图片平均耗时约1.2秒，内存占用稳定在300MB左右。虽然比不上服务器端的性能，但对于嵌入式场景已经足够实用。
