基于Android移動醫(yī)療監(jiān)護的設(shè)計與研究

1、基于 Android 移動醫(yī)療監(jiān)護的設(shè)計與研究摘 要 基于自主研發(fā)的健康監(jiān)護儀設(shè)備，研究如何 在手機端利用有限的計算資源，實現(xiàn)實時接收監(jiān)護儀設(shè)備上 傳的檢測數(shù)據(jù)，并且快速、高效地并發(fā)處理、展示及存儲手 機端接收的檢測數(shù)據(jù)，從而為疾病早發(fā)現(xiàn)早治療提供數(shù)據(jù)支 持。最終，利用自定義的 SurfaceView,結(jié)合多線程以及緩存 隊列技術(shù)，很好地解決了實時監(jiān)護數(shù)據(jù)的接收、處理及展示 這一關(guān)鍵問題。關(guān)鍵詞 雙緩沖；多線程；緩沖隊列doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2016. 11. 108中圖分類號 TN919.8 文獻標(biāo)識碼 A 文章編號 1673

2、- 0194（2016）11- 0181- 030 引言隨著生活水平的提高，以及人口老齡化趨勢的日益顯著， 人們愈加關(guān)注家庭健康問題。加之手機智能化的發(fā)展，移動 智能手機已成為人們生活必需品，同時也改變著醫(yī)療保健產(chǎn) 業(yè)的發(fā)展方向。移動醫(yī)療、智能醫(yī)療、遠程醫(yī)療成為醫(yī)療領(lǐng) 域發(fā)展的新熱點?；谒壵n題“家庭式健康監(jiān)護儀” ，本文主要研究智 能手機終端與家庭式健康監(jiān)護儀之間多種生理參數(shù)監(jiān)護數(shù) 據(jù)的實時交互及展示。手機終端在接收到這些數(shù)據(jù)后，經(jīng)過 報文解析處理，在界面上實時顯示健康監(jiān)護數(shù)據(jù)并進行持久 化存儲。然而，手機的處理性能有限，如何實現(xiàn)實時接收、 處理并展示監(jiān)護數(shù)據(jù)，是本課題研究的關(guān)鍵，也是本課

3、題研 究的重點與難點。1 背景通過研究發(fā)現(xiàn)，目前市場上結(jié)合 Android 平臺及便攜監(jiān) 護儀的移動家庭式監(jiān)護產(chǎn)品尚處于起步階段1 ，僅有國內(nèi)邁瑞已研制出一款名為邁瑞 UBICARE（優(yōu)必康）H900的生理參 數(shù)監(jiān)測儀 / 健康一體機。 該設(shè)備具備基本的家用監(jiān)護功能， 但 還處于初期研發(fā)階段，存在不足。因降低成本，監(jiān)護儀測量數(shù)據(jù)過于簡略，如心電數(shù)據(jù)標(biāo) 明三導(dǎo)聯(lián)波形，實際只有II導(dǎo)聯(lián)一道波形；無呼吸波（RESP、 血氧描記波（PLEH的檢測功能；僅可將單次測量的一導(dǎo)聯(lián) 10 s心電波形上傳至手機端作為歷史波形靜態(tài)展示與查看； 不支持測量數(shù)據(jù)的實時交互傳輸。總而言之，該款設(shè)備定位于家用，而且配套的

4、手機端應(yīng) 用功能也很弱，只能作為記錄單次測量結(jié)果的工具。在課題研究中，自己研制了家庭式便攜型監(jiān)護設(shè)備，該 設(shè)備集成電源管理模塊和藍牙 4.0 模塊。通過最新的低功耗 藍牙 4.0 協(xié)議，監(jiān)護設(shè)備與手機終端可實時交互監(jiān)護數(shù)據(jù)、 控制命令以及告警信息。設(shè)備設(shè)計如圖 1 所示。大多數(shù)智能手機的處理資源和存儲資源相對于PC機器是相當(dāng)有限的，而醫(yī)療板卡對外傳輸?shù)某掷m(xù)性監(jiān)護數(shù)據(jù)量很 大，本文所采用的醫(yī)療板卡發(fā)送各主要數(shù)據(jù)包的頻率，如表 1 所示。表 1 所示，僅心電波形數(shù)據(jù)，每秒鐘就會向外發(fā)出 250 個數(shù)值點，即使在非實際監(jiān)護狀態(tài)下，醫(yī)療板卡也會通過藍 牙向手機發(fā)送數(shù)據(jù)，只是此時的數(shù)據(jù)相當(dāng)于當(dāng)前心電測量

