掘金 AMA - 聽閒魚客戶端架構師宗心談 Flutter 和他的團隊

一週前的 沸點，掘金團隊請來了閒魚技術團隊 Leader、閒魚客戶端架構師、Flutter 佈道者的做者 @宗心 (於佳) 作了爲期三天的 Ask Me Anything (AMA) 活動。咱們在此精選了一些來自用戶的提問及宗心的回答。

關於宗心：

• 閒魚技術團隊 Leader
• 閒魚客戶端架構師
• Flutter 佈道者
• 掘金我的主頁：juejin.im/user/5b46c7…
• 技術團隊專欄：juejin.im/user/5ac2db…

社區小夥伴提問

如何看待目前大前端這個概念？ ─ @一縷殤流化隱半邊冰霜

想問宗心兩個問題：

1. 如何看待目前大前端這個概念的，大前端之因此爲大，是由於涉及的面比較廣，那前端的邊界在哪裏呢？先後端以 Nginx 爲界麼？那前端在 Nginx 以前的全部事情均可以作麼？在咱們這邊仍是有大前端的概念，咱們大前端甚至也會接觸到後端 mysql 這些。不過我看在阿里集團內部，這個概念好像並無，內部好像是客戶端終端團隊，前端團隊。

2. 我之因此會問前一個問題，實際上是由於在大前端的概念裏，無論是前端的 leader 想帶領好客戶端同窗往前進，仍是客戶端的 leader 想帶領好前端的同窗往前進，都是挺不容易的，雖然二者有結合點，可是在縱深方向二者差別挺大的。阿里內部是如何處理好這種問題的呢？

1.我其實以爲工種的細分，必定仍是有緣由的，因此其實針對大前端的概念，一方面我但願客戶端的同窗能擁有部分前端的知識，擴展本身的邊界，另外一方面，我很敬畏這件事情，曾經我覺得個人團隊特別優秀，一個月就能夠全團隊切換到weex，並且還能保證大項目的落地，但在後續的過程當中隨着對知識體系的深刻了解，我發現，不少事情咱們在短時間內是沒法搞定的，好比咱們不擅長玩法和運營活動相關的事情，並且咱們在weex的代碼規範和工具體系建設上，實話說仍是須要咱們的前端團隊以及咱們本身的weex專家來幫助。因此我以爲尤爲在大公司，要保證某些場景下的專精的狀況下，分工依然在。這也是爲何公司沒說你們都走全棧的緣由。但你們能夠在各自棧的場景下多走一步，多創造一些可能性，好比客戶端會了weex能夠在部分產品上使用該技術，好比店鋪，好比閒魚號，另外客戶端同窗能不能學點AI相關的東西呢，在端側把tf-lite的工程體系用起來。總之，我但願的大前端概念上，應該有必定的跨棧能力，但不用作到都很是專精，依然仍是在本身的領域有本身的專長。

2.對於leader來說，在不停承擔責任的同時，這個問題必定都會出現，試想我以前只作iOS帶iOS團隊，後來帶android，我android勉強還能夠吧，再作flutter要學flutter，再若是讓我帶服務端呢？我仍是要會，但做爲TL，我需不須要都是團隊第一，我以爲不是，不然你帶的團隊必定很菜，全部人都不如你，那你就是團隊的天花板，因此TL在技術上我來看，要有本身的專業度和方法論。再有就是業務TL必定要有廣度，個人老闆服務端出身，作客戶端他確定作不過我，但他的廣度上面，他看業務的角度以及破局的能力，老實說高我好幾個段位，那這就是他給予團隊的獨特性，因此我以爲若是從此我要作一個好的TL，我也須要補充這些內容，而深度的話，我以爲會能找到更多比我更專業的同窗，一塊兒作的更好。TL最重要的做用，是他有沒有給公司帶來一支有想象力的團隊，這個應該就是阿里對TL的要求，聚人成事，借事修人

在面大廠的時候，簡歷、面試該關注哪些點？或者說，你招人的時候看中候選人的什麼特性呢？ ─ @永遠的根號三

你好，我本科讀的機械專業轉的安卓開發，如今在一個不到 20 人的初創小公司，請問像我這種非科班出身的程序員，在面大廠的時候，簡歷、面試該關注哪些點呢？或者換句話，大家找人的時候看中候選人的什麼特性呢？學歷我也是 985 的只是非計算機專業出身

