20169205 项目进度三 文件资源管理器接口设计文档

20169205 项目进度三 文件资源管理器接口设计文档

文件资源浏览器系统架构设计

根据文件管理器的功能需求及开发和编译过程中所涉及Android系统层次的不同，文件管理器的实现可以分为两部分：基本功能部分，主要包括文件系统的显示、访问操作及其它一些辅助功能，通过界面与用户进行直接的交互。与Android自带的应用类似，该部分功能位于Android系统架构最上层应用层，同时依赖于系统应用程序框架层和系统库的支持；文件安全管理部分，基于Android内核虚拟文件系统及连接器相关机制，在Android系统内核层根据连接器框架新建文件系统监测连接器，对文件系统操作信息进行截获后通过连接器将消息发送给用户空间接收程序。接收程序可实现向下完成消息的接收与记录，向上提供文件监控开关控制接口，通过与内核文件监控过程及应用层基本功能部分的交互，把整个系统有机的联系了起来。从Android系统架构不同层次来看，文件理器架构如下图所示。
从图中可以看到，文件管理器基本功能部分运行在用户空间，安全管理部分主要存在于内核空间中。文件管理器所要实现的功能需求和对应的解决方案决定了两大部分在Android系统中所处的不同层次，论文将在下面分别对两部分的总体设计进行介绍，同时于下一节对文件管理器的开发编译环境进行说明。

文件管理器基本功能设计

Android鼓励弱耦合和组件的重用，官方建议开发者采用MVC的模式来开发应用层的app，Android的四大组件本质上就是为了实现嵌入式设备上的MVC架构的。
在Android中MVC思想具体体现如下：

• 视图层(view)：应用的界面部分，一般采用xml文件进行描述，开发的过程中可以在不影响其他部分的前提下随时对界面效果进行修改，使用的时候可以非常方便的引入。
• 控制层(controller)：主要是针对具体问题的操作，对数据业务逻辑进行处理，也可以理解为把一些数据层的操作进行组合。在Android中控制层的处理变得相对简单，一个活动可能包含多个界面，只需要将视图层界面的ID传递到setContentView()，就指定了以什么样的视图模型显示底层的数据。因为每个应用一般都要有多个活动组成，控制层还要处理众多活动之间的关系。不要在Android活动包含较多的代码，应该把具体的操作交付给model数据访问层处理，这样做的另外一个原因是Android中活动的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。
• 数据访问层(model)：负责对底层文件系统、网络数据等信息的直接访问，系统主要功能和核心操作都在该层进行处理。和视图层保持独立性。另外从Android上层应用开发的工程结构中也看得出Android MVC开发的设计思想。工程结构中res目录包含了drawable、layout、menu、values等项，存放工程所需的各类视图资源；src目录下的各个Activity活动文件配合工程的整体配置文件AndroidManifcst．xml充当了架构中的控制层，数据访问层文件需要开发人员根据实际情况进行核心操作的编写，同样位于src目录下供控制层文件调用。工程中引用的SDK库则是数据访问层的操作对象。

作为文件管理器的主体，其基本功能实现部分主要位于Android系统的应用层，同样适合采用MVC架构来开发。其开发架构示意图如下图所示。

文件资源管理器具体接口设计

(1) 视图层：负责界面窗口的设计，主要完成数据的显示及与用户的交互功能。

文件管理器设计由多个界面组成，包括文件浏览主界面、应用设置界面、文件搜索界面等。对于应用主界面的显示要求，我们可以采用Android ListView组件来完成。ListView是Android中较常用的界面设计方式，以列表的形式展示要显示的数据，如系统中的setting界面等都采用了ListView的方式来实现。每个ListView都与一个Adapter对应，该适配器起着把数据源映射到ListView上的中介作用。我们可以在程序中自定义ListView的适配器，在其中自定义列表项的布局及动态显示效果。
Android SDK也提供了AlertDialog类来供开发人员使用，对话框经常作为Activity的一部分来创建和显示，应用中可以使用对话框来完成用户的输入或操作确认工作，进一步丰富文件管理器的界面效果。在视图层，应用中会大量用到各种菜单，在合适的地方提供特定的选项供用户选择。在Android的界面设计中，可能用到的菜单有ContextMenu、OptionsMenu、SubMenu等。我们可以在菜单中提供对文件的复制，查询，排序，搜索等各种操作接口供用户使用。当然，在必要的情况下，也可以自定义一个“菜单"，如利用layout文件设计一个工具栏，使用户的操作更方便，高效。
(2) 控制层：控制界面的跳转及显示，控制文件系统访问操作的执行。根据视图层用户的操作指令调用不同的响应函数，控制不同活动之间的跳转。

