精华内容
下载资源
问答
  • 关于上报方案的报告
    2021-09-14 14:31:25

    网络舆情上报同网络舆情报送,是将监测舆情汇报给相关领导或责任人的过程。

    一、快速上报监测舆情信息的重要性
    1.往上便于上级领导及相关责任人快速掌握舆情,及时制定应对方案;
    2.往下便于舆情工作者有序执行舆情工作,快速引导舆情,阻止舆情的持续发酵;
    3.在舆情应对过程中,有助于实时了解舆情处理动态,把控危机公关的实施效果,便于舆情应对策略的优化调整;
    4.此外也有助于掌握舆情的后续发展,防止次生舆情等的滋生。

    二、快速上报监测舆情信息的流程
    大致可分成三个步骤进行。首先,需要从海量的网络舆情信息中发现、获取、筛选和整理提炼与己相关的舆情信息。其次,根据舆情的重要等级【可分为轻舆情(Ⅳ级,非常态)、中度舆情(Ⅲ级,警示级)、重舆情(Ⅱ级,危险级)和特重舆情(Ⅰ级,极度危险级)四个等级)】决定舆情报送的时间。最后,则是向舆情接收对象报送。

    三、快速上报监测舆情信息的辅助工具
    为了及时地将舆情进行上报,因此,舆情的时效性就变得很关键。在过去,也许没有专业的舆情监测平台工具,只能靠人工手动检索信息,不仅速度慢不说,还很容易漏报或报错舆情。

    而为了彻底解决这一现状,弥补人工的不足,专业的大数据舆情监测平台工具应运而生。以识微商情监测系统为例,可完成对全网和指定网站/媒体的互联网公开信息的7*24小时实时监测分析,重点关注信息自动精准识别(负面/敏感/突发等等),舆情全面综合分析,分析图表、简报自动生成,并支持短信、邮件、客户端、微信等多样化的自动化舆情报送方式,报送延迟最快可在30秒内,极大地提高了快速上报监测舆情的效率。

    更多相关内容
  • 集团 ERP 方案报告 XX集团 ERP 方案报告 制药三厂 ERP 应用解决方案 XX 软件有限公司 前 言 首先感谢哈药集团给予我们这个机会能够作为候选厂商之一参与贵集团公司的 ERP 应用调研工作为了最大限度地保证项目的...
  • 数据采集停留在手工作业阶段业务员通过纸质表格电话甚至是短信方式将采集到的业务数据上报主管逐级上报的操作模式经常导致销售信息反馈慢信息失真现象严重 外勤业务人员的考勤和管控容易形成管理真空促销资源和销售...
  • [Windows]_[中级]_[崩溃报告的高级解决方案] http://blog.csdn.net/infoworld/article/details/53958736
  • 5、所有水电专业需剔凿、返工处理时,必须已书面报告通知总包,经批准后,方可处理。 6、所有水电专业在已施工完墙顶面层腻子或涂料的房间上面板时,应戴干净手套施工。 7、进入已施工完楼面的房间时,所有梯子、小...
  • 制造行业日报:昆山华恒携手江苏移动、华为推5G AGV解决方案.pdf
  • 本文以一个简单的手机APP远程空气质量监测应用为例,将教会大家如何使用STM32CubeMX图形化配置工具生成MCU工程,然后只需编写几个简单的接口,即可将机智云自助生成的STM32方案工程里面的设备协议移植过来,99%图形...
  • ②在开工之前,我们将查明施工区域内原有地下管线的埋设情况,并以书面报告的形式提出具体的解决办法,报请监理工程师批准后方可开工。对管道施工所经路线的障碍物进行初步清除,为以后的测量放线定位工序提供较好...
  • 5)在割接过程中发生问题时,应及时与用户工程师进行沟通,快速解决问题,存在分 歧的上报负责人。 (二)线路维护中心职责: 1)负责割接方案的审核,指导施工队做好割接准备,并进行割接管控 2)负责协中建鸿泰...
  • 不良事件上报系统

    2022-08-11 14:02:02
    风险评估功能要包括评估表管理、风险评估、...★上报的事件要具有事件编号、上报人、上报时间、报告状态等内容,并支持相应事件处理的时间轴,时间轴要能清晰地显示事件上报的时间、上报人、审核人等各种操作记录;...

    功能要求:
    1. ★要求系统具有内部公告功能(如当前待处理事件),要能支持内容公告的发布和提示信息,可以自动弹出公告,具有即时消息提示功能,支持制度和流程图的定义和显示;
    2. ★系统要具有强大灵活的接口工具,能够与医院现有相关系统紧密无缝接结合,患者不良事件的信息能够从医院HIS、病案管理系统中自动调取;
    3. 要求系统要能够保证数据的安全性,要具有数据备份和数据还原的功能;
    4. 系统要具有开放性,具备良好的输入输出接口,可为医院的HIS等数据提供接口,同时要能够满足部分功能的定制开发,能够实现与医院其他系统进行联合使用;
    5. 系统首页要显示出医院各类事件比例图、每月事件上报例数图、全院各科室上报例数、全院各类事件发生例数等;
    6. 具备事件上报、事件处理、风险评估、统计分析以及系统设置模块;
    7. ★事件上报模块要具有医疗、护理、药品、跌倒坠床、压疮、院感、输血、管道滑落、给药缺陷、治安、后勤等多方面的不良事件上报,且上报项及内容可根据医院的要求自定义设置;
    8. 各事件上报时患者的基本信息要能够通过住院号、门诊号进行查询,并支持自行录入患者信息;
    9. 医疗不良事件的上报要能够填写事件基本信息、事件经过、事件详细信息、事件的等级、原因分析以及整改措施等内容;
    10.    护理不良事件要能够记录不良事件基本信息、不良事件陈述、不良事件处理、原因分析和整改措施等内容;
    11.    ★上报的事件要具有事件编号、上报人、上报时间、报告状态等内容,并支持相应事件处理的时间轴,时间轴要能清晰地显示事件上报的时间、上报人、审核人等各种操作记录;
    12.    事件处理要包括各类事件处理和审核信息管理,事件处理模块能够根据事件类型、事件编号、患者姓名、发生科室等对事件进行查询和导出操作;
    13.    审核信息管理模块必须以事件编号作为唯一的查询条件进行查询浏览,能够查询出上报事件所经经过的流程名称、当前流程处理部门、事件每个流程处理的时间和事件信息描述等信息;
    14.    风险评估功能要包括评估表管理、风险评估、风险评估查询、待评估列表、评估历史打印,要能够根据患者的基本情况进行预设评估,每一个风险评估具有评分值,可以根据评分值的高低对不良事件进行规避;
    15.    风险评估表管理模块要能够根据事件类型对风险评估表的评分项、预防措施、评估等级等内容进行管理;
    16.    系统要具有统计分析功能,可以针对不良事件的类别、上报时间、发生科室、级别、处理响应时间等进行等级分析;
    17.    ★不良事件的统计分析可以按年度、季度、月度以及时间区间进行查询,具有事件比例图形,且统计的事件类型及例数可以进行钻取;
    18.    事件处理响应时间统计功能支持根据上报时间、事件类型进行查询统计
    19.    系统要具有灵活性,要能够根据需求灵活的设置界面,提供个性化自定义界面修改功能,满足医院移动、关闭、调整等界面上的任一项,使操作简便,提高录入速度;
    20.    能够支持不良事件类别的自定义修改,提交时间和上报事件分开;
    ★系统要求系统具有系统设置模块,可以对科室管理、用户管理、公告管理,页面设置、参数设置、审核信息设置以及处理反馈,可以方便快速的对系统进行维护。

    展开全文
  • 和计算口径不统一,各部门上报的数据不一致、不及时,导致过程需要反复的数据复核; ③项目投资测算投入工作量大。 因此,要做好房地产开发项目投资收益管理,需要从企业认知、体系构建、业务支 撑和工具应用四个...
  • 本文主要介绍如何结合ODC理论分析客户上报的软件缺陷,从而找到当前开发测试流程当中存在的问题,提出改进方案,提高产品质量。Defect(软件缺陷)分析是软件开发和测试中一个重要的环节。传统的使用严重等级,重要...
  • 医院信息系统应急预案 一、网络故障应急预案 (一)对网络... 针对上述故障分类等级,处理方案如下: 一类故障——由信息部负责人上报医务部和院领导,由医务部组织协调恢复工作。 二类故障——由信息部工作人员上报
  • 为了满足人们日益增长的家庭安防需求,结合基本每家每户都有闲置的智能手机的现状,本文提出了一种基于移动智能端的家庭安防系统构造方案。系统充分利用了智能手机的传感器、摄像头、麦克风、闪光灯以及3G/4G/wifi等...

    项目预览视频 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公司从20世纪30年代开始拓展简单的防盗报警业务,逐渐发展成为一家举世闻名的联网报警服务商,建立了十分先进的联网报警服务平台。其业务以家庭安防为中心,涵盖安防摄像头、家庭自动化系统、身份防盗等多项业务,在统一平台上为用户提供安防设备和配套的解决方案。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/

    展开全文
  • 优秀范文 PAGE PAGE 1 ...一应急范围 医院所有计算机外围设备打印机刷卡器服务器网络设备电脑病毒感染停电 二报告程序及预案启动 1报告程序 如出现网络故障问题网管员应迅速排查问题解决不了的问题立即上报网络部请求
  • 2 被测系统任一性能指标达到预警值 中止压测,故障群通知,上报项目组 3 用户上报生产系统故障 中止压测,故障群通知,协助恢复 4 被测系统大量GC 中止压测,故障群通知,上报监控中心及项目组,协助恢复 5 监控发现...

    一、性能测试流程:

     

    1、压测申请

    注意点:

    • 申请提出时间:至少在期望压测时间前3天提出压测申请。
    • 期望压测执行人:经过性能测试培训并通过考试的测试人员。
    • 压测环境:选择“生产环境”,则走按生产环境压测规范来进行后续流程;选择其他环境,则以非生产环境压测规范来进行后续流程。
    • 生产压测必要条件:生产压测选择生产压测必要条件,具体”生产压测必要条件“章节
    • 其他参考性能指标:可以是默认的几项,也可是其他自定义项。
    • 环境机型:填写被测环境应用机型,非生产环境压测,填写生产环境及被测环境机型。生产环境压测可只填写生产环境机型。此处可通过“环境机型查询”,通过输入“应用ID”,来查找机型结果,找到匹配的内容,选择后即可自动填入环境机型栏。

    2、压测方案

    注意点:

    • 编写人:压测方案由压测执行人编写。
    • 环境配比结论:通过“性能测试关键指标估算方法”,得出生产与测试环境配比。
    • 待测项及预期性能指标:填写被测环境配比后的期望结果。
    • 测试用例:测试目的大致可分3种,1、是否达到期望指标;2、找到最佳性能点;3、找到性能拐点。
    • 测试场景,请描述清楚与所选压测类型匹配的测试场景。
      • 负载测试:测试场景并发数由低到高等比递增,达到或超越期望结果。
      • 稳定性测试:测试场景并发数按性能拐点80%的并发量持续运行12小时以上。

    3、方案评审

    注意点:

    • 生产环境评审
      • 组织人:压测执行人 
      • 参与方:被测应用产品负责人、开发架构师及下游相关方开发架构师、运维负责人、监控组、技术平台相关负责人、专职性能测试,压测执行人与评审专职性能测试不可为同一人)或测试架构师(可选)
      • 评审结果:参与方都需要签字确认,确保方案无误。
    • 非生产环境评审
      • 组织人:压测执行人
      • 参与方:被测应用产品负责人、开发架构师,下游相关方开发架构师(可选)、专职性能测试(压测执行人与评审专职性能测试不可为同一人)或测试架构师(可选)

    4、测试脚本开发

    (略)

    5、测试执行

    注意点:

    • 生产压测
      • 事前:提前一天在钉钉-故障处理保障群发通知告知压测协助方,周知其他各方,内容包括:压测内容、预定开始、结束时间、预估影响范围。
      • 事中:钉钉-故障处理保障群,通知开始压测。压测期间触发“异常中止标准”,则立即停止压测,在故障处理保障群通报异常,并协助恢复。
      • 事后:钉钉-故障处理保障群,通知结束压测或者中止压测。
    • 非生产压测
      • 事前:提前一天在钉钉-质量改进部群发通知周知各方,内容包括:压测内容、预定开始、结束时间、预估影响范围。
      • 事中:钉钉-部门群,通知开始压测。
      • 事后:钉钉-部门群,通知结束压测。

    6、结果分析

    注意点:

    • 测试的通过/不通过的标准:
      • 压测中任一性能指标不符合预期结果,则压测失败,并中止。
    • 准出标准:无P0P1P2 Bug。

    7、压测报告

    注意点:

    • 环境配比结论:实际压测时,生产与测试环境配比。
    • 测试目标:实际被测环境配比后的期望结果。
    • 测试结果:实际待测项是否测试结果。
    • 与报告一同提交的图形报表,用于佐证实际压测结果真实可靠
      • 时间/tps变化图
      • 时间/cpu变化图(或其他资源消耗图,按需提供)
      • 时间/并发数变化图

     

    8、报告评审

    注意点:

    • 评审人:专职性能测试人员(压测执行人与专职性能测试人员相同的,则由测试架构师评审)
    • 评审结果:不通过则重测。

    9、必压测接口判定

    满足某些条件则为必压测接口

    近一周工作日内接口峰值tps>=500

     

    二、性能测试关键指标估算方法

    估算方法前提条件计算公式
    2.8法B/S系统提供UV,PV、接口提供被调次数,考察时间长度

    并发数=uv*0.8/(8小时*0.2*3600秒)*3倍

    处理能力(tps)=pv*0.8/(8小时*0.2*3600秒)

    处理能力(tps)=被调次数*0.8/(8小时*0.2*3600秒)

    8小时中,80%的访问量集中在20%的时间里
    简单峰值法B/S系统提供UV,PV、接口提供被调次数,考察时间长度

    并发数=uv*0.9/((12-8)*3600秒)*3倍

    处理能力(tps)=pv*0.9/((12-8)*3600秒)

    处理能力(tps)=被调次数*0.9/((12-8)*3600秒)

    8~12点处理90%的访问量,其他时间处理10%的访问量
    并发数精算法平均每天访问用户数、一天内用户从登录到退出的平均时间、考察时间长度

    平均并发数=平均每天访问用户数*一天内用户从登录到退出的平均时间/考察时间长度

    并发数=平均并发数+3√平均并发数

    平均并发数=400*4/8=200

    并发数=200+3√200=242

     

    每天400个用户访问系统,平均时长4小时,访问时间段8小时内
    并发数估算法一系统最大在线用户数

    并发数 = 系统最大在线用户数*12%

    并发数 = 2000*12%=240

    系统最大在线用户数2000
    并发数估算法二处理能力(tps),平均响应时间

    并发数=处理能力(tps)*平均响应时间

    并发数=200*0.5=100

    tps:200trs/s

    平均响应时间:500ms

    性能比等比估算法

     
    测试环境,生产环境机型相同,数量不同,如应用为耗CPU类则认为生产环境、测试环境处理能力比例为 6:1生产环境、测试环境机型相同,内存,磁盘大小不同,数量比例6:1
    测试环境,生产环境机器CPU频率相同或差别不大,内核数不同,机器数量不同,如应用为耗CPU类则认为生产环境、测试环境处理能力比例 大于8:1测试环境,生产环境机器CPU频率相同或差别不大,内核数比例为2:8,内存,磁盘大小不同,机器数量比例1:2
    测试环境,生产环境机型相同,数量相同,内存大小不同,如应用为耗io类则认为生产环境、测试环境处理能力比例为 6:1生产环境、测试环境机型相同,内存数量比例6:1
    测试环境,生产环境机器CPU频率相同或差别不大,内核数不同,机器数量不同,内存大小不同,如应用为耗io类因为是耗io类,则忽略cpu差异,认为生产环境、测试环境处理能力比例为12:1测试环境,生产环境机器CPU频率相同或差别不大,内核数比例为2:4,内存数量比例是1:6,机器数量比例1:2

     

    三、性能测试checklist

    编号事项分类状态应用场景备注
    1服务器端和客户端必须在同一个局域网内环境类确认  
    2必须在有线网络情况下进行性能测试环境类确认  
    3要注意检查点的设置,确认脚本是否成功执行脚本工具类确认  
    4要考虑参数化和关联的资源消耗对性能的影响。脚本工具类确认  
    5运行性能测试时关闭日志功能,调试脚本时可以打开日志功能脚本工具类确认  
    6如果数据是会不断累加的,要考虑软件生命周期内可能的最大数据量环境类确认  
    7测试不通过,需提供相关日志及数据给开发协查脚本工具类确认  
    8性能测试必选期望指标,并发数、响应时间、处理能力(tps或qps)、成功率业务类确认  

     

    四、性能测试Bug级别定义

    级别名称定义
    P0紧急

    性能问题导致的系统崩溃/服务挂起

    关键路径性能测试不符合预期性能指标

    吞吐量占网络带宽的90%以上

    P1严重

    次要路径性能测试不符合预期性能指标

    关键页面加载速度不符合预期性能指标,严重影响用户体验

    小概率(小等于5%)P0bug

    耗CPU类型应用,CPU资源使用率长时间处于100%

    耗io类型应用,内存使用率长时间处于95%以上

    吞吐量占网络带宽的70%以上

    P2重要

    非必要路径性能测试不符合预期性能指标

    小概率(小等于5%)P1bug

    耗CPU类型应用,CPU资源使用率长时间处于95%以上

    耗io类型应用,内存使用率长时间处于90%以上

    吞吐量站网络带宽的50%以上

     

    五、预期性能参数

    系统类型参数单位备注
    B/S 页面UV(独立访客)位/天访问系统的一台电脑客户端为一个访客,同一天内相同的客户端只被计算一次
     PV(页面浏览量)次/天页面浏览量或点击量
     考察时长(访问量分布时长)小时例:访问量集中在工作时间,则按8小时计算
    接口类被调次数次/天一天内接口被调用次数合计值
     考察时长(访问量分布时长)小时被调接口访问量集中的被调时长
     UV(独立访客)位/天访问系统的一台电脑客户端为一个访客,同一天内相同的客户端只被计算一次

     

    六、生产压测异常中止标准

    编号中止条件对应措施 
    1被测系统及下游系统应用出现异常报错中止压测,故障群通知,上报监控中心及项目组,协助恢复 
    2被测系统任一性能指标达到预警值中止压测,故障群通知,上报项目组 
    3用户上报生产系统故障中止压测,故障群通知,协助恢复 
    4被测系统大量GC中止压测,故障群通知,上报监控中心及项目组,协助恢复 
    5监控发现数据库死锁、网络瓶颈、链接超时、线程池沾满不释放等异常告警中止压测,故障群通知,协助恢复 

     

    七、生产压测必要条件

    编号生产压测必要条件  
    1容量规划治理  
    2寻找链路瓶颈  
    3   

     

    展开全文
  • 手游SDK-数据上报

    2020-01-03 17:47:15
    数据上报可以分为运营统计数据上报 和 崩溃日志数据上报 一、运营统计数据上报 市面上也已经有很多第三方的统计服务了,比如友盟统计。 第三方统计服务的优点是:简单、方便、统计范围广。 缺点也很明显: 数据...
  • • LAN/WLAN捕包功能,提高了分析问题的协同效率,简化了疑难问题的上报程序 • 随着测试需求的增加,Versiv™ 测试平台将通过添加新的模块来扩展测试功能,即便是新手,有了它也可 以成为解决问题的能手 五、DTX...
  • 车网互联为您所想】 信息管理:车辆基础信息、保养信息、违章记录查询等; 行程管理:出车申请、车辆调度、油耗管理、里程管理等;...车辆位置数据持续上报,一旦发生非法移动、非法启动、行驶碰撞,系统自动报警;
  • 关于计算机安全检查的自查报告(网络版).doc》由会员分享,可免费在线阅读全文,更多与《关于计算机安全检查的自查报告(网络版)》相关文档资源请在帮帮文库(www.woc88.com)数亿文档库存里搜索。1、对照学校计算机...
  • 1、精品范文-关于计算机安全检查的自查报告_自查报告我校信息中心接到xx市学校计算机信息系统安全检查实施方案的通知后,学校领导班子十分重视,及时召集信息中心、微机组等科组负责人,按照文件要求,根据实施方案...
  • 捕获 flutter app的崩溃日志并上报

    千次阅读 2021-01-15 10:39:11
    这部份可以直接交给native崩溃收集sdk来处理,比如 firebase crashlytics、 bugly、xCrash 等等 reportError 堆栈上报 线上app 出现异常虽然捕获了,但只是打印出来是没办法解决问题,还需要把他上报到开发者能...
  • 关于LIS系统与HIS系统的接口方案

    千次阅读 2020-11-08 00:43:35
    7、 检验报告 是指验科室接受检验申请、完成样本检验、审核结果后,向临床科室发布的、包含检验结果的书面报告。 8、 电子检验报告 是指存放在计算机系统的检验报告,可以方便地查询出来供阅读、打印等。 9、 检验...
  • Flutter异常搜集和上报

    2021-09-17 19:50:19
    比如widget构建失败,又或是某个网络请求解析失败,所以针对flutter我们也需要有一套规则来捕捉异常,下面主要是介绍异常类型, 全局异常捕捉的三种方式、异常报告的几种形式, 在查看了Isolate,Future,FlutterError.on...
  • 应急响应实施方案

    千次阅读 2021-10-24 21:08:49
    应急响应实施方案 文章目录应急响应实施方案1 准备阶段(Preparation)1.1.1 ...输出:《准备工具清单》、《事件初步报告表》、《实施人员工作清单》[z1] 1.1.1 负责人准备内容 制定工作方案和计划; 提供人员和物质
  • 1证券代码:600579证券简称:ST黄海编号:2008—044青岛黄海橡胶股份有限公司关于规范运作自查自纠活动的整改报告本公司及董事会全体成员保证公告内容的真实、准确和完整,对公告的虚假记载、误导性陈述或者重大遗漏...
  • 服务器配置评估报告

    2021-08-08 08:44:22
    服务器配置评估报告 内容精选换一换为了对源端服务器进行迁移可行性评估以及为后续目的端服务器的选择和配置提供必要性数据,迁移Agent会收集源端服务器的相关信息并上报到主机迁移服务。收集的Windows操作系统的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,992
精华内容 3,996
热门标签
关键字:

关于上报方案的报告