皮皮网

Vue—关于响应式（二、异步更新队列原理分析）

       本节学习要点：Event Loop、Promise

       关于Event Loop的介绍，可以参考阮一峰老师的文章。

       关于Promise，请访问：developer.mozilla.org/z...

       上一节介绍了Vue通过Object.defineProperty拦截数据变化的响应式原理，数据变化后会触发notify方法来通知变更。这一节将继续分析，收到通知后Vue会开启一个异步更新队列。

       以下是两个问题：

       一、异步更新队列

       首先看一段代码演示。

       将上一节的代码拿过来，假设我们现在不仅依赖x，还有y、z，分别将x、y、z输出到页面上。我们现在依赖了x、y、z三个变量，那么我们应该把onXChange函数名改为watch，表示它可以监听变化，而不仅仅是监听一个x的变化。

       可以看到这三个值都被打印在页面上。

       现在我们对x、y、z的value进行修改。

       查看页面，结果没有问题，每个数据的变化都被监听到并且进行了响应。

       既然结果是对的，那我们的问题是什么？

       这个问题是：每次数据变化都进行了响应，每次都渲染了模板，如果数据变化了一百次、一千次呢？难道要重复渲染一百遍、一千遍吗？

       我们都知道频繁操作DOM会影响网页性能，涉及重排和重绘的知识感兴趣请阅读阮一峰老师的文章：ruanyifeng.com/blog/...

       因此，既要保证所有的依赖都准确更新，又要保证不能频繁渲染成为了首要问题。现在我们修改x.value、y.value、z.value都是同步通知依赖进行更新的，有没有一种机制可以等到我修改这些值之后再执行更新任务呢？

       这个答案是——异步。

       异步任务会等到同步任务清空后执行，借助这个特点和我们前面的分析，我们需要：

       按照步骤，我们创建如下代码：

       接着我们需要修改一下notify的代码，监听到数据变化后不立即调用依赖进行更新，而是将依赖添加到队列中。

       回到页面，我们发现页面上还是重复渲染了三次模板。

       那么我们写的这段代码有什么用呢？异步又体现在哪里呢？接着往下看。

       二、nextTick原理分析

       上面的代码中，虽然我们开启了一个队列，并且成功将任务推入队列中进行执行，但本质上还是同步推入和执行的。我们要让它变成异步队列。

       于是到了Promise发挥作用的时候了。关于宏任务和微任务的介绍请参考：zhuanlan.zhihu.com/p/...

       我们创建nextTick函数，nextTick接收一个回调函数，返回一个状态为fulfilled的Promise，并将回调函数传给then方法。

       然后只需要在添加任务时调用nextTick，将执行任务的flushJobs函数传给nextTick即可。

       回到页面。

       虽然修改了x、y、z三个变量的value，最后页面上只渲染了一次。

       再来总结一下这段代码的执行过程：

       这也正是Vue采用的解决方案——异步更新队列，官方文档描述得很清楚。

       文档地址：cn.vuejs.org/v2/guide/r...

       三、结合Vue源码来看nextTick

       在Vue中，我们可以通过两种方式来调用nextTick：

       （至于什么时候使用nextTick，如果你不偷懒看了官方文档的话，都能找到答案哈哈）

       以下源码节选自vue2.6.版本，这两个API分别在initGlobalAPI函数和renderMixin函数中挂载，它们都引用了nextTick函数。

       nextTick源码如下：

       在内部，它访问了外部的callbacks，这个callbacks就是前面提到的队列，nextTick一调用就给队列push一个回调函数，然后判断pending（pending的作用就是控制同一时间内只执行一次timerFunc），调用timerFunc()，最后返回了一个Promise（使用过nextTick的应该都知道吧）。

       我们来看一下callbacks、pending、timerFunc是如何定义的。

       可以看到timerFunc函数只是调用了p.then方法并将flushCallbacks函数推入了微任务队列，而p是一个fulfilled状态的Promise，与我们自己的nextTick功能一致。

       这个flushCallbacks函数又干了什么呢？

       flushCallbacks中重新将pending置为初始值，复制callbacks队列中的任务后将队列清空，然后依次执行复制的任务，与我们自己的flushJobs函数功能一致。

       看完上面的源码，可以总结出Vue是这么做的，又到了小学语文之——提炼中心思想的时候了。

       对比一下我们自己写的代码，你学会了吗？

       以上演示代码已上传github：github.com/Mr-Jemp/VueS...

       后面要学习的内容在这里：

       Vue—关于响应式（三、Diff Patch原理分析）

       Vue—关于响应式（四、深入学习Vue响应式源码）

       本文由博客一文多发平台OpenWrite发布！

