一、概述   作为一个码农，在成长过程中总是有各种各样的挑战，面对这些挑战很对人又不知该如何解决。而作为成长方向上为数不多的有光明前途的平台设计者，可以拥有更多的“机会”，也是团队中可以指引整体发展方向的“引导者”，在组织中拥有“重要”的地位。   当然先成长为一个优秀的“开发者”对升级成为一个平台设计者会更有帮助，以前的文章也有探讨过研发思维的建设，传送门在这里 码农进阶中的思维变化。   回归正题，多数程序员成长过程中经常会遇到不知怎么将一个很好的东西变成高大上的产品的问题，或者说不知道该更方便的提供/邀请给其他人使用，这里介绍平台化设计思维或者说方向，可以给大家提供一个思路。 二、定义  平台：它是一个基础设施，可以提供 “资源”、“交流”、“服务”等内容，并制定完善的规则，使各种角色的用户可以制作或者获取到特定的内容。 三、如何拥有平台化思维 3.1、为啥要做“平台”   这里我们先探讨“如何拥有”平台化思维，让我们先有个潜意识的就会往那边想，至于“如何设计”，我们下一章节讨论。   为何我这里说“我们先有个潜意识“，是因为我发现日常工作中很多能力强的小伙伴其实都有不错的”研发能力“、”效能思维“、”行动能力“等，然后工作中遇到问题后开发出来了一个”工具“提升了自己的开发效率或者沟通效率，但是却止步于此，比如一个调试工具、一个多端编译工具、一个上传工具等，这些“工具”都有一个普遍的特点，那就是：“单向服务无组织规则”、“功能共享使用者却无法约束”、“生产的数据不共享”、“即使开源也得不到发展”，因此我们要做“平台化”，建立一个基础设施，作为一个“平台”，上面的用户(内容提供者、内容使用者)可以有机的组织到一起，使服务更加流畅、用户各司其职、信息共享更加方便、发展更加迅速，那么如何建立这种“平台化思维”呢，我这里有一个简单的方法-“两步七问”，即：   第一步：规划，时刻谨记我们需要成长和成果，因此我们需要一些更耀眼的“内容”    ●要不要功能更强大一些；    ●要不要推广更广泛一些；    ●要不要做成独一无二(一定范围内)；   第二步：落地，判断能不能做成“平台”    ●可以共享使用功能和数据吗？    ●可以让更多人来自主“生产”内容吗？    ●需要统一管理用户和使用规则吗？    ●需要有更多人来一起发展吗？   以上要时刻提醒、锻炼自己，形成一定的思考习惯，在做之前先“思考”，不然遗忘或者没这个想法，那自己设计开发的东西就发展不起来，甚至可能启发其他人并被占先； 3.2、平台化思维如何建立   上面的3.1小章节只是用来让大家时刻谨记“要不要”和“是否适合“的，接下来我们思考平台要做成什么样，也就是“平台化”的“战略目标”； 这里简单画了一个思维导图，大家看起来可以更加直观。 [图片] 3.2.1、定位   对应图里的”解决什么问题“，也就是我们这个”平台“是用来做啥的，是个”工具平台“、”电商平台“，还是”管理平台“、”娱乐平台“，有了目标才能规划功能，这里简单罗列了几个方向。   需求：范围较广，比如来自产品、研发、测试等等；   效率：提高服务、内容生产的效率，如商城、后台管 理等；   降本：降低了”工作内容“的成本，如开源社区、工具类平台等； 3.2.2、角色   角色即使用此平台的所有构成者的身份，粗略划分为“内容使用者”、“内容提供者”、“中心化服务”，真实用户又可以划分的更加细致，比如后台管理员、会员等级1、会员等级2、普通会员等 3.2.3、组织   组织即平台通过一定的“规则”使所有使用者、内容形成一定的规范，可以形成功能闭环，不同部分各司其职，共同组成了一个“平台”。我们可以这样假设，现在有一堆人、有不同的需求，但是“人”能够去哪、“看”到什么东西、“制作”出什么东西、如何“交流”，这都是零散的、独立的，是个无效、无意义的“组合”，只有通过一定的“规则”“组织”起不同的部分，提供一个平面上，“用户”可以到不同的“地方”，“看”或者“制作”不同的“内容”，这样才能性能一个有效的“系统”。所以一个“平台”需要提供两方面内容：“制定规则”、“提供基础服务”。 3.2.4、发展   一个“平台“若不发展，迟早要没落，要想发展，那就需要提供“更多功能”吸引“更多人”来使用，“更多人”来提供“更多功能”。简单理解就是用户更多、开发更多，那么从一个平台来说，在不谈主动推广，只探讨自然生长的情况下，如果做到“更多人”来开发呢？现在有个比较好的模式就是“生态”，开放出去一部分能力，让更多的人基于“开放”去制作更多的“内容”和”功能“，类似“插件”。这些”插件“越来越多，功能越来越强大，使用的人也就越来越多。 四、如何设计一个平台  上面已经讲了“战略”，接下来我们思考“战术”，即一个平台该“怎么做” 4.1、公式 [图片]   为了方便大家的使用，简单总结了一个公式(大家可以一起来完善它)如上，这里简单介绍一下：    ●“角色A和B”：用户    ●“可以”：权限    ●“动作”：规则    ●“内容X”：数据    ●“越来越多、很多”：生态    ●整体表达：需求 4.2、思维导图   为了方便大家理解，我们还是画个图 [图片] 4.2.1、定位   思考方向主要有：    ●用途，提供给什么人什么服务，大方向上制定目标    ●发展方向，细分市场，提前做好规划    ●竞争对手，对比竞对，思考优势劣势 4.2.2、角色   尽可能多的争取到更多的用户，划分出各种角色，后续可方便规划“需求”、“规则” 4.2.3、规则   可分为如下的内容(粗略)：    ●用户管理：包含登录、注册、权限等    ●内容管理：包含制作、存储、删除、获取等    ●数据管理：包含统计等    ●业务逻辑：包含使用规则、功能服务逻辑、流程逻辑等 4.2.4、生态   “插件”的设计规则：    ●准入规则：登录、权限等    ●开放规则：“平台”基础服务、规范、兼容等    ●制作规则：开发、调试、发布、定价等    ●容器规则：跟平台的”融合“逻辑等    ●使用规则：购买、打烊、过期等    ●管理规则：禁用、删除、推广、分账等    ●其他：安全、审核、文档等 五、举个栗子🌰 5.1、背景   笔者曾经接到过一个C端消息通知的需求，要求是服务端推送消息给C端，我们可选择的是自研和购买第三方服务，经过调研对比了：功能、性能、成本、兼容性等多个方面打算自研，那么很自然而然的想到要实现这个需求，我们可以建一个服务提供生成消息、发送消息、存储消息等等，然后实现一个客户端sdk，用于接收消息和处理消息。需求实现了，皆大欢喜了，然而我们是否就可以满足了？结项了？ 接下来让我们用今天讨论的平台化设计思维再来思考一遍。 5.2、战略思考   两步七问，规划和落地：    ●要不要功能更强大一些     ○当前的需求确实简单，一推一收即可，将来会不会有黑名单、群发、根据特定的产品范围发、是否有c端向服务端发送的消息？可以跟产品探讨一下。更多的功能是否就可以有更多的沉淀、更多的收获、跟多的发展？     ○- 要    ●要不要推广更广泛一些     ○当前是一个产品功能在用，公司或集团下有没有其他部门也有类似的需求？更多人使用我们的价值产出是否就更大，甚至将来作为isv开放给外部企业使用，未来的“钱途”是否也会更好？     ○- 要    ●要不要做成独一无二(一定范围内)     ○是否可以设计成一个统一的系统，不同的人可以划定一个“私有区域”，可以管理只跟”自己“相关的内容，比如成本、消息管理、权限管理？然后让大家都来使用，完全“垄断”某一个范围？ps：垄断的好处就不用说了吧～     ○- 要    ●可以共享使用功能和数据吗？     ○不同部门的产品同样有此类需求，达到“总成本”降低     ○可以    ●可以让更多人来自主“生产”内容吗？     ○不同的需求需要生成不同的“消息”     ○可以    ●需要统一管理用户和使用规则吗？     ○多团队使用时，需要管理不同的成本单元用户；也需要管理c端不同权限以及名单的用户和使用规则     ○需要    ●需要有更多人来一起发展吗？     ○可以开放一些插件(消息处理方向)，比如针对特定消息内容可以类型转换、展示不同交互，让不同的团队自己实现自己的“功能“，减少本团队的人力成本     ○不确定   结论：有做成平台的必要性 5.3、战术思考   根据公式： {“越来越多”} {“角色A”} {“可以“} 通过平台 {“动作”} {“很多”} {“角色B”} {“动作”} 的 {“内容X”}   思考如下：    1、定位：面向公司内部的需求，实现客户端、服务端之间的消息通信，将来可以开放给其他外部企业付费使用，简单易接入、兼容各个平台、功能完善定位于基本的消息处理并深度挖掘业务使用场景(抛弃如视频、语音等场景)、费用比竞对低、稳定安全有保障；    2、角色：不同研发、不同消息生产者、不同消息接收者、其他功能扩展开发者；    3、规则：设计一个平台，包含：运营管理系统、后台管理系统、用户端sdk/消息页等，囊括的逻辑有，用户身份相关和权限管理、消息产生发送接收流程、组织间“数据”独立和组织管理、数据(消息)的流转保存统计、成本管理等；    4、生态：即插件的设计规则，如接口定义、上传和使用规则、审核和更新流程等   最后，通过相关的“产品”设计、“UI”设计、“架构”设计、“流程”设计、“开发”设计，逐步实现整个平台。 六、最后   还是那句话，我们每个人都需要成长，从最初写一个“方法”的代码、到写一个“功能”、实现一个“模块”、跟一个”项目“、设计一个”架构“、搭建一个”平台“，这一个又一个的阶段有不同的目标也有不同的思维模式，我们要不停的改变、不停的成长、不停的思考才能应对不同的问题或者目标，一种思维模式也需要慢慢养成一种习惯。 好了，我的分享结束，希望能对大家有用，如有问题请及时与我反馈，我们一同进步～😄

