文档教程知识库【免费下载链接】android-tech-frontier【停止维护】一个定期翻译国外Android优质的技术、开源库、软件架构设计、测试等文章的开源项目项目地址https://gitcode.com/gh_mirrors/an/android-tech-frontier点击查看免费下载本文依据 android-tech-frontier 仓库 中收录的译文《简化Android的UI开发》原文作者 Zaitsev Serge译者 chaossss校对 ZhaoKaiQiang整理扩写。文中介绍了一种把 Web 端「虚拟 DOM」思想移植到 Android 的方案用嵌套的v()调用以纯 Java 声明布局、以属性设置结点绑定数据与监听器、在用户交互后自动重渲染差异部分从而摆脱臃肿脆弱的 XML 布局。读完本文你将理解这一方案的完整数据结构、渲染流程与自动重渲染机制并能基于文中不到 250 行的核心思路设计自己的声明式 UI 框架。一、Android UI 开发为什么如此痛苦在 Android 上写 UI代码往往是支离破碎的——大量模板化代码、没有结构可言。原文作者Zaitsev Serge其博客文章《Android UI development made easy》开篇就列出了几个纯属个人见解的问题Android UI 开发很少符合 MVC或 M-V-任何其他东西模式Activity/Fragment 既要管业务逻辑又要管视图细节职责混杂XML 文件包含大量重复代码代码复用性差相似的布局要反复复制粘贴抽成 include、style 的代价又很高XML 非常脆弱写错了控件名例如把TextView打成TextVeiw编译期编译器不会报任何警告直到 App 运行到该布局时才会抛出InflateException缺少对 styles 的支持缺少对变量的支持不支持宏和计算结果例如10dp 2px这种表达式无法在 XML 中直接书写没有数据绑定必须自己把所有的findViewById和setOn...Listener一个个写出来用 Java 代码直接构造布局虽然可行但写出来的代码「有如天书」冗长且难以阅读。简而言之定义布局在一个目录使用布局在另一个目录再在 UI 代码里手工改变视图状态——这样的开发方式既不安全、也不高效。二、Web 端的启示从 jQuery 到虚拟 DOM 与 Mithril.js面对同样的问题Web 开发者们早就开始了自救。在缺少 MVx 框架时开发复杂应用非常吃力于是大家意识到 jQuery 式「拿到元素、逐个改属性」的写法存在结构性缺陷先后催生了 Backbone、Knockout、Angular、Ember 等框架。而 Android 上的常见做法与 jQuery 时代几乎如出一辙——只是把选择器换成了findViewById// Web 的 jQuery 写法 $(.myview).text(Hello); $(.myview).on(click, function() { ... }); // Android 的传统写法 myView.setText(Hello); myView.setOnClickListener(new View.OnClickListener() { ... });随后React.js 给 Web 开发带来了一个关键转折以树状关系的自定义对象创建「虚拟 DOM」来描绘实际的 HTML 布局。虚拟树创建和切换的开销都很小当实际 DOM 需要被渲染时框架对比「前一棵虚拟树」与「新的虚拟树」只把不匹配的部分渲染出来。Mithril.js 则是一个精悍、短小的框架它让 React 的思路变得更整洁除了纯 JavaScript几乎摆脱一切框架束缚同时让你在写布局时能享受到「图灵完备语言」带来的力量return m(div, m(p, someText), m(ul, items.map((item) m(li, item))), m(button, {onclick: myClickHandler}));用这样的写法你能用循环生成许多 View能用条件语句改变布局中的某个部分最后还能绑定数据和设置事件监听器。那么——这个方法能否被移植到 Android 中这正是本文后续要回答的问题。三、虚拟布局把虚拟 DOM 的思想搬到 Android虚拟布局virtual layout借鉴了 Web 端虚拟 DOM 的概念它是一棵由自定义 Java 对象组成的树用于描述实际的 Android 布局而不是直接操作真实的 View。工作流程是无论 App 数据改变多少次树都会被重新构建但最终真正变化的布局内容应该仅仅是前后两棵树不一致的部分当前布局与改变前布局的差异。作者设计框架时只导入一个静态类因此所有静态方法都可以不带类名前缀直接使用例如直接用v()而不是Render.v()——这是利用 Java 静态导入的语言特性带来的书写便利。下面是如何创建布局的示例v(LinearLayout.class, orientation(LinearLayout.VERTICAL), v(TextView.class, text(someText)), v(Button.class, text(Click me), onClick(someClickHandler)));这里的第一个v()方法返回一个虚拟布局结点每一次调用后它返回的是当前应用状态的展示注意不是实际的 View。当某个文字变量被改变时虚拟树中对应的结点值发生变化框架在下一次渲染时针对这个差异调用setText()更新相应的 TextView 实例而其余的布局不发生任何变化——这正是「只渲染差异部分」的核心价值。四、核心数据结构Node 与 AttributeSetter一棵虚拟布局树在理想情况下应该只有一种类作者把它称为结点Node。但结点主要有两种类型View 结点——对应TextView.class等真实 View 类属性设置结点——例如text(someText)负责对某个 View 设置属性。这意味着结点需要能「任意」地包含一个 View 类以及一个用于改变 View 属性的方法。对应的最小实现如下interface AttributeSetter { public void set(View v); } public static class Node { ListNode attrs new ArrayListNode(); Class? extends View viewClass; // for view nodes AttributeSetter setter; // for attribute setter nodes public Node(Class? extends View c) { this.viewClass c; } public Node(AttributeSetter setter) { this.setter setter; } }从源码结构看Node是一个高度自洽的树结点attrs保存子结点列表既可以是子 View 结点也可以是属性设置结点viewClass标记 View 类型setter则封装「如何修改一个 View」。这样的设计让一棵树可以同时承载结构与行为。4.1 Renderable谁拥有这棵虚拟布局树有了 Node 还不够还需要定义「产生虚拟布局」的载体。作者将其称为可渲染类Renderable——它可以是一个 Activity、一个自定义的 ViewGroup甚至是一个 Fragment。每一个可渲染类都应该提供一个返回虚拟布局的方法最好还能指明该方法作用于实际布局中的哪个 Viewpublic interface Renderable { Node view(); ViewGroup getRootView(); }4.2 v()声明式 API 的入口由于v()的第一个参数是 View 子类的泛型Class? extends View类型安全性得到了保证其余参数都是结点类型实现时只需要把它们添加到子结点列表中——如果遇到空结点直接忽略会更好public static Node v(final Class? extends View cls, final Node ...nodes) { return new Node(cls) ; }4.3 属性设置器text() 的示例实现下面是text()属性设置器的示例原文注明实际代码会略有差异但完全可以按这样的思路实现public static Node text(final String s) { return new Node(new AttributeSetter() { public void set(View v) { ((TextView) v).setText(s); } }); }其他类似的工具方法也能用于改变线性布局的方向、View 的大小、页边距、间距——总而言之所有 View 可配置的参数都能被封装成这样的属性设置结点。这也是整个框架可扩展性的根基每新增一个工具方法就等于为声明式布局语言新增一个「关键字」。五、渲染器 inflateNode把虚拟树变成真实 View接下来需要一个「渲染者」它能够根据类名创建 View使用AttributeSetter修改对应参数并递归地添加子 View。public static View inflateNode(Context c, Node node, ViewGroup parent) { if (node.viewClass null) { throw new RuntimeException(Root is not a view!); } // Exception handling skipped here to make the code look shorter View v (View) node.viewClass.getConstructor(Context.class).newInstance(c); parent.addView(v); for (Node subnode: node.attrs) { if (subnode.setter ! null) { subnode.setter.set(v); } else { View subview inflateNode(c, subnode, (ViewGroup) v); } } return v; }这段代码揭示了渲染的完整调用链检查根结点确实是 View 结点viewClass非空否则直接抛出RuntimeException通过「带 Context 的构造器」反射式地newInstance创建真实 View原文简化了异常处理真实工程中需要补充NoSuchMethodException、InstantiationException等处理把新 View 加入父容器parent遍历子结点若是属性设置结点则调用setter.set(v)修改属性若是 View 结点则递归inflateNode挂载子视图返回创建出的 View。到这里我们已经真正摆脱 XML并以一种简洁的方式通过 Java 完成布局。需要注意两点原文中的简化点布局结点不应该被直接使用而应通过render(Renderer r)重渲染某个 View和render()重渲染所有被展示的 View这两个入口来间接使用Renderer 通过弱哈希表存储因此当 View 被移除或 Activity 被销毁时对应的渲染者也会随之失效避免内存泄漏。六、自动重渲染什么时候去渲染这个框架的核心卖点是自动重渲染UI 总能展示当前的虚拟布局状态。因此render()应该在某个「特定节点」被调用——作者参考 Mithril 的做法把每一个On...Listener与「调用 render 的方法」捆绑在每一次 UI 交互中public static Node onClick(final View.OnClickListener listener) { return new Node(new AttributeSetter() { public void set(View v) { v.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { listener.onClick(v); // After the click was processed - some data may have been changed // so we try to re-render the UI render(); } }); } }); }这样的设计是有道理的大多数 Android 应用的数据都是在用户交互发生时被改变的。点击事件处理完毕后数据可能已经变化此时调用render()重渲染差异部分即可让 UI 与数据保持一致而如果你的数据是因其他因素网络回调、后台线程等改变的则只能手动调用render()。结合前文对 MVVM 模式 的介绍可以看出这种「交互 → 数据变化 → 自动刷新视图」的闭环实际上已经触及了数据驱动 UI 的思想只是它用「事件处理完毕后自动重渲染」来实现而非依赖官方的可观察字段机制。七、总的来说这个方法可行吗作者总结道这个方法虽然简单却非常有用你能用类似 XML 的方式定义布局结构——通过嵌套调用v()方法你能用一种清晰易懂的方式绑定数据和监听器布局是类型安全的你的编译器会自动完成相应的工作不再有运行期InflateException的隐患没有运行时产生的开销没有使用反射机制没有自动生成代码注意inflateNode中的newInstance是创建 View 实例的必要手段框架本身并未依赖反射做属性绑定你能在任何地方使用 Java变量、语句、宏生成布局——循环、条件分支、函数复用都是天然能力你能使用自定义 View和自定义的属性设置方法因为所有 UI 数据都被保存在属性中因此你能轻易地保存它们便于状态恢复使用纯 Java 实现这些逻辑需要的代码还不到 250 行正是这种极低的实现成本证明了这个方法是可行的。作者在文末直言现在我在想如果有人想要用这个方法开发一个功能齐全的库呢八、走向完整库区分算法与自动生成设置器要把这个原型发展成功能齐全的库作者指出了两个关键难点。8.1 设计一个好的「区分diff」算法自动重渲染的核心在于判断一个结点是否被添加 / 移除 / 修改难点集中在属性结点上对于简单的数据类型调用equals()比较两个值即可但监听器Listener怎么办v(SomeView.java, onClick(v ...));每一次虚拟树被创建onClick都会创建一个全新的监听器对象——两棵树中的监听器永远不会equals()。于是必须回答怎么去比较它们还是永远不更新监听器、只更新那些确实发生了改变的监听器类抑或干脆放弃监听器改用某种事件分发机制例如事件总线 / 事件流来解耦这些设计取舍直接决定了一个声明式 UI 框架在「对比差异」环节的健壮性与性能表现。8.2 不想手写所有设置器借鉴 Kotlin Koan另一个现实问题是作者不想自己把全部属性设置方法一个个写出来。更好的思路是像 Kotlin 的Koan库那样做——用语言/工具特性批量生成。作者明确表示正在研究如何从 android.jar 的类中自动生成设置器以让这个项目更有用从项目本身的设计看这可以理解为解析android.jar中各 View 的 setter 签名自动生成对应的Node静态工厂方法从而避免手工维护数百个工具方法。作者将当时的全部代码以MIT 许可开源为 Anvil 库并欢迎大家评论和提交 PR——在 Android 官方 Data Binding 尚未成熟的那个年代这属于社区对「声明式 UI」的早期探索。九、与官方 Data Binding 的呼应殊途同归值得注意的是这个仓库同期收录了多篇关于 Android 官方数据绑定框架的文章恰好构成一组完整的对照阅读材料Android双向数据绑定介绍利用官方 Data Binding 让两个EditText绑定同一 bean、输入实时互显的场景属于「双向绑定」Android数据绑定-再见Presenter,你好ViewModel讲述 Data Binding 如何接管 Presenter 的职责推动架构从 MVP 走向 MVVM数据绑定(Data Binding)-Part1-Part1.md) 到 Part5-Part5.md)系统讲解官方数据绑定框架的使用与原理。对比之下可以看到两条路线殊途同归官方 Data Binding 通过XML 中的{...}表达式在编译期生成绑定代码需要编译期代码生成而本文的方案则把布局与绑定全部收拢到纯 Java用虚拟树 diff 在运行期完成增量更新把布局编写重新交还给图灵完备的语言。两者要解决的是同一个问题——UI 与数据状态的一致性与可维护性——只是实现哲学不同。结语本文完整还原了「虚拟布局」这一 Android UI 声明式方案的思路以Node树描述布局、以AttributeSetter封装属性变更、以inflateNode递归实例化真实 View、以交互监听器触发自动重渲染全程不超过 250 行 Java 代码。这套思想后来也在各类声明式 UI 库中不断得到印证把「界面 状态到视图的映射」作为核心抽象把 diff 交给框架把开发者从findViewById与 XML 解析的泥潭中解放出来。关联原文译文见 others/简化Android的UI开发/readme.md仓库还收录了 MVVM 模式简介 与官方 Data Binding 系列-Part1.md)可配合阅读从架构模式与官方实现两个维度理解 Android UI 数据驱动化的演进。赞分享文档教程知识库【免费下载链接】android-tech-frontier【停止维护】一个定期翻译国外Android优质的技术、开源库、软件架构设计、测试等文章的开源项目项目地址https://gitcode.com/gh_mirrors/an/android-tech-frontier点击查看免费下载相关推荐洛雪音乐音源完全指南从零开始打造你的专属音乐库洛雪音乐音源完全指南从零开始打造你的专属音乐库 在这个音乐流媒体服务层出不穷的时代你是否曾为寻找真正免费且高品质的音乐资源而烦恼今天我将带你深入了解一个音视频AndroidSwipeLayout与数据绑定简化滑动布局中的数据处理AndroidSwipeLayout与数据绑定简化滑动布局中的数据处理 在Android应用开发中滑动操作是提升用户体验的重要交互方式。AndroidSwi移动开发UI组件如何将Pace集成到Vue/React项目AMD与Browserify场景的完整接入指南如何将Pace集成到Vue/React项目AMD与Browserify场景的完整接入指南 Pacepace js是一个自动为网站添加顶部进度条的轻量库自前端上一篇XiangShan XSPdb 批处理执行机制从 CLI 参数、脚本重放到波形回调的自动化调试实现下一篇mixwith.js API 完全解析从 apply() 到 mix().with() 的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
