記錄一位社招面試騰訊成功拿到offer的面試內容及收集的答案(上)

//   以下記錄 是爲了 以後如果有機會面試大廠 起碼瞭解一些 作爲合格前端應該掌握的知識點  勉勵自己

//   對了 還有平時 對用到的專有名詞及縮寫 請查清全稱及讀音 否則面試的時候 真的畫面太有喜感了  不敢想了

//  記錄一位社招面試騰訊成功拿到offer的面試內容及收集的答案(下)  https://blog.csdn.net/gaoqiang1112/article/details/103366051

騰訊社招    答案爲本文蒐集答案 非標準或正確答案，務必自己分辨清楚

一面

1. 性能優化

2. http緩存

3. 做過的有特點的項目

4. 遇到的問題與解決方案

5. toB和toC的區別

6. 現場面對客戶的經歷

7. 前端安全相關(着重中間人劫持)

8. 爲什麼跳槽

9. 職業規劃

10. 有什麼問我的(團隊簡介、前端參與項目的過程)

收集答案：

   1.這個問題描述有些泛泛，所以我只能結合自己認識及搜到的內容進行

  A 頁面級別優化

   http請求數 ：減少http請求數是最重要也是最有效的方法，可以通過以下方法來減少http請求

（1）合理的設置http緩存，恰當的緩存設置可以大大減少http請求。要儘可能地讓資源能夠在緩存中待得更久

（2）從設計實現層面簡化頁面，保持頁面簡潔、減少資源的使用時是最直接的。

（3）資源合併與壓縮，儘可能的將外部的腳本、樣式進行合併，多個合爲一個。

  (4)   CSS Sprites，通過合併 CSS圖片，這是減少請求數的一個好辦法

  我的答案：思路清晰 從請求發送開始談，減少請求，增加緩存，然後到頁面渲染。

js我記得谷歌瀏覽器默認併發請求最多好像是4個還是6個，所以 比如你用webpack打包的項目 你的js 和css 做個split處理 但是不能處理的太細碎  比如js 可以利用註釋 

這種 將瑣碎的js文件 按你需要的模塊打包到一起（分包是優化，不過簡單的組裝更是一種優化~），然後就是按需加載，即 單頁應用 進入某個頁面 再加載這個頁面的js 和css  利用es6 的

做到按需加載，然後就是 各種 雪碧圖，圖片 懶加載 預加載 等等，這些都可以 減少http的請求數，當然 圖片的尺寸及大小也是你要注意的，然後就是利用oss 減少從服務器獲取圖片，應該會快一些的

B 內聯腳本的位置

瀏覽器是併發請求的，而外鏈腳本在加載時卻常常阻塞其他資源，例如在腳本加載完成之前，它後面的圖片、樣式以及其他腳本都處於阻塞狀態，直到腳本加載完成後纔會開始加載。如果將腳本放在比較靠前的位置，則會影響整個頁面的加載速度

C DOM操作優化：

要避免在document上直接進行頻繁的DOM操作，可以使用classname代替大量的內聯樣式修改，對於複雜的UI元素，設置position爲absolute或fixed，儘量使用css動畫，適當使用canvas儘量減少css表達式的使用，使用事件代理

   我的答案：這個就是重繪和重構的問題了，比如少用js去操作css  如果一定用 那就用cssText去操作，比如操作css的時候 display none後  調整好樣式 再display block 會比你反覆設置css樣式會更快 或者比如 你可以用class提前約定好你要切換的css樣式。然後切換class 可以做到減少調整次數 減少重繪  這裏要理解頁面上部的重繪重構都會引起下面的重繪重構。所以合理排版佈局。更多的自己收集些吧

CSS選擇符：

大多數人認爲，瀏覽器對CSS的解析是從左往右的，事實上從右往左解析的效率更高，因爲第一個id選擇基本上就把查找的範圍限定了。

我的答案： 這個稍微細節些  上個截圖  在上面說的css 減少重繪重構的同時 最好記住css書寫規範 因爲 他也會引起重繪和重構，

對上圖  我再舉個例子  你一個css 設置了寬高顏色背景色等  domtree 和csstree結合的時候 一頓合併 然後你最後寫了個position:absolute   domtree 心裏一頓mmb，你不在文檔流裏  爲什麼不早告訴我 然後又重新調整結構， 這下你知道 css書寫規範的作用了吧  具體可以看這個網址，寫的非常棒  鏈接

好吧 性能調優 先說這麼多