Figma已经成为很多人喜爱的UI/UX设计工具。同时,React配合Tailwind CSS也是一个流行的前端技术栈。如果能够从Figma设计自动生成使用Tailwind CSS样式化的React组件可以提供一种自动化方案! 在这篇文章里,我将展示如何使用Figma API,将Figma设计转换成带有Tailwind CSS类的React组件。 概览 主要步骤如下: 使用Figma API从Figma文件中提取节点数据 获取节点中使用的图片资源的映射 扁平化和优化节点树结构 将图片引用映射到URL 将节点转换成React/JSX的AST抽象语法树 从AST生成React组件代码 为每个组件创建Next.js页面文件 下载图片资源和写入组件文件 最终结果是带有Tailwind CSS类的React组件,样式与Figma中的设计相匹配。 从Figma获取节点数据 首先我们将使用Figma API从Figma文件中获取节点数据。我们可以指定文件key、需要的节点以及像获取向量数据这样的可选参数: [代码]type MixedNode = | FrameNode | RectangleNode | InstanceNode | TextNode | VectorNode | GroupNode | BooleanOperationNode | EllipseNode; const getFigmaFileNodes = async ({ fileKey, accessToken, nodeIds }) => { const query = qs.stringify({ ids: nodeIds, geometry: "paths", }); const url = `https://api.figma.com/v1/files/${fileKey}/nodes?${query}`; const res = await fetch(url, { method: "GET", headers: { "X-FIGMA-TOKEN": accessToken, }, }); let nodes: MixedNode[] = []; const document = await res.json(); for (let key in document.nodes) { nodes.push(document.nodes[key].document); } return nodes; } [代码] 上面的代码一每个document下的节点作为每个react组件的节点数据 这将返回包含id、name、节点位置、填充等信息的节点的多叉树。这个多叉树正好可以映射成jsx element。下面就是考虑应该怎么样去转换代码。（更多的节点细节可以参考figma官网的文档） 下载图片资源 许多设计使用了图片填充,所以我们需要下载文件中使用的图片: [代码]const getImagesInFile = async ({ fileKey, accessToken}) => { const query = qs.stringify({ ids: nodeIds, }); const res = await fetch( `https://api.figma.com/v1/files/${fileKey}/images?${query}`, { method: "GET", headers: { "X-FIGMA-TOKEN": accessToken, }, } ); const data = await res.json(); return data.meta.images; } [代码] 这将给我们一个从图片ID到图片URL的映射。 需要注意的是这里面返回的图片资源是原始的图片，但是在figma中使用的图片一般都经历过裁剪, 旋转等，所以我们还需要写一个 图片服务来专门处理图片的压缩，裁剪。这个可以再另外一遍文章里介绍。 映射图片引用 我们可以遍历节点,将任何节点填充对应的引用映射到已下载的图片hash: [代码] const getImageRefsInNodes = (nodes, imagesMap) => { const getImageRefsInNodes = ( nodes: MixedNode[], imagesMap: { [key: string]: string } ) => { let imageRefsMap: { [key: string]: string; } = {}; for (let layerNode of nodes) { traverseNode(layerNode, null, { All: { enter(node, parentNode) { for (let fill of node.fills) { if (fill.type === "IMAGE") { if (fill.imageRef) { imageRefsMap[fill.imageRef] = imagesMap[fill.imageRef]; } } } }, }, }); } return imageRefsMap; }; [代码] 这个映射之后在生成图片组件时会用到。代码中的[代码]traverseNode[代码]用的是一种设计模式（访问者模式）,一般就是应用在处理 ast节点转换成另外一种ast的情况。这里面使用非常合适。 [代码] type ExtendMixedNode = MixedNode & { ast?: t.JSXElement; }; const traverseNode = ( node: ExtendMixedNode, parentNode: ExtendMixedNode | null, visitor: Visitor ) => { let methods = visitor[node.type]; if (methods && methods.enter) { methods.enter(node, parentNode); } let methodsAll = visitor["All"]; if (methodsAll && methodsAll.enter) { methodsAll.enter(node, parentNode); } if (Array.isArray(node.children)) { for (let i of node.children) { traverseNode(i as ExtendMixedNode, node, visitor); } } if (methods && methods.exit) { methods.exit(node, parentNode); } if (methodsAll && methodsAll.exit) { methodsAll.exit(node, parentNode); } }; [代码] 优化节点树结构 事实上ui给的设计稿中 节点的结构。并不总是按视觉的结构那样是一颗从大到小，从里到外的这样一颗节点树。而可能是一颗很随意分布的节点，这样其实不利于未来的代码维护。造成这种情况是figma节点布局有两种，一种是类似于浏览器的flex布局，这种布局方式产生的结构是有序的。还有一种是absolute的布局,这种布局是无序的排列中layer上。同是absolute的布局是基于整个文件的canvas图层的左上角来布局的，这块的属性我们也需要处理。 [代码] const walk = ( node: MixedNode, parentNode: MixedNode | null, rootOffset: { x: number; y: number; }, flattenResult: OptimizedNode[], flattenNodeMap: { [key: string]: OptimizedNode; } ) => { const { children, ...rest } = node; let optimizedNode = rest as OptimizedNode; if (parentNode) { optimizedNode.parentId = parentNode.id; optimizedNode.absoluteBoundingBox.x -= rootOffset.x; optimizedNode.absoluteBoundingBox.y -= rootOffset.y; } else { optimizedNode.parentId = null; rootOffset.x = node.absoluteBoundingBox.x; rootOffset.y = node.absoluteBoundingBox.y; optimizedNode.absoluteBoundingBox.x = 0; optimizedNode.absoluteBoundingBox.y = 0; } // 过滤掉不显示的节点 if (isBoolean(node.visible) && !node.visible) { return; } if (isNumber(node.opacity) && node.opacity === 0) { return; } flattenResult.push(optimizedNode); flattenNodeMap[optimizedNode.id] = optimizedNode; if (Array.isArray(node.children)) { for (let i of node.children) { walk(i as MixedNode, node, rootOffset, flattenResult, flattenNodeMap); } } }; [代码] 上面是将absolute布局转换成浏览器的模式按父节点的非static布局的位置来布局。同事将视觉上不显示的节点隐藏掉。 还有一部分就是更改节点的位置这一部分代码可以按照自己的业务需求，合并,移动节点。这一部分代码就不展示了。 将节点转换成JSX AST 现在我们可以遍历优化后的节点,将其转化成React JSX AST。我们将为每种节点类型写个处理函数: [代码]const transformNodeToAst = (node) => { switch(node.type) { FRAME: { enter(node, parentNode) { let ast; const imagesAst = getNextImageAst(node.fills, node); if (imagesAst.length > 0) { ast = template.expression.ast( nodeTemplate(node, parentNode, "", false), { plugins: ["jsx"], } ) as t.JSXElement; ast.children.push(...imagesAst); } else { ast = template.expression.ast( nodeTemplate(node, parentNode, "", !node.children), { plugins: ["jsx"], } ) as t.JSXElement; } node.ast = ast; }, exit(node, parentNode) { if (parentNode && parentNode.ast && node.ast) { if (Array.isArray(parentNode.ast.children)) { parentNode.ast.children.push(node.ast); } else { parentNode.ast.children = []; } } }, }, case "TEXT": let textAST = jsx`<Text>`; return textAST; // ...其他类型 } } [代码] 构建AST时,我们将其挂载到父节点下,以保证正确的嵌套结构。 生成组件代码 为生成组件代码,我们可以使用模板字符串包装根AST: [代码]const generateCode = (ast) => { let programTemplate = template.program(` import React from 'react'; import Image from 'next/image'; const Section${index} = () => { %%sectionArrowFnBody%% } export default Section${index} `); const ast = programTemplate({ sectionArrowFnBody: t.returnStatement(jsxElement), }) as t.Node; return generate(ast).code; } [代码] 我们可以为每个顶级AST调用此方法,现在就得到了生成的React组件代码! 创建Next.js页面 为方便使用,我们可以为每个组件创建自己的Next.js页面文件。 首先创建pages/components文件夹。然后遍历组件,写入文件,下载图片: [代码]components.forEach((component, i) => { fs.writeFileSync( `./pages/components/Section${i}.js`, component ); downloadImages(i); }); [代码] 现在我们有独立的组件文件和图片资源啦! 添加Tailwind CSS样式 到现在我们只有原生的JSX代码。为添加样式,我们可以遍历节点并为如下属性生成Tailwind类名: 布局定位 布局模式 尺寸大小 颜色 效果 边框 下面是布局定位的代码 [代码]const getTailwindClasses = (node) => { if ( node.type === "FRAME" || node.type === "INSTANCE" || node.type === "GROUP" ) { if (node.layoutMode) { classNames.push("flex"); if (node.layoutMode === "HORIZONTAL") { classNames.push("flex-row"); } if (node.layoutMode === "VERTICAL") { classNames.push("flex-col"); } // auto layout children if (node.layoutAlign) { classNames.push(`self-${node.layoutAlign.toLowerCase()}`); } // TODO if (node.counterAxisSizingMode) { if (node.counterAxisSizingMode === "AUTO") { } if (node.counterAxisSizingMode === "FIXED") { } } if (node.counterAxisAlignItems) { if (node.counterAxisAlignItems === "CENTER") { classNames.push("items-center"); } if (node.counterAxisAlignItems === "BASELINE") { classNames.push("items-baseline"); } if (node.counterAxisAlignItems === "MAX") { classNames.push("items-stretch"); } if (node.counterAxisAlignItems === "MIN") { } } if (node.primaryAxisAlignItems) { if (node.primaryAxisAlignItems === "CENTER") { classNames.push("justify-center"); } if (node.primaryAxisAlignItems === "SPACE_BETWEEN") { classNames.push("justify-between"); } } if (node.itemSpacing) { classNames.push(`gap-[${node.itemSpacing}px]`); } } } if ( parentNode && (parentNode.type === "FRAME" || parentNode.type === "INSTANCE" || parentNode.type === "GROUP") ) { if (!parentNode.layoutMode) { classNames.push( ...getPositionClassNames(node, parentNode === null ? node : parentNode) ); } } else { classNames.push( ...getPositionClassNames(node, parentNode === null ? node : parentNode) ); } if (node.type === "VECTOR") { if (isNumber(node.layoutGrow)) { classNames.push(`grow-[${node.layoutGrow}]`); } } return classNames; } [代码] 关键是将Figma的样式属性映射到相应的Tailwind CSS实用类。 我们可以在转换AST时为元素应用这些类。 总结 通过这种方式,我们可以从一个Figma设计文件直接生成带Tailwind CSS样式的React组件,可以直接导入前端代码库中使用。 优点是设计师和开发可以在自己偏爱的工具中独立工作,同时保持一致的实现。 一些可以扩展的方向包括: 支持更多节点和样式类型 生成响应式样式类 更好地处理文本样式和图片组件 优化SVG处理 但这为从设计自动转换为代码奠定了坚实的基础。 所以下次需要从Figma构建某些设计时,不必从零开始编码 - 使用为设计定制的React组件自动生成代码骨架吧!

小程序性能优化课程基于实际开发场景，由资深开发者分享小程序性能优化的各项能力及应用实践，提升小程序性能表现，满足用户体验。

微盟小程序SaaS业务演进 小程序SaaS是什么？简单来说，就是微盟基于底层的技术能力，为企业提供不同场景下的智慧商业解决方案，让传统行业的客户不需要任何技术的投入，也能享受智能互联的便利。 以某零售客户为例，他仅仅只需要在微盟新云平台上创建店铺，选用模板页面或者进行一些可视化搭建，就可以快速生成一个在C端消费者的微信中显示的微信或小程序商城。C端用户在小程序中可以浏览店铺、查看商品、下单购买、申请会员等，形成一个交易闭环。 [图片] 自2013年成立之初，微盟在构建SaaS服务方面便投入了很多资源，推出了适用于不同行业的解决方案，随着业务的深入发展，越来越多的大客户、品牌客户入驻，客户的需求变得更加多样，一方面，体现在前端的展现形式和消费者使用体验上；另一方面客户需要智能的后台管理，提升运营效率。 虽然，各行各业的客户都有着不同的需求，但是我们发现在技术底层上有很多可以共享的能力。因此，基于在SaaS服务上积累的经验和新技术，2017年微盟对旗下产品架构系统进行全新技术变革和战略升级，深化微盟软件产品的全行业平台能力，统一旗下用户、商户、服务商系统，构建线上线下融合、全渠道营销、开放互通的智慧商业服务生态体系。 [图片] 微盟小程序SaaS在前端应用上的挑战 SaaS前端应用，具有流量大且难预测、极致追求速度体验、自定义模板和功能需求强、多渠道等特点。微盟丰富的产品矩阵，如何能高效整合前端应用，快速满足客户的多元需求，提升小程序运行效率，成为微盟现阶段面对的挑战。 细分下来，在前端上，面临着3类挑战： 第一类挑战在C端，在确保高峰期流量稳定的同时，缩短页面加载时长，进一步优化用户体验。 第二类挑战在B端，B端客户有着不同的需求，比如小程序有近3000多个页面，我们需要提升页面的复用率。 第三类挑战是多渠道，随着去中心平台的进一步发展，客户也将在不同的渠道展开商业布局，如何确保微盟小程序在不同的平台和渠道的适配性，提高效率，这也是微盟面临的重要挑战。 [图片] 微盟SaaS前端应用优化实践 面对上面的问题，微盟是如何解决的呢？微盟在技术栈的选择上，侧重在稳定、成本、便捷、安全、服务等五个方面。基于此，微盟选择了微信和腾讯云联合推出的小程序·云开发。 1）基于云开发的架构优化 自云开发被集成于微盟SaaS系统中后,微盟的小程序SaaS接入微信的流程得到简化,可以免鉴权直接调用微信开发接口,并且实现云端解密。相比传统开发模式,“小程序·云开发”在登陆流程的终端性能提升50%以上,效果明显。 第一是微信小程序的接口调用流程得到了优化。 [图片] 举个再具体一点的例子，大家做微信开发很常见就是静默授权。 我们做了一个测试，使用了云开发中的云函数和没使用的，在性能上有3倍的差别。因为云开发的云函数和微信是一个整体，我可以把它合在一起看，他们只需要跟我们的后端进行一次交互就可以达到我们的目标了。但在之前，我们的微信客户端到我们的服务器，再到腾讯微信的服务器，有三次公网请求。我们通过接口减少和链路优化极大地减少这方面的性能损耗，所以终端的体验，从1.15秒直接降到421毫秒。 [图片] 另外用户授权，我们也通过结合云开发中的云函数来做这个事情。从1.17秒降到820毫秒。 [图片] 第二是云开发享有微信私有协议，能够帮助微盟的系统运营更加稳定。比如，基于云函数开发营销活动、节日大促等前端应用，技术人员可以专注于业务逻辑，不用操心运维和扩容方案，研发效率得到极大的提升。 再有，云开发提供更友好的开发体验，同时也支持微信第三方平台，这帮助微盟研发团队提升研发效率。 最后，是更安全。利用云函数，等于在微盟已有的安全防护体系外再进一步叠加腾讯云和微信的安全保障机制,微盟客户的小程序安全性将再提高一个台阶。   2）基于微盟微前端Kraken的优化 微盟SaaS软件目前给超过300万商户提供服务，除了对稳定性要求非常高之外，提高客户的操作效率也至关重要。因此，微盟内部对微前端进行升级和优化，以提高微盟的整体研发效率以及提升B端商户的操作体验，这个项目我们取名为Kraken。 [图片] 举个简单的例子，我们B端客户在新云平台做后端搭建的时候，往往需要做不同的创建动作，完成页面创建。我们通过微前端的建构帮助客户在一个页面停留时就能完成不同的操作需求，提升创建的流畅感，保证良好使用体验的同时，提高效率。具体来说，做一套微前端的架构有一下几个好处：  无刷新，不同子应用之间路由跳转不需要 刷新整个页面，极大提高用户体；兼容多框架，各子应用不限制框架 ；独立部署，各子应用独立发布和部署，能适应不同团队，快速发布，快速回滚；海量页面，支持上千级别；页面的加载与渲染，无限扩容；快速响应，开发更灵活，能快速响应产品需求的迭代和变化。[图片] 3）监控优化 微盟开发了一套APM系统，我们称之为HOUND，它能将消费前端与后台的数据进行融合，同时还能将不同端(小程序、H5)的数据结合在一起，实时监控。比如，我们能够准确、快速的查询到某个页面加载慢的原因以及给出解决办法。 [图片] 通过APM系统，我们提高了研发效率，提升了项目质量。 未来,微盟在小程序的重心，将充分利用“小程序·云开发”的技术优势,把合适的前端应用迁移至云开发的云函数中，进一步提升微盟小程序产品的体验和服务质量。 分享嘉宾：微盟CTO 黄骏伟关于微盟：微盟成立于2013年，是中国领军的企业云端商业及营销解决方案提供商，致力于通过产品和服务，助力企业向数字化转型，通过科技驱动商业革新，让商业变得更智慧。  

微信公众平台下的「第三方平台」开放给所有通过资质认证的开发者使用。在获得公众号或小程序运营者授权后，第三方平台开发者可以通过调用微信开放平台的接口能力，为公众号或小程序的运营者提供全方位服务。

微信云托管是为开发者提供的后端服务云原生解决方案，支持托管任意语言及框架的容器化应用，创建环境即可享受能自动扩缩容的容器资源，用户可面向代码/镜像等方式使用，免服务器、免运维。

重磅打造的小程序学习路径课，从微信小程序到微信云开发体系化的学习，带来更加顺畅的学习体验。