本文以本人有限的經歷提供一些思路，實際真的有解決過比較棘手的問題的同學就沒什么看的必要了，
我認為這個問題主要考察的一方面是求職者解決問題的能力，另一方面是求職者的總結復盤能力，有時還考察求職者是否對技術有關注和接觸，這類主觀題我覺得可以針對JD的要求去貼近招人需求，
平時忙于業務開發的同學，有時很容易忽略一些問題，或者有時急著完成需求和修復bug，解決問題后沒及時記錄下來，本文就起個拋磚引玉的作用，列舉一些比較通用型的問題，
按鈕重復點擊的問題
其實這場景應該還蠻容易遇見的，所以我覺得比較適合做前端年限不太長比如一兩年的同學來作為備選，
有時因為網路問題，或者手機性能問題，或者一些未知原因，導致用戶點擊按鈕的操作沒有及時得到回應，用戶下意識的就會頻繁重復點擊，
如果該按鈕的點擊回呼是去呼叫介面，假設用戶頻繁點擊，不可避免的就會給服務器造成壓力，最簡單的處理就是在用戶點擊之后設定按鈕為不可點擊，等到介面有回傳后再將按鈕狀態重置；如果介面沒有合適的回傳，為了防止因網路等原因導致的沒有回應，也可以前端設定定時，使用戶操作控制在一定的頻率，比如發送驗證碼這種場景，
如果該按鈕的點擊回呼是打開一個彈窗，頻繁點擊的后果可能就是打開一串的彈窗，當然也可以給按鈕設定狀態標記欄位或者定時，此時就可以結合節流與防抖作答，正好面試中也很容易遇到節流與防抖的問題，化被動為主動更好把握面試節奏，當然前提就是對這方面的內容有所準備，
如果該按鈕是與原生有互動，比如本人曾經遇到過呼叫原生打開新的webview或者其他app，如果原生因為某些系統原因沒有及時打開，節流防抖也做了，但是如果回應延遲很久，用戶可能在頁面上做其他操作了，此時如果之前打開新的webview或者其他app有了回應，就有可能同時出現多個操作的互動反饋，造成混亂，后來的解決方案還是做了欄位標記，在第一次打開webview的操作就作標記，如果此標記沒重置（沒打開新的appview），就不回應后續此頁面上的其他互動，這在使用邏輯上可能有些不太合理，但是打開webview和其他app的操作原生無法取消，當時還沒想到比較好的其他處理方案，
輪詢介面的問題
此類場景也還算常見，適合兩三年、三四年的同學作為備選，
有時我們會遇到一些需求，比如頁面要定時獲取最新的資料，如用戶積分、app內訊息通知，一般簡單的處理就是使用介面輪詢，定時呼叫后端介面，如果應用的流量不大、使用的用戶不多，這么處理也沒什么大問題，
但實際這樣做會使請求過多，占用服務器資源，出于優化思考，可以考慮websocket，就可以提前對websocket做一些了解學習，如果專案實際開發中有使用經驗就更好了，
單次加載圖片過多的問題
這個問題通常發生在移動端，尤其圖片體積偏大時，可能影響其他請求的發送，
比較常見的就是串列，往往這些串列的資料是用戶在后臺上傳的，因此如果用戶傳一些高清圖，就可能導致圖片體積過大，圖片壓縮當要做，同時在移動端，我們也可以做圖片懶加載，只渲染進入可視區域的圖片，等待圖片即將進入可視區域時再進行加載；現在移動端串列一般會做分頁，也就是常見的上拉加載，一次不會加載太多圖片，如果對性能要求比較高的時候也可以加上懶加載，
如果圖片托管在OSS平臺，也可以在鏈接后面追加處理引數（x-oss-process），對回傳的圖片的大小和尺寸進行限制，也是一種方法，
移動端適配問題
移動端老生常談的問題了，css中的相對單位，常用方案rem可以說，配合了解一些webpack插件，
也可以說說vw、vh，螢屏解析度，瀏覽器視口，
移動端兼容問題
移動端手機型號多，尤其安卓機型，或多或少會碰到這類問題，但這些問題又不能一概而論，
如果有同學解決過較多這方面的問題，但是平日里沒有整理過，可以提前做一些整理，去mdn、caniuse等網站針對做一些補充完善，就可以在面試時發揮了，
應用性能問題
如果實在作業開發中沒碰到過什么大的問題，還可以有個萬能的回答，就是對應用性能進行優化，我看很多JD里也會希望候選人有性能優化方面的經驗，正好可以對應上，
隨著需求迭代，專案代碼不可避免會增多，打包體積隨之增加，用戶首次打開應用也會變慢，這個問題可以從多方面著手去作答，
從互動層面，可以做骨架屏，使得頁面首次加載不會長時間白屏，也能讓用戶預先知道頁面的分布；或者增加一些等待的互動，
從代碼層面，可以提取公用代碼、通用代碼，抽取出來做成公用函式，或者封裝成組件，業務組件或者基礎組件，
從構建工具方面，比如webpack，可以提前了解它的一些配置，比如代碼壓縮、代碼拆分、tree-shaking、懶加載，
從性能工具方面，比如lighthouse，量化指標，根據提供的建議進行調優，可以提前了解一些代碼和性能分析工具，
從網路請求方面，比如用戶端設定快取，可以提前預備強快取和協商快取方面的儲備知識，一方面減少用戶請求，一方面及時更新快取；使用CDN等等，
從技術方面，可以準備微前端等相關知識，
線上問題定位
對于前端來說有個很頭疼的問題，就是線上問題，不想后端一樣可以有線上日志，前端問題出現在客戶端時我們不知道發生了什么，用戶操作了什么，就算可以聯系到用戶，有時他們也不一定記得自己做了什么，而往往很多時候知道原因就很容易解決問題了，難的就是不知道導致問題的原因，
這個問題我大概是五六年前的時候第一次碰見，很緊急的一個線上支付問題，前端反反復復盲改，一直沒改好了，后來加了錯誤捕獲，再通過呼叫介面獲取到錯誤資訊，才知道原因是什么；后來換了作業在新公司中接觸到埋點，才開始了解到這一塊的東西，不過當時公司的埋點主要用于用戶行為分析，在用戶進行一些互動操作，比如點擊、進入頁面、登錄時，將用戶行為資料上報給埋點平臺，資料分析的同學會利用這些資料進行統計，可以給運營同學做一些運營策略的參考，給產品經理規劃需求時做參考，
再后來在作業中又接觸到監控平臺sentry，使用它將應用中捕獲到的錯誤上報給平臺，在sentry平臺可以看到哪些錯誤是比較頻發的，還可以直觀的看到在拋出錯誤時上報的相關資料，比如作業系統、用戶標識、ip、錯誤資訊等等，還可以看到問題是在哪些時間段頻發，從而可以確認新發的包是否解決了之前的問題；當然還有很多功能我用的不怎么多還不知道，
如果有同學想把這個問題作為備選，可以提前了解前端的埋點和監控平臺，
其實我覺得埋點的核心一個是前期將需要的資料通過介面上報，不管是用戶行為資料還是錯誤資訊資料；另一個是后期解決后確認是否該問題不會出現或者被控制在一定范圍內，
手動打包問題
我最早待過的一家公司是開發自己手動打包，然后將包發給運維部署，這很容易出錯，眾所周知，我們通常是拉分支做需求的，如果在做新需求時要切換到舊分支，流程繁瑣，很容易誤操作，存在安全隱患，也影響新需求的開發效率和進度，后來我們運維就自己搞了一套自動化構建的東西，當時我也沒有接觸，
后來換了一家公司，接觸到jenkins，才開始對自動化構建有一些了解，
如果崗位的JD有這方面的偏好，就可以從自動化構建、CICD方面做一些準備，
作業效率問題
一個是上述的手動打包問題可以說，還可以發揮的地方有，如果專案代碼過多，影響構建效率，當我們的代碼還在測驗階段時，有時候改bug可能要頻繁構建，如果構建慢就很影響測驗進度，甚至有時構建慢影響到緊急bug的修復上線，此時可以針對構建工具比如webpack做一些相關配置，相應的就是要對webpack的相關配置提前有所了解，
也可以說說單測，前提是去了解下常用的單元測驗工具，
還可以從代碼規范著手，講講eslint、husky等，提高團隊的協作效率；做學習作業方面的分享，提升技術的同時防止一些問題的重復發生；提取公用代碼，減少重復勞動，等等，
本文來自博客園，作者：beckyye，轉載請注明原文鏈接：https://www.cnblogs.com/halftonine/p/16914871.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/539524.html
標籤：其他