1.背景
先说一下之前的开屏策略：
APP第一次冷启动默认加载一张默认的开屏图片，与此同时异步去下载要展示的图片内容，下载完成后进行磁盘缓存，APP第二次冷启动时检测到有磁盘缓存，加载缓存图片。
此策略存在的弊端:我们需要在特殊的日期内显示特定的开屏图片，但当前的机制下，会导致特殊节日已经过了，才显示此开屏图片，没有达到预期的效果。且在后续的品牌宣传规划中，开屏模块是一个很重要的宣传阵地，或许会承载宣传任务，因此须对此处显示规则进行调整，以期最大限度保证在该特定图片可在指定日期内显示。
2.策略
图1是主要流程，主要包括数据展示、数据请求、数据处理。
下面讲解一下具体思路：
我们把开屏页面看作是主题，分为生日特权主题、日主题、月主题、默认主题（从前到后优先级依次降低）。服务端提前配置好要展示的主题，APP每次启动先展示符合要求的主题并异步下载相应的主题缓存到本地，
2.1 主题展示逻辑：
图2主要展示的是根据主题优先级先判断用户是否是生日主题。
图3主要展示的是非生日主题情况下其他主题的处理逻辑。
具体逻辑描述：
APP冷启动判断用户是否已登录
已登录状态：
查询是用户否是生日期间，是则展示生日特权主题；不是则判断本地是否有缓存日主题，有则取出符合当前时间段的日主题并展示，没有则继续判断是否有月主题，有则取出符合当前时间段的月主题并展示，否则显示默认主题。未登录状态：
判断本地是否有缓存日主题，有则取出符合当前时间段的日主题并展示，没有则继续判断是否有月主题，有则取出符合当前时间段的月主题并展示，否则显示默认主题。
备注：关于当前时间获取：如果APP第一次安装一般都会有引导页，即第一次安装打开APP不会出现开屏页面，此时取服务器时间与系统时间作差值，差值存本地（每次启动APP都会更新该差值），再次冷启动APP时，服务器时间 = 时间差 + 手机系统时间。如果用户在此期间把手机时间给改了，用户第一次冷启动APP时，显示会有错误，再次冷启动时就正常了，无伤大雅。
时间差 = 服务器时间 - 手机系统时间
服务器时间 = 时间差 + 手机系统时间
2.2 数据结构：
json数据结构如下，日主题和月主题的时间先后顺序，服务端给定。
{
"dayLaunch" : [
{
"endDate" : "", // 结束时间
"imageUrl" : "",
"launchId" : "",
"startDate" : "", // 开始展示时间
"duration" : "" // 主题展示时间
}
],
"monthLaunch" : [
{
"endDate" : "",
"imageUrl" : "",
"launchId" : "",
"startDate" : "",
"duration" : ""
}
]
}
serverTime : 1533700611 // 服务器时间
2.3 数据处理：
图4主要展示了数据处理相关逻辑：
- 1、本地缓存数据删除：取本地缓存主题数据，通过launchId唯一标识删除服务器数据不包含的本地缓存主题。
- 2、服务器数据去重：去掉服务器中本地已缓存的数据。
- 3、服务器数据存储：每次只存储一个月主题和两个日主题数据（具体存储个数根据业务需要灵活调整）。
三、功能扩展
- 数据结构中可添加跳转连接，即广告跳转逻辑
四、意见收集
如果您有更好的改进策略请您多多指教
网友评论