5、參 數(shù)的零值。2 應(yīng)用總體設(shè)計本文研究的移動監(jiān)護 APP軟件，主要包括以下模塊。人機交互處理模塊：負責(zé)實時處理并動態(tài)描繪接收的監(jiān) 護波形數(shù)據(jù)以及其他數(shù)值型健康數(shù)據(jù)，提供友好的人機界面， 接收界面操作指令并向用戶反饋處理結(jié)果信息。健康數(shù)據(jù)接收處理模塊：本模塊通過手機端的藍牙 4.0 協(xié)議接口，與監(jiān)護設(shè)備建立數(shù)據(jù)連接，交互指令數(shù)據(jù)以及監(jiān) 護數(shù)據(jù)，并進行報文的解析與封裝。數(shù)據(jù)存儲訪問處理模塊：該模塊基于 Android 的 Sqlite 數(shù)據(jù)庫，為其他模塊提供監(jiān)護數(shù)據(jù)增刪改查的持久化操作接 口。數(shù)據(jù)通信模塊：此模塊提供對外網(wǎng)絡(luò)交互接口，彌補健 康監(jiān)護儀的傳輸能力不足通過移動互聯(lián)網(wǎng)與外部健康系統(tǒng) 平臺

6、進行監(jiān)護數(shù)據(jù)、個人信息等信息的交互。其中，人機交互處理以及健康數(shù)據(jù)接收處理，是應(yīng)用的 核心部分， 也是影響整個應(yīng)用性能以及魯棒性的關(guān)鍵， 因而， 這兩個模塊是本文著重研究與討論的重點。3 緩沖機制針對上節(jié)實際需求，本文借助 Android SurfaceView 雙緩 沖機制 2 ，采用多線程結(jié)合阻塞隊列的生產(chǎn)者消費者模式， 很好解決了人機交互以及實時健康數(shù)據(jù)的并發(fā)處理問題。數(shù)據(jù)交互過程中，因設(shè)計或網(wǎng)絡(luò)影響，數(shù)據(jù)發(fā)送速率與 接收速率并不總是能夠保證一致的。尤其當(dāng)發(fā)送速率高于接 收速率時，可能會出現(xiàn)數(shù)據(jù)丟失的情況。3.1 雙緩沖機制Android 提供了兩種基本畫圖對象： View 和 Surf

7、aceView 組件。View與SurfaceView在動態(tài)作圖差異上的對比如下 3:View 沒有雙緩沖機制，難于保存之前繪制的內(nèi)容；當(dāng)View 組件上圖形狀態(tài)數(shù)據(jù)發(fā)生變化，需要更新 View 組件上 的圖像時，必須重繪整個 View 組件，如果數(shù)據(jù)量大，耗時 較長;View的繪圖必須在當(dāng)前的 UI線程中進行，在更新View 組件時需要借助使用 Android Handler 機制來處理。 因而， 在 繪制數(shù)據(jù)量大情況下，使用 View 很可能會阻塞 UI 線程，導(dǎo) 致手機應(yīng)用出現(xiàn)操作卡頓。對比后可知， View 組件適合于圖形數(shù)據(jù)量小， 狀態(tài)數(shù)據(jù)變化較少，無需記錄上次數(shù)據(jù)的整體視圖繪制情形

8、，但不適 合實時動態(tài)畫圖及頻繁局部圖形更新的使用場景。相比較 View 組件， SurfaceView 啟動新的線程，采用 SurfaceHolder 更新 SurfaceView 的組件繪制，而且通過獲取 SurfaceView上指定區(qū)域的 Canvas,只對指定的圖像區(qū)域部分 進行數(shù)據(jù)更新，降低了性能消耗，提高了畫面的更新速度， 因而動態(tài)效果比自定義的 View 組件更加出色。3.2 雙緩沖與多線程在使用 SurfaceView 繪制波形時,由于 SurfaceView 是通 過鎖定Canvas的方式來畫圖，因此需要耗費時間， 不能保證 動態(tài)畫圖的流暢,特別是在數(shù)據(jù)量大的情況下,這種問題尤