2 http緩存

答案 a https://www.cnblogs.com/ranyonsue/p/8918908.html

我的答案：這裏 要區分  問的是http緩存 不是 瀏覽器緩存 所以不要說 什麼cookie sessionstorage dbindex等 你以爲的緩存內容

然後http緩存    第一次請求 肯定不存在緩存了（我說的絕對第一次請求，務較真 )  我們說第二次請求的時候 

htttp 緩存分爲  強緩存 協商緩存 和不緩存  當然  如果你角度不同 還分爲 私有緩存和 共享緩存  我們不討論這個

這裏強緩存 涉及 幾個 請求頭 中的 關鍵字 progma catch-control expires 這3個次 我按優先級列出的

協商緩存  涉及 幾個關鍵字  ETag/if-not-match  last-modified/if-modified-since  意思 就是英文翻譯的直譯即可

上2個 強緩存 關鍵字的信息

 

下面上2個 協商緩存的圖

理解 這個2個圖後 你需要知道 js 如何設置

基本都是在 頁面的meta標籤裏

1.1、html頁面禁用緩存的設置如下：
<meta http-equiv="pragma" content="no-cache">
// 僅有IE瀏覽器才識別的標籤，不一定會在請求字段加上Pragma，但的確會讓當前頁面每次都發新請求
<meta http-equiv="cache-control" content="no-cache">
// 其他主流瀏覽器識別的標籤
<meta http-equiv="expires" content="0">
// 僅有IE瀏覽器才識別的標籤，該方式僅僅作爲知會IE緩存時間的標記，你並不能在請求或響應報文中找到Expires字段

1.2、html設置緩存如下：
<meta http-equiv="Cache-Control" content="max-age=7200" />
// 其他主流瀏覽器識別的標籤
<meta http-equiv="Expires" content="Mon, 20 Aug 2018 23:00:00 GMT" />
// 僅有IE瀏覽器才識別的標籤

掛2個鏈接 便於你理解 內容寫的都非常棒 鏈接1  鏈接2    關於 http 緩存 先說這麼多吧

3 .做過的有特點的項目

這裏沒什麼可說的了 結合你自己說吧  比如博主的 單頁egg+vue+webpack項目 或者 ssr的服務端渲染項目等，切記  介紹的時候 不要盲目吹噓 把自己真實掌握 並且理解的東西 展現出來  哪怕是錯的  你如果認爲 你是真實理解的 就可以說  不確定的 不要吹噓

4.遇到的問題與解決方案

這裏也沒啥可說的了 你自己遇到的 自己解決的過程  比如 iphone和安卓的兼容性  比如input 軟鍵盤談起收回，比如js的計算誤差，比如iframe下 fixed定位失效 比如滑動遲鈍 比如 input 節流防抖 比如 使用某些ui框架組件的bug 比如跨域 比如 swiper反向滑動點擊失效 比如 手機端彈出提示窗口禁用頁面滑動 比如ios點擊h5 數字能撥打電話  或者頁面 灰度閃屏  這些 是你真實的經歷

5.toB和toC的區別

這裏 其實 博主我也不是很確定  百度 搜  toB 和 toC 指的是你的是產品 是對某一個行業領域 還是對你的用戶需求

B 可能是business ,C 可能是Consumer 以上基於猜測啊 

不過我在想 B有可能是browser , C有可能是client 也就是對瀏覽器和對客戶端的卻別   感覺這個和前端還有點靠邊

所以 這裏不做具體答案 大家自行理解 自行百度吧   抱歉sorry

6.現場面對客戶的經歷

都是開放問題  博主這  感覺 面對我們的產品就是面對客戶了  產品的所有需求 都是從客戶哪收集的  畢竟客戶是上帝 哈哈哈

反正是有很多奇葩的想法 當然也有很多改進型意見  比如  頁面跳轉後 返回 客戶可能希望保留這個頁面之前 他輸入的一些值

但是 這個頁面上可能還有 必須每次刷新的內容 所以 技術點可能在跳轉保存數據吧  可以用url來回帶餐 當然弊端就是如果跳的多了 信息就丟了  那也可以 利用sessionstorage去緩存 都可以。

還有一個是 做免登陸 或者 快速登錄的操作一般就結合 wx zfb等第三方做的開發  你列舉一些就可以了

7.前端安全相關(着重中間人劫持)

一：XSS：跨站腳本攻擊

