一、引言

2008年，全球移动终端接入互联网的用户数首次超过使用桌面电脑接入互联网的用户数（国际电信联盟统计数据），标志着人类正式进入移动互联网时代。重要推动因素是2007年苹果公司发布的第一代iPhone开启了智能手机大量上市的浪潮，以iPhone为代表的智能手机不仅具有革命性的触屏设计和简单直观的操作界面，更提供了一个软件应用的生态系统，为开发者提供了一个平台，使其可以结合手机硬件和操作系统软件，充分发挥创造力，在全世界范围内开发、分发移动应用程序。这使得智能手机不再仅仅是通信工具，更成为一个功能强大的移动计算终端，围绕这个终端，产生了与PC互联网时代不同的技术架构思路和产品设计方法，从而创造了无数与“旧时代”不同的新商业模式，带给人们在全新场景下的用户体验。

2013年，京东物流的信息化系统仍然只有PC端，几乎没有移动端，在业务探索和执行效率上亟需加强。利用移动互联网技术进行创新，是突破业务局限、提升运营效率比较直接有效的方式，对于京东物流这样一家已经数字化程度相当深厚的“供应链企业”来说，全面拥抱移动化是当时的趋势。从2014年开始，京东物流陆续在仓储、拣运、配送、大件、客服等核心业务领域研发并使用移动应用产品，在移动互联网的技术驱动下焕发出新的活力。

本文将基于上述实践，探讨面向移动应用的产品开发特点，从终端应用选型、运营后台规划、后端服务开发到产品场景化设计以及用户操作体验优化5个不同的角度阐述移动应用开发的特点，并重点介绍供应链物流领域移动应用开发与PC Web应用开发的差异，希望能为业务运营、产品研发人员提供理论和实践的参考。

二、终端应用：选择业务需要的交互框架

“你要做的APP是一个工具，还是一门生意？”——每当我们根据业务诉求规划一个移动APP时，都要先回答公司管理层的这个“灵魂拷问”。是的，无论是从软件的生命周期角度还是从业务的运营成本角度来说，一个APP的研发上线，只是一个开始，后续的业务能够“持续”运营才是真正的价值体现。一个APP，是作为降本提效的工具，还是作为开源增收的生意，在商业经营模式和运营成本投入上都有着显著的不同，作为软件开发者一定要和业务运营者规划明白，列举清楚各方面的投入，达成一致意见，方能进入下一个阶段。在供应链物流领域，移动应用主要可以“工具”、“社区”、“电商”3种类型来提供业务价值：

当你根据业务需求确定了将要开发的移动应用属于哪种类型之后，下一步规划就是要做好技术选型，即选择合适的交互框架来承载你的应用。早期的移动应用技术如WAP、Symbian、Windows Phone在不同时期都曾经辉煌过，但如今它们已经消失在历史中，正常情况下企业不会再选择这些技术开发应用。在2008年移动互联网时代爆发至今的十多年时间里，也涌现出很多基于移动操作系统或移动浏览器的“轻应用”技术，时至今日也基本波澜不惊了，主要原因还是“跨厂商兼容”的局限性所导致，因此我们在技术选型时一般也不需要考虑。

目前在国内来说，仍然在牌桌上的移动应用“主框架”除了传统的iOS、Android两大移动原生平台以及H5页面以外，以Flutter、RN（React Native）为主要代表的移动跨平台框架也逐渐成为主流，另外，随着2017年底“跳一跳”小游戏的爆发，基于应用程序生态的微信小程序和基于H5技术的微信公众号也成为了移动应用框架的另一个“山头”。当然，未来华为的“鸿蒙”是否能形成独立的生态成为移动应用框架的另一极，还得观察。

那么，面对3种不同业务类型，应该如何在多种主流技术框架中进行选择？主要考虑如下因素：

