Update performance.md

docs/performance.md

 #### 运行原理
 
-``uni-app`` 在 App 端或小程序端运行时，从架构上分为逻辑层和视图层两个部分。逻辑层负责储存数据和执行业务逻辑，视图层负责页面渲染。
+1. 逻辑层和视图层分离，且非H5端通信有折损
+``uni-app`` 在非H5端运行时，从架构上分为逻辑层和视图层两个部分。逻辑层负责储存数据和执行业务逻辑，视图层负责页面渲染。
 
 页面加载时，联网和逻辑运算在逻辑层（Android是v8，iOS是jscore），然后会传递数据给视图层渲染。这种通信有损耗。同样，在视图层操作时，比如拖动页面，要实时传递事件给逻辑层接收，也是有损耗的。
 
+2. App端渲染引擎可切换
 在App端，nvue页面的视图层是由原生引擎渲染的，vue页面的视图层是os的webview渲染的。
+uni-app的webview渲染经过优化，性能也足够好。它比nvue弱的地方主要在于启动速度和可左右拖动的长列表。
 
+3. app-vue和小程序的数据更新，分页面级和组件级
+对于复杂页面，更新某个区域的数据时，需要把这个区域做成组件，这样更新数据时就只更新这个组件，否则会整个页面的数据更新，造成点击延迟卡顿。
+这就是自定义组件编译模式的特点。
+比如微博长列表页面，点击一个点赞图标，赞数要立即+1，此时这个点赞图标一定要做成组件。否则这个+1会引发页面级所有数据的更新。
+app-nvue和h5不存在此问题。造成差异的原因是小程序目前只提供了组件差量更新的机制，不能自动计算所有页面差量。
 
 #### 优化建议
 
@@ -52,7 +60,7 @@
 
 **优化页面切换动画**
 
-* 页面初始化时若存在大量图片渲染和大量数据通讯，很有可能造成页面切换卡顿、掉帧。建议延时100ms~300ms渲染图片，分批进行数据通讯，以减少一次性渲染的节点数量。
+* 页面初始化时若存在大量图片或原生组件渲染和大量数据通讯，会发生新页面渲染和窗体进入动画抢资源，造成页面切换卡顿、掉帧。建议延时100ms~300ms渲染图片或复杂原生组件，分批进行数据通讯，以减少一次性渲染的节点数量。
 * App端动画效果可以自定义。popin/popout的双窗体联动挤压动画效果对资源的消耗更大，如果动画期间页面里在执行耗时的js，可能会造成动画掉帧。此时可以使用消耗资源更小的动画效果，比如slide-in-right/slide-out-right。
 
 **优化样式渲染速度**