以智能手机为代表的移动智能产品已辐射到世界的各个角落和专业领域. 依托于微电子技术和小型化传感器的迅速发展，移动智能设备具有的传感器种类已经在满足日常生活需求的基础之上，多出了众多特殊途径的针对性传感器. 智能设备具备的计算力和传感器感知能力在满足民众的日常生活需求之外，富余的大部分资源往往被浪费.

移动群智感知技术^[1-3]能够有效地利用群体闲余的感知能力，通过移动智能设备上各类传感器采集感知信息，将个体感知信息汇聚成群体大数据. 移动群智感知技术通过数据挖掘完成特定的环境感知任务，获取有效信息. 该技术的核心为“感知”. 移动群智感知技术是基于移动设备的感知能力，将拥有感知能力的个体当作移动群智感知网络中的节点，基本要素为感知信息，本质工作为数据感知和采集. 移动群智感知数据的方式^[4]分为2种：参与感知和机会感知. 参与感知是通过个体主观行动，由用户主动参与，如：拍照、录音等获取感知信息，得到的数据精度高；机会感知方法是不通过个体，移动智能设备自动进行感知获取数据的方式，用户的主观性干扰小，但数据精度无法保证且需要隐私保护机制.

近年来，移动群智感知应用逐渐兴起. Kim等^[5]提出的Creekwatch通过手机图片和手持检测类传感器对河流进行水质监测，虽然感知数据有图片、水质检测传感器类专业数据等，但应用是为河流污染与水质监测服务的. Dutta等^[6]提出通过图文数据收集3D城市需求的建筑物照片的PhotoCity应用. 现有移动群智感知相关的移动端应用面临的主要问题如下：1）感知数据源单一. 大多群智应用完成目标感知任务用到的感知数据类型多是图文+专业传感器感知数据的方式，智能设备丰富的传感器资源没有得到较好的使用. 2）感知任务类型单调. 在相关调研中，大多应用只面向某一个问题提供解决方法，如Mathur等^[7]提出的交通监测方法，通过公共设施感知，对道路拥挤路况进行监控，收集的感知数据利用率低.

本文应用设计和开发的目的是使用移动群智感知技术将闲置的计算力和感知资源汇集，完成传统感知器件所无法处理或须花费众多算力和时间才能解决的感知任务，突破了上文应用的局限性；使用不同任务模版对应多种类任务的方式，使得应用不局限于只解决单一类型的感知任务，而是能够针对多类型、多领域的感知任务，提供多种类感知问题的解决途径；针对传感器感知优化、冗余数据和感知数据无效利用的问题，创建SenseInfo封装类，整合传感器感知数据获取和SQLite数据库存储功能，实时采集传感数据，简化了数据获取和存储过程.

通过对出现的相关应用和移动群智应用现状研究分析，移动群智感知技术应用目前主要有如下3个类别：环境感知、公共设施感知和社会感知^[4].

在环境感知类别中，移动群智感知技术可以运用到收集空气质量^{[6, 8]}相关信息（PM2.5、污染物含量）、恶劣天气信息感知、有害排放物^[9]感知、噪音路段信息^[6]等. 具有特殊传感器的可通信设备收集目标信息，通过互联网或者近距离信息传递方式传输感知数据，完成移动环境感知任务. 道路交通情况感知是公共设施感知类别中常见的感知任务，一般用于检测车况检测、出行高峰期交通拥堵情况^[10-11]感知等. 此外，还有停车位^[7]、公共设施损坏情况检测等. 在社会感知中，常见的感知途径是通过社交网络，比如：微博、Twitter、Facebook、博客、微信朋友圈等完成感知任务. 普遍任务如下：热点事件^[12]的影响程度及舆论趋势感知，社交关系网络构建或者是通过在社交网络分享个性化事物，制定诸如美食推荐、健康生活建议或者旅游计划等. 移动群智应用的开发需要适合匹配移动群智技术的系统框架，Liu等^[13]提出新的CrowdOS操作系统，为移动群智应用平台提供了统一系统框架，构建了OS内核，提出了3个核心框架，分别是任务解析和分配框架（TRAF）、集成资源管理（IRM）和任务结果质量优化模块（TRO）.

