一、引言

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），計算機系統能夠更好地理解用戶的行為和需求，如果充分結合移動應用的優勢，必將為用戶提供更加精準高效的智能化服務。

審核編輯 黃宇