WebAssembly
看一下WebAssembly的來源，JIT的出現確實帶來了可觀的性能提升，但是受限於JS動態類型和運行時編譯的特點，判斷類型成爲了限制JIT的一個重要因素。對此Mozilla提出了asm.js，通過註解和檢測等手段確保強類型，減少JS依據上下文判斷類型的損耗，優化機器碼的解釋過程。
後來各家各戶覺得Mozilla這思路挺好，於是聯合起來，設定了WebAssembly，即一份字節碼標準，以字節碼的形式依賴虛擬機在瀏覽器中運行。
首先要明確的一點，WASM並不能達到Assembly的性能，它只是一種約定的字節碼，既然是字節碼，肯定還是需要解釋器翻譯成機器碼執行。它的優點是相對於JS字節碼，它的翻譯速度要快上許多。
其次對於CPU密集型任務，WASM也只是多提供了一種選擇，有些時候使用WEBGL來做GPU加速往往是更好的選擇。
最後，並不是指使用WASM就一定比JS快，V8使用的JIT有個很重要的優點，就是它會對熱點代碼進行抽取，直接編譯生成二進制機器碼方便接下來的調用。
options
今天查看自己網址的options請求時發現找不到，查了資料發現chrome需要更改一個設置：
chrome://flags/#out-of-blink-cors
因爲是瀏覽器的緣故，用火狐還是可以看到的。
一個this題
var length = 10;
function fn(){
console.log(this.length)
}
var obj = {
length:5,
method: function(fn){
fn()
arguments[0]()
}
}
首先會輸出10是沒有什麼異議的，因爲函數傳參，this丟失。
其次因爲arguments[0]其實也是代指fn，但是因爲是arguments調用的函數，因此這裏的this指向的是arguments。它的length自然是2了。
Promise.prototype.finally
之前對finally理解有偏頗，一直以爲是和resolve一樣的靜態方法，這次終於發現原來也是個實例方法。
無論當前 Promise 是成功還是失敗，調用finally之後都會執行 finally 中傳入的函數，並且將值原封不動的往下傳。
做個題吧LeetCode300
給定一個無序的整數數組，找到其中最長上升子序列的長度。
示例:
輸入: [10,9,2,5,3,7,101,18]
輸出: 4
解釋: 最長的上升子序列是 [2,3,7,101]，它的長度是 4。
dp的題，列方程，首先我們找到i之前的最大序列，設它的最大值爲j，dp[j]即爲i爲j時的答案。
我們當i>j時，我們若想要arr[i]能夠連接到arr[j]後面，必須要滿足arr[i]>arr[j]，因此：
var lengthOfLIS = function(nums) {
if(!nums.length) return 0
let res = new Array(nums.length).fill(1)
for(let i = 0;i<nums.length;i++){
for(let j = 0;j<i;j++){
if(nums[i]>nums[j]) res[i]=Math.max(res[i],res[j]+1)
}
}
return Math.max(...res)
};
總結
有點焦慮，做題加複習來緩解。抽空還要彙總起來，現在知識點太零散，對自己複查和他人看都不方便。但是最近確實是查缺補漏的狀態，先這樣寫了。