https://www.zhihu.com/question/425726667/answer/1525039692

我不觉得是弯路，毕竟对于多数的项目来说，写得爽比线上崩溃一两次要重要得多。

先说一下题主提到的第二点，

2) 异常处理强制了进行动态类型识别，这是一种额外的开销（虽然并不大）

题主指的应该是在异常发生时对异常对象的动态类型转换？其实这也可以看作异常处理的优势：在没有异常发生时，不需要这种额外开销。通过返回值（包括返回 Result）传递错误，由于存在更多的分支，给编译器优化、分支预测、指令 Cache 带来了负面影响；而异常通常只需要在栈上多开一点点空间（用来存放异常处理指针）。从性能上说，虽然在异常发生时它的性能要低于返回值，但在正常执行时，异常反而存在优势。

至于题主说的第一点，

许多时候面对一个子函数调用，我们可能无法知道它是否会抛出异常（当然有些语言有异常规格说明，但其实形同虚设），这导致有些时候当我们错误地假定函数不会抛出异常时，就会出现资源泄漏。写出强异常安全的代码在try-catch显得很隐晦，因而困难。

这就要说到异常的分类了。包括 C++ 和 C# 在内的很多语言，使用的都是 Unchecked Exception；而 Java 用的是 Checked Exception （除了 RuntimeException 之外）。题主谈到的，确实是 Unchecked Exception 的弊病。在我看来，Unchecked Exception 其实是最不靠谱的那种。如果一门语言使用的是 Checked Exception，那么理论上在编写强安全的代码时，难度应该与使用返回值/Result的语言没有差别。

然而，使用 Checked Exception 的 Java 被吐槽最多的，正是它的异常处理。很奇怪吧？Java设计出checked exception有必要吗？

但正如 Andrew 在一篇采访 The Trouble with Checked Exceptions 中所说，在某些时候（比如应用开发），大多数人并不关心如何处理异常，他们只关心当异常发生时我要处理好后事（C# 的 using），剩下的事就交给最上层的 catch 去做好了。这是大家喜欢 Unchecked Exception 的原因。

Unchecked Exception 很烂，但是大家就是喜欢，毕竟懒是人类的天性。

所以，一些项目会禁用 C++ 的异常，甚至不惜自己魔改一套不用异常的 STL，尤其是那些偏底层的、关键的、崩溃代价很高的项目。而大多数人做的并不是这样的项目，写得爽比线上崩溃一两次要重要得多。

题主说的第三点，

许多基于try-catch的编程语言，并不完全强制用户处理所有异常，这带来了便捷，但却又使得程序员会忽略一些本该处理的异常。

这也主要是 Unchecked Exception 的问题。对于不支持 Option/Result 的语言（比如 C 和 go），如果使用返回值的方式，其实同样会导致程序员忽略处理错误。

---

Rust 以及很多函数式语言的 Option/Result 确实也是我目前最喜欢的错误处理模型了。理论上，一门语言可以完全屏蔽它在底层对错误的处理方式，比如看起来是使用返回值，其实是抛了异常；或者看起来像是抛了异常，其实只是返回了一个值。因为它们只是两种不同的错误处理方式，所提供的能力是一致的；语言具体怎么表达，才是最影响用户编程体验的。我知道的唯一一个后者就是 Haskell，它让你有一种在使用传统的 try/catch 的错觉。

很多使用异常的语言对 try/catch 的支持还有其他的问题，比如语法不够简洁、处理粒度不够细等等。

另外再次推荐一下这篇文章（长文警告）：Joe Duffy – The Error Model​

以及我的翻译：dontpanic：错误模型 – The Error Model​

Firefox 的 logo 上趴着的不是 Fox，而是一只小熊猫！！

…they opted for an animal that was not well known on the web at the time. It was the red panda. Unfortunately, people thought that the animal on the Mozilla Firefox logo was a fox. This “firefox” is actually a red panda which is a protected species in Asia. A mistake when translating red panda from Chinese to English is how we got firefox.

The Story Behind the Mozilla Firefox Logo (freelogodesign.org)

Firefox 官推大概是最大的小熊猫粉丝聚集地，官推经常发一些萌萌哒小熊猫吸粉（划掉）

不过从 Firefox 取名的历程来说（Phoenix 到 Firebird 再到 Firefox），Mozilla 一开始估计还是把它当作狐狸的，官方（或者是小编）对于它到底是狐狸还是小熊猫有时表现得很暧昧，比如这里又说它是狐狸：

