Compose组件下对Modifier中padding的理解

Compose组件下对Modifier中padding的理解

前言

开发原生安卓对padding的理解相信对一个成熟的android开发者是非常熟悉的，但是在申明式UI的大背景下，padding却没有了原有的意思，取而代之的只留白的思想，所以本文对Modifier下的padding进行一下分析理解

问题的引出

首先看下面两段代码：

代码一：

Text(
            text = "这是一个textView",
            textAlign = TextAlign.Center,
            fontFamily = FontFamily.Cursive,
            modifier = Modifier
                .wrapContentWidth()
                .wrapContentHeight()
                .clip(RoundedCornerShape(20))
                .background(Color.Red)
                .padding(20.dp),
            color = Color.White,
            fontSize = 14.sp,
        )

代码二：

Text(
            text = "这是一个textView",
            textAlign = TextAlign.Center,
            fontFamily = FontFamily.Cursive,
            modifier = Modifier
                .wrapContentWidth()
                .wrapContentHeight()
                .clip(RoundedCornerShape(20))
                .padding(20.dp)
                .background(Color.Red),
            color = Color.White,
            fontSize = 14.sp,
        )

会出现两个不同的结果：

效果一：

image.png

效果二：

image.png

难道bg与padding的顺序不一样，呈现的效果不一样？

答案确实是这样的：bg的顺序与padding的顺序不一样，呈现的效果确实不一样，这需要明白链式调用渲染的道理

为什么放置的顺序不一样，padding的效果会大不同呢？

首先我们来看官方对padding的定义是什么？

image.png

大致看了一下与android中padding似乎都是同一个意思，就是留出空白，但是这里基准是元素本身（废话）

链式调用渲染的逻辑就是一层层的进行分割渲染，在compose中没有了margin的概念，也没有了android xml中padding内边距的概念，所以这里的padding只有一个概念就是留白，这里的白并不是指的白色，而是原来是什么颜色就是留这个颜色。

要理解这个概念可以先来看下面这段代码：

 Text(
            text = "这是一个textView",
            textAlign = TextAlign.Center,
            fontFamily = FontFamily.Cursive,
            modifier = Modifier
                .padding(20.dp)
                .wrapContentWidth()
                .wrapContentHeight()
                .background(Color.Red)
                .clip(RoundedCornerShape(20)),
            color = Color.White,
            fontSize = 14.sp,
        )

image.png

将padding放在了设置宽高之前，所以呈现出来的就有了上面的类似于android xml中的margin效果，这里可以这样来理解：

基于元素本身是置顶的，这个时候先进行了padding，所以在元素周围都留出了20dp的空间，由于物理屏幕是不可变的，怎样来展现这20dp的空间呢？那就直接把组件向下移动20dp，左右也拓展20dp，这样就形成了原生android中的margin现象

我们继续拓展这个理解

进行下面的代码验证：

Text(
            text = "这是一个textView",
            textAlign = TextAlign.Center,
            fontFamily = FontFamily.Cursive,
            modifier = Modifier
                .padding(20.dp)
                .wrapContentWidth()
                .wrapContentHeight()
                .background(Color.Red)
                .padding(20.dp)
                .clip(RoundedCornerShape(20)),
            color = Color.White,
            fontSize = 14.sp,
        )

呈现出来的效果如下：

image.png

继续来分析理解，可以这样来看待这个结果：
首先进行了padding，所以出现了上一次的情况，整个组件向下移动了20dp，这个时候再进行background，是基于元素的background，所以元素空间变成了红色，然后再进行了padding，因为上一次元素空间已经变成了红色，所以再进行padding的时候继续向四周拓展20dp，所以出现了红色块左右上下都拓宽了20dp，这个时候加上原来的20dp总共就是40dp，所以元素看着向下移动了40dp，左右两边其实都预留了40dp出来，只是物理屏幕看不出来而已

虽然没有margin的概念，在讲解中也只是用到了padding的all属性，但是并不是没有设置左右上下的具体属性，可以通过以上的概念方式加上自定义的属性使用进行业务的扩展，例如源码中的PaddingValues进行具体的设定。

image.png

结尾

进过上面的讲解，应该对compose中的padding有来一个全新的认识，并不是android原生中的padding内边距的概念，也没有了margin的概念，但是这样的设计既解决了内边距也解决了margin的功能，一举两得，所以在使用padding的时候一定要根据业务的需求进行顺序的链式调用才能真正的做到padding灵活运用