App产品原型背后要交代的细节或要理解的原则（六）

22 「缓存」是整体性、系统性的工作

使用缓存，主要是提高性能和离线访问数据（用户需求或体验）。比如，缓存可以支持离线访问、支持用户离线操作、减少用户流量损耗、提升速度、节约访问服务器成本等。

其原理就是将加载过的内容存储下来（缓存），下次读取时，首先从缓存中查找，找到了则直接执行，找不到则再从内存中找。

1. 产品经理在处理缓存问题的三类场景

第一类，功能或性能上必须缓存。这种情况下无需产品经理强调，开发都会进行缓存处理的。

比如微信通讯录中用户的头像，在第一次加载的时候就全部拿到。之后刷新列表，都将基于前一次缓存的数据重新进行更新。

第二类，产品经理有目的地针对具体功能要求给予缓存。根据KANO模型，多是为了做出用户期望的或兴奋的效果。

比如，资讯阅读类App，用户第一次加载出的内容缓存下来。下次因网络太差无法加载数据时，可以看到老信息。

第三类，在产品功能基本完善的时候，将缓存作为一个系统整体机制来梳理和规范。这个时候产品经理做的是排查，然后以缓存作为方案进行补充完善。

产品经理要清楚一般App的缓存习惯，比如如下场景：

聊天记录（使用IM及时聊天SDK的情况下，往往本身就是保存了的）；

个人资料（用户自己在本地维护的，所以无需拉取服务器）；

自己创作的作品（原理同个人资料）；

草稿或编辑一半的内容（比如制作视频的规程中意外中断了操作，下次进入可以继续）；

支付明细，或其他操作记录。

其他。

以上，有的可能在开发的过程已经实现了。但最终产品经理要做一个核查和规范。

2. 缓存的数据到哪里了

缓存数据就是存在手机的文件夹路径中了。当然也可以存储在相册这样的地方。必要的时候产品经理要与开发定义。

总的来说，App缓存的位置分内部存储和外部存储两类（以前的手机的SD卡就是外部存储)。

内部存储里的文件默认是只能被指定的App访问的。卸载App的时候，里面的相关文件都清除干净。

外部存储并不总是可用的，往往需要请求授权，比如访问相册。当用户卸载App时，系统仅仅会删除其中相关的文件。

3. 缓存数据的清除

缓存本质就是拿内容换时间，因此缓存的内容会挤压存储空间，甚至拖累性能。通常自动清除，结合手动清除。

自动清理缓存的两个要素：设置缓存的上限、设置清理缓存的频率。

比如UCG的视频，App每次刷新可以加载10个，且不重复加载，那么就可以将每次加载的视频ID存储在手机中，下次加载做差异化扣减。但是显然这个量日积月累也够大的。所以可以设置为（比如）每周自动清除一次。

手动清除，比如微信的清除缓存。

手动和被动清除，都需要代码规定哪些可以清掉，哪些不能，这个在具体应用中要与开发约定。

23 「版本更新」的三种场景

版本更新，通常是通过应用市场、使用时提醒用户、离线时推送消息，这三种手段分别对应三种用户与App的场景。

1. 弹框更新提醒

版本发布到应用市场，市场就会判断后提醒用户更新（当然前提是用户得来到应用市场）。如果用户不来，就需要App内弹窗提醒更新。

打开应用时，通过弹窗的方式来告诉用户有新的版本了。好处在于用户使用产品时就能够看见，有针对性。不好的是打扰到用户了。

一种常见的机制是，设置两个版本号，一个开发版本号，另一个是显示给用户的用户版本号。每个App版本都有唯一的开发版本号，就像序列号一样唯一且严格。

而显示版本号是给用户看的，所以可以拟定，在用户打开应用时校验版本差别。

后台设置的参数有：开发版本号、显示版本号、更新内容、是否启用等。

还有一个看不见的规则：当新版本的【开发版本号】大于用户版本的【开发版本号】，则强制更新；否则，更新，但不强制。

举个例子：用户的App的当前显示版本号是V1.1.1，开发版本号是1.2.2。发布了更新，并在后台设置新版的显示版本号是V1.1.2，开发版本号是1.2.2，那么启动后，会弹框提醒，但是不强制用户更新。

2. 总结弹框更新提醒

每次打开App，都校验是否有新版本；若有，则校验是否属于强制更新。强制更新 则只能更新，或者退出应用；非强制更新可以不更，继续使用；

安卓往往从公司服务器下载（避免商城的不确定性），当然也可以像IOS一样跳往应用商店；

安卓受管制少，所以一般直接显示下载进度条，下载不能打断或暂停；下载完毕 toast提示，同时直接安装；安装完毕 toast提示，同时直接打开APP；