基于Android畫板的同屏傳輸

陳富琴，周淵平

(四川大學 電子信息學院 ，四川 成都 610065)

基于Android畫板的同屏傳輸

陳富琴，周淵平

(四川大學 電子信息學院 ，四川 成都 610065)

在利用電話進行通信時，有時候語言的描述可能并不能很好地表達所傳遞的信息，如果此時雙方能夠及時地開啟一個畫板實時傳輸數(shù)據(jù)，在畫板上手繪圖表等信息來幫助表達意圖，可提高通信的質(zhì)量和效率。基于Android平臺實現(xiàn)了畫板間的實時通信功能，可在不同網(wǎng)絡(luò)情況下實時傳輸畫板數(shù)據(jù)。該畫板是將移動設(shè)備作為手繪輸入板，用戶可以通過手指觸摸屏來實現(xiàn)繪圖等功能。為了確保無論用戶在什么樣的網(wǎng)絡(luò)環(huán)境下都能夠有效通信，文中提供了三個不同的解決方案。重點描述了當通信雙方在不同局域網(wǎng)時，利用UDP打洞傳輸數(shù)據(jù)的通信方式。

畫板；實時傳輸；UDP；網(wǎng)絡(luò)

0 引言

隨著網(wǎng)絡(luò)技術(shù)與移動互聯(lián)網(wǎng)的飛速發(fā)展，智能手機與人們的生活聯(lián)系越來越緊密。如QQ、微信等應(yīng)用軟件都給人們提供了一個與外界交流的方式。本文的畫板傳輸也是基于這樣的理念，讓通信雙方能夠及時地獲取對方的消息。本文的通信模式采用的是端對端的傳輸。Android系統(tǒng)是一種基于Linux的自由及開放源代碼的操作系統(tǒng)，主要應(yīng)用于移動設(shè)備。在此基礎(chǔ)上開發(fā)畫板是非常有市場前景的。由于移動端的移動特性，用戶所處的環(huán)境可能隨時在發(fā)生改變，本文根據(jù)用戶移動端所處的不同網(wǎng)絡(luò)環(huán)境，選擇不同的傳輸方式，保證用戶的最佳體驗。本文提出了三種傳輸方式來保證傳輸質(zhì)量和效率。當處于同一個局域網(wǎng)的用戶進行通信時，采用直接傳輸?shù)姆绞健．斢脩綦p方處在不同局域網(wǎng)時，采用的是UDP打洞的方式。P2P的通信核心就是UDP打洞[1]。在以上兩種方式都不成功的情況下，為了保證通信，采用服務(wù)器中轉(zhuǎn)通信的方式。在TCP和UDP傳輸方式中，由于UDP的傳輸是基于無連接的，傳輸效率更高；UDP程序設(shè)計結(jié)構(gòu)相對簡單，并且對系統(tǒng)的資源要求較少，因此本文選擇了UDP的傳輸方式，同時也更符合本文的設(shè)計意圖。

1 總體框架

1.1 同一個局域網(wǎng)內(nèi)的用戶通信

局域網(wǎng)是指在某一區(qū)域內(nèi)由多臺計算機互聯(lián)組成的計算機組，兩個移動端連接的無線信號很可能處于同一個局域網(wǎng)中，眾所周知處于同一個局域網(wǎng)的兩個主機是可以互相ping通的，在同一個局域網(wǎng)的主機是可以相互通信的。因此如果移動端的兩個IP地址為同一個局域網(wǎng)的私有地址，則可以直接通信，這是最快速高效的通信方式。

1.2 兩用戶處于不同局域網(wǎng)

圖1 UDP打洞流程圖

內(nèi)網(wǎng)主機不能直接用私有地址訪問外網(wǎng)的主機，私有地址是不能夠被路由的。它要與外網(wǎng)通信必須經(jīng)過NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)設(shè)備。NAT功能一般都會被集成到路由器、防火墻等設(shè)備中。當內(nèi)網(wǎng)的私有地址要與外網(wǎng)通信時，NAT就在網(wǎng)關(guān)處將內(nèi)網(wǎng)地址轉(zhuǎn)成公網(wǎng)地址，才能使內(nèi)網(wǎng)地址在外部公網(wǎng)上正常使用。NAT維持了一張表，記錄了內(nèi)網(wǎng)地址出去的公網(wǎng)地址。外網(wǎng)地址傳輸進來的時候根據(jù)這張表進行查找，以找到接收方。這種情況下采用UDP打洞方式進行傳輸，利用了路由的NAT功能[2]。UDP打洞流程圖如下圖1。

