01 vue是觀察者模式還是發布訂閱模式(自學前端學到什么程度可以找工作)

小白準備轉行學習前端，有大神可以提一些建議嗎

學習是以興趣為前提的，你要對你所要學的內容產生興趣，這樣你才會花心思去學習。這和是不是小白沒關系的，對于小白而言，在學習過程中就需要更努力，多花時間和心思沒有什么是學不會的。

自學方法：

1、作為一個初學者，你必須明確系統的學習方案，我建議一定有一個指導的人，全靠自己學，放棄的幾率非常大，在你對于web前端還沒有任何概念的時候，需要一個人領進門，之后就都靠自己鉆研，第一步就是確定web前端都需要哪些內容，并且在多少時間內學完，建議時間6個月保底。

2、視頻為主，書為輔。很多初學者在學習前端的時候非常喜歡去買書，但是最后的結果是什么？看來看去什么都不會寫，所以在這里給大家提醒，書可以看，但是是在建立于你已經對于某個知識點有了具體操作的執行后，在用書去鞏固概念，這樣更加利于你對于知識的理解。

3、對于學習技術來講，掌握一個學習方法是非常重要的，其實對于學習web前端來講，學習方法確實很多都是相通的，一旦學習方法不對，可能就會造成“方法不對，努力白費”。其實關于這方面還是很多的，我就簡單說個例子，有的人邊聽課邊跟著敲代碼，這樣就不對，聽課的時候就專心聽，做題的時候就專心做題，這都是過來人的經驗，一定要聽。根據每個人的不同，可能學習方法也會有所出路，找到適合你自己的學習法方法是學習的前提。

4、不建議自己一個人瞎學，在我了解學習編程的這些人來看，從零基礎開始學并且最后成功做這份工作的其實并沒有幾個，我覺得大部分原因就是因為他們都不了解web前端是干什么的，學什么的，就盲目的買書看，到處找視頻看，最后看著看著就放棄了，所以我建議初學者在沒有具體概念之前，還是找有經驗的人請教一下，聊過之后你就會知道web前端具體是干什么的，該怎么學，這是我個人的小建議，可以不采納。

自學路線：

第1階段：前端頁面重構(4周)

內容包含了：(PC端網站布局項目、HTML5+CSS3基礎項目、WebApp頁面布局項目)

第2階段：JavaScript高級程序設計(5周)

內容包含：(原生JavaScript交互功能開發項目、面向對象進階與ES5/ES6應用項目、JavaScript工具庫自主研發項目)

第3階段：PC端全棧項目開發(3周)

內容包含：(jQuery經典交互特效開發、HTTP協議、Ajax進階與PHP/JAVA開發項目、前端工程化與模塊化應用項目、PC端網站開發項目、PC端管理信息系統前端開發項目)

第4階段：移動端項目開發(6周)

內容包含：(Touch端項目、買粉絲場景項目、應用Angular+Ionic開發WebApp項目、應用Vue.js開發WebApp項目、應用React.js開發WebApp項目)

第5階段：混合(Hybrid,ReactNative)開發(1周)

內容包含：(買粉絲小程序開發、ReactNative、各類混合應用開發)

第6階段：NodeJS全棧開發(1周)

內容包括：(WebApp后端系統開發、一、NodeJS基礎與NodeJS核心模塊二、Express三、noSQL數據庫)

視頻教程：

網頁鏈接

網頁鏈接

如果你對于學習前端有任何不懂的可以隨時來問我，如果沒有比較好的教程，也可以問我要。

做混合的話Uniapp和Flutter我應該學哪個啊？

‍

本文由阿里閑魚技術團隊祈晴分享，本次有修訂和改動，感謝作者的技術分享。

1、內容概述

本文總結了阿里閑魚技術團隊使用Flutter在對閑魚IM進行移動端跨端改造過程中的技術實踐等，文中對比了傳統Native與現在大熱的Flutter跨端方案在一些主要技術實現上的差異，以及針對Flutter技術特點的具體技術實現，值得同樣準備使用Flutter開發IM的技術同行們借鑒和參考。

學習交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：買粉絲s://github.買粉絲/JackJiang2011/MobileIMSDK

（本文同步發布于：買粉絲://買粉絲.52im.買粉絲/thread-3615-1-1.買粉絲）

2、閑魚IM現狀

閑魚IM的移動端框架構建于2016至2017年間，期間經過多次迭代升級導致歷史包袱累積多，后面又經歷IM界面的Flutter化，從而造成了客戶端架構愈加復雜。

從開發層面總結閑魚IM移動端當前架構主要存在如下幾個問題：

1）研發效率較低：當前架構涉及到Android/iOS雙端的邏輯代碼以及Flutter的UI代碼，定位問題往往只能從Flutter UI表相倒查到Native邏輯層；2）架構層次較差：架構設計上分層不清晰，業務邏輯夾雜在核心的邏輯層致使代碼變更風險大；3）性能測試略差：核心數據源存儲Native內存，需經Flutter Plugin將數據源序列化上拋Flutter側，在大批量數據源情況下性能表現較差。

從產品層面總結閑魚IM移動端當前架構的主要問題如下：

