UI组件选择历程

[toc]

FlutterGetX框架选择历程

为什么

• Flutter 状态管理框架 Provider 和 Get 分析

前言

1.getX的功能不只是只有状态管理功能。
2.只是为了状态管理的话，项目中新功能可使用。使用不影响其他人。且目前项目中的依赖已包含getX。
3.如果是旧功能，在赶项目的阶段如果没法把握能保量保质的完成开发，不建议使用。当然还是希望大家使用，但任务的完成质量是第一位，如果只是为了使用而影响了项目进度，我认为不是特别可取，除非涉及严重问题不得不。所以没有规定不能使用，但结果是要完成好开发，而不是简单的“好了”，然后存在有很多细节没完善的地方。

对于一个功能，我认为所谓的好了，起码是
①主流程没问题，
②特殊流程已处理，
③异常已容错，
④界面效果与ui完全一致，不差任何一两个像素及颜色偏差，
⑤使用上至少不存在用户感知到的卡顿，
⑥自己发现的问题已跟进处理，而不是挂着等测试或产品提，
⑦别人发现的也一样处理，而不是不重要，
⑧甚至不应该出现用户感知是可点击的，结果点了了没任何效果的问题，哪个加个toast也比没有强
⑨流程上的有些偏可以下沉到底层的，如按钮的重复点击问题处理，图片的加载缓存404等处理，是否在自己的模块上处理完成，或者说告知之前这块没处理过，后面安排处理，
⑩debug模式是否正常，而不是像项目一开始时候的debug都基本无法debug，都在跑release。
等等…

对内的代码结构是否合理，

所以在能保证质量完成开发或者除了不影响使用的解决不了的情况下很希望大家也多看看多学学多了解和使用一些优秀的框架。但框架是为开发服务的，不能说想使用了什么框架结果完成不了，或做得有点大概。
4.另外对于getX的状态管理使用，也不是一使用了就得全部替换，甚至说新功能就一定得按getX来实现。拿个关于页面，一个简单页面用getX与现有的，反而使用getX可认为是完全没必要，因为页面可认为是不需要“可变”状态，只是需要很独立的数据显示而已。类似于做原生，也有很多优秀的框架甚至架构，但mvc的模式肯定在你的项目里有存在，而且在那种场景下，它的优点反而更明显。可以理解为越简单的东西越没有必要使用非常强大的框架，没必要用大炮打小鸟。

优秀新框架的初使用，我认为在前期是允许使用，而不是规定都得使用。好比有人很熟悉，但其他人不熟悉可能做起来，他就没法完成他原本安排的任务，形象而夸大的说，可以想象成让你换个语言开发，排期不变，保证开发完成和质量，而且还不是说他那块的就一定得使用新框架才能。

所以鼓励使用优秀的技术，但别忘了保证完成自己的开发。当然使用新技术时候，如果时间差不多，也可同产品商量适当一两天，在其接受延期的情况下才能延期，不然要使用的话，哪怕加再多班也得完成。而对于一些类似完全重构的任务，自然会同产品协商专门安排一期处理。不管是原生开发还是跨平台，我觉得这些理念和思维应该都差不多。

End