自己關(guān)于Android上下文對(duì)象的理解

Android中有個(gè)我們熟悉又陌生的對(duì)象Context(上下文)，當(dāng)我們啟動(dòng)Activity的時(shí)候需要上下文，當(dāng)我們使用dialog的時(shí)候我們需要上下文，但是上下文對(duì)象到底是個(gè)什么東西呢？

10年的大觀網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營銷的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整大觀建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“大觀網(wǎng)站設(shè)計(jì)”,“大觀網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

在Android api當(dāng)中是這樣描述context對(duì)象的。

"Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc."

“是一個(gè)用于實(shí)現(xiàn)關(guān)于應(yīng)用環(huán)境的整體信息的一個(gè)接口。這是一個(gè)由安卓系統(tǒng)提供的抽象類并且系統(tǒng)有對(duì)他進(jìn)行實(shí)現(xiàn)。它允許訪問到應(yīng)用特殊的資源和類，同時(shí)它也可以實(shí)現(xiàn)到應(yīng)用級(jí)別的操作，例如：Activity的啟動(dòng)，廣播的實(shí)現(xiàn)和接受intent等。”

一、Context的主要實(shí)現(xiàn)和繼續(xù)理解

知道了context的大概描述，我們可以再繼續(xù)理解Context這個(gè)神秘的對(duì)象了，首先，作為基類，肯定有其它類去實(shí)現(xiàn)它，主要實(shí)現(xiàn)了context類的類是Activity，Service，Application。他們?nèi)齻€(gè)類雖然都是Context的子類，但是具體的繼承關(guān)系卻有些不大一樣：

Activity的繼承關(guān)系：

Service和Application的繼承關(guān)系：

可以看出我們的Context其實(shí)就是我們熟知的Activity，Service，Application。

在這3個(gè)類中，Activity的context對(duì)象和Application的context對(duì)象最容易弄混淆。

二、Context中的主要方法

知道了Context的大概描述和他的一些繼承關(guān)系，我們對(duì)Context這個(gè)類有了一個(gè)大致的了解。現(xiàn)在可以看看在context中的一些方法，來加深對(duì)context的一個(gè)理解，有很多我們使用過的方法其實(shí)都是從Context這個(gè)類中實(shí)現(xiàn)而來。

我們從Android api中查看Context類，這里出現(xiàn)了一個(gè)非常熟悉的方法：startActivity，可以看到其實(shí)Activity中的StartActivity方法是重寫了Context中的方法。

abstract void startActivity ( Intent intent)

Same as startActivity(Intent, Bundle) with no options specified.

abstract void startActivity ( Intent intent, Bundle options)

Launch a new activity.

同時(shí)context還可以訪問到資源文件，獲得資源文件中的信息。

abstract Resources getResources ()

Return a Resources instance for your application's package.

abstract SharedPreferences getSharedPreferences ( String name, int mode)

Retrieve and hold the contents of the preferences file 'name', returning a SharedPreferences through which you can retrieve and modify its values.

final String getString (int resId)

Return a localized string from the application's package's default string table.

final String getString (int resId, Object... formatArgs)

Return a localized formatted string from the application's package's default string table, substituting the format arguments as defined in Formatter and format(String, Object...) .

同時(shí)context不但可以開啟一個(gè)activity，同時(shí)還可以開啟或者關(guān)閉一個(gè)Service。

abstract ComponentName startService ( Intent service)

Request that a given application service be started.

abstract boolean stopService ( Intent service)

Request that a given application service be stopped.

訪問Android Api 或者查看源碼可以看到，Context中還有很多訪問資源文件和程序之間互相通信的方法。

可以看出context其實(shí)就是一個(gè)應(yīng)用之中的手腳，可以通過他來拿取資源文件中的資源，還可以通過他來處理Activity和Service中的一些操作，這個(gè)類就是整個(gè)程序的樞紐，負(fù)責(zé)管理整個(gè)程序的通暢運(yùn)行。

我們可以通過分析一個(gè)Toast通知的源碼去分析context的去向和使用，來了解context到底做了些神馬操作：

public static Toast makeText(Context context, CharSequence text, int duration) {

Toast result = new Toast(context);

LayoutInflater inflate = (LayoutInflater)

context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);

TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);

tv.setText(text);

result.mNextView = v;

result.mDuration = duration;

return result;

}

