Android面試指南一

筆試+面試了很多家公司,有得也有失。在這些面試中學(xué)到了不少東西!下面把我的android面試經(jīng)歷中被問到的一些常見的問題給大家分享一下,以后有些常見的問題會及時更新。有些不足和不稱意的地方請大家多多指教。網(wǎng)上有的一般比較分散不是很全不容易記,看起來也比較浪費(fèi)時間。這里簡單整理一下和大家來分享免得以后走彎路。
首先,面試的過程中,問到的一些問題如果不會的話,面試完了記得一定要查清楚(至少面試再被問到的時候能回答個大概),因?yàn)橥粋€問題被下家問的的可能性非常大,面試多了問題很多都是共性的。
如果你簡歷上寫了做過javaWeb相關(guān)的項(xiàng)目,面試官肯定是要先問一些javaWeb相關(guān)的知識,這里大體先說一下java基礎(chǔ)知識面試常被問到的相關(guān)題目。之后再具體介紹一下android的相關(guān)題目:

  1. 面向?qū)ο蟮奶卣鳎悍庋b 繼承 多態(tài)。
    多態(tài)的兩種表現(xiàn)形式:重載和重寫。
    重載:是發(fā)生在同一類中,具有相同的方法名,主要是看參數(shù)的個數(shù),類型,順序不同實(shí)現(xiàn)方法的重載的,返回值的類型可以不同。
    重寫:是發(fā)生在兩個類中(父類和子類),具有相同的方法名,主要看方法中參數(shù),個數(shù),類型必須相同,返回值的類型必須相同。

  2. 常見的排序算法(面試的過程中,面試官可能會當(dāng)面讓你寫一種排序算法,從大到小或從小到大。當(dāng)時我就用的冒泡排序排序?qū)懙模┝信e幾種常見的排序算法(從小到大排序)具體代碼大家可以百度在此不一一列舉
    2.1 冒泡法排序 原理:第一輪冒泡比較把最大值放在了最后,第二輪比較次大又放在了最后,比較n - 1 輪(可以形象的比喻近視眼只認(rèn)識相鄰的)
    比較相鄰的元素。如果第一個比第二個大,就交換他們兩個。
    對每一對相鄰元素作同樣的工作,從開始第一對到結(jié)尾的最后一對。在這一 點(diǎn),最后的元素應(yīng)該會是最大的數(shù)。
    針對所有的元素重復(fù)以上的步驟,除了最后一個。
    持續(xù)每次對越來越少的元素重復(fù)上面的步驟,直到?jīng)]有任何一對數(shù)字需要比較
    舉例說明:要排序數(shù)組:int[] arr={6,3,8,2,9,1};

public static void buble_sort(int[] arr){
        //外層循環(huán),它決定一共走幾趟
        for(int i=0;i < arr.length-1;i++){
            //內(nèi)層循環(huán),開始逐個比較
            //如果我們發(fā)現(xiàn)前一個數(shù)比后一個數(shù)大,則交換
            for(int j =0; j < arr.length-1;j++){
                if(arr[j] > arr[j+1]){
                    //交換a[j]和a[j+1]
                    int temp = arr[j];
                    arr[j] = arr[j+1];
                    arr[j+1] = temp;
                }
            }
        }
    }
2.2 選擇法排序 原理:類似于排隊(duì)時體育老師挨個敲把最小的放在最前面

選擇排序是一種簡單直觀的排序算法,其基本原理如下:對于給定的一組記錄,經(jīng)過第一輪比較后得到最小的記錄,然后將該記錄的位置與第一個記錄的位置交換;接著對不包括第一個記錄以外的其他記錄進(jìn)行第二次比較,得到最小記錄并與第二個位置記錄交換;重復(fù)該過程,知道進(jìn)行比較的記錄只剩下一個為止。

