圖源：unsplash
我在巴西一家P2P網絡借貸金融科技公司Mutual工作，具體的工作任務是幫助尋求公平利率的借款人與尋求高于市場回報的貸方聯系起來。我們的ReactNative IOS和Android應用程序被廣泛應用，在巴西國內的用戶量很大，可以通過各種設備下載。
然而，我們可以通過Facebook的設備-年份-類庫了解到：在給定設備型號的情況下，該庫會顯示出在哪一年該設備被視為高端設備。我們的大多數用戶使用的是低端設備。
例如，最受用戶歡迎的手機是三星Galaxy A10，雖然它在2019年3月推出，但在2013年被認為是一款高端手機。縱觀所有用戶的設備，其中85%在2015年或之前是高端產品。
因此，我們打算把重點放在優化應用程序上，這樣即使設備配置不怎么高端，我們的用戶也能獲得良好的體驗。
每年旗艦產品設備的百分比
我們最近仔細研究了一下應用程序的大小，在Android上的應用程序大小是26.8MB。雖然這個數字并不是很大，但絕對超過了同行的中位數，google Play控制臺報告的中位數是16.3MB。
對于那些由于數據計劃有限，可用磁盤空間很少甚至根本沒有，不得不選擇保留或卸載哪些應用程序的用戶來說，程序大小可能是一個決定因素。
這一點對于Mutual尤為重要，因為借款人必須通過該應用程序支付每月的分期款項。當借款人卸載該應用程序時，他們按時還款的機率會急劇下降，直接影響投資者在公司市場上的回報。
Mutual的應用程序（26.8 MB）比同類應用程序要大得多
應用程序的大小不僅影響卸載率，而且對安裝激活轉化率也有很大的影響。APK的大小每增加6 MB，安裝激活轉換率就會降低1%。
Google Play的一篇文章很深入地談到了這個問題（
https://medium.com/googleplaydev/shrinking-apks-growing-installs-5d3fcba23ce2）。在低端設備使用比例較大的發展中國家，這種影響甚至更大:在新興市場，如果應用程序的APK刪減10 MB，安裝激活轉換率就能增加約2.5%。
每個國家的APK大小每減少10MB，安裝激活轉換率的增加
因此，必須在不降低用戶體驗的前提下，盡可能地縮小應用程序大小。我們要做的第一步是查看Android開發人員可用的官方資源。
Android App Bundle
這一部分表明縮小應用程序大小的最簡單方法是嘗試新的Android App Bundle(AAB)分發方法。在此之前，我們一直在編譯一個可以在大多數Android設備中運行的舊Android Package(APK)文件，并將其上傳到Google Play控制臺來分發應用程序。
然而，AAB包只包含編譯過的代碼和資源。因此，上傳時，通過了解其規格和CPU架構，Google Play本身就會為每種設備類型生成一個優化的APK。
圖源：unsplash
所以只要對構建管道做一個簡單的改變，就可以免費獲得縮減程序大小的好處！
在瀏覽了這篇文章之后，我們修改其React Native Gradle構建腳本去運行bundleRelease，而不是當前的assembleRelease。就這樣，我們有了AAB文件。
在對FastlaneConfig的supply進行了一些更深一步的修改之后，就可以直接自動上傳到Play Store了，新版本將會出現在Google Play控制臺上。通過這一改變，我們將已交付的APK大小縮減了9.1MB~12.4MB！
舊的APK為26.8 MB，而新的AAB為14.4至17.7 MB
但是要小心：如果在Hermes中使用React Native，那么可能要根據這個問題更新soloader依賴，否則就有可能讓用戶使用到一個有嚴重錯誤的應用程序。
好在我們能夠通過在alpha發布軌道中的測試捕捉到這個問題。但它可能很容易通過，因為它不會在本地或建立一個APK時出現。
使用Android Size Analyzer優化資產
下一個建議是Android Size Analyzer。這是一個命令行工具，可以分析一個Android應用程序，指出可以對尺寸進行多少縮減。
在使用命令size-analyzercheck-bundle[BUNDLE]運行它之后，會收到一個可以優化的大型資產和映像列表，還包括配置ProGuard。
size-analyzer命令的輸出
Proguard
Proguard是一個壓縮、模糊和優化JAVA字節碼的工具。因為已經了解到可能與其他Android庫不兼容，所以我們還沒有探索這一途徑。我們正在尋找快速而容易的縮減的方法，未來可再進行優化。
大型資產
使用-d標志再次運行該命令，將得到按大小排序的每個資產的列表。由于size-analyzer工具不知道應用程序的用戶流，它讓我們決定哪些可以刪除或動態捆綁。
按大小排序的大型資產列表
第一個也是最大的項目是React Native JavaScript包。目前還不可能拆分和動態加載，但是將在稍后看到如何縮小它。沿著建議列表進一步向下，我們看到許多大型字體（TTF）和圖像（JPG和PNG）資產。
不需要的圖片
內部Storybook工具中使用的四張巨大的JPG圖片吸引了我們的注意力。他們給生產APK增加了額外的2MB垃圾！
在軟件工程這個復雜的世界里，人人都會犯錯誤。我相信與同行分享這些經驗時，大家都可以從這里學習到很多。如果不跟蹤應用程序不斷增長的規模，很可能也會犯這些失誤。
字體
在迅速擺脫這些大圖之后，我們不斷地查看列表的其余部分。很明顯，有大量的字體被捆綁。在與設計團隊交談后，他們告訴我們許多舊組件沒有嚴格遵循排版指南。
圖源：unsplash
所以我們確定了哪些組件可以被移除，哪些可以使用類似的更新字體。通過此法，我們把字體的使用從六個減少到四個。
另一個問題是字體資產大小巨大無比！每個字體大小幾乎達到了670KB。這意味著四種字體占了未壓縮包高達2.7MB的大小。
有一個名為FontForge的工具，可以更深入地查看和修改這些字體文件。打開后可以看到大部分的資產規模可以用擴展的西里爾文字和其他不需要的字形來解釋。這些都可以被刪除，因為應用程序完全是葡萄牙語。
隨著這一變化，每個字體大小從670KB縮小到70KB，減少了90%！
字體中包含的一些字形的示例
刪除不需要的字體并優化剩余的字體總共減少了3.8 MB，這意味著最終APK的大小減少了2 MB。
刪除兩個字體并優化剩余字體前后對比
優化圖像
在剩下的圖像中有一些是相當大的。我們通過圖像優化工具（tinyjpg）優化了其中的幾個，大小縮減了很多。之后，我們決定優化應用程序內使用的所有41個JPG和PNG資產。
優化的圖像的前后
這使圖像資產從2.5MB減少到756 KB，減少了70%。但是圖像本身沒有優化，在生成最終APK的過程中已經被壓縮了。因此，實際上只為最終用戶削減了500 KB。
在這之后，我們意識到已經耗盡了所有容易的hanging fruit optimizations。所有進一步的資產優化要么需要更多的努力，要么只會帶來很小的改進。
優化React Native JavaScript bundle
已經看完了native資產，現在是時候分析JavaScript包了。這是一件特別值得優化的事情，原因有三：
· 首先，它減小了成品APK的bundle大小；
· 其次，由于JS虛擬機解析更少的代碼，所以能進行更快的應用程序啟動；
· 最后，也是最重要的一點是，它加快了每周通過CodePush多次發布的空中（OTA）更新的速度。
Bundle analyzer
要決定將如何減少bundle的大小，首先，需要能夠看到什么占用了最多的空間。為此，我們將依靠另一個優秀的開源工具：
react-native-bundle-visualizer。在項目運行時，得到了應用程序的每個文件夾和依賴項以及它們各自大小的可視化。
Mutual前端代碼庫的庫和文件夾的展示及其大小
應用程序包總共有5.49MB，其中57.8%來自node_modules依賴項，27.5%來自應用程序代碼，其余部分是工具無法映射的。捆綁過程已經移除了未使用的代碼路徑，在這里看到的是應用程序實際使用的代碼。即便如此，總還有改進的空間。
最大的依賴項是math.js，顧名思義，它實現了許多數學運算。我們應該不需要這種依賴項，因為在服務器中執行所有敏感的計算，然后只需將結果發送給應用程序。
仔細查看前端代碼，可以發現庫用于一些簡單的操作。很有可能是一個同樣從事過后端代碼開發者出于習慣而使用它。我們迅速地從庫中提取了這些方法，并將其納入代碼庫，完全消除了此依賴項。這將捆綁包的大小降至4.64MB。移除一個lib之后，大小縮減了15.5%！
圖源：unsplash
如前所述，我們使用Storybook獨立地開發和測試組件。但是，它應該只在本地和臨時環境中可用。任何最終用戶都不能看到它。
正因為如此，我們使用一個環境變量來控制是否啟用App的這一部分。雖然這對于限制訪問有效，但捆綁程序無法知道該變量的值。由于這個限制，所有的Storybook代碼最終都要放入到production bundle中去。
為了解決這個問題，將此部分的導入隔離到單個文件中。然后創建了該文件的兩個版本：一個包含Storybook，另一個用于生產，只有一個虛擬組件。為了在面向生產時在這些文件之間切換，編寫了一個腳本，該腳本在交換兩個文件的綁定步驟之前運行。
通過這種方法，我們能夠從生產中完全刪除Storybook代碼路徑，消除node_modules依賴項以及內部配置的所有代碼。
更新之后帶有兩個版本索引文件的storybook文件
通過這兩項更改，能夠將bundle大小從5.49MB縮減到4.2MB。這意味著用戶將擁有更快的應用程序啟動速度和更新下載速度。
bundle最終大小為4.2MB
在所有這些改進之后，我們再次將應用程序上傳到了Play商店。最終的APK大小將在10.5到13.7MB之間，從最初的26.8MB減少了60%！按照Google Play團隊的文章，這可以將安裝激活轉化率提高3.75%。
最初的APK和經過所有改進的最終AAB版本之間的比較
作為面向業務的軟件工程師，我們知道對公司來說最好的決定就是積累技術債務來更快地更新迭代產品。對于像Mutual這樣試圖找到產品與市場契合點的初創公司來說，情況尤其如此。
但是如果不監控這個債務，可能會犯一些大錯誤，比如捆綁2MB的測試圖片和使用一個不必要的巨大的庫。這也是常見的隧道視野，快速和容易的機會優化已有的。
圖源：unsplash
所以需要定期后退一步。確保不會錯過對應用程序的大小、速度或任何方面的快速改進。我們只花了兩天的時間來分析、規劃和執行上述所有的改進，這些改進使應用程序的大小縮減了60%。
這么小的努力，解決困擾已久的難題，帶來這么多實實在在的效果，這真的很驚人。
