数据分层处理益处多多

做了将近两个月的android应用开发，第一版已差不多结束了。作为一个新手，我感受比较深的就是开发中最重要的是逻辑设计。我觉得就语言而言，从应用的角度来将没什么感觉，就按照官方的demo照葫芦画瓢就可以了，不会的就google一下，没有觉得什么。当然实现这些实用的控件是非常了不起的，那些背后的设计模式是非常好的。暂时没有去深究。在很方便的使用这些控件的时候，我感受比较深的是如何把应用做得稳定，如何提高访问的速度，如何降低内存的占用，等等。

这些方面我比较深刻的映象是对于数据流程的处理。上学期看了一些书，学了这些设计方面的知识。在一开始设计的时候，我把数据分成了三层：界面、领域、数据源。Android本身已经很好的实现了MVC，界面都是通过xml来编辑的。在一个手机应用中领域层的功能比较小，因为没有太复杂的计算，所以，在我的应用中，实际上领域层并不是很明显。有的时候直接界面层访问数据源层运行还好一些。数据源层中，主要处理来自手机数据库，网络，手机本地文件的数据。原本我觉得这些都是一个层次的，没有对内部进行仔细的设计。没想到在后面对这一部分改了好几次，甚至在临近发布了，又进行了一次比较大的改进。

举一个例子，我的应用中有一个功能是照片的显示，我最初的流程是这样的：

这样的考虑是觉得数据库和网络是一个层次的，我觉得都可以理解为从外部读取数据。而且为了在第一时间将结果呈现出来，所以这样的设计都是在读取到数据后马上反映到界面上。结果这样产生了很不好的效果。比如因为实际上界面上显示的数据来自不同的地方，至少有数据库和网络，那么就要做判断。我是用gridview来显示图片的。由于来源不同，在显示的时候需要将得到的数据拼凑起来，如果要符合同统一的规律显示就更加困难了。在实际的操作中，GridView如果从网络读取数据，就得另外开线程。就又需要考虑将得到的图像和相应的ImageView配对起来。网上有很多这样做的，事先用一个arraylist把需要放图片的ImageView和对应的图片存到里面。用一个回调接口，等下载成功后把得到的图片显示到界面上。但不管哪个，都比较复杂。过一段时间之后，或者另外的人来看都会比较费劲。GridView在显示的时候，一个方格可能会刷新很多次，会调用很多次getView方法，如果是开线程，就会开好多其实是一个目的的线程。这里就又需要想办法来限制。Android的UI不是线程安全的，显示的任务只能交给主线程。这又要考虑线程之间的通信。读取网络很可能会出问题。线程又是不可控制的。所以这一切都会造成相册显示不稳定。

       后来我考虑了一下，做了一些改进：

这里其实是在数据源层内部也进行了明显的分层。现在数据库的数据来源只是网络，手机界面显示的数据只来自数据库。这样就可以解决很多的问题。因为手机界面的数据来源是单一的，所以就免去了很多的判断。并且很多的排序，筛选之类的工作都交给数据库完成，手机界面就只是负责显示的任务，减轻了很多的负担。从网络下载的图片数据不再直接显示到手机界面上，而是一律存储到数据库中。这就免去了主线程以外的线程来操控界面，省去了一些不稳定的因素。从网络下载图片放到软件启动的时候，这样用户打开相册的时候就可以直接从数据库读取图片，不用等待去网络下载，速度会更加快。而且专门有一个时间来从网络读图片就可以很方便的用线程池来维护这些下载图片的线程，使线程可控性更高。当这样清晰之后，可以节省很多代码，不容易出错，而且软件更加稳定。前两天看过一句话，我觉得很经典：“有两种设计方式，一种是把系统设计得足够复杂，以至于看不出明显的错误；另外一种是把系统设计得足够简单，以至于明显看不出错误。”深有体会啊。逻辑清楚简单的代码也容易让别人懂。

       这是一个我碰到的简单的例子，这些日子我体会了为什么设计模式很重要，好的设计思想可以把复杂的事情变得简单，简单的流程意味着可以做出更加强大的系统。好的设计思想使系统简洁，容易维护。简单的容易维护四个字后面意味着可以容易扩展，可以节约很多的成本。可以有更长的生命周期，所带来的价值太大了。这是我现在才体会到的。

       今天看了Mark Little的一篇文章，深有启发。所以决定在急着去学习下一个热门技术之前。好好总结一下这些平淡无奇但是实用的思路，经验。因为很多时候，直接提高一个系统的性能的往往不是尖端的技术，而是这些平常的但是久经考验的知识。由此，有勇气把这个简单的总结写了下来。