2.3 插入法排序 原理:類似于摸牌
插入排序.png
2.4 二分查找 前提是已排序的數(shù)組中查找
  1. int 和 integer的區(qū)別
    Java 提供兩種不同的類型:引用類型和原始類型(或內(nèi)置類型)。Int是java 的原始數(shù)據(jù)類型,Integer是java為int提供的封裝類。Java為每個原始類型提供了封裝類。原始類型封裝類booleanBooleancharCharacterbyteByteshortShortintIntegerlongLongfloatFloatdoubleDouble引用類型和原始類型的行為完全不同,并且它們具有不同的語義。引用類型和原始類型具有不同的特征和用法,它們包括:大小和速度問題,這種類型以哪種類型的數(shù)據(jù)結(jié)構(gòu)存儲,當(dāng)引用類型和原始類型用作某個類的實(shí)例數(shù)據(jù)時所指定的缺省值。對象引用實(shí)例變量的缺省值為 null,而原始類型實(shí)例變量的缺省值與它們的類型有關(guān)。

  2. String StringBuffer StringBuilder的區(qū)別(筆試中常見)
    String(大姐,出生于JDK1.0時代) 不可變字符序列
    StringBuffer(二姐,出生于JDK1.0時代) 線程安全的可變字符序列,里面的 方法是同步的
    StringBuilder(小妹,出生于JDK1.5時代) 非線程安全的可變字符序列 ,里 面的方法是不同步的

  3. list列表和set列表存儲特點(diǎn)等(面試時候可以說是必問的,面試官可能會問你比較熟悉的一種存儲方式簡單介紹一下存儲過程和原理)

    List存儲特點(diǎn):有序可重復(fù);Set存儲特點(diǎn):不可重復(fù)
    List中常見的ArrayList和LinkList
    ArrayList:采用的是數(shù)組的形式來保存對象的,這種方式將對象放在連續(xù)的位置上,所以最大的缺點(diǎn)就是插入刪除時非常麻煩。
    LinkList:采用的是將對象放在獨(dú)立的空間中,而且在每個空間中還保存下一個鏈接的索引,但缺點(diǎn)是查找非常麻煩,要從第一個索引開始。
    Set存儲 :hashSet 無序不可重復(fù)無下標(biāo);TreeSet 有序不可重復(fù)無下標(biāo)

  4. 抽象類和接口的區(qū)別

    6.1 首先根據(jù)java繼承的特征只支持單繼承,不允許多繼承,一個子類只能有一個父類。所以一個類只能繼承一個抽象類,而一個類可以實(shí)現(xiàn)多個接口
    6.2 抽象類中可以有各種類型的變量和方法而接口中的成員變量只能是public static final類型的
    6.3 抽象類中可以有靜態(tài)代碼塊和靜態(tài)方法;接口中不能有靜態(tài)代碼塊和靜態(tài)方法
    6.4 抽象類中可以含有抽象方法和非抽象的方法并且可以提供成員方法的實(shí)現(xiàn)細(xì)節(jié),含有抽象方法的類肯定是抽象類,而接口中都是抽象的方法

  5. java四種引用類型(問到的可能性也很大,面試官也可能會問你怎樣理解gc垃圾回收機(jī)制,當(dāng)時我就是被這么問到的,還好沒有被問懵為未自己的機(jī)智回答點(diǎn)個贊哈哈)

    7.1 強(qiáng)引用(必不可少) 垃圾回收器絕對不會回收它。如Object obj = new Object(); obj便是內(nèi)存不足時,java虛擬機(jī)寧愿拋出OutofMemorryError錯誤導(dǎo)致程序崩潰異常終止,也 不會回收強(qiáng)引用的對象。
    7.2 軟引用(可有可無)如果內(nèi)存空間足夠,垃圾回收就不會回收它,如果內(nèi)存空間不足了,就會回收這些對象的內(nèi)存
    7.3 弱引用(可有可無)垃圾回收器一旦發(fā)現(xiàn)了只具有弱引用的對象,不管當(dāng)前內(nèi)存空間足夠與否,都會回收它的內(nèi)存,當(dāng)發(fā)生GC的時候,弱引用的對象總是被回收
    7.4 虛引用 當(dāng)垃圾回收器準(zhǔn)備回收一個對象時,如果發(fā)現(xiàn)它還有虛引用,就會在回收對象的內(nèi)存之前把這個虛引用加入到與之前關(guān)聯(lián)的引用隊(duì)列中。與弱引用不同點(diǎn)就是虛引用必須和引用隊(duì)列聯(lián)合使用。

  6. hashMap和hashTable的區(qū)別

    8.1 hashMap 是map接口的一個實(shí)現(xiàn)類; hashTable是Dictionary的子類
    8.2 hashMap中的方法是非同步的(多線程中需要同步處理),內(nèi)部通過一個Entry數(shù)組來實(shí)現(xiàn);hashTable的方法是同步的(多線程應(yīng)用程序中不用專門的操作就可以安全的使用)
    8.3 hashMap允許null鍵和null值;

    比較:HashMap比HashTable功能更多,而且它不是基于一些陳舊的類所以一般情況下HashMap優(yōu)于HashTable

  7. 什么是不可變對象(immutable object),不可變對象有什么好處,在什么情況下應(yīng)該用,或者更具體一些,Java的String類為什么要設(shè)成immutable類型?
    不可變對象,顧名思義就是創(chuàng)建后不可以改變的對象,典型的例子就是Java中的String類,

    String s = “ABC”;
    s.toLowerCase();
    .toLowerCase() //并沒有改變“ABC”的值,而是創(chuàng)建了一個新的String類”abc”,然后將新的實(shí)例的指向變量s。
