自如首創iOS圖片資源極致優化方案（一）

背景

iOS開發過程中對資源的管理業界沒有給出一個優質方案，於是大專案通過不斷迭代都會遇到包體過大的情況。包體瘦身便有了百家爭鳴的局面，瘦身的矛頭都指向了導致包體暴增的大boss：資源！但是沒有一個方案是可以解決病根的，自如另闢蹊徑，開創了資源管理系統新途徑，併成功拿到3項相關技術專利

資源管理通常遇到的問題

這裡的前提是工程已經元件化，不同元件通過路由管理，元件間0耦合，元件管理使用cocoapod

問題的產生原因

在日常開發中，我們接到需求之後如果有圖片就會匯入到工程，如果這個圖片經過迭代廢棄了，很多人是不會主動去刪除的，因為開發人員是不知道這個圖片是不是在其他地方有人在用，刪了可能引起嚴重丟圖bug！所有，業界很少有人主動刪圖，因此大量廢棄圖片導致包體日益增加

業界通常遇到的問題

問題：元件A裡面有圖片 x、y、z，元件B裡面有q、r、x，這時候圖片怎麼管理？ 方案1：把圖片和元件放在一起做成pod元件來使用，無論是通過bundle還是通過xcasset，都會出現圖片x重複。很多第三方都是這麼做，比如阿里的： 這裡面有倆問題 1，圖片可能和其他元件重複 2，圖片如果包含2x和3x，在出包的時候slicing就不會使用，xcasset本身在安裝到具體手機的時候會自動選擇使用2x還是3x，使用bundle或者指定asset目錄的形式會使蘋果的這一優化失效；另外，蘋果會對xcasset裡的png圖片進行最優壓縮，這一特性也會失效，從而導致包體無法縮減到最優狀態

方案2：使用一個獨立圖片元件，這個元件包括工程中所有的圖片 許多工程優化過程中經常會經過這個階段，所有圖片都放到一個pod元件庫裡面，作為一個基礎元件使用，這樣就可以解決圖片重複問題，而且圖片可以統一管理和統一壓縮，基本趨於完美的狀態。例如：元件A用到圖片 x、y、z，元件B用到q、r、x，圖片元件M包含 x、y、z、q、r，這樣只需要A依賴M，B依賴M，最終打包的時候僅包含這5張圖片就可以實現需求，圖片也沒有重複 這裡存在一個問題 1，如果公司還有另一個專案P1，P1需要用到B元件，這時候P1就會引入5張圖片！如果按需索取的話，應該僅僅引入q、r、x即可，這樣直接打破了元件跨app使用的通用性，資源完全耦合到這一個app裡了！

如果把所有圖片都放主工程xcasset裡，結果和方案2是一樣的

自如資源管理無敵方案

簡單來說，資源資源管理無敵方案就是雲端管理圖片和元件之間的關係，統計圖片使用次數，雲控3個月沒有使用記錄的圖片

以上是整體架構圖，裡面涉及到許多技術後面會慢慢講，先說下這裡如何解決的問題以及本方案的優勢

1，一般方案中圖片重複的問題，本方案圖片和元件建立一對一關係，通過雲端統一管理，不會出現重複問題 2，一般方案中的xcasset特性和slicing問題，本方案在打包期間實時從雲端拉取圖片，生成xcasset之後匯入到工程，這些優質特性都會生效 3，一般方案中跨app使用問題，本方案圖片和元件一對一對應，可以隨意遷移到其他app，而不會缺少圖片或圖片重複

由此可見，雲端管理系統可以解決市面上一般方案引起的一系列問題，除了解決這些問題之外，還可以統計圖片使用次數，根據使用次數來評估廢棄圖片；另外，雲端管理圖片可以延伸為管理資源，plist、音影片、webp等資源

自如資源管理系統研發歷程

圖片管理一期

圖片一期屬於頭腦風暴的開始，奠定了資源管理的基礎

我們要解決的難點一共倆： 1. iOS圖片一般使用UIImage imageNamed 同步方式讀取圖片，雲端管理之後如何不改變使用方式的情況下非同步下載圖片來使用 2. 如何找出每個元件對應哪些圖片

第一個問題是主要問題，如果實現不了非同步下載圖片和不改變原有使用方式，圖片管理這個事情就無法推動，圖片管理方案也就失去了意義。好在最終我們找到了方案！這個功能我們放到了圖片二期的時候來做，圖片一期主要解決問題2

找出工程中所有使用的圖片，包括圖片名稱是拼接的、圖片名是服務端控制的、圖片名是個變數等

找工程中的圖片幾種方法： 1. 根據查詢使用API的方式定位，比如：UIImage imageNamed 2. 匯出工程中所有的圖片資源作為工程中使用的圖片

我們使用的元件化方案是採用pod管理各個元件的，元件的圖片資源有的是放元件裡的、有的是通過圖片元件統一管理的、也有直接放主工程xcasset裡的，因此，我們面臨如何統計圖片資源的問題。

統計工程中的所有圖片方法： 1. 匯出工程使用的所有圖片到一個資料夾下（使用指令碼批量處理） 2. 每條業務線負責的元件都建立一個image_manager.txt檔案，存放本元件使用到的圖片。（這步有丟失圖片的可能，因為有些圖片可能是變數拼接的，由於人工疏忽而沒有寫入到image_manager.txt，但是測試階段很容易發現問題） 3. 我們要管理的資源定位是自研元件，因此無需考慮第三方圖片的情況

主工程作為特殊的元件處理，給主工程起一個工程ID名稱，比如ios_ziroom，主工程元件的名稱就是工程ID名稱。這樣主工程就可以跟元件一樣的處理和圖片之間的關係，每個元件收集完image_manager.txt之後，用指令碼在打包的時候彙總所有的image_manager.txt檔案內容，並且除重，得到的結果和工程中搜索到的資源進行對比，沒差異之後說明統計的圖片名稱和資源都能對上號了，這些工作是為了資源雲管理做的準備。

後期我們會對資源管理系統進行繼續詳細分享

自如大前端研發中心招募新同學！ FE/IOS/Android工程師看過來

公司福利有： 全額五險一金，並額外購買商業保險 免費健身房+年度體檢 公司附近租房9折優惠 每年2次晉升機會

辦公地點：北京酒仙橋普天實業科技園 歡迎對技術有執著熱愛的你加入我們！簡歷請投遞 [email protected]！