公司考虑到之后要开发一个较大的版本，所以准备引入flutter框架来开发新的功能。
Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面。 Flutter可以与现有的代码一起工作。在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。
由于我之前也只是听过flutter，并没有任何实操的经历，所以这次的新版本开发，准备用几个简单的界面来进行实践。
随着版本的逐步迭代，之后的功能会越来越多，而按照目前的人手来看，要想提高开发效率，目前可以做的就是从工具着手，提前做好准备。跨平台技术进过几年的发展，最新一代的技术就落在了flutter上，无论从性能还是适配方面，它占有绝对的优势。
此次我主要的任务就是将重心放在研究flutter上，知道在这过程中会遇到各种各样的坑，但是没有想到比我想象中的更多。因为flutter的版本一直在更新中，而网上能搜到安装flutter环境的文章大部分是几个月前的文章。虽说大同小异，但实际上还是会有些差别。所以当我再去搭建flutter环境时，因为参考的是比较老的文章，而自己的安装包又是最新的，这就导致了一些问题，最终还是参考官方的文档来解决了该问题。
如果官方文档也是最新那就好办了，但某些地方官方的文档也不是很准，当我在后面去生成依赖包给他人用的时候，按照官方文档的写法，相应的界面却总是无法出现。再次确认没有遗漏，还是不成时，我就去搜索新的方案，发现有很多网友也遇到该同样的问题。有网友也给出了相应的解决方案，我按照他们自己的方式去实现后，我这边最终也能够跑通。
这真是一个史前巨坑啊。有时候按照官方的文档去实现是可以解决问题，而有时候却因为文档没有及时更新而导致新的问题出现。
那么该无何避免这样一种情况呢？那时候我的头脑中就有一个观念，钥匙并不在锁头上。因为如果钥匙在锁头上，那么这个锁就是开的，不再锁住。所以说钥匙当然是在别的地方，换句话说当此路走不通的时候，那就要想着去尝试着另外一条路，如果一直盯着锁看，那它必定还是锁着的。
假如说我认定官方文档没有问题，那这个问题就会一直困扰着我，而如果当我去怀疑官方文档也不一定准确时，所以我就得从其他的方面去着手来去印证，从而遇到的问题很可能就会解决。
