用 React Native 开发物流应用：五个项目的经验总结

我为物流行业的五家客户公司开发了移动应用。其中四款面向客户：分别为 Buzmavi、Mitlog、CDA Lojistik 和 Almark Global Lojistik 开发，帮助这些公司的客户更方便地追踪物流、保持沟通。第五款则面向内部：一款在 TCT Lojistik 仓库中用条码追踪货物出入库的运营应用。我是 Berke Özyaşar，在这篇文章中整理了从这些项目中得出的实用经验。如果您正考虑为自己的物流公司开发移动应用，开始之前需要了解的很多内容都在这里。

先问一个问题：应用是给谁用的？

在物流行业，说到“移动应用”，可能指的是两种截然不同的产品。第一种是面向客户的应用：您的出口商或进口商客户可以在手机上看到货物在哪里、处于哪个阶段，以及应该联系谁。第二种是运营应用：仓库员工、司机或外勤人员用手机完成自己的工作。即使在同一家公司，这两者也应该是独立的应用；它们的用户、页面、安全需求和成功标准完全不同。

客户应用的目标，是减少打给运营团队询问“我的货在哪儿”的电话，并为客户提供一个专业的渠道。运营应用的目标则是速度和零差错：如果扫一个箱子花的时间比必要的长，团队就会放弃使用应用，重新回到纸笔。

为什么选择 React Native

这些项目我全部用 React Native 开发。物流公司的客户既用 iPhone 也用 Android；分别写两个原生应用，开发和维护成本都会翻倍。用 React Native，可以从一套代码为两个平台产出应用，新增一个功能时也能在两端同时上线。摄像头、推送通知、地图和打印机通信等设备功能都有成熟的库可用；必要时也可以编写原生模块。

每个项目的平台选择并不相同。Buzmavi 和 Mitlog 在 App Store 和 Google Play 都已上架；CDA 和 Almark 的应用在 Google Play 上架。仓储应用则是为仓库中使用的 Android 设备打造的。只要代码从一开始就按双平台编写，日后增加 iOS 版本就不是一个新项目，而是一件小得多的工作。

客户应用必备的内容

面向客户的物流应用，首版并不需要一长串功能清单。只要把下面几项做好，应用就会有人用：

• 货运列表和详情：客户的在途货物、每票货的最新状态和历史轨迹。状态名称应该用客户能看懂的语言来写，而不是运营团队的内部行话。
• 通知：状态变化时收到的推送通知，是应用创造价值最多的地方。但每个小变化都发通知，结果只会是用户关闭通知；需要和运营团队一起挑选哪些事件值得通知。
• 沟通：一键致电、发邮件或发消息给对应的业务代表。客户遇到问题时，不应该还要去找该联系谁。
• 单证：如果公司系统以数字形式保存单证，就提供提单、发票和报关文件等单证的查阅入口。
• 安全登录：每位客户只能看到自己的货物。权限校验应该在服务端完成；不能信任应用本身。

最难的部分：对接现有系统

几乎每家物流公司都有一套用了多年的运营软件或数据库。移动应用的价值，取决于它能否准确、及时地展示这套系统中的数据。因此，项目最关键的阶段往往不是界面，而是集成。

在 TCT 项目中，应用接入了公司现有的 ASP.NET Core 和 SQL Server 基础设施；我们没有替换现有系统，而是在其之上构建。这也是我的一贯做法：移动应用不应直接连接数据库，而应连接一个负责身份验证、只返回必要数据的 API 层。这样即使数据库结构发生变化，移动应用也不受影响，安全也能在一处集中管理。

集成时我关注的要点：

• 和运营团队逐一确认状态码和字段的含义。数据库里一个字段的名字，和它实际的用途并不总是一致。
• 设置超时、重试和易懂的错误提示，避免应用在缓慢或不稳定的网络下卡死。
• 长列表分页；不要把多年积累的数据一次性拉到手机上。
• 会话时长和令牌刷新。TCT 应用中的身份验证使用 JWT。

运营应用是另一个世界

TCT 仓储应用和客户应用是完全不同的工作。这里的用户是仓库员工；应用在入库和出库时用摄像头扫描箱子条码，条码无法识别时用 OCR 读取标签上的文字，选择车牌，并通过网络从 Zebra 打印机打印标签。对这样的应用来说，成功标准不是页面好不好看，而是一个戴着手套的人能否在光线不佳的环境下快速、准确地完成操作。因此，大触控区域、清晰的反馈和步骤最少的流程都非常重要。这个项目的技术细节，我写在了条码仓储应用一文中。

应用商店流程：尽早规划账号

在客户项目中，应用以谁的名义发布，必须一开始就明确。Buzmavi 和 Mitlog 在 App Store 上是用各公司自己的开发者账号发布的；应用在商店中以公司名义显示，账号也归公司所有。这需要一个企业级 Apple Developer 账号，而且由于 D-U-N-S 编码等步骤，这个过程可能比预期更长。开始开发时就同步启动账号申请，是不让发布日期延后的最简单方法。

在应用商店审核中，有几个物流应用特有的问题：

• 演示账号：如果应用需要登录才能使用，就要给审核团队提供一个包含示例数据的测试账号。在不展示真实客户数据的前提下准备好它，本身就是一项工作。
• 账号删除：如果应用中可以创建账号，就必须提供让用户删除账号的途径。
• 权限说明：要清楚写明为什么需要定位、通知和摄像头等权限；不使用的权限不要申请。
• 仅仅套壳网站的应用在审核中可能会遇到问题。应用需要通过通知和原生页面提供真正的移动体验。

上线之后

移动应用并不是上线当天就结束了。iOS 和 Android 每年都会推出新版本，Google Play 会定期更新目标 SDK 要求，React Native 本身也在快速演进。没有维护计划的应用，可能一两年内就变得无法更新。因此我建议上线后也要定期发布版本更新；这对安全和应用商店合规都是必要的。

总结

一款好的物流公司应用，从少而准的页面开始：货运状态、有意义的通知和便捷的沟通。真正的难点在于通过稳健的 API 对接现有系统，并尽早规划应用商店流程。如果您也想为公司打造类似的应用，可以在移动应用开发页面了解我的工作方式，并从那里与我联系。