android+網路詳解2

上小節我們以簡單的兩個小執行個體講解了在ANDROID系統上去操作網路資料的過程,下面我們繼續以小案例來深入講解關於在ANDROID系統上對網路的實際操作,在這裡我就以一個通過擷取服務端最新資訊來即時的顯示最新的資料在ANDROID手機用戶端為列,類似於現在一些手機應用的資訊顯示方式,如,通過服務端資訊的更新來即時監測自己的應用資訊的最新資訊,對其匹配否來判斷更新點,下面我們就來詳細講解要實現的全過程吧:

環境描述:首先有一個顯示列表:XXX檔案,大小XXXM，檔案格式XXX,如果是視頻的話,就會多添加一項,播放長度XXXX小時/分鐘,在這裡,我們採取判斷,如果播放時間大於一個小時的話,就以小時計算,如果小於小時的話,就以分計算,這時當用戶端關注伺服器的資料有所更新時,ANDROID用戶端就會發一個通知告訴瀏覽的使用者是否更新,在處理這個更新時,我採用的是使用者可自訂,如使用者可以自己定製接受檔案更新的方式有:預設為提示1分鐘後自動更新,可設定不需要提示直接更新,與彈出對話方塊提示更新,或收到提示後按時5分鐘提示一次希望你手動更新,並顯示更新的記錄

