王昊楠 蘇鈺澤 孔欽 葉長青
Abstract: With the improvement of the economics, people pay more attention to the health and exercise. In this condition, Marathon comes into a new stage of rapid growth and expansion. In recent years, Marathons held by governments and local enterprises spring up. With the appearance of this phenomenon, some problems arise. In this case, a set of effective system is urgently required to help people in the Marathon experience the charm of race and reduce the cost of the Marathon sponsors. The auxiliary system for Marathon based on the Android system and Baidu maps is an Android application to achieve this goal.
引言
互聯網技術成為當代中國經濟發展新的經濟增長引擎,為國內各方面的快速進步提供了現實廣闊可能,而互聯網技術與各個領域的深度結合已然成為行業吸納變革與創新的重要決策走向。其中,體育運動App即是依靠寬帶無線接入技術的高速發展、移動終端的全面普及以及多媒介終端的無縫聯動,以自體傳播和大眾傳播為支撐,有效地突破了現實與互聯網虛擬世界的延展罅隙,拓寬了互聯網+體育的表現域[1]。在這種背景之下,近年來頻頻見諸報導的現代馬拉松賽事無疑將面臨一個效益與效果雙重提升的有利契機。眾所皆知,舉辦馬拉松賽事是一項復雜性的工作,復雜性主要體現在3個方面,可闡釋表述如下。
(1)參賽者數量多。管理和組織如此多的人,單純依靠舉辦方招募的志愿者并不能維系有效的管理。這里,僅以2016年北京馬拉松為例,參賽者達到了30 302人,完賽人數為28 957人。如此規模的參賽者,對于舉辦方的管理來說頗具應對難度。
(2)后勤服務問題。馬拉松參賽人員的號碼牌發放、衣物和芯片的存取都需要指派人員進行管理。由于馬拉松賽程長的特點,沿途的醫療救助點、能量補給站和公共盥洗間等,必須形成科學布局,并且保證數量合理且物資充裕。此處還以2016年北京馬拉松為例,馬拉松組委會在起點、沿途(沿馬拉松路線自5 km開始每2.5 km)及終點設立固定醫療點。在2~5 km每間隔1 km,7.5~40 km每間隔2.5 km處設有移動衛生間。
(3)管理人員和賽事成本問題。除了中國著名的國際馬拉松賽事有大量的活動贊助商,民間馬拉松目前都是由政府財政贊助再配合參賽人員的參賽費用勉強支付開銷成本,難以實現盈利,后果就是無法保證舉辦質量,影響力逐漸減小,賽事舉辦難以獲得長期生命力。
綜上可知,針對這項全民皆可參與的大眾運動—馬拉松運動,參與人數幾千到上萬不等,此等數目的參賽者共同比賽,將無法僅僅依靠人力來做到對萬人級別競賽提供及時服務或者應對突發情況。基于此,研發設計一整套的賽事流程管理和輔助系統,對保障賽事正常順利籌辦,應對意外事件具有重要的規范和完善行為實踐的作用。體育賽事的風險管理是指運用科學的手段和方法對賽事的風險進行評估,制定可行的應急預案,采取有效的措施控制、規避賽事運作過程的事故發生風險,盡量減少事故發生后的各種損失。之所以要引入風險管理,是為了降低或減少在舉辦體育賽事過程中可能遇到的各種不確定的致損因素,以期增加舉辦賽事收益的可靠性和穩定性,而并非要增加賽事的運行成本[2]。研發馬拉松賽事管理系統即在可以直接減少其運營成本、提高賽事質量、規范賽事流程的同時,也已然成為該項賽事科技應用方面的基礎必備配置。
目前,國內針對馬拉松的移動應用并不常見,仍有可觀的發展和創新空間。本文擬將從馬拉松賽事輔助系統實現的優點出發,解讀馬拉松輔助系統的具體設計過程,從各個方面探討互聯網為馬拉松運動帶來的改變,以及明晰減少系統管理成本的運作機制,從而實現對參賽者的精細化科學管理,協助參賽者更好地完成比賽。
1研究方法與技術
1.1研究方法
馬拉松賽事輔助系統開發之前,首先對馬拉松賽事的舉辦流程展開詳盡分析,列舉尋出馬拉松賽事的成本來源,以及生成其中涉及到馬拉松賽事的參賽規則、人數統計、賽程規劃、計分標準、后勤保障等諸多方面的組織管理預案。根據統計數據,對研究中管理薄弱的環節和可以削減成本的方面做出可行性分析及需求分析,為下一步設計奠定合理性的堅實基礎。
如前所述,馬拉松賽事輔助系統一方面致力于為馬拉松賽事的參賽者研發配套服務,助益其整場賽事能夠取得最佳成績。在另一方面,系統也能幫助賽事的舉辦方降低組織管理方面的部分成本。基于此,本文客戶端則采用了Android手機端的App,手機端自帶的GPS定位系統將有利于獲取對參賽者的實時定位,而定位系統也是整個馬拉松賽事輔助系統的核心與關鍵。
服務端使用Java語言,基于阿里云服務器搭建Java語言的運行環境和MySQL數據庫。MySQL數據庫重點用于信息的持久化存儲,主要記錄用戶的個人信息和參賽記錄等。
1.2開發環境研究和搭建
馬拉松賽事輔助系統的開發軟件是Android Studio 2.2.3.0,這是一款專用的Android開發工具軟件。Android Studio相對Eclipse代碼提示和搜索功能要更加強大、智能,在代碼重構、調試等方面有出色表現,極大地減少了Android開發的工作量,提高了開發效率。賽事輔助系統基于Android SDK 23(Android 6.0版本)設計研發,頁面調試主要是在模擬器上生成輸出結果,并利用AVD Manager(Android Virtual Manager)進行配置設定。
服務器端采用的是Java設計語言,利用Eclipse軟件來編寫和構建服務器端代碼。數據庫采用的是免費的MySQL數據庫,進行數據的持久化存儲。在前期階段,服務器采用了tomcat,在上線后將采用阿里云服務器的方式來控制操作部署,從而達到真機測試運行的目的。
為了研發得到該系統的部分功能,在開發系統中引用了第三方的包,即:百度的鷹眼Android SDK3.0,可以實現繪制Android手機運動軌跡的功能。
1.3應用技術
在處理過程中,本系統使用了Android開發技術、百度地圖API中百度鷹眼功能的相關技術、MySQL數據庫的應用技術,以及阿里云的云服務器設計等流行的開發工具。
Android是Google公司在2007年推出的基于Linux平臺的手機操作系統。Android的開源性能夠支持面對第三方的修改接口,從而第三方廠商就可以自行定義安卓系統,以更好地適應自己開發的硬件。本系統研究使用的安卓開發框架包含如下3個基本模塊,也就是:頁面展示、邏輯功能和數據存儲。
阿里云的云服務器(Elastic Compute Service,ECS)是一種簡捷高效、處理能力可彈性伸縮的計算服務,幫助快速構建更穩定、安全的應用,提升運維效率,降低 IT 成本,使用戶更專注于核心業務創新。馬拉松賽事輔助系統的服務器端搭建在這個云服務器上,配置可參見阿里云的文檔,不僅清晰、而且直觀。本系統采用了基于Linux系統的各類集成軟件,分別是:JDK 1.6/1.7/1.8、Tomcat 6/Tomcat 7/Tomcat 8、MySQL5.6,是Java多版本環境。
1.4應用系統架構
馬拉松賽事輔助系統的整體設計架構如圖1所示。研究推得,各部分的功能解析可見如下。
(1)客戶端。是Android手機應用,手機端自帶的GPS服務可以準確定位,將定位信息加工后發送給百度鷹眼服務,再經變換流程后將結果信息回傳給手機應用。
(2)服務器端。是建立在阿里云服務器的基礎上,代碼使用Java語言編寫。這一部分主要就是對數據庫的數據進行增、刪、查、改,傳遞數據信息,并未增設復雜的數據處理操作。
(3)數據庫。采用云端數據庫MySQL5.6版本,對于手機應用產生的各種數據來實配系列操作,用于持久化數據存儲。
2系統分析
2.1可行性分析
在開發馬拉松輔助系統前,即要著手啟動該次項目的可行性分析。研究知道,馬拉松輔助系統的設計,是一個初級的原型系統,旨在嘗試解決馬拉松賽事組織和管理上的一些問題,對于舉辦方來說可以降低成本,對于參賽者而言可以更好地激發參賽狀態,創造佳績。基于此,本文將從技術、經濟和操作這3個方面對本次研發系統進行可行性分析,探討馬拉松賽事輔助系統的設計過程能否實現。各要點內容可分述如下。
2.1.1技術可行性
技術可行性方面,由于賽事輔助系統的開發用到了新技術及工具,所以在設計研發中始終都要伴隨學習新知識、應用新知識、進而在解決問題中精通新知識的過程,從而使研發得到的最終系統能夠滿足初期設計要求。
2.1.2經濟可行性
經濟可行性上即涉及到是否盈利的問題,馬拉松賽事的舉辦方在某些方面的投入為附加成本,就是對于報名、宣傳、賽事引導等多個方面,均可縮減大量人工成本。經過分析,得出結論:本次研發在經濟上是可行的。
2.1.3操作可行性
操作可行性方面,通過查證馬拉松賽事的比賽規則,其中并未規定馬拉松愛好者禁止攜帶手機參加比賽。換言之,帶手機參加馬拉松比賽是可行的。且日常的手機跑步應用都已經證實:人們已經習慣攜帶手機跑步,甚至部分跑者是伴著手機音樂跑至目標終點的。如上敘述證實了手機運動應用的可行性,而且也證明了馬拉松賽事輔助系統建立在手機端的合理性。
2.2需求分析
至此,在經歷了對馬拉松賽事舉辦流程、參賽進程、比賽過程諸多方面的系統探究研讀后,并且參考了中國參賽人數最多、影響力最大的北京國際馬拉松賽事,這里也將以2016年北京國際馬拉松為例,從3個方面據實推演分析,最終得到了系統研發的總體目標為:實現一個賽事原型系統。參賽者可以借助其在賽前及時關注賽事公告,知曉賽事動態。還可以在比賽中幫助參賽者指引賽事路線,繪制參賽者的軌跡,提送參賽者的完賽情況以及全程記錄。這個系統將輔助馬拉松舉辦方減少在賽程設置引導上的成本,而且由于實時定位的便利更可以及時幫助需要醫療救助的參賽者,減少醫療投入的成本。
在此基礎上,還將實際提出具體功能性目標,可詳述如下。
(1)注冊登錄功能。用戶可以注冊登錄系統,編輯個人信息。
(2)賽事報名功能。用戶可以對賽事進行報名。
(3)賽事查詢功能。用戶可以通過系統查詢賽事的詳細信息和公告。
(4)運動軌跡功能。通過對百度鷹眼的調用可以繪制出參賽人員的運動軌跡。
(5)標記位置功能。可以在地圖上標示出來,注明補給點的地理位置。
(6)運動記錄功能。記錄用戶的運動時間和路程等信息。
2.3系統概要設計
2.3.1系統主要功能
(1)用戶注冊登錄。輸入用戶名和密碼來申請注冊,將這些信息存儲到MySQL數據庫中進行持久保存。用戶在登錄界面輸入用戶名和密碼,驗證通過后登錄成功,跳轉到主頁面。
(2)賽事報名功能。每場賽事在數據庫中都對應一張表,內部包括參賽者的姓名和ID,報名就是將當前用戶存儲到數據庫這張表上。當然用戶也可以取消報名,就是在此表中刪除這一用戶。
(3)賽事查詢功能。用戶點擊賽事查詢系統,系統會將所有的賽事羅列出來,點擊賽事就可以看到詳盡的細節信息。
(4)運動軌跡功能。通過系統對百度鷹眼的調用,每經過一段時間打包傳送一次實時位置,而后依據這些實時位置點描繪出用戶的運動軌跡。
(5)標記位置功能。將特殊用途區域在百度地圖的指定位置用不同的標記展示出來,參賽者可以直接找到補給點、醫療點或者衛生間的位置。
(6)運動記錄功能。利用計時的方式,將運動耗時、路程等全盤記錄下來,再將其保存在MySQL數據庫中。
2.3.2系統的用例圖
研究中,為了生動呈現該系統的設計功能,根據系統的基本需求研發得到反映系統表述功能的用例圖。可得技術應用效果如圖2所示。
2.3.3軟件結構圖
為了整體把握馬拉松賽事輔助系統的結構框架,建立了交互模型,可對手機端各個模塊之間的關系生成一個全景描述。如圖3所示,指出的就是手機Android端的系統模塊之間的交互。
3系統功能設計
本節將基于系統流程設計來依序展開馬拉松賽事輔助系統的具體實現論述。研究可將整個系統分為個人模塊、賽事模塊、定位功能模塊三大部分。可得研究設計過程如下。
3.1主體功能設計
(1)用戶注冊登錄模塊。該模塊的數據流圖,如圖4所示。
(2)賽事報名模塊。該模塊的系統流程圖,如圖5所示。
(3)運動軌跡模塊。模塊的系統流程圖,如圖6所示。
(4)分組模塊。模塊流程如圖7所示。
(5)標記位置模塊。模塊的設計流程如圖8所示。
(6)運動記錄模塊
① 運動記錄模塊的層次圖,如圖9所示。
② 運動記錄模塊的流程圖,如圖10所示。
運動記錄模塊是手機App、百度云服務和服務器端交互的重要單元構成。手機通過調用百度云服務實現對運動點偏移量和路程的計算。通過對手機端的定位點進行存儲,而后調用百度云服務精準記錄用戶運動軌跡。服務器端的主要功能就是存儲手機端產生的定位點、時間、路程等信息數據。
3.2系統界面設計
考慮到本系統的界面設計將遵循簡單、易維護原則,研究中采用了Fragment技術,可以使activity分離成多個可重用的組件,從而便捷創建動態、靈活的UI設計,且每個組件均有其專屬的生命周期和UI,這樣就可極大節省工作量。另外,Fragment的實現機制是可以在activity運行中得到動態移除、加入、交換等。相比Activity間的切換不流暢,Fragment具有輕量切換的優點。這些優點對馬拉松賽事輔助系統的Android 頁面開發非常有益。
Fragment雖然有自己的生命周期,但卻不能獨立存在,而是必須嵌入到activity中,并且Fragment的生命周期將直接受到托載的activity的影響。此種關系示意即如圖11所示。
利用Fragment設計的頁面,最終的運行效果可如圖12所示。
3.3系統核心功能詳細設計
研究中,利用了百度鷹眼官方文檔,可得設計詳情如下。
(1)百度鷹眼Android SDK。實時查詢entity最新位置、高度、速度、方向和相關屬性信息。設計提供了2種查詢方法,功能表述可見如下。
① queryEntityList()。該方法用于查詢服務端上存儲的最新實時數據。若終端處于斷網狀態,或有大量緩存數據并未上傳,則查詢結果將是目前服務端接收到的最新數據,可能并不是終端真實的最新位置。
② queryRealtimeLoc()。該方法用于單獨發起一次即時定位,返回為當前終端所在位置。類似定位SDK的使用方法,與軌跡采集上傳完全獨立,互不關聯。
(2)坐標系的說明。輸出參數坐標系均為百度經緯度坐標系(bd09ll)。
(3)查詢服務端最新數據。queryEntityList()支持通過entity_name列表和可檢索的屬性字段2種條件查詢。可對其重點闡析如下。
① 通過entity_name查詢。調用queryEntityList()接口時,在entityNames參數中指定查詢的entity_name列表,則會返回這些entity最后更新的位置。
② 通過可檢索的entity屬性字段查詢。使用Web服務API的entity/addcolumn方法,可以自定義entity的屬性字段,并設置為可精確搜索字段。之后調用queryEntityList()時,支持通過該自定義屬性字段,進行精確篩選。例如開發者創建了team和city這2個可檢索的自定義屬性字段,需要查詢team=2且city=Beijing的entity。
從數據上傳到鷹眼服務端,再到利用查詢接口查詢到該數據,在聯網正常的情況下延時在毫秒級別,可認為是無延時地同步。在上傳時,受打包周期的限制,會存在一個打包周期的延遲。若開發者對實時性要求較高,可以將打包周期設置成采集周期,但需斟酌評測流量方面的消耗。
(4)即時定位queryRealtimeLoc()。調用queryRealtimeLoc()接口,若gps已定位,則SDK會返回已轉換為百度經、緯度的GPS坐標信息;若gps未定位,SDK會采集定位依據(WiFi、基站)上傳到定位服務器,并返回定位結果。
4結束語
馬拉松賽事輔助系統就是基于移動互聯網技術解決一些馬拉松賽事的現存問題,進而減少舉辦方組織和管理的成本,實現馬拉松賽事的科學管理。與此同時,通過這個系統,參賽者可以充分地發揮水平、完成比賽。馬拉松賽事輔助系統是移動互聯網科技與現代體育競技運動的一次嘗試性融合,對未來其它競技體育項目的科學管理有著深遠的借鑒意義。本文研發的馬拉松賽事輔助系統的創新性主要表現在如下3個方面。
首先,在系統理念上,馬拉松賽事輔助系統,立足于馬拉松這一極富挑戰性的體育運動,融合了現今的互聯網新技術,試圖構建一套更加科學、高效的個人馬拉松運動服務完備系統。與傳統的運動App相比,有本質區別和獨特的優勢。內容闡述如下。
(1)服務的對象。馬拉松賽事輔助系統,核心在于賽事,以賽事為中心,圍繞如何使用戶更好地參與比賽,樂享比賽。這一核心理念控制并決定了提供的系統服務要與賽事的各個環節相契合,必須具有鮮明的實用性,否則將無法為參賽者提供強力保障。
(2)在執行功能方面,馬拉松賽事輔助系統除了具有賽事方面的特有功能,同時對傳統的運動App的功能也做到了兼而有之。對于傳統運動App的個人運動記錄或者運動軌跡服務等功能進行了保留和完善,滿足用戶多方面的功能需求。
(3)馬拉松賽事系統的可擴展性遠超傳統的App,目前的馬拉松賽事尚未臻至高效的互聯網化,功能挖掘和發展均有無限空間。也就是說,馬拉松賽事輔助系統前瞻性的研發潛能堪稱巨大。
其次,在新技術方面,馬拉松賽事輔助系統是基于Android平臺開發的,服務器端建立在百度云服務和阿里云服務器上,除了運用Android和Java的開發技術和方法,創新地運用了2種目前流行的新技術。一是百度地圖提供的開放應用程序接口。二是阿里云服務器技術。馬拉松賽事輔助系統為了實現真機測試運行,租用了阿里云的服務器,降低了物理服務器的復雜管理,摒棄了服務器可能產生的風險和隱患。總之,阿里云服務器極大簡便了開發過程,降低了成本。
最后,在系統的設計方面,遵循了軟件開發流程的設計范本,從可行性分析、到需求分析、系統設計等,嚴格執行、且保證了系統開發的效率和可靠性。在設計方面,完全濾除了傳統運動App的社交功能,專注于賽事服務。值得推介的一點,是利用百度地圖的自帶服務,創新性地推出道路指引功能設計,為參賽者配備添加了準確的指路功能。這一設計創新是整個馬拉松賽事輔助系統與其它系統相比所特有的功能,今后對這一功能可設計更多的交互方式,完善其操作過程,進而全面提升交互體驗。
參考文獻
[1] 蔡衛清. 體育運動APP對全民健身活動的影響研究[J]. 青海師范大學學報(自然科學版),2016(4):84-89.
[2] 王小群. 風險管理[M]. 上海:上海財經大學出版社,2003.
[3] 中國田徑協會. 中國田徑協會全國馬拉松及相關運動注冊賽事日歷[Z]. 北京:中國田徑協會,2016.
[4] 李雪,馮曉麗,王琰. 路跑熱潮下跑步類APP 應用現狀與發展困境研究[J]. 遼寧體育科技,2016,38(3):125-128.
[5] 胡靜. 淺析黑盒測試與白盒測試[J]. 衡水學院學報,2008,10(1):30-32.