前言:前端
運氣不佳沒有被選中到現場參加第二屆 See Conf 螞蟻金服體驗科技大會,全程看的直播,印象最深的分別是上午場樓院長的分享以及下午場悠鶴大佬的分享。react
原先只是簡單整理一下筆記,在記錄過程當中,本身有一些想法冒了出來,因而就成了這篇筆記裏的 「XX注」。webpack
因爲當時在星巴克看的直播,有些內容沒有聽清楚,加上本身理解誤差因此筆記不免有所疏漏或者錯誤,本身也在有疑惑的地方標註出來了,歡迎各位大佬指正web
製做人:XX,愛回收網前端開發,微信:X_XDalston算法
公衆號:清風迅來,攝影/美食/旅行/前端/翻譯/閱讀/健身……redux
XX注:一開始沒仔細聽講者說的內容,還覺得是講者寫的,就想,果真前端都這麼文藝有才的啊…性能優化
XX注:想起了上午場的「情感」要素,或許有時候產品設計師也不會想到產品在海量的用戶羣體下,開放式的交互,結合真實的情感,會本身演化出各類意想不到而又在情理之中的體驗服務器
XX注:依然仍是一個情字:情感、情緒、感情。 微信
XX注:第一次看到這個目錄的時候,沒仔細看,沒什麼感受;如今寫筆記的時候,忽然發現講者還真是挺文藝的,起標題很講究文藝範兒,例如:又回到最初的起點,XXXXX 青澀的臉、……框架
開發時間短,項目工期趕
用戶量大(且低版本安卓仍有很多用戶)
XX注:簡而言之,這是:日益增加的性能優化/開發效能需求與落後的兼容性問題之間的矛盾;無關對錯,關乎取捨;
XX注:這個就不用解釋了吧……
XX注:比如網遊宣傳語,一刀999,秒升99級,還行是吧?但換成:一刀 3.1415,秒升 0.618 級……(黑人問號???)
百分比進度條給用戶以期待感
eg:講者提到了王者榮耀每一個英雄在等級邊上都有升級進度條,給人一種期待感
XX注:順着這個例子,XX以爲這樣有利於玩家隨時瞭解當前升級狀況,有利於一些戰術操做從而給對方一個驚喜,或是判斷當前場上局勢,或者只是單純地告訴玩家,很快就要升級了再加油補幾個兵。
進度條變化給用戶以感知
數字真正表明可收取的數量
XX注:PPT 裏的小蜜蜂是會動的,確實跳着8字。講者描述的內容沒仔細聽,但這張圖片的動效以及旁邊的文字足夠清晰和生動形象了,
講者提到了,最後的實現是經過:兩個三角函數疊加(而後說線上版本好像沒有?什麼新版主題來着?XX沒聽清楚……)
細節,上午場也有提到「細節」。在幫助引導系統中,經過不打擾用戶的狀況下,提供一些小細節給用戶帶來溫暖的感受 ;而講者在以後的演講中也提到了細節兩字,注重細節貫徹了螞蟻莊園的核心價值觀:爲世界帶來美好而微小的改變。在同類產品競爭激烈的狀況下,細節或許是有能力打動用戶的關鍵因素之一。
另外一個方面,既然稱爲細節,就很容易被忽略掉,就好比我書讀的少,也沒仔細觀察過蜜蜂,若是不是講者提到蜜蜂🐝是跳8的,若是看到這個細節,我也不會有所共鳴、不會在心裏有一種「啊哈,這個好贊!」的感受。這樣的代價或許就是,因爲部分用戶的認知能力沒法Get到產品細節,因此某種意義上浪費了部分開發投入成本。
但又換句話說,考慮到人與人之間的交流,或許某個午後,一個發現這個神細節的人會由於這個細節而與另外一個朋友進行分享…… 好了打住不說了,隨緣。
採用「分層設計」:
業務層:
理念:組件化、數據驅動
XX注:忘記講者提到用了什麼框架,但看到有 redux,那應該就是 react 了吧,但圖上一堆 luna 又有點不肯定,估計是內部項目代號…… 組件化和數據驅動,就不解釋了
數據層:
基於 Redux
XX注:核心概念:單一數據源、State 是隻讀的、使用純函數來執行修改
細節:增長了「防抖」、「組合」
XX注:防抖(debounce),通常老是會拿來和「節流」(throttle)一塊兒說,二者相似而不一樣,目的都是優化高頻執行操做的性能,例如監聽屏幕滾動事件處理,看似只是滑動一下,實際每移動1像素都會觸發一次滾動事件。防抖,舉個例子,乘公交車,以司機開公交車爲例,只要必定時間內,有人還在上車,那麼司機就一直等,等到一段時間內沒人上車了再開。例如模糊搜索通常爲了減小服務器壓力,會採用防抖,經過keydown的間隔判斷只要用戶還在輸入,就一直等,等到認爲用戶中止輸入了,再發送請求。
遊戲層:
理念:
工程化
配置化
舉例:雪碧圖,抽取出來可配置
好處:減小開發在實現新功能時考慮的事情,下降了維護成本
效:遊戲渲染調試
遇到問題:不知道邊框在什麼位置?(記不清)
如何解決:(XX忘記了)
淨:調試代碼無侵入
巧:圖片自動合成。
自動化 => 雪碧圖合成工做
嘗試
最初:因爲受 webpack 生命週期限制,不能很好地實現這種功能;
最終:改成 webpack loader
微:打磨動畫細節:(螞蟻莊園理念:爲世界帶來美好而微小的改變)
關於微,若是作得很差,那麼 => 微不足道的問題,等用戶體量大時,都會成爲致命的問題
XX注:所謂防微杜漸,千里之堤毀於蟻穴。或許前陣子的 Ant Design 聖誕節彩蛋可能就是一個很不錯的反面教材…… 就我我的角度而言這個彩蛋是個驚喜,但當用戶體量大了,用戶畫像的數量和規模遠超過彩蛋的可控範圍了,那就沒法稱之爲驚喜了.
極:純手工切圖
XX注:此處又是一種取捨,優雅的第一條就是「效」,而純手工切圖怎麼看都和效率搭不上邊,但正如上午婁院長提到的「高跟鞋隱喻」,所謂工匠精神,就是哪怕效率很低,開發很不爽,很痛苦,但看到最終圖片體積小了,同時圖片質量也很高,讓產品的體驗更好了,也願意去作純手工切圖……
H5圖片體積嚴格;
對大圖片進行拆分;
每個點作到極致;
XX注:mock 數據的事情平時再常見不過了,但能 mock 得如此清麗脫俗氣質不凡而又形象生動意簡言駭,做者必定是個骨骼精奇萬中無一的習武天才
XX注:這裏沒啥特別想說的,只是不知爲啥忽然想到了 LOL 以及王者榮耀很重要的盈利點就是賣皮膚裝扮,尤爲是各類節日限定的皮膚,更坑的是 LOL 有時候還會拿過去限定的皮膚返場,經過10連抽卡的形式來賣,…… (實際上是想到了本身非洲人的黑歷史,惟一歐洲是當年總算抽到了龍年盲僧李青,所謂龍瞎……)
XX注:此處引用一位朋友的原話:穿上這個套裝,我就是最靚的崽兒。
XX注:接着上個話題,上個話題能夠說是表面上看起來很光鮮,各類裝扮,把小雞打扮的賊靚;可是這光鮮背後大概就是程序猿/設計師小哥哥小姐姐們多少個日日夜夜費勁頭髮不斷優化的成果。
需求介紹:
XX注:這類需求太常見了……
只在中秋節3天展現特殊樣式
原先吃餅乾動做改爲吃月餅
團隊狀況
任務時間很少
現有的素材,已經有 1M 大小
解決方案:
1M 大小緣由:全部小雞動畫都是幀動畫。每一個幀動畫有20多幀,加起來有 1M 多
影響:每次進入首頁,有1M多流量消耗,用戶會發現流量忽然用掉好多,會對此質疑
從幀動畫到骨骼X幀動畫
想法:
嘗試:
問題:
倆字兒 => 不會
XX注:這熟悉的北方口音,竟然給我一種好親切的感受……
進展:
從10月底,嘗試使用。發現仍是 dragon bones 實際上仍是用到了幀動畫
後來(此處沒記下來)而後與視覺合做
最終:數據文件+骨骼模型,100多K
另外一個需求:支持動態換裝
- 方案:
- 資源系統
- 優勢:
- 根據服務端版本,實時更新
- 主要優化方案:
- 加載策略:
- 介紹:優先加載 js 文件,而後異步加載主題圖片、裝扮圖片
- 好處:加載 js 能保證主要功能不受素材文件加載異常的影響
- 利用工程化手段:
- 優化圖片數量、體積、尺寸
- 解決圖片雲構建系統依賴問題
複製代碼
優化無止境:爲了小性能,不擇手段,優化內存
問題:圖片資源多,內存佔用大,
before :5200b
XX注:減肥前
- 網上找算法
XX注:減肥中
- max-rects-algorithm
- 問題:
- 大學學的算法都還給老師了
- 解決方案:
- 讓新進來的校招生,來實現該算法(還成功了)
XX注:算法鬼才,XXX淘到寶了
- 大體思路:
- 改變圖片排列
- 優化了圖片體積
複製代碼
XX注:具體說了啥記不清了……就記得下圖有兩個遊戲是用 R3 實現的,圖3爬山賽我還真玩過…… 曾經有一次爲了拿第一,原本差點就到第一了,結果手滑失誤了,當時連刪除當時第一名好友的心都有了,反正又不是微信…… 這裏面刪除好友的成本很低……
XX注:凡是過往,皆爲序章。天道好輪迴,……(?走錯片場了)
線上遇到不少穩定性問題,可能與內存、CPU有關
XX注:安卓機:怪我咯?
螞蟻莊園,雖然是 2D 的,不像 3D 那樣對性能要求那麼嚴格,可是仍須要優化
9月份,開啓新版本的性能測試,
發現問題:用戶閃退
嘗試思路:WebGL 能避免閃退問題
實際業務場景:在一年多時間裏,經歷支付寶版本升級,支付寶內核升級,對安卓手機的支持度更好了
結論:又回到最初的起點: WebGL 青澀的臉
XX注:那些年,咱們填過的坑、改過的 bug、禿掉的頭髮……
XX注:此處記錄的誤差可能較大,僅供參考
提問:提了一個線上的bug,螞蟻莊園排行榜,小雞來偷吃的時候,有提醒,但點擊的時候發現並無(大概是這樣,當時過於震撼第一個問題竟然是提bug,而後就記不清說了啥)
回答:由於用戶體量特別大,因此數據不必定會準,可能存在數據延遲。
提問:建議:揍小雞的功能,加個新道具:中毒卡,做用是吃飼料的速度變慢。
回答:反饋很好,後期會與產品討論。
問題:小雞幀動畫的問題,用什麼引擎or工具解決?cocos2d
回答:這些都差很少。
問題:小雞換裝的時候,每次都要從新切圖,拼裝,不順利。
回答:作了一個系統,把這些工做給視覺去作……
XX注:畢竟大公司,系統說作就作……
XX注:此處沒聽清楚具體的,但大體意思就是上面本身寫的吧
XX注:前端有本身的優點:邏輯思惟與感性的結合,同時不管是2C仍是2B,都是開發中離用戶最接近的一環,最容易體會到用戶的真實需求,就好比最近我參與到一個公司內部的相似 TAPD 的協做平臺,快接近開發完成時,本身就用上了,自測過程當中把此次開發任務添加爲系統中的的一個項目,而且把遇到的bug在裏面提交等等,多是這個項目最先的真實用戶了,包攬了開發、測試、普通用戶角色。
寫這篇筆記的時候已經寫到凌晨三點多了,既然主界面點小雞的時候會有文字提示,或許能夠考慮加入一些對熬夜人士的舒適提示:好比再熬夜髮際線就和我同樣了……
之後等想到了再更新吧,也就2個月前剛從北京回上海時開始玩的 ……
本身從事前端也5年多了,關於 webgl 一樣涉獵較少,但正如講者的經歷,他們團隊在接觸2D動畫、骨骼模型時也都是一臉蒙圈,但如他所言,咋辦?一個字:學。就是這麼簡單。
或許正如次日D2論壇裏圓心提到的,與其餘程序崗位不一樣,前端領域是一個變化很快的領域,充滿挑戰的同時,也是充滿了機遇。
結合我本身經驗,剛作前端的時候,憑着本身學校裏自學的 jQuery 、搭我的博客還有計算機科班出身的基礎和對前端的好感,入行前端,然後發現從 jQuery,jQuery UI 到 Bootstrap,到 template.js X lodash 到 Vue 全家桶再到如今的 React X Typescript X Mbox… 好像就歷來沒停下過學習的腳步……是否是很可怕?
卻想起曾經在書聲上屢次聽到的一句話:「將來十年,咱們所認爲的能力將蕩然無存」。因此解決方案就是:《Lifelong Kindergarten》,面對不肯定性的將來,保持好奇心,培養創造力、終身學習。
用一句老比喻來講,上面提到的內容或許決定了咱們職業發展的下限,講者提到的,工程思惟,工匠精神;可能則是決定了咱們職業發展的上限。
也許上面的比喻並不恰當,不過工程思惟、工匠精神的重要性想必聽了此次的分享不言而喻。說到工匠精神,個人第一反應就是這本書《旅行與讀書》,一個問題:「若是你到了一百歲生日,你要在哪一個餐廳用餐?」以及一句話:「每當你覺得單一美食最高境界過如此,總有新的經驗能讓我再度驚豔」。
而工程思惟,這個我卻是以爲很簡單:只要不斷地被坑、填坑、被坑、填坑、被坑、填坑……就行,固然,只是普通的填坑不行,要優雅地填坑。
寫完這篇筆記,總共大概寫了5個多小時左右… 效率上要增強,否則頭髮都不夠掉了;固然筆記還有不少不足,望指正。
這篇筆記主要是XX本身隨緣記錄了一些想法,其實仍是過於零散,興許往後會對本身有影響的,只是最後的反思部分,亦或者正如文中出現的幾處:引用 See Conf 上半場分享的幾個觀點,之後也許會在某個時刻,靈光乍現般記起這一次悠鶴分享的內容中的某個觀點。
但無論怎麼說,就如同讀書、旅行,未必要領悟出什麼人生哲理,而是在這個過程當中足夠爽就已經很好了;一樣記筆記的這個過程,其實記多了會發現也是頗有趣的,至少XX開始享受這一個過程,或許也已經足夠了。(雖然頭髮掉了不少)
若是以爲這篇文章筆記有幫助,歡迎關注一下文章最開頭的公衆號二維碼~ 今年立了 flag 會多寫幾篇技術文、讀書筆記、項目盤點反思……
哦,還會記錄最近本身與脫髮抗爭的經歷……