企业官网建设流程全解析

1. 字体适配到底在解决什么问题

做过Android开发的人大概都遇到过这种场景：用户把系统字体调到最大，打开你的App，发现首页的标题直接撑破容器，按钮上的文字被截断成两行，列表项的高度错乱，整个界面像是被人捏变形了一样。更尴尬的是，测试同学提了个bug说“字体调到最大时页面崩了”，你打开自己的手机一看——一切正常，因为你的系统字体是默认的。

这就是字体适配要解决的核心问题。它不是一个“锦上添花”的优化项，而是一个必须处理的基础适配问题。Android系统从很早的版本就允许用户在设置里调整字体大小，这个设置的初衷是好的——照顾视力不佳的用户。但对于开发者来说，它带来的是一系列连锁反应：SP单位的文字会跟着系统设置缩放，而DP单位的布局不会，两者一配合，界面就崩了。

这篇文章要聊的，就是怎么让App的字体不跟随系统字体大小变化，以及在需要的时候动态设置字体大小时，会遇到哪些坑。我会把整个思路拆开，从最基础的单位概念讲起，一直讲到具体的代码实现和踩坑记录。不管你是刚接触Android不久的新手，还是做过几个项目但一直没系统整理过这块的老手，应该都能从中找到有用的东西。

先明确一下适用范围：这里讨论的是原生Android开发（Kotlin/Java），不涉及Flutter、React Native等跨平台方案。文中提到的方案在Android 5.0到Android 14上我都实际验证过，基本覆盖了目前主流的设备范围。

2. 先搞清楚SP、DP和系统字体缩放的关系

2.1 SP和DP的本质区别

很多开发者对SP和DP的理解停留在“文字用SP，其他用DP”这个层面，但具体为什么，可能没仔细想过。

DP的全称是Density-independent Pixels，它只跟屏幕密度有关。比如一个160dpi的屏幕上，1dp等于1px；320dpi的屏幕上，1dp等于2px。系统会根据屏幕密度自动换算，保证不同设备上看到的物理尺寸大致一致。

SP的全称是Scale-independent Pixels，它在DP的基础上多了一个维度——用户的字体缩放偏好。也就是说，1sp最终占多少像素，等于屏幕密度换算 × 用户的字体缩放系数。这个缩放系数就是系统设置里那个字体大小滑块控制的。

用一个生活化的类比：DP就像是一个固定尺寸的盒子，不管谁来拿都是那么大；SP则像是一个可以根据使用者手的大小自动调整的盒子——手大的人拿到的盒子就大一些。这个设计本身是合理的，问题在于，当你的布局没有为“盒子变大”留出足够空间时，就会出问题。

2.2 系统字体缩放的取值范围

不同厂商的系统对字体缩放范围的定义不太一样。原生Android通常提供“小”、“默认”、“大”、“最大”四档，对应的缩放系数大约是0.85、1.0、1.15、1.3。但部分厂商的系统会提供更极端的档位，比如某些定制系统可以调到1.5甚至2.0。

这意味着什么？假设你的按钮文字用的是14sp，在默认设置下显示正常。当用户把字体调到最大档（假设缩放系数1.3），实际渲染出来的文字大小相当于18.2sp。如果按钮的高度是固定48dp，文字可能还能放下；但如果用户用的是某些可以调到2.0的系统，14sp就变成了28sp，按钮直接装不下了。

注意：不要假设用户的字体缩放系数只在1.0附近波动。实际数据显示，有相当比例的用户会主动调整字体大小，尤其是中老年用户群体。

2.3 为什么“不跟随系统字体”是一个合理需求

看到这里你可能会问：系统提供字体缩放是为了无障碍，我们把它禁掉，是不是不太合适？