一句話: 頁面渲染的數據中包含可運行的腳本   一般就是富文本編輯器 或者一些input輸入框   即用戶可以輸入內容的地方，會被注入一些 腳本代碼 

二：CSRF：跨站請求僞造

一句話：a網站的前後端通信後  a網站瀏覽器存儲了一些信息    然後  b網站獲取a網站上存儲的信息 去給a網站後端發送請求 即 a網站登錄後  信息存儲本地 然後 b網站獲取到登錄信息 跳過登錄 去進行操作

三：點擊劫持

一句話：第三方網站通過iframe內嵌某一個網站，並且將iframe設置爲透明不可見，將其覆蓋在其他經過僞裝的DOM上，僞裝的可點擊DOM（按鈕等）與實際內嵌網站的可點擊DOM位置相同，當用戶點擊僞裝的DOM時，實際上點擊的是iframe中內嵌的網頁的DOM從而觸發請求操作

我的答案  上面3種 博主都遇到過

第一種： input地方 當然 要對信息 進行轉義  比如 大於小於等於 其他沒注意過  可以從一會給的鏈接去多學學

第二種：csrf 的話  博主用過egg框架  所有的post請求 要帶有csrf 可以放參數裏 可以放請求頭裏 然後 後臺會對比每次的csrf 然後後臺 對csrf 進行每次刷新及返回  其實就是比對 每次的csrf是否相同 還有就是利用token 可以放cookie 然後 每次請求的時候 都帶着  和上面的csrf 同理

第三種：iframe的話 還是egg 框架  裏面可以設置 你的網站是否允許被iframe包含  這是最有效的處理的方式

原理就是  設置http響應頭 X-Frame-Options：有三個值 DENY（禁止內嵌） SAMEORIGIN（只允許同域名頁面內嵌） ALLOW-FROM（指定可以內嵌的地址）

還有就是利用 被iframe了  頁面的變化 去進行一些處理 Javascript禁止內嵌：當網頁沒有被使用iframe內嵌時，top和window是相等的；當網頁被內嵌時，top和window是不相等的

問題中的 中間人劫持 其實 就是  二 和三 的合併 你要做的  1是 用https 2是 你除了我說的那些 還可以對內容進行加密處理  即 前後端約定好加密串 然後採用非對稱加密的方式  這樣也可以有效的減少

更多信息  放鏈接  鏈接1 鏈接2 鏈接3

8.爲什麼跳槽

9.職業規劃

我覺得 這2個 可以一起回答了  對自己的職業規劃有個方向 然後 跳槽 多半就是和自己的規劃不太符合

10.有什麼問我的(團隊簡介、前端參與項目的過程)

我的答案 ： 這裏 可以問一下 工作內容 包括使用的技術 日常工作安排 然後公司對每一個人的規劃 然後 問問 其他你關心的問題

二面（資深前端研發同事）

1. 項目開發流程

2. 對vuex的看法

3. vue從data改變到頁面渲染的過程

4. 介紹狀態機

5. 組件設計原則

6. 怎麼看待組件層級嵌套很多層

7. 前端安全防範措施

8. 介紹oauth

9. 怎麼看待virtual dom

10. 對flutter的瞭解

11. weex和rn原理

12. 大屏用的技術

13. 大屏數據來源與管理

14. websocket的使用場景

15. pwa的使用

16. 對http2的瞭解

17. 對新技術的瞭解

18. 職業規劃

19. 爲什麼想來騰訊

20. 有什麼問我的（團隊協作方式、技術積累、對我的期待）

收集答案

1.項目開發流程

我的答案： 這裏博主只說 自己經歷的 過程 每個公司不一樣 所以僅做參考 

A.首先肯定是產品收集同類產品信息 ，然後結合自身產品，分析出產品方向 然後 結合收集的用戶需求 制定 自己產品的需求文檔 

這裏 接觸的 工具是  《墨刀》 

B.然後就是和產品碰頭 開需求會  也就是溝通下哪些功能 是實現不了的  哪些東西 和產品想象的不一樣  就是撕x的過程吧 算是

C.然後就是確定的功能 討論定下來後 我們可以根據修訂的墨刀先進行功能開發，然後 UI出設計圖 ，然後 技術開會 和後臺溝通 確定下 各個接口的參數 和返回值 及具體字段  （這個階段多半會調整一陣）

D.然後編輯服務器mock 做好假數據  然後 根據ui圖 排版，做一些兼容處理

E.然後開發過程中 一般是我帶的團隊開發。我檢查一下他們的代碼規範及註釋等等。然後做一些優化處理

