駱 超，靳 晟，張?zhí)t

(新疆農(nóng)業(yè)大學 計算機與信息工程學院，新疆 烏魯木齊 830052)

0 引 言

隨著國民經(jīng)濟的提高，人們對精神食糧的追求也越來越高，娛樂的方式也變得多種多樣。騎馬這種有趣的娛樂項目，也漸漸進入了大家的眼簾[1]。但僅僅是將馬用于騎乘游玩，很難帶動馬產(chǎn)業(yè)的發(fā)展，因為它的經(jīng)濟效益是有限的。通過借鑒其他發(fā)達國家或地區(qū)的經(jīng)驗，可以觀察到，賽馬運動的發(fā)展是帶動馬產(chǎn)業(yè)發(fā)展的關鍵[2-3]。發(fā)達的賽馬賽事產(chǎn)業(yè)不僅能夠帶動馬產(chǎn)業(yè)的發(fā)展，同時能夠帶來巨大的經(jīng)濟效益。新疆作為國內(nèi)傳統(tǒng)的馬產(chǎn)業(yè)大區(qū)，馬匹數(shù)量居全國首位，而且正值新疆著力打造馬產(chǎn)業(yè)，促使新疆的馬產(chǎn)業(yè)由傳統(tǒng)的繁育、騎乘、肉食領域向文化旅游、競技賽事等領域邁進[4-5]?？傮w來說，新疆的馬產(chǎn)業(yè)具備較為完整的產(chǎn)業(yè)鏈，發(fā)展賽馬產(chǎn)業(yè)具備良好的基礎。借此機遇與基礎，探索如何通過信息化手段對新疆的賽馬賽事的發(fā)展提供幫助，并提升整個新疆賽馬賽事的信息化水平，是文中研究的主要目的。針對目前移動網(wǎng)絡用戶數(shù)量的不斷攀升，將重點放在對于手機信息化應用的開發(fā)上，研究開發(fā)具備什么樣功能的應用能使信息化的作用發(fā)揮更大[6]。通過觀察發(fā)現(xiàn)，應用市場上已有的賽馬賽事應用主要分兩類：一類是主要用于馬彩的應用，第二類是關注于賽事信息發(fā)布的應用。就賽馬賽事在中國的發(fā)展狀況，現(xiàn)有的應用模式借鑒性不大。

對處于發(fā)展初期的賽馬賽事，首要任務就是吸引人們的關注，設計的應用就需要對用戶有吸引的作用，只有吸引了用戶，才能更好地傳授賽馬知識或信息給用戶。關于怎樣吸引更多人關注，通過對時下最流行的朋友圈、短視頻及直播等信息技術化手段的借鑒，研究如何將這些最新的信息技術糅合到應用中，從而更好地將賽馬賽事傳達到用戶方[7]。之后再探索通過如賽馬競猜及馬特產(chǎn)商城等功能來鞏固用戶群。

1 總體設計

1.1 功能設計

通過分析現(xiàn)有賽馬賽事的發(fā)展，總結規(guī)律，得出功能性需求并列出功能結構，如圖1所示。

由圖1可以看出，這款賽馬賽事應用所具備的功能涵蓋很多內(nèi)容，如賽馬文化傳播、互動、購票以及競猜等等。這種設計能夠迎合賽馬賽事發(fā)展的初期，借助最新的娛樂手段來傳播賽馬文化，通過應用的裝載，可以通過賽事信息發(fā)布傳播最新的賽馬信息，給用戶傳播正確的賽馬文化；通過競猜模塊吸引用戶參與到賽馬比賽中來，并且還可以出售馬產(chǎn)品；而票務與賽事招募，對于賽事組織、管理模塊都會有很好的幫助。

1.2 軟件架構設計