1.3 中轉(zhuǎn)通信方式

在以上兩種情況都失敗的情況下，選擇利用中轉(zhuǎn)服務(wù)器來傳輸數(shù)據(jù)。主動請求方直接把傳輸?shù)臄?shù)據(jù)發(fā)送給中轉(zhuǎn)服務(wù)器，中轉(zhuǎn)服務(wù)器再幫忙轉(zhuǎn)發(fā)給被請求方。這種情況下，傳輸效率比較低，傳輸?shù)臄?shù)據(jù)太多時，服務(wù)器承受的壓力較大，一般不會優(yōu)先考慮這種方式。圖2是中轉(zhuǎn)服務(wù)器示意圖。

圖2 服務(wù)器中轉(zhuǎn)圖

1.4 總體通信流程

通過以上三種方式，保證用戶在不同的網(wǎng)絡(luò)情況下，都能夠成功通信。本文總體測試流程圖如圖3。

圖3 總體測試流程圖

2 客戶端

2.1 客戶端總體概述

用戶的客戶端由兩個界面組成，一個是注冊界面MainActivity，一個是畫板界面SecondActivity。注冊界面是用戶用來注冊自己的信息到服務(wù)器和通知服務(wù)器想要通信的另一客戶的信息。電話通信是Android智能手機最基礎(chǔ)最核心的功能，每個移動端都有屬于自己的電話號碼。因此選擇手機號碼作為每一個客戶端的唯一標識。注冊信息時，需要把自己的手機號注冊到服務(wù)器上，只有在服務(wù)器上注冊了信息的用戶才能夠讓其他用戶聯(lián)系到。用戶主動發(fā)起通信時，必須給服務(wù)器發(fā)送請求方的手機號碼。如果雙方同時在線，則進入畫板界面進行數(shù)據(jù)的傳輸。

2.2 注冊界面

注冊界面由兩個文本輸入框和三個按鈕組成，主動請求方和被動連接方都有不同的注冊協(xié)議。

注冊輸入框，輸入本機的電話號碼，點擊注冊按鈕，調(diào)用clientSend函數(shù)將獲取本機號碼、本機的IP(一般是內(nèi)網(wǎng)地址)及本機端口。它們以逗號進行連接，將數(shù)據(jù)封裝好發(fā)送給服務(wù)器。主動方和被動方都有這一步驟。

主動方需要手動輸入聯(lián)系人號碼，點擊好友按鈕，調(diào)用getComm函數(shù)。將被動方的電話號碼與主動方的號碼及主動方的私有地址和端口以逗號的方式連接，發(fā)送給服務(wù)器，并等待服務(wù)器返回被動方的地址信息。地址信息包括被動方的內(nèi)網(wǎng)地址、公網(wǎng)地址及端口號等信息。

主動方從服務(wù)器獲得被動方的地址后，進行以下幾個步驟：

(1)首先向被動方的私有地址直接發(fā)送數(shù)據(jù)包，包括被動方的電話號碼。如果能夠收到被動方返回的連接成功信息，即表明這兩個用戶處于同一個局域網(wǎng)，可以直接通信。執(zhí)行成功后直接跳轉(zhuǎn)傳輸畫板。

(2)如果發(fā)送的數(shù)據(jù)包失敗，則表明兩個用戶處于不同的局域網(wǎng)。即利用返回的被動方的公網(wǎng)地址和端口進行UDP穿透。

(3)如果UDP打洞失敗，再直接將數(shù)據(jù)發(fā)給轉(zhuǎn)發(fā)服務(wù)器，讓它直接將數(shù)據(jù)轉(zhuǎn)發(fā)給被動方。

被動接收方不需要輸入聯(lián)系人的號碼，直接點擊通信按鈕，調(diào)用waitToComm函數(shù)，阻塞等待被連接。當它收到數(shù)據(jù)包時，首先與自己的本機號碼比較，如果一致，則給對方返回連接成功的信息。然后進入畫板，實現(xiàn)通信。

2.3 畫板界面

實現(xiàn)畫板的常用方式有自定義View、繼承SurfaceView，也可通過Canvas類實現(xiàn)。本文采用第一種方式實現(xiàn)同步畫板。定義了一個畫筆，用來繪制線條。繪制的原理是通過重寫onTouchEvent事件，根據(jù)用戶手指的滑動位置的坐標記錄相應(yīng)的路徑。MotionEvent.ACTION_DOWN記錄手指開始繪制的起點，MotionEvent.ACTION_MOVE記錄手指的移動，MotionEvent.ACTION_UP記錄手指繪制的結(jié)束點。通過不斷地刷新整個畫板來重繪畫板。在此基礎(chǔ)上，增加了擦除功能、保存功能、改變畫筆大小、調(diào)整畫筆顏色等輔助功能[3]。