你好，我相信這個也是不少同窗關心的問題，校招的同窗若是有問題我單獨再講，社招的同窗，除了經驗和技能上的要求之外，我想突出說兩點，一個是但願在作事情的時候有本身的思考和總結，好比你作的項目，好在哪裏，有什麼問題，後續要怎麼解決，度量標準是什麼，這個很重要，咱們但願這個同窗是不斷思考持續進步的，送你們一句話，if you cannot measure it，how to improve it。第二點，好奇心，除了你本職工做之外，想不想了解你上下游的同窗在作什麼，這個業務總體架構是什麼，大家公司在端側核心競爭力的那些代碼是怎麼實現的，爲何這麼作，業內流行趨勢是什麼，有沒有嘗試過，怎麼看這些技術的將來。我在面試每位同窗的時候，打內心但願你們都能過，由於咱們真的很是缺人，但可能不少同窗在工做之後，沒有以上兩點意識，形成後續的積累就會比較慢，這裏講給你，也但願能幫助更多同窗成就更好的本身，找到好工做。

基於什麼樣的考慮選擇在閒魚客戶端中使用 Flutter ？─ @liutao

你好，新技術剛發佈的時候，一般都有不少未知的坑要去填，風險比較大，因此不少技術團隊都不會第一時間去選擇新技術來開發業務，請問你和團隊當時是基於什麼考慮選擇在閒魚客戶端中使用 Flutter ？

講一下心路歷程，確切的說咱們是在去年flutter還在alpha版本的時候就已經跟進了，開始的時候更多的是作預研部分的事情，好比作了一個內部國際版的閒魚，徹底基於flutter的，整個工具鏈和flutter的內部原理咱們都趟過一遍，在我看來flutter的設計思想比較先進，在ui的兼容性以及性能上，較其餘的跨平臺框架是有較大優點的，加上咱們跟google的flutter團隊創建了長期的完善的交流機制，爲後續的落地打下了比較堅實的基礎，另外，我在flutter上看到了將來跨終端上友好的擴展性，據我所知google團隊已經完成了flutter在mac上的demo，後續是否能夠在其餘桌面操做系統和iot設備上應用，讓咱們拭目以待。咱們在一年的調研沉澱之後，基於上述的緣由，選擇了flutter在閒魚業務線的嘗試和落地，目前看起來，會有少部分兼容性問題，但總體來看，距離大面積商業應用已經比較近了。

請閒魚使用 Flutter 開發時，移動客戶端的分工是怎樣的 ？─ @NeXT

請閒魚使用 Flutter 開發時，移動客戶端的分工是怎樣的？會有專人進行 Flutter 的開發仍是 Android 和 iOS 都要參與到 Flutter 的開發和學習中？會考慮更大範圍使用 Flutter 嗎？

很好的問題，閒魚在使用過程當中，採起了混合工程的場景，因此確實是有專人寫flutter，部分同窗仍然開發native的代碼的，因此這個過程當中，若是但願平滑的作技術棧的切換，咱們在工程改造上作了很大的努力，研發模式上，咱們針對native和flutter的同窗有兩種開發模式，比較好切換，對native同窗來講，是感知不知道flutter存在的，固然，將來咱們但願在業務代碼測逐漸切換成flutter。

爲什麼阿里一直在基於其餘技術作改造 ？─ 令狐洋蔥

爲什麼阿里產出不了相似react, webpack, babel, flutter等框架/工具，一直在基於其餘技術作改造 ？

我跟google團隊接觸的過程當中，確實能看到，跟世界最頂端的公司相比，咱們的技術水平上確實仍是有必定的差距，我以爲沒什麼，正視差距跟優秀的團隊看齊，繼續努力學習他們的優點，把他們的優點帶回來，另外，公司在工程化和技術的商業化上，我以爲作的挺好，只要能產生商業價值，基於這些現有的架構體系改造是最快的。

淘寶爲啥不把首頁改成flutter ？─ @快樂有家

問個無關的問題。不少人都已經把淘寶做爲新時代的跑分軟件了，卡的死人的淘寶爲啥不把首頁改成flutter ？

淘寶首頁其實使用了另外一種模版引擎的技術叫dynamic，是個人其餘同事作的，相比weex來說，主要負責模版的渲染，會更輕量一些，若是考慮首頁的方案，建議也能夠去看下天貓的同窗的Tangram的方案，是比較完善的。我看來現階段flutter的初次加載，其實也比較慢一些，可能還達不到首頁的加載效果，咱們正在考慮優化這個加載過程。

怎麼在flutter裏處理h5連接跳轉，flutter和native間的數據傳遞和狀態保存怎麼管理 ？─ @不萬能的喜劇6

通常用flutter結合native去寫的時候，怎麼在flutter裏面處理h5連接跳轉，flutter和native之間的數據傳遞和狀態保存又是怎麼管理的呢？

