[文章]

HDC2021技术分论坛：进程崩溃/应用卡死，故障频频怎么办？

作者：jiwenqiang，DFX技术专家

提到开发一个产品，我们通常首先想到的是要实现什么样的功能，但是除了功能之外，非功能属性也会很大程度上影响一个产品的体验效果，比如不定时出现的应用卡死、崩溃现象。那为什么有的系统故障频频，有的却很少出现这些问题呢，这就不得不提到我们今天的主角DFX了。

一、什么是DFX？

DFX是早在1960~1970年代就出现的产品设计理念，但是对于不少开发者而言，这是一个陌生的概念，什么是DFX？所谓DFX（Design For X），是指产品的非功能属性设计，其中的X代表产品的某个特性或者产品生命周期的某个阶段。

从下面的图可以看出，产品的非功能属性是非常丰富的，它们直接影响产品的质量、效率、成本等这些长期核心竞争力。

图1 产品DFX

在过去的几年里，华为软件的交付效率和质量一直在不断提高，每个软件大版本相较于上个版本交付时间在不断缩短，故障率也有大幅降低，这些提升的背后，DFX起到了很重要的作用。

随着业界认识的深入，DFX逐渐成为了卓越产品设计的基石以及头部企业产品设计开发的基础设施，因此现在对DFX又有了另一种解释，即“Design For eXcellence”，面向卓越的设计。

二、什么是操作系统DFX？

现在我们了解了DFX的概念，也知道DFX设计对产品来说异常重要，因此我们在设计HarmonyOS的时候，坚持将DFX的理念带了进来，使其成为操作系统的公共基础设施，使能高质量卓越产品的设计、实现、测试和维护。通过对应用程序、设备产品这些操作系统所服务的对象进行考察，我们归纳出系统所能提供的非功能需求，并从中提炼出公共、基础的DFX框架加入到HarmonyOS中，这就产生了操作系统DFX。开发者在使用HarmonyOS的过程中，可以根据产品需要直接使用或灵活拓展这些DFX能力。

图2 操作系统DFX

看到这里，大家可能会觉得，操作系统DFX不就是将产品DFX的能力拷贝到操作系统中吗。其实不然，操作系统DFX相较于产品DFX有两个显著的不同点：

由于操作系统不是为某类产品所专门定制的，而是一个全栈、公共的基础设施，因此操作系统DFX主要聚焦记录、诊断、恢复、观测、剖析、维护和服务等开发产品所需要的公共能力。
操作系统DFX更多地关注开发者和设备商的开发体验，以帮助他们设计出更卓越的产品为目标。

三、HarmonyOS对DFX能力的要求

既然操作系统DFX是为了使能开发者开发出更卓越的产品，而HarmonyOS中也加入了DFX框架和能力，那么大家一定很好奇，HarmonyOS中的DFX是什么样的？DFX能为HarmonyOS带来些什么呢？在回答这些问题之前，我们先来看一下HarmonyOS对DFX能力的要求。

几乎所有的操作对DFX的要求都包含以下三方面：

轻量有效：系统资源开销少，易用易学习，精准有效。
基础通用：关键、基础、通用、易扩展，方便开发者裁剪和增强。
覆盖全面：全面服务应用和设备品类，全面服务开发者和设备商，全面覆盖产品全生命周期。

HarmonyOS除了这些基本要求外，还对DFX提出了新的要求：

我们知道，HarmonyOS是面向超级终端的系统，而不同超级终端的资源可能是差距巨大的，比如有的富设备提供的资源为RAM 8GB、ROM 512GB，而有的瘦设备却只有RAM 128KB、ROM 2MB。面对这么大的资源差异，HarmonyOS对DFX提出了支持全栈多语言、可大可小、灵活部署的要求。

除了面向超级终端，HarmonyOS的另一大特色是其丰富的分布式超级终端场景支持能力，因此HarmonyOS要求系统的DFX能力要能够支持分布式场景，比如分布式的日志、分布式跟踪、分布式调试调优等等。

图3 HarmonyOS对DFX能力的要求

四、HarmonyOS DFX框架与能力

通过上面的介绍，相信大家已经对操作系统DFX的概念有了一定的了解，那么我们现在开始进入正题，给大家介绍一下HarmonyOS DFX的框架与能力。

图4 HarmonyOS DFX框架和能力全景图

图4的全景图中间褐色部分为HarmonyOS DFX所提供的能力。

HarmonyOS DFX提供了以下能力：

（1）记录能力：提供了轻量的日志、事件和跟踪功能，可以将程序运行的轨迹记录下来，为后续分析度量奠定基础。

（2）故障管理能力：提供精准有效的故障检测、定位和恢复能力。

（3）观测剖析能力：提供了统一便捷的观测与剖析工具，主要包含信息导出、信息分析和联动调试能力。

那么这些DFX能力的作用又是什么呢？从全景图中代表DFX的中间部分与周边的关系可以看出，DFX的这些能力不仅需要为操作系统的其他子系统提供服务，其更重要的使命是支撑影音娱乐、智慧出行等软件应用以及“1+8+N”等硬件设备。除此之外，这些能力也是产品开发运维工具链的基础，需要支撑开发调试的IDE工具以及产品运维大数据分析平台的构建。