F.這裏很遺憾 我一直沒有接觸過 自己編寫單元測試 公司規模不夠吧 或許吧  

G.測試階段 修改bug 解決 一些偶發 或者兼容問題  

H.項目發佈   

這裏的流程 是博主本人的  可能相對大廠 不是很全  僅供參考

2.對vuex的看法

我的答案：A.首先 先說說vuex的概念

Vuex 是一個專爲 Vue.js 應用程序開發的狀態管理模式。它採用集中式存儲管理應用的所有組件的狀態，並以相應的規則保證狀態以一種可預測的方式發生變化。

B.然後就是 vuex 的適用場景吧

1.涉及到非父子關係的組件，例如兄弟關係、祖孫關係，甚至更遠的關係；
2.他們之間如果有數據交互，那麼應該使用Vuex來實現；
3.如果頁面複雜度比較低的話，也可以考慮使用 global-event-bus 來實現；
4.如果只是父子關係的組件數據交互，那麼應該考慮使用props進行單向傳遞；
5.如果涉及到子組件向父組件的數據傳遞，那麼應該考慮使用 $emit 和 $on；

其實就是  多層組件或者跨頁面傳值問題而誕生 比如 常見的 登錄狀態  常用的就是後臺管理系統

C.然後就是vuex裏的核心4要素 state actions getters mutations 及 mutations-types

D.然後就是一些語法糖mapstate mapGetters mapMutations mapActions 等等 以及 從頁面發起dispatch 到最後頁面信息改變的流程

最後補充下 你實際應用在哪裏了  什麼場景 是你使用的  什麼時候 你直接傳值 而不用vuex  這個一定要分清

3.vue從data改變到頁面渲染的過程

1. new Vue，執行初始化
2. 掛載$mount方法，通過自定義Render方法、template、el等生成Render函數
3. 通過Watcher監聽數據的變化
4. 當數據發生變化時，Render函數執行生成VNode對象
5. 通過patch方法，對比新舊VNode對象，通過DOM Diff算法，添加、修改、刪除真正的DOM元素、

我的答案：

A.new Vue 初始化  給 data裏的值  利用 Object.defineProperty 設置set 和get ，然後多一個對應的watcher進行監聽（vue3裏已經換成proxy了，處理了 不能監聽數組的問題，當然 就拋棄了ie）

B.生成上面說的Render 渲染函數  這個函數會被調用  返回一個虛擬的dom Tree（也就是Virtual Tree） 就是上面說的vnode對象

C.然後交給patch函數 把這個虛擬的dom Tree （也就是Virtual Tree）變成真正的dom 

D.當有內容被修改的時候 先觸發set 然後 會觸發notify函數 通知所有的watcher 然後 觸發vm._update(vm._render(),hydrating) 會重新生成新的虛擬dom Tree （也就是Virtual Tree）然後 還是個patch函數 進行對比   然後 改動真實的 dom Tree

E. 這裏多說2句  感覺 這個問題核心就是想問問你知不知道  2次virtual Tree 的diff對比  這裏上3張圖  助大家理解

下圖 是 最原始的  思路   然後 是 優化後的 二代思路 

上面2種思路 是進化的過程 但是 都有缺陷  也是因爲上面的思考過程  然後 衍生出了  virtual Tree 虛擬dom 樹

什麼是virtual tree呢   可以理解爲 一個js對象    

比如 一個 正常的標籤  <div id ='gq'><span>Hello world</span></div>

那麼 虛擬dom的 js對象 是   ['div',{id:'gq'},['span',{},'Hello world']]  顯示標籤 然後是屬性 然後是 children

上面的  內容 就是 虛擬dom 產生的 過程 及 優點  讓你明白 所謂的virtual dom 是怎麼回事

然後 我再說一下 diff 算法  關鍵字  A 同層比對  B 循環的時候 添加key值  且不用index

同層比對的時候 我舉一個部分例子  比如  第一層 想同  那麼我們比對第二層  如果 第二層不同  那麼 直接清空 原來virtual tree的子節點 然後 直接複製 新的virtual tree  去渲染   

再具體些  這個文章 我認爲 是講的 最細 最全的  的    點擊鏈接  裏面有vue diff算法的  對比過程  即 處理 a.頭部同類型節點 b.處理尾部的同類型節點c.處理 頭尾 同類型的節點d.處理新增節點e.處理更新節點 f.處理需要刪除的節點    鏈接1  鏈接2

