『壹』 android：窗口、自定義view、bitmap
1、ViewRoot 對應於 ViewRootImpl 類，它是連接 WindowManager 和 DecorView 的紐帶，View 的三大流程均是通過 ViewRoot 來完成的。在 ActivityThread 中，當 Activity 對象被創建完畢後，會將 DecorView 添加到 Window 中，同時會創建 ViewRootImpl 對象，並將 ViewRootImpl 對棚彎象和 DecorView 建立關聯
2、 自定義View-繪制流程概述
4、 Android Handler
6、 Android Bitmap
2、MeasureSpec：
3、一般來說，使用多進程會造成以下幾個方面的問題：
5、Window 概念與分類：
Window 是一個抽象類，它的具體實現是 PhoneWindow。WindowManager 是外界訪問 Window 的入口，Window 的具體實現位於 WindowManagerService 中，WindowManager 和 WindowManagerService 的交互是一個 IPC 過程。Android 中所有的視圖都是通過 Window 來呈現，因此 Window 實際是 View 的直接管理者。
6、window的三大操作：addView、upView、removeView
7、 Bitmap 中有兩個內部枚舉類：
保存圖片資源：
圖片壓縮：
基本使用：
8、Context 本身是一個抽象類，是對一系列系統服務介面的封裝，包括：內部伏叢資源、包、類載入、I/O操作、許可權、主線程、IPC 和組件啟動等操作的管理。ContextImpl, Activity, Service, Application 這些都是 Context 的直接或間接子類
9、SharedPreferences 採用key-value（鍵值對）形式, 主要用於輕量級的數據存儲, 尤其適合保存應用的配置參數, 但不建議使用 SharedPreferences 來存儲大規模的數據, 可能會降低性能
10、SharedPreferences源碼有用synchronize進行加鎖同步
11、Handler 有兩個主要用途：
（1）安排 Message 和 runnables 在將來的某個時刻執行;
（2）將要在不同鏈廳悶於自己的線程上執行的操作排入隊列。(在多個線程並發更新UI的同時保證線程安全。)
只有主線程能對UI進行操作，所以在對UI進行跟改之前，ViewRootImpl 對UI操作做了驗證，這個驗證工作是由 ViewRootImpl的 checkThread 方法完成：
12、ThreadLocal 是一個線程內部的數據存儲類，通過它可以在指定的線程中存儲數據，其他線程則無法獲取。Looper、ActivityThread 以及 AMS 中都用到了 ThreadLocal。當不同線程訪問同一個ThreadLocal 的 get方法，ThreadLocal 內部會從各自的線程中取出一個數組，然後再從數組中根據當前 ThreadLcoal 的索引去查找對應的value值：
13、Android 提供了幾種途徑來從其他線程訪問 UI 線程:
Android單線程模式必須遵守的規則：
14、HandlerThread 集成了 Thread，卻和普通的 Thread 有顯著的不同。普通的 Thread 主要用於在 run 方法中執行一個耗時任務，而 HandlerThread 在內部創建了消息隊列，外界需要通過 Handler 的消息方式通知 HanderThread 執行一個具體的任務。
15、IntentService 可用於執行後台耗時的任務，當任務執行後會自動停止，由於其是 Service 的原因，它的優先順序比單純的線程要高，所以 IntentService 適合執行一些高優先順序的後台任務。在實現上，IntentService 封裝了 HandlerThread 和 Handler。IntentService 第一次啟動時，會在 onCreatea 方法中創建一個 HandlerThread，然後使用的 Looper 來構造一個 Handler 對象 mServiceHandler，這樣通過 mServiceHandler 發送的消息最終都會在 HandlerThread 中執行。每次啟動 IntentService，它的 onStartCommand 方法就會調用一次，onStartCommand 中處理每個後台任務的 Intent，onStartCommand 調用了 onStart 方法。可以看出，IntentService 僅僅是通過 mServiceHandler 發送了一個消息，這個消息會在 HandlerThread 中被處理。mServiceHandler 收到消息後，會將 Intent 對象傳遞給 onHandlerIntent 方法中處理，執行結束後，通過 stopSelf(int startId) 來嘗試停止服務。（stopSelf() 會立即停止服務，而 stopSelf(int startId) 則會等待所有的消息都處理完畢後才終止服務）。
16、RecyclerView 優化
『貳』 Android自定義View——從零開始實現書籍翻頁效果（一）
前言 ：本篇是系列博客的第三篇，這次我們要研究 書籍翻頁效果 。不知道大家平時有沒用過iReader、掌閱這些小說軟體，裡面的翻頁效果感覺十分的酷炫。有心想研究研究如何實現，於是網上找了找，發現這方面的教學資料非常少，所幸能找到 何明桂大大 的 Android 實現書籍翻頁效果----原理篇 這樣的入門博客（感謝大大 Orz），我們就以這篇博客為切入點從零實現我們自己的翻頁效果。由於這次坑比較深，預計會寫好幾期，感興趣的小夥伴可以點下關注以便及時收到更新提醒，謝謝大家的支持 ~
本篇只著重於思路和實現步驟，裡面用到的一些知識原理不會非常細地拿來講，如果有不清楚的api或方法可以在網上搜下相應的資料，肯定有大神講得非常清楚的，我這就不獻丑了。本著認真負責的精神我會把相關知識的博文鏈接也貼出來（其實就是懶不想寫那麼多哈哈），大家可以自行傳送。為了照顧第一次閱讀系列博客的小夥伴，本篇會出現一些在之前 系列博客 就講過的內容，看過的童鞋自行跳過該段即可
國際慣例，先上效果圖，本次主要實現了 基本的上下翻頁效果 與 右側最大翻頁距離的限制
在看這篇博客之前，希望大家能先了解一下書籍翻頁的實現原理，博客鏈接我已經貼出來了。通過原理講解我們知道，整個書籍翻頁效果界面分成了三個區域， A 為當前頁區域， B 為下一頁區域， C 為當前頁背面，如圖所示
書籍翻頁效果的實現就是要以我們 觸摸屏幕位置的坐標 為基礎繪制出這三個區域，形成模擬翻頁的特效。要繪制這三個區域，我們需要通過一組 特定的點 來完成，這些點的坐標需要通過兩個已知的點（ 觸摸點 、 相對邊緣角 ）計算得到，下圖我將各個特定點的位置和計算公式貼出來，大家對照著原理一起理解（渣畫工望體諒 ╮(╯▽╰)╭ ），其中 b 點是由 ae 和 cj 的交點， k 點是由 ah 和 cj 的交點
簡單總結一下， a 是觸摸點， f 是觸摸點相對的邊緣角， eh 我們設置為 af 的垂直平分線，則 g 是 af 的中點， ab 、 ak 、 dj 是 直線 ； 曲線cdb 是起點為 c ，控制點為 e ，終點為 b 的 二階貝塞爾曲線 ； 曲線kij 是起點為 k ，控制點為 h ，終點為 j 的 二階貝塞爾曲線 ，區域 A 、 B 、 C 就由這些點和線劃分開來。我們將這些點稱為標識點，下一步就是模擬設定 a 和 f 點的位置，將這組標識點繪制到屏幕上來驗證我們的計算公式是否正確，創建 BookPageView
實體類 MyPoint 用來存放我們的標識點坐標
界面布局：
在Activity中進行注冊
效果如圖
前文我們提到 ab 、 ak 、 dj 是 直線 ； 曲線cdb 是起點為 c ，控制點為 e ，終點為 b 的 二階貝塞爾曲線 ； 曲線kij 是起點為 k ，控制點為 h ，終點為 j 的 二階貝塞爾曲線 。通過觀察分析得知， 區域A 是由View 左上角 ， 左下角 ， 曲線cdb ， 直線 ab 、 ak ， 曲線kij ， 右上角 連接而成的區域，修改 BookPageView ，利用 path 繪制處 區域A
效果如圖
區域C 理論上應該是由點 a , b , d , i , k 連接而成的閉合區域,但由於 d 和 i 是曲線上的點，我們沒辦法直接從 d 出發通過 path 繪制路徑連接 b 點（ i , k 同理），也就不能只用 path 的情況下直接繪制出 區域C ，我們需要用 PorterDuffXfermode 方面的知識「曲線救國」。我們試著先將點 a , b , d , i , k 連接起來，觀察閉合區域與 區域A 之間的聯系。修改 BookPageView
效果如圖
我們將兩條曲線也畫出來對比觀察
觀察分析後可以得出結論， 區域C 是 由直線ab,bd,dj,ik,ak連接而成的區域 減去 與區域A交集部分 後剩餘的區域。於是我們設置 區域C 畫筆 Xfermode 模式為 DST_ATOP
效果如圖
最後是 區域B ，因為 區域B 處於最底層，我們直接將 區域B 畫筆 Xfermode 模式設為 DST_ATOP ，在 區域A、C 之後繪制即可，修改 BookPageView
效果如圖
翻頁可以從右下方翻自然也可以從右上方翻，我們將 f 點設在右上角，由於View上下兩部分是呈 鏡像 的，所以各標識點的位置也應該是鏡像對應的，因為 區域B和C 的繪制與 f 點沒有關系，所以我們只需要修改 區域A 的繪制邏輯，新增 getPathAFromTopRight() 方法
效果如圖
之前由於測試效果沒有對View的大小進行重新測量，在實現觸摸翻頁之前先把這個結了。重寫View的 onMeasure() 方法
我們的需求是，在上半部分翻頁時 f 點在右上角，在下半部分翻頁時 f 則在右下角，當手指離開屏幕時回到 初始狀態 ，根據需求，修改 BookPageView
在Activity中監聽View的 onTouch 狀態
注意，要設置 android:clickable 為 true ，否則無法監聽到 ACTION_MOVE 和 ACTION_UP 狀態
效果如圖
到這里我們已經實現了基本的翻頁效果，但要還原真實的書籍翻頁效果，我們還需要設置一些限制條件來完善我們的項目
對於一般的書本來說，最左側應該是釘起來的，也就是說如果我們從右側翻頁，翻動的距離是 有限制的 ，最下方翻頁形成的曲線起點（ c 點）的x坐標不能小於0（上方同理），按照這個限定條件，修改我們的 BookPageView
效果如圖
至此本篇教程就告一段落了，當然還有許多功能需要繼續完善，例如橫向翻頁、翻頁動畫、陰影效果等等，這些都會在後面的教程中一一解決。如果大家看了感覺還不錯麻煩點個贊，你們的支持是我最大的動力~
『叄』 Android 自定義TextView實現文字兩端對齊
Android組件有很多自帶的屬性，如 android:layout_width、android:layout_height等，使用 attrs.xml 文件，可以自己定義屬性，這里我在 attrs.xml 文件中添加如下屬性，用作判斷是否需要兩端對齊
自定義view計算文字長度實現兩端對齊效果
然後直接在使用布局文件中使用即可
『肆』 Android開發 自定義View
Android自定義View實現很簡單:
1、繼承View，重寫構造函數、onDraw，（onMeasure）等函數。
2、如果自定義的View需要有自定義的屬性，需要在values下建立attrs.xml。在其中定義你的屬性。
3、在使用到自定義View的xml布局文件中需要加入xmlns:前綴="http://schemas.android.com/apk/res/你的自定義View所在的包路徑".
4、在使用自定義屬性的時候，使用前綴：屬性名，如my:textColor="#FFFFFFF"。
實例：
自定義TextView類：
復制代碼
package com.zst.service.component;
import com.example.hello_wangle.R;
import android.content.Context;
import android.content.res.TypedArray;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;
import android.util.AttributeSet;
import android.util.Log;
import android.view.View;
import android.widget.TextView;
public class MyTextView extends TextView {
//不能在布局文件中使用
public MyTextView(Context context) {
super(context);
}
//布局文件中用到此構造函數
『伍』 Carson帶你學Android：手把手教你寫一個完整的自定義View
自定義View一共分為兩大類，具體如下圖：
對於自定義View的類型介紹及使用場景如下圖：
在使用自定義View時有很多注意點（坑），希望大家要非常留意：
View的內部本身提供了post系列的方法，完全可以替代Handler的作用，使用起來更加方便、直接。
主要針對View中含有線程或動畫的情況： 當View退出或不可見時，記得及時停止該View包含的線程和動畫，否則會造成內存泄露問題 。
當View帶有滑動嵌套情況時，必須要處理好滑動沖突，否則會嚴重影響View的顯示效果。
接下來，我將用自定義View中最常用的 繼承View 來說明自定義View的具體應用和需要注意的點
在下面的例子中，我將講解：
下面我將逐個步驟進行說明：
步驟1：創建自定義View類（繼承View類）
特別注意：
步驟2：在布局文件中添加自定義View類的組件及顯示
至此，一個基本的自定義View已經實現了，運行效果如下圖。
接下來繼續看自定義View關於屬性自定義的問題：
先來看wrap_content & match_parent屬性的區別
如果不手動設置支持 wrap_content 屬性，那麼 wrap_content 屬性是不會生效（顯示效果同 match_parent ）
padding 屬性：用於設置控制項內容相對控制項邊緣的邊距；
如果不手動設置支持padding屬性，那麼padding屬性在自定義View中是不會生效的。
繪制時考慮傳入的padding屬性值（四個方向）。
除了常見的以android:開頭的系統屬性(如下所示)，很多場景下自定義View還需要系統所沒有的屬性，即自定義屬性。
實現自定義屬性的步驟如下：
下面我將對每個步驟進行具體介紹
對於自定義屬性類型 & 格式如下：
至此，一個較為規范的自定義View已經完成了。
Carson_Ho的github： 自定義View的具體應用
不定期分享關於 安卓開發 的干貨，追求 短、平、快 ，但 卻不缺深度 。
『陸』 Android 自定義View之Layout過程
系列文章：
在上篇文章： Android 自定義View之Measure過程 ，我們分析了Measure過程，本次將會掀開承上啟下的Layout過程神秘面紗，
通過本篇文章，你將了解到：
在上篇文章的比喻里，我們說過：
該ViewGroup 重寫了onMeasure(xx)和onLayout(xx)方法：
同時，當layout 執行結束，清除PFLAG_FORCE_LAYOUT標記，該標記會影響Measure過程是否需要執行onMeasure。
該View 重寫了onMeasure(xx)和onLayout(xx)方法：
MyViewGroup里添加了MyView、Button兩個控制項，最終運行的效果如下：
可以看出，MyViewGroup 里子布局的是橫向擺放的。我們重點關注Layout過程。實際上，MyViewGroup里我們只重寫了onLayout(xx)方法，MyView也是重寫了onLayout(xx)方法。
接下來，分析View Layout過程。
與Measure過程類似，連接ViewGroup onLayout(xx)和View onLayout(xx)之間的橋梁是View layout(xx)。
可以看出，最終都調用了setFrame(xx)方法。
對於Measure過程在onMeasure(xx)里記錄了尺寸的值，而對於Layout過程則在layout(xx)里記錄了坐標值，具體來說是在setFrame(xx)里，該方法兩個重點地方：
View.onLayout(xx)是空實現
從layout(xx)和onLayout(xx)聲明可知，這兩個方法都是可以被重寫的，接下來看看ViewGroup是否重寫了它們。
ViewGroup.layout(xx)雖然重寫了layout(xx)，但是僅僅做了簡單判斷，最後還是調用了View.layout(xx)。
這重寫後將onLayout變為抽象方法，也就是說繼承自ViewGroup的類必須重寫onLayout(xx)方法。
我們以FrameLayout為例，分析其onLayout(xx)做了什麼。
FrameLayout.onLayout(xx)為子布局Layout的時候，起始坐標都是以FrameLayout為基準，並沒有記錄上一個子布局佔了哪塊位置，因此子布局的擺放位置可能會重疊，這也是FrameLayout布局特性的由來。而我們之前的Demo在水平方向上記錄了上一個子布局的擺放位置，下一個擺放時只能在它之後，因此就形成了水平擺放的功能。
由此類推，我們常說的某個子布局在父布局裡的哪個位置，決定這個位置的即是ViewGroup.onLayout(xx)。
上邊我們分析了View.layout(xx)、View.onLayout(xx)、ViewGroup.layout(xx)、ViewGroup.onLayout(xx)，這四者什麼關系呢？
View.layout(xx)
View.onLayout(xx)
ViewGroup.layout(xx)
ViewGroup.onLayout(xx)
View/ViewGroup 子類需要重寫哪些方法：
用圖表示：
通過上述的描述，我們發現Measure過程和Layout過程里定義的方法比較類似：
它倆的套路比較類似：measure(xx)、layout(xx)一般不需要我們重寫，measure(xx)里調用onMeasure(xx)，layout(xx)為調用者設置坐標值。
若是ViewGroup：onMeasure(xx)里遍歷子布局，並測量每個子布局，最後將結果匯總，設置自己測量的尺寸；onLayout(xx)里遍歷子布局，並設置每個子布局的坐標。
若是View：onMeasure(xx)則測量自身，並存儲測量尺寸；onLayout(xx)不需要做什麼。
Measure過程雖然比Layout過程復雜，但仔細分析後就會發現其本質就是為了設置兩個成員變數：
而Layout過程雖然比較簡單，其本質是為了設置坐標值
將Measure設置的變數和Layout設置的變數聯系起來：
此外，Measure過程通過設置PFLAG_LAYOUT_REQUIRED 標記來告訴需要進行onLayout，而Layout過程通過清除 PFLAG_FORCE_LAYOUT來告訴Measure過程不需要執行onMeasure了。
這就是Layout的承上作用
我們知道View的繪制需要依靠Canvas繪制，而Canvas是有作用區域限制的。例如我們使用：
Cavas繪制的起點是哪呢？
對於硬體繪制加速來說：正是通過Layout過程中設置的RenderNode坐標。
而對於軟體繪制來說：
關於硬體繪制加速/軟體繪制 後續文章會分析。
這就是Layout的啟下作用
以上即是Measure、Layout、Draw三者的內在聯系。
當然Layout的"承上"還需要考慮margin、gravity等參數的影響。具體用法參見最開始的Demo。
getMeasuredWidth()/getMeasuredHeight 與 getWidth/getHeight區別
我們以獲取width為例，分別來看看其方法：
getMeasuredWidth()：獲取測量的寬，屬於"臨時值"
getWidth()：獲取View真實的寬
在Layout過程之前，getWidth() 默認為0
何時可以獲取真實的寬、高
下篇將分析Draw()過程，我們將分析"一切都是draw出來的"道理
本篇基於 Android 10.0