本文接上一篇「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；
提醒更新和商店更新的文案不同。提醒更新的更简洁，文案在后台配置。比如，要求最多显示6行（一行显示不完的自动换行，超行与换行符的换行无差别对待），超出6行的显示…
3. 推送消息通知更新
提醒更新前提是用户打开App，为避免用户长久不打开App，也可以通过发推送的方式提醒用户更新版本。
推送不能点击后直接跳入AppStore。其主要作用是提醒用户：最近我有很多好玩的新功能哦，快来瞅瞅吧。
24 热更新就那点事
热更新就是，通过一些技术手段，直接对线上App添加新功能或者修改bug，以避开上架审核造成的麻烦或不通过。该过程所用的技术手段就统称为热更新。
热更新时候，可以通知用户手动触发，比如王者荣耀。也可以不告诉用户，直接更新。无论代码是原生还是H5，理论上都可以进行热更新。
热更新可以理解为代码版本更新的一个细分手段，只下载缺失的那部分内容，文件对比后 重新合并，减少了下载量。
25 关于安装测试包
1. 正式包与测试包
测试App时候，可以使用正式包（生产包），也可以使用测试包，二者因连接两个不同环境的服务器而区别。
需要注意的是，这与是否连外网没必然关系，测试环境也可以连外网，供在公司之外测试。
有时候我们需要生产和测试环境切换来来排查问题，安卓的开发员通常会写一个开发者模式，这样安装一个APK包，就可以在测试版和正式版之间切换。
正式包与测试包通常是同一份代码，分别发布在不同的环境中。但需要注意， 两个版本可能不对称。比如1.1版本的代码只在正式服务器发布了，那么切换到测试服务器的时候代码是不一样的，功能就不一样了。
2. 安装版本
安装新版本的时候，安卓可以文件传输形式进行安装。但是苹果不能。苹果需要连手机线在特定环境下安装。当然也可以申请一个临时的小版本企业账户（百十来个人的上限），因为苹果管控比较严格。
新旧安装包安装时候，压缩包签名相同的会自动覆盖，这样更新之后账号依然在，类似热更新。但最好是先卸载旧的，避免可能的冲突。
26 APK压缩是最后一关
精简安装包大小对用户升级等待时间和流量消耗影响很大。在正式发布之前，会抽出一段时间，着重压缩安装包。
基本是从两个思路去减少APK体积的：减少代码的大小、减少资源的大小。
1. 减少代码的大小
比如，删除无用的代码逻辑，删除无用的产品逻辑，混淆代码，把一些代码做内联，把代码中的类名、方法名和变量名替换成更加短小的无意义名字，测试代码分离等。
2. 减少资源的大小
其原理就是找出里面较大的文件或数据库，进行压缩。比如封面图或字体大小，若压缩之后清晰度可以，那么就这么干了。
通常开发通过插件，对所有的图片进行遍历，自动压缩成webp，并删除原来的图片；很多png是不能进行webp化，那么可以进行tinypng压缩。
压缩应用是个持续工作。如果没有去持续关注，很可能一点点就挤压过大了。
#相关阅读#
App产品原型背后要交代的细节或要理解的原则（一）
App产品原型背后要交代的细节或要理解的原则（二）
App产品原型背后要交代的细节或要理解的原则（三）
App产品原型背后要交代的细节或要理解的原则（四）
App产品原型背后要交代的细节或要理解的原则（五）
