east – 第55页 – gitweixin

flume 7月 10,2021

Flume对接数据遇到的坑

业务是这样的：别的地方服务器通过ftp传来一些压缩包，对压缩包进行解压，然后flume进行采集发到kafka，spark Streaming进行处理。

进行解压的脚本代码如下:

#/bin/bash
end = "${dirname "$0"}"/"$1"
source = "${dirname "$0"}"/"$2"
final =  "${dirname "$0"}"/"$3"
while [2 -gt 1 ]
do
   for i in 'ls ${source}‘
   do
   if [[ ${i} != "" && ${i} != *.tmp ]]
   then
       unzip ${source}/${i} -d ${end}/
       mv -f ${source}/${i} ${final}
   fi
done
sleep 5

原本一直持续能解压文件，最近出现停止。

执行命令时，还出现提示是否覆盖。这时才明白可能是这个原因导致脚本没能顺利执行。为了不提示是否覆盖，可以加参数 -o。修改命令如下：

unzip -o ${source}/${i} -d ${end}/

作者 east

bug清单, flume 6月 13,2021

鸿蒙Harmony和Android服务Service对比

Harmony和Android都提供了后台服务，当用户切换别的应用时，都可以使用服务来播放音乐保证不中断。

图1 鸿蒙Harmony Service Ability 生命周期

图2 Android Service的生命周期

Harmony Service Ability：

基于Service模板的Ability（以下简称“Service”）主要用于后台运行任务（如执行音乐播放、文件下载等），但不提供用户交互界面。Service可由其他应用或Ability启动，即使用户切换到其他应用，Service仍将在后台继续运行。

Service是单实例的。在一个设备上，相同的Service只会存在一个实例。如果多个Ability共用这个实例，只有当与Service绑定的所有Ability都退出后，Service才能够退出。由于Service是在主线程里执行的，因此，如果在Service里面的操作时间过长，开发者必须在Service里创建新的线程来处理（详见线程间通信），防止造成主线程阻塞，应用程序无响应。

与Page类似，Service也拥有生命周期，如图1所示。根据调用方法的不同，其生命周期有以下两种路径：

启动Service该Service在其他Ability调用startAbility()时创建，然后保持运行。其他Ability通过调用stopAbility()来停止Service，Service停止后，系统会将其销毁。
连接Service该Service在其他Ability调用connectAbility()时创建，客户端可通过调用disconnectAbility()断开连接。多个客户端可以绑定到相同Service，而且当所有绑定全部取消后，系统即会销毁该Service。图1 Service生命周期

一般情况下，Service都是在后台运行的，后台Service的优先级都是比较低的，当资源不足时，系统有可能回收正在运行的后台Service。

在一些场景下（如播放音乐），用户希望应用能够一直保持运行，此时就需要使用前台Service。前台Service会始终保持正在运行的图标在系统状态栏显示。

使用前台Service并不复杂，开发者只需在Service创建的方法里，调用keepBackgroundRunning()将Service与通知绑定。调用keepBackgroundRunning()方法前需要在配置文件中声明ohos.permission.KEEP_BACKGROUND_RUNNING权限，同时还需要在配置文件中添加对应的backgroundModes参数。在onStop()方法中调用cancelBackgroundRunning()方法可停止前台Service。

Android Service：

Service 是一种可在后台执行长时间运行操作而不提供界面的应用组件。服务可由其他应用组件启动，而且即使用户切换到其他应用，服务仍将在后台继续运行。此外，组件可通过绑定到服务与之进行交互，甚至是执行进程间通信 (IPC)。例如，服务可在后台处理网络事务、播放音乐，执行文件 I/O 或与内容提供程序进行交互。

以下是三种不同的服务类型：前台前台服务执行一些用户能注意到的操作。例如，音频应用会使用前台服务来播放音频曲目。前台服务必须显示通知。即使用户停止与应用的交互，前台服务仍会继续运行。后台后台服务执行用户不会直接注意到的操作。例如，如果应用使用某个服务来压缩其存储空间，则此服务通常是后台服务。

注意：如果您的应用面向 API 级别 26 或更高版本，当应用本身未在前台运行时，系统会对运行后台服务施加限制。在诸如此类的大多数情况下，您的应用应改为使用计划作业。绑定当应用组件通过调用 bindService() 绑定到服务时，服务即处于绑定状态。绑定服务会提供客户端-服务器接口，以便组件与服务进行交互、发送请求、接收结果，甚至是利用进程间通信 (IPC) 跨进程执行这些操作。仅当与另一个应用组件绑定时，绑定服务才会运行。多个组件可同时绑定到该服务，但全部取消绑定后，该服务即会被销毁。

虽然本文档分开概括讨论启动服务和绑定服务，但您的服务可同时以这两种方式运行，换言之，它既可以是启动服务（以无限期运行），亦支持绑定。唯一的问题在于您是否实现一组回调方法：onStartCommand()（让组件启动服务）和 onBind()（实现服务绑定）。

无论服务是处于启动状态还是绑定状态（或同时处于这两种状态），任何应用组件均可像使用 Activity 那样，通过调用 Intent 来使用服务（即使此服务来自另一应用）。不过，您可以通过清单文件将服务声明为私有服务，并阻止其他应用访问该服务。使用清单文件声明服务部分将对此做更详尽的阐述。

作者 east

Android, Harmony 6月 11,2021

鸿蒙Harmony和Android的Intent对比

鸿蒙harmony和android都有Intent，用于一个操作界面调用另一个操作界面，并可用于传递数据。

Harmony Intent：

Intent是对象之间传递信息的载体。例如，当一个Ability需要启动另一个Ability时，或者一个AbilitySlice需要导航到另一个AbilitySlice时，可以通过Intent指定启动的目标同时携带相关数据。Intent的构成元素包括Operation与Parameters，具体描述参见表1。

属性	子属性	描述
Operation	Action	表示动作，通常使用系统预置Action，应用也可以自定义Action。例如IntentConstants.ACTION_HOME表示返回桌面动作。
Entity	表示类别，通常使用系统预置Entity，应用也可以自定义Entity。例如Intent.ENTITY_HOME表示在桌面显示图标。
Uri	表示Uri描述。如果在Intent中指定了Uri，则Intent将匹配指定的Uri信息，包括scheme, schemeSpecificPart, authority和path信息。
Flags	表示处理Intent的方式。例如Intent.FLAG_ABILITY_CONTINUATION标记在本地的一个Ability是否可以迁移到远端设备继续运行。
BundleName	表示包描述。如果在Intent中同时指定了BundleName和AbilityName，则Intent可以直接匹配到指定的Ability。
AbilityName	表示待启动的Ability名称。如果在Intent中同时指定了BundleName和AbilityName，则Intent可以直接匹配到指定的Ability。
DeviceId	表示运行指定Ability的设备ID。
Parameters	–	Parameters是一种支持自定义的数据结构，开发者可以通过Parameters传递某些请求所需的额外信息。

当Intent用于发起请求时，根据指定元素的不同，分为两种类型：

如果同时指定了BundleName与AbilityName，则根据Ability的全称（例如“com.demoapp.FooAbility”）来直接启动应用。
如果未同时指定BundleName和AbilityName，则根据Operation中的其他属性来启动应用。

说明

Intent设置属性时，必须先使用Operation来设置属性。如果需要新增或修改属性，必须在设置Operation后再执行操作。

关于Intent最简单的使用方法，可参见快速入门的示例代码。其中“实现页面跳转”重点描述了使用Intent实现两个页面跳转关系的操作。

根据Ability的全称启动应用

通过构造包含BundleName与AbilityName的Operation对象，可以启动一个Ability、并导航到该Ability。示例代码如下：

Intent intent = new Intent();
// 通过Intent中的OperationBuilder类构造operation对象，指定设备标识（空串表示当前设备）、应用包名、Ability名称Operation operation = new Intent.OperationBuilder()        .withDeviceId("")        .withBundleName("com.demoapp")        .withAbilityName("com.demoapp.FooAbility")        .build();
// 把operation设置到intent中intent.setOperation(operation);startAbility(intent);

作为处理请求的对象，会在相应的回调方法中接收请求方传递的Intent对象。以导航到另一个Ability为例，导航的目标Ability可以在其onStart()回调的参数中获得Intent对象。

根据Operation的其他属性启动应用

有些场景下，开发者需要在应用中使用其他应用提供的某种能力，而不感知提供该能力的具体是哪一个应用。例如开发者需要通过浏览器打开一个链接，而不关心用户最终选择哪一个浏览器应用，则可以通过Operation的其他属性（除BundleName与AbilityName之外的属性）描述需要的能力。如果设备上存在多个应用提供同种能力，系统则弹出候选列表，由用户选择由哪个应用处理请求。以下示例展示使用Intent跨Ability查询天气信息。

