kotlin_android
λ：
一直想写这份笔记。单是kotlin，就值得写。而kotlin早已被定为android开发一等语言，这也是kotlin最大的用武之地，所以把这两个东西放一块。
我大二决定用kotlin写andorid的时候，Google刚把它置为一等开发语言两年多，市场大多数项目还是java，网上教程和学校里教的，也都还是java版本。但是我还是一如既往，不喜欢被牵着走。我花时间去读kotlin文档，如haskell rust scala等语言一样，是现在流行的“函数式”风格。语法设计简单先进，并没有难的地方，但又是强大灵活。
写这种语言，代码量不多，但是动脑子多，怎样用最精简又不邪恶的写法实现一个功能，是真正体现水平的。就像我现在工作中正在写的flutter项目，一个功能函数被洋洋洒洒写了一页代码，乍一看肯定是复杂功能。但其实是因为糊代码惯了，动不动定临时变量、for循环，再加上算法学的糟糕，才会写出这种糟糕的代码。这个函数我重写后只有一行代码，本着“不能邪恶”的原则，我拆成两行。所以，真的是业务逻辑复杂吗，总觉得是基础不过关。写东西不动脑子一通糊。我感觉我现在专职删代码。
那时kotlin还在1.2.*，协程还没稳定。而android还没重构andoridx库，也没有jetpack。当时好用的kotlin android库是anko，现在已经停止维护，因为有了jetpack。尽管如此，单凭kotlin语言和原有库的支持，已经比java好太多了。
现在，Google出了androidx jetpack，kotlin 协程也早就稳定，更重要的是Google健全了开发文档。andorid developer 官网 从mvvm架构，到组件和工具的最佳组合，都有详细文档。同时还有jetpack最佳实践demo应用：sunflower。并且明确说明部分内容只支持kotlin。
要是新起个项目还是用java或者换汤不换药：仅仅是换个语言，架构和库仍是老旧过时。那就太不应该了，在我看来只是不爱学习罢了，其他都是借口。别人费力才去掉的诟病、糟粕，全都被找回来，还觉得自己起个架构很牛逼，优越感油然而生，于是觉得没人比得上自己，不必学习靠现有的知识储量也能胜任工作。因为不学习，所以遇到问题又拿出远古的解决方案…… 这就是循环。
关于坏习惯，不能再展开了。因为这些坏习惯导致了项目不断变糟糕。现在之所以重新拾起学习android新库这件事，是因为现有的正在开发的flutter项目因为StatefulWidget Provider等滥用、功能暴力实现等等导致性能出现大问题，而且功能还是不稳定的。以前只有一两个人开发的时候，我还有救场和修正的余地，但是现在人多了，我根本修不过来。人多不一定力量大，不看文档照葫芦画瓢写出来的东西，在我看来是在添乱。一个简单的列表，能有肉眼可见的掉帧卡顿，实现得有多糟糕。我优化了首页列表，可是这种实现还有很多，总不能我挨个重构，而且我一己之力追不上这么多人“创造”的速度。而且有点难度的需求和样式，就会说sdk不支持，我们不是原生之类的。实际并不是，所以这种需求都是我接，一群人说着这不行那不行的时候，我就说一个“可以”，然后就都不说话了。现在又换了新的说法：需求不合理，没有这么做的。产品就会说哪些主流app就是这样的… 不是sdk做不到，是用的人不知道sdk能做。
摆在我这的有两条路，用flutter重构掉糟糕的实现,或者用原生从头构建，android ios 各一套。我估计了一下，要是flutter修改的话，无异于从头写，也就省去第一次写时的踩坑时间。而且之后的新需求肯定还会出这种问题，难道要不断地这样推翻写好的东西，为什么不在第一实现的时候多学学，好好写？ 既然无异于从头写，不如直接原生重构，原生里写的烂和好性能应该不会有太大差距，当然有可能又是我想多了…
学习来源：
| gradle android 配置 build 变体 | 2022.08.19 |
| Android RecyclerView | 2022.02.25 |
| Android DataStore | 2022.02.24 |
| Android 底部导航栏+页面切换 | 2021.9.9 |
| kotlin 回调转协程挂起函数 | 2021.8.7 |
| gradle迁到kts, 以及module管理 | 2021.08.29 |
| android 依赖注入 | 2021.08.21 |
| android ViewBinding, DataBinding | 2021.04.23 |
| Android Skia图形库 | 2020.12.17 |
| Android navigation组件 | 2020.11.24 |
| android mvvm架构 | 2020.10.23 |