这个问题要分两面看。对于以阅读为主的App（比如新闻客户端、电子书阅读器），跟随系统字体大小是合理的，甚至应该主动适配。但对于工具类、电商类、社交类App，界面的布局密度很高，元素之间的间距是精心计算过的，如果文字突然放大30%，整个设计就崩了。这时候，更合理的做法是：App内部提供自己的字体大小设置，让用户在App的框架内调整，而不是直接跟随系统。

这就是标题里说的“不跟随系统字体大小、动态设置字体大小”的实际含义——我们要把字体大小的控制权从系统手里拿回来，放到App自己手里。

3. 让字体不跟随系统缩放的几种方案对比

3.1 方案一：在BaseActivity中覆写attachBaseContext

这是目前最主流、兼容性最好的方案。核心思路是在Activity的上下文创建阶段，通过覆写Configuration中的fontScale值，把它强制设为1.0。

override fun attachBaseContext(newBase: Context) { val config = Configuration(newBase.resources.configuration) config.fontScale = 1.0f val newContext = newBase.createConfigurationContext(config) super.attachBaseContext(newContext) }

这段代码的逻辑是：拿到当前的Configuration对象，把fontScale改成1.0，然后用这个修改后的配置创建一个新的Context，交给Activity使用。这样，这个Activity里所有用SP标注的文字，都会按照1.0的缩放系数来渲染，不再受系统设置影响。

这个方案的优势很明显：一次编写，全局生效。你只需要把它放在BaseActivity里，所有继承自BaseActivity的页面都会自动应用。而且它不影响App内部自己的字体缩放逻辑——你仍然可以在App内部通过其他方式调整字体大小。

但它也有一个需要注意的地方：attachBaseContext的调用时机非常早，在Activity的onCreate之前。如果你在这个方法里做了太多耗时操作，会影响Activity的启动速度。所以这里的代码要尽量轻量，只做Configuration的修改就好。

3.2 方案二：在Application中全局配置

如果你想让整个App（包括Dialog、Toast等）都不跟随系统字体，可以在Application的onCreate中做全局配置。

override fun onCreate() { super.onCreate() val config = resources.configuration config.fontScale = 1.0f resources.updateConfiguration(config, resources.displayMetrics) }

但这里有一个坑：resources.updateConfiguration在Android 7.0之后被标记为deprecated，而且在某些厂商的ROM上行为不一致。更麻烦的是，它会影响整个进程的资源加载，如果处理不当，可能导致其他依赖系统字体的组件显示异常。

所以我的建议是：优先用方案一，方案二作为补充。方案一覆盖不到的角落（比如某些系统组件弹出的Dialog），再考虑用方案二兜底。但方案二一定要谨慎使用，测试要充分。

3.3 方案三：自定义TextView重写setTextSize

还有一种思路是自定义一个TextView，重写它的setTextSize方法，在里面把系统缩放系数除掉。

class FixedTextView(context: Context, attrs: AttributeSet?) : AppCompatTextView(context, attrs) { override fun setTextSize(unit: Int, size: Float) { val scaledSize = size / context.resources.configuration.fontScale super.setTextSize(unit, scaledSize) } }

这个方案的问题在于：你需要把项目里所有的TextView都替换成FixedTextView，包括XML布局里的和代码里动态创建的。工作量巨大，而且容易遗漏。更麻烦的是，很多第三方库内部的TextView你没法替换，它们仍然会跟随系统缩放。

所以这个方案只适合在特定场景下使用，比如某个自定义控件需要精确控制文字大小，不适合作为全局方案。

3.4 三种方案的对比与选型建议

选型的核心逻辑是：优先选择覆盖范围广、侵入性低的方案。BaseActivity覆写方案在这两个维度上都是最优的，所以作为首选。Application方案虽然覆盖范围更广，但兼容性风险更高，建议只在必要时使用。自定义TextView方案侵入性太强，除非有特殊需求，否则不建议。

4. 动态设置字体大小的正确姿势

4.1 为什么动态设置字体大小容易出问题

“不跟随系统字体”只是第一步。很多App还需要在内部提供字体大小调节功能，比如设置里有“小、中、大”三档。这时候就涉及到动态设置字体大小的问题。