请求方

在Ability中构造Intent以及包含Action的Operation对象，并调用startAbilityForResult()方法发起请求。然后重写onAbilityResult()回调方法，对请求结果进行处理。

private void queryWeather() {    Intent intent = new Intent();    Operation operation = new Intent.OperationBuilder()            .withAction(Intent.ACTION_QUERY_WEATHER)            .build();    intent.setOperation(operation);    startAbilityForResult(intent, REQ_CODE_QUERY_WEATHER);}
@Overrideprotected void onAbilityResult(int requestCode, int resultCode, Intent resultData) {    switch (requestCode) {        case REQ_CODE_QUERY_WEATHER:            // Do something with result.            ...            return;        default:            ...    }}

处理方

作为处理请求的对象，首先需要在配置文件中声明对外提供的能力，以便系统据此找到自身并作为候选的请求处理者。
1. {
2. “module”: {
3. …
4. “abilities”: [
5. {
6. …
7. “skills”:[
8. {
9. “actions”:[
10. “ability.intent.QUERY_WEATHER”
11. ]
12. }
13. ]
14. …
15. }
16. ]
17. …
18. }
19. …
20. }
在Ability中配置路由以便支持以此action导航到对应的AbilitySlice。
1. @Override
2. protected void onStart(Intent intent) {
3. …
4. addActionRoute(Intent.ACTION_QUERY_WEATHER, DemoSlice.class.getName());
5. …
6. }
在Ability中处理请求，并调用setResult()方法暂存返回结果。
1. @Override
2. protected void onActive() {
3. …
4. Intent resultIntent = new Intent();
5. setResult(0, resultIntent); //0为当前Ability销毁后返回的resultCode。
6. …
7. }

Android Intent：

Intent 是一个消息传递对象，您可以用来从其他应用组件请求操作。尽管 Intent 可以通过多种方式促进组件之间的通信，但其基本用例主要包括以下三个：

启动 ActivityActivity 表示应用中的一个屏幕。通过将 Intent 传递给 startActivity()，您可以启动新的 Activity 实例。Intent 用于描述要启动的 Activity，并携带任何必要的数据。如果您希望在 Activity 完成后收到结果，请调用 startActivityForResult()。在 Activity 的 onActivityResult() 回调中，您的 Activity 将结果作为单独的 Intent 对象接收。如需了解详细信息，请参阅 Activity 指南。
启动服务Service 是一个不使用用户界面而在后台执行操作的组件。使用 Android 5.0（API 级别 21）及更高版本，您可以启动包含 JobScheduler 的服务。如需了解有关 JobScheduler 的详细信息，请参阅其 API-reference documentation。对于 Android 5.0（API 级别 21）之前的版本，您可以使用 Service 类的方法来启动服务。通过将 Intent 传递给 startService()，您可以启动服务执行一次性操作（例如，下载文件）。Intent 用于描述要启动的服务，并携带任何必要的数据。如果服务旨在使用客户端-服务器接口，则通过将 Intent 传递给 bindService()，您可以从其他组件绑定到此服务。如需了解详细信息，请参阅服务指南。
传递广播广播是任何应用均可接收的消息。系统将针对系统事件（例如：系统启动或设备开始充电时）传递各种广播。通过将 Intent 传递给 sendBroadcast() 或 sendOrderedBroadcast()，您可以将广播传递给其他应用。

本页的其余部分将说明 Intent 的工作方式及如何使用 Intent。对于相关信息，请参阅与其他应用交互和共享内容。

Intent 类型

Intent 分为两种类型：

显式 Intent：通过提供目标应用的软件包名称或完全限定的组件类名来指定可处理 Intent 的应用。通常，您会在自己的应用中使用显式 Intent 来启动组件，这是因为您知道要启动的 Activity 或服务的类名。例如，您可能会启动您应用内的新 Activity 以响应用户操作，或者启动服务以在后台下载文件。
隐式 Intent ：不会指定特定的组件，而是声明要执行的常规操作，从而允许其他应用中的组件来处理。例如，如需在地图上向用户显示位置，则可以使用隐式 Intent，请求另一具有此功能的应用在地图上显示指定的位置。

图 1 显示如何在启动 Activity 时使用 Intent。当 Intent 对象显式命名某个具体的 Activity 组件时，系统立即启动该组件。

图 1. 隐式 Intent 如何通过系统传递以启动其他 Activity：[1] Activity A 创建包含操作描述的 Intent，并将其传递给 startActivity()。[2] Android 系统搜索所有应用中与 Intent 匹配的 Intent 过滤器。找到匹配项之后，[3] 该系统通过调用匹配 Activity (Activity B) 的 onCreate() 方法并将其传递给 Intent，以此启动匹配 Activity。

使用隐式 Intent 时，Android 系统通过将 Intent 的内容与在设备上其他应用的清单文件中声明的 Intent 过滤器进行比较，从而找到要启动的相应组件。如果 Intent 与 Intent 过滤器匹配，则系统将启动该组件，并向其传递 Intent 对象。如果多个 Intent 过滤器兼容，则系统会显示一个对话框，支持用户选取要使用的应用。

Intent 过滤器是应用清单文件中的一个表达式，用于指定该组件要接收的 Intent 类型。例如，通过为 Activity 声明 Intent 过滤器，您可以使其他应用能够直接使用某一特定类型的 Intent 启动 Activity。同样，如果您没有为 Activity 声明任何 Intent 过滤器，则 Activity 只能通过显式 Intent 启动。

注意：为了确保应用的安全性，启动 Service 时，请始终使用显式 Intent，且不要为服务声明 Intent 过滤器。使用隐式 Intent 启动服务存在安全隐患，因为您无法确定哪些服务将响应 Intent，且用户无法看到哪些服务已启动。从 Android 5.0（API 级别 21）开始，如果使用隐式 Intent 调用 bindService()，系统会抛出异常。

构建 Intent

Intent 对象携带 Android 系统用来确定要启动哪个组件的信息（例如，准确的组件名称或应当接收该 Intent 的组件类别），以及收件人组件为了正确执行操作而使用的信息（例如，要采取的操作以及要处理的数据）。

Intent 中包含的主要信息如下：组件名称要启动的组件名称。

这是可选项，但也是构建显式 Intent 的一项重要信息，这意味着 Intent 应当仅传递给由组件名称定义的应用组件。如果没有组件名称，则 Intent 则为隐式，且系统将根据其他 Intent 信息（例如，以下所述的操作、数据和类别）决定哪个组件应当接收 Intent。如需在应用中启动特定的组件，则应指定该组件的名称。

请注意：启动 Service 时，应始终指定组件名称。否则，您无法确定哪项服务会响应 Intent，且用户无法看到哪项服务已启动。

Intent 的这一字段是 ComponentName 对象，您可以使用目标组件的完全限定类名指定此对象，其中包括应用的软件包名称。例如，com.example.ExampleActivity。您可以使用 setComponent()、setClass()、setClassName()，或 Intent 构造函数设置组件名称。操作指定要执行的通用操作（例如，查看或选取）的字符串。

对于广播 Intent，这是指已发生且正在报告的操作。操作会在很大程度上决定其余 Intent 的构成，特别是数据和 extra 中包含的内容。

您可以指定自己的操作，供 Intent 在您的应用内使用（或者供其他应用在您的应用中调用组件）。但是，您通常应该使用由Intent 类或其他框架类定义的操作常量。以下是一些用于启动 Activity 的常见操作：ACTION_VIEW如果您拥有一些某项 Activity 可向用户显示的信息（例如，要使用图库应用查看的照片；或者要使用地图应用查看的地址），请通过 Intent 将此操作与 startActivity() 结合使用。ACTION_SEND这也称为共享 Intent。如果您拥有一些用户可通过其他应用（例如，电子邮件应用或社交共享应用）共享的数据，则应使用 Intent 将此操作与 startActivity() 结合使用。

有关更多定义通用操作的常量，请参阅 Intent 类参考文档。其他操作在 Android 框架中的其他位置定义。例如，对于在系统的设置应用中打开特定屏幕的操作，将在 Settings中定义。

您可以使用 setAction() 或 Intent 构造函数为 Intent 指定操作。

作者 east

Android, Harmony 6月 10,2021

鸿蒙Harmony和Android生命周期对比

Android发展了这么多年了，其生命周期已经是非常完善，鸿蒙harmony也是借鉴android生命周期，甚至生命周期名字都类似。

harmony鸿蒙生命周期

鸿蒙Harmony的Page Ability生命周期

系统管理或用户操作等行为均会引起Page实例在其生命周期的不同状态之间进行转换。Ability类提供的回调机制能够让Page及时感知外界变化，从而正确地应对状态变化（比如释放资源），这有助于提升应用的性能和稳健性。

onStart()当系统首次创建Page实例时，触发该回调。对于一个Page实例，该回调在其生命周期过程中仅触发一次，Page在该逻辑后将进入INACTIVE状态。开发者必须重写该方法，并在此配置默认展示的AbilitySlice。
1. @Override
2. public void onStart(Intent intent) {
3. super.onStart(intent);
4. super.setMainRoute(FooSlice.class.getName());
5. }
onActive()Page会在进入INACTIVE状态后来到前台，然后系统调用此回调。Page在此之后进入ACTIVE状态，该状态是应用与用户交互的状态。Page将保持在此状态，除非某类事件发生导致Page失去焦点，比如用户点击返回键或导航到其他Page。当此类事件发生时，会触发Page回到INACTIVE状态，系统将调用onInactive()回调。此后，Page可能重新回到ACTIVE状态，系统将再次调用onActive()回调。因此，开发者通常需要成对实现onActive()和onInactive()，并在onActive()中获取在onInactive()中被释放的资源。
onInactive()当Page失去焦点时，系统将调用此回调，此后Page进入INACTIVE状态。开发者可以在此回调中实现Page失去焦点时应表现的恰当行为。
onBackground()如果Page不再对用户可见，系统将调用此回调通知开发者用户进行相应的资源释放，此后Page进入BACKGROUND状态。开发者应该在此回调中释放Page不可见时无用的资源，或在此回调中执行较为耗时的状态保存操作。
onForeground()处于BACKGROUND状态的Page仍然驻留在内存中，当重新回到前台时（比如用户重新导航到此Page），系统将先调用onForeground()回调通知开发者，而后Page的生命周期状态回到INACTIVE状态。开发者应当在此回调中重新申请在onBackground()中释放的资源，最后Page的生命周期状态进一步回到ACTIVE状态，系统将通过onActive()回调通知开发者用户。
onStop()系统将要销毁Page时，将会触发此回调函数，通知用户进行系统资源的释放。销毁Page的可能原因包括以下几个方面：
- 用户通过系统管理能力关闭指定Page，例如使用任务管理器关闭Page。
- 用户行为触发Page的terminateAbility()方法调用，例如使用应用的退出功能。
- 配置变更导致系统暂时销毁Page并重建。
- 系统出于资源管理目的，自动触发对处于BACKGROUND状态Page的销毁。

Android Activity 生命周期:

当用户浏览、退出和返回到您的应用时，您应用中的 Activity 实例会在其生命周期的不同状态间转换。Activity 类会提供许多回调，这些回调会让 Activity 知晓某个状态已经更改：系统正在创建、停止或恢复某个 Activity，或者正在销毁该 Activity 所在的进程。

在生命周期回调方法中，您可以声明用户离开和再次进入 Activity 时 Activity 的行为方式。例如，如果您正构建流媒体视频播放器，当用户切换至另一应用时，您可能要暂停视频或终止网络连接。当用户返回时，您可以重新连接网络并允许用户从同一位置继续播放视频。换言之，每个回调都支持您执行适合给定状态变更的特定作业。在合适的时间执行正确的作业，并妥善处理转换，这将提升应用的稳健性和性能。例如，良好的生命周期回调实现有助于防止应用出现以下问题：

当用户在使用应用时接听来电，或切换至另一应用时崩溃。
当用户未主动使用它时，消耗宝贵的系统资源。
当用户离开应用并在稍后返回时，丢失用户的进度。
当屏幕在横向和纵向之间旋转时，崩溃或丢失用户的进度。

本文档将详细介绍 Activity 生命周期。首先介绍生命周期范例。接着介绍每个回调：它们执行时内部发生了什么，以及您应该在执行期间实现什么。然后，简要介绍 Activity 状态与导致进程被系统终止的漏洞之间的关系。最后，讨论与在 Activity 状态之间转换相关的若干主题。

如需了解有关处理生命周期的信息（包括最佳做法的相关指导），请参阅使用生命周期感知型组件处理生命周期和保存界面状态。如需了解如何将 Activity 与架构组件结合使用，以构建生产质量的稳健应用，请参阅应用架构指南。

Activity 生命周期概念

为了在 Activity 生命周期的各个阶段之间导航转换，Activity 类提供六个核心回调：onCreate()、onStart()、onResume()、onPause()、onStop() 和 onDestroy()。当 Activity 进入新状态时，系统会调用其中每个回调。

图 1 是对此范例的直观展现。

图 1. Activity 生命周期的简化图示。

当用户开始离开 Activity 时，系统会调用方法来销毁该 Activity。在某些情况下，此销毁只是部分销毁；Activity 仍然驻留在内存中（例如当用户切换至另一应用时），并且仍然可以返回到前台。如果用户返回到该 Activity，Activity 会从用户离开时的位置继续运行。除了少数例外，应用在后台运行时会受到限制，无法启动 Activity。

系统终止给定进程及其中 Activity 的可能性取决于当时 Activity 的状态。Activity 状态和从内存中弹出会更详细地介绍状态与弹出漏洞之间的关系。

根据 Activity 的复杂程度，您可能不需要实现所有生命周期方法。但是，请务必了解每个方法，并实现能够确保应用按用户预期方式运行的方法，这非常重要。

在下一部分中，本文档将详细介绍用于处理状态间转换的回调。

生命周期回调

本部分介绍 Activity 生命周期中所用回调方法的相关概念及实现信息。

某些操作（例如调用 setContentView()）属于 Activity 生命周期方法本身。不过，用于实现依赖组件操作的代码应放在组件本身内。为此，您必须使依赖组件具有生命周期感知能力。请参阅使用生命周期感知型组件处理生命周期，了解如何让您的依赖组件获得生命周期感知能力。

onCreate()

您必须实现此回调，它会在系统首次创建 Activity 时触发。Activity 会在创建后进入“已创建”状态。在 onCreate() 方法中，您需执行基本应用启动逻辑，该逻辑在 Activity 的整个生命周期中只应发生一次。例如，onCreate() 的实现可能会将数据绑定到列表，将 Activity 与 ViewModel 相关联，并实例化某些类作用域变量。此方法会接收 savedInstanceState 参数，后者是包含 Activity 先前保存状态的 Bundle 对象。如果 Activity 此前未曾存在，Bundle 对象的值为 null。

如果您有一个生命周期感知型组件与您的 Activity 生命周期相关联，该组件将收到 ON_CREATE 事件。系统将调用带有 @OnLifecycleEvent 注释的方法，以使您的生命周期感知型组件可以执行已创建状态所需的任何设置代码。

onCreate() 方法的以下示例显示执行 Activity 某些基本设置的一些代码，例如声明界面（在 XML 布局文件中定义）、定义成员变量，以及配置某些界面。在本示例中，系统通过将文件的资源 ID R.layout.main_activity 传递给 setContentView() 来指定 XML 布局文件。

onStart()

当 Activity 进入“已开始”状态时，系统会调用此回调。onStart() 调用使 Activity 对用户可见，因为应用会为 Activity 进入前台并支持互动做准备。例如，应用通过此方法来初始化维护界面的代码。

当 Activity 进入已开始状态时，与 Activity 生命周期相关联的所有生命周期感知型组件都将收到 ON_START 事件。

onStart() 方法会非常快速地完成，并且与“已创建”状态一样，Activity 不会一直处于“已开始”状态。一旦此回调结束，Activity 便会进入“已恢复”状态，系统将调用 onResume() 方法。

onResume()

Activity 会在进入“已恢复”状态时来到前台，然后系统调用 onResume() 回调。这是应用与用户互动的状态。应用会一直保持这种状态，直到某些事件发生，让焦点远离应用。此类事件包括接到来电、用户导航到另一个 Activity，或设备屏幕关闭。

当 Activity 进入已恢复状态时，与 Activity 生命周期相关联的所有生命周期感知型组件都将收到 ON_RESUME 事件。这时，生命周期组件可以启用在组件可见且位于前台时需要运行的任何功能，例如启动相机预览。

当发生中断事件时，Activity 进入“已暂停”状态，系统调用 onPause() 回调。

如果 Activity 从“已暂停”状态返回“已恢复”状态，系统将再次调用 onResume() 方法。因此，您应实现 onResume()，以初始化在 onPause() 期间释放的组件，并执行每次 Activity 进入“已恢复”状态时必须完成的任何其他初始化操作。

onPause()

系统将此方法视为用户将要离开您的 Activity 的第一个标志（尽管这并不总是意味着 Activity 会被销毁）；此方法表示 Activity 不再位于前台（尽管在用户处于多窗口模式时 Activity 仍然可见）。使用 onPause() 方法暂停或调整当 Activity 处于“已暂停”状态时不应继续（或应有节制地继续）的操作，以及您希望很快恢复的操作。Activity 进入此状态的原因有很多。例如：

如 onResume() 部分所述，某个事件会中断应用执行。这是最常见的情况。
在 Android 7.0（API 级别 24）或更高版本中，有多个应用在多窗口模式下运行。无论何时，都只有一个应用（窗口）可以拥有焦点，因此系统会暂停所有其他应用。
有新的半透明 Activity（例如对话框）处于开启状态。只要 Activity 仍然部分可见但并未处于焦点之中，它便会一直暂停。

onStop()

如果您的 Activity 不再对用户可见，说明其已进入“已停止”状态，因此系统将调用 onStop() 回调。例如，当新启动的 Activity 覆盖整个屏幕时，可能会发生这种情况。如果 Activity 已结束运行并即将终止，系统还可以调用 onStop()。

当 Activity 进入已停止状态时，与 Activity 生命周期相关联的所有生命周期感知型组件都将收到 ON_STOP 事件。这时，生命周期组件可以停止在组件未显示在屏幕上时无需运行的任何功能。

在 onStop() 方法中，应用应释放或调整在应用对用户不可见时的无用资源。例如，应用可以暂停动画效果，或从精确位置更新切换到粗略位置更新。使用 onStop() 而非 onPause() 可确保与界面相关的工作继续进行，即使用户在多窗口模式下查看您的 Activity 也能如此。

您还应使用 onStop() 执行 CPU 相对密集的关闭操作。例如，如果您无法找到更合适的时机来将信息保存到数据库，可以在 onStop() 期间执行此操作。

作者 east

bug清单, Kafka, Spark 6月 10,2021

运行 Spark Streaming出现”Could not find KafkaClient entry in the JAAS configuration”

在使用FusionInsight HD大数据平台，用Spark Streaming来处理数据接入，kafka作为消费者，运行程序时出现”Could not find KafkaClient entry in the JAAS configuration”，当时怀疑是FusionInsight HD 的客户端相关配置有问题。

采用替换法思维，在另一台已经验证 FusionInsight HD 的客户端没问题的服务上运行，果然这个问题没做出现，仔细对比了这2台服务FusionInsight HD 的客户端的配置，发现在spark配置文件（hd安装目录/Spark2x/spark/conf/Jaas.conf）要修改为下面的配置：

KafkaClient{
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
principal="大数据平台账号"
useTicketCache=false
keyTab="user.keytab的路径"
storeKey=true;
};

作者 east

Android, Harmony 6月 9,2021

鸿蒙Harmony和Android应用组件对比

在Android开发中，有我们熟知的四大组件，
activity、service、content provider、broadcast receiver。而在harmony中，则抽象为 Ability ，

分为FA（Feature Ability）和PA（Particle Ability）两种类型：

FA支持Page Ability：Page模板是FA唯一支持的模板，用于提供与用户交互的能力。（类同于Android的Activity）
PA支持Service Ability和Data Ability：Service模板用于提供后台运行任务的能力；Data模板用于对外部提供统一的数据访问抽象。(
Service模板类似于Android 的Service，
Data模板类似于Android的
content provider ）

在Android开发中，用Broadcast Receiver并不是非常多，更多是用EventBus等消息框架，在harmony设计中，也是借鉴EventsBus等消息框架的思想。

HarmonyOS通过CES（Common Event Service，公共事件服务）为应用程序提供订阅、发布、退订公共事件的能力，通过ANS（Advanced Notification Service，即通知增强服务）系统服务来为应用程序提供发布通知的能力。

公共事件可分为系统公共事件和自定义公共事件。
- 系统公共事件：系统将收集到的事件信息，根据系统策略发送给订阅该事件的用户程序。例如：用户可感知亮灭屏事件，系统关键服务发布的系统事件（例如：USB插拔，网络连接，系统升级等）。
- 自定义公共事件：应用自定义一些公共事件用来处理业务逻辑。
通知提供应用的即时消息或通信消息，用户可以直接删除或点击通知触发进一步的操作。
IntentAgent封装了一个指定行为的Intent，可以通过IntentAgent启动Ability和发布公共事件。

应用如果需要接收公共事件，需要订阅相应的事件。

约束与限制

公共事件的约束与限制

目前公共事件仅支持动态订阅。部分系统事件需要具有指定的权限，具体的权限见API参考。
目前公共事件订阅不支持多用户。
ThreadMode表示线程模型，目前仅支持HANDLER模式，即在当前UI线程上执行回调函数。
deviceId用来指定订阅本地公共事件还是远端公共事件。deviceId为null、空字符串或本地设备deviceId时，表示订阅本地公共事件，否则表示订阅远端公共事件。

通知的约束与限制

通知目前支持六种样式：普通文本、长文本、图片、社交、多行文本和媒体样式。创建通知时必须包含一种样式。
通知支持快捷回复。

IntentAgent的限制

使用IntentAgent启动Ability时，Intent必须指定Ability的包名和类名。

作者 east

Android, Harmony 6月 9,2021

鸿蒙Harmony和Android应用权限管理对比

早期的Android对权限管理不严格，导致了一些app获取各种超过需要的权限，甚至做一些损害用户的行为，例如后台自动下载，监听短信内容，自动打电话等等。后来google认识这些问题，后期版本对权限管理严格了很多。Harmony作为后起之秀，自然在设计之初就考虑了这个问题。

Harmony应用权限管理：

HarmonyOS中所有的应用均在应用沙盒内运行。默认情况下，应用只能访问有限的系统资源，系统负责管理应用对资源的访问权限。

应用权限管理是由接口提供方（Ability）、接口使用方（应用）、系统（包括云侧和端侧）以及用户等多方共同参与的整个流程，保证受限接口是在约定好的规则下被正常使用，避免接口被滥用而导致用户、应用和设备受损。

本节重点介绍应用权限管理的基本思想。有关权限使用的详细信息，请参阅权限。

权限声明

应用需要在config.json中使用“reqPermissions”属性对需要的权限逐个进行声明。
若使用到的三方库也涉及权限使用，也需统一在应用的config.json中逐个声明。
没有在config.json中声明的权限，应用就无法获得此权限的授权。

动态申请敏感权限

动态申请敏感权限基于用户可知可控的原则，需要应用在运行时主动调用系统动态申请权限的接口，系统弹框由用户授权，用户结合应用运行场景的上下文，识别出应用申请相应敏感权限的合理性，从而做出正确的选择。

即使用户向应用授予了请求的权限，应用在调用受此权限管控的接口前，也应该先检查自己有无此权限，而不能把之前授予的状态持久化，因为用户在动态授予后还可以通过设置取消应用的权限。

有关于应用动态申请敏感权限的详细信息，请参阅动态申请权限。

自定义权限

HarmonyOS为了保证应用对外提供的接口不被恶意调用，需要对调用接口的调用者进行鉴权。

大多情况下，系统已定义的权限满足了应用的基本需要，若有特殊的访问控制需要，应用可在config.json中以”defPermissions”: []属性来定义新的权限，并通过“availableScope”和“grantMode”两个属性分别确定权限的开放范围和授权方式，使得权限定义更加灵活且易于理解。有关HarmonyOS权限开放范围和授权方式详细的描述，请参阅权限授予方式字段说明和权限限制范围字段说明。

为了避免应用自定义新权限出现重名的情况，建议应用对新权限的命名以包名的前两个字段开头，这样可以防止不同开发者的应用间出现自定义权限重名的情况。

权限保护方法

保护Ability：通过在config.json里对应的Ability中配置”permissions”: [“权限名“]属性，即可实现保护整个Ability的目的，无指定权限的应用不能访问此Ability。
保护API：若Ability对外提供的数据或能力有多种，且开放范围或保护级别也不同，可以针对不同的数据或能力在接口代码实现中通过verifyPermission(String permissionName, int pid, int uid)来对uid标识的调用者进行鉴权。

权限使用原则

权限申请最小化。跟用户提供的功能无关的权限，不要申请；尽量采用其他无需权限的操作来实现相应功能（如：通过intent拉起系统UI界面由用户交互、应用自己生成uuid代替设备ID等）。
权限申请完整。应用所需权限（包括应用调用到的三方库依赖的权限）都要逐个在应用的config.json中按格式声明。
满足用户可知。应用申请的敏感权限的目的需要真实准确告知用户。
权限就近申请。应用在用户触发相关业务功能时，就近提示用户授予实现此功能所需的权限。
权限不扩散。在用户未授权的情况下，不允许提供给其他应用使用。
应用自定义权限防止重名。建议以包名为前缀来命名权限，防止跟系统定义的权限重名。

Android应用权限管理：

Android 将权限分为不同的类型，包括安装时权限、运行时权限和特殊权限。每种权限类型都指明了当系统授予应用该权限后，应用可以访问的受限数据范围以及应用可以执行的受限操作范围。

安装时权限

图 2. 某应用商店中显示的某个应用的安装时权限列表。

安装时权限授予应用对受限数据的受限访问权限，并允许应用执行对系统或其他应用只有最低影响的受限操作。如果您在应用中声明了安装时权限，系统会在用户安装您的应用时自动授予应用相应权限。应用商店会在用户查看应用详情页面时向其显示安装时权限通知，如图 2 所示。

Android 提供多个安装时权限子类型，包括普通权限和签名权限。

普通权限

此类权限允许访问超出应用沙盒的数据和执行超出应用沙盒的操作。但是，这些数据和操作对用户隐私及对其他应用的操作带来的风险非常小。

系统会为普通权限分配“normal”保护级别，如权限 API 参考文档页面中所示。

签名权限

当应用声明了其他应用已定义的签名权限时，如果两个应用使用同一证书进行签名，系统会在安装时向前者授予该权限。否则，系统无法向前者授予该权限。注意：有些签名权限不适合第三方应用使用。

系统会为签名权限分配“signature”保护级别，如权限 API 参考文档页面中所示。

运行时权限

图 3. 当应用请求运行时权限时显示的系统权限提示。

运行时权限也称为危险权限，此类权限授予应用对受限数据的额外访问权限，并允许应用执行对系统和其他应用具有更严重影响的受限操作。因此，您需要先在应用中请求运行时权限，然后才能访问受限数据或执行受限操作。当应用请求运行时权限时，系统会显示运行时权限提示，如图 3 所示。

许多运行时权限会访问用户私有数据，这是一种特殊的受限数据，其中包含可能比较敏感的信息。例如，位置信息和联系信息就属于用户私有数据。

系统会为运行时权限分配“dangerous”保护级别，如权限 API 参考文档页面中所示。

特殊权限

特殊权限与特定的应用操作相对应。只有平台和原始设备制造商 (OEM) 可以定义特殊权限。此外，如果平台和 OEM 想要防止有人执行功能特别强大的操作（例如通过其他应用绘图），通常会定义特殊权限。

系统设置中的特殊应用访问权限页面包含一组用户可切换的操作。其中的许多操作都以特殊权限的形式实现。

每项特殊权限都有自己的实现细节。如需查看使用每项特殊权限的说明，请访问权限 API 参考文档页面。系统会为特殊权限分配“appop”保护级别。

最佳做法

应用权限基于系统安全功能，并有助于 Android 支持与用户隐私相关的以下目标：

控制：用户可以控制他们与应用分享的数据。
透明度：用户了解应用使用了哪些数据以及应用为何访问相关数据。
数据最小化：应用仅访问和使用用户调用的特定任务或操作所需的数据。

本部分将介绍一组在应用中有效使用权限的核心最佳做法。如需详细了解如何在 Android 中使用权限，请访问应用权限最佳做法页面。

请求最少数量的权限

当用户在应用中请求执行特定操作时，应用应当只请求完成该操作所需的权限。根据您使用权限的方式，您可以通过其他方式实现应用的用例，而无需依赖于访问敏感信息。

将运行时权限与特定操作相关联

尽可能往后推迟到在应用的用例流程中请求权限。例如，如果应用允许用户向他人发送语音消息，请等到用户已导航到消息屏幕并已按下发送语音消息按钮后再请求权限。待用户按下该按钮后，应用再请求麦克风使用权限。

考虑应用的依赖项

添加某个库时，您也会继承它的权限要求。请注意每个依赖项所需的权限以及这些权限的用途。

公开透明

请求权限时，请清晰说明您要访问的内容以及访问原因，以便用户可以做出明智的决策。

以显式方式访问系统

当您访问敏感数据或硬件（例如相机或麦克风）时，请在应用中持续提供指示。此提醒可帮助用户确切了解应用何时会访问受限数据或执行受限操作。

系统组件中的权限

权限不仅仅用于请求系统功能。应用的系统组件可以限制哪些其他应用可以与您的应用交互，如介绍如何限制与其他应用的交互的页面中所述。

对比说明：

对于敏感权限，无论是Harmony还是新版本的Android都是需要动态申请。
Harmony在config.json中以”defPermissions”来描述，Android是在AndroidManifest.xml中描述。而且相对于Android，Harmony权限控制更严，通讯录不给随便读取和修改了。

Harmony受限开放的权限

受限开放的权限通常是不允许三方应用申请的。如果有特殊场景需要使用，请提供相关申请材料到应用市场申请相应权限证书。如果应用未申请相应的权限证书，却试图在config.json文件中声明此类权限，将会导致应用安装失败。另外，由于此类权限涉及到用户敏感数据或危险操作，当应用申请到权限证书后，还需按照动态申请权限的流程向用户申请授权。

权限分类名称	典型场景	权限名	说明
通讯录	社交、通讯、备份和恢复用户信息、电话拦截等	ohos.permission.READ_CONTACTS	允许应用读取联系人数据。
通讯、备份和恢复用户信息等	ohos.permission.WRITE_CONTACTS	允许应用添加、移除和更改联系人数据。

作者 east

Android, Harmony 6月 8,2021

鸿蒙Harmony和Android共享数据对比

在现在多应用互动，多屏互动的时代，共享数据在日常应用中非常多，harmony和android共享数据的机制也比较类似。

Harmony共享数据：

harmony使用Data模板的Ability（以下简称“Data”）有助于应用管理其自身和其他应用存储数据的访问，并提供与其他应用共享数据的方法。Data既可用于同设备不同应用的数据共享，也支持跨设备不同应用的数据共享。

数据的存放形式多样，可以是数据库，也可以是磁盘上的文件。Data对外提供对数据的增、删、改、查，以及打开文件等接口，这些接口的具体实现由开发者提供。

URI介绍

Data的提供方和使用方都通过URI（Uniform Resource Identifier）来标识一个具体的数据，例如数据库中的某个表或磁盘上的某个文件。HarmonyOS的URI仍基于URI通用标准，格式如下：

scheme：协议方案名，固定为“dataability”，代表Data Ability所使用的协议类型。
authority：设备ID。如果为跨设备场景，则为目标设备的ID；如果为本地设备场景，则不需要填写。
path：资源的路径信息，代表特定资源的位置信息。
query：查询参数。
fragment：可以用于指示要访问的子资源。

URI示例：

跨设备场景：dataability://device_id/com.domainname.dataability.persondata/person/10
本地设备：dataability:///com.domainname.dataability.persondata/person/10

Android共享数据：

在Android中有很多的内容提供者，包括内置的、自己编写的和他人编写的。那么，如何识别和找到需要的内容提供者呢？Android提供了一种叫做Content URI技术，通过它可以指定一个内容提供者，访问内容提供者后面的资源。

Android中的Content URI就是Android平台的内容资源定位符，与Web上的应用一样，Android平台上的Content URI定义的时候也要全球唯一，因此它的命名可以借助所在应用的包名命名，但是要注意这种命名方式不是必须的，而是推荐的命名方式。因为一个应用的包名是唯一的，不会重复的。

（1）协议名字。content是URI协议名字，content表明这个URI是一个内容提供器。类似于http://www.acme.com/icons/logo.gif中的HTTP，协议名不可以修改。

（2）权限。URI的权限部分，用来标识内容提供者，它的命名必须确保唯一性，类似于http://www.acme.com/icons/logo.gif中的www.acme.com部分。

（3）路径。用来判断请求数据类型的路径。在Content URI中可以有0个或多个路径。类似http://www.acme.com/icons/logo.gif中的icons部分。

（4）id。被指定的特定记录的id，如果没有指定特定id记录，这个部分可以省略，类似于http://www.acme.com/icons/logo.gif中的logo.gif部分。

对比说明：

从上面看,harmony和android共享数据定义的协议URI非常类似，harmony多了一个填写设备ID可用于跨屏。

作者 east

Android, Harmony 6月 6,2021

鸿蒙Harmony和Android的UI控件概览对比

Android对于UI控件，可以在xml中来写ui控件， Android 提供对应 View 类及其子类的简明 XML 词汇，如用于微件和布局的词汇。也可使用 Android Studio 的 Layout Editor，并采用拖放界面来构建 XML 布局。也可以直接在java等代码创建 View 对象和 ViewGroup 对象（并操纵其属性）。Harmony提供了Java UI框架和JS UI框架。两者的UI组件还是比较相同，都可以自定义组件。

Android的UI概览：

布局定义了应用中的界面结构（例如 Activity 的界面结构）。布局中的所有元素均使用 View 和 ViewGroup 对象的层次结构进行构建。View 通常用于绘制用户可看到并与之交互的内容。ViewGroup 则是不可见的容器，用于定义 View 和其他 ViewGroup 对象的布局结构

属性

每个 View 对象和 ViewGroup 对象均支持自己的各种 XML 属性。某些属性是 View 对象的特有属性（例如，TextView 支持 textSize 属性），但可扩展此类的任一 View 对象也会继承这些属性。某些属性是所有 View 对象的共有属性，因为它们继承自 View 根类（例如 id 属性）。此外，其他属性被视为“布局参数”，即描述 View 对象特定布局方向的属性，如该对象的父 ViewGroup 对象所定义的属性。

ID

任何 View 对象均可拥有与之关联的整型 ID，用于在结构树中对 View 对象进行唯一标识。编译应用后，系统会以整型形式引用此 ID，但在布局 XML 文件中，系统通常会以字符串的形式在 id 属性中指定该 ID。这是所有 View 对象共有的 XML 属性（由 View 类定义），并且您会经常使用该属性。XML 标记内部的 ID 语法是：

android:id="@+id/my_button"

字符串开头处的 @ 符号指示 XML 解析器应解析并展开 ID 字符串的其余部分，并将其标识为 ID 资源。加号 (+) 表示这是一个新的资源名称，必须创建该名称并将其添加到我们的资源（在 R.java 文件中）内。Android 框架还提供许多其他 ID 资源。引用 Android 资源 ID 时，不需要加号，但必须添加 android 软件包命名空间，如下所示：

android:id="@android:id/empty"

Harmony的Java UI概览：

应用的Ability在屏幕上将显示一个用户界面，该界面用来显示所有可被用户查看和交互的内容。

应用中所有的用户界面元素都是由Component和ComponentContainer对象构成。Component是绘制在屏幕上的一个对象，用户能与之交互。ComponentContainer是一个用于容纳其他Component和ComponentContainer对象的容器。

Java UI框架提供了一部分Component和ComponentContainer的具体子类，即创建用户界面（UI）的各类组件，包括一些常用的组件（比如：文本、按钮、图片、列表等）和常用的布局（比如：DirectionalLayout和DependentLayout）。用户可通过组件进行交互操作，并获得响应。

所有的UI操作都应该在主线程进行设置。

组件和布局

用户界面元素统称为组件，组件根据一定的层级结构进行组合形成布局。组件在未被添加到布局中时，既无法显示也无法交互，因此一个用户界面至少包含一个布局。在UI框架中，具体的布局类通常以XXLayout命名，完整的用户界面是一个布局，用户界面中的一部分也可以是一个布局。布局中容纳Component与ComponentContainer对象。

Component和ComponentContainer

Component：提供内容显示，是界面中所有组件的基类，开发者可以给Component设置事件处理回调来创建一个可交互的组件。Java UI框架提供了一些常用的界面元素，也可称之为组件，组件一般直接继承Component或它的子类，如Text、Image等。
ComponentContainer：作为容器容纳Component或ComponentContainer对象，并对它们进行布局。Java UI框架提供了一些标准布局功能的容器，它们继承自ComponentContainer，一般以“Layout”结尾，如DirectionalLayout、DependentLayout等。

图1 Component结构

LayoutConfig

每种布局都根据自身特点提供LayoutConfig供子Component设定布局属性和参数，通过指定布局属性可以对子Component在布局中的显示效果进行约束。例如：“width”、“height”是最基本的布局属性，它们指定了组件的大小。图2 LayoutConfig

组件树

布局把Component和ComponentContainer以树状的层级结构进行组织，这样的一个布局就称为组件树。组件树的特点是仅有一个根组件，其他组件有且仅有一个父节点，组件之间的关系受到父节点的规则约束。

Harmony JS UI框架概览：

JS UI框架是一种跨设备的高性能UI开发框架，支持声明式编程和跨设备多态UI。阅读本开发指南前，开发者需要掌握以下基础知识：

HTML5
CSS
JavaScript

关于组件和接口的详细参考文档请参见JS API参考。说明

本文档适用于手机（Phone）、平板（Tablet）、智慧屏（TV）和智能穿戴（Wearable）应用开发，针对轻量级智能穿戴（Lite Wearable）请参考轻量级智能穿戴开发。

基础能力

声明式编程JS UI框架采用类HTML和CSS声明式编程语言作为页面布局和页面样式的开发语言，页面业务逻辑则支持ECMAScript规范的JavaScript语言。JS UI框架提供的声明式编程，可以让开发者避免编写UI状态切换的代码，视图配置信息更加直观。
跨设备开发框架架构上支持UI跨设备显示能力，运行时自动映射到不同设备类型，开发者无感知，降低开发者多设备适配成本。
高性能开发框架包含了许多核心的控件，如列表、图片和各类容器组件等，针对声明式语法进行了渲染流程的优化。

整体架构

JS UI框架包括应用层（Application）、前端框架层（Framework）、引擎层（Engine）和平台适配层（Porting Layer）。

Application应用层表示开发者使用JS UI框架开发的FA应用，这里的FA应用特指JS FA应用。使用Java开发FA应用请参考《Java UI框架》。
Framework前端框架层主要完成前端页面解析，以及提供MVVM（Model-View-ViewModel）开发模式、页面路由机制和自定义组件等能力。
Engine引擎层主要提供动画解析、DOM（Document Object Model）树构建、布局计算、渲染命令构建与绘制、事件管理等能力。
Porting Layer适配层主要完成对平台层进行抽象，提供抽象接口，可以对接到系统平台。比如：事件对接、渲染管线对接和系统生命周期对接等。

作者 east

Android, Harmony 6月 6,2021

Harmony鸿蒙和Android安卓资源文件的分类对比

鸿蒙Harmoney的资源文件和Android很类似，下面做一些对比：

先来个总的概览：

Android的资源目录结构：

    res/
        drawable/
            graphic.png
        drawable-en/
        drawable-fr-rCA/
        drawable-en-port/
        drawable-en-notouch-12key/
        drawable-port-ldpi/
        drawable-port-notouch-12key/
        layout/
            main.xml
            info.xml
        mipmap/
            icon.png
        values/
            strings.xml
        drawable/

Harmoney的资源目录结构：

resources
|---base  // 默认存在的目录
|   |---element
|   |   |---string.json
|   |---media
|   |   |---icon.png
|---en_GB-vertical-car-mdpi // 限定词目录示例，需要开发者自行创建   
|   |---element
|   |   |---string.json
|   |---media
|   |   |---icon.png
|---rawfile  // 默认存在的目录

对比：目录结构差不多，都有存放图片、存放字符串的，都有配置限定字符，都是默认的目录；不同的是harmoney采用json，而不像android主要用xml来描述。

Android的限定词取值规则：

配置限定符值描述MCC 和 MNC示例：
mcc310
mcc310-mnc004
mcc208-mnc00
等等

移动设备国家代码 (MCC)，（可选）后跟设备 SIM 卡中的移动设备网络代码 (MNC)。例如，mcc310 是指美国的任一运营商，mcc310-mnc004 是指美国的 Verizon 公司，mcc208-mnc00 是指法国的 Orange 公司。

如果设备使用无线装置连接（GSM 手机），则 MCC 和 MNC 值均来自 SIM 卡。

您也可以单独使用 MCC（例如，将国家/地区特定的合法资源加入应用）。如果只需根据语言指定，则改用语言和地区限定符（稍后进行介绍）。如果决定使用 MCC 和 MNC 限定符，请谨慎执行此操作并测试限定符是否按预期工作。

另请参阅配置字段 mcc 和 mnc，二者分别表示当前的移动设备国家代码和移动设备网络代码。语言和区域示例：
en
fr
en-rUS
fr-rFR
fr-rCA
b+en
b+en+US
b+es+419

语言通过由两个字母组成的 ISO 639-1 语言代码进行定义，可以选择后跟两个字母组成的 ISO 3166-1-alpha-2 区域码（前缀用小写字母 r）。

这些代码不区分大小写；r 前缀用于区分区域码。您不能单独指定区域。

Android 7.0（API 级别 24）引入对 BCP 47 语言标记的支持，可供您用来限定特定语言和区域的资源。语言标记由一个或多个子标记序列组成，每个子标记都能优化或缩小由整体标记标识的语言范围。如需了解有关语言标记的详细信息，请参阅用于标识语言的标记。

如要使用 BCP 47 语言标记，请将 b+ 和两个字母的 ISO 639-1 语言代码连接；其后还可选择使用其他子标记，用 + 分隔即可。

如果用户在系统设置中更改语言，则语言标记可能会在应用的生命周期中发生变更。如需了解运行时应用会因此受到何种影响，请参阅处理运行时变更。

有关针对其他语言本地化应用的完整指南，请参阅本地化。

另请参阅 getLocales() 方法，了解该方法提供的已定义语言区域列表。此列表包含主要的语言区域。布局方向ldrtl
ldltr

应用的布局方向。ldrtl 是指“布局方向从右到左”。ldltr 是指“布局方向从左到右”（默认的隐式值）。

此配置适用于布局、可绘制资源或值等任何资源。

例如，若要针对阿拉伯语提供某种特定布局，并针对任何其他“从右到左”的语言（如波斯语或希伯来语）提供某种通用布局，则可提供以下资源：

res/
    layout/
        main.xml (Default layout)
    layout-ar/
        main.xml (Specific layout for Arabic)
    layout-ldrtl/
        main.xml (Any "right-to-left" language, except
                  for Arabic, because the "ar" language qualifier
                  has a higher precedence.)

请注意：如要为应用启用从右到左的布局功能，则必须将 supportsRtl 设置为 "true"，并将 targetSdkVersion 设置为 17 或更高版本。

此项为 API 级别 17 中的新增配置。smallestWidthsw<N>dp

示例：
sw320dp
sw600dp
sw720dp
等等

屏幕的基本尺寸，由可用屏幕区域的最小尺寸指定。具体而言，设备的 smallestWidth 是屏幕可用高度和宽度的最小尺寸（您也可将其视为屏幕的“最小可能宽度”）。无论屏幕的当前方向如何，您均可使用此限定符确保应用界面的可用宽度至少为 <N> dp。

例如，如果布局要求屏幕区域的最小尺寸始终至少为 600dp，则可使用此限定符创建布局资源 res/layout-sw600dp/。仅当可用屏幕的最小尺寸至少为 600dp（无论 600dp 表示的边是用户所认为的高度还是宽度）时，系统才会使用这些资源。最小宽度为设备的固定屏幕尺寸特征；即使屏幕方向发生变化，设备的最小宽度仍会保持不变。

使用最小宽度确定一般屏幕尺寸非常有用，因为宽度通常是设计布局时的驱动因素。界面经常会垂直滚动，但对其水平方向所需要的最小空间具有非常硬性的限制。可用宽度也是确定是否对手持式设备使用单窗格布局，或对平板电脑使用多窗格布局的关键因素。因此，您可能最关注每台设备上的最小可能宽度。

设备的最小宽度会将屏幕装饰元素和系统界面考虑在内。例如，如果设备屏幕上的某些永久性界面元素沿着最小宽度轴占据空间，则系统会声明最小宽度小于实际屏幕尺寸，因为这些屏幕像素不适用于您的界面。

以下是一些可用于常见屏幕尺寸的值：

320，适用于屏幕配置如下的设备：
- 240×320 ldpi（QVGA 手机）
- 320×480 mdpi（手机）
- 480×800 hdpi（高密度手机）
480，适用于 480×800 mdpi 之类的屏幕（平板电脑/手机）。
600，适用于 600×1024 mdpi 之类的屏幕（7 英寸平板电脑）。
720，适用于 720×1280 mdpi 之类的屏幕（10 英寸平板电脑）。

当应用为多个资源目录提供不同的 smallestWidth 限定符值时，系统会使用最接近（但未超出）设备 smallestWidth 的值。

此项为 API 级别 13 中的新增配置。

另请参阅 android:requiresSmallestWidthDp 属性（声明与应用兼容的最小 smallestWidth）和 smallestScreenWidthDp 配置字段（存放设备的 smallestWidth 值）。

如需了解有关不同屏幕设计和使用此限定符的详细信息，请参阅支持多种屏幕开发者指南。可用宽度w<N>dp

示例：
w720dp
w1024dp
等等

指定资源应使用的最小可用屏幕宽度（以 dp 为单位，由 <N> 值定义）。当屏幕方向在横向和纵向之间切换时，此配置值也会随之变化，以匹配当前的实际宽度。

此功能往往有助于确定是否使用多窗格布局，因为即便在使用平板电脑设备时，您通常也不希望竖屏以横屏的方式使用多窗格布局。因此，您可以使用此功能指定布局所需的最小宽度，而无需同时使用屏幕尺寸和屏幕方向限定符。

应用为此配置提供具有不同值的多个资源目录时，系统会使用最接近（但未超出）设备当前屏幕宽度的值。此处的值会考虑屏幕装饰元素，因此如果设备显示屏的左边缘或右边缘上有一些永久性 UI 元素，考虑到这些 UI 元素，同时为减少应用的可用空间，设备会使用小于实际屏幕尺寸的宽度值。

此项为 API 级别 13 中的新增配置。

另请参阅 screenWidthDp 配置字段，该字段存放当前屏幕宽度。

如需了解有关不同屏幕设计和使用此限定符的详细信息，请参阅支持多种屏幕开发者指南。可用高度h<N>dp

示例：
h720dp
h1024dp
等等

指定资源应使用的最小可用屏幕高度（以“dp”为单位，由 <N> 值定义）。当屏幕方向在横向和纵向之间切换时，此配置值也会随之变化，以匹配当前的实际高度。

对比使用此方式定义布局所需高度与使用 w<N>dp 定义所需宽度，二者均非常有用，且都无需同时使用屏幕尺寸和方向限定符。但大多数应用不需要此限定符，因为界面经常垂直滚动，所以高度需更有弹性，而宽度则应更固定。

当应用为此配置提供具有不同值的多个资源目录时，系统会使用最接近（但未超出）设备当前屏幕高度的值。此处的值会考虑屏幕装饰元素，因此如果设备显示屏的上边缘或下边缘上有一些永久性 UI 元素，考虑到这些 UI 元素，同时为减少应用的可用空间，设备会使用小于实际屏幕尺寸的高度值。非固定的屏幕装饰元素（例如，全屏时可隐藏的手机状态栏）并不在考虑范围内，标题栏或操作栏等窗口装饰亦如此，因此应用必须准备好处理稍小于其指定值的空间。

此项为 API 级别 13 中的新增配置。

另请参阅 screenHeightDp 配置字段，该字段存放当前屏幕宽度。

如需了解有关不同屏幕设计和使用此限定符的详细信息，请参阅支持多种屏幕开发者指南。屏幕尺寸small
normal
large
xlarge

small：尺寸类似于低密度 VGA 屏幕的屏幕。小屏幕的最小布局尺寸约为 320×426 dp。例如，QVGA 低密度屏幕和 VGA 高密度屏幕。
normal：尺寸类似于中等密度 HVGA 屏幕的屏幕。标准屏幕的最小布局尺寸约为 320×470 dp。例如，WQVGA 低密度屏幕、HVGA 中等密度屏幕、WVGA 高密度屏幕。
large：尺寸类似于中等密度 VGA 屏幕的屏幕。大屏幕的最小布局尺寸约为 480×640 dp。例如，VGA 和 WVGA 中等密度屏幕。
xlarge：明显大于传统中等密度 HVGA 屏幕的屏幕。超大屏幕的最小布局尺寸约为 720×960 dp。在大多数情况下，屏幕超大的设备体积太大，不能放进口袋，最常见的是平板式设备。此项为 API 级别 9 中的新增配置。

请注意：使用尺寸限定符并不表示资源仅适用于该尺寸的屏幕。如果没有为备用资源提供最符合当前设备配置的限定符，则系统可能会使用其中最匹配的资源。

注意：如果所有资源均使用大于当前屏幕的尺寸限定符，则系统不会使用这些资源，并且应用将在运行时崩溃（例如，如果所有布局资源均以 xlarge 限定符标记，但设备是标准尺寸的屏幕）。

此项为 API 级别 4 中的新增配置。

如需了解详细信息，请参阅支持多种屏幕。

另请参阅 screenLayout 配置字段，该字段指示屏幕是小尺寸、标准尺寸还是大尺寸。屏幕纵横比long
notlong

long：宽屏，如 WQVGA、WVGA、FWVGA
notlong：非宽屏，如 QVGA、HVGA 和 VGA

此项为 API 级别 4 中新增配置。

此配置完全基于屏幕的纵横比（宽屏较宽），并且与屏幕方向无关。

另请参阅 screenLayout 配置字段，该字段指示屏幕是否为宽屏。圆形屏幕round
notround

round：圆形屏幕，例如圆形可穿戴式设备
notround：方形屏幕，例如手机或平板电脑

此项为 API 级别 23 中的新增配置。

另请参阅 isScreenRound() 配置方法，该方法指示屏幕是否为圆形屏幕。广色域widecg
nowidecg

{@code widecg}：显示广色域，如 Display P3 或 AdobeRGB
{@code nowidecg}：显示窄色域，如 sRGB

此项为 API 级别 26 中的新增配置。

另请参阅 isScreenWideColorGamut() 配置方法，该方法指示屏幕是否具有广色域。高动态范围 (HDR)highdr
lowdr

{@code highdr}：显示高动态范围
{@code lowdr}：显示低/标准动态范围

此项为 API 级别 26 中的新增配置。

另请参阅 isScreenHdr() 配置方法，该方法指示屏幕是否具有 HDR 功能。屏幕方向port
land

port：设备处于纵向（垂直）
land：设备处于横向状态（水平）

如果用户旋转屏幕，此配置可能会在应用生命周期中发生变化。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理运行时变更。

另请参阅 orientation 配置字段，该字段指示当前的设备方向。界面模式car
desk
television
appliance
watch
vrheadset

car：设备正在车载手机座上显示
desk：设备正在桌面手机座上显示
television：设备正在通过电视显示内容，通过将界面投影到离用户较远的大屏幕上，为用户提供“十英尺”体验。主要面向遥控交互或其他非触控式交互
appliance：设备正在用作没有显示屏的装置
watch：设备配有显示屏，并且可戴在手腕上
vrheadset：设备正在通过虚拟现实耳机显示内容

此项为 API 级别 8 中的新增配置，API 13 中的新增电视配置，API 20 中的新增手表配置。

如需了解应用在设备插入基座或从中移除时的响应方式，请阅读确定并监控插接状态和类型。

如果用户将设备插入基座，此配置可能会在应用生命周期中发生变化。您可以使用 UiModeManager 启用或禁用其中的部分模式。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理运行时变更。夜间模式night
notnight

night：夜间
notnight：白天

此项为 API 级别 8 中的新增配置。

如果夜间模式停留在自动模式（默认），此配置可能会在应用生命周期中发生变化。在此情况下，该模式会根据当天的时间进行调整。您可以使用 UiModeManager 启用或禁用此模式。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理运行时变更。屏幕像素密度 (dpi)ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi
anydpi
nnndpi

ldpi：低密度屏幕；约为 120dpi。
mdpi：中等密度（传统 HVGA）屏幕；约为 160dpi。
hdpi：高密度屏幕；约为 240dpi。
xhdpi：超高密度屏幕；约为 320dpi。此项为 API 级别 8 中的新增配置
xxhdpi：绝高密度屏幕；约为 480dpi。此项为 API 级别 16 中的新增配置
xxxhdpi：极高密度屏幕使用（仅限启动器图标，请参阅支持多种屏幕中的注释）；约为 640dpi。此项为 API 级别 18 中的新增配置
nodpi：可用于您不希望为匹配设备密度而进行缩放的位图资源。
tvdpi：密度介于 mdpi 和 hdpi 之间的屏幕；约为 213dpi。此限定符并非指“基本”密度的屏幕。它主要用于电视，且大多数应用都不使用该密度 — 大多数应用只会使用 mdpi 和 hdpi 资源，而且系统将根据需要对这些资源进行缩放。此项为 API 级别 13 中的新增配置
anydpi：此限定符适合所有屏幕密度，其优先级高于其他限定符。这非常适用于矢量可绘制对象。此项为 API 级别 21 中的新增配置
nnndpi：用于表示非标准密度，其中 nnn 是正整数屏幕密度。此限定符不适用于大多数情况。使用标准密度存储分区，可显著减少因支持市场上各种设备屏幕密度而产生的开销。

六个基本密度之间的缩放比为 3:4:6:8:12:16（忽略 tvdpi 密度）。因此，9×9 (ldpi) 位图相当于 12×12 (mdpi)、18×18 (hdpi)、24×24 (xhdpi) 位图，依此类推。

如果您认为图像资源在电视或其他某些设备上的呈现效果不够好，进而想尝试使用 tvdpi 资源，则缩放系数应为 1.33*mdpi。例如，mdpi 屏幕的 100px x 100px 图像应相当于 tvdpi 屏幕的 133px x 133px 图像。

请注意：使用密度限定符并不表示资源仅适用于该密度的屏幕。如果没有为备用资源提供最符合当前设备配置的限定符，则系统可能使用其中最匹配的资源。

如需详细了解如何处理不同屏幕密度以及 Android 如何缩放位图以适应当前密度，请参阅支持多种屏幕。触摸屏类型notouch
finger

notouch：设备没有触摸屏。
finger：设备有一个专供用户通过手指直接进行交互的触摸屏。

另请参阅 touchscreen 配置字段，该字段指示设备上的触摸屏类型。键盘可用性keysexposed
keyshidden
keyssoft

keysexposed：设备拥有可用的键盘。如果设备启用了软键盘（不无可能），那么即使用户未找到硬键盘，或者该设备没有硬键盘，也可使用此限定符。如果未提供或已禁用软键盘，则只有在配备硬键盘的情况下才可使用此限定符。
keyshidden：设备具有可用的硬键盘，但其处于隐藏状态，且设备未启用软键盘。
keyssoft：设备已启用软键盘（无论是否可见）。

如果您提供了 keysexposed 资源，但未提供 keyssoft 资源，则无论键盘是否可见，只要系统已启用软键盘，其便会使用 keysexposed 资源。

如果用户打开硬键盘，此配置可能会在应用生命周期中发生变化。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理运行时变更。

另请参阅配置字段 hardKeyboardHidden 和 keyboardHidden，二者分别指示硬键盘的可见性和任一键盘（包括软键盘）的可见性。主要的文本输入法nokeys
qwerty
12key

nokeys：设备没有用于文本输入的硬按键。
qwerty：设备拥有标准硬键盘（无论是否对用户可见）。
12key：设备拥有 12 键硬键盘（无论是否对用户可见）。

另请参阅 keyboard 配置字段，该字段指示可用的主要文本输入法。导航键可用性navexposed
navhidden

navexposed：导航键可供用户使用。
navhidden：导航键不可用（例如，在密封盖子后面）。

如果用户显示导航键，此配置可能会在应用生命周期中发生变化。如需了解这会在运行时期间给应用带来哪些影响，请参阅处理运行时变更。

另请参阅 navigationHidden 配置字段，该字段指示导航键是否处于隐藏状态。主要的非触摸导航方法nonav
dpad
trackball
wheel

nonav：除了使用触摸屏以外，设备没有其他导航设施。
dpad：设备具有用于导航的方向键。
trackball：设备具有用于导航的轨迹球。
wheel：设备具有用于导航的方向盘（不常见）。

另请参阅 navigation 配置字段，该字段指示可用的导航方法类型。平台版本（API 级别）示例：
v3
v4
v7
等等

设备支持的 API 级别。例如，v1 对应 API 级别 1（装有 Android 1.0 或更高版本系统的设备），v4 对应 API 级别 4（装有 Android 1.6 或更高版本系统的设备）。如需了解有关这些值的详细信息，请参阅 Android API 级别文档。

Harmony的限定词取值规则：

限定词类型	含义与取值说明
移动国家码和移动网络码	移动国家码（MCC）和移动网络码（MNC）的值取自设备注册的网络。MCC后面可以跟随MNC，使用下划线（_）连接，也可以单独使用。例如：mcc460表示中国，mcc460_mnc00表示中国_中国移动。详细取值范围，请查阅ITU-T E.212（国际电联相关标准）。
语言	表示设备使用的语言类型，由2~3个小写字母组成。例如：zh表示中文，en表示英语，mai表示迈蒂利语。详细取值范围，请查阅ISO 639（ISO制定的语言编码标准）。
文字	表示设备使用的文字类型，由1个大写字母（首字母）和3个小写字母组成。例如：Hans表示简体中文，Hant表示繁体中文。详细取值范围，请查阅ISO 15924（ISO制定的文字编码标准）。
国家或地区	表示用户所在的国家或地区，由2~3个大写字母或者3个数字组成。例如：CN表示中国，GB表示英国。详细取值范围，请查阅ISO 3166-1（ISO制定的国家和地区编码标准）。
横竖屏	表示设备的屏幕方向，取值如下：vertical：竖屏horizontal：横屏
设备类型	表示设备的类型，取值如下：phone：手机tablet：平板car：车机tv：智慧屏wearable：智能穿戴
颜色模式	表示设备的颜色模式，取值如下：dark：深色模式light：浅色模式
屏幕密度	表示设备的屏幕密度（单位为dpi），取值如下：sdpi：表示小规模的屏幕密度（Small-scale Dots Per Inch），适用于dpi取值为(0, 120]的设备。mdpi：表示中规模的屏幕密度（Medium-scale Dots Per Inch），适用于dpi取值为(120, 160]的设备。ldpi：表示大规模的屏幕密度（Large-scale Dots Per Inch），适用于dpi取值为(160, 240]的设备。xldpi：表示特大规模的屏幕密度（Extra Large-scale Dots Per Inch），适用于dpi取值为(240, 320]的设备。xxldpi：表示超大规模的屏幕密度（Extra Extra Large-scale Dots Per Inch），适用于dpi取值为(320, 480]的设备。xxxldpi：表示超特大规模的屏幕密度（Extra Extra Extra Large-scale Dots Per Inch），适用于dpi取值为(480, 640]的设备。

对比说明：

还是很类似，比如语言、横竖屏，android发展年数比较久，规则和完档相对多些。而harmony强大之处是支持万物互联，比android多了一些支持设备。

作者 east

Mysql线上环境遇到的坑