通過功能結構設計，可以發(fā)現(xiàn)整個應用的功能比較多，而且很多功能都不能僅僅依托于本地來實現(xiàn)。以登陸、注冊功能為例，如果注冊的時候將用戶的信息存儲在本地，那在同一臺設備上登陸是沒有問題的，但是當換一臺設備以后，那就無法登陸了。因為這個用戶的信息不在這臺手機上，所以無法登陸。幾乎應用的所有功能都會涉及這個問題，將信息保存到本地，換臺手機便無法獲取相同內(nèi)容。因此需要將數(shù)據(jù)存儲在云端數(shù)據(jù)庫，這樣只要有網(wǎng)絡，不管在哪里都能獲取到相同的信息[8]。解決了數(shù)據(jù)存儲的問題，現(xiàn)在的問題就是數(shù)據(jù)管理以及數(shù)據(jù)交互了。現(xiàn)在需要一臺服務器，這臺機器上面運行著寫好的程序，通過這個程序可以操作與管理數(shù)據(jù)庫，并且按照某種邏輯來設計接口，并提供給手機應用使用。整個軟件的架構就出來了，手機通過網(wǎng)絡與云端服務器中部署的程序建立聯(lián)系，通過云端程序來操作云端數(shù)據(jù)庫(見圖2)。

圖2 軟件架構

1.3 技術選擇

1.3.1 應用開發(fā)

因為開發(fā)的是Android應用程序，所以首選谷歌公司推薦的編程語言進行開發(fā)，如Java或Kotlin。相較于Kotlin，Java的受眾更多，相關教程也會更多，所以開發(fā)語言選擇Java[9]。開發(fā)工具也用谷歌公司推薦的Android Studio工具。

1.3.2 服務器端程序的開發(fā)

服務器端開發(fā)技術選擇較多，但是大多數(shù)技術學習難度大，或者技術維護上做的不是特別好。通過參考資料也可以發(fā)現(xiàn)，Python語言的使用量在不斷增長，可見Python因為它的易用性以及實用性，越來越受到歡迎。所以根據(jù)以往經(jīng)驗和排名，選擇基于Python的Django框架進行開發(fā)。

1.3.3 數(shù)據(jù)庫開發(fā)

對于數(shù)據(jù)庫，主要結合免費、滿足需求以及使用排名來進行選擇，選擇MySQL作為云端數(shù)據(jù)庫。

2 關鍵技術

2.1 OkHttp

OkHttp是一個處理網(wǎng)絡請求的開源項目,是安卓端較為火熱的輕量級框架,由移動支付Square公司貢獻。通過這個框架，可以輕松完成Http的請求及響應。

2.2 Json

Json(JavaScript object notation)是一種輕量級的數(shù)據(jù)交換格式。簡潔和清晰的層次結構使得Json成為理想的數(shù)據(jù)交換語言，其易于閱讀和編寫，同時也易于機器解析和生成，并能有效提升網(wǎng)絡傳輸效率。在網(wǎng)絡傳輸中將主要傳遞Json格式的數(shù)據(jù)。

2.3 多線程、異步

多線程是指從軟件或者硬件上實現(xiàn)多個線程并發(fā)(同步)執(zhí)行的技術。具有多線程能力的計算機因有硬件支持而能夠在同一時間執(zhí)行多于一個線程，進而提升整體處理性能。

異步可以理解為計算機多線程的異步處理。與同步處理相對，異步處理不用阻塞當前線程來等待處理完成，而是允許后續(xù)操作，直至其他線程將處理完成，并回調(diào)通知此線程。通過多線程和異步技術，可以提升應用的用戶體驗。

3 軟件架構實現(xiàn)

3.1 數(shù)據(jù)庫端的實現(xiàn)

在開始數(shù)據(jù)庫實現(xiàn)之前需要做兩方面工作，首先確定怎樣創(chuàng)建數(shù)據(jù)庫中的表，其次就是設計應用邏輯，將邏輯轉換成數(shù)據(jù)庫中的表。創(chuàng)建數(shù)據(jù)庫有多種方式，傳統(tǒng)方式通過Sql語句進行數(shù)據(jù)庫的創(chuàng)建，或者通過可視化數(shù)據(jù)庫管理工具(如Navicat)進行可視化創(chuàng)建。如同創(chuàng)建Excel數(shù)據(jù)表一般，相較于通過Sql語句進行創(chuàng)建，通過工具創(chuàng)建會方便很多。因為服務器端的實現(xiàn)采用的是Django框架，而該框架提供了ORM(對象關系映射)工具,通過ORM工具不僅可以輕松地創(chuàng)建數(shù)據(jù)庫，還可以在不寫一句Sql語句的情況下對數(shù)據(jù)庫進行操作。

