最近我被 Neurobridge Tech. 聘為資深行動應用程式開發者，負責開發並領導其旗艦應用程式 Chanakya AI 的端到端產品開發！
想要查看這個應用程式嗎？
下載 Android
下載 iOS
目前他們的應用程式已經發布，使用者也相當活躍。但是當時應用程式的大小約為 75MB。因此我們自然遇到了一些性能、擴展性等問題，但我們將在下一篇文章中討論這些。
回到背景故事，根據行業標準，對於一個簡單的應用程式，若客戶端沒有複雜的處理或 30-40 個繁重的動畫畫面，應用程式的大小應該不超過 25MB；但是我們使用了伺服器端事件處理和一些進階功能，35MB 是可以接受的。
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lju9oqsef09jsbp993mg.png" width="100"/>
但我們卻面臨了一顆 75MB 的大塊頭小行星摧毀者！！
<br>
領悟....
我開始識別我們使用空間的地方。在仔細檢查之後（我被程式碼嚇到了），我發現整個應用程式需要以更好的程式編寫習慣和更優化的方式進行重構（有些東西已經無法拯救了）。
<br>
重構（但更好）
因此，在老的程式碼基礎上，我開始構建新的架構。
現在來到重點部分 -
<br>
1. 🛞 重新發明輪子
我注意到之前我們為功能創建了不同的畫面和元件，這些元件有 80% 是相同的（登入用戶和訪客用戶）。所以我開始將兩個流程合併，以減少程式碼基礎。
我刪除了超過 300 個檔案，將整個程式碼基礎減少了 75%（從 1500 行程式碼減少到約 350 行）。
始終要記住的一件事是，如果兩個或更多模組擁有超過 70% 的相同基本功能，將它們保留在單一來源中是更好的，同時維持條件執行。
<br>
2. 🖼️ 收集器
由於初創公司中的開發速度很快，我們經常忘記刪除任何不必要的檔案或資產，這些檔案或資產可能會使我們的應用程式變得臃腫。
我分析並模組化了所有圖像和資產，刪除了未使用的媒體，這導致了在打包資產時的大小減少。
<br>
3. ♾️ 領域擴展 - NPM 安裝
隨著經驗的增長，你會越來越意識到，如果可以手動完成，那就自己做吧。
不要成為那種人「兄弟，就再加一個模組，我隨時可以刪除它」。
對於每一件小事都使用 Node 模組，即使你自己可以做到，這並不好！這個壞傢伙有 3.5GB 的 Node 模組（是的，就是那個該死的 GigaByte）！
我不知怎麼會這樣，也真的不想知道！
我最關心的是在重構大部分功能和刪除未使用的鏈接模組的同時，將其減少到最低限度，因為本地鏈接模組即使在 JS 程式碼中未使用時仍會被打包。
<br>
4. 🦚 Geeta 方法 - 單一真相來源
在開發一個複雜且互相連結的應用程式時，我們往往會忘記使其模組化和更全球化。
之前我們所有值、方法、函式等都是直接硬編碼在位置上，這導致了額外的編譯和記憶體使用，最終造成了一個糟糕的產品。
我將每個可重用的項目（變數、字串、函式、數據處理器等）進行模組化，以確保所有內容僅初始化一次，然後可以通過引用使用。
<br>
✅ 結論
經過這次重構以及 兩週的小心編寫，我們終於將應用程式的大小從 75MB 減少到 34MB。
一個更小的應用程式不僅運行更快，還對用戶流量起著至關重要的作用。沒有人想要一個龐大的應用程式並且運行緩慢，每個人都希望保持其小巧、快速和靈活。
<br>
🎁 額外內容（為什麼不呢）
在將應用程式大小控制到最佳的同時，我還使整個應用程式 🚀 增加了 80% 的性能速度，並將網路請求減少到 50%，最終導致：
- 更好的伺服器健康
- 更少的載入時間
- 更少的開銷
- 更少的停機時間
- 更少的運行成本
- 可擴展性收益
- 低延遲
- 快速的 UI/UX 流程
聽起來不錯吧！？
請查看我的下一篇文章，看看我究竟使用了什麼來使系統在保持大小和依賴最小化的同時達到 80% 的效率！
<br>
感謝您的閱讀，夥伴們！
在評論中表達一些愛或問任何你想問的問題 :)
原文出處：https://dev.to/suyashdev/how-i-reduced-my-app-size-from-75mb-to-34mb--51m1
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式