一次真正意義上的低成本技術架構升級。
項目背景
衡東點貨網是根據物流行業(yè)發(fā)展趨勢及國家政策引導開發(fā)的網絡貨運平臺，其主要功能承載“車貨信息發(fā)布、匹配、運費支付與發(fā)放、信用管理等”。
而關于項目的開發(fā)人員組成，長期以來僅僅只是“核心開發(fā) 2 人 實習開發(fā) 2 人“的規(guī)模，在支撐日常的業(yè)務迭代方面力有不逮。同時，結合 2020 年網絡貨運平臺政策的調整，點貨網作為網絡貨運平臺，我們的移動端 App 內需嵌入監(jiān)管平臺的 SDK 插件，從而日常業(yè)務運營數(shù)據能夠與監(jiān)管平臺的系統(tǒng)打通，統(tǒng)一管理規(guī)范。
難點出現(xiàn)了。
因現(xiàn)有的開發(fā)團隊組成主要以 Java 工程師為主，同時能夠對接三方 SDK 的開發(fā)僅兩位，開發(fā)資源突然捉襟見肘。而在原有的工程中，存在 Uni-App 的選型，在缺少對方技術團隊支持的情況下，要我們現(xiàn)有團隊實現(xiàn)原生 SDK 的接入頗有難度。同時考慮到后續(xù)“點貨網 App”自身需具備接入原始 SDK 的能力，因此我們的視角開始轉向了“如何保障項目順利完成聯(lián)調測試，并提升自有 App 的健壯性”。
我們開始篩選市面上各類跨平臺的 App 開發(fā)技術，在此期間對比了 Uni-App、Weex、Flutter、mPaaS 等跨平臺開發(fā)框架。
作為一名 Java 開發(fā)，以上各跨平臺開發(fā)框架的對比僅作為第一印象。針對各框架的優(yōu)劣對比沒有展開深度分析，僅適用于大家在現(xiàn)有項目/工程中應對特定需求的技術選型參考。
因個人目前只具備 Java 和 Vue.js 的開發(fā)能力，無法在短時間內快速掌握一門全新的開發(fā)語音或原生 UI 組件開發(fā)的能力，但因業(yè)務要求我們務必要徹底提升 App 的健壯性，因此團隊決定將 Uni-App 替換為 mPaaS。
接入過程回顧
作為一名 Java 開發(fā)，對于 Vue.js 的語法還算熟悉，因此我在 2019 年 8 月起開始接觸并測試 mPaaS 的框架能力，尤其是小程序容器的部分，同時在這期間開始了解安卓開發(fā)的相關知識。
2020 年 6 月開始，我開始嘗試獨立接入 mPaaS 小程序，針對點貨網 App 進行功能遷移并正式接入監(jiān)管 SDK 插件。
由于在正式使用之前，我已了解到 mPaaS 產品的具體特性，也了解到 mPaaS 不同版本之間開發(fā)配置存在一定差異，最終我們決定直接基于“mPaaS 小程序 Demo”實現(xiàn)點貨網的基礎功能，并在此基礎上針對功能進行調整，以滿足自身業(yè)務特性的需要。期間也有遇到一些小問題，在 mPaaS 研發(fā)團隊的支持下得以順利解決。
我們也建議大家，如果是初次接觸 mPaaS，務必要針對官方文檔提供的步驟，結合現(xiàn)有的 Demo 進行測試，避免因技術框架兼容性導致各類異常錯誤。
最終，得益于 mPaaS 小程序的不斷升級迭代，點貨網 App 的小程序組件接入和更新也變得愈發(fā)簡單，技術門檻被極大地降低優(yōu)化。
回顧第一版點貨網 App 接入 mPaaS 小程序容器的場景，當時我們團隊只有兩位技術開發(fā)，另外一位同學還需要兼顧運維和其他開發(fā)事項，因此實際上真正開發(fā)的只有一個人。
面對這樣的情況，我們只能選擇冒險。但本質上，我們實際上信任的還是 mPaaS 具備原生應用與小程序兼容的框架能力，以及 mPaaS 技術團隊的支持響應速度。
我們選擇現(xiàn)有的 App 直接接入 mPaaS 進行開發(fā)，為了加快業(yè)務的迭代速度，第一版點貨網 App 中我們只包含原有 App 的核心功能和監(jiān)管 SDK 能力，并同時根據實際業(yè)務需求完成迭代。
目前，點貨網 App 基于 mPaaS 小程序，已成功實現(xiàn)從歡迎頁啟動后自動進入小程序，并直接調用自定義 API 實現(xiàn)歡迎頁面銷毀和安卓端權限校驗的功能。預計八月下旬，我們將正式上線，替換原有的 App 為客戶提供服務。
價值沉淀
回顧接入 mPaaS 小程序的歷程，我們也受益良多。對于 Java 開發(fā)同學而言，我們不再需要專門學習安卓的 UI，用熟悉的 HTML 即可直接進行頁面開發(fā)，真正地以較低成本進行技術架構的升級。
而我們的 Web 端與小程序的網絡請求全部使用相同的框架，因此 Web 端已開發(fā)完成的業(yè)務能夠快速地遷移至 mPaaS 小程序中，只需簡單的調整即可滿足 mPaaS 業(yè)務邏輯的處理需要，從而避免業(yè)務邏輯代碼重復編寫，保證雙端業(yè)務邏輯一致，降低多人協(xié)作中業(yè)務理解差異導致項目實現(xiàn)不一致的問題。
實現(xiàn) mPaaS 接入后，只有在原生 SDK 插件變更時或增加時，我們才需要針對 App 進行更新。像一般小程序的功能調整、變更、升級，均可以實現(xiàn)用戶無感知升級，避免對用戶的打擾，同時也能充分滿足我們業(yè)務快速迭代的訴求。
未來展望
作為一名非專業(yè)的 App 開發(fā)，我們也由衷希望 mPaaS 能夠推出插件市場或者平臺，為開發(fā)者直接提供如人臉核身、圖片識別、手機號碼校驗等通用基礎 API 服務或者功能。
開發(fā)者的訴求實際上很簡單，如果能專注于業(yè)務的需求開發(fā)，而不是重復地接入通用化的能力，對于個人及業(yè)務的成長都具有一定價值。
未來“點貨網 App”將繼續(xù)依托 mPaaS，利用現(xiàn)有的移動端組件能力幫助 App 持續(xù)升級。以客戶的需求為導向，結合實際業(yè)務隨取，為客戶提供簡單、便捷和實用的 App 體驗。對于“點貨網 App”而言，我們同時也保持開放，希望能夠跟更多開發(fā)者一起交流接入、使用 mPaaS 過程中遇到的問題，和大家一起共建 mPaaS 的開發(fā)者生態(tài)。
本文為阿里云原創(chuàng)內容，未經允許不得轉載。
版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經查實，本站將立刻刪除。