1.第一個問題，我這邊的場景會有一個統一的openurl方法，在native側，native調用你們應該都很清楚，flutter的調用的話，寫一個plugin，調用dart的openurl方法經過channel機制轉到native的openurl統一處理便可，剩下的無論是什麼連接，都跟native的處理方式是同樣的。

2.第二個問題的數據傳遞和狀態保存是個難點，由於flultter對native的數據傳遞都是copy生成一份的，因此native和flutter的狀態就是兩份，不一樣步的，目前若是有變動咱們主要仍是採起通知的方式，但處理起來仍是有點不優雅，有更好的方案能夠跟咱們交流哈，我本身的但願是，可能後續都存在一邊會比較好，無論是flutter仍是native，理論上來說多是flutter，由於後續但願把剩餘的native代碼遷走。

通常19屆的進去，須要什麼樣的條件呢 ？─ @山鬼

19屆的同窗看你投遞的崗位哈，我目前也在負責閒魚的校招，對大部分同窗來講，建議投遞工程相關的崗位，好比java研發，客戶端開發等，要求通常是三點：1.基礎，要求重點學科優秀，對數據結構/算法/操做系統原理/計算機網絡等掌握紮實，或在某個領域有特別的特長 2.熱情，瞭解目前普遍應用的技術，有本身的學習技術的路徑，對某一領域有本身的強烈好奇心，並願意額外投入不少精力，並最終能取得好的結果3.成果，這個主要指專一於某一個領域，深刻了解了技術在實際場景的應用，能夠經過本身專一的領域去解決實際問題，或者有重要學術論文和專利。

知足兩條的同窗是最低要求，知足三條的同窗通常比較合適。但願能幫到你。

如何管理一個技術團隊？在團隊管理上你踩過那些坑 ？─ @一百一

宗心大佬我想問下，大家技術團隊如今有多少人？如何管理一個技術團隊？在團隊管理上你踩過那些坑？

咱們大技術團隊大概70多人吧，還屬於一個比較小的團隊，固然咱們但願能在今年招到更多優秀的同窗作同事，個人目前團隊大概不到20名同窗，都是我招進來的。

我以爲技術團隊的管理相對簡單一些，比較重要的實際上是要關注你們的成長，本身須要在大的框架目標肯定後，在過程當中放權和訓練團隊的思考能力，讓團隊同窗在重要的事情上面造成本身的判斷和決定，引導他們思考，而不是直接給他們結論，其實總結起來也很簡單，就是一切都是以團隊同窗的成長爲出發點思考，並不斷溝通和對焦，懷着對你們負責的心，應該就能作好。

踩坑上面，我以爲我犯得比較大的錯誤是我剛帶團隊那會兒，本身是p7，團隊大部分同窗是p5和p6，招進來新同窗的時候，發現不少事情他們作不了，因此本身主動就把大的架構升級改造的遷移所有本身作了，也承擔了不少業務，但最後的結果就是，新的同窗其實在試用期並無承擔很大的壓力，也沒有得到快速的成長，後續的過程當中，表現的就比較很差，這個結果我一直都以爲對兩位同窗有所內疚，我以爲若是當時對他們要求高一些，而不是當老母雞同樣護着他們，他們也許會有更好的發展，老母雞是帶不出雄鷹的，因此本身後續有了改變，知道TL更可能是作引導和訓練，而不是直接給結論，並且你要容許下屬在必定時間段內產能不如你，學會放手，下屬的成長就是要主管給予指導和放權。

我去年本身也會看一些課程，推薦獲得上的寧向東老師的清華管理學課，很是贊。不但對一線TL管用，對公司的中高層一樣管用，後面課程裏的戰略地圖等都是頗有效的方法。

閒魚招 iOS 嗎？具體的崗位要求是怎麼樣的呢 ？─ @周熵

大佬好，我最近在找 iOS 的工做，方便的話能夠分享下你以前面試的時候提的面試題嗎？以及閒魚招 iOS 嗎？具體的崗位要求是怎麼樣的呢？

我本身在阿里內部整理過比較多iOS的面試題，但後續隨着時間推移，一個是知識已經比較過期了，另外一個本身在招聘上對人的思考也有提高，可能我以爲面試題自己不太適合找到合適的人，因此更可能是從人自己的特質上去看一我的是什麼樣子的。

咱們有閒魚的崗位JD，裏面描述了一些知識層面的基本要求，崗位要求

我這裏補一些閒魚或者說阿里在這上面的軟性的要求