不管了，反正小熊猫这么可爱，就钦定它是小熊猫了！

假期去成都熊猫基地，一直小熊猫刚好从我脚边溜过，简直萌到爆炸 (●’◡’●)

---

另外小熊猫不是小浣熊，它们长得不一样：

认真你就输啦 (?ω?)ノ- ( ゜- ゜)つロ​www.acfun.cn

这是我的两篇知乎文章 https://zhuanlan.zhihu.com/p/234397497 和 https://zhuanlan.zhihu.com/p/243981657 的合辑。

---

最近因为个人问题一直又烦又颓，知乎一直没什么动态，连 OpenPal3 都几个月没更新了。但是从昨晚开始好几个小号想过来打我的脸，原因是我一年之前回答了这个问题：为什么很多人不相信鸿蒙系统是真的？​

姑且不说你们搞清楚我讽刺的点在哪没有，请问你们可以拿现在的剑去圆去年前年吹的 b 吗？作为一个程序员，始终对华为终端在软件上的吹逼行为十分讨厌。而且花粉们似乎已经接受了这样的现实，还觉得“大嘴吹过的皮全都实现了”。这种空手套沸腾的行为，不是华为还真不敢干。论营销，你以为华为在负一层，其实他在第五层。这些人搞得我心态爆炸真的烦，我就想看看鸿蒙 2.0 到底是个什么东西。

一开始大家说华为电视上的鸿蒙 1.0 是安卓套壳，很多人纷纷跳出来说“adb 说明不了问题”，颇有见到胳膊就想到大腿的意味；后来又改了话术，说“按照路线图，1.0 就是安卓套壳。怎么了？”。那按照路线图，请问 2.0 就应该不是安卓套壳吧？

DevEco Studio

所以我去下了 DevEco Studio。需要注意的是，DevEco Studio 并不是新做的，华为之前就有这个东西，是开发安卓的：文档中心​

我一开始就找错了，这个是1.0。2.0 把安卓的支持“删掉”了，换成了鸿蒙。当然这都没什么问题，用 IDEA 二次开发也没什么问题，只是预防海军把 DevEco 拿来作为鸿蒙早就存在的论据。

工程方面现在支持新建电视、智能手表和半智能手表（个人归类，不喜你对）。电视和智能手表支持 Java 和 Javascript，半智能手表只支持 Javascript。比较关心电视的 Java 实现，所以新建了这个。

package com.example.myapplication;

import com.example.myapplication.slice.MainAbilitySlice;
import ohos.aafwk.ability.Ability;
import ohos.aafwk.content.Intent;

public class MainAbility extends Ability {
    @Override
    public void onStart(Intent intent) {
        super.onStart(intent);
        super.setMainRoute(MainAbilitySlice.class.getName());
    }
}

Emmmm…. 虽然我不做安卓，但是很久以前学过一点。这好像跟 Activity 有点像？不过也没关系，毕竟（做）好的 API 设计拿来用用，也不是不行。

下面我就想去看看 Ability 的代码。SDK 里面包含的全是 Stub，我去 OpenHarmony 上也没找到 aafwk 的源代码。只找到了 aafwk-lite，但这个明显不是电视上用的版本。各位海军请不要再随便丢一个链接过来说“鸿蒙已经开源了链接在这你还不服吗”，你们自己有去看过吗？还烦请哪位大佬找到了 aafwk 的源码的话留个言。

模拟器运行

找不到就算了，DevEco 还有一个 HVD 管理器，我想这既然模拟器都有，里面运行时肯定是全的吧？

不过这个 Manager 还需要下一些包才能运行，下载一直磕磕绊绊的出问题。这也导致我现在才把模拟器抱起来。

运行模拟器需要登录华为账号？也罢毕竟我以前用过荣耀手机，华为账号还是有的。然后实名注册了一波回来发现，模拟器运行每次限时 1 小时？大概各位也能猜到了，这模拟器其实是跑在服务器上的，界面再串流串回来！

这就堵住了我想看看模拟器里面内容的想法。也行，我先把 Hello World 跑起来吧。跑了 HelloWorld 起来之后，很快就会有 log 打出来。这个也有别人发过了，各位估计也见过：

嗯？

如果你随便下个断点，还能看到更具体的：

