菜单导航

App产品原型背后要交代的细节或要理解的原则(六)(原创)

作者: 昌平信息网 发布时间: 2019年12月20日 08:12:33

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版本都有唯一的开发版本号,就像序列号一样唯一且严格。

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

App产品原型背后要交代的细节或要理解的原则(六)(原创)

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

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

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

2. 总结弹框更新提醒

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

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

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