说实话，做移动端机器学习的朋友应该都听过这种吐槽：“模型在服务器上跑得挺欢，一到手机上就炸了。” 尤其是当你拿着一个几百兆的量化模型，指望在老款iPhone或者中低端Android设备上实现60fps的实时推理，结果却看到内存飙升、帧率暴跌，甚至App直接被系统Kill掉的时候，那种挫败感真的很难形容。
最近我和团队折腾了一轮跨平台的移动端ML库实测，重点放在了TensorFlow Lite (TFLite)、Core ML、ONNX Runtime Mobile，还有最近冒头但势头很猛的MNN和TNN上。我们的测试场景很具体：离线环境、低内存限制（目标150MB以内堆内存）、高帧率实时推理（视频流处理、物体检测、姿态估计）。今天就把这些踩坑经验和实测数据掏心窝子分享出来，不整那些虚的。
为什么离线和内存限制这么让人头疼？
先别急着看库的对比，咱们得先明白痛点在哪。离线部署意味着你不能依赖后端API，模型必须打包在App里。这就带来了两个核心矛盾：
第一，模型大小和加载速度的博弈。一个未经优化的ResNet50可能有好几百MB，加载它需要时间，占用大量内存，用户流量也不划算。第二，实时性要求对硬件的压榨。实时推理通常要求每帧处理时间在16ms以内（对应60fps），这在算力有限的移动端CPU/GPU/NPU上是非常苛刻的。
更别提现在市面上的设备碎片化严重。你有一台旗舰iPhone 15 Pro，也有用户手里拿着五年前的入门级Android机。模型必须足够轻量，推理引擎必须足够高效，才能覆盖广泛的用户群。
TensorFlow Lite：安卓端的“老熟人”，iOS端的“潜力股”
TensorFlow Lite是Google主推的移动端解决方案，在Android生态里有着天然的优势。很多Android开发者上手TFLite几乎是无缝衔接的，因为Android本身对TensorFlow的支持就很好。
Android端的实测表现
在Android上，TFLite的表现相当稳健。我们用了一个简化的YOLOv5s模型做物体检测测试，目标设备包括Pixel 6（旗舰）和Redmi Note 10（中端）。
// Android TFLite 基本调用示例
class ObjectDetector(private val context: Context) {
private var interpreter: Interpreter? = null
private var inputBuffer: ByteBuffer? = null
private var outputBuffer: Array<Any>? = null
init {
val model = loadModelFile(context)
val options = Interpreter.Options().apply {
// 尝试使用GPU加速
addDelegate(GpuDelegate())
// 限制线程数，避免内存爆炸
setNumThreads(2)
}
interpreter = Interpreter(model, options)
// 预分配内存，减少运行时分配
val batchSize = 1
val height = 320
val width = 320
val channels = 3
val inputSize = batchSize * height * width * channels * 4 // float32
inputBuffer = ByteBuffer.allocateDirect(inputSize).apply {
order(ByteOrder.nativeOrder())
}
val numClasses = 80
val numBoxes = 2520
outputBuffer = arrayOf(
Array(numBoxes) { FloatArray(numClasses + 5) }
)
}
fun detect(image: Bitmap): List<DetectionResult> {
// 预处理
preprocess(image)
// 推理
interpreter?.run(inputBuffer, outputBuffer)
// 后处理（NMS等）
return postprocess(outputBuffer!!)
}
fun close() {
interpreter?.close()
}
}
在Pixel 6上，启用GPU Delegate后，YOLOv5s的推理时间稳定在12-14ms，完全满足60fps的需求。内存占用峰值大约在120MB左右，表现不错。但在Redmi Note 10上，情况就有些尴尬了——CPU推理需要45ms左右，GPU Delegate支持有限，帧率只能跑到20fps上下。
这里有个细节值得注意：TFLite的内存管理其实挺聪明的。它支持模型量化（Quantization），能把模型从float32压缩到int8，大小减少75%，同时大部分现代移动端设备都支持int8推理，速度还更快。我们实测中，将模型量化为int8后，Pixel 6上的推理时间降到了8ms，内存占用也减少到了80MB左右。
iOS端的尴尬处境
然而，到了iOS端，TFLite就显得有些力不从心了。虽然它确实支持iOS，但相比Core ML，TFLite在iOS上的性能优化明显不足。我们拿同一套YOLOv5s模型，在iPhone 15 Pro和iPhone XR上做了对比测试。
iPhone 15 Pro上，TFLite（CPU）的推理时间是18ms，勉强够用；但iPhone XR上直接崩到了45ms，完全无法满足实时性要求。更麻烦的是，TFLite在iOS上对Metal GPU加速的支持不如Core ML对Apple Silicon的统一内存架构那么友好。
有个真实案例：我们之前帮一个客户优化他们的AR试妆App，他们用的是TFLite做人脸关键点检测。在iPhone 12上还行，但一旦换到iPhone SE（第三代），内存直接OOM（OutOfMemory），App崩溃。排查下来发现，TFLite在iOS上的内存分配策略不够精细，容易在低端设备上引发内存压力。
结论是：TFLite在Android上是首选，在iOS上则不是最优解。
Core ML：iOS生态的“王者”，跨平台时的“瘸腿选手”
如果你主要做iOS应用，Core ML几乎是唯一的选择。Apple从iOS 11开始就大力推广Core ML，这几年随着Apple Silicon（M系列芯片）的普及，Core ML的性能更是迎来了质的飞跃。
iOS端的实测表现
我们用Core ML跑同样的YOLOv5s模型，在iPhone 15 Pro上的表现非常惊艳。启用NNX（Neural Network X）加速后，推理时间稳定在6-8ms，比TFLite快了一倍不止。内存占用更是只有60MB左右，非常友好。
Core ML的强大之处在于它与iOS系统的深度整合。它可以直接调用GPU、Neural Engine，甚至CPU，系统会根据当前负载自动调度。而且Core ML支持模型压缩和量化，生成的.mlpackage格式可以很好地集成到Xcode项目中。
// iOS Core ML 基本调用示例
import CoreML
import Vision
class ObjectDetector: NSObject {
private var model: MLModel?
private var visionRequest: VNCoreMLRequest?
override init() {
super.init()
// 加载模型
guard let modelURL = Bundle.main.url(forResource: "YOLOv5s", withExtension: "mlmodelc"),
let loadedModel = try? MLModel(contentsOf: modelURL) else {
fatalError("无法加载模型")
}
self.model = loadedModel
// 创建Vision请求
let coreMLModel = try? VNCoreMLModel(for: loadedModel)
self.visionRequest = VNCoreMLRequest(model: coreMLModel!) { [weak self] request, error in
self?.handleVisionRequest(request: request, error: error)
}
self.visionRequest?.isPreferBackgroundProcessing = false
}
func detect(image: CIImage) {
let handler = VNImageRequestHandler(ciImage: image, options: [:])
try? handler.perform([visionRequest!])
}
private func handleVisionRequest(request: VNRequest, error: Error?) {
guard let results = request.results as? [VNRecognizedObjectObservation] else { return }
// 处理检测结果
}
}
但在iPhone XR这样的老设备上，Core ML的优势就没有那么明显了。虽然比TFLite快，但受限于硬件，推理时间也在25-30ms左右，勉强能维持30fps。
Android端的“水土不服”
Core ML的致命弱点在于它只支持iOS和macOS，Android根本跑不了。这意味着如果你的应用需要同时支持两个平台，Core ML就只能用在iOS端，Android端还得找别的方案。
我们之前有个项目是用Core ML做iOS端的实时文字识别（OCR），效果非常好。但Android端用了Tesseract，性能和准确度完全不在一个档次上。后来我们换成了Google的ML Kit，才勉强追上Core ML的水平。
结论是：Core ML是iOS端的绝对王者，但跨平台时它就是个“局外人”。
ONNX Runtime Mobile：跨平台的“通用语”，但性能有代价
ONNX（Open Neural Network Exchange）是微软牵头制定的开放模型格式，目的是让模型训练和部署不再被某个框架绑定。ONNX Runtime Mobile则是配套的轻量级推理引擎，主打跨平台。
跨平台实测
ONNX Runtime Mobile最大的卖点是“写一次，到处跑”。我们在Android和iOS上都部署了同样的YOLOv5s模型（导出为.onnx格式），测试了推理性能和内存占用。
Android端（Pixel 6）：CPU推理时间约15ms，内存占用约100MB。 iOS端（iPhone 15 Pro）：CPU推理时间约12ms，内存占用约90MB。
这个表现中规中矩，既没有TFLite在Android上的极致优化，也没有Core ML在iOS上的硬件加速优势。但它的优势在于一致性——同一套模型代码，两个平台都能跑，而且行为一致。
# 模型转换示例：PyTorch -> ONNX
import torch
import onnx
# 加载PyTorch模型
model = torch.hub.load('ultralytics/yolov5', 'yolov5s', pretrained=True)
model.eval()
# 创建示例输入
dummy_input = torch.randn(1, 3, 320, 320)
# 导出为ONNX
torch.onnx.export(
model,
dummy_input,
"yolov5s.onnx",
input_names=['input'],
output_names=['output'],
dynamic_axes={'input': {0: 'batch_size'}, 'output': {0: 'batch_size'}},
opset_version=11
)
# 验证ONNX模型
onnx_model = onnx.load("yolov5s.onnx")
onnx.checker.check_model(onnx_model)
print("ONNX模型验证成功")
// Android ONNX Runtime 调用示例
import ai.onnxruntime.OrtEnvironment;
import ai.onnxruntime.OrtSession;
import ai.onnxruntime.OrtException;
public class OnnxDetector {
private OrtEnvironment env;
private OrtSession session;
public OnnxDetector(Context context) throws OrtException {
env = OrtEnvironment.getEnvironment();
// 加载ONNX模型
session = env.createSession(context.getAssets().open("yolov5s.onnx"),
new OrtSession.SessionOptions());
}
public float[][][] detect(float[][][] input) throws OrtException {
OrtValue inputTensor = OrtTensorUtils.createOrtTensorFromFloatArray3D(input);
try {
OrtSession.Result result = session.run(Collections.singletonList(inputTensor),
Collections.singletonList("input"));
float[][][] output = OrtTensorUtils.getFloat3DTensorFromResult(result);
return output;
} finally {
inputTensor.close();
}
}
public void close() {
try {
session.close();
} catch (OrtException e) {
e.printStackTrace();
}
OrtEnvironment.unload();
}
}
但问题也很明显：性能有代价。ONNX Runtime为了保持跨平台兼容性，牺牲了一部分针对特定硬件的优化。在GPU加速方面，它不如TFLite的GPU Delegate和Core ML的Neural Engine那么高效。
还有个隐患是模型转换的兼容性。虽然ONNX支持大多数主流框架，但在转换过程中，某些自定义操作（Custom Ops）可能会出问题。我们之前就遇到过，一个用了特殊激活函数的模型，在导出为ONNX后，推理结果完全不对。排查了半天才发现是某个算子的实现有偏差。
结论是：ONNX Runtime Mobile适合对跨平台一致性要求高、对极致性能要求不高的场景。
MNN和TNN：国产新秀的“弯道超车”
这几年，阿里推出的MNN（Mobile Neural Network）和腾讯推出的TNN（Tensor Network）在移动端ML领域异军突起。这两个库都是国内团队开发的，针对移动端做了大量优化，尤其在Android端表现亮眼。
MNN的实测表现
MNN是阿里达摩院推出的轻量级推理引擎，支持Android、iOS、Linux等多个平台。它的特点是完全开源、代码精简、性能高效。
我们在Android端用MNN跑了同样的YOLOv5s模型，在Pixel 6上的推理时间只有7-9ms，比TFLite还快一点。内存占用更是只有70MB左右，非常节省。MNN还支持一种叫“代码生成”的优化技术，能把模型编译成机器码，进一步提升性能。
// MNN C++ 调用示例
#include <MNN/Interpreter.hpp>
#include <MNN/Tensor.hpp>
class MnnDetector {
public:
MnnDetector(const char* modelPath) {
// 加载模型
net_.reset(MNN::Interpreter::createFromBuffer(modelFileContent_, modelFileSize_));
// 创建session
session_ = net_->createSession({{1, 3, 320, 320}});
// 获取input和output tensor
inputTensor_ = net_->getSessionInput(session_, nullptr);
outputTensor_ = net_->getSessionOutput(session_, nullptr);
}
std::vector<float> detect(const std::vector<float>& inputData) {
// 复制输入数据
inputTensor_->copyFromFloatBuffer(inputData.data());
// 运行推理
net_->runSession(session_);
// 获取输出
std::vector<float> outputData(outputTensor_->size());
outputTensor_->copyToFloatBuffer(outputData.data());
return outputData;
}
private:
std::unique_ptr<MNN::Interpreter> net_;
MNN::Session* session_ = nullptr;
MNN::Tensor* inputTensor_ = nullptr;
MNN::Tensor* outputTensor_ = nullptr;
};
MNN在iOS端的表现也不错，在iPhone 15 Pro上推理时间约10ms，和Core ML接近，但比TFLite快。内存占用约80MB。
不过MNN有个小缺点是文档和社区相对较小。遇到问题时，可能找不到现成的解决方案，得自己去翻源码或者在GitHub上提Issue。
TNN的实测表现
TNN是腾讯开源的跨平台推理引擎，主打高性能和低延迟。我们在测试中发现，TNN在Android端的性能非常出色，尤其是GPU加速方面。
在Pixel 6上，用TNN跑YOLOv5s，GPU推理时间稳定在5-7ms，比MNN还快一点。但TNN的iOS支持相对弱一些，在iPhone 15 Pro上的GPU加速效果不如Android端明显，推理时间在10-12ms左右。
// TNN C++ 调用示例
#include <TNN/NNNetwork.h>
#include <TNN/DEVICE/CPU/CPUComputeDevice.h>
class TnnDetector {
public:
TnnDetector(const std::string& modelPath) {
// 创建设备
device_ = std::make_shared<CPUComputeDevice>();
// 创建网络实例
network_instance_ = std::make_shared<TNNCore::NNNetwork>();
// 加载模型
NetConfig net_config;
net_config.net_proto_content = modelContent;
net_config.net_proto_path = "";
net_config.model_type = TNNModelProto;
TNNResult result = network_instance_->Init(net_config);
if (result != TNN_OK) {
LOGE("TNN load model failed: %d", result);
}
// 创建输入输出
input_tensor_ = std::make_shared<TNNCore::Tensor>(network_instance_->GetInput(0)->GetDevice());
output_tensor_ = std::make_shared<TNNCore::Tensor>(network_instance_->GetOutput(0)->GetDevice());
}
std::vector<float> detect(const std::vector<float>& inputData) {
// 设置输入
input_tensor_->SyncInputData(inputData.data());
// 运行推理
TNNResult result = network_instance_->Forward({input_tensor_}, {output_tensor_});
if (result != TNN_OK) {
LOGE("TNN forward failed: %d", result);
}
// 获取输出
std::vector<float> outputData(output_tensor_->GetCount() * 4); // float32
output_tensor_->SyncOutputData(outputData.data());
return outputData;
}
private:
std::shared_ptr<ComputeDevice> device_;
std::shared_ptr<TNNCore::NNNetwork> network_instance_;
std::shared_ptr<TNNCore::Tensor> input_tensor_;
std::shared_ptr<TNNCore::Tensor> output_tensor_;
};
MNN和TNN的共同优点是针对国内场景做了大量优化，比如对国产芯片的支持、对国内社交App（微信、抖音）的适配等。如果你的目标用户主要是国内用户，这两个库值得考虑。
结论是：MNN和TNN是国产移动端推理引擎的代表，Android端表现优秀，iOS端也有一定竞争力，但生态和文档相对薄弱。
综合对比与选型建议
好了，说了这么多，咱们来做个总结对比。下表是我们在同等条件下（同一模型、同一批设备）的实测数据汇总：
| 库 | Android CPU (ms) | Android GPU (ms) | iOS CPU (ms) | iOS GPU (ms) | 内存占用 (MB) |