debuggerx

条目非等高的长列表还要带滚动条，原理上就没办法高效、完美解决，只能是各种取舍，有时是技术上，有时是设计上。
或者换句话说，只要原理上无法避免大量元素 layout 的场景，怎么都会卡，只是在同等硬件配置下不同的语言和框架会出现卡顿现象的量级会有所不同。

@aptupdate 我现在对简书的唯一印象就是：「前世渣男把我迷晕还叫我别怕，重生后我杀疯了」

@povsister 我第一反应也是这个。不过还祭啥天，他们还有几个活人？

直接看 http 调用的文档自己手搓，比他们提供的 sdk 高效得多，我对接很多家的云服务都是这么干的

@furlxy 想得太多，学得太少

@murmur 因为三维渲染是项目中期加入的需求，不是项目的核心功能，项目中存在大量表单、交互逻辑，还需要适配手机、平板、桌面，技术选型阶段就拍定了要采用“成熟度高、开发效率高、真・跨平台”的技术方案。unreal 的门槛就不说了，unity 我也做过，拿它做大量业务的应用完全不现实。其实接到要加三维渲染需求的时候我们考虑过是不是用 unity 或者 gl 去实现，但是简单调研了一下就发现这个用纯 flutter 自身的 api 就完全能做，无需引入新的框架和技术栈，而且几乎不增加项目复杂度和平台适配成本，还能通过写 dart 工具脚本的方式快速把其他组的资源转换成我们需要的格式，从而使这个需求快速推进，所以就按这个路线做了。

@furlxy 当然碰到过问题，开发过程中就解了，线上环境碰到的问题我拿 sentry 捕捉后修掉跟随下个版本上线，很少出现用户反馈有问题的情况。我 18 年开始研究 flutter ，一开始确实是个人喜好写了不少 demo ，不过后面在四五家公司（非外包）做各种项目，除了做到一半项目被砍的，最终都正常交付。

@furlxy 你说的这些有什么问题呢，早几年就有人用 flutter 做这些了。我不知道什么算“复杂”，接蓝牙算不算，做桌面程序接系统 api 算不算，做实时图表绘制算不算，这些我都做过，“能做”。这两天在搞工业三维渲染，不桥接原生，不用 webview ，不靠 gl ，就用纯 flutter 搞，一套代码直接跑在移动端、桌面段和 web 所有平台上，效果已经验证通过了。