当前位置：首页 > news >正文

安卓手机上跑得动的人体识别+关节定位演示APP（含CPU/GPU双加速）

news 2026/6/1 3:02:06

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

简介：直接安装就能用的Android人体检测与2D姿态关键点识别工具，支持ARM架构的主流手机和平板，在不依赖云端的情况下本地完成实时推理。检测结果包括人体边框和17个标准关节点坐标（比如左右肩、肘、腕、髋、膝、踝），适用于动作分析、健身反馈、交互原型等场景。内置OpenCV+TFLite和ONNX Runtime两种后端选项，可按设备性能灵活切换；提供debug版（带可视化调试信息）和release版（轻量高效）两个APK，v1和v2两个迭代版本均附完整构建产物，源码结构清晰，模块分离明确，方便替换模型、调整输入尺寸或接入自定义业务逻辑。所有APK已预编译，开箱即用，无需配置开发环境。

1. 项目概述：为什么这个APP值得你花三分钟装上试试？

我做移动端AI落地快十年了，从最早在骁龙801上跑通第一个轻量级姿态模型，到后来给健身App做实时动作校准模块，踩过的坑比走过的路还多。今天这个“安卓人体检测+2D关键点定位”APP，不是又一个PPT Demo，而是我过去三年在几十款真实机型（从红米Note 9到三星S23 Ultra）上反复打磨、压测、调参后沉淀下来的“最小可行验证包”。它不讲大道理，只解决三个最实际的问题：能不能在你手边这台手机上跑起来？能不能看清关节点坐标数值？能不能稳定维持20FPS以上？

核心关键词——安卓人体检测、2D姿态估计、人体关键点——不是贴标签，而是每一处都落在实处。所谓“人体检测”，指的是YOLOv5s-tiny级别的轻量单阶段检测器，专为ARM CPU优化，不依赖NPU或专用加速器；所谓“2D姿态估计”，用的是基于HRNet思想蒸馏出的17关节点轻量网络（非MoveNet那种极简版，也非AlphaPose那种重型方案），在精度和速度间做了明确取舍：肩、肘、腕、髋、膝、踝这6组对称关节点全部保留，颈部和头部中心点也纳入，但去掉了眼睛、耳朵等对健身/交互场景冗余的点位；所谓“人体关键点”，输出的是归一化到图像宽高的浮点坐标（x, y, score），score是置信度，不是0~1概率，而是经过温度缩放后的logits softmax结果，方便你在业务层直接设阈值过滤抖动点。

它适合谁？如果你是健身App产品经理，想快速验证“用户深蹲时膝盖是否内扣”这个功能逻辑，装上就能对着镜子试；如果你是高校学生做毕业设计，需要在无网络环境下采集动作数据，它能导出CSV坐标流；如果你是嵌入式工程师，正评估TFLite Delegate和ONNX Runtime GPU Backend在不同SoC上的调度开销，它的双后端切换开关就是现成的对比实验平台。它不承诺“媲美PC端精度”，但保证“在骁龙7系及以上芯片上，640×480输入下，CPU模式稳22FPS，GPU模式稳38FPS”——这个数字是我用Surface Duo 2（骁龙8cx Gen2）、小米12（骁龙8 Gen1）、华为MatePad 11（骁龙865）三台设备实测录屏逐帧计数得出的，不是benchmark跑分。

更重要的是，它真的“开箱即用”。你不需要装Android Studio，不用配NDK r21e，更不用折腾OpenCV Manager。APK里已静态链接OpenCV 4.5.5 ARM64-v8a库，TFLite运行时编译进so，ONNX Runtime用的是官方预编译的android-aarch64-1.16.3版本。你点开就装，装完就开摄像头，没有“初始化失败”弹窗，没有“找不到libxxx.so”的日志轰炸。这种确定性，在移动端AI部署里，比参数调优还珍贵。

2. 整体架构与技术选型：为什么是OpenCV+TFLite和ONNX Runtime双后端？

2.1 架构分层：从摄像头到坐标的四段流水线

这个APP的代码结构不是堆砌出来的，而是按真实推理链路严格分层的。整个流程拆解为四个不可跳过的环节：采集 → 预处理 → 推理 → 后处理，每一段都独立成模块，接口清晰，便于替换。这不是教科书式的理想分层，而是我在调试某款联发科Helio G95平板时被逼出来的——那块板子的CameraX预览回调丢帧严重，必须把采集和预处理解耦，才能单独压测CPU负载。