4.介紹狀態機

文字介紹 ：狀態機的數學定義是一個計算模型，我的理解是：狀態機就是保存你的狀態和狀態變化的一個盒子。這裏有一些不同種類的狀態機，適用於我們這個案例的是有限狀態機。像它的名字一樣，有限狀態機包含有限的幾種狀態。它接收一個輸入並且基於這個輸入和當前的狀態決定下一個狀態，可能會有多種情況輸出。當狀態機改變了狀態，我們就稱爲它過渡到一個新的狀態。
我的答案： 其實 所謂的狀態機  你可以粗略的理解爲  類switch 的功能  他讓你更清晰直觀的 瞭解 你當前情況 所涉及的狀態 以及 你對不同狀態的 不同處理方式  百度後  大多討論 vuex 及 redux  因爲 這2者 就是狀態機的 具體體現及應用  不過 不同的是  vue允許修改store裏的state 因爲vue監聽方式  修改state後 會觸發get 而修改頁面  而 redux 則不能修改state 只能 利用  reducer 去返回一個新的state 

再百話一點  你把 一些 繁瑣的 if else  等  反覆嵌套的判斷  變成了 你熟知 明確的  不同狀態  然後 根據不同狀態 去修改你要操作的代碼 這樣  你對所謂的組件的 整體狀態 就有了更準確的把控

文章鏈接   鏈接1 鏈接2 鏈接3

5.組件設計原則

• 層次結構和 UML 類圖
• 扁平化、面向數據的 state/props
• 更加純粹的 State 變化
• 低耦合
• 輔助代碼分離
• 提煉精華
• 及時模塊化
• 集中/統一的狀態管理

放2個鏈接   都是  文字類  理論描述  鏈接1  鏈接2_1 鏈接2_2 鏈接2_3

我的答案： 這裏只說我涉及組件的體會   你需要考慮到 後續當要添加功能時 能否二次複用 所以  比如 一些事件 最好不要寫在組件裏 而是用觸發調用組件上的方法 去編寫   然後就是 屬性儘量 有類型約束  然後  名稱不要用對象 要見名知意的 去定義屬性  然後 就是 減少對其他組件的依賴 以及上文說到的  環形依賴  儘量松耦合  讓你的組件 更加扁平  如果你的組件 能成爲別人組件的 一部分 那我覺得 這是一個很好的輪子  然後就是如果二次 去豐富你的組件的時候 要考慮到 已經使用這個組件的地方  如果你要修改你的組件  那麼要考慮清楚你的默認值 及變動 否則 最好  寫個新組件 去繼承 第一個組件  然後 去修改 新的組件繼承的方法的實現  這也是較少耦合

6.怎麼看待組件層級嵌套很多層

我的答案 首先 這麼做肯定難以維護  哪怕用了狀態管理 去控制你組件裏的那些值  但是  多層嵌套後  如果出了問題 還是很難去確認的 所以 我建議 如果你想要服用別的組件時 可以 繼承或者mixin 這個組件 混合後 去重寫 你要的東西 或者修改     再者 如果真的要複用 那麼請先確認要 底層組件的 所有參數及屬性  有可能因爲不瞭解 造成 無法尋找的錯誤  或者因爲不瞭解 而重複設置想同功能的代碼   那真是得不償失

7.前端安全防範措施

這個一面的時候應該提及了  xss  csrf  跨站點攻擊  注入漏洞  防範  也列舉過  進行轉義  開啓csrf對比  利用token 利用驗證碼 等等

8.介紹oauth

全程 open Authorization  翻譯就是開放登錄授權  其實就類似於 你登錄一些app 然後用你的wx 或者qq 或者支付寶 授權 去進行登錄

這樣既省去了你註冊的繁瑣  同時 簡化了用戶的操作  用戶體驗更高  畢竟密碼太多 很難記住的  而且 這個方式 其實更加安全

比如微信授權登錄的流程

1. 第三方發起微信授權登錄請求，微信用戶允許授權第三方應用後，微信會拉起應用或重定向到第三方網站，並且帶上授權臨時票據code參數；

2. 通過code參數加上AppID和AppSecret等，通過API換取access_token；

3. 通過access_token進行接口調用，獲取用戶基本數據資源或幫助用戶實現基本操作。

給2個鏈接   喜歡的 去讀一讀吧   鏈接1  鏈接2

9.怎麼看待virtual dom

這個我在 二面 3問裏 進行了介紹 和回答  這裏不再處理

