android基礎
1.資料庫的操作型別有哪些,如何匯入外部資料庫?
把原資料庫包括在專案原始碼的 res/raw
android系統下資料庫應該存放在 /data/data/com.*.*(package name)/目錄下,所以我們需要做的是把已有的資料庫傳入那個目錄下.操作方法是用FileInputStream讀取原資料庫,再用FileOutputStream把讀取到的東西寫入到那個目錄.
2.是否使用過本地廣播,和全域廣播有什么差別?
因廣播資料在本應用范圍內傳播,不用擔心隱私資料泄露的問題, 不用擔心別的應用偽造廣播,造成安全隱患, 相比在系統內發送全域廣播,它更高效,
3.是否使用過intentServer,作用是什么,AIDL解決了什么問題?(小米)
生成一個默認的且與主執行緒互相獨立的作業者執行緒來執行所有傳送至 `onStartCommand() `方法的`Intetnt`,
生成一個作業佇列來傳送Intent物件給你的`onHandleIntent()`方法,同一時刻只傳送一個`Intent`物件,這樣一來,你就不必擔心多執行緒的問題,
在所有的請求(Intent)都被執行完以后會自動停止服務,所以,你不需要自己去呼叫`stopSelf()`方法來停止該服務
提供了一個`onBind()`方法的默認實作,它回傳null
提供了一個`onStartCommand()`方法的默認實作,它將`Intent`先傳送至作業佇列,然后從作業佇列中每次取出一個傳送至`onHandleIntent()`方法,在該方法中對Intent對相應的處理,
AIDL (Android Interface Definition Language) 是一種IDL 語言,用于生成可以在Android設備上兩個行程之間進行行程間通信(interprocess communication, IPC)的代碼,如果在一個行程中(例如Activity)要呼叫另一個行程中(例如Service)物件的操作,就可以使用AIDL生成可序列化的引數, AIDL IPC機制是面向介面的,像COM或Corba一樣,但是更加輕量級,它是使用代理類在客戶端和實作端傳遞資料,
4.Activity、Window、View三者的差別,fragment的特點?(360)
Activity像一個工匠(控制單元),Window像窗戶(承載模型),View像窗花(顯示視圖) LayoutInflater像剪刀,Xml配置像窗花圖紙,
- 在
Activity中呼叫attach,創建了一個Window - 創建的
window是其子類PhoneWindow,在attach中創建PhoneWindow - 在
Activity中呼叫setContentView(R.layout.xxx) - 其中實際上是呼叫的
getWindow().setContentView() - 呼叫
PhoneWindow中的setContentView方法 - 創建
ParentView:作為ViewGroup的子類,實際是創建的DecorView(作為FramLayout的子類) - 將指定的
R.layout.xxx進行填充通過布局填充器進行填充【其中的parent指的就是DecorView】 - 呼叫到
ViewGroup - 呼叫
ViewGroup的removeAllView(),先將所有的view移除掉 - 添加新的
view:addView()
關于文中所說到的知識點,我都放在GitHub上了,如有需要,可自行查看,
同時我也推薦一下我的Android交流裙Android技術交流,不僅可以免費獲取資料,而且還能有一幫大佬為你擺平關于Android的技術問題~
fragment 特點
Fragment可以作為Activity界面的一部分組成出現;- 可以在一個
Activity中同時出現多個Fragment,并且一個Fragment也可以在多個Activity中使用; - 在
Activity運行程序中,可以添加、移除或者替換Fragment; Fragment可以回應自己的輸入事件,并且有自己的生命周期,它們的生命周期會受宿主Activity的生命周期影響,
5.描述一次網路請求的流程(新浪)

