项目预览视频 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/