国内移动群智感知应用还处于待发展阶段，目前常见的相关应用大多与兼职、众包相关，应用框架虽然以任务为核心，却缺乏移动群体感知技术的具现化功能. 例如：众宝、微差事等生活类应用. 众宝的功能框架尚未完善，用户体验感差. 微差事主要关注商品市场调研这些商业类任务，应用本身不与群智感知技术相关，因为推广力度不够，应用中的任务少且使用人数不多，基础任务数量少. 以上应用不具备让用户主动发布任务功能，存在的问题如下：不主动收集感知数据进行有效信息的挖掘，依靠现实社会中的事件进展情况对发布的任务进行是否完成的判定.

国外移动群智感知相关的应用发展迅速，完成了移动群智感知技术的成果转换，解决了如何在实际应用中对该技术运用的问题. 如：CreekWatch^[5]、Common Sense^[6]、EarPhone^[14]、PhotoCity^[15]等拥有移动群智感知技术核心，基于移动设备采集的感知数据对某问题进行研究. CreekWatch采用用户主动参与感知的方式，要求用户使用手持检测类传感器，对经过的河流的水质情况通过图片、文本描述和传感器数据完成水质研究的感知任务. Comman Sense是用于空气质量监测的应用，使用相关的空气质量传感器感知空气信息. 该类应用主题虽然是群智感知技术，但面向的感知任务类型过于单一. CreekWatch只仅仅针对河流水质情况进行完成，CommonSense发布的感知任务只与空气质量相关，EarPhone是对噪音路段进行感知并完成可视化. 他们挖掘的数据源只涉及到单类型传感器或图文信息，不能完整利用到移动设备中具备的所有传感资源.

本文提出普适综合性的移动群智感知平台应用，能够收集智能设备中全部类型的传感器感知数据，具备多领域、多类型的感知任务发布功能，能够针对不同种类的问题，提供感知任务的解决方法.

移动群智感知平台应用开发的程序架构设计使用了模型－视图－控制器（model-view-controller，MVC）架构思想^[16]. 显示各个页面用户（user interface，UI）界面，涵盖各类View组件的Layout布局文件视作为View视图，负责展现数据、显示各个业务逻辑处理结果、开放交互入口给用户. Model是实现应用业务逻辑的功能实体类，如实现数据存储的功能类，实现感知数据获取的Sensor类. Model层涵盖了所有耗时操作及算法实现，且将业务逻辑处理的数据结果返回给View—即对应的布局，通知显示数据的组件更新界面，达到响应用户操作的目的. 负责加载布局文件，初始化应用活动的Activity活动是Controller控制器. 它从View布局文件中获取可操作性的组件实例对象，并处理用户交互操作，获取用户的输入；根据不同的点击事件触发Model层对应的功能，将待处理的数据传递给Model. MVC框架设计如图1所示.

提出的移动群智感知平台应用使用MVC框架，能够将数据与业务逻辑处理、视图中分离，便于各层的独立更新和改进. 例如在更改业务逻辑时，不需要重写数据和视图层，只会涉及到实现业务逻辑的功能类的代码变更. 若出现个性化定制用户界面的需求，则只需要修改视图层布局文件的大部分操作，不会影响功能实现，达到高度解耦的目的.

移动群智感知平台应用功能分为5大功能模块：感知任务发布与接受、感知信息的获取、数据存储、发送网络请求以及个人账户管理，如图2所示.

感知任务发布与接受功能模块完成感知任务在移动群智感知平台中的流通. 用户发布感知任务需要填写感知任务相关的内容，如感知任务类型、主要任务内容、任务涉及的传感器或感知信息. 为了引导用户顺利完成感知任务发布，应用设计了任务模版选择功能，通过经典任务类型的划分，设立不同类型的模版对应不同类别的感知任务发布. 感知任务接受的前置步骤是能够让用户查看到任务的详情，接受的后续步骤是任务完成时进行的相关数据提交. 在完成的过程中，感知任务处于待完成状态，应用应能够提醒用户未完成的任务的状态以及更新感知任务相关的内容变动.

感知信息获取是完成移动群智感知平台应用核心功能的模块，主要涵盖的3个子功能模块为传感器数据获取、位置数据获取及Service后台服务. 感知数据获取功能需要取得Android系统给予的传感器服务，对智能设备拥有的传感器进行操作. 位置数据获取功能类似，通过位置服务能够获取对应的位置经纬度数据. Service后台服务让感知数据的获取转入后台进行，避免长时间的数据获取操作阻塞主进程的业务逻辑的实现，需要结合Serivce服务类实现.

