这问题，一开始就有。因为忙着忙着也没管。后来发现还是很有需要灵活修改代理ip和端口号的。所以得处理一波了。
为镶黄等地区用户提供了全套网页设计制作服务，及镶黄网站建设行业解决方案。主营业务为做网站、网站设计、镶黄网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
因为本身做Android出身，就草船借鉴了下Android里的设置点个8下，进入开发者模式的套路。看到这，系不系心如明镜般？哈哈~ 摸着Android过河也是可以的。
解决方案有了：
我们设置了20次，点点点吧，减小误触几率。
这个Http代理填写IP和端口号的页面，可以新开一个，就是两个输入框，点Submit后，重置Dio实例，并把代理设置给HttpClient。
这里需要注意的是，如果你这里重置了client.findProxy，那么一定要重新实例化Dio实例，不然不生效。这一点也可以在源码中得到印证.
^_^，这就搞完了。还挺简单的。但是确实解决了很大的问题，也很灵活。大家自行拿去试试吧。
Stateful（有状态） 和 stateless（无状态） widgets
stateless widget 没有内部状态. Icon、 IconButton, 和Text 都是无状态widget, 他们都是 StatelessWidget的子类。
stateful widget 是动态的. 用户可以和其交互 (例如输入一个表单、 或者移动一个slider滑块),或者可以随时间改变 (也许是数据改变导致的UI更新). Checkbox, Radio, Slider, InkWell, Form, and TextField 都是 stateful widgets, 他们都是 StatefulWidget的子类。
StatefulWidget类
具有可变状态的小部件。
状态是（1）在构建窗口小部件时可以同步读取的信息，以及（2）在窗口小部件的生命周期内可能会更改的信息。这是小工具实施者的责任，以确保国家的及时通知当这种状态的改变，使用State.setState。
有状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。
当您描述的用户界面部分可以动态更改时（例如由于具有内部时钟驱动状态或依赖于某些系统状态），状态窗口小部件非常有用。对于仅依赖于对象本身中的配置信息以及窗口小部件膨胀的 BuildContext的组合，请考虑使用 StatelessWidget。
StatefulWidget实例本身是不可变的，并且将它们的可变状态存储在由createState方法创建的单独State对象中 ，或者存储在State订阅的对象中，例如Stream或ChangeNotifier对象，其引用存储在StatefulWidget的最终字段中本身。
框架在膨胀StatefulWidget时 调用createState，这意味着如果该窗口小部件已插入到多个位置的树中，则多个State对象可能与同一StatefulWidget关联。同样，如果StatefulWidget从树中移除，后来在树再次插入时，框架将调用createState再创建一个新的国家目标，简化的生命周期状态的对象。
如果StatefulWidget的创建者使用GlobalKey作为其 键，则StatefulWidget在从树中的一个位置移动到另一个位置时保持相同的State对象。由于具有GlobalKey的窗口小部件可以在树中的至多一个位置使用，因此使用GlobalKey的窗口小部件最多只有一个关联元素。当通过将与该窗口小部件关联的（唯一）子树从旧位置移植到新位置（而不是在该位置重新创建子树）时，框架利用此属性将全局键从树中的一个位置移动到另一个位置时利用此属性。新的位置）。与StatefulWidget关联的State对象与子树的其余部分一起被移植，这意味着State对象在新位置被重用（而不是被重新创建）。但是，为了有资格进行嫁接，必须将窗口小部件插入到从旧位置移除它的同一动画帧中的新位置。
StatefulWidget有两个主要类别。
首先是其中一个分配资源State.initState并在他们的处置State.dispose，但不依赖于InheritedWidget S或致电State.setState。这些小部件通常在应用程序或页面的根目录中使用，并通过ChangeNotifier， Stream或其他此类对象与子小部件进行通信。遵循这种模式的有状态小部件相对便宜（就CPU和GPU周期而言），因为它们构建一次然后永不更新。因此，它们可能有一些复杂和深刻的构建方法。
第二类是使用State.setState或依赖于 InheritedWidget的小部件。这些通常会在应用程序的生命周期内重建多次，因此最小化重建此类窗口小部件的影响非常重要。（他们也可以使用State.initState或 State.didChangeDependencies并分配资源，但重要的是他们重建。）
可以使用几种技术来最小化重建有状态窗口小部件的影响：
StatelessWidget类
一个不需要可变状态的小部件。
无状态窗口小部件是一个窗口小部件，它通过构建一个更具体地描述用户界面的其他窗口小部件来描述用户界面的一部分。构建过程以递归方式继续，直到用户界面的描述完全具体（例如，完全由RenderObjectWidget组成，其描述具体的RenderObject）。
当您描述的用户界面部分不依赖于对象本身的配置信息以及窗口小部件膨胀的BuildContext时，无状态窗口小部件非常有用。对于可以动态更改的组合，例如由于具有内部时钟驱动状态或依赖于某些系统状态，请考虑使用StatefulWidget。
无状态窗口小部件的构建方法通常仅在以下三种情况下调用：第一次将窗口小部件插入树中，窗口小部件的父窗口更改其配置时，以及何时依赖于更改的InheritedWidget。
如果窗口小部件的父级将定期更改窗口小部件的配置，或者它依赖于经常更改的继承窗口小部件，则优化构建方法的性能以保持流畅的呈现性能非常重要。
可以使用几种技术来最小化重建无状态窗口小部件的影响：
dynamic_widget 是一个可以用json来描述flutter widget的动态布局框架，json code和flutter widget code一一对应，如下图：
dynamic_widget:
Flutter中Widget分为StatefulWidget和StatelessWidget，分别为动态视图和静态视图，视图的更新需要调用StatefulWidget的setState方法，这会遍历调用子Widget的build方法。当一个主页面比较复杂时，会包含多个widget，如果直接调用setState，会遍历所有子Widget的build，这是非常不必要的性能开销，有没有单独刷新指定Widget的方式呢？这个时候就要用到GlobalKey了。
一个StatefulWidget包含一个Button，一个Text，通过点击Button调用主Widget的setState方法，刷新Text，示例如下：
同样一个StatefulWidget包含一个多个Text和Button，点击Button我们只需要刷新指定的Text，通过GlobalKey的方式，实现如下：
主Widget，包含一个需要更新的TextWidget和一个不需要更新的Text
需要单独更新的Widget
传递事件的Button
这样点击Button就只会更新指定的TextWidget了，效果如下：
这只是一个简单的例子，在实际开发中为了页面刷新的高效率，模块化封装非常重要。很多情况下都只需要局部刷新，而不是重构整个视图。所以Globalkey的运用在项目中需要熟练掌握
最近在做的一个项目，项目的前期采用Weex开发。但是随着交互复杂度的增加，Weex一处开发多处多处运行的特征并没有很好的体现，相反很多时候我们还是需要做IOS和Android的适配。如今火热的Flutter相比Weex和Rn来说，给出了更好的跨平台解决方案。所以我们设计了一套基于Weex实现，底层跑在Flutter Engine上的框架。
底层的Runtime采用isolate engine,框架业务逻辑，Dom的解析逻辑和Render逻辑都跑在这里。
渲染引擎采用Flutter的Skia，彻底剥离了Android和IOS的差异性.
将Weex VirsualDom的解析都替换成Flutter Widget.
设计基于Weex2Dart的Brider,使JS和Dart可以相互调用
weex-demo的性能展示
release环境下采用AOT模式，性能会有质的飞跃。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能，同时具有更好的跨平台性
相比Flutter，具有动态部署的能力（Flutter Release采用AoT模式并没有动态部署的能力，即使Debug版本也只是开发环境下才有动态化能力并没有可以实施项目的能力）
只需要会Weex开发或则Rn开发就可以，不需要额外学习Dart，已有的Weex项目可以无缝切换。
效果比较多的是动态体验，可以编写后查看效果；
参考自 CSDN的Flutter入门课程