我們都知道哈,如果一個界面的邏輯夠復雜,那么你的Activity如果在不進行優化或者細分的情況下的代碼量會異常的多,那么現在博客就和大家來討論一下如何給activity減輕負擔!
為什么我們的Activity中的代碼會很多呢?這是因為在activity里面你既要寫 顯示View的邏輯、數據處理的邏輯、網絡請求的邏輯、可能還有其他亂七八糟的邏輯, 那么我們知道問題的所在,為什么不主動去優化呢?
需求:假設現在我現在有一個界面,整個是一個列表,然后最上面有一個輪播圖顯示多張的圖片 輪播圖每一個圖片點擊會跳轉到其他頁面
那么我們現在就知道列表的每一個Item顯示都是一樣的,寫一個適配器就夠了 上面的輪播圖,如果我們使用ListView的話,可以添加頭部視圖的方法可以加到列表的最上面 那么很多人就很自然的把顯示輪播圖的邏輯全寫在Activity中,如果需求就如我所說的這么一點,那么這么寫也是可以的,因為夠簡單就沒必要優化 但是如果你的列表頁面像淘寶一樣復雜呢? 如果你負責實現列表的顯示,另一個人負責實現輪播圖的展示呢?
所以這時候你可以這樣子做一個分解!添加到ListView頭部的就是一個HeaderView,那么你完全可以把這部分的實現給分離出去,比如建立一個MyHeader的類,這個類可以根據顯示的數據data創建出View并且返回,如下
public class MyHeader { PRivate Context mContext; public MyHeader(Context context) { mContext = context; } /** * 顯示數據到View * * @param imagesPath * @return */ public View init(List<String> imagesPath) { View contentView = View.inflate(mContext, R.layout.header, null); //這里實現展示輪播圖的邏輯 //比如先找到ViewPager,然后創建顯示的適配器 //ViewPager vp = (ViewPager) contentView.findViewById(R.id.vp); //............... return contentView; }}真實的情況下肯定沒有這么簡單,比如這里面你需要對ViewPager的每一個View進行點擊事件的監聽,然后實現跳轉的邏輯,你會發現,你的這寫代碼都沒寫在Activity中 在Activity中只要獲取到輪播圖的數據,調用init方法,拿到需要顯示的View,添加到ListView的Header中就可以了,只要和輪播圖有關的代碼都被抽取到MyHeader中來實現,你的Activity中的代碼能不減少么?
這種方式不僅僅用于舉例的這種情況,你可以用于很多情況,只要你對你要展示的View進行一個劃分就可以了 比如頁面根據參數有兩種展示的情況的,非常適合這么做 比如頁面需要發送多個請求,每一個請求顯示在一塊區域中 等等。。。。。。。
上述的例子就是對列表的頭部的輪播圖進行了一個劃分!
這個說法相信對所有的人都很熟悉,其實我們平常中可以封裝的東西有很多很多,不僅可以讓代碼看上去更簡潔,而且可以讓代碼量也有說減少 比如土司一個提示:封裝過之后
T.show(mContext,"提示");這么做的好處還有一個就是可以統一管理,你想要關閉或者開啟都會非常的方便
同樣的,測試輸出也是一樣的
可以使用通用的一些適配器,避免每次寫重復代碼
然后再舉例一個比較經典的例子:更換頭像
相信這個功能很多人都做過,從本地選擇一個圖片,然后上傳這個圖片到服務器,圖片可能是需要裁剪過的,也可能是拍照再裁剪 有很多人是這么做的: 拍照為一個入口去實現這個邏輯 選擇本地圖片為一個入口去實現這個邏輯
其實對于上述的需求,無非就是一句話:拿到一張圖片裁剪過的路徑
所以針對這句話,你可以想到的封裝一個類庫啊!這個類庫集拍照、裁剪、預覽、圖片放大等等功能,這個庫的輸出就是多張圖片的路徑
這也就是為什么需要使用一些好用的第三方庫來實現這樣子的功能,你會發現你的代碼會變的很簡單簡單,你根本不需要想任何事情,你只需要開啟這個類庫,拿到返回值(圖片路徑)就可以了
有些人又會想,我想要圖片裁剪層指定大小還不是要我自己拿到圖片再做操作,其實這都應該是圖片選擇框架(類庫)的事情,你在開啟圖片選擇框架(類庫)的時候完全可以開啟裁剪功能和指定裁剪的大小,那么這個就根本不是問題 還是回歸到了最開始說的那句話:拿到一張圖片裁剪過的路徑
代碼優化是需要你去思考的,以上都是我個人從編程以來自己一步一步總結過來的,所以如果你想寫出高質量、高可讀的代碼,請你多思考.歡迎大家在評論去留言討論哦
--小金子新聞熱點
疑難解答