在真實創(chuàng)建表的時候，ORM工具會把每個表用類的形式來表示。如下面的代碼，創(chuàng)建了Common TimeInfo、EveryDaySign這兩個類，要實現(xiàn)的是每日打卡獲取馬券的功能，按規(guī)定打卡只能一天打一次。所以創(chuàng)建的表需要包含用戶標識以及日期，其中EveryDaySign是用于存放這些信息的表，而CommonTimeInfo類通過在自身的Meta內(nèi)部類中設置abstract=True，就表明它是抽象基類，只能用于被繼承，而不能被用于生成數(shù)據(jù)表。EveryDaySign類繼承了CommonTimeInfo類，同時也會擁有Common TimeInfo類具有的屬性[10]。

class CommonTimeInfo(models.Model):

pub_date=models.DateTimeField(

'發(fā)表時間',

auto_now_add=True,

editable=True)

update_time=models.DateTimeField(

'更新時間',

auto_now=True,

null=True)

actived=models.BooleanField(

default=0,

blank=False,

verbose_name="是否可用")

class Meta:

abstract=True

class EveryDaySign(CommonTimeInfo,models.Model):

user=models.ForeignKey(

User,

verbose_name="關聯(lián)用戶")

signday=models.DateField(

auto_now_add=True,

verbose_name="打卡日期")

通過先后執(zhí)行makemigrations以及migrate命令，就可以將EveryDaySign類轉換為相應的數(shù)據(jù)表，并且繼承CommonTimeInfo類的屬性。在上面的代碼中可以發(fā)現(xiàn)，EveryDaySign中有一個與User類進行關聯(lián)的外鍵，當生成真正的數(shù)據(jù)表時，也能夠體現(xiàn)出來(見圖3)。

圖3 EveryDaySign表結構

通過ORM工具，不用再糾結于創(chuàng)建Sql語句，而是可以專注于實現(xiàn)功能邏輯,只需要將邏輯轉化成一個一個的類并且構建它們之間的關系。其他任務都可以就交給ORM工具處理。

3.2 服務器端的實現(xiàn)

構建應用的系統(tǒng)架構，不僅需要創(chuàng)建數(shù)據(jù)庫和設計應用結構，在數(shù)據(jù)庫與軟件之間建立連接以及承擔起整個系統(tǒng)之間的邏輯關系也是十分重要的。需要提供一個云端服務承擔起這個角色。而應用與服務端之間建立聯(lián)系是需要基于某種協(xié)議的。一般實時性要求較高的會采用TCP或者UDP協(xié)議，還有一些使用面相對廣泛的協(xié)議，如HTTP、FTP、SMTP。由于該系統(tǒng)實時性要求不高，而且Web服務基本上都是基于HTTP協(xié)議的，所以選用支持Http協(xié)議的Django框架來實現(xiàn)服務端程序的開發(fā)。

3.2.1 請求與響應

應用與服務器之間的聯(lián)系是基于請求與響應的，Django基于訪問的路徑來攔截軟件發(fā)起的請求，然后調(diào)用相應的視圖方法來處理相關操作，根據(jù)返回語句決定返回的是何種格式的數(shù)據(jù)(見圖4)。

圖4 請求與響應過程

HTTP協(xié)議常用于響應Html頁面，而一般的手機應用不直接處理Html頁面。軟件需要接受能夠表達完整意義以及易于傳輸、易于處理的格式化文本，如Xml和Json。采用更受歡迎的Json語句來完成響應。

