android設計方案

1. IOS與Android的UI設配方案

IOS與Android共用一套設計效果圖 1242*2208

IOS與 Android常用的尺寸中，最大尺寸為6p的尺寸，即1242*2208px

IOS常用尺寸： 1242*2208    750*1334    640*1136    640*960，其中750*1334    640*1136    640*960 同為@2x    1242*2208為@3x，所以750*1334    640*1136    640*960隻做一套640*1136就好。

Android 常用尺寸：1080*1920    720*1080    480*800，他們之間相鄰是可以整除1.5的，也就是1080除以1.5等於720,720除以1.5等於480，即這三個尺寸可以等比縮放大小，只做一套1080*1920就可以。

那麼問題來了。

IOS要做兩套尺寸，1242*2208與640*1136

Android要做一套尺寸，1080*1920

這樣不就是三套設計圖了嗎？設計師們會被氣死的？

其實，6p的尺寸1242*2208整除1.15就剛好就等於1080*1920，也就是說，1242*2208與1080*1920是可以等比縮放的。

現在就剩下IOS的640*1136。

那麼就有人問，那IOS的1242*2208可以直接等比縮放成640*1136。答案是不可以的，因為他們之間不能整除的，但是我們把1242*2208的設計圖直接在Photoshop裡面直接等不縮放到寬度為640的尺寸，我們會發現原本的2208變成了1138，也就是說比1136多了2個像素，2個像素的誤差對於沒有有強迫證的也就無所謂了，2個像素的誤差我們會將1138硬改成1136，現在你會發現，裡面的圖標，1136跟1138大小其實是一樣。

為什麼提到圖標呢？因為我們交付的物只需要一套效果圖與五套切圖就好了。即

一套效果圖   1242*2208

五套切圖  1242*2208   640*1136   1080*1920   720*1080   480*800

最後注意縮放的圖標要細調一下，由於轉換有誤差，共用一套效果圖是有一定風險的，例如UI細節上的風險。開發前，設計師與開發人員要先共同確認此適配方案，要全程溝通，及時改正UI方面的問題。

IOS與Android共用一套設計效果圖 750*1334

上面提到過，750*1334    640*1136    640*960 同為@2x，所以750跟640用同一套圖標，同一套字體，至於其他尺寸大小，只要跟著尺寸延伸就沒問題啦。尺寸750*1334應用1242*2208，則需要把@2x導出成@3x，也就是把字體放大1.5倍，其餘的直接放到1242就可以啦。

至於Android版本，我個人的做法是把750*1334直接換算成1080*1920，因為只有1PX像素只差，直接忽略。換算出1080*1920，Android的其他尺寸就按他們之間的規律處理就可以啦。

因為我們交付的物只需要一套效果圖與五套切圖就好了。即

一套效果圖   750*1334

五套切圖  1242*2208   640*1136   1080*1920   720*1080   480*800

IOS與Android各做兩套設計效果圖 

原理跟方案一、二差不多，但為了追求細節上的完美，可以多做一套設計圖，即兩套設計圖：1242*2208和640*1136.

1242*2208適配6P、Android三種尺寸。

1242*2208整除1.5等於1080*1920：

1080*1920整除1.5等於720*1280：

720*1280整除1.5等於480*800：

640*1136適配6 5 5S等尺寸。

如果追求完美，那就需要三套圖。即:

1242*2208       640*1136       1080*1920 

還可以加上一套640*960,總之分開做越多套，出來的效果圖就會越精細，反之，你懂得，不過這也取決設計師本人和公司領導的決策，會不會給那麼多時間。不說廢話了，希望能幫到各位！

2. android界面設計有什麼好的方案

• 多看android官方規范，靈活使用8dp（一般間距）與48dp（一般可觸摸區域）。
  

• 靈活使用點九切圖。圖標與按鈕分開切，字全讓研發自己輸入。千萬不要切死圖。
  

• 早期的時候跟研發約好時間。比如某個半天，你弄個筆記本，跟研發坐一起，嚴格的把你的規范執行下去，後期大家合作起來就方便了。
  

