本文接上一篇「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压缩。
压缩应用是个持续工作。如果没有去持续关注,很可能一点点就挤压过大了。
#相关阅读#
#专栏作家#
唧唧歪歪PM,公众号:唧唧歪歪PM(ID:jjyypm),人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交App。
本文原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议