一个相机预览功能，写了个自定义插件

在 Lyker 的开发过程中，我们遇到了一个看似很小、却触发了一系列深层思考的问题：社区相机插件没有预览能力。

用户想拍下餐盘里的食物，打开相机后面对的却是一个不可控的原生界面——取景、对焦全在黑箱里进行。对于一款以食物记录为起点的应用，这是不可接受的。我们调研了社区方案，但为了更深度地定制预览界面并为未来传感器集成留出架构空间，最终决定自己动手写桥接代码。这意味着要写 TypeScript 到 Swift 和 Kotlin 的双端桥接层，把原生相机预览嵌入 Ionic 页面。

这件事本身不大，但它在团队内部引发了一次持续至今的讨论：我们为什么要选择一条需要不断“自己造桥”的技术路线？

一、AOT 编译与转译构建：两种语言的对话

在技术选型时，我逐渐形成了一种分类视角，用以理解我们面临的选择。这个视角将语言分为两类：

AOT 编译语言（如 C++、Swift）：源代码直接编译为机器码，对硬件有绝对掌控，性能极致，但开发反馈环长，双端迭代成本高。

转译构建语言（以 TypeScript 为代表）：源代码先被转译为 JavaScript，运行在 JS 引擎上。它天然享有动态宿主赋予的极速修改-刷新循环，UI 迭代几乎无感，但代价是每当硬件能力超出框架抽象层时，必须手动桥接。

Lyker 的技术底座是 Vue + Ionic + Capacitor，这套组合让我们能用 Web 开发的节奏同时覆盖 iOS 和 Android。但我们选择的本质是：用 TypeScript 覆盖 90% 的业务和 UI，再用自己写的桥接层去攻克那 10% 的原生硬骨头。 相机预览正是那 10% 的典型。

这种取舍就像在两块高速运转的齿轮之间，自己动手焊一组新的传动轴——麻烦，但可控。并且随着桥接经验的积累，成本会越来越低。

二、比传感器精度更重要的东西

相机插件的打磨只是起点。随着 Lyker 的演化，一个更本质的问题浮现出来：在健康管理这件事上，传感器采集的精度，是否真的等同于用户得到的价值？

我们曾无数次优化餐食估测的准确度，但也观察到真实场景中一个无法避免的现象：中午不小心多估了 500 大卡，并不会毁掉健康管理。因为用户的晚餐时间可能推迟，或者摄入量自然减少。一周结束后，系统生成的周报里，那天的误差会变成一个微小的异常——它反而引发用户的自我觉察：“哦，那天中午我应该是拍多了。”

用户不是被算法批评，而是和 App 一起，更了解自己的身体信号。这个洞察让我们从对“单次极限精准”的执念中释然了。Lyker 真正交付的，不是一个完美的卡路里计算器，而是一个允许误差存在、并通过长周期多维度数据自动校准的系统。 当用户坚持记录数周，健康趋势会自己浮现，远比任何单点测量更可信。

这就是为什么 Lyker 没有停留在“拍食物→得数据”的工具逻辑上。我们设计了周期记录、主观感受入口，并用 AI 从长期数据中生成洞察。传感器只是三角测量的一个点，另外两个点是用户对自己行为的诚实记录，以及时间的力量。

三、桥接，是为了走更远的路

回到那段自定义相机代码。它不仅解决了一个 UX 缺陷，更在团队内部确立了一种信念：只要跨平台路线的效率优势能持续放大，我们就愿意为硬件访问的摩擦支付合理的桥接成本。未来当我们需要更充分地利用手机传感器时，今天写下的桥接架构和工程纪律会直接复用。

这或许就是跨平台框架的“桥接哲学”：接受摩擦，管理摩擦，让摩擦成为可控的工程成本，而不是阻碍。

这篇文章记录了 Lyker 开发中一段真实的思考。如果你也在用跨平台框架构建需要深度硬件能力的应用，或者对健康管理产品的技术实践感兴趣，欢迎留言交流。你可以在零曦科技官网找到本文的另一个版本，那里还有更多关于我们产品哲学的记录：www.zerora.cn。