Android淘宝首页高仿源码：RecyclerView多类型布局+自定义UI组件封装

本文还有配套的精品资源，点击获取

简介：直接可运行的Android淘宝首页UI实现，重点还原首页的商品推荐、轮播Banner、分类入口、活动横幅等典型区块。底层基于RecyclerView多Item类型（MultiViewType）动态加载不同内容模块，结构清晰、扩展性强。内置多个开箱即用的自定义View：带图标文字的导航按钮、支持圆角/阴影的商品卡片、可配置指示器与自动轮播的Banner控件，并完整演示attrs.xml属性定义、TypedArray解析及XML中属性调用全过程。项目采用标准Android工程结构，包含app模块、规范资源目录（drawable/layout/values）、基础工具类和真实设备截图，Gradle配置完整，适配主流Android Studio版本，无第三方依赖，导入即编译运行。适合深入理解RecyclerView高级用法、UI组件封装逻辑、Android界面分层设计与自定义属性实践。

1. 项目概述：为什么一个“淘宝首页高仿”值得你花两小时细读

如果你正在Android开发路上摸索UI架构、组件复用和RecyclerView的真正威力，而不是只停留在“写个列表显示数据”的层面，那这个项目就是你该停下来认真拆解的典型样本。它不是那种堆砌了二十个第三方库、靠一行Glide加载图片就敢叫“高仿”的半成品；它是一套从设计意图出发、用原生能力扎扎实实把淘宝首页核心区块——轮播Banner、商品瀑布流、图标导航入口、活动横幅、猜你喜欢推荐——全部用RecyclerView多类型（MultiViewType）+ 自定义View封装的方式落地的工程实践。关键词里写的“RecyclerView多类型”“淘宝首页仿写”“自定义View组件”，每一个都不是虚词，而是贯穿整个代码结构的骨架逻辑。

我带过不少刚出校门的安卓实习生，他们第一次看到这个项目时，第一反应往往是：“不就是个首页？切几个布局文件不就完了？”但真正动手去改一个Banner的指示器颜色、给商品卡片加个点击反馈动画、或者想在分类入口里新增一个带角标的图标按钮时，才意识到：如果没把UI拆成可配置、可复用、可独立测试的组件，光靠复制粘贴layout.xml，三天后连自己写的代码都看不懂。而这个项目，恰恰是用最朴素的Android原生API，把“组件化思维”刻进了每一行XML和Java/Kotlin里。它没有用任何MVVM框架、没有引入Dagger做依赖注入、甚至没上协程——但它把attrs.xml怎么定义、TypedArray怎么安全解析、onMeasure()里如何处理wrap_content与match_parent的冲突、RecyclerView.Adapter中getItemViewType()如何与业务状态解耦这些“教科书里一笔带过、实际开发中天天踩坑”的细节，全都在真实场景里给你摊开了讲。它适合两类人：一类是刚学完RecyclerView基础、正卡在“怎么让不同样式的数据共用一个RecyclerView”的同学；另一类是做了两年业务开发、开始思考“为什么每次改一个按钮样式都要动三个模块”的中级开发者。前者能照着抄作业快速上手，后者能从中拎出一套可迁移到自己项目的UI分层规范。

2. 整体设计思路拆解：为什么非得用MultiViewType，而不是Fragment或ViewPager？

2.1 核心矛盾：首页不是静态页面，而是动态内容容器

淘宝首页表面看是固定几个区块，但背后是强运营驱动的：今天主推双十二，Banner要置顶；明天做品类日，分类入口要临时增加一个“数码配件”Tab；后天算法推荐模块要AB测试两种排序策略。如果用传统方式——每个区块写一个Fragment，再用ViewPager或BottomNavigationView切换——看似模块清晰，实则埋下三个硬伤：

• 首屏加载慢：ViewPager默认预加载左右两个页面，首页的“猜你喜欢”可能包含上百条商品，一上来就初始化三套RecyclerView，内存直接飙到80MB以上，低端机秒变卡顿；
• 状态同步难：Banner自动轮播需要全局生命周期感知，Fragment A里的Banner开始滚动，Fragment B里的商品列表却还在执行耗时的图片解码，结果用户滑动时主线程被Block；
• 数据耦合重：所有Fragment都得从同一个ViewModel取首页数据，但每个Fragment只关心其中一部分字段（Banner只关心url和title，商品列表只关心price和picUrl），强行共享一个大JSON，不仅浪费内存，还让数据变更通知变得不可控。

