HarmonyOS鸿蒙Next中可以用webview加载的形式开发应用吗？

可以的，

web组件（混合开发）

1.Web组件的生命周期

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/web-event-sequence

• onControllerAttached
• onLoadIntercept
• onInterceptRequest
• onPageBegin
• onProgressChange
• onPageEnd
• onPageVisible

Web组件网页正常加载过程所涉及的状态说明

• aboutToAppear函数：在创建自定义组件的新实例后，在执行其build函数前执行。建议在此设置WebDebug调试模式、自定义协议URL的权限、Cookie等。
• onControllerAttached事件：当Controller成功绑定到Web组件时触发该回调，且禁止在该事件回调前调用Web组件相关的接口，否则会抛出js-error异常。建议在此事件中注入JS对象、设置自定义用户代理，使用操作网页不相关的接口。但因该回调调用时网页还未加载，因此无法在回调中使用有关操作网页的接口，例如zoomIn、zoomOut等。
• onLoadIntercept事件：当Web组件加载url之前触发该回调，用于判断是否阻止此次访问。默认允许加载。
• onInterceptRequest事件：当Web组件加载url之前触发该回调，用于拦截url并返回响应数据。
• onPageBegin事件：网页开始加载时触发该回调，且只在主frame（表示一个HTML元素，用于展示HTML页面的HTML元素）触发。如果是iframe或者frameset（用于包含frame的HTML标签）的内容加载时则不会触发此回调。多frame页面可能同时加载，主frame加载结束时子frame可能仍在加载。同一页面导航或失败的导航不会触发该回调。
• onProgressChange事件：告知开发者当前页面加载的进度。多frame页面或者子frame可能还在继续加载而主frame已经加载结束，所以在onPageEnd事件后仍可能收到该事件。
• onPageEnd事件：网页加载完成时触发该回调，且只在主frame触发。多frame页面有可能同时开始加载，即使主frame已经加载结束，子frame也有可能才开始或者继续加载中。同一页面导航或失败的导航不会触发该回调。建议在此回调中执行JavaScript脚本。注意，收到该回调不能保证下一帧反映DOM状态。

Web组件网页异常加载过程所涉及的状态说明

• onOverrideUrlLoading事件：当URL将要加载到当前Web中时，让宿主应用程序有机会获得控制权，回调函数返回true将导致当前Web中止加载URL，而返回false则会导致Web继续照常加载URL。onLoadIntercept接口和onOverrideUrlLoading接口行为不一致，触发时机也不同，所以在应用场景上存在一定区别。onLoadIntercept事件在LoadUrl和iframe加载时触发，但onOverrideUrlLoading事件在LoadUrl和特定iframe加载时不会触发。
• onPageVisible事件：Web回调事件。渲染流程中当HTTP响应的主体开始加载，新页面即将可见时触发该回调。此时文档加载还处于早期，因此链接的资源比如在线CSS、在线图片等可能尚不可用。
• onRenderExited事件：应用渲染进程异常退出时触发该回调，可以在此回调中进行系统资源的释放、数据的保存等操作。如果应用希望异常恢复，需要调用loadUrl接口重新加载页面。详细用法参考应用如何避免Web组件渲染子进程异常退出导致的页面卡死问题。
• onDisAppear事件：组件卸载消失时触发此回调。该事件在组件卸载时触发。

Cookie管理

• Cookie是网络访问过程中，由服务端发送给客户端的一小段数据。客户端可持有该数据，并在后续访问该服务端时，方便服务端快速对客户端身份、状态等进行识别。
• 当Cookie SameSite属性未指定时，默认值为SameSite=Lax,只在用户导航到cookie的源站点时发送cookie,不会在跨站请求中被发送。
• Web组件提供了WebCookieManager类，用于管理Web组件的Cookie信息。

Cookie信息保存在应用沙箱路径下/proc/{pid}/root/data/storage/el2/base/cache/web/Cookiesd 的文件中。

缓存与存储管理