環境描述完了,下面我就來描述一下我們怎麼去實現上面這個環境要求呢,這就需要我們去瞭解更多的關於網路知識與ANDROUD本機群組件服務機制了,先我們假設列表已經正常顯示,此時我們需要搭建服務端,相對來說服務端會做很複雜的工作,只是特別注意的是,在這裡我講解在服務端儲存資訊的方式分為XML與JSON格式,而在其檔案頭請一定要把<?XML VERSION="1.0" ENCODING="UTF-8"?>寫在頭放,不管你的頭行有多少資料,你都不能把它寫在其它行,不然會報錯的,其次在服務端做的工作我就不多說了,如安全驗證,等,當然我會簡單對資料更新提示與編碼格式做些簡單的介紹,我們先從第一次去擷取服務端的資訊開始講起吧,在這裡我們就不在使用HttpRULConnection做要求標頭發送訪問響應了,而是直接採用SOCKET編程來實現,因為我們固定了服務端主機名稱與連接埠來提供訪問,然而在服務端,我們採用的是多線程並發訪問機制來接收的,主要資訊就是提供一個線程池:ExecutorService executorService = Executors.newFixedThreadPool(Runtime.getRuntime().avilableProcessors()*100)提供一百個線程並發的訪問量,其次就是服務端特別提供的監聽連接埠XXX.再次就是存放斷點資料用來在傳輸資訊時假如資訊傳輸在某一個時刻失敗的話就會記住當前斷點並在再次開啟傳輸時擷取之前斷點繼續傳輸,只是這個功能是在這個講解中多處來的,為什麼是多出來的了,它用在伺服器端,主要是實現上傳檔案時使用,如果我們在下載檔案時只需要在用戶端儲存斷點即可,OK,多點知識不是壞處嘛,其次就是單獨開啟一個方法來啟動這些線程,在服務端,我們採用了資料擷取的方式去擷取網路上最新的資訊,另外添加了人工處理資料的方式對其資料分別進行更新,當然這裡數伺服器端技術,主要使用的是J2EE方面的技術,由於我之前做J2EE比較長,所以在之前的項目中兩方面都有兼任,在這裡我就大體介紹一下我們其中的項目在J2EE上的架構吧,說到這裡不說也不行了,只是我不會說出具體項目與詳細細節,因為項目還在保密其,其架構我就說個基本的,相對來說這個架構比較簡單,但是內部機制不是你想象的那麼簡單,呵呵,有點調胃口的感覺,廢話不多說了,不然誰看到這樣的文章都受不了的,甚至給我痛罵一頓，首先我們後台管理顯示層頁面使用JSP,其次是資料控制層,資料控制層實現了資料緩衝與資料服務機制,再次就是商務邏輯層,使用MEMBERSHIP與RBAC提供對商務邏輯的處理,再次據是資源訪問層,使用J2EE技術構建實體並對其實體進行管理控制,採用SubSonic機制來實現,這層主要是對資源層,即資料庫資源做控制輸入輸出,在J2EE裡的基本架構也就這樣，如果是詳細描述的話,那可能就是個糟糕的問題了,所以就簡單描述在這裡吧,還有就是在WEB最上層是提供了對手機用戶端訪問的驗證需求,這是必要的,你可以採用SOAPHEADER+動態SESSIONID來對其操作,這是完全可以的,這就不知不覺好像談起架構來了,前端時間做架構好像有點上癮了,既然這樣,我也就簡單來介紹下我們手機用戶端的大體架構模式吧,記住是大體,即以MVC模式的架構方式:在V層我們主要提供了資料顯示與輸入,所以需要一個VIEW來提供顯示,還需要一個資料配接器來對資料進行配置顯示,即Data Adapter,其次就是在C層,在這層主要是UI對其的控制,它主要的作用就是關注資料與對V層資料提供進行控制,其次就是M層,這層就是針對M層來講的,它主要的作用就是擷取資料來源並想C層提供資料,在擷取資料來源的方式有幾種,一種是記憶體緩衝,一種是本地，另一種就是通過網路,即伺服器端擷取資料,對其也可以儲存在本地,OK,基本架構就是這樣了,可能有的人很關心我們在通過手機用戶端與網路伺服器進行資料互動時的過程,下面我們就來詳細講解了:在用戶端服務線程,我們會發一個定時器,使用SOCKET方式去獲得服務端的某地址XXXX,連接埠XXX,以Socket socket = new Socket(服務IP,連接埠);OutputStream outStream = Socket.getOutputStream()與服務端獲得串連,然後把要求標頭資訊組建成一個實體物件:String head = "Content-Type="+...."/r/n",然後通過outStream.write(head.getBytes())進行寫入並請求,只是需要注意的是我們在這裡面使用了PushbackInputStream,因為我們在資料讀取過程中,在頭或者內容的最後都會跟上斷行符號換行,我是說假如,當你讀取到/R後/N沒有讀取到的話,這時候根據檔案讀取長度,就會多讀到下一個內容的部分,那樣的話,下一個檔案內容就會出現不完整,然而普通流只能向前讀不能向後讀,所以我們使用PushbackInputStream裡的一個unread()方法可以對其已讀取的資料進行回退,只要經過是的判斷,如判斷讀到當前內容最後為/N時結束第一段,否則的話返回重新讀取當前位元組,這樣就可以避免我們在使用SOCKET編程實現資料轉送的過程誤讀不能後退的弊端,只是我們在這裡要盡量小心才是,由於我們是去獲得資訊,所以我們第一次不會有預設ID的唯一標誌,這是需要在服務端進行分配,也就是服務端獲得了相應的的請求並判斷你是不是帶有一個系統服務賦予的動態ID,如果沒有的話,就會動態新建立一個SESSIONID,並為當前進行保留,同時把相應的資訊附加到要傳遞給用戶端資訊的後面,作為資訊對象傳遞給用戶端,當用戶端擷取到這樣的資訊後就直接進行解析,由於我服務端採用的是JSON資料存放區資訊格式,所以在用戶端,我們首先要去對資訊進行解析,以對象對應格式做相應的處理,如獲得的是圖片格式,我們採用的是直接以二進位接收內容的方式進行顯示:Bitmap bitmap = BitmapFactory.encodeArray(datas,0,data.lengt);如是一般檔案就直接使用new String(file,"編碼格式")來進行封裝並返回與接收即可,只是在服務端對資訊響應時,它不是單純的只會去響應,而是定時的更新服務端資訊，在提示,服務端資訊是通過網路或者人工輸入來更新的,所以在對資料進行服務更新時,需要對曆史資料進行更新處理,這個過程比較複雜,在這裡我就不繼續介紹了,OK服務端基本就是這樣了,然後就是用戶端獲得資訊後,根據流輸出後並組建標誌讀取位置來實現判讀讀取的問價內容以至於踩用不同的格式進行讀取,並使用PushbackInputStream流防止誤讀機制來寫入,這點非常重要,請牢記,因為我們每種格式的內容都做了標記,只有我們通過這個標記的判斷才能知道我需要寫入的內容為格式以至於錯讀方式的倒退,OK,嚴格控制它就可以獲得不同的對象格式進行很好的分類來儲存取了,如獲得的是以MP3格式的檔案內容,我們就需要