• 圖一定要像素級別（包括720的圖標），所有錨點都優化好。
  

• 還是研發吧，沒事多往那邊跑，帶點乾果花生什麼的一邊吃一邊改。他是怎麼實現的，你一定要問清楚，你想怎麼實現，你也得跟他講清楚。
  

• 仍然還是研發，他們不怕麻煩，只是怕做好後又改。所以不要老讓他們嘗試，自己多做效果圖，嚴謹一點，多用axure把效果圖轉手機里看看。
  

• 做一個UI套件（dribbble上搜索UI kit看下別人怎麼做的），後期你也會方便很多，重要的是交接工作會很好。

• 多看知乎，有些關於ps的技巧，作圖技巧還蠻實用的。

3. 安卓APP的主要開發原理以及其主要過程是什麼

開發原理：

Android應用程序是用Java語言編寫的。編譯過後的位元組碼，以及應用程序要求的其他數據和資源文件，通過aapt工具被綁定在一起，稱為 Android包，這是一個帶.apk後綴的檔案文件。這個文件也是用戶下載到他們設備上的文件。所有的代碼在一個單一的.apk文件中，組成一個「應用程序」。

主要過程：

1、需求分析：

大部分創業型項目在這個階段只是一些比較抽象的想法。有一份相對完善的需求文檔，不僅有助於創業者自身對項目的理解和周全性分析，如果項目是交由設計公司去完成的話，也更有利於對方准確把握項目的定位和商業模式，以便給出專業的建議和解決方案。

2、原型設計

接下來會根據上面提到的具體需求文檔，項目經理進行會進行原型圖的設計。

3、UI設計

原型圖經過反復推敲修正後，UI 設計師會進行UI界面相關的配色設計、功能具象化處理、交互設計、以及各種機型、系統的適配。UI 設計師經過多次與項目經理溝通修改後，最終的到定稿的高保真設計圖。

4、開發

經過以上幾個過程之後，會正式進入到開發階段。

5、測試調試

APP 功能開發完成之後，測試人員會對整項目進行系統性測試。這個環節會調動起項目組內所有人相關人員。而測試這個環節的重要性不亞於前期功能的規劃，如果團隊沒有經過專業系統性訓練的測試人員，很可能會導致項目出現與設計初衷存在落差，以及遺漏下一些邏輯上的坑。

6、發布app

經過至少兩輪的內部測試以及小范圍外測（或者完成滿足測試要求的周期）後，會進行最終版本的上架。

(3)android設計方案擴展閱讀

APP開發工具

1、MOTODEV Studio for Android

MOTODEV Studio for Android，這是基於Android的開發環境，為開發者們提供新的MOTODEV App Accelerator Program使他們可以開發出更適合摩托羅拉Android手機的應用程序。

2、J2ME開發插件 Mobile Tools for Java

Mobile Tools for Java (MTJ) 是Nokia公司開發的一款 Eclipse插件，用於支持 Java 手機應用程序開發。其前身就是大名鼎鼎的 EclipseME。

3、apk文件修改工具 Root Tools

RootTools是一個新的工具軟體，Android開發者可以在這一工具軟體的支持下，對.apk格式的文件進行再次修改，讓程序表現更加出色，滿足用戶的需求。Root Tools裡面自帶有很多工具，比如BusyBox，它裡面集成壓縮了很多Linux的工具和命令，這樣軟體開發者在對....

4、IDEA的Android開發插件 idea-android

idea-android 是在 IDEA 集成開發環境中開發 Android 應用程序的插件。

參考資料

網路-app開發

4. 如何製作一個安卓版的APP軟體方案

