状态机

A2dp sink的初始化流程和A2dp 的初始化流程,基本一样,这里做简单分析.这里分析的android的版本是Android O. 我们先从service的启动说起吧. 下面 是启动的时候的log: D/BluetoothAdapterService( 2029): setProfileServiceState() - Starting service com.android.bluetooth.a2dpsink.A2dpSinkService 01-01 08:00:22.042 D/A2dpSinkService( 2029): Received start request. Starting profile... 01-01 08:00:22.045 D/A2dpSinkService( 2029): start() 01-01 08:00:22.054 I/BluetoothA2dpSinkServiceJni( 2029): classInitNative: succeeds 我们看看 A2dpSinkService.java的start函数的实现: protected boolean start() { if (DBG) { Log.d(TAG, "start()"); } // Start the media browser service. Intent

添加链接描述 什么是状态机？ 来源： CSDN 作者： 人生中最美丽的春天 链接： https://blog.csdn.net/weixin_43044825/article/details/103946888

大盗阿福 阿福是一名经验丰富的大盗。趁着月黑风高，阿福打算今晚洗劫一条街上的店铺。 这条街上一共有 N 家店铺，每家店中都有一些现金。 阿福事先调查得知，只有当他同时洗劫了两家相邻的店铺时，街上的报警系统才会启动，然后警察就会蜂拥而至。 作为一向谨慎作案的大盗，阿福不愿意冒着被警察追捕的风险行窃。 他想知道，在不惊动警察的情况下，他今晚最多可以得到多少现金？ 输入格式 输入的第一行是一个整数 T，表示一共有 T 组数据。 接下来的每组数据，第一行是一个整数 N ，表示一共有 N 家店铺。 第二行是 N 个被空格分开的正整数，表示每一家店铺中的现金数量。 每家店铺中的现金数量均不超过1000。 输出格式 对于每组数据，输出一行。 该行包含一个整数，表示阿福在不惊动警察的情况下可以得到的现金数量。 数据范围 1≤T≤50, 1≤N≤105 输入样例： 2 3 1 8 2 4 10 7 6 14 输出样例： 8 24 样例解释 对于第一组样例，阿福选择第2家店铺行窃，获得的现金数量为8。 对于第二组样例，阿福选择第1和4家店铺行窃，获得的现金数量为10+14=24。 这道题分析还是很好分析的先上一个线性DP的代码 # include <bits/stdc++.h> # define long long using namespace std ; const int N = 1e5 + 7

《敏捷软件开发》读书笔记（3） 书中设计模式的汇总 命令类模式，分离执行和定义 CMD模式 其实是事件-事务绑定的模型： 可以用事件驱动，只要收到事件，执行绑定到事件对应的CMD对象.do方法就行，对于真正执行的事情无感知。解除了系统的逻辑互联关系和实际连接关系的设备之间的耦合。 事务型操作，把验证和执行分离，由执行框架完成验证和执行操作。解除了获取数据、验证数据、执行数据操作这种空间耦合，同时也可以在执行时间上进行解耦。扩展可以增加undo接口，系统把CMD对象压入堆栈，在进行回退的时候调用undo。 整体上就是把程序算法或者业务逻辑，和程序的实际控制执行解耦，有点像函数式编程。 ACTIVE OBJECT模式 这部分没看懂，似乎是多线程任务执行引擎，可以把CMD对象放回到引擎列表中。这种类型的线程任务是RTC线程。 复用算法，分离业务逻辑的模式 TEMPLATE METHOD模式 把算法的控制和逻辑分离，通用算法封装到基类，不需要理解的逻辑部分交给子类实现，比如冒泡排序。（其实不一定用继承，可以用组合），注意防止滥用。 STRATEGY模式 相比TEMPLATE METHOD，更好的解除了具体实现和算法的耦合，使用接口+组合，而不是继承，能提高具体实现的复用性，优先使用。 统一对外接口，隐藏策略的模式 FACADE模式 封装组件对外的策略和约束

C# Under the Hood: async/await 原文地址：https://www.markopapic.com/csharp-under-the-hood-async-await/ 前言 Async 和 await 关键字是在 C# 5 版本中提出的，作为一种很酷的特征用来处理异步任务。它们允许我们以十分简单、直觉的方式来指定将被异步执行的任务。然而，一些人仍然迷惑于异步编程，并且不确定它是如何工作的。我将向你展示当使用 async 和 await 时底下的魔法。 Awaiter Pattern 异步等待者模式 C# 语言编译它一些特征（关键字）称之为语法糖，语法糖的意思是这些语法仅只是现有语法的一种方便的表达。许多这样的语法糖被解释为模式。这些模式都基于方法调用，属性查看或接口实现。 await 表达式就是这些语法糖中的一个。它利用一个基于一些方法调用的模式。为了得到一个可等待的类型，它需要符合以下需求： 它必须具有以下方法： INotifyCompletion GetAwaiter() GetAwaiter 方法的返回类型需要实现 INotifyCompletion 接口，并且还要： 有一个属性：bool IsCompleted 有一个方法：void GetResult（） 如果你去看 Task 类的源码，就会发现它符合上述所有需求。 所以

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ‍ ‍ 引言 ‍ ‍ 现在的手游玩法越来越复杂，特别是战斗系统，再也不是以前那种简单的回合制模式。越来越多的手游采用了实时战斗的模式（如刀塔传奇），玩法有点类似于以前的即时战略游戏，这对于程序设计提出了更高的要求。本文提出了一种手游中实时战斗系统可行的设计思路。 设计需求 实时战斗，不同于早期页游和手游单纯的看战报或回合制模式，整个战斗过程是流畅和连贯的，人物的移动、攻击、技能释放都不会让玩家感觉到停滞，整体感觉类似于传统的即时战略游戏（魔兽、星际等），玩家在游戏中的指令（如释放技能）可以实时得到执行。 这里带来的问题是，如何设计一个稳定且高效的战斗系统，来满足多人战斗时可能的高并发；不会因为高并发对服务器造成过重的负担，不会对玩家带来糟糕的延时体验；同时数目繁多的兵种和技能要能够稳定有序地工作在这个系统中，不会让程序员疲于应付而无所适从。 下面针对这些需求提出了一种设计思路。 设计要点 : 内存化 当玩家在线人数很多时，如果还是将每次数据修改入库，势必会带来很大的cpu开销。笔者曾经参与一个项目，当同时在线人数达到500时，服务器用于mysql的cpu占用率飙到了800%。后来经过分析，有很大一部分数据没必要实时入库，例如战场上的NPC数据，相对不敏感，即使服务器重启也无所谓，这部分数据可以全走内存

Raft算法之日志压缩 最后的一部分是关于服务器日志压缩的，因为随着运行时间的增增长，日志信息也会变得越来越多，占有更多的空间。因此Raft采取了日志压缩的方法解决该问题，即将当前整个系统状态写入稳定存储的快照，然后该时间点之前的日志就可以丢弃掉，从而释放存储空间。 1 快照结构 从图中可见，快照包括以下几个部分内容: lastIncludedIndex: 表明快照中最后一条日志的索引值。也就是说日志一直压缩到该索引值的位置。该值以前连续若干个索引值的日志被压缩为快照，而该值以后的日志则不在快照中。 lastIncludedTerm:表明快照中最后一条日志所在的任期值。 state machine state:复制状态机的当前状态。 集群中每一个服务器都可以独立地进行拍摄快照(只对已提交的日志进行快照的拍摄)，其中 lastIncludedIndex 与 lastIncludedTerm 值的存在时为了通过之前讲到的在日志复制中需要做的一致性检查。当服务器完成了该快照的写入之后，就可以将从快照中最后一条日志一直到先前所有的日志删除。 2 快照的发送 正常情况下， Leader 的日志将会与 Follower 保持一致，但并不是所有情况都处于正常情况下，有时候可能因为 Follower 的反应缓慢或崩溃造成与 Leader 的日志不一致。所以有时候需要 Leader 将快照信息发送给

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 忏悔时间：我有点过分了在这章塞下太多东西。表面我是讨论状态模式，但是我不可能在讨论这个时不涉及到更基本的有限状态机（FSM）的概念。一旦我讲到那了，我发现我又不得不介绍分层状态机（hierarchical state mechine）和下推自动机（pushdown automata）。 要讲的东西太多了，所以为了使篇幅尽可能短，一些代码例子省略了一些细节，这些需要你自己补全。我希望这些仍然是简单清晰的使你了解框架。 不要感到悲伤如果你没听过状态机。熟知AI和编译器的程序员，也对其他圈子不甚了解。我认为他们了解的比较广了，所以我这次抛给他们一个不一样的问题。 We've all been there 我们做一个横版小游戏。我们的工作是实现玩家控制的女英雄。这意味着要使其响应玩家的输入。按下“B”，她应该跳起来。很简单： void Heroine::handleInput(Input input) { if (input == PRESS_B) { yVelocity_ = JUMP_VELOCITY; setGraphics(IMAGE_JUMP); } } 找到bug了没？ 没有任何阻止“空中跳”的条件-当她在空中时不断地敲击“B”键，然后她就会一直漂浮在空中

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 状态机思路在单片机程序设计中的应用 状态机的概念 状态机是软件编程中的一个重要概念。比这个概念更重要的是对它的灵活应用。在一个思路清晰而且高效的程序中，必然有状态机的身影浮现。 比如说一个按键命令解析程序，就可以被看做状态机：本来在A状态下，触发一个按键后切换到了B状态；再触发另一个键后切换到C状态，或者返回到A状态。这就是最简单的按键状态机例子。实际的按键解析程序会比这更复杂些，但这不影响我们对状态机的认识。 进一步看，击键动作本身也可以看做一个状态机。一个细小的击键动作包含了：释放、抖动、闭合、抖动和重新释放等状态。 同样，一个串行通信的时序（不管它是遵循何种协议，标准串口也好、I2C也好；也不管它是有线的、还是红外的、无线的）也都可以看做由一系列有限的状态构成。 显示扫描程序也是状态机；通信命令解析程序也是状态机；甚至连继电器的吸合/释放控制、发光管（LED）的亮/灭控制又何尝不是个状态机。 当我们打开思路，把状态机作为一种思想导入到程序中去时，就会找到解决问题的一条有效的捷径。有时候用状态机的思维去思考程序该干什么，比用控制流程的思维去思考，可能会更有效。这样一来状态机便有了更实际的功用。 程序其实就是状态机。 也许你还不理解上面这句话。请想想看，计算机的大厦不就是建立在“0”和“1

上一篇文章: Raft算法之Leader选举   之前说完了Raft算法中的Leader选举过程，本文将在上一篇文章的基础上说明日志复制。 Raft算法之日志复制   先看以下日志所包含的基本内容: 可以被复制状态机执行的命令 任期号 :创建该日志时Leader所处的当前任期号 索引号 :整数，用于标识日志所在的位置 日志的状态分为两种:未被提交，已被提交(日志为安全的，不会被删除或覆盖)。 1 正常情况 当 Leader 接收到由客户端发送的请求(请求中包含可以被复制状态机执行的命令)时，Leader将会把该请求作为新的内容添加到日志中(任期号为当前 Leader 所处的任期号，索引号为当前 Leader 本地存储的日志集合中的日志的最高索引号加1)。 Leader 在当前任期内最多只能创建一个给定索引号的日志(即不可能在一个任期内创建两个以上的具有相同索引的日志条目) 然后将该日志通过 AppendEntries RPC 消息发送到网络中其他的服务器(以下简称 Follower )，从而复制该日志。 在网络中 Follower 接收到该日志消息后则会返回复制成功的回复。 在 Leader 接收到网络中大部分的 Follower 的成功复制的回复之后， Leader 便认为该日志 可以被提交 。此时 Leader 将会同时做三件事： 将该日志应用到 Leader 本地的复制状态机