嗯？×2

点开 .shadow class，还可以看到：

可能有点看不清，我贴过来：

嗯？×3

dalvik 出现。以及，编译生成的 hap 是个 zip 吗？

嗯？×4

既有 dex 又有 apk，我们把 apk 再解一下，看看究竟是不是大白腿：

嗯？×5

半智能手表

上面也提到过，半智能手表只能使用 Javascript 开发，这是与电视和智能手表不同的地方。其实它们还有另一个不同之处，就是电视和智能手表支持由在服务器上串流调试，但是半智能手表不行。而且它连本地的模拟器（Emulator）都没有，只有一个用 Node 做的 Simulator：

华为目前开源出来的代码，都是 Lite 版本，是基于它 2016 年就开源了的 LiteOS 做的。所以有理由相信，现在只有半智能手表会用 LiteOS 版本的鸿蒙。而且现在连完整的模拟器都没有，只能用 nodejs 顶一下。

结语

所以我觉得到这里可以大胆地做出结论了：

电视和智能手表上，完全就是安卓套壳；只有半智能手表，是华为在它 16 年开源出来的 LiteOS 的基础上做出来的。

以华为在嵌入式领域的积累，花一年多做成 LiteOS + 半智能手表这样的进度是合理的。这个答案 如何看待 9 月 10 日华为发布的鸿蒙 OS 2.0 系统，应用前景如何？

里有一段话，我想摘录在这里：

华为本来有两个选择：
1. 我们被美国制裁了，我们别无他法，我们决心从现在开始，用3到5年的时间，自主研发我们的一套体系，摆脱对美依赖；
2. 我们被美国制裁了，但是我们早就做好了准备，已经掏空安卓，随时能拿出鸿蒙来替代，引起一片沸腾；然后顶着沸腾、质疑和嘲讽暗戳戳的加班加点3到5年，终于拿出东西来。
我始终搞不懂的是，为什么华为选择了方案2，因为华为高管喜欢沸腾？
两种选择反映的其实是一家公司的做事态度，反映的是它的诚信度和责任感。

作者：世界树的影子
链接：https://www.zhihu.com/question/420404904/answer/1465210355
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

说实话，要是我的老板把牛逼吹出去了（难听点说就是造假），但我现在的代码做不到，我会脸上滚烫，生怕谁过来问我说“这个 Feature 是还有问题吗？这里是还有 Bug 吗？”。不知道华为的程序员会不会如此。如果也是这样，我能做的也只是摸摸他们受伤的心灵了。

海军还要如何吹？

我也想了一下，海军还能怎么吹呢？

• 不管，就是打你的脸了！鸿蒙真的存在！
• 看到 apk 就想到安卓？鸿蒙兼容安卓，这不是很正常吗？
• 你知道做操作系统多难吗？不用一些开源的东西，你能做出来？
• 按照路线图，鸿蒙 2.0 就是这个样子，3.0 明年见。
• 我只能说鸿蒙是中国的希望

当然，具体鸿蒙是什么里子他们是不会管的，华为是不是吹牛逼他们也不会管的。要是华为不吹了，他们大概反而会失落吧。

---

距离 9 月 10 号已经过去很多天了，鸿蒙的开水终于逐渐平息。我在 上一篇文章 （饱含了对沸腾人民、沸腾现象的愤怒情绪）中最后的总结是：

电视和智能手表上，完全就是安卓套壳；只有半智能手表，是华为在它 16 年开源出来的 LiteOS 的基础上做出来的。

如果你还对现在电视上的鸿蒙心存幻想，觉得鸿蒙不是安卓、觉得鸿蒙是在兼容安卓、觉得安卓是鸿蒙的子系统，这篇文章会更加清楚明白地告诉你真相；如果你认可了鸿蒙是安卓套壳，那么这篇文章会从技术角度探究一下，这层壳到底有多厚。

HDC：鸿蒙版的 ADB

前两天刷 IT 之家，刚好刷到这篇帖子：[系统] 鸿蒙2.0：API/SDK逆向-模拟器鉴赏-LiteOS对比

原来用鸿蒙版的 adb，是可以直接连上 Shell 的… root 之后读取 build.prop，证实了系统就是安卓 10。随便看看，还有大量的安卓包、动态库、目录结构什么的，也能够佐证。

