关于适配HarmonyOS鸿蒙NEXT一些API的问题

关于适配HarmonyOS鸿蒙NEXT一些API的问题

先抛出问题：

1. HarmonyOS NEXT 支不支持应用多进程？（非常重要）
2. HarmonyOS NEXT FAF框架是否考虑授权第三方应用管理用户文件？（重要）
3. HarmonyOS NEXT FAF框架是否考虑授权第三方应用管理用户选择的指定目录下的文件？（不重要）
4. HarmonyOS NEXT Native API是否完全支持C++17？（非常重要）
5. HarmonyOS NEXT Native API是否完全支持开源图形库AGG？（非常重要）
6. HarmonyOS NEXT Native API是否考虑提供Android没有的字体匹配策略API？（重要）

原因：

我这边是一个PDF编辑器项目，项目必然会适配HarmonyOS NEXT，但这边需要评估一下适配所需要的大致工作量。针对于现有项目在Android平台上的实现，大部分已经基于现有的3.1/4.0的文档找到了HarmonyOS上的对应API，但以上问题是现有我的账户可查阅的文档上未提及的。希望官方或者有知道的大佬能否帮忙解答一下上面的疑问，以便于我更好的评估接入工作量。

1.HarmonyOS NEXT 支不支持应用多进程？（非常重要）

目前查阅的文档，从进程模型概述来看，应用并不支持多进程，而WebView拥有独立的渲染进程。 相较于其他普通应用，PDF编辑器需要比较多的运行内存进行页面渲染，甚至有些文档中插入的位图在渲染过程中会产生非常大的内存使用波动。处理WebView的PDF查看也能知晓这需要大量的运行内存。若整个应用处于同一个进程，那么非文档编辑页面会与文档编辑页面形成一个很大的内存竞争。这会大大的限制文档编辑页面功能使用。这是应用内的资源竞争，另外应用支持其他应用调度打开PDF，应用也支持新窗口打开多个文档，多个文档同时打开的时候，这样运行内存需求量更大，如果这些都在一个进程中，那么触发内存不足的错误更加容易。 目前Android应用多进程上的一些弊端：使用android:process可为页面指定进程，但其必须在页面声明时指定，中途无法用代码灵活指定。在其他应用调度我们应用进行PDF阅读与编辑时，我们会尽可能的为其准备一个单独的进程进行处理。但这个声明的限制，导致我们只能声明N个进程，在第N+1个应用调起时，我们只能重新开始复用第一个进程。这其实类似于微信的小程序。项目中我们声明了5个进程，虽说能满足大部分用户场景了，但其实实现效果并不是最佳的。 倘若HarmonyOS NEXT支持声明多进程及代码动态指定多进程，那将是非常完美的解决应用对运行时需要较多的运行内存的完美解决。或者有其他方式能够解决内存不足的问题也是可以的。

2.HarmonyOS NEXT FAF框架相关问题

虽说充当FAF框架中的FileMananger来管理用户的所有PDF类型的文档文件并不是那么必不可少，但它还是能够给用户带来不少便捷的。而去掉这部分功能，如果用户的PDF文档都存在于设备外部存储，那么用户将频繁的在我们应用与系统的文件管理器之间来回切换。如果用户为了不在两个应用之间频繁切换而选择将PDF文档存储到我们应用的应用存储空间，虽然方便了，但用户恐怕会有不知道应用卸载而会导致这部分存储的文档全部丢失的问题。我们也提供云存储进行跨端协同，但这是带有空间大小限制的，当然用户愿意使用我们的云存储那是更欢迎的。

3.HarmonyOS NEXT Native API 基础之C++17与AGG

看到C++17正在完善，希望在HarmonyOS NEXT上完全支持，这样减少底层打鸿蒙so对代码的改动。AGG图形库的支持可大大减少底层改动，一般来说都支持的吧？当然如果支持Google的Skia也不错，但我猜测Skia可能不支持。

4.字体匹配

Android并不提供标准的字体匹配API，目前我们是通过读取系统文件etc/fonts.xml以及结合fonts下面的所有字体文件进行字体匹配。fonts.xml其实警告了第三方应用的解析。但要与系统达成比较一致的字体匹配效果，那么只能通过这种方式进行。若HarmonyOS NEXT在Native API中提供字体匹配API，那么这将完美保持了未内嵌字体的文档在文字呈现上与系统完全一致（忽略主题中的字体效果）。