• 在访问网站时，网络资源请求是相对比较耗时的。开发者可以通过Cache、Dom Storage等手段将资源保存到本地，以提升访问同一网站的速度。

Cache
使用cacheMode()配置页面资源的缓存模式，Web组件为开发者提供四种缓存模式，分别为：
·Default:优先使用未过期的缓存，如果缓存不存在，则从网络获取。
·None:加载资源使用cache,如果cache中无该资源则从网络中获取。
·Online:加载资源不使用cache,全部从网络中获取。
·Only:只从cache中加载资源。

Dom Storage
Dom Storage包含了Session Storage和Local Storage两类。
前者为临时数据，其存储与释放跟随会话生命周期；后者为可持久化数据，落盘在应用目录下。两者的
数据均通过Key-Value的形式存储，通常在访问需要客户端存储的页面时使用。
开发者可以通过Web组件的属性接口domStorageAccess()进行使能配置。

在新窗口中打开页面

• Web组件提供了在新窗口打开页面的能力。
• 开发者可以通过multiWindowAccess()接口来设置是否允许网页在新窗口打开。
• 当有新窗口打开时，应用侧会在onWindowNew()接口中收到Web组件新窗口事件，开发者需要在此接口事件中，新建窗口来处理Web组件窗口请求。
• allowWindowOpenMethod()接口设置为true时，前端页面通过JavaScript函数调用的方式打开新窗口。
• 如果开发者在onWindowNew()接口通知中不需要打开新窗口，需要将ControllerHandler.setWebController()接口参数设置成null。

调用

• 应用侧可以通过runJavaScript()方法调用前端页面的JavaScript相关函数。
• 开发者使用Web组件将应用侧代码注册到前端页面中，注册完成之后，前端页面中使用注册的对象名 称就可以调用应用侧的函数，实现在前端页面中调用应用侧方法。
• 注册应用侧代码方法一：在Web组件初始化调用，使用javaScriptProxy()接口。
• 注册应用侧代码方式二：在Web组件初始化完成后调用，使用registerJavaScriptProxy()接口。

使用Devtools工具调试前端页面

• Web组件支持使用DevTools工具调试前端页面。DevTools是一个Web前端开发调试工具，提供了电脑上调试移动设备前端页面的能力。
• 开发者通过setWebDebuggingAccess()接口开启Web组件前端页面调试能力，利用DevTools工具可以在电脑上调试移动设备上的前端网页。
• 想使用setWebDebuggingAccess()接口需要先导入@ohos.web.webview模块，模块提供web控制能力，Web组件提供网页显示的能力。
• 开发步骤：
  • 在应用代码中开启Web调试开关：

import { webview } from "@kit.ArkWeb"
aboutToAppear(): void {
  webview.WebviewController.setWebDebuggingAccess(true)
}

• 开启调试功能需要在DevEco Studio应用工程hap模块的module.json5文件中增加如下权限

"requestPermissions": [
  {
    "name": "ohos.permission.INTERNET",
  }
],

• 将设备连接上电脑，在电脑端配置端口映射，配置方法如下：

//查找 devtools 远程调试所需的 domain socket 名称，该名称与进程号有关，重启调试应用后，需要重复此步骤，以完成端口转发
cat /proc/net/unix | grep devtools
// 添加映射[pid]替换成实际的进程id
hdc fport tcp:9222 localabstract:webview_devtools_remote_[pid]
//查看映射
hdc fport ls
示例：
hdc shell
cat /proc/net/unix |grep devtools
//显示 webview_devtools_remote_3458
exit
hdc fport tcp:9222 localabstract:webview_devtools_remote_3458
hdc fport ls

• 在电脑端Chrome浏览器地址栏中输入chrome:/inspect/#devices,页面识别到设备后，就可以开始页面调试。
• 多应用调试请在调试地址内Devices中的configure添加多个端口号以同时调试多个应用

使用crashpad收集Web组件崩溃信息(https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/web-crashpad)

