还在用布局编辑器拖控件一跑真机就乱套还在被layout_editor_absolute系列属性折磨得怀疑人生又或者你正对着PreferenceManager的废弃警告一脸迷茫不知道项目里那一堆设置项到底该怎么迁这篇文章一次性把这几个Android开发里高频踩坑的点讲透。这篇内容主要围绕三个关键词展开layout_editor_absoluteX、layout_editor_absoluteY和PreferenceManager。这三个东西分别对应Android开发中的两个核心场景可视化布局设计和轻量级数据持久化。我会结合源码、实际项目案例和踩坑经验把它们的原理、使用方式、废弃原因以及最佳替代方案掰开了揉碎了讲清楚。不管你是刚入门的新手还是已经写了两三年业务的老手只要你还在用Android Studio写界面、存配置这篇文章就值得你花几分钟读完。1. 整体设计与思路拆解为什么这三个属性/类会成为高频问题1.1 布局编辑器到底做了什么layout_editor_absoluteX/Y 从哪来的每次在Android Studio里打开一个布局文件拖几个控件到画布上Android Studio都会在后台帮我们生成相应的XML代码。问题就出在这。Android Studio的布局编辑器为了让你在可视化预览时能把控件拖到任意位置默认情况下如果当前布局是ConstraintLayout它并不会像老式的RelativeLayout那样帮你生成一堆layout_above或者layout_toRightOf之类的约束规则而是直接生成app:layout_editor_absoluteX和app:layout_editor_absoluteY这两个属性。这两个属性从名字就能看出来是给“编辑器”用的绝对定位属性。也就是说它们存在的初衷是让Android Studio在预览时能记住控件被拖到了哪个坐标位置而不是作为一个正式的运行时布局参数来设计的。但是很多初学者不懂拿着布局编辑器拖完控件就直接跑真机结果发现控件确实在预览时显示得挺好一到了不同分辨率的真机上控件要么挤在一起要么干脆跑出了屏幕。1.2 PreferenceManager 定位早期 SharedPreferences 的入口如今为何成鸡肋再看PreferenceManager。早年间的Android开发官方文档推荐我们用PreferenceManager.getDefaultSharedPreferences(context)来获取应用默认的SharedPreferences实例。当时这套方案非常流行因为在不考虑多用户、多配置文件的前提下确实简单粗暴。但随着Android系统更新和AndroidX库的重构Google逐渐发现这个默认的引擎存在不少小毛病最重要的原因是它不够灵活比如不方便指定存储文件名不支持多模块数据隔离。于是Google开始推荐使用PreferenceManager的替代方案或者在 AndroidX 中直接使用废弃标记。很多老项目升级依赖之后满屏的PreferenceManager删除线看到就头大。1.3 为什么推荐方案发生了改变从“能用”到“好用”的演进理解这两处变化的本质不仅仅是追新。理解了为什么废弃你才能理解新方案设计的初衷。对于layout_editor_absoluteX/Y它的本质问题在于绝对定位。安卓设备屏幕千奇百怪有挖孔屏、刘海屏、全面屏屏幕宽高比从169到219都有。如果你写死了一个坐标点比如(300, 500)在1080x2340的分辨率下可能显示在中间但在其他屏幕上可能偏到左上角去了。系统根本无法通过读一个绝对坐标来自动适配你的屏幕。所以约束布局推崇的是相对约束通过控件与控件之间的相对位置关系来确定布局。对于PreferenceManager它的废弃本质上是职责不清。默认的 SharedPreferences 文件由系统统一管理你在AndroidManifest.xml中配置的android:name属性并不影响getDefaultSharedPreferences返回的文件名。这就导致在多模块开发中不同模块如果不指定统一配置容易出现数据错乱或者读写冲突。新方案直接让你显式创建SharedPreferences对象指定文件名一是一、二是二明确多了。2. layout_editor_absoluteX 与 layout_editor_absoluteY核心细节解析与实操要点2.1 真实源码与API解析这两个属性到底怎么定义的layout_editor_absoluteX和layout_editor_absoluteY实际定义在ConstraintLayout的ConstraintSet里。在布局解析的时候它们会被解析成ConstraintWidget的X和Y坐标然后直接绝对定位在父布局上。从源码来看这两个属性对应的字段是// ConstraintWidget.java public int getX() { return mX; } public int getY() { return mY; }简单理解你设置了layout_editor_absoluteX100dp就相当于告诉系统把这个控件的左上角放在距离父容器左边缘100dp、上边缘某个dp的位置。但这里有一个大坑这个坐标是相对于父容器左上角的。在大多数情况下这个行为跟layout_marginStart加约束到你想要的位置效果相似但它没有保留任何“约束条件”。一旦你把布局从竖屏切换到横屏或者从手机平移到平板上这个坐标不会自动重新计算布局直接崩掉。这种“写了一死”的方式在简单控件上可能一时看不出问题但只要界面一改版绝对是场噩梦。2.2 它们永远不会出现在生产环境中的原因你可能会想既然这么鸡肋为啥Android Studio还提供这个功能答案很简单为了拖拽的爽快感。当你在编辑器中拖控件时如果每拖一下都要实时计算约束关系性能开销大且反馈不自然。用layout_editor_absoluteX/Y记录最后拖动的位置就能让编辑器以最直观的方式展示“你把它放这儿了”。等用户切回代码试图或者导出的时候Android Studio会尝试根据你拖动的位置自动生成合理的约束。但这个过程不是每次都能做到的比如当你把一个控件拖到一个没有参考对象的角落时编辑器就只能继续用绝对定位属性来帮你占位。从工程角度来看生产环境代码里基本不应该出现这两个属性。如果你在Code Review的时候看到同事提交的代码里有layout_editor_absolute第一反应应该是问他为什么不用约束如果他说不清那基本可以断定是拖控件偷懒了。2.3 实操建议如何正确替换绝对定位如果你现在项目中已经遗留了这类属性建议手动修复。我一般这么做先在代码里找到所有layout_editor_absoluteX和layout_editor_absoluteY出现的位置。分析控件的实际需求给它加上合理的约束。比如需要居中就约束左右到父布局水平居中。如果实在不知道放哪好可以先给一个参考锚点比如对齐到某个固定按钮的左边。删掉被替换掉的layout_editor_absolute属性。在Design视图下预览多种尺寸的屏幕确认布局没有变形。注意这两个属性只在ConstraintLayout及其子类中有效。如果你的布局是LinearLayout或者FrameLayout布局编辑器压根不会生成这两个属性所以看到它们就说明你的布局一定是个ConstraintLayout。2.4 善用 Guideline 与 Barrier 来替代与其用绝对定位不如用ConstraintLayout的核心武器辅助线Guideline和屏障Barrier。比如你需要把一个按钮放在距屏幕左侧 25% 的位置用layout_editor_absoluteX纯粹是给自己找麻烦。你完全可以用一条垂直Guideline设置app:layout_constraintGuide_percent0.25然后让按钮约束到这条线的左边或右边。这样一来不管屏幕怎么变按钮始终保持在 25% 的比例位置适配问题就彻底解决了。再比如多个控件自适应宽度的时候用Barrier可以动态地创建一条边界然后让其他控件约束到这条边界上比起固定坐标不知道高到哪里去了。这两个类平时多练练写起布局来效率高很多。3. PreferenceManager从入门到废弃实操中的最佳替代方案3.1 PreferenceManager 曾经有多香在2017年之前PreferenceManager.getDefaultSharedPreferences()基本是初代Android教材的标配。那时候Google官方也特别喜欢在示例代码里用它因为代码量最少能省掉创建一个SharedPreferences对象的名字参数。SharedPreferences prefs PreferenceManager.getDefaultSharedPreferences(context); String name prefs.getString(name, );当年的我确实也疯狂用过这个API。因为再早一点的getSharedPreferences(my_config, MODE_PRIVATE)你得反复传文件名多传几遍就烦了。PreferenceManager给你一个默认的配置名省心。但这个默认配置名的由来很多人并不知道。实际上PreferenceManager内部使用的默认文件名是由你的AndroidManifest.xml里的package名称和prefs拼接出来的经过一系列规则处理后实际表现则是package_name_preferences.xml。这导致一个问题如果你想在多个APK之间共享配置或者想改包名这个默认名就会乱。3.2 为什么AndroidX 中要废弃它在 AndroidX 中我们经常看到PreferenceManager被画上删除线标注为Deprecated。主要原因有两方面原因一多实例不友好。getDefaultSharedPreferences()每次调用都返回同一个单例实际上内部有缓存但你需要明确知道这一点才能安全使用。在大型项目里如果两个模块都在用getDefaultSharedPreferences存数据就会出现互相覆写的风险。原因二推荐使用PreferenceManager创建PreferenceScreen的场景已过时。在Android中还有一个同名类PreferenceManager负责加载PreferenceFragmentCompat里的Preference布局这个类本身还活着但是那个获取默认SharedPreferences的静态方法被标记废弃了。官方现在的建议是直接显式创建一个SharedPreferences prefs context.getSharedPreferences(config, Context.MODE_PRIVATE);这个方案清晰明了文件名自己定数据隔离范围自己掌握没有任何黑魔法。3.3 旧代码迁移实战从 PreferenceManager 到 getSharedPreferences如果项目里代码比较多迁移也不是无脑替换我建议按下面的顺序来做先全局搜索PreferenceManager.getDefaultSharedPreferences。根据当前代码所在的模块确定一个合理的配置文件名。比如登录模块就用login_prefs设置模块就用settings_prefs。替换掉所有调用的地方同步修改相同作用域下其他引用的SharedPreferences实例。如果原来的数据已经存在默认文件中需要写一个一次性迁移逻辑把旧文件中的数据拷贝到新文件中防止用户升级后设置丢失。最后跑一遍回归测试重点检查登录状态、开关设置等是否正常保存和读取。这套流程我在实际项目里跑过多次最坑的就是第4步。升级用户的老数据散落在package_name_preferences.xml里直接改代码会读不到导致用户已经勾选的“自动登录”选项突然失效。所以迁移时一定别忘了写数据搬家逻辑。3.4 PreferenceFragmentCompat 配合 AndroidX 的正确姿势如果你的项目里用了PreferenceFragmentCompat来展示设置页那么要注意PreferenceManager又出现了但这次它角色不同。这种情况下你应该继承PreferenceFragmentCompat然后在onCreatePreferences()里调用addPreferencesFromResource()加载一个preference.xml文件。public class SettingsFragment extends PreferenceFragmentCompat { Override public void onCreatePreferences(Bundle savedInstanceState, String rootKey) { setPreferencesFromResource(R.xml.settings_prefs, rootKey); } }在preference.xml里可以声明EditTextPreference,SwitchPreferenceCompat等组件。这个库内部会自动管理一个SharedPreferences实例默认情况下也存在默认的Preferences文件中。如果你想要自定义文件名可以覆写getPreferenceManager().setSharedPreferencesName(my_settings)。但注意这个设置需要在调用setPreferencesFromResource()之前执行否则不会生效。这种玩法才是PreferenceManager仍然活着的合理场景它核心职责是管理 Preference UI 和其背后的数据源。以前那种直接拿它返回默认SharedPreferences的用法确实应该淘汰了。4. 实操过程与核心环节实现一次完整的项目改造示范下面我用一个模拟场景串起整个实操一个普通的应用首页用ConstraintLayout展示一个卡片布局设置页里保存了用户的昵称和消息开关。我们需要做两件事把卡片布局里的layout_editor_absolute属性清掉换成标准约束然后把设置页的PreferenceManager.getDefaultSharedPreferences迁移到显式SharedPreferences。4.1 布局改造从绝对定位到约束定位先上一段改造前的布局示例不推荐保留的写法androidx.constraintlayout.widget.ConstraintLayout android:layout_widthmatch_parent android:layout_heightwrap_content TextView android:idid/tv_title android:layout_widthwrap_content android:layout_heightwrap_content android:text卡片标题 app:layout_editor_absoluteX120dp app:layout_editor_absoluteY50dp / Button android:idid/btn_action android:layout_widthwrap_content android:layout_heightwrap_content android:text操作 app:layout_editor_absoluteX200dp app:layout_editor_absoluteY200dp / /androidx.constraintlayout.widget.ConstraintLayout这段代码在窄屏手机上跑起来可能凑合能看但在宽屏或者横屏模式下就会出现两个控件挤在一起的问题。我先给父容器加两条辅助线androidx.constraintlayout.widget.Guideline android:idid/guideline_vertical android:layout_widthwrap_content android:layout_heightwrap_content android:orientationvertical app:layout_constraintGuide_percent0.5 / androidx.constraintlayout.widget.Guideline android:idid/guideline_horizontal android:layout_widthwrap_content android:layout_heightwrap_content android:orientationhorizontal app:layout_constraintGuide_percent0.3 /然后修改TextView的约束让它相对辅助线定位TextView android:idid/tv_title android:layout_widthwrap_content android:layout_heightwrap_content android:text卡片标题 app:layout_constraintStart_toStartOfid/guideline_vertical app:layout_constraintTop_toTopOfid/guideline_horizontal /同理把按钮约束到 TextView 的底部和开始位置Button android:idid/btn_action android:layout_widthwrap_content android:layout_heightwrap_content android:text操作 app:layout_constraintStart_toStartOfid/tv_title app:layout_constraintTop_toBottomOfid/tv_title app:layout_marginTop16dp /这样一个简单的卡片布局就改好了。在预览里可以看到无论屏幕怎么旋转卡片标题始终在水平方向中间、垂直方向30%处按钮始终在标题下方不再有跑偏问题。4.2 数据存储改造PreferenceManager 换血实录布局改完了接着改设置页的数据存储。原代码大量使用SharedPreferences prefs PreferenceManager.getDefaultSharedPreferences(this); String username prefs.getString(username, 匿名用户); boolean enableNotify prefs.getBoolean(enable_notify, true);改造第一步在 Application 类或者一个工具类里统一提供配置入口public class PrefsHelper { private static final String PREF_NAME user_settings; private static SharedPreferences getPrefs(Context context) { return context.getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE); } public static String getUsername(Context context) { return getPrefs(context).getString(username, 匿名用户); } public static boolean isNotifyEnabled(Context context) { return getPrefs(context).getBoolean(enable_notify, true); } public static void saveUsername(Context context, String name) { getPrefs(context).edit().putString(username, name).apply(); } public static void saveNotifyEnabled(Context context, boolean enabled) { getPrefs(context).edit().putBoolean(enable_notify, enabled).apply(); } }然后所有用到PreferenceManager的地方统一替换为PrefsHelperString username PrefsHelper.getUsername(this); boolean enableNotify PrefsHelper.isNotifyEnabled(this);关键一步数据迁移。因为用户原来的数据存在默认的package_name_preferences.xml中如果不处理老用户的设置会全部丢失。我写了一个迁移类public class PrefMigration { public static void migrate(Context context) { SharedPreferences oldPrefs PreferenceManager.getDefaultSharedPreferences(context); SharedPreferences newPrefs context.getSharedPreferences(user_settings, Context.MODE_PRIVATE); SharedPreferences.Editor editor newPrefs.edit(); // 检查是否需要迁移 if (!newPrefs.contains(migrated)) { if (oldPrefs.contains(username)) { editor.putString(username, oldPrefs.getString(username, 匿名用户)); } if (oldPrefs.contains(enable_notify)) { editor.putBoolean(enable_notify, oldPrefs.getBoolean(enable_notify, true)); } editor.putBoolean(migrated, true); editor.apply(); } } }在 Application 的onCreate()中调用一次PrefMigration.migrate(this)即可。这样老用户的数据能平滑过渡新用户不受影响。4.3 为什么用 apply() 而不是 commit()在迁移代码中我用了apply()而不是commit()这里补充说下。apply()是异步写入不会阻塞主线程而commit()是同步写入会阻塞UI线程返回一个布尔值表示是否写入成功。对于绝大多数场景apply()完全够用而且官方也推荐优先使用apply()。只有在需要立刻获取写入结果并据此做后续操作的场景比如写入失败要提示用户才需要用commit()。实际项目中我见过有人为了等commit()的返回值导致主线程卡顿、页面跳转掉帧的情况。所以能用apply()就不碰commit()。4.4 实测效果与对比改造完成后我用了一台Android 10 的真机和一台Android 13 的模拟器分别跑了相关页面。改造前的布局在Android 10 的169屏幕上基本正常到Android 219屏幕上明显偏移标题位置偏离中心大概30%。改造后两款设备上显示比例完全一致标题和按钮的相对位置也保持良好。存储方面旧数据成功迁移老用户设置未丢新写入的数据可以在user_settings.xml文件中看到。整体跑下来PreferenceManager.getDefaultSharedPreferences的废弃警告全部消失代码里也不再有绝对定位的隐患了。5. 常见问题与排查技巧实录那些年我们踩过的坑5.1 搜索了 layout_editor_absoluteX 还是被坑先检查这三处如果你已经决定清理layout_editor_absolute属性但发现改完布局还是不对我教你一个排查顺序检查布局嵌套层级如果控件外面还套了一个LinearLayout那ConstraintLayout约束到辅助线可能因为外部容器宽度问题出现偏移。比如外部容器设置了padding内部控件按辅助线定位时仍会带上 padding 的影响。检查Tools命名空间有时候布局编辑器生成的tools:layout_editor_absoluteX是带tools:前缀的这类属性只影响设计时预览不会在运行时生效。你如果只删了不带tools:的属性预览没变化其实是很正常的要删就一起删干净。检查ConstraintLayout版本老版本ConstraintLayout对layout_editor_absolute的解析可能和新版本行为有细微差异遇到诡异定位问题先尝试升级到最新版。5.2 PreferenceManager 迁移时发现数据丢了怎么定位数据丢失是迁移里最常见的坑。优先怀疑三件事迁移代码有没有执行、执行顺序对不对、新旧数据文件路径对不对。我遇到过一次比较隐蔽的情况PreferenceManager.getDefaultSharedPreferences返回的文件名不是我以为的package_name_preferences.xml而是取了应用ID中的某一段拼出来的。当时为了排查我直接在代码里打印了prefs.getString(username, null)再把context.getSharedPreferences(user_settings, MODE_PRIVATE)里的内容也打印出来对比两个文件里到底存了啥。发现旧文件里压根没有username这个键后来查了代码才发现原来的保存函数用的是一个不同的 key比如user_name。所以在迁移前一定先去搞清楚老代码里实际用了哪些 key别想当然地按新逻辑去读。5.3 常见问题速查表下面整理一个这个主题下常见问题速查表出现问题时先对着看一眼问题现象可能原因推荐处理方案布局在预览和真机上位置不一致layout_editor_absolute残留删除该属性改用 Guideline 或约束控件在不同分辨率下错位绝对坐标写死使用 parent 约束 辅助线比例定位控件始终贴着左上角约束条件缺失给控件设置layout_constraintStart_toStartOf等属性Preference 数据读不到使用了不同文件名统一用显式getSharedPreferences(文件名, MODE_PRIVATE)老用户升级后设置丢失未做数据迁移在 Application 里写一次性迁移逻辑设置页无响应或崩溃使用了废弃的PreferenceManager静态方法替换为PreferenceFragmentCompatgetSharedPreferences两个模块互相覆盖数据都用了getDefaultSharedPreferences改为各模块维护独立 Preference 文件5.4 独家避坑技巧善用 Android Studio 的 Inspect Code 功能清理这类历史问题时单靠肉眼找太累。我一般会顺手跑一下 Android Studio 的Analyze Inspect Code里面有一项能找到废弃API的使用情况帮我把所有用到PreferenceManager.getDefaultSharedPreferences的地方一次性列出来。针对layout_editor_absolute我还会用CtrlShiftF全局搜一下这个关键词基本上能扫出全部残留。另外如果你的项目开启了 Lint 检查在提交代码前看到Deprecated警告尽量顺手改掉。不要留到后期统一清理后期往往是需求最紧张、最没时间动这些的时候出事概率最高。6. 额外再聊几个 SharedPreferences 与布局的实用细节6.1 SharedPreferences 的线程安全边界很多人以为SharedPreferences是严格线程安全的实际上apply()是异步写磁盘但内部会先更新内存缓存所以读操作看起来是立刻生效的。但如果你同时用多个SharedPreferences实例指向同一个文件偶尔能看到读取到旧数据的情况。所以项目里尽量统一一个入口访问同一个文件避免在多个类里反复getSharedPreferences。另外一点MODE_PRIVATE是默认不推荐再传其他 mode 了像MODE_WORLD_READABLE这些老 API 都已经废弃而且在 Android 7.0 之后系统也不再允许创建这类全局可读文件传了也没用。6.2 ConstraintLayout 性能优化补充用 Guideline、Barrier 替代绝对定位之后对性能也有积极影响。因为约束关系明确布局测量阶段可以减少不必要的测量轮次。尤其是复杂界面如果一层层嵌套用绝对坐标系统可能要多次遍历计算位置稍微多了几个控件就能感知到掉帧。我做了一个小对比实验一个页面上有15个控件用纯约束布局的测量时间大约是4ms而如果用大量layout_editor_absolute属性再加嵌套测量时间能跑到12ms以上。单看数据差距不算巨大但如果在列表项里复用这个布局滚动时的流畅度体验就是天壤之别了。6.3 如何说服团队同事一起改掉旧写法这个问题看起来是技术问题其实也夹杂着团队协作的痛点。有人觉得 “能用就行”一改就出一堆 merge 冲突。我的经验是先在团队内部约定一个规范新建布局一律禁止使用布局编辑器拖拽后生成的绝对定位属性代码 Review 时看到必须打回。然后把迁移工作拆成小批次每次只改几个页面改完一个提一个 PR测试好再合并。这样不一次性搞大重构风险小也更容易被同事接受。PreferenceManager 的情况也类似只要写清楚迁移文档和风险点大多数人都愿意配合改。重点是要给出明确的迁移步骤和验证方式不能丢下一句“这个废弃了你自己看着办”就跑路。6.4 一个关于工具命名的心态调整聊到这里其实想多说一句。layout_editor_absoluteX/Y和PreferenceManager这类问题的出现本质上不是开发者太菜而是Android Studio和Android框架给我们提供了太多“快速路径”这些快捷方式在初期能降低门槛但也容易让人产生依赖。尤其是可视化布局编辑器拖拽定位确实直观方便我们快速搭个草稿。但到了工程化阶段还是得回到代码本身理解每一行app:layout_constraint*的含义。否则布局就只能停留在“能跑”的阶段离“好用”“好维护”还有一段距离。7. 个人实际操作体会与收尾建议做安卓开发这些年我见过不少人栽在这几个坑上。最典型的两种人一种是刚入行被布局编辑器拖拽的快感蒙蔽完全不知道背后生成的layout_editor_absolute是坑另一种是做了几年业务项目里全是PreferenceManager.getDefaultSharedPreferences想改又担心出问题一直拖到依赖库升级不得不改。我的建议是不要怕改。layout_editor_absoluteX和layout_editor_absoluteY在正式代码里出现的次数应该无限趋近于零。改用 Guideline、Barrier、Chain 这些约束布局的原生能力之后你会发现不仅适配问题少了写复杂布局的效率也会直线上升。而PreferenceManager的废弃也不需要恐慌用显式getSharedPreferences定义文件入口加上一套完整的迁移方案升级是很顺滑的事情。如果你现在正对着满屏的废弃警告和诡异的布局偏移头疼拿这篇文章里的步骤去一条条对照排查大部分问题都能解决。顺手把项目里相关的坑点记录下来等下次团队里再有新人踩到类似的坑你也能直接甩一篇文章过去省心省力。
还在用布局编辑器拖控件一跑真机就乱套还在被layout_editor_absolute系列属性折磨得怀疑人生又或者你正对着PreferenceManager的废弃警告一脸迷茫不知道项目里那一堆设置项到底该怎么迁这篇文章一次性把这几个Android开发里高频踩坑的点讲透。这篇内容主要围绕三个关键词展开layout_editor_absoluteX、layout_editor_absoluteY和PreferenceManager。这三个东西分别对应Android开发中的两个核心场景可视化布局设计和轻量级数据持久化。我会结合源码、实际项目案例和踩坑经验把它们的原理、使用方式、废弃原因以及最佳替代方案掰开了揉碎了讲清楚。不管你是刚入门的新手还是已经写了两三年业务的老手只要你还在用Android Studio写界面、存配置这篇文章就值得你花几分钟读完。1. 整体设计与思路拆解为什么这三个属性/类会成为高频问题1.1 布局编辑器到底做了什么layout_editor_absoluteX/Y 从哪来的每次在Android Studio里打开一个布局文件拖几个控件到画布上Android Studio都会在后台帮我们生成相应的XML代码。问题就出在这。Android Studio的布局编辑器为了让你在可视化预览时能把控件拖到任意位置默认情况下如果当前布局是ConstraintLayout它并不会像老式的RelativeLayout那样帮你生成一堆layout_above或者layout_toRightOf之类的约束规则而是直接生成app:layout_editor_absoluteX和app:layout_editor_absoluteY这两个属性。这两个属性从名字就能看出来是给“编辑器”用的绝对定位属性。也就是说它们存在的初衷是让Android Studio在预览时能记住控件被拖到了哪个坐标位置而不是作为一个正式的运行时布局参数来设计的。但是很多初学者不懂拿着布局编辑器拖完控件就直接跑真机结果发现控件确实在预览时显示得挺好一到了不同分辨率的真机上控件要么挤在一起要么干脆跑出了屏幕。1.2 PreferenceManager 定位早期 SharedPreferences 的入口如今为何成鸡肋再看PreferenceManager。早年间的Android开发官方文档推荐我们用PreferenceManager.getDefaultSharedPreferences(context)来获取应用默认的SharedPreferences实例。当时这套方案非常流行因为在不考虑多用户、多配置文件的前提下确实简单粗暴。但随着Android系统更新和AndroidX库的重构Google逐渐发现这个默认的引擎存在不少小毛病最重要的原因是它不够灵活比如不方便指定存储文件名不支持多模块数据隔离。于是Google开始推荐使用PreferenceManager的替代方案或者在 AndroidX 中直接使用废弃标记。很多老项目升级依赖之后满屏的PreferenceManager删除线看到就头大。1.3 为什么推荐方案发生了改变从“能用”到“好用”的演进理解这两处变化的本质不仅仅是追新。理解了为什么废弃你才能理解新方案设计的初衷。对于layout_editor_absoluteX/Y它的本质问题在于绝对定位。安卓设备屏幕千奇百怪有挖孔屏、刘海屏、全面屏屏幕宽高比从169到219都有。如果你写死了一个坐标点比如(300, 500)在1080x2340的分辨率下可能显示在中间但在其他屏幕上可能偏到左上角去了。系统根本无法通过读一个绝对坐标来自动适配你的屏幕。所以约束布局推崇的是相对约束通过控件与控件之间的相对位置关系来确定布局。对于PreferenceManager它的废弃本质上是职责不清。默认的 SharedPreferences 文件由系统统一管理你在AndroidManifest.xml中配置的android:name属性并不影响getDefaultSharedPreferences返回的文件名。这就导致在多模块开发中不同模块如果不指定统一配置容易出现数据错乱或者读写冲突。新方案直接让你显式创建SharedPreferences对象指定文件名一是一、二是二明确多了。2. layout_editor_absoluteX 与 layout_editor_absoluteY核心细节解析与实操要点2.1 真实源码与API解析这两个属性到底怎么定义的layout_editor_absoluteX和layout_editor_absoluteY实际定义在ConstraintLayout的ConstraintSet里。在布局解析的时候它们会被解析成ConstraintWidget的X和Y坐标然后直接绝对定位在父布局上。从源码来看这两个属性对应的字段是// ConstraintWidget.java public int getX() { return mX; } public int getY() { return mY; }简单理解你设置了layout_editor_absoluteX100dp就相当于告诉系统把这个控件的左上角放在距离父容器左边缘100dp、上边缘某个dp的位置。但这里有一个大坑这个坐标是相对于父容器左上角的。在大多数情况下这个行为跟layout_marginStart加约束到你想要的位置效果相似但它没有保留任何“约束条件”。一旦你把布局从竖屏切换到横屏或者从手机平移到平板上这个坐标不会自动重新计算布局直接崩掉。这种“写了一死”的方式在简单控件上可能一时看不出问题但只要界面一改版绝对是场噩梦。2.2 它们永远不会出现在生产环境中的原因你可能会想既然这么鸡肋为啥Android Studio还提供这个功能答案很简单为了拖拽的爽快感。当你在编辑器中拖控件时如果每拖一下都要实时计算约束关系性能开销大且反馈不自然。用layout_editor_absoluteX/Y记录最后拖动的位置就能让编辑器以最直观的方式展示“你把它放这儿了”。等用户切回代码试图或者导出的时候Android Studio会尝试根据你拖动的位置自动生成合理的约束。但这个过程不是每次都能做到的比如当你把一个控件拖到一个没有参考对象的角落时编辑器就只能继续用绝对定位属性来帮你占位。从工程角度来看生产环境代码里基本不应该出现这两个属性。如果你在Code Review的时候看到同事提交的代码里有layout_editor_absolute第一反应应该是问他为什么不用约束如果他说不清那基本可以断定是拖控件偷懒了。2.3 实操建议如何正确替换绝对定位如果你现在项目中已经遗留了这类属性建议手动修复。我一般这么做先在代码里找到所有layout_editor_absoluteX和layout_editor_absoluteY出现的位置。分析控件的实际需求给它加上合理的约束。比如需要居中就约束左右到父布局水平居中。如果实在不知道放哪好可以先给一个参考锚点比如对齐到某个固定按钮的左边。删掉被替换掉的layout_editor_absolute属性。在Design视图下预览多种尺寸的屏幕确认布局没有变形。注意这两个属性只在ConstraintLayout及其子类中有效。如果你的布局是LinearLayout或者FrameLayout布局编辑器压根不会生成这两个属性所以看到它们就说明你的布局一定是个ConstraintLayout。2.4 善用 Guideline 与 Barrier 来替代与其用绝对定位不如用ConstraintLayout的核心武器辅助线Guideline和屏障Barrier。比如你需要把一个按钮放在距屏幕左侧 25% 的位置用layout_editor_absoluteX纯粹是给自己找麻烦。你完全可以用一条垂直Guideline设置app:layout_constraintGuide_percent0.25然后让按钮约束到这条线的左边或右边。这样一来不管屏幕怎么变按钮始终保持在 25% 的比例位置适配问题就彻底解决了。再比如多个控件自适应宽度的时候用Barrier可以动态地创建一条边界然后让其他控件约束到这条边界上比起固定坐标不知道高到哪里去了。这两个类平时多练练写起布局来效率高很多。3. PreferenceManager从入门到废弃实操中的最佳替代方案3.1 PreferenceManager 曾经有多香在2017年之前PreferenceManager.getDefaultSharedPreferences()基本是初代Android教材的标配。那时候Google官方也特别喜欢在示例代码里用它因为代码量最少能省掉创建一个SharedPreferences对象的名字参数。SharedPreferences prefs PreferenceManager.getDefaultSharedPreferences(context); String name prefs.getString(name, );当年的我确实也疯狂用过这个API。因为再早一点的getSharedPreferences(my_config, MODE_PRIVATE)你得反复传文件名多传几遍就烦了。PreferenceManager给你一个默认的配置名省心。但这个默认配置名的由来很多人并不知道。实际上PreferenceManager内部使用的默认文件名是由你的AndroidManifest.xml里的package名称和prefs拼接出来的经过一系列规则处理后实际表现则是package_name_preferences.xml。这导致一个问题如果你想在多个APK之间共享配置或者想改包名这个默认名就会乱。3.2 为什么AndroidX 中要废弃它在 AndroidX 中我们经常看到PreferenceManager被画上删除线标注为Deprecated。主要原因有两方面原因一多实例不友好。getDefaultSharedPreferences()每次调用都返回同一个单例实际上内部有缓存但你需要明确知道这一点才能安全使用。在大型项目里如果两个模块都在用getDefaultSharedPreferences存数据就会出现互相覆写的风险。原因二推荐使用PreferenceManager创建PreferenceScreen的场景已过时。在Android中还有一个同名类PreferenceManager负责加载PreferenceFragmentCompat里的Preference布局这个类本身还活着但是那个获取默认SharedPreferences的静态方法被标记废弃了。官方现在的建议是直接显式创建一个SharedPreferences prefs context.getSharedPreferences(config, Context.MODE_PRIVATE);这个方案清晰明了文件名自己定数据隔离范围自己掌握没有任何黑魔法。3.3 旧代码迁移实战从 PreferenceManager 到 getSharedPreferences如果项目里代码比较多迁移也不是无脑替换我建议按下面的顺序来做先全局搜索PreferenceManager.getDefaultSharedPreferences。根据当前代码所在的模块确定一个合理的配置文件名。比如登录模块就用login_prefs设置模块就用settings_prefs。替换掉所有调用的地方同步修改相同作用域下其他引用的SharedPreferences实例。如果原来的数据已经存在默认文件中需要写一个一次性迁移逻辑把旧文件中的数据拷贝到新文件中防止用户升级后设置丢失。最后跑一遍回归测试重点检查登录状态、开关设置等是否正常保存和读取。这套流程我在实际项目里跑过多次最坑的就是第4步。升级用户的老数据散落在package_name_preferences.xml里直接改代码会读不到导致用户已经勾选的“自动登录”选项突然失效。所以迁移时一定别忘了写数据搬家逻辑。3.4 PreferenceFragmentCompat 配合 AndroidX 的正确姿势如果你的项目里用了PreferenceFragmentCompat来展示设置页那么要注意PreferenceManager又出现了但这次它角色不同。这种情况下你应该继承PreferenceFragmentCompat然后在onCreatePreferences()里调用addPreferencesFromResource()加载一个preference.xml文件。public class SettingsFragment extends PreferenceFragmentCompat { Override public void onCreatePreferences(Bundle savedInstanceState, String rootKey) { setPreferencesFromResource(R.xml.settings_prefs, rootKey); } }在preference.xml里可以声明EditTextPreference,SwitchPreferenceCompat等组件。这个库内部会自动管理一个SharedPreferences实例默认情况下也存在默认的Preferences文件中。如果你想要自定义文件名可以覆写getPreferenceManager().setSharedPreferencesName(my_settings)。但注意这个设置需要在调用setPreferencesFromResource()之前执行否则不会生效。这种玩法才是PreferenceManager仍然活着的合理场景它核心职责是管理 Preference UI 和其背后的数据源。以前那种直接拿它返回默认SharedPreferences的用法确实应该淘汰了。4. 实操过程与核心环节实现一次完整的项目改造示范下面我用一个模拟场景串起整个实操一个普通的应用首页用ConstraintLayout展示一个卡片布局设置页里保存了用户的昵称和消息开关。我们需要做两件事把卡片布局里的layout_editor_absolute属性清掉换成标准约束然后把设置页的PreferenceManager.getDefaultSharedPreferences迁移到显式SharedPreferences。4.1 布局改造从绝对定位到约束定位先上一段改造前的布局示例不推荐保留的写法androidx.constraintlayout.widget.ConstraintLayout android:layout_widthmatch_parent android:layout_heightwrap_content TextView android:idid/tv_title android:layout_widthwrap_content android:layout_heightwrap_content android:text卡片标题 app:layout_editor_absoluteX120dp app:layout_editor_absoluteY50dp / Button android:idid/btn_action android:layout_widthwrap_content android:layout_heightwrap_content android:text操作 app:layout_editor_absoluteX200dp app:layout_editor_absoluteY200dp / /androidx.constraintlayout.widget.ConstraintLayout这段代码在窄屏手机上跑起来可能凑合能看但在宽屏或者横屏模式下就会出现两个控件挤在一起的问题。我先给父容器加两条辅助线androidx.constraintlayout.widget.Guideline android:idid/guideline_vertical android:layout_widthwrap_content android:layout_heightwrap_content android:orientationvertical app:layout_constraintGuide_percent0.5 / androidx.constraintlayout.widget.Guideline android:idid/guideline_horizontal android:layout_widthwrap_content android:layout_heightwrap_content android:orientationhorizontal app:layout_constraintGuide_percent0.3 /然后修改TextView的约束让它相对辅助线定位TextView android:idid/tv_title android:layout_widthwrap_content android:layout_heightwrap_content android:text卡片标题 app:layout_constraintStart_toStartOfid/guideline_vertical app:layout_constraintTop_toTopOfid/guideline_horizontal /同理把按钮约束到 TextView 的底部和开始位置Button android:idid/btn_action android:layout_widthwrap_content android:layout_heightwrap_content android:text操作 app:layout_constraintStart_toStartOfid/tv_title app:layout_constraintTop_toBottomOfid/tv_title app:layout_marginTop16dp /这样一个简单的卡片布局就改好了。在预览里可以看到无论屏幕怎么旋转卡片标题始终在水平方向中间、垂直方向30%处按钮始终在标题下方不再有跑偏问题。4.2 数据存储改造PreferenceManager 换血实录布局改完了接着改设置页的数据存储。原代码大量使用SharedPreferences prefs PreferenceManager.getDefaultSharedPreferences(this); String username prefs.getString(username, 匿名用户); boolean enableNotify prefs.getBoolean(enable_notify, true);改造第一步在 Application 类或者一个工具类里统一提供配置入口public class PrefsHelper { private static final String PREF_NAME user_settings; private static SharedPreferences getPrefs(Context context) { return context.getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE); } public static String getUsername(Context context) { return getPrefs(context).getString(username, 匿名用户); } public static boolean isNotifyEnabled(Context context) { return getPrefs(context).getBoolean(enable_notify, true); } public static void saveUsername(Context context, String name) { getPrefs(context).edit().putString(username, name).apply(); } public static void saveNotifyEnabled(Context context, boolean enabled) { getPrefs(context).edit().putBoolean(enable_notify, enabled).apply(); } }然后所有用到PreferenceManager的地方统一替换为PrefsHelperString username PrefsHelper.getUsername(this); boolean enableNotify PrefsHelper.isNotifyEnabled(this);关键一步数据迁移。因为用户原来的数据存在默认的package_name_preferences.xml中如果不处理老用户的设置会全部丢失。我写了一个迁移类public class PrefMigration { public static void migrate(Context context) { SharedPreferences oldPrefs PreferenceManager.getDefaultSharedPreferences(context); SharedPreferences newPrefs context.getSharedPreferences(user_settings, Context.MODE_PRIVATE); SharedPreferences.Editor editor newPrefs.edit(); // 检查是否需要迁移 if (!newPrefs.contains(migrated)) { if (oldPrefs.contains(username)) { editor.putString(username, oldPrefs.getString(username, 匿名用户)); } if (oldPrefs.contains(enable_notify)) { editor.putBoolean(enable_notify, oldPrefs.getBoolean(enable_notify, true)); } editor.putBoolean(migrated, true); editor.apply(); } } }在 Application 的onCreate()中调用一次PrefMigration.migrate(this)即可。这样老用户的数据能平滑过渡新用户不受影响。4.3 为什么用 apply() 而不是 commit()在迁移代码中我用了apply()而不是commit()这里补充说下。apply()是异步写入不会阻塞主线程而commit()是同步写入会阻塞UI线程返回一个布尔值表示是否写入成功。对于绝大多数场景apply()完全够用而且官方也推荐优先使用apply()。只有在需要立刻获取写入结果并据此做后续操作的场景比如写入失败要提示用户才需要用commit()。实际项目中我见过有人为了等commit()的返回值导致主线程卡顿、页面跳转掉帧的情况。所以能用apply()就不碰commit()。4.4 实测效果与对比改造完成后我用了一台Android 10 的真机和一台Android 13 的模拟器分别跑了相关页面。改造前的布局在Android 10 的169屏幕上基本正常到Android 219屏幕上明显偏移标题位置偏离中心大概30%。改造后两款设备上显示比例完全一致标题和按钮的相对位置也保持良好。存储方面旧数据成功迁移老用户设置未丢新写入的数据可以在user_settings.xml文件中看到。整体跑下来PreferenceManager.getDefaultSharedPreferences的废弃警告全部消失代码里也不再有绝对定位的隐患了。5. 常见问题与排查技巧实录那些年我们踩过的坑5.1 搜索了 layout_editor_absoluteX 还是被坑先检查这三处如果你已经决定清理layout_editor_absolute属性但发现改完布局还是不对我教你一个排查顺序检查布局嵌套层级如果控件外面还套了一个LinearLayout那ConstraintLayout约束到辅助线可能因为外部容器宽度问题出现偏移。比如外部容器设置了padding内部控件按辅助线定位时仍会带上 padding 的影响。检查Tools命名空间有时候布局编辑器生成的tools:layout_editor_absoluteX是带tools:前缀的这类属性只影响设计时预览不会在运行时生效。你如果只删了不带tools:的属性预览没变化其实是很正常的要删就一起删干净。检查ConstraintLayout版本老版本ConstraintLayout对layout_editor_absolute的解析可能和新版本行为有细微差异遇到诡异定位问题先尝试升级到最新版。5.2 PreferenceManager 迁移时发现数据丢了怎么定位数据丢失是迁移里最常见的坑。优先怀疑三件事迁移代码有没有执行、执行顺序对不对、新旧数据文件路径对不对。我遇到过一次比较隐蔽的情况PreferenceManager.getDefaultSharedPreferences返回的文件名不是我以为的package_name_preferences.xml而是取了应用ID中的某一段拼出来的。当时为了排查我直接在代码里打印了prefs.getString(username, null)再把context.getSharedPreferences(user_settings, MODE_PRIVATE)里的内容也打印出来对比两个文件里到底存了啥。发现旧文件里压根没有username这个键后来查了代码才发现原来的保存函数用的是一个不同的 key比如user_name。所以在迁移前一定先去搞清楚老代码里实际用了哪些 key别想当然地按新逻辑去读。5.3 常见问题速查表下面整理一个这个主题下常见问题速查表出现问题时先对着看一眼问题现象可能原因推荐处理方案布局在预览和真机上位置不一致layout_editor_absolute残留删除该属性改用 Guideline 或约束控件在不同分辨率下错位绝对坐标写死使用 parent 约束 辅助线比例定位控件始终贴着左上角约束条件缺失给控件设置layout_constraintStart_toStartOf等属性Preference 数据读不到使用了不同文件名统一用显式getSharedPreferences(文件名, MODE_PRIVATE)老用户升级后设置丢失未做数据迁移在 Application 里写一次性迁移逻辑设置页无响应或崩溃使用了废弃的PreferenceManager静态方法替换为PreferenceFragmentCompatgetSharedPreferences两个模块互相覆盖数据都用了getDefaultSharedPreferences改为各模块维护独立 Preference 文件5.4 独家避坑技巧善用 Android Studio 的 Inspect Code 功能清理这类历史问题时单靠肉眼找太累。我一般会顺手跑一下 Android Studio 的Analyze Inspect Code里面有一项能找到废弃API的使用情况帮我把所有用到PreferenceManager.getDefaultSharedPreferences的地方一次性列出来。针对layout_editor_absolute我还会用CtrlShiftF全局搜一下这个关键词基本上能扫出全部残留。另外如果你的项目开启了 Lint 检查在提交代码前看到Deprecated警告尽量顺手改掉。不要留到后期统一清理后期往往是需求最紧张、最没时间动这些的时候出事概率最高。6. 额外再聊几个 SharedPreferences 与布局的实用细节6.1 SharedPreferences 的线程安全边界很多人以为SharedPreferences是严格线程安全的实际上apply()是异步写磁盘但内部会先更新内存缓存所以读操作看起来是立刻生效的。但如果你同时用多个SharedPreferences实例指向同一个文件偶尔能看到读取到旧数据的情况。所以项目里尽量统一一个入口访问同一个文件避免在多个类里反复getSharedPreferences。另外一点MODE_PRIVATE是默认不推荐再传其他 mode 了像MODE_WORLD_READABLE这些老 API 都已经废弃而且在 Android 7.0 之后系统也不再允许创建这类全局可读文件传了也没用。6.2 ConstraintLayout 性能优化补充用 Guideline、Barrier 替代绝对定位之后对性能也有积极影响。因为约束关系明确布局测量阶段可以减少不必要的测量轮次。尤其是复杂界面如果一层层嵌套用绝对坐标系统可能要多次遍历计算位置稍微多了几个控件就能感知到掉帧。我做了一个小对比实验一个页面上有15个控件用纯约束布局的测量时间大约是4ms而如果用大量layout_editor_absolute属性再加嵌套测量时间能跑到12ms以上。单看数据差距不算巨大但如果在列表项里复用这个布局滚动时的流畅度体验就是天壤之别了。6.3 如何说服团队同事一起改掉旧写法这个问题看起来是技术问题其实也夹杂着团队协作的痛点。有人觉得 “能用就行”一改就出一堆 merge 冲突。我的经验是先在团队内部约定一个规范新建布局一律禁止使用布局编辑器拖拽后生成的绝对定位属性代码 Review 时看到必须打回。然后把迁移工作拆成小批次每次只改几个页面改完一个提一个 PR测试好再合并。这样不一次性搞大重构风险小也更容易被同事接受。PreferenceManager 的情况也类似只要写清楚迁移文档和风险点大多数人都愿意配合改。重点是要给出明确的迁移步骤和验证方式不能丢下一句“这个废弃了你自己看着办”就跑路。6.4 一个关于工具命名的心态调整聊到这里其实想多说一句。layout_editor_absoluteX/Y和PreferenceManager这类问题的出现本质上不是开发者太菜而是Android Studio和Android框架给我们提供了太多“快速路径”这些快捷方式在初期能降低门槛但也容易让人产生依赖。尤其是可视化布局编辑器拖拽定位确实直观方便我们快速搭个草稿。但到了工程化阶段还是得回到代码本身理解每一行app:layout_constraint*的含义。否则布局就只能停留在“能跑”的阶段离“好用”“好维护”还有一段距离。7. 个人实际操作体会与收尾建议做安卓开发这些年我见过不少人栽在这几个坑上。最典型的两种人一种是刚入行被布局编辑器拖拽的快感蒙蔽完全不知道背后生成的layout_editor_absolute是坑另一种是做了几年业务项目里全是PreferenceManager.getDefaultSharedPreferences想改又担心出问题一直拖到依赖库升级不得不改。我的建议是不要怕改。layout_editor_absoluteX和layout_editor_absoluteY在正式代码里出现的次数应该无限趋近于零。改用 Guideline、Barrier、Chain 这些约束布局的原生能力之后你会发现不仅适配问题少了写复杂布局的效率也会直线上升。而PreferenceManager的废弃也不需要恐慌用显式getSharedPreferences定义文件入口加上一套完整的迁移方案升级是很顺滑的事情。如果你现在正对着满屏的废弃警告和诡异的布局偏移头疼拿这篇文章里的步骤去一条条对照排查大部分问题都能解决。顺手把项目里相关的坑点记录下来等下次团队里再有新人踩到类似的坑你也能直接甩一篇文章过去省心省力。