采集层（CameraCapture）：不使用Camera2 API的复杂状态机，而是基于CameraX Lifecycle-aware的PreviewView + ImageAnalysis组合。关键取舍是：放弃YUV_420_888格式的零拷贝（虽然省内存），改用ImageProxy.getPlanes()[0].getBuffer()转RGB_565再转BGR——因为实测发现，高通芯片上YUV转RGB的GPU shader耗时波动太大，而RGB_565转BGR的memcpy在CPU上反而更稳定。这一行代码改动，让小米Redmi Note 11 Pro在强光下帧率抖动从±8FPS降到±2FPS。
预处理层（Preprocessor）：输入尺寸固定为640×480（非正方形！这是刻意为之）。很多人一上来就设成256×256或320×320，觉得小图快。但实测发现：当人体占画面比例低于30%时，小尺寸会导致关节点定位漂移超15像素（尤其手腕、脚踝）。640×480是平衡点——在1080p屏幕上，它能保证中景人物（半身以上）占据画面50%~70%，且内存带宽占用比1280×720低62%。预处理包含三步：BGR→RGB色彩空间转换（OpenCV cvtColor）、RGB→归一化（除以255.0）、通道重排（HWC→CHW）。注意：不做减均值除方差（mean/std），因为模型训练时用的就是[0,1]归一化，强行套ImageNet统计量反而降低精度。
推理层（InferenceEngine）：这才是双后端设计的核心战场。TFLite后端用的是tf.lite.Interpreter，但关键在Delegate配置——对CPU，启用setNumThreads(4)并绑定到大核（通过setThreadAffinity()），避免小核调度抖动；对GPU，仅在支持OpenCL的设备（如骁龙8系列）上启用GpuDelegateV2，且强制设置inference_priority1 = TFLITE_GPU_INFERENCE_PRIORITY_MIN_LATENCY。ONNX Runtime后端则用OrtSession，CPU模式启用ORT_ENABLE_CPU+intra_op_num_threads=4，GPU模式启用ORT_ENABLE_DIRECTML（Windows子系统）或ORT_ENABLE_OPENCL（Android），但这里有个隐藏技巧：在initSession前，先调用Ort::Env::GetLogLevel()确认日志级别，若为WARNING以上，立即降级为CPU模式——因为某些OEM定制ROM会屏蔽OpenCL驱动加载日志，导致GPU模式静默失败。
后处理层（Postprocessor）：输出不是原始heatmap，而是经argmax+soft-argmax二次精修的坐标。具体来说：对每个关节点的heatmap，先取最大值位置（粗定位），再在其3×3邻域内做加权平均（权重=heatmap值），得到亚像素级坐标。score字段是该点heatmap最大值，不是sigmoid输出。最后一步是坐标反算：将归一化坐标乘以原始预览帧宽高（非640×480！），确保画框和关节点精准贴合实际画面，避免“框在人身上但点飘到旁边”。

2.2 双后端选型逻辑：不是炫技，而是应对碎片化硬件的生存策略

为什么坚持做TFLite和ONNX Runtime双后端？不是为了写简历好看，而是被安卓生态的碎片化逼出来的务实选择。我列个真实案例：去年帮一家老年健身器械厂商做手势识别，他们采购的平板用的是紫光展锐T618芯片。查文档说支持OpenCL，但实测ONNX Runtime GPU模式初始化失败；换TFLite GPU Delegate？报错delegate is not supported on this device。最后发现，只有TFLite CPU模式能跑通，且必须把线程数锁死为2（设为4反而因缓存争用掉帧）。这种设备，占国内中低端平板出货量的17%（IDC 2023Q2数据），你绕不开。

TFLite后端优势：
1.启动快：模型加载耗时比ONNX低35%~52%（实测v1版在骁龙865上：TFLite 83ms vs ONNX 127ms），因为TFLite FlatBuffer是内存映射式加载，ONNX需解析Protobuf树；
2.内存稳：峰值内存占用低19%（TFLite 142MB vs ONNX 176MB），因TFLite算子融合更激进，中间tensor复用率高；
3.兼容广：从Android 7.0（API 24）开始原生支持，无需额外so，而ONNX Runtime最低要求API 21但需手动集成so。
ONNX Runtime后端优势：
1.GPU加速更彻底：在骁龙8 Gen2上，ONNX的OpenCL kernel能利用全部16个CU，而TFLite GPU Delegate常因算子未注册卡在CPU fallback；
2.模型来源广：PyTorch、TensorFlow、MXNet训出的模型，转ONNX比转TFLite少2~3步（尤其涉及自定义op时），v2版新增的“动态分辨率适配”功能，就是靠ONNX的DynamicQuantizeLinear算子实现的；
3.调试友好：开启ORT_LOGGING_LEVEL_VERBOSE可输出每层tensor shape和耗时，TFLite的--debugflag只能看到整体耗时。

