相机预览、桥接代码与 500 大卡的误差 —— Lyker 技术团队的一次内部复盘
Lyker 技术团队 · 技术笔记 2026年7月4日
在 Lyker，用户每天都会拍下他们的餐食。一个流畅的拍照体验，是我们交付给用户的最基本承诺。但几个月前，我们发现了一个无法绕过的断层：社区提供的相机桥接插件只能拍照，无法在 App 内提供拍照前的预览画面。
用户打开相机后，面对的是一个不可控的原生界面。取景、对焦、构图全部在黑箱中进行。对于一款以食物记录为起点的应用，这种体验是不可接受的。于是，我们决定自己动手。
这引出了一个更深层的问题：为什么我们要选择一条需要不断"自己造桥"的技术路线？
一、跨平台的效率与桥接的代价
Lyker 的技术底座是 Vue + Ionic + Capacitor。这套组合让我们能够用 Web 开发的节奏，同时覆盖 iOS 与 Android。但 Ionic 的本质是在 Web 技术之上，通过桥接层调用原生能力。这就带来一个永恒的张力：跨平台效率越高，对原生硬件的直接控制就越需要绕路。
当我们需要一个带预览的自定义相机时，我们调研了社区方案，但为了更深度地定制预览界面并为未来传感器集成留出架构空间，我们决定自己动手写桥接代码。这意味着要写 TypeScript 到 Swift 和 Kotlin 的桥接层——就像在两块高速运转的齿轮之间，自己动手焊一组新的传动轴。
在团队内部，我们常把这种取舍比作两种语言的对话。C++/Swift 这类 AOT 编译语言，产出机器码，对硬件有绝对的掌控力，但开发反馈环长，双端独立迭代成本高。而 TypeScript 这样的语言，通过转译运行在 JavaScript 引擎上，天然享有动态宿主带来的极速修改-刷新循环，UI 迭代快到几乎无感——代价就是每当硬件能力超出框架抽象层时，必须手动桥接。
我们的选择是：用 TypeScript 覆盖 90% 的业务与 UI，再用自己写的桥接层去攻克那 10% 的原生硬骨头。 相机预览正是那 10% 的典型。
二、当别人追求"单点精准"时，我们更相信"长周期校准"
相机插件的打磨只是起点。随着 Lyker 的演化，我们逐渐意识到一个更本质的问题：在健康管理这件事上，传感器采集的精度，是否真的等同于用户得到的价值？
我们曾无数次测试餐食估测的准确度，并不断优化。但我们也观察到真实用户的使用场景中，一个无可避免的现象：偶尔的记录误差，例如中午不小心多估了 500 大卡，并不会毁掉一个人的健康管理。
因为用户的晚餐时间可能因此推迟，或者晚餐的摄入量自然减少。等到一周结束，系统生成周报时，那一天的误差会变成一个微小的异常——它反而引发用户的自我觉察：“哦，那天中午我应该是拍多了。” 用户不是被算法批评，而是和 Lyker 一起，更了解自己的身体信号。
这个洞察让我们从对"单次极限精准"的执着中释然了。Lyker 真正交付给用户的，不是一个完美的卡路里计算器，而是一个允许误差存在、并通过长周期多维度数据自动校准的系统。 当用户坚持记录数周，他们的健康趋势会自己浮现出来，远比任何单点测量更可信。
这也是为什么 Lyker 没有停留在"拍食物 → 得数据"的工具逻辑上。我们设计了周期记录、主观感受入口，并用 AI 从长期数据中生成健康洞察。传感器只是三角测量的一个点，另外两个点，是用户对自己行为的诚实记录，以及时间的力量。
三、桥接，不只是为了这一刻的相机
回到最初那段自定义相机插件代码。它解决的不只是一个 UX 缺陷，更在团队内部确立了一种技术信念：只要跨平台路线的开发效率优势能持续放大，我们就愿意为硬件访问的摩擦支付合理的桥接成本。 并且，随着桥接层经验的积累，这笔成本会越来越低。
未来，当我们需要更充分地利用手机传感器，进一步降低食物记录的摩擦时，我们今天写的桥接架构和工程纪律会直接复用。Lyker 的长远目标——整合个人健康数据、饮食记录与生活习惯，构建持久的营养追踪与管理体系——也需要我们在"自己造桥"这件事上越来越从容。
结语
这篇文章，是 Lyker 技术团队的一次内部对话的外化。我们选择一条少有人走的路：用 Web 技术基座去承载一个需要深度硬件能力的健康应用。这条路不总是平坦，但每一个亲手写下的桥接插件，都在提醒我们当初为什么出发。
我们不追求每一次记录都毫无误差，但我们愿意陪用户一起，在更长的时间尺度上，发现真正的健康趋势。
如果你对 Lyker 的技术路线或产品哲学有任何好奇，欢迎在官网留言或通过应用内反馈联系我们。我们乐于将更多思考记录下来，与同行者分享。
零曦科技 Lyker 团队 记录每一餐，理解每一个你。