当页面的框架固定时，只需要加载框架内数据时，采用这种刷新样式，即先加载框架，再加载框架内的数据。为了反之框架内的内容为空，会用占位符或者预设图片来填充。

上面简单将六种常见的loading加载样式介绍了一下，样式虽然有六种，但是其实只有两种加载原理：一种是整体加载页面数据，加载完成后一次显示;第二种是先加载部分内容，再加载剩余内容(先加载文字再加载图片;先加载框架再加载框架内的数据)。

我常说的一句话是设计形式永远是服务于产品功能的，而产品功能则是为了满足用户需求。了解了这些loading加载的设计形式，进一步深度思考一下：这些形式是为了减少用户等待数据加载时的焦虑感。那么有没有更好的机制来降低用户等待时的焦虑感?当然有。

第一：优化App的加载算法，使得App与服务器交互数据的时间简短。这个需要开发人员的精益求精了。这个是从根本上解决了问题，因为直接减少了加载数据的时间，也就是减少了用户需要等待的时间。

第二：采用预加载机制。拿阅读App打比方，当用户在看第一页的时候，App在后台加载完后面的几页，等用户翻到第二页的时候就不需要等待加载了，因为App已经帮用户提前加载好了。这种加载机制对用户体验特别好，但是存在一个问题，就是要预测用户行为，加载其他数据，这样会消耗不少流量，所以建议在WiFi网络环境下采取这种预加载机制，而在蜂窝网络状态下则不采用预加载机制。这个要和开发人员讨论沟通，确保预加载机制完美运行。

第三：异步处理。这一点做得好的App莫过于Instagram，不知道你有没有发现，用Instagram的时候会觉得特别流畅，即使在网络不好的情况下。这是为什么?因为在网络不好的情况下，你给好友点了赞，Instagram并不会提示你网络不好，操作失败，而是提示你点赞成功了，其实将它只是将你点赞的操作记录了下来，等网络一好就将点赞的行为上传到服务器，从而完成点赞行为。这就是减少用户的操作负担，让产品自己去解决问题，而不是把问题抛给用户。

请记住，目前App常见的loading加载样式就这六种，当然还有其他的加载设计样式，但是这有什么关系?你已经掌握了产品加载的原理，真正理解了加载机制，这样你才可以不变应万变。