在了解了HarmonyOS DFX的框架之后，我们知道HarmonyOS DFX主要包含日志、事件、跟踪、故障管理、观测剖析这5部分。日志、事件和跟踪体现了DFX的记录能力，故障管理能够帮助开发者快速定位和发现问题，而观测剖析则是通过一系列工具，帮助开发者在集成的环境下使用这些DFX能力。接下来我们就来逐个看看HarmonyOS中所具备的这些DFX能力。

1. 日志（HiLog）

日志通常被视为最简单的功能，但是在开发者使用日志的过程中，有两个比较明显的问题，一个是滥打日志现象，另一个是随着软件规模和组织规模的扩大，系统日志杂乱、流量超大的问题越来越严重，不仅容易泄露隐私，甚至连开发者想查看自己的日志都变得愈发困难。针对这两个问题，HarmonyOS DFX设计了一套全新的日志功能——HiLog。下面是HiLog的示意图。

图5 日志（HiLog）

从上图可以看出，HiLog不仅提供了支持JS/Java/C/C++多语言的日志采集功能，还着重在日志分类查询、流量控制和隐私处理上做了专门设计。下面我们逐个看看这些设计。

（1）分类查询

为了解决日志杂乱、不便查看的问题，HiLog对于不同级别的日志进行了分类，提供分级查询日志的命令。并且除了可以按照级别（Level）、类型（Type）、标签（Tag）查看日志，还提供了按照领域（Domain）查看日志的命令。所谓领域是指跨软件栈层次的业务垂域。那么我们为什么要按照领域查看日志呢？我们设想一下以下场景：Camera功能领域包含应用、服务和驱动，开发者如果想从一堆日志中过滤出Camera领域的日志，是没有功能支持的，用老的过滤方法是不行的。为此，我们给需要的领域定义了DomainID，通过领域过滤来解决这个问题。

（2）流量控制

通过分类查询，我们解决了日志查看不便的问题，但是超量的日志也会对系统性能产生巨大影响，根据经验，如果把系统中所有日志全部都打开，严重的情况下系统的性能可能会下降至70%。那么该如何解决日志超量的问题呢？

HiLog通过对不同领域的日志总量进行流控来解决这个问题，在采集日志时，记录每个领域的日志总量，识别出超过阈值的领域，然后对该领域的超量日志进行控制。其中对超量日志的处理在调试（Debug）和商用（Release）两种模式下有不同的处理策略：在Debug模式下，会提示超量日志，但不会真的丢弃超量日志。而在Release模式下，会将超量的日志丢弃并打印一条日志丢弃的提示。

图6 流量控制的两种模式

（3）隐私管控

除了查询不便和超量日志问题，日志的隐私管控也需要引起重视。在我们开发调试的过程中，经常会倾向于打印更多的信息，这就很有可能将用户隐私信息也打印出来，比如姓名、访问的URL地址等。而现在对于隐私泄露的处罚是比较严厉的，欧盟的《通用数据保护条例》（General Data Protection Regulation，简称GDPR）针对隐私泄露最高罚款2千万欧元或年度营业额的4%，因此，我们在日志打印的时候需要非常谨慎，不能将用户隐私打印到日志里。

为了对隐私安全进行管控，HiLog提供了变量打印控制功能，开发者可以通过格式化字符{private}或{public}灵活对变量内容进行声明，如果声明为{private}，则表示该变量为隐私变量，在Release模式下会隐藏这些隐私的变量内容，而对于不需要管控的变量，则可用{public}来指明，不进行隐藏。

图7 HiLog的变量打印控制

2. 事件（HiView）

除了日志以外，HarmonyOS DFX对事件也提供了记录能力，并为此设计了一套全新的事件框架（HiView）。

图8 事件框架HiView

我们知道，事件可能来源于应用，也可能来源于系统，因此HiView框架分为系统事件框架和应用事件框架两个部分。每个部分都提供了事件采集接口，系统事件框架使用HiSysEvent接口，应用事件框架使用HiAppEvent接口。除此之外，HiView还提供了灵活的订阅查询接口，可以为后端处理者分享采集到的事件。该接口的应用场景有很多，比如IDE可以通过此接口订阅事件，从而在调试界面上呈现事件，而系统厂商也可以通过此接口订阅事件，再进行定制化处理。

另外，HiView还对系统事件框架的处理逻辑做了插件化设计，通过在HarmonyOS上配置和部署系统插件，可以实现对不同大小终端设备的灵活适配。

3. 跟踪（HiTrace）

接下来，我们来看一下HarmonyOS DFX的最后一项记录能力——跟踪。

由于HarmonyOS是面向超级终端的系统，因此除了像常规操作系统那样跟踪应用间、进程间的交互过程，还需要具备跨设备跟踪程序交互过程的能力。在HarmonyOS中，这种分布式跟踪的能力由HiTrace提供，而HiTrace通过TraceID的传递来对整个业务链进行跟踪。TraceID不仅能够在APP、Native、Kernel之间跨层传递，还能够跨进程、甚至跨设备传递。值得一提的是，HiTrace是一种轻量级的跟踪机制，在Wi-Fi条件下仅仅会增加微秒级延迟，而这种延迟对系统来说影响是非常小的。