既然能登上 Shell，那也就可以把运行时拉下来，看看鸿蒙的运行时到底是什么样子的。

boot-zframework.z.vdex

直接

grep -Rl ohos /system

看下来一圈，猜测 /system/framework/boot-zframework.z.vdex 就是鸿蒙的 Java 运行时，pull 下来一看确实是。vdex 叫做 pre-validated DEX，是安卓新引进的格式。可以用下面的工具anestisb/vdexExtractor​

把 vdex 转换回普通的 dex（转换完会有两个 dex）。直接扔进 jadx 就可以反编译了：

如果跟 SDK 对比一下，会发现很多 SDK 中不存在的类使用了安卓的包。从设计上，大多是使用了 Delegate/Proxy/Adapter 避免了上层代码直接依赖安卓，这也是屏蔽实现细节的常用手段。不难看出，虽然华为在 SDK 剔除掉了安卓的依赖，但现在鸿蒙仍然是在安卓之上做的封装。

鸿蒙的分布式特性

在继续分析这层壳的薄厚之前，我觉得有必要先说一下鸿蒙的分布式特性。看了一圈代码下来，是能够感觉到鸿蒙有自己的设计和想法的。这一段完全来自我对反编译代码的理解，未必完全正确，也代表不了鸿蒙真正的思路。

基本想法是：把 API 做成 RPC Call。

鸿蒙的 Ability，比安卓的 Activity 概念要宽泛一些，更像是一个 Service。比如 Wifi Device 是一个 Ability，Wifi Enhancer 是一个 Ability，Wifi HotSpot 也是一个 Ability，另外还会有一个 Registra 来做服务注册和查询。具体这些 Ability 是由谁提供的不是很重要，毕竟都是 RPC Call，理论上不在本机也可以。在 SDK 这一侧，这些功能会被包装成普通的 API。

当然这些都不是新概念，老旧的 COM 就已经可以统一 RPC Call 和本地 Call、也连带提供服务注册和查询。后端上这种微服务架构也比较常见。不过，把操作系统的 API 也做成这种结构，我确实不清楚现在有其他的系统在做。

鸿蒙的壳，有厚有薄

运行时里面包含了很多的组件，完成度各不相同。我把它们大致归为四类，从上到下完成度递减：

1. 已经按照上面的设计，做完了 RPC 封装、在 Java SDK 和 Service 一侧都不再依赖安卓组件
2. Java SDK 一侧已经不再依赖安卓，用 JNI 调用了自己封装的 native library，但是在 native 一侧仍然需要依赖安卓
3. Java SDK 一侧还是需要依赖安卓组件，但是也有依赖自己封装的 native library
4. 安卓 API 映射大法

我没有全部看完所有组件。目前看的组件里，只有部分相对较轻、比较独立包能够做到第一类（比如 wifi 和 bluetooth），大多组件都是第二和第三类（包括 Ability/AbilityShell/Agp/Usb等等）。第四类也有，典型的比如 os.ProcessManager。

先举一个第一类的例子吧，比如 WifiEnhancer:

这是个单例，在新建对象的时候会把需要的 AbilityId 传进去存起来。API 都是 Message Passing：

在每个函数最后的 request 里，会使用 AbilityId 去 Registra 里面找相应的 Ability 缓存起来，然后直接对他 Rpc call。

再举个第二/第三类的例子吧：Agp 是华为自己的自绘组件库，封装了常见的 UI 组件和自绘能力：

components 和 render 里面都是对自己 native library 的 wrapper。在 SDK 一侧，还是需要有 Adapter 来依赖安卓包；而在 native library 一侧，也还有对安卓的依赖：

上面是 libagp.z.so 的导入表，对安卓的依赖不多。它还导入了很多 Skia 的方法，基本可以是确定是用 Skia 自绘。Skia 是谷歌开发的图形库，不过是跨平台的，可以不算安卓独有。

下面是 libagp.so 的导入表，还依然有大量的安卓导入函数：

其实根据国内每家都有自己的安卓 UI 来看，各厂应该都有类似的库，只是未必直接作为 Java API 提供给 App 使用。所以我就好奇去下了个 DevEco 1.0，华为在 1.0 里面提供了线上的手机模拟器。开了个 P40 Pro (Emui 10)，里面也有 libagp。（所以盲猜这个 agp 本来是 Emui 里面的自绘库，在鸿蒙里面做了一些新改动，暴露给了 App。）