动态设置字体大小的难点在于：你需要在运行时改变字体大小，并且让这个改变立即生效，同时还要保证改变后的布局不会错乱。这涉及到资源重新加载、界面刷新、状态保存等一系列问题。

我见过不少项目在这块踩坑，典型的表现是：用户调完字体大小后，部分页面生效了，部分页面没生效；或者生效了但布局错位；或者切换页面后又变回去了。这些问题背后的原因各不相同，但核心都是对Android资源加载机制理解不够深入。

4.2 基于Configuration的字体缩放方案

最正统的做法是：在App内部维护一个字体缩放系数，把它应用到Configuration的fontScale上，然后触发资源重新加载。

object FontScaleManager { private const val KEY_FONT_SCALE = "app_font_scale" private const val DEFAULT_SCALE = 1.0f fun getFontScale(context: Context): Float { return SharedPreferencesHelper.getFloat(context, KEY_FONT_SCALE, DEFAULT_SCALE) } fun setFontScale(context: Context, scale: Float) { SharedPreferencesHelper.putFloat(context, KEY_FONT_SCALE, scale) } fun applyFontScale(context: Context): Context { val scale = getFontScale(context) val config = Configuration(context.resources.configuration) config.fontScale = scale return context.createConfigurationContext(config) } }

然后在BaseActivity的attachBaseContext里，把系统缩放和App缩放结合起来：

