【讨论】怎么才能有效的优化！

[xmsz]

背景

• 产品的功能越来越多，安卓小程序变得越来越卡，普通的手机可能一下子内存就爆了，还有页面渲染变得拖拖拉拉
• 使用的是vue3，原本用JSX渲染，发现对性能会有影响，或者说vue3对于模板渲染本身有做优化，然后全部改写成vue单文件，性能上有明显提升。
• 想起Taro那边3.0也有段时间了，看看Taro是否有性能优化的处理

测试环境

• PC Macbook pro 16
• QQ小程序
• 安卓机子 z5x
• vue3

列表渲染测试

测试了一下Taro和kbone在超长列表的渲染

结论

• 开发者工具上，kbone比较异常，能渲染的条数非常的少，但是真机上正常，不知道什么原因，不过不影响
• 在真机上，无论从最多渲染数量，渲染真实速度都差不多，渲染一个较为复杂的列表，基本都是600条，15s的渲染时间...
• 唯一不同的就是在nextTick中Taro大概5s只有就返回了，说明setData操作应该是延后执行，这种做法有好有坏，我是不喜欢
• 对比原生，原生600条渲染只要5s。还是有差距。

关于Taro

其实很早之前为了让H5的同学快速进行开发有用过，和现在3.0差异很大。Taro的优势在于时间和生态，活得久，用得人多，填坑自然又多又快。

但是不太习惯的是Taro不能剥离出核心，一定只能用Taro本身的框架，这就造成了更多其他的问题... 这点也就非常难以忍受的

当然写的时候也不是很习惯，例如只能使用view标签，都知道目的是为了适配所有平台，但是这就让不需要适配那么多平台的情况很难受。而且还要把原有代码全部改成view... 如果以后又不用，难道又要改回去？还有像h5这样的平台，本来可以做一些优化，现在可能因为Taro本身编译无法实现，这就是和框架太耦合的结果。

所以肯定是更愿意接受像kbone这样的方案

真实案例

kbone没有展示出来哪些案例，所以没办法真机测试其他应用情况
Taro有很多，但是首页上展示的都是一些功能比较简单的应用。看到一个京喜算是大的商城应用，结果用安卓使用，也是卡出了天际。

总结

• 好的不用说，无论对团队，还是个人。还是对产品都是前所未有的提升。
• 不好的就是关于安卓的性能上真的太让人头疼，特别是QQ那边，97%都是安卓用户，开玩笑的说就是面向安卓开发
• 关于性能的优化，h5肯定非常流畅不管是不是安卓。小程序那边能做的也做了，但是对于大一点的应用还是卡。这一卡就是大问题，卡分成两种，一种是迟钝，一种是动画卡。动画卡用户还好就觉得你做的比较差，但是迟钝就会觉得你应用不好用就不用。

太烦恼了，现在面临几个选择

• 用Taro重写，好处是可能有所提升，没有提升可以参考其他案例。但是不太喜欢
• 复杂的页面用原生组件重写，这种方式的混合估计效果也不会很好
• 原生写，那真的耗时耗力

[JuneAndGreen]

kbone 的话，如果明确更新范围，可以尝试使用 wx-view 进行隔离呢？比如你的列表页是这样的：

<div>其他逻辑</div>
<div class="list">
  <div class="item"></div>
  <div class="item"></div>
</div>

这里假设你的 list 里会频繁新增 item，所以可以改造成这样：

<div>其他逻辑</div>
<wx-view class="list">
  <div class="item"></div>
  <div class="item"></div>
</wx-view>

然后如果每个 item 里面也会有频繁的 update，那么还可以改成这样：

<div>其他逻辑</div>
<wx-view class="list">
  <wx-view class="item"></wx-view>
  <wx-view class="item"></wx-view>
</wx-view>

只要能界定出频繁更新的范围的地方，就使用 wx-view 来代替普通标签，这样会生成一个自定义组件，减少更新 diff 范围。当然，自定义组件的初创会比普通标签更慢，所以相当于牺牲初创开销来优化更新开销。这里需要考量的是需要拆分出多少个自定义组件，这就要根据业务来定了。

另外上面拆分后，miniprogram-element/miniprogram-render 也要更新到最新版本，最新版本支持了小范围更新的优化，在这种场景也能减少更新数据包。

PS：不过私以为，要死磕性能的话，还是建议上原生，几乎任何小程序框架都会引入损耗，而原生可以更自由地做优化定制。使用原生尤其针对长列表的情况，也可以试试原生的 recycle-view 看看能否满足：https://developers.weixin.qq.com/miniprogram/dev/extended/component-plus/recycle-view.html （理论上使用各个框架也能实现可回收列表，不过目前没有现成的案例，就不提供了）。

[xmsz]

嗯 实际开发中有使用wx-view，不过没有具体测试效果。
虚拟列表也实现了，解决了很大的长列表问题。但是因为因为变成了原生写法，所以又和web端断开了，所以少数页面在用。

我真的太难了，小程序的产品搞得跟APP一样。�开发又要快，如果写原生简直是要加班通宵的节奏。

---

实在不行，只有希望支持一下页面可以引入原生页面，这样一个一个页面替换写吧。

大概思路就是

• kbone.config 可以配置自定义页面路径，其实和自定义组件一样
• 然后编译的时候，自动把自定义页面路径的文件夹拷贝过去

[JuneAndGreen]

原生页面和 kbone 页面一直是可以混在一个小程序里的，配置 generate.app 为 noemit 就可以不输出 project.config.json 和 app 相关的代码，只输出 common 和 pages 等。如果想将 common/pages 在收归到一个目录中，可以改 webpack 的输出配置或者利用分包的输出特性。

然后其他部分你可以直接在输出目录里写，也可以利用 webpack 插件从某个目录拷贝到输出目录。

[xmsz]

原生页面和 kbone 页面一直是可以混在一个小程序里的，配置 generate.app 为 noemit 就可以不输出 project.config.json 和 app 相关的代码，只输出 common 和 pages 等。如果想将 common/pages 在收归到一个目录中，可以改 webpack 的输出配置或者利用分包的输出特性。

然后其他部分你可以直接在输出目录里写，也可以利用 webpack 插件从某个目录拷贝到输出目录。

好的

[xmsz]

@JuneAndGreen Taro更新了CustomWrapper组件，看一下有没有参考价值。现在的原生自定义组件的引入方式和调试确实有点麻烦

[JuneAndGreen]

@JuneAndGreen Taro更新了CustomWrapper组件，看一下有没有参考价值。现在的原生自定义组件的引入方式和调试确实有点麻烦

taro 这个并不是引入原生自定义组件，而是强制开启一层自定义组件，以减少每次 diff 的范围吧。这个 kbone 一开始就提供了，就像上面有提到的，使用 wx-view 就可以单独开一个自定义组件。

[xmsz]

@JuneAndGreen Taro更新了CustomWrapper组件，看一下有没有参考价值。现在的原生自定义组件的引入方式和调试确实有点麻烦

taro 这个并不是引入原生自定义组件，而是强制开启一层自定义组件，以减少每次 diff 的范围吧。这个 kbone 一开始就提供了，就像上面有提到的，使用 wx-view 就可以单独开一个自定义组件。

原来如此 没有看具体代码以为搞了什么黑科技