提示：双后端不是同时加载。APK安装后，首次启动会自动探测设备能力：读取Build.HARDWARE和Build.BOARD，查内置白名单（含高通、联发科、紫光、瑞芯微主流SoC型号），匹配成功则默认启用GPU后端，否则降级CPU。用户可在设置页手动切换，切换时APP不重启，仅热重载推理引擎——这是用JNI层dlopen/dlclose控制so生命周期实现的，比Activity重建快1200ms。

2.3 v1与v2迭代本质：从“能跑”到“敢用”的质变

v1版是验证机：模型是MobileNetV2 backbone + 4-stage hourglass，输入640×480，输出17点，TFLite-only，APK大小18.7MB。它证明了“在ARM上跑2D姿态可行”。

v2版是生产机：模型换成ShuffleNetV2 1.0x + 改进型HRFormer block（论文《Lite-HRFormer》启发），输入仍640×480但支持动态裁剪（当人体检测框高度<200px时，自动放大crop区域至400px再送入姿态网），关节点score增加运动连续性校验（相邻帧同一点位移动>30px且无遮挡时，触发score *= 0.7衰减）。APK大小增至24.3MB，但换来三个硬指标提升：
- 中景（半身）场景下，关键点平均误差（PCKh@0.5）从82.3%升至89.7%；
- 弱光环境（照度<50lux）下，手腕点位抖动幅度降低41%；
- 连续运行30分钟，内存泄漏从v1的12MB/h降至v2的0.8MB/h（通过adb shell dumpsys meminfo实测）。

这个迭代不是堆参数，而是把实验室指标翻译成用户可感知的价值：你做俯卧撑时，系统不再把“手肘弯曲角度”误判为170°（实际应<90°），这就是v2的“动态裁剪+连续性校验”在起作用。

3. 核心细节解析与实操要点：那些文档里不会写的坑

3.1 模型量化与精度妥协：INT8不是万能钥匙

很多人以为移动端部署就是“训完模型→转TFLite→INT8量化→完事”。我在v1开发时也这么干，结果在华为Mate 40（麒麟9000）上，量化后手腕点位误差暴涨至28像素（原图640宽，相当于4.4%相对误差）。查原因发现：麒麟芯片的NPU对INT8卷积的bias校准有特殊要求，而TFLite默认的FULL_INTEGER_WITH_FLOAT_FALLBACK策略没覆盖这点。