通過ANDROUD內建的解碼器來接受並解碼,當然,我是說,如果你需要播放的話,當然首先,你得把它儲存在本地,然後就可以直接使用ANDROID內建的播放介面來實現更多的比ANDROID自己實現的跟票亮與複雜的播放效果,ANDROID的內建的只是一個很簡單的DEMO,但是它提供了免費的結構可以讓去施展它的儘可能:File autioFile = new File(Environment.getExtenalStorageDirectory(),fileName.getText().toString());MediaPlayer().release();MediaPlayer().setDataSource(audioFile.getAbsolutePath());MediaPlayer().prepare(); MediaPlayer().start();在這裡我不會講關於在ANDROID播放可能會存在哪些問題,在後面,我會講到在ANDROID中在播放視頻與音頻時遇到的問題與問題的解決方案,以至於我們該怎麼去實現一個即時播放的流媒體效果.OK,在流的傳輸機制中,我可能講得很簡單,只是流寫入與寫出我想大家讀很瞭解了,所以我只是在這個過程中我們怎麼去取得即時資料與可能遇到的問題進行了分析,以後在於遇到這樣的問題時應該用什麼樣的思路去解決,最後在ANDROID用戶端的顯示我就不在介紹了,那是關於UI顯示處理問題,再下來我就想說一下,當我們第一次獲得資料並成功顯示在手機用戶端後,我們怎麼去知道伺服器資料有所更新了呢,在這裡我們是這樣做的:在手機用戶端開啟一個服務線程,這個服務線程用來定時方法,也就是所謂的實現了定時重新整理的效果,也就是定時帶上本地第一次重服務端帶過來的SESSIONID以頭的方式封裝起來向服務端發出請求,當服務端獲得請求後,會根據用戶端帶過來的SESSIONID與本地之前儲存的SESSIONID進行對比,當然,本地之前儲存的SESSIONID收服務端資料更新服務來控制,如果有資料更新就會重建一個動態SESSIONID對其之前的SESSIONID進行替換,此時,如果用戶端傳過來的SESSIONID與服務端更新後的SESSIONID不匹配的話,就說明資料已經更新,此時,就會開啟服務端流進行寫入,用戶端也相應的對其索取與更新,在項目之後,我突發靈感,下面是個人技術探索,沒真正去實驗與應用過,如果感興趣的讀者或技術偏愛可以根據思路去測試一下:就是在用戶端使用BroadcastReceive來實現對資料進行監聽,但是需要在服務端可以指定一個連接埠供用戶端來實現監聽,也就是當服務端有資料更新時,服務端會發送一個訊息給那個連接埠,是監聽那個連接埠的接收者通過某種方式獲得這樣的資訊後並通知用戶端資料服務線程,讓他自動開啟與伺服器端對流串連的請求來擷取最新的資訊並更新自己.......等,好了,在這裡我簡單介紹一下,為什麼我採用直接使用Socket編程而不直接使用HTTP協議封裝後的組建來做呢,比如說可以使用HttpCilent來操作,如果你想在網路上指定某個功能單純實現某樣工作的話,然而你使用開源架構,它們都是對一些通用機制的封裝,雖然也包含了你所要的功能,只是你需要的只是它很小的一部分功能,缺慣用了一些很不需要的代碼,這樣到來的直接後果會導致你的應用程式效能嚴重下降,除非你要使用到了開源架構裡的所有功能,為了方便即可以去使用,畢竟人家開源的最佳化效果還是很明顯的,再次我們在做請求資料轉送的時候為什麼不直接使用HttpURLConnection呢,因為,我們已經知道主機的IP與連接埠,這是長時間固定的,然而在實現這個功能時,只是應用的很小的一部分,還有別的功能也需要引入類似的實現,如要實現FTP上傳檔案等功能,這時我們就需要使用SOCKET支援的斷點續傳上傳功能,然而HTTP協議是不支援,即使支援,在服務端也是限制傳輸大小的,比如一般的伺服器可能只能上傳到達2M,有的可能有5M或者更少,但是使用SOCKET是不受限制的,如就以FTP上傳伺服器為例:如果我們使用HttpURLConnection的話,HtttpURLConnection是繼承了URLConnection,然而它使用了一個預設緩衝機制限制了你在網路上的傳輸速率,一般它最大隻支援1M,它傳入的方式是以寫入記憶體的方式進行傳入,也就是供檔案一次性傳入與寫出,然而這樣使其記憶體是嚴重受限的,維持當你數傳比較大的檔案,如音頻或者視頻上G的檔案時,就會報記憶體溢出,然而我們使用SOCKET流機制寫入是不過分的依賴與記憶體的限制,它使用了一個ByteArrayOutputStream來實現緩衝機制的邊讀邊寫的方式據會把讀入記憶體的資料第一時間讀出來寫入本機資料庫或本地檔案進行儲存,同樣,我們提到斷點,在這裡就多說幾句吧,說為實現斷點續傳就是在當我們用手機下載或上傳某個檔案時,突然沒了網路,或者手機沒電了,此時檔案下載或者上傳就會被斷開,這時,服務端與用戶端都分別會記載其檔案上傳或者下載的檔案節點位置並寫入本地檔案或者資料庫,當我們再次啟動這個應用的時候去在上次丟失的工作就會首先去擷取本地之前儲存的節點來尋找對應的節點來進行匹配,如果匹配的話就繼續從匹配點開始讀取或寫入資訊.好了今天就說在這裡,下次我會對其部分以更詳細的案例進行解說.....