將枚舉類型更改為常規(guī)類或?qū)⒊Ｒ?guī)類更改為枚舉類型時，熱重載(r)不起作用。 需要hot restart(cmd + shift + r)
成都創(chuàng)新互聯(lián)公司長期為數(shù)千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為瑞昌企業(yè)提供專業(yè)的網(wǎng)站設計、網(wǎng)站建設，瑞昌網(wǎng)站改版等技術服務。擁有十年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
修改泛型類型聲明后，熱重裝將無法工作。 例如，以下操作將無效：
Widget 快速替換 、 包裝 、 移動 、 刪除 、 抽取成變量 、 抽取成方法
焦點放到相應的widget上, 然后 cmd + . 如果提示沒有相關操作,多試幾次
如題，在Flutter開發(fā)中，正常情況下，修改后按保存（ctrl+s），就能自動將更新內(nèi)容熱加載到設備中，但是我早上突然就遇到保存后沒有熱加載的情況。
試了試，有的頁面是沒問題，可以熱更新的，有的頁面不行，那應該就是某些頁面的問題了。在熱更新生效的頁面，每次保存后查看Run里面輸出的日志，發(fā)現(xiàn)最后一行是類似：
而熱更新無效的頁面，保存后的日志是：
也就是AS沒有找到改變的東西，所以沒更新。
聯(lián)想到早些時候把幾個dart文件的位置拖動了下，是不是那個操作引起的問題，打開來看了看，發(fā)現(xiàn)了問題所在。那些引用被拖動文件的地方，引用語句由
變成了
（***是我脫敏替代了）
導致AS無法加載最新修改的內(nèi)容。
把引用方式由file的方式改回package的方式就行。
以上。
最近項目中要集成flutter來進行混編，但是在集成后，突然遇到一個很神奇的問題，在debug模式下，用數(shù)據(jù)線連接真機打包可以打開flutter頁面，但是一旦拔掉數(shù)據(jù)線，再打開flutter頁面就不行了，開始以為是因為flutterSDK的原因，但是一查資料才發(fā)現(xiàn)，原來是因為debug模式下flutter實現(xiàn)了熱重載，默認的編譯方式是JIV,但是iOS14+之后的系統(tǒng)限制了JIV這種編譯方式，所以連接Xcode重新run一個release包就可以了，因為flutter在release模式下的編譯方式是AOT，iOS14+的系統(tǒng)是支持這種編譯方式的，具體解決方案如下圖
再運行就可以了。
當然還有另外一種解決方案，就是修改flutter的編譯配置，強制設為release
Flutter可以算是當下最火熱的新技術之一，我現(xiàn)在所在團隊也準備將Flutter技術應用到線上工程中。
關于混合工程，官方文檔其實寫的已經(jīng)比較清楚了，按著文檔走一般問題不大，
但是有一點值得注意的是，F(xiàn)lutter工程引入的庫的gradle的 buildTypes 要與原工程保持一致，如果不一致需要手工添加。
進入正題，現(xiàn)在Flutter官方默認只提供armeabi-v7a、arm64-v8a、x86和x86-64，其中x86和x86-64是為模擬器準備的。目前我們使用的SDK大部分只使用了armeabi架構，直接使用我們會遇見找不到 libflutter.so，libapp.so 的情況，所以我們需要對FlutterSDK做一定的改造。
首先我們要了解下Flutter編譯產(chǎn)物，因為不同版本產(chǎn)物是不同的，這里我們只針對Flutter 1.9.1-hotfixes來說。除了資源文件之外，F(xiàn)lutter打包會生成兩個非常重要的so庫，他們分別是 libflutter.so，libapp.so 。其中 libflutter.so 是Flutter的SDK產(chǎn)物而 libapp.so 正是我們編寫的dart文件的產(chǎn)物。默認情況下，這兩個文件都會出現(xiàn)在armeabi-v7a中，因此我們要作出對應的改造。
libflutter.so 位于FlutterSDK中，這里順帶提一句，除了這對不同CPU架構，它還分為Debug版和Release版，它們的區(qū)別在于Debug是為JIT編譯方式打造的，體積較大而Release是為AOT編譯方式打造的，體積很小。對 libflutter.so 的改造，只要將其移動文件路徑即可，運行以下腳本即可，此腳本來自美團分享的Flutter文章。
移動完了 libflutter.so 之后我們打包發(fā)現(xiàn)， libapp.so 仍然會出現(xiàn)在armeabi-v7a中，所以第二部我們就是移動 libapp.so 。這個需要更改 flutter.gradle ，我們在 flutter.gradle 的45行可以看到如下定義，它定義了我們的環(huán)境。
在524行我們可以看到，abiValue的取值就是根據(jù)上述定義值。
所以結論很簡單，只要將
private static final String ARCH_ARM32 = "armeabi-v7a";
改為
private static final String ARCH_ARM32 = "armeabi";
就可以完成對與 libflutter.so 的移動。
前期工作我們都做好了，打成aar就非常簡單了
直接使用 flutter build aar --target-platform android-arm
打出來后可以解壓檢查下 libflutter.so，libapp.so 是否都在armeabi文件夾下即可。
說完了armeabi適配問題，這里下說下有關于有關于FlutterBoost的接入。這個東西接入有兩點要注意。
在主app內(nèi)加上即可，常規(guī)操作，強制統(tǒng)一support包的版本號
注釋flutter.gradle第655行。因為編譯過程中，會去初始化插件項目的buildType下面的debug配置，而插件項目下并未配置debug，導致報錯。
如果發(fā)現(xiàn)文章中有錯誤或者有更好的解決方案歡迎指正留言，當然如果本篇文章幫助你解決了問題，也不要吝嗇你的感謝。謝謝各位。
重慶分公司
重慶分公司