一、打開速度快
開發者的任何一行代碼都可能延遲應用的響應時間，對於這方面的解決方案的話，就是代碼的優化方面了， 比如說內存優化、UI的優化、載入圖片時的優化等都是項目成功的關鍵，在很多公司開發的產品中，一大部分的應用基本上都是用演算法來進行優化的，這也就是很多開發者，無論是對於哪個領域哪個行業 來說，只要你演算法學的精通，那麼也就不愁你的項目性能上的問題了，一款成功的應用=好的創意+好的設計+高質量代碼，雖說的比較籠統，但這幾環也是環環相扣的。
二、用戶體驗好
開發一款安卓APP應用軟體的最終目的就是為了迎合大眾的胃口從而贏得用戶的親睞，所以用戶體驗是必不可少的功能。如果你下載了一款應用，花費了很長一段時間在程序的啟動上，你會等待嗎？或者說這款手機安卓APP客戶端應用軟體在真正運行的時候，突然卡死了，然而再也無法啟動了，你還會選擇繼續使用嗎，然而換做用戶的角度思考遇到這種類似的問題，一般都會選擇卸載，所以用戶體驗的質量決定了這塊APP的成敗。失去了用戶，開發的APP也就失去了價值！
三、關注可用性和響應性能
響應性能，這也是影響手機安卓app的一個重要的因素，對每個開發APP的開發商來說，都不希望APP開發出來後，會因為響應性能受到影響，解決這個問題的唯一辦法就是在開發APP的過程中開發技術人員要做好基礎性的工作，不斷的對項目進行優化。讓項目做的更為精緻。其實我們的每一次努力和優化都是在逐步的完善和改進APP的不足，不要在你還不容易成功的開發出了一款安卓APP手機客戶端，然後卻輸在了APP的運行上，那樣就太不劃算了。
因此在開發手機APP安卓版客戶端時，我們會遇到的問題還有很多基於條件有限，不能跟您一一講述，但是以上的三點因素絕對是決定您的APP能夠開發成功的關鍵，所以廣大開發商應該尤為重視。

5. Android設備的界面適配設計

Android設備App設計中有一個問題可能會被設計師忽略，在各種解析度各種尺寸「雜屏」的界面適配。可能產出的界面稿在常用的720*1280的解析度中是完美，但一到各個不同解析度不同尺寸的設備後

這里就談談適配，了解適配讓設計從PS、sketch到移動設備上都能完美呈現。

如此繁雜的安卓設備，採用哪個標准設計呢？

1.選擇一種尺寸一種解析度作為基準。

2.選擇2-3款主流的Android設備，制定一套適配規則。（國內主流設備、解析度可參考友盟指數）

3.部分極端效果特別注釋說明。

目前移動端設計師多採用iPhone 5與6的解析度設計，這兩個解析度也最接近Android xhdpi的720*1280，設計之後再做等比適配（不做設計元素等比適配會導致Android設備上視覺呈現較小）。

我則傾向於選取720*1280的解析度設計。優點是處於常用解析度的中間值，對小解析度大解析度調整也較容易。另外iOS@1x的320與720剛好是2.25的倍率關系，使用sketch等比輸出快捷多了。（如果時間成本允許的話可以將Android的標注單位用dp，具體的設備尺寸、解析度知識這里不詳描述，可見文章最後面的「Android基礎知識」）

案例說明：

雅虎新聞為各個dpi做了優化，圖片等比縮放，文字區域等比縮放，並且考慮到在低dpi下會被推移至第二屏，就減小圖片了高度，保持文字區域最小高度。

老司機都不會忘記的，僅提醒下新手，每個圖標記得輸出多個比例。並且記得查看各個比例下圖標的顯示效果。

案例說明：

還是拿一個雅虎新聞的例子，大家感受下。

Android設備的系統各個廠商都做了定製化，默認的字體庫可能不同，且字體占空間大小可能不同。不同設備顯示文字會出現不同效果。設計時考慮3點：

多採用流式布局，不對單行做字數限制（如「單行顯示多少個字」「文本寬度多少」），而是定義文本容器的高寬，超出則用「…」「漸隱」或者「遮擋」等方式省略。

若較長的文本需要完整顯示，設計時預留換行空間。

若文本需要在單行完整顯示（如提示類文字），盡量控制字數（建議16字內），避免小屏不夠放置。

案例說明：

