Observer

最近一直在学习Vue，而vue生命周期是我们不可能绕开的一个很核心的知识点，今天来简单的梳理一下大概的内容。 一、钩子函数 在一开始学习的时候，总有钩子函数这个名词冒出来，而且在vue官网文档中也频繁出现，也相信给很多初学者带来了困扰。那到底什么是钩子函数呢？ 按我个人的理解，钩子函数就是一个函数，他最大的特点就是在生命周期执行流程中去执行的。 钩子函数钩子函数，就是挂载一些东西的，我们把需要实现的一些功能代码写在对应的钩子函数中，当生命周期在执行的时候，就能执行我们挂载的代码。 钩子函数的实现，基本原理就是callback，回调函数。 二、vue生命周期图示（注释） 原图是从vuejs官方文档上拷下来的，自己用ps写了一点注释。 三、vue生命周期详细解析 1. 实例化vue(组件)对象：new Vue() 2. 初始化事件和生命周期 init events 和 init lifecycle 3. beforeCreate函数： 在实例初始化之后，数据观测 (data observer) 和 event/watcher 事件配置之前被调用。 即此时vue（组件）对象被创建了，但是vue对象的属性还没有绑定，如data属性，computed属性还没有绑定，即没有值。此时还没有数据和真实DOM。属性还没有赋值，也没有动态创建template属性对应的HTML元素

