android基礎夯實3

28)FrameWork 層的每個類都折騰了？
> 在寫android程式碼時，我們基本不會出現new MyActivity(), new MyService()等等這樣的程式碼，要知道android app的編寫語言是java，java的特點是什麼：“一切皆物件”。那麼問題來了，我們寫的activity，service等什麼時候被new出來了的呢，它們是怎樣被new出來的，帶著這個問題我們繼續看下去。
  android framework層架構採用了ioc方式，程式設計師實現的activity，service等式在android的框架層new出來的，程式猿在完成一個activity後都需要在mainfest註冊。然後android framework層利用反射的方式動態的建立其物件。所以android採用這樣的方式將控制權全部掌握在框架層，客戶端程式設計師只需要按照其方式實現就行。
  但是緊接著新的問題又會出現，既然我們客戶端程式設計師不需要new 元件物件，也就是說我們的各個元件間是相互獨立的。然後新的問題產生各元件之間的互動該如何處理呢，android framework為我們想到了這個問題，所以Intent信使產生了，android設計者通過Intent信使實現各個元件間的互動，不得不說框架的設計確實很好，這裡膜拜大神。
  android的框架層牢牢掌控住客戶端的，包括物件的建立呼叫等。其中運用的很多好的設計模式以及方法值得我們學習。
  關於framework，更多是做的應用層之下的系統層面的東西。比如電源管理、訊息佇列、包管理等等，還包括對硬體的支援及系統提供給上層的硬體功能呼叫介面。framework的學習必然離不開不斷編譯rom和刷機。這就要求有耐心有時間有興趣。而且由於framework層多數模組都是以JNI方式被呼叫的，因此你需要有比較紮實的C語言基礎，之少能看懂程式結構。除此之外，對你想要詳細研讀的模組在應用層的應用需要有必要的理解。我剛開始看原始碼的時候是從電源管理模組開始看的，就是因為當時對android系統自帶的電源提醒方式以及電量通知不太滿意，想重新定義更多層級的提醒。剛開始也是一頭霧水，但還是硬著頭皮一點點啃。這個過程中，為了防止忘記之前看過什麼，所以又不斷對看過的原始碼做註釋並做閱讀筆記。大概兩三個月，雖然瞭解的也比較淺顯，但是我的目的達到了。原始碼之路漫漫，看個三五年都不一定敢說能夠整體吃透。雖如此，但只要有鑽研的方向和基本的能力，相信工作中遇到的framework層的改動應當還是能夠負擔得住的。

29)Hook 會玩了？
  >如果要攔截惡意軟體對電話、簡訊等API的呼叫，在Java或者Dalvik層面是不好進行的，因為這些層面都沒有提供Hook的手段，而在Native層面，我認為可行的方案是對電話、簡訊的執行庫so進行Hook（比如系統執行庫\system\lib\libreference-ril.so或\system\lib\libril.so），如果注入自己的so到上述程式後，並通過dlopen()和dlsym()獲取原有API地址，替換原有API地址為自己so中的API地址就可以達到Hook的目的。Hook的前提是程式注入，而Linux下最便捷的程式注入手段——ptrace.一種方案：程式碼主要功能是注入子程式的地址空間，Hook住子程式執行系統呼叫時的引數，並反轉其引數，從而逆序輸出ls命令的結果。
  Intel官網上下載了Intel處理器開發手冊《64-ia-32-architectures-software-developer-vol-1-manual.pdf》方才解答我的問題，定址方式涉及兩個暫存器，DS和RSI，參考手冊的說法，DS表示資料段的selector，其實這個selector就是index索引的意思，由於x64下字長64bit，即8個位元組，索引乘以8即得資料段在記憶體中的基址，RSI表示資料段內偏移地址，與基址相加即可得出資料的絕對地址，使用此地址直接訪問記憶體就可以取出資料。

30)各種 SystemService 也知道怎麼執行的了？

31)View 的渲染你明白是怎麼回事了？
》父View與子View

》》訊息佇列有如下幾個好處，這大都是由其系統解耦和訊息快取兩點擴充套件而來的：
提升系統可靠性：
冗餘：Process_B崩潰之後，資料並不會丟失，因為MQ多采用put-get-delete模式，即，僅當確認message被完成處理之後，才從MQ中移除message；
可恢復：MQ實現解耦，部分程式崩潰，不會拖累整個系統癱瘓，例，Process_B崩潰之後，Process_A仍可向MQ中新增message，並等待Process_B恢復；
可伸縮：有較強的峰值處理能力，通常應用會有突發的訪問流量上升情況，使用足夠的硬體資源時刻待命，空閒時刻較長，資源浪費，而訊息佇列卻能夠平滑峰值流量，緩解系統元件的峰值壓力；
提升系統可擴充套件性：
調整模組：由於實現解耦，可以很容易調整，訊息入隊速率、訊息處理速率、增加新的Process；
其他：
單次送達：保證MQ中一個message被處理一次，並且只被處理一次。本質：get獲取一個message後，這一message即被預定，同一程式不會再次獲取這一message；當且僅當程式處理完這一message後，MQ中會delete這個message。否則，過一段時間後，這一message自動解除被預訂狀態，程式能夠重新預定這個message；
排序保證：即，滿足佇列的FIFO，先入先出策略；
非同步通訊：很多場景下，不會立即處理訊息，這是，可以在MQ中儲存message，並在某一時刻再進行處理；
資料流的階段效能定位：獲取使用者某一操作的各個階段（通過message來標識），捕獲不同階段的耗時，可用於定位系統瓶頸。