相對于可變對象,不可變對象有很多優(yōu)勢。
1)不可變對象可以提高String Pool的效率和安全性。如果你知道一個對象是不可變的,那么需要拷貝這個對象的內(nèi)容時,就不用復(fù)制它的本身而只是復(fù)制它的地址,復(fù)制地址( 通常一個指針的大小)需要很小的內(nèi)存效率也很高。對于同時引用這個“ABC”的其他變量也不會造成影響。
2)不可變對象對于多線程是安全的,因?yàn)樵诙嗑€程同時進(jìn)行的情況下,一個可變對象的值很可能被其他進(jìn)程改變,這樣會造成不可預(yù)期的結(jié)果,而使用不 可變對象就可以避免這種情況。當(dāng)然也有其他方面原因,但是最Java把String設(shè)成immutable最大的原因應(yīng)該就是效率和安全的。
  1. 單例種類和表現(xiàn)形式以及各自優(yōu)缺點(diǎn)比較
    單例模式有以下特點(diǎn):
      1、單例類只能有一個實(shí)例。
      2、單例類必須自己創(chuàng)建自己的唯一實(shí)例。
      3、單例類必須給所有其他對象提供這一實(shí)例。
    10.1 餓漢式單例類
    //餓漢式單例類.在類初始化時,已經(jīng)自行實(shí)例化
    public class Singleton1{
    //私有的默認(rèn)構(gòu)造子
    private Singleton1(){}
    //已經(jīng)自行實(shí)例化
    private static final Singleton1 single=new Singleton1();
    //靜態(tài)工廠方法
    public static Singleton1 getInstance(){
    return single;
    }
    }
特點(diǎn):此類加載時就初始化單例對象,較大時會影響系統(tǒng)加載速度

10.2 懶漢式單例類
    //懶漢式單例類.在第一次調(diào)用的時候?qū)嵗?    public class Singleton2{
    //私有的默認(rèn)構(gòu)造子
    private Singleton2(){}
    //注意,這里沒有final
    private static Singleton2 single=null;
    //靜態(tài)工廠方法
    public synchronized static Singleton2 getInstance(){
    if(single==null){
    single=new Singleton2();
    }
    return single;
    }
    }
特點(diǎn):只有訪問到單例對象的時候才去檢查和實(shí)例化單例對象,多線程訪問
需要加同步鎖影響訪問效率

10.3 使用靜態(tài)內(nèi)部類作為Singleton容器(登記式單例類)

public class Singleton{
private Singleton(){ }
private static class SingletonHolder{
// 私有內(nèi)部類在Singleton加載時不初始化
private static Singleton instance = new Singleton();
}
public static Singleton getInstance(){
return SingletonHolder.instance;
}
}

特點(diǎn):能延遲加載,又能保證線程安全 原理是直接用classLoader(jvm類加載機(jī)制) 進(jìn)行異步加鎖的問題,并減少了內(nèi)存消耗保證了初始化instance時只有一個線程,所以是線程安全的

(二)接下來總結(jié)一下Android原生相關(guān)的面試題:

  1. handler機(jī)制的原理
    andriod提供了 Handler 和 Looper 來滿足線程間的通信。Handler 先進(jìn)先出原則。Looper類用來管理特定線程內(nèi)對象之間的消息交換(Message Exchange)。
    1)Looper: 一個線程可以產(chǎn)生一個Looper對象,由它來管理此線程里的Message Queue(消息隊(duì)列)。
    2)Handler: 你可以構(gòu)造Handler對象來與Looper溝通,以便push新消息到Message Queue里;或者接收Looper從Message Queue取出)所送來的消息。

    1. Message Queue(消息隊(duì)列):用來存放線程放入的消息。
      4)線程:UI thread 通常就是main thread,而Android啟動程序時會替它建立一個Message Queue
  2. Android四大組件(重點(diǎn)看下廣播和服務(wù))
    ①activity 提供用戶界面 用于與用戶交互的組件,(活動窗體)它需要為保持各界面的狀態(tài),做很多持久化的事情,妥善管理生命周期以及一些跳轉(zhuǎn)邏輯
    ②content Provider
    為應(yīng)用程序之間訪問提供的接口的組件,實(shí)現(xiàn)數(shù)據(jù)共享,結(jié)構(gòu)化數(shù)據(jù)集合,以表的形式對外提供數(shù)據(jù),可以像數(shù)據(jù)庫一樣記性選擇排序
    ③BroadCastReceiver (廣播)
    采用異步機(jī)制完成組件之間消息的傳遞,異步是指廣播的發(fā)送方將消息標(biāo)記后發(fā)出,不需要得到對方的回應(yīng),可以繼續(xù)做自己的操作
    默認(rèn)情況下,所有的組件都有接收廣播的能力,組件想要接收廣播就注冊與發(fā)送方一致的標(biāo)記
    包括普通廣播和有序廣播:
    發(fā)送有序廣播:sendOrderedBroadCast(…);
    有序廣播可以進(jìn)行應(yīng)用程序之間傳遞消息,可以根據(jù)manifest文件中注冊的優(yōu)先級的高低判斷接收的順序。

無序廣播:sendBroadCast();
實(shí)現(xiàn)過程:
創(chuàng)建一個類繼承BroadCastReceiver,重寫其中的onReceiver()方法,進(jìn)行接收廣播之后的操作。
廣播 的生命周期注冊方式:
1. 程序代碼中動態(tài)注冊 退出時要取消注冊。特點(diǎn):關(guān)掉后,廣播就失效了
2. 清單文件中靜態(tài)注冊。 特點(diǎn):無需關(guān)心廣播接收器是否關(guān)閉,廣播觸發(fā)時,即使退出應(yīng)用也會對它起作用

