微信小程序长期建立在AppService加WebView的双线程模型上。官方《Skyline渲染引擎介绍》承认：Web历史包袱重，逻辑和渲染挤在同一类线程模型里时，界面容易被脚本堵住。Skyline另开渲染线程负责Layout、Composite和Paint，并在AppService里划出原先由WebView承担的JS与建树逻辑。结果是页面更不容易被逻辑卡住、不必为每个页面新建一套JS引擎、页面间能共享更多资源、框架内部少走JSBridge。基础库3.0.0正式版同期给出的线上观测是：点击到完全渲染（LCP）从WebView的2492毫秒降到Skyline的2052毫秒，降幅约17.6%；从框架建树到完全渲染从626毫秒降到312毫秒，降幅约50%。这些是已上线小程序的统计，不是实验室峰值，值得当作迁移的预期，而不是合同里的保证值。
一、兼容是优势，渐进是纪律
官方强调：不使用Skyline新特性的代码，在低版本或不支持的平台会回退到WebView。WXS被挪到AppService后，读页面信息的接口会变异步，复杂动画应改用更靠近渲染线程的Worklet。迁移最佳实践把顺序写死了：先开启按需注入并测完副作用，再逐页打开Skyline。存量项目优先迁关键路径；新页面默认Skyline；全新项目可以全局打开以换内存。不要第一周就全站切换，否则样式精简带来的错位会把性能收益淹没在兼容清单里。
1.1 为什么必须先做按需注入
Skyline依赖按需注入。打开后，部分页面行为会变，官方要求把兼容问题提前消化。很多团队把“包体积优化”理解成只砍图片，却继续让主包承担所有页面的JS。按需注入加上分包，才能让Skyline的共享引擎优势出现：多个Skyline页面跑在同一渲染实例里，全局样式和公共代码不必按页复制一份。
二、分包与预下载决定用户有没有耐心
主包只留启动和首页必需。列表、订单、我的、活动页按独立分包切开；从分享卡直达的详情页可考虑独立分包，但要接受不能直接读app.js全局状态的代价。预下载规则应写在真正会流向下一站的页面上，并尽量限制在Wi-Fi。客户端不会像预热WebView那样自动预热Skyline，官方提供wx.preloadSkylineView，建议在可能跳入Skyline页的路径上、于onShow里延迟调用，避免返回时再付一次冷启动。
| 主题 | WebView路径 | Skyline路径 | 排期建议 |
|---|---|---|---|
| 线程模型 | 逻辑易阻塞渲染 | 独立渲染线程，少JSBridge | 先迁首屏与列表 |
| 组件框架 | 传统双线程通信 | glass-easel建树降约30%–40%，setData无通信开销 | 与renderer一并打开 |
| 样式 | 运行时解析WXSS | 预编译二进制，官方称快5倍以上 | 避免依赖被精简掉的旧CSS |
| 长列表 | 易全量建树 | scroll-view按视口渲染+lazy mount | 商品/订单列表作为第二批 |
| 动画 | WXS或JS驱动 | Worklet跑在渲染线程 | 有手势的详情页再迁 |
三、长列表是最值回票价的一页
Skyline的scroll-view按直接子节点靠近视口才渲染，离开后回收；相似节点还能共享样式计算。商品流、工单流、库存流水最适合作为第二批迁移对象。约束是用法必须符合官方结构，乱套一层view再内部滚动，优化不会生效。glass-easel降低建树耗时，但救不了一次setData塞整表的接口设计。迁渲染引擎的同时，接口仍要分页。
四、用两周验证，而不是用一个大版本赌
页面json里打开Skyline时，通常要同时声明renderer为skyline、componentFramework为glass-easel，并按官方示例配置defaultDisplayBlock与defaultContentBox，减少和WebView默认盒模型的差异。建议的最小验证集是：启动页、一条关键转化页（下单或预约）、一条长列表。打开开发者工具的Skyline调试与Worklet编译，用Audits和Performance看LCP、帧率和setData频率。内存下降要在多页来回里测，单页截图看不出来。官方数字可以当作对照，但每个行业包体积和接口形状不同，要用自己的真机基线说话。分享进来的独立分包页如果也走Skyline，记得单独处理初始化，不要假设主包的全局状态已经在。
Skyline迁移的对手不是WebView，而是“想一次改完”的日程表。把按需注入当第一周，把两个关键页当第二周，把长列表当第三周，比排一个“全面Skyline化”的季度项目更接近官方最佳实践。等关键路径稳定了，再让新页面默认走新引擎——用户会先在手指上感觉到，而不是在版本说明里读到。