Flutter相关项目维护心得
心得
写自己的项目倒是没什么积极性，一直在维护别人的项目
Kazumi 项目
最近维护的是 Kazumi
Issue 1418 的 PR
在 Issue1418 中收获良多，看人家的代码学习了属于是
捋了一下，基础架构可能是：Hive 数据库（NoSQL），封装为 GStorage 类，提供外部接口供人调用，
然后是 showDialog 等，自己封装了一层 Layer 出来方便在需要用到对话框的地方调用
这种分层的设计思想挺好的，相对而言比较解耦。
此外就是我自己注释的问题被吐槽了（说我给一些没必要的东西加注释……）
然后是关于 vscode 配置和 pubspec 文件的问题，因为我把自己的给交上去然后被说了，
下次注意纳入包管理的时候不要破坏 main 环境
之后是项目所有者 Predidit 给出的一些建议：
==@aliferne==
顺带问一下，构建软件并发布的相关教程是在哪里看的？我只写过小软件但还没发布经验。
如果你是指 github actions 中的 CI 的话，我最开始也是从其他项目里抄的，如果你感兴趣的话，也可以直接用 kazumi 现在的 github actions 的配置。
如果你是指 f-droid/flatpak 发布，或是 signpath 签名这些东西的话，它们都有相关的文档，并且他们的支持人员都很乐于助人。
然后是把 pubspec.lock 文件纳入 Git 管理的问题，官方是推荐这么做的
Issue 1413 的 PR
本次主要是学到了 分支 与 PR 的对应关系：
==@aliferne==
我似乎在重新创建一个简单得多的 PR 中遇到了困难我打开 GitHub 然后创建 Pull Request 的时候总是会让我 View Pull Request，然后跳转到这里来
我打算关闭这个 PR，先提交那个，然后重新来过，你觉得怎样
==@Predidit==:
PR 是跟随分支的，提交 PR 的一般流程是单独建立一个相关的分支，从对应分支发起 PR ，而不是从 fork 仓库的 main 分支 PR这样才能保证各个 PR 的独立，并且各个分支的变更会被实时同步到对应的 PR
在你的现在的处理下，如果你想保留这个 PR ，需要先 revert 掉在这个PR上多余的弹幕相关的提交，让这个 PR 恢复正常
然后从你的 fork 仓库建立一个新的分支，那个分支基于 kazumi 主分支，而不是你现在这个修改过了的分支，然后在那个分支上应用弹幕相关变更，并从那个分支发起 PR
换句话说，老生常谈的 main-dev 分支模式，在 dev 上去修改东西，PR 也在 dev 上发起，不要污染 main 分支，改几个 PR 就弄几个 dev
此外就是不要将 controller 作为注入项传入，这可能和 controller 本身所要负责的逻辑等有关，
如果传 controller，反而就不确定什么时候会被 dispose 了，可能会在页面退出前 dispose，也可能一直都不会被 dispose，
不管是哪个，结果上来说都不太好（内存泄漏或者程序提前终止啥的）
然后是自己在写代码加 feature 的时候发现其实对于 search_controller.dart 这种文件（用的是 MobX 库），
需要注意一下就是用 Observer 模式之类的，和 setState 还是不太一样的，观察-被观察，然后触发重建。
这个问题主要是在写过滤开关的时候碰到的问题，Switch 就是切换不了状态——我的推测是没重建，事实也确实如此，但是更复杂一点：
- 改了 search_controller.dart 却没跑
flutter pub run build_runner build，导致修改没有及时更新到.g.dart文件中，然后导致一些东西还是未修改前的逻辑 - 有观察者模式不用，要用
setState，然后搞半天没搞出来，本来这个 PR 其实可以快点提交的
其他暗病倒是没有了，此外就是成功在 Kazumi 的 Contributors 中上榜了（乐，还是别人告诉我的）