◦交付成本和操作体验之间的平衡。对于工具型应用，由于其核心在于解决具体业务问题，提高工作效率，一般对性能和即时反馈有较高要求，同时用户没有选择权——必须安装，必须使用，用完即走，无需黏性。这种情况下基于原生（Native）框架的终端技术是优先考虑的选择，特别对于安装在特定设备上（如工业PDA）的厂内应用，一般会基于Android原生框架开发，优点是开发维护成本可控、运行效率高、硬件支持好，京东的盘古中小件仓APP、昆仑大件仓APP都是这种情况；当工具应用的范围扩大到手机等个人电子设备，那就必须要考虑iOS和Android双平台的支持，此时选择Flutter/RN这类高性能跨平台框架，不仅能够提供准原生级的操作体验，还能实现一次编写多平台运行，减少开发成本和后期维护负担；如果想进一步降低开发和维护的成本，也可以选择微信小程序，当然这需要牺牲一些运行效率和硬件控制能力。而对于社区型应用，虽然也需要良好的运行效率，但相对而言，其更侧重于信息展示、用户互动与内容分享，因此如果没有特殊的战略限制，可以优先考虑基于微信生态进行构建——利用内嵌H5页面承载内容和展示，通过微信公众号/服务号进行内容推送和消息通知，最终目标可将用户引入微信小程序内完成操作和互动的闭环，同理也可适用于“轻”电商型应用，例如京东快递微信小程序。至于“重”电商型应用，考虑到支付系统的可选性、交易的安全性、“黄金流程”的顺畅体验，并且由于toB业务天然的一些工具属性，建议基于原生框架开发iOS/Android双端APP，可以根据业务体量选择全原生架构，或“原生壳”结合Flutter/RN跨平台框架以节约开发成本，也可针对部分静态或轻量页面采用“积木式H5”嵌套框架以节约维护成本，例如菜鸟裹裹。

◦受众群体及其对屏幕、终端等硬件能力的需求。工具型应用，主要服务于企业内部员工或特定行业用户，往往需要针对特定的硬件环境进行适配，如扫条形码、扫二维码、红外通信、蓝牙通信、NFC通信等，这时候选择基于设备操作系统的原生框架进行开发一般是比较常见的做法；在某些单一的业务场景下，也可以采用PC端系统软件+数据采集硬件的模式来完成小范围场景下的移动应用，省去移动终端应用程序开发的成本，例如在仓储、分拣的收货、拒收等环节采用PC Web应用+扫描枪来操作。而社区型和电商型应用，由于主要面向大众用户，需要运行在各种不同品牌、型号的消费级智能终端上，为了确保广泛的适配性体验，就必须要做好对屏幕、终端的兼容性，采用iOS/Android原生框架或Flutter/RN跨平台框架开发都需要在页面布局上做一定的处理，并且要增加多终端兼容性测试，甚至为Phone和PAD开发不同的应用版本。而开发微信小程序和微信公众号则会在屏幕、终端的兼容性处理上节省很多工作，因为微信提供的应用程序框架和响应式H5框架帮助开发者处理了绝大多数的共性问题。

◦“富客户端”模式下业务逻辑的侵入需求。在一些特定的工具型应用中，由于其深度集成到业务流程之中，往往需要在终端处理复杂的业务逻辑并存取一定量级的数据。例如在物流场景下分拣、配送等环节，遇到停电、网络受限等情况，移动终端需要支持一定程度的离线作业；又如在IoT等场景下，经常需要和硬件即时交互，移动终端需要具有比较强大的“边缘计算”能力；在上述情况下，基于Web View（浏览器）架构的微信H5框架就不合适了，因为性能、兼容性、安全性都存在比较大的问题；这时候，基于iOS/Android原生框架开发是第一选择，因为其性能最优；如果需要跨平台，Flutter/RN框架也可以考虑，但需要注意是否存在特殊的硬件SDK，Flutter/RN框架能否兼容。当然，如果是传统企业初涉移动互联网，仅做简单展示分享、私域营销的社区型应用，从节省成本的角度，建立一个H5形态的微网站用来嵌入、分发也是可行的。

◦对于“可控性”的需求。从企业运营和经营角度来看，开发移动应用需要考虑技术人员和软件分发的可控性风险，这涉及到团队构建、发布、升级等挑战。iOS/Android、Flutter/RN等原生或准原生框架固然性能好、扩展性强，但所采用的技术栈如Swift、Kotlin、Dart相对封闭和小众，不利于团队快速构建和补充，另外其“重客户端架构”造成了软件发布渠道杂、升级风险大、更新维护可控性差等问题。而微信小程序的开发语言类似VUE JS，普通前端开发者可以快速上手，并且基于Web View H5技术运行，这种“轻客户端架构”可以做到类似BS（Browser Server）架构的实时更新，也具备一定CS（Client Server）架构的本地计算能力，可控性较强；但也需要考虑到，由于微信体系作为应用程序内框架的局限性，其性能和硬件能力扩展性必然受到一定限制。因此，如何选型，要基于业务场景对于“可控性”的实际需要。

