一、前言 路由是现如今移动端开发中不可或缺的功能，尤其是对于跨平台的大型移动端应用，不同平台之间的页面跳转更为复杂，好的路由设计方案可以提升开发效率，降低代码维护成本，达到事半功倍的效果。 二、背景 基于移动端业务动态化发版，还有提高人效的诉求，微盟商户助手接入了跨平台技术方案，为了可以更好的管理各个平台之间的页面跳转，需要用到路由框架，而目前市面上主流的路由框架功能都比较单一，只能够满足原生页面之间的跳转，同时也无法动态下发路由 URL，无法满足当前交互跳转的诉求，还有不同版本需要支持不同页面跳转等复杂的业务场景，基于此我们自研了一套涉及到前后端一体化的路由交互框架。 三、需求分析 为了保持三端（Android，IOS，小程序）页面路由跳转的统一性，支持不同平台页面之间的跳转，提升页面跳转的自由度以及降低真实 URL 的维护成本，路由设计需要满足以下几个条件： 1.路由URL需要根据不同的平台隔离配置。 2.应用不同版本单个触发事件可以支持路由到不同的页面。 3.不可以暴漏真实的页面URL给业务开发人员。 4.页面路由需要通过后端接口动态下发到移动端。 5.三端页面路由配置保持一致。 四、技术方案 4.1  整体技术方案    针对保持三端一致性以及复杂业务场景路由跳转的诉求，我们设计了虚拟路由的概念。 虚拟路由是什么？ 虚拟路由就是遵循一套规则定义的一个文本字符串，代表了设计者的理念和思想，单个页面对应一个虚拟路由，可以在虚拟路由下面设置不同系统的真实路由，目前支持Android, iOS, 小程序三端，每个端根据不同实现类型，不同版本设置不同的真实路由虚拟路由的文本规范： page://{bosId}/{key}/产品/模块/页面名称?参数=xxx{bosId} 商户助手真实店铺的唯一标识 {key} 业务后端填充的一个字符串，通过字符串可以置换到业务相关的参数信息 产品 业务产品线标识       模块 业务线里的模块 虚拟路由交互跳转设计分为PC端和移动端 4.1.1  PC端 PC端主要负责虚拟路由的配置，配置虚拟URL以及对应的真实URL等信息，真实信息包括：端类型，业务产品版本号，真实URL地址，实现类型。 [图片] 真实的配置表如下图： [图片] 4.1.2  移动端 移动端通过接口下发拿到整个虚拟路由的配置表，然后在触发点击事件的同时，通过接口拿到当前事件对应的虚拟路由，去虚拟路由配置表中匹配到真实的URL和对应的平台类型，执行不同平台的跳转逻辑，实现页面的跳转。    4.2 具体实现  按照整体功能具体实现可以分为路由配置中心，路由管理类、路由配置表、路由跳转四部分。                      [图片] 4.2.1 路由配置中心 路由配置中心主要负责虚拟路由的配置管理工作，配置虚拟路由以及对应的真实路由等信息。 新增路由配置页面 包括虚拟URL和路由规则，规则就是各个端真实路由信息。 [图片] 添加规则页面 添加各个端的真实URL，版本号，实现类型等信息。 [图片] 1、端类型目前支持Android，iOS，小程序三端。 2、组件标识版本号对应业务版本号。 3、真实URL对应不同端真实Page路径。 4、实现类型目前支持原生，H5，Donut等。 添加后的完整信息 [图片] 4.2.2 初始化路由管理类 路由管理类的作用是支持不同平台的页面路由跳转，应用初始化时期需要注册不同平台的实现类，比如：原生，H5等；每个平台实现类的跳转逻辑是不一样的，H5是通过 WebView 渲染打开页面，原生是通过原生的 API 打开页面，管理类最终以 Key 和 Value 的形式存储内容，Key 是实现平台的类型，Value 是具体实现的跳转类。 [图片] 4.2.3 初始化路由配置表 路由配置表是路由跳转的核心，路由映射管理信息都存储于路由配置表中 初始化路由配置表首先调用后端配置接口拉取路由配置，接口传参需要携带系统类型【比如：Android系统】和配置的版本号参数，接口会先通过系统类型筛选出当前系统下的所有路由配置信息，系统总共包括Android，iOS，小程序3端，以Android端为例，接口接收到请求，会立即匹配端类型为Android的所有配置信息，然后再根据版本号参数匹配版本信息，因为PC配置中心单个虚拟路由有可能会配置多个版本，需要筛选出符合当前版本的配置信息； 版本的匹配逻辑是：首先匹配和当前传参版本一致的版本，如果匹配不到就向下兼容去匹配最新的一个版本，以此类推匹配完所有的路由；APP获取到匹配好的完整路由表后，循环整个路由配置表，以Key和Value的形式存储于内存中，Key是虚拟路由，Value是对应的真实URL，版本号，实现类型等信息，至此整个初始化流程就完成了。      [图片] 4.2.4 路由跳转 路由跳转的触发事件主要在应用主页的菜单上 。 [图片]     所有菜单均有后端接口返回，菜单会携带对应的虚拟URL。 触发点击菜单的同时获取到虚拟URL，首先校验虚拟URL是否规范，因为虚拟URL是我们定义的一套标准，只有符合规范才可以触发后续的流程，不符合会终止流程，校验成功后会解析虚拟URL上是否有携带参数，目标页面的虚拟URL和真实URL都支持在URL上配置业务参数，参数解析完成后，去内存中的路由映射表中匹配到真实URL，检查真实URL上是否携带了业务参数，解析完成后合并所有的参数，根据真实URL对应的实现类型匹配到具体的跳转实现类，携带参数，执行跳转交互逻辑。 以下是匹配跳转类的核心代码： when (ImplType.valueOf(rb.implType)) { ImplType.NATIVE -> { val pr = NativePageRouter(rb) pr.routeUrl = routeUrl pr.processRoute() } ImplType.H5 -> { val pr = H5PageRouter(rb) pr.routeUrl = routeUrl pr.processRoute() } ImplType.DONUT -> { val pr = DefaultPageRouter(rb) pr.routeUrl = routeUrl pr.processRoute() } }    [图片]       至此，整个交互流程已经完成，四个模块的职责依赖关系也清晰明了，如下图：     [图片] 五、优势 相较于传统路由框架功能更加强大，带来的优势包括： 动态化  传统的路由框架路由都是在本地配置，局限性太强，此方案支持路由配置动态下发到移动端，跳转更加灵活，能够支持更加复杂多变的用户使用场景。    统一性    目前各个端都是各自为政，没有统一的标准，不成体系，此方案通过虚拟路由的概念，统一各个端的路由标准，更加易于维护管理，单个虚拟路由支持不同端不同版本的不同配置。 灵活性    传统的路由框架跳转修改需要强感知页面URL,  此方案跳转变动只需修改PC配置即可，业务开发人员无感知。 多平台  传统的路由框架仅支持原生页面之间的跳转，此方案可以支持不同平台页面的跳转，功能更加强大，新增业务平台只需实现对应的跳转类即可，易扩展。 容灾能力  如果新版本页面跳转有问题，可以降级到老版本页面，避免线上问题。 六、实践 微盟商户助手接入虚拟路由交互设计后，对业务迭代提供了很大的帮忙。 例如：企微小程序在接入虚拟路由之前，产品业务消息配置的页面都是小程序中的真实路径，由后端接口返回，但是如果单个业务消息跳转的页面需要变更，无法做到新老版本的兼容，老版本在点击消息触发跳转事件时就会提示找不到目标页面。     接入虚拟路由后所有消息只需配置一个通用的真实路径，目标页面的虚拟路由作为参数传递即可，点击消息触发跳转事件时，小程序会通过目标页面的虚拟路由匹配到当前小程序版本的真实路径，这样就可以实现消息页面的跳转，就解决了新老版本无法兼容的问题。 七、总结 移动端虚拟路由交互跳转设计运用到微盟助手商户中后发挥了极其重要的作用，业务开发人员无需关注真实的URL，只需要通过虚拟路由就可以跳转到不同平台的不同页面，跳转的页面可以通过服务端动态配置，单个页面支持不同版本跳转到不同的页面，业务功能遇到问题也可以降级处理，给业务提供了更多的灵活性和可能性。