9、 其明顯。解決方法是采用多線程的方式,通過建立單獨的子 線程，在子線程中使用 SurfaceView來繪制波形。當(dāng)手機端計算處理過于頻繁時,會嚴(yán)重消耗處理資源,降低手 機應(yīng)用的用戶體驗。在實際過程中,為了保證動態(tài)實時效果 且又能夠減少手機CPU處理負擔(dān)，本文在繪制動態(tài)波形數(shù)據(jù) 時對數(shù)據(jù)進行了分段處理。如對于心電波形數(shù)據(jù),每秒產(chǎn)生 250 個點,即 4 ms 產(chǎn)生一個點, 而人動態(tài)視覺效果刷屏為 60 Hz,大約16 ms刷新一次，則感受不到停頓，那么在實際處 理中可以每次描繪 45個波形數(shù)據(jù)點構(gòu)成的分段波形。3.3 多線程與阻塞隊列一方面為了保證數(shù)據(jù)不會因為發(fā)送與處理速率的不同 而丟失,另一方

10、面為了使得數(shù)據(jù)接收順序與處理順序、展示順序始終保持一致，因而，本文利用基于阻塞隊列的生產(chǎn)者 消費者模式，使用多線程來完成數(shù)據(jù)的接收、分發(fā)與處理。 數(shù)據(jù)接收線程在接收到新的數(shù)據(jù)報文后，作為生產(chǎn)者將報文 放入第一級的阻塞隊列中，數(shù)據(jù)處理線程作為報文的消費者， 從隊列中獲取報文并進行解析，同時數(shù)據(jù)處理線程作為下一 級的生產(chǎn)者將解析后的報文分發(fā)到不同的阻塞隊列中。4 結(jié)論 本設(shè)計中對于波形數(shù)據(jù)展示方式，參照傳統(tǒng)監(jiān)護儀器設(shè) 備上的心電波、呼吸波以及血氧描記波的動態(tài)描繪效果，以 小段重繪的方式動態(tài)展示，處理方式如下：(1) 采用FIFO機制，逐步擦除動態(tài)展示波形數(shù)據(jù)中最早的小段波形數(shù)據(jù)，并加入本次最新的小

11、段波形數(shù)據(jù)，以達 到與監(jiān)護儀上的波形顯示相同的效果。( 2)針對繪圖數(shù)據(jù)量大的特點，應(yīng)用接收線程在累計 接收處理 5個波形數(shù)據(jù)點后，交由繪圖線程一次性繪制5 個點的小段波形，逐段覆蓋更新。(3)控制canvas,避免圖像局部變化過于頻繁。以心電 II 導(dǎo)聯(lián)波形為例，基于本文的技術(shù)研究，最終在 手機上實現(xiàn)了預(yù)期的處理及繪制效果，并可以流暢地切換顯 示測量的7導(dǎo)聯(lián)心電波形(ECG、呼吸波形(RESP以及血 氧波形(PLETH等波形數(shù)據(jù)。本設(shè)計中的手機監(jiān)護應(yīng)用 App 完整實現(xiàn)效果圖，如圖 2 所示。5 結(jié)語本文采用自定義的雙緩沖機制 SurfaceView 控件進行動 態(tài)監(jiān)護波形描繪，相比于 View 控件，在動態(tài)波形圖繪制上 性能更加優(yōu)越，并且大大降低了處理資源需求。同時，利用 多線程和阻塞隊列技術(shù)，很好的解決了實際應(yīng)用中監(jiān)護數(shù)據(jù) 量過大以及傳輸處理速率不對等的問題，從而實現(xiàn)利用手機 上有限的計算資源實時接收、處理并動態(tài)展示監(jiān)護的各項生 理參數(shù)數(shù)據(jù)，并且在已接入健康數(shù)據(jù)平臺的情況下，可以支 持將接收處理的監(jiān)護數(shù)據(jù)通過移動互聯(lián)網(wǎng)實時上傳