在Android生态蓬勃发展的数十年间，设备碎片化始终是困扰开发者的核心难题之一，从早期千差万别的屏幕尺寸与像素密度，到如今刘海屏、挖孔屏、折叠屏等多元形态的涌现，屏幕适配能力已成为衡量Android应用用户体验与市场覆盖度的关键指标，Android屏幕适配并非一蹴而就的技术单点突破，而是伴随系统迭代、UI框架升级、设备形态革新逐步演进的技术体系，从最初依赖dp/sp单位、多layout文件夹的基础适配，到今日头条方案的全局单位校准，再到ConstraintLayout约束布局的精准管控与Jetpack Compose声明式UI的响应式适配，每一代方案的诞生都在解决特定阶段的适配痛点，本文以从0到1的知识脉络为框架，通过基础概念拆解、早期方案溯源、现代核心方案剖析、进阶场景攻坚及最佳实践总结五大模块，系统梳理Android屏幕适配方案的演进逻辑，为不同层级的开发者搭建完整的适配知识体系，助力其从容应对各类适配场景的技术挑战。
知识点汇总：
一、基础概念与适配痛点（0-1入门）
1.1、Android屏幕适配的核心目标是什么？
Android屏幕适配的核心目标是让同一应用在不同Android设备上，都能呈现一致、正常的用户体验，具体可拆解为四个关键维度。
布局无畸形：控件不会被截断、重叠、拉伸变形或出现空白区域过大的情况（比如手机上正常显示的按钮，在平板上不会跑到屏幕边缘）。
比例协调：控件大小、间距、图文比例与设计图一致，不会出现“某控件在小屏上过大，大屏上过小”的失衡问题。
文字清晰可用：文字不会模糊、过密或过疏，支持系统字体大小调整后仍能正常阅读（不会超出控件或显示不全）。
功能完整：所有交互功能（如点击、滑动）不受屏幕形态影响，不会因适配问题导致功能失效（比如按钮被遮挡无法点击）。
简单说，适配的核心就是“消除设备差异带来的体验差异”，让用户在任何Android设备上使用你的App时，都能感受到“专为该设备设计”的流畅体验。
1.2、为什么Android会存在屏幕适配问题？本质原因是什么？
Android存在屏幕适配问题的直接原因是设备碎片化，而本质原因是Android系统的开源特性导致的生态多样性，没有统一的硬件标准，各厂商可自由定制设备参数，具体体现在四个方面。
屏幕尺寸多样：从4英寸的小屏手机，到10英寸以上的平板，甚至折叠屏（展开/折叠两种尺寸），屏幕物理大小差异极大。
像素密度（dpi）不同：同样是5英寸屏幕，可能有320dpi（hdpi）、480dpi（xxhdpi）等不同密度，导致“相同像素数对应的物理大小”不一样。
屏幕宽高比差异：早期以16:9为主，现在出现21:9（带鱼屏）、18:9、4:3（平板）等多种比例，布局排列逻辑需适配不同比例。
系统与厂商定制：不同Android版本（如4.4、10、14）的API支持不同，部分厂商还会修改系统UI（如状态栏、导航栏样式）或新增硬件特性（如刘海屏、挖孔屏），进一步增加适配复杂度。
本质上，适配问题是“统一的App设计”与“多样化的设备硬件/系统环境”之间的矛盾，需要通过技术方案弥合这种差异。
1.3、Android系统中，屏幕相关的核心概念有哪些？
屏幕适配的基础是理解以下核心概念，用“生活化比喻”帮你快速记住：
1.4、px、dp、sp三者的定义及区别是什么？为什么推荐用dp作为布局单位、sp作为文字单位？
三者的定义与核心区别：
推荐使用dp和sp的原因：
为什么用dp做布局单位：假设你用px定义一个按钮大小为100px：在160dpi（mdpi）设备上，100px≈0.625英寸，但在480dpi（xxhdpi）设备上，100px仅 ≈ 0.208英寸（按钮会变得很小），而用dp定义100dp：系统会自动按公式px=dp×density换算（density=当前dpi/160），160dpi设备上是100px，480dpi设备上是300px，最终视觉大小一致，完美解决“不同密度设备尺寸不一致”的问题。
为什么用sp做文字单位：文字需要兼顾“ accessibility（无障碍）”，用户可能因视力问题在系统设置中放大字体，如果用dp定义文字，系统字体调整后文字大小不会变，可能导致视力不好的用户看不清，而sp会跟随系统字体缩放，既保证了不同设备的基础一致性，又支持用户自定义调整，符合Android无障碍设计规范。
注意：不要用sp做布局单位（比如控件大小），否则用户调整系统字体后，控件会被拉伸/压缩，导致布局畸形。
1.5、像素密度（dpi）的计算方式是什么？mdpi、hdpi、xhdpi等密度等级的划分标准是什么？
一、dpi的计算方式
dpi是“每英寸像素数”，计算公式为：dpi=屏幕对角线像素数÷屏幕尺寸（英寸）
关键步骤：先算屏幕对角线像素数：根据分辨率（宽×高），用勾股定理计算 → 对角线像素数 = √(宽像素² + 高像素²)，用对角线像素数除以屏幕尺寸（英寸），得到dpi。
举例：某手机分辨率 1080×1920，屏幕尺寸5.5英寸，对角线像素数=√(1080²+1920²)≈2203px，dpi=2203÷5.5≈400dpi（属于xhdpi与xxhdpi之间，系统会按最接近的等级匹配）。
图解：
二、Android 系统的密度等级划分
Android为了简化适配，将不同dpi归类为多个“密度等级”，并以mdpi（160dpi）作为基准等级（dp 换算的核心基准），各等级的划分标准如下：
注意：密度等级是“范围”而非固定值，比如400dpi设备会被系统识别为xxhdpi（因为最接近480dpi），按density=3.0进行dp换算。
1.6、Android系统对不同屏幕尺寸、密度的设备，资源加载规则是什么？（如drawable、layout文件夹的匹配逻辑）
Android系统通过“资源限定符”（比如drawable-xxhdpi、layout-sw320dp中的后缀）识别设备特性，优先加载与当前设备最匹配的资源，核心规则可总结为“精准匹配优先，无匹配则fallback到默认资源”。
一、资源文件夹的命名规则
资源文件夹的格式为：资源类型-限定符1-限定符2（限定符顺序有规范，可参考Android官方文档），常见限定符。
密度限定符：mdpi/hdpi/xhdpi/xxhdpi（对应像素密度）。
尺寸限定符：small/normal/large/xlarge（早期屏幕尺寸分类）、sw<N>dp（最小宽度，如sw320dp表示屏幕最小宽度≥320dp）。
宽高比限定符：long（长屏，如16:9）、notlong（非长屏，如 4:3）。
方向限定符：land（横屏）、port（竖屏）。
二、核心加载逻辑（以drawable和layout为例）
系统先查找“完全匹配当前设备特性”的资源文件夹：比如：xxhdpi（密度）+ 竖屏（port）+ sw360dp（最小宽度）的设备，会优先找drawable-xxhdpi-port-sw360dp文件夹。
无完全匹配时，按“限定符优先级”找最接近的匹配：限定符优先级：密度 > 最小宽度 > 宽高比 > 方向（核心是“影响资源显示效果的关键特性优先”）。
无任何匹配时，加载“默认资源文件夹”：默认文件夹是“无任何限定符后缀”的文件夹，比如drawable（图片默认）、layout（布局默认）。
资源缺失时的fallback规则：图片资源：若某密度文件夹缺失图片，系统会从其他密度文件夹加载图片，再缩放至当前设备所需尺寸（比如xxhdpi设备缺少图片，会加载xhdpi的图片并放大1.5倍，可能导致模糊），布局资源：若某尺寸限定符的layout文件夹缺失，直接加载默认layout文件夹的布局。
三、举例理解
假设你的项目中有以下drawable文件夹：drawable（默认）、drawable-hdpi、drawable-xxhdpi，某手机是xxhdpi（480dpi），系统会优先加载drawable-xxhdpi中的图片，若该文件夹中没有目标图片，会找drawable-hdpi（次接近密度），最后找drawable（默认）。
再比如layout文件夹：layout（默认）、layout-sw320dp（最小宽度≥320dp）、layout-sw480dp（最小宽度≥480dp），手机（sw360dp）：优先加载layout-sw320dp（因为360≥320，且无sw360dp文件夹），平板（sw600dp）：优先加载 layout-sw480dp（600≥480），小屏设备（sw240dp）：无匹配限定符，加载默认layout。
1.7、早期Android设备（如2.3-4.4时代）的屏幕适配主要面临哪些痛点？
早期Android系统（2010-2014年左右）适配方案不成熟，设备碎片化已初步显现，开发者主要面临五大核心痛点。
布局易畸形：早期主流布局是LinearLayout和RelativeLayout，LinearLayout嵌套过深会导致布局层级复杂，RelativeLayout依赖父控件/兄弟控件定位，在不同尺寸设备上容易出现控件重叠、被截断（比如小屏上按钮超出屏幕，大屏上间距过大）。
图片适配成本高：矢量图（VectorDrawable）未普及，需为mdpi/hdpi/xhdpi等多个密度提供对应分辨率图片，不仅增加设计工作量，还导致安装包体积臃肿。
文字显示问题：部分开发者直接用px定义文字大小，导致不同密度设备上文字要么过小（高密度设备）要么过大（低密度设备），且早期系统对sp单位的支持不够完善，系统字体调整后容易出现文字超出控件的情况。
适配方案繁琐：主要依赖“多 layout文件夹”（如layout-large、layout-xlarge）和“多dimens.xml文件”（为不同密度/尺寸定义不同dp值），需手动维护大量冗余文件，修改成本高（比如改一个按钮大小，要改所有dimens文件）。
兼容性问题突出：早期Android系统版本碎片化严重（从2.3到4.4跨度大），部分适配API（如屏幕尺寸获取、密度计算）在低版本设备上不支持，且厂商定制系统（如 MIUI、EMUI早期版本）会修改屏幕显示逻辑，导致适配效果不一致。
这些痛点本质是“适配方案的灵活性跟不上设备碎片化速度”，也推动了后续ConstraintLayout、今日头条方案等更高效适配技术的诞生。
1.8、为什么仅使用dp作为单位，依然无法完全解决所有适配问题？
dp是适配的基础单位，但它只能解决“不同像素密度设备上控件视觉大小一致”的问题，无法覆盖所有适配场景，核心原因有五点。
屏幕宽高比差异：dp仅保证“单个控件大小一致”，但不同宽高比设备的“可用空间比例”不同，比如：设计图是16:9屏幕，用dp定义3个横向排列的按钮（各占100dp），在16:9设备上刚好排满，但在21:9宽屏设备上，按钮会集中在中间，两侧出现大量空白，在4:3设备上，按钮可能超出屏幕被截断。
屏幕尺寸差异（物理大小）：dp保证“视觉大小一致”，但不同物理尺寸设备的“交互体验需求不同”，比如：手机上48dp的按钮（符合Android触控最小尺寸规范）在10英寸平板上，虽然视觉大小和手机一致，但相对平板屏幕来说会显得过小，用户点击不便。
特殊布局场景无法覆盖：比如“控件宽度占满屏幕宽度的80%”“控件间距随屏幕尺寸动态调整”，仅用固定dp值无法实现，需要依赖权重（weight）、约束布局（ConstraintLayout）等更灵活的布局方式。
系统字体调整影响：dp不受系统字体大小调整影响，若用dp定义文字，用户放大系统字体后，文字不会同步放大，可能导致视力不好的用户看不清（违反无障碍规范），若用dp定义文字控件的宽高，系统字体放大后，文字会超出控件边界。
异形屏/特殊区域影响：dp未考虑刘海屏、挖孔屏的“缺口区域”，若用dp定义控件紧贴屏幕顶部，在刘海屏设备上会被缺口遮挡，此外，导航栏、状态栏的高度在不同设备上不同（虽可用dp表示，但需手动计算可用空间，仅靠dp无法自动适配）。
简单说：dp解决的是“单个控件的尺寸一致性”，而适配的核心需求是“整个布局在不同设备上的合理性”，后者需要结合布局方式、屏幕特性、交互需求等多方面因素，仅靠dp远远不够。
总结（基础概念与痛点核心要点）：
适配核心目标：跨设备一致体验，涵盖布局、比例、文字、功能四大维度。
适配问题本质：Android开源导致的设备碎片化（尺寸、密度、宽高比、系统/厂商定制差异）。
核心单位逻辑：dp管布局（密度无关）、sp管文字（密度+字体缩放无关），坚决不用px做布局/文字。
资源加载规则：精准匹配优先，无匹配fallback到默认资源，依赖资源限定符实现多设备适配。
早期痛点与dp局限：早期依赖冗余文件适配，效率低，dp仅解决尺寸一致性，无法覆盖宽高比、物理大小、特殊布局等场景，需结合更灵活的适配方案。
二、早期适配方案（基础方案演进）
布局适配类（解决“不同设备布局合理性”问题）
2.1、什么是“多layout文件夹适配”？实现原理和使用场景是什么？
一、核心定义
“多 layout 文件夹适配”是早期最直接的布局适配方案：为不同屏幕特性（尺寸、最小宽度、方向）的设备，创建独立的layout文件夹，存放针对性设计的布局文件，让系统自动加载与当前设备匹配的布局。
常见的layout文件夹命名（核心是“资源限定符”）：
按屏幕尺寸（早期）：layout-small（小屏）、layout-normal（普通屏，如手机）、layout-large（大屏，如早期平板）、layout-xlarge（超大屏）。
按最小宽度（推荐，更精准）：layout-sw320dp（屏幕最小宽度≥320dp）、layout-sw480dp、layout-sw600dp（平板常用）、layout-sw800dp。
按屏幕方向：layout-land（横屏）、layout-port（竖屏）。
组合限定符：layout-sw600dp-land（最小宽度≥600dp + 横屏）。
二、实现原理
完全依赖Android系统的资源加载规则。
1、系统先识别当前设备的核心特性（如最小宽度 360dp、竖屏）
2、优先查找“完全匹配特性”的layout文件夹（如layout-sw360dp-port）。
3、若未找到，查找“最接近匹配”的文件夹（如layout-sw320dp）。
4、若仍无匹配，加载默认layout文件夹的布局。
三、使用场景
屏幕尺寸差异极大的场景：比如手机和平板的布局差异（手机单面板，平板双面板）。
特殊屏幕方向的布局调整：比如横屏时需要重新排列控件位置（如视频App横屏显示控制栏）。
极端尺寸设备适配：比如小屏功能机（sw240dp）和大屏车载设备（sw1000dp）的布局完全不同。
四、实例理解
假设做一个新闻 App：
手机（sw360dp）：用layout文件夹的news_activity.xml，单面板显示“新闻列表”。
平板（sw600dp）：用 layout-sw600dp 文件夹的 news_activity.xml，双面板显示“左侧列表+右侧详情”。
系统会自动为手机加载默认布局，为平板加载sw600dp布局，实现“不同设备不同布局结构”的适配。
2.2、“dimens.xml多分辨率适配”的核心思路是什么？如何实现？
一、核心思路
“统一布局引用，不同设备对应不同尺寸值”，简单说就是：
1、布局文件中，所有控件的大小、间距都引用dimens.xml中定义的“变量”（如 @dimen/btn_width）。
2、为不同屏幕特性（密度、最小宽度）的设备，创建独立的dimens.xml文件，同一“变量名”在不同文件中定义不同的dp值。
3、系统加载布局时，会自动匹配当前设备对应的dimens.xml，从而实现“一套布局，多套尺寸”的适配。
二、实现步骤（以“按最小宽度适配”为例）
步骤一：创建多套dimens.xml文件
在res目录下创建不同限定符的values文件夹，每个文件夹下都有dimens.xml：
res/├─ values/ # 默认（适配多数设备）│ └─ dimens.xml├─ values-sw320dp/ # 最小宽度≥320dp（小屏手机）│ └─ dimens.xml├─ values-sw360dp/ # 最小宽度≥360dp（主流手机）│ └─ dimens.xml└─ values-sw600dp/ # 最小宽度≥600dp（平板）└─ dimens.xml
步骤二：定义统一的尺寸变量
所有dimens.xml中使用相同的变量名，但定义不同的dp值。
默认values/dimens.xml（主流设备）：
<resources><dimen name="btn_width">120dp</dimen> <!-- 按钮宽度 --><dimen name="item_margin">16dp</dimen> <!-- 控件间距 --><dimen name="text_size">16sp</dimen> <!-- 文字大小 --></resources>
小屏values-sw320dp/dimens.xml（缩小尺寸，避免拥挤）：
<resources><dimen name="btn_width">100dp</dimen><dimen name="item_margin">12dp</dimen><dimen name="text_size">14sp</dimen></resources>
平板values-sw600dp/dimens.xml（放大尺寸，提升交互体验）：
<resources><dimen name="btn_width">180dp</dimen><dimen name="item_margin">24dp</dimen><dimen name="text_size">20sp</dimen></resources>
步骤三：布局文件中引用变量
布局文件（如 activity_main.xml）中，所有尺寸都用 @dimen/xxx 引用，无需修改：
<Buttonandroid:layout_width="@dimen/btn_width"android:layout_height="48dp"android:layout_margin="@dimen/item_margin"android:textSize="@dimen/text_size"android:text="点击按钮"/>
三、核心优势
1、布局文件统一，无需维护多套 layout，减少冗余。
2、尺寸调整灵活，只需修改 dimens.xml，无需改动布局。
3、适配逻辑清晰，变量名统一，便于协作。
2.3、LinearLayout的weight权重适配的原理是什么？适用场景与局限性？
一、核心原理
weight（权重）是LinearLayout独有的属性，作用是按比例分配“剩余空间”（而非直接分配屏幕宽度/高度）。
关键公式（以水平方向android:orientation="horizontal" 为例）：
1、控件最终宽度 = 控件自身宽度（layout_width） + 剩余空间 ×（当前控件 weight / 所有控件 weight 总和）。
2、剩余空间 = 父容器宽度 - 所有控件“自身宽度”之和。
关键注意点：
1、若想让控件完全按weight比例分配，需将layout_width设为0dp（水平方向）或 0dp（垂直方向），此时“自身宽度”为0，剩余空间=父容器宽度，比例最精准。
2、若layout_width设为wrap_content/match_parent，会先占用自身所需空间，再分配剩余空间，比例可能不符合预期。
二、实例理解
<LinearLayoutandroid:layout_width="match_parent"android:layout_height="wrap_content"android:orientation="horizontal"><Buttonandroid:layout_width="0dp" <!-- 关键：设为0dp -->android:layout_height="48dp"android:weight="1" <!-- 权重1 -->android:text="按钮1"/><Buttonandroid:layout_width="0dp"android:layout_height="48dp"android:weight="2" <!-- 权重2 -->android:text="按钮2"/></LinearLayout>
剩余空间 = 屏幕宽度（假设 360dp）- 0 - 0 = 360dp，按钮1宽度 = 0 + 360 × (1/(1+2)) = 120dp，按钮2宽度 = 0 + 360 × (2/(1+2)) = 240dp，最终比例 1:2，完美适配所有屏幕宽度。
三、适用场景
控件按固定比例分配空间：如“1:1 平分屏幕”“2:1 左右布局”。
自适应填充剩余空间：如“左侧按钮固定大小，右侧文本占满剩余宽度”。
简单的线性布局适配（无需复杂定位）。
四、局限性
仅支持LinearLayout：无法在RelativeLayout、ConstraintLayout中直接使用。
方向限制：水平方向仅影响宽度，垂直方向仅影响高度，无法同时控制宽高比例。
性能问题：若LinearLayout嵌套weight，或控件较多，会导致多次测量（measure），影响布局加载速度。
复杂布局难以实现：如“控件既按比例分配，又需要相对其他控件定位”，weight无法满足。
2.4、RelativeLayout如何实现适配？与LinearLayout的优势和性能差异？
一、适配原理：“相对定位，摆脱固定尺寸依赖”
RelativeLayout允许控件通过“相对父容器”或“相对其他控件”的位置来定位，无需指定固定的宽高或间距，从而适配不同屏幕。
相对父容器：layout_alignParentLeft（靠左）、layout_centerHorizontal（水平居中）、layout_alignParentBottom（靠底）。
相对其他控件：layout_toRightOf（在某控件右侧）、layout_above（在某控件上方）、layout_alignBaseline（与某控件文字基线对齐）。
弹性尺寸：layout_width="match_parent"（占满父容器宽度）、wrap_content（包裹内容），配合 margin实现灵活间距。
二、实例理解
<RelativeLayoutandroid:layout_width="match_parent"android:layout_height="match_parent"><!-- 按钮1：水平居中，距离顶部 32dp --><Buttonandroid:id="@+id/btn1"android:layout_width="wrap_content"android:layout_height="48dp"android:layout_centerHorizontal="true"android:layout_marginTop="32dp"android:text="按钮1"/><!-- 按钮2：在按钮1右侧，与按钮1顶部对齐，间距 16dp --><Buttonandroid:layout_width="wrap_content"android:layout_height="48dp"android:layout_toRightOf="@id/btn1"android:layout_alignTop="@id/btn1"android:layout_marginLeft="16dp"android:text="按钮2"/><!-- 文本：在按钮1下方，水平居中，间距 24dp --><TextViewandroid:layout_width="wrap_content"android:layout_height="wrap_content"android:layout_below="@id/btn1"android:layout_centerHorizontal="true"android:layout_marginTop="24dp"android:text="相对布局适配示例"/></RelativeLayout>
无论屏幕宽度是320dp（小屏）还是600dp（平板），按钮1始终居中，按钮2始终在按钮1右侧，文本始终在按钮1下方，布局结构不会变形。
三、与LinearLayout的核心对比
四、关键结论
适配优势：RelativeLayout能减少布局嵌套（比如用1层RelativeLayout替代3层LinearLayout），避免因嵌套过深导致的适配问题，且定位更灵活。
性能差异：单层布局时，两者性能接近，复杂布局时，RelativeLayout因嵌套少，性能优于多层LinearLayout，但RelativeLayout的测量逻辑更复杂，若子控件过多（如10个以上），性能可能略逊于LinearLayout。
资源适配类（解决“不同设备资源显示正常”问题）
2.5、图片资源适配的核心原则是什么？如何实现？
一、核心原则
“密度对应，避免缩放失真”，为不同像素密度（mdpi/hdpi/xhdpi 等）的设备，提供对应分辨率的图片资源，让系统无需缩放（或仅少量缩放）即可显示，保证图片清晰无模糊、无拉伸变形。
核心逻辑：以mdpi（160dpi）为基准密度，其他密度的图片分辨率按“密度系数”缩放（密度系数=当前密度/dpi÷160dpi）。
二、图片分辨率对应关系（基准：mdpi=1x）
三、实现步骤
设计图输出：让设计师按mdpi或xxhdpi输出基准图片（推荐xxhdpi，因为当前主流设备是xxhdpi，减少放大失真）。
创建多密度drawable文件夹：在res目录下创建drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxhdpi。
放入对应分辨率图片：将不同分辨率的图片分别放入对应文件夹，图片文件名必须完全一致（如 icon_home.png）。
布局中引用：直接用@drawable/icon_home引用，系统会自动加载当前设备密度对应的图片。
四、fallback规则（图片缺失时）
若某密度文件夹缺失图片，系统会从其他密度文件夹加载图片并缩放：
例如：xxhdpi设备缺少icon_home.png，会优先加载drawable-xxxhdpi的图片（缩小1.33 倍），或drawable-xhdpi 的图片（放大 1.5 倍），注意：缩放会导致图片模糊（放大）或细节丢失（缩小），尽量为核心密度（xhdpi/xxhdpi）提供完整图片。
五、优化建议
无需为所有密度提供图片：比如仅提供drawable-xhdpi和drawable-xxhdpi，覆盖90%以上设备，减少设计和维护成本。
避免过大图片：xxxhdpi图片仅用于2K/4K设备，普通设备无需提供，避免安装包体积臃肿。
2.6、.9.png图片的作用是什么？如何制作和使用？
一、核心作用
解决“图片拉伸变形”问题，普通图片拉伸时，整个图片会被拉伸（比如圆角按钮背景，拉伸后圆角会变扁），而.9.png是“可拉伸的九宫格图片”，能指定“拉伸区域”和“内容区域”，拉伸时仅拉伸指定区域，保持其他区域（如圆角、边框）不变。
适用场景：按钮背景、聊天气泡、输入框背景、弹窗边框等需要自适应不同尺寸的图片。
二、.9.png的核心原理
将图片分为9个区域（九宫格），仅中间1个区域可拉伸，四周8个区域保持原样：
┌─────────┬─────────────┬─────────┐│ 不可拉伸 │ 可拉伸 │ 不可拉伸 │ 顶部├─────────┼─────────────┼─────────┤│ 不可拉伸 │ 可拉伸 │ 不可拉伸 │ 中间（仅这里拉伸）├─────────┼─────────────┼─────────┤│ 不可拉伸 │ 可拉伸 │ 不可拉伸 │ 底部└─────────┴─────────────┴─────────┘
额外功能：还能指定“内容区域”（图片内文字/子控件的显示范围），避免文字覆盖圆角或边框。
三、制作步骤（用Android Studio自带工具）
准备基础图片：设计一张带圆角/边框的图片（如 btn_bg.png），建议尺寸适中（如 48×48px），避免过大。
打开Draw 9-patch工具：Android Studio → 右键图片 → Open With → Draw 9-patch。
绘制拉伸区域（黑色像素线）：
1、顶部边缘：横向绘制 1 条黑色细线（表示水平方向可拉伸区域）。
2、左侧边缘：纵向绘制 1 条黑色细线（表示垂直方向可拉伸区域）。
3、细线越窄，拉伸区域越精准（建议 1-2 像素宽）。
绘制内容区域（可选）：
1、底部边缘：横向绘制细线（表示文字水平显示范围）。
2、右侧边缘：纵向绘制细线（表示文字垂直显示范围）。
保存：点击左上角“Save”，自动生成.9.png 后缀的图片（如btn_bg.9.png）。
注意：
1、黑色细线必须画在图片的“边缘”（上下左右各1像素的透明区域），不能画在图片内容上。
2、若绘制错误，可按Erase按钮清除，或直接删除.9.png重新制作。
四、使用方法
1、将.9.png图片放入drawable文件夹（无需分密度，因为可拉伸）。
2、布局中直接引用：
<Buttonandroid:layout_width="wrap_content"android:layout_height="48dp"android:background="@drawable/btn_bg.9"android:text="可拉伸按钮"/>
无论按钮宽度是100dp还是200dp，.9.png 仅拉伸中间区域，圆角和边框保持不变。
2.7、矢量图（VectorDrawable）为什么能解决多分辨率适配？优缺点与注意事项？
一、核心原理：“基于路径描述，无限缩放不失真”
矢量图（VectorDrawable）不是由像素点组成，而是通过XML代码描述图形的路径、颜色、轮廓（比如“画一个圆形，半径24dp，填充红色”），因为它是“数学公式描述”的图形，而非像素集合，所以：可无限放大/缩小，不会出现模糊或锯齿（完美适配所有密度设备），无需为不同密度提供多套图片，一套XML即可适配所有设备。
二、实例：简单矢量图的XML结构（icon_arrow.xml）
<vector xmlns:android="http://schemas.android.com/apk/res/android"android:width="24dp" <!-- 默认显示宽度（可在布局中修改） -->android:height="24dp" <!-- 默认显示高度 -->android:viewportWidth="24.0" <!-- 视图窗口宽度（路径坐标基于此） -->android:viewportHeight="24.0"><!-- 路径描述：向右的箭头 --><path android:fillColor="#FF0000"<!-- 填充颜色 -->android:pathData="M12,5l-1.41,1.41L16.17,12l-5.58,5.59L12,19l8,-8z"/></vector>
pathData是核心，用指令（M=移动、L=直线、z=闭合）描述图形路径，布局中引用@drawable/icon_arrow，无论设备是mdpi还是xxxhdpi，显示都清晰。
三、优缺点分析
四、使用注意事项
低版本兼容：需在build.gradle中添加VectorDrawableCompat依赖，支持Android 4.0（API 14）以上：
android {defaultConfig {vectorDrawables.useSupportLibrary = true}}dependencies {implementation 'androidx.vectordrawable:vectordrawable:1.1.0'}
布局中引用时，需用app:srcCompat替代android:src：
<ImageViewandroid:layout_width="48dp"android:layout_height="48dp"app:srcCompat="@drawable/icon_arrow"/>
避免复杂图形：仅用于简单图标（如箭头、开关、图标），不用于背景、照片等复杂图形。
性能优化：复杂矢量图可拆分为多个简单路径，或直接用位图替代。
2.8、早期“像素适配”的实现思路是什么？为什么现在不推荐使用？
一、实现思路
早期Android设备分辨率相对单一（如480×800、720×1280），“像素适配”的核心是：
1、针对特定分辨率的设备，直接用px（像素）作为布局单位，写死控件的宽高、间距。
2、比如为480×800设备设计布局，按钮宽度设为160px，间距设为20px，确保在该分辨率设备上显示正常。
3、若要适配其他分辨率，需创建多套layout文件夹（如 layout-480x800、layout-720x1280），每套布局用对应分辨率的px值。
二、为什么现在不推荐？（核心是“适配性极差”）
与像素密度无关，导致尺寸不一致：px是物理像素，同一px值在不同密度设备上的视觉大小不同（比如160px在mdpi设备上是1英寸，在xxhdpi设备上仅0.33英寸）。
设备碎片化导致维护成本极高：现在Android设备分辨率有上百种（如1080×1920、2560×1440、2400×1080 等），为每种分辨率创建一套布局几乎不可能。
屏幕尺寸变化时布局畸形：比如为5英寸1080×1920设备写死的px布局，在6英寸1080×1920设备上，控件会显得过小（因为屏幕更大，像素密度更低）。
违反Android设计规范：Android官方明确推荐使用dp/sp单位，px仅用于极少数特殊场景（如绘制自定义View时的像素级操作）。
三、总结
像素适配是“早期设备分辨率单一”时的临时方案，完全依赖“固定分辨率匹配”，无法应对现在的设备碎片化，已被dp单位、多dimens适配等方案彻底替代。
单位适配类（承接早期适配，聚焦“单位层面的灵活适配”）
2.9、dp单位的底层转换逻辑是什么？（dp与px的换算公式：px = dp * (dpi / 160)）
一、核心前提：理解“密度系数 density”
dp（密度无关像素）的本质是“让不同密度设备上的视觉大小一致”，而底层转换的核心依赖密度系数（density），Android系统定义：
density = 当前设备dpi ÷ 基准dpi（160dpi）
这就是为什么公式可以简化为：px = dp × density（与你给出的 px = dp × (dpi / 160) 完全等价）
二、底层转换流程（系统如何处理dp？）
当你在布局中写android:layout_width="100dp" 时，Android系统会按以下步骤转换为实际像素：
1、系统获取当前设备的实际dpi（比如xxhdpi设备的 dpi≈480）。
2、计算density：480÷160=3.0。
3、执行换算：100dp×3.0=300px。
4、屏幕最终按300px的物理像素绘制控件。
三、为什么以160dpi为基准？
160dpi是Android早期定义的“标准密度设备”（比如早期320×480分辨率、3.2英寸屏幕的手机，dpi≈160），Google以此为基准制定dp规则，目的是：
1、让1dp在160dpi设备上恰好等于1px（1dp × 1.0 = 1px），简化设计与开发的换算。
2、为后续不同密度设备提供统一的“缩放基准”，避免碎片化导致的尺寸混乱。
四、实例验证
不同密度设备上，100dp最终的物理视觉大小完全一致，这就是dp解决“密度适配”的核心价值。
2.10、什么是“最小宽度适配（sw dp）”？其核心思想和实现步骤是什么？适用于哪些场景？
一、核心定义：什么是“最小宽度（sw）”？
“最小宽度”指的是屏幕短边的最小dp值（不随屏幕方向变化）：
竖屏手机（360dp宽、640dp高）：短边是宽度，sw=360dp。
横屏手机（640dp宽、360dp高）：短边是高度，sw仍=360dp。
平板（600dp宽、900dp高）：sw=600dp。
简单说：sw是设备的“最小尺寸标识”，同一sw区间的设备，其可用空间的“最小规模”一致，适合复用同一套适配规则。
开源项目：https://github.com/wildma/ScreenAdaptation
二、核心思想
“按最小宽度分组适配”，把sw相近的设备归为一类，为每类设备提供对应的尺寸/布局，核心是：忽略设备的具体分辨率、宽高比差异，只关注“最小可用空间”，实现“同组设备体验一致，跨组设备精准适配”。
三、实现步骤（两种常见方式）
方式一：结合多dimens.xml适配（推荐，低冗余）
这是最常用的方式，无需多套布局，仅通过尺寸变量适配：
划分sw区间（根据目标设备覆盖范围）：常见区间：sw240dp（小屏功能机）、sw320dp（老款手机）、sw360dp（主流手机）、sw480dp（大屏手机）、sw600dp（平板）、sw800dp（大平板）。
创建对应values文件夹：res/values-sw320dp/、res/values-sw360dp/、res/values-sw600dp/，每个文件夹下创建dimens.xml。
统一变量名，差异化尺寸值：比如@dimen/btn_width在sw320dp中是100dp，sw360dp中是120dp，sw600dp中是180dp。
布局中引用变量：所有控件尺寸用@dimen/xxx 引用，系统自动加载当前设备 sw 对应的dimens.xml。
方式二：结合多layout文件夹适配（适用于布局结构差异大的场景）
当sw差异导致布局结构需要改变时（比如手机单面板、平板双面板），创建带sw限定符的layout文件夹：res/layout-sw360dp/（手机布局）、res/layout-sw600dp/（平板布局），系统会优先加载当前设备sw对应的layout文件夹，实现“结构+尺寸”双重适配。
四、适用场景
1、设备尺寸跨度大，但宽高比相对统一（比如手机+平板的适配）。
2、希望“低冗余”适配（仅维护多套dimens，无需多套布局）。
3、核心需求是“控件尺寸随设备最小空间等比例缩放”，而非布局结构重构。
五、核心优势
稳定性强：sw不随屏幕方向变化，横竖屏切换时适配规则一致。
覆盖范围广：同一sw区间可覆盖多种分辨率设备（比如sw360dp可覆盖1080×1920、1440×2560等分辨率的手机）。
维护成本低：相比“多分辨率适配”，sw区间数量少（通常3-5组即可覆盖95%设备）。
2.11、“屏幕宽高比适配”的思路是什么？如何针对不同宽高比设计布局？
一、核心思路
“按屏幕宽高比分类，针对性调整布局”，宽高比决定了屏幕的“形状”（比如16:9是普通宽屏，21:9是带鱼屏，4:3是方正屏），适配的核心是：让布局在不同“形状”的屏幕上，既不浪费空间，也不出现控件截断/重叠。
二、宽高比的计算与分类
计算方式：宽高比 = 屏幕宽度像素数 ÷ 屏幕高度像素数（竖屏时），或高度 ÷ 宽度（横屏时）。
常见分类：普通屏（16:9≈1.78）、带鱼屏（21:9≈2.33）、方正屏（4:3≈1.33）、长屏（18:9≈2.0）。
三、实现方式（两种核心方案）
方式一：多layout文件夹 + 宽高比限定符（静态适配）
利用Android资源限定符long（长屏，宽高比≥1.8）和notlong（非长屏，宽高比<1.8），或自定义宽高比限定符。
创建带宽高比限定符的layout文件夹：res/layout-long/（长屏：18:9、21:9），res/layout-notlong/（非长屏：16:9、4:3），自定义限定符（更精准）：res/layout-aspect-21_9/、res/layout-aspect-16_9/（需通过 configChanges 配置识别）。
为不同文件夹设计差异化布局：长屏（21:9）：横向增加控件数量，或扩大控件间距，避免两侧空白，非长屏（4:3）：减少横向控件数量，或缩小间距，避免控件截断。
方式二：代码动态调整布局（动态适配，更灵活）
通过代码获取当前屏幕宽高比，动态修改控件的可见性、大小、位置：
获取屏幕宽高比：
// 在 Activity 的 onCreate 中（需在 setContentView 后）val displayMetrics = resources.displayMetricsval screenWidth = displayMetrics.widthPixelsval screenHeight = displayMetrics.heightPixelsval aspectRatio = screenWidth.toFloat() / screenHeight.toFloat() // 竖屏时的宽高比
根据宽高比调整布局：
val btnExtra = findViewById<Button>(R.id.btn_extra)val marginLayout = findViewById<LinearLayout>(R.id.margin_layout)when {aspectRatio >= 2.1f -> { // 21:9 带鱼屏btnExtra.visibility = View.VISIBLE // 显示额外按钮，填充横向空间val layoutParams = marginLayout.layoutParams as ViewGroup.MarginLayoutParamslayoutParams.leftMargin = resources.getDimensionPixelSize(R.dimen.margin_large)layoutParams.rightMargin = resources.getDimensionPixelSize(R.dimen.margin_large)}aspectRatio <= 1.5f -> { // 4:3 方正屏btnExtra.visibility = View.GONE // 隐藏额外按钮，避免横向拥挤val layoutParams = marginLayout.layoutParams as ViewGroup.MarginLayoutParamslayoutParams.leftMargin = resources.getDimensionPixelSize(R.dimen.margin_small)layoutParams.rightMargin = resources.getDimensionPixelSize(R.dimen.margin_small)}else -> { // 16:9 普通屏，默认布局btnExtra.visibility = View.INVISIBLE}}
四、适用场景
1、带鱼屏（21:9）与普通屏（16:9）的适配（比如视频App控制栏布局、游戏UI适配）。
2、平板（4:3）与手机（16:9）的布局调整（比如办公 App 的工具栏适配）。
3、避免因宽高比差异导致的“横向空白过多”或“控件挤压”问题。
三、现代主流适配方案（进阶核心）
现代主流适配方案：今日头条适配方案
今日头条方案是目前最流行的全局适配方案之一，核心优势是“一次集成，全项目适配”，彻底解决了早期方案的冗余问题，下面从原理到实战详细拆解。
3.1、今日头条屏幕适配方案的核心原理是什么？（修改DisplayMetrics的density和scaledDensity）
核心前提：Android系统的dp换算依赖DisplayMetrics
Android系统中，所有dp/sp到px的转换，都依赖Resources.getDisplayMetrics()中的两个关键参数：
density：用于dp转px（px=dp × density），scaledDensity：用于sp转px（px=sp×scaledDensity），默认与density相等，系统字体调整时会同步变化，这两个参数是系统全局的“适配标尺”，只要修改它们，就能改变全项目的dp/sp换算规则，这就是今日头条方案的核心逻辑。
方案本质：“强制统一全设备的换算标尺”
早期适配方案是“让布局/尺寸适配设备”，而今日头条方案是“让设备适配布局”：假设设计图的基准是360dp宽（主流设计图尺寸），无论设备的实际分辨率、密度如何，都通过修改density，让设备的“可用宽度”在dp层面恰好等于设计图宽度，这样，布局中写的100dp，在任何设备上都占“设计图宽度的100/360”，实现“等比例缩放”。
核心原理总结：通过反射或直接修改DisplayMetrics中的density和scaledDensity，强制将所有设备的“dp 标尺”统一为设计图的基准尺寸，从而实现“一套布局，适配所有设备”。
3.2、今日头条方案中，如何计算目标density？（基于设计图宽度/高度的适配逻辑）
目标density的计算核心是“设备实际宽度px÷设计图基准宽度dp”，确保设备的“dp 宽度”等于设计图宽度。
一、核心公式（以“基于设计图宽度适配”为例，推荐优先使用）
目标density=设备实际可用宽度（px）÷设计图基准宽度（dp）
目标scaledDensity=目标density（默认，后续需处理字体调整）
目标densityDpi=目标density×160（系统内部用，可选修改）
二、关键概念解释
设备实际可用宽度（px）：屏幕总宽度减去状态栏、导航栏等系统占用宽度后的“布局可用宽度”。
设计图基准宽度（dp）：设计师提供的设计图宽度，通常是360dp、375dp（主流手机设计图尺寸），需与设计师确认。
三、实例计算
假设：设计图基准宽度=360dp，设备实际可用宽度=1080px（比如 1080×1920 分辨率手机，无导航栏）。
计算目标density：目标density=1080px÷360dp=3.0
此时，布局中1dp会被换算为3px，360dp恰好等于设备可用宽度1080px，完美匹配设计图比例。
四、基于设计图高度适配（可选，适用于特殊场景）
部分场景（如竖屏滚动布局）可能需要基于高度适配，公式类似：
目标 density = 设备实际可用高度（px） ÷ 设计图基准高度（dp）
注意：基于高度适配时，横屏切换会导致density突变，布局可能错乱，优先推荐基于宽度适配。
五、可用宽度的精准获取（避免系统栏干扰）
如果设备有导航栏/状态栏，直接用屏幕总宽度会导致计算偏差，需获取“应用可用宽度”：
// 方式一：通过 WindowInsets 获取（Android 11+ 推荐）val windowInsets = window.decorView.rootWindowInsetsval systemBarLeft = windowInsets.getInsets(WindowInsets.Type.systemBars()).leftval systemBarRight = windowInsets.getInsets(WindowInsets.Type.systemBars()).rightval availableWidth = displayMetrics.widthPixels - systemBarLeft - systemBarRight// 方式二：兼容低版本（Android 10 及以下）val decorView = window.decorViewval contentView = window.findViewById<ViewGroup>(Window.ID_ANDROID_CONTENT)val availableWidth = contentView.width // 需在布局加载完成后获取（如 onWindowFocusChanged）
3.3、今日头条方案如何解决系统字体大小调整导致的适配问题？（scaledDensity与density的同步）
问题本质：系统字体调整会破坏scaledDensity与density的比例，默认情况下，scaledDensity=density，但用户在系统设置中调整字体大小后：系统会自动修改scaledDensity（比如字体放大20%，scaledDensity=density×1.2），而今日头条方案修改的是density，未同步修改scaledDensity，会导致：文字用sp单位时，缩放比例与控件dp比例不一致（文字过大/过小，超出控件），布局错乱（比如文字挤压控件，或出现大量空白）。
解决方案：监听字体变化，同步scaledDensity与density的比例，核心思路是：让scaledDensity始终等于“目标density×系统字体缩放比例”，保持文字缩放与控件缩放同步。
具体步骤：
1、初始化时，记录系统默认的scaledDensity/density比例（即系统字体缩放系数）。
2、监听系统字体大小变化（通过ContentObserver监听Settings.System.FONT_SCALE）。
3、字体变化时，重新计算scaledDensity=目标density×系统字体缩放系数。
关键代码实现：
// 1. 记录系统默认的字体缩放比例private var fontScale = 1.0f // 初始为 1.0（默认字体大小）// 2. 初始化时获取系统默认比例val originalDisplayMetrics = application.resources.displayMetricsfontScale = originalDisplayMetrics.scaledDensity / originalDisplayMetrics.density// 3. 监听系统字体大小变化application.contentResolver.registerContentObserver(Settings.System.CONTENT_URI,true,object : ContentObserver(Handler(Looper.getMainLooper())) {override fun onChange(selfChange: Boolean) {super.onChange(selfChange)// 获取新的系统字体缩放系数val newFontScale = Settings.System.getFloat(application.contentResolver,Settings.System.FONT_SCALE,1.0f)// 同步 scaledDensity：目标 density × 新字体缩放系数val targetScaledDensity = targetDensity * newFontScale// 更新全局 DisplayMetricsupdateDisplayMetrics(targetDensity, targetScaledDensity)}})// 4. 更新 DisplayMetrics 的工具方法private fun updateDisplayMetrics(targetDensity: Float, targetScaledDensity: Float) {val appDisplayMetrics = application.resources.displayMetricsappDisplayMetrics.density = targetDensityappDisplayMetrics.scaledDensity = targetScaledDensityappDisplayMetrics.densityDpi = (targetDensity * 160).toInt()// 同时更新 Activity 的 DisplayMetrics（避免部分场景未生效）val activityDisplayMetrics = resources.displayMetricsactivityDisplayMetrics.density = targetDensityactivityDisplayMetrics.scaledDensity = targetScaledDensityactivityDisplayMetrics.densityDpi = (targetDensity * 160).toInt()}
效果验证：
系统字体默认大小：scaledDensity=3.0（与目标density 一致），文字16sp=48px。
系统字体放大 20%：scaledDensity=3.0×1.2=3.6，文字16sp=57.6px。
控件100dp=300px（不变），文字缩放比例与控件尺寸比例同步，不会出现布局错乱。
3.4、今日头条方案的优点和缺点是什么？在哪些场景下不适用？
一、核心优点
适配效率极高：一次集成，全项目生效，无需维护多layout、多dimens文件，开发成本低。
适配效果统一：所有设备按设计图等比例缩放，布局比例与设计图完全一致，无畸形。
侵入性低：无需修改现有布局代码，仅需在Application或BaseActivity中初始化。
支持动态调整：可根据业务需求切换设计图基准（如部分页面用375dp基准）。
二、核心缺点
全局修改的副作用：DisplayMetrics是全局共享的，修改后会影响所有依赖dp/sp的组件（包括第三方库、系统控件）。
多模块适配冲突：若项目是多模块开发（如SDK集成、组件化项目），不同模块可能有不同设计图基准，全局density会导致部分模块适配异常。
WebView适配问题：WebView会自动重置DisplayMetrics的density为系统默认值，导致WebView内的H5页面与原生布局适配不一致。
特殊设备适配受限：折叠屏、平板等设备需要“非等比例适配”（如平板放大控件而非等比例缩放）时，方案不灵活。
系统兼容性风险：部分Android版本（如Android 12+）对DisplayMetrics的修改有限制，可能导致适配失效。
不适用场景：
多模块/组件化项目：不同模块设计图基准不同，全局density无法满足所有模块。
WebView密集型项目：H5页面与原生布局适配规则不一致，需单独适配WebView。
大屏设备优化：平板、折叠屏需要“大屏专属布局”（如双面板），而非简单等比例缩放。
系统级应用：依赖系统原生density的应用（如launcher、系统工具），修改后可能导致功能异常。
第三方库强依赖dp规则：部分第三方UI库（如Material Design）对dp有固定要求，修改density可能导致控件变形。
3.5、如何在Android项目中集成今日头条适配方案？关键代码和配置步骤是什么？
下面以Kotlin 语言 + AndroidX 项目为例，提供完整的集成步骤（兼容Android 8.0+，适配大部分设备）。
一、核心集成步骤
步骤一：定义适配常量（设计图基准）
在Application或单独的工具类中定义设计图基准尺寸（与设计师确认）：
object AdaptConstant {// 设计图基准宽度（dp），根据实际设计图修改（常见 360、375、414）const val DESIGN_WIDTH_DP = 360f// 是否基于宽度适配（true=宽度，false=高度）const val ADAPT_BY_WIDTH = true}
步骤二：实现适配工具类（核心逻辑）
import android.app.Applicationimport android.content.ContentResolverimport android.content.Contextimport android.content.Intentimport android.content.pm.ActivityInfoimport android.content.res.Resourcesimport android.net.Uriimport android.os.Buildimport android.os.Handlerimport android.os.Looperimport android.provider.Settingsimport android.util.DisplayMetricsimport android.view.WindowInsetsimport android.view.WindowManagerobject ScreenAdaptUtil {private var targetDensity = 0f // 目标 densityprivate var defaultFontScale = 1.0f // 系统默认字体缩放比例// 初始化适配（在 Application 的 onCreate 中调用）fun init(application: Application) {// 1. 获取系统默认的字体缩放比例val originalMetrics = application.resources.displayMetricsdefaultFontScale = originalMetrics.scaledDensity / originalMetrics.density// 2. 计算目标 densitytargetDensity = calculateTargetDensity(application)// 3. 初始化 DisplayMetricsupdateGlobalDisplayMetrics(application, targetDensity)// 4. 监听系统字体大小变化registerFontScaleObserver(application)}// 计算目标 densityprivate fun calculateTargetDensity(context: Context): Float {val displayMetrics = context.resources.displayMetrics// 获取设备可用宽/高（px）val (availableWidth, availableHeight) = getAvailableScreenSize(context)return if (AdaptConstant.ADAPT_BY_WIDTH) {// 基于宽度适配availableWidth / AdaptConstant.DESIGN_WIDTH_DP} else {// 基于高度适配availableHeight / AdaptConstant.DESIGN_HEIGHT_DP // 需在 AdaptConstant 中定义 DESIGN_HEIGHT_DP}}// 获取设备可用屏幕尺寸（排除状态栏、导航栏）private fun getAvailableScreenSize(context: Context): Pair<Float, Float> {return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {// Android 11+：通过 WindowInsets 获取val windowManager = context.getSystemService(Context.WINDOW_SERVICE) as WindowManagerval windowMetrics = windowManager.currentWindowMetricsval insets = windowMetrics.windowInsets.getInsetsIgnoringVisibility(WindowInsets.Type.systemBars())val width = (windowMetrics.bounds.width() - insets.left - insets.right).toFloat()val height = (windowMetrics.bounds.height() - insets.top - insets.bottom).toFloat()Pair(width, height)} else {// Android 10 及以下：通过 DecorView 获取val windowManager = context.getSystemService(Context.WINDOW_SERVICE) as WindowManagerval display = windowManager.defaultDisplayval displayMetrics = DisplayMetrics()display.getMetrics(displayMetrics)val decorView = (context as? android.app.Activity)?.window?.decorViewval contentView = decorView?.findViewById<android.view.View>(android.R.id.content)val width = contentView?.width?.toFloat() ?: displayMetrics.widthPixels.toFloat()val height = contentView?.height?.toFloat() ?: displayMetrics.heightPixels.toFloat()Pair(width, height)}}// 更新全局 DisplayMetricsprivate fun updateGlobalDisplayMetrics(application: Application, targetDensity: Float) {// 计算目标 scaledDensity（同步系统字体缩放）val targetScaledDensity = targetDensity * defaultFontScaleval targetDensityDpi = (targetDensity * 160).toInt()// 更新 Application 级别的 DisplayMetricsval appMetrics = application.resources.displayMetricsappMetrics.density = targetDensityappMetrics.scaledDensity = targetScaledDensityappMetrics.densityDpi = targetDensityDpi// 更新 Activity 级别的 DisplayMetrics（可选，确保当前 Activity 生效）val currentActivity = getCurrentActivity(application)currentActivity?.let {val activityMetrics = it.resources.displayMetricsactivityMetrics.density = targetDensityactivityMetrics.scaledDensity = targetScaledDensityactivityMetrics.densityDpi = targetDensityDpi}}// 监听系统字体大小变化private fun registerFontScaleObserver(application: Application) {application.contentResolver.registerContentObserver(Settings.System.CONTENT_URI,true,object : android.database.ContentObserver(Handler(Looper.getMainLooper())) {override fun onChange(selfChange: Boolean, uri: Uri?) {super.onChange(selfChange, uri)if (uri == Settings.System.getUriFor(Settings.System.FONT_SCALE)) {// 字体大小变化，重新计算 scaledDensityval newFontScale = Settings.System.getFloat(application.contentResolver,Settings.System.FONT_SCALE,1.0f)val targetScaledDensity = targetDensity * newFontScale// 更新 DisplayMetricsval appMetrics = application.resources.displayMetricsappMetrics.scaledDensity = targetScaledDensitygetCurrentActivity(application)?.resources?.displayMetrics?.scaledDensity = targetScaledDensity}}})}// 获取当前 Activity（辅助方法，可选）private fun getCurrentActivity(application: Application): android.app.Activity? {if (application is android.app.Application) {val activities = application.activityLifecycleCallbacks?.let {// 需自定义 ActivityLifecycleCallbacks 记录当前 Activity// 此处简化，实际项目需实现完整的生命周期监听null}return activities?.lastOrNull()}return null}}
步骤三：在Application中初始化
class MyApp : Application() {override fun onCreate() {super.onCreate()// 初始化今日头条适配方案ScreenAdaptUtil.init(this)}}
步骤四：配置AndroidManifest.xml
确保Application类正确配置，同时添加必要权限（监听系统设置变化无需额外权限）：
<applicationandroid:name=".MyApp"...>...</application>
二、关键注意事项
设计图基准确认：必须与设计师确认设计图的宽度（dp），否则适配比例会偏差。
WebView兼容处理：若项目中有WebView，需在WebView初始化后重新设置DisplayMetrics（因为WebView会重置density）：
val webView = WebView(this)// WebView 初始化后，重新应用适配规则ScreenAdaptUtil.init(application) // 或重新计算并设置 density
多进程处理：若项目有多个进程（如推送进程、视频进程），需在每个进程初始化时调用ScreenAdaptUtil.init()。
折叠屏适配：折叠屏设备需在折叠状态变化时（onConfigurationChanged）重新计算targetDensity，避免适配失效。
三、验证适配效果
1、用不同分辨率设备（如720p、1080p、2K手机）运行项目。
2、检查布局控件比例是否与设计图一致，文字是否清晰，无重叠/截断。
3、调整系统字体大小，观察文字是否同步缩放，布局是否保持正常。
4、头条官方给出的图片，适配前后和设计图对比图：
适配后各机型的显示效果图：
今日头条方案核心要点：
核心原理：修改全局DisplayMetrics的density和scaledDensity，统一全设备的dp换算标尺。
关键计算：targetDensity=设备可用宽度px÷设计图宽度dp，确保布局等比例缩放。
字体适配：监听系统字体变化，让scaledDensity=targetDensity×字体缩放系数，避免布局错乱。
适用场景：单模块、无大量 WebView、追求高效适配的项目，不适用多模块、大屏优化、WebView 密集型项目。
集成关键：在Application初始化，处理WebView兼容和多进程问题。
今日头条方案的出现，标志着Android适配从“被动适配设备”走向“主动统一规则”，是适配方案演进的重要里程碑，但没有万能方案，需根据项目场景选择最合适的适配技术。
ConstraintLayout约束布局适配
ConstraintLayout是Google在Android Studio 2.3推出的布局，目前已成为官方推荐的首选布局，核心定位是“用单层布局实现复杂UI，同时提供极致的适配灵活性”。
3.6、ConstraintLayout作为Google推荐的布局，其适配核心优势是什么？
ConstraintLayout的适配优势本质是“扁平化布局+精准约束”，完美解决了传统LinearLayout/RelativeLayout的适配痛点，核心优势可总结为五点。
彻底减少布局嵌套，降低适配复杂度：传统布局实现复杂UI需多层嵌套（如LinearLayout嵌套RelativeLayout），嵌套越深，适配时越容易出现“牵一发而动全身”的问题（比如修改外层尺寸导致内层控件错位），而ConstraintLayout可通过单层布局实现任意控件定位，适配逻辑更清晰，维护成本更低。
精准的约束规则，适配不同屏幕尺寸：支持“相对父容器”“相对其他控件”“百分比定位”“比例约束”等多种约束方式，能精准控制控件的位置、大小和间距，无论屏幕尺寸如何变化，都能保持布局结构稳定（比如控件始终居中、间距按比例缩放）。
可视化编辑效率高，适配调试更便捷：Android Studio提供强大的可视化编辑器（Design模式），可通过拖拽、点击添加约束，实时预览不同屏幕尺寸的适配效果，无需手动编写复杂XML代码，新手也能快速上手。
支持动态约束修改，适配特殊场景：可通过代码动态修改控件的约束条件（如改变控件的依赖关系、调整间距），轻松实现“屏幕旋转、尺寸变化时的布局适配”（比如横屏时重新排列控件）。
性能更优，适配大视图更流畅：传统多层嵌套布局的测量（measure）、布局（layout）过程是“递归遍历”，耗时较长，而ConstraintLayout是“单层测量”（仅需遍历一次子控件），性能损耗更低，尤其在复杂UI或滚动列表中，适配大屏幕时更流畅。
3.7、ConstraintLayout的关键约束属性（如match_constraint、guideline、barrier、chain）如何助力屏幕适配？
ConstraintLayout的核心是“约束”，以下四个关键属性/组件是适配的核心工具，每个都能针对性解决特定适配问题。
一、match_constraint（0dp）：自适应父容器空间
定义：layout_width或layout_height设为0dp时，控件大小由约束条件决定（而非固定尺寸），是ConstraintLayout适配的“基础属性”。
适配逻辑：控件会填充“约束条件定义的可用空间”，自动适应不同屏幕尺寸。
示例场景：按钮宽度占父容器宽度的“左右各32dp间距之间的全部空间”。
<androidx.constraintlayout.widget.ConstraintLayoutandroid:layout_width="match_parent"android:layout_height="wrap_content"><Buttonandroid:id="@+id/btn_submit"android:layout_width="0dp" <!-- match_constraint -->android:layout_height="48dp"android:text="提交"app:layout_constraintLeft_toLeftOf="parent"app:layout_constraintRight_toRightOf="parent"app:layout_constraintLeft_margin="32dp"app:layout_constraintRight_margin="32dp"/></androidx.constraintlayout.widget.ConstraintLayout>
适配优势：无论屏幕宽度是320dp（小屏）还是600dp（平板），按钮都会自动填充“父容器-左右边距”的空间，无需手动调整尺寸。
二、Guideline（引导线）：百分比/固定值定位
定义：虚拟的“参考线”（不可见），可按“百分比”或“固定dp值”定位，用于辅助其他控件对齐，解决“不同屏幕尺寸下控件位置比例一致”的问题。
核心属性：
orientation="horizontal"（水平引导线，控制垂直位置）。orientation="vertical"（垂直引导线，控制水平位置）。layout_constraintGuide_percent（百分比定位，0-1 之间，如 0.5 表示居中）。layout_constraintGuide_begin（距离父容器起始端的固定 dp 值）。
示例场景：两个按钮分别位于屏幕水平方向的30%和70%位置。
<androidx.constraintlayout.widget.ConstraintLayoutandroid:layout_width="match_parent"android:layout_height="wrap_content"><!-- 垂直引导线：距离左侧 30% 位置 --><androidx.constraintlayout.widget.Guidelineandroid:id="@+id/guideline_30"android:layout_width="wrap_content"android:layout_height="wrap_content"android:orientation="vertical"app:layout_constraintGuide_percent="0.3"/><!-- 垂直引导线：距离左侧 70% 位置 --><androidx.constraintlayout.widget.Guidelineandroid:id="@+id/guideline_70"android:layout_width="wrap_content"android:layout_height="wrap_content"android:orientation="vertical"app:layout_constraintGuide_percent="0.7"/><Buttonandroid:layout_width="wrap_content"android:layout_height="48dp"android:text="按钮1"app:layout_constraintLeft_toLeftOf="@id/guideline_30"/><Buttonandroid:layout_width="wrap_content"android:layout_height="48dp"android:text="按钮2"app:layout_constraintLeft_toLeftOf="@id/guideline_70"/></androidx.constraintlayout.widget.ConstraintLayout>
适配优势：无论屏幕宽度如何变化，按钮始终在30%和70%位置，比例保持一致，避免小屏拥挤、大屏偏移。
三、Barrier（屏障）：动态约束组控件
定义：虚拟的“屏障线”，可将多个控件视为一个“整体”，屏障线会跟随组内控件的最大/最小尺寸动态调整，解决“多个动态尺寸控件的对齐适配”问题。
核心属性：
barrierDirection（屏障方向，如left表示屏障在组内控件左侧）。
constraint_referenced_ids（引用的控件ID，多个用逗号分隔）。
示例场景：两个文本控件（长度不固定）右侧对齐一个按钮，按钮位置跟随最长文本的右侧：
<androidx.constraintlayout.widget.ConstraintLayoutandroid:layout_width="match_parent"android:layout_height="wrap_content"><TextViewandroid:id="@+id/tv1"android:layout_width="wrap_content"android:layout_height="wrap_content"android:text="短文本"app:layout_constraintLeft_toLeftOf="parent"app:layout_constraintTop_toTopOf="parent"/><TextViewandroid:id="@+id/tv2"android:layout_width="wrap_content"android:layout_height="wrap_content"android:text="非常长的动态文本内容"app:layout_constraintLeft_toLeftOf="parent"app:layout_constraintTop_toBottomOf="@id/tv1"app:layout_constraintTop_margin="16dp"/><!-- 屏障：在 tv1 和 tv2 的右侧，跟随最长文本的右侧 --><androidx.constraintlayout.widget.Barrierandroid:id="@+id/barrier_right"android:layout_width="wrap_content"android:layout_height="wrap_content"app:barrierDirection="right"app:constraint_referenced_ids="tv1,tv2"/><!-- 按钮：对齐屏障右侧，间距 16dp --><Buttonandroid:layout_width="wrap_content"android:layout_height="48dp"android:text="查看"app:layout_constraintLeft_toRightOf="@id/barrier_right"app:layout_constraintLeft_margin="16dp"app:layout_constraintTop_toTopOf="parent"/></androidx.constraintlayout.widget.ConstraintLayout>
适配优势：无论文本长度如何变化（如多语言翻译后长度不同），按钮始终与最长文本右侧对齐，避免文本与按钮重叠或间距过大。
四、Chain（链条）：控件组比例分配/对齐
定义：将多个控件通过“双向约束”连接成“链条”，可统一控制链条的对齐方式、比例分配空间，解决“多个控件按比例适配”的问题（替代LinearLayout的weight）。
核心属性：
链条领头控件设置layout_constraintHorizontal_chainStyle（水平链条）或layout_constraintVertical_chainStyle（垂直链条）。
链条样式：spread（均匀分布，默认）、spread_inside（两端贴边，中间均匀分布）、packed（紧凑排列）。
比例分配：通过layout_constraintHorizontal_weight（水平）设置权重。
示例场景：三个按钮水平按 1:2:1 比例分配父容器宽度。
<androidx.constraintlayout.widget.ConstraintLayoutandroid:layout_width="match_parent"android:layout_height="wrap_content"><Buttonandroid:id="@+id/btn1"android:layout_width="0dp" <!-- match_constraint -->android:layout_height="48dp"android:text="1"app:layout_constraintLeft_toLeftOf="parent"app:layout_constraintRight_toLeftOf="@id/btn2"app:layout_constraintHorizontal_weight="1" <!-- 权重 1 -->app:layout_constraintHorizontal_chainStyle="spread"/> <!-- 链条样式 --><Buttonandroid:id="@+id/btn2"android:layout_width="0dp"android:layout_height="48dp"android:text="2"app:layout_constraintLeft_toRightOf="@id/btn1"app:layout_constraintRight_toLeftOf="@id/btn3"app:layout_constraintHorizontal_weight="2"/> <!-- 权重 2 --><Buttonandroid:id="@+id/btn3"android:layout_width="0dp"android:layout_height="48dp"android:text="3"app:layout_constraintLeft_toRightOf="@id/btn2"app:layout_constraintRight_toRightOf="parent"app:layout_constraintHorizontal_weight="1"/> <!-- 权重 1 --></androidx.constraintlayout.widget.ConstraintLayout>
适配优势：比LinearLayout的weight更灵活（支持多种链条样式），且无需嵌套，性能更优，适配不同屏幕宽度时比例始终一致。
3.8、如何使用ConstraintLayout实现“响应式布局”？（适配不同屏幕尺寸的控件显示/隐藏、大小变化）
“响应式布局”的核心是“根据屏幕特性（尺寸、方向）动态调整UI”，ConstraintLayout结合“资源限定符”和“动态约束修改”，可轻松实现，主要有三种方式：
方式一：多ConstraintLayout布局（静态响应式）
利用“资源限定符”为不同屏幕尺寸创建独立的ConstraintLayout布局文件，系统自动加载匹配的布局，示例：手机（sw360dp）单面板布局，平板（sw600dp）双面板布局。
res/├─ layout/ # 手机布局（单面板）│ └─ activity_main.xml # ConstraintLayout 单面板└─ layout-sw600dp/ # 平板布局（双面板）└─ activity_main.xml # ConstraintLayout 双面板
适配逻辑：手机显示“列表”，平板显示“左侧列表+右侧详情”，无需代码修改，系统自动匹配。
方式二：动态修改约束（代码控制响应式）
通过ConstraintSet类动态修改控件的约束条件（显示/隐藏、大小、位置），适配不同屏幕尺寸，示例：屏幕宽度≥600dp 时显示右侧详情控件，否则隐藏。
class MainActivity : AppCompatActivity() {override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)val constraintLayout = findViewById<ConstraintLayout>(R.id.constraint_layout)val tvDetail = findViewById<TextView>(R.id.tv_detail)val screenWidth = resources.displayMetrics.widthPixelsval screenDensity = resources.displayMetrics.densityval screenWidthDp = screenWidth / screenDensity // 屏幕宽度（dp）// 初始化约束集（复制当前布局的约束）val constraintSet = ConstraintSet()constraintSet.clone(constraintLayout)if (screenWidthDp >= 600) { // 平板（≥600dp）：显示详情，调整约束tvDetail.visibility = View.VISIBLE// 动态修改详情控件的约束（右侧对齐父容器，左侧对齐列表）constraintSet.connect(R.id.tv_detail, ConstraintSet.LEFT,R.id.rv_list, ConstraintSet.RIGHT,dp2px(16) // 间距 16dp（转 px）)constraintSet.connect(R.id.tv_detail, ConstraintSet.RIGHT, ConstraintSet.PARENT_ID, ConstraintSet.RIGHT, dp2px(16))constraintSet.connect(R.id.tv_detail, ConstraintSet.TOP, ConstraintSet.PARENT_ID, ConstraintSet.TOP, dp2px(16))constraintSet.connect(R.id.tv_detail, ConstraintSet.BOTTOM, ConstraintSet.PARENT_ID, ConstraintSet.BOTTOM, dp2px(16))constraintSet.applyTo(constraintLayout) // 应用约束修改} else { // 手机（<600dp）：隐藏详情tvDetail.visibility = View.GONE}}// dp 转 px 工具方法private fun dp2px(dp: Int): Int {return (dp * resources.displayMetrics.density).toInt()}}
方式三：使用layout_constraintWidth_percent实现比例大小
通过“百分比宽度/高度”属性，让控件大小随屏幕尺寸等比例变化，无需代码修改，示例：图片宽度占父容器80%，高度为宽度的50%（保持宽高比2:1）：
<ImageViewandroid:layout_width="0dp"android:layout_height="0dp"android:src="@drawable/img_banner"app:layout_constraintLeft_toLeftOf="parent"app:layout_constraintRight_toRightOf="parent"app:layout_constraintTop_toTopOf="parent"app:layout_constraintWidth_percent="0.8" <!-- 宽度占父容器80% -->app:layout_constraintDimensionRatio="2:1"/> <!-- 宽高比 2:1 -->
适配优势：无论屏幕宽度是360dp还是600dp，图片始终保持80%宽度和2:1比例，不会变形。
3.9、ConstraintLayout与传统布局（LinearLayout/RelativeLayout）相比，适配效率和性能有何提升？
一、适配效率提升：从“繁琐嵌套”到“一站式适配”
实例对比：实现“顶部标题栏+中间三列按钮+底部按钮”的UI：
传统布局：需3层 LinearLayout 嵌套（垂直 LinearLayout 包含顶部、中间、底部，中间是水平 LinearLayout 包含 3 个按钮）。
ConstraintLayout：单层布局，通过链条、约束直接实现，适配时仅需调整约束参数，无需修改布局结构。
二、性能提升：从“递归测量”到“单层测量”
布局性能的核心是“测量（measure）”和“布局（layout）”的耗时，ConstraintLayout通过“扁平化”大幅优化。
测量次数优化：传统嵌套布局：测量是“递归过程”（先测量子控件，再测量父控件），嵌套N层需测量N+1次，ConstraintLayout：仅需“单层测量”（一次性测量所有子控件，通过约束计算位置），无论子控件多少，测量次数固定为2次（最坏情况）。
绘制效率优化：嵌套布局会增加“过度绘制”风险（多层控件重叠绘制），ConstraintLayout单层结构，控件层级清晰，过度绘制风险低，绘制更流畅。
性能测试数据（Google官方测试）：复杂UI（10+ 控件）：ConstraintLayout的测量+布局耗时比传统嵌套布局低30%-50%，滚动列表（如RecyclerView -item使用）：ConstraintLayout加载速度比传统布局快20%+，适配大屏设备时卡顿更少。
核心结论：ConstraintLayout既解决了传统布局“适配灵活性不足”的问题，又优化了“嵌套导致的性能损耗”，是XML布局时代的“终极适配方案”，Google推荐使用它替代所有复杂嵌套布局，从根本上提升适配效率和应用性能。
Jetpack Compose适配方案
Jetpack Compose是Google推出的声明式UI框架（替代传统XML布局），其适配逻辑与XML布局有本质区别，核心是“状态驱动UI，适配逻辑与UI代码一体化”。
3.10、Jetpack Compose 的“声明式 UI”思想如何影响屏幕适配？与 XML 布局适配的核心差异是什么？
一、声明式UI对适配的核心影响
传统XML布局是“命令式”（先定义UI结构，再通过代码修改UI），而Compose是“声明式”（通过“状态”描述UI应该是什么样，状态变化时UI自动重绘），这种思想让适配更简洁、更灵活。
适配逻辑与UI代码融合：无需单独维护多套布局文件或资源文件，适配规则可直接写在UI代码中（如根据屏幕尺寸判断显示哪种UI）。
状态驱动适配：屏幕尺寸、方向变化时，可视为“状态变化”，UI自动重绘为适配后的样式，无需手动刷新布局。
无嵌套冗余：声明式UI天然支持“组合式”布局（而非嵌套），适配时无需考虑层级问题。
二、与XML布局适配的核心差异
核心差异总结：XML适配是“基于资源的适配”（通过多资源文件弥合设备差异），而Compose适配是“基于状态的适配”（通过状态判断动态生成适配 UI），前者是“静态适配”，后者是“动态适配”。
3.11、Compose中如何使用dp单位和sp单位？其底层适配逻辑与XML布局有何不同？
一、Compose中dp和sp的使用方式
Compose中单位是“内联类”（Dp和Sp），无需像XML那样写字符串（如16dp），直接使用Kotlin常量或扩展函数，用法更简洁：
dp单位：用于控件大小、间距等布局相关尺寸，直接使用dp后缀（如16.dp）。
sp单位：用于文字大小，直接使用sp后缀（如18.sp）。
示例代码：
fun AdaptUnitExample() {Column(modifier = Modifier.fillMaxWidth().padding(16.dp) // dp 单位：间距) {Text(text = "Compose 单位适配示例",fontSize = 18.sp, // sp 单位：文字大小modifier = Modifier.width(200.dp) // dp 单位：宽度.height(48.dp) // dp 单位：高度)Button(onClick = {},modifier = Modifier.width(120.dp).height(48.dp).margin(top = 16.dp)) {Text(text = "点击", fontSize = 16.sp)}}}
二、底层适配逻辑对比
Compose与XML布局的dp/sp底层适配逻辑“核心一致”（都基于屏幕密度换算），但实现方式不同。
关键差异：Compose的单位是“类型安全”的（编译时检查是否为Dp/Sp），避免了XML中“将dp写成px”的低级错误，同时支持“局部密度修改”，可实现“全局统一适配+局部特殊适配”（如某页面需要不同的缩放比例）。
3.12、Compose中的Modifier（如fillMaxWidth、weight、constrainAs）如何实现灵活适配？
Modifier是Compose中“控制UI布局、样式、行为”的核心工具，其设计理念是“链式调用、组合复用”，以下四个关键Modifier是适配的核心。
fillMaxWidth/fillMaxHeight：填充父容器空间
作用：控件宽度/高度填充父容器的全部空间（类似XML的match_parent），适配不同屏幕尺寸。
进阶用法：支持传入比例参数（0-1 之间），实现“占父容器百分比宽度/高度”。
示例：按钮宽度占父容器80%，高度占10%：
fun FillMaxExample() {Box(modifier = Modifier.fillMaxSize() // 父容器填充整个屏幕.padding(16.dp)) {Button(onClick = {},modifier = Modifier.fillMaxWidth(0.8f) // 宽度占父容器 80%.fillMaxHeight(0.1f) // 高度占父容器 10%) {Text(text = "填充比例示例")}}}
适配优势：无需手动计算尺寸，自动适应不同屏幕大小，比例始终一致。
weight：线性比例分配空间
作用：在Row或Column中，按权重比例分配剩余空间（类似LinearLayout 的 weight）。
使用条件：需配合modifier.weight()，且控件的宽度（Row）/高度（Column）设为Modifier.width(0.dp)（或 fillMaxWidth()）。
示例：三个按钮在Row中按1:2:1比例分配宽度。
fun WeightExample() {Row(modifier = Modifier.fillMaxWidth().padding(16.dp)) {Button(onClick = {},modifier = Modifier.weight(1f) // 权重 1.height(48.dp)) { Text(text = "1") }Button(onClick = {},modifier = Modifier.weight(2f) // 权重 2.height(48.dp).padding(horizontal = 4.dp)) { Text(text = "2") }Button(onClick = {},modifier = Modifier.weight(1f) // 权重 1.height(48.dp)) { Text(text = "3") }}}
适配优势：比XML的weight更简洁，支持链式调用，且无布局嵌套，性能更优。
constrainAs：Compose中的约束布局适配
Compose提供ConstraintLayout组件（需添加依赖），通过constrainAs修饰符实现类似XML ConstraintLayout的精准约束：
依赖添加（build.gradle）：
implementation "androidx.constraintlayout:constraintlayout-compose:1.0.1"示例：控件水平居中、距离顶部32.dp，右侧对齐另一个控件。
fun ConstraintLayoutExample() {androidx.constraintlayout.compose.ConstraintLayout(modifier = Modifier.fillMaxWidth()) {// 定义约束引用 IDval (tvTitle, btnAction) = createRefs()Text(text = "约束布局示例",modifier = Modifier.constrainAs(tvTitle) { // 约束 tvTitletop.linkTo(parent.top, margin = 32.dp)start.linkTo(parent.start)end.linkTo(btnAction.start, margin = 16.dp)})Button(onClick = {},modifier = Modifier.constrainAs(btnAction) { // 约束 btnActiontop.linkTo(tvTitle.top)end.linkTo(parent.end)}) {Text(text = "操作")}}}
适配优势：继承XML ConstraintLayout的精准约束能力，同时结合Compose的声明式思想，适配逻辑更简洁，支持动态约束修改。
padding/margin：自适应间距
作用：控制控件的内边距（padding）和外边距（margin），使用dp单位，自动适配不同密度设备。
进阶用法：结合LocalConfiguration获取屏幕尺寸，动态调整间距。
示例：屏幕宽度≥600dp时，间距设为24.dp，否则设为16.dp：
fun DynamicPaddingExample() {val config = LocalConfiguration.currentval screenWidthDp = config.screenWidthDp // 屏幕宽度（dp）val padding = if (screenWidthDp >= 600) 24.dp else 16.dpColumn(modifier = Modifier.fillMaxWidth().padding(padding)) {Text(text = "动态间距示例", fontSize = 18.sp)Text(text = "屏幕宽度：$screenWidthDp dp", fontSize = 16.sp, modifier = Modifier.margin(top = padding))}}
适配优势：间距随屏幕尺寸动态调整，避免小屏拥挤、大屏间距过大。
3.13、Compose如何处理不同屏幕尺寸和方向的适配？（如使用BoxWithConstraints、WindowSizeClass）
Compose提供了三个核心工具，专门解决“屏幕尺寸+方向”适配问题，覆盖从简单到复杂的所有场景。
工具一：LocalConfiguration + 状态判断（基础适配）
LocalConfiguration是Compose提供的“设备配置局部变量”，可获取屏幕尺寸、方向、密度等信息，通过状态判断动态调整UI。
核心属性：
screenWidthDp/screenHeightDp：屏幕宽高（dp）。
orientation：屏幕方向（Configuration.ORIENTATION_PORTRAIT 竖屏，Configuration.ORIENTATION_LANDSCAPE 横屏）。
示例：竖屏显示Column（垂直排列），横屏显示Row（水平排列）：
fun OrientationAdaptExample() {val config = LocalConfiguration.currentval isPortrait = config.orientation == Configuration.ORIENTATION_PORTRAITif (isPortrait) {// 竖屏：垂直排列Column(modifier = Modifier.fillMaxWidth().padding(16.dp)) {Text(text = "竖屏模式", fontSize = 18.sp)Button(onClick = {}, modifier = Modifier.margin(top = 16.dp)) { Text(text = "竖屏按钮") }}} else {// 横屏：水平排列Row(modifier = Modifier.fillMaxWidth().padding(16.dp)) {Text(text = "横屏模式", fontSize = 18.sp)Button(onClick = {}, modifier = Modifier.margin(start = 16.dp)) { Text(text = "横屏按钮") }}}}
适配优势：简单直接，无需额外依赖，适合基础的尺寸/方向适配。
工具二：BoxWithConstraints（获取父容器尺寸）
BoxWithConstraints是“带约束的Box”，可获取父容器的可用尺寸（宽高），从而根据父容器大小调整子UI，解决“子控件需适配父容器尺寸”的问题。
示例：父容器宽度≥300dp时，子控件显示为卡片样式，否则显示为简单文本：
fun BoxWithConstraintsExample() {BoxWithConstraints(modifier = Modifier.fillMaxWidth().padding(16.dp)) {// constraints 是父容器的约束信息（宽高、最小宽高）val parentWidth = constraints.maxWidth.dp // 父容器最大宽度（dp）if (parentWidth >= 300.dp) {// 父容器足够宽：显示卡片样式Card(modifier = Modifier.fillMaxWidth(),elevation = CardDefaults.cardElevation(8.dp)) {Text(text = "卡片样式（父容器宽度≥300dp）",modifier = Modifier.padding(24.dp),fontSize = 18.sp)}} else {// 父容器较窄：显示简单文本Text(text = "简单文本（父容器宽度<300dp）",modifier = Modifier.fillMaxWidth(),fontSize = 16.sp)}}}
适配优势：精准响应父容器尺寸，而非屏幕尺寸，适合嵌套布局中的局部适配。
工具三：WindowSizeClass（Google推荐，大屏适配）
WindowSizeClass是Jetpack提供的“窗口尺寸分类工具”（AndroidX核心库），将屏幕尺寸分为“小屏、中屏、大屏、超大屏”，是Google推荐的“多设备适配标准”（尤其适合平板、折叠屏）。
核心分类（基于屏幕宽度dp）：
Compact（紧凑屏）：<600dp（手机竖屏）。
Medium（中屏）：600dp-840dp（手机横屏、小平板）。
Expanded（大屏）：≥840dp（平板、折叠屏展开）。
使用步骤：
1、添加依赖（build.gradle）：
implementation "androidx.window:window:1.1.0"2、在Activity中获取WindowSizeClass。
3、传递给Composable函数，根据分类调整UI。
示例代码：
// Activity 中获取 WindowSizeClassclass MainActivity : ComponentActivity() {override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)val windowSizeClass = calculateWindowSizeClass(this) // 获取窗口尺寸分类setContent {WindowSizeAdaptExample(windowSizeClass = windowSizeClass)}}}// Composable 中适配不同窗口尺寸fun WindowSizeAdaptExample(windowSizeClass: WindowSizeClass) {when (windowSizeClass.widthSizeClass) {WindowWidthSizeClass.Compact -> {// 紧凑屏（手机竖屏）：单面板CompactScreen()}WindowWidthSizeClass.Medium -> {// 中屏（手机横屏）：双面板（列表+简易详情）MediumScreen()}WindowWidthSizeClass.Expanded -> {// 大屏（平板/折叠屏）：双面板（完整列表+完整详情）ExpandedScreen()}}}// 紧凑屏 UIfun CompactScreen() {Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {Text(text = "手机竖屏：单面板", fontSize = 18.sp)// 列表 UI...}}// 中屏 UIfun MediumScreen() {Row(modifier = Modifier.fillMaxSize()) {Column(modifier = Modifier.weight(1f).padding(16.dp)) {Text(text = "手机横屏：列表", fontSize = 18.sp)// 列表 UI...}Column(modifier = Modifier.weight(1f).padding(16.dp)) {Text(text = "简易详情", fontSize = 18.sp)// 简易详情 UI...}}}// 大屏 UIfun ExpandedScreen() {Row(modifier = Modifier.fillMaxSize()) {Column(modifier = Modifier.weight(1f).padding(16.dp)) {Text(text = "平板：完整列表", fontSize = 18.sp)// 完整列表 UI...}Column(modifier = Modifier.weight(2f).padding(16.dp)) {Text(text = "平板：完整详情", fontSize = 18.sp)// 完整详情 UI...}}}
适配优势：标准化的尺寸分类，无需手动定义屏幕区间，适配逻辑更统一，完美支持手机、平板、折叠屏等多设备。
3.14、Compose中矢量图（ImageVector）的使用和适配优势是什么？
Compose中推荐使用ImageVector作为矢量图格式（替代XML中的VectorDrawable），其适配优势更突出，使用更便捷。
一、ImageVector的使用方式
ImageVector是Compose原生支持的矢量图格式，有两种创建方式：
通过XML矢量图转换：将传统VectorDrawable（.xml 文件）转换为ImageVector，使用painterResource加载。
通过Compose内置函数创建：使用ImageVector.Builder手动构建简单矢量图（如箭头、图标）。
示例代码：
fun ImageVectorExample() {Column(modifier = Modifier.fillMaxWidth().padding(16.dp)) {// 方式 1：加载 XML 矢量图（res/drawable/icon_arrow.xml）Image(painter = painterResource(id = R.drawable.icon_arrow),contentDescription = "箭头图标",modifier = Modifier.size(48.dp) // 任意尺寸，不失真.margin(bottom = 16.dp))// 方式 2：手动构建 ImageVector（简单箭头）val customArrow = ImageVector.Builder(name = "CustomArrow",defaultWidth = 24.dp,defaultHeight = 24.dp,viewportWidth = 24f,viewportHeight = 24f).path(pathData = androidx.compose.ui.graphics.PathData {moveTo(12f, 5f)lineTo(19f, 12f)lineTo(12f, 19f)lineTo(5f, 12f)close()},fill = SolidColor(Color.Red)).build()Image(imageVector = customArrow,contentDescription = "自定义箭头",modifier = Modifier.size(64.dp) // 放大到 64dp，不失真)}}
二、核心适配优势
无限缩放不失真：与VectorDrawable一致，ImageVector基于路径描述，无论放大多少倍（如平板上显示大图标），都不会模糊或出现锯齿，完美适配所有密度设备。
体积更小，加载更快：ImageVector是Compose原生格式，无需像VectorDrawable那样进行兼容性转换，加载速度更快，且XML代码量少，减少安装包体积。
动态修改更便捷：可直接通过代码修改ImageVector的颜色、路径、大小，无需创建多个资源文件，适配不同主题或状态（如选中/未选中状态的图标颜色变化）。
无兼容性问题：ImageVector是Compose内置格式，无需依赖VectorDrawableCompat，支持所有Compose兼容的Android版本（API 21+）。
与Modifier完美配合：可通过Modifier的size()任意调整图标大小，适配不同屏幕尺寸的控件需求（如手机上24dp，平板上32dp）。
三、使用注意事项
仅适用于简单图标：复杂矢量图（如带渐变、纹理的图形）仍建议使用VectorDrawable或位图。
避免过度复杂路径：路径过多会增加绘制耗时，影响性能，复杂图标建议拆分或使用位图替代。
Jetpack Compose适配方案总结：
核心思想：声明式UI+状态驱动，适配逻辑与UI代码一体化，动态响应设备变化。
单位使用：dp/sp是类型安全的内联类，底层换算逻辑与XML一致，支持局部密度修改。
适配工具：Modifier（fillMaxWidth/weight/constrainAs）、BoxWithConstraints（父容器尺寸适配）、WindowSizeClass（标准化多设备适配）。
矢量图优势：ImageVector原生支持、无限缩放、动态修改便捷，适配所有密度设备。
适用场景：新Compose项目，多设备（手机、平板、折叠屏）适配，追求高灵活性和开发效率的场景。
ConstraintLayout解决了传统XML布局的适配痛点，而Compose则重构了适配逻辑，让适配更简洁、更灵活，是未来Android适配的主流方向。
其他主流适配方案
3.15、 “AndroidAutoSize框架”的核心功能是什么？与今日头条方案相比，有哪些优化和扩展？
项目地址：https://github.com/JessYanCoding/AndroidAutoSize
一、AndroidAutoSize核心功能
AndroidAutoSize是基于今日头条方案优化的开源全局适配框架，核心定位是“让全局适配更稳定、更灵活、更易集成”，核心功能包括如下。
自动全局适配：无需手动计算density，框架自动根据设计图基准尺寸，修改DisplayMetrics，实现全项目dp等比例缩放。
多维度适配支持：支持“宽度适配”“高度适配”“最小宽度适配”“屏幕方向适配”，可按需选择适配维度。
细粒度控制：支持单个Activity/Fragment单独设置设计图基准，或排除适配（如WebView页面）。
兼容性优化：解决了今日头条方案的WebView重置、系统字体调整、多进程适配等痛点。
无侵入集成：仅需添加依赖+配置设计图尺寸，无需修改现有布局代码，集成成本极低。
二、与今日头条方案的优化和扩展
今日头条方案是“基础思路”，AndroidAutoSize是“工业化成熟方案”，核心优化点如下。
三、核心代码示例（集成与使用）
步骤一：添加依赖（build.gradle）
// AndroidX 项目implementation 'me.jessyan:autosize:1.2.1'// 可选：权限申请（若需适配 Android 10+ 分区存储）implementation 'me.jessyan:autosize-annotation:1.2.1'annotationProcessor 'me.jessyan:autosize-compiler:1.2.1'
步骤二：配置设计图基准（3种方式，推荐方式1）
方式一：AndroidManifest.xml 全局配置（推荐）
<application...><!-- 设计图宽度（dp），与设计师确认 --><meta-dataandroid:name="design_width_in_dp"android:value="360"/><!-- 设计图高度（dp），仅在“高度适配”时生效 --><meta-dataandroid:name="design_height_in_dp"android:value="640"/></application>
方式二：单个Activity单独配置（注解方式）
// 该Activity用375dp宽度基准，覆盖全局配置@AutoSizeConfig(designWidth = 375, designHeight = 667)class DetailActivity : AppCompatActivity() {// ...}
方式三：排除某个页面适配（注解方式）
// WebView 页面，排除适配，避免 WebView 与原生布局冲突@AutoSizeIgnoreclass WebViewActivity : AppCompatActivity() {// ...}
步骤三：高级配置（可选，如切换适配维度）
// 在 Application 中初始化时配置class MyApp : Application() {override fun onCreate() {super.onCreate()AutoSize.initCompatMultiProcess(this)// 切换适配维度：默认是宽度适配，可改为最小宽度适配AutoSizeConfig.getInstance().setBaseOn(BaseOn.MIN_WIDTH) // 基于最小宽度（sw dp）适配.setExcludeFontScale(true) // 是否排除字体缩放（默认 false，支持字体同步缩放）}}
四、核心优势总结
AndroidAutoSize是今日头条方案的“增强版”，解决了基础方案的兼容性和灵活性问题，适合中大型项目、多模块项目、WebView较多的项目，既保留了全局适配的高效性，又避免了基础方案的各种“坑”。
3.16、 “屏幕尺寸适配框架（如SizeAdapter）”的实现思路是什么？适用于哪些复杂场景？
一、核心实现思路
SizeAdapter这类框架的核心是“基于屏幕尺寸分类+动态适配规则”，本质是对“最小宽度适配（sw dp）”的灵活扩展，实现思路可拆解为三步。
屏幕尺寸分类：框架预定义或自定义“屏幕尺寸区间”（如小屏<360dp、中屏360-600dp、大屏≥600dp），或直接使用设备的sw dp、宽高比作为分类依据。
适配规则定义：为每个尺寸区间定义独立的适配规则，包括“控件尺寸缩放比例”“布局结构切换”“控件显示/隐藏”等。
动态应用规则：框架在Activity启动时，自动检测当前设备的尺寸分类，加载对应的适配规则，通过修改控件布局参数（如宽高、margin、visibility）实现适配。
二、核心技术细节
尺寸检测：通过Resources.getConfiguration().screenWidthDp、DisplayMetrics等获取屏幕尺寸。
规则存储：适配规则可存储在XML文件、JSON配置或代码中，支持动态修改。
布局修改：通过View.post()或OnGlobalLayoutListener监听布局加载完成，再动态修改控件参数，避免布局未加载导致的尺寸计算错误。
三、简单实现示例（核心逻辑）
// 1. 定义屏幕尺寸分类enum class ScreenSizeType {SMALL, // 小屏：<360dpMEDIUM, // 中屏：360dp-600dpLARGE // 大屏：≥600dp}// 2. 定义适配规则data class AdaptRule(val scale: Float, // 控件尺寸缩放比例val showExtraView: Boolean // 是否显示额外控件)// 3. 核心适配工具类object SizeAdapter {// 预定义适配规则private val adaptRules = mapOf(ScreenSizeType.SMALL to AdaptRule(0.8f, false),ScreenSizeType.MEDIUM to AdaptRule(1.0f, true),ScreenSizeType.LARGE to AdaptRule(1.2f, true))// 检测当前屏幕尺寸类型fun getScreenSizeType(context: Context): ScreenSizeType {val screenWidthDp = context.resources.configuration.screenWidthDpreturn when {screenWidthDp < 360 -> ScreenSizeType.SMALLscreenWidthDp < 600 -> ScreenSizeType.MEDIUMelse -> ScreenSizeType.LARGE}}// 应用适配规则（在 Activity 的 onCreate 中调用）fun applyAdapt(activity: Activity) {val screenType = getScreenSizeType(activity)val rule = adaptRules[screenType] ?: AdaptRule(1.0f, true)// 遍历根布局下的所有控件，应用缩放规则val rootView = activity.findViewById<ViewGroup>(android.R.id.content)rootView.post { // 确保布局已加载完成traverseView(rootView, rule)}}// 递归遍历控件，修改尺寸和显示状态private fun traverseView(view: View, rule: AdaptRule) {// 1. 缩放控件宽高val layoutParams = view.layoutParams ?: returnif (layoutParams.width > 0) { // 仅缩放固定尺寸的控件layoutParams.width = (layoutParams.width * rule.scale).toInt()}if (layoutParams.height > 0) {layoutParams.height = (layoutParams.height * rule.scale).toInt()}view.layoutParams = layoutParams// 2. 处理额外控件显示/隐藏（示例：tag 为 "extra_view" 的控件）if (view.tag == "extra_view") {view.visibility = if (rule.showExtraView) View.VISIBLE else View.GONE}// 3. 递归处理子控件if (view is ViewGroup) {for (i in 0 until view.childCount) {traverseView(view.getChildAt(i), rule)}}}}// 4. 在 Activity 中使用class MainActivity : AppCompatActivity() {override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)// 应用尺寸适配规则SizeAdapter.applyAdapt(this)}}
四、适用复杂场景
SizeAdapter这类框架的核心优势是“精细化、可配置”，适用于以下复杂场景：
多形态设备适配：折叠屏（折叠/展开状态尺寸变化）、平板+手机跨设备适配，需要“不同尺寸区间有不同缩放比例”。
老项目改造：老项目未使用dp单位（或使用px单位），无法重构布局，需通过框架动态缩放控件尺寸。
多模块差异化适配：同一项目中，不同模块的设计图基准不同（如A模块360dp，B 模块375dp），需为每个模块配置独立规则。
控件级精细适配：部分控件需要特殊缩放（如标题栏不缩放，内容区缩放），支持按控件 tag/ID 单独配置规则。
动态适配需求：适配规则需从服务器获取（如根据用户设备类型返回不同缩放比例），支持动态修改规则。
五、注意事项
仅适用于“固定尺寸控件”：对match_parent/wrap_content的控件无效，需结合ConstraintLayout等布局使用。
避免过度缩放：缩放比例过大可能导致控件变形，建议缩放范围控制在0.8-1.2之间。
性能影响：递归遍历控件会增加少量耗时，复杂布局建议只适配关键控件，而非全部控件。
3.17、Google 推荐的“窗口尺寸类（WindowSizeClass）”是什么？如何使用它实现多屏幕适配？（Android 12+）
一、WindowSizeClass核心定义
WindowSizeClass是Google在Android 12（API 31）推出的“窗口尺寸分类标准”，核心目的是：统一多设备的“尺寸分类规则”，替代自定义的sw dp区间（如360dp、600dp），让开发者无需关注具体屏幕尺寸，只需根据“尺寸类”设计UI，实现“一次设计，多设备适配”。
它将屏幕尺寸分为宽度尺寸类（WindowWidthSizeClass）和高度尺寸类（WindowHeightSizeClass），每个分类对应不同设备形态：
二、核心优势
标准化：Google统一的分类规则，适配逻辑更通用，避免不同开发者自定义区间导致的混乱。
窗口感知：不仅支持全屏适配，还支持分屏、多窗口、折叠屏等场景（窗口尺寸变化时，尺寸类会同步更新）。
框架集成：与Jetpack Compose、ConstraintLayout等官方框架深度集成，使用便捷。
向前兼容：通过androidx.window库，可兼容到Android 7.0（API 24），无需局限于Android 12+。
三、使用步骤（兼容Android 7.0+）
步骤一：添加依赖（build.gradle）
// 核心依赖（窗口尺寸类）implementation "androidx.window:window:1.2.0"// 可选：Compose 集成（若使用 Compose）implementation "androidx.window:window-compose:1.2.0"
步骤二：获取WindowSizeClass
有两种方式获取，分别适用于XML布局和Jetpack Compose。
方式一：XML 布局（Activity/Fragment 中）
class MainActivity : AppCompatActivity() {private lateinit var windowSizeClass: WindowSizeClassoverride fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)// 1. 获取 WindowSizeClass（需在 onCreate 中调用）windowSizeClass = calculateWindowSizeClass(this)// 2. 根据尺寸类适配 UIadaptUI(windowSizeClass.widthSizeClass)}// 根据宽度尺寸类适配 UIprivate fun adaptUI(widthSizeClass: WindowWidthSizeClass) {val tvTitle = findViewById<TextView>(R.id.tv_title)val extraView = findViewById<View>(R.id.extra_view)val constraintLayout = findViewById<ConstraintLayout>(R.id.root_layout)val constraintSet = ConstraintSet().apply { clone(constraintLayout) }when (widthSizeClass) {WindowWidthSizeClass.Compact -> {// 紧凑屏（手机竖屏）：隐藏额外控件，单栏布局tvTitle.text = "手机竖屏模式"extraView.visibility = View.GONEconstraintSet.clear(R.id.content, ConstraintSet.END)constraintSet.connect(R.id.content, ConstraintSet.END, ConstraintSet.PARENT_ID, ConstraintSet.END, 16.dp2px())}WindowWidthSizeClass.Medium -> {// 中屏（手机横屏）：显示额外控件，双栏布局（1:1）tvTitle.text = "手机横屏模式"extraView.visibility = View.VISIBLEconstraintSet.connect(R.id.content, ConstraintSet.END, R.id.extra_view, ConstraintSet.START, 16.dp2px())constraintSet.connect(R.id.extra_view, ConstraintSet.END, ConstraintSet.PARENT_ID, ConstraintSet.END, 16.dp2px())}WindowWidthSizeClass.Expanded -> {// 大屏（平板/折叠屏）：显示额外控件，双栏布局（1:2）tvTitle.text = "平板/折叠屏模式"extraView.visibility = View.VISIBLEconstraintSet.connect(R.id.content, ConstraintSet.END, R.id.extra_view, ConstraintSet.START, 24.dp2px())constraintSet.connect(R.id.extra_view, ConstraintSet.END, ConstraintSet.PARENT_ID, ConstraintSet.END, 24.dp2px())// 调整 extra_view 宽度为 content 的 2 倍（通过 ConstraintLayout 链条权重）constraintSet.setHorizontalChainStyle(R.id.content, ConstraintSet.CHAIN_SPREAD)constraintSet.setConstraintWeight(R.id.content, 1f)constraintSet.setConstraintWeight(R.id.extra_view, 2f)}}constraintSet.applyTo(constraintLayout)}// dp 转 px 工具方法private fun Int.dp2px() = (this * resources.displayMetrics.density).toInt()}
方式二：Jetpack Compose（推荐，更简洁）
fun WindowSizeAdaptExample() {// 1. Compose 中直接获取 WindowSizeClass（需添加 window-compose 依赖）val windowSizeClass = calculateWindowSizeClass()val widthSizeClass = windowSizeClass.widthSizeClass// 2. 根据尺寸类动态组合 UIwhen (widthSizeClass) {WindowWidthSizeClass.Compact -> {// 紧凑屏：单栏布局Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {Text(text = "手机竖屏模式", fontSize = 18.sp)ContentView() // 核心内容控件}}WindowWidthSizeClass.Medium -> {// 中屏：双栏布局（1:1）Row(modifier = Modifier.fillMaxSize().padding(16.dp)) {ContentView(modifier = Modifier.weight(1f))ExtraView(modifier = Modifier.weight(1f).padding(start = 16.dp))}}WindowWidthSizeClass.Expanded -> {// 大屏：双栏布局（1:2）Row(modifier = Modifier.fillMaxSize().padding(24.dp)) {ContentView(modifier = Modifier.weight(1f))ExtraView(modifier = Modifier.weight(2f).padding(start = 24.dp))}}}}// 核心内容控件fun ContentView(modifier: Modifier = Modifier) {Box(modifier = modifier.fillMaxHeight().background(Color.LightGray), contentAlignment = Alignment.Center) {Text(text = "核心内容", fontSize = 16.sp)}}// 额外控件fun ExtraView(modifier: Modifier = Modifier) {Box(modifier = modifier.fillMaxHeight().background(Color.Gray), contentAlignment = Alignment.Center) {Text(text = "额外详情", fontSize = 16.sp, color = Color.White)}}
步骤三：处理窗口尺寸变化（如分屏、折叠状态切换）
当窗口尺寸变化时（如分屏、折叠屏展开/折叠），需重新适配 UI：
// 在 Activity 中重写 onConfigurationChanged（需在 AndroidManifest 中配置 configChanges）override fun onConfigurationChanged(newConfig: Configuration) {super.onConfigurationChanged(newConfig)// 重新计算 WindowSizeClass，适配新尺寸windowSizeClass = calculateWindowSizeClass(this)adaptUI(windowSizeClass.widthSizeClass)}// AndroidManifest 配置（允许监听屏幕尺寸变化）<activityandroid:name=".MainActivity"android:configChanges="screenSize|orientation|smallestScreenSize"/>
四、适用场景
多设备适配：手机、平板、折叠屏、桌面端（Chrome OS）统一适配。
窗口化场景：分屏、多窗口、悬浮窗适配。
官方推荐方案：Google明确建议新项目使用WindowSizeClass替代自定义尺寸区间，尤其适合Compose项目。