图9 HiTrace分布式跟踪

4. 故障管理

除了上面介绍的一些记录能力，故障管理也是HarmonyOS DFX的一项重要能力。为了帮助开发者快速定位和发现问题，HarmonyOS DFX在系统侧部署了全量、精准的故障检测机制，包含7类单系统故障检测器（进程崩溃、应用卡死、资源泄露、踩内存、整机重启、不开机和系统死机）和1类分布式故障检测器，通过这些检测器，故障检测率可以达到80%以上。为了满足HarmonyOS面向超级终端的特性，这些故障检测器还可以在不同设备上根据资源灵活进行部署。

图10 故障检测器

由于篇幅原因，下面我们重点对这7类故障检测器中的进程崩溃检测器、应用卡死检测器以及系统死机检测器进行介绍：

（1）进程崩溃检测器

说到进程崩溃大家一定都不陌生，这是一种最常见的故障，对此的检测机制也都比较成熟，但当前的检测机制还存在着一些问题，比如，应用进程无法直接获取自己进程相关的崩溃日志，崩溃日志包含很多无效信息、重复信息，以及抓取崩溃调用栈失败等。为了解决这些问题，HarmonyOS DFX对其提供的进程崩溃检测器做了以下特殊设计：

支持Java/JS/Native全栈检测。
开放专门的API给应用进程查询自己进程的崩溃日志，能且只能获取自己进程的崩溃信息，解决了应用无权获取自己崩溃日志的问题。
通过对崩溃日志信息的去重，删除了很多的无效信息，帮助开发者更加准确地定位信息。
支持同时抓取多个进程的调用栈，避免抓取日志不全的问题，保证更准确地还原故障现场。

（2）应用卡死&系统死机检测器

应用卡死和系统死机也是比较常见的故障，它们一般概率性发生，但是严重影响用户体验。检测这类问题的难点在于，如何将软件故障与用户感知的死机故障做有效匹配，如果所有软件bug都上报，开发者会无从下手，而如果漏检了则又无法准确定位。为此，HarmonyOS DFX对应用卡死&系统死机检测器，做了以下特殊设计：

在系统中部署了32个检测点，全面检测软件死机故障。
另外增加了4个用户行为检测点，准确检测用户对死机现象的反应。

这些部署的检测点支持根据不同设备的故障模式灵活部署，如果我们的设备没有屏幕，那么就不用去部署亮灭屏超时及快速点击屏幕检测点。除了测点，判决规则也能够根据故障检测结果的大数据分析动态进行调整。通过上述优化，死机故障检测率从30%提升到了80%。

图11 应用卡死&系统死机检测

5. 观测剖析

看到这里，大家或许会有个疑问，开发者如何才能使用HarmonyOS DFX所提供的这些日志、事件、跟踪和故障管理能力呢？那接下来我们就来介绍一下我们的观测剖析工具，这些工具可以帮助开发者分析定位问题、调试调优。

（1）信息导出工具（HiDumper）

开发者在开发、调试、测试、维护等过程中，需要频繁观测系统的各种信息，一般这些观测信息都是通过信息导出来获得。虽然通常操作系统都会提供各类信息导出工具，但是这些工具之间可能规则差异很大，并且很难对自动化测试工具或IDE进行适配。随着产品种类的增加，系统要导出的信息也变得异常丰富，信息导出接口多、能力杂，适配难的问题也更加凸显。

为了避免上述信息导出问题，HarmonyOS提供了统一的系统信息导出工具HiDumper，相比于其他信息导出工具，HiDumper对命令参数进行了统一的规格化管理，并对所有导出信息进行分类、调度和输出，减少了后端工具的适配难度。

图12 信息导出工具HiDumper

（2）分布式联动调试工具

目前的APP调试一般都是使用本地调试器，每个待调试设备需要一套独立的调试终端和IDE工具，这显然不能很好地支持需要多设备之间联动调试的分布式业务场景。为了应对这种场景，HarmonyOS全新开发了分布式联动调试工具，将跨设备的日志、事件、跟踪及故障日志在同一个IDE调试窗口进行关联展示，给开发者类似单设备调试的窗口体验。IDE运行时能自动捕获异常信息，通过异常信息关联出相关的事件列表和流水日志，再通过异常日志能准确定位到代码行，大大提高调试效率。

图13 分布式联动调试

（3）分布式调优工具

在介绍完观测和调试工具之后，最后我们再来看一下调优工具。HarmonyOS新开发的分布式调优工具，能准确全栈跟踪JS/Java/C/C++等多语言调用链，记录跨线程、跨进程、跨设备等不同颗粒度的活动，生成规格化的HiTrace文件。通过将HiTrace文件在IDE图形化工具中展示，开发者可以很便利地分析分布式应用性能瓶颈。