④server(服務(wù))
不需要提供用戶界面,在后臺運(yùn)行服務(wù)于activity,執(zhí)行長時間耗時操作的組件

  1. 網(wǎng)絡(luò)存儲方式
3.1 使用SharedPreferences存儲數(shù)據(jù)
 適用范圍:保存少量的數(shù)據(jù),且這些數(shù)據(jù)的格式非常簡單:字符串型、基本類型的值。比如應(yīng)用程序的各種配置信息(如是否打開音效、是否使用震動效果、小游戲的玩家積分等),解鎖口 令密碼等

3.2 文件存儲數(shù)據(jù)
通過讀取文件里的文件io流,SD卡等存儲
 核心原理: Context提供了兩個方法來打開數(shù)據(jù)文件里的文件IO流 ,F(xiàn)ileInputStream openFileInput(String name); FileOutputStream(String name , int mode),
這兩個方法第一個參數(shù) 用于指定文件名,第二個參數(shù)指定打開文件的模式。

3.3 SQLite存儲數(shù)據(jù)
SQLite是輕量級嵌入式數(shù)據(jù)庫引擎,它支持 SQL 語言,并且只利用很少的內(nèi)存就有很好的性能。

3.4 網(wǎng)絡(luò)存儲

可以調(diào)用webService返回的數(shù)據(jù)或是解析http協(xié)議實(shí)現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)交互等等

3.5 ContentProvider

 為應(yīng)用程序之間訪問提供的接口組件,實(shí)現(xiàn)數(shù)據(jù)共享結(jié)構(gòu)化數(shù)據(jù)集合,以表的形式對外提供數(shù)據(jù),可以像數(shù)據(jù)庫一樣選擇排序

4. 服務(wù)如何啟用Service,如何停用Service。Android中的service類似于windows中的service,service一般沒有用戶操作界面,它運(yùn)行于系統(tǒng)中不容易被用戶發(fā)覺,
可以使用它開發(fā)如監(jiān)控之類的程序。
首先服務(wù)的特點(diǎn):1 沒有界面用戶不可見 2 程序在后臺運(yùn)行做耗時操作
服務(wù)分三類:startService() bindService() intentService

一。步驟

第一步:繼承Service類
  public class SMSService extends Service { }
  第二步:在AndroidManifest.xml文件中的節(jié)點(diǎn)里對服務(wù)進(jìn)行配置:
  二。Context.startService()和Context.bindService
  服務(wù)不能自己運(yùn)行,需要通過調(diào)用Context.startService()或Context.bindService()方法啟動服務(wù)。這兩個方法都可
  以啟動Service,但是它們的使用場合有所不同。

4.1 使用startService()方法啟用服務(wù),調(diào)用者與服務(wù)之間沒有關(guān)連,即使調(diào)用者退出了,服務(wù)仍然運(yùn)行。
  使用bindService()方法啟用服務(wù),調(diào)用者與服務(wù)綁定在了一起,調(diào)用者一旦退出,服務(wù)也就終止。

4.2 采用Context.startService()方法啟動服務(wù),在服務(wù)未被創(chuàng)建時,系統(tǒng)會先調(diào)用服務(wù)的onCreate()方法,

接著調(diào)用onStart()方法。如果調(diào)用startService()方法前服務(wù)已經(jīng)被創(chuàng)建,多次調(diào)用startService()方法并
  不會導(dǎo)致多次創(chuàng)建服務(wù),但會導(dǎo)致多次調(diào)用onStart()方法。
  采用startService()方法啟動的服務(wù),只能調(diào)用Context.stopService()方法結(jié)束服務(wù),服務(wù)結(jié)束時會調(diào)用
  onDestroy()方法。

4.3 采用Context.bindService()方法啟動服務(wù),在服務(wù)未被創(chuàng)建時,系統(tǒng)會先調(diào)用服務(wù)的onCreate()方法,
  接著調(diào)用onBind()方法。這個時候調(diào)用者和服務(wù)綁定在一起,調(diào)用者退出了,系統(tǒng)就會先調(diào)用服務(wù)的onUnbind()方法,
  。接著調(diào)用onDestroy()方法。如果調(diào)用bindService()方法前服務(wù)已經(jīng)被綁定,多次調(diào)用bindService()方法并不會
  導(dǎo)致多次創(chuàng)建服務(wù)及綁定(也就是說onCreate()和onBind()方法并不會被多次調(diào)用)。如果調(diào)用者希望與正在綁定的服務(wù)
  解除綁定,可以調(diào)用unbindService()方法,調(diào)用該方法也會導(dǎo)致系統(tǒng)調(diào)用服務(wù)的onUnbind()–>onDestroy()方法。

三。Service的生命周期

4.4 Service常用生命周期回調(diào)方法如下:

onCreate() 該方法在服務(wù)被創(chuàng)建時調(diào)用,該方法只會被調(diào)用一次,無論調(diào)用多少次startService()或bindService()方法,
  服務(wù)也只被創(chuàng)建一次。 onDestroy()該方法在服務(wù)被終止時調(diào)用。

4.5 Context.startService()啟動Service有關(guān)的生命周期方法