三、运营后台：管理、分析、优化业务的核心中控

“把业务系统转向移动互联网，第一件事要做什么？”——这个问题见仁见智，可能有各种答案，如果要规划一个大型企业的移动应用产品集，除了找人以外，我觉得先不要着急上马各种业务APP的建设，最好先布局“基础设施”，培育好移动应用生长的技术土壤，这可能会让后期的业务建设事半功倍，同时避免一些重大的架构问题。

这个基础设施就是专门为移动应用产品集构建的运营后台。一般情况下，这个运营后台会包含众多的功能和模块，但往往不需要全部重新建设，可以把一些已有的能力拿过来集成即可；也不可能一次建设到位，会根据业务发展的轻重缓急迭代构建。以下将针对一些移动应用特需的运营后台功能做说明：

1.分发。了解分布式服务架构的开发者都明白，如果没有统一的服务注册和发现机制，治理分布在各个机器上的服务接口将会是灾难性的工作。同理，如果没有统一的注册管控，分发到移动互联网上成千上万个终端里的移动应用产品也会面临“失控”的问题，富客户端的发布、修复、更新会比PC Web端更加麻烦，要做更多的工作来保障。因此，运营后台应该提供移动应用的注册登记功能，通过静态以及动态的方式获取应用最新的基础数据信息；在基础数据信息之上，构建产品版本管理机制，将安装包、二维码、邀请码等“分发材料”统一管理起来；然后可以在产品版本管理机制之上，构建更新发布机制，这包括：强制/可选/静默等应用发布策略、根据用户属性分发的灰度策略、应用商店上下架管理、组件/插件升级管理等，以上能力可以根据业务体量和实际需要进行裁减。

2.CMS（内容管理）。对于移动应用来说，一些通用的静态内容从远端推送或拉取是比较合适的，这样既能灵活管控，又能节约成本，这一般有新闻、帮助、培训等模块，也可以包括定制启动页等功能。从实现上来说，通过运营后台的CMS模块配合客户端的积木式H5、热更新插件等技术能很好的管理起这部分内容，从而避免一些仅为了更新内容进行版本发布的浪费。

3.消息通知。相对PC Web端来说，移动应用“永远在线”，能够将消息通知随时随地推送给用户是一个独特的优势。推送的渠道有很多种，常见的有操作系统推送、应用程序推送、短信推送、微信推送，在不同的框架下推送的成本、触达率、展示效果都会有所不同，因此，当业务发展到一定程度，有必要把消息统一管理起来，这不仅包括推送技术渠道的管控，也包括推送内容模板的编辑管理。

4.IVR（交互式语音应答）。 很多情况下，当移动应用承载的业务人工客服能力不足时，完全可以通过移动应用语音交互的便捷性开发IVR服务来作为补充。用户可以通过IVR服务，根据系统的指示，键入适当的选项或个人资料，以听取预录之语音信息；或经计算机系统根据预设的程序 (Call Flow) 组合数据，以语音方式读出特定的资料（如订单状态等）；亦可通过系统提示输入交易指示，以执行预设的交易（如更改联系电话号码等）；还可设计和编辑语音模版，向第三方应用发出个性化语音通知（如配送消息提醒）。对于运营后台来说，需要提供相应的IVR管理功能进行支撑。

5.用户反馈。由于移动应用能够随时随地使用，因此具有很强的即时性，能够方便获取用户的第一手体验、感受和需要，还能通过硬件能力方便地采集到照片、位置等辅助信息。针对这类共性需求，如：获取用户的问题建议、商机意向等可以提炼成公共的后台运营能力统一管理，功能可以包括表单自定义、管理员回复、邮件转发等。