10.對flutter的瞭解

flutter 最近是吵的比較火  他算是一個框架吧   編寫代碼的語言是dart  畢竟我周圍的 安卓和ios 都在學習   我沒有把時間放在他上面 而是學習了python  這裏沒法給大家一些答案 不過  我看了一些介紹 dart  裏的語法 有些類 js 及python  然後  靠近 ts   主要是基於1端代碼 去實現  2個客戶端 ios 及 安卓 的應用   語法上  定義變量 用var    這裏 放一些 dart的官網  有興趣的可以學學 不過 我覺得 還是應該多瞭解些

11.weex和rn原理

Weex 和React Native最主要的區別可以總結爲：Write once, run anywhere和 Learn once, write anywhere思想層次，以及Vue.js和React.js兩大基礎框架上的區別。

這裏其實可以把 flutter 加上  3者進行討論

我的答案  這裏問的原理  我覺得 根據上面的思想可以理解 weex  寫一次 在哪裏都可以運行 他和flutter一樣  有自己的書寫語言  然後利用編譯器 編譯成  不同c端識別的代碼   而 rn是 學習一次 在哪裏都寫   也就是 從自身語法觸發   利用自己的語法 可以寫成ios 識別的代碼 也可以寫成安卓的代碼  所以  rn 對2個c端  需要寫2分代碼 但用的都是 rn的語法  

基礎原理 就還是 virtual dom 那提到的  react 的 虛擬樹  其實是個方法  而不是 不被識別的html代碼  那麼 如果有了虛擬樹的方法  那麼就可以改變對這個方法的解析方法 從而解析成不同c端所識別的代碼了

而flutter 和weex 更多的是利用引擎  我編寫好了一套代碼 利用引擎 去轉義成  不同c端識別的代碼

這個鏈接說的不錯  鏈接1   鏈接2  鏈接3

12.大屏用的技術

我的答案 這裏 博主 參與過2次大屏的製作  第一次 沒有經驗 一共4塊屏幕 作者寫了4個項目 然後 拼接出來的  大屏效果

第二次大屏項目 因爲公司大屏 分辨率問題  正常的代碼  在大屏上 會拉伸  所以 博主 都是通過 css3 的 scale 去橫向拉伸頁面 去完成的效果展示  哎  記憶尤深   下面說說 用到的技術  不知道對不對  僅供參考   

首先 echart 肯定跑不了了  大屏主要就是由各個 圖片構成  然後就是 例如滾動字文字 那麼有個jq插件 滾動不錯 當然 自己也可以寫 不難   插件地址  http://resource.haorooms.com/softshow-29-270-1.html  然後就是頁面的信息  因爲大屏要實時請求接口  所以  用的定時器 去調用接口 間隔 5s  利用的setInterval 去做的  然後就是一些炫酷的圖  多半 都是svg圖 所以你也需要  然後就是 css的一些基礎知識  

所以  1 css基礎 什麼vh vw css3的 scale rotate啥的  2 echarts   3 就是jq的一些插件 4  js一些定時器 5 canvas 也會用  這是我能想到的  當然 還有付費的datav 是阿里的  博主沒有去嘗試

13.大屏數據來源與管理

我的答案：有些模糊 不知道問點在哪裏  模糊作答  數據來源 一般都是後臺接口 然後定時器請求   管理的話  區別好緩存處理

比如一個大屏上多個數據 有一些 是實時更新的 有一些 是按天更新的 有一些是 固定內容 那麼當然要分塊管理  實時的 處理好緩存 可以添加隨機數後綴   一定時間的 定時器要做好 開啓和清空處理  固定的 要考慮好維護   博主只能粗糙作答 見諒

14.websocket的使用場景

我的答案：Websocket是一個持久化的協議，相對於HTTP這種非持久的協議來說。啥意思呢  比如 你之前的前後臺交互  觸發點都是前臺  用戶 打開網頁看到數據  用戶點擊按鈕 用戶失去焦點 去完成什麼什麼  但是 沒有後端主動給前臺發送些什麼信息  這是因爲 你的項目 都是非持久鏈接    現在 想象一個場景  你現在 要寫一個聊天室 也就是 你自己的qq 當你上線後   別人給你發信息 是不是主動彈出  主動推到你的電腦裏   並不是你點擊個按鈕 說看一看有沒有人跟我說話啊  等你按完 黃花菜都涼了  這種 服務端 主動發送信息給客戶端 並且客戶端能夠接收進行處理的技術 可以用websocket去實現   當我們創建 這個繪話的時候 我們彼此就建立了 持久化的協議  然後 各自都有約定好的監聽   後臺可以隨時主動與你通信   你也可以主動給後臺發送請求  具體一些的使用場景