圖文混排同一行顯示時，圖片等比固定在右側顯示，文字部分區域寬度會因設備不同出現較大的差異，預留文字多行高度。如下圖不同設備下文字的展示空間有差異，需要考慮小解析度下預留多行文字空間。如圖2第二條新聞標題文字溢出的醜陋展示，建議設定一個文字區域最大高度，超出部分則隱藏。

單行出現多個文字元素時，注意元素在低dpi下的顯示層級，提前說明好該情況的覆蓋或者隱藏規則。如下圖第一個用戶名稱，在低dpi下，避免各元素交錯，而省略了超出的用戶名稱。

圖片常用的方式有固定寬度dp等比縮放高度（用於非通欄圖片）；固定高度dp等比縮放寬度（用於橫向滾動圖片，如全屏相冊中的縱向圖片）；根據屏幕寬度等比縮放（橫向通欄圖片）。設計時考慮3點：

注意圖片佔用的寬高比，避免大屏設備上占據大量空間，導致內容比例不協調同時降低了屏幕利用率。

考慮到設備屏幕密度不同，輸出圖片時別忘了輸出多個解析度。

考慮圖片寬高比過大的縮略圖處理（最常見的處理方式：高度遠大於寬度時，是給出最大區域，讓圖片等寬居中填充該區域，只顯示該區域；寬度遠大於高度時，與展示區域等高居中取部分顯示。當然也可能出現特殊顯示要求，需要根據具體情況具體處理。）

案例說明：

網易游戲相冊的全屏瀏覽中，大於設備寬高比的寬圖按照最大寬度放置，小於設備寬高比的高度按照最大高度放置。

一行多張圖片要考慮圖片的在不同設備下等比縮放帶來顯示效果的差異。排列時會有兩種情況：

1.要求在一行內顯示完，根據圖片的顯示效果決定放置的數量，超過則不顯示（如下圖1第二條新聞）

2.流式布局，當圖片寬度小於設定值時自動換行（如下圖2相冊展示，低dpi低解析度設備一行顯示3張，高的顯示4-5張，且按比例撐滿屏幕寬度）。

寬高比超出設計區域時的處理，如網路貼吧中列表的小圖模式，給出了正方形區域，當圖片非正方形時，根據寬高中的短邊等比撐滿正方形區域後，截取了圖片居中的部分顯示。

在固定區域內多元素混合放置時，文字一般採取流式布局，圖片多採用等比縮放，圖標元素多採用 彈性布局，即元素內容本身規格不變，考慮水平、垂直方向的間距做相應擴展。設備屏幕越大，在擴展方向上可以顯示更多內容，發揮了大屏幕的優勢。

彈性布局需要給出哪一個元素dp不變，哪一個元素縮放的策略。

彈性布局下部分距離標注採用百分比標注。

當有兩個等比縮放元素時考慮避免重疊的情況。

案例說明：

網易游戲的新聞列表樣式，每一條新聞區域，要求圖片dp不變，而文字區域進行彈性縮放。

下圖網易游戲專區中間的幽靈按鈕圖標為確保點按效果，按照固定dp顯示，中間間隔的寬度按照設備寬度的百分比來確定

網易游戲求交往的界面，中間卡片區域大小根據設備等比縮放，如中間用戶頭像與「同喜歡2款游戲」的文字，在設計時需要考慮產品的目標設備中最小設備下的布局顯示效果，避免出現重疊的情況。而縱向的元素數量也需要如此考慮。

Android界面適配的案例說明就寫到這里啦。

設計時多考慮各個元素（圖標、文本、圖片、區域）在不同設備的情況。當然，做設計時也不是死板的按照建議來實現，特別是固定區域下的元素放置，根據實際情況來處理即可。

Android系統的UI也在不斷進化完善，隨著設計趨勢的改變，Android除了常見的卡片、列表、浮層外，可能會有更多的展示方式，而Android設備也是逐漸淘汰ldpi與mdpi，設備的解析度逐漸變大。也就要求我們需要不斷的去了解嘗試新的設計趨勢，產出最好的方案。