数据存储功能模块是通过SQLite数据库实现，通过获取数据库管理服务，完成数据的写入以及相关数据库操作.

网络请求功能模块使用Retrofit网络请求开源框架完成，负责应用的数据上传，如：用户账户注册登录的网络请求发送、个人账户信息加载、任务列表刷新加载、感知任务和数据的提交、任务详情的获取、消息通知获取等. RecyclerView刷新功能是为列表数据加载设计的功能，本质是通过滑动事件触发retrofit发送网络请求. 它承担了应用大部分页面中的网络请求工作以及数据交互.

个人账户管理功能模块下有5个子功能模块，包含账户注册和账户登录功能. 登录账户后，程序应提供用户账户管理相关的功能入口. 根据本应用的需求，设立任务完成、发布记录历史查看功能，能够让用户检索自己曾经接受和发布的任务，同时允许用户更改个人信息资料. 任务完成、任务发布成功、接受任务的内容状态变更以及平台应用通知等反馈和通知信息设计了消息通知功能，让用户接收.

应用页面层次结构如图3所示. MainActivity是打开应用进入的第一个页面，根据框架设计，主活动是一个中心Controller；在页面层次架构方面，它负责根据用户不同的交互，将程序的最上层界面跳转到对应的二级页面或者完成切换一级页面的操作. 主页面设计了能够跳转到首页、任务发布、任务提醒、个人信息4个一级页面的交互界面. 这4个页面因功能独立、模块化而视作轻量级Activity，且在层次架构中同属一层次，能够视为同类页；使用Fragment片段化，交由MainActivity统一管理，根据用户交互创建和删除对应的功能页面，在主活动中设立底部导航栏（BottomNavigationView），提供不同Fragment的切换功能.

首页主要显示平台用户发布的感知任务，拥有计步功能的入口，允许用户点击查看具体任务、跳转到任务详情的二级页面. 任务发布页面能够跳转到任务模版内容二级页面. 任务提醒的一级页面是实现任务提醒功能的所在地. 个人信息页面能够跳转到实现个人账户管理功能的各个二级页面—个人资料编辑页面、用户登录页面、任务记录页、消息通知页面等.

实现传感器感知功能需要获取到系统提供的SensorManager传感器管理服务，通过SensorManager获取到设备支持的传感器类型，通过编程能够获得感知数据. 位置经纬度数据是通过LocationManager才能获取. 作为感知任务的核心组成部分，位置信息及传感器感知数据都是需要实时监控数据更新的对象. SensorEventListener中监听事件触发频率过高，最高能够1 s触发50 000次；目前普遍智能设备的传感器种类丰富，不同传感器的感知数据若不经过调整感知频率，重复数据检测则会产生大量的冗余，需要对从传感器传递的数据作一定的预处理和冗余划分，将有用信息写入到数据库.

该应用自定义了SenseInfo类，封装了传感器与位置数据的数据获取过程、数据筛选过程以及数据库写入工作，如图4所示. SenseInfo包含了SensorManager和LocationManager，整合了系统提供的传感器管理服务和位置信息管理服务；引入SQLite数据库的写入操作，将实现交互功能的代码和实现业务逻辑的代码分隔开，优化应用的功能结构，降低了耦合性. 应用将SenseInfo包装成应用架构中感知数据的来源，形成数据层，所有围绕感知数据的操作都放到该类中，便于引入不同的数据处理算法，提高感知数据的利用率和数据库写入速度、效率.

感知任务的发布页面入口位于第一页面层中，可以通过首页中的底部导航栏跳转.

感知任务模版类别如图5所示，分为图文收集、定时采集、问卷调查和实时监测4类. 图文收集类感知任务主要面向仅使用图片和文本数据类型便能够完成的感知任务，如日常生活类感知任务、路线规划类感知任务等. 定时采集类感知任务的主要特征为时间标记感知，通过设定时间间隔或者固定日期，让智能设备启动相应的传感器，上传获取的感知数据完成感知任务，常见类型有：长期的科学研究任务、不同时段的室外PM2.5检测任务、温度变化监测任务等. 问卷调查类感知任务主要使用问卷作为任务载体，主要数据类型为文本，一般用于市场调查、科学调研类任务. 实时监测类感知任务与定时检测类相反，通过不间断地获取传感器感知数据达到任务的最终完成目标，如医学监测感知类任务.

