[关闭]
@rogeryi 2017-01-20T08:51:51.000000Z 字数 1635 阅读 512

对页端开发高性能(交互/动画) Mobile WebApp 的一些思考

WebApp


一个高水平客户端应用 UI 的开发者,通常需要满足以下的一些条件:

  1. 熟悉跟渲染有关的基本概念,比如 2D 绘图,光栅化,合成;
  2. 对所使用 UI Toolkit 的渲染流水线有较深的了解;
  3. 掌握 UI Toolkit 里面的 View/Layer 等概念,知道在满足布局/交互的需求下,如何构建一个性能最佳的 View/Layer Hierarchy;
  4. 掌握 UI Toolkit 提供的性能分析工具,能够对应用的 UI 性能(交互/动画)进行分析,找出性能瓶颈;
  5. 掌握常见的最佳实践和优化技巧;

虽然上述条件略高,但是满足条件或者起码部分满足条件的客户端开发者数量上应该还是不少的。国内互联网公司里面,比较成熟的客户端应用开发团队,起码都会有一两位。

假设我们把上述条件稍微进行修改,写一个针对页端的 WebApp UI 开发者的版本:

  1. 熟悉跟渲染有关的基本概念,比如 2D 绘图,光栅化,合成;
  2. 对浏览器内核的渲染流水线有较深的了解;
  3. 掌握浏览器内核里面的 DOM/Render Layer/Compositing Layer 等概念,知道它们之间的映射关系,知道在满足布局/交互的需求下,如何构建一个性能最佳的 Compositing Layer Hierarchy;
  4. 掌握浏览器提供的性能分析工具,能够对 WebApp 的 UI 性能(交互/动画)进行分析,找出性能瓶颈;
  5. 掌握常见的最佳实践和优化技巧;

假如我们使用上述条件进行过滤,恐怕这次满足条件甚至部分满足条件的页端开发者就是凤毛麟角了。页端和客户端的开发者在这方面的差异,它的原因是什么,要填补上这个差异的困难又是什么,以下是自己的一些思考。

客观的原因

  1. 客户端 UI 开发者在 UI Toolkit 提供的编程环境中,需要直接操作 View/Layer/Canvas,而页端 UI 开发者在浏览器提供的编程环境中,直接面对的是更高抽象层级的 DOM/CSS,这也意味着页端离底层更远 ,这本身是页端开发的一个优势,但在降低了开发门槛的同时也容易导致对底层运行机制理解和掌握的不足;

  2. 浏览器的渲染流水线通常比 UI Toolkit 更复杂,首先是因为浏览器本身需要处理的源对象是更高抽象层级的 DOM/CSS,其次浏览器的渲染流水线本身不是完全独立的,它自身也是一种客户端应用,跟其它客户端应用一样,需要基于平台的 UI Toolkit 来完成完整的渲染和交互;

  3. 基于 UI Toolkit 公开的入门指南,最佳实践,甚至内部运行机制分析等文档资料和书籍更多且更系统,而浏览器引擎相关的公开文档资料则非常少且零散,而从页端的角度写的,能够为页端所理解的就更少了;

主观的原因

客户端的开发有着更悠久的历史,相应的开发技术和方法论更成熟,也因为其开发门槛较高,一般而言开发团队的工程化和专业化的程度也更高。

而 Web 开发还是正处于一个传统文档流类型网页转向 WebApp 应用类型网页的过程中(即使浏览器本身也还处于一个逐步进行技术演进的过程),两种不同类型的网页所需要的开发技术和方法论有所差异,工程化和专业化的要求程度也不同。

页端团队自身也还在适应这个过程,一方面在语言/框架/工具/规范方面的工程化程度已经达到较高的水平,但是另一方面,适应应用开发的开发技术和方法论的掌握还不足,专业化程度也并不够,在专业领域知识/经验的积累和传承,领域专家的培养,不同专业领域的分工协作等方面还有很大的提高空间。

最后的思考

我个人相信,基于 Open Web 技术开发的 Mobile WebApp 应用,按当前现状的普遍质量而言,在交互/动画方面还有很大的提高空间。但是这需要内核开发者和页端开发者的共同努力,一方面内核开发者需要进一步加速内核的技术演进,使之更适应 WebApp 的开发,并且内核开发者应该更主动地输出相应的工具,知识和经验来帮助页端开发者;另一方面,页端开发者也需要进一步掌握应用开发的开发技术和方法论,提高开发团队的工程化和专业化程度。

Make The Open Web Great Again!

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注