override fun attachBaseContext(newBase: Context) { val config = Configuration(newBase.resources.configuration) // 先禁用系统缩放 config.fontScale = 1.0f val baseContext = newBase.createConfigurationContext(config) // 再应用App内部的缩放 val appContext = FontScaleManager.applyFontScale(baseContext) super.attachBaseContext(appContext) }

这样，系统字体缩放被禁用，App内部的字体缩放生效。用户在App设置里调整字体大小时，只需要更新SharedPreferences中的值，然后重启Activity（或者重建Activity）即可生效。

4.3 重启Activity的正确方式

调整字体大小后，需要让所有已打开的页面都重新加载资源。最直接的方式是重启Activity。

fun restartApp(activity: Activity) { val intent = activity.intent intent.addFlags(Intent.FLAG_ACTIVITY_NO_ANIMATION) activity.finish() activity.overridePendingTransition(0, 0) activity.startActivity(intent) }

但这里有几个坑要注意：

第一个坑是重启时的闪烁问题。如果直接finish再startActivity，用户会看到明显的闪烁。解决办法是加上FLAG_ACTIVITY_NO_ANIMATION，并且用overridePendingTransition(0, 0)去掉转场动画。

第二个坑是Activity栈的处理。如果用户已经打开了多个页面，只重启当前页面是不够的。更彻底的做法是清空Activity栈，重新启动首页。但这会影响用户体验，需要权衡。

第三个坑是状态保存。重启Activity会导致页面状态丢失，比如用户填了一半的表单。所以字体大小调整最好放在设置页面，调整后提示用户“字体大小将在下次打开时生效”，或者让用户手动确认重启。

实操心得：我在项目里采用的是“设置页调整 + 返回时重启”的方案。用户在设置页调整字体大小，返回上一页时触发重启。这样既保证了生效，又避免了在设置页频繁重启导致的闪烁。

4.4 不重启Activity的局部刷新方案

如果你不想重启Activity，也可以尝试局部刷新。核心思路是：遍历当前页面的所有View，重新设置它们的文字大小。

fun updateFontScale(view: View, scale: Float) { when (view) { is TextView -> { val originalSize = view.tag as? Float ?: view.textSize view.tag = originalSize view.setTextSize(TypedValue.COMPLEX_UNIT_PX, originalSize * scale) } is ViewGroup -> { for (i in 0 until view.childCount) { updateFontScale(view.getChildAt(i), scale) } } } }

这个方案的问题是：你需要保存每个TextView的原始文字大小，否则多次调整后会累积缩放。而且它只能处理当前页面的View，对于RecyclerView中未创建的Item无能为力。所以这个方案只适合在特定场景下使用，比如某个弹窗需要临时调整字体大小。

4.5 动态字体大小的边界处理

不管用哪种方案，都需要处理边界情况。比如：

• 字体缩放系数的取值范围要限制在合理区间，比如0.8到1.5之间。太小了看不清，太大了布局会崩。
• 调整字体大小后，要检查关键页面的布局是否正常。特别是那些文字较长、容器较窄的地方。
• 如果App支持多语言，不同语言的文字长度差异很大，字体缩放后可能表现不同。比如中文和英文在同样字号下占用的宽度不同，需要分别测试。

5. 那些年我踩过的字体适配坑

5.1 WebView的字体不跟随App设置

WebView是一个独立的渲染引擎，它不遵循Android的Configuration.fontScale设置。如果你在App里调整了字体大小，WebView里的内容不会跟着变。

解决办法是通过WebSettings注入CSS或者JavaScript来调整字体大小：

webView.settings.textZoom = (fontScale * 100).toInt()

textZoom属性控制WebView中文字的缩放比例，默认是100。把它设置成fontScale * 100，就能让WebView的文字跟随App的字体设置。

但这里还有一个坑：textZoom会影响页面布局。如果网页的宽度是固定的，文字放大后可能出现横向滚动条。所以最好在网页端也做响应式设计，或者用loadUrl时注入viewport meta标签。

5.2 Toast和Dialog的字体不受控

Toast和系统Dialog是由系统进程渲染的，它们不遵循App的Configuration设置。即使你在Application里改了fontScale，Toast的文字大小仍然跟随系统设置。

对于Toast，解决办法是自定义一个Toast布局，用App的字体设置来渲染。对于Dialog，建议使用AppCompatDialog或者自定义Dialog，避免使用系统原生Dialog。

fun showCustomToast(context: Context, message: String) { val toast = Toast(context) val view = LayoutInflater.from(context).inflate(R.layout.custom_toast, null) val textView = view.findViewById<TextView>(R.id.toast_text) textView.text = message textView.setTextSize(TypedValue.COMPLEX_UNIT_SP, 14f * FontScaleManager.getFontScale(context)) toast.view = view toast.duration = Toast.LENGTH_SHORT toast.show() }

5.3 第三方库的字体适配问题

很多第三方库（比如某些图表库、富文本编辑器）内部有自己的字体处理逻辑，可能不遵循App的字体设置。这时候你有两个选择：要么找到库的配置项，手动设置字体大小；要么在库的渲染完成后，遍历它的View树，强制修改文字大小。

后者虽然粗暴，但在紧急情况下是有效的。我遇到过一个图表库，它的坐标轴文字不跟随App字体设置，最后就是在图表渲染完成后，通过遍历View树找到对应的TextView，手动设置了文字大小。

5.4 字体缩放与深色模式的冲突

这是一个比较隐蔽的坑。当你在attachBaseContext里同时处理字体缩放和深色模式时，如果处理顺序不对，可能导致其中一个失效。

正确的顺序是：先处理深色模式，再处理字体缩放。因为深色模式会改变Configuration的uiMode属性，而字体缩放会改变fontScale属性，两者互不影响，但创建Context的顺序会影响最终生效的配置。

override fun attachBaseContext(newBase: Context) { var config = Configuration(newBase.resources.configuration) // 先处理深色模式 config.uiMode = if (isDarkMode) { (config.uiMode and Configuration.UI_MODE_NIGHT_MASK.inv()) or Configuration.UI_MODE_NIGHT_YES } else { (config.uiMode and Configuration.UI_MODE_NIGHT_MASK.inv()) or Configuration.UI_MODE_NIGHT_NO } var context = newBase.createConfigurationContext(config) // 再处理字体缩放 config = Configuration(context.resources.configuration) config.fontScale = FontScaleManager.getFontScale(context) context = context.createConfigurationContext(config) super.attachBaseContext(context) }

5.5 常见问题速查表

6. 字体适配的测试与验证方法

6.1 如何模拟不同的系统字体大小

在开发阶段，你不需要真的去系统设置里反复调整字体大小。可以通过ADB命令直接修改：

adb shell settings put system font_scale 1.3

执行后，系统会立即应用新的字体缩放系数。你可以用这个命令快速切换不同的缩放档位，验证App的表现。

如果要恢复默认值：

adb shell settings put system font_scale 1.0

这个方法的优势是快，而且可以精确控制缩放系数，不受系统设置档位的限制。我通常在开发阶段用这个命令做快速验证，在测试阶段再让测试同学用真实的系统设置来验证。

6.2 自动化测试中的字体适配验证

如果你有UI自动化测试，可以在测试用例中加入字体缩放的验证。核心思路是：在测试开始前通过ADB修改字体缩放系数，然后运行UI测试，检查关键页面的截图是否正常。

@Before fun setUp() { // 设置字体缩放为1.3 executeAdbCommand("settings put system font_scale 1.3") // 重启App activityRule.scenario.recreate() } @Test fun testHomePageWithLargeFont() { onView(withId(R.id.home_title)).check(matches(isDisplayed())) onView(withId(R.id.home_button)).check(matches(isCompletelyDisplayed())) }

这个方案的关键是在测试前重启App，确保新的字体缩放系数被应用。否则测试可能仍然使用旧的配置。

6.3 需要重点验证的页面类型

不是所有页面都需要同等程度的字体适配验证。根据我的经验，以下几类页面需要重点关注：

• 文字密集的列表页：比如商品列表、消息列表。文字放大后，列表项的高度可能不够，导致文字被截断。
• 表单页面：输入框的提示文字、标签文字放大后，可能超出容器宽度。
• 底部导航栏：导航项的文字放大后，可能换行或者被截断。
• 弹窗和对话框：这些通常有固定的宽度，文字放大后容易溢出。
• 自定义控件：比如进度条上的文字、图表上的标签，这些地方往往没有考虑字体缩放。

实操心得：我通常会在字体缩放1.3和1.5两个档位下，把上面这几类页面都过一遍。1.3是大多数系统的最大档，1.5是极端情况。如果1.5下布局还能接受，那基本就没问题了。

7. 一套完整的字体适配方案落地记录

7.1 项目背景与需求

我最近参与的一个项目是一个电商类App，用户群体中有相当比例的中老年用户。产品经理提了一个需求：App内部提供字体大小调节功能，同时不允许跟随系统字体大小，以保证界面布局的稳定性。

需求拆解下来有几点：

• 系统字体缩放不影响App界面
• App内部提供“标准、大、超大”三档字体设置
• 字体调整后，所有页面立即生效
• 关键页面在最大字体下布局不能错乱

7.2 方案设计与代码结构

最终的方案是：BaseActivity + FontScaleManager + 重启机制。

FontScaleManager负责管理App内部的字体缩放系数，提供读写接口。BaseActivity在attachBaseContext中先禁用系统缩放，再应用App缩放。设置页面调整字体后，通过重启Activity让新配置生效。

// FontScaleManager.kt object FontScaleManager { private const val KEY_FONT_SCALE = "app_font_scale" const val SCALE_SMALL = 0.9f const val SCALE_NORMAL = 1.0f const val SCALE_LARGE = 1.15f const val SCALE_EXTRA_LARGE = 1.3f fun getFontScale(context: Context): Float { val sp = context.getSharedPreferences("app_settings", Context.MODE_PRIVATE) return sp.getFloat(KEY_FONT_SCALE, SCALE_NORMAL) } fun setFontScale(context: Context, scale: Float) { val sp = context.getSharedPreferences("app_settings", Context.MODE_PRIVATE) sp.edit().putFloat(KEY_FONT_SCALE, scale).apply() } }

// BaseActivity.kt abstract class BaseActivity : AppCompatActivity() { override fun attachBaseContext(newBase: Context) { val config = Configuration(newBase.resources.configuration) config.fontScale = 1.0f val baseContext = newBase.createConfigurationContext(config) val appConfig = Configuration(baseContext.resources.configuration) appConfig.fontScale = FontScaleManager.getFontScale(baseContext) val finalContext = baseContext.createConfigurationContext(appConfig) super.attachBaseContext(finalContext) } }

7.3 设置页面的实现细节

设置页面的字体选择用RadioGroup实现，选中后立即保存并重启。

radioGroup.setOnCheckedChangeListener { _, checkedId -> val scale = when (checkedId) { R.id.scale_small -> FontScaleManager.SCALE_SMALL R.id.scale_normal -> FontScaleManager.SCALE_NORMAL R.id.scale_large -> FontScaleManager.SCALE_LARGE R.id.scale_extra_large -> FontScaleManager.SCALE_EXTRA_LARGE else -> FontScaleManager.SCALE_NORMAL } FontScaleManager.setFontScale(this, scale) // 延迟一点重启，让用户看到选中效果 window.decorView.postDelayed({ restartApp() }, 200) }

这里延迟200毫秒是为了让用户看到RadioButton的选中动画，避免点击后立即重启导致的突兀感。

7.4 布局文件的适配要点

字体缩放后，布局能否正常显示，很大程度上取决于布局文件怎么写。以下是我总结的几个要点：

• 避免固定高度：TextView的高度尽量用wrap_content，如果必须固定，用minHeight代替height。
• 避免单行显示：除非确定文字不会太长，否则不要设置android:singleLine="true"或android:maxLines="1"。
• 使用ConstraintLayout：ConstraintLayout的约束机制比LinearLayout更灵活，文字放大后不容易撑破布局。
• 留足间距：文字和容器边缘之间留足够的padding，给字体放大留出空间。
• 测试长文本：用最长的文案来测试，比如“超大字体设置下的长文本显示效果”。

7.5 上线后的效果与反馈

方案上线后，字体相关的bug数量明显下降。之前每个月都有几个关于字体显示的反馈，上线后基本没有了。用户对App内字体调节功能的评价也不错，特别是中老年用户，反馈说“终于能看清了”。

不过也收到了一些反馈，主要是关于字体调整后需要重启的问题。有用户觉得重启有点突兀，希望能无缝切换。这个我们后续考虑用局部刷新的方案来优化，但优先级不高，因为字体调整本身是一个低频操作。

8. 关于字体适配的一些个人体会

字体适配这件事，说大不大，说小不小。它不像性能优化那样有明确的指标，也不像新功能那样有可见的产出，但它直接影响用户体验。一个字体适配没做好的App，在用户眼里就是“粗糙”、“不专业”。

我在实际项目中的体会是：字体适配要趁早做。如果项目初期没有考虑这个问题，等到后期再补，工作量会大很多。因为你需要检查所有页面的布局，修改所有可能出问题的TextView，还要处理各种第三方库的兼容问题。而如果在项目初期就把BaseActivity和FontScaleManager搭好，后续的开发只需要遵循一些布局规范，成本很低。

另一个体会是：不要试图用一套方案解决所有问题。BaseActivity方案能覆盖大部分场景，但WebView、Toast、系统Dialog这些角落需要单独处理。与其追求一个完美的全局方案，不如接受“主方案+补丁”的组合，把每个场景都处理好。

最后说一个容易被忽略的点：字体适配不只是技术问题，也是设计问题。如果设计师在出图时没有考虑字体放大的情况，开发者再怎么适配也是事倍功半。所以最好在项目初期就和设计师沟通好，哪些地方需要留出字体放大的空间，哪些地方可以用固定字号。技术和设计配合，才能做出真正好用的字体适配方案。