1.社交訂閱 2.多玩家遊戲 3.協同編輯/編程 4.點擊流數據 5.股票基金報價 6.體育實況更新 7.多媒體聊天 8.基於位置的應用  這些都比較官方 你都可以回答 直播和 屏幕共享  給個鏈接吧  鏈接1 鏈接2

 15.pwa的使用

這裏博主接觸過 百度有一個pwa框架  叫做lavas  不過最新消息 據說 項目流產了  鏈接

接下來介紹一下pwa    全稱Progressive Web App  漸進式web應用  下面摘自百度搜索  當然最後放鏈接  目的就是大家查看方便 博主也2次學習

pwa 特點 

1. 可靠——即時加載，即使在不確定的網絡條件下也不會受到影響。

2. 快速

3. 沉浸式體驗—— 感覺就像設備上的原生應用程序，具有沉浸式的用戶體驗。

Web應用程序中，可以通過manifest.json控制應用程序的顯示方式和啓動方式，指定主屏幕圖標、啓動應用程序時要加載的頁面、屏幕方向，甚至可以指定是否顯示瀏覽器Chrome。

pwa的核心

1. Web App Manifest
2. Service Worker
3. Cache API 緩存
4. Push&Notification 推送與通知
5. Background Sync 後臺同步
6. 響應式設計

pwa 彌補了 與原生app的 差距：

1 無法離線使用 

Service Worker + HTTPS +Cache Api + indexedDB 等一系列web技術實現離線加載和緩存

2 數據更新 

Background Sync 後臺同步技術

3 無法實現推送

Push&Notification 實現推送與通知

4 無法添加到桌面

通過manifest.json文件配置，使得可以直接添加到手機的桌面上。

pwa的優勢

1. 無需安裝，無需下載，只要你輸入網址訪問一次，然後將其添加到設備桌面就可以持續使用。

2. 發佈不需要提交到app商店審覈

3. 更新迭代版本不需要審覈，不需要重新發布審覈

4. 現有的web網頁都能通過改進成爲PWA， 能很快的轉型，上線，實現業務、獲取流量

5. 不需要開發Android和IOS兩套不同的版本

我的答案：說完了百度 說一下博主的經驗 博主所在公司 曾經給公司領導們弄了一個cms 的手機版 然後利用的 vue-eement-admin 弄了一版 然後 因爲這個框架 自帶了pwa部分  博主這裏說一下 曾經調試的  首先 做過幫助中心頁 也就是給 單位的領導們一個安裝幫助 即 打開瀏覽器 然後 分享 然後 添加到主屏幕     添加到主屏幕這  安卓和ios 不同 所以  做了這個幫助頁面

然後就是一些配置   其中就是 manifest

上圖中 title 爲落地圖標的名稱  link 中rel爲icon 是給安卓準備的桌面圖標 這裏有個坑 就是圖片要封閉留邊 否則 你的圖標背景 就會和圖標顏色相同    上面的 link 是apple-touch-icon的 是給 ios各個機型配置的不同尺寸的 桌面圖標

說完了配置 再說說我的理解 

A.你在開發h5的經歷中是否遇到過 你們的產品讓你做 如果在沒有網的情況下 顯示什麼內容  那個時候 我總是淡淡一笑  沒網了 我能做啥？哈哈哈 對  pwa 最大的特點 就是對這個  如果你沒有網絡的時候 你有很多頁面都緩存在瀏覽器裏 但是你卻用不了  有的pwa 你就可以了  斷網情況下 還可以讓用戶繼續使用 那些 不需要網絡的東西 

B.做web  h5 最被app鄙視的就是 什麼都基於先打開瀏覽器  有了pwa 無需瀏覽器 我們的假殼 就想app啓動圖標一樣留住用戶的桌面上

C.你使用app的時候是不是總收到後臺的推送 玩玩遊戲 哐當一下 就彈出了一個推送 有了pwa 你的h5也可以這樣

D.你都可以把h5頁面放用戶桌面上了  就不用學習安卓 和ios了語言了 也不需要經歷蘋果 提審 沒過 再提審的痛苦 重啓服務器  搞定

博主 目前設計的 pwa 只有這麼多  具體的 service worker 和push 啥的  還沒涉及過 無法解釋更多  慢慢學習吧