2.3.1發(fā)送方式

在MotionEvent.ACTION_UP設(shè)置了一個監(jiān)聽按鈕，當用戶手指離開觸摸屏代表用戶一條路徑畫完，此時開啟一個發(fā)送線程，將獲得路徑數(shù)據(jù)發(fā)送給通信另一端。

2.3.2接收方式

進入畫板就開啟了一個接收線程，是阻塞式接收，只有接收到了數(shù)據(jù)才能更新界面。接收過程利用了Android的Handler機制。在Android系統(tǒng)中只允許主線程來修改UI組件，SecondActivity界面的更新畫板操作不能直接在子線程完成，必須利用Handler傳輸?shù)街骶€程完成。

3 服務(wù)器端

3.1 服務(wù)器的多任務(wù)處理機制

服務(wù)器創(chuàng)建了一個線程池來限制系統(tǒng)中執(zhí)行的線程數(shù)量。線程池可以減少在創(chuàng)建和銷毀線程上所花的時間以及系統(tǒng)的開銷[4]。利用Executors的工廠方法來創(chuàng)建一個固定線程數(shù)量為50的線程池，即可同時滿足50個線程同時工作，屬于多線程并發(fā)執(zhí)行任務(wù)[5]。當沒有空閑線程的時候，任務(wù)會在阻塞隊列中排隊等待。

阻塞隊列使用的是LinkedBlockingQueu隊列，默認的keepalive時間是0 s。最大線程池的數(shù)量與核心線程池的數(shù)量都是50。當提交新任務(wù)時，首先判斷核心線程池的線程數(shù)量是否已經(jīng)為50，如果小于50，則創(chuàng)建新線程馬上執(zhí)行任務(wù)，否則判斷阻塞隊列是否已滿，如果沒滿，則在阻塞隊列中等待，否則就得按照RejectedExecutionHandler處理，默認的處理方式是直接拋出異常。

3.2 服務(wù)器的存儲

利用ConcurrentHashMap存儲用戶的注冊信息。ConcurrentHashMap采用了分段鎖的設(shè)計，不僅保證了同步操作，同時大大提高了并發(fā)環(huán)境下的處理能力。

ConcurrentHashMaphm

=newConcurrentHashMap();

第一個參數(shù)String存放的是用戶的唯一id手機號碼字符串，String[]數(shù)組存放的是注冊用戶的IP地址和端口。每個用戶都有所在局域網(wǎng)的私有地址和通過NAT的公網(wǎng)地址[6]。將其都存放在數(shù)組中。數(shù)組第一個元素存放的是私有地址和端口，第二個元素存放的是公網(wǎng)地址與端口。

3.3 服務(wù)器的運行

服務(wù)器一直在9999端口監(jiān)聽，接收到數(shù)據(jù)后，就交給線程池中的線程處理。線程處理任務(wù)包括以下幾個步驟：

(1)將服務(wù)器收到的數(shù)據(jù)用逗號分隔成一個字符串數(shù)組。

(2)判斷數(shù)組的大小，如果數(shù)組大小為2，即表明這個用戶是來注冊的，再繼續(xù)判斷第一個位置上的字符串是否為電話號碼，如果是就將號碼存入ConcurrentHashMap，作為鍵，其值為一個數(shù)組。數(shù)組的第一個元素，即用戶的私有地址和端口。第二個元素即為經(jīng)過NAT后的公網(wǎng)地址和端口。

(3)如果數(shù)組的大小為3，即用戶是請求與另一個用戶進行通信。獲取數(shù)組中第一個元素，元素的值是被動方的電話號碼，在ConcurrentHashMap中查詢被動方號碼，如果查詢成功，則將獲取到的被動方的私有地址和公網(wǎng)地址一起發(fā)送給主動方。如果查詢不到號碼，等待10 s后，還是查找不到，則此次查詢失敗。

服務(wù)器運行流程圖如圖4所示。

圖4 服務(wù)器流程圖

4 測試結(jié)果

本次測試的實驗環(huán)境：兩個服務(wù)器程序存放在購買的阿里云服務(wù)器上，阿里云服務(wù)器的公網(wǎng)IP：120.24.211.74，內(nèi)網(wǎng)IP：10.44.97.37。服務(wù)器程序采用Java開發(fā)，因此首先要配置jdk的環(huán)境，再在cmd命令中運行服務(wù)器程序。圖5、圖6分別是服務(wù)器程序啟動的界面和客戶端的注冊界面。

