android事件類
Ⅰ Android中使用事件匯流排的優缺點分別是什麼
Android中使用事件匯流排Eventbus的優缺點如下:
1.Android EventBus事件匯流排是一個Android平台輕量級的事件匯流排框架, 它簡化了Activity、Fragment、Service等組件之間的交互,很大程度上降低了它們之間的耦合,使得代碼更加簡潔,耦合性更低,提升代碼質量。
2.AndroidEventBus使用註解來標識接收函數,這樣函數名不受限制。
3.缺點是要實現上述訂閱/發布模型的功能,付出的代價就是對各個注冊Bus的類進行反射。如果大量的使用的情況下,對應用的性能多少有點副影響。
AndroidEventBus類似於觀察者模式,通過register函數將需要訂閱事件的對象注冊到事件匯流排中,然後根據@Subcriber註解來查找對象中的訂閱方法,並且將這些訂閱方法和訂閱對象存儲在map中。當用戶在某個地方發布一個事件時,事件匯流排根據事件的參數類型和tag找到對應的訂閱者對象,最後執行訂閱者對象中的方法。這些訂閱方法會執行在用戶指定的線程模型中,比如mode=ThreadMode.ASYNC則表示該訂閱方法執行在子線程中
Ⅱ android點擊事件
Android中View的onClick事件有四種寫法:
1.匿名內部類:
button.setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
//點擊後執行
}
});
2.自定義單擊事件監聽類:
class MyClickListener implements OnClickListener {
@Override
public void onClick(View v) {
//點擊後執行
}
}
3.Activity直接實現View.OnClickListener的onClick方法
@Override
public void onClick(View v) {
//點擊後執行
}
4.在XML文件中顯示指定按鈕的onClick屬性,這樣點擊按鈕時會利用反射的方式調用對應Activity中的click()方法:
android:onClick="onClick"
public void onClick(View v) {
//點擊後執行
}
Ⅲ 請簡述什麼是android事件處理,並分析兩種android事件處理機制的實現過程和區別
UI編程通常都會伴隨事件處理,Android也不例外,它提供了兩種方式的事件處理:基於回調的事件處理和基於監聽器的事件處理。
對於基於監聽器的事件處理而言,主要就是為Android界面組件綁定特定的事件監聽器;對於基於回調的事件處理而言,主要做法是重寫Android組件特定的回調函數,Android大部分界面組件都提供了事件響應的回調函數,我們主要重寫它們就行。
一 基於監聽器的事件處理
相比於基於回調的事件處理,這是更具「面向對象」性質的事件處理方式。在監聽器模型中,主要涉及三類對象:
1)事件源Event Source:產生事件的來源,通常是各種組件,如按鈕,窗口等。
2)事件Event:事件封裝了界面組件上發生的特定事件的具體信息,如果監聽器需要獲取界面組件上所發生事件的相關信息,一般通過事件Event對象來傳遞。
3)事件監聽器Event Listener:負責監聽事件源發生的事件,並對不同的事件做相應的處理。
基於監聽器的事件處理機制是一種委派式Delegation的事件處理方式,事件源將整個事件委託給事件監聽器,由監聽器對事件進行響應處理。這種處理方式將事件源和事件監聽器分離,有利於提供程序的可維護性。
舉例:
View類中的OnLongClickListener監聽器定義如下:(不需要傳遞事件)
[java] view plainprint?
public interface OnLongClickListener {
boolean onLongClick(View v);
}
public interface OnLongClickListener {
boolean onLongClick(View v);
}
View類中的OnLongClickListener監聽器定義如下:(需要傳遞事件MotionEvent)
[java] view plainprint?
public interface OnTouchListener {
boolean onTouch(View v, MotionEvent event);
}
public interface OnTouchListener {
boolean onTouch(View v, MotionEvent event);
}
二 基於回調的事件處理
相比基於監聽器的事件處理模型,基於回調的事件處理模型要簡單些,該模型中,事件源和事件監聽器是合一的,也就是說沒有獨立的事件監聽器存在。當用戶在GUI組件上觸發某事件時,由該組件自身特定的函數負責處理該事件。通常通過重寫Override組件類的事件處理函數實現事件的處理。
舉例:
View類實現了KeyEvent.Callback介面中的一系列回調函數,因此,基於回調的事件處理機制通過自定義View來實現,自定義View時重寫這些事件處理方法即可。
[java] view plainprint?
public interface Callback {
// 幾乎所有基於回調的事件處理函數都會返回一個boolean類型值,該返回值用於
// 標識該處理函數是否能完全處理該事件
// 返回true,表明該函數已完全處理該事件,該事件不會傳播出去
// 返回false,表明該函數未完全處理該事件,該事件會傳播出去
boolean onKeyDown(int keyCode, KeyEvent event);
boolean onKeyLongPress(int keyCode, KeyEvent event);
boolean onKeyUp(int keyCode, KeyEvent event);
boolean onKeyMultiple(int keyCode, int count, KeyEvent event);
}
public interface Callback {
// 幾乎所有基於回調的事件處理函數都會返回一個boolean類型值,該返回值用於
// 標識該處理函數是否能完全處理該事件
// 返回true,表明該函數已完全處理該事件,該事件不會傳播出去
// 返回false,表明該函數未完全處理該事件,該事件會傳播出去
boolean onKeyDown(int keyCode, KeyEvent event);
boolean onKeyLongPress(int keyCode, KeyEvent event);
boolean onKeyUp(int keyCode, KeyEvent event);
boolean onKeyMultiple(int keyCode, int count, KeyEvent event);
}
三 比對
基於監聽器的事件模型符合單一職責原則,事件源和事件監聽器分開實現;
Android的事件處理機制保證基於監聽器的事件處理會優先於基於回調的事件處理被觸發;
某些特定情況下,基於回調的事件處理機制會更好的提高程序的內聚性。
四 基於自定義監聽器的事件處理流程
在實際項目開發中,我們經常需要自定義監聽器來實現自定義業務流程的處理,而且一般都不是基於GUI界面作為事件源的。這里以常見的app自動更新為例進行說明,在自動更新過程中,會存在兩個狀態:下載中和下載完成,而我們的程序需要在這兩個狀態做不同的事情,「下載中」需要在UI界面上實時顯示軟體包下載的進度,「下載完成」後,取消進度條的顯示。這里進行一個模擬,重點在說明自定義監聽器的事件處理流程。
4.1)定義事件監聽器如下:
Ⅳ Android事件的downTime和eventTime有何區別
區別:DownTime() /是獲取按下開始時間,EventTime() //是獲取事件結束時間。
在android中,不管是DownTime,還是EventTime,都是MontionEvent類 的方法。當用戶觸摸屏幕時,將創建一個MontionEvent對象(event),可以通過這個對象獲取觸控事件的具體信息(比如觸摸的坐標event.getX(nID); //獲取第nID個觸控點的x位置 event.getY(nID); //獲取第nID個點觸控的y位置)。
補充:獲取到DownTime和eventTime,他們的時間差就是總共按下時花費時間(event.getEventTime()-event.getDownTime()))
Ⅳ android里的所有事件都是基於消息隊列的嗎
Android廣播分為兩個方面:廣播發送者和廣播接收者,通常情況下,BroadcastReceiver指的就是廣播接收者(廣播接收器)。廣播作為Android組件間的通信方式,可以使用的場景如下:1.同一app內部的同一組件內的消息通信(單個或多個線程之間)。2.同一app內部的不同組件之間的消息通信(單個進程)。3.同一app具有多個進程的不同組件之間的消息通信。4.不同app之間的組件之間消息通信。5.Android系統在特定情況下與App之間的消息通信。從實現原理看上,Android中的廣播使用了觀察者模式,基於消息的發布/訂閱事件模型。因此,從實現的角度來看,Android中的廣播將廣播的發送者和接受者極大程度上解耦,使得系統能夠方便集成,更易擴展。具體實現流程要點粗略概括如下:1.廣播接收者BroadcastReceiver通過Binder機制向AMS(Activity Manager Service)進行注冊;2.廣播發送者通過binder機制向AMS發送廣播;3.AMS查找符合相應條件(IntentFilter/Permission等)的BroadcastReceiver,將廣播發送到BroadcastReceiver(一般情況下是Activity)相應的消息循環隊列中;4.消息循環執行拿到此廣播,回調BroadcastReceiver中的onReceive()方法。 對於不同的廣播類型,以及不同的BroadcastReceiver注冊方式,具體實現上會有不同。但總體流程大致如上。
Ⅵ Android可監聽的事件類型(提示:用戶事件和系統事件,用戶事件又分為按鍵事件和觸屏事件)
在android系統中,存在多種界面事件,如點擊事件,觸摸事件,焦點事件,和菜單事件
用戶事件和系統事件等,事件發生時,android界面框架調用界面控制項的事件處理函數對事件進行處理。
如:用戶事件:
按鍵事件:keyevent將傳遞給onkey()函數進行處理
觸屏事件:touchevent將傳遞給ontouch()函數進行處理。
Ⅶ android常用的事件有哪些
1:查看是否有存儲卡插入
String status=Environment.getExternalStorageState();
if(status.equals(Enviroment.MEDIA_MOUNTED))
{
說明有SD卡插入
}
2:讓某個Activity透明
OnCreate中不設Layout
this.setTheme(R.style.Theme_Transparent);
以下是Theme_Transparent的定義(注意transparent_bg是一副透明的圖片)
3:在屏幕元素中設置句柄
使用Activity.findViewById來取得屏幕上的元素的句柄. 使用該句柄您可以設置或獲取任何該對象外露的值.
TextView msgTextView = (TextView)findViewById(R.id.msg);
msgTextView.setText(R.string.push_me);
4:發送簡訊
String body=」this is mms demo」;
Intent mmsintent = new Intent(Intent.ACTION_SENDTO, Uri.fromParts(」smsto」, number, null));
mmsintent.putExtra(Messaging.KEY_ACTION_SENDTO_MESSAGE_BODY, body);
mmsintent.putExtra(Messaging.KEY_ACTION_SENDTO_COMPOSE_MODE, true);
mmsintent.putExtra(Messaging.KEY_ACTION_SENDTO_EXIT_ON_SENT, true);
startActivity(mmsintent);
可參考鏈接http://jykenan.iteye.com/blog/1062141
Ⅷ Android中KeyDown事件
Developer官網上關於返回值是這樣寫的:True if the listener has consumed the event, false otherwise. 意即,返回True代表事件完成,否則由系統進行後續處理。
Ⅸ android開發中,事件處理的方法有哪些
用戶的每次觸碰(onClick,onLongClick,onScroll,etc.)都是由一個ACTION_DOWN+n個ACTION_MOVE+1個ACTION_UP組成的,用戶觸碰必先有個ACTION_DOWN響應,用戶觸碰結束必然會有個ACTION_UP。(當然如果在途中被攔截,就可能不會有了!)那麼View是如何分發消息和攔截消息呢?
1.View及其子類都會有的兩個方法:
public boolean dispatchTouchEvent(MotionEvent ev) 這個方法用來分發TouchEvent
public boolean onTouchEvent(MotionEvent ev) 這個方法用來處理TouchEvent
2.特殊的View子類ViewGroup則還有一個方法:
Ⅹ android的事件處理機制有兩種
1.基於監聽的事件處理機制,有一個關鍵就是事件注冊。 但是我們在實踐的時候並沒有自己手動的為某個視圖控制項注冊監聽器。
解答: 我們會經常用到 諸如 setOnclickListener(),OnTouchListener()方法等。 從字面意義理解,它為設置...監聽器。 但是,它 跟注冊還是頗有一些區別的。 我想注冊實踐監聽器,就是將它掛在在一個線程上,也就是說有一個事件監聽線程,那麼,有事件的視圖,就至少是雙線程的程序了。 不過很可惜,在去看set..Listener的源碼的時候,是看不到它在java源碼方面的具體實現的。 也就是說,要麼它依賴操作系統實現,要麼它依賴jni實現,並且,事件線程由jni管理。 換言之,實現注冊監聽是由ni實現的。
2.事件源的觸發流程:
解答: 學習過操作系統朋友應該知道,操作系統的很多操作都是通過中斷來完成。 同理,比如一個點擊事件,android手機硬體中,包括了一個觸摸屏的硬體,它分為內屏和外屏。 其中負責觸發屏幕點擊和觸摸中斷的為內屏。 內屏大概由五個層次構成,具體有什麼用不知道,反正我拆過~~~ 從內屏上,當有電容屏感應的時候,會接收到你觸摸的位置信息,甚至觸摸力度!!! 這個消息經由系統中斷(具有最高優先順序,應該是由最高優先順序的進程通知)發送給cpu,經由cpu通過進程間的消息機制傳遞給這個進程(當前正在用戶界面運行的進程,這時候只有一個),也就是這個程序運行的內存空間的某個點。(或者說通過廣播機制,將這個事件發送給所有的app也是有可能的)。