16.對http2的瞭解

首先了解http1 http稱爲超文本傳輸協議，是互聯網上應用最爲廣泛的一種網絡協議。而 http1 是http的 第一個版本

http1 隨着社會發展 暴露出了很多缺點

1、高延遲--帶來頁面加載速度的降低   

主要體現網絡延遲問題主要由於隊頭阻塞(Head-Of-Line Blocking),導致帶寬無法被充分利用。谷歌瀏覽器 默認併發6個請求 如果來10個請求 那麼有4個就要等待  如果這6箇中有一個阻塞 那麼後續的請求也會被一併阻塞 所以人們爲了優化  做了一些技術改進 什麼 雪碧圖 什麼圖片base64碼等等 或者 圖片的原始數據放到css的url裏 或者利用webpack 拆包的同時 合併包 減少併發請求

2、無狀態特性--帶來的巨大HTTP頭部

可能傳輸信息很少 但是http 頭部信息過於飽滿 且 重複無意義

3、明文傳輸--帶來的不安全性

信息明文傳輸  抓包後 可以進行 信息泄露

4、不支持服務器推送消息

http2 的特性

1、二進制傳輸

HTTP/2傳輸數據量的大幅減少,主要有兩個原因:以二進制方式傳輸和Header 壓縮；HTTP/2 將請求和響應數據分割爲更小的幀，並且它們採用二進制編碼。HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數量的雙向數據流。每個數據流都以消息的形式發送，而消息又由一個或多個幀組成。多個幀之間可以亂序發送，根據幀首部的流標識可以重新組裝。

2、Header 壓縮

利用新的hpack壓縮算法  且 在客戶端和服務端建立首部表  並且不斷更新  主要是爲了  下次再傳輸的時候 對比下 有的 就不必要再傳輸了 減少了 傳輸的內容

3、多路複用

• 同域名下所有通信都在單個連接上完成。

• 單個連接可以承載任意數量的雙向數據流。

• 數據流以消息的形式發送，而消息又由一個或多個幀組成，多個幀之間可以亂序發送，因爲根據幀首部的流標識可以重新組裝。

這一特性，使性能有了極大提升：

• 同個域名只需要佔用一個 TCP 連接，使用一個連接並行發送多個請求和響應,這樣整個頁面資源的下載過程只需要一次慢啓動，同時也避免了多個TCP連接競爭帶寬所帶來的問題。

• 並行交錯地發送多個請求/響應，請求/響應之間互不影響。

• 在HTTP/2中，每個請求都可以帶一個31bit的優先值，0表示最高優先級， 數值越大優先級越低。有了這個優先值，客戶端和服務器就可以在處理不同的流時採取不同的策略，以最優的方式發送流、消息和幀。

4、Server Push

服務端可以主動推送 比如  請求html文件的時候  同時 把 html可能用到的 css js 一併返還回去 不用再等待html請求後 再請求css js的時候 返還回去

5、提高安全性

http2 也是加密傳輸的

這裏多說一句 http3也在提議當中  主要針對的http2的一些缺陷 比如丟包 阻塞等  他是在http2上 的優化

我的答案：http1 的缺點列舉下  http2 主要採用幀的形式  無序的 把同一個域名下的請求 放在了一個單獨的tcp通道上  ，速度會更快 而且 進行了特殊的壓縮 及優化處理  還有就是加密  然後http3 解決http2阻塞因爲http2 無序導致丟包 後的阻塞  http3 是在http2 同域名單通道的情況下 進行 單通道的 拆分排序    這樣便於 處理丟包等問題

這裏有我轉載的  一篇  http的博客 可以去看看

17.對新技術的瞭解

這裏就自由發揮了  關注一些 新動態   博主 以前是java  學習過python 然後轉前端  使用vue及react寫個項目  上面提到的electron 和 flutter  pwa  uniapp 都可以說一說你的看法  然後就是 相對RESTful風格對立而生的 graphql 請求 也可以談談   自由發揮吧

18.職業規劃

19.爲什麼想來騰訊

20.有什麼問我的（團隊協作方式、技術積累、對我的期待）

上面的3個題 就都是開發作答了  自由發揮吧  要是我回答 可能騰訊的遊戲 掙我太多錢了  我想從騰訊這掙回來點 哈哈哈哈  開玩笑

 

這篇博客太長了 所以 我把  三面  四面  五面的  寫在了另一篇博客裏