按照阳历日子，今天是我踏入「30 岁」的第一天，以后对外介绍自己的年龄时，得是“三十多岁”了。感谢老妈、老婆昨天给我过的生日。
时间怎么就过得这么快呢。想起当时大学时期，20 出头的年纪，天天和室友调侃着“奔三”了。读书，工作，结婚，一路走过来，感觉也就一瞬间的事儿。很多事情，也在这一瞬间就变了。

周末的时候，又去了一次地大北街，吃之前吃过的韩餐。我和老婆骑共享单车到地方之后，我找好地方停完车就先去店里点餐了。我点好餐，过了好一会，老婆才来点店里，说：你要不去把自行车帮忙摆一下，我没找到地方停。我当时并不在意：共享单车啊，随便找个地方停着就可以了，没事~。
然后饥肠辘辘地等着上餐了，看起来可真不错呀。

最近对 Kotlin 的协程、Flow 简单了解一下，也在实际开发中尝试使用了，还是挺香的。凯哥也出了 Compose 的课程，我同学买了课，群里发个群收款，想看的就付个款，免费的大家就不会看了，手忍不住地就付了。确实是因为付了钱，所以觉得不看就亏了，然后下班回家还硬着头皮看了两节课，这可是我少有的在下班时间研究技术了，金钱的魔力呀。
因为暂且可能还不会用 Compose，好记性不如烂笔头，就简单记录一下。

什么是 Compose

Jetpack Compose 是用于构建原生 Android 界面的新工具包。它可简化并加快 Android 上的界面开发，使用更少的代码、强大的工具和直观的 Kotlin API，快速让应用生动而精彩。

简单来说，就是一套 UI 框架，可以编写 Kotlin 代码来替代原先的 xml 工作，这样就不用 xml 与 Java/Kotlin 代码间来回切换了。

继上一篇文章，协程里有一个很大的特性就是 Flow。经过一阵尝试、学习，可能有一点点的收获，还是记录一下吧。
「流」这个词，相信现在越来越多的开发者都接触并喜欢这个概念了。当 RxJava 风靡全球时，就有了「流」这个概念。基于 Kotlin，我们可以流式的写并发代码；基于 Flow，我们也可以流式的处理数据。面对复杂的数据逻辑，写出来的代码也可以像流淌的溪水一样干净，漂亮。

太久没有注重 Android 开发知识了，打算学习下协程，算是未来的趋势吧。二话不多说，凯哥视频三连~
Kotlin 的协程「用力瞥一眼」
Kotlin 协程的挂起好神奇好难懂？今天我把它的皮给扒了
到底什么是「非阻塞式」挂起？协程真的比线程更轻量级吗？

站在凯哥的肩膀上，我大概建立了以下几个概念：

1. 协程就是一个线程框架，它可以很方便地进行线程切换；
2. 非阻塞式挂起，也就是协程内部切线程了，所以当前调用协程的线程不会被阻塞，它可以继续做其他的事情。假设协程内部不切线程，那么其实也是阻塞（同步）的；
3. 使用协程可以将异步代码平铺，看起来就像同步代码一样，避免线程切换的各种回调和缩进。

所以当有切线程这样的场景时，就可以使用协程了。

继上篇文章，通过高精度数据可以知道当前车辆的位置，结合考试地图建立好坐标系。那么车辆在这个地图中的一切行为轨迹都将是可以计算的，可以想象成一张蜘蛛网中蜘蛛的移动。那么接下来就是要利用这些数据来做评判了：判断当前车辆是否压线，以及打灯的时长是否足够等等。

在上篇文章中，遗留一个问题：世界坐标系里的坐标，假设 Pos(1000,1000) 这个点即是相对原点往北 10 米，往东 10 米的一个点，而安卓原点在左上角，如何将这个点绘制在安卓屏幕上呢？
其实很简单：直接画。
假设屏幕像素为1920*1080，简单一点让地图 MapView 的宽高也是这个，那么这个点就会在屏幕 (1000,1000) 的位置被绘制出来。世界坐标系中的其他所有的点，也都可以这样直接绘制。只是这样绘制之后，某些点可能在 MapView 上看不到而已，但是所有点的相对位置都是对的。接下来就要祭出大杀器「Matrix」了。

上篇文章已经基本把「科二考试系统」的核心思路描述清楚了，接下来记录一下稍微具体的知识点。

这是一个系列文章的开篇，尝试理解项目中用到的知识与结构，许多代码都是上级编写，我只能以我的能力尽量把东西说清楚，讲明白。

目标

首选抛出一个目标，实现一个「科二考试系统」。这是一个 App，可以借助各种手段来评判这个学员是否按照考试规则进行考试，如果有错误的地方，需要扣分，扣分达到一定程度则考试不合格，下次再来。怎么来实现这样的目标呢？
首先得有具体的考试规则。比如直角转弯需要打转向灯，在哪个地方如果没打灯就需要扣分。比如行驶中开车门，解安全带，曲线行驶压线了，这些都是需要扣分的。
考试规则是最顶层的功能，为了实现这些规则，我们需要车辆信号（车速、挡位、灯信号等等）。信号可以通过车辆自身的 OBD，或者外接很多传感器来实现，比如挡位传感器，比如拓展口（外接一根线，连接到左转灯的灯泡里，就可以拿到左转灯亮、灭的信号了）等。
那么还有一个难以解决的问题：如何判断车辆压线？以我个人的经验，我可能想到的就是通过摄像头拍照，然后结合图像识别技术来评判是否压线。但是这种必须得有真实的线，拍出的照片里得有「线」才能判断得出吧。那假设有一些「不存在的线」（比如电子栅栏）也需要进行判断呢？那就没辙了。所以有另外一种方案：基于「高精度定位」，将所有现实中的物体，映射到一个坐标系中，粗略将车子抽象成一个矩形，那么车辆压线就可以认作是：在一个坐标系中，矩形与线段是否触碰，这就可以理解为是个数学题了。

一个业务场景：科二学员考试系统，当学员做了错误的操作之后，会扣分。那么如何实现这样的一个扣分引擎呢？

1. 检测时机：很显然的我们需要一个定时检测的时机，比如每隔 100 毫秒，或者 1 秒，执行一次检测。这样的话，可以理解为，有一个死循环，持续进行检测。
2. 检测事项：每一次检测需要检测哪些数据，当数据不符合条件，就扣这个分。
3. 引擎状态：当开始考试时，需要启动引擎，进行检测。结束考试时，就停止检测。