而MultiViewType方案，本质是把首页当成一个单页应用（SPA）式的垂直滚动流：所有内容区块都是同一条RecyclerView的子项，由同一个Adapter统一调度。它不关心“这是Banner还是商品”，只关心“当前这条数据该渲染成什么类型”。这种设计天然契合首页的业务特征——内容虽异构，但滚动行为一致、生命周期统一、数据源单一。

2.2 MultiViewType不是炫技，而是为了解耦“数据结构”与“UI表现”

很多人误以为MultiViewType就是getItemViewType()返回不同数字，然后onCreateViewHolder()里一堆if-else。这恰恰是本项目最值得学习的第一课：它用数据驱动视图类型，而非硬编码判断。

看它的数据模型设计：

sealed class HomeItem { data class BannerItem(val banners: List<Banner>) : HomeItem() data class CategoryItem(val categories: List<Category>) : HomeItem() data class GoodsItem(val goodsList: List<Goods>) : HomeItem() data class AdBannerItem(val ad: AdBanner) : HomeItem() }

注意，这里没有type: Int字段。getItemViewType()的实现是：

override fun getItemViewType(position: Int): Int = when (items[position]) { is BannerItem -> VIEW_TYPE_BANNER is CategoryItem -> VIEW_TYPE_CATEGORY is GoodsItem -> VIEW_TYPE_GOODS is AdBannerItem -> VIEW_TYPE_AD_BANNER }

好处是什么？当你新增一个“直播入口”区块时，只需：
1. 新增data class LiveItem(val liveList: List<Live>) : HomeItem()
2. 在getItemViewType()里加一行is LiveItem -> VIEW_TYPE_LIVE
3. 实现对应的LiveViewHolder和bind()逻辑

完全不用动现有任何一行代码，也不用改网络请求返回的JSON结构——因为后端返回的首页数据，本身就是按区块划分的JSON数组，前端直接映射成List<HomeItem>即可。这种设计让UI层彻底摆脱了对“类型枚举值”的硬依赖，把变化点锁死在数据模型层，这才是真正的面向接口编程。

2.3 自定义View封装：不是为了“看起来高级”，而是解决重复劳动

项目里封装的三个核心组件——IconTextButton、GoodsCardView、BannerView——每一个都直指日常开发中的高频痛点：

• IconTextButton：电商App里至少有10处要用“图标+文字”的按钮（首页顶部搜索、购物车、我的、分类、领券中心……）。如果每处都写一遍<LinearLayout><ImageView/><TextView/></LinearLayout>，改一次图标尺寸就得改10个layout；而封装成自定义View后，XML里一行<com.yus.taobaoui.widget.IconTextButton app:iconSrc="@drawable/ic_search" app:text="搜索"/>搞定，属性修改全局生效；
• GoodsCardView：商品卡片看似简单，但实际需求极多——圆角大小要适配不同机型（全面屏需更大圆角）、阴影深度要区分列表页和详情页、点击反馈动画要符合Material Design规范、图片加载失败时要显示占位图。把这些逻辑全塞进activity_main.xml里？维护成本爆炸。而封装后，app:cardCornerRadius="8dp"、app:cardElevation="4dp"等属性直接控制，且内部已预设好StateListDrawable实现水波纹效果；
• BannerView：轮播控件最易被低估。新手常犯的错是：用ViewPager2硬套，结果发现指示器位置不对、自动轮播停不下来、滑动冲突（用户手指一碰就暂停，松开又继续，体验极差）。本项目BannerView内部用Handler + postDelayed实现精准轮播，通过setUserInputEnabled(false)禁用ViewPager2的手势，再监听onPageScrollStateChanged状态，在SCROLL_STATE_IDLE时才触发下一页，彻底解决“滑一半就跳走”的反人类体验。

这三个组件的共同点是：它们都不依赖Activity或Fragment的上下文，不持有任何业务逻辑，只接受数据并渲染，且所有可变参数均通过attrs.xml暴露为XML属性。这意味着你可以把它复制到任何一个新项目里，改几行XML就能用，这才是组件化的终极目标——不是“能用”，而是“开箱即用”。