onStart() 只有采用Context.startService()方法啟動服務(wù)時才會回調(diào)該方法。該方法在服務(wù)開始運(yùn)行時被調(diào)用。
  多次調(diào)用startService()方法盡管不會多次創(chuàng)建服務(wù),但onStart()方法會被多次調(diào)用。

4.6 Context.bindService()啟動Service有關(guān)的生命周期方法

onBind()只有采用Context.bindService()方法啟動服務(wù)時才會回調(diào)該方法。該方法在調(diào)用者與服務(wù)綁定時被調(diào)用,
  當(dāng)調(diào)用者與服務(wù)已經(jīng)綁定,多次調(diào)用Context.bindService()方法并不會導(dǎo)致該方法被多次調(diào)用。
  onUnbind()只有采用Context.unbindService()方法啟動服務(wù)時才會回調(diào)該方法。該方法在調(diào)用者與服務(wù)解除綁定時被調(diào)用。
  備注:

4.7 采用startService()啟動服務(wù)

  Intent intent =new Intent(DemoActivity.this, DemoService.class);
  startService(intent);

4.8 Context.bindService()啟動

  Intent intent =new Intent(DemoActivity.this, DemoService.class);
  bindService(intent, conn, Context.BIND_AUTO_CREATE);
  //unbindService(conn);//解除綁定

4.9 intentService()
大部分的service不需要同時處理多個請求(處理多個請求是一個比較危險的多線程場景)這樣的情況下最好使用intentService類去實(shí)現(xiàn)
原因:intentService會直接創(chuàng)建默認(rèn)的工作線程,在服務(wù)中無須再自己寫線程,自帶一個重寫的onhandleIntent()方法,該方法對意圖的處理是按照
是不會阻塞別的事情,當(dāng)處理完所有intent后該方法會自動調(diào)用stopself()所以不需要手動調(diào)用。

5. 網(wǎng)絡(luò)處理Volley和okHttp為什么結(jié)合使用

volley重點(diǎn)在于request的隊(duì)列的管理,其他的地方都很不強(qiáng),一般
都是volley+okhttp接合使用,不過如果沒有特別多的網(wǎng)絡(luò)性能要求(一般而言,比如你們用戶量沒有超百萬)還是默認(rèn)使用volley那套網(wǎng)絡(luò)連接方式就夠了。
OkHttp引擎在Android 4.4上是基于HttpURLConnection的。 Twitter, Facebook 和 Snapch都采用了它。

Volley的工作方式是創(chuàng)建不同的request,然后把它們添加到隊(duì)列中(queue)。一個項(xiàng)目只需要一個queue就足夠了,每次你想創(chuàng)建一個request的時候你都只需要獲得這個唯一的queue來添加。

Volley可以輕松設(shè)置OkHttp作為其傳輸層,Request參數(shù)中設(shè)置HttpStack

volley 只是適合小數(shù)據(jù)的傳輸,上傳文件下載文件這些都支持的不是很好

Volley/Gson的解決方案比較成熟,因?yàn)檫@是谷歌的解決方案,同時也因?yàn)槌霈F(xiàn)在安卓開發(fā)者網(wǎng)站上,因此在2013到2014年都非常流行。到目前為止,這仍然是一個很好的選擇,它是簡單有效的。不過需要考慮一下的是Volley和Gson現(xiàn)在不怎么更新了。

okhttp還比volley有更多的選擇。文中說的組合是說替換volley的HttpStack為okhttp的stack。并不是說okhttp只做了傳輸層的封裝……volley的網(wǎng)絡(luò)請求過程還就直接封裝成異步的了……
拓展性高的是okhttp,數(shù)據(jù)流還是用okio來優(yōu)化的,請求過程有同步,也有異步方法,響應(yīng)體保持同步阻塞,大大的方便了有進(jìn)行連續(xù)多次網(wǎng)絡(luò)請求的需求。

相關(guān)鏈接:http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0720/3209.html

6. 自定義View是如何繪制到界面上的
自定義View包含文字,幾何圖形,Bitmap

繼承view
6.1 繪制文字 => onDraw()

      Paint paint = new Paint(); 
      Canvas.drawText("text",0,50,paint); 0和 50分別指橫坐標(biāo)X和縱坐標(biāo)Y
      可以通過paint設(shè)置文字顏色,字體大小~~~

6.2 繪制幾何圖形

      6.2.1 直線 canvas.drawLine(x,x,y,y,paint) 參數(shù)分別為start   end  
      start  end. 
      6.2.2 矩形  canvas.drawRect(left,top,right,bottom,paint)  
      6.2.3 圓形  canvas.drawCircle(cx,cy,radius,paint)      

6.3 繪制圖像

     canvas.drawBitmap(bitmap, left,top,paint)
     bitmap 可在構(gòu)造方法中動態(tài)產(chǎn)生 如bitmap = BitmapFactory.decodeResource(getResource(), R.drawable.ic_launcher)

