去年有个做社区团购的客户找到我们，说想做个秒杀模块，纠结是用框架还是原生。他听别人说，微信小程序原生开发性能好，但上手门槛高，是不是真的？我当时没直接回答，拉着他看了我们后台一段真实录屏：一个纯原生写的商品列表页，快速滑动时帧率能稳稳跑在 58-60，极少掉帧。他又看了同一套业务用某个跨端框架跑出来的效果，数据一出来，他自己就说“差别确实明显”。这其实不是个例，很多团队在选型时，都会在这种“要不要用原生”的问题上反复摇摆。
我自己从 2017 年微信小程序开始内测就接触原生，到现在带团队做了几十个商业项目，最大的感受是——原生开发被妖魔化了。很多人一提原生，脑子里浮现的就是“开发慢、维护累、没人愿意写”。但你仔细去拆，会发现真实情况跟传言差得远。真正拖慢速度的，往往不是原生本身，而是没有把底层机制摸透，硬着头皮上，导致到处是坑。
举个例子，原生开发里最让人头疼的 setData，不少开发者习惯把整个接口返回的大对象一把塞进去，从页面到组件，数据体量一大，页面交互就卡成狗。我们团队早期也犯过这个毛病，后来给一个生鲜配送项目做性能优化，发现某个列表页每次 onShow 都在全量刷新购物车数据，用户从商品详情返回时，要等将近 400ms 才能滑动。我们做了两件事：第一，把数据做差分，只更新变动的字段；第二，把购物车数据下沉到全局 app 对象，列表页只取自己需要的那几个字段，不再把整个购物车对象传过去。改完以后，滑动响应时间压到 50ms 以内，用户体感上基本是瞬间流畅。这个项目后来平稳扛住了早高峰 10 万量级的并发访问，没倒过一次。这就是原生开发的好处——当你把底层通信机制吃透了，你有绝对的控制权，不需要依赖框架的“黑盒优化”。
另一个常被吐槽的点是组件复用。很多人觉得原生自定义组件写起来啰嗦，不如框架的组件化来得爽。但去年我们给一个连锁便利店做巡店系统，里面有个拍照上传和电子签名模块，需要反复调用原生相机和 Canvas 接口。当时试了一个跨端方案，发现 Canvas 的触摸绘制在低端安卓机上笔迹延迟特别明显，甚至出现短线断裂。后来切回原生，直接用 Canvas 2D 接口，配合 touch 事件做节流处理，笔迹跟随流畅了很多。而且我们把签名组件封装成独立的自定义组件后，在多个页面复用，只需要传一个参数就能控制是“签名模式”还是“查看模式”，维护成本其实很低。这个组件后来被抽出来，在不同的几个项目里直接用，改改样式就能复用，没觉得比框架慢多少。
还见过不少团队，一上来就要求“我们要做行业版 SaaS 小程序，要有灵活的配置后台”。想法很好，但技术选型容易走偏。比如有些团队为了快速出 demo，用某个跨端框架搭了原型，界面确实漂亮，但后续业务逻辑一复杂，交互一多，就开始出现各种诡异问题：wxs 不支持、自定义 tabBar 闪烁、原生组件覆盖层级错乱。这些问题不是说框架不好，而是框架的封装层在某些深度交互场景下，会跟微信的底层 API 产生摩擦，排查起来很痛苦。我们团队的做法是，凡是涉及硬件交互、地图、蓝牙、长列表这种对性能要求高的场景，就会坚定地走微信小程序原生开发。像我们做过的一个冷链物流温控项目，需要实时读取蓝牙温度计的数据并上报，同时要在地图上绘制轨迹，这种场景下，任何一层额外的抽象都可能让数据传输的稳定性打折。原生开发让我们能精确控制每一帧的渲染和每一次蓝牙通信的时机，最终设备掉线率压到了 0.3% 以下。
那原生开发到底快不快？这其实是个伪命题。开发速度取决于你对这个技术栈的熟悉程度和团队的工程化能力。我们内部沉淀了一套原生开发的脚手架，把常用的工具函数、请求封装、组件库都做了标准化，一个新项目启动时，从零到能跑通主流程，两个人三天足够。这跟用一些成熟框架的启动速度，并没有数量级的差别。真正拉开差距的，是后期面对复杂需求时的稳定性和优化空间。原生开发能让你直面微信的底层能力，没有中间商赚差价，出了问题能顺着调用链一路查到根。
我们也不是所有项目都无脑上原生。有些纯展示型的小程序，交互简单的，我们用一些轻量方案也能快速交付。但凡是涉及到交易、支付、复杂表单、即时通讯这些核心业务，我们给客户的建议一定是：优先考虑原生。原因很简单，这些场景里，任何一点性能上的妥协，最终都会转化成用户流失和客诉。你总不想在用户抢优惠券的时候，按钮点不动，然后后台日志里全是“setData 超时”吧。
我们之前服务的一个本地生活平台，迭代了快两年，中间经历过一次大的重构。早期为了追进度，部分模块用了第三方 UI 库，结果随着业务增长，很多页面变得臃肿，加载速度掉到了 2 秒以上。我们接手后，分批把核心交易链路全部用原生重构，包括商品详情、下单、支付成功页，同时把一些非必要的第三方依赖剥离。重构完，首屏加载时间从 2.3 秒降到 0.9 秒，支付成功率提升了将近 3 个百分点。这个数字看起来不大，但换算到他们的日订单量，每天就是多赚出来的利润。客户后来跟我们说，这次重构的钱，两个月就收回来了。
如果你现在正在纠结技术选型，我的建议是，别光听别人说“原生开发慢”，也别被各种框架的 demo 炫技带偏。去写一个真实的业务页面，把数据量拉到 100 条，用真机跑一遍，看看滑动帧率、看看内存占用、看看 setData 的调用耗时，数据会告诉你答案。如果你们团队缺原生开发的经验，或者现有项目已经踩了坑不知道怎么优化，可以找我们聊。我们团队在做成都运多多网络 这几年，接的很多项目都是客户自己用框架搞不定，或者性能到了瓶颈，才找到我们。我们一直觉得，技术选型没有银弹，但有一条铁律：在关键业务上，永远把控制权握在自己手里，这比什么都重要。
免责声明：本网站部分内容来源于网络，如有侵权，请及时与本站联系处理。
