uni-app 的 API 与微信小程序 API 基本一致。掌握微信小程序 API 对后面的开发很有帮助。微信小程序 API 文档:https://developers.weixin.qq.com/miniprogram/dev/api/

Phone 设置项中可以模拟来电和短信：From：选择或输入电话号码；CALL DEVICE：点击来电；HOLD CALL：点击保持通话；END CALL：点击结束通话；SMS message：输入模拟消息的正文内容；SEND MESSAGE：点击发送短信。

注册微信小程序账号，获取到 AppID，我们后面配置的时候会用到。在 HBuilderX 工具栏，点击发行，选择小程序-微信。输入小程序名称和 AppID，单击发行就可以了。这样我们就会获得一个微信小程序的打包文件，接下来我们来发布微信小程序项目，打开微信小程序开发者工具，导入刚刚生成的微信小程序项目的打包文件，在微信小程序开发者工具中先测试一下，项目运行是否正常，项目测试没有问题后，点击右上角>>按钮，上传代码就可以发布微信小程序了，最后等待微信团队审核通过，别人就可以在线上访问到你的项目了。

数据转换成电信号还是比较简单的，将字符根据指定的编码转换成唯一的二进制编码，然后将二进制的 01 映射成高低电平就可以传输出去了。

星投影是一种特殊的星号投影，它一般用来表示不知道关于泛型实参的任何信息，换句话说就是它表示一种特定的类型，但是只是这个类型不知道或者不能被确定而已。

RabbitMQ 在进行消息传递的时候，会在其容器中进行一些必要的检测，来保证消息间通信的可靠性，具体 RabbitMQ 是怎样进行消息间通信的检测的，我们在本套课程中就不再介绍了，因为这涉及到 RabbitMQ 的底层实现，和课程初衷是不符的。现在我们只需要这样理解就行了：当我们将一条消息放入到 RabbitMQ 中时，RabbitMQ 首先会检测消息所处的环境，然后 RabbitMQ 会将该条消息通过一定的加密算法进行加密，最后，通过 RabbitMQ 的消息通道，将消息投递到它该去的地方。

Battery 设置中共用4项参数可以调节，模拟设备的电池属性，了解应用在不同条件下的运行情况：Charge level：设置当前电量值，百分比；Charger connection：设置充电器连接状态，是否连接充电器；battery health：设置电池监控状态，正常或者损坏等；Battery status：设置电池状态，正在充电或者已经充满等。

基础概念：消息适配器，可能一说这个名词，大家就感觉有点陌生，我们可以把消息适配器拆开来进行理解。首先，消息这一名词就不用多说了，消息在我们的应用程序中指的就是应用程序中的数据，在 RabbitMQ 中，指的就是在 RabbitMQ 中流转的消息，也就是说，我们应用程序中的数据在 RabbitMQ 中就被称为消息。最后，我们再来看适配器。和之前一样，我们先从日常生活中举个例子，比如我们的笔记本电脑，在笔记本电脑上存在不同的对外暴露的类似USB形式的端口，这些端口不仅仅只有USB这一种类型，还有Type-C，以及Light端口等，根据我们的需要来连接这些端口所用的工具就可以看做是一个适配器。当我们需要将自己的电脑与大屏或投影仪设备相连接时，此时，我们需要一根连接在电脑和大屏或投影仪设备之间的连线，这根线我们通常称为数据线，在有了这根数据线之后，我们就可以建立起一个在电脑和大屏或投影仪设备之间的连接，就可以将电脑的屏幕投影到大屏或投影仪设备上，这个过程就是我们的电脑适配大屏或投影仪设备的一个过程，而这中间的数据线就被可以被称为适配器。如果我们没有这个数据线来作为电脑与大屏或投影仪设备之间的适配器，那么通常情况下我们就不能将电脑屏幕来进行投影了（Wifi投影的情况除外）。在这一例子中，我们也可以这样说：即需要一根数据线来将我们的电脑屏幕与大屏或投影仪设备进行适配，以达到投影电脑屏幕的目的。说白了，适配器其实就是为了适配两种不同物品，来达到两种或多种物品之间的协同工作的目的的一种技术手段，而这种技术手段可以是技术实物（比如数据线），也可以是一种可以在空气中进行传播的介质（Wifi投屏）。消息适配器亦是如此，在 Spring-AMQP 中，消息适配器指的就是，为了监听 RabbitMQ 中的消息，从而将消息与具体的业务逻辑相结合，达到消息适配业务逻辑的目的的一种技术手段。在介绍完消息适配器的基础概念之后，下面让我们来看一下如何对消息适配器进行简单的配置吧。