6.4 在XML中定義樣式和屬性對顯示效果的影響(位置,顏色,滾動~~~)

    6.4.1 res-->value-->attires.xml

             <declare-styleable name="NumText">

                <attr name="Linnum" format="Integer">

            </declare-styleable>

    6.4.2 在布局中引入命名空間 nt="http:...res/conn + 項(xiàng)目包名"

    6.4.3 nt: num="3";

    6.4.4 代碼中解析:TypedArray對象 Ta = context.obtainStyleAttribute(...)

獲取樣式屬性 解析后要釋放Ta.recycle()
詳細(xì)了解可以點(diǎn)擊此鏈接 自定義View,自定義屬性(帶進(jìn)度的圓形進(jìn)度條):http://www.cnblogs.com/linlf03/p/3577828.html

6.5 繪制流程以及自定義View的主要步驟:

我們知道,不管是自定義View還是系統(tǒng)提供的TextView這些,它們都必須放置在LinearLayout等一些ViewGroup中,因此理論上我們可以很好的 理onMeasure(),onLayout(),onDraw()這三個函數(shù):
1.View組件及子組建本身大小多少,這由onMeasure()決定;
2.View在ViewGroup中的位置如何,這由onLayout()決定;
3.繪制View的內(nèi)容,onDraw()定義了如何繪制這個View;
invalidate():調(diào)用該方法,可以強(qiáng)制重新繪制界面
requestLayout():當(dāng)前布局大小改變時,可以調(diào)用該方法,刷新布局。

相關(guān)詳細(xì)鏈接:http://blog.csdn.net/chziroy/article/details/43069975

7. Android中跨進(jìn)程通信

       7.1 隱式意圖
       7.2 廣播
       7.3 contentProvider
       7.4 service(服務(wù))
       7.5 aidl跨進(jìn)程通信  AIDL的英文全稱是Android Interface Define Language 當(dāng)B進(jìn)程要去調(diào)用A進(jìn)程中的service時,并實(shí)現(xiàn)通信,通過AIDL實(shí)現(xiàn)Service的跨進(jìn)程通信(IPC),其實(shí)是通過Binder機(jī)制來實(shí)現(xiàn)的。我們通常都是通過AIDL來操作的之前整理過的一博客做了詳細(xì)的介紹:http://blog.csdn.net/yshr1991/article/details/51568752
       7.6 利用Messenger信使,與aidl方式的區(qū)別就在于AIDL是多線程的,而Messenger是單                             線程的,也就是說利用Messenger的跨進(jìn)程通信在消息隊(duì)列中每次只有一個請求。

8. intent和intentfilter區(qū)別

是一個Service或者是啟動一個BroadcastReceiver,都可以使用統(tǒng)一的
Intent這種”啟動意圖”,這樣就使用了一致的編程模型,也是一種高層
次的”解耦”。
8.1\. 從名字來看IntentFilter 比Intent 多了個Filter 即后者比前者多了
個篩選作用篩選條件: action、data和category
力,所以一般不會在java代碼中設(shè)置,而是在應(yīng)用的manifest文件中作為元素的方式聲明。 一個例外是,為broadcast receiver
注冊動態(tài)的filter,可以調(diào)用Context.registerReceiver()方法,通過直接
實(shí)例化IntentFilter對象創(chuàng)建

9. 事件分發(fā)傳遞

   方法主要涉及三個方法:
  9.1 分發(fā)事件 boolean dispatchTouchEvent(MotionEvent e)因?yàn)?  控件 所有的事件都是通過 Activity 的 dispatchTouchEvent 進(jìn)行分
  發(fā)的;控件直接從 Activity 獲取到事件,這個事件會首先被傳遞到控
  件的dispatchTouchEvent 方法
 dispatchTouchEvent()無論返回true還是false,事件都不會進(jìn)行分發(fā),
愿望,能否分發(fā)成功還需要經(jīng)過事件攔截的審核,true表示自身本層消費(fèi)。
法進(jìn)行消費(fèi),同時事件會停止向下傳遞;
如果 return false,事件分發(fā)分為兩種情況:
如果當(dāng)前 View 獲取的事件直接來自 Activity,則會將事件返回給
Activity 的 onTouchEvent 進(jìn)行消費(fèi);View 的 onTouchEvent 進(jìn)
行消費(fèi)
9.2 攔截事件 boolean onInterceptTouchEvent(MotionEvent e)
true 則攔截交由本層view的onTouchEvent()處理
false 不攔截 發(fā)給子view 由子view的dispatchTouchEvent()
處理進(jìn)行
事件分發(fā)
如果 onInterceptTouchEvent 返回 super.onInterceptTouchEvent(ev),事件默認(rèn)會被攔截,并將攔截到的事件交由當(dāng)前 View 的 onTouchEvent
進(jìn)行處理。
9.3 處理事件 boolean onTouchEvent()
并且 onInterceptTouchEvent 返回 true 或返回、super.onInterceptTouchEvent(ev) 的情況下 onTouchEvent 會被調(diào)用
返回true或返回 super.onInterceptTouchEvent(ev) )。才可以交由本
層的onTouchEvent 的事件響應(yīng)邏輯如下:

