Compose原理

原理"/>

Compose原理

前言：

compose目前是越来越火了，19年

其原理一篇文章是远远讲不完的，所以准备做成一个系列来讲。

今天第一篇，我们就来说一说Compose设计原理， 用最通俗的方式来聊一聊。

一.原生XML布局的弊端

讲compose原理之前，我们可以先回头想一想，原生的XML的布局有哪些问题？

1.性能问题。

虽然比H5一类的好得多，但是其自身的弊端也是存在的。我认为最大的问题就是多层嵌套的时候，绘制的计算复杂度成指数型增长。所以这就造成了如果我们的布局嵌套层级过多的时候，就会发现刷新会有卡顿，绘制效率特别的低。

2.加载问题。

布局文件XML最终打包进APK的时候，仍然是XML的形式。而把XML转换成ViewGroup的实际是在inflate或者setContentView的时候（第二个其实最终调用的也是第一种方式）。而读取XML属于IO操作，解析XML成ViewGroup也有大量的逻辑存在，所以这个耗时是无法避免的。一般的页面加载XML的时间都在30ms左右，这就造成了启动Activity的时候，要多耗费30ms的时间。

3.跨平台问题。

这个原因比较简单，如果H5的话只需要开发一套，安卓/IOS/网页都可以使用。但是如果三端都各自开发的话，则就需要三倍的工作量去开发。

二.如何解决：

很早之前就想过这个问题，所以我在个人的项目上也做过一定的尝试，有的效果不错，有的则失败了。

解决性能问题

针对上面提到的第一个性能问题，我觉得最大的问题就是为了保证绝对的安全，所以造成无用的计算太多了，而且是指数形式的计算。所以我在个人的项目中有时候会有一些十分复杂的布局或者元素特别多的布局，就会尝试直接返回宽高，而不去计算其子View的宽高。等到执行draw的时候，一次性去计算完成，每个子View只计算一次，然后直接使用canvas绘制。这个最终效果其实是不错的，具体可以看我的另外一篇文章有专门的介绍：

解决加载问题：

针对上面的第二个加载问题，之前朋友给过一个提示，在编译打包的时候插入自定义gradle任务，把布局文件转换为编译好的class文件进行打包。这个简单实现了一下，效果其实是很不错的。但是问题就是会有很多自定义View中也加载了xml文件，所以要兼容的点太多了。而且XML替换为View之后，调用处的代码也需要修改，然后重新编译， 会就变得十分的复杂。当然，理论上是行得通的，只是复杂度的问题。

解决跨平台问题：

java其实是跨平台的，那么基于java的安卓其实也完全可以做到跨平台。至少可以针对某块功能跨平台。和java跨平台的原理类似，布局这块负责逻辑计算，最终只要下发绘制命令给Native层，然后转发给硬件端。

三.Compose如何解决的

初步看完了compose的原理，我简直惊呆了，其设计思想就和我上面的优化想法简直是不谋而合。当然，区别也肯定是有的。

Compose中去计算区域使用的是基于LayoutNode的方式，每个view对应一个LayoutNode。简单来说，就是Compose针对测量进行了优化，每个节点只会计算一遍，效率则大幅提升。

加载的问题更不存在，因为布局本身就是使用KT写的，所以不存在解析的问题。

跨平台这块，只要支持虚拟机就可以执行其解析逻辑，把最终的产物硬件去绘制。在安卓上的绘制载体竟然仍是canvas。也就是说，其实在安卓上，只是换了一种方式写布局而已，其最终的绘制方法都没变。