> [TOC] ## 🎈 為啥要禁止？ - 由於前端頁面會調用很多介面，有些介面會被別人爬蟲分析，**破解後獲取數據** - 為了 **杜絕** 這種情況，最簡單的方法就是禁止人家調試自己的前端代碼 禁止調試 ## 🎈 無限 debugger - 前端頁面防止調試的方法主要是通過不斷 `debu ...
轉載自：https://www.jianshu.com/p/8f423e52b5d1
最近剛完成了一個產品的熱更新功能，頗有感慨。趁著有點時間寫點東西，希望能對其他開發者有點幫助吧。
為什麼需要做熱更新？
這個問題不是本文的重點，但既然這篇文章是關於 React Native 熱更新的，就大概說一下吧。
- 快速發佈新版本。
或許有人會說，如果不計算打包和提交的工作，一個新包提交到應用商店後，通常在兩三天之內就會通過審核，慢的話通常不會超過一個星期，快的話24小時內就能通過審核，有必要去糾結這點時間麽？
其實不然。很多開發者應該都遇到過類似這樣的情形：一個新包剛提交或發佈沒多久，就發現了某個地方需要修改，或許僅僅是個樣式，又或者是個小Bug。是不是很頭痛？如果有了熱更新，那就好解決了。 - 做 A/B 面的產品。
因為某些原因（或許是某些不可描述的原因），需要讓應用商店的審核人員與真實的用戶看到的是不一樣的內容，以便快速通過審核。
綜上，這就是為什麼絕大部分React Native App都會做熱更新的主要原因。
4種React Native熱更新方案的比較
好吧，前面廢話了一下。現在進入正題。
在React Native項目中，常見的有四種做熱更新的方案。下麵一一對其進行介紹和比較。
1. CodePush
官網：https://appcenter.ms/
由鼎鼎大名的微軟出品，是App Center的一部分。如果不考慮穩定性，這絕對是不二選擇。但是非常可惜，因某些不可言表的原因，其服務在中國非常不穩定。
有人說不選擇CodePush的原因是因為它的伺服器在海外，速度慢。其實慢與快不是考慮的重點（除非慢到極端），一個React Native App的Js bound通常只有幾M，能達到20M的都是罕見的了，在如今的網路環境下，這根本就不是個事。所以考慮的重點其實是穩定性。
經本人在公司的網路環境下測試，發佈新版不成功的概率超過10%，更新不成功（無法連接、中斷、以及不知是何原因）的概率超過20%。這還僅僅是在一個網路環境下和某個時間段內，如果放大到全國和所有時間段，那這個概率應該還會提高。
因此，如果你的產品是面向海外用戶的，那麼就選擇CodePush，不用考慮其它。如果是面向國內用戶的，那麼不建議使用。
2. 中文社區的CodePush
官網：https://code-push.cn/
由CodePush中文社區出品。其實就是微軟的CodePush，將伺服器改在了國內，然後在用法上進行了一些封裝和簡化。我們公司現在用的是這個。之所以選擇它，是因為我最早測試的是微軟的CodePush，然後順理成章就選擇了這個。
其特點是使用簡單。雖然仍然是微軟的CodePush，但經過二次封裝，其用法要比微軟的CodePush更簡單直接。當然，之所以有這種感覺，也有可能是我在折騰微軟的CodePush時是剛開始接觸，而在使用中文社區的CodePush時已經有了前面的積累，所以就感覺上更簡單了。
3. Pushy
官網：https://pushy.reactnative.cn/
由React Native中文社區出品。正是由於微軟的CodePush在中國不穩定，所以促使中文社區的開發者們開發出了一些類似功能的服務。Pushy應該算是其中的佼佼者。
經在公司的網路環境下測試，其服務還算比較穩健。
從用法上來看，其實也能看到一些CodePush的影子。當然，熱更新功能最核心的無外乎就是上傳與更新，也不可能玩出朵花來。
對比中文社區的兩個產品，感覺中文社區的CodePush是在微軟的CodePush上做減法，而Pushy是在微軟的CodePush上做加法。
4. 自建CodePush伺服器
先說結論：自己玩玩可以，但如果要用在公司的產品上，強烈不建議。
還是由於微軟的CodePush在中國不穩定，所以網上有些文章介紹用一些開源項目搭建自己的CodePush伺服器。講真，我還真試過。下麵說說本人的一個小故事。
本人從參考網上的各種文章、自己動手嘗試、到最後選定方案並實現在公司的產品中，共用了約三天時間，所有這些工作由本人一個人完成，並得到了項目老大的表揚。後來我想，既然可以用開源項目自己搭CodePush伺服器，幹嘛不自己搭一個呢？於是在網上搜各種文章並照著做，感覺差不多了後，興衝衝地跑去找老大，本以為會再次得到表揚，沒想到老大說：自己公司的業務都忙不過來，幹嘛要花時間搞這個？幹這種事的都是閑得Q疼的。你能保障服務的穩健性麽？能承受多少用戶同時更新？。。。。。然後吧啦吧啦說了一大推，說得我直冒冷汗，感覺老大是感覺我太閑了。~_^
後來想想，確實如此。先不說網上那些開源項目是否經歷過商業產品的驗證，以及代碼質量如何，就算這些都沒問題，也不是放到伺服器上跑起來就行的。保障服務的穩健和大訪問量的可靠性也是一項專門的運維技術活。
開發成本、時間成本、運維成本、帶寬成本，這些都是開發中需要重點考慮的。
有些人（比如我們老大）下意識就能想到這些，而有些人（比如我）卻不一定。或許這就是一個開發人員成熟度的體現吧。
