編輯:關於Android編程
AndroidAnnotations是一個開源框架,旨在加快Android開發的效率。通過使用它開放出來的注解api,你幾乎可以使用在任何地方, 大大的減少了無關痛癢的代碼量,讓開發者能夠抽身其外,有足夠的時間精力關注在真正的業務邏輯上面。而且通過簡潔你的代碼,也提高了代碼的穩定性和後期的維護成本。以下AndroidAnnotations簡稱為AA
可能會有人提出異議了,我們移動設備的性能,不比後台服務器擁有充足的內存和運算能力。當大量的使用注解的時候,會不會對APP的造成什麼不良的影響,會不會影響到APP的執行性能?在這裡先明確的聲明,AA不會給APP帶來任何副作用,相反它強大易用的api能為你帶來前所未有的編程體驗。
目前主流的注解框架有xUtils、ButterKnife、Dragger和Roboguice,它們的實現原理都是一致的,都是通過反射機制實現的。通過在Runtime運行期去反射類中帶有注解的Field和Method,然後再去執行注解相對應的邏輯代碼。大家都知道反射機制是在APP的運行期執行的,會造成執行的效率下降,執行時間變長的缺點。當在我們APP中大量的使用基於反射的注解,會嚴重影響到性能。但是AA的實現的邏輯並不是基於此。
AA工作的原理其實也很簡單,它通過使用jdk 1.6引入的Java Annotation Processing Tool,
在編譯器中加了一層額外的自動編譯步驟,用來生成基於你源碼的代碼。生成的代碼是你源碼的直接子類,而且自動生成的類的名稱就是父類名稱後面加個下劃線。比如使用了@EActivity注解的MyActivity,AA都會自動幫你生成一個名為MyActivity_的類。使用AA的注解在編譯期間就已經自動生成了對應的子類,運行期運行的其實就是這個子類,所以說AA的使用不會給APP的執行性能造成負面影響。
AA開發環境搭建:右鍵=>Properties=>Java Compiler => Annotation Processing => Factory Path。
下面我們通過示例來簡單了解這個強大的框架,主要介紹一些常用的注解。
一、組件的注解
@EActivity這個注解是用來修飾Activity的,向Activity注入布局,也可以設置頁面的樣式為全屏、無Title。這些使用具有實意的注解來實現,是不是很方便呀。對於其他的組件支持也是相當簡單的,如@EService、@EReceiver、@EProvider、@EApplication、@EApplication、@EFragment。同時也能修飾自定義控件,注解為@EView、@EViewGroup。支持是不是相當全面。
二、資源引用的注解
有了AA,各種讓人煩躁的findViewById從此一去不再返了,你可以簡單的使用@ViewById去綁定布局裡面的控件,如果你的變量名和控件的id值一致,連id的指向也可省去。而且在注解中不寫id的情況下,如果編譯器在R文件中找不到對應變量id名的時候,編譯器也會給你提示,很是友好。
同時你要是想在成員變量中引用資源的話,只要在變量上加入對應的注解修飾就可以了,同樣的如果變量名稱和資源id一致的時候,id就可省去。支持所有的資源文件,所有的。
如果你想獲取系統服務,只要在你的變量前加上@SystemService注解。
獲取Intent中傳遞的值,加上@Extra注解,同時容錯性很好,如果接收不到這個key對應的value,也沒問題,你可以設置默認值。再有就是強轉失敗也不會造成crash,比如傳遞的是個int值,接收的時候是個String,也沒有問題,只是接收失敗罷了。
很強大有木有,修飾成員變量的注解主要用來解決它們初始化的問題,做到聲明即初始化,拿來即可用的功能。還有很多屬性,就不一一介紹了。
三、事件綁定注解
AA支持基本所有的原生事件的綁定,示例中展示的是常見的三種。簡單的一個事件注解加上一個監聽的控件id,就能完成以前要做的復雜的事件綁定呀,內部類實現呀等。而且方法名可以任意定制,如果方法名與控件的id一致,注解中的id也可省去,同樣如果匹配不上的話,編譯器也編譯不過的。方法的參數列表也是可以自定義的,當需要參數的時候,就把原生監聽方法的參數列表拉過來就可以直接使用了。其他常用的還有@TextChange、@ItemClick、@SeekBarProgressChange。
四、異步線程與UI線程的交互
當View相關的成員變量初始化完畢後,會調用擁有@AfterViews注解的方法,你可以在裡面初始化一些界面控件等。如果其他的成員變量處事完畢,就會調用@AfterInject。
比如大多數應用的邏輯是這樣的,初始化界面之後,就發起耗時的數據請求,然後解析獲取到的數據,再設置到界面上。一般的涉及UI線程與異步任務交互的時候,相對都比較麻煩一些。讓我們看下AA是如何實現的。
很簡單吧,UI線程執行的方法加個@UiThread,異步線程方法加個@Background,兩者的交互就是方法直接的相互調用,其他的你不用關心,一切的實現都是AA的編譯器去自動生成交互的代碼。交互的過程,完全沒有在執行異步的感覺,不用再使用Handler去發送接收Message了。兩個注解就把以前一堆的代碼實現的功能給實現了,真心給個最大的贊。
五、Rest API
在AA中也支持Rest API,而且支持所有的HTTP請求方法。下面演示的是一個GET請求。
定義一個請求的接口,然後就可以直接使用了,不需要自己再去實現。這個跟公司後台接口設計緊密相關,如果你公司接口交互都是Rest風格的話,你就重寫下,好好體驗AA的魅力吧。
寫在最後:AndroidAnnotations功能強大,是注解框架中當之無愧的王者,靈活的API大大的提高了開發的效率,降低維護的成本。如果說它有什麼弊端,我只能說NO,它沒有弊端。如果硬要來一個的話,也只能是它的注解比較多,熟悉需要一段時間,如果整個開發團隊技術遷移過來的話,前期技術成本稍高。但是所謂砍柴不誤磨刀功,還是不能歸結為一個弊端。AA還有很多強大實用的功能,限於篇幅就不展開說了,自己去探索吧。
好了,今天的干貨都到此為止。
在我們的實際項目中,數據應該說是很多的,我們的ListView不可能一下子把數據全部加載進來,我們可以當滾動條滾動到ListView的底部的時候,給一個更多的提示,當我們
最近項目中需要完成以下這個需求UI給我了五張圖片,我感覺太浪費了,自定義view完全可以做而且適配起來更加的方便最終實現效果項目效果擴展需要知道技術點在實現這個過程之前,
項目地址:XBanner簡介:功能強大的圖片無限自動輪播控件,可支持自定義狀態點及指示器顯示位置等功能支持圖片無限輪播的控件,可進行自定義功能。主要功能:支持根據服務端返
Dev Club 是一個交流移動開發技術,結交朋友,擴展人脈的社群,成員都是經過審核的移動開發工程師。每周都會舉行嘉賓分享,話題討論等活動。本期,我們邀請了騰訊WXG A