3. 核心细节解析：从attrs.xml到TypedArray，手把手拆解自定义属性全流程

3.1 attrs.xml不是摆设：它是组件对外的“说明书”

很多开发者把attrs.xml当成模板文件，复制粘贴完就扔一边。但在这个项目里，res/values/attrs.xml是理解所有自定义View的关键入口。以GoodsCardView为例，它的属性定义如下：

<declare-styleable name="GoodsCardView"> <attr name="cardCornerRadius" format="dimension" /> <attr name="cardElevation" format="dimension" /> <attr name="cardBackgroundColor" format="color" /> <attr name="showShadow" format="boolean" /> <attr name="imageScaleType" format="enum"> <enum name="fitXY" value="0" /> <enum name="centerCrop" value="1" /> </attr> </declare-styleable>

注意三点细节：
-format="dimension"意味着这个属性既支持"8dp"也支持"@dimen/card_radius"，比硬写8更灵活；
-showShadow是布尔值，但实际在View内部，它控制的是setOutlineProvider()和setClipToOutline()的组合调用，而非简单开关elevation——因为Android 5.0以下不支持elevation，必须用LayerDrawable模拟阴影；
-imageScaleType用enum而非string，是因为ImageView.ScaleType本身是枚举类，TypedArray解析时可直接映射，避免字符串匹配错误。

这些设计不是凭空而来。比如cardCornerRadius，项目截图里商品卡片圆角明显比系统默认的4dp更大，这是为了在全面屏手机上提升视觉舒适度——设计师给的标注是12dp，所以属性必须支持dimension格式，才能让UI同学直接在XML里写app:cardCornerRadius="12dp"，而不是让开发同学去代码里改常量。

3.2 TypedArray解析：安全获取属性的唯一正确姿势

拿到TypedArray后，新手常犯的错是直接调用getDimension()或getColor()，结果遇到NullPointerException。本项目GoodsCardView的构造函数里，解析逻辑是这样的：