6.埋点监控。不同于PC Web应用，移动应用出现的Crash（崩溃）等问题都发生在客户终端，这里面除了应用程序自身的问题外，还有可能是外部应用、系统环境等因素所导致，因此必须要通过埋点的方式将Crash的上下文信息采集、发送到一个“中控后台”进行监控、分析和处理。当然，除了采集Crash信息，为了支撑业务运营工作，还可以根据移动应用的特点进行埋点，采集设备信息、位置信息、用户行为信息等数据。

7.数据分析。通过用户反馈和埋点监控能从主动和被动的角度采集到了大量运营数据和用户数据，那么建立相应的数据分析体系，挖掘数据的价值并进行可视化的展示是后续要做的工作，这对于业务优化、产品改善、客户服务、安全管控、精准营销等能力的提升有着很好的指导作用。不过，建立上述数据采集和分析的体系需要针对不同系统框架开发客户端SDK、服务端API以及可视化后台系统，成本较高且通用性较强，所以，可以考虑集成成熟的第三方解决方案来实现，例如京东的鹰眼监控和子午线数据平台，百度、腾讯等大型厂商也有不错的解决方案。

8.个性化功能和配置。针对移动应用和供应链物流业务的特点，往往会存在很多共性的后台管控需求，例如：轨迹采集、GIS打卡、二维码签到签退、任务分配等功能，另外，针对一些应用内参数、开关的配置及相关下发的能力也可以做成统一的运营后台功能。

四、后端服务：承载业务逻辑和数据的“水下冰山”

“区区几个页面的APP，为什么需要这么多时间？”——当项目发起人或业务方有此疑问的时候，这表明其在一定程度上了解技术实现的成本，但可能未必全面，因此，非常有必要从技术角度解释清楚移动应用研发成本的构成。

根据业内统计和实践经验，一般来说，研发一款移动应用的总成本，除去前期的产品分析设计，后期约30%的投入在于前端应用开发以及UX设计，而70%的投入在于后端服务的开发。前端应用承载的业务逻辑和数据存取越“轻”，后端服务投入得越“重”，由于物流供应链业务偏toB的特点，出于数据安全性和业务逻辑整体性的需要，此类移动应用往往更加偏重于后端服务建设。

与PC Web应用不同的是，如果客户端不是工作在内网环境下（如仓内应用的WMS APP），构建移动应用的后台服务，一定需要在后端服务接口和前端移动应用之间架设一套“移动网关”服务。移动网关是连接移动客户端与后端服务的桥梁，它的主要作用是提供如下能力将内网的API服务“暴露”到公网上给客户端调用：

◦提供面向移动应用的服务API的注册、发现、管控，实现服务聚合与集成，为不同的客户终端屏蔽后端服务异构性，降低开发和管理的成本。

◦提供统一的传输加密机制、防篡改签名验证机制、防越权参数加盐机制等安全能力，提升数据安全性。

◦提供一定程度的数据压缩、缓存服务，以及限流、限速等管控功能，保护后端服务。

◦提供经过优化的数据协议与通讯协议，提高公网RPC通讯的质量和效率。

◦进一步地，为客户端提供RPC调用的存根（stub）生成服务，用SDK的形式，为客户端调用者屏蔽网络通信协议、传输数据格式的差异，提升开发效率；也可以帮助客户端自动装箱（Boxing）和拆箱（Unboxing），简化处理数据编码的工作量。

◦更进一步的，基于存根生成服务，统一服务端和客户端的异常处理机制，例如在服务端抛出明确的系统或业务异常供客户端分类处理，在客户端针对RPC异常弹出标准的对话框或提示框（Toast）。

在京东物流刚开始建设移动互联网产品时，市面上并没有合适的移动网关产品或服务供选择，因此我们不得不自建“移动网关”。进入到2024年，主流云计算平台提供的云原生移动网关已经相当成熟稳定了，完全可以放心选用。但如果你需要为本地化项目构建移动应用时，就不得不自行部署移动网关服务了，好在，目前可供选择的开源产品也有不少比较出色的，以下列举3款比较典型、功能丰富、可扩展、流行度广的开源产品供参考：

