一. 确认过眼神，是不想遇见的bug
如上三张图所示：
- 第一张是【还未刷新】的效果，即初始界面；
- 第二张是【正常刷新】效果，白色区域随着手指下拉而显示，这里设置了margin值，小球是从navbar下来的。
- 第三张图是【非正常跳动】效果，即初次进入界面时准备下拉刷新，但并未出现第二张的效果，而是猛然跳动一大块距离！令人费解！
起初笔者天真地以为是因为对Refresh和Scroller中第一个item设置的margin、padding值对其的影响，但是发现去掉之后仍存在这张异常效果，而且在官方例子上加上margin、padding值显示仍旧是正常的，故排除这张可能。
二. 搜索Weex相关资料，探索原因
1. 寻找线索
曾搜索发现有人称之现象为“抖动”，由于Weex相关资料过少，此处以“抖动”为关键字寻找思路，寻得错误原因有以下几处：
- Android - ScrollView抖动，焦点所致。
- mescroll的div里面会抖动，div元素属性是 fixed所致。
- IOS中UITableView下拉刷新上下/左右颤抖，contentOffset的变化过大导致
以上三种推理与笔者自身项目无太大关联，无法解决，下面两个讨论的方案稍有启发，笔者归其原因为“渲染位置尚未结束“所致，故建议限制界面组件的宽高。这确实是个新的思路，但笔者界面中有的块div宽高动态决定的，其原因仍不太清楚。
- weex 界面的侧滑、抖动问题，渲染原因
- Android - PullToRefreshListView抖动，问题出在onSizeChanged()的时候，它会重新测算header和footer的大小。然后刷新布局导致了页面的抖动。
2. 真相不远了
在淘宝技术专栏发布的一篇Weex实战分享|Weex在盛大游戏中的应用实践中确定了笔者的猜想，内容如下：
其次是注意scoller和list的使用。长列表一定要做懒加载，还要划分好cell颗粒度，嵌套不要太深。像我之前做单页，我都怀疑当时做单页是嵌套太深了，所以导致App偶尔出现Crush。嵌套一定要扁平一些，这时候就考验前端工程师的功底了。
性能优化这方面上午阿里同学已经讲过，我们首选list，还有未来的list性能会更好，我们好好期待吧！平时还要注意划分好Vue组件的颗粒度。
此篇分享文章中强调了list组建相比于scroller组件的高效率，重点则是第一张图片中对于这两个组件的渲染说明：
- Scroller：所有子组件一次性渲染；
- List：渲染可视区域子组件，子组件移出可视区域后内存收回；
3. 确定原因
基于Scroller和List的渲染机制理论支撑，暂且将原因归咎为Scroller的渲染问题，在标签没有写死宽高的情况下，需要子元素加载完才能计算出宽高，从而导致抖动问题。
笔者将出现抖动问题的界面代码中的scroller组件替换为List组件，除此之外没有改动任何代码，抖动问题解决！
三. 实践官方例子证实猜想，得出结论
在官方Scroller示例上加上Refresh组件运行测试，分分钟抖你没商量，但是在这个官方Refresh示例（搭配的也是Scroller组件）中却显示正常。
在对比两个例子并测试多个条件后，可得出以下结论：
在使用Scroller组件搭配Refresh，且以下两个条件并集（&&）时，下拉刷新会出现抖动现象！
- Scroller内展示内容超出屏幕长度；
- Scroller内展示内容中的宽高或者opacity属性被动态指定；
四. 解决办法
经过以上过程后，可根据结论得出以下几种解决办法：
（1）在Scroller内容超出屏幕长度取消动态指宽高、opacity
个人中心界面Scroller内展示的内容存在超出屏幕长度的可能，无法避免，且为了实现头部“渐变”效果无法取消动态opacity需求，且“我的服务”模块内容高度也是动态确定。因此次方案pass。
（2）Scroller组件换成强大的List组件
由于个人中心需求中存在“Scroller内展示内容超出屏幕长度”、“Scroller内展示内容中宽高或者opacity动态指定”这两个致命性需求，且Weex中Scroller组件内隐形的坑太多，不如简单粗暴使用List组件，比较高枕无忧。
weex坑里游～