去年接了一個運動員綜合分析訓(xùn)練系統(tǒng)的項目技術(shù)棧定在 uniapp springboot一套前端代碼同時覆蓋安卓 App 和微信小程序后端用 Java 搭一套完整的業(yè)務(wù)接口。這個項目做完給我的最大感受是它有難度但難度不在某個單獨的技術(shù)點上而是怎么把跨端開發(fā)、藍牙數(shù)據(jù)采集、實時分析和多端打包這些事放在同一個項目里穩(wěn)定地跑起來。這篇文章就把整個項目的設(shè)計和落地過程完整拆一遍從技術(shù)選型到關(guān)鍵代碼從踩坑記錄到優(yōu)化方案盡量把能直接抄作業(yè)的細節(jié)都寫出來。無論你是剛接觸 uniapp 和 springboot 的新手還是準(zhǔn)備做類似體育訓(xùn)練、運動健康類應(yīng)用的同學(xué)這篇文章都應(yīng)該能幫到你。1. 項目定位與整體方案設(shè)計1.1 項目到底要做什么運動員綜合分析訓(xùn)練系統(tǒng)核心業(yè)務(wù)不復(fù)雜但涉及的邊界挺多。簡單說它要圍繞一名運動員的日常訓(xùn)練做全流程管理教練創(chuàng)建訓(xùn)練計劃運動員在手機端接收計劃并執(zhí)行執(zhí)行過程中的運動數(shù)據(jù)時長、心率、里程、打卡頻次、訓(xùn)練重量和組數(shù)等被采集并上報到后端后端經(jīng)過計算和分析后把結(jié)果反饋給教練和運動員形成一個“計劃、執(zhí)行、反饋、調(diào)整”的閉環(huán)。在做需求拆解的時候我把整個系統(tǒng)拆成這幾個核心模塊運動員檔案管理維護運動員基礎(chǔ)信息、體能指標(biāo)、歷史傷病記錄等。訓(xùn)練計劃管理教練按周期創(chuàng)建訓(xùn)練計劃可以細化到每天的訓(xùn)練項目和強度。訓(xùn)練數(shù)據(jù)采集App 和小程序端記錄訓(xùn)練過程數(shù)據(jù)支持藍牙設(shè)備接入心率帶、手環(huán)和手動錄入。綜合分析引擎對累積的訓(xùn)練數(shù)據(jù)做統(tǒng)計分析生成趨勢圖和報告輔助教練判斷訓(xùn)練效果。消息提醒與反饋訓(xùn)練計劃下發(fā)提醒、教練點評和調(diào)整建議推送。初期很多人會犯一個錯誤就是上來就寫代碼。我建議先把核心業(yè)務(wù)實體和它們之間的關(guān)系畫清楚哪怕用一張紙畫個草圖都行。這個項目里核心的表其實沒幾張運動員表、教練表、訓(xùn)練計劃表、訓(xùn)練記錄表、分析結(jié)果表外加用戶綁定表和系統(tǒng)配置表。表和表之間的關(guān)系理順了后端的寫法和前端的頁面設(shè)計都會清晰很多。1.2 技術(shù)選型背后的取舍邏輯選 uniapp 的理由非常直接項目要求必須同時覆蓋安卓 App 和微信小程序而團隊的成員對 Vue 語法比較熟。uniapp 基于 Vue 發(fā)展而來寫一套代碼可以編譯到 App、小程序和 H5 等多個平臺開發(fā)效率高維護成本低遇到復(fù)雜的原生能力也可以通過插件市場找現(xiàn)成方案或者寫原生插件去補充。當(dāng)時也考慮過兩個單獨的方案比如原生安卓加原生小程序或者 Flutter 加小程序但都被否了。原生開發(fā)意味著兩套代碼、兩套維護人員成本至少要翻倍。Flutter 雖然性能好但它在小程序端的支持并不成熟還是要額外寫一套小程序代碼等于工作量回到原點。springboot 的選擇也是從實際需求出發(fā)的。這個系統(tǒng)有大量數(shù)據(jù)統(tǒng)計和報表需求Java 生態(tài)里做數(shù)據(jù)處理的類庫非常豐富比如 Hutool、MyBatis-Plus、EasyExcel 這些工具能大大提升開發(fā)效率。springboot 的自動配置和 starter 機制讓我可以不用花大量時間在框架配置上專心寫業(yè)務(wù)邏輯。而且 springboot 天然適合做微服務(wù)的演進路徑項目初期可以用單體架構(gòu)快速上線后續(xù)如果需要拆分成獨立的分析服務(wù)、消息服務(wù)也方便平滑過渡。架構(gòu)上我采用了經(jīng)典的前后端分離模式。前端 uniapp 負責(zé)頁面展示和用戶交互后端 springboot 提供 RESTful API數(shù)據(jù)傳輸統(tǒng)一用 JSON認證采用 Token 機制。移動端通過 HTTP 請求訪問后端接口部分實時性要求高的場景比如訓(xùn)練數(shù)據(jù)同步可以用 WebSocket 補充。整體流量鏈路是“App/小程序——API 網(wǎng)關(guān)或負載均衡——springboot 服務(wù)——MySQL 數(shù)據(jù)庫”如果后續(xù)數(shù)據(jù)量大了可以再引入 Redis 做緩存和消息隊列做異步處理。1.3 系統(tǒng)架構(gòu)與數(shù)據(jù)流轉(zhuǎn)這里說到數(shù)據(jù)流轉(zhuǎn)是整個系統(tǒng)的靈魂。我把一次完整的訓(xùn)練閉環(huán)梳理成了下面幾個步驟教練在 App 端創(chuàng)建訓(xùn)練計劃后端存儲計劃數(shù)據(jù)并生成待辦任務(wù)。運動員登錄小程序或 App查看自己的訓(xùn)練計劃點擊開始訓(xùn)練。訓(xùn)練過程中前端采集數(shù)據(jù)。如果連接了藍牙設(shè)備可以通過 BLE 接口實時讀取心率等數(shù)據(jù)如果沒有設(shè)備就采用手動錄入。訓(xùn)練結(jié)束后前端把數(shù)據(jù)打包上報給后端接口后端校驗數(shù)據(jù)完整性寫入訓(xùn)練記錄表。后端的分析模塊執(zhí)行統(tǒng)計任務(wù)更新運動員的累計訓(xùn)練數(shù)據(jù)和趨勢指標(biāo)。教練在管理端查看分析結(jié)果必要時調(diào)整后續(xù)計劃。這個閉環(huán)通過幾個關(guān)鍵接口串聯(lián)起來我會在后面第 4 節(jié)詳細講接口的設(shè)計和實現(xiàn)。現(xiàn)在先把整體結(jié)構(gòu)放在腦子里后面每個環(huán)節(jié)就知道自己在整個系統(tǒng)里的位置了。2. uniapp 前端環(huán)境搭建與關(guān)鍵技術(shù)落地2.1 項目初始化和目錄結(jié)構(gòu)規(guī)劃使用 HBuilderX 創(chuàng)建 uniapp 項目時我建議直接選“默認模板”不要去選那些帶復(fù)雜 UI 組件的模板因為自帶的示例代碼往往用不上清理起來反而麻煩。項目創(chuàng)建好以后第一步是配置 manifest.json這里面的配置直接決定你的應(yīng)用在各端的表現(xiàn)。manifest.json 里需要關(guān)注幾個關(guān)鍵配置項基礎(chǔ)配置應(yīng)用名稱、AppIDDCloud 申請、版本號。App 圖標(biāo)和啟動圖安卓打包必備圖標(biāo)需要多尺寸可以直接用工具生成。模塊配置如果要用藍牙、掃碼、地圖等原生能力需要在這里勾選對應(yīng)的模塊。小程序配置微信小程序需要填寫 AppID1.0 以上的基礎(chǔ)庫版本建議根據(jù)自己依賴的 API 調(diào)整。目錄結(jié)構(gòu)上我一般按業(yè)務(wù)模塊劃分 pages而不是默認的“pages 下面平鋪所有頁面”。比如這個項目里我建了這些目錄pages/ login/ 登錄頁 home/ 首頁 plan/ 訓(xùn)練計劃列表、詳情 training/ 訓(xùn)練執(zhí)行頁 record/ 訓(xùn)練記錄 analyze/ 數(shù)據(jù)分析 profile/ 個人中心靜態(tài)資源放到 static 目錄公共組件放 components公共工具方法請求封裝、登錄態(tài)處理、格式化放 utils。把工具方法獨立出來的好處是不管頁面怎么加核心邏輯不會散落各處改一處全項目生效。2.2 頁面路由與參數(shù)傳遞的核心寫法uniapp 的路由跳轉(zhuǎn)使用uni.navigateTo跳轉(zhuǎn)時如果需要帶參數(shù)直接拼在 url 后面就行。這個項目里從訓(xùn)練計劃列表跳到詳情頁就是典型的參數(shù)傳遞場景uni.navigateTo({ url: /pages/plan/detail?id item.id typeitem.type });在目標(biāo)頁面的onLoad生命周期里接收參數(shù)onLoad(options) { this.planId options.id; this.planType options.type; }這里有一個容易踩的坑如果參數(shù)是一個對象直接拼接字符串得到的是[object Object]傳過去以后完全沒法用。正確做法是先序列化再編碼const param encodeURIComponent(JSON.stringify(item)); uni.navigateTo({ url: /pages/plan/detail?data param }); // 接收JSON.parse(decodeURIComponent(options.data))實際上是提醒大家路由參數(shù)本身只適合傳簡單的標(biāo)識字段。如果是大量數(shù)據(jù)或者包含敏感信息正確做法是前端維護一個全局數(shù)據(jù)緩存路由只傳業(yè)務(wù) id頁面加載時通過 id 去拿詳細數(shù)據(jù)。這樣既安全也不會有 URL 長度超限的隱患。2.3 藍牙設(shè)備接入訓(xùn)練數(shù)據(jù)采集的硬核環(huán)節(jié)這個項目里運動員訓(xùn)練時要用到藍牙心率帶所以 BLE 藍牙接入是前端開發(fā)中比較核心的部分。uniapp 的藍牙 API 體系基本覆蓋了 BLE 的完整鏈路大致流程是初始化藍牙 - 搜索設(shè)備 - 連接設(shè)備 - 獲取服務(wù) - 獲取特征值 - 監(jiān)聽特征值變化獲取心率數(shù)據(jù)。我在項目里封裝了一個藍牙工具類核心邏輯大致如下// 初始化藍牙適配器 uni.openBluetoothAdapter({ success() { // 開始搜索設(shè)備 uni.startBluetoothDevicesDiscovery({ allowDuplicatesKey: false, success(res) { // 若搜索到設(shè)備通過 onBluetoothDeviceFound 監(jiān)聽 uni.onBluetoothDeviceFound((res) { res.devices.forEach(device { if (device.name device.name.indexOf(HeartRate) ! -1) { // 找到了心率設(shè)備保存 deviceId 并停止搜索 this.deviceId device.deviceId; uni.stopBluetoothDevicesDiscovery({}); } }); }); } }); } }); // 連接藍牙設(shè)備 uni.createBLEConnection({ deviceId: this.deviceId, success() { // 獲取設(shè)備服務(wù) uni.getBLEDeviceServices({ deviceId: this.deviceId, success(res) { // 遍歷 services找到心率服務(wù)通常 UUID 包含 180d // 然后再通過 getBLEDeviceCharacteristics 獲取特征值 } }); } }); // 監(jiān)聽心率特征值變化 uni.notifyBLECharacteristicValueChange({ state: true, deviceId: this.deviceId, serviceId: this.serviceId, characteristicId: this.characteristicId, success() { uni.onBLECharacteristicValueChange((res) { // 解析心率數(shù)據(jù)通常心率數(shù)據(jù)在 DataView 的特定字節(jié) const heartRate this.parseHeartRate(res.value); this.currentHeartRate heartRate; }); } });這里有一個必須注意的細節(jié)藍牙接口幾乎全是異步的而且回調(diào)層級很深如果不做封裝代碼會變成“回調(diào)地獄”。建議在實際項目中用 Promise 封裝每個藍牙操作再用 async/await 把流程串起來代碼可讀性會高很多。另外打包成 App 以后還需要在 manifest 的“App 模塊配置”里勾選 Bluetooth 模塊否則接口調(diào)用會失敗。小程序端藍牙權(quán)限需要用戶授權(quán)要注意在調(diào)用前先檢查授權(quán)狀態(tài)被拒絕以后要有引導(dǎo)用戶開啟的提示邏輯。2.4 數(shù)據(jù)可視化用 echarts 在 uniapp 中畫趨勢圖運動員訓(xùn)練分析系統(tǒng)里數(shù)據(jù)可視化是剛需。教練和運動員都希望看到一段時間內(nèi)的訓(xùn)練趨勢、負荷變化、成績提升曲線這些用表格無法直觀呈現(xiàn)必須上圖表。uniapp 中使用 echarts我推薦通過lime-echarts這個插件來實現(xiàn)它做了小程序端和 App 端的兼容處理。如果你用原生 echarts 自己寫大概率會在小程序 canvas 渲染上遇到各種兼容性問題。安裝好插件后圖表初始化的方式類似這樣import * as echarts from /components/lime-echarts/echarts; // 渲染一個訓(xùn)練負荷趨勢折線圖 const chart this.$refs.chartRef.init(echarts); chart.setOption({ title: { text: 近30天訓(xùn)練負荷趨勢 }, tooltip: { trigger: axis }, xAxis: { type: category, data: this.dateList }, yAxis: { type: value, name: 負荷指數(shù) }, series: [{ name: 訓(xùn)練負荷, type: line, smooth: true, areaStyle: {}, data: this.loadList }] });實際做下來有幾個注意點圖表組件必須設(shè)置明確的高度不然畫布高度為 0 什么都顯示不出來Web 端的圖表渲染邏輯和小程序端有差異盡量在數(shù)據(jù)加載完成后調(diào)用 init 并且加上 setTimeout 延遲幾十毫秒避免 canvas 尚未完成渲染導(dǎo)致的白屏問題。性能方面圖表實例不要頻繁銷毀重建數(shù)據(jù)變化時用setOption更新即可否則會不斷創(chuàng)建 canvas內(nèi)存占用會越來越大。2.5 小程序端適配與分享功能uniapp 一次開發(fā)多端運行聽起來很美實際上多端適配的細節(jié)還是不少。我在這個項目里遇到的主要問題有三個自定義導(dǎo)航欄、軟鍵盤遮擋、分享功能。自定義導(dǎo)航欄小程序的默認導(dǎo)航欄樣式有限為了統(tǒng)一 App 和小程序的體驗我在項目里啟用了自定義導(dǎo)航欄。做法是在 pages.json 里設(shè)置navigationStyle: custom然后在頁面里通過計算狀態(tài)欄高度和膠囊按鈕位置來布局。具體代碼要處理不同機型的兼容這里分享一個常用的獲取系統(tǒng)信息的寫法const systemInfo uni.getSystemInfoSync(); this.statusBarHeight systemInfo.statusBarHeight; // 狀態(tài)欄高度 // 如果是小程序還需要獲取膠囊按鈕位置 const menuButton uni.getMenuButtonBoundingClientRect(); this.navBarHeight menuButton.height (menuButton.top - this.statusBarHeight) * 2;軟鍵盤遮擋問題在小程序里輸入訓(xùn)練備注或重量數(shù)據(jù)時軟鍵盤彈起會遮擋輸入框。這個問題我在相關(guān)搜索里也看到很多人在問。常規(guī)做法是在 input 的 adjust-position 屬性上做文章或者用uni.pageScrollTo把頁面滾動到輸入框可見的位置。但我實測下來最全面的方案是監(jiān)聽鍵盤高度變化然后把整個最外層容器的高度動態(tài)抬高onLoad() { uni.onKeyboardHeightChange(res { this.keyboardHeight res.height; }); }然后在模板里給底部輸入?yún)^(qū)域動態(tài)綁定margin-bottom: {{keyboardHeight}}px。注意onKeyboardHeightChange只在部分平臺上支持實際開發(fā)中還是要結(jié)合bindkeyboardheightchange這類平臺專屬事件做兼容處理。分享功能uniapp 中自定義分享首先要確保onShareAppMessage生命周期函數(shù)存在否則小程序右上角菜單不會顯示“分享”按鈕。如果你在全局混入了onShareAppMessage要注意頁面本身定義的分享方法是否會覆蓋全局方法避免出現(xiàn)分享標(biāo)題和圖片失效的情況。分享時可以自定義標(biāo)題、路徑和圖片onShareAppMessage() { return { title: 我的訓(xùn)練計劃, path: /pages/plan/detail?id this.planId, imageUrl: /static/share-bg.png }; }App 端的分享則通常依賴原生插件比如集成微信 SDK 后調(diào)用uni.share接口這部分的配置要比小程序端復(fù)雜一些需要在 manifest 里配置微信分享的 AppID 和 Universal Link。3. springboot 后端核心開發(fā)與接口設(shè)計3.1 工程結(jié)構(gòu)和依賴選型后端工程我使用 Maven 構(gòu)建Spring Initializr 生成基礎(chǔ)項目Java 版本選了 8。很多同學(xué)喜歡一上來就用最新版 Java 和高版本 Spring Boot但實際上版本越新潛在的兼容性問題越多。我在項目里用的是 Spring Boot 2.7.x 系列它穩(wěn)定、社區(qū)資料多、和各種組件的兼容性都經(jīng)過了充分驗證完全滿足業(yè)務(wù)需求。如果你選了 Spring Boot 3.x需要注意它基于 Jakarta EE很多第三方組件還在適配期遇到問題排查成本會高一些。核心依賴包括dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version3.19.4/version /dependency工程分層我用的是經(jīng)典的 Controller - Service - Mapper 三層結(jié)構(gòu)另外單獨建了 config、common、entity、dto、vo 這些包。common 包里放統(tǒng)一返回結(jié)果、全局異常處理器、常量定義這些基礎(chǔ)代碼早點寫好后面每個接口都能復(fù)用能省不少事。3.2 數(shù)據(jù)庫設(shè)計與自動建表數(shù)據(jù)庫設(shè)計上這個項目最重要的幾張表我列一下核心字段運動員表CREATE TABLE athlete ( id bigint(20) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 姓名, gender tinyint(4) DEFAULT NULL COMMENT 性別 1男 2女, age int(11) DEFAULT NULL, height decimal(5,2) DEFAULT NULL, weight decimal(5,2) DEFAULT NULL, sport_type varchar(50) DEFAULT NULL COMMENT 運動項目, level varchar(20) DEFAULT NULL COMMENT 運動員等級, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;訓(xùn)練計劃表包含計劃名稱、訓(xùn)練周期、訓(xùn)練內(nèi)容、計劃狀態(tài)、創(chuàng)建人、創(chuàng)建時間。訓(xùn)練記錄表包含運動員 ID、計劃 ID、訓(xùn)練日期、訓(xùn)練時長、平均心率、最大心率、訓(xùn)練距離、訓(xùn)練重量、訓(xùn)練組數(shù)、備注等。分析結(jié)果表則存儲后端的分析輸出包括訓(xùn)練負荷、訓(xùn)練成效、體能評分等。關(guān)于建表有一個提升開發(fā)效率的方案是 MyBatis-Plus 的自動建表能力。通過自定義一個表結(jié)構(gòu)初始化組件在項目啟動時掃描實體類如果發(fā)現(xiàn)表不存在就自動執(zhí)行建表 SQL。這個方案尤其在開發(fā)環(huán)境很有用團隊成員拉下代碼后不需要手動執(zhí)行 SQL 腳本啟動項目就能直接跑。實現(xiàn)思路是在 ApplicationRunner 或 CommandLineRunner 里檢查表是否存在然后動態(tài)執(zhí)行建表語句。你可以直接使用 MyBatis-Plus 的DbType和TableInfoHelper來獲取實體對應(yīng)的表信息也可以更簡單粗暴地在初始化 SQL 文件里用CREATE TABLE IF NOT EXISTS語句啟動時用 JdbcTemplate 執(zhí)行整個 SQL 文件。后者的實現(xiàn)更可控符合大多數(shù)項目的實際需求。3.3 安全與配置管理yml 敏感信息處理后面在 yml 配置文件里數(shù)據(jù)庫密碼、密鑰這些敏感信息不能明文存。很多項目直接把密碼寫在 application.yml 里代碼上傳到倉庫后密碼就泄露了。正確做法是用 Jasypt 對敏感信息加密運行時自動解密。引入依賴dependency groupIdcom.github.ulisesbocchio/groupId artifactIdjasypt-spring-boot-starter/artifactId version3.0.5/version /dependency然后在配置里這樣寫spring: datasource: url: ENC(xxxx加密后的數(shù)據(jù)庫連接串) username: ENC(xxxx加密后的用戶名) password: ENC(xxxx加密后的密碼) jasypt: encryptor: password: your-salt加密后的值用ENC()包起來。Jasypt 會在 springboot 加載配置時自動解密。注意加密鹽值password 字段不要寫在配置里可以通過環(huán)境變量或者啟動參數(shù)傳入比如java -jar app.jar --jasypt.encryptor.passwordyour-salt這樣即使配置文件泄露沒有鹽值也拿不到明文密碼。雖然 Jasypt 不是唯一方案但在 springboot 項目中它是最成熟和簡單的強力推薦。3.4 接口設(shè)計與統(tǒng)一返回格式前后端分離模式下接口設(shè)計的好壞直接影響開發(fā)效率。我第一次做這個項目時沒有統(tǒng)一返回格式每個接口返回的數(shù)據(jù)結(jié)構(gòu)都不一樣前端聯(lián)調(diào)時苦不堪言。后來我封裝了統(tǒng)一的 Result 類public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }所有接口返回結(jié)構(gòu)一致前端只需要寫一次響應(yīng)攔截器統(tǒng)一處理 code 和 message。這種方式看似簡單實際帶來的效率提升非常明顯。身份認證這塊我采用了 JWTJSON Web Token方案。用戶登錄成功后后端生成一個有效期為 24 小時的 Token前端每次請求時放在請求頭 Authorization 中傳遞后端通過攔截器統(tǒng)一校驗。登錄接口本身不需要 Token其他接口一律校驗這樣才能保證接口安全。攔截器配置如下public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登錄接口通過路徑判斷或注解控制 String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BusinessException(401, 未登錄或登錄已過期); } // 解析并校驗 token try { JWT.require(Algorithm.HMAC256(SECRET)).build().verify(token); return true; } catch (Exception e) { throw new BusinessException(401, Token無效); } } }4. 核心功能完整實操從訓(xùn)練計劃到數(shù)據(jù)分析4.1 教練端訓(xùn)練計劃的創(chuàng)建與下發(fā)教練創(chuàng)建訓(xùn)練計劃的流程是這樣的前端填寫計劃信息名稱、周期、訓(xùn)練項目、強度要求等提交到后端/api/plan/create接口。后端接收請求后先做參數(shù)校驗然后寫入訓(xùn)練計劃表并且給指定的運動員生成待執(zhí)行記錄返回創(chuàng)建成功的計劃 ID。創(chuàng)建計劃的 Controller 大致是PostMapping(/api/plan/create) public ResultLong createPlan(RequestBody Valid PlanCreateDTO dto) { Long planId planService.createPlan(dto); return Result.success(planId); }Service 層處理核心邏輯Override public Long createPlan(PlanCreateDTO dto) { // 1. 保存計劃基本信息 TrainingPlan plan new TrainingPlan(); BeanUtils.copyProperties(dto, plan); plan.setStatus(0); // 0-未開始 1-進行中 2-已完成 plan.setCreateTime(new Date()); planMapper.insert(plan); // 2. 給計劃關(guān)聯(lián)的運動員生成任務(wù)記錄 ListLong athleteIds dto.getAthleteIds(); athleteIds.forEach(athleteId - { PlanAssign assign new PlanAssign(); assign.setPlanId(plan.getId()); assign.setAthleteId(athleteId); assign.setStatus(0); assign.setCreateTime(new Date()); planAssignMapper.insert(assign); }); // 3. 這里可以發(fā)送消息通知比如通過微信模板消息 return plan.getId(); }這里有幾個小細節(jié)值得說。第一計劃狀態(tài)我用的是數(shù)值枚舉而不是字符串好處是存儲空間小、查詢效率高但壞處是不夠直觀所以建議在枚舉類里定義好狀態(tài)值的含義避免后期混亂。第二給運動員生成任務(wù)記錄時要把運動員和計劃關(guān)聯(lián)起來運動員端查看“我的計劃”時直接通過關(guān)聯(lián)表查詢而不要每次去掃描所有計劃再篩選。4.2 訓(xùn)練數(shù)據(jù)的采集與上報訓(xùn)練數(shù)據(jù)的采集是整個系統(tǒng)中數(shù)據(jù)入口也是最容易出現(xiàn)臟數(shù)據(jù)的地方。前端在訓(xùn)練過程中可能因為網(wǎng)絡(luò)波動、程序異常導(dǎo)致數(shù)據(jù)上報失敗所以我在后端設(shè)計中特別強調(diào)了接口的冪等性設(shè)計。運動員點擊“結(jié)束訓(xùn)練”后前端會將本次訓(xùn)練的所有數(shù)據(jù)打包上報const reportData { planId: this.planId, trainingDate: this.trainingDate, duration: this.duration, // 訓(xùn)練時長秒 avgHeartRate: this.avgHeartRate, maxHeartRate: this.maxHeartRate, distance: this.distance, // 公里 weight: this.totalWeight, // 總重量公斤 setCount: this.setCount, remark: this.remark }; uni.request({ url: https://api.example.com/api/training/report, method: POST, data: reportData, success(res) { // 處理上報結(jié)果 } });后端接收上報后要處理幾個核心問題冪等校驗同一個計劃同一天不能重復(fù)上報或者用前端生成的業(yè)務(wù)流水號requestId去重。數(shù)據(jù)合法性校驗心率范圍是否合理20~240時長是否超過 24 小時距離是否為負這些前置校驗在進入業(yè)務(wù)邏輯之前就要完成避免臟數(shù)據(jù)直接寫庫。事務(wù)一致性寫入訓(xùn)練記錄和更新分析結(jié)果必須在一個事務(wù)里失敗則全部回滾保證數(shù)據(jù)的一致性。具體的 Service 層邏輯Override public void reportTraining(TrainingReportDTO dto) { // 1. 冪等校驗檢查 requestId 是否已存在 Integer count trainingReportMapper.selectCountByRequestId(dto.getRequestId()); if (count 0) { return; // 說明是重復(fù)提交直接返回 } // 2. 數(shù)據(jù)合法性校驗 if (dto.getAvgHeartRate() ! null (dto.getAvgHeartRate() 20 || dto.getAvgHeartRate() 240)) { throw new BusinessException(平均心率數(shù)據(jù)不合法); } // 3. 寫入訓(xùn)練記錄 TrainingRecord record new TrainingRecord(); BeanUtils.copyProperties(dto, record); record.setCreateTime(new Date()); trainingRecordMapper.insert(record); // 4. 更新運動員累計訓(xùn)練數(shù)據(jù) athleteStatService.updateStat(dto.getAthleteId(), dto); }這里要特別注意的是并發(fā)問題。如果同一次訓(xùn)練被前端同時提交兩次可能會繞過冪等校驗所以更穩(wěn)妥的做法是在數(shù)據(jù)庫層面用唯一索引約束 requestId從底層保證不會插入重復(fù)數(shù)據(jù)。4.3 綜合分析面板的實現(xiàn)邏輯綜合分析是本系統(tǒng)的核心亮點。訓(xùn)練數(shù)據(jù)積累到一定量后后端需要對數(shù)據(jù)進行匯總和計算輸出有價值的信息。我在實現(xiàn)時主要做了以下分析維度訓(xùn)練負荷結(jié)合訓(xùn)練時長、平均心率和訓(xùn)練強度計算一個負荷指數(shù)。訓(xùn)練頻次統(tǒng)計每周、每月的訓(xùn)練次數(shù)和規(guī)律性。成績趨勢根據(jù)訓(xùn)練記錄的累積數(shù)據(jù)繪制運動員的體能變化曲線。效果對標(biāo)把當(dāng)前運動員的數(shù)據(jù)和同級別運動員的平均數(shù)據(jù)做對比。訓(xùn)練負荷指數(shù)的計算我用了一個相對簡單的公式負荷指數(shù) 訓(xùn)練時長分鐘 × 平均心率 / 100這個公式來自訓(xùn)練監(jiān)控領(lǐng)域的 TRIMP 概念簡化版雖然不是最精確的但在工程實現(xiàn)上可解釋性強數(shù)據(jù)變化趨勢也能反映訓(xùn)練強度的波動。分析接口的數(shù)據(jù)返回結(jié)構(gòu){ code: 200, message: success, data: { trend: { dates: [2025-01-01, 2025-01-02], load: [80, 95], duration: [60, 75] }, stats: { totalTrainings: 24, totalDuration: 1560, avgHeartRate: 142 } } }前端拿到這些數(shù)據(jù)后在 echarts 里渲染趨勢圖和統(tǒng)計卡效率很高后端基本不用拼接 HTML專注輸出結(jié)構(gòu)化數(shù)據(jù)即可。5. 常見問題排查與避坑實錄5.1 uniapp 運行到微信開發(fā)者工具沒反應(yīng)這個問題在開發(fā)初期幾乎每臺電腦都會遇到一次。uniapp 通過 HBuilderX 運行到微信開發(fā)者工具經(jīng)常遇到“沒反應(yīng)”“編譯成功但工具不打開”的情況。排查思路按優(yōu)先級來先確認微信開發(fā)者工具的“設(shè)置 - 安全設(shè)置 - 服務(wù)端口”已開啟。如果服務(wù)端口沒打開HBuilderX 無法通過命令行調(diào)用工具打開項目。其次看項目目錄下是否有dist/dev/mp-weixin目錄生成如果沒有說明 uniapp 編譯失敗看控制臺報錯信息。如果有編譯產(chǎn)物但工具不打開可以手動點擊微信開發(fā)者工具的“導(dǎo)入項目”選擇dist/dev/mp-weixin目錄一般就能定位問題。5.2 小程序支付功能對接的那些事項目里涉及訓(xùn)練課程的付費購買需要對接微信支付。第一個坑就是小程序支付必須先完成微信認證并且要開通微信支付商戶號。如果小程序因為違規(guī)導(dǎo)致支付功能被限制需要在微信公眾平臺查看具體的違規(guī)原因處理完申訴后才能恢復(fù)。對接微信支付 V3 接口時我強烈建議使用官方 SDK不要自己寫簽名邏輯簽名細節(jié)太容易出錯了一個字段順序不對就會報簽名錯誤。5.3 安卓高版本系統(tǒng)的兼容問題有些測試機是 Android 14有些老的測試機還是 Android 8。uniapp 打包的 App 默認 targetSdkVersion 版本往往較高導(dǎo)致低版本安卓系統(tǒng)無法安裝。解決辦法是在打包時設(shè)置合適的 targetSdkVersion或者通過云打包界面設(shè)置“支持最低安卓版本”。一般把 minSdkVersion 設(shè)為 21Android 5.0即可覆蓋絕大多數(shù)機型。另外Android 6.0 以上系統(tǒng)對權(quán)限管理做了改動藍牙、定位等敏感權(quán)限需要動態(tài)申請uniapp 框架內(nèi)會在調(diào)用相關(guān) API 時自動彈窗申請但你要確保在 manifest 里聲明了對應(yīng)的權(quán)限否則真機運行時接口會直接返回失敗。應(yīng)用上架安卓應(yīng)用市場時各家市場華為、小米、OPPO、vivo 等對隱私政策的要求越來越嚴格在 manifest 里配置隱私彈窗時要明確告知用戶收集了哪些信息。如果用戶點擊“不同意”需要退出 App 而不是繼續(xù)使用。這里補充一個實際經(jīng)驗需要用條件編譯區(qū)分 App 端和小程序端因為小程序的隱私政策授權(quán)邏輯和 App 不太一樣。App 端在用戶拒絕隱私政策后退出 App 的寫法// 用戶點擊“不同意” uni.exitApp();同時在 manifest.json 的 App 隱私政策配置中把“隱私彈窗的按鈕點擊事件”對應(yīng)起來。安卓環(huán)境下uni.exitApp()會直接退出應(yīng)用但這只是一個兜底方案更合理的做法是把用戶導(dǎo)回系統(tǒng)設(shè)置或停在協(xié)議彈窗前引導(dǎo)用戶重新確認。5.4 圖表渲染白屏和軟鍵盤問題圖表白屏問題我在 2.4 節(jié)提到過這里再補充一個案例。項目里有一個頁面數(shù)據(jù)量很大一次性把 90 天的訓(xùn)練數(shù)據(jù)全部塞進折線圖結(jié)果在小程序工具里顯示正常真機上白屏。排查后發(fā)現(xiàn)是 canvas 渲染數(shù)據(jù)量太大導(dǎo)致性能瓶頸。解決方案是前端對數(shù)據(jù)做了降采樣只展示最近 30 天的趨勢點并在數(shù)據(jù)加載完成后延遲渲染圖表穩(wěn)定復(fù)現(xiàn)的問題徹底消失。軟鍵盤遮擋的問題很多頁面都會遇到除了我之前說的監(jiān)聽鍵盤高度方法還可以在輸入框聚焦時用uni.pageScrollTo({ scrollTop: 當(dāng)前位置 200 })把頁面頂上去。兩種方案配合使用效果最好。5.5 藍牙連接不穩(wěn)的排查思路藍牙模塊在安卓手機上的兼容性差異特別大。我遇到過一個問題某些國產(chǎn)手機上連上后頻繁斷連后來發(fā)現(xiàn)是因為沒有處理好藍牙回調(diào)的上下文導(dǎo)致內(nèi)存中被創(chuàng)建了多個藍牙連接實例。解決方案是在連接新設(shè)備之前先斷開已有的連接并清理監(jiān)聽器uni.closeBLEConnection({ deviceId: this.oldDeviceId, success() { uni.offBLECharacteristicValueChange(); } });另外藍牙連接過程中要避免在短時間內(nèi)執(zhí)行過于頻繁的掃描和停止掃描操作掃描一段時間后主動停止連接成功后再次掃描會干擾通信實際開發(fā)中要設(shè)計好狀態(tài)機把“掃描中、已連接、數(shù)據(jù)傳輸中、斷開重連”這些狀態(tài)分開管理。6. 從開發(fā)到上線打包與部署經(jīng)驗6.1 uniapp 多端打包發(fā)布流程uniapp 打包 App 有兩種方式云打包和本地打包。云打包是最快捷的方式直接在 HBuilderX 里選擇“發(fā)行 - 原生App-云打包”不需要本地搭建安卓開發(fā)環(huán)境DCloud 云端會完成打包。我推薦初期用云打包重點是它不需要額外配置本地環(huán)境而且可以給多個平臺簽名。但云打包之前必須把 manifest.json 里的配置全部完善好應(yīng)用圖標(biāo)、啟動圖、App 名稱、版本號、包名、證書別名和密碼。安卓證書可以通過 keytool 命令行生成或者在 HBuilderX 的云打包界面直接生成證書這兩種方式我都試過云打包界面生成證書更簡單直觀keytool -genkey -alias your-alias -keyalg RSA -keystore your-key.keystore -validity 36500生成后妥善保存證書文件和密碼以后每次更新版本都需要使用同一個證書簽名否則會出現(xiàn)“應(yīng)用未安裝”或“更新包無法覆蓋安裝”的問題。小程序端則相對簡單在 HBuilderX 里“發(fā)行 - 小程序-微信”生成dist/build/mp-weixin目錄再用微信開發(fā)者工具導(dǎo)入并上傳代碼到微信公眾平臺提交審核。6.2 springboot 后端部署實踐后端部署我選擇用 Docker 容器化部署把 springboot 應(yīng)用打包成鏡像配合 MySQL 容器一起部署到一臺 2 核 4G 的云服務(wù)器上成本低、部署快、回滾方便。Dockerfile 寫得很簡單FROM openjdk:8-jre-alpine VOLUME /tmp ADD target/training-system.jar app.jar ENV TZAsia/Shanghai ENTRYPOINT [java,-Djava.security.egdfile:/dev/./urandom,-jar,/app.jar]啟動時通過環(huán)境變量注入數(shù)據(jù)庫連接和 Jasypt 鹽值docker run -d \ -p 8080:8080 \ -e DB_HOST192.168.1.100 \ -e DB_USERroot \ -e DB_PASSWORDxxx \ -e JASYPT_PASSWORDyour-salt \ --name training-system \ training-system:1.0.0部署中有一個經(jīng)驗想提醒大家就是數(shù)據(jù)庫連接和 redis 配置一定要通過環(huán)境變量注入不要寫在 yml 里。這樣不同環(huán)境開發(fā)、測試、生產(chǎn)只需要維護一份鏡像通過環(huán)境變量區(qū)分配置運維成本大幅降低也能避免敏感信息泄露。6.3 上線后的一些性能優(yōu)化項目上線后的第一周隨著運動員用戶量增加我明顯感覺到兩個接口變慢了一個是首頁的訓(xùn)練計劃列表還有一個是綜合分析里的趨勢數(shù)據(jù)接口。排查中發(fā)現(xiàn)兩個問題數(shù)據(jù)庫層面訓(xùn)練記錄表的數(shù)據(jù)量增長很快但是關(guān)聯(lián)查詢沒有走索引導(dǎo)致慢查詢。解決方案是在外鍵字段上補充索引比如athlete_id和plan_id上創(chuàng)建聯(lián)合索引ALTER TABLE training_record ADD INDEX idx_athlete_plan (athlete_id, plan_id);同時把 trend 查詢的 SQL 改寫避免在循環(huán)里逐條查詢數(shù)據(jù)庫。一次性查出需要的數(shù)據(jù)在 Service 層做內(nèi)存中的聚合把數(shù)據(jù)庫連接往返次數(shù)從幾十次降到兩次。第二個問題是前端頻繁點擊查詢時圖表接口被重復(fù)調(diào)用。在 App 端我加了一層簡單的防抖邏輯在頁面卸載時取消未完成的請求關(guān)鍵是使用uni.request返回的 RequestTask 對象調(diào)用它的abort()方法即可取消這一招立刻降低了后端一半以上的無效請求量。7. 寫在最后的一些心得整個項目從立項到上線大概花了四個月的時間其中真正寫代碼的時間不到一半大量時間花在了需求溝通和多端適配的排錯上?；剡^頭來看有幾個經(jīng)驗對我自己特別有價值。第一技術(shù)選型一定要考慮團隊實際情況。uniapp springboot 這個組合不是最炫技的但它是我認為在當(dāng)前業(yè)務(wù)場景下最能平衡開發(fā)效率和運行穩(wěn)定性的方案。前端一套代碼兩端復(fù)用后端生態(tài)成熟有問題網(wǎng)上基本都能找到答案這對一個中小型團隊來說太重要了。第二多端開發(fā)一定要有一套自己的“最佳實踐清單”。哪些 API 在 App 端表現(xiàn)好但在小程序端有坑哪些組件在小程序端需要特殊處理這些踩過的坑如果不記錄下來團隊成員還會重復(fù)踩。我建議每個項目都建一個docs/troubleshooting.md把自己遇到過的典型問題、排查步驟和最終解決方案記錄下來。最后一個小技巧分享給準(zhǔn)備做這種運動訓(xùn)練類應(yīng)用的開發(fā)者一定把數(shù)據(jù)的“質(zhì)量”放在第一位。訓(xùn)練數(shù)據(jù)的準(zhǔn)確性直接決定了分析結(jié)論是否可信所以在前端采集、網(wǎng)絡(luò)傳輸、后端入庫的每個環(huán)節(jié)都要考慮數(shù)據(jù)的校驗和校正。寧可少一條數(shù)據(jù)也不要讓臟數(shù)據(jù)污染你的分析結(jié)果。這個項目后續(xù)是可以繼續(xù)擴展的比如接入更豐富的運動設(shè)備生態(tài)、引入更高級的算法模型來做訓(xùn)練效果預(yù)測也可以在社交互動上做文章讓運動員之間能分享訓(xùn)練成果、互相鼓勵。只要底層的這套“計劃-執(zhí)行-數(shù)據(jù)-分析”的閉環(huán)跑得夠穩(wěn)往上面疊加什么功能都有基礎(chǔ)。