rs={"status":0,"msg":"獲取失?。?}

return JsonResponse(rs)

如上面的代碼，Json語句具備最基本的兩個變量。應用可以判斷每次請求的發(fā)送是否成功，但是并不能確定每次請求邏輯上是否正確，所以需要服務端將結果通過響應返回到軟件，然后應用根據(jù)返回來執(zhí)行相關提示和操作。表1便是服務端響應的不同消息，應用會根據(jù)響應的狀態(tài)來進行判斷。

表1 響應碼說明

3.2.2 權限驗證與裝飾器

服務器端不僅要完成基本的邏輯構建，還要完成復雜的權限鑒定，如實現(xiàn)判斷用戶是否登陸的鑒定等。如果沒有相關鑒定，其他用意不良的人，很容易便可以破壞后臺的數(shù)據(jù)。所以必須要在關鍵操作中檢查權限。但是肯定不能在每一次檢驗的時候，都將相同的檢驗代碼寫一遍，這樣會出現(xiàn)很多重復的代碼。因為Django是基于Python開發(fā)的，所以可以使用Python提供的裝飾器功能來完成檢驗。就以登陸權限鑒定為例，Django提供了登陸檢驗，但是當檢測到用戶沒有登陸，會響應Html頁面，希望返回Json文本，所以不符合要求。可以重寫一個裝飾器。如下面的代碼，寫好一個裝飾器，可以反復使用，而且復用的方式非常簡單，只需在視圖函數(shù)上添加@符號和裝飾器名稱，就能實現(xiàn)對用戶進行登陸鑒定。

def xjhorse_login_required(func):

def _wrapped_view(request,*args,**kwargs):

rs={"status":-1,"msg":"請先登陸賬號！"}

if request.user.is_authenticated:

return func(request,*args,**kwargs)

return JsonResponse(rs)

return _wrapped_view

@xjhorse_login_required

def somerequest(request):

3.2.3 獎金分配表達式

結合現(xiàn)有的新疆本地賽馬規(guī)則，根據(jù)不同的比賽以及單場參賽馬數(shù)的不同，獎金分配規(guī)則也是不同的，所以不能直接把程序寫死，必須在服務器后臺根據(jù)不同的比賽進行填寫。為了方便設置規(guī)則，根據(jù)具體需求，設計出了一套獎金分配表達式，具體如下：

6=50+30+20

15=30+25+20+15+10

這兩個表達式的意思是：當參賽數(shù)量超過6個時，前三名按照50%、30%及20%的比例進行分配；當參賽數(shù)量超過15個時，按照前五名30%、25%、20%、15%及10%的比例進行分配。

服務器端程序首先會通過回車與換行符，將所有表達式分割,然后通過正則表達式對所有的分配表達式進行比對，如下代碼：

re.match(r'^d+=d{1,2}([〗]{1}[d]{1,2})+$','6=50+30+20')

比對通過以后，再對表達式進行拆分，主要有兩項檢驗，分別是分配比例的總和必須等于100，以及分配比例必須是從大到小排列。如果全部檢驗通過，將會把表達式存放在數(shù)據(jù)庫中，供下次計算獎金使用。

3.3 應用端的實現(xiàn)

3.3.1 Csrf問題以及Cookie的保存

應用與服務端之間有許多交互，而這些交互有些是Get請求，有些是Post請求。當應用發(fā)起Post請求的時候，Django會檢驗請求是否包含CSRF(跨站請求偽造)密鑰，如果沒有，Django將拒絕服務。CSRF攻擊是一種常見的網(wǎng)絡攻擊手段。當用戶登陸了某個網(wǎng)站沒有退出會話，現(xiàn)在去訪問另一個網(wǎng)站，而這個用意不良的網(wǎng)站獲取到了相關重要操作的鏈接，并修改了鏈接，誘導用戶去點擊這個鏈接，因為相關會話沒有關閉，所以用戶只要一點擊，很可能就會被攻擊。CSRF密鑰是保存在Cookie中的，必須在執(zhí)行Post請求的時候，將CSRF密鑰添加到請求頭里面或者請求參數(shù)里面，才能起到效果。

因此在服務端添加一個專門響應CSRF密鑰的方法，當軟件啟動時，請求服務端獲取密鑰，然后將密鑰存放到變量中。在進行Post請求時，添加CSRF密鑰，響應便能成功(見圖5)。

現(xiàn)在CSRF的問題解決了，接下來就需要解決會話保存的問題了。服務器一般通過存儲在Cookie里面的Session值來判斷請求方的狀態(tài)[11]。所以一定要保存好Cookie值，并做到及時更新，這樣就能保存應用的會話狀態(tài)了。

圖5 CSRF密鑰處理過程

3.3.2 視頻直播功能

直播是一個重要的手段，可以為養(yǎng)馬或愛馬人士提供一個很好的宣傳窗口，普通用戶可以通過這個窗口近距離地接觸馬匹，一舉兩得。搭建一個基本的直播功能必須具備三個基本的組成部分，那就是一臺RTMP(實時消息傳輸協(xié)議)媒體服務器、一個推流端以及一個拉流端。采用支持RTMP協(xié)議的Srs軟件作為媒體服務器;而推流端分為電腦端和手機端，電腦端直接使用Obs軟件進行推流，手機采用第三方推流應用實現(xiàn)，無需再開發(fā)應用;而拉流端，該軟件直接集成百度拉流Sdk，便可獲取在線直播流。

3.3.3 打卡獲取馬券功能

為了不單單將該應用做成一個傳播平臺，而是將它做成用戶粘性很高的具備娛樂功能的平臺，在應用中集成了競猜功能。為了完成獎勵與懲罰，構建了一套數(shù)字幣的規(guī)則，就是馬券，它不僅可以用于競猜，還可以用于兌換禮品。用戶可以通過打卡來獲取馬券，因此設計了打卡的功能。用戶只要登陸該應用，然后點擊獲取馬券，后臺會判斷用戶當天是否點擊獲取過馬券，獲取馬券的數(shù)量也會隨機分配給用戶，當數(shù)據(jù)庫中已經(jīng)存在用戶當天打卡記錄，軟件將提示用戶已經(jīng)獲取過馬券。

3.3.4 賽事競猜功能

為了調(diào)動用戶參與到賽馬運動中以及傳播賽馬競猜的規(guī)則，通過對現(xiàn)有馬匹競猜規(guī)則的研究，總結與提煉規(guī)則便構建了賽事競猜功能。管理員在服務端添加可以進行競猜的比賽項目，然后對項目添加參賽馬匹和參賽騎手。普通用戶可以通過應用選擇要競猜的項目，然后選擇下注的馬與騎手以及下注馬券數(shù)目。當比賽結果公布時，如果用戶猜中了，系統(tǒng)將返還用戶下注的馬券，并扣除所有輸?shù)舯荣惖挠脩舻鸟R券作為獎勵金，然后按照贏得競猜的用戶下注比例，將獎勵金發(fā)放給獲勝用戶(見圖6)。用戶可以用馬券不斷進行競猜，也可以在該應用的馬特產(chǎn)商城中兌換禮品。馬券不能用于兌換現(xiàn)金，也不能用現(xiàn)金充值。