可以看到makeText方法接受的context被用于

context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);

這是用于獲取XML中定義的View的方法，可以看到通過外部傳入的Context，在這里獲得了一個(gè)View布局用于顯示Toast。

public Toast(Context context) {

mContext = context;

mTN = new TN();

mTN.mY = context.getResources().getDimensionPixelSize(

com.android.internal.R.dimen.toast_y_offset);

mTN.mGravity = context.getResources().getInteger(

com.android.internal.R.integer.config_toastDefaultGravity);

}

這一行中可以看出在context又被用來獲取資源文件，可以看出Toast的顯示和布局都是通過context去調(diào)用系統(tǒng)寫好的資源文件來進(jìn)行實(shí)現(xiàn)的。

三、Activity context和Application context的區(qū)別

Activity的context和Application的context的區(qū)別在于生命周期的區(qū)別，Activity的context是依附在著Activity的生命周期的，而Application的Context的生命周期是依附在整個(gè)應(yīng)用之上的。

Android 之理解 VSYNC 信號(hào)

UI 優(yōu)化系列專題，來聊一聊 Android 渲染相關(guān)知識(shí)，主要涉及 UI 渲染背景知識(shí) 、 如何優(yōu)化 UI 渲染 兩部分內(nèi)容。

《 View 繪制流程之 setContentView() 到底做了什么？ 》

《 View 繪制流程之 DecorView 添加至窗口的過程 》

《 深入 Activity 三部曲（3）View 繪制流程 》

《 Android 之 LayoutInflater 全面解析 》

《 關(guān)于渲染，你需要了解什么？ 》

《 Android 之 Choreographer 詳細(xì)分析 》

《 Android 之如何優(yōu)化 UI 渲染（上） 》

《 Android 之如何優(yōu)化 UI 渲染（下） 》

優(yōu)化是無止境的，Google 在 2012 年的 I/O 大會(huì)上宣布了 Project Butter 黃油計(jì)劃，并且在 Android 4.1 中正式開啟了這個(gè)機(jī)制。

Project Butter 主要包含兩個(gè)組成部分：一個(gè)是 VSYNC，另一個(gè)是 Triple Buffering。

也正是從這時(shí)候開始，作為嚴(yán)重影響 Android 口碑的 UI 流暢性問題便得到了有效解決。今天我們就來聊一聊這兩個(gè)組成部分的工作原理，不過在理解它們之前，需要先看下所涉及的另外兩個(gè)概念：

表示屏幕在一秒內(nèi)刷新畫面的次數(shù)， 刷新率取決于硬件的固定參數(shù)，單位 HZ（Hz）。例如常見的 60 Hz，即每秒鐘刷新 60 次。

逐行掃描

顯示器并不是一次性將畫面顯示到屏幕上，而是從左到右邊，從上到下逐行掃描顯示，不過這一過程快到人眼無法察覺到變化，以 60 Hz 刷新率的屏幕為例，即 1000 / 60 ≈ 16ms。

表示 GPU 在一秒內(nèi)繪制操作的幀數(shù)。例如電影采用 24 fps、Android 系統(tǒng)采用 60 fps，即一秒鐘繪制 30 / 60 幀畫面。更多內(nèi)容參考《 Why 60 fps 》。

現(xiàn)在，刷新頻率和幀速率需要一起合作，才能使圖形內(nèi)容呈現(xiàn)在屏幕上，GPU 會(huì)獲取圖形數(shù)據(jù)進(jìn)行繪制， 然后硬件負(fù)責(zé)把圖像內(nèi)容呈現(xiàn)到屏幕上，這一過程在應(yīng)用程序的生命周期內(nèi)一遍又一遍的發(fā)生。

不幸的是，刷新頻率和幀率并不總是能夠保持相對(duì)同步，如果你的幀速率實(shí)際比刷新率快，例如幀速率是 120 fps，顯示器的刷新頻率為 60 Hz。此時(shí)將會(huì)發(fā)生一些視覺上的問題。

由于顯示器提取畫面是從左到右，從上到下逐行掃描提取圖像顯示，這一過程需要 16ms（1000 / 60），當(dāng) GPU 利用一塊內(nèi)存區(qū)域?qū)懭霂瑪?shù)據(jù)時(shí)，從頂部開始新一幀覆蓋前一幀，并立刻輸出一行內(nèi)容。當(dāng)屏幕刷新時(shí)，它并不知道圖像緩沖區(qū)的狀態(tài)，因此它從 GPU 抓取的幀并不是完整的數(shù)據(jù)。也就是它有一半的前一幀和一半的當(dāng)前幀，這種情況被稱之為 屏幕撕裂 。