（此处应有截图，但是华为的线上模拟器经常点不了允许调试…）

再放一个第四类的吧。不过 ProcessManager 本身足够简单，不需要过度封装：

结语

按照目前的分析，我认为鸿蒙如果真的想完全不依赖安卓，还有很长的路要走，个人乐观估计往后一到两年都会是安卓套壳/基于安卓/安卓魔改的状态。跟大嘴的 PPT 更是差得远，更谈不上已经掏空、随时替代、比安卓快 60%。而且似乎并没有要走 WSL1 的路线，这样改下去，要是未来某一天真的把安卓所有的东西都换掉了，肯定是没办法二进制兼容安卓 App 的，连源代码级别的兼容都做不到。

最后，还是想带一点私货。这几天大概看到了热心群众这样的心路历程：从“鸿蒙横空出世”，到“鸿蒙囊括了安卓”，到“鸿蒙在兼容安卓”，再到“华为是在诈美国”，最后是“你说的都对，但是华为需要群众的沸腾来支持”… 难道现在天道有轮回，再次进入亩产三万斤的时代了吗？

若真是如此，那美帝看我们，跟我们看三哥，恐怕没什么大区别。

前一阵子想找一个简单的 build system，看到了 redo，就去研究了一下。一开始还有点迷糊，但最后发现，虽然 redo 看起来只做了一件事（当文件变化时重新执行脚本），但它其实还解决了另一件更重要的事：如何在一个命令式语言中描述结构信息？

声明式语言是擅长描述结构信息的，谁是谁的父亲、谁是谁的兄弟、谁依赖了谁、谁的属性是什么等等。Makefile 就是一种典型的声明式语言，大多数 build system 也都使用声明式语言来描述构建流程（也有的使用了同时掺杂了命令式和声明式的语言，比如 Meson）。

回到一开始的问题，如何在命令式语言中方便地描述这种结构信息？熟悉函数式编程的人大概一下子就会想到使用 Method Chaining:

target("all")
    .depends_on("other_target")
    .source_files("a.c", "b.c")
    .call("...")
    ....;

虽然很多语言都能模仿出这种写法（你甚至可以用 bash 写 fp），但这已经不算是典型的命令式语言的用法了。同时，它仍然是“提前声明”式的做法（即在 build target 之前声明好这个 target 的所有属性、依赖等等），不够灵性。Redo 的做法同时也解决了 Makefile 的一些其他问题，例如依赖的其他 Make 文件是在编译过程中产生的情况、或是 Recursive Make Considered Harmful。

Redo 的做法其实很简单，就是让脚本一边跑，一边收集脚本或文件之间的依赖关系。这是它与其他声明式语法的 build system 的最大不同之处。这样的好处是，build 过程仍然用 bash 描述（比起用 Method Chaining 自然很多），而且依赖关系可以随时添加——甚至在编译结束之后。在命令式语言里看起来这是再正常不过的事了：

# 依赖 $2.c
redo-ifchange $2.c
gcc -MD -MF $2.d -c -o $3 $2.c
read DEPS <$2.d

# 依赖 gcc 生成的头文件列表中的所有文件
redo-ifchange ${DEPS#*:}

---

稍微跑个题，我很久之前其实也想过类似的问题：如何在 C++ 中描述一个图形界面？这个问题与虽然跟 Redo 半毛钱关系没有，但解决的思路其实完全一样。最后我做到了这样：

这是完全合法的 C++ 代码，扔进编译器就能编过。它描述了 main_form、button1 和 button2 之间的结构关系（父子关系），看起来像是声明式的语法，但仍然不丧失命令式语言的特点。最后只要：

int main()  
{
    yz::app app;
    yz::window* w = yz::ui["main_form"];
    app.exec();
    return 0;
}

就能启动。实现细节请看 https://zhuanlan.zhihu.com/p/24196189

---

至于如何看待 Redo，我觉得它小众自然有它的原因。一个 build 脚本，目标的依赖关系方面使用声明式语言更容易表达，而每个目标的产出过程是一个命令式的过程。所以路无非三条：可以在声明式的语法中加上点命令元素，或是在命令式的语法中加上点声明元素，或是干脆搞一个半声明半命令式的语言。Make 走的第一条路，Redo 是第二条，Meson 是第三条。

从结果来看，大家明显认为解决目标之间的依赖问题更重要。