正文  基础知识 > 生命周期/运行原理 >

Android: onSaveInstanceState与生命周期API的根本区别

生命周期的态度是这样的:在手机这样的弱能力终端上, 系统运行环境时刻是变化的, 而为了应付这种变化, 在每一次变化之前, 我都给你一次机会, 让你进行恰当的或者必要的处理 ,至于你能不能做到恰当的处理, ...

生命周期的态度是这样的:
 
在手机这样的弱能力终端上, 系统运行环境时刻是变化的, 而为了应付这种变化, 在每一次变化之前, 我都给你一次机会, 让你进行恰当的或者必要的处理 ,至于你能不能做到恰当的处理, 那就不是我力所能及的范围了. 但机会我已经给你了所以你看着办吧!
 
所以说, 生命周期API的存在是为了在为应用提供应付变化的能力同时最大化用户的体验价值. 也就是说, 通过对这些API的正确实现, 你可以做到几乎无缝的应用体验. 但是前提是这样的体验是分级的. 你可以分级别保存下来你认为最重要的或者是次重要的东西, 并且通过这么做最大化你的用户体验价值 , and this is ALL.
 
onSaveInstanceState是这样的:
 
它只有在stop的时候才会被调用. 而我们知道stop并不是总会被调用. 系统唯一保证会调用的函数是onPause, 所以它唯一或者说更多地倾向于要去维护的东西就只能是体验了. 或者说, 从一定的程度上说它所设计的出发点就是用户体验. 比如, 它所应付的唯一问题是什么呢? 无出进程销毁. 如果没有进程销毁这件事, 它就不可能存在. 它存在的唯一目的就是为了解决进程销毁的问题. 进程销毁导致很多问题, 而补偿它的一种办法便是状态保存(并且这种保存仍在内存中, 只不过在被销毁进程以外暂存一下它, 并没有持久化).
 
而内存能做的或者说其维护的更多的当然是用户体验而不是数据. 因为真正的数据大多需要持久存储, 需要跨越关机时间. 数据当然也是体验的一个部分或者说有体验的成分在里面, 但两者却绝对不是一样的东西.
 
另一个问题是, 用户程序与系统体验也不是同一个问题. ANDROID随意回收进程的结果是, 系统的可用性大大降低. 因为用户将面临不停的数据损失, 这个一方面是不好的体验, 另一方面对持久化数据也存在着影响. 后者虽然通过onPause接口得到解决, 但体验问题仍旧摆在那里. 而onPause的东西又并不一定会被回收, 甚至不一定会被"不可见", 在onPause的同时进行内存数据维护即体验维护显然将引入资源浪费, 根本原因还是在于两者并不是同一回事. 于是才有分开设计的两个接口.
 
这是演绎式程序不可避免的问题: 要么做A, 要么做B, 不可能同时做A又做B. 这个问题是由此类型系统本身的行为性决定的: 这种系统中, 行为即演绎是一切的基础. 所以行为必须区分得非常严格, 否则就可能导致不一样的结果. 那么这种系统就失去它的使用价值了.
 
关于冯诺依曼结构与数据流机的区别, 还是认为形式逻辑并不拥有对冯结构的分析能力.
 
冯结构的能力超出了现有逻辑理论, 或者说逻辑的讨论能力