Jetpack Compose 探索

Why compose Compose UI 的编写只需要 Kotlin,在遵循 Android 应用架构时,这样更有利于聚合 UI Elements 的代码,不需要去区分 Kotlin 代码和 xml 布局文件,在我看来这种方式更加容易采用 Android 架构指南去控制项目架构。 但从另一方面来讲,Compose 这种嵌套的 UI 组合方式会加深代码层次,因此开发过程中需要对 UI 上各个元素做更细的区分,以增加代码的可读性。另外如果状态使用没有处理好,也会对 Compose 的重组性能带来影响。 完善的声明式 UI Android View 系统设计的时候是遵循 OOP 的,虽然有 XML 可以帮我们减少下面这种命令式代码的使用,但这种声明式构建 + 命令式执行的缺点还是很明显,因为需要一个加载器把布局转化到业务逻辑代码中。 // 命令式 val parent = ViewGroup(); val node = View(); parent.addView(node); 如果按照理想的声明式 UI 编写方式去改造传统 View 系统,那呈现出的代码可能会包括下面两个特点: 节点的构建不应该有返回值 节点的连接不依赖于 API <LinearLayout> <TextView>Hello World</TextView> <MaterialButton android:onCLick="syaHi()">hi</MaterialButton> </LinearLayout> 将上面的布局代码转换为 Java/Kotlin 理想的声明式代码 LinearLayout { TextView("Hello World") MaterialButton("Hi") { syaHi() } } Compose 利用 Kotlin DSL 构建声明式 UI,一个 @Composable 相当于一个节点,在内部也可以调用其他 @Composable 函数构建子节点。...

July 8, 2022

Flutter 绘制流程分析与代码实践

Render Tree 的创建过程 RenderObject 的类型 我们知道 Element 主要分为负责渲染的 RenderObjectElement 和负责组合的 ComponentElement 两大类,而创建 RenderObject 节点的是前者 mount() 方法中调用的 RenderObjectWidget.createRenderObject() 方法。 该方法是一个抽象方法,需要子类实现,对于不同的布局的 Widget 创建的 RenderObject 类型也不一样,在 Render Tree 中最主要的有两种 RenderObject: 首先是在 RenderObject 注释说明中大量提到了一个类 RenderBox,它是大部分的 RenderObjectWidget 所对应的 RenderObject 的抽象类 /// A render object in a 2D Cartesian coordinate system. /// 一个在 2D 坐标系中的渲染对象 abstract class RenderBox extends RenderObject 以及 Render Tree 的根节点 RenderView /// The root of the render tree. /// Render Tree 的根节点,处理渲染管道的引导和渲染树的输出 /// 它有一个填充整个输出表面的 RenderBox 类型的唯一子节点 class RenderView extends RenderObject with RenderObjectWithChildMixin<RenderBox> 其他的类型的 RenderObject 基本是为了特定布局(如滑动、列表)的实现,但大部分都直接或间接集成自 RenderBox。...

January 11, 2022