32)Intent 是如何實現 Activity、Service等之間的解耦合的？
》Intent與Android元件之間的關係

33)單元測試會寫了？
》Eclipse與Android Studio的環境配置。

34)Monkey 能跑多長時間？

35)效能測試通過了？

36)ClassLoader 和 DexLoader 會玩了？
>
40)Android翻頁效果原理實現之引來折線??

37)Context 是個啥你也知道了？
>Context字面意思上下文，或者叫做場景，也就是使用者與作業系統操作的一個過程，比如你打電話，場景包括電話程式對應的介面，以及隱藏在背後的資料.Activity、Service、Application都是Context的子類；Android系統的角度來理解：Context是一個場景，代表與作業系統的互動的一種過程。從程式的角度上來理解：Context是個抽象類，而Activity、Service、Application等都是該類的一個實現。在其內部引用了一個Activity作為Context，也就是說，我們的這個Activity只要我們的專案活著，就沒有辦法進行記憶體回收。而我們的Activity的生命週期肯定沒這麼長，所以造成了記憶體洩漏。
>因此應用程式App共有的Context數目公式為：
總Context例項個數 = Service個數 + Activity個數 + 1（Application對應的Context例項）
>避免context相關的記憶體洩露，記住以下幾點：
1. 不要讓生命週期長的物件引用activity context，即保證引用activity的物件要與activity本身生命週期是一樣的
2. 對於生命週期長的物件，可以使用application context
3. 避免非靜態的內部類，儘量使用靜態類，避免生命週期問題，注意內部類對外部物件引用導致的生命週期變化

38)許可權機制也弄清楚了？
>Android 是一個許可權分離的系統 。 這是利用 Linux 已有的許可權管理機制，通過為每一個 Application 分配不同的 uid 和 gid ， 從而使得不同的 Application 之間的私有資料和訪問（ native 以及 java 層通過這種 sandbox 機制，都可以）達到隔離的目的 。 與此 同時， Android 還 在此基礎上進行擴充套件，提供了 permission 機制，它主要是用來對 Application 可以執行的某些具體操作進行許可權細分和訪問控制，同時提供了 per-URI permission 機制，用來提供對某些特定的資料塊進行 ad-hoc 方式的訪問。
>Android 的許可權分離的基礎是建立在 Linux 已有的 uid 、 gid 、 gids 基礎上的 。
UID 。 Android 在 安裝一個應用程式，就會為 它 分配一個 uid （參考 PackageManagerService 中的 newUserLP 實現）。其中普通 A ndroid 應用程式的 uid 是從 10000 開始分配 （參見 Process.FIRST_APPLICATION_UID ）， 10000 以下是系統程式的 uid 。
GID 。對 於普通應用程式來說， gid 等於 uid 。由於每個應用程式的 uid 和 gid 都不相同， 因此不管是 native 層還是 java 層都能夠達到保護私有資料的作用 。
GIDS 。 gids 是由框架在 Application 安裝過程中生成，與 Application 申請的具體許可權相關。 如果 Application 申請的相應的 permission 被 granted ，而且 中有對應的 gid s ， 那麼 這個 Application 的 gids 中將 包含這個 gid s 。
>一個許可權主要包含三個方面的資訊：許可權的名稱；屬於的許可權組；保護級別。一個許可權組是指把許可權按照功能分成的不同的集合。每一個許可權組包含若干具體 許可權，例如在 COST_MONEY 組中包含 android.permission.SEND_SMS ， android.permission.CALL_PHONE 等和費用相關的許可權。
每個許可權通過 protectionLevel 來標識保護級別： normal ， dangerous ， signature ， signatureorsystem 。不同的保護級別代表了程式要使用此許可權時的認證方式。 normal 的許可權只要申請了就可以使用； dangerous 的許可權在安裝時需要使用者確認才可以使用； signature 和 signatureorsystem 的許可權需要使用者的 app 和系統使用同一個數字證照。
Package 的許可權資訊主要 通過在 AndroidManifest.xml 中通過一些標籤來指定。如 <permission> 標籤， <permission-group> 標籤 <permission-tree> 等標籤。如果 package 需要申請使用某個許可權，那麼需要使用 <use-permission> 標籤來指定。


39)觸屏事件的分發呢？Handler 、Message 和 Looper 是怎麼跑起來的？
>一個事件由down move up 三個動作組成，其中move動作可以有多個或者0個，但down 和up動作有且只有一個。這個三個動作中down是最先響應的，它是先驅，由它來決定move和up動作響應路線。
>Touch事件分發中只有兩個主角:ViewGroup和View。Activity的Touch事件事實上是呼叫它內部的ViewGroup的Touch事件，可以直接當成ViewGroup處理。

View在ViewGroup內，ViewGroup也可以在其他ViewGroup內，這時候把內部的ViewGroup當成View來分析。

ViewGroup的相關事件有三個：onInterceptTouchEvent、dispatchTouchEvent、onTouchEvent。View的相關事件只有兩個：dispatchTouchEvent、onTouchEvent。

先分析ViewGroup的處理流程：首先得有個結構模型概念：ViewGroup和View組成了一棵樹形結構，最頂層為Activity的ViewGroup，下面有若干的ViewGroup節點，每個節點之下又有若干的ViewGroup節點或者View節點