這不是彩蛋哈，僅僅補充安卓設備的基礎知識，老司機完全可以忽略，供新手參考閱讀。

為展示設備的多樣化，貼出Android屏幕尺寸示意圖（藍色矩形的大小代表不同尺寸，顏色深淺則代表所佔百分比的大小。）

屏幕大小以屏幕尺寸來衡量，指屏幕的對角線的長度，單位是英寸，1英寸=2.54厘米

目前的主流尺寸：5.0" ~ 5.5" (有繼續往更大尺寸發展的趨勢，但趨於穩定)

常見的設備尺寸： 4" ~ 10" 。

手機適配參考尺寸： 4" ~ 6"

手機 + 平板適配參考尺寸： 4" ~ 10」

屏幕解析度是指在橫縱向上的像素點數，單位是px，1px=1個像素點。一般以縱向像素*橫向像素，如1960*1080。

屏幕像素密度是指每英寸上的像素點數，單位是dpi，即「dot per inch」的縮寫。目前每個屏幕像素可以認為就是一個「點」。

屏幕 dpi 的計算方式:

Android 設備中 dpi 分幾個段：

•ldpi：~ 120 dpi (幾乎絕跡)

•mdpi：~ 160 dpi (罕見)

•hdpi：~ 240 dpi (逐漸減少中)

•xhdpi：~ 320 dpi

•xxhdpi：~ 480 dpi

•xxxhdpi：~ 640dpi (目前較少)

dp(與 dip 同義) 是在 160dpi 下每個像素對應的物理尺寸，可近似理解為:

•160 dp = 1 inch

•1 dp = 1 / 160 inch = 0.15875 mm

•1 dp = 1 px (160 dpi 屏幕下)

•1 dp = 2 px (320 dpi 屏幕下)

Android的屏幕適配指標都基於物理尺寸（即屏幕的物理大小），而非像素（解析度）。為什麼呢？這里根據dp與px適配出兩種效果來說明。

按 dp 適配不同屏幕的效果如下，內容的物理尺寸變化不大:

若直接按照像素適配，出現以下情況，高像素密度的設備內容顯得特別小，影響布局與可用性：

屏幕長邊和短邊的比例。

目前手持設備的 長邊 dpi 和 短邊 dpi 普遍非常接近，可認為屏幕比例和屏幕水平、垂直像素比例一致

屏幕比例目前趨於 16:9 ~ 16:10 (8:5)

因不少設備使用了虛擬按鍵，所以通常非全屏的 app 可用面積略低，屏幕比例更接近 16:10

6. android開發框架有哪些

主要總結了7個好用的android 開發框架推薦給你：

一、 Afinal

Afinal是一個Android的ioc，orm框架，內置了四大模塊功能：,FinalBitmap,FinalDb,FinalHttp。通過，我們可以通過註解的方式進行綁定ui和事件。通過finalBitmap，我們可以方便的載入bitmap圖片，而無需考慮oom等問題。通過finalDB模塊，我們一行代碼就可以對android的sqlite資料庫進行增刪改查。通過FinalHttp模塊，我們可以以ajax形式請求http數據。

功能：

一個android的ioc，orm框架，內置了四大模塊功能：,FinalBitmap,FinalDb,FinalHttp。通過，我們可以通過註解的方式進行綁定ui和事件。通過finalBitmap，我們可以方便的載入bitmap圖片，而無需考慮oom等問題。通過finalDB模塊，我們一行代碼就可以對android的sqlite資料庫進行增刪改查。通過FinalHttp模塊，我們可遲戚以以ajax形式請求http數據。

優點：功能比較全面，文檔完善，代碼效率比較高。

缺點：沒有項目demo，框架的時間比較久，代碼冗餘比較多(這也是無可避免的)，文檔比較老跟不上代碼更新進度。

二、 xUtils

xUtils：可以說是Afinal的升級版。

xUtils 包含了簡旦陪很多實用的android工具。

