显示相关
屏幕朝向
https://developer.android.com/reference/android/content/res/Configuration.html#orientation
具体区别如下：
activity.getResources().getConfiguration().orientation获取的是当前设备的实际屏幕方向值，可以动态地根据设备的旋转或用户的操作进行改变。例如，当用户将设备从纵向旋转到横向时，获取到的屏幕方向值也会相应地改变。
总结来说，activity.getResources().getConfiguration().orientation获取的是当前设备的实际屏幕方向值，而Manifest中配置的orientation是活动的默认方向，但实际方向可能会根据设备和用户的操作而改变。
Android屏幕朝向
ORIENTATION_UNDEFINED：未指定
ORIENTATION_PORTRAIT：竖屏
ORIENTATION_LANDSCAPE：横屏
ORIENTATION_SQUARE：正方形
/** Constant for {@link #orientation}: a value indicating that no value has been set. */
public static final int ORIENTATION_UNDEFINED = 0;
/** Constant for {@link #orientation}, value corresponding to the
* <a href="{@docRoot}guide/topics/resources/providing-resources.html#OrientationQualifier">port</a>
* resource qualifier. */
public static final int ORIENTATION_PORTRAIT = 1;
/** Constant for {@link #orientation}, value corresponding to the
* <a href="{@docRoot}guide/topics/resources/providing-resources.html#OrientationQualifier">land</a>
* resource qualifier. */
public static final int ORIENTATION_LANDSCAPE = 2;
/** @deprecated Not currently supported or used. */
@Deprecated public static final int ORIENTATION_SQUARE = 3;
官方
android:screenOrientation
Activity 在设备上的显示方向。如果 activity 是在多窗口模式下运行，则系统会忽略该属性。在 Android 12（API 级别 31）及更高版本中，设备制造商可以将个别设备屏幕（例如，平板电脑大小的可折叠设备屏幕）配置为忽略屏幕方向指定，并强制应用在竖屏模式下垂直展示而在横屏模式下以信箱模式展示，这样便可保持应用所需的固定宽高比，但又能调整应用的屏幕方向以便用户更好地使用。
landscape(常用) 屏幕方向为横向（显示的宽度大于高度）。
portrait(常用) 屏幕方向为纵向（显示的高度大于宽度）。
sensor(常用) 屏幕方向由设备方向传感器决定。显示方向取决于用户如何手持设备，它会在用户旋转设备时发生变化。但在默认情况下，一些设备不会旋转为所有四种可能的方向。如要支持所有这四种方向，请使用 "fullSensor"。即使用户锁定基于传感器的旋转，系统仍可使用传感器。
fullSensor(常用) 屏幕方向由使用 4 种方向中任一方向的设备方向传感器决定。这与 "sensor" 类似，不同之处在于无论设备在正常情况下使用哪种方向，该值均支持所有 4 种可能的屏幕方向（例如，一些设备正常情况下不使用反向纵向或反向横向，但其支持这些方向）。API9 新增
unspecified 默认值。由系统选择方向。在不同设备上，系统使用的政策以及基于政策在特定上下文中所做的选择可能会有所差异。
behind 与 Activity 栈中紧接其后的 Activity 的方向相同。
reverseLandscape 屏幕方向是与正常横向方向相反的横向。API9 新增
reversePortrait 屏幕方向是与正常纵向方向相反的纵向。API9 新增
sensorLandscape 屏幕方向为横向，但可根据设备传感器调整为正常或反向的横向。即使用户锁定基于传感器的旋转，系统仍可使用传感器。API9 新增
sensorPortrait 屏幕方向为纵向，但可根据设备传感器调整为正常或反向的纵向。即使用户锁定基于传感器的旋转，系统仍可使用传感器。API9 新增
userLandscape 屏幕方向为横向，但可根据设备传感器和用户首选项调整为正常或反向的横向。API18 新增
userPortrait 屏幕方向为纵向，但可根据设备传感器和用户首选项调整为正常或反向的纵向。API18 新增
nosensor 确定屏幕方向时不考虑物理方向传感器。系统会忽略传感器，因此显示内容不会随用户手持设备的方向而旋转。
user 用户当前的首选方向。
fullUser 如果用户锁定基于传感器的旋转，则其行为与 user 相同，否则，其行为与 fullSensor 相同，并且支持所有 4 种可能的屏幕方向。API18 新增
locked 将屏幕方向锁定为其当前的任意旋转方向。API18 新增
注意：如果您声明其中一个横向或纵向值，则系统会将其视为对 activity 运行方向的硬性要求。 因此，您声明的值支持通过 Google Play 等服务进行过滤，这样只有支持 activity 规定方向的设备才能使用您的应用。例如，如果您声明 “landscape”、“reverseLandscape” 或 “sensorLandscape”，则您的应用只能供支持横向方向的设备使用。
此外，您还应通过 元素（例如 ）明确声明，您的应用要求采用纵向还是横向方向。这是 Google Play（以及其他支持过滤的服务）提供的一种过滤行为，平台本身并不能控制是否可在仅支持某种方向的设备上安装您的应用。
android:configChanges
列出 activity 将自行处理的配置变更。在运行时发生配置变更时，默认情况下会关闭 activity 并将其重启，但使用该属性声明配置将阻止 activity 重启。相反，activity 会保持运行状态，并且系统会调用其 onConfigurationChanged() 方法。
下列字符串是该属性的有效值。若有多个值，则使用 | 进行分隔，例如 “locale|navigation|orientation”。
注意：如果应用面向 Android 3.2（API 级别 13）或更高版本的系统，则还应声明 “screenLayout” 和 “screenSize” 配置，因为当设备在纵向模式与横向模式之间切换时，屏幕布局和屏幕大小可能会发生变化。
所有这些配置变更都可能影响应用所看到的资源值。因此，调用 onConfigurationChanged() 时，通常必须再次检索所有资源（包括视图布局和可绘制对象），才能正确处理更改。
注意：如要处理所有多窗口模式相关的配置变更，请使用 “screenLayout” 和 “smallestScreenSize”。Android 7.0（API 级别 24）或更高版本的系统支持多窗口模式。
方法 onConfigurationChanged
Called by the system when the device configuration changes while your activity is running. Note that this will only be called if you have selected android:configChanges you would like to handle with the R.attr.configChanges attribute in your manifest. If any configuration change occurs that is not selected to be reported by that attribute, then instead of reporting it the system will stop and restart the activity (to have it launched with the new configuration).
At the time that this function has been called, your Resources object will have been updated to return resource values matching the new configuration.
方法 onSaveInstanceState
**Called to retrieve per-instance state from an activity before being killed so that the state can be restored in onCreate(Bundle) or onRestoreInstanceState(Bundle) (the Bundle populated by this method will be passed to both).
This method is called before an activity may be killed so that when it comes back some time in the future it can restore its state. For example, if activity B is launched in front of activity A, and at some point activity A is killed to reclaim resources, activity A will have a chance to save the current state of its user interface via this method so that when the user returns to activity A, the state of the user interface can be restored via onCreate(Bundle) or onRestoreInstanceState(Bundle).
The default implementation takes care of most of the UI per-instance state for you by calling View.onSaveInstanceState() on each view in the hierarchy that has an id, and by saving the id of the currently focused view (all of which is restored by the default implementation of onRestoreInstanceState(Bundle)). If you override this method to save additional information not captured by each individual view, you will likely want to call through to the default implementation, otherwise be prepared to save all of the state of each view yourself.
If called, this method will occur after onStop() for applications targeting platforms starting with Build.VERSION_CODES.P(28). For applications targeting earlier platform versions this method will occur before onStop() and there are no guarantees about whether it will occur before or after onPause().**
方法 onRestoreInstanceState
This method is called after onStart() when the activity is being re-initialized from a previously saved state, given here in savedInstanceState. Most implementations will simply use onCreate(Bundle) to restore their state, but it is sometimes convenient to do it here after all of the initialization has been done or to allow subclasses to decide whether to use your default implementation. The default implementation of this method performs a restore of any view state that had previously been frozen by onSaveInstanceState(Bundle).
This method is called between onStart() and onPostCreate(Bundle). This method is called only when recreating an activity; the method isn’t invoked if onStart() is called for any other reason
Configuration
处理配置变更
某些设备配置可能会在应用运行期间发生变更。这些变更包括但不限于：
- 应用显示大小
- 屏幕方向
- 字体大小和粗细
- 语言区域
- 深色模式与浅色模式
- 键盘可用性
其中大部分配置变更都是由某些用户互动触发的。例如，旋转或折叠设备会改变应用可用的屏幕空间量。同样，更改设备设置（例如字体大小、语言或首选主题）也会改变 Configuration 对象中的相应值。
这些参数通常需要对应用界面进行充分的更改。因此，Android 平台提供了一种专有机制来处理这种更改。这种机制就是 Activity 重新创建。
activity 重新创建
当发生配置变更时，系统会重新创建 Activity。为此，系统会调用 onDestroy() 并销毁现有的 Activity 实例。随后，系统会使用 onCreate() 创建一个新实例，并且这个新的 Activity 实例会使用更新后的新配置进行初始化。这也意味着，系统还会使用新配置重新创建界面。
重新创建行为会自动利用与新设备配置相匹配的备用资源来自动重新加载应用，从而帮助它适应新配置。
重新创建示例
假设有这样一个 TextView，它使用布局 XML 文件中定义的 android:text=“@string/title” 来显示静态标题。创建视图后，视图会根据当前语言来准确设置文本一次。如果语言发生更改，系统会重新创建 activity。因此，系统还会重新创建该视图，并根据新语言将其初始化为正确的值。
重新创建过程还会清除您在 Activity 或其包含的 Fragment、View 或其他对象中，以字段形式保留的任何状态。这是因为 Activity 重新创建过程会创建 Activity 和界面的全新实例。此外，之前的旧 Activity 不再可见或不再有效，因此对该 activity 或其所含对象的任何其余引用都已过时。它们会导致 bug、内存泄漏和崩溃。
配置变更：关键概念和最佳实践
在处理配置变更时，您需要了解以下关键概念：
- 配置：设备配置用于定义界面如何向用户显示内容，例如应用显示大小、语言区域或系统主题。
- 配置变更：配置会根据用户互动发生变更。例如，用户可能会更改设备设置或与设备的物理互动方式。您无法阻止配置变更。
- Activity 重新创建：默认情况下，配置变更会导致重新创建 Activity。这是为新配置重新初始化应用状态的内置机制。
- Activity 销毁：Activity 重新创建会导致系统销毁旧的 Activity 实例，并创建一个新实例来代替它。旧实例现已过时。对该实例的任何其余引用都会导致内存泄漏、bug 或崩溃。
- 状态：旧 Activity 实例中的状态不存在于新 Activity 实例中，因为它们是两个不同的对象实例。请按照保存界面状态中描述的方法保留应用和用户状态。
- 停用：为某种类型的配置变更停用 activity 重新创建功能是一种潜在的优化方案。您需要确保应用根据新配置进行正确更新。
为了提供良好的用户体验，请遵循以下最佳实践：
为配置频繁变更做好准备：不要认为配置变更会很少发生或从不发生过，无论 API 级别、外形规格或界面工具包如何。当用户导致配置变更时，他们会希望应用进行更新，并继续使用新配置正常运行。
保留状态：在重新创建 Activity 时，不要丢失用户的状态。请按照保存界面状态中描述的方法保留状态。
避免停用快速修复功能：不要停用 Activity 重新创建功能，这样可以轻松避免丢失状态。停用 activity 重新创建功能需要实现处理变更的承诺，而您可能会因为其他配置变更、进程终止或应用关闭所带来的 Activity 重新创建而丢失状态。因此，您无法完全停用 Activity 重新创建功能。请按照保存界面状态中描述的方法保留状态。
不要回避配置变更：不要为了回避配置变更和 Activity 重新创建，而对屏幕方向、宽高比或尺寸可调整性施加限制。这会对想要按照自己首选方式使用应用的用户产生负面影响。