解決該問題的方案是雙緩沖，即 GPU 和顯示器都有各自的工作緩沖區(qū)。GPU 始終將完成的一幀繪制數(shù)據(jù)寫入到 Back Buffer，而顯示器使用 Frame Buffer。當(dāng)屏幕刷新時(shí)，F(xiàn)rame Buffer 并不會(huì)發(fā)生變化。Back Buffer 根據(jù)屏幕的刷新將數(shù)據(jù) copy 到 Frame Buffer，這便是 VSYNC 的用武之地。

在 Android 4.1 之前，Android 使用雙緩沖機(jī)制。怎么理解呢？一般來說，同一個(gè) View Hierarchy 內(nèi)的 View 都會(huì)共用一個(gè) Window，也就是共用一個(gè) Surface。

而每個(gè) Surface 都會(huì)有一個(gè) BufferQueue 緩存隊(duì)列，但是這個(gè)隊(duì)列會(huì)由 SurfaceFlinger 管理，通過匿名共享內(nèi)存與 App 應(yīng)用層交互。

整個(gè)流程如下：

Android 一直使用 VSYNC 來阻止屏幕撕裂，對(duì)于 Android 4.0，CPU 可能會(huì)因?yàn)樵诿ζ渌氖虑椋瑢?dǎo)致沒來得及處理 UI 繪制。所以從 4.1 開始 VSYNC 則更進(jìn)一步，VSYNC 脈沖現(xiàn)在用于開始下一幀的所有處理。

VSYNC 類似于時(shí)鐘中斷，每收到 VSYNC 中斷，CPU 會(huì)立即準(zhǔn)備 Buffer 數(shù)據(jù)，由于大部分顯示設(shè)備刷新頻率都是 60Hz（一秒刷新 60 次），也就是說一幀數(shù)據(jù)的準(zhǔn)備工作都要在 16ms（1000/60≈16）內(nèi)完成。

這樣應(yīng)用總是在 VSYNC 邊界上開始繪制，而 SurfaceFlinger 總是在 VSYNC 邊界上進(jìn)行合成。這樣便可以消除卡頓，并提升圖形的視覺表現(xiàn)。

如果理解了雙緩沖機(jī)制的原理，那就非常容易理解什么是三緩沖區(qū)了。如果只有兩個(gè) Graphic Buffer 緩存區(qū) A 和 B，如果 CPU/GPU 繪制過程較長，超過了一個(gè) VSYNC 信號(hào)周期，因?yàn)榫彌_區(qū) B 中的數(shù)據(jù)還沒有準(zhǔn)備完成，所以只能繼續(xù)展示 A 緩沖區(qū)的內(nèi)容，這樣緩沖區(qū) A 和 B 都分別被顯示設(shè)備和 GPU 占用，CPU 則無法準(zhǔn)備下一幀的數(shù)據(jù)。

如果再提供一個(gè)緩沖區(qū)，CPU、GPU 和顯示設(shè)備都能使用各自的緩沖區(qū)工作，互不影響。簡單來說，三緩沖機(jī)制就是在雙緩沖機(jī)制基礎(chǔ)上增加了一個(gè) Graphic Buffer 緩沖區(qū)，這樣可以最大限度利用空閑時(shí)間，帶來的壞處是多使用了一個(gè) Graphic Buffer 所占用的內(nèi)存。

從圖中可以看出，緩沖區(qū) B 花費(fèi)的時(shí)間太長，并且正在使用 A 來顯示當(dāng)前幀。不過這次，系統(tǒng)不是在重復(fù)的緩沖區(qū)中浪費(fèi)時(shí)間，而是創(chuàng)建一個(gè) C 緩沖區(qū)，并開始處理下一幀。三重緩沖降低了 jank 的進(jìn)一步加劇。

三緩沖并不總是存在，通常情況下僅運(yùn)行一個(gè)雙緩沖區(qū)，但是當(dāng)發(fā)生延遲等情況時(shí)，第三個(gè)緩沖區(qū)就會(huì)出現(xiàn)，以便降低延遲的加劇。對(duì)于 VSYNC 信號(hào)和 Triple Buffering 更詳細(xì)的介紹，可以參考《 Project Butter - How it works and What it added？ 》。