RKs Android 屏蔽蓝牙弹窗及桌面悬浮通知

       针对RKs设备的Android系统，客户提出了一些特定需求的修改。首先，针对屏幕上的WebView，允许系统应用正常使用，改动位于

       frameworks\base\core\java\android\webkit\WebViewFactory.java

       文件中。

       为了屏蔽蓝牙配对弹出窗口，实现静默确认配对，改动涉及到

       packages/apps/Settings/src/com/android/settings/bluetooth/BluetoothPairingDialog.java

       当请求开启蓝牙时，自动确认设置在

       packages\apps\Settings\res\values\config.xml

       ，将auto_confirm_bluetooth_activation_dialog设为true。

       对于全局通知，尤其是桌面悬浮提示，需要在

       frameworks\base\packages\SettingsProvider\res\values\defaults.xml

       中修改，将def_heads_up_enabled设为0，如果不存在则新增该设置。

       SystemUI的桌面音量面板弹出也被要求隐藏，改动在

       frameworks\base\packages\SystemUI\src\com\android\systemui\volume\VolumeDialogImpl.java

       中，注释掉mDialog.show()方法。

       此外，为了优化用户体验，蓝牙外设连接成功后，Activity不再自动刷新，改动在

       frameworks/base/core/java/android/app/ActivityThread.java

       中。

       最后，为了避免WIFI连接失败时弹出通知打扰用户，需要在

       packages\modules\Wifi\service\java\com\android\server\wifi\ConnectionFailureNotifier.java

       中屏蔽mNotificationManager.notify这一行代码。

       以上就是针对客户特定需求所做的源码修改记录。

synchronize底层原理

       synchronize底层原理是什么?我们先通过反编译下面的代码来看看Synchronized是如何实现对代码块进行同步的：

       1 package com.paddx.test.concurrent;

       2

       3 public class SynchronizedDemo {

       4 public void method() {

       5 synchronized (this) {

       6 System.out.println(Method 1 start);

       7 }

       8 }

       9 }

       反编译结果：

       关于这两条指令的作用，我们直接参考JVM规范中描述：

       monitorenter ：

       Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref, as follows:

        If the entry count of the monitor associated with objectref is zero, the thread enters the monitor and sets its entry count to one. The thread is then the owner of the monitor.

        If the thread already owns the monitor associated with objectref, it reenters the monitor, incrementing its entry count.

        If another thread already owns the monitor associated with objectref, the thread blocks until the monitors entry count is zero, then tries again to gain ownership.

       这段话的大概意思为：

       每个对象有一个监视器锁(monitor)。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程：

       1、如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。

       2、如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1.

       3.如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。

       monitorexit：

       The thread that executes monitorexit must be the owner of the monitor associated with the instance referenced by objectref.

       The thread decrements the entry count of the monitor associated with objectref. If as a result the value of the entry count is zero, the thread exits the monitor and is no longer its owner. Other threads that are blocking to enter the monitor are allowed to attempt to do so.

       这段话的大概意思为：

       执行monitorexit的线程必须是objectref所对应的monitor的所有者。

       指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。

       通过这两段描述，我们应该能很清楚的看出Synchronized的实现原理，Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。

       我们再来看一下同步方法的反编译结果：

       源代码：

       1 package com.paddx.test.concurrent;

       2

       3 public class SynchronizedMethod {

       4 public synchronized void method() {

       5 System.out.println(Hello World!);

       6 }

       7 }

       反编译结果：

       从反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来完成(理论上其实也可以通过这两条指令来实现)，不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。