如果事件傳遞到當(dāng)前 View 的 onTouchEvent 方法,而該方法返回了
false,那么這個事件會從當(dāng)前 View 向上傳遞,并且都是由上層 View
的 onTouchEvent 來接收,如果傳遞到上面的 onTouchEvent 也返回
false,這個事件就會“消失”,而且接收不到下一次事件。
如果返回了 true 則會接收并消費(fèi)該事件。
如果返回 super.onTouchEvent(ev) 默認(rèn)處理事件的邏輯和返回 false
時相同

相關(guān)詳細(xì)鏈接: http://www.lxweimin.com/p/e99b5e8bd67b
相關(guān)詳細(xì)鏈接2(通過代碼比較容易理解): http://www.cnblogs.com/sunzn/archive/2013/05/10/3064129.html
onTouch和onTouchEvent的區(qū)別鏈接:http://www.cnblogs.com/Claire6649/p/5947139.html
10. ListView的優(yōu)化方案

  10.1 在getView()方法中復(fù)用convertView盡可能的少創(chuàng)建view
  10.2 定義一個viewHolder對象,用于緩存顯示數(shù)據(jù),減少
  findViewById的次數(shù)
  10.3 如果item顯示很多,就要考慮分頁加載,規(guī)定每頁加載多少
  條,每次請求加載多少條,用戶拉到列表底部的時候,再去加載接
  下來的條目。

12. Android中動畫的使用(類別 特點(diǎn)和區(qū)別)

   Android 3.0之前分兩種:
   12.1 tween動畫(補(bǔ)間動畫)
     這種實(shí)現(xiàn)方式可以使視圖組件 移動 縮放 旋轉(zhuǎn) 和 淡入淡出四種動
     畫操作
   12.2 Frame(幀)動畫
   傳統(tǒng)的動畫方法,通過順序的播放排列好的圖片來實(shí)現(xiàn),類似于放
   電影
   Android 3.0之后系統(tǒng)提供了一種全新的動畫模式:屬性動畫,可以
   完全取代補(bǔ)間動畫
   補(bǔ)間動畫缺陷:
   1 對一個view對象進(jìn)行操作,如果自定義view  使用canvas根據(jù)paint
   坐標(biāo)進(jìn)行繪制只能用屬性動畫
  2 補(bǔ)間動畫只能實(shí)現(xiàn)移動 縮放 旋轉(zhuǎn) 和 淡入淡出四種動畫操作,如view
  背景進(jìn)行改變就用屬性動畫了
  3 只能改變view的顯示效果,不能改變屬性,比如說,現(xiàn)在屏幕的左上
  角有一個按鈕,然后我們通過補(bǔ)間動畫將它移動到了屏幕的右下角,現(xiàn)
  在你可以去嘗試點(diǎn)擊一下這個按鈕,點(diǎn)擊事件是絕對不會觸發(fā)的,因?yàn)?  實(shí)際上這個按鈕還是停留在屏幕的左上角,只不過補(bǔ)間動畫將這個按鈕
  繪制到了屏幕的右下角而已。
 屬性動畫的機(jī)制:通過對目標(biāo)對象進(jìn)行賦值,并修改其屬性來實(shí)現(xiàn)

13. Android 四種啟動模式以及應(yīng)用場景

 13.1  standard
默認(rèn)模式,可以不用寫配置。在這個模式下,每次激活A(yù)ctivity都會默認(rèn)
創(chuàng)建一個新的Activity實(shí)例并放入棧中,可以有多個相同的實(shí)例,也允許
多個 相同Activity疊加。
應(yīng)用場景:Activity可以多次入棧
13.2 singleTop
可以有多個實(shí)例,但是不允許多個相同Activity疊加。如果Activity在棧
頂?shù)臅r候,啟動相同的Activity,不會創(chuàng)建新的實(shí)例,而會調(diào)用其onNewIntent方法,否則會創(chuàng)建新的實(shí)例并放入棧頂,即使棧中存在該
Activity的實(shí)例,只要是不在棧頂都會創(chuàng)建新的實(shí)例
應(yīng)用場景:棧頂存在則復(fù)用,不存在則創(chuàng)建;瀏覽器的書簽界面,
接受通知啟動的內(nèi)容顯示界面
13.3 singleTask
若棧中存在activity實(shí)例,就會重用該實(shí)例(調(diào)用其onNewIntent
方法),并將其上的實(shí)例移出棧,如果棧中不存在該實(shí)例,將會創(chuàng)
建新的實(shí)例放入棧中。
應(yīng)用場景:如果一個activity創(chuàng)建需要占用系統(tǒng)大量的資源(如CPU
, 內(nèi)存。。。) 就用singleTask;瀏覽器的Activity不管從多個瀏覽
器只會啟動主界面一次,其余情況都會走onNewIntent方法并會清
空主界面上的其它界面
13.4 singleInstance
單一實(shí)例啟動模式 Activity會運(yùn)行在自己的任務(wù)棧中,并且這個任
務(wù)棧中只有一個實(shí)例存在,不允許其它activity在本任務(wù)棧中。
應(yīng)用場景:如果activity在整個手機(jī)系統(tǒng)中只允許一個實(shí)例存在,
如電話撥打界面。