Android 渲染框架非常龐大，而且演進(jìn)的非常快。感興趣的朋友可以進(jìn)一步閱讀下面的參考資料。

Android 深入理解單例模式

本文主要記錄使用單例模式的幾種形式，并分析各自的優(yōu)缺點(diǎn)。使用單例模式可以避免重復(fù)創(chuàng)建對(duì)象，以此來節(jié)省開銷，首先了解一下單例模式的四大原則：

常用的單例模式有：餓漢模式、懶漢模式、雙重鎖懶漢模式、靜態(tài)內(nèi)部類模式、枚舉模式，我們來逐個(gè)解釋這些模式的區(qū)別。

關(guān)于 volatile 修飾符，又是一個(gè)內(nèi)容，需要理解：

參考（有例子，比較好理解）： ，

靜態(tài)內(nèi)部類單例模式的優(yōu)點(diǎn)：

那么有人會(huì)問了，如果有多個(gè)線程同時(shí)訪問 getInstance() 方法，會(huì)多次初始化類，然后創(chuàng)建多個(gè)對(duì)象嗎？答案是不會(huì)的，這我們需要了解一下類的加載機(jī)制：

虛擬機(jī)會(huì)保證一個(gè)類的clinit()方法在多線程環(huán)境中被正確地加鎖、同步，如果多個(gè)線程同時(shí)去初始化一個(gè)類，那么只會(huì)有一個(gè)線程去執(zhí)行這個(gè)類的clinit()方法，其他線程都需要阻塞等待，直到活動(dòng)線程執(zhí)行clinit()方法完畢。

所以如果一個(gè)類的clinit()方法中有耗時(shí)很長的操作，就可能造成多個(gè)進(jìn)程阻塞(需要注意的是，其他線程雖然會(huì)被阻塞，但線程喚醒之后不會(huì)再次進(jìn)入clinit()方法。因?yàn)樵谕粋€(gè)加載器下，一個(gè)類只會(huì)初始化一次。)

所以靜態(tài)內(nèi)部類單例模式不僅能保證線程的安全性、實(shí)例的唯一性、還延遲了單例的實(shí)例化。

但是靜態(tài)內(nèi)部類單例模式也有一個(gè) 缺點(diǎn) ，就是無法傳遞參數(shù)。因?yàn)樗峭ㄟ^靜態(tài)內(nèi)部類的形式去創(chuàng)建單例的，所以外部就無法傳遞參數(shù)進(jìn)去。

枚舉單例模式占用的內(nèi)存是靜態(tài)變量的兩倍，所以一般都不使用enum來實(shí)現(xiàn)單例。

單例有餓漢模式、懶漢模式、雙重鎖懶漢模式、靜態(tài)內(nèi)部類模式、枚舉模式這幾種形式。

餓漢模式在初始化類時(shí)就創(chuàng)建了對(duì)象，容易造成資源浪費(fèi)；懶漢模式在多線程環(huán)境下有風(fēng)險(xiǎn)；枚舉模式占用內(nèi)存過高。這三種模式都有明顯的弊端，所以一般不去采用。

雙重鎖懶漢模式使用了 volatile 修飾符，在性能上會(huì)差一點(diǎn)點(diǎn)；靜態(tài)內(nèi)部類模式無法傳遞參數(shù)。但是這兩種方式都能保證實(shí)例的唯一性，線程的安全性，也不會(huì)造成資源的浪費(fèi)。所以我們?cè)谑褂脝卫Ｊ綍r(shí)，可以在這兩種方式中酌情選擇。

參考文章：

徹底理解Android架構(gòu)，打造一個(gè)令人眼前一亮的項(xiàng)目架構(gòu)

架構(gòu)究竟是什么？如何更好的理解架構(gòu)？

我們知道一個(gè)APP通常是由class組成，而這些class之間如何組合，相互之間又如何產(chǎn)生作用，就是影響這個(gè)APP的關(guān)鍵點(diǎn)。

細(xì)分的話我們可以將其分為類、接口、任務(wù)流。