6.Handler、Thread和HandlerThread的差別(小米)
http://blog.csdn.net/guolin_blog/article/details/9991569
http://droidyue.com/blog/2015/11/08/make-use-of-handlerthread/
從Android中Thread(java.lang.Thread -> java.lang.Object)描述可以看出,Android的Thread沒有對Java的Thread做任何封裝,但是Android提供了一個繼承自Thread的類HandlerThread(android.os.HandlerThread -> java.lang.Thread),這個類對Java的Thread做了很多便利Android系統的封裝,
android.os.Handler可以通過Looper物件實體化,并運行于另外的執行緒中,Android提供了讓Handler運行于其它執行緒的執行緒實作,也是就HandlerThread,HandlerThread物件start后可以獲得其Looper物件,并且使用這個Looper物件實體Handler,
7.低版本SDK實作高版本api(小米)
自己實作或@TargetApi annotation
8.編譯安卓系統(百度)
1.創建一個大小寫敏感的磁盤鏡像檔案 2.首先你要安裝的就是Xcode 3.從macports.org安裝MacPorts工具 4.從MacPorts安裝make,git, and GPG packages 5.修改檔案識別符號限制 6.創建~/bin/目錄 7.安裝repo 8.設定repo可執行權限 9.修改~/bin/repo檔案將第五行 10.新建目錄gingerbread,并進入該目錄 11.執行repoinit 12. reposync 13.設定必要的編譯環境-編譯 14.利用Eclipse除錯代碼
9.launch mode應用場景(百度、小米、樂視)
standard,創建一個新的Activity,
singleTop,堆疊頂不是該型別的Activity,創建一個新的Activity,否則,onNewIntent,
singleTask,回退堆疊中沒有該型別的Activity,創建Activity,否則,onNewIntent+ClearTop,
注意: 1.設定了"singleTask"啟動模式的Activity,它在啟動的時候,會先在系統中查找屬性值affinity等于它的屬性值taskAffinity的Task存在; 如果存在這樣的Task,它就會在這個Task中啟動,否則就會在新的任務堆疊中啟動,因此, 如果我們想要設定了"singleTask"啟動模式的Activity在新的任務中啟動,就要為它設定一個獨立的taskAffinity屬性值, 2.如果設定了"singleTask"啟動模式的Activity不是在新的任務中啟動時,它會在已有的任務中查看是否已經存在相應的Activity實體, 如果存在,就會把位于這個Activity實體上面的Activity全部結束掉,即最終這個Activity 實體會位于任務的Stack頂端中, 3.在一個任務堆疊中只有一個”singleTask”啟動模式的Activity存在,他的上面可以有其他的Activity,這點與singleInstance是有區別的,
singleInstance,回退堆疊中,只有這一個Activity,沒有其他Activity,
singleTop適合接收通知啟動的內容顯示頁面, 例如,某個新聞客戶端的新聞內容頁面,如果收到10個新聞推送,每次都打開一個新聞內容頁面是很煩人的, singleTask適合作為程式入口點, 例如瀏覽器的主界面,不管從多少個應用啟動瀏覽器,只會啟動主界面一次,其余情況都會走onNewIntent,并且會清空主界面上面的其他頁面, singleInstance應用場景:鬧鈴的響鈴界面, 你以前設定了一個鬧鈴:上午6點,在上午5點58分,你啟動了鬧鈴設定界面,并按 Home 鍵回桌面;在上午5點59分時,你在微信和朋友聊天; 在6點時,鬧鈴響了,并且彈出了一個對話框形式的 Activity(名為 AlarmAlertActivity) 提示你到6點了(這個 Activity 就是以 SingleInstance 加載模式打開的),你按回傳鍵,回到的是微信的聊天界面,這是因為 AlarmAlertActivity 所在的 Task 的堆疊只有他一個元素, 因此退出之后這個 Task 的堆疊空了,如果是以 SingleTask 打開AlarmAlertActivity,那么當鬧鈴響了的時候,按回傳鍵應該進入鬧鈴設定界面,
10.touch 事件傳遞流程(小米)
http://hanhailong.com/2015/09/24/Android-%E4%B8%89%E5%BC%A0%E5%9B%BE%E6%90%9E%E5%AE%9ATouch%E4%BA%8B%E4%BB%B6%E4%BC%A0%E9%80%92%E6%9C%BA%E5%88%B6/
11.view繪制流程(百度)
http://www.codekk.com/blogs/detail/54cfab086c4761e5001b253f
12.多執行緒(360)
- Activity.runOnUiThread(Runnable)
- View.post(Runnable),View.postDelay(Runnable,long)
- Handler
- AsyncTask
13.執行緒同步(百度)
http://www.itzhai.com/java-based-notebook-thread-synchronization-problem-solving-synchronization-problems-synchronized-block-synchronized-methods.html#read-more
http://www.juwends.com/tech/android/android-inter-thread-comm.html
單例
public class Singleton{
private volatile static Singleton mSingleton;
private Singleton(){
}
public static Singleton getInstance(){
if(mSingleton == null){\\A
synchronized(Singleton.class){\\C
if(mSingleton == null)
mSingleton = new Singleton();\\B
}
}
return mSingleton;
}
}
14.什么情況導致記憶體泄漏(美團)
1.資源物件沒關閉造成的記憶體泄漏
描述: 資源性物件比如(Cursor,File檔案等)往往都用了一些緩沖,我們在不使用的時候,應該及時關閉它們,以便它們的緩沖及時回收記憶體,它們的緩沖不僅存在于 java虛擬機內,還存在于java虛擬機外,如果我們僅僅是把它的參考設定為null,而不關閉它們,往往會造成記憶體泄漏,因為有些資源性物件,比如 SQLiteCursor(在解構式finalize(),如果我們沒有關閉它,它自己會調close()關閉),如果我們沒有關閉它,系統在回收它時也會關閉它,但是這樣的效率太低了,因此對于資源性物件在不使用的時候,應該呼叫它的close()函式,將其關閉掉,然后才置為null.在我們的程式退出時一定要確保我們的資源性物件已經關閉, 程式中經常會進行查詢資料庫的操作,但是經常會有使用完畢Cursor后沒有關閉的情況,如果我們的查詢結果集比較小,對記憶體的消耗不容易被發現,只有在常時間大量操作的情況下才會復現記憶體問題,這樣就會給以后的測驗和問題排查帶來困難和風險,
2.構造Adapter時,沒有使用快取的convertView
描述: 以構造ListView的BaseAdapter為例,在BaseAdapter中提供了方法: public View getView(int position, ViewconvertView, ViewGroup parent) 來向ListView提供每一個item所需要的view物件,初始時ListView會從BaseAdapter中根據當前的螢屏布局實體化一定數量的 view物件,同時ListView會將這些view物件快取起來,當向上滾動ListView時,原先位于最上面的list item的view物件會被回收,然后被用來構造新出現的最下面的list item,這個構造程序就是由getView()方法完成的,getView()的第二個形參View convertView就是被快取起來的list item的view物件(初始化時快取中沒有view物件則convertView是null),由此可以看出,如果我們不去使用 convertView,而是每次都在getView()中重新實體化一個View物件的話,即浪費資源也浪費時間,也會使得記憶體占用越來越大, ListView回收list item的view物件的程序可以查看: android.widget.AbsListView.java --> voidaddScrapView(View scrap)方法, 示例代碼:
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代碼:
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
3.Bitmap物件不在使用時呼叫recycle()釋放記憶體
描述: 有時我們會手工的操作Bitmap物件,如果一個Bitmap物件比較占記憶體,當它不在被使用的時候,可以呼叫Bitmap.recycle()方法回收此物件的像素所占用的記憶體,但這不是必須的,視情況而定,可以看一下代碼中的注釋:
/** ?Free up the memory associated with thisbitmap's pixels, and mark the ?bitmap as "dead", meaning itwill throw an exception if getPixels() or ?setPixels() is called, and will drawnothing. This operation cannot be ?reversed, so it should only be called ifyou are sure there are no ?further uses for the bitmap. This is anadvanced call, and normally need ?not be called, since the normal GCprocess will free up this memory when ?there are no more references to thisbitmap. */
4.試著使用關于application的context來替代和activity相關的context
這是一個很隱晦的記憶體泄漏的情況,有一種簡單的方法來避免context相關的記憶體泄漏,最顯著地一個是避免context逃出他自己的范圍之外,使用Application context,這個context的生存周期和你的應用的生存周期一樣長,而不是取決于activity的生存周期,如果你想保持一個長期生存的物件,并且這個物件需要一個context,記得使用application物件,你可以通過呼叫 Context.getApplicationContext() or Activity.getApplication()來獲得,更多的請看這篇文章如何避免 Android記憶體泄漏,
5.注冊沒取消造成的記憶體泄漏
一些Android程式可能參考我們的Anroid程式的物件(比如注冊機制),即使我們的Android程式已經結束了,但是別的參考程式仍然還有對我們的Android程式的某個物件的參考,泄漏的記憶體依然不能被垃圾回收,呼叫registerReceiver后未呼叫unregisterReceiver, 比如:假設我們希望在鎖屏界面(LockScreen)中,監聽系統中的電話服務以獲取一些資訊(如信號強度等),則可以在LockScreen中定義一個PhoneStateListener的物件,同時將它注冊到TelephonyManager服務中,對于LockScreen物件,當需要顯示鎖屏界面的時候就會創建一個LockScreen物件,而當鎖屏界面消失的時候LockScreen物件就會被釋放掉, 但是如果在釋放 LockScreen物件的時候忘記取消我們之前注冊的PhoneStateListener物件,則會導致LockScreen無法被垃圾回收,如果不斷的使鎖屏界面顯示和消失,則最侄訓由于大量的LockScreen物件沒有辦法被回收而引起OutOfMemory,使得system_process 行程掛掉, 雖然有些系統程式,它本身好像是可以自動取消注冊的(當然不及時),但是我們還是應該在我們的程式中明確的取消注冊,程式結束時應該把所有的注冊都取消掉,
6.集合中物件沒清理造成的記憶體泄漏
我們通常把一些物件的參考加入到了集合中,當我們不需要該物件時,并沒有把它的參考從集合中清理掉,這樣這個集合就會越來越大,如果這個集合是static的話,那情況就更嚴重了,
15.ANR定位和修正
如果開發機器上出現問題,我們可以通過查看/data/anr/traces.txt即可,最新的ANR資訊在最開始部分,
-
主執行緒被IO操作(從4.0之后網路IO不允許在主執行緒中)阻塞,
-
主執行緒中存在耗時的計算
-
主執行緒中錯誤的操作,比如
Thread.wait或者Thread.sleep等Android系統會監控程式的回應狀況,一旦出現下面兩種情況,則彈出ANR對話框 -
應用在5秒內未回應用戶的輸入事件(如按鍵或者觸摸)
-
BroadcastReceiver未在10秒內完成相關的處理 -
Service在特定的時間內無法處理完成 20秒 -
使用
AsyncTask處理耗時IO操作, -
使用
Thread或者HandlerThread時,呼叫Process.setThreadPriority(Process.THREAD*PRIORITY*BACKGROUND)設定優先級,否則仍然會降低程式回應,因為默認Thread的優先級和主執行緒相同, -
使用
Handler處理作業執行緒結果,而不是使用Thread.wait()或者Thread.sleep()來阻塞主執行緒, -
Activity的onCreate和onResume回呼中盡量避免耗時的代碼 -
BroadcastReceiver中onReceive代碼也要盡量減少耗時,建議使用IntentService處理,
16.什么情況導致oom(樂視、美團)
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0920/3478.html
1)使用更加輕量的資料結構 2)Android里面使用Enum 3)Bitmap物件的記憶體占用 4)更大的圖片 5)onDraw方法里面執行物件的創建 6)StringBuilder
17.Android Service與Activity之間通信的幾種方式
- 通過
Binder物件 - 通過
broadcast(廣播)的形式
18.Android各個版本API的區別
http://blog.csdn.net/lijun952048910/article/details/7980562
19. Android代碼中實作WAP方式聯網(360)
http://blog.csdn.net/asce1885/article/details/7844159
20.如何保證service在后臺不被kill
一、onStartCommand方法,回傳START_STICKY
1、START_STICKY 在運行onStartCommand后service行程被kill后,那將保留在開始狀態,但是不保留那些傳入的intent,不久后service就會再次嘗試重新創建,因為保留在開始狀態,在創建 service后將保證呼叫onstartCommand,如果沒有傳遞任何開始命令給service,那將獲取到null的intent,
2、START*NOT*STICKY 在運行onStartCommand后service行程被kill后,并且沒有新的intent傳遞給它,Service將移出開始狀態,并且直到新的明顯的方法(startService)呼叫才重新創建,因為如果沒有傳遞任何未決定的intent那么service是不會啟動,也就是期間onstartCommand不會接收到任何null的intent,
3、START*REDELIVER*INTENT 在運行onStartCommand后service行程被kill后,系統將會再次啟動service,并傳入最后一個intent給onstartCommand,直到呼叫stopSelf(int)才停止傳遞intent,如果在被kill后還有未處理好的intent,那被kill后服務還是會自動啟動,因此onstartCommand不會接收到任何null的intent,
二、提升service優先級
在AndroidManifest.xml檔案中對于intent-filter可以通過android:priority = "1000"這個屬性設定最高優先級,1000是最高值,如果數字越小則優先級越低,同時適用于廣播,
三、提升service行程優先級
Android中的行程是托管的,當系統行程空間緊張的時候,會依照優先級自動進行行程的回收,Android將行程分為6個等級,它們按優先級順序由高到低依次是: 1.前臺行程( FOREGROUND*APP) 2.可視行程(VISIBLE*APP ) 3. 次要服務行程(SECONDARY*SERVER )4.后臺行程 (HIDDEN*APP)5.內容供應節點(CONTENT*PROVIDER) 6.空行程(EMPTY*APP) 當service運行在低記憶體的環境時,將會kill掉一些存在的行程,因此行程的優先級將會很重要,可以使用startForeground 將service放到前臺狀態,這樣在低記憶體時被kill的幾率會低一些,
四、onDestroy方法里重啟service
service +broadcast 方式,就是當service走ondestory的時候,發送一個自定義的廣播,當收到廣播的時候,重新啟動service;
五、Application加上Persistent屬性
六、監聽系統廣播判斷Service狀態
通過系統的一些廣播,比如:手機重啟、界面喚醒、應用狀態改變等等監聽并捕獲到,然后判斷我們的Service是否還存活,別忘記加權限啊,
21.Requestlayout,onlayout,onDraw,DrawChild區別與聯系(獵豹)
requestLayout()方法 :會導致呼叫measure()程序 和 layout()程序 , 說明:只是對View樹重新布局layout程序包括measure()和layout()程序,不會呼叫draw()程序,但不會重新繪制任何視圖包括該呼叫者本身,
onLayout()方法(如果該View是ViewGroup物件,需要實作該方法,對每個子視圖進行布局)
呼叫onDraw()方法繪制視圖本身 (每個View都需要多載該方法,ViewGroup不需要實作該方法)
drawChild()去重新回呼每個子視圖的draw()方法
22.invalidate()和postInvalidate() 的區別及使用(百度)
http://blog.csdn.net/mars2639/article/details/6650876
23.Android影片框架實作原理
Animation框架定義了透明度,旋轉,縮放和位移幾種常見的影片,而且控制的是整個View,實作原理是每次繪制視圖時View所在的ViewGroup中的drawChild函式獲取該View的Animation的Transformation值,然后呼叫canvas.concat(transformToApply.getMatrix()),通過矩陣運算完成影片幀,如果影片沒有完成,繼續呼叫invalidate()函式,啟動下次繪制來驅動影片,影片程序中的幀之間間隙時間是繪制函式所消耗的時間,可能會導致影片消耗比較多的CPU資源,最重要的是,影片改變的只是顯示,并不能相應事件,
24.Android為每個應用程式分配的記憶體大小是多少?(美團)
android程式記憶體一般限制在16M,也有的是24M
25.Android View重繪機制(百度、美團)
由ViewRoot物件的performTraversals()方法呼叫draw()方法發起繪制該View樹,值得注意的是每次發起繪圖時,并不會重新繪制每個View樹的視圖,而只會重新繪制那些“需要重繪”的視圖,View類內部變數包含了一個標志位DRAWN,當該視圖需要重繪時,就會為該View添加該標志位,
呼叫流程 :
mView.draw()開始繪制,draw()方法實作的功能如下:
-
繪制該
View的背景 -
為顯示漸變框做一些準備操作(見5,大多數情況下,不需要改漸變框)
-
呼叫
onDraw()方法繪制視圖本身 (每個View都需要多載該方法,ViewGroup不需要實作該方法) -
呼叫
dispatchDraw ()方法繪制子視圖(如果該View型別不為ViewGroup,即不包含子視圖,不需要多載該方法)值得說明的是,ViewGroup類已經為我們重寫了dispatchDraw ()的功能實作,應用程式一般不需要重寫該方法,但可以多載父類函式實作具體的功能,
26.LinearLayout對比RelativeLayout(百度)
1.RelativeLayout會讓子View呼叫2次onMeasure,LinearLayout 在有weight時,也會呼叫子View2次onMeasure2.RelativeLayout的子View如果高度和RelativeLayout不同,則會引發效率問題,當子View很復雜時,這個問題會更加嚴重,如果可以,盡量使用padding代替margin, 3.在不影響層級深度的情況下,使用LinearLayout和FrameLayout而不是RelativeLayout, 最后再思考一下文章開頭那個矛盾的問題,為什么Google給開發者默認新建了個RelativeLayout,而自己卻在DecorView中用了個LinearLayout,因為DecorView的層級深度是已知而且固定的,上面一個標題欄,下面一個內容欄,采用RelativeLayout并不會降低層級深度,所以此時在根節點上用LinearLayout是效率最高的,而之所以給開發者默認新建了個RelativeLayout是希望開發者能采用盡量少的View層級來表達布局以實作性能最優,因為復雜的View嵌套對性能的影響會更大一些,
27.優化自定義view(百度、樂視、小米)
為了加速你的view,對于頻繁呼叫的方法,需要盡量減少不必要的代碼,先從onDraw開始,需要特別注意不應該在這里做記憶體分配的事情,因為它會導致GC,從而導致卡頓,在初始化或者影片間隙期間做分配記憶體的動作,不要在影片正在執行的時候做記憶體分配的事情,
你還需要盡可能的減少onDraw被呼叫的次數,大多數時候導致onDraw都是因為呼叫了invalidate().因此請盡量減少呼叫invaildate()的次數,如果可能的話,盡量呼叫含有4個引數的invalidate()方法而不是沒有引數的invalidate(),沒有引數的invalidate會強制重繪整個view,
另外一個非常耗時的操作是請求layout,任何時候執行requestLayout(),會使得Android UI系統去遍歷整個View的層級來計算出每一個view的大小,如果找到有沖突的值,它會需要重新計算好幾次,另外需要盡量保持View的層級是扁平化的,這樣對提高效率很有幫助,
如果你有一個復雜的UI,你應該考慮寫一個自定義的ViewGroup來執行他的layout操作,與內置的view不同,自定義的view可以使得程式僅僅測量這一部分,這避免了遍歷整個view的層級結構來計算大小,這個PieChart例子展示了如何繼承ViewGroup作為自定義view的一部分,PieChart有子views,但是它從來不測量它們,而是根據他自身的layout法則,直接設定它們的大小,
28.ContentProvider(樂視)
http://blog.csdn.net/coder_pig/article/details/47858489
29.ragment生命周期

