項目預覽視頻 http://chenlinlin.wang:520/video/Graduation%20Project.mp4
摘 要
爲了滿足人們日益增長的家庭安防需求，結合基本每家每戶都有閒置的智能手機的現狀，本文提出了一種基於移動智能端的家庭安防系統構造方案。系統充分利用了智能手機的傳感器、攝像頭、麥克風、閃光燈以及3G/4G/wifi等網絡通訊模塊，構造了一個集視頻直播、視頻點播、遠程報警爲一體的家庭安防系統。系統採用C/S的架構設計，分設三臺客戶端和兩臺服務器。客戶端以Android系統爲依託分別實現傳感器數據採集、視頻數據採集、視頻播放功能。服務器分爲事務服務器和流媒體服務器，事務服務器使用python語言搭建，實現數據接收和上報，流媒體服務器採用Linux系統，用於保存流媒體數據。
本文對Android手機傳感器、視頻直播技術、視頻存儲技術進行了研究，利用閒置手機各種硬件資源，結合雲端服務器平臺，設計了一套完整的家庭安防解決方案、爲普通用戶提供了一個高效便捷易於部署和維護的安防系統。論證了加速度傳感器對門窗震動檢測可行性，給出具體傳感器採集解決方案；完成了推流、拉流、流媒體檢索的調用；以及服務器推送功能。針對不同的客戶端、不同版本的Android操作系統，分別做了版本兼容處理，軟件穩定性強，實用性高。課題實現的震動檢測、視頻上報、遠端存儲、預警推送等功能基本滿足日常安防需要。
關鍵詞：Android；家庭安防；手機傳感器；遠程監控
Abstract
In order to meet people’s increasing demand for home security, combined with the fact that almost every household has an idle smartphone, this paper proposes a mobile security terminal-based home security system construction scheme. The system makes full use of the smart phone’s sensors, camera, microphone, flash and 3G / 4G / wifi and other network communication modules to construct a home security system that integrates live video, video on demand, and remote alarm. The system adopts C / S architecture design, with three clients and two servers. The client implements sensor data collection, video data collection, and video playback functions based on the Android system. The server is divided into a transaction server and a streaming media server. The transaction server is built in python language to realize data reception and reporting. The streaming media server uses a Linux system to store streaming media data.
This article studies Android mobile phone sensors, video live broadcast technology, and video storage technology. Using various hardware resources of idle mobile phones and a cloud server platform, a complete set of home security solutions is designed to provide an efficient, convenient, and Security systems for deployment and maintenance. Demonstrates the feasibility of acceleration sensors for door and window vibration detection, gives specific sensor acquisition solutions; completes the call of push stream, pull stream, streaming media retrieval; and server push function. For different clients and different versions of the Android operating system, version compatibility has been done separately, with strong software stability and high practicality. The vibration detection, video reporting, remote storage, and early warning push functions implemented by the project basically meet the daily security needs.
Keywords: Android; home security; mobile phone sensors; Remote monitoring
目錄
第 1 章 緒 論 1
1.1 研究背景和研究意義 1
1.2 研究現狀 1
1.2.1 閒置手機現狀 1
1.2.2 安防領域現狀 2
1.3 研究思路和方法和論文內容及結構安排 3
1.3.1 研究思路和方法 3
1.3.2 結構安排 3
第 2 章 設計平臺以及相關技術 4
2.1 Android操作系統 4
2.1.1 Android四大組件詳解 4
2.1.2 Android 系統架構 5
2.1.3 Android手機傳感器技術 7
2.2 Linux平臺 7
2.3 本章小結 8
第 3 章 場景及採取方案 9
3.1 應用場景介紹 9
3.1.1 設計要求 9
3.1.2 典型應用場景 9
3.2 解決方案以及相關技術 10
3.3 技術路線 11
3.3.1 傳感器部分 12
3.3.2 推流部分 12
3.3.3 流媒體服務器部分 12
3.3.4 視頻播放部分 12
3.4 本章小結 13
第 4 章 Android客戶端設計與實現 14
4.1 傳感器採集端 14
4.1.1 傳感器採集端介紹 14
4.1.2 採取方案以及可行性分析 14
4.1.3 UI和數據上報 15
4.1.4 傳感器採集端配置 16
4.1.5 傳感器採集端監控參數 17
4.2 視頻採集端 17
4.2.1 視頻採集客戶端介紹 17
4.2.2 原始視頻採集和處理 18
4.2.3 視頻編碼封裝處理技術 18
4.2.4 推流技術 19
4.2.5 代碼分析和配置簡介 20
4.2.6 附加功能 23
4.2.7 問題及分析 24
4.3 遠程監控端 25
4.3.1 遠程監控端介紹 25
4.3.2 視頻直播配置 26
4.3.3 視頻點播配置 27
4.3.4 遠程報警 30
4.4 本章小結 32
第 5 章 服務器端 33
5.1 事務服務器 33
5.1.1 傳感器接收 33
5.1.2 個推服務器 33
5.2 流媒體服務器 34
5.3 本章小結 36
第 6 章 結 論 37
致 謝 38
參考文獻 39
第 1 章 緒 論
1.1 研究背景和研究意義
隨着信息技術的不斷髮展，以及我國居民居住條件的不斷改善，人們對家庭安防的認知不斷深化，家庭環境下的安防需求也越來越強烈，智能家庭安防已經成爲社會生活的“剛需”。家庭監控是家庭安防系統的重要部分，一直以來都受到高度重視。但現有的家庭安防系統有諸多缺點：1、成本過高，目前大城市中人口仍然在增加，人員流動性很強，結構不穩定，在大城市租房房租也在不斷上漲，爲了安防如果房東給每間出租屋安裝安防系統無疑會將成本轉嫁到租客身上[1]。2、不利於移動或者維護，目前實現監控的方案大多使用固定攝像頭，一旦使用膨脹螺絲將其固定起來，普通用戶要想移動攝像頭非常困難。基於這樣的現實需求，本着低成本廢物利用的原則，本文采用閒置手機作爲家庭安防系統的核心部件，搭建智能家庭安防系統。選擇閒置不用智能手機充當監控設備是經過審慎的評估的，現在每家每戶基本都有閒置的智能手機，這些智能手機本身的CPU能夠達到視頻錄製上報的算力要求[2]；智能手機包含的網絡模塊，能夠方便的從家庭網絡環境切換到4G網絡，當家庭網絡常出現故障，仍然能夠完成數據上報；另外現有的手機一般具有兩個攝像頭，本文設計的系統可以以任意角度固定手機；傳統攝像頭沒有UPS支持，一旦出現電力問題，攝像頭便無法繼續工作，在典型的盜竊犯罪場景中家庭電力系統也很容易遭到破壞，入侵者先破壞電源，再入侵到室內，此時攝像頭便無法正常工作形同虛設，家庭網絡系統也會停止運行，所以本文需要一個自帶電力儲備，並且即使家庭WiFi癱瘓，也可以繼續錄製視頻，並且能夠將數據上傳的設備，閒置手機恰好可以滿足本文的需求。
1.2 研究現狀
目前國內閒置手機留存量已經突破十億，如何將這些閒置手機再次利用起來發揮餘熱成爲重要課題，諸多個人和單位都嘗試在閒置手機上運行定製化的服務，例如用手機作爲Linux服務器提供web服務等；另一方面國內安防局勢不容樂觀，隨着經濟下行壓力的增加導致犯罪率開始回升，入室盜竊成爲普遍的犯罪場景，因此國內諸多企業開始佈局家庭安防業務場景，目前家庭安防領域仍然是一個新興市場。
1.2.1 閒置手機現狀
調查顯示平均每位用戶大約18個月會更換一次手機，這些更換下來的手機回收率不足2%，絕大多數被淘汰掉的手機會被存放在家中，閒置手機內CPU算力雖然不能夠滿足我們的日常生活需求，但是如果用來做家庭監控，那麼這些手機仍然可以繼續發揮低功耗高性能的嵌入式產品優勢。
近年來隨着手機芯片性能的提升，手機換代速度也越來越快，僅僅去年一年，國內手機出貨量達到4.25億部，與此同時新用戶5698萬，這意味着將近3.7億部手機將被閒置，這些閒置的手機放在居家環境中，由於手機長時間處於關機狀態，很可能會因爲外界環境導致手機自燃帶從而帶來安全隱患。長時間閒置而且又佔地方，因此這些存放的手機很可能被丟棄在城市的垃圾桶裏，大街小巷中，甚至可能出現在土壤之中。手機內部本身含有大量的重金屬，在土壤中的手機將會嚴重污染地下水資源。手機回收目前仍然處於不規範的狀態，手機是日常生活中接觸最多的電子設備之一，手機內部存貯着大量的個人隱私，很可能會出現藉着回收手機的幌子，實質上是爲了竊取個人隱私的手機回收，這一方面仍然需要時間讓市場和政府來規範。因此在現階段最好的方法就是繼續利用淘汰的閒置智能手機，讓這些手機繼續爲用戶提供服務，等到手機已經徹底不具備利用價值的時候，通過專門的手機回收機構進行手機回收和銷燬。
1.2.2 安防領域現狀
目前國內的防系統處於起步階段，家庭攝像頭普及率仍舊很低市場潛力巨大，《IDC中國智能家居設備市場季度跟蹤報告》顯示，2018年中國家庭安全監控市場出貨量達到1338萬臺，同比增長65.9%，未來發展潛力巨大[3]。
小米家庭攝像頭在國內起步較早，隨着時間的發展米家攝像頭已經成爲中國最暢銷的家庭安防攝像頭之一，從硬件攝像頭到服務器再到手機app都有不錯的用戶體驗。米家攝像頭按照不同的產品定位，分爲不同的產品線以及價位，基本滿足普通用戶的需求。小米在人臉識別方面也取得巨大進步，當陌生人經過攝像頭時，如果被識別爲陌生人則會遠程報警，且攝像頭會追蹤陌生人移動。
美國ADT公司從２０世紀３０年代開始拓展簡單的防盜報警業務，逐漸發展成爲一家舉世聞名的聯網報警服務商，建立了十分先進的聯網報警服務平臺。其業務以家庭安防爲中心，涵蓋安防攝像頭、家庭自動化系統、身份防盜等多項業務，在統一平臺上爲用戶提供安防設備和配套的解決方案。GE安防作爲美國通用電氣公司的全資子公司，是安防技術與生命安全技術的重要供應商。GE安防提供行業最廣泛的安全業務組合，範圍涵蓋爆炸物與毒品探測、防盜和門禁控制、密鑰管理、視頻監控、侵入防範及火災探測等。 國內的華爲、360、海康威視等科技公司也紛紛發力家庭安防系統，分別針對自己傳統的業務領域推陳出新提出一系列新的解決方案[4]，爲用戶打造一個安全易用的家庭網絡安防系統。
這些安防系統的設備都需要額外購買的，並沒有爲用戶節省成本，也沒有提供“斷電”、“斷網”等極端情況下的安全的解決方案，不能滿足本文嚴苛的安防需求。
1.3 研究思路和方法和論文內容及結構安排
1.3.1 研究思路和方法
1、瞭解國內外相關產業情況，深入探究他們是利用了哪些平臺以及如何實現的這些功能模塊的，他們利用了哪些開源的框架，如何實現自己的功能和個性化定製的。
2、基於國內外成熟的廠商方案，提取這些開源框架、SDK等等。然後查找同一類別的SDK進行對比分析，尋找到最適合家庭應用場景的框架等利用其進行二次開發。
3、基於這些框架等開始進行方案的搭建，將三個Android客戶端打通，然後連接到兩臺服務器上。在實際的開發工作中，遇到不適合的開發框架，則應慎重考慮後更換框架。在整體搭建完成後，進行軟件的內部優化，以及細節部分的處理，打造可用性強的軟件系統。
1.3.2 結構安排
第一章爲緒論部分主要介紹了課題的研究背景、意義，以及現在家庭安防系統的現狀，已有的家庭安防系統的優點和缺點的分析，制定本文的研究方向和需要重點攻關的關鍵技術。
第二章爲設計平臺以及相關技術介紹：詳細介紹了本文的設計平臺即Android終端平臺以及Linux服務器平臺。其中Android平臺重點介紹了本文中用到的Android傳感器、攝像頭、四大組件，以及Android的主體架構等。
第三章爲軟件系統設計：介紹了課題的應用場景、課題的解決方案、技術路線等等。
第四章爲Android客戶端的設計與實現，分別介紹了三個Android客戶端設計理念以及方法的論證，到最後實現的功能，以及這些功能背後的技術支撐。
第五章爲服務器設計與實現，介紹如何搭建兩個服務器平臺，以及每個平臺所做的工作等。
第六章爲總結，描述了整個項目情況，以及未來的應用場景和擴展前景。
第 2 章 設計平臺以及相關技術
本文設計的客戶端將運行在Android操作系統之中，Android操作系統是目前最廣泛使用的手機操作系統，提供諸多資源接口方便開發者調用，另外由於Android廣泛使用，出現了Android的各種模塊化的SDK，使得開發效率有很大的提升，在開發過程中出現問題也可以很方便的在社區網絡中尋找答案。服務器端採用常見的Linux服務器，Linux服務器可以無界面啓動，減少了資源的消耗，另外Linux提供的文件管理和權限配置等，恰好可以滿足本文安全方面的需求。
2.1 Android操作系統
Android一詞的本義指“機器人”，在法國作家利爾亞當1886年發表的科幻小說《未來夏娃》將外形像人的機器叫做Android。後來andy rubin用了這個名字爲新操作系統命名，從此Android操作系統便誕生了。
Android基於Linux，很多東西包括內核文件系統等等都是從Linux上直接移植過來，受蘋果iPhone發佈的影響，Google也加進了對Android的收購腳步，最終在2005年8月被Google收購，從此Android操作系統便成了以Google的一項重要產業佈局，由Google和開放手機聯盟等負責運營以及新產品功能的開發。Android目的是打造一個智能手機操作系統，目前主流的嵌入式設備基本都用Android來做操作系統智能手機、智能電視，智能機頂盒，平板電腦，智能家電等等， 隨後Google與多家軟硬件公司共同打造Android操作系統，最終Android操作系統便在全世界範圍內流行，Android基於Linux，因此採用了 Apache開源許可證的授權方式，現階段Android已經發布到Android10版本，版本各自之間有很大的不同，但是Android的一些底層架構和開發者最常用的四大組件基本沒有太大的變化[5]。
2.1.1 Android四大組件詳解
Android系統四大組件是幾乎每個程序都要用到的，四大組件分別爲activity、service、content provide、broadcast receiver。
Activity可以理解爲應用程序的窗口，在Android studio中新建一個工程默認就會有mainactivity，在mainactivity中會有對應的layout，Android studio中默認爲constraintlayout，但是這個layout在實際的開發工作中並不常用，常用的是linerlayout以及relativelayout因爲本文設計的app需要滾動，因此設置爲linerlayout並設置可以滾動窗口，以此兼容小屏幕手機。
Service屬於運行的代碼程序，例如本文中的遠程報警就採用的是service方式Service一般沒有用戶UI，因此它一般位於後臺運行，沒有用戶交互的功能，Service組件需要繼承Service類，系統自帶的service類提供了諸多的方法，想要調用自己的方法可以選擇建立新的成員函數或者override。Service爲其他組件提供後臺服務的支持，也可以監控組件處於什麼樣的運行狀態[6]。
圖 2 1 典型Activity生命週期
Content provider方便同一手機不同程序間的數據共享，以提供數據集的方式，將數據傳遞出去，符合採用統一的資源定位符即uri來定位資源，凡是由內容提供者提供的數據一律以content://作爲前綴，以此來標識資源的位置。
Broadcast receiver廣播接收者，由於廣播衆多，因此編程時可以只對感興趣的外部事件(如當電話呼入時，或者數據網絡可用時)進行接收並做出響應，隨着Android系統日益權限收緊的情況下，此種方式只適用於特定場合下的廣播。靜態註冊相比動態註冊則有諸多好處，首先只要設備是開啓狀態，廣播接收器也是打開着的那麼就能及時接收到推動，其次app本身未啓動，該app訂閱的廣播到達時候也會對APP起作用。
2.1.2 Android 系統架構
Android 的架構可以大致分爲四部分，它們分別是應用程序層(Applications)，應用程序架構層(Application Framework)，系統運行時庫層(Libraries和Android Runtime)與 linux的內核層(Linux Kernel)。
(1) Linux 內核層： Android是基於Linux開源系統內核來進行開發的，而Linux是使用C/C++開發的，常見的Androidapp，一般採用Java語言編寫，這是因爲Android在頂層預留了Java的接口。Linux內核的支持下，不需要去寫獨立的驅動來驅動各種硬件設備，例如使用相機的時候，只需要進行權限的聲明即可調用相機。不過隨着時代的發展，Linux內核的優點也在慢慢變化，變成了Android的缺點，隨着微內核的興起，Linux這種宏內核的方式能否繼續滿足時代的要求本文還不得而知[7]。
(2)系統運行庫層：在Android的系統架構示意圖中，除了Linux內核層更重要的是系統運行庫層，系統運行庫層保證了與Linux的隔離，它能夠支持應用程序運行，也可以爲Android系統帶來了和Linux完全不同的接口[7]。Android NDK提供了很多訪問 Android 系統的內部資源的方法，因爲這個庫本身就是採用 C/C++來完成程序接口的。Dalvik 虛擬機也是基於Linux 內核平臺的，所以也能夠完成進程的隔離與線程的管理功能，處理異常情況並回收內存垃圾。
圖 2 1 關於Android系統架構
(3) 應用框架層：這一層屬於開發這比較常見的一個層次，功能大體是來提供在構建應用程序過程中有可能會用到的各種 API編程 接口，在 Android 中，本文可以常見的部分系統自帶應用就是利用這些 API最好的例子，他們極致使用了這些接口，由於這些API的開放性，軟件開發者也可以利用這些 API 來編寫各自的應用，實現不同的功能，利用它們實現快速有效的應用程序開發和產品迭代，同時也方便重用與個性化擴展組件[7]。
(4) 應用層：應用層屬於用戶比較熟悉的層次，包括各種可以與用戶交互的應用，或基於 Java 編寫的後臺服務等等，換句話說，所有安裝在手機上的應用程序都是屬於應用層的，系統默認的聯繫人列表，短信服務等程序這些都是應用層很好的運用，從應用商店下載的應用，當然，其中也包括了本應用都是應用層的例子[7]。
2.1.3 Android手機傳感器技術
Android傳感器有很多，不同的Android手機也有不同的傳感器，目前市場上常見的傳感器主要有以下幾種：1.加速度傳感器、2.磁場傳感器、3.方向傳感器、4.陀螺儀傳感器、5.重力傳感器、6.線性加速度傳感器、7.溫度傳感器、8.光線傳感器、9.距離傳感器等等[8]。
加速度傳感器又叫G-sensor，測量x、y、z三軸的加速度數值，可以通過sensormanager調用。
該數值包含地心引力的影響，單位是m/s^2。將手機平放在桌面上，x軸默認爲0，y軸默認0，z軸默認9.81。將手機朝下放在桌面上，z軸爲-9.8。將手機向左傾斜，x軸爲正值。將手機向右傾斜，x軸爲負值。將手機向上傾斜，y軸爲負值。將手機向下傾斜，y軸爲正值。本文采用加速度傳感器使用的是Z軸來進行測量。
加速度傳感器可能是最爲成熟的一種mems產品，市場上的加速度傳感器種類很多。手機中常用的加速度傳感器有BOSCH（博世）的BMA系列，AMK的897X系列，ST的LIS3X系列等。這些傳感器一般提供±2G至±16G的加速度測量範圍，採用I2C或SPI接口和MCU相連，數據精度小於16bit。
2.2 Linux平臺
常見的服務器平臺一般有Windows和Linux兩種，目前Linux服務器使用率遠遠大於Windows服務器。Linux服務器又分爲多種，常見的又Ubuntu，Debian，以及centos。這幾種Linux發行版本各自有各自的特點。其中Ubuntu一般用於桌面級服務，其對桌面級應用支持較好；centos一般用於服務器，centos的軟件一般經過嚴格測試纔會上架，而且每個發行版本都經過較長時間的打磨纔會公佈，目前centos已經到了centos8版本。
本文的流服務器便是採用virtualBox中運行centos7來接收流媒體數據。虛擬機分爲兩個大的平臺分別爲VMware的虛擬機，以及VirtualBox。VMware虛擬機是收費的，而且價格較爲昂貴，普通用戶無需購買如此昂貴的產品，因此本文選擇後者，VirtualBox是開源的免費的，而且一般輕度使用和VMware操作基本一致。VirtualBox的用戶量也很大，遇到問題也可以很便捷的從網上獲取的本文的問題的解決方案。
Linux自帶文件管理可以很方面的存儲流媒體數據塊，流媒體數據塊需要按照時間戳命名，而Linux提供ntp對時機制，很好的保證了流媒體服務器時間的精確性，當拉取流媒體數據時，時間戳的精確度將會嚴重影響到視頻的質量，因此一個好的服務器必須要有精確的授時系統。由於視頻文件的脆弱性，這裏需要一個高可靠的文件系統和鑑權系統，Linux的自帶權限管理能夠很好的抵禦外來攻擊,防止文件被不明操作者刪除，保證數據安全。
2.3 本章小結
本章首先介紹了Android操作系統，介紹了Android系統的過去的發展，以及未來的趨勢，然後介紹了Android操作系統的四大組件，詳解介紹了各個組件主要的功能以及如何使用這些組件完成自己所需的功能。緊接着介紹了Android系統的主題架構，深入進行Android系統的探究，在緊接着介紹了本文的服務器平臺。
第 3 章 場景及採取方案
3.1 應用場景介紹
3.1.1 設計要求
1、能夠實時觀看家中情況，遠程瞭解室內信息，做到時時刻刻都在監控。
2、數據必須存貯在雲端數據中心，當家中遭到破壞時，歹徒一旦發現家中攝像頭勢必會毀壞其中存儲芯片。如果歹徒可以輕易破壞本文的安防系統，那這個安防系統必定是不合格的安防系統。
3、能夠應對複雜惡劣情況下的數據上報。隨着社會安防意識的普遍提高，不法分子的反偵察能力也在不斷增強，有時候入室盜竊歹徒會先切斷家中電源，使得家中安防攝像頭無法工作，即使安防攝像頭帶ups，但是這些攝像頭一般採用的是wifi信號將數據傳遞出去，雖然攝像頭可以正常工作，但是家中的網絡系統已經癱瘓，犯罪分子進入室內便可以在室內“來無影去無蹤”，普通家庭攝像頭根本無法捕捉到犯罪現場。
4、能夠隨時回看視頻，有時候可能需要查找特定時間點的視頻信息，因此這一點便尤爲重要，這一步實現首先需要對直播視頻流進行解碼處理，將視頻信號封包成爲一個一個的數據片段，另外需要提供檢索信息，方便本文客戶端查找指定視頻片段的時候能更快的響應。
5、遠程報警，當家中一旦遭到不明身份的人進入，應立即通知家庭成員，做到早發現、早預警、早處置。當家中門窗發生異常震動，比如陌生人暴力進入，甚至大風天氣導致玻璃破碎等等，凡是家中出現了異常情況都應當及時通知家中主人有異常發生，並推送對應的視頻片段到手機上，方便做下一步的判斷。
3.1.2 典型應用場景
入戶門或者需要監控的窗戶等等上面固定傳感器採集端，用於監控門窗異常震動，視頻採集客戶端放在適宜的地方，選擇自己想監控的區域，這就是一個典型的家庭應用場景。視頻上傳到雲端的服務器，由於採用了手機上報的方式，手機自帶的網絡通訊方式以及電池，可以屏蔽掉wifi還是移動網絡的差距，因此可以適用於不同網絡場景的。做到了本文所說的家庭“斷電”、“斷網”的極端情況下的安防系統的正常運行。
傳感器採集端應當能夠檢測細微震動，報警一定要靈敏並且可靠。傳感器採集端是本文的安防系統中最底層的環節，報警信息也是由此客戶端觸發，如果傳感器採集端失效，本文就不能及時發現家中異常，萬一有危險出現本文就將錯過最佳的響應窗口。
視頻採集客戶端由於是固定在門上，由於固定方式不同、因此攝像頭必須可以選擇性調用後置攝像頭或者前置攝像頭，另外還可以根據需要增加一下選擇性的功能例如開始關閉麥克風、開啓關閉閃光燈，如果有必要應當增加對焦等功能。
圖 3 1 典型的應用場景
遠程監控端是本文隨身攜帶的用戶端，用戶端可以隨時從雲上檢索視頻數據，及時回看家中監控視頻。另外應當可以直播家中場景，消滅一切的安全隱患。當門窗發生異常震動時候應當有推送到本文的手機上，點擊對應的通知，應當迅速定位到觸發傳感器採集端報警的視頻片段。
3.2 解決方案以及相關技術
根據以上應用場景設計了以下的系統架構，傳感器採集端一旦被觸發則將其觸發數據上傳到事務服務器上，事務服務器接收到傳感器數據之後通過個推服務器將報警信息以時間戳的形式推送給本文的遠程監控端。與此同時視頻採集客戶端也在源源不斷地將視頻數據長傳到本文的流媒體服務器上面，遠程監控端獲取到推送之後，當這個推送時間被點擊之後，跳轉到對應的播放頁面然後初始化控件，根據時間戳從流媒體服務器上檢索對應的視頻片段，然後通過流數據播放。在此基礎上本文做了其他的擴展，使得安防系統易用性得到增強，通過不斷測試，軟件系統的穩定性也有很大的改觀。
圖 3 2 系統總體架構設計
系統總體架構分爲三個Android客戶端以及兩臺服務器。
傳感器採集端通過http方式上報數據到事務服務器；視頻採集端需要將獲取到的數據流推送出去，此過程需要完成和流媒體服務器握手和流媒體數據可靠傳輸；流媒體接收到數據之後，需要響應拉流請求，將數據轉發出去，另外需要將視頻保存本地供遠程監控端調用；視頻播放需要支持流數據解碼播放，在低緩衝率情況下保證視頻不卡頓。
3.3 技術路線
實現本文中的解決方案需要解決傳感器採集的問題、推流的穩定性和低延遲、流媒體服務器搭建和握手問題、以及視頻播放快速解碼。
圖 3 3 技術路線圖
3.3.1 傳感器部分
Android系統的傳感器部分已經統一封裝成一個sensormanager，獲取到sensormanager對象之後，通過調用相關的參數獲取到對應的傳感器，再通過傳感器獲取傳感器測量到的各個維度的數據，後來進行分析等等。獲取到傳感器數據之後，很容易通過http發出一個get方式的請求，將本文的傳感器數據發送出去。
3.3.2 推流部分
目前推流SDK有很多，例如大牛SDK，sopcast等。本文選擇sopcast用於推流，它有很多優點例如：最好的 P2P傳輸技術，能夠在所有觀看者之間共享數據，即使觀看者這NAT環境下也可以輕易穿透，視頻傳輸對帶寬要求非常大，P2P模式使得數據傳輸冗餘性更高，減輕了服務器壓力，同時應用程序端獲得的數據更穩定，另外sopcast的P2P延時在業界屬於很低的，可以很容易建立自己的廣播頻道，本文距離的廣播頻道爲aaaa。媒體編碼方面，sopcast支持以多種實時流媒體協議獲取數據：mms，http，支持多個文件格式：asf, wmv, rm, rmvb, mp3等支持循環播放文件。Sopcast資源友好，由於本文是在閒置手機上運行，因此算力較小，sopcast內存佔用率和CPU佔用率都很低，播放一個節目內存佔用10M-30M，CPU佔用小於5%佔用資源少[9]，非常符合課題需要。
3.3.3 流媒體服務器部分
目前流協議很多如rtmp以及rtsp。本文采用的協議是rtmp即 Real Time Messaging Protocol，由Adobe Systems 公司爲 Flash 播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議，也是國內直播主要採用的方式之一；流媒體服務器系統是centos7，centos有很多自動化的運維工具方便本文的部署；centos發行版有較長的生命週期支持，方面本文後期的維護以及擴展其他功能；centos非常的穩定，相比較Ubuntu，debian等centos的每次迭代更新都十分慎重，服務器宕機機率很少。流媒體服務軟甲使用的是開源的nginx，因爲需要在上面裝nginx的web服務器安裝rtmp-module，所以需要本地編譯的方式安裝[10-11]。
3.3.4 視頻播放部分
Vitamio能夠流暢播放清晰度爲720P甚至1080P高清MKV，FLV，MP4，MOV，TS，RMVB等常見格式的視頻。因爲vitamio的特性，它屏蔽了平臺之間的差異，因此還可以在Android與iOS上跨平臺支持MMS, RTSP, RTMP, HLS(m3u8) 等常見的多種視頻流媒體協議，能夠在多種架構上進行音視頻硬件解碼工作。最新版的vitamio支持大多數FFmpeg AVOptions功能，從而啓用自定義HTTP頭支持。Vitamio使用.so庫來支持更多硬件，例如 X86或MIPS。Vitamio自適應技術，能夠改善流媒體播放清晰度和卡頓問題，特別是支持自適應比特率流媒體。安全性方面，vitamio包含OpenSSL，因此支持某些與SSL相關的協議，例如https，tls，rtmps，rtmpts。播放速度控制可以從0.5到2.0。最新版的vitamio改進對字幕支持，包括外部位圖字幕。在線視頻緩存到本地存儲中，可以重複使用，直到系統自動刪除緩存文件爲止。更多MediaPlayer API，例如 getMetadata，getVideoTrack。支持RGBA_8888渲染，支持將RGB_565或RGBA_8888切換到視頻渲染，添加了增強Android 16+中的硬件解碼[12]。
支持ARMV6 CPU，可能會有一些錯誤。Vitamio支持直播和點播兩種方式，因此本文在這兩種方式的基礎上進行擴展，做了三個比較大的功能：視頻直播，視頻點播，遠程報警。
3.4 本章小結
本章介紹了本文設計的對應業務場景，以及部署方案。對應用場景進行了分析，然後針對這些應用場景提出了對應的解決方案和技術路線。詳細介紹了要採用哪些技術，以及爲什麼採用這些技術，這些技術有什麼好處等，最後對這些方案進行論證是否能夠滿足本文設計需要等等。
第 4 章 Android客戶端設計與實現
Android客戶端分爲三個分別爲傳感器採集端、視頻採集端、遠程監控端。
傳感器採集端負責檢測門窗震動情況，一旦發生險情傳感器採集端數據會上傳到事務服務器上；視頻採集端的數據會通過wifi一直上傳到服務器上面，保證了視頻數據的完整性，視頻採集端採用高性能編碼和封裝方案，從視頻採集到上傳到服務器完畢總耗時低於1秒；遠程監控端實現了視頻直播、視頻點播、遠程報警三大功能，滿足日常監控預警需要。
4.1 傳感器採集端
4.1.1 傳感器採集端介紹
傳感器採集端位於本文整體設計的最底層位置，用於檢測門窗震動。本文傳感器採集端是基於加速度傳感器設計的，上報地址和端口可以按照實際部署的服務器開放的端口進行更換。此外一個傳感器可以向多臺服務器上報數據。除了向遠程服務器上報數據之外，傳感器採集端也將數據儲存到本地的TF或者內部存儲器的存儲空間中，記錄的數據有時間戳以及傳感器被觸發時候的測量值。
圖 4 1 傳感器採集端
4.1.2 採取方案以及可行性分析
傳感器採集端主要用到的是加速度傳感器。本文用膠帶將手機固定到房間門上，並開門關門檢測其三軸傳感器數據。其中典型的開門關門產生的數據如下圖4-2所示
圖 4 2 典型檢測數據
可以看到數據有明顯變化，但是開門關門三軸直觀變化結果較小，本文將數據平方並相加擴大差異得到如下圖所示結果
圖 4 3 傳感器數據變動情況
此圖的變化比較明顯，其中第一個波谷爲爲開門時產生的加速度變化，第二個波谷爲門停止運動再次產生的加速度變化。爲了確保數據的準確性，本文對其進行多組實驗，測量了多組數據，繪製多組圖像，其中典型值如下圖所示
圖 4 4 多組測量值及其圖例
當手機準確固定在門上時候，門處於關閉狀態時，不會觸發傳感器採集端報警，當開門的時候，甚至鑰匙插進鎖眼的時候都會觸發傳感器報警，因此可以得出加速度傳感器能夠滿足本文檢測門窗細微變化的要求，用手機加速度傳感器可以測量出門開關狀態的變化，此方案可行。
4.1.3 UI和數據上報
傳感器本身的測量也會有誤差，每次測量的值都不同，因此本文應當設定適當的閾值，當加速度傳感器某一軸的數據變化超出了本文的閾值範圍，則觸發報警。因爲傳感器數據在加速度的測量上有可能出現負值，因此本文對加速度數據取絕對值後進行操作。當加速度傳感器測得數據的絕對值大於本文預設值時，數據將會以get的方式上傳到服務器。發送格式爲"http://" + edit4 + “:” + edit5 + “/sensor?” + “Time=” + System.currentTimeMillis() + “&accz=” + acclerometerZ。其中edit4爲本文的域名參數或者時IP地址，edit5爲端口參數0-65535，System.currentTimeMillis()爲系統時間戳，acclerometerZ爲Z軸傳感器參數。在門上反覆實驗之後，得出閾值爲0-0.4，上限爲0.4的時候，門在關閉的情況下不會導致傳感器出現報警，另外也能夠滿足本文的開門關門測量需求，因此傳感器採集端設置測量精度缺省值爲0.4。
圖4-5爲傳感器採集端配置頁面，點擊開始測量之後，則跳轉到圖4-6所示的監測界面。
圖 4 5 傳感器採集端配置頁面 圖 4 6 傳感器採集端監測頁面
4.1.4 傳感器採集端配置
測量精度：加速度傳感器本身精度很高，因此應當設置一個閾值，當加速度數值在閾值之內則不報警，否則觸發報警，將當前的時間戳上傳到事務服務器上，加速度傳感器觸發的閾值爲double類型數據，根據實際情況進行設置，不同的固定角度閾值也有所不同，本文默認採用豎直固定方式，默認值爲0.4。
下限、上限：方位傳感器觸發閾值，每次開門關門方位傳感器會切割南北地磁線從而測定自己所處的方位，此種方式測量較爲準確，但一些老舊手機並沒有此種傳感器，因此本app還是以加速度傳感器來測量，但保留了方位傳感器觸發接口。
域名：傳感器服務器的域名，支持普通域名和ip模式，可根據不同情況修改，圖中爲域名信息，本次測試時缺省值爲127.0.0.1。
端口：傳感器服務器的端口，如有防火牆應在防火牆中打開此端口，圖中爲服務器端口，本地測試時缺省值爲52038。
4.1.5 傳感器採集端監控參數
系統時間戳爲本地時間，手機一般的時間設定都是聯網授時，因此時間精度低於一秒，處於誤差接收範圍內。
X、Y、Z軸的數據爲系統實時的加速度傳感器數據，傳感器數據變化系統會通知更新界面的UI，此頁面可以爲設定閾值信息提供參數信息，根據不同的固定角度提供不同的傳感器測量數據，便於設定實際的閾值使得觸發更加的準確。
Orientation爲方位傳感器數據，當手機支持此出傳感器時候則在下方列出方位傳感器各項數據，部分老舊手機不支持此傳感器，方位傳感器部分則不顯示。
上報到服務器以及寫入本地log均在右圖activity進行，通過新線程的方式將數據傳遞出去，每次傳感器測量值超過閾值，則新建一個線程發送http的get請求，所以開門一次，一般會有多次的get請求數據包，冗餘數據包可以防止第一個數據包在中途丟包導致報警信息沒能傳遞到服務器上，服務器收到多個數據包後進行過濾處理，在最近的觸發中，只保留一個數據包並把信息推送給遠程監控端。
4.2 視頻採集端
4.2.1 視頻採集客戶端介紹
視頻採集客戶端處於安防系統的核心環節，遠程監控端和傳感器採集端都是爲視頻採集客戶端服務的，視頻採集客戶端宕機則整個安防系統就失效了，失去的監控器的安防系統，就失去了安防的價值。因此視頻採集客戶端的穩定性，冗餘性一定要遠遠大於安防系統的其他部分。視頻採集客戶端可運行在不同版本的Android系統之上，因此對版本的兼容性以及有效性有着非常高的要求。
圖 4 7 視頻採集客戶端
視頻採集客戶端工作流程主要有以下幾步：
原始視頻數據採集和處理—>編碼和封裝—>推流到服務器
4.2.2 原始視頻採集和處理
採集是視頻推流的第一步也是最爲重要的一步，它從系統的採集設備中獲取原始視頻數據，將其輸出到編碼部分。視頻的採集主要涉及兩方面數據的採集：使用手機自帶攝像頭進行圖像採集以及調用手機麥克風進行音頻採集。
圖像採集：將圖像採集的圖片結果進行處理，然後組成連續播放的動畫，一般的畫面爲1s30幀，幀率的減少能夠有效減少佔用資源，另一方面幀率過低會造成視頻卡頓。 在監控系統中因爲對視頻大小敏感，以及對幀率要求並不是特別高因此本文設計的系統中設置爲10幀到20幀，由於人的視覺暫留效應，這些幀連續變化即構成所看到的視頻 [13-17]。
音頻採集：音頻數據可以和圖像結合組合成視頻數據，系統設計過程中本文把音頻採集設置爲一個可選功能，不需要音頻情況下可以選擇不採集音頻。音頻的採集過程主要通過Android硬件設備將環境中的聲音信號採集成模擬信號，然後再把採集的模擬信號數字化，音頻採集使用了諸多算法如延回聲消除算法（AEC）、靜音檢測算法（VAD）和各種混音算法等[13-17]。
4.2.3 視頻編碼封裝處理技術
對於媒體文件來說，這種大型數據的編碼非常重要，它的編碼速度和編碼壓縮率直接決定了消耗的帶寬資源，編碼處理不好將會嚴重影響用戶體驗和傳輸成本。
視頻壓縮編碼技術的核心思想就是去除冗餘信息，冗餘信息包括：
1、空間冗餘：圖像相鄰像素之間有較強的相關性
2、時間冗餘：視頻序列的相鄰圖像之間內容相似
3、編碼冗餘：不同像素值出現的概率不同
4、視覺冗餘：人的視覺系統對某些細節不敏感
5、知識冗餘：規律性的結構可由先驗知識和背景知識得到
相機底層編碼爲YUV編碼格式，這種編碼格式數據極大，因此需要對其進行壓縮，這裏採用了開源的ffmepg進行圖像處理，壓縮爲H264的編碼格式，H264是目前主流的編碼格式之一，它成像效果好且佔用資源很少。本文采用的時MPEG2-TS的數據封裝格式，首先rtmp的流式直播協議支持這樣的數據格式，直接將這些數據上報到服務器即可，另外服務器會生成.ts的文件將會有利於本文的點播回看，因此選擇此種格式效率最高格式轉換次數低，另外支持MPEG2-TS的播放器有很多[13]，例如VLC等等，也方便進行編碼調試。
4.2.4 推流技術
推流到服務器是指視頻採集端將數據上報到流媒體服務器的過程，此過程需要大量的網絡通訊，本文設計的數據採集客戶端當且僅當流媒體服務器開機並且握手成功之後纔會上報流數據。推流整個安防系統監控數據信息第一步，推流對這個視頻成像效果效果影響非常大，如果推流的網絡不穩定，客戶端有沒有做相應的調整，或者帶寬不足以支持數據的正常上報，視頻播放將會出現卡頓、掉幀等，用戶的體驗會很糟糕。
根據以上問題，數據傳輸協議選擇RTMP(Real Time Messaging Protocol)這是一種實時消息傳送協議，是Adobe公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議，另外HLS(HTTP Live Streaming)協議是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議支持嵌入RTMP協議之中。當以RTMP協議上傳數據時，流媒體服務器接收到數據很容易就可以分片和組裝，可以根據配置截斷成爲一個一個的視頻片段 [15]。
圖 4 8 RTMP協議流程
本文采用一個sopcast開源的SDK項目用於推送視頻流。Sopcast能夠能夠實現將本地數據直接上報的流媒體服務器。sopcast支持視頻本地預覽，播放的視頻就是實時上報的視頻，sopcast支持帶寬優化功能，當網絡出現波動，sopcast會智能降低分辨率採用較低的碼率進行視頻信號的傳輸，儘量保證視頻的完整。
圖 4 9 Sopcat-SDK構造
4.2.5 代碼分析和配置簡介
視頻採集端的代碼處理需要做版本兼容，從Android6.0之後使用相機需要動態的權限申請，低於Android6.0在安裝時聲明即可。具有相機權限則打開相機，同時繪製當前頁面UI，讓相機內容在當前手機屏幕上面顯示出來，於此同時，將當前顯示數據打包上報到指定的流媒體服務器上。握手成功並且成功上傳將顯示“start living”如圖4-10所示：
圖 4 10 視頻採集客戶端提示信息
相機授權分爲版本檢測、權限檢測、權限申請等步驟。應用程序啓動時檢測是否具有相機權限，如果具有直接開啓相機，否則進行版本判斷。當Android系統版本高於6.0則需要動態申請權限，彈出用戶授權框。當用戶拒絕授權則直接退出應用，如果授權成功，則啓動相機，進行下一步操作。代碼實現如下：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M){ //高版本兼容性選擇
if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) != PackageManager.PERMISSION_GRANTED) {//檢查是否具有相機權限獲取相機權限，因爲Android版本不同高於Android6.0之後相機權限需要動態申請。先做版本判斷，如果低於6.0直接進行下一步，如果高於6.0進行不同版本兼容性處理。
if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA)) {
//是否應該繼續顯示對話框
//之前請求過拒絕了 返回true
new AlertDialog.Builder(MainActivity.this).setTitle(“申請權限”).setMessage(“拍照需要申請相機權限，是否允許?”).setPositiveButton(“取消”,null).setNegativeButton(“確定”, new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
//點擊確定的時候再次進行權限的申請
ActivityCompat.requestPermissions(MainActivity.this, tancePermission, 0);
}
}).show();
} else {
ActivityCompat.requestPermissions(this, tancePermission, 0);
}
}
if (ContextCompat.checkSelfPermission(this, Manifest.permission.RECORD_AUDIO) != PackageManager.PERMISSION_GRANTED) {//應用沒有該權限
if(ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA)) {//是否應該繼續顯示對話框
new AlertDialog.Builder(MainActivity.this).setTitle(“申請權限”).setMessage(“錄像申請相機權限，是否允許?”).setPositiveButton(“取消”,null).setNegativeButton(“確定”, new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
//再次進行相機權限的申請
ActivityCompat.requestPermissions(MainActivity.this,tancePermission, 0);
}
}).show();
} else {
ActivityCompat.requestPermissions(this, tancePermission, 0);
}
}
}
//申請相機權限結束
圖 4 11 視頻採集客戶端成功打開相機
配置流服務器地址：配置流服務器地址非常重要。流服務器地址由域名端口以及服務軟件入口地址和上報數據存儲位置組成。此處以“192.168.1.100:1935/hls/aaaa”爲例，其中“192.168.1.100”爲域名信息，此處可以爲域名也可以爲IP地址，後臺會根據所填動態解析，如果爲域名則請求DNS轉換爲IP；1935爲常見的RTMP流端口，可根據流服務器開放的端口自行修改；hls爲服務軟件名稱，rtmp可分爲live和hls兩種工作模式，設置爲hls不僅可以直播，還可以保證數據會存儲在雲端服務器；“aaaa”爲直播上報路徑，此處不唯一，因爲一臺服務器可以支持多臺視頻採集端數據上報，因此此字段可以根據實際情況填寫。
圖 4 12 配置流媒體服務器地址
4.2.6 附加功能
附加功能有麥克風的關閉，閃光燈開啓關閉，攝像頭的反轉，手動聚焦等等。
麥克風關閉：默認app在視頻錄製的時候是啓用聲音錄製的，即在上傳數據流的同時也在上傳音頻，播放端可以看到“音視頻”。如果本文不希望錄製音頻，只要求錄製視頻的話，則點擊一下頂部的麥克風按鈕，系統將不在錄製音頻，播放段和服務器的媒體數據都將是靜音狀態。
閃光燈開啓與關閉：此種場景適用於比較黑暗或者某些需要燈光的環境下使用，本文可以選擇性的打開閃光燈和關閉閃光燈。
反轉攝像頭：考慮到視頻採集端的固定角度不同，並不是所有的用戶都希望使用手機後置的攝像頭進行錄製，在某些特定的應用場景將會使用前置攝像頭，於是攝像頭反轉便成爲一項非常重要的功能。此外還對攝像頭反轉做了優化處理，即使在上傳數據流的時候也可以進行攝像頭的反轉，中間缺失數據做模糊動畫處理。
聚焦：手機的拍攝位置不同，會出現虛焦等情況。在錄像當中一旦出現了虛焦的情況，本app是會自動調焦進行對焦的，但偶爾也會有不盡如人意的地方，因此做了一個手動調焦功能。可以拍攝不同的景深位置，特定位置的對焦。
圖 4 13 視頻採集客戶端攝像頭反轉
4.2.7 問題及分析
Rtmp直播流延遲一般都在30s左右，當延遲越短視頻出現卡頓等問題機率越大，經過調整播放緩衝區，優化測試最佳播放延遲爲2s左右。經檢查發現，推流延遲小於1s，服務器處理後的數據也是小於1s，播放延遲主要是因爲vitamio的原因，爲此使用了別的rtmp播放器測試，均可以達到較爲理想的播放效果。Vitamio優點在於佔用資源少，視頻不卡頓，支持多種格式的媒體文件播放。
圖 4 14 最優播放延遲
4.3 遠程監控端
4.3.1 遠程監控端介紹
遠程監控端主要有三大功能：視頻直播、視頻點播、遠程報警。
視頻直播：採用RTMP協議直接從流媒體服務器拉取最近的數據緩衝進行播放。
視頻點播：通過http的get方式獲取流媒體服務器的index.m3u8索引，根據索引的內容動態繪製playlist的UI，每個控件命名爲對應的時間戳，根據點擊事件拉取指定數據塊緩衝到本地進行播放。
遠程報警：完成遠程消息推送，報警信息在通知欄提醒時，點擊可以提取到對應的時間戳，然後根絕時間戳向流媒體服務器拉取指定數據塊進行播放。
圖 4 15 遠程監控端
4.3.2 視頻直播配置
在配置頁面輸入服務器所在的地址，以及端口號等等。然後點擊觀看直播，則app自動通過index.m3u8文件可以檢索到最近的視頻片段，把“直播”的數據流從流媒體服務器拉取到本地進行緩衝播放[12]。代碼分析如下：
mVideoView = (VideoView) findViewById(R.id.vitamio_videoView);
//找到vitamio的videoView這個控件
videopath = “rtmp://192.168.1.171/hls/aaaa”;
//設置播放地址，由於是局域網內實現因此直接寫對應的ip地址即可，rtmp默認端口爲1935，服務器並沒有更改端口，因此此處無需表明端口，直接給出二級地址“/hls”即可，在hls文件夾中可以同時建立多路直播信號，此處本文只建立一個直播信號即“aaaa”，所有的視頻媒體片段將都放到aaaa文件夾下，具體請見服務器章節
mVideoView.setVideoPath(videopath);//設置路徑
mVideoView.setMediaController(new MediaController(this));//設置媒體控件，例如進度條等等，此處意義不大，因爲是直播流，進度條不會出現變動。
mVideoView.requestFocus();//要求focus
mVideoView.setBufferSize(102464);//緩衝區大小默認爲10241024
mVideoView.setOnPreparedListener(new MediaPlayer.OnPreparedListener() {
@Override
public void onPrepared(MediaPlayer mediaPlayer) {
mediaPlayer.setPlaybackSpeed(1.0f);//設置播放速度設置爲1.0，默認1.0
}
});
圖 4 16 遠程監控端以及視頻直播
4.3.3 視頻點播配置
視頻採集客戶端上傳的視頻時連續的，由雲端服務器進行切片封裝、命名、存儲，並且建立一個index.m3u8de的索引文件，遠程監控端可以根據這個索引文件找到所有的文件。找到所有的文件之後跟進文件數量和名稱進行遠程監控端視頻的ui繪製。這是一個異步的問題，主線程不允許阻塞，所以需要新建一個線程取獲取index.m3u8中的數據。由於是網絡數據，所以必須得等待數據完全得到之後才能進行ui的繪製，如果出錯，或者有其他問題需要做異常處理。
視頻點播如何獲取視頻播放地址呢，首先前面的地址本文時清楚的視頻都是放在http://192.168.1.171/hls/aaaa/index文件夾下面的，但是具體的文件名不清楚，只有到index.m3u8這個索引文件中去尋找，然後轉化爲一個list格式的數組，在進行UI的繪製操作。以下是一個獲取index索引的一個函數，首先設置一個url前綴，然後設置幾個異步調用的函數，當數據獲取過來之後會調用onCcompleted這個函數。
M3U8Manger.getInstance().setUrl(“http://192.168.1.171/hls/aaaa/index.m3u8”)
//設m3u8文件的url
.getM3U8(new M3U8Listener() {M3U8 m3U82;
@Override
public void onStart() {Log.e(“hdltag”, “onStart(MainActivity.java:75):開始了”);
}
@Override
public void onError(Throwable errorMsg) {
Log.e(“hdltag”, “onStart(MainActivity.java:75):出錯了” + errorMsg);
}
public void onCompleted() {
Log.e(“hdltag”, “onStart(MainActivity.java:75):完成了”);
}});
}
@Override
public void onM3U8Info(M3U8 m3U8) throws InterruptedException {
Log.e(“hdltag”, “ttttttttttttttttt:”);
Log.e(“hdltag”, “onStart(MainActivity.java:75):拿到結果了” + m3U8);
videoList = m3U8.getTsList();
m3U82 = m3U8;
Log.e(“hdltag”, “onM3U8Info(MainActivity.java:91):” + videoList);
//videoList.notify();
});
這樣本文就可以獲取到所有的視頻數據獲取到視頻數據之後本文用到了gridview這個Android組件，根據服務器上面的數據，動態繪製UI界面，服務器上的每個文件，對應一個格子，每個格子裏面可以放圖片以及對應的文件名。本文使用默認的Androidlogo做每個視頻的封面圖片，文件名使用時間戳轉成日期之後編程string格式的字符串，見圖4-17所示：
圖 4 17 點播視頻
每一個小的Android機器人代表一個媒體文件，每個文件大約30s左右，下面的文件名採用時間命名方便快速定位到指定的視頻片段，此外時間可以轉化爲時間戳，可以通過時間戳提取服務器媒體信息。另外一種提取媒體方式是採用數組方式，index.m3u8可以看作一個list數組，gridList可以給出index，因此直接根據index就可以找到index.m3u8中的某個文件數據，將通過intent的方式傳遞到 vediopath然後通過生命週期事件即可播放。
圖 4 18 點播視頻延遲
此處本文點擊12：48：07秒的文件，打開之後的結果就是從12：48：07秒開始錄製的，通過list的index方式尋找到文件路徑要比直接從文件名比較查找要更加的高效快捷。
4.3.4 遠程報警
遠程報警是將三個客戶端，兩臺服務器連接起來的一個重要功能，遠程報警利用到了全部的資源。
圖 4 19 遠程報警架構
傳感器採集端檢測到門窗震動，將震動信息以get方式發送到事務服務器上，事務服務器接收到數據之後，通過調用第三方個推sdk將信息發送到個推服務器上，個推服務器將報警信息以及傳遞的參數推送到視頻播放段。收到推送之後，點擊狀態欄對應的信息，手機自動打開此app，並開始播放觸發傳感器採集端報警的畫面。個推服務器將時間戳推送給遠程監控端視頻，播放端通過時間戳的比較，尋找到距離目標時間戳最近的一個視頻片段開始播放，播放完畢即結束，觀看者也可以通過點播的方式尋找到其他的視頻片段進行觀看。由於所有的數據全部儲存在雲端的服務器，安全性有極大的保障。
點播功能集成了個推SDK在項目中，其中典型的數據流如圖4-20所示
圖 4 20 推送流程
本文將個推sdk集成到遠程監控端中，實現了消息的推送，在通知欄顯示推送之後，通過intent參數打開手機app內對應的activity頁面，然後傳遞相應的時間戳。客戶端開始拉去index索引數據進行時間戳的對比，當此時間齪小於傳遞的時間戳且索引的下一個時間戳大於傳遞的時間戳時候，則播放略小於傳遞過來的時間戳的視頻數據，完成預警信息的推送[18]。
圖 4 21 遠程監控端推送提醒
4.4 本章小結
本章介紹了三大客戶端，分別爲傳感器採集端，視頻採集客戶端，遠程監控端等。傳感器採集端首先對其進行可行性分析，然後介紹了課題設計UI界面以及對應的功能。視頻採集客戶端介紹了UI設計，以及如何採集並進行編碼處理，在後面介紹瞭如何將數據推送到服務器等。遠程監控端介紹了三個功能分別爲視頻直播視頻點播遠程報警，依次介紹了這三個功能背後的技術支撐。
第 5 章 服務器端
服務器端有兩個模塊，一個是視頻流服務器模塊，用於拉流推流。一個是事務服務器模塊，接收傳感器發送過來數據，並上傳到個推服務器，穿透的數據主要有時間戳等，獲取到時間戳本文就可以進行下一步的操作。
5.1 事務服務器
事務服務器模塊基於python3.7編寫，分爲傳感器接收和個推服務器推送。傳感器接收利用socket模擬http服務器響應，傳感器採集使用get方式獲取數據最大輸入爲1000字符，目前採用ipv4通訊方式，可按照要求支持雙棧[19-20]。獲取到數據之後通過Getui的SDK發送到個推服務器上，實現參數的傳遞和穿透，觸發頻率最高爲1分鐘一次。
5.1.1 傳感器接收
傳感器接收服務器平臺使用pycharm在本地搭建，由於需要接收傳感器採集端以get方式傳遞的數據，因此需要使用socket模擬http響應，此處有兩種方案：1、get方式發送數據，使用tornado提取參數然後將這些參數上傳到個推服務器。2、get方式過來的數據不必提取，與此同時獲取本機時間，將本機時間封裝並通過個推服務器發送出去。
綜合比較兩者，採用第二種實現方式。第二種實現方式操作起來比較簡單，另外還可以將多次觸發事件合併爲一次推送，防止多次推送到達遠程監控端。
5.1.2 個推服務器
搭建事務服務器步驟：1、在個推平臺申請賬號，獲取到appkey，appid，mastersecret等參數。2、將個推SDK集成到遠程監控端內。3、配置遠程監控端SDK參數。4、將個推服務器SDK集成到傳感器接收中，共同構成事務服務器。
將個推SDK集成到傳感器接收服務器中，其中要把host放到循環體外面，否則由於循環體賦值問題，程序會找不到host。推送的內容核心數據爲觸發時間，因此將本地時間轉換爲YYYY-MM-DD HH:MM:SS的格式上報到個推服務器。直接上傳字符串方式可以避免在遠程監控端將時間戳轉換爲本地時間的資源消耗。完成上述步驟後，使用傳感器採集端測試，將閾值調整到足夠小，保證輕微震動也可以觸發報警。在事務服務器控制檯觀察是否能夠觸發推送，以及推送的內容是否符合本文的預期。
sockethost, socketport = ‘0.0.0.0’, 52038
#設置監聽ip地址以及端口
listen_socket = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
listen_socket.bind((sockethost, socketport))
#綁定端口等
listen_socket.listen(1)
print(‘Serving HTTP on port %s …’ % socketport)
while True:
client_connection, client_address = listen_socket.accept()
request = client_connection.recv(1000)
print(request)
http_response = b"""
HTTP/1.1 200 OK\r\n
\r\n
“”"
#通過socket模擬http的響應頭
client_connection.send(http_response)
client_connection.close() pushMessageToApp(time.strftime(’%Y-%m-%d %H:%M:%S’,time.localtime(time.time())),“檢測有門窗震動！”)
#將門窗震動信息發送出去
time.sleep(15)#傳感器採集端不做濾波處理，此處在傳感器服務器中延遲一定時間，防止反覆觸發。
圖 5 1 事務服務器控制檯
5.2 流媒體服務器
視頻流服務器模塊的系統爲centos7，centos系列被廣泛採用做服務器，centos系統和配套軟件穩定，保證長時間運行不會宕機。流媒體服務器需要構建web頁面，web常見的有httpd和nginx，nginx開源而且支持二次開發，因此使用業界最常用的nginx做web服務。Nginx開源特性使得它具有很多module，流媒體方面有nginx-rtmp-module，將nginx源碼和nginx-rtmp-modules源碼下載到nginx服務器上進行編譯安裝。
安裝完成後會在對應的目錄下生成conf文件夾，對conf下的配置文件nginx.conf進行修改。由於本地服務器的資源有限，本文設置視頻留存時間長度爲3600s（可根據要求修改），fragment爲30s，支持live和hls兩種直播點播方式，命名方式是根據時間戳命名。具體配置信息見下：
表 5 1 流媒體服務器配置參數表
配置名稱 設置方法 參數 備註
監聽端口 Listen 1935 監聽的端口注意要在防火牆或者ACL中放行此端口
數據塊大小 chunk_size 4000 默認數據塊大小爲4000
切片命名 hls_fragment_naming system 使用系統時間戳來給文件命名
視頻存放路徑 hls_path /usr/local/html/hls 視頻流存放地址此處注意權限
切片時長 hls_fragment 30s 每個視頻時長爲30秒
存儲時長 hls_playlist_length 3600s 總共可以回看的事件，此處設置的是1小時
在接收到視頻採集客戶端發來數據的同時，流媒體會根據實際的數據生成一個web頁面，本文可以在web頁面中看到文件的具體情況，當然也可以通過Linux服務器內部儲存數據的掛載點來觀看兩者均可，通過web方式觀看的話會更加便捷，通過刷新頁面可以得到最新的視頻流數據。Index也是根據實際的數據生成的。訪問192.168.1.116/hls/aaaa會得到如下圖5-3所示數據，使用時間戳命名，後面爲塊大小。
以服務器系統本地時間戳命名的視頻片段，其中服務器本地時間採用NTP對時系統進行校正，保證視頻命名精度[13,21-23]。
圖 5 2 流媒體服務器數據
5.3 本章小結
本章介紹了兩個服務器平臺，分別爲事務服務器以及流媒體服務器，事務服務器主要介紹瞭如何將傳感器信息接收過來並處理，然後發送到個推服務器上面。後面進行流媒體服務器介紹，採用了什麼樣的流媒體方案，如何將流媒體儲存在服務器上面等等。
第 6 章 結 論
本文對基於移動智能終端的家庭安防系統進行了研究，充分利用了移動智能終端的傳感器、攝像頭、CPU、網絡通訊模塊等硬件模塊，完成了三個客戶端和兩臺服務器設計。實現了對家中情況實時監控；實現了視頻的雲端存儲，保證了數據的安全不被破壞；實現了對已有視頻的點播，方便隨時回看指定時間點視頻；實現了遠程報警消息推送。通過對客戶端和服務器平臺的不斷測試，讓客戶端以及服務器端的穩定性不斷增強，達到了實用性要求。本論文主要貢獻如下：
通過實地對開關門時候的加速度傳感器變化測量，得出手機自帶的加速度傳感器能夠充分滿足本文對於開關門振動的檢測的可行性分析，並給出了一套完整的從測量到上報到服務器的編碼實現。
視頻採集方面，通過對sopcast-SDK參數設進行設置，實現視頻從底層YUV編碼到mp4編碼的轉換，並通過多線程的方式將視頻傳輸到遠程rtmp服務器。上傳過程中可根據網絡阻塞情況實時調整分辨率，減少帶寬佔用，保證視頻不間斷上傳到流媒體服務器並完成存儲。
視頻播放分爲三個方面分別爲：視頻直播、視頻點播、遠程報警。視頻直播：通過利用vitamio實現對遠端視頻的解碼處理並播放；視頻點播：通過http獲取視頻索引文件index.m3u8，使用多線程異步繪製遠程監控端UI，調用gridview控件，將所有的視頻顯示出來；遠程報警：實現了消息推送，打通了傳感器採集端、視頻採集客戶端、遠程監控端、事務服務器（傳感器數據接收）、流媒體服務器並給出了一套完整的家庭安防系統解決方案。
致 謝
一路走來有諸多的恩師良友傾盡全力幫助我，僅以此章以示感謝！
感謝我的指導老師殷成鳳女士！18年的時候就開始跟隨殷成鳳老師做SRTP，殷老師對我和同學們的諄諄教導依然歷歷在目。本次畢業設計從選題，到方案的選擇殷老師都給予了我很大的幫助。剛開始接觸本文有很多的想法的，但在確定題目技術方案的時候都被殷老師否決掉了，感謝殷老師及時糾正我不成熟的想法。在實際開始編碼工作中發現很多東西不想我想象的那麼簡單，如果按照我最初的想法來做這次畢設，由於很多技術點都不懂，大概率這次畢業設計根本就做不出來，所以再次感謝殷成鳳老師對我的指導，讓我少走了許多彎路，另今後可能去四川的機會就很少了，不知是否還有緣相見，僅此遙祝殷老師身體健康！
感謝西南交大信息化與網絡中心的全體老師！16年時候到信網處應聘，第一次見到了劉老師，在此感謝劉老師給了我進入信網處的機會，讓我看到這麼多優秀的學長學姐。在信網處除了擴展了自己的視野，也慢慢的瞭解了一些哲理。呂老師給開會時“同樣的資源，交給不同的人來做，可能就是兩種完全不同的效果”這句話讓我最爲印象深刻。現在回想起來自己在信網處碌碌無爲，安排的任務時常不知從何下手，不知靜心反省，反而浮躁之心日盛，實在是有愧於帶我的諸位老師。
感謝西南交通大學信息科學技術學院！雖於學院直接接觸不多，但每次有急事需要找學院，學院各部門老師都會想盡辦法幫助，護犢之情溢於言表。
2020將於諸位辭行，點滴恩情皆化爲甘露滋潤於心，僅以此謝遙祝恩師、舊友安貞之吉，應地無疆。
參考文獻
[1] 林露. 智能安防的感知和識別關鍵技術研究[D]. 博士論文. 浙江大學, 2019.
[2] 王羣. 車聯網的安全機制及關鍵技術研究[D]. 博士論文. 南京理工大學, 2016.
[3] IDC. 2018年中國家庭安全監控市場出貨量達1338萬臺[EB/OL]. http://www.qianjia.com/html/2019-05/16_336983.html, 2019-5-16.
[4] 於洋. 基於安卓系統的實驗課程管理系統設計與實現[D]. 碩士論文. 電子科技大學, 2014.
[5] 禤文昊. 東莞村鎮非正規租賃住房研究[D]. 博士論文. 清華大學, 2012.
[6] CSDN. Android四大組件[EB/OL]. https://blog.csdn.net/weixin_39399984/article/details/79249079, 2018-02.
[7] 黃卓勳. 基於安卓手機傳感器和定位的健身軟件設計[D]. 碩士論文. 武漢郵電科學研究院, 2017.
[8] 孔菁. 基於智能手機傳感器的行爲與身份識別研究[D]. 碩士論文. 戰略支援部隊信息工程大學.2018.
[9] 百度百科. SopCast[EB/OL]. https://baike.baidu.com/item/SopCast/10347733?fr=aladdin, 2020.
[10] CSDN. 搭建Nginx+nginx-rtmp-module的hls流媒體服務器並用OBS進行推流[EB/OL]. https://blog.csdn.net/Ricardo18/article/details/89359623, 2019-04-17.
[11] CSDN. HLS協議解析[EB/OL]. https://www.cnblogs.com/jimodetiantang/p/9133564.html, 2018-06-04.
[12] CSDN. Android開發之Vitamio使用之如何直播RTMP流､m3u8流(HLS)､RTSP流和 MMS流[EB/OL]. https://blog.csdn.net/zanelove/article/details/45957793, 2015-05-24.
[13] CSDN. 視頻直播點播nginx-rtmp開發手冊中文版[EB/OL]. https://www.cnblogs.com/zx-admin/p/5783523.html, 2016-08-19.
[14] CSDN. Android開發基於RTMP實現視頻直播[EB/OL]. https://blog.csdn.net/haoxuhong/article/details/86492396, 2019-01-15.
[15] 張印. 基於RTMP協議的流媒體系統的設計實現[D]. 碩士論文. 電子科技大學, 2015.
[16] 蔣維. 實時流媒體傳輸系統中關鍵技術的研究與實現[D]. 博士論文. 浙江工業大學, 2017.
[17] 祝城鑫. 移動互聯網視頻監控關鍵技術研究與實現[D]. 碩士論文. 北京郵電大學, 2015.
[18] 簡書. 如何實現Android消息推送[EB/OL]. https://www.jianshu.com/p/fce737cf2e46.2017-12-16.
[19] Alexander C. Rokohl, Marc Trester, Yongwei Guo, Werner Adler, Viktoria K. Jaeger, Niklas Loreck,Joel M. Mor,Keith R. Pine,Ludwig M. Heindl. Dry anophthalmic socket syndrome – Standardized clinical evaluation of symptoms and signs[J]. The Ocular Surface, 2020,18(3).
[20] N. Gupta,S. Agarwal. Advanced–PRF: Clinical evaluation in impacted mandibular third molar sockets[J]. Journal of Stomatology oral and Maxillofacial Surgery, 2020.
[21] 尚青青. 多場所多路高清視頻監控中心的設計與實現[D]. 碩士論文. 南京郵電大學,2013.
[22] 程瀅穎. 移動終端上視頻直播系統的研究與設計[D]. 碩士論文. 華東理工大學,2013.
[23] Remote Sensing. South Dakota State University Reports Findings in Remote Sensing (Development and Evaluation of a New Algorithm for Detecting 30 M Land Surface Phenology From Viirs and Hls Time Series)[J]. Journal of Mathematics, 2020.
附件下載:
http://chenlinlin.wang:520/video/Graduation%20Project.mp4
http://chenlinlin.wang:520/video/