我們?cè)谶M(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，通常具有一定的目的性，用一句話來概括就是： 架構(gòu)設(shè)計(jì)的真正目的是為了解決軟件系統(tǒng)的復(fù)雜度帶來的問題， 所謂高性能、高可用、高擴(kuò)展。

我們將其大致可以分為：易擴(kuò)展、易維護(hù)、可定制、可伸縮

現(xiàn)在我們?cè)谶M(jìn)行設(shè)計(jì)的時(shí)候，一般都會(huì)有要求 高內(nèi)聚、低耦合 ，以此來保證APP的高質(zhì)量

為了方便大家理解，這邊舉個(gè)栗子：

低內(nèi)聚，高耦合：

高內(nèi)聚，低耦合：

大家覺得誰更好維護(hù)？更容易調(diào)整？出錯(cuò)了更容易排查？

我們?cè)诩軜?gòu)設(shè)計(jì)中最本質(zhì)的目的就是管理復(fù)雜度，你聽過的各種思想、原則、方法大多都是為了控制復(fù)雜度而設(shè)計(jì)出來的。

像依賴注入就是項(xiàng)目組件解耦中非常重要的一個(gè)手段，Dagger2 和 Hilt 都是在 Android 中最主要的依賴注入框架。

依賴注入其實(shí)并不是一個(gè)很神秘的概念，往往在不經(jīng)意間我們就使用了依賴注入。依賴注入應(yīng)用了IOC控制反轉(zhuǎn)的原理，簡單來說就是在類的外部構(gòu)造依賴項(xiàng)，使用構(gòu)造器或者 setter 注入。

使用依賴注入可以為我們帶來什么好處呢？

我們都知道Dagger是一個(gè)早期的依賴注入庫，但確實(shí)不好用，需要配置很多東西。雖然它能很好幫我們解耦各個(gè)模塊之間的強(qiáng)關(guān)聯(lián)性，提高項(xiàng)目的健壯性。但其卻以羞澀難懂、難用而聞名，嚇退了很多的開發(fā)者。

Hilt是 Dagger2 的二次封裝， Hilt 本質(zhì)上是對(duì) Dagger 進(jìn)行場景化 。是一個(gè)功能強(qiáng)大且用法簡單的依賴注入框架，同時(shí)也可以說是近期 Jetpack 家族中最重要的一名新成員。但Hilt涉及的知識(shí)點(diǎn)也是相當(dāng)繁多，即使它將 Dagger2 的用法進(jìn)行了大幅的簡化，如果你之前對(duì)于依賴注入完全沒有了解，直接上手 Hilt 還是會(huì)有不少的困難。

在這里問大家?guī)讉€(gè)問題，看看能不能回答上來：

說了這么多，那么我們?nèi)绾螌W(xué)習(xí)Hilt，將IOC技術(shù)融入進(jìn)我們的架構(gòu)設(shè)計(jì)中呢？

為了幫助大家站在高級(jí)工程師的角度，深度理解IOC技術(shù)在移動(dòng)端的實(shí)戰(zhàn)應(yīng)用，同時(shí)掌握移動(dòng)端流行IOC框架Hilt與Dagger2的實(shí)戰(zhàn)應(yīng)用與實(shí)現(xiàn)原理。

在這里分享一份由大佬親自收錄整理的 學(xué)習(xí)PDF+架構(gòu)視頻+面試文檔+源碼筆記 ， 高級(jí)架構(gòu)技術(shù)進(jìn)階腦圖、Android開發(fā)面試專題資料，高級(jí)進(jìn)階架構(gòu)資料

這些都是我現(xiàn)在閑暇時(shí)還會(huì)反復(fù)翻閱的精品資料。里面對(duì)近幾年的大廠面試高頻知識(shí)點(diǎn)都有詳細(xì)的講解。相信可以有效地幫助大家掌握知識(shí)、理解原理，幫助大家在未來取得一份不錯(cuò)的答卷。

當(dāng)然，你也可以拿去查漏補(bǔ)缺，提升自身的競爭力。

真心希望可以幫助到大家，Android路漫漫，共勉！

如果你有需要的話，只需 私信我【進(jìn)階】即可獲取

文章標(biāo)題：android理解,android知識(shí)點(diǎn)
標(biāo)題來源：http://chinadenli.net/article1/dseisod.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、動(dòng)態(tài)網(wǎng)站、靜態(tài)網(wǎng)站、網(wǎng)站改版、網(wǎng)站營銷、網(wǎng)頁設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)