這問題，一開始就有。因?yàn)槊χχ矝]管。后來發(fā)現(xiàn)還是很有需要靈活修改代理ip和端口號的。所以得處理一波了。
為鑲黃等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及鑲黃網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為做網(wǎng)站、網(wǎng)站設(shè)計(jì)、鑲黃網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
因?yàn)楸旧碜鯝ndroid出身，就草船借鑒了下Android里的設(shè)置點(diǎn)個(gè)8下，進(jìn)入開發(fā)者模式的套路?？吹竭@，系不系心如明鏡般？哈哈~ 摸著Android過河也是可以的。
解決方案有了：
我們設(shè)置了20次，點(diǎn)點(diǎn)點(diǎn)吧，減小誤觸幾率。
這個(gè)Http代理填寫IP和端口號的頁面，可以新開一個(gè)，就是兩個(gè)輸入框，點(diǎn)Submit后，重置Dio實(shí)例，并把代理設(shè)置給HttpClient。
這里需要注意的是，如果你這里重置了client.findProxy，那么一定要重新實(shí)例化Dio實(shí)例，不然不生效。這一點(diǎn)也可以在源碼中得到印證.
^_^，這就搞完了。還挺簡單的。但是確實(shí)解決了很大的問題，也很靈活。大家自行拿去試試吧。
Stateful（有狀態(tài)） 和 stateless（無狀態(tài)） widgets
stateless widget 沒有內(nèi)部狀態(tài). Icon、 IconButton, 和Text 都是無狀態(tài)widget, 他們都是 StatelessWidget的子類。
stateful widget 是動(dòng)態(tài)的. 用戶可以和其交互 (例如輸入一個(gè)表單、 或者移動(dòng)一個(gè)slider滑塊),或者可以隨時(shí)間改變 (也許是數(shù)據(jù)改變導(dǎo)致的UI更新). Checkbox, Radio, Slider, InkWell, Form, and TextField 都是 stateful widgets, 他們都是 StatefulWidget的子類。
StatefulWidget類
具有可變狀態(tài)的小部件。
狀態(tài)是（1）在構(gòu)建窗口小部件時(shí)可以同步讀取的信息，以及（2）在窗口小部件的生命周期內(nèi)可能會更改的信息。這是小工具實(shí)施者的責(zé)任，以確保國家的及時(shí)通知當(dāng)這種狀態(tài)的改變，使用State.setState。
有狀態(tài)窗口小部件是一個(gè)窗口小部件，它通過構(gòu)建一個(gè)更具體地描述用戶界面的其他窗口小部件來描述用戶界面的一部分。構(gòu)建過程以遞歸方式繼續(xù)，直到用戶界面的描述完全具體（例如，完全由RenderObjectWidget組成，其描述具體的RenderObject）。
當(dāng)您描述的用戶界面部分可以動(dòng)態(tài)更改時(shí)（例如由于具有內(nèi)部時(shí)鐘驅(qū)動(dòng)狀態(tài)或依賴于某些系統(tǒng)狀態(tài)），狀態(tài)窗口小部件非常有用。對于僅依賴于對象本身中的配置信息以及窗口小部件膨脹的 BuildContext的組合，請考慮使用 StatelessWidget。
StatefulWidget實(shí)例本身是不可變的，并且將它們的可變狀態(tài)存儲在由createState方法創(chuàng)建的單獨(dú)State對象中 ，或者存儲在State訂閱的對象中，例如Stream或ChangeNotifier對象，其引用存儲在StatefulWidget的最終字段中本身。
框架在膨脹StatefulWidget時(shí) 調(diào)用createState，這意味著如果該窗口小部件已插入到多個(gè)位置的樹中，則多個(gè)State對象可能與同一StatefulWidget關(guān)聯(lián)。同樣，如果StatefulWidget從樹中移除，后來在樹再次插入時(shí)，框架將調(diào)用createState再創(chuàng)建一個(gè)新的國家目標(biāo)，簡化的生命周期狀態(tài)的對象。
如果StatefulWidget的創(chuàng)建者使用GlobalKey作為其 鍵，則StatefulWidget在從樹中的一個(gè)位置移動(dòng)到另一個(gè)位置時(shí)保持相同的State對象。由于具有GlobalKey的窗口小部件可以在樹中的至多一個(gè)位置使用，因此使用GlobalKey的窗口小部件最多只有一個(gè)關(guān)聯(lián)元素。當(dāng)通過將與該窗口小部件關(guān)聯(lián)的（唯一）子樹從舊位置移植到新位置（而不是在該位置重新創(chuàng)建子樹）時(shí)，框架利用此屬性將全局鍵從樹中的一個(gè)位置移動(dòng)到另一個(gè)位置時(shí)利用此屬性。新的位置）。與StatefulWidget關(guān)聯(lián)的State對象與子樹的其余部分一起被移植，這意味著State對象在新位置被重用（而不是被重新創(chuàng)建）。但是，為了有資格進(jìn)行嫁接，必須將窗口小部件插入到從舊位置移除它的同一動(dòng)畫幀中的新位置。
StatefulWidget有兩個(gè)主要類別。
首先是其中一個(gè)分配資源State.initState并在他們的處置State.dispose，但不依賴于InheritedWidget S或致電State.setState。這些小部件通常在應(yīng)用程序或頁面的根目錄中使用，并通過ChangeNotifier， Stream或其他此類對象與子小部件進(jìn)行通信。遵循這種模式的有狀態(tài)小部件相對便宜（就CPU和GPU周期而言），因?yàn)樗鼈儤?gòu)建一次然后永不更新。因此，它們可能有一些復(fù)雜和深刻的構(gòu)建方法。
第二類是使用State.setState或依賴于 InheritedWidget的小部件。這些通常會在應(yīng)用程序的生命周期內(nèi)重建多次，因此最小化重建此類窗口小部件的影響非常重要。（他們也可以使用State.initState或 State.didChangeDependencies并分配資源，但重要的是他們重建。）
可以使用幾種技術(shù)來最小化重建有狀態(tài)窗口小部件的影響：
StatelessWidget類
一個(gè)不需要可變狀態(tài)的小部件。
無狀態(tài)窗口小部件是一個(gè)窗口小部件，它通過構(gòu)建一個(gè)更具體地描述用戶界面的其他窗口小部件來描述用戶界面的一部分。構(gòu)建過程以遞歸方式繼續(xù)，直到用戶界面的描述完全具體（例如，完全由RenderObjectWidget組成，其描述具體的RenderObject）。
當(dāng)您描述的用戶界面部分不依賴于對象本身的配置信息以及窗口小部件膨脹的BuildContext時(shí)，無狀態(tài)窗口小部件非常有用。對于可以動(dòng)態(tài)更改的組合，例如由于具有內(nèi)部時(shí)鐘驅(qū)動(dòng)狀態(tài)或依賴于某些系統(tǒng)狀態(tài)，請考慮使用StatefulWidget。
無狀態(tài)窗口小部件的構(gòu)建方法通常僅在以下三種情況下調(diào)用：第一次將窗口小部件插入樹中，窗口小部件的父窗口更改其配置時(shí)，以及何時(shí)依賴于更改的InheritedWidget。
如果窗口小部件的父級將定期更改窗口小部件的配置，或者它依賴于經(jīng)常更改的繼承窗口小部件，則優(yōu)化構(gòu)建方法的性能以保持流暢的呈現(xiàn)性能非常重要。
可以使用幾種技術(shù)來最小化重建無狀態(tài)窗口小部件的影響：
dynamic_widget 是一個(gè)可以用json來描述flutter widget的動(dòng)態(tài)布局框架，json code和flutter widget code一一對應(yīng)，如下圖：
dynamic_widget:
Flutter中Widget分為StatefulWidget和StatelessWidget，分別為動(dòng)態(tài)視圖和靜態(tài)視圖，視圖的更新需要調(diào)用StatefulWidget的setState方法，這會遍歷調(diào)用子Widget的build方法。當(dāng)一個(gè)主頁面比較復(fù)雜時(shí)，會包含多個(gè)widget，如果直接調(diào)用setState，會遍歷所有子Widget的build，這是非常不必要的性能開銷，有沒有單獨(dú)刷新指定Widget的方式呢？這個(gè)時(shí)候就要用到GlobalKey了。
一個(gè)StatefulWidget包含一個(gè)Button，一個(gè)Text，通過點(diǎn)擊Button調(diào)用主Widget的setState方法，刷新Text，示例如下：
同樣一個(gè)StatefulWidget包含一個(gè)多個(gè)Text和Button，點(diǎn)擊Button我們只需要刷新指定的Text，通過GlobalKey的方式，實(shí)現(xiàn)如下：
主Widget，包含一個(gè)需要更新的TextWidget和一個(gè)不需要更新的Text
需要單獨(dú)更新的Widget
傳遞事件的Button
這樣點(diǎn)擊Button就只會更新指定的TextWidget了，效果如下：
這只是一個(gè)簡單的例子，在實(shí)際開發(fā)中為了頁面刷新的高效率，模塊化封裝非常重要。很多情況下都只需要局部刷新，而不是重構(gòu)整個(gè)視圖。所以Globalkey的運(yùn)用在項(xiàng)目中需要熟練掌握
最近在做的一個(gè)項(xiàng)目，項(xiàng)目的前期采用Weex開發(fā)。但是隨著交互復(fù)雜度的增加，Weex一處開發(fā)多處多處運(yùn)行的特征并沒有很好的體現(xiàn)，相反很多時(shí)候我們還是需要做IOS和Android的適配。如今火熱的Flutter相比Weex和Rn來說，給出了更好的跨平臺解決方案。所以我們設(shè)計(jì)了一套基于Weex實(shí)現(xiàn)，底層跑在Flutter Engine上的框架。
底層的Runtime采用isolate engine,框架業(yè)務(wù)邏輯，Dom的解析邏輯和Render邏輯都跑在這里。
渲染引擎采用Flutter的Skia，徹底剝離了Android和IOS的差異性.
將Weex VirsualDom的解析都替換成Flutter Widget.
設(shè)計(jì)基于Weex2Dart的Brider,使JS和Dart可以相互調(diào)用
weex-demo的性能展示
release環(huán)境下采用AOT模式，性能會有質(zhì)的飛躍。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能，同時(shí)具有更好的跨平臺性
相比Flutter，具有動(dòng)態(tài)部署的能力（Flutter Release采用AoT模式并沒有動(dòng)態(tài)部署的能力，即使Debug版本也只是開發(fā)環(huán)境下才有動(dòng)態(tài)化能力并沒有可以實(shí)施項(xiàng)目的能力）
只需要會Weex開發(fā)或則Rn開發(fā)就可以，不需要額外學(xué)習(xí)Dart，已有的Weex項(xiàng)目可以無縫切換。
效果比較多的是動(dòng)態(tài)體驗(yàn)，可以編寫后查看效果；
參考自 CSDN的Flutter入門課程
重慶分公司
重慶分公司