任务模版内包含辅助用户发布任务的过程引导，如步骤提示、填写内容指示. 模版内的基础内容有：感知任务类型、任务名称、截止时间、激励金、任务数量、传感数据类型和任务详细描述等填写栏. 根据任务类别，对应的任务模版会有不同的填写栏. 问卷调查类将拥有问题设立的选项，定时采集类能够设立感知时间间隔. 自定义任务模版类型能够允许任务发布者自定义删添任务相关的信息.

任务模版设计使得开发的移动群智平台应用能够容纳多领域多类型的感知任务. 通过4种类型的任务模版，完成了绝大多数感知任务的适配. 开放用户自定义任务模版功能，提高了平台内感知任务发布的自由度和拓展性，突破了如今大多群智应用只面向单一感知任务类型的局限.

MainActivity是应用程序的主进程与主界面的运行载体，也是移动群智感知平台应用框架中的MainController. 如图6所示，作为响应打开应用操作的主控制器，负责应用界面组件的初始化以及数据呈现，还控制启动2个提供功能服务的Model，即Fragment及Service. 主活动设立FragmentContainer，管理各个提供显式服务的Fragment. 这些Frament是功能设计的承载体，用以页面开发和功能展示. 如Fragment_publish为实现任务发布功能建立，在主控制器启动时进行参数初始化，通过FragmentTransaction添加到FragmentContainer中. MainActivity管理着首页、任务发布、任务提醒和4个个人一级页面的切换，通过底部导航栏和Fragment回退栈完成页面跳转. 随着应用启动而开启的传感器感知功能作为隐式服务，使用Service实现. MainActivity在开启感知服务的同时，会通过Service初始化SenseInfo类. 根据SenseInfo类的设计，MainActivity将开启传感器感知功能和感知数据的采集.

该应用创建List<Sensor>类，通过getSensor List（Sensor.TYPE_ALL）从SensorMana ger中获取到移动设备支持的传感器列表.

传感器感知数据不是通过sensor类获取，感知数据存储在SensorEvent类的value数组中，SensorEvent类是作为传感器事件监听器SensorEvent

Listener接口中onSensorChanged（）方法的参数出现. 传感器感知数据的获取过程如下：1）从系统服务中获取传感器服务，初始化SensorManager；2）从SensorManager中获取支持的传感器列表；3）自定义类实现SensorEvent Listener接口，在onSensorChanged（）方法中传递感知数据；4）利用SensorManager的register（）方法，给目标传感器绑定自定义的传感器事件监听器类.

本次应用开发中为目标智能设备所支持的所有传感器都注册了事件监听器，能够收集智能设备所有传感器类型的感知数据，完成了多类型多源数据的获取. 位置服务的获得方式与传感器管理服务类似，注册服务的参数变为“LOCATION_SERVICE”.

LocationManager提供多种获取位置信息的方法，getLastKnownLocation（String provider）可以获取上一次更新的Location类，requestLocationUpdates（）能够实时更新位置信息，方法参数需求LocationLisener类的监听器. 位置传感器provider有4种类型，如表1所示.

本次应用开发使用了GPS_PROVIDER，在使用位置服务时，需要在配置文件中添加获取位置权限的声明.

MainActivity需要伴随启动Service实现传感器感知功能. 使用Intent类，传达唤醒Service意图. Intent是Android设立协助应用间交互通讯或应用内部启动服务、传递数据信息的运行绑定机制. Intent按使用方式分为显示Intent和隐式Intent. 相比于隐式Intent在配置文件中配置Action和Category配置隐式的使用方法，本应用使用更直接的显示Intent启动Service：1）新建Intent（MainActivity，Service）；2）传递意图startService（Intent）.

Service是后台不可视服务，用户界面停留在Main Activity视图中. 在Main Activity生命周期中结束阶段，需要在onDestroy（）方法中使用stopService（Intent）方法停止Service的运行.

主活动使用底部导航栏Bottom Navigation View，实现跳转到首页、任务提醒、任务发布和个人账户管理页面的功能. 不同于ActionBar标题导航栏，底部导航栏是Android5.0以上官方提供的运用级封装组件类.

在主活动生命周期到达onCreate期间时，初始化Bottom NavigationView时需要赋值对应View组件的ID，通过context.findViewById（R.id）方法找到对应组件View，创建menu资源文件，设置对应的控件个数及相关参数. Bottom Navigation View最多只能设立5个控件，且在拥有3个及以上组件时默认使用方式下控件的名称会丢失，需要在BottomNavigationView的属性声明中添加：app：labelVisibilityMode="labeled".

