Android研究笔记三-返回机制的不合理

用户使用手机的过程不一定总是一样。有时候我使用菜单作为途径，直来直去。也就是说，一条线来一条线去，中间没有任何分叉。比如我可能在连续十个点击之后到达我的功能点并且完成我的操作然后返回（也可能不返回。事实上，在大多数情况下操作完成以后的返回并没有意义）。有时候我把它当作程序处理，比如我先到第一层菜单并且从第一条做起，在这个过程里面我可能深入也可能不深入第一条的子菜单然后回到第一层菜单做这个菜单的第二条，然后第三条...依此类推。这样的做法就跟大多数程序差不多了-大多数程序都是顺序执行的（这个事实上是另一个话题中的重要内容： 顺序执行的程序都是演绎的所以都是依赖型程序即所有后面的语句都依赖前面的语句，最少是这样假设的--不然为什么要一句一句地执行而不是一起执行像很多数据流机一样？因为很多时候我对并存的几条语句并没有执行顺序要求。比如我收到一个请求后要做三件事：A，B，C。但是这件事之间却没有任何联系，我要求的是这三件事都得到完成，仅此而已。但在冯诺依曼型的计算机中它们永远都是顺序执行的，除非你把它们放到不同的线程中去。这就是冯诺依曼的语句结构），但这并不是大多数的情况。所以说，这个地方的设计顾在偏差。

它的坏影响：

1，浪费内存。比如我虽然要经过一条菜单但只是作为途径导航性地经过一下，但是Android却把整个菜单存下来了。当然浪费内存；

2，非路径式而是调用式（顺序结构的特点）实现的坏处除了它是调用式以外，另一个特点即是它不是任何其它的东西，比如非路径式实现（菜单究竟跟程序有什么相似之处以致于Android要这样子实现呢？其实菜单跟程序并不是完全一样的，比如菜单列出来的东西有导航性但程序中保存的东西是堆栈即数据是执行结果。一个是指导性的东西，一个是存储性的东西，但从外面看的结果怎么会觉得它们这么相似？）。路径式实现的好处是，比如快捷键或Shortcut。

3，返回的另一个问题是在返回过程中看到的很多东西都是没有用的。也就是说系统做了无用的渲染。

4，菜单与程序相似的原因是菜单也是一种存储。程序的顺序性以及堆栈是由冯诺依曼系统的演绎性决定的也就是说程序从这种机制中得到了好处。好处就是演绎。因为演绎必须状态存储。但是菜单并不具有任何演绎性所以不能从中得到任何好处除了存储。所以还是那句话：为什么要保存过去的菜单？为了导航？如果是为了导航，为什么不允许向前“返回”？

从此可以看出，无论如何返回机制中都是程序思想在用户设计中的残留。即，被程序影响的设计或者说没有完全用户价值化的设计。是一个“技术”设计。