对于同一个活动，在不同的操作状态下，其界面显示也将有所不同。在程序开发中，视图层和控制层之间的联系主要是自定义的菜单项或系统的回调函数。对于ListView列表界面来说，系统回调函数主要为包含ListView组件的活动ListActivity成员函数，如onCreateContextMenu、onlistitemclick、onKeyDown等。系统应用框架层的Activity Manager管理着活动的生命周期的循环及不同活动间的跳转，我们可以根据活动所处的不同状态，如开始、暂停、停止、结束等，灵活的进行应用的逻辑控制操作。文件管理器的搜索功能可以基于Android的搜索框架来实现。我们不必担心视图层搜索界面的处理，也不需要在数据访问层重新去开发一个搜索框架，只需要在控制层调用系统提供的搜索管理器接口，并执行应用程序发送的搜索请求，接着返回相应的搜索关键字即可。在控制层还要实现对文件监控信息的接收以及根据文件监控设计的接口来控制文件安全管理功能的打开和关闭。
(3) 数据访问层：负责具体文件系统访问操作的实现及应用相关数据的
存储。
在对底层文件系统的访问过程中，需要涉及到许多内核系统函数的调用。用户态下对文件操作的系统调用有两种方式：直接系统调用(system call)和库函数调用(1ibrary functions)。对于第一种调用方式，系统中维护了一个调用接口表，这个表实质上就是系统调用号与内核服务函数的对照表，用数组sys call table来表示。这个表的每个表项中存放着对应内核服务例程的指针，而该表项的下标就是该内核服务例程的系统调用号。在用户态的指令会以中断的形式跳转到内核去执行。对于第二种方式，用户态程序可以在自己的代码中通过引用系统提供的库函数来实现底层文件的访问，库函数内部的最终执行结果其实和第一种一样，也是通过调用接口表以中断的方式跳转到内核中。显然采用第一种方式可以提高应用的执行效率，但目前Android Dalvik虚拟机只支持由java编写的应用程序。谷歌发布的NDK当前版本还有很多局限，其并没有提供对应用程序生命周期的维护，也不提供对Android系统中大量系统事件的支持，对于作为应用程序交互接口的UI API也没有进行支持。即使用其他语言编写的程序，最终还需要通过JNI来调用。不过随着技术的不断发展，手机处理器的功能也越来越强大，双核cpu早已诞生，所以在关于文件访问的系统函数调用方面完全可以通过系统核心库中提供的java．io．File库来解决．在数据访问层还需要处理应用中的相关的数据存储问题。Android开发提供了四种数据存储方式，第一种是文件存储；第二种是SharedPreferences存储：第三种就是数据库SQLiteDatabase存储，第四种是Content Provider。文件存储即常说的文件(I／O)存储方法，常用于存储大数量的数据。SharedPreferences是以键值对的方式来存储应用程序的配置信息。SQLite数据库是Android平台上默认的数据库引擎，它的设计目的是嵌入式开发，而且占用的资源非常少，是一款轻量级数据库。Content Provider为存储和获取数据提供统一的接口，可以实现在不同的应用程序之间共享数据。通过对Android数据存储方式的使用可以满足数据库、应用参数、用户设置等数据存储问题。

如上所述，文件管理器基本功能的实现设计如下图所示。

阶段开发计划

时间	计划	任务成员	成果	完成状态
第十二周	完成数据结构和框架设计	20169205	项目详细计划文档	已完成
第十三周	底层公共模块开发与设计	20169202、20169204	接口设计文档	已完成
第十四周	逻辑功能模块设计与开发	20169205、20169207	功能说明文档	已完成
第十五周	测试与交付	20169221	用户使用文档	待完成