圖6 競猜流程

3.3.5 馬圈分享功能

當應用具備了初步的娛樂功能，有一定的用戶粘性后，最關鍵的就是怎樣讓用戶接觸賽馬文化，真正喜歡上賽馬。最簡單有效的方式，就是通過時下最流行的方式，如短視頻，所有用戶都可在上面分享他們關于賽馬的視頻或者圖片。將這個功能命名為馬圈，用戶可以發(fā)布視頻和圖片，并且可以配上文字說明，其他用戶也可以進入馬圈，獲取別人發(fā)布的馬圈，然后可以對別人的馬圈進行點贊和評論。

3.3.6 解決內(nèi)存溢出錯誤

應用中包含了大量的列表頁，而每個列表項基本上都會關聯(lián)一張照片，當通過大量子線程去下載圖片的時候，因為有的圖片特別大，而且圖片數(shù)量也多，由于這些圖片數(shù)據(jù)是存儲在內(nèi)存中的，而每個應用所分配的內(nèi)存是有限的，便造成了內(nèi)存溢出現(xiàn)象。為了解決這個問題，軟件使用Picasso第三方開源框架，該框架可以轉換圖片以適應布局大小并減少內(nèi)存占用,并且提供圖片緩存功能，以節(jié)省用戶流量[12]。因此使用該框架既避免了內(nèi)存溢出的問題，又節(jié)省了用戶的手機流量，同時也提高了列表的滑動速度。

