Rust 所有权规则简述

对于低级语言而言，对象的回收往往是一个难题。一个对象创建后，往往会在各个地方传递，由于对象的引用者们生命周期不尽相同，也就不知道何时、由谁来负责对象的回收。

Rust 所有权规则是如何解决这个问题的呢？它把对象分为可变对象和不可变对象，对象的引用者分为所有者和借用者。下面是我根据自己的理解做的总结：

• 一个对象有且只能有一个所有者，对象的回收由其所有者负责，对象的所有权可以转移。

• 借用分为可变借用和不可变借用：

  • 多个不可变借用可共存；
  • 可变借用不可和其他借用共存，无论借用是可变还是不可变；
  • 对象所有者不能在不可变借用前写对象，不能在可变借用前读写对象；
  • 可变对象可以有可变和不可变借用，不可变对象只能有不可变借用；

• 对象的所有权转移时，对象的可变性可以发生更改。

不能共存指的是它们的作用域不能有交集。一个变量的作用域从声明的地方开始，到最后一次使用的位置结束，这一点和其他语言不同。

前言

Kotlin 中的协程是无栈协程（话说 Kotlin 能实现有栈线程吗🤔），网上很多文章都说无栈协程一般都是通过状态机实现的，刚开始听到这个状态机的时候觉得有点玄乎，今天打算利用反编译工具并结合协程库源码，来探究一下 Kotlin 协程实现原理。

从一个简单的示例开始

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

fun main() {
    runBlocking {
        val result = fun1()
        println(result)
    }
}

suspend fun fun1(): Int {
    var localInt = 0
    localInt += fun2()
    localInt += fun3()
    return localInt
}

suspend fun fun2(): Int = 1

suspend fun fun3(): Int {
    delay(1000)
    return 1
}

什么是跨源请求

先看同源 URL 定义：

如果两个 URL 的协议、端口（如果有指定的话）和主机都相同的话，则这两个 URL 是同源的。这个方案也被称为“协议/主机/端口元组”，或者直接是“元组”。（“元组”是指一组项目构成的整体，具有双重/三重/四重/五重等通用形式。）

当网页发出请求的 URL 和网页的 URL 是非同源的，我们便说这个请求是跨源请求。安全起见，浏览器会对跨源请求做出限制。

为什么要对跨源请求进行限制

假如你曾经登录过银行网站 A，该网站会将 token 保存在你浏览器的 Cookies 中。某天你收到了一封来自钓鱼网站 B 的邮件，你点开链接打开了 B 网站，B 网站调用 A 网站的转账接口，企图将你在这家银行的钱转进他的帐户里。如果浏览器不对跨源请求做任何限制，A 网站的 Cookies 便会附带到转账请求中，请求就能顺利通过 A 网站服务器的身份验证，你的钱就被转走了。

为了解决这个问题，浏览器引入了 同源策略。

P199： “默认情况下，如果可执行文件是动态连接的，那么 GCC 会使用 PIC 的方法来产生可执行文件的代码段部分，以便于不同的进程能够共享” 但我用 GCC 去编译 32 位可执行文件，加 -fPIC 和不加 -fPIC，编出的指令是有差别的：

学习 vfork 的时候，看到这篇文章中的一个例子，觉得很有趣，就拷贝下来自己跑了一下，其中的例子差不多是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

void fun1() {
    vfork();
    printf("%d\n", getpid());
}
 
void fun2() {
    _exit(0);
}
 
int main() {
 
    fun1();

    printf("%d goes 1\n", getpid());

    fun2();   

    printf("%d goes 2\n", getpid());

    return 0;
}

前言

这两天为了破解魔百盒费了好大劲，看了好多帖子，好在最后破解成功了。为了让大家少走弯路，我把破解方法分享出来，希望能帮助到大家。

盒子型号

我的盒子型号是 CM201-2 长虹代工 (CH)，具体信息见图片：

板子上的硬件信息是：CPU 型号是 HI3890MV300，闪存是 emmc。机型编码和牌照方不同应该没太大关系，大家可以先尝试一下，不行再说。

View 的焦点机制

约定：文章中的 View 有时是指狭义的 View.class，有时指的是 View.class 和 ViewGruop.class 的统称，具体含义根据上下文而定。

和焦点相关的 xml 属性

在 xml 中，有两个比较重要的属性和焦点有关，它们是 focusable 和 focusableInTouchMode。前者决定这个 View 是否可获取焦点，如果它的值为 false，那么它就和焦点无缘了；后者决定这个 View 在触屏模式下是否可获取焦点，如果它的值为 false，那么即使 focusable 的值为 true，在触屏模式下它也无法获取焦点。比如 Button，如果我们通过外接键盘进行操作，我们会发现 Button 是可以获得焦点的，但是在触屏模式下，Button 是不可获取焦点的。所以我们可以知道 Button 的 focusable 属性默认为 true，而 focusableInTouchMode 属性为 false。

Android LaunchMode 总结

Android 中的 LaunchMode 是一个比较基础的知识点，关于这块之前每次都是先用现学，然后学了之后又忘了，现在把 LaunchMode 的规律记录下来以备后用。

需要了解的知识点

在讲 LaunchMode 之前，需要了解一下几点知识：

1. task 有属性 affinity，Activity 有属性 taskAffinity
2. 可以存在两个 affinity 一样的 task；
3. 一个 Activity 的 taskAffnity 默认值为 package name，如果有指定值就会设为指定值
   阅读全文 »

Android 事件分发规律总结

定义

事件序列：手指接触屏幕开始到离开屏幕为止产生的事件为一次事件序列。

规律一

从父视图的角度来看，无论他的子视图是 View 还是 ViewGroup，对父视图来说都是透明的。它只知道如果当 ACTION_DOWN 事件传给子视图后子视图的 dispatchTouchEvent () 返回 true，说明子视图想要处理这个事件，那么以后的事件就都交给它，不管以后子视图的 dispatchTouchEvent() 返回的是 true 还是 false; 如果 ACTION_DOWN 事件传给子视图后子视图返回的是 false，那么以后的事件再也不会传给子视图（子视图没有处理 ACTION_DOWN 就视作它不想处理该事件序列）。如果一个子视图的 dispatchTouchEvent() 在处理 ACTION_DOWN 时返回 true ，只要父视图没有拦截事件, 那么该事件序列中的后续事件都会传入该视图中，也就是传入该视图的 dispatchTouchEvent() 方法中，就算手指的触摸区域已经超出了该视图的范围。并且对于该事件序列的之后所有事件，即使该视图的 dispatchTouchEvent() 返回 false 事件也同样会继续传入该视图，唯一的影响是会将该事件原路返回，最终落到 activity.onTouchEvent() 中。因此建议如果消耗了该事件，除非有特殊情况需要处理，最好不要返回 false，否则上级视图以为下面的视图没有处理事件从而自己处理。