-
产品体验官有奖体验:HiChat【活动已结束】本次体验采用有奖征集体验评测报告的形式,从体验官中招募10人,体验产品并输出产品体验评测报告。我们会按照评测体验维度、深度、意见建议等方面,从中筛选出2份优秀体验报告及3份高质量体验报告,给予礼品奖励。奖品设置如下优秀体验报告:2名奖品:华为入耳式耳机一副高质量体验报告:3名奖品:32G存储卡一副产品体验评测内容要求体验评测报告内容需要包含以下维度:1.操作体验:在各种使用场景中操作是否流畅,是否出现逻辑上的中断。2. 性能:页面性能是否感受比较舒服。3. 功能特性:对比体验官已用过的沟通协作产品,是否有哪些功能觉得有意思(比如统一搜索、上下文快速跳转、sinnpet文本片段、提醒事项、@汇总等等),是否觉得确实了哪些重要功能。4. 满意度及推荐度:体验官是否愿意使用该产品作为自己企业的协作工具?是否愿意推荐给其他朋友或同事?5. 沟通协作是喜欢使用PC客户端还是web接入?对客户端接入和web接入的各自评价如何?6.对于HiChat产品的意见和建议。体验过程及评测报告中可参考的竞品:1.微信2.阿里钉钉3.Slack4.Worktile企业im体验评测报告交稿时间:12月18日 14:00前,请将评测用word形式通过邮件发送至devcloud@163.com,并同步微信告知小助手(微信:hwyxzs)微信号。评测报告字数不少于1000字,可图文并茂,并在落款标注姓名和群内昵称,以便评奖时使用。12月20日16:00前群内公布获奖名单。HiChat使用指南1.大家可用PC点击下方链接,登陆华为云DevCloud.https://www.huaweicloud.com/devcloud/2.点击“免费试用5人套餐”3.点击右下方小图标,即可进入HiChat功能。4.您可以开始体验web版的HiChat,也可下载PC客户端体验。产品体验官体验评测【HiChat产品体验官评测】从0到1,HiChat体验报告【HiChat产品体验官评测】-铺路能手的评测报告【HiChat产品体验官评测】-十二月的评测报告【HiChat产品体验官评测】-hym的评测报告【HiChat产品体验官评测】-Jackrabbit的评测报告【HiChat产品体验官评测】-那年夏天的评测报告
-
在OC官网主页上找了很久,我想接入设备进去,里面也有详细说明创建应用跟产品,就是找不到web地址,有人知道是在哪里进吗?我只晓得开发者中心,没找到开发者平台,创建应用跟产品是在哪儿啊?
-
这段时间出差,时间仓促,只能浅显的表达一下对HiChat 这款产品的个人意见。希望能有点价值。。 这是我第一次接触华为云,之前一直使用的是阿里云。首先简单说一下阿里云和华为云第一印象的对比。1、 登陆:账号密码错误时候,华为云有5次输入机会,然后锁定15分钟,阿里云并不限定输出错误次数。个人偏向阿里云的操作方式。当然从安全性角度考虑华为云显得更为有保障,但实际情况是,阿里云会识别登陆账号的电脑(网络),首次登陆阿里云的电脑(网络)需要通过绑定的手机验证码进行验证,之后则无需验证。其实安全性上给人感觉相差无几。但是便捷性上个人认为华为云还可以提升,尤其是其它平台账号关联登陆,这可能涉及到生方面的问题有所限制,但提升还是有必要的。2、 移动端+PC端阿里云客户端是APP+PC,相互验证配合,具体结合形式和功能是不做赘述,但这方便了用户的使用,虽然是企业客户居多,但是也绕不开移动+PC结合的优势。 关于云的就说到这,回归正题。 以下是个人对HiChat 的几点看法,以供参考:1、初始化延迟问题:PC端HiChat页面初始化延时过高,一款沟通协作软件,我决定流畅性在用户体验中的占比还是相当重要的。部分部件初始化延迟过高,比如聊天表情 2、界面图标标识问题当用户首次接触到一款产品的时候,即使在有用户操作手册的情况下,如果功能图标上没有明确的文字标识的情况下,用户会有,,明显的排斥感,不利于尽快上手。所以必要的功能标识,设置提示性的简介是非常有必要的3、PC客户端下载安装问题A:安装包首次下载速度过慢。B:安装过程中,没有相关软件的介绍以及安装指引,尤其是安装位置,都是默认安装地址,且不能修改C:客户端默认开机自启,没有给用户提示,不够友好。4、PC端登陆问题登陆页面就是一个网页插件,由此带来的客户端感受就是一款简化版的浏览器。实际操作也是如此。同样延迟也是过高,估计是因为本身是网页的原因。并且存在一个极为不友好的地方,当我在客户端点击首页的时候,和华为云WEB端界面无差别,但是点到具体的功能项的时候,却打开了浏览器。并且我已经无法返回到Hichat本身界面。由此,这个客户端已经失去了其本身的意义和作用。(补充:实际各项操作完之后,这其实就是一款浏览器,只不过是专属于华为云,WEB端存在的问题,PC端一样存在。感到失落) 5、编辑组织架构新开页面问题PC 和WEB端均是打开新页面编辑,我感觉完全没有必要,简单便捷还是很有必要的。6、项目和HiChat关联的建议我一直都没有明白这款产品的定位,当然即时通讯是完全没有必要了。所以我只能谈谈我对这款软件和华为云为开发者提高的项目托管的生态聊聊一点看法:我简单看了一下,项目管理做的已经很不错了,尤其是看到能比较好的适配敏捷开发需求,表示真心体贴,如果能够开放相关端口对接坐席系统,公司ERP等系统的话,个人觉得很有价值(制定标准,个性开发,让大家都可以参与,可以参考钉钉的开发生态1、项目托管有分项目进行整合,如果能够将HiChat 和每个项目进行结合,比如每个项目自动生成一个讨论组,可以随时让项目参与者获取到醒目进度、沟通信息,以及共享文件。2、在HiChat中提供信息获取标识,比如消息已读提醒,共享资源被哪些人引用参考,公告是否所有人都获取到了,项目贡献值等等类似的标识,一来可以确保各项重要的消息及时通知到每个人,二来可以激发团体的积极性。有利于项目推进 最后的关于各项安全性的问题不做赘述,这是每款产品必须严把的关口。 以上就是我的一些看法,时间仓促,只能浅显的说几点。祝华为能开发出一款很棒的产品。很期待! 作者:华为云产品体验官-Jackrabbit 2018年12月18日夜----苏州
-
本次华为云HiChat产品体验我就已产品使用流程进度进行评测吧 1首先进入的是web界面,整体给人感官视觉还算简洁,但是整体界面布局色调不舒服,甚至有点看不清楚,可能是字体太小的缘故吧,希望这里给与优化2紧接着,我就下载了华为云HiChatWindows客户端,客户端比预想的要大呀 200多兆,下载速度也是堪忧,估计后期客户端资源下载速度不会是这样。3客户端安装还算流畅,弹出客户端登录界面,我有点懵,我这是装了个浏览器吗!! 客户端是这样的登录界面,我表示不接受,此处还望优化,优化,优化,重要的事情说三遍。4登入客户端,哇,这个界面比较舒服了,比起web界面,好多了。主菜单七个功能,都是特别实用的,对于团队协作来说,也都是不可或缺的实用功能,功能使用频繁程度来编排,非常不错。 5 登陆后,功能菜单看了一遍,还是比较简洁易用的,产品品质把控比较好,是那种让人有欲望去摸索使用的那种软件,菜单图标比较简洁易懂,这里还要说明一点,华为云HiChat产品是基于华为云 DevCloud 的一款沟通协作产品,它在华为云 DevCloud 界面有快捷图标进行研发协同,在华为云 DevCloud就能快速唤起华为云HiChat产品,这个还是非常方便快捷的,也是研发过程中不可缺少的一部分。 6对华为云HiChat产品功能熟悉过程中,其中文本片段的 快捷发送这个功能我特别喜欢,那既然是研发协同软件,代码自然是无处不在的,这个功能就很好的满足了程序员们的切身的功能需求。这点很重要,而且文本还可以设置高亮显示,突出显示,这个用心了。还有一个功能我也是很喜欢,那就是设置提醒功能,对于办公人员来说,这个功能就很好用了,而且使用起来非常方便。7华为云HiChat产品,这里我还特别注意到有个整体搜索功能,这个功能是亮点。对于程序员们来说,产品研发设计过程中,对于一些产品研发中碰到的问题,以及代码的问题,需要进行交流沟通,往往很多问题是大部分程序员在同一个项目中都会碰到的问题,我们在讨论组里讨论的一些问题,我们进过讨论解决了,后期又遇到同样的问题,但是时间长了,可能就记不清楚之前那个问题是如何解决。或者其他同事也是遇到同样的问题,不知道怎么去解决的时候,那不妨去搜索下,找找看,可能就会有答案。8华为云HiChat这里还有一个对于提醒到我的消息做了一个单独的栏目,这个也是非常实用,而且对于这个功能单独分类提出来,非常的实用,这样就不会错过重要的消息。 整体使用体验下来,我对于华为云HiChat产品非常喜欢,我愿意使用该产品作为自己企业的协作工具。我也愿意推荐给其他朋友或同事。沟通协作时更喜欢使用PC客户端,对客户端接入和web接入的各自评价如何?这个问题以及在上面的文档里具体做了说明 对于HiChat产品的意见和建议总之,华为云HiChat产品我非常认同,功能,界面都比较棒。但是在体验过程中,我发现,不管是客户端还是web端,都会在十几分钟不操作后提示重新登录,这一点希望调整下,十几分钟就自动登录失效,如果有收到消息会不会就接收不到了呢,希望在这个登录时效上适当做出调整。作者:华为云产品体验官-那年夏天
-
HiChat的体验测评报告一、操作体验1. 选择发送表情时,显示的是英文字符,而不是表情本身。HiChat的:微信的:2. HiChat没有截图功能,有个截图的功能会更方便(哈哈,可能是受微信QQ的影响)。3. HiChat对已发的消息可以通过编辑来改正,但没有撤销的功能,最好点击撤销后最好不要留下撤销的痕迹(个人感觉)。二、性能页面布局很合理,有会话、通讯录、团队文件、收藏、搜索以及提到我的消息。三、功能特性1. 设置提醒功能非常赞,可以通过提醒功能防止忘记了。2. 文本片段功能非常nice,尤其是在对代码的粘贴复制格式不会变。3. 对某条消息的评论表情功能非常人性化,可以对某条信息表示自己的态度。4. 搜索功能有点慢了。5. 第一次点击置顶消息时有点慢,而且是换个页面了,是否应该直接定位到会话内容中,可以找到相对应的上下文。四、满意度和推荐度作为办公软件,非常满意这款软件,可以作为企业内的协作工具,非常愿意推荐给自己的同学、朋友和课题组使用。但作为社交软件,可能略逊于微信(哈哈,不好意思哈)。五、对HiChat产品的意见和建议1. 是否可以通过HiChat结合华为其他产品打造出华为的生态系统。2. 对于PC客户端或者Web接入,大部分用户应该是接收客户端,可能因为市场上大部分都是客户端。我是比较喜欢Web接入的,这样可以少了安装步骤了。3. 对于HiChat是否应该加入已读的功能,毕竟是面向办公协同的工具。4. 对于会话接收的文件是否可以缓存到云,以便于后期查找。5. 是否可以增加语音及语音电话功能,这样更方便团队间沟通。6. 信息安全方面,可以增加会话保密的功能,以防团队沟通的核心问题外泄。 作者:华为云产品体验官-十二月
-
在日常的开发中,我们习惯使用QQ作为协同沟通的工具,但QQ有一定的限制,例如代码不能高亮、git提交通知。并且不知道@的同事时,不知他是不是真的看到,还是看到了没有回复。所以借华为云HiChat体验,看看是否有一款在QQ、钉钉、微信之外,专为开发人员定制的沟通协同工具呢?我带着好奇心做一回小白鼠。HiChat下载与安装在华为云轻易找到HiChat的入口。容量瞬间吓我一跳,222M!连钉钉也就110M而己,日常使用的QQ只有72M。这一容量,令我对该HiChat的功能有了更高的期待。毕竟容量越大,功能通常是越多。当然对于大多数客户还是使用Windows 7,所以嘛,.net 4.5.2也是要装。既然用上了.net 4.5, net 4.5有很多机器学习的库,并且华为云的AI服务也做得不错,所以,我就更期待了,难道这是专为AI研发人员的沟通工具?经过了一段时间的安装(毕竟微软的服务器在美国嘛),也安装完成了。HiChat初体验一打开,就惊讶了,是个网页?好吧,毕竟在现在全栈开发流行的背景下,可能HiChat是第一款全栈的构通工具吧?不管了,登录体验一把。首先,体验其宣传其非常牛的代码高亮功能。先拿一段Python来试试结果...... 可能python不支持,那就试试我们业务系统用的C#吧。怎么还是这样呢?是不是要发送出去才能高亮呢?结果还是不行......好吧,我们继续测试一下有什么牛逼的功能吧看见有个“组织架构”,就试试是不是可以建组织然后被弹到Web后端,看来全栈时代,要得适应一下才行。添加过程倒比想像中简单。然而在这时发现Web版,其实与PC端是非常类似。不过人的习惯嘛,不是一下子能调整过来的。对于开发人员习惯的PC端,问题就来了,每过一段时间。就要重新登陆一次,还不能保存密码。对于像我们公司有泄密资质的,都要8位以上数字+字母+特殊符号...... 意料之外HiChat的截图功能意外地成熟,估计也是用了与QQ相同的控件?而PC版,本地不自带emoji,所以嘛......而一开始,还以为是APP,毕竟现在应该不会再出PC版了吧。结果一下载HiChat就雷倒了......是合作伙伴与华为员工进行即时沟通的工具。(传说中的华为手机特价消息渠道?) 总结虽然HiChat各种不完善,但是至少是华为从0到1的突破,也是我使用的第一款基于全栈技术开发的沟通工具。全栈技术虽然前些年炒很热,但从这次HiChat的体现中也发现其不众多不完善,再加上开发难度较高。所幸的是,我们自主研发的产品没有随波逐流改全栈。下面是按标准模板总结一下:1.操作体验:与标杆产品有差距。2. 性能:算挺流畅,当然前提是公司的网络要够好。3. 功能特性:其实是挺期待高亮代码、关联git通知,不过前者不知怎么用不了,后者估计要看HiChat是否开放API。4. 满意度及推荐度:体验官是否愿意使用该产品作为自己企业的协作工具?答:3分(5分为满分的话)是否愿意推荐给其他朋友或同事?答:暂时不会,毕竟还有一段路要走。5. 沟通协作是喜欢使用PC客户端还是web接入?对客户端接入和web接入的各自评价如何?答:喜欢PC端6.对于HiChat产品的意见和建议。答:初版肯定是各种不完善,相信以华为的精神能弄好。作者:华为云产品体验官-益欣
-
PageSpeed Insights 的Chrome扩展是由谷歌官方开发的一款可以分析页面载入的各个方面,包括资源、网络、DOM以及时间线等等信息的插件,安装以后会附加到Developer Tools(开发者工具)中。所以安装之后,大家只需要在页面上点击右键——审查元素,就可以在最后一个标签中看到 PageSpeed 了。PageSpeed Insight的分析一般包含以下几个方面: * 优化缓存——让你应用的数据和逻辑完全避免使用网络 * 减少回应时间——减少一连串请求-响应周期的数量 * 减小请求大小——减少上传大小 * 减小有效负荷大小——减小响应、下载和缓存页面的大小 * 优化浏览器渲染——改善浏览器的页面布局离线Chrome插件安装文件(crx)的安装方法:PageSpeed Insights.zip1.首先用户点击谷歌浏览器右上角的自定义及控制按钮,在下拉框中选择工具选项,然后点击扩展程序来启动Chrome浏览器的扩展管理器页面。2.在打开的谷歌浏览器的扩展管理器中用户可以看到一些已经安装程序的Chrome插件,或者一个Chrome插件也没有。3.找到自己已经下载好的Chrome离线安装文件xxx.crx,然后将其从资源管理器中拖动到Chrome的扩展管理界面中,这时候用户会发现在扩展管理器的中央部分中会多出一个”拖动以安装“的插件按钮。4.松开鼠标就可以把当前正在拖动的插件安装到谷歌浏览器中去,但是谷歌考虑用户的安全隐私,在用户松开鼠标后还会给予用户一个确认安装的提示。5.用户这时候只需要点击添加按钮就可以把该离线Chrome插件安装到谷歌浏览器中去,安装成功以后该插件会立即显示在浏览器右上角(如果有插件按钮的话),如果没有插件按钮的话,用户还可以通过Chrome扩展管理器找到已经安装的插件。
-
目录前言... 1从一次页面请求说起... 3浏览器运行机制... 3浏览器是多进程的... 3浏览器内核是多线程的... 4HTTP缓存... 6强制缓存... 7对比缓存... 7运行流程... 8DNS域名解析... 10TCP连接... 12HTTP请求与响应... 12页面渲染... 15关闭TCP连接... 16结束语... 17 前言 经常听到有人说,前端很简单,就是画画界面。好像也不无道理,只是还没有真正的去了解它,就像跑步一样,也确实很简单,但是你百米跑进十秒试试。只有对每一个动作都充分了解,才能把速度提上去,而且每进步一秒,都要付出更大的努力。简单的事情做到极致,就不简单了。其实前端并非想象中的简单,也有自己的一套庞大生态体系。下面是一张最新的前端知识体系图,长路漫漫,还需要潜心修炼才行。本文旨在带领大家进入前端的世界,不会讲解具体的HTML/CSS/JS的语法,也不涉及前端框架,而是帮助大家了解前端的运行机制,准确的说是浏览器页面加载的机制。只有充分的了解了前端,才能更好的优化我们的Web系统。对前端不感兴趣也没关系,就当是了解一下,后续还有《Web之旅-后端篇》带给大家。本文中部分内容参考《WebKit技术内幕》一书,感兴趣的童鞋可以研究一下。从一次页面请求说起先考大家一个问题:从打开一个URL到看到页面,中间都经历了什么?输入URL,加载资源,显示页面?没毛病,不过从前端角度来说,一般会经历下面几个过程:1) 在浏览器中输入URL并回车(当然,也可以直接点击URL超链接打开)2) 浏览器查找当前URL是否存在缓存,并比较缓存是否过期3) DNS解析URL获取对应IP4) 根据IP建立TCP连接(三次握手)5) 发送HTTP请求6) 服务器处理请求,浏览器接收HTTP响应7) 渲染页面8) 关闭TCP连接(四次挥手)那么这里的每一步又是怎么实现的呢?作为一名IT工作者,可能有些过程大家已经耳濡目染了,那就可以选择性的跳过啦。如果还不太了解,那也没关系,下面就开始我们的Web之旅-前端篇。首先第一步,输入URL?不不不,是打开浏览器。是的,你没看错,作为此次Web之旅的主办单位及赞助商,在发车之前,浏览器的运行机制,确定不先了解一下么。浏览器运行机制首先申明,下面要讲述的是Chrominum浏览器的架构模型,不排除个别浏览器特立独行哦。浏览器是多进程的 当我们启动浏览器的时候,默认就启动了一个进程(进程和线程的概念就不再科普了),作为主进程,并从系统中获取资源(CPU、内存)。每当我们打开一个tab页签,就会另起一个新的进程(某些情况下多个tab会合并进程)。那么浏览器到底包含哪些进程呢?下面列举了一些主要进程:1) Browser进程:浏览器的主进程(负责协调、主控),只有一个。a. 负责浏览器界面显示,与用户交互。如前进,后退等b. 负责各个页面的管理,创建和销毁其他进程c. 将Renderer进程得到的内存中的Bitmap,绘制到用户界面上d. 网络资源的管理,下载等2) 第三方插件进程:每种类型的插件对应一个进程,仅当使用该插件时才创建3) GPU进程:最多一个,用于3D绘制等4) 浏览器内核(渲染进程)(Renderer进程,内部是多线程的):默认每个Tab页面一个进程,互不影响。主要用来进行页面渲染、脚本执行以及事件的处理那么Browser进程和浏览器内核(Renderer进程)的通信过程是怎样的呢?引用Chromium浏览器的代码层次结构图:从WebKit接口层到用户界面的路径1) Browser进程收到用户请求,首先需要获取页面内容(比如通过网络下载资源),随后将该任务通过RendererHost接口传递给Render进程。2) Renderer进程的Renderer接口收到消息,简单解释后,调用相应的WebKit接口层,进行渲染,并将Webkit处理后的结果发送回去3) Browser进程接收到结果并将结果绘制出来作为前端开发,我们需要重点关注一下浏览器内核进程,也是渲染页面所需要的。浏览器内核是多线程的 每一个tab页面可以看作是一个浏览器内核进程,内核进程是多线程的,主要包含下面几大类线程:1) GUI渲染线程a. 负责渲染浏览器界面,解析HTML(SVG/XHTML)和CSS,构建DOM树和Render树,并进行布局和绘制等操作。b. 当界面需要重绘(Repaint)或由于某种操作引发重排(Reflow)时,该线程就会执行c. 注意,GUI渲染线程与JS引擎线程是互斥的,当JS引擎执行时GUI线程会被挂起,GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。2) JS引擎线程a. 也称为JS内核,负责处理Javascript脚本程序。(例如V8引擎)b. JS引擎线程负责解析Javascript脚本,执行代码。c. JS引擎一直等待着任务队列中任务的到来,然后加以处理,一个Tab页(Renderer进程)中无论什么时候都只有一个JS线程在运行JS程序d. 同样注意,GUI渲染线程与JS引擎线程是互斥的,所以如果JS执行的时间过长,这样就会造成页面的渲染不连贯,导致页面渲染阻塞。3) 事件触发线程a. 归属于浏览器而不是JS引擎,用来控制事件循环(可以理解,JS引擎自己都忙不过来,需要浏览器另开线程协助)b. 当JS引擎执行代码块如setTimeOut时(也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等),会将对应任务添加到事件线程中c. 当对应的事件符合触发条件被触发时,该线程会把事件添加到待处理队列的队尾,等待JS引擎的处理d. 注意,由于JS的单线程关系,所以这些待处理队列中的事件都得排队等待JS引擎处理(当JS引擎空闲时才会去执行)4) 定时触发器线程a. 传说中的setInterval与setTimeout所在线程b. 浏览器定时计数器并不是由JS引擎计数的,因为JS引擎是单线程的,如果处于阻塞线程状态就会影响计时的准确性。因此通过单独线程来计时并触发定时任务(计时完毕后,添加到事件队列中,等待JS引擎空闲后执行)c. 注意,W3C在HTML标准中规定,要求setTimeout中低于4ms的时间间隔算为4ms。5) 异步http请求线程a. XMLHttpRequest在连接后是通过浏览器新开一个线程进行异步请求b. 当检测到状态变更时,如果设置有回调函数,异步线程就产生状态变更事件放到JS引擎的处理队列中等待处理。c. 在发起了一个异步请求时,http请求线程则负责去请求服务器,有了响应以后,事件触发线程再把回调函数放到事件队列当中。d. 大部分浏览器支持6个左右的并发请求(并发数是针对同一域名的),超过限制数目的请求会被阻塞。浏览器这块先介绍到这里,至于浏览器内核(渲染进程)具体是怎么工作的,各线程之间是怎么配合的,我们到页面渲染那一章节再详细介绍。好了,参观完浏览器,现在是不是可以出发了呢?还不行,下面我们要验票了,已经参加过web之旅的童鞋可能就不需要再次参加了。HTTP缓存 HTTP缓存有多种规则,根据是否需要向服务器发起请求,可以分为两大类:强制缓存和对比缓存。强制缓存如果生效,不再需要和服务器发生交互,而对比缓存不管是否生效,都需要与服务端发生交互。两类缓存规则可以同时存在,而强制缓存优先级高于对比缓存,也就是说,当执行强制缓存的规则时,如果缓存生效,直接使用缓存,不再执行对比缓存规则。和缓存规则相关的配置信息均存在于Http报文的请求头里。强制缓存强制缓存规则主要通过Cache-Control字段进行描述,而早先的HTTP1.0中使用的是Expires字段,以及古老的IE中支持的Pragma字段(这里就不细说了),为了保证兼容性,这些旧的字段还是会用到的。1) Expires:值为服务端返回的到期时间,是一个绝对时间。浏览器检查当前时间,如果还没到失效时间就直接使用缓存文件。估计大家已经想到了一个问题:当服务器时间与客户端时间不一致时,这种方式就会产生误差。所以从HTTP1.1版开始,使用Cache-Control来代替Expires。2) Cache-Control:用于定义所有的缓存机制都必须遵循的缓存指示,这些指示是一些特定的指令,包括public、private、no-cache、no-store、max-age、s-maxage以及must-revalidate等。其中的max-age保存一个相对时间。例如Cache-Control: max-age = 484200,表示浏览器收到文件后,缓存在484200s内均有效。当同时设置了上述三种规则时(包括Pragma),浏览器按照Cache-Control、Expires、Pragma的顺序进行覆盖处理。对比缓存强制缓存决定客户端是否向服务器发送请求,缓存判断生效,则直接从本地缓存读取数据,缓存失效,则需要向服务器发送请求。那么这时的资源是否真的已经发生了变化呢?如果没有变化,再把数据重传一遍岂不是会浪费带宽和时间。为了让客户端与服务器之间能实现缓存文件是否更新的验证,提升缓存的复用率,HTTP1.1新增了两种规则:Last-Modified以及ETag。一个是对比最后更新时间,一个是对比内容变化(如MD5值)。1) Last-Modifie:服务器将资源传递给客户端时,会将资源最后更改的时间以“Last-Modified: GMT”的形式加在响应头上一起返回给客户端。客户端会为资源标记上该信息,下次再次请求时,会把该信息附带在请求报文中一并带给服务器去做检查,若传递的时间值与服务器上该资源最终修改时间一致,则说明该资源没有被修改过,返回304状态码知会客户端直接使用本地缓存即可。否则以常规GET 200回包形式将新的资源(包括新的Last-Modified时间)返回给客户端。相关报文头字段:If-Modified-Since 和 If-Unmodified-Since。可能细心的小伙伴又要问了,如果只是更新了时间,内容没有发生变化呢?为了解决这个困扰,HTTP1.1还增加了ETag规则。2) Etag:服务器会通过某种算法,给资源计算出一个唯一标志符(比如md5值),在把资源返回给客户端的时候,会在响应头加上“ETag: 唯一标识符”一起返回给客户端。客户端保留该 ETag 字段,并在下一次请求时将其一并带给服务器。服务器只需要比较客户端传来的ETag跟自己服务器上该资源的ETag是否一致,就能很好地判断资源相对客户端而言是否被修改过了。如果服务器判断ETag是一致的,直接返回304状态码知会客户端直接使用本地缓存即可。否则以常规GET 200回包形式将新的资源(当然也包括了新的ETag)发给客户端相关报文头字段:If-None-Match 和 If-Match3) 如果同时指定了Last-Modifie和ETag字段,那么需要同时校验这两个规则。运行流程讲了这么多概念,是不是有点大脑缺氧呢,这到底是怎样一个运行流程呢?下面就通过一张图来回顾一下HTTP的缓存机制: 到这里,大家对HTTP的缓存机制应该有了清晰的认识了吧,下面我们放松一下,探讨一个比较有趣的话题:你知道浏览器里的回车(转到)和刷新(F5)有什么区别么?对,按键不同,还有呢?简单的说:1) 回车保证了原有的缓存规则不变,即在 强制缓存有效的时候,是不会去请求服务器的,打开调试看到的请求也只是伪造的,比如 谷歌浏览器可能显示 200(from cached),其实并没有发起实际的请求,而是直接读取了本地缓存。2) F5则会跳过 强制缓存,只有Last-Modified/ETag起作用,如果服务器比较后返回 304,再去本地缓存中读取,返回200则使用服务器返回的资源。但是浏览器依然会保留之前的一些变量的值,所以可能会造成页面刷新后,网页出现错误,甚至打不开的情况。3) 那么如果想完全抛弃本地缓存怎么办?Ctrl+F5!此时请求头会发送 Cache-Control: no-cache,告诉浏览器,我不要缓存中的文件了,直接从服务器获取文件,此时缓存完全失效。是不是很有意思呢,一般人我都不告诉他的。好了,那些已经参加过Web前端之旅的乘客,你已经被浏览器的强制缓存检测到了,请前往浏览器工作室进行页面的渲染。剩下的乘客请前往候车室,并耐心在座位等待。什么?为什么还不出发?因为导游要确定一下行程,你说去www.webzhilv.com ,除非是老司机,要不怎么知道具体在哪呢?没关系,我们正在查询线路网系统:DNS域名解析。DNS域名解析 关于域名解析,想必大部分童鞋都有所了解的,我们在地址栏输入的域名并不是最后资源所在的真实位置,域名只是与IP地址的一个映射。网络服务器的IP地址那么多,我们不可能去记一串串的数字,因此域名就产生了,域名解析的过程实际是将域名还原为IP地址的过程。 域名解析的过程,大体会经历下面几个步骤:1) 浏览器检查自身的缓存中有没有这个域名对应的解析过的IP地址,如果有,就使用这个IP。浏览器域名缓存在数量和时间(TTL)上都是有限制的,合理的设置才能保证域名的正常解析。小窍门:在浏览器中输入chrome://net-internals/#dns可以查看当前缓存的域名信息哦。2) 查找操作系统缓存即本地hosts文件,如果hosts文件中有相应的域名映射记录,则使用对应的IP地址。温馨提示:要当心恶意程序修改你的hosts文件来把特定的域名解析到它指定的IP地址上,导致这些域名被劫持。3) 当前面步骤都无法完成域名解析时,就要请求本地域名解析器(LDNS)来解析了。那么怎么知道域名服务器在哪呢?这个就是操作系统网络配置中的DNS服务器地址了。4) 如果LDNS仍然没有解析到,就直接到Root Service域名解析器请求解析。5) 根域名服务器返回给本地域名服务器一个所查询余的主域名服务器(gTLDServer)地址。gTLD是国际顶级域名服务器,如:.com/.cn/.org等,全球只有13台左右。6) 本地域名服务器再向gTLD服务器发送请求。7) 接收请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址,这个Name Server通常就是你注册的域名服务器(如你的域名供应商)。8) Name Server域名服务器会查询存储的域名和IP的映射关系表,正常情况下都根据域名得到目标IP记录,连同一个TTL值返回给DNS Server域名服务器。9) 返回该域名对应的IP和TTL值,本地域名服务器会缓存这个域名和IP的对应关系,缓存的时间有TTL值控制。10) 把解析的结果返回给用户,用户根据TTL值缓存在浏览器缓存中,域名解析过程结束。经过这么一系列查询,总算知道目的地在哪了,可以出发了吧。什么?还不行?奔溃中...为了大家安全着想,我们需要先向目的地发信息确认一下,路线是否畅通,是否有工作人员接站,要不然就有去无回了。先来个三次握手(TCP连接)吧。TCP连接在获取到服务器的IP地址后,便会开始建立一次连接,这是由TCP协议完成的,主要通过三次握手的方式建立连接:1) 第一次握手: 建立连接时,客户端发送SYN包(syn=i)到服务器,并进入SYN_SENT状态,等待服务器确认。2) 第二次握手: 服务器收到SYN包,必须确认客户的SYN(ack=i+1),同时自己也发送一个SYN包(syn=j),即SYN+ACK包,此时服务器进入SYN_RECV状态。3) 第三次握手: 客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=j+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。经过三次握手之后,我们就可以放心的出发了。NO NO NO,还要稍等片刻(估计大家已经崩溃了吧),先检查下火车头及车厢是否准备就绪(也就是封装HTTP消息头和消息体)。HTTP请求与响应 先来科普一下:HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW)服务器传输超文本到本地浏览器的传送协议。HTTP基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件,查询结果等),是一个属于应用层的面向对象的协议。 HTTP请求报文由三部分组成:请求行、请求报文头、请求报文体。下面是一个实际的请求报文: HTTP请求行包括请求方法、请求URL和HTTP协议及版本。1) GET和POST是最常见的HTTP请求方法,除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。2) 请求URL和报文头里的HOST属性拼接组成完整的请求URL。3) 当前使用的协议是HTTP/1.1版本,在此之前还有HTTP/0.9和HTTP/1.0。那么HTTP/1.1和HTTP/1.0有哪些区别呢?a. HTTP/1.1则默认支持长连接,HTTP/1.0中每对请求/ 响应都使用一个新的连接。b. HTTP/1.1在请求消息头多一个Host域,HTTP/1.0则没有这个域。c. HTTP/1.1增加了带宽优化的一些字段:比如range头域、100响应码、Content-Encoding等,具体细节在后续的优化篇中再详细介绍。d. HTTP1.1增加了OPTIONS、PUT、 DELETE、TRACE、CONNECT请求方法。e. HTTP/1.1中新增了24个状态响应码。HTTP请求报文头,以明文的字符串格式传送,是以冒号分隔的键/值对,如:Cache-Control: no-cache,每一个消息头最后以回车符(CR)和换行符(LF)结尾。HTTP消息头结束后,会用一个空白的字段来标识,这样就会出现两个连续的CR-LF。结构大体如下图所示:我们前面在介绍HTTP缓存时提到的Cache-Control字段,就位于请求报文头里。此外常见的HTTP请求报文头属性还有Accept、Cookie、Referer、Connection、Host、Content-Type等等。详细的报文头属性这里就不再介绍了,感兴趣的童鞋可自行查阅。Content-Type用来表示请求体数据的媒体类型信息,常见类型有application/json、text/xml以及application/x-www-form-urlencoded。浏览器负责发送HTTP请求,同时也接收返回的HTTP响应信息。HTTP响应报文同样由三部分组成:响应行、响应头和响应体。下面是一个实际的HTTP响应报文:响应行包含协议版本信息以及状态码和状态描述信息。HTTP响应状态码由5段组成:1) 1xx 消息,一般是告诉客户端,请求已经收到了,正在处理,别急...2) 2xx 处理成功,一般表示:请求收到、我明白你要的、请求已受理、已经处理完成等信息.3) 3xx 重定向到其它地方,它让客户端再发起一个请求以完成整个处理。4) 4xx 处理发生错误,责任在客户端,如客户端的请求一个不存在的资源,客户端未被授权,禁止访问等。5) 5xx 处理发生错误,责任在服务端,如服务端抛出异常,路由出错,HTTP版本不支持等。响应头结构和请求头一样,常见报文头属性有:Cache-Control、ETag、Location、Set-Cookie、Content-Type等。响应体则是服务器返回的数据了,可能是一个HTML页面,一个图片或者一段JSON数据。HTTP请求报文生成后,总算是可以出发了,祝大家一路顺风!HTTP请求发出之后,就交由指定的后台服务来进行处理(Web服务器或者反向代理服务器等),具体的处理过程,我们会在后续的《Web之旅-后端篇》中再详细介绍。终于来到了大家最感兴趣的环节,估计看了前面那么多繁琐的步骤,已经脑阔疼了吧。建议休息五分钟,然后再来看下浏览器获取到HTML页面后,是怎么一步步把界面渲染出来的。页面渲染在前面浏览器运行机制章节,我们有提到,浏览器是多进程的,每打开一个tab页就会创建一个新的进程,也就是渲染进程。渲染进程又是多线程的,各个线程之间相互协作,共同完成页面的渲染工作。那么各个线程是怎样的一个分工呢?简单来讲,GUI渲染线程按照从上到下的顺序解析HTML文件,当遇到任何样式(link、style)与脚本(script)时,就会调用异步请求线程去加载资源。加载到的CSS交给GUI渲染线程继续处理,JS文件则交由JS引擎线程去解析执行。当JS引擎线程解析遇到事件(如Ajax异步请求)时,提交任务给事件触发线程,由事件触发线程判断触发条件是否满足,满足时再交由JS引擎线程处理。对于setInterval和setTimeout方法,定时计数交给定时触发器线程处理,计时完毕后再交由JS引擎处理。从页面的渲染角度来讲,大概可以划分成以下几个过程:1) 解析HTML/SVG/XHTML,构造DOM树。Webkit中有三个C++的类来处理这三类文档,解析后会产生一个DOM树。2) 解析CSS构造CSS规则树。3) 解析JS,通过DOM API和CSSOM API 来操作DOM树和CSS规则树4) 通过DOM树和CSS规则树构造Render树,计算各元素尺寸和位置,即Layout/Reflow的过程。DOM树与HTML一一对应,而Render树会忽略诸如head、display:none的元素,并且附加CSS规则到Render树的每个节点(Element)上。5) 绘制Render树(Paint),绘制页面像素信息6) 浏览器会将各层的信息发送给GPU,GPU会将各层合成(composite),显示在屏幕上。整个解析过程,默认采用同步的方式进行。当解析到外部资源(CSS、JS)时,浏览器会启用异步请求线程去加载资源。如果是CSS资源,资源加载不会阻塞DOM树的解析,但是要在CSS加载完成后,才能构造Render树。如果CSS加载不阻塞render树渲染的话,那么当CSS加载完之后,Render树可能又得Repaint或者Reflow了,这就造成了一些没有必要的损耗。什么是Repaint和Reflow呢?Repaint(重绘):部分节点需要更新,但不改变其他集合形状。如改变某个元素的颜色是,就会发生重绘。Reflow(重排):Render树的部分更新,如尺寸变化,就会发生重排。为提高页面的加载速度,我们要尽量的避免页面的Repaint和Reflow操作。如果解析遇到外部JS资源,资源加载将阻塞DOM树的解析,直到JS解析完成后,再继续往下解析。这是因为JS是可操纵DOM的,如果在修改这些元素属性同时渲染界面(即JS引擎线程和GUI线程同时运行),那么渲染线程前后获得的元素数据就可能不一致了。因此为了防止渲染出现不可预期的结果,浏览器设置GUI渲染线程与JS引擎线程为互斥的关系,当JS引擎执行时GUI线程会被挂起,GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。所以如果JS执行时间过长,就会阻塞整个页面的渲染,我们要尽量避免这种情况,比如把JS脚本应用放到HTML的最后(</body>之前)。那如果耗时操作必不可少呢,别担心,JS里有一个叫Worker的类,可以帮助我们实现类似多线程的操作,感兴趣的童鞋可以去了解下。当然,JS也可以采用异步加载的方式,如HTML5在<script>增加的async和defer属性,可以让浏览器异步去下载并执行JS,而不阻塞页面的渲染。异步加载原理基本上都是向DOM中写入script或者通过eval函数执行JS代码,可以把它放在匿名函数中执行,也可以在onload中执行,也可以通过XHR注入实现,也可以创建一个iframe元素,然后在iframe中执行**JS代码。但是异步执行需要自行判断指定JS文件是否会对页面的渲染造成影响,否则会出现渲染异常的情况。这次旅程差不多到这里就要结束了,是时候挥手告别了。关闭TCP连接 建立TCP连接需要三次握手,关闭TCP连接则需要四次挥手。 第一次挥手是浏览器发完数据后,发送FIN请求断开连接。第二次挥手是服务器发送ACK表示同意,如果在这一次服务器也发送FIN请求断开连接似乎也没有不妥,但考虑到服务器可能还有数据要发送,所以服务器发送FIN放在了第三次挥手中。最后浏览器返回ACK表示同意,也就是第四次挥手。结束语 首先恭喜大家完成了此次的web前端之旅,通过这次旅程,大家应该对前端的整个加载机制有了初步的了解,如果还意犹未尽,可以参考《WebKit技术内幕》一书进行深入学习和研究。 同时我们也看到了,在整个页面的加载机制中,有很多复杂繁琐的步骤。而浏览器也已经做了很多的优化工作,那么对于前端开发来说,如何才能快速的获取和展示出我们想要的数据呢?下一篇文章《Web之旅-前端优化篇》,将针对每一个步骤,阐述如何进行优化,以达到极致体验。敬请期待。
-
1 【火爆】21天转型区块链实战营,开发者福利,学习前沿知识还能享受多重好礼! https://bbs.huaweicloud.com/forum/thread-10748-1-1.html 2 华为消费者云背后的微服务实践经验 https://bbs.huaweicloud.com/forum/thread-10676-1-1.html 3 虚机应用中如何接入应用运维功能 https://bbs.huaweicloud.com/forum/thread-10351-1-1.html 4 servicecomb启动报错An exceptionCaught() event was fired https://bbs.huaweicloud.com/forum/thread-10324-1-1.html 5 地图在手,使用无忧 https://bbs.huaweicloud.com/forum/thread-10557-1-1.html 6 5分钟Serverless实践|使用FunctionGraph构建无服务器的敏感词过滤后端系统 https://bbs.huaweicloud.com/forum/thread-10858-1-1.html 7 skr!是时候展现真正的技术了 https://bbs.huaweicloud.com/forum/thread-10777-1-1.html 8 详解如何实现在线聊天系统中的实时消息获取 https://bbs.huaweicloud.com/forum/thread-10460-1-1.html 9 【技术交流】从代码机制看AK/SK认证问题 https://bbs.huaweicloud.com/forum/thread-10335-1-1.html 10 大规模分布式系统性能测试实践 https://bbs.huaweicloud.com/forum/thread-10371-1-1.html 11 云应用立体运维解决方案使用场景全面介绍 https://bbs.huaweicloud.com/forum/thread-10456-1-1.html 12 vertx HttpClient使用的各种坑 https://bbs.huaweicloud.com/forum/thread-10550-1-1.html 13 大规模分布式系统性能测试实践 https://bbs.huaweicloud.com/forum/thread-10369-1-1.html 14 【系列视频课程03】实战:部署第一个区块链实例 https://bbs.huaweicloud.com/forum/thread-10338-1-1.html 15 5分钟-基于FunctionGraph构造无服务器图片鉴黄Web应用 https://bbs.huaweicloud.com/forum/thread-10667-1-1.html 16 Serverless架构介绍 https://bbs.huaweicloud.com/forum/thread-10509-1-1.html 17 详细剖析华为云应用立体运维解决方案 https://bbs.huaweicloud.com/forum/thread-10437-1-1.html 18 【转载】5分钟Serverless实践 | 使用FunctionGraph构建无服务器图片鉴黄Web应用 https://bbs.huaweicloud.com/forum/thread-10847-1-1.html 19 有Serverless真的可以为所欲为--深入浅出介绍华为云FunctionGraph产品 https://bbs.huaweicloud.com/forum/thread-10931-1-1.html 20 【云端大事件】宏天软件入驻华为云市场,助力企业流程升级! https://bbs.huaweicloud.com/forum/thread-10428-1-1.html
-
内容速览:---前言---Serverless优势---构建无服务器的图片分类Web应用---构建事件触发的实时图片分类系统前 言在过去“5分钟Serverless实践”系列文章中,我们介绍了如何构建无服务器API和Web应用,从本质上来说,它们都属于基于APIG触发器对外提供一个无服务器API的场景。现在本文将介绍一种新的设计模式:基于事件的实时数据处理。为了更形象地描述,我们以图片分类为例,先介绍通过APIG触发器如何构建一个图片分类的Web应用,再介绍通过OBS触发器如何构造一个实时的图片分类系统。 Serverless优势相比于传统的架构,无服务器架构具有如下优点:1. 无需关注任何服务器,只需关注核心业务逻辑,提高开发和运维效率;2. 事件触发,灵活扩展;3. 函数运行随业务量弹性伸缩,按需付费,执行才计费,对于负载波峰波谷非常明显的场景可以减少大量成本;4. 通过简单的配置即可连通函数工作流和其它各云服务,甚至云服务和云服务; 构建无服务器的图片分类Web应用像以往的文章介绍的那样,serverless很擅长构建一个Web应用,如下图,该系统会将用户上传的图片进行分类,并打上类别标签。 我们可以通过函数工作流服务来快速构建这个系统,并且完全无需关注服务器,且弹性伸缩运行、按需计费,如图:创建函数,在函数中调用华为云图片分析服务的图片标签接口,给图片打标签分类。再为该函数配置一个APIG触发器,这样便可以对外提供一个图片分类的API,最后部署前端页面到OBS,托管为静态网站,从而构建出一个完整的图片分类的无服务器Web应用。页面调用API,他会自动触发函数执行,而开发者编写的函数只需实现接收到图片之后如何处理图片的逻辑即可,最后将结果返回给页面。 接下来,我们将介绍如何完整地将此无服务器Web应用构建出来。 1. 准备工作进入华为云图片检测服务,申请开通图片检测服务的图片标签功能,成功申请后便可以调用图片标签接口了。 2. 构建后端程序进入函数工作流服务,选择模板“图片打标签Web后端”,创建函数。函数创建完成之后,为其配置具有IAM访问权限的委托,因为本函数代码中获取用户的ak、sk需要拥有访问IAM的权限。 创建成功后,API的URL可以在函数详情页面的“触发器”栏看到:至此,我们就成功地构建了一个无服务器的图片分类API。 3. 搭建前端页面为了更方便地搭建前端页面,我们提供了对应的函数模板实现快速构建前端页面。选择模板“图片打标签Web前端”,创建函数,其中自定义数据REST_API中设置上一步创建的API URL,创建完成后,函数详情页面的“触发器”栏中的URL就是页面的浏览器访问地址。至此,我们就成功地构建了一个无服务器的图片分类Web应用。接下来,我们将介绍另一种场景。 构建事件触发的实时图片分类系统本文接下来将具体介绍事件触发的实时数据处理场景,考虑下面场景,用户上传图片到OBS桶中,需要自动执行图片分类,并按照类别转储到另一个桶的不同目录下。比如下面这个例子,上传一张企鹅图片到一个桶,图片就会自动转储到另一个桶对应的penguins、seabird、bird目录下。 我们可以通过函数工作流服务来快速构建这个系统,并且完全无需关注服务器,且弹性伸缩运行、按需计费,如图:创建函数,在函数中调用华为云图片分析服务的图片标签接口,给图片打标签分类。再为该函数配置一个OBS触发器,监控桶的POST事件,当向该桶上传一个文件时,便会自动触发函数执行,从而实现一个基于事件触发的无服务器系统。用户向桶中上传一张图片,它会自动触发函数执行,而开发者编写的函数只需实现从桶中下载图片并分类转储的逻辑即可。 接下来,我们将介绍如何完整地将此事件触发的图片分类系统构建出来。准备工作1. 申请开通图像识别服务“图像标签”功能2. 进入对象存储服务(OBS)服务,创建两个桶,一个用于接收待分类的图片(source),一个用于存储分类后的图片(result),并将桶的“桶策略”设为公共读写。 创建函数1. 进入函数工作流服务创建函数页面,选择“图片实时分类(按图片类型)”函数模板,该模板已为您提供本案例的代码。 2. 设置环境变量result_bucket为存储分类后图片的桶的名称(result)3. 配置OBS触发器,桶选择接受待分类图片的桶(source),事件选择post。当向桶中上传新图片时,会触发函数执行。4. 点击创建,创建函数和触发器。 配置函数1. 进入函数详情页面,进入“配置”标签,给函数设置一个具有访问IAM和OBS权限的委托,使函数能够获取到用户的AK、SK,并访问OBS桶资源。2. 保存配置 测试函数1. 向接收待分类图片的桶(source)中上传一张图片2. 查看存储分类结果的桶(result)中的文件,会发现图片存储到了对应类别的目录下。 更多精彩:函数工作流,0负担享受编程的乐趣
-
本期【云享专家·微话题】由云享专家 HuangJacky 与大家一起探讨“云端WAF技术”,希望大家能够畅所欲言。如果大家有其他相关的问题,也可以在本帖回复直接咨询云享专家 HuangJacky 。=======【云享专家·微话题】云端WAF技术 =======随着云计算的普及,客户更多业务迁移到云上,以往传统的配套安全服务也转变云上SaaS服务,Web应用防火墙(WAF)对业务无侵入,来划分安全和业务开发的职责,大大减轻业务安全工作量,因此成为云上客户标配安全服务之一。然而云上客户业务的多样性,流量大,这些都对云WAF提出了新的挑战。为了应对这些挑战,云WAF不断引入新的技术,比如利用机器学习打造更加智能更贴合业务的检测引擎,利用DPDK技术打造更高并发网关。我们始终相信技术创造未来,开启云WAF新时代。每个人对“云端WAF技术”都有不一样的理解,今天我们就“云端WAF技术”一起来讨论,希望看到大家精彩的评论:1. 云WAF和传统WAF的区别?2. 云WAF遇到的问题和误报?3. 机器学习和云WAF能做什么?4. 你期望云WAF应该具备哪些功能?微话题活动:参与本次微话题讨论,有机会获得优质评论奖活动时间:2018年8月20日-9月2日参与方式:直接在本帖回复你关于以上4个问题的理解或评论获奖方式:活动结束后,将由云享专家 HuangJacky 选取出3名优质评论奖,各送出《白帽子讲Web安全》书籍1本。
上滑加载中
推荐直播
-
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家;李炎-华为云码道产品专家;彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战,从0到1打通消息通道;码道鸿蒙端云一体化实战,快速搭建员工签到系统。
回顾中 -
华为云开发者AI素养直播课·第五期2026/09/04 周五 16:00-18:00
林华鼎-华为云AI开发者运营负责人;蒋春阳-华为云AI开发者案例开发专家
本期直播内容: AI工具体验营 · 第5-8课连讲。Agent-Team 多智能体协作完成毕业设计实践
回顾中 -
华为云开发者AI素养ClassRoom·第六期2026/09/08 周二 19:00-20:00
樊渊-2026华为软件挑战赛冠军
高手来了:看软挑高手解析二维排样问题—从工业难题到算法突破
回顾中
热门标签