不可变和线程安全
大多数线程安全问题，来源自对可变对象的并发读写。以下是一个在java中的典型并发问题代码片段：
image.png
如果多个线程调用同一个SomeExampleClass对象的getThisOrThat方法时，就会出现一个典型的竞争条件。当第二个线调用此方法并尝试读取mCount变量时，第一个线程此时可能正在执行mCount++操作，因此，我们就无法确定第二个线程将会读取到什么值。这个问题的根本原因，就是多个线程尝试读写了一个可变对象mCounter。一般来说，当我们遇到将计算分配到各个不同线程中去计算的问题时，竞争条件是最常见的问题。
竞争条件的存在，导致了在多线程中处理UI问题变得特别复杂。在Android中，view对象都都是富有状态并且状态可被改变。例如TextView，在保持当前文本的同时，需要给开发者暴露setText()的方法，允许改变其状态。这意味着在Android系统中，如果UI框架打算在其他线程中执行耗时计算（如layout）时，框架就必须解决在耗时计算的同时，对象的状态可能被其他线程修改的问题。
让我们暂时回到我们的示例代码上。之前我们阐述过，主要问题是来源于getThisOrThat()方法中访问了一个可变对象mCounter。因此，是否可以找到一个功能上等价但是不用依赖这些可变状态的方法实现？我们先设想存在一个，一旦创建，就无法改变的对象。在这样的对象中，如果没有状态可以被修改，那么我们就不会出现之前提到的竞争条件。我们尝试重写之前的示例代码：
image.png
目前，SomeExampleClass中不再存在任何可以被修改的状态，因此可以说，这个方法是完全线程安全的。getThisOrThat()方法可以被称做一个纯净的函数(‘pure function')，其返回的结果仅仅依赖于输入参数而不产生任何副作用。
在Litho中，我们试图在layouti计算中，严格应用相同的概念。一个Compoent是一个包含了所有layout计算相关参数（使用注解@Prop和@State标记）的不可变对象。这也解释了为什么我们需要@Prop和@State注解来实现不可变，如果不存在这些注解，我们就无法把layout计算作为一个纯净的函数(‘pure function')
同步和异步操作
Litho为layout计算提供了同步和异步的APIs。这两个API都是线程安全的，并且可以通过任意线程去调用。最终的layout总是由最后一次setRoot()或者setRootAsync()方法的调用决定。
同步layout计算保证在ComponentTree调用setRoot()后，计算结果能立刻被加载到LithoView中。而这种计算的主要缺点在于，计算会发生在被调用的线程。因此，在主线程调用setRoot()是不建议的。另外，在某些情况下，你可能不允许等待后台线程计算完毕再显示到屏幕上，此时同步的调用setRoot()是最好的解决办法。支持同步操作使得Litho能够很容易的和现有的线程模型兼容。如果你的应用已经具有了一个复杂的线程设计，你可能不想将layout计算移植到Litho内建的线上中去计算。
异步layout计算将允许Litho使用layout thread去计算Component layout。这意味着，计算工作将会被立刻放到一个计算队列当中，而计算结果不会立刻出现在调用者线程中。异步layout计算的样例可以在RecyclerBinder中查看。
网友评论