閒魚技術
閒魚在 2017 年便引入了 Flutter，是國內第一個引進Flutter的團隊。
當時的 Flutter 還遠未成熟，行業內也沒有把 Flutter 放入已有工程體系進行開發的先例。
這兩年，Flutter 也逐漸在其他企業裡落地，但同時也不斷有質疑的聲音發出。甚至有傳言表示“閒魚的新業務已經放棄 Flutter”、“相信閒魚遇到了很大的難題”......
那麼，作為 Flutter 先驅和探路者，閒魚在過去幾年的摸索過程中遇到過什麼阻力？踩過什麼“坑”？對於相關技術開源的態度是怎樣的？對於以上的一些傳言又是怎麼看待的呢？
針對這些疑問，閒魚代表團隊分享了一些開發者背後不為人知的小故事。希望能讓大家從背後人的維度去看閒魚團隊，理解他們的初心，以及這個過程中遇到的挑戰、掙扎、付出的努力、得到的教訓。
1. 在新技術落地過程中，遇到過什麼阻力，有什麼避免“踩坑”的經驗？
閒魚從2017 年開始接觸Flutter，最初是一個自上而下的嘗試。
一方面，從創新團隊的角度來看，需要以戰養戰，為團隊儲備更多的人才；另一方面，希望切實解決當時團隊人難招、產能低的問題。
在前期的調研過程中，最初是希望將Flutter 作為閒魚國際化版本的主要技術選型；由於後續業務上的決策，導致該項目夭折，因此希望將Flutter 引入主App 中進行探索。
在嘗試之初，從組織、配套工具，到架構側都沒有準備得特別好，項目落地面臨很多困難。在團隊抽調的突擊小組中，有大量的研發人員非常不看好這項技術，大部分研發人員並不認同Flutter，沒人知道這件事情該怎麼做。
當然，從2017 年開始，閒魚在多個技術方向都進行了類似的嘗試，實踐證明，創新的確比想象難得多。
時間來到2020 年，回首過去嘗試的多個方向，目前只有Flutter 得到了階段性的勝利，並作為閒魚的技術品牌為大家廣泛熟知。這裡面所經歷的艱難險阻只有當時參與過從0 到1 過程的研發人員才能體會。
由於Flutter 落地過程的艱辛，其間也有不少同事離開了閒魚，幸好後續有更多希望這件事情成功的研發人員加入，大家一起努力至今，才有了今天看到的成果。我們也非常感謝在此過程中付出過努力的每一位同事，不管今天他們是否還在閒魚，是每一位同事的努力讓美好終於發生。
從Flutter 落地的過程中總結出以下觀點，供大家參考。
從佈道者的角度來看，需解決以下兩方面的問題：向上，需要得到更多決策者的支持；向下，需要減少開發者進入的成本。
關於決策者鏈路，Flutter 在閒魚落地的過程中沒有上層的阻力，因為開始是一個自上而下的決策，但在後續的推廣和落地過程中，從更大的組織視角去看，比如構建AliFlutter 組織、構建Flutter China 組織，這些是一個自下而上的行為。
在這個過程中，閒魚選擇的是“農村包圍城市”的理念。先從社區出發，發現同路人，找到不同公司、不同業務的價值，再回歸內部，影響決策者。前期不管是構建集團Flutter 的興趣小組，還是正式有了AliFlutter 的虛擬組織，都是找到同路人，探討和爭論其技術價值的過程，這個過程可以請各團隊的關鍵決策者躬身入局。通過討論又能幫助團隊進行更深入的思考，併為Flutter 提供一個階段性的明確定位——面向研發效能提升，構建新的研發模式，快速支持小前臺業務落地。將該目標與阿里巴巴集團大的研發效能目標進行連接和推動，即可順利地推進該項目。
關於開發者成本，首先是自己團隊的開發者成本。在任何新技術落地的前期，都有一定的成本，需要度過這個階段才能得到收益。因此，在開始階段，必須儘量降低落地成本。
在項目之初，最好以小規模團隊的形式進行嘗試，同時新技術在前期架構落地中需要重點考慮過渡階段的效率問題，不要斷崖式地遷移。閒魚在初期沒有充分考慮這個問題，導致工程側開始的架構並不合理。後來，閒魚重點圍繞混合架構，以Flutter 開發小組與原生開發小組的協作模式進行設計和落地後，該問題得到了有效解決。
例如，前期閒魚就重點解決了原生項目無法獨立打包的問題，極大地解決了當時研發效率的阻塞問題。混合棧（Flutter Boost）的重新設計，也解決了當時由於Flutter和原生生命週期不一致帶來的一系列複雜問題，保證了開發調試的穩定性。如果團隊仍有餘力，可以考慮對開源社區進行一些力所能及的輸出。閒魚先通過發佈文章，再通過部分開源項目以及內部開源的形式，給Flutter 社區和阿里巴巴集團提供了一些幫助。閒魚相信“日拱一卒，功不唐捐”，雖然依然還有很多問題需要解決，但是隨著更多開發者的進入，大量的問題終究會被解決。
2. 閒魚對開源項目的態度是什麼？未來會把大量文章中提到的技術開源出來嗎？
閒魚在2018 年完成Flutter 主鏈路的部分改造後，發現在落地過程中有很多問題，而且Flutter 社區並沒有給出很好的解決方案。
從幫助Flutter 社區其他開發者的角度出發，閒魚內部開始討論開源事宜，這是閒魚第一次嘗試開源，所有人都沒有經驗。大家開開心心地希望能將自己做的一些事情同社區進行交流。
當然，作為第一次開源，很多事情做得也非常糟糕，糟糕的文檔、糟糕的Demo、沒有測試用例、問題維護不及時、沒有好的社區共建方式，於是引發了社區開發者的大量抱怨。
從自己真實的感受來說，要維護好社區項目，需要付出大量的精力和時間，這些甚至需要不少同事全職去做，這對一個業務團隊來說有些勉為其難。
對開源的反思是要敬畏開源，敬畏社區，在反饋中不斷地成長，完善自身項目。例如，Flutter Boost 前期的設計在兼容性上侵入性太強，導致後續的升級成本較高。在未來的3.0 版本中，閒魚會主動解決這一問題，減少關鍵的幾個類的繼承和重寫，簡化概念，降低接入成本。
目前，這個階段會重點關注已經開源的項目，尤其是Flutter Boost 這種在阿里巴巴集團內外都屬於開發者剛需的項目，需要持續地維護，也非常歡迎更多的社區開發者參與進來。
關於文章中提到的其他Flutter 相關技術，閒魚會盡量考慮使用Demo 等形式將部分原理輸出，幫助開發者更好地理解文章及其背後的思想。
一方面保證了閒魚對Flutter 社區的啟發和幫助，一方面也緩解了閒魚目前面臨的無法保證全職人員從事開源工作的問題。但不論如何，閒魚希望通過文章及代碼，持續地幫助Flutter 社區，盡我們的一份綿薄之力。
也許我們做得並不完美，甚至不夠優秀，但隨著閒魚有更多優秀研發人員的加入，在創新和分享文化方面進行不斷的自我革新，相信總有一天能伴隨這項技術成為真正的國民級別應用的貢獻者。
3. 聽說閒魚放棄了Flutter，作為當事人，閒魚的態度是什麼？
在各類社交平臺匿名區和公眾號中，都有人階段性地、煞有介事地散播閒魚放棄了Flutter 以及未來不會再投入的消息，作為當事人，我先說結論——這些都是謠言！
《Flutter企業級開發應用實戰：閒魚技術演進與創新》一書的出版是對這些謠言最有力的反駁，也感謝出版社幫我們闢謠。
移動互聯網發展的十年， 對於跨平臺技術來說， 從最早的PhoneGap 到ReactNative、Weex，再到目前的Flutter，形形色色的技術不斷迭代和演進。
從當前階段來看，Flutter 具備跨平臺技術的先驅——QT 的大部分優勢，且配套了更現代的語言、更合理的分層架構，並有Google 公司支持，是新一代跨平臺技術的集大成者。
在下一個十年，面向萬物互聯的新操作系統，如華為鴻蒙及Google Fuchsia 的出現，使得跨平臺技術的價值進一步凸顯。
因此，學習這項開源技術對未來的開發者來說是一個不錯的選擇。我們無法預測Flutter 是否一定為下一個十年的主流技術，但這套代碼和其背後的思想一定能給未來的開發者以啟發，就像我們的前輩用QT 開發了KDE，KDE 又提供了一個排版引擎KHTML，而蘋果公司Fork 了這個項目，從而產生了WebKit，而Google 又Fork 了WebKit，從而產生了Blink。
這些令人尊敬的公司和開發者站在巨人的肩膀上不斷地努力，最終打造了令人耳熟能詳的技術，從而改變世界。
今天，Flutter 代碼中有很多概念也存在瀏覽器內核的一些影子。作為客戶端的從業者，希望開發者都能客觀地評價這些技術，根據實際情況進行學習並將其落地。
對於外界傳出的類似閒魚放棄Flutter 的謠言，大部分時間我們選擇付之一笑。
作為管理者，我不太希望團隊過於關注外部的評價和過度迴應不實傳聞，希望閒魚的開發者可以做正確的事情，並保持長期的耐心。
未來的三年，閒魚更希望探索先進的研發模式，幫助整個阿里巴巴集團在商業競爭中保持技術的先進性和成本優勢。當然，我們希望這種研發模式是基於我們現有的技術沉澱基礎之上的，因此會依然持續地投入Flutter 之中。
同時，作為一個創新團隊，閒魚也一定會持續地關注行業的最新動態，未來也一定會像在Flutter 領域一樣，在其他領域有所建樹。
