@learningman 哦哦，因为 flutter 升级之后，SDK 源码可能是会改变的，如果正巧需要 patch 的那个源码文件更新了（与这个 bug 无关的修改）， 而且是在想要修改位置的前面，patch 不就不好使了嘛，所以我用的 replace 法

@learningman 啥意思？

我现在写博客也在有意识避免通篇无机质的纯技术性叙述给人带来的压迫感，不过个人会觉得 LZ 的这篇故事成分有点略高，如果是公众号什么的或许能够接受，但是作为技术博客，我应该就不会想去关注收藏了。
顺便贴点我最近写的：

https://www.debuggerx.com/2021/02/23/a-app-bug-caused-by-hand-cream/#%E9%97%AE%E8%AF%A2

https://www.debuggerx.com/2021/03/07/migrate-flutter-project-to-null-safety/

我也在静态博客里用的 Editor.md ，不过看上去 vditor 功能也很完善 ，准备以后有 react 项目需求的时候试试

现在这样才是合理的，想搞成一个接口返回信息和图片内容，看上去是减少了一次请求，实际上却是更浪费的。

@lwlizhe http://www.debuggerx.com/2020/12/29/these-years-about-flutter-and-me/?from=v2ex#5%E6%9C%88

@lwlizhe 我写阅读器的时候也碰到这个问题了，没办法，最后是绞尽脑汁，不分页，用百分比做文章进度转跳，然后每次只绘制当前页和前后页，只 layout 三个页面的文字量，总计算耗时大约十几毫秒，勉强能够接受吧:

http://www.debuggerx.com/2020/12/29/these-years-about-flutter-and-me/?from=v2ex#5 月

@zzw1998 看看我这篇博客：
http://www.debuggerx.com/2021/03/07/migrate-flutter-project-to-null-safety/?from=v2ex

个人开发和工程项目开发的区别。个人开发怎么方便怎么快怎么来，但是多人大项目一直迭代，很多“简单”、“减少工作量”的做法直接会导致项目失控，被这样坑过的人才能真正理解“学院派框架”的优点。
如果看一些资深架构设计的或者大公司的 vue/react 项目，其实很多也早已经变成了“麻烦”的样子。

@tusik 自己部署也可以弄成公网可访问的，一样用私有仓库就行了

@meteor957 #3 因为 rn 的组件就是调用系统内置组件，所以效果和系统默认的一样呗 ：)

@qianji201712 #17 干货 [赞]

@icyalala 我是以我的经验和理解给出解释，有能力的人应该可以顺着这个思路和方向找到解决方案或者自己动手修改，而不是上来就说 flutter 不行、掉帧、不跟手，不要用……

至于你说的，这不是习不习惯的问题，但其实你下面举例的所谓“用户预期”，还是平台固有表现给老用户带来的习惯问题。。私以为，有追求的产品确实应该给各个平台的用户提供最接近习惯的体验，但是这个和大部分使用 Flutter 方案团队的初衷有冲突了。Flutter 最主要还是为了解决跨平台代码共享和表现一致性问题，深层次的这种体验细节，我相信通过自定义物理解算器是可以实现的，但是需要大量的投入，可能对大部分公司都有点不太现实吧……所以总的来说，我也承认这算是 flutter 目前存在的问题吧，但是很多人不知道问题出在哪里，而是不负责任的主观臆测，说是性能问题，我就挺无语的

@James369 习惯问题，其实没有好坏对错。类似的问题还有 MacOS 的鼠标加速度，习惯的人觉得各种好，不习惯的人会很难受。其实大家都是符合所谓“物理运动规律”的，但问题是摩擦系数应该是多大？阻尼应该是多少？最终的感觉就有像是在冰面推石头和在水面推木头的区别，毕竟设计中的元素终归不是现实世界的实体，它们滑动起来该有“多滑”都是带有个人偏好的

看看是不是这个问题：
https://juejin.cn/post/6844904187201847310

分清楚是掉帧问题还是物理动画解算器的效果差异，就像我用惯 Android 后使用 iOS 就会觉得 iOS 的列表默认滑动效果 “太滑”

文字加阴影？类似弹幕，视频画面有时亮有时暗，白色文字加阴影边框才能比较好适应

所以我现在都不改桥接了，反正现在电信给的光猫性能和稳定性也都还行，更多需求直接 DMZ 到下级 pandavan 路由器去处理