一、前言 主题色，简而言之，是界面设计中被用作基础配色方案的主要颜色。它是在设计中明确定义的一种核心色彩，用于塑造界面的整体氛围和风格。通过恰当选择和运用主题色，可以 提升界面的可视性和易用性，从而大幅地提升用户体验。 提到图像提取主题色，⼤家可能会想到 OpenCV 这种专业的计算机视觉库，其实Javascript 这种轻量级的 脚本语⾔也是可以被⽤来实现该功能。并且相较于其他语⾔，由于其实时性和动态性以及浏览器的原生支持，JS 具有更好的动态响应能⼒以及定制化能力。 二、背景 目前微盟 CRM 会员模块主要支持两种类型的会员卡，分别是等级会员卡以及权益会员卡。商户可以根据不同的应用场景去创建不同的会员方案（成长值等级类型、消费行为等级类型、权益卡以及付费会员），以及对它们配置、管理。满足丰富的业务场景，能帮助商家针对行业对会员进行个性化运营，帮助商家给会员提供更好的服务，提升会员的黏性和忠诚度。  [图片] 并且每⼀套等级/权益卡的卡面外观，包含了勋章图案、卡面背景、自定义图片、⽂字颜色和背景配色，商户可以对其进行自定义搭配用以塑造界面的整体氛围和风格，提升整体的视觉体验。 [图片] 等级卡装修页面 [图片] 等级卡背景色设置          [图片] 权益卡设置 当商家配置好背景/卡面图片后，其需要手动配置背景/卡面主题色，可能需要进行多次尝试才能找到最合适的配色方案。这无疑增加了配置成本。 此外，可供选择的主题色为固定的几个色板，这导致在设计页面时受到一定的局限性。为了解决这一问题，我们考虑在商户配置好图片后自动生成与其图片相匹配的主题色并自动应用，从而提升整体观感。 三、需求分析 解决该问题最重要的便是获取图片的主题色啦，那么我们该如何去获取到一张图片的主题色呢？市场上常用的提取主题色的方案主要为以下几种： 1.基于平均色的方案：这种方法计算图像中所有像素的RGB值的平均值，然后将这个平均值作为主题色。这种方法简单直接，但可能无法捕捉到图像中的主要色调。 2.颜色直方图：将图像的颜色分布表示为颜色直方图，然后选择直方图中的峰值作为主题色。这种方法对于多种颜色的图像效果较好，但总体效果较差 3.Opencv: 使用 OpenCV 这个强大的计算机视觉库来加载图像，然后使用颜色空间转换和阈值处理来提取特定颜色的部分。 但其实 Javascript 也可以被用来实现该功能，并且相较于其他方案，Js 处理的好处如下： 1.客户端控制：无需后端服务器支持，不用处理图像上传/下载等逻辑。 2.响应性：在处理尺寸较小的图片（CRM会员卡背景图片限制1M以内）时，具有更好的响应性。 3.交互性：可以直接在前端图像上实现交互，例如用户点击图片上的区域来提取特定颜色，或者通过滑块来调整颜色提取的敏感度。 四、需求分析 简而言之，我们的技术方案主要为以下几个步骤： 1.加载图像数据: 使用 Canvas 绘制图像并获取像素数据。 2.数据预处理: 对像素数据进行降噪/缩放/去皮等定制化处理。 3.生成主题色：采用切割算法（中位切分/八叉树）进行颜色提取。 [图片] 接下去我们会一步一步讲解具体的实现步骤。 1、加载图像数据           [图片] 前端开发者对于 Canvas 这个元素应该是再熟悉不过了，我们通过 Canvas 的像素渲染的特性，很轻松的就能获取到图片上的像素数据。但需要注意的是需要使用 IE8及之后版本哦。 首先我们需要通过创建一个 Canvas 元素并调用 Canvas 上下文的 DrawImage 方法将图片绘制到 Canvas 上，再通过 GetImageData 方法获取到图像数据，即ImageData 对象。 并且我们使用了 Web Workers 来对 Canvas 进行离屏渲染，使其在后台线程中处理图像，防止其阻塞主线程的执行。 现在我们已经获取到所有像素数据了，接下来我们便需要对其进行预处理，为我们之后的计算打好基础。 2、数据预处理    2.1 降噪            [图片] 这里的降噪不是指声音的降噪，而是图像处理中的一个专业术语，简单来说是为了去除图像中的干扰。常见的图像降噪处理有高斯滤波、均值滤波、中值滤波等方式。 我们使用高斯滤波（Gaussian Filter）来解释其工作原理，滤波器本质是一种对图像的卷积（image convolutions）。 什么？你说你不知道啥是卷积？ 那你知道图像的模糊和锐化吧？那就是一个卷积。 用过P图软件的魔术棒抠图吗？没错那也是卷积。 用手机自拍开过美颜加过滤镜吗？恭喜你！这还是卷积。 卷积无处不在，而且也很好理解，用数学上的术语来表示卷积是对两个相同维度的矩阵进行逐元素相乘并求和。 如果把图片当做一个大矩阵，那么对图片进行模糊、锐化、边缘检测等处理的功能就是一个小矩阵我们称之为核（kernel），通常来说核的大小是MxM（M为奇数）如3x3，这样可以确保其有一个核心坐标(x, y)。 接着把核心坐标放在图像的起始坐标上，将他们重叠区域的元素进行逐个相乘后求和并将计算结果输出到和当前核心坐标相同的图像坐标上，按从左往右从上往下的顺序平滑核心坐标重复此步骤。        [图片] 弄明白卷积后我们回过头来讲高斯滤波就容易多了，万变不离其宗，高斯滤波其实就是创造一个符合高斯分布的卷积核并对图像进行卷积计算（对像素的R、G、B值分别计算得出结果），详细步骤不在这里过多阐述，来看下具体的运行效果。          [图片] 经过高斯滤波处理之后，图片看起来变模糊了。这就是像素被平滑处理之后的效果，为了减少之后计算的复杂度。 2.2 去皮           [图片] 经过降噪处理后，我们还需要剔除一部分边界颜色我们称之为去皮。因为有些配图是带有纯色背景色的比如白色，大面积的白色或黑色会影响统计结果，并且造成统计性能的下降。 在实际运行过程中会发现有些看似是白色的背景实际会有一定的色差。因此我们并不是简单的对颜色值为(255, 255, 255)的像素去除，而是选取一定的范围。这个范围不能过大，且尽量贴近黑、白色的边界。 如果我们选取RGB值小于(5, 5, 5)或大于(250, 250, 250)的像素进行去除的话，代码实现如下： function convertToPixelsArray(imgData) { const data = imgData.data; const pixels = []; const [min, max] = [5, 250]; //像素点RGB值不在此范围内的进行过滤 范围可选 for (let i = 0; i < data.length; i += 4) { const r = data[i]; const g = data[i + 1]; const b = data[i + 2]; // rgb值都在[5, 250]范围内，则不过滤 if (!(Math.min(r, g, b) >= max || Math.max(r, g, b) <= min)) { // 过滤透明度（可选） pixels.push([data[i], data[i + 1], data[i + 2]]); } } return pixels; } 3、生成主题色    在我们的项目中，我们主要采用了两种算法：中位切分法和八叉树。这些算法被用于不同的情境，以满足不同的图像处理需求。 对于那些需要快速获取主题色，并且对图像细节不太关心的场景，我们选择了中位切分法。这个简单且高效的算法能够帮助用户快速批量地获取图片的主题色。在这种情况下，我们的重点在于迅速处理大量图像，而不需要过多关注图像的微小差异。 在那些对细致和真实主题色有更高要求的场景中，八叉树无疑是更好的选择。比如： 渐变背景色：八叉树能够创造出更加复杂多样的背景效果，从而使渐变过程更加平滑自然，为视觉体验增添层次感。 细致的颜色匹配：八叉树具备实现对图像中不同区域进行精细颜色匹配的能力，从而更好地将主题色与整体设计融合。 下面就来介绍一下怎么用 JS 实现这两种算法。          4.1 中位切分法  中位切分其实非常好理解。首先需要各位读者发挥下空间想象能力，将R、G、B想象成三维空间的X、Y、Z轴，这样我们就得到了一个边长为256的立方体盒子，接着把每个像素点当作一个无体积的小球根据其坐标（r,g,b)放入盒子中。          [图片] 中位切分法的核心思想就是不断对某一根轴上的中位数进行切割，与日常生活中的折纸类似（把一张纸对折42次就可以上月球了，由此可见该算法的强大）。 不同的是，我们每次会选择像素密度最大子空间的最长边上的中位数进行切割，以确保每次切割过后的子空间中的像素数量大致相等。并在完成每次切分后使用插值排序法进行排序，从而找出密度最大子空间（或质量最大子空间）以进行下一次切割。          [图片] 某图像颜色在三维空间中的分布示意，可以看到部分区域的像素点非常密集                    [图片]          [图片] 沿R轴像素中位数处切割成左右2个子空间，右边空间包含的像素数量更多          当子空间边长小于设定的阀值时，我们便将其存入结果数组中。算法终止条件为切割次数或结果数组达到要求，此时密度排序靠前的几个子空间中包含的颜色即为我们所寻找的主题色。 以下是 JavaScript 的实现： function medianCut(pixels) { const colorRange = getColorRange(pixels);// 获取该颜色盒子的RGB范围 const colorBox = new ColorBox(colorRange, pixels.length, pixels); const divisions = 8; // 最大切割次数，在demo中写死 实际项目中使用者可自定义 let [box1, box2] = cutBox(colorBox); // 第一次切割 return queueCut([box1, box2], divisions); } function queueCut(queue, num) { let isSmallBox = false; while (queue.length < num && !isSmallBox) { const denselyBox = queue.shift(); const resultBox = cutBox(denselyBox); // 只返回一个盒子时，说明最长边已经小于阀值 if (resultBox.length === 1) { isSmallBox = true; queue.unshift(resultBox); return; } queue = insertValueInSortedArray(queue, resultBox); // 插值排序 } return queue; } function cutBox(colorBox) { const { colorRange, total, rgbArr } = colorBox; const cutSide = colorBox.getCutSide(colorRange); if (cutSide === -1) return colorBox; // 当切割边为-1即切割范围小于阀值时 停止切割 const colorInCutSide = rgbArr.map((item) => item[cutSide]); // 统计出各个值的数量 let medianColor = getMedianColor(colorInCutSide, total); // 此处做简易处理，实际处理中需考虑中位数值的像素数量是否过大 if (medianColor === colorRange[cutSide][0]) { medianColor++; } // 防止空切 const newRange = getCutRange(colorRange, cutSide, medianColor); // 获取切割后的两个盒子的RGB范围 const dividedPixels = dividePixel(rgbArr, cutSide, medianColor); // 分割像素到两个盒子中并返回... return [boxOne, boxTwo]; } 看到这里是否对中位切分算法有了更深的理解？在实际运用中，要注意切割次数和最小子空间的设定会影响到结果的准确性。 3.2 八叉树  我知道有些同学看到这个名字的时候已经开始头疼了。但请先别急，听我慢慢讲解 先用一句话简单概况，八叉树（Octree）是一种用于描述三维空间的树状数据结构，它是一种递归的树形数据结构，可以将三维空间划分为八个等分的小立方体（子节点），每个空间可以进一步细分为八个子空间，以此类推。 八叉树怎么和RGB颜色盒子连接起来呢？ 首先，要将三维空间划分成八个等分的小立方体，我们需要沿着每条轴的中点切割，确保每个子空间的边长相等，从而确保每个立方体的体积相等。 比如将一座葫芦山（完整颜色盒子）用八叉树切分后会得到八种不同颜色的葫芦娃；          [图片]（没办法葫芦娃只有七个人，拿蛤蟆凑个数） 但是其颜色，比如蓝色的范围太广泛了，其分为天蓝色、宝蓝色、钢蓝色、葫蓝色、蔚蓝色、紫蓝色等等，天蓝色又分为淡蓝色、浅蓝色、鲜蓝色、翠蓝色、深蓝色等等。那么我们就需要对这些葫芦娃进行递归切割以获取这些更精确的颜色。 那么我们要切割到第几层才能获取到具体的像素点（1*1*1的颜色盒子）呢？我们可以观察到，每对颜色盒子进行一次切割，会导致子节点继承的RGB范围减半，而256=2^8，这意味着在对一个完整的颜色盒子划分到第八层时，我们就可以获得单个像素点啦。 我们知道了八叉树对于颜色盒子的划分规则后，我们该怎么使用八叉树来提取图像主题色呢？ 上文中提到八叉树是按照三条轴的中点对空间进行递归切割的，也就是说在八叉树第一层结构中，各轴会被分成[0, 127], [128, 255]两个区间，颜色盒子被均分成八个小盒子。那我们该如何将这些小盒子其与八叉树中的第一层节点对应起来呢？ 与二分查找法类似，我们需要将像素的RGB值分别与其轴中点进行比较并将结果用0、1来表示（0-小于中点，1-大于中点），在第一层中得到的对应关系如下图所示。          [图片] 以此类推，我们最终得到以下对应关系。          [图片] 以此类推，我们可以得到各像素点在八叉树中所挂载的节点（如下图所示）。八叉树将颜色数据按照层级关系组织与管理起来，从而实现高效的存储和查找操作。          [图片]           知道了怎么将像素数据存入八叉树结构后，我们就可以开始提取主题色啦。 首先，在八叉树最后一层结构中，每个节点表示的是一个具体的RGB值，我们称其为叶子节点。与此同时，在最后一层中每个兄弟节点的RGB差值范围为1，也就是说该父节点的所有子节点的颜色都十分类似。我们可以发现，在八叉树较深层级中，兄弟节点的RGB差值范围较小，公式为diff=2^(8-n)，其中diff为RGB差值，n为层数。 那么我们可以利用这个特性来合并相似元素从而更有效地表示数据，当一个颜色盒子中存有过多小盒子（子节点）与葫芦娃（像素）的时候，丢弃其中所有小盒子，并保留所有葫芦娃至父盒子中，从而进行空间压缩，减少空间复杂度。 为什么要进行合并呢？在介绍中位切分法的篇幅中，我们提到，提取主题色其实就是找到密度最集中的几个簇，被合并的盒子的像素都为那些像素集中且密度较大的盒子。这便是我们所需找到的簇，也就是主题色。 如果将所有像素全都储存在八叉树结构后，才进行合并叶子节点的步骤的话，这无疑极大的增加了空间复杂度，所以我们设定了一个阀值N（可自定义），一般来说，N越大，得到的结果越精确，但时间复杂度与空间复杂也会同步上升。 在将像素插入八叉树结构的过程中，当叶子节点数量超过N时，我们便会将挂有最多叶子节点的父节点进行合并操作。合并后，将该父节点设为叶子节点，且之后所有在该分支上的像素均挂载至该父节点上。 当所有的像素数据遍历结束后，我们就可以得到N个叶子节点了。 我们需要根据每个叶子节点上的像素数量对其进行排序，排名前列的便是我们所需要的主题色啦。 以上介绍了中值切分法和八叉树两种算法的实现 中位切分法适用于资源有限且需要快速提取图像主题色的场景，尤其适合实时或大规模处理需求。它的简单性和计算效率使其在这些场景下成为很好的选择，尤其是当主要目标是从图像中快速捕捉主题颜色而不需要过多考虑细节和渐变色时。比如当商户只需要快速批量地获取图片的主题色，且不关心主题色的精度时 而八叉树在动态适应性和处理颜色渐变方面具有优势，适用于需要保持细节不和平滑度的图像颜色提取任务，但其算法复杂度较高，内存消耗较大。主要应用场景如下: 并且该两种算法我们都会放在 Web Worker 中处理，以提高页面性能和用户体验，同时保持主线程的渲染进程不受影响。 五、成果 以上就是这篇文章的总体内容了，通过 Canvas，可以在 Web 前端对图像进行操作和渲染。结合切割算法，可以实现类似的图像颜色提取功能。这种方法尤其适合需要在用户界面中实时显示颜色提取结果的交互式应用。并且通过对于 Web Worker的一个使用，避免了对主线程渲染的影响，从而提升了用户体验。 接下来我们看一下会员卡接入该功能之后的一个整体效果吧。 会员权益卡接入该功能后，当用户上传完卡面图片，便会自动提取其中的主题色。这样，用户可以直接选择提取出的色彩作为主题色应用，以确保卡面图片和主题色的协调性。具体效果如下所示：          [图片] 权益卡效果展示 会员等级卡接入该功能后的效果图如下所示： [图片] 等级卡效果展示 我们还可以利用该工具，当加载一些比较耗时的大图片时使用提取出的主题色进行渐变填充，实现一种"模糊渐变加载"的过渡效果。这种过渡场景可以增加页面加载的视觉吸引力和平滑性。如下图所示： [图片]

消费互联网时代，纷繁的应用需求催生了产品和功能的指数级增长。在复杂多元的研发场景下，高效快速、保质保量、可持续交付的研发模式，方能支撑高速扩张的业务需求。 01. Titian 是什么？ 近日，微盟重磅推出多渠道移动端组件库——Titian。作为移动端前台的“底层”能力，它伴随了“微盟 WOS -新商业操作系统”的研发历程，经历了从无序到有序，从稚嫩到成熟的蜕变，并助力了需要不断实现的“产品一体化、体验一体化、服务一体化、数据一体化和开放一体化”的 WOS 终极形态。 [图片] 经过一年多的不断进化，Titian 取得了大量核心业务应用及有效性验证。Titian 提供了清晰统一的 API ，满足多渠道小程序与多前端框架能力，极大的降低了研发成本与提升需求流转效率。同时，Titian 也是体验良好的重要保障，遵循用户习惯、维持用户心智，为业务提供了有序一致的产品体验。 [图片] 02.设计理念体验设计远不止于核心任务，更需要沉淀与延续设计模式和理念，为后续的设计产出质量与效率提升做基奠。为此，微盟Titian在完成核心任务的同时并行落地了“移动端设计体系”。包含以下三部分：分别为“设计理念”、“视觉语言”、“设计规范”。体系是设计在执行时的规则、标准与指导。 [图片] 针对微盟产研、微盟生态开发者、外部行业开发者3类用户群体，微盟Titian在提升效率、普适通用的核心思路下，基于“有序、普适、多元”的设计理念与价值观，打造具有自身特色的移动端组件库。 · 体验有序一致 即内外的有序，内在拥有统一的标准、规则及模式。外在有统一的设计语言让用户体验有序一致。 · 场景应用普适性 沉淀于微盟核心的 SaaS 业务，对“交易场景”拥有良好的普适性。既能满足当下需求，也能拓展延伸至更广泛的应用场景。 · 品牌调性多元化 丰富多元的场景选择性，满足不同品牌调性展现。贴合用户心智，维持品牌认知。在赋能品牌的同时，开发者更能探索出无限可能。 03.Titian 提供的能力 3.1 完善的基础组件 Titian 目前提供了 60+ 移动端基础组件，足以支撑绝大多数的业务需求。 [图片] 3.2 更丰富的多端小程序支持 借力微盟自研的小程序多渠道转码工具（即将开放），Titian小程序组件库可在微信、支付宝、小红书、快手等渠道的小程序顺畅运行。 3.3 React 和 Vue 同步支持 Titian H5 基于 Web Components 能力，Titian H5 提供 React 和 Vue 3.0 两套组件库。该两套组件库底层互通， API 一致，满足业务方丰富的使用场景。 3.4 H5 与小程序 API 统一小程序与 H5 组件库两者采用统一的 API 设计，方便开发者接入。 3.5  二次开发能力 在 Titian 丰富的基础组件上，用户可以快速开发满足自身需求的定制组件。在微盟已经有大量的案例落地，满足了丰富的业务需求。 [图片] 3.6 多维度主题切换 在确保品牌风格统一的前提下，Titian基于品牌调性提炼了具有共性的视觉特征，分别为颜色、图标、圆角。并用这些特征组合为“通用”、“潮流”、“亲和”套风格（后续会持续增加），让开发者随心选择，让产品视觉更贴合品牌调性，保持品牌识别度，维持C端用户对品牌的心智认知。 3.7 开箱即用的体验 Titian 提供交互式的示例，对于组件最常用的功能，可以直接配置相关属性。业务方可以直接上手操作，简单直观。 04. 开发工具 · 自研打包工具基于 esbuild ， Titian 自研了小程序打包工具，让编译流程更加快速，开发体验更加友好。 · VS Code 提示插件 帮助用户在 VS Code 中快捷使用 Titian 组件。 · WXML 格式化工具一个 prettier 格式化插件，方便统一代码风格。 · Figma 设计组件Titian提供了一整套完整的设计组件资源，接入引用即可立即使用，方便快速搭建页面，设计组件覆盖代码能实现的所有能力，做到了设计-研发闭环。 · UED 验收工具对于 Titian 组件，打开验收工具配置后，长按即可变得半透明。可以帮助 UI 快速分辨出 Titian 组件。 05. 优秀案例 经过1年的迭代与不断调优，Titian已为微盟企业内部及微盟商城、CRM、CMS、商户助手、微盟客等客户，累积提供了5000+的移动端场景的应用及验证。 [图片] [图片] [图片] [图片] [图片] [图片] [图片] 未来，微盟将在 Titian 组件库的基础上做更多的探索，开放优化可视化建站平台、D2C 设计图转代码工具、物料市场等新工具新平台，敬请大家多多关注～ 反馈和共建请访问Titian UI - 多渠道移动端组件库PC端官网，进行体验！ https://titian.design.weimob.com/ github链接：https://github.com/weimob-tech/titian-design 微盟云开发者可通过微盟云开发者工具中的Titian使用文档指引，查找使用方式！ https://doc.weimobcloud.com/word?menuId=53&childMenuId=58&tag=3764

通过打日志查看，在打开一个页面，并且页面首次渲染完成时：页面生命周期钩子(onLoad, onShow, onReady)都触发完后，通过 PerformanceObserver 监听方式的回调才触发。即，数据可采集的顺序为： page.onLoadpage.onShowpage.onReadyperformance 的 routeperformance 的 evaluateScriptperformance 的 firstRender疑问： performance 的evaluateScript 代码注入阶段（记为A）、page.onReady 首次渲染完成（记为B），实际发生顺序是 A ➜ B，但真实数据获可采集顺序却是 B ➜ A，这个是什么原因？两者可采集顺序是固定的吗？

小程序模板消息能力在帮助小程序实现服务闭环的同时，也存在一些问题，如： 1. 部分开发者在用户无预期或未进行服务的情况下发送与用户无关的消息，对用户产生了骚扰； 2. 模板消息需在用户访问小程序后的 7 天内下发，不能满足部分业务的时间要求。 为提升小程序模板消息能力的使用体验，我们对模板消息的下发条件进行了调整，由用户自主订阅所需消息。 一次性订阅消息 一次性订阅消息用于解决用户使用小程序后，后续服务环节的通知问题。用户自主订阅后，开发者可不限时间地下发一条对应的服务消息；每条消息可单独订阅或退订。 [图片] （一次性订阅示例） 长期性订阅消息 一次性订阅消息可满足小程序的大部分服务场景需求，但线下公共服务领域存在一次性订阅无法满足的场景，如航班延误，需根据航班实时动态来多次发送消息提醒。为便于服务，我们提供了长期性订阅消息，用户订阅一次后，开发者可长期下发多条消息。 目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放，后期将逐步支持到其他线下公共服务业务。 调整计划 小程序订阅消息接口上线后，原先的模板消息接口将停止使用，详情如下： 1. 开发者可登录小程序管理后台开启订阅消息功能，接口开发可参考文档：《小程序订阅消息》 2. 开发者使用订阅消息能力时，需遵循运营规范，不可用奖励或其它形式强制用户订阅，不可下发与用户预期不符或违反国家法律法规的内容。具体可参考文档：《小程序订阅消息接口运营规范》 3. 原有的小程序模板消息接口将于 2020 年 1 月 10 日下线，届时将无法使用此接口发送模板消息，请各位开发者注意及时调整接口。            微信团队 2019.10.12