有了移动网关的“加持”，针对移动应用场景下的后端服务架构设计，我们仍然需要注意相对于PC Web应用：移动应用的性能表现对于后端服务传输的公网数据包大小较为敏感，如果有可能，尽量为移动应用提供专门的、数据精简的、服务聚合的API，尽量避免生硬照搬PC Web服务的API，特别是把大型报表展示的API拿来直接使用；另外，移动应用面临的混合网络（Wi-Fi/3G/4G/5G）情况不同于宽带网络，在某些情况下，后端服务的开发者需要考虑处理多种无线网络场景带来的切换、限制、中断等挑战；对于后端服务的架构师来说，为了减少网络延迟的风险和数据传输的损耗，也可以考虑将一些相对独立的计算和数据放到移动端本地进行处理。

五、情景：发挥“移动”的优势

开发移动应用的产品，除了要满足业务提出的基本需求之外，还要思考如何利用移动设备本身的硬件传感能力更好的优化现有业务，在一些情景下提供PC Web应用难以具备的能力，方能体现移动化的价值。目前，主流的消费级智能终端一般具有如下的场景感知能力：

如上所示，有了场景下的数据，移动应用产品就可以读取和分析用户在特定情景下的潜在“语义”，从而对业务和用户进行需求“预测”，方式包括但不限于人工规则配置、组织经验匹配以及机器学习+人工智能推理，然后就可以进行相应的业务处理或服务对接，从而提升业务效率和用户体验。

目前，在京东物流有很多典型的场景应用，例如运力系统会采集位置坐标信息，绘制运输轨迹，监控运输车辆，当然，这个功能在智能手机上实现，还需要做好“保活”技术研究；营业点巡检系统会采集照片、视频数据结合时间、地理信息，来验证和评估基层管理人员的工作效能；分拣中心内的IoT设备管理接入了微信小程序后，通过分析生产数据，实时推送异常告警，使现场问题的发现和处理变得高效快速，在某自动化分拣中心应用后，管理干预从原来的隔天提升到15分钟内，从而使丢失率、破损率、回流率等指标大幅度下降；另外，营业部、门店相关系统在包裹包装、门店陈列等场景下，规划实施“多终端多物料接触点二维码体系”助力分析用户决策，在提升用户的转化率方面起到了一定的作用。

六、体验：避免“移动”的痛点

把业务系统转向移动应用，也并非全都是优点。在充分发挥上述优势的时候，我们也要看到移动技术对用户体验造成的“痛点”，从而想办法在设计上去规避。

◦永远在线——移动应用的“永远在线”特性既可以提高用户黏性，也可能造成频繁地推送通知，对用户形成骚扰。不断打扰用户的行为可能会导致用户厌烦，关闭通知甚至卸载应用。正确的做法是，首先，我们需要根据经验或算法结合用户行为偏好，进行慎重、精准推送，提高通知的相关性以及对用户的价值，特别对于“工具”型应用应该避免追求“黏性”设计，转而打造“用完即忘”的用户体验；其次，如果业务允许，可以考虑在特定时间段内（如夜间）默认进入非打扰模式，或仅保留重要通知；最后，如果有必要，可以允许用户设置通知的类型、频率和时间，自主避免不必要的打扰。

◦输入厌恶——相对于显示器+物理键盘，利用移动设备的小屏+虚拟键盘进行批量文字输入和编辑十分繁琐，体验很难做好。首先，我们应该坚决将大文本编辑的需求转入PC Web应用，如果不可避免地需要在移动应用中填写长表单，也应该通过减少必填项、使用下拉菜单、使用单选或多选按钮等方式简化输入，或将长表单分段输入和提交来优化交互体验；其次，可以充分发挥智能终端设备语音输入友好的特性，提供语音识别功能，让用户可以通过语音录入文字，提升便捷性；最后，如果有必要，可以通过智能化技术简化输入流程，利用自动补全、建议文本、文本解析（例如：地址标准化识别）等方式减少用户输入的负担，即通过复制、粘贴、解析识别，然后加以简单编辑即可完成长文本录入。