主活动使用Fragment Container片段容器View作为4个主页面统一的管理类，初始化Fragment Container后，通过Fragment事务操作默认显示“首页”页面.

结合Bottom Navigation View声明绑定创建的事件监听器，将Transaction操作放到对应事件响应中，可以实现页面的切换功能.

4个一级页面共同使用Fragment实现. Fragment由Layout文件和内部逻辑的Class类共同完成创建. 依附于Activity存在的Fragment生命周期与Activity生命周期不同，所以创建FragmentContainer统一管理4个Fragment. Fragment初始化View组件过程与在Activity中的组件初始化过程类似，通过Context.findViewByID（R.id）方法完成，其中Context是fragment依附的Activity的上下文属性.

首页中使用图片轮转器ViewPager显示图片资讯，由GridView组件显示的其他子功能入口，如计步测量，由List列表组件显示的感知任务列表，用户能够点击具体项查看进入任务详情查看页面. ListView的实现在通过findViewById方法初始化组件后，加载List Item的内部组件布局文件；根据布局文件中拥有的View种类和数量设置定制的数据适配器，以此填充列表各个表项的数据. 考虑到如果出现用户不断刷新感知任务列表或者感知任务显示数量过多，因为每个Item都创建了view对象，占用大量设备内存，且创建对象操作mInflater.inflate.inflate（R.layout.item）属于耗时的IO操作，将会影响性能. 为了降低性能的影响，使用viewHolder重用机制.

Android系统提供了Recycler构件，不被显示的Item会被缓存到Recycler中重新形成一个缓存Item；ListView中的每个item显示都需要调用一次Adapter的getView（）方法，初始化各类view组件. 通过Recyler的使用，减少在大量加载Item的情景下智能设备的内存资源被大量使用，导致内存溢出.

对该应用进行压力测试，实验设计为应用加载10个、100个、1 000个感知任务时，对CPU占比、内存占用、交互响应时间3个性能指标进行监控和记录，重复完成4次测试. 性能测试使用Android Studio的profile性能分析器，对应用程序在实机上运行时的各项测试数据进行监控. 使用的测试机为华为荣耀8，处理器为麒麟950，运行内存为4.0 GB.

如表2~4所示，应用程序在处理大量感知任务显示时CPU占比与内存占用与少量感知任务显示时无明显差距，保持低消耗的能耗. 应用没有在处理显示大量感知任务的情况下出现内存溢出异常，程序能够流畅运行. 应用对用户操作的交互响应时间小于2 s.

本文主要围绕移动群智感知平台应用进行软件开发设计和实现，详细讲述了应用的框架设计及功能设计，在Android开发环境下完成平台应用的实现. 整体框架遵从MVC模式. 功能概要设计划分为5大模块：感知任务发布与接受、感知信息的获取、数据存储、发送网络请求以及个人账户管理. 感知任务的发布和接受、传感器信息获取为应用的核心功能. UI页面层次分为2层，第一层分为首页、任务发布、任务提醒和账户管理页面，第二层为次级功能页面，承载实现5大功能模块下的子功能. 根据应用的设计内容，使用Android构造组件、开发框架和技术完成应用. 使用Retrofit完成网络请求功能，使用SQLite完成数据的本地化存储. 通过SensorManager及LocaitonManager系统服务类获取传感器感知信息和位置信息，结合数据存储功能封装成SenseInfo类. 应用主活动实现后台感知服务，让应用能够不阻塞主程序的情况下完成感知信息的获取，使用FrgamentContainer容纳4个使用Fragment实现的一级页面，可以通过底部导航栏BottomNavigation切换. 任务发布功能通过任务模版页面完成，任务模版根据不同的感知任务类型，设立发布步骤提示引导用户完成感知任务的发布. 讲述了应用的开发和功能实现的过程，

本次应用开发工作有许多不足之处，需要在以后的工作和版本更新中改进. 应用系统框架目前仅是满足移动群智平台的基本使用需求，缺乏高层次的整体设计和拓展性设计. 应用目前只在Android系统上实现，应考虑到多平台多系统的拓展可行性. 用户界面虽然基本满足了功能实现的需求，但缺少Material Design材料设计理念. 在应用实现的过程中，应用功能模块的实现不是“最优解”，引入了冗余代码和不必要的内存消耗；在未来的更新中应该对应用功能实现的代码进行维护，增加鲁棒性.