我在前文中曾经介绍过 鸿蒙的 Javascript 框架 ，这几天终于把 JS 仓库编译通过了，期间踩了不少坑，也给鸿蒙贡献了几个 PR。今天我们就来逐行分析鸿蒙系统中的 JS 框架。 文中的所有代码都基于鸿蒙的当前最新版（版本为 677ed06 ，提交日期为 2020-09-10）。 鸿蒙系统使用 JavaScript 开发 GUI 是一种类似于微信小程序、轻应用的模式。而这个 MVVM 模式中，V 其实是由 C++ 来承担的。JavaScript 代码只是其中的 ViewModel 层。 鸿蒙 JS 框架是零依赖的，只在开发打包过程中使用到了一些 npm 包。打包完之的代码是没有依赖任何 npm 包的。我们先看一下使用鸿蒙 JS 框架写出来的 JS 代码到底长什么样。 export default { data() { return { count: 1 }; }, increase() { ++this.count; }, decrease() { --this.count; }, } 如果我不告诉你这是鸿蒙，你甚至会以为它是 vue 或小程序。如果单独把 JS 拿出来使用（脱离鸿蒙系统），代码是这样： const vm = new ViewModel({ data() { return { count: 1 }; }, increase() { ++this.count;

一 前言 最近在改造一些历史的代码，发现一个很明显的特点，大部分代码是记叙文，按照事件的发展过程将故事平铺直叙的讲解出来。 这种方式的好处是比较符合人类的思维习惯，一条主线讲到底，代码阅读起来没有太大难度，只要顺着藤就能摸到瓜，但是缺点也很明显，一旦故事线中需要插入一些新的元素，比如：加入一个新的人物角色、新的时间线，都会需要大量更改故事线以配合这个新元素的融入，甚至对原有文章造成破坏性的影响。 为了解决这个问题，人们总结出了很多种文章结构，例如：总-分结构，并列结构，总-分-总结构等等，有了这些结构，在加入新元素的时候，甚至不必考虑新元素与原故事情节的关联性，直接单拉一个分支故事线独立去讲就好了，只要能够在整体故事结束前，与汇聚到主线故事就可以了（是不是很像git？）。 在软件开发领域，也有很多这样的非常有用的实践总结，我们称之为设计模式。对于设计模式，大家都不陌生，随便找个人，估计都能讲出N个设计模式来，但是除了这些设计模式的概念，很多人不知道如何灵活运用这些设计模式。所以借这篇文章和大家共同学习设计模式的思想。 二 理解设计模式 我尽量用最通俗易懂的示例和语言来讲述我理解的设计模式，希望能对大家有所帮助。 另外也无需精通所有的设计模式，只要能够融汇贯通常见的设计模式，就能让你的代码变得优雅。就像程咬金只会三板斧，但是熟练度无人能及，照样能横行天下。 1 工厂模式

继续上篇文章内容，我们继续VOL1中的3.5 LOGICAL LINKS AND LOGICAL TRANSPORTS小节之后的内容学习。本章节讲述了BLE传输数据时候，不同的数据流应该采用不同的协议去传输，即使用什么样的协议去传输什么样的数据。举个比较简单的例子：之前章节我们提到，ADV的广播方式是不可靠的数据传输方式，如果应用要求传输数据可靠度很高，就不可以采用ADV的方式去传播数据。 以下列举了目前BLE支持的logical transport方式：ACL(基于connect的可靠传输), ADV（基于广播的不可靠传输）, ISO（流数据传输） 1. 传输使用的Logical transports介绍 LE ACL：基于连接的，用于传输LL and L2CAP control signaling and best effort asynchronous user data。此种传输使用NESN/SN和access address来保证传输的可靠性。传输的link包括LE-C,LE-U. LE advertising broadcast (ADVB)：基于广播的，broadcast control and user data to all scanning devices in a given area。不可靠的数据传输方式。传输的link包括ADVB-C,ADVB-U.

MobX一直是主要用于JS的主要的状态管理技术。flutter 现在关于状态管理的方案有 Scoped Model，Inherited Widget，Redux for Flutter，甚至是BLoC 。 之前写React的时候就有用过mobx,很是喜欢 , 现在发现提供了dart版本,于是来学习一下. 也许会成为最好用的状态管理工具呢 介绍 MobX只是一个状态管理库，可以很容易地将应用程序的被动数据与UI连接起来. 使用 导包 首先，我们将导入mobx，flutter_mobx，作为我们的依赖项。 此外，我们必须导入mobx_codegen和build_runner作为dev依赖项。 dependencies: flutter: sdk: flutter mobx: ^0.1.4 flutter_mobx: ^0.1.3 dev_dependencies: flutter_test: sdk: flutter mobx_codegen: ^0.1.3 build_runner: ^1.4.0 创建可观察对象 然后我们先创建一个dart文件: /* * author: Created by 李卓原 on 2019/5/16. * email: zhuoyuan93@gmail.com * */ import 'package:mobx/mobx.dart'; part

Nordic开发环境如何快速搭建？如何理解Nordic的BLE透传服务？如何开发自己的数据透传应用？如何提高BLE数据传输速率？手机和BLE设备之间通信有没有什么工具可以进行压力测试？哪里可以找到手机端BLE app参考程序？本文将对以上问题进行解答。 在很多应用场合，BLE只是作为一个数据透传模块，即将设备端数据上传给手机，同时接收手机端下发的数据。本文将和大家一起，一步一步演示如何开发一个BLE透传应用程序。按照本文的说明，大家可以很快就实现一个BLE透传应用，BLE透传应用已经是BLE应用中比较复杂的一种，一旦大家掌握了BLE透传应用，其他BLE应用开发就更不在话下了。本文还将手把手教大家如何提高BLE数据传输速度（ 在蓝牙4.2模式下我们实测速度达到了 85kB/s （理论值90kB/s）； 在蓝牙5.0模式下我们实测速度达到了150kB/s （理论值170kB/s））。最后，我们将告诉大家如何使用安卓版nRF Connect来对你的BLE设备进行压力测试，以测试设备的稳定性和可靠性。文章的最后还会告诉大家如何找到安卓和iOS手机BLE app开发参考代码。 这是一篇纯实践的文章，如果你对低功耗蓝牙的一些基本概念还不是很懂的话，那么建议你先看一下这篇文章： 低功耗蓝牙ATT_GATT_Profile_Service_Char规格解读 ，有了BLE这些基本概念后

【本文版权归微信公众号"代码艺术"（ID：onblog）所有，若是转载请务必保留本段原创声明，违者必究。若是文章有不足之处，欢迎关注微信公众号私信与我进行交流！】 观察者模式（Observer Pattern）也叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式。这个模式的一个最重要的作用就是解耦。也就是将被观察者和观察者进行解耦，使得他们之间的依赖性更小，甚至做到毫无依赖。 观察者模式的定义：该模式定义了对象之间的一对多依赖关系，Subject 对象是一，Observer 对象是多。当 Subject 对象的状态发生改变时，所有依赖于该 Subject 对象的 Observer 对象都会得到通知，并且自动更新。 仔细分析定义，要精确理解观察者模式主要注意三点： 定义了对象间的一对多依赖关系。 当 Subject 对象的状态发生改变时，所有依赖于该 Subject 对象的 Observer 对象都会得到通知。 Observer 对象得到通知后，会自动更新，而不是被动。 经过上面的分析，下面我用代码简单实现上述逻辑。 1.首先需要定义一个观察者对象，内部含有data数据（getter、setter、构造方法、toString）。 public class Observer { private String data; public

为什么会有ZooKeeper 我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。有可能是收到消息以后发生了网络故障，也有可能是没有收到消息，又或者可能接收方的进程死了。发送方唯一的确认方法就是再次连接发送消息，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。所以大部分应用需要开发私有的协调程序，协调程序的反复编写浪费时间，这个时候就需要一个通用的、伸缩性好的协调器。就是因为这样的场景，ZooKeeper应运而生，ZooKeeper的设计目的，就是为了减轻分布式应用程序所承担的协调任务。 ZooKeeper常用的应用场景 01 / 分布式协调 分布式协调简单说就是有人对ZooKeeper中的数据做了监听，如果修改了ZooKeeper中被监听的数据，ZooKeeper反过来会告诉给发起监听的人数据的变更。比如在Kafka的设计中，Kafka的一个节点在ZooKeeper中创建了一个数据，Kafka的策略是谁创建了这个数据谁就是Kafka集群的主节点，其余的节点都会去监听这个数据。如果主节点宕机了，这ZooKeeper对应的数据就会发生变更，既而监听这个数据的其余节点就会感知到主节点宕机了

本文讲解 LiveData 用法，以及 LiveData 源码解析。 官方文档： https://developer.android.google.cn/topic/libraries/architecture/livedata 一句话介绍 LiveData ：LiveData 是一种可观察的数据存储器类。 与常规的可观察类不同，LiveData 具有生命周期感知能力，意指它遵循其他应用组件（如 Activity、Fragment 或 Service）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。 为什么需要 LiveData： 能够保证数据和 UI 统一（跟 LiveData 采用观察者模式有关，LiveData 是被观察的，当数据有变化时它会通知 UI 界面来更新数据。） 减少内存泄漏（在 LiveData 中，能够感知到组件的生命周期，当组件的生命周期处于未激活状态或已经处于 Destroy 状态的时候，观察者就会被清理掉。） 当 Activity 停止时不会引起崩溃（因为 Stop 时就已经变成非激活状态，在 LiveData 分发数据的过程中此时这个组件是非激活状态，LiveData 就不会给它分发数据，其实在组件处于 Pause 时就已经不给他分发数据了，只有它再次 Resume 的时候会重新灌入数据。）

行为模式: 关注系统中对象之间的相互交互，研究运行时对象之间的相互通信和协作，明确对象职责 1.模板方法模式（template method） 定义了一个操作中的算法 骨架 ，将某些步骤延迟到子类中实现。这样，新的子类可以在不改变一个算法结构的前提下重新定义该算法的某些特定步骤。 即：处理步骤父类中定义好，具体实现延迟到子类中定义。 开发中：数据库访问的封装、Junit单元测试、servlet中doGet/doPost方法调用、Hibernate中模板程序等等 银行案例： 1 public abstract class BankTemplateMethod { 2 3 // 具体方法 4 public void takeNumber() { 5 System.out.println("取号排队" ); 6 } 7 8 // 办理具体业务 、钩子方法 9 public abstract void transact(); 10 public void evaluate() { 11 System.out.println("反馈评分" ); 12 } 13 14 // 模板方法 15 public final void process() { 16 this .takeNumber(); 17 18 this .transact(); 19 20 this .evaluate(); 21