- tags: android
- date: 2015-12-17
我们知道一般 App 启动的时候都有一个过度页面，一方面可以在这个时候做 App 的初始化（比如 ImageLoader、推送服务等），另一方面可以通过启动页的图片达到宣传推广的目的。大概像这样：
当然，上面图片的弹跳效果不是今天讨论的重点。
为了到达宣传推广的目的，启动页使用的图片是会经常改变的，所以肯定不能内置在客户端 App 里每次发布新版本的时候才能更换。这个图片的加载应该由服务器从接口下发数据直接控制，与此同时，运营方面不仅需要可以动态调整启动加载图，更是对客户端这个图片的更换时间有着非常精准的要求；比如为了配合圣诞节、元旦等等等活动需要用户在改日凌晨更新这个启动加载图片。
如上所说，我们可以在用户打开 app 时向服务器请求一个 json 数据，其中包含了目标加载图片的 url 地址：
{
img:"url_of_img"
}
然后客户端下载这个图片，现实，并缓存到本地客户端文件系统。
但是这种情况下用户下载图片可能需要消耗很长时间在网络请求上，不能及时做出响应造成体验不好。为了使用户每次打开 app 时都能够达到一个相对顺畅的启动加载，我们对将要更新的图片在客户端做预缓存。
同样，用户打开 app 的时候向服务器请求一个 json 数据，其中需要有两个图片的 url 地址，客户端对把其中的一个图片作为启动引导图，同时将另外一张图片缓存进本地文件系统：
{
img_to_load:"url_of_img_to_load",
img_to_cache:"url_of_img_to_cache"
}
等到需要更新用户端图片的时刻将服务器返回 json 数据中 img_to_load 的值改为之前 img_to_cache 中已经加载过的图片地址。由于用户已经在更新加载图之前已经将图片缓存到了本地文件系统，相比再次网络文件传输会有很大的性能提升。
即使用户不幸在我们更新加载图之前并没有预先缓存新图片，那么用户还是可以通过网络加载到我们需要的新图，相比直接默认为网络传输，已经缩短了大部分用户的加载时间。至此，满足了定时更新加载图的需求，又不会因为加载图的更新导致用户首页加载过长。
这是一个相对保守的预加载方案，但是已经能够满足我们大多数用户的体验需求，如果想要预加载提供更广的用户覆盖率，我们仍有很多优化空间。比如提前推送预加载消息，然后在客户端响应。