1）定位問題困難：線上輿情反饋千奇百怪，測試始終無法復現相關場景，因此很多時候只能靠現象猜測本質；2）疑難雜癥較多：架構的不穩定性造成出現的問題反復出現，當前疑難雜癥主要包括未讀紅點計數、iPhone5C低端機以及多媒體發送等多個問題；3）問題差異性大：Android和iOS兩端邏輯代碼差異大，包括埋點邏輯都不盡相同，排查問題根源時雙端都會有不同根因，解決方案也不相同。3、業界的移動端跨端方案

為解決當前IM的技術痛點，閑魚今年特起關于IM架構升級項目，重在解決客戶端中Andriod和iOS雙端一致性的痛點，初步設想方案就是實現跨端統一的Android/iOS邏輯架構。

在當前行業內跨端方案可初步歸類如下圖架構：

在GUI層面的跨端方案有Weex、ReactNative、H5、Uni-APP等，其內存模型大多需要通過橋接到Native模式存儲。

在邏輯層面的跨端方案大致有C/C++等與虛擬機無關語言實現跨端，當然匯編語言也可行。

此外有兩個獨立于上述體系之外的架構就是Flutter和KMM（谷歌基于Kotlin實現類似Flutter架構），其中Flutter運行特定DartVM，將內存數據掛載其自身的isolate中。

考慮閑魚是Flutter的前沿探索者，方案上優先使用Flutter。然而Flutter的isolate更像一個進程的概念（底層實現非使用進程模式），相比Android，同一進程場景中，Android的Dalvik虛擬機多個線程運行共享一個內存Heap，而DartVM的Isolate運行隔離各自的Heap，因而isolate之間通訊方式比較繁瑣（需經過序列化反序列化過程）。

整個模型如下圖所示：

若按官方混合架構實現Flutter應用，開啟多個FlutterAcitivty/FlutterController，底層會生成多個Engine，對應會存在多個isolate，而isolate通訊類似于進程通訊（類似socket或AIDL），這里借鑒閑魚FlutterBoost的設計理念，FlutterIM架構將多個頁面的Engine共享，則內存模型就天然支持共享讀取。

原理圖如下：

4、閑魚IM基于Flutter的架構設計

4.1 新老架構對比

如下圖所示：是一個老架構方案，其核心問題主要集中于Native邏輯抽象差，其中邏輯層面還設計到多線程并發使得問題倍增，Android/iOS/Flutter交互繁雜，開發維護成本高，核心層耦合較為嚴重，無插拔式概念.

考慮到歷史架構的問題，演進如下新架構設計：

如上圖所示，架構從上至下依次為：

1）業務層；2）分發層；3）邏輯層；4）數據源層。

數據源層來源于推送或網絡請求，其封裝于Native層，通過Flutter插件將消息協議數據上拋到Flutter側的核心邏輯層，處理完成后變成Flutter DB的Enitity實體，實體中掛載一些消息協議實體。

核心邏輯層將繁雜數據扁平化打包掛載到分發層中的會話內存模型數據或消息內存模型數據，最后通過觀察者模式的訂閱分發到業務邏輯中。

Flutter IM重點集中改造邏輯層和分發層，將IM核心邏輯和業務層面數據模型進行封裝隔離，核心邏輯層和數據庫交互后將數據封裝到分發層的moleData中，通過訂閱方式分發到業務層數據模型中。

此外在IM模型中DB也是重點依賴的，個人對DB數據庫管理進行全面封裝解，實現一種輕量級，性能佳的Flutter DB管理框架。

4.2 DB存儲模型

Flutter IM架構的DB存儲依賴數據庫插件，目前主流插件是Sqflite。

其存儲模型如下：

依據上圖Sqflite插件的DB存儲模型會有2個等待隊列：

一個是Flutter層同步執行隊列；一個是Native層的線程執行隊列。

其Android實現機制是HandlerThread，因此Query/Save讀寫在會同一線程隊列中，導致響應速度慢，容易造成DB SQL堆積，此外缺失緩存模型。

于是個人定制如下改進方案：

Flutter側通過表的主鍵設計查詢時候會優先從Entity Cache層去獲取，若緩存不存在，則通過Sqflite插件查詢。

同時改造Sqflite插件成支持sync/Async同步異步兩種方式操作，對應到Native側也會有同步線程隊列和異步線程隊列，保證數據吞吐率。但是這里建議查詢使用異步，存儲使用同步更穩妥，主要怕出現多個相同的數據元model同一時間進入異步線程池中，存儲先后順序無法有效的保證。

4.3 ORM數據庫方案

IM架構重度依賴DB數據庫，而當前業界還沒有一個完備的數據庫ORM管理方案，參考了Android的OrmLite/GreenDao，個人自行設計一套Flutter ORM數據庫管理方案。

其核心思想如下：

由于Flutter不支持反射，因此無法直接像Android的開源數據庫方式操作，但可通過APT方式，將Entity和Orm Entity綁定于一身，操作OrmEntity即操作Entity，整個代碼風格設計也和OrmLite極其相似。

參考代碼如下：

4.4 IM內存數據模型

基于Flutter的IM移動端架構在內存數據模型主要劃分為會話和消息兩個顆粒度：

1）會話內存數據模型交托于SessionMoleData：會話內存數據有一個根節點RootNotice，然后其掛載PSessionMessageNotice（這里PSessionMessageNotice是ORM映射的會話DB表模型）子節點集合。2）消息內存數據模型交托于MessageMoleData：消息內存數據會有一個MessageConatine

很赞哦!（92433）