14. 內(nèi)存泄露和內(nèi)存溢出的區(qū)別

     14.1 內(nèi)存泄漏:向系統(tǒng)申請了一塊內(nèi)存空間使用new關(guān)鍵字 使
     用完了沒有及時釋放掉程序時間越長占用內(nèi)存越多最終崩潰
   原因可能存在如下:
   14.1.1 查詢數(shù)據(jù)庫時沒有關(guān)閉游標(biāo)cursor
   14.1.2 構(gòu)造Adapter時,沒有復(fù)用convertView
   14.1.3 bitmap使用完后,沒有recycle()給釋放掉
   14.1.4 廣播推出程序后,未取消注冊
   14.1.5 使用文件或訪問網(wǎng)絡(luò)資源時未關(guān)閉InputStrean/OutStream
   14.2 內(nèi)存溢出:你要求分配的內(nèi)存超出了系統(tǒng)能給的,系統(tǒng)不能
   提供滿足需求的內(nèi)存,還沒有new就直接崩潰了。

15.
Android中Java和JavaScript交互
https://droidyue.com/blog/2014/09/20/interaction-between-java-and-javascript-in-android/

// 交互三種方式的講解和比較
http://blog.csdn.net/carson_ho/article/details/64904691

http://blog.csdn.net/Lennie_Z/article/details/75424032

//app中常涉及
http://mobile.51cto.com/aprogram-452011.htm

16.關(guān)于MVC,MVP,MVVM的一點(diǎn)總結(jié)和思考
軟件的架構(gòu)方式有很多種,從最開始的MVC模式,演化到MVP,然后到現(xiàn)在的MVVM,在不斷的演化過程中其核心的思想就是降低各組件之間的耦合度,使得數(shù)據(jù)的流向更加的清晰明了。

16.1MVC
較為傳統(tǒng)和成熟的一種架構(gòu)方式,最核心的就是通過Control層來進(jìn)行調(diào)控,所有的調(diào)度都是由Control來進(jìn)行處理。其核心的策略簡示如下:


MVC.png

優(yōu)點(diǎn):優(yōu)點(diǎn)是對于混亂的軟件組織方式有了一個明確的組織方式,通過Control來掌控全局,同時將View展示和Model的變化分離開。
缺點(diǎn):從圖示中也可以看出,在View和Model之間是直接進(jìn)行交互的,也就是說View和Model之間是可以相互產(chǎn)生影響的,這樣在代碼中就必然會導(dǎo)致View和Model之間的耦合。

16.2MVP
MVC架構(gòu)方式的變種,使用Presenter來代替Control,而且改變了數(shù)據(jù)的流向,View和Model之間不再直接進(jìn)行交互,而是全部通過Presenter來進(jìn)行。


MVP.png

優(yōu)點(diǎn):優(yōu)點(diǎn)是可以是得整個軟件分層清晰,降低耦合度,同時也將Activity從既是Control又是View的境地中解脫出來,只需要單一的負(fù)責(zé)UI即可,降低了Activity的任務(wù)
缺點(diǎn):缺點(diǎn)是需要加入Presenter來作為橋梁協(xié)調(diào)View和Model,同時也會導(dǎo)致Presenter變得很臃腫,在維護(hù)時比較不方便。而且對于每一個Activity,基本上均需要一個對應(yīng)的Presenter來進(jìn)行對應(yīng)。

16.3MVVM
MVVM其實(shí)是對MVP的一種改進(jìn),他將Presenter替換成了ViewModel,并通過雙向的數(shù)據(jù)綁定來實(shí)現(xiàn)視圖和數(shù)據(jù)的交互。也就是說只需要將數(shù)據(jù)和視圖綁定一次之后,那么之后當(dāng)數(shù)據(jù)發(fā)生改變時就會自動的在UI上刷新而不需要我們自己進(jìn)行手動刷新。在MVVM中,他盡可能的會簡化數(shù)據(jù)流的走向,使其變得更加簡潔明了


MVVM.png

優(yōu)點(diǎn):可以使得數(shù)據(jù)流的走向更加的清晰明了,同時也簡化了開發(fā),數(shù)據(jù)和視圖只需要進(jìn)行一次綁定即可。
缺點(diǎn):目前這種架構(gòu)方式的實(shí)現(xiàn)方式比較不完善規(guī)范,常見的就是DataBinding框架

  1. 相對定位 絕對定位
    相對定位的元素不會脫離文檔流,占用文檔流的空間,Left; Right; Top和Bottom屬性與margin屬性混合使用會產(chǎn)生累加效果。 絕對定位的元素脫離文檔流,偏移不影響文檔流中的其它元素,Left; Right; Top和Bottom屬性與margin屬性混合使用,偏移方向相同值累加,方向相反,margin屬性值無效。 絕對定位的元素以最近的定位祖先元素為參照物
    如果給父元素(div-1)定義為position:relative;子元素(div-1a)定義為position:absolute,那么子元素(div-1a)的位置將相對于父元素(div-1),而不是整個頁面。

相對位置會相對于它在文檔流中默認(rèn)的位置

未完,待續(xù)~~~

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容