◦资源受限——虽然当前移动终端设备的计算和存储能力越来越强，但由于CPU架构及散热功耗所限，相对于PC终端仍然属于“资源受限”设备。移动应用的持续运行和频繁数据同步会消耗大量电量和内存资源，同时某些社交型应用会在本地不断积存大量的数据内容，这会引起移动终端运行性能下降、存储空间耗尽，从而导致用户体验变差。为了避免这种问题，开发者要编写高效代码致力于减少不必要的资源消耗和后台任务，或通过调度策略优化后台任务的执行时间以减少电量消耗，还可以考虑提供“一键清理”功能（例如：社交应用的清理功能），帮助用户定期清理缓存和不再需要的本地数据。

◦流量敏感——虽然当前移动网络流量已经越来越便宜，但针对某些人群，或某些地区，或特定应用场景下， 我们仍然需要关注大量数据上传下载对用户的影响，避免造成用户困扰。首先，应该尽可能地采用数据压缩技术减少数据传输量，如使用HTTP/2协议传输、Gzip文本压缩、WebP格式图像等方案只需简单的配置或转换即可启用，并且为主流的现代浏览器所支持；其次，在业务场景和成本允许的前提下，开发离线功能，利用本地数据缓存，让用户不需要网络也能使用部分功能，并在有网络时同步数据；最后，可以在大流量操作前提示用户，或提供Wi-Fi优先选项（例如：应用市场内的下载功能），给予用户贴心的感受。

◦版本更新——不同于PC Web应用，移动APP的版本更新会对用户产生一定影响，频繁的版本更新可能导致用户感到厌烦，也会消耗用户的存储空间和流量，尤其是强制更新会打断用户的使用过程。因此，首先，我们要做好产品和需求的规划，有节奏地安排更新频率，避免过于频繁的更新发版，并特别要慎用“强制更新”策略，给用户留有余地，允许用户在方便时更新应用；其次，对于一些经常需要改动的模块，可以考虑使用之前提到的“积木式H5”或“热更新插件”技术，来实现无感知更新，减轻对用户正常使用的干扰；最后，可以在用户连接Wi-Fi或设备充电时，提示用户更新，给予用户贴心的感受。

七、总结并展望未来

从2008年开始，由于移动互联网行业发展初期广阔的蓝海空间、病毒式传播驱动大量用户增长带来的高估值、新技术带动新商业模式的涌现以及充裕风险投资的大量涌入，在短时间内确实造成了“做一个APP就能拿几百万投资”的夸张现象。然而，随着市场的逐渐成熟和竞争的加剧，时至今日，最初的移动互联网的热潮早已过去，行业逐渐趋于理性化，在当前阶段，移动应用开发者和企业很难仅通过商业模式创新就获得用户数量和收益的短期内爆发性增长，它们更加注重通过用户体验提升、技术优化以及精细化运营来提升业务的可持续发展能力以及商业利润变现，这与传统应用软件的发展趋势也是一致的。

对于未来，我们可以从当下一些新、热点技术的角度来展望移动应用的发展趋势，总体来说会朝着硬件融合、智能化的大方向发展。这些技术方向主要有：

◦新一代移动通信技术和物联网。随着5G技术的普及，移动应用能够进一步实现高速、低延迟的网络体验，推动更多实时性要求高的应用场景，如AR（增强现实）眼镜在仓储生产中的应用；另外，有了5G的支持，物联网（IoT）技术和设备将会加速普及，这会使得移动应用与硬件设备的融合更加紧密，加速自动化仓库、数字孪生、智慧城市以及其它工业互联网应用的发展。

◦无界（全场景）智能终端平台。对于消费类电子产品，智能化的趋势不仅局限于手机、平板、可穿戴设备，已经向家电、汽车等多种终端发展。未来的移动应用开发框架可能会向实现“跨平台无缝体验”的方向发展，“华为终端鸿蒙智能设备操作系统”正是基于此理念，通过利用“分布式”技术，将手机、电脑、平板、电视、汽车和智能穿戴等多款设备融合成一个“超级终端”，使用户便于操作和共享各种设备的资源。

◦生成式人工智能（AIGC）。 如前文所提到的，人工智能技术在京东物流的移动应用中从一开始就在广泛地应用，从OCR文本识别、IVR语音识别到路线规划、储位推荐，一直在持续提升业务的效率。而随着2022年生成式人工智能技术的爆发，利用大模型（LLM），计算机系统能够更好地理解用户的行为和需求，如果充分结合移动应用的优势，必将为用户提供更加精准高效的智能化服务。