企业官网建设流程全解析

网站关键词用热门的还是冷门,个人网站要备案吗,企业网站备案不通过,免费的虚拟主机空间网罗开发#xff08;小红书、快手、视频号同名#xff09;大家好#xff0c;我是 展菲#xff0c;目前在上市企业从事人工智能项目研发管理工作#xff0c;平时热衷于分享各种编程领域的软硬技能知识以及前沿技术#xff0c;包括iOS、前端、Harmony OS、Java、Python等方…网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录前言通信的本质不是“能不能调”而是“谁该知道谁”三种通信方式对应三种场景同步调用直接拿结果异步调用发起请求等待结果ArkTS 主动通知 H5一个推荐的整体通信分层结构第一层通信协议层第二层桥接实现层第三层业务能力层一个完整示例结构示意methodList 本质上是“通信白名单”通信设计中最容易踩的几个坑把 Bridge 当成业务层同步接口偷偷做耗时操作没有统一的数据格式一个简单但好用的通信设计原则总结前言只要项目里引入了 Web 组件通信设计一定会成为隐性复杂点。一开始可能只是H5 想调个原生方法原生想通知 H5 一个结果但随着业务增长问题会逐渐暴露出来同步、异步混在一起JS 想干的事情越来越多ArkTS 端开始变成“万能工具箱”没人说得清这条通信链路的边界所以这篇文章我们不再从“怎么写代码”开始而是先把通信模型本身理清楚。通信的本质不是“能不能调”而是“谁该知道谁”在鸿蒙的 Web 场景里H5 和 ArkTS 本质上是两个世界H5偏业务表达、快速迭代ArkTS偏系统能力、稳定边界通信的核心问题从来不是技术能力而是哪些信息可以跨界哪些必须隔离。所以一个合理的通信模型至少要回答三件事调用是同步还是异步主动权在谁是否允许返回结果三种通信方式对应三种场景在实际项目里我会把 H5 ↔ ArkTS 的通信明确拆成三类。同步调用直接拿结果代表方式javaScriptProxy特点非常明确JS 主动调用ArkTS 同步返回调用即完成适合做什么获取登录态获取配置获取环境信息不适合做什么网络请求文件操作长时间计算你可以把它理解成“查询型接口”异步调用发起请求等待结果代表方式URL schemeWeb 消息机制这一类通信通常是JS 发起动作ArkTS 执行执行完成后再通知 JS适合做什么支付上传调系统能力这里的关键不是“怎么调”而是一定要有请求 ID 或状态回传机制否则后期你会完全不知道某次调用是哪个 JS 发起的。ArkTS 主动通知 H5这一类在复杂项目里非常常见但经常被忽略。典型场景包括登录状态变化网络状态变化权限变化页面生命周期变化特点是ArkTS 是主动方H5 是被通知方通常没有返回值如果你没设计好这一层后期就会出现H5 不知道状态变了原生状态和页面状态不同步各种“看不懂的偶现问题”一个推荐的整体通信分层结构在中大型项目里我强烈建议把通信结构拆成三层。第一层通信协议层这一层只关心一件事数据怎么传比如method 名参数结构返回值结构不掺杂任何业务逻辑。第二层桥接实现层这一层是javaScriptProxyWeb 消息URL scheme它只负责把 JS 请求转成 ArkTS 调用把 ArkTS 结果转回 JS这里不允许写业务判断。第三层业务能力层真正的业务逻辑放在这里登录权限设备能力数据处理这一层完全不知道调用来自 H5 还是 ArkTS 页面它只关心“这是不是一个合法的业务请求”一个完整示例结构示意在 ArkTS 侧结构可以像这样web/ ├── bridge/ │ ├── JsBridge.ts // 仅定义可暴露方法 │ └── BridgeProtocol.ts // 参数与返回结构 ├── service/ │ ├── UserService.ts │ └── DeviceService.ts └── page/ └── WebPage.ets这样拆的好处是JS 能调用什么一眼可见业务逻辑不会被“Web 特性”污染后期重构成本极低methodList 本质上是“通信白名单”回到javaScriptProxy很多人只是把它当成配置项。但在架构上它其实是通信权限控制点methodList:[getUserId,getEnv]意味着JS 只能访问这两个能力ArkTS 内部再复杂也不会泄露这一步非常关键尤其是在多人协作外包 H5活动页频繁更新的项目里通信设计中最容易踩的几个坑把 Bridge 当成业务层结果就是一个类几十个方法什么都往里塞谁都不敢改同步接口偷偷做耗时操作表面看没问题实际是Web 偶发卡死定位极其困难没有统一的数据格式JS 端各种判断if(restrue)if(res.code0)if(res.success)最后没人知道“标准结果”长什么样。一个简单但好用的通信设计原则如果你只记住一句话我建议是这一句同步只做查询异步只做动作Bridge 只做边界。这个原则在鸿蒙 Web 项目里几乎不会出错。总结H5 和 ArkTS 的通信问题本质上是一个边界设计问题。不是“怎么连”而是哪些能力该暴露哪些状态该同步哪些事情必须隔离当你把通信模型想清楚具体用javaScriptProxy还是消息机制反而只是实现细节。