constructor(context: Context, attrs: AttributeSet?) : super(context, attrs) { val a = context.obtainStyledAttributes(attrs, R.styleable.GoodsCardView) try { // 安全获取：提供默认值，且用getDimensionPixelSize避免小数像素 cornerRadius = a.getDimensionPixelSize(R.styleable.GoodsCardView_cardCornerRadius, resources.getDimensionPixelSize(R.dimen.default_card_corner)) elevation = a.getDimensionPixelSize(R.styleable.GoodsCardView_cardElevation, 0) backgroundColor = a.getColor(R.styleable.GoodsCardView_cardBackgroundColor, ContextCompat.getColor(context, R.color.card_bg_default)) showShadow = a.getBoolean(R.styleable.GoodsCardView_showShadow, true) imageScaleType = when (a.getInt(R.styleable.GoodsCardView_imageScaleType, 0)) { 0 -> ImageView.ScaleType.FIT_XY else -> ImageView.ScaleType.CENTER_CROP } } finally { a.recycle() // 关键！必须回收，否则内存泄漏 } }

重点解析：
-getDimensionPixelSize()vsgetDimension()：前者返回int像素值（如12dp转为36px），后者返回float，而setCornerRadius()需要int，用float会导致精度丢失；
-resources.getDimensionPixelSize(R.dimen.default_card_corner)作为默认值：把默认值抽离到dimens.xml，方便全局统一管理，比如夜间模式下可替换为不同值；
-a.recycle()放在finally块：这是Android官方文档强调的强制要求，TypedArray内部持有资源引用，不回收会导致内存持续增长；
-getInt()解析enum时，用0作为默认值对应FIT_XY：因为设计师通常以FIT_XY为基准，其他模式属于特殊需求。

这套解析逻辑，保证了即使XML里漏写了某个属性，View也能用合理默认值渲染，不会崩溃——这是生产环境组件的基本素养。

3.3 自定义View的生命周期意识：onMeasure()里的“尺寸博弈”

很多自定义View在onMeasure()里直接写死setMeasuredDimension(300, 200)，结果放到ConstraintLayout里宽高失效。本项目BannerView的onMeasure()实现堪称教科书：

override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) { val widthSize = MeasureSpec.getSize(widthMeasureSpec) val widthMode = MeasureSpec.getMode(widthMeasureSpec) // 高度必须由宽度决定：Banner宽高比固定为3:2 val desiredHeight = (widthSize * 2 / 3).coerceAtLeast(minHeight) val heightSize = if (widthMode == MeasureSpec.EXACTLY) { desiredHeight } else { MeasureSpec.getSize(heightMeasureSpec) } setMeasuredDimension(widthSize, heightSize) }

逻辑很清晰：Banner是响应式组件，宽度由父容器决定（比如ConstraintLayout里设为0dp匹配parent），高度则根据宽高比动态计算。这里用了coerceAtLeast(minHeight)确保最小高度不小于120dp，防止在超窄屏幕（如折叠屏半展开状态）下Banner被压扁成一条线。这种写法，让BannerView既能嵌入LinearLayout（wrap_content），也能放进ConstraintLayout（0dp），真正实现“一次编写，多处复用”。

4. 实操过程详解：从零搭建一个可运行的首页模块

4.1 工程结构解读：为什么app模块下只有src/main，没有test或debug？

打开项目目录，你会发现app/src/main/下结构极其干净：

├── java/com/yus/taobaoui/ │ ├── MainActivity.kt # 入口Activity，仅负责setContentView() │ ├── adapter/ # 所有RecyclerView Adapter │ │ └── HomeAdapter.kt # 核心首页Adapter │ ├── model/ # 数据模型，对应HomeItem密封类 │ ├── widget/ # 自定义View组件包 │ │ ├── IconTextButton.kt │ │ ├── GoodsCardView.kt │ │ └── BannerView.kt │ └── util/ # 工具类，如ImageLoader（用Glide封装） ├── res/ │ ├── layout/ # 布局文件，命名规范：item_banner.xml, item_category.xml... │ ├── values/ # attrs.xml, colors.xml, dimens.xml │ └── drawable/ # 矢量图ic_home.xml, ic_cart.xml等

这种结构刻意规避了Android Studio默认生成的test/、androidTest/、debug/等目录，原因很实在：这是一个教学导向的UI演示项目，不是生产级App。删掉测试目录，能让初学者一眼看清“核心代码在哪”；没有buildTypes配置，说明它不涉及签名、混淆等发布流程，专注UI本身。如果你要在自己的项目中借鉴，建议保留test/目录，但把本项目的UI逻辑抽成独立module，这样既能复用，又能单独测试。

4.2 HomeAdapter实现：如何让多类型Adapter不变成“上帝类”

HomeAdapter是整个首页的灵魂，它的代码量不到300行，却完美体现了“职责单一”原则。我们拆解它的关键方法：

onCreateViewHolder()：工厂模式的极致简化

override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder { return when (viewType) { VIEW_TYPE_BANNER -> BannerViewHolder( LayoutInflater.from(parent.context) .inflate(R.layout.item_banner, parent, false) ) VIEW_TYPE_CATEGORY -> CategoryViewHolder( LayoutInflater.from(parent.context) .inflate(R.layout.item_category, parent, false) ) VIEW_TYPE_GOODS -> GoodsViewHolder( LayoutInflater.from(parent.context) .inflate(R.layout.item_goods, parent, false) ) else -> AdBannerViewHolder( LayoutInflater.from(parent.context) .inflate(R.layout.item_ad_banner, parent, false) ) } }

注意：这里没有findViewById()！所有View的查找都在ViewHolder构造函数里完成，且用Kotlin的by lazy委托：

class BannerViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) { private val bannerView: BannerView by lazy { itemView.findViewById(R.id.banner_view) } private val indicator: LinearLayout by lazy { itemView.findViewById(R.id.indicator_layout) } fun bind(bannerItem: BannerItem) { bannerView.setData(bannerItem.banners) // ...绑定逻辑 } }

好处是：bind()方法里直接用bannerView，无需每次findViewById，性能提升显著；且lazy确保只在首次调用bind()时初始化，避免ViewHolder创建时就触发查找。

onBindViewHolder()：数据绑定的“无副作用”原则

override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) { when (holder) { is BannerViewHolder -> holder.bind(items[position] as BannerItem) is CategoryViewHolder -> holder.bind(items[position] as CategoryItem) is GoodsViewHolder -> holder.bind(items[position] as GoodsItem) is AdBannerViewHolder -> holder.bind(items[position] as AdBannerItem) } }

这里强制类型转换（as BannerItem）看似危险，实则是密封类（sealed class）的保障——编译器已确保items[position]必然是这四种类型之一，运行时不会抛ClassCastException。这种写法比用instanceof判断更安全、更简洁。

4.3 BannerView实战：从XML配置到自动轮播的完整链路

在activity_main.xml中使用BannerView：

<com.yus.taobaoui.widget.BannerView android:id="@+id/banner_view" android:layout_width="match_parent" android:layout_height="0dp" app:layout_constraintTop_toTopOf="parent" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintHeight_percent="0.35" app:indicatorGravity="center_horizontal|bottom" app:indicatorMargin="16dp" app:indicatorSelectedColor="@color/orange_500" app:indicatorUnselectedColor="@color/gray_300" app:isAutoPlay="true" app:playInterval="3000" />

关键属性解析：
-app:layout_constraintHeight_percent="0.35"：在ConstraintLayout中占父容器35%高度，配合BannerView.onMeasure()的宽高比计算，实现响应式；
-app:indicatorGravity="center_horizontal|bottom"：指示器居中+底部对齐，符合淘宝设计规范；
-app:isAutoPlay="true"：开启自动轮播，但不等于“一进来就滚动”——BannerView内部在onAttachedToWindow()中才启动Handler，确保View已绘制完成；
-app:playInterval="3000"：3秒轮播，这个值可动态修改，比如进入后台时调用stopAutoPlay()，回到前台再startAutoPlay()，避免耗电。

轮播核心逻辑在BannerView.kt：

private fun startAutoPlay() { if (isAutoPlay && !isPlaying) { isPlaying = true handler.postDelayed(autoPlayRunnable, playInterval.toLong()) } } private val autoPlayRunnable = object : Runnable { override fun run() { if (!isPlaying) return val currentItem = viewPager.currentItem val nextItem = if (currentItem == bannerList.size - 1) 0 else currentItem + 1 viewPager.setCurrentItem(nextItem, true) // true表示带动画 handler.postDelayed(this, playInterval.toLong()) } }

这里用handler.postDelayed()而非Timer，是因为Handler绑定主线程Looper，避免TimerTask在子线程更新UI导致崩溃；setCurrentItem(nextItem, true)的第二个参数true启用平滑滚动动画，比直接赋值currentItem更符合用户体验。

5. 常见问题与排查技巧实录：那些只有踩过才知道的坑

5.1 问题速查表：从编译报错到运行时异常

5.2 实操心得：三个被忽略但致命的细节

心得一：getItemCount()永远返回items.size，别信“数据还没加载完”
很多新手在首页数据从网络加载时，会在Adapter里写：

override fun getItemCount() = if (isLoading) 0 else items.size

这会导致RecyclerView高度为0，整个页面空白。正确做法是：用占位符（Placeholder）代替空数据。本项目在HomeAdapter中，当items为空时，仍返回1，并在onBindViewHolder()里显示一个“加载中”布局。这样RecyclerView始终有高度，用户体验更连贯。

心得二：notifyDataSetChanged()是“核武器”，慎用
项目里所有数据更新都用notifyItemRangeInserted()、notifyItemChanged()等局部刷新方法。比如Banner数据更新：

fun updateBanner(newBanners: List<Banner>) { val oldSize = items.filterIsInstance<BannerItem>().size items.clear() items.add(BannerItem(newBanners)) // ...添加其他区块 notifyItemRangeInserted(0, 1) // 只刷新Banner位置 }

如果用notifyDataSetChanged()，RecyclerView会销毁所有ViewHolder重新创建，Banner的轮播状态、商品列表的滚动位置全部丢失。局部刷新保证了状态连续性。

心得三：自定义View的onSaveInstanceState()不是可选项
BannerView实现了完整的状态保存：

override fun onSaveInstanceState(): Parcelable? { return SavedState(super.onSaveInstanceState()).apply { currentItem = viewPager.currentItem isPlaying = this@BannerView.isPlaying } } override fun onRestoreInstanceState(state: Parcelable?) { if (state is SavedState) { super.onRestoreInstanceState(state.superState) viewPager.currentItem = state.currentItem if (state.isPlaying) startAutoPlay() } else { super.onRestoreInstanceState(state) } }

为什么重要？当用户旋转屏幕，Activity重建时，Banner能记住当前页码和播放状态，不会从第一页重新开始。这个细节，90%的开源轮播控件都忽略了。

6. 扩展与演进：如何把这个“教学项目”升级为你的生产级UI框架

6.1 从“能跑”到“可维护”：引入ViewBinding与模块化

本项目用findViewById()是为教学清晰，但在你的实际项目中，应立即升级为ViewBinding。改造GoodsViewHolder只需三步：
1. 在app/build.gradle中启用：viewBinding = true
2.GoodsViewHolder构造函数改为：

class GoodsViewHolder(private val binding: ItemGoodsBinding) : RecyclerView.ViewHolder(binding.root)

3. bind()方法中直接用binding.goodsTitle.text = goods.title

这样做，编译期就能发现goodsTitle不存在的错误，且避免了findViewById()的反射开销。更重要的是，ViewBinding生成的类名与layout文件名强绑定（item_goods.xml→ItemGoodsBinding），团队新人一眼就能从类名定位到布局文件，大幅提升协作效率。

6.2 从“单机演示”到“云端配置”：把Banner数据源从本地JSON换成网络接口

项目里Banner数据是硬编码在MainActivity的mockData()方法里。生产环境需对接网络。改造思路：
- 新建HomeRepository类，封装Retrofit请求；
- 在HomeAdapter中增加submitList()方法，接收List<HomeItem>；
-MainActivity中，网络请求成功后，调用adapter.submitList(transformApiResponse(apiResponse))；
- 关键点：transformApiResponse()要把服务器返回的JSON数组，按类型映射为BannerItem、CategoryItem等，保持HomeItem密封类的约束。

这样，UI层完全不知道数据来自本地还是网络，更换数据源只需改一行代码。

6.3 从“UI组件”到“设计系统”：沉淀你的Design Token

项目里的colors.xml和dimens.xml是设计系统的雏形。建议你在此基础上扩展：
-colors.xml中定义语义化颜色：<color name="brand_primary">#FF6B35</color>（橙色主色），而非<color name="orange_500">#FF6B35</color>（Material色阶）；
-dimens.xml中定义间距系统：<dimen name="spacing_xs">4dp</dimen>、<dimen name="spacing_sm">8dp</dimen>、<dimen name="spacing_md">16dp</dimen>；
- 所有自定义View的属性，优先使用这些Token，比如app:cardCornerRadius="@dimen/corner_md"。

当你的App上线后，设计师说“把所有卡片圆角从8dp改成12dp”，你只需改dimens.xml里一行，全App自动生效——这才是组件化带来的真实提效。

最后分享一个小技巧：这个项目截图里的Screenshot_2016-11-30-14-36-29_com.yus.taobaoui.png，其实是用Android Studio的Layout Inspector截的真机画面，不是PS合成。打开Layout Inspector后，选中BannerView，右侧Properties面板里能看到所有app:开头的自定义属性实时值，比如indicatorSelectedColor确实是#FF6B35。这意味着，你不仅能看代码，还能在运行时验证属性是否生效——这才是调试UI组件的正确姿势。

本文还有配套的精品资源，点击获取

简介：直接可运行的Android淘宝首页UI实现，重点还原首页的商品推荐、轮播Banner、分类入口、活动横幅等典型区块。底层基于RecyclerView多Item类型（MultiViewType）动态加载不同内容模块，结构清晰、扩展性强。内置多个开箱即用的自定义View：带图标文字的导航按钮、支持圆角/阴影的商品卡片、可配置指示器与自动轮播的Banner控件，并完整演示attrs.xml属性定义、TypedArray解析及XML中属性调用全过程。项目采用标准Android工程结构，包含app模块、规范资源目录（drawable/layout/values）、基础工具类和真实设备截图，Gradle配置完整，适配主流Android Studio版本，无第三方依赖，导入即编译运行。适合深入理解RecyclerView高级用法、UI组件封装逻辑、Android界面分层设计与自定义属性实践。

本文还有配套的精品资源，点击获取