3.3.7 版本適配

由于Android系統(tǒng)的版本更新較快，不同手機的系統(tǒng)版本跨度較大，為了讓該應用在更多的手機上應用，需要做好版本適配，讓所有功能都能在不同的Android系統(tǒng)中正確執(zhí)行。主要適配要點如下：

(1)Android5：提供了新的攝像頭接口Camera2,所以使用Camera2接口時，一定要對低版本的系統(tǒng)進行適配。

(2)Android6：新增了運行時權限確認。以往的Android版本要使用某項權限，只需要在Android Manifest.xml文件中添加相關權限就可以了，但是現(xiàn)在如果要調(diào)用某些權限(例如：通訊錄、位置、相機)，還需要在應用運行的時候動態(tài)地申請并被用戶允許才能正常使用。

(3)Android7:禁止直接通過路徑訪問應用私有文件，如某個應用調(diào)用系統(tǒng)自帶相機進行拍照，不進行處理是無法拍照的，因為系統(tǒng)相機應用無法訪問該應用的私有文件路徑，需要通過FileProvider類給相機應用提供一個可以訪問的路徑才行。

通過Build.VERSION.SDK_INT常量，可以獲取當前系統(tǒng)的版本號，應用在需要適配的地方，根據(jù)不同的版本號執(zhí)行不同的程序，就可以實現(xiàn)在不同的版本系統(tǒng)上正常運行[13]。

3.3.8 應用自更新

由于Android系統(tǒng)的開源性，不僅催生了大量的手機廠商使用Android系統(tǒng)，也同樣造成了一個手機廠商一個應用商城，沒有統(tǒng)一的應用商城。為了減少維護成本，應用升級離不開自動更新，只有具備自動更新功能，最新的功能才能更好地傳達到用戶，而且不用被不同的應用商場所束縛。

可以在服務器端創(chuàng)建一個表，結構如表2所示。

表2 版本更新

當應用啟動時，去服務器獲取最新版本信息，并將AndroidManifest.xml中配置的android:versionCode與最新版本進行比對，如果不一致，就提示更新，如果服務器要求強制更新，那用戶只有更新后才能正常使用當前應用[14]。

4 系統(tǒng)運行結果展示

該應用實現(xiàn)的主要功能包括用戶登錄、賽事信息、伯樂識馬、門票購買、賽事競猜、禮品兌換以及馬圈分享等。圖7與圖8給出了該款應用的部分截圖。

圖7 馬品種展示 圖8 競猜項列表

5 結束語

在智能手機飛速發(fā)展的今天，移動設備的便攜性使其可以在某些方面代替?zhèn)鹘y(tǒng)的桌上型計算機，給用戶帶來了極大便利，并且移動設備的用戶量在不斷攀升，用戶量也是開發(fā)移動應用的重要考慮因素。因為在賽馬運動的發(fā)展過程中，離不開越來越多人的關注，只有借助用戶量多的平臺才能吸引更多的人去關注。通過應用的開發(fā)可以將最新的賽馬賽事信息傳遞給用戶，實現(xiàn)賽馬競猜等功能可以讓用戶嘗試與體驗怎么參與到賽馬運動中來，不斷結合時下流行的信息技術在做到傳遞賽馬知識的同時，吸引更多的用戶關注賽馬賽事是該應用設計與開發(fā)的期望結果。