我能夠說下閒魚但願iOS開發是什麼樣子的 1.基礎好，基本上iOS的一些基礎的知識體系要知道，但可能我不會直接就問你題目，我但願你能在本身作的項目或者實踐中有體現，好比我問內存管理相關的知識，若是你只知道它的原理，但根本沒用到過，我以爲基本上也是屬於死記硬背型的，沒有項目或者技術方案落地的基礎知識，我以爲可能只能對工做2年內的同窗是work的，再工做久一些的我以爲就不行了。 2.有好奇心的，關注最近產出的新技術，無論是wwdc也好，仍是github上的重點項目，並關注它的一些原理性的東西，這是很好的習慣，但我但願能夠再進一步，將你關注的這些內容落地，好比我以爲如今大部分的iOS開發應該都瞭解一些RN和weex的知識，那原理是什麼，有沒有作過擴展，有沒有踩過什麼坑，能答上來有一些不同的思考我就以爲很棒。3.精益求精，這點特別體如今性能和穩定性上，這裏既能夠考知識體系的基礎，也能夠考知識體系的系統性，專業性。好比每一個人看待性能優化都是不同的，你的總體解決方案是什麼，哪一部分是你優化的重點，效果如何度量，你的方法能不能沉澱做爲基礎設施，都是很重要的。這裏其實能看出P6/P7/P8在上面的區別。

因此我但願能找到的同窗是--基礎好/好奇心驅動/有匠心/理論結合實際有結果 這樣的一我的。

請問，閒魚App中有哪些地方使用RN，你怎樣看待最近Airbnb和Udacity都相繼放棄了RN ？─ @zyf在掘金

閒魚app裏沒有使用RN，但有很多頁面使用Weex，在我看來，無論是Weex仍是RN，咱們去當作本1.前端體系的學習成本 2.debug和兼容性的成本 3.基礎設施建設的成本 這三個成本是逃不過的，因此若是以爲這三個成本大於你的收益，建議不要用。而對於閒魚來講 1.我團隊有專門的weex專家帶一些有前端知識體系的同窗 2.基礎設施有阿里巴巴集團的基礎設施作基礎，本身須要再建設的很少。 這兩個其實已經決定了咱們在使用過程當中成本沒有那麼高，目前最高的可能就是debug成本和兼容性問題了，暫時是能夠接受的。再說收益1.咱們有一套從sketch到代碼的生成工具，因此UI還原部分，咱們基於此少寫了不少代碼2.三端一致性，在部分業務上確實帶來了好處，尤爲閒魚要在外部多端進行投放，無論是手淘仍是外部投放，我就寫一份代碼，相比來講成本確定要低一些，因此這個要看場景3.做爲前端使用，性能上比h5仍是會好不少，前端使用過程當中也有一些收益。 均衡來看，咱們仍是在對應的場景下會持續使用下去。

這裏延伸一下flutter，成本可能會是1.flutter的學習成本2.debug體系和工程體系的成本3.基礎設施的成本 這裏沒提到兼容性，由於從UI還原的角度上來，flutter的兼容性確定仍是好於weex，至少兩端的一致性是比較強的。咱們看怎麼解這個問題1.學習成本上dart比較接近java很是好學，基本上看一遍就會了，工具體系也像java，團隊有成熟的android同窗徹底能夠cover 2.debug體系和工程體系成本，確實是一個成本，目前在逐步解決，但怎麼說，IDE開發flutter的時候，仍是相對更接近客戶端的開發體驗3.基礎設施的成本，確實也有，因此咱們如今考慮，怎麼後續經過創建一套基礎設施能支持flutter/weex/h5/native等多個體系，也就是說，經過架構統一底層能力，而不用重複建設。咱們再看收益1.一樣咱們有sketchToFlutter的工具，部分代碼也能夠不用寫了，雖然還有一些bug，後續會持續作優化2.雙端一致性，效率翻倍，這個過程前期只要兼容性問題咱們作好，後期應該不太會有兼容性問題 3.高性能，整個flutter的性能是很是好的，native的性能表現

這麼看來，對native側的需求來講，flutter是另外一個比較好的選擇。

---

本期 AMA 社區小夥伴提了許多實用問題，一樣感謝宗心認真地爲掘金小夥伴解答了很多疑問。瀏覽更多的問答，能夠到宗心的 AMA 進行閱讀和討論。

---

下期預告

下期 AMA 嘉賓爲騰訊 NOW 直播技術團隊的 Rand，你們記得準備好問題喲~ 下期 AMA 結束，嘉賓將會指定一名他以爲提出好問題的小夥伴贈送一本書籍 《碼農翻身》，一樣的，官方會根據誰的提問得到最多點贊贈送他一本《碼農翻身》喲~ 下期 AMA：2018.07.25 - 2018.07.27 見