xUtils 支持大文件上傳，更全面的http請求協議支持(10種謂詞)，擁有更加靈活的ORM，更多的事件註解支持且不受混淆影響...

xUitls 最低兼容android 2.2 (api level 8)

三、

是一個免費的開源的、簡易的、遵循Apache2開源協議發布的Android開發框架，其開發宗旨是簡單、快速的進行Android應用程序的開發，包含Android

mvc、簡易sqlite orm、ioc模塊、封裝Android

httpclitent的http模塊,具有快速構建文件緩存功能，無需考慮緩存文件的格式，都可以非常輕松的實現緩存，它還基於文件緩存模塊實現了圖片緩存功能，在android中載入的圖片的時候，對oom的問題，和對載入圖片錯位的問題都輕易解決。他還包括了一個手機開發中經常應用的實用工具類，如日誌管理，配置文件管理，android下載器模塊，網路切換檢測等等工具

四、 LoonAndroid

如果你想看ui方面的東西，這里沒有，想要看牛逼的效果這里也沒有。這只是純實現功能的框架，它的目標是節省代碼量，降低耦合，讓代碼層次看起來更清晰。整個框架一部分是網上的，一部分是我改的，為了適應我的編碼習慣，還有一部分像orm完全是網上的組件。在此感謝那些朋友們。

整個框架式的初衷是為了偷懶，之前都是一個功能一個jar，做項目的時候拉進去，這樣對於我來說依然還是比較麻煩。最後就導致我把所有的jar做成了一個工具集合包。

有很多框架都含有這個工具集合里的功能，這些不一定都好用，因為這是根據我個人使用喜歡來實現的，如果你們有自己的想法，可以自己把架包解壓了以後，源碼拉出來改動下。

目前很多框架都用到了註解，除了沒有入侵我們應用的代碼以外，其他的基本上都有，要麼是必須繼承框架裡面的activity,要麼是必須在activity的oncreat裡面調用某個方法。

整個框架式不同於，Roboguice等ioc框架，這是一個類似spring的實現方式。在整應用的生命周期中找到切入點，然後對activity的生命周期進行攔截，然後插入自己的功能。

五、

又叫KJLibrary，是一個android的orm 和 ioc

框架。同時封裝了android中的Bitmap與Http操作的框架，使其更加簡單易用;

的設計思想是通過封裝Android原生SDK中復雜的復雜操作而達到簡化Android應用級開發，最終實現快速而又安全的開發APP。我們提倡用最少的代碼，完成最多的操作，用最高的效率，完成最復雜的功能。

功能：

一個android的orm 和 ioc 框架。同時封裝了android中的Bitmap與Http操作的框架，使其更加簡單易用;

開發框架的設計思想是通過封攔蠢裝Android原生SDK中復雜的復雜操作而達到簡化Android應用級開發，最終實現快速而又安全的開發APP。總共分為五大模塊：UILibrary，HttpLibrary，DBLibrary。

六、 dhroid

dhroid 是基於android 平台,

極速開發框架，其核心設計目標是開發迅速、代碼量少、學習簡單、功能強大、輕量級、易擴展.使你更快,更好的開發商業級別應用

功能：

1.Ioc容器: (用過spring的都知道)視圖注入,對象注入,介面注入,解決類依賴關系

2.Eventbus: android平台事件匯流排框架,獨創延時事件,事件管理輕松

3.Dhnet: 網路http請求的解決方案,使用簡單,減少代碼,自帶多種網路訪問緩存策略

4.adapter模塊: 數據綁定輕松,不用寫多餘的adapter,天生網路支持(一行代碼搞定載入,刷新問題)

5.DhDb: android中sqlite的最輕量orm框架(增刪改查輕松搞定)

6.Perference: android自帶Perference 升級版,讓你的Perference更強大,更方便

工具集合 JSONUtil(安全處理json),ViewUtil(數據綁定更快) (非同步任務工具)...

七、

SmartAndroid是一套給

Android開發者使用的應用程序開發框架和工具包。它提供一套豐富的標准庫以及簡單的介面和邏輯結構，其目的是使開發人員更快速地進行項目開發。使用