30.volley決議(美團、樂視)
http://a.codekk.com/detail/Android/grumoon/Volley%20%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90
31.Android Glide原始碼決議
http://www.lightskystreet.com/2015/10/12/glidesourceanalysis/ http://frodoking.github.io/2015/10/10/android-glide/
32.Android 設計模式
http://blog.csdn.net/bboyfeiyu/article/details/44563871
33.架構設計(搜狐)

http://www.tianmaying.com/tutorial/AndroidMVC
34.Android屬性影片特性(樂視、小米)
如果你的需求中只需要對View進行移動、縮放、旋轉和淡入淡出操作,那么補間影片確實已經足夠健全了,但是很顯然,這些功能是不足以覆寫所有的場景的,一旦我們的需求超出了移動、縮放、旋轉和淡入淡出這四種對View的操作,那么補間影片就不能再幫我們忙了,也就是說它在功能和可擴展方面都有相當大的局限性,那么下面我們就來看看補間影片所不能勝任的場景,
注意上面我在介紹補間影片的時候都有使用“對View進行操作”這樣的描述,沒錯,補間影片是只能夠作用在View上的,也就是說,我們可以對一個Button、TextView、甚至是LinearLayout、或者其它任何繼承自View的組件進行影片操作,但是如果我們想要對一個非View的物件進行影片操作,抱歉,補間影片就幫不上忙了,可能有的朋友會感到不能理解,我怎么會需要對一個非View的物件進行影片操作呢?這里我舉一個簡單的例子,比如說我們有一個自定義的View,在這個View當中有一個Point物件用于管理坐標,然后在onDraw()方法當中就是根據這個Point物件的坐標值來進行繪制的,也就是說,如果我們可以對Point物件進行影片操作,那么整個自定義View的影片效果就有了,顯然,補間影片是不具備這個功能的,這是它的第一個缺陷,
然后補間影片還有一個缺陷,就是它只能夠實作移動、縮放、旋轉和淡入淡出這四種影片操作,那如果我們希望可以對View的背景色進行動態地改變呢?很遺憾,我們只能靠自己去實作了,說白了,之前的補間影片機制就是使用硬編碼的方式來完成的,功能限定死就是這些,基本上沒有任何擴展性可言,
最后,補間影片還有一個致命的缺陷,就是它只是改變了View的顯示效果而已,而不會真正去改變View的屬性,什么意思呢?比如說,現在螢屏的左上角有一個按鈕,然后我們通過補間影片將它移動到了螢屏的右下角,現在你可以去嘗試點擊一下這個按鈕,點擊事件是絕對不會觸發的,因為實際上這個按鈕還是停留在螢屏的左上角,只不過補間影片將這個按鈕繪制到了螢屏的右下角而已,
轉載請註明出處,本文鏈接:https://www.uj5u.com/yidong/278886.html
標籤:其他
上一篇:Android低版本 CardView和ImageView實作圓角質感按鈕出現的詭異問題解決
下一篇:vue創建專案程序(命令創建)