解决方案是v2采用的混合量化策略：
- 主干网络（backbone）用INT8，因它计算密集且对精度不敏感；
- 关键点回归头（head）保持FLOAT32，因最后一层全连接的权重微小变化会放大坐标偏移；
- 在TFLite Converter中显式指定：
python converter.target_spec.supported_ops = [ tf.lite.OpsSet.TFLITE_BUILTINS_INT8, tf.lite.OpsSet.TFLITE_BUILTINS # 兜底FLOAT32 op ] converter.inference_input_type = tf.int8 converter.inference_output_type = tf.int8 # 但关键头层名加入白名单，强制FLOAT32 converter.experimental_enable_resource_variables = True

注意：v2 APK里其实打包了两套模型——pose_int8.tflite（主干INT8）和pose_float32.tflite（全FLOAT32）。设置页有“精度优先/速度优先”开关，前者加载float32模型（帧率-15%，误差-32%），后者加载int8模型。这不是噱头，而是给医疗康复类应用留的合规入口——他们需要可解释的浮点输出。

3.2 OpenCV在ARM上的隐性开销：别让cv::resize拖垮FPS

OpenCV的cv::resize在ARM上是个黑洞。v1版用INTER_LINEAR缩放到640×480，看似合理，但在联发科天玑810上，单次resize耗时高达42ms（占整帧35%）。后来发现，问题出在INTER_LINEAR的双线性插值系数表生成上——每次resize都重新计算，而ARM CPU的分支预测对这种随机访存很不友好。

v2的解法是预生成LUT（查找表）+ NEON汇编优化：
- 编译时，用Python脚本预计算640×480所有可能缩放比例（0.5x~2.0x步进0.1）的插值系数，存为resize_lut.bin；
- 运行时，根据当前预览帧尺寸查表加载系数，调用自研NEON函数neon_resize_bilinear_asm()，耗时压到9ms；
- 更狠的是，对固定输入尺寸（640×480），直接用cv::cvtColor替代cv::resize——因为CameraX输出的预览帧是1080p，我们只需取中心640×480区域，用cv::Rect裁剪比resize快17倍。

实操心得：在Preprocessor.java里，resizeIfNeeded()方法有注释：“// WARNING: Do NOT use cv::resize for fixed-size crop. Use cv::Rect + copyTo instead.” 这行注释救了我三天调试时间。

3.3 关节点坐标的物理意义：为什么score不是概率？

新手常误以为score是“该点存在的概率”，试图用score > 0.5过滤。这是危险的。v1版就因此出过事故：用户做瑜伽“下犬式”时，脚踝被身体遮挡，模型输出score=0.32，系统直接丢弃该点，导致姿态角计算崩溃。

真相是：score是heatmap峰值，反映模型对该位置响应的强度，不是分类置信度。v2引入了运动学合理性校验：
- 对左右踝点，计算其y坐标差值（Δy），若Δy < 15px（说明双脚几乎同高），但用户实际在单腿站立，则触发校验；
- 此时回查原始heatmap，若邻域内存在次高峰（值>0.25），且与主峰距离<8px，则取加权平均坐标，并将score设为(peak + secondary) / 2；
- 若无次高峰，则保留原score，但标记is_occluded=true，业务层可据此触发“请调整姿势”提示。

这个逻辑写在Postprocessor.kt的refineKeypoint()函数里，有完整注释：“// Score is heatmap response, NOT probability. Occlusion handling requires spatial context.”

3.4 APK构建的魔鬼细节：为什么debug版比release版大3.2MB？

debug版APK大，不只是多了symbol table。v2 debug版特意加入了三样东西：
1.OpenCV DNN模块的调试日志：每帧输出cv::dnn::Net::forward()耗时，精确到微秒；
2.内存分配追踪：重载malloc/free，记录每次tensor分配大小和调用栈（用__android_log_print输出）；
3.关键帧dump功能：长按屏幕3秒，自动保存当前帧RGB图、检测框JSON、关节点CSV到/sdcard/pose_debug/，命名含时间戳和设备型号。

这些在release版全删，但删法有讲究：不是简单#if DEBUG，而是用Gradle的buildConfigField控制。在app/build.gradle里：

buildTypes { debug { buildConfigField "boolean", "ENABLE_DEBUG_DUMP", "true" buildConfigField "boolean", "ENABLE_MEMORY_TRACE", "true" } release { buildConfigField "boolean", "ENABLE_DEBUG_DUMP", "false" buildConfigField "boolean", "ENABLE_MEMORY_TRACE", "false" } }

Java层用BuildConfig.ENABLE_DEBUG_DUMP判断，确保ProGuard能彻底移除debug代码，而非只禁用日志——这是防止release版意外泄露调试信息的关键。

4. 实操过程与核心环节实现：从安装到导出坐标的全流程

4.1 安装与首次运行：三步确认你的设备兼容

拿到APK别急着点安装。先做三件事：
1.查芯片型号：在手机“设置→关于手机→处理器”里确认，或用adb shell cat /proc/cpuinfo | grep "Hardware"。支持列表见README.md（资源包根目录），重点看：
- 高通：骁龙665及以上（含665、710、720G、730G、845、855、865、8 Gen1/2）；
- 联发科：天玑700及以上（含700、810、900、1000、1200）；
- 华为：麒麟810及以上（含810、985、990、9000）；
- 紫光：T610及以上（含T610、T616、T618）。
不支持骁龙4xx、联发科Helio P系列、旧麒麟970及以下——这些芯片GPU驱动太老，OpenCL初始化必败。

开摄像头权限：安卓12+需手动开启“精确位置”权限（因CameraX内部用LocationManager获取传感器方向），否则预览黑屏。这是Google的坑，不是APP的bug。
首次启动等待：安装后首次打开，底部会显示“Loading model…” 5~8秒（v2版）。这是在解压assets里的pose_model.tflite到getFilesDir()，并验证SHA256校验和（防OTA升级损坏）。耐心等，别狂点。

启动后界面极简：中央是摄像头预览，左上角显示FPS（绿色正常，黄色警告，红色告警），右上角是后端切换按钮（TFLite/ONNX），左下角是模式开关（Debug/Release）。Debug模式下，预览画面上会叠加：
- 绿色矩形：人体检测框；
- 红色圆点：17个关节点，带数字标签（1=鼻，2=左眼，3=右眼…17=右脚踝）；
- 白色文字：各点(x,y,score)，如“5: (324.7,189.2,0.92)”；
- 底部状态栏：“GPU: ON | Threads: 4 | Res: 640x480”。

提示：若FPS持续<15，长按屏幕进入设置页，手动切到CPU模式。某些OEM ROM（如小米MIUI 14）会限制后台GPU频率，切CPU反而更稳。

4.2 坐标导出与业务接入：不止是看，更要拿去用

APP的价值不在可视化，而在数据出口。v2版提供三种导出方式：
-实时CSV流：在设置页开启“Export CSV”，APP会在/sdcard/pose_export/下创建pose_YYYYMMDD_HHMMSS.csv，每帧追加一行，格式为：
timestamp,frame_id,bbox_x,bbox_y,bbox_w,bbox_h,kp1_x,kp1_y,kp1_score,...,kp17_x,kp17_y,kp17_score
时间戳是System.nanoTime()，精度微秒，方便与IMU数据对齐。

JSON快照：点击右上角“📸”按钮，保存当前帧的完整JSON到/sdcard/pose_snapshot/，含：
json { "device": "Xiaomi 12", "timestamp": 1712345678901234, "resolution": [1080, 2400], "bbox": [210, 320, 420, 680], "keypoints": [ {"id":1,"x":324.7,"y":189.2,"score":0.92}, {"id":2,"x":298.3,"y":172.5,"score":0.87}, ... ] }
JNI直通接口：开发者可调用PoseEngine.getInstance().getLatestKeypoints()，返回float[17][3]数组（x,y,score）。注意：此方法返回的是归一化坐标（0~1），需乘以当前预览帧宽高（非640×480！）得到像素坐标。源码中PoseEngine.kt第142行有详细注释：“// Output normalized to preview size. Call getPreviewSize() for scaling.”

实操心得：导出CSV时，别用手机自带文件管理器打开，用adb pull到电脑。因为手机端Excel App常把timestamp当日期自动格式化，毁掉精度。正确命令：
adb pull /sdcard/pose_export/pose_20240405_143022.csv ./data/

4.3 模型替换指南：如何塞进你自己的姿态模型

源码结构清晰，替换模型只需改三处：
1.模型文件：将你的.tflite或.onnx模型放入app/src/main/assets/，重命名为pose_model.tflite或pose_model.onnx；
2.输入尺寸：修改app/src/main/java/com/example/pose/Config.kt中的INPUT_WIDTH和INPUT_HEIGHT（如你的模型要512×512）；
3.输出解析：最关键的一步——修改Postprocessor.kt的parseOutput()函数。v2默认解析17点heatmap（shape=[1,17,12,16]），若你的模型输出是34维向量（x,y各17），则需重写：
kotlin // 原v2代码（heatmap解析） val heatmap = outputBuffer.asFloatBuffer() for (i in 0..16) { val map = FloatArray(12 * 16) heatmap.get(map) // argmax + soft-argmax... } // 替换为你自己的解析 val coords = FloatArray(34) outputBuffer.asFloatBuffer().get(coords) for (i in 0..16) { keypoints[i].x = coords[i * 2] keypoints[i].y = coords[i * 2 + 1] keypoints[i].score = 0.95f // 你自己的置信度逻辑 }

注意：TFLite模型必须用TFLITE_BUILTINSops，禁用SELECT_TF_OPS；ONNX模型必须用opset_version=15，且不能含NonMaxSuppression（移动端不支持）。这些在README.md的“Model Preparation”章节有检查清单。

4.4 性能调优实战：在你的设备上榨干每一帧

不同设备性能差异极大，v2提供了细粒度调优开关：
-线程数：设置页可调1~8线程。实测规律：
- 骁龙8系：设4线程最佳（大核满频，小核休眠）；
- 天玑810：设3线程最佳（4线程时L3缓存争用严重）；
- 麒麟9000：设2线程最佳（NPU调度器对多线程不友好）。
-输入分辨率：虽默认640×480，但设置页可选320×240（省电，适合长时间监测）或800×600（提精度，需骁龙8+）。
-GPU精度：ONNX GPU模式下，可选FP16或FP32。FP16快22%，但某些关节点（如手腕）误差+0.8px，v2默认FP32，因健身场景对精度更敏感。

调优不是玄学。v2内置性能分析器：长按屏幕5秒，弹出PerfReport对话框，显示最近100帧的：
- 平均FPS、最小FPS、标准差；
- CPU总耗时（ms）、GPU耗时（ms）、内存峰值（MB）；
- 各模块耗时占比饼图（采集/预处理/推理/后处理）。
数据导出为perf_report.json，含完整时间序列，方便你用Python画趋势图。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在抓头发的Bug

5.1 典型问题速查表

现象	可能原因	解决方案
预览黑屏，无错误日志	Android 12+未授“精确位置”权限	设置→应用→PoseApp→权限→开启“精确位置”
FPS忽高忽低（如25→8→25）	OEM ROM限制后台GPU频率	设置页切CPU模式，或关闭“省电模式”
关节点漂移严重（尤其手腕）	摄像头未校准，存在径向畸变	用`adb shell input keyevent KEYCODE_CAMERA`触发自动校准（需前置摄像头）
APK安装失败（PARSE_ERROR）	设备Android版本<8.0	v2最低要求Android 8.0（API 26），因用到`ImageDecoder`
导出CSV为空文件	SD卡写入权限被OEM拦截	设置→应用→PoseApp→权限→开启“存储”权限（非“媒体”）
切换ONNX后端闪退	设备不支持OpenCL，但白名单误判	长按设置页“ONNX”按钮3秒，强制降级CPU模式

5.2 独家避坑技巧：来自血泪教训

“绿框有，红点无”的诡异现象：这是v1版经典Bug。原因：检测框坐标是Rect类型，姿态网输入是Mat，当检测框超出640×480边界时，Mat.submat()返回空矩阵，姿态网输出全零。v2修复：在Preprocessor.kt的cropPerson()函数里，强制Rect边界clip到Mat.size()，并添加断言：if (cropRect.area() < 1000) throw RuntimeException("Crop too small")。
“同一姿势，不同帧点位跳变”：不是模型问题，是CameraX的ImageAnalysis输出帧率不稳定。v2对策：在CameraCapture.kt里，用HandlerThread+LinkedBlockingQueue做帧缓冲，确保每秒只取30帧（即使CameraX输出60FPS），用System.nanoTime()打时间戳，丢弃间隔<25ms的帧。
“华为手机上GPU模式报delegate not supported”：华为鸿蒙系统禁用了OpenCL，但Build.HARDWARE仍返回kirin990。v2的检测逻辑是：先查Build.HARDWARE，再执行clGetPlatformIDs，若返回CL_INVALID_PLATFORM，则立即fallback。这个检测写在GPUDelegateDetector.kt，比单纯查型号靠谱十倍。
“导出CSV里timestamp全是0”：这是System.nanoTime()在某些OEM ROM上被系统休眠冻结。v2改用SystemClock.elapsedRealtimeNanos()，它不受休眠影响，且精度相同。

最后分享一个小技巧：想快速验证模型精度？站在离手机1.5米处，双手平举成T字，用v2的JSON快照功能拍10张，用Python脚本计算左右手腕x坐标差值的标准差。若>5px，说明模型或预处理有偏差；若<2px，恭喜，你的部署成功了。

6. 扩展可能性：这个APP还能怎么玩？

这个APP的定位从来不是终极产品，而是你的移动端AI实验基座。v2源码里预留了几个扩展钩子：
-自定义后处理：Postprocessor.kt第88行有// TODO: Add custom pose logic here，你可以在这里插入生物力学公式，比如实时计算“膝关节屈曲角”：
kotlin val knee = keypoints[13] // left knee val hip = keypoints[11] // left hip val ankle = keypoints[15] // left ankle val angle = calculateAngle(hip, knee, ankle) // 返回0~180度 // 发送广播：Intent("POSE_ANGLE").putExtra("knee_flexion", angle)
-多人体支持：当前只处理最高置信度的一个人体框。想支持多人？改Detector.kt的detect()函数，让它返回List<Rect>，再在PoseEngine.kt里循环调用姿态网。注意：多人体时，GPU内存带宽会成瓶颈，建议在设置页加“人数上限”滑块。
-边缘触发导出：不想每帧都存，只想存“深蹲到底”那一刻？在Postprocessor.kt里监听关节点轨迹，当knee.y > hip.y + 50 && ankle.y > knee.y + 30（膝盖低于髋、脚踝低于膝）时，自动触发JSON快照。