SmartAndroid可以減少代碼的編寫量，並將你的精力投入到項目的創造性開發上。

功能：

SmartAndroid 擁有全范圍的類庫，可以完成大多數通常需要的APP開發任務，包括：非同步網路操作相關所有功能、強大的圖片處理操作、輕量級ORM資料庫Sqlite庫、zip操作、動畫特效、Html等解析採集、事件匯流排EventBus/Otto、Gson(Json)、AQuery、主流所有UI控制項(例如：ActionbarSherlock，SlidingMenu，BottomView，Actionbar，DragListView等10多種UI庫)等。

7. Android模塊化設計方案之使用代理模式解耦

Android模塊化設計方案系列文章：

1、 Android模塊化設計方案模型圖

2、 Android模塊化設計方案之介面API化

3、 Android模塊化設計方案之使用代理模式解耦

本篇是Android模塊化設計方案的第三篇，也是對 第一篇 中ThridLibs Proxy模塊進行說明。

很多人覺得對那些優秀的第三方依賴庫再次封裝是一件多餘的事情，因為這些庫可能出自大神/大廠，或有非常高的star並且使用起來十分穩定，可以在項目中直接拿來使用。當然每個開發者都有自己的態度，我也只是根據以往的經驗，表達一下自己的看法。

作為從了解四大組件就不愁找不到工作的互聯網大時代中一路走來的Android老鳥，經歷了網路請求框架從HttpConnection到Volley再到OkHttp，也經歷了圖片載入框架從UniversalImageLoader到Picasso再到Gilde，技術的迭代隨時都會發生。讓項目架構具有良好的擴展性是在設計之初就需要考慮的東西。

那麼接下來我用一個簡單的demo來演示一下如何使用代理模式對第三方框架進行解耦。

現在我們有一個名為 thirdlib 的模塊，為我們提供圖片載入功能。

第一步：我們創建了一個新的模塊 thridlibproxy ，並且該模塊依賴於 thirdlib ，我們在該模塊中創建包私有的介面ImageLoaderInterface，這個介面中把thirdlib模塊中提供的功能抽象為介面：

第二步：創建包私有的介面的實現類ImageLoaderOneImpl，類中圖片載入的業務邏輯是通過調用 thirdlib 中的ImageLoader類實現的：

第三步：我們提供一個供外部調用的ImageLoaderOneImpl介面代理類ImageLoaderProxy：

最後我們就可以通過ImageLoaderProxy中提供的loadImage方法進行圖片的載入了。

看到這里有些盆友就會問了，在第二步的時候，我們就完成了 thirdlib 的封裝工作，為什麼還要有第三步？還有我寫一個單例類直接對 thirdlib 進行封裝不就行了，為什麼還要抽象出介面？

原因很簡單，為的就是盡可能的滿足軟體設計七大原則中的第一個： 開閉原則 。

一個好的軟體設計，需要對拓展開放，對修改關閉。我們在設計之初就要想到，在更換圖片載入框架之後如何最大程度上滿足開閉原則。

如果直接對 thirdlib 進行封裝，是面向類的開發而不是面向介面。如果此時更換圖片載入類庫，那必然會對封裝出來的類進行大量的修改，把原來的實現替換為新的實現。

使用代理模式的好處就是，我新創建一個被代理的類ImageLoaderTwoImpl：

然後只需要對第三步中的被代理類進行替換就行了。

在想要達到相同效果的時候，最大程度的滿足了開閉原則。

我們業務層模塊也和第三方庫實現了完全的解耦，我不需要知道 thridlibproxy 是如何幫我完成圖片載入工作的，但是只要調用它提供的方法就完事兒的，這也符合軟體設計七大原則中的： 最少知道原則 。
關於為何以及怎麼通過代理調用第三方依賴庫，到這里就介紹完畢了，趕快動手試試吧~

我只想說： 原則是死的，人是活的😹

如果覺得有收獲的話，歡迎點贊評論以及關注~