开发建议

1. 长列表应使用list，避免用scroll-view
   原因：scroll-view会一次性创建和渲染所有的子节点；孩子数量越多，首次渲染越慢。而list只会创建可见区域的孩子节点，首次渲染耗时较少。

2. list的子节点应避免使用动态class和动态id
   动态class和动态id就是类似 class="cls{{index}}"、id="{{item.id}}" 这种通过胡子语法赋值给class属性或id属性的写法
   原因：list的cell会被复用。当list滚动时，已经下屏的cell会根据类型被复用在新位置上，并刷新cell对象的属性数据和UI。由于class和id的更新会涉及到CSS规则集重新选择匹配和应用，并导致重新渲染，很容易导致严重的滑动卡顿。

3. 避免在 list 的 bindscroll 事件中做耗时操作
   原因：在list滑动的时候，稍许的延时就会看起来卡顿，所以应该避免在 bindscroll 中做耗时操作。例如：遍历DOM树、上报、耗时运算、变更class或者id、大量的数据操作等

4. list的数据建议预处理
   建议提供给list的数据就是明确的ViewModel，并严格的区分cellType，可以极大的优化list的性能。应该避免同一种cellType，由于数据的不同而增删子节点。
   原因：cell是被回收和复用的，如果在复用时cell内的子节点数量发生变化，会导致cell自身被重新测量和布局，会降低滑动流畅度。

5. 避免在list的cell内使用 vn:if，并且判断条件会随着索引不同而变化
   原因：list滑动时cell被复用，如果数据导致 vn:if 判断条件变化的话，会导致cell的子节点发生销毁和重建。子节点的创建是很耗时的操作，对滑动流畅度有极大的影响。

6. 避免在list里使用自定义组件，同时又在自定义组件中使用 vn.data.watch() 监听和加工数据
   原因：list的cell复用导致自定义组件会经常收到数据变更通知（每一次复用就会通知一次数据变更）。组件数据当前是 copy-on-write 的模式，加工数据会导致数据copy耗时操作。建议增加list的数据预处理，一次性处理好整个list和子节点的数据。（注：0.8版本开始支持组件数据双向穿透的方案，加工数据可以避免拷贝，这样可以把数据加工逻辑放在组件内部，优化开发体验）

7. 尽量减少view层级和数量，可以提高渲染性能

8. 尽量减少半透明、圆角、阴影、Border的使用量，尽量用图片替代，可以提高性能

9. 尽量减少半透明的使用量，可以提高渲染性能

10. 优化JSAPI的性能
    原因：所有JS逻辑都是在UI线程中运行，包括JSAPI。所以应尽量优化JSAPI的性能。另外，JSAPI的参数和返回值应尽量减少冗余数据，因为所有数据都需要经过序列化传递，冗余数据会导致性能浪费。

11. 尽量减少使用webpack、rollup等打包工具处理的JS入口文件数量
    原因：webpack会把所有的依赖模块源码都添加到JS入口文件里，会导致JS源代码变大导致加载变慢。建议使用一到两个JS文件包含所有的外部依赖（npm模块），让webpack仅处理这几个JS文件；而剩下的JS文件可以通过require这几个JS文件的方式引用外部模块。