创建一个关于该文档的树结构。使用DOM的好处是可以引用和操作每一个对象。但是为一个文档创建一个树结构,尤其当文档尺寸很大的时候,需要大量的内存空间。
3.2.2 SAX解析算法和其他解析算法的比较研究
(1)与DOM算法的比较。和DOM不同的是,SAX2是基于事件的,这意味着当它在一个XML文档中发现特殊的符号的时候,它会产生相关的事件。SAX2的优点是当它读到 XML文档中每一部分内容的时候,就会产生一个事件,我们的应用程序就可以在这个事件中写入具体的处理代码,然后解析器就移动到文档的下一段。因为 SAX2以序列的形式处理文档,它和DOM相比,对内存的需求很少。而且当SAX2找到需要的信息的时候,它能够停止对当前文档的解析。因为SAX不需要在内存中建立整个文档的树结构,SAX和DOM相比,可以被认为是一个轻量级的接口集合。
(2)与Pull 算法的比较。与DOM 解析算法相同的是,PULL算法也是基于节点的,即,在使用PULL解析XML时,解析器读入整个文档并构建一个驻留在内存的树结构(节点树),然后才可以使用PULL标准的接口来操作这个树结构。所以,同DOM一样,Pull解析式将内容读到内存中去,这样就消耗了系统的大量资源,而且给开发提取数据也造成了一定的麻烦。而SAX不需要在内存中建立整个文档的树结构,SAX和Pull相比,可以被认为是一个轻量级的接口集合。
由于此,在基于Google Android 移动平台技术的新闻阅读器的研究中,使用了SAX解析算法。
3.3 Google android 移动平台控件的研究
3.3.1 Google android系统控件与自定义控件的比较研究
在Google Android 中给出了非常多的绚丽的控件,但是在某些时候需要的实现某些功能的时候,系统的控件显得有些笨拙和难以控制,如,在本系统中,本打算使用系统自带的控件TabLayout 显示频道,但是现在的过程中,发现,该控件的每一个Tab之间有一定距离的间隔,且每一个Tab上面的图片很难控制其显示的方式和显示的效果,因此该综合美观和操作性的基础上,决定不用该控件来显示频道切换界面。而才用笔者自定义的控件--TabController ,此控件从需求上必须能弥补系统控件TabLayout 的不足,且能易于用户操作。
3.3.2 Google android 自定义控件的实现的研究
在Google Android 移动平台中,自定义控件都大致可以分成俩部分来走。第一,界面的实现;第二,功能的实现;第三,控件的调用。
(1) 界面的实现。在Google Android 平台中所有的控件都是继承了View这个超
类,所以在我们自定义一个控件的时候也需要继承这个超类,但是有些情况下不需要继承这个超类而是继承它的子类,如基于Google Android 平台的新闻阅读器中,就继承了这个超类的子类ViewGroup,即:public class TabController extends ViewGroup{}。基于此我们就得到了我们要实现的那个控件的最基本的那部分--界面的实现。
(2) 要实现一个控件,让其能产生特定的效果,我们需要自己来重写父类某些甚
至是全部的构造函数,如在基于Google Android 平台的新闻阅读器中,笔者就重写了
protected void onLayout(boolean changed, int l, int t, int r, int b) {
.........
}
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
..........
}
protected void onFinishInflate() {
............
}
等方法。在方法中实现所需的功能,这样一个自定义控件就好了。
(3)控件的调用。在Android 系统中,控件的调用非常的方便,如系统控件TextView,其调用方式如下:
TextView>
但是当使用自定义控件的时候,其调用方式就与其有很大的区别。在自定义控件中,其调用的形式是通过命名空间的形式来进行调用的。如,在基于Google Android 移动平台的新闻阅读器中,调用自定义控件的方式如下:
.......
>
com.baina.viewtools.TabController>
3.4 数据的持久化研究
3.4.1数据持久化的意义
持久化(Persistence),即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。持久化的主要应用是将内存中的数据存储在关系型的数据库中,当然也可以存储在磁盘文件中、XML数据文件中等等。
持久化是一种对象服务,就是把内存中的对象保存到外存中,让以后能够取回。需要实现至少3个接口:
void Save(object o) 把一个对象保存到外存中
Object Load(object oid) 通过对象标识从外存中取回对象
bool Exists(object oid) 检查外存中是否存在某个对象
为什么需要持久化服务呢?那是由于内存本身的缺陷引起的:
内存掉电后数据会丢失,但有一些对象是无论如何都不能丢失的,比如银行账号,遗憾的是,人们还无法保证内存永不掉电。内存过于昂贵,与硬盘、磁带、光盘等 外存相比,内存的价格要高2~3个数量级,而且维持成本也高,至少需要一直供电吧。所以即使对象不需要永久保存,也会因为内存的容量限制不能一直呆在内存 中,需要持久化来缓存到外存。
既然持久化服务在看得到的未来还有市场,如何构建一个好的持久化框架,框架是否真的好在于如何在扩展性、缩放性、重用性上取得良好的平衡:
扩展性,如果一个持久性框架不能支持用户定义的类型,显然不是一个好的框架。
缩放性,保存和取回对象都需要耗费cpu、带宽、时间资源,哪一个消耗太多都不能接受。
重用性是建立框架的初衷,就是通过框架能够减少一些编码和测试的工作量。
持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案,目前 主流的持久化方案是关系数据库方案,关系数据库方案不仅解决了并发的问题,更重要的是,关系 数据库还提供了持久化服务之外的价值:统计分析功能。刚才我说到,凡是可以序列化的对象都可以持久化,极端的说,我们可以只建立一个表 Object(OID,Bytes),但基本上没有人这么做,因为一旦这样,我们就失去了关系数据库额外的统计分析功能。
关系数据库和面向对象之间有一条鸿沟,因为两中模式不匹配,所以就存在一个OR(Object/Relations)映射问题。
3.4.2 Android 移动平台数据持久化的研究
在 Google Android 平台中,数据的持久化,官方提供了四种方法,分别为:1. SharePerfrence;2. Files;3. 数据库 4. 网络。
(1)Preferences从其保存数据的结构来分析,这是一个相对较轻量级的存储数据的方法。类似于我们常用的ini文件保存软件初始化设置,同样在Android平台常用于存储较简单的参数设置。例如,可以通过它保存上一次用户所作的修改或者自定义参数设定,当再次启动程序后依然保持原有的设置。通过Context.getSharedPreferences()方法来读写数值,这个方法通过设置name来使得同一个程序内的其它模块共享数据。如果不需要与其它模块共享数据,可以使用Activity.getPreferences()方法保持数据私有。需要着重强调一点,无法直接在多个程序间共享Preferences数据(不包括使用Content Providers)。
(2)Files。这是第二种方法,可以在
上一篇:中国智能手机市场发展前景预测报告
下一篇:记录文件6:基于IOS的易车新闻客户端