• Web组件支持使用crashpad记录进程崩溃信息。
• crashpad是chromium内核提供的进程崩溃信息处理工具，在应用使用Web组件导致的进程崩溃出现后（包括应用主进程与Web渲染进程），crashpad会在应用主进程沙箱目录写入minidump文件。
• 该文件为二进制格式，后缀为dmp,其记录了进程崩溃的原因、线程信息、寄存器信息等，应用可以使用该文件分析Web组件相关进程崩溃问题。
• 实现步骤
  • 在应用使用Web组件导致的进程崩溃出现后，会在应用主进程沙箱目录下产生对应的dmp文件，对应的沙箱路径如下：

/data/storage/el2/log/crashpad

• 参考Native访问应用沙箱实现访问应用沙箱dmp文件。
• 获取dmp文件后进行解析，具体步骤如下：
  • 通过minidump_stackwalk工具解析dmp文件，可以得到上述dmp文件对应的进程崩溃信息（崩溃的原因、线程信息、寄存器信息等），示例如下（Linux环境）：

./minidump_stackwalk b678e0b5-894b-4794-9ab3-fb5d6dda06a3.dmp > parsed_stacktrace.txt

minidump_stackwalk由breakpad项目源码编译得到，编译方法见项目仓库：breakpad仓库地址。
- 查看解析后的文件，以下示例列出部分内容：

Crash reason:  SIGSEGV /SEGV_MAPERR     表示导致进程crash的信号，此处示例为段错误
Crash address: 0x0
Process uptime: 12 seconds

Thread 0 (crashed)                     表示Thread 0发生crash
 0  libweb_engine.so + 0x2e0b340        0层调用栈，0x2e0b340为so偏移地址，可用来反编译解析crash源码（依赖unstripped so）
     x0 = 0x00000006a5719ff8    x1 = 0x000000019a5a28c0
     x2 = 0x0000000000020441    x3 = 0x00000000000001b6
     x4 = 0x0000000000000018    x5 = 0x0000000000008065
     x6 = 0x0000000000008065    x7 = 0x63ff686067666d60
     x8 = 0x0000000000000000    x9 = 0x5f129cf9e7bf008c
    x10 = 0x0000000000000001   x11 = 0x0000000000000000
    x12 = 0x000000069bfcc6d8   x13 = 0x0000000009a1746e
    x14 = 0x0000000000000000   x15 = 0x0000000000000000
    x16 = 0x0000000690df4850   x17 = 0x000000010c0d47f8
    x18 = 0x0000000000000000   x19 = 0x0000005eea827db8
    x20 = 0x0000005eea827c38   x21 = 0x00000006a56b1000
    x22 = 0x00000006a8b85020   x23 = 0x00000020002103c0
    x24 = 0x00000006a56b8a70   x25 = 0x0000000000000000
    x26 = 0x00000006a8b84e00   x27 = 0x0000000000000001
    x28 = 0x0000000000000000     fp = 0x0000005eea827c10
     lr = 0x000000069fa4b33c     sp = 0x0000005eea827c10
     pc = 0x000000069fa4b340
    Found by: given as instruction pointer in context
 1  libweb_engine.so + 0x2e0b338
     fp = 0x0000005eea827d80     lr = 0x000000069fa48d44
     sp = 0x0000005eea827c20     pc = 0x000000069fa4b33c
    Found by: previous frame's frame pointer
 2  libweb_engine.so + 0x2e08d40
     fp = 0x0000005eea827e50     lr = 0x00000006a385cef8
     sp = 0x0000005eea827d90     pc = 0x000000069fa48d44
    Found by: previous frame's frame pointer
 3  libweb_engine.so + 0x6c1cef4
     fp = 0x0000005eea828260     lr = 0x00000006a0f11298
     sp = 0x0000005eea827e60     pc = 0x00000006a385cef8
 ......

- 使用llvm工具链解析crash源码位置，示例如下（Linux环境）：  

./llvm-addr2line -Cfpie libweb_engine.so 0x2e0b340

llvm-addr2line工具链位于sdk中。