隨著我們對web前端編程開發(fā)技術(shù)的掌握，越來越多的框架語言和架構(gòu)方式被我們所熟知。
定興ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
下面廣州北大青鳥就一起來了解一下，web前端開發(fā)的一些常見框架結(jié)構(gòu)。
1.全包型這類框架大的特點就是從底層的渲染引擎、布局引擎，到中層的DSL，再到上層的框架全部由自己開發(fā)，代表框架是Qt和Flutter。
這類框架優(yōu)點非常明顯：性能(的上限)高;各平臺渲染結(jié)果一致。
缺點也非常明顯：需要完全重新學習DSL(QML/Dart)，以及難以適配中國特色的端：小程序。
這類框架是原始也是純正的的多端開發(fā)框架，由于底層到上層每個環(huán)節(jié)都掌握在自己手里，也能大可能地去保證開發(fā)和跨端體驗一致。
但它們的框架研發(fā)成本巨大，渲染引擎、布局引擎、DSL、上層框架每個部分都需要大量人力開發(fā)維護。
2.Web技術(shù)型這類框架把Web技術(shù)(JavaScript，CSS)帶到移動開發(fā)中，自研布局引擎處理CSS，使用JavaScript寫業(yè)務邏輯，使用流行的前端框架作為DSL，各端分別使用各自的原生組件渲染。
代表框架是ReactNative和Weex，這樣做的優(yōu)點有：開發(fā)迅速;復用前端生態(tài);易于學習上手，不管前端后端移動端，多多少少都會一點JS、CSS。
缺點有：1.交互復雜時難以寫出高性能的代碼，這類框架的設計就必然導致JS和Native之間需要通信，類似于手勢操作這樣頻繁地觸發(fā)通信就很可能使得UI無法在16ms內(nèi)及時繪制。
ReactNative有一些聲明式的組件可以避免這個問題，但聲明式的寫法很難滿足復雜交互的需求。
2.由于沒有渲染引擎，使用各端的原生組件渲染，相同代碼渲染的一致性沒有一種高。
3.JavaScript編譯型這類框架就是我們這篇文章的主角們：Taro、WePY、uni-app、mpvue、chameleon，它們的原理也都大同小異：先以JavaScript作為基礎選定一個DSL框架，以這個DSL框架為標準在各端分別編譯為不同的代碼，各端分別有一個運行時框架或兼容組件庫保證代碼正確運行。
flutter很強，目前一套代碼可以供Android，iOS， Web 使用，妥妥的一套代碼，多端使用，在跨平臺開發(fā)中，有著巨大的影響。
相對于iOS開發(fā)，F(xiàn)lutter的布局更具有靈活性，每個頁面設計都不一樣，相同頁面可選擇的布局方式也不一樣，如果單純的說應該如何去布局，我覺得不現(xiàn)實，大家可以參考下 Flutter官方的布局教程 。接下來，筆者，通過項目中的一個頁面，來一步一步的拆解布局的流程。整個過程，基本上按照拆解、組件封裝、具體布局這三步來的。
根據(jù)設計圖，可以看出整體可以分成兩部分，上面一部分是系統(tǒng)介紹模塊，下面一部分是真正的登錄內(nèi)容，因為涉及到疊加，因此考慮用Stack；
系統(tǒng)介紹模塊部分：整體也是涉及到疊加，考慮用Stack，分為四部分。最底部漸變色背景用一個contanier，無須指定位置，全視圖擴展；載放logo圖標在上一層，用Image。最后兩個Text同級放在最上層。Image，Text各用Positioned包裹去指定位置。
登錄內(nèi)容模塊是最外層是一個Contanier容器，去控制背景色和圓角。然后是一個Column元素，逐行排列。
第一行為Image，
第二行為Text，
第三行可以看成一個小Column，分兩塊進行布局
第四行可以看成一個小Column，分兩塊進行布局
第五行可以看作一個TextButton，
第六行可以看作一個Row，分三塊進行布局
通過上面這樣一步一步的分析后，基本上對大致的布局有了一個了解，最外層的控件大致選對（只要能實現(xiàn)的話，就是復雜度以及效率的問題），然后一步一步的拆解每一行的元素，如果有重復的或者覺得可以封裝出來的部分，則進行下一步。
每一行的拆解，大致也是按照這個思路來進行，因此筆者在這里就不做講解了。
在做到第三第四行的時候，發(fā)現(xiàn)這兩個很相似，而且設計到一些交互邏輯，筆者就想對第三第四行的這種展示進行封裝，覺得今后的布局可能會用到，因此在這一步，可以先把這一塊兒抽離出一個控件。利用TextField來實現(xiàn)這種輸入操作，具體的實現(xiàn)筆者不再詳細的描述了。
經(jīng)過這一步，整體的規(guī)劃設計圖已經(jīng)有了，各個組件也都有了，接下來的工作就是組裝了。
具體布局設計到一些細節(jié)的地方，例如整體Column的居中對齊（crossAxisAlignment）、間隔（Padding或Container包裹，筆者更喜歡用SizedBox占位）、居左居右居中（Align）、點擊事件（GestureDetector）以及圓角（BorderRadius）等一些特殊情況。
像第六行row是放在底部的，就可以在第六行前面增加一個Spacer()去填充空白區(qū)域。
對文字顏色大小等，可以用TextStyle直接設置。
對于輸入框的刪除按鈕，可以用Offstage這種Flutter特有的控制顯示隱藏的控件。
作者：閑魚技術(shù)－國有
國有，閑魚架構(gòu)團隊負責人。在7月13號落幕的2019年Archsummit峰會上就近一年來閑魚在FlutterFaaS一體化項目上的 探索 和實踐進行了分享。
隨著無線，IoT的發(fā)展，5G的到來，移動研發(fā)越發(fā)向多端化發(fā)展。傳統(tǒng)的基于Native＋Web＋服務端的開發(fā)方式，研發(fā)效率低下，顯然已經(jīng)無法適應發(fā)展需要。
我們希望 探索 閑魚這樣規(guī)模的獨立APP的高效研發(fā)架構(gòu)。主要思路是圍繞Flutter解決多端問題，并使Flutter與FaaS等無服務容能力打通，形成云端一體化的研發(fā)能力，支持一云多端的發(fā)展需要。在某些場景已經(jīng)取得效果，希望分享過程中的思考，與大家交流。
閑魚選擇Flutter主要是出于高性能的考慮。Flutter高性能主要來源于2個原因：
更多比較：
沒有銀彈的解決方案，F(xiàn)lutter與RN各有優(yōu)點。如何選擇因素很多，關(guān)鍵看如何取舍，舉個例子：
云端技術(shù)棧的打通，是減少協(xié)同的不錯的解法。以往前端＋Node.js的一體化方案大家應該不會陌生，然而如果端側(cè)使用了Flutter，那云側(cè)Dart自然是第一選擇。
FaaS的本質(zhì)是運行在云端，那Dart適合用在云/Server上嗎？
Dart語言早于Flutter，在最初的設計上，Dart就可以用于Web、Server。Dart具備一些服務端語言的特點：
閑魚首先嘗試將Dart作為普通的Server，替代傳統(tǒng)的Java Server，然后再將Dart容器嵌入到FaaS容器中。建立Dart Server能力是第一步，也是主要的工作量所在。
閑魚在Dart Server方面的建設思路：
開發(fā)期：
運行期：
上述內(nèi)容實現(xiàn)了FlutterDart FaaS的技術(shù)棧的統(tǒng)一，但僅技術(shù)棧統(tǒng)一還遠遠不夠，端、云的同學仍然無法真正互補和一體化打通，原因在于還有更多深入問題需要考慮：
面向這些問題，閑魚的解法思路：
案例一，一體化在資源均衡方面的體現(xiàn)。在近期的一個項目中，云端一體化使原本2個月的項目時間，減少了20天。
案例二，一體化在業(yè)務閉環(huán)方面的體現(xiàn)。負責增長的一位開發(fā)同學，專注在增長業(yè)務上，在合適的情況下為合適的人投放合適的內(nèi)容，以此帶來用戶的增長和活躍效果。一體化的方式下，可以統(tǒng)一云、端的切面，業(yè)務研發(fā)不再受云、端的限制。
一體化是建設高效研發(fā)框架的方向，并不是所有場景都需要一體化的開發(fā)，但一體化的Flutter、FaaS等技術(shù)組件，可以獨立使用，也會帶來效率提升，并且與原有的開發(fā)模式兼容。從一體化的思路去建設，可以使整體架構(gòu)體系更加一致，也有機會做一體的架構(gòu)沉淀。
未來閑魚希望在一體化上做更多嘗試和深入 探索 ，包括一體化工具、一體化業(yè)務平臺、數(shù)據(jù)化智能化等方向。
下面這種情況下，為 InkWell 設置的 splashColor 不會生效：
需要用 Material 去除背景色，然后將顏色設置在 InkWell 外部：
在 Dialog builder 中使用 WillPopScope 禁用返回鍵返回：
注意：使用此方法同時也會禁用 iOS 上的手勢滑動返回功能，推薦判斷平臺后再使用。
修改對話框中的復選框狀態(tài)，最簡便的方法是通過 Element 中的 markNeedsBuild 方法：
當然，更推薦的做法是通過 StatefulBuilder ，然后就可以在 Dialog 中調(diào)用 setState 方法了，不過在調(diào)用 setState 時需要判斷 Dialog 是否已經(jīng)關(guān)閉，否則會造成 setState() called after dispose() 的錯誤，可以通過添加一個標志位來解決，如下：
在 Web 中加載網(wǎng)絡圖片有時會失敗，遇到這樣的報錯： Exception caught by image resource service... ，造成該錯誤的原因通常是，圖片跨域了（見 跨域資源共享 ）。最簡單的解決辦法是， 使用 HTML 渲染加載 ，而不是默認的 CanvasKit。
Flutter 中所有的 list 默認都是沒有 ScrollBar 的，必須使用 ScrollBar 組件。ScrollBar 組件通過監(jiān)聽 ScrollView 的 ScrollNotification 來刷新位置，所以 List 的長度必須是固定的。
當使用 WebView 等高度不定的組件時會出現(xiàn)內(nèi)容被截斷的情況，通常可以使用 NestedScrollView 來解決該問題，需要在 WebView 外部嵌套 SingleChildScrollView。
雖然使用了緩存，而且也是用 builder 加載圖片的，但是發(fā)現(xiàn)一個現(xiàn)象：滑動屏幕后圖片短暫消失并重新加載了。圖片高度很高時這種現(xiàn)象更加明顯，其原因是超出屏幕范圍一定距離的組件被重新渲染了。解決方法是在 ListView 上設置 cacheExtent 參數(shù):
該參數(shù)的作用是改變超出屏幕高度后繼續(xù)渲染的范圍（以像素為單位），比如設置成 9999 后意味著超出屏幕 10000 像素以內(nèi)的內(nèi)容都會被保留下來。
借助 IntrinsicHeight 組件：
另外，IntrinsicHeight 還可以用于 Dialog 或者 BottomSheet 中，使得其中的元素 顯示內(nèi)在元素的高度 ，從而避免元素因為約束的存在而不顯示或者高度太高（比如在使用了 Column 或者 Row 的時候）。
在通過 Uri 的 queryParameters 獲取 query 參數(shù)時，發(fā)現(xiàn)有些鏈接會拋出下面異常：
造成該異常的原因是 Uri 默認使用 utf-8 解碼超鏈接字符串，如果鏈接中包含非 utf-8 字符，就會造成上面的錯誤，相關(guān) issue 見： issue #31621 。目前該 issue 處于 open 的狀態(tài)，暫時的解決辦法是，在所有使用到 queryParameter 的地方用 try..catch 捕捉可能拋出的異常。
Flutter 開發(fā)非常依賴各種官方或第三方的插件，而在使用這些插件時多少都會遇到一些問題，大部分問題都可以通過搜索和查找 issue 來解決。這里記錄下一些我在使用部分插件時遇到的問題及其解決方法。
目前該庫沒有圖片加載完成的回調(diào)（見 issue #545 ），不過我們可以通過在 imageBuilder 中來添加回調(diào)：
這是一個應用內(nèi)更新插件，安卓 10 以上安裝時需要在 manifest 中添加以下內(nèi)容：
目前功能最強大的 WebView 插件，基本能滿足絕大部分移動端網(wǎng)頁加載的需求，而且可定制化程度高。
一般通過 CookieManager 修改 Cookie，攔截請求并修改請求對象的 Header 不會生效。
InAppWebViewOptions 的 userAgent 只在 iOS 上生效，而 applicationNameForUserAgent 只在 Android 上生效，所以最好的做法是分平臺設置 InAppWebViewOptions ，而且需要注意，由于設置 userAgent 后會覆蓋默認的 UserAgent，所以如果需要在默認的 UserAgent 上添加其它參數(shù)，iOS 上需要通過 InAppWebViewController.getDefaultUserAgent() 獲取默認 UserAgent 參數(shù)，而 Android 不需要添加。
如果圖片源或者請求是 http 的，為了在 Android 上正常加載請求，必須在 AndroidInAppWebViewOptions 中將 mixedContentMode 設置為 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。
當我們想要設置全屏圖片的時候，由于默認的 Constraint 會將圖片居中顯示，所以圖片四周會留有空隙。為了去除這個限制，我們需要 Xcode 中打開 LaunchScreen.storyboard，然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。
具體設置方法：右側(cè) Inspector 面板 Show the Size inspector 解選 Layout Margins 中的 Safe Area Relative Margins，拖動圖片占滿全屏，然后根據(jù) View Controller Scene 的 Warning，更新 Constraint 就可以了。
在集成某些三方庫之后，在使用命令行運行 iOS 模擬器的時候可能會遇到下面這個報錯：
這是因為 iOS 模擬器未來將會兼容 arm64 架構(gòu)，但是目前還不支持，所以我們需要修改 Build Setting 使得能夠在 x86_64 的模擬器上運行，操作步驟見 這里 。
重慶分公司
重慶分公司
