主要观点总结
文章主要讲述了1688小程序随着业务加速迭代，在技术层面上的支撑与未来规划。介绍了整体架构、研发工程、体验工程，并详细阐述了搜索推荐、商品详情、旺旺消息、旺铺、采购车等核心链路的优化措施。同时，还讲述了性能监控、研发平台、微信生态探索等方面的内容，并探讨了小程序跨端化、组件库、微信生态整合等未来能力布局。
关键观点总结
关键观点1: 1688小程序的技术支撑与迭代
文章详细描述了1688小程序在业务加速迭代中的技术支撑，包括整体架构、研发工程、体验工程等。
关键观点2: 核心链路的优化措施
文章详细阐述了搜索推荐、商品详情、旺旺消息、旺铺、采购车等核心链路的优化措施，包括性能优化、动画效果改进等。
关键观点3: 性能监控与研发平台
文章介绍了基于无侵入式切面代理的核心机制，实现用户行为轨迹的全链路追踪，API函数劫持，以及微信生态运营的利器SCRM平台。
关键观点4: 微信生态探索
文章探讨了微信生态的丰富性，并基于微信生态进行技术架构的构建，以实现用户在生态内的生命周期管理、多场景数据协同及业务流程自动化。
关键观点5: 未来能力布局
文章讨论了小程序跨端化、组件库、微信生态整合等未来能力布局，并介绍了技术选型、跨端组件库构建、微信生态整合的具体方案。
正文
d. Builder依赖关系梳理
以下是梳理得到的数十个Builder的依赖关系DAG图
最终接口性能整体服务接口优化使原有RT降低了50%；
预载方案
od加载出完整数据的步骤比较简单：接口获取到数据，然后将其经过逻辑处理后渲染出来，完事了。只要数据成功获取到，逻辑处理和渲染都不是什么难题，所以od加载的核心卡点在数据获取上。
前端上使用了接口预读方案。目前商品详情是在od页加载完成后才进行接口读取，从点击推荐页的商品后，到商品页首屏加载完成中间的这个时间，网络层什么都没有做（跳转？跳转也算时间哦）。所以优化的根本原理是利用起来前端路由跳转的这段时间，在发起跳转命令的时刻就进行接口请求。这里使用了小程序的getOpenerEventChannel API，这是一个建立在当前页面和上一页面的事件通道，正是通过这种方式将页面跳转前获取到的数据传递给了当前页。通过这种优化方案
我们将od首屏加载时长平均下降了200ms；
动画
在页面内容相同的基础上，最能使得体感更加流畅的方式就是动画。与搜推列表类似，我们从js逻辑动画修改为了使用wxs方案（wxs即为可以在渲染层上直接进行编程的方案，无需通信即可控制元素css状态）。我们修改了如下组件，使其像🍫（广告位招租）一样丝滑
后续优化
其实od加载优化的终极方案就是在进入od前就获取到od的各种核心数据（如商品标题、商品主图等），之后在od页面渐进式地逐步渲染；后续将结合各业务逻辑逐步改造（以推荐列表为例，每一项均需要提前获取到od的一些关键信息优先渲染类似主图、标题、详描等。
2.1.2.3
旺旺消息
不论是售前的询盘，还是售后的服务，均需要与商家沟通这份桥梁。所以我们也针对旺旺的链路进行了优化。这次优化分为两部分，旺旺的消息列表和旺旺的消息详情
消息列表
最早我们小程序的消息列表是h5的版本。但是由于h5只有在曝光后才会开始加载，所以在进入消息列表页时需要进行漫长的等待（足足2s），并且也没有办法及时获取到有多少未读消息，于是乎我们考虑将其升级为原生化的列表。
思路是将消息列表改造为原生化后，我们就可以在应用进入时在后台直接初始化消息列表sdk，这样就可以省去列表获取的时间，也可以在后台实时获取到未读消息数，渲染到消息栏。消息列表的sdk是基于钉钉imsdk实现的，淘天在web上基于imsdk做出过一版封装，于是我们就将其clone了下来，针对小程序做了魔改：比如将基于web的websocket修改为基于小程序的CustomWebSocket、将默认接口的鉴权token获取修改为了基于小程序鉴权改造的mtop接口获取等等。
当然，坑远远不止这些，由于小程序只识别es5语法，所以我们将一些不支持es5（也无法通过babel编译到es5）的逻辑干掉了（此处感谢钉钉imsdk的 龙允、闲鱼的前端大佬 灼升 提供的技术支持），并将其打包为一份es5的imsdk.js文件供小程序使用（为什么不借助小程序的编译打包生成，因为我们是基于原生开发）。虽然经过这次修改消息列表做到了秒开，但这使得我们的包体积增加了300kb。至于为什么不能使用动态加载方案，借用小程序跨端框架Taro的一句话：
平台客服&旺旺消息
平台-买家：小程序目前售后还有所欠缺（难退无赔无任何保障），只有电话客服无法举证，无法多次连续与平台沟通，消费者无法解决问题，因此只能投诉到微信平台。处理反馈和投诉只能人工介入，处理不及时会降低小程序的体验分，严重甚至会导致小程序下架。
商家-买家：小程序的旺旺消息非常简陋，只能文本交流，体验不好会非常影响转化。
|
升级前-平台客服
|
升级前-旺旺客服
|
升级后效果
|
入口-OD截屏
|
入口-消息置顶
|
入口-工作台
|
平台客服
|
旺旺消息
|
方案选型
方案1: 小程序原生开发旺旺消息页，由于旺旺卡片数量巨大，有几百种，工作量巨大，旺旺侧团队粗估60人日。
✅方案2: 复用pc的旺旺消息聊天页面，做小程序侧的兼容，主要是登录态和卡片点击功能兼容，工作量主要在于梳理卡片以及前端兼容，分3期逐步兼容卡片进行上线
。
-
登录态适配： 为了解决进入旺旺页需要登录的问题，对第三方包@ali/im-sdk-saas进行了登录态适配。对卡片点击跳转的页面进行登录态适配，包括选择订单页面，FAQ页面等。
-
平台客服卡片梳理与兼容： 对平台客服的所有卡片进行了细致的梳理，并特别针对FAQ卡片实现了DX渲染实现。此外进行了交互方面的兼容，对链接进行了拦截控制，比如：商品点击原本是打开新页面，会自动唤客户端，需要禁止，改造为跳转小程序od
、
选择订单原本是打开新页面，改造为半窗交互
、
点击卡片“去支付”打开支付页面，然而小程序有可能未进件，支付不了，改造为跳转订单详情
-
聊天消息新增图片发送功能： wap旺旺没有发送图片的能力，因为图床登录态没法适配。因此开发了新的接口，背后用纵横平台存储图片，实现了发送图片聊天的能力。这一功能的实现，为用户提供了更加丰富的沟通方式，提升了沟通效率。
-
卡片展不了的解决方案： 为了解决无法展示卡片时可能引起的用户焦虑，搭建了新的sop流程发送转人工卡片。
2.1.2.4
旺铺
围绕商家私域运营能力，从0-1建设极简旺铺，强化商家分享和私域运营。
sticky效果