乐观是一种积极的解决问题的态度。所谓乐观锁认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。基本思想：每次提交一个事务更新时，查看要修改的数据从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败。实现方案：在实体中增加一个版本控制字段，每次事务更新后就将版本 (Version) 字段的值加 1。Tips： 乐观锁本质就是版本控制管理的实现，记录的每一次更新操作都会以版本递增的方式进行记录。一个事务在更新之前，先获取记录的当前版本号，更新时，如果版本还是最新的则可以更新，否则说明有事务比你先更新，则需要放弃。或者重新查询到最新版本信息后再更新。所以，在乐观锁的实现中，冲突是常态。实现过程：在学生实体类中添加新属性，用来记录每次更新的版本号。public class Student implements Serializable {//省略…… @Versionprivate Long version;//省略…… ｝stu = (Student) session.get(Student.class, new Integer(1));System.out.println("当前版本号："+stu.getVersion);//模拟延迟，如果在这个时间内有其它事务进行了更新操作，此事务的更新不会成功Thread.sleep(30000);stu.setStuName("Hibernate");transaction.commit();好了，悲观也好，乐观也好，只是一种解决问题的态度。对于这两种态度，咱们要总结一下。乐观锁：优势：性能好，并发性高。缺点：用户体验不好，可能会出现高高兴兴去更新，却告知已经有人捷足先登了。悲观锁：优势：锁住记录为我所用，没修改完成之前，其他事务只能瞪眼瞧着，时间虽然延迟，至少心里有底。缺点：并发性不好，性能不高。Hibernate 的其它性能优化：随时使用 Session.clear（）及时清除 Session 缓存区的内容；1+N 问题 ( 一条 SQL 语句能解决的问题用了很多条 SQL 语句来实现) ；使用 Criteria 查询可以解决这个问题；Lazy 加载：需要时，使用 get（） 方法发出 SQL 语句。使用类似于 from Student s left join s.classRoom c 的关联查询语句。缓存使用：在对象更新、删除、添加相对于查询要少得多时， 二级缓存的应用将不怕 n+1 问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的，刚好又利用了 n+1。

定义：乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新的时候，才会正式对数据冲突与否进行检测。乐观锁的实现：依旧拿数据库的锁进行比较介绍，乐观锁并不会使用数据库提供的锁机制， 一般在表中添加 version 宇段或者使用业务状态来实现。 乐观锁直到提交时才锁定，所以不会产生任何死锁。Java 中的乐观锁：我们之前所学习的 CAS 原理即是乐观锁技术，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。Tips：我们这里所说的对于乐观锁，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败。注意失败两字，失败意味着有操作，而悲观锁是等待，意味着不能同时操作。

可以看到，乐观锁虽然有缺陷，它会使更新失败，因此必须重复获取数据然后重试，但是它保证了数据的正确性和完整性。在读多写少的场景下，乐观锁不会出现太多的重试，当然如果出现了很多重试，证明场景已经可能不是读多写少了，可以尝试换方案了。乐观锁的实现也颇为简单，不需要任何第三方依赖，你完全可以自己直接实现，不过仍然有一些第三方框架提供了开箱即用的乐观锁，你可以根据自己的使用语言和生态去查找相应的乐观锁框架。

这是一种优化的读模式。乐观读模式相关的几个方法如下。tryOptimisticRead () 方法：非阻塞尝试乐观获取读锁，只有当写锁没有被获取时返回一个非 0 的 stamp 。乐观读取模式适用于短时间读取操作，降低竞争和提高吞吐量。在使用时一般需将数据存储到一个副本中，在后继处理中用于对比数据是否是最新状态；validate (long stamp) 方法：用于检查在获取到读锁 stamp 后，锁有没被其他写线程抢占。如果写锁没有被获取，那么 validate () 方法返回 true。可多次调用验证这一信息。另外，此类也提供了一组读写锁之间的转换方法：tryConvertToWriteLock (long stamp) 方法：尝试转换为写锁。转换条件：tryConvertToReadLock (long stamp) 方法：尝试转换为悲观读锁。tryConvertToOptimisticRead (long stamp) 方法：尝试转换为乐观读锁。注意此类的编程方法有这样一个共通特征：所有获取锁的方法，都返回一个邮戳（Stamp），Stamp 为 0 表示获取失败，其余都表示成功；所有释放锁的方法，都需要一个邮戳（Stamp），这个 Stamp 必须是和成功获取锁时得到的 Stamp 一致；下面我们举一个具体的编程例子。

乐观锁的使用十分广泛，我们也推荐你在实际的开发中使用乐观锁，接下来，我们以一个例子来详细的说明一下乐观锁。我们新建一个测试数据表 imooc_order ：DROP TABLE IF EXISTS imooc_order;CREATE TABLE imooc_order( id int PRIMARY KEY, price decimal(10,2), -- version 字段作为乐观锁版本控制位 version int NOT NULL DEFAULT 0);INSERT INTO imooc_order(id,price,version)VALUES (1,23.2,1);注意： 我们已经在表中添加了 version 字段

为了更好地理解悲观锁与乐观锁，我们通过设置一个简单的示例场景来进行分析。并且我们采用悲观锁 synchronized 和乐观锁 Atomic 操作进行分别实现。Atomic 操作类，指的是 java.util.concurrent.atomic 包下，一系列以 Atomic 开头的包装类。例如 AtomicBoolean，AtomicInteger，AtomicLong。它们分别用于 Boolean，Integer，Long 类型的原子性操作。Atomic 操作的底层实现正是利用的 CAS 机制，而 CAS 机制即乐观锁。场景设计：创建两个线程，创建方式可自选；定义一个全局共享的 static int 变量 count，初始值为 0；两个线程同时操作 count，每次操作 count 加 1；每个线程做 100 次 count 的增加操作。结果预期：最终 count 的值应该为 200。悲观锁 synchronized 实现：public class DemoTest extends Thread{ private static int count = 0; //定义count = 0 public static void main(String[] args) { for (int i = 0; i < 2; i++) { //通过for循环创建两个线程 new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(10); } catch (Exception e) { e.printStackTrace(); } //每个线程让count自增100次 for (int i = 0; i < 100; i++) { synchronized (DemoTest.class){ count++; } } } }). start(); } try{ Thread.sleep(2000); }catch (Exception e){ e.printStackTrace(); } System.out.println(count); }}结果验证：200乐观锁 Atomic 操作实现：public class DemoTest extends Thread{ //Atomic 操作，引入AtomicInteger。这是实现乐观锁的关键所在。 private static AtomicInteger count = new AtomicInteger(0); public static void main(String[] args) { for (int i = 0; i < 2; i++) { new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(10); } catch (Exception e) { e.printStackTrace(); } //每个线程让count自增100次 for (int i = 0; i < 100; i++) { count.incrementAndGet(); } } }). start(); } try{ Thread.sleep(2000); }catch (Exception e){ e.printStackTrace(); } System.out.println(count); }}结果验证：200代码解读：此处主要关注两个点，第一个是 count 的创建，是通过 AtomicInteger 进行的实例化，这是使用 Atomic 的操作的入口，也是使用 CAS 乐观锁的一个标志。第二个是需要关注 count 的增加 1 调用是 AtomicInteger 中 的 incrementAndGet 方法，该方法是原子性操作，遵循 CAS 原理。

Flask 是一个 Python 实现的 Web 开发微框架，但是这个“微”并不代表着 Flask 功能比较简陋、有所欠缺。微框架中的 “微” 意味着：Flask 旨在保持核心简单而易于扩展；Flask 不会替用户做出太多决策，比如使用何种数据库；Flask 的选项（比如使用何种模板引擎) 通常有多个，用户很容易替换。默认情况下，Flask 不包含数据库抽象层、模板引擎、身份认证或其它任何已有多种库可以胜任的功能，如下图所示。然而，Flask 支持用扩展来给应用添加这些功能，应用程序可以很方便的集成这些扩展。众多的扩展提供了数据库集成、表单验证、上传处理、各种各样的开放认证技术等功能。

在日常工作学习中，我们经常需要把有限的内容按照一定的比例进行分开，比如一天的时间用来工作，学习，娱乐，休息这样的时间需要进行按比例合理划分。一般这样多比较占比的时候大家一般都会使用饼图表示。饼图又称饼状图，用于描述量、频率或百分比之间的相对关系。

微前端 尚处在发展时期，其核心概念和 微服务 相似。现阶段较为常用的微前端框架为 single-spa 和 qiankun，后者是基于前者实现的。该技术能做到 技术栈无关，即一个应用，能由多个不同技术的子应用构成，同时做到子应用的相互隔离，这里的隔离就可以选择采用 Web Components 实现。

for…in 循环可以用来遍历对象的属性名。var obj = { name: '小红', age: 12, hobby: ['打篮球', '唱歌'],};for (key in obj) { console.log(obj[key]);}// 输出：// "小红"// 12// ["打篮球", "唱歌"]每一次遍历拿到的 key 就是对象的某一个属性名，当属性名被遍历完后会自动退出循环。有部分 key 是无法遍历到的，具体规则可以参阅对象章节。

模拟10086来电；gsm call 10086模拟接听来电；gsm accept 10086模拟挂断来电；gsm cancel 10086下面是完整会话示例。pt@Win10-Panda:~$ telnet localhost 5554Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Android Console: Authentication requiredAndroid Console: type 'auth <auth_token>' to authenticateAndroid Console: you can find your <auth_token> in'C:\Users\panda\.emulator_console_auth_token'OKauth KeGgPVHDN7YifXfZAndroid Console: type 'help' for a list of commandsOKgsm call 10086OKgsm accept 10086OKgsm cancel 10086OK

IP 地址，物理地址网站后台访问地址，密码信息家庭成员信息，电话信息生日（很多人的秘密是生日日期）公司信息，同事信息

事件日志中包含屏幕电源状态，其中 0 表示屏幕关闭，1 表示屏幕打开，2 表示已锁屏。日志范例如下：grep screen_toggled bugreport-2015-10-18-16-52-22.txt10-18 15:05:04.383 992 992 I screen_toggled: 110-18 15:05:07.010 992 992 I screen_toggled: 010-18 15:23:15.063 992 992 I screen_toggled: 110-18 15:23:25.684 992 992 I screen_toggled: 010-18 15:36:31.623 992 992 I screen_toggled: 110-18 15:36:37.660 3283 3283 I screen_toggled: 2错误报告中还包含关于唤醒锁的统计信息，唤醒锁是应用开发者采用的一种机制，用于表明其应用需要设备保持开启状态。唤醒锁总时长统计信息仅跟踪唤醒锁实际负责使设备保持唤醒状态的时间，不包括屏幕处于开启状态的时间。此外，如果同时持有多个唤醒锁，系统会在它们之间分配唤醒锁时长。

试想一下，如果你在电脑上使用聊天工具，跟对方说了一句 你好，对方的电脑如果只收到了 你好的电频信号，是不能直接解析出来信息的。电脑解析电平信号需要解决很多问题：这个电信号我该用什么规则解析出正确的字符？这信息是谁发给我的？我的电脑现在运行着微信/ QQ /邮件服务等，它到底跟哪个应用交互的？对方的地址是什么，我要怎么回复出去？等等问题很多，所以信息的发送不止是简单的电信号转换，还要给我们的数据添加额外的很多标识，让对方机器清楚你是谁，哪里来的，跟我这台电脑的哪个程序交互等信息。网络模型就很详细的说明了里面具体要处理的事情，这里根据标准的 ISO 七层模型讲解。

1. 独立的页面维护了全局 错误码错误码由5位整数构成2. 每个接口一个独立的 参数说明页面正常情况下出参只返回业务实体异常情况才有 errCode errMsg每个接口下也可能有自己的业务错误码

咱们打开新浪微博，然后随便找个带皇冠的，按下F12键(Mac用户按command+option+i)然后选中控制台的箭头，再点击皇冠：再点开这个图片可以发现：可以看到那些大 V 图标皇冠图标以及各种微博认证等图标，都是放在了一张雪碧图里(即使再牛的大 V，身份标志也是放在雪碧图中的)。

我们都知道，什么事情都不可能是十全十美的。抛开 RabbitMQ 不说，在互联网行业中的其他工具，也不能百分百保证每时每刻都在正常工作，更何况是涉及到消息通信的工具。RabbitMQ 在传递消息时，由于一些客观原因或者是其本身的原因，可能会出现，在有大批量消息传递时，所有的消息不能百分百传递到目的地的问题。RabbitMQ 在设计之初就考虑到了这个问题的出现，所以，RabbitMQ 提供了内置的消息补偿机制，这里我们简单做一下介绍。当存在大批量的消息都需要经过 RabbitMQ 来投递时，RabbitMQ 会将这些消息划分成若干组，然后通过为组设置顺序的方式，来依次投递这些消息。如果在任意一组中，出现了消息未能投递到目的地的现象，那么， RabbitMQ 会将该条消息进行短暂的存储，待其他消息都到达目的地后，RabbitMQ 会重新将该条消息进行投递，然而，这个过程执行的时间是微乎其微的，几乎近于实时。

乐观与悲观是两种不同的态度，从名字上看，二者就是以开发者的态度作为边界来分类的。乐观锁认为，同一数据在并发条件下，发生冲突是小概率事件，因此我们不加锁，而是加上版本号判断修改是否成功。悲观锁认为，同一数据在并发条件下，冲突是大概率事件，因此我们必须先加锁，不允许别人修改。悲观锁和乐观锁其实是一种思想，主要取决于开发者对待它的态度。在锁这一小节中，里面谈到的所有锁宏观上（可能实现的思想是乐观锁）来说都是悲观锁，因此一旦加锁，都会锁定数据，直到解锁才会释放。

上节课我们学习了基于 IEDA 搭建 Kotlin 的开发环境以及使用如何创建一个 Kotlin 项目。这节课我们继续学习在 Eclipse 下搭建 Kotlin 的开发环境。作为老牌的 Java 开发 IDE，使用 Eclipse 的开发者依然很多。在 Eclipse 下搭建 Kotlin 的开发环境要比 IDEA 稍微繁琐一些，下面我们一起来看一下。

不同的系统会有不同的默认 Button 样式，但是它们都有一个共同点——丑。相比于 TextView 而言，Button 是一个互动感很强的控件，除了设置字体字号，还需要有形状、背景、颜色、点击态等等样式变化。特别是在游戏及娱乐类 App 中 ，Button 的样式及变化效果将直接影响用户体验，所以这里将重点讲解几种设置样式的方法。

乐观锁不全依赖于数据库，一般情况下我们都是在代码层面上来完成它的，主流的设计思路是这样的：我们在数据表中添加一个字段version，version 代表版本号，字段类型为整型。当我们获取数据时，假设得到它的version字段为n，执行完其它操作对该数据进行更新时，会执行UPDATE ... SET version=n+1 WHERE version=n。如果在更新时，数据已经被别人更新过了，那么该数据的version字段已经不是n了，那么此时修改就会失败，反之修改就会成功。可以看到，乐观锁就像它的名称一样乐观，适合数据读多写少的场景，因为实际上并没锁住数据，所以性能十分可观；而悲观锁则与之相反，适合写多读少的场景，盲目的排他性一定程度上会大幅影响性能。

命令说明power display显示电池和充电器状态。power ac {on\off}将交流电充电状态设为 on 或 off。power status {unknown\charging\discharging\not-charging\full}按照说明更改电池状态。power present {true\false}设置电池存在状态。power health {unknown\good\overheat\dead\overvoltage\failure}设置电池运行状况。power capacity percent将电池剩余电量状态设为 0 到 100 之间的百分比。