圖5 服務(wù)器啟動界面圖

圖6 客戶端啟動界面圖

(1)同一個局域網(wǎng)的內(nèi)網(wǎng)測試

主動方的內(nèi)網(wǎng)地址：192.168.191.4，端口號為58276，注冊號碼為：18200397836。被動方的內(nèi)網(wǎng)地址為：192.168.3.12，端口號為37299，注冊號碼為：18200394709。在服務(wù)器注冊的情況如下圖7。公網(wǎng)地址和端口是通過DatagramSocket獲取的。圖8是客戶端的請求情況，圖9是雙方通信的結(jié)果。

圖7 服務(wù)器的注冊信息

圖8 客戶端請求信息

圖9 兩客戶端通信信息

(2)外網(wǎng)的UDP打洞情況

主動方的地址變?yōu)椋?0.35.196.240，端口號為51772，注冊號碼為：18200397836。被動方的內(nèi)網(wǎng)地址為：192.168.191.4，端口號為58276，注冊號碼為：18200394709。在服務(wù)器注冊的情況如圖10，通信情況如圖11。

圖10 UDP打洞注冊信息

圖11 UDP打洞通信

(3)中轉(zhuǎn)服務(wù)的處理

中轉(zhuǎn)服務(wù)器充當著兩個客戶端之間的通信使者身份，它將收到的主動方的數(shù)據(jù)直接轉(zhuǎn)發(fā)給被動方，被動方返回信息給主動方也必須經(jīng)過中轉(zhuǎn)服務(wù)器的傳輸。傳輸效果與上圖類似，不再贅述。

5 結(jié)論

本文通過三種不同的方式成功地完成了基于Android的畫板傳輸，使用戶處在不同的網(wǎng)絡(luò)環(huán)境下都能夠與另一用戶進行通信，實現(xiàn)了本文的設(shè)想。接下來的工作是將此應(yīng)用與電話撥號功能連接起來，使人們在通話時，隨時可以在不影響通話的情況下調(diào)用畫板，進行實時傳輸，幫助提高通信質(zhì)量和效率。

[1] 姚彬. P2P流媒體系統(tǒng)數(shù)據(jù)調(diào)度和傳輸層優(yōu)化技術(shù)研究[D]. 杭州：浙江大學, 2013.

[2] 周敏,余慕春,黃維豐.綜合UDP打洞與Http代理的SIP穿越NAT方案[J].計算機技術(shù)與發(fā)展,2014(8):147-151.

[3] 饒永生. 超級畫板作圖效率研究[D]. 廣州：廣州大學, 2009.

[4] 楊薇, 趙亮. Web服務(wù)器性能優(yōu)化研究[J]. 電子技術(shù)與軟件工程, 2016(13):20.

[5] 宋廣華. 多線程內(nèi)存數(shù)據(jù)庫服務(wù)器設(shè)計[J]. 計算機工程與應(yīng)用, 2001, 37(18):107-110.

[6] 童怡. 淺析NAT技術(shù)[J]. 科技資訊, 2009(32):191.

Transmission between Sketchpads based on Android

Chen Fuqin, Zhou Yuanping

(College of Electronics and Information Engineering, Sichuan University, Chengdu 610065, China)

When using the telephone to communicate,sometimes the description of the language may not express the message well.At this time,if both sides can timely open a drawing board to transmit data by drawing charts or other information on the drawing board,it can improve the quality and efficiency of communication. In this paper, the function of reat-time communication between the sketchpads is realized based on the Android platform. It can transmit data in real time in different network circumstances. The mobile device is used as the hand drawing input board, and the users can realize the drawing function through the finger touching screen. To ensure that users can communicate in any network environment, this paper provides three differet solutions.This paper importantly describes the communication mode of data transmission by using UDP hole when the communication is in different LAN.

drawing board; real-time transmission; UDP; network

TP399

A

10.19358/j.issn.1674- 7720.2017.23.019

陳富琴，周淵平.基于Android畫板的同屏傳輸[J].微型機與應(yīng)用，2017,36(23)：66-69.

2017-06-12)

陳富琴(1992-)，女，碩士研究生，主要研究方向：信號與信息處理。

周淵平(1955-)，男，博士，教授，博士生導師，主要研究方向：通信與信息系統(tǒng)，信號與信息處理。