From 24b053cd768a80796a83fce329221e9e045ba11a Mon Sep 17 00:00:00 2001
From: "jixin.li" <jixin.li@jiduauto.com>
Date: Fri, 6 Dec 2024 18:09:36 +0800
Subject: [PATCH] Site updated: 2024-12-06 18:09:35

---
 2014/12/23/hello-world/index.html             |   2 +-
 2015/01/27/android-open-sources/index.html    |   2 +-
 .../java-multithreading-concurrent/index.html |   2 +-
 2015/11/06/book-list-of-2015/index.html       |   2 +-
 .../01/android-googlemap-summary/index.html   |   2 +-
 2016/03/15/facebook-google+signin/index.html  |   2 +-
 2016/03/20/android-books-reading-/index.html  |   2 +-
 .../android-new-knowledge-summary/index.html  |   2 +-
 2016/05/12/GCM-Azure_summary/index.html       |   2 +-
 2016/05/18/javaString-and-bytes/index.html    |   2 +-
 2016/05/24/JNI-Learning/index.html            |   2 +-
 2016/05/24/JNI-Learning0/index.html           |   2 +-
 2016/05/28/qiniu-android-summary/index.html   |   2 +-
 2016/06/08/gson-summary/index.html            |   2 +-
 2016/07/25/android-webview-summary/index.html |   2 +-
 .../08/03/android-LocationListener/index.html |   2 +-
 2016/08/16/RxAndroid-Learning/index.html      |   2 +-
 .../index.html                                |   2 +-
 2016/09/20/AVG-unwanted-software/index.html   |   2 +-
 .../index.html                                |   2 +-
 2016/09/22/JNI-get-publickey/index.html       |   2 +-
 2016/09/22/quit-whole-application/index.html  |   2 +-
 .../28/Android-interview-questions/index.html |   2 +-
 2016/10/12/gradle-learning/index.html         |   2 +-
 2016/10/13/gradle-learning2/index.html        |   2 +-
 .../03/hexo-mac-module-not-found/index.html   |   2 +-
 .../21/Difference_between-T-E-K-V/index.html  |   2 +-
 .../index.html                                |   2 +-
 2016/12/04/hexo-learning0/index.html          |   2 +-
 2016/12/06/hexo-learning1/index.html          |   2 +-
 2016/12/11/ThreadLocal-usage/index.html       |   2 +-
 2016/12/20/Android-patch-update/index.html    |   2 +-
 .../13/abroad-IM-service-company/index.html   |   2 +-
 2017/02/12/iterm2-to-linux/index.html         |   2 +-
 2017/02/21/Multi-Process-Dispatch/index.html  |   2 +-
 2017/03/09/Https-Questions/index.html         |   2 +-
 2017/03/14/JAVA-JSR-330-Assertion/index.html  |   2 +-
 2017/03/20/SVN-server-linux/index.html        |   2 +-
 .../04/10/Annotation-Android-usage/index.html |   2 +-
 2017/05/11/Object-Oriented/index.html         |   2 +-
 .../18/handler-replace-timertask/index.html   |   2 +-
 .../07/08/android-binder-principle/index.html |   2 +-
 .../10/android-binder-principle2/index.html   |   2 +-
 2017/07/12/android-noroot-hook/index.html     |   2 +-
 2017/08/01/aosp-compile/index.html            |   2 +-
 2017/08/02/activity-start-process/index.html  |   2 +-
 2017/08/17/IntervieweeQuestions/index.html    |   2 +-
 2017/09/12/PBOCKonwledge/index.html           |   2 +-
 2017/09/21/PBOCKonwledgeCode/index.html       |   2 +-
 .../index.html                                |   2 +-
 2017/10/22/JavaScript-knowledge/index.html    |   2 +-
 2017/12/02/Python-knowledge/index.html        |   2 +-
 .../Toastmaster-self-introduction/index.html  |   2 +-
 2018/02/24/Mac-terminal-command/index.html    |   2 +-
 .../01/IntervieweeQuestions-senior/index.html |   2 +-
 2018/03/14/IntentService-AsyncTask/index.html |   2 +-
 .../02/Toastmaster-two-drawbacks/index.html   |   2 +-
 2018/04/23/Usage-of-genericity/index.html     |   2 +-
 2018/06/08/JVM-stack-heap-GC/index.html       |   2 +-
 .../26/Toastmaster-md-introduction/index.html |   2 +-
 .../22/Handler-Looper-MessageQueue/index.html |   2 +-
 .../06/Android-audio-introduction/index.html  |   2 +-
 .../Android-request-memory-leaks/index.html   |   2 +-
 .../index.html                                |   2 +-
 2019/05/27/TCP-Three-way-Handshake/index.html |   2 +-
 .../30/RecyclerView-Design-Pattern/index.html |   2 +-
 .../05/31/RecyclerView-source-code/index.html |   2 +-
 .../17/RecyclerView-pre-initiate/index.html   |   2 +-
 2019/07/30/LeakCanary_source_code/index.html  |   2 +-
 2019/09/12/Horizontal-Coordinator/index.html  |   2 +-
 2019/12/08/Android-bits-operation/index.html  |   2 +-
 2019/12/09/Android-Measure/index.html         |   2 +-
 .../26/download-function-analysis/index.html  |   2 +-
 2020/07/10/profile_analysis/index.html        |   2 +-
 2020/08/31/JVM-stack-and_heap/index.html      |   2 +-
 2020/09/07/Kotlin-DSL/index.html              |   2 +-
 .../Diffrence-between-kotlin&Java/index.html  |   2 +-
 .../RecyclerView_scroll_relatedapi/index.html |   2 +-
 .../04/19/Android-PIP-Hack-summary/index.html |   2 +-
 2021/06/07/ANR-summary/index.html             |   2 +-
 2021/07/18/gradle-plugin/index.html           |   2 +-
 2021/07/18/recyclerview-cache/index.html      |   2 +-
 2021/08/07/view-scroll-apis/index.html        |   2 +-
 2021/12/14/AOP-android/index.html             |   2 +-
 .../10/android-binder-principle3/index.html   |   2 +-
 2022/02/13/Java-summary/index.html            |   2 +-
 2022/03/28/sp-source-code-analysis/index.html |   2 +-
 2022/07/21/async-inflate-strategy/index.html  |   2 +-
 2022/08/08/anr-trigger-principle/index.html   |   2 +-
 2023/02/10/constraintlayout-intro/index.html  |   2 +-
 2023/09/26/matrix-trace-canary/index.html     |   2 +-
 2023/10/26/cross-process-bridge/index.html    |   2 +-
 2023/11/02/native-crash-principle/index.html  |   2 +-
 .../native-crash-anr-log-analysis/index.html  |   2 +-
 2024/04/24/jacoco-test-coverage/index.html    |   2 +-
 .../matrix-io-canary-introducation/index.html |   2 +-
 .../index.html                                |  69 ++-
 baidusitemap.xml                              | 460 +++++++++---------
 content.json                                  |   2 +-
 index.html                                    |  21 +-
 page/10/index.html                            |  16 +-
 page/11/index.html                            |  16 +-
 page/12/index.html                            |  16 +-
 page/13/index.html                            |   2 +-
 page/2/index.html                             |  16 +-
 page/3/index.html                             |  16 +-
 page/4/index.html                             |  16 +-
 page/5/index.html                             |  16 +-
 page/6/index.html                             |  16 +-
 page/7/index.html                             |  16 +-
 page/8/index.html                             |  16 +-
 page/9/index.html                             |  16 +-
 sitemap.xml                                   |  92 ++--
 113 files changed, 534 insertions(+), 480 deletions(-)

diff --git a/2014/12/23/hello-world/index.html b/2014/12/23/hello-world/index.html
index 50b00af74..17df983ce 100644
--- a/2014/12/23/hello-world/index.html
+++ b/2014/12/23/hello-world/index.html
@@ -657,7 +657,7 @@ <h3 id="Deploy-to-remote-sites"><a href="#Deploy-to-remote-sites" class="headerl
 
 </div>
 
-    <a data-url="http://agehua.github.io/2014/12/23/hello-world/" data-id="cm4b8fqj90008d547ilryjv84" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2014/12/23/hello-world/" data-id="cm4cl3h4z0000sl47vk8znx1u" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2015/01/27/android-open-sources/index.html b/2015/01/27/android-open-sources/index.html
index f0b1f2101..81ebb4e5a 100644
--- a/2015/01/27/android-open-sources/index.html
+++ b/2015/01/27/android-open-sources/index.html
@@ -706,7 +706,7 @@ <h3 id="顺便推荐大家几个网站："><a href="#顺便推荐大家几个网
 
 </div>
 
-    <a data-url="http://agehua.github.io/2015/01/27/android-open-sources/" data-id="cm4b8fqiw0000d547wkbe3kyh" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2015/01/27/android-open-sources/" data-id="cm4cl3h590004sl47wc24ubi3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2015/03/16/java-multithreading-concurrent/index.html b/2015/03/16/java-multithreading-concurrent/index.html
index 261ff55ed..52b35e731 100644
--- a/2015/03/16/java-multithreading-concurrent/index.html
+++ b/2015/03/16/java-multithreading-concurrent/index.html
@@ -765,7 +765,7 @@ <h1 id="好文推荐"><a href="#好文推荐" class="headerlink" title="好文
 
 </div>
 
-    <a data-url="http://agehua.github.io/2015/03/16/java-multithreading-concurrent/" data-id="cm4b8fqj30002d547niqaox8t" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2015/03/16/java-multithreading-concurrent/" data-id="cm4cl3h560002sl470grxrzp7" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2015/11/06/book-list-of-2015/index.html b/2015/11/06/book-list-of-2015/index.html
index 3d3c1b818..a7f570ab1 100644
--- a/2015/11/06/book-list-of-2015/index.html
+++ b/2015/11/06/book-list-of-2015/index.html
@@ -654,7 +654,7 @@ <h1 class="article-title" itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2015/11/06/book-list-of-2015/" data-id="cm4b8fqj70006d547ues8fxny" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2015/11/06/book-list-of-2015/" data-id="cm4cl3h5c0009sl47bsjk75mr" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/03/01/android-googlemap-summary/index.html b/2016/03/01/android-googlemap-summary/index.html
index 357803ebb..912dd6a35 100644
--- a/2016/03/01/android-googlemap-summary/index.html
+++ b/2016/03/01/android-googlemap-summary/index.html
@@ -684,7 +684,7 @@ <h3 id="3-在真机上测试效果"><a href="#3-在真机上测试效果" class=
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/01/android-googlemap-summary/" data-id="cm4b8fqjg000cd547ayhuj658" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/01/android-googlemap-summary/" data-id="cm4cl3h8x007zsl47mwtwixh0" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/03/15/facebook-google+signin/index.html b/2016/03/15/facebook-google+signin/index.html
index 37a10f0ff..18b47f8f2 100644
--- a/2016/03/15/facebook-google+signin/index.html
+++ b/2016/03/15/facebook-google+signin/index.html
@@ -723,7 +723,7 @@ <h3 id="6-fragment事件穿透"><a href="#6-fragment事件穿透" class="headerl
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/15/facebook-google+signin/" data-id="cm4b8fqjc0009d547t8w3y3me" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/15/facebook-google+signin/" data-id="cm4cl3h5c0008sl478q4jr9sw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/03/20/android-books-reading-/index.html b/2016/03/20/android-books-reading-/index.html
index edc2ff236..0d5e06ff0 100644
--- a/2016/03/20/android-books-reading-/index.html
+++ b/2016/03/20/android-books-reading-/index.html
@@ -894,7 +894,7 @@ <h5 id="3-ContentProvider的android-multiprocess属性决定它是否是单实
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/20/android-books-reading-/" data-id="cm4b8fqjj000dd547h1edrzk9" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/20/android-books-reading-/" data-id="cm4cl3h5d000asl4752zsri1l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/03/20/android-new-knowledge-summary/index.html b/2016/03/20/android-new-knowledge-summary/index.html
index fa14642b9..551310f0b 100644
--- a/2016/03/20/android-new-knowledge-summary/index.html
+++ b/2016/03/20/android-new-knowledge-summary/index.html
@@ -709,7 +709,7 @@ <h3 id="五-setSystemUiVisibility-View-SYSTEM-UI-FLAG-HIDE-NAVIGATION-的限制"
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/20/android-new-knowledge-summary/" data-id="cm4b8fqjm000od5470r3xyolq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/20/android-new-knowledge-summary/" data-id="cm4cl3h5k000esl47vcwzks80" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/05/12/GCM-Azure_summary/index.html b/2016/05/12/GCM-Azure_summary/index.html
index 1671074ec..4cf586175 100644
--- a/2016/05/12/GCM-Azure_summary/index.html
+++ b/2016/05/12/GCM-Azure_summary/index.html
@@ -680,7 +680,7 @@ <h3 id="4-Android4-4以上系统根据Uri正确获取文件路径的方法"><a h
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/12/GCM-Azure_summary/" data-id="cm4b8fqjn000qd547q24lluw5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/12/GCM-Azure_summary/" data-id="cm4cl3h5h000dsl4796rdo9bf" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/05/18/javaString-and-bytes/index.html b/2016/05/18/javaString-and-bytes/index.html
index 78cd4967c..3f1fd1ea8 100644
--- a/2016/05/18/javaString-and-bytes/index.html
+++ b/2016/05/18/javaString-and-bytes/index.html
@@ -677,7 +677,7 @@ <h3 id="7，其他资料"><a href="#7，其他资料" class="headerlink" title="
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/18/javaString-and-bytes/" data-id="cm4b8fqjl000hd547tup28n1z" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/18/javaString-and-bytes/" data-id="cm4cl3h5o000isl472gxizxpw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/05/24/JNI-Learning/index.html b/2016/05/24/JNI-Learning/index.html
index eb02054b2..4c175058a 100644
--- a/2016/05/24/JNI-Learning/index.html
+++ b/2016/05/24/JNI-Learning/index.html
@@ -816,7 +816,7 @@ <h4 id="8-1-更新内容，JNI获取publickey实现"><a href="#8-1-更新内容
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning/" data-id="cm4b8fqjl000kd547ba7whzux" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning/" data-id="cm4cl3h5p000ksl4770975p17" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/05/24/JNI-Learning0/index.html b/2016/05/24/JNI-Learning0/index.html
index 5d93b9302..1fa073c91 100644
--- a/2016/05/24/JNI-Learning0/index.html
+++ b/2016/05/24/JNI-Learning0/index.html
@@ -941,7 +941,7 @@ <h3 id="3-JNI知识积累"><a href="#3-JNI知识积累" class="headerlink" title
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning0/" data-id="cm4b8fqjv001md547ogp7tlc1" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning0/" data-id="cm4cl3h5q000osl47u2tvsy2y" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/05/28/qiniu-android-summary/index.html b/2016/05/28/qiniu-android-summary/index.html
index 72bc1a352..ca9cf78a6 100644
--- a/2016/05/28/qiniu-android-summary/index.html
+++ b/2016/05/28/qiniu-android-summary/index.html
@@ -682,7 +682,7 @@ <h3 id="2-代码"><a href="#2-代码" class="headerlink" title="2.代码"></a>2.
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/28/qiniu-android-summary/" data-id="cm4b8fqjw001pd5473h58m9yy" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/28/qiniu-android-summary/" data-id="cm4cl3h5r000vsl4743q1wqeu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/06/08/gson-summary/index.html b/2016/06/08/gson-summary/index.html
index 076eaff5a..b07389c02 100644
--- a/2016/06/08/gson-summary/index.html
+++ b/2016/06/08/gson-summary/index.html
@@ -700,7 +700,7 @@ <h3 id="3-第二种情况，举例"><a href="#3-第二种情况，举例" class=
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/06/08/gson-summary/" data-id="cm4b8fqjn000td547l819prag" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/06/08/gson-summary/" data-id="cm4cl3h5r000rsl47gskjvvmq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/07/25/android-webview-summary/index.html b/2016/07/25/android-webview-summary/index.html
index a88c0d6a6..b6318ba18 100644
--- a/2016/07/25/android-webview-summary/index.html
+++ b/2016/07/25/android-webview-summary/index.html
@@ -703,7 +703,7 @@ <h3 id="3-Android中WebView的JavaScript代码和本地代码交互的三种方
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/07/25/android-webview-summary/" data-id="cm4b8fqjo000xd547wbfvahp2" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/07/25/android-webview-summary/" data-id="cm4cl3h5t0011sl47wzibx7v3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/08/03/android-LocationListener/index.html b/2016/08/03/android-LocationListener/index.html
index 083cc44fc..9a39bebc1 100644
--- a/2016/08/03/android-LocationListener/index.html
+++ b/2016/08/03/android-LocationListener/index.html
@@ -670,7 +670,7 @@ <h3 id="1-LocationListener使用"><a href="#1-LocationListener使用" class="hea
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/08/03/android-LocationListener/" data-id="cm4b8fqjo000vd547ow5yrm1x" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/08/03/android-LocationListener/" data-id="cm4cl3h5s000ysl4714gvwiac" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/08/16/RxAndroid-Learning/index.html b/2016/08/16/RxAndroid-Learning/index.html
index 55cde4646..401c9aa78 100644
--- a/2016/08/16/RxAndroid-Learning/index.html
+++ b/2016/08/16/RxAndroid-Learning/index.html
@@ -764,7 +764,7 @@ <h3 id="6-特殊的情况"><a href="#6-特殊的情况" class="headerlink" title
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/08/16/RxAndroid-Learning/" data-id="cm4b8fqju001id547j37ee0m8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/08/16/RxAndroid-Learning/" data-id="cm4cl3h5w001csl47l87a7m0y" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/09/05/ThreadLocal-HandlerThread-Looper/index.html b/2016/09/05/ThreadLocal-HandlerThread-Looper/index.html
index 2e1c9c13a..5cad7e720 100644
--- a/2016/09/05/ThreadLocal-HandlerThread-Looper/index.html
+++ b/2016/09/05/ThreadLocal-HandlerThread-Looper/index.html
@@ -723,7 +723,7 @@ <h3 id="5-HandlerThread"><a href="#5-HandlerThread" class="headerlink" title="5.
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/" data-id="cm4b8fqjq0015d5471epragt4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/" data-id="cm4cl3h5y001hsl47ks1qnwln" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/09/20/AVG-unwanted-software/index.html b/2016/09/20/AVG-unwanted-software/index.html
index f5d465712..b58f59d77 100644
--- a/2016/09/20/AVG-unwanted-software/index.html
+++ b/2016/09/20/AVG-unwanted-software/index.html
@@ -676,7 +676,7 @@ <h3 id="排查"><a href="#排查" class="headerlink" title="排查"></a>排查</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/20/AVG-unwanted-software/" data-id="cm4b8fqjp0012d547grsro2xc" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/20/AVG-unwanted-software/" data-id="cm4cl3h5t0015sl47w8g73c8l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/09/20/android-design-pattern-singleton/index.html b/2016/09/20/android-design-pattern-singleton/index.html
index 074b66818..f09fbdd69 100644
--- a/2016/09/20/android-design-pattern-singleton/index.html
+++ b/2016/09/20/android-design-pattern-singleton/index.html
@@ -749,7 +749,7 @@ <h3 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/20/android-design-pattern-singleton/" data-id="cm4b8fqjr0019d547sdq9ph8p" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/20/android-design-pattern-singleton/" data-id="cm4cl3h5x001esl47yomn6qzh" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/09/22/JNI-get-publickey/index.html b/2016/09/22/JNI-get-publickey/index.html
index dd707a3c6..f7b40ce2a 100644
--- a/2016/09/22/JNI-get-publickey/index.html
+++ b/2016/09/22/JNI-get-publickey/index.html
@@ -709,7 +709,7 @@ <h3 id="3-附赠版本兼容的方法问题（随时更新）"><a href="#3-附
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/22/JNI-get-publickey/" data-id="cm4b8fqjs001fd547zyfvtvnb" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/22/JNI-get-publickey/" data-id="cm4cl3h5z001rsl47ksfo851y" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/09/22/quit-whole-application/index.html b/2016/09/22/quit-whole-application/index.html
index efccd7903..8b20721af 100644
--- a/2016/09/22/quit-whole-application/index.html
+++ b/2016/09/22/quit-whole-application/index.html
@@ -695,7 +695,7 @@ <h3 id="4-JNI实现守护进程"><a href="#4-JNI实现守护进程" class="heade
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/22/quit-whole-application/" data-id="cm4b8fqjr001cd547fsfs3xgl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/22/quit-whole-application/" data-id="cm4cl3h5u0018sl47psa8r85n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/09/28/Android-interview-questions/index.html b/2016/09/28/Android-interview-questions/index.html
index ab0af2f53..8057a7c05 100644
--- a/2016/09/28/Android-interview-questions/index.html
+++ b/2016/09/28/Android-interview-questions/index.html
@@ -789,7 +789,7 @@ <h4 id="使用-DialogFragment-创建对话框"><a href="#使用-DialogFragment-
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/28/Android-interview-questions/" data-id="cm4b8fqk2001wd547iigxoyto" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/28/Android-interview-questions/" data-id="cm4cl3h61001wsl47w1qu5q7n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/10/12/gradle-learning/index.html b/2016/10/12/gradle-learning/index.html
index fa4ec522e..404e039fb 100644
--- a/2016/10/12/gradle-learning/index.html
+++ b/2016/10/12/gradle-learning/index.html
@@ -727,7 +727,7 @@ <h4 id="依赖关系管理"><a href="#依赖关系管理" class="headerlink" tit
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/10/12/gradle-learning/" data-id="cm4b8fqk1001sd547rfckzlay" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/10/12/gradle-learning/" data-id="cm4cl3h5y001ksl473i9m18zl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/10/13/gradle-learning2/index.html b/2016/10/13/gradle-learning2/index.html
index 6ce3d2fcf..b73454b14 100644
--- a/2016/10/13/gradle-learning2/index.html
+++ b/2016/10/13/gradle-learning2/index.html
@@ -782,7 +782,7 @@ <h4 id="获取debug-keystore的SHA1和MD5"><a href="#获取debug-keystore的SHA1
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/10/13/gradle-learning2/" data-id="cm4b8fqk40026d547r09s4v0g" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/10/13/gradle-learning2/" data-id="cm4cl3h5z001osl47uxpi6omg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/11/03/hexo-mac-module-not-found/index.html b/2016/11/03/hexo-mac-module-not-found/index.html
index 48a6d0a25..816bdd805 100644
--- a/2016/11/03/hexo-mac-module-not-found/index.html
+++ b/2016/11/03/hexo-mac-module-not-found/index.html
@@ -679,7 +679,7 @@ <h4 id="Error-Cannot-find-module-‘-build-Release-DTraceProviderBindings’"><a
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/" data-id="cm4b8fqk6002ad547vj33spfj" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/" data-id="cm4cl3h60001usl47my906ls3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/11/21/Difference_between-T-E-K-V/index.html b/2016/11/21/Difference_between-T-E-K-V/index.html
index 83541a2a4..4ee578b27 100644
--- a/2016/11/21/Difference_between-T-E-K-V/index.html
+++ b/2016/11/21/Difference_between-T-E-K-V/index.html
@@ -739,7 +739,7 @@ <h3 id="3-下来说说T，Class，Class-lt-gt-区别"><a href="#3-下来说说T
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/" data-id="cm4b8fqk8002gd54752pxmjc1" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/" data-id="cm4cl3h61001zsl47r5pkt0hn" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/12/03/nodejs-learning-getting-started/index.html b/2016/12/03/nodejs-learning-getting-started/index.html
index 6666ba188..e24fc7532 100644
--- a/2016/12/03/nodejs-learning-getting-started/index.html
+++ b/2016/12/03/nodejs-learning-getting-started/index.html
@@ -999,7 +999,7 @@ <h3 id="总结与展望"><a href="#总结与展望" class="headerlink" title="
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/" data-id="cm4b8fqq700e4d5474n9nqyfq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/" data-id="cm4cl3hbw00ebsl47ls5zd8ri" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/12/04/hexo-learning0/index.html b/2016/12/04/hexo-learning0/index.html
index f3150b8bc..5336afe28 100644
--- a/2016/12/04/hexo-learning0/index.html
+++ b/2016/12/04/hexo-learning0/index.html
@@ -753,7 +753,7 @@ <h4 id="Block-Grid"><a href="#Block-Grid" class="headerlink" title="Block Grid">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/04/hexo-learning0/" data-id="cm4b8fqk30023d547899vm599" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/04/hexo-learning0/" data-id="cm4cl3h66002csl47ziowaiwf" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/12/06/hexo-learning1/index.html b/2016/12/06/hexo-learning1/index.html
index e01fdcb04..e6aefd6a1 100644
--- a/2016/12/06/hexo-learning1/index.html
+++ b/2016/12/06/hexo-learning1/index.html
@@ -766,7 +766,7 @@ <h3 id="参考资源"><a href="#参考资源" class="headerlink" title="参考
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/06/hexo-learning1/" data-id="cm4b8fqk2001zd547ltiu62gp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/06/hexo-learning1/" data-id="cm4cl3h630022sl47dxgtx3vn" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/12/11/ThreadLocal-usage/index.html b/2016/12/11/ThreadLocal-usage/index.html
index 16d95c3ae..400be354e 100644
--- a/2016/12/11/ThreadLocal-usage/index.html
+++ b/2016/12/11/ThreadLocal-usage/index.html
@@ -769,7 +769,7 @@ <h4 id="table扩容"><a href="#table扩容" class="headerlink" title="table扩
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/11/ThreadLocal-usage/" data-id="cm4b8fqk8002dd547ef878n0g" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/11/ThreadLocal-usage/" data-id="cm4cl3h69002gsl47tql5sneg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2016/12/20/Android-patch-update/index.html b/2016/12/20/Android-patch-update/index.html
index e2ce9856d..650adee26 100644
--- a/2016/12/20/Android-patch-update/index.html
+++ b/2016/12/20/Android-patch-update/index.html
@@ -714,7 +714,7 @@ <h3 id="增量更新存在的不足"><a href="#增量更新存在的不足" clas
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/20/Android-patch-update/" data-id="cm4b8fqka002md547pylpxkxt" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/20/Android-patch-update/" data-id="cm4cl3h650026sl47i9kdq5q4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/01/13/abroad-IM-service-company/index.html b/2017/01/13/abroad-IM-service-company/index.html
index 53f6434ab..4c3ce39b1 100644
--- a/2017/01/13/abroad-IM-service-company/index.html
+++ b/2017/01/13/abroad-IM-service-company/index.html
@@ -789,7 +789,7 @@ <h4 id="2-3-更多比较："><a href="#2-3-更多比较：" class="headerlink" t
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/01/13/abroad-IM-service-company/" data-id="cm4b8fqka002pd547nyk673jp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/01/13/abroad-IM-service-company/" data-id="cm4cl3h660029sl470xncvxof" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/02/12/iterm2-to-linux/index.html b/2017/02/12/iterm2-to-linux/index.html
index bcec201f4..bc2bc525d 100644
--- a/2017/02/12/iterm2-to-linux/index.html
+++ b/2017/02/12/iterm2-to-linux/index.html
@@ -693,7 +693,7 @@ <h4 id="iTerm从mac传文件到linux"><a href="#iTerm从mac传文件到linux" cl
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/02/12/iterm2-to-linux/" data-id="cm4b8fqkb002rd547j09y5zg7" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/02/12/iterm2-to-linux/" data-id="cm4cl3h6e002xsl47h75jnala" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/02/21/Multi-Process-Dispatch/index.html b/2017/02/21/Multi-Process-Dispatch/index.html
index 10984cb37..e50218b0b 100644
--- a/2017/02/21/Multi-Process-Dispatch/index.html
+++ b/2017/02/21/Multi-Process-Dispatch/index.html
@@ -698,7 +698,7 @@ <h4 id="二、剥离出一个类，具有同Application相同的生命周期方
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/" data-id="cm4b8fqkd0032d5473wwgg3xv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/" data-id="cm4cl3h6d002tsl478a65864o" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/03/09/Https-Questions/index.html b/2017/03/09/Https-Questions/index.html
index 0e7a96c98..2dfb5bc7c 100644
--- a/2017/03/09/Https-Questions/index.html
+++ b/2017/03/09/Https-Questions/index.html
@@ -714,7 +714,7 @@ <h3 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/03/09/Https-Questions/" data-id="cm4b8fqkb002vd54784imqowl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/03/09/Https-Questions/" data-id="cm4cl3h6a002isl47ham6tkpq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/03/14/JAVA-JSR-330-Assertion/index.html b/2017/03/14/JAVA-JSR-330-Assertion/index.html
index ad5bb7954..5a7c8b854 100644
--- a/2017/03/14/JAVA-JSR-330-Assertion/index.html
+++ b/2017/03/14/JAVA-JSR-330-Assertion/index.html
@@ -736,7 +736,7 @@ <h3 id="assertion-断言"><a href="#assertion-断言" class="headerlink" title="
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/" data-id="cm4b8fqkf003ad547wznvr6lj" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/" data-id="cm4cl3h6b002nsl47hj7p1c4d" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/03/20/SVN-server-linux/index.html b/2017/03/20/SVN-server-linux/index.html
index e783650c0..8d7f8ab0e 100644
--- a/2017/03/20/SVN-server-linux/index.html
+++ b/2017/03/20/SVN-server-linux/index.html
@@ -709,7 +709,7 @@ <h3 id="linux-svn启动和关闭"><a href="#linux-svn启动和关闭" class="hea
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/03/20/SVN-server-linux/" data-id="cm4b8fqk9002jd54729ll958c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/03/20/SVN-server-linux/" data-id="cm4cl3h6a002lsl4723jke4ln" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/04/10/Annotation-Android-usage/index.html b/2017/04/10/Annotation-Android-usage/index.html
index c491182d9..ceb97d54c 100644
--- a/2017/04/10/Annotation-Android-usage/index.html
+++ b/2017/04/10/Annotation-Android-usage/index.html
@@ -916,7 +916,7 @@ <h3 id="annotationProcessor介绍"><a href="#annotationProcessor介绍" class="h
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/04/10/Annotation-Android-usage/" data-id="cm4b8fqkm003ud5478fo522a5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/04/10/Annotation-Android-usage/" data-id="cm4cl3h6e0030sl47uix94j01" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/05/11/Object-Oriented/index.html b/2017/05/11/Object-Oriented/index.html
index a97e1119b..3d47c40fd 100644
--- a/2017/05/11/Object-Oriented/index.html
+++ b/2017/05/11/Object-Oriented/index.html
@@ -741,7 +741,7 @@ <h3 id="IPC通信的三步骤"><a href="#IPC通信的三步骤" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/05/11/Object-Oriented/" data-id="cm4b8fqkd0035d547gu9bd9xm" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/05/11/Object-Oriented/" data-id="cm4cl3h6j0038sl473j5x058p" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/05/18/handler-replace-timertask/index.html b/2017/05/18/handler-replace-timertask/index.html
index 0ce82329a..ebceb2a97 100644
--- a/2017/05/18/handler-replace-timertask/index.html
+++ b/2017/05/18/handler-replace-timertask/index.html
@@ -681,7 +681,7 @@ <h3 id="Handler替代TimerTask"><a href="#Handler替代TimerTask" class="headerl
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/05/18/handler-replace-timertask/" data-id="cm4b8fqkc002yd54792km399j" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/05/18/handler-replace-timertask/" data-id="cm4cl3h6c002qsl47ru8dgp6c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/07/08/android-binder-principle/index.html b/2017/07/08/android-binder-principle/index.html
index 567427f11..76e07132b 100644
--- a/2017/07/08/android-binder-principle/index.html
+++ b/2017/07/08/android-binder-principle/index.html
@@ -766,7 +766,7 @@ <h3 id="分析系统服务调用流程"><a href="#分析系统服务调用流程
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/07/08/android-binder-principle/" data-id="cm4b8fqke0038d547lvbc9hrv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/07/08/android-binder-principle/" data-id="cm4cl3h6h0034sl47dvwqzkae" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/07/10/android-binder-principle2/index.html b/2017/07/10/android-binder-principle2/index.html
index 6eb28fca9..ecbc0e35c 100644
--- a/2017/07/10/android-binder-principle2/index.html
+++ b/2017/07/10/android-binder-principle2/index.html
@@ -762,7 +762,7 @@ <h3 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/07/10/android-binder-principle2/" data-id="cm4b8fqki003nd547jhxjwh09" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/07/10/android-binder-principle2/" data-id="cm4cl3h6k003fsl475v2rli94" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/07/12/android-noroot-hook/index.html b/2017/07/12/android-noroot-hook/index.html
index 893f9c113..d209a1e8f 100644
--- a/2017/07/12/android-noroot-hook/index.html
+++ b/2017/07/12/android-noroot-hook/index.html
@@ -808,7 +808,7 @@ <h3 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/07/12/android-noroot-hook/" data-id="cm4b8fqkr004fd547tg27dybu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/07/12/android-noroot-hook/" data-id="cm4cl3h6j0036sl47uysijtd1" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/08/01/aosp-compile/index.html b/2017/08/01/aosp-compile/index.html
index 29f68b168..bb17befc1 100644
--- a/2017/08/01/aosp-compile/index.html
+++ b/2017/08/01/aosp-compile/index.html
@@ -793,7 +793,7 @@ <h3 id="错误收集"><a href="#错误收集" class="headerlink" title="错误
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/08/01/aosp-compile/" data-id="cm4b8fqkh003jd547ixh9mqum" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/08/01/aosp-compile/" data-id="cm4cl3h6k003csl472n3lqte0" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/08/02/activity-start-process/index.html b/2017/08/02/activity-start-process/index.html
index c93d25fcd..6a3cf1f2f 100644
--- a/2017/08/02/activity-start-process/index.html
+++ b/2017/08/02/activity-start-process/index.html
@@ -813,7 +813,7 @@ <h3 id="参考资料"><a href="#参考资料" class="headerlink" title="参考
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/08/02/activity-start-process/" data-id="cm4b8fqkg003gd547wjyeqaum" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/08/02/activity-start-process/" data-id="cm4cl3h6t003ssl47o3nz12fd" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/08/17/IntervieweeQuestions/index.html b/2017/08/17/IntervieweeQuestions/index.html
index efab08cfc..f0581e2e5 100644
--- a/2017/08/17/IntervieweeQuestions/index.html
+++ b/2017/08/17/IntervieweeQuestions/index.html
@@ -854,7 +854,7 @@ <h3 id="27、Kotlin面试题"><a href="#27、Kotlin面试题" class="headerlink"
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/08/17/IntervieweeQuestions/" data-id="cm4b8fqkf003cd547uwo69ur6" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/08/17/IntervieweeQuestions/" data-id="cm4cl3h6u003vsl47wjle5046" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/09/12/PBOCKonwledge/index.html b/2017/09/12/PBOCKonwledge/index.html
index 1445727a1..1be653dec 100644
--- a/2017/09/12/PBOCKonwledge/index.html
+++ b/2017/09/12/PBOCKonwledge/index.html
@@ -880,7 +880,7 @@ <h3 id="参考资料"><a href="#参考资料" class="headerlink" title="参考
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/09/12/PBOCKonwledge/" data-id="cm4b8fqko003xd547h2upkgg4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/09/12/PBOCKonwledge/" data-id="cm4cl3h6n003jsl47xj8jsmcw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/09/21/PBOCKonwledgeCode/index.html b/2017/09/21/PBOCKonwledgeCode/index.html
index 2e39c6c9c..073210cf4 100644
--- a/2017/09/21/PBOCKonwledgeCode/index.html
+++ b/2017/09/21/PBOCKonwledgeCode/index.html
@@ -744,7 +744,7 @@ <h3 id="工具代码"><a href="#工具代码" class="headerlink" title="工具
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/" data-id="cm4b8fqkl003qd5477wsac0s0" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/" data-id="cm4cl3h6s003qsl47256r7kwa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/10/22/Buildcross-platform-desktop-apps/index.html b/2017/10/22/Buildcross-platform-desktop-apps/index.html
index 56db29e47..66a8955b7 100644
--- a/2017/10/22/Buildcross-platform-desktop-apps/index.html
+++ b/2017/10/22/Buildcross-platform-desktop-apps/index.html
@@ -701,7 +701,7 @@ <h3 id="Electron"><a href="#Electron" class="headerlink" title="Electron"></a>El
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/" data-id="cm4b8fqkp0044d547a43w7wbg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/" data-id="cm4cl3h6r003msl47m2u7gh0w" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/10/22/JavaScript-knowledge/index.html b/2017/10/22/JavaScript-knowledge/index.html
index 54c45ebbf..a9f578c91 100644
--- a/2017/10/22/JavaScript-knowledge/index.html
+++ b/2017/10/22/JavaScript-knowledge/index.html
@@ -893,7 +893,7 @@ <h3 id="操作DOM"><a href="#操作DOM" class="headerlink" title="操作DOM"></a
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/10/22/JavaScript-knowledge/" data-id="cm4b8fqkq0048d547hbovp8th" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/10/22/JavaScript-knowledge/" data-id="cm4cl3h71004dsl47qd1r04a4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2017/12/02/Python-knowledge/index.html b/2017/12/02/Python-knowledge/index.html
index 21a51c78b..28afcd4d1 100644
--- a/2017/12/02/Python-knowledge/index.html
+++ b/2017/12/02/Python-knowledge/index.html
@@ -825,7 +825,7 @@ <h3 id="Python之禅-Zen-Of-Python"><a href="#Python之禅-Zen-Of-Python" class=
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/12/02/Python-knowledge/" data-id="cm4b8fqkv004md5473dydpmyg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/12/02/Python-knowledge/" data-id="cm4cl3h6z0042sl47cg7n1u7c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/01/08/Toastmaster-self-introduction/index.html b/2018/01/08/Toastmaster-self-introduction/index.html
index f701404d1..32a1b3ebb 100644
--- a/2018/01/08/Toastmaster-self-introduction/index.html
+++ b/2018/01/08/Toastmaster-self-introduction/index.html
@@ -676,7 +676,7 @@ <h1 class="article-title" itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/" data-id="cm4b8fqkp0041d547wdmftbuv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/" data-id="cm4cl3h6y003ysl47hlsdugkq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/02/24/Mac-terminal-command/index.html b/2018/02/24/Mac-terminal-command/index.html
index ee08a7d8a..3d8e3e02a 100644
--- a/2018/02/24/Mac-terminal-command/index.html
+++ b/2018/02/24/Mac-terminal-command/index.html
@@ -1253,7 +1253,7 @@ <h3 id="unix的命令"><a href="#unix的命令" class="headerlink" title="unix
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/02/24/Mac-terminal-command/" data-id="cm4b8fql9004zd547mrzm3uph" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/02/24/Mac-terminal-command/" data-id="cm4cl3h700046sl47bgqluczw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/03/01/IntervieweeQuestions-senior/index.html b/2018/03/01/IntervieweeQuestions-senior/index.html
index 797e93a4e..5bfd871ef 100644
--- a/2018/03/01/IntervieweeQuestions-senior/index.html
+++ b/2018/03/01/IntervieweeQuestions-senior/index.html
@@ -1244,7 +1244,7 @@ <h3 id="61-面试常考的算法"><a href="#61-面试常考的算法" class="hea
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/" data-id="cm4b8fqkx004qd547c5ixnu8e" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/" data-id="cm4cl3h790054sl47thozusaw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/03/14/IntentService-AsyncTask/index.html b/2018/03/14/IntentService-AsyncTask/index.html
index 063d49ee0..3641ac102 100644
--- a/2018/03/14/IntentService-AsyncTask/index.html
+++ b/2018/03/14/IntentService-AsyncTask/index.html
@@ -791,7 +791,7 @@ <h3 id="Service实现IPC"><a href="#Service实现IPC" class="headerlink" title="
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/03/14/IntentService-AsyncTask/" data-id="cm4b8fql5004wd547e88ygujp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/03/14/IntentService-AsyncTask/" data-id="cm4cl3h75004ksl47vcbq9q3r" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/04/02/Toastmaster-two-drawbacks/index.html b/2018/04/02/Toastmaster-two-drawbacks/index.html
index 3da883f93..97d9415a3 100644
--- a/2018/04/02/Toastmaster-two-drawbacks/index.html
+++ b/2018/04/02/Toastmaster-two-drawbacks/index.html
@@ -675,7 +675,7 @@ <h1 class="article-title" itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/" data-id="cm4b8fqkr004cd5475aimkp41" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/" data-id="cm4cl3h74004hsl47au425tey" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/04/23/Usage-of-genericity/index.html b/2018/04/23/Usage-of-genericity/index.html
index f3c91cc88..37efa4b51 100644
--- a/2018/04/23/Usage-of-genericity/index.html
+++ b/2018/04/23/Usage-of-genericity/index.html
@@ -705,7 +705,7 @@ <h4 id="使用内联函数"><a href="#使用内联函数" class="headerlink" tit
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/04/23/Usage-of-genericity/" data-id="cm4b8fqks004jd54752zv31dz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/04/23/Usage-of-genericity/" data-id="cm4cl3h700049sl47zf2qqg96" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/06/08/JVM-stack-heap-GC/index.html b/2018/06/08/JVM-stack-heap-GC/index.html
index 657a31b81..79188259f 100644
--- a/2018/06/08/JVM-stack-heap-GC/index.html
+++ b/2018/06/08/JVM-stack-heap-GC/index.html
@@ -715,7 +715,7 @@ <h3 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/" data-id="cm4b8fqld0052d5471i12pkfu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/" data-id="cm4cl3h78004ysl473fg2rmzv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/06/26/Toastmaster-md-introduction/index.html b/2018/06/26/Toastmaster-md-introduction/index.html
index a6bee3d64..0661ef0bd 100644
--- a/2018/06/26/Toastmaster-md-introduction/index.html
+++ b/2018/06/26/Toastmaster-md-introduction/index.html
@@ -677,7 +677,7 @@ <h1 class="article-title" itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/" data-id="cm4b8fqlk0057d547twbogql5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/" data-id="cm4cl3h76004osl470o4mw3fl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/08/22/Handler-Looper-MessageQueue/index.html b/2018/08/22/Handler-Looper-MessageQueue/index.html
index a7694d404..d12e809ec 100644
--- a/2018/08/22/Handler-Looper-MessageQueue/index.html
+++ b/2018/08/22/Handler-Looper-MessageQueue/index.html
@@ -718,7 +718,7 @@ <h3 id="Toast在子线程的用法"><a href="#Toast在子线程的用法" class=
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/" data-id="cm4b8fqll005ad547r633j2gh" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/" data-id="cm4cl3h7y006fsl47z74wuww3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2018/12/06/Android-audio-introduction/index.html b/2018/12/06/Android-audio-introduction/index.html
index b94d8fd18..810de5383 100644
--- a/2018/12/06/Android-audio-introduction/index.html
+++ b/2018/12/06/Android-audio-introduction/index.html
@@ -720,7 +720,7 @@ <h3 id="参考文章"><a href="#参考文章" class="headerlink" title="参考
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/12/06/Android-audio-introduction/" data-id="cm4b8fqls005ld547183zaeoq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/12/06/Android-audio-introduction/" data-id="cm4cl3h77004usl47s069zfzl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/01/26/Android-request-memory-leaks/index.html b/2019/01/26/Android-request-memory-leaks/index.html
index 6d01674d3..92f2e8fb6 100644
--- a/2019/01/26/Android-request-memory-leaks/index.html
+++ b/2019/01/26/Android-request-memory-leaks/index.html
@@ -693,7 +693,7 @@ <h4 id="Lifeful的实现类"><a href="#Lifeful的实现类" class="headerlink" t
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/01/26/Android-request-memory-leaks/" data-id="cm4b8fql3004sd547mpub5nps" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/01/26/Android-request-memory-leaks/" data-id="cm4cl3h77004rsl47y4q0pyxa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/03/27/Android-APP-Bundles-Introduction/index.html b/2019/03/27/Android-APP-Bundles-Introduction/index.html
index f17e4e311..ee9cd9304 100644
--- a/2019/03/27/Android-APP-Bundles-Introduction/index.html
+++ b/2019/03/27/Android-APP-Bundles-Introduction/index.html
@@ -753,7 +753,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/" data-id="cm4b8fqlt005od54790k5liim" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/" data-id="cm4cl3h790058sl47htcpro7f" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/05/27/TCP-Three-way-Handshake/index.html b/2019/05/27/TCP-Three-way-Handshake/index.html
index 43bf163ad..94908f581 100644
--- a/2019/05/27/TCP-Three-way-Handshake/index.html
+++ b/2019/05/27/TCP-Three-way-Handshake/index.html
@@ -822,7 +822,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/" data-id="cm4b8fqlq005hd547rgztc9gx" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/" data-id="cm4cl3h7e005bsl472gvpk7so" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/05/30/RecyclerView-Design-Pattern/index.html b/2019/05/30/RecyclerView-Design-Pattern/index.html
index 7ef4485fe..79c7239f8 100644
--- a/2019/05/30/RecyclerView-Design-Pattern/index.html
+++ b/2019/05/30/RecyclerView-Design-Pattern/index.html
@@ -765,7 +765,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><hr>
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/" data-id="cm4b8fqlp005ed547xep7ru8m" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/" data-id="cm4cl3h7i005ysl47uz7lkny4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/05/31/RecyclerView-source-code/index.html b/2019/05/31/RecyclerView-source-code/index.html
index daf930f7a..2956c57ee 100644
--- a/2019/05/31/RecyclerView-source-code/index.html
+++ b/2019/05/31/RecyclerView-source-code/index.html
@@ -848,7 +848,7 @@ <h3 id="总结-1"><a href="#总结-1" class="headerlink" title="总结"></a>总
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/05/31/RecyclerView-source-code/" data-id="cm4b8fqq400e3d547u9bgjv7g" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/05/31/RecyclerView-source-code/" data-id="cm4cl3hc300eesl47458hzreu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/07/17/RecyclerView-pre-initiate/index.html b/2019/07/17/RecyclerView-pre-initiate/index.html
index 65b6ab52b..8ac5ca904 100644
--- a/2019/07/17/RecyclerView-pre-initiate/index.html
+++ b/2019/07/17/RecyclerView-pre-initiate/index.html
@@ -699,7 +699,7 @@ <h3 id="延伸阅读Recyclerview缓存"><a href="#延伸阅读Recyclerview缓存
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/" data-id="cm4b8fqlu005rd547e10qaqnz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/" data-id="cm4cl3h780051sl47fpdoywfu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/07/30/LeakCanary_source_code/index.html b/2019/07/30/LeakCanary_source_code/index.html
index bec90960f..5bf3a6e82 100644
--- a/2019/07/30/LeakCanary_source_code/index.html
+++ b/2019/07/30/LeakCanary_source_code/index.html
@@ -774,7 +774,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/07/30/LeakCanary_source_code/" data-id="cm4b8fqlw0062d547rqhgfkls" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/07/30/LeakCanary_source_code/" data-id="cm4cl3h7f005isl47ft6mqb6b" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/09/12/Horizontal-Coordinator/index.html b/2019/09/12/Horizontal-Coordinator/index.html
index e959b4450..9888fdcf9 100644
--- a/2019/09/12/Horizontal-Coordinator/index.html
+++ b/2019/09/12/Horizontal-Coordinator/index.html
@@ -771,7 +771,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/09/12/Horizontal-Coordinator/" data-id="cm4b8fqlw0066d5476rl7kfd5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/09/12/Horizontal-Coordinator/" data-id="cm4cl3h7g005psl47qbq9jy9f" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/12/08/Android-bits-operation/index.html b/2019/12/08/Android-bits-operation/index.html
index 6a970eae1..f58e00ddd 100644
--- a/2019/12/08/Android-bits-operation/index.html
+++ b/2019/12/08/Android-bits-operation/index.html
@@ -796,7 +796,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/12/08/Android-bits-operation/" data-id="cm4b8fqlu005ud5475vvms6jg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/12/08/Android-bits-operation/" data-id="cm4cl3h7e005fsl47c2wj8c8u" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2019/12/09/Android-Measure/index.html b/2019/12/09/Android-Measure/index.html
index 20c388c99..5afadf2a0 100644
--- a/2019/12/09/Android-Measure/index.html
+++ b/2019/12/09/Android-Measure/index.html
@@ -722,7 +722,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/12/09/Android-Measure/" data-id="cm4b8fqlv0060d547nehrtrym" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/12/09/Android-Measure/" data-id="cm4cl3h7g005msl47qcu1v6yn" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2020/05/26/download-function-analysis/index.html b/2020/05/26/download-function-analysis/index.html
index 7aedb7432..ff7bf0f4e 100644
--- a/2020/05/26/download-function-analysis/index.html
+++ b/2020/05/26/download-function-analysis/index.html
@@ -707,7 +707,7 @@ <h4 id="HttpUrlConnection断点下载"><a href="#HttpUrlConnection断点下载"
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/05/26/download-function-analysis/" data-id="cm4b8fqm60069d547xzz1vqql" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/05/26/download-function-analysis/" data-id="cm4cl3h7h005wsl474u5k1lzg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2020/07/10/profile_analysis/index.html b/2020/07/10/profile_analysis/index.html
index bb1711532..677f483d3 100644
--- a/2020/07/10/profile_analysis/index.html
+++ b/2020/07/10/profile_analysis/index.html
@@ -719,7 +719,7 @@ <h3 id="App启动流程分析"><a href="#App启动流程分析" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/07/10/profile_analysis/" data-id="cm4b8fqlv005yd5473bt3h7u2" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/07/10/profile_analysis/" data-id="cm4cl3h7h005tsl478pozkokm" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2020/08/31/JVM-stack-and_heap/index.html b/2020/08/31/JVM-stack-and_heap/index.html
index 00beec48c..8dbf40439 100644
--- a/2020/08/31/JVM-stack-and_heap/index.html
+++ b/2020/08/31/JVM-stack-and_heap/index.html
@@ -921,7 +921,7 @@ <h3 id="面试题"><a href="#面试题" class="headerlink" title="面试题"></a
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/08/31/JVM-stack-and_heap/" data-id="cm4b8fqmg006vd547q8g2w7nl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/08/31/JVM-stack-and_heap/" data-id="cm4cl3h7t0068sl470nhdd8sa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2020/09/07/Kotlin-DSL/index.html b/2020/09/07/Kotlin-DSL/index.html
index f73fe8a16..e83271136 100644
--- a/2020/09/07/Kotlin-DSL/index.html
+++ b/2020/09/07/Kotlin-DSL/index.html
@@ -741,7 +741,7 @@ <h3 id="总结"><a href="#总结" class="headerlink" title="总结"></a>总结</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/09/07/Kotlin-DSL/" data-id="cm4b8fqmc006kd5479r3qfssp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/09/07/Kotlin-DSL/" data-id="cm4cl3h7n0062sl47y1s21u4d" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2020/10/26/Diffrence-between-kotlin&Java/index.html b/2020/10/26/Diffrence-between-kotlin&Java/index.html
index 105425a4f..22e023fb0 100644
--- a/2020/10/26/Diffrence-between-kotlin&Java/index.html
+++ b/2020/10/26/Diffrence-between-kotlin&Java/index.html
@@ -978,7 +978,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&Java/" data-id="cm4b8fqmc006hd547dtzcc4zs" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&Java/" data-id="cm4cl3h7z006ksl4758xrov3x" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2020/12/04/RecyclerView_scroll_relatedapi/index.html b/2020/12/04/RecyclerView_scroll_relatedapi/index.html
index 405e4da88..d67080294 100644
--- a/2020/12/04/RecyclerView_scroll_relatedapi/index.html
+++ b/2020/12/04/RecyclerView_scroll_relatedapi/index.html
@@ -783,7 +783,7 @@ <h3 id="REF"><a href="#REF" class="headerlink" title="REF"></a>REF</h3><p>图文
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/" data-id="cm4b8fqmb006ed547wdo788py" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/" data-id="cm4cl3h80006osl47m733ac0c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2021/04/19/Android-PIP-Hack-summary/index.html b/2021/04/19/Android-PIP-Hack-summary/index.html
index 675834034..aa05462b8 100644
--- a/2021/04/19/Android-PIP-Hack-summary/index.html
+++ b/2021/04/19/Android-PIP-Hack-summary/index.html
@@ -713,7 +713,7 @@ <h3 id="REF"><a href="#REF" class="headerlink" title="REF"></a>REF</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/" data-id="cm4b8fqmb006cd5473rfg8aej" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/" data-id="cm4cl3h7q0065sl47f5lgmxku" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2021/06/07/ANR-summary/index.html b/2021/06/07/ANR-summary/index.html
index 129e7747f..fb3fe9391 100644
--- a/2021/06/07/ANR-summary/index.html
+++ b/2021/06/07/ANR-summary/index.html
@@ -782,7 +782,7 @@ <h3 id="ANR日志生成原理"><a href="#ANR日志生成原理" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/06/07/ANR-summary/" data-id="cm4b8fqmj007bd547kdwof81l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/06/07/ANR-summary/" data-id="cm4cl3h8q0072sl47hbtnvvl8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2021/07/18/gradle-plugin/index.html b/2021/07/18/gradle-plugin/index.html
index 1f56e3198..6195a417b 100644
--- a/2021/07/18/gradle-plugin/index.html
+++ b/2021/07/18/gradle-plugin/index.html
@@ -730,7 +730,7 @@ <h3 id="REF"><a href="#REF" class="headerlink" title="REF"></a>REF</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/07/18/gradle-plugin/" data-id="cm4b8fqmg006yd5476nqy64sq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/07/18/gradle-plugin/" data-id="cm4cl3h7x006bsl47s4smrsxa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2021/07/18/recyclerview-cache/index.html b/2021/07/18/recyclerview-cache/index.html
index f3f1afd6c..e9d92e7e1 100644
--- a/2021/07/18/recyclerview-cache/index.html
+++ b/2021/07/18/recyclerview-cache/index.html
@@ -795,7 +795,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/07/18/recyclerview-cache/" data-id="cm4b8fqmi0075d547rsf6a0yq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/07/18/recyclerview-cache/" data-id="cm4cl3h8g006vsl47ruksg52t" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2021/08/07/view-scroll-apis/index.html b/2021/08/07/view-scroll-apis/index.html
index 4dc5a5c30..35d58ad07 100644
--- a/2021/08/07/view-scroll-apis/index.html
+++ b/2021/08/07/view-scroll-apis/index.html
@@ -719,7 +719,7 @@ <h4 id="getGlobalVisibleRect-与-getLocalVisibleRect-方法介绍"><a href="#get
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/08/07/view-scroll-apis/" data-id="cm4b8fqme006rd5473fyzazcz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/08/07/view-scroll-apis/" data-id="cm4cl3h7z006msl47tcb5bgob" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2021/12/14/AOP-android/index.html b/2021/12/14/AOP-android/index.html
index cd7898a05..f05ec4957 100644
--- a/2021/12/14/AOP-android/index.html
+++ b/2021/12/14/AOP-android/index.html
@@ -924,7 +924,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/12/14/AOP-android/" data-id="cm4b8fqmh0070d547mk53moai" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/12/14/AOP-android/" data-id="cm4cl3h8a006ssl4715x5740z" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2022/02/10/android-binder-principle3/index.html b/2022/02/10/android-binder-principle3/index.html
index 9145d63c3..aa4a1a7f4 100644
--- a/2022/02/10/android-binder-principle3/index.html
+++ b/2022/02/10/android-binder-principle3/index.html
@@ -698,7 +698,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/02/10/android-binder-principle3/" data-id="cm4b8fqmd006od547owl17836" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/02/10/android-binder-principle3/" data-id="cm4cl3h7z006hsl47l8hmljpl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2022/02/13/Java-summary/index.html b/2022/02/13/Java-summary/index.html
index 290a8e084..0eb331be9 100644
--- a/2022/02/13/Java-summary/index.html
+++ b/2022/02/13/Java-summary/index.html
@@ -1375,7 +1375,7 @@ <h3 id="为什么List-lt-String-gt-不能赋值给List-lt-Object-gt"><a href="#
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/02/13/Java-summary/" data-id="cm4b8fqq800e6d547upzci25b" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/02/13/Java-summary/" data-id="cm4cl3hc100ecsl47uf1q4ncl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2022/03/28/sp-source-code-analysis/index.html b/2022/03/28/sp-source-code-analysis/index.html
index cf0ec5173..f6adcdd96 100644
--- a/2022/03/28/sp-source-code-analysis/index.html
+++ b/2022/03/28/sp-source-code-analysis/index.html
@@ -730,7 +730,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/03/28/sp-source-code-analysis/" data-id="cm4b8fqmi0078d5473p6k9es8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/03/28/sp-source-code-analysis/" data-id="cm4cl3h8t007bsl47o4etqsnv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2022/07/21/async-inflate-strategy/index.html b/2022/07/21/async-inflate-strategy/index.html
index fc1476c2f..a7f3bafa0 100644
--- a/2022/07/21/async-inflate-strategy/index.html
+++ b/2022/07/21/async-inflate-strategy/index.html
@@ -726,7 +726,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/07/21/async-inflate-strategy/" data-id="cm4b8fqmj007fd547dptgc4yk" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/07/21/async-inflate-strategy/" data-id="cm4cl3h8t0075sl471m6iawy6" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2022/08/08/anr-trigger-principle/index.html b/2022/08/08/anr-trigger-principle/index.html
index 4e6533436..f7d0a7f9b 100644
--- a/2022/08/08/anr-trigger-principle/index.html
+++ b/2022/08/08/anr-trigger-principle/index.html
@@ -714,7 +714,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/08/08/anr-trigger-principle/" data-id="cm4b8fqmh0073d547w0yycmcp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/08/08/anr-trigger-principle/" data-id="cm4cl3h8i006zsl470vu1l6vu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2023/02/10/constraintlayout-intro/index.html b/2023/02/10/constraintlayout-intro/index.html
index 2acb7fbfe..53924eabd 100644
--- a/2023/02/10/constraintlayout-intro/index.html
+++ b/2023/02/10/constraintlayout-intro/index.html
@@ -830,7 +830,7 @@ <h3 id="参考"><a href="#参考" class="headerlink" title="参考"></a>参考</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/02/10/constraintlayout-intro/" data-id="cm4b8fqmk007hd547f6jz7u8l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/02/10/constraintlayout-intro/" data-id="cm4cl3h8t0078sl47s7quwybz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2023/09/26/matrix-trace-canary/index.html b/2023/09/26/matrix-trace-canary/index.html
index 6f9cea1da..f0490aaa0 100644
--- a/2023/09/26/matrix-trace-canary/index.html
+++ b/2023/09/26/matrix-trace-canary/index.html
@@ -776,7 +776,7 @@ <h4 id="ANR检测"><a href="#ANR检测" class="headerlink" title="ANR检测"></a
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/09/26/matrix-trace-canary/" data-id="cm4b8fqml007rd547k48ny3y3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/09/26/matrix-trace-canary/" data-id="cm4cl3h8v007jsl47ev4v7e30" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2023/10/26/cross-process-bridge/index.html b/2023/10/26/cross-process-bridge/index.html
index be95fc69e..0a879ecd1 100644
--- a/2023/10/26/cross-process-bridge/index.html
+++ b/2023/10/26/cross-process-bridge/index.html
@@ -698,7 +698,7 @@ <h4 id="怎么拿到动态生成的代理class"><a href="#怎么拿到动态生
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/10/26/cross-process-bridge/" data-id="cm4b8fqml007nd5476h7lldrt" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/10/26/cross-process-bridge/" data-id="cm4cl3h8u007dsl47ap7qxf0o" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2023/11/02/native-crash-principle/index.html b/2023/11/02/native-crash-principle/index.html
index 3a8f291c5..35ba4a53b 100644
--- a/2023/11/02/native-crash-principle/index.html
+++ b/2023/11/02/native-crash-principle/index.html
@@ -769,7 +769,7 @@ <h3 id="Ref"><a href="#Ref" class="headerlink" title="Ref"></a>Ref</h3><p><a hre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/11/02/native-crash-principle/" data-id="cm4b8fqmn007ud547hy079ciz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/11/02/native-crash-principle/" data-id="cm4cl3h8v007gsl47pzdaouge" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2023/11/13/native-crash-anr-log-analysis/index.html b/2023/11/13/native-crash-anr-log-analysis/index.html
index cced36059..645c007bc 100644
--- a/2023/11/13/native-crash-anr-log-analysis/index.html
+++ b/2023/11/13/native-crash-anr-log-analysis/index.html
@@ -933,7 +933,7 @@ <h4 id="11-SIGTRAP"><a href="#11-SIGTRAP" class="headerlink" title="11. SIGTRAP"
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/" data-id="cm4b8fqmk007kd547seqc7rbd" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/" data-id="cm4cl3h8w007qsl47ppmitgct" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2024/04/24/jacoco-test-coverage/index.html b/2024/04/24/jacoco-test-coverage/index.html
index df0b80cfa..55ad42aee 100644
--- a/2024/04/24/jacoco-test-coverage/index.html
+++ b/2024/04/24/jacoco-test-coverage/index.html
@@ -732,7 +732,7 @@ <h3 id="增量代码覆盖率"><a href="#增量代码覆盖率" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2024/04/24/jacoco-test-coverage/" data-id="cm4b8fqmr007xd5479k6grv2n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2024/04/24/jacoco-test-coverage/" data-id="cm4cl3h8v007nsl4709bmc3vo" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2024/11/22/matrix-io-canary-introducation/index.html b/2024/11/22/matrix-io-canary-introducation/index.html
index efafddde8..ddbdc970c 100644
--- a/2024/11/22/matrix-io-canary-introducation/index.html
+++ b/2024/11/22/matrix-io-canary-introducation/index.html
@@ -703,7 +703,7 @@ <h3 id="Matrix-向后兼容"><a href="#Matrix-向后兼容" class="headerlink" t
 
 </div>
 
-    <a data-url="http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/" data-id="cm4b8fqms0080d54794sbeejo" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/" data-id="cm4cl3h8x007wsl47qxxewlq6" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/2024/12/04/matrix-battery-canary-introducation/index.html b/2024/12/04/matrix-battery-canary-introducation/index.html
index 809cf853d..4e760b4a7 100644
--- a/2024/12/04/matrix-battery-canary-introducation/index.html
+++ b/2024/12/04/matrix-battery-canary-introducation/index.html
@@ -7,19 +7,19 @@
     
     <title>Matrix Battery 介绍和使用 | Agehua</title>
     <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />
-    <meta name="description" content="Battery-CanaryBatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.">
+    <meta name="description" content="App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。 本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位">
 <meta name="keywords" content="Matrix, Battery, APM">
 <meta property="og:type" content="article">
 <meta property="og:title" content="Matrix Battery 介绍和使用">
 <meta property="og:url" content="http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/index.html">
 <meta property="og:site_name" content="Agehua">
-<meta property="og:description" content="Battery-CanaryBatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.">
+<meta property="og:description" content="App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。 本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位">
 <meta property="og:locale" content="en">
 <meta property="og:image" content="https://raw.githubusercontent.com/agehua/blog-imags/img/lib-jekyll/La%20Berceuse%20Augustine%20Roulin%203.jpg">
-<meta property="og:updated_time" content="2024-12-05T09:46:33.303Z">
+<meta property="og:updated_time" content="2024-12-06T10:06:32.072Z">
 <meta name="twitter:card" content="summary">
 <meta name="twitter:title" content="Matrix Battery 介绍和使用">
-<meta name="twitter:description" content="Battery-CanaryBatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.">
+<meta name="twitter:description" content="App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。 本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位">
 <meta name="twitter:image" content="https://raw.githubusercontent.com/agehua/blog-imags/img/lib-jekyll/La%20Berceuse%20Augustine%20Roulin%203.jpg">
     
 
@@ -463,7 +463,7 @@ <h3 id="title">Android Developer &amp; Web Enthusiast</h3>
         
             <div id='toc-wrap' class="toc-wrap">
                 <strong class="toc-title">文章目录</strong>
-                <ol class="toc"><li class="toc-item toc-level-2"><a class="toc-link" href="#Battery-Canary"><span class="toc-number">1.</span> <span class="toc-text">Battery-Canary</span></a><ol class="toc-child"><li class="toc-item toc-level-3"><a class="toc-link" href="#Android-系统电量统计服务"><span class="toc-number">1.1.</span> <span class="toc-text">Android 系统电量统计服务</span></a><ol class="toc-child"><li class="toc-item toc-level-4"><a class="toc-link" href="#BatteryStatsService-时长统计流程"><span class="toc-number">1.1.1.</span> <span class="toc-text">BatteryStatsService 时长统计流程</span></a></li><li class="toc-item toc-level-4"><a class="toc-link" href="#BatteryStatsService-功耗计算流程"><span class="toc-number">1.1.2.</span> <span class="toc-text">BatteryStatsService 功耗计算流程</span></a></li><li class="toc-item toc-level-4"><a class="toc-link" href="#Android-系统-App-耗电排行"><span class="toc-number">1.1.3.</span> <span class="toc-text">Android 系统 App 耗电排行</span></a></li><li class="toc-item toc-level-4"><a class="toc-link" href="#线程监控"><span class="toc-number">1.1.4.</span> <span class="toc-text">线程监控</span></a></li></ol></li><li class="toc-item toc-level-3"><a class="toc-link" href="#参考"><span class="toc-number">1.2.</span> <span class="toc-text">参考</span></a></li></ol></li></ol>
+                <ol class="toc"><li class="toc-item toc-level-3"><a class="toc-link" href="#Android-系统电量统计服务"><span class="toc-number">1.</span> <span class="toc-text">Android 系统电量统计服务</span></a><ol class="toc-child"><li class="toc-item toc-level-4"><a class="toc-link" href="#BatteryStatsService-时长统计流程"><span class="toc-number">1.1.</span> <span class="toc-text">BatteryStatsService 时长统计流程</span></a></li><li class="toc-item toc-level-4"><a class="toc-link" href="#BatteryStatsService-功耗计算流程"><span class="toc-number">1.2.</span> <span class="toc-text">BatteryStatsService 功耗计算流程</span></a></li><li class="toc-item toc-level-4"><a class="toc-link" href="#Android-系统-App-耗电排行"><span class="toc-number">1.3.</span> <span class="toc-text">Android 系统 App 耗电排行</span></a></li><li class="toc-item toc-level-4"><a class="toc-link" href="#线程监控"><span class="toc-number">1.4.</span> <span class="toc-text">线程监控</span></a></li></ol></li><li class="toc-item toc-level-3"><a class="toc-link" href="#BatteryCanary使用"><span class="toc-number">2.</span> <span class="toc-text">BatteryCanary使用</span></a></li><li class="toc-item toc-level-3"><a class="toc-link" href="#参考"><span class="toc-number">3.</span> <span class="toc-text">参考</span></a></li></ol>
             </div>
         
     </div>
@@ -546,7 +546,7 @@ <h1 class="article-title" itemprop="name">
     </div>
 
 
-                        <div style="color:#cba11f;float:right">2 min read , Words: 352</div>                    </div>
+                        <div style="color:#cba11f;float:right">5 min read , Words: 909</div>                    </div>
                 
             </header>
         
@@ -554,7 +554,8 @@ <h1 class="article-title" itemprop="name">
         <div class="article-entry" itemprop="articleBody">
         
 
-            <h2 id="Battery-Canary"><a href="#Battery-Canary" class="headerlink" title="Battery-Canary"></a>Battery-Canary</h2><p>BatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.</p>
+            <p>App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。</p>
+<p>本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位</p>
 <a id="more"></a>
 <h3 id="Android-系统电量统计服务"><a href="#Android-系统电量统计服务" class="headerlink" title="Android 系统电量统计服务"></a>Android 系统电量统计服务</h3><p>Android 系统的电量统计工作，是由一个叫 BatteryStatsService 的系统服务完成的。</p>
 <p>先了解一下其中四个比较关键的角色：</p>
@@ -576,6 +577,58 @@ <h4 id="线程监控"><a href="#线程监控" class="headerlink" title="线程
 <p>在这里有一点需要单独拎出来讲：utime 和 stime 具体代表什么意义呢？ 我们已经知道它们是表示线程的工作时长，但实际上其单位 jiffy 并不是一个时间的单位，而是一个<strong>频率</strong>的单位！</p>
 <p>Android Linux 上，100 Jiffies ≈ 1 Second</p>
 <p>所以我们可以记住一个比较重要的结论：在 Android 系统上，Jiffy 和 Millis 的换算关系大概是 1 比 10。（100 Hz 是一个 Linux 系统的编译参数，在不同的 Linux 版本上这个值可能是不同的。）</p>
+<h3 id="BatteryCanary使用"><a href="#BatteryCanary使用" class="headerlink" title="BatteryCanary使用"></a>BatteryCanary使用</h3><p>BatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.</p>
+<p>通过BatteryCanaryInitHelper这个类，<br><figure class="highlight java"><table><tr><td class="code"><pre><span class="line">sBatteryConfig = <span class="keyword">new</span> BatteryMonitorConfig.Builder()</span><br><span class="line">                <span class="comment">// Thread Activities Monitor</span></span><br><span class="line">                .enable(JiffiesMonitorFeature.class)</span><br><span class="line">                .enableStatPidProc(<span class="keyword">true</span>)</span><br><span class="line">                .greyJiffiesTime(<span class="number">3</span> * <span class="number">1000L</span>)</span><br><span class="line">                .enableBackgroundMode(<span class="keyword">false</span>)</span><br><span class="line">                .backgroundLoopCheckTime(<span class="number">30</span> * <span class="number">60</span> * <span class="number">1000L</span>)</span><br><span class="line">                .enableForegroundMode(<span class="keyword">true</span>)</span><br><span class="line">                .foregroundLoopCheckTime(<span class="number">20</span> * <span class="number">60</span> * <span class="number">1000L</span>)</span><br><span class="line">                .setBgThreadWatchingLimit(<span class="number">5000</span>)</span><br><span class="line">                .setBgThreadWatchingLimit(<span class="number">8000</span>)</span><br><span class="line"></span><br><span class="line">                <span class="comment">// CPU Stats</span></span><br><span class="line">                .enable(CpuStatFeature.class)</span><br><span class="line"></span><br><span class="line">                <span class="comment">// App &amp; Device Status Monitor For Better Invalid Battery Activities Configure</span></span><br><span class="line">                .setOverHeatCount(<span class="number">1024</span>)</span><br><span class="line">                .enable(DeviceStatMonitorFeature.class)</span><br><span class="line">                .enable(AppStatMonitorFeature.class)</span><br><span class="line">                .setSceneSupplier(<span class="keyword">new</span> Callable&lt;String&gt;() &#123;</span><br><span class="line">                    <span class="meta">@Override</span></span><br><span class="line">                    <span class="function"><span class="keyword">public</span> String <span class="title">call</span><span class="params">()</span> </span>&#123;</span><br><span class="line">                        <span class="keyword">return</span> <span class="string">"Current AppScene"</span>;</span><br><span class="line">                    &#125;</span><br><span class="line">                &#125;)</span><br><span class="line"></span><br><span class="line">                <span class="comment">// AMS Activities Monitor:</span></span><br><span class="line">                <span class="comment">// alarm/wakelock watch</span></span><br><span class="line">                .enableAmsHook(<span class="keyword">true</span>)</span><br><span class="line">                .enable(AlarmMonitorFeature.class)</span><br><span class="line">                .enable(WakeLockMonitorFeature.class)</span><br><span class="line">                .wakelockTimeout(<span class="number">2</span> * <span class="number">60</span> * <span class="number">1000L</span>)</span><br><span class="line">                .wakelockWarnCount(<span class="number">3</span>)</span><br><span class="line">                .addWakeLockWhiteList(<span class="string">"Ignore WakeLock TAG1"</span>)</span><br><span class="line">                .addWakeLockWhiteList(<span class="string">"Ignore WakeLock TAG2"</span>)</span><br><span class="line">                <span class="comment">// scanning watch (wifi/gps/bluetooth)</span></span><br><span class="line">                .enable(WifiMonitorFeature.class)</span><br><span class="line">                .enable(LocationMonitorFeature.class)</span><br><span class="line">                .enable(BlueToothMonitorFeature.class)</span><br><span class="line">                .enable(NotificationMonitorFeature.class)</span><br><span class="line"></span><br><span class="line">                <span class="comment">// BatteryStats</span></span><br><span class="line">                .enable(BatteryStatsFeature.class)</span><br><span class="line">                .setRecorder(<span class="keyword">new</span> BatteryRecorder.MMKVRecorder(mmkv))</span><br><span class="line">                .setStats(<span class="keyword">new</span> BatteryStats.BatteryStatsImpl())</span><br><span class="line">                .enable(HealthStatsFeature.class)</span><br><span class="line"></span><br><span class="line">                <span class="comment">// Lab Feature:</span></span><br><span class="line">                <span class="comment">// network monitor</span></span><br><span class="line">                <span class="comment">// looper task monitor</span></span><br><span class="line">                .enable(TrafficMonitorFeature.class)</span><br><span class="line">                .enable(LooperTaskMonitorFeature.class)</span><br><span class="line">                .addLooperWatchList(<span class="string">"main"</span>)</span><br><span class="line">                .useThreadClock(<span class="keyword">false</span>)</span><br><span class="line">                .enableAggressive(<span class="keyword">true</span>)</span><br><span class="line">                .enable(TopThreadFeature.class)</span><br><span class="line"></span><br><span class="line">                <span class="comment">// Monitor Callback</span></span><br><span class="line">                .setCallback(<span class="keyword">new</span> BatteryStatsListener())</span><br><span class="line">                .build();</span><br></pre></td></tr></table></figure></p>
+<p>总结下BatteryCanary 的功能有：</p>
+<ul>
+<li>监控现场CPU使用情况，使用Jiffies 衡量</li>
+<li>CPU状态监控</li>
+<li>设备状态监控</li>
+<li>App状态监控</li>
+<li>Alarm、WakeLock监控</li>
+<li>Wifi使用监控</li>
+<li>Location使用监控</li>
+<li>Bluetooth使用监控</li>
+<li>Notification使用监控</li>
+<li>电池状态监控<ul>
+<li>使用mmkv记录电池状态</li>
+<li>电池健康状态，包括温度</li>
+</ul>
+</li>
+<li>实验功能<ul>
+<li>流量使用监控</li>
+<li>looper任务监控（主线程）</li>
+<li>Top线程监控</li>
+</ul>
+</li>
+</ul>
+<p>初次运行Demo可能会有疑惑，不知道都有哪些功能，简单介绍下：</p>
+<ul>
+<li><p>第一个按钮：Dump BatteryStats Report</p>
+<ul>
+<li>对应 BatteryStatsFeature，使用compositeMonitors dump数据，在log里打印，并写入BatteryStatsFeature 的BatteryRecords 里<figure class="highlight java"><table><tr><td class="code"><pre><span class="line"><span class="comment">// 将数据打印到日志</span></span><br><span class="line">      <span class="keyword">final</span> Printer printer = <span class="keyword">new</span> Printer();</span><br><span class="line">      printer.writeTitle();</span><br><span class="line">      <span class="keyword">new</span> BatteryMonitorCallback.BatteryPrinter.Dumper().dump(compositeMonitors, printer);</span><br><span class="line">      printer.writeEnding();</span><br><span class="line"></span><br><span class="line">      <span class="comment">// 将数据写入 BatteryStatsFeature 的 BatteryRecorder里</span></span><br><span class="line">      BatteryStatsFeature statsFeat = BatteryCanary.getMonitorFeature(BatteryStatsFeature.class);</span><br><span class="line">      <span class="keyword">if</span> (statsFeat != <span class="keyword">null</span>) &#123;</span><br><span class="line">          statsFeat.statsMonitors(compositeMonitors);</span><br><span class="line">      &#125;</span><br></pre></td></tr></table></figure>
+</li>
+</ul>
+</li>
+<li><p>第二个：Checkout BatteryStats Report</p>
+<ul>
+<li>同样 BatteryStatsFeature，获取当前进程的 BatteryRecords<figure class="highlight java"><table><tr><td class="code"><pre><span class="line">BatteryCanary.getMonitorFeature(BatteryStatsFeature.class, <span class="keyword">new</span> Consumer&lt;BatteryStatsFeature&gt;() &#123;</span><br><span class="line">        <span class="meta">@Override</span></span><br><span class="line">        <span class="function"><span class="keyword">public</span> <span class="keyword">void</span> <span class="title">accept</span><span class="params">(BatteryStatsFeature batteryStatsFeature)</span> </span>&#123;</span><br><span class="line">            List&lt;BatteryRecord&gt; records = batteryStatsFeature.readRecords(dayOffset, mProc);</span><br><span class="line">            <span class="keyword">if</span> (mFilter != <span class="keyword">null</span>) &#123;</span><br><span class="line">                records = mFilter.filtering(records);</span><br><span class="line">            &#125;</span><br><span class="line">            BatteryRecords batteryRecords = <span class="keyword">new</span> BatteryRecords();</span><br><span class="line">            batteryRecords.date = BatteryStatsFeature.getDateString(dayOffset);</span><br><span class="line">            batteryRecords.records = records;</span><br><span class="line">            add(batteryRecords);</span><br><span class="line">        &#125;</span><br><span class="line">    &#125;);</span><br></pre></td></tr></table></figure>
+</li>
+</ul>
+</li>
+<li><p>第三个：Checkout BatteryStats Report</p>
+<ul>
+<li>同第二个，只是展示不同进程的数据</li>
+</ul>
+</li>
+<li>第四个、第五个：Show/Close TOP indicator<ul>
+<li>展示或取消 top indicator</li>
+<li>对应 TopThreadFeature，获取下面各个feature的数据并展示<figure class="highlight java"><table><tr><td class="code"><pre><span class="line">BatteryCanary.getMonitorFeature(TopThreadFeature.class, <span class="keyword">new</span> Consumer&lt;TopThreadFeature&gt;() &#123;</span><br><span class="line">    <span class="meta">@Override</span></span><br><span class="line">    <span class="function"><span class="keyword">public</span> <span class="keyword">void</span> <span class="title">accept</span><span class="params">(TopThreadFeature topThreadFeat)</span> </span>&#123;</span><br><span class="line">        topThreadFeat.top(seconds, <span class="keyword">new</span> Supplier&lt;CompositeMonitors&gt;() &#123;</span><br><span class="line">            <span class="meta">@Override</span></span><br><span class="line">            <span class="function"><span class="keyword">public</span> CompositeMonitors <span class="title">get</span><span class="params">()</span> </span>&#123;</span><br><span class="line">                CompositeMonitors monitors = <span class="keyword">new</span> CompositeMonitors(mCore, CompositeMonitors.SCOPE_TOP_INDICATOR);</span><br><span class="line">                monitors.metric(JiffiesMonitorFeature.UidJiffiesSnapshot.class);</span><br><span class="line">                monitors.metric(CpuStatFeature.CpuStateSnapshot.class);</span><br><span class="line">                monitors.metric(CpuStatFeature.UidCpuStateSnapshot.class);</span><br><span class="line">                monitors.metric(HealthStatsFeature.HealthStatsSnapshot.class);</span><br><span class="line">                monitors.metric(TrafficMonitorFeature.RadioStatSnapshot.class);</span><br><span class="line">                monitors.sample(DeviceStatMonitorFeature.CpuFreqSnapshot.class, <span class="number">500L</span>);</span><br><span class="line">                monitors.sample(DeviceStatMonitorFeature.BatteryCurrentSnapshot.class, <span class="number">500L</span>);</span><br><span class="line">                monitors.sample(TrafficMonitorFeature.RadioBpsSnapshot.class, <span class="number">500L</span>);</span><br><span class="line">                <span class="keyword">return</span> monitors;</span><br><span class="line">            &#125;</span><br><span class="line">        &#125;, <span class="keyword">new</span> ContinuousCallback() &#123;</span><br><span class="line">            <span class="meta">@Override</span></span><br><span class="line">            <span class="function"><span class="keyword">public</span> <span class="keyword">boolean</span> <span class="title">onGetDeltas</span><span class="params">(<span class="keyword">final</span> CompositeMonitors monitors, <span class="keyword">long</span> windowMillis)</span> </span>&#123;</span><br><span class="line">                refresh(monitors);</span><br><span class="line">                <span class="keyword">if</span> (mRootView == <span class="keyword">null</span> || !mRunningRef.get(hashcode, <span class="keyword">false</span>)) &#123;</span><br><span class="line">                    <span class="keyword">return</span> <span class="keyword">true</span>;</span><br><span class="line">                &#125;</span><br><span class="line">                <span class="keyword">return</span> <span class="keyword">false</span>;</span><br><span class="line">            &#125;</span><br><span class="line">        &#125;);</span><br><span class="line">    &#125;</span><br><span class="line">&#125;);</span><br></pre></td></tr></table></figure>
+</li>
+</ul>
+</li>
+</ul>
+<p>综上是 BatteryCanary 的主要功能，后续有时间再开一篇介绍下其中原理</p>
 <h3 id="参考"><a href="#参考" class="headerlink" title="参考"></a>参考</h3><p><a href="https://cloud.tencent.com/developer/article/1855937" target="_blank" rel="noopener">https://cloud.tencent.com/developer/article/1855937</a></p>
 <hr>
 <div style="width:690.45px"><div style="display:inline-block;width:110px"><a rel="noopener" href="http://creativecommons.org/licenses/by/2.5/cn/" target="_blank"><img style="border-width:0" src="https://raw.githubusercontent.com/agehua/blog-imags/img/lib-hexo-blog-img/blogimages/attribution_88x31.png"></a></div><div style="display:inline-block;width:580px;"><br>    本文采用<a rel="noopener" href="http://creativecommons.org/licenses/by/2.5/cn/" target="_blank">知识共享署名 2.5 中国大陆许可协议</a>进行许可，欢迎转载，但转载请注明来自<a href="http://conorlee.top/" target="_blank" rel="noopener">Agehua’s Blog</a>，并保持转载后文章内容的完整。本人保留所有版权相关权利。</div></div>
@@ -696,7 +749,7 @@ <h3 id="参考"><a href="#参考" class="headerlink" title="参考"></a>参考</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/" data-id="cm4b8fqms0083d54734ob7sn8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/" data-id="cm4cl3h8w007ssl47gys04u9n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/baidusitemap.xml b/baidusitemap.xml
index da287d5e2..d0e9bea41 100644
--- a/baidusitemap.xml
+++ b/baidusitemap.xml
@@ -4,12 +4,12 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/</loc>
-    <lastmod>2024-12-05T09:48:36.850Z</lastmod>
+    <loc>http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/</loc>
+    <lastmod>2024-12-06T10:06:32.072Z</lastmod>
     <data>
         <display>
-        <title>Matrix io 介绍和使用</title>
-        <pubTime>2024-11-21T16:00:00.000Z</pubTime>
+        <title>Matrix Battery 介绍和使用</title>
+        <pubTime>2024-12-03T16:00:00.000Z</pubTime>
         
         <tag>Matrix</tag>
          
@@ -24,12 +24,12 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/</loc>
-    <lastmod>2024-12-05T09:46:33.303Z</lastmod>
+    <loc>http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/</loc>
+    <lastmod>2024-12-05T09:48:36.850Z</lastmod>
     <data>
         <display>
-        <title>Matrix Battery 介绍和使用</title>
-        <pubTime>2024-12-03T16:00:00.000Z</pubTime>
+        <title>Matrix io 介绍和使用</title>
+        <pubTime>2024-11-21T16:00:00.000Z</pubTime>
         
         <tag>Matrix</tag>
          
@@ -196,16 +196,14 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/12/06/hexo-learning1/</loc>
+    <loc>http://agehua.github.io/2016/10/13/gradle-learning2/</loc>
     <lastmod>2024-12-05T09:41:56.282Z</lastmod>
     <data>
         <display>
-        <title>Hexo 模板学习——Hexo 结构</title>
-        <pubTime>2016-12-05T16:00:00.000Z</pubTime>
+        <title>gradle 学习2——生成指定文件名的apk</title>
+        <pubTime>2016-10-12T16:00:00.000Z</pubTime>
         
-        <tag>Hexo</tag>
-         
-        <tag>Hexo structure</tag>
+        <tag>gradle</tag>
          
          
            
@@ -218,14 +216,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/10/13/gradle-learning2/</loc>
+    <loc>http://agehua.github.io/2016/12/06/hexo-learning1/</loc>
     <lastmod>2024-12-05T09:41:56.282Z</lastmod>
     <data>
         <display>
-        <title>gradle 学习2——生成指定文件名的apk</title>
-        <pubTime>2016-10-12T16:00:00.000Z</pubTime>
+        <title>Hexo 模板学习——Hexo 结构</title>
+        <pubTime>2016-12-05T16:00:00.000Z</pubTime>
         
-        <tag>gradle</tag>
+        <tag>Hexo</tag>
+         
+        <tag>Hexo structure</tag>
          
          
            
@@ -245,10 +245,10 @@
         <title>LeakCanary源码分析及借鉴</title>
         <pubTime>2019-07-29T16:00:00.000Z</pubTime>
         
-        <tag>Android Source Code</tag>
-         
         <tag>LeakCanary</tag>
          
+        <tag>Android Source Code</tag>
+         
          
            
              
@@ -346,21 +346,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/09/20/AVG-unwanted-software/</loc>
+    <loc>http://agehua.github.io/2016/05/28/qiniu-android-summary/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>apk中含有admob广告插件</title>
-        <pubTime>2016-09-19T16:00:00.000Z</pubTime>
+        <title>七牛android使用总结</title>
+        <pubTime>2016-05-27T16:00:00.000Z</pubTime>
         
         <tag>ANDROID</tag>
          
-        <tag>remove admob</tag>
+        <tag>qiniu</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="technology" url="http://agehua.github.io/categories/technology/"/>
           
         </display>
     </data>
@@ -368,21 +368,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/09/22/quit-whole-application/</loc>
+    <loc>http://agehua.github.io/2016/09/20/AVG-unwanted-software/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Android 退出整个应用程序解决方案</title>
-        <pubTime>2016-09-21T16:00:00.000Z</pubTime>
+        <title>apk中含有admob广告插件</title>
+        <pubTime>2016-09-19T16:00:00.000Z</pubTime>
         
         <tag>ANDROID</tag>
          
-        <tag>exitApplication</tag>
+        <tag>remove admob</tag>
          
          
            
              
-              <breadCrumb title="technology" url="http://agehua.github.io/categories/technology/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -390,16 +390,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/05/28/qiniu-android-summary/</loc>
+    <loc>http://agehua.github.io/2016/09/22/quit-whole-application/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>七牛android使用总结</title>
-        <pubTime>2016-05-27T16:00:00.000Z</pubTime>
+        <title>Android 退出整个应用程序解决方案</title>
+        <pubTime>2016-09-21T16:00:00.000Z</pubTime>
         
         <tag>ANDROID</tag>
          
-        <tag>qiniu</tag>
+        <tag>exitApplication</tag>
          
          
            
@@ -412,16 +412,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/12/04/hexo-learning0/</loc>
+    <loc>http://agehua.github.io/2016/12/20/Android-patch-update/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Hexo 模板学习——EJS介绍</title>
-        <pubTime>2016-12-03T16:00:00.000Z</pubTime>
+        <title>Android 增量更新整理</title>
+        <pubTime>2016-12-19T16:00:00.000Z</pubTime>
         
-        <tag>Hexo</tag>
+        <tag>ANDROID</tag>
          
-        <tag>EJS</tag>
+        <tag>Patch Update</tag>
          
          
            
@@ -434,16 +434,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/12/20/Android-patch-update/</loc>
+    <loc>http://agehua.github.io/2016/12/04/hexo-learning0/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Android 增量更新整理</title>
-        <pubTime>2016-12-19T16:00:00.000Z</pubTime>
+        <title>Hexo 模板学习——EJS介绍</title>
+        <pubTime>2016-12-03T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
+        <tag>Hexo</tag>
          
-        <tag>Patch Update</tag>
+        <tag>EJS</tag>
          
          
            
@@ -500,16 +500,18 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/08/17/IntervieweeQuestions/</loc>
+    <loc>http://agehua.github.io/2017/09/12/PBOCKonwledge/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Android面试题积累</title>
-        <pubTime>2017-08-16T16:00:00.000Z</pubTime>
+        <title>PBOC知识收集</title>
+        <pubTime>2017-09-11T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
+        <tag>Basic Knowledge</tag>
          
-        <tag>Interview</tag>
+        <tag>PBOC</tag>
+         
+        <tag>PBOC 2.0</tag>
          
          
            
@@ -546,18 +548,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/09/12/PBOCKonwledge/</loc>
+    <loc>http://agehua.github.io/2017/08/17/IntervieweeQuestions/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>PBOC知识收集</title>
-        <pubTime>2017-09-11T16:00:00.000Z</pubTime>
+        <title>Android面试题积累</title>
+        <pubTime>2017-08-16T16:00:00.000Z</pubTime>
         
-        <tag>Basic Knowledge</tag>
-         
-        <tag>PBOC</tag>
+        <tag>Interview</tag>
          
-        <tag>PBOC 2.0</tag>
+        <tag>ANDROID</tag>
          
          
            
@@ -570,21 +570,19 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/10/22/JavaScript-knowledge/</loc>
+    <loc>http://agehua.github.io/2018/04/23/Usage-of-genericity/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>JavaScript知识点积累</title>
-        <pubTime>2017-10-21T16:00:00.000Z</pubTime>
+        <title>泛型的应用</title>
+        <pubTime>2018-04-22T16:00:00.000Z</pubTime>
         
-        <tag>Basic Knowledge</tag>
-         
-        <tag>JavaScript</tag>
+        <tag>genericity</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="Java" url="http://agehua.github.io/categories/java/"/>
           
         </display>
     </data>
@@ -592,19 +590,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2018/04/23/Usage-of-genericity/</loc>
+    <loc>http://agehua.github.io/2017/10/22/JavaScript-knowledge/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>泛型的应用</title>
-        <pubTime>2018-04-22T16:00:00.000Z</pubTime>
+        <title>JavaScript知识点积累</title>
+        <pubTime>2017-10-21T16:00:00.000Z</pubTime>
         
-        <tag>genericity</tag>
+        <tag>Basic Knowledge</tag>
+         
+        <tag>JavaScript</tag>
          
          
            
              
-              <breadCrumb title="Java" url="http://agehua.github.io/categories/java/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -612,16 +612,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/</loc>
+    <loc>http://agehua.github.io/2018/03/14/IntentService-AsyncTask/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Android面试题积累(高阶)</title>
-        <pubTime>2018-02-28T16:00:00.000Z</pubTime>
+        <title>IntentService和AsyncTask的区别</title>
+        <pubTime>2018-03-13T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
+        <tag>IntentService</tag>
          
-        <tag>Interview</tag>
+        <tag>AsyncTask</tag>
          
          
            
@@ -656,21 +656,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2018/03/14/IntentService-AsyncTask/</loc>
+    <loc>http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>IntentService和AsyncTask的区别</title>
-        <pubTime>2018-03-13T16:00:00.000Z</pubTime>
+        <title>Java的内存管理与垃圾回收</title>
+        <pubTime>2018-06-07T16:00:00.000Z</pubTime>
         
-        <tag>IntentService</tag>
+        <tag>GC</tag>
          
-        <tag>AsyncTask</tag>
+        <tag>JVM</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="Java" url="http://agehua.github.io/categories/java/"/>
           
         </display>
     </data>
@@ -678,21 +678,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/</loc>
+    <loc>http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Java的内存管理与垃圾回收</title>
-        <pubTime>2018-06-07T16:00:00.000Z</pubTime>
+        <title>Android面试题积累(高阶)</title>
+        <pubTime>2018-02-28T16:00:00.000Z</pubTime>
         
-        <tag>GC</tag>
+        <tag>Interview</tag>
          
-        <tag>JVM</tag>
+        <tag>ANDROID</tag>
          
          
            
              
-              <breadCrumb title="Java" url="http://agehua.github.io/categories/java/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -700,14 +700,14 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/</loc>
+    <loc>http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>RecyclerView 中的设计模式</title>
-        <pubTime>2019-05-29T16:00:00.000Z</pubTime>
+        <title>Android App Bundle(AAB) 文件介绍</title>
+        <pubTime>2019-03-26T16:00:00.000Z</pubTime>
         
-        <tag>RecyclerView</tag>
+        <tag>Android APP Bundles</tag>
          
          
            
@@ -720,14 +720,18 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/</loc>
+    <loc>http://agehua.github.io/2019/12/09/Android-Measure/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>Android App Bundle(AAB) 文件介绍</title>
-        <pubTime>2019-03-26T16:00:00.000Z</pubTime>
+        <title>从FrameLayout分析View测量原理</title>
+        <pubTime>2019-12-08T16:00:00.000Z</pubTime>
         
-        <tag>Android APP Bundles</tag>
+        <tag>FrameLayout</tag>
+         
+        <tag>RelativeLayout</tag>
+         
+        <tag>Measure</tag>
          
          
            
@@ -760,18 +764,14 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2019/12/09/Android-Measure/</loc>
+    <loc>http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>从FrameLayout分析View测量原理</title>
-        <pubTime>2019-12-08T16:00:00.000Z</pubTime>
+        <title>RecyclerView 中的设计模式</title>
+        <pubTime>2019-05-29T16:00:00.000Z</pubTime>
         
-        <tag>FrameLayout</tag>
-         
-        <tag>RelativeLayout</tag>
-         
-        <tag>Measure</tag>
+        <tag>RecyclerView</tag>
          
          
            
@@ -824,21 +824,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2019/05/31/RecyclerView-source-code/</loc>
+    <loc>http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>RecyclerView 源码分析</title>
-        <pubTime>2019-05-30T16:00:00.000Z</pubTime>
+        <title>nodejs入门</title>
+        <pubTime>2016-12-02T16:00:00.000Z</pubTime>
         
-        <tag>Android Source Code</tag>
+        <tag>read</tag>
          
-        <tag>RecyclerView</tag>
+        <tag>nodejs</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="read" url="http://agehua.github.io/categories/read/"/>
           
         </display>
     </data>
@@ -846,21 +846,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/</loc>
+    <loc>http://agehua.github.io/2019/05/31/RecyclerView-source-code/</loc>
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     <data>
         <display>
-        <title>nodejs入门</title>
-        <pubTime>2016-12-02T16:00:00.000Z</pubTime>
+        <title>RecyclerView 源码分析</title>
+        <pubTime>2019-05-30T16:00:00.000Z</pubTime>
         
-        <tag>read</tag>
+        <tag>RecyclerView</tag>
          
-        <tag>nodejs</tag>
+        <tag>Android Source Code</tag>
          
          
            
              
-              <breadCrumb title="read" url="http://agehua.github.io/categories/read/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -936,21 +936,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/08/03/android-LocationListener/</loc>
+    <loc>http://agehua.github.io/2016/05/24/JNI-Learning0/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>Android手机定位服务</title>
-        <pubTime>2016-08-02T16:00:00.000Z</pubTime>
+        <title>android JNI学习② JNI调用过程</title>
+        <pubTime>2016-05-23T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
+        <tag>JNI</tag>
          
-        <tag>LocationListener</tag>
+        <tag>android source code</tag>
          
          
            
              
-              <breadCrumb title="technology" url="http://agehua.github.io/categories/technology/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -958,23 +958,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/</loc>
+    <loc>http://agehua.github.io/2016/08/03/android-LocationListener/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>ThreadLocal、HandlerThread、Looper区别</title>
-        <pubTime>2016-09-04T16:00:00.000Z</pubTime>
+        <title>Android手机定位服务</title>
+        <pubTime>2016-08-02T16:00:00.000Z</pubTime>
         
-        <tag>ThreadLocal</tag>
-         
-        <tag>HandlerThread</tag>
+        <tag>ANDROID</tag>
          
-        <tag>Looper</tag>
+        <tag>LocationListener</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="technology" url="http://agehua.github.io/categories/technology/"/>
           
         </display>
     </data>
@@ -982,21 +980,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/09/20/android-design-pattern-singleton/</loc>
+    <loc>http://agehua.github.io/2016/08/16/RxAndroid-Learning/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>ANDROID设计模式之单例模式</title>
-        <pubTime>2016-09-19T16:00:00.000Z</pubTime>
+        <title>RxJava 学习</title>
+        <pubTime>2016-08-15T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
+        <tag>RxJava</tag>
          
-        <tag>Singleton</tag>
+        <tag>RxAndroid</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="technology" url="http://agehua.github.io/categories/technology/"/>
           
         </display>
     </data>
@@ -1004,21 +1002,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/08/16/RxAndroid-Learning/</loc>
+    <loc>http://agehua.github.io/2016/09/20/android-design-pattern-singleton/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>RxJava 学习</title>
-        <pubTime>2016-08-15T16:00:00.000Z</pubTime>
+        <title>ANDROID设计模式之单例模式</title>
+        <pubTime>2016-09-19T16:00:00.000Z</pubTime>
         
-        <tag>RxJava</tag>
+        <tag>ANDROID</tag>
          
-        <tag>RxAndroid</tag>
+        <tag>Singleton</tag>
          
          
            
              
-              <breadCrumb title="technology" url="http://agehua.github.io/categories/technology/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -1026,16 +1024,18 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2016/05/24/JNI-Learning0/</loc>
+    <loc>http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>android JNI学习② JNI调用过程</title>
-        <pubTime>2016-05-23T16:00:00.000Z</pubTime>
+        <title>ThreadLocal、HandlerThread、Looper区别</title>
+        <pubTime>2016-09-04T16:00:00.000Z</pubTime>
         
-        <tag>JNI</tag>
+        <tag>ThreadLocal</tag>
          
-        <tag>android source code</tag>
+        <tag>HandlerThread</tag>
+         
+        <tag>Looper</tag>
          
          
            
@@ -1075,10 +1075,10 @@
         <title>Android面试知识点整理</title>
         <pubTime>2016-09-27T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
-         
         <tag>Interview</tag>
          
+        <tag>ANDROID</tag>
+         
          
            
              
@@ -1090,21 +1090,19 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/03/20/SVN-server-linux/</loc>
+    <loc>http://agehua.github.io/2017/01/13/abroad-IM-service-company/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>linux(centos) 搭建SVN服务器</title>
-        <pubTime>2017-03-19T16:00:00.000Z</pubTime>
+        <title>IM 国外公司，服务费，方案</title>
+        <pubTime>2017-01-12T16:00:00.000Z</pubTime>
         
-        <tag>svn server</tag>
-         
-        <tag>linux</tag>
+        <tag>IM Company</tag>
          
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+              <breadCrumb title="Investigation" url="http://agehua.github.io/categories/investigation/"/>
           
         </display>
     </data>
@@ -1112,19 +1110,21 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/01/13/abroad-IM-service-company/</loc>
+    <loc>http://agehua.github.io/2017/03/20/SVN-server-linux/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>IM 国外公司，服务费，方案</title>
-        <pubTime>2017-01-12T16:00:00.000Z</pubTime>
+        <title>linux(centos) 搭建SVN服务器</title>
+        <pubTime>2017-03-19T16:00:00.000Z</pubTime>
         
-        <tag>IM Company</tag>
+        <tag>svn server</tag>
+         
+        <tag>linux</tag>
          
          
            
              
-              <breadCrumb title="Investigation" url="http://agehua.github.io/categories/investigation/"/>
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
     </data>
@@ -1132,18 +1132,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/05/11/Object-Oriented/</loc>
+    <loc>http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>Android架构师积累</title>
-        <pubTime>2017-05-10T16:00:00.000Z</pubTime>
+        <title>JSR-330和assertion(断言)介绍</title>
+        <pubTime>2017-03-13T16:00:00.000Z</pubTime>
         
-        <tag>Android Framework</tag>
-         
-        <tag>EIT</tag>
+        <tag>Annotation</tag>
          
-        <tag>Object-oriented</tag>
+        <tag>assertion</tag>
          
          
            
@@ -1156,16 +1154,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/07/08/android-binder-principle/</loc>
+    <loc>http://agehua.github.io/2017/04/10/Annotation-Android-usage/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>Android Binder机制分析（一）</title>
-        <pubTime>2017-07-07T16:00:00.000Z</pubTime>
+        <title>注解在Android中的应用</title>
+        <pubTime>2017-04-09T16:00:00.000Z</pubTime>
         
-        <tag>AIDL</tag>
+        <tag>ANDROID</tag>
          
-        <tag>Binder</tag>
+        <tag>Annotation</tag>
          
          
            
@@ -1178,16 +1176,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/</loc>
+    <loc>http://agehua.github.io/2017/07/08/android-binder-principle/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>JSR-330和assertion(断言)介绍</title>
-        <pubTime>2017-03-13T16:00:00.000Z</pubTime>
+        <title>Android Binder机制分析（一）</title>
+        <pubTime>2017-07-07T16:00:00.000Z</pubTime>
         
-        <tag>Annotation</tag>
+        <tag>AIDL</tag>
          
-        <tag>assertion</tag>
+        <tag>Binder</tag>
          
          
            
@@ -1200,18 +1198,18 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/08/02/activity-start-process/</loc>
+    <loc>http://agehua.github.io/2017/05/11/Object-Oriented/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>Activity启动流程分析</title>
-        <pubTime>2017-08-01T16:00:00.000Z</pubTime>
+        <title>Android架构师积累</title>
+        <pubTime>2017-05-10T16:00:00.000Z</pubTime>
         
-        <tag>Binder</tag>
+        <tag>Android Framework</tag>
          
-        <tag>AMS</tag>
+        <tag>EIT</tag>
          
-        <tag>AOSP</tag>
+        <tag>Object-oriented</tag>
          
          
            
@@ -1246,16 +1244,18 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2017/04/10/Annotation-Android-usage/</loc>
+    <loc>http://agehua.github.io/2017/08/02/activity-start-process/</loc>
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     <data>
         <display>
-        <title>注解在Android中的应用</title>
-        <pubTime>2017-04-09T16:00:00.000Z</pubTime>
+        <title>Activity启动流程分析</title>
+        <pubTime>2017-08-01T16:00:00.000Z</pubTime>
         
-        <tag>ANDROID</tag>
+        <tag>Binder</tag>
          
-        <tag>Annotation</tag>
+        <tag>AOSP</tag>
+         
+        <tag>AMS</tag>
          
          
            
@@ -1368,28 +1368,6 @@
          
            
              
-              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
-          
-        </display>
-    </data>
-    </url>
-
-    
-  <url>
-    <loc>http://agehua.github.io/2016/03/01/android-googlemap-summary/</loc>
-    <lastmod>2024-12-05T09:41:56.277Z</lastmod>
-    <data>
-        <display>
-        <title>android Google map使用总结</title>
-        <pubTime>2016-02-29T16:00:00.000Z</pubTime>
-        
-        <tag>ANDROID</tag>
-         
-        <tag>google map</tag>
-         
-         
-           
-             
               <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
@@ -1594,14 +1572,16 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2023/10/26/cross-process-bridge/</loc>
-    <lastmod>2024-12-05T09:41:25.330Z</lastmod>
+    <loc>http://agehua.github.io/2016/03/01/android-googlemap-summary/</loc>
+    <lastmod>2024-12-05T09:41:56.277Z</lastmod>
     <data>
         <display>
-        <title>跨进程通信Bridge建立</title>
-        <pubTime>2023-10-25T16:00:00.000Z</pubTime>
+        <title>android Google map使用总结</title>
+        <pubTime>2016-02-29T16:00:00.000Z</pubTime>
         
-        <tag>multi-process</tag>
+        <tag>ANDROID</tag>
+         
+        <tag>google map</tag>
          
          
            
@@ -1614,14 +1594,14 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2021/08/07/view-scroll-apis/</loc>
-    <lastmod>2024-12-05T09:41:25.325Z</lastmod>
+    <loc>http://agehua.github.io/2023/10/26/cross-process-bridge/</loc>
+    <lastmod>2024-12-05T09:41:25.330Z</lastmod>
     <data>
         <display>
-        <title>移动view的几种方式总结</title>
-        <pubTime>2021-08-06T16:00:00.000Z</pubTime>
+        <title>跨进程通信Bridge建立</title>
+        <pubTime>2023-10-25T16:00:00.000Z</pubTime>
         
-        <tag>view scroll</tag>
+        <tag>multi-process</tag>
          
          
            
@@ -1648,6 +1628,26 @@
          
            
              
+              <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
+          
+        </display>
+    </data>
+    </url>
+
+    
+  <url>
+    <loc>http://agehua.github.io/2021/08/07/view-scroll-apis/</loc>
+    <lastmod>2024-12-05T09:41:25.325Z</lastmod>
+    <data>
+        <display>
+        <title>移动view的几种方式总结</title>
+        <pubTime>2021-08-06T16:00:00.000Z</pubTime>
+        
+        <tag>view scroll</tag>
+         
+         
+           
+             
               <breadCrumb title="accumulation" url="http://agehua.github.io/categories/accumulation/"/>
           
         </display>
@@ -1683,10 +1683,10 @@
         <title>Recyclerview 滑动相关功能总结</title>
         <pubTime>2020-12-03T16:00:00.000Z</pubTime>
         
-        <tag>Android Source Code</tag>
-         
         <tag>RecyclerView</tag>
          
+        <tag>Android Source Code</tag>
+         
          
            
              
@@ -1698,12 +1698,12 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/</loc>
+    <loc>http://agehua.github.io/2023/11/02/native-crash-principle/</loc>
     <lastmod>2024-12-05T09:41:25.324Z</lastmod>
     <data>
         <display>
-        <title>Native Crash日志分析</title>
-        <pubTime>2023-11-12T16:00:00.000Z</pubTime>
+        <title>Native Crash捕获原理</title>
+        <pubTime>2023-11-01T16:00:00.000Z</pubTime>
         
         <tag>Native Crash</tag>
          
@@ -1718,12 +1718,12 @@
 
     
   <url>
-    <loc>http://agehua.github.io/2023/11/02/native-crash-principle/</loc>
+    <loc>http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/</loc>
     <lastmod>2024-12-05T09:41:25.324Z</lastmod>
     <data>
         <display>
-        <title>Native Crash捕获原理</title>
-        <pubTime>2023-11-01T16:00:00.000Z</pubTime>
+        <title>Native Crash日志分析</title>
+        <pubTime>2023-11-12T16:00:00.000Z</pubTime>
         
         <tag>Native Crash</tag>
          
@@ -1765,10 +1765,10 @@
         <title>RecyclerView 缓存机制</title>
         <pubTime>2021-07-17T16:00:00.000Z</pubTime>
         
-        <tag>Android Source Code</tag>
-         
         <tag>RecyclerView</tag>
          
+        <tag>Android Source Code</tag>
+         
          
            
              
@@ -2081,12 +2081,12 @@
         
         <tag>Looper</tag>
          
+        <tag>Android Source Code</tag>
+         
         <tag>Handler</tag>
          
         <tag>MessageQueue</tag>
          
-        <tag>Android Source Code</tag>
-         
          
            
              
diff --git a/content.json b/content.json
index 3353d4687..8d48c7798 100644
--- a/content.json
+++ b/content.json
@@ -1 +1 @@
-{"meta":{"title":"Agehua","subtitle":null,"description":"","author":"ConorLee","url":"http://agehua.github.io"},"pages":[{"title":"人不逍遥，名逍遥","date":"2023-11-16T03:42:40.871Z","updated":"2023-11-16T03:42:40.871Z","comments":true,"path":"about/index.html","permalink":"http://agehua.github.io/about/index.html","excerpt":"","text":"本文链接：http://agehua.github.io/about/index.html","raw":null,"content":null},{"title":"Categories","date":"2023-11-16T03:42:40.872Z","updated":"2023-11-16T03:42:40.872Z","comments":true,"path":"categories/index.html","permalink":"http://agehua.github.io/categories/index.html","excerpt":"","text":"本文链接：http://agehua.github.io/categories/index.html","raw":null,"content":null},{"title":"Tags","date":"2023-11-16T03:42:41.107Z","updated":"2023-11-16T03:42:41.107Z","comments":true,"path":"tags/index.html","permalink":"http://agehua.github.io/tags/index.html","excerpt":"","text":"本文链接：http://agehua.github.io/tags/index.html","raw":null,"content":null}],"posts":[{"title":"Matrix Battery 介绍和使用","slug":"matrix-battery-canary-introducation","date":"2024-12-03T16:00:00.000Z","updated":"2024-12-05T09:46:33.303Z","comments":true,"path":"2024/12/04/matrix-battery-canary-introducation/","link":"","permalink":"http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/","excerpt":"Battery-CanaryBatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.","text":"Battery-CanaryBatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等. Android 系统电量统计服务Android 系统的电量统计工作，是由一个叫 BatteryStatsService 的系统服务完成的。 先了解一下其中四个比较关键的角色： 功率：power_profile.xml，Android 系统使用此文件来描述设备各个硬件模块的额定功率，包括上面提到的多档位功率和 CPU 电量算需要到的各种参数值。 时长：StopWatch &amp; SamplingCounter，其中 StopWatch ⏱ 是用来计算 App 各种硬件模块的使用时长，而 SamplingCounter 则是用来采样统计 App 在不同 CPU Core 和不同 CpuFreq 下的工作时长。 计算：PowerCalculators，每个硬件模块都有一个相应命名的 PowerCalculator 实现，主要是用来完成具体的电量统计算法。 存储：batterystats.bin，电量统计服务相关数据的持久化文件。 BatteryStatsService 时长统计流程BatteryStatsService 框架的核心是 ta 持有的一个叫 BatteryStats 的类，BatteryStats 又持有一个 Uid [] 数组，每一个 Uid 实例实际上对应一个 App，当我们安装或者卸载 App 的时候，BatteryStats 就会更新相应的 Uid 元素以保持最新的映射关系。同时 BatteryStats 持有一系列的 StopWatch 和 SamplingCounter，当 App 开始使用某些硬件模块的功能时，BatteryStats 就会调用相应 Uid 的 StopWatch 或 SamplingCounter 来统计其硬件使用时长。 这里以 Wifi 模块来举例：当 App 通过 WifiManager 系统服务调用 Wifi 模块开始扫描的时候，实际上会通过 WifiManager#startScan() --&gt; WifiScanningServiceImp --&gt; BatteryStatsService#noteWifiScanStartedFromSource() --&gt; BatteryStats#noteWifiScanStartedLocked(uid)等一连串的调用，通知 BatteryStats 开启 App 相应 Uid 的 Wifi 模块的 StopWatch 开始计时。当 App 通过 WifiManager 停止 Wifi 扫描的时候又会通过类似的流程调用 BatteryStats#noteWifiScanStoppedLocked (uid) 结束 StopWatch 的计时，这样一来就通过 StopWatch 完成 App 对 Wifi 模块使用时长的统计。 BatteryStatsService 功耗计算流程具体电量计算方面，BatteryStats 是通过 ta 依赖的一个 BatteryStatsHelper 的辅助类来完成的。BatteryStatsHelper 通过组合使用 Uid 里的时长数据、PoweProfile 里的功率数据（power_profile.xml 的解析实例）以及具体各个模块的 PowerCalculator 算法，计算出每一个 App 的综合电量消耗，并把计算结果保存在 BatterySipper [] 数组里（按计算值从大到小排序）。 还是以 Wifi 模块来举例：当需要计算 App 电量消耗的时候，BatteryStats 会通过调用 BtteryStatsHelper#refreshStats() --&gt; #processAppUsage() 来刷新 BatterySipper [] 数组以计算最新的 App 电量消耗数据。而其中 Wifi 模块单独的电量统计就是在 processAppUsage 方法中通过 WifiPowerCalculator 来完成的：Wifi 模块电量 = PowerProfile 预置的 Idle 功率 + Uid 统计的 Wifi Idle 时间 + 上行功率 × 上行时间 + 下行功率 × 下行时间。 Android 系统 App 耗电排行通过以上分析，我们其实已经知道 Android 系统 App 耗电排行是通过读取 BatteryStatsHelper 里的 BatterySipper [] 数据来实现排行的。一般情况下，BatteryStats 的统计口径是 STATS_SINCE_CHARGED, 也就距离上次设备充满电到现在的状态。不过个别 OEM 系统上这里的统计细节有所不同，有的 Android 设备系统可以显示最近数天甚至一周以上的 App 的电量统计数据，具体实现细节不得而知，姑且推断是根据 BatteryStatsHelper 自行定制的服务。 线程监控实际上，我们除了通过 SystemClock.currentThreadTimeMillis () 来获取当前 Java 线程的工作时间此外，并没有直接的办法能够直接获取 App 所有线程的工作时长和状态，幸运的是 Linux 的 proc 命令可以给我们提供一些帮助。 Linux 命令 proc/[pid]/stat 和 proc/[pid]/task/[tid]/stat 可以 Dump 当前 App 进程和线程的统计信息。 &gt; cat /proc/&lt;mypid&gt;/task/&lt;tid&gt;/stat10966 (terycanary.test) S 699 699 0 0 -1 1077952832 6187 0 0 0 22 2 0 0 20 0 17 0 9087400 5414273024 24109 18446744073709551615 421814448128 421814472944 549131058960 0 0 0 4612 1 1073775864 1 0 0 17 7 0 0 0 0 0 421814476800 421814478232 422247952384 549131060923 549131061022 549131061022 549131063262 0 这里比较关键的数据是 进程 / 线程名、进程 / 线程状态，以及第 13 - 16 位的 utime、stime、cutime 和 **cstime。utime 和 stime 分别是进程 / 线程的用户时间和系统时间，而 cutime/cstime 是当前进程等在子进程的时间（在 Android 进程上大都是 0）。实际上我们对这些数据内容也不完全是陌生的，Logcat 里一些线程相关的 syslog 也有类似的输出。 在这里有一点需要单独拎出来讲：utime 和 stime 具体代表什么意义呢？ 我们已经知道它们是表示线程的工作时长，但实际上其单位 jiffy 并不是一个时间的单位，而是一个频率的单位！ Android Linux 上，100 Jiffies ≈ 1 Second 所以我们可以记住一个比较重要的结论：在 Android 系统上，Jiffy 和 Millis 的换算关系大概是 1 比 10。（100 Hz 是一个 Linux 系统的编译参数，在不同的 Linux 版本上这个值可能是不同的。） 参考https://cloud.tencent.com/developer/article/1855937 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Matrix","slug":"matrix","permalink":"http://agehua.github.io/tags/matrix/"}]},{"title":"Matrix io 介绍和使用","slug":"matrix-io-canary-introducation","date":"2024-11-21T16:00:00.000Z","updated":"2024-12-05T09:48:36.850Z","comments":true,"path":"2024/11/22/matrix-io-canary-introducation/","link":"","permalink":"http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/","excerpt":"IO-Canary参考 Matrix IO-Canary 功能，实现对主线程操作io、重复读相同文件、读写文件buffer过小的代码动态检测","text":"IO-Canary参考 Matrix IO-Canary 功能，实现对主线程操作io、重复读相同文件、读写文件buffer过小的代码动态检测 主要类IOIssue在 Java 层实体类是：public final class IOIssue &#123; public final int type; public final String path; public final long fileSize; public final int opCnt; public final long bufferSize; public final long opCostTime; public final int opType; public final long opSize; public final String threadName; public final String stack; public final int repeatReadCnt; public IOIssue(int type, String path, long fileSize, int opCnt, long bufferSize, long opCostTime, int opType, long opSize, String threadName, String stack, int repeatReadCnt) &#123; this.type = type; this.path = path; this.fileSize = fileSize; this.opCnt = opCnt; this.bufferSize = bufferSize; this.opCostTime = opCostTime; this.opType = opType; this.opSize = opSize; this.threadName = threadName; this.stack = stack; this.repeatReadCnt = repeatReadCnt; &#125;&#125; detector.h功能实现是在Native层，可以先看 detector.h 这个类 #ifndef MATRIX_IO_CANARY_DETECTOR_H#define MATRIX_IO_CANARY_DETECTOR_H#include &lt;vector&gt;#include &lt;set&gt;#include \"core/io_info_collector.h\"#include \"core/io_canary_env.h\"namespace iocanary &#123; typedef enum &#123; kDetectorMainThreadIO = 0, kDetectorSmallBuffer, kDetectorRepeatRead &#125; DetectorType; typedef enum &#123; kIssueMainThreadIO = 1, kIssueSmallBuffer, kIssueRepeatRead &#125; IssueType ; class Issue &#123; public: Issue(IssueType type, IOInfo file_io_info); const IssueType type_; const IOInfo file_io_info_; const std::string key_; int repeat_read_cnt_; std::string stack; private: static std::string GenKey(const IOInfo&amp; file_io_info); &#125;; class FileIODetector &#123; public: virtual ~FileIODetector(); virtual void Detect(const IOCanaryEnv&amp; env, const IOInfo&amp; file_io_info, std::vector&lt;Issue&gt;&amp; issues) = 0; protected: void PublishIssue(const Issue&amp; target, std::vector&lt;Issue&gt;&amp; issues); private: void MarkIssuePublished(const std::string&amp; key); bool IsIssuePublished(const std::string&amp; key); std::set&lt;std::string&gt; published_issue_set_; &#125;;&#125;#endif //MATRIX_IO_CANARY_DETECTOR_H 重点看 Detect 方法的实现，有三个类，分别是：main_thread_detector.cc 、repeat_read_detector.cc、small_buffer_detector.cc 每个类对应一个功能，触发场景分别如下： 检测场景main_thread_detector触发条件： 1.必须是主线程 2.单次文件读写超过时间限制（kPossibleNegativeThreshold），type = 1，位置见下面 3.整体连续读写超时（kDefaultMainThreadTriggerThreshold）,type = 2，位置见下面 4.两种情况可以同时命中，type = 3 5.type不等于1，则上报 同时，用repeat_read_cnt 来记录type 值。 repeat_read_detector触发条件比较复杂： 1.用map记录文件被读取次数，文件path作为key。如果最大读取时间小于 kPossibleNegativeThreshold，则不会向map里记录。否则会计入map 2.如果文件被写过，从map中拿到repeat信息，清空该repeat信息，否则记录然后+1 3.如果repeat count 大于等于 kDefaultRepeatReadThreshold 次数，则上报 small_buffer_detector这个比较简单： 1.buffer 操作次数 大于 kSmallBufferOpTimesThreshold 2.buffer 的空间大小 小于 kDefaultBufferSmallThreshold （4096KB） 3.最大读写时间 大于等于 kPossibleNegativeThreshold 4.三种条件需要同时满足，就会上报 #### 预定义的限制数据，都是定义在 io_canary_env.h 文件中：#ifndef MATRIX_IO_CANARY_IO_CANARY_ENV_H#define MATRIX_IO_CANARY_IO_CANARY_ENV_Hnamespace iocanary &#123; enum IOCanaryConfigKey &#123; kMainThreadThreshold = 0, kSmallBufferThreshold, kRepeatReadThreshold, //!!kConfigKeysLen always the last one!! kConfigKeysLen &#125;; class IOCanaryEnv &#123; public: IOCanaryEnv(); void SetConfig(IOCanaryConfigKey key, long val); long GetJavaMainThreadID() const; long GetMainThreadThreshold() const; long GetSmallBufferThreshold() const; long GetRepeatReadThreshold() const; //in μs. //it may be negative if the io-cost more than POSSIBLE_NEGATIVE_THRESHOLD //else it can be negligible //80% of the well-known 16ms constexpr static const int kPossibleNegativeThreshold = 13*1000; constexpr static const int kSmallBufferOpTimesThreshold = 20; private: long GetConfig(IOCanaryConfigKey key) const; //in μs constexpr static const int kDefaultMainThreadTriggerThreshold = 500*1000; // 500毫秒 //We take 4096B(4KB) as a small size of the buffer constexpr static const int kDefaultBufferSmallThreshold = 4096; constexpr static const int kDefaultRepeatReadThreshold = 5; long configs_[IOCanaryConfigKey::kConfigKeysLen]; &#125;;&#125;#endif //MATRIX_IO_CANARY_IO_CANARY_ENV_H Matrix 向后兼容Matrix 目前只兼容到了Android P，也就是 Android 9。 下面对 Android 9 以上版本的适配，做了一定的兼容，当然下面的代码仅仅说明了适配的方向，可能还有一些其他问题需要处理。 对于 Closeable 泄露监控来说，在 Android 10 及上无法兼容的原因是 CloseGuard#getReporter 无法直接通过反射获取， reporter 字段也是无法直接通过反射获取。如果无法获取到原始的 reporter，那么原始的 reporter 在我们 hook 之后就会失效。如果我们狠下决心，这也是可以接受的，但是对于这种情况我们应该尽量避免。 那么我们现在的问题就是如何在高版本上获取到原始的 reporter，那么有办法吗？有的，因为我们前面说到了无法直接通过反射获取，但是可以间接获取到。这里我们可以通过 反射的反射 来获取。实例如下： private static void doHook() throws Exception &#123; Class&lt;?&gt; clazz = Class.forName(\"dalvik.system.CloseGuard\"); Class&lt;?&gt; reporterClass = Class.forName(\"dalvik.system.CloseGuard$Reporter\"); Method setEnabledMethod = clazz.getDeclaredMethod(\"setEnabled\", boolean.class); setEnabledMethod.invoke(null, true); // 直接反射获取reporter// Method getReporterMethod = clazz.getDeclaredMethod(\"getReporter\");// final Object originalReporter = getReporterMethod.invoke(null); // 反射的反射获取 Method getDeclaredMethodMethod = Class.class.getDeclaredMethod(\"getDeclaredMethod\", String.class, Class[].class); Method getReporterMethod = (Method) getDeclaredMethodMethod.invoke(clazz, \"getReporter\", null); final Object originalReporter = getReporterMethod.invoke(null); Method setReporterMethod = clazz.getDeclaredMethod(\"setReporter\", reporterClass); Object proxy = Proxy.newProxyInstance( reporterClass.getClassLoader(), new Class&lt;?&gt;[]&#123;reporterClass&#125;, new InvocationHandler() &#123; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable &#123; return method.invoke(originalReporter, args); &#125; &#125; ); setReporterMethod.invoke(null, proxy);&#125; 对于 native hook 的三种场景来说，Android 9 版本以上无法适配的原因应该是 hook 失效导致的。可以使用字节的 bytehook 替换老旧的 xhook 来达到同样的效果。 同时对于 9 以后的版本需要 hook “libc.so” 的write和 read 方法：// ...bool is_libjavacore = (strstr(so_name, \"libc.so\") != nullptr || strstr(so_name, \"libjavacore.so\") != nullptr);if (is_libjavacore) &#123; bytehook_stub_t stub2 = bytehook_hook_single(so_name, NULL, \"read\", (void *) ProxyRead, hacker_bytehook_hooked_callback, NULL); if (stub2 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook read failed, try __read_chk\"); bytehook_stub_t stub3 =bytehook_hook_single(so_name, NULL, \"__read_chk\", (void *) ProxyReadChk,hacker_bytehook_hooked_callback, NULL); if (stub3 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook failed: __read_chk\"); return JNI_FALSE; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook __read_chk success\"); anrHookStubs.push_back(stub3); &#125; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook read success\"); anrHookStubs.push_back(stub2); &#125; bytehook_stub_t stub4 = bytehook_hook_single(so_name,NULL, \"write\", (void*)ProxyWrite, hacker_bytehook_hooked_callback, NULL); if (stub4 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook write failed, try __write_chk\"); bytehook_stub_t stub5 = bytehook_hook_single(so_name, NULL,\"__write_chk\", (void*)ProxyWriteChk, hacker_bytehook_hooked_callback, NULL); if (stub5 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook failed: __write_chk\"); return JNI_FALSE; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook __write_chk success\"); anrHookStubs.push_back(stub5); &#125; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook write success\"); anrHookStubs.push_back(stub4); &#125;&#125;// ... 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Matrix","slug":"matrix","permalink":"http://agehua.github.io/tags/matrix/"}]},{"title":"代码覆盖率统计——集成Jacoco","slug":"jacoco-test-coverage","date":"2024-04-23T16:00:00.000Z","updated":"2024-12-05T09:41:25.295Z","comments":true,"path":"2024/04/24/jacoco-test-coverage/","link":"","permalink":"http://agehua.github.io/2024/04/24/jacoco-test-coverage/","excerpt":"代码覆盖率代码覆盖率是软件测试中一个重要的评价指标。主要是指程序运行过程中，被执行到的代码在总代码中的占比程度，现在有很多插件可以实现这个功能，应用比较广的就是jacoco。\n代码覆盖率从测试方式上有两个方向可以进行：\n\n单元测试（白盒测试）\n功能测试（黑盒测试）\n\n下面在Android工程中，分别用Jacoco来实现这两个方向的代码覆盖率统计：","text":"代码覆盖率代码覆盖率是软件测试中一个重要的评价指标。主要是指程序运行过程中，被执行到的代码在总代码中的占比程度，现在有很多插件可以实现这个功能，应用比较广的就是jacoco。 代码覆盖率从测试方式上有两个方向可以进行： 单元测试（白盒测试） 功能测试（黑盒测试） 下面在Android工程中，分别用Jacoco来实现这两个方向的代码覆盖率统计： 单元测试单元测试代码覆盖率对于单元测试（白盒测试），gradle编译工具已经集成了JaCoCo插件，只需要添加这个插件，然后在工具栏 Run “YourUnitTestCase” with Coverage 即可，执行完用例之后，在IDE右侧会自动显示覆盖率报告，也可以单独建一个gradle task来生成jacoco覆盖率报告。 需要编写单元测试代码 使用下面的gradle task来生成单元测试的报告// 源代码路径def coverageSourceDirs = [ '../app/src/main/java']task jacocoTestReport(type: JacocoReport) &#123; group = \"Reporting\" description = \"Generate Jacoco coverage reports after running tests.\" reports &#123; xml.enabled = true html.enabled = true &#125; // 字节码路径 classDirectories.from = fileTree( dir: './build/intermediates/javac/debug', excludes: ['**/R*.class', '**/*$InjectAdapter.class', '**/*$ModuleAdapter.class', '**/*$ViewInjector*.class' ]) sourceDirectories.from = files(coverageSourceDirs) // 覆盖率数据路径，这个数据是执行单测时自动生成的 executionData.from = files(\"$buildDir/outputs/unit_test_code_coverage/debugUnitTest/testDebugUnitTest.exec\") doFirst &#123; new File(\"$buildDir/intermediates/javac/\").eachFileRecurse &#123; file -&gt; if (file.name.contains('$$')) &#123; file.renameTo(file.path.replace('$$', '$')) &#125; &#125; &#125;&#125; 黑盒测试代码覆盖率黑盒测试，也叫功能测试，也就是把app装在手机上，人工（或自动化）去操作UI界面。这种测试的代码覆盖率，用JaCoCo也可以统计到。 常见获取覆盖率的方法分两种，一种是在源码中，以打桩的形式，收集覆盖率数据，针对性较强，但是需要深入源码，另一种是改写应用入口，通过instrument启动应用，记录应用执行期间全局的代码覆盖率。 大致分为三个步骤： 使用gradle编译apk、aar、jar时，添加jacoco插件（记得只在buildType为debug时开启），完成插桩。apk/aar/jar运行期间，在指定时机（比如OnDestroy时或者用户点击按钮）利用反射机制调用 jacoco api 拿到覆盖率统计数据，然后保存到手机，如果做了覆盖率平台，可以上传到平台。把覆盖率数据从手机pull下来，在gradle里面添加一个生成报告的任务（参考上面单元测试代码覆盖率报告生成）。如果是做成了平台，也可以调用 jacoco api 根据覆盖率数据、源码、字节码生成报告并展示。下面请看例子： 调用下面代码来生成对应报告fun generateEcFile(isNew: Boolean, generateCallback: ((Boolean) -&gt; Unit)? = null) &#123; var out: OutputStream? = null val dir = FacadeHelper.getApplicationContext().getExternalFilesDir(null).toString() + \"/shareData/\" val target = dir + File.separator + \"coverage.ec\" val mCoverageFilePath = File(target) try &#123; val targetDir = File(dir) if (!targetDir.exists()) &#123; targetDir.mkdirs() &#125; if (isNew &amp;&amp; mCoverageFilePath.exists()) &#123; JaLog.d(TAG, \"清除旧的ec文件\") mCoverageFilePath.delete() &#125; if (!mCoverageFilePath.exists()) &#123; mCoverageFilePath.createNewFile() &#125; out = FileOutputStream(mCoverageFilePath.path, true) val agent = Class.forName(\"org.jacoco.agent.rt.RT\") .getMethod(\"getAgent\") .invoke(null) if (agent != null) &#123; out.write( agent.javaClass.getMethod(\"getExecutionData\", Boolean::class.javaPrimitiveType) .invoke(agent, false) as ByteArray ) &#125; generateCallback?.invoke(true) &#125; catch (e: Exception) &#123; JaLog.d(TAG, e.toString()) generateCallback?.invoke(false) &#125; finally &#123; try &#123; out?.close() &#125; catch (e: IOException) &#123; JaLog.d(TAG, e.toString()) generateCallback?.invoke(false) &#125; &#125; &#125; 支持多Module源码在下面，主要实现步骤： 1.在App module中定义一个jacoco.gradle，引入jacoco插件 2.定义一个 copyTask，将class文件和source code文件复制到指定目录（这里复制到了 /build/custom下） 3.在 copyTask中遍历项目所有的 project，对每个 project执行复制操作 复制文件方法参考： Gradle Copy Task 4.copyTask每次在 package${buildType} 任务后执行，这样打好包后，文件也已复制完毕 这里支持多种buildType构建，比如debug、staging等。但不支持release 5.从App拿到覆盖率数据，放到指定目录后，执行 jacocoTestReport，将在 build/reports/ 目录下生成Html报告 6.最后，在app.gradle中定义开关，根据开关状态判断是否引入 jacoco.gradle 如果是由服务端生成最终报告，需要上传覆盖率数据和class文件。因为所有class文件都在一个目录，可以轻易将class文件打包为一个jar，将jar包传给服务端 // jacoco.gradle文件apply plugin: 'jacoco'//Jacoco 版本，本篇创建时最新版本jacoco &#123; toolVersion = \"0.8.11\"&#125;//源代码存放路径def sourceCodeDirs = \"$buildDir/customJavaSources\"def javaClassDirs = \"$buildDir/customJavaClasses\"def currentBuildType = nulltasks.register('copyTask') &#123; group = \"JacocoReport\" def originalSourceDir = &#123; Set&lt;Project&gt; projects = project.rootProject.subprojects List&lt;String&gt; tmpDir = new ArrayList&lt;&gt;(projects.size()) projects.forEach &#123;// println(\"当前project is $&#123;it.name&#125;\") tmpDir.add(\"$it.projectDir/src/main/java\") &#125; tmpDir &#125; def originalJavaClassDir = &#123; Set&lt;Project&gt; projects = project.rootProject.subprojects List&lt;String&gt; tmpDir = new ArrayList&lt;&gt;(projects.size()) projects.forEach &#123; def subBuildType = currentBuildType.toLowerCase() if (it.name != \"app\") &#123; try &#123; def androidConfig = it.extensions.getByName('android') def buildTypeExists = androidConfig.buildTypes.any &#123; it.name.equalsIgnoreCase(subBuildType) &#125; if (!buildTypeExists) &#123; subBuildType = 'debug' &#125;// println(\"当前 project($&#123;it.name&#125;) 的config $&#123;androidConfig&#125;，buildtype 是$&#123;subBuildType&#125;\") &#125; catch (Exception e) &#123; subBuildType = 'debug'// println(\"当前 project($&#123;it.name&#125;) 没有 'android' 扩展名: $&#123;e.message&#125;\") &#125; &#125; tmpDir.add(\"$it.projectDir/build/intermediates/javac/$&#123;subBuildType&#125;/classes\") &#125; tmpDir &#125; def originalKotlinClassDir = &#123; Set&lt;Project&gt; projects = project.rootProject.subprojects List&lt;String&gt; tmpDir = new ArrayList&lt;&gt;(projects.size()) projects.forEach &#123; def subBuildType = currentBuildType.toLowerCase() if (it.name != \"app\") &#123; try &#123; def androidConfig = it.extensions.getByName('android') def buildTypeExists = androidConfig.buildTypes.any &#123; it.name.equalsIgnoreCase(subBuildType) &#125; if (!buildTypeExists) &#123; subBuildType = 'debug' &#125;// println(\"当前 project($&#123;it.name&#125;) 的config $&#123;androidConfig&#125;，buildtype 是$&#123;subBuildType&#125;\") &#125; catch (Exception e) &#123; subBuildType = 'debug'// println(\"当前 project($&#123;it.name&#125;) 没有 'android' 扩展名: $&#123;e.message&#125;\") &#125; &#125;// tmpDir.add(\"$it.projectDir/build/tmp/kotlin-classes/debug\") // https://issuetracker.google.com/issues/161300933#comment13 tmpDir.add(\"$it.projectDir/build/intermediates/asm_instrumented_project_classes/$&#123;subBuildType&#125;\") &#125; tmpDir &#125; doLast &#123; if (!Boolean.parseBoolean(enableJacoco)) &#123; println(\"开关未打开，不复制文件\") return &#125; println(\"开始删除文件\") delete sourceCodeDirs delete javaClassDirs println(\"开始复制文件\") // https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Copy.html copy &#123; from originalSourceDir // 目标目录 into sourceCodeDirs duplicatesStrategy = DuplicatesStrategy.INCLUDE exclude '**/com/blelib/**', \"**/com/alibaba/**\", \"**/com/bumptech/**\", \"**/com/chad/**\", '**/*_HiltComponents**' println(\"复制java源文件开始\") &#125; copy &#123; from originalJavaClassDir // 目标目录 into javaClassDirs duplicatesStrategy = DuplicatesStrategy.INCLUDE exclude '**/com/blelib/**', \"**/com/alibaba/**\", \"**/com/bumptech/**\", \"**/com/chad/**\", '**/*_HiltComponents**' println(\"复制java class开始\") &#125; copy &#123; from originalKotlinClassDir // 目标目录 into javaClassDirs duplicatesStrategy = DuplicatesStrategy.INCLUDE exclude '**/com/blelib/**', \"**/com/alibaba/**\", \"**/com/bumptech/**\", \"**/com/chad/**\", '**/*_HiltComponents**' println(\"复制Kotlin class开始\") &#125; println(\"复制文件完成\") &#125;&#125;//初始化Jacoco Tasktasks.register('jacocoInit') &#123; group = \"JacocoReport\" File file = new File(\"$buildDir/outputs/code-coverage/\") if (!file.exists()) &#123; file.mkdir() &#125;&#125;/** * 单元测试，生成报告task */tasks.register('jacocoTestReport', JacocoReport) &#123; group = \"JacocoReport\" description = \"Generate Jacoco coverage reports after running tests.\" reports &#123; xml.enabled = true html.enabled = true &#125; def excludes = [ '**_HiltComponents_**', '**/*databinding*/**', '**/*BindingImpl*', '**/*hilt_aggregated_deps*/**' ] classDirectories.from = files([fileTree(dir: javaClassDirs, excludes: excludes)]) sourceDirectories.from = files([sourceCodeDirs])// sourceDirectories.from = files([fileTree(dir: sourceCodeDirs, excludes: excludes)]) // 这行报错 // 将 coverage.ec文件提前复制到这里：adb pull /storage/emulated/0/Android/data/com.xxx.xxx/files/shareData/coverage.ec executionData.from = files(\"$buildDir/outputs/code-coverage/coverage.ec\")&#125;afterEvaluate &#123; def taskNames = gradle.startParameter.taskNames taskNames.each &#123; taskName -&gt; println \"Current taskName: $taskName\" if (taskName.toLowerCase().contains(\"debug\")) &#123; currentBuildType = \"Debug\" &#125; else if (taskName.toLowerCase().contains(\"staging\")) &#123; currentBuildType = \"Staging\" &#125; &#125; if (currentBuildType != null) &#123; println \"Current Build Type: $currentBuildType\" &#125; else &#123; println \"Could not determine current build type.\" return &#125; def jacocoTestReport = tasks.findByName('copyTask') def merge = tasks.findByName(\"package$&#123;currentBuildType&#125;\") if (null != merge) &#123; merge.finalizedBy(jacocoTestReport)// jacocoTestReport.dependsOn(merge) &#125; else &#123; println(\"任务未找到\") &#125;&#125; // app.gradle，省略其他代码// 是否开启代码分析if (Boolean.parseBoolean(enableJacoco)) &#123; apply from: 'jacoco.gradle'&#125; Hilt支持正常的kotlin生成的class文件路径：build/tmp/kotlin-classes/debug，如果使用这个路径，@AndroidEntryPoint 修饰的类的覆盖率测试一直是0。需要替换为 build/intermediates/asm_instrumented_project_classes/debug 这个路径，参考：https://issuetracker.google.com/issues/161300933#comment13 Failed resolution of: Lorg/jacoco/agent/rt/internal_/Offline官方FAQ有解释： If you use offline instrumentation the instrumented classes get a direct dependency on the JaCoCo runtime. Therefore jacocoagent.jar of the same JaCoCo version must be on the classpath and accessible from by the instrumented classes. 但是出现这个问题有两种情况： 第一种情况是确实缺少 jacocoagent.jar，那需要下载和gradle里一致的版本，不要下错。 1.下载地址：https://repo1.maven.org/maven2/org/jacoco/jacoco/ 2.改为使用统一版本。在项目级的build.gradle里加入下面代码：subprojects &#123; configurations.all &#123; resolutionStrategy &#123; eachDependency &#123; details -&gt; if ('org.jacoco' == details.requested.group) &#123; details.useVersion \"0.8.11\" &#125; &#125; &#125; &#125;&#125; 第二种情况是使用了混淆，导致找不到class，需要在混淆文件中添加下面的规则：-keep class org.jacoco.**&#123;*;&#125;-keep class com.vladium.emma.**&#123;*;&#125; 拿到手机上的测试覆盖数据执行adb命令就可以：adb pull /storage/emulated/0/Android/data/com.xxx.xxx/files/shareData/coverage.ec 关于混淆尽量使用同一种，否则在合并测试报告时会出问题：https://stackoverflow.com/questions/54629643/merge-jacoco-results-obfuscated-and-not-obfuscated-runs 增量代码覆盖率 计算增量的最小单位是 方法，即使方法中有一行变更，那也算作方法变更 配合git，拿到相关变更方法 需要修改Jacoco的代码，因为Jacoco的方法注入为全量注入。 大概架构图 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2024/04/24/jacoco-test-coverage/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Jacoco","slug":"jacoco","permalink":"http://agehua.github.io/tags/jacoco/"}]},{"title":"Native Crash日志分析","slug":"native-crash-anr-log-analysis","date":"2023-11-12T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2023/11/13/native-crash-anr-log-analysis/","link":"","permalink":"http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/","excerpt":"本文是上一篇《Native Crash 捕获原理》的姊妹篇，主要介绍如何分析Native Crash日志，以及常见的Native Crash类型","text":"本文是上一篇《Native Crash 捕获原理》的姊妹篇，主要介绍如何分析Native Crash日志，以及常见的Native Crash类型 NA Crash日志对比Logcat中抓到的日志：A Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 14206 (conorlee.test), pid 14206 (conorlee.test)Cmdline: com.conorlee.testpid: 14206, tid: 14206, name: conorlee.test &gt;&gt;&gt; com.conorlee.test &lt;&lt;&lt; #00 pc 000000000000f6d0 /data/app/~~thPbPJ0ZokAxuuRZPsdShQ==/com.conorlee.test-_xwNfmDQiQWDDcg5TlCGqA==/lib/arm64/libcrash-lib.so (Crash()+20) (BuildId: ad36e849968841628dab3afed7e6010c4c500b02) #01 pc 000000000000f774 /data/app/~~thPbPJ0ZokAxuuRZPsdShQ==/com.conorlee.test-_xwNfmDQiQWDDcg5TlCGqA==/lib/arm64/libcrash-lib.so (Java_com_dodola_breakpad_MainActivity_crash+20) (BuildId: ad36e849968841628dab3afed7e6010c4c500b02) #04 pc 000000000031cad4 /data/data/com.conorlee.test/code_cache/.overlay/base.apk/classes.dex (com.conorlee.test.MainActivity$1$1.run+8) #08 pc 000000000031cb1c /data/data/com.conorlee.test/code_cache/.overlay/base.apk/classes.dex (com.conorlee.test.MainActivity$1.onClick+20) APM SDK抓到的日志（理想状态）：Native Crash, signal: 11, tname: conorlee.test, pid: 13283, tid: 13283, code: 1, error: 0Stack trace is #0, pc 61075, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so, (sname: Java_com_dodola_breakpad_MainActivity_stringFromJNI, saddr: 55) #1, pc 61019, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so, (sname: Java_com_dodola_breakpad_MainActivity_crash, saddr: 15) #2, pc 61003, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so, (sname: _Z5Crashv, saddr: 15) #3, pc 60987, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so Java thread(main), stack is : com.conorlee.test.MainActivity.crash() -2 com.conorlee.test.MainActivity$1$1.run() 63 java.lang.Thread.run() 1,015 com.conorlee.test.MainActivity$1.onClick() 65 android.view.View.performClick() 7,614 android.view.View.performClickInternal() 7,591 android.view.View.-$$Nest$mperformClickInternal() 0 android.view.View$PerformClick.run() 29,809 android.os.Handler.handleCallback() 942 android.os.Handler.dispatchMessage() 99 android.os.Looper.loopOnce() 223 android.os.Looper.loop() 324 android.app.ActivityThread.main() 8,546 java.lang.reflect.Method.invoke() -2 com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run() 582 com.android.internal.os.ZygoteInit.main() 1,061 上面的关键信息有： NA Crash，Signal 11 -&gt; SIGSEGV -&gt; 非法内存操作，空指针操作 进程名，包名只展示后15个字符 pid 进程id；tid 线程id code 1，代表 SEGV_MAPERR Native调用堆栈（backtrace）。具体数据都来自Dl_info结构体 行号计数（#0） pc（加载模块的句柄） dli_fname（一个指针，指向包含address的加载模块的文件名） dli_sname（一个指针，指向与指定address最接近的符号的名称） saddr（地址的偏移量，即与代码段函数地址的偏移量） Java调用堆栈（根据线程名匹配） 根据日志堆栈定位到代码使用addr2line和objdump命令这两个命令行工具已在NDK中集成，在我的mac上地址如下：/Users/xxx/Library/Android/sdk/ndk/21.4.7075529/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin addr2line 工具可以帮助定位到代码行号执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可：./aarch64-linux-android-addr2line -e /Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/build/intermediates/cmake/normDebug/obj/arm64-v8a/libcrash-lib.so 000000000000f6d0 000000000000f774 结果如下：/Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/.cxx/Debug/2b1z3a2r/arm64-v8a/../../../../src/main/cpp/crash.cpp:13/Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/.cxx/Debug/2b1z3a2r/arm64-v8a/../../../../src/main/cpp/crash.cpp:29 从addr2line的结果就能看到，我们拿到了错误代码的调用行数（其实也可以分析出调用关系，本例体现不出来），在crash.cpp的13行和29行 addr2line 命令使用介绍：https://cloud.tencent.com/developer/article/2019609 objdump命令获取函数信息通过addr2line命令，其实我们已经找到了我们代码中出错的位置，已经可以帮助程序员定位问题所在了。但是，这个方法只能获取代码行数，并没有显示函数信息，下面就用objdump命令来获取函数信息. /Users/xxx/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump -S /Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/build/intermediates/cmake/normDebug/obj/arm64-v8a/libcrash-lib.so &gt; testcrash.asm 在生成的asm文件中查找刚刚我们定位的关键指针000000000000f6d0，如下图 从上图可以看出，这个指针所在的方法名。结合前面的行号，可以进一步确定发生异常的位置（要注意的是，在不同的NDK版本和不同的操作系统中，asm文件的格式不是完全相同，但都大同小异，请大家仔细比对）。 objdump命令详细介绍：https://cloud.tencent.com/developer/article/1494510 实时解析crash日志使用 ndk-stack工具，在我的电脑上，位置是：/Users/xxx/Library/Android/sdk/ndk/21.4.7075529/ndk-stack 使用方法如下：adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi-v7a 参考链接：https://developer.android.com/ndk/guides/ndk-stack?hl=zh-cn 进程名展示不全原因Tips: 为什么进程名对比包名，有时候展示不全？ 简单来说，这是因为Linux内核的一个特性：一个进程有两个不同的名称。 其中一个是可执行文件路径的最后一个组件。例如，如果您的应用程序位于/data/app/com.example.hello/native_executable，则为native_eexecute。这是出现在/proc/PID/status的“名称”字段中的名称。内核将其截断为15个字符，因此在本例中它包含native_executob。 另一个名称由调用应用程序的程序传递，作为其命令行参数。这是出现在/proc/PID/cmdline开头的名称，ps显示该名称。 可执行文件的路径也是符号链接/proc/PID/exe的目标。按照惯例，当一个程序启动另一个程序时，它应该使用可执行文件的名称作为命令行参数0，但它可以选择其他方式。/proc/PID/status的Name字段始终设置为内核可执行文件的（截断的）名称。 来自：https://stackoverflow.com/questions/14176058/why-is-the-name-of-a-process-in-proc-pid-status-not-matching-package-name-or-ps 线上崩溃堆栈还原 1.模拟示例源码： int add()&#123; int a = 1; a ++; int b = a+3; return b;&#125;int div()&#123; int a = 1; a ++; int b = a/0; //这里除0会引发崩溃 return b;&#125;int _tmain(int argc, _TCHAR* argv[])&#123; add(); sub(); return 0;&#125; 2.对应符号表，这里简化了符号表，没带行号信息 0x00F913B0 ~ 0x00F913F0 add()0x00F91410 ~ 0x00F91450 div()0x00F91A90 ~ 0x00F91ACD _tmain() 3.现有一崩溃堆栈 0x00F9143A0x00F91AB0 4.进行符号化 0x00F9143A div() //查找符号表，地址0x00F9143A的符号名，在0x00F91410 ~ 0x00F91450范围内0x00F91AB0 _tmain() //查找符号表，地址0x00F91AB0的符号名，在0x00F91A90 ~ 0x00F91ACD范围内 这里的符号化最终也是用到addr2line工具 更详细信息参考：客户端堆栈还原原理及实现 常见的NA Crash类型1. SIGILLSIG是信号名的通用前缀，ILL是 illegal instruction（ 非法指令 ） 的缩写。 对应的数值为 4。 SIGILL 是当一个进程尝试执行一个非法指令时发送给它的信号。 常见原因有: CPU架构不匹配 .so 文件被破坏，或者代码段被破坏导致； 主动崩溃，如 _builtintrap() 也会使用非法指令来实现。 si_addr 为出错的指令。 该信号量中常见的错误码说明： Code 说明 ILL_ILLOPC 非法的操作码(opcode) ILL_ILLOPN 非法的操作数(operand) ILL_ILLADR 非法的寻址模式 ILL_ILLTRP 非法的trap ILL_PRVOPC 特权操作码(Privileged opcode) ILL_PRVREG 特权寄存器(Privileged register) ILL_COPROC 协处理器错误 ILL_BADSTK 内部堆栈错误 2. SIGBUSSIG是信号名的通用前缀，BUS是bus error (总线错误) ，意味着系统检测到硬件问题后发送给进程的信号。 对应的数值为7。 通常该信号的产生不是因为硬件有物理上的损坏，而是代码实现有 bug 导致 ，如地址不对齐，或者不存在的物理地址等。 si_addr 为所访问的非法地址。 该信号量中常见的错误码说明： Code 说明 BUS_ADRALN 访问的地址不对齐。32位处理器一般要求指针是4字节对齐的 BUS_ADRERR 访问不存在的物理地址。一般是由于 mmap 的文件发生 truncated 导致。常见于文件访问过程中，被删除或者替换；或 mmap 到内存后，继续向文件写入且导致文件 truncated，再读取时就会出现该错误；另外， mmap 且访问超过文件实际大小的空间时，也可能会出现该错误 BUS_OBJERR 特定对象的硬件错误 BUS_MCEERR_AR BUS_MCEERR_AR BUS_MCEERR_AQ BUS_MCEERR_AQ 3. SIGSEGVSIG 是信号名的通用前缀, SEGV 是 segmentation violation 的缩写。 对应的数值为 11。 该信号意味着一个进程执行了一个无效的内存引用，或发生段错误。 si_addr 为所访问的无效地址。 该信号量中常见的错误码说明： Code 说明 SEGV_MAPERR 地址不在 /proc/self/map 映射中 SEGV_ACCERR 没有访问权限 4. SIGFPESIG是信号名的通用前缀。FPE是floating-point exception（浮点异常）的首字母缩写拼接而成。 对应的数值为 8。 该信号一般是算术运算相关问题导致的。 si_addr 为失败的指令。 该信号量中常见的错误码说明： Code 说明 FPE_INTDIV 整数除以 0 FPE_INTOVF 整数溢出 FPE_FLTDIV 浮点数除以 0 FPE_FLTOVF 浮点数向下溢出 FPE_FLTRES 浮点数结果不精确 FPE_FLTINV 无效的浮点运算 FPE_FLTSUB 下标超出范围 5. SIGABRTSIG是信号名的通用前缀。ABRT是abort program的缩写。 对应的数值为 6。 该信号意味着异常退出；通常是调用 abort(), raise(), kill(), pthread_kill() 或者被系统进程杀死时出现。 当错误码为 SI_USER 时表示是被其它程序杀死，一般情况是由于ANR被 system_server 杀死； 其他错误码一般是业务自己调用 abort() 等函数退出，此时错误码一般认为无效。 6. SIGSTKFLTSIG是信号名的通用前缀，STKFLT是stack fault 的缩写。 对应的数值为 16。 按照官方文档说明，该信号量意味着协处理器栈故障。 根据网上的部分问题结论说明，在内存耗尽时，一般 malloc 返回 NULL 且设置 errno 为 ENOMEM，但有些系统可能会使用 SIGSTKFLT 信号代替。 7. SIGPIPE该信号对应的数值为 13。 该信号意味着管道错误，通常在进程间通信产生，比如采用FIFO(管道)通信的两个进程，读管道没打开或者意外终止仍继续往管道写，写进程就会收到 SIGPIPE 信号。 8. SIGUSR2为 12。用户自定义信号2。 9. SIGTERMSIG是信号名的通用前缀，TERM 是 Termination 的缩写。该信号对应的数值为 15。 与 SIGKILL (signal 9) 类似，不过 SIGKILL 不可捕获，而 SIGTERM 可被捕获。一般常见于 APP 处于后台时，被系统 vold 进程使用 SIGTERM 杀死，该情形基本没有意义，可忽略。 另外，chromium 多进程架构中，经常也会使用 SIGTERM 杀死出现了异常的子进程。 10. SIGSYS该信号对应的数值为 31，通常是因为无效的 linux 内核系统调用而产生。 在 android O (android 8.0) 中，部分不安全的系统调用被移除，若代码中仍然使用它们，则会出现 SIGSYS。 11. SIGTRAP该信号对应的数值为 5。gdb 调试设置断点等操作使用的信号。 Code 说明 TRAP_BRKPT TRAP_BRKPT TRAP_TRACE TRAP_TRACE TRAP_BRANCH TRAP_BRANCH TRAP_HWBKPT TRAP_HWBKPT 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Native Crash","slug":"native-crash","permalink":"http://agehua.github.io/tags/native-crash/"}]},{"title":"Native Crash捕获原理","slug":"native-crash-principle","date":"2023-11-01T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2023/11/02/native-crash-principle/","link":"","permalink":"http://agehua.github.io/2023/11/02/native-crash-principle/","excerpt":"本文主要介绍Native Crash捕获原理","text":"本文主要介绍Native Crash捕获原理 目前流行的Native Crash捕获方案 方案 优点 缺点 Google Breakpad 官方出品，多平台支持，文档全面 代码体量大，crash信息保存在mini_dump文件中，拿到dump文件后，需要再次解析才能获取crash堆栈 利用Logcat日志 利用Android系统实现 需要再Crash时启动新进程过滤logcat日志，不可靠 unwind库 实现简单，改动容易。很多三方库也是基于该方案 需要了解信号机制，自行实现获取Crash堆栈方式 本次实践采用方案三（unwind） 使用 信号量+&lt;unwind.h&gt;库。 崩溃信息写入文件，通过 log 上传到日志平台（Elastic） 下次启动后读取文件内容上报，然后删除文件 对java层的崩溃捕获不会有任何影响，Native层Crash bugly不再能够捕获异常 实现方案细节要实现 Native Crash 的收集，主要有四个重点： 知道 Crash 的发生； 捕获到 Crash 的位置； 获取 Crash 发生位置的函数调用栈； 数据能回传到服务器。 一、知道 Crash 的发生与 Java 平台不同，C/C++ 没有一个通用的异常处理接口，在 C 层，CPU 通过异常中断的方式，触发异常处理流程。不同的处理器，有不同的异常中断类型和中断处理方式，linux 把这些中断处理，统一为信号量，每一种异常都有一个对应的信号，可以注册回调函数进行处理需要关注的信号量。 信号量定义在 signal.h 中，常见的信号量有：#define SIGHUP 1 // 终端连接结束时发出(不管正常或非正常)#define SIGINT 2 // 程序终止(例如Ctrl-C)#define SIGQUIT 3 // 程序退出(Ctrl-\\)#define SIGILL 4 // 执行了非法指令，或者试图执行数据段，堆栈溢出#define SIGTRAP 5 // 断点时产生，由debugger使用#define SIGABRT 6 // 调用abort函数生成的信号，表示程序异常#define SIGIOT 6 // 同上，更全，IO异常也会发出#define SIGBUS 7 // 非法地址，包括内存地址对齐出错，比如访问一个4字节的整数, 但其地址不是4的倍数#define SIGFPE 8 // 计算错误，比如除0、溢出#define SIGKILL 9 // 强制结束程序，具有最高优先级，本信号不能被阻塞、处理和忽略#define SIGUSR1 10 // 未使用，保留#define SIGSEGV 11 // 非法内存操作，与SIGBUS不同，他是对合法地址的非法访问，比如访问没有读权限的内存，向没有写权限的地址写数据#define SIGUSR2 12 // 未使用，保留#define SIGPIPE 13 // 管道破裂，通常在进程间通信产生#define SIGALRM 14 // 定时信号,#define SIGTERM 15 // 结束程序，类似温和的SIGKILL，可被阻塞和处理。通常程序如果终止不了，才会尝试SIGKILL#define SIGSTKFLT 16 // 协处理器堆栈错误#define SIGCHLD 17 // 子进程结束时, 父进程会收到这个信号。#define SIGCONT 18 // 让一个停止的进程继续执行#define SIGSTOP 19 // 停止进程,本信号不能被阻塞,处理或忽略#define SIGTSTP 20 // 停止进程,但该信号可以被处理和忽略#define SIGTTIN 21 // 当后台作业要从用户终端读数据时, 该作业中的所有进程会收到SIGTTIN信号#define SIGTTOU 22 // 类似于SIGTTIN, 但在写终端时收到#define SIGURG 23 // 有紧急数据或out-of-band数据到达socket时产生#define SIGXCPU 24 // 超过CPU时间资源限制时发出#define SIGXFSZ 25 // 当进程企图扩大文件以至于超过文件大小资源限制#define SIGVTALRM 26 // 虚拟时钟信号. 类似于SIGALRM, 但是计算的是该进程占用的CPU时间.#define SIGPROF 27 // 类似于SIGALRM/SIGVTALRM, 但包括该进程用的CPU时间以及系统调用的时间#define SIGWINCH 28 // 窗口大小改变时发出#define SIGIO 29 // 文件描述符准备就绪, 可以开始进行输入/输出操作#define SIGPOLL SIGIO // 同上，别称#define SIGPWR 30 // 电源异常#define SIGSYS 31 // 非法的系统调用 注册信号处理函数，也是在 signal.h 中：int sigaction(int __signal, const struct sigaction* __new_action, struct sigaction* __old_action); 第一个参数 int 类型，表示需要关注的信号量 第二个参数 sigaction 结构体指针，用于声明当某个特定信号发生的时候，应该如何处理 第三个参数也是 sigaction 结构体指针，他表示的是默认处理方式，当我们自定义了新的信号量处理的时候，用他来存储之前默认的处理方式。这也是指针与引用的区别，指针操作操作的都是变量本身，所以给新指针赋值了以后，需要另一个指针来记录封装了默认处理方式的变量在内存中的位置。 sigaction 内容结构体如下：struct sigaction &#123; union &#123; sighandler_t sa_handler; void (*sa_sigaction)(int, struct siginfo*, void*); &#125;; sigset_t sa_mask; int sa_flags; void (*sa_restorer)(void);&#125;; sa_sigaction就是信号处理函数的指针，这个指针指向的是一个拥有三个参数的函数，结构体中定义的函数指针为： void (*sa_sigaction)(int, struct siginfo_t *,void *) 1.第一个参数为信号值 2.第二个参数为信号的一些具体信息 3.第三个参数为一些上下文信息, 包括崩溃时的 pc 值 siginfo_t 结构体siginfo_t &#123; int si_signo; /* 信号数值 */ int si_errno; /* 错误值 */ int si_code; /* 信号代码 */ int si_trapno; /*导致硬件生成信号的陷阱号，在大多数体系结构中未使用*/ pid_t si_pid; /* 发送信号的进程ID */ uid_t si_uid; /*发送信号的真实用户ID */ int si_status; /* 退出值或信号状态*/ clock_t si_utime; /*消耗的用户时间*/ clock_t si_stime; /*消耗的系统时间*/ sigval_t si_value; /*信号值*/ int si_int; /* POSIX.1b 信号*/ void *si_ptr; int si_overrun; /*计时器溢出计数*/ int si_timerid; /* 计时器ID */ void *si_addr; /*导致故障的内存位置 */ long si_band; int si_fd; /* 文件描述符*/ short si_addr_lsb; /*地址的最低有效位 (从Linux 2.6.32开始存在) */ void *si_lower; /*地址冲突时的下限*/ void *si_upper; /*地址冲突时的上限 (从Linux 3.19开始存在) */ int si_pkey; /*导致的PTE上的保护密钥*/ void *si_call_addr; /*系统调用指令的地址*/ int si_syscall; /*尝试的系统调用次数*/ unsigned int si_arch; /* 尝试的系统调用的体系结构*/ &#125; 结构体内包含了我们常见的si_signo、si_code、si_errno等。类似：Native Crash, signal: 11, tname: conorlee.test, pid: 13283, tid: 13283, code: 1, error: 0 所以，要订阅异常发生的信号，最简单的做法就是直接用一个循环遍历所有要订阅的信号，对每个信号调用sigaction()，如下示例： void init() &#123; struct sigaction handler; struct sigaction old_signal_handlers[SIGNALS_LEN]; for (int i = 0; i &lt; SIGNALS_LEN; ++i) &#123; sigaction(signal_array[i], &amp;handler, &amp; old_signal_handlers[i]); &#125;&#125; 二、捕获到Crash的位置然后，我们仿照上面的信号处理函数定义，可以声明一个函数，直接将函数的地址赋值给sa_sigaction // 我们声明的函数void signal_handle(int code, siginfo_t *si, void *context) &#123;&#125;void init() &#123; struct sigaction old_signal_handlers[SIGNALS_LEN]; struct sigaction handler; // 赋值给该指针 handler.sa_sigaction = signal_handle; handler.sa_flags = SA_SIGINFO; for (int i = 0; i &lt; SIGNALS_LEN; ++i) &#123; sigaction(signal_array[i], &amp;handler, &amp; old_signal_handlers[i]); &#125;&#125; 这样当发生 Crash 的时候就会回调我们传入的signal_handle()函数了。在signal_handle()函数中，通过siginfo_t 结构体，我们就能拿到当前执行的代码信息。 设置紧急栈空间如果当前函数发生了无限递归造成堆栈溢出，在统计的时候需要考虑到这种情况来新开堆栈，否则本来就满了的堆栈又在当前堆栈处理溢出信号，处理肯定是会失败的。所以我们需要设置一个用于紧急处理的新栈，可以使用 sigaltstack() 在任意线程注册一个可选的栈，保留一下在紧急情况下使用的空间。（系统会在危险情况下把栈指针指向这个地方，使得可以在一个新的栈上运行信号处理函数） void signal_handle_test(int sig) &#123; write(2, \"stack overflow\\n\", 15); _exit(1);&#125;unsigned infinite_recursion(unsigned x) &#123; return infinite_recursion(x)+1;&#125;int main() &#123; static char stack[SIGSTKSZ]; stack_t ss = &#123; .ss_size = SIGSTKSZ, .ss_sp = stack, &#125;; struct sigaction sa = &#123; .sa_handler = signal_handle_test, .sa_flags = SA_ONSTACK &#125;; sigaltstack(&amp;ss, 0); sigfillset(&amp;sa.sa_mask); sigaction(SIGSEGV, &amp;sa, 0); infinite_recursion(0);&#125; 三、捕获出问题的代码signal_handle() 函数中的第三个参数 context 是uc_mcontext的结构体指针，它封装了 cpu 相关的上下文，包括当前线程的寄存器信息和奔溃时的 pc 值，能够知道崩溃时的pc，就能知道崩溃时执行的是那条指令。 不过uc_mcontext结构体的定义是平台相关的，比如我们熟知的arm、x86这种都不是同一个结构体定义，要兼容其他架构的 cpu 在处理的时候，就得要寄出宏编译大法，不同的架构使用不同的定义，如下展示了不同架构获取pc值（绝对内存地址）的不同方式： uintptr_t pc_from_ucontext(const ucontext_t *uc) &#123;#if (defined(__arm__)) return uc-&gt;uc_mcontext.arm_pc;#elif defined(__aarch64__) return uc-&gt;uc_mcontext.pc;#elif (defined(__x86_64__)) return uc-&gt;uc_mcontext.gregs[REG_RIP];#elif (defined(__i386)) return uc-&gt;uc_mcontext.gregs[REG_EIP];#elif (defined (__ppc__)) || (defined (__powerpc__)) return uc-&gt;uc_mcontext.regs-&gt;nip;#elif (defined(__hppa__)) return uc-&gt;uc_mcontext.sc_iaoq[0] &amp; ~0x3UL;#elif (defined(__sparc__) &amp;&amp; defined (__arch64__)) return uc-&gt;uc_mcontext.mc_gregs[MC_PC];#elif (defined(__sparc__) &amp;&amp; !defined (__arch64__)) return uc-&gt;uc_mcontext.gregs[REG_PC];#else#error \"Architecture is unknown, please report me!\"#endif&#125; pc值转内存地址pc值是程序加载到内存中的绝对地址，绝对地址不能直接使用，因为每次程序运行创建的内存肯定都不是固定区域的内存，所以绝对地址肯定每次运行都不一致。我们需要拿到崩溃代码相对于当前库的相对偏移地址，这样才能使用 addr2line 分析出是哪一行代码。 通过 dladdr() 可以获得共享库加载到内存的起始地址，和pc值相减就可以获得相对偏移地址，并且可以获得共享库的名字。 Dl_info info; if (dladdr(addr, &amp;info) &amp;&amp; info.dli_fname) &#123; void * const nearest = info.dli_saddr; uintptr_t addr_relative = addr - info.dli_fbase; &#125; 获取 Crash 发生时的函数调用栈获取函数调用栈是最麻烦的，至今没有一个好用的，全都要做一些大改动。常见的做法有四种： 第一种：直接使用系统的&lt;unwind.h&gt;库，可以获取到出错文件与函数名。只不过需要自己解析函数符号，同时经常会捕获到系统错误，需要手动过滤。 第二种：在4.1.1以上，5.0以下，使用系统自带的 libcorkscrew.so，5.0开始，系统中没有了libcorkscrew.so，可以自己编译系统源码中的libunwind。libunwind是一个开源库，事实上高版本的安卓源码中就使用了他的优化版替换 libcorkscrew。 第三种：使用开源库coffeecatch，但是这种方案也不能百分之百兼容所有机型。 第四种：使用 Google 的breakpad，这是所有 C/C++堆栈获取的权威方案，基本上业界都是基于这个库来做的。只不过这个库是全平台的 android、iOS、Windows、Linux、MacOS 全都有，所以非常大，在使用的时候得把无关的平台剥离掉减小体积。 下面以第一种为例讲一下实现： 核心方法是使用&lt;unwind.h&gt;库提供的一个方法_Unwind_Backtrace()这个函数可以传入一个函数指针作为回调，指针指向的函数有一个重要的参数是_Unwind_Context类型的结构体指针。可以使用_Unwind_GetIP()函数将当前函数调用栈中每个函数的绝对内存地址（也就是上文中提到的 pc 值），写入到_Unwind_Context结构体中，最终返回的是当前调用栈的全部函数地址了，_Unwind_Word实际上就是一个unsigned int。而capture_backtrace()返回的就是当前我们获取到调用栈中内容的数量。 /** * callback used when using &lt;unwind.h&gt; to get the trace for the current context */_Unwind_Reason_Code unwind_callback(struct _Unwind_Context *context, void *arg) &#123; backtrace_state_t *state = (backtrace_state_t *) arg; _Unwind_Word pc = _Unwind_GetIP(context); if (pc) &#123; if (state-&gt;current == state-&gt;end) &#123; return _URC_END_OF_STACK; &#125; else &#123; *state-&gt;current++ = (void *) pc; &#125; &#125; return _URC_NO_REASON;&#125;/** * uses built in &lt;unwind.h&gt; to get the trace for the current context */size_t capture_backtrace(void **buffer, size_t max) &#123; backtrace_state_t state = &#123;buffer, buffer + max&#125;; _Unwind_Backtrace(unwind_callback, &amp;state); return state.current - buffer;&#125; 当所有的函数的绝对内存地址(pc 值)都获取到了，就可以用上文讲的办法将 pc 值转换为相对偏移量，获取到真正的函数信息和相对内存地址了。void *buffer[max_line];int frames_size = capture_backtrace(buffer, max_line);for (int i = 0; i &lt; frames_size; i++) &#123; Dl_info info; const void *addr = buffer[i]; if (dladdr(addr, &amp;info) &amp;&amp; info.dli_fname) &#123; void * const nearest = info.dli_saddr; uintptr_t addr_relative = addr - info.dli_fbase; &#125; Dl_info是一个结构体，内部封装了函数所在文件、函数名、当前库的基地址等信息 具体结构体如下：typedef struct &#123; /* Pathname of shared object that contains address. */ const char* dli_fname; /* Address at which shared object is loaded. */ void* dli_fbase; /* Name of nearest symbol with address lower than addr. */ const char* dli_sname; /* Exact address of symbol named in dli_sname. */ void* dli_saddr;&#125; Dl_info; 有了这个对象，我们就能获取到全部想要的信息了。虽然获取到全部想要的信息，但&lt;unwind.h&gt;有个麻烦的就是不想要的信息也给你了，所以需要手动过滤掉各种系统错误，最终得到的数据，就可以上报到自己的服务器了。 如何分析上面抓到各种信息，可以看我的下一篇文章：《Native Crash日志分析》 四、数据传回到服务器数据回传有两种方式，一种是直接将信息写入文件，下次启动的时候直接由 Java 上报；另一种就是回调 Java 代码，让 Java 去处理。用 Java 处理的好处是 Java 层可以继续在当前上下文上加上 Java 层的各种状态信息，写入到同一个文件中，使得开发在解决 bug 的时候能更方便。 目前遗留的问题 64位so在部分设备（比如我自己的 IQOO）上无法获取到崩溃堆栈，只能捕获到信号，但是32位的so没有这个问题 数据可以上传到java层，但是日志上报是在java层的子线程，native无法等待子线程执行完成 堆栈信息在java层上传的时候未格式化 部分backtrace没有关键信息，比如一些SIGSEGV RefAndroid Native Crash 收集 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/11/02/native-crash-principle/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Native Crash","slug":"native-crash","permalink":"http://agehua.github.io/tags/native-crash/"}]},{"title":"跨进程通信Bridge建立","slug":"cross-process-bridge","date":"2023-10-25T16:00:00.000Z","updated":"2024-12-05T09:41:25.330Z","comments":true,"path":"2023/10/26/cross-process-bridge/","link":"","permalink":"http://agehua.github.io/2023/10/26/cross-process-bridge/","excerpt":"本文介绍了Android跨进程通信的原理，并对Hermes的源码进行分析。\n先简单总结下：Hermes也是通过AIDL的方式来最终实现跨进程通信，通信的内容是Gson。其中用到的了动态代理技术。后面再详细分析下为什么要用到动态代理","text":"本文介绍了Android跨进程通信的原理，并对Hermes的源码进行分析。 先简单总结下：Hermes也是通过AIDL的方式来最终实现跨进程通信，通信的内容是Gson。其中用到的了动态代理技术。后面再详细分析下为什么要用到动态代理 手动创建IInterface类如何创建AIDL文件本文就不在讲了，感兴趣的可以看我之前的文章：Android Binder 机制分析（一） 代理什么是代理代理就是客户类不再直接和委托类打交道, 而是通过一个中间层来访问, 这个中间层就是代理。为啥要这样呢, 是因为使用代理有两个优势： 1.可以隐藏委托类的实现 2.可以实现客户与委托类之间的解耦, 在不修改委托类代码的情况下能够做一些额外的处理 静态代理接口：public interface HelloService &#123; String sayHello(String content);&#125; 接口实现类 public class HelloServiceImpl implements HelloService &#123; @Override public String sayHello(String content) &#123; return \"hello \" + content; &#125;&#125; 代理类 public class HelloServiceProxy implements HelloService &#123; private HelloService helloService; public HelloServiceProxy(HelloService helloService) &#123; this.helloService = helloService; &#125; @Override public String sayHello(String content) &#123; System.out.println(\"before invoke\"); String result = helloService.sayHello(content); System.out.println(\"after invoke\"); return result; &#125;&#125; 这里的代理类其实也满足了一个面向对象的设计原则，即组合优先于集成。 动态代理Java动态代理是一种在运行时创建代理类的方法。它可以在不修改源代码的情况下，在程序运行期间为接口创建代理类。它基于 Java 反射机制实现。 动态代理是一种很有用的工具，可以帮助您在不更改目标对象代码的情况下对其进行包装。 动态代理是为接口创建代理类，所以要提前定义一个接口：public interface HelloService &#123; String sayHello(String content);&#125; HelloServiceImpl实现类public class HelloServiceImpl implements HelloService &#123; @Override public String sayHello(String content) &#123; return \"hello \" + content; &#125;&#125; 使用InvocationHandler，实现动态代理public class MyInvocationHandler implements InvocationHandler &#123; // 真实对象 private Object obj; public MyInvocationHandler(Object obj) &#123; this.obj = obj; &#125; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable &#123; System.out.println(\"before invoke......\"); // 此处通过反射，调用真实对象的相关方法 Object result = method.invoke(obj, args); System.out.println(\"after invoke......\"); return result; &#125;&#125; 如何使用：public class DynamicProxyTest &#123; public static void main(String[] args) &#123; String content = \"dynamic proxy\"; // 创建真实实现对象 HelloService helloService = new HelloServiceImpl(); // 创建调用器 InvocationHandler handler = new MyInvocationHandler(helloService); // 创建代理实例 Object proxy = Proxy.newProxyInstance(helloService.getClass().getClassLoader(), helloService.getClass() .getInterfaces(), handler); System.out.println(\"代理类名称:\" + proxy.getClass().getName()); System.out.println(\"代理类接口:\" + proxy.getClass().getInterfaces()[0].getName()); // 类型转换 HelloService proxyService = (HelloService) proxy; // 执行代理逻辑 System.out.println(proxyService.sayHello(content)); &#125;&#125; 输出：代理类名称:com.sun.proxy.$Proxy0代理类接口:com.sankuai.meituan.zcm.depot.proxy.HelloServicebefore invoke......after invoke......hello dynamic proxy 动态代理分析public final class $Proxy0 extends Proxy implements HelloService &#123; private static Method m1; private static Method m3; private static Method m2; private static Method m0; public $Proxy0(InvocationHandler var1) throws &#123; super(var1); &#125; public final boolean equals(Object var1) throws &#123; try &#123; return (Boolean)super.h.invoke(this, m1, new Object[]&#123;var1&#125;); &#125; catch (RuntimeException | Error var3) &#123; throw var3; &#125; catch (Throwable var4) &#123; throw new UndeclaredThrowableException(var4); &#125; &#125; // 对外的代理方法，下面的h是上面传入的handler public final String sayHello(String var1) throws &#123; try &#123; return (String)super.h.invoke(this, m3, new Object[]&#123;var1&#125;); &#125; catch (RuntimeException | Error var3) &#123; throw var3; &#125; catch (Throwable var4) &#123; throw new UndeclaredThrowableException(var4); &#125; &#125; public final String toString() throws &#123; try &#123; return (String)super.h.invoke(this, m2, (Object[])null); &#125; catch (RuntimeException | Error var2) &#123; throw var2; &#125; catch (Throwable var3) &#123; throw new UndeclaredThrowableException(var3); &#125; &#125; public final int hashCode() throws &#123; try &#123; return (Integer)super.h.invoke(this, m0, (Object[])null); &#125; catch (RuntimeException | Error var2) &#123; throw var2; &#125; catch (Throwable var3) &#123; throw new UndeclaredThrowableException(var3); &#125; &#125; static &#123; try &#123; m1 = Class.forName(\"java.lang.Object\").getMethod(\"equals\", Class.forName(\"java.lang.Object\")); m3 = Class.forName(\"com.sankuai.meituan.zcm.depot.proxy.HelloService\").getMethod(\"sayHello\", Class.forName(\"java.lang.String\")); m2 = Class.forName(\"java.lang.Object\").getMethod(\"toString\"); m0 = Class.forName(\"java.lang.Object\").getMethod(\"hashCode\"); &#125; catch (NoSuchMethodException var2) &#123; throw new NoSuchMethodError(var2.getMessage()); &#125; catch (ClassNotFoundException var3) &#123; throw new NoClassDefFoundError(var3.getMessage()); &#125; &#125;&#125; 怎么拿到动态生成的代理classimport sun.misc.ProxyGenerator;import java.io.FileOutputStream;import java.io.IOException;public class ProxyUtils &#123; /** * 将根据类信息动态生成的二进制字节码保存到硬盘中，默认的是clazz目录下 * params: clazz 需要生成动态代理类的类 * proxyName: 为动态生成的代理类的名称 */ public static void generateClassFile(Class clazz, String proxyName) &#123; // 根据类信息和提供的代理类名称，生成字节码 byte[] classFile = ProxyGenerator.generateProxyClass(proxyName, clazz.getInterfaces()); String paths = clazz.getResource(\".\").getPath(); System.out.println(paths); FileOutputStream out = null; try &#123; //保留到硬盘中 out = new FileOutputStream(paths + proxyName + \".class\"); out.write(classFile); out.flush(); &#125; catch (Exception e) &#123; e.printStackTrace(); &#125; finally &#123; try &#123; out.close(); &#125; catch (IOException e) &#123; e.printStackTrace(); &#125; &#125; &#125;&#125; 然后运行下面的代码就可以：// 保存JDK动态代理生成的代理类，类名保存为 UserServiceProxyProxyUtils.generateClassFile(userServiceImpl.getClass(), \"UserServiceProxy\"); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/10/26/cross-process-bridge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"multi-process","slug":"multi-process","permalink":"http://agehua.github.io/tags/multi-process/"}]},{"title":"Matrix TraceCanary源码分析","slug":"matrix-trace-canary","date":"2023-09-25T16:00:00.000Z","updated":"2024-12-05T09:41:25.309Z","comments":true,"path":"2023/09/26/matrix-trace-canary/","link":"","permalink":"http://agehua.github.io/2023/09/26/matrix-trace-canary/","excerpt":"本文主要介绍Matrix的Trace部分，主要涉及帧率、ANR、慢函数、启动耗时的检测逻辑。","text":"本文主要介绍Matrix的Trace部分，主要涉及帧率、ANR、慢函数、启动耗时的检测逻辑。 Trace Canary主要特性 编译期动态修改字节码, 高性能记录执行耗时与调用堆栈 准确的定位到发生卡顿的函数，提供执行堆栈、执行耗时、执行次数等信息，帮助快速解决卡顿问题 自动涵盖卡顿、启动耗时、页面切换、慢函数检测等多个流畅性指标 Tracer模块主要结构： 其中： FrameTracer负责帧率检测 AnrTracer负责ANR问题检测 EvilMethodTracer负责检测慢函数 StartupTracer负责应用启动耗时检测 帧率检测FrameTracer部分主要做帧率、掉帧、帧耗时等检测，具体实现逻辑在FrameTracer和UIThreadMonitor。 Demo中的入口在TestFpsActivity，onCreate()中通过FrameTracer.onStartTrace()开启检测，页面退出时通过FrameTracer.onCloseTrace()结束检测，并移除监控回调。 从使用侧开始，看看帧率的计算逻辑。 TestFpsActivity：sample.tencent.matrix.trace.TestFpsActivityprotected void onCreate(@Nullable Bundle savedInstanceState) &#123; // 启动帧率检测，使用FrameTrace计算FPS Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().onStartTrace(); // 添加帧率回调 Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().addListener(mDoFrameListener);&#125;protected void onDestroy() &#123; super.onDestroy(); // 移除帧率回调 Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().removeListener(mDoFrameListener); // 关闭帧率检测 Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().onCloseTrace();&#125; 看下TestFpsActivity的FPS监控回调部分：sample.tencent.matrix.trace.TestFpsActivity// 异步线程private static HandlerThread sHandlerThread = new HandlerThread(\"test\");// 帧率检测回调private IDoFrameListener mDoFrameListener = new IDoFrameListener(new Executor() &#123; Handler handler = new Handler(sHandlerThread.getLooper()); @Override public void execute(Runnable command) &#123; //将回调方法放到异步线程执行 handler.post(command); &#125; &#125;) &#123; @Override public void doFrameAsync(String visibleScene, long taskCost, long frameCostMs, int droppedFrames, boolean isContainsFrame) &#123; super.doFrameAsync(visibleScene, taskCost, frameCostMs, droppedFrames, isContainsFrame); // 计算总的掉帧数 count += droppedFrames; &#125; &#125;; 回调接口IDoFrameListener支持将同步和异步回调方法：doFrameSync()和doFrameAsync，需要使用侧传入一个Executor。 解释下IDoFrameListener.doFrameAsync()的参数含义： visibleScene：场景名称，默认是Activity的类名 taskCost：主线程每一帧耗时 frameCostMs：帧率检测时用不到 droppedFrames：掉帧数 isContainsFrame：是否包含一帧 这里提一下visibleScene的获取逻辑：Matrix初始化时，AppActiveMatrixDelegate.controller()内部通过Application. registerActivityLifecycleCallbacks()监听Activity生命周期。当Activity start时，将activity.getClass().getName()做为visibleScene。FrameTracer再通过AppMethodBeat.getVisibleScene()获取visibleScene。 继续看下回调方法doFrameAsync()的上游逻辑。FrameTracer.notifyListener()：IDoFrameListener.doFrameAsync()是在FrameTracer.notifyListener()中调用的：com.tencent.matrix.trace.tracer.FrameTracer private void notifyListener(final String visibleScene, final long taskCostMs, final long frameCostMs, final boolean isContainsFrame) &#123; long start = System.currentTimeMillis(); try &#123; synchronized (listeners) &#123; for (final IDoFrameListener listener : listeners) &#123; if (config.isDevEnv()) &#123; listener.time = SystemClock.uptimeMillis(); &#125; // 计算掉帧数 final int dropFrame = (int) (taskCostMs / frameIntervalMs); listener.doFrameSync(visibleScene, taskCostMs, frameCostMs, dropFrame, isContainsFrame); if (null != listener.getExecutor()) &#123; //通过TestFpsActivity传入的Executor，将回调放到异步 listener.getExecutor().execute(new Runnable() &#123; @Override public void run() &#123; // 回调给TestFpsActivity listener.doFrameAsync(visibleScene, taskCostMs, frameCostMs, dropFrame, isContainsFrame); &#125; &#125;); &#125; &#125; &#125; &#125; finally &#123; long cost = System.currentTimeMillis() - start; // debug模式下，回调doFrameAsync中执行超过17ms，log警告 if (config.isDebug() &amp;&amp; cost &gt; frameIntervalMs) &#123; MatrixLog.w(TAG, \"[notifyListener] warm! maybe do heavy work in doFrameSync! size:%s cost:%sms\", listeners.size(), cost); &#125; &#125; &#125; 从上面代码可以看出掉帧数dropFrame就是taskCostMs/frameIntervalMs。 taskCostMs：一帧的执行耗时 frameIntervalMs：默认是17ms，计算逻辑是Choreographer.mFrameIntervalNanos+1。其中，Choreographer.mFrameIntervalNanos是屏幕刷新时间间隔，默认16ms。计算代码如下：com.tencent.matrix.trace.tracer.FrameTracerthis.frameIntervalMs = TimeUnit.MILLISECONDS.convert(UIThreadMonitor.getMonitor().getFrameIntervalNanos(), TimeUnit.NANOSECONDS) + 1;com.tencent.matrix.trace.core.UIThreadMonitorchoreographer = Choreographer.getInstance();// 通过反射获取Choreographer的mFrameIntervalNanos字段，默认是16msframeIntervalNanos = reflectObject(choreographer, \"mFrameIntervalNanos\"); 上面计算掉帧的方式：taskCostMs/17，其实并不是非常严谨，比如taskCostMs=33时，应该丢了两帧，但是计算结果是1。 上面提到的FrameTracer.notifyListener()由FrameTracer.doFrame()触发，看下FrameTracer.doFrame()： FrameTracer.doFrame():com.tencent.matrix.trace.tracer.FrameTracer@Override public void doFrame(String focusedActivityName, long start, long end, long frameCostMs, long inputCostNs, long animationCostNs, long traversalCostNs) &#123; if (isForeground()) &#123; // IDoFrameListener.doFrameAsync()中的参数taskCostMs即为end - start。 notifyListener(focusedActivityName, end - start, frameCostMs, frameCostMs &gt;= 0); &#125; &#125; 这个方法没有做太多事情，主要是计算掉帧数用的taskCostMs是end - start的结果。 FrameTracer.doFrame()由UIThreadMonitor.dispatchEnd()触发，看下后者的实现。 UIThreadMonitor.dispatchEnd()com.tencent.matrix.trace.core.UIThreadMonitor private void dispatchEnd() &#123; if (isBelongFrame) &#123; doFrameEnd(token); &#125; // 对应每一帧的开始时间，在dispatchBegin()中赋值 long start = token; // 对应每一帧的结束时间 long end = SystemClock.uptimeMillis(); synchronized (observers) &#123; for (LooperObserver observer : observers) &#123; if (observer.isDispatchBegin()) &#123; // isBelongFrame ? end - start : 0 - frameCost, 如果是帧耗时计算，则frameCost为0，否则和taskCost一样 // queueCost数组，存储对应Choreographer中三类task(input/animation/traversal)的耗时 observer.doFrame(AppMethodBeat.getVisibleScene(), token, SystemClock.uptimeMillis(), isBelongFrame ? end - start : 0, queueCost[CALLBACK_INPUT], queueCost[CALLBACK_ANIMATION], queueCost[CALLBACK_TRAVERSAL]); &#125; &#125; &#125; // 计算结束时间 dispatchTimeMs[3] = SystemClock.currentThreadTimeMillis(); dispatchTimeMs[1] = SystemClock.uptimeMillis(); AppMethodBeat.o(AppMethodBeat.METHOD_ID_DISPATCH); synchronized (observers) &#123; for (LooperObserver observer : observers) &#123; if (observer.isDispatchBegin()) &#123; observer.dispatchEnd(dispatchTimeMs[0], dispatchTimeMs[2], dispatchTimeMs[1], dispatchTimeMs[3], token, isBelongFrame); &#125; &#125; &#125; &#125; 这部分内容主要做了这几件事情： 获取每一帧耗时的开始、结束时间戳，即start、end，将差值通过observer.doFrame()传给消费方执行observer.doFrame()，该方法主要消费方是AnrTracer、EvilMethodTracer、FrameTracer赋值dispatchTimeMs[1]，dispatchTimeMs[3]，其中dispatchTimeMs数组含义后面会提到执行observer.dispatchEnd()，该方法主要消费方是AnrTracer、EvilMethodTracer看完了UIThreadMonitor.dispatchEnd()，再看下UIThreadMonitor.dispatchBegin()： com.tencent.matrix.trace.core.UIThreadMonitorprivate void dispatchBegin() &#123; // 对dispatchTimeMs[0]、dispatchTimeMs[2]赋值 token = dispatchTimeMs[0] = SystemClock.uptimeMillis(); dispatchTimeMs[2] = SystemClock.currentThreadTimeMillis(); AppMethodBeat.i(AppMethodBeat.METHOD_ID_DISPATCH); //每一帧开始执行时的回调 synchronized (observers) &#123; for (LooperObserver observer : observers) &#123; if (!observer.isDispatchBegin()) &#123; observer.dispatchBegin(dispatchTimeMs[0], dispatchTimeMs[2], token); &#125; &#125; &#125; &#125; 这里简单说下SystemClock.uptimeMillis()和SystemClock.currentThreadTimeMillis()的区别，详细内容可以看官方文档： SystemClock.uptimeMillis()：记录从开机到现在的时长，系统深睡眠（CPU睡眠、黑屏、系统等待外部输入对其唤醒）的时间不算在内，且不受系统设置时间调整的影响。是大多数时间间隔计算方法的基础，比如Thread.sleep(long)、Object.wait(long)、System.nanoTime() SystemClock.currentThreadTimeMillis()：这个比较容易理解，当前线程的活动时长（线程处于running状态） LooperObserver.dispatchEnd()解释下LooperObserver.dispatchEnd()的参数含义，后续对理解AnrTracer、EvilMethodTracer的实现有帮助：com.tencent.matrix.trace.listeners.LooperObserverpublic void dispatchEnd(long beginMs, long cpuBeginMs, long endMs, long cpuEndMs, long token, boolean isBelongFrame) beginMs：主线程一帧任务的开始时间点，对应dispatchTimeMs[0]，在UIThreadMonitor.dispatchBegin()中赋值 cpuBeginMs：当前线程活动期间，方法开始执行时间点，对应dispatchTimeMs[2] endMs：主线程一帧方法结束执行时间点，对应dispatchTimeMs[1]，在UIThreadMonitor.dispatchEnd()中赋值。所以，一帧耗时就是endMs-beginMs。 cpuEndMs：当前线程活动期间，方法解释执行时间点，对应dispatchTimeMs[3] token：等同于beginMs isBelongFrame：可简单理解为是否属于主线程任务。在Choreographer处理input任务时执行UIThreadMonitor.run()，内部将- - isBelongFrame置为true，这块逻辑可以看下UIThreadMonitor.onStart() 上面提到，一帧任务执行结束时会执行UIThreadMonitor.dispatchEnd()，该方法在LooperMonitor注册的监听器中执行的。看下这块逻辑： com.tencent.matrix.trace.core.UIThreadMonitorLooperMonitor.register(new LooperMonitor.LooperDispatchListener() &#123; @Override public boolean isValid() &#123; return isAlive; &#125; @Override public void dispatchStart() &#123; super.dispatchStart(); UIThreadMonitor.this.dispatchBegin(); &#125; @Override public void dispatchEnd() &#123; super.dispatchEnd(); UIThreadMonitor.this.dispatchEnd(); &#125; &#125;); UIThreadMonitor向LooperMonitor注册了监听器，用于监听每一帧的开始和结束。 其中，LooperDispatchListener的dispatchStart()和dispatchEnd()都是LooperMonitor.dispatch()执行的。由isBegin决定执行dispatchStart()还是dispatchEnd()。看下LooperMonitor.dispatch()：LooperMonitor.dispatch():com.tencent.matrix.trace.core.LooperMonitorprivate void dispatch(boolean isBegin, String log) &#123; for (LooperDispatchListener listener : listeners) &#123; if (listener.isValid()) &#123; if (isBegin) &#123; if (!listener.isHasDispatchStart) &#123; // 内部回调dispatchStart() listener.onDispatchStart(log); &#125; &#125; else &#123; if (listener.isHasDispatchStart) &#123; // 内部回调dispatchEnd() listener.onDispatchEnd(log); &#125; &#125; &#125; else if (!isBegin &amp;&amp; listener.isHasDispatchStart) &#123; listener.dispatchEnd(); &#125; &#125; &#125; isBegin的逻辑看下面代码：LooperMonitor.LooperPrinter:com.tencent.matrix.trace.core.LooperMonitorclass LooperPrinter implements Printer &#123; @Override public void println(String x) &#123; ... if (!isHasChecked) &#123; // 根据参数x内容，判断是开始还是结束，即isBegin isValid = x.charAt(0) == '&gt;' || x.charAt(0) == '&lt;'; isHasChecked = true; if (!isValid) &#123; MatrixLog.e(TAG, \"[println] Printer is inValid! x:%s\", x); &#125; &#125; if (isValid) &#123; // x.charAt(0) == '&gt;'时，isBegin为true dispatch(x.charAt(0) == '&gt;', x); &#125; &#125; &#125; 即，入参字符串x以&gt;开头时，isBegin为true。 上面逻辑是自定义LooperPrinter的实现方法。在LooperMonitor初始化时，会向main looper注册一个LooperPrinter：com.tencent.matrix.trace.core.LooperMonitorpublic class LooperMonitor &#123; private LooperPrinter printer; //主线程looper looper = Looper.getMainLooper() // 将前面提到的自定义LooperPrinter塞给主线程looper looper.setMessageLogging(printer = new LooperPrinter(originPrinter));&#125; 上面代码主要是把自定义LooperPrinter塞给主线程looper。对Looper比较熟悉的同学其实已经有眉目了，我们回顾下looper的逻辑：Looper.loop()android.os.Looper.javapublic static void loop() &#123; final Looper me = myLooper(); if (me == null) &#123; throw new RuntimeException(\"No Looper; Looper.prepare() wasn't called on this thread.\"); &#125; final MessageQueue queue = me.mQueue; ... for (;;) &#123; Message msg = queue.next(); // might block if (msg == null) &#123; // No message indicates that the message queue is quitting. return; &#125; // This must be in a local variable, in case a UI event sets the logger // logging对象外部自定义，传入一个自定义Printer实现每一帧的监听计算 final Printer logging = me.mLogging; if (logging != null) &#123; // 每一帧开始时打印的log logging.println(\"&gt;&gt;&gt;&gt;&gt; Dispatching to \" + msg.target + \" \" + msg.callback + \": \" + msg.what); &#125; ... try &#123; // 消息执行 msg.target.dispatchMessage(msg); dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0; &#125; finally &#123; if (traceTag != 0) &#123; Trace.traceEnd(traceTag); &#125; &#125; ... if (logging != null) &#123; // 每一帧结束时打印的log logging.println(\"&lt;&lt;&lt;&lt;&lt; Finished to \" + msg.target + \" \" + msg.callback); &#125; ... &#125; &#125; 很多APM计算帧率都采用了这个逻辑，我在Android图形渲染之Choreographer原理 最后也提到使用“Looper &amp; Printer”计算帧率。 Looper在每个消息消费前后msg.target.dispatchMessage(msg)，会通过一个Printer对象分别打印&gt;&gt;&gt;&gt;&gt; Dispatching to和&lt;&lt;&lt;&lt;&lt; Finished to两个日志。通过Looper.setMessageLogging()可以设置我们自定义的Printer，通过监听主线程方法执行前后的两个日志字符串，就可以计算一帧的耗时。 前面LooperMonitor中就通过Looper.setMessageLogging()将自定义的Printer传给了Looper，所以可以拦截每个消息执行前后的日志。 到这里，每一帧的监听、掉帧逻辑及帧率计算方式就讲完了。 总结：回顾下整体代码的执行过程： Looper.loop() //主线程消息执行也是looper机制 LooperMonitor.LooperPrinter.println() //消息执行前后会打印两个日志 LooperMonitor.dispatch() //拦截到两个日志后进行分发 UIThreadMonitor.dispatchBegin()/dispatchEnd() //记录相关时间节点，分发每一帧执行前后的回调方法 FrameTracer.doFrame() FrameTracer.notifyListener() TestFpsActivity.IDoFrameListener.doFrameSync()/doFrameAsync() //业务侧获取帧率回调总体来说，帧率检测使用了“Looper &amp; Printer”方式。Printer的日志字符串对应主线程每一帧方法执行的开始和结束，通过给主线程Looper设置自定义Printer，即可拦截日志。根据日志内容即可得知每一帧执行的前后节点，进而记录每一帧的开始、结束时间戳，从而可以计算每一帧的耗时、帧率、掉帧等核心指标。 ANR检测ANR检测的主要实现在AnrTracer。 demo中，将TestTraceMainActivity.testANR()内部执行耗时改大一点（大于5000ms），比如改到7800，就能看到AS中输出如下ANR警告log： 看下AnrTracer如何统计ANR，收集上述log信息：AnrTracer：com.tencent.matrix.trace.tracer.AnrTracer@Override public void dispatchBegin(long beginMs, long cpuBeginMs, long token) &#123; super.dispatchBegin(beginMs, cpuBeginMs, token); // 构造AnrTask anrTask = new AnrHandleTask(AppMethodBeat.getInstance().maskIndex(\"AnrTracer#dispatchBegin\"), token); // 延迟5s发消息，Constants.DEFAULT_ANR = 5 * 1000 // token是方法开始执行的时间 // (SystemClock.uptimeMillis() - token)：校正方法的开始时间 anrHandler.postDelayed(anrTask, Constants.DEFAULT_ANR - (SystemClock.uptimeMillis() - token)); &#125; @Override public void dispatchEnd(long beginMs, long cpuBeginMs, long endMs, long cpuEndMs, long token, boolean isBelongFrame) &#123; super.dispatchEnd(beginMs, cpuBeginMs, endMs, cpuEndMs, token, isBelongFrame); // 移除anrTask if (null != anrTask) &#123; anrTask.getBeginRecord().release(); anrHandler.removeCallbacks(anrTask); &#125; &#125; 前面讲FrameTracer时提到过，每一帧执行前后分别回调Tracer.dispatchBegin()和Tracer.dispatchEnd()。 上面代码在dispatchBegin()内部发送了一个延迟消息执行AnrTask，延迟时间约为5s（Constants.DEFAULT_ANR = 5 * 1000），在dispatchEnd()移除对应的任务。所以，如果主线程一帧执行任务超过5s，AnrTask就会执行。 要注意的一点是，ANR log中，may be happen ANR(5007ms)!，这里的5007ms时间并不是一帧任务的耗时（因为我们把测试方法耗时改成了7800ms），而是AnrTracer中AnrTask的消息延迟时间。 AnrTask：看下AnrTask的逻辑：com.tencent.matrix.trace.tracer.AnrTracer.AnrHandleTask@Overridepublic void run() &#123; long curTime = SystemClock.uptimeMillis(); boolean isForeground = isForeground(); // process 进程信息 int[] processStat = Utils.getProcessPriority(Process.myPid()); long[] data = AppMethodBeat.getInstance().copyData(beginRecord); beginRecord.release(); // 业务场景，FrameTracer中提到过 String scene = AppMethodBeat.getVisibleScene(); // memory 内存信息，其中VmSize从“/proc/&#123;PID&#125;/status”文件中获取 long[] memoryInfo = dumpMemory(); // Thread state Thread.State status = Looper.getMainLooper().getThread().getState(); // 线程调用堆栈 StackTraceElement[] stackTrace = Looper.getMainLooper().getThread().getStackTrace(); // 堆栈裁剪 String dumpStack = Utils.getStack(stackTrace, \"|*\\t\\t\", 12); // frame UIThreadMonitor monitor = UIThreadMonitor.getMonitor(); // 获取input/animation/traversal三类任务耗时 long inputCost = monitor.getQueueCost(UIThreadMonitor.CALLBACK_INPUT, token); long animationCost = monitor.getQueueCost(UIThreadMonitor.CALLBACK_ANIMATION, token); long traversalCost = monitor.getQueueCost(UIThreadMonitor.CALLBACK_TRAVERSAL, token); // trace ... StringBuilder reportBuilder = new StringBuilder(); StringBuilder logcatBuilder = new StringBuilder(); // 获取ANR时长 long stackCost = Math.max(Constants.DEFAULT_ANR, TraceDataUtils.stackToString(stack, reportBuilder, logcatBuilder)); // stackKey String stackKey = TraceDataUtils.getTreeKey(stack, stackCost); // 打印ANR日志 MatrixLog.w(TAG, \"%s \\npostTime:%s curTime:%s\", printAnr(scene, processStat, memoryInfo, status, logcatBuilder, isForeground, stack.size(), stackKey, dumpStack, inputCost, animationCost, traversalCost, stackCost), token, curTime); // for logcat if (stackCost &gt;= Constants.DEFAULT_ANR_INVALID) &#123; MatrixLog.w(TAG, \"The checked anr task was not executed on time. \" + \"The possible reason is that the current process has a low priority. just pass this report\"); return; &#125; // report 启动IssuesListActivity页面，展示ANR信息 ...&#125; 主要内容都加了注释，可以参考下。 总结：ANR的检测逻辑：在主线程一帧任务开始前发送（5s）的延迟消息，任务结束时移除该消息。如果主线程一帧任务执行时间超过了消息的延迟时间（认为这一帧导致了ANR），延迟消息将会执行，触发ANR信息收集任务 延迟消息（AnrTask）在异步线程执行，收集进程、调用堆栈、内存使用、trace信息，后续将信息log出来，并启动IssuesListActivity展示ANR结果。 慢函数检测将TestTraceMainActivity.testANR()实现耗时改成7800ms，AS会输出如下慢函数log。从log中可以看出发生了Jankiness，方法耗时7804ms，和我们的修改基本吻合。 下面看下慢函数的实现逻辑，主要代码在EvilMethodTracer。EvilMethodTracer：com.tencent.matrix.trace.tracer.EvilMethodTracer@Override public void dispatchEnd(long beginMs, long cpuBeginMs, long endMs, long cpuEndMs, long token, boolean isBelongFrame) &#123; super.dispatchEnd(beginMs, cpuBeginMs, endMs, cpuEndMs, token, isBelongFrame); long start = config.isDevEnv() ? System.currentTimeMillis() : 0; try &#123; long dispatchCost = endMs - beginMs; // 一帧耗时超过evilThresholdMs（默认700ms），执行慢函数计算逻辑 if (dispatchCost &gt;= evilThresholdMs) &#123; long[] data = AppMethodBeat.getInstance().copyData(indexRecord); long[] queueCosts = new long[3]; System.arraycopy(queueTypeCosts, 0, queueCosts, 0, 3); String scene = AppMethodBeat.getVisibleScene(); // 异步线程执行AnalyseTask MatrixHandlerThread.getDefaultHandler().post(new AnalyseTask(isForeground(), scene, data, queueCosts, cpuEndMs - cpuBeginMs, endMs - beginMs, endMs)); &#125; &#125; finally &#123; ... &#125; &#125; 主要逻辑在dispatchEnd()里面。从上面代码可以看出，当主线程一帧内耗时超过evilThresholdMs（默认700ms，可以通过TraceConfig配置），执行慢函数的警告，打印上面提到的log。 其中，慢函数的耗时，就是上面代码中的endMs - beginMs，这个逻辑在“帧率检测 - UIThreadMonitor.dispatchEnd()”中有具体讲到。 具体慢函数打印的log逻辑如下：AnalyseTask:com.tencent.matrix.trace.tracer.EvilMethodTracer.AnalyseTaskprivate class AnalyseTask implements Runnable &#123; ... void analyse() &#123; // process 进程信息 int[] processStat = Utils.getProcessPriority(Process.myPid()); String usage = Utils.calculateCpuUsage(cpuCost, cost); LinkedList&lt;MethodItem&gt; stack = new LinkedList(); ... StringBuilder reportBuilder = new StringBuilder(); StringBuilder logcatBuilder = new StringBuilder(); long stackCost = Math.max(cost, TraceDataUtils.stackToString(stack, reportBuilder, logcatBuilder)); String stackKey = TraceDataUtils.getTreeKey(stack, stackCost); // 和AnrTracer一样，打印log，启动IssuesListActivity页面，展示EvilMethod信息 MatrixLog.w(TAG, \"%s\", printEvil(scene, processStat, isForeground, logcatBuilder, stack.size(), stackKey, usage, queueCost[0], queueCost[1], queueCost[2], cost)); // for logcat ... &#125; &#125; 其中，AnalyseTask的逻辑和AnrTask类似，只是log中的部分内容不一样，就不具体展开了。 总结：慢函数的检测逻辑比较简单，在主线程一帧执行结束时，判断帧耗时是否大于预先设置的慢函数阈值，超过该阈值，即认为慢函数发生。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/09/26/matrix-trace-canary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ConstraintLayout","slug":"constraintlayout","permalink":"http://agehua.github.io/tags/constraintlayout/"}]},{"title":"ConstraintLayout 高级用法介绍","slug":"constraintlayout-intro","date":"2023-02-09T16:00:00.000Z","updated":"2024-12-05T09:41:25.286Z","comments":true,"path":"2023/02/10/constraintlayout-intro/","link":"","permalink":"http://agehua.github.io/2023/02/10/constraintlayout-intro/","excerpt":"本文介绍了部分ConstraintLayout 2.0新增的api，同时介绍了一下ConstraintLayout中不太常用的方法，方便以后查阅。","text":"本文介绍了部分ConstraintLayout 2.0新增的api，同时介绍了一下ConstraintLayout中不太常用的方法，方便以后查阅。 边距边距与平常使用并无太大区别，但需要先确定view的位置，边距才会生效。如： GONE MarginConstraintLayout提供了特殊的goneMargin属性，在目标View隐藏时，属性生效。有如下属性： layout_goneMarginStart layout_goneMarginEnd layout_goneMarginLeft layout_goneMarginTop layout_goneMarginRight layout_goneMarginBottom 居中在RelativeLayout居中，通常是使用以下三个属性： layout_centerInParent 中间居中 layout_centerHorizontal 水平居中 layout_centerVertical 垂直居中 而在ConstraintLayout居中则采用左右上下边来约束居中。 水平居中 layout_constraintLeft_toLeftOf &amp; layout_constraintRight_toRightOf 垂直居中 layout_constraintTop_toTopOf &amp; layout_constraintBottom_toBottomOf 中间居中 水平居中 &amp; 垂直居中 偏移 layout_constraintHorizontal_bias 水平偏移 layout_constraintVertical_bias 垂直偏移 两个属性的取值范围在0-1。在水平偏移中，0表示最左，1表示最右；在垂直偏移，0表示最上，1表示最下；0.5表示中间 角度定位（圆形定位）角度定位指的是可以用一个角度和一个距离来约束两个空间的中心。举个例子：&lt;TextView android:id=\"@+id/TextView1\" android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" /&gt;&lt;TextView android:id=\"@+id/TextView2\" android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" app:layout_constraintCircle=\"@+id/TextView1\" app:layout_constraintCircleAngle=\"120\" app:layout_constraintCircleRadius=\"150dp\" /&gt; 上面例子中的TextView2用到了3个属性： app:layout_constraintCircle=&quot;@+id/TextView1&quot; app:layout_constraintCircleAngle=&quot;120&quot;（角度） app:layout_constraintCircleRadius=&quot;150dp&quot;（距离） 指的是TextView2的中心在TextView1的中心的120度，距离为150dp 有ConstraintLayout实践经验的朋友应该知道margin设置负值在ConstraintLayout是没有效果的.可以通过Space来间接实现view重叠效果。 /** * Space is a lightweight View subclass that may be used to create gaps between components * in general purpose layouts. */public final class Space extends View &#123; ConstraintLayout中的控件尺寸约束在ConstraintLayout中控件可以三种方式来设置其尺寸约束。 指定具体的值。如123dp 使用值 WRAP_CONTENT,内容自适配。 设为 0dp ,即 MATCH_CONSTRAINT，扩充可用空间。 这种情况会根据约束情况重新计算控件大小，一般会测量2次 在ConstraintLayout中，不推荐使用MATCH_PARENT，而是推荐使用MATCH_CONSTRAINT(0dp),它们的行为是类似的 控件设为MATCH_CONSTRAINT时，控件的大小会扩展所有可用空间，可以通过以下属性改变控件的行为。 layout_constraintWidth_min 最小宽度 layout_constraintHeight_min 最小高度 layout_constraintWidth_max 最大宽度 layout_constraintHeight_max 最大高度 layout_constraintWidth_percent 宽度占parent的百分比 layout_constraintHeight_percent 高度占parent的百分比 比例约束控件的宽高比，要求是宽或高至少一个设为0dp，然后设置属性layout_constraintDimensionRatio即可。&lt;TextView android:text=\"Hello\" app:layout_constraintDimensionRatio=\"3:1\" android:layout_width=\"0dp\" android:layout_height=\"100dp\" /&gt; 这里设置宽高比为3:1,高度为100dp,那么宽度将为300dp。 也可以在比例前加W,H表示是宽高比还是高宽比，比如：app:layout_constraintDimensionRatio=\"H,16:9\" // 高宽比16:9 链链在水平或者垂直方向提供一组类似行为，多个元素在水平或垂直方向想相互约束，并且最终与parent约束，才能形成一条链。 横向链最左边第一个控件，垂直链最顶边第一个控件称为链头，可以通过下面两个属性链头统一定制链的样式。layout_constraintHorizontal_chainStyle //水平方向链式layout_constraintVertical_chainStyle //垂直方向链式 它两的值可以是 CHAIN_SPREAD 展开样式（默认） Weighted chain 在CHAIN_SPREAD样式，部分控件设置了MATCH_CONSTRAINT，那他们将扩展可用空间。 配合 layout_constraintHorizontal_weight=”1” 使用 CHAIN_SPREAD_INSIDE 展开样式，但两端不展开 CHAIN_PACKED 抱团(打包)样式，控件抱团一起。通过偏移bias，可以改变packed元素的位置。 工具类Guideline（参考线）参考线实际上不会在界面进行显示，只是方便在ConstraintLayout布局view时候做一个参考。通过设置Guideline的属性orientation来表示是水平方向还是垂直方向的参考线，对应值为vertical和horizontal。可以通过三种方式来定位Guideline位置。 layout_constraintGuide_begin 从左边或顶部指定具体的距离 layout_constraintGuide_end 从右边或底部指定具体的距离 layout_constraintGuide_percent 从宽度或高度的百分比来指定具体距离 Barrier（栅栏）Barrier有点类似Guideline，但Barrier会根据所有引用的控件尺寸的变化重新定位。例如经典的登录界面，右边的EditText总是希望与左右所有TextView的最长边缘靠齐。如果两个TextView其中一个变得更长，EditText的位置都会跟这变化，这比使用RelativeLayout灵活很多。 &lt;android.support.constraint.ConstraintLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" xmlns:app=\"http://schemas.android.com/apk/res-auto\" android:layout_width=\"match_parent\" android:layout_height=\"match_parent\"&gt; &lt;android.support.constraint.Barrier android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" app:barrierDirection=\"right\" android:id=\"@+id/barrier\" app:constraint_referenced_ids=\"tvPhone,tvPassword\" /&gt; &lt;TextView android:layout_width=\"wrap_content\" android:text=\"手机号码\" android:id=\"@+id/tvPhone\" android:gravity=\"center_vertical|left\" android:padding=\"10dp\" android:layout_height=\"50dp\"/&gt; &lt;TextView android:layout_width=\"wrap_content\" android:text=\"密码\" android:padding=\"10dp\" android:gravity=\"center_vertical|left\" android:id=\"@+id/tvPassword\" app:layout_constraintTop_toBottomOf=\"@id/tvPhone\" android:layout_height=\"wrap_content\"/&gt; &lt;EditText android:layout_width=\"wrap_content\" android:hint=\"输入手机号码\" android:id=\"@+id/etPassword\" app:layout_constraintLeft_toLeftOf=\"@id/barrier\" android:layout_height=\"wrap_content\"/&gt; &lt;EditText android:layout_width=\"wrap_content\" android:hint=\"输入密码\" app:layout_constraintTop_toBottomOf=\"@id/etPassword\" app:layout_constraintLeft_toLeftOf=\"@id/barrier\" android:layout_height=\"wrap_content\"/&gt;&lt;/android.support.constraint.ConstraintLayout&gt; app:barrierDirection所引用控件对齐的位置，可设置的值有：bottom、end、left、right、start、top.constraint_referenced_ids为所引用的控件，例如这里的tvPhone,tvPasswrod。 Group（组）用来控制一组view的可见性，如果view被多个Group控制，则以最后的Group定义的可见性为主。 &lt;androidx.constraintlayout.widget.Group android:layout_height=\"wrap_content\" android:layout_width=\"wrap_content\" android:visibility=\"visible\" app:constraint_referenced_ids=\"textView3,textView2,textView1\" /&gt; Placeholder（占位符）一个view占位的占位符，当指定Placeholder的content属性为另一个view的id时，该view会移动到Placeholder的位置。&lt;androidx.constraintlayout.widget.Placeholder android:id=\"@+id/place_holder\" android:layout_height=\"60dp\" android:layout_width=\"100dp\" app:layout_constraintEnd_toEndOf=\"parent\" app:layout_constraintTop_toTopOf=\"@+id/guideline2\" app:content=\"@id/textView3\"/&gt; 也可以通过代码调用的方式移动view到PlaceHolder，如下：placeholder.setContentId(R.id.textView3); Optimizer当我们使用 MATCH_CONSTRAINT 时，ConstraintLayout 将对控件进行 2 次测量，ConstraintLayout在1.1中可以通过设置 layout_optimizationLevel 进行优化，可设置的值有： none：无优化 standard：仅优化直接约束和屏障约束（默认） direct：优化直接约束 barrier：优化屏障约束 chain：优化链约束 dimensions：优化尺寸测量 Layer把一些控件组合在一起，当作一个图层，该图层自动计算边界，也是View的子类，但是功能不是完整的，Layer并不会增加 view 的层级。 支持的操作： 设置背景色 支持elevation属性 设置可见性 支持补间动画（alpha 是layer动，scale,rotation,transaction是其中的每个控件同时动） 多个图层同时包含同一个控件 图层本身支持事 支持padding、不支持margin、不支持大小 自定义 Helper为什么需要自定义? 保持 view 的层级不变，不像 ViewGroup 会增加 view 的层级 封装一些特定的行为，方便复用 一个 View 可以被多个 Helper引用，可以很方便组合出一些复杂的效果出来 如何自定义? public abstract class ConstraintHelper extends View public abstract class VirtualLayout extends ConstraintHelper public class Flow extends VirtualLayout Helper持有 view 的引用，所以可以获取 view (getViews)然后操作 view。 提供了 onLayout 前后的 callback（updatePreLayout/updatePreLayout） Helper 继承了 view，所以Helper本身也是 view Constraintlayout 2.0新增/少见的用法Flow 流式布局&lt;androidx.constraintlayout.helper.widget.Flow android:id=\"@+id/flow_test\" android:layout_height=\"wrap_content\" android:layout_width=\"wrap_content\" app:constraint_referenced_ids=\"tvA,tvB,tvC,tvD,tvE,tvF,tvG\" app:flow_firstHorizontalStyle=\"spread\" app:flow_horizontalGap=\"30dp\" app:flow_lastHorizontalStyle=\"packed\" app:flow_maxElementsWrap=\"4\" app:flow_verticalGap=\"30dp\" app:flow_wrapMode=\"chain\" app:layout_constraintEnd_toEndOf=\"parent\" app:layout_constraintStart_toStartOf=\"parent\" ... flow_wrapMode属性一共有四种值： none: 所有引用的view形成一条链，水平居中，超出屏幕两侧的view不可见. chain: 所引用的View形成一条链，超出部分会自动换行，同行的View会平分宽度，中间排列。 aligned: 所引用的View形成一条链，超出部分会自动换行，同行的View会优先左侧排列。 chain2: 所引用的View形成一条链，超出部分会自动换行，同行的View会平分宽度。但会导致app:flow_maxElementsWrap 属性失效 其他属性： app:flow_maxElementsWrap=&quot;4&quot; 一行几个元素 app:flow_verticalGap=&quot;10dp&quot; 竖直间距 app:flow_horizontalGap=&quot;10dp&quot; 横向间距 android:orientation=&quot;horizontal&quot;水平方向的流式还是竖直方向的流式 app:flow_verticalAlign =&quot;top&quot; 值有top，bottom，center，baseline。每一行元素的对齐方式 app:flow_horizontalStyle = &quot;spread | spread_inside | packed&quot; 当wrapMode为chain或ALIGNED时生效 app:flow_horizontalBias = &quot;float&quot; low的bias偏移，只在style为packed时生效 ImageFilterViewImageFilterView继承自ImageView，可以轻松实现圆角、图片色彩调节等&lt;androidx.constraintlayout.utils.widget.ImageFilterView android:id=\"@+id/imageFilterView\" android:layout_height=\"50dp\" android:layout_width=\"50dp\" app:altSrc=\"@mipmap/ic_launcher\" app:brightness=\"1\" app:contrast=\"4\" app:crossfade=\"0.5\" app:round=\"20dp\" app:roundPercent=\"1\" app:srcCompat=\"@drawable/test_logo\" app:warmth=\"1\" /&gt; roundPercent取值在0-1，由正方形向圆形过渡。 但是以下情况可能圆角会失效： layout_width或layout_height为wrapcontent时，圆角失效。或者设置了layout_constraintHorizontal_weight，且layout_width为0dp时，圆角失效 其他属性： app:altSrc=&quot;@mipmap/ic_launcher&quot; altSrc和src属性是一样的概念，altSrc提供的资源将会和src提供的资源通过crossfade属性形成交叉淡化效果。默认情况下,crossfade=0，altSrc所引用的资源不可见,取值在0-1 warmth 色温：1=neutral自然, 2=warm暖色, 0.5=cold冷色 brightness 亮度：0 = black暗色, 1 = original原始, 2 = twice as bright两倍亮度； saturation 饱和度：0 = grayscale灰色, 1 = original原始, 2 = hyper saturated超饱和； contrast 对比度：1 = unchanged原始, 0 = gray暗淡, 2 = high contrast高对比; ImageFilterButtonImageFilterView与ImageFilterButton的属性一模一样，只是它两继承的父类不一样，一些操作也就不一样。ImageFilterButton继承自AppCompatImageButton, 也就是ImageButtion。而ImageFilterView继承自ImageView。 public class ImageFilterButton extends androidx.appcompat.widget.AppCompatImageButton &#123; //...public class ImageFilterView extends androidx.appcompat.widget.AppCompatImageView &#123; //... MockViewMockView能简单的帮助构建UI界面，通过对角线形成的矩形+标签。例如：&lt;androidx.constraintlayout.utils.widget.MockView android:id=\"@+id/first\" android:layout_width=\"100dp\" android:layout_height=\"100dp\" app:layout_constraintLeft_toLeftOf=\"parent\" app:layout_constraintTop_toTopOf=\"parent\" /&gt; 关键帧动画在 ConstraintLayout 中，可以使用 ConstraintSet 和 TransitionManager 为尺寸和位置元素的变化添加动画效果。 重要提示：ConstraintSet 动画仅为子元素的尺寸和位置添加动画效果。它们不会为其他属性（例如颜色）添加动画效果。 最后，ConstraintLayout 2.0还增加了ConstraintProperties类用于通过api(代码)更新ConstraintLayout子视图，ConstraintsChangedListener监听，具体可以参考Api。 参考https://juejin.cn/post/6949186887609221133 https://juejin.cn/post/7071165641973530638 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/02/10/constraintlayout-intro/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ConstraintLayout","slug":"constraintlayout","permalink":"http://agehua.github.io/tags/constraintlayout/"}]},{"title":"ANR 触发原理","slug":"anr-trigger-principle","date":"2022-08-07T16:00:00.000Z","updated":"2024-12-05T09:41:25.320Z","comments":true,"path":"2022/08/08/anr-trigger-principle/","link":"","permalink":"http://agehua.github.io/2022/08/08/anr-trigger-principle/","excerpt":"Input超时机制input的超时检测机制跟service、broadcast、provider截然不同，为了更好的理解input过程先来介绍两个重要线程的相关工作：","text":"Input超时机制input的超时检测机制跟service、broadcast、provider截然不同，为了更好的理解input过程先来介绍两个重要线程的相关工作： InputReader线程负责通过EventHub(监听目录/dev/input)读取输入事件，一旦监听到输入事件则放入到InputDispatcher的mInBoundQueue队列，并通知其处理该事件； InputDispatcher线程负责将接收到的输入事件分发给目标应用窗口，分发过程使用到3个事件队列： mInBoundQueue用于记录InputReader发送过来的输入事件； outBoundQueue用于记录即将分发给目标应用窗口的输入事件； waitQueue用于记录已分发给目标应用，且应用尚未处理完成的输入事件； input的超时机制并非时间到了一定就会爆炸，而是处理后续上报事件的过程才会去检测是否该爆炸，所以更像是扫雷的过程，具体如下图所示: 1.InputReader线程通过EventHub监听底层上报的输入事件，一旦收到输入事件则将其放至mInBoundQueue队列，并唤醒InputDispatcher线程 2.InputDispatcher开始分发输入事件，设置埋雷的起点时间。先检测是否有正在处理的事件(mPendingEvent)，如果没有则取出mInBoundQueue队头的事件，并将其赋值给mPendingEvent，且重置ANR的timeout；否则不会从mInBoundQueue中取出事件，也不会重置timeout。然后检查窗口是否就绪(checkWindowReadyForMoreInputLocked)，满足以下任一情况，则会进入扫雷状态(检测前一个正在处理的事件是否超时)，终止本轮事件分发，否则继续执行步骤3。当应用窗口准备就绪，则将mPendingEvent转移到outBoundQueue队列 对于按键类型的输入事件，则outboundQueue或者waitQueue不为空， 对于非按键的输入事件，则waitQueue不为空，且等待队头时间超时500ms 3.当outBoundQueue不为空，且应用管道对端连接状态正常，则将数据从outboundQueue中取出事件，放入waitQueue队列 4.InputDispatcher通过socket告知目标应用所在进程可以准备开始干活 5.App在初始化时默认已创建跟中控系统双向通信的socketpair，此时App的包工头(main线程)收到输入事件后，会层层转发到目标窗口来处理 6.包工头完成工作后，会通过socket向中控系统汇报工作完成，则中控系统会将该事件从waitQueue队列中移除。 input超时机制为什么是扫雷，而非定时爆炸呢？是由于对于input来说即便某次事件执行时间超过timeout时长，只要用户后续在没有再生成输入事件，则不会触发ANR。 这里的扫雷是指当前输入系统中正在处理着某个耗时事件的前提下，后续的每一次input事件都会检测前一个正在处理的事件是否超时（进入扫雷状态），检测当前的时间距离上次输入事件分发时间点是否超过timeout时长。如果前一个输入事件，则会重置ANR的timeout，从而不会爆炸。 ANR处理流程不管是啥 anr ，最终都会调用到 ProcessRecord 的 appNotResponding 方法，下面来看看这个方法里面具体都做了啥： 当发生ANR时, 会按顺序依次执行: 输出ANR Reason信息到EventLog. 也就是说ANR触发的时间点最接近的就是EventLog中输出的am_anr信息; 收集并输出重要进程列表中的各个线程的traces信息，该方法较耗时; 【见小节2】 输出当前各个进程的CPU使用情况以及CPU负载情况; 将traces文件和 CPU使用情况信息保存到dropbox，即data/system/dropbox目录 根据进程类型,来决定直接后台杀掉,还是弹框告知用户. ANR输出重要进程的traces信息，这些进程包含: firstPids队列：第一个是ANR进程，第二个是system_server，剩余是所有persistent进程； Native队列：是指/system/bin/目录的mediaserver,sdcard 以及surfaceflinger进程； lastPids队列: 是指mLruProcesses中的不属于firstPids的所有进程。 Ref深入理解 Android ANR 触发原理以及信息收集过程 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/08/08/anr-trigger-principle/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANR","slug":"anr","permalink":"http://agehua.github.io/tags/anr/"}]},{"title":"RecyclerView inflate优化","slug":"async-inflate-strategy","date":"2022-07-20T16:00:00.000Z","updated":"2024-12-05T09:41:25.316Z","comments":true,"path":"2022/07/21/async-inflate-strategy/","link":"","permalink":"http://agehua.github.io/2022/07/21/async-inflate-strategy/","excerpt":"背景本文是在工作中对App启动耗时中页面展现耗时的一个优化，特意记录优化方案和遇到的问题。主要是针对首页Recyclerview itemview的一个优化，减少itemview inflate耗时，从而减少onCreateViewHolder耗时，最终减少页面展现的耗时","text":"背景本文是在工作中对App启动耗时中页面展现耗时的一个优化，特意记录优化方案和遇到的问题。主要是针对首页Recyclerview itemview的一个优化，减少itemview inflate耗时，从而减少onCreateViewHolder耗时，最终减少页面展现的耗时 思路关于view的异步inflate，官方给出了一个方案：AsyncLayoutInflater。对其原理感兴趣的朋友可以看下这篇文章：https://juejin.cn/post/6844904170508681224 关于如何减少ViewHolder的inflate时间，基于官方的方法，我做了两套方案： 1.异步初始化viewholder和 2.提前初始化viewholderprivate var sUseAsyncInflate = falseprivate var sUseAheadInflate = falsefun init(application: Application?) &#123; if (Build.VERSION.SDK_INT &lt; Build.VERSION_CODES.Q) &#123; // android 10 // 低端设备使用提前初始化viewholder aheadInflateView(application, sFirstScreenTypes) sUseAheadInflate = true// sUseAsyncInflate = true // 可以都开启，但是低端设备也异步会导致主线程事务增多 &#125; else &#123; // 高端设备异步初始化viewholder// aheadInflateView(application, sFirstScreenTypes) // 提前初始化多个，可能未初始化完首页就已经展示了 sUseAsyncInflate = true &#125;&#125; 一、提前初始化viewholder提前初始化比较简单，只需要在首页展示之前初始化好对应的viewholder，我的方案细节如下： 在Application里仅异步初始化首屏viewholder AsyncLayoutInflater异步初始化需要指定一个ViewParent，这种场景是Recyclerview Recyclerview必须指定一个LayoutManager，这里和首页一样，使用的LinearLayoutManager 异步初始化完成后，需要移除itemview的parent private var sFirstScreenTypes: IntArray = intArrayOf( // 首屏对应的viewholder的type CommonConstants.card_show_subtype_13, CommonConstants.card_show_subtype_551, CommonConstants.card_show_subtype_14)/*** 提前初始化首屏 view*/private fun aheadInflateView(application: Context?, viewTypes: IntArray) &#123; sFirstScreenTypes = viewTypes sAsyncLayoutInflater = MyAsyncLayoutInflater(application!!) sFakeParent = RecyclerView(application) sFakeParent!!.layoutManager = LinearLayoutManager(application) for (viewType in viewTypes) &#123; val model = ViewHolderTypeManager.transformViewHolder(viewType) // model是一个自定义类，绑定了viewtype和layoutid var resid = model.layoutId if (resid &lt; 0) &#123; resid = CommonGlobalContext.getAppContext().resources.getIdentifier( model.layout, \"layout\", CommonGlobalContext.getAppContext().packageName ) &#125; sAsyncLayoutInflater!!.inflate( resid, sFakeParent, viewType, null ) &#123; view, resid, parent, viewType, fakeViewHolder -&gt; if (null != view.parent) &#123; // 移除itemview的parent (view.parent as ViewGroup).removeView(view) &#125; DebugLog.d(TAG, \"aheadInflateView 完成 $viewType\") saveAsyncInflateView(application, viewType, view) // 保存初始化好的viewholder，方便首页使用 &#125; &#125;&#125;/** * 根据type，提前异步初始化一个view*/private fun saveAsyncInflateView(context: Context, type: Int, view: View?): Int &#123; if (!typeToContainer.containsKey(type)) &#123; val container = ViewHolderContainer(context, type, mReferenceQueue) container.position = -1 container.isFake = false container.view = view typeToContainer[type] = container &#125; else &#123; // TODO 后续处理提前初始化一个type多个view的情况 &#125; return -1&#125; ViewHolderContainer 是一个链表类，内部有一个next指针，所以typeToContainer其实是一个type对应一个链表private val typeToContainer: MutableMap&lt;Int, ViewHolderContainer?&gt; = HashMap() // map(viewtype, container)作为存储容器 使用的时候直接在onCreateViewHolder中判断即可 二、异步初始化viewholder异步初始化稍微复杂一点，思路是需要先绑定一个fake viewholder，等 real viewholder infalte完成在替换为real viewholder 基本原理如下： 1.区分占位viewholer和原viewholder因为是异步的，在real view没有inflate完成时，需要展示一个占位的view。占位view的viewtype = 原viewtype * (-1) 2.原viewholder inflate完成后，替换掉占位viewholer占位view在原本view inflate完成后，需要被替换，需要保存占位view的位置，然后更新为 real view 实现方案： 1.不缓存占位（fake）viewholder // 此处 type 为负数mRecyclerView.getRecycledViewPool().setMaxRecycledViews(type, 0); // RecycledViewPool不缓存 负数类型的viewholder 2.因为不缓存，所以在调用 notifyItemChanged(int position) 时会重新走到 onCreateViewHolder 简单说下 Recyclerview 分为四级缓存，1.mChangedScrap 2.mAttachedScrap、mCachedViews 3.mViewCacheExtension 4.mRecyclerPool 更多Recyclerview缓存相关的细节分析，请看我的这篇文章：RecyclerView 缓存机制 下面贴一下大概的实现方案： @Overridepublic int getItemViewType(int position) &#123; int type = ViewHolderTypeManager.transformViewHolder((Card) mDataList.get(position)).getType(); // 先拿到正确的type，判断该type是否有开启了异步初始化，然后判断是否是fake if (mUseAsyncInflate &amp;&amp; AsyncInflateHelper.INSTANCE.isFake(mContext, type, originPos, false)) &#123;// 这里并未绑定type和position type *=-1; mRecyclerView.getRecycledViewPool().setMaxRecycledViews(type, 0); // recycledPool 不缓存 fake的 &#125;&#125;// public RecyclerView.ViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) &#123; boolean useFake = mUseAsyncInflate; if(useFake) &#123; View view = AsyncInflateHelper.INSTANCE.getContainerForType(viewType); if (!isFake) &#123; if (null != view) &#123; DebugLog.d(\"ConorLee\", \"use async inflate viewtype is \" + viewType); tmpViewHolder = (BaseNewViewHolder) getViewHolder(view, model.getClassName()); &#125; else &#123; useFake = false; &#125; &#125; else &#123; View viewGroup = LayoutInflater.from(mContext).inflate(R.layout.common_album_item_default, parent, false); tmpViewHolder = new EmptyViewHolder(mContext, viewGroup); DebugLog.d(\"ConorLee\", \"fake onCreate is \"+ viewType); int layoutId = model.getLayoutId(); if (layoutId &lt; 0) &#123; layoutId = CommonGlobalContext.getAppContext().getResources().getIdentifier(model.getLayout(), \"layout\", CommonGlobalContext.getAppContext().getPackageName()); &#125; MyAsyncLayoutInflater asyncLayoutInflater = new MyAsyncLayoutInflater(mContext); asyncLayoutInflater.inflate(layoutId, parent, viewType, tmpViewHolder, new MyAsyncLayoutInflater.OnInflateFinishedListener() &#123; @Override public void onInflateFinished(@NonNull View view, int resid, @Nullable ViewGroup parent, int viewType, BaseNewViewHolder fakeViewHolder) &#123; DebugLog.d(\"ConorLee\", \"async inflate complete \"+ viewType); // inflate完成 int pos = AsyncInflateHelper.INSTANCE.updatePosAndView(viewType, view); notifyItemChanged(pos); // 这里pos是在onBindViewHolder()方法里绑定好了 if (pos == -1) &#123; DebugLog.d(\"ConorLee\", \"async inflate error \"+ viewType); &#125; &#125; &#125;); &#125; &#125;&#125; 在onBindViewHolder()方法中如果发现holder是fake，那么可以直接return，显著减少onBind时间public void onBindViewHolder(@NonNull RecyclerView.ViewHolder holder, int position, @NonNull List&lt;Object&gt; payloads) &#123; int viewHolderType = holder.getItemViewType(); if (mUseAsyncInflate &amp;&amp; viewHolderType &lt; 0) &#123; AsyncInflateHelper.INSTANCE.isFake(mContext, viewHolderType, position, true); // 这里绑定绑定type和position return; &#125; // ...&#125; 这里再说明一下： fakeviewholder是在onCreateViewHolder中创建，并且在onBindViewHolder和position绑定，绑定之后由前面的typeToContainer类保存。 异步初始化完成后，根据type在typeToContainer中找到第一个fakeviewholder，拿到位置并更新 跨页面缓存相同type的ViewHolder，如何回收？可以参考LeakCanary检测Activity是否泄漏的方法，检测viewholder的View或Context是否被回收。基本原理如下： 用弱引用（WeakReference）包裹实体类ViewHolderContainer，然后给这个弱引用绑定一个引用队列。 如果弱引用的内容被回收，该弱引用会被加入到引用队列。然后某个时间点遍历引用队列，回收ViewHolderContainer 因为Activity生命周期的原因，如果在onDestroy里立刻去遍历引用队列，可能还未回收，所以onDestroy方法不是一个完美的时间点 建议可以在上一个页面的onResume方法中延迟去做 清除的方法大概如下： fun clearViewContainer() &#123; var needLoop = true while (needLoop) &#123; val ref = mReferenceQueue.poll() as KeyedWeakReference&lt;*&gt;? ref?.let &#123; var head = typeToContainer[ref.viewHolderType] var prev: ViewHolderContainer? = null while (head != null) &#123; if (head.mKeyedWeakReference.get() == null) &#123; DebugLog.d(TAG, \"页面退出，回收container type is \" + ref.viewHolderType + \" pos is \" + ref.viewHolderPos) // 移除head节点 if (null == prev) &#123; head = head.next typeToContainer[ref.viewHolderType] = head &#125; else &#123; prev.next = head.next &#125; break &#125; prev = head head = head.next &#125; &#125; ?: let&#123; needLoop = false&#125; &#125;&#125; 结论采用这两种方式，可以显著减少viewholder的onCreateViewHolder和onBindViewHolder这两个方法的耗时，从而页面整体展现可以较以前提高100~200ms 不足： 1.异步初始化完成后，其实应该根据当前列表的firstvisiblepos和lastvisiblepos找到对应的fakeviewholder，这样效率更高。目前为了实现简单，每次异步完成都是遍历列表，拿第一个fakeviewholder，儿没有判断是否可见 2.不支持在viewholder中new Handler(), 因为底层用的官方AsyncLayoutInflater，初始化view在子线程，此时new Handler()会抛出异常 RefView 的异步 Inflate+ 全局缓存：加速你的页面 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/07/21/async-inflate-strategy/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView optimization","slug":"recyclerview-optimization","permalink":"http://agehua.github.io/tags/recyclerview-optimization/"},{"name":"AsyncInflate","slug":"asyncinflate","permalink":"http://agehua.github.io/tags/asyncinflate/"}]},{"title":"SP源码阅读和其导致ANR原因分析","slug":"sp-source-code-analysis","date":"2022-03-27T16:00:00.000Z","updated":"2024-12-05T09:41:25.311Z","comments":true,"path":"2022/03/28/sp-source-code-analysis/","link":"","permalink":"http://agehua.github.io/2022/03/28/sp-source-code-analysis/","excerpt":"背景本文是在看了字节的这篇文章: 剖析 SharedPreference apply 引起的 ANR 问题，发现很多原理不太清楚，特意根据源码总结一下，避免网上的人云亦云","text":"背景本文是在看了字节的这篇文章: 剖析 SharedPreference apply 引起的 ANR 问题，发现很多原理不太清楚，特意根据源码总结一下，避免网上的人云亦云 从如何使用开始我们使用SP，都是通过Context，直接看ContextImpl的具体实现：class ContextImpl extends Context &#123; //静态存储类，缓存所有应用的SP容器,该容器key对应应用名称，value则为每个应用存储所有sp的容器 private static ArrayMap&lt;String, ArrayMap&lt;File, SharedPreferencesImpl&gt;&gt; sSharedPrefsCache; @Override public SharedPreferences getSharedPreferences(String name, int mode) &#123; ...... File file; synchronized (ContextImpl.class) &#123; // 获取锁，然后根据name获取相对应的文件 if (mSharedPrefsPaths == null) &#123; mSharedPrefsPaths = new ArrayMap&lt;&gt;(); &#125; file = mSharedPrefsPaths.get(name); if (file == null) &#123; file = getSharedPreferencesPath(name); mSharedPrefsPaths.put(name, file); &#125; &#125; return getSharedPreferences(file, mode); &#125; @Override public SharedPreferences getSharedPreferences(File file, int mode) &#123; SharedPreferencesImpl sp; synchronized (ContextImpl.class) &#123; // 获取类锁 // 根据packagename从 sSharedPrefsCache 中拿到当前包名的cache final ArrayMap&lt;File, SharedPreferencesImpl&gt; cache = getSharedPreferencesCacheLocked(); sp = cache.get(file); // 得到一个 SharedPreferencesImpl 实例 if (sp == null) &#123; // cache中没有就创建一个 checkMode(mode); if (getApplicationInfo().targetSdkVersion &gt;= android.os.Build.VERSION_CODES.O) &#123; if (isCredentialProtectedStorage() &amp;&amp; !getSystemService(UserManager.class) .isUserUnlockingOrUnlocked(UserHandle.myUserId())) &#123; throw new IllegalStateException(\"SharedPreferences in credential encrypted \" + \"storage are not available until after user is unlocked\"); &#125; &#125; sp = new SharedPreferencesImpl(file, mode); cache.put(file, sp); return sp; &#125; &#125; if ((mode &amp; Context.MODE_MULTI_PROCESS) != 0 || getApplicationInfo().targetSdkVersion &lt; android.os.Build.VERSION_CODES.HONEYCOMB) &#123; // If somebody else (some other process) changed the prefs // file behind our back, we reload it. This has been the // historical (if undocumented) behavior. sp.startReloadIfChangedUnexpectedly(); &#125; return sp; &#125; &#125; ArrayMap 是android framework 中非常常见的容器类，比如 Bundle 中传递的 Key和 Value 都是用ArrayMap来存储的 继续看 SharedPreferencesImpl 是怎么实现保存的 找到具体实现类 SharedPreferencesImplSharedPreferencesImpl 实现了SharedPreferences 接口，其内部类 EditorImpl 也实现 Editor 接口 我们随便找一个EditorImpl类的 putXXX的方法，比如 putBoolean ：// EditorImpl @Override public Editor putBoolean(String key, boolean value) &#123; synchronized (mEditorLock) &#123; // mEditorLock是一个Object对象锁 mModified.put(key, value); // mModified是一个 HashMap，保存暂时修改的值 return this; &#125; &#125; // 为什么要多贴一个 remove方法，继续看下面的commit方法 @Override public Editor remove(String key) &#123; synchronized (mEditorLock) &#123; mModified.put(key, this); return this; &#125; &#125; 从这里也能看到SP的整个实现，各种地方都加了synchronized实现线程安全，应该是线程安全的 Editor调用完putXXX()后，需要调用 commit() 或 apply()来保存提交，我们先看下commit() : // EditorImpl @Override public boolean commit() &#123; long startTime = 0; if (DEBUG) &#123; startTime = System.currentTimeMillis(); &#125; // 将提交的数据保存到内存中 MemoryCommitResult mcr = commitToMemory(); SharedPreferencesImpl.this.enqueueDiskWrite( mcr, null /* sync write on this thread okay */); try &#123; // 调用了CountDownLatch的 await 方法，等待写入文件完成，会阻塞当前线程 mcr.writtenToDiskLatch.await(); &#125; catch (InterruptedException e) &#123; return false; &#125; finally &#123; if (DEBUG) &#123; Log.d(TAG, mFile.getName() + \":\" + mcr.memoryStateGeneration + \" committed after \" + (System.currentTimeMillis() - startTime) + \" ms\"); &#125; &#125; notifyListeners(mcr); return mcr.writeToDiskResult; &#125; 上面的await()，如果SP内容过多，会阻塞主线程导致ANR，但这种情况并不常见 继续看上面提到的 commitToMemory()// EditorImpl private MemoryCommitResult commitToMemory() &#123; // Returns true if any changes were made long memoryStateGeneration; boolean keysCleared = false; List&lt;String&gt; keysModified = null; Set&lt;OnSharedPreferenceChangeListener&gt; listeners = null; Map&lt;String, Object&gt; mapToWriteToDisk; synchronized (SharedPreferencesImpl.this.mLock) &#123; // We optimistically don't make a deep copy until // a memory commit comes in when we're already // writing to disk. if (mDiskWritesInFlight &gt; 0) &#123; // 有未同步到本地的数据 mMap = new HashMap&lt;String, Object&gt;(mMap); &#125; mapToWriteToDisk = mMap; // mDiskWritesInFlight 代表的是“此时需要将数据写入磁盘，但还未处理或未处理完成的次数” // 将 mDiskWritesInFlight 自增1（这里是唯一会增加 mDiskWritesInFlight 的地方） mDiskWritesInFlight++; // 省略 OnSharedPreferenceChangeListener 通知 synchronized (mEditorLock) &#123; boolean changesMade = false; if (mClear) &#123; // 只有调用了 Editor.clear() ，mClear才为true if (!mapToWriteToDisk.isEmpty()) &#123; changesMade = true; mapToWriteToDisk.clear(); &#125; keysCleared = true; mClear = false; &#125; // mModified是上面调用 putXXX方法来保存对应key和value的容器 for (Map.Entry&lt;String, Object&gt; e : mModified.entrySet()) &#123; String k = e.getKey(); Object v = e.getValue(); // 当v 为 this或 v为null时移除对应的key if (v == this || v == null) &#123; // 什么情况下v为this？再看下上面的remove(key)方法 if (!mapToWriteToDisk.containsKey(k)) &#123; continue; &#125; mapToWriteToDisk.remove(k); &#125; else &#123; if (mapToWriteToDisk.containsKey(k)) &#123;// 相同key的value是否相等，相等则跳过 Object existingValue = mapToWriteToDisk.get(k); if (existingValue != null &amp;&amp; existingValue.equals(v)) &#123; continue; &#125; &#125; mapToWriteToDisk.put(k, v); &#125; changesMade = true; &#125; mModified.clear(); // 清空 mModified 历史记录 if (changesMade) &#123; mCurrentMemoryStateGeneration++; &#125; memoryStateGeneration = mCurrentMemoryStateGeneration; &#125; &#125; // memoryStateGeneration 包含了所有的数据，所以每次commit都会把所有数据都写入磁盘一遍 return new MemoryCommitResult(memoryStateGeneration, keysCleared, keysModified, listeners, mapToWriteToDisk); &#125; 总结一下，commitToMemory()方法会将 Editor 中的提交和现有内存中的数据（mMap）合并，保存到 mapToWriteToDisk （其实也是mMap）中。 需要注意的是，在commitToMemory()方法中，当mClear为true，会清空mMap，但不会清空mModified，所以依然会遍历mModified，将其中保存的写记录同步到mMap中，所以下面这种写法是错误的： sharedPreferences.edit() .putString(\"key1\", \"value1\") // key1 不会被 clear 掉，commit 之后依旧会被写入磁盘中 .clear() .commit(); 此外，为什么Editor.remove(Key)时为什么不直接在map中移除对应key呢？这是为了在多线程场景下保证数据一致 看下 MemoryCommitResult 都有什么内容：// SharedPreferencesImpl 的内部类 MemoryCommitResult private static class MemoryCommitResult &#123; final long memoryStateGeneration; final boolean keysCleared; @Nullable final List&lt;String&gt; keysModified; @Nullable final Set&lt;OnSharedPreferenceChangeListener&gt; listeners; final Map&lt;String, Object&gt; mapToWriteToDisk; final CountDownLatch writtenToDiskLatch = new CountDownLatch(1); //... // 这个方法在写入文件后会被调用 void setDiskWriteResult(boolean wasWritten, boolean result) &#123; this.wasWritten = wasWritten; writeToDiskResult = result; writtenToDiskLatch.countDown(); // CountDownLatch 减一 &#125; &#125; commitToMemory() 之后会调用下面的方法将数据写入文件中private void enqueueDiskWrite(final MemoryCommitResult mcr, final Runnable postWriteRunnable) &#123; final boolean isFromSyncCommit = (postWriteRunnable == null); // 创建一个 Runnable 对象，该对象负责写磁盘操作 final Runnable writeToDiskRunnable = new Runnable() &#123; @Override public void run() &#123; synchronized (mWritingToDiskLock) &#123; // 顾名思义了，这就是最终通过文件操作将数据写入磁盘的方法了 writeToFile(mcr, isFromSyncCommit); &#125; synchronized (mLock) &#123; // 写入磁盘后，将 mDiskWritesInFlight 自减1，代表写磁盘的需求减少一个 mDiskWritesInFlight--; &#125; if (postWriteRunnable != null) &#123; // 执行 postWriteRunnable（提示，在 apply 中，postWriteRunnable 才不为 null） postWriteRunnable.run(); &#125; &#125; &#125;; // Typical #commit() path with fewer allocations, doing a write on // the current thread. if (isFromSyncCommit) &#123; // 由commit调用时，这里是true boolean wasEmpty = false; synchronized (mLock) &#123; // 如果此时只有一个 commit 请求（注意，是 commit 请求，而不是 apply ）未处理，那么 wasEmpty 为 true wasEmpty = mDiskWritesInFlight == 1; &#125; if (wasEmpty) &#123; // 当只有一个 commit 请求未处理，那么无需开启线程进行处理，直接在本线程执行 writeToDiskRunnable 即可 writeToDiskRunnable.run(); return; &#125; &#125; // 将 writeToDiskRunnable 方法线程池中执行（非主线程） // 程序执行到这里，有两种可能： // 1. 调用的是 commit() 方法，并且当前只有一个 commit 请求未处理 // 2. 调用的是 apply() 方法，第二个参数为true QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);&#125; apply()和commit()到底有什么区别再来看下apply()和commit()有什么不同。@Overridepublic void apply() &#123; final long startTime = System.currentTimeMillis(); // commitToMemory方法前面已经分析过，这里和commit方法相同 final MemoryCommitResult mcr = commitToMemory(); final Runnable awaitCommit = new Runnable() &#123; @Override public void run() &#123; try &#123; mcr.writtenToDiskLatch.await(); // commit方法中也提到了这里会等待写入文件完成 &#125; catch (InterruptedException ignored) &#123; &#125; // 省略log信息 &#125; &#125;; // 由一个LinkedList 保存 QueuedWork.addFinisher(awaitCommit); Runnable postWriteRunnable = new Runnable() &#123; @Override public void run() &#123; // 在 enqueueDiskWrite 中调用了 run() 方法 awaitCommit.run(); QueuedWork.removeFinisher(awaitCommit); // 移除掉对应的awaitCommit &#125; &#125;; // 比commit方法多了一个 runnable SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);&#125; 对比apply和commit可以发现。commitToMemory()是一样的，不同点如下： commit()只有一个待处理的（mDiskWritesInFlight == 1）则不会进入到 QueuedWork ，直接由writeToDiskRunnable处理 commit()有多个待处理，和apply()一样都会进入到 QueuedWork，区别是第二个参数分别是 false和true 下面在看 QueuedWork.queue方法：// QueuedWork.java public static void queue(Runnable work, boolean shouldDelay) &#123; Handler handler = getHandler(); synchronized (sLock) &#123; sWork.add(work); // LinkedList 保存每个 work if (shouldDelay &amp;&amp; sCanDelay) &#123; // apply会延迟 100 handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY); &#125; else &#123; handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN); &#125; &#125; &#125; handler 对象是在子线程中创建的：// QueuedWork.java private static Handler getHandler() &#123; synchronized (sLock) &#123; if (sHandler == null) &#123; HandlerThread handlerThread = new HandlerThread(\"queued-work-looper\", Process.THREAD_PRIORITY_FOREGROUND); handlerThread.start(); // 创建了一个子线程handler sHandler = new QueuedWorkHandler(handlerThread.getLooper()); &#125; return sHandler; &#125; &#125; 由handler处理 MSG_RUN 消息，最终会调用到下面的方法： // QueuedWork.java private static void processPendingWork() &#123; // 执行在子线程 long startTime = 0; if (DEBUG) &#123; startTime = System.currentTimeMillis(); &#125; synchronized (sProcessingWork) &#123; LinkedList&lt;Runnable&gt; work; synchronized (sLock) &#123; work = (LinkedList&lt;Runnable&gt;) sWork.clone(); sWork.clear(); getHandler().removeMessages(QueuedWorkHandler.MSG_RUN); &#125; // 遍历处理 LinkedList 中的消息 if (work.size() &gt; 0) &#123; for (Runnable w : work) &#123; // 这里的work是 enqueueDiskWrite() 方法中的 writeToDiskRunnable w.run(); &#125; if (DEBUG) &#123; Log.d(LOG_TAG, \"processing \" + work.size() + \" items took \" + +(System.currentTimeMillis() - startTime) + \" ms\"); &#125; &#125; &#125; &#125; 可以看到 apply() 和 commit() 方法都是提交runnable给 QueuedWork，由 QueuedWork保存在一个LinkedList中，然后由Handler切换到子线程去遍历 LinkedList 挨个执行。只不过 apply() 比 commit() 多了100毫秒延迟。 为什么SP会导致很多ANR既然是在子线程中执行，为什么网上都说 apply和commit会导致ANR呢？ 那就是下面这个关键方法，注意看官方的注释：// QueuedWork.java /** * Trigger queued work to be processed immediately. The queued work is processed on a separate * thread asynchronous. While doing that run and process all finishers on this thread. The * finishers can be implemented in a way to check weather the queued work is finished. * * Is called from the Activity base class's onPause(), after BroadcastReceiver's onReceive, * after Service command handling, etc. (so async work is never lost) */ public static void waitToFinish() &#123; long startTime = System.currentTimeMillis(); boolean hadMessages = false; Handler handler = getHandler(); synchronized (sLock) &#123; // 拿到锁之后移除handler中消息，前面 queue()方法也是用这个锁 if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) &#123; // Delayed work will be processed at processPendingWork() below handler.removeMessages(QueuedWorkHandler.MSG_RUN); &#125; // We should not delay any work as this might delay the finishers sCanDelay = false; &#125; StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();// 允许 disk reads &amp; writes try &#123; processPendingWork(); // 这里会耗时 &#125; finally &#123; StrictMode.setThreadPolicy(oldPolicy); // 回退 StrictMode &#125; try &#123; while (true) &#123; // 遍历通知各个finisher Runnable finisher; synchronized (sLock) &#123; finisher = sFinishers.poll(); &#125; if (finisher == null) &#123; break; &#125; finisher.run(); &#125; &#125; finally &#123; sCanDelay = true; &#125; // 删除耗时统计 &#125; 简单翻译一下：waitToFinish() 会立即触发队列的处理。队列中的work是在单独的线程中异步处理的，同时所有的finishers也是在这个线程中处理。finishers是用来实现一种检查队列中的work是否完成的方式。 waitToFinish() 会在一些地方被调用，比如：Activity的onPause()中，BroadcastReceiver’s onReceive之后，Service command handling之后等等（其实这些都是在**主线程）。 在 ActivityThread的搜索waitToFinish()这个方法，可以看到有好几处，比如 handleStopService()中，如下：private void handleStopService(IBinder token) &#123; Service s = mServices.remove(token); if (s != null) &#123; try &#123; s.onDestroy(); s.detachAndCleanUp(); //.. QueuedWork.waitToFinish(); //...&#125; ActivityThread 是主线程，所以当SP中提交的修改比较多时，因为 QueuedWork.waitToFinish() 有可能会导致主线程 ANR 比如下面这个ANR日志：java.lang.Object.wait(Native Method)java.lang.Thread.parkFor(Thread.java:1220)sun.misc.Unsafe.park(Unsafe.java:299)java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:813)java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:973)java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)java.util.concurrent.CountDownLatch.await(CountDownLatch.java:202)android.app.SharedPreferencesImpl$EditorImpl$1.run(SharedPreferencesImpl.java:363)android.app.QueuedWork.waitToFinish(QueuedWork.java:88)android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3336)android.app.ActivityThread.access$2300(ActivityThread.java:197)android.app.ActivityThread$H.handleMessage(ActivityThread.java:1709)android.os.Handler.dispatchMessage(Handler.java:111)android.os.Looper.loop(Looper.java:224)android.app.ActivityThread.main(ActivityThread.java:5958)java.lang.reflect.Method.invoke(Native Method)java.lang.reflect.Method.invoke(Method.java:372)com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1113) 总结 SharedPreferences肯定是线程安全的，它的内部实现使用了大量synchronized关键字，但不是进程安全的 SharedPreferences 不要存放特别大的数据 第一次加载时，需要将整个SP加载到内存当中，如果过于大，会导致阻塞，甚至会导致 ANR 每次apply或者commit，都会把全部的数据一次性写入磁盘, 所以 SP 文件不应该过大, 影响整体性能 SharedPreference的文件存储性能与文件大小相关，我们不要将毫无关联的配置项保存在同一个文件中，同时考虑将频繁修改的条目单独隔离出来 apply()同步回写（commitToMemory()）内存SharedPreferences.mMap，然后把异步回写磁盘的任务放到一个子线程中等待处理。apply()不需要等待写入磁盘完成，而是马上返回 commit()同步回写（commitToMemory()）内存SharedPreferences.mMap，然后如果mDiskWritesInFlight（此时需要将数据写入磁盘，但还未处理或未处理完成的次数）的值等于1，那么直接在调用 commit()的线程（一般是主线程）执行回写磁盘的操作，否则把异步回写磁盘的任务放到一个子线程中等待执行。commit()会阻塞调用线程，直到写入磁盘完成才返回 SP 操作仅仅把 commit() 替换为 apply() 不是万能的，如果 commit() 过于频繁也会和apply一样，在 ActivityThread 中导致ANR Ref面试高频题：一眼看穿 SharedPreferences 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/03/28/sp-source-code-analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"ANR","slug":"anr","permalink":"http://agehua.github.io/tags/anr/"}]},{"title":"Java内存分配策略","slug":"Java-summary","date":"2022-02-12T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2022/02/13/Java-summary/","link":"","permalink":"http://agehua.github.io/2022/02/13/Java-summary/","excerpt":"java的内存分配策略1、Java 程序运行时的内存分配策略有三种：\n(1) 静态分配\n(2) 栈式分配\n(3) 堆式分配\n","text":"java的内存分配策略1、Java 程序运行时的内存分配策略有三种： (1) 静态分配 (2) 栈式分配 (3) 堆式分配 2、对应的三种存储策略使用的内存空间如下： (1) 静态存储区(也称方法区) 主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好， 并且在程序整个运行期间都存在。 (2) 栈区 当方法被执行时，方法体内的局部变量都在栈上创建，并在方法执行结束时这些局部变量 所持有的内存将会自动被释放。因为栈内存分配运算内置于处理器的指令集中，效率很高， 但是分配的内存容量有限。 (3) 堆区 又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存。这部分内存在不使 用时将会由 Java 垃圾回收器来负责回收。 (4) 栈与堆的区别： 在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存 中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过 该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被 重新使用。 堆内存用来存放所有由 new 创建的对象（包括该对象其中的所有成员变量）和数组。在堆中分 配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还可以在栈 中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变 量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。 (5) 结论： 局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。—— 因为它们属于方法中的变量，生命周期随方法而结束。 成员变量全部存储与堆中（包括基本数据类型，引用和引用的对象实体）—— 因为它们属于类，类对象终究是要被 new 出来使用的。 3、垃圾回收的算法有哪些? ① 引用计数法:原理是在此对象有个引用,即增加一个计数,删除一个引用则减少一个计数.垃圾回收时,只收集计数为0的对象.此算法的最致命的无法处理循环引用的问题 ②: 标记-清除 :此算法分两个阶段,第一阶段从引用的根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除,此算法需要暂停应用,同时产生内存碎片 ③: 复制算法 此算法把内存划分为两个相等的区域,每次只使用一个区域,垃圾回收时,遍历当前使用的区域,把正在使用的对象复制到另一个区域中每次算法每次只处理正在使用的对象,因此复制的成本比较小,同时复制过去以后还能进行相应的内存整理,不会出现”碎片问题”,此算法的缺点也很明显,需要两倍的内存空间 ④: 标记-整理:此算法结合了”标记-清除”和:复制算法的两个的优点,也是分两个阶段,第一个阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,清除未标记的对象并且把存活的对象”压缩”到堆的其中一块,按顺序排放,,此算法避免”标记-清除”的碎片问题,同时也避免”复制”的空间问题 4。root搜索算法中,哪些可以作为root? 被启动类(bootstrap加载器)加载的类和创建的对象 JavaStack中引用的对象(栈内存中引用的对象) 方法区中静态引用 （1.jvm栈的栈帧中的本地变量表的引用 2.方法区静态属性引用 3.方法区中的常量引用 4.本地方法引用） 5、Java 是如何管理内存 Java 的内存管理就是对象的分配和释放问题。在 Java 中，程序员需要通过关键字 new 为 每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的 释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。 这也是 Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控 每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。监视 对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。 6、什么是 Java 中的内存泄露 在 Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是 可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再 使用这些对象。如果对象满足这两个条件，这些对象就可以判定为 Java 中的内存泄漏，这些对象 不会被 GC 所回收，然而它却占用内存。 对象被回收的条件 可达性分析，该对象没有与GC Roots相连接的引用链，将进行如下操作 如果对象还没有执行finalize()方法，就会被放入F-Queue中 当GC触发时，Finalizer线程会F-Queue中的对象的finalize()方法 执行完finalize()方法后，会再次判断对象是否可达，如果不可达，才会被回收（所以对象可以通过在finalize()中将自己连接上某个GC Root链的方式来拯救自己） java集合 1.List：ArrayList、LinkedList、Vector、CopyOnWriteArrayList 2.Set：HashSet、TreeSet、LinkedHashSet、CopyOnWriteArraySet、EnumSet 3.Map：HashMap、TreeMap、LinkedHashMap、HashTable、ConcurrentHashMap、WeakHashMap、EnumMap 4.Queue：ArrayBlockingQueue、LinkedBlockingQueue、DelayQueue、PriorityBlockingQueue、PriorityQueue。 栈：Stack&lt;E&gt; extends Vector&lt;E&gt; // 或者Deque&lt;Integer&gt; stack = new ArrayDeque&lt;Integer&gt;();// 入栈stack.push(E item)// 出栈stack.pop()// 查看栈顶元素stack.peek() ArrayList/** * ArrayList底层的容器 */transient Object[] elementData; // non-private to simplify nested class access transient解释：其实是ArrayList在序列化的时候会调用writeObject()，直接将size和element写入ObjectOutputStream；反序列化时调用readObject()，从ObjectInputStream获取size和element，再恢复到elementData。原因在于elementData是一个缓存数组，它通常会预留一些容量，等容量不足时再扩充容量，那么有些空间可能就没有实际存储元素，采用上诉的方式来实现序列化时，就可以保证只序列化实际存储的那些元素，而不是整个数组，从而节省空间和时间。 扩容为原来的1.5倍 CopyOnWriteArrayListCopyOnWriteArrayList有点像线程安全的ArrayList. 其实它的原理简单概括起来就是读写分离.写操作是在一个复制的数组上进行的,读操作在原始数组中进行,读写是分离的.写操作的时候是加锁了的,写操作完成了之后将原来的数组指向新的数组. 下面我们简单看下add和get方法是如何实现写读操作的. /** * Appends the specified element to the end of this list. * * @param e element to be appended to this list * @return &#123;@code true&#125; (as specified by &#123;@link Collection#add&#125;) */public boolean add(E e) &#123; final ReentrantLock lock = this.lock; lock.lock(); try &#123; Object[] elements = getArray(); int len = elements.length; Object[] newElements = Arrays.copyOf(elements, len + 1); newElements[len] = e; setArray(newElements); return true; &#125; finally &#123; lock.unlock(); &#125;&#125;@SuppressWarnings(\"unchecked\")private E get(Object[] a, int index) &#123; return (E) a[index];&#125;/** * &#123;@inheritDoc&#125; * * @throws IndexOutOfBoundsException &#123;@inheritDoc&#125; */public E get(int index) &#123; return get(getArray(), index);&#125; 适用场景因为每次写数据的时候都会开辟一个新的数组,这样就会耗费内存,而且加锁了,写的性能不是很好.而读操作是非常迅速的,并且还支持在写的同时可以读. 所以就非常适合读多写少的场景. 缺点内存消耗大: 每次写操作都需要复制一个新的数组,所以内存占用是非常大的数据不一致: 读数据的时候可能读取到的不是最新的数据,因为可能部分写入的数据还未同步到读的数组中.对内存敏感和实时性要求很高的场景都不适合. CopyOnWriteArrayList为啥比Vector性能好?在Vector内部,增删改查都进行了synchronized修饰,每个方法都要去锁,性能会大大降低.而CopyOnWriteArrayList只是把增删改加锁了,所以CopyOnWriteArrayList在读方面明显好于Vector.所以CopyOnWriteArrayList最好是在读多写少的场景下使用. LinkedListpublic class LinkedList&lt;E&gt; extends AbstractSequentialList&lt;E&gt; implements List&lt;E&gt;, Deque&lt;E&gt;, Cloneable, java.io.Serializable AbstractSequentialList这个类提供了List的一个骨架实现接口，以尽量减少实现此接口所需的工作量由“顺序访问”数据存储（如链接列表）支持。对于随机访问数据（如数组），应使用AbstractList优先于此类。 实现了List接口,意味着LinkedList元素是有序的,可以重复的,可以有null元素的集合. Deque是Queue的子接口,Queue是一种队列形式,而Deque是双向队列,它支持从两个端点方向检索和插入元素. 实现了Cloneable接口,标识着可以它可以被复制.注意,ArrayList里面的clone()复制其实是浅复制(不知道此概念的赶快去查资料,这知识点非常重要). 实现了Serializable 标识着集合可被序列化。 LinkedList底层是链表结构: 插入和删除比较快（O(1)），查询则相对慢一些（O(n)） 因为是链表结构，所以分配的空间不要求是连续的 private static class Node&lt;E&gt; &#123; E item; //该节点的数据 Node&lt;E&gt; next; //指向下一个节点的指针 Node&lt;E&gt; prev; //指向上一个节点的指针 Node(Node&lt;E&gt; prev, E element, Node&lt;E&gt; next) &#123; this.item = element; this.next = next; this.prev = prev; &#125;&#125; // LinkedList 当做队列使用Queue&lt;Integer&gt; queue = new LinkedList&lt;&gt;();queue.peek(); // 得到队列头元素，不出队queue.poll(); // 取出队列头元素，出队queue.offer();// 入队，队列容量不够时，不会抛出异常，这点跟 queue.add() 相反~ HashMap 存储结构JDK 1.7内部是以数组的形式存储了Entry对象,而每个Entry对象里面有key和value用来存值.它里面包含了key、value、next、hash四个字段,其中next字段是用来引用下一个Entry的(相同的hash值会被放入同一个链表中).数组中的每个位置都是一条单链表(也可以称之为桶),数组中的元素的表头.解决冲突的方式是拉链法,同一条单链表中的Entry的hash值是相同的. transient Entry&lt;K,V&gt;[] table;static class Entry&lt;K,V&gt; implements Map.Entry&lt;K,V&gt; &#123; final K key; V value; Entry&lt;K,V&gt; next; int hash;&#125; JDK 1.8存储结构也是数组,只不过将Entry换了个名字叫Node.1.7中hash值相同的是放单链表中,1.8也是,当这个单链表的长度超过8时,会转换成红黑树,增加查找效率. 负载因子和阈值 /** * The default initial capacity - MUST be a power of two. */static final int DEFAULT_INITIAL_CAPACITY = 1 &lt;&lt; 4; // aka 16/** * The load factor used when none specified in constructor. */static final float DEFAULT_LOAD_FACTOR = 0.75f; HashMap的默认大小是16,默认负载因子是0.75,意思是当存的元素个数超过16*0.75时就要对数组扩容,这里的阈值就是16*0.75=12.负载因子就是用来控制什么时候进行扩容的. 阈值 = 当前数组长度*负载因子 每次扩容之后都得重新计算阈值.默认的数组长度是16,默认的负载因子是0.75这些都是有讲究的.在元素个数达到数组的75%时进行扩容是一个比较折中的临界点,如果定高了的话hash冲突就很严重,桶就会很深,查找起来比较慢,定低了又浪费空间.一般情况下,还是不会去定制这个负载因子. 拉链法工作原理每次新存入一个新的键值对时,首先计算Entry的hashCode,用hashCode%数组长度得到所在桶下标,然后在桶内依次查找是否已存在该元素,存在则更新,不存在则插入到桶的头部. HashMap 1.7和1.8区别 JDK1.7用的是头插法,JDK1.8及置换是尾插法. 且1.7插入时候顺序是与原来相反的,而1.8则还是原来的顺序 JDK1.7是数组+链表,JDK1.8是数组+链表+红黑树 JDK1.7在插入数据之前进行扩容,JDK1.8是插入数据之后才扩容 JDK1.7是Entry来表示节点,而JDK1.8是Node JDK1.7扩容和后存储位置是用hash &amp; (length-1)计算来的,而JDK1.8只需要判断hash值新增参与运算的位是0还是1就能快速计算出扩容后该放在原位置,还是需要放在 原位置+扩容的大小值 . 计算hash值的时候,JDK1.7用了9次扰动处理,而JDK1.8是2次ps: 红黑树查找元素,需要O（logn）的开销 下面来介绍下HashMap与Hashtable的区别： 1.实现：HashMap继承的类是AbstractMap类，而Hashtable继承的是Dictionary类，而Dictionary是一个过时的类，因此通常情况下建议使用HashMap而不是使用Hashtable 2.内部结构：其实HashMap与Hashtable内部基本都是使用数组-链表的结构，但是HashMap引入了红黑树的实现，内部相对来说更加复杂而性能相对来说应该更好 3.NULL值控制：通过前面的介绍我们知道Hashtable是不允许key-value为null值的，Hashtable对于key-value为空的情况下将抛出NullPointerException，而HashMap则是允许key-value为null的，HashMap会将key=null方法index=0的位置。 4.线程安全：通过阅读源码可以发现Hashtable的方法中基本上都是有synchronized关键字修饰的，但是HashMap是线程不安全的，故对于单线程的情况下来说HashMap的性能更优于Hashtable，单线程场景下建议使用HashMap. HashMap是绝大部分利用键值对存取场景的首选.多线程环境下,推荐使用ConcurrentHashMap. 数组+链表+红黑树 ConcurrentHashMap ConcurrentHashMap存在的意义?有了HashMap和Hashtable为啥还需要ConcurrentHashMap? HashMap本身不是线程安全的,不应该在多线程情况下使用!!!. Hashtable是使用synchronized保证线程安全,当一个线程访问其中一个同步方法时,另外的线程是不能访问其同步方法的(竞争的是同一把锁).这样就会导致在put数据的时候,其他线程也不能get数据之类的操作.在线程竞争激烈的条件下,并发效率非常低. 既要多线程环境下使用,也要效率高? 选ConcurrentHashMap没错了. ConcurrentHashMap使用的是分段锁(Segment)技术,将数组分成很多段,每个分段锁维护着几个桶(HashEntry),然后修改数据的时候将这一段锁起来,其他线程这个时候要操作其他分段的数据也互不干扰.如果操作的不是同一分段,则线程间不存在竞争关系,大大提高了并发效率. 当然,有的朋友可能也想到了,有些时候可能需要跨段,比如调用size()方法,这个时候可能会锁整个表. 而在JDK1.8中抛弃了Segment分段锁机制,利用CAS+synchronized来保证并发更新的安全. 乐观锁是一种思想，CAS是这种思想的其中一种实现方式.当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新变量的值,而其他线程都失败,失败的线程并不会挂起,而是被告知这次竞争失败,并可以再次尝试. CAS操作中包含3个操作数: 需要读写的位置(V)、进行比较的预期原值(A)和拟写入的新值(B).如果内存位置V的值与预期原值A相匹配,那么处理器会自动将该位置值更新为新值B.否则处理器不做任何操作. TreeMap和LinkedHashMap TreeMap整体结构TreeMap底层的数据结构是红黑树,和HashMap的红黑树结构是一样的. TreeMap利用红黑树左节点小,右节点大的性质,根据key进行排序,使每个元素能够插入到红黑树中大小适当的位置,维护了key的大小关系,适用于key需要排序的场景. 因为底层使用的是平衡二叉树的结构,所以containsKey,get,put,put,remove等方法的时间复杂度都是log(n). LinkedHashMap的使用HashMap是无序的,TreeMap可以根据key进行排序,LinkedHashMap可以维护插入的顺序.LinkedHashMap是HashMap的子类,它内部有一个双向链表维护着键值对的顺序.每个键值对即是位于哈希表中,也是位于双向链表中.LinkedHashMap支持两种顺序: 插入顺序: 先添加的在前面,后添加的在后面.修改操作是不影响顺序的 访问顺序: 在get/put操作之后,其对应的键值对会移动到链表末尾,表示最近使用到的.而链表的头部就是最久没有被访问到的. HashSet和TreeSet HashSetHashSet里面维护了一个不含重复元素的集合,实现比较简单,就是通过HashMap来实现的. TreeSetTreeSet大致的结构是和HashSet相似,底层的数据结构是TreeMap,所以继承了TreeMap key能够排序的功能,迭代的时候也可以按照key的顺序排序进行迭代. HashSet和TreeSet的区别 HashSet保存的数据是无序的,TreeSet保存的数据是有序的. TreeSet保存自定义类对象的时候,必须实现Comparable接口,不实现就无法区分大小关系,无法排序.HashSet存对象的时候,判断其元素是否重复的依据是hashCode()和equals(). Android中的Bundle,SparseArray和ArrayMap Bundle Android为什么要设计Bundle而不是直接使用HashMap来直接进行数据传递? Bundle内部是由ArrayMap实现的,ArrayMap在设计上比传统的HashMap更多考虑的是内存优化Bundle使用的是Parcelable序列化,而HashMap使用Serializable序列化 SparseArray SparseArray是用来存储key-value组合的,类似HashMap.但是它只能存储key为int类型的,也就避免了key的装箱操作和分配空间.建议使用SparseArray&lt;V&gt;替换HashMap&lt;Integer,V&gt;. 还有就是SparseArray是专门设计来节省空间的,所以它里面的数据存储得非常紧凑.key和value都是单独用一个数组来存储的,并且数组是按大小排好序了的,每次增删改查等操作都是用二分查找来进行定位位置的. 可以看到SparseArray比HashMap少了基本数据的自动装箱操作,而且不需要额外的结构体,单个元素存储成本低,在数据量小的情况下,随机访问的效率很高.但是缺点也显而易见,就是增删的效率比较低,在数据量比较大的时候,调用gc拷贝数组成本巨大. 除了SparseArray,Android还提供了SparseIntArray(int:int),SparseBooleanArray(int:boolean),SparseLongArray(int:long)等,其实就是把对应的value换成基本数据类型. ArrayMap ArrayMap是一种通用的key-value映射的数据结构,和SparseArray类似.但是SparseArray只能存储int类型的key,而ArrayMap可以存储其他类型的key.如果你没有见过它也没关系,你肯定用过它.Bundle底层就是用的这玩意儿存储的数据.它底层不使用SparseArray可能就是因为它的key只能是int类型. ArrayMap与传统的HashMap不同,它的数据结构是两个数组,一个数组(mHashes)用来存放key的hashcode,一个数组(mArray)用来存放key和value.你没看错,mArray数组里面即存放了key,也存放了value ArrayMap在put/remove时,和SparseArray基本是一致的,也是通过二分查找求数组索引,然后再执行相应的操作.不同的是ArrayMap的扩容机制和缩容机制. 在put需要扩容时,如果容量小于4就给4,小于8就给8,其次就是扩容1.5倍.之所以给4或8是因为可以利用缓存的ArrayMap对象;在remove时,如果数组长度大于8但是存储的数据不足数据大小的1/3时,就会缩容,mSize小于等于8则设置新大小为8,否就设置为mSize的1.5倍,也就是说在内存使用量不足1/3时,内存数据收紧50%. 除了 put 方法，ArrayMap 和 SparseArray 都有一个 append 方法，它和 put 很相似，append 的差异在于该方法不会去做扩容操作，是一个轻量级的插入方法。在明确知道肯定会插入队尾的情况下使用 append 性更好，因为 put 一上来就做二分查找，时间复杂度 O(logn)，而 append 时间复杂度为 O(1)。 ArraySet 也是 Android 特有的数据结构，用来替代 HashSet 的，和 ArrayMap 几乎一致，包含了缓存机制、扩容机制等。 ArrayList和LinkedList区别我们知道，通常情况下，ArrayList和LinkedList的区别有以下几点： ArrayList是实现了基于动态数组的数据结构，而LinkedList是基于链表的数据结构； 对于随机访问get和set，ArrayList要优于LinkedList，因为LinkedList要移动指针； 对于添加和删除操作add和remove，一般大家都会说LinkedList要比ArrayList快，因为ArrayList要移动数据。但是实际情况并非这样，对于添加或删除，LinkedList和ArrayList并不能明确说明谁快谁慢 针对for循环，ArrayList比LinkedList速度快，因为LinkedList没有实现RandomAccess接口，需要从头或者从尾开始遍历到指定位置。如果都使用迭代器遍历的话，双方时间差不多。 关于第三条：ArrayList在添加和删除，如果未出现扩容的情况下，ArrayList快，这是因为：当 ArrayList 在添加元素到数组中间时，有一部分数据需要复制重排，效率就不是很高，那为啥 LinkedList 比它还要低呢？这是因为 LinkedList 把元素添加到中间位置的时候，需要在添加之前先遍历查找，这个查找的时间比较耗时。更多详细区别可以看这篇文章 https://blog.csdn.net/javageektech/article/details/108162342 // 使用Iterator遍历没有实现 RandomAccess的数据结构if (!(list instanceof RandomAccess)) &#123; Iterator it = list.iterator(); while(it.hasNext()) &#123; Println(it.next()); &#125;&#125; HashMap、concurrentHashMap、HashTable的区别HashMap是基于哈希表实现的，每一个元素都是一个key-value对，其内部通过单链表解决冲突问题，容量不足（超过了阈值）时，同样会自动增长。 HashMap是非线程安全的，只是用于单线程环境下，多线程环境下可以采用concurrent并发包下的concurrentHashMap。 HashMap实现了Serializable接口，因此它支持序列化，实现了Cloneable接口，能被克隆。 HashMap、HashTable区别1、HashMap是非线程安全的，HashTable是线程安全的。 2、HashMap的键和值都允许有null值存在，而HashTable则不行。 3、因为线程安全的问题，HashMap效率比HashTable的要高。 ConcurrentHashMap是线程安全的HashMap的实现。同样是线程安全的类，它与HashTable在同步方面有什么不同呢？ ConcurrentHashMap与HashTable的区别ConcurrentHashMap基于concurrentLevel划分出了多个Segment来对key-value进行存储，从而避免每次锁定整个数组，在默认的情况下，允许16个线程并发无阻塞的操作集合对象，尽可能地减少并发时的阻塞现象。 ConcurrentHashMap使用Lock锁住部分数组，而HashTable则是锁住整个数组，所以在多线程的环境中，相对于HashTable，ConcurrentHashMap会带来很大的性能提升！ 而在JDK1.8中抛弃了Segment分段锁机制,利用CAS+synchronized来保证并发更新的安全. Java中Vector和ArrayList的区别首先看这两类都实现List接口，而List接口一共有三个实现类，分别是ArrayList、Vector和LinkedList。List用于存放多个元素，能够维护元素的次序，并且允许元素的重复。3个具体实现类的相关区别如下： ArrayList是最常用的List实现类，内部是通过数组实现的，它允许对元素进行快速随机访问。数组的缺点是每个元素之间不能有间隔，当数组大小不满足时需要增加存储能力，就要讲已经有数组的数据复制到新的存储空间中。当从ArrayList的中间位置插入或者删除元素时，需要对数组进行复制、移动、代价比较高。因此，它适合随机查找和遍历，不适合插入和删除。 Vector与ArrayList一样，也是通过数组实现的，不同的是它支持线程的同步，即某一时刻只有一个线程能够写Vector，避免多线程同时写而引起的不一致性，但实现同步需要很高的花费，因此，访问它比访问ArrayList慢。 LinkedList是用链表结构存储数据的，很适合数据的动态插入和删除，随机访问和遍历速度比较慢。另外，他还提供了List接口中没有定义的方法，专门用于操作表头和表尾元素，可以当作堆栈、队列和双向队列使用。 关于ArrayList和Vector区别如下： ArrayList在内存不够时默认是扩展50% + 1个，Vector是默认扩展1倍。 Vector提供indexOf(obj, start)接口，ArrayList没有。 Vector属于线程安全级别的，但是大多数情况下不使用Vector，因为线程安全需要更大的系统开销。 深拷贝or浅拷贝在java语言中，有几种方式可以创建对象呢？ 1 使用new操作符创建一个对象 2 使用clone方法复制一个对象 那么这两种方式有什么相同和不同呢？ new操作符的本意是分配内存。程序执行到new操作符时， 首先去看new操作符后面的类型，因为知道了类型，才能知道要分配多大的内存空间。分配完内存之后，再调用构造函数，填充对象的各个域，这一步叫做对象的初始化，构造方法返回后，一个对象创建完毕，可以把他的引用（地址）发布到外部，在外部就可以使用这个引用操纵这个对象。 而clone在第一步是和new相似的，都是分配内存，调用clone方法时，分配的内存和源对象（即调用clone方法的对象）相同，然后再使用原对象中对应的各个域，填充新对象的域， 填充完成之后，clone方法返回，一个新的相同的对象被创建，同样可以把这个新对象的引用发布到外部。 Person p = new Person(23, \"zhang\"); Person p1 = p; System.out.println(p); System.out.println(p1); 这种是复制引用 如果两个Person对象的name的地址值相同， 说明两个对象的name都指向同一个String对象， 也就是浅拷贝， 而如果两个对象的name的地址值不同， 那么就说明指向不同的String对象， 也就是在拷贝Person对象的时候， 同时拷贝了name引用的String对象， 也就是深拷贝。验证代码如下： Person p = new Person(23, \"zhang\"); Person p1 = (Person) p.clone(); String result = p.getName() == p1.getName() ? \"clone是浅拷贝的\" : \"clone是深拷贝的\"; System.out.println(result); clone是浅拷贝的 序列化属于深拷贝 更多关于java拷贝知识参考这篇文章： https://juejin.cn/post/6844903806577164302 java引用类型 引用类型 被垃圾回收时间 用途 生存时间 强引用 从来不会 对象的一般状态 JVM停止运行时终止 软引用 在内存不足时 对象缓存 内存不足时终止 弱引用 在垃圾回收时 对象缓存 gc运行后终止 虚引用 Unknown Unknown Unknown 强引用是使用最普遍的引用：Object o=new Object(); 特点：不会被GC将对象的引用显示地置为null：o=null; // 帮助垃圾收集器回收此对象 软引用用来描述一些还有用但是并非必须的对象，在Java中用java.lang.ref.SoftReference类来表示。对于软引用关联着的对象，只有在内存不足的时候JVM才会回收该对象。因此，这一点可以很好地用来解决OOM的问题，并且这个特性很适合用来实现缓存：比如网页缓存、图片缓存等 弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象 虚引用也称为幻影引用：一个对象是都有虚引用的存在都不会对生存时间都构成影响，也无法通过虚引用来获取对一个对象的真实引用。唯一的用处：能在对象被GC时收到系统通知，JAVA中用PhantomReference来实现虚引用。 android中的位运算https://juejin.im/post/5c51f308e51d45141a1f2f2c Java 内存模型（Java Memory Model ,JMM）Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。 而JMM就作用于工作内存和主存之间数据同步过程。他规定了如何做数据同步以及什么时候做数据同步。 主内存和工作内存与JVM内存结构中的Java堆、栈、方法区等并不是同一个层次的内存划分，无法直接类比。《深入理解Java虚拟机》中认为，如果一定要勉强对应起来的话，从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分。工作内存则对应于虚拟机栈中的部分区域 总结下，JMM是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。目的是保证并发编程场景中的原子性、可见性和有序性。 Java内存模型的实现了解Java多线程的朋友都知道，在Java中提供了一系列和并发处理相关的关键字，比如volatile、synchronized、final、concurren包等。其实这些就是Java内存模型封装了底层的实现后提供给程序员使用的一些关键字。 其实，原子性问题，可见性问题和有序性问题。是人们抽象定义出来的。而这个抽象的底层问题就是前面提到的缓存一致性问题、处理器优化问题和指令重排问题等 原子性是指在一个操作中就是cpu不可以在中途暂停然后再调度，既不被中断操作，要不执行完成，要不就不执行。 可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。 有序性即程序执行的顺序按照代码的先后顺序执行。 原子性在Java中，为了保证原子性，提供了两个高级的字节码指令monitorenter和monitorexit。在synchronized的实现原理文章中，介绍过，这两个字节码，在Java中对应的关键字就是synchronized。 因此，在Java中可以使用synchronized来保证方法和代码块内的操作是原子性的。 可见性Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值的这种依赖主内存作为传递媒介的方式来实现的。 Java中的volatile关键字提供了一个功能，那就是被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次是用之前都从主内存刷新。因此，可以使用volatile来保证多线程操作时变量的可见性。 除了volatile，Java中的synchronized和final两个关键字也可以实现可见性。只不过实现方式不同，这里不再展开了。 有序性 在Java中，可以使用synchronized和volatile来保证多线程之间操作的有序性。实现方式有所区别： volatile关键字会禁止指令重排。synchronized关键字保证同一时刻只允许一条线程操作。 好了，这里简单的介绍完了Java并发编程中解决原子性、可见性以及有序性可以使用的关键字。读者可能发现了，好像synchronized关键字是万能的，他可以同时满足以上三种特性，这其实也是很多人滥用synchronized的原因。 但是synchronized是比较影响性能的，虽然编译器提供了很多锁优化技术，但是也不建议过度使用。 ReentrantLock与synchronized对比 SynchronizedSynchronized是通过同步互斥来实现线程安全的；即同一时间只能有一个线程访问synchronized修饰的代码块或方法。其特性与功能如下： synchronized是java的关键字，由jvm支持。 支持重入，即一个线程在获取对象的锁以后可以再次对此对象上锁。 修饰普通方法，锁是当前实例对象；修饰静态方法，锁是当前类的class对象；包裹代码块，锁是括号中的对象。 不支持等待中断。 synchronized是非公平的。 ReentrantLockReentrantLock是一种非常常见的临界区处理手段，通过在执行代码前上锁保证同一时间只有一个线程能执行指定的代码块。ReentrantLock的特性与功能如下： ReentrantLock是java api层面的实现，有Unsafe支持。 支持重入。 支持公平锁、非公平锁，默认是非公平锁。公平锁指：多个线程在等待同一个线程的锁时，必须按照申请所得时间顺序来获取锁。非公平锁指：在锁被释放时，任何一个等待锁的线程都有机会获取锁。 支持等待中断。例如：A线程获取对象O的锁， B线程等待获取O的锁，当B长时间无法获取锁时，B可以放弃获取锁。 锁可以绑定多个条件。线程进入临界区，却发现在某一条件满足之后才能执行，条件对象就是用来管理那些已经获得了锁，但是却不能做有用工作的线程。一个ReentrantLock对象可以同时绑定多个Condition对象。 ReentrantLock本质上是通过一个队列来完成同步的。因为每个Node与一个线程关联，只需要做好对队列节点的同步处理，既可以完成多线程的同步处理。 public class Test &#123; ReentrantLock lock = new ReentrantLock(); public static void main(String[] args) &#123; Test tt = new Test(); Thread t1 = new Thread(new Runnable() &#123; @Override public void run() &#123; tt.add(); &#125; &#125;); Thread t2 = new Thread(new Runnable() &#123; @Override public void run() &#123; tt.add(); &#125; &#125;); t1.start(); t2.start(); &#125; public void add()&#123; try&#123; lock.lock(); for (int i = 0; i &lt;10; i++) &#123; System.out.println(\"测试\"+i); &#125; &#125;catch (Exception e)&#123;&#125; finally &#123; lock.unlock(); &#125; &#125;&#125; 通过以上代码我们可以发现，不同于synchronized，ReentrantLock需要开发手动在代码中加锁和解锁。 公平锁与非公平锁 公平锁：通过同步队列来实现多个线程按照申请锁的顺序获取锁。 默认情况下，synchronized和ReentrantLock都是非公平锁。但是ReentrantLock可以通过构造函数传参true,来创建公平锁，可以通过以下的部分源码。 synchronized是JVM虚拟机的实现， 而ReentrantLock是JDK实现的，是java.util.concurrent包中的锁。 单例的双重校验锁实现(面试必备) public class Singleton &#123; private Singleton() &#123;&#125; // 使用volatile修饰变量可以禁止JVM的指令重排，保证多线程下获取实例的唯一。 private volatile static Singleton instance; public static Singleton getInstance()&#123; if(instance == null)&#123; synchronized (Singleton.class)&#123; if(instance == null)&#123; instance = new Singleton(); &#125; &#125; &#125; return instance; &#125;&#125; 深入理解 AQS 和 CAS 原理AQS 全称是 Abstract Queued Synchronizer，即抽象队列同步器，AQS内部基于CAS、LockSupport、自旋和双端等待队列实现的多线程同步工具，AQS它是一套实现多线程同步功能的框架。AQS 在JDK源码中被大量使用到，尤其是在 JUC（Java Util Concurrent）中，比如ReentrantLock、CountDownLatch、ThreadPoolExecutor。理解 AQS 对我们理解 JUC 中其他组件至关重要，并且在实际开发中也可以通过自定义 AQS 来实现各种需求场景。 链接：https://www.jianshu.com/p/5ff4bfe546f3 https://juejin.cn/post/6844904167044038663 注解原理继承 AbstractProcessor ，根据注解构建对象，将对象存入map。然后使用javapoet 遍历map输出到一个类中。这个类就保存了所有的注解对象的键值对 应用APP启动过程应用app具体会运行到哪个进程，我们从一个app的启动入手分析。app的启动一般从该应用的桌面图标点击开始，调用startActivity(Intent), 再通过Binder IPC机制, 最终调用到AMS。AMS会执行如下操作: 1.通过PackageManager的resolveIntent()收集这个intent对象的指向信息. 2.通过grantUriPermissionLocked()方法来验证用户是否有足够的权限去调用该intent对象指向的Activity. 3.如果有权限, AMS会检查并在新的task中启动目标activity. 4.如果ProcessRecord是null, AMS调用startProcessLocked()方法来创建新的进程. android崩溃当应用崩溃时，默认会调用Thread类中设置的一个 UncaughtExceptionHandler 中的 uncaughtException方法，所以我们只要实现一个UncaughtExceptionHandler对象，在其对应方法中实现对崩溃信息的保存或者上传即可。 异常分类Throwable是Java语言中所有错误或异常的超类。下一层分为Error和Exception Error类是指Java运行时系统的内部错误和资源耗尽错误。应用程序不会抛出该类对象。如果出现了这样的错误，除了告知用户，剩下的就是尽力使程序安全的终止。 Exception又有两个分支， 一个是运行时异常RuntimeException，如：NullPointerException、ClassCastException； 一个是检查异常CheckedException，如I/O错误导致的IOException、SQLException。 RuntimeException是那些可能在 Java 虚拟机正常运行期间抛出的异常的超类。派生RuntimeException的异常一般包含几个方面： 1、错误的类型转换 2、数组访问越界 3、访问空指针 如果出现RuntimeException，那么一定是程序员的错误 检查异常CheckedException一般是外部错误，这种异常都发生在编译阶段，Java编译器会强制程序去捕获此类异常，即会出现要求你把这段可能出现异常的程序进行try catch，该类异常一般包括几个方面：1、试图在文件尾部读取数据2、试图打开一个错误格式的URL3、试图根据给定的字符串查找class对象，而这个字符串表示的类并不存在 RuntimeException：在定义方法时不需要声明会抛出RuntimeException， 在调用这个方法时不需要捕获这个RuntimeException；总之，未检查异常不需要try…catch…或throws 机制去处理CheckedException：定义方法时必须声明所有可能会抛出的exception； 在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去总之，一个方法必须声明所有的可能抛出的受检异常；未检查异常要么不可控制（Error），要么应该避免（RuntimeException）。如果方法没有声明所有的可能发生的受检异常，编译器就会给出错误信息 Exception 和 Error 区别Exception和Error都是继承了Throwable类,在Java中只有Throwable类型的实例才可以被抛出(throw)或者捕获,它是异常处理机制的基本组成类型. Exception和Error体现了Java平台设计者对不同异常情况的分类,Exception是程序正常运行中,可以预料的意外情况,可能并且应该捕获,进行相应的处理. Error是指正常情况下,不大可能出现的情况,绝大部分的Error都会导致程序处于非正常状态,不可恢复状态.既然是非正常情况,所以不便于也不需要捕获,常见的如OutOfMemoryError之类的都是Error的子类. Exception又分为可检查(checked)异常和不检查(unchecked)异常,可检查异常在源码里必须显式地进行捕获处理,这里是编译期检查的一部分.不检查异常就是所谓的运行时异常,类似NullPointerException,ArrayIndexOutOfBoundsExceptin之类的,通常是可以编码避免的逻辑错误,具体根据需要来判断是否需要捕获,并不会在编译期强制要求. ClassNotFoundException 和 NoClassDefFoundError 区别需要注意到的是一个是Exception一个是Error. Java支持使用Class.forName方法来动态加载类,任意一个类的类名如果被作为参数传递给这个方法都将导致该类被加载到JVM内存中,如果这个类在类路径中没有被找到,那么此时就会在运行时抛出ClassNotFountException异常. 如果JVM或者ClassLoader实例尝试加载(可能通过正常的方法调用,也可能是使用new来创建新的对象)类的时候找不到类的定义.要查找的类在编译的时候是存在的,运行的时候却找不到类,这个时候就会导致NoClassDefFoundError.造成该问题的原因可能是打包过程中漏掉了部分类,或者jar包出现了损毁或者篡改.解决这个问题的方法是查找那些在开发期间存在于类路径但运行期间却不在类路径下的类. Java多线程sleep和wait的区别 使用方面：从使用的角度来看sleep方法是Thread线程类的方法，而wait是Object顶级类的方法。sleep可以在任何地方使用，而wait只能在同步方法和同步块中使用。 CPU及锁资源释放:sleep、wait调用后都会暂停当前线程并让出CPU的执行时间，但不同的是sleep不会释放当前持有对象的锁资源，到时间后会继续执行，而wait会释放所有的锁并需要notify/notifyAll后重新获取到对象资源后才能继续执行。 异常捕获方面：sleep需要捕获或者抛出异常，而notify/notifyAll则不需要，但是wait方法需要捕获 InterruptedException。 简述jvm中默认的classLoader与功能 1.Bootstrap ClassLoader：负责加载java基础类，主要是 %JRE_HOME/lib/ 目录下的rt.jar、resources.jar、charsets.jar和class等 2.Extension ClassLoader：负责加载java扩展类，主要是 %JRE_HOME/lib/ext 目录下的jar和class 3.App ClassLoader：负责加载当前java应用的classpath中的所有类。 4.classloader 加载类用的是全盘负责双亲委托机制。 1.所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有 Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入。所以，当我们自定义的classloader加载成功了 com.company.MyClass以后，MyClass里所有依赖的class都由这个classLoader来加载完成。 2.双亲委托，是指子类加载器如果没有加载过该目标类，就先委托父类加载器加载该目标类，只有在父类加载器找不到字节码文件的情况下才从自己的类路径中查找并装载目标类。 重写的特性 1.方法名相同，参数类型和顺序相同 2.子类返回类型小于等于父类方法返回类型。即：子类返回的类型要为父类的子类 3.子类抛出异常小于等于父类方法抛出异常。即：子类抛出的异常类型要为父类的子类 4.子类访问权限大于等于父类方法访问权限。 理解Serializable和Parcelable我们日常用到的有二种场景。 1.数据的持久化保存，这里主要是指保存到文件 2.Android页面间数据的传递 第一种情况两者耗时差不多 第二种情况intent putExtra中添加实现了Serializable接口的对象时。Parcel会将Serializable先序列化为字节数组，然后写入，所以这中间就进行了二次序列化，性能肯定比Parcelable要低很多。所以如果我们的场景是界间传值的话，Parcelable是首选。 自行决定哪些需要字段需要序列化 1.继承Parcelable的类，在writeToParcel 方法中由开发者自己决定哪些字段参与初始化 2.Serializable可以使用transient关键字来忽略一些不需要参与序列化的字段，也可以重写writeObject和readObject二个方法来替代默认的序列化调用。JDK中有很多这样的类，比如ArrayList，HashMap，都是重写了writeObject方法。 为什么HashMap要自定义序列化逻辑呢？我想可能的原因是，存储数据的数组table，一般都是不满的（因为HashMap的负载因子默认0.75，超过就会扩容），里面肯定会有很多null，如果是默认的序列化，这些null也会被被序列化，显然这些null是没有必要的做序列化的 Activity 中的 onAttachedToWindow，View 的 onAttachedToWindow和 RecyclerView.Adapter 的 onViewAttachedToWindow Activity 中的 onAttachedToWindow 就是在 View 附加到 window 上的时候进行回调，而 onDetachedFromWindow() 就刚好相反。是在OnResume之后回调，但是在 onAttachedToWindow() 回调的时候，不能拿到 View 的宽高 View 的 onAttachedToWindow 的调用时机会发生在 onMeasure() 之前。我们在自定义 View 的时候，某些比较重量级的资源，而且不能与其他 View 通用的时候，就可以重写这两个方法，并在 onAttachedToWindow() 中进行初始化，onDetachedFromWindow() 方法里释放掉。 RecyclerView.Adapter 的 onViewAttachedToWindow 和onViewDetachedToWindow。这两个方法在列表布局的时候，用作曝光埋点非常好用，当 Adapter 创建的 View 被窗口分离（即滑动离开了当前窗口界面的）的时候，onViewDetachedToWindow() 会被直接回调，反之，在列表项 View 在被滑动进屏幕的时候，onViewAttachedToWindow() 会立马被调用。 RecyclerView.Adapter 的onBindViewHolder和onViewRecycled(RecyclerView.ViewHolder holder)可以成对使用，表示ViewHolder绑定和解绑，但是这两个方法不适合用来做曝光埋点。因为RecyclerView的一二级缓存的重复使用不会回调onBindViewHolder。 RecyclerView.Adapter 咋还有一个 onAttachedToRecyclerView。根据源码我们可以发现，onAttachedToRecyclerView() 是在 setAdapter() 的时候触发。 我的 RecyclerView.Adapter 的 onViewAttachedToWindow 为啥没起作用？可能会有小伙伴会遇到这个问题，在遇到这个问题前，先检查一下你这个 RecyclerView 是否是一个正常滚动的 View，你如果是被别人嵌套滚动，把自己设置了 isNestedScrollingEnabled 为 false 的话，那你都失去了 Recyclerview 的功用了，那自然是不行的。可能又有小伙伴说了，由于需求历史原因，我就是用了 NestedScrollView 嵌套了 Recyclerview，并禁掉了 Recyclerview 的滑动功能，但又想做上面的曝光埋点功能，那如何是好？如果是这样的话，大概你就只能通过类似 View 的 getGlobalVisibleRect() 这样的方法来判断 View 的可见性来处理了。关于 View 的可见性分析，这里就点到为止，大家就自行 Google 吧。 LiveData为何能感知生命周期LiveData是一个数据持有类，它可以通过添加观察者被其他组件观察其变更 LiveData的特点： 1）采用观察者模式，数据发生改变，可以自动回调（比如更新UI）。 2）不需要手动处理生命周期，不会因为Activity的销毁重建而丢失数据。 3）不会出现内存泄漏。 4）不需要手动取消订阅，Activity在非活跃状态下（pause、stop、destroy之后）不会收到数据更新信息。 LiveData 的生命周期感知是由Lifecycle来实现的。ComponentActivity 实现了LifecycleOwner，并添加了一个ReportFragment，通过fragment的生命周期回调来完成生命周期的状态切换，并通知给注册的 LifecycleObserver接口 自定义的Activity都继承自AppCompatActivity ，AppCompatActivity 实现了LifecycleOwner接口，同时持有实现了Lifecycle的LifecycleRegistry对象，这个对象就可以将其理解为观察者模式中的Subject，LifecycleRegistr聚合多个LifecycleObserver，生命周期改变时通知LifecycleObserver进行相应的方法调用。 ViewModelViewModel旨在以注重生命周期的方式存储和管理界面相关的数据(配合它里面的livedata)。 1.1 将Activity的UI处理和数据处理分离，分开管理，解耦且高效。 1.2 ViewModel在屏幕旋转等系统配置更改后被继续保留，避免再次请求数据，浪费网络资源。重建该 Activity时，它接收的ViewModel实例与之前的Activity持有的ViewModel相同。只有当Activity真正销毁时，框架才会调用getViewModelStore().clear()清除所有的ViewModel。 1.3 避免页面销毁后，数据返回后刷新界面导致crash，例如页面发起请求后，数据还没返回就关闭activity，数据返回后，刷新界面，因view不存在而crash。 1.4 两个Fragment可以使用其Activity的ViewModel来处理通信。 1.5 和onSaveInstanceState()对比，onSaveInstanceState()仅适合可以序列化再反序列化的少量数据，而不适合数量可能较大的数据，如用户列表或位图。 1.6 ViewModelScope，为应用中的每个ViewModel定义了ViewModelScope。如果ViewModel已清除，则在此范围内启动的协程都会自动取消。 原理ViewModelProviderViewModelStoreOwner：是一个接口，只定义了一个方法：getViewModelStore()。同样ComponentActivity和Fragment实现了这个接口，所以我们在Activity或者Fragment中使用ViewModelProvider传入的this就可以了。 ViewModelStore：ViewModelStore主要是用来存储ViewModel对象的，内部有一个HashMap集合（HashMap&lt;String, ViewModel&gt; mMap）用来存储ViewModel对象。 ComponentActivity持有一个ViewModelStore，可以通过ViewModelStoreOwner中的getViewModelStore()方法获取。（为啥不直接在Activity获取ViewModelStore，再获取ViewModel呢？因为ViewModel要通过ViewModelProvider.Factory创建） Factory：是一个接口，用来创建ViewModel的 Activity 可以调用ViewMode的方法，同时ViewModel通过LiveData变化的监听改变view Kotlin单例使用 object 关键字object SomeSingleton&#123; fun sayHi()&#123;&#125;&#125; 转成java代码之后是： public final class SomeSingleton &#123; public static final SomeSingleton INSTANCE; public final void sayHi() &#123; &#125; static &#123; SomeSingleton var0 = new SomeSingleton(); INSTANCE = var0; &#125;&#125; 有对比就清晰了，Kotlin 的 object 关键字，在 Java 表现的特点如下： 类用 final 标记，标识不可变性。 内部声明一个 static final 的当前类的对象 INSATNCE。 在静态代码块中，进行 INSTANCE 对象的初始化。 可以看到，在 Kotlin 的 object 中，是使用类的初始化锁来保证线程安全的。 那什么是类的初始化锁？简单来说， JVM 在类的初始化阶段（即在 Class 被加载后，且被线程使用之前），会执行类的初始化，在初始化期间，JVM 会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化，避免多线程调用时，引发线程安全的问题。 怎样保证任务顺序执行 观察者模式，使用队列保存注册的观察者，按队列顺序依次执行 责任链模式，参考view的事件分发、有序广播、Okhttp拦截器 怎么统计app启动过程中的方法AMS 方法进入的时候埋点，方法退出的时候埋点 Fragment栈原理fragment的切换切换都是通过getFragmentManager()，以beginTransaction()开始，commit() / commitNow() / commitAllowingStateLoss() 结束。getFragmentManager().beginTransaction().setCustomAnimations(R.anim.active_right_in, 0, 0, R.anim.active_right_out).add(android.R.id.content, fragment, \"DebugConfigFragment\").addToBackStack(getClass().getSimpleName()).commitAllowingStateLoss(); beginTransaction() 会返回一个FragmentTransaction的实现 -》 BackStackRecord@NonNullpublic FragmentTransaction beginTransaction() &#123; return new BackStackRecord(this);&#125; FragmentTransaction 是一个抽象类，内部定义了操作fragment栈的各种方法 BackStackRecord是FragmentTransaction的实现类 内部定义了一些常量int值，用作操作指令 同时内部有一个实体类 Op，Op类的实例会存储 fragment引用，对应的指令。 在 BackStackRecord 类中，我们以show和hide为例，每次show或hide都会创建一个对应的Op类，并持有了对应的fragment和指令：@NonNullpublic FragmentTransaction hide(@NonNull Fragment fragment) &#123; addOp(new Op(OP_HIDE, fragment)); // OP_HIDE 就定义在FragmentTransaction类中 return this;&#125;@NonNullpublic FragmentTransaction show(@NonNull Fragment fragment) &#123; addOp(new Op(OP_SHOW, fragment)); return this;&#125; addOp()方法将新创建的指令加入到了 mOps（ArrayList）中： ArrayList&lt;Op&gt; mOps = new ArrayList&lt;&gt;();void addOp(Op op) &#123; mOps.add(op); op.mEnterAnim = mEnterAnim; op.mExitAnim = mExitAnim; op.mPopEnterAnim = mPopEnterAnim; op.mPopExitAnim = mPopExitAnim;&#125; 从FragmentTransaction 继承来的方法，比如show和hide这种只会向 mOps 中添加数据，真正消耗 mOps 操作的是 executeOps() 和 executePopOps() 方法： void executeOps() &#123; final int numOps = mOps.size(); for (int opNum = 0; opNum &lt; numOps; opNum++) &#123; // 从前向后遍历 final Op op = mOps.get(opNum); final Fragment f = op.mFragment; if (f != null) &#123; f.setNextTransition(mTransition); &#125; switch (op.mCmd) &#123; case OP_HIDE: f.setNextAnim(op.mExitAnim); mManager.hideFragment(f); break; case OP_SHOW: f.setNextAnim(op.mEnterAnim); mManager.setExitAnimationOrder(f, false); mManager.showFragment(f); break; //... void executePopOps(boolean moveToState) &#123; for (int opNum = mOps.size() - 1; opNum &gt;= 0; opNum--) &#123; // 从后向前遍历 final Op op = mOps.get(opNum); Fragment f = op.mFragment; if (f != null) &#123; f.setNextTransition(FragmentManager.reverseTransit(mTransition)); &#125; switch (op.mCmd) &#123; case OP_HIDE: f.setNextAnim(op.mPopEnterAnim); mManager.showFragment(f); break; case OP_SHOW: f.setNextAnim(op.mPopExitAnim); mManager.setExitAnimationOrder(f, true); mManager.hideFragment(f); break; //... executeOps() 方法和 executePopOps() 方法遍历正好相反、相同指令对应的操作也正好相反。同时这两个方法都是在FragmentManager的commit() / commitNow() / commitAllowingStateLoss()这几个方法中触发的，篇幅有限，本文就不具体展开了。 32位和64位的区别64位可以使用的虚拟内存空间更大，64位意味着操作系统和CPU将使用64位的指令集 虚拟内存（VSS OOM）当前绝大部分系统已经是 64 位系统，无论是服务器、个人 PC、亦或是终端手机。64 位系统的进程地址空间分布中，如果是 3 级页表，内核栈和用户栈分别有 512G 的地址空间，如果是 4 级页表，内核栈和用户栈分别有 256TB 的地址空间，这个值远大于实际物理内存，使用耗尽的可能性也非常小。 而我们的问题，发生在 64 位的 Android 系统中，但却是 32 位的应用。 32 位应用的可用虚拟内存只有 4G。物理内存我们有非常多的机制去管理和控制它的使用量，但虚拟内存其实只是一个空头支票，所以可以理解说，在设计时，能申请的虚拟内存范围是很大的，一般远大于一个进程实际会用的物理内存，所以它不需要复杂的管理机制，从可用的资源中找一块空虚的即可。然而当下系统和应用附加的东西越来越多，手机上可用的物理内存也越来越多，甚至有十几 G 内存的手机，仅仅 4G 的地址空间，些许错误或者资源申请较多，便很容易出现 OOM。 所以总结起来有两个问题导致： 32 位系统的 4G 虚拟内存在当下资源消耗较多的情况下，已捉襟见肘。 虚拟内存没有防止碎片化等复杂的管理机制，出现碎片化等问题。 在32位的应用上，内存使用不合理时，会比较容易引发因虚拟内存不足而导致的白屏或OOM等问题。参考：https://cloud.tencent.com/developer/article/1797705 虚拟内存浅析在多任务操作系统中，每个进程都拥有独立的虚拟地址空间，通过虚拟地址进行内存访问主要具备以下几点优势： 进程可使用连续的地址空间来访问不连续的物理内存，内存管理方面得到了简化。 实现进程与物理内存的隔离，对各个进程的内存数据起到了保护的作用。 程序可使用远大于可用物理内存的地址空间，虚拟地址在读写前不占用实际的物理内存，并为内存与磁盘的交换提供了便利。 重载和重写的区别https://zhuanlan.zhihu.com/p/288278829 区别点 重载方法 重写方法 参数列表 必须修改 一定不能修改 返回类型 可以修改 一定不能修改 异常 可以修改 可以减少或删除，一定不能抛出新的或者更广的异常 访问 可以修改 一定不能做更严格的限制（可以降低限制） 重载方法之间的方法名是相同的，但方法签名不同 一定要注意的是方法重载时，方法返回值没有什么意义，是由方法名和参数列表决定的 方法名和形参数据类型列表可以唯一的确定一个方法，与方法的返回值一点关系都没有，这是判断重载重要依据，所以，以下的代码是不允许的 public long aaaa()&#123; &#125; public int aaaa()&#123; &#125; 类型签名又是另一种了，参考： https://cloud.tencent.com/developer/article/1870340?from=article.detail.1787542 再看一下类型签名：public void test1()&#123;&#125; test1()V public void test2(String str) test2(Ljava/lang/String;)V public int test3()&#123;&#125; test3()I 从以上三个例子，我们就可以很简单的看出一些小小的规律： JVM为我们提供的类型签名实际上是由 方法名(上文的例子为了简单没有写出全类名)、形参列表、返回值三部分构成的，基本形式就是： 全类名.方法名(形参数据类型列表)返回值数据类型 Java方法类型签名中特殊字符/字母含义| 特殊字符 | 数组类型 | 特殊说明 ||:——–:|:——-:|:——–:||V| void| 一般用于表示方法的返回值||Z |boolean|||B| byte|||C| char|||S |short|||I| int|||J|long|||F|float|||D|double|||[|数组| 以[开头，配合其他的特殊字符，表示对应数据类型的数组，几个[表示几维数组||L|全类名|引用类型 以 L 开头 ; 结尾，中间是引用类型的全类名| android 中系统时间参考： https://www.jianshu.com/p/dfa184764daa System.currentTimeMillis()我们一般通过它来获取手机系统的当前时间。事实上，它返回的值是系统时刻距离标准时刻(1970.01.01 00:00:00)的毫秒数。它相当于家里的“挂钟”一样，并不是十分精准，而且可以随意修改。所以它可能经常被网络或者用户校准。正是由于这个原因，这个方法获取的值不适合用来做时间间隔的统计。但是它适合用来获取当前日期，时刻等时间点相关的逻辑。 SystemClock.upTimeMillis()这个值记录了系统启动到当前时刻经过的时间。但是系统深度睡眠(CPU睡眠，黑屏，系统等待唤醒)之中的时间不算在内。这个值不受系统时间设置，电源策略等因素的影响，因此它是大多数时间间隔统计的基础，例如Thread.sleep(long millis),Object.wait(long millis),System.nanoTime()等。系统保证了这个值只增长不下降，所以它适合所有的不包括系统睡眠时间的时间间隔统计。 SystemClock.elapsedRealtime() &amp; SystemClock.elapsedRealtimeNanos这个值与SystemClock.upTimeMillis()类似。它是系统启动到当前时刻经过的时间，包括了系统睡眠经过的时间。在CPU休眠之后，它依然保持增长。所以它适合做更加广泛通用的时间间隔的统计。 综上，如果想要避免用户修改时间，网络校准时间对时间间隔统计的影响，使用SystemClock类相关的方法就可以了，至于选择upTimeMillis()还是elapsedRealtime()就要根据自己的需求确定了。 系统还提供了几个时间控制相关的工具： 标准方法Thread.sleep(long millis) 和 Object.wait(long millis)是基于SystemClock.upTimeMillis()的。所以在系统休眠之后它们的回调也会延期，直到系统被唤醒才继续计时。并且这两个同步方法会响应InterruptException，所以在使用它们的时候必须要处理InterruptException异常。 SystemClock.sleep(long millis) 与 Thread.sleep(long millis) 方法是类似的，只不过SystemClock.sleep(long millis) 不响应InterruptException异常。Handler类的 postDelay()方法也是基于SystemClock.upTimeMillis()方法的。 AlarmManager可以定时发送消息，即使在系统睡眠、应用停止的状态下也可以发送。我们在创建定时事件的时候有两个参数可以选择RTC和ELAPSED_REALTIME，它们对应的方法就是System.currentTimeMillis() ~ RTC，SystemClock.elapsedRealtime() ~ ELAPSED_REALTIME。这样一对应，它们的区别也就非常明显了。 子线程更新UI下次如果有人问你 Android 中子线程真的不能更新 UI 吗？ 你可以这么回答：任何线程都可以更新自己创建的 UI。只要保证满足下面几个条件就好了 在 ViewRootImpl 还没创建出来之前 UI 修改的操作没有线程限制。 在 ViewRootImpl 创建完成之后 1.保证「创建 ViewRootImpl 的操作」和「执行修改 UI 的操作」在同一个线程即可。也就是说，要在同一个线程调用 ViewManager#addView 和 ViewManager#updateViewLayout 的方法。 注：ViewManager 是一个接口，WindowManger 接口继承了这个接口，我们通常都是通过 WindowManger（具体实现为 WindowMangerImpl） 进行 view 的 add remove update 操作的。 2.对应的线程需要创建 Looper 并且调用 Looper#loop 方法，开启消息循环。 有同学可能会问，保证上述条件 1 成立，不就可以避免 checkThread 时候抛出异常了吗？为什么还需要开启消息循坏？ 条件 1 可以避免检查异常，但是无法保证 UI 可以被绘制出来。 条件 2 可以让更新的 UI 效果呈现出来 WindowManger#addView 最终会调用 WindowManageGlobal#addView 方法，进而触发ViewRootImpl#setView 方法，该方法内部会调用 ViewRootImpl#requestLayout 方法。 了解过 UI 绘制原理的同学应该知道 下一步就是 scheduleTraversals 了，该方法会往消息队列中插入一条消息屏障，然后调用 Choreographer#postCallback 方法，往 looper 中插入一条异步的 MSG_DO_SCHEDULE_CALLBACK 消息。等待垂直同步信号回来之后执行。 注：ViewRootImpl 有一个 Choreographer 成员变量，ViewRootImpl 的构造函数中会调用 Choreographer#getInstance(); 方法，获取一个当前线程的 Choreographer 局部实例。 使用子线程更新 UI 有实际应用场景吗？ Android 中的 SurfaceView 通常会通过一个子线程来进行页面的刷新。如果我们的自定义 View 需要频繁刷新，或者刷新时数据处理量比较大，那么可以考虑使用 SurfaceView 来取代 View。 java线程状态 初始状态(NEW)实现Runnable接口和继承Thread可以得到一个线程类，new一个实例出来，线程就进入了初始状态。 就绪状态(RUNNABLE之READY)就绪状态只是说你资格运行，调度程序(Cpu)没有挑选到你，你就永远是就绪状态。调用线程的start()方法，此线程进入就绪状态。当前线程sleep()方法结束，其他线程join()结束，等待用户输入完毕，某个线程拿到对象锁，这些线程也将进入就绪状态。当前线程时间片用完了，调用当前线程的yield()方法，当前线程进入就绪状态。锁池里的线程拿到对象锁后，进入就绪状态。进入：调用Thread.start() 运行中状态(RUNNABLE之RUNNING)线程调度程序从可运行池中选择一个线程作为当前线程时线程所处的状态。这也是线程进入运行状态的唯一的一种方式。 阻塞状态(BLOCKED)阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。进入：等待进入synchronized方法、等待进入synchronized块退出：获取到锁 等待(WAITING)处于这种状态的线程不会被分配CPU执行时间，它们要等待被显式地唤醒，否则会处于无限期等待的状态。进入：Object.wait() Thread.join() LockSupport.park()退出：Object.notify() Object.notifyAll() LockSupport.unpark(Thread) 超时等待(TIMED_WAITING)处于这种状态的线程不会被分配CPU执行时间，不过无须无限期等待被其他线程显示地唤醒，在达到一定时间后它们会自动唤醒。进入：Thread.sleep(long) Object.wait(long) Thread.join(long) LockSupport.parkNanos() LockSupport.parkUnit()退出：Object.notify() Object.notifyAll() LockSupport.unpark(Thread) 终止状态(TERMINATED)当线程的run()方法完成时，或者主线程的main()方法完成时，我们就认为它终止了。这个线程对象也许是活的，但是它已经不是一个单独执行的线程。线程一旦终止了，就不能复生。在一个终止的线程上调用start()方法，会抛出java.lang.IllegalThreadStateException异常。进入：执行完成 同步队列与等待队列Wait()与Notify()方法wait(): 持有锁的线程调用wait()方法后，会一直阻塞，直到有别的线程调用notify()将其唤醒notify(): 只能通知一个等待线程，唤醒任意一个处于wait线程notifyall()：将等待队列中的所有线程唤醒，并加入同步队列 任意一个object以及其子类对象都有两个队列 同步队列：所有尝试获取该对象Monitor失败的线程，都加入同步队列排队获取锁 等待队列：已经拿到锁的线程在等待其他资源时，主动释放锁，置入该对象等待队列中，等待被唤醒，当调用notify()会在等待队列中任意唤醒一个线程，将其置入同步队列的尾部，排队获取锁 同步队列状态当前线程想调用对象A的同步方法时，发现对象A的锁被别的线程占有，此时当前线程进入同步队列。简言之，同步队列里面放的都是想争夺对象锁的线程。当一个线程1被另外一个线程2唤醒时，1线程进入同步队列，去争夺对象锁。同步队列是在同步的环境下才有的概念，一个对象对应一个同步队列。线程等待时间到了或被notify/notifyAll唤醒后，会进入同步队列竞争锁，如果获得锁，进入RUNNABLE状态，否则进入BLOCKED状态等待获取锁。 参考：https://segmentfault.com/a/1190000038392244 静态方法传递Context会导致内存泄漏吗？不会，解释如下： Passing a context or any argument for that matter, to a method, whether it is static or not, will put that argument on the function stack. For the scope of that function the context will be kept on the stack. As soon as the function ends, the function stack is cleared, i.e. the context won’t leak! No exceptions to this! This is the whole pure synchronous function thing discussed previously. If you pass a context to a method (static or not) and in that method you decide to run some background stuff you might leak. This is not a pure function. You would leak if you are holding onto the context longer than it takes to finish executing the original method. Using anonymous inner classes for callbacks when doing background work is typically a culprit here because that callback is invoked after the original function ends. You should ask yourself how the callback can fire and access the context argument if the original function has concluded. Well a copy is created so you now are holding onto a context that outlives the scope of the original function and tada leak! 参考：https://www.reddit.com/r/androiddev/comments/d9khex/can_passing_context_to_static_method_cause_a/ Https 单向认证和双向认证贴张https讲解比较全面的图：还可以参考下面的链接：https://cloud.tencent.com/developer/article/1420302 除了tcp三次握手，还有ssl四次握手https://www.cnblogs.com/wangwenhui/p/14870881.html https://segmentfault.com/a/1190000025126670 Activity启动流程主要包含几步？我们以点击Launcher的一个icon为开始，整体扯一下Activity的启动过程，桌面其实就是LauncherApp的一个Activity 当点击Launcher的icon开始，Launcher进程会像AMS发送点击icon的启动信息（这些信息就是在AndroidMainifest.xml中&lt;intent-filter&gt;标签定义的启动信息，数据由PackageManagerService解析出来） AMS收到信息后会先后经过ActivityTaskManagerService-&gt;ActivityStartController-&gt;ActivityStarter内部类Request，然后把信息存到Request中，并通知Launcher进程让Activity休眠（补充个小知识点，这个过程会检测Activity在AndroidMainifest.xml的注册，如果没有注册就报错了） Launcher进程的ApplicationThread对象收到消息后调用handlePauseActivity()进行暂停，并通知AMS已经暂停。实现细节：ActivityThread.sendMessage()通过ActivityThread的H类发送Handler消息，然后触发 mTransactionExecutor.execute(transaction)，执行过程中依赖ActivityClientRecord.mLifecycleState数值并通过ClientTransactionHandler抽象类的实现（ActivityThread）进行分发。注 ：ActivityClientRecord.mLifecycleState（-1 ~ 7分别代表 UNDEFINED, PRE_ON_CREATE, ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_RESTART） AMS收到Launcher的已暂停消息后，会检查要启动的Activity所在的进程是否已经启动了，如果已经启动了就打开，如果未启动则通过Process.start(android.app.ActivityThread)来启动一个新的进程。 进程创建好以后，会调用ActivityThread.main(),初始化MainLooper，并创建Application对象。然后Instrumentation.newApplication()反射创建Application，创建ContextImpl通过Application的attach方法与Application进行绑定，最终会调用Instrumentation.callApplicationOnCreate执行Application的onCreate函数进行一些初始化的工作。完成后会通知AMS进程已经启动好了。通知过程：通过IActivityManager.attachApplication（IApplicationThread thread, long startSeq），将Application对象传入AMS AMS收到app进程启动成功的消息后，从ActivityTaskManagerService中取出对应的Activity启动信息， 并通过ApplicationThreadProxy对象，调用其scheduleTransaction(ClientTransaction transaction)方法，具体要启动的Activity都在ClientTransaction对象中。 app进程的ApplicationThread收到消息后会调用ActiivtyThread.sendMessage()，通过H发送Handler消息，在handleMessage方法的内部又会调用 mTransactionExecutor.execute(transaction);具体参考第3步最终调用performLaunchActivity方法创建activity和context并将其做关联，然后通过mInstrumentation.callActivityOnCreate()-&gt;Activity.performCreate()-&gt;Activity.onCreate()回调到了Activity的生命周期。 activity向Instrumentation请求创建 Instrumentation通过AMS在本地进程的IBinder接口，访问AMS，这里采用的跨进程技术是AIDL。 然后AMS进程一系列的工作，如判断该activity是否存在，启动模式是什么，有没有进行注册等等。 通过ClientLifeCycleManager，利用本地进程在系统服务进程的IBinder接口直接访问本地ActivityThread。 ApplicationThread是ActivityThread的内部类，IApplicationThread是在远程服务端的Binder接口 ApplicationThread接收到服务端的事务后，把事务直接转交给ActivityThread处理。 ActivityThread通过Instrumentation利用类加载器进行创建实例，同时利用Instrumentation回调activity的生命中周期 阻止activity重建时出现多个fragment正常activity重建后，fragment系统会帮你重建一个，执行到onCreate 自己又会重建一个，所以会出现多个protected void onCreate(@Nullable Bundle savedInstanceState) &#123; if (savedInstanceState != null) &#123; savedInstanceState.putParcelable(\"android:support:fragments\", (Parcelable)null); &#125;&#125; intent传输数据大小限制通过 intent 的 bundle 的源码可以看到它们都是实现了 Parcelable ，其实就是通过序列化来实现通信的。Parcelable 的底层使用了 Parcel 机制。传递实际上是使用了 binder 机制，binder 机制会将 Parcel序列化的数据写入到一个共享内存中，读取时也是 binder 从共享内存中读出字节流，然后 Parcel 反序列化后使用。这就是 Intent 或 Bundle 能够在 activity或者跨进程通信的原理。 这个共享内存就叫 Binder transaction buffer，这块内存有一个大小限制，目前是 1MB，而且共用的，当超过了这个大小就会报错（TransactionTooLargeException）。 HandlerHandler 构造方法：// Handler.javapublic Handler(@Nullable Callback callback, boolean async) &#123; mLooper = Looper.myLooper(); if (mLooper == null) &#123; throw new RuntimeException( \"Can't create handler inside thread \" + Thread.currentThread() + \" that has not called Looper.prepare()\"); &#125; mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async;&#125;// Looper.java public static @Nullable Looper myLooper() &#123; return sThreadLocal.get();&#125;// Looper.java private static void prepare(boolean quitAllowed) &#123; if (sThreadLocal.get() != null) &#123; throw new RuntimeException(\"Only one Looper may be created per thread\"); &#125; sThreadLocal.set(new Looper(quitAllowed)); // 创建mQueue&#125;// Looper.java private Looper(boolean quitAllowed) &#123; mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread();&#125; 一个线程可以创建多个handler，但只会有一个Looper，因此也只会有一个MessageQueue。 如果子线程创建handler的时候没有调用 Looper.prepare() 那么会抛出运行时异常 //MessageQueue.javaMessageQueue(boolean quitAllowed) &#123; mQuitAllowed = quitAllowed; mPtr = nativeInit();&#125; 在java层中，mPtr保存了nativeInit()返回的值，Looper和MessageQueue在java层和native层都有，但它们的功能并不是一一对应，此处native层的Looper与Java层的Looper没有任何的关系，只是在native层重实现了一套类似功能的逻辑。通过管道与epoll机制建立一套消息机制在java层，没有消息时，会调用nativePollOnce方法进入阻塞。进入阻塞后可以通过超时唤起，也可以调用 natvieWake 主动唤起 //frameworks/base/core/jni/android_os_MessageQueue.cppstatic void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj, jlong ptr, jint timeoutMillis) &#123; //把ptr强转为NativeMessageQueue NativeMessageQueue* nativeMessageQueue = reinterpret_cast&lt;NativeMessageQueue*&gt;(ptr); nativeMessageQueue-&gt;pollOnce(env, obj, timeoutMillis);&#125; 总结一下： 因为java层的消息机制是依赖native层的消息机制来实现的，而native层的消息机制是通过Linux的管道和epoll机制实现的，epoll机制是一种高效的IO多路复用机制， 它使用一个文件描述符管理多个描述符，java层通过mPtr指针也就共享了native层的epoll机制的高效性，当loop方法中取不到消息时，便阻塞在MessageQueue的next方法，而next方法阻塞在nativePollOnce方法，nativePollOnce方法通过JNI调用进入到native层中去，最终nativePollOnce方法阻塞在epoll_wait方法中，epoll_wait方法会让当前线程释放CPU资源进入休眠状态，等到下一个消息到达(mWakeEventFd会往管道写入字符)或监听的其他事件发生时就会唤醒线程，然后处理消息，所以就算loop方法是死循环，当线程空闲时，它会进入休眠状态，不会消耗大量的CPU资源。 Native层参考这两篇文章： https://www.jianshu.com/p/57a426b8f145 https://www.jianshu.com/p/c4e34c16aa45 为什么List&lt;String&gt;不能赋值给List&lt;Object&gt;java在1.5的时候引入了泛型，虽然String是Object的子类，但是List&lt;String&gt; 并不是List&lt;Object&gt;的子类型，这叫做不支持协变（也有说型变）。 如何让java支持协变，List&lt;String&gt; 可以赋值给 List&lt;Object&gt;呢，下面这样写就可以List&lt;? extends Object&gt; list = new ArrayList&lt;String&gt;();list.add(\"kotlin\"); // 编译报错，不允许 在kotlin写法如下：val list: List&lt;Any?&gt; = ArrayList&lt;String?&gt;()// 这里的List是一个接口类public interface List&lt;out E&gt; : Collection&lt;E&gt; &#123; //... // 没有add方法&#125; add方法不能使用的原因就是将泛型声明为协变所需要付出的代价。 跟协变对立的是逆变，关键字是super或in（kotlin 这里再延伸一下，java中数组不支持泛型是协变的，kotlin中数组是支持泛型的，也就不再协变 更多的关于协变和逆变的介绍可以看我的这篇文章：Kotlin 与 Java 语言比较 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/02/13/Java-summary/","raw":null,"content":null,"categories":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/categories/java/"}],"tags":[{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"Android Binder机制分析（三）","slug":"android-binder-principle3","date":"2022-02-09T16:00:00.000Z","updated":"2024-12-05T09:41:25.309Z","comments":true,"path":"2022/02/10/android-binder-principle3/","link":"","permalink":"http://agehua.github.io/2022/02/10/android-binder-principle3/","excerpt":"背景上篇文章分析到了Binder机制，同时介绍了Android Framework层系统服务的binder使用。本篇文章分析下Binder的底层实现，以及为什么Binder只需要一次内存拷贝。","text":"背景上篇文章分析到了Binder机制，同时介绍了Android Framework层系统服务的binder使用。本篇文章分析下Binder的底层实现，以及为什么Binder只需要一次内存拷贝。 Binder到底是什么？Android系统内核是Linux，每个进程有自己的虚拟地址空间，在32位系统下最大是4GB，其中3GB为用户空间，1GB为内核空间；每个进程用户空间相对独立，而内核空间是一样的，可以共享，如下图 Linux驱动运行在内核空间，狭义上讲是系统用于控制硬件的中间程序，但是归根结底它只是一个程序一段代码，所以具体实现并不一定要和硬件有关。Binder就是将自己注册为一个misc类型的驱动，不涉及硬件操作，同时自身运行于内核中，所以可以当作不同进程间的桥梁实现IPC功能。 Linux最大的特点就是一切皆文件，驱动也不例外，所有驱动都会被挂载在文件系统dev目录下，Binder对应的目录是/dev/binder，注册驱动时将open release mmap等系统调用注册到Binder自己的函数，这样的话在用户空间就可以通过系统调用以访问文件的方式使用Binder。 进一步关于内核空间和用户空间的区别，可以看这篇文章：https://zhuanlan.zhihu.com/p/343597285 Binder的简略通讯过程一个进程如何通过binder和另一个进程通讯？最简单的流程如下 接收端进程开启一个专门的线程，通过系统调用在binder驱动（内核）中先注册此进程（创建保存一个bidner_proc），驱动为接收端进程创建一个任务队列（biner_proc.todo）接收端线程开始无限循环，通过系统调用不停访问binder驱动，如果该进程对应的任务队列有任务则返回处理，否则阻塞该线程直到有新任务入队发送端也通过系统调用访问，找到目标进程，将任务丢到目标进程的队列中，然后唤醒目标进程中休眠的线程处理该任务，即完成通讯 Binder的一次拷贝众所周知Binder的优势在于一次拷贝效率高，众多博客已经说烂了，那么什么是一次拷贝，如何实现，发生在哪里，这里尽量简单地解释一下。 上面已经说过，不同进程通过在内核中的Binder驱动来进行通讯，但是用户空间和内核空间是隔离开的，无法互相访问，他们之间传递数据需要借助copy_from_user和copy_to_user两个系统调用，把用户/内核空间内存中的数据拷贝到内核/用户空间的内存中，这样的话，如果两个进程需要进行一次单向通信则需要进行两次拷贝，如下图。 Binder单次通信只需要进行一次拷贝，因为它使用了内存映射，将一块物理内存（若干个物理页）分别映射到接收端用户空间和内核空间，达到用户空间和内核空间共享数据的目的。 发送端要向接收端发送数据时，内核直接通过copy_from_user将数据拷贝到内核空间映射区，此时由于共享物理内存，接收进程的内存映射区也就能拿到该数据了，如下图: 用户空间通过mmap系统调用，调用到Binder驱动中binder_mmap函数进行内存映射 Binder套件架构内核层的Binder驱动已经提供了IPC功能，不过还需要在framework native层提供一些对于驱动层的调用封装，使framework开发者更易于使用，由此封装出了native Binder；同时，由于framework native层是c/c++语言实现，对于应用开发者，需要更加方便的Java层的封装，衍生出Java Binder；最后在此之上，为了减少重复代码的编写和规范接口，在Java Binder的基础上又封装出了AIDL。经过层层封装，在使用者使用AIDL时对于Binder基本上是无感知的。 这里贴一张架构图。 Native层：BpBinder代表服务端Binder的一个代理，内部有一个成员mHandle就是服务端Binder在驱动层的句柄，客户端通过调用BpBinder::transact传入该句柄，经过驱动层和服务端BBinder产生会话，最后服务端会调用到BBinder::onTransact。在这里两者之间通过约定好的code来标识会话内容。 Java层：Java层是对native层的封装，本质没有什么区别，。 AIDL：AIDL生成的代码对于Binder进行了进一步封装，&lt;接口&gt;.Stub对应服务端Binder，&lt;接口&gt;.Stub.Proxy标识客户端，内部持有一个mRemote实例（BinderProxy），aidl根据定义的接口方法生成若干个TRANSACTION_&lt;函数名&gt; code常量，两端Binder通过这些code标识解析参数，调用相应接口方法。换言之AIDL就是对BinderProxy.transact和Binder.onTransact进行了封装，使用者不必再自己定义每次通讯的code以及参数解析。 RefBinder概述，快速了解Binder体系 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/02/10/android-binder-principle3/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AIDL","slug":"aidl","permalink":"http://agehua.github.io/tags/aidl/"},{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"}]},{"title":"android场景实现AOP编程","slug":"AOP-android","date":"2021-12-13T16:00:00.000Z","updated":"2024-12-05T09:41:25.311Z","comments":true,"path":"2021/12/14/AOP-android/","link":"","permalink":"http://agehua.github.io/2021/12/14/AOP-android/","excerpt":"我在很早之前就了解过面向切面（AOP）的编程思想，比如AspectJ 实现简单的切面编程，不过都快忘了 :(。本文是想探究AOP在Android环境中的使用，补全Android开发者的技能树。\n常见的AOP编程框架有AspectJ、 Cglib，Hibernate 和 Spring 等等，而这些目前流行的AOP框架绝大多数底层实现都是直接或间接地通过 ASM 来实现字节码操作，本文重点就来介绍一下ASM。","text":"我在很早之前就了解过面向切面（AOP）的编程思想，比如AspectJ 实现简单的切面编程，不过都快忘了 :(。本文是想探究AOP在Android环境中的使用，补全Android开发者的技能树。 常见的AOP编程框架有AspectJ、 Cglib，Hibernate 和 Spring 等等，而这些目前流行的AOP框架绝大多数底层实现都是直接或间接地通过 ASM 来实现字节码操作，本文重点就来介绍一下ASM。 ASM简介ASM是一个通用的Java字节码操作和分析框架，它可以用来修改现有的类或直接以二进制形式动态生成类。官网地址是：https://asm.ow2.io/ java字节码简单介绍由于 ASM 是直接对class文件的字节码进行操作，因此，要修改class文件内容时，也要注入相应的java字节码。 所以，在注入字节码之前，我们还需要了解下class文件的结构，JVM指令等知识。 1.class文件结构Java源文件经过javac编译器编译之后，将会生成对应的二进制.class文件 Java类文件是 8 位字节的二进制流。数据项按顺序存储在class文件中，相邻的项之间没有间隔，这使得class文件变得紧凑，减少存储空间。在Java类文件中包含了许多大小不同的项，由于每一项的结构都有严格规定，这使得 class 文件能够从头到尾被顺利地解析。 类结构体中所有的修饰符、字符常量和其他常量都被存储在class文件开始的一个常量堆栈(Constant Stack)中，其他结构体通过索引引用。 每个类必须包含headers（包括：class name, super class, interface, etc.）和常量堆栈（Constant Stack）其他元素，例如：字段（fields）、方法（methods）和全部属性（attributes）可以选择显示或者不显示。 每个字段块（Field section）包括名称、修饰符（public, private, etc.）、描述符号(descriptor)和字段属性。 每个方法区域（Method section）里面的信息与header部分的信息类似，信息关于最大堆栈（max stack）和最大本地变量数量（max local variable numbers）被用于修改字节码。对于非abstract和非native的方法有一个方法指令表，exceptions表和代码属性表。除此之外，还可以有其他方法属性。 每个类、字段、方法和方法代码的属性有属于自己的名称记录在类文件格式的JVM规范的部分，这些属性展示了字节码多方面的信息，例如源文件名、内部类、签名、代码行数、本地变量表和注释。JVM规范允许定义自定义属性，这些属性会被标准的VM（虚拟机）忽略，但是可以包含附件信息。 方法代码表包含一系列对java虚拟机的指令。有些指令在代码中使用偏移量，当指令从方法代码被插入或者移除时，全部偏移量的值可能需要调整。 2.Java类型与class文件内部类型对应关系Java类型分为基本类型和引用类型，在 JVM 中对每一种类型都有与之相对应的类型描述，如下表： Java type JVM Type descriptor boolean Z char C byte B short S int I float F long J double D Object Ljava/lang/Object; int[] [I Object[][] [[Ljava/lang/Object; 在 ASM 中要获得一个类的 JVM 内部描述，可以使用org.objectweb.asm.Type类中的getDescriptor(final Class c)方法，如下：public class TypeDescriptors &#123; public static void main(String[] args) &#123; System.out.println(Type.getDescriptor(TypeDescriptors.class)); System.out.println(Type.getDescriptor(String.class)); &#125; &#125; 运行结果：Lorg/victorzhzh/core/structure/TypeDescriptors; Ljava/lang/String; 3.Java方法声明与class文件内部声明的对应关系在Java的二进制文件中，方法的方法名和方法的描述都是存储在Constant pool 中的，且在两个不同的单元里。因此，方法描述中不含有方法名，只含有参数类型和返回类型。格式：(参数描述符)返回值描述符 Method declaration in source file Method descriptor void m(int i, float f) (IF)V int m(Object o) (Ljava/lang/Object;)I int[] m(int i, String s) (ILjava/lang/String;)[I Object m(int[] i) ([I]Ljava/lang/Object; String m() ()Ljava/lang/String; 上面3点，如果不熟悉字节码操作集合的话，写起来会很费劲，所以ASM为主流的IDE专门提供了开发插件BytecodeOutline： IDEA：ASM Bytecode Outline Eclipse：BytecodeOutline 以IDEA为例，只需要对应的类中右击-&gt;Show Bytecode outline即可 ASM 框架执行流程ASM对字节码的操作和分析都是基于访问者模式来实现，而访问者模式有两个核心类分别是：独立的访问者、接收访问者事件产生器对应的ASM里面就是两个核心类：ClassVisitor和ClassReader，下面分别进行介绍； 关于访问者模式的介绍，可以看这篇文章：访问者模式 ClassVisitorASM 内部采用 访问者模式 将 .class 类文件的内容从头到尾扫描一遍，每次扫描到类文件相应的内容时，都会调用ClassVisitor内部相应的方法。比如： 扫描到类文件时，会回调ClassVisitor的visit()方法； 扫描到类注解时，会回调ClassVisitor的visitAnnotation()方法； 扫描到类成员时，会回调ClassVisitor的visitField()方法； 扫描到类方法时，会回调ClassVisitor的visitMethod()方法；······扫描到相应结构内容时，会回调相应方法，该方法会返回一个对应的字节码操作对象（比如，visitMethod()返回MethodVisitor实例），通过修改这个对象，就可以修改class文件相应结构部分内容，最后将这个ClassVisitor字节码内容覆盖原来.class文件就实现了类文件的代码切入。 具体关系如下： 树形关系 使用的接口 Class ClassVisitor Field FieldVisitor Method MethodVisitor Annotation AnnotationVisitor 整个具体的执行时序如下图所示： 根据时序，上面所有方法都会被事件产生器ClassReader调用，所有方法中的参数都是ClassReader提供的 ClassReader此类主要功能就是读取字节码文件，然后把读取的数据通知ClassVisitor，字节码文件可以多种方式传入：public ClassReader(final InputStream inputStream)：字节流的方式；public ClassReader(final String className)：文件全路径；public ClassReader(final byte[] classFile)：二进制文件； 常见使用方式如下所示：ClassReader classReader = new ClassReader(\"com/zh/asm/TestService\");ClassWriter classVisitor = new ClassWriter(ClassWriter.COMPUTE_MAXS);classReader.accept(classVisitor, 0); ClassReader的accept方法处理接收一个访问者，还包括另外一个parsingOptions参数，选项包括： SKIP_CODE：跳过已编译代码的访问（如果您只需要类结构，这可能很有用）； SKIP_DEBUG：不访问调试信息，也不为其创建人工标签； SKIP_FRAMES：跳过堆栈映射帧； EXPAND_FRAMES：解压缩这些帧； ClassWriter以上实例中使用了ClassWriter，其继承于ClassVisitor，主要用来生成类，可以单独使用，如下所示：ClassWriter cw = new ClassWriter(0);cw.visit(V1_5, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE,\"pkg/Comparable\", null, \"java/lang/Object\",new String[]&#123;\"pkg/Mesurable\"&#125;);cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, \"LESS\",\"I\", null, new Integer(-1)).visitEnd();cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, \"EQUAL\",\"I\", null, new Integer(0)).visitEnd();cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, \"GREATER\",\"I\", null, new Integer(1)).visitEnd();cw.visitMethod(ACC_PUBLIC + ACC_ABSTRACT, \"compareTo\",\"(Ljava/lang/Object;)I\", null, null).visitEnd();cw.visitEnd();byte[] b = cw.toByteArray();//输出FileOutputStream fileOutputStream = new FileOutputStream(new File(\"F:/asm/Comparable.class\"));fileOutputStream.write(b);fileOutputStream.close(); 以上通过ClassWriter生成一个字节码文件，然后转换成字节数组，最后通过FileOutputStream输出到文件中，反编译结果如下：package pkg;public interface Comparable extends Mesurable &#123; int LESS = -1; int EQUAL = 0; int GREATER = 1; int compareTo(Object var1);&#125; 在实例化ClassWriter需要提供一个参数flags，选项包括： COMPUTE_MAXS：将为你计算局部变量与操作数栈部分的大小；还是必须调用 visitMaxs，但可以使用任何参数：它们将被忽略并重新计算；使用这一选项时，仍然必须自行计算这些帧； COMPUTE_FRAMES：一切都是自动计算；不再需要调用 visitFrame，但仍然必须调用 visitMaxs（参数将被忽略并重新计算）； 0：不会自动计算任何东西；必须自行计算帧、局部变量与操作数栈的大小； 以上只是对ClassWriter的单独使用，但更有意义的其实是把以上三个核心类整合起来使用，下面重点看看转换操作；转换操作在类读取器和类写入器之间引入一个 ClassVisitor，把三者整合起来，大致代码结构如下所示：ClassReader classReader = new ClassReader(\"com/zh/asm/TestService\");ClassWriter classWriter = new ClassWriter(ClassWriter.COMPUTE_MAXS);//处理ClassVisitor classVisitor = new AddFieldAdapter(classWriter...);classReader.accept(classVisitor, 0); 这里提供了一个添加属性的适配器，可以重写visitEnd方法，然后写入新的属性，代码如下：public class AddFieldAdapter extends ClassVisitor &#123; private int fAcc; private String fName; private String fDesc; //是否已经有相同名称的属性 private boolean isFieldPresent; public AddFieldAdapter(ClassVisitor cv, int fAcc, String fName, String fDesc) &#123; super(ASM4, cv); this.fAcc = fAcc; this.fName = fName; this.fDesc = fDesc; &#125; @Override public FieldVisitor visitField(int access, String name, String desc, String signature, Object value) &#123; //判断是否有相同名称的字段，不存在才会在visitEnd中添加 if (name.equals(fName)) &#123; isFieldPresent = true; &#125; return cv.visitField(access, name, desc, signature, value); &#125; @Override public void visitEnd() &#123; if (!isFieldPresent) &#123; FieldVisitor fv = cv.visitField(fAcc, fName, fDesc, null, null); if (fv != null) &#123; fv.visitEnd(); &#125; &#125; cv.visitEnd(); &#125;&#125; 根据ClassVisitor的每个方法被调用的顺序，如果类中有多个属性，那么visitField会被调用多次，每次都会检查要添加的字段是否已经有了，然后保存在isFieldPresent标识中，这样在访问最后的visitEnd中判断是否需要添加新属性；ClassVisitor classVisitor = new AddFieldAdapter(classWriter,ACC_PUBLIC + ACC_FINAL + ACC_STATIC,\"id\",\"I\"); 这里添加了一个public static final int id；可以把字节数组写入class类文件中，然后反编译查看：public class TestService &#123; public static final int id; ......&#125; visitField()方法返回了一个 FieldVisitor，它是一个抽象类，所以可以在 visitField() 方法中返回我们自己定义的 FieldVisitor 的实现类，去处理对应的逻辑；同理还有 MethodVisitor 几个常见的工具类介绍 TypeType对象表示一种 Java类型，既可以由类型描述符构造，也可以由Class对象构建；Type类还包含表示基元类型的静态变量； TraceClassVisitor扩展了ClassVisitor类，并构建了所访问类的文本表示；使用TraceClassVisitor以便获得实际生成内容的可读跟踪； CheckClassAdapterClassWriter 类并不会核实对其方法的调用顺序是否恰当，以及参数是否有效；因此有可能会生成一些被 Java 虚拟机验证器拒绝的无效类。为了尽可能提前检测出部分此类错误，可以使用CheckClassAdapter类 ； ASMifier这个类为TraceClassVisitor工具提供了一个可选的后端（默认情况下，它使用一个Textifier后端，产生上面显示的输出类型）。这个后端使TraceClassVisitor类的每个方法打印用于调用它的Java代码 LocalVariablesSorter继承自MethodVisitor，将一个方法中使用的局部变量按照它们在这个方法中的出现顺序重新进行编号，同时可以使用 newLocal 方法创建一个新的局部变量； AdviceAdapter继承自LocalVariablesSorter，此适配器是一个抽象类，可用于在方法的开头以及任何RETURN或ATHROW指令之前插入代码；其主要优点是它也适用于构造函数，其中代码不能仅插入构造函数的开头，而是在调用超级构造函数之后插入。 处理字节码的工具介绍完了，那android的插件如何将操作后的字节码打包的apk中呢？官方提供了一份在打包 dex 文件之前的编译过程中操作 .class 文件的api，那就是 AGP AGP(Android Gradle Plugin) 很早之前郭霖大神就写过一篇文章：Android Gradle高级用法，动态编译技术:Plugin Transform Javassist操作Class文件 文章中提到：gradle 从1.5开始，gradle 插件包含了一个叫 Transform 的 API，这个 API 允许第三方插件在 class 文件转为为 dex 文件前操作编译好的 class 文件，这个 API 的目标是简化自定义类操作，而不必处理 Task，并且在操作上提供更大的灵活性。 他文章里的transform依赖是这样compile 'com.android.tools.build:transform-api:1.5.0' 但是现在是这样//从2.0.0版本开始就是在gradle-api中了implementation 'com.android.tools.build:gradle-api:3.1.4' 关于Gradle版本和Gradle Plugin的版本，参考官方的介绍：gradle plugin版本说明，这里简单列出常见的几个版本： Gradle版本 Gradle Plugin版本 4.1+ 3.0.0+ 4.4+ 3.1.0+ 5.4.1+ 3.5.0 - 3.5.4 6.5+ 4.1.0+ 7.0+ 7.0 AGP 4.1 中移除了构建缓存，本文使用的AGP版本为 3.5.4 Gradle的架构 在最下层的是底层Gradle框架，它主要提供一些基础服务，如task的依赖，有向无环图的构建等 上面的则是Google编译工具团队的Android Gradle plugin框架，它主要是在Gradle框架的基础上，创建了很多与Android项目打包有关的task及artifacts 最上面的则是开发者自定义的Plugin，一般是在Android Gradle plugin提供的task的基础上，插入一些自定义的task，或者是增加Transform进行编译时代码注入 android plugin层语言选择：Google编译工具组从3.2.0开始，新增的插件全部都是用Kotlin编写的。 怎么查看官方的plugin都有哪些呢，在android studio Project视图 &gt; External libraries &gt; com.android.tools.build:gradle:x.x.x里，如下图： 如何创建Plugin我们后面再说，可以提前了解一点的是：官方和我们自己实现的plugin都是基于 org.gradle.api.Plugin 实现的，都需要提供一个类似 META-INF.gradle-plugins/xxx.properties 这样的配置文件，文件内容是需要指定 “implementation-class”的实现类是什么。 打开上图里的任意一个.properties文件，里面就是对应plugin实现类的地址 自定义Gradle PluginGradle支持通过插件的方式来扩展功能，已保证开发者可以按照自己的需求来完成自动化构建。而且Gradle插件允许已任何可以被编译成字节码的语言编写Gradle提供如下几个插件编写方式： Build Script我们可以在build脚本中直接完成插件代码的编写，这种方式缺点是只能在一个脚本中使用，优点是开发编译都很方便 buildSrc 工程除了应用程序工程，Gradle脚本同样也可以作为工程进行管理。默认情况下，Gradle会自动处理如下路径的插件源码，并添加到编译流程中：[Project_root]/buildSrc/src/main/groovy 这种方式整个app所有build脚本中都可以使用，但也仅限于本应用程序范畴 Standalone Project以独立工程实现，在这种情况下，插件JAR包存在，并支持在一个包中包含多个插件 根据Gradle规定，用户自定义的插件需要实现Plugin接口。当我们在build脚本中使用插件时，可以通过apply plugin:[PLUG_ID]来指明。然后Gradle会调用该插件中的apply方法：apply plugin: GreetingPluginclass GreetingPlugin implements Plugin&lt;Project&gt; &#123; void apply(Project project) &#123; project.task('hello') &lt;&lt; &#123; println \"Hello from the GreetingPlugin\" &#125; &#125;&#125; 这段代码用于添加一个名为”hello“的task，它的代码虽然简单，但是apply方法中传递了一个重要的类 org.gradle.api.Project，其他复杂的插件都是通过Project类来操作编译过程，达到对应的效果。下面是 Project 类的一些重要方法：// 根据name创建一个task，就是上面例子里的写法，还有好多同名方法，这里不一一列举了Task task(String name) throws InvalidUserDataException;// 根据一个工程路径，获得一个File对象，省略同名方法File file(Object path);// Adds a closure to be called immediately after this project has been evaluated.afterEvaluate​(Closure closure)//Returns the properties of this project.getProperties()// ... 其他方法的介绍可以看gradle 文档：https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html 如果我们不单只是创建一个Task去执行，还想在android编译过程中进行处理，则需要使用到Transform Api，像下面这种方式：AppExtension appExtension = (AppExtension)project.getProperties().get(\"android\");// 或者// AppExtension appExtension = project.extensions.getByType(AppExtension)//将自定义Transform添加到编译流程中appExtension.registerTransform(new MethodTimeTransform(project)); Transform ApiTransform 是专门处理构建过程中的中间产物，Transform 可以被看作是 Gradle 在编译项目时的一个 task，在 .class 文件转换成 .dex 的流程中会执行这些 task，对所有的 .class 文件（可包括第三方库的 .class）进行转换，转换的逻辑定义在 Transform 的 transform 方法中。实际上平时我们在 build.gradle 中常用的功能都是通过 Transform 实现的，比如混淆（proguard）、dexBuilder等。 篇幅有限，本文关于当前android上实现AOP编程就介绍到这里。关于Transform api的语法和具体例子可以看这篇文章：手把手教大家用Transform API和ASM实现一个防快速点击案例 Ref字节码增强技术探索 ASM教程：https://github.com/dengshiwei/asm-module ASM入门篇：https://segmentfault.com/a/1190000040160637 参考：https://juejin.cn/post/6844903616487096333 Android 进阶之路：ASM 修改字节码，这样学就对了！ 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/12/14/AOP-android/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AGP","slug":"agp","permalink":"http://agehua.github.io/tags/agp/"},{"name":"ASM","slug":"asm","permalink":"http://agehua.github.io/tags/asm/"},{"name":"Transform","slug":"transform","permalink":"http://agehua.github.io/tags/transform/"},{"name":"AOP","slug":"aop","permalink":"http://agehua.github.io/tags/aop/"}]},{"title":"移动view的几种方式总结","slug":"view-scroll-apis","date":"2021-08-06T16:00:00.000Z","updated":"2024-12-05T09:41:25.325Z","comments":true,"path":"2021/08/07/view-scroll-apis/","link":"","permalink":"http://agehua.github.io/2021/08/07/view-scroll-apis/","excerpt":"移动view的几种方式使用View.layout(l, t, r, b)方法\nAssign a size and position to a view and all of its descendants这个方法是用来指定一个view和它所有的子view的尺寸和位置","text":"移动view的几种方式使用View.layout(l, t, r, b)方法 Assign a size and position to a view and all of its descendants这个方法是用来指定一个view和它所有的子view的尺寸和位置This is the second phase of the layout mechanism. (The first is measuring). In this phase, each parent calls layout on all of its children to position them. This is typically done using the child measurements that were stored in the measure pass()这个是布局的第二阶段，第一阶段是 measure。这个阶段由父view调用每个子view的layout方法来定位子view。Derived classes should not override this method. Derived classes with children should override onLayout. In that method, they should call layout on each of their children.实现类不应该重写这个方法，而是应该重写 onLayout 方法，在onLayout方法中会调用实现类的各个子view的layout方法 这四个参数也都是相对于父视图来说的，layout的过程就是确定View在屏幕上显示的具体位置，在代码中就是设置其成员变量mLeft，mTop，mRight，mBottom的值，这几个值构成的矩形区域就是该View显示的位置，不过这里的具体位置都是相对于父视图的位置。 其中，mRight所指的是当前view的右边缘离父视图左边缘的距离（mLeft+自己的宽度），mBottom也是指当前view的下边缘离父视图的上边缘的距离 这种方式可以刷新页面，但是一旦调用requestLayout，会导致view回到最开始的位置，因为mTop、mLeft被重置了 使用View.setX()在 getX() 方法的注释上是这样说的： The visual x position of this view, in pixels. This is equivalent to the setTranslationX(float) translationX property plus the current getLeft() left property. 意思就是说获取到实际的View的x y 值，该值 getX = getLeft + getTraslationX，并且最后得出的值也是相对父视图来说的。 使用setTranslationX(float translationX) Sets the horizontal location of this view relative to its {@link #getLeft() left} position. This effectively positions the object post-layout, in addition to wherever the object’s layout placed it. param translationX: The horizontal position of this view relative to its left position, in pixels. translateX是相对于自身left属性来进行的平移，比如 left=20，此时调用setTranslationX(30)后，就是相对于left（而不是它上一次的translationX后的位置）往右平移30px，若此时再调用调用setTranslationX(40)，之前的30px值就被覆盖，改为相对于left右移40px。 这里水平方向上的X也是相对于父容器的当前View的位置，就像前面的等式所说，x = left + translationX；所以每一次setTranslationX都会导致getX值的变化，而left的值并不会改变，requestLayout也不会让view发生任何改变 使用View的offsetLeftAndRight(offset) Offset this view’s horizontal location by the specified amount of pixels. 垂直方向上使用 offsetTopAndBottom()。RecyclerView移动子view就是使用这两个方法，具体原理可以看我的这篇文章Recyclerview 滑动相关功能总结。本质上也是改变mTop、mLeft的值，但是要注意这个方法不能用在onTouch的MotionEvent.ACTION_MOVE事件上，会导致滑动距离加倍 改变LayoutParams的marginLayoutParams是相对于父布局而言，所以这种方式只能在父布局范围内移动view，如果父View内只有一个子view，推荐使用这种方式移动子viewsetmargins 相对父视图来实现移动，前提是不能跟其他子view发生关系需要手动调用 requestLayout 通知重绘 使用 setPadding(l, t, r, b)设置该view的内部缩进值(自己内部)，相对于Margin(相对于其他view或ViewGroup). 不推荐使用这种方式移动view，因为可能会造成View内部内容展示不全 利用View的scrollTo(x, y), scrollBy(x, y) Set the scrolled position of your view. This will cause a call to {@link #onScrollChanged(int, int, int, int)} and the view will be invalidated.这个方法修改的是View的两个成员变量mScrollX、mScrollY，然后触发了 invalidate，在View的onDraw()方法中会使用这两个成员变量来确定view的位置 注意这个方法的滑动方向与正常方向不同 比如如果从左向右滑动100px 那么 是scrollBy(-100,0)这两个方法有个致命的缺陷：它们滑动的是View里面的内容而不是View自身 也就是说如果用于ViewGroup中内容的滑动是可以的 但是如果用于让自身控件移动是不可以的 总结 建议优先使用LayoutParams的方式，前提是父View中只有这一个子View，否则会因margin属性的改变，导致其他子view无法正常显示 其次如果onTouch事件中实现view的移动，可以使用view.layout(l, t, r, b)方法 不是在onTouch事件中，可以使用属性动画setTranslationX 拓展贴一个跟随手指移动view的实现 1.使用layoutparams.setMargin方式（Kotlin） override fun onTouchEvent(event: MotionEvent): Boolean &#123; when (event.action) &#123; MotionEvent.ACTION_DOWN -&gt; &#123; if (null != mDragAnimSet &amp;&amp; mDragAnimSet!!.isRunning) &#123; mDragAnimSet!!.cancel() &#125; isPressed = true isDrag = false inputStartX = event.rawX.toInt() inputStartY = event.rawY.toInt() viewStartLeft = mFloatBallParams.leftMargin viewStartBottom = mFloatBallParams.bottomMargin &#125; MotionEvent.ACTION_MOVE -&gt; run &#123; val moveX: Int = event.rawX.toInt() - inputStartX val moveY: Int = event.rawY.toInt() - inputStartY if (mScreenWidth &lt; 0 || mScreenHeight &lt; 0) &#123; isDrag = false return@run &#125; if (abs(moveX) &gt; slop &amp;&amp; abs(moveY) &gt; slop) &#123; isDrag = true mFloatBallParams.leftMargin = viewStartLeft + moveX mFloatBallParams.bottomMargin = viewStartBottom - moveY layoutParams = mFloatBallParams &#125; else &#123; isDrag = false &#125; &#125; MotionEvent.ACTION_UP -&gt; &#123; if (isDrag) &#123; //恢复按压效果 isPressed = false &#125; //吸附贴边计算和动画 welt() &#125; else -&gt; &#123; &#125; &#125; return isDrag || super.onTouchEvent(event)&#125; 2.使用view.layout()方式 @Overridepublic boolean onTouch(View view, MotionEvent event) &#123; float dx, dy; switch (event.getAction()) &#123; case MotionEvent.ACTION_DOWN: startTouchX = event.getX(); startTouchY = event.getY(); circleImageLeft = circleImage.getLeft(); circleImageRight = circleImage.getRight(); break; case MotionEvent.ACTION_MOVE: dx = event.getX() - startTouchX; dy = event.getY() - startTouchY;/* 注意： 1. 这里不要用 (circleImage.getLeft() + dx)，因为每次layout之后已经改变了left的值，因此getLeft是已经更新后的值，这样将会导致dx全部累计，滑动使得view滑动的更快。 2. 一定要记得right也要跟着变，否则right不变的话，view将会被压缩或者拉伸。*/ circleImage.layout((int) (circleImageLeft + dx), circleImage.getTop(), (int) (circleImageRight + dx), circleImage.getBottom()); break; case MotionEvent.ACTION_UP: AppLog.e(\"ACTION_UP\"); break; case MotionEvent.ACTION_CANCEL: AppLog.e(\"ACTION_CANCEL\"); break; &#125; return true;&#125; MotionEvent.getX()、MotionEvent.getRawX()的区别MotionEvent的getX(),getY()是当前触摸点相对于设置此监听触摸事件的view的左边和顶部的距离。只有MotionEvent的getRawX(),getRawY()是绝对坐标。 getGlobalVisibleRect() 与 getLocalVisibleRect() 方法介绍getGlobalVisibleRect() 是view可见区域相对与屏幕来说的坐标位置.getLocalVisibleRect() 是view可见区域相对于自己坐标的位置. 一定要记清楚是可见区域. 详情查阅这篇文章 ：https://www.jianshu.com/p/2aa908f6a2e6 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/08/07/view-scroll-apis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"view scroll","slug":"view-scroll","permalink":"http://agehua.github.io/tags/view-scroll/"}]},{"title":"自定义gradle插件","slug":"gradle-plugin","date":"2021-07-17T16:00:00.000Z","updated":"2024-12-05T09:41:25.325Z","comments":true,"path":"2021/07/18/gradle-plugin/","link":"","permalink":"http://agehua.github.io/2021/07/18/gradle-plugin/","excerpt":"gradle和gradlew的区别如果配置好了 gradle 环境变量后,就可以在cmd中使用gradle命令了在cmd中输入： gradle -v","text":"gradle和gradlew的区别如果配置好了 gradle 环境变量后,就可以在cmd中使用gradle命令了在cmd中输入： gradle -v输出如下:------------------------------------------------------------Gradle 5.6.4------------------------------------------------------------ 但是有时候没有配置环境变量，却在Android项目根目录使用 gradlew 命令./gradlew -v 输出的版本和gradle-wrapper.properties文件中的版本一致 其实 gradlew是 gradle wrapper 的简写。Gradle wrapper 是Gradle的核心特性，能够让机器在没有安装Gradle运行时的情况下运行Gradle构建，也可以让构建脚本运行在一个指定的Gradle版本上。使用Wrapper被认为是最佳实践，这样在不同的机器上面，构建的版本就能够保证统一。使用了包装器的Gradle脚本非常适合作为自动化发布的一部分，比如持续集成。 我们每个Android项目的根目录下都有一个 gradlew的可执行文件，./gradlew 正是访问的这个文件 Gradle构建块每个Gradle构建都包含三个基本构建块：project、task、property。每个构建至少包含一个project，进而包含一个或者多个task。project和task暴露的属性可以用来控制构建。 Gradle使用的是领域驱动设计（DDD）的原理为其自己的领域构建软件建模。因此，在Gradle API中有相应的类来表示project和task。 Gradle API中有相应的类来表示project和task。这一点是要明确的，Gradle中的脚本实际上是转为代码来执行的。 项目Project在Gradle术语中，一个项目（project）代表一个正在构建的组件，比如一个JAR文件，或一个想要完成的目标，如部署应用程序。当构建进程启动后，Gradle基于build.gradle中的配置实例化org.gradle.api.Project接口，并且能够通过project变量使其隐式可用。 关于 Project 的介绍可以看这里: https://www.jianshu.com/p/434eba22561e 任务Task任务动作 task action，定义了一个当任务执行时最小的工作单元。任务依赖 task dependency，很多时候运行一个task之前需要运行另一个task。Gradle task对应的API是org.gradle.api.Task 接口。 关于 task更多的介绍可以看这里 https://www.jianshu.com/p/60bf794cdf91 属性 Property每个Project和Task实例都提供了可以通过getter和setter方法访问的属性。一个属性可能是一个任务的描述或者项目的版本。你也可以定义自己的属性。Gradle允许用户通过扩展属性自定义一些标量 Gradle 插件分类Gradle插件分为两类： 脚本插件，是一个普通的Gradle构建脚本，它可以被导入到其它的构建脚本中。对象插件，需要实现org.gradle.api.Plugin接口。1 使用脚本插件假设我们有一个脚本名为 sayhello.gradle ，它里面有一个task：task sayHello &lt;&lt; &#123; println 'hello world'&#125; 然后我们在build.gradle 中依赖这个外部脚本，调用Project的apply方法，apply方法调用时传入from属性，它的值可以是任何类型的URL，比如HTTP地址。apply from: 'sayhello.gradle' 此时我们运行gradle sayHello 命令，可以看到sayHello 这个task执行了：:sayHellohello world 通过apply from的方式引入脚本插件，就好像那个脚本插件中的内容是写在当前的build.gradle中一样。它是使用比较简单，这里就不多做介绍了。 对象插件我们之前讲了自定义的task，它的实现逻辑是一种可维护、可测试的解决方案。通过打包成jar文件，task可以在独立的项目中被重用。然而，该方式仍有一些限制。优点： 定制逻辑在类中是自包含的，并且可以通过增强型task配置 通过将task属性用注解标志可以支持声明式增量构建 自定义的task可以测试缺点： 自定义的task仅仅暴露独立的工作单元。所提供的额外的公式化代码、约定和生命周期的整合并不是很直接 自定义的task仅仅能通过增强型task来配置。通过自定义的DSL，缺乏有表达性的扩展机制 其他插件的功能不容易使用或扩展 而使用对象插件的方式，可以给你最大的灵活性去封装高复杂度的逻辑，并且提供一种强大的扩展机制可以在构建脚本中定制它的行为。比如编译Java代码，我们会通过一句话来引入Java插件：apply plugin :&apos;java&apos; 然后我们还可以配置很多属性来控制编译逻辑。这个Java插件就是一个对象插件。 对象插件的实现方式对于实现一个对象插件，有4个基本元素是非常重要的。 在放置插件实现的位置方面Gradle给你完全的灵活性。代码可以放在构建脚本中或者buildSrc目录下，也可以作为一个独立的工程被开发并且以jar文件方式发布。 每个插件都需要提供一个实现类，它代表着插件的入口点。插件可以用任何JVM语言编写并编译成字节码。 应用到项目中的插件可以通过暴露出来的扩展对象进行定制。如果用户想要在构建脚本中覆盖插件的默认配置时，这一点特别有用。 插件描述符是一个属性文件，它包含了关于插件的元信息。通常，它包含有插件的简短名字和插件实现类的映射。 编写插件编写一个插件最低的要求是提供org.gradle.api.Plugin&lt;T&gt;接口的一个实现类。该接口仅仅定义了一个简单的方法：apply(T target)。 现在我们来演示自定义一个插件，这个插件的作用是提供一个task来打印用户凭证。我们前面已经提到，自定义对象插件和自定义task方式类似，代码可以放在构建脚本中或者buildSrc目录下，也可以作为一个独立的工程被开发并且以JAR文件方式发布，下面我们根据这三种方式来分别演示如何自定义和使用插件。 放在构建脚本中在build.gradle中，代码如下：apply plugin:CredentialPluginuserCredential&#123; username='admin' password='000000'&#125;class CredentialPlugin implements Plugin&lt;Project&gt;&#123; @Override void apply(Project project)&#123; project.extensions.create('userCredential',CredentialExtension) project.tasks.create('printUserCredential') &lt;&lt; &#123; println \"username is: \" + project.userCredential.username println \"password is: \" + project.userCredential.password &#125; &#125;&#125;//扩展模型class CredentialExtension &#123; String username String password&#125; Gradle将语言结构化模型作为扩展，扩展可以被添加到许多Gradle对象中，如果一个类实现了org.gradle.api.plugins.ExtensionAware接口，比如Project或者Task，就认为它是扩展可知的。每个扩展都是一个数据模型，它是扩展的基础。这个模型可以是一个POJO或者Groovy Bean。 在上面的代码中，userCredential闭包中的内容，可以从构建脚本中给task提供所需要的属性值，这个userCredential就是我们暴露的一个DSL。ExtensionAware对象有一个方法getExtensions()，该方法返回一个ExtensionContainer对象，ExtensionContainer对象可以通过create()方法来注册我们的扩展，也就是把我们配置的DSL和具体的类关联起来。在本例中就是把userCredential这个闭包和CredentialExtension这个类关联起来，这就是插件的扩展机制。 扩展对象vs额外属性 被用来扩展一个对象的DSL的扩展是扩展可知的，一个已注册的扩展模型会暴露一些属性和方法，用来给构建脚本建立新的构建语言结构，这些属性名和方法在创建的时候已经定好。扩展模型的典型用例是插件。额外属性，是一些通过ext命名空间创建的简单变量，它们一般提供给用户空间也就是构建脚本使用，额外属性的属性名是可以任意指定的。请尽量避免在插件实现中使用额外属性。 放在buildSrc目录下与自定义task一样，Groovy代码放在buildSrc/src/main/groovy 目录下，package com.sososeen.credentialimport org.gradle.api.Pluginimport org.gradle.api.Projectclass CredentialPlugin implements Plugin&lt;Project&gt;&#123; @Override void apply(Project project)&#123; ... &#125;&#125;package com.sososeen.credentialclass CredentialExtension &#123; ...&#125; 在与buildSrc同级的目录下，创建build.gradle脚本，引入这个plugin：apply plugin:com.sososeen.credential.CredentialPluginuserCredential&#123; username='admin' password='000000'&#125; 然后执行 gradle printUserCredential 命令，可以看到打印结果：:printUserCredentialusername is: adminpassword is: 000000 可以看到，我们引入这个插件的时候是把它的包名带类名写上了，这显得太长了，不好写。我们可以给这个插件一个有意义且精简的名字。在src/main/resources/META-INF/gradle-plugins目录下，我们可以创建一个属性文件来配置。比如创建一个credentials.properties，它就是一个插件描述符，暴露了插件名字是credentials。在这个文件中，将该插件类的全局类名赋值给键implemention-class，如下：implementation-class = com.sososeen.credential.CredentialPlugin 然后应用插件就可以这样子：apply plugin : 'credentials' 执行 gradle printUserCredential 命令，可以看到打印结果与之前一样。 以jar文件形式提供插件这个步骤与自定义task打包为jar文件一样，新建一个项目，把buildSrc目录下的文件复制过来，同时，在该项目下创建一个build.gradle文件。apply plugin: 'groovy' //应用这个插件来编译Groovy代码apply plugin: 'maven'version = '1.0'group = 'com.sososeen09'archivesBaseName = 'credential'repositories &#123; mavenCentral()&#125;dependencies &#123; // 使用Gradle中的API需要这个 compile gradleApi()&#125;uploadArchives &#123; repositories &#123; mavenDeployer &#123; repository(url: \"file:../lib\") &#125; &#125;&#125; 执行gradle uploadArchives命令后就可以看到，在与当前项目同级的lib文件目录中生成了我们期望的jar文件。 我们再新建一个工程，这个工程中有一个脚本文件build.gradle:apply plugin : 'credentials'buildscript &#123; repositories &#123; maven &#123; url 'file:../lib' &#125; &#125; dependencies &#123; classpath 'com.sososeen09:credential:1.0' &#125;&#125;userCredential&#123; username='admin' password='000000'&#125; 执行 gradle printUserCredential 命令，可以看到打印结果与之前一样。 REFhttps://www.jianshu.com/p/158851436e82 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/07/18/gradle-plugin/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gradle","slug":"gradle","permalink":"http://agehua.github.io/tags/gradle/"},{"name":"AGP","slug":"agp","permalink":"http://agehua.github.io/tags/agp/"}]},{"title":"RecyclerView 缓存机制","slug":"recyclerview-cache","date":"2021-07-17T16:00:00.000Z","updated":"2024-12-05T09:41:25.323Z","comments":true,"path":"2021/07/18/recyclerview-cache/","link":"","permalink":"http://agehua.github.io/2021/07/18/recyclerview-cache/","excerpt":"RecyclerView 内存性能优越，这得益于它独特的缓存机制\n由问题引入\n回收的是什么？复用什么？\n回收到哪里去？从哪里获得复用？\n什么时候回收？什么时候复用？","text":"RecyclerView 内存性能优越，这得益于它独特的缓存机制 由问题引入 回收的是什么？复用什么？ 回收到哪里去？从哪里获得复用？ 什么时候回收？什么时候复用？ 从addView()开始RecyclerView继承自 ViewGroup，遂以RecyclerView.addView()为切入点向上搜寻复用的代码。在RecyclerView.java中全局搜索“addView”，发现RecyclerView()并没有对addView()函数重载，但找到一处addView()的调用： //RecyclerView是ViewGroup的子类public class RecyclerView extends ViewGroup implements ScrollingView, NestedScrollingChild2 &#123; ... private void initChildrenHelper() &#123; mChildHelper = new ChildHelper(new ChildHelper.Callback() &#123; ... @Override public void addView(View child, int index) &#123; if (VERBOSE_TRACING) &#123; TraceCompat.beginSection(\"RV addView\"); &#125; //直接调用ViewGroup.addView() RecyclerView.this.addView(child, index); if (VERBOSE_TRACING) &#123; TraceCompat.endSection(); &#125; dispatchChildAttached(child); &#125; &#125; &#125; ...&#125; 以ChildHelper.Callback.addView()为起点沿着调用链继续向上搜寻，经历了如下方法调用： ChildHelper.addView() LayoutManager.addViewInt() LayoutManager.addView() LinearLayoutManager.layoutChunk()： void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) &#123; //获得下一个表项 View view = layoutState.next(recycler); ... LayoutParams params = (LayoutParams) view.getLayoutParams(); if (layoutState.mScrapList == null) &#123; //将表项插入到列表中 if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) &#123; addView(view); &#125; else &#123; addView(view, 0); &#125; &#125; ...&#125; addView(view)中传入的view是函数layoutState.next()的返回值。猜测该函数是用来获得下一个表项的。表项不止一个，应该有一个循环不断的获得下一个表项才对。果然layoutChunk在 fill() 方法的 while 循环中被调用 public class LinearLayoutManager extends RecyclerView.LayoutManager implements ItemTouchHelper.ViewDropHandler, RecyclerView.SmoothScroller.ScrollVectorProvider &#123; ... int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) &#123; ... //recyclerview 剩余空间 int remainingSpace = layoutState.mAvailable + layoutState.mExtra; LayoutChunkResult layoutChunkResult = mLayoutChunkResult; //不断填充，直到空间消耗完毕 while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; layoutChunkResult.resetInternal(); if (VERBOSE_TRACING) &#123; TraceCompat.beginSection(\"LLM LayoutChunk\"); &#125; //填充一个表项 layoutChunk(recycler, state, layoutState, layoutChunkResult); ... &#125; ... &#125;&#125; 而fill()是在onLayoutChildren()中被调用：/** * Lay out all relevant child views from the given adapter. * 布局所有给定adapter中相关孩子视图 */public void onLayoutChildren(Recycler recycler, State state) &#123; Log.e(TAG, \"You must override onLayoutChildren(Recycler recycler, State state) \");&#125; 看完注释，感觉前面猜测应该是正确的。onLayoutChildren()是用来布局RecyclerView中所有的表项的。 回头去看一下layoutState.next()，表项复用逻辑应该就在其中.public class LinearLayoutManager &#123; static class LayoutState &#123; /** * Gets the view for the next element that we should layout. * 获得下一个元素的视图用于布局 */ View next(RecyclerView.Recycler recycler) &#123; if (mScrapList != null) &#123; return nextViewFromScrapList(); &#125; //调用了Recycler.getViewForPosition() final View view = recycler.getViewForPosition(mCurrentPosition); mCurrentPosition += mItemDirection; return view; &#125; &#125;&#125; 最终调用了Recycler.getViewForPosition()，Recycler是回收器的意思，感觉离想要找的“复用”逻辑越来越近了。 Recycler到底是做什么用的？public class RecyclerView &#123; /** * A Recycler is responsible for managing scrapped or detached item views for reuse. * Recycler负责管理scrapped和detached表项的复用 */ public final class Recycler &#123; ... &#125;&#125; 终于找到你~~ ，Recycler用于表项的复用！沿着Recycler.getViewForPosition()的调用链继续向下搜寻，找到了一个关键函数（函数太长了，为了防止头晕，只列出了关键节点）public class RecyclerView &#123; public final class Recycler &#123; /** * Attempts to get the ViewHolder for the given position, either from the Recycler scrap, * cache, the RecycledViewPool, or creating it directly. * 尝试获得指定位置的ViewHolder，要么从scrap，cache，RecycledViewPool中获取，要么直接重新创建 */ @Nullable ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... boolean fromScrapOrHiddenOrCache = false; ViewHolder holder = null; //0 从changed scrap集合中获取ViewHolder if (mState.isPreLayout()) &#123; holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; &#125; //1. 通过position从attach scrap或一级回收缓存中获取ViewHolder if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); ... &#125; if (holder == null) &#123; ... final int type = mAdapter.getItemViewType(offsetPosition); //2. 通过id在attach scrap集合和一级回收缓存中查找viewHolder if (mAdapter.hasStableIds()) &#123; holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition), type, dryRun); ... &#125; //3. 从自定义缓存中获取ViewHolder if (holder == null &amp;&amp; mViewCacheExtension != null) &#123; // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension .getViewForPositionAndType(this, position, type); ... &#125; //4.从缓存池中拿ViewHolder if (holder == null) &#123; // fallback to pool ... holder = getRecycledViewPool().getRecycledView(type); ... &#125; //所有缓存都没有命中，只能创建ViewHolder if (holder == null) &#123; ... holder = mAdapter.createViewHolder(RecyclerView.this, type); ... &#125; &#125; boolean bound = false; if (mState.isPreLayout() &amp;&amp; holder.isBound()) &#123; // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; &#125; //只有invalid的viewHolder才能绑定视图数据 else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; final int offsetPosition = mAdapterHelper.findPositionOffset(position); //获得ViewHolder后，绑定视图数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125; ... return holder; &#125; &#125;&#125; 函数的名字以“tryGet”开头，“尝试获得”表示可能获得失败，再结合注释中说的：“尝试获得指定位置的ViewHolder，要么从scrap，cache，RecycledViewPool中，要么直接重新创建。”猜测scrap，cache，RecycledViewPool是回收表项的容器，相当于表项缓存，如果缓存未命中则只能重新创建。 函数的返回值是ViewHolder，难道回收和复用的是ViewHolder? 函数开头声明了局部变量ViewHolder holder = null;最终返回的也是这个局部变量，并且有4处holder == null的判断，这样的代码结构是不是有点像缓存？每次判空意味着上一级缓存未命中并继续尝试新的获取方法？缓存是不是有不止一种存储形式？ 让我们一次一次地看： 第一次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (mState.isPreLayout()) &#123; holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; &#125; ...&#125; 只有在mState.isPreLayout()为true时才会做这次尝试，这应该是一种特殊情况，先忽略。 第二次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); //下面一段代码蕴含着一个线索，买个伏笔，先把他略去 ... &#125; ...&#125; 当第一次尝试失败后，尝试通过getScrapOrHiddenOrCachedHolderForPosition()获得ViewHolder。这里故意省略了一段代码，先埋个伏笔，待会分析。先沿着获取ViewHolder的调用链继续往下：//省略非关键代码 /** * Returns a view for the position either from attach scrap, hidden children, or cache. * 从attach scrap，hidden children或者cache中获得指定位置上的一个ViewHolder */ ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) &#123; final int scrapCount = mAttachedScrap.size(); // Try first for an exact, non-invalid match from scrap. //1.在attached scrap中搜索ViewHolder for (int i = 0; i &lt; scrapCount; i++) &#123; final ViewHolder holder = mAttachedScrap.get(i); if (!holder.wasReturnedFromScrap() &amp;&amp; holder.getLayoutPosition() == position &amp;&amp; !holder.isInvalid() &amp;&amp; (mState.mInPreLayout || !holder.isRemoved())) &#123; holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP); return holder; &#125; &#125; //2.从移除屏幕的视图中搜索ViewHolder，找到了之后将他存入scrap回收集合中 if (!dryRun) &#123; View view = mChildHelper.findHiddenNonRemovedView(position); if (view != null) &#123; final ViewHolder vh = getChildViewHolderInt(view); mChildHelper.unhide(view); int layoutIndex = mChildHelper.indexOfChild(view); ... mChildHelper.detachViewFromParent(layoutIndex); scrapView(view); vh.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP | ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST); return vh; &#125; &#125; // Search in our first-level recycled view cache. //3.在缓存中搜索ViewHolder final int cacheSize = mCachedViews.size(); for (int i = 0; i &lt; cacheSize; i++) &#123; final ViewHolder holder = mCachedViews.get(i); //若找到ViewHolder，还需要对ViewHolder的索引进行匹配判断 if (!holder.isInvalid() &amp;&amp; holder.getLayoutPosition() == position) &#123; ... return holder; &#125; &#125; return null; &#125; 依次从三个地方搜索ViewHolder：1. mAttachedScrap 2. 隐藏表项 3. mCachedViews，找到立即返回。其中mAttachedScrap和mCachedViews作为Recycler的成员变量，用来存储一组ViewHolder：public final class Recycler &#123; final ArrayList&lt;ViewHolder&gt; mAttachedScrap = new ArrayList&lt;&gt;(); ... final ArrayList&lt;ViewHolder&gt; mCachedViews = new ArrayList&lt;ViewHolder&gt;(); ... RecycledViewPool mRecyclerPool;&#125; 看到这里应该可以初步得出结论：RecyclerView回收机制中，回收复用的对象是ViewHolder，且以ArrayList为结构存储在Recycler对象中。 RecycledViewPool mRecyclerPool; 看着也像是回收容器，那待会是不是也会到这里拿 ViewHolder? 值得注意的是，当成功从mCachedViews中获取ViewHolder对象后，还需要对其索引进行判断，这就意味着 mCachedViews中缓存的ViewHolder只能复用于指定位置 ，打个比方：手指向上滑动，列表向下滚动，第2个表项移出屏幕，第4个表项移入屏幕，此时再滑回去，第2个表项再次出现，这个过程中第4个表项不能复用被回收的第2个表项的ViewHolder，因为他们的位置不同，而再次进入屏幕的第2个表项就可以成功复用。 待会可以对比一下其他复用是否也需要索引判断 回到刚才埋下的伏笔，把第二次尝试获取ViewHolder的代码补全：ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); //下面一段代码蕴含这一个线索，买个伏笔，先把他略去 if (holder != null) &#123; //检验ViewHolder有效性 if (!validateViewHolderForOffsetPosition(holder)) &#123; // recycle holder (and unscrap if relevant) since it can not be used if (!dryRun) &#123; // we would like to recycle this but need to make sure it is not used by // animation logic etc. holder.addFlags(ViewHolder.FLAG_INVALID); if (holder.isScrap()) &#123; removeDetachedView(holder.itemView, false); holder.unScrap(); &#125; else if (holder.wasReturnedFromScrap()) &#123; holder.clearReturnedFromScrapFlag(); &#125; //若不满足有效性检验，则回收ViewHolder recycleViewHolderInternal(holder); &#125; holder = null; &#125; else &#123; fromScrapOrHiddenOrCache = true; &#125; &#125; &#125; ...&#125; 如果成功获得ViewHolder则检验其有效性，若检验失败则将其回收。好不容易获取了ViewHoler对象，一言不合就把他回收？难道对所有复用的 ViewHolder 都有这么严格的检验吗？ 暂时无法回答这些疑问，还是先把复用逻辑看完吧： 第三次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... //只有当Adapter设置了id，才会进行这次查找 if (mAdapter.hasStableIds()) &#123; holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),type, dryRun); if (holder != null) &#123; // update position holder.mPosition = offsetPosition; fromScrapOrHiddenOrCache = true; &#125; &#125; ...&#125; 这一次尝试调用的函数名（“byId”）和上一次（“byPosition”）只是后缀不一样。上一次是通过表项位置，这一次是通过表项id。内部实现也几乎一样，判断的依据从表项位置变成表项id。为表项设置id属于特殊情况，先忽略。 第四次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null &amp;&amp; mViewCacheExtension != null) &#123; // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension.getViewForPositionAndType(this, position, type); if (view != null) &#123; //获得view对应的ViewHolder holder = getChildViewHolder(view); if (holder == null) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view which does not have a ViewHolder\" + exceptionLabel()); &#125; else if (holder.shouldIgnore()) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view that is ignored. You must call stopIgnoring before\" + \" returning this view.\" + exceptionLabel()); &#125; &#125; &#125; ...&#125; 经过从mAttachedScrap和mCachedViews获取ViewHolder未果后，继续尝试通过ViewCacheExtension 获取：/** * ViewCacheExtension is a helper class to provide an additional layer of view caching that can * be controlled by the developer. * ViewCacheExtension提供了额外的表项缓存层，用户帮助开发者自己控制表项缓存 * &lt;p&gt; * When &#123;@link Recycler#getViewForPosition(int)&#125; is called, Recycler checks attached scrap and * first level cache to find a matching View. If it cannot find a suitable View, Recycler will * call the &#123;@link #getViewForPositionAndType(Recycler, int, int)&#125; before checking * &#123;@link RecycledViewPool&#125;. * 当Recycler从attached scrap和first level cache中未能找到匹配的表项时，它会在去RecycledViewPool中查找之前，先尝试从自定义缓存中查找 * &lt;p&gt; */public abstract static class ViewCacheExtension &#123; /** * Returns a View that can be binded to the given Adapter position. * &lt;p&gt; * This method should &lt;b&gt;not&lt;/b&gt; create a new View. Instead, it is expected to return * an already created View that can be re-used for the given type and position. * If the View is marked as ignored, it should first call * &#123;@link LayoutManager#stopIgnoringView(View)&#125; before returning the View. * &lt;p&gt; * RecyclerView will re-bind the returned View to the position if necessary. */ public abstract View getViewForPositionAndType(Recycler recycler, int position, int type);&#125; 注释揭露了很多信息：ViewCacheExtension用于开发者自定义表项缓存，且这层缓存的访问顺序位于mAttachedScrap和mCachedViews之后，RecycledViewPool 之前。这和Recycler.tryGetViewHolderForPositionByDeadline()中的代码逻辑一致，那接下来的第五次尝试，应该是从 RecycledViewPool 中获取 ViewHolder 第五次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; ... //从回收池中获取ViewHolder对象 holder = getRecycledViewPool().getRecycledView(type); if (holder != null) &#123; holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) &#123; invalidateDisplayListInt(holder); &#125; &#125; &#125; ...&#125; 前四次尝试都未果，最后从RecycledViewPool 中获取ViewHolder。稍等片刻！相对于从mAttachedScrap 和 mCachedViews 中获取 ViewHolder，此处并没有严格的检验逻辑。为啥要区别对待不同的缓存？ 大大的问号悬在头顶，但现在暂时无法解答，还是接着看RecycledViewPool 的结构吧~public final class Recycler &#123; ... RecycledViewPool mRecyclerPool; //获得RecycledViewPool实例 RecycledViewPool getRecycledViewPool() &#123; if (mRecyclerPool == null) &#123; mRecyclerPool = new RecycledViewPool(); &#125; return mRecyclerPool; &#125; ...&#125;public static class RecycledViewPool &#123; ... //从回收池中获取ViewHolder对象 public ViewHolder getRecycledView(int viewType) &#123; final ScrapData scrapData = mScrap.get(viewType); if (scrapData != null &amp;&amp; !scrapData.mScrapHeap.isEmpty()) &#123; final ArrayList&lt;ViewHolder&gt; scrapHeap = scrapData.mScrapHeap; return scrapHeap.remove(scrapHeap.size() - 1); &#125; return null; &#125; ...&#125; 函数中只要访问了类成员变量，它的复杂度就提高了，因为类成员变量的作用于超出了函数体，使得函数就和类中其他函数耦合，所以不得不进行阅读更多以帮助理解该函数： public static class RecycledViewPool &#123; //同类ViewHolder缓存个数上限 private static final int DEFAULT_MAX_SCRAP = 5; /** * Tracks both pooled holders, as well as create/bind timing metadata for the given type. * 回收池中存放单个类型ViewHolder的容器 */ static class ScrapData &#123; //同类ViewHolder存储在ArrayList中 ArrayList&lt;ViewHolder&gt; mScrapHeap = new ArrayList&lt;&gt;(); //每种类型的ViewHolder最多存5个 int mMaxScrap = DEFAULT_MAX_SCRAP; &#125; //回收池中存放所有类型ViewHolder的容器 SparseArray&lt;ScrapData&gt; mScrap = new SparseArray&lt;&gt;(); ... //ViewHolder入池 按viewType分类入池，一个类型的ViewType存放在一个ScrapData中 public void putRecycledView(ViewHolder scrap) &#123; final int viewType = scrap.getItemViewType(); final ArrayList&lt;ViewHolder&gt; scrapHeap = getScrapDataForType(viewType).mScrapHeap; //如果超限了，则放弃入池 if (mScrap.get(viewType).mMaxScrap &lt;= scrapHeap.size()) &#123; return; &#125; if (DEBUG &amp;&amp; scrapHeap.contains(scrap)) &#123; throw new IllegalArgumentException(\"this scrap item already exists\"); &#125; scrap.resetInternal(); //回收时，ViewHolder从列表尾部插入 scrapHeap.add(scrap); &#125; //从回收池中获取ViewHolder对象 public ViewHolder getRecycledView(int viewType) &#123; final ScrapData scrapData = mScrap.get(viewType); if (scrapData != null &amp;&amp; !scrapData.mScrapHeap.isEmpty()) &#123; final ArrayList&lt;ViewHolder&gt; scrapHeap = scrapData.mScrapHeap; //复用时，从列表尾部获取ViewHolder（优先复用刚入池的ViewHoler） return scrapHeap.remove(scrapHeap.size() - 1); &#125; return null; &#125;&#125; 上述代码列出了RecycledViewPool 中最关键的一个成员变量和两个函数。至此可以得出结论：RecycledViewPool中的ViewHolder存储在SparseArray中，并且按viewType分类存储（即是Adapter.getItemViewType()的返回值），同一类型的ViewHolder存放在ArrayList 中，且默认最多存储5个。 相比较于mCachedViews，从mRecyclerPool中成功获取ViewHolder对象后并没有做合法性和表项位置校验，只检验viewType是否一致。所以从mRecyclerPool中取出的ViewHolder只能复用于相同viewType的表项。 创建ViewHolder并绑定数据ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) &#123; ... //所有缓存都没有命中，只能创建ViewHolder if (holder == null) &#123; ... holder = mAdapter.createViewHolder(RecyclerView.this, type); ... &#125; ... boolean bound = false; if (mState.isPreLayout() &amp;&amp; holder.isBound()) &#123; // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; &#125; //如果表项没有绑定过数据 或 表项需要更新 或 表项无效 且表项没有被移除时绑定表项数据 else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; if (DEBUG &amp;&amp; holder.isRemoved()) &#123; throw new IllegalStateException(\"Removed holder should be bound and it should\" + \" come here only in pre-layout. Holder: \" + holder + exceptionLabel()); &#125; final int offsetPosition = mAdapterHelper.findPositionOffset(position); //为表项绑定数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125;&#125; 再进行了上述所有尝试后，如果依然没有获得ViewHolder，只能重新创建并绑定数据。沿着调用链往下，就会找到熟悉的onCreateViewHolder()和onBindViewHolder()。 绑定数据的逻辑嵌套在一个大大的if中（原来并不是每次都要绑定数据，只有满足特定条件时才需要绑定） 那什么情况下需要绑定，什么情况下不需要呢？这就要引出“缓存优先级”这个概念。 缓存优先级缓存有优先级一说，在使用图片二级缓存（内存+磁盘）时，会先尝试去优先级高的内存中获取，若未命中再去磁盘中获取。优先级越高意味着性能越好。RecyclerView的缓存机制中是否也能套用“缓存优先级”这一逻辑？ 虽然为了获取ViewHolder做了5次尝试（共从6个地方获取），先排除3种特殊情况，即从mChangedScrap获取、通过id获取、从自定义缓存获取，正常流程中只剩下3种获取方式，优先级从高到低依次是： 1.从mAttachedScrap获取 2.从mCachedViews获取 3.从mRecyclerPool 获取 这样的缓存优先级是不是意味着，对应的复用性能也是从高到低？（复用性能越好意味着所做的昂贵操作越少） 最坏情况：重新创建ViewHodler并重新绑定数据 次好情况：复用ViewHolder但重新绑定数据 最好情况：复用ViewHolder且不重新绑定数据 毫无疑问，所有缓存都未命中的情况下会发生最坏情况。剩下的两种情况应该由3种获取方式来分摊，猜测优先级最低的 mRecyclerPool 方式应该命中次好情况，而优先级最高的 mAttachedScrap 应该命中最好情况，去源码中验证一下： ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) &#123; final int scrapCount = mAttachedScrap.size(); // Try first for an exact, non-invalid match from scrap. //1.从attached scrap回收集合中 for (int i = 0; i &lt; scrapCount; i++) &#123; final ViewHolder holder = mAttachedScrap.get(i); //只有当holder是有效时才返回 if (!holder.wasReturnedFromScrap() &amp;&amp; holder.getLayoutPosition() == position &amp;&amp; !holder.isInvalid() &amp;&amp; (mState.mInPreLayout || !holder.isRemoved())) &#123; holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP); return holder; &#125; &#125;&#125;ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; ... //从回收池中获取ViewHolder对象 holder = getRecycledViewPool().getRecycledView(type); if (holder != null) &#123; //重置ViewHolder holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) &#123; invalidateDisplayListInt(holder); &#125; &#125; &#125; ... //如果表项没有绑定过数据 或 表项需要更新 或 表项无效 且表项没有被移除时绑定表项数据 else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; if (DEBUG &amp;&amp; holder.isRemoved()) &#123; throw new IllegalStateException(\"Removed holder should be bound and it should\" + \" come here only in pre-layout. Holder: \" + holder + exceptionLabel()); &#125; final int offsetPosition = mAdapterHelper.findPositionOffset(position); //为表项绑定数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125; ...&#125;public abstract static class ViewHolder &#123; /** * This ViewHolder has been bound to a position; mPosition, mItemId and mItemViewType * are all valid. * 绑定标志位 */ static final int FLAG_BOUND = 1 &lt;&lt; 0; /** * This ViewHolder’s data is invalid. The identity implied by mPosition and mItemId * are not to be trusted and may no longer match the item view type. * This ViewHolder must be fully rebound to different data. * 无效标志位 */ static final int FLAG_INVALID = 1 &lt;&lt; 2; //判断ViewHolder是否无效 boolean isInvalid() &#123; //将当前ViewHolder对象的flag和无效标志位做位与操作 return (mFlags &amp; FLAG_INVALID) != 0; &#125; //判断ViewHolder是否被绑定 boolean isBound() &#123; //将当前ViewHolder对象的flag和绑定标志位做位与操作 return (mFlags &amp; FLAG_BOUND) != 0; &#125; /** * 将ViewHolder重置 */ void resetInternal() &#123; //将ViewHolder的flag置0 mFlags = 0; mPosition = NO_POSITION; mOldPosition = NO_POSITION; mItemId = NO_ID; mPreLayoutPosition = NO_POSITION; mIsRecyclableCount = 0; mShadowedHolder = null; mShadowingHolder = null; clearPayload(); mWasImportantForAccessibilityBeforeHidden = ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_AUTO; mPendingAccessibilityState = PENDING_ACCESSIBILITY_STATE_NOT_SET; clearNestedRecyclerViewIfNotNested(this); &#125;&#125; 温故知新，回看 mRecyclerPool 复用逻辑时，发现在成功获得ViewHolder对象后，立即对其重置（将flag置0）。这样就满足了绑定数据的判断条件（因为0和非0位与之后必然为0）。 同样的，在才mAttachedScrap中获取ViewHolder时，只有当其是有效的才会返回。所以猜测成立：从mRecyclerPool中复用的ViewHolder需要重新绑定数据，从mAttachedScrap 中复用的ViewHolder不要重新出创建也不需要重新绑定数据。 总结 在 RecyclerView 中，并不是每次绘制表项，都会重新创建 ViewHolder 对象，也不是每次都会重新绑定 ViewHolder 数据。 RecyclerView 通过Recycler获得下一个待绘制表项。 Recycler有4个层次用于缓存 ViewHolder 对象，优先级从高到底依次为 ArrayList&lt;ViewHolder&gt; mAttachedScrap、 ArrayList&lt;ViewHolder&gt; mCachedViews、 ViewCacheExtension mViewCacheExtension、 RecycledViewPool mRecyclerPool。 如果四层缓存都未命中，则重新创建并绑定 ViewHolder 对象。 RecycledViewPool 对 ViewHolder 按viewType分类存储（通过SparseArray），同类 ViewHolder 存储在默认大小为5的ArrayList中。 从mRecyclerPool中复用的 ViewHolder 需要重新绑定数据，从mAttachedScrap 中复用的 ViewHolder 不需要重新创建也不需要重新绑定数据。 从mRecyclerPool中复用的ViewHolder ，只能复用于viewType相同的表项，从mCachedViews中复用的 ViewHolder ，只能复用于指定位置的表项。 mCachedViews是离屏缓存，用于缓存指定位置的 ViewHolder ，只有“列表回滚”这一种场景（刚滚出屏幕的表项再次进入屏幕），才有可能命中该缓存。该缓存存放在默认大小为 2 的ArrayList中。 这篇文章粗略的回答了关于“复用”的4个问题，即“复用什么？”、“从哪里获得复用？”、“什么时候复用？”、“复用优先级”。读到这里，可能会有很多疑问： 预布局、预测动画是什么？关于预测动画和预布局的介绍，可以看这篇文章：深入理解 RecyclerView 的缓存机制 RecyclerView的滚动和回收机制：RecyclerView之所以能滚动，就是因为它在监听到手指滑动之后，不断地更新Item的位置，也就是反复layout子View了，这部分工作由LayoutManager负责。 LayoutManager在layout子View之前，会先把RecyclerView的每个子View所对应的ViewHolder都放到mAttachedScrap中，然后根据当前滑动距离，筛选出哪些Item需要layout。获取子View对象，会通过getViewForPosition方法来获取。这个方法就是题目中说的那样：先从mAttachedScrap中找，再…… Item布局完成之后，会对刚刚没有再次布局的Item进行缓存（回收），这个缓存分两种： 取出（即将重用）时无须重新绑定数据（即不用执行onBindViewHolder方法）。这种缓存只适用于特定position的Item（名花有主）； 取出后会回调onBindViewHolder方法，好让对应Item的内容能正确显示。这种缓存适用所有同类型的Item（云英未嫁）；第一种缓存，由Recycler.mCachedViews来保管，第二种放在RecycledViewPool中。 如果回收的Item它的状态（包括：INVALID、REMOVED、UPDATE、POSITION_UNKNOWN）没有变更，就会放到mCachedViews中，否则扔RecycledViewPool里。 emmmm，除了滚动过程中，会对Item进行回收和重新布局，还有一种就是，当Adapter数据有更新时： Inserted：如果刚好插入在屏幕可见范围内，会从RecycledViewPool中找一个相同类型的ViewHolder（找不到就create）来重新绑定数据并layout； Removed：会把对应ViewHolder扔到mAttachedScrap中并播放动画，动画播放完毕后移到RecycledViewPool里； Changed：这种情况并不是大家所认为的：直接将这个ViewHolder传到Adapter的onBindViewHolder中重新绑定数据。而是先把旧的ViewHolder扔mChangedScrap中，然后像Inserted那样从RecycledViewPool中找一个相同类型的ViewHolder来重新绑定数据。旧ViewHolder对象用来播放动画，动画播完，同样会移到RecycledViewPool里； 注意：如果是使用notifyDataSetChanged方法来通知更新的话，那么所有Item都会直接扔RecycledViewPool中，然后逐个重新绑定数据的。 这几个存放缓存的集合，各自的作用以及使用场景？ mAttachedScrap：LayoutManager每次layout子View之前，那些已经添加到RecyclerView中的Item以及被删除的Item的临时存放地。使用场景就是RecyclerView滚动时、还有在可见范围内删除Item后用notifyItemRemoved方法通知更新时； mChangedScrap：作用：存放可见范围内有更新的Item。使用场景：可见范围内的Item有更新，并且使用notifyItemChanged方法通知更新时； mCachedViews：作用：存放滚动过程中没有被重新使用且状态无变化的那些旧Item。场景：滚动，prefetch； RecycledViewPool：作用：缓存Item的最终站，用于保存那些Removed、Changed、以及mCachedViews满了之后更旧的Item。场景：Item被移除、Item有更新、滚动过程； 写到这里发现漏讲了一个prefetch，好吧，这个prefetch机制就是RecyclerView在滚动和惯性滚动的时候，借助Handler来事先从RecycledViewPool中取出即将要显示的Item，随即扔到mCachedViews中，这样的话，当layout到这个Item时，就能直接拿来用而不用绑定数据了。 Ref深入理解 RecyclerView 的缓存机制 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/07/18/recyclerview-cache/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"ANR 总结与分析","slug":"ANR-summary","date":"2021-06-06T16:00:00.000Z","updated":"2024-12-05T09:41:25.323Z","comments":true,"path":"2021/06/07/ANR-summary/","link":"","permalink":"http://agehua.github.io/2021/06/07/ANR-summary/","excerpt":"ANR 分类Android ANR问题分为三类：Input，Receiver，Service\n在我们常见的APP开发中，主要遇到的都是Input超时问题，本文就详细分析下Input超时是如何产生以及如何排查","text":"ANR 分类Android ANR问题分为三类：Input，Receiver，Service 在我们常见的APP开发中，主要遇到的都是Input超时问题，本文就详细分析下Input超时是如何产生以及如何排查在分析Input超时之前，我们先来简单的介绍一下Android的Input系统。Android Input体系中，大致有两种类型的事件，实体按键key事件，屏幕点击触摸事件，当然如果根据事件类型的不同我们还能细分为基础实体按键的key(power，volume up/down，recents，back，home)，实体键盘按键，屏幕点击(多点，单点)，屏幕滑动等等的事件。在Android整个Input体系中有三个格外重要的成员：Eventhub，InputReader，InputDispatcher。它们分别担负着各自不同的职责，Eventhub负责监听/dev/input产生Input事件，InputReader负责从Eventhub读取事件，并将读取的事件发给InputDispatcher，InputDispatcher则根据实际的需要具体分发给当前手机获得焦点实际的Window。当然它们三者之间有工作远比我介绍的要复杂的很多。 详细源码可以参考：Input系统—ANR原理分析 要产生 ANR，至少得有两个输入事件，场景如下： 第一个输入事件产生，系统将其发送给用户当前操作的 App； 系统收到第二个事件，发现当前距第一个输入事件发送时间超过 0.5s 仍未处理完毕，则设置一个定时器，5s 后触发； 5s 之后，若系统发现第一个输入事件仍然没有回应时，则触发 ANR，激活 App 中的 Signal Cather 线程生成 traces.txt，然后弹出 ANR 对话框，告知用户 App 无响应。 也就是说，要产生 ANR，第一个输入事件必需在 5.5s 以上没有被处理完成并反馈回系统；并且要有第二个输入事件产生。如果没有第二个输入事件，即便第一个输入事件执行了 60s 或更长时间，也是不会产生 ANR 的。 ANR 产生原因Input ANR reason主要有以下几类： 无窗口, 有应用：Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up. 窗口暂停: Waiting because the [targetType] window is paused. 窗口未连接: Waiting because the [targetType] window’s input channel is not registered with the input dispatcher. The window may be in the process of being removed. 窗口连接已死亡：Waiting because the [targetType] window’s input connection is [Connection.Status]. The window may be in the process of being removed. 窗口连接已满：Waiting because the [targetType] window’s input channel is full. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度]. 按键事件，输出队列或事件等待队列不为空：Waiting to send key event because the [targetType] window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度]. 非按键事件，事件等待队列不为空且头事件分发超时500ms：Waiting to send non-key event because the [targetType] window has not finished processing certain input events that were delivered to it over 500ms ago. Wait queue length: [waitQueue长度]. Wait queue head age: [等待时长]. 其中 targetType: 取值为”focused”或者”touched” Connection.Status: 取值为”NORMAL”，”BROKEN”，”ZOMBIE” 实例分析，Reason: Waiting because the focused window is paused.最近遇到这个问题，但是没有trace文件可以分析，只有logcat和dumpsys文件。下面利用这两个文件尝试分析下如何定位这类ANR先看下logcat内容 step1, 在logcat中搜索 Application is not responding，并确认这条日志的时间点：06-01 04:38:39.160 // 第一步搜索 Application is not responding06-01 04:38:39.160 1457 1669 I InputDispatcher: Application is not responding: AppWindowToken&#123;b7d5d7c token=Token&#123;5a5c6f ActivityRecord&#123;12f034e u0 com.xxx/.MainActivity t4569&#125;&#125;&#125; - Window&#123;703780b u0 cxxx/xxx.xActivity&#125;. It has been 5008.2ms since event, 5003.2ms since wait started. Reason: Waiting because the focused window is paused. step2, ANR属于InputDispatcher类型，向前选5s，大概在 06-01 04:38:34的时间点 step3, 在上一步的时间点，看看有没有到对应的input事件，找到了： 06-01 04:38:34.151 23143 23143 D AndroidRuntime: Calling main entry com.android.commands.input.Input06-01 04:38:34.152 23143 23143 I Input : injectKeyEvent: KeyEvent &#123; action=ACTION_DOWN, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=2108288622, downTime=2108288622, deviceId=-1, source=0x101 &#125; step4, 根据事件，猜测是点击返回时发生了ANR， step5, 搜索关键字 ANR in，查看CPU占用，发现CPU占用过高 06-01 04:38:49.302 1457 23156 E ActivityManager: ANR in xxx (xxx/.x,xActivity)06-01 04:38:49.302 1457 23156 E ActivityManager: PID: 1883306-01 04:38:49.302 1457 23156 E ActivityManager: Reason: Input dispatching timed out (Waiting because the focused window is paused.), happend at time = 2108297657@#@1883306-01 04:38:49.302 1457 23156 E ActivityManager: Load: 0.0 / 0.0 / 0.006-01 04:38:49.302 1457 23156 E ActivityManager: CPU usage from 105ms to -6001ms ago:06-01 04:38:49.302 1457 23156 E ActivityManager: 131% 18833/xxx: 30% user + 100% kernel / faults: 19725 minor 18 major06-01 04:38:49.302 1457 23156 E ActivityManager: 33% 19724/com.android.commands.monkey: 29% user + 3.6% kernel / faults: 5507 minor 1 major06-01 04:38:49.302 1457 23156 E ActivityManager: 20% 1457/system_server: 12% user + 8.3% kernel / faults: 1084 minor 7 major06-01 04:38:49.302 1457 23156 E ActivityManager: 10% 452/surfaceflinger: 3.9% user + 6% kernel / faults: 45 minor 虽然现在手机基本都是多核CPU，比如4核的话，CPU上线是 400%。但App正常使用时，单个CPU占用应该不超过100%。到这里猜测，在点击按钮返回时，页面刷新App CPU占用过高，导致ANR，此时对应Activity的onPause和onResume两个生命周期， 在分析一下为什么ANR 原因是 Input dispatching timed out (Waiting because the focused window is paused.) 查看 dumpsys 文件在 dumpsys 文件中搜索 Input Dispatcher，找到下面的内容，注释内容是我自己添加的，便于理解Input Dispatcher State at time of last ANR: ANR: Time: 2021-06-01 04:38:39 // 这里时间跟 step1 的时间一致 Window: AppWindowToken&#123;b7d5d7c token=Token&#123;5a5c6f ActivityRecord&#123;12f034e u0 xxx/.xxxActivity t4569&#125;&#125;&#125; - Window&#123;703780b u0 xxx/xxx.xActivity&#125; // 注意上面的 Window&#123;703780b ... DispatchLatency: 5008.2ms WaitDuration: 5003.2ms Reason: Waiting because the focused window is paused. DispatchEnabled: 1 DispatchFrozen: 0 FocusedApplication: name='AppWindowToken&#123;b7d5d7c token=Token&#123;5a5c6f ActivityRecord&#123;12f034e u0 xxx/.xxxActivity t4569&#125;&#125;&#125;', dispatchingTimeout=5000.000ms FocusedWindow: name='Window&#123;703780b u0 xxx/xxx.xActivity&#125;' TouchStates: &lt;no displays touched&gt; Windows: //.... 省略 // 根据 703780b 找到对应的window，同时发现有两个window状态是 paused，但Window&#123;6dfcc50 hasFocus=false 暂不考虑 8: name='Window&#123;6dfcc50 u0 PopupWindow:408c8f7&#125;', displayId=0, paused=true, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x41800008, type=0x000003e8, layer=21020, frame=[223,149][474,208], scale=1.000000, touchableRegion=[223,149][474,208], inputFeatures=0x00000000, ownerPid=18833, ownerUid=13560, dispatchingTimeout=5000.000ms // Window&#123;703780b paused=true 9: name='Window&#123;703780b u0 xxx/xxx.xActivity&#125;', displayId=0, paused=true, hasFocus=true, hasWallpaper=false, visible=true, canReceiveKeys=true, flags=0x81810520, type=0x00000001, layer=21015, frame=[0,0][1280,720], scale=1.000000, touchableRegion=[0,0][1280,720], inputFeatures=0x00000000, ownerPid=18833, ownerUid=13560, dispatchingTimeout=5000.000ms 在 dumpsys 文件中 继续搜索 WINDOW MANAGER LAST ANR，找到 Window{703780b-------------------------------------------------------------------------------WINDOW MANAGER LAST ANR (dumpsys window lastanr)//.... 省略Window #3 Window&#123;703780b u0 xxx/xxx.xActivity&#125;: mDisplayId=0 stackId=156 mSession=Session&#123;eaba5cd 18833:u0a13560&#125; mClient=android.os.BinderProxy@9fb1bda mOwnerUid=13560 mShowToOwnerOnly=true package=com.xxx appop=NONE mAttrs=WM.LayoutParams&#123;(0,0)(fillxfill) sim=#20 ty=1 fl=#81810500 wanim=0x103045b vsysui=0x1606 sysuil=true needsMenuKey=2&#125; Requested w=1280 h=720 mLayoutSeq=311401 mBaseLayer=21000 mSubLayer=0 mAnimLayer=21015+0=21015 mLastLayer=21015 mToken=AppWindowToken&#123;31531d3 token=Token&#123;40bffc2 ActivityRecord&#123;82ca40d u0 xxx/xxx.xActivity t4569&#125;&#125;&#125; mRootToken=AppWindowToken&#123;31531d3 token=Token&#123;40bffc2 ActivityRecord&#123;82ca40d u0 xxx/xxx.xActivity t4569&#125;&#125;&#125; mAppToken=AppWindowToken&#123;31531d3 token=Token&#123;40bffc2 ActivityRecord&#123;82ca40d u0 xxx/xxx.xActivity t4569&#125;&#125;&#125; mViewVisibility=0x0 mHaveFrame=true mObscured=false mSeq=2 mSystemUiVisibility=0x1606 mGivenContentInsets=[0,0][0,0] mGivenVisibleInsets=[0,0][0,0] mConfiguration=&#123;1.12 ?mcc?mnc zh_CN ldltr sw360dp w640dp h342dp 320dpi nrml long land finger -keyb/v/h -nav/h s.339mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0&#125; mHasSurface=true mShownFrame=[0.0,0.0][1280.0,720.0] isReadyForDisplay()=true mFrame=[0,0][1280,720] last=[0,0][1280,720] mSystemDecorRect=[0,0][1280,720] last=[0,0][0,0] Frames: containing=[0,0][1280,720] parent=[0,0][1280,720] display=[0,0][1280,720] overscan=[0,0][1280,720] content=[0,0][1280,720] visible=[0,0][1280,720] decor=[0,0][1280,720] outset=[0,0][1280,720] Cur insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] outsets=[0,0][0,0] Lst insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] physical=[0,0][0,0] outset=[0,0][0,0] WindowStateAnimator&#123;63d5e15 xxx/xxx.xActivity&#125;: mSurface=Surface(name=xxx/xxx.xActivity) mDrawState=HAS_DRAWN mLastHidden=false Surface: shown=true layer=21015 alpha=1.0 rect=(0.0,0.0) 1280.0 x 720.0 mGlobalScale=1.0 mDsDx=1.0 mDtDx=0.0 mDsDy=0.0 mDtDy=1.0 从上面日志可以发现这个window，属于是AppWindowToken，说明这个window就是一个Activity。 如果对AppWindowToken和ActivityRecord感兴趣的，可以看下罗老师的这篇文章：https://blog.csdn.net/luoshengyang/article/details/8498908 这里列一下返回时，两个Activity的生命周期交互 onBackPressed() 流程：SecondActivity - onPause() — MainActivity - onRestart() — MainActivity - onStart() — MainActivity - onResume() — SecondActivity - onStop() — SecondActivity - onDestroy() 综合上面的分析和猜测 :) , 需要着重看下xxActivity的onPause和下层Activity的onResume方法。 OK，到这里我们就知道了该如何分析 Waiting because the focused window is paused 对应的ANR了。 Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up在dumpsys文件中：Input Dispatcher State at time of last ANR: ANR: Time: 2021-05-31 23:33:18 // 跟上面分析过的 dumpsys文件对比，发现这里没有 - Window&#123;id u0 xxx/xxx.xActivity&#125; Window: AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; DispatchLatency: 5003.8ms WaitDuration: 5000.7ms Reason: Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up. DispatchEnabled: 1 DispatchFrozen: 0 FocusedApplication: name='AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125;', dispatchingTimeout=5000.000ms FocusedWindow: name='&lt;null&gt;' TouchStates: &lt;no displays touched&gt; Windows: // 这里有一个对应包名的window Window #8 Window&#123;7e932b5 u0 Starting com.xxx&#125;: mDisplayId=0 stackId=156 mSession=Session&#123;86d25c5 1457:1000&#125; mClient=android.view.ColorViewRootImplHooks$ColorW@7d1ceec mOwnerUid=1000 mShowToOwnerOnly=false package=com.xxx appop=NONE mAttrs=WM.LayoutParams&#123;(0,0)(fillxfill) sim=#20 ty=3 fl=#81830518 pfl=0x11 wanim=0x103045b vsysui=0x600 needsMenuKey=2&#125; Requested w=1280 h=720 mLayoutSeq=292571 mBaseLayer=21000 mSubLayer=0 mAnimLayer=21040+0=21040 mLastLayer=21040 mToken=AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; mRootToken=AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; mAppToken=AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; mViewVisibility=0x0 mHaveFrame=true mObscured=false mSeq=0 mSystemUiVisibility=0x600 mGivenContentInsets=[0,0][0,0] mGivenVisibleInsets=[0,0][0,0] mConfiguration=&#123;1.12 ?mcc?mnc zh_CN ldltr sw360dp w640dp h342dp 320dpi nrml long land finger -keyb/v/h -nav/h s.119mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0&#125; mHasSurface=true mShownFrame=[0.0,0.0][1280.0,720.0] isReadyForDisplay()=true mFrame=[0,0][1280,720] last=[0,0][1280,720] mSystemDecorRect=[0,0][1280,720] last=[0,0][0,0] Frames: containing=[0,0][1280,720] parent=[0,0][1280,720] display=[0,0][1280,720] overscan=[0,0][1280,720] content=[0,0][1280,720] visible=[0,0][1280,720] decor=[0,0][1280,720] outset=[0,0][1280,720] Cur insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] outsets=[0,0][0,0] Lst insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] physical=[0,0][0,0] outset=[0,0][0,0] WindowStateAnimator&#123;b277152 Starting com.xxx&#125;: mSurface=Surface(name=Starting com.xxx) mDrawState=HAS_DRAWN mLastHidden=false Surface: shown=true layer=21040 alpha=1.0 rect=(0.0,0.0) 1280.0 x 720.0 mGlobalScale=1.0 mDsDx=1.0 mDtDx=0.0 mDsDy=0.0 mDtDy=1.0 在logcat文件中：// input事件发生的时间点05-31 23:33:18.336 1457 1669 I WindowManager: Input event dispatching timed out sending to application AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125;. Reason: Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.05-31 23:33:18.341 28229 28258 I chatty : uid=13560(com.xxx) expire 2 lines05-31 23:33:18.344 1457 1669 D ActivityManager: ANR post Runnable for ProcessRecord&#123;772ec6 28229:com.xxx/u0a3560&#125; to deal with anr happend at 2089972814@#@2822905-31 23:33:18.344 1457 1669 D ActivityManager: ANR caller(2) = com.android.server.am.ActivityRecord$Token.keyDispatchingTimedOut:388 com.android.server.wm.InputMonitor.notifyANR:134 com.android.server.input.InputManagerService.notifyANR:1625 &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; 05-31 23:33:18.347 1457 1527 W InputManager: Input event injection from pid 28213 timed out.05-31 23:33:18.348 1457 28282 D ActivityManager: inputDispatchingTimedOut appNotResponding: proc ProcessRecord&#123;772ec6 28229:com.xxx/u0a3560&#125;05-31 23:33:18.349 1457 28282 D ActivityManager: appNotResponding: activity ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;05-31 23:33:18.350 28213 28213 I Input : injectKeyEvent: KeyEvent &#123; action=ACTION_UP, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=2089967799, downTime=2089967799, deviceId=-1, source=0x101 &#125;05-31 23:33:18.353 1457 28284 D ActivityManager: ANR deal 3 appNotResponding for ProcessRecord&#123;772ec6 28229:com.xxx/u0a3560&#125;, pid = 28229, annotation = Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.), happend at time = 2089972814@#@28229// ANR 收集到的时间点05-31 23:33:24.416 1457 28284 E ActivityManager: ANR in com.xxx (com.xxx/oxxx.PlayerActivity)05-31 23:33:24.416 1457 28284 E ActivityManager: PID: 2822905-31 23:33:24.416 1457 28284 E ActivityManager: Reason: Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.), happend at time = 2089972814@#@2822905-31 23:33:24.416 1457 28284 E ActivityManager: Load: 0.0 / 0.0 / 0.005-31 23:33:24.416 1457 28284 E ActivityManager: CPU usage from 955ms to -6002ms ago:05-31 23:33:24.416 1457 28284 E ActivityManager: 61% 26158/com.android.commands.monkey: 22% user + 39% kernel / faults: 3743 minor 26 major05-31 23:33:24.416 1457 28284 E ActivityManager: 20% 1457/system_server: 12% user + 7.8% kernel / faults: 16282 minor 21 major05-31 23:33:24.416 1457 28284 E ActivityManager: 9.6% 6732/VosTXThread: 0% user + 9.6% kernel05-31 23:33:24.416 1457 28284 E ActivityManager: +0% 28229/com.xxx: 0% user + 0% kernel 发现我们app的CPU 占用是0%，说明可能是我们的应用还没有启动起来，就发生了ANR。此时CPU占用最高的是monkey线程。 幸运的是这次抓到trace文件 关键：traces.txt 日志分析关于traces文件分析，我参考的是这篇文章：Android ANR日志分析指南 当APP不响应、响应慢了、或者WatchDog的监视没有得到回应时，系统就会dump出一个traces.txt文件，存放在文件目录: /data/anr/traces.txt，通过traces文件,我们可以拿到线程名、堆栈信息、线程当前状态、binder call等信息。 通过adb命令拿到该文件：adb pull /data/anr/traces.txt 我详细解析一下traces.txt里面的一些字段，看看它到底能给我们提供什么信息.main：main标识是主线程，如果是线程，那么命名成“Thread-X”的格式,x表示线程id,逐步递增。prio：线程优先级,默认是5tid：tid不是线程的id，是线程唯一标识IDgroup：是线程组名称sCount：该线程被挂起的次数dsCount：是线程被调试器挂起的次数obj：对象地址self：该线程Native的地址sysTid：是线程号(主线程的线程号和进程号相同)nice：是线程的调度优先级sched：分别标志了线程的调度策略和优先级cgrp：调度归属组handle：线程处理函数的地址。state：是调度状态schedstat：从 /proc/[pid]/task/[tid]/schedstat读出，三个值分别表示线程在cpu上执行的时间、线程的等待时间和线程执行的时间片长度，不支持这项信息的三个值都是0；utm：是线程用户态下使用的时间值(单位是jiffies）stm：是内核态下的调度时间值core：是最后执行这个线程的cpu核的序号。 main的堆栈信息是我们最关心的，它能够定位到具体位置。从上面的traces,我们可以判断java.io.File.isAbsolute 导致发生了ANR。这时候可以对着源码查看，找到出问题，并且解决它。 这里就主要看 mian线程// ... 省略suspend all histogram: Sum: 29.777ms 99% C.I. 4us-17039.359us Avg: 465.265us Max: 20121usDALVIK THREADS (36):\"Signal Catcher\" daemon prio=5 tid=2 Runnable | group=\"system\" sCount=0 dsCount=0 obj=0x12d0a0a0 self=0xed7b8600 | sysTid=28234 nice=0 cgrp=default sched=0/0 handle=0xf497f930 | state=R schedstat=( 5272239 1424062 9 ) utm=0 stm=0 core=6 HZ=100 | stack=0xf4883000-0xf4885000 stackSize=1014KB | held mutexes= \"mutator lock\"(shared held) native: #00 pc 0035e8cd /system/lib/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiPKcPNS_9ArtMethodEPv+116) native: #01 pc 0033ed6b /system/lib/libart.so (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+138) native: #02 pc 00348ce5 /system/lib/libart.so (_ZN3art14DumpCheckpoint3RunEPNS_6ThreadE+420) native: #03 pc 00349841 /system/lib/libart.so (_ZN3art10ThreadList13RunCheckpointEPNS_7ClosureE+192) native: #04 pc 00349d41 /system/lib/libart.so (_ZN3art10ThreadList4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+124) native: #05 pc 0034a429 /system/lib/libart.so (_ZN3art10ThreadList14DumpForSigQuitERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+312) native: #06 pc 0031f8e3 /system/lib/libart.so (_ZN3art7Runtime14DumpForSigQuitERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+66) native: #07 pc 0032a007 /system/lib/libart.so (_ZN3art13SignalCatcher13HandleSigQuitEv+910) native: #08 pc 0032aa2d /system/lib/libart.so (_ZN3art13SignalCatcher3RunEPv+668) native: #09 pc 0003fc7b /system/lib/libc.so (_ZL15__pthread_startPv+30) native: #10 pc 00019fc5 /system/lib/libc.so (__start_thread+6) (no managed stack frames)\"main\" prio=5 tid=1 Suspended // 状态是暂停 | group=\"main\" sCount=1 dsCount=0 obj=0x740c1360 self=0xf5402500 | sysTid=28229 nice=0 cgrp=default sched=0/0 handle=0xf76e5b34 | state=S schedstat=( 489913748 62354685 405 ) utm=38 stm=10 core=7 HZ=100 | stack=0xff78b000-0xff78d000 stackSize=8MB | held mutexes= at java.io.File.isAbsolute(File.java:510) at java.io.File.getAbsolutePath(File.java:373) at com.tencent.tinker.lib.tinker.Tinker$Builder.&lt;init&gt;(Proguard:359) at com.tencent.tinker.lib.tinker.con.a(Proguard:63) at com.xxx.hotfix.con.a(Proguard:127) at com.xxx.hotfix.con.a(Proguard:46) at com.xxx.hotfix.c.con.b(Proguard:198) at com.xxx.ApplicationDelegate.initTinker(Proguard:208) at com.xxx.ApplicationDelegate.onCreate(Proguard:152) at com.tencent.tinker.entry.TinkerApplicationInlineFence.onCreateImpl_$noinline$(Proguard:99) at com.tencent.tinker.entry.TinkerApplicationInlineFence.onCreate(Proguard:110) at com.tencent.tinker.loader.app.TinkerApplication.onCreate(Proguard:153) at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1014) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4995) at android.app.ActivityThread.access$1800(ActivityThread.java:170) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1555) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:179) at android.app.ActivityThread.main(ActivityThread.java:5769) at java.lang.reflect.Method.invoke!(Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:674)\"ReferenceQueueDaemon\" daemon prio=5 tid=4 Waiting | group=\"system\" sCount=1 dsCount=0 obj=0x12d04be0 self=0xf5402a00 | sysTid=28235 nice=0 cgrp=default sched=0/0 handle=0xf4880930 | state=S schedstat=( 947291 9095001 12 ) utm=0 stm=0 core=7 HZ=100 | stack=0xf477e000-0xf4780000 stackSize=1038KB | held mutexes= at java.lang.Object.wait!(Native method) - waiting on &lt;0x09e82a5a&gt; (a java.lang.Class&lt;java.lang.ref.ReferenceQueue&gt;) at java.lang.Daemons$ReferenceQueueDaemon.run(Daemons.java:152) - locked &lt;0x09e82a5a&gt; (a java.lang.Class&lt;java.lang.ref.ReferenceQueue&gt;) at java.lang.Thread.run(Thread.java:818)\"FinalizerDaemon\" daemon prio=5 tid=5 Waiting | group=\"system\" sCount=1 dsCount=0 obj=0x12d04c40 self=0xf5402f00 | sysTid=28236 nice=0 cgrp=default sched=0/0 handle=0xf477b930 | state=S schedstat=( 899169 4021874 6 ) utm=0 stm=0 core=5 HZ=100 | stack=0xf4679000-0xf467b000 stackSize=1038KB | held mutexes= at java.lang.Object.wait!(Native method) - waiting on &lt;0x005da48b&gt; (a java.lang.ref.ReferenceQueue) at java.lang.Object.wait(Object.java:423) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:101) - locked &lt;0x005da48b&gt; (a java.lang.ref.ReferenceQueue) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:72) at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:193) at java.lang.Thread.run(Thread.java:818)\"FinalizerWatchdogDaemon\" daemon prio=5 tid=6 Waiting | group=\"system\" sCount=1 dsCount=0 obj=0x12d04ca0 self=0xf5403400 | sysTid=28237 nice=0 cgrp=default sched=0/0 handle=0xf4676930 | state=S schedstat=( 899684 3116201 10 ) utm=0 stm=0 core=7 HZ=100 | stack=0xf4574000-0xf4576000 stackSize=1038KB | held mutexes= at java.lang.Object.wait!(Native method) - waiting on &lt;0x0e839968&gt; (a java.lang.Daemons$FinalizerWatchdogDaemon) at java.lang.Daemons$FinalizerWatchdogDaemon.waitForObject(Daemons.java:275) - locked &lt;0x0e839968&gt; (a java.lang.Daemons$FinalizerWatchdogDaemon) at java.lang.Daemons$FinalizerWatchdogDaemon.run(Daemons.java:244) at java.lang.Thread.run(Thread.java:818) 看trace文件，应该是其他线程占用了资源，导致main线程暂停 最后，结合上面CPU占用分析，应该是monkey线程占用了资源，导致main线程挂起 拓展Service，Reason: executing service xxx/xxx.Service在logcat中遇到一个Service ANR Service Timeout是位于”ActivityManager”线程中的AMS.MainHandler收到SERVICE_TIMEOUT_MSG消息时触发。 对于Service有两类: 对于前台服务，则超时为SERVICE_TIMEOUT = 20s； 对于后台服务，则超时为SERVICE_BACKGROUND_TIMEOUT = 200s 由变量ProcessRecord.execServicesFg来决定是否前台启动先看logcat日志，有如下内容，以时间先后排列：// 系统进程都已经挂掉了06-01 04:54:26.174 1457 1807 I ActivityManager: Process com.android.browser (pid 27980) has died06-01 04:54:26.174 1457 1807 D ActivityManager: cleanUpApplicationRecord -- 2798006-01 04:54:26.975 1457 1807 I ActivityManager: Start proc 28150:com.oppo.usercenter/u0a59 for content provider com.oppo.usercenter/com.platform.usercenter.newcommon.db.UserCenterContentProvider06-01 04:54:27.011 1457 1471 I ActivityManager: Process com.oppo.market (pid 28086) has died06-01 04:54:27.011 1457 1471 D ActivityManager: cleanUpApplicationRecord -- 2808606-01 04:54:28.093 1457 2688 I ActivityManager: Process com.tencent.mm:push (pid 12440) has died06-01 04:54:28.093 1457 2688 D ActivityManager: cleanUpApplicationRecord -- 12440// 应用被force-stop, 发送广播ACTION_PACKAGE_RESTARTED，用于停止已注册的alarm,notification.06-01 04:54:40.840 1457 1457 D JobSchedulerService: Receieved: android.intent.action.PACKAGE_RESTARTED06-01 04:54:40.841 1457 1457 D JobSchedulerService: Stop app Removing jobs for uid: 13560 pkg = xxx06-01 04:54:40.883 1457 1522 W WindowManager: Attempted to add application window with unknown token Token&#123;6f25abd ActivityRecord&#123;bf5f214 u0 xxx/oxxx.PlayerActivity t4576 f&#125;&#125;. Aborting.// 在一个Activity启动前，系统会先创建一个启动窗口作为过渡，这里starting window就代表启动窗口，启动窗口也添加失败06-01 04:54:40.902 1457 1522 W WindowManager: Exception when adding starting window 06-01 04:54:40.902 1457 1522 W WindowManager: java.lang.IllegalArgumentException: View=com.android.internal.policy.PhoneWindow$DecorView&#123;7d429de V.E...... R.....ID 0,0-0,0&#125; not attached to window manager06-01 04:54:40.902 1457 1522 W WindowManager: at android.view.WindowManagerGlobal.findViewLocked(WindowManagerGlobal.java:424)06-01 04:54:40.902 1457 1522 W WindowManager: at android.view.WindowManagerGlobal.removeView(WindowManagerGlobal.java:350)06-01 04:54:40.902 1457 1522 W WindowManager: at android.view.WindowManagerImpl.removeViewImmediate(WindowManagerImpl.java:118)06-01 04:54:40.902 1457 1522 W WindowManager: at com.android.server.policy.PhoneWindowManager.addStartingWindow(PhoneWindowManager.java:2811)06-01 04:54:40.902 1457 1522 W WindowManager: at com.android.server.wm.WindowManagerService$H.handleMessage(WindowManagerService.java:8406)06-01 04:54:40.902 1457 1522 W WindowManager: at android.os.Handler.dispatchMessage(Handler.java:102)06-01 04:54:40.902 1457 1522 W WindowManager: at android.os.Looper.loop(Looper.java:179)06-01 04:54:40.902 1457 1522 W WindowManager: at android.os.HandlerThread.run(HandlerThread.java:61)06-01 04:54:40.902 1457 1522 W WindowManager: at com.android.server.ServiceThread.run(ServiceThread.java:46)// 杀掉应用进程06-01 05:26:03.900 1457 2476 I ActivityManager: Force stopping xxx appid=13560 user=0: from pid 2418506-01 05:26:03.901 1457 2476 I ActivityManager: Killing 7767:xxx/u0a3560 (adj 0): stop xxx06-01 05:26:03.902 1457 2476 D ActivityManager: cleanUpApplicationRecord -- 7767// 重启应用进程06-01 05:26:25.005 1457 2643 I ActivityManager: Start proc 7916:xxx/u0a3560 for activity xxx/.WelcomeActivity06-01 05:26:25.020 14580 14580 I MediaScannerReceiver: onReceive, intent=Intent &#123; act=android.intent.action.MEDIA_SCANNER_SCAN_FILE dat=file:///sdcard/monkey_screenshot/122_2021-06-01_05-26-09.png flg=0x10 cmp=com.android.providers.media/.MediaScannerReceiver &#125;// window freeze timeout App freeze timeout 网上说这里是屏幕方向改变时，清理旧配置信息超时06-01 05:26:27.071 1457 1522 W WindowManager: Window freeze timeout expired.06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;9ec2733 u0 Starting xxx&#125;06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;38b9629 u0 xxx/xxx.WelcomeActivity&#125;06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;863574f u0 xxx/xxx.WelcomeActivity&#125;06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;4bf40a2 u0 com.android.systemui.ImageWallpaper&#125;06-01 05:26:27.075 1457 1522 V WindowManager: set sys.app_freeze_timeout: pkg=xxx06-01 05:26:27.084 1457 1522 W WindowManager: App freeze timeout expired.06-01 05:26:27.085 1457 1522 W WindowManager: Force clearing freeze: AppWindowToken&#123;e409897 token=Token&#123;68b58d8 ActivityRecord&#123;17fbbb u0 xxx/.WelcomeActivity t4595&#125;&#125;&#125;06-01 05:26:27.145 1457 1522 I WindowManager: Screen frozen for +2s74ms due to Window&#123;9ec2733 u0 Starting xxx&#125;06-01 05:26:27.156 1457 1522 I WindowManager: finishPostLayoutPolicyLw (statusbar != null ) true topIsFullscreen true top = Window&#123;9ec2733 u0 Starting xxx&#125;06-01 05:26:27.156 1457 1522 I StatusBarManagerService: topIsFullscreen fullscreen true06-01 05:26:27.174 1457 1471 I WindowManager: Switching to real app window: Window&#123;863574f u0 xxx/xxx.WelcomeActivity&#125;// launch timeout 可以看下这篇文章： https://blog.csdn.net/bruk_spp/article/details/9776937606-01 05:26:47.226 1457 1497 W ActivityManager: Launch timeout has expired, giving up wake lock!06-01 05:26:47.230 21977 21995 I Launcher.LauncherTraceUtil: writeLauncherStateToFile. The mStateTrace is null!06-01 05:26:47.232 7916 7953 I chatty : uid=13560(xxx) expire 2 lines06-01 05:26:47.332 1457 8210 I Process : Sending signal. PID: 7916 SIG: 3// ANR 发生的地方06-01 05:26:47.234 1457 1497 W ActivityManager: Timeout executing service: ServiceRecord&#123;d006edc u0 xxx/xxxService&#125;06-01 05:26:47.235 1457 1500 V OppoAppStartupManager: intent == null || callerApp == null06-01 05:26:47.239 1457 1863 D BluetoothManagerService: checkIfCallerIsForegroundUser: valid=true callingUser=0 parentUser=-10000 foregroundUser=006-01 05:26:47.242 2646 2646 E ANR_LOG : &gt;&gt;&gt; msg's executing time is too long06-01 05:26:47.242 2646 2646 E ANR_LOG : Blocked msg = &#123; when=-2s244ms what=3 target=com.qti.internal.telephony.gsm.QtiGsmServiceStateTracker obj=android.os.AsyncResult@f88f23e &#125; , cost = 2243 ms06-01 05:26:47.242 2646 2646 E ANR_LOG : &gt;&gt;&gt;Current msg List is:06-01 05:26:47.242 2646 2646 E ANR_LOG : Current msg &lt;1&gt; = &#123; when=+20s0ms what=10 target=com.qti.internal.telephony.gsm.QtiGsmServiceStateTracker &#125;06-01 05:26:47.242 2646 2646 E ANR_LOG : &gt;&gt;&gt;CURRENT MSG DUMP OVER&lt;&lt;&lt;06-01 05:26:47.243 14580 14580 I MediaScannerReceiver: onReceive, intent=Intent &#123; act=android.intent.action.MEDIA_SCANNER_SCAN_FILE dat=file:///sdcard/monkey_screenshot/123_2021-06-01_05-26-49.png flg=0x10 cmp=com.android.providers.media/.MediaScannerReceiver &#125;06-01 05:26:47.245 1457 1457 E ANR_LOG : &gt;&gt;&gt; msg's executing time is too long06-01 05:26:47.245 1457 1457 E ANR_LOG : Blocked msg = &#123; when=-5s541ms what=0 target=android.os.Handler callback=com.android.server.BatteryService$12 &#125; , cost = 5541 ms06-01 05:26:47.245 1457 8210 D ActivityManager: ANR deal 3 appNotResponding for ProcessRecord&#123;7d985f 7916:xxx/u0a3560&#125;, pid = 7916, annotation = executing service xxx/xxx.Service// 捕获到ANR的地方06-01 05:26:53.364 1457 8210 E ActivityManager: ANR in xxx06-01 05:26:53.364 1457 8210 E ActivityManager: PID: 791606-01 05:26:53.364 1457 8210 E ActivityManager: Reason: executing service xxx/xxx.Service06-01 05:26:53.364 1457 8210 E ActivityManager: Load: 0.0 / 0.0 / 0.006-01 05:26:53.364 1457 8210 E ActivityManager: CPU usage from 0ms to 6087ms later:06-01 05:26:53.364 1457 8210 E ActivityManager: 108% 7916/xxx: 21% user + 86% kernel / faults: 15083 minor 47 major06-01 05:26:53.364 1457 8210 E ActivityManager: 9.2% 1457/system_server: 4.9% user + 4.2% kernel / faults: 958 minor ANR发生的过程怀疑是，应用被杀死，但没有杀死Service，然后重启应用，启动过程中CPU占用过高，而出现的ANR 哪些场景会出现ANR 场景1：低内存anr：查看CPU，手机内存低导致anr时，一般以下两个进程CPU使用率高，手机会出现大量应用anr： 35% 90/mmcqd/0: 0% user + 35% kernel18% 49/kswapd0: 0% user + 18% kernel 场景2： 某一个进程的cpu使用率高，导致当前进程无法获取资源，可以根据trace查看是哪个进程在工作； 场景3：主线程卡死： 1）主线程等待其他线程锁waiting to lock； 2） 主线程繁忙；3）主线程对应的native调用栈卡住； 场景4：Activity resume、restart或pause太慢，导致无焦点窗口问题，通常会有黑屏白屏等现象； 场景5：省电精灵智能省电模式冻结后台进程，resume activity时，没有及时解冻，产生无焦点窗口anr； 场景6：其它进程Binder线程耗尽（ProcessState.cpp中指定最大binder线程数，如maxThreads:32），导致当前进程卡在IPCThreadState::talkWithDriver； 场景7：Input dispatching timed out：接收输入事件的窗口出现异常，丢失焦点，伴随冻屏现象 场景8：monkey启动大量对象GC耗时久导致anr。从dumpsys中可以看到启动很多window，从log中看GC耗时很久； 场景9：抓取整机log导致anr。此类问题中，adbd、bugreport、chargelogcat等进程CPU使用率高； 场景10：Framework缺陷导致无焦点窗口问题，activity已经正常resume了（am_on_resume_called），dumpsys中mFocusedWindow为null。 ANR一定会发生吗？不会 可以参考这篇文章：https://juejin.cn/post/6890758574364950541 和 http://gityuan.com/2019/04/06/android-anr/ 比如 input事件： input超时机制为什么是扫雷，而非定时爆炸呢？是由于对于input来说即便某次事件执行时间超过timeout时长，只要用户后续在没有再生成输入事件，则不会触发ANR。 这里的扫雷是指当前输入系统中正在处理着某个耗时事件的前提下，后续的每一次input事件都会检测前一个正在处理的事件是否超时（进入扫雷状态），检测当前的时间距离上次输入事件分发时间点是否超过timeout时长。如果前一个输入事件，则会重置ANR的timeout，从而不会爆炸。 更多细节详见Input系统-ANR原理分析，http://gityuan.com/2017/01/01/input-anr ANR日志生成原理网上大概有这么几种方式： 系统的 system_server 进程在检测到 App 出现 ANR 后，会向出现 ANR 的进程发送 SIGQUIT (signal 3)信号。正常情况下，系统的 libart.so 会收到该信号，并调用 Java 虚拟机的 dump 方法生成 traces。以友盟+的 U-APM 应用性能监控平台为例，集成SDK 后，SDK 会拦截 SIGQUIT。在出现 ANR 时，libcrashsdk.so 会优先收到信号，并生成 traces 和 ANR 日志。在 SDK 处理完信号后，会将信号继续传递给系统的 libart.so，让系统生成 ANR traces.txt。 监控ANR异常，通过反编译Bugly jar包，发现ANR异常捕获是通过FileObserver实现的。当ANR发生的时候，通过监听文件文件夹“data/anr/”的写入情况, 来判断是否发生了ANR，如果监听到data/anr/traces.txt文件写入。说明有此时有ANR异常发生。 FileObserver捕获ANR异常,缺点是Android5.0低权限应用不能监听变化“、data/anr/traces.txt”，只能在root之后才可以 ANR-WatchDog是参考Android WatchDog机制（com.android.server.WatchDog.java）起个单独线程向主线程发送一个变量+1操作，自我休眠自定义ANR的阈值，休眠过后判断变量是否+1完成，如果未完成则告警。但是无法保证能捕捉所有ANR，对阈值的设置直接影响捕获概率。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/06/07/ANR-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANR","slug":"anr","permalink":"http://agehua.github.io/tags/anr/"}]},{"title":"android 画中画功能总结","slug":"Android-PIP-Hack-summary","date":"2021-04-18T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2021/04/19/Android-PIP-Hack-summary/","link":"","permalink":"http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/","excerpt":"首先，Google官方给的画中画api比较简单，想要实现一个画中画需要很多其他交互，本文就以画中画涉及到的具体操作来总结如何实现画中画","text":"首先，Google官方给的画中画api比较简单，想要实现一个画中画需要很多其他交互，本文就以画中画涉及到的具体操作来总结如何实现画中画官方文档： https://developer.android.google.cn/guide/topics/ui/picture-in-picture 简单实现修改清单文件，让activity支持画中画&lt;activity android:name=\"xxx.VideoActivity\" android:configChanges=\"orientation|keyboardHidden|screenSize|keyboard|screenLayout|smallestScreenSize\" android:launchMode=\"singleTop\" android:taskAffinity=\".VideoActivity\" android:supportsPictureInPicture=\"true\" android:stateNotNeeded=\"false\" android:autoRemoveFromRecents=\"true\" android:excludeFromRecents=\"true\" /&gt; 1.设置 android:supportsPictureInPicture 属性为 true 2.configChanges 添加 smallestScreenSize，避免进入画中画导致Activity重建 3.指定新的taskAffinity，可以在小窗模式下打开新的页面，而不是在小窗中打开新页面 4.可以添加stateNotNeeded、autoRemoveFromRecents、excludeFromRecents等，使画中画页面不显示在最近的应用列表中 taskAffinity 需要配合singleTask或singleInstance使用。这里指定为singleTop是有一个小技巧，即可以通过是否添加 intent.addFlags(FLAG_ACTIVITY_NEW_TASK) 标记动态控制是否在新任务栈中打开VideoActivity 注意：如果VideoActivity不添加taskAffinity属性，开启画中画的情况下，那么新启动的Activity有 singleTask或FLAG_ACTIVITY_NEW_TASK标记，新的Activity会展示在画中画中 进入画中画 1.主动触发 getActivity().enterPictureInPictureMode(); 2.离开页面 @Overridepublic void onUserLeaveHint () &#123; if (iWantToBeInPipModeNow()) &#123; enterPictureInPictureMode(); &#125;&#125; 官方只有这两步，但是使用中还会有其他要求，继续往下看： 其他交互操作进入画中画的同时，打开另一个页面// 需要延时，因为画中画只能打开在前台的Activity，不加延时则画中画最上层页面是 VideoDescActivity new Handler().postDelayed(new Runnable() &#123; @Override public void run() &#123; if (null == mActivity) &#123; return; &#125; Intent intent = new Intent(mActivity, VideoDescActivity.class); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); mActivity.startActivity(intent); &#125;&#125;, 300); 点击画中画回到VideoActivity：不用特别处理点击VideoDescActivity上元素，回到VideoActivity重新启动VideoActivity即可Intent intent = new Intent(mActivity, VideoActivity.class);intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TOP);mActivity.startActivity(intent); 点击VideoDescActivity上元素，关闭画中画// 使用本地广播，通知 VideoActivity 收到广播后直接 finishIntent intent = new Intent();intent.setAction(PIP_ACTION_FILTER_ENTER); // 需要 VideoActivity 注册这个actionintent.putExtra(\"closeOrReopen\", true);LocalBroadcastManager.getInstance(CartoonGlobalContext.getAppContext()).sendBroadcast(intent); 监听系统关闭画中画重写Activity onPictureInPictureModeChanged：onPictureInPictureModeChanged(boolean isInPictureInPictureMode, Configuration newConfig) &#123; if (!isInPictureInPictureMode) &#123; // 这里是关闭 &#125;&#125; VideoActivity打开新的页面，比如TimerActivityIntent intent = new Intent(mActivity, TimerActivity.class);mActivity.startActivity(intent); 这里必须使用mActivity，不能是Application，否则 TimerActivity 会显示在默认taskAffinity属性的 activity 上。 关闭TimerActivity后，回到VideoActivity// 重新启动 VideoActivity，并且设置 intent 属性如下：Intent intent1 = new Intent(this, VideoActivity.class);intent1.setAction(Intent.ACTION_MAIN);intent1.addCategory(Intent.CATEGORY_LAUNCHER);startActivity(intent1); VideoActivity关闭后，切回到默认task画中画切到手机桌面上后，将画中画切换为全屏，这时候退出VideoActivity会回到手机桌面，如果需要返回到App的默认activity栈，则需要添加下面的代码： public static void navToLauncherTask(Context appContext) &#123; if (null == appContext || Build.VERSION.SDK_INT &lt; Build.VERSION_CODES.LOLLIPOP) &#123; return; &#125; ActivityManager activityManager = (ActivityManager) appContext.getSystemService(Context.ACTIVITY_SERVICE); // iterate app tasks available and navigate to launcher task (browse task) final List&lt;ActivityManager.AppTask&gt; appTasks = activityManager.getAppTasks(); for (ActivityManager.AppTask task : appTasks) &#123; final Intent baseIntent = task.getTaskInfo().baseIntent; final Set&lt;String&gt; categories = baseIntent.getCategories(); if (categories != null &amp;&amp; categories.contains(Intent.CATEGORY_LAUNCHER)) &#123; task.moveToFront(); return; &#125; &#125;&#125; task 也有 startActivity的方法，感兴趣的可以看一下 注意问题 在支持画中画的activity中，并且开启过画中画，getContext()方法返回值是ContextThemeWrapper，用这个跳转页面（getContext().startActivity），会有栈reparent问题，可以使用XXXActivity.this 或者 view.getContext()代替 REFhttps://developer.android.google.cn/guide/topics/ui/picture-in-picture https://proandroiddev.com/task-management-for-picture-in-picture-mode-on-android-o-882103271cad 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"picture-in-picture","slug":"picture-in-picture","permalink":"http://agehua.github.io/tags/picture-in-picture/"}]},{"title":"Recyclerview 滑动相关功能总结","slug":"RecyclerView_scroll_relatedapi","date":"2020-12-03T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2020/12/04/RecyclerView_scroll_relatedapi/","link":"","permalink":"http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/","excerpt":"本文总结一下RecyclerView提供的滑动相关的api，并探究一下为什么有的滑动方法不会回调监听 onScrollStateChanged(int state)","text":"本文总结一下RecyclerView提供的滑动相关的api，并探究一下为什么有的滑动方法不会回调监听 onScrollStateChanged(int state)RecyclerView scroll 相关API有： scrollTo(int x, int y) scrollBy(int x, int y) scrollToPosition(int position) smoothScrollBy(@Px int dx, @Px int dy) 及其重载方法 smoothScrollToPosition(int position) 当然，还有手势滑动 RecyclerView 通过 addOnScrollListener(OnScrollListener)监听滑动事件 RecyclerView 调用这个方法通知layoutmanager，scroll状态已经改变@Overridepublic void onScrollStateChanged(int state) &#123; super.onScrollStateChanged(recyclerView, newState); if (state == SCROLL_STATE_IDLE) &#123; //滑动停止 &#125;&#125;@Overridepublic void onScrolled(RecyclerView recyclerView, int dx, int dy) &#123; super.onScrolled(recyclerView, dx, dy); //...&#125; 但是并不是所有的滑动行为都会回调到 onScrollStateChanged ,下面来一一分析下每个滑动场景 scrollTo 和 scrollByscrollTo 和 scrollBy 是 View 相关方法，实现的是 View 内容的滑动，效果是 View 控件本身并没有滑动，而是控件上绘制的内容在控件范围内发生滑动。看下在 RecyclerView 里面的实现：// RecyclerView@Overridepublic void scrollTo(int x, int y) &#123; // RecyclerView 不支持滚动到绝对位置，尝试使用 scrollToPosition 替换 Log.w(TAG, \"RecyclerView does not support scrolling to an absolute position. \" + \"Use scrollToPosition instead\");&#125;@Overridepublic void scrollBy(int x, int y) &#123; // 这个方法可以配合实现 NestedScrollingChild 的控件联动 if (mLayout == null) &#123; Log.e(TAG, \"Cannot scroll without a LayoutManager set. \" + \"Call setLayoutManager with a non-null argument.\"); return; &#125; if (mLayoutSuppressed) &#123; return; &#125; final boolean canScrollHorizontal = mLayout.canScrollHorizontally(); final boolean canScrollVertical = mLayout.canScrollVertically(); if (canScrollHorizontal || canScrollVertical) &#123; scrollByInternal(canScrollHorizontal ? x : 0, canScrollVertical ? y : 0, null); &#125;&#125; scrollByInternal 介绍scrollByInternal后面在处理手势拖动的时候也会用到，继续往下看：// RecyclerViewboolean scrollByInternal(int x, int y, MotionEvent ev) &#123; int unconsumedX = 0; int unconsumedY = 0; int consumedX = 0; int consumedY = 0; consumePendingUpdateOperations(); if (mAdapter != null) &#123; mReusableIntPair[0] = 0; mReusableIntPair[1] = 0; // 这里处理滑动 scrollStep(x, y, mReusableIntPair); consumedX = mReusableIntPair[0]; consumedY = mReusableIntPair[1]; unconsumedX = x - consumedX; unconsumedY = y - consumedY; &#125; // ... 分发 nestedscroll 结果 dispatchNestedScroll(consumedX, consumedY, unconsumedX, unconsumedY, mScrollOffset, TYPE_TOUCH, mReusableIntPair); // ... 通知 onScrolled 事件 if (consumedX != 0 || consumedY != 0) &#123; dispatchOnScrolled(consumedX, consumedY); &#125; // ...&#125; dispatchOnScrolled 会通知 onScrolled 的监听者 scrollStep方法，如下：// RecyclerViewvoid scrollStep(int dx, int dy, @Nullable int[] consumed) &#123; // ... int consumedX = 0; int consumedY = 0; if (dx != 0) &#123; // 调用LayoutManager处理滑动 consumedX = mLayout.scrollHorizontallyBy(dx, mRecycler, mState); &#125; if (dy != 0) &#123; consumedY = mLayout.scrollVerticallyBy(dy, mRecycler, mState); &#125; // ...&#125; LayoutManager.scrollHorizontallyBy 介绍本文以下都以 LinearLayoutManager 为例，继续看scrollHorizontallyBy 方法： // LinearLayoutManagerint scrollBy(int delta, RecyclerView.Recycler recycler, RecyclerView.State state) &#123; if (getChildCount() == 0 || delta == 0) &#123; return 0; &#125; ensureLayoutState(); mLayoutState.mRecycle = true; final int layoutDirection = delta &gt; 0 ? LayoutState.LAYOUT_END : LayoutState.LAYOUT_START; final int absDelta = Math.abs(delta); updateLayoutState(layoutDirection, absDelta, true, state); final int consumed = mLayoutState.mScrollingOffset + fill(recycler, mLayoutState, state, false); // ... final int scrolled = absDelta &gt; consumed ? layoutDirection * consumed : delta; mOrientationHelper.offsetChildren(-scrolled); mLayoutState.mLastScrollDelta = scrolled; return scrolled;&#125; mOrientationHelper是LinearLayoutManager 类的一个全局变量，初始化是在：// LinearLayoutManagerpublic void setOrientation(@RecyclerView.Orientation int orientation) &#123; if (orientation != HORIZONTAL &amp;&amp; orientation != VERTICAL) &#123; throw new IllegalArgumentException(\"invalid orientation:\" + orientation); &#125; assertNotInLayoutOrScroll(null); if (orientation != mOrientation || mOrientationHelper == null) &#123; mOrientationHelper = OrientationHelper.createOrientationHelper(this, orientation); mAnchorInfo.mOrientationHelper = mOrientationHelper; mOrientation = orientation; requestLayout(); &#125;&#125; 继续往下看：// abstract class OrientationHelperpublic static OrientationHelper createOrientationHelper( RecyclerView.LayoutManager layoutManager, @RecyclerView.Orientation int orientation) &#123; switch (orientation) &#123; case HORIZONTAL: return createHorizontalHelper(layoutManager); case VERTICAL: return createVerticalHelper(layoutManager); &#125; throw new IllegalArgumentException(\"invalid orientation\");&#125; 以HORIZONTAL 方向为例：public static OrientationHelper createHorizontalHelper( RecyclerView.LayoutManager layoutManager) &#123; return new OrientationHelper(layoutManager) &#123; @Override public int getEndAfterPadding() &#123; return mLayoutManager.getWidth() - mLayoutManager.getPaddingRight(); &#125; @Override public int getEnd() &#123; return mLayoutManager.getWidth(); &#125; @Override public void offsetChildren(int amount) &#123; // 最终还是调用的全局变量 mLayoutManager 的 offsetChildrenHorizontal 方法 mLayoutManager.offsetChildrenHorizontal(amount); // 垂直方向调用的就是下面的方法： // mLayoutManager.offsetChildrenVertical(amount); &#125; //... &#125;&#125;private OrientationHelper(RecyclerView.LayoutManager layoutManager) &#123; mLayoutManager = layoutManager;&#125; mLayoutManager 作为 OrientationHelper 构造方法的唯一参数。点击mLayoutManager.offsetChildrenHorizontal(amount) 方法，跳转到的是RecyclerView.LayoutManger的方法：// RecyclerView.LayoutManger public void offsetChildrenHorizontal(@Px int dx) &#123; if (mRecyclerView != null) &#123; mRecyclerView.offsetChildrenHorizontal(dx); &#125;&#125; 回到RecyclerView的这个方法：public void offsetChildrenHorizontal(@Px int dx) &#123; final int childCount = mChildHelper.getChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; // getChildAt返回的是每个child view mChildHelper.getChildAt(i).offsetLeftAndRight(dx); &#125;&#125; View.offsetLeftAndRight 介绍经过上面的跳转步骤，最终发现会调用到列表里每个View的 offsetLeftAndRight 方法：// Viewpublic void offsetLeftAndRight(int offset) &#123; if (offset != 0) &#123; final boolean matrixIsIdentity = hasIdentityMatrix(); if (matrixIsIdentity) &#123; if (isHardwareAccelerated()) &#123; invalidateViewProperty(false, false); &#125; else &#123; final ViewParent p = mParent; if (p != null &amp;&amp; mAttachInfo != null) &#123; final Rect r = mAttachInfo.mTmpInvalRect; int minLeft; int maxRight; if (offset &lt; 0) &#123; minLeft = mLeft + offset; maxRight = mRight; &#125; else &#123; minLeft = mLeft; maxRight = mRight + offset; &#125; r.set(0, 0, maxRight - minLeft, mBottom - mTop); p.invalidateChild(this, r); &#125; &#125; &#125; else &#123; invalidateViewProperty(false, false); &#125; mLeft += offset; mRight += offset; mRenderNode.offsetLeftAndRight(offset); if (isHardwareAccelerated()) &#123; invalidateViewProperty(false, false); invalidateParentIfNeededAndWasQuickRejected(); &#125; else &#123; if (!matrixIsIdentity) &#123; invalidateViewProperty(false, true); &#125; invalidateParentIfNeeded(); &#125; notifySubtreeAccessibilityStateChangedIfNeeded(); &#125;&#125; 这里RecyclerView的每个子View都是通过改变子 View 的 mLeft、mTop 等坐标，将初始位置值及偏移量传入，即需要滑动到的位置的坐标完成滑动。这里的 mLeft、mTop是指基于父控件的视图坐标系中的坐标 Android 中有两种坐标系： 一种是视图坐标系，以当前控件左上角为坐标原点，向右为 X 轴正方向，向下为 Y 轴正方向，MotionEvent 的 getX()、getY() 方法获取的是点击位置在视图坐标系中的坐标。 另一种是 Android 坐标系，以屏幕左上角为坐标原点，向右为 X 轴正方向，向下为 Y 轴正方向，MotionEvent 的 getRawX()、getRawY() 方法获取的是点击位置在 Android 坐标系中的坐标 小结小结一下，scorllBy 方法通知了onScrolled 回调，但是没有通知 onScrollStateChanged 回调 额外补充一点RecyclerView的布局过程，看上面scrollBy 里调用的 fill 方法// LinearLayoutManager// fill填充方法， 返回的是填充ItemView需要的像素，以便拿去做滚动int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) &#123; // 填充起始位置 final int start = layoutState.mAvailable; if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) &#123; //如果有滚动就执行一次回收 recycleByLayoutState(recycler, layoutState); &#125; // 计算剩余可用的填充空间 int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace; // 用于记录每一次while循环的填充结果 LayoutChunkResult layoutChunkResult = mLayoutChunkResult; // ================== 核心while循环 ==================== while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; // ====== 填充itemView核心填充方法 ====== 屏幕还有剩余可用空间并且还有数据就继续执行 layoutChunk(recycler, state, layoutState, layoutChunkResult); // ... &#125; // 填充完成后修改起始位置 return start - layoutState.mAvailable;&#125; 这个方法是用来填充内容的，更多布局过程可以参考这篇文章：《图文详解LinearLayoutManager填充、测量、布局过程》 scrollToPosition再来看下 scrollToPosition，这个方法会使 RecyclerView 滚动最小的距离，以使目标位置可见，如果目标位置的view没有创建，则滑动不会发生 // RecyclerView.javapublic void scrollToPosition(int position) &#123; if (mLayoutSuppressed) &#123; return; &#125; stopScroll(); if (mLayout == null) &#123; Log.e(TAG, \"Cannot scroll to position a LayoutManager set. \" + \"Call setLayoutManager with a non-null argument.\"); return; &#125; mLayout.scrollToPosition(position); // 实际调用的是LayoutManager的对应方法 awakenScrollBars();&#125; 这个方法调用了LayoutManager的同名方法： // LinearLayoutManager.java@Overridepublic void scrollToPosition(int position) &#123; // 用 mPendingScrollPosition 变量保存方法传入的位置 mPendingScrollPosition = position; mPendingScrollPositionOffset = INVALID_OFFSET; if (mPendingSavedState != null) &#123; mPendingSavedState.invalidateAnchor(); &#125; requestLayout(); // 请求刷新布局&#125; requestLayout()，会重走onMeasure, onLayout过程，在 RecyclerView 的 dispatchLayoutStep1() 中 会调用onLayoutChildren()方法。同时 LinearLayoutManager 重写了onLayoutChildren方法// LinearLayoutManager.java@Overridepublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) &#123; // layout algorithm: 布局算法 // 1) by checking children and other variables, find an anchor coordinate and an anchor item position. // 通过检查孩子和其他变量，找到锚坐标和锚点项目位置 mAnchor为布局锚点 理解为不具有的起点. // mAnchor包含了子控件在Y轴上起始绘制偏移量（coordinate）,ItemView在Adapter中的索引位置(position)和布局方向(mLayoutFromEnd) // 2) fill towards start, stacking from bottom 开始填充, 从底部堆叠 // 3) fill towards end, stacking from top 结束填充,从顶部堆叠 // 4) scroll to fulfill requirements like stack from bottom. 滚动以满足堆栈从底部的要求 // resolve layout direction 设置布局方向(VERTICAL/HORIZONTAL) resolveShouldLayoutReverse(); // ... final View focused = getFocusedChild(); if (!mAnchorInfo.mValid || mPendingScrollPosition != RecyclerView.NO_POSITION || mPendingSavedState != null) &#123; // mPendingScrollPosition 值已更新，会进到这里 mAnchorInfo.reset(); // mStackFromEnd需要我们开发者主动调用，不然一直未false // VERTICAL方向为mLayoutFromEnd为false HORIZONTAL方向是为true mAnchorInfo.mLayoutFromEnd = mShouldReverseLayout ^ mStackFromEnd; // 计算更新保存绘制锚点信息 updateAnchorInfoForLayout(recycler, state, mAnchorInfo); mAnchorInfo.mValid = true; &#125; else if (focused != null &amp;&amp; (mOrientationHelper.getDecoratedStart(focused) &gt;= mOrientationHelper.getEndAfterPadding() || mOrientationHelper.getDecoratedEnd(focused) &lt;= mOrientationHelper.getStartAfterPadding())) &#123; mAnchorInfo.assignFromViewAndKeepVisibleRect(focused, getPosition(focused)); &#125; // ... 如果 mPendingScrollPosition 有效，则会在 prelayout 阶段在用到这个值 if (state.isPreLayout() &amp;&amp; mPendingScrollPosition != RecyclerView.NO_POSITION &amp;&amp; mPendingScrollPositionOffset != INVALID_OFFSET) &#123; final View existing = findViewByPosition(mPendingScrollPosition); if (existing != null) &#123; final int current; final int upcomingOffset; if (mShouldReverseLayout) &#123; current = mOrientationHelper.getEndAfterPadding() - mOrientationHelper.getDecoratedEnd(existing); upcomingOffset = current - mPendingScrollPositionOffset; &#125; else &#123; current = mOrientationHelper.getDecoratedStart(existing) - mOrientationHelper.getStartAfterPadding(); upcomingOffset = mPendingScrollPositionOffset - current; &#125; if (upcomingOffset &gt; 0) &#123; extraForStart += upcomingOffset; &#125; else &#123; extraForEnd -= upcomingOffset; &#125; &#125; &#125; // ...省略根据布局方向调用 fill 方法填充&#125;// 更新 anchorInfoprivate boolean updateAnchorFromPendingData(RecyclerView.State state, AnchorInfo anchorInfo) &#123; //... // 简单理解，如果位置大于itemCount，不会更新 anchorInfo，并且清除 mPendingScrollPosition 的值 if (mPendingScrollPosition &lt; 0 || mPendingScrollPosition &gt;= state.getItemCount()) &#123; mPendingScrollPosition = RecyclerView.NO_POSITION; mPendingScrollPositionOffset = INVALID_OFFSET; if (DEBUG) &#123; Log.e(TAG, \"ignoring invalid scroll position \" + mPendingScrollPosition); &#125; return false; &#125; // ...&#125; 小结上面代码可以看出，如果scrollToPosition(position) 的参数 position 所在位置还没有view被layout，则滑动不会被处理。 同时也可以看出 scrollToPosition 是 LayoutManager 通过 requestLayout 方式来刷新 ReycclerView，所以并不会通知 onScrollStateChanged 这里额外介绍一下根据 mAnchor 和布局方向填充view的逻辑 圆形红点就是我们布局算法在第一步updateAnchorInfoForLayout方法中计算出来的填充锚点位置。 第一种情况是屏幕显示的位置在RecyclerView的最底部，那么就只有一种填充方向为formEnd 第二种情况是屏幕显示的位置在RecyclerView的顶部，那么也只有一种填充方向为formStart 第三种情况应该是最常见的，屏幕显示的位置在RecyclerView的中间，那么填充方向就有formEnd和formStart两种情况，这就是 fill 方法调用两次的原因。 上面是RecyclerView的方向为VERTICAL的情况，当为HORIZONTAL方向的时候填充算法是不变的。 smoothScrollBysmoothScrollBy有很多重载方法，直接看最终的： // RecyclerView.javavoid smoothScrollBy(@Px int dx, @Px int dy, @Nullable Interpolator interpolator, int duration, boolean withNestedScrolling) &#123; // ... 前面都是是否能滑动判断 if (dx != 0 || dy != 0) &#123; boolean durationSuggestsAnimation = duration == UNDEFINED_DURATION || duration &gt; 0; if (durationSuggestsAnimation) &#123; if (withNestedScrolling) &#123; int nestedScrollAxis = ViewCompat.SCROLL_AXIS_NONE; if (dx != 0) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_HORIZONTAL; &#125; if (dy != 0) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_VERTICAL; &#125; startNestedScroll(nestedScrollAxis, TYPE_NON_TOUCH); &#125; mViewFlinger.smoothScrollBy(dx, dy, duration, interpolator); &#125; else &#123; scrollBy(dx, dy); &#125; &#125;&#125; 最终调用了mViewFlinger.smoothScrollBy 方法：// ViewFlinger.smoothScrollBypublic void smoothScrollBy(int dx, int dy, int duration, @Nullable Interpolator interpolator) &#123; // Handle cases where parameter values aren't defined. if (duration == UNDEFINED_DURATION) &#123; duration = computeScrollDuration(dx, dy, 0, 0); &#125; if (interpolator == null) &#123; interpolator = sQuinticInterpolator; &#125; // If the Interpolator has changed, create a new OverScroller with the new // interpolator. if (mInterpolator != interpolator) &#123; mInterpolator = interpolator; mOverScroller = new OverScroller(getContext(), interpolator); &#125; // Reset the last fling information. mLastFlingX = mLastFlingY = 0; // 调用RecyclerView的setScrollState方法，通知滑动事件开始 setScrollState(SCROLL_STATE_SETTLING); mOverScroller.startScroll(0, 0, dx, dy, duration); if (Build.VERSION.SDK_INT &lt; 23) &#123; mOverScroller.computeScrollOffset(); &#125; postOnAnimation();&#125; 小结smoothScrollBy 调用了 RecyclerView.setScrollState方法，最终会通知 onScrollStateChanged 的监听 smoothScrollToPosition再来看下 smoothScrollToPosition// RecyclerView.javapublic void smoothScrollToPosition(int position) &#123; if (mLayoutSuppressed) &#123; return; &#125; if (mLayout == null) &#123; Log.e(TAG, \"Cannot smooth scroll without a LayoutManager set. \" + \"Call setLayoutManager with a non-null argument.\"); return; &#125; mLayout.smoothScrollToPosition(this, mState, position);&#125; 上面直接调用了LayoutManager的同名方法// LinearLayoutManager.java@Overridepublic void smoothScrollToPosition(RecyclerView recyclerView, RecyclerView.State state, int position) &#123; LinearSmoothScroller linearSmoothScroller = new LinearSmoothScroller(recyclerView.getContext()); linearSmoothScroller.setTargetPosition(position); startSmoothScroll(linearSmoothScroller);&#125; 可以看到每次调用方法，都会创建一个LinearSmoothScroller，LinearSmoothScroller的父类是RecyclerView.SmoothScroller 最终调用的是 mRecyclerView.mViewFlinger.postOnAnimation();ViewFlinger其实一个Runnable,在postOnAnimation()内部又将该Runnable发送出去了那么我们在看下ViewFlinger的run()方法就行了。// RecyclerView.ViewFlinger@Overridepublic void run() &#123; // ... final OverScroller scroller = mScroller; //获得layoutManger中的SmoothScroller final SmoothScroller smoothScroller = mLayout.mSmoothScroller; if (scroller.computeScrollOffset()) &#123;//如果是第一次走，会返回false // ...省略部分代码 if (mAdapter != null) &#123; mReusableIntPair[0] = 0; mReusableIntPair[1] = 0; scrollStep(unconsumedX, unconsumedY, mReusableIntPair); consumedX = mReusableIntPair[0]; consumedY = mReusableIntPair[1]; // ... &#125; if (consumedX != 0 || consumedY != 0) &#123; dispatchOnScrolled(consumedX, consumedY); &#125; &#125; if (smoothScroller != null) &#123; if (smoothScroller.isPendingInitialRun()) &#123; smoothScroller.onAnimation(0, 0); &#125; if (!mReSchedulePostAnimationCallback) &#123; smoothScroller.stop(); //stop if it does not trigger any scroll &#125; &#125; // ...&#125; 小结可以看出在ViewFlinger 的 run()方法中，调用了dispatchOnScrolled(consumedX, consumedY)，通知了onScrolled() 真正产生滑动距离consumedX、consumedY 的方法是 scrollStep() 。这个方法前面分析 scrollBy()方法的时候已经分析过了，最终会调用到每个view的offsetLeftAndRight()方法。 补充滚到到一个屏幕外的位置scrollToPosition 和 smoothScrollToPosition 只能保证指定位置的item滑动到屏幕可见，如果指定的item本来就已在屏幕可见范围，则不会滑动，并且屏幕外的item滑到可见范围后，还需手动置顶，手动置顶可以调用 LinearLayoutManager.scrollToPositionWithOffset(position, 0)recyclerView.scrollToPosition(pos);linearLayoutManager.scrollToPositionWithOffset(pos, 0) 还可以使用另一种方式：可以继承 LinearSmoothScroller，重写getVerticalSnapPreference()或getHorizontalSnapPreference()getVerticalSnapPreference()// LinearSmoothScrollerprotected int getHorizontalSnapPreference() &#123; return mTargetVector == null || mTargetVector.x == 0 ? SNAP_TO_ANY : mTargetVector.x &gt; 0 ? SNAP_TO_END : SNAP_TO_START;&#125;@Overrideprotected int getVerticalSnapPreference() &#123; // 子view与RecyclerView垂直方向顶部对齐 return SNAP_TO_START; &#125; 之后这样调用就可以：final TopSmoothScroller mTopScroller = new TopSmoothScroller(this);mTopScroller.setTargetPosition(position);mRecyclerView.getLayoutManager.startSmoothScroll(mTopScroller); 补充 scrollToPositionWithOffset这个方式是LinearLayoutManager才有的方法，RecyclerView没有。RecyclerView可以调用的是LinearLayoutManger.scrollToPosition(position) 这两个方法区别是区别是RecyclerView.scrollToPosition(position) 的 mPendingScrollPositionOffset 值为 INVALID_OFFSET = Integer.MIN_VALUEpublic void scrollToPositionWithOffset(int position, int offset) &#123; mPendingScrollPosition = position; mPendingScrollPositionOffset = offset; if (mPendingSavedState != null) &#123; mPendingSavedState.invalidateAnchor(); &#125; requestLayout();&#125; 前面也提到过了，这个方法第二个参数传0，可以让 position 位置对应的view置顶 同样这个方法是 LayoutManager 通过 requestLayout 方式来刷新 ReycclerView，所以并不会通知 onScrollStateChanged。 手势滑动手势处理肯定是在RecyclerView的onTouchEvent方法中了： @Overridepublic boolean onTouchEvent(MotionEvent e) &#123; switch (action) &#123; case MotionEvent.ACTION_MOVE: &#123; // ...判断手势索引，避免多指引起冲突 final int index = e.findPointerIndex(mScrollPointerId); final int x = (int) (e.getX(index) + 0.5f); final int y = (int) (e.getY(index) + 0.5f); int dx = mLastTouchX - x; int dy = mLastTouchY - y; if (mScrollState != SCROLL_STATE_DRAGGING) &#123; boolean startScroll = false; if (canScrollHorizontally) &#123; if (dx &gt; 0) &#123; dx = Math.max(0, dx - mTouchSlop); &#125; else &#123; dx = Math.min(0, dx + mTouchSlop); &#125; if (dx != 0) &#123; startScroll = true; &#125; &#125; if (canScrollVertically) &#123; if (dy &gt; 0) &#123; dy = Math.max(0, dy - mTouchSlop); &#125; else &#123; dy = Math.min(0, dy + mTouchSlop); &#125; if (dy != 0) &#123; startScroll = true; &#125; &#125; if (startScroll) &#123; // 可以滑动。设置状态 setScrollState(SCROLL_STATE_DRAGGING); &#125; &#125; if (mScrollState == SCROLL_STATE_DRAGGING) &#123; mReusableIntPair[0] = 0; mReusableIntPair[1] = 0; if (dispatchNestedPreScroll( // 处理 nested 联动 canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, mReusableIntPair, mScrollOffset, TYPE_TOUCH )) &#123; dx -= mReusableIntPair[0]; dy -= mReusableIntPair[1]; // Updated the nested offsets mNestedOffsets[0] += mScrollOffset[0]; mNestedOffsets[1] += mScrollOffset[1]; // Scroll has initiated, prevent parents from intercepting getParent().requestDisallowInterceptTouchEvent(true); &#125; mLastTouchX = x - mScrollOffset[0]; mLastTouchY = y - mScrollOffset[1]; if (scrollByInternal( // 调用 scrollByInternal() 让每个view自己滑动 canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, e)) &#123; getParent().requestDisallowInterceptTouchEvent(true); &#125; &#125; &#125; break; case MotionEvent.ACTION_UP: &#123; mVelocityTracker.addMovement(vtev); eventAddedToVelocityTracker = true; mVelocityTracker.computeCurrentVelocity(1000, mMaxFlingVelocity); final float xvel = canScrollHorizontally ? -mVelocityTracker.getXVelocity(mScrollPointerId) : 0; final float yvel = canScrollVertically ? -mVelocityTracker.getYVelocity(mScrollPointerId) : 0; // 跟踪滑动速度，是否采取 fling 操作 if (!((xvel != 0 || yvel != 0) &amp;&amp; fling((int) xvel, (int) yvel))) &#123; setScrollState(SCROLL_STATE_IDLE); &#125; resetScroll(); &#125; break; &#125;&#125; 小结这里分两种情况： 没有触发fling操作，直接调用scrollByInternal()方法，最终调用View的offsetLeftAndRight(offset)方法。 触发fling操作，由mViewFlinger.fling(velocityX, velocityY)处理，最终在 mViewFlinger的run()方法中，调用View的offsetLeftAndRight(offset)方法。 总结看到这里不知道大家有没有被绕晕，其实不管方法是哪个，都是调用每个子View的offsetLeftAndRight(offset)来实现列表的滑动 scrollTo &emsp; scrollBy scrollToPosition smoothScrollBy smoothScrollToPosition onScrolled 无反应 触发 位置可见无反应，否则触发 触发 位置可见无反应，否则触发 onScrollStateChanged 无反应 无反应 无反应 触发 位置可见无反应，否则触发 手势滑动两者都会触发，只不过因为放不下了，没有在表格里展示 :) REF图文详解LinearLayoutManager填充、测量、布局过程: https://www.jianshu.com/p/e9752f8890c8 View 的滑动原理和实现方式 : https://www.jianshu.com/p/a177869b0382 用SmoothScroller实现RecyclerView滚动到指定位置并置顶: https://blog.csdn.net/weixin_39428125/article/details/89032646 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"Kotlin 与 Java 语言比较","slug":"Diffrence-between-kotlin&Java","date":"2020-10-25T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2020/10/26/Diffrence-between-kotlin&Java/","link":"","permalink":"http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&Java/","excerpt":"本文整理了一些 Kotlin 与 Java 语言的区别，方便从Java转型学习Kotlin的同学。\nKotlin 解决了一些 Java 中的问题Kotlin 通过以下措施修复了 Java 中一系列长期困扰我们的问题：","text":"本文整理了一些 Kotlin 与 Java 语言的区别，方便从Java转型学习Kotlin的同学。 Kotlin 解决了一些 Java 中的问题Kotlin 通过以下措施修复了 Java 中一系列长期困扰我们的问题：+代表理解难度 空引用由类型系统控制（可空类型与非空类型）(+) 无原始类型(+) Kotlin 中数组是不型变的(++) 相对于 Java 的 SAM(Single Abstract Method)-转换，Kotlin 有更合适的函数类型(++) 没有通配符的使用处型变(+++) Kotlin 没有受检异常(+)Java 有而 Kotlin 没有的东西 受检异常 原始类型 —— 字节码会尽可能试用原生类型，但不是显式可用的。 静态成员 —— 以 伴生对象、 顶层函数、 扩展函数 或者 @JvmStatic 取代。 通配符类型 —— 以 声明处协变 与 类型投影 取代。 三目操作符 a ? b : c —— 以 if 表达式取代Kotlin 有而 Java 没有的东西 Lambda 表达式 + 内联函数 = 高性能自定义控制结构(++) 扩展函数 空安全 智能类型转换 字符串模板 类的属性 主构造函数 委托 变量与属性类型的类型推断 单例 声明处型变 &amp; 类型投影 区间表达式 in a...b step 2 操作符重载 operator关键字 伴生对象 companion 数据类 data class A 密封类 sealed class A 分离用于只读与可变集合的接口 MutableList, MutableSet, MutableMap 协程 数组支持泛型，不会协变 空安全var a: String = \"abc\" // 默认情况下，常规初始化意味着非空a = null // 编译错误var b: String? = \"abc\" // 可以设置为空b = null // okprint(b)val l = b.length // 错误：变量“b”可能为空 但是我们还是需要访问该属性，对吧？有几种方式可以做到 在条件中检测 null首先，可以显式检测 b 是否为 null，并分别处理两种可能：val l = if (b != null) b.length else -1 安全的调用第二个选择是安全调用操作符，写作 ?.val a = \"Kotlin\"val b: String? = nullprintln(b?.length)println(a?.length) // 无需安全调用 如果 b 非空，就返回 b.length，否则返回 null，这个表达式的类型是 Int?。 对集合，如果要只对非空值执行某个操作，安全调用操作符可以与 let 一起使用：val listWithNulls: List&lt;String?&gt; = listOf(\"Kotlin\", null)for (item in listWithNulls) &#123; item?.let &#123; println(it) &#125; // 输出 Kotlin 并忽略 null&#125; 安全调用也可以出现在赋值的左侧。这样，如果调用链中的任何一个接收者为空都会跳过赋值，而右侧的表达式根本不会求值：// 如果 `person` 或者 `person.department` 其中之一为空，都不会调用该函数：person?.department?.head = managersPool.getManager() Elvis 操作符当我们有一个可空的引用 b 时，我们可以说“如果 b 非空，我使用它；否则使用某个非空的值”：val l: Int = if (b != null) b.length else -1 除了完整的 if-表达式，这还可以通过 Elvis 操作符表达，写作 ?:：val l = b?.length ?: -1 如果 ?: 左侧表达式非空，elvis 操作符就返回其左侧表达式，否则返回右侧表达式。 请注意，当且仅当左侧为空时，才会对右侧表达式求值。 !! 操作符第三种选择是为 NPE 爱好者准备的：非空断言运算符（!!）将任何值转换为非空类型，若该值为空则抛出异常。我们可以写 b!! ，这会返回一个非空的 b 值 （例如：在我们例子中的 String）或者如果 b 为空，就会抛出一个 NPE 异常：val l = b!!.length 安全的类型转换如果对象不是目标类型，那么常规类型转换可能会导致 ClassCastException。 另一个选择是使用安全的类型转换，如果尝试转换不成功则返回 null：val aInt: Int? = a as? Int 可空类型的集合如果你有一个可空类型元素的集合，并且想要过滤非空元素，你可以使用 filterNotNull 来实现：val nullableList: List&lt;Int?&gt; = listOf(1, 2, null, 4)val intList: List&lt;Int&gt; = nullableList.filterNotNull() kotlin无原始类型在 Kotlin 中，所有东西都是对象，在这个意义上讲我们可以在任何变量上调用成员函数与属性。 一些类型可以有特殊的内部表示——例如，数字、字符以及布尔值可以在运行时表示为原生类型值，但是对于用户来说，它们看起来就像普通的类val b: Byte = 1val c:Double = b.toDouble() 型变Java 类型系统中最棘手的部分之一是通配符类型（T，E，K，V，？）。 而 Kotlin 中没有。 相反，它有两个其他的东西：型变（variance）与类型投影（type projections），型变包括声明处型变和使用处型变。 首先，让我们思考为什么 Java 需要那些神秘的通配符。在 《Effective Java》第三版 解释了该问题——第 31 条：利用有限制通配符来提升 API 的灵活性。首先，Java 中的泛型是不型变的，这意味着 List&lt;String&gt; 并不是 List&lt;Object&gt;的子类型。为什么这样？ 如果 List 不是不型变的，它就没比 Java 的数组好到哪去，因为如下代码会通过编译然后导致运行时异常：// JavaList&lt;String&gt; strs = new ArrayList&lt;String&gt;();List&lt;Object&gt; objs = strs; // ！！！此处的编译器错误让我们避免了之后的运行时异常objs.add(1); // 这里我们把一个整数放入一个字符串列表String s = strs.get(0); // ！！！ ClassCastException：无法将整数转换为字符串 因此，Java 禁止这样的事情以保证运行时的安全。但这样会有一些影响。例如，考虑 Collection 接口中的 addAll() 方法。该方法的签名应该是什么？直觉上，我们会这样：// Javainterface Collection&lt;E&gt; …… &#123; void addAll(Collection&lt;E&gt; items);&#125; 但随后，我们就无法做到以下简单的事情（这是完全安全）// Javavoid copyAll(Collection&lt;Object&gt; to, Collection&lt;String&gt; from) &#123; to.addAll(from); // ！！！对于这种简单声明的 addAll 将不能编译： // Collection&lt;String&gt; 不是 Collection&lt;Object&gt; 的子类型&#125; （在 Java 中，我们艰难地学到了这个教训，参见《Effective Java》第三版，第 28 条：列表优先于数组） 这就是为什么 addAll() 的实际签名是以下这样：// Javainterface Collection&lt;E&gt; …… &#123; void addAll(Collection&lt;? extends E&gt; items);&#125; 通配符类型参数 ? extends E 表示此方法接受 E 或者 E 的 一些子类型对象的集合，而不只是 E 自身。 这意味着我们可以安全地从其中（该集合中的元素是 E 的子类的实例）读取 E，但不能写入， 因为我们不知道什么对象符合那个未知的 E 的子类型。 反过来，该限制可以让Collection&lt;String&gt;表示为Collection&lt;? extends Object&gt;的子类型。 简而言之，带 extends 限定（上界）的通配符类型使得类型是协变的（covariant）。 理解为什么这个技巧能够工作的关键相当简单：如果只能从集合中获取元素，那么使用 String 的集合， 并且从其中读取 Object 也没问题 。反过来，如果只能向集合中 放入 元素，就可以用 Object 集合并向其中放入 String：在 Java 中有 List&lt;? super String&gt; 是 List&lt;Object&gt; 的一个超类。 后者称为 逆变性（contravariance），并且对于 List &lt;? super String&gt; 你只能调用接受 String 作为参数的方法 （例如，你可以调用 add(String) 或者 set(int, String)），当然如果调用函数返回 List&lt;T&gt; 中的 T，你得到的并非一个 String 而是一个 Object。 看一个关于java通配符集合的经典图： Joshua Bloch 称那些你只能从中读取的对象为生产者，并称那些你只能写入的对象为消费者。他建议：“为了灵活性最大化，在表示生产者或消费者的输入参数上使用通配符类型”，并提出了以下助记符： PECS 代表生产者-Extends、消费者-Super（Producer-Extends, Consumer-Super）。 注意：如果你使用一个生产者对象，如 List&lt;? extends Foo&gt;，在该对象上不允许调用 add() 或 set()。但这并不意味着该对象是不可变的：例如，没有什么阻止你调用 clear()从列表中删除所有元素，因为 clear() 根本无需任何参数。通配符（或其他类型的型变）保证的唯一的事情是类型安全。不可变性完全是另一回事。 Kotlin 中的 Java 泛型Kotlin 的泛型与 Java 有点不同。当将 Java 类型导入 Kotlin 时，我们会执行一些转换： 消费者 in, 生产者 out! :-) Java 的通配符转换成类型投影 Foo&lt;? extends Bar&gt; 转换成 Foo&lt;out Bar!&gt;! Foo&lt;? super Bar&gt; 转换成 Foo&lt;in Bar!&gt;! Java的原始类型转换成星投影 List 转换成 List&lt;*&gt;!，即 List&lt;out Any?&gt;! 如果泛型类型具有多个类型参数，则每个类型参数都可以单独投影。 例如，如果类型被声明为 interface Function &lt;in T, out U&gt;，我们可以想象以下星投影： Function&lt;*, String&gt; 表示 Function&lt;in Nothing, String&gt;； Function&lt;Int, *&gt; 表示 Function&lt;Int, out Any?&gt;； Function&lt;*, *&gt; 表示 Function&lt;in Nothing, out Any?&gt;。 注意：星投影非常像 Java 的原始类型，但是安全。 和 Java 一样，Kotlin 在运行时不保留泛型，即对象不携带传递到他们构造器中的那些类型参数的实际类型。 即 ArrayList&lt;Integer&gt;() 和 ArrayList&lt;Character&gt;() 是不能区分的。 这使得执行 is-检测不可能照顾到泛型。 Kotlin 只允许 is-检测星投影的泛型类型：if (a is List&lt;Int&gt;) // 错误：无法检测它是否真的是一个 Int 列表// butif (a is List&lt;*&gt;) // OK：不保证列表的内容 类型投影的使用处型变fun copy(from: Array&lt;out Any&gt;, to: Array&lt;Any&gt;) &#123; …… &#125; 简单介绍下，这里 out 修饰的数组只能调用 get()，对应于 Java 的 Array&lt;? extends Object&gt;。fun fill(dest: Array&lt;in String&gt;, value: String) &#123; …… &#125; Array&lt;in String&gt; 对应于 Java 的 Array&lt;? super String&gt;，也就是说，你可以传递一个 CharSequence 数组或一个 Object 数组给 fill() 函数。 Kotlin 中数组是不型变的Kotlin 中数组是不型变的（invariant）。这意味着 Kotlin 不让我们把 Array&lt;String&gt;赋值给 Array&lt;Any&gt;，以防止可能的运行时失败。 但是你可以使用 Array&lt;out Any&gt; 创建数组 arrayOf() 函数我们可以使用库函数 arrayOf() 来创建一个数组并传递元素值给它，这样 arrayOf(1, 2, 3) 创建了 array [1, 2, 3]。 val a = arrayOf(\"Hello\", \"world\")// 这里，arrayOf() 函数创建了一个 Array&lt;String&gt; 对象val arr = arrayOf(\"aaa\", \"bbb\", 123, true) // Array&lt;Any&gt;println(arr[2]) emptyArray() 函数 // emptyArray() 函数是创建一个长度为 0 的 null 数组，然后将它强制转换为指定类型的数组。// 所以我们可以用 arrayOfNulls&lt;T&gt;(0) 替代 emptyArray() 函数// 因为 emptyArray() 函数需要转换为特定的数组类型，所以定义变量需要指定数组类型，否则出现编译错误val emptyArray1: Array&lt;String?&gt; = emptyArray()// 也可以写成 val emptyArray2: Array&lt;String?&gt; = arrayOfNulls(0)，这里是类型推断val emptyArray2 = arrayOfNulls&lt;String?&gt;(0)println(Arrays.equals(emptyArray1, emptyArray2)) // 输出 true arrayOfNulls() 函数 val fixedSizeArray = arrayOfNulls&lt;Int&gt;(5)// 直接指定长度，返回一个长度指定、所有值都是 null 的数组。 不使用 Array 类, 使用装箱操作比如, 对于 Int 类型数组, 使用 IntArray 类替代 Array 类： val arr = arrayOf(1, 2, 3)val intArr = intArrayOf(1, 2, 3) //同理还有 booleanArrayOf() 等 声明处型变假设有一个泛型接口 Source&lt;T&gt;，该接口中不存在任何以 T 作为参数的方法，只是方法返回 T 类型值：// Javainterface Source&lt;T&gt; &#123; T nextT();&#125; 那么，在 Source &lt;Object&gt; 类型的变量中存储 Source &lt;String&gt;实例的引用是极为安全的——没有消费者-方法可以调用。但是 Java 并不知道这一点，并且仍然禁止这样操作：// Javavoid demo(Source&lt;String&gt; strs) &#123; Source&lt;Object&gt; objects = strs; // ！！！在 Java 中不允许 // ……&#125; 为了修正这一点，我们必须声明对象的类型为 Source&lt;? extends Object&gt;，这是毫无意义的，因为我们可以像以前一样在该对象上调用所有相同的方法，所以更复杂的类型并没有带来价值。但编译器并不知道。 在 Kotlin 中，有一种方法向编译器解释这种情况。这称为声明处型变：我们可以标注 Source 的类型参数 T 来确保它仅从 Source&lt;T&gt; 成员中返回（生产），并从不被消费。 为此，我们提供 out 修饰符：interface Source&lt;out T&gt; &#123; fun nextT(): T&#125;​fun demo(strs: Source&lt;String&gt;) &#123; val objects: Source&lt;Any&gt; = strs // 这个没问题，因为 T 是一个 out-参数 // ……&#125; 一般原则是：当一个类 C 的类型参数 T 被声明为 out 时，它就只能出现在 C 的成员的输出-位置，但回报是 C&lt;Base&gt; 可以安全地作为 C&lt;Derived&gt;的超类。 简而言之，他们说类 C 是在参数 T 上是协变的，或者说 T 是一个协变的类型参数。 你可以认为 C 是 T 的生产者，而不是 T 的消费者。 这里，out 由于它在类型参数声明处提供，所以我们称之为声明处型变. 泛型函数不仅类可以有类型参数。函数也可以有。类型参数要放在函数名称之前fun &lt;T&gt; singletonList(item: T): List&lt;T&gt; &#123; // ……&#125;fun &lt;T&gt; T.basicToString(): String &#123; // 扩展函数 // ……&#125; 要调用泛型函数，在调用处函数名之后指定类型参数即可：val l = singletonList&lt;Int&gt;(1) 可以省略能够从上下文中推断出来的类型参数，所以以下示例同样适用：val l = singletonList(1) 泛型函数约束的上界 最常见的约束类型是与 Java 的 extends 关键字对应的 上界： fun &lt;T : Comparable&lt;T&gt;&gt; sort(list: List&lt;T&gt;) &#123; …… &#125; 冒号之后指定的类型是上界：只有 Comparable 的子类型可以替代 T。 例如： sort(listOf(1, 2, 3)) // OK。Int 是 Comparable&lt;Int&gt; 的子类型sort(listOf(HashMap&lt;Int, String&gt;())) // 错误：HashMap&lt;Int, String&gt; 不是sort(listOf(1, 2, 3)) // OK。Int 是 Comparable&lt;Int&gt; 的子类型sort(listOf(HashMap&lt;Int, String&gt;())) // 错误：HashMap&lt;Int, String&gt; 不是 Comparable&lt;HashMap&lt;Int, String&gt;&gt; 的子类型 默认的上界（如果没有声明）是 Any?。在尖括号中只能指定一个上界。 如果同一类型参数需要多个上界，我们需要一个单独的 where-子句： fun &lt;T&gt; copyWhenGreater(list: List&lt;T&gt;, threshold: T): List&lt;String&gt; where T : CharSequence, T : Comparable&lt;T&gt; &#123; return list.filter &#123; it &gt; threshold &#125;.map &#123; it.toString() &#125;&#125; 所传递的类型必须同时满足 where 子句的所有条件。在上述示例中，类型 T 必须既实现了 CharSequence 也实现了 Comparable。 Kotlin与java8的 SAM 转换对比只有一个抽象方法的接口称为函数式接口或 SAM（Single Abstract Method 单一抽象方法）接口。函数式接口可以有多个非抽象成员，但只能有一个抽象成员。SAM 实际上这是java8中提出的概念，你就把他理解为是只有一个抽象方法的接口的就可以了 可以用 fun 修饰符在 Kotlin 中声明一个函数式接口。fun interface KRunnable &#123; fun invoke()&#125; SAM 转换对于函数式接口，可以通过 lambda 表达式实现 SAM 转换，从而使代码更简洁、更有可读性。 使用 lambda 表达式可以替代手动创建实现函数式接口的类。 通过 SAM 转换， Kotlin 可以将其签名与接口的单个抽象方法的签名匹配的任何 lambda 表达式转换为实现该接口的类的实例。例如，有这样一个 Kotlin 函数式接口：fun interface IntPredicate &#123; fun accept(i: Int): Boolean&#125; 如果不使用 SAM 转换，那么你需要像这样编写代码：// 创建一个类的实例val isEven = object : IntPredicate &#123; override fun accept(i: Int): Boolean &#123; return i % 2 == 0 &#125;&#125; 通过利用 Kotlin 的 SAM 转换，可以改为以下等效代码：// 通过 lambda 表达式创建一个实例val isEven = IntPredicate &#123; it % 2 == 0 &#125; 可以通过更短的 lambda 表达式替换所有不必要的代码。 fun interface IntPredicate &#123; fun accept(i: Int): Boolean&#125;​val isEven = IntPredicate &#123; it % 2 == 0 &#125;​fun main() &#123; println(\"Is 7 even? - $&#123;isEven.accept(7)&#125;\")&#125; 再看一个开发中用到的代码：ExecutorService executorService= Executors.newScheduledThreadPool(3); executorService.execute(new Runnable() &#123; @Override public void run() &#123; System.out.println(\"hello world\"); &#125; &#125;); 用下面的java8中的lambda 来写 也是可以的。executorService.execute(()-&gt;System.out.println(\"hello world\")); kotlin中的lambda 这里可以这么写val executorService: ExecutorService = Executors.newScheduledThreadPool(3)//kotlin中的 匿名内部类的标准写法executorService.submit(object :Runnable&#123; // object 作为关键字，这里代表对象表示 override fun run() &#123; System.out.println(\"hello world\") &#125;&#125;)// 使用lambda表达式的精简写法executorService.submit &#123; System.out.println(\"hello world\") &#125; 这个kotlin的lambda的类型就是 ()-&gt;Unit 是一个没有参数也没有返回值的类型 kotlin编译器遇到上面的代码，实际上是帮我们生成了一个函数：fun Runnable(block:() -&gt; Unit):Runnable &#123; return object: Runnable &#123; override fun run() &#123; block() &#125; &#125;&#125; 这个Runnable函数的意思是接收一个方法，别名是 block，返回一个Runnable对象，并在Runnable对象的run方法中，调用 block 方法。这里的 ()-&gt;Unit 是一个kotlin函数类型 函数类型Kotlin 使用类似 (Int) -&gt; String 的一系列函数类型来处理函数的声明. 这些类型具有与函数签名相对应的特殊表示法，即它们的参数和返回值： 所有函数类型都有一个圆括号括起来的参数类型列表以及一个返回类型：(A, B) -&gt; C表示接受类型分别为 A 与 B 两个参数并返回一个 C 类型值的函数类型。 参数类型列表可以为空，如 () -&gt; A。Unit 返回类型不可省略。 函数类型可以有一个额外的接收者类型，它在表示法中的点之前指定： 类型 A.(B) -&gt; C 表示可以在 A 的接收者对象上以一个 B 类型参数来调用并返回一个 C 类型值的函数。 带有接收者的函数字面值通常与这些类型一起使用。 挂起函数属于特殊种类的函数类型，它的表示法中有一个 suspend 修饰符 ，例如 suspend () -&gt; Unit或者 suspend A.(B) -&gt; C。 函数类型表示法可以选择性地包含函数的参数名：(x: Int, y: Int) -&gt; Point。 这些名称可用于表明参数的含义。 如需将函数类型指定为可空，请使用圆括号：((Int, Int) -&gt; Int)?。 函数类型可以使用圆括号进行接合：(Int) -&gt; ((Int) -&gt; Unit) 箭头表示法是右结合的，(Int) -&gt; (Int) -&gt; Unit 与前述示例等价，但不等于 ((Int) -&gt; (Int)) -&gt; Unit。 还可以通过使用类型别名给函数类型起一个别称： typealias ClickHandler = (Button, ClickEvent) -&gt; Unit 函数类型实例化及调用 使用 lambda 表达式或匿名函数进行实例化 var onItemClick:(Int, String) -&gt; Unit = &#123; a:Int, b:String -&gt; Log.e(\"AAA\", \"aaa$a$b\") // 配合lambda表达式&#125;onItemClick.invoke(1, \"2\")onItemClick(1, \"2\") // 这两种方式都可以val f:(Int, String) -&gt; String = fun(a:Int, b:String):String &#123; return \"aaa$a$b\" // 使用匿名函数进行实例化&#125;f.invoke(1, \"2\") 使用实现函数类型接口的自定义类的实例。下例中可直接使用 Test()(111) private class Test:(Int)-&gt;String&#123; override fun invoke(p1: Int): String = \"$p1 xxxx\"&#125; 函数引用及属性引用 val intPlus: Int.(Int) -&gt; Int = Int::plus// 下面三种方式都可以使用intPlus.invoke(1, 1)intPlus(1, 2)2.intPlus(3) :: 表示创建一个函数成员引用或者一个类引用 函数引用fun isOdd(x: Int) = x % 2 != 0 我们可以很容易地直接调用它（isOdd(5)），但是我们也可以将其作为一个函数类型的值，例如将其传给另一个函数。为此，我们使用 :: 操作符：val numbers = listOf(1, 2, 3)println(numbers.filter(::isOdd)) 这里 ::isOdd 是函数类型 (Int) -&gt; Boolean 的一个值。 等同于下面使用形参odd的方式val odd:(x: Int) -&gt; Boolean = &#123;x:Int -&gt; x % 2 != 0&#125;val numbers = listOf(1, 2, 3)println(numbers.filter(odd)) 类引用最基本的反射功能是获取 Kotlin 类的运行时引用。要获取对静态已知的 Kotlin 类的引用，可以使用 类字面值 语法：val c = MyClass::class 该引用是 KClass 类型的值。 请注意，Kotlin 类引用与 Java 类引用不同。要获得 Java 类引用， 请在 KClass 实例上使用 .java 属性val d = MyClass::class.java Kotlin中的异常Kotlin 中所有异常类都是 Throwable 类的子孙类。 每个异常都有消息、堆栈回溯信息以及可选的原因 try 是一个表达式，即它可以有一个返回值：val a: Int? = try &#123; parseInt(input) &#125; catch (e: NumberFormatException) &#123; null &#125; try-表达式的返回值是 try 块中的最后一个表达式或者是（所有）catch 块中的最后一个表达式。 finally 块中的内容不会影响表达式的结果 受检的异常受检查异常要用 try-catch 捕获，要么抛出，否则会发生编译错误。而 kotlin 中没有受检查异常，所有异常都是运行时异常，即便是原本在 Java 中的受检查异常，在 kotlin 中也是运行时异常，例如：IOException 在 Java 中是受检查异常，在 kotlin 中是运行时异常。 以下是 JDK 中 StringBuilder 类实现的一个示例接口：public int readNumber(BufferedReader reader) throws IOException &#123; int result = 0; String line = reader.readLine(); // 这里要么在方法声明上抛出，要么在内部捕获处理，否则无法编译通过 result = Integer.parseInt(line); reader.close(); return result;&#125; 这并不好，参见《Effective Java》第三版 第 77 条：不要忽略异常。 通过一些小程序测试得出的结论是异常规范会同时提高开发者的生产力与代码质量，但是大型软件项目的经验表明一个不同的结论——生产力降低、代码质量很少或没有提高。 kotlin实现静态成员的方式在 kotin 语言中其实没有 java static 的这个概念，基本都是用一个静态对象来模拟 class 的静态属性和方法，目前有4种实现方式： 伴生对象——声明单例的方式类内部的对象声明可以用 companion 关键字标记，这样它就与外部类关联在一起，我们就可以直接通过外部类访问到对象的内部元素。即可以声明属性，也可以声明方法，kotlin 中的调用方式感觉和 java 的 static 一样class BookKotlin &#123; var name: String = \"AA\" fun speak() &#123;&#125; companion object instance &#123; var nameStatic: String = \"BB\" fun speakStatic() &#123;&#125; &#125;&#125; 调用方式为：BookKotlin.nameStaticBookKotlin.speakStatic() 将kotlin代码转为java代码后，调用方式如下：BookKotlin.instance.getNameStatic()BookKotlin.instance.setNameStatic(String s)BookKotlin.instance.speakStatic() 注意：一个类里面只能声明一个内部关联对象，即关键字 companion 只能使用一次。 kotlin 中所有的成员变量，不管是不是 static 的都有 get/set 方法，另外 kotlin 并没有把我们声明的静态参数和方法声明成 static 的，而是通过 instance 这个静态对象中转使用的 @JvmField + @JvmStatic 注解声明成员和方法使用 JVM 提供的特性 @JvmField - 修饰静态变量 @JvmStatic - 修饰静态方法 @JvmField 和 @JvmStatic 只能写在 object 修饰的类或者 companion object 里，写法虽然有些别扭，但是效果是真的是按 static 来实现的 修改一下上面代码：class BookKotlin &#123; companion object &#123; @JvmField var nameStatic: String = \"BB\" @JvmStatic fun speakStatic() &#123; &#125; &#125; var name: String = \"AA\" fun speak() &#123;&#125;&#125; object 单例kotlin 自身提供了一种单例实现方式：object ，直接用来修饰 class ，用 object 修饰的类不能 new 对象，只能使用 object 提供的单例object BookKotlin &#123; var name: String = \"AA\" fun speak() &#123;&#125;&#125; Kotlin中使用如下：BookKotlin.nameBookKotlin.speak() constconst 写在 class 外面，效果 = @JvmField，但是不能修饰方法，也不能和 @JvmField 混用，一般就是用来声明常用值的，用处不多，而且只能用 val ，var 不行，想要修饰方法的话，不写 const 就行const val name: String = \"AA\"fun adk()&#123;&#125;class BookKotlin &#123; fun speak() &#123;&#125;&#125; kotlin没有三目运算符用表达式if() ... else ... 或 if () ... else if () ... else ... 代替 var number = if(n&gt;0) \"Positive\" else if(n&lt;0) \"Negative\" else \"Zero\"// 这一行比三元运算符简单得多，可读性也更强 Kotlin内联函数Java 方法执行的内存模型是基于 Java 虚拟机栈的：每个方法被执行的时候都会创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧入栈、出栈的过程。也就是说每调用一个方法，都会对应一个栈帧的入栈出栈过程，如果你有一个工具类方法，在某个循环里调用很多次，那就会对应很多次的栈帧入栈、出栈过程。这里首先要记住的一点是，栈帧的创建及入栈、出栈都是有性能损耗的。下面以一个例子来说明，看段代码片段：fun test() &#123; //多次调用 sum() 方法进行求和运算 println(sum(1, 2, 3)) println(sum(100, 200, 300)) println(sum(12, 34)) //....可能还有若干次&#125;fun sum(vararg ints: Int): Int &#123; var sum = 0 for (i in ints) &#123; sum += i &#125; return sum&#125; 在测试方法 test() 里，我们多次调用了 sum() 方法。为了避免多次调用 sum() 方法带来的性能损耗，我们期望的代码类似这样子的：fun test() &#123; var sum = 0 for (i in arrayOf(1, 2, 3)) &#123; sum += i &#125; println(sum) sum = 0 for (i in arrayOf(100, 200, 300)) &#123; sum += i &#125; println(sum) sum = 0 for (i in arrayOf(12, 34)) &#123; sum += i &#125; println(sum)&#125; 3次数据求和操作，都是在 test() 方法里执行的，没有之前的 sum() 方法调用，最后的结果依然是一样的，但是由于减少了方法调用，虽然代码量增加了，但是性能确提升了。那么怎么实现这种情况呢，一般工具类有很多公共方法，我总不能在需要调用这些公共方法的地方，把代码复制一遍吧，内联就是为了解决这一问题。 定义内联函数：inline fun sum(vararg ints: Int): Int &#123; var sum = 0 for (i in ints) &#123; sum += i &#125; return sum&#125; 如上所示，用关键字 inline 标记函数，该函数就是一个内联函数。还是原来的 test() 方法，编译器在编译的时候，会自动把内联函数 sum() 方法体内的代码，替换到调用该方法的地方。查看编译后的字节码，会发现 test() 方法里已经没了对 sum() 方法的调用，凡是原来代码里出现 sum() 方法调用的地方，出现的都是 sum() 方法体内的字节码了。 注意，内联可能导致生成的代码增加；不过如果我们使用得当（即避免内联过大函数），性能上会有所提升，尤其是在循环中的“超多态（megamorphic）”调用处。 禁用内联如果一个内联函数的参数里包含 lambda表达式，也就是函数参数，那么该形参也是 inline 的，举个例子：inline fun test(inlined: () -&gt; Unit) &#123;...&#125; 这里有个问题需要注意，如果在内联函数的内部，函数参数被其他非内联函数调用，就会报错，如下所示：//内联函数inline fun test(inlined: () -&gt; Unit) &#123; //这里会报错 otherNoinlineMethod(inlined) &#125;//非内联函数fun otherNoinlineMethod(oninline: () -&gt; Unit) &#123; &#125; 要解决这个问题，必须为内联函数的参数加上 noinline 修饰，表示禁止内联，保留原有函数的特性，所以 test() 方法正确的写法应该是：inline fun test(noinline inlined: () -&gt; Unit) &#123; otherNoinlineMethod(inlined)&#125; 注意，如果一个内联函数没有可内联的函数参数并且没有具体化的类型参数，编译器会产生一个警告，因为内联这样的函数很可能并无益处（如果你确认需要内联，则可以用 @Suppress(“NOTHING_TO_INLINE”) 注解关掉该警告 非局部返回在 Kotlin 中，我们只能对具名或匿名函数使用正常的、非限定的 return 来退出。 这意味着要退出一个 lambda 表达式，我们必须使用一个标签，并且在 lambda 表达式内部禁止使用裸 return，因为 lambda 表达式不能使包含它的函数返回：fun test() &#123; innerFun &#123; //return 会报错，非局部返回，直接退出 test() 函数。 return@innerFun //局部返回，只退出 innerFun() 函数 &#125; //以下代码依旧会执行 println(\"test...\")&#125;fun innerFun(a: () -&gt; Unit) &#123; a()&#125; 非局部返回我的理解就是返回到顶层函数，如上面代码中所示，默认情况下是不能直接 return 的，但是内联函数确是可以的。所以改成下面这个样子fun test() &#123; innerFun &#123; return //非局部返回，直接退出 test() 函数。 &#125; //以下代码不会执行 println(\"test...\")&#125;inline fun innerFun(a: () -&gt; Unit) &#123; a()&#125; 也就是说内联函数的函数参数在调用时，可以非局部返回，如上所示。那么 crossinline 修饰的 lambda 参数，可以禁止内联函数调用时非局部返回。fun test() &#123; innerFun &#123; return //这里这样会报错，只能 return@innerFun &#125; //以下代码不会执行 println(\"test...\")&#125;inline fun innerFun(crossinline a: () -&gt; Unit) &#123; a()&#125; 具体化的类型参数有时候我们需要访问一个作为参数传给我们的一个类型：fun &lt;T&gt; TreeNode.findParentOfType(clazz: Class&lt;T&gt;): T? &#123; var p = parent while (p != null &amp;&amp; !clazz.isInstance(p)) &#123; p = p.parent &#125; @Suppress(\"UNCHECKED_CAST\") return p as T?&#125; 在这里我们向上遍历一棵树并且检测每个节点是不是特定的类型。 这都没有问题，但是调用处不是很优雅：treeNode.findParentOfType(MyTreeNode::class.java) 我们真正想要的只是传一个类型给该函数，即像这样调用它：treeNode.findParentOfType&lt;MyTreeNode&gt;() 为能够这么做，内联函数支持具体化的类型参数，于是我们可以这样写：inline fun &lt;reified T&gt; TreeNode.findParentOfType(): T? &#123; var p = parent while (p != null &amp;&amp; p !is T) &#123; p = p.parent &#125; return p as T?&#125; 我们使用 reified 修饰符来限定类型参数，现在可以在函数内部访问它了， 几乎就像是一个普通的类一样。由于函数是内联的，不需要反射，正常的操作符如 !is 和 as 现在都能用了。此外，我们还可以按照上面提到的方式调用它：myTree.findParentOfType&lt;MyTreeNodeType&gt;()。 再举个栗子：inline fun &lt;reified T: Activity&gt; startActivity() &#123; startActivity(Intent(this, T::class.java))&#125; 使用时直接传入泛型即可，代码简洁明了：startActivity&lt;MainActivity&gt;() 扩展函数扩展函数可以在已有类中添加新的方法，不会对原类做修改，扩展函数定义形式：fun receiverType.functionName(params)&#123; body&#125; receiverType：表示函数的接收者，也就是函数扩展的对象functionName：扩展函数的名称params：扩展函数的参数，可以为NULL 以下实例扩展 User 类 ：class User(var name:String)/**扩展函数**/fun User.Print()&#123; print(\"用户名 $name\")&#125;fun main(arg:Array&lt;String&gt;)&#123; var user = User(\"Runoob\") user.Print()&#125; 类的属性Kotlin 类的属性可以声明为可变的（var）或者是只读的（val），声明一个属性的完整语法如下：var &lt;propertyName&gt;[: &lt;PropertyType&gt;] [= &lt;property_initializer&gt;] [&lt;getter&gt;] [&lt;setter&gt;]val &lt;propertyName&gt;[: &lt;PropertyType&gt;] [= &lt;property_initializer&gt;] [&lt;getter&gt;] 以一个简单的 Student 类为例：class Student(_name: String, _age: Int) &#123; val name: String = _name var age: Int = _age val isAdult: Boolean get() = this.age &gt;= 18&#125; 这里声明 name 和 age 时确实是有 getter 和 setter 方法的，只是被省略了而已，我们以为的不省略写法如下（错误的）：class Student(_name: String, _age: Int) &#123; val name = _name // Initializer is not allowed here because this property has no backing field get() = this.name // Recursive call var age = _age // Initializer is not allowed here because this property has no backing field get() = this.age // Recursive call set(value) &#123; this.age = value // Recursive call &#125;&#125; this.name 会造成 Recursive call（递归调用）。我们看一下是怎么回事： 第一步，调用 student.name； 第二步，调用 get() 方法； 第三步，在 get() 方法里，调用 this.name； 第一步，调用 student.name； 第二步，调用 get() 方法； … 这样就形成了递归调用了 get() 方法，并且没有终止条件，所以是有问题的。 另一条错误信息提示没有backing field，也叫幕后字段 backing fieldKotlin 类中不能直接声明 Fields。然而，当一个属性需要一个 backing field 时，Kotlin 会自动地提供它。在访问器中使用 field 标识符就可以引用到 backing field 看下官方文档里的例子：var counter = 0 // Note: the initializer assigns the backing field directly set(value) &#123; if (value &gt;= 0) field = value &#125; 改写一下刚才的Student类：class Student(_name: String, _age: Int) &#123; val name = _name get() = field // redundant var age = _age get() = field // redundant set(value) &#123; // redundant field = value &#125; val isAdult: Boolean get() = this.age &gt;= 18&#125; Backing Properties如果上面的方案都不符合你的需求，那么可以试试“后端属性”(backing property)的方法，它实际上也是隐含试的对属性值的初始化声明，避免了空指针。class Student(_name: String, _age: Int) &#123; val name = _name var age = _age private var _grades: Map&lt;String, Int&gt;? = null // 私有属性，后端属性 val grades: Map&lt;String, Int&gt; get() &#123; if (_grades == null) &#123; // 只有在首次访问时才加载成绩信息，并只执行一次 _grades = loadGrades() &#125; return _grades!! &#125; private fun loadGrades(): MutableMap&lt;String, Int&gt; &#123; println(\"loadGrades() called\") val result = mutableMapOf&lt;String, Int&gt;() result.put(\"Chinese\", 100) result.put(\"Math\", 99) result.put(\"English\", 100) return result &#125;&#125; Kotlin 独有的一些细节主构造函数在Kotlin类中只有一个主构造函数(主构造器)，而辅助构造函数（次级构造器）可以是一个或者多个。主构造函数用于初始化类，它在类标题中声明。标准写法：class 类名 construction(参数1，参数2….)&#123;&#125; 当constructor关键字没有注解和可见性修饰符作用于它时，constructor关键字可以省略 class Person &#123; private val name:String private val age:Int constructor(name:String,age:Int)&#123; // 次级构造函数 this.name = name this.age = age &#125;&#125; 数据类Kotlin 可以创建一个只包含数据的类，关键字为 data：data class User(val name: String, val age: Int) 编译器会自动的从主构造函数中根据所有声明的属性提取以下函数： equals() / hashCode() toString() 格式如 “User(name=John, age=42)” componentN() functions 对应于属性，按声明顺序排列 copy() 函数 为了保证生成代码的一致性以及有意义，数据类需要满足以下条件： 主构造函数至少包含一个参数 所有的主构造函数的参数必须标识为val 或者 var 数据类不可以声明为 abstract, open, sealed 或者 inner 数据类不能继承其他类 (但是可以实现接口) 复制复制使用 copy() 函数，我们可以使用该函数复制对象并修改部分属性, 对于上文的 User 类，其实现会类似下面这样：fun copy(name: String = this.name, age: Int = this.age) = User(name, age) 实例使用 copy 类复制 User 数据类，并修改 age 属性:data class User(val name: String, val age: Int)fun main(args: Array&lt;String&gt;) &#123; val jack = User(name = \"Jack\", age = 1) val olderJack = jack.copy(age = 2) println(jack) println(olderJack)&#125;// 输出结果为：// User(name=Jack, age=1)// User(name=Jack, age=2) 密封类密封类用来表示受限的类继承结构：当一个值为有限几种的类型, 而不能有任何其他类型时。在某种意义上，他们是枚举类的扩展：枚举类型的值集合 也是受限的，但每个枚举常量只存在一个实例，而密封类 的一个子类可以有可包含状态的多个实例。 声明一个密封类，使用 sealed 修饰类，密封类可以有子类，但是所有的子类都必须要内嵌在密封类中。 sealed 不能修饰 interface ,abstract class(会报 warning,但是不会出现编译错误) 密封类就是一种专门用来配合 when 语句使用的类，举个例子，假如在 Android 中我们有一个 view，我们现在想通过 when 语句设置针对 view 进行两种操作：显示和隐藏，那么就可以这样做：sealed class UiOp &#123; object Show: UiOp() object Hide: UiOp()&#125;fun execute(view: View, op: UiOp) = when (op) &#123; UiOp.Show -&gt; view.visibility = View.VISIBLE UiOp.Hide -&gt; view.visibility = View.GONE&#125; 以上功能其实完全可以用枚举实现，但是如果我们现在想加两个操作：水平平移和纵向平移，并且还要携带一些数据，比如平移了多少距离，平移过程的动画类型等数据，用枚举显然就不太好办了，这时密封类的优势就可以发挥了，例如：sealed class UiOp &#123; object Show: UiOp() object Hide: UiOp() class TranslateX(val px: Float): UiOp() class TranslateY(val px: Float): UiOp()&#125;fun execute(view: View, op: UiOp) = when (op) &#123; UiOp.Show -&gt; view.visibility = View.VISIBLE UiOp.Hide -&gt; view.visibility = View.GONE is UiOp.TranslateX -&gt; view.translationX = op.px // 这个 when 语句分支不仅告诉 view 要水平移动，还告诉 view 需要移动多少距离，这是枚举等 Java 传统思想不容易实现的 is UiOp.TranslateY -&gt; view.translationY = op.px // 不再需要 `else` 子句，因为我们已经覆盖了所有的情况&#125; 以上代码中，TranslateX 是一个类，它可以携带多于一个的信息，比如除了告诉 view 需要水平平移之外，还可以告诉 view 平移多少像素，甚至还可以告诉 view 平移的动画类型等信息，我想这大概就是密封类出现的意义吧。 除此之外，如果 when 语句的分支不需要携带除“显示或隐藏view之外的其它信息”时（即只需要表明 when 语句分支，不需要携带额外数据时），用 object 关键字创建单例就可以了，并且此时 when 子句不需要使用 is 关键字。只有需要携带额外信息时才定义密封类的子类，而且使用了密封类就不需要使用 else 子句，每当我们多增加一个密封类的子类或单例，编译器就会在 when 语句中给出提示，可以在编译阶段就及时发现错误，这也是以往 switch-case 语句和枚举不具备的功能。 最后，我们甚至可以把这一组操作封装成一个函数，以便日后调用，如下：// 先封装一个UI操作列表class Ui(val uiOps: List = emptyList()) &#123; operator fun plus(uiOp: UiOp) = Ui(uiOps + uiOp)&#125;// 定义一组操作val ui = Ui() + UiOp.Show + UiOp.TranslateX(20f) + UiOp.TranslateY(40f) + UiOp.Hide// 定义调用的函数fun run(view: View, ui: Ui) &#123; ui.uiOps.forEach &#123; execute(view, it) &#125;&#125;run(view, ui) // 最终调用 Break 和 Continue 标签在 Kotlin 中任何表达式都可以用标签（label）来标记。 标签的格式为标识符后跟 @ 符号，例如：abc@、fooBar@都是有效的标签。 要为一个表达式加标签，我们只要在其前加标签即可。loop@ for (i in 1..100) &#123; for (j in 1..100) &#123; if (……) break@loop &#125;&#125; 标签限制的 break 跳转到刚好位于该标签指定的循环后面的执行点。 continue 继续标签指定的循环的下一次迭代。 标签处返回(待补充)Kotlin 有函数字面量、局部函数和对象表达式。因此 Kotlin 的函数可以被嵌套。 标签限制的 return 允许我们从外层函数返回。 最重要的一个用途就是从 lambda 表达式中返回。回想一下我们这么写的时候：fun foo() &#123; ints.forEach &#123; if (it == 0) return print(it) &#125;&#125; 这个 return 表达式从最直接包围它的函数即 foo 中返回。 （注意，这种非局部的返回只支持传给内联函数的 lambda 表达式。） 如果我们需要从 lambda 表达式中返回，我们必须给它加标签并用以限制 return。 fun foo() &#123; ints.forEach lit@ &#123; if (it == 0) return@lit print(it) &#125;&#125; 现在，它只会从 lambda 表达式中返回。通常情况下使用隐式标签更方便。 该标签与接受该 lambda 的函数同名。 fun foo() &#123; ints.forEach &#123; if (it == 0) return@forEach print(it) &#125;&#125; object 关键字object 是Kotlin中的一个重要的关键字，也是Java中没有的。object 主要有以下三种使用场景： 对象声明（Object Declaration），前面提到了，用于创建类的单例 伴生对象（Companion Object），类似java中 static 关键字 对象表达式（Object Expression），替换java的匿名内部类 分离用于只读与可变集合的接口委托参考 一文彻底搞懂 Kotlin 中的委托 协程（coroutines）参考谷歌官方文档：Android 上的 Kotlin 协程 RefKotlin 语言中文站Kotlin内联函数:使用 Kotlin 进行 Android 开发Kotlin 的 Backing Fields 和 Backing Properties 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&amp;Java/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Kotlin","slug":"kotlin","permalink":"http://agehua.github.io/tags/kotlin/"}]},{"title":"Kotlin DSL 语法糖","slug":"Kotlin-DSL","date":"2020-09-06T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2020/09/07/Kotlin-DSL/","link":"","permalink":"http://agehua.github.io/2020/09/07/Kotlin-DSL/","excerpt":"Kotlin 中使用 DSL最近发现一个使用Kotlin DSL技术来代替XML生成UI布局的工程，类似 Anko，觉得很有意思，特意复制过来，研究一下实现原理，源码在这里 layout_dsl\n所谓DSL领域专用语言(Domain Specified Language)，其基本思想是“求专不求全”：为专门解决某一特定问题的计算机语言，比如大家耳熟能详的 SQL 和正则表达式。\nKotlin DSL 所体现的代码结构有如下特点：链式调用，大括号嵌套，并且可以近似于英语句子。","text":"Kotlin 中使用 DSL最近发现一个使用Kotlin DSL技术来代替XML生成UI布局的工程，类似 Anko，觉得很有意思，特意复制过来，研究一下实现原理，源码在这里 layout_dsl 所谓DSL领域专用语言(Domain Specified Language)，其基本思想是“求专不求全”：为专门解决某一特定问题的计算机语言，比如大家耳熟能详的 SQL 和正则表达式。 Kotlin DSL 所体现的代码结构有如下特点：链式调用，大括号嵌套，并且可以近似于英语句子。 实现原理看了那么多 Kotlin DSL 的风格和使用场景，相较于刻板的、传统的 Java 而言，更加神奇和富有想象力。要理解 Kotlin DSL 这场魔术盛宴，就必须了解其背后用到的魔术道具——扩展函数、lambda、中缀调用和 invoke 约定。 扩展函数（扩展属性）对于同样作为静态语言的 Kotlin 来说，扩展函数（扩展属性）是让他拥有类似于动态语言能力的法宝，即我们可以为任意对象动态的增加函数或属性。 比如，为 String 扩展一个函数： lastChar():package stringsfun String.lastChar(): Char = this.get(this.length - 1) 与 JavaScript 这类动态语言不一样，Kotlin 实现原理是： 提供静态工具类，将接收对象(此例为 String )做为参数传递进来,以下为该扩展函数编译成 Java 的代码 /* Java */char c = StringUtilKt.lastChar(\"Java\"); lambda介绍lambda 为 Java 8 提供的新特性，于2014年3月18日发布。在2018年的今天我们依然无法使用或者要花很大的代价才能在 Android 编程中使用，而 Kotlin 则帮助我们解决了这一瓶颈，这也是我们拥抱 Kotlin 的原因之一。 lambda 是构建整洁代码的一大利器。 lambda 表达式下图是 lambda 表达式，他总是用一对大括号包装起来，可以作为值传递给下节要提到的高阶函数。 lambda 表达式总是括在花括号中， 完整语法形式的参数声明放在花括号内，并有可选的类型标注， 函数体跟在一个 -&gt; 符号之后。如果推断出的该 lambda 的返回类型不是 Unit，那么该 lambda 主体中的最后一个（或可能是单个） 表达式会视为返回值。 高阶函数关于高阶函数的定义，参考《Kotlin 实战》： 高阶函数就是以另一个函数作为参数或返回值的函数 如果用 lamba 来作为高价函数的参数（此时为形参），就必须先了解如何声明一个函数的形参类型，如下： // printSum 为高阶函数，定义了 lambda 形参fun printSum(sum:(Int,Int)-&gt;Int)&#123; // sum作为传入的函数的形参，然后可以通过sum 调用方法 val result = sum(1, 2) println(result)&#125;// 以下 lambda 为实参，传递给高阶函数 printSumval sum = &#123;x:Int,y:Int-&gt;x+y&#125;printSum(sum) 有了高阶函数，我们可以很轻易地做到一个 lambda 嵌套另一个 lambda 的代码结构。 大括号放在最后Kotlin 的 lambda 有个规约：如果 lambda 表达式是函数的最后一个实参，则可以放在括号外面。如果该 lambda 表达式是调用时唯一的参数，那么圆括号可以完全省略：person.maxBy(&#123; p:Person -&gt; p.age &#125;)// 可以写成，放在括号外面person.maxBy()&#123; p:Person -&gt; p.age&#125;// 更简洁的风格，可以省略括号：person.maxBy&#123; p:Person -&gt; p.age&#125; 再举一个例子： // &#123; acc, e -&gt; acc * e &#125; 作为函数最后一个实参，放在了括号外面val product = items.fold(1) &#123; acc, e -&gt; acc * e &#125; // 省略圆括号run &#123; println(\"...\") &#125; 这种语法也称为拖尾 lambda 表达式。 这个规约是 Kotlin DSL 实现嵌套结构的本质原因，比如很多博客提到的 anko Layout： // 省略圆括号verticalLayout &#123; val name = editText() button(\"Say Hello\") &#123; onClick &#123; toast(\"Hello, $&#123;name.text&#125;!\") &#125; &#125;&#125; 这里 verticalLayout 中 嵌套了 button，想必该库定义了如下函数：fun verticalLayout( ()-&gt;Unit )&#123; &#125;fun button( text:String,()-&gt;Unit )&#123; &#125; verticalLayout 和 button 均是高阶函数，结合大括号放在最后的规约，就形成了 lambda 嵌套的语法结构。 注意，允许将函数留在圆括号外的简写语法仅适用于 lambda 表达式。 带接收者的 lambda函数类型可以有一个额外的接收者类型，它在表示法中的点之前指定： 类型 A.(B) -&gt; C 表示可以在 A 的接收者对象上以一个 B 类型参数来调用并返回一个 C 类型值的函数。 带有接收者的函数字面值通常与这些类型一起使用。如下图： Kotlin 提供了使用指定的接收者对象调用函数字面值的功能。 在函数字面值的函数体中，可以调用该接收者对象上的方法而无需任何额外的限定符。 函数字面值，有的也叫函数字面量，（英文：function literal）。函数字面值（量）即一段函数文本，说白了就是一段代码，可以当作参数来传递。 val sum: Int.(Int) -&gt; Int = &#123; other -&gt; plus(other) &#125;// 相当于: val sum: Int.(Int) -&gt; Int = &#123; other -&gt; this.plus(other) &#125; // plus是Int的一个方法 在使用的时候，需要指定接收者。 //类似扩展函数的用法，用实例对象来调用 println( 1.sum(2) )//输出 3 1即这里的接收者，定义的函数字面值里的this就是指向了它 匿名函数语法允许你直接指定函数字面值的接收者类型。 如果你需要使用带接收者的函数类型声明一个变量，并在之后使用它，这将非常有用。 val sum = fun Int.(other: Int): Int = this + other// 下面写法是错误的，不能既用 = ，又用&#123;&#125;val sum = fun Int.(other: Int): Int = &#123;this + other&#125; 此外，带有接收者类型的函数的非字面值可以作为参数进行传递，前提是所需要接收函数的地方应该有一个接收者类型的参数，反之依然，比如说：String.(Int) -&gt; Boolean 与（String, Int）-&gt; Boolean是等价的，下面用代码进行说明： val myEquals: String.(Int) -&gt; Boolean = &#123;param -&gt; this.toIntOrNull() == param&#125;println(\"11\".myEquals(11))println(\"11\".myEquals(12))// 结果 true false 为了说明”String.(Int) -&gt; Boolean与（String, Int）-&gt; Boolean是等价的”，下面用代码来论证下： fun myTest(op:(String, Int) -&gt; Boolean, a: String, b:Int, c:Boolean) = println(op(a, b) == c)// 这里可以传入 myEquals 函数，并且能成功执行，说明两者是等价的myTest(myEquals, \"200\", 200, true) 带接收者的 lambda 丰富了函数声明的信息，当传递该 lambda值时，将携带该接收者，比如： // 声明接收者fun kotlinDSL(block: StringBuilder.()-&gt;Unit)&#123; block(StringBuilder(\"Kotlin\"))&#125;// 调用高阶函数kotlinDSL &#123; // 这个 lambda 的接收者类型为StringBuilder append(\" DSL\") println(this)&#125;&gt;&gt;&gt; 输出 Kotlin DSL 简单介绍一下上面代码的意思：kotlinDSL是一个函数，接收一个名为block的参数，该参数本身就是一个函数。block函数的类型是 StringBuilder.()-&gt;Unit，它是一个带接受者的函数类型。这意味着我们需要向block函数传递一个StringBuilder类型的实例（接收者），并且我们可以在kotlinDSL 函数内部调用该实例的成员。该接收者可以通过this关键字访问 可以再看下面这个例子：class HTML &#123; fun body() &#123; println(\"HTML BODY\") &#125;&#125;fun html(init: HTML.() -&gt; Unit): HTML &#123; val html = HTML() // 创建接收者对象 html.init() // 将该接收者对象传给该 lambda return html&#125;html &#123; // 带接收者的 lambda 由此开始 body() // 调用该接收者对象的一个方法&#125; 总而言之，lambda 在 Kotlin 和 Kotlin DSL 中扮演着很重要的角色，是实现整洁代码的必备语法糖。 中缀调用Kotlin 中有种特殊的函数可以使用中缀调用，代码风格如下：\"key\" to \"value\"// 等价于\"key.to(\"value\") 而 to() 的实现源码如下：infix fun Any.to(that:Any) = Pair(this,that) 这段源码理解起来不难，infix 修饰符代表该函数支持中缀调用，然后为任意对象提供扩展函数 to，接受任意对象作为参数，最终返回键值对。 中缀调用是实现类似英语句子结构 DSL 的核心。 invoke 约定Kotlin 提供了 invoke 约定，可以让对象向函数一样直接调用，比如：class Person(val name:String)&#123; operator fun invoke()&#123; println(\"my name is $name\") &#125;&#125;&gt;&gt;&gt;val person = Person(\"geniusmart\")&gt;&gt;&gt; person()my name is geniusmart 看下网上提到的 Gradle Kotlin DSL：dependencies &#123; compile(\"com.android.support:appcompat-v7:27.0.1\") compile(\"com.android.support.constraint:constraint-layout:1.0.2\")&#125; // 等价于：dependencies.compile(\"com.android.support:appcompat-v7:27.0.1\")dependencies.compile(\"com.android.support.constraint:constraint-layout:1.0.2\") 这里，dependencies 是一个实例，既可以调用成员函数 compile，同时也可以直接传递 lambda 参数，后者便是采用了 invoke 约定，实现原理简化如下：class Dependencies&#123; fun compile(coordinate:String)&#123; println(\"add $coordinate\") &#125; operator fun invoke(block:Dependencies.()-&gt;Unit)&#123; block() &#125;&#125;&gt;&gt;&gt;val dependencies = Dependencies()&gt;&gt;&gt;// 以两种方式分别调用 compile() invoke 约定让对象调用函数的语法结构更加简洁。 总结Kotlin 本身语法就非常整洁，使用DSL则是对 Kotlin 所有语法糖的一个融合，相信以后Kotlin DSL技术应用的地方会越来越多。 参考：《Kotlin 之美—DSL篇》，部分内容有增加带接收者的函数字面值与解构声明详解 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/09/07/Kotlin-DSL/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Kotlin","slug":"kotlin","permalink":"http://agehua.github.io/tags/kotlin/"}]},{"title":"JVM 堆和栈知识点积累","slug":"JVM-stack-and_heap","date":"2020-08-30T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2020/08/31/JVM-stack-and_heap/","link":"","permalink":"http://agehua.github.io/2020/08/31/JVM-stack-and_heap/","excerpt":"最近在看《深入理解Java虚拟机》，在此记录一下书中的重点，方便以后查阅。部分介绍内容来自网络。\n线程独占区","text":"最近在看《深入理解Java虚拟机》，在此记录一下书中的重点，方便以后查阅。部分介绍内容来自网络。 线程独占区 虚拟机栈虚拟机栈属于线程独占区，具体指虚拟机栈中的局部变量表。虚拟机栈描述的是Java方法执行的动态内存模型。每个方法执行都会创建一个栈帧，伴随着方法从创建到执行完成。用于存储局部变量表，操作数栈，动态链接，方法出口等。 局部变量表的内存空间，在编译期完成分配，当进入一个方法时，这个方法需要帧中分配多少内存是固定的，在方法运行期间不会改变局部变量表大小 局部变量表保存的是对象的引用，对象是分配在堆内存中 虚拟机栈已满，但仍有方法需要进栈，则会抛出 StackOverflowError，栈未满；但内存不够了，则会抛出OutOfMemory异常 栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义：int a = 3;int b = 3; 编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。 这时，如果再令 a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响 到b的值。 要注意这种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。 Java中方法参数是值传递，在方法中如果对参数进行修改，将不会影响到实际参数。但可以通过对象引用变量，改变对象的内部状态。更多形参和实参，值传递和引用传递介绍，可以看这篇文章: 深入理解Java中方法的参数传递机制 对于成员变量和局部变量：成员变量就是方法外部，类的内部定义的变量；局部变量就是方法或语句块内部定义的变量。局部变量必须初始化。 方法的形式参数是局部变量，局部变量的数据存在于栈内存中。栈内存中的局部变量随着方法的消失而消失。 成员变量存储在堆中的对象里面，由垃圾回收器负责回收。 本地方法栈本地方法栈为虚拟机执行native方法服务 程序计数器线程共享区Java堆 新生代 Eden Survivor 存活区 Tenured Gen 老年代 存放对象实例垃圾收集器管理的主要区域分新生代，老年代，Eden空间OutOfMemory 方法区方法区系统分配的一个内存逻辑区域，是一块所有线程共享的内存区域，用来存储类信息(类型信息可以理解为类的描述信息（类的全限定名，访问修饰符，字段，方法等）)、常量和静态变量 存储运行时常量池，已被虚拟机加载类信息，常量，静态变量，即时编译器编译后的代码等数据 类信息： 类的版本 字段 方法 接口 方法区和永久代：有的虚拟机（HotSpot），使用永久代实现的方法区，但两者并不等价 垃圾回收在方法区中的行为：常量池的回收，类型的卸载 异常：OutOfMemory 运行时常量池常量池即文件常量池，主要用来保存字面量和符号引用 1）JVM为每个已加载的类型维护一个常量池，常量池就是这个类型用到的常量的一个有序集合。包括直接常量(基本类型，String)和对其他类型、方法、字段的符号引用。池中的数据和数组一样通过索引访问。 2）java中的常量池技术，是为了方便快捷地创建某些对象而出现的，当需要一个对象时，就可以从池中取一个出来（如果池中没有则创建一个），则在需要重复创建相等变量时节省了很多时间。常量池其实也就是一块内存空间，不同于使用new关键字创建的对象所在的堆空间。 java中的基本类型有：byte、short、char、int、long、boolean。其对应的包装类分别是：Byte、Short、Character、Integer、Long、Boolean。上边提到的这些包装类都实现了常量池技术，而两种浮点数类型的包装类则没有实现。另外，String类型也实现了常量池技术。 字符串对象的创建，s1 = new String(“a”)内容存放在堆内存，而s1 = “a”则存放在方法区的常量池中 String s1 = \"abc\";String s2 = \"abc\"; // s1 == s2 true，地址相同， 字节码常量String s3 = new String(\"abc\"); // s3在堆内存，s1 == s3 false 地址不同System.out.println(s1 == s3.intern()); // true，s3.intern()则会将内容搬到方法区的常量池中去，地址相同// s3.intern()叫运行时常量 直接内存堆内存之外分配的内存，NIO可以直接分配堆外内存 对象的创建指针碰撞空闲列表 线程安全问题 线程同步 本地线程分配缓冲 对象的结构Header 对象头 自身运行时数据 (Mark Word)： 哈希值 GC分代年龄 锁状态标志 线程持有的锁 偏向线程ID 偏向时间戳 64bit 类型指针 对象指向它类的元数据的指针 InstanceDataPadding填充内存，保证8bit的整数倍 对象的访问定位 使用句柄 指向堆中，句柄池，通过句柄池找到对象内存地址 直接指针 指向内存区域 GCRoot对象 执行上下文 虚拟机栈(栈帧中的本地变量表) 全局性的引用 方法区类属性所引用的对象 方法区中常量所引用的对象 本地方法栈中引用的对象 内存分配策略-verbose:gc 控制台打印gc日志-XX:+PrintGCDetails-XX:+UseSerialGC 启动serialgc回收器，默认使用parallel回收器-Xms20M -Xmx20M 堆内存大小20M，不可扩展-Xmn10M 指定新生代内存为10M-XX:SurvivorRatio =8 Eden 区域为80% ??? 对象优先在Eden上分配 大对象直接进入老年代-XX:PretenureSizeThreshold : 指定老年代阈值，超过这个阈值大小的对象会直接放入老年代 长期存活对象将进入到老年代-XX:MaxTenuringThreshold: 指定老年代任期阈值 空间分配担保（Eden区域不够用，已分配对象会被移到老年代）-XX:+HandlerPromotionFailure: 是否禁用空间分配担保（+开启，默认，-禁用） 动态对象年龄判断 JVM 参数样式： -XX:+&lt;option&gt;, 表示开启option选项 -XX:-&lt;option&gt;, 表示关闭option选项 -XX:&lt;option&gt;=&lt;value&gt;, 表示将option选项的值设置为value 逃逸分析与栈上分配逃逸分析：分析对象的作用域，栈上分配：方法体内没有逃逸的对象，会分配在栈上 Jconsole死锁检测 Davilk 字节码指令，基于寄存器架构Java 虚拟机的指令集，基于栈架构 类的初始化1.遇到new，getstatic, putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化常见的场景有：new关键字实例化对象，读取或设置一个类的静态字段（没有被final修饰），调用一个类的静态方法时。 被final修饰的叫静态字段，会被放入常量池（方法区）中。所以引用类中的常量字段，是不会触发类的初始化的 2.当初始化一个类的时候，如果发现其父类还没有进行初始化，则需要先触发其父类的初始化3.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有初始化，则需要先触发其初始化 不会初始化类的场景通过子类引用父类的静态字段，子类不会被初始化通过数组定义来引用类，类不会被初始化，实例化的是数组类型A[] a = new A[10];// A对象不会初始化 调用类的常量（final），类不会初始化 助记符： anewarray: 表示创建一个引用类型（如类，接口，数组）的数组，并将其压入栈顶 newarray: 表示创建一个指定的原始类型（如int、float、char等）的数组，并将其压入栈顶 加载通过一个类的全限定类名来获取定义此类的二进制流 可以从文件加载 Class文件 Jar 包 网络 applet 计算生成一个二进制流 $Proxy(反射包中) 由其他文件生成 JSP 数据库 验证验证是连接的第一步，这一阶段目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全 准备准备阶段正式为类变量分配内存，并设置变量的初始值，这些变量使用的内存都将在方法区中进行分配。这里的初始值并非我们指定的值，而是默认值。但是如果被final修饰，初始化值为常量值 解析解析阶段是虚拟机将常量池中的符号引用替换为直接引用的过程 关于符号引用和直接引用，可以看这篇文章: https://www.zhihu.com/question/30300585 对符号引用进行解析： 类或接口解析字段解析类方法解析 上面三个都会对扶摇引用进行权限验证，不具备访问权限，抛出java.lang.illegalAccessError异常接口方法解析 接口所有方法都是public，所以不存在权限验证 初始化初始化时类加载的最后一步初始化是执行&lt;clinit&gt;()方法的过程 public class Demo &#123; static &#123; i = 0; System.out.println(i); // i可以赋值，但不能访问 &#125; static int i = 1;&#125; &lt;clinit&gt;()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问定义在静态语句块之前的变量，定义在它之后的变量，在前面的语句块中可以赋值，但是不能访问。 public class Parent &#123; public static int A =1; static &#123; A = 2; &#125; static class Sub extends Parent &#123; public static int B = A; &#125; public static void main(String[] args) &#123; System.out.println(Sub.B); &#125;&#125; 子类的&lt;clinit&gt;()在执行之前，虚拟机保证父类的先执行完毕，因此在赋值前父类static已经执行，因此结果为2. 接口中也有变量要赋值，也会生成&lt;clinit&gt;()，但不需要先执行父类的&lt;clinit&gt;()方法。只有父接口中定义的变量使用时才会初始化。 如果多个线程同时初始化一个类，只有一个线程会执行这个类的&lt;clinit&gt;()，其他线程等待执行完毕。如果方法执行时间过长，则会造成多个线程阻塞。 类的初始化步骤： 假如这个类还没有被加载和连接，那就先进行加载和连接 假如类存在直接父类，并且这个父类还没有被初始化，那就先初始化直接父类 假如类中存在初始化语句，那就依次执行这些初始化语句 类的初始化时机： 主动使用 创建类的实例 访问某个类或接口的静态变量，或者对该静态变量赋值 调用类的静态方法 反射（如Class.forName(“com.test.XXXX”)） 初始化一个类的子类 Java虚拟机启动时被标明为启动类的类（Java Test） JDK1.7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic, REF_putStatic, REF_invokeStatic句柄对应的类没有初始化则初始化 除了上述7中情形，其他使用Java类的方式都被看作是被动使用，不会导致类的初始化 当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则不适用于接口 - 在初始化一个类时，并不会先初始化它所实现的接口 - 在初始化一个接口时，并不会初始化它的父接口 只有当程序访问的静态变量或静态方法确实在当前类或当前接口中定义时，才可以认为是对类或接口的主动使用 来看一个父类子类和成员变量初始化顺序的问题：public class Base &#123; private String baseName = \"base\"; public Base() &#123; callName(); &#125; public void callName() &#123; System.out.println(baseName); &#125; static class Sub extends Base &#123; private String baseName = \"sub\"; public void callName() &#123; // 子类重写了父类的方法 System.out.println(baseName) ; &#125; &#125; public static void main(String[] args) &#123; Base b = new Sub(); &#125; /** * 链接：https://www.nowcoder.com/questionTerminal/c2bfb1512dfa4a7eab773a5871a52402 * 来源：牛客网 * * 初始化的过程：1、初始化父类中的静态成员变量和静态代码块。2、初始化子类中的静态成员变量和静态代码块。3、初始化父类的普通成员变量和代码块，再执行父类的构造方法。4、初始化子类的普通成员变量和代码块，再执行子类的构造方法。 * 题目中new Sub()会先初始化父类中的baseName变量，再调用父类的构造函数，调用子类重写的callName()方法，打印出子类中的baseName，接下来才初始化子类中变量，调用子类构造函数，所以打印null。 * 可以单步调试看下代码的执行过程。 */&#125; 答案是只有 ”null“ 类的实例化为新的对象分配内存，为实例变量赋初始值，为实例变量赋默认值。java编译器为它编译的每一个类都至少生成一个实例初始化方法，在java的class文件中，这个实例初始化方法被称为&lt;init&gt;。针对源代码中每一个类的构造方法，java编译器都产生一个&lt;init&gt;方法。类变量是在准备阶段就已经分配内存 类加载器 Java虚拟机自带的加载器 根类加载器（Bootstrap） 扩展类加载器（Extension） 系统（应用）类加载器（System） 用户自己定义的加载器 java.lang.ClassLoader的子类 用户可以定制类的加载方式 类加载器并不需要等到某个类被”首次主动使用“时再加载它。 如果在预先加载的过程中遇到.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类是才报告错误(LinkageError错误)，如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。 双亲委派模型 启动类加载器 由C++实现，是虚拟机的一部分，用于加载javahome下的lib目录下的类(rt.jar， java.lang.Object) 扩展类加载器 加载javahome下的 /lib/ext/目录中的类 应用程序类加载器 加载用户类路径上所指定的类库 自定义类加载器 class MyParent &#123; public static String str = \"Hello world\": static &#123; System.out.println(\"Parent static block\"); &#125;&#125;class MyChild extends MyParent &#123; public static String str2 = \"Welcome\": static &#123; System.out.println(\"Child static block\"); &#125;&#125;class Test &#123; public static void main(String[] args) &#123; System.out.println(MyChild.str2); // 打印 Parent static block Child static block Hello world // System.out.println(MyChild.str); // 打印 Parent static block Hello world &#125;&#125; 对于打印str2，主动使用了MyChild类，MyChild会初始化，子类如果被初始化，所有父类必须先行初始化，所以 MyParent会初始化对于打印str，对于静态字段，只有直接定义了该字段的类才会被初始化，所以不会初始化MyChild类 -XX:+TraceClassLoading，用于追踪类的加载信息并打印出来。对于打印str，虽然没有打印 “Child static block”，说明没有初始化MyChild，但是也完成了MyChild类的加载 class MyParent &#123; public static final String str = \"Hello world\": static &#123; System.out.println(\"Parent static block\"); &#125;&#125;class Test2 &#123; public static void main(String[] args) &#123; System.out.println(MyParent.str); // 只打印 ”Hello world“ &#125;&#125; 加上final，表示常量在编译阶段，常量会被存入调用这个常量的方法(main方法)所在的类(Test2)的常量池中。甚至，可以把编译后的MyParent类删除，程序可以正常执行。 本质上，调用类并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化 反编译Test2.class后查看类源码，发现一个助记符：ldc ldc表示将int，float或是String类型的常量值从常量池中推送至栈顶 助记符 bipush，表示是将单字节（-128 - 127）的常量值推送至栈顶 助记符 sipush，表示是将短整形（-32768 - 32767）的常量值推送至栈顶 助记符 iconst_1，表示将int类型1推送至栈顶（iconst_m1 - iconst_5）(-1 - 5) 再看下一例子class MyParent &#123; public static final String str = UUID.randomUUID().toString(): static &#123; System.out.println(\"Parent static block\"); &#125;&#125;public class Test3 &#123; public static void main(String[] args) &#123; System.out.println(MyParent.str); // 会打印静态代码块 &#125;&#125; 当一个常量的值并非编译期间可以确定，那么其值就不会放到调用类的常量池中。这里str在编译期间不能确定，所以需要加载定义常量的类。 当一个接口初始化时，并不要求父接口都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量时），才会初始化 类的加载的最终产品是位于内存中的Class对象，Class对象封装了类在方法区内的数据结构，并向Java程序员提供了访问方法区内的数据结构的接口 虚拟机字节码执行引擎运行时栈帧结构 局部变量表，编译期已经确定了大小。最小存储单元叫 slot。slot复用，全局变量，在加载中会被赋初始值，初始化阶段会被赋上用户定义的值。方法内的局部变量，没有机会赋值，因此使用局部变量必须赋值。 操作数栈，虚拟机指令执行方式 动态连接，符号引用 方法返回地址，附加信息 方法调用javap -verbose xxx.class 查看class文件的汇编指令 静态分派 编译期确定静态类型，针对方法的重载public void sayHello(Parent p) &#123; System.out.println(\"parent called\");&#125;public void sayHello(Child1 c) &#123; System.out.println(\"child1 called\");&#125;Parent c = new Child1(); // Parent是静态类型d.sayHello((Child2)c);// 静态类型改变 方法调用，多个匹配，会选择一个最比配的方法翻译为invokevirtual 动态分派，针对方法的重写，根据实际类型方法翻译为invokevirtual，是在invokevirtual里做了处理 动态类型语言支持静态类型语言在非运行阶段，变量的类型时可以确定的，也是变量是有类型的动态类型在非运行阶段，变量类型时无法确定的，也就是变量是没有类型的，但值是有类型的，也就是运行期间可以确定变量的值的类型 ####Java的内存模型禁止把final字段的写，重排序到构造方法以外。final 字段不能再静态代码块中赋值。必须在类初始化之后赋值，且只能初始化一次。 初始化顺序：静态代码块，main方法，构造器，代码块 面试题 i = i++和 i = ++i public static void main(String[] args) &#123; int i = 1; i = i++; int j = i++; int k = i + ++i * i++; System.out.println(\"i=\"+i); System.out.println(\"j=\"+j); System.out.println(\"k=\"+k);&#125; i = i++, i 变量先进入操作数栈，然后在局部变量表中进行自增，然后在把栈中的数据返回给我们的变量 i 反过来，i = ++i， i 变量先在局部变量表中进行自增，然后再将 i 进栈，然后再把栈中的数据返回给我们的变量 i 所以这题的答案是：i=4j=1k=11 2.类变量准备阶段和初始化阶段差别public class Test &#123; public static void main(String[] args) &#123; Singleton singleton = Singleton.getInstance(); System.out.println(\"counter1: \"+ Singleton.counter1); System.out.println(\"counter2: \"+ Singleton.counter2); // 输出接口 1 0 &#125;&#125;class Singleton &#123; public static int counter1; private static Singleton singleton = new Singleton(); private Singleton() &#123; counter1++; counter2++; // 这里时 counter1 和counter2 都是1 &#125; public static int counter2 = 0; // 这里对counter2重新赋值 public static Singleton getInstance() &#123; return singleton; &#125;&#125; Singleton类加载过程中，有两步都对counter2的值进行了修改： 在准备阶段，counter1 赋初值 0， singleton赋初值null， 构造方法没有执行，counter2 赋初值 0。 外部调用类的静态方法，类被调用，类从上到下进行初始化，singleton初始值为new Singleton()，构造方法被执行，counter2 值为2，然后对counter2初始化，值为0，所以最后打印出来counter2值为0。 把 public static int counter1; 改为 public static int counter1 = 1;，打印结果是2，0。 准备阶段赋初值，初始化阶段为类变量赋予正确默认值，且初始化赋值按照从上到下执行。具体解释可以看这篇文章：https://juejin.cn/post/6991736846204010533 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/08/31/JVM-stack-and_heap/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"JVM","slug":"jvm","permalink":"http://agehua.github.io/tags/jvm/"}]},{"title":"Android Studio CPU Profiler使用","slug":"profile_analysis","date":"2020-07-09T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2020/07/10/profile_analysis/","link":"","permalink":"http://agehua.github.io/2020/07/10/profile_analysis/","excerpt":"Android Studio CPU Profiler使用CPU Profiler谷歌的官方文档使用 CPU Profiler 检查 CPU 活动中，对CPU Profiler的功能描述是：","text":"Android Studio CPU Profiler使用CPU Profiler谷歌的官方文档使用 CPU Profiler 检查 CPU 活动中，对CPU Profiler的功能描述是： 系统跟踪数据：捕获精细的详细信息，以便您检查应用与系统资源的交互情况。 方法和函数跟踪数据：对于应用进程中的每个线程，您可以了解一段时间内执行了哪些方法 (Java) 或函数 (C/C++)，以及每个方法或函数在其执行期间消耗的 CPU 资源。您还可以使用方法和函数跟踪数据来识别调用方和被调用方。调用方是指调用其他方法或函数的方法或函数，而被调用方是指被其他方法或函数调用的方法或函数。您可以使用此信息来确定哪些方法或函数负责调用常常会消耗大量资源的特定任务，并优化应用的代码以避免不必要的工作。 本文是我想对App的启动过程进行优化，先总结对Profiler工具的使用。 如何获取 trace 数据CPU Profiler可以对trace文件进行分析，获取trace文件的方式，大概有3种： 1.启用调试设备，在Profiler面板左上角点击加号➕，第二项是已连接的可调试设备，点击设备，选择要调试应用的进程。 2.还是上面加号➕，点击选择第一项 load from file…，表示用本地的文件，关于文件的生成有两种方式： 1.在搭载 Android 9（API 级别 28）或更高版本的设备上，您可以使用一个名为“系统跟踪”的系统应用来记录设备上的系统跟踪数据，详细介绍在这里 2.在Android 8.0（API 级别 26）或更高版本的设备上，使用 Debug API，掉用startMethodTracing(String tracePath) 开始记录数据；调用 stopMethodTracing()停止记录数据。结束后会在tracePath（默认会在sd卡根目录创建&lt;trace-name&gt;.trace文件）。 注意Debug API 不要和其他两种方式同时使用 如何生成app启动过程中的 trace数据 1.依次选择 Run &gt; Edit Configurations。 2.在 Profiling 标签中，勾选 Start recording a method trace on startup 旁边的复选框。 3.从菜单中选择 CPU 记录配置。 4.点击 Apply。 5.依次选择 Run &gt; Profile，将您的应用部署到搭载 Android 8.0（API 级别 26）或更高版本的设备上。 如何使用CPU Profiler 进行分析成功导入或直接调试出数据后，Profiler面板会如下图所示(这里只截了一部分)： 图中最上面是整个trace文件记录的时间段，默认是选中了全部。下面是我们的应用里使用到CPU的各个线程，其中记录显示的颜色有三种： 1.橙色，是指对系统 API 的调用 2.绿色，对应用自有方法的调用 3.蓝色，为对第三方 API（包括 Java 语言 API）的调用 点击mian，对应应用的主线程，Profiler面板的右侧会展示这个线程的数据，分三个维度： Top Down 标签显示一个调用列表，在该列表中展开方法或函数节点会显示它的被调用方 Flame Chart 标签页提供一个倒置的调用图表，用来汇总完全相同的调用堆栈。也就是说，将具有相同调用方顺序的完全相同的方法或函数收集起来，并在火焰图中将它们表示为一个较长的横条。这样更方便您查看哪些方法或函数消耗的时间最多。不过，这也意味着，横轴不代表时间轴，而是表示执行每个方法或函数所需的相对时间。 Bottom Up 标签页显示一个调用列表，在该列表中展开函数或方法的节点会显示它的调用方。Bottom Up 标签页用于按照占用的 CPU 时间由多到少（或由少到多）的顺序对方法或函数排序 App启动流程分析在Top Down标签页下，有一个搜索框，可以输入想要重点关注的方法调用。对于App启动流程，我建议有几处可以关注： attach() (android.app.Application)，这里会回调application的attachBaseContext()方法。 callApplicationOnCreate() (android.app.Instrumentation)，这里会回调application的onCreate()方法，可以检查以上两处有无耗时操作，比如各种sdk的初始化。 搜索框输入第一个启动的activity，类似 WelcomeActivity 这种，查找关于这个activity的onCreate()和onResume()中的耗时方法。 暂时只想到这几点，如有遗漏，欢迎补充~ 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/07/10/profile_analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Profiler","slug":"profiler","permalink":"http://agehua.github.io/tags/profiler/"}]},{"title":"分析下载功能源码和实现","slug":"download-function-analysis","date":"2020-05-25T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2020/05/26/download-function-analysis/","link":"","permalink":"http://agehua.github.io/2020/05/26/download-function-analysis/","excerpt":"安卓下载功能分析最近看了一份实现下载功能的代码，为了方便学习和记忆，将下载功能拆分，根据功能模块分析源码逻辑，做了一份整理：\n目标\n\n1.支持多种下载api，如okhttp、HttpURLConnection\n2.多线程、断点续传下载，线程池支持\n3.下载管理：开始、暂停、继续、取消、重新开始","text":"安卓下载功能分析最近看了一份实现下载功能的代码，为了方便学习和记忆，将下载功能拆分，根据功能模块分析源码逻辑，做了一份整理： 目标 1.支持多种下载api，如okhttp、HttpURLConnection 2.多线程、断点续传下载，线程池支持 3.下载管理：开始、暂停、继续、取消、重新开始 最基础功能下载需要创建一个代理类，FileDownloadProxy 来判断需要使用哪种方式下载以使用HttpURLConnection方式为例下载文件，创建一个 UrlConnectionFileDownload 类HttpURLConnection connection = null;File downloadingFile = new File(bean.getDownloadingPath());long downloadSize = downloadingFile.length();try &#123; connection = (HttpURLConnection) url.openConnection(); connection.setRequestMethod(\"GET\"); connection.addRequestProperty(\"Connection\", \"Keep-Alive\"); connection.setConnectTimeout(30000); connection.setReadTimeout(30000); connection.setInstanceFollowRedirects(false); int responseCode = connection.getResponseCode(); // 这里先忽略其他请求状态码，比如重定向302等 switch (responseCode) &#123; case HttpURLConnection.HTTP_OK: inputStream = urlConn.getInputStream(); //... &#125;&#125; catch (Exception e) &#123; return FileDownloadConstant.DOWNLOAD_ERROR;&#125; 然后根据输入流去下载文件，后面在分析如何断点下载 下载线程管理下载放在一个单独的线程里，最好线程池管理线程.线程池采用ThreadPoolExecutor，第六个参数可以指定一个ThreadFactory，创建指定的Runnable对象 public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue&lt;Runnable&gt; workQueue, ThreadFactory threadFactory) &#123; this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, defaultHandler);&#125; 实现一个Runnable类，XInfiniteRetryRunnable支持重试，并且能够通知前台线程执行状态 伪代码实现如下：int retryCount;boolean isRunning;int times = 5;@Overridepublic final void run() &#123; // 准备活动 if (!onPreExecute(bean)) &#123; if (!isRunning) &#123; onCancelled(bean); &#125; else &#123; onPreExecuteError(bean); &#125; return; &#125; while (isRunning) &#123; if (onExecute() || !isRunning) &#123; // 执行成功，或外部中断，退出循环 break; &#125; // 添加重试 while (isRunning &amp;&amp; retryCount &lt; times) &#123; Thread.sleep(100 * retryCount); retryCount++; &#125; &#125; // 执行结束 if (isRunning) &#123; // 正常结束情况下，调用onPostExecute onExecuteFinish(bean); &#125; else &#123; // 被中断情况下，调用onCancelled onCancelled(bean); &#125;&#125;// 通知外界，用于执行耗时任务boolean onExecute(T bean);// 通知外界，正常执行成功boolean onExecuteFinish(T bean);// 在这里执行下载前数据的初始化操作boolean onPreExecute(T bean)void onCancelled(T bean);void onPreExecuteError(T bean); 最后调用ExecutorService.submit() 提交下载线程 下载状态管理前端需要知道下载中的状态，并作出相应的处理定义一个下载类对象，总结一下，大概有五个状态TODO,DOING,DONE,ERROR,DEFAULT（未初始化状态）public interface TaskBean extends Cloneable &#123; public static final int STATUS_DEFAULT = -1;// 默认状态(未进执行队列) public static final int STATUS_TODO = 0;// 未执行状态 public static final int STATUS_DOING = 1;// 正在执行状态 public static final int STATUS_DONE = 2;// 已完成状态 public static final int STATUS_ERROR = 3;// 错误状态 // 定义一些属性方法 String getId(); int getStatus(); void setStatus(int status); public long getCompleteSize(); public void setCompleteSize(long completeSize);&#125; 使用状态机处理状态转换状态机有五个行为start,pause,abort,endSuccess,endError子类继承时，重写五个行为的回调方法即可：onStart(),onPause(),onAbort(),onEndSuccess(),onEndError() start = {@link TaskBean#STATUS_TODO} / {@link TaskBean#STATUS_ERROR} to {@link TaskBean#STATUS_DOING} pause = {@link TaskBean#STATUS_DOING} to {@link TaskBean#STATUS_TODO} or {@link TaskBean#STATUS_DEFAULT} abort = all status to {@link TaskBean#STATUS_DONE} endSuccess ={@link TaskBean#STATUS_DOING} to {@link TaskBean#STATUS_DONE} endError = {@link TaskBean#STATUS_DOING} to {@link TaskBean#STATUS_ERROR} 先定义一个接口，大概方法如下：public interface ITaskExecutor&lt;B extends TaskBean&gt; &#123; // 这里的参数采用数据，而不是int值的方式，可以避免必须传入一个int值，preStatus可以为空 int start(int... preStatus); int pause(int... postStatus); boolean abort(); B getBean(); String getId(); void setStatus(int status); int getStatus(); void setListener(ITaskListener&lt;B&gt; listener); ITaskListener&lt;B&gt; getListener(); // 通过一个listener将状态机状态通知出去&#125; 定义一个抽象类实现状态的检查和切换，下面代码以start状态为例：public abstract class StateMachineExecutor&lt;B extends TaskBean&gt; implements ITaskExecutor&lt;B&gt; &#123; private volatile int mStatus; // 状态 private B mBean; // 任务数据 @Override public int start(int... preStatus) &#123; // 检查任务状态 int oldStatus = getStatus(); if (oldStatus == TaskBean.STATUS_STARTING || oldStatus == TaskBean.STATUS_DOING) &#123; return StateMachineStatus.TASK_START_DOING_OR_STARTING; &#125; if (getStatus() != TaskBean.STATUS_TODO &amp;&amp; getStatus() != TaskBean.STATUS_ERROR) &#123; //在三种情况下可以启动下载任务：STATUS_TODO,STATUS_ERROR,preStatus[0]指定状态才能启动 return StateMachineStatus.TASK_INVALIDATED_STATUS; &#125; //将当前任务标记为正在启动状态 setStatus(TaskBean.STATUS_STARTING); if (!onStart()) &#123; // 子类要实现onStart()方法 // 任务启动失败 setStatus(oldStatus); return StateMachineStatus.TASK_START_FAIL; &#125; // 任务启动完成，设置状态为进行中 setStatus(TaskBean.STATUS_DOING); if (mListener != null) &#123; mListener.onStart(getBean()); &#125; return StateMachineStatus.TASK_START_SUCCESS; &#125; @Override public int pause(int... postStatus) &#123; &#125; @Override public boolean abort() &#123; &#125; @Override public void setStatus(int status) &#123; mStatus = status; mBean.setStatus(status); &#125; @Override public int getStatus() &#123; return mStatus; &#125; // 子类通过实现抽象方法，获取执行中的状态回调 protected abstract boolean onStart(); protected abstract boolean onPause(); protected abstract boolean onAbort(); protected abstract boolean onEndSuccess(); protected abstract boolean onEndError(String errorCode, boolean retry);&#125; 在这个抽象类里，定义了listener，子类可以自己判断是否需要监听状态事件，定义抽象方法，子类必须在特定状态实现特定方法。setStatus()和getStatus()是操作任务对象（B）的状态，而start()方法的返回值是状态机的状态，这样的好处是状态机调度任务执行状态（这是使用状态的目的）和状态机本身的状态相互分离。 状态机与下载任务结合public class DownloadFileTask extends StateMachineExecutor&lt;FileDownloadObject&gt; &#123; /** * 负责启动和轮询的异步线程 */ private volatile FileDownloadRunnable mRunnable; @Override protected boolean onStart() &#123; // 在开始状态中创建runnable，并提交给线程池 mRunnable = new FileDownloadRunnable(mContext, this); FileDownloadExecutors.UNIVERSAL_DOWNLOAD_POOL.submit(mRunnable); &#125; @Override protected boolean onPause() &#123; exitRunnable(); return true; &#125; @Override protected boolean onAbort() &#123; exitRunnable(); return true; &#125; @Override protected boolean onEndSuccess() &#123; mRunnable = null; return true; &#125; @Override protected boolean onEndError(String errorCode, boolean retry) &#123; mRunnable = null; return true; &#125; private void exitRunnable() &#123; if (mRunnable != null) &#123; mRunnable.cancel(); mRunnable = null; &#125; &#125; public void notifyDoing(long completeSize) &#123; if (mListener != null) &#123; if (this.getStatus() != this.getBean().getStatus()) &#123; //保持下载任务和下载对象的状态统一 this.getBean().setStatus(this.getStatus()); &#125; mListener.onDoing(getBean(), completeSize); &#125; &#125;&#125; 这里的FileDownloadRunnable就是继承了XInfiniteRetryRunnable类，实现了onExecute()、onExecuteFinish()、onPreExecute()方法FileDownloadObject是实现了TaskBean接口，拓展一些TaskBean没有的属性class FileDownloadRunnable extends XInfiniteRetryRunnable&lt;FileDownloadObject&gt; &#123; private XBaseTaskExecutor&lt;FileDownloadObject&gt; mHost; protected FileDownloadRunnable(Context context, XBaseTaskExecutor&lt;FileDownloadObject&gt; host) &#123; mHost = host; &#125; @Override public boolean onPreExecute(FileDownloadObject bean) &#123; //检查url，filePath是否正确 if (TextUtils.isEmpty(bean.getId())) &#123; getBean().errorCode = FileDownloadConstant.FILE_DOWNLOAD_URL_NULL; // 校验失败返回false，线程不在继续执行 return false; &#125; if (TextUtils.isEmpty(bean.getDownloadPath())) &#123; getBean().errorCode = FileDownloadConstant.FILE_DOWNLOAD_PATH_NULL; return false; &#125; &#125; @Override public boolean onExecute(FileDownloadObject bean) &#123; int result = -1; //标记下载开始时间 bean.setDownloadStartTime(System.currentTimeMillis()); // 封装了HttpUrlConnection，下载文件，并监听下载进度 result = httpAdapter.downloadFile(bean, bean.getCallbackInterval(), new DownloadProgressCallback&lt;FileDownloadObject&gt;() &#123; @Override public void onDataChanged(FileDownloadObject bean) &#123; // 下载进度保存在了bean中 if (bean.verifyContentLength() &amp;&amp; bean.getFileSzie() == -1) &#123; bean.setFileSize(bean.getContentLength()); &#125; // 通过DownloadFileTask的listener将进度通知出去 mHost.notifyDoing(-1); &#125; &#125;); &#125; @Override public void onExecuteFinish(FileDownloadObject bean) &#123; if (isDownloadSuccess) &#123; mHost.endSuccess(); &#125; else &#123; deleteFileIfError(bean); mHost.endError(getBean().errorCode, true); &#125; &#125; //... &#125; 到这里就将下载线程和状态机联系了起来，外面只需要接触DownloadFileTask这一个类，就可以监听执行下载的状态 HttpUrlConnection断点下载再说下HttpUrlConnection实现断点下载，补充文章开头的部分int responseCode = connection.getResponseCode();switch (responseCode) &#123; case HttpURLConnection.HTTP_OK: case HttpURLConnection.HTTP_PARTIAL: // 关键在处理206状态码 bean.setFileSize(connection.getContentLength()); return downloadFileByUrlConnection(connection, bean, callbackInterval, callback); //...&#125; 下载涉及到BufferedInputStream的使用，具体可以看下这篇博文：JavaIO之BufferedInputStream详解private static final int DOWNLOAD_BUFFER_SIZE = 16 * 1024;private int downloadFileByUrlConnection(HttpURLConnection connection, B bean, long callbackInterval, DownloadProgressCallback&lt;B&gt; callback) &#123; FileOutputStream fos = null; BufferedInputStream bis = null; InputStream inputStream = null; File downloadingFile = null; long contentLength = -1; long completeSize = 0; byte[] mBuffer; bean.setErrorCode(\"\"); try &#123; if (connection.getURL() != null) &#123; bean.setDownloadUrl(connection.getURL().toString()); &#125; inputStream = connection.getInputStream(); if (inputStream == null) &#123; bean.setErrorCode(FileDownloadConstant.FILE_DOWNLOAD_INPUTSTREAM_IS_NULL); return FileDownloadConstant.DOWNLOAD_INTERVAL_RETRY; &#125; mBuffer = new byte[DOWNLOAD_BUFFER_SIZE]; //从contentLength获取，若返回时200，则contentLength等于整个文件大小 //若返回206，则contentLength表示这个文件剩余下载的大小，需要更新整个文件大小 contentLength = bean.getFileSzie(); completeSize = bean.getCompleteSize(); downloadingFile = new File(bean.getDownloadingPath()); //contentLength对于下载没有帮助，仅用于计算下载进度 if (contentLength &lt;= 0) &#123; deliverException(bean); &#125; else &#123; //修正completeSize大小 if (completeSize &lt; 0) &#123; completeSize = 0; &#125; //更新总大小 long realSize = completeSize + contentLength; if (realSize &gt; 0 &amp;&amp; realSize != bean.getFileSzie()) &#123; bean.setFileSize(realSize); &#125; &#125; bis = new BufferedInputStream(inputStream); fos = new FileOutputStream(downloadingFile, true); // 之前read读取的数据量 int bufferStart = 0; // 一次read读取的数据量 int numRead = 0; // 用于控制刷新进度的变量 long curUpdateTime = 0; long lastUpdateTime = System.currentTimeMillis(); long lastCompleteSize = completeSize; while (true) &#123; // 如果被中断，则整体退出 if (!isRunning()) &#123; bean.setErrorCode(FileDownloadConstant.FILE_DOWNLOAD_ABORT); return FileDownloadConstant.DOWNLOAD_ERROR; &#125; curUpdateTime = System.currentTimeMillis(); numRead = bis.read(mBuffer, bufferStart, DOWNLOAD_BUFFER_SIZE - bufferStart); // 已经没有数据了，退出循环 if (numRead == -1) &#123; if (bufferStart &gt; 0) &#123; // buffer未填充满，但已经没数据了，则写入文件 fos.write(mBuffer, 0, bufferStart); &#125; break; &#125; // 递增已下载大小 completeSize = completeSize + numRead; // 第一次刷新UI，同时为了防止频繁刷新界面，第二次刷新UI间隔大于1秒 if (curUpdateTime - lastUpdateTime &gt;= callbackInterval || isFirstCallback) &#123; //计算速度 long increaseCompleteSize = completeSize - lastCompleteSize; long gapTime = curUpdateTime - lastUpdateTime; long speed = 0; if (gapTime != 0) &#123; speed = increaseCompleteSize / gapTime * 1000; &#125; bean.setSpeed(speed); bean.setCompleteSize(completeSize); lastUpdateTime = curUpdateTime; lastCompleteSize = completeSize; if (callback != null) &#123; callback.onDataChanged(bean); &#125; &#125; if (numRead + bufferStart &lt; DOWNLOAD_BUFFER_SIZE) &#123; // buffer未填满 bufferStart = numRead + bufferStart; &#125; else &#123; // buffer已填满，则写入文件 fos.write(mBuffer, 0, DOWNLOAD_BUFFER_SIZE); // buffer重新开始填充 bufferStart = 0; &#125; &#125; //下载完成 if (callback != null) &#123; bean.setCompleteSize(completeSize); callback.onDataChanged(bean); &#125; return FileDownloadConstant.DOWNLOAD_SUCCESS; &#125; catch (SocketTimeoutException e) &#123; return FileDownloadConstant.DOWNLOAD_SOCKET_RETRY; &#125; catch (SocketException e) &#123; return FileDownloadConstant.DOWNLOAD_SOCKET_RETRY; &#125; catch (IOException e) &#123; bean.setErrorCode(FileDownloadConstant.FILE_DOWNLOAD_IO_EXCEPTION); bean.setErrorInfo(e.getMessage()); return FileDownloadConstant.DOWNLOAD_INTERVAL_RETRY; &#125; finally &#123; FileUtils.silentlyCloseCloseable(bis); FileUtils.silentlyCloseCloseable(inputStream); FileUtils.silentlyCloseCloseable(fos); &#125;&#125; 文章就到这里了，后面也可以把 DownloadFileTask 这个类加到一个单独的进程，采用aidl的方式跨进程调用，这里就不详说了。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/05/26/download-function-analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"download","slug":"download","permalink":"http://agehua.github.io/tags/download/"}]},{"title":"从FrameLayout分析View测量原理","slug":"Android-Measure","date":"2019-12-08T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/12/09/Android-Measure/","link":"","permalink":"http://agehua.github.io/2019/12/09/Android-Measure/","excerpt":"Android View测量原理public class DecorView extends FrameLayout implements RootViewSurfaceTaker, WindowCallbacks &#123;    //...&#125;\n我们知道DecorView是继承自FrameLayout，而且FrameLayout本身也比较简单，所以本文打算从FrameLayout的角度来分析view的measure过程。","text":"Android View测量原理public class DecorView extends FrameLayout implements RootViewSurfaceTaker, WindowCallbacks &#123; //...&#125; 我们知道DecorView是继承自FrameLayout，而且FrameLayout本身也比较简单，所以本文打算从FrameLayout的角度来分析view的measure过程。 View的根布局每个Activity都要重写onCreate方法，通常是调用setContentView来设置当前Activity的布局。那么每个Activity布局是放在了哪里呢？传说中的根布局到底是什么呢？一起往下看吧。@Override public void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); &#125; 进入setContentView的方法里面： public void setContentView(int layoutResID) &#123; getWindow().setContentView(layoutResID); initActionBar(); &#125; getWindow()会返回一个继承Window的PhoneWindow(TV的话，会是TVWindow)，然后执行它的setContentView()，而如下所示，PhoneWindow是在Activity的attach()中通过makeNewWindow生成的 final void attach(Context context, ActivityThread aThread, // 此处省去一些代码…… mWindow = PolicyManager.makeNewWindow(this); mWindow.setCallback(this); mWindow.getLayoutInflater().setPrivateFactory(this); if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) &#123; mWindow.setSoftInputMode(info.softInputMode); &#125; if (info.uiOptions != 0) &#123; mWindow.setUiOptions(info.uiOptions); &#125; // 此处省去巨量代码…… &#125; PolicyManager通过反射得到了Policy，如下 public final class PolicyManager &#123; private static final String POLICY_IMPL_CLASS_NAME = \"com.android.internal.policy.impl.Policy\"; private static final IPolicy sPolicy; static &#123; try &#123; Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME); sPolicy = (IPolicy)policyClass.newInstance(); &#125; catch (ClassNotFoundException ex) &#123; throw new RuntimeException( POLICY_IMPL_CLASS_NAME + \" could not be loaded\", ex); &#125; catch (InstantiationException ex) &#123; throw new RuntimeException( POLICY_IMPL_CLASS_NAME + \" could not be instantiated\", ex); &#125; catch (IllegalAccessException ex) &#123; throw new RuntimeException( POLICY_IMPL_CLASS_NAME + \" could not be instantiated\", ex); &#125; &#125; // 省去构造方法…… public static Window makeNewWindow(Context context) &#123; return sPolicy.makeNewWindow(context); &#125; // 省去无关代码…… &#125; 在Policy中的makeNewWindow()直接返回了一个PhoneWindow public Window makeNewWindow(Context context) &#123; return new PhoneWindow(context); &#125; 下面就说到了，上面提的setContentView() public class PhoneWindow extends Window implements MenuBuilder.Callback &#123; // 省去代码…… @Override public void setContentView(int layoutResID) &#123; if (mContentParent == null) &#123; installDecor(); &#125; else &#123; mContentParent.removeAllViews(); &#125; mLayoutInflater.inflate(layoutResID, mContentParent); final Callback cb = getCallback(); if (cb != null &amp;&amp; !isDestroyed()) &#123; cb.onContentChanged(); &#125; &#125; // 省去代码…… &#125; 到这里我们可以看出，就是将我们自己传进来的layoutId，添加到mContentParent下面，而这个mContentParent是在installDecor()里面赋值的，首先会初始化成员变量DecorView类的mDecor，然后调用generateLayout()，传入DecorView，来得到mContentParent。private void installDecor() &#123; if (mDecor == null) &#123; mDecor = generateDecor(); // 省省省…… &#125; if (mContentParent == null) &#123; mContentParent = generateLayout(mDecor); // 省省省…… &#125; // 省省省…… &#125;protected DecorView generateDecor(int featureId) &#123; // 省略context创建过程，主要是避免依赖到activity的context return new DecorView(context, featureId, this, getAttributes());&#125;protected ViewGroup generateLayout(DecorView decor) &#123; // 省去巨量代码…… ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT); // 省去一些代码…… &#125; 在generateLayout()中，会根据不同的Style类型来选择不同的布局文件，然后会add进DecorView中，然后调用findViewById()从DecorView里面得到mContentParent，这个才是真正的根布局，一般情况下，根布局都是FrameLayout来担任，我们可以用xml的最顶层viewGroup调用getParent()，返回的就是FrameLayout对象，其id是android:id=”@android:id/content”。 所以，一个Activity，里面是PhoneWindow，然后是DecorView，这个DecorView继承自FrameLayout，最后，才是我们自己setContentView的布局 VSYNC接下来，View就显示出来了么？我们熟知的 onMeasure、onLayout 和 onDraw都还没有调用呢？看起来，我们需要一个时机来触发 View 的操作。这个就得说下垂直同步机制(VSYNC)： VSYNC 就是一种同步机制，以某种固定的频率进行同步，当其他组件收到这个同步信号时，就执行相应的操作。设想一下，如果没有这个同步机制，各个模块又怎能知道在哪个时候去执行自己的工作了？ 这里可以初步地将 VSYNC 当做闹钟，每间隔固定时间，就响一次，其他组件听到闹铃后，就开始干活了。这个间隔的时间，与屏幕刷新频率有关，例如大多数 Android 设备的刷新频率是 60 FPS(Frame per second)，一秒钟刷新60次，因而间隔时间就是 1000 / 60 = 16.667 ms。这个时间，大家是不是很熟悉了？看过太多性能优化的文章，都说每一帧的绘制时间不要超过 16 ms，其背后的原因就是这个。绘制每一帧对应的 View，这个步骤发生在 UI 线程上，所以也不要在 UI 线程上进行耗时的操作，否则就可能在 16 ms内，无法完成界面更新操作了。 长话短说，总结一下，当 Choreographer 接收到 VSYNC 信号后，ViewRootImpl 调用 scheduleTraversals 方法，通知 View 进行相应的渲染，其后 ViewRootImpl 将 View 添加或更新到 Window 上去，并会执行TraversalRunnable 的doTraversal()，会调用到 performTraversals()，这是一个非常长的方法，里面就会提到我们熟悉的Measure、Layout 和 Draw。 measure()和onMeasure()performTraversals() 会调用到 performMeasure()方法：// ViewRootImpl中：private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) &#123; Trace.traceBegin(Trace.TRACE_TAG_VIEW, \"measure\"); try &#123; mView.measure(childWidthMeasureSpec, childHeightMeasureSpec); &#125; finally &#123; Trace.traceEnd(Trace.TRACE_TAG_VIEW); &#125;&#125; 这里的mView就是DecorView，但measure()方法View的，并且有final修饰，不能复写，在这个方法中调用了onMeasure()。在View中有默认的onMeasure实现： protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) &#123; setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec), getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));&#125;protected int getSuggestedMinimumWidth() &#123; return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth()); &#125;public static int getDefaultSize(int size, int measureSpec) &#123; int result = size; int specMode = MeasureSpec.getMode(measureSpec); int specSize = MeasureSpec.getSize(measureSpec); switch (specMode) &#123; case MeasureSpec.UNSPECIFIED: result = size; break; case MeasureSpec.AT_MOST: case MeasureSpec.EXACTLY: result = specSize; break; &#125; return result;&#125; getSuggestedMinimumWidth()，如果背景为空，那么我们直接返回mMinWidth最小宽度，否则，就在mMinWidth和背景最小宽度之间取一个最大值，getSuggestedMinimumHeight类同，mMinWidth和mMinHeight默认都是0。 getDefaultSize()中，当模式为AT_MOST和EXACTLY时均会返回解算出的测量尺寸，这里的specSize是。 FrameLayout的onMeasure方法@Overrideprotected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) &#123; int count = getChildCount(); // 父View传过来的layoutparams包含wrap_content属性 final boolean measureMatchParentChildren = MeasureSpec.getMode(widthMeasureSpec) != MeasureSpec.EXACTLY || MeasureSpec.getMode(heightMeasureSpec) != MeasureSpec.EXACTLY; mMatchParentChildren.clear(); int maxHeight = 0; int maxWidth = 0; int childState = 0; for (int i = 0; i &lt; count; i++) &#123; final View child = getChildAt(i); if (mMeasureAllChildren || child.getVisibility() != GONE) &#123; // 设置子View的宽度和高度，这里widthUsed 和 heightUsed都是0，说明子view想要多大就是多大 measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0); final LayoutParams lp = (LayoutParams) child.getLayoutParams(); // 累加子View的宽高和上下左右margin，统计所有子view中的最大宽度和高度，作为父view自己的宽高 maxWidth = Math.max(maxWidth, child.getMeasuredWidth() + lp.leftMargin + lp.rightMargin); maxHeight = Math.max(maxHeight, child.getMeasuredHeight() + lp.topMargin + lp.bottomMargin); childState = combineMeasuredStates(childState, child.getMeasuredState()); if (measureMatchParentChildren) &#123; if (lp.width == LayoutParams.MATCH_PARENT || lp.height == LayoutParams.MATCH_PARENT) &#123; // 子View指定了match_parent属性，需要在测量一次，先加到数组里 mMatchParentChildren.add(child); &#125; &#125; &#125; &#125; // 省略Foreground计算代码，非本文重点 // 第一次测量完成，让每个view按照自己想要的大小，同时FrameLayout自己的getMeasuredWidth() / // getMeasureHeight() 已经有值了 setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState), resolveSizeAndState(maxHeight, heightMeasureSpec, childState &lt;&lt; MEASURED_HEIGHT_STATE_SHIFT)); count = mMatchParentChildren.size(); if (count &gt; 1) &#123; // 有超过1个子View设置了match_parent属性，需要重新测量FrameLayout的宽高 for (int i = 0; i &lt; count; i++) &#123; final View child = mMatchParentChildren.get(i); final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams(); final int childWidthMeasureSpec; if (lp.width == LayoutParams.MATCH_PARENT) &#123; // 设置子view的宽度为当前FrameLayout测量后的宽度（这里getMeasuredWidth 就是上面setMeasuredDimension 后的宽度） final int width = Math.max(0, getMeasuredWidth() - getPaddingLeftWithForeground() - getPaddingRightWithForeground() - lp.leftMargin - lp.rightMargin); childWidthMeasureSpec = MeasureSpec.makeMeasureSpec( width, MeasureSpec.EXACTLY); &#125; else &#123; // 非match_parent: 将子view margin算入子view的宽度中 childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec, getPaddingLeftWithForeground() + getPaddingRightWithForeground() + lp.leftMargin + lp.rightMargin, lp.width); &#125; final int childHeightMeasureSpec; if (lp.height == LayoutParams.MATCH_PARENT) &#123; // 高度与宽度同理，都是设置子view的宽或高为FrameLayout的宽或高 final int height = Math.max(0, getMeasuredHeight() - getPaddingTopWithForeground() - getPaddingBottomWithForeground() - lp.topMargin - lp.bottomMargin); childHeightMeasureSpec = MeasureSpec.makeMeasureSpec( height, MeasureSpec.EXACTLY); &#125; else &#123; childHeightMeasureSpec = getChildMeasureSpec(heightMeasureSpec, getPaddingTopWithForeground() + getPaddingBottomWithForeground() + lp.topMargin + lp.bottomMargin, lp.height); &#125; // 更新child的宽度 child.measure(childWidthMeasureSpec, childHeightMeasureSpec); &#125; &#125;&#125; measureChildWithMargins是ViewGroup的方法，并且调用了child.measure方法。FrameLayout继承子ViewGroupprotected void measureChildWithMargins(View child, int parentWidthMeasureSpec, int widthUsed, int parentHeightMeasureSpec, int heightUsed) &#123; final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams(); final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec, mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin + widthUsed, lp.width); final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec, mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin + heightUsed, lp.height); child.measure(childWidthMeasureSpec, childHeightMeasureSpec);&#125; 总结：当FrameLayout的宽或高属性为Wrap_content属性时，同时有两个及以上的子view属性为match_parent时，则所有子view会measure两次 FrameLayout什么情况下子view会measure两次？需要满足两个条件：1.FrameLayout自身的MeasureSpec.Mode 不等于 MeasureSpec.EXACTLY。2.有两个或以上子view设置了match_parent 为什么这种情况FrameLayout会测量两次呢？我们先看下面这个问题： 获取ChildMeasureSpec时，FrameLayout 与 RelativeLayout 区别这里还有一个问题：getChildMeasureSpec是ViewGroup的静态方法，但是getChildMeasureSpec方法会改变子view的 MeasureSpec.Mode。 如果FrameLayout的SpecMode是AT_MOST或UNSPECIFIED，而子view的layout属性时MATCH_PARENT或WRAP_CONTENT，则子view的SpecMode会变成和父view一样 注意看下面代码的注释1和注释2public static int getChildMeasureSpec(int spec, int padding, int childDimension) &#123; // 获取父容器（这里指的是FrameLayout）的测量模式和尺寸大小 int specMode = MeasureSpec.getMode(spec); int specSize = MeasureSpec.getSize(spec); // 这个尺寸应该减去内边距的值 int size = Math.max(0, specSize - padding); // 声明临时变量存值 int resultSize = 0; int resultMode = 0; switch (specMode) &#123; case MeasureSpec.EXACTLY: // 父容器尺寸大小是一个确定的值 if (childDimension &gt;= 0) &#123; //如果childDimension是一个具体的值 那么就将该值作为结果 resultSize = childDimension; // 而这个值也是被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.MATCH_PARENT) &#123; //如果子元素的布局参数为MATCH_PARENT // 那么就将父容器的大小作为结果 resultSize = size; // 因为父容器的大小是被确定的所以子元素大小也是可以被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.WRAP_CONTENT) &#123; //如果子元素的布局参数为WRAP_CONTENT // 那么就将父容器的大小作为结果 resultSize = size; // 但是子元素的大小包裹了其内容后不能超过父容器 resultMode = MeasureSpec.AT_MOST; &#125; break; case MeasureSpec.AT_MOST: // 父容器尺寸大小拥有一个限制值 if (childDimension &gt;= 0) &#123; //如果childDimension是一个具体的值 // 那么就将该值作为结果 resultSize = childDimension; // 而这个值也是被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.MATCH_PARENT) &#123; //如果子元素的布局参数为MATCH_PARENT，那么就将父容器的大小作为结果 resultSize = size; // 注释1：因为父容器的大小是受到限制值的限制所以子元素的大小也应该受到父容器的限制 resultMode = MeasureSpec.AT_MOST; &#125; else if (childDimension == LayoutParams.WRAP_CONTENT) &#123; //如果子元素的布局参数为WRAP_CONTENT // 那么就将父容器的大小作为结果 resultSize = size; // 但是子元素的大小包裹了其内容后不能超过父容器 resultMode = MeasureSpec.AT_MOST; &#125; break; case MeasureSpec.UNSPECIFIED: // 父容器尺寸大小未受限制 if (childDimension &gt;= 0) &#123; //如果childDimension是一个具体的值，那么就将该值作为结果 resultSize = childDimension; // 而这个值也是被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.MATCH_PARENT) &#123; //如果子元素的布局参数为MATCH_PARENT // 注释2：因为父容器的大小不受限制而对子元素来说也可以是任意大小所以不指定也不限制子元素的大小 resultSize = 0; resultMode = MeasureSpec.UNSPECIFIED; &#125; else if (childDimension == LayoutParams.WRAP_CONTENT) &#123; //如果子元素的布局参数为WRAP_CONTENT // 因为父容器的大小不受限制而对子元素来说也可以是任意大小所以不指定也不限制子元素的大小 resultSize = 0; resultMode = MeasureSpec.UNSPECIFIED; &#125; break; &#125; // 返回封装后的测量规格 return MeasureSpec.makeMeasureSpec(resultSize, resultMode); 回答上面问题，为什么这种情况FrameLayout的子view会测量两次？先看下图：以宽度为例说明，因为FrameLayout可能包含多个子view，第一次测量后，设置了match_parent的view1和view2变为wrap_content，child.getMeasuredWidth为wrap_content的宽度，即子view自己的宽度。由于有多个match_parent的子view，父view需要重新调整自己的宽度为最大的子view的宽度，所以所有的子view需要在根据父view的宽度重新调整一下自己的宽度，最终导致子view measure两次。 多说一句，RelativeLayout并没有用这个方法，而是自定义了一个getChildMeasureSpec()方法，所以RelativeLayout与FrameLayout表现上是不一样的。感兴趣的可以在Android Studio里修改一下下面布局，替换RelativeLayout和FrameLayout，试一下看下效果： &lt;RelativeLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\"&gt; &lt;TextView android:layout_width=\"match_parent\" android:layout_height=\"match_parent\" android:background=\"@android:color/holo_red_light\" android:gravity=\"center\" android:text=\"text\" /&gt; &lt;TextView android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" android:gravity=\"center\" android:text=\"2222222222\" /&gt;&lt;/RelativeLayout&gt; Ref测量（Measure） 自定义View —— onMeasure、 onLayout 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/12/09/Android-Measure/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"FrameLayout","slug":"framelayout","permalink":"http://agehua.github.io/tags/framelayout/"},{"name":"RelativeLayout","slug":"relativelayout","permalink":"http://agehua.github.io/tags/relativelayout/"},{"name":"Measure","slug":"measure","permalink":"http://agehua.github.io/tags/measure/"}]},{"title":"弄懂Android 源码中那些巧妙位运算","slug":"Android-bits-operation","date":"2019-12-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2019/12/08/Android-bits-operation/","link":"","permalink":"http://agehua.github.io/2019/12/08/Android-bits-operation/","excerpt":"本文部分内容节选自星星笑语的文章\n原码反码补码的概念在介绍位运算符之前，我们先来看看关于反码补码等的相关知识。\n\n正数的原码反码补码相同，都是将数字转换为二进制形式，然后将高位补0。比如说对于8位来说：\n10所对应的原码反码补码都是 0000 1010\n30所对应的原码反码补码都是 0001 1110","text":"本文部分内容节选自星星笑语的文章 原码反码补码的概念在介绍位运算符之前，我们先来看看关于反码补码等的相关知识。 正数的原码反码补码相同，都是将数字转换为二进制形式，然后将高位补0。比如说对于8位来说： 10所对应的原码反码补码都是 0000 1010 30所对应的原码反码补码都是 0001 1110 而对于负数，负数的原码是它的绝对值对应的二进制，而最高位是1。所以： -10所对应的原码是 1000 1010 -30所对应的原码是 1001 1110 负数的反码是它原码最高位除外的其余所有位取反，所以： -10所对应的反码是 1111 0101 -30所对应的反码是 1110 0001 而负数的补码是将其反码的数值+1，所以： -10所对应的补码是 1111 0110 -30所对应的补码是 1110 0010 是不是感觉负数的三种很杂乱？没关系，马上让你觉得不过如此～ 我们对于刚才计算出来的负数的三种码，我们抛开符号为的概念，把三种码作为单存的二进制数来看。首先对于原码，原码是在最高位写上1得到的，而对于8位二进制，最高位的1是128，所以： -10所对应的原码是 1000 1010，而这个二进制数是128+10； -30所对应的原码是 1001 1110，而这个二进制数是128+30； 然后对于反码，在原码的基础上，最高位不变，其余各位取反，也就是说抛开最高位，其余各位变化前后的和是111 1111，所以： -10所对应的反码是 1111 0101，其值为127-10+128 -30所对应的反码是 1110 0001，其值为127-30+128 其余各位变化前后的和是111 1111，意思是 原码 + 反码 = 127 至于补码，就是反码加上1，所以： -10所对应的补码是 1111 0110，其值为256-10 -30所对应的补码是 1110 0010，其值为256-30 所以一个负数就可以看成是一个正数 256-x 计算机为什么要引入补码的概念呢？主要是补码能够简化计算，例如对于8位的二进制数，从0000 0000一直到1111 1111，如果看作补码，所表示的数依次为0，1，…，127，-128，-127，…，-2，-1。对于两个正数的加法，正数的补码就是它本身，所以直接相加就能得到结果（注意，如果和超过了127，结果会错误）； -128 对应的补码是 1000 0000，对应原码是 1 1000 0000 对于两个负数的加法，我们仍然可以将他们的补码直接相加，而得到结果～比如对于两个负数-a和-b，他们的补码分别是256-a和256-b，相加后是512-（a+b），当a+b小于128时（a+b&gt;128时这两个数相加超过了范围，得不到正确的结果），在计算机的表示是1 xxxx xxxx由于最高位的1超过了8位的范围所以舍去，所以相加结果是128-（a+b）而这就是-a-b的补码。 对于正数a和负数-b之间的加法，我们将其补码相加后得到256+a-b，而这就是a-b的补码（不管ab谁大都成立）。 由于减法可以对被减数取反，所以我们只用考虑加法运算。所以说如果使用补码，可以很好的将加减法运算转换成两个正数（负数的补码可以看成是一个正数256-x）的加法运算。如果计算机保存补码，在做数之间的加减法运算的时候能够直接将补码相加而得到正确的结果（没超过范围的情况下）。 我们也能够直接相加得到正确的结果。由于减法可以对被减数取反，所以我们只用考虑加法运算 实际上，考虑将所以有理数按256取模得到的数相等来分成256组，在做加减乘运算的时候，用同组的任意两个数运算得到的结果均是相同的，而负数和其补码是位于同一个组的，所以在做四则运算的时候，加减乘运算完全可以使用其的补码。 整型在 Java的内存形式学习完补码之后，我们认识到如果使用补码，其在做运算时的方便之处。而Java的整形就是保存的各个数的补码，我们也可以在 Java上验证： System.out.println(Integer.toHexString(-1));System.out.println(Integer.toHexString(-10));System.out.println(Integer.toHexString(Integer.MAX_VALUE));System.out.println(Integer.toHexString(Integer.MAX_VALUE));System.out.println(Long.toHexString(-1));System.out.println(Long.toHexString(Long.MAX_VALUE));fffffffffffffff67fffffff7fffffffffffffffffffffff7fffffffffffffff Java中的位运算要使用位运算之前，肯定是要了解下面的这些运算符号以及作用的。 与运算（and）&amp;表示，当两个相同位对应的数都是1的时候，该位获得的结果才是1，否则为0例如说6 &amp; 11，转换为二进制就是0110 &amp; 1011，结果为0010 或运算（or）|表示，当两个相同位对应的数只要有一个数1的时候，该位获得的结果为1，否则为0还是用6和11这两个数做例子，就是0110 | 1011 = 1111 非运算（not）~表示，这个运算只针对一个数字，将数字全部取反（原来是0结果就是1，原来是1结果就是0）。例如说：~110 = 001注意，这里的取反是对二进制数进行取反，如果对非二进制数取反，可能有意想不到的结果：System.out.println(\"～1 = \" + ~(1));System.out.println(\"～0 = \" + ~(0)); 这个例子是对整数int进行取反，结果是：~1 = -2 ~0 = -1，详细回答可以看这里 异或运算（xor）^表示，当两个相同位对应的数字不同的时候为1，否则为0例如说：0110 ^ 1011 = 1101 左移（shl）&lt;&lt;表示，a &lt;&lt; b表示a左移b位，由于移位在末位多出来的未知数字补零。在这里面可以等价为a * 2^b这个运算（针对十进制）。 右移（shr）&gt;&gt;表示，a &gt;&gt; b表示将a右移b位，原本的末位进行右移后会被舍弃，左边的用原有标志位补充。同样的，右移在十进制里面也可以近似为a / (2^b)的形式，不过要对结果取整，也不一定准确，只能够说意思大概如此。 无符号右移&gt;&gt;&gt;表示，不管正负标志位为0还是1，将该数的二进制码整体右移，左边部分总是以0填充，右边部分舍弃。 1 &lt;&lt; 1 = 2(对于int数的计算) 4 &gt;&gt; 1 = 2(对于int数的计算) 4 &gt;&gt;&gt; 1 = 2(对于int数的计算) System.out.println(Integer.toHexString(0x7fffffff &gt;&gt; 4));System.out.println(Integer.toHexString(0x8fffffff &gt;&gt; 4));System.out.println(Integer.toHexString(0xffffffff &gt;&gt; 4));System.out.println(Integer.toHexString(0x0fffffff &gt;&gt; 4));System.out.println();System.out.println(Integer.toHexString(0x7fffffff &lt;&lt; 4));System.out.println(Integer.toHexString(0x8fffffff &lt;&lt; 4));System.out.println(Integer.toHexString(0xffffffff &lt;&lt; 4));System.out.println(Integer.toHexString(0x0fffffff &lt;&lt; 4));System.out.println();System.out.println(Integer.toHexString(0x7fffffff &gt;&gt;&gt; 4));System.out.println(Integer.toHexString(0x8fffffff &gt;&gt;&gt; 4));System.out.println(Integer.toHexString(0xffffffff &gt;&gt;&gt; 4));System.out.println(Integer.toHexString(0x0fffffff &gt;&gt;&gt; 4)); 7ffffff f8ffffff ffffffff ffffff fffffff0 fffffff0 fffffff0 fffffff0 7ffffff 8ffffff fffffff ffffff 总结来说： 右移：整体向右移，原来的最高位是0，就补0，原来的最高位是1，就补1； 左移：整体左移，在最低位补0； 无符号右移：最高位补0。 位运算符的使用又如下几点需要注意： 位运算符都是在整型保存在内存地址上的每一位进行运算的，所以有些会看起来超出我们的常识； 左移右移并不能简单的看作是在数的基础上乘以2或者除以2，而要结合它的内存形式来具体分析。 例如：System.out.println(~1);结果是-2而不是0这是因为1在内存上是000....001,~1就是111...1110,而这是-2的补码，所以结果是-1；System.out.println(-1 &gt;&gt; 1);结果还是-1而不是0这是因为-1在内存上是111...1，它的符号位是1，所以右移的时候高位补1，结果不变；System.out.println(Integer.MAX_VALUE &lt;&lt; 1);结果是-2，正数左移移成了负数。。。System.out.println(0xBFFFFFFF);System.out.println(0xBFFFFFFF &lt;&lt; 1);-10737418252147483646负数左移成了正数。。。System.out.println(-1 &gt;&gt;&gt; 1);2147483647-1左移成了int的最大值。。。 Android中的应用 A | B 添加标志B，可以添加多个（只要不冲突）例如： mViewFlags = SOUND_EFFECTS_ENABLED | HAPTIC_FEEDBACK_ENABLED | FOCUSABLE_AUTO;// 或者mPrivateFlags |= PFLAG_FORCE_LAYOUT;mPrivateFlags |= PFLAG_INVALIDATED; A &amp; B 判断A中是否有标志B原理就是与运算之中的1 &amp; 1 = 1, 0 &amp; 1 = 0，以此来判断flag对应位是否存在该flag以(mViewFlags &amp; FOCUSABLE_AUTO) != 0这个判断语句为例：若为真，则与的结果不等于0，表示flag之中有该标志 (mPrivateFlags &amp; PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT A &amp; ~B 去除标志B（上者的逆运算）例如：mViewFlags = (mViewFlags &amp; ~FOCUSABLE) | newFocus用于去除原有的标志位并附上新的标志位（相当于更新） mPrivateFlags3 &amp;= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT; A ^ B 取出A与B不同的部分，一般用于判断A是否发生改变 int changed = mViewFlags ^ old;if (changed == 0) &#123; return;&#125; MeasureSpec许最早在Android源码里面接触位运算的话就是在自定义View部分的时候，当书里面提及MeasureSpec这个变量的时候采用如下描述： MeasureSpec代表一个32位int值，高2位代表SpecMode，低30位代表SpecSize，SpecMode是指测量模式，而SpecSize是指在某种测量模式下的规格大小。 这里面就是典型的位运算的运用，不论是这个变量需要分别拆分获得SpecMode和SpecSize，还是其他的一些相关的操作，都需要位运算。首先是SpecMode，在描述之中是高2位的部分，那么在处理之中一定会运用到左移或者右移来完成需求。 在这个类里面，一开始就声明了两个基本变量以及不同测量模式的值，已经用到了位运算中的左移// 声明位移量private static final int MODE_SHIFT = 30;// 后期截取SpecMode或SpecSize时使用的变量// 3对应的二进制是11，左移30位后，int值的前2位就都是1，后30位为0，二进制是：11000000000000000000000000000000private static final int MODE_MASK = 0x3 &lt;&lt; MODE_SHIFT;// 三种测量模式对应的值public static final int UNSPECIFIED = 0 &lt;&lt; MODE_SHIFT;public static final int EXACTLY = 1 &lt;&lt; MODE_SHIFT;public static final int AT_MOST = 2 &lt;&lt; MODE_SHIFT; 先看看是如何通过位运算来获取SpecMode和SpecSize：@MeasureSpecMode// 等价于@IntDef(value=&#123;...&#125;)。一种枚举类注释public static int getMode(int measureSpec) &#123; return (measureSpec &amp; MODE_MASK); // 让低30位的值变为0，只保留高2位的值&#125;public static int getSize(int measureSpec) &#123; return (measureSpec &amp; ~MODE_MASK); // 非运算直接让MASK值变成int值高2位为0，低30位为1 // 进行与运算，直接将高2位的值变为0&#125; 这里就是典型的通过位运算来截取对应值，利用的是x &amp; 1 = x, x &amp; 0 = 0，其中x代表0与1两种值。 这种方式让一个变量能够存储多个内容方式实现，甚至也可以使用这样的方式将合成的值作为特定的key来做匹配或者相似需求。接下来是如何获得MeasureSpec值：public static int makeMeasureSpec( @IntRange(from = 0, to = (1 &lt;&lt; MeasureSpec.MODE_SHIFT) - 1) int size, // 要求传入的size值在指定范围内 @MeasureSpecMode int mode) &#123; if (sUseBrokenMakeMeasureSpec) &#123;// 是否用原来的方法对MeasureSpec进行构建 return size + mode; &#125; else &#123; return (size &amp; ~MODE_MASK) | (mode &amp; MODE_MASK); &#125;&#125; 在API17及其以下的时候，是按照size + mode的方式进行构建，一个是只有int前2位有值，一个是只有int后30位有值，这么思考处理也情有可原。但假若两个值有溢出情况就会严重影响MeasureSpec的结果。故Google官方在API17之后就对该方法进行了修正，也是采用的位运算的形式：(size &amp; ~MODE_MASK) | (mode &amp; MODE_MASK)。相当于就是分别获得了SpecSize和SpecMode后通过或运算获得结果。 位运算应用口诀清零取反要用与，某位置一可用或若要取反和交换，轻轻松松用异或 Java中整形就是保存的各个数的补码。关于浮点型或原码、反码与补码的概念，请看这篇文章：Java基础补完之数值与位运算符 补充1、判断两个数是否异号int x = -1, y = 2;bool f = ((x ^ y) &lt; 0); // trueint x = 3, y = 2;bool f = ((x ^ y) &lt; 0); // false 这个技巧还是很实用的，利用的是补码编码的符号位。如果不用位运算来判断是否异号，需要使用if else分支，还挺麻烦的。有人可能想到利用乘积或者商来判断，但是这种方式可能造成溢出，从而出现错误。 Ref谈谈位运算和在Android中的运用 弄懂Android 源码中那些巧妙位运算 Android中巧妙的位运算 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/12/08/Android-bits-operation/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"bits operation","slug":"bits-operation","permalink":"http://agehua.github.io/tags/bits-operation/"}]},{"title":"CoordinatorLayout源码解读","slug":"Horizontal-Coordinator","date":"2019-09-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2019/09/12/Horizontal-Coordinator/","link":"","permalink":"http://agehua.github.io/2019/09/12/Horizontal-Coordinator/","excerpt":"CoordinatorLayout本文源码基于 27.1.1AppBarLayout 和 CoordinatorLayout是 2015年就已经推出的Material Design控件，一直以来也是只知其一这次通过阅读源码参考实现一个水平方向的 CoordinatorLayout和AppBarLayout组合。","text":"CoordinatorLayout本文源码基于 27.1.1AppBarLayout 和 CoordinatorLayout是 2015年就已经推出的Material Design控件，一直以来也是只知其一这次通过阅读源码参考实现一个水平方向的 CoordinatorLayout和AppBarLayout组合。CoordinatorLayout是一个增强型的FrameLayout。CoordinatorLayout#LayoutParams是用在子view上，对应在xml里子view的”app:layout_xxx“属性。通常的一个包含CoordinatorLayout的布局文件，大概是这样：&lt;android.support.design.widget.CoordinatorLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" xmlns:app=\"http://schemas.android.com/apk/res-auto\" xmlns:tools=\"http://schemas.android.com/tools\" android:layout_width=\"match_parent\" android:layout_height=\"match_parent\" android:id=\"@+id/coordinator\"&gt; &lt;android.support.design.widget.AppBarLayout android:layout_width=\"match_parent\" android:id=\"@+id/appbar\" android:layout_height=\"220dp\" android:background=\"#ffffff\"&gt; .... &lt;/android.support.design.widget.AppBarLayout&gt; &lt;android.support.v7.widget.RecyclerView android:layout_width=\"match_parent\" android:layout_height=\"500dp\" android:background=\"#1d9d29\" app:layout_behavior=\"@string/appbar_scrolling_view_behavior\"&gt; .... &lt;/android.support.v7.widget.RecyclerView&gt;&lt;/android.support.design.widget.CoordinatorLayout&gt; 来看一下CoordinatorLayout#LayoutParams的解析// CoordinatorLayout#LayoutParamsLayoutParams(Context context, AttributeSet attrs) &#123; super(context, attrs); final TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.CoordinatorLayout_Layout); // ... mBehaviorResolved = a.hasValue( R.styleable.CoordinatorLayout_Layout_layout_behavior); if (mBehaviorResolved) &#123; // 这里通过反射获得对应的Behavior对象 mBehavior = parseBehavior(context, attrs, a.getString( R.styleable.CoordinatorLayout_Layout_layout_behavior)); &#125; a.recycle(); if (mBehavior != null) &#123; // If we have a Behavior, dispatch that it has been attached mBehavior.onAttachedToLayoutParams(this); &#125;&#125; 感兴趣的可以继续点到CoordinatorLayout_Layoutstyle里面看看。 这里简单介绍几个属性： app:layout_anchor app:layout_anchorGravity这两个一般配合FloatingActionButton使用，用来指定位置 app:layout_behavior是本文的重点，为子View指定一个Behavider，是一个字符串，这是使用反射方式取得Behavior类。具体解析方式去看上面的parseBehavior()方法，这里不介绍了 Bahavior介绍在上面的布局文件里，RecyclerView指定了一个 appbar_scrolling_view_behavior，对应的类为： android.support.design.widget.AppBarLayout$ScrollingViewBehavior。这个Behavior也可以配合其他view使用，比如ViewPager、ListView、ScrollView。 AppBarLayout为什么没有指定layout_behavior呢？因为CoordinatorLayout提供了一个注解：@Deprecated@Retention(RetentionPolicy.RUNTIME)public @interface DefaultBehavior &#123; Class&lt;? extends Behavior&gt; value();&#125; 而AppBarLayout正是通过注解的方式添加的：@CoordinatorLayout.DefaultBehavior(AppBarLayout.Behavior.class)public class AppBarLayout extends LinearLayout &#123; //...&#125; 关于这个注解的解析在getResolvedLayoutParams(View child)这个方法里，感兴趣的可以去看一下。Behavior解析出来后，调用child.layoutParams.setBehavior()，保存在了child的LayoutParams的成员变量里。 CoordinatorLayout.Behavior是一个抽象类，总共有9个子类，直接子类有4个，如下： AppBarLayout.ScrollingViewBehavior 继承自 HeaderScrollingViewBehavior AppBarLayout.Behavior 继承自 HeaderBehavior BaseTransientBottomBar.Behavior 继承自 SwipeDismissBehavior BottomSheetBehavior FloatingActionButton.Behavior HeaderBehavior 继承自 ViewOffsetBehavior HeaderScrollingViewBehavior 继承自 ViewOffsetBehavior SwipeDismissBehavior ViewOffsetBehavior 下面以CoordinatorLayout + AppBarLayout + Recyclerview为例，分析用到的Behavior类结构如下： 现在CoordinatorLayout的子view都有了Behavior类，那么它们之间怎么和CoordinatorLayout交互并联动呢？ 以AppBarLayout + Recyclerview为例分析子View之间联动CoordinatorLayout是通过CoordinatorLayout.Behavior来控制子view的连动，这里涉及到触摸事件的处理。 @Overridepublic boolean onTouchEvent(MotionEvent ev) &#123; boolean handled = false; boolean cancelSuper = false; MotionEvent cancelEvent = null; final int action = ev.getActionMasked(); // 这里mBehaviorTouchView 会在 performIntercept()方法返回true时被赋值，表示将事件交给CoordinatorLayout处理 if (mBehaviorTouchView != null || (cancelSuper = performIntercept(ev, TYPE_ON_TOUCH))) &#123; // Safe since performIntercept guarantees that // mBehaviorTouchView != null if it returns true final LayoutParams lp = (LayoutParams) mBehaviorTouchView.getLayoutParams(); final Behavior b = lp.getBehavior(); // 通过mBehaviorTouchView的layoutParams来获取Behavior对象，交由mBehaviorTouchView的Behavior对象来处理事件 if (b != null) &#123; handled = b.onTouchEvent(this, mBehaviorTouchView, ev); &#125; &#125; // Keep the super implementation correct if (mBehaviorTouchView == null) &#123; // 如果mBehaviorTouchView 为空，则还是交由父类去处理touch事件 handled |= super.onTouchEvent(ev); &#125; //...&#125; 从上面分析可以看出，CoordinatorLayout本身并没有处理touch事件，而是哪个子view确定拦截事件后，交给这个子view的Behavior对象来处理这个事件。 我们以AppBarLayout + Recyclerview这两个比较常见的子View形式来分析。首先有两种滑动逻辑： 当手指触摸AppBarLayout时候的滑动逻辑为弄清手指触摸AppBarLayout时候的滑动逻辑，我们先看一下AppBarLayout.Behavior这个类。关于这个类的继承关系可以看上面的类图，这里先总结一下两个类的作用，需要详细的实现的请自行阅读源码吧： ViewOffsetBehavior：该Behavior主要运用于View的移动，从名字就可以看出来，该类中提供了上下移动，左右移动的方法。HeaderBehavior：该类主要用于View处理触摸事件以及触摸后的fling事件，AppBarLayout.Behavior的onTouchEvent和onInterceptTouchEvent处理逻辑都是在这里 HeaderBehavior的滑动都是通过setHeaderTopBottomOffset()方法处理的，这个方法在AppBarLayout.Behavior中进行了重写。 我们直接看AppBarLayout.Behavior中的源码：@Override//newOffeset传入了dy，也就是我们手指移动距离上一次移动的距离，//minOffset等于AppBarLayout的负的height，maxOffset等于0。int setHeaderTopBottomOffset(CoordinatorLayout coordinatorLayout, AppBarLayout appBarLayout, int newOffset, int minOffset, int maxOffset) &#123; final int curOffset = getTopBottomOffsetForScrollingSibling();//获取当前的滑动Offset int consumed = 0; //AppBarLayout滑动的距离如果超出了minOffset或者maxOffset，则直接返回0 if (minOffset != 0 &amp;&amp; curOffset &gt;= minOffset &amp;&amp; curOffset &lt;= maxOffset) &#123; //矫正newOffset，使其minOffset&lt;=newOffset&lt;=maxOffset newOffset = MathUtils.clamp(newOffset, minOffset, maxOffset); //由于默认没设置Interpolator，所以interpolatedOffset=newOffset; if (curOffset != newOffset) &#123; final int interpolatedOffset = appBarLayout.hasChildWithInterpolator() ? interpolateOffset(appBarLayout, newOffset) : newOffset; //调用ViewOffsetBehvaior的方法setTopAndBottomOffset(...)，最终通过 //ViewCompat.offsetTopAndBottom()移动AppBarLayout final boolean offsetChanged = setTopAndBottomOffset(interpolatedOffset); //记录下消费了多少的dy。 consumed = curOffset - newOffset; //没设置Interpolator的情况， mOffsetDelta永远=0 mOffsetDelta = newOffset - interpolatedOffset; //.... //分发回调OnOffsetChangedListener.onOffsetChanged(...) appBarLayout.dispatchOffsetUpdates(getTopAndBottomOffset()); updateAppBarLayoutDrawableState(coordinatorLayout, appBarLayout, newOffset, newOffset &lt; curOffset ? -1 : 1, false); &#125; //... return consumed;&#125; 上面注释也解释的比较清楚了，通过setTopAndBottomOffset()来计算AppBarLayout滑动多少距离，达到移动AppBarLayout的目的，那么这里AppBarLayout就可以跟着手上下移动了.但是，RecyclerView是如何跟随滑动的呢？在上面的布局文件里，我们给RecyclerView指定了一个layout_behavior，前面也说了这个Behavior是通过反射获取的，点击去可以找到这个类，它是：android.support.design.widget.AppBarLayout$ScrollingViewBehavior 注意区分，这个类不是我们上面提到的AppBarLayout.Behavior，两者并不相同 AppBarLayout$ScrollingViewBehavior重写了下面两个方法，并通过这两个方法将AppBarLayout和Recyclerview关联了起来@Overridepublic boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) &#123; // We depend on any AppBarLayouts return dependency instanceof AppBarLayout;&#125;@Overridepublic boolean onDependentViewChanged(CoordinatorLayout parent, View child, View dependency) &#123; offsetChildAsNeeded(parent, child, dependency); return false;&#125; Recyclerview依赖于AppBarLayout，在AppBarLayout移动的过程中，Recyclerview会随着AppBarLayout的移动回调onDependentViewChanged()方法，进而调用 offsetChildAsNeeded(parent, child, dependency) private void offsetChildAsNeeded(CoordinatorLayout parent, View child, View dependency) &#123; final CoordinatorLayout.Behavior behavior = ((CoordinatorLayout.LayoutParams) dependency.getLayoutParams()).getBehavior(); if (behavior instanceof Behavior) &#123; // Offset the child, pinning it to the bottom the header-dependency, maintaining // any vertical gap and overlap final Behavior ablBehavior = (Behavior) behavior; ViewCompat.offsetTopAndBottom(child, (dependency.getBottom() - child.getTop()) + ablBehavior.mOffsetDelta + getVerticalLayoutGap() - getOverlapPixelsForOffset(dependency)); &#125;&#125; 这样我们就知道了当手指移动AppBarLayout时候的过程，下面整理一下： 首先通过Behavior.onTouchEvent(…)收到滑动距离，进而通知AppBarLayout.Behavior调用ViewCompat.offsetTopAndBottom()进行滑动；在AppBarLayout滑动的过程中，由于Recyclerview中的ScrollingViewBehavior会依赖于AppBarLayout，所以在AppBarLayout滑动时候，Recyclerview也会随着滑动，调用的方法也是ViewCompat.offsetTopAndBottom()。 当手指触摸Recyclerview时的滑动逻辑在Touch触发的时候，先走到CoordinatorLayout的onInterceptTouchEvent()方法，然后走到performIntercept()，调用Behavior的onInterceptTouchEvent()方法，最终Recyclerview绑定的ScrollingViewBehavior并没有重写onInterceptTouchEvent()，所以父viewCoordinatorLayout并不会拦截这个Touch事件，所以会在Recyclerview的onInterceptTouchEvent进行处理。@Override public boolean onInterceptTouchEvent(MotionEvent e) &#123; //... final int action = e.getActionMasked(); final int actionIndex = e.getActionIndex(); switch (action) &#123; case MotionEvent.ACTION_DOWN: if (mIgnoreMotionEventTillDown) &#123; mIgnoreMotionEventTillDown = false; &#125; mScrollPointerId = e.getPointerId(0); mInitialTouchX = mLastTouchX = (int) (e.getX() + 0.5f); mInitialTouchY = mLastTouchY = (int) (e.getY() + 0.5f); if (mScrollState == SCROLL_STATE_SETTLING) &#123; getParent().requestDisallowInterceptTouchEvent(true); setScrollState(SCROLL_STATE_DRAGGING); &#125; // Clear the nested offsets mNestedOffsets[0] = mNestedOffsets[1] = 0; int nestedScrollAxis = ViewCompat.SCROLL_AXIS_NONE; if (canScrollHorizontally) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_HORIZONTAL; &#125; if (canScrollVertically) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_VERTICAL; &#125; // 在这里触发nestedscroll startNestedScroll(nestedScrollAxis, TYPE_TOUCH); break; //... &#125; return mScrollState == SCROLL_STATE_DRAGGING; &#125; Recyclerview实现了NestedScrollingChild2接口，但是具体实现都在NestedScrollingChildHelper类中public boolean startNestedScroll(@ScrollAxis int axes, @NestedScrollType int type) &#123; if (hasNestedScrollingParent(type)) &#123; // Already in progress return true; &#125; if (isNestedScrollingEnabled()) &#123; //是否支持嵌套滑动 ViewParent p = mView.getParent(); View child = mView; // mView就是当前的Recyclerview //从子View向外查询第一个接收滑动的父View，当前p就是CoordinatorLayout while (p != null) &#123; if (ViewParentCompat.onStartNestedScroll(p, child, mView, axes, type)) &#123; setNestedScrollingParentForType(type, p); //调用父view的onNestedScrollAccepted() ViewParentCompat.onNestedScrollAccepted(p, child, mView, axes, type); return true; &#125; if (p instanceof View) &#123; child = (View) p; &#125; p = p.getParent(); &#125; &#125; return false;&#125; 下面是ViewParentCompat.onStartNestedScroll()的处理代码：public static boolean onStartNestedScroll(ViewParent parent, View child, View target, int nestedScrollAxes, int type) &#123; if (parent instanceof NestedScrollingParent2) &#123; // First try the NestedScrollingParent2 API return ((NestedScrollingParent2) parent).onStartNestedScroll(child, target, nestedScrollAxes, type); &#125; else if (type == ViewCompat.TYPE_TOUCH) &#123; // Else if the type is the default (touch), try the NestedScrollingParent API return IMPL.onStartNestedScroll(parent, child, target, nestedScrollAxes); &#125; return false;&#125; CoordinatorLayout正好实现了NestedScrollingParent2接口，所以由CoordinatorLayout来处理onStartNestedScroll()方法@Overridepublic boolean onStartNestedScroll(View child, View target, int axes, int type) &#123; boolean handled = false; final int childCount = getChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; final View view = getChildAt(i); if (view.getVisibility() == View.GONE) &#123; // If it's GONE, don't dispatch continue; &#125; final LayoutParams lp = (LayoutParams) view.getLayoutParams(); final Behavior viewBehavior = lp.getBehavior(); // 由CoordinatorLayout转发给各个Behavior if (viewBehavior != null) &#123; final boolean accepted = viewBehavior.onStartNestedScroll(this, view, child, target, axes, type); handled |= accepted; lp.setNestedScrollAccepted(type, accepted); &#125; else &#123; lp.setNestedScrollAccepted(type, false); &#125; &#125; return handled;&#125; 上面代码可以看出，由CoordinatorLayout转发给各个Behavior，根据其返回值作进一步处理 下面是Behavior的onStartNestedScroll()方法的注释：/** * Called when a descendant of the CoordinatorLayout attempts to initiate a nested scroll. * * &lt;p&gt;Any Behavior associated with any direct child of the CoordinatorLayout may respond * to this event and return true to indicate that the CoordinatorLayout should act as * a nested scrolling parent for this scroll. Only Behaviors that return true from * this method will receive subsequent nested scroll events.&lt;/p&gt; //... * @see NestedScrollingParent2#onStartNestedScroll(View, View, int, int) */ 当CoordinatorLayout的子类想要启动一个nested scroll（嵌套滑动）时需要重写这个方法。CoordinatorLayout的子类可以响应这个事件，返回true表示CoordinatorLayout应该扮演一个嵌套滑动的父类。只有返回true的Behavior才会收到后续的嵌套滑动事件。 在这个例子中（AppBarLayout+ Recyclerview），只有AppBarLayout.Behavior重写了这个方法，并返回了true。但是这里并没有移动view的方法。 简单总结一下：Recyclerview作为子View滑动时候会首先调用startNestedScroll(…)方法来询问父View即CoordinatorLayout是否需要消费事件，CoordinatorLayout作为代理做发给对应Behavior，这里就分发给了AppBarLayout.Behavior，并返回true，说明AppBarLayout需要进行消费事件的处理.而ScrollingViewBehavior作为事件的触发者，并没有重写startNestedScroll()方法，所以返回false，表示不需要对事件进行消费。 前面分析了Recyclerview的onInterceptTouchEvent()的处理流程，父类并没有拦截Touch事件。所以，Touch事件肯定是在Recyclerview的 onTouchEvent()里进行了处理。最终，在Recyclerview的onTouchEvent对ACTION_MOVE的处理中看到了下面的代码：case MotionEvent.ACTION_MOVE: &#123; final int index = e.findPointerIndex(mScrollPointerId); if (index &lt; 0) &#123; Log.e(TAG, \"Error processing scroll; pointer index for id \" + mScrollPointerId + \" not found. Did any MotionEvents get skipped?\"); return false; &#125; final int x = (int) (e.getX(index) + 0.5f); final int y = (int) (e.getY(index) + 0.5f); int dx = mLastTouchX - x; int dy = mLastTouchY - y; // 1.这里向父view（CoordinatorLayout）分发了滑动处理 if (dispatchNestedPreScroll(dx, dy, mScrollConsumed, mScrollOffset, TYPE_TOUCH)) &#123; // 剪掉被AppBarLayout消耗的距离，剩下距离作为Recyclerview的滑动距离 dx -= mScrollConsumed[0]; dy -= mScrollConsumed[1]; vtev.offsetLocation(mScrollOffset[0], mScrollOffset[1]); // Updated the nested offsets mNestedOffsets[0] += mScrollOffset[0]; mNestedOffsets[1] += mScrollOffset[1]; &#125; //... if (mScrollState == SCROLL_STATE_DRAGGING) &#123; mLastTouchX = x - mScrollOffset[0]; mLastTouchY = y - mScrollOffset[1]; // 2.这里向父view（CoordinatorLayout）分发了滑动处理 if (scrollByInternal( canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, vtev)) &#123; getParent().requestDisallowInterceptTouchEvent(true); &#125; if (mGapWorker != null &amp;&amp; (dx != 0 || dy != 0)) &#123; mGapWorker.postFromTraversal(this, dx, dy); &#125; &#125;&#125; 进入上面注释2处：boolean scrollByInternal(int x, int y, MotionEvent ev) &#123; int unconsumedX = 0, unconsumedY = 0; int consumedX = 0, consumedY = 0; consumePendingUpdateOperations(); if (mAdapter != null) &#123; startInterceptRequestLayout(); onEnterLayoutOrScroll(); TraceCompat.beginSection(TRACE_SCROLL_TAG); fillRemainingScrollValues(mState); if (x != 0) &#123; consumedX = mLayout.scrollHorizontallyBy(x, mRecycler, mState); unconsumedX = x - consumedX; &#125; //... &#125; // dispatchNestedScroll也向CoordinatorLayout转发了处理 if (dispatchNestedScroll(consumedX, consumedY, unconsumedX, unconsumedY, mScrollOffset, TYPE_TOUCH)) &#123; // Update the last touch co-ords, taking any scroll offset into account mLastTouchX -= mScrollOffset[0]; mLastTouchY -= mScrollOffset[1]; if (ev != null) &#123; ev.offsetLocation(mScrollOffset[0], mScrollOffset[1]); &#125; mNestedOffsets[0] += mScrollOffset[0]; mNestedOffsets[1] += mScrollOffset[1]; &#125; else if (getOverScrollMode() != View.OVER_SCROLL_NEVER) &#123; if (ev != null &amp;&amp; !MotionEventCompat.isFromSource(ev, InputDevice.SOURCE_MOUSE)) &#123; pullGlows(ev.getX(), unconsumedX, ev.getY(), unconsumedY); &#125; considerReleasingGlowsOnScroll(x, y); &#125; if (consumedX != 0 || consumedY != 0) &#123; dispatchOnScrolled(consumedX, consumedY); &#125; if (!awakenScrollBars()) &#123; invalidate(); &#125; return consumedX != 0 || consumedY != 0;&#125; 从上面两段代码可以发现在Recyclerview的onTouch事件中，有两处将事件分发了出去，先简单说一下两个分发的流程顺序：1.dispatchNestedPreScroll流程是: Recyclerview.dispatchNestedPreScroll(…) -&gt; NestedScrollingChildHelper.dispatchNestedPreScroll(…)-&gt;ViewParentCompat.onNestedPreScroll()-&gt;NestedScrollingParent2.onNestedPreScroll()-&gt;CoordinatorLayout.onNestedPreScroll(…) 2.dispatchNestedScroll流程是: Recyclerview.dispatchNestedScroll(…) -&gt; NestedScrollingChildHelper.dispatchNestedScroll(…)-&gt;ViewParentCompat.onNestedScroll()-&gt;NestedScrollingParent2.onNestedScroll()-&gt;CoordinatorLayout.onNestedScroll(…) onNestedPreScroll和onNestedScroll区别关于这两者的区别，看一下谷歌给出的介绍： onNestedPreScroll is called each time the nested scroll is updated by the nested scrolling child, before the nested scrolling child has consumed the scroll distance itself. Each Behavior responding to the nested scroll will receive the same values. The CoordinatorLayout will report as consumed the maximum number of pixels in either direction that any Behavior responding to the nested scroll reported as consumed. 这里的the nested scrolling child指的是实现了NestedScrollingChild2或NestedScrollingChild接口的view。 onNestedPreScroll由the nested scrolling child发起，在the nested scrolling child消费滑动距离之前调用这个方法。任何响应嵌套滑动的Behavior消耗的像素数都是由CoordinatorLayout来转发。 onNestedScroll is called each time the nested scroll is updated by the nested scrolling child, with both consumed and unconsumed components of the scroll supplied in pixels. Each Behavior responding to the nested scroll will receive the same values. onNestedScroll也是由the nested scrolling child发起，并且每个响应嵌套滑动的Behavior都会收到相同的消耗和未消耗的像素数。 总结一下就是： onNestedPreScroll : 接收滑动控件处理滑动前的滑动距离信息，所有Behavior控件并且Behavior的isNestedScrollAccepted()返回true，都可以优先响应滑动操作。消耗部分或者全部滑动距离. onNestedScroll : 接收子控件处理完滑动后的滑动距离信息, 在这里外控件可以选择是否处理剩余的滑动距离. onNestedPreScroll流程分析下面先以onNestedPreScroll为例，分析滑动处理流程。在CoordinatorLayout的onNestedPreScroll()方法中@Overridepublic void onNestedPreScroll(View target, int dx, int dy, int[] consumed, int type) &#123; int xConsumed = 0; int yConsumed = 0; boolean accepted = false; final int childCount = getChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; final View view = getChildAt(i); if (view.getVisibility() == GONE) &#123; // If the child is GONE, skip... continue; &#125; final LayoutParams lp = (LayoutParams) view.getLayoutParams(); if (!lp.isNestedScrollAccepted(type)) &#123; // 没有接受事件，这里直接返回 continue; &#125; // 将事件转发给各个Behavior final Behavior viewBehavior = lp.getBehavior(); if (viewBehavior != null) &#123; mTempIntPair[0] = mTempIntPair[1] = 0; viewBehavior.onNestedPreScroll(this, view, target, dx, dy, mTempIntPair, type); xConsumed = dx &gt; 0 ? Math.max(xConsumed, mTempIntPair[0]) : Math.min(xConsumed, mTempIntPair[0]); yConsumed = dy &gt; 0 ? Math.max(yConsumed, mTempIntPair[1]) : Math.min(yConsumed, mTempIntPair[1]); accepted = true; &#125; &#125; consumed[0] = xConsumed; consumed[1] = yConsumed; if (accepted) &#123; onChildViewsChanged(EVENT_NESTED_SCROLL); &#125;&#125; 看到这里CoordinatorLayout遍历子view的Behavior，大家应该比较熟悉了。前面代码\bCoordinatorLayout的onStartNestedScroll()里有lp.setNestedScrollAccepted(type, accepted);这样一句话，由于Recyclerview的Behavior没有重写这个方法，所以accepted的值是false，导致这里lp.isNestedScrollAccepted(type)得到的值也是false，所以Recyclerview并不会执行onNestedPreScroll()方法。只有另一个子View(AppBarLayout) 会触发这个方法：AppBarLayout.Behavior的onNestedPreScroll()@Overridepublic void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child, View target, int dx, int dy, int[] consumed, int type) &#123; if (dy != 0) &#123; int min, max; if (dy &lt; 0) &#123; // We're scrolling down min = -child.getTotalScrollRange(); max = min + child.getDownNestedPreScrollRange(); &#125; else &#123; // We're scrolling up min = -child.getUpNestedPreScrollRange(); max = 0; &#125; if (min != max) &#123; // AppBarLayout只支持垂直方向，这里只需要更新Y方向值就可以 consumed[1] = scroll(coordinatorLayout, child, dy, min, max); &#125; &#125;&#125; scroll()会调用setHeaderTopBottomOffset()方法，这个方法在前面介绍手指触摸AppBarLayout时已经贴过，这里就不贴了，需要注意的是AppBarLayout.Behavior对setHeaderTopBottomOffset()方法进行了重写。 consumed的值有两种情况： 当滑动的距离在minOffset和maxOffset区间之内，则consume!=0，也就说明需要AppBarLayout进行消费，这里对应着AppBarLayout还没移出我们的视线时候的消费情况。 当滑动的距离超出了minOffset或者maxOffset后，则consume==0，也就说明需要AppBarLayout不进行消费了，这里对应着AppBarLayout移出我们的视线时候的消费情况。 再看一下刚才CoordinatorLayout.onNestedPreScroll()方法中最后一句onChildViewsChanged(EVENT_NESTED_SCROLL); final void onChildViewsChanged(@DispatchChangeEvent final int type) &#123; //... for (int i = 0; i &lt; childCount; i++) &#123; //... // Get the current draw rect of the view getChildRect(child, true, drawRect); //... if (type != EVENT_VIEW_REMOVED) &#123; // Did it change? if not continue getLastChildRect(child, lastDrawRect); if (lastDrawRect.equals(drawRect)) &#123; //当前view的宽高没有发生变化 continue; &#125; recordLastChildRect(child, drawRect); &#125; // Update any behavior-dependent views for the change for (int j = i + 1; j &lt; childCount; j++) &#123; // j 从1开始，checkChild就是Recyclerview final View checkChild = mDependencySortedChildren.get(j); final LayoutParams checkLp = (LayoutParams) checkChild.getLayoutParams(); final Behavior b = checkLp.getBehavior(); // 这里b是AppBarLayout.ScrollingViewBehavior，layoutDependsOn()返回true if (b != null &amp;&amp; b.layoutDependsOn(this, checkChild, child)) &#123; if (type == EVENT_PRE_DRAW &amp;&amp; checkLp.getChangedAfterNestedScroll()) &#123; // If this is from a pre-draw and we have already been changed // from a nested scroll, skip the dispatch and reset the flag checkLp.resetChangedAfterNestedScroll(); continue; &#125; final boolean handled; switch (type) &#123; case EVENT_VIEW_REMOVED: // EVENT_VIEW_REMOVED means that we need to dispatch // onDependentViewRemoved() instead b.onDependentViewRemoved(this, checkChild, child); handled = true; break; default: // Otherwise we dispatch onDependentViewChanged() // 传进来的type = EVENT_NESTED_SCROLL handled = b.onDependentViewChanged(this, checkChild, child); break; &#125; if (type == EVENT_NESTED_SCROLL) &#123; // If this is from a nested scroll, set the flag so that we may skip // any resulting onPreDraw dispatch (if needed) checkLp.setChangedAfterNestedScroll(handled); &#125; &#125; &#125; &#125; &#125; 在AppBarLayout.ScrollingViewBehavior的onDependentViewChanged()方法中，会调用其offsetChildAsNeeded()方法private void offsetChildAsNeeded(CoordinatorLayout parent, View child, View dependency) &#123; final CoordinatorLayout.Behavior behavior = ((CoordinatorLayout.LayoutParams) dependency.getLayoutParams()).getBehavior(); if (behavior instanceof Behavior) &#123; // Offset the child, pinning it to the bottom the header-dependency, maintaining // any vertical gap and overlap final Behavior ablBehavior = (Behavior) behavior; ViewCompat.offsetTopAndBottom(child, (dependency.getBottom() - child.getTop()) + ablBehavior.mOffsetDelta + getVerticalLayoutGap() - getOverlapPixelsForOffset(dependency)); &#125;&#125; dependency这里就是AppBarLayout，child就是Recyclerview，而parent当然就是CoordinatorLayout了。这个方法就是根据AppBarLayout的位置，来调整Recyclerview的位置。如果注释掉这个代码，滑动过程中，Recyclerview左边距位置不会调整，会和AppBarLayout之间出现空白。 onNestedScroll流程分析与上面类似，来看CoordinatorLayout的onNestedScroll()方法：@Overridepublic void onNestedScroll(View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed, int type) &#123; final int childCount = getChildCount(); boolean accepted = false; for (int i = 0; i &lt; childCount; i++) &#123; final View view = getChildAt(i); if (view.getVisibility() == GONE) &#123; // If the child is GONE, skip... continue; &#125; //这里也是先判断是否接受嵌套滑动 final LayoutParams lp = (LayoutParams) view.getLayoutParams(); if (!lp.isNestedScrollAccepted(type)) &#123; continue; &#125; // 分发给每个Behavior final Behavior viewBehavior = lp.getBehavior(); if (viewBehavior != null) &#123; viewBehavior.onNestedScroll(this, view, target, dxConsumed, dyConsumed, dxUnconsumed, dyUnconsumed, type); accepted = true; &#125; &#125; if (accepted) &#123; onChildViewsChanged(EVENT_NESTED_SCROLL); &#125;&#125; 同样，在我们例子中，Recyclerview的isNestedScrollAccepted返回的是false，所以也不会处理onNestedScroll()逻辑。因为当前是拖动Recyclerview来移动AppBarLayout，所以Recyclerview没必要处理onNestedScroll()方法. 找到AppBarLayout#Behavior类的onNestedScroll()方法中：@Overridepublic void onNestedScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child, View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed, int type) &#123; if (dyUnconsumed &lt; 0) &#123; // 小于0表示view要向下滑动 // If the scrolling view is scrolling down but not consuming, it's probably be at // the top of it's content scroll(coordinatorLayout, child, dyUnconsumed, -child.getDownNestedScrollRange(), 0); &#125;&#125; 可以看到这里AppBarLayout处理了垂直方向向下的滑动。 水平方向联动系统的AppBarLayout只支持垂直方向：@Overridepublic void setOrientation(int orientation) &#123; if (orientation != VERTICAL) &#123; throw new IllegalArgumentException(\"AppBarLayout is always vertical and does\" + \" not support horizontal orientation\"); &#125; super.setOrientation(orientation);&#125; 要实现水平方向的AppBarLayout，只需要按照上面的分析，重写对应的方法，具体代码放在了这里Github agehua/HorizontalCoordinatorDemo RefCoordinatorLayout三部曲学习之三：AppBarLayout联动源码学习 安卓自定义View进阶-多点触控详解 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/09/12/Horizontal-Coordinator/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"CoordinatorLayout","slug":"coordinatorlayout","permalink":"http://agehua.github.io/tags/coordinatorlayout/"}]},{"title":"LeakCanary源码分析及借鉴","slug":"LeakCanary_source_code","date":"2019-07-29T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2019/07/30/LeakCanary_source_code/","link":"","permalink":"http://agehua.github.io/2019/07/30/LeakCanary_source_code/","excerpt":"煤矿中的金丝雀LeakCanary是一个帮我们在Android或Java项目开发时检测内存泄漏的库。\n本文以LeakCanary-1.5.1版本为例，分析LeakCanary原理，以及借鉴其中的方法。","text":"煤矿中的金丝雀LeakCanary是一个帮我们在Android或Java项目开发时检测内存泄漏的库。 本文以LeakCanary-1.5.1版本为例，分析LeakCanary原理，以及借鉴其中的方法。关于它的图标有一个故事： 17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。 内存泄漏检测的基本原理给弱引用关联一个引用队列，当弱引用持有内容被gc回收后，该弱引用会被添加到关联的引用队列中。 试试下面的代码，注释掉user=null;和不注释掉，看看有什么不同public class RefTest &#123; public static void main(String[] args) &#123; //user为强引用 User user = new User(\"张三\", 18); //创建弱引用并关联引用队列 ReferenceQueue&lt;User&gt; queue = new ReferenceQueue&lt;&gt;(); WeakReference&lt;User&gt; weakReference = new WeakReference&lt;User&gt;(user,queue); //置空强引用，触发GC user=null; Runtime.getRuntime().gc(); try &#123; Thread.sleep(100); &#125; catch (InterruptedException e) &#123; e.printStackTrace(); &#125; //强制系统回收已经没有强引用的对象 System.runFinalization(); WeakReference pollRef=null; //弹出对列的引弱用 while ((pollRef = (WeakReference) queue.poll()) != null) &#123; System.out.println(\"pollRef的内存地址:\"+pollRef.toString()); System.out.println(\"pollRef等于weakReference？:\"+weakReference.equals(pollRef)); &#125; &#125;&#125; Java垃圾回收(GC) 在Java中垃圾判断方法是 可达性分析算法，这个算法的基本思路是通过一系列的”GC Root”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC Root没有任何引用链相连时，则证明此对象是不可用的。 GC Root的对象包括以下几种： 1、虚拟机栈中引用的对象。 2、方法区中类静态属性引用的对象。 3、方法区中常量引用的对象。 4、本地方法栈中JNI引用的对象。 就算一个对象，通过可达性分析算法分析后，发现其是『不可达』的，也并不是非回收不可的。一般情况下，要宣告一个对象死亡，至少要经过两次标记过程： 1、经过可达性分析后，一个对象并没有与GC Root关联的引用链，将会被第一次标记和筛选。筛选条件是此对象有没有必要执行finalize()方法。如果对象没有覆盖finalize()方法，或者已经执行过了。那就认为他可以回收了。如果有必要执行finalize()方法，那么将会把这个对象放置到F-Queue的队列中，等待执行。 2、虚拟机会建立一个低优先级的Finalizer线程执行F-Queue里面的对象的finalize()方法。如果对象在finalize()方法中可以『拯救』自己，那么将不会被回收，否则，他将被移入一个即将被回收的ReferenceQueue。 LeakCanary使用LeakCanary在Application初始化，代码如下: public class BaseApplication extends Application &#123; @Override public void onCreate() &#123; super.onCreate(); //检查当前进程是否在HeapAnalyzerService所属进程 if (LeakCanary.isInAnalyzerProcess(this)) &#123; return; &#125; //安装泄露检测 LeakCanary.install(this); &#125; &#125; 编译成功后，可以在debug状态下的AndroidManifest.xml文件中，看到LeakCanary注册的组件。&lt;!-- 这个是LeakCanary分析泄露的Service --&gt; &lt;service android:name=\"com.squareup.leakcanary.internal.HeapAnalyzerService\" android:enabled=\"false\" android:process=\":leakcanary\" /&gt; &lt;!-- 这个是LeakCanary展示泄露的Service --&gt; &lt;service android:name=\"com.squareup.leakcanary.DisplayLeakService\" android:enabled=\"false\"/&gt; &lt;activity android:name=\"com.squareup.leakcanary.internal.DisplayLeakActivity\" android:enabled=\"false\" android:icon=\"@mipmap/leak_canary_icon\" android:label=\"@string/leak_canary_display_activity_label\" android:taskAffinity=\"com.squareup.leakcanary.com.pengguanming.studydemo\" android:theme=\"@style/leak_canary_LeakCanary.Base\" &gt; &lt;intent-filter&gt; &lt;action android:name=\"android.intent.action.MAIN\" /&gt; &lt;category android:name=\"android.intent.category.LAUNCHER\" /&gt; &lt;/intent-filter&gt; &lt;/activity&gt; 其中DisplayLeakActivity被设置为Launcher，并设置了金丝雀的icon，这也就是为什么使用LeakCanary会在桌面上生成icon入口的原因。但是，这里要注意DisplayLeakActivity的enable属性被设置为false了，默认在桌面上是不会显示入口的。 监听Activity销毁的方法返回来看 LeakCanary.install(this)方法/** * Creates a &#123;@link RefWatcher&#125; that works out of the box, and starts watching activity * references (on ICS+). */public static RefWatcher install(Application application) &#123; return refWatcher(application).listenerServiceClass(DisplayLeakService.class) .excludedRefs(AndroidExcludedRefs.createAppDefaults().build()) .buildAndInstall();&#125;/** Builder to create a customized &#123;@link RefWatcher&#125; with appropriate Android defaults. */public static AndroidRefWatcherBuilder refWatcher(Context context) &#123; return new AndroidRefWatcherBuilder(context);&#125; install方法通过AndroidRefWatcherBuilder，构造了一个RefWatcher对象，再看buildAndInstall()方法：public RefWatcher buildAndInstall() &#123; RefWatcher refWatcher = build(); if (refWatcher != DISABLED) &#123; LeakCanary.enableDisplayLeakActivity(context); ActivityRefWatcher.install((Application) context, refWatcher); &#125; return refWatcher;&#125; ActivityRefWatcher.install()调用了watchActivities()方法。public static void install(Application application, RefWatcher refWatcher) &#123; new ActivityRefWatcher(application, refWatcher).watchActivities();&#125; watchActivities()通过传过来的application对象注册了一个registerActivityLifecycleCallbacks。public void watchActivities() &#123; // Make sure you don't get installed twice. stopWatchingActivities(); application.registerActivityLifecycleCallbacks(lifecycleCallbacks);&#125; 这个监听只监听了onActivityDestroyed()方法private final Application.ActivityLifecycleCallbacks lifecycleCallbacks = new ActivityLifecycleCallbacksAdapter() &#123; @Override public void onActivityDestroyed(Activity activity) &#123; refWatcher.watch(activity); &#125;&#125;; 上面就是LeakCanary注册监听Activity onDestroy()生命周期的过程 检测对象弱引用关联引用队列前面提到，弱引用关联一个引用队列，当弱引用保存的引用被释放掉后，弱引用就会进入到引用队列中，LeakCanary当然也是用这种方式，不过它更聪明。 进入到refWatcher.watch()方法中： public void watch(Object watchedReference, String referenceName) &#123; if (this == DISABLED) &#123; return; &#125; // 这里的 watchedReference 就是一个 Activity checkNotNull(watchedReference, \"watchedReference\"); checkNotNull(referenceName, \"referenceName\"); final long watchStartNanoTime = System.nanoTime(); String key = UUID.randomUUID().toString(); // 为每个 watchedReference 生成一个随机key，将key添加到retainedKeys中 retainedKeys.add(key); // 每次创建一个弱引用，并关联一个引用队列 final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue); ensureGoneAsync(watchStartNanoTime, reference);&#125; 上面的retainedKeys是一个支持并发访问的 CopyOnWriteArraySet 对象。这个 KeyedWeakReference 里的key值就是LeakCanary聪明的地方了final class KeyedWeakReference extends WeakReference&lt;Object&gt; &#123; public final String key; public final String name; KeyedWeakReference(Object referent, String key, String name, ReferenceQueue&lt;Object&gt; referenceQueue) &#123; super(checkNotNull(referent, \"referent\"), checkNotNull(referenceQueue, \"referenceQueue\")); // 比普通 WeakReference 多了两个参数，其中的 key 最为关键 this.key = checkNotNull(key, \"key\"); this.name = checkNotNull(name, \"name\"); &#125;&#125; 为什么要多保存一个key值呢？它在哪里用到了呢？继续往下看：private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) &#123; // 这里逻辑先不考虑，直接看 ensureGone() watchExecutor.execute(new Retryable() &#123; @Override public Retryable.Result run() &#123; return ensureGone(reference, watchStartNanoTime); &#125; &#125;);&#125; @SuppressWarnings(\"ReferenceEquality\") // Explicitly checking for named null.Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) &#123; // 计算watch方法到gc垃圾回收的时长 long gcStartNanoTime = System.nanoTime(); long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime); // 尝试移除已经到达引用队列的弱引用 removeWeaklyReachableReferences(); if (debuggerControl.isDebuggerAttached()) &#123; // The debugger can create false leaks. return RETRY; &#125; if (gone(reference)) &#123; return DONE; &#125; // 手动gc gcTrigger.runGc(); // gc后，再次移除引用队列中的弱引用 removeWeaklyReachableReferences(); if (!gone(reference)) &#123; // 弱引用没有被移除，说明内存泄漏了 long startDumpHeap = System.nanoTime(); long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime); // 确定泄漏后，生成prof文件 File heapDumpFile = heapDumper.dumpHeap(); if (heapDumpFile == RETRY_LATER) &#123; // Could not dump the heap. return RETRY; &#125; long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap); heapdumpListener.analyze( new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs, gcDurationMs, heapDumpDurationMs)); &#125; return DONE;&#125;private boolean gone(KeyedWeakReference reference) &#123; return !retainedKeys.contains(reference.key);&#125;private void removeWeaklyReachableReferences() &#123; // WeakReferences are enqueued as soon as the object to which they point to becomes weakly // reachable. This is before finalization or garbage collection has actually happened. KeyedWeakReference ref; while ((ref = (KeyedWeakReference) queue.poll()) != null) &#123; retainedKeys.remove(ref.key); &#125;&#125; 在removeWeaklyReachableReferences()方法中，将queue队列里所有弱引用弹栈。如果出栈了，就移除掉retainedKeys中保存的key。 在gone()方法判断，如果retainedKeys依然包含reference的key，说明该reference没有进入queue队列，也就是没有释放掉对象的引用，所以很可能是发生了内存泄漏。 所以KeyedWeakReference中保存的key值，就是为了方便判断当前的弱引用是否发生了内存泄漏。 LeakCanary的线程调度刚才再看刚才忽略的 watchExecutor.execute()方法，watchExecutor是一个接口，它的实现类是AndroidWatchExecutor。public final class AndroidWatchExecutor implements WatchExecutor &#123; static final String LEAK_CANARY_THREAD_NAME = \"LeakCanary-Heap-Dump\"; private final Handler mainHandler; private final Handler backgroundHandler; private final long initialDelayMillis; private final long maxBackoffFactor; public AndroidWatchExecutor(long initialDelayMillis) &#123; mainHandler = new Handler(Looper.getMainLooper()); HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME); handlerThread.start(); backgroundHandler = new Handler(handlerThread.getLooper()); this.initialDelayMillis = initialDelayMillis; maxBackoffFactor = Long.MAX_VALUE / initialDelayMillis; &#125; @Override public void execute(Retryable retryable) &#123; // 最终都会切换到主线程，调用waitForIdle()方法 if (Looper.getMainLooper().getThread() == Thread.currentThread()) &#123; waitForIdle(retryable, 0); &#125; else &#123; postWaitForIdle(retryable, 0); &#125; &#125; void postWaitForIdle(final Retryable retryable, final int failedAttempts) &#123; // 切换到主线程 mainHandler.post(new Runnable() &#123; @Override public void run() &#123; waitForIdle(retryable, failedAttempts); &#125; &#125;); &#125; void waitForIdle(final Retryable retryable, final int failedAttempts) &#123; // This needs to be called from the main thread. // 在主线程执行下面代码 Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() &#123; @Override public boolean queueIdle() &#123; postToBackgroundWithDelay(retryable, failedAttempts); // 方法如果返回 false，这个 IdleHandler 只会执行一次 return false; &#125; &#125;); &#125; void postToBackgroundWithDelay(final Retryable retryable, final int failedAttempts) &#123; // 设置延迟发送时间 long exponentialBackoffFactor = (long) Math.min(Math.pow(2, failedAttempts), maxBackoffFactor); long delayMillis = initialDelayMillis * exponentialBackoffFactor; // 子线程运行一个runnable backgroundHandler.postDelayed(new Runnable() &#123; @Override public void run() &#123; Retryable.Result result = retryable.run(); if (result == RETRY) &#123; postWaitForIdle(retryable, failedAttempts + 1); &#125; &#125; &#125;, delayMillis); &#125;&#125; AndroidWatchExecutor类中，有两个handler，一个在main thread，一个在HandlerThread的子线程中。外部调用execute()方法，最终都会在主线程调用waitForIdle()方法。 waitForIdle()运行在主线程，会在主线程添加一个IdleHandler。 IdleHandler的妙用 IdleHandler，这是一种在只有当消息队列没有消息时或者是队列中的消息还没有到执行时间时才会执行的 IdleHandler，它存放在 mPendingIdleHandlers 队列中。 关于IdleHandler如何使用，这篇文章提供了一个非常好的方法：你知道android的MessageQueue.IdleHandler吗？ 简单总结下这篇文章： 1.使用HandlerThread，利用HandlerThread绑定的子线程Handler，实现单线程队列处理数据+异步线程接收数据更新 2.反射HandlerThread，得到MessageQueue对象，调用MessageQueue.addIdleHandler() 3.在IdleHandler的queueIdle()回调方法里通知数据改变 这样做有两个好处： 1.HanlderThread按加入顺序操作数据，不需要对数据加锁 2.对HandlerThread的MessageQueue调用addIdleHandler()，不管操作了多少遍数据，只会在所有操作完成后（idle），通知数据的监听者，避免频繁更新UI AndroidWatchExecutor的作用就是，在主线程空闲的时候才会调用，并且是延迟调用子线程的retryable.run()方法。这样可以保证不影响主线程的流畅度。 手动触发GC上面的retryable.run()运行在子线程，说明ensureGone()就是在子线程。在看一下LeakCanary是如何调用GC的：public interface GcTrigger &#123; GcTrigger DEFAULT = new GcTrigger() &#123; @Override public void runGc() &#123; // Code taken from AOSP FinalizationTest: // https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/ // java/lang/ref/FinalizationTester.java // System.gc() does not garbage collect every time. Runtime.gc() is // more likely to perfom a gc. Runtime.getRuntime().gc(); enqueueReferences(); System.runFinalization(); &#125; private void enqueueReferences() &#123; // Hack. We don't have a programmatic way to wait for the reference queue daemon to move // references to the appropriate queues. try &#123; Thread.sleep(100); &#125; catch (InterruptedException e) &#123; throw new AssertionError(); &#125; &#125; &#125;; void runGc();&#125; gcTrigger.runGc() 先会调用 Runtime.getRuntime().gc() 以触发系统gc操作，然后当前后台子线程sleep 100毫秒，最后调用System.runFinalization()强制系统回收没有引用的队列，这样确保引用对象是否真的被回收了。 泄露信息分析上面 heapDumper.dumpHeap() 方法的具体实现是在AndroidHeapDumper类中：@SuppressWarnings(\"ReferenceEquality\") // Explicitly checking for named null.@Override public File dumpHeap() &#123; // 创建一个XXX_pending.hprof文件，这种文件最多7个 // 文件存储路径为 /storage/emulated/0/Download/leakcanary-xxx(package-name)/ File heapDumpFile = leakDirectoryProvider.newHeapDumpFile(); if (heapDumpFile == RETRY_LATER) &#123; // 文件创建失败 return RETRY_LATER; &#125; FutureResult&lt;Toast&gt; waitingForToast = new FutureResult&lt;&gt;(); showToast(waitingForToast); if (!waitingForToast.wait(5, SECONDS)) &#123; CanaryLog.d(\"Did not dump heap, too much time waiting for Toast.\"); return RETRY_LATER; &#125; Toast toast = waitingForToast.get(); try &#123; // 向文件写入内容 Debug.dumpHprofData(heapDumpFile.getAbsolutePath()); cancelToast(toast); return heapDumpFile; &#125; catch (Exception e) &#123; CanaryLog.d(e, \"Could not dump heap\"); // Abort heap dump return RETRY_LATER; &#125; &#125;private void showToast(final FutureResult&lt;Toast&gt; waitingForToast) &#123; mainHandler.post(new Runnable() &#123; @Override public void run() &#123; final Toast toast = new Toast(context); toast.setGravity(Gravity.CENTER_VERTICAL, 0, 0); toast.setDuration(Toast.LENGTH_LONG); LayoutInflater inflater = LayoutInflater.from(context); toast.setView(inflater.inflate(R.layout.leak_canary_heap_dump_toast, null)); toast.show(); // Waiting for Idle to make sure Toast gets rendered. Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() &#123; @Override public boolean queueIdle() &#123; waitingForToast.set(toast); return false; &#125; &#125;); &#125; &#125;); &#125;private void cancelToast(final Toast toast) &#123; mainHandler.post(new Runnable() &#123; @Override public void run() &#123; toast.cancel(); &#125; &#125;); &#125; 这里的FutureResult，会阻塞当前后台子线程，并监听主线程是否空闲，若5秒内不空闲，则返回RETRY_LATER。若主线程空闲则会调用waitingForToast.set(toast)，不在阻塞后台子线程，调用android.os.Debug.dumpHprofData()生成.prof文件。 Debug.dumpHprofData 会导致线程阻塞。因为dumpheap的操作是在应用进程的主线程中进行操作，本质上是在该应用进程的虚拟机中进行，dumpheap时应用进程会block住，如过heap文件过大很容易导致应用进程操作界面卡住，如果此时再进行点击或滑动等操作极易再抛出anr等弹窗，用户体验极差。 这里介绍下 FutureResult 的实现：public final class FutureResult&lt;T&gt; &#123; // AtomicReference实现对象引用的原子更新 private final AtomicReference&lt;T&gt; resultHolder; // 同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待 private final CountDownLatch latch; public FutureResult() &#123; resultHolder = new AtomicReference&lt;&gt;(); latch = new CountDownLatch(1); &#125; public boolean wait(long timeout, TimeUnit unit) &#123; try &#123; return latch.await(timeout, unit); &#125; catch (InterruptedException e) &#123; throw new RuntimeException(\"Did not expect thread to be interrupted\", e); &#125; &#125; public T get() &#123; if (latch.getCount() &gt; 0) &#123; throw new IllegalStateException(\"Call wait() and check its result\"); &#125; return resultHolder.get(); &#125; public void set(T result) &#123; resultHolder.set(result); latch.countDown(); &#125;&#125; 关于CountDownLatch的介绍参考：Java并发学习之CountDownLatch实现原理及使用姿势 prof文件分析关于prof文件的分析，还要回到RefWatch.ensureGone()方法中：heapdumpListener.analyze( new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs, gcDurationMs, heapDumpDurationMs)); 最终会调用到HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);// 在HeapAnalyzerService 中public static void runAnalysis(Context context, HeapDump heapDump, Class&lt;? extends AbstractAnalysisResultService&gt; listenerServiceClass) &#123; Intent intent = new Intent(context, HeapAnalyzerService.class); intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName()); intent.putExtra(HEAPDUMP_EXTRA, heapDump); context.startService(intent);&#125; HeapAnalyzerService继承自IntentService。在前面的AndroidManifest中可以看到，HeapAnalyzerService是运行在单独的进程中。 在HeapAnalyzerService的onHandleIntent方法中接收和处理传递过来的dump文件。@Override protected void onHandleIntent(Intent intent) &#123; if (intent == null) &#123; CanaryLog.d(\"HeapAnalyzerService received a null intent, ignoring.\"); return; &#125; String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA); HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA); HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs); AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey); // 调用另一个AbstractAnalysisResultService的静态方法，将结果返回 AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);&#125; 再看下在heapAnalyzer.checkForLeak()方法：public AnalysisResult checkForLeak(File heapDumpFile, String referenceKey) &#123; long analysisStartNanoTime = System.nanoTime(); if (!heapDumpFile.exists()) &#123; Exception exception = new IllegalArgumentException(\"File does not exist: \" + heapDumpFile); return failure(exception, since(analysisStartNanoTime)); &#125; try &#123; // 使用HAHA库 HprofBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile); HprofParser parser = new HprofParser(buffer); Snapshot snapshot = parser.parse(); // 这里使用了THashMap，去掉重复路径 deduplicateGcRoots(snapshot); // 根据引用key找到泄漏对象 Instance leakingRef = findLeakingReference(referenceKey, snapshot); // False alarm, weak reference was cleared in between key check and heap dump. if (leakingRef == null) &#123; return noLeak(since(analysisStartNanoTime)); &#125; // 返回一个AnalysisResult对象 return findLeakTrace(analysisStartNanoTime, snapshot, leakingRef); &#125; catch (Throwable e) &#123; return failure(e, since(analysisStartNanoTime)); &#125;&#125; 在heapAnalyzer.checkForLeak()方法中引入HAHA库(一个heap prof堆文件分析库)，将hprof文件解析成内存快照Snapshot对象进行分析。还使用jetBrains的THashMap(THashMap的内存占用量比HashMap小)做中转，去掉snapshot中GCRoot的重复路径，以减少内存压力。 返回分析结果在HeapAnalyzerService的onHandleIntent方法中，调用了AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);// 在AbstractAnalysisResultService 中public static void sendResultToListener(Context context, String listenerServiceClassName, HeapDump heapDump, AnalysisResult result) &#123; Class&lt;?&gt; listenerServiceClass; try &#123; listenerServiceClass = Class.forName(listenerServiceClassName); &#125; catch (ClassNotFoundException e) &#123; throw new RuntimeException(e); &#125; Intent intent = new Intent(context, listenerServiceClass); intent.putExtra(HEAP_DUMP_EXTRA, heapDump); intent.putExtra(RESULT_EXTRA, result); context.startService(intent);&#125; 启动DisplayLeakService，并将结果返回。DisplayLeakService运行在主线程，继承自AbstractAnalysisResultService，也是一个IntentService。在AbstractAnalysisResultService的onHandleIntent()接收结果，并回调onHeapAnalyzed()方法，创建并显示一个通知。 具体的结果分析和处理，可以看这篇文章：LeakCanary源码分析第三讲－HeapAnalyzerService详解 内存泄漏信息保存和分析的大概流程是： 通过Debug.dumpHprofData()，生成一个xxx_pending.hprof文件 使用HAHA库（github.com/square/haha），将hprof文件解析成内存快照Snapshot对象进行分析 使用jetBrains的THashMap做中转，去掉snapshot中GCRoot的重复路径，以减少内存压力。 找出泄露对象并找出泄露对象的最短路径 得到结果后，重命名xxx_pending.hprof 文件为yyyy-MM-dd_HH-mm-ss_SSS.hprof 将hprof文件内容和分析结果都保存到yyyy-MM-dd_HH-mm-ss_SSS.hprof.result文件中 以上就是整个LeakCanary捕获内存泄漏，并展示出来的整体流程。 学习借鉴 使用FutureResult同步主线程和子线程 使用CopyOnWriteArraySet解决并发读写问题 构建者模式，代码简洁、清新，链式调用创建对象，参考RefWatcherBuilder对象 MessageQueue.addIdleHandler(IdleHandler handler)，监听线程空闲 手动GC，参考GCTrigger.runGc()。 IntentService跨进程 Refhttps://www.jianshu.com/p/49239eac7a76 https://juejin.im/post/5d09fb7e5188252af2012e73 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/07/30/LeakCanary_source_code/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"LeakCanary","slug":"leakcanary","permalink":"http://agehua.github.io/tags/leakcanary/"}]},{"title":"RecyclerView预加载机制源码分析","slug":"RecyclerView-pre-initiate","date":"2019-07-16T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2019/07/17/RecyclerView-pre-initiate/","link":"","permalink":"http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/","excerpt":"RecyclerView四级缓存再次总结一下 RecyclerView 的四级缓存\n\nScrap\nCache\nViewCacheExtension\nRecycledViewPool","text":"RecyclerView四级缓存再次总结一下 RecyclerView 的四级缓存 Scrap Cache ViewCacheExtension RecycledViewPool Scrap: 对应ListView 的Active View，就是屏幕内的缓存数据，就是相当于换了个名字，可以直接拿来复用。 Cache: 刚刚移出屏幕的缓存数据，默认大小是2个，当其容量被充满同时又有新的数据添加的时候，会根据FIFO原则，把优先进入的缓存数据移出并放到下一级缓存中，然后再把新的数据添加进来。Cache里面的数据是干净的，也就是携带了原来的ViewHolder的所有数据信息，数据可以直接来拿来复用。需要注意的是，cache是根据position来寻找数据的，这个postion是根据第一个或者最后一个可见的item的position以及用户操作行为（上拉还是下拉）。举个栗子：当前屏幕内第一个可见的item的position是1，用户进行了一个下拉操作，那么当前预测的position就相当于（1-1=0），也就是position=0的那个item要被拉回到屏幕，此时RecyclerView就从Cache里面找position=0的数据，如果找到了就直接拿来复用。 ViewCacheExtension: 是google留给开发者自己来自定义缓存的，这个ViewCacheExtension我个人建议还是要慎用，因为我扒拉扒拉网上其他的博客，没有找到对应的使用场景，而且这个类的api设计的也有些奇怪，只有一个public abstract View getViewForPositionAndType(@NonNull Recycler recycler, int position, int type);让开发者重写通过position和type拿到ViewHolder的方法，却没有提供如何产生ViewHolder或者管理ViewHolder的方法，给人一种只出不进的赶脚，还是那句话慎用。 RecycledViewPool: 刚才说了Cache默认的缓存数量是2个，当Cache缓存满了以后会根据FIFO（先进先出）的规则把Cache先缓存进去的ViewHolder移出并缓存到RecycledViewPool中，RecycledViewPool默认的缓存数量是5个。RecycledViewPool与Cache相比不同的是，从Cache里面移出的ViewHolder再存入RecycledViewPool之前ViewHolder的数据会被全部重置，相当于一个新的ViewHolder，而且Cache是根据position来获取ViewHolder，而RecycledViewPool是根据itemType获取的，如果没有重写getItemType()方法，itemType就是默认的。因为RecycledViewPool缓存的ViewHolder是全新的，所以取出来的时候需要走onBindViewHolder()方法。 ref让你彻底掌握RecyclerView的缓存机制 Prefetch功能的使用google官方在 Support Library v25 版本中，为RecyclerView增加了Prefetch。 并且在 v25.1.0 以及25.3.0版本中进行了完善。在最新的稳定版本25.3.1中已经基本稳定。Prefetch 默认就是处理开启的状态，通过LinearLayoutManager的setItemPrefetchEnabled()我们可以手动控制该功能的开启关闭。 我们都知道android是通过每16ms刷新一次页面来保证ui的流畅程度，现在android系统中刷新ui会通过cpu产生数据，然后交给gpu渲染的形式来完成，从上图可以看出当cpu完成数据处理交给gpu后就一直处于空闲状态，需要等待下一帧才会进行数据处理，而这空闲时间就被白白浪费了，如何才能压榨cpu的性能，让它一直处于忙碌状态，这就是rv的预取功能(Prefetch)要做的事情，rv会预取接下来可能要显示的item，在下一帧到来之前提前处理完数据，然后将得到的itemholder缓存起来，等到真正要使用的时候直接从缓存取出来即可。 预取代码理解虽说预取是默认开启不需要我们开发者操心的事情，但是明白原理还是能加深该功能的理解。下面就说下自己在看预取源码时的一点理解。实现预取功能的一个关键类就是gapworker，可以直接在rv源码中找到该类GapWorker mGapWorker; rv通过在ontouchevent中触发预取的判断逻辑，在手指执行move操作的代码末尾有这么段代码case MotionEvent.ACTION_MOVE: &#123; ...... if (mGapWorker != null &amp;&amp; (dx != 0 || dy != 0)) &#123; mGapWorker.postFromTraversal(this, dx, dy); &#125; &#125; &#125; break; 通过每次move操作来判断是否预取下一个可能要显示的item数据，判断的依据就是通过传入的dx和dy得到手指接下来可能要移动的方向，如果dx或者dy的偏移量会导致下一个item要被显示出来则预取出来，但是并不是说预取下一个可能要显示的item一定都是成功的，其实每次rv取出要显示的一个item本质上就是取出一个viewholder，根据viewholder上关联的itemview来展示这个item。而取出viewholder最核心的方法就是tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) 名字是不是有点长，在rv源码中你会时不时见到这种巨长的方法名，看方法的参数也能找到和预取有关的信息,deadlineNs的一般取值有两种，一种是为了兼容版本25之前没有预取机制的情况，兼容25之前的参数为static final long FOREVER_NS = Long.MAX_VALUE; ，另一种就是实际的deadline数值，超过这个deadline则表示预取失败，这个其实也好理解，预取机制的主要目的就是提高rv整体滑动的流畅性，如果要预取的viewholder会造成下一帧显示卡顿强行预取的话那就有点本末倒置了。关于预取成功的条件通过调用boolean willCreateInTime(int viewType, long approxCurrentNs, long deadlineNs) &#123; long expectedDurationNs = getScrapDataForType(viewType).mCreateRunningAverageNs; return expectedDurationNs == 0 || (approxCurrentNs + expectedDurationNs &lt; deadlineNs);&#125; 来进行判断，approxCurrentNs的值为long start = getNanoTime();if (deadlineNs != FOREVER_NS &amp;&amp; !mRecyclerPool.willCreateInTime(type, start, deadlineNs)) &#123; // abort - we have a deadline we can't meet return null;&#125; 而mCreateRunningAverageNs就是创建同type的holder的平均时间，感兴趣的可以去看下这个值如何得到，不难理解就不贴代码了。关于预取就说到这里，感兴趣的可以自己去看下其余代码的实现方式，可以说google对于rv还是相当重视的，煞费苦心提高rv的各种性能，据说最近推出的viewpager2控件就是通过rv来实现的，大有rv控件一统天下的感觉。 预取功能的应用预取功能是默认开启的，在对应的RecyclerView.LayoutManager中提供了一个setInitialPrefetchItemCount(int itemCount)来设置预取个数。有一种场景，比如你在垂直列表里面有一个水平滚动列表的时候，竖屏每一行都是展示三个半item，可以调用内部（横向）Recyclerview的 innerLLM.setInitialItemsPrefetchCount(4)，这样当水平列表将要展示在屏幕上的时候，如果UI线程有空闲时间，RecyclerView会尝试在内部预先把这几个item取出来。 RefRecyclerView预加载机制源码分析 :https://blog.csdn.net/weishenhong/article/details/81150172 https://www.jianshu.com/p/1d2213f303fc 延伸阅读Recyclerview缓存RecyclerView 源码分析(三) - RecyclerView的缓存机制【进阶】RecyclerView源码解析(三)——深度解析缓存机制 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"RecyclerView 源码分析","slug":"RecyclerView-source-code","date":"2019-05-30T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/05/31/RecyclerView-source-code/","link":"","permalink":"http://agehua.github.io/2019/05/31/RecyclerView-source-code/","excerpt":"\n本文承接上文《RecyclerView 中的设计模式》，结合源码分析Recyclerview绘制、滑动、和缓存等逻辑\n","text":"本文承接上文《RecyclerView 中的设计模式》，结合源码分析Recyclerview绘制、滑动、和缓存等逻辑 RecyclerView的代码设计结构，如下面两张图： RecyclerViewDataObserver 数据观察器 Recycler View循环复用系统，核心部件 SavedState RecyclerView状态 AdapterHelper 适配器更新 ChildHelper 管理子View ViewInfoStore 存储子VIEW的动画信息 Adapter 数据适配器 LayoutManager 负责子VIEW的布局，核心部件 ItemAnimator Item动画 ViewFlinger 快速滑动管理 NestedScrollingChildHelper 管理子VIEW嵌套滑动 绘制详情可见RecyclerView涉及的类相当多，所以看代码的时候很容易迷失。因此我们需要抽丝剥茧，按照主线来进行分析。一般我们使用的时候是这样的 recyclerView = (RecyclerView) findViewById(R.id.recyclerView); LinearLayoutManager layoutManager = new LinearLayoutManager(this); //设置布局管理器 recyclerView.setLayoutManager(layoutManager); //设置为垂直布局，这也是默认的 layoutManager.setOrientation(OrientationHelper. VERTICAL); //设置Adapter recyclerView.setAdapter( recycleAdapter); //设置分隔线 recyclerView.addItemDecoration( new DividerGridItemDecoration(this )); //设置增加或删除条目的动画 recyclerView.setItemAnimator( new DefaultItemAnimator()); 首先recyclerView = (RecyclerView) findViewById(R.id.recyclerView);会执行其构造方法,我们看一下干了些什么事: public RecyclerView(Context context, @Nullable AttributeSet attrs, int defStyle) &#123; super(context, attrs, defStyle); setScrollContainer(true); setFocusableInTouchMode(true); final int version = Build.VERSION.SDK_INT; mPostUpdatesOnAnimation = version &gt;= 16; final ViewConfiguration vc = ViewConfiguration.get(context); mTouchSlop = vc.getScaledTouchSlop(); mMinFlingVelocity = vc.getScaledMinimumFlingVelocity(); mMaxFlingVelocity = vc.getScaledMaximumFlingVelocity(); setWillNotDraw(ViewCompat.getOverScrollMode(this) == ViewCompat.OVER_SCROLL_NEVER); mItemAnimator.setListener(mItemAnimatorListener); initAdapterManager(); initChildrenHelper(); // If not explicitly specified this view is important for accessibility. if (ViewCompat.getImportantForAccessibility(this) == ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_AUTO) &#123; ViewCompat.setImportantForAccessibility(this, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_YES); &#125; mAccessibilityManager = (AccessibilityManager) getContext() .getSystemService(Context.ACCESSIBILITY_SERVICE); setAccessibilityDelegateCompat(new RecyclerViewAccessibilityDelegate(this)); // Create the layoutManager if specified. boolean nestedScrollingEnabled = true; if (attrs != null) &#123; int defStyleRes = 0; //获取布局属性值 TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.RecyclerView, defStyle, defStyleRes); String layoutManagerName = a.getString(R.styleable.RecyclerView_layoutManager); a.recycle(); createLayoutManager(context, layoutManagerName, attrs, defStyle, defStyleRes); if (Build.VERSION.SDK_INT &gt;= 21) &#123; a = context.obtainStyledAttributes(attrs, NESTED_SCROLLING_ATTRS, defStyle, defStyleRes); nestedScrollingEnabled = a.getBoolean(0, true); a.recycle(); &#125; &#125; // Re-set whether nested scrolling is enabled so that it is set on all API levels setNestedScrollingEnabled(nestedScrollingEnabled);&#125; 代码进行了一系列的初始化工作,关键是createLayoutManager,创建了一个布局管理器 private void createLayoutManager(Context context, String className, AttributeSet attrs, int defStyleAttr, int defStyleRes) &#123; //如果布局属性存在 if (className != null) &#123; className = className.trim(); if (className.length() != 0) &#123; // Can't use isEmpty since it was added in API 9. className = getFullClassName(context, className); try &#123; ClassLoader classLoader; if (isInEditMode()) &#123; // Stupid layoutlib cannot handle simple class loaders. classLoader = this.getClass().getClassLoader(); &#125; else &#123; classLoader = context.getClassLoader(); &#125; //根据布局属性值设置的layoutManager通过反射实例化layoutManager Class layoutManagerClass = classLoader.loadClass(className).asSubclass(LayoutManager.class); Constructor constructor; Object[] constructorArgs = null; try &#123; constructor = layoutManagerClass .getConstructor(LAYOUT_MANAGER_CONSTRUCTOR_SIGNATURE); constructorArgs = new Object[]&#123;context, attrs, defStyleAttr, defStyleRes&#125;; &#125; catch (NoSuchMethodException e) &#123; try &#123; constructor = layoutManagerClass.getConstructor(); &#125; catch (NoSuchMethodException e1) &#123; e1.initCause(e); throw new IllegalStateException(attrs.getPositionDescription() + \": Error creating LayoutManager \" + className, e1); &#125; &#125; constructor.setAccessible(true); setLayoutManager(constructor.newInstance(constructorArgs)); &#125; catch (ClassNotFoundException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Unable to find LayoutManager \" + className, e); &#125; catch (InvocationTargetException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Could not instantiate the LayoutManager: \" + className, e); &#125; catch (InstantiationException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Could not instantiate the LayoutManager: \" + className, e); &#125; catch (IllegalAccessException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Cannot access non-public constructor \" + className, e); &#125; catch (ClassCastException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Class is not a LayoutManager \" + className, e); &#125; &#125; &#125;&#125; 如果在布局文件里面设置了布局管理器的类型，那么这里会通过反射的方式实例化出对应的布局管理器。最后将实例化出的布局管理器设置到当前的RecyclerView,参考文章在创建实例时候public void setLayoutManager(LayoutManager layout) &#123; if (layout == mLayout) &#123; return; &#125; stopScroll(); // TODO We should do this switch a dispachLayout pass and animate children. There is a good // chance that LayoutManagers will re-use views. if (mLayout != null) &#123; if (mIsAttached) &#123; mLayout.dispatchDetachedFromWindow(this, mRecycler); &#125; mLayout.setRecyclerView(null); &#125; mRecycler.clear(); mChildHelper.removeAllViewsUnfiltered(); mLayout = layout; if (layout != null) &#123; if (layout.mRecyclerView != null) &#123; throw new IllegalArgumentException(\"LayoutManager \" + layout + \" is already attached to a RecyclerView: \" + layout.mRecyclerView); &#125; mLayout.setRecyclerView(this); if (mIsAttached) &#123; mLayout.dispatchAttachedToWindow(this); &#125; &#125; requestLayout();&#125; 设置布局管理器之前会先清空所有之前的缓存VIEW。最后通知VIEW刷新,requestLayout可见要绘制了public void requestLayout() &#123; if (mMeasureCache != null) mMeasureCache.clear(); if (mAttachInfo != null &amp;&amp; mAttachInfo.mViewRequestingLayout == null) &#123; // Only trigger request-during-layout logic if this is the view requesting it, // not the views in its parent hierarchy ViewRootImpl viewRoot = getViewRootImpl(); if (viewRoot != null &amp;&amp; viewRoot.isInLayout()) &#123; if (!viewRoot.requestLayoutDuringLayout(this)) &#123; return; &#125; &#125; mAttachInfo.mViewRequestingLayout = this; &#125; //为当前view设置标记位 PFLAG_FORCE_LAYOUT mPrivateFlags |= PFLAG_FORCE_LAYOUT; mPrivateFlags |= PFLAG_INVALIDATED; if (mParent != null &amp;&amp; !mParent.isLayoutRequested()) &#123; //向父容器请求布局 mParent.requestLayout(); &#125; if (mAttachInfo != null &amp;&amp; mAttachInfo.mViewRequestingLayout == this) &#123; mAttachInfo.mViewRequestingLayout = null; &#125;&#125; 在requestLayout方法中，首先先判断当前View树是否正在布局流程，接着为当前子View设置标记位，该标记位的作用就是标记了当前的View是需要进行重新布局的，接着调用mParent.requestLayout方法，这个十分重要，因为这里是向父容器请求布局，即调用父容器的requestLayout方法，为父容器添加PFLAG_FORCE_LAYOUT标记位，而父容器又会调用它的父容器的requestLayout方法，即requestLayout事件层层向上传递，直到DecorView，即根View，而根View又会传递给ViewRootImpl，也即是说子View的requestLayout事件，最终会被ViewRootImpl接收并得到处理。纵观这个向上传递的流程，其实是采用了责任链模式，即不断向上传递该事件，直到找到能处理该事件的上级，在这里，只有ViewRootImpl能够处理requestLayout事件。 @Overridepublic void requestLayout() &#123; if (!mHandlingLayoutInLayoutRequest) &#123; checkThread(); mLayoutRequested = true; scheduleTraversals(); &#125;&#125;void scheduleTraversals() &#123; if (!mTraversalScheduled) &#123; mTraversalScheduled = true; mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); if (!mUnbufferedInputDispatch) &#123; scheduleConsumeBatchedInput(); &#125; notifyRendererOfFramePending(); pokeDrawLockIfNeeded(); &#125;&#125;final class TraversalRunnable implements Runnable &#123; @Override public void run() &#123; doTraversal(); &#125;&#125;void doTraversal() &#123; if (mTraversalScheduled) &#123; mTraversalScheduled = false; mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier); if (mProfile) &#123; Debug.startMethodTracing(\"ViewAncestor\"); &#125; performTraversals(); if (mProfile) &#123; Debug.stopMethodTracing(); mProfile = false; &#125; &#125;&#125; 在这里，调用了scheduleTraversals方法，这个方法是一个异步方法，最终会调用到ViewRootImpl#performTraversals方法，这也是View工作流程的核心方法，在这个方法内部，分别调用measure、layout、draw方法来进行View的三大工作流程private void performTraversals() &#123; ... if (!mStopped) &#123; int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width); // 1 int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height); performMeasure(childWidthMeasureSpec, childHeightMeasureSpec); &#125; &#125; if (didLayout) &#123; performLayout(lp, desiredWindowWidth, desiredWindowHeight); ... &#125; if (!cancelDraw &amp;&amp; !newSurface) &#123; if (!skipDraw || mReportNextDraw) &#123; if (mPendingTransitions != null &amp;&amp; mPendingTransitions.size() &gt; 0) &#123; for (int i = 0; i &lt; mPendingTransitions.size(); ++i) &#123; mPendingTransitions.get(i).startChangingAnimations(); &#125; mPendingTransitions.clear(); &#125; performDraw(); &#125; &#125; ...&#125; 这里很熟悉了吧,view,viewgroup的绘制,如果这里有问题的,自己百度吧,所以会最终调用到recyclerview的onMeature recyclerView.setLayoutManager(layoutManager)就是桥接模式的体现，因为layoutManager的实现可以有多种,即桥接模式具体实现化逻辑ConcreteImplementor ListView功能 recyclerView.setLayoutManager(new LinearLayoutManager(this)); GridView功能 recyclerView.setLayoutManager(new GridLayoutManager(this,3)); 瀑布流形式功能 recyclerView.setLayoutManager(new StaggeredGridLayoutManager(2,StaggeredGridLayoutManager.VERTICAL)); 横向ListView的功能 recyclerView.setLayoutManager(new LinearLayoutManager(this)); layoutManager.setOrientation(…); public LinearLayoutManager(Context context, int orientation, boolean reverseLayout) &#123; setOrientation(orientation); setReverseLayout(reverseLayout); setAutoMeasureEnabled(true);&#125;public StaggeredGridLayoutManager(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) &#123; Properties properties = getProperties(context, attrs, defStyleAttr, defStyleRes); setOrientation(properties.orientation); setSpanCount(properties.spanCount); setReverseLayout(properties.reverseLayout); setAutoMeasureEnabled(mGapStrategy != GAP_HANDLING_NONE); mLayoutState = new LayoutState(); createOrientationHelpers();&#125; GridLayoutManager继承LinearLayoutManager 可见其初始化时候会设置AutoMeasurEnabled,前面说过，RecyclerView会将测量与布局交给LayoutManager来做，并且LayoutManager有一个叫做mAutoMeasure的属性，这个属性用来控制LayoutManager是否开启自动测量，开启自动测量的话布局就交由RecyclerView使用一套默认的测量机制，否则，自定义的LayoutManager需要重写onMeasure来处理自身的测量工作。RecyclerView目前提供的几种LayoutManager都开启了自动测量，所以这里我们关注一下自动测量部分的逻辑： protected void onMeasure(int widthSpec, int heightSpec) &#123; ... if (mLayout.mAutoMeasure) &#123; final int widthMode = MeasureSpec.getMode(widthSpec); final int heightMode = MeasureSpec.getMode(heightSpec); final boolean skipMeasure = widthMode == MeasureSpec.EXACTLY &amp;&amp; heightMode == MeasureSpec.EXACTLY; mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec); if (skipMeasure || mAdapter == null) &#123; return; &#125; if (mState.mLayoutStep == State.STEP_START) &#123; dispatchLayoutStep1(); &#125; mLayout.setMeasureSpecs(widthSpec, heightSpec); mState.mIsMeasuring = true; dispatchLayoutStep2(); mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec); if (mLayout.shouldMeasureTwice()) &#123; mLayout.setMeasureSpecs( MeasureSpec.makeMeasureSpec(getMeasuredWidth(), MeasureSpec.EXACTLY), MeasureSpec.makeMeasureSpec(getMeasuredHeight(), MeasureSpec.EXACTLY)); mState.mIsMeasuring = true; dispatchLayoutStep2(); mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec); &#125; &#125; ...&#125; 自动测量的原理如下:当RecyclerView的宽高都为EXACTLY时，可以直接设置对应的宽高，然后返回，结束测量。 补充MeasureSpect三种模式三种模式是EXACTLY,UNSPECIFIED,AT_MOST,分别代表精确大小,不精确大小,最大值;通过MeasureSpect.getMode就可以获得该值,那么MeasureSpect到底是由什么决定的呢?MeasureSpect是由LayoutParameter通过父容器的施加的规则产生的下面我们来看一看三种模式产生的情况. MeasureSpec.EXACTLY父容器已经精确的检测出了子View的大小,子view的大小就是MeasureSpect.getSize()的值.适用情况: a.子View的LayoutParameter使用具体的值(如:宽高为100dp),不管父容器的spectMode为什么,系统返回给子View的mode为EXACTLY,系统返回给子View的大小为子V诶额外自己指定的大小(100dp) b.子View的LayoutParams采用match_parent并且父容器的mode为EXACTLY,那么子View的mode即为EXACTLY,子View大小为父容器剩余的大小 MeasureSpec.AT_MOST父容器期望对子View的最大值做了限定适用情况: c.子View的LayoutParams采用match_parent并且父容器的mode为AT_MOST,那么子View的mode即为AT_MOST,子View大小为父容器剩余的大小 d.当子View的LayoutParams采用wrap_content时并且父容器的mode为EXACTLY或者AT_MOST时,子View的Mode就为AT_MOST，子View的specSize就为该父容器剩余的大小 MeasureSpec.UNSPECIFIED父容器不限定大小,子View想多大就多大适应情况: e.当子View的LayoutParams采用wrap_content时并且父容器的mode为UNSPECIFIED时,子View的Mode就为UNSPECIFIED，子View的大小不做限制 如果宽高的测量规则不是EXACTLY的,则会在onMeasure()中开始布局的处理，这里首先要介绍一个很重要的类： RecyclerView.State ，这个类封装了当前RecyclerView的有用信息。State的一个变量mLayoutStep表示了RecyclerView当前的布局状态，包括STEP_START、STEP_LAYOUT 、 STEP_ANIMATIONS三个，而RecyclerView的布局过程也分为三步，其中，STEP_START表示即将开始布局，需要调用dispatchLayoutStep1来执行第一步布局，接下来，布局状态变为STEP_LAYOUT，表示接下来需要调用dispatchLayoutStep2里进行第二步布局，同理，第二步布局后状态变为STEP_ANIMATIONS，需要执行第三步布局dispatchLayoutStep3。 这三个步骤的工作也各不相同，step1负责记录状态，step2负责布局，step3则与step1进行比较，根据变化来触发动画。 RecyclerView将布局划分的如此细致必然是有其原因的，在开启自动测量模式的情况，RecyclerView是支持WRAP_CONTENT属性的，比如我们可以很容易的在RecyclerView的下面放置其它的View，RecyclerView会根据子View所占大小动态调整自己的大小，这时候，RecyclerView就会将子控件的measure与layout提前到Recycler的onMeasure中，因为它需要确定子空间的大小与位置后，再来设置自己的大小。所以这时候就会在onMeasure中完成step1与step2。否则，就需要在onLayout中去完成整个布局过程。 综上，整个mLayout.mAutoMeasure就是在做前两步的布局，可见RecylerView的measure与layout是紧密相关的，所以我们来赶快瞧一瞧RecyclerView是如何layout的。 我们直接看下onLayout的代码：protected void onLayout(boolean changed, int l, int t, int r, int b) &#123; TraceCompat.beginSection(TRACE_ON_LAYOUT_TAG); dispatchLayout(); TraceCompat.endSection(); mFirstLayoutComplete = true;&#125; 直接追进dispatchLayout：void dispatchLayout() &#123; ... mState.mIsMeasuring = false; if (mState.mLayoutStep == State.STEP_START) &#123; dispatchLayoutStep1(); mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2(); &#125; else if (mAdapterHelper.hasUpdates() || mLayout.getWidth() != getWidth() ||mLayout.getHeight() != getHeight()) &#123; // First 2 steps are done in onMeasure but looks like we have to run again due to // changed size. mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2(); &#125; else &#123; // always make sure we sync them (to ensure mode is exact) mLayout.setExactMeasureSpecsFrom(this); &#125; dispatchLayoutStep3();&#125; 通过查看dispatchLayout的代码正好验证了我们前文关于RecyclerView的layout三步走原则，如果在onMeasure中已经完成了step1与step2，则只会执行step3，否则三步会依次触发。接下来我们一步一步的进行分析 dispatchLayoutStep1private void dispatchLayoutStep1()&#123; ... if (mState.mRunSimpleAnimations) &#123; int count = mChildHelper.getChildCount(); for (int i = 0; i &lt; count; ++i) &#123; final ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i)); final ItemHolderInfo animationInfo = mItemAnimator .recordPreLayoutInformation(mState, holder, ItemAnimator.buildAdapterChangeFlagsForAnimations(holder), holder.getUnmodifiedPayloads()); mViewInfoStore.addToPreLayout(holder, animationInfo); ... &#125; &#125; ... mState.mLayoutStep = State.STEP_LAYOUT;&#125;class ViewInfoStore &#123; private static final boolean DEBUG = false; @VisibleForTesting final ArrayMap mLayoutHolderMap = new ArrayMap&lt;&gt;(); @VisibleForTesting final LongSparseArray mOldChangedHolders = new LongSparseArray&lt;&gt;(); void clear() &#123; mLayoutHolderMap.clear(); mOldChangedHolders.clear(); &#125;&#125;public static class ItemHolderInfo &#123; public int left; public int top; public int right; public int bottom; @AdapterChanges public int changeFlags; public ItemHolderInfo() &#123; &#125;&#125; step的第一步目的就是在记录View的状态，首先遍历当前所有的View依次进行处理，mItemAnimator会根据每个View的信息封装成一个ItemHolderInfo，这个ItemHolderInfo中主要包含的就是当前View的位置状态等。然后ItemHolderInfo 就被存入mViewInfoStore中,由代码可见被存在ArrayMap和LongSparseArray中,其是对HashMap的android优化,是用两个数组来完成存储,arraymap的key可以是任意值,SparseArray的key只能为int,其核心是折半查找 注意这里调用的是mViewInfoStore的addToPreLayout方法，我们追进：void addToPreLayout(ViewHolder holder, ItemHolderInfo info) &#123; InfoRecord record = mLayoutHolderMap.get(holder); if (record == null) &#123; record = InfoRecord.obtain(); mLayoutHolderMap.put(holder, record); &#125; record.preInfo = info; record.flags |= FLAG_PRE;&#125; addToPreLayout方法中会根据holder来查询InfoRecord信息，如果没有，则生成，然后将info信息赋值给InfoRecord的preInfo变量。最后标记FLAG_PRE信息，如此，完成函数。所以纵观整个layout的第一步，就是在记录当前的View信息，因为进入第二步后，View的信息就将被改变了。我们来看第二步： dispatchLayoutStep2private void dispatchLayoutStep2() &#123; ... mLayout.onLayoutChildren(mRecycler, mState); ... mState.mLayoutStep = State.STEP_ANIMATIONS;&#125; layout的第二步主要就是真正的去布局View了，前面也说过，RecyclerView的布局是由LayoutManager负责的，所以第二步的主要工作也都在LayoutManager中，由于每种布局的方式不一样，这里我们以常见的LinearLayoutManager为例。我们看其onLayoutChildren方法： public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) &#123; ... if (!mAnchorInfo.mValid || mPendingScrollPosition != NO_POSITION || mPendingSavedState != null) &#123; updateAnchorInfoForLayout(recycler, state, mAnchorInfo); &#125; ... if (mAnchorInfo.mLayoutFromEnd) &#123; firstLayoutDirection = mShouldReverseLayout ? LayoutState.ITEM_DIRECTION_TAIL : LayoutState.ITEM_DIRECTION_HEAD; &#125; else &#123; firstLayoutDirection = mShouldReverseLayout ? LayoutState.ITEM_DIRECTION_HEAD : LayoutState.ITEM_DIRECTION_TAIL; &#125; ... onAnchorReady(recycler, state, mAnchorInfo, firstLayoutDirection); ... if (mAnchorInfo.mLayoutFromEnd) &#123; ... &#125; else &#123; // fill towards end updateLayoutStateToFillEnd(mAnchorInfo); fill(recycler, mLayoutState, state, false); ... // fill towards start updateLayoutStateToFillStart(mAnchorInfo); ... fill(recycler, mLayoutState, state, false); ... &#125; ...&#125; 整个onLayoutChildren过程还是很复杂的，这里我尽量省略了一些与流程关系不大的细节处理代码。整个onLayoutChildren过程可以大致整理如下： 找到anchor点 根据anchor一直向前布局，直至填充满anchor点前面的所有区域 根据anchor一直向后布局，直至填充满anchor点后面的所有区域这里我以垂直布局来说明，mAnchorInfo为布局锚点信息，包含了子控件在Y轴上起始绘制偏移量（coordinate），ItemView在Adapter中的索引位置（position）和布局方向（mLayoutFromEnd）——这里是指start、end方向。 这部分代码的功能就是：确定布局锚点，以此为起点向开始和结束方向填充ItemView，如图所示： anchor点的寻找是由updateAnchorInfoForLayout函数负责的：private void updateAnchorInfoForLayout(RecyclerView.Recycler recycler, RecyclerView.State state, AnchorInfo anchorInfo) &#123; ... if (updateAnchorFromChildren(recycler, state, anchorInfo)) &#123; return; &#125; ... anchorInfo.assignCoordinateFromPadding(); anchorInfo.mPosition = mStackFromEnd ? state.getItemCount() - 1 : 0;&#125; 函数内首先通过子view来获取anchor，如果没有获取到，就根据就取头/尾点来作为anchor。所以这里我们主要关注updateAnchorFromChildren函数： private boolean updateAnchorFromChildren(RecyclerView.Recycler recycler, RecyclerView.State state, AnchorInfo anchorInfo) &#123; if (getChildCount() == 0) &#123; return false; &#125; final View focused = getFocusedChild(); if (focused != null &amp;&amp; anchorInfo.isViewValidAsAnchor(focused, state)) &#123; anchorInfo.assignFromViewAndKeepVisibleRect(focused); return true; &#125; if (mLastStackFromEnd != mStackFromEnd) &#123; return false; &#125; View referenceChild = anchorInfo.mLayoutFromEnd ? findReferenceChildClosestToEnd(recycler, state) : findReferenceChildClosestToStart(recycler, state); if (referenceChild != null) &#123; anchorInfo.assignFromView(referenceChild); ... return true; &#125; return false;&#125; updateAnchorFromChildren内部做的事情也很容易理解，首先寻找被focus的child，找到的话以此child作为anchor，否则根据布局的方向寻找最合适的child来作为anchor，如果找到则将child的信息赋值给anchorInfo，其实anchorInfo主要记录的信息就是view的物理位置与在adapter中的位置。找到后返回true，否则返回false则交由上一步的函数做处理。 综上，刚刚的所追踪的代码都是在寻找anchor点。在我们寻找后，LinearLayoutManager还给了我们更改anchor的时机，就是 onAnchorReady 函数，我们可以继承LinearLayoutManager 来重写onAnchorReady方法，就可以实现某些特定的功能，比如进入RecyclerView时定位在某一项等等。 总之，我们现在找到了anchor信息，接下来就是根据anchor来布局了。无论从上到下还是从下到上布局，都调用的是fill方法，我们进入fill方法来查看一番：int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) &#123; final int start = layoutState.mAvailable; if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) &#123; recycleByLayoutState(recycler, layoutState); &#125; int remainingSpace = layoutState.mAvailable + layoutState.mExtra; LayoutChunkResult layoutChunkResult = mLayoutChunkResult; while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; layoutChunk(recycler, state, layoutState, layoutChunkResult); ... &#125; return start - layoutState.mAvailable;&#125; 这里同样省略了很多代码，我们关注重点： 首先比较重要的函数是recycleByLayoutState，这个函数就厉害了，它会根据当前信息对不需要的View进行回收： private void recycleByLayoutState(RecyclerView.Recycler recycler, LayoutState layoutState) &#123; if (layoutState.mLayoutDirection == LayoutState.LAYOUT_START) &#123; ... &#125; else &#123; recycleViewsFromStart(recycler, layoutState.mScrollingOffset); &#125;&#125; 我们继续追进recycleViewsFromStart：private void recycleViewsFromStart(RecyclerView.Recycler recycler, int dt) &#123; final int limit = dt; final int childCount = getChildCount(); if (mShouldReverseLayout) &#123; ... &#125; else &#123; for (int i = 0; i &lt; childCount; i++) &#123; View child = getChildAt(i); if (mOrientationHelper.getDecoratedEnd(child) &gt; limit || mOrientationHelper.getTransformedEndWithDecoration(child) &gt; limit) &#123; recycleChildren(recycler, 0, i); return; &#125; &#125; &#125;&#125; 这个函数的作用就是遍历所有的子View，找出逃离边界的View进行回收，回收函数我们锁定在recycleChildren里，而这个函数最后又会调到removeAndRecycleViewAt：public void removeAndRecycleViewAt(int index, Recycler recycler) &#123; final View view = getChildAt(index); removeViewAt(index); recycler.recycleView(view);&#125; 这个函数首先调用removeViewAt函数，这个函数的作用是将View从RecyclerView中移除， 紧接着我们看到，是recycler执行了view的回收逻辑。这里我们暂且打住，关于recycler我们会单独进行说明，这里我们只需要理解，在fill函数的一开始会去回收逃离出屏幕的view。我们再次回到fill函数，关注这里： while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; layoutChunk(recycler, state, layoutState, layoutChunkResult); ...&#125; 这段代码很容易理解，只要还有剩余空间，就会执行layoutChunk方法：void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state, LayoutState layoutState, LayoutChunkResult result) &#123; View view = layoutState.next(recycler); ... LayoutParams params = (LayoutParams) view.getLayoutParams(); if (layoutState.mScrapList == null) &#123; if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) &#123; addView(view); &#125; else &#123; addView(view, 0); &#125; &#125; else &#123; ... &#125; ... layoutDecoratedWithMargins(view, left, top, right, bottom); ...&#125; 我们首先看到，layoutState的next方法返回了一个View，凭空变出一个View，好神奇，追进去看一下：View next(RecyclerView.Recycler recycler) &#123; ... final View view = recycler.getViewForPosition(mCurrentPosition); return view;&#125; 可见，view的获取逻辑也由recycler来负责，所以，这里我们同样打住，只需要清楚recycler可以根据位置返回一个view即可。 再回到layoutChunk看一下对刚刚生成的view作何处理：if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) &#123; addView(view); &#125; else &#123; addView(view, 0);&#125; 很明显调用了addView方法，虽然这个方法是LayoutManager的，但这个方法最终会多次辗转调用到RecyclerView的addView方法，将view添加在RecyclerView中。综上，我们就梳理了整个第二步布局的过程，此过程完成了子View的测量与布局，任务还是相当繁重。 多说一点，这里的addView()，中间会调用的下面这个方法，这个方法会调用到 RecyclerView的onChildAttachedToWindow 和 mAdapter.onViewAttachedToWindow。通过这两个方法可以监听view或者viewholder显示的时机// RecyclerViewvoid dispatchChildAttached(View child) &#123; final ViewHolder viewHolder = getChildViewHolderInt(child); onChildAttachedToWindow(child); if (mAdapter != null &amp;&amp; viewHolder != null) &#123; mAdapter.onViewAttachedToWindow(viewHolder); &#125; if (mOnChildAttachStateListeners != null) &#123; final int cnt = mOnChildAttachStateListeners.size(); for (int i = cnt - 1; i &gt;= 0; i--) &#123; mOnChildAttachStateListeners.get(i).onChildViewAttachedToWindow(child); &#125; &#125; &#125; dispatchLayoutStep3接下来，就到了布局的最后一步了，我们直接看下dispatchLayoutStep3方法：private void dispatchLayoutStep3() &#123; mState.mLayoutStep = State.STEP_START; if (mState.mRunSimpleAnimations) &#123; for (int i = mChildHelper.getChildCount() - 1; i &gt;= 0; i--) &#123; ... final ItemHolderInfo animationInfo = mItemAnimator .recordPostLayoutInformation(mState, holder); mViewInfoStore.addToPostLayout(holder, animationInfo); &#125; mViewInfoStore.process(mViewInfoProcessCallback); &#125; ...&#125; 这一步是与第一步呼应的的，此时由于子View都已完成布局，所以子View的信息都发生了变化。我们会看到第一步出现的mViewInfoStore和mItemAnimator再次登场，这次mItemAnimator调用的是recordPostLayoutInformation方法，而mViewInfoStore调用的是addToPostLayout方法，还记得刚刚我强调的吗，之前是pre，也就是真正布局之前的状态，而现在要记录布局之后的状态，我们追进addToPostLayout：void addToPostLayout(ViewHolder holder, ItemHolderInfo info) &#123; InfoRecord record = mLayoutHolderMap.get(holder); if (record == null) &#123; record = InfoRecord.obtain(); mLayoutHolderMap.put(holder, record); &#125; record.postInfo = info; record.flags |= FLAG_POST;&#125; 和第一步的addToPreLayout类似，不过这次info信息被赋值给了record的postInfo变量，这样，一个record中就包含了布局前后view的状态。 最后，mViewInfoStore调用了process方法，这个方法就是根据mViewInfoStore中的View信息，来执行动画逻辑，这又是一个可以展看很多的点，这里不做探讨，感兴趣的可以深入的看一下，会对动画流程有更直观的体会。 接下来就是onDraw,RecyclerView的draw过程可以分为２部分来看：RecyclerView负责绘制所有decoration；ItemView的绘制由ViewGroup处理，这里的绘制是android常规绘制逻辑，本文就不再阐述了。下面来看看RecyclerView的draw()和onDraw()方法：@Overridepublic void draw(Canvas c) &#123; super.draw(c); final int count = mItemDecorations.size(); for (int i = 0; i &lt; count; i++) &#123; mItemDecorations.get(i).onDrawOver(c, this, mState); &#125; ...&#125;@Overridepublic void onDraw(Canvas c) &#123; super.onDraw(c); final int count = mItemDecorations.size(); for (int i = 0; i &lt; count; i++) &#123; mItemDecorations.get(i).onDraw(c, this, mState); &#125;&#125; 好了,测量,布局,绘制都大体讲了一下,回到我们开头,setLayoutManager已经完成。接下来是setAdapter(适配器模式),我们一起结合动画的实现(观察者模式)来解读,先看一下adapter类 setAdapter(适配器模式)public static abstract class Adapter &#123; private final AdapterDataObservable mObservable = new AdapterDataObservable(); public void registerAdapterDataObserver(AdapterDataObserver observer) &#123; mObservable.registerObserver(observer); &#125; public void unregisterAdapterDataObserver(AdapterDataObserver observer) &#123; mObservable.unregisterObserver(observer); &#125; public final void notifyItemInserted(int position) &#123; mObservable.notifyItemRangeInserted(position, 1); &#125;&#125; RecyclerView的Adapter，这个控件需要的是View(dst),而我们有的一般是datas(src),所以适配器Adapter就是完成了数据源datas 转化成 ItemView的工作。带入src-&gt;Adapter-&gt;dst中，即datas-&gt;Adapter-&gt;View. 通过public abstract void onBindViewHolder(VH holder, int position);将datas绑定到view然后返回ViewHolder我们可以看到Adapter中包含一个AdapterDataObservable的对象mObservable，这个是一个可观察者，在可观察者中可以注册一系列的观察者AdapterDataObserver。在我们调用的notify函数的时候，就是可观察者发出通知，这时已经注册的观察者都可以收到这个通知，然后依次进行处理。哈哈,是不是我们前面的Subject…那么我们看一下注册观察者的地方。 注册观察者的地方就是在RecyclerView的这个函数中。这个是setAdapter方法最终调用的地方。它主要做了： 如果之前存在Adapter，先移除原来的，注销观察者，和从RecyclerView Detached。然后根据参数，决定是否清除原来的ViewHolder然后重置AdapterHelper，并更新Adapter，注册观察者。public void setAdapter(Adapter adapter) &#123; // bail out if layout is frozen setLayoutFrozen(false); setAdapterInternal(adapter, false, true); requestLayout();&#125; 看一看setAdapterInternalprivate void setAdapterInternal(Adapter adapter, boolean compatibleWithPrevious, boolean removeAndRecycleViews) &#123; if (mAdapter != null) &#123; mAdapter.unregisterAdapterDataObserver(mObserver); mAdapter.onDetachedFromRecyclerView(this); &#125; if (!compatibleWithPrevious || removeAndRecycleViews) &#123; // end all running animations if (mItemAnimator != null) &#123; mItemAnimator.endAnimations(); &#125; // Since animations are ended, mLayout.children should be equal to // recyclerView.children. This may not be true if item animator's end does not work as // expected. (e.g. not release children instantly). It is safer to use mLayout's child // count. if (mLayout != null) &#123; mLayout.removeAndRecycleAllViews(mRecycler); mLayout.removeAndRecycleScrapInt(mRecycler); &#125; // we should clear it here before adapters are swapped to ensure correct callbacks. mRecycler.clear(); &#125; mAdapterHelper.reset(); final Adapter oldAdapter = mAdapter; mAdapter = adapter; if (adapter != null) &#123; adapter.registerAdapterDataObserver(mObserver); adapter.onAttachedToRecyclerView(this); &#125; if (mLayout != null) &#123; mLayout.onAdapterChanged(oldAdapter, mAdapter); &#125; mRecycler.onAdapterChanged(oldAdapter, mAdapter, compatibleWithPrevious); mState.mStructureChanged = true; markKnownViewsInvalid();&#125; 从这里我们可以看出，mObserver这个成员变量就是注册的观察者，那么我们去看看这个成员变量的内容。 该成员变量是一个RecyclerViewDataObserver的实例，那么RecyclerViewDataObserver实现了AdapterDataObserver中的方法。其中onItemRangeInserted(int positionStart, int itemCount)就是观察者接受到有数据插入通知的方法。那么我们来分析这个方法。看注释。private final RecyclerViewDataObserver mObserver = new RecyclerViewDataObserver();private class RecyclerViewDataObserver extends AdapterDataObserver &#123; ... mPostUpdatesOnAnimation = version &gt;= 16; @Override public void onItemRangeInserted(int positionStart, int itemCount) &#123; // 1) 断言不在布局或者滚动过程中，其实就是如果在布局或者滚动过程中，则不会执 // 行下面的内容 assertNotInLayoutOrScroll(null); // 2) 这里小型，不要小看if括号中的内容，这是关键。我们去看看这个方法的实现。 // 见下面注释 3)，在 3) 返回true之后执行triggerUpdateProcessor方法， // triggerUpdateProcessor方法分析请看注释 4)。 if (mAdapterHelper.onItemRangeInserted(positionStart, itemCount)) &#123; triggerUpdateProcessor(); &#125; &#125;&#125; AdapterHelper中onItemRangeInserted函数即相关内容，请看注释 3)。class AdapterHelper implements OpReorderer.Callback &#123; // 一个待处理更新操作的列表，该列表中存放所有等待处理的操作信息。 final ArrayList mPendingUpdates = new ArrayList(); // 3) 该方法将插入操作的信息存储到一个UpdateOp中，并添加到待处理更新操作列表中， // 如果操作列表中的值是1，就返回真表示需要处理操作，等于1的判断避免重复触发处理操作。 // obtainUpdateOp内部是通过池来得到一个UpdateOp对象。那么下面回去看我们注释 4)。 boolean onItemRangeInserted(int positionStart, int itemCount) &#123; if (itemCount &lt; 1) &#123; return false; &#125; mPendingUpdates.add(obtainUpdateOp(UpdateOp.ADD, positionStart, itemCount, null)); mExistingUpdateTypes |= UpdateOp.ADD; return mPendingUpdates.size() == 1; &#125;&#125;// 4) 触发更新处理操作，分为两种情况，在 版本大于16 且 已经Attach 并且 设置了大小固定 的情况下，// 进行mUpdateChildViewsRunnable中的操作。否则请求布局。void triggerUpdateProcessor() &#123; if (mPostUpdatesOnAnimation &amp;&amp; mHasFixedSize &amp;&amp; mIsAttached) &#123; ViewCompat.postOnAnimation(RecyclerView.this, mUpdateChildViewsRunnable); &#125; else &#123; mAdapterUpdateDuringMeasure = true; requestLayout(); &#125;&#125;// 5) 其中核心代码是consumePendingUpdateOperations()那么继续往下看。private final Runnable mUpdateChildViewsRunnable = new Runnable() &#123; public void run() &#123; ... consumePendingUpdateOperations(); &#125;&#125;;private void consumePendingUpdateOperations() &#123; ... if (mAdapterHelper.hasAnyUpdateTypes(UpdateOp.UPDATE) &amp;&amp; !mAdapterHelper .hasAnyUpdateTypes(UpdateOp.ADD | UpdateOp.REMOVE | UpdateOp.MOVE)) &#123; // 6) 如果只有更新类型的操作(这里指内容的更新，不影响View位置的改变)的情况下， // 先进行预处理，然后在没有View更新的情况下消耗延迟的更新操作，否则调用 // dispatchLayout方法对RecyclerView中的View重新布局。那么接下来分析 // preProcess()方法。 mAdapterHelper.preProcess(); if (!mLayoutRequestEaten) &#123; if (hasUpdatedView()) &#123; dispatchLayout(); &#125; else &#123; mAdapterHelper.consumePostponedUpdates(); &#125; &#125; resumeRequestLayout(true); &#125; else if (mAdapterHelper.hasPendingUpdates()) &#123; // 7) 在既有更新操作又有添加或者删除或者移动中任意一个的情况下，调用 // dispatchLayout方法对RecyclerView中的View重新布局 dispatchLayout(); &#125;&#125;// 8) 预处理做了以下几件事情，&lt;1&gt; 先将待处理操作重排。&lt;2&gt; 应用所有操作 &lt;3&gt; 清空待处理操作列表，// 以ADD为例分析流程。void preProcess() &#123; mOpReorderer.reorderOps(mPendingUpdates); final int count = mPendingUpdates.size(); for (int i = 0; i &lt; count; i++) &#123; UpdateOp op = mPendingUpdates.get(i); switch (op.cmd) &#123; case UpdateOp.ADD: applyAdd(op); break; case UpdateOp.REMOVE: applyRemove(op); break; case UpdateOp.UPDATE: applyUpdate(op); break; case UpdateOp.MOVE: applyMove(op); break; &#125; if (mOnItemProcessedCallback != null) &#123; mOnItemProcessedCallback.run(); &#125; &#125; mPendingUpdates.clear();&#125;// 9) 直接看postponeAndUpdateViewHoldersprivate void applyAdd(UpdateOp op) &#123; postponeAndUpdateViewHolders(op);&#125;// 10) 先将操作添加到推迟的操作列表中。然后将操作的内容交给回调处理。private void postponeAndUpdateViewHolders(UpdateOp op) &#123; mPostponedList.add(op); switch (op.cmd) &#123; case UpdateOp.ADD: mCallback.offsetPositionsForAdd(op.positionStart, op.itemCount); break; case UpdateOp.MOVE: mCallback.offsetPositionsForMove(op.positionStart, op.itemCount); break; case UpdateOp.REMOVE: mCallback.offsetPositionsForRemovingLaidOutOrNewView(op.positionStart, op.itemCount); break; case UpdateOp.UPDATE: mCallback.markViewHoldersUpdated(op.positionStart, op.itemCount, op.payload); break; default: throw new IllegalArgumentException(\"Unknown update op type for \" + op); &#125;&#125;// 11) 直接看offsetPositionRecordsForInsert@Overridepublic void offsetPositionsForAdd(int positionStart, int itemCount) &#123; offsetPositionRecordsForInsert(positionStart, itemCount); mItemsAddedOrRemoved = true;&#125;// 12) 该方法主要是便利所有的ViewHolder，然后把在插入位置之后的ViewHolder的位置// 向后移动插入的个数，最后在对Recycler中缓存的ViewHolder做同样的操作，最后申请重新布局。void offsetPositionRecordsForInsert(int positionStart, int itemCount) &#123; final int childCount = mChildHelper.getUnfilteredChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; final ViewHolder holder = getChildViewHolderInt(mChildHelper.getUnfilteredChildAt(i)); if (holder != null &amp;&amp; !holder.shouldIgnore() &amp;&amp; holder.mPosition &gt;= positionStart) &#123; holder.offsetPosition(itemCount, false); mState.mStructureChanged = true; &#125; &#125; mRecycler.offsetPositionRecordsForInsert(positionStart, itemCount); requestLayout();&#125; 前面讲过ViewInfoStore这个类是用来追踪View所要做的动画的。其中有一个内部类InfoRecord，该类用来存储ViewHolder前后的信息，以及ViewHolder状态的flag。其中还有一个非常重要的方法，process，该方法会处理所有的mLayoutHolderMap中的值，并根据其flag和前后的信息来判断ViewHolder的动作，并将这个动作反应给ProcessCallback。分别有4种行为：消失，出现，一直存在，为使用。然后交给外面去处理。 前面说过 dispatchLayoutStep3mViewInfoStore.process(mViewInfoProcessCallback);,之后我们看一下mViewInfoStore的ProcessCallback的实现mViewInfoProcessCallback，这里只拿processAppeared做分析：private final ViewInfoStore.ProcessCallback mViewInfoProcessCallback = new ViewInfoStore.ProcessCallback() &#123; ... @Override public void processAppeared(ViewHolder viewHolder, ItemHolderInfo preInfo, ItemHolderInfo info) &#123; animateAppearance(viewHolder, preInfo, info); &#125; ...&#125;; 然后看一下animateAppearance方法：private void animateAppearance(@NonNull ViewHolder itemHolder, @Nullable ItemHolderInfo preLayoutInfo, @NonNull ItemHolderInfo postLayoutInfo) &#123; itemHolder.setIsRecyclable(false); if (mItemAnimator.animateAppearance(itemHolder, preLayoutInfo, postLayoutInfo)) &#123; postAnimationRunner(); &#125;&#125; 该方法中不要忽略if中的内容：mItemAnimator.animateAppearance(itemHolder, preLayoutInfo, postLayoutInfo)那么进入该方法：看注释。@Overridepublic boolean animateAppearance(@NonNull ViewHolder viewHolder, @Nullable ItemHolderInfo preLayoutInfo, @NonNull ItemHolderInfo postLayoutInfo) &#123; // 该方法通过前后的布局信息来判断是移动还是添加。下面我们以添加为例分析 if (preLayoutInfo != null &amp;&amp; (preLayoutInfo.left != postLayoutInfo.left || preLayoutInfo.top != postLayoutInfo.top)) &#123; return animateMove(viewHolder, preLayoutInfo.left, preLayoutInfo.top, postLayoutInfo.left, postLayoutInfo.top); &#125; else &#123; return animateAdd(viewHolder); &#125;&#125; 真正实现是在DefaultItenAnimator中：这里做了三件事情，重置holder的动画，设置显示属性，然后添加到mPendingAdditions中，mPendingAdditions是一个存储添加ViewHolder的List，表示待处理的添加动画的ViewHolder。同样在DefaultItenAnimator总也有，移动的，移除的列表。@Overridepublic boolean animateAdd(final ViewHolder holder) &#123; resetAnimation(holder); ViewCompat.setAlpha(holder.itemView, 0); mPendingAdditions.add(holder); return true;&#125; 最后返回true，进入if，执行postAnimationRunner方法。private void postAnimationRunner() &#123; if (!mPostedAnimatorRunner &amp;&amp; mIsAttached) &#123; ViewCompat.postOnAnimation(this, mItemAnimatorRunner); mPostedAnimatorRunner = true; &#125;&#125; 去看mItemAnimatorRunner，其中调用的ItemAnimator的runPendingAnimations方法。private Runnable mItemAnimatorRunner = new Runnable() &#123; @Override public void run() &#123; if (mItemAnimator != null) &#123; mItemAnimator.runPendingAnimations(); &#125; mPostedAnimatorRunner = false; &#125;&#125;; 然后分析runPendingAnimations方法：该方法并不难，按照移除，移动，改变，添加，依次处理之前的待处理列表中的内容。这里还是以添加的做为例子来分析，看注释。public void runPendingAnimations() &#123; boolean removalsPending = !mPendingRemovals.isEmpty(); boolean movesPending = !mPendingMoves.isEmpty(); boolean changesPending = !mPendingChanges.isEmpty(); boolean additionsPending = !mPendingAdditions.isEmpty(); if (!removalsPending &amp;&amp; !movesPending &amp;&amp; !additionsPending &amp;&amp; !changesPending) &#123; return; &#125; for (ViewHolder holder : mPendingRemovals) &#123; ... &#125; mPendingRemovals.clear(); if (movesPending) &#123; ... &#125; if (changesPending) &#123; ... &#125; if (additionsPending) &#123; final ArrayList additions = new ArrayList&lt;&gt;(); additions.addAll(mPendingAdditions); mAdditionsList.add(additions); mPendingAdditions.clear(); // 重要的是这个adder。其中重要的是 animateAddImpl(holder) 方法。那么来分析这个方法。 Runnable adder = new Runnable() &#123; public void run() &#123; for (ViewHolder holder : additions) &#123; animateAddImpl(holder); &#125; additions.clear(); mAdditionsList.remove(additions); &#125; &#125;; if (removalsPending || movesPending || changesPending) &#123; long removeDuration = removalsPending ? getRemoveDuration() : 0; long moveDuration = movesPending ? getMoveDuration() : 0; long changeDuration = changesPending ? getChangeDuration() : 0; long totalDelay = removeDuration + Math.max(moveDuration, changeDuration); View view = additions.get(0).itemView; ViewCompat.postOnAnimationDelayed(view, adder, totalDelay); &#125; else &#123; adder.run(); &#125; &#125;&#125; 这个方法其实就是通过属性动画对ViewHolder中的View做渐变动画。private void animateAddImpl(final ViewHolder holder) &#123; final View view = holder.itemView; final ViewPropertyAnimatorCompat animation = ViewCompat.animate(view); mAddAnimations.add(holder); animation.alpha(1).setDuration(getAddDuration()). setListener(new VpaListenerAdapter() &#123; @Override public void onAnimationStart(View view) &#123; dispatchAddStarting(holder); &#125; @Override public void onAnimationCancel(View view) &#123; ViewCompat.setAlpha(view, 1); &#125; @Override public void onAnimationEnd(View view) &#123; animation.setListener(null); dispatchAddFinished(holder); mAddAnimations.remove(holder); dispatchFinishedWhenDone(); &#125; &#125;).start();&#125; 到这里，终于是触发了我们的动画。其它的动作，流程类似，细节不同而已。那么通过流程我们可以深入理解以下2点： 如果我们的RecyclerView的高度和宽度不变，那么通过手动执行setHasFixedSize(true)，可以在一定程度上减少计算，提高性能。可以在 4) 步的时候绕过requestLayout，只走自身的布局流程。而requestLayout是申请父控件重新布局流程，两者的计算量是不一样的。自定义ItemAnimator的时候，如果在animateAppearance，animateDisappearance……方法中直接运行了动画，就返回false，如果是暂存起来，就返回true，然后将真正执行动画的操作放在runPendingAnimations方法中。 滑动RecyclerView的滑动过程可以分为2个阶段：手指在屏幕上移动，使RecyclerView滑动的过程，可以称为scroll；手指离开屏幕，RecyclerView继续滑动一段距离的过程，可以称为fling。现在先看看RecyclerView的触屏事件处理onTouchEvent()方法：public boolean onTouchEvent(MotionEvent e) &#123; ... if (mVelocityTracker == null) &#123; mVelocityTracker = VelocityTracker.obtain(); &#125; ... switch (action) &#123; ... case MotionEvent.ACTION_MOVE: &#123; ... final int x = (int) (MotionEventCompat.getX(e, index) + 0.5f); final int y = (int) (MotionEventCompat.getY(e, index) + 0.5f); int dx = mLastTouchX - x; int dy = mLastTouchY - y; ... if (mScrollState != SCROLL_STATE_DRAGGING) &#123; ... if (canScrollVertically &amp;&amp; Math.abs(dy) &gt; mTouchSlop) &#123; if (dy &gt; 0) &#123; dy -= mTouchSlop; &#125; else &#123; dy += mTouchSlop; &#125; startScroll = true; &#125; if (startScroll) &#123; setScrollState(SCROLL_STATE_DRAGGING); &#125; &#125; if (mScrollState == SCROLL_STATE_DRAGGING) &#123; mLastTouchX = x - mScrollOffset[0]; mLastTouchY = y - mScrollOffset[1]; if (scrollByInternal( canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, vtev)) &#123; getParent().requestDisallowInterceptTouchEvent(true); &#125; &#125; &#125; break; ... case MotionEvent.ACTION_UP: &#123; ... final float yvel = canScrollVertically ? -VelocityTrackerCompat.getYVelocity(mVelocityTracker, mScrollPointerId) : 0; if (!((xvel != 0 || yvel != 0) &amp;&amp; fling((int) xvel, (int) yvel))) &#123; setScrollState(SCROLL_STATE_IDLE); &#125; resetTouch(); &#125; break; ... &#125; ...&#125; 这里我以垂直方向的滑动来说明。当RecyclerView接收到ACTION_MOVE事件后，会先计算出手指移动距离（dy），并与滑动阀值（mTouchSlop）比较，当大于此阀值时将滑动状态设置为SCROLL_STATE_DRAGGING，而后调用scrollByInternal()方法，使RecyclerView滑动，这样RecyclerView的滑动的第一阶段scroll就完成了；当接收到ACTION_UP事件时，会根据之前的滑动距离与时间计算出一个初速度yvel，这步计算是由VelocityTracker实现的，然后再以此初速度，调用方法fling()，完成RecyclerView滑动的第二阶段fling。显然滑动过程中关键的方法就2个：scrollByInternal()与fling()。接下来同样以垂直线性布局来说明。先来说明scrollByInternal()，跟踪进入后，会发现它最终会调用到LinearLayoutManager.scrollBy()方法，这个过程很简单，我就不列出源码了，但是分析到这里先暂停下，去看看fling()方法：public boolean fling(int velocityX, int velocityY) &#123; ... mViewFlinger.fling(velocityX, velocityY); ...&#125; 有用的就这一行，其它乱七八糟的不看也罢。mViewFlinger是一个Runnable的实现ViewFlinger的对象，就是它来控件着ReyclerView的fling过程的算法的。下面来看下类ViewFlinger的一段代码：void postOnAnimation() &#123; if (mEatRunOnAnimationRequest) &#123; mReSchedulePostAnimationCallback = true; &#125; else &#123; removeCallbacks(this); ViewCompat.postOnAnimation(RecyclerView.this, this); &#125;&#125;public void fling(int velocityX, int velocityY) &#123; setScrollState(SCROLL_STATE_SETTLING); mLastFlingX = mLastFlingY = 0; mScroller.fling(0, 0, velocityX, velocityY, Integer.MIN_VALUE, Integer.MAX_VALUE, Integer.MIN_VALUE, Integer.MAX_VALUE); postOnAnimation();&#125; 可以看到，其实RecyclerView的fling是借助Scroller实现的；然后postOnAnimation()方法的作用就是在将来的某个时刻会执行我们给定的一个Runnable对象，在这里就是这个mViewFlinger对象，这部分原理我就不再深入分析了，它已经不属于本文的范围了。并且，关于Scroller的作用及原理，本文也不会作过多解释。对于这两点各位可以自行查阅，有很多文章对于作过详细阐述的。接下来看看ViewFlinger.run()方法：public void run() &#123; ... if (scroller.computeScrollOffset()) &#123; final int x = scroller.getCurrX(); final int y = scroller.getCurrY(); final int dx = x - mLastFlingX; final int dy = y - mLastFlingY; ... if (mAdapter != null) &#123; ... if (dy != 0) &#123; vresult = mLayout.scrollVerticallyBy(dy, mRecycler, mState); overscrollY = dy - vresult; &#125; ... &#125; ... if (!awakenScrollBars()) &#123; invalidate();//刷新界面 &#125; ... if (scroller.isFinished() || !fullyConsumedAny) &#123; setScrollState(SCROLL_STATE_IDLE); &#125; else &#123; postOnAnimation(); &#125; &#125; ...&#125; 本段代码中有个方法mLayout.scrollVerticallyBy()，跟踪进入你会发现它最终也会走到LinearLayoutManager.scrollBy()，这样虽说RecyclerView的滑动可以分为两阶段，但是它们的实现最终其实是一样的。这里我先解释下上段代码。第一，dy表示滑动偏移量，它是由Scroller根据时间偏移量（Scroller.fling()开始时间到当前时刻）计算出的，当然如果是RecyclerView的scroll阶段，这个偏移量也就是手指滑动距离。第二，上段代码会多次执行，至到Scroller判断滑动结束或已经滑动到边界。再多说一下，postOnAnimation()保证了RecyclerView的滑动是流畅，这里涉及到著名的“android 16ms”机制，简单来说理想状态下，上段代码会以16毫秒一次的速度执行，这样其实，Scroller每次计算的滑动偏移量是很小的一部分，而RecyclerView就会根据这个偏移量，确定是平移ItemView，还是除了平移还需要再创建新ItemView。 现在就来看看LinearLayoutManager.scrollBy()方法：int scrollBy(int dy, RecyclerView.Recycler recycler, RecyclerView.State state) &#123; ... final int absDy = Math.abs(dy); updateLayoutState(layoutDirection, absDy, true, state); final int consumed = mLayoutState.mScrollingOffset + fill(recycler, mLayoutState, state, false); ... final int scrolled = absDy &gt; consumed ? layoutDirection * consumed : dy; mOrientationHelper.offsetChildren(-scrolled); ...&#125; 如上文所讲到的fill()方法，作用就是向可绘制区间填充ItemView，那么在这里，可绘制区间就是滑动偏移量！再看方法mOrientationHelper.offsetChildren()作用就是平移ItemView。好了整个滑动过程就分析完成了，当然RecyclerView的滑动还有个特性叫平滑滑动（smooth scroll），其实它的实现就是一个fling滑动，所以就不再赘述了。 缓存逻辑前面的章节对于Recycler这个类相关的操作我们都直接进行了忽略，这里我们好好的来看下RecylerView是如何工作的。 与ListView不同，RecyclerView的缓存是分为多级的，但其实整个的缓存逻辑还是很容易理解的，Recycler的作用就是重用ItemView。在填充ItemView的时候，ItemView是从它获取的；滑出屏幕的ItemView是由它回收的。对于不同状态的ItemView存储在了不同的集合中，比如有scrapped、cached、exCached、recycled，当然这些集合并不是都定义在同一个类里。 public final class Recycler &#123; // 一级缓存 final ArrayList&lt;ViewHolder&gt; mAttachedScrap = new ArrayList&lt;&gt;(); ArrayList&lt;ViewHolder&gt; mChangedScrap = null; // 二级缓存 final ArrayList&lt;ViewHolder&gt; mCachedViews = new ArrayList&lt;ViewHolder&gt;(); // 三级缓存 private ViewCacheExtension mViewCacheExtension; // 四级缓存 RecycledViewPool mRecyclerPool;&#125; 回到之前的layoutChunk方法中，有行代码layoutState.next(recycler)，它的作用自然就是获取ItemView，我们进入这个方法查看，最终它会调用到RecyclerView.Recycler.getViewForPosition()方法： View getViewForPosition(int position, boolean dryRun) &#123; return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView;&#125; getViewForPosition 可以看到其实每次 rv 取出要显示的一个item本质上就是取出一个viewholder，根据viewholder上关联的itemview来展示这个item。而取出viewholder最核心的方法就是 tryGetViewHolderForPositionByDeadlineViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; // ... boolean fromScrapOrHiddenOrCache = false; ViewHolder holder = null; // 0) 先从 mChangedScrap 取viewholder（一级缓存） if (mState.isPreLayout()) &#123; holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; &#125; // 1) 从mAttachedScrap(一级缓存) 或 mCachedViews（二级缓存）中取viewholder if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); if (holder != null) &#123; if (!validateViewHolderForOffsetPosition(holder)) &#123; // recycle holder (and unscrap if relevant) since it can't be used if (!dryRun) &#123; // we would like to recycle this but need to make sure it is not used by // animation logic etc. holder.addFlags(ViewHolder.FLAG_INVALID); if (holder.isScrap()) &#123; removeDetachedView(holder.itemView, false); holder.unScrap(); &#125; else if (holder.wasReturnedFromScrap()) &#123; holder.clearReturnedFromScrapFlag(); &#125; recycleViewHolderInternal(holder); &#125; holder = null; &#125; else &#123; fromScrapOrHiddenOrCache = true; &#125; &#125; &#125; if (holder == null) &#123; // ... stable ids的逻辑 // 3) 三级缓存 if (holder == null &amp;&amp; mViewCacheExtension != null) &#123; // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension .getViewForPositionAndType(this, position, type); if (view != null) &#123; holder = getChildViewHolder(view); if (holder == null) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view which does not have a ViewHolder\" + exceptionLabel()); &#125; else if (holder.shouldIgnore()) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view that is ignored. You must call stopIgnoring before\" + \" returning this view.\" + exceptionLabel()); &#125; &#125; &#125; if (holder == null) &#123; // fallback to pool // 4) 四级缓存 holder = getRecycledViewPool().getRecycledView(type); if (holder != null) &#123; holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) &#123; invalidateDisplayListInt(holder); &#125; &#125; &#125; if (holder == null) &#123; // ... // 这里会回调到 adapter的 onCreateViewHolder()方法 holder = mAdapter.createViewHolder(RecyclerView.this, type); // ... &#125; &#125; // 拿到holder之后会调用 tryBindViewHolderByDeadline 进行绑定 boolean bound = false; if (mState.isPreLayout() &amp;&amp; holder.isBound()) &#123; // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; &#125; else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; if (DEBUG &amp;&amp; holder.isRemoved()) &#123; throw new IllegalStateException(\"Removed holder should be bound and it should\" + \" come here only in pre-layout. Holder: \" + holder + exceptionLabel()); &#125; final int offsetPosition = mAdapterHelper.findPositionOffset(position); // 下面方法会回调adapter的onBindViewHolder()方法 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125; //生成LayoutParams的代码 ... return holder.itemView;&#125; 获取View的逻辑可以整理成如下：根据列表位置获取ItemView，先后从scrapped、cached、exCached、recycled集合中查找相应的ItemView，如果没有找到，就创建（ Adapter.createViewHolder() ），最后与数据集绑定。 其中scrapped、cached和exCached集合定义在RecyclerView.Recycler中，分别表示将要在RecyclerView中删除的ItemView、一级缓存ItemView和二级缓存ItemView，cached集合的大小默认为２，exCached是需要我们通过RecyclerView.ViewCacheExtension自己实现的，默认没有； recycled集合其实是一个Map,private SparseArray&gt; mScrap = new SparseArray&gt;();，定义在RecyclerView.RecycledViewPool中，将ItemView以ItemType分类保存了下来，这里算是RecyclerView设计上的亮点，通过RecyclerView.RecycledViewPool可以实现在不同的RecyclerView之间共享ItemView，只要为这些不同RecyclerView设置同一个RecyclerView.RecycledViewPool就可以了。 上面解释了ItemView从不同集合中获取的方式，那么RecyclerView又是在什么时候向这些集合中添加ItemView的呢？下面我逐个介绍下。scrapped集合中存储的其实是正在执行REMOVE操作的ItemView，这部分会在后文进一步描述。在fill()方法的循环体中有行代码recycleByLayoutState(recycler, layoutState);，最终这个方法会执行到RecyclerView.Recycler.recycleViewHolderInternal()方法：void recycleViewHolderInternal(ViewHolder holder) &#123; ... if (holder.isRecyclable()) &#123; if (!holder.hasAnyOfTheFlags(ViewHolder.FLAG_INVALID | ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_UPDATE)) &#123; int cachedViewSize = mCachedViews.size(); if (cachedViewSize &gt;= mViewCacheMax &amp;&amp; cachedViewSize &gt; 0) &#123; recycleCachedViewAt(0); cachedViewSize --; &#125; if (cachedViewSize &lt; mViewCacheMax) &#123; mCachedViews.add(holder); cached = true; &#125; &#125; if (!cached) &#123; addViewHolderToRecycledViewPool(holder); recycled = true; &#125; &#125; ...&#125; View的回收并不像View的创建那么复杂，这里只涉及了两层缓存mCachedViews与mRecyclerPool，mCachedViews相当于一个先进先出的数据结构，每当有新的View需要缓存时都会将新的View存入mCachedViews，而mCachedViews则会移除头元素，并将头元素放入mRecyclerPool，所以mCachedViews相当于一级缓存，mRecyclerPool则相当于二级缓存，并且mRecyclerPool是可以多个RecyclerView共享的，这在类似于多Tab的新闻类应用会有很大的用处，因为多个Tab下的多个RecyclerView可以共用一个二级缓存。减少内存开销。 RecyclerView定义了4种针对数据集的操作，分别是ADD、REMOVE、UPDATE、MOVE，封装在了AdapterHelper.UpdateOp类中，并且所有操作由一个大小为30的对象池管理着。当我们要对数据集作任何操作时，都会从这个对象池中取出一个UpdateOp对象，放入一个等待队列中，最后调用RecyclerView.RecyclerViewDataObserver.triggerUpdateProcessor()方法，根据这个等待队列中的信息，对所有子控件重新测量、布局并绘制且执行动画。以上就是我们调用Adapter.notifyItemXXX()系列方法后发生的事。显然当我们对某个ItemView做操作时，它很有可以会影响到其它ItemView。下面我以REMOVE为例来梳理下这个流程。 首先调用Adapter.notifyItemRemove()，追溯到方法RecyclerView.RecyclerViewDataObserver.onItemRangeRemoved()：public void onItemRangeRemoved(int positionStart, int itemCount) &#123; assertNotInLayoutOrScroll(null); if (mAdapterHelper.onItemRangeRemoved(positionStart, itemCount)) &#123; triggerUpdateProcessor(); &#125;&#125; 这里的mAdapterHelper.onItemRangeRemoved()就是向之前提及的等待队列添加一个类型为REMOVE的UpdateOp对象， triggerUpdateProcessor()方法就是调用View.requestLayout()方法，这会导致界面重新布局，也就是说方法RecyclerView.onLayout()会随后调用，这之后的流程就和在绘制流程一节中所描述的一致了。 与AdapterView比较谈到RecyclerView，总避免不了与它的前辈AdapterView家族进行一撕，这里我整理了一下RecylerView与AdapterView的各自特点： 前面四点两位都提供了各自的实现，但也各有各自的特点： 点击事件ListView原生提供Item单击、长按的事件, 而RecyclerView则需要使用onTouchListener，相对自己实现会比较复杂。 分割线ListView可以很轻松的设置divider属性来显示Item之间的分割线，RecyclerView需要我们自己实现ItemDecoration，前者使用简单，后者可定制性强。 布局类型AdapterView提供了ListView与GridView两种类型，分别对应流式布局与网格式布局。RecyclerView提供了LinearLayoutManager、GridLayoutManager与之抗衡，相对而言，使用RecyclerView来进行更换布局方式更为轻松。只需要更换一个变量即可，而对于AdapterView而言则是需要更换一个View了。 缓存方式ListView使用了一个名为RecyclerBin的类负责试图的缓存，而Recycler则使用Recycler来进行缓存，原理上两者基本一致。RecyclerView：里面存储的不是View，而是ViewHolder 局部刷新这是一个很有用的功能，在ListView中我们想局部刷新某个Item需要自己来编写刷新逻辑，而在RecyclerView中我们可以通过 notifyItemChanged(position) 来刷新单个Item，甚至可以通过 notifyItemChanged(position, payload) 来传入一个payload信息来刷新单个Item中的特定内容。 动画作为视觉动物，我相信很多人喜欢RecylerView都和它简单的动画API有关，因为之前对ListView做动画比较困难，并且不舒服。 嵌套布局嵌套布局也是最近比较火的一个概念，RecyclerView实现了 NestedScrollingChild 接口，使得它可以和一些嵌套组件很好的工作。我们再来看ListView原生独有的几个特点： 头部与尾部的支持ListView原生支持添加头部与尾部，虽然RecyclerView可以通过定义不同的Type来做支持，但实际应用中，如果封装的不好，是很容易出问题的，因为Adapter中的数据位置与物理数据位置发生了偏移。 多选支持多选、单选也是ListView的一大长处，其实如果要我们自己在RecyclerView中去做支持还是需要不少代码量的。多数据源的支持ListView提供了CursorAdapter、ArrayAdapter，可以让我们很方便的从数据库或者数组中获取数据，这在测试的时候很有用。 总结综上，我们会发现RecycerView的最大特点就是灵活，正因为这种灵活，因此会牺牲了某些便利性。而AdapterView相对来讲就比较刻板，但它原生为我们提供了很多有用的方法来便于我们快速开发。ListView并不像当年的ActivityGroup，在Fragment出来后就被标记为Deprecated。两者目前还是一种互补的关系，起码在短时间内RecyclerView还并不能完全替代AdapterView，个人感觉原因有两个，一是目前太多的应用使用了ListView，并且ListView向RecyclerView转变也没有无损的方法。第二点，比如我就是想添加个头部，每个item带个点击事件这类简单的需求，ListView完全可以很轻松的胜任，没必要舍近求远来使用RecyclerView。因此，在实际应用中选择更适合自己的就好。 当然，从Google最近几次的更新来看，RecyclerView的进化还是很迅速的，而ListView则几乎没什么变动，所以RecyclerView绝对是大大的潜力股呀。 设计精巧的类在翻看RecycleView源码的过程中也遇见了许多之前没有注意过的类，这些类都可以复用在我们的日常工作当中。这里列举出其中具有代表性的几位。 Bucket如果一个对象有大量的是与非的状态需要表示，通常我们会使用BitMask 技术来节省内存，在 Java 中，一个 byte 类型，有 8 位（bit），可以表达 8 个不同的状态，而 int 类型，则有 32 位，可以表达 32 种状态。再比如Long类型，有64位，则可以表达64中状态。一般情况下使用一个Long已经足够我们使用了。但如果有不设上限的状态需要我们表示呢？在ChildHelper里有一个静态内部类Bucket，基本源码如下：static class Bucket &#123; final static int BITS_PER_WORD = Long.SIZE; final static long LAST_BIT = 1L &lt;&lt; (Long.SIZE - 1); long mData = 0; Bucket next; void set(int index) &#123; if (index &gt;= BITS_PER_WORD) &#123; ensureNext(); next.set(index - BITS_PER_WORD); &#125; else &#123; mData |= 1L &lt;&lt; index; &#125; &#125; ...&#125; 可以看到，Bucket是一个链表结构，当index大于64的时候，它便会去下一个Bucket去寻找，所以，Bucket可以不设上限的表示状态。 Pools熟悉Message回收机制的朋友可能了解，在使用Message对象时最好通过 Message.obtain() 方法来获取，这样可以在很多情况下避免创建新对象。在使用完之后调用 message.recycle() 来回收消息。谷歌为这种机制也提供了抽象的实现,就是位于v4包下Pools类, 内部接口Pool提供了 acquire 与 release 两个方法,不过需要注意的是这个 acquire 方法可能返回空,毕竟Pools不是业务类,它不应该清楚对象的具体创建逻辑.还有一点是Pools与Message类的实现机制不同,每个Message对象内部都持有一个引用下一个message的指针,相当于一个链表结构,而Pool的实现类 SimplePool 中使用的是数组.Pool机制在 RecycleView 中有如下几处应用： RecycleView将item的增删改封装为 UpdateOp 类。ViewInfoStore 类中静态内部类 InfoRecord 。 总结RecyclerView也不是万能的，它的灵活性也是有一定限制的，比如我就遇到了一不是很好解决的问题：Recyler的缓存级别是一个Item的整个View，而我们没办法自定义缓存级别，这样说比较抽象，举个例子，我的某些Item的某个子View加载很耗时，所以我希望我在上下滑动的时候，Item的其它View是可以被回收利用的，但这个加载很耗时的View是不要重复使用的。即我希望用空间换取时间来获取滑动的流畅性。当然，这样的需求不常见，RecyclerView也不能很好的满足这一点。 RecyclerView也应该算作一个明星控件了，自从其诞生开始就备受欢迎，仔细的学习也能让我们在工作中更容易的、更恰当的使用。本文也只是分析了RecyclerView的一部分，关于动画、滑动、嵌套滑动等等还需要大家自行去研究。有兴趣的可以看看RecyclerView 和 ListView 使用对比分析 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/05/31/RecyclerView-source-code/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"RecyclerView 中的设计模式","slug":"RecyclerView-Design-Pattern","date":"2019-05-29T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/05/30/RecyclerView-Design-Pattern/","link":"","permalink":"http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/","excerpt":"本篇文章是在掘金上偶然看到，介绍的比较全面，收藏到本博客\nRecyclerview 在 Android 应用开发中使用非常频繁，但一般人只知道onCreateViewHolder、onBindViewHolder等简单使用。了解这篇文章无论是对项目中实际开发还是Android源码设计，都会有借鉴和帮助\nRecyclerview 源码中用到的设计模式本文通过桥接,组合,适配器,观察者模式四种设计模式来解读RecyclerView。","text":"本篇文章是在掘金上偶然看到，介绍的比较全面，收藏到本博客 Recyclerview 在 Android 应用开发中使用非常频繁，但一般人只知道onCreateViewHolder、onBindViewHolder等简单使用。了解这篇文章无论是对项目中实际开发还是Android源码设计，都会有借鉴和帮助 Recyclerview 源码中用到的设计模式本文通过桥接,组合,适配器,观察者模式四种设计模式来解读RecyclerView。 通过桥接模式，使RecyclerView 将布局方式独立成LayoutManager，实现对布局的定制化。 通过组合模式，使RecycleView通过dispatchLayout对Item View进行布局绘制的。 通过适配器模式，ViewHolder将RecycleView与ItemView联系起来，使得RecycleView方便操作ItemView。 通过观察者模式，给ViewHolder注册观察者，当调用notifyDataSetChanged时，就能重新绘制。 设计思路RecyclerView官网给出的定义是: A flexible view for providing a limited window into a large data set. ，也就是在限定的视图内展示大量的数据，来一张通俗明了的图： RecyclerView的职责就是将Datas中的数据以一定的规则展示在它的上面，但说破天RecyclerView只是一个ViewGroup，它只认识View，不清楚Data数据的具体结构，所以两个陌生人之间想构建通话，我们很容易想到适配器模式,因此，RecyclerView需要一个Adapter(适配器模式)来与Datas进行交流： 如上如所示，RecyclerView表示只会和ViewHolder进行接触，而Adapter的工作就是将Data转换为RecyclerView认识的ViewHolder，因此RecyclerView就间接地认识了Datas。 事情虽然进展愉快，但RecyclerView是个很懒惰的人，尽管Adapter已经将Datas转换为RecyclerView所熟知的View，但RecyclerView并不想自己管理些子View，因此，它雇佣了一个叫做LayoutManager的大祭司来帮其完成布局(桥接模式)，现在，图示变成下面这样： 如上图所示，LayoutManager协助RecyclerView来完成布局。但LayoutManager这个大祭司也有弱点，就是它只知道如何将一个一个的View布局在RecyclerView上，但它并不懂得如何管理这些View，如果大祭司肆无忌惮的玩弄View的话肯定会出事情，所以，必须有个管理View的护法，它就是Recycler，LayoutManager在需要View的时候回向护法进行索取，当LayoutManager不需要View(试图滑出)的时候，就直接将废弃的View丢给Recycler，图示如下： 到了这里，有负责翻译数据的Adapter，有负责布局的LayoutManager，有负责管理View的Recycler，一切都很完美，但RecyclerView乃何等神也，它下令说当子View变动的时候姿态要优雅(动画)，所以用雇佣了一个舞者ItemAnimator(观察者模式)，因此，舞者也进入了这个图示: 如上，我们就是从宏观层面来对RecylerView有个大致的了解，可以看到，RecyclerView作为一个View，它只负责接受用户的各种讯息，然后将信息各司其职的分发出去。接下来我们将深入源码，详细讲解用到的设计模式，看看RecyclerView都是怎么来操作各个组件工作的。 桥接模式详解模式的定义将抽象部分与实现部分分离，使它们都可以独立的变化。 模式的使用场景如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性，避免在两个层次之间建立静态的联系。设计要求实现化角色的任何改变不应当影响客户端，或者实现化角色的改变对客户端是完全透明的。需要跨越多个平台的图形和窗口系统上。一个类存在两个独立变化的维度，且两个维度都需要进行扩展。 UML类图 角色介绍抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。 修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接 口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。具体实现化(ConcreteImplementor)角色：这个角色给出实现化角色接口的具体实现。 模式的简单实现其实Java的虚拟机就是一个很好的例子，在不同平台平台上，用不同的虚拟机进行实现，这样只需把Java程序编译成符合虚拟机规范的文件，且只用编译一次，便在不同平台上都能工作。 但是这样说比较抽象，用一个简单的例子来实现bridge模式。 编写一个程序，使用两个绘图的程序的其中一个来绘制矩形或者原型，同时，在实例化矩形的时候，它要知道使用绘图程序1（DP1）还是绘图程序2（DP2）。 (ps:假设dp1和dp2的绘制方式不一样，它们是用不同方式进行绘制，示例代码，不讨论过多细节) 实现源码首先是两个绘图程序dp1,dp2//具体的绘图程序类dp1public class DP1 &#123; public void draw_1_Rantanle()&#123; System.out.println(\"使用DP1的程序画矩形\"); &#125; public void draw_1_Circle()&#123; System.out.println(\"使用DP1的程序画圆形\"); &#125;&#125;//具体的绘图程序类dp2public class DP2 &#123; public void drawRantanle()&#123; System.out.println(\"使用DP2的程序画矩形\"); &#125; public void drawCircle()&#123; System.out.println(\"使用DP2的程序画圆形\"); &#125;&#125; 接着​抽象的形状Shape和两个派生类：矩形Rantanle和圆形Circle//抽象化角色Abstractionabstract class Shape &#123; //持有实现的角色Implementor(作图类) protected Drawing myDrawing; public Shape(Drawing drawing) &#123; this.myDrawing = drawing; &#125; abstract public void draw(); //保护方法drawRectangle protected void drawRectangle()&#123; //this.impl.implmentation() myDrawing.drawRantangle(); &#125; //保护方法drawCircle protected void drawCircle()&#123; //this.impl.implmentation() myDrawing.drawCircle(); &#125;&#125;//修正抽象化角色Refined Abstraction(矩形)public class Rantangle extends Shape&#123; public Rantangle(Drawing drawing) &#123; super(drawing); &#125; @Override public void draw() &#123; drawRectangle(); &#125;&#125;//修正抽象化角色Refined Abstraction(圆形)public class Circle extends Shape &#123; public Circle(Drawing drawing) &#123; super(drawing); &#125; @Override public void draw() &#123; drawCircle(); &#125;&#125; 最后，我们的实现绘图的Drawing和分别实现dp1的V1Drawing和dp2的V2Drawing//实现化角色Implementor//implmentation两个方法，画圆和画矩形public interface Drawing &#123; public void drawRantangle(); public void drawCircle();&#125;//具体实现化逻辑ConcreteImplementor//实现了接口方法，使用DP1进行绘图public class V1Drawing implements Drawing&#123; DP1 dp1; public V1Drawing() &#123; dp1 = new DP1(); &#125; @Override public void drawRantangle() &#123; dp1.draw_1_Rantanle(); &#125; @Override public void drawCircle() &#123; dp1.draw_1_Circle(); &#125; &#125;//具体实现化逻辑ConcreteImplementor//实现了接口方法，使用DP2进行绘图public class V2Drawing implements Drawing&#123; DP2 dp2; public V2Drawing() &#123; dp2 = new DP2(); &#125; @Override public void drawRantangle() &#123; dp2.drawRantanle(); &#125; @Override public void drawCircle() &#123; dp2.drawCircle(); &#125;&#125; 在这个示例中，图形Shape类有两种类型，圆形和矩形，为了使用不同的绘图程序绘制图形，把实现的部分进行了分离，构成了Drawing类层次结构，包括V1Drawing和V2Drawing。在具体实现类中，V1Drawing控制着DP1程序进行绘图，V2Drawing控制着DP2程序进行绘图，以及保护的方法drawRantangle,drawCircle(Shape类中) 。 组合模式详解模式的定义组合模式(Composite Pattern)又叫作部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。 GoF在《设计模式》一书中这样定义组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。 模式的使用场景表示对象的部分-整体层次结构。从一个整体中能够独立出部分模块或功能的场景。 UML类图 角色分析Component抽象构件角色 ：定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性。Leaf叶子构件 : 叶子对象，其下再也没有其他的分支。Composite树枝构件 ：树枝对象，它的作用是组合树枝节点和叶子节点形成一个树形结构。 该模式的实现实例抽象构件 Component.java：public abstract class Component &#123; //个体和整体都具有的共享 public void doSomething()&#123; //业务逻辑 &#125;&#125; 树枝构件 Composite.javapublic class Composite extends Component &#123; //构件容器 private ArrayList componentArrayList = new ArrayList(); //增加一个叶子构件或树枝构件 public void add(Component component)&#123; this.componentArrayList.add(component); &#125; //删除一个叶子构件或树枝构件 public void remove(Component component)&#123; this.componentArrayList.remove(component); &#125; //获得分支下的所有叶子构件和树枝构件 public ArrayList getChildren()&#123; return this.componentArrayList; &#125; &#125; 树叶构件 Leaf.javapublic class Leaf extends Component &#123; //可以覆写父类方法 public void doSomething()&#123; &#125;&#125; 场景类 Client.javapublic class Client &#123; public static void main(String[] args) &#123; //创建一个根节点 Composite root = new Composite(); root.doSomething(); //创建一个树枝构件 Composite branch = new Composite(); //创建一个叶子节点 Leaf leaf = new Leaf(); //建立整体 root.add(branch); branch.add(leaf); &#125; //通过递归遍历树 public static void display(Composite root)&#123; for(Component c:root.getChildren())&#123; if(c instanceof Leaf)&#123; //叶子节点 c.doSomething(); &#125;else&#123; //树枝节点 display((Composite)c); &#125; &#125; &#125;&#125; 适配器模式详解7种结构型模式：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。其中对象的适配器模式是各种模式的起源，我们看下面的图： 适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。首先，我们来看看类的适配器模式，先看类图： 类的适配器模式 核心思想就是：有一个Source类，拥有一个方法，待适配，目标接口时Targetable，通过Adapter类，将Source的功能扩展到Targetable里，看代码：public class Source &#123; public void method1() &#123; System.out.println(\"this is original method!\"); &#125; &#125; public interface Targetable &#123; /* 与原类中的方法相同 */ public void method1(); /* 新类的方法 */ public void method2(); &#125; public class Adapter extends Source implements Targetable &#123; @Override public void method2() &#123; System.out.println(\"this is the targetable method!\"); &#125; &#125; Adapter类继承Source类，实现Targetable接口，下面是测试类：public class AdapterTest &#123; public static void main(String[] args) &#123; Targetable target = new Adapter(); target.method1(); target.method2(); &#125; &#125; 对象的适配器模式基本思路和类的适配器模式相同，只是将Adapter类作修改，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。看图： 只需要修改Adapter类的源码即可：public class Wrapper implements Targetable &#123; private Source source; public Wrapper(Source source)&#123; super(); this.source = source; &#125; @Override public void method2() &#123; System.out.println(\"this is the targetable method!\"); &#125; @Override public void method1() &#123; source.method1(); &#125; &#125; 测试类：public class AdapterTest &#123; public static void main(String[] args) &#123; Source source = new Source(); Targetable target = new Wrapper(source); target.method1(); target.method2(); &#125; &#125; 接口的适配器模式接口的适配器是这样的：有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的所有方法，这明显有时比较浪费，因为并不是所有的方法都是我们需要的，有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们需要的方法就行。看一下类图： 这个很好理解，在实际开发中，我们也常会遇到这种接口中定义了太多的方法，以致于有时我们在一些实现类中并不是都需要。看代码：public interface Sourceable &#123; public void method1(); public void method2(); &#125; 抽象类Wrapper2：public abstract class Wrapper2 implements Sourceable&#123; public void method1()&#123;&#125; public void method2()&#123;&#125; &#125; public class SourceSub1 extends Wrapper2 &#123; public void method1()&#123; System.out.println(\"the sourceable interface's first Sub1!\"); &#125; &#125; public class SourceSub2 extends Wrapper2 &#123; public void method2()&#123; System.out.println(\"the sourceable interface's second Sub2!\"); &#125; &#125; public class WrapperTest &#123; public static void main(String[] args) &#123; Sourceable source1 = new SourceSub1(); Sourceable source2 = new SourceSub2(); source1.method1(); source1.method2(); source2.method1(); source2.method2(); &#125; &#125; 讲了这么多，总结一下三种适配器模式的应用场景： 类的适配器模式：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。 对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。 接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。 观察者模式详解观察者模式（Observer）是类和类之间的关系，不涉及到继承，学的时候应该记得归纳。观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。先来看看关系图： 我解释下这些类的作用：MySubject类就是我们的主对象，Observer1和Observer2是依赖于MySubject的对象，当MySubject变化时，Observer1和Observer2必然变化。AbstractSubject类中定义着需要监控的对象列表，可以对其进行修改：增加或删除被监控对象，且当MySubject变化时，负责通知在列表内存在的对象。我们看实现代码： 一个Observer接口：public interface Observer &#123; public void update(); &#125; 两个实现类：public class Observer1 implements Observer &#123; @Override public void update() &#123; System.out.println(\"observer1 has received!\"); &#125; &#125; public class Observer2 implements Observer &#123; @Override public void update() &#123; System.out.println(\"observer2 has received!\"); &#125; &#125; Subject接口及实现类：public interface Subject &#123; /*增加观察者*/ public void add(Observer observer); /*删除观察者*/ public void del(Observer observer); /*通知所有的观察者*/ public void notifyObservers(); /*自身的操作*/ public void operation(); &#125; public abstract class AbstractSubject implements Subject &#123; private Vector vector = new Vector(); @Override public void add(Observer observer) &#123; vector.add(observer); &#125; @Override public void del(Observer observer) &#123; vector.remove(observer); &#125; @Override public void notifyObservers() &#123; Enumeration enumo = vector.elements(); while(enumo.hasMoreElements())&#123; enumo.nextElement().update(); &#125; &#125; &#125; public class MySubject extends AbstractSubject &#123; @Override public void operation() &#123; System.out.println(\"update self!\"); notifyObservers(); &#125; &#125; 测试类：public class ObserverTest &#123; public static void main(String[] args) &#123; Subject sub = new MySubject(); sub.add(new Observer1()); sub.add(new Observer2()); sub.operation(); &#125; &#125; 这些东西，其实不难，只是有些抽象，不太容易整体理解，还有就是门面模式，适配器模式，桥接模式有些同学觉得都差不多，其实大不一样，但都是结构型模式。 Facade（门面模式）出现较多是这样的情况,你有一个复杂的系统,对应了各种情况,客户看了说功能不错,但是使用太麻烦.你说没问题,我给你提供一个统一的门面.所以Facade使用的场合多是对系统的”优化”. Adapter出现是这样的情况,你有一个类提供接口A,但是你的客户需要一个实现接口B的类,这个时候你可以写一个Adapter让把A接口变成B接口,所以Adapter使用的场合是指鹿为马.就是你受夹板气的时候,一边告诉你我只能提供给你A(鹿),一边告诉你说我只要B(马),他长了四条腿,你没办法了,把鹿牵过去说,这是马,你看他有四条腿.(当然实现指鹿为马也有两种方法,一个方法是你只露出鹿的四条腿,说你看这是马,这种方式就是封装方式的Adapter实现,另一种方式是你把鹿牵过去,但是首先介绍给他说这是马,因为他长了四条腿这种是继承的方式.) Bridge在一般的开发中出现的情况并不多,AWT是一个,SWT也算部分是,如果你的客户要求你开发一个系统,这个系统在Windows下运行界面的样子是Windows的样子.在Linux下运行是Linux下的样子.在Macintosh下运行要是Mac Os的样子.怎么办? 定义一系列的控件Button,Text,radio,checkBox等等.供上层开发者使用,他们使用这些控件的方法,利用这些控件构造一个系统的GUI,然后你为这些控件写好Linux的实现,让它在Linux上调用Linux本地的对应控件,在Windows上调用Windows本地的对应控件,在Macintosh上调用Macintosh本地的对应控件ok,你的任务完成了. 篇幅有限本文只介绍了Recyclerview源码中应用到的几种设计模式，下一篇文章会继续介绍Recyclerview源码 Ref 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"TCP三次握手解读","slug":"TCP-Three-way-Handshake","date":"2019-05-26T16:00:00.000Z","updated":"2024-12-05T09:41:56.283Z","comments":true,"path":"2019/05/27/TCP-Three-way-Handshake/","link":"","permalink":"http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/","excerpt":"本篇文章节选自知乎问答，部分图片来自网络，文末已给出链接\n网络上\b有很多关于TCP三次握手的解读和类比，这些都是不全面的，如下：\n\n三次握手：“喂，你听得到吗？”“我听得到呀，你听得到我吗？”“我能听到你，今天 balabala……”","text":"本篇文章节选自知乎问答，部分图片来自网络，文末已给出链接 网络上\b有很多关于TCP三次握手的解读和类比，这些都是不全面的，如下： 三次握手：“喂，你听得到吗？”“我听得到呀，你听得到我吗？”“我能听到你，今天 balabala……” SYN、ACT是TCP封包中的控制单元，但其实过程中省略了其他封包内容，例如： 上面的例子错误，就是因为忽略了SEQ内容。看完下面内容，你就会明白为什么了。 三次握手的误解与错误类比(RFC解读)如果你细读RFC793，也就是 TCP 的协议 RFC，你就会发现里面就讲到了为什么三次握手是必须的——TCP 需要 seq 序列号来做可靠重传或接收，而避免连接复用时无法分辨出 seq 是延迟或者是旧链接的 seq，因此需要三次握手来约定确定双方的 ISN（初始 seq 序列号）。 下面给出详细的 RFC 解读说明：（数据分组称为分段（Segment），国内通常用包来称呼） 我们首先要知道到一点就是， TCP 的可靠连接是靠 seq（ sequence numbers 序列号）来达成的。 A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. TCP 设计中一个基本设定就是，通过TCP 连接发送的每一个包，都有一个sequence number。而因为每个包都是有序列号的，所以都能被确认收到这些包。确认机制是累计的，所以一个对sequence number X 的确认，意味着 X 序列号之前(不包括 X) 包都是被确认接收到的。 The protocol places no restriction on a particular connection being used over and over again. The problem that arises from this is – “how does the TCP identify duplicate segments from previous incarnations of the connection?” This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished. TCP 协议是不限制一个特定的连接（两端 socket 一样）被重复使用的。所以这样就有一个问题：这条连接突然断开重连后，TCP 怎么样识别之前旧链接重发的包？——这就需要独一无二的 ISN（初始序列号） 机制。 When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN’s will be unique. 当一个新连接建立时，初始序列号（ initial sequence number ISN）生成器会生成一个新的32位的 ISN。 这个生成器会用一个32位长的时钟，差不多4µs 增长一次，因此 ISN 会在大约 4.55 小时循环一次（2^32位的计数器，需要2^324 µs才能自增完，除以1小时共有多少µs便可算出2^324 /(1606010001000)=4.772185884 ） 而一个段在网络中并不会比最大分段寿命（Maximum Segment Lifetime (MSL) ，默认使用2分钟）长，MSL 比4.55小时要短，所以我们可以认为 ISN 会是唯一的。 发送方与接收方都会有自己的 ISN （下面的例子中就是 X 与 Y）来做双方互发通信，具体的描述如下： 1 A –&gt; B SYN my sequence number is X2 A &lt;– B ACK your sequence number is X3 A &lt;– B SYN my sequence number is Y4 A –&gt; B ACK your sequence number is Y 2与3都是 B 发送给 A，因此可以合并在一起，因此成为three way (or three message) handshake（其实翻译为三步握手，或者是三次通信握手更为准确） 因此最终可以得出，三次握手是必须的： A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN’s. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3]. 三次握手（A three way handshake）是必须的， 因为 sequence numbers（序列号）没有绑定到整个网络的全局时钟（全部统一使用一个时钟，就可以确定这个包是不是延迟到的）以及 TCPs 可能有不同的机制来选择 ISN（初始序列号）。 接收方接收到第一个 SYN 时，没有办法知道这个 SYN 是是否延迟了很久了，除非他有办法记住在这条连接中，最后接收到的那个sequence numbers（然而这不总是可行的）。 这句话的意思是：一个 seq 过来了，跟现在记住的 seq 不一样，我怎么知道他是上条延迟的，还是上上条延迟的呢？ 所以，接收方一定需要跟发送方确认 SYN。 假设不确认 SYN 中的 SEQ，那么就只有： 1 A –&gt; B SYN my sequence number is X2 A &lt;– B ACK your sequence number is X SYN my sequence number is Y 只有B确认了收到了 A 的 SEQ， A 无法确认收到 B 的。也就是说，只有 A 发送给 B 的包都是可靠的， 而 B 发送给 A 的则不是，所以这不是可靠的连接。这种情况如果只需要 A 发送给 B ，B 无需回应，则可以不做三次握手。 所以，正确的类比应该是这样的： TCP 传递信息可以理解为美国与中国用货船来传货物，但因为一首轮船穿放不下，货物要分开一只只轮船来发货。所以需要一个序列号来识别该货物是第几个，以便到达后将其拼接回原来的货物。因为同一条航道（也就是 tcp连接）上，可能会有多批货物发送（复用 tcp 连接）。发货时，双方需要通知对方这个序列号是从哪里开始（init seq）的，这样才能辨识过来的是不是一个对的货物，以及能拼接成完整的货物。 货物运输拼接（tcp）最重要的是可靠性，如果没有用三次握手来确认双方都可以获得对方的 序列号（seq）的话，就无法知道当前航班（连接）中，对的货物序号是怎么样的了。 三次握手详细过程 TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT –&gt; &lt;SEQ=100&gt;&lt;CTL=SYN&gt; –&gt; SYN-RECEIVED 3. ESTABLISHED &lt;– &lt;SEQ=300&gt;&lt;ACK=101&gt;&lt;CTL=SYN,ACK&gt; &lt;– SYN-RECEIVED 4. ESTABLISHED –&gt; &lt;SEQ=101&gt;&lt;ACK=301&gt;&lt;CTL=ACK&gt; –&gt; ESTABLISHED 5. ESTABLISHED –&gt; &lt;SEQ=101&gt;&lt;ACK=301&gt;&lt;CTL=ACK&gt;&lt;DATA&gt; –&gt; ESTABLISHED Basic 3-Way Handshake for Connection SynchronizationFigure 7. 在上图 第二行中， A 发送了 SEQ 100，标志位是 SYN. 第三行，B 发回了 ACK 101 与 SEQ 300，标志位是 SYN 与 ACK（两个过程合并了）。注意，ACK 是101意味着，B 希望接收到 101序列号开始的数据段。 第四行，A 返回了空的数据，SEQ 101， ACK 301，标志位为 ACK。至此，双方的开始 SEQ （也就是 ISN）号100与300都被确认接收到了。 第五行，开始正式发送数据包，注意的是 ACK 依旧是第四行的301，因为没有需要 ACK 的 SYN 了（第四行已经 ACK 完）。 以上，4 最后这个确认的过程，是可以带上数据的。 The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.To deal with this, a special control message, reset, has been devised.If the receiving TCP is in a non-synchronized state (i.e., SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user. We discuss this latter case under “half-open” connections below. 三次握手的原则设计是防止旧复用链接的初始化导致问题，为了解决此问题，我们设计了reset这个特别的控制信号来处理。 如果接收中的 TCP 在一个未同步状态如 SYN-SENT, SYN-RECEIVED，它会返回 reset 给对方。 如果 TCP 是同步状态中如(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT)，他会终止此连接并通知用户。 看起来有点绕，我们举个图例看看： TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT –&gt; &lt;SEQ=100&gt;&lt;CTL=SYN&gt; … 3. (duplicate) … &lt;SEQ=90&gt;&lt;CTL=SYN&gt; –&gt; SYN-RECEIVED 4. SYN-SENT &lt;– &lt;SEQ=300&gt;&lt;ACK=91&gt;&lt;CTL=SYN,ACK&gt; &lt;– SYN-RECEIVED 5. SYN-SENT –&gt; &lt;SEQ=91&gt;&lt;CTL=RST&gt; –&gt; LISTEN 6. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&emsp;&emsp;&emsp;&emsp; … &lt;SEQ=100&gt;&lt;CTL=SYN&gt; –&gt; SYN-RECEIVED 7. SYN-SENT &lt;– &lt;SEQ=400&gt;&lt;ACK=101&gt;&lt;CTL=SYN,ACK&gt; &lt;– SYN-RECEIVED 8. ESTABLISHED –&gt; &lt;SEQ=101&gt;&lt;ACK=401&gt;&lt;CTL=ACK&gt; –&gt; ESTABLISHED Recovery from Old Duplicate SYN 这是 复用连接时，旧在途包发往新连接中的例子。 3中，一个旧的重复的 SYN到达 B。 4中， B分别不出是否旧的，照样子正常回包。 5中，A检测到 B 返回的ACK不正确，所以返回 RST(reset) 6中，B接收到 RST(reset)信号，于是变成 LISTEN 状态。 7中，新连接正常的 SYN终于到达了，三次握手正常进行。 这种是简化的情况，但是可以看出 TCP 是如何处理复用旧链接的包到达的。 RefTCP 为什么是三次握手，而不是两次或四次？ TCP 三向交握 (Three-way Handshake) 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"TCP","slug":"tcp","permalink":"http://agehua.github.io/tags/tcp/"}]},{"title":"Android App Bundle(AAB) 文件介绍","slug":"Android-APP-Bundles-Introduction","date":"2019-03-26T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/03/27/Android-APP-Bundles-Introduction/","link":"","permalink":"http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/","excerpt":"在2018年的Google I/O大会上，Google向 Android 引入了新 App 动态化框架（即Android App Bundle，缩写为AAB）","text":"在2018年的Google I/O大会上，Google向 Android 引入了新 App 动态化框架（即Android App Bundle，缩写为AAB） 关于Android App BundlesAndroid App Bundle 是一种包含编译后代码和资源文件的新的上传格式（.aab），它推迟了APK的生成和签名，由google play来完成 Google Play推出新app交付模式，叫做动态交付 (Dynamic Delivery)，它根据每个用户的设备信息，使用开发者上传的app bundle来生成对应的apk文件使用aab文件会将apk的大小限制增加到500MB，这个限制不是指aab文件的大小，而是下载apk时的大小此外，也可以在app bundle中添加dynamic feature modules。这些模块可以包含新的功能和资源。开发者可以决定用户第一次安装时需不需要下载这些资源构建一个Android App Bundle，只需要几次点击，但是添加dynamic feature模块，可能需要重构整个项目 Android App Bundle != APKApp Bundle 纯粹是为了上传设计的文件，用户无法直接安装和使用它。它是一个 zip 文件，Google Play 从中生成优化的 APK 并将其提供给设备进行安装从 APK 切换到App Bundle是一个无缝过程 Get started构建 app bundles和支持动态交付，需要下面几步： 1.Android Studio 3.2 or higher 2.支持动态交付，需要包含一个base module，重新组织代码和资源，生成configuration APKs，此外可以添加 dynamic feature模块 3.生成 aab 文件（使用 AS 或 命令行工具） 4.使用 bundletool 来测试aab生成apk或发布到测试机上 5.使用 Google Play 应用签名要使用推荐的应用发布格式 Android App Bundle，您需要先注册 Google Play 应用签名，然后才能在 Play Console上传您的 app bundle 文件。 6.上传Play Console Split APKsSplit APKs是Android 5.0开始提供多apk构建机制，是 Dynamic Delivery 功能的最基本组件。 Split APKs将原来一个APK中多个模块共享同一份资源的模型，分离成多个APK使用各自的资源，并且可以继承Base APK中的资源，多个APK有相同的data，cache目录，多个dex文件，相同的进程，在Settings.apk中只显示一个APK，并且使用相同的包名。 Split APK可以将一个庞大的APK，按屏幕密度，ABI等形式拆分成多个独立的APK，在应用程序更新时，不必下载整个APK，只需单独下载某个模块即可安装更新。 Base apks: 包含了一些基本功能，和其他split apks公用的资源和代码。Google play从你的项目的 app module来生成base apk。当用户请求下载完整apk时，base apk是第一个被下载和安装的。 如果你想减少初始下载的大小，那就需要减少你的 app module 的代码 Configuration apks: 包括不同的 native 代码，特定屏幕尺寸，CPU架构或者多语言。每当用户要下载这个应用的时候，只会下载真正对应其设备信息的apk。配置apk不用单独的新建 module，google play会自动生成对应apk Dynamic feature apks: 每个apk包含一个特性，对应一个module。Play Core Library负责为用户按需安装这些特性。这个 Dynamic feature 不是第一次安装需要的，Google play 从Dynamic feature module来生成动态特性apk文件 下图描述了为了提供一个完整app体验，Split Apks产生的依赖结构，并可能会在同一个设备上安装多个apk文件。 Devices running Android 4.4 (API level 19) and lowerAndroid 4.4 及以下设备并不支持下载和安装Split APKs。 Google Play提供一个根据设备信息优化后的apk文件，叫做multi-APK对于多语言，multi-APK会包含所有支持的语音，避免切换手机语言后还要下载对应语言的apk问题multi-APK不支持按需下载动态特性（dynamic features），所以在创建dynamic features模块的时候，需要考虑是否禁用按需下载或打开Fusing The Android App Bundle formatAndroid App Bundle 是一种发布格式 —— 精确地说，是一个带有 .aab 扩展名的 zip 文件。它包含应用支持的所有设备的代码和资源，例如 DEX 文件、本地代码库、清单文件、各种资源文件等 注意：每个APP bundle对应一个独立的app或applicationID。因此，如果你使用了product flavors来创建不同版本的app，并且每个版本app都对应一个不同的applicationID，那你就需要为每个app构建一个app bundle 蓝色方框区域就是configuration apks支持的配置项 Play Core LibraryPlay Core Library是AAB提供的核心库，用于下载、安装dynamic feature模块。Android studio3.3 开始也支持为 Instant apps 按需下载模块 在Android Studio上选择 New -&gt; Module -&gt; 选择 Instant Dynamic Feature Module，会自动创建一个 Instant Module，对应的 AndroidManifest.xml 文件内容如下：&lt;manifest xmlns:android=\"http://schemas.android.com/apk/res/android\" xmlns:dist=\"http://schemas.android.com/apk/distribution\" package=\"com.google.android.samples.instantdynamicfeatures\"&gt; &lt;!-- The dist:instant=\"true\" makes this module instant enabled. Assuming the \"app\" module is also instant enabled, when this bundle is uploaded to the instant track on the Google Play Developer Console, this module will be included in the instant app. Any non instant enabled modules will be excluded --&gt; &lt;dist:module dist:instant=\"true\" dist:onDemand=\"false\" dist:title=\"@string/module_instant_feature_split_install\"&gt; &lt;dist:fusing dist:include=\"true\" /&gt; &lt;/dist:module&gt; &lt;application&gt; &lt;activity android:name=\"com.google.android.samples.instantdynamicfeatures.SplitInstallInstantActivity\"&gt;&lt;/activity&gt; &lt;/application&gt;&lt;/manifest&gt; Bundletool 介绍Bundletool 是一个用于处理 Android App Bundle 的命令行工具。使用 bundletool，您可以构建 AAB，提取连接的设备配置，生成 APK Set 文件 (.apks)，从 APK Set 文件中提取或安装 APK，以及验证App Bundle。由于 AAB 仅是一种发布格式，因此 bundletool 用于生成和测试 APK。 用Bundletool工具测试AAB 1.安装bundletool： brew install bundletool 2.切换到aab所在文件夹，生成 apks 文件bundletool build-apks --bunlde=&lt;bundle_name&gt;.aab --output=./&lt;bundle_name&gt;.apks 3.如果要build签名的apks文件，则需要加上keystore设置bundletool build-apks --bundle=&lt;bundle_name&gt;.aab --output=&lt;bundle_name&gt;.apks --ks=&lt;your_keystorename&gt;.jks/.keystore --ks-pass=pass:&lt;your_keystore_pass&gt; --ks-key-alias=&lt;your_keystore_alias&gt; --key-pass=pass:&lt;your_keystore_pass&gt; 4.将apks安装在设备上bundletool install-apks --apks=&lt;bundle_name&gt;.apks 另外介绍两个有用的功能： 输出当前设备对应的设备信息bundletool get-device-spec --output=tcl.json --adb=/Library/Android_sdk/platform-tools/adb 生成当前设备对应的apksbundletool build-apks --connected-device --bundle=app.aab --output=./app1.apks --adb=/Library/Android_sdk/platform-tools/adb Compressed download size restriction App首次下载安装，整个app（比如 base.apk+configuration.apk）大小不能超过 150MB 后续按需下载，每次也不能超过150MB Android App Bundles不支持apk扩展文件（*.obb） OBB（Opaque Binary Blob）文件格式，是安卓游戏通用数据包。在一些大型游戏上较为常见，同时还附以Data文件，亦或是md5.dat文件出现。通常在游戏开始前，程序会自动将obb解包/sdcard/Android/obb 目录下。但也有游戏不会解包，直接读取。 Merits and demeritsBenifit of App Bundle Size更小（最高可以减少50%应用体积） 安装更快 （ base.apk + split apks） Android App Bundle 是单一工件，因此无需构建、签名或管理多个 APK 支持动态发布(为特定用户添加动态功能，而无需增加安装时的应用体积) 官方提供的系统级插件化方案 Limitations and costs 仅限于通过 Google Play 发布的应用，（Google进一步巩固自身生态） 需要加入到 Google 的 beta program 最低支持版本Android 5.0 (API level 21) 低于Android 5.0 (API level 21) 的版本GooglePlay会优化Size，但不支持动态交付。 需要升级到Android Studio 3.2以上，修改工程结构以便支持App Bundle格式 集成Play Core Library Known issues 不支持动态修改resource tables 在dynamic feature 模块的清单文件里，不能引用不在base模块里的资源 在AS中，更改base模块的 build variant，并不会自动更改依赖base的其他模块，所以构建时可能会报错 不同模块 build configuration 不同，可能会有冲突，导致构建或运行时出错，比如 buildTypes.release.debuggable = true 由于AAB可能包含多个apk文件，所以在把apk发送到设备时可能会因找不到资源，导致运行时异常，比如 adb刷机（ sideloading ） 动态下载模块需要安装最新的Play Store app，所以有很小概率下载app时会回滚为下载一个multi-APK（为 Android 4.4以下设备提供） RefBundleTool Github地址 简书-Android动态化框架App Bundles 爱奇艺组件化探索之原理篇 【Android】函数插桩（Gradle + ASM） 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android APP Bundles","slug":"android-app-bundles","permalink":"http://agehua.github.io/tags/android-app-bundles/"}]},{"title":"Android避免网络请求造成内存泄漏","slug":"Android-request-memory-leaks","date":"2019-01-25T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/01/26/Android-request-memory-leaks/","link":"","permalink":"http://agehua.github.io/2019/01/26/Android-request-memory-leaks/","excerpt":"现在的网络请求框架很多也很完善，但是使用中不注意还是会有内存泄漏的现象。为了避免内存泄漏，大概有两种方式：\n\n1.在Activity结束时取消请求\n2.在异步回调的时候，通过Activity.isFinishing()方法判断Activity是否已经被销毁\n\n但是最近在工作中，发现一个问题：同一个请求，会在多个页面被调用到，这就导致相同的代码包括发送请求，成功或失败回调，数据解析等会出现好几处。如果我想把这个网络请求单独抽离出来，放到一个类里，不依赖具体的Activity，现在的网络框架回调一般都会运行在主线程，如果未及时释放资源，很容易造成内存泄漏。","text":"现在的网络请求框架很多也很完善，但是使用中不注意还是会有内存泄漏的现象。为了避免内存泄漏，大概有两种方式： 1.在Activity结束时取消请求 2.在异步回调的时候，通过Activity.isFinishing()方法判断Activity是否已经被销毁 但是最近在工作中，发现一个问题：同一个请求，会在多个页面被调用到，这就导致相同的代码包括发送请求，成功或失败回调，数据解析等会出现好几处。如果我想把这个网络请求单独抽离出来，放到一个类里，不依赖具体的Activity，现在的网络框架回调一般都会运行在主线程，如果未及时释放资源，很容易造成内存泄漏。 针对这种方式，可以采用EventBus，来发送包含解析后的数据到对应的Activity，在Activity onDestroy里取消EventBus监听。但是如果使用postSticky发送事件，会导致事件接收混乱。 为了真的实现这种需求，参考网上的一篇文章：如何在Activity/Fragment结束时处理异步回调？ 基于Lifeful接口的异步回调框架Lifeful接口设计我们定义Lifeful，一个不依赖于Context、也不依赖于PATH的接口。 /** * 判断生命周期是否已经结束的一个接口。 */public interface Lifeful &#123; /** * 判断某一个组件生命周期是否已经走到最后。一般用于异步回调时判断Activity或Fragment生命周期是否已经结束。 * * @return */ boolean isAlive();&#125; 实际上，我们只需要让具有生命周期的类(一般是Activity或Fragment)实现这个接口，然后再通过这个接口来判断这个实现类是否还存在，就可以与Context解耦了。 接下来定义一个接口生成器，通过弱引用包装Lifeful接口的实现类，并返回所需要的相关信息。/** * 生命周期具体对象生成器。 */public interface LifefulGenerator&lt;Callback&gt; &#123; Callback getCallback(); WeakReference&lt;Lifeful&gt; getLifefulWeakReference(); boolean isLifefulNull();&#125; 提供一个该接口的默认实现：/** * 默认生命周期管理包装生成器。 */public class DefaultLifefulGenerator&lt;Callback&gt; implements LifefulGenerator&lt;Callback&gt; &#123; private WeakReference&lt;Lifeful&gt; mLifefulWeakReference; private boolean mLifefulIsNull; private Callback mCallback; public DefaultLifefulGenerator(Callback callback, Lifeful lifeful) &#123; mCallback = callback; mLifefulWeakReference = new WeakReference&lt;&gt;(lifeful); mLifefulIsNull = lifeful == null; &#125; @Override public Callback getCallback() &#123; return mCallback; &#125; public WeakReference&lt;Lifeful&gt; getLifefulWeakReference() &#123; return mLifefulWeakReference; &#125; @Override public boolean isLifefulNull() &#123; return mLifefulIsNull; &#125;&#125; 接着通过一个静态方法判断是否对象的生命周期：/** * 生命周期相关帮助类。 */public class LifefulUtils &#123; private static final String TAG = LifefulUtils.class.getSimpleName(); public static &lt;T&gt; boolean shouldGoHome(LifefulGenerator&lt;T&gt; lifefulGenerator, boolean objectIsNull) &#123; WeakReference&lt;Lifeful&gt; lifefulWeakReference = lifefulGenerator.getLifefulWeakReference(); if (lifefulWeakReference == null) &#123; Log.e(TAG, \"Go home, lifefulWeakReference == null\"); return true; &#125; Lifeful lifeful = lifefulWeakReference.get(); if (null == lifeful &amp;&amp; !objectIsNull) &#123; return true; &#125; if (null != lifeful &amp;&amp; !lifeful.isAlive()) &#123; lifefulGenerator.setCallback(null); // 取消持有的callback return true; &#125; return false; &#125; public static &lt;T&gt; boolean shouldGoHome(LifefulGenerator&lt;T&gt; lifefulGenerator) &#123; if (null == lifefulGenerator) &#123; Log.e(TAG, \"Go home, null == lifefulGenerator\"); return true; &#125; if (null == lifefulGenerator.getCallback()) &#123; Log.e(TAG, \"Go home, null == lifefulGenerator.getCallback()\"); return true; &#125; return shouldGoHome(lifefulGenerator, lifefulGenerator.isLifefulNull()); &#125;&#125; 具有生命周期的Runnable具体到跟线程打交道的异步类，只有Runnable(Thread也是其子类)，因此只需要处理Runnable就可以了。我们可以通过Wrapper包装器模式，在处理真正的Runnable类之前，先通过Lifeful接口判断对象是否还存在，如果不存在则直接返回。对于Runnable：/** * 与周期相关的异步线程回调类。 */public class LifefulRunnable implements Runnable &#123; private LifefulGenerator&lt;Runnable&gt; mLifefulGenerator; public LifefulRunnable(Runnable runnable, Lifeful lifeful) &#123; mLifefulGenerator = new DefaultLifefulGenerator&lt;&gt;(runnable, lifeful); &#125; @Override public void run() &#123; if (LifefulUtils.shouldGoHome(mLifefulGenerator)) &#123; return; &#125; mLifefulGenerator.getCallback().run(); &#125;&#125; Lifeful的实现类最后说一下Lifeful类的实现类，主要包括Activity和Fragment，public class BaseActivity extends Activity implements Lifeful &#123; @Override public boolean isAlive() &#123; return activityIsAlive(); &#125; public boolean activityIsAlive() &#123; if (currentActivity == null) return false; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.JELLY_BEAN_MR1) &#123; return !(currentActivity.isDestroyed() || currentActivity.isFinishing()); &#125; else &#123; return !currentActivity.isFinishing(); &#125; &#125;&#125;public class BaseFragment extends Fragment implements Lifeful &#123; @Override public boolean isAlive() &#123; return activityIsAlive(); &#125; public boolean activityIsAlive() &#123; Activity currentActivity = getActivity(); if (currentActivity == null) return false; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.JELLY_BEAN_MR1) &#123; return !(currentActivity.isDestroyed() || currentActivity.isFinishing()); &#125; else &#123; return !currentActivity.isFinishing(); &#125; &#125;&#125; 除了这两个类以外，别的类如果有生命周期，或者包含生命周期的引用，也可以实现Lifeful接口(如View，可以通过onAttachedToWindow()和onDetachedToWindow())。 包含生命周期的异步调用对于需要用到异步的地方，调用也很方便。 // ThreadCore是一个用于线程调度的ThreadPoolExecutor封装类，也用于主线程和工作线程之间的切换ThreadCore.getInstance().postOnMainLooper(new LifefulRunnable(new Runnable() &#123; @Override public void run() &#123; // 实现真正的逻辑。 &#125;&#125;, this)); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/01/26/Android-request-memory-leaks/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Memory leaks","slug":"memory-leaks","permalink":"http://agehua.github.io/tags/memory-leaks/"},{"name":"net request","slug":"net-request","permalink":"http://agehua.github.io/tags/net-request/"}]},{"title":"Android录音相关方法介绍","slug":"Android-audio-introduction","date":"2018-12-05T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2018/12/06/Android-audio-introduction/","link":"","permalink":"http://agehua.github.io/2018/12/06/Android-audio-introduction/","excerpt":"本文介绍Android开发录音功能中用到的相关API和音频数据编码解码的处理\n录音基础知识常用音频格式：\n\nWAV 格式：音质高 无损格式 体积较大\nAAC（Advanced Audio Coding） 格式：相对于 mp3，AAC 格式的音质更佳，文件更小，有损压缩，一般苹果或者Android SDK4.1.2（API 16）及以上版本支持播放,性价比高\nAMR 格式：压缩比比较大，但相对其他的压缩格式质量比较差，多用于人声，通话录音\nAMR分类:  AMR(AMR-NB): 语音带宽范围：300－3400Hz，8KHz抽样\n\n\nmp3 格式：特点 使用广泛， 有损压缩，牺牲了12KHz到16KHz高音频的音质","text":"本文介绍Android开发录音功能中用到的相关API和音频数据编码解码的处理 录音基础知识常用音频格式： WAV 格式：音质高 无损格式 体积较大 AAC（Advanced Audio Coding） 格式：相对于 mp3，AAC 格式的音质更佳，文件更小，有损压缩，一般苹果或者Android SDK4.1.2（API 16）及以上版本支持播放,性价比高 AMR 格式：压缩比比较大，但相对其他的压缩格式质量比较差，多用于人声，通话录音 AMR分类: AMR(AMR-NB): 语音带宽范围：300－3400Hz，8KHz抽样 mp3 格式：特点 使用广泛， 有损压缩，牺牲了12KHz到16KHz高音频的音质 音频开发的具体内容 音频采集/播放 音频算法处理（去噪、静音检测、回声消除、音效处理、功放/增强、混音/分离，等等） 音频的编解码和格式转换 音频传输协议的开发（SIP，A2DP、AVRCP，等等） 录音API: AudioRecordAudioRecord是相对MediaRecord更为底层的API，使用AudioRecord也可以很方便的完成录音功能。AudioRecord录音录制的是原始的PCM音频数据，可以使用AudioTrack来播放PCM音频文件。 先看下AudioRecord的构造函数，/** * @param audioSource ：录音源 * 这里选择使用麦克风：MediaRecorder.AudioSource.MIC * @param sampleRateInHz： 采样率 * @param channelConfig：声道数 * @param audioFormat： 采样位数. * See &#123;@link AudioFormat#ENCODING_PCM_8BIT&#125;, &#123;@link AudioFormat#ENCODING_PCM_16BIT&#125;, * and &#123;@link AudioFormat#ENCODING_PCM_FLOAT&#125;. * @param bufferSizeInBytes： 音频录制的缓冲区大小 * See &#123;@link #getMinBufferSize(int, int, int)&#125;*/AudioRecord(int audioSource, int sampleRateInHz, int channelConfig, int audioFormat, int bufferSizeInBytes) \b可以看到构造函数需要 5 个参数，最后一个参数bufferSizeInBytes，获取方式为：private int channelCount=2; //音频采样通道，默认2通道bufferSize = AudioRecord.getMinBufferSize(sampleRate, channelConfig, audioFormat)*2; // 5.录音过程中音频缓冲空间大小 (码率) 初始化完成后，就可以开始录制：//实例化AudioRecordmRecorder=new AudioRecord(MediaRecorder.AudioSource.MIC,sampleRate,channelConfig, audioFormat,bufferSize);private FileOutputStream fos; //用于保存录音文件//开始录制mRecorder.startRecording();byte[] byteBuffer = new byte[bufferSize];while (state == RecordState.RECORDING) &#123; // //循环读取数据到buffer中，并保存buffer中的数据到文件中 int end = audioRecord.read(byteBuffer, 0, byteBuffer.length); notifyData(byteBuffer); fos.write(byteBuffer, 0, end); fos.flush();&#125;mRecorder.stop();//暂停录制 更新 RecordState 状态就可以退出 while循环，结束录制 /** * 表示当前状态 */public enum RecordState &#123; /** * 空闲状态 */ IDLE, /** * 录音中 */ RECORDING, /** * 暂停中 */ PAUSE, /** * 正在停止 */ STOP, /** * 录音流程结束（转换结束） */ FINISH&#125; 计算合适码率不同的设备可以支持的采样率不同，根据采样率从大到小计算 bufferSizepublic void getValidBufferSize() &#123; for (int rate : new int[]&#123;44100, 22050, 11025, 16000, 8000&#125;) &#123; // add the rates you wish to check against int bufferSize = AudioRecord.getMinBufferSize(rate, AudioFormat.CHANNEL_CONFIGURATION_DEFAULT, AudioFormat.ENCODING_PCM_16BIT); if (bufferSize &gt; 0) &#123; audioRecord = new AudioRecord(MediaRecorder.AudioSource.VOICE_COMMUNICATION, currentConfig.getSampleRate(), currentConfig.getChannelConfig(), currentConfig.getEncodingConfig(), bufferSize); return; &#125; &#125;&#125; 根据码率计算已录制时间Stack Overflow上有回答：Calculate elapsed time from AudioRecord上面提到 AudioRecord的最后一个参数就是码率： 码率 = 采样频率 采样位数 声道个数； 例：采样频率44.1KHz，量化位数16bit，立体声(双声道)，未压缩时的码率 = 44.1KHz 16 2 = 1411.2Kbps = 176.4KBps，即每秒要录制的资源大小, 理论上码率和质量成正比对应时间的计算方式应该是：已录制时长(单位是秒) = dataSize/(getEncoding()*getChannelCount()*44100) /** * 获取当前录音的采样位宽 单位bit * * @return 采样位宽 0: error */public int getEncoding() &#123; if (encodingConfig == AudioFormat.ENCODING_PCM_8BIT) &#123; return 8; &#125; else if (encodingConfig == AudioFormat.ENCODING_PCM_16BIT) &#123; return 16; &#125; else &#123; return 0; &#125;&#125;/** * 当前的声道数 * * @return 声道数： 0：error */public int getChannelCount() &#123; if (channelConfig == AudioFormat.CHANNEL_IN_MONO) &#123; return 1; &#125; else if (channelConfig == AudioFormat.CHANNEL_IN_STEREO) &#123; return 2; &#125; else &#123; return 0; &#125;&#125; 按照上面的步骤，我们就能成功的录制PCM音频文件了，但是处于传输和存储方面的考虑，一般来说，我们是不会直接录制PCM音频文件的。而是在录制过程中就对音频数据进行编码为aac、mp3、wav等其他格式的音频文件 关于录制pcm，mp3格式，详细可以看这篇文章：Android音频开发（1）：音频基础知识 AAC格式介绍AAC（高级音频编码技术 Advanced Audio Coding)，出现于1997年，是基于MPEG-2的音频编码技术。由Fraunhofer IIS、杜比、苹果、AT&amp;T、索尼等公司共同开发，以取代mp3格式。2000年，MPEG-4标准出台，AAC从新整合了其特性，故现又称MPEG-4 AAC，即m4a。 作为一种高压缩比的音频压缩算法，AAC通常压缩比为18：1，也有资料说为20：1，远胜mp3，而音质由于采用多声道，和使用低复杂性的描述方式，使其比几乎所有的传统编码方式在同规格的情况下更胜一筹。不过直到2006年，使用这一格式储存音频的并不多，可以播放该格式的mp3播放器更是少之又少，目前所知仅有苹果iPod，而手机支持AAC的相对要多一些，此外电脑上很多音频播放软件都支持AAC格式，如苹果iTunes。AAC所采用的运算法则 AAC所采用的运算法则与MP3的运算法则有所不同，AAC通过结合其他的功能来提高编码效率。AAC的音频算法在压缩能力上远远超过了以前的一些压缩算法（比如MP3等）。它还同时支持多达48个音轨、15个低频音轨、更多种采样率和比特率、多种语言的兼容能力、更高的解码效率。号称「最大能容纳48通道的音轨，采样率达96 KHz，并且在320Kbps的数据速率下能为5.1声道音乐节目提供相当于ITU-R广播的品质」。 总之，AAC可以在比MP3文件节省大约30%的储存空间与带宽的前提下提供更好的音质。但是在空间上和结构上AAC和mp3编码出来后的风格不太一样，喜欢与否属于仁者见仁智者见智的事情。 硬件编解码API: MediaCodecMediaCodec 是 Android 提供的可以访问底层解码和编码Media的组件，它是 Android 底层多媒体支持框架的一部分 下图是Android官方提供的MediaCodec工作流程： 针对于上图，我们可以把InputBuffers和OutputBuffers简单的理解为它们共同组成了一个环形的传送带，传送带上铺满了空盒子。编解码开始后，我们需要得到一个空盒子（dequeueInputBuffer），然后往空盒子中填充原料（需要被编/解码的音/视频数据），并且放回到传送带你取出时候的那个位置上面（queueInputBuffer）。传送带经过处理器（Codec）后，盒子里面的原料被加工成了你所期望的东西（编解码后的数据），你就可以按照你放入原料时候的顺序，连带着盒子一起取出加工好的东西（dequeueOutputBuffer），并将取出来的东西贴标签（加数据头之类的非必须）和装箱（组合编码后的帧数据）操作，同样之后也要把盒子放回到原来的位置（releaseOutputBuffer） 初始化编码器实例public void initAudioEncoder(RecordConfig recordConfig)&#123; aBufferInfo = new MediaCodec.BufferInfo(); audioQueue = new LinkedBlockingQueue&lt;&gt;(); audioCodecInfo = selectCodec(AUDIO_MIME_TYPE); if (audioCodecInfo == null) &#123; return; &#125; // 取到前面录音时的相关配置 int sampleRate = recordConfig.getSampleRate(); int pcmFormat = recordConfig.getEncoding(); int chanelCount = recordConfig.getChannelCount(); audioFormat = MediaFormat.createAudioFormat(AUDIO_MIME_TYPE, sampleRate, chanelCount); audioFormat.setInteger(MediaFormat.KEY_AAC_PROFILE, MediaCodecInfo.CodecProfileLevel.AACObjectLC); audioFormat.setInteger(MediaFormat.KEY_CHANNEL_MASK, AudioFormat.CHANNEL_IN_STEREO);//CHANNEL_IN_STEREO 立体声 int bitRate = sampleRate * pcmFormat * chanelCount; audioFormat.setInteger(MediaFormat.KEY_BIT_RATE, bitRate); audioFormat.setInteger(MediaFormat.KEY_CHANNEL_COUNT, chanelCount); audioFormat.setInteger(MediaFormat.KEY_SAMPLE_RATE, sampleRate); if (aEncoder != null) &#123; return; &#125; try &#123; // 创建音频编码器 aEncoder = MediaCodec.createEncoderByType(AUDIO_MIME_TYPE); &#125; catch (IOException e) &#123; e.printStackTrace(); throw new RuntimeException(\"初始化音频编码器失败\", e); &#125;&#125;private MediaCodecInfo selectCodec(String mimeType) &#123; int numCodecs = MediaCodecList.getCodecCount(); for (int i = 0; i &lt; numCodecs; i++) &#123; MediaCodecInfo codecInfo = MediaCodecList.getCodecInfoAt(i); if (!codecInfo.isEncoder()) &#123; continue; &#125; String[] types = codecInfo.getSupportedTypes(); for (int j = 0; j &lt; types.length; j++) &#123; if (types[j].equalsIgnoreCase(mimeType)) &#123; return codecInfo; &#125; &#125; &#125; return null;&#125; 解码器开始工作//之前的音频录制是直接循环读取，然后写入文件，这里需要做编码处理再写入文件//这里的处理就是和之前传送带取盒子放原料的流程一样private void startAudioEncode() &#123; audioEncoderThread = new Thread() &#123; // 注意一般在子线程中循环处理 @Override public void run() &#123; Log.d(TAG, \" 编码线程 启动...\"); presentationTimeUs = System.currentTimeMillis() * 1000; aEncoderEnd = false; aEncoder.configure(audioFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); aEncoder.start(); while (audioEncoderLoop &amp;&amp; !Thread.interrupted()) &#123; try &#123; byte[] data = audioQueue.take(); // 从队列中取得数据，这个队列在下面有解释 encodeAudioData(data); &#125; catch (InterruptedException e) &#123; e.printStackTrace(); break; &#125; &#125; if (aEncoder != null) &#123; //停止音频编码器 aEncoder.stop(); //释放音频编码器 aEncoder.release(); aEncoder = null; &#125; audioQueue.clear(); Log.d(TAG, \"= =lgd= ==Audio 编码线程 退出...\"); &#125; &#125;; audioEncoderLoop = true; audioEncoderThread.start();&#125;/*** 从队列中取得数据，并编码为 AAC 格式* @param input*/private void encodeAudioData(byte[] input)&#123; try &#123; //拿到输入缓冲区,用于传送数据进行编码 ByteBuffer[] inputBuffers = aEncoder.getInputBuffers(); //首先通过dequeueInputBuffer(long timeoutUs)请求一个输入缓存，timeoutUs代表等待时间，设置为-1代表无限等待 int inputBufferIndex = aEncoder.dequeueInputBuffer(-1); if (inputBufferIndex &gt;= 0) &#123; ByteBuffer inputBuffer = inputBuffers[inputBufferIndex]; //使用之前要clear一下，避免之前的缓存数据影响当前数据 inputBuffer.clear(); //把数据添加到输入缓存中， inputBuffer.put(input); //并调用queueInputBuffer()把缓存数据入队 aEncoder.queueInputBuffer(inputBufferIndex, 0, input.length, 0, 0); &#125; //拿到输出缓冲区,用于取到编码后的数据 ByteBuffer[] outputBuffers = aEncoder.getOutputBuffers(); //拿到输出缓冲区的索引 int outputBufferIndex = aEncoder.dequeueOutputBuffer(aBufferInfo, TIMEOUT_USEC); ByteBuffer outputBuffer; int outBitSize; int outPacketSize; byte[] chunkAudio; while (outputBufferIndex &gt;= 0) &#123; outBitSize = aBufferInfo.size; //添加ADTS头,ADTS头包含了AAC文件的采样率、通道数、帧数据长度等信息。 outPacketSize = outBitSize + 7;//7为ADTS头部的大小 outputBuffer = outputBuffers[outputBufferIndex];//拿到输出Buffer outputBuffer.position(aBufferInfo.offset); outputBuffer.limit(aBufferInfo.offset + outBitSize); chunkAudio = new byte[outPacketSize]; addADTStoPacket(chunkAudio, outPacketSize); // 给编码出的aac裸流添加adts头字段 outputBuffer.get(chunkAudio, 7, outBitSize);//将编码得到的AAC数据 取出到byte[]中偏移量offset=7 outputBuffer.position(aBufferInfo.offset); if (null != mCallback) &#123; mCallback.outputAudioData(chunkAudio, chunkAudio.length, (int) aBufferInfo.presentationTimeUs / 1000); &#125; //releaseOutputBuffer方法必须调用 aEncoder.releaseOutputBuffer(outputBufferIndex, false); outputBufferIndex = aEncoder.dequeueOutputBuffer(aBufferInfo, 10000); &#125; &#125; catch (Exception t) &#123; Log.e(TAG, \" =encodeAudioData=====error: \" + t.toString()); &#125;&#125; 上面的audioQueue 是一个链表 LinkedBlockingQueue&lt;byte[]&gt;。它的作用是由 audioRecord.read(byteBuffer, 0, byteBuffer.length) 获取录音数据，放入队列/** * 放入音频数据 * @param data */public void putAudioData(byte[] data) &#123; try &#123; audioQueue.put(data); &#125; catch (InterruptedException e) &#123; e.printStackTrace(); &#125;&#125; 给编码出的aac裸流添加adts头字段/** * 添加ADTS头 * * @param packet 要空出前7个字节，否则会搞乱数据 * @param packetLen */private void addADTStoPacket(byte[] packet, int packetLen) &#123; int profile = 2; // AAC LC int freqIdx = 8; // 44.1KHz int chanCfg = 1; // CPE // fill in ADTS data packet[0] = (byte) 0xFF; packet[1] = (byte) 0xF9; packet[2] = (byte) (((profile - 1) &lt;&lt; 6) + (freqIdx &lt;&lt; 2) + (chanCfg &gt;&gt; 2)); packet[3] = (byte) (((chanCfg &amp; 3) &lt;&lt; 6) + (packetLen &gt;&gt; 11)); packet[4] = (byte) ((packetLen &amp; 0x7FF) &gt;&gt; 3); packet[5] = (byte) (((packetLen &amp; 7) &lt;&lt; 5) + 0x1F); packet[6] = (byte) 0xFC;&#125; 音视频混合API: 音视频混合APIMediaMuxer的使用很简单，在Android Developer官网上MediaMuxer的API说明中，也有其简单的使用示例代码，这里就不列了。 参照官方的说明和代码示例，我们可以知道，音视频混合（也可以音频和音频混合），只需要将编码器的MediaFormat加入到MediaMuxer中，得到一个音轨视频轨的索引，然后每次从编码器中取出来的ByteBuffer，写入（writeSampleData）到编码器所在的轨道中就ok了。这里需要注意的是，一定要等编码器设置编码格式完成后，再将它加入到混合器中，编码器编码格式设置完成的标志是dequeueOutputBuffer得到返回值为MediaCodec.INFO_OUTPUT_FORMAT_CHANGED。 源码文章内用到的源码，在agehua/ZlwAudioRecorder，这个是forked from zhaolewei/ZlwAudioRecorder。在原来项目上加入了 AAC 格式支持 参考文章Android硬编码——音频编码、视频编码及音视频混合 Android音频开发（1）：音频基础知识 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/12/06/Android-audio-introduction/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AudioRecord","slug":"audiorecord","permalink":"http://agehua.github.io/tags/audiorecord/"},{"name":"AAC","slug":"aac","permalink":"http://agehua.github.io/tags/aac/"}]},{"title":"Handler、Looper与MessageQueue分析","slug":"Handler-Looper-MessageQueue","date":"2018-08-21T16:00:00.000Z","updated":"2022-03-28T09:32:40.000Z","comments":true,"path":"2018/08/22/Handler-Looper-MessageQueue/","link":"","permalink":"http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/","excerpt":"本文内容节选自《Android从小工到专家——第三章：App流畅度——多线程》，内容稍有修改\n我们知道在Android应用启动时，会默认有一个主线程（UI线程），在这个线程中会关联一个消息队列，所有的操作都会被封装成消息然后交给主线程来处理。为了保证主线程不会主动退出，会将获取消息的操作放在一个死循环中，这样，程序就不会退出.","text":"本文内容节选自《Android从小工到专家——第三章：App流畅度——多线程》，内容稍有修改 我们知道在Android应用启动时，会默认有一个主线程（UI线程），在这个线程中会关联一个消息队列，所有的操作都会被封装成消息然后交给主线程来处理。为了保证主线程不会主动退出，会将获取消息的操作放在一个死循环中，这样，程序就不会退出. Handler、Looper、Message有啥关系？在子线程中完成耗时操作，很多情况下需要更新UI，最常用的就是通过Handler将一个消息Post到UI线程中，然后再在Handler的handlerMessage方法中进行处理。而每个Handler都会关联一个消息队列（MessageQueue），Looper负责的就是创建一个MessageQueue，而每个Looper又会关联一个线程（Looper通过ThreadLocal封装）。默认情况下，MessageQueue只有一个，即主线程的消息队列。 源码解读ActivityThread主线程中启动启动消息循环Looper在ActivityThread的main方法中：public static void main(String[] args) &#123; // 代码省略 Process.setArgV0(\"&lt;pre-initialized&gt;\"); Looper.prepareMainLooper(); //1.创建消息\b循环Looper ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) &#123; sMainThreadHandler = thread.getHandler(); // UI线程的Handler &#125; if (false) &#123; Looper.myLooper().setMessageLogging(new LogPrinter(Log.DEBUG, \"ActivityThread\")); &#125; Looper.loop(); // 2.执行消息循环 throw new RuntimeException(\"Main thread loop unexpectedly exited\"); &#125; ActivityThread通过Looper.prepareMainLooper()创建主线程的消息队列，最后执行Looper.loop()来启动消息队列。Handler关联消息队列和线程。 在 API 22 之后，Google 删除了 AsyncTask.init() 方法，main 函数中也不再调用它。 具体可以看这篇文章：AsyncTask 解析 执行ActivityThread.main方法后，应用程序就启动了，并且会一直从消息队列中取消息，然后处理消息，使得系统运转起来。那么系统是如何将消息投递到消息队列，\b又是如何从消息中获取消息并处理的呢？答案就是Handler Handler关联消息队列和线程消息队列被封装在Looper中，而每个Looper又会关联一个线程（\bLooper通过ThreadLocal封装），最终就等于每个消息队列会关联一个线程。 \b那Handler是如何关联到消息队列以及线程的呢？请看下面的源代码： public Handler() &#123; //代码省略 mLooper = Looper.myLooper(); //获取Looper if (mLooper == null) &#123; throw new RuntimeException( \"Can't create handler inside thread that has not called Looper.prepare()\"); &#125; mQueue = mLooper.mQueue; //获取消息队列 mCallback = null;&#125; Handler会在内部通过Looper.getLooper()方法来获取Looper对象，并且与之关联，并获取消息队列。那么Looper.getLooper()如何工作的呢？ public static @Nullable Looper myLooper() &#123; return sThreadLocal.get();&#125;public static @NonNull MessageQueue myQueue() &#123; return myLooper().mQueue;&#125;public static void prepare() &#123; prepare(true);&#125;//为当前线程设置一个Looperprivate static void prepare(boolean quitAllowed) &#123; if (sThreadLocal.get() != null) &#123; throw new RuntimeException(\"Only one Looper may be created per thread\"); &#125; sThreadLocal.set(new Looper(quitAllowed));&#125;//设置UI线程的Looperpublic static void prepareMainLooper() &#123; prepare(false); synchronized (Looper.class) &#123; if (sMainLooper != null) &#123; throw new IllegalStateException(\"The main Looper has already been prepared.\"); &#125; sMainLooper = myLooper(); &#125;&#125;// Looper的私有构造方法private Looper(boolean quitAllowed) &#123; mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread();&#125; 在Looper类中，myLooper()方法，通过sThreadLocal.get()来获取的，在prepareMainLooper()中调用prepare()方法，在这个方法中创建了一个Looper对象，并将对象设置了sThreadLocal()。这样队列就和线程关联起来了。通过sThreadLocal.get()方法，保证不同的线程不能访问对方的消息队列。 再回到Handler，消息队列通过Looper与线程关联上，而Handler又与Looper关联，因此，Handler最终就和线程、线程的消息队列关联上了。 为什么要更新UI的Handler必须在主线程中创建？因为Handler要与主线程的消息队列关联上，这样handlerMessage才会执行在UI线程，此时UI线程才是安全的。 消息循环，消息处理消息循环的建立就是通过Looper.loop()方法。源代码如下： /** * Run the message queue in this thread. Be sure to call * &#123;@link #quit()&#125; to end the loop. */public static void loop() &#123; final Looper me = myLooper(); if (me == null) &#123; throw new RuntimeException(\"No Looper; Looper.prepare() wasn't called on this thread.\"); &#125; final MessageQueue queue = me.mQueue; //1.获取消息队列 // 代码省略 for (;;) &#123; //2.死循环，即消息循环 //3.获取消息，可能阻塞 Message msg = queue.next(); // might block if (msg == null) &#123; // No message indicates that the message queue is quitting. return; &#125; // 代码省略 try &#123; msg.target.dispatchMessage(msg); //4.处理消息 end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis(); &#125; finally &#123; if (traceTag != 0) &#123; Trace.traceEnd(traceTag); &#125; &#125; // 代码省略 msg.recycleUnchecked(); //回收消息 &#125;&#125; 从上述程序我们可以看出，loop()方法的实质上是建立一个死循环，然后通过从消息队列中逐个取出消息，最后处理消息。对于Looper：通过Looper.prepare()来创建Looper对象（消息队列封装在Looper对象中），并且保存在sThreadLocal中，然后通过通过Looper.loop()进行消息循环，这两步通常成对出现。 消息处理机制在上面代码中通过 msg.target.dispatchMessage(msg) 来处理消息，其中msg是Message类型，源码如下： public final class Message implements Parcelable &#123; //target处理 Handler target; //Runnable类型的callback Runnable callback; //下一条消息，消息队列是链式存储的 Message next; //代码省略&#125; 从源码中可以看出，target是Handler类型。实际上就是转了一圈，通过Handler发送消息给消息队列，消息队列又将消息分发给Handler处理。在Handler类中： //消息处理函数，子类覆写public void handleMessage(Message msg) &#123;&#125;private static void handleCallback(Message message) &#123; message.callback.run();&#125;//分发消息public void dispatchMessage(Message msg) &#123; if (msg.callback != null) &#123; handleCallback(msg); &#125; else &#123; if (mCallback != null) &#123; if (mCallback.handleMessage(msg)) &#123; return; &#125; &#125; handleMessage(msg); &#125;&#125; 从上述程序可以看出，dispatchMessage只是一个分发的方法，如果Run nable类型的callback为空，则执行handleMessage来处理消息，该方法为空，我们会将更新UI的代码写在该函数中；如果callback不为空，则执行handleCallback来处理，该方法会调用callback (Runnable对象) 的run方法。 其实这是Handler分发的两种类型，比如post(Runnable callback)则callback就不为空，当我们使用Handler来sendMessage时通常不设置callback，因此，执行handlerMessage。 我们看看这两种实现： public final boolean post(Runnable r)&#123; return sendMessageDelayed(getPostMessage(r), 0);&#125;private static Message getPostMessage(Runnable r) &#123; Message m = Message.obtain(); m.callback = r; return m;&#125;public final boolean sendMessageDelayed(Message msg, long delayMillis)&#123; if (delayMillis &lt; 0) &#123; delayMillis = 0; &#125; return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);&#125;public boolean sendMessageAtTime(Message msg, long uptimeMillis) &#123; MessageQueue queue = mQueue; if (queue == null) &#123; RuntimeException e = new RuntimeException( this + \" sendMessageAtTime() called with no mQueue\"); Log.w(\"Looper\", e.getMessage(), e); return false; &#125; return enqueueMessage(queue, msg, uptimeMillis); // 将消息插入到消息队列&#125;private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) &#123; msg.target = this; // Message的target就是该Handler本身 if (mAsynchronous) &#123; msg.setAsynchronous(true); &#125; return queue.enqueueMessage(msg, uptimeMillis);// 调用MessageQueue的加入消息方法&#125; 从上述程序可以看到，在post(Runnable r)时，会将Runnable包装成Message对象，并且将Runnable对象设置给Message对象的callback，最后会将该对象插入消息队列。sendMessage也是类似实现： public final boolean sendMessage(Message msg)&#123; return sendMessageDelayed(msg, 0);&#125; 不管是post一个Runnable还是Message，都会调用sendMessageDelayed(msg, time)方法。Handler最终将消息追加到MessageQueue中，而Looper不断地从MessageQueue中读取消息，并且调用Handler的dispatchMessage分发消息，这样消息就源源不断地被产生、添加到MessageQueue、被Handler处理，Android应用就运转起来了。 子线程正确创建Handler在上面Handler的构造方法中看到，如果mLooper = Looper.myLooper()，mLooper为空，则会抛出异常。正确使用方法应该是： new Thread()&#123; Handler handler = null; public void run () &#123; //为当前线程创建Looper，并且绑定到ThreadLocal中 Looper.prepare() handler = new Handler(); //启动消息循环 Looper.loop(); &#125;;&#125;.start(); 如果只创建Looper不启动消息循环，虽然不抛出异常，但是通过handler来post或者sendMessage()也不会有效。因为虽然消息会被追加到消息队列，但是并没有启动消息循环，也就不会从消息队列中获取消息并且执行了。 为什么说MessageQueue 和 Looper 是一对一关系，Handler 和 Looper 是多对一？首先，在上面Looper的私有构造方法，每一个Looper对象都会new MessageQueue()来创建一个MessageQueue，所以是一对一关系没错。为什么Handler和Looper可以是多对一呢？这是因为Handler的构造方法中，会获取当前线程的Looper对象（由ThreadLocal保存的），一个线程Looper对象只有一个，但是可以创建多个Handler对象，所以是多对一 Toast在子线程的用法Toast在子线程直接使用，会报错：java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare() at android.os.Handler.&lt;init&gt;(Handler.java:200) at android.os.Handler.&lt;init&gt;(Handler.java:114) at android.widget.Toast$TN$2.&lt;init&gt;(Toast.java:345) at android.widget.Toast$TN.&lt;init&gt;(Toast.java:345) at android.widget.Toast.&lt;init&gt;(Toast.java:103) at android.widget.Toast.makeText(Toast.java:262) at com.agehua.loveprints.view.main.MainActivity$ShowExceptionThread.run(MainActivity.java:127) 回到前面看下Handler的构造函数，可以发现报这个错误的原因是 mLooper 为null。所以正确的用法应该是： private class ShowExceptionThread extends Thread &#123; private String ex; ShowExceptionThread(String ex) &#123; this.ex = ex; &#125; @Override public void run() &#123; Looper.prepare(); Toast.makeText(AndroidApplication.getInstance().getApplicationContext(), \"Error Encountered: \" + ex, Toast.LENGTH_LONG).show(); Looper.loop(); &#125;&#125; 关于为什么Toast里面会需要Handler，可以看这篇博客：Android Toast源码分析 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Looper","slug":"looper","permalink":"http://agehua.github.io/tags/looper/"},{"name":"Handler","slug":"handler","permalink":"http://agehua.github.io/tags/handler/"},{"name":"MessageQueue","slug":"messagequeue","permalink":"http://agehua.github.io/tags/messagequeue/"},{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"投马-Markdown介绍","slug":"Toastmaster-md-introduction","date":"2018-06-25T16:00:00.000Z","updated":"2023-11-16T03:42:40.849Z","comments":true,"path":"2018/06/26/Toastmaster-md-introduction/","link":"","permalink":"http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/","excerpt":"                   .-&apos; _..`.                           /  .&apos;_.&apos;.&apos;                 | .&apos; (.)`.                 ;&apos;   ,_   `. .--.__________.&apos;    ;  `.;-&apos;|  ./               /|  |               / `..&apos;`-._  _____, ..&apos;     / | |     | |\\ \\    / /| |     | | \\ \\   / / | |     | |  \\ \\  /_/  |_|     |_|   \\_\\","text":".-&apos; _..`. / .&apos;_.&apos;.&apos; | .&apos; (.)`. ;&apos; ,_ `. .--.__________.&apos; ; `.;-&apos;| ./ /| | / `..&apos;`-._ _____, ..&apos; / | | | |\\ \\ / /| | | | \\ \\ / / | | | | \\ \\ /_/ |_| |_| \\_\\ Good afternoon, today I want to introduce a new file format. Before the introduction, I want to ask a question firest: do you have a habit of taking notes or writing blogs? You may heard of Evernote or Jianshu. They all suppost this format to publish arcitles or notes. This format called markdown The file name of this format end up with md or markdown extension. I write my blog use this format. And it is useful and convenient. First, what is the markdown?Markdown is a lightweight markup language with plain text formatting syntax.The motivation for inventing this language was to write content for the web and make the content easy-to-read and easy-to-write.Markdown’s syntax is comprised entirely of punctuation(标点符号) characters, which punctuation characters have been carefully chosen so as to look like what they mean. E.g., asterisks around a word actually look like emphasis. Markdown lists look like, well, lists. Even blockquotes look like quoted passages of text. Second, how does the markdown work?To write Markdown content, you only need a simple text eidtor which support txt extension. That is because it’s written in “plaintext”, which is exactly the sort of text you’re used to writing and seeing. Plaintext is just the regular alphabet, with a few familiar symbols, like pounds (#) and backticks (`). But if you want to see the formated content while you are writing, you need an editor which support markdown. But don’t worry, there are many recommendations on the Internet. Third, why markdown is popular?Markdown is not a replacement for HTML, or even close to it. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.Text written in Markdown can be easily shared between computers, mobile phones, and people. It’s quickly becoming the writing standard for academics(学术), scientists, writers, and many more. Websites like GitHub and reddit use Markdown to style their comments. In china, there are some websites using markdown to write articles as well.Such as, jianshu, a blog community to share articles. Evernote，a famous tools to keep notes. And even more, we can use markdown to write subscription articles for wechat. Finally, Is it diffcult to learn the markdown syntax?No, not at all. Formatting text in Markdown has a very gentle learning curve, it is very easy to learn. It doesn’t do anything fancy like change the font size, color, or type. All you have control over is the display of the text—stuff. For example, surrounded with two asterisks will make the text bold, and starting with two pounds will create a level-two header, and starting with three pounds will create a H3 header, and so on. Now, if you are interested in markdown, I recommend you a website 马克飞象, you can take a look at the official introduction. 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/","raw":null,"content":null,"categories":[{"name":"english","slug":"english","permalink":"http://agehua.github.io/categories/english/"}],"tags":[{"name":"toastmaster","slug":"toastmaster","permalink":"http://agehua.github.io/tags/toastmaster/"}]},{"title":"Java的内存管理与垃圾回收","slug":"JVM-stack-heap-GC","date":"2018-06-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/06/08/JVM-stack-heap-GC/","link":"","permalink":"http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/","excerpt":"不知不觉已经6月8号了，回首一下5月，发现没有什么积累。给自己找个借口，是工作太忙，还是找工作太累？都不是，应该只是自己偷懒了。\n待着是一天，忙碌着也是一天。所以从这篇博文开始，\b为自己立下三个小目标，来督促自己：1.总结一个Java\b系列的文章（至少三篇）2.总结一个数据结构和算法相关的文章（至少三篇）3.学习Android Framework知识，总结出至少三篇\n本篇主要介绍《Java的内存管理与垃圾回收》","text":"不知不觉已经6月8号了，回首一下5月，发现没有什么积累。给自己找个借口，是工作太忙，还是找工作太累？都不是，应该只是自己偷懒了。 待着是一天，忙碌着也是一天。所以从这篇博文开始，\b为自己立下三个小目标，来督促自己：1.总结一个Java\b系列的文章（至少三篇）2.总结一个数据结构和算法相关的文章（至少三篇）3.学习Android Framework知识，总结出至少三篇 本篇主要介绍《Java的内存管理与垃圾回收》 作者：Vamei 出处：http://www.cnblogs.com/vamei/archive/2013/04/28/3048353.html Java是在JVM所虚拟出的内存环境中运行的。内存分为栈(stack)和堆(heap)两部分。我们将分别考察这两个区域。 栈栈是有序的元素集合。栈最显著的特征是LIFO (Last In, First Out, 后进先出)。 栈中的每个元素称为一个frame。而最上层元素称为top frame。栈只支持三个操作， pop, top, push。 栈最经典的计算机应用是函数调用。每个进程都会有一个栈，每个frame中记录了调用函数的参数，自动变量和返回地址。当该函数调用一个新的函数时，栈中会 push一个frame。当函数执行完毕返回时，该frame会pop，从而进入调用该函数的原函数，继续执行 许多语言利用栈数据结构来记录函数调用的次序和相关变量(参考Linux从程序到进程)。 在Java中，JVM中的栈记录了线程的方法调用。每个线程拥有一个栈。在某个线程的运行过程中，如果有新的方法调用，那么该线程对应的栈就会增加一个存储单元，即帧(frame)。在frame中，保存有该方法调用的参数、局部变量和返回地址。 Java的参数和局部变量只能是基本类型的变量(比如int)，或者对象的引用(reference)。因此，在栈中，只保存有基本类型的变量和对象引用。 引用所指向的对象保存在堆中。(引用可能为Null值，即不指向任何对象) 堆如上所述，栈(stack)可以自己照顾自己。但堆必须要小心对待。堆是JVM中一块可自由分配给对象的区域。当我们谈论垃圾回收(garbage collection)时，我们主要回收堆(heap)的空间。 Java的普通对象存活在堆中。与栈不同，堆的空间不会随着方法调用结束而清空。因此，在某个方法中创建的对象，可以在方法调用结束之后，继续存在于堆中。这带来的一个问题是，如果我们不断的创建新的对象，内存空间将最终消耗殆尽。 垃圾回收垃圾回收(garbage collection，简称GC)可以自动清空堆中不再使用的对象。垃圾回收机制最早出现于1959年，被用于解决Lisp语言中的问题。垃圾回收是Java的一大特征。并不是所有的语言都有垃圾回收功能。比如在C/C++中，并没有垃圾回收的机制。程序员需要手动释放堆中的内存。 由于不需要手动释放内存，程序员在编程中也可以减少犯错的机会。利用垃圾回收，程序员可以避免一些指针和内存泄露相关的bug(这一类bug通常很隐蔽)。但另一方面，垃圾回收需要耗费更多的计算时间。垃圾回收实际上是将原本属于程序员的责任转移给计算机。使用垃圾回收的程序需要更长的运行时间。 在Java中，对象的是通过引用使用的(把对象相像成致命的毒物，引用就像是用于提取毒物的镊子)。如果不再有引用指向对象，那么我们就再也无从调用或者处理该对象。这样的对象将不可到达(unreachable)。垃圾回收用于释放不可到达对象所占据的内存。这是垃圾回收的基本原则。 (不可到达对象是死对象，是垃圾回收所要回收的垃圾) 早期的垃圾回收采用引用计数(reference counting)的机制。每个对象包含一个计数器。当有新的指向该对象的引用时，计数器加1。当引用移除时，计数器减1。当计数器为0时，认为该对象可以进行垃圾回收。 然而，一个可能的问题是，如果有两个对象循环引用(cyclic reference)，比如两个对象互相引用，而且此时没有其它(指向A或者指向B)的引用，我们实际上根本无法通过引用到达这两个对象。 因此，我们以栈和static数据为根(root)，从根出发，跟随所有的引用，就可以找到所有的可到达对象。也就是说，一个可到达对象，一定被根引用，或者被其他可到达对象引用。 JVM实施JVM的垃圾回收是多种机制的混合。JVM会根据程序运行状况，自行决定采用哪种垃圾回收。 我们先来了解&quot;mark and sweep&quot;。这种机制下，每个对象将有标记信息，用于表示该对象是否可到达。当垃圾回收启动时，Java程序暂停运行。JVM从根出发，找到所有的可到达对象，并标记(mark)。随后，JVM需要扫描整个堆，找到剩余的对象，并清空这些对象所占据的内存。 另一种是&quot;copy and sweep&quot;。这种机制下，堆被分为两个区域。对象总存活于两个区域中的一个。当垃圾回收启动时，Java程序暂停运行。JVM从根出发，找到可到达对象，将可到达对象复制到空白区域中并紧密排列，修改由于对象移动所造成的引用地址的变化。最后，直接清空对象原先存活的整个区域，使其成为新的空白区域。 可以看到，”copy and sweep”需要更加复杂的操作，但也让对象可以紧密排列，避免”mark and sweep”中可能出现的空隙。在新建对象时，”copy and sweep”可以提供大块的连续空间。因此，如果对象都比较”长寿”，那么适用于”mark and sweep”。如果对象的”新陈代谢”比较活跃，那么适用于”copy and sweep”。 上面两种机制是通过分代回收(generational collection)混合在一起的。每个对象记录有它的世代(generation)信息。所谓的世代，是指该对象所经历的垃圾回收的次数。世代越久远的对象，在内存中存活的时间越久。 根据对Java程序的统计观察，世代越久的对象，越不可能被垃圾回收(富人越富，穷人越穷)。因此，当我们在垃圾回收时，要更多关注那些年轻的对象。 现在，具体看一下JVM中的堆: 我们看到，堆分为三代。其中的永久世代(permanent generation)中存活的是Class对象。这些对象不会被垃圾回收。我们在RTTI中已经了解到，每个Class对象代表一个类，包含有类相关的数据与方法，并提供类定义的代码。每个对象在创建时，都要参照相应的Class对象。每个对象都包含有指向其对应Class对象的引用。 年轻世代(young generation)和成熟世代(tenured generation)需要进行垃圾回收。年轻世代中的对象世代较近，而成熟世代中的对象世代较久。 年轻世代进一步分为三个区域 eden(伊甸): 新生对象存活于该区域。新生对象指从上次GC后新建的对象。 from, to: 这两个区域大小相等，相当于copy and sweep中的两个区域。 当新建对象无法放入eden区时，将出发minor collection。JVM采用copy and sweep的策略，将eden区与from区的可到达对象复制到to区。经过一次垃圾回收，eden区和from区清空，to区中则紧密的存放着存活对象。随后，from区成为新的to区， to区成为新的from区。 如果进行minor collection的时候，发现to区放不下，则将部分对象放入成熟世代。另一方面，即使to区没有满，JVM依然会移动世代足够久远的对象到成熟世代。 如果成熟世代放满对象，无法移入新的对象，那么将触发major collection。JVM采用mark and sweep的策略，对成熟世代进行垃圾回收。 总结以上是对JVM内存管理的一个概述。实际上，JVM拥有众多版本。不同版本实施的GC机制会有不小的差异。另一方面，Java本身并没有规定JVM的GC实施方式。GC依然是JVM发展的一个热点方向。我们可以预期JVM的GC机制在未来会发生许多变化。 另外，也可以参考这篇文章：一篇简单易懂的原理文章，让你把JVM玩弄与手掌之中 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/","raw":null,"content":null,"categories":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/categories/java/"}],"tags":[{"name":"GC","slug":"gc","permalink":"http://agehua.github.io/tags/gc/"},{"name":"JVM","slug":"jvm","permalink":"http://agehua.github.io/tags/jvm/"}]},{"title":"泛型的应用","slug":"Usage-of-genericity","date":"2018-04-22T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/04/23/Usage-of-genericity/","link":"","permalink":"http://agehua.github.io/2018/04/23/Usage-of-genericity/","excerpt":"我在之前转载过一篇Java泛型的介绍：JAVA 泛型通配符 T，E，K，V 区别，T 以及 Class，Class&lt;?&gt; 的区别\n最近在开发中遇到一个场景，想简化流程，突然发现可以使用泛型。这个场景就是，在手机上实现分页加载的功能时，把通用的数据映射成对象，然后使用泛型来替代具体业务类，从而封装出一个对应分页加载的类。","text":"我在之前转载过一篇Java泛型的介绍：JAVA 泛型通配符 T，E，K，V 区别，T 以及 Class，Class&lt;?&gt; 的区别 最近在开发中遇到一个场景，想简化流程，突然发现可以使用泛型。这个场景就是，在手机上实现分页加载的功能时，把通用的数据映射成对象，然后使用泛型来替代具体业务类，从而封装出一个对应分页加载的类。 有点绕，往下看： 泛型的应用在手机上实现分页加载功能，一般都会去服务器请求一个list，但除了list之外，可能还有其他通用的消息内容，比如下面的这个Json内容： &#123; \"list\": [&#123; \"description\": \"b\", \"editTime\": \"12/04/2018\", \"expireTime\": \"20/04/2018 16:30\", \"id\": 105, \"lang\": \"en\", \"sendTimeShort\": \"12/04/2018\", \"status\": \"3\", \"title\": \"a1\", \"unread\": \"1\" &#125;, ... &#123; \"description\": \"d20\", \"editTime\": \"10/04/2018\", \"expireTime\": \"11/04/2018 15:19\", \"id\": 78, \"lang\": \"en\", \"sendTimeShort\": \"10/04/2018\", \"status\": \"3\", \"title\": \"push notification\", \"unread\": \"1\" &#125;], \"pageNo\": 1, \"pageSize\": 10, \"totalCount\": 19, \"totalPages\": 2&#125; 可以发现上面的json串的末尾，是一些跟具体业务无关的固定格式的键值对，这些键值对可以是分页需要的信息，也可以是交易验等证信息。 上面除了通用信息，还有一个list，这个list就跟具体业务有关了，可以用泛型 &lt;T&gt;来代替。 针对上面的json，写出一个对象，代码如下： public class FCMModel&lt;T extends Parcelable&gt; implements Parcelable &#123; private int pageNo; //对应上面json里的键值对 private int totalPages; private int pageSize; private int totalCount; private ArrayList&lt;T&gt; list; private static String DATA_KEY = \"bean_key\";//这个值在序列化 ArrayList 的时候用到 //省略参数的 get 和 set 方法... public List&lt;T&gt; getList() &#123; return list; &#125; public void setList(ArrayList&lt;T&gt; list) &#123; this.list = list; &#125; //继承 Parcelable 必须的方法 public static final Creator&lt;FCMModel&gt; CREATOR = new Creator&lt;FCMModel&gt;() &#123; @Override public FCMModel createFromParcel(Parcel in) &#123; return new FCMModel(in); &#125; @Override public FCMModel[] newArray(int size) &#123; return new FCMModel[size]; &#125; &#125;; @Override public int describeContents() &#123; return 0; &#125; @Override public void writeToParcel(Parcel dest, int flags) &#123; dest.writeInt(this.pageNo); dest.writeInt(this.totalPages); dest.writeInt(this.pageSize); dest.writeInt(this.totalCount); Bundle bundle = new Bundle(); //注意ArrayList的序列化方法 bundle.putParcelableArrayList(DATA_KEY, list); dest.writeBundle(bundle); &#125; public FCMModel() &#123; &#125; protected FCMModel(Parcel in) &#123; this.pageNo = in.readInt(); this.totalPages = in.readInt(); this.pageSize = in.readInt(); this.totalCount = in.readInt(); this.list = in.readBundle().getParcelableArrayList(DATA_KEY); &#125; public static class NotificationListBean implements Parcelable &#123; //这个类只是一个业务类，除了实现Parcelable 接口外没有特殊方法，这里全部省略 ... &#125;&#125; 在上面的代码中，FCMModel就是抽象出来的类，它封装了分页功能中的通用数据，开发者可以只简单实现业务类就行了，是不是方便了一点点，哈哈。 fastjson 泛型转换 注意：在使用 fastjson 对有泛型存在的实体类做序列化时，必须要用到 com.alibaba.fastjson.TypeReference 类，否则会抛出 java.lang.ClassCastException 异常。 我是参考的这篇文章：fastJson泛型如何转换 针对本例子，应该这样使 fastjson 做转换： final static Type type = new TypeReference&lt;FCMModel&lt;FCMModel.NotificationListBean&gt;&gt;() &#123;&#125;.getType();List&lt;FCMModel.NotificationListBean&gt; mBeanList= new ArrayList&lt;&gt;();//...mFCMModel = JSON.parseObject(result.getDataStr(), type);mBeanList = mFCMModel.getList(); 这里的Type是 java.lang.reflect.Type 获取泛型的类型参数以kotlin语音为例，我们不能直接获取一个泛型的类型，比如：val listType = ArrayList&lt;String&gt;::class.java // 不被允许val mapType = Map&lt;String, String&gt;::class.java // 不被允许 如何获取一个泛型的具体类型呢，有两种方式： 使用匿名内部类先看下面的例子：val list1 = ArrayList&lt;String&gt;()val list2 = object: ArrayList&lt;String&gt;() &#123;&#125; // 使用object创建匿名内部类println(list1.javaClass.genericSuperclass)println(list2.javaClass.genericSuperclass) // 结果：java.util.AbstractList&lt;E&gt;java.util.ArrayList&lt;java.lang.String&gt; list2成功拿到了泛型的具体类型，这是因为 泛型类型擦除并不是真的将全部的类型信息都擦除，还是会将类型信息放在对应class的常量池中 匿名内部类在初始化的时候就会绑定父类或父接口的相应信息，这样就能通过获取父类或父接口的泛型信息来实现我们的需求。 我们来设计一个能获取所有类型的信息的泛型类： import java.lang.reflect.ParameterizedTypeimport java.lang.reflect.Typeopen class GenericsToken&lt;T&gt; &#123; var type : Type = Any::class.java init &#123; // 在初始化的时候就能拿到父类或父接口的类型信息 val superClass = this.javaClass.genericSuperclass type = (superClass as ParameterizedType).getActualTypeArguments()[0] &#125;&#125;// 使用：val gt = object: GenericsToken&lt;Map&lt;String, String&gt;&gt;() &#123;&#125; // 一个匿名内部类println(gt.type)// 结果：java.util.Map&lt;java.lang.String, ? extends java.lang.String&gt; 到这里再看下上面的fastjson是如何获取泛型类型的，是不是就可以为什么fastjson要这样写了？ 同理，Gson也是用的相同的设计 使用内联函数其实Kotlin中的内联函数在编译的时候，编译器也会将相应函数的字节码插入到调用的地方，参数类型也会插入到字节码中，这样我们就可以获取参数的类型了。inline fun &lt;reified T&gt; getType() &#123; // 关键字 reified return T::class.java&#125; 这里的意思相当于在编译的会将具体的类型插入响应的字节码中，那么我们就能在运行时获取到对应参数的类型了。所以可以在Kotlin中改进Gson的使用方式： inline fun &lt;reified T : Any&gt; Gson.fromJson(json: String) : T &#123; // 对 Gson.fromJson进行扩展 return Gson().fromJson(json, T::class.java)&#125;// 使用val json =\" ... \"val stringList = Gson().fromJson&lt;List&lt;String&gt;&gt;(json) // 只需传入json一个参数 reified 关键字带来的特性在Android开发中也格外有用，比如修改 startActivity 方法：inline fun &lt;reified T : Activity&gt; Activity.startActivity() &#123; startActivity(Intent(this, T::class.java))&#125;// 使用startActivity&lt;DetailActivity&gt;() 更多关于 reified 关键字的介绍可以看这篇文章：https://juejin.cn/post/6844903833596854279 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/04/23/Usage-of-genericity/","raw":null,"content":null,"categories":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/categories/java/"}],"tags":[{"name":"genericity","slug":"genericity","permalink":"http://agehua.github.io/tags/genericity/"}]},{"title":"投马-two drawbacks","slug":"Toastmaster-two-drawbacks","date":"2018-04-01T16:00:00.000Z","updated":"2023-11-16T03:42:40.848Z","comments":true,"path":"2018/04/02/Toastmaster-two-drawbacks/","link":"","permalink":"http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/","excerpt":"                   .-&apos; _..`.                           /  .&apos;_.&apos;.&apos;                 | .&apos; (.)`.                 ;&apos;   ,_   `. .--.__________.&apos;    ;  `.;-&apos;|  ./               /|  |               / `..&apos;`-._  _____, ..&apos;     / | |     | |\\ \\    / /| |     | | \\ \\   / / | |     | |  \\ \\  /_/  |_|     |_|   \\_\\","text":".-&apos; _..`. / .&apos;_.&apos;.&apos; | .&apos; (.)`. ;&apos; ,_ `. .--.__________.&apos; ; `.;-&apos;| ./ /| | / `..&apos;`-._ _____, ..&apos; / | | | |\\ \\ / /| | | | \\ \\ / / | | | | \\ \\ /_/ |_| |_| \\_\\ Good Afternoon, my dear colleagues. Today, I want to share my two drawbacks with you. Hope I can give you some inspirations or warnings. If you have the same feeling, you should also be aware of these two things.First I wanna tell is the smartphone. Second I wanna talk about the helloworld. Let me ask a question. What is the opposite word of work? You may say it is leisure, or vacation. Actually I don’t think so. Leisure is a busy thing. you need to plan what to do and where to go spend your leisure time. The opposite of work is idleness. We all spend much time on mobile phone, but I was worse. In my case, without smartphone, I can’t taste the flavor of the food. So What do I watch on the mobile phone? I usually watch fragmentation news and entertainment shows. When you watching these, You feel comfortable and joyful, but your brain doesn’t think deeply. And this is idleness. Every day, you feel no gains or no efficiency, that is because of idleness. When you get used to idleness, you will waste your concentration and lose your independent mind. In my opinion, concentration is more valuable than time. Because we all have the same 24 hours each day, but for concentration everyone and every day is different. So don’t waste your concentrations on your phone, or other fragmented information. And my solution is to put your phone far away from you, and spend at least 2 hours each day to stay alone. You can use this time to read a book, or to develop your own habit. And When you really concentrate on something, time flies. Now, back to the second part, the helloworld. I guess all programmers know helloworld means. It’s means a quick start of a programming language. As a software programmer, we need to learn different programming languages. We are very familiar with installing software, configuring development environment. Also, we know so many ways to say ‘Hello world’ using different languages. But we don’t know what to do next after those elementary courses. As far as I’m concerned, study is a lifelong work, we need to learn new knowledge to better ourselves. After coming through the quick start, we need use the new knowledge into practice. And don’t assume you can use it very well at the beginning. In this using process, we need to accept our clumsiness(笨拙), and keep using it even if the result is not good enough. For me, I found one way to use the new knowledge. I write blogs to keep notes. I hope this method can help you too. That’s all, thank you! 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/","raw":null,"content":null,"categories":[{"name":"english","slug":"english","permalink":"http://agehua.github.io/categories/english/"}],"tags":[{"name":"toastmaster","slug":"toastmaster","permalink":"http://agehua.github.io/tags/toastmaster/"}]},{"title":"IntentService和AsyncTask的区别","slug":"IntentService-AsyncTask","date":"2018-03-13T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/03/14/IntentService-AsyncTask/","link":"","permalink":"http://agehua.github.io/2018/03/14/IntentService-AsyncTask/","excerpt":"IntentService和AsyncTask的区别先说总结：Service：Service只适合处理长期后台执行的，这里的后台是指与前台Activity无关的东西，但跟Activity同样运行在UI线程。同时Service开销比Thread大，Service本身不能解决多线程问题。同一个Service多次启动，只会在第一次启动时回调onStart()或onBind()方法，并多次回调onStartCommand方法。","text":"IntentService和AsyncTask的区别先说总结：Service：Service只适合处理长期后台执行的，这里的后台是指与前台Activity无关的东西，但跟Activity同样运行在UI线程。同时Service开销比Thread大，Service本身不能解决多线程问题。同一个Service多次启动，只会在第一次启动时回调onStart()或onBind()方法，并多次回调onStartCommand方法。IntentService：IntentService，是一个抽象类。继承自Service，这使它的优先级比单纯的线程要高很多，同时内部封装了一个HandlerThread 和 Handler，导致它可以执行异步任务，所以它是比较适合一些高优先级的后台任务。HandlerThread是\b在子线程使用Handler的方式，内部实现了Loop循环 但是IntentService，内部队列是MessageQueue，多次调用同一个IntentService，只能是阻塞式执行任务，即当前个任务执行完才会取得下一个任务并执行。 IntentService 默认实现了 OnBind()，返回值为 null。在 onHandleIntent(Intent intent)回调中，处理耗时任务。 那么，用 IntentService 有什么好处呢？首先，可以省去了在 Service 中手动开线程的麻烦，第二，任务执行完后，IntentService 会自动停止，不用手动停止 Service。 AsyncTask也是一个抽象类，自定义一个类继承自AsyncTask。 AsyncTask内容节选自郭霖大神的这篇文章：Android AsyncTask完全解析，带你从源码的角度彻底理解 注意，AsyncTask有3个泛型参数： 1.Params: 在执行AsyncTask时需要传入的参数，可用于在后台任务中使用。 2.Progress: 后台任务执行时，如果需要在界面上显示当前的进度，则使用这里指定的泛型作为进度单位。 3.Result:当任务执行完毕后，如果需要对结果进行返回，则使用这里指定的泛型作为返回值类型。 一个最简单的自定义AsyncTask就可以写成如下方式：class DownloadTask extends AsyncTask&lt;Void, Integer, Boolean&gt; &#123; ……&#125; AsyncTask在Android 3.0之前同一时刻能够运行的线程数为5个，线程池总大小为128。也就是说当我们启动了10个任务时，只有5个任务能够立刻执行，另外的5个任务则需要等待，当有一个任务执行完毕后，第6个任务才会启动，以此类推。而线程池中最大能存放的线程数是128个，当我们尝试去添加第129个任务时，程序就会崩溃。 而3.0之后的AsyncTask同时只能有1个任务在执行。为什么升级之后可以同时执行的任务数反而变少了呢？这是因为更新后的AsyncTask已变得更加灵活，如果不想使用默认的线程池，还可以自由地进行配置。比如使用如下的代码来启动任务： Executor exec = new ThreadPoolExecutor(15, 200, 10, TimeUnit.SECONDS, new LinkedBlockingQueue&lt;Runnable&gt;()); new DownloadTask().executeOnExecutor(exec); 这样就可以使用我们自定义的一个Executor来执行任务，而不是使用SerialExecutor。上述代码的效果允许在同一时刻有15个任务正在执行，并且最多能够存储200个任务。 下面内容\b选自知乎里的\u001c一篇问答：《安卓中AsyncTask和thread以及Service和IntentService的关系和区别？》 什么是线程，同步和异步？ 1、同步：在一个线程执行，先执行完了前面的代码，才会执行后面的代码，是阻塞的。 2、异步：开启一个新的线程执行，不会等前面的代码执行完，就会执行后面的代码，是非阻塞的。 3、什么是main（UI）线程：android启动的第一个线程。主要负责处理ui和事件的工作。 【特别注意】 1)、更新ui只能在ui线程进行，不可以在其他线程更新ui，否则会崩溃。ActivityThread只是运行在UI线程，不等于UI线程。 2)、在ui线程不可以做耗时操作，比如网络请求等，如果做耗时操作，就会阻塞ui线程，就会导致界面卡顿。会出现ANR（application not response、应用无响应）。 4、异步通讯：那么我们要请求网络或者其他耗时操作的时候怎么办？这就涉及到异步通讯或者叫线程通讯。 先在子线程加载数据，做耗时操作，然后把取得的数据传递给ui线程，让ui线程来更新ui。 5、线程通讯的方式： 1)、Handler 在主线程中使用方法： (1)、在主线程实例化一个Hanlder，复写handleMessage()方法，在里面做更新ui的操作； (2)、让子线程持有handler的引用，使用handler来发送消息。 传递参数： 获取消息，请使用handler.obtainMessage(); what:用来区分消息的类型 obj：传递复杂参数 arg1:传递简单的int参数 arg2:传递简单的int参数 Handler的原理： (1)、在主线线程新建一个handler，在子线程中调用这个Handler发送消息到消息队列，在发送的时候，message.target会保存发送它的Handler； (2)、主线程只带一个looper循环，会不断的从消息队列中取出消息，如果没有消息，就阻塞，这里的阻塞并不会导致主线程，因为这里的阻塞底层采用的是Linux的pipe与epoll机制； (3)、在主线程中调用message.target（发送他的Handler）的DispatchMessage，间接调用handlerMeaage来处理消息。 在子线程中使用Handler： 因为使用Handler需要消息循环，子线程中没有消息循环，所以，这里有2中方法： (1)、使用主线程的loop（getMainLooper()），然后在创建Handler的时候，把这个获取的主线程的loop传进去；但是，这种方法，子线程中的Handler还是在主线程处理消息。因为用的主线程的循环。 (2)、给子线程建立消息循环：先调用 Looper.prepare();建立消息循环，消息队列等。在建立了Handler之后，调用Looper.loop()，开始loop循环，如果不掉用，循环就不会开始运行，就不会处理消息。 代码如下： new Thread(new Runnable() &#123; @Override public void run() &#123; Log.i(TAG, \"run: \"); //建立消息循环，建立消息队列 Looper.prepare(); han=new Handler()&#123; @Override public void handleMessage(Message msg) &#123; Log.i(TAG, \"handleMessage: \"+Thread.currentThread().getName()); &#125; &#125;; //开始loop循环 Looper.loop(); &#125;&#125;).start(); Handler的其他使用 (1)、hander.post()方法可以直接把一个代码post到主线程执行； handler.post(new Runnable() &#123; @Override public void run() &#123; //这里在主线程执行 &#125; &#125;); (2)、activity的runOnUITHread（）； runOnUiThread(new Runnable() &#123; @Override public void run() &#123; //这里在主线程执行 &#125;&#125;); (3)、任何控件的Post方法（）； tv.post(new Runnable() &#123; @Override public void run() &#123; //这里在主线程执行 &#125;&#125;); (4)、延时执行： handler.postDelayed(new Runnable() &#123; @Override public void run() &#123; //需要延时执行的代码 &#125; &#125;,1000); 2)、HandlerThread: 支持Handler的线程，内部实现了Loop循环 使用方法： //新建一个代loop的子线程final HandlerThread handlerThread=new HandlerThread(\"zixiancheng\");//让子线程开始执行handlerThread.start();//把线程的looper传给Hander运行，这样，这个Hander就在zixiancheng中执行了。handler=new Handler(handlerThread.getLooper()) 【 注意！！】 使用了这个HandlerThread，他会开启一个循环一直跑，所以，在退出程序的时候，一定要调用quit()，退出循环。 @Overrideprotected void onDestroy() &#123; handlerThread.quit(); super.onDestroy();&#125; 3)、AsyncTask:异步任务继承自AsyncTask，写一个自己的异步任务，注意，AsyncTask有3个泛型。 从做到又分别是：参数的类型，进度的类型，返回结果的类型。 execute()：执行这个异步任务，必须在主线程中调用 onPreExecute()：在执行异步任务之前调用 doInBackground()：执行任务的函数，比如去请求网络 publishProgress()：在请求的过程中，更新一下进度，会调用onProgressUpdate onProgressUpdate()：更新进度，在主线程中运行 onPostExecute()：请求完了以后，可以保存结果 cancel()：取消任务的时候调用。 以上，是关于线程通讯。 Service介绍： 1、startService： 特点： 仅仅需要长时间运行,不需要和其数据交互 使用stopService/stopself()停止服务 多次调用，onCreate方法只执行一次,onStartCommand多次执行 不与当前的Activity绑定，即使当前activity已经关闭了，服务也会继续运行 使用方法： 继承Service写一个类，实现自己的业务需要（onCreate、onStartCommand）； 然后在清单文件中申明； 在activity里面通过startService来启动这个服务； 2、bindService： 特点： 需要和其进行数据交互,使用Binder类 使用unbindService停止服务 当activity销毁之后对应绑定的service自动停止、销毁 不能跨进程通信绑定 不能在广播中调用 使用方式： 继承Service写一个类，实现自己的业务需要（onCreate、onBind）； 然后在清单文件中申明； 在activity里面通过bindService来启动这个服务，这里还需要一个参数，就是serviceConnection对象，通过这个对象来处理activity和Service绑定的事件； 如果要\bActivity和Service相互通讯，还需要使用Binder： 继承自Binder来实现一个自己的Binder，在service的onBind里面返回一个自己的Binder实例； public class MsgService extends Service &#123; //..... /** * 返回一个Binder对象 */ @Override public IBinder onBind(Intent intent) &#123; return new MsgBinder(); &#125; public class MsgBinder extends Binder&#123; /** * 获取当前Service的实例 * @return */ public MsgService getService()&#123; return MsgService.this; &#125; &#125;&#125; 在activity的ServiceConnection里面的onServiceConnected会把service里面的Binder的对象传递回来；我们可以在Binder里面，得到目标service的实例，这样，就可以和Service交互了。 这里的Activity和Service相互通讯，有三种方式： 1.得到Service引用后，直接调用\bMyService的\b具体方法。 2.使用接口，在Service内定义接口类，在Activity内得到MyService引用后，\b注册接口监听。 3.可以使用广播，当然Activity要注册相应的接收器。比如Service要向多个Activity发送同样的消息的话，用这种方法就更好 3、IntentService： 特点： 会自动开启一个子线程，子线程任务结束以后，会自动stop，不需要手动去stopService或者stopself()； 如果多次启动，会在一个队列中，依次的运行; 使用方法： 继承IntentService，实现自己的服务，然后重写onHandleIntent(),在里面做耗时操作； intentService在启动的时候，需要一个默认的构造函数； Service实现IPCService可以结合Messenger实现IPC，当然也可以使用AIDL的方式实现进程间通信。以Messenger为例，实现IPC分以下几个步骤： 1.service 内部需要有一个 Handler 的实现，它被用来处理从每一个 client 发送过的来请求 //MyService类内class ServiceHandler extends Handler &#123; @Override public void handleMessage(Message msg) &#123; switch (msg.what) &#123; default: super.handleMessage(msg); &#125; &#125;&#125; 2.通过这个 Handler ，来生成一个 Messenger //MyService类内final Messenger mMessenger = new Messenger(new ServiceHandler()); 3.在 service 的onBind() 方法中，需要向 client 返回由该 Messenger 生成的一个 IBinder 实例 @Overridepublic IBinder onBind(Intent intent) &#123; //返回给客户端一个IBinder实例 return mMessenger.getBinder();&#125; 4.client 使用从 service 返回的 IBinder 实例来初始化一个 Messenger， 然后使用该 Messenger 与 service 进行通信 //Activity类内部private ServiceConnection mConnection = new ServiceConnection() &#123; public void onServiceConnected(ComponentName className, IBinder service) &#123; //接收onBind()传回来的IBinder，并用它构造Messenger mService = new Messenger(service); mBound = true; &#125; public void onServiceDisconnected(ComponentName className) &#123; mService = null; mBound = false; &#125;&#125;; 5.service 通过它自身内部的 Handler 实现（ServiceHandler 的 handleMessage() 方法中）来处理从 client 发送过来的请求 //发送消息Message msg = Message.obtain();//fill your info into msgmessenger.send(msg); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/03/14/IntentService-AsyncTask/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"IntentService","slug":"intentservice","permalink":"http://agehua.github.io/tags/intentservice/"},{"name":"AsyncTask","slug":"asynctask","permalink":"http://agehua.github.io/tags/asynctask/"}]},{"title":"Android面试题积累(高阶)","slug":"IntervieweeQuestions-senior","date":"2018-02-28T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/03/01/IntervieweeQuestions-senior/","link":"","permalink":"http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/","excerpt":"\n转载自简书Android大厂面试题锦集(BAT TMD JD 小米)\n\n1.android事件分发机制，请详细说下整个流程","text":"转载自简书Android大厂面试题锦集(BAT TMD JD 小米) 1.android事件分发机制，请详细说下整个流程 2.android view绘制机制和加载过程，请详细说下整个流程 1.ViewRootImpl会调用performTraversals(),其内部会调用performMeasure()、performLayout、performDraw()。 2.performMeasure()会调用最外层的ViewGroup的measure()–&gt;onMeasure()。ViewGroup的onMeasure()是抽象方法，但其提供了measureChildren()，这之中会遍历子View然后循环调用measureChild()这之中会用getChildMeasureSpec()+父View的MeasureSpec+子View的LayoutParam一起获取本View的MeasureSpec，然后调用子View的measure()到View的onMeasure()–&gt;setMeasureDimension(getDefaultSize(),getDefaultSize()),getDefaultSize()默认返回measureSpec的测量数值，所以继承View进行自定义的wrap_content需要重写。 3.performLayout()会调用最外层的ViewGroup的layout(l,t,r,b),本View在其中使用setFrame()设置本View的四个顶点位置。在onLayout(抽象方法)中确定子View的位置，如LinearLayout会遍历子View，循环调用setChildFrame()–&gt;子View.layout()。 4.performDraw()会调用最外层ViewGroup的draw():其中会先后调用background.draw()(绘制背景)、onDraw()(绘制自己)、dispatchDraw()(绘制子View)、onDrawScrollBars()(绘制装饰)。 5.MeasureSpec由2位SpecMode(UNSPECIFIED、EXACTLY(对应精确值和match_parent)、AT_MOST(对应warp_content))和30位SpecSize组成一个int,DecorView的MeasureSpec由窗口大小和其LayoutParams决定，其他View由父View的MeasureSpec和本View的LayoutParams决定。ViewGroup中有getChildMeasureSpec()来获取子View的MeasureSpec。 6.三种方式获取measure()后的宽高： 1.Activity#onWindowFocusChange()中调用获取 2.view.post(Runnable)将获取的代码投递到消息队列的尾部。 3.ViewTreeObservable. 3.android四大组件的加载过程，请详细介绍下1.android四大组件的加载过程:请看这篇博客 4.Activity的启动模式1.standard:默认标准模式，每启动一个都会创建一个实例，2.singleTop：栈顶复用，如果在栈顶就调用onNewIntent复用，从onResume()开始3.singleTask：栈内复用，本栈内只要用该类型Activity就会将其顶部的activity出栈4.singleInstance：单例模式，除了3中特性，系统会单独给该Activity创建一个栈。 5.A、B、C、D分别是四种Activity的启动模式，那么A-&gt;B-&gt;C-&gt;D-&gt;A-&gt;B-&gt;C-&gt;D分别启动，最后的activity栈是怎么样的1.这个题目需要深入了解activity的启动模式2.最后的答案是：两个栈，前台栈是只有D，后台栈从底至上是A、B、C分前台栈和后台栈 6.Activity缓存方法1.配置改变导致Activity被杀死，横屏变竖屏：在onStop之前会调用onSaveInstanceState()保存数据在重建Activity之后，会在onStart()之后调用onRestoreInstanceState(),并把保存下来的Bundle传给onCreate()和它会默认重建Activity当前的视图，我们可以在onCreate()中，回复自己的数据。2.内存不足杀掉Activity，优先级分别是：前台可见，可见非前台，后台。 7.Service的生命周期，两种启动方法，有什么区别 1.context.startService() -&gt;onCreate()- &gt;onStart()-&gt;Service running–&gt;(如果调用context.stopService() )-&gt;onDestroy() -&gt;Service shut down 1.如果Service还没有运行，则调用onCreate()然后调用onStart()； 2.如果Service已经运行，则只调用onStart()，所以一个Service的onStart方法可能会重复调用多次。 3.调用stopService的时候直接onDestroy， 4.如果是调用者自己直接退出而没有调用stopService的话，Service会一直在后台运行。该Service的调用者再启动起来后可以通过stopService关闭Service。 2.context.bindService()-&gt;onCreate()-&gt;onBind()-&gt;Service running–&gt;onUnbind() -&gt; onDestroy() -&gt;Service stop 1.onBind将返回给客户端一个IBind接口实例，IBind允许客户端回调服务的方法，比如得到Service运行的状态或其他操作。 2.这个时候会把调用者和Service绑定在一起，Context退出了,Service就会调用onUnbind-&gt;onDestroy相应退出。 3.所以调用bindService的生命周期为：onCreate –&gt; onBind(只一次，不可多次绑定) –&gt; onUnbind –&gt; onDestory。 8.怎么保证service不被杀死1.提升service优先级2.提升service进程优先级3.onDestroy方法里重启service 9.静态的Broadcast 和动态的有什么区别1.动态的比静态的安全2.静态在app启动的时候就初始化了 动态使用代码初始化3.静态需要配置 动态不需要4.生存期，静态广播的生存期可以比动态广播的长很多5.优先级动态广播的优先级比静态广播高 10.Intent可以传递哪些数据类型1.Serializable2.charsequence: 主要用来传递String，char等3.parcelable4.Bundle 11.Json有什么优劣势、解析的原理1.JSON的速度要远远快于XML2.JSON相对于XML来讲，数据的体积小3.JSON对数据的描述性比XML较差4.解析的基本原理是：词法分析 12.一个语言的编译过程1.词法分析：将一串文本按规则分割成最小的结构，关键字、标识符、运算符、界符和常量等。一般实现方法是自动机和正则表达式2.语法分析：将一系列单词组合成语法树。一般实现方法有自顶向下和自底向上3.语义分析：对结构上正确的源程序进行上下文有关性质的审查4.目标代码生成5.代码优化：优化生成的目标代码， 13.动画有哪几类，各有什么特点 1.动画的基本原理：其实就是利用插值器和估值器，来计算出各个时刻View的属性，然后通过改变View的属性来，实现View的动画效果。 2.View动画: 只是影像变化，view的实际位置还在原来的地方。 3.帧动画是在xml中定义好一系列图片之后，使用AnimationDrawable来播放的动画。 4.View的属性动画： 1.插值器（Interpolator）：作用是根据时间的流逝的百分比来计算属性改变的百分比 2.估值器（TypeEvaluator）：在1的基础上由这个东西来计算出属性到底变化了多少数值的类 14.Handler、Looper消息队列模型，各部分的作用 1.MessageQueue：读取会自动删除消息，单链表维护，在插入和删除上有优势。在其next()中会无限循环，不断判断是否有消息，有就返回这条消息并移除。 2.Looper：Looper创建的时候会创建一个MessageQueue，调用loop()方法的时候消息循环开始，loop()也是一个死循环，会不断调用messageQueue的next()，当有消息就处理，否则阻塞在messageQueue的next()中。当Looper的quit()被调用的时候会调用messageQueue的quit(),此时next()会返回null，然后loop()方法也跟着退出。 3.Handler：在主线程构造一个Handler，然后在其他线程调用sendMessage(),此时主线程的MessageQueue中会插入一条message，然后被Looper使用。 4.系统的主线程在ActivityThread的main()为入口开启主线程，其中定义了内部类Activity.H定义了一系列消息类型，包含四大组件的启动停止。 5.MessageQueue和Looper是一对一关系，Handler和Looper是多对一 15.怎样退出终止App1.自己设置一个Activity的栈，然后一个个finish() 16.Android IPC:Binder原理 1.在Activity和Service进行通讯的时候，用到了Binder。 1.当属于同个进程我们可以继承Binder然后在Activity中对Service进行操作 2.当不属于同个进程，那么要用到AIDL让系统给我们创建一个Binder，然后在Activity中对远端的Service进行操作。 2.系统给我们生成的Binder： 1.Stub类中有:接口方法的id，有该Binder的标识，有asInterface(IBinder)(让我们在Activity中获取实现了Binder的接口，接口的实现在Service里，同进程时候返回Stub，\b不同进程则返回Proxy)，有onTransact() 这个方法是在不同进程的情况下，Proxy通过这个方法，在Activity进行远端调用实现Activity操作Service 2.Proxy类是代理，在Activity端，其中有:IBinder mRemote(这就是远端的Binder)，两个接口的实现方法不过是代理最终还是要在远端的onTransact()中进行实际操作。 3.哪一端的Binder是副本，该端就可以被另一端进行操作，因为Binder本体在定义的时候可以操作本端的东西。所以可以在Activity端传入本端的Binder，让Service端对其进行操作称为Listener，可以用RemoteCallbackList这个容器来装Listener，防止Listener因为经历过序列化而产生的问题。 4.当Activity端向远端进行调用的时候，当前线程会挂起，当方法处理完毕才会唤醒。 5.如果一个AIDL就用一个Service太奢侈，所以可以使用Binder池的方式，建立一个AIDL其中的方法是返回IBinder，然后根据方法中传入的参数返回具体的AIDL。 6.IPC的方式有：Bundle（在Intent启动的时候传入，不过是一次性的），文件共享(对于SharedPreference是特例，因为其在内存中会有缓存)，使用Messenger(其底层用的也是AIDL，同理要操作哪端，就在哪端定义Messenger)，AIDL，ContentProvider(在本进程中继承实现一个ContentProvider，在增删改查方法中调用本进程的SQLite，在其他进程中查询)，Socket17.描述一次跨进程通讯 1.client、proxy、serviceManager、BinderDriver、impl、service 2.client发起一个请求service信息的Binder请求到BinderDriver中，serviceManager发现BinderDiriver中有自己的请求 然后将clinet请求的service的数据返回给client这样完成了一次Binder通讯 3.clinet获取的service信息就是该service的proxy，此时调用proxy的方法，proxy将请求发送到BinderDriver中，此时service的 Binder线程池循环发现有自己的请求，然后用impl就处理这个请求最后返回，这样完成了第二次Binder通讯 4.中间client可挂起，也可以不挂起，有一个关键字oneway可以解决这个18.android重要术语解释 1.ActivityManagerServices，简称AMS，服务端对象，负责系统中所有Activity的生命周期 2.ActivityThread，App的真正入口。当开启App之后，会调用main()开始运行，开启消息循环队列，这就是传说中的UI线程或者叫主线程。与ActivityManagerServices配合，一起完成Activity的管理工作 3.ApplicationThread，用来实现ActivityManagerService与ActivityThread之间的交互。在ActivityManagerService需要管理相关Application中的Activity的生命周期时，通过ApplicationThread的代理对象与ActivityThread通讯。 4.ApplicationThreadProxy，是ApplicationThread在服务器端的代理，负责和客户端的ApplicationThread通讯。AMS就是通过该代理与ActivityThread进行通信的。 5.Instrumentation，每一个应用程序只有一个Instrumentation对象，每个Activity内都有一个对该对象的引用。Instrumentation可以理解为应用进程的管家，ActivityThread要创建或暂停某个Activity时，都需要通过Instrumentation来进行具体的操作。 6.ActivityStack，Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。 7.ActivityRecord，ActivityStack的管理对象，每个Activity在AMS对应一个ActivityRecord，来记录Activity的状态以及其他的管理信息。其实就是服务器端的Activity对象的映像。 8.TaskRecord，AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。如果你清楚Activity的4种launchMode，那么对这个概念应该不陌生。 19.理解Window和WindowManager 1.Window用于显示View和接收各种事件，Window有三种类型：应用Window(每个Activity对应一个Window)、子Window(不能单独存在，附属于特定Window)、系统window(Toast和状态栏) 2.Window分层级，应用Window在1-99、子Window在1000-1999、系统Window在2000-2999.WindowManager提供了增删改View三个功能。 3.Window是个抽象概念：每一个Window对应着一个View和ViewRootImpl，Window通过ViewRootImpl来和View建立联系，View是Window存在的实体，只能通过WindowManager来访问Window。 4.WindowManager的实现是WindowManagerImpl其再委托给WindowManagerGlobal来对Window进行操作，其中有四个List分别储存对应的View、ViewRootImpl、WindowManger.LayoutParams和正在被删除的View 5.Window的实体是存在于远端的WindowMangerService中，所以增删改Window在本端是修改上面的几个List然后通过ViewRootImpl重绘View，通过WindowSession(每个应用一个)在远端修改Window。 6.Activity创建Window：Activity会在attach()中创建Window并设置其回调(onAttachedToWindow()、dispatchTouchEvent()),Activity的Window是由Policy类创建PhoneWindow实现的。然后通过Activity#setContentView()调用PhoneWindow的setContentView。 20.Bitmap的处理 1.当使用ImageView的时候，可能图片的像素大于ImageView，此时就可以通过BitmapFactory.Option来对图片进行压缩，inSampleSize表示缩小2^(inSampleSize-1)倍。 2.BitMap的缓存： 1.使用LruCache进行内存缓存。 2.使用DiskLruCache进行硬盘缓存。 3.实现一个ImageLoader的流程：同步异步加载、图片压缩、内存硬盘缓存、网络拉取 1.同步加载只创建一个线程然后按照顺序进行图片加载 2.异步加载使用线程池，让存在的加载任务都处于不同线程 3.为了不开启过多的异步任务，只在列表静止的时候开启图片加载 21.如何实现一个网络框架(参考Volley) 1.缓存队列,以url为key缓存内容可以参考Bitmap的处理方式，这里单独开启一个线程。 2.网络请求队列，使用线程池进行请求。 3.提供各种不同类型的返回值的解析如String，Json，图片等等。 22.ClassLoader的基础知识 1.双亲委托：一个ClassLoader类负责加载这个类所涉及的所有类，在加载的时候会判断该类是否已经被加载过，然后会递归去他父ClassLoader中找。 2.可以动态加载Jar通过URLClassLoader 3.ClassLoader 隔离问题 JVM识别一个类是由：ClassLoader id+PackageName+ClassName。 4.加载不同Jar包中的公共类： 1.让父ClassLoader加载公共的Jar，子ClassLoader加载包含公共Jar的Jar，此时子ClassLoader在加载公共Jar的时候会先去父ClassLoader中找。(只适用Java) 2.重写加载包含公共Jar的Jar的ClassLoader，在loadClass中找到已经加载过公共Jar的ClassLoader，也就是把父ClassLoader替换掉。(只适用Java) 3.在生成包含公共Jar的Jar时候把公共Jar去掉。 23.插件化框架描述：dynamicLoadApk为例子 1.可以通过DexClassLoader来对apk中的dex包进行加载访问 2.如何加载资源是个很大的问题，因为宿主程序中并没有apk中的资源，所以调用R资源会报错，所以这里使用了Activity中的实现ContextImpl的getAssets()和getResources()再加上反射来实现。 3.由于系统启动Activity有很多初始化动作要做，而我们手动反射很难完成，所以可以采用接口机制，将Activity的大部分生命周期提取成接口，然后通过代理Activity去调用插件Activity的生命周期。同时如果想增加一个新生命周期方法的时候，只需要在接口中和代理中声明一下就行。 4.缺点： 1.慎用this，因为在apk中使用this并不代表宿主中的activity，当然如果this只是表示自己的接口还是可以的。除此之外可以使用that代替this。 2.不支持Service和静态注册的Broadcast 3.不支持LaunchMode和Apk中Activity的隐式调用。 24.热修复：Andfix为例子 1.大致原理：apkpatch（阿里Andfix提供的工具包）将两个apk做一次对比，然后找出不同的部分。可以看到生成的apatch了文件，后缀改成zip再解压开，里面有一个dex文件。通过jadx查看一下源码，里面就是被修复的代码所在的类文件,这些更改过的类都加上了一个_CF的后缀，并且变动的方法都被加上了一个叫@MethodReplace的annotation，通过clazz和method指定了需要替换的方法。然后客户端sdk得到补丁文件后就会根据annotation来寻找需要替换的方法。最后由JNI层完成方法的替换。 2.无法添加新类和新的字段、补丁文件很容易被反编译、加固平台可能会使热补丁功能失效 25.线程同步的问题，常用的线程同步 1.sycn：保证了原子性、可见性、有序性 2.锁：保证了原子性、可见性、有序性 1.自旋锁:可以使线程在没有取得锁的时候，不被挂起，而转去执行一个空循环。 1.优点:线程被挂起的几率减少，线程执行的连贯性加强。用于对于锁竞争不是很激烈，锁占用时间很短的并发线程。 2.缺点:过多浪费CPU时间，有一个线程连续两次试图获得自旋锁引起死锁 2.阻塞锁:没得到锁的线程等待或者挂起，Sycn、Lock 3.可重入锁:一个线程可多次获取该锁，Sycn、Lock 4.悲观锁:每次去拿数据的时候都认为别人会修改，所以会阻塞全部其他线程 Sycn、Lock 5.乐观锁:每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。cas 6.显示锁和内置锁:显示锁用Lock来定义、内置锁用synchronized。 7.读-写锁:为了提高性能，Java提供了读 3.volatile 1.只能保证可见性，不能保证原子性 2.自增操作有三步，此时多线程写会出现问题 4.CAS (Compare and swap) 1.操作:内存值V、旧的预期值A、要修改的值B，当且仅当预期值A和内存值V相同时，将内存值修改为B并返回true，否则什么都不做并返回false。 2.解释:本地副本为A，共享内存为V，线程A要把V修改成B。某个时刻线程A要把V修改成B，如果A和V不同那么就表示有其他线程在修改V，此时就表示修改失败，否则表示没有其他线程修改，那么把V改成B。 3.局限:如果V被修改成V1然后又被改成V，此时cas识别不出变化，还是认为没有其他线程在修改V，此时就会有问题 4.局限解决:将V带上版本。 5.线程不安全到底是怎么回事： 1.一个线程写，多个线程读的时候，会造成写了一半就去读 2.多线程写，会造成脏数据 26.Asynctask和线程池，GC相关（怎么判断哪些内存该GC，GC算法） 1.Asynctask：异步任务类，单线程线程池+Handler 2.线程池： 1.ThreadPoolExecutor：通过Executors可以构造单线程池、固定数目线程池、不固定数目线程池。 2.ScheduledThreadPoolExecutor：可以延时调用线程或者延时重复调度线程。 3.GC相关：重要 1.搜索算法： 1.引用计数 2.图搜索，可达性分析 2.回收算法： 1.标记清除复制：用于青年代 2.标记整理：用于老年代 3.堆分区： 1.青年区eden 80%、survivor1 10%、survivor2 10% 2.老年区 4.虚拟机栈分区： 1.局部变量表 2.操作数栈 3.动态链接 4.方法返回地址 5.GC Roots: 1.虚拟机栈(栈桢中的本地变量表)中的引用的对象 2.方法区中的类静态属性引用的对象 3.方法区中的常量引用的对象 4.本地方法栈中JNI的引用的对象 27.网络 1.ARP协议:在IP以太网中，当一个上层协议要发包时，有了该节点的IP地址，ARP就能提供该节点的MAC地址。 2.HTTP HTTPS的区别: 1.HTTPS使用TLS(SSL)进行加密 2.HTTPS缺省工作在TCP协议443端口 3.它的工作流程一般如以下方式: 1.完成TCP三次同步握手 2.客户端验证服务器数字证书，通过，进入步骤3 3.DH算法协商对称加密算法的密钥、hash算法的密钥 4.SSL安全加密隧道协商完成 5.网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改 3.http请求包结构，http返回码的分类，400和500的区别 1.包结构： 1.请求：请求行、头部、数据 2.返回：状态行、头部、数据 2.http返回码分类：1到5分别是，消息、成功、重定向、客户端错误、服务端错误 4.Tcp 1.可靠连接，三次握手，四次挥手 1.三次握手：防止了服务器端的一直等待而浪费资源，例如只是两次握手，如果s确认之后c就掉线了，那么s就会浪费资源 1.syn-c = x，表示这消息是x序号 2.ack-s = x + 1，表示syn-c这个消息接收成功。syn-s = y，表示这消息是y序号。 3.ack-c = y + 1，表示syn-s这条消息接收成功 2.四次挥手：TCP是全双工模式 1.fin-c = x , 表示现在需要关闭c到s了。ack-c = y,表示上一条s的消息已经接收完毕 2.ack-s = x + 1，表示需要关闭的fin-c消息已经接收到了，同意关闭 3.fin-s = y + 1，表示s已经准备好关闭了，就等c的最后一条命令 4.ack-c = y + 1，表示c已经关闭，让s也关闭 3.滑动窗口，停止等待、后退N、选择重传 4.拥塞控制，慢启动、拥塞避免、加速递减、快重传快恢复 28.数据库性能优化：索引和事务，需要找本专门的书大概了解一下29.APK打包流程和其内容1.流程 1.aapt生成R文件 2.aidl生成java文件 3.将全部java文件编译成class文件 4.将全部class文件和第三方包合并成dex文件 5.将资源、so文件、dex文件整合成apk 6.apk签名 7.apk字节对齐 2.内容：so、dex、asset、资源文件 30.网络劫持的类型原理：可以百度一下了解一下具体概念 1.DNS劫持、欺骗、污染 2.http劫持：重定向、注入js，http注入、报文扩展 1.java类加载过程： 1.加载时机：创建实例、访问静态变量或方法、反射、加载子类之前 2.验证：验证文件格式、元数据、字节码、符号引用的正确性 3.加载：根据全类名获取文件字节流、将字节流转化为静态储存结构放入方法区、生成class对象 4.准备：在堆上为静态变量划分内存 5.解析：将常量池中的符号引用转换为直接引用 6.初始化：初始化静态变量 7.书籍推荐：深入理解java虚拟机，博客推荐：Java/Android阿里面试JVM部分理解32.retrofit的了解 1.动态代理创建一个接口的代理类 2.通过反射解析每个接口的注解、入参构造http请求 3.获取到返回的http请求，使用Adapter解析成需要的返回值。 33.bundle的数据结构，如何存储 1.键值对储存 2.传递的数据可以是boolean、byte、int、long、float、double、string等基本类型或它们对应的数组，也可以是对象或对象数组。 3.当Bundle传递的是对象或对象数组时，必须实现Serializable 或Parcelable接口 34.listview内点击buttom并移动的事件流完整拦截过程：1.点下按钮的时候： 1.产生了一个down事件，activity–&gt;phoneWindow–&gt;ViewGroup–&gt;ListView–&gt;botton,中间如果有重写了拦截方法，则事件被该view拦截可能消耗。 2.没拦截，事件到达了button，这个过程中建立了一条事件传递的view链表 3.到button的dispatch方法–&gt;onTouch–&gt;view是否可用–&gt;Touch代理 2.移动点击按钮的时候: 1.产生move事件，listView中会对move事件做拦截 2.此时listView会将该滑动事件消费掉 3.后续的滑动事件都会被listView消费掉 3.手指抬起来时候：前面建立了一个view链表，listView的父view在获取事件的时候，会直接取链表中的listView让其进行事件消耗。 35.service的意义：不需要界面，在后台执行的程序36.android的IPC通信方式，线程（进程间）通信机制有哪些 1.ipc通信方式：binder、contentprovider、socket 2.操作系统进程通讯方式：共享内存、socket、管道 37.操作系统进程和线程的区别 1.简而言之,一个程序至少有一个进程,一个进程至少有一个线程. 2.线程的划分尺度小于进程，使得多线程程序的并发性高。 3.另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。 4.多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配 38.HashMap的实现过程：Capacity就是buckets的数目，Load factor就是buckets填满程度的最大比例。如果对迭代性能要求很高的话不要把capacity设置过大，也不要把load factor设置过小。 1.简单来说HashMap就是一个会自动扩容的数组链表 2.put过程 1.对key的hashCode()做hash，然后再计算index; 2.如果没碰撞直接放到bucket里； 3.如果碰撞了，以链表的形式存在buckets后； 4.如果碰撞导致链表过长(大于等于TREEIFY_THRESHOLD)，就把链表转换成红黑树； 5.如果节点已经存在就替换old value(保证key的唯一性) 6.如果bucket满了(超过load factor*current capacity)，就要resize。 3.resize：当put时，如果发现目前的bucket占用程度已经超过了Load Factor所希望的比例，那么就会发生resize。在resize的过程，简单的说就是把bucket扩充为2倍，之后重新计算index，把节点再放到新的bucket中 4.get过程 1.根据key的hash算出数组下表 2.使用equals遍历链表进行比较39.mvc、mvp、mvvm： 1.mvc:数据、View、Activity，View将操作反馈给Activity，Activitiy去获取数据，数据通过观察者模式刷新给View。循环依赖 1.Activity重，很难单元测试 2.View和Model耦合严重 2.mvp:数据、View、Presenter，View将操作给Presenter，Presenter去获取数据，数据获取好了返回给Presenter，Presenter去刷新View。PV，PM双向依赖 1.接口爆炸 2.Presenter很重 3.mvvm:数据、View、ViewModel，View将操作给ViewModel，ViewModel去获取数据，数据和界面绑定了，数据更新界面更新。 1.viewModel的业务逻辑可以单独拿来测试 2.一个view 对应一个 viewModel 业务逻辑可以分离，不会出现全能类 3.数据和界面绑定了，不用写垃圾代码，但是复用起来不舒服 40.java的线程如何实现 1.Thread继承 2.Runnale 3.Future 4.线程池41.ArrayList 如何删除重复的元素或者指定的元素； 1.删除重复：Set 2.删除指定：迭代器42.如何设计在 UDP 上层保证 UDP 的可靠性传输； 1.简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的超时重传，有序接受，应答确认，滑动窗口流量控制等机制,等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制。 2.比如使用UDP数据包+序列号，UDP数据包+时间戳等方法，在服务器端进行应答确认机制，这样就会保证不可靠的UDP协议进行可靠的数据传输。 3.基于udp的可靠传输协议有：RUDP、RTP、UDT 43.Java 中内部类为什么可以访问外部类1.因为内部类创建的时候，需要外部类的对象，在内部类对象创建的时候会把外部类的引用传递进去 44.设计移动端的联系人存储与查询的功能，要求快速搜索联系人，可以用到哪些数据结构？数据库索引，平衡二叉树(B树、红黑树) 45.红黑树特点 1.root节点和叶子节点是黑色 2.红色节点后必须为黑色节点 3.从root到叶子每条路径的黑节点数量相同46.linux异步和同步i/o: 1.同步：对于client，client一直等待，但是client不挂起：主线程调用 2.异步：对于client，client发起请求，service好了再回调client：其他线程调用，调用完成之后进行回调 3.阻塞：对于service，在准备io的时候会将service端挂起，直至准备完成然后唤醒service：bio 3.非阻塞：对于service，在准备io的时候不会将service端挂起，而是service一直去轮询判断io是否准备完成，准备完成了就进行操作：nio、linux的select、poll、epoll 4.多路复用io：非阻塞io的一种优化，java nio，用一个线程去轮询多个 io端口是否可用，如果一个可用就通知对应的io请求，这使用一个线程轮询可以大大增强性能。 1.我可以采用 多线程+ 阻塞IO 达到类似的效果，但是由于在多线程 + 阻塞IO 中，每个socket对应一个线程，这样会造成很大的资源占用。 2.而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。 5.异步io：aio，用户线程完全不感知io的进行，所有操作都交给内核，io完成之后内核通知用户线程。 1.这种io才是异步的，2、3、4都是同步io，因为内核进行数据拷贝的过程都会让用户线程阻塞。 2.异步IO是需要操作系统的底层支持，也就是内核支持，Java 7中，提供了Asynchronous IO 47.ConcurrentHashMap内部实现，HashTable的实现被废弃的原因: 1.HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。 2.ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock，在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构， 一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护者一个HashEntry数组里的元素,当对HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁。 48.HandlerThread是什么1.MessageQueue + Looper + Handler 49.IntentService是什么1.含有HandlerThread的Service，可以多次startService()来多次在子线程中进行 onHandlerIntent()的调用。 50.class和dex 1.dvm执行的是dex格式文件，jvm执行的是class文件，android程序编译完之后生产class文件。然后dex工具会把class文件处理成dex文件，然后把资源文件和.dex文件等打包成apk文件。 2.dvm是基于寄存器的虚拟机，而jvm执行是基于虚拟栈的虚拟机。寄存器存取速度比栈快的多，dvm可以根据硬件实现最大的优化，比较适合移动设备。 3.class文件存在很多的冗余信息，dex工具会去除冗余信息，并把所有的class文件整合到dex文件中。减少了I/O操作，提高了类的查找速度51.内存泄漏 1.其他线程持有一个Listener，Listener操作activity。那么在线程么有完毕的时候，activity关闭了，原本是要被回收的但是，不能被回收。 2.例如Handler导致的内存泄漏，Handler就相当于Listener。 3.在activity关闭的时候注意停止线程，或者将Listener的注册取消 3.使用弱引用，这样即使Listener持有了activity，在GC的时候还是会被回收 4.工具:LeakCanary 52.过度绘制、卡顿优化: 1.过度绘制： 1.移除Window默认的Background：getWidow.setBackgroundDrawable(null); 2.移除XML布局文件中非必需的Background 3.减少布局嵌套(扁平化的一个体现，减少View数的深度，也就减少了View树的遍历时间，渲染的时候，前后期的工作，总是按View树结点来) 4.在引入布局文件里面，最外层可以用merge替代LinearLayout,RelativeLayout，这样把子UI元素直接衔接在include位置 5.工具：HierarchyViewer 查看视图层级 2.卡顿优化：16ms数据更新 53.apk瘦身: 1.classes.dex：通过代码混淆，删掉不必要的jar包和代码实现该文件的优化 2.资源文件：通过Lint工具扫描代码中没有使用到的静态资源 3.图片资源：使用tinypng和webP，下面详细介绍图片资源优化的方案,矢量图 4.SO文件将不用的去掉，目前主流app一般只放一个arm的so包 54.ANR的形成，各个组件上出现ARN的时间限制是多少 1.只要是主线程耗时的操作就会ARN 如io 2.broadcast超时时间为10秒 按键无响应的超时时间为5秒 前台service无响应的超时时间为20秒，后台service为200秒 55.Serializable和Parcelable 的区别 1.P 消耗内存小 2.网络传输用S 程序内使用P 3.S将数据持久化方便 4.S使用了反射 容易触发垃圾回收 比较慢 56.Sharedpreferences源码简述 1.储存于硬盘上的xml键值对，数据多了会有性能问题 2.ContextImpl记录着SharedPreferences的重要数据，文件路径和实例的键值对 3.在xml文件全部内加载到内存中之前，读取操作是阻塞的，在xml文件全部内加载到内存中之后，是直接读取内存中的数据 4.apply因为是异步的没有返回值, commit是同步的有返回值能知道修改是否提交成功 5.多并发的提交commit时，需等待正在处理的commit数据更新到磁盘文件后才会继续往下执行，从而降低效率; 而apply只是原子更新到内存，后调用apply函数会直接覆盖前面内存数据，从一定程度上提高很多效率。 3.edit()每次都是创建新的EditorImpl对象. 6.博客推荐：全面剖析SharedPreferences 57.操作系统如何管理内存的： 1.使用寄存器进行将进程地址和物理内存进行映射 2.虚拟内存进行内存映射到硬盘上增大内存 3.虚拟内存是进行内存分页管理 4.页表实现分页，就是 页+地址偏移。 5.如果程序的内存在硬盘上，那么就需要用页置换算法来将其调入内存中：先进先出、最近未使用最少等等 6.博客推荐：现代操作系统部分章节笔记 58.浏览器输入地址到返回结果发生了什么 1.DNS解析 2.TCP连接 3.发送HTTP请求 4.服务器处理请求并返回HTTP报文 5.浏览器解析渲染页面 6.连接结束59.java泛型类型擦除发生在什么时候，通配符有什么需要注意的。 1.发生在编译的时候 2.PECS，extends善于提供精确的对象 A是B的子集，Super善于插入精确的对象 A是B的超集 3.博客推荐：Effective Java笔记（不含反序列化、并发、注解和枚举）、android阿里面试java基础锦集 60.activity的生命周期 1.a启动b，后退键再到a的生命周期流程：a.create–&gt;a.start–&gt;a.resume–&gt;a.pause–&gt;b.create–&gt;b.start–&gt;b.resume–&gt;b界面绘制–&gt;a.stop–&gt;b.pause–&gt;a.restart–&gt;a.start–&gt;a.resume–&gt;b.stop–&gt;b.destroy 2.意外销毁会调用saveInstance，重新恢复的时候回调用restoreInstance。储存数据的时候使用了委托机制，从activity–&gt;window–&gt;viewGroup–&gt;view 会递归调用save来保持本view的数据，restore则是递归恢复本view数据。我们可以在里面做一些自己需要的数据操作。 从图中可以得出两点总结： 当跳转到另一个Activity时，总是要等到另一个Activity的onResume方法执行完才会返回当前Activity的生命周期继续执行 当跳转到另一个Activity时，总是要等到当前的Activity的onPause方法执行完才会执行另一个Activity的生命周期（onCreate或onRestart） 61.面试常考的算法 1.快排、堆排序为首的各种排序算法 2.链表的各种操作：判断成环、判断相交、合并链表、倒数K个节点、寻找成环节点 3.二叉树、红黑树、B树定义以及时间复杂度计算方式 4.动态规划、贪心算法、简单的图论 5.推荐书籍：算法导论，将图论之前的例子写一遍62.Launcher进程启动另外一个进程的过程：启动一个app63.开源框架源码 1.Fresco 1.mvc框架： 1.Controller控制数据显示在Hierarchy中的Drawable的显隐 2.ImagePipeline在Controller中负责进行数据获取，返回的数据是CloseableImage 3.Drawee把除了初始化之外的操作全部交给Holder去做，Holder持有Controller和Hierarchy 2.Drawable层次以及绘制： 1.如果要绘制一次Drawable就调用invalidateSelf()来触发onDraw() 2.Drawable分为：容器类(保存一些Drawable)、自我绘制类(进度条)、图形变换类(scale、rotate、矩阵变换)、动画类(内部不断刷新，进行webp和gif的帧绘制) 3.ImagePipeline返回的CloseableImage是由一个个DrawableFactory解析成Drawable的 4.webp和gif动画是由jni代码解析的，然后其他静态图片是根据不同的android平台使用BitmapFactory来解析的 3.职责链模式：producer不做操作标n，表示只是提供一个consumer。获取图片–》解码图片缓存Producer–》后台线程Producer–》client图片处理producer(n)–》解码producer(n)–》旋转或剪裁producer(n)–》编码图片内存缓存producer–》读硬盘缓存producer–》写硬盘缓存producer(n)–》网络producer提供CloseableImage《–解码图片缓存consumer《–client图片处理consumer《–解码consumer《–旋转或剪裁consumer《–编码图片内存缓存consumer《–写硬盘缓存consumer《–图片数据 4.内存缓存： 1.一个CountingLruMap保存已经没有被引用的缓存条目，一个CountingLruMap保存所有的条目包括没有引用的条目。每当缓存策略改变和一定时间缓存配置的更新的时候，就会将 待销毁条目Map中的条目一个个移除，直到缓存大小符合配置。 2.这里的引用计数是用Fresco组件实现的引用计数器。 3.缓存有一个代理类，用来追踪缓存的存取。 4.CountingLruMap是使用LinkedHashMap来储存数据的。 5.硬盘缓存： 1.DefaultDiskStorage使用Lru策略。 2.为了不让所有的文件集中在一个文件中，创建很多命名不同的文件夹，然后使用hash算法把缓存文件分散 3.DiskStorageCache封装了DefaultDiskStorage，不仅进行缓存存取追踪，并且其在内存里面维持着一个 的键值对，因为文件修改频繁，所有只是定时刷新，因此如果在内存中找不到，还要去硬盘中找一次。 4.删除硬盘的缓存只出现在硬盘数据大小超限的时候，此时同时也会删除缓存中的key，所以不会出现内存中有key，但是硬盘上没有的情况。 5.在插入硬盘数据的时候，采用的是插入器的形式。返回一个Inserter，在Inserter.writeData()中传入一个CallBack(里面封装了客户端插入数据的逻辑和文件引用)，让内部实现调用CallBack的逻辑来插入文件数据，前面写的文件后缀是.temp,只有调用commit()之后才会修改后缀，让文件对客户端可见。 6.使用了java提供的FileTreeVisitor来遍历文件 6.对象池： 1.使用数组来存储一个桶，桶内部是一个Queue。数组下标是数据申请内存的byte大小，桶内部的Queue存的是内存块的。所以数组使用的是稀疏数组 2.申请内存的方式有两种 1.java堆上开辟的内存 2.ashme 的本地内存中开辟的内存 7.设计模式：Builder、职责链、观察者、代理、组合、享元、适配器、装饰者、策略、生产者消费者、提供者 8.自定义计数引用：类似c++智能指针 1.使用一个静态IdentityHashMap &lt;储存需要被计数引用的对象,其被引用的次数&gt; 2.用SharedReference分装需要被计数引用的对象，提供一个销毁资源的销毁器，提供一个静态工厂方法来复制自己，复制一个引用计数加一。提供一个方法销毁自己，表示自己需要变成无人引用的对象了，此时引用计数减一。 3.引用计数归零，销毁器将销毁资源，如bitmap的recycle或者是jni内存调用jni方法归还内存。 9.博客推荐：Android Fresco源码文档翻译、从零开始撸一个Fresco之硬盘缓存 2.oKhttp： 1.同步和异步： 1.异步使用了Dispatcher来将存储在 Deque 中的请求分派给线程池中各个线程执行。 2.当任务执行完成后，无论是否有异常，finally代码段总会被执行，也就是会调用Dispatcher的finished函数，它将正在运行的任务Call从队列runningAsyncCalls中移除后，主动的把缓存队列向前走了一步。 2.连接池： 1.一个Connection封装了一个socket，ConnectionPool中储存s着所有的Connection，StreamAllocation是引用计数的一个单位 2.当一个请求获取一个Connection的时候要传入一个StreamAllocation，Connection中存着一个弱引用的StreamAllocation列表，每当上层应用引用一次Connection，StreamAllocation就会加一个。反之如果上层应用不使用了，就会删除一个。 .ConnectionPool中会有一个后台任务定时清理StreamAllocation列表为空的Connection。5分钟时间，维持5个socket 3.选择路线与建立连接 1.选择路线有两种方式： 1.无代理，那么在本地使用DNS查找到ip，注意结果是数组，即一个域名有多个IP，这就是自动重连的来源 2.有代理HTTP：设置socket的ip为代理地址的ip，设置socket的端口为代理地址的端口 3.代理好处：HTTP代理会帮你在远程服务器进行DNS查询，可以减少DNS劫持。 2.建立连接 1.连接池中已经存在连接，就从中取出(get)RealConnection，如果没有命中就进入下一步 2.根据选择的路线(Route)，调用Platform.get().connectSocket选择当前平台Runtime下最好的socket库进行握手 3.将建立成功的RealConnection放入(put)连接池缓存 4.如果存在TLS，就根据SSL版本与证书进行安全握手 5.构造HttpStream并维护刚刚的socket连接，管道建立完成 4.职责链模式：缓存、重试、建立连接等功能存在于拦截器中网络请求相关，主要是网络请求优化。网络请求的时候遇到的问题 5.博客推荐：Android数据层架构的实现 上篇、Android数据层架构的实现 下篇 3.okio 1.简介； 1.sink：自己–》别人 2.source：别人–》自己 3.BufferSink：有缓存区域的sink 4.BufferSource：有缓存区域的source 5.Buffer：实现了3、4的缓存区域，内部有Segment的双向链表，在在转移数据的时候，只需要将指针转移指向就行 2.比java io的好处： 1.减少内存申请和数据拷贝 2.类少，功能齐全，开发效率高 3.内部实现： 1.Buffer的Segment双向链表，减少数据拷贝 2.Segment的内部byte数组的共享，减少数据拷贝 3.SegmentPool的共享和回收Segment 4.sink和source中被实际操作的其实是Buffer，Buffer可以充当sink和source 5.最终okio只是对java io的封装，所有操作都是基于java io 的 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"mac终端命令大全介绍","slug":"Mac-terminal-command","date":"2018-02-23T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2018/02/24/Mac-terminal-command/","link":"","permalink":"http://agehua.github.io/2018/02/24/Mac-terminal-command/","excerpt":"OSX 的文件系统\n转载自：https://www.douban.com/note/75797151/\n\nOSX 采用的Unix文件系统，所有文件都挂在跟目录 /下面，所以不在要有Windows 下的盘符概念。你在桌面上看到的硬盘都挂在 /Volumes 下。","text":"OSX 的文件系统 转载自：https://www.douban.com/note/75797151/ OSX 采用的Unix文件系统，所有文件都挂在跟目录 /下面，所以不在要有Windows 下的盘符概念。你在桌面上看到的硬盘都挂在 /Volumes 下。 比如接上个叫做 USBHD的移动硬盘，桌面上会显示出一个硬盘图标，它实际在哪里呢？在终端里执行 ls /Volumes/USBHD, 看看显示出的是不是这个移动硬盘的内容。 根目录位置是 /, 核心 Mach_kernel 就在这里，驱动所在位置 /Systme/Library/Extensions用户文件夹位置 /User/用户名桌面的位置 /User/用户名/Desktop文件通配符为星号 * 注意：在 Unix系统中是区别大小写字符的，A.txt 不等于 a.txt。 根目录标志 / 不是可有可无，cd /System 表示转到跟目录下的System中，而cd System 表示转到当前目录下的 System中 如何进入命令行操作模式再图形界面下，用finder 打开 应用程序 –&gt;实用程序–&gt;终端如果连图形界面都进不去了（比如安错了显示驱动），开机时按 F8，用－s参数启动，然后输入命令 mount -uw / 获得权限为了防止误操作破坏系统，再用户状态下时没有权限操作系统重要文件的，所以先要取得root权限sudo －s 然后输入密码，输入密码时没有任何回显，连星号都没有，只管输完回车就行了。 基本命令 列出文件ls 参数 目录名例: 想看看跟目录下有什么，ls /想看看驱动目录下有什么，ls /System/Library/Extensions参数 -w 显示中文，-l 详细信息， -a 包括隐藏文件 转换目录cd例：想到驱动目录下溜达一圈cd /System/Library/Extensions 建立新目录mkdir 目录名例：在驱动目录下建一个备份目录 backupmkdir /System/Library/Extensions/backup在桌面上建一个备份目录 backupmkdir /User/用户名/Desktop/backup 拷贝文件cp 参数 源文件 目标文件例：想把桌面的Natit.kext 拷贝到驱动目录中cp -R /User/用户名/Desktop/Natit.kext /System/Library/Extensions参数R表示对目录进行递归操作，kext在图形界面下看起来是个文件，实际上是个文件夹。把驱动目录下的所有文件备份到桌面backupcp -R /System/Library/Extensions/* /User/用户名/Desktop/backup 删除文件rm 参数 文件例：想删除驱动的缓存rm -rf /System/Library/Extensions.kextcacherm -rf /System/Library/Extensions.mkext参数－rf 表示递归和强制，千万要小心使用，如果执行了 rm -rf / 你的系统就全没了 移动文件mv 文件例：想把AppleHDA.Kext 移到桌面mv /System/Library/Extensions/AppleHDA.kext /User/用户名/Desktop想把AppleHDA.Kext 移到备份目录中mv /System/Library/Extensions/AppleHDA.kext /System/Library/Extensions/backup 更改文件权限chmod 参数 权限 文件例：把驱动目录下所有文件设定到root读写，其他用户只读chmod -R 755 /System/Library/Extensions参数R 表示递归，755表示各用户的权限 更改文件属主chown 参数 用户:组 文件例：把驱动目录下的所有文件属主改成根用户chown -R root:wheel /System/Library/Extensions参数R 表示递归操作 修复整个系统中文件的权限diskutil repairpermissions /严格的说这不是一个unix 命令，而是osx一个软件，记得修改或添加的驱动就执行一次。 文本编辑nano 文件名例：编辑natit Info.plistnano /System/Library/Extensions/Natit.kext/Info.plist编辑完成后 用 Ctrl ＋O 存盘，Ctrl＋X 退出另一个文本编辑软件是 vi，操作有些古怪，熟了是非常好用的，而且在所有类Unix系统中都它，走遍天下都不怕了。 补充一个vi的命令： 在默认的”指令模式”下按 i 进入编辑模式 在非指令模式下按 ESC 返回指令模式 在”指令模式”下输入::w 保存当前文件:q 退出编辑,如果文件为保存需要用强制模式:q! 强制退出不保存修改:wq 组合指令, 保存并退出 在”指令模式”下移动:h 左j 下k 上l 右 翻页control + f(front) 下一页control + b(back) 上一页 运行脚本命令sh 脚本文件名例 修改驱动后所有需要的操作存成一个脚本，以后修改了驱动后只要运行一次这个脚本就可以了，方便吧 终端中运行nano /clean 把下列代码粘贴到 nano 中 rm -rf /System/Library/Extensions.kextcache rm -rf /System/Library/Extensions.mkext chown -R root:wheel /System/Library/Extensions chmod -R 755 /System/Library/Extensions diskutil repairpermissions / kextcache -k /System/Library/Extensions/ Ctrl ＋O 存盘，Ctrl＋X 退出 以后只要动了驱动，就在终端中运行一次 sh /clean ———————————————————————————————————— 小技巧 用 Tab 键自动补齐命令比如想到 /System 目录中去，输入 cd /Sy 然后按一下Tab 键，命令就会自动补齐成 cd /System操作带名字中带有空格的文件和目录空格在命令中写成 空格， 比如要进入 My Documents，命令为 cd My Documents 查看命令的详细帮助man 命令名比如要看看 ls 命令的详细用法，执行 man ls 典型操作流程(假设已经制作好清理脚本，记得每次操作前 sudo -s 获得系统权限)假设下载了一个显卡驱动 Natit.zip，在桌面解压得到了一个Natit.kext，该怎么做呢？ 为了保险起见，先把所有驱动备份了再说mkdir /User/用户名/Desktop/backup 在桌面上建立备份文件夹cp -R /System/Library/Extensions/* /User/用户名/Desktop/backup 备份驱动文件 现在可以安心安装了cp -R /User/用户名/Desktop/Natit.kext /System/Library/Extensions 把它 拷贝到系统驱动目录位置sh /clean 执行清理脚本，操作完成 重新开机失败，进不去桌面了，发现不应该安这个驱动，怎么恢复呢？开机按F8，用 -s 参数启动执行 mount -uw /rm -rf /User/用户名/Desktop/Natit.kext 删除这个驱动sh /clean 执行清理脚本，操作完成 重启，回到原先状态了，不死心啊，没有特效怎么行呢，又听说需要修改 Natit的 Info. plist 文件才行，好，再来cp -R /User/用户名/Desktop/Natit.kext /System/Library/Extensions 把它 拷贝到系统驱动目录位置nano /System/Library/Extensions/Natit.kext/Info.plist编辑完成后 用 Ctrl ＋O 存盘，Ctrl＋X 退出sh /clean 执行清理脚本，操作完成 重启，这回对了，显卡特效都有了，该弄声卡了，天知道会出什么事，得把现有成果保护好。mkdir /User/用户名/Desktop/gooddrivers 专为有效驱动建个目录cp -R /System/Library/Extensions/Natit.kext /User/用户名/Desktop/gooddrivers 备份这个声卡要求把 AppleHDA.kext 删除和编辑 AppleAzaliaAudio.kext中的Info.plist 文件，谁知道以后会不会还用AppleHDA呢，不如暂时禁用吧。mkdir /System/Library/Extensions/disabled 建立个禁用目录mv /System/Library/Extensions/AppleHDA.kext /System/Library/Extensions/disabled 移动过去nano /System/Library/Extensions/Natit.kext/AppleAzaliaAudio.kext/Info.plist编辑完成后 用 Ctrl ＋O 存盘，Ctrl＋X 退出sh /clean 执行清理脚本，操作完成成功了，也把修改好的驱动备份一下把 unix的命令以下是unix的命令行,供参考: 目录操作 命令名 功能描述 使用举例 mkdir 创建一个目录 mkdir dirname rmdir 删除一个目录 rmdir dirname mvdir 移动或重命名一个目录 mvdir dir1 dir2 cd 改变当前目录 cd dirname pwd 显示当前目录的路径名 pwd ls 显示当前目录的内容 ls -la dircmp 比较两个目录的内容 dircmp dir1 dir2 文件操作 命令名 功能描述 使用举例 cat 显示或连接文件 cat filename pg 分页格式化显示文件内容 pg filename more 分屏显示文件内容 more filename od 显示非文本文件的内容 od -c filename cp 复制文件或目录 cp file1 file2 rm 删除文件或目录 rm filename mv 改变文件名或所在目录 mv file1 file2 ln 联接文件 ln -s file1 file2 find 使用匹配表达式查找文件 find . -name “*.c” -print file 显示文件类型 file filename 选择操作 命令名 功能描述 使用举例 head 显示文件的最初几行 head -20 filename tail 显示文件的最后几行 tail -15 filename cut 显示文件每行中的某些域 cut -f1,7 -d: /etc/passwd colrm 从标准输入中删除若干列 colrm 8 20 file2 paste 横向连接文件 paste file1 file2 diff 比较并显示两个文件的差异 diff file1 file2 sed 非交互方式流编辑器 sed “s/red/green/g” filename grep 在文件中按模式查找 grep “\\^[a-zA-Z]” filename awk 在文件中查找并处理模式 awk ‘{print $1 $1}’ filename sort 排序或归并文件 sort -d -f -u file1 uniq 去掉文件中的重复行 uniq file1 file2 comm 显示两有序文件的公共和非公共行 comm file1 file2 wc 统计文件的字符数、词数和行数 wc filename nl 给文件加上行号 nl file1 &gt;file2 安全操作 命令名 功能描述 使用举例 passwd 修改用户密码 passwd chmod 改变文件或目录的权限 chmod ug+x filename umask 定义创建文件的权限掩码 umask 027 chown 改变文件或目录的属主 chown newowner filename chgrp 改变文件或目录的所属组 chgrp staff filename xlock 给终端上锁 xlock -remote 编程操作 命令名 功能描述 使用举例 make 维护可执行程序的最新版本 make touch 更新文件的访问和修改时间 touch -m 05202400 filename dbx 命令行界面调试工具 dbx a.out xde 图形用户界面调试工具 xde a.out 进程操作 命令名 功能描述 使用举例 ps 显示进程当前状态 ps u kill 终止进程 kill -9 30142 nice 改变待执行命令的优先级 nice cc -c *.c renice 改变已运行进程的优先级 renice +20 32768 时间操作 命令名 功能描述 使用举例 date 显示系统的当前日期和时间 date cal 显示日历 cal 8 1996 time 统计程序的执行时间 time a.out 网络与通信操作 命令名 功能描述 使用举例 telnet 远程登录 telnet hpc.sp.net.edu.cn rlogin 远程登录 rlogin hostname -l username rsh 在远程主机执行指定命令 rsh f01n03 date ftp 在本地主机与远程主机之间传输文件 ftp ftp.sp.net.edu.cn rcp 在本地主机与远程主机 之间复制文件 rcp file1 host1:file2 ping 给一个网络主机发送 回应请求 ping hpc.sp.net.edu.cn mail 阅读和发送电子邮件 mail write 给另一用户发送报文 write username pts/1 mesg 允许或拒绝接收报文 mesg n Korn Shell 命令 命令名 功能描述 使用举例 history 列出最近执行过的 几条命令及编号 history r 重复执行最近执行过的 某条命令 r -2 alias 给某个命令定义别名 alias del=rm -i unalias 取消对某个别名的定义 unalias del 其它命令 命令名 功能描述 使用举例 uname 显示操作系统的有关信息 uname -a clear 清除屏幕或窗口内容 clear env 显示当前所有设置过的环境变量 env who 列出当前登录的所有用户 who whoami 显示当前正进行操作的用户名 whoami tty 显示终端或伪终端的名称 tty stty 显示或重置控制键定义 stty -a du 查询磁盘使用情况 du -k subdir df 显示文件系统的总空间和可用空间 df /tmp w 显示当前系统活动的总信息 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/02/24/Mac-terminal-command/","raw":null,"content":null,"categories":[{"name":"Mac","slug":"mac","permalink":"http://agehua.github.io/categories/mac/"}],"tags":[{"name":"CMD","slug":"cmd","permalink":"http://agehua.github.io/tags/cmd/"}]},{"title":"投马-自我介绍","slug":"Toastmaster-self-introduction","date":"2018-01-07T16:00:00.000Z","updated":"2023-11-16T03:42:40.846Z","comments":true,"path":"2018/01/08/Toastmaster-self-introduction/","link":"","permalink":"http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/","excerpt":"                   .-&apos; _..`.                  /  .&apos;_.&apos;.&apos;                 | .&apos; (.)`.                 ;&apos;   ,_   `. .--.__________.&apos;    ;  `.;-&apos;|  ./               /|  |               / `..&apos;`-._  _____, ..&apos;     / | |     | |\\ \\    / /| |     | | \\ \\   / / | |     | |  \\ \\  /_/  |_|     |_|   \\_\\","text":".-&apos; _..`. / .&apos;_.&apos;.&apos; | .&apos; (.)`. ;&apos; ,_ `. .--.__________.&apos; ; `.;-&apos;| ./ /| | / `..&apos;`-._ _____, ..&apos; / | | | |\\ \\ / /| | | | \\ \\ / / | | | | \\ \\ /_/ |_| |_| \\_\\ Good afternoon, my dear colleagues.Here is my self-introduction, if you heard something wrong, or you don’t agree with, my apology! My name is Conor. I choose Conor as my English name is because I have an idol who is a professional mixed martial artist and boxer named Conor McGregor. He is the only fighter to be champion in two Ultimate Fighting Championship (UFC) divisions simultaneously. I come from Tangshan city in Hebei province which is not far away from Beijing. I like doing exercise, like running, Skating and swimming. When it comes to the family life, I got married in October 7th last year. What is different between being married and single? My opinion is You have to do cleaning more often, and you have to say I love you ever day. In a word，you have to performance much better than you did when the time you pursuing her. If you don’t ,she will say you have changed since we married. You don’t love me anymore. Come on, I am a good guy, I love her, but I don’t want to say it everyday. As a software engineer, I like coding, I built my own blog on the github. And I wrote an Electronic wedding invitation based on a source code. I konw a joke, let’s see can you all understand this: what is the difference between Java and JavaScript? The answer is Java and Javascript are similar like Car and Carpet are similar. I also like traveling and I prefer to go to historic places. That is because you can enjoy the beautiful scenery and feel the history simultaneously. I have been to the city of Jincheng in Shanxi province. There is a temple called Qinglian temple which was built in Sui and Tang Dynasties. It was situated at the foot of a hill and beside a stream. The temple has a lot of Buddha, but most of them are damaged. The staff there told me,the buddhas’ hands and feet were cut off during the Revolution. When I went there, a big Buddha was being repaired, but many small Buddha statues were put aside, and nobody took care of them. The most impressive one was a small Thousands Hands Guanyin statue. It was badly destroyed and her right half of the body were disappered. Although her body was incomplete, the Buddha‘s face is still smiling. What I want to say is althrough we have a long history and a rich culture in China which we are proud of. But we don’t cherish them. We prefer to Glamorous things, but ignore the old-fashioned things. I hope every one can make an effort to protect our culture. At last, I’d like to recommend a book called 《The path of beauty》(美的历程) in which you can have a Further understanding of our culture by the history timeline. 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/","raw":null,"content":null,"categories":[{"name":"english","slug":"english","permalink":"http://agehua.github.io/categories/english/"}],"tags":[{"name":"toastmaster","slug":"toastmaster","permalink":"http://agehua.github.io/tags/toastmaster/"},{"name":"self-introduction","slug":"self-introduction","permalink":"http://agehua.github.io/tags/self-introduction/"}]},{"title":"Python知识积累","slug":"Python-knowledge","date":"2017-12-01T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/12/02/Python-knowledge/","link":"","permalink":"http://agehua.github.io/2017/12/02/Python-knowledge/","excerpt":"python re 模块 findall 函数用法简述本段转载自：CSDN-python re 模块 findall 函数用法简述\n&gt;&gt;&gt; import re  &gt;&gt;&gt; s = \"adfad asdfasdf asdfas asdfawef asd adsfas \"    &gt;&gt;&gt; reObj1 = re.compile('((\\w+)\\s+\\w+)')  &gt;&gt;&gt; reObj1.findall(s)  [('adfad asdfasdf', 'adfad'), ('asdfas asdfawef', 'asdfas'), ('asd adsfas', 'asd')]    &gt;&gt;&gt; reObj2 = re.compile('(\\w+)\\s+\\w+')  &gt;&gt;&gt; reObj2.findall(s)  ['adfad', 'asdfas', 'asd']    &gt;&gt;&gt; reObj3 = re.compile('\\w+\\s+\\w+')  &gt;&gt;&gt; reObj3.findall(s)  ['adfad asdfasdf', 'asdfas asdfawef', 'asd adsfas']","text":"python re 模块 findall 函数用法简述本段转载自：CSDN-python re 模块 findall 函数用法简述 &gt;&gt;&gt; import re &gt;&gt;&gt; s = \"adfad asdfasdf asdfas asdfawef asd adsfas \" &gt;&gt;&gt; reObj1 = re.compile('((\\w+)\\s+\\w+)') &gt;&gt;&gt; reObj1.findall(s) [('adfad asdfasdf', 'adfad'), ('asdfas asdfawef', 'asdfas'), ('asd adsfas', 'asd')] &gt;&gt;&gt; reObj2 = re.compile('(\\w+)\\s+\\w+') &gt;&gt;&gt; reObj2.findall(s) ['adfad', 'asdfas', 'asd'] &gt;&gt;&gt; reObj3 = re.compile('\\w+\\s+\\w+') &gt;&gt;&gt; reObj3.findall(s) ['adfad asdfasdf', 'asdfas asdfawef', 'asd adsfas'] 按以上代码例子讲解： findall函数返回的总是正则表达式在字符串中所有匹配结果的列表，此处主要讨论列表中“结果”的展现方式，即findall中返回列表中每个元素包含的信息。 @1.当给出的正则表达式中带有多个括号时，列表的元素为多个字符串组成的tuple，tuple中字符串个数与括号对数相同这里是指正则表达式中的括号对数，字符串内容与每个括号内的正则表达式相对应，并且排放顺序是按括号出现的顺序。 @2.当给出的正则表达式中带有一个括号时，列表的元素为字符串，此字符串的内容与括号中的正则表达式相对应（不是整个正则表达式的匹配内容）。 @3.当给出的正则表达式中不带括号时，列表的元素为字符串，此字符串为整个正则表达式匹配的内容。 其实正则表达式常用的就那几种，熟悉了就很强大了： [ ] 表示都可以匹配，比如[abc]匹配a或b或c {1,3}表示重复1-3次 [^abc]表示非abc 一些常用的匹配比如.*?表示非贪婪地匹配任何东西 Python函数的参数Python的函数定义非常简单，但灵活度却非常大。除了正常定义的必选参数外，还可以使用默认参数、可变参数和关键字参数，使得函数定义出来的接口，不但能处理复杂的参数，还可以简化调用者的代码。 位置参数我们先写一个计算x2的函数： def power(x): return x * x 对于power(x)函数，参数x就是一个位置参数。 当我们调用power函数时，必须传入有且仅有的一个参数x：&gt;&gt;&gt; power(5)25&gt;&gt;&gt; power(15)225 现在，如果我们要计算x3怎么办？可以再定义一个power3函数，但是如果要计算x4、x5……怎么办？我们不可能定义无限多个函数。 你也许想到了，可以把power(x)修改为power(x, n)，用来计算xn，说干就干：def power(x, n): s = 1 while n &gt; 0: n = n - 1 s = s * x return s 对于这个修改后的power(x, n)函数，可以计算任意n次方：&gt;&gt;&gt; power(5, 2)25&gt;&gt;&gt; power(5, 3)125 修改后的power(x, n)函数有两个参数：x和n，这两个参数都是位置参数，调用函数时，传入的两个值按照位置顺序依次赋给参数x和n。 默认参数新的power(x, n)函数定义没有问题，但是，旧的调用代码失败了，原因是我们增加了一个参数，导致旧的代码因为缺少一个参数而无法正常调用： &gt;&gt;&gt; power(5)Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt;TypeError: power() missing 1 required positional argument: 'n' Python的错误信息很明确：调用函数power()缺少了一个位置参数n。 这个时候，默认参数就排上用场了。由于我们经常计算x2，所以，完全可以把第二个参数n的默认值设定为2：def power(x, n=2): s = 1 while n &gt; 0: n = n - 1 s = s * x return s 这样，当我们调用power(5)时，相当于调用power(5, 2)：&gt;&gt;&gt; power(5)25&gt;&gt;&gt; power(5, 2)25 而对于n &gt; 2的其他情况，就必须明确地传入n，比如power(5, 3)。 从上面的例子可以看出，默认参数可以简化函数的调用。设置默认参数时，有几点要注意： 一是必选参数在前，默认参数在后，否则Python的解释器会报错（思考一下为什么默认参数不能放在必选参数前面）； 二是如何设置默认参数。 当函数有多个参数时，把变化大的参数放前面，变化小的参数放后面。变化小的参数就可以作为默认参数。 使用默认参数有什么好处？最大的好处是能降低调用函数的难度。 举个例子，我们写个一年级小学生注册的函数，需要传入name和gender两个参数： def enroll(name, gender): print('name:', name) print('gender:', gender) 这样，调用enroll()函数只需要传入两个参数： &gt;&gt;&gt; enroll('Sarah', 'F')name: Sarahgender: F 如果要继续传入年龄、城市等信息怎么办？这样会使得调用函数的复杂度大大增加。 我们可以把年龄和城市设为默认参数： def enroll(name, gender, age=6, city='Beijing'): print('name:', name) print('gender:', gender) print('age:', age) print('city:', city) 这样，大多数学生注册时不需要提供年龄和城市，只提供必须的两个参数： &gt;&gt;&gt; enroll('Sarah', 'F')name: Sarahgender: Fage: 6city: Beijing 只有与默认参数不符的学生才需要提供额外的信息： enroll('Bob', 'M', 7)enroll('Adam', 'M', city='Tianjin') 可见，默认参数降低了函数调用的难度，而一旦需要更复杂的调用时，又可以传递更多的参数来实现。无论是简单调用还是复杂调用，函数只需要定义一个。 有多个默认参数时，调用的时候，既可以按顺序提供默认参数，比如调用enroll(‘Bob’, ‘M’, 7)，意思是，除了name，gender这两个参数外，最后1个参数应用在参数age上，city参数由于没有提供，仍然使用默认值。 也可以不按顺序提供部分默认参数。当不按顺序提供部分默认参数时，需要把参数名写上。比如调用enroll(‘Adam’, ‘M’, city=’Tianjin’)，意思是，city参数用传进去的值，其他默认参数继续使用默认值。 默认参数很有用，但使用不当，也会掉坑里。默认参数有个最大的坑，演示如下： 先定义一个函数，传入一个list，添加一个END再返回： def add_end(L=[]): L.append('END') return L 当你正常调用时，结果似乎不错： &gt;&gt;&gt; add_end([1, 2, 3])[1, 2, 3, 'END']&gt;&gt;&gt; add_end(['x', 'y', 'z'])['x', 'y', 'z', 'END'] 当你使用默认参数调用时，一开始结果也是对的： &gt;&gt;&gt; add_end()['END'] 但是，再次调用add_end()时，结果就不对了： &gt;&gt;&gt; add_end()['END', 'END']&gt;&gt;&gt; add_end()['END', 'END', 'END'] 很多初学者很疑惑，默认参数是[]，但是函数似乎每次都“记住了”上次添加了’END’后的list。 原因解释如下： Python函数在定义的时候，默认参数L的值就被计算出来了，即[]，因为默认参数L也是一个变量，它指向对象[]，每次调用该函数，如果改变了L的内容，则下次调用时，默认参数的内容就变了，不再是函数定义时的[]了。 定义默认参数要牢记一点：默认参数必须指向不变对象！要修改上面的例子，我们可以用None这个不变对象来实现： def add_end(L=None): if L is None: L = [] L.append('END') return L 现在，无论调用多少次，都不会有问题： &gt;&gt;&gt; add_end()['END']&gt;&gt;&gt; add_end()['END'] 为什么要设计str、None这样的不变对象呢？因为不变对象一旦创建，对象内部的数据就不能修改，这样就减少了由于修改数据导致的错误。此外，由于对象不变，多任务环境下同时读取对象不需要加锁，同时读一点问题都没有。我们在编写程序时，如果可以设计一个不变对象，那就尽量设计成不变对象。 可变参数在Python函数中，还可以定义可变参数。顾名思义，可变参数就是传入的参数个数是可变的，可以是1个、2个到任意个，还可以是0个。 我们以数学题为例子，给定一组数字a，b，c……，请计算a2 + b2 + c2 + ……。 要定义出这个函数，我们必须确定输入的参数。由于参数个数不确定，我们首先想到可以把a，b，c……作为一个list或tuple传进来，这样，函数可以定义如下： def calc(numbers): sum = 0 for n in numbers: sum = sum + n * n return sum 但是调用的时候，需要先组装出一个list或tuple： &gt;&gt;&gt; calc([1, 2, 3])14&gt;&gt;&gt; calc((1, 3, 5, 7))84 如果利用可变参数，调用函数的方式可以简化成这样： &gt;&gt;&gt; calc(1, 2, 3)14&gt;&gt;&gt; calc(1, 3, 5, 7)84 所以，我们把函数的参数改为可变参数： def calc(*numbers): sum = 0 for n in numbers: sum = sum + n * n return sum 定义可变参数和定义一个list或tuple参数相比，仅仅在参数前面加了一个*号。在函数内部，参数numbers接收到的是一个tuple，因此，函数代码完全不变。但是，调用该函数时，可以传入任意个参数，包括0个参数： &gt;&gt;&gt; calc(1, 2)5&gt;&gt;&gt; calc()0 如果已经有一个list或者tuple，要调用一个可变参数怎么办？可以这样做： &gt;&gt;&gt; nums = [1, 2, 3]&gt;&gt;&gt; calc(nums[0], nums[1], nums[2])14 这种写法当然是可行的，问题是太繁琐，所以Python允许你在list或tuple前面加一个*号，把list或tuple的元素变成可变参数传进去： &gt;&gt;&gt; nums = [1, 2, 3]&gt;&gt;&gt; calc(*nums)14 *nums表示把nums这个list的所有元素作为可变参数传进去。这种写法相当有用，而且很常见。 关键字参数可变参数允许你传入0个或任意个参数，这些可变参数在函数调用时自动组装为一个tuple。而关键字参数允许你传入0个或任意个含参数名的参数，这些关键字参数在函数内部自动组装为一个dict。请看示例： def person(name, age, **kw): print('name:', name, 'age:', age, 'other:', kw) 函数person除了必选参数name和age外，还接受关键字参数kw。在调用该函数时，可以只传入必选参数： &gt;&gt;&gt; person('Michael', 30)name: Michael age: 30 other: &#123;&#125; 也可以传入任意个数的关键字参数： &gt;&gt;&gt; person('Bob', 35, city='Beijing')name: Bob age: 35 other: &#123;'city': 'Beijing'&#125;&gt;&gt;&gt; person('Adam', 45, gender='M', job='Engineer')name: Adam age: 45 other: &#123;'gender': 'M', 'job': 'Engineer'&#125; 关键字参数有什么用？它可以扩展函数的功能。比如，在person函数里，我们保证能接收到name和age这两个参数，但是，如果调用者愿意提供更多的参数，我们也能收到。试想你正在做一个用户注册的功能，除了用户名和年龄是必填项外，其他都是可选项，利用关键字参数来定义这个函数就能满足注册的需求。 和可变参数类似，也可以先组装出一个dict，然后，把该dict转换为关键字参数传进去： &gt;&gt;&gt; extra = &#123;'city': 'Beijing', 'job': 'Engineer'&#125;&gt;&gt;&gt; person('Jack', 24, city=extra['city'], job=extra['job'])name: Jack age: 24 other: &#123;'city': 'Beijing', 'job': 'Engineer'&#125; 当然，上面复杂的调用可以用简化的写法： &gt;&gt;&gt; extra = &#123;'city': 'Beijing', 'job': 'Engineer'&#125;&gt;&gt;&gt; person('Jack', 24, **extra)name: Jack age: 24 other: &#123;'city': 'Beijing', 'job': 'Engineer'&#125; extra表示把extra这个dict的所有key-value用关键字参数传入到函数的kw参数，kw将获得一个dict，注意kw获得的dict是extra的一份拷贝，对kw的改动不会影响到函数外的extra。 命名关键字参数对于关键字参数，函数的调用者可以传入任意不受限制的关键字参数。至于到底传入了哪些，就需要在函数内部通过kw检查。 仍以person()函数为例，我们希望检查是否有city和job参数： def person(name, age, **kw): if 'city' in kw: # 有city参数 pass if 'job' in kw: # 有job参数 pass print('name:', name, 'age:', age, 'other:', kw) 但是调用者仍可以传入不受限制的关键字参数： &gt;&gt;&gt; person('Jack', 24, city='Beijing', addr='Chaoyang', zipcode=123456) 如果要限制关键字参数的名字，就可以用命名关键字参数，例如，只接收city和job作为关键字参数。这种方式定义的函数如下： def person(name, age, *, city, job): print(name, age, city, job) 和关键字参数**kw不同，命名关键字参数需要一个特殊分隔符*，*后面的参数被视为命名关键字参数。 调用方式如下： &gt;&gt;&gt; person('Jack', 24, city='Beijing', job='Engineer')Jack 24 Beijing Engineer 如果函数定义中已经有了一个可变参数，后面跟着的命名关键字参数就不再需要一个特殊分隔符*了： def person(name, age, *args, city, job): print(name, age, args, city, job) 命名关键字参数必须传入参数名，这和位置参数不同。如果没有传入参数名，调用将报错： &gt;&gt;&gt; person('Jack', 24, 'Beijing', 'Engineer')Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt;TypeError: person() takes 2 positional arguments but 4 were given 由于调用时缺少参数名city和job，Python解释器把这4个参数均视为位置参数，但person()函数仅接受2个位置参数。 命名关键字参数可以有缺省值，从而简化调用：def person(name, age, *, city='Beijing', job): print(name, age, city, job) 由于命名关键字参数city具有默认值，调用时，可不传入city参数： &gt;&gt;&gt; person('Jack', 24, job='Engineer')Jack 24 Beijing Engineer 使用命名关键字参数时，要特别注意，如果没有可变参数，就必须加一个*作为特殊分隔符。如果缺少*，Python解释器将无法识别位置参数和命名关键字参数： def person(name, age, city, job): # 缺少 *，city和job被视为位置参数 pass 参数组合在Python中定义函数，可以用必选参数、默认参数、可变参数、关键字参数和命名关键字参数，这5种参数都可以组合使用。但是请注意，参数定义的顺序必须是：必选参数、默认参数、可变参数、命名关键字参数和关键字参数。 比如定义一个函数，包含上述若干种参数： def f1(a, b, c=0, *args, **kw): print('a =', a, 'b =', b, 'c =', c, 'args =', args, 'kw =', kw)def f2(a, b, c=0, *, d, **kw): print('a =', a, 'b =', b, 'c =', c, 'd =', d, 'kw =', kw) 在函数调用的时候，Python解释器自动按照参数位置和参数名把对应的参数传进去。 &gt;&gt;&gt; f1(1, 2)a = 1 b = 2 c = 0 args = () kw = &#123;&#125;&gt;&gt;&gt; f1(1, 2, c=3)a = 1 b = 2 c = 3 args = () kw = &#123;&#125;&gt;&gt;&gt; f1(1, 2, 3, 'a', 'b')a = 1 b = 2 c = 3 args = ('a', 'b') kw = &#123;&#125;&gt;&gt;&gt; f1(1, 2, 3, 'a', 'b', x=99)a = 1 b = 2 c = 3 args = ('a', 'b') kw = &#123;'x': 99&#125;&gt;&gt;&gt; f2(1, 2, d=99, ext=None)a = 1 b = 2 c = 0 d = 99 kw = &#123;'ext': None&#125; 最神奇的是通过一个tuple和dict，你也可以调用上述函数：&gt;&gt;&gt; args = (1, 2, 3, 4)&gt;&gt;&gt; kw = &#123;'d': 99, 'x': '#'&#125;&gt;&gt;&gt; f1(*args, **kw)a = 1 b = 2 c = 3 args = (4,) kw = &#123;'d': 99, 'x': '#'&#125;&gt;&gt;&gt; args = (1, 2, 3)&gt;&gt;&gt; kw = &#123;'d': 88, 'x': '#'&#125;&gt;&gt;&gt; f2(*args, **kw)a = 1 b = 2 c = 3 d = 88 kw = &#123;'x': '#'&#125; 对上面代码的结果做一个说明：*args是可变参数，接收list或tuple，然后自动组装成tuple。而一个单独的*，表示命名关键字参数，它和关键字参数一样，都必须接收带参数名的参数。对于f2函数而言，它只接受3个位置参数，一个或一个以上的带参数名的参数（这里的一个的参数名必须是d，因为命名关键字参数没有缺省值的话，不能为空，而关键字参数可以为空），args是一个tuple参数，最多只能传3个值，而kw作为一个dict，必须包含一个d参数名的参数。 所以，对于任意函数，都可以通过类似func(*args, **kw)的形式调用它，无论它的参数是如何定义的。 虽然可以组合多达5种参数，但不要同时使用太多的组合，否则函数接口的可理解性很差 小结Python的函数具有非常灵活的参数形态，既可以实现简单的调用，又可以传入非常复杂的参数。 默认参数一定要用不可变对象，如果是可变对象，程序运行时会有逻辑错误！ 要注意定义可变参数和关键字参数的语法： *args是可变参数，args接收的是一个tuple； **kw是关键字参数，kw接收的是一个dict。 以及调用函数时如何传入可变参数和关键字参数的语法： 可变参数既可以直接传入：func(1, 2, 3)，又可以先组装list或tuple，再通过*args传入：func(*(1, 2, 3))； 关键字参数既可以直接传入：func(a=1, b=2)，又可以先组装dict，再通过**kw传入：func(**{&#39;a&#39;: 1, &#39;b&#39;: 2})。 使用*args和**kw是Python的习惯写法，当然也可以用其他参数名，但最好使用习惯用法。 命名的关键字参数是为了限制调用者可以传入的参数名，同时可以提供默认值。 定义命名的关键字参数在没有可变参数的情况下不要忘了写分隔符*，否则定义的将是位置参数。 Python语法回顾看这篇文章：分分钟学会一门语言之Python篇 Python之禅(Zen Of Python)Python 输入 import this 就会显示 Tim Peters 的 The Zen of Python，原文和翻译请看：《Python之禅》的翻译和解释 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/12/02/Python-knowledge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"Python","slug":"python","permalink":"http://agehua.github.io/tags/python/"}]},{"title":"跨平台桌面程序开发","slug":"Buildcross-platform-desktop-apps","date":"2017-10-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.314Z","comments":true,"path":"2017/10/22/Buildcross-platform-desktop-apps/","link":"","permalink":"http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/","excerpt":"跨平台桌面程序开发今天搜索Alfred 英文词典应用时发现了这个工具：Youdao Alfred Workflow\n\u001d作者在这篇文章：学英语和写工具，里面介绍了Alfred插件开发，同时也介绍了一下跨平台插件开发的方式：","text":"跨平台桌面程序开发今天搜索Alfred 英文词典应用时发现了这个工具：Youdao Alfred Workflow \u001d作者在这篇文章：学英语和写工具，里面介绍了Alfred插件开发，同时也介绍了一下跨平台插件开发的方式： 下面这段摘自这篇文章： 从趋势上来看，基于 HTML5 API 和 Node.js 的跨平台插件开发是未来的主流方向。 Chrome App 。从 Github 上下载一些 chrome app sample 示例，简单浏览一下教程（墙内的、墙外的）和官方 API 文档 ，不出半天时间就能开发出一款插件。 npm 命令行工具。npm 模块除了在 node 环境下作为依赖模块被引用以外，还可以直接作为命令行工具使用。通过 package.json bin 字段定义，在全局安装时即可自动注册为全局命令行。例如，这款用于生成字体的 makefont 命令行模块。 NW.js 。将 webkit 和 node 集成打包使用的跨平台方案。当前 Mac 版的「夺命追魂钉」用的就是这个方案。node + webkit 方案最终将会取代 Adobe AIR ，这是 HTML5 对 Flash 的胜利。 Electron 。微软新出的 Visual Studio Code 编辑器和 Github 的 Atom 编辑器使用的内核引擎，与 NW.js 的区别参看这里 。 对于程序员来说，这是一个非常好的全栈实践之路。 Visual Studio Code 配置指南 Visual Studio Code和Atom竟然是用Electron开发出来的，顿时觉得这种技术好强大，下决心要学习一下这个技术。 关于 ElectronElectron的官方网址是：https://electronjs.org/ 如果你可以建一个网站，你就可以建一个桌面应用程序。 Electron 是一个使用 JavaScript, HTML 和 CSS 等 Web 技术创建原生程序的框架，它负责比较难搞的部分，你只需把精力放在你的应用的核心上即可。 Electron（最初名为Atom Shell[3]）是GitHub开发的一个开源框架。它允许使用Node.js（作为后端）和Chromium（作为前端）完成桌面GUI应用程序的开发。Electron现已被多个开源Web应用程序用于前端与后端的开发，著名项目包括GitHub的Atom和微软的Visual Studio Code。 入门教程有：Electron W3C中文文档Github: electron-cn-docs 由于Electron基于Node.js，所以入门第一关应当稍微熟悉Node.js的文档. Electron主进程 在 Electron 里，运行 package.json 里 main 脚本的进程被称为主进程。在主进程运行的脚本可以以创建 web 页面的形式展示 GUI。渲染进程 由于 Electron 使用 Chromium 来展示页面，所以 Chromium 的多进程结构也被充分利用。每个 Electron 的页面都在运行着自己的进程，这样的进程我们称之为渲染进程。在一般浏览器中，网页通常会在沙盒环境下运行，并且不允许访问原生资源。然而，Electron 用户拥有在网页中调用 io.js 的 APIs 的能力，可以与底层操作系统直接交互。 主进程与渲染进程的区别 主进程使用 BrowserWindow 实例创建网页。每个 BrowserWindow 实例都在自己的渲染进程里运行着一个网页。当一个 BrowserWindow 实例被销毁后，相应的渲染进程也会被终止。主进程管理所有页面和与之对应的渲染进程。每个渲染进程都是相互独立的，并且只关心他们自己的网页。由于在网页里管理原生 GUI 资源是非常危险而且容易造成资源泄露，所以在网页面调用 GUI 相关的 APIs 是不被允许的。如果你想在网页里使用 GUI 操作，其对应的渲染进程必须与主进程进行通讯，请求主进程进行相关的 GUI 操作。在 Electron，我们提供用于在主进程与渲染进程之间通讯的 ipc 模块。并且也有一个远程进程调用风格的通讯模块 remote。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Alfred Workflow","slug":"alfred-workflow","permalink":"http://agehua.github.io/tags/alfred-workflow/"},{"name":"Electron","slug":"electron","permalink":"http://agehua.github.io/tags/electron/"},{"name":"JavaScript","slug":"javascript","permalink":"http://agehua.github.io/tags/javascript/"}]},{"title":"JavaScript知识点积累","slug":"JavaScript-knowledge","date":"2017-10-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/10/22/JavaScript-knowledge/","link":"","permalink":"http://agehua.github.io/2017/10/22/JavaScript-knowledge/","excerpt":"JavaScript积累\n‘Java and JavaScript are similar like Car and Carpet are similar’ - Greg Hewgill\n\n本文大部分内容来自: 廖雪峰–JavaScript教程\nfor … of循环介绍ES6引入了for … of循环遍历集合，你可能会有疑问，for … of循环和for … in循环有何区别？\nfor … in循环由于历史遗留问题，它遍历的实际上是对象的属性名称。一个Array数组实际上也是一个对象，它的每个元素的索引被视为一个属性。","text":"JavaScript积累 ‘Java and JavaScript are similar like Car and Carpet are similar’ - Greg Hewgill 本文大部分内容来自: 廖雪峰–JavaScript教程 for … of循环介绍ES6引入了for … of循环遍历集合，你可能会有疑问，for … of循环和for … in循环有何区别？ for … in循环由于历史遗留问题，它遍历的实际上是对象的属性名称。一个Array数组实际上也是一个对象，它的每个元素的索引被视为一个属性。 当我们手动给Array对象添加了额外的属性后，for … in循环将带来意想不到的意外效果：var a = ['A', 'B', 'C'];a.name = 'Hello';for (var x in a) &#123; console.log(x); // '0', '1', '2', 'name'&#125; for … in循环将把name包括在内，但Array的length属性却不包括在内。 for … of循环则完全修复了这些问题，它只循环集合本身的元素：var a = ['A', 'B', 'C'];a.name = 'Hello';for (var x of a) &#123; console.log(x); // 'A', 'B', 'C'&#125; 这就是为什么要引入新的for … of循环。 然而，更好的方式是直接使用iterable内置的forEach方法，它接收一个函数，每次迭代就自动回调该函数。以Array为例： 'use strict';var a = ['A', 'B', 'C'];a.forEach(function (element, index, array) &#123; // element: 指向当前元素的值 // index: 指向当前索引 // array: 指向Array对象本身 console.log(element + ', index = ' + index);&#125;); 注意，forEach()方法是ES5.1标准引入的，你需要测试浏览器是否支持。 Set与Array类似，但Set没有索引，因此回调函数的前两个参数都是元素本身：var s = new Set(['A', 'B', 'C']);s.forEach(function (element, sameElement, set) &#123; console.log(element);&#125;); Map的回调函数参数依次为value、key和map本身：var m = new Map([[1, 'x'], [2, 'y'], [3, 'z']]);m.forEach(function (value, key, map) &#123; console.log(value);&#125;); 如果对某些参数不感兴趣，由于JavaScript的函数调用不要求参数必须一致，因此可以忽略它们。例如，只需要获得Array的element：var a = ['A', 'B', 'C'];a.forEach(function (element) &#123; console.log(element);&#125;); rest参数JavaScript还有一个免费赠送的关键字arguments，它只在函数内部起作用，并且永远指向当前函数的调用者传入的所有参数。arguments类似Array但它不是一个Array.由于JavaScript函数允许接收任意个参数，于是我们就不得不用arguments来获取所有参数：function foo(a, b) &#123; var i, rest = []; if (arguments.length &gt; 2) &#123; for (i = 2; i&lt;arguments.length; i++) &#123; rest.push(arguments[i]); &#125; &#125; console.log('a = ' + a); console.log('b = ' + b); console.log(rest);&#125; 为了获取除了已定义参数a、b之外的参数，我们不得不用arguments，并且循环要从索引2开始以便排除前两个参数，这种写法很别扭，只是为了获得额外的rest参数，有没有更好的方法？ ES6标准引入了rest参数，上面的函数可以改写为：function foo(a, b, ...rest) &#123; console.log('a = ' + a); console.log('b = ' + b); console.log(rest);&#125;foo(1, 2, 3, 4, 5);// 结果:// a = 1// b = 2// Array [ 3, 4, 5 ]foo(1);// 结果:// a = 1// b = undefined// Array [] rest参数只能写在最后，前面用…标识，从运行结果可知，传入的参数先绑定a、b，多余的参数以数组形式交给变量rest，所以，不再需要arguments我们就获取了全部参数。 如果传入的参数连正常定义的参数都没填满，也不要紧，rest参数会接收一个空数组（注意不是undefined）。 全局作用域不在任何函数内定义的变量就具有全局作用域。实际上，JavaScript默认有一个全局对象window，全局作用域的变量实际上被绑定到window的一个属性 你可能猜到了，由于函数定义有两种方式，以变量方式var foo = function () {}定义的函数实际上也是一个全局变量，因此，顶层函数的定义也被视为一个全局变量，并绑定到window对象：'use strict';function foo() &#123; alert('foo');&#125;foo(); // 直接调用foo()window.foo(); // 通过window.foo()调用 名字空间全局变量会绑定到window上，不同的JavaScript文件如果使用了相同的全局变量，或者定义了相同名字的顶层函数，都会造成命名冲突，并且很难被发现。 减少冲突的一个方法是把自己的所有变量和函数全部绑定到一个全局变量中。例如：// 唯一的全局变量MYAPP:var MYAPP = &#123;&#125;;// 其他变量:MYAPP.name = 'myapp';MYAPP.version = 1.0;// 其他函数:MYAPP.foo = function () &#123; return 'foo';&#125;; 把自己的代码全部放入唯一的名字空间MYAPP中，会大大减少全局变量冲突的可能。 许多著名的JavaScript库都是这么干的：jQuery，YUI，underscore等等。 局部作用域由于JavaScript的变量作用域实际上是函数内部，我们在for循环等语句块中是无法定义具有局部作用域的变量的：'use strict';function foo() &#123; for (var i=0; i&lt;100; i++) &#123; // &#125; i += 100; // 仍然可以引用变量i&#125; 为了解决块级作用域，ES6引入了新的关键字let，用let替代var可以申明一个块级作用域的变量：'use strict';function foo() &#123; var sum = 0; for (let i=0; i&lt;100; i++) &#123; sum += i; &#125; // SyntaxError: i += 1;&#125; ES6标准引入了新的关键字const来定义常量，const与let都具有块级作用域. 解构赋值从ES6开始，JavaScript引入了解构赋值，可以同时对一组变量进行赋值如果数组本身还有嵌套，也可以通过下面的形式进行解构赋值，注意嵌套层次和位置要保持一致：let [x, [y, z]] = ['hello', ['JavaScript', 'ES6']];x; // 'hello'y; // 'JavaScript'z; // 'ES6' 解构赋值还可以忽略某些元素：let [, , z] = ['hello', 'JavaScript', 'ES6']; // 忽略前两个元素，只对z赋值第三个元素z; // 'ES6' 对一个对象进行解构赋值时，同样可以直接对嵌套的对象属性进行赋值，只要保证对应的层次是一致的：var person = &#123; name: '小明', age: 20, gender: 'male', passport: 'G-12345678', school: 'No.4 middle school', address: &#123; city: 'Beijing', street: 'No.1 Road', zipcode: '100001' &#125;&#125;;var &#123;name, address: &#123;city, zip&#125;&#125; = person;name; // '小明'city; // 'Beijing'zip; // undefined, 因为属性名是zipcode而不是zip// 注意: address不是变量，而是为了让city和zip获得嵌套的address对象的属性:address; // Uncaught ReferenceError: address is not defined 使用解构赋值对对象属性进行赋值时，如果对应的属性不存在，变量将被赋值为undefined，这和引用一个不存在的属性获得undefined是一致的。如果要使用的变量名和属性名不一致，可以用下面的语法获取：var person = &#123; name: '小明', age: 20, gender: 'male', passport: 'G-12345678', school: 'No.4 middle school'&#125;;// 把passport属性赋值给变量id:let &#123;name, passport:id&#125; = person;name; // '小明'id; // 'G-12345678'// 注意: passport不是变量，而是为了让变量id获得passport属性:passport; // Uncaught ReferenceError: passport is not defined 解构赋值还可以使用默认值，这样就避免了不存在的属性返回undefined的问题：var person = &#123; name: '小明', age: 20, gender: 'male', passport: 'G-12345678'&#125;; // 如果person对象没有single属性，默认赋值为true:var &#123;name, single=true&#125; = person;name; // '小明'single; // true 有些时候，如果变量已经被声明了，再次赋值的时候，正确的写法也会报语法错误：// 声明变量:var x, y;// 解构赋值:&#123;x, y&#125; = &#123; name: '小明', x: 100, y: 200&#125;;// 语法错误: Uncaught SyntaxError: Unexpected token = 这是因为JavaScript引擎把{开头的语句当作了块处理，于是=不再合法。解决方法是用小括号括起来：(&#123;x, y&#125; = &#123; name: '小明', x: 100, y: 200&#125;); 使用场景 解构赋值在很多时候可以大大简化代码。例如，交换两个变量x和y的值，可以这么写，不再需要临时变量：var x=1, y=2;[x, y] = [y, x] 快速获取当前页面的域名和路径：var &#123;hostname:domain, pathname:path&#125; = location; 如果一个函数接收一个对象作为参数，那么，可以使用解构直接把对象的属性绑定到变量中。例如，下面的函数可以快速创建一个Date对象：function buildDate(&#123;year, month, day, hour=0, minute=0, second=0&#125;) &#123; return new Date(year + '-' + month + '-' + day + ' ' + hour + ':' + minute + ':' + second);&#125; 它的方便之处在于传入的对象只需要year、month和day这三个属性：buildDate(&#123; year: 2017, month: 1, day: 1 &#125;);// Sun Jan 01 2017 00:00:00 GMT+0800 (CST) 也可以传入hour、minute和second属性：buildDate(&#123; year: 2017, month: 1, day: 1, hour: 20, minute: 15 &#125;);// Sun Jan 01 2017 20:15:00 GMT+0800 (CST) 使用解构赋值可以减少代码量，但是，需要在支持ES6解构赋值特性的现代浏览器中才能正常运行。目前支持解构赋值的浏览器包括Chrome，Firefox，Edge等。 方法this、apply和call在一个方法内部，this是一个特殊变量，它始终指向当前对象'use strict';var xiaoming = &#123; name: '小明', birth: 1990, age: function () &#123; var y = new Date().getFullYear(); return y - this.birth; &#125;&#125;;var fn = xiaoming.age;fn(); // Uncaught TypeError: Cannot read property 'birth' of undefined this指针只在age方法的函数内指向xiaoming，在函数内部定义的函数，this又指向undefined了！（在非strict模式下，它重新指向全局对象window！） 'use strict';var xiaoming = &#123; name: '小明', birth: 1990, age: function () &#123; var that = this; // 在方法内部一开始就捕获this function getAgeFromBirth() &#123; var y = new Date().getFullYear(); return y - that.birth; // 用that而不是this &#125; return getAgeFromBirth(); &#125;&#125;;xiaoming.age(); // 25 用var that = this;，你就可以放心地在方法内部定义其他函数，而不是把所有语句都堆到一个方法中。 虽然在一个独立的函数调用中，根据是否是strict模式，this指向undefined或window，不过，我们还是可以控制this的指向的！ 要指定函数的this指向哪个对象，可以用函数本身的apply方法，它接收两个参数，第一个参数就是需要绑定的this变量，第二个参数是Array，表示函数本身的参数。 用apply修复getAge()调用：function getAge() &#123; var y = new Date().getFullYear(); return y - this.birth;&#125;var xiaoming = &#123; name: '小明', birth: 1990, age: getAge&#125;;xiaoming.age(); // 25getAge.apply(xiaoming, []); // 25, this指向xiaoming, 参数为空 另一个与apply()类似的方法是call()，唯一区别是： apply()把参数打包成Array再传入； call()把参数按顺序传入。 比如调用Math.max(3, 5, 4)，分别用apply()和call()实现如下：Math.max.apply(null, [3, 5, 4]); // 5Math.max.call(null, 3, 5, 4); // 5 对普通函数调用，我们通常把this绑定为null。 装饰器利用apply()，我们还可以动态改变函数的行为。 JavaScript的所有对象都是动态的，即使内置的函数，我们也可以重新指向新的函数。 现在假定我们想统计一下代码一共调用了多少次parseInt()，可以把所有的调用都找出来，然后手动加上count += 1，不过这样做太傻了。最佳方案是用我们自己的函数替换掉默认的parseInt()：'use strict';var count = 0;var oldParseInt = parseInt; // 保存原函数window.parseInt = function () &#123; count += 1; return oldParseInt.apply(null, arguments); // 调用原函数&#125;; 高阶函数JavaScript的函数其实都指向某个变量。既然变量可以指向函数，函数的参数能接收变量，那么一个函数就可以接收另一个函数作为参数，这种函数就称之为高阶函数。 mapmap()方法定义在JavaScript的Array中，我们调用Array的map()方法，传入我们自己的函数，就得到了一个新的Array作为结果'use strict';function pow(x) &#123; return x * x;&#125;var arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];var results = arr.map(pow); // [1, 4, 9, 16, 25, 36, 49, 64, 81]console.log(results); 注意：map()传入的参数是pow，即函数对象本身。 把Array的所有数字转为字符串：var arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];arr.map(String); // ['1', '2', '3', '4', '5', '6', '7', '8', '9'] 只需要一行代码。 reduceArray的reduce()把一个函数作用在这个Array的[x1, x2, x3…]上，这个函数必须接收两个参数，reduce()把结果继续和序列的下一个元素做累积计算，其效果就是：[x1, x2, x3, x4].reduce(f) = f(f(f(x1, x2), x3), x4) 要把[1, 3, 5, 7, 9]变换成整数13579，reduce()也能派上用场：var arr = [1, 3, 5, 7, 9];arr.reduce(function (x, y) &#123; return x * 10 + y;&#125;); // 13579 filterfilter也是一个常用的操作，它用于把Array的某些元素过滤掉，然后返回剩下的元素。 和map()类似，Array的filter()也接收一个函数。和map()不同的是，filter()把传入的函数依次作用于每个元素，然后根据返回值是true还是false决定保留还是丢弃该元素。 把一个Array中的空字符串删掉，可以这么写：var arr = ['A', '', 'B', null, undefined, 'C', ' '];var r = arr.filter(function (s) &#123; return s &amp;&amp; s.trim(); // 注意：IE9以下的版本没有trim()方法&#125;);r; // ['A', 'B', 'C'] filter()接收的回调函数，其实可以有多个参数。通常我们仅使用第一个参数，表示Array的某个元素。回调函数还可以接收另外两个参数，表示元素的位置和数组本身：var arr = ['A', 'B', 'C'];var r = arr.filter(function (element, index, self) &#123; console.log(element); // 依次打印'A', 'B', 'C' console.log(index); // 依次打印0, 1, 2 console.log(self); // self就是变量arr return true;&#125;); 利用filter，可以巧妙地去除Array的重复元素：'use strict';var r, arr = ['apple', 'strawberry', 'banana', 'pear', 'apple', 'orange', 'orange', 'strawberry'];r = arr.filter(function (element, index, self) &#123; return self.indexOf(element) === index;&#125;);console.log(r.toString()); 去除重复元素依靠的是indexOf总是返回第一个元素的位置，后续的重复元素位置与indexOf返回的位置不相等，因此被filter滤掉了。 sort()sort()方法会直接对Array进行修改，它返回的结果仍是当前Array：var a1 = ['B', 'A', 'C'];var a2 = a1.sort();a1; // ['A', 'B', 'C']a2; // ['A', 'B', 'C']a1 === a2; // true, a1和a2是同一对象 闭包高阶函数除了可以接受函数作为参数外，还可以把函数作为结果值返回。 返回闭包时牢记的一点就是：返回函数不要引用任何循环变量，或者后续会发生变化的变量如果一定要引用循环变量怎么办？方法是再创建一个函数，用该函数的参数绑定循环变量当前的值，无论该循环变量后续如何更改，已绑定到函数参数的值不变：function count() &#123; var arr = []; for (var i=1; i&lt;=3; i++) &#123; arr.push((function (n) &#123; return function () &#123; return n * n; &#125; &#125;)(i)); &#125; return arr;&#125;var results = count();var f1 = results[0];var f2 = results[1];var f3 = results[2];f1(); // 1f2(); // 4f3(); // 9 注意这里用了一个“创建一个匿名函数并立刻执行”的语法：(function (x) &#123; return x * x;&#125;)(3); // 9 理论上讲，创建一个匿名函数并立刻执行可以这么写：function (x) &#123; return x * x &#125; (3); 但是由于JavaScript语法解析的问题，会报SyntaxError错误，因此需要用括号把整个函数定义括起来：(function (x) &#123; return x * x &#125;) (3); 通常，一个立即执行的匿名函数可以把函数体拆开，一般这么写：(function (x) &#123; return x * x;&#125;)(3) 闭包有非常强大的功能。举个栗子： 在面向对象的程序设计语言里，比如Java和C++，要在对象内部封装一个私有变量，可以用private修饰一个成员变量。 在没有class机制，只有函数的语言里，借助闭包，同样可以封装一个私有变量。我们用JavaScript创建一个计数器：'use strict';function create_counter(initial) &#123; var x = initial || 0; return &#123; inc: function () &#123; x += 1; return x; &#125; &#125;&#125; 它用起来像这样：var c1 = create_counter();c1.inc(); // 1c1.inc(); // 2c1.inc(); // 3var c2 = create_counter(10);c2.inc(); // 11c2.inc(); // 12c2.inc(); // 13 在返回的对象中，实现了一个闭包，该闭包携带了局部变量x，并且，从外部代码根本无法访问到变量x。换句话说，闭包就是携带状态的函数，并且它的状态可以完全对外隐藏起来。 闭包还可以把多参数的函数变成单参数的函数。例如，要计算xy可以用Math.pow(x, y)函数，不过考虑到经常计算x2或x3，我们可以利用闭包创建新的函数pow2和pow3：'use strict';function make_pow(n) &#123; return function (x) &#123; return Math.pow(x, n); &#125;&#125;// 创建两个新函数:var pow2 = make_pow(2);var pow3 = make_pow(3);console.log(pow2(5)); // 25console.log(pow3(7)); // 343 使用闭包的注意点： 1）由于闭包会使得函数中的变量都被保存在内存中，内存消耗很大，所以不能滥用闭包，否则会造成网页的性能问题，在IE中可能导致内存泄露。解决方法是，在退出函数之前，将不使用的局部变量全部删除。 2）闭包会在父函数外部，改变父函数内部变量的值。所以，如果你把父函数当作对象（object）使用，把闭包当作它的公用方法（Public Method），把内部变量当作它的私有属性（private value），这时一定要小心，不要随便改变父函数内部变量的值。 闭包的思考关于闭包的总结也可以再看下这篇文章：学习Javascript闭包（Closure） 上面提到的这篇文章的最后，列出了一道思考题：如果你能理解下面两段代码的运行结果，应该就算理解闭包的运行机制了。代码片段一。var name = \"The Window\";var object = &#123; name : \"My Object\", getNameFunc : function()&#123; return function()&#123; return this.name; &#125;; &#125;&#125;;alert(object.getNameFunc()()); 代码片段二。var name = \"The Window\";var object = &#123; name : \"My Object\", getNameFunc : function()&#123; var that = this; return function()&#123; return that.name; &#125;; &#125;&#125;;alert(object.getNameFunc()()); 我先说结果，代码段一的结果是：The Window；而代码段二的结果是：My Object。 关于this关键字，前面已经介绍过了，它代表的实例会根据环境不同而变化的. In JavaScript this always refers to the “owner” of the function we’re executing, or rather, to the object that a function is a method of. 上面这段话，摘自：The this keyword。 我理解的意思是，this永远指向我们要执行的方法的“owner”，或者更确切的说，是指向function作为某个object的一个方法（method）的那个object。 在代码片段一里，object.getNameFunc()返回的是function，假设是f，那么:alert(object.getNameFunc()()); 等价于===》 alert(f());f()的执行已经和object没有关系了，this这里应该指向的是window对象，所以name值应该是：”The Window”。 在代码片段二里，在object.getNameFunc()执行的时候，this代表object对象，用that变量（that不是关键字）保存了起来，而最里面的这个function是可以访问that变量的，那么alert(object.getNameFunc()()); 应该等价于===》 alert(f(that));所以name的值应该是：“My Object”。 箭头函数ES6标准新增了一种新的函数：Arrow Function（箭头函数）。箭头函数有两种格式，一种像上面的，只包含一个表达式，连{ … }和return都省略掉了。还有一种可以包含多条语句，这时候就不能省略{ … }和return：。如果参数不是一个，就需要用括号()括起来：// 两个参数:(x, y) =&gt; x * x + y * y// 无参数:() =&gt; 3.14// 可变参数:(x, y, ...rest) =&gt; &#123; var i, sum = x + y; for (i=0; i&lt;rest.length; i++) &#123; sum += rest[i]; &#125; return sum;&#125; 如果要返回一个对象，就要注意，如果是单表达式，这么写的话会报错：// SyntaxError:x =&gt; &#123; foo: x &#125; 因为和函数体的{ … }有语法冲突，所以要改为：// ok:x =&gt; (&#123; foo: x &#125;) this 箭头函数看上去是匿名函数的一种简写，但实际上，箭头函数和匿名函数有个明显的区别：箭头函数内部的this是词法作用域，由上下文确定。 回顾前面的例子，由于JavaScript函数对this绑定的错误处理，下面的例子无法得到预期结果：var obj = &#123; birth: 1990, getAge: function () &#123; var b = this.birth; // 1990 var fn = function () &#123; return new Date().getFullYear() - this.birth; // this指向window或undefined &#125;; return fn(); &#125;&#125;; 现在，箭头函数完全修复了this的指向，this总是指向词法作用域，也就是外层调用者obj：var obj = &#123; birth: 1990, getAge: function () &#123; var b = this.birth; // 1990 var fn = () =&gt; new Date().getFullYear() - this.birth; // this指向obj对象 return fn(); &#125;&#125;;obj.getAge(); // 25 如果使用箭头函数，以前的那种hack写法：var that = this; 就不再需要了。由于this在箭头函数中已经按照词法作用域绑定了，所以，用call()或者apply()调用箭头函数时，无法对this进行绑定，即传入的第一个参数被忽略：var obj = &#123; birth: 1990, getAge: function (year) &#123; var b = this.birth; // 1990 var fn = (y) =&gt; y - this.birth; // this.birth仍是1990 return fn.call(&#123;birth:2000&#125;, year); &#125;&#125;;obj.getAge(2015); // 25 关于箭头函数中this的解释，可以看这篇文章：箭头函数中this的用法和深入浅出ES6（七）：箭头函数 Arrow Functions这篇 标准对象总结一下，有这么几条规则需要遵守： 不要使用new Number()、new Boolean()、new String()创建包装对象； 用parseInt()或parseFloat()来转换任意类型到number； 用String()来转换任意类型到string，或者直接调用某个对象的toString()方法； 通常不必把任意类型转换为boolean再判断，因为可以直接写if (myVar) {…}； typeof操作符可以判断出number、boolean、string、function和undefined； 判断Array要使用Array.isArray(arr)； 判断null请使用myVar === null； 判断某个全局变量是否存在用typeof window.myVar === ‘undefined’； 函数内部判断某个变量是否存在用typeof myVar === ‘undefined’。 任何对象都有toString()方法吗？null和undefined就没有！确实如此，这两个特殊值要除外，虽然null还伪装成了object类型。 更细心的同学指出，number对象调用toString()报SyntaxError：123.toString(); // SyntaxError 遇到这种情况，要特殊处理一下：123..toString(); // '123', 注意是两个点！(123).toString(); // '123' Date对象 如果要创建一个指定日期和时间的Date对象，可以用：var d = new Date(2015, 5, 19, 20, 15, 30, 123); JavaScript的Date对象月份值从0开始，牢记0=1月，1=2月，2=3月，……，11=12月。 var d = Date.parse('2015-06-24T19:49:22.875+08:00');d; // 1435146562875 var d = new Date(1435146562875);d; // Wed Jun 24 2015 19:49:22 GMT+0800 (CST)d.getMonth(); // 5 使用Date.parse()时传入的字符串使用实际月份01~12，转换为Date对象后getMonth()获取的月份值为0~11。 要获取当前时间戳，可以用：'use strict';if (Date.now) &#123; console.log(Date.now()); // 老版本IE没有now()方法&#125; else &#123; console.log(new Date().getTime());&#125; RegExp， 正则表达式的内容参考：标准对象-RegExp 构造函数除了直接用{ … }创建一个对象外，JavaScript还可以用一种构造函数的方法来创建对象。它的用法是，先定义一个构造函数：function Student(name) &#123; this.name = name; this.hello = function () &#123; alert('Hello, ' + this.name + '!'); &#125;&#125; 你会问，咦，这不是一个普通函数吗？ 这确实是一个普通函数，但是在JavaScript中，可以用关键字new来调用这个函数，并返回一个对象：var xiaoming = new Student('小明');xiaoming.name; // '小明'xiaoming.hello(); // Hello, 小明! 注意，如果不写new，这就是一个普通函数，它返回undefined。但是，如果写了new，它就变成了一个构造函数，它绑定的this指向新创建的对象，并默认返回this，也就是说，不需要在最后写return this;。 新创建的xiaoming的原型链是：xiaoming ----&gt; Student.prototype ----&gt; Object.prototype ----&gt; null xiaoming的原型指向函数Student的原型。如果你又创建了xiaohong、xiaojun，那么这些对象的原型与xiaoming是一样的：xiaoming ↘xiaohong -→ Student.prototype ----&gt; Object.prototype ----&gt; nullxiaojun ↗ 用new Student()创建的对象还从原型上获得了一个constructor属性，它指向函数Student本身：xiaoming.constructor === Student.prototype.constructor; // trueStudent.prototype.constructor === Student; // trueObject.getPrototypeOf(xiaoming) === Student.prototype; // truexiaoming instanceof Student; // true 看晕了吧？用一张图来表示这些乱七八糟的关系就是： 不过还有一个小问题，注意观察：xiaoming.name; // '小明'xiaohong.name; // '小红'xiaoming.hello; // function: Student.hello()xiaohong.hello; // function: Student.hello()xiaoming.hello === xiaohong.hello; // false xiaoming和xiaohong各自的name不同，这是对的，否则我们无法区分谁是谁了。 xiaoming和xiaohong各自的hello是一个函数，但它们是两个不同的函数，虽然函数名称和代码都是相同的！ 如果我们通过new Student()创建了很多对象，这些对象的hello函数实际上只需要共享同一个函数就可以了，这样可以节省很多内存。 要让创建的对象共享一个hello函数，根据对象的属性查找原则，我们只要把hello函数移动到xiaoming、xiaohong这些对象共同的原型上就可以了，也就是Student.prototype： 修改代码如下：function Student(name) &#123; this.name = name;&#125;Student.prototype.hello = function () &#123; alert('Hello, ' + this.name + '!');&#125;; 忘记写new怎么办 如果一个函数被定义为用于创建对象的构造函数，但是调用时忘记了写new怎么办？ 在strict模式下，this.name = name将报错，因为this绑定为undefined，在非strict模式下，this.name = name不报错，因为this绑定为window，于是无意间创建了全局变量name，并且返回undefined，这个结果更糟糕。 所以，调用构造函数千万不要忘记写new。为了区分普通函数和构造函数，按照约定，构造函数首字母应当大写，而普通函数首字母应当小写，这样，一些语法检查工具如jslint将可以帮你检测到漏写的new。 最后，我们还可以编写一个createStudent()函数，在内部封装所有的new操作。一个常用的编程模式像这样：function Student(props) &#123; this.name = props.name || '匿名'; // 默认值为'匿名' this.grade = props.grade || 1; // 默认值为1&#125;Student.prototype.hello = function () &#123; alert('Hello, ' + this.name + '!');&#125;;function createStudent(props) &#123; return new Student(props || &#123;&#125;)&#125; 这个createStudent()函数有几个巨大的优点：一是不需要new来调用，二是参数非常灵活，可以不传，也可以这么传：var xiaoming = createStudent(&#123; name: '小明'&#125;);xiaoming.grade; // 1 如果创建的对象有很多属性，我们只需要传递需要的某些属性，剩下的属性可以用默认值。由于参数是一个Object，我们无需记忆参数的顺序。如果恰好从JSON拿到了一个对象，就可以直接创建出xiaoming。 原型继承在传统的基于Class的语言如Java、C++中，继承的本质是扩展一个已有的Class，并生成新的Subclass。JavaScript由于采用原型继承，我们无法直接扩展一个Class，因为根本不存在Class这种类型。但是办法还是有的。 我们还是用上面的Student函数，现在，我们要基于Student扩展出PrimaryStudent，可以先定义出PrimaryStudent：function PrimaryStudent(props) &#123; // 调用Student构造函数，绑定this变量: Student.call(this, props); this.grade = props.grade || 1;&#125; 但是，调用了Student构造函数不等于继承了Student，PrimaryStudent创建的对象的原型是：new PrimaryStudent() ----&gt; PrimaryStudent.prototype ----&gt; Object.prototype ----&gt; null 必须想办法把原型链修改为：new PrimaryStudent() ----&gt; PrimaryStudent.prototype ----&gt; Student.prototype ----&gt; Object.prototype ----&gt; null 我们必须借助一个中间对象来实现正确的原型链，这个中间对象的原型要指向Student.prototype。为了实现这一点，参考道爷（就是发明JSON的那个道格拉斯）的代码，中间对象可以用一个空函数F来实现：// PrimaryStudent构造函数:function PrimaryStudent(props) &#123; Student.call(this, props); this.grade = props.grade || 1;&#125;// 空函数F:function F() &#123;&#125;// 把F的原型指向Student.prototype:F.prototype = Student.prototype;// 把PrimaryStudent的原型指向一个新的F对象，F对象的原型正好指向Student.prototype:PrimaryStudent.prototype = new F();// 把PrimaryStudent原型的构造函数修复为PrimaryStudent:PrimaryStudent.prototype.constructor = PrimaryStudent;// 继续在PrimaryStudent原型（就是new F()对象）上定义方法：PrimaryStudent.prototype.getGrade = function () &#123; return this.grade;&#125;;// 创建xiaoming:var xiaoming = new PrimaryStudent(&#123; name: '小明', grade: 2&#125;);xiaoming.name; // '小明'xiaoming.grade; // 2// 验证原型:xiaoming.__proto__ === PrimaryStudent.prototype; // truexiaoming.__proto__.__proto__ === Student.prototype; // true// 验证继承关系:xiaoming instanceof PrimaryStudent; // truexiaoming instanceof Student; // true 用一张图来表示新的原型链： 注意，函数F仅用于桥接，我们仅创建了一个new F()实例，而且，没有改变原有的Student定义的原型链。 如果把继承这个动作用一个inherits()函数封装起来，还可以隐藏F的定义，并简化代码：function inherits(Child, Parent) &#123; var F = function () &#123;&#125;; F.prototype = Parent.prototype; Child.prototype = new F(); Child.prototype.constructor = Child;&#125; 这个inherits()函数可以复用：function Student(props) &#123; this.name = props.name || 'Unnamed';&#125;Student.prototype.hello = function () &#123; alert('Hello, ' + this.name + '!');&#125;function PrimaryStudent(props) &#123; Student.call(this, props); this.grade = props.grade || 1;&#125;// 实现原型继承链:inherits(PrimaryStudent, Student);// 绑定其他方法到PrimaryStudent原型:PrimaryStudent.prototype.getGrade = function () &#123; return this.grade;&#125;; 总结JavaScript的原型继承实现方式就是： 定义新的构造函数，并在内部用call()调用希望“继承”的构造函数，并绑定this； 借助中间函数F实现原型链继承，最好通过封装的inherits函数完成； 继续在新的构造函数的原型上定义新方法。 class继承上面的我们看到了JavaScript的对象模型是基于原型实现的，特点是简单，缺点是理解起来比传统的类－实例模型要困难，最大的缺点是继承的实现需要编写大量代码，并且需要正确实现原型链。 新的关键字class从ES6开始正式被引入到JavaScript中。class的目的就是让定义类更简单。 如果用新的class关键字来编写Student，可以这样写：class Student &#123; constructor(name) &#123; this.name = name; &#125; hello() &#123; alert('Hello, ' + this.name + '!'); &#125;&#125; 比较一下就可以发现，class的定义包含了构造函数constructor和定义在原型对象上的函数hello()（注意没有function关键字），这样就避免了Student.prototype.hello = function () {…}这样分散的代码。 最后，创建一个Student对象代码和前面章节完全一样：var xiaoming = new Student('小明');xiaoming.hello(); class继承原型继承的中间对象，原型对象的构造函数等等都不需要考虑了，直接通过extends来实现：class PrimaryStudent extends Student &#123; constructor(name, grade) &#123; super(name); // 记得用super调用父类的构造方法! this.grade = grade; &#125; myGrade() &#123; alert('I am at grade ' + this.grade); &#125;&#125; 注意PrimaryStudent的定义也是class关键字实现的，而extends则表示原型链对象来自Student。子类的构造函数可能会与父类不太相同，例如，PrimaryStudent需要name和grade两个参数，并且需要通过super(name)来调用父类的构造函数，否则父类的name属性无法正常初始化。 PrimaryStudent已经自动获得了父类Student的hello方法，我们又在子类中定义了新的myGrade方法。 ES6引入的class和原有的JavaScript原型继承有什么区别呢？实际上它们没有任何区别，class的作用就是让JavaScript引擎去实现原来需要我们自己编写的原型链代码。简而言之，用class的好处就是极大地简化了原型链代码。 你一定会问，class这么好用，能不能现在就用上？ 现在用还早了点，因为不是所有的主流浏览器都支持ES6的class。如果一定要现在就用上，就需要一个工具把class代码转换为传统的prototype代码，可以试试Babel这个工具。 操作DOM由于HTML文档被浏览器解析后就是一棵DOM树，要改变HTML的结构，就需要通过JavaScript来操作DOM。 始终记住DOM是一个树形结构。操作一个DOM节点实际上就是这么几个操作： 更新：更新该DOM节点的内容，相当于更新了该DOM节点表示的HTML的内容； 遍历：遍历该DOM节点下的子节点，以便进行进一步操作； 添加：在该DOM节点下新增一个子节点，相当于动态增加了一个HTML节点； 删除：将该节点从HTML中删除，相当于删掉了该DOM节点的内容以及它包含的所有子节点。 在操作一个DOM节点前，我们需要通过各种方式先拿到这个DOM节点。最常用的方法是document.getElementById()和document.getElementsByTagName()，以及CSS选择器document.getElementsByClassName()。 由于ID在HTML文档中是唯一的，所以document.getElementById()可以直接定位唯一的一个DOM节点。document.getElementsByTagName()和document.getElementsByClassName()总是返回一组DOM节点。要精确地选择DOM，可以先定位父节点，再从父节点开始选择，以缩小范围。 例如：// 返回ID为'test'的节点：var test = document.getElementById('test');// 先定位ID为'test-table'的节点，再返回其内部所有tr节点：var trs = document.getElementById('test-table').getElementsByTagName('tr');// 先定位ID为'test-div'的节点，再返回其内部所有class包含red的节点：var reds = document.getElementById('test-div').getElementsByClassName('red');// 获取节点test下的所有直属子节点:var cs = test.children;// 获取节点test下第一个、最后一个子节点：var first = test.firstElementChild;var last = test.lastElementChild; 第二种方法是使用querySelector()和querySelectorAll()，需要了解selector语法，然后使用条件来获取节点，更加方便：// 通过querySelector获取ID为q1的节点：var q1 = document.querySelector('#q1');// 通过querySelectorAll获取q1节点内的符合条件的所有节点：var ps = q1.querySelectorAll('div.highlighted &gt; p'); 注意：低版本的IE&lt;8不支持querySelector和querySelectorAll。IE8仅有限支持 严格地讲，我们这里的DOM节点是指Element，但是DOM节点实际上是Node，在HTML中，Node包括Element、Comment、CDATA_SECTION等很多种，以及根节点Document类型，但是，绝大多数时候我们只关心Element，也就是实际控制页面结构的Node，其他类型的Node忽略即可。根节点Document已经自动绑定为全局变量document。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/10/22/JavaScript-knowledge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"JavaScript","slug":"javascript","permalink":"http://agehua.github.io/tags/javascript/"}]},{"title":"PBOC知识收集（干货）","slug":"PBOCKonwledgeCode","date":"2017-09-20T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/09/21/PBOCKonwledgeCode/","link":"","permalink":"http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/","excerpt":"PBOC规范基础知识（干货）摘自：《中国集成电路（IC）卡规范第2部分：电子钱包电子存折应用规范》\n消费交易消费交易允许持卡人使用电子存折或电子钱包的余额进行购物或获取服务。此交易可以在销售点终端(POS)上脱机进行。使用电子存折进行的消费交易必须提交个人识别码(PIN)，使用电子钱包则不需要。\n发出初始化消费(INITIALIZE FOR PURCHASE)命令指令字节：","text":"PBOC规范基础知识（干货）摘自：《中国集成电路（IC）卡规范第2部分：电子钱包电子存折应用规范》 消费交易消费交易允许持卡人使用电子存折或电子钱包的余额进行购物或获取服务。此交易可以在销售点终端(POS)上脱机进行。使用电子存折进行的消费交易必须提交个人识别码(PIN)，使用电子钱包则不需要。 发出初始化消费(INITIALIZE FOR PURCHASE)命令指令字节： 命令 CLA INS P1 P2消费初始化(INITIALIZE FOR PURCHASE) ‘80’ ‘50’ ‘01’ ‘0X’ 上面的指令字节，其实就是APDU（Application Protocol data unit), 是智能卡与智能卡读卡器之间传送的信息单元 APDU的格式为：CLA INS P1 P2 Lc Data Le其中CLA为指令类别；INS为指令码；P1、P2为参数；Lc为Data的长度；Le为希望响应时回答的数据字节数，0表最大可能长度。 COS命令由具体应用分为4种命令报文结构如下：① 情形1：CLA INS P1 P2 00② 情形2：CLA INS P1 P2 Le③ 情形3：CLA INS P1 P2 Lc Data④ 情形4：CLA INS P1 P2 Lc Data Le 而消费交易初始化的具体命令如下： 响应报文结构：响应数据 响应状态码Data SW1 SW1 DATA： 返回给用户的数据，即命令的执行结果。SW1、SW2： 返回命令处理的状态。 如果命令执行不成功，则只在响应报文中回送SW1和SW2。命令执行成功的状态字一般是“9000”，但个别卡商在执行成功后，返回61 xx，这里表示还有xx字节需要返回，需要再使用卡商提供的GET REPONSE命令接收从IC卡中传递向读卡设备的数据。 消费交易初始化执行成功，返回的响应报文，总长度是（Le 0F）15个字节： 一个字节是8bit，4个bit用一个16进制表示（0-9 A-F）。所以一个字节可以由两个16进制表示 VERIFY 命令定义和范围VERIFY命令用于校验命令数据域中的个人识别码的正确性。如PIN文件位于某一应用下，当此应用被锁定时，禁止校验PIN;如PIN文件位于MF下，当应用被锁 定后可以执行校验PIN命令。 命令报文 代码 值 CLA ‘00’ INS ‘20’ P1 ‘00’ P2 ‘00’ Lc 可变 Data 外部输入的个人识别码 Le 不存在 P2=’00’表示无特殊限定符被使用。在IC卡上，VERIFY命令在处理过程中应明确知道如何去寻找个人识别码。 这里外部输入的PIN码长度是，4到12位（2-6字节），响应报文数据域不存在。 此命令执行成功的状态字是“9000”。当前的应用选择中，命令数据域中外部输入的个人识别码与卡中存放的个人识别码校验失败时，IC 卡将回送SW2=’Cx’，其中’x’表示个人识别码允许重试的次数;当卡回送’C0’时，表示不能重试个人识别 码。此时再使用VERIFY命令时，将回送失败状态字SW1 SW2=“6983”。 IC卡可能回送的警告状态字见表48。 工具代码下面贴一些转换工具代码：/** * 把16进制字符串转换成字节数组 * * @param hex * @return */public static byte[] hexStringToByte(String hex) &#123; int len = (hex.length() / 2); byte[] result = new byte[len]; char[] achar = hex.toCharArray(); for (int i = 0; i &lt; len; i++) &#123; int pos = i * 2; result[i] = (byte) (toByte(achar[pos]) &lt;&lt; 4 | toByte(achar[pos + 1])); &#125; return result;&#125;private static byte toByte(char c) &#123; byte b = (byte) \"0123456789ABCDEF\".indexOf(c); return b;&#125;/** * 把字节数组转换成16进制字符串 * * @param bArray * @return */public static final String bytesToHexString(byte[] bArray) &#123; if(bArray == null ) &#123; return \"\"; &#125; StringBuffer sb = new StringBuffer(bArray.length); String sTemp; for (int i = 0; i &lt; bArray.length; i++) &#123; sTemp = Integer.toHexString(0xFF &amp; bArray[i]); if (sTemp.length() &lt; 2) sb.append(0); sb.append(sTemp.toUpperCase()); &#125; return sb.toString();&#125; IC卡交易金额转换（以分为单位，输出byte[]）public static String IntToHex(int n)&#123; char[] ch = new char[20]; int nIndex = 0; while ( true )&#123; int m = n/16; int k = n%16; if ( k == 15 ) ch[nIndex] = 'F'; else if ( k == 14 ) ch[nIndex] = 'E'; else if ( k == 13 ) ch[nIndex] = 'D'; else if ( k == 12 ) ch[nIndex] = 'C'; else if ( k == 11 ) ch[nIndex] = 'B'; else if ( k == 10 ) ch[nIndex] = 'A'; else ch[nIndex] = (char)('0' + k); nIndex++; if ( m == 0 ) break; n = m; &#125; StringBuffer sb = new StringBuffer(); sb.append(ch, 0, nIndex); sb.reverse(); String strHex = new String(\"\"); strHex += sb.toString(); return strHex;&#125;public static byte[] hexStringToByteArray(String s) &#123; if (TextUtils.isEmpty(s)) return null; int len = s.length(); String append= \"\"; switch (len)&#123; case 1: s = \"0000000\"+s; break; case 2: s = \"000000\"+s; break; case 3: s = \"00000\"+s; break; case 4: s = \"0000\"+s; break; case 5: s = \"000\"+s; break; case 6: s = \"00\"+s; break; case 7: s = \"0\"+s; break; case 8: break; &#125; len = s.length(); byte[] b = new byte[len / 2]; for (int i = 0; i &lt; len; i += 2) &#123; // 两位一组，表示一个字节,把这样表示的16进制字符串，还原成一个字节 b[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) &lt;&lt; 4) + Character .digit(s.charAt(i + 1), 16)); &#125; return b;&#125;/** * 交易金额转换 */public static byte[] intTo4HexByte(int num)&#123; return hexStringToByteArray(IntToHex(num));&#125; Hex字符串转换为GBKpublic static String decode(String hexStr) throws UnsupportedEncodingException &#123; if (null == hexStr || \"\".equals(hexStr) || (hexStr.length()) % 2 != 0) &#123; return null; &#125; int byteLength = hexStr.length() / 2; byte[] bytes = new byte[byteLength]; int temp = 0; for (int i = 0; i &lt; byteLength; i++) &#123; temp = hex2Dec(hexStr.charAt(2 * i)) * 16 + hex2Dec(hexStr.charAt(2 * i + 1)); bytes[i] = (byte) (temp &lt; 128 ? temp : temp - 256); &#125; return new String(bytes,\"GBK\");&#125;private static int hex2Dec(char ch) &#123; if (ch == '0') return 0; if (ch == '1') return 1; if (ch == '2') return 2; if (ch == '3') return 3; if (ch == '4') return 4; if (ch == '5') return 5; if (ch == '6') return 6; if (ch == '7') return 7; if (ch == '8') return 8; if (ch == '9') return 9; if (ch == 'a') return 10; if (ch == 'A') return 10; if (ch == 'B') return 11; if (ch == 'b') return 11; if (ch == 'C') return 12; if (ch == 'c') return 12; if (ch == 'D') return 13; if (ch == 'd') return 13; if (ch == 'E') return 14; if (ch == 'e') return 14; if (ch == 'F') return 15; if (ch == 'f') return 15; else return -1;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"PBOC","slug":"pboc","permalink":"http://agehua.github.io/tags/pboc/"},{"name":"PBOC 2.0","slug":"pboc-2-0","permalink":"http://agehua.github.io/tags/pboc-2-0/"}]},{"title":"PBOC知识收集","slug":"PBOCKonwledge","date":"2017-09-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/09/12/PBOCKonwledge/","link":"","permalink":"http://agehua.github.io/2017/09/12/PBOCKonwledge/","excerpt":"PBOC规范基础知识术语和定义\n集成电路 integrated circuit (IC) 具有处理和/或存储功能的电子器件。\n集成电路卡(IC 卡) integrated circuit(s) card (ICC) 内部封装一个或多个集成电路用于执行处理和存储功能的卡片。\n电子存折 electronic deposit 一种为持卡人进行消费、取现等交易而设计的支持个人识别码(PIN)保护的金融IC卡应用。它支持圈存、圈提、消费和取现等交易。\n电子钱包 electronic purse 一种为方便持卡人小额消费而设计的金融IC卡应用。它支持圈存、消费等交易。消费不支持个人识别码(PIN)保护。","text":"PBOC规范基础知识术语和定义 集成电路 integrated circuit (IC) 具有处理和/或存储功能的电子器件。 集成电路卡(IC 卡) integrated circuit(s) card (ICC) 内部封装一个或多个集成电路用于执行处理和存储功能的卡片。 电子存折 electronic deposit 一种为持卡人进行消费、取现等交易而设计的支持个人识别码(PIN)保护的金融IC卡应用。它支持圈存、圈提、消费和取现等交易。 电子钱包 electronic purse 一种为方便持卡人小额消费而设计的金融IC卡应用。它支持圈存、消费等交易。消费不支持个人识别码(PIN)保护。 圈存 load持卡人将其在银行相应账户上的资金划转到电子存折或电子钱包中。圈存交易必须在金融终端上联机进行。一般情况下，圈存到电子存折中的资金仍计付活期利息，圈存到电子钱包中的资金不计付利息。但 具体作法由发卡方自行决定。 圈提 unload持卡人将电子存折中的部分或全部资金划回到其在银行的相应账户上。圈提交易必须在金融终端上 联机进行2。 符号和缩略语下列符号和缩略语适用于 JR/T 0025 的本部分。 AID 应用标识符(Application Identifier) an 字母数字型(Alphanumeric) ans 字母数字及特殊字符型(Alphanumeric Special) ATI 应用类型标识(Application Type Identifier)，卡上有两种应用时，用来区分是电子存折和电子钱包 b 二进制(Binary) CLA 命令报文的类别字节(Class Byte of the Command Message) cn 压缩数字型(Compressed Numeric) DEA 数据加密算法(Data Encryption Algorithm) DF 专用文件(Dedicated File) ED 电子存折(Electronic Deposit) EF 基本文件(Elementary File) EP 电子钱包(Electronic Purse) FCI 文件控制信息(File Control Information) INS 命令报文的指令字节(Instruction Byte of Command Message) ISO 国际标准化组织(International Organization for Standardization) Lc 终端发出的命令数据的实际长度(Exact Length of Data Sent) Le 响应数据中的最大期望长度(Maximum Length of Data Expected) MAC 报文鉴别码(Message Authentication Code) MF 主文件(Master File) n 数字型(Numeric) P1 参数 1(Parameter 1) P2 参数 2(Parameter 2) PIN 个人识别码(Personal Identification Number) POS 销售点终端(Point of Service) PSAM 销售点终端安全存取模块(Purchase Secure Access Module) PSE 支付系统环境(Payment System Environment) PVN PIN 校验值(PIN Verification Number) SFI 短文件标识符(Short File Identifier) SW1 状态字 1(Status Word One) SW2 状态字 2(Status Word Two) TAC 交易验证码(Transaction Authorization Crypogram) TTI 交易类型标识(Transaction Type Identifier) YYYYMMDD 年、月、日(Year, Month, Day) 智能卡又称为IC卡(Integrated circuit Card),即集成电路卡。根据卡中使用的集成电路的不同可以分为存储器卡、逻辑加密卡和CPU卡。由于CPU卡中集成了中央处理器CPU、存储器和芯片操作系统(Chip Operating System, COS) ,构成一个完整的计算机系统, 具有独立的数据处理能力, 因此安全性大大增强,从而得到了广泛的应用,成为IC卡中的主流产品。 文件操作2.1 基本文件结构文件系统是COS的基础模块,它负责组织、管理、维护IC卡内存储的所有数据。根据ISO7816-4,COS 支持的文件类型为: 主文件(Master File, MF) 、目录文件(Dedicated File, DF)和基本文件(Elementary File,EF) 。主文件MF为文件系统的根，下面可以有多个目录文件DF和基本文件EF。目录文件DF分为DDF和ADF两种。DDF可以含有下级目录ADF, 而ADF不能含有下级目录文件。 主文件MF在IC卡中唯一且必须存在。DDF是指包含多个应用的DF, 一个ADF则代表一个应用, 任何一个DF在物理上和逻辑上都保持独立。基本文件EF用于存放密钥或用户数据, 分为密钥文件和工作基本文件。 三种专用文件(DF)类型:MF: 根目录，是整个文件系统的根，同属应用环境类。MF 下可以有 EF(基本文件)、SF (安全文件)、DDF(目录文件)、ADF(应用文件);DDF: 目录文件，用于定义一个应用环境，它是应用的集合。DDF下可以有ADF、子DDF、 EF和SF等结构。ADF: 应用文件，用于定义具体应用。ADF下可以有EF和SF。 2.2 文件的访问控制文件的访问控制可采取鉴别寄存器方式和状态机方式,这里以鉴别寄存器方式为例。用两个四位寄存器来表示安全状态: 一个寄存器称为MF的安全状态寄存器,另一个寄存器为当前DF的安全状态寄存器。每个寄存器的初始值是0,取值安全状态员安全状态圆执行命令符合命令要求的安全属性钥命令拒绝安全机制再晕图员智能卡安全体系范围是0～F之间的某一个值。文件有两种不同的访问控制权限AC0,AC1。AC0 是使用权限,AC1 是修改权限,分别用一个字节表示。当前安全状态寄存器的值大于AC字节的低半字节小于其高半字节时, 该文件的相应读、写权限在该安全状态下被满足,则能进行相关操作。COS在建立文件时指定其AC0和AC1的值来对文件的访问权限进行设定,通过口令校验和外部认证两条命令可以改变安全状态寄存器的值,从而利用安全机制实现对文件的访问控制。 命令的类别字节和指令字节 命令 CLA INS P1 P2 修改个人识别码(CHANGE PIN) ‘80’ ‘5E’ ‘01’ ‘00’ 圈存(CREDIT FOR LOAD) ‘80’ ‘52’ ‘00’ ‘00’ 消费/取现(DEBIT FOR PURCHASE/CASH WITHDRAW) ‘80’ ‘54’ ‘01’ ‘00’ 圈提(DEBIT FOR UNLOAD) ‘80’ ‘54’ ‘03’ ‘00’ 读余额(GET BALANCE) ‘80’ ‘5C’ ‘00’ ‘0X’ 取交易认证(GET TRANSACTION PROVE) ‘80’ ‘5A’ ‘00’ ‘XX’ 取现初始化(INITIALIZE FOR CASH WITHDRAW) ‘80’ ‘50’ ‘02’ ‘01’ 圈存初始化(INITIALIZE FOR LOAD) ‘80 ‘50’ ‘00’ ‘0X’ 消费初始化(INITIALIZE FOR PURCHASE) ‘80’ ‘50’ ‘01’ ‘0X’ 圈提初始化(INITIALIZE FOR UNLOAD) ‘80’ ‘50’ ‘05’ ‘01’ 修改初始化(INITIALIZE FOR UPDATE) ‘80’ ‘50’ ‘04’ ‘01’ 重装个人识别码(RELOAD PIN) ‘80’ ‘5E’ ‘00’ ‘00’ 修改透支限额(UPDATE OVERDRAW LIMIT) ‘80’ ‘58’ ‘00’ ‘00’ IC卡、M1卡、CPU卡、SAM卡、PSAM卡的联系与区别 一、 技术方面（非接触式IC卡） 1、 逻辑加密卡又叫存储卡，卡内的集成电路具有加密逻辑和EEPROM（电可擦除可编程只读存储器）。 2、 CPU卡又叫智能卡，卡内的集成电路包括中央处理器（CPU）、EEPROM、随机存储器(ROM)、以及固化在只读存储器（ROM）中的片内操作系统(COS)，有的卡内芯片还集成了加密运算协处理器以提高安全性和工作速度，使其技术指标远远高于逻辑加密卡。 3、 CPU卡由于具有微处理功能，使得在交易速度以及数据干扰方面远远高于逻辑加密卡，且允许多张卡片同时操作，具有防冲突机制。 4、 两者在技术方面的最大区别在于：CPU卡是一种具有微处理芯片的IC卡，可执行加密运算和其它操作，存储容量较大，能应用于不同的系统；逻辑加密卡是一种单一的存储卡，主要特点是内部有只读存储器，但存储容量较CPU卡小，使其在用途方面没有扩展性。 二、 保密方面（非接触式IC卡） 1、 逻辑加密卡具有防止对卡中信息随意改写功能的存储IC卡，当对加密卡进行操作时必须首先核对卡中密码，只有核对正确，卡中送出一串正确的应答信号时，才能对卡进行正确的操作，但由于只进行一次认证，且无其它的安全保护措施，容易导致密码的泄露和伪卡的产生，其安全性能很低。 2、 由于CPU卡中有微处理机和IC卡操作系统（COS），当CPU卡进行操作时，可进行加密和解密算法（算法和密码都不易破解），用户和IC卡系统之间需要进行多次的相互密码认证（且速度极快），提高了系统的安全性能，对于防止伪卡的产生有很好的效果。 综上所述，对于逻辑加密卡和CPU卡来说，CPU卡不仅具有逻辑加密卡的所有功能，更具有逻辑加密卡所不具备的高安全性、灵活性以及支持与应用扩展等优良性能，也是今后IC卡发展的主要趋势和方向。 CPU卡安全系统与逻辑加密系统的比较 众所周知，密钥管理系统（Key Management System），也简称KMS，是IC项目安全的核心。如何进行密钥的安全管理，贯穿着IC卡应用的整个生命周期。 1、 非接触逻辑加密卡的安全认证，依赖于每个扇区独立的KEYA和KEYB的校验，可以通过扇区控制字对KEYA和KEYB的不同安全组合，实现扇区数据的读写安全控制。非接触逻辑加密卡的个人化也比较简单，主要包括数据和各扇区KEYA、KEYB的更新，在期间所有敏感数据包括KEYA和KEYB都是直接以明文的形式更新。由于KEYA和KEYB的校验机制，只能解决卡片对终端的认证，而无法解决终端对卡片的认证，即我们俗称的“伪卡”的风险。接触逻辑加密卡，即密钥就是一个预先设定的确定数，无论用什么方法计算密钥，最后就一定要和原先写入的数一致，就可以对被保护的数据进行读写操作。因此无论是一卡一密的系统还是统一密码的系统，经过破解就可以实现对非接触逻辑加密卡的解密。很多人认为只要是采用了一卡一密、实时在线系统或非接触逻辑加密卡的ID号就能避免密钥被解密，其实，非接触逻辑加密卡被解密就意味着M1卡可以被复制，使用在线系统尽可以避免被非法充值，但是不能保证非法消费，即复制一张一样ID号的M1卡，就可以进行非法消费。现在的技术使用FPGA就可以完全复制。基于这个原理，M1的门禁卡也是不安全的。目前国内80%的门禁产品均是采用原始IC卡的ID号或ID卡的ID号去做门禁卡，根本没有去进行加密认证或开发专用的密钥，其安全隐患远远比Mifare卡的破解更危险，非法破解的人士只需采用的是专业的技术手段就可以完成破解过程，导致目前国内大多数门禁产品都不具备安全性原因之一，是因为早期门禁产品的设计理论是从国外引进过来的，国内大部分厂家长期以来延用国外做法，采用ID和IC卡的只读特性进行身份识别使用，很少关注卡与机具间的加密认证，缺少钥匙体系的设计；而ID卡是很容易可复制的载体，导致所有的门禁很容易几乎可以在瞬间被破解复制；这才是我们国内安防市场最大的灾难。 2、 非接触CPU卡智能卡与非接触逻辑加密卡相比，拥有独立的CPU处理器和芯片操作系统，所以可以更灵活的支持各种不同的应用需求，更安全的设计交易流程。但同时，与非接触逻辑加密卡系统相比，非接触CPU卡智能卡的系统显得更为复杂，需要进行更多的系统改造，比如密钥管理、交易流程、PSAM卡以及卡片个人化等。密钥通常分为充值密钥（ISAM卡），减值密钥（PSAM卡），外部认证密钥（SAM卡）和全能密钥（ASAM卡）。非接触CPU卡智能卡可以通过内外部认证的机制，例如像建设部定义的电子钱包的交易流程，高可靠的满足不同的业务流程对安全和密钥管理的需求。对电子钱包圈存可以使用圈存密钥，消费可以使用消费密钥，清算可以使用TAC密钥，更新数据可以使用卡片应用维护密钥，卡片个人化过程中可以使用卡片传输密钥、卡片主控密钥、应用主控密钥等，真正做到一钥一用。 SAM(Secure Access Module)安全存取模块介绍为什么要用SAM？究竟谁最开始使用SAM这个词，已经无从考证，能够确认的是：这个世界上先有了PSAM，然后才有了SAM。由于网络状况的原因，或者是应用环境的要求，使用IC卡作为支付介质的系统里面，消费环境不能在每次交易的时候，都做到实时与后台相连接认证IC卡的合法性以及交易完全性。因此，一种我们目前已经认可的交易模式——“电子钱包脱机消费”产生了。即便目前通讯技术发展到已经不存在技术障碍，在权衡风险、代价、方便性等等，我们还是要继续使用并发扬光大脱机消费这样一个模式。由此，就需要对发生交易的终端有所要求，一是能够鉴别IC卡的真伪，再者需要能够保证交易的合法性与安全性，本着不把终端制造商拉下水的目的，于是，坚持一个原则：终端设备与系统安全机制分离，即所有有关安全性的因素，都放置到一个叫PSAM卡里面，由系统发行方来发行管理。没有 PSAM卡的消费终端，相当于没有SIM卡的手机，安装PSAM卡以后，该消费终端就获得了系统运营商的许可，有权鉴别卡片的真伪，有权从卡上的钱包扣款。因此，PSAM的解释为：销售点终端安全存取模块（Purchase Secure Access Module）。 上述最初起源自金融领域 IC卡电子钱包支付系统中的消费应用。在迅猛发展，并极具想象力的IC卡行业，PSAM的应用模式很快得到了延伸，去掉了P（Purchase）的限制之后的SAM（Secure Access Module），被用于很多模式中，变成了“各种终端内嵌入的、认证及存储所有安全数据与敏感信息的设备”。SAM是一个统称，SAM可以是一张标准尺寸的IC卡大小，更多的时候还是符合ISO/IEC 7810里面ID-000标准的小卡形状，也可以是一个DIP8或者SOP8/16封装的IC集成电路形状。如同印章一样，放一个SAM到一个通用的设备里面，表明运营商获得这个设备的控制权和所有权，才能完成该终端赋予的各种功能。 CPU卡加密算法和随机数发生器与安装在读写设备中的密钥认证卡(SAM卡)相互发送认证的随机数，可以实现以下功能： 1）通过终端设备上SAM卡实现对卡的认证 2）CPU卡与终端设备上的SAM卡的相互认证，实现对卡终端的认证 3）通过ISAM卡对CPU卡进行充值操作，实现安全的储值 4）通过PSAM卡对CPU卡进行减值操作，实现安全的扣款 5）在终端设备与CPU卡中传输的数据是加密传输 6）通过对CPU卡发送给SAM卡的MAC1，SAM卡发送给CPU的MAC2和由CPU卡返回的TAC，可以实现数据传输验证的计算。而MAC1、MAC2和TAC就是同一张CPU卡每次传输的过程中都是不同的，因此无法使用空中接收的办法来破解CPU卡的密钥。 有几种SAM？ PSAM：放在脱机消费终端内，用来控制电子钱包脱机消费交易的SAM卡，通常是铳成ID-000的小卡形状，存放消费主密钥，能够验证用户卡上消费子密钥是否符合约定的对应关系，并且保证扣款过程的安全性。 ISAM：ISAM的出现并不具有典型意义，其中的I，可解释为Input，也可解释为Increase，放置在充值终端设备内，脱机充值交易中控制充值交易安全。说它不具有典型意义的原因是，脱机充值的模式是小额支付系统早期的模式，基于安全、风险、政策、技术发展等考虑，脱机充值应用在未来不会有生命力，因此， ISAM作为一个过渡产品，慢慢会成为历史。 ESAM，ESAM属于企业创造的新名词，其中的“E”代表一种形态，特指采用SOP或者DIP封装形式的SAM，作为设备原始设计的一部分，生产的时候焊接在设备的电路板上，不像是其他的SAM是在卡座内，可以灵活拆卸。ESAM的名字与功能无关，比如ESAM形式的PSAM或者ISAM，比如ESAM形式的电子钱包应用。都是符合逻辑的说法。ESAM有几种典型的应用：作为电子计数文件，在预付费表具内控制表具的运行。作为安全数据的存储与认证，实现硬件设备的版权保护与安全使用。 USAM： 是一个新产品，是基于已有SAM概念的基础上，进行的10%左右的创新而来，其中的“U”，大家一定比较容易猜到，即“USB”，是一个采用USB接口和通讯方式的SAM，在这里补充一下，前面所说的各种SAM的通讯方式都是符合ISO/IEC 7816中规定的接口和通讯协议。USAM是两种成熟技术结合，一种全新形态的产品。能大幅度提高SAM的效率与性能，减少设备开发工作量，使SAM的应用趋于标准化、开放性，也扩展了SAM的应用领域。 SAM的技术要求SAM是与终端设备配套使用的安全设备，它具备这样的几个基本要求： 1、是带有COS的CPU卡（模块）； 2、密钥安全的存储在卡内，在某种认可的权限下，能被用于运算，但是不能被直接读出； 3、高安全等级芯片，低功耗、宽电压、宽温度范围； 4、SAM最核心的要求是安全性； 5、SAM最重要的两个参数是运算速度和通讯速率； 对IC卡操作时，耗费时间最多的环节是通讯所占用的时间，而在IC卡应用系统中，尤其是非接触式的应用中，每一个毫秒的时间都是非常宝贵的，都会极大地影响用户感受，在高速公路不停车收费系统中，每增加一个毫秒，都意味着通行速度的大幅降低。 而采用USAM的最大特点在于：1、减少数据流通环节；2、提高数据通讯速度。 USAM直接插入标准USB接口即可使用，不用外接IC卡读写器或者需要SAM卡座；便于安装、使用； USAM比较适合用于：城市通卡、高速公路收费、金融领域、加油领域、预付费水电气表。 参考资料PSAM SAM：https://www.bbsmax.com/A/lk5aGpwPz1/ IC卡、M1卡、CPU卡、SAM卡、PSAM卡的联系与区别:https://www.bbsmax.com/A/8Bz8BRpx5x/ 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/09/12/PBOCKonwledge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"PBOC","slug":"pboc","permalink":"http://agehua.github.io/tags/pboc/"},{"name":"PBOC 2.0","slug":"pboc-2-0","permalink":"http://agehua.github.io/tags/pboc-2-0/"}]},{"title":"Android面试题积累","slug":"IntervieweeQuestions","date":"2017-08-16T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/08/17/IntervieweeQuestions/","link":"","permalink":"http://agehua.github.io/2017/08/17/IntervieweeQuestions/","excerpt":"1、Activity面试题1、Activity是什么Activity是四大组件之一，它提供一个界面让用户点击和各种滑动操作，这就是Activity\n2、Activity四种状态runingpausedstoppedkilled\n3、Activity生命周期onCreate()onStart()","text":"1、Activity面试题1、Activity是什么Activity是四大组件之一，它提供一个界面让用户点击和各种滑动操作，这就是Activity 2、Activity四种状态runingpausedstoppedkilled 3、Activity生命周期onCreate()onStart()onResume()onPause()onStop()onDestroy()onRestart() 4、进程的优先级空进程后台进程服务进程可见进程前台进程 5、Activity任务栈先进后出 6、Activity启动模式standardsingletopsingletask: 能够保证Activity A在栈中只有一个实例，这个栈也允许存在其他的实例. 特别需要注意的是使用startActivityForResult方法的时候，根据startActivityForResult的api说明: if the activity you are launching uses the singleTask launch mode, it will not run in your task and thus you will immediately receive a cancel result意思就是使用startActivityForResult方法启动一个singleTask模式的Activity，该Activity不会在原来的任务栈中启动，因此会立即收到一个RESULT_CANCELED结果 singleinstance: singleInstance要求activity的实例不仅只有一个，并且整个task中只有一个activity实例，而singleTask所在的栈中允许存在其他activity的实例。 singleInstance的activity也具有上面的特性，此外，activity设置了singleInstance，那么无论被启动的activity有没有设置singleInstance，都无法获取返回值 7、scheme跳转协议Android中的scheme是一种页面内跳转协议，通过定义自己的scheme协议，可以跳转到app中的各个页面服务器可以定制化告诉app跳转哪个页面App可以通过跳转到另一个App页面可以通过H5页面跳转页面（DeepLink）：&lt;a href=&quot;[scheme]://[host]/[path]?[query]&quot;&gt;启动应用程序&lt;/a&gt; &lt;intent-filter&gt; &lt;data android:scheme=\"http\" /&gt; &lt;!-- or you can use deep linking like --&gt; &lt;data android:scheme=\"http\" android:host=\"xyz.abc.com\"/&gt; &lt;action android:name=\"android.intent.action.VIEW\"/&gt; &lt;category android:name=\"android.intent.category.BROWSABLE\"/&gt; &lt;category android:name=\"android.intent.category.DEFAULT\"/&gt;&lt;/intent-filter&gt; 2、Fragment面试题1、Fragment为什么被称为第五大组件Fragment比Activity更节省内存，其切换模式也更加舒适，使用频率不低于四大组件，且有自己的生命周期，而且必须依附于Activity 2、Activity创建Fragment的方式静态创建：在activity布局文件里声明fragment，activity_main.xml中声明： 动态创建：通过java代码将fragment添加到已存的ViewGroup中fragment = new MyFragment();fragmentStack.push(fragment);transaction = manager.beginTransaction();transaction.add(R.id.fragments, fragment);transaction.commit(); 3、FragmentPageAdapter和FragmentStatePagerAdapter的区别FragmentPageAdapter在每次切换页面的的时候，是将Fragment进行分离，适合页面较少的Fragment使用以保存一些内存，对系统内存不会多大影响FragmentPagerAdapter 中所有创建过的Fragment都缓存在FragmentManager中；页面切换，只是调用detach，而不是remove，所以只执行onDestroyView，而不是onDestroy。 destroyItem的时候，调用detach从页面上移除fragment，内存中还有当前实例 FragmentStatePagerAdapter，使用 mFragments 在每次切换页面的时候，是将Fragment进行回收，适合页面较多的Fragment使用，这样就不会消耗更多的内存FragmentStatePagerAdapter缓存的个数是(mOffscreenPageLimit * 2 + 1)，而不是全部；页面切换，调用remove删除，且要缓存State。 destroyItem的时候，将当前fragment = null，直接销毁fragment 4、Fragment生命周期onAttach()onCreate()onCreateView()onActivityCreated()onStart()onResume()onPause()onStop()onDestroyView()onDestroy()onDetach() 5、Fragment的通信Fragment调用Activity中的方法：getActivityActivity调用Fragment中的方法：接口回调Fragment调用Fragment中的方法：FragmentManager.findFragmentById 6、Fragment的replace、add、remove方法replace：替代Fragment的栈顶页面add：添加Fragment到栈顶页面remove：移除Fragment栈顶页面 3、Service面试题1、Service是什么Service是四大组件之一，它可以在后台执行长时间运行操作而没有用户界面的应用组件 2、Service和Thread的区别Service是安卓中系统的组件，它运行在独立进程的主线程中，不可以执行耗时操作，超时会有ANR异常。Thread是程序执行的最小单元，分配CPU的基本单位，可以开启子线程执行耗时操作Service在不同Activity中可以获取自身实例，可以方便的对Service进行操作。Thread在不同的Activity中难以获取自身实例，如果Activity被销毁，Thread实例就很难再获取得到 3、Service启动方式startServicebindService 4、Service生命周期startService：onCreate()onStartCommand(Intent intent, int flags, int startId)onDestroy() 重点介绍下，onStartCommand()方法，先看下官方doc里的介绍：Added in API level 5Called by the system every time a client explicitly starts the service by calling startService(Intent), providing the arguments it supplied and a unique integer token representing the start request. Do not call this method directly.参数：intent: The Intent supplied to startService(Intent), as given. This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except START_STICKY_COMPATIBILITY.flags: Additional data about this start request. Currently either 0, START_FLAG_REDELIVERY, or START_FLAG_RETRY.startId: A unique integer representing this specific request to start. Use with stopSelfResult(int).返回值：The return value indicates what semantics the system should use for the service’s current started state. It may be one of the constants associated with the START_CONTINUATION_MASK bits.总结如下，onStartCommand()是当一个service调用startService()之后由系统调用的，开发者不用直接调用这个方法，但是可以重写这个方法。方法的返回值有四个int值，分别是：START_STICKY, START_NOT_STICKY, START_REDELIVER_INTENT, or START_STICKY_COMPATIBILITY. bindService：onCreate()onBind()onUnbind()onDestroy() 4、Broadcast Receiver面试题1、Broadcast Receiver是什么Broadcast是四大组件之一，是一种广泛运用在应用程序之间传输信息的机制，通过发送Intent来传送我们的数据 2、Broadcast Receiver的使用场景同一App具有多个进程的不同组件之间的消息通信不同App之间的组件之间的消息通信 3、Broadcast Receiver的种类普通广播有序广播 Context.sendOrderedBroadcast本地广播 LocalBroadcastManager.getInstance(context).sendBroadcast(intent) 除了能解决BroadcastReceiver进程间安全性问题外，相对Context操作的BroadcastReceiver而言还具有更高的运行效率。Sticky广播 的sendStickyBroadcast(Intent)接口发送，需要添加权限也可以通过Context的removeStickyBroadcast(Intent intent)接口移除缓存的粘性广播。sticky有序广播 StickyOrderedBroadcast 4、Broadcast Receiver的实现静态注册：注册后一直运行，尽管Activity、进程、App被杀死还是可以接收到广播动态注册：跟随Activity的生命周期 5、Broadcast Receiver实现机制自定义广播类继承BroadcastReceiver，复写onReceiver()通过Binder机制向AMS进行注册广播广播发送者通过Binder机制向AMS发送广播AMS查找符合相应条件的广播发送到BroadcastReceiver相应的循环队列中消息队列执行拿到广播，回调BroadcastReceiver的onReceiver() 6、LocalBroadcastManager特点本地广播只能在自身App内传播，不必担心泄漏隐私数据本地广播不允许其他App对你的App发送该广播，不必担心安全漏洞被利用本地广播比全局广播更高效以上三点都是源于其内部是用Handler实现的 5、WebView面试题1、WebView安全漏洞API16之前存在远程代码执行安全漏洞，该漏洞源于程序没有正确限制使用WebView.addJavascriptInterface方法，远程攻击者可通过使用Java反射机制利用该漏洞执行任意Java对象的方法 2、WebView销毁步骤WebView在其他容器上时（如：LinearLayout），当销毁Activity时，需要在onDestroy()中先移除容器上的WebView，然后再将WebView.destroy()，这样就不会导致内存泄漏 3、WebView的jsbridge客户端和服务端之间可以通过Javascript来互相调用各自的方法 4、WebViewClient的onPageFinishedWebViewClient的onPageFinished在每次完成页面的时候调用，但是遇到未加载完成的页面跳转其他页面时，就会一直调用，使用WebChromeClient.onProgressChanged可以替代 5、WebView后台耗电在WebView加载页面的时候，会自动开启线程去加载，如果不很好的关闭这些线程，就会导致电量消耗加大，可以采用暴力的方法，直接在onDestroy方法中System.exit(0)结束当前正在运行中的java虚拟机 6、WebView硬件加速Android3.0引入硬件加速，默认会开启，WebView在硬件加速的情况下滑动更加平滑，性能更加好，但是会出现白块或者页面闪烁的副作用，建议WebView暂时关闭硬件加速 7、WebView内存泄漏由于WebView是依附于Activity的，Activity的生命周期和WebView启动的线程的生命周期是不一致的，这会导致WebView一直持有对这个Activity的引用而无法释放，解决方案如下独立进程，简单暴力，不过可能涉及到进程间通信（推荐）动态添加WebView，对传入WebView中使用的Context使用弱引用 6、Binder面试题1、Linux内核的基本知识 进程隔离/虚拟地址空间：进程间是不可以共享数据的，相当于被隔离，每个进程被分配到不同的虚拟地址中系统调用：Linux内核对应用有访问权限，用户只能在应用层通过系统调用，调用内核的某些程序binder驱动：它负责各个用户的进程，通过binder通信内核来进行交互的模块 而Binder，就是充当 连接 两个进程（内核空间）的通道。 2、为什么使用Binder性能上，相比传统的Socket更加高效安全性高，支持协议双方互相校验 3、Binder通信模型 虚线表示并非直接交互 说明1：Client进程、Server进程 &amp; Service Manager 进程之间的交互都必须通过Binder驱动（使用 open 和 ioctl文件操作函数），而非直接交互 原因： Client进程、Server进程 &amp; Service Manager进程属于进程空间的用户空间，不可进行进程间交互 Binder驱动 属于 进程空间的 内核空间，可进行进程间 &amp; 进程内交互 说明2： Binder驱动 &amp; Service Manager进程 属于 Android基础架构（即系统已经实现好了）；而Client 进程 和 Server 进程 属于Android应用层（需要开发者自己实现） 所以，在进行跨进程通信时，开发者只需自定义Client &amp; Server 进程 并 显式使用上述3个步骤，最终借助 Android的基本架构功能就可完成进程间通信 详细参考这篇博客：图文详解 Android Binder 跨进程通信机制原理 对比 Linux （Android基于linux）上的其他进程通信方式（管道/消息队列/共享内存/信号量/Socket），Binder 机制的优点有： 高效Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次通过驱动在内核空间拷贝数据，不需要额外的同步处理 安全性高Binder 机制为每个进程分配了 UID/PID 来作为鉴别身份的标示，并且在 Binder 通信时会根据 UID/PID 进行有效性检测传统的进程通信方式对于通信双方的身份并没有做出严格的验证如，Socket通信 ip地址是客户端手动填入，容易出现伪造 使用简单采用Client/Server 架构实现 面向对象 的调用方式，即在使用Binder时就和调用一个本地对象实例一样 4、AIDL客户端通过aidl文件的Stub.asInterface()方法，拿到Proxy代理类通过调用Proxy代理类的方法，将参数进行封包后，调用底层的transact()方法transact()方法会回调onTransact()方法，进行参数的解封在onTransact()方法中调用服务端对应的方法，并将结果返回 7、Handler面试题1、Handler是什么Handler通过发送和处理Message和Runnable对象来关联相对应线程的MessageQueue 2、Handler使用方法post(runnable)sendMessage(message) 3、Handler工作原理Android进阶——Android消息机制之Looper、Handler、MessageQueen 4、Handler引起的内存泄漏原因：非静态内部类持有外部类的匿名引用，导致Activity无法释放解决：Handler内部持有外部Activity的弱引用Handler改为静态内部类Handler.removeCallback() 8、AsyncTask面试题1、AsyncTask是什么它本质上就是一个封装了线程池和Handler的异步框架 2、AsyncTask使用方法三个参数Params：表示后台任务执行时的参数类型，该参数会传给AysncTask的 doInBackground() 方法Progress：表示后台任务的执行进度的参数类型，该参数会作为 onProgressUpdate() 方法的参数Result：表示后台任务的返回结果的参数类型，该参数会作为 onPostExecute() 方法的参数五个方法onPreExecute()：异步任务开启之前回调，在主线程中执行doInBackground()：执行异步任务，在线程池中执行onProgressUpdate()：当doInBackground中调用publishProgress时回调，在主线程中执行onPostExecute()：在异步任务执行之后回调，在主线程中执行onCancelled()：在异步任务被取消时回调 3、AsyncTask工作原理Android进阶——多线程系列之异步任务AsyncTask的使用与源码分析http://blog.csdn.net/qq_30379689/article/details/53203556 4、AsyncTask引起的内存泄漏原因：非静态内部类持有外部类的匿名引用，导致Activity无法释放解决：AsyncTask内部持有外部Activity的弱引用AsyncTask改为静态内部类AsyncTask.cancel() 5、AsyncTask生命周期在Activity销毁之前，取消AsyncTask的运行，以此来保证程序的稳定 6、AsyncTask结果丢失由于屏幕旋转、Activity在内存紧张时被回收等情况下，Activity会被重新创建，此时，旧的AsyncTask持有旧的Activity引用，这个时候会导致AsyncTask的 onPostExecute()对UI更新无效 7、AsyncTask并行or串行AsyncTask在Android 2.3之前默认采用并行执行任务，AsyncTask在Android 2.3之后默认采用串行执行任务如果需要在Android 2.3之后采用并行执行任务，可以调用AsyncTask的executeOnExecutor() 8、一个AsyncTask对象只能被执行一次，即只能调用一次execute，多次执行就报错。同一个进程里所有用到 AsyncTask 的地方都是同一个线程池，导致任务缓存队列就容易满.同一个进程里面所有AsyncTask对象都共享同一个SerialExecutor对象。 参考：https://blog.csdn.net/zhaoyangfang/article/details/76100607 在Android2.3中AsyncTask的调用可以并发执行.在一个线程池中被调用. 该线程池有5个核心线程.即一次可以并发执行5个任务在Android3.0及其以后AsyncTask的调用在默认情况同时只能有1个任务在执行.在AsyncTask中采用了SerialExecutor,线程池中只有一个线程的线程池但我们可以调用方法asyncTask.executeOnExecutor(executor, params);来设置自己的线程池实现并发。 9、HandlerThread面试题1、HandlerThread产生背景当系统有多个耗时任务需要执行时，每个任务都会开启一个新线程去执行耗时任务，这样会导致系统多次创建和销毁线程，从而影响性能。为了解决这一问题，Google提供了HandlerThread，HandlerThread是在线程中创建一个Looper循环器，让Looper轮询消息队列，当有耗时任务进入队列时，则不需要开启新线程，在原有的线程中执行耗时任务即可，否则线程阻塞 2、HanlderThread的特点、HandlerThread本质上是一个线程，继承自ThreadHandlerThread有自己的Looper对象，可以进行Looper循环，可以创建HandlerHandlerThread可以在Handler的handlerMessage中执行异步方法HandlerThread优点是异步不会堵塞，减少对性能的消耗HandlerThread缺点是不能同时继续进行多任务处理，需要等待进行处理，处理效率较低HandlerThread与线程池不同，HandlerThread是一个串行队列，背后只有一个线程。 Looper、Handler、Message三者关系转载自Android 异步消息处理机制 让你深入理解 Looper、Handler、Message三者关系 1、首先Looper.prepare()在本线程中保存一个Looper实例，然后该实例中保存一个MessageQueue对象；因为Looper.prepare()在一个线程中只能调用一次，所以MessageQueue在一个线程中只会存在一个。 2、Looper.loop()会让当前线程进入一个无限循环，不端从MessageQueue的实例中读取消息，然后回调msg.target.dispatchMessage(msg)方法。 3、Handler的构造方法，会首先得到当前线程中保存的Looper实例，进而与Looper实例中的MessageQueue想关联。 4、Handler的sendMessage方法，会给msg的target赋值为handler自身，然后加入MessageQueue中。 5、在构造Handler实例时，我们会重写handleMessage方法，也就是msg.target.dispatchMessage(msg)最终调用的方法。 好了，总结完成，大家可能还会问，那么在Activity中，我们并没有显示的调用Looper.prepare()和Looper.loop()方法，为啥Handler可以成功创建呢，这是因为在Activity的启动代码中，已经在当前UI线程调用了Looper.prepare()和Looper.loop()方法。 10、IntentService面试题1、IntentService是什么IntentService是继承自Service并处理异步请求的一个类，其内部采用HandlerThread和Handler实现的，在IntentService内有一个工作线程来处理耗时操作，其优先级比普通Service高。当任务完成后，IntentService会自动停止，而不需要手动调用stopSelf()。另外，可以多次启动IntentService，每个耗时操作都会以工作队列的方式在IntentService中 onHandlerIntent() 回调方法中执行，并且每次只会执行一个工作线程 2、IntentService使用方法创建Service继承自IntentService覆写构造方法和onHandlerIntent()方法在onHandlerIntent()中执行耗时操作 11、视图工作机制面试题Android进阶——Android视图工作机制之measure、layout、draw Android事件分发机制之dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent 12、ListView面试题1、ListView是什么ListView是能将一个数据集合以动态滚动的方式展示到用户界面上的View 2、ListView的RecycleBin机制 3、ListView的优化重用convertView使用ViewHolder图片三级缓存监听滑动事件少用透明View开启硬件加速 13、Android项目构建面试题1、android构建流程 2、jenkins持续集成构建这里可参考蒲公英文档 3、Git常用命令git init：仓库的初始化git status：查看当前仓库的状态git diff：查看仓库与上次修改的内容git add：将文件放进暂存区git commit：提交代码git clone：克隆代码git bransh：查看当前分支git checkout：切换当前分支 4、git工作流fork/clone（主流）fork：将别人的仓库代码fork到自己的仓库上clone：克隆下自己仓库的代码update、commit：修改代码并提交到自己的仓库push：提交到自己的仓库pull request：请求添加到别人的仓库clone 5、proguard是什么ProGuard工具是用于压缩、优化和混淆我们的代码，其主作用是移除或混淆代码中无用类、字段、方法和属性 6、proguard技术功能压缩优化混淆预检测 7、proguard工作原理将无用的字段或方法存入到EntryPoint中，将非EntryPoint的字段和方法进行替换 8、为什么要混淆由于Java是一门跨平台的解释性语言，其源代码被编译成class字节码来适应其他平台，而class文件包含了Java源代码信息，很容易被反编译 14、ANR面试题1、什么是ANRApplication Not Responding，页面无响应的对话框 2、发生ANR的条件应用程序的响应性是由ActivityManager和WindowManager系统服务监视的，当ANR发生条件满足时，就会弹出ANR的对话框Activity超过5秒无响应BroadcastReceiver超过10秒无响应Service超过20秒无响应 3、造成ANR的主要原因主线程被IO操作阻塞Activity的所有生命周期回调都是执行在主线程的Service默认执行在主线程中BoardcastReceiver的回调onReceive()执行在主线程中AsyncTask的回调除了doInBackground，其他都是在主线程中没有使用子线程Looper的Handler的handlerMessage，post(Runnable)都是执行在主线程中 4、如何解决ANR使用AsyncTask处理耗时IO操作使用Thread或HandlerThread提供优先级使用Handler处理工作线程的耗时操作Activity的onCreate和onResume回调尽量避免耗时操作 15、OOM面试题1、什么是OOMOOM指Out of memory（内存溢出），当前占用内存加上我们申请的内存资源超过了Dalvik虚拟机的最大内存限制就会抛出Out of memory异常 2、OOM相关概念内存溢出：指程序在申请内存时，没有足够的空间供其使用内存泄漏：指程序分配出去的内存不再使用，无法进行回收内存抖动：指程序短时间内大量创建对象，然后回收的现象 3、解决OOMBitmap相关图片压缩加载缩略图在滚动时不加载图片回收Bitmap使用inBitmap属性捕获异常其他相关listview重用convertView、使用LruCache避免onDraw方法执行对象的创建谨慎使用多进程 16、Bitmap面试题1、recycle在安卓3.0以前Bitmap是存放在堆中的，我们只要回收堆内存即可在安卓3.0以后Bitmap是存放在内存中的，我们需要回收native层和Java层的内存官方建议我们3.0以后使用recycle方法进行回收，该方法也可以不主动调用，因为垃圾回收器会自动收集不可用的Bitmap对象进行回收recycle方法会判断Bitmap在不可用的情况下，将发送指令到垃圾回收器，让其回收native层和Java层的内存，则Bitmap进入dead状态recycle方法是不可逆的，如果再次调用getPixels()等方法，则获取不到想要的结果 2、LruCache原理LruCache是个泛型类，内部采用LinkedHashMap来实现缓存机制，它提供get方法和put方法来获取缓存和添加缓存，其最重要的方法trimToSize是用来移除最少使用的缓存和使用最久的缓存，并添加最新的缓存到队列中 3、计算inSampleSizepublic static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) &#123; final int height = options.outHeight; final int width = options.outWidth; int inSampleSize = 1; if (height &gt; reqHeight || width &gt; reqWidth) &#123; if (width &gt; height) &#123; inSampleSize = Math.round((float)height / (float)reqHeight); &#125; else &#123; inSampleSize = Math.round((float)width / (float)reqWidth); &#125; &#125; return inSampleSize;&#125; 4、缩略图public static Bitmap thumbnail(String path,int maxWidth, int maxHeight, boolean autoRotate) &#123; BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; Bitmap bitmap = BitmapFactory.decodeFile(path, options); options.inJustDecodeBounds = false; int sampleSize = calculateInSampleSize(options, maxWidth, maxHeight); options.inSampleSize = sampleSize; options.inPreferredConfig = Bitmap.Config.RGB_565; options.inPurgeable = true; options.inInputShareable = true; if (bitmap != null &amp;&amp; !bitmap.isRecycled()) &#123; bitmap.recycle(); &#125; bitmap = BitmapFactory.decodeFile(path, options); return bitmap;&#125; 5、保存Bitmappublic static String save(Bitmap bitmap,Bitmap.CompressFormat format, int quality, File destFile) &#123; try &#123; FileOutputStream out = new FileOutputStream(destFile); if (bitmap.compress(format, quality, out)) &#123; out.flush(); out.close(); &#125; if (bitmap != null &amp;&amp; !bitmap.isRecycled()) &#123; bitmap.recycle(); &#125; return destFile.getAbsolutePath(); &#125; catch (FileNotFoundException e) &#123; e.printStackTrace(); &#125; catch (IOException e) &#123; e.printStackTrace(); &#125; return null;&#125; 6、保存到SD卡 public static String save(Bitmap bitmap,Bitmap.CompressFormat format, int quality, Context context) &#123; if (!Environment.getExternalStorageState() .equals(Environment.MEDIA_MOUNTED)) &#123; return null; &#125; File dir = new File(Environment.getExternalStorageDirectory() + \"/\" + context.getPackageName() + \"/save/\"); if (!dir.exists()) &#123; dir.mkdirs(); &#125; File destFile = new File(dir, UUID.randomUUID().toString()); return save(bitmap, format, quality, destFile);&#125; 7、三级缓存网络缓存本地缓存内存缓存 下面介绍了 Android 位图内存管理的演变过程： 在 Android Android 2.2（API 级别 8）及更低版本上，当发生垃圾回收时，应用的线程会停止。这会导致延迟，从而降低性能。Android 2.3 添加了并发垃圾回收功能，这意味着系统不再引用位图后，很快就会回收内存。 在 Android 2.3.3（API 级别 10）及更低版本上，位图的后备像素数据存储在本地内存中。它与存储在 Dalvik 堆中的位图本身是分开的。本地内存中的像素数据并不以可预测的方式释放，可能会导致应用短暂超出其内存限制并崩溃。 从 Android 3.0（API 级别 11）到 Android 7.1（API 级别 25），像素数据会与关联的位图一起存储在 Dalvik 堆上。 在 Android 8.0（API 级别 26）及更高版本中，位图像素数据存储在原生堆中。 更多关于bitmap位图数据存储的介绍，可以看下官方的介绍：https://developer.android.com/topic/performance/graphics/manage-memory 17、UI卡顿面试题1、UI卡顿原理View的绘制帧数保持60fps是最佳，这要求每帧的绘制时间不超过16ms（1000/60），如果安卓不能在16ms内完成界面的渲染，那么就会出现卡顿现象 2、UI卡顿的原因分析在UI线程中做轻微的耗时操作，导致UI线程卡顿布局Layout过于复杂，无法在16ms内完成渲染同一时间动画执行的次数过多，导致CPU和GPU负载过重overDraw，导致像素在同一帧的时间内被绘制多次，使CPU和GPU负载过重View频繁的触发measure、layout，导致measure、layout累计耗时过多和整个View频繁的重新渲染频繁的触发GC操作导致线程暂停，会使得安卓系统在16ms内无法完成绘制冗余资源及逻辑等导致加载和执行缓慢ANR 3、UI卡顿的优化布局优化使用include、ViewStub、merge不要出现过于嵌套和冗余的布局使用自定义View取代复杂的ViewListView优化复用convertView滑动不加载背景和图片优化缩略图图片压缩避免ANR不要在UI线程中做耗时操作 18、内存泄漏面试题1、Java内存泄漏引起的主要原因长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏 2、Java内存分配策略静态存储区：又称方法区，主要存储全局变量和静态变量，在整个程序运行期间都存在栈区：方法体的局部变量会在栈区创建空间，并在方法执行结束后会自动释放变量的空间和内存堆区：保存动态产生的数据，如：new出来的对象和数组，在不使用的时候由Java回收器自动回收 3、Android解决内存泄漏的例子单例造成的内存泄漏：在单例中，使用context.getApplicationContext()作为单例的context匿名内部类造成的内存泄漏：由于非静态内部类持有匿名外部类的引用，必须将内部类设置为staticHandler造成的内存泄漏：使用static的Handler内部类，同时在实现内部类中持有Context的弱引用避免使用static变量：由于static变量会跟Activity生命周期一致，当Activity退出后台被后台回收时，static变量是不安全，所以也要管理好static变量的生命周期资源未关闭造成的内存泄漏：比如Socket、Broadcast、Cursor、Bitmap、ListView等，使用完后要关闭AsyncTask造成的内存泄漏：由于非静态内部类持有匿名内部类的引用而造成内存泄漏，可以通过AsyncTask内部持有外部Activity的弱引用同时改为静态内部类或在onDestroy()中执行AsyncTask.cancel()进行修复 非静态内部类和非静态匿名内部类中确实都持有外部类的引用， 静态内部类中未持有外部类的引用 19、内存管理面试题1、Android内存管理机制分配机制管理机制 2、内存管理机制的特点更少的占用内存在合适的时候，合理的释放系统资源在系统内存紧张的时候，能释放掉大部分不重要的资源能合理的在特殊生命周期中，保存或还原重要数据 3、内存优化方法Service完成任务后应停止它，或用IntentService（因为可以自动停止服务）代替Service在UI不可见的时候，释放其UI资源在系统内存紧张的时候，尽可能多的释放非重要资源避免滥用Bitmap导致内存浪费避免使用依赖注入框架使用针对内存优化过的数据容器使用ZIP对齐的APK使用多进程 20、冷启动和热启动面试题1、什么是冷启动和热启动冷启动：在启动应用前，系统中没有该应用的任何进程信息热启动：在启动应用时，在已有的进程上启动应用（用户使用返回键退出应用，然后马上又重新启动应用） 2、冷启动和热启动的区别冷启动：创建Application后再创建和初始化MainActivity热启动：创建和初始化MainActivity即可 3、冷启动时间的计算这个时间值从应用启动（创建进程）开始计算，到完成视图的第一次绘制为止 4、冷启动流程Zygote进程中fork创建出一个新的进程创建和初始化Application类、创建MainActivityinflate布局、当onCreate/onStart/onResume方法都走完contentView的measure/layout/draw显示在界面上总结：Application构造方法-&gt;attachBaseContext()-&gt;onCreate()-&gt;Activity构造方法-&gt;onCreate()-&gt;配置主题中背景等属性-&gt;onStart()-&gt;onResume()-&gt;测量布局绘制显示在界面上 5、冷启动优化减少第一个界面onCreate()方法的工作量不要让Application参与业务的操作不要在Application进行耗时操作不要以静态变量的方式在Application中保存数据减少布局的复杂性和深度不要在mainThread中加载资源通过懒加载方式初始化第三方SDK 21、其他优化面试题1、Android不用静态变量存储数据静态变量等数据由于进程已经被杀死而被初始化使用其他数据传输方式：文件/sp/contentProvider 2、SharePreference安全问题不能跨进程同步文件不宜过大 3、内存对象序列化Serializeble：是java的序列化方式，Serializeble在序列化的时候会产生大量的临时对象，从而引起频繁的GCParcelable：是Android的序列化方式，且性能比Serializeble高，Parcelable不能使用在要将数据存储在硬盘上的情况 4、避免在UI线程中做繁重的操作 22、架构模式面试题Android基础——框架模式MVC在安卓中的实践http://blog.csdn.net/qq_30379689/article/details/52909656Android基础——框架模式MVP在安卓中的实践http://blog.csdn.net/qq_30379689/article/details/52910567Android基础——框架模式MVVM之DataBinding的实践http://blog.csdn.net/qq_30379689/article/details/53037430 Android App的设计架构：MVC,MVP,MVVM与架构经验谈https://www.tianmaying.com/tutorial/AndroidMVC 23、插件化面试题1、插件化解决的问题动态加载APK（反射、类加载器）资源加载（反射、AssetManager、独立资源、分段资源）代码加载（反射获取生命周期） 2、类加载器（Java中字节码添加到虚拟机中）DexClassLoader：能够加载未安装的jar/apk/dex，主要用于动态加载和代码热更新PathClassLoader：只能加载系统中已经安装过的apk 24、热更新面试题1、热更新主要流程线上检查到Crash拉出Bugfix分支修复Crash问题jenkins构建和补丁生成app通过推送或主动拉取补丁文件将Bugfix代码合到master上 2、热更新主流框架DexposedAndFixNuwaTinker 3、热更新的原理在ClassLoader创建一个dexElements数组将修复好的dex文件存放在dexElements数组的最前面ClassLoader会遍历dexElements数组，找到最前面的dex文件优先加载 25、进程保活面试题1、进程的优先级空进程后台进程服务进程可见进程前台进程 2、Android进程回收策略Low memory Killer（定时执行）：通过一些比较复杂的评分机制，对进程进行打分，然后将分数高的进程判定为bad进程，杀死并释放内存OOM_ODJ：判别进程的优先级 3、Android保活方案利用系统广播拉活利用系统Service机制拉活利用Native进程拉活利用JobScheduler机制拉活利用账号同步机制拉活 26、Lint面试题1、什么是Android LintAndroid Lint是一个静态代码分析工具，它能够对你的Android项目中潜在的Bug、可优化的代码、安全性、性能、可用性、可访问性、国际化等进行检查 2、Lint工作流程 3、配置Lint创建Lint.xml到根目录下，自定义Lint安全等级等在Java文件中可以使用@suppressLint(“NewApi”)来忽视Lint的报错在xml文件中可以使用tool:ignore(“UnusedResources”)来忽视Lint的报错自定义Lint检查，可以创建类，继承Detector和实现JavaPsiScanner 27、Kotlin面试题1、什么是KotlinKotlin是一种基于JVM的编程语言对Java的一种拓展，比Java更简洁Kotlin支持函数式编程Kotlin类和Java类可以相互调用 2、Kotlin环境搭建直接在Plugin中下载Kotlin插件即可系统会自动配置到Kotlin环境 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/08/17/IntervieweeQuestions/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"Activity启动流程分析","slug":"activity-start-process","date":"2017-08-01T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/08/02/activity-start-process/","link":"","permalink":"http://agehua.github.io/2017/08/02/activity-start-process/","excerpt":"Activity启动流程分析本文主要介绍Activity的启动过程和过程中主要涉及的类。如果你跟随上一篇文章，成功编译了Android源码，可以动手跟本篇文章一步一步调试分析整个启动过程。没有编译源码，也可以看看android.googlesource，这里也有源码。\n主要对象功能介绍zygote进程和SystemServer进程android是基于Linux系统的，而在linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote 进程也不例外。\n\n每一个App其实都是\n\n一个单独的dalvik虚拟机\n一个单独的进程\n\n\nAndroid系统开启新进程的方式，是通过fork第一个zygote 进程实现的。所以说，除了第一个zygote进程，其他应用所在的进程都是zygote的子进程。","text":"Activity启动流程分析本文主要介绍Activity的启动过程和过程中主要涉及的类。如果你跟随上一篇文章，成功编译了Android源码，可以动手跟本篇文章一步一步调试分析整个启动过程。没有编译源码，也可以看看android.googlesource，这里也有源码。 主要对象功能介绍zygote进程和SystemServer进程android是基于Linux系统的，而在linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote 进程也不例外。 每一个App其实都是 一个单独的dalvik虚拟机 一个单独的进程 Android系统开启新进程的方式，是通过fork第一个zygote 进程实现的。所以说，除了第一个zygote进程，其他应用所在的进程都是zygote的子进程。 SystemServer 也是一个进程，而且是由zygote进程fork出来的。为什么说SystemServer非常重要呢？因为系统里面重要的服务都是在这个进程里面开启的，比如ActivityManagerService、PackageManagerService、WindowManagerService等等。 我们的App和AMS(SystemServer进程)还有zygote进程分属于三个独立的进程，他们之间如何通信呢？App与AMS通过Binder进行IPC通信，AMS(SystemServer进程)与zygote通过Socket进行IPC通信。 与Activity启动有关的类我们下面的文章将围绕着这几个类进行介绍。可能你第一次看的时候，印象不深，不过没关系，当你跟随者我读完这篇文章的时候，相信那时候你会对这些类更加的熟悉和深刻。 ActivityManagerServices，简称AMS，服务端对象，负责系统中所有Activity的生命周期，查看源码，点击这里 ActivityThread，App的真正入口。当开启App之后，会调用main()开始运行，开启消息循环队列，这就是传说中的UI线程或者叫主线程。与ActivityManagerServices配合，一起完成Activity的管理工作 ApplicationThread，用来实现ActivityManagerService与ActivityThread之间的交互。在ActivityManagerService需要管理相关Application中的Activity的生命周期时，通过ApplicationThread的代理对象与ActivityThread通讯。 ApplicationThreadProxy，是ApplicationThread在服务器端的代理，负责和客户端的ApplicationThread通讯。AMS就是通过该代理与ActivityThread进行通信的。 Instrumentation，每一个应用程序只有一个Instrumentation对象，每个Activity内都有一个对该对象的引用。Instrumentation可以理解为应用进程的管家，ActivityThread要创建或暂停某个Activity时，都需要通过Instrumentation来进行具体的操作。 ActivityStack，Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。 ActivityRecord，ActivityStack的管理对象，每个Activity在AMS对应一个ActivityRecord，来记录Activity的状态以及其他的管理信息，比如在哪进程中ProcessState，当前的状态CurentState等。其实就是服务器端的Activity对象的映像。 TaskRecord，AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。如果你清楚Activity的4种launchMode，那么对这个概念应该不陌生。 ProcessRecord，这个类记录的是一个进程中的信息，因为一个应用中可能会包含多个进程。 App程序的入口我们一般在启动Activity的时候都是使用系统提供的方法Activity.startActivity()操作的，本文就在此方法上分析整个过程: 这里我的app进程是：foo.bar.multi，后面深入源码后会在系统进程system_process和app进程之间切换。 @Overridepublic void startActivity(Intent intent) &#123; this.startActivity(intent, null);&#125;@Overridepublic void startActivity(Intent intent, @Nullable Bundle options) &#123; if (options != null) &#123; //options这里为null startActivityForResult(intent, -1, options); &#125; else &#123; // Note we want to go through this call for compatibility with // applications that may have overridden the method. startActivityForResult(intent, -1); &#125;&#125;public void startActivityForResult(@RequiresPermission Intent intent, int requestCode, @Nullable Bundle options) &#123; if (mParent == null) &#123; //这里mParent不为空 options = transferSpringboardActivityOptions(options); Instrumentation.ActivityResult ar = mInstrumentation.execStartActivity( this, mMainThread.getApplicationThread(), mToken, this, intent, requestCode, options); if (ar != null) &#123; mMainThread.sendActivityResult( mToken, mEmbeddedID, requestCode, ar.getResultCode(), ar.getResultData()); &#125; // 代码省略.... &#125; else &#123; // 代码省略.... &#125;&#125; 上面代码可以看到，这里用到了mMainThread变量去执行的操作，再看看这个变量，它是ActivityThread的一个实例。ActivityThread是一个应用非常关键的一个类，首先它是一个应用的主线程，其次就是他才是一个程序的入口（main方法）的地方： public static void main(String[] args) &#123; //...代码省略&#125; 没有Android源码的，可以看这里：android.googlesource。后面介绍这个入口main方法什么时候执行。 上面的mInstrumentation对象，是在Activity的attach()方法中被赋值的 Instrumentation是什么？和ActivityThread是什么关系？接着说上面的mInstrumentation.execStartActivity()方法，有三个同名的重载方法：public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options)public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, String target, Intent intent, int requestCode, Bundle options)public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options, UserHandle user) 考验眼力的时候到了，仔细看下，上面的mInstrumentation.execStartActivity()调用的其实是第一个重载方法：public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) &#123; IApplicationThread whoThread = (IApplicationThread) contextThread; //...ignore some code... try &#123; intent.migrateExtraStreamToClipData(); intent.prepareToLeaveProcess(); int result = ActivityManagerNative.getDefault() .startActivity(whoThread, who.getBasePackageName(), intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null ? target.mEmbeddedID : null, requestCode, 0, null, options); checkStartActivityResult(result, intent); &#125; catch (RemoteException e) &#123; &#125; return null;&#125; 可以看到execStartActivity()方法，调用了ActivityManagerNative的startActivity()方法，看到这个ActivityManagerNative类有没有感觉和之前一篇文章，Android Binder机制分析（二）里的ServiceManagerNative有点类似，这里涉及到的是系统服务间的Binder机制，不了解的同学可以看看这篇文章。 稍后分析ActivityManagerNative，这里简单介绍下Instrumentation类。 Instrumentation意为“仪器”。每个Activity都持有Instrumentation对象的一个引用，但是整个进程只会存在一个Instrumentation对象。 Instrumentation这个类里面的方法大多数和Application和Activity有关，可以说是对Application和Activity初始化和生命周期的工具类。 举个例子，callActivityOnCreate()public void callActivityOnCreate(Activity activity, Bundle icicle) &#123; prePerformCreate(activity); activity.performCreate(icicle); postPerformCreate(activity);&#125; 对activity.performCreate(icicle);这一行代码熟悉吗？这一行里面就调用了传说中的Activity的入口函数onCreate()，不信？接着往下看Activity.performCreate()final void performCreate(Bundle icicle) &#123; onCreate(icicle); mActivityTransitionState.readState(icicle); performCreateCommon();&#125; 确实，onCreate在这里调用了。但是有一件事情必须说清楚，那就是这个Instrumentation类这么重要，为啥我在开发的过程中，没有发现他的踪迹呢？ 是的，Instrumentation这个类很重要，对Activity生命周期方法的调用根本就离不开他，但他只负责Activity的内部管理。外部想调整Activity的状态，必须通过ActivityThread。 ActivityThread你都没听说过？那你肯定听说过传说中的UI线程吧？是的，这就是UI线程。我们前面说过，App和AMS是通过Binder传递信息的，那么ActivityThread就是专门与AMS的外交工作的。Instrumentation相当于老板娘，处理家务，很少露面。ActivityThread是老板，处理对外事务。 所以说，AMS是董事会，负责指挥和调度的，ActivityThread是老板，虽然说家里的事自己说了算，但是需要听从AMS的指挥，而Instrumentation则是老板娘，负责家里的大事小事，但是一般不抛头露面，听一家之主ActivityThread的安排。 简介AMS和ActivityThread之间的Binder通信前面的两篇文章：Android Binder机制分析（一）和Android Binder机制分析（二）。已经介绍了Android都是通过Binder机制调用远程的系统服务。这里在介绍下ActivityThread（App进程）是如何调用AMS服务的。 前面我们说到，在调用Activity.startActivity()的时候，实际上调用的是：mInstrumentation.execStartActivity()这个方法里面调用的是：ActivityManagerNative.getDefault().startActivity() 用鼠标定位一下，上面的startActivity()方法，会发现这个方法是IActivityManager接口里的方法。注意IActivityManager继承了IInterface接口，而这个接口就是AIDL接口类必须实现的接口。 再看，ActivityManagerNative.getDefault()返回的就是ActivityManagerService的远程接口的本地代理，即ActivityManagerProxy。public abstract class ActivityManagerNative extends Binder implements IActivityManager&#123; //从类声明上，我们可以看到ActivityManagerNative是Binder的一个子类，而且实现了IActivityManager接口 static public IActivityManager getDefault() &#123; return gDefault.get(); &#125;//最终返回的还是一个ActivityManagerProxy对象static public IActivityManager asInterface(IBinder obj) &#123; if (obj == null) &#123; return null; &#125; IActivityManager in = (IActivityManager)obj.queryLocalInterface(descriptor); if (in != null) &#123; return in; &#125; //这里面的Binder类型的obj参数会作为ActivityManagerProxy的成员变量保存为mRemote成员变量，负责进行IPC通信 return new ActivityManagerProxy(obj); &#125;&#125; 其实ActivityManagerNative类就是远端服务的中间者Stub类，其实名字不叫Stub罢了，以后其实只要看到是继承了Binder类和实现了AIDL接口类型的就是Stub类，不要关心类名了。看到他的asInterface方法的时候也是和之前的其他系统服务都是类似的。//通过单例模式获取一个IActivityManager对象，这个对象通过asInterface(b)获得private static final Singleton&lt;IActivityManager&gt; gDefault = new Singleton&lt;IActivityManager&gt;() &#123; protected IActivityManager create() &#123; IBinder b = ServiceManager.getService(\"activity\"); if (false) &#123; Log.v(\"ActivityManager\", \"default service binder = \" + b); &#125; IActivityManager am = asInterface(b); if (false) &#123; Log.v(\"ActivityManager\", \"default service = \" + am); &#125; return am; &#125; &#125;;&#125; 在这里可以看到了，其实gDefalut借助Singleton实现的单例模式，而在内部可以看到先从ServiceManager中获取到AMS远端服务的Binder对象，然后使用asInterface方法转化成本地化对象（其实就是ActivityManagerProxy对象，这个对象是ActivityManagerNative的内部类）。然后我们在看看上面调用了startActivity方法，其实就是调用了ActivityManagerProxy对象的这个方法。 在这里面做的事情就是IPC通信，利用Binder对象，调用transact()，把所有需要的参数封装成Parcel对象，向AMS发送数据进行通信。 这个方法中添加一个断点，注意这里startActivity()是ActivityManagerProxy类的方法，这里的进程应该还是App进程：foo.bar.multi public int startActivity(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle options) throws RemoteException &#123; Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(caller != null ? caller.asBinder() : null); data.writeString(callingPackage); intent.writeToParcel(data, 0); //...省略部分代码 mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0); reply.readException(); int result = reply.readInt(); reply.recycle(); data.recycle(); return result;&#125; 注意，这里先别放开断点 Binder本质上只是一种底层通信方式，和具体服务没有关系。为了提供具体服务，Server必须提供一套接口函数以便Client通过远程访问使用各种服务。这时通常采用Proxy设计模式：将接口函数定义在一个抽象类中，Server和Client都会以该抽象类为基类实现所有接口函数，所不同的是Server端是真正的功能实现，而Client端是对这些函数远程调用请求的包装。 客户端：ActivityManagerProxy =====&gt;Binder驱动=====&gt; ActivityManagerService：服务器 Binder只能传递数据，并不知道是要调用ActivityManagerServices的哪个方法，所以在数据中会添加方法的唯一标识码，比如前面的startActivity()方法中的标识：START_ACTIVITY_TRANSACTION。 在远端服务调用了transact()方法后，即mRemote.transact()，会转接到远端服务中间者ActivityManagerNative的onTransact方法中，找到对应的标识码： 注意这里的接收者ActivityManagerNative的onTransact方法是在system_process进程中，想要继续debug调试的的话，需要在monitor中选中这个进程，然后再在下面的方法中添加断点。最后放开上面添加的断点。 @Overridepublic boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException &#123; switch (code) &#123; case START_ACTIVITY_TRANSACTION: &#123; //最好在case方法里面添加断点，避免受其他系统发送的消息影响 data.enforceInterface(IActivityManager.descriptor); IBinder b = data.readStrongBinder(); IApplicationThread app = ApplicationThreadNative.asInterface(b); String callingPackage = data.readString(); Intent intent = Intent.CREATOR.createFromParcel(data); String resolvedType = data.readString(); IBinder resultTo = data.readStrongBinder(); String resultWho = data.readString(); int requestCode = data.readInt(); int startFlags = data.readInt(); ProfilerInfo profilerInfo = data.readInt() != 0 ? ProfilerInfo.CREATOR.createFromParcel(data) : null; Bundle options = data.readInt() != 0 ? Bundle.CREATOR.createFromParcel(data) : null; int result = startActivity(app, callingPackage, intent, resolvedType, resultTo, resultWho, requestCode, startFlags, profilerInfo, options); reply.writeNoException(); reply.writeInt(result); return true; &#125; //...省略&#125; 这里的startActivity方法，是在IActivityManager接口中定义的，跟ActivityManagerProxy没有关系了，是由远端服务来实现的，这里我们可以猜想应该是叫做ActivityManagerService中，这个类的源代码可以在android.googlesource里找到： 这个类里有三个重载的startActivity()方法，仔细看，对应的应该是第三个方法：final int startActivity(Intent intent, ActivityStackSupervisor.ActivityContainer container)@Overridepublic int startActivity(IBinder whoThread, String callingPackage, Intent intent, String resolvedType, Bundle bOptions)@Overridepublic final int startActivity(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) 这个方法直接调用了startActivityAsUser()方法@Overridepublic final int startActivityAsUser(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) &#123; enforceNotIsolatedCaller(\"startActivity\"); userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(), userId, false, ALLOW_FULL_ONLY, \"startActivity\", null); // TODO: Switch to user app stacks here. return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent, resolvedType, null, null, resultTo, resultWho, requestCode, startFlags, profilerInfo, null, null, bOptions, false, userId, null, null);&#125; 这里的mActivityStarter是在ActivityManagerService创建的时候初始化的。public ActivityManagerService(Context systemContext) &#123; //...省略代码 mStackSupervisor = new ActivityStackSupervisor(this); mActivityStarter = new ActivityStarter(this, mStackSupervisor); //...省略代码&#125; 下面就是ActiviStarter、ActivityStack和ActivityStackSupervisor三个类之间方法调来调去了，这里为了节省篇幅就不再贴代码了，有毅力的同学可以每个方法都打上一个断点，走一遍： ActivityStarter.startActivityMayWait()-&gt; ActivityStarter.startActivityLocked()-&gt; ActivityStarter.startActivityUnchecked()-&gt; ActivityStackSupervisor.resumeFocusedStackTopActivityLocked() 再往后都是ActivityStackSupervisor类的方法，调用： 从resumeFocusedStackTopActivityLocked()-&gt; resumeFocusedStackTopActivityLocked()-&gt; resumeTopActivityUncheckedLocked()-&gt; resumeTopActivityInnerLocked()-&gt; startSpecificActivityLocked()-&gt; realStartActivityLocked() IApplicationThread接口简介重点在最后的方法里realStartActivityLocked()调用了，app.thread.scheduleLaunchActivity()方法final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app, boolean andResume, boolean checkConfig) throws RemoteException &#123; //...代码省略 final ActivityStack stack = task.stack; try &#123; //...代码省略 app.forceProcessStateUpTo(mService.mTopProcessState); app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken, System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration), new Configuration(task.mOverrideConfig), r.compat, r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle, r.persistentState, results, newIntents, !andResume, mService.isNextTransitionForward(), profilerInfo); //...代码省略 &#125; catch (RemoteException e) &#123; &#125; return true;&#125; scheduleLaunchActivity()方法是IApplicationThread接口里面的方法，但是是由那个类实现的呢，这里就需要猜了，哈哈 下面几个类都实现了相同的接口IApplicationThread：private class ApplicationThread extends ApplicationThreadNative &#123;&#125;public abstract class ApplicationThreadNative extends Binder implements IApplicationThread&#123;&#125;class ApplicationThreadProxy implements IApplicationThread &#123;&#125;public interface IApplicationThread extends IInterface &#123;&#125; IApplicationThread的源码在这里：android.googlesource IApplicationThread是实现了IInterface接口的，说明也是用的Binder远程通讯，这里的当前进程是system_process，本地代理类应该是ApplicationThreadProxy类，而这个类是内部类，在ApplicationThreadNative类中 来看ApplicationThreadProxy类的scheduleLaunchActivity()方法：public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident, ActivityInfo info, Configuration curConfig, Configuration overrideConfig, CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor, int procState, Bundle state, PersistableBundle persistentState, List&lt;ResultInfo&gt; pendingResults, List&lt;ReferrerIntent&gt; pendingNewIntents, boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) throws RemoteException &#123; Parcel data = Parcel.obtain(); data.writeInterfaceToken(IApplicationThread.descriptor); //....写入数据 mRemote.transact(SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION, data, null, IBinder.FLAG_ONEWAY); data.recycle();&#125; 记住这个标识，SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION，在ApplicationThreadNative类的onTransact()方法里找： 这里注意，调用完mRemote.transact()方法，回调的onTransact()方法已经不再system_process进程中了，而是到了App进程：foo.bar.multi //onTransact()方法里：case SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION: &#123; data.enforceInterface(IApplicationThread.descriptor); // 取出数据 scheduleLaunchActivity(intent, b, ident, info, curConfig, overrideConfig, compatInfo, referrer, voiceInteractor, procState, state, persistentState, ri, pi, notResumed, isForward, profilerInfo); return true; &#125; 取出各种数据，在调用scheduleLaunchActivity()方法。 这里的cheduleLaunchActivity()在哪里实现？感觉应该在ApplicationThreadService类里。但是并没有这个类。其实应该是ApplicationThread类，不叫XXXService了，这个类实现了ApplicationThreadNative接口，同时它是ActivityThread的内部类 到这里总结下IApplicationThread接口的Binder机制： 客户端：ApplicationThread &lt;=====Binder驱动&lt;===== ApplicationThreadProxy：服务器对比之前的IActivityManager：客户端：ActivityManagerProxy =====&gt;Binder驱动=====&gt; ActivityManagerService：服务器有没有发现Binder只能单向传递。 这两次的Binder通信如下图所示： 再来看ApplicationThread类的scheduleLaunchActivity()方法// we use token to identify this activity without having to send the// activity itself back to the activity manager. (matters more with ipc)@Overridepublic final void scheduleLaunchActivity(Intent intent, IBinder token, int ident, ActivityInfo info, Configuration curConfig, Configuration overrideConfig, CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor, int procState, Bundle state, PersistableBundle persistentState, List&lt;ResultInfo&gt; pendingResults, List&lt;ReferrerIntent&gt; pendingNewIntents, boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) &#123; updateProcessState(procState, false); ActivityClientRecord r = new ActivityClientRecord(); r.token = token; r.ident = ident; r.intent = intent; r.referrer = referrer; r.voiceInteractor = voiceInteractor; r.activityInfo = info; r.compatInfo = compatInfo; r.state = state; r.persistentState = persistentState; r.pendingResults = pendingResults; r.pendingIntents = pendingNewIntents; r.startsNotResumed = notResumed; r.isForward = isForward; r.profilerInfo = profilerInfo; r.overrideConfig = overrideConfig; updatePendingConfiguration(curConfig); sendMessage(H.LAUNCH_ACTIVITY, r);&#125; 在继续看接收消息的地方，在H类里（H类继承了Handler），public void handleMessage(Message msg) &#123; if (DEBUG_MESSAGES) Slog.v(TAG, \"&gt;&gt;&gt; handling: \" + codeToString(msg.what)); switch (msg.what) &#123; case LAUNCH_ACTIVITY: &#123; Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, \"activityStart\"); final ActivityClientRecord r = (ActivityClientRecord) msg.obj; r.packageInfo = getPackageInfoNoCheck( r.activityInfo.applicationInfo, r.compatInfo); handleLaunchActivity(r, null, \"LAUNCH_ACTIVITY\"); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); &#125; break; //.... handleLaunchActivity()-&gt;performLaunchActivity()。 performLaunchActivity()通过ClassLoader导入相应的Activity类，然后把它启动起来，注意看代码里的注释。Activity activity = null;try &#123; //通过ClassLoader将foo.bar.multi.XXXActivity类加载进来： java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); StrictMode.incrementExpectedActivityCount(activity.getClass()); r.intent.setExtrasClassLoader(cl); r.intent.prepareToEnterProcess(); if (r.state != null) &#123; r.state.setClassLoader(cl); &#125;&#125; catch (Exception e) &#123; if (!mInstrumentation.onException(activity, e)) &#123; throw new RuntimeException( \"Unable to instantiate activity \" + component + \": \" + e.toString(), e);try &#123; //创建Application对象，这是根据AndroidManifest.xml配置文件中的Application标签的信息来创建的 Application app = r.packageInfo.makeApplication(false, mInstrumentation); //代码主要创建Activity的上下文信息，并通过attach方法将这些上下文信息设置到XXXActivity中去： if (activity != null) &#123; activity.attach(appContext, this, getInstrumentation(), r.token, r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID, r.lastNonConfigurationInstances, config, r.referrer, r.voiceInteractor, window); //调用activity的onCreate函数，上面提到过这个方法： mInstrumentation.callActivityOnCreate(activity, r.state); 无论是通过点击应用程序图标来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都要借助于应用程序框架层的ActivityManagerService服务进程。在Android应用程序框架层中，ActivityManagerService是一个非常重要的接口，它不但负责启动Activity和Service，还负责管理Activity和Service。 Android应用程序框架层中的ActivityManagerService启动Activity的过程大致如下图所示： 在这个图中，ActivityManagerService和ActivityStack位于同一个进程中，而ApplicationThread和ActivityThread位于另一个进程中。其中，ActivityManagerService是负责管理Activity的生命周期的，ActivityManagerService还借助ActivityStack是来把所有的Activity按照后进先出的顺序放在一个堆栈中；对于每一个应用程序来说，都有一个ActivityThread来表示应用程序的主进程，而每一个ActivityThread都包含有一个ApplicationThread实例，它是一个Binder对象，负责和其它进程进行通信。 下面简要总结一下启动的过程： Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口； Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息； Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了； Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity； Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动； Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作； Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。 补充，通过Launcher启动ActivityAndroid的Launcher本身也是一个应用程序，点击应用图标，调用的方法还是Activity.startActivity()。与之前分析的不同之处是在ActivityStackSupervisor.startSpecificActivityLocked()方法中：void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) &#123; // Is this activity's application already running? ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid, true); r.task.stack.setLaunchTime(r); //区别在这里，Launcher启动方式，app为null，应用内启动app不为null if (app != null &amp;&amp; app.thread != null) &#123; try &#123; if ((r.info.flags&amp;ActivityInfo.FLAG_MULTIPROCESS) == 0 || !\"android\".equals(r.info.packageName)) &#123; // Don't add this if it is a platform component that is marked // to run in multiple processes, because this is actually // part of the framework so doesn't make sense to track as a // separate apk in the process. app.addPackage(r.info.packageName, r.info.applicationInfo.versionCode, mService.mProcessStats); &#125; realStartActivityLocked(r, app, andResume, checkConfig); return; &#125; catch (RemoteException e) &#123; Slog.w(TAG, \"Exception when starting activity \" + r.intent.getComponent().flattenToShortString(), e); &#125; // If a dead object exception was thrown -- fall through to // restart the application. &#125; //所以要执行ActivityServiceManager的去开启一个新的进程 mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0, \"activity\", r.intent.getComponent(), false, false, true);&#125; 每一个应用程序都有自己的uid，uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。当然，我们可以配置两个应用程序具有相同的uid和package，或者在AndroidManifest.xml 配置文件的application标签或者activity标签中显式指定相同的process属性值，这样，不同的Activity可以运行在不同的进程中。 mService.startProcessLocked()方法最终会调用到下面的代码去开启新的进程Process.ProcessStartResult startResult = Process.start(entryPoint, app.processName, uid, uid, gids, debugFlags, mountExternal, app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet, app.info.dataDir, entryPointArgs); 新的进程会导入android.app.ActivityThread 类，并且执行它的main方法，这个main方法其实就是一个应用进程的入口方法。这就是为什么我们前面说每一个应用程序都有一个ActivityThread实例来对应的原因。 在main方法中，调用了自身的attach方法，在attach方法中：private void attach(boolean system) &#123; //... final IActivityManager mgr = ActivityManagerNative.getDefault(); try &#123; mgr.attachApplication(mAppThread); &#125; catch (RemoteException ex) &#123; throw ex.rethrowFromSystemServer(); &#125; //...&#125; 在ActivityManagerService的attachApplication()方法中又调用了ttachApplicationLocked()方法：private final boolean attachApplicationLocked(IApplicationThread thread, int pid) &#123; //...代码省略 // See if the top visible activity is waiting to run in this process... if (normalMode) &#123; try &#123; if (mStackSupervisor.attachApplicationLocked(app)) &#123; didSomething = true; &#125; &#125; catch (Exception e) &#123; Slog.wtf(TAG, \"Exception thrown launching activities in \" + app, e); badApp = true; &#125; &#125; // Find any services that should be running in this process... if (!badApp) &#123; try &#123; didSomething |= mServices.attachApplicationLocked(app, processName); &#125; catch (Exception e) &#123; Slog.wtf(TAG, \"Exception thrown starting services in \" + app, e); badApp = true; &#125; &#125; // Check if a next-broadcast receiver is in this process... if (!badApp &amp;&amp; isPendingBroadcastProcessLocked(pid)) &#123; try &#123; didSomething |= sendPendingBroadcastsLocked(app); &#125; catch (Exception e) &#123; // If the app died trying to launch the receiver we declare it 'bad' Slog.wtf(TAG, \"Exception thrown dispatching broadcasts in \" + app, e); badApp = true; &#125; &#125; //...代码省略 这个方法中最终调用了ActivityStackSupervisor类的attachApplicationLocked()方法，而attachApplicationLocked()方法又调用了realStartActivityLocked()方法。 后面的过程就基本与普通Activity启动模式一样了。 参考资料Android源码分析-Activity的启动过程 罗老师的，Android应用程序的Activity启动过程简要介绍和学习计划和 Android应用程序启动过程源代码分析 【凯子哥带你学Framework】Activity启动过程全解析 Android系统篇之—-解读AMS远端服务调用机制以及Activity的启动流程 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/08/02/activity-start-process/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"},{"name":"AMS","slug":"ams","permalink":"http://agehua.github.io/tags/ams/"},{"name":"AOSP","slug":"aosp","permalink":"http://agehua.github.io/tags/aosp/"}]},{"title":"Mac下Android源码编译（AOSP）","slug":"aosp-compile","date":"2017-07-31T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/08/01/aosp-compile/","link":"","permalink":"http://agehua.github.io/2017/08/01/aosp-compile/","excerpt":"Mac下源码编译作为一名安卓开发人员，有能力阅读Android源码，是向高手进阶的重要一步。本文介绍在Mac系统下，进行Android源码编译需要的操作。\n编译需要的步骤android源码编译的四个流程: 1.搭建编译环境; 2.源码下载; 3.编译源码; 4运行.下文也将按照该流程讲述.\n搭建编译环境使用本地工作环境来编译 Android 源文件，需要使用 Linux 或 Mac OS。目前不支持在 Windows 环境下进行编译。","text":"Mac下源码编译作为一名安卓开发人员，有能力阅读Android源码，是向高手进阶的重要一步。本文介绍在Mac系统下，进行Android源码编译需要的操作。 编译需要的步骤android源码编译的四个流程: 1.搭建编译环境; 2.源码下载; 3.编译源码; 4运行.下文也将按照该流程讲述. 搭建编译环境使用本地工作环境来编译 Android 源文件，需要使用 Linux 或 Mac OS。目前不支持在 Windows 环境下进行编译。 系统要求和JDK要求等，参考Google源码编译要求 设置Mac OS编译环境在默认安装过程中，Mac OS 会在一个保留大小写但不区分大小写的文件系统中运行。Git 并不支持此类文件系统。因此，我们建议您始终在区分大小写的文件系统中对 AOSP 源文件进行操作。使用下文中介绍的磁盘映像可以非常轻松地做到这一点。 创建区分大小写的磁盘映像通过 shell 使用以下命令创建磁盘映像：hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg 如果您以后需要更大的存储卷，还可以使用以下命令来调整稀疏映像的大小：hdiutil resize -size 100g ~/android.dmg.sparseimage 我编译的是7.1.1版本的系统源码，狠心之下给了100G空间 对于存储在主目录下的名为 android.dmg 的磁盘映像，您可以向 ~/.bash_profile 中添加辅助函数： # mount the android file imagefunction mountAndroid &#123; hdiutil attach ~/android.dmg -mountpoint /Volumes/android; &#125;# unmount the android file imagefunction umountAndroid() &#123; hdiutil detach /Volumes/android; &#125; 1.要在执行 mountAndroid 时装载磁盘映像 2.要在执行 umountAndroid 时卸载磁盘映像 注意：如果系统创建的是 .dmg.sparseimage 文件，请将 ~/android.dmg 替换成 ~/android.dmg.sparseimage。 装载 android 存储卷后，您将在其中开展所有工作。您可以像对待外接式存储盘一样将其弹出（卸载）。 Android源码下载Android源码的下载要使用到repo工具，这部分主要参考了下面两篇文章：CSDN——自己动手编译最新Android源码及SDKSource-Android——谷歌下载源代码 repo工具下载及安装repo工具负责下载AOSP源码，总结来说，repo就是这么一种工具，由一系列python脚本组成，通过调用Git命令实现对AOSP项目的管理. 在命令行工具里，依次执行下面的命令，实现repo工具的下载和安装mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo &gt; ~/bin/repochmod a+x ~/bin/repo 关于repo工具和AOSP项目的组织方式，感兴趣的看上面的那篇CSDN博客 curl是一个利用URL规则在命令行下工作的文件传输工具，可以说是一款很强大的http命令行工具。它支持文件的上传和下载，是综合传输工具，但按传统，习惯称curl为下载工具。 创建源码目录在上面创建好的磁盘映像里，创建一个目录，用来存放repo工具下载下来的代码。后面编译出的产物也都放在这里。mkdir sourcecd source 初始化仓库我们将上面的source文件夹作为仓库，现在需要来初始化这个仓库了。通过执行初始化仓库命令可以获取AOSP项目master上最新的代码并初始化该仓库，命令如下（需要特殊的翻墙技巧）: repo init -u https://android.googlesource.com/platform/manifest 如果执行上面的命令，提示无法连接到 gerrit.googlesource.com，Operation timed out。那么我们需要编辑 ~/bin/repo文件，找到REPO_URL这一行,然后将其内容修改为:REPO_URL = 'https://gerrit-google.tuna.tsinghua.edu.cn/git-repo' 注意: 上面的地址已经不能用了，要使用下面的地址，具体详情参看：Git Repo 镜像使用帮助REPO_URL = 'https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/' 然后在使用下面的命令初始化仓库：repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest 注意，上面不带参数的manifest命令用于获取master上最新的代码。 可以通过-b参数指定获取某个特定的android版本repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest -b android-4.0.1_r1 AOSP项目当前所有的分支列表参看：https://source.android.com/source/build-numbers#source-code-tags-and-builds 同步源码到本地初始化仓库之后,就可以开始正式同步代码到本地了,命令如下:repo sync 以后如果需要同步最新的远程代码到本地，也只需要执行该命令即可。在同步过程中,如果因为网络原因中断,使用该命令继续同步即可。 同步过程大概需要5个小时，看你的网速了 :) Android Build系统代码下载完成以后，不着急编译，先了解下Android Build系统。 Android Build 系统用来编译 Android 系统，Android SDK 以及相关文档。该系统主要由 Make 文件，Shell 脚本以及 Python 脚本组成，其中最主要的是 Make 文件。Build 系统中最主要的处理逻辑都在 Make 文件中，而其他的脚本文件只是起到一些辅助作用。整个 Build 系统中的 Make 文件可以分为三类： 第一类是 Build 系统核心文件，此类文件定义了整个 Build 系统的框架，而其他所有 Make 文件都是在这个框架的基础上编写出来的。 第二类是针对某个产品（一个产品可能是某个型号的手机或者平板电脑）的 Make 文件，这些文件通常位于 device 目录下，该目录下又以公司名以及产品名分为两级目录。对于一个产品的定义通常需要一组文件，这些文件共同构成了对于这个产品的定义。例如，/device/sony/it26 目录下的文件共同构成了对于 Sony LT26 型号手机的定义。 第三类是针对某个模块的 Make 文件。整个系统中，包含了大量的模块，每个模块都有一个专门的 Make 文件，这类文件的名称统一为“Android.mk”，该文件中定义了如何编译当前模块。Build 系统会在整个源码树中扫描名称为“Android.mk”的文件并根据其中的内容执行模块的编译。 更多编译系统的内容，请看IBM的这篇文章：Android Build系统 编译 Android 系统初始化编译环境执行：source build/envsetup.sh 这句话的意思是引入build/envsetup.sh脚本。该脚本的作用是初始化编译环境，并引入一些辅助的 Shell 函数，这其中就包括下面使用 lunch 函数。 选择编译目标执行：lunch 执行完lunch函数，可以看到下面的结果：You're building on DarwinLunch menu... pick a combo: 1. aosp_arm-eng 2. aosp_arm64-eng 3. aosp_mips-eng 4. aosp_mips64-eng 5. aosp_x86-eng 6. aosp_x86_64-eng 7. full_fugu-userdebug 8. aosp_fugu-userdebug 9. mini_emulator_arm64-userdebug 10. m_e_arm-userdebug 11. m_e_mips-userdebug 12. m_e_mips64-eng 13. mini_emulator_x86-userdebug 14. mini_emulator_x86_64-userdebug 15. aosp_dragon-userdebug 16. aosp_dragon-eng 17. aosp_marlin-userdebug 18. aosp_sailfish-userdebug 19. aosp_flounder-userdebug 20. aosp_angler-userdebug 21. aosp_bullhead-userdebug 22. hikey-userdebug 23. aosp_shamu-userdebugWhich would you like? [aosp_arm-eng] 这里的lunch是选择编译目标，直接输入数字就代表选中 编译目标格式说明: 编译目标的格式:BUILD-BUILDTYPE,比如上面的第一个，aosp_arm-eng的BUILD是aosp_arm，BUILDTYPE是eng. 编译目标的选择，决定了模拟器的响应速度，那么选择哪个编译目标呢？这里StackOverflow上有提问，建议编译aosp_x86-userdebug with HAXM installed 但是我的lunch并没有列出这个编译目标： 所以这里可以使用choosecombo命令,记住也要先执行envsetup.sh脚本哟： choosecomboBuild type choices are: 1. release 2. debugWhich would you like? [1]//这里直接输入2，选择第二个Which product would you like? [aosp_arm]//这里并没有对应的BUILD，所以直接自己输入：aosp_x86Variant choices are: 1. user 2. userdebug 3. eng//这里选择第二个，直接输入2 这样就选择好了编译目标，对应的Terminal的顶部标题也已经改变 编译选择好编译目标后，调用“make -j*”进行编译就可以了. 可以看到线程数为8. make 的参数“-j”指定了同时编译的 Job 数量，这是个整数，该值通常是编译主机 CPU 支持的并发线程总数的 1 倍或 2 倍（例如：在一个 4 核，每个核支持两个线程的 CPU 上，可以使用 make -j8 或 make -j16） 可以使用下面的命令查看本机CPU的内核数与线程数： $ sysctl machdep.cpumachdep.cpu.core_count: 2machdep.cpu.thread_count: 4machdep.cpu.tsc_ccc.numerator: 242machdep.cpu.tsc_ccc.denominator: 2 可以看到我的电脑线程数为4，所以我采用 make -8 编译成功后，使用 emulator 命令就可以运行编译出来的模拟器啦。 下面介绍几个常用到的命令： 如果make失败，或是想换一个BUILD类型，使用下面的命令：make clobber //清理out目录下的文件 ncdu，当电脑磁盘空间不够用时，用下面的命令，遍历大文件 sudo ncdu //查看硬盘中的大文件 安装方式： brew install ncdu 调试Android源码：参考这篇文章：自己动手调试Android源码 将Android源码导入Android Studio：source build/envsetup.shmmm development/tools/idegen/sudo ./development/tools/idegen/idegen.sh 上面代码执行完后，会在源码目录下生成IEDA工程配置文件: android.ipr,android.iml及android.iws.可以发现android.ipr文件的应用图标应该改成了Android Studio样式。 但这里不用Android Studio来打开工程，而是使用IntelliJ来查看和DebugAndroid源码，具体参考这篇文章使用 IntelliJ 查看 Android 源码 单独编译Android源代码工程的模块在Android源码找到目录/packages/experimental，在这个目录下有Google提供基于前面提到的Android BUILD模式构建的apk工程。如下图： 我们选择一个工程：MultiPackageApk，要把它安装到模拟器上需要执行下面的命令：source build/envsetup.shmmm packages/experimental/MultiPackageApk make snod 重启下模拟器，刚才安装的应用就会出现了 单独编译源代码工程出错： ninja: error: 'out/target/common/obj/JAVA_LIBRARIES/core-junit_intermediates/classes.dex.toc', needed by 'out/target/common/obj/APPS/MultiPackageApk_intermediates/with-local/classes.dex', missing and no known rule to make itmake: *** [ninja_wrapper] Error 1 解决方案：应该选择好编译环境后（用lunch或choosecombo命令），再执行单独编译源码工作，最后别忘了执行make snod 使用 IntelliJ Debug Android 源码参考这篇文章：使用 IntelliJ Debug Android 源码 文中，有一个地方跟我的电脑上不太一样： 打开 monitor 选择 debug 进程我电脑上的monitor不是用命令行打开，而是有monitor.app。位置在：/Library/Android_sdk/tools/lib/monitor-x86_64/monitor.app如下图： 到这里Android源码部分的内容就整理完了，下篇文章利用Android源码分析下Activity的启动流程。 ccache造成硬盘空间不足ccache 是一个是适用于 C 和 C++ 的编译器缓存，有助于提高编译速度。但是它本身是采用牺牲空间换取编译速度的方式。如果你设置了 ccache，而且经常使用 make clean，或者经常在不同的编译产品之间切换（比如choosecombo 或 lunch命令），会导致大量的硬盘存储空间被占用。 默认情况下，ccache 的缓存将存储在 ~/.ccache 下。如果你用的是MAC 电脑编译的 AOSP，可以看下这个目录有多大 :( 要想清理空间，直接删除 ~/.ccache 下的内容即可。 具体介绍参考google：设置 ccache 错误收集1.Try increasing heap size with java option ‘-Xmx‘ 这个是说明需要增加Java heap size，具体参见stackoverflow 解决方法是： export JACK_SERVER_VM_ARGUMENTS=\"-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g\"./prebuilts/sdk/tools/jack-admin kill-server./prebuilts/sdk/tools/jack-admin start-server 2.failed to build aosp. says subcommand failedMAC系统升级到high sierra，在用make指令编译源码的时候报错，没有更多提示，只有下面的日志：... system/tools/aidl/aidl_language_y.yy... aidl_language_l.cppninja: build stopped: subcommand failed.15:57:14 ninja failed with: exit status 1 #### failed to build some targets (05:20 (mm:ss)) #### 关键错误信息是aidl_language_y.yy和aidl_language_l.cpp 解决方案： Step1. Patch bison fix for High Sierra and build bison: 1. cd /Volumes/AOSP/external/bison2. git cherry-pick c0c852bd6fe462b148475476d9124fd740eba1603. mm Step2. Replace prebuilt bison binary with patched binary 1. cp /Volumes/AOSP/out/host/darwin-x86/bin/bison /Volumes/AOSP/prebuilts/misc/darwin-x86/bison/ Step3. Build 1. make -j4 如果mm命令无法执行，需要回去执行以下命令:source build/envsetup.shlunch #之后回到external/bison目录mm 参考自：http://www.jianshu.com/p/35f840dd7869 和https://groups.google.com/forum/#!topic/android-building/D1-c5lZ9Oco 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/08/01/aosp-compile/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AOSP","slug":"aosp","permalink":"http://agehua.github.io/tags/aosp/"},{"name":"sdk compile","slug":"sdk-compile","permalink":"http://agehua.github.io/tags/sdk-compile/"}]},{"title":"Android免root实现hook系统服务拦截方法","slug":"android-noroot-hook","date":"2017-07-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.326Z","comments":true,"path":"2017/07/12/android-noroot-hook/","link":"","permalink":"http://agehua.github.io/2017/07/12/android-noroot-hook/","excerpt":"本文转载自博文：Android系统篇之—-免root实现Hook系统服务拦截方法，结合最新开源的滴滴插件化方案 VirtualApk 对hook系统服务进行分析。\n360之前开源了一款插件框架 Droid Plugin。与滴滴同一天，360又开源了一款插件框架 RePlugin。\n有关新闻介绍在这里：https://www.itcodemonkey.com/article/278.html                https://www.itcodemonkey.com/article/277.html\n关于360两款插件框架有什么不同，可以查看RePlugin里的readme\n本文简单结合VirtualApk源码来记录实现hook系统服务方法。\nAndroid免root实现hook系统服务拦截方法Binder机制回顾","text":"本文转载自博文：Android系统篇之—-免root实现Hook系统服务拦截方法，结合最新开源的滴滴插件化方案 VirtualApk 对hook系统服务进行分析。 360之前开源了一款插件框架 Droid Plugin。与滴滴同一天，360又开源了一款插件框架 RePlugin。 有关新闻介绍在这里：https://www.itcodemonkey.com/article/278.html https://www.itcodemonkey.com/article/277.html 关于360两款插件框架有什么不同，可以查看RePlugin里的readme 本文简单结合VirtualApk源码来记录实现hook系统服务方法。 Android免root实现hook系统服务拦截方法Binder机制回顾 在之前一篇文章中介绍了 Android中的Binder机制和系统远程服务调用机制，本文将继续借助上一篇的内容来实现Hook系统服务拦截指定方法的逻辑，了解了上一篇文章之后，知道系统的服务其实都是一个远程Binder对象，而这个对象都是由ServiceManager大管家管理的，用户在使用系统服务的时候，会通过指定服务的Stub方法的asInterface把远程的Binder对象转化成本地化对象即可使用，而在这个过程中，我们也知道因为系统服务是在system_server进程中的，所以这个系统服务使用过程中属于跨进程调用，那么返回的对象其实就是Proxy代理对象。 系统中服务使用流程本文主要就是借助这个知识点，通过Hook系统的服务来拦截服务方法，下面我们就通过系统剪切板服务案例作为分析//获取剪切板服务ClipboardManager cm =(ClipboardManager)getSystemService(Context.CLIPBOARD_SERVICE);//设置剪切板内容cm.setPrimaryClip(ClipData.newPlainText(\"data\",\"jack\"));//获取剪切板数据对象ClipData cd = cm.getPrimaryClip();String msg = cd.getItemAt(0).getText().toString();Log.d(\"jw\", \"msg:\"+ msg); 这里看到了，使用系统服务的时候都是用了getSystemService方法，通过定义在Context中的服务描述符常量来获取服务对象，而getSystemService方法定义在ComtextImpl.java类中：@Overridepublic Object getSystemService(String name) &#123; ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); return fetcher == null ? null : fetcher.getService(this);&#125; 这里维护了一个ServiceFetcher的Map结构，看看这个结构在哪里填充数据的：private static void registerService(String serviceName, ServiceFetcher fetcher) &#123; if (!(fetcher instanceof StaticServiceFetcher)) &#123; fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++; &#125; SYSTEM_SERVICE_MAP.put(serviceName, fetcher);&#125; 在registerService方法中添加一个服务名称和一个ServiceFetcher对象，而这个方法在静态代码块中进行调用的:static &#123; registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() &#123; public Object getService(ContextImpl ctx) &#123; return AccessibilityManager.getInstance(ctx); &#125;&#125;); //... registerService(CLIPBOARD_SERVICE, new ServiceFetcher() &#123; public Object createService(ContextImpl ctx) &#123; return new ClipboardManager(ctx.getOuterContext(), ctx.mMainThread.getHandler()); &#125;&#125;); //.... registerService(CONNECTIVITY_SERVICE, new ServiceFetcher() &#123; public Object createService(ContextImpl ctx) &#123; IBinder b = ServiceManager.getService(CONNECTIVITY_SERVICE); return new ConnectivityManager(IConnectivityManager.Stub.asInterface(b)); &#125;&#125;); //....&#125; ClipboardManager这个服务也在这个代码块中注册了 这里其实是一个ClipboardManager对象，其实这个对象是内部封装了IClipboard.Stub功能，可以看看其他的服务，比如上面的联网服务，直接调用了IConnectivityManager.Stub类的asInterface方法获取Proxy对象。 下面就进去ClipboardManager.java中看看究竟：public void setPrimaryClip(ClipData clip) &#123; try &#123; if (clip != null) &#123; clip.prepareToLeaveProcess(); &#125; getService().setPrimaryClip(clip, mContext.getOpPackageName()); &#125; catch (RemoteException e) &#123; &#125;&#125; 看到这里的设置剪切板内容的方法，其实内部是调用了getService方法获取对象然后在调用指定方法，那么可以大概知道了这个getService方法返回的应该就是IClipboard.Stub通过asInterface方法返回的Proxy对象：static private IClipboard getService() &#123; synchronized (sStaticLock) &#123; if (sService != null) &#123; return sService; &#125; IBinder b = ServiceManager.getService(\"clipboard\"); sService = IClipboard.Stub.asInterface(b); return sService; &#125;&#125; 吧，果然是这样，这里通过ServiceManager获取到Clipboard的远端IBinder对象，然后通过asInterface方法返回一个Proxy对象即可。 到这里我们就简单的分析完了系统中的获取剪切板的服务，其实系统中的服务都是这么个逻辑，只是有的可能会在外面包装一层罢了，下面总结一下流程： 现在只要记住一点：每次获取系统服务的流程都是一样的，先通过ServiceManager的getService方法获取远端服务的IBinder对象，然后在通过指定服务的Stub类的asInterface方法转化成本地可使用对象，而这个对象其实就是一个Proxy对象，在这个过程中，Stub类继承了Binder对象和实现了AIDL接口类型，Proxy对象实现了AIDL接口类型，而AIDL接口类型实现了IInterface接口类型。 Hook系统服务上面分析完了Android中系统服务的使用流程以及原理解析，下面在来看一下android中实现Hook机制的方法和原理解析，我们知道其实在很多系统中都存在这样一个Hook技术，有的也叫作钩子，但是不管任何系统，Hook技术的核心点都是一样的，只有两点即可完成Hook技术： 1、找到Hook点，即你想Hook哪个对象，那么得先找到这个对象定义的地方，然后使用反射获取到这个对象实例。所以这里可以看到，一般Hook点都是一个类的单例方法或者是静态变量，因为这样的话Hook起来就非常方便，都是static类型，反射调用都比较方便无需具体的实例对象即可。而关于这个点也是整个Hook过程中最难的点，因为很难找到这个点。Android中主要是依靠分析系统源码类来做到的。 2、构造一个Hook原始对象的代理类，关于这个代理其实在Java中有两种方式，一种是静态代理，一种是动态代理。 静态代理：代理类中维护一个原始对象的成员变量，每个方法调用之前调用原始对象的方法即可。无需任何条件限制 动态代理：比静态代理复杂点就是有一个规则：就是原始对象必须要实现接口才可以操作，原理是因为动态代理其实是自动生成一个代理类的字节码，类名一般都是Proxy$0啥的，这个类会自动实现原始类实现的接口方法，然后在使用反射机制调用接口中的所有方法。 下面结合VirtualApk源码，分析这个原理： 这里的代码与原博文里的代码有所不同，原博文是结合DroidPlugin进行分析 在VirtualApk的源码com/didi/virtualapk/delegate/目录下，有两个Proxy结尾的类，这两个类动态代理模式相同，我们只看一个。在IContentProviderProxy.java文件中public class IContentProviderProxy implements InvocationHandler &#123; //.....代码省略 public static IContentProvider newInstance(Context context, IContentProvider iContentProvider) &#123; return (IContentProvider) Proxy.newProxyInstance(iContentProvider.getClass().getClassLoader(), new Class[] &#123; IContentProvider.class &#125;, new IContentProviderProxy(context, iContentProvider)); &#125; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable &#123; Log.v(TAG, method.toGenericString() + \" : \" + Arrays.toString(args)); wrapperUri(method, args); try &#123; return method.invoke(mBase, args); &#125; catch (InvocationTargetException e) &#123; throw e.getTargetException(); &#125; &#125; //...代码省略&#125; 看到这里，了解java AOP技术的已经知道IContentProviderProxy这个类使用了java.lang.ref.proxy方案来实现动态生成代理类。 不了解ASM和InvocationHandler的同学可以看IBM的这篇文章：AOP 的利器：ASM 3.0 介绍 简单介绍下java本身的动态代理机制在java的动态代理机制中，有两个重要的类或接口，一个是InvocationHandler(Interface)、另一个则是Proxy(Class)，这一个类和接口是实现我们动态代理所必须用到的。 这里借用上面IBM的文章中的例子：Account类是一个接口，具体操作由AccountImpl类实现public interface Account &#123; void operation();&#125; public class AccountImpl extends Account&#123; public void operation() &#123; System.out.println(\"operation...\"); //TODO real operation &#125;&#125; 现在的要求是在Account的operation()方法执行前加入一个checkSecurity()检查。 那么使用InvocationHandler和Proxy的实现方式就是：class SecurityProxyInvocationHandler implements InvocationHandler &#123; private Object proxyedObject; public SecurityProxyInvocationHandler(Object o) &#123; proxyedObject = o; &#125; @Override public Object invoke(Object object, Method method, Object[] arguments) throws Throwable &#123; if (object instanceof Account &amp;&amp; method.getName().equals(\"opertaion\")) &#123; SecurityChecker.checkSecurity(); &#125; return method.invoke(proxyedObject, arguments); &#125;&#125; public static void main(String[] args) &#123; Account account = (Account) Proxy.newProxyInstance( Account.class.getClassLoader(), new Class[] &#123; Account.class &#125;, new SecurityProxyInvocationHandler(new AccountImpl()) ); account.function();&#125; 总结如下： InvocationHandler这个接口只有一个方法invoke()： Object invoke(Object proxy, Method method, Object[] args) throws Throwable proxy: 指代我们所代理的那个真实对象 method: 指代的是我们所要调用真实对象的某个方法的Method对象 args: 指代的是调用真实对象某个方法时接受的参数 每一个动态代理类都必须要实现InvocationHandler这个接口，当我们通过代理对象（这里就是account对象）调用一个方法的时候，这个方法的调用就会被转发为由InvocationHandler这个接口的invoke方法来进行调用 Proxy类使用的最多的就是newProxyInstance这个方法： public static Object newProxyInstance(ClassLoader loader, Class&lt;?&gt;[] interfaces, InvocationHandler h) throws IllegalArgumentException loader: 一个ClassLoader对象，定义了由哪个ClassLoader对象来对生成的代理对象进行加载 interfaces: 一个Interface对象的数组，表示的是我将要给我需要代理的对象提供一组什么接口，如果我提供了一组接口给它，那么这个代理对象就宣称实现了该接口(多态)，这样我就能调用这组接口中的方法了 h: 一个InvocationHandler对象，表示的是当我这个动态代理对象在调用方法的时候，会关联到哪一个InvocationHandler对象上 Proxy类并不负责实例化对象，newProxyInstance()方法的作用是动态创建一个代理对象的类。 Proxy动态生成代理的不足之处在于： Proxy 是面向接口的，所有使用 Proxy 的对象都必须定义一个接口，而且用这些对象的代码也必须是对接口编程的：Proxy 生成的对象是接口一致的而不是对象一致的：例子中 Proxy.newProxyInstance 生成的是实现 Account接口的对象而不是 AccountImpl 的子类。这对于软件架构设计，尤其对于既有软件系统是有一定掣肘的。 Proxy 毕竟是通过反射实现的，必须在效率上付出代价：有实验数据表明，调用反射比一般的函数开销至少要大10倍。而且，从程序实现上可以看出，对 proxy class 的所有方法调用都要通过使用反射的 invoke 方法。因此，对于性能关键的应用，使用 proxy class 是需要精心考虑的，以避免反射成为整个应用的瓶颈。 对比VirtualApk框架中的 IContentProviderProxy 类，和上面Account例子里的 SecurityProxyInvocationHandler 类，可以发现，IContentProviderProxy 使用了 InvocationHandler 的动态代理机制，而代理的具体内容就在invoke()回调里。 好的，现在在回到VirtualApk的IContentProviderProxy源码的invoke()方法里。invoke() 方法中调用了wrapperUri()，来看下这个方法：private void wrapperUri(Method method, Object[] args) &#123; Uri uri = null; int index = 0; if (args != null) &#123; for (int i = 0; i &lt; args.length; i++) &#123; if (args[i] instanceof Uri) &#123; uri = (Uri) args[i]; index = i; break; &#125; &#125; &#125; //如果挂钩的是call方法 Bundle bundleInCallMethod = null; if (method.getName().equals(\"call\")) &#123; bundleInCallMethod = getBundleParameter(args); if (bundleInCallMethod != null) &#123; String uriString = bundleInCallMethod.getString(KEY_WRAPPER_URI); if (uriString != null) &#123; uri = Uri.parse(uriString); &#125; &#125; &#125; //... PluginManager pluginManager = PluginManager.getInstance(mContext); //这里根据uri找到对应的ContentProvider ProviderInfo info = pluginManager.resolveContentProvider(uri.getAuthority(), 0); if (info != null) &#123; String pkg = info.packageName; LoadedPlugin plugin = pluginManager.getLoadedPlugin(pkg); String pluginUri = Uri.encode(uri.toString()); StringBuilder builder = new StringBuilder(PluginContentResolver.getUri(mContext)); builder.append(\"/?plugin=\" + plugin.getLocation()); builder.append(\"&amp;pkg=\" + pkg); builder.append(\"&amp;uri=\" + pluginUri); Uri wrapperUri = Uri.parse(builder.toString()); if (method.getName().equals(\"call\")) &#123; bundleInCallMethod.putString(KEY_WRAPPER_URI, wrapperUri.toString()); &#125; else &#123; args[index] = wrapperUri; &#125; &#125;&#125; 1.从wrapperUri()的第二个参数找到Uri 2.调用resolveContentProvider()方法，根据uri找到占坑的ContentProvider public ProviderInfo resolveContentProvider(String name, int flags) &#123; return this.mProviders.get(name);&#125; ProviderInfo对象的解释就是：Holds information about a specific content provider 3.使用StringBuilder对，将uri，pkg，plugin等参数等拼接上去，替换到args中的uri，然后继续走原本的流程。 假设是调用了query方法，应该就可以到达占坑的provider的query方法了。这就是插件框架里传说中的占坑，即不用注册就可以启动插件里的组件啦 剪切板实例到此我们了解了Java中的Hook技术的核心知识点了，下面就用开始的剪切板服务来做实验，我们Hook系统的剪切板服务功能，拦截其方法，上面也说道了，既然要Hook服务，首先得找到Hook点，通过开始对Android中系统服务的调用流程分析知道，其实这些服务都是一些保存在ServiceManager中的远端IBinder对象，这其实是一个Hook点： public static IBinder getService(String name) &#123; try &#123; IBinder service = sCache.get(name); if (service != null) &#123; return service; &#125; else &#123; return getIServiceManager().getService(name); &#125; &#125; catch (RemoteException e) &#123; Log.e(TAG, \"error in getService\", e); &#125; return null;&#125; 其实ServiceManager中每次在获取服务的时候，其实是先从一个缓存池中查找，如果有就直接返回了：private static HashMap&lt;String, IBinder&gt; sCache = new HashMap&lt;String, IBinder&gt;(); 这个缓存池正好是全局的static类型，所以就可以很好的使用反射机制获取到它了，然后进行操作了 接下来，我们就需要构造一个剪切板的服务IBinder对象了，然后在把这个对象放到上面得到的池子中即可。 那么按照上面的动态代理的流程（使用Proxy Java原生动态代理） 第一、原始对象必须实现一个接口，这里也正好符合这个规则，每个远程服务其实是实现了IBinder接口的。 第二、其次是要有原始对象，这个也可以，通过上面的缓存池即可获取。 有了这两个条件那么接下来就可以使用动态代理构造一个代理类了：try &#123; //下面这一段的意思其实就是ServiceManager.getService(\"clipboard\") //只不过ServiceManager这个类是@hide的 Class&lt;?&gt; serviceManager = Class.forName(\"android.os.ServiceManager\"); Method getService = serviceManager.getDeclaredMethod(\"getService\", String.class); //取得ServiceManager里的原始的clipboard binder对象 //一般来说这是一个Binder代理对象 IBinder rawBinder =(IBinder) getService.invoke(null, Context.CLIPBOARD_SERVICE); //Hook掉这个Binder代理的queryLocalInterface 方法 //然后在queryLocalInterface返回一个IInterface对象，hook掉我们感兴趣的方法即可 IBinder hookedBinder =(IBinder) Proxy.newProxyInstance( serviceManager.getClassLoader, new Class&lt;?&gt;[](IBinder.class), new IClipboardHookBinderHandler(rawBinder) ); //放回ServiceManager中，替换掉原有的 Field cacheField = serviceManager.getDeclaredField(\"sCache\"); cacheField.setAccessible(true); @SuppressWarnings(&#123;\"unchecked\"&#125;) Map&lt;String, IBinder&gt; cache = (Map&lt;String,IBinder&gt;) cacheField.get(null); cache.put(Context.CLIPBOARD_SERVICE, hookedBinder);&#125;catch (Exception e)&#123;&#125; Field.get()可以返回一个Object，字段不是静态字段的话，要传入反射类的对象。如果传null是会报 java.lang.NullPointerException。但是如果字段是静态字段的话,传入任何对象都是可以的,包括null 这里是通过反射去获取ServiceManager中的缓存池Binder对象。我们先获取到缓存池，然后得到剪切板服务Binder对象，构造一个代理类，最后在设置回去即可。 下面主要来看一下构造了代理类之后，如何拦截哪些方法？@Overridepublic Object invoke(Object object, Method method, Object[] args) throws Throwable &#123; if (method.getName().equals(\"queryLocalInterface\")) &#123; Log.d(TAG, \"hook queryLocalInterface\"); //这里直接返回真正被hook掉的Service接口 //这个代理类必须实现IInterface接口 return Proxy.newProxyInstance( base.getClassLoader, new Class&lt;?&gt;[](this.iinterface), new HookBinderInvocationHander(base,stub) ); &#125; return method.invoke(base, args);&#125; 因为拦截的是queryLocalInterface()方法，这个方法返回的是一个远端的服务，还没有转化为本地对象，所以不能去拦截具体的服务方法 这里一定要注意了，有的同学可能想直接在这里拦截setPrimaryClip这样的剪切板方法不就可以了吗？想想是肯定不可以的，为什么呢？因为我们现在代理的是远端服务的Binder对象，他还没有转化成本地对象呢？如何会有这些方法呢，而我们真正要拦截的方法是IClipboardManager，其实就是Proxy类，而这个对象也是Stub类的asInterface方法得到的，所以我们现在的思路是有了远端服务的代理对象，拦截肯定是拦截这个代理对象Binder的一些方法，那么这个远端服务有哪些方法会在这个过程中被调用呢？我们再看看之前的一个简单AIDL的例子：public static com.agehua.aidldemo.Demo asInterface(android.os.IBinder obj) &#123; if ((obj == null)) &#123; return null; &#125; //这里的obj就是远端对象，它通过queryLocalInterface()方法获取本进程中的服务，这里就是hook点 android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) &amp;&amp; (iin instanceof com.agehua.aidldemo.Demo))) &#123; return ((com.agehua.aidldemo.Demo) iin); &#125; return new com.agehua.aidldemo.Demo.Stub.Proxy(obj);&#125; 然后在想，我们如果想拦截IClipboardManager的setPrimaryClip方法，其实就是要拦截ClipboardManager$Proxy的这些方法，那么还需要做一次代理，代理ClipboardManager$Proxy类对象 第一、ClipboardManager$Proxy类实现了AIDL接口类型，符合规则。 第二、我们可以直接使用反射获取到IClipboardManager$Stub类，然后反射调用它的asInterface方法就可以得到了IClipboardManager$Proxy对象了，符合规则。 public IClipboardHookBinderHandler(IBinder base) &#123; this.base = base; try &#123; this.stub =Class.forName(\"android.content.IClipboard$Stub\"); this.iinterface = Class.forName(\"android.content.IClipboard\"); &#125;catch (ClassNotFoundException e)&#123; &#125;&#125; 到这里，看来这个对象也符合了代理的条件，那么就简单了，继续使用动态代理机制产生一个代理类即可：public IClipboardHookBinderHandler(IBinder base, Class&lt;?&gt; stubClass) &#123; try &#123; Method asInterfaceMethod = stubClass.getDeclaredMethod(\"asInterface\", IBinder.class); this.base = asInterfaceMethod.invoke(null, base); &#125;catch (Exception e)&#123; throw new RuntimeException(\"hooked failed\") &#125;&#125; 这个代理类的InvocationHandler中，先需要通过反射获取到Proxy原始对象：@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable&#123; if (\"getPrimaryClip\".equals(method.getName())) &#123; return ClipData.newPlainText(null, \"you are hooked\"); &#125; //欺骗系统，使之认为剪切板上一直有内容 if (\"hasPrimaryClip\".equals(method.getName())) &#123; return true; &#125; //千万不要忘了调用原始对象的方法 return method.invoke(base, args);&#125; 到这里就已经完成了hook剪切板服务的整个步骤，再看一下流程图： 1、我们的目的就是拦截系统的服务功能，那么最开始的入口就是服务大管家ServiceManager对象，而在他内部也正好有一个远端服务对象的IBinder缓存池，那么这个变量就是我们操作的对象了，可以先使用反射机制去获取到他，然后在获取到指定的剪切板服务IBinder对象实例。 2、下一步肯定是Hook这个剪切板服务的Binder对象，这里采用动态代理方式产生一个Binder对象代理类，符合两个规则： 1) 这个Binder对象实现了IBinder接口类型 2) 我们已经得到了原始的Binder对象实例构造完代理类之后，我们拦截的方法是queryLocalInterface方法，为什么是这个方法呢？因为在整个服务使用过程中之后在Stub类中使用到了这个方法，很多同学会认为为什么不在这里直接拦截系统方法呢？这是一个误区，要想清楚，这里的代理对象是远程服务的Binder，还不是本地化对象，不能会有哪些系统方法的，所以得再做一次Hook，去Hook住系统的本地化对象。 3、在拦截了Binder对象的queryLocalInterface方法之后，再一次做一下本地化服务对象的代理生成操作，而这个本地化对象一般都是IClipboard$Proxy，那么动态代理的规则： 1) 本地化服务对象都会实现AIDL接口类型(这里才有哪些我们想拦截的系统方法) 2) 通过反射调用IClipboard$Stub类的asInterface方法得到IClipboard$Proxy类对象实例符合这两个规则那么就可以产生代理对象了，然后开始拦截服务的指定方法即可。 这个Hook系统服务只对本应用有效。真正能够拦截系统并对所有应用有效的，需要hook进system_server进程中，所以就需要root权限 总结到这里我们就介绍完了Android中Hook系统服务的流程，本文中主要介绍了Hook系统剪切板服务，拦截指定方法。同时，对VirtualApk插件框架感兴趣的同学也可以看看张鸿洋的这篇文章： 滴滴插件化方案 VirtualApk 源码解析 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/07/12/android-noroot-hook/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"},{"name":"HOOK","slug":"hook","permalink":"http://agehua.github.io/tags/hook/"},{"name":"Android system service","slug":"android-system-service","permalink":"http://agehua.github.io/tags/android-system-service/"}]},{"title":"Android Binder机制分析（二）","slug":"android-binder-principle2","date":"2017-07-09T16:00:00.000Z","updated":"2024-12-05T09:41:56.322Z","comments":true,"path":"2017/07/10/android-binder-principle2/","link":"","permalink":"http://agehua.github.io/2017/07/10/android-binder-principle2/","excerpt":"背景上篇文章分析到了Binder机制，分别介绍了自定义AIDL服务和调用系统的远程服务和他们之间的区别。本文承接上篇文章，继续介绍ServiceManager和系统服务的注册流程，最后对Binder机制进行分析。\n\n关于系统服务的注册流程，大都转载自这篇文章\n\n服务大管家ServiceManager\nServiceManager.java的源码可以在谷歌源码中看到，点击这里\n\n上篇文章末尾提到，系统服务的IBinder对象都是由ServiceManager统一管理的。为什么这么说呢，先看下ServiceManager.getService方法:","text":"背景上篇文章分析到了Binder机制，分别介绍了自定义AIDL服务和调用系统的远程服务和他们之间的区别。本文承接上篇文章，继续介绍ServiceManager和系统服务的注册流程，最后对Binder机制进行分析。 关于系统服务的注册流程，大都转载自这篇文章 服务大管家ServiceManager ServiceManager.java的源码可以在谷歌源码中看到，点击这里 上篇文章末尾提到，系统服务的IBinder对象都是由ServiceManager统一管理的。为什么这么说呢，先看下ServiceManager.getService方法:/** * Returns a reference to a service with the given name. * * @param name the name of the service to get * @return a reference to the service, or &lt;code&gt;null&lt;/code&gt; if the service doesn't exist */public static IBinder getService(String name) &#123; try &#123; IBinder service = sCache.get(name); if (service != null) &#123; return service; &#125; else &#123; return getIServiceManager().getService(name); &#125; &#125; catch (RemoteException e) &#123; Log.e(TAG, \"error in getService\", e); &#125; return null;&#125; sCache是一个本地静态Map对象，作为缓存池：private static HashMap&lt;String, IBinder&gt; sCache = new HashMap&lt;String, IBinder&gt;(); ServiceManager本身会维护一个IBinder缓存池，也是为了效率高考虑，对于一个应用频繁的使用一些服务的话效率就会高很多。 然后最核心的获取服务的方法是getIServiceManager方法：private static IServiceManager getIServiceManager() &#123; if (sServiceManager != null) &#123; return sServiceManager; &#125; // Find the service manager sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject()); return sServiceManager;&#125; 在上面的代码中，调用了ServiceManagerNative.asInterface()方法，是不是说明ServiceManager也通过远端服务来取得对应的服务呢？ 具体在看一下ServiceManagerNative.java方法：public abstract class ServiceManagerNative extends Binder implements IServiceManager&#123; /** * Cast a Binder object into a service manager interface, generating * a proxy if needed. */ static public IServiceManager asInterface(IBinder obj) &#123; if (obj == null) &#123; return null; &#125; IServiceManager in = (IServiceManager)obj.queryLocalInterface(descriptor); if (in != null) &#123; return in; &#125; return new ServiceManagerProxy(obj); &#125; //....&#125; 看到上面的代码，基本可以确认，在获取ServiceManager对象也是通过了远程调用。只是名字改成了ServiceManagerNative，本应该叫ServiceManagerService的。 看到这里的ServiceManager也是通过远端服务获取到他的IBinder对象，然后在转化成本地对象进行使用的。那么刚刚看到系统的服务都是通过ServiceManager管理获取的，而现在ServiceManager本身是怎么获取到的IBinder对象的呢？这个就要从系统启动的时机看了，众所周知系统启动的时候是根据init.rc文件进行操作的： service servicemanager /system/bin/servicemanager class core user system group system critical onrestart restart healthd onrestart restart zygote onrestart restart media onrestart restart surfaceflinger onrestart restart drm 这里会启动一个servicemanager服务，那么就要去service_manager.c程序中的入口程序看了： 这个入口其实包含了Binder机制的重要信息，而主要就是三件事： 1、打开底层的Binder驱动程序，这个后面介绍Binder机制在介绍 2、通过向binder程序发送命令：BINDER_SET_CONTEXT_MGR，告诉binder程序，我要成为大管家 3、进入循环监听上层应用的服务请求处理，所以这里可以看到其实ServiceManager是一个守护进程在后台默默监听 在第二步中成为大管家的代码深入看一看： 其实这里的逻辑也是比较简单的，首先创建一个属于servicemanager的binder节点，然后在创建一个binder链表，而这个链表的作用就是存放上层中需要系统服务的所有binder对象的节点，这样ServiceManager就可以实现了服务的增加和查询操作了。 再来看看ServiceManager的添加服务操作： 添加服务比较复杂，首先查看这个服务有没有注册权限限制，不是所有的服务都能注册的，然后在查看这个服务是不是已经被注册过了，最后在通知binder驱动程序注册一个服务即可。 然后在来看看ServiceManager的查找服务功能： 查找服务就比较简单了，直接通过服务的描述符名称遍历binder链表节点即可。 1、Service Manager能集中管理系统内的所有服务，它能被施加权限控制，并不是任何进程都能注册服务的。 2、Service Manager支持通过字符串名称来查找对应的Service。 3、由于各种原因的影响，Server进程可能生死无常。如果有了Service Manager做统一的管理，那么Client只要向Service Manager做查询，就能得到Server的最新信息。 系统服务注册流程分析这部分内容也可以参考博客：Android深入浅出之Binder机制 下面来看一下一些系统服务是如何进程注册的，这里用MediaService来进行查看吧。 系统中的MediaService服务的启动也是在init.rc中的service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ioprio rt 4 查看Main_mediaserver.cpp源码的main函数：int main(int argc, char** argv)&#123; //获得一个ProcessState实例 sp&lt;ProcessState&gt; proc(ProcessState::self()); //得到一个ServiceManager对象 sp&lt;IServiceManager&gt; sm = defaultServiceManager(); MediaPlayerService::instantiate();//初始化MediaPlayerService服务 ProcessState::self()-&gt;startThreadPool(); IPCThreadState::self()-&gt;joinThreadPool();&#125; sp是google搞出来的为了方便C/C++程序员管理指针的分配和释放的一套方法，就把它当做一个普通的指针看待，sp&lt;XXX&gt;就看成是XXX*就可以了 这里用MediaPlayerService来看看注册操作：void MediaPlayerService::instantiate() &#123; defaultServiceManager()-&gt;addService( String16(\"media.player\"), new MediaPlayerService()); )&#125; 看到熟悉的代码了把，这里通过ServiceManager来进行服务注册了，那么这里是如何获取到ServiceManager的？sp&lt;IServiceManager&gt; defaultServiceManager() &#123; if (gDefaultServiceManager != NULL) return gDefaultServiceManager; &#123; AutoMutex _l(gDefaultServiceManagerLock); //---&gt;锁保护 while (gDefaultServiceManager == NULL) &#123; gDefaultServiceManager = interface_cast&lt;IServiceManager&gt; ( ProcessState::self()-&gt;getContextObject(NULL)); if (gDefaultServiceManager == NULL) sleep(1); &#125; &#125; return gDefaultServiceManager;&#125; 看看ProcessState.cpp的源码：sp&lt;IBinder&gt; ProcessState::getContextObject(const sp&lt;IBinder&gt;&amp; caller) &#123; return getStrongProxyForHandle(0);&#125; 看看getStrongProxyForHandle方法实现： 这里看到了，会使用IPCThreadState的transact方法和底层的Binder进行通信的，然后使用一个句柄handle构造一个BpBinder对象，而BpBinder对象其实就是native层实现的Binder对象，以后只要看到Bp开头的就是代理对象对应Java层的Proxy对象，Bn开头的就是native对象对应Java层的Stub对象。 在上面分析servicemanager的时候知道会维护一个binder节点链表，那里其实就有一个每个binder对应句柄handle，而后续进行通信的话都是通过这个句柄来标识是哪个服务的binder对象了，这样也就在通信的时候不会发生紊乱了，而servicemanager的句柄handle就是0。还有一个知识点就是可以看到IPC通信的时候传输数据使用的就是Parcel类，这个类就是为了跨进程通信产生的，他有一个方法readStrongBinder，就是可以从Parcel的数据中获取到Binder对象，这个也是在跨进程中传递Binder对象的核心地方。public final IBinder readStrongBinder() &#123; return nativeReadStronBinder(mNativePtr);&#125; 好了，上面就通过系统的mediaserver服务来讲解了系统服务的注册流程： 到这里就分析完了Android中的远程服务调用机制逻辑以及ServiceManager这个服务大管家的作用: 1、首先跨进程通信的话，肯定会有两个对象：一个是本地端的中间者Proxy对象，一个是远程端的中间者Stub对象 2、Proxy对象通过静态代理模式维持一个远端传递过来的Binder对象，而Stub对象可以把远端传递过来的Binder对象转化成一个实际服务对象给应用使用 3、Android中在使用系统服务的时候通过getSystemService方法获取到的其实都是Stub把远端的Binder转化的对象，因为系统服务都是在system_server进程中，所以肯定是跨进程获取对象的，那么这个Binder对象其实就是上面的Proxy对象 4、系统的服务都是在一个指定的系统进程中system_server 5、服务大管家ServiceManager在系统启动的时候也是先获取自生的Binder对象，然后转化成实际操作对象，然后才可以操作系统服务的注册和查询功能 下面是系统一些服务的注册流程： 上面已经介绍了远程服务调用机制以及ServiceManager的实现原理，下面就要看看另外一个重点，也是上面提到的一个重要对象Binder，准确来说这个是Binder机制，在Android中Binder机制最复杂的一个架构系统了，它的设计很复杂，所以有很多同学在了解Binder机制的时候，总是看着看着就晕了，今天我们就直说重点，而且说得要相对明了简单。 Binder机制解析第一、Android中的IPC为何要采用Binder机制Binder是Android系统进程间通信(IPC)方式之一。Linux已经拥有的进程间通信IPC手段包括(Internet Process Connection)：管道(Pipe)、信号(Signal)和跟踪(Trace)、插口(Socket)、报文队列(Message)、共享内存(Share Memory)和信号量(Semaphore)。 Binder基于Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID,PID身份，既支持实名Binder也支持匿名Binder，安全性高。对Binder而言，Binder可以看成Server提供的实现某个特定服务的访问接入点， Client通过这个‘地址’向Server发送请求来使用该服务；对Client而言，Binder可以看成是通向Server的管道入口，要想和某个Server通信首先必须建立这个管道并获得管道入口。 第二、Android中的Binder实现原理其实Android中的Binder通信都是通过虚拟驱动设备程序/dev/binder来实现的，我们知道一些硬件都会对应一个驱动程序，而binder驱动程序没有对应的硬件，所以叫做虚拟驱动设备程序，其实他就是一个字符驱动设备，或者叫做miscdevice混杂设备驱动。 其实混杂驱动设备是字符设备的一种，它们共享一个主设备号(10)，但次设备号不同，所有的混杂设备形成一个链表，对设备访问时内核根据次设备号查找到相应的miscdevice设备。例如:触摸屏，LED，按键，串口。即：为了节约主设备号，将某些设备用链表的形式连接在一起，最后通过查找次设备区分。这里用主设备无法匹配出设备驱动，只能找到链表，再通过次设备号，才能找到设备驱动。而之前所学的，一般字符设备，通过主设备号，就能找到设备驱动了。我们可以通过命令查看/dev/binder驱动的主设备号： 第三、Android中Binder通信机制先来看一张图，我们可以大体的了解到了客户端和服务端通过Binder驱动进行通信 首先不管是客户端进程还是服务端进程都是在用户空间的，而binder驱动是在内核空间的，通信的数据是有规定格式也叫作IPC数据，既然是一种通信机制，肯定是需要协议，数据格式等基础结构信息的： 上面在分析了ServiceManager的启动的时候说到了，第一步是打开驱动程序，具体打开函数在binder.c中： 在使用一个驱动之前，肯定要先打开驱动，然后把驱动程序映射到内存中，接着借助IPCTreadState.cpp和binder驱动进行通信了： 所以看到这里IPCThreadState也是需要进入后台进行监听的，处理来自客户端和服务端的数据传输消息 最后再来看一下通信时序图。 到这里我们就介绍完了Binder机制了，关于Binder机制最好不要看太深，因为越深你觉得越复杂越难理解，其实你只要了解到他是一个通信工具，通信采用的是驱动操作，通过传输IPC数据来进行通信即可。其他的关于他的详细数据格式和通信协议，感兴趣的同学可以了解一下，但是太过复杂而且在实际中也没多大用途，所以这里就不介绍了。 技术点概要理解远程服务通信机制通过案例先了解到本地端和服务端跨进程通信，主要就是借助Binder进行功能调用，而在这里主要有两个核心类，一个是Stub类，这个类是继承了Binder类具备了将远程传递的Binder对象转化成本地实际对象asInterface方法即可，同时实现了IXXX接口，需要实现AIDL中的功能方法，还有一个类就是Proxy类，实现了IXXX接口，同时内部保留着远端传递的Binder对象，然后通过这个对象调用远端方法。这里Stub类就是服务端的中间者，而Proxy就是本地端的中间者。 系统服务调用流程通过分析了跨进程通信机制原理之后，再去看看Android系统中在使用一些服务的时候，通过getSystemService方法获取服务对象，其实这内部就是通过跨进程获取到了远端服务的Binder对象，然后转化成系统服务对象给应用调用，而这些系统服务的Binder对象在系统启动的时候服务会自动注册到ServiceManager中。 服务大管家ServiceManager在整个远程服务调用过程中两个重要对象，一个是Binder对象，一个就是ServiceManager类，这个类是管理系统服务的类，他可以注册服务，查询服务，系统服务在系统启动的时候会通过addService进行服务注册，然后应用就可以通过getService进行服务查询，而在这个过程中，底层会维护一个这些服务的binder链表结构，同时每个服务的binder对象都一个句柄handle，通过这个句柄来表示通信标识，这样通信才不会紊乱。 底层通信核心Binder最后分析了底层真正实现跨进程通信的机制Binder，其实是通过虚拟驱动程序/dev/binder进行通信的。一个通信机制肯定有通信协议，传输的数据结构，但是这里并没有介绍这些知识，原因是我们后面的需求并不会用到这些，其次是这些知识点太详细介绍也不好，因为会越看越乱。 总结本文介绍的东东有点多，但是如果掌握了Android中的Binder机制和远程服务调用机制对后面拦截系统api做了铺垫，说到结束了才告诉大家为什么要介绍这个知识点，是因为最近在研究如何拦截系统启动Activity的事，那么就必须了解Activity的启动流程，但是在这个过程中有一个对象就是ActivityManagerService，而他就和Binder以及远程服务调用机制紧密联系了，如果不了解Binder机制，后面工作是没办法进行的，好了，说到最后再来一张神图算是总结了本文内容： 这张图非常好的表达了Android中应用使用系统服务的一个流程，也是最好的最全的解释了。看懂这张图之后，那么对Android中的binder机制和远程服务调用机制就可以掌握了，可以进行后续的拦截操作了。 参考文献：Android系统篇之—-Binder机制和远程服务调用机制分析 进击的Android注入术《五》 Android深入浅出之Binder机制 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/07/10/android-binder-principle2/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AIDL","slug":"aidl","permalink":"http://agehua.github.io/tags/aidl/"},{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"}]},{"title":"Android Binder机制分析（一）","slug":"android-binder-principle","date":"2017-07-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/07/08/android-binder-principle/","link":"","permalink":"http://agehua.github.io/2017/07/08/android-binder-principle/","excerpt":"背景分析最近在学习Android非侵入Hook机制，\n6月30日，360开源RePlugin，安卓进入“全面插件化”时代：https://www.itcodemonkey.com/article/278.html\n同一天，滴滴开源Android端插件化框架VirtualAPK：https://www.itcodemonkey.com/article/277.html\n然后本人发现竟然可以不在清单文件中注册就可以启动Activity，还有这种操作？哈哈。后面会有单独的文章介绍这种骚操作。\n在搜索中发现了这篇博客，Android系统篇之—-Binder机制和远程服务调用机制分析。本文大部分转载自原来博客，结合自己的分析，是研究Hook机制前的知识储备。\nAndroid中远程服务调用分析简单介绍，跨进程调用一个远程服务需要下面这几步：","text":"背景分析最近在学习Android非侵入Hook机制， 6月30日，360开源RePlugin，安卓进入“全面插件化”时代：https://www.itcodemonkey.com/article/278.html 同一天，滴滴开源Android端插件化框架VirtualAPK：https://www.itcodemonkey.com/article/277.html 然后本人发现竟然可以不在清单文件中注册就可以启动Activity，还有这种操作？哈哈。后面会有单独的文章介绍这种骚操作。 在搜索中发现了这篇博客，Android系统篇之—-Binder机制和远程服务调用机制分析。本文大部分转载自原来博客，结合自己的分析，是研究Hook机制前的知识储备。 Android中远程服务调用分析简单介绍，跨进程调用一个远程服务需要下面这几步： 1.定义一个AIDL文件：Demo.aidl 类似于定义接口类型，这个AIDL文件将在本地和远端都要使用到 package com.agehua.aidldemo;interface Demo &#123; int sendData(String data); String getData();&#125; 2.定义远程服务在远程服务中的onBind方法，实现AIDL接口的具体方法，并且返回Binder对象//远程服务，应该定义在另个一进程中public class DemoService extends Service &#123; @Override public IBinder onBind(Intent intent) &#123; //返回远程的Binder对象，并且实现类 return new Demo.Stub() &#123; @Override public int sendData(String data) throws RemoteException &#123; return 0; &#125; @Override public String getData() throws RemoteException &#123; return \"\"; &#125; &#125; &#125;&#125; 接口方法的具体传递实现都是在远端服务中。 3.本地创建连接对象本地创建一个服务连接对象，实现ServiceConnection接口，在连接成功之后，会得到一个远端传递过来的Binder对象，就是上面的远端服务onBind方法返回的，得到Binder对象之后在进行转化就可以得到AIDL对象，然后即可调用方法。 //连接远程服务的回调public class DemoConnection implements ServiceConnection &#123; @Override public void onServiceConnected(Component name, IBinder service) &#123; //连接成功后，会传递远端的Binder对象 Demo demo =Demo.Stub.asInterface(service); try &#123; demo.setData(\" \"); demo.getData(); &#125;catch (RemoteException e) &#123; e.printStackTrace(); &#125; &#125; @Override public void onServiceDisconnected(Component name) &#123; //断开连接 &#125;&#125; 连接成功后，从远端服务中获取到了Binder对象，然后在转化成本地接口对象，即可调用方法。 4、连接服务连接服务也是比较简单的，这时候把上面的连接对象传递进去即可 Intent intent = new Intent(this, DemoService.class);bindService(intent, new DemoConnection(), Context.BIND_AUTO_CREATE); AIDL实现机制分析上面的步骤就可以实现一个远程服务调用了。但是有一个核心的地方就是Demo.Stub类，这个类起着重要的作用，下面来分析一下它的实现： 每次定义了AIDL接口文件之后，编译一下就会在build/generated/source/目录中产生对应的java文件了： package com.agehua.aidldemo;//IInterface接口由AIDL类去实现。IInterface接口包含一个方法asBinder()public interface Demo extends android.os.IInterface &#123; /** * Local-side IPC implementation stub class. * 由Stub类实现Binder类和AIDL接口 */ public static abstract class Stub extends android.os.Binder implements com.agehua.aidldemo.Demo &#123; private static final java.lang.String DESCRIPTOR = \"com.agehua.aidldemo.Demo\"; public Stub() &#123; this.attachInterface(this, DESCRIPTOR); &#125; /** * Cast an IBinder object into an com.agehua.aidldemo.Demo interface, * generating a proxy if needed. * 将远端传过来的Binder对象转化成本地对象 */ public static com.agehua.aidldemo.Demo asInterface(android.os.IBinder obj) &#123; if ((obj == null)) &#123; return null; &#125; //如果本地进程和服务端都在一个进程中，那么直接返回当前类的IInterface android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) &amp;&amp; (iin instanceof com.agehua.aidldemo.Demo))) &#123; return ((com.agehua.aidldemo.Demo) iin); &#125; //如果本地进程和服务端不在一个进程中，则返回一个代理对象给客户端 return new com.agehua.aidldemo.Demo.Stub.Proxy(obj); &#125; @Override public android.os.IBinder asBinder() &#123; return this; &#125; //处理客户端发过来的请求方法，这里不详细展开了 @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException &#123; switch (code) &#123; case INTERFACE_TRANSACTION: &#123; reply.writeString(DESCRIPTOR); return true; &#125; case TRANSACTION_sendData: &#123; data.enforceInterface(DESCRIPTOR); java.lang.String _arg0; _arg0 = data.readString(); int _result = this.sendData(_arg0); reply.writeNoException(); reply.writeInt(_result); return true; &#125; case TRANSACTION_getData: &#123; data.enforceInterface(DESCRIPTOR); java.lang.String _result = this.getData(); reply.writeNoException(); reply.writeString(_result); return true; &#125; &#125; return super.onTransact(code, data, reply, flags); &#125; //稍后分析这个类 private static class Proxy implements android.app.IServiceConnection &#123; /** ... **/ &#125; &#125; //Demo.aidl提供的方法，由Proxy类去实现，这里不用实现 public int sendData(java.lang.String data) throws android.os.RemoteException; //Demo.aidl提供的方法，由Proxy类去实现，这里不用实现 public java.lang.String getData() throws android.os.RemoteException;&#125; 1、AIDL接口必须实现IInterface接口IInterface接口包含一个asBinder()方法，由这个方法进行转化对象功能，把当前的AIDL对象转化成一个IBinder对象。package android.os;public interface IInterface&#123; /** * Retrieve the Binder object associated with this interface. * You must use this instead of a plain cast, so that proxy objects * can return the correct result. */ public IBinder asBinder();&#125; 2、AIDL接口中肯定有一个静态实现类Stub这个类必须实现Binder类，以及本身的AIDL接口类型。那么这个类就具备了Binder类中的四个功能： 1.可以将Binder对象转化成AIDL对象，调用asInterface方法，可以看到这个方法其实和上面的asBinder方法对立的 2.通信方法onTransact实现，这个方法是最核心的用于通信之间的逻辑实现 3.通过queryLocalInterface方法可以根据类的描述符(字符串可以唯一标识这个远端服务的名称即可)获取到对应的AIDL对象(其实是IInterface类型的) 4.在构造方法中必须调用Binder中的attachInterface方法把当前服务对象和描述符进行关联 3、Stub类只是中间者，由Proxy类生成服务端的代理 为什么说是由Proxy类生成服务端的代理的呢？ 因为在上面的DemoConnection类中，生成本地Demo对象，是调用了Demo.Stub.asInterface(IBinder)这个方法。前面提到，服务端和客户端不在同一个进程的时候，asInterface()方法实际上调用了Demo.Stub.Proxy(IBinder)这个方法。 而且Demo.aidl中定义的抽象方法，具体都是由Proxy类去实现的。 Stub类，其实只是远端服务Binder对象的一个中间者，下面看代码： //实现了aidl接口类。private static class Proxy implements com.agehua.aidldemo.Demo &#123; //保存了一个mRemote变量，这个变量就是由服务端传递过来的IBinder对象 private android.os.IBinder mRemote; Proxy(android.os.IBinder remote) &#123; mRemote = remote; &#125; @Override public android.os.IBinder asBinder() &#123; return mRemote; &#125; public java.lang.String getInterfaceDescriptor() &#123; return DESCRIPTOR; &#125; @Override public int sendData(java.lang.String data) throws android.os.RemoteException &#123; android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); int _result; try &#123; _data.writeInterfaceToken(DESCRIPTOR); _data.writeString(data); //调用Binder的transact()方法，会调用上面Stub类中的onTransact方法进一步处理 mRemote.transact(Stub.TRANSACTION_sendData, _data, _reply, 0); _reply.readException(); _result = _reply.readInt(); &#125; finally &#123; _reply.recycle(); _data.recycle(); &#125; return _result; &#125; @Override public java.lang.String getData() throws android.os.RemoteException &#123; android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); java.lang.String _result; try &#123; _data.writeInterfaceToken(DESCRIPTOR); //调用Binder的transact()方法，会调用上面Stub类中的onTransact方法进一步处理 mRemote.transact(Stub.TRANSACTION_getData, _data, _reply, 0); _reply.readException(); _result = _reply.readString(); &#125; finally &#123; _reply.recycle(); _data.recycle(); &#125; return _result; &#125;&#125; Proxy是Stub类中的一个静态类，Proxy对象就是远端传递过来的Binder对象在本地的代理。这里用到的是静态代理模式。 在服务连接成功后，在onServiceConnected()方法中，返回一个服务端Binder对象，本地通过asInterface()方法生成的一个代理；Demo demo = Demo.Stub.asInterface(IBinder); 这个demo对象，就是客户端这边用户和服务端交互的中间者。我们在前面的Stub类的asInterface()方法实现中可以看到： 借助queryLocalInterface()方法根据服务描述符来获取对象，会把远端传递过来的Binder对象转化成一个本地对象：public IInterface queryLocalInterface(String descriptor) &#123; if (mDescriptor.equals(descriptor)) &#123; return mOwner; &#125; return null;&#125; 而这个mOwner和mDescriptor之间的对应关系就在attachInterface方法中进行初始化的，也就是在Stub类的构造方法中public void attachInterface(IInterface owner, String descriptor) &#123; mOwner = owner; mDescriptor = descriptor;&#125; 那么现在就清楚了，如果客户端和服务端是在一个进程中，那么其实queryLocalInterface获取的就是Stub对象，如果不在一个进程queryLocalInterface查询的对象肯定为null，因为new Demo.Stub()和Demo.Stub.asInterface(IBinder)方法分别是在远端进程和本地进程中调用的，在不同进程有不同虚拟机，肯定查不到mOwner对象的，所以这时候其实是返回的Proxy对象了。 通过上面的讲解之后，发现多进程服务通信基准就是借助Binder对象，先传递Binder对象，然后在把Binder转成可以使用的原生对象即可调用了，而对于Stub类和Proxy类其实就是相当于是服务端和客户端的中间者，把一些逻辑封装起来，这种设计也会显得不是那么凌乱： 分析系统服务调用流程其实系统中的一些服务使用的时候其实也是跨进程使用，比如下面来看一下著名的PackageManager，IPackageManager，PackageManagerService体系： PackageManagerService是Android系统中最常用的服务之一。它负责系统中Package的管理，应用程序的安装、卸载、信息查询等。PackageManager获取的信息即来自AndroidManifest.XML interface IPackageManager &#123; boolean isPackageAvailable(String packageName, int userId); PackageInfo getPackageInfo(String packageName, int flags, int userId); int getPackageUid(String packageName, int userId); int[] getPackageGids(String packageName); String[] currentToCanonicalPackageNames(String[] names); String[] canonicalToCurrentPackageNames(String[] names); PermissionInfo getPermissionInfo(String name, int flags) ParceledListSlice&lt;PermissionInfo&gt; queryPermissionsByGroup(String group, int flags) //...&#125; 上面代码在谷歌的源码中查到，详情点击链接 因为我们还没有编译源码，所以看不到IPackageManager.java，这里可能需要AIDL工具单独编译才能看到了：public interface IPackageManager extends android.os.IInterface &#123; //定义内部类Stub，派生自Binder，实现IPackageManager接口 public static abstract class Stub extends android.os.Binder implements android.content.pm.IPackageManager &#123; private static final java.lang.String DESCRIPTOR = \"android.content.pm.IPackageManager\"; publicStub() &#123; this.attachInterface(this,DESCRIPTOR); &#125; //...... //定义Stub的内部类Proxy，实现IPackageManager接口 private static class Proxy implements android.content.pm.IPackageManager&#123; //通过mRemote变量和服务端交互 private android.os.IBinder mRemote; Proxy(android.os.IBinderremote) &#123; mRemote = remote; &#125; //...... &#125; //......&#125; 这里看到了熟悉的远端服务中间者Stub和本地端的中间者Proxy类了，而这两个类的规则都和上面一样的。 下面来看一下远端服务实现代码PackageManagerService.java，(这个类就可以在IDE中看到了)：public class PackageManagerService extends IPackageManager.Stub &#123; static final String TAG = \"PackageManager\"; static final boolean DEBUG_SETTINGS = false; static final boolean DEBUG_PREFERRED = false; static final boolean DEBUG_UPGRADE = false; static final boolean DEBUG_DOMAIN_VERIFICATION = false; //...&#125; 实现了上面的的Stub类功能。 下面我们再走一遍获取PackageManager的流程：PackageManager pm = getPackageManager(); 而这个getPackageManager方法是在ContextImpl.java中实现的： @Overridepublic PackageManager getPackageManager() &#123; if (mPackageManager != null) &#123; return mPackageManager; &#125; IPackageManager pm = ActivityThread.getPackageManager(); if (pm != null) &#123; // Doesn't matter if we make more than one instance. return (mPackageManager = new ApplicationPackageManager(this, pm)); &#125; return null;&#125; 具体内容实现是在ActivityThread.getPackageManager()方法中：public static IPackageManager getPackageManager() &#123; if (sPackageManager != null) &#123; //Slog.v(\"PackageManager\", \"returning cur default = \" + sPackageManager); return sPackageManager; &#125; IBinder b = ServiceManager.getService(\"package\"); //Slog.v(\"PackageManager\", \"default service binder = \" + b); sPackageManager = IPackageManager.Stub.asInterface(b); //Slog.v(\"PackageManager\", \"default service = \" + sPackageManager); return sPackageManager;&#125; 看到了吧，IPackageManager.Stub.asInterface(b)中的参数b由ServiceManager.getService方法获取到。然后在使用Stub的asInterface方法进行转化成本地的PackageManager对象，其实就是那个Proxy对象。然后就可以通过PackageManager来调用方法和远端的PackageManagerService服务进行通信了。 而DemoService是在DemoConnection（继承自ServiceConnection）的onServiceConnected回调中得到远端的IBinder对象，然后获得Proxy对象。 这里与自定义远程服务然后调用的区别就是，系统的远程服务都是由ServiceManager保存的，也就是由系统去创建和管理；而自定义的远程服务由开发者去创建、维护和销毁 通过上面的PackageManager案例可以分析，我们在使用系统中的服务的时候的流程都是如此： 总结一下，每个应用在使用系统服务的时候，都会走这么几步： 1、调用getService(String serviceName)方法获取服务对象 2、而getSystemService一般都是在ContextImpl类中实现的，其实是调用了ServiceManager的getService方法 3、调用ServiceManager的getService方法获取远端服务的IBinder对象 4、有了远端服务的IBinder对象之后，在使用远端服务的中间者类Stub进行转化对象asInterface方法 5、因为系统中的服务获取都是肯定是跨进程的，远端服务都是在system_server进程中的，所以asInterface方法中返回的是Proxy代理对象，也就是本地端的中间者。 6、最后返回的对象其实就是这个Proxy对象，而这个对象内部使用了静态代理方式，内部有一个来自远端的mRemote变量即IBinder对象。然后直接调用方法其实就是调用mRemote的transact方法进行通信了。 所以在这个过程中可以看到有两个对象很重要，一个是ServiceManager，一个是IBinder对象。下篇文章再来一一介绍 参考文献： Android系统篇之—-Binder机制和远程服务调用机制分析 《Android上玩玩Hook？》: http://blog.csdn.net/yzzst/article/details/47318751 《进击的Android注入术&lt;一&gt;》:http://blog.csdn.net/l173864930/article/details/38455951 极客学院——深入理解Android卷②：http://wiki.jikexueyuan.com/project/deep-android-v2/powermanagerservice.html 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/07/08/android-binder-principle/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AIDL","slug":"aidl","permalink":"http://agehua.github.io/tags/aidl/"},{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"}]},{"title":"Handler替代TimerTask","slug":"handler-replace-timertask","date":"2017-05-17T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/05/18/handler-replace-timertask/","link":"","permalink":"http://agehua.github.io/2017/05/18/handler-replace-timertask/","excerpt":"Handler替代TimerTask原文来自：http://www.mopri.de/2010/timertask-bad-do-it-the-android-way-use-a-handler/\n作者文中提到，使用TimerTask更新GUI，debug看起来可以，但实际上根本不起作用。同时作者发现，使用handler可以得到更好的表现。\n下面是一个例子，使用handler在100ms后启动一个Runnable:private Handler handler = new Handler();handler.postDelayed(runnable, 100);\n下面代码里有一个小技巧，实现每隔100ms运行一次Runnable，就像TimerTask的scheduleAtFixedRate()方法:","text":"Handler替代TimerTask原文来自：http://www.mopri.de/2010/timertask-bad-do-it-the-android-way-use-a-handler/ 作者文中提到，使用TimerTask更新GUI，debug看起来可以，但实际上根本不起作用。同时作者发现，使用handler可以得到更好的表现。 下面是一个例子，使用handler在100ms后启动一个Runnable:private Handler handler = new Handler();handler.postDelayed(runnable, 100); 下面代码里有一个小技巧，实现每隔100ms运行一次Runnable，就像TimerTask的scheduleAtFixedRate()方法: private Runnable runnable = new Runnable() &#123; @Override public void run() &#123; /* do what you need to do */ foobar(); /* and here comes the \"trick\" */ handler.postDelayed(this, 100); &#125;&#125;; 如何取消运行Runnable呢？只需要调用handler.removeCallback(runnable)就可以了。 这样做还有另一个有点，就是不用总是new Timer(Task)了，可以重复使用上面代码中的handler和runnable。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/05/18/handler-replace-timertask/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"TimerTask","slug":"timertask","permalink":"http://agehua.github.io/tags/timertask/"},{"name":"handler","slug":"handler","permalink":"http://agehua.github.io/tags/handler/"}]},{"title":"Android架构师积累","slug":"Object-Oriented","date":"2017-05-10T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/05/11/Object-Oriented/","link":"","permalink":"http://agehua.github.io/2017/05/11/Object-Oriented/","excerpt":"Android架构师积累 ——By 高焕堂“-Oriented”的涵意◎ ”-Oriented”意味着一种信仰 。◎ ”Object-oriented”相信任何软件都是由对象所构成的，而且Nothing else 。\n”-Driven”的涵意; 例如:Model-driven、Use Case-driven– 其实”-driven”是”引导”，而不是大家常说的”驱动”。– 就向北极星引导我们，指出方向而已。也像汽车司机(Driver)只是引导汽车方向，并没有去驱动汽车;而是引擎才是驱动汽车。\n“-Centered”的涵意; 例如:Architecture-centered、 Architecture-centeric–一切软件开发的活动都围绕着架构，就像盛诞节的糖果和礼物都挂在圣诞树上一样。\n卡榫函数• 所谓「卡榫(Hook)」，就是用来接合两个东西的接口。如果两个东西于不同时间出现，则一方会预留虚空，给予另一边于未来时刻能以实体来填补该空间，两者虚实相依，就密合起来了。设计优良的卡榫，可以让实体易于新陈代谢、抽换自如(Plug and Play, 俗称PnP)。","text":"Android架构师积累 ——By 高焕堂“-Oriented”的涵意◎ ”-Oriented”意味着一种信仰 。◎ ”Object-oriented”相信任何软件都是由对象所构成的，而且Nothing else 。 ”-Driven”的涵意; 例如:Model-driven、Use Case-driven– 其实”-driven”是”引导”，而不是大家常说的”驱动”。– 就向北极星引导我们，指出方向而已。也像汽车司机(Driver)只是引导汽车方向，并没有去驱动汽车;而是引擎才是驱动汽车。 “-Centered”的涵意; 例如:Architecture-centered、 Architecture-centeric–一切软件开发的活动都围绕着架构，就像盛诞节的糖果和礼物都挂在圣诞树上一样。 卡榫函数• 所谓「卡榫(Hook)」，就是用来接合两个东西的接口。如果两个东西于不同时间出现，则一方会预留虚空，给予另一边于未来时刻能以实体来填补该空间，两者虚实相依，就密合起来了。设计优良的卡榫，可以让实体易于新陈代谢、抽换自如(Plug and Play, 俗称PnP)。 • 变与不变的分离(Separate code that changes from the code that doesn’t)是设计卡榫(Hook)函数及应用框架之基本原则和手艺。• 分离出变(Variant)与不变(Invariant)部份之后，就可以将不变部份写在父类别(Super- class)里，而变的部份就写在子类别 (Subclass)里。 在Java里，使用抽象(abstract)函数或可覆写(overridable)函数来实现卡榫函数。 IoC机制与Default函数卡榫函数实现IoC机制• 控制反转(IoC: Inversion of Control)• IoC机制源自于OO语言(如C++等)的类别 继承体系，例如C++语言中，基类的函数可以主动调用子类的函数，这就是典型的IoC机制• 基类与子类之间，主控权是在基类手上， 透过Hook函数来调用子类• 通常基类是撰写在先，而子类则撰写在后， 这种前辈拥有主导权，进而「控制」后辈 之情形，就通称为「控制反转」。 默认(Default)行为• 基类的重要功能:提供默认(预设)行为• 基类可事先定义许多「默认」(Default)函数。这些默认函数可让子类来继承(或调用)之。 interface IShape &#123; void template_paint(Graphics gr);&#125; // 一般接口 // Shape.javaimport java.awt.*;public abstract class Shape implements IShape &#123; public void template_paint(Graphics gr)&#123; //默认行为 invariant_paint(gr); //画背景 hook_paint(gr); //画前景 &#125; private void invariant_paint(Graphics gr)&#123; gr.setColor(Color.black); gr.fillRect(10,30, 200,100); &#125; abstract protected void hook_paint(Graphics gr);&#125; // Bird.javaimport java.awt.*;public class Bird extends Shape &#123; private void hook_paint(Graphics gr)&#123; //控制反转 gr.setColor(Color.cyan); gr.drawArc(30,80,90,110,40,100); gr.drawArc(88,93,90,100,40,80); gr.setColor(Color.white); gr.drawArc(30,55,90,150,35,75); gr.drawArc(90,80,90,90,40,80); &#125;&#125; 在Android中，子类Activity继承父类Activity，需要重写onCreate()方法，onCreate()方法就是基类主动调用，这也是IOC机制 认识EIT造形 有了架构设计造形的&lt;简单性&gt;，人们就很容易理解软件的复杂关系，进而提升了掌握软件系统复杂多变的能力，唯有熟谙此道，才能创造架构和产品的&lt;未来性&gt;。 高焕堂老师提出简单的EIT软件造形；则让人们能理解Android多层框架体系里的复杂关系 EIT造形是一种基本的结构(Structure)，一种概念(Concept)；我们称它为”EIT造形(Form)”。 强龙做&lt;E&amp;I&gt;，将&lt;T&gt;外包给地头蛇。 强龙掌控&lt;E&amp;I&gt;，外包就不会失控。 所以EIT造形支持当今主流的外包模式。 题目演练：由提供一个值N，由&lt;T&gt;通过不同的算法，如1+2+3+ … + N或1+2^2+ … + N^2进行计算，最后将计算结果传递给&lt;E&gt;。 现在可以试试先想想接口&lt;I&gt;设计:1.&lt;T&gt;必须有个抽象函数，被&lt;T&gt;反向调用(IoC)到&lt;T&gt;。在调用该函数时，顺便把&lt;E&gt;里的N值传递下去给&lt;T&gt;。2.由&lt;T&gt;进行计算工作，然后将计算结果传回给&lt;E&gt;。3.不同的算法就对应不同的&lt;T&gt;类 代码实现如下：//Counter.java，这就对应接口&lt;I&gt;public abstract class Counter &#123; public int run()&#123; int N = getCount(); return onCal(N); &#125; public int getCount() &#123; return 6; &#125; protected abstract int onCal(int n);&#125; //myCounter.java，是&lt;T&gt;类的一种算法public class myCounter extends Counter&#123; @Override protected int onCal(int n) &#123; int sum = 0; for(int i=1; i&lt;=n; i++) &#123; sum += i; &#125; return sum; &#125;&#125; //在&lt;E&gt;类中，调用方式如下counter = new myCounter();int sum = counter.run(); 框架(或架构)设计的关键任务就是接口(Interface)设计，这项接口是框架&lt;E&gt;与插件&lt;T&gt;之间的接口，这就是所谓的：框架API。 IPCIPC(Inter-Process Communication)通信， 是跨越两个不同进程(Process)之通信 IPC通信的效率 当我们启动某一支应用程序(App)时， Android系统里的Zygote服务孵化(Fork)一个新进程(Process)给它，然后将它(该App)加载到这个新诞生的进程里。 基于Linux的安全限制，以及进程的基本特性(例如，不同进程的地址空间是独立的)，如果两个类(或其对象)在同一个进程里执行时，两者沟通方便也快速 。 但是，当它们分别在不同的进程里执行时，两者沟通就属于IPC跨进程沟通了，不如前者方便，也慢些 一个进程是一个独立的执行空间，不会被正在其它进程里的程序所侵犯。这种保护方法是Android的重要安全机制。于是，得先认识进程的内涵，才能进一步了解跨进 程IPC机制。 在Android的进程里，有一个虚拟机(Virtual Machine，简称VM)的对象，可执行Java代码，也引导JNI本地程序的执行，实现Java与C/C++之间的沟通。如下图: 不同进程的地址空间是独立的 每一个进程在诞生时，都会诞生一个主线程(Main Thread)，以及诞生一个Looper类的对象和一个MQ(Message Queue)数据结构。每当主线程作完事情，就会去执行Looper类。 主线程最主要的工作就是处理UI画面的事件(Event)，每当UI事件发生时，Android框架会丢信息(Message)到MQ里。主线程看到MQ有新的信息时，就取出信息，然后依据信息内容而去执行特定的函数。执行完毕，就再继续执行Looper类，不断地观察MQ的动态。 IPC的IBinder接口 – 定义与实现大家都知道，当两个类都在同一个进程里执行时，两者之间的沟通，只要采取一般的函数调用(Function Call)就行了，既快速又方便。一旦两个类分别在不同的进程里执行时，两者之间的沟通，就不能采取一般的函数调用途径了。只好采取IPC沟通途径。 Android框架的IPC沟通仰赖单一的IBinder接口。此时Client端调用IBinder接口的transact()函数，透过IPC机制而调用到远方(Remote)的onTransact()函数。 Java层的IBinder 接口是定义于IBinder.java代码文档里// IBinder.java// .......public interface IBinder &#123;// ........public boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException; // ...........&#125; IBinder接口定义了一些函数，可以让Client程序可以进行跨进程的调用(当然也能支持同进程的短程调用)。其中，最主要的一个函数就是: transact()函数 在Android的框架里，由Binder基类实现IBinder接口。 Binder基类的很重要目的是支持跨进程调 用Service，也就是让远程的Client可以跨 进程调用某个Service。Binder基类定义于Binder.java文件里:// Binder.java// .......public class Binder implements IBinder &#123; // .......... private int mObject; public Binder() &#123; init(); // ........... &#125; //用来实现IBinder的transact()函数接口 public final boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException &#123; // ................ boolean r = onTransact(code, data, reply, flags); return r; &#125; //其角色与transact()函数是相同的，只是这是用来让C/C++本地程序来调用的。 private boolean execTransact(int code, int dataObj, int replyObj, int flags) &#123; Parcel data = Parcel.obtain(dataObj); Parcel reply = Parcel.obtain(replyObj); boolean res; res = onTransact(code, data, reply, flags); // ............ return res; &#125; //这是一个抽象函数，让应用子类来覆写(Override)的. //上述的transact()和 execTransact()两者都是调用onTransact()函数来实现反向调用(IoC, Inversion of Control)的。 protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException &#123; &#125; //这是一个本地(Native)函数，让JNI模块来实现这个函数. //Binder()构造函数会调用这个init()本地函数 private native final void init();&#125; Binder就是EIT造形里的&lt;E&gt; 这个IBinder接口是Binder(即&lt;E&gt;)提供给Client的接口，简称为&lt;CI&gt; onTransact()就是EIT造形里的&lt;I&gt;，是支持&lt;基类/子类&gt;之间IoC调用的接口 示例：有一个Activity类别，它想跨进程去调用MediaPlayer播放引擎，以便播放MP3音乐. 类结构图如下： 在上图里，从myActivity到IBinder接口，画上了虚线箭头，表示那是抽象概念的。实际上，myActivity并没有直接调用Java层的IBinder接口，而是绕到底层C/C++和Binder驱动而间接调用到Binder基类的execTransact()函数，转而调用myBinder的onTransact()函数。如下图: IPC通信的三步骤还是用上面的MediaPlayer例子，其IPC通信的三个步骤是: Step-1. Activity使用startService()函數來启动Service。 Step-2. Activity调用bindService()来绑定Service。亦即，Activity建立与Service之间的连结(Connection)。 Step-3. Activity调用IBinder接口的transact() 函数，透过底层Binder Driver驱动而间接调用到Binder基类的execTransact()函数， 转而调用 myBinder的onTransact()函数。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/05/11/Object-Oriented/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Framework","slug":"android-framework","permalink":"http://agehua.github.io/tags/android-framework/"},{"name":"EIT","slug":"eit","permalink":"http://agehua.github.io/tags/eit/"},{"name":"Object-oriented","slug":"object-oriented","permalink":"http://agehua.github.io/tags/object-oriented/"}]},{"title":"注解在Android中的应用","slug":"Annotation-Android-usage","date":"2017-04-09T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/04/10/Annotation-Android-usage/","link":"","permalink":"http://agehua.github.io/2017/04/10/Annotation-Android-usage/","excerpt":"注解是Java语言的特性之一，它是在源代码中插入标签，这些标签在后面的编译或者运行过程中起到某种作用，每个注解都必须通过注解接口 @Interface 进行声明，接口的方法对应着注解的元素。\n在上一篇文章JSR-330和assertion(断言)介绍中介绍了Java中的JSR-330 规范，这个规范就是使用注解的方式。\n这篇文章主要介绍注解在Android中的应用。\nAndorid中的应用JSR-330规范只发布了规范 API 源码，主要是面向依赖注入使用者，而对注入器实现、配置并未作详细要求。该规范主要配合依赖注入框架来使用。在Android中的依赖注入框架有 ButterKnife 和 Dagger2。下面简单分析 ButterKnife 的应用。","text":"注解是Java语言的特性之一，它是在源代码中插入标签，这些标签在后面的编译或者运行过程中起到某种作用，每个注解都必须通过注解接口 @Interface 进行声明，接口的方法对应着注解的元素。 在上一篇文章JSR-330和assertion(断言)介绍中介绍了Java中的JSR-330 规范，这个规范就是使用注解的方式。 这篇文章主要介绍注解在Android中的应用。 Andorid中的应用JSR-330规范只发布了规范 API 源码，主要是面向依赖注入使用者，而对注入器实现、配置并未作详细要求。该规范主要配合依赖注入框架来使用。在Android中的依赖注入框架有 ButterKnife 和 Dagger2。下面简单分析 ButterKnife 的应用。 关于依赖注入框架的好处，我理解 1.可以减少样板类代码，比如 Setter 方法。2.程序运行期间，可以将某种依赖关系动态注入到对象中，实现懒加载（需要的时候才会去加载）。 ButterKnifeButterKnife从严格意义上讲不算是依赖注入框架，它只是专注于Android 系统的VIew注入框架，并不支持其他方面的注入。它可以减少大量 findViewById 以及 setOnClickListener 代码。 ButterKnife用到了编译时注解，因为它需要依赖 android-apt 插件//project 的 build.gradle dependencies &#123; ... classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'&#125;//Module:app 的 build.gradledependencies &#123; ... compile 'com.jakewharton:butterknife:8.4.0' apt 'com.jakewharton:butterknife-compiler:8.4.0'&#125; 关于 android-apt 插件后面会介绍。 ButterKnife提供的注解有： 绑定控件：@BindView 绑定资源：@BindString、@BindArray、@BindBool、@BindColor、@BindDimen、@BindDrawable、@BindBitmap。 绑定监听：@OnClick、@OnLongClick、@OnTextChanged、@OnTouch 可选绑定：@Nullable @Nullable用于@BindView或其他的注解操作符，如果找不到目标时，避免引发异常，例如：@Nullable@BindView(R.id.tv_title)TextView tvTitle; ButterKnife原理解析前面提到ButterKnife使用的是编译时注解，先看看最常用的@BindView注解的源码： @Retention (RetentionPolicy.Class)@Target (ElementType.FIELD)public @interface BindView &#123; int value();&#125; @interface 声明会创建一个实际的Java接口，与其他任何接口一样，注解也会编译成.class文件。@Retention 和@Target 下面会介绍到。 关于ButterKnife更多源码分析，请看这篇文：butterknife 源码分析 Java注解的分类Java API中默认定义的注解叫做标准注解。它们定义在java.lang、java.lang.annotation和javax.annotation包中。按照使用场景不同，可以分为如下三类： 编译相关注解编译相关的注解是给编译器使用的，有以下几种： @Override：编译器检查被注解的方法是否真的重载了一个来自父类的方法，如果没有，编译器会给出错误提示。 @Deprecated：可以用来修饰任何不再鼓励使用或已被弃用的属性、方法等。 @SuppressWarnings：可用于除了包之外的其他声明项中，用来抑制某种类型的警告。 @SafeVarargs：用于方法和构造函数，用来断言不定长参数可以安全使用 @Generated：一般是给代码生成工具使用，用来表示这段代码不是开发者手动编写的，而是工具生成的。被@Generated修饰的代码一般不建议手动修改它。 @FunctionalInterface：用来修饰接口，表示对应得接口是带单个方法的函数式接口 资源相关注解一共有四个，一帮用在JavaEE领域，Android开发中应该不会用到，就不在详细介绍\b了。分别是： @PostConstruct @PreDestroy @Resource @Resources 元注解Butterknife的Bind注解用到的就是元注解。 元注解，顾名思义，就是用来定义和实现注解的注解，总共有如下五种： @Retention, 用来指明注解的访问范围，也就是在什么级别保留注解，有三种选择： 源码级注解：使用@Retention(RetentionPolicy.SOURCE)修饰的注解，该类型修饰的注解信息只会保留在 .java源码里，源码经过编译后，注解信息会被丢弃，不会保留在编译好的 .class文件中。 编译时注解：使用@Retention(RetentionPolicy.CLASS)修饰的注解，该类型的注解信息会保留在 .java源码里和 .class文件里，在执行的时候会被Java虚拟机丢弃，不会加载到虚拟机中。 运行时注解：使用@Retention(RetentionPolicy.RUNTIME)修饰的注解，Java虚拟机在运行期间也保留注解信息，可以通过反射机制读取注解的信息未指定类型时，默认是CLASS类型。 @Target, 这个注解的取值是一个ElementType类型的数组，用来指定注解所使用的对象范围，共有十种不同的类型，如下表所示，同时支持多种类型共存，可以进行灵活的组合。 元素类型 适用于 ANNOTATION_TYPE 注解类型声明 CONSTRUCTOR 构造函数 FIELD 实例变量 LOCAL_VARIABLE 局部变量 METHOD 方法 PACKAGE 包 PARAMETER 方法参数或者构造函数的参数 TYPE 类（包含enum）和接口（包含注解类型） TYPE_PARAMETER 类型参数 TYPE_USE 类型的用途 如果一个注解的定义没有使用@Target修饰，那么它可以用在除了TYPE_USE和TYPE_PARAMETER之外的其他类型声明中 @Inherited, 表示该注解可以被子类继承的。 @Documented, 表示被修饰的注解应该被包含在被注解项的文档中（例如用JavaDoc生成的文档） @Repeatable, 表示这个注解可以在同一个项上面应用多次。不过这个注解是在Java 8中才引入的，前面四个元注解都是在Java 5中就已经引入。 运行时注解前面说过，要定义运行时注解只需要在声明注解时指定 @Retention(RetentionPolicy.RUNTIME)即可，运行时注解一般和反射机制配合使用。 熟悉java反射机制的同学一定对java.lang.reflect包非常熟悉，该包中的所有api都支持读取运行时Annotation的能力。相比编译时注解性能比较低，但灵活性好，实现起来比较简单。 Butterknife在较低版本依然是通过运行时反射实现View的注入，性能较低下，不过在8.0.0版本以后使用编译时注解来提升性能。 运行时注解的简单使用下面展示一个Demo。其功能是通过注解实现布局文件的设置。 之前我们是这样设置布局文件的： @Overrideprotected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); setContentView(R.layout.activity_home);&#125; 如果使用注解，我们就可以这样设置布局了 @ContentView(R.layout.activity_home)public class HomeActivity extends BaseActivity &#123; ...&#125; 我们先不讲这两种方式哪个好哪个坏，我们只谈技术不谈需求。 那么这样的注解是怎么实现的呢？很简单，往下看。 创建一个注解@Retention(RetentionPolicy.RUNTIME)@Target(&#123;ElementType.TYPE&#125;)public @interface ContentView &#123; int value();&#125; 前面已经讲过元注解，这不不再介绍。 对于：public @interface ContentView 这里的interface并不是说ContentView是一个接口。就像申明类用关键字class。申明枚举用enum。申明注解用的就是@interface。 （值得注意的是：在ElementType的分类中，class、interface、Annotation、enum同属一类为ElementType.Type，并且从官方注解来看，interface是包含@interface的） /** Class, interface (including annotation type), or enum declaration */TYPE, 对于：int value(); 返回值表示这个注解里可以存放什么类型值。比如我们是这样使用的@ContentView(R.layout.activity_home) R.layout.activity_home 实质是一个int型id，如果这样用就会报错： @ContentView(“string”) 关于注解的具体语法，可以看这篇文章Android编译时注解框架-语法讲解 注解解析注解申明好了，但具体是怎么识别这个注解并使用的呢？@ContentView(R.layout.activity_home)public class HomeActivity extends BaseActivity &#123; ...&#125; 注解的解析就在BaseActivity中。我们看一下BaseActivity代码public class BaseActivity extends AppCompatActivity &#123; @Override protected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); //注解解析 for (Class c = this.getClass(); c != Context.class; c = c.getSuperclass()) &#123; ContentView annotation = (ContentView) c.getAnnotation(ContentView.class); if (annotation != null) &#123; try &#123; this.setContentView(annotation.value()); &#125; catch (RuntimeException e) &#123; e.printStackTrace(); &#125; return; &#125; &#125;&#125; 解释下上面的代码： 第一步：遍历所有的子类 第二步：找到修饰了注解ContentView的类 第三步：获取ContentView的属性值。 第四步：为Activity设置布局。 总结：要定义运行时注解，只需要在声明注解时指定@Retention(RetentionPolicy.RUNTIME)即可，运行时注解一般和反射机制配合使用，相比编译时注解性能比较低，但实现比较简单，会提高一定的开发效率。 编译时注解编译时注解能够自动处理Java源文件并生成更多的源码、配置文件、脚本或其他可能想要生成的东西。这些操作是通过注解处理器（Annotation Processor Tool）完成的。Java通过在编译期间调用 javac -processor命令可以调起注解处理器，它能够实现编译时注解的功能。 注解处理器其实是在javac开始编译之前，以java源码文件或编译后的class文件作为输入，然后输出另一些文件，可以是.java文件，也可以是.class文件，但通常我们输出的是.java文件，这些.java文件回合其他源码文件一起被javac编译，从而提高函数库的性能。 定义注解处理器自定义编译时注解后，需要编写Processor类实现注解处理器，处理自定义注解。Processor继承自AbstractProcessor类并实现process方法，同时需要指定注解处理器能够处理的注解类型以及支持的Java版本，语句如下： public class JsonAnnotationProcessor extends AbstractProcessor &#123; @Override public synchronized void init(ProcessingEnvironment env)&#123; super.init(env); //初始化方法，会被注解处理工具调用，并传入ProcessingEnvironment类型参数， //这个参数包含了很多工具类，如Elements、Types、Filer等 elementUtils = env.getElementUtils(); typeUtils = env.getTypeUtils(); filer = env.getFiler(); &#125; @Override public Set&lt;String&gt; getSupportedAnnotationTypes() &#123; //指定这个注解处理器能够处理的注解类型，返回一个支持的类型字符串合集 return super.getSupportedAnnotationTypes(); &#125; @Override public SourceVersion getSupportedSourceVersion() &#123; //指定注解处理器使用的Java版本 return SourceVersion.latestSupported(); &#125; @Override public boolean process(Set&lt;? extends TypeElement&gt; annotations, RoundEnvironment roundEnv) &#123; //在这个方法中实现注解处理器的具体业务逻辑，根据输入参数roundEnv可以得到包含特定注解的被注解元素 //下面代码是Butterknife中这个方法的源码 Map&lt;TypeElement, BindingClass&gt; targetClassMap = findAndParseTargets(env); for (Map.Entry&lt;TypeElement, BindingClass&gt; entry : targetClassMap.entrySet()) &#123; TypeElement typeElement = entry.getKey(); BindingClass bindingClass = entry.getValue(); try &#123; JavaFileObject jfo = filer.createSourceFile(bindingClass.getFqcn(), typeElement); Writer writer = jfo.openWriter(); writer.write(bindingClass.brewJava()); writer.flush(); writer.close(); &#125; catch (IOException e) &#123; error(typeElement, \"Unable to write view binder for type %s: %s\", typeElement, e.getMessage()); &#125; &#125; //返回值 表示这组 annotations 是否被这个 Processor 接受， //如果接受（true）后续子的 pocessor 不会再对这个 Annotations 进行处理 return true; &#125; //Butterknife源码：RoundEnvironment表示当前或是之前的运行环境，可以通过该对象查找找到相应的注解。 private Map&lt;TypeElement, BindingClass&gt; findAndParseTargets(RoundEnvironment env) &#123; Map&lt;TypeElement, BindingClass&gt; targetClassMap = new LinkedHashMap&lt;TypeElement, BindingClass&gt;(); Set&lt;String&gt; erasedTargetNames = new LinkedHashSet&lt;String&gt;(); // Process each @Bind element. for (Element element : env.getElementsAnnotatedWith(Bind.class)) &#123; //所有被使用的@Bind注解 try &#123; parseBind(element, targetClassMap, erasedTargetNames); &#125; catch (Exception e) &#123; logParsingError(element, Bind.class, e); &#125; &#125; ...... &#125; &#125; 一个注解处理器，只能产生新的源文件，它不能够修改一个已经存在的源文件。当没有属于该Process处理的注解被使用时，process不会执行。 从Java7 开始，我们也可以使用注解来代替上面的getSupportedAnnotationTypes()和getSupportedSourceVersion()方法，代码如下：@SupportedAnnotationTypes(&#123; //该注解处理器支持的所有注解全名&#125;)@SupportedSourceVersion(SourceVersion.RELEASE_7)public class ContentViewProcessor extends AbstractProcessor &#123; ...&#125; Element类型所有通过注解取得元素都将以Element类型等待处理，也可以理解为Element的子类类型与自定义注解时用到的@Target是有对应关系的。 Element的官方注释：Represents a program element such as a package, class, or method.Each element represents a static, language-level construct (and not, for example, a runtime construct of the virtual machine). 表示一个程序元素，比如包、类或者方法。 Element的子类有： ExecutableElement表示某个类或接口的方法、构造方法或初始化程序（静态或实例），包括注释类型元素。对应@Target(ElementType.METHOD) @Target(ElementType.CONSTRUCTOR) PackageElement表示一个包程序元素。提供对有关包极其成员的信息访问。对应@Target(ElementType.PACKAGE) TypeElement表示一个类或接口程序元素。提供对有关类型极其成员的信息访问。对应@Target(ElementType.TYPE) 注意：枚举类型是一种类，而注解类型是一种接口。 TypeParameterElement表示一般类、接口、方法或构造方法元素的类型参数。对应@Target(ElementType.PARAMETER) VariableElement表示一个字段、enum常量、方法或构造方法参数、局部变量或异常参数。对应@Target(ElementType.LOCAL_VARIABLE) Processor输出日志虽然是编译时执行Processor,但也是可以输入日志信息用于调试的。Processor日志输出的位置在编译器下方的Messages窗口中。Processor支持最基础的System.out方法。 同样Processor也有自己的Log输出工具: Messager。//同样是Butterknife源码private void error(Element element, String message, Object... args) &#123; if (args.length &gt; 0) &#123; message = String.format(message, args); &#125; processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR, message, element);&#125; 注册注解处理器为了让javac -processor能够对定义好的注解处理进行处理，我们需要将注解处理器打包到一个jar文件中，同时，需要在jar文件中增加一个名为javax.annotation.processing.processor的文件来指明jar文件中有哪些注解处理器，这个文件最终目录在jar文件根目录的META-INF/service目录中，jar文件解压后的目录结构如下图： javax.annotation.processing.Processor文件的内容是注解处理器全路径名，如果存在多个注解处理器，以换行进行分隔，代码看图片 源文件的目录是，我们需要在src/main/java同级目录中新建一个名为resources的目录，将META-INF/services/javax.annotation.processing.Processor文件放进去就行 注意，注解处理器所在的Android Studio工程必须是Java Library类型，而不应该是Android Library类型。因为Android Library的JDK中不包含某些javax包里面的类。 手动实现上面注册过程很繁琐，因此Google开源了一个名为AutoService的函数库，使用这个库后，只需在自定义Processor时使用@AutoService注解标记即可完成上面注册步骤。 @AutoService(Processor.class)@SupportedAnnotationTypes(&#123; //该注解处理器支持的所有注解全名&#125;)@SupportedSourceVersion(SourceVersion.RELEASE_7)public class ContentViewProcessor extends AbstractProcessor &#123; ...&#125; android-apt插件注解处理器所在的jar文件只能在编译期间起作用，到应用运行时不会用到，因此，在build.gradle中引入依赖时应该以provided方式，而不是compile方式引入。 当然，我们可以使用android-apt插件的方式。 android-apt是由一位开发者自己开发的apt框架，源代码托管在这里，随着Android Gradle 插件 2.2 版本的发布，Android Gradle 插件提供了名为 annotationProcessor 的功能来完全代替 android-apt ，自此android-apt 作者在官网发表声明最新的Android Gradle插件现在已经支持annotationProcessor，并警告和或阻止android-apt ，并推荐大家使用 Android 官方插件annotationProcessor。 但是很多项目目前还是使用android-apt，如果想替换为annotationProcessor，那就要知道android-apt是如何使用的。 它的作用主要如下： 只在编译期间引入注解处理器所在的函数库作为依赖，不会打包到最终生成的APK中。 为注解处理器生成的源码设置好正确的路径，以便Android Studio能够正常找到，避免报错。 Project项目中使用android-apt插件 1.使用该插件，添加如下到你的构建脚本中： //配置在Project下的build.gradle中buildscript &#123; repositories &#123; mavenCentral() &#125; dependencies &#123; ... //替换成最新android-apt版本 classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8' &#125;&#125;apply plugin: 'com.neenbedankt.android-apt' 2.接着以apt的方式引入注解处理器函数库作为依赖 dependencies &#123; apt'com.bluelinelabs:logansquare-compiler:1.3.6' compile 'com.bluelinelabs:logansquare:1.3.6'&#125; LoganSquare是一个实现了编译时注解以提高性能的JSON解析函数库。 通常在使用的时候，项目依赖可能分为多个部分。上面的compiler库就有两个组件loganSquare-compiler和loganSquare。loganSquare-commpiler仅用于编译时，是loganSquare的注解处理器，运行时必需使用loganSquare。 基本使用就是上面这两点，想用annotationProcessor替代android-apt。删除和替换相应部分即可 Provided 和apt/annotationProcessor区别provided vs apt使用注解处理器的不同？ provided 将会导入注解处理器的classes和它的依赖到IDE的类路径下。这意味着你可以附带的引入并使用这些classes。例如，当注解处理器使用Guava，你可能错误的import其相关代码到你的Android 代码中。当运行时将导致crash。 provided也可以用在重复引用的库上，避免依赖重复的资源。 使用apt，注解处理器的classes将不会添加到你当前的类路径下，仅仅用于注解处理过程。并且会把所有注解处理器生成的source放在IDE的类路径下，方便Android Studio引用。 具体可以参考：深入理解编译注解（三）依赖关系 apt/annotationProcessor与Provided的区别 APT处理annotation的流程越来越多第三方库使用apt技术，如DBflow、Dagger2、ButterKnife、ActivityRouter、AptPreferences。在编译时根据Annotation生成了相关的代码，非常高大上但是也非常简单的技术，可以给开发带来了很大的便利。 注解处理器（AbstractProcess）+代码处理（javaPoet）+处理器注册（AutoService）+apt 具体流程： 1.定义注解（如@inject） 2.定义注解处理器 3.在处理器里面完成处理方式，通常是生成Java代码。 4.注册处理器 5.利用APT完成如下图的工作内容。 annotationProcessor介绍annotationProcessor是APT工具中的一种，他是google开发的内置框架，不需要引入，可以直接在build.gradle文件中使用，ButterKnife就是使用annotationProcessor处理注解，如下： dependencies &#123; annotationProcessor project(':xx') annotationProcessor 'com.jakewharton:butterknife-compiler:8.5.1'&#125; apt vs annotationProcessor两者有何不同？ android-apt是由一位开发者自己开发的apt框架，源代码托管在这里，随着Android Gradle 插件 2.2 版本的发布，Android Gradle 插件提供了名为 annotationProcessor 的功能来完全代替 android-apt ，自此android-apt 作者在官网发表声明最新的Android Gradle插件现在已经支持annotationProcessor，并警告和或阻止android-apt ，并推荐大家使用 Android 官方插件annotationProcessor。 最近Android N的发布，android 迎来了Java 8，要想使用Java 8的话必须使用Jack编译，android-apt只支持javac编译而annotationProcessor既支持javac同时也支持jack编译。 想用annotationProcessor替代android-apt。删除和替换相应部分即可，具体可以参考这篇文章 文章参考： Android 打造编译时注解解析框架 这只是一个开始Android APT（编译时代码生成）最佳实践Android编译时注解框架系列1-什么是编译时注解你必须知道的APT、annotationProcessor、android-apt、Provided、自定义注解《Android高级进阶》一书——注解在Android中的应用 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/04/10/Annotation-Android-usage/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Annotation","slug":"annotation","permalink":"http://agehua.github.io/tags/annotation/"}]},{"title":"linux(centos) 搭建SVN服务器","slug":"SVN-server-linux","date":"2017-03-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/03/20/SVN-server-linux/","link":"","permalink":"http://agehua.github.io/2017/03/20/SVN-server-linux/","excerpt":"linux(centos) 搭建SVN服务器安装步骤如下：\n第一步：安装SVNyum install subversion\n第二步：创建SVN版本库目录mkdir -p /var/svn/svnrepos\n第三步：创建版本库","text":"linux(centos) 搭建SVN服务器安装步骤如下： 第一步：安装SVNyum install subversion 第二步：创建SVN版本库目录mkdir -p /var/svn/svnrepos 第三步：创建版本库 svnadmin create /var/svn/svnrepos 第四步：进入conf目录（该SVN版本库配置文件）authz文件是权限控制文件passwd是帐号密码文件svnserve.confSVN服务配置文件 第五步：修改svnserve.conf文件vi svnserve.conf打开下面的几个注释： anon-access = read #匿名用户可读auth-access = write #授权用户可写password-db = passwd #使用哪个文件作为账号文件authz-db = authz #使用哪个文件作为权限文件realm = /var/svn/svnrepos # 认证空间名，版本库所在目录 svnserve.conf、passwd、authz文件中各配置项前不要有空格 第六步：设置帐号密码vi passwd 在[users]块中添加用户和密码，格式：帐号=密码，如binjoo = 123456。 [users]binjoo = 123456 第七步：设置权限vi authz 在末尾添加如下代码： [groups][/]binjoo=rw 意思是版本库的根目录binjoo对其有读写权限。 第八步：启动svn版本库svnserve -d -r /var/svn/svnrepos 链接方式svn://127.0.0.1 遇到问题在客户端试图 svn merge 总是报svn: E220001: 遇到不可读的路径；拒绝访问。这个错误 提示 : SVN 遇到不可读的路径；拒绝访问。 英文是: Unreadable path encountered; access denied; 既然看不到日志又无法merge等操作. GOOGLE了一下，下面的方法解决了问题。 后面才发现是配置问题. 在项目的conf/svnserve.conf 中, 设置 anon-access = none 即可. 然后重启Subversion服务. 如果本地SVN客户端查看过日志会有缓存, 需要在 设置-&gt;日志缓存-&gt;缓存的版本库 中删除有问题的版本缓存 再重新查看日志就好了. linux svn启动和关闭 1，启动SVNsudo svnserve -d -r /var/svn/svnrepos 其中 -d 表示守护进程， -r 表示在后台执行/var/svn/svnrepos 为svn的安装目录 2，关闭SVN这里采取linux杀死进程的方式处理的ps -ef|grep svnserveroot 4967 1 0 Aug23 ? 00:00:00 svnserve -d -r repository/ 这里 kill -9 4967杀死进程， 此4967为进程号 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/03/20/SVN-server-linux/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"svn server","slug":"svn-server","permalink":"http://agehua.github.io/tags/svn-server/"},{"name":"linux","slug":"linux","permalink":"http://agehua.github.io/tags/linux/"}]},{"title":"JSR-330和assertion(断言)介绍","slug":"JAVA-JSR-330-Assertion","date":"2017-03-13T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/03/14/JAVA-JSR-330-Assertion/","link":"","permalink":"http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/","excerpt":"@Inject注解和Android中的依赖注入框架怎么让代码显得高大上呢，当然是多使用注解，那Android Support Annotation没新意了，有没有更高端的呢？\n当然有了。Java 依赖注入标准（JSR-330）规范，主要应用在JavaEE中。在 javax.inject 包中提供了一个接口 Provider，和几个注解类型 @Scope、@Inject、@Named、@Qualifier\n关于JSR-330标准可以看这篇文章：Java 依赖注入标准（JSR-330）\n下面简单介绍下 javax.inject 中提供的注解类型。","text":"@Inject注解和Android中的依赖注入框架怎么让代码显得高大上呢，当然是多使用注解，那Android Support Annotation没新意了，有没有更高端的呢？ 当然有了。Java 依赖注入标准（JSR-330）规范，主要应用在JavaEE中。在 javax.inject 包中提供了一个接口 Provider，和几个注解类型 @Scope、@Inject、@Named、@Qualifier 关于JSR-330标准可以看这篇文章：Java 依赖注入标准（JSR-330） 下面简单介绍下 javax.inject 中提供的注解类型。 @Inject@Inject是javax.inject中提供的一个注解，可以不使用new关键字直接创建对象，怎么样，是不是很高端 :) 在字段注解：用@Inject注解，字段不能是final的。可以拥有一个合法的名称 doc文档原文： Injectable fields: - are annotated with @Inject. - are not final. - may have any otherwise valid name.@Inject FieldModifiers(opt) Type VariableDeclarators; (opt)这里表示可选 在方法上注解：用@Inject注解，不能是抽象方法，不能声明自身参数类型。可以有返回结果。拥有一个合法的名称。可以有0个或多个参数 doc文档原文： Injectable methods:- are annotated with @Inject.- are not abstract.- do not declare type parameters of their own.- may return a result- may have any otherwise valid name.- accept zero or more dependencies as arguments.@Inject MethodModifiers(opt) ResultType Identifier(FormalParameterList(opt)) Throws(opt) MethodBody (opt)这里表示可选 代码示例： @InjectWeatherDao weatherDao; @InjectWeatherDao(Context context) &#123; this.context = context;&#125; @Inject支持构造函数、方法和字段注解，也可能使用于静态实例成员。可注解成员可以是任意修饰符（private,package-private,protected,public）。注入顺序：构造函数、字段，然后是方法。父类的字段和方法注入优先于子类的字段和方法，同一类中的字段和方法是没有顺序的。 @Inject注解的构造函数可以是无参或多个参数的构造函数。@Inject每个类中最多注解一个构造函数。 除了@Inject注解，还有@Named、@Qualifier和@Provider，下面简单介绍一下。 @Named@Named，一般和@Inject一起使用，如果没有值生成的Bean名称默认和类名相同。 如果指定名称，那么就生成一个指定名称的Bean。public class Car &#123; @Inject @Named(\"driver\") Seat driverSeat; @Inject @Named(\"passenger\") Seat passengerSeat; ...&#125; @Qualifier自定义一个新的修饰语（注解），一个qualifier注解应该满足如下条件： 定义的注解类有@Qualifier，@Retention(RUNTIME)和@Documented。 可以有属性 可以是公共API的一部分 可以用@Target注解限定使用范围 doc文档原文是：Identifies qualifier annotations. Anyone can define a new qualifier. A qualifier annotation:- is annotated with @Qualifier, @Retention(RUNTIME), and typically @Documented.- can have attributes.- may be part of the public API, much like the dependency type, but unlike implementation types which needn't be part of the public API.- may have restricted usage if annotated with @Target. While this specification covers applying qualifiers to fields and parameters only, some injector configurations might use qualifier annotations in other places (on methods or classes for example). 下面是java doc文档@Named注解的生成代码@Qualifier@Documented@Retention(value=RUNTIME)public @interface Named @Documented @Retention(RetentionPolicy.RUNTIME) @Qualifier @Target(value = &#123;ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE&#125;) public @interface Genre &#123; User user() default User.STUDENT; public enum User &#123;STUDENT, TEACHER&#125; &#125; @Named @Genre(user = User.STUDENT) public class StudentDAO implements IUserDAO&#123; @Override public int count() &#123; System.out.println(\"----StudentDAO----\"); return 0; &#125;&#125; @Provider@Provider注解，可以实现任意类型的对象的注入。相对于直接注入T对象，@Provider提供了一个T.get()方法来获取注入的对象 doc文档原文:Provides instances of T. Typically implemented by an injector. For any type T that can be injected, you can also inject Provider&lt;T&gt;. Compared to injecting T directly, injecting Provider&lt;T&gt; enables:- retrieving multiple instances.- lazy or optional retrieval of an instance.- breaking circular dependencies.- abstracting scope so you can look up an instance in a smaller scope from an instance in a containing scope. For example:class Car &#123;@Inject Car(Provider&lt;Seat&gt; seatProvider) &#123; Seat driver = seatProvider.get(); Seat passenger = seatProvider.get(); ... &#125;&#125; get方法解释T get() Provides a fully-constructed and injected instance of T. @Singleton使用该注解标记该类只创建一次，不能被继承。一般在类上用该注解。 doc原文:@Scope@Documented@Retention(value=RUNTIME)public @interface SingletonIdentifies a type that the injector only instantiates once. Not inherited. @Scope注解 @Scope 用于标识作用域注解。一个作用域注解是被标识在包含一个可注入构造器的类上的，用于控制该类型的实例如何被注入器重用。缺省情况下，如果没有标识作用域注解，注入器将为每一次注入都创建（通过注入类型的构造器）新实例，并不重用已有实例。如果多个线程都能够访问一个作用域内的实例，该实例实现应该是线程安全的。作用域实现由注入器完成。 在下面的例子中，作用域注解 @Singleton 确保我们始终只有一个 Log 实例： @Singletonclass Log &#123; void log(String message) &#123; ... &#125;&#125; 当多于一个作用域注解或不被注入器支持的作用域注解被使用在同一个类上时，注入器将生成一个错误。 一个作用域注解： 被标注了 @Scope、@Retention(RUNTIME) 标注的，通常也被 @Documented 标注。 不应该含有属性。 不应该被 @Inherited 标注，因此作用域与继承实现（正交）无关。 如果标注了 @Target 可能会有一些用法限制。 使用 @Scope 来标识一个作用域注解有助于注入器探测程序员使用了作用域注解但却忘了去配置作用域的情况。一个保守的注入器应该生成一个错误而不是去适用该作用域。 doc原文请点击 assertion(断言)在实现中，assertion就是在程序中的一条语句，它对一个boolean表达式进行检查，一个正确程序必须保证这个boolean表达式的值为true；如果该值为false，说明程序已经处于不正确的状态下，系统将给出警告并且退出。 在语法上，为了支持assertion，Java增加了一个关键字assert。它包括两种表达式，分别如下： 1.assert expression1;2.assert expression1: expression2; expression1表示一个boolean表达式，expression2表示一个基本类型、表达式或者是一个Object，用于在失败时输出错误信息。 在运行时，如果关闭了assertion功能，这些语句将不起任何作用。 如果打开了assertion功能，那么expression1的值将被计算。 如果它的值为false，该语句强抛出一个AssertionError对象。 如果expression1值为true，expression2将不被计算。 如何关闭和开启assertion功能，请看这篇文章 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Annotation","slug":"annotation","permalink":"http://agehua.github.io/tags/annotation/"},{"name":"assertion","slug":"assertion","permalink":"http://agehua.github.io/tags/assertion/"}]},{"title":"“HTTPS”安全在哪里？","slug":"Https-Questions","date":"2017-03-08T16:00:00.000Z","updated":"2024-12-05T09:41:56.319Z","comments":true,"path":"2017/03/09/Https-Questions/","link":"","permalink":"http://agehua.github.io/2017/03/09/Https-Questions/","excerpt":"\n文章转载自：“HTTPS”安全在哪里？ (出处: Bugly)\n\n\n背景最近基于兴趣学学习了下 HTTPS 相关的知识，在此记录下学习心得。\n在上网获取信息的过程中，我们接触最多的信息加密传输方式也莫过于HTTPS了。每当访问一个站点，浏览器的地址栏中出现绿色图标时，意味着该站点支持HTTPS信息传输方式。我们知道HTTPS是我们常见的HTTP协议与某个加密协议的混合体，也就是 HTTP+S。这个 S 可以是 TLS（安全传输层协议）、也可以是 SSL（安全套接层），不过我更认可另一个抽象概括的说法，HTTP+Security。不过要谈论 HTTPS 为何安全，还得从 HTTP 为何不安全说起。","text":"文章转载自：“HTTPS”安全在哪里？ (出处: Bugly) 背景最近基于兴趣学学习了下 HTTPS 相关的知识，在此记录下学习心得。 在上网获取信息的过程中，我们接触最多的信息加密传输方式也莫过于HTTPS了。每当访问一个站点，浏览器的地址栏中出现绿色图标时，意味着该站点支持HTTPS信息传输方式。我们知道HTTPS是我们常见的HTTP协议与某个加密协议的混合体，也就是 HTTP+S。这个 S 可以是 TLS（安全传输层协议）、也可以是 SSL（安全套接层），不过我更认可另一个抽象概括的说法，HTTP+Security。不过要谈论 HTTPS 为何安全，还得从 HTTP 为何不安全说起。 假设你现在正坐在教室里上课，现在你非常想和走道旁的迷人的 TA 说一些话，一般这个时候你会用“传纸条”的方式来交流。而这个方式和 TCP/IP 协议基本的工作模式十分相像： 通过小动作引起对方注意； 对方以多种可能的方式（注视、肢体语言等）回应于你； 你确认对方感知到你后，将纸条传给对方； 对方阅读纸条； 对方给予你阅读后的反应； 怎么样，这个流程是不是很熟悉？ 如果你要传递纸条的 TA 距离你很远怎么办？HTTP 协议就是指你在纸条上写明你要传给的 TA 是谁，或者 TA 的座位在哪，接着只需要途径的同学拿到纸条后根据纸条上的指示依次将纸条传过去就 OK 了。 这个时候问题来了：途径的同学完全可以观看并知道你在纸条上写了什么。 这就是 HTTP 传输所面临的问题之一：中间人攻击，指消息传递的过程中，处在传递路径上的攻击者可以嗅探或者窃听传输数据的内容。 加密HTTPS 针对这个问题，采用了“加密”的方式来解决。最著名原始的加密方法就是对称加密算法了，就是双方约定一个暗号，用什么字母替换什么字母之类的。现在一般采用一种叫 AES（高级加密算法）的对称算法。 对称加密算法既指加密和解密需要使用的密钥 key 是一样的。 AES 在数学上保证了，只要你使用的 key 足够长，破解几乎是不可能的（除非光子计算机造出来了）我们先假设在没有密钥 key 的情况下，密文是无法被破解的，然后再回到这个教室。你将用 AES 加密后的内容噌噌噌地写在了纸条上，正要传出去的时候你突然想到，TA 没有 key 怎么解密内容呀，或者说，应该怎么把 key 给TA？ 如果把 key 也写在纸条上，那么中间人照样可以破解窃听纸条内容。也许在现实环境中你有其他办法可以把 key 通过某种安全的渠道送到 TA 的手里，但是互联网上的实现难度就比较大了，毕竟不管怎样，数据都要经过那些路由。 于是聪明的人类发明了另一种加密算法——非对称加密算法。这种加密算法会生成两个密钥（key1 和 key2）。凡是 key1 加密的数据，key1 自身不能解密，需要 key2 才能解密；凡事 key2 加密的数据，key2 自身不能解密，只有 key1 才能解密。 目前这种算法有很多中，最常用的是RSA。其基于的数学原理是： 两个大素数的乘积很容易算，但是用这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因确实比较困难，尤其是当这个大数足够大的时候（通常使用2的10次方个二进制位那么大），就算是超级计算机，解密也需要非常长的时间。现在就把这种非对称加密的方法应用在我们教室传纸条的场景里。 你在写纸条内容之前先用 RSA 技术生成了一对密钥 k1 和 k2。 你把 k1 用明文传了出去，路经也许有人会截取，但是没有用，k1 加密的数据需要 k2 才可以破解，而 k2 在你自己手中。 k1 传到了目的人，目的人会去准备一个接下来准备用于对称加密（AES）的传输密钥 key，然后用收到的 k1 把 key 加密，传给你。 你用手上的 k2 解出 key 后，全教室只有你和你的目的人拥有这个对称加密的 key，你们俩就可以尽情聊天不怕窃听啦~ 这里也许你会有问题，为什么不直接用非对称加密来加密信息，而是加密 AES 的 key 呢？ 因为非对称加密和解密的平均消耗时间比较长，为了节省时间提高效率，我们通常只是用它来交换密钥，而非直接传输数据。然而使用非对称加密真的可以防范中间人攻击吗？虽然看上去很安全，但是实际上却挡不住可恶的中间人攻击。 假设你是 A，你的目的地是 B，现在要途径一个恶意同学M。 中间人的恶意之处在于它会伪装成你的目标。当你要和 B 完成第一次密钥交换的时候，M 把纸条扣了下来，假装自己是B并伪造了一个 key，然后用你发来的 k1 加密了 key 发还给你。你以为你和 B 完成了密钥交换，实际上你是和 M 完成了密钥交换。同事M 和 B 完成一次密钥交换，让 B 以为和 A 你完成了密钥交换。现在整体的加密流程变成了A（加密链接1）-&gt;M(明文)-&gt;B(加密链接2)的情况了，这时候 M 依然可以知道A和B传输的全部消息。 这个时候就是体现 HTTPS 和传纸条的区别了。在教室里，你是和一位与你身份几乎对等的的对象来通信；而在访问网站时，对方往往是一个比较大（或者知名）的服务者，他们有充沛的资源，或许他们可以向你证明他们的合法性。此时我们需要引入一个非常权威的第三方，一个专门用来认证网站合法性的组织，可以叫做 CA（Certificate Authority）。各个网站服务商可以向CA申请证书，使得他们在建立安全连接时可以带上CA的签名。而CA得安全性是由操作系统或者浏览器来认证的。 你的Windows、Mac、Linux、Chrome、Safari等会在安装的时候带上一个他们认为安全的 CA 证书列表，只有和你建立安全连接的网站带有这些CA的签名，操作系统和浏览器才会认为这个链接是安全的，否则就有可能遭到中间人攻击。一旦某个CA颁发的证书被用于的非法途径，那么这个CA之前颁发过的所有证书都将被视为不安全的，这让所有CA在颁发证书时都十分小心，所以CA证书在通常情况下是值得信任的。 总结使 HTTP 后面增加一个S（Security）的技术，正是 对称加密 + 非对称加密 + CA认证 这三种技术的混合体。当然这个主要是 HTTPS 的基本原理，真正实际中的 HTTPS 的协议是比以上的描述更为复杂一些的，并且其中任何一步稍有闪失，整个流程都将不再安全。这也是为什么 HTTPS 协议从 SSL 1.0升级到 SSL 3.0，再被 TLS 1.0 现在被 TLS 1.3取代，其背后都是一个个细节上的优化，以防有任何闪失。TLS 协议相比 SSL 协议增加了传输层的安全保证。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/03/09/Https-Questions/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"HTTPS","slug":"https","permalink":"http://agehua.github.io/tags/https/"}]},{"title":"解决Android多进程导致Application重复创建问题","slug":"Multi-Process-Dispatch","date":"2017-02-20T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/02/21/Multi-Process-Dispatch/","link":"","permalink":"http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/","excerpt":"\n本编文章是在阅读：Android架构思考(模块化、多进程)过程中，结合自己的理解，对Android开启多进程，会导致Application重复创建问题进行一个总结。\n\n\nAndroid开启多进程一般情况下，一个应用程序就一个进程，这个进程的名称就是应用程序包名。Android的四大组件在AndroidManifest文件中注册的时候，有个属性是android:process，这里可以指定组件的所处的进程。\n一个进程情况下，Application的onCreate方法只会执行一次，但如果应用中采用多进程方式，onCreate方法会执行多次。\n解决Application的onCreate方法多次调用总结了两种实现方式：","text":"本编文章是在阅读：Android架构思考(模块化、多进程)过程中，结合自己的理解，对Android开启多进程，会导致Application重复创建问题进行一个总结。 Android开启多进程一般情况下，一个应用程序就一个进程，这个进程的名称就是应用程序包名。Android的四大组件在AndroidManifest文件中注册的时候，有个属性是android:process，这里可以指定组件的所处的进程。 一个进程情况下，Application的onCreate方法只会执行一次，但如果应用中采用多进程方式，onCreate方法会执行多次。 解决Application的onCreate方法多次调用总结了两种实现方式： 一、根据不同的进程名字进行不同数据的初始化。这是现在网络上通用的方法，在自定义的Application的onCreate方法中控制不同进程的初始化 代码如下： @Overridepublic void onCreate() &#123; super.onCreate(); String processName = getProcessName(this, android.os.Process.myPid()); if (processName != null) &#123; boolean defaultProcess = processName.equals(Constants.REAL_PACKAGE_NAME); // 默认的主进程启动时初始化应用 if (defaultProcess) &#123; initAppForMainProcess(); &#125; // 其他进程启动时初始化对应内容 else if (processName.contains(\":webbrowser\")) &#123; &#125; else if (processName.contains(\":bgmusic\")) &#123; &#125; &#125; 获取当前进程名的方法如下： /** * @return null may be returned if the specified process not found */public static String getProcessName(Context cxt, int pid) &#123; ActivityManager am = (ActivityManager) cxt.getSystemService(Context.ACTIVITY_SERVICE); List&lt;RunningAppP.rocessInfo&gt; runningApps = am.getRunningAppProcesses(); if (runningApps == null) &#123; return null; &#125; for (RunningAppProcessInfo procInfo : runningApps) &#123; if (procInfo.pid == pid) &#123; return procInfo.processName; &#125; &#125; return null;&#125; 二、剥离出一个类，具有同Application相同的生命周期方法，每个进程拥有一个该类实例这就是文章开头提到的博客中使用的方式Android架构思考(模块化、多进程) 实现这种方式，一共有涉及到3个类， 一个是MaApplication继承了Application，是程序的入口，这是一个抽象类，需要子类去实现一些方法 一个是BaseApplicationLogic，这也是基类，由这个类来实现每个进程单独管理Application的生命周期，每个进程实现一个该类的子类 还有一个类是PriorityLogicWrapper，它是一个封装类，继承了Comparable接口，实现了对BaseApplicationLogic按照指定顺序排序（也就是可以按照优先级顺序初始化BaseApplicationLogic） 首先，我们先把所有ApplicationLogic注册到MaApplication中；然后，MaApplication会根据注册时的进程名信息进行筛选，选择相同进程名的ApplicationLogic，保存到本进程中；其次，对这些本进程的ApplicationLogic进行实例化；最后，调用ApplicationLogic的onCreate方法，实现ApplicationLogic与Application生命周期同步，同时还有onTerminate、onLowMemory、onTrimMemory、onConfigurationChanged等方法，与onCreate一致。 流程图如下所示： 代码实现，先看基类BaseApplicationLogic，每个进程都要实现一个该类的子类： public class BaseApplicationLogic &#123; protected MaApplication mApplication; public BaseApplicationLogic() &#123; &#125; public void setApplication(@NonNull MaApplication application) &#123; mApplication = application; &#125; public void onCreate() &#123; &#125; public void onTerminate() &#123; &#125; public void onLowMemory() &#123; &#125; public void onTrimMemory(int level) &#123; &#125; public void onConfigurationChanged(Configuration newConfig) &#123; &#125;&#125; 其次PriorityLogicWrapper，这是一个封装类，实现了BaseApplicationLogic的按优先级排列：public class PriorityLogicWrapper implements Comparable&lt;PriorityLogicWrapper&gt; &#123; public int priority = 0; public Class&lt;? extends BaseApplicationLogic&gt; logicClass = null; public BaseApplicationLogic instance; public PriorityLogicWrapper(int priority, Class&lt;? extends BaseApplicationLogic&gt; logicClass) &#123; this.priority = priority; this.logicClass = logicClass; &#125; @Override public int compareTo(PriorityLogicWrapper o) &#123; return o.priority - this.priority; &#125;&#125; 在MaApplication中直接对PriorityLogicWrapper进行操作，无需操作BaseApplicationLogic对象public abstract class MaApplication extends Application &#123; //mLogicList只持有当前进程的PriorityLogicWrapper对象 private ArrayList&lt;PriorityLogicWrapper&gt; mLogicList; //mLogicClassMap持有所有进程的PriorityLogicWrapper数组对象 private HashMap&lt;String, ArrayList&lt;PriorityLogicWrapper&gt;&gt; mLogicClassMap; @Override public void onCreate() &#123; super.onCreate(); init(); initializeLogic(); dispatchLogic(); instantiateLogic(); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; //找到当前进程的BaseApplicationLogic实例后，执行其onCreate()方法 priorityLogicWrapper.instance.onCreate(); &#125; &#125; &#125; &#125; private void init() &#123; mLogicClassMap = new HashMap&lt;&gt;(); &#125; public abstract boolean needMultipleProcess(); //由MaApplication的实现类，去实现这个方法，调用registerApplicationLogic() //注册所有进程的BaseApplicationLogic对象 protected abstract void initializeLogic(); /** * 添加所有来自不同进程的，不同的BaseApplicationLogic对象到HashMap中 * @param processName 进程名 * @param priority 优先级 * @param logicClass 继承BaseApplicationLogic的对象 * @return */ protected boolean registerApplicationLogic(String processName, int priority, @NonNull Class&lt;? extends BaseApplicationLogic&gt; logicClass) &#123; boolean result = false; if (null != mLogicClassMap) &#123; ArrayList&lt;PriorityLogicWrapper&gt; tempList = mLogicClassMap.get(processName); if (null == tempList) &#123; tempList = new ArrayList&lt;&gt;(); mLogicClassMap.put(processName, tempList); &#125; if (tempList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : tempList) &#123; if (logicClass.getName().equals(priorityLogicWrapper.logicClass.getName())) &#123; throw new RuntimeException(logicClass.getName() + \" has registered.\"); &#125; &#125; &#125; PriorityLogicWrapper priorityLogicWrapper = new PriorityLogicWrapper(priority, logicClass); tempList.add(priorityLogicWrapper); //tempList更新，则mLogicClassMap中的value也跟着更新了，不用再调用mLogicClassMap.put方法 &#125; return result; &#125; /** * 得到一个属于本进程的ArrayList对象，里面保存着封装类PriorityLogicWrapper */ private void dispatchLogic() &#123; if (null != mLogicClassMap) &#123; //根据进程名，得到该进程名对应的ArrayList&lt;PriorityLogicWrapper&gt; mLogicList = mLogicClassMap.get(ProcessUtil.getProcessName(this, ProcessUtil.getMyProcessId())); &#125; &#125; /** * 取得mLogicList中的PriorityLogicWrapper对象，并按优先级顺序初始化BaseApplicationLogic对象 */ private void instantiateLogic() &#123; if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; Collections.sort(mLogicList); //根据进程优先级，按顺序初始化 for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper) &#123; try &#123; /** * 调用Class.newInstance()，会创建这个Class的实例，但是不会执行Android中这个类相关的生命周期 * **/ priorityLogicWrapper.instance = priorityLogicWrapper.logicClass.newInstance(); &#125; catch (InstantiationException e) &#123; e.printStackTrace(); &#125; catch (IllegalAccessException e) &#123; e.printStackTrace(); &#125; if (null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.setApplication(this); &#125; &#125; &#125; &#125; &#125; &#125; //Application生命周期的处理，下面方法都类似 @Override public void onTerminate() &#123; super.onTerminate(); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onTerminate(); &#125; &#125; &#125; &#125; @Override public void onLowMemory() &#123; super.onLowMemory(); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onLowMemory(); &#125; &#125; &#125; &#125; @Override public void onTrimMemory(int level) &#123; super.onTrimMemory(level); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onTrimMemory(level); &#125; &#125; &#125; &#125; @Override public void onConfigurationChanged(Configuration newConfig) &#123; super.onConfigurationChanged(newConfig); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onConfigurationChanged(newConfig); &#125; &#125; &#125; &#125;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"multi-process","slug":"multi-process","permalink":"http://agehua.github.io/tags/multi-process/"}]},{"title":"MAC下用iTerm2连接远程主机","slug":"iterm2-to-linux","date":"2017-02-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2017/02/12/iterm2-to-linux/","link":"","permalink":"http://agehua.github.io/2017/02/12/iterm2-to-linux/","excerpt":"MAC下用iTerm2连接远程主机iTerm2是MAC的一个终端工具。简单介绍一个小功能，使用iTerm2连接远程主机：\n\n1.先打开一个iTerm2窗口，选择菜单profiles中的Open Profiles，然后选择Edit Profiles中创建一个新的Profile，随便命名成容易记的。\n2.选择command，输入ssh -A -p xxx root@输入远程计算机的IP地址（xxx表示端口）。\n3.然后选择这个新的profile，New一个window就可以连接远程服务器了。\n\nSCP命令使用说明","text":"MAC下用iTerm2连接远程主机iTerm2是MAC的一个终端工具。简单介绍一个小功能，使用iTerm2连接远程主机： 1.先打开一个iTerm2窗口，选择菜单profiles中的Open Profiles，然后选择Edit Profiles中创建一个新的Profile，随便命名成容易记的。 2.选择command，输入ssh -A -p xxx root@输入远程计算机的IP地址（xxx表示端口）。 3.然后选择这个新的profile，New一个window就可以连接远程服务器了。 SCP命令使用说明 scp用来在网络上不同的主机之间复制文件，它使用ssh安全协议传输数据，具有和ssh一样的验证机制，从而安全的远程拷贝文件。 下面是一个简单例子： 首先创建一个本地文件echo hello, world &gt; a-file.txt copy本地文件到服务器的命令如下：scp &lt;local file&gt; &lt;remote user&gt;@&lt;remote machine&gt;:&lt;remote path&gt; 如果想Copy远程文件到本地，则是：scp &lt;remote user&gt;@&lt;remote machine&gt;:&lt;remote path&gt; &lt;local file&gt; 如果想复制目录也是可以的：scp -r local_folder remote_username@remote_ip:remote_folder 比如下面命令：scp -r /home/space/jdk-8u121-linux-x64.tar.gz root@107.182.178.94:/home/root/others/ 参数说明： [root@tank test]# scp –helpusage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 […] [[user@]host2:]file2 -1 强制scp命令使用协议ssh1-2 强制scp命令使用协议ssh2-4 强制scp命令只使用IPv4寻址-6 强制scp命令只使用IPv6寻址-B 使用批处理模式（传输过程中不询问传输口令或短语）-C 允许压缩。（将-C标志传递给ssh，从而打开压缩功能）-p 保留原文件的修改时间，访问时间和访问权限。-q 不显示传输进度条。-r 递归复制整个目录。-v 详细方式显示输出。scp和ssh(1)会显示出整个过程的调试信息。这些信息用于调试连接，验证和配置问题。-c cipher 以cipher将数据传输进行加密，这个选项将直接传递给ssh。-F ssh_config 指定一个替代的ssh配置文件，此参数直接传递给ssh。-i identity_file 从指定文件中读取传输时使用的密钥文件，此参数直接传递给ssh。-l limit 限定用户所能使用的带宽，以Kbit/s为单位。-o ssh_option 如果习惯于使用ssh_config(5)中的参数传递方式，-P port 注意是大写的P, port是指定数据传输用到的端口号-S program 指定加密传输时所使用的程序。此程序必须能够理解ssh(1)的选项。 转载自：http://blog.51yip.com/linux/1027.html iTerm从mac传文件到linuxsudo scp -P 28547 ~/Downloads/nexus-3.2.1-01-unix.tar.gz root@107.182.178.94:/usr/local -P 指定linux服务器的端口号，必须是大写 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/02/12/iterm2-to-linux/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"linux","slug":"linux","permalink":"http://agehua.github.io/tags/linux/"},{"name":"iterm","slug":"iterm","permalink":"http://agehua.github.io/tags/iterm/"},{"name":"scp","slug":"scp","permalink":"http://agehua.github.io/tags/scp/"}]},{"title":"IM 国外公司，服务费，方案","slug":"abroad-IM-service-company","date":"2017-01-12T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/01/13/abroad-IM-service-company/","link":"","permalink":"http://agehua.github.io/2017/01/13/abroad-IM-service-company/","excerpt":"一、海外提供IM服务的公司1.1 Sinch官网： https://www.sinch.com/products/instant-messaging/收费介绍","text":"一、海外提供IM服务的公司1.1 Sinch官网： https://www.sinch.com/products/instant-messaging/收费介绍 1.2 quickblox官网：https://quickblox.com/收费介绍 1.3 Layerhttps://layer.com/use-cases 具体价格需要注册，然后注册的邮箱里会收到一封邮件： 1.4sendbirdhttps://sendbird.com 收费介绍 1.5 applozichttps://www.applozic.com/收费介绍 二、各家IM服务公司比较 图片来源：Which Chat SDK is better for user experience? Applozic, Sendbird, Layer or Quickblox! 2.1 QuickBlox vs Applozic这部分内容转载自stackoverflow I have recently just tested two of the solutions you have cited. QuickBlox: protocol xmpp open source documentated less clearly than applozic easy set up Applozic: protocol mqtt open source easy set up, if a bit laborious well documented, and very easy API to use. Very customizable. Both programs: have video call/audio call/groups have code bases that are constantly being updated, and from their Github pages new version have been released in the past few months I preferred Applozic as the user interface was nicer and easier to use, and the features and pricing clearer. I also preferred the API and the setup code was easier. 2.2 Quickblox vs SendBird vs Layer本部分内容转载自Do I need to have my own backend? My research on Quickblox vs SendBird vs Layer.com is: 1.Backend-as-a-Service (BaaS) or Chat-as-a-Service (CaaS): Quickblox: Both, BaaS and CaaS SendBird (aka JIVER): CaaS (BaaS for Enterprise-only) Layer.com: CaaS only 2.WebSocket-based: Quickblox: No (XMPP) SendBird: Yes Layer.com: Yes 3.Voice and Video: Quickblox: Yes SendBird: No Layer.com: No 4.Chat UI Kit: Quickblox: QMChatViewController SendBird: Open-source Sample UIs for iOS, Android, JavaScript (Web &amp; React Native), Xamarin, Unity (You can use their Sample UI or 3rd party UI Kit like JSQMessagesViewController) Layer.com: Atlas 5.Number of Members in a Group: Quickblox: Thousands (you may need to host Quickblox BaaS at a dedicated AWS infrastructure for better performance) SendBird: Thousands (no need for an extra infrastructure) Layer.com: limited to 25 per group 6.The ability to host the BaaS/CaaS at your own IaaS: Quickblox: Yes (setup cost starts from $599) SendBird: Yes (limited to Enterprise plans only) Layer.com: No 7.Custom Objects Backend (the need for extra infrastructure): Quickblox: Included in Quickblox BaaS SendBird: Partial support (Key/value custom object stores for channels to be released in March) Layer.com: No 8.BaaS/CaaS Admin Panel/Dashboard: Quickblox: Basic with Custom Dashboard when subscribed to the enterprise plan, starts from $599/month (Classic UI) SendBird: Advanced (Modern UI) Layer.com: Basic (Modern UI) 9.Attachment max file size: Quickblox: Unknown SendBird: 25MB per file (custom limit for Enterprise plans) Layer.com: 2GB (be aware that their pricing is based on the data transfer) 10.Availability SLA: Quickblox: Based on AWS EC2 SLA (99.95%) SendBird: 99.9% Layer.com: 99.9% 11.Pricing (per month): Quickblox: Mainly based on the number of messengers per second (/s) and monthly active users: Free-$49-$214-$599-$1,199-$2,399 (Plans) SendBird: Mainly based on the number of monthly active users (MAU): Free-$59-$179-$599-Custom (https://sendbird.com/pricing) Layer.com: Mainly based on the monthly data transfer and monthly users: Free-$599 per month-Custom (https://layer.com/plans) 12.Number of freelancers at UpWork.com who have this Baas/CaaS as one of their skill set: Quickblox: 547 (keyword: “Quickblox”) SendBird: 0 (keyword: “SendBird” or “JIVER”) « new to the market Layer: 13 (keyword: “Layer.com” not Layer) 2.3 更多比较：https://www.quora.com/Quickblox-vs-SendBird-vs-Layer-com-Do-I-need-to-have-my-own-backend http://stackoverflow.com/questions/37678528/comparing-layer-applozic-quickblox-sendbird-for-quick-whatsapp-like-messagin https://www.applozic.com/blog/applozic-vs-sendbird-vs-layer-vs-quickblox-alternatives/ https://siftery.com/product-comparison/sendbird-vs-quickblox-vs-layer https://stackshare.io/stackups/sendbird-vs-sinch-vs-layer https://www.quora.com/What-SDKs-APIs-are-viable-for-implementing-instant-messaging-between-clients-Android-iOS-and-web 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/01/13/abroad-IM-service-company/","raw":null,"content":null,"categories":[{"name":"Investigation","slug":"investigation","permalink":"http://agehua.github.io/categories/investigation/"}],"tags":[{"name":"IM Company","slug":"im-company","permalink":"http://agehua.github.io/tags/im-company/"}]},{"title":"Android 增量更新整理","slug":"Android-patch-update","date":"2016-12-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/12/20/Android-patch-update/","link":"","permalink":"http://agehua.github.io/2016/12/20/Android-patch-update/","excerpt":"背景在前几年，整体移动网络环境相比现在差很多，加之流量费用又相对较高，因此每当我们发布新版本的时候，一些用户升级并不是很积极，这就造成了新版本的升级率并不高。而google为了解决了这个问题，提出了Smart App Update，即增量更新（也叫做差分升级）。\n增量更新与热修复完全不是一个东西。增量更新需要重新安装apk，而热修复不需要。热修复也能完成部分增量更新的功能。\n增量更新的流程增量更新的具体流程是：用户手机上安装着某个应用，下载了增量包，手机上的apk和增量包合并形成新的包，然后再次安装（注意这个过程是要重新安装的，当然部分应用市场有root权限你可能感知不到）。","text":"背景在前几年，整体移动网络环境相比现在差很多，加之流量费用又相对较高，因此每当我们发布新版本的时候，一些用户升级并不是很积极，这就造成了新版本的升级率并不高。而google为了解决了这个问题，提出了Smart App Update，即增量更新（也叫做差分升级）。 增量更新与热修复完全不是一个东西。增量更新需要重新安装apk，而热修复不需要。热修复也能完成部分增量更新的功能。 增量更新的流程增量更新的具体流程是：用户手机上安装着某个应用，下载了增量包，手机上的apk和增量包合并形成新的包，然后再次安装（注意这个过程是要重新安装的，当然部分应用市场有root权限你可能感知不到）。 增量更新的原理增量更新的原理也很简单，就是将手机上已安装的旧版本apk与服务器端新版本apk进行二进制对比，并得到差分包（patch），用户在升级更新应用时，只需要下载差分包，然后在本地使用差分包与旧版的apk合成新版apk，然后进行安装。差分包文件的大小，那就远比APK小得多了，这样也便于用户进行应用升级。 那么增量更新的流程可以细化为几个关键点： 1.用户手机上提取当前安装应用的apk 2.如何利用old.apk和new.apk生成增量文件（差分包） 3.增加文件与1.中的old.apk合并，然后安装 旧版的APK可以在/data/app/%packagename%/下找到。 也可以参考下面的代码： public class ApkExtract &#123; public static String extract(Context context) &#123; context = context.getApplicationContext(); ApplicationInfo applicationInfo = context.getApplicationInfo(); String apkPath = applicationInfo.sourceDir; Log.d(\"hongyang\", apkPath); return apkPath; &#125;&#125; 这部分可以参考张鸿洋的博客 关于生成差分包制作差分包的工具为bsdiff， 网址： http://www.daemonology.net/bsdiff/ 下载地址： http://www.daemonology.net/bsdiff/bsdiff-4.3.tar.gz 这是一个非常牛的二进制查分工具，bsdiff源代码在Android的源码目录下 ”\\external\\bsdiff“”这边也可以找到。另外还需要依赖bzlib来进行打包。在安全性方面，补丁和新旧版APK最好都要进行MD5验证，以免被篡改。 关于这个工具可以使用别人编译好的so库，这里；熟悉NDK开发的也可以自己编译，请看这里。这里就不在考虑这个工具问题了。 生成增量文件./bsdiff old.apk new.apk old-to-new.patch 这样就生成了一个增量文件old-to-new.patch 关于合并差分包生成差分包肯定是在服务端，合并差分包才是Android客户端需要做的： 增量文件和old.apk合并成新的apk./bspatch old.apk new2.apk old-to-new.patch 这样就生成一个new2.apk 生成后，要查看下两个文件的md5值。如果两个文件md5值一致，那么几乎可以肯定两个文件时一模一样的。 增量更新存在的不足 1、增量升级是以两个应用版本之间的差异来生成补丁的，但是我们无法保证用户每次的及时升级到最新，也就是在更新前，新版和旧版只差一个版本，所以必须对你所发布的每一个版本都和最新的版本作差分，以便使所有版本的用户都可以差分升级，这样相对就比较繁琐了。解决方法也有，可以通过Shell脚本来实现批量生成。 2.增量升级能成功的前提是，从手机端能够获得旧版APK，并且与服务端的APK签名是一样的，所以像那些破解的APP就无法实现更新。前面也提到了，为了安全性，防止补丁合成错误，最好在补丁合成前对旧版本的apk进行sha1或者MD5校验，保证基础包的一致性，这样才能顺利的实现增量升级。 想要封装一套增量更新的工具，请看这篇文章：打造Android万能的软件更新库，修改只要一点点 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/20/Android-patch-update/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Patch Update","slug":"patch-update","permalink":"http://agehua.github.io/tags/patch-update/"}]},{"title":"ThreadLocal一个使用——SimpleDateFormat","slug":"ThreadLocal-usage","date":"2016-12-10T16:00:00.000Z","updated":"2024-12-05T09:41:56.414Z","comments":true,"path":"2016/12/11/ThreadLocal-usage/","link":"","permalink":"http://agehua.github.io/2016/12/11/ThreadLocal-usage/","excerpt":"背景之前写过一篇文章：《ThreadLocal、HandlerThread、Lopper区别》，其中简单提及了ThreadLocal的解释。本篇文章主要结合具体应用场景——SimpleDateFormat，和大家来一起学习ThreadLocal的原理，并对ThreadLocal进行一个详细的介绍。\n下面是本文的参考资料：\njava学习记录–ThreadLocal使用案例——SimpleDateFormat：http://blog.csdn.net/u012706811/article/details/53231598\nSimpleDateFormat的线程安全问题与解决方案：http://www.cnblogs.com/zemliu/archive/2013/08/29/3290585.html\n前言Thread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals。\n这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。\n我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（ThreadLocal用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。\nThreadLocal为变量在每个线程中都创建了一个副本，所以每个线程可以访问自己内部的副本变量，不同线程之间不会互相干扰。\n本篇文章结合具体应用场景，来分析ThreadLocal为什么可以实现不同线程之间不会互相干扰。","text":"背景之前写过一篇文章：《ThreadLocal、HandlerThread、Lopper区别》，其中简单提及了ThreadLocal的解释。本篇文章主要结合具体应用场景——SimpleDateFormat，和大家来一起学习ThreadLocal的原理，并对ThreadLocal进行一个详细的介绍。 下面是本文的参考资料： java学习记录–ThreadLocal使用案例——SimpleDateFormat：http://blog.csdn.net/u012706811/article/details/53231598 SimpleDateFormat的线程安全问题与解决方案：http://www.cnblogs.com/zemliu/archive/2013/08/29/3290585.html 前言Thread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals。 这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。 我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（ThreadLocal用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。 ThreadLocal为变量在每个线程中都创建了一个副本，所以每个线程可以访问自己内部的副本变量，不同线程之间不会互相干扰。 本篇文章结合具体应用场景，来分析ThreadLocal为什么可以实现不同线程之间不会互相干扰。 应用场景那么，在什么场景下比较适合使用ThreadLocal呢？ stackoverflow上有人给出了还不错的回答： When and how should I use a ThreadLocal variable?One possible (and common) use is when you have some object that is not thread-safe, but you want to avoid synchronizing access to that object (I’m looking at you, SimpleDateFormat). Instead, give each thread its own instance of the object. SimpleDateFormat为什么线程不安全SimpleDateFormat类内部持有一个Calendar对象引用， 如果你的工具类里，SimpleDateFormat是个static的，那么多个thread之间就会共享这个SimpleDateFormat，同时也会共享这个Calendar引用。 查看下源码中的SimpleDateFormat.parse()方法，你会发现有如下的调用: protected Calendar calendar;Date parse() &#123; calendar.clear(); // 清理calendar ... // 执行一些操作, 设置 calendar 的日期什么的 calendar.getTime(); // 获取calendar的时间&#125; 这里calendar.clear()方法是线程不安全的，不同thread调用parse()方法，会导致结果不可预期 问题重现可以看：这篇博客 解决方案最简单的解决方案我们可以把static去掉，这样每个新的线程都会有一个自己的SimpleDateFormat实例，从而避免线程安全的问题 但是，使用这种方法，在高并发的情况下会大量的new SimpleDateFormat以及销毁SimpleDateFormat，这样是非常耗费资源的 下面是一个从网上找的使用ThreadLocal解决SimpleDateFormat线程不安全问题的例子： import java.text.ParseException;import java.text.SimpleDateFormat;import java.util.Date;import java.util.HashMap;import java.util.Map;public class DateUtil &#123; /** 锁对象 */ private static final Object lockObj = new Object(); /** 存放不同的日期模板格式的SimpleDateFormat的Map */ private static Map&lt;String, ThreadLocal&lt;SimpleDateFormat&gt;&gt; sdfMap = new HashMap&lt;String, ThreadLocal&lt;SimpleDateFormat&gt;&gt;(); /** * 返回一个ThreadLocal的SimpleDateFormat,每个线程只会new一次SimpleDateFormat * * @param pattern * @return */ private static SimpleDateFormat getSdf(final String pattern) &#123; ThreadLocal&lt;SimpleDateFormat&gt; tl = sdfMap.get(pattern); // 此处的双重判断和同步是为了防止sdfMap这个单例被多次put重复的sdf if (tl == null) &#123; synchronized (lockObj) &#123; tl = sdfMap.get(pattern); if (tl == null) &#123; // 只有Map中还没有这个pattern的sdf才会生成新的sdf并放入map System.out.println(\"put new sdf of pattern \" + pattern + \" to map\"); // 这里是关键,使用ThreadLocal&lt;SimpleDateFormat&gt;替代原来直接new SimpleDateFormat tl = new ThreadLocal&lt;SimpleDateFormat&gt;() &#123; @Override protected SimpleDateFormat initialValue() &#123; System.out.println(\"thread: \" + Thread.currentThread() + \" init pattern: \" + pattern); return new SimpleDateFormat(pattern); &#125; &#125;; sdfMap.put(pattern, tl); &#125; &#125; &#125; return tl.get(); &#125; /** * 是用ThreadLocal&lt;SimpleDateFormat&gt;来获取SimpleDateFormat,这样每个线程只会有一个SimpleDateFormat * * @param date * @param pattern * @return */ public static String format(Date date, String pattern) &#123; return getSdf(pattern).format(date); &#125; public static Date parse(String dateStr, String pattern) throws ParseException &#123; return getSdf(pattern).parse(dateStr); &#125;&#125; 实现原理那为什么ThreadLocal为变量在每个线程都保存了一个副本呢？ 下面部分内容来自博文，http://www.jianshu.com/p/33c5579ef44f (深入浅出ThreadLocal) 先看一下Thread和ThreadLocal两个类的具体结构，如下： 从线程Thread的角度来看，每个线程内部都会持有一个对ThreadLocalMap实例的引用（也就是threadLocals变量），ThreadLocalMap是TThreadLocal的静态内部类。而Entry则是ThreadLocalMap的静态内部类。ThreadLocalMap实例相当于线程的局部变量空间，由Entry[] table存储着线程的私有数据。 EntryEntry继承自WeakReference类，是存储线程私有变量的数据结构。ThreadLocal实例作为引用，意味着如果ThreadLocal实例为null，就可以从table中删除对应的Entry。 class Entry extends WeakReference&lt;ThreadLocal&lt;?&gt;&gt; &#123; Object value; Entry(ThreadLocal&lt;?&gt; k, Object v) &#123; super(k); value = v; &#125;&#125; ThreadLocalMap内部使用table数组存储Entry，默认大小INITIAL_CAPACITY(16)，先介绍几个参数： size：table中元素的数量。 threshold：table大小的2/3，当size &gt;= threshold时，遍历table并删除key为null的元素，如果删除后size &gt;= threshold*3/4时，需要对table进行扩容。 ThreadLocal.set()实现/** * ThreadLocal.set() */public void set(T value) &#123; Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value);&#125;ThreadLocalMap getMap(Thread t) &#123; return t.threadLocals;&#125; 从上面代码中看出来： 1.从当前线程Thread中获取ThreadLocalMap实例。 2.ThreadLocal实例和value封装成Entry。 ThreadLocal.get() 实现public T get() &#123; Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) &#123; ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) &#123; @SuppressWarnings(\"unchecked\") T result = (T)e.value; return result; &#125; &#125; return setInitialValue();&#125;private T setInitialValue() &#123; T value = initialValue(); Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); return value;&#125;ThreadLocalMap getMap(Thread t) &#123; return t.threadLocals;&#125; 从上面代码中可以看出， ThreadLocal.get()方法，如果是不同线程ThreadLocalMap为null，最终会调用initialValue()方法，这个方法也是我们给出的解决方案中重载的方法。最后得到的结果是，不同线程ThreadLocal只有一个，而SimpleDateFormat则每个线程都有一个。 但当同一线程有了一个SimpleDateFormat了，会是什么情况呢？看下面代码： //同一线程中再次执行ThreadLocal.get()public T get() &#123; Thread t = Thread.currentThread();//得到当前子线程 ThreadLocalMap map = getMap(t); //同一个线程，map不为空 if (map != null) &#123; ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) &#123; @SuppressWarnings(\"unchecked\") T result = (T)e.value; return result; &#125; &#125; return setInitialValue();&#125;ThreadLocalMap getMap(Thread t) &#123; //同一线程Thread，变量threadLocals经过初始化了，则不为空 return t.threadLocals;&#125; ThreadLocalMap.getEntry()是如何实现的呢？先看下Entry是如何存入table数组的 Entry存入table数组如何实现的：/** * static class ThreadLocalMap.set()方法 */private void set(ThreadLocal&lt;?&gt; key, Object value) &#123; Entry[] tab = table; int len = tab.length; int i = key.threadLocalHashCode &amp; (len-1); for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) &#123; ThreadLocal&lt;?&gt; k = e.get(); if (k == key) &#123; e.value = value; return; &#125; if (k == null) &#123; replaceStaleEntry(key, value, i); return; &#125; &#125; tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) &amp;&amp; sz &gt;= threshold) rehash();&#125; 1.通过ThreadLocal的nextHashCode方法生成hash值。 threadLocalHashCode，由nextHashCode()方法得到/** * 对应上面代码的key.threadLocalHashCode * 在ThreadLocal 类中 */private final int threadLocalHashCode = nextHashCode(); 2.通过 key.threadLocalHashCode &amp; (len -1) 定位到table的位置i，假设table中i位置的元素为f。 3.如果f != null，假设f中的引用为k： 如果k和当前ThreadLocal实例一致，则修改value值，返回。 如果k为null，说明这个f已经是stale(陈旧的)的元素。调用replaceStaleEntry方法删除table中所有陈旧的元素（即entry的引用为null）并插入新元素，返回。 否则通过nextIndex方法找到下一个元素f，继续进行步骤3。 4.如果f == null，则把Entry加入到table的i位置中。 5.通过cleanSomeSlots删除陈旧的元素，如果table中没有元素删除，需判断当前情况下是否要进行扩容。 /** * ThreadLocal 类中 */private static AtomicInteger nextHashCode = new AtomicInteger();private static int nextHashCode() &#123; return nextHashCode.getAndAdd(HASH_INCREMENT);&#125; 从nextHashCode方法可以看出，ThreadLocal每实例化一次，其hash值就原子增加HASH_INCREMENT。 Entry从table数组中取出在回看getEntry()方法，就简单多了：/** * ThreadLocalMap的getEntry()方法 */private Entry getEntry(ThreadLocal&lt;?&gt; key) &#123; int i = key.threadLocalHashCode &amp; (table.length - 1); Entry e = table[i]; if (e != null &amp;&amp; e.get() == key) return e; else return getEntryAfterMiss(key, i, e);&#125; 1.通过key.threadLocalHashCode &amp; (len -1)定位到table的位置i，假设table中i位置的元素为g。 2.如果g不为null，且和当前ThreadLocal实例一致，则返回这个Entry。 在看一遍ThreadLocal.get()的代码：//同一线程中再次执行ThreadLocal.get()public T get() &#123; Thread t = Thread.currentThread();//得到当前子线程 ThreadLocalMap map = getMap(t); //同一个线程，map不为空 if (map != null) &#123; //当前ThreadLocal实例一致，则Entry不为null ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) &#123; @SuppressWarnings(\"unchecked\") T result = (T)e.value; return result; &#125; &#125; return setInitialValue();&#125; 所以，同一个线程，ThreadLocalMap不为空，Entry不为null，则返回table中保存的result。不会执行到setInitialValue()。所以，而SimpleDateFormat则会每一个线程只有一个。 由此，就可以得出结论了，确实可以使用ThreadLocal解决SimpleDateFormat的线程安全问题。 p.s. 感兴趣的可以结合ThreadLocal源码继续研究下面的内容： 获取当前的线程的threadLocals。 如果threadLocals不为null，则通过ThreadLocalMap.getEntry方法找到对应的entry，如果其引用和当前key一致，则直接返回，否则在table剩下的元素中继续匹配。 如果threadLocals为null，则通过setInitialValue方法初始化，并返回。private Entry getEntryAfterMiss(ThreadLocal&lt;?&gt; key, int i, Entry e) &#123; Entry[] tab = table; int len = tab.length; while (e != null) &#123; ThreadLocal&lt;?&gt; k = e.get(); if (k == key) return e; if (k == null) expungeStaleEntry(i); else i = nextIndex(i, len); e = tab[i]; &#125; return null;&#125; table扩容如果table中的元素数量达到阈值threshold的3/4，会进行扩容操作，过程很简单： /** * 在ThreadLocalMap类中 */private void resize() &#123; Entry[] oldTab = table; int oldLen = oldTab.length; int newLen = oldLen * 2; Entry[] newTab = new Entry[newLen]; int count = 0; for (int j = 0; j &lt; oldLen; ++j) &#123; Entry e = oldTab[j]; if (e != null) &#123; ThreadLocal&lt;?&gt; k = e.get(); if (k == null) &#123; e.value = null; // Help the GC &#125; else &#123; int h = k.threadLocalHashCode &amp; (newLen - 1); while (newTab[h] != null) h = nextIndex(h, newLen); newTab[h] = e; count++; &#125; &#125; &#125; setThreshold(newLen); size = count; table = newTab;&#125; 新建新的数组newTab，大小为原来的2倍。 复制table的元素到newTab，忽略陈旧的元素，假设table中的元素e需要复制到newTab的i位置，如果i位置存在元素，则找下一个空位置进行插入。 文章到这里就结束了，没有更多了:） 文章内容部分来自互联网，部分为自己整理，最后感谢耐心看到这里的人， 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/11/ThreadLocal-usage/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"ThreadLocal","slug":"threadlocal","permalink":"http://agehua.github.io/tags/threadlocal/"}]},{"title":"Hexo 模板学习——Hexo 结构","slug":"hexo-learning1","date":"2016-12-05T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2016/12/06/hexo-learning1/","link":"","permalink":"http://agehua.github.io/2016/12/06/hexo-learning1/","excerpt":"起步Hexo会读取根目录下的_config.yml里面的theme属性, 从而采用对应的主题。而主题都是放在themes/目录下面的，然后你会发现他里面有个landscape的目录，这个就是默认主题啦。\n接着，我们查看themes/landscape/目录，以及根据文档docs-themes，我们很容易得出：一个主题其实由4部分组成。\n\n_config.yml: 主题的配置文件\nsource/: 放我们的CSS文件以及图片\nlayout/: 模板文件\nscripts: 放JavaScript文件，他们会自动加载\n\n根据文档docs-templates，下面表格中每个页面都有一个可用的模板，可以没有这些模板，但至少要有一个index模板。","text":"起步Hexo会读取根目录下的_config.yml里面的theme属性, 从而采用对应的主题。而主题都是放在themes/目录下面的，然后你会发现他里面有个landscape的目录，这个就是默认主题啦。 接着，我们查看themes/landscape/目录，以及根据文档docs-themes，我们很容易得出：一个主题其实由4部分组成。 _config.yml: 主题的配置文件 source/: 放我们的CSS文件以及图片 layout/: 模板文件 scripts: 放JavaScript文件，他们会自动加载 根据文档docs-templates，下面表格中每个页面都有一个可用的模板，可以没有这些模板，但至少要有一个index模板。 Template Page Fallback index Home page post Posts index page Pages index archive Archives index category Category archives archive tag Tag archives archive 每次当我们在浏览器访问时，Hexo都会去解析sources目录下对应的模板文件。不同的URL对应不同的文件，所以才有了不同的页面。那么，我们怎么知道哪个URL对应哪个页面呢？(下面我们以EJS为例) 无论URL是什么，Hexo先读取layout.ejs，然后里面的body变量会替换成上面表格里的模板：(Fallback的意思是如果访问/archives时，我们的archives.ejs不存在的话，就会返回index.ejs) 布局编写布局文件(layout.ejs)模板文件在layout文件夹下，文件名对应Hexo中的模板名，有index,post,page,archive,category,tag几种，对于普通的header + content + footer的页面结构，header和footer往往是可以复用的，因此我们可以使用layout.ejs进行布局，动态的内容使用body变量去动态渲染，所以我的layout.ejs大概长这样: &lt;!doctype html&gt;&lt;html lang=\"en\"&gt;&lt;head&gt; &lt;meta charset=\"UTF-8\"&gt; &lt;meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0, user-scalable=no\"/&gt; &lt;title&gt;&lt;%= config.title %&gt;&lt;/title&gt; &lt;%- css('css/style') %&gt;&lt;/head&gt;&lt;body&gt; &lt;%- partial('_partial/header') %&gt; &lt;div class=\"main\"&gt; &lt;%- body %&gt; &lt;/div&gt; &lt;%- partial('_partial/footer') %&gt; &lt;%- js('js/index.js') %&gt;&lt;/body&gt;&lt;/html&gt; partial,js和css是Hexo提供的辅助函数，后面再说。 其他模板文件每一个模板文件对应的是一种布局，当你使用hexo new 的时候，其实忽略了一个参数，完整的命令是hexo new [layout] ，这个layout就决定了文章使用何种方式布局，比如创建一个自己简介的About页面，hexo new page “about”其实就是使用了page布局。每种布局对应到我们的模板文件上就是index.ejs(首页),post.ejs(文章),archive.ejs(归档),tag.ejs(标签归档),page.ejs(分页)。 index.ejs首页一般是一些博文的摘要和一个分页器，通过Hexo的page变量拿到页面的数据渲染即可，这里我们不直接在index.ejs中写HTML结构，新建一个_partial/article.ejs，将文章数据传给子模板渲染，然后再额外传入一个参数{index: true}，对后面的post.ejs和page.ejs加以区分，让子模板能正确渲染。最后，index.ejs大致是这样的: //index.ejs&lt;% page.posts.each(function(post, index)&#123; %&gt; &lt;%- partial('_partial/article', &#123;index: true, post: post&#125;) %&gt;&lt;% &#125;) %&gt;&lt;div class=\"pagination\"&gt; &lt;%- paginator(&#123; total: Math.ceil(site.posts.length / config.per_page)&#125;) %&gt;&lt;/div&gt; post.ejs文章模板和首页差不多，只是对应的是一篇具体的文章，所以就把文章传入，再额外传入{index: false}告诉子模板不要按首页的方式去渲染就好了。就一行代码(因为都在子模板里 XD //post.ejs&lt;%- partial('_partial/article', &#123;index: false, post: page&#125;) %&gt; page.ejs我个人对Page模板其实是有点懵逼的，在我自己的实践中是添加about(hexo new page “about”)页面后，访问/about会走分页布局，实际上这个页面对应的内容是/source/about里的index.md，也相当于对文章的渲染，因此我把Page模板也写成了和文章模板一样: //page.ejs&lt;%- partial('_partial/article', &#123;index: false, post: page&#125;) %&gt;_partial/article.ejs 前面一共有三处共用了article模板，另外page和post的一样的，所以实际上只有两种情况:主页(index: true)和非主页(index: false)。对应的_partial/article.ejs里只要判断这个值就可以正确渲染了，基本结构如下： //_partial/article.ejs&lt;% if(index)&#123; %&gt; //index logic...&lt;% &#125;else&#123; %&gt; //post or page logic...&lt;% &#125; %&gt; tag.ejs标签归档页内容很少，直接用Hexo的辅助函数list_tags生成一个标签的列表就ok了: //tag.ejs&lt;%- list_tags() %&gt; 归档页模板和首页差不多，归档页只需要展示文章标题和最后的分页器就好: //archive.ejs&lt;div class=\"archive\"&gt; &lt;% var lastyear; %&gt; &lt;% page.posts.each(function(post)&#123; %&gt; &lt;% var year = post.date.year() %&gt; &lt;% if(lastyear !== year)&#123; %&gt; &lt;h4 class=\"year\"&gt;&lt;%= year %&gt;&lt;/h4&gt; &lt;% lastyear = year %&gt; &lt;% &#125; %&gt; &lt;div class=\"archive_item\"&gt; &lt;a class=\"title\" href=\"&lt;%- url_for(post.path) %&gt;\"&gt;&lt;%= post.title %&gt;&lt;/a&gt; &lt;span class=\"date\"&gt;&lt;%= post.date.format('YYYY-MM-DD') %&gt;&lt;/span&gt; &lt;/div&gt; &lt;% &#125;) %&gt; &lt;div class=\"pagination\"&gt; &lt;%- paginator(&#123; total: Math.ceil(site.posts.length / config.per_page)&#125;) %&gt; &lt;/div&gt;&lt;/div&gt; 至此，模板文件就写好了，对于category模板就放弃了，感觉比较鸡肋。。。 变量其实在模板文件中我们已经看到了page.post,site.posts.length,config.per_page等等，页面的内容就是根据这些变量获取的，由Hexo提供，拿来直接用，Hexo提供了很多变量，但不是都很常用，一般就用到以下变量: site: 对应整个网站的变量，一般会用到site.posts.length制作分页器 page: 对应当前页面的信息，例如我在index.ejs中使用page.posts获取了当前页面的所有文章而不是使用site.posts。 config: 博客的配置信息，博客根目录下的_config.yml。 theme: 主题的配置信息，对于主题根目录下的_config.yml。 辅助函数(Helper)制作一个分页器，我们需要知道文章的总数和每页展示的文章数，然后通过循环生成每个link标签，还要根据当前页面判断link标签的active状态，但是在Hexo中这些都不用我们自己来做了!Hexo提供了paginator这一辅助函数帮助我们生成分页器，只需要将文章总数site.posts.length和每页文章数config.per_page传入就可以生成了。 其他的Helper: list_tags([options]): 快速生成标签列表 js(path/to/js), css(path/to/css) 用来载入静态资源，path可以是字符串或数组(载入多个资源)，默认会去source文件夹下去找。 partial(path/to/partial) 引用字模板，默认会去layout文件夹下找。 样式知道了Hexo的渲染方式，我们就可以使用HTML标签+CSS样式个性化我们的主题了，推荐大家使用CSS预处理语言的一种来写样式，这样就可以通过预处理语言自身的特点让样式更灵活。 其他添加对多说和Disqus的支持评论是很常用的功能，不如就直接在我们的主题里支持了，然后通过配置变量决定是否开启，评论区跟在文章内容下面，对于这种三方的代码块，最好也以partial的方式提取出来，方便移除或是替换。 //_partial/article.ejs&lt;section class='post-content'&gt; &lt;%- post.content %&gt;&lt;/section&gt;//评论部分，post.comments判断是否开启评论，config.duoshuo_shortname和config.disqus_shortname来判断启用那种评论插件，这里优先判断了多说&lt;% if(post.comments)&#123; %&gt; &lt;section id=\"comments\"&gt; &lt;% if (config.duoshuo_shortname)&#123; %&gt; &lt;%- partial('_partial/duoshuo') %&gt; &lt;% &#125;else if(config.disqus_shortname)&#123; %&gt; &lt;%- partial('_partial/disqus') %&gt; &lt;% &#125; %&gt; &lt;/section&gt;&lt;% &#125; %&gt; 再将多说和Disqus提供的js脚本代码放在_partial/duoshuo.ejs和_partial/disqus.ejs下就ok了~ 使用highlight.js提供代码高亮highlight.js提供了多种语言的支持和多种皮肤，用法也很简单，载入文件后调用初始化方法，一切都帮你搞定，对于使用那种皮肤，喜好因人而异，我们干脆在主题的配置文件中做成配置项让用户自己选择: //showonne/_config.yml...other configs# highlight.jshighlight_theme: zenburn 对应的layout.ejs中: &lt;link rel=\"stylesheet\" href=\"//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.4.0/styles/&lt;%= theme.highlight_theme %&gt;.min.css\"&gt; 样式文件通过CDN引入，因为不同皮肤对应不同的文件名，所以十分灵活。 最后当初是对应着landscape照葫芦画瓢写的，最近回头来发现一些不合理的地方，所以就又改了改，也对应着写了这么一篇总结，接下来准备再把样式划分一下，对于颜色这类样式通过变量的方式提取出来，也变得可配置，能让主题更灵活一些。 参考资源 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/06/hexo-learning1/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Hexo","slug":"hexo","permalink":"http://agehua.github.io/tags/hexo/"},{"name":"Hexo structure","slug":"hexo-structure","permalink":"http://agehua.github.io/tags/hexo-structure/"}]},{"title":"Hexo 模板学习——EJS介绍","slug":"hexo-learning0","date":"2016-12-03T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/12/04/hexo-learning0/","link":"","permalink":"http://agehua.github.io/2016/12/04/hexo-learning0/","excerpt":"什么是EJS？EJS是JavaScript模板库，用来从JSON数据中生成HTML字符串\nEJS的语法和功能：1、缓存功能，能够缓存已经解析好的html模版2、&lt;% code %&gt;用于执行其中javascript代码。&lt;% alert('hello world') %&gt;\n3、&lt;%= code =%&gt;会对code进行html转义；","text":"什么是EJS？EJS是JavaScript模板库，用来从JSON数据中生成HTML字符串 EJS的语法和功能：1、缓存功能，能够缓存已经解析好的html模版2、&lt;% code %&gt;用于执行其中javascript代码。&lt;% alert('hello world') %&gt; 3、&lt;%= code =%&gt;会对code进行html转义； &lt;h1&gt;&lt;%=title %&gt;&lt;/h1&gt; 注：会把title里面存的值给显示出来在h1中。&lt;p&gt;&lt;%= 'hello world' %&gt;&lt;/p&gt; 注：会把hello world显示在h1中。&lt;h1&gt;&lt;%= '&lt;b&gt;hello world&lt;/b&gt;' %&gt;&lt;/h1&gt; 注：会把hello world变粗，然后显示在h1中。 4、&lt;%- code %&gt;将不会进行转义；，这一行代码不会执行，像是被注释了一样，然后显示原来的html。也不会影响整个页面的执行。&lt;h1&gt;&lt;%-title %&gt;asd&lt;/h1&gt; 最后显示asd，及显示原网页&lt;p&gt;&lt;%# 'hello world' %&gt;asd&lt;/p&gt; 最后显示asd，及显示原网页 5、支持自定义标签，比如’&lt;%’可以使用’NaN‘代替；ejs 里，默认的闭合标记是 &lt;% .. %&gt;，我们也可以定义自己的标签。例如： app.set(\"view options\",&#123; \"open\":\"&#123;&#123;\", \"close\":\"&#125;&#125;\"&#125;); 6、提供一些辅助函数，用于模版中使用 1)、first，返回数组的第一个元素； 2)、last，返回数组的最后一个元素； 3)、capitalize，返回首字母大写的字符串； 4)、downcase，返回字符串的小写； 5)、upcase，返回字符串的大写； 6)、sort，排序（Object.create(obj).sort()？）； 7)、sort_by:’prop’，按照指定的prop属性进行升序排序； 8)、size，返回长度，即length属性，不一定非是数组才行； 9)、plus:n，加上n，将转化为Number进行运算； 10)、minus:n，减去n，将转化为Number进行运算； 11)、times:n，乘以n，将转化为Number进行运算； 12)、divided_by:n，除以n，将转化为Number进行运算； 13)、join:’val’，将数组用’val’最为分隔符，进行合并成一个字符串； 14)、truncate:n，截取前n个字符，超过长度时，将返回一个副本 15)、truncate_words:n，取得字符串中的前n个word，word以空格进行分割； 16)、replace:pattern,substitution，字符串替换，substitution不提供将删除匹配的子串； 17)、prepend:val，如果操作数为数组，则进行合并；为字符串则添加val在前面； 18)、append:val，如果操作数为数组，则进行合并；为字符串则添加val在后面； 19)、map:’prop’，返回对象数组中属性为prop的值组成的数组； 20)、reverse，翻转数组或字符串； 21)、get:’prop’，取得属性为’prop’的值； 22)、json，转化为json格式字符串 利用&lt;%- include filename %&gt;加载其他页面模版； ejs我的总结：ejs 写法： 1.普通传入并使用变量： &lt;%= title %&gt; 2.普通for执行js代码（for中间的代码一定可以执行到）： &lt;% for(var i=0; i&lt;headerNavbar.length; i++) &#123;%&gt; &lt;li&gt;&lt;a href=\"/reg\"&gt;&lt;%= headerNavbar[i].name %&gt;&lt;/a&gt;&lt;/li&gt;&lt;% &#125; %&gt; 3.特殊if语句的js代码（if中间的额代码不一定可以执行到）： &lt;% if(active=='index')&#123;%&gt;class=\"active\" &lt;% &#125;%&gt; stylus介绍部分内容转载自：stylus入门使用方法 stylus项目地址：http://stylus-lang.com/ Stylus 是一个CSS的预处理框架，2010年产生，来自Node.js社区，主要用来给Node项目进行CSS预处理支持，所以 Stylus 是一种新型语言，可以创建健壮的、动态的、富有表现力的CSS。比较年轻，其本质上做的事情与 SASS/LESS 等类似，应该是有很多借鉴，所以近似脚本的方式去写CSS代码。 Stylus功能上更为强壮，和js联系更加紧密（EXPRESSIVE, DYNAMIC, ROBUST CSS） Stylus安装使用node包管理器，全局安装$ npm install stylus -g 生成CSS建立一个stylusExample/，再在里面建立 src 目录专门存放 stylus 文件，在里面建立 example.styl 文件。然后在 stylusExample 目录下面执行下面命令$ stylus --compress src/ 输出compiled src/example.css ，这个时候表示你生成成功了，带上–compress参数表示你生成压缩的CSS文件。$ stylus --css css/example.css css/out.styl CSS转换成styl$ stylus help box-shadow CSS属性的帮助$ stylus --css test.css 输出基本名一致的.styl文件 具体语法和应用可以参考: Stylus中文参考文档 CSS3 column多列布局介绍CSS3提供了个新属性columns用于多列布局。在这之前，有些大家习以为常的排版，要用CSS动态实现其实是比较困难的。如竖版报纸 Columns属性最大的问题还是浏览器兼容性问题摘选自：CSS3 column多列布局介绍 栅格与响应式设计栅格样式库一般是这样做的：将页面划分为若干等宽的列（column），然后推荐你通过等宽列来创建响应式的页面区块。 虽然看起来都是这样的思路，但不同的栅格样式库，在做法上却是各有各的点子。下面，本文将介绍几个比较有代表性的栅格样式库，讲述它们的简要原理和用法 Bootstrap中的栅格:Bootstrap把它的栅格放在CSS这个分类下，并称它为Gird system。默认分为12列。 要理解Bootstrap中的栅格，最好从掌握正确的使用方法开始。这其中有2个要点。 第1个要点是容器（container），行（row）和列（column）之间的层级关系。一个正确的写法示例如下： &lt;div class=\"container\"&gt; &lt;div class=\"row\"&gt; &lt;div class=\"col-md-6\"&gt;&lt;/div&gt; &lt;div class=\"col-md-6\"&gt;&lt;/div&gt; &lt;/div&gt;&lt;/div&gt; 第2个要点，是不同的断点类型的意义及其搭配。 Bootstrap栅格的column对应的类名形如.col-xx-y。y是数字，表示该元素的宽度占据12列中的多少列。而xx只有特定的几个值可供选择，分别是xs、sm、md、lg，它们就是断点类型。 在Bootstrap栅格的设计中，断点的意义是，当视口（viewport）宽度小于断点时，column将竖直堆叠（display: block的默认表现），而当视口宽度大于或等于断点时，column将水平排列（float的效果）。按照xs、sm、md、lg的顺序，断点像素值依次增大，其中xs表示极小，即认为视口宽度永远不小于xs断点，column将始终水平浮动。 Foundation中的栅格Foundation栅格叫做Grid，它和Bootstrap栅格的设计十分近似，只是在类名和结构上有所差异。Foundation栅格同样默认12列。 行与列类比之前Bootstrap栅格的例子，Foundation栅格的一个正确的写法示例如下：&lt;div class=\"row\"&gt; &lt;div class=\"medium-6 columns\"&gt;&lt;/div&gt; &lt;div class=\"medium-6 columns\"&gt;&lt;/div&gt;&lt;/div&gt; Foundation栅格的行用.row表示，而列由至少两个类名组成，一是.columns或.column（2种写法完全相同，单纯为了支持语法偏好）表明这是列元素，二是.medium-6这种用于表示断点类型和对应宽度。在默认情况下，Foundation栅格的断点类型从小到大依次是small、medium、large，其中small类似Bootstrap栅格的xs，也是指任意屏幕尺寸下都水平排列。 Foundation栅格没有container，只需要row和column，因此显得比Bootstrap栅格更简单一些。其中row定义了最大宽度（可以认为承担了container的部分功能），column定义了0.9375rem的水平内边距。如果要嵌套，仍然是column内续接row，再继续接column。 组合使用多个断点类型，其方法也和Bootstrap栅格相同。需要注意的是，Foundation栅格的断点值是用的em而不是px，对应的，它们转换后的像素值也有别于Bootstrap栅格。 Block Grid作为栅格系统的补充，Foundation还提供了另外一个叫做Block Grid的栅格。不过，它并不是一个超出传统栅格的新东西，而只是一个针对特定栅格应用场景的方法糖。 摘选自：有关css栅格系统的故事 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/04/hexo-learning0/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Hexo","slug":"hexo","permalink":"http://agehua.github.io/tags/hexo/"},{"name":"EJS","slug":"ejs","permalink":"http://agehua.github.io/tags/ejs/"}]},{"title":"nodejs入门","slug":"nodejs-learning-getting-started","date":"2016-12-02T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/12/03/nodejs-learning-getting-started/","link":"","permalink":"http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/","excerpt":"\n本文是我自己的学习笔记，整理自《Node入门》\n\nNode入门作者： Manuel Kiessling翻译： goddyzhao &amp; GrayZhang &amp; MondayChen\n本书致力于教会你如何用Node.js来开发应用，过程中会传授你所有所需的“高级”JavaScript知识。本书绝不是一本“Hello World”的教程。\n服务端JavaScriptJavaScript最早是运行在浏览器中，然而浏览器只是提供了一个上下文，它定义了使用JavaScript可以做什么，但并没有“说”太多关于JavaScript语言本身可以做什么。事实上，JavaScript是一门“完整”的语言： 它可以使用在不同的上下文中，其能力与其他同类语言相比有过之而无不及。\nNode.js事实上就是另外一种上下文，它允许在后端（脱离浏览器环境）运行JavaScript代码。","text":"本文是我自己的学习笔记，整理自《Node入门》 Node入门作者： Manuel Kiessling翻译： goddyzhao &amp; GrayZhang &amp; MondayChen 本书致力于教会你如何用Node.js来开发应用，过程中会传授你所有所需的“高级”JavaScript知识。本书绝不是一本“Hello World”的教程。 服务端JavaScriptJavaScript最早是运行在浏览器中，然而浏览器只是提供了一个上下文，它定义了使用JavaScript可以做什么，但并没有“说”太多关于JavaScript语言本身可以做什么。事实上，JavaScript是一门“完整”的语言： 它可以使用在不同的上下文中，其能力与其他同类语言相比有过之而无不及。 Node.js事实上就是另外一种上下文，它允许在后端（脱离浏览器环境）运行JavaScript代码。 要实现在后台运行JavaScript代码，代码需要先被解释然后正确的执行。Node.js的原理正是如此，它使用了Google的V8虚拟机（Google的Chrome浏览器使用的JavaScript执行环境），来解释和执行JavaScript代码。 除此之外，伴随着Node.js的还有许多有用的模块，它们可以简化很多重复的劳作，比如向终端输出字符串。 因此，Node.js事实上既是一个运行时环境，同时又是一个库。 要使用Node.js,首先需要进行安装。关于如何安装Node.js，这里就不赘述了，可以直接参考官方的安装指南。安装完成后，继续回来阅读本书下面的内容。 “Hello World”好了，“废话”不多说了，马上开始我们第一个Node.js应用：“Hello World”。 打开你最喜欢的编辑器，创建一个helloworld.js文件。我们要做就是向STDOUT输出“Hello World”，如下是实现该功能的代码： console.log(\"Hello World\"); 保存该文件，并通过Node.js来执行：node helloworld.js 正常的话，就会在终端输出Hello World 。 好吧，我承认这个应用是有点无趣，那么下面我们就来点“干货”。 一个完整的基于Node.js的web应用用例我们来把目标设定得简单点，不过也要够实际才行： 用户可以通过浏览器使用我们的应用。当用户请求http://domain/start 时，可以看到一个欢迎页面，页面上有一个文件上传的表单。用户可以选择一个图片并提交表单，随后文件将被上传到http://domain/upload ，该页面完成上传后会把图片显示在页面上。差不多了，你现在也可以去Google一下，找点东西乱搞一下来完成功能。但是我们现在先不做这个。 更进一步地说，在完成这一目标的过程中，我们不仅仅需要基础的代码而不管代码是否优雅。我们还要对此进行抽象，来寻找一种适合构建更为复杂的Node.js应用的方式。 应用不同模块分析我们来分解一下这个应用，为了实现上文的用例，我们需要实现哪些部分呢？ 我们需要提供Web页面，因此需要一个HTTP服务器对于不同的请求，根据请求的URL，我们的服务器需要给予不同的响应，因此我们需要一个路由，用于把请求对应到请求处理程序（request handler）当请求被服务器接收并通过路由传递之后，需要可以对其进行处理，因此我们需要最终的请求处理程序路由还应该能处理POST数据，并且把数据封装成更友好的格式传递给请求处理入程序，因此需要请求数据处理功能我们不仅仅要处理URL对应的请求，还要把内容显示出来，这意味着我们需要一些视图逻辑供请求处理程序使用，以便将内容发送给用户的浏览器最后，用户需要上传图片，所以我们需要上传处理功能来处理这方面的细节我们先来想想，使用PHP的话我们会怎么构建这个结构。一般来说我们会用一个Apache HTTP服务器并配上mod_php5模块。从这个角度看，整个“接收HTTP请求并提供Web页面”的需求根本不需要PHP来处理。 不过对Node.js来说，概念完全不一样了。使用Node.js时，我们不仅仅在实现一个应用，同时还实现了整个HTTP服务器。事实上，我们的Web应用以及对应的Web服务器基本上是一样的。 听起来好像有一大堆活要做，但随后我们会逐渐意识到，对Node.js来说这并不是什么麻烦的事。 现在我们就来开始实现之路，先从第一个部分–HTTP服务器着手。 构建应用的模块一个基础的HTTP服务器当我准备开始写我的第一个“真正的”Node.js应用的时候，我不但不知道怎么写Node.js代码，也不知道怎么组织这些代码。我应该把所有东西都放进一个文件里吗？网上有很多教程都会教你把所有的逻辑都放进一个用Node.js写的基础HTTP服务器里。但是如果我想加入更多的内容，同时还想保持代码的可读性呢？ 实际上，只要把不同功能的代码放入不同的模块中，保持代码分离还是相当简单的。 这种方法允许你拥有一个干净的主文件（main file），你可以用Node.js执行它；同时你可以拥有干净的模块，它们可以被主文件和其他的模块调用。 那么，现在我们来创建一个用于启动我们的应用的主文件，和一个保存着我们的HTTP服务器代码的模块。 在我的印象里，把主文件叫做index.js或多或少是个标准格式。把服务器模块放进叫server.js的文件里则很好理解。 让我们先从服务器模块开始。在你的项目的根目录下创建一个叫server.js的文件，并写入以下代码： var http = require(\"http\");http.createServer(function(request, response) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;).listen(8888); 搞定！你刚刚完成了一个可以工作的HTTP服务器。为了证明这一点，我们来运行并且测试这段代码。首先，用Node.js执行你的脚本： node server.js 接下来，打开浏览器访问http://localhost:8888/ ，你会看到一个写着“Hello World”的网页。 这很有趣，不是吗？让我们先来谈谈HTTP服务器的问题，把如何组织项目的事情先放一边吧，你觉得如何？我保证之后我们会解决那个问题的。 分析HTTP服务器那么接下来，让我们分析一下这个HTTP服务器的构成。 第一行请求（require）Node.js自带的 http 模块，并且把它赋值给 http 变量。 接下来我们调用http模块提供的函数： createServer 。这个函数会返回一个对象，这个对象有一个叫做 listen 的方法，这个方法有一个数值参数，指定这个HTTP服务器监听的端口号。 咱们暂时先不管 http.createServer 的括号里的那个函数定义。 我们本来可以用这样的代码来启动服务器并侦听8888端口：var http = require(\"http\");var server = http.createServer();server.listen(8888); 这段代码只会启动一个侦听8888端口的服务器，它不做任何别的事情，甚至连请求都不会应答。 最有趣（而且，如果你之前习惯使用一个更加保守的语言，比如PHP，它还很奇怪）的部分是 createServer() 的第一个参数，一个函数定义。 实际上，这个函数定义是 createServer() 的第一个也是唯一一个参数。因为在JavaScript中，函数和其他变量一样都是可以被传递的。 进行函数传递举例来说，你可以这样做： function say(word) &#123; console.log(word);&#125;function execute(someFunction, value) &#123; someFunction(value);&#125;execute(say, \"Hello\"); 请仔细阅读这段代码！在这里，我们把 say 函数作为execute函数的第一个变量进行了传递。这里传递的不是 say 的返回值，而是 say 本身！ 这样一来， say 就变成了execute 中的本地变量 someFunction ，execute可以通过调用 someFunction() （带括号的形式）来使用 say 函数。 当然，因为 say 有一个变量， execute 在调用 someFunction 时可以传递这样一个变量。 我们可以，就像刚才那样，用它的名字把一个函数作为变量传递。但是我们不一定要绕这个“先定义，再传递”的圈子，我们可以直接在另一个函数的括号中定义和传递这个函数： function execute(someFunction, value) &#123; someFunction(value);&#125;execute(function(word)&#123; console.log(word) &#125;, \"Hello\"); 我们在 execute 接受第一个参数的地方直接定义了我们准备传递给 execute 的函数。 用这种方式，我们甚至不用给这个函数起名字，这也是为什么它被叫做 匿名函数 。 这是我们和我所认为的“进阶”JavaScript的第一次亲密接触，不过我们还是得循序渐进。现在，我们先接受这一点：在JavaScript中，一个函数可以作为另一个函数接收一个参数。我们可以先定义一个函数，然后传递，也可以在传递参数的地方直接定义函数。 函数传递是如何让HTTP服务器工作的带着这些知识，我们再来看看我们简约而不简单的HTTP服务器： var http = require(\"http\");http.createServer(function(request, response) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;).listen(8888); 现在它看上去应该清晰了很多：我们向 createServer 函数传递了一个匿名函数。 用这样的代码也可以达到同样的目的： var http = require(\"http\");function onRequest(request, response) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;http.createServer(onRequest).listen(8888); 也许现在我们该问这个问题了：我们为什么要用这种方式呢？ 基于事件驱动的回调这个问题可不好回答（至少对我来说），不过这是Node.js原生的工作方式。它是事件驱动的，这也是它为什么这么快的原因。 你也许会想花点时间读一下Felix Geisendörfer的大作Understanding node.js，它介绍了一些背景知识。 这一切都归结于“Node.js是事件驱动的”这一事实。好吧，其实我也不是特别确切的了解这句话的意思。不过我会试着解释，为什么它对我们用Node.js写网络应用（Web based application）是有意义的。 当我们使用 http.createServer 方法的时候，我们当然不只是想要一个侦听某个端口的服务器，我们还想要它在服务器收到一个HTTP请求的时候做点什么。 问题是，这是异步的：请求任何时候都可能到达，但是我们的服务器却跑在一个单进程中。 写PHP应用的时候，我们一点也不为此担心：任何时候当有请求进入的时候，网页服务器（通常是Apache）就为这一请求新建一个进程，并且开始从头到尾执行相应的PHP脚本。 那么在我们的Node.js程序中，当一个新的请求到达8888端口的时候，我们怎么控制流程呢？ 嗯，这就是Node.js/JavaScript的事件驱动设计能够真正帮上忙的地方了——虽然我们还得学一些新概念才能掌握它。让我们来看看这些概念是怎么应用在我们的服务器代码里的。 我们创建了服务器，并且向创建它的方法传递了一个函数。无论何时我们的服务器收到一个请求，这个函数就会被调用。 我们不知道这件事情什么时候会发生，但是我们现在有了一个处理请求的地方：它就是我们传递过去的那个函数。至于它是被预先定义的函数还是匿名函数，就无关紧要了。 这个就是传说中的 回调 。我们给某个方法传递了一个函数，这个方法在有相应事件发生时调用这个函数来进行 回调 。 至少对我来说，需要一些功夫才能弄懂它。你如果还是不太确定的话就再去读读Felix的博客文章。 让我们再来琢磨琢磨这个新概念。我们怎么证明，在创建完服务器之后，即使没有HTTP请求进来、我们的回调函数也没有被调用的情况下，我们的代码还继续有效呢？我们试试这个： var http = require(\"http\");function onRequest(request, response) &#123; console.log(\"Request received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;http.createServer(onRequest).listen(8888);console.log(\"Server has started.\"); 注意：在 onRequest （我们的回调函数）触发的地方，我用 console.log 输出了一段文本。在HTTP服务器开始工作之后，也输出一段文本。 当我们与往常一样，运行它node server.js时，它会马上在命令行上输出“Server has started.”。当我们向服务器发出请求（在浏览器访问http://localhost:8888/ ），“Request received.”这条消息就会在命令行中出现。 这就是事件驱动的异步服务器端JavaScript和它的回调啦！ （请注意，当我们在服务器访问网页时，我们的服务器可能会输出两次“Request received.”。那是因为大部分浏览器都会在你访问 http://localhost:8888/ 时尝试读取 http://localhost:8888/favicon.ico ) 服务器是如何处理请求的好的，接下来我们简单分析一下我们服务器代码中剩下的部分，也就是我们的回调函数 onRequest() 的主体部分。 当回调启动，我们的 onRequest() 函数被触发的时候，有两个参数被传入： request 和 response 。 它们是对象，你可以使用它们的方法来处理HTTP请求的细节，并且响应请求（比如向发出请求的浏览器发回一些东西）。 所以我们的代码就是：当收到请求时，使用 response.writeHead() 函数发送一个HTTP状态200和HTTP头的内容类型（content-type），使用 response.write() 函数在HTTP相应主体中发送文本“Hello World”。 最后，我们调用 response.end() 完成响应。 目前来说，我们对请求的细节并不在意，所以我们没有使用 request 对象。 服务端的模块放在哪里 OK，就像我保证过的那样，我们现在可以回到我们如何组织应用这个问题上了。我们现在在 server.js 文件中有一个非常基础的HTTP服务器代码，而且我提到通常我们会有一个叫 index.js 的文件去调用应用的其他模块（比如 server.js 中的HTTP服务器模块）来引导和启动应用。 我们现在就来谈谈怎么把server.js变成一个真正的Node.js模块，使它可以被我们（还没动工）的 index.js 主文件使用。 也许你已经注意到，我们已经在代码中使用了模块了。像这样： var http = require(\"http\");...http.createServer(...); Node.js中自带了一个叫做“http”的模块，我们在我们的代码中请求它并把返回值赋给一个本地变量。 这把我们的本地变量变成了一个拥有所有 http 模块所提供的公共方法的对象。 给这种本地变量起一个和模块名称一样的名字是一种惯例，但是你也可以按照自己的喜好来： var foo = require(\"http\");...foo.createServer(...); 很好，怎么使用Node.js内部模块已经很清楚了。我们怎么创建自己的模块，又怎么使用它呢？ 等我们把 server.js 变成一个真正的模块，你就能搞明白了。 事实上，我们不用做太多的修改。把某段代码变成模块意味着我们需要把我们希望提供其功能的部分 导出 到请求这个模块的脚本。 目前，我们的HTTP服务器需要导出的功能非常简单，因为请求服务器模块的脚本仅仅是需要启动服务器而已。 我们把我们的服务器脚本放到一个叫做 start 的函数里，然后我们会导出这个函数。 var http = require(\"http\");function start() &#123; function onRequest(request, response) &#123; console.log(\"Request received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 这样，我们现在就可以创建我们的主文件 index.js 并在其中启动我们的HTTP了，虽然服务器的代码还在 server.js 中。 创建 index.js 文件并写入以下内容： var server = require(\"./server\");server.start(); 正如你所看到的，我们可以像使用任何其他的内置模块一样使用server模块：请求这个文件并把它指向一个变量，其中已导出的函数就可以被我们使用了。 好了。我们现在就可以从我们的主要脚本启动我们的的应用了，而它还是老样子： node index.js 非常好，我们现在可以把我们的应用的不同部分放入不同的文件里，并且通过生成模块的方式把它们连接到一起了。 我们仍然只拥有整个应用的最初部分：我们可以接收HTTP请求。但是我们得做点什么——对于不同的URL请求，服务器应该有不同的反应。 对于一个非常简单的应用来说，你可以直接在回调函数 onRequest() 中做这件事情。不过就像我说过的，我们应该加入一些抽象的元素，让我们的例子变得更有趣一点儿。 处理不同的HTTP请求在我们的代码中是一个不同的部分，叫做“路由选择”——那么，我们接下来就创造一个叫做路由的模块吧。 如何来进行请求的“路由”我们要为路由提供请求的URL和其他需要的GET及POST参数，随后路由需要根据这些数据来执行相应的代码（这里“代码”对应整个应用的第三部分：一系列在接收到请求时真正工作的处理程序）。 因此，我们需要查看HTTP请求，从中提取出请求的URL以及GET/POST参数。这一功能应当属于路由还是服务器（甚至作为一个模块自身的功能）确实值得探讨，但这里暂定其为我们的HTTP服务器的功能。 我们需要的所有数据都会包含在request对象中，该对象作为onRequest()回调函数的第一个参数传递。但是为了解析这些数据，我们需要额外的Node.JS模块，它们分别是url和querystring模块。 url.parse(string).query | url.parse(string).pathname | | | | | ------ -------------------http://localhost:8888/start?foo=bar&amp;hello=world --- ----- | | | | querystring(string)[\"foo\"] | | querystring(string)[\"hello\"] 当然我们也可以用querystring模块来解析POST请求体中的参数，稍后会有演示。 现在我们来给onRequest()函数加上一些逻辑，用来找出浏览器请求的URL路径： var http = require(\"http\");var url = require(\"url\");function start() &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 好了，我们的应用现在可以通过请求的URL路径来区别不同请求了–这使我们得以使用路由（还未完成）来将请求以URL路径为基准映射到处理程序上。 在我们所要构建的应用中，这意味着来自/start和/upload的请求可以使用不同的代码来处理。稍后我们将看到这些内容是如何整合到一起的。 现在我们可以来编写路由了，建立一个名为router.js的文件，添加以下内容： function route(pathname) &#123; console.log(\"About to route a request for \" + pathname);&#125;exports.route = route; 如你所见，这段代码什么也没干，不过对于现在来说这是应该的。在添加更多的逻辑以前，我们先来看看如何把路由和服务器整合起来。 我们的服务器应当知道路由的存在并加以有效利用。我们当然可以通过硬编码的方式将这一依赖项绑定到服务器上，但是其它语言的编程经验告诉我们这会是一件非常痛苦的事，因此我们将使用依赖注入的方式较松散地添加路由模块（你可以读读Martin Fowlers关于依赖注入的大作来作为背景知识）。 首先，我们来扩展一下服务器的start()函数，以便将路由函数作为参数传递过去： var http = require(\"http\");var url = require(\"url\");function start(route) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(pathname); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 同时，我们会相应扩展index.js，使得路由函数可以被注入到服务器中：var server = require(\"./server\");var router = require(\"./router\");server.start(router.route); 在这里，我们传递的函数依旧什么也没做。 如果现在启动应用（node index.js，始终记得这个命令行），随后请求一个URL，你将会看到应用输出相应的信息，这表明我们的HTTP服务器已经在使用路由模块了，并会将请求的路径传递给路由： bash$ node index.jsRequest for /foo received.About to route a request for /foo （以上输出已经去掉了比较烦人的/favicon.ico请求相关的部分）。 行为驱动执行请允许我再次脱离主题，在这里谈一谈函数式编程。 将函数作为参数传递并不仅仅出于技术上的考量。对软件设计来说，这其实是个哲学问题。想想这样的场景：在index文件中，我们可以将router对象传递进去，服务器随后可以调用这个对象的route函数。 就像这样，我们传递一个东西，然后服务器利用这个东西来完成一些事。 嗨那个叫路由的东西，能帮我把这个路由一下吗？ 但是服务器其实不需要这样的东西。它只需要把事情做完就行，其实为了把事情做完，你根本不需要东西，你需要的是动作。也就是说，你不需要名词，你需要动词。 理解了这个概念里最核心、最基本的思想转换后，我自然而然地理解了函数编程。 我是在读了Steve Yegge的大作名词王国中的死刑之后理解函数编程。你也去读一读这本书吧，真的。这是曾给予我阅读的快乐的关于软件的书籍之一。 路由给真正的请求处理程序回到正题，现在我们的HTTP服务器和请求路由模块已经如我们的期望，可以相互交流了，就像一对亲密无间的兄弟。 当然这还远远不够，路由，顾名思义，是指我们要针对不同的URL有不同的处理方式。例如处理/start的“业务逻辑”就应该和处理/upload的不同。 在现在的实现下，路由过程会在路由模块中“结束”，并且路由模块并不是真正针对请求“采取行动”的模块，否则当我们的应用程序变得更为复杂时，将无法很好地扩展。 我们暂时把作为路由目标的函数称为请求处理程序。现在我们不要急着来开发路由模块，因为如果请求处理程序没有就绪的话，再怎么完善路由模块也没有多大意义。 应用程序需要新的部件，因此加入新的模块 – 已经无需为此感到新奇了。我们来创建一个叫做requestHandlers的模块，并对于每一个请求处理程序，添加一个占位用函数，随后将这些函数作为模块的方法导出： function start() &#123; console.log(\"Request handler 'start' was called.\");&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\");&#125;exports.start = start;exports.upload = upload; 这样我们就可以把请求处理程序和路由模块连接起来，让路由“有路可寻”。 在这里我们得做个决定：是将requestHandlers模块硬编码到路由里来使用，还是再添加一点依赖注入？虽然和其他模式一样，依赖注入不应该仅仅为使用而使用，但在现在这个情况下，使用依赖注入可以让路由和请求处理程序之间的耦合更加松散，也因此能让路由的重用性更高。 这意味着我们得将请求处理程序从服务器传递到路由中，但感觉上这么做更离谱了，我们得一路把这堆请求处理程序从我们的主文件传递到服务器中，再将之从服务器传递到路由。 那么我们要怎么传递这些请求处理程序呢？别看现在我们只有2个处理程序，在一个真实的应用中，请求处理程序的数量会不断增加，我们当然不想每次有一个新的URL或请求处理程序时，都要为了在路由里完成请求到处理程序的映射而反复折腾。除此之外，在路由里有一大堆if request == x then call handler y也使得系统丑陋不堪。 仔细想想，有一大堆东西，每个都要映射到一个字符串（就是请求的URL）上？似乎关联数组（associative array） 能完美胜任。 不过结果有点令人失望，JavaScript没提供关联数组 – 也可以说它提供了？事实上，在JavaScript中，真正能提供此类功能的是它的对象。 在这方面，http://msdn.microsoft.com/en-us/magazine/cc163419.aspx 有一个不错的介绍，我在此摘录一段： 在C++或C#中，当我们谈到对象，指的是类或者结构体的实例。对象根据他们实例化的模板（就是所谓的类），会拥有不同的属性和方法。但在JavaScript里对象不是这个概念。在JavaScript中，对象就是一个键/值对的集合 – 你可以把JavaScript的对象想象成一个键为字符串类型的字典。 但如果JavaScript的对象仅仅是键/值对的集合，它又怎么会拥有方法呢？好吧，这里的值可以是字符串、数字或者……函数！ 好了，最后再回到代码上来。现在我们已经确定将一系列请求处理程序通过一个对象来传递，并且需要使用松耦合的方式将这个对象注入到route()函数中。 我们先将这个对象引入到主文件index.js中： var server = require(\"./server\");var router = require(\"./router\");var requestHandlers = require(\"./requestHandlers\");var handle = &#123;&#125;handle[\"/\"] = requestHandlers.start;handle[\"/start\"] = requestHandlers.start;handle[\"/upload\"] = requestHandlers.upload;server.start(router.route, handle); 虽然handle并不仅仅是一个“东西”（一些请求处理程序的集合），我还是建议以一个动词作为其命名，这样做可以让我们在路由中使用更流畅的表达式，稍后会有说明。 正如所见，将不同的URL映射到相同的请求处理程序上是很容易的：只要在对象中添加一个键为”/“的属性，对应requestHandlers.start即可，这样我们就可以干净简洁地配置/start和/的请求都交由start这一处理程序处理。 在完成了对象的定义后，我们把它作为额外的参数传递给服务器，为此将server.js修改如下： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(handle, pathname); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 这样我们就在start()函数里添加了handle参数，并且把handle对象作为第一个参数传递给了route()回调函数。 然后我们相应地在route.js文件中修改route()函数： function route(handle, pathname) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](); &#125; else &#123; console.log(\"No request handler found for \" + pathname); &#125;&#125;exports.route = route; 通过以上代码，我们首先检查给定的路径对应的请求处理程序是否存在，如果存在的话直接调用相应的函数。我们可以用从关联数组中获取元素一样的方式从传递的对象中获取请求处理函数，因此就有了简洁流畅的形如handlepathname;的表达式，这个感觉就像在前方中提到的那样：“嗨，请帮我处理了这个路径”。 有了这些，我们就把服务器、路由和请求处理程序在一起了。现在我们启动应用程序并在浏览器中访问http://localhost:8888/start，以下日志可以说明系统调用了正确的请求处理程序： Server has started.Request for /start received.About to route a request for /startRequest handler 'start' was called. 并且在浏览器中打开http://localhost:8888/可以看到这个请求同样被start请求处理程序处理了： Request for / received.About to route a request for /Request handler 'start' was called. 让请求处理程序作出响应很好。不过现在要是请求处理程序能够向浏览器返回一些有意义的信息而并非全是“Hello World”，那就更好了。 这里要记住的是，浏览器发出请求后获得并显示的“Hello World”信息仍是来自于我们server.js文件中的onRequest函数。 其实“处理请求”说白了就是“对请求作出响应”，因此，我们需要让请求处理程序能够像onRequest函数那样可以和浏览器进行“对话”。 不好的实现方式对于我们这样拥有PHP或者Ruby技术背景的开发者来说，最直截了当的实现方式事实上并不是非常靠谱： 看似有效，实则未必如此。 这里我指的“直截了当的实现方式”意思是：让请求处理程序通过onRequest函数直接返回（return()）他们要展示给用户的信息。 我们先就这样去实现，然后再来看为什么这不是一种很好的实现方式。 让我们从让请求处理程序返回需要在浏览器中显示的信息开始。我们需要将requestHandler.js修改为如下形式： function start() &#123; console.log(\"Request handler 'start' was called.\"); return \"Hello Start\";&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\"); return \"Hello Upload\";&#125;exports.start = start;exports.upload = upload; 好的。同样的，请求路由需要将请求处理程序返回给它的信息返回给服务器。因此，我们需要将router.js修改为如下形式： function route(handle, pathname) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; return handle[pathname](); &#125; else &#123; console.log(\"No request handler found for \" + pathname); return \"404 Not found\"; &#125;&#125;exports.route = route; 正如上述代码所示，当请求无法路由的时候，我们也返回了一些相关的错误信息。 最后，我们需要对我们的server.js进行重构以使得它能够将请求处理程序通过请求路由返回的内容响应给浏览器，如下所示： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); var content = route(handle, pathname) response.write(content); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 如果我们运行重构后的应用，一切都会工作的很好：请求http://localhost:8888/start, 浏览器会输出“Hello Start”，请求http://localhost:8888/upload 会输出“Hello Upload”,而请求http://localhost:8888/foo 会输出“404 Not found”。 好，那么问题在哪里呢？简单的说就是： 当未来有请求处理程序需要进行非阻塞的操作的时候，我们的应用就“挂”了。 没理解？没关系，下面就来详细解释下。 阻塞与非阻塞正如此前所提到的，当在请求处理程序中包括非阻塞操作时就会出问题。但是，在说这之前，我们先来看看什么是阻塞操作。 我不想去解释“阻塞”和“非阻塞”的具体含义，我们直接来看，当在请求处理程序中加入阻塞操作时会发生什么。 这里，我们来修改下start请求处理程序，我们让它等待10秒以后再返回“Hello Start”。因为，JavaScript中没有类似sleep()这样的操作，所以这里只能够来点小Hack来模拟实现。 让我们将requestHandlers.js修改成如下形式： function start() &#123; console.log(\"Request handler 'start' was called.\"); function sleep(milliSeconds) &#123; var startTime = new Date().getTime(); while (new Date().getTime() &lt; startTime + milliSeconds); &#125; sleep(10000); return \"Hello Start\";&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\"); return \"Hello Upload\";&#125;exports.start = start;exports.upload = upload; 上述代码中，当函数start()被调用的时候，Node.js会先等待10秒，之后才会返回“Hello Start”。当调用upload()的时候，会和此前一样立即返回。 （当然了，这里只是模拟休眠10秒，实际场景中，这样的阻塞操作有很多，比方说一些长时间的计算操作等。） 接下来就让我们来看看，我们的改动带来了哪些变化。 如往常一样，我们先要重启下服务器。为了看到效果，我们要进行一些相对复杂的操作（跟着我一起做）： 首先，打开两个浏览器窗口或者标签页。在第一个浏览器窗口的地址栏中输入http://localhost:8888/start， 但是先不要打开它！ 在第二个浏览器窗口的地址栏中输入http://localhost:8888/upload， 同样的，先不要打开它！ 接下来，做如下操作：在第一个窗口中（“/start”）按下回车，然后快速切换到第二个窗口中（“/upload”）按下回车。 注意，发生了什么： /start URL加载花了10秒，这和我们预期的一样。但是，/upload URL居然也花了10秒，而它在对应的请求处理程序中并没有类似于sleep()这样的操作！ 这到底是为什么呢？原因就是start()包含了阻塞操作。形象的说就是“它阻塞了所有其他的处理工作”。 这显然是个问题，因为Node一向是这样来标榜自己的：“在node中除了代码，所有一切都是并行执行的”。 这句话的意思是说，Node.js可以在不新增额外线程的情况下，依然可以对任务进行并行处理 —— Node.js是单线程的。它通过事件轮询（event loop）来实现并行操作，对此，我们应该要充分利用这一点 —— 尽可能的避免阻塞操作，取而代之，多使用非阻塞操作。 然而，要用非阻塞操作，我们需要使用回调，通过将函数作为参数传递给其他需要花时间做处理的函数（比方说，休眠10秒，或者查询数据库，又或者是进行大量的计算）。 对于Node.js来说，它是这样处理的：“嘿，probablyExpensiveFunction()（译者注：这里指的就是需要花时间处理的函数），你继续处理你的事情，我（Node.js线程）先不等你了，我继续去处理你后面的代码，请你提供一个callbackFunction()，等你处理完之后我会去调用该回调函数的，谢谢！” （如果想要了解更多关于事件轮询细节，可以阅读Mixu的博文——理解node.js的事件轮询。） 接下来，我们会介绍一种错误的使用非阻塞操作的方式。 和上次一样，我们通过修改我们的应用来暴露问题。 这次我们还是拿start请求处理程序来“开刀”。将其修改成如下形式： var exec = require(\"child_process\").exec;function start() &#123; console.log(\"Request handler 'start' was called.\"); var content = \"empty\"; exec(\"ls -lah\", function (error, stdout, stderr) &#123; content = stdout; &#125;); return content;&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\"); return \"Hello Upload\";&#125;exports.start = start;exports.upload = upload; 上述代码中，我们引入了一个新的Node.js模块，child_process。之所以用它，是为了实现一个既简单又实用的非阻塞操作：exec()。 exec()做了什么呢？它从Node.js来执行一个shell命令。在上述例子中，我们用它来获取当前目录下所有的文件（“ls -lah”）,然后，当/startURL请求的时候将文件信息输出到浏览器中。 上述代码是非常直观的： 创建了一个新的变量content（初始值为“empty”），执行“ls -lah”命令，将结果赋值给content，最后将content返回。 和往常一样，我们启动服务器，然后访问“http://localhost:8888/start” 。 之后会载入一个漂亮的web页面，其内容为“empty”。怎么回事？ 这个时候，你可能大致已经猜到了，exec()在非阻塞这块发挥了神奇的功效。它其实是个很好的东西，有了它，我们可以执行非常耗时的shell操作而无需迫使我们的应用停下来等待该操作。 （如果想要证明这一点，可以将“ls -lah”换成比如“find /”这样更耗时的操作来效果）。 然而，针对浏览器显示的结果来看，我们并不满意我们的非阻塞操作，对吧？ 好，接下来，我们来修正这个问题。在这过程中，让我们先来看看为什么当前的这种方式不起作用。 问题就在于，为了进行非阻塞工作，exec()使用了回调函数。 在我们的例子中，该回调函数就是作为第二个参数传递给exec()的匿名函数： function (error, stdout, stderr) &#123; content = stdout;&#125; 现在就到了问题根源所在了：我们的代码是同步执行的，这就意味着在调用exec()之后，Node.js会立即执行 return content ；在这个时候，content仍然是“empty”，因为传递给exec()的回调函数还未执行到——因为exec()的操作是异步的。 我们这里“ls -lah”的操作其实是非常快的（除非当前目录下有上百万个文件）。这也是为什么回调函数也会很快的执行到 —— 不过，不管怎么说它还是异步的。 为了让效果更加明显，我们想象一个更耗时的命令： “find /”，它在我机器上需要执行1分钟左右的时间，然而，尽管在请求处理程序中，我把“ls -lah”换成“find /”，当打开/start URL的时候，依然能够立即获得HTTP响应 —— 很明显，当exec()在后台执行的时候，Node.js自身会继续执行后面的代码。并且我们这里假设传递给exec()的回调函数，只会在“find /”命令执行完成之后才会被调用。 那究竟我们要如何才能实现将当前目录下的文件列表显示给用户呢？ 好，了解了这种不好的实现方式之后，我们接下来来介绍如何以正确的方式让请求处理程序对浏览器请求作出响应。 以非阻塞操作进行请求响应我刚刚提到了这样一个短语 —— “正确的方式”。而事实上通常“正确的方式”一般都不简单。 不过，用Node.js就有这样一种实现方案： 函数传递。下面就让我们来具体看看如何实现。 到目前为止，我们的应用已经可以通过应用各层之间传递值的方式（请求处理程序 -&gt; 请求路由 -&gt; 服务器）将请求处理程序返回的内容（请求处理程序最终要显示给用户的内容）传递给HTTP服务器。 现在我们采用如下这种新的实现方式：相对采用将内容传递给服务器的方式，我们这次采用将服务器“传递”给内容的方式。 从实践角度来说，就是将response对象（从服务器的回调函数onRequest()获取）通过请求路由传递给请求处理程序。 随后，处理程序就可以采用该对象上的函数来对请求作出响应。 原理就是如此，接下来让我们来一步步实现这种方案。 先从server.js开始： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(handle, pathname, response); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 相对此前从route()函数获取返回值的做法，这次我们将response对象作为第三个参数传递给route()函数，并且，我们将onRequest()处理程序中所有有关response的函数调都移除，因为我们希望这部分工作让route()函数来完成。 下面就来看看我们的router.js: function route(handle, pathname, response) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](response); &#125; else &#123; console.log(\"No request handler found for \" + pathname); response.writeHead(404, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"404 Not found\"); response.end(); &#125;&#125;exports.route = route; 同样的模式：相对此前从请求处理程序中获取返回值，这次取而代之的是直接传递response对象。 如果没有对应的请求处理器处理，我们就直接返回“404”错误。 最后，我们将requestHandler.js修改为如下形式： var exec = require(\"child_process\").exec;function start(response) &#123; console.log(\"Request handler 'start' was called.\"); exec(\"ls -lah\", function (error, stdout, stderr) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(stdout); response.end(); &#125;);&#125;function upload(response) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello Upload\"); response.end();&#125;exports.start = start;exports.upload = upload; 我们的处理程序函数需要接收response参数，为了对请求作出直接的响应。 start处理程序在exec()的匿名回调函数中做请求响应的操作，而upload处理程序仍然是简单的回复“Hello World”，只是这次是使用response对象而已。 这时再次我们启动应用（node index.js），一切都会工作的很好。 如果想要证明/start处理程序中耗时的操作不会阻塞对/upload请求作出立即响应的话，可以将requestHandlers.js修改为如下形式： var exec = require(\"child_process\").exec;function start(response) &#123; console.log(\"Request handler 'start' was called.\"); exec(\"find /\", &#123; timeout: 10000, maxBuffer: 20000*1024 &#125;, function (error, stdout, stderr) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(stdout); response.end(); &#125;);&#125;function upload(response) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello Upload\"); response.end();&#125;exports.start = start;exports.upload = upload; 这样一来，当请求http://localhost:8888/start 的时候，会花10秒钟的时间才载入，而当请求http://localhost:8888/upload 的时候，会立即响应，纵然这个时候/start响应还在处理中。 更有用的场景到目前为止，我们做的已经很好了，但是，我们的应用没有实际用途。 服务器，请求路由以及请求处理程序都已经完成了，下面让我们按照此前的用例给网站添加交互：用户选择一个文件，上传该文件，然后在浏览器中看到上传的文件。 为了保持简单，我们假设用户只会上传图片，然后我们应用将该图片显示到浏览器中。 好，下面就一步步来实现，鉴于此前已经对JavaScript原理性技术性的内容做过大量介绍了，这次我们加快点速度。 要实现该功能，分为如下两步： 首先，让我们来看看如何处理POST请求（非文件上传），之后，我们使用Node.js的一个用于文件上传的外部模块。之所以采用这种实现方式有两个理由。 第一，尽管在Node.js中处理基础的POST请求相对比较简单，但在这过程中还是能学到很多。第二，用Node.js来处理文件上传（multipart POST请求）是比较复杂的，它不在本书的范畴，但，如何使用外部模块却是在本书涉猎内容之内。 处理POST请求考虑这样一个简单的例子：我们显示一个文本区（textarea）供用户输入内容，然后通过POST请求提交给服务器。最后，服务器接受到请求，通过处理程序将输入的内容展示到浏览器中。 /start请求处理程序用于生成带文本区的表单，因此，我们将requestHandlers.js修改为如下形式： function start(response) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello Upload\"); response.end();&#125;exports.start = start;exports.upload = upload; 好了，现在我们的应用已经很完善了，都可以获得威比奖（Webby Awards）了，哈哈。（译者注：威比奖是由国际数字艺术与科学学院主办的评选全球最佳网站的奖项，具体参见详细说明）通过在浏览器中访问http://localhost:8888/start 就可以看到简单的表单了，要记得重启服务器哦！ 你可能会说：这种直接将视觉元素放在请求处理程序中的方式太丑陋了。说的没错，但是，我并不想在本书中介绍诸如MVC之类的模式，因为这对于你了解JavaScript或者Node.js环境来说没多大关系。 余下的篇幅，我们来探讨一个更有趣的问题： 当用户提交表单时，触发/upload请求处理程序处理POST请求的问题。 现在，我们已经是新手中的专家了，很自然会想到采用异步回调来实现非阻塞地处理POST请求的数据。 这里采用非阻塞方式处理是明智的，因为POST请求一般都比较“重” —— 用户可能会输入大量的内容。用阻塞的方式处理大数据量的请求必然会导致用户操作的阻塞。 为了使整个过程非阻塞，Node.js会将POST数据拆分成很多小的数据块，然后通过触发特定的事件，将这些小数据块传递给回调函数。这里的特定的事件有data事件（表示新的小数据块到达了）以及end事件（表示所有的数据都已经接收完毕）。 我们需要告诉Node.js当这些事件触发的时候，回调哪些函数。怎么告诉呢？ 我们通过在request对象上注册监听器（listener） 来实现。这里的request对象是每次接收到HTTP请求时候，都会把该对象传递给onRequest回调函数。 如下所示： request.addListener(\"data\", function(chunk) &#123; // called when a new chunk of data was received&#125;);request.addListener(\"end\", function() &#123; // called when all chunks of data have been received&#125;); 问题来了，这部分逻辑写在哪里呢？ 我们现在只是在服务器中获取到了request对象 —— 我们并没有像之前response对象那样，把 request 对象传递给请求路由和请求处理程序。 在我看来，获取所有来自请求的数据，然后将这些数据给应用层处理，应该是HTTP服务器要做的事情。因此，我建议，我们直接在服务器中处理POST数据，然后将最终的数据传递给请求路由和请求处理器，让他们来进行进一步的处理。 因此，实现思路就是： 将data和end事件的回调函数直接放在服务器中，在data事件回调中收集所有的POST数据，当接收到所有数据，触发end事件后，其回调函数调用请求路由，并将数据传递给它，然后，请求路由再将该数据传递给请求处理程序。 还等什么，马上来实现。先从server.js开始： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var postData = \"\"; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); request.setEncoding(\"utf8\"); request.addListener(\"data\", function(postDataChunk) &#123; postData += postDataChunk; console.log(\"Received POST data chunk '\"+ postDataChunk + \"'.\"); &#125;); request.addListener(\"end\", function() &#123; route(handle, pathname, response, postData); &#125;); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 上述代码做了三件事情： 首先，我们设置了接收数据的编码格式为UTF-8，然后注册了“data”事件的监听器，用于收集每次接收到的新数据块，并将其赋值给postData 变量，最后，我们将请求路由的调用移到end事件处理程序中，以确保它只会当所有数据接收完毕后才触发，并且只触发一次。我们同时还把POST数据传递给请求路由，因为这些数据，请求处理程序会用到。 上述代码在每个数据块到达的时候输出了日志，这对于最终生产环境来说，是很不好的（数据量可能会很大，还记得吧？），但是，在开发阶段是很有用的，有助于让我们看到发生了什么。 我建议可以尝试下，尝试着去输入一小段文本，以及大段内容，当大段内容的时候，就会发现data事件会触发多次。 再来点酷的。我们接下来在/upload页面，展示用户输入的内容。要实现该功能，我们需要将postData传递给请求处理程序，修改router.js为如下形式： function route(handle, pathname, response, postData) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](response, postData); &#125; else &#123; console.log(\"No request handler found for \" + pathname); response.writeHead(404, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"404 Not found\"); response.end(); &#125;&#125;exports.route = route; 然后，在requestHandlers.js中，我们将数据包含在对upload请求的响应中： function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent: \" + postData); response.end();&#125;exports.start = start;exports.upload = upload; 好了，我们现在可以接收POST数据并在请求处理程序中处理该数据了。 我们最后要做的是： 当前我们是把请求的整个消息体传递给了请求路由和请求处理程序。我们应该只把POST数据中，我们感兴趣的部分传递给请求路由和请求处理程序。在我们这个例子中，我们感兴趣的其实只是text字段。 我们可以使用此前介绍过的querystring模块来实现： var querystring = require(\"querystring\");function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent the text: \"+ querystring.parse(postData).text); response.end();&#125;exports.start = start;exports.upload = upload; 好了，以上就是关于处理POST数据的全部内容。 处理文件上传最后，我们来实现我们最终的用例：允许用户上传图片，并将该图片在浏览器中显示出来。 回到90年代，这个用例完全可以满足用于IPO的商业模型了，如今，我们通过它能学到这样两件事情： 如何安装外部Node.js模块，以及如何将它们应用到我们的应用中。 这里我们要用到的外部模块是Felix Geisendörfer开发的node-formidable模块。它对解析上传的文件数据做了很好的抽象。 其实说白了，处理文件上传“就是”处理POST数据 —— 但是，麻烦的是在具体的处理细节，所以，这里采用现成的方案更合适点。 使用该模块，首先需要安装该模块。Node.js有它自己的包管理器，叫NPM。它可以让安装Node.js的外部模块变得非常方便。通过如下一条命令就可以完成该模块的安装： npm install formidable 如果终端输出如下内容： npm info build Success: formidable@1.0.9npm ok 就说明模块已经安装成功了。 现在我们就可以用formidable模块了——使用外部模块与内部模块类似，用require语句将其引入即可： var formidable = require(\"formidable\"); 这里该模块做的就是将通过HTTP POST请求提交的表单，在Node.js中可以被解析。我们要做的就是创建一个新的IncomingForm，它是对提交表单的抽象表示，之后，就可以用它解析request对象，获取表单中需要的数据字段。 node-formidable官方的例子展示了这两部分是如何融合在一起工作的： var formidable = require('formidable'), http = require('http'), util = require('util');http.createServer(function(req, res) &#123; if (req.url == '/upload' &amp;&amp; req.method.toLowerCase() == 'post') &#123; // parse a file upload var form = new formidable.IncomingForm(); form.parse(req, function(err, fields, files) &#123; res.writeHead(200, &#123;'content-type': 'text/plain'&#125;); res.write('received upload:\\n\\n'); res.end(util.inspect(&#123;fields: fields, files: files&#125;)); &#125;); return; &#125; // show a file upload form res.writeHead(200, &#123;'content-type': 'text/html'&#125;); res.end( '&lt;form action=\"/upload\" enctype=\"multipart/form-data\" '+ 'method=\"post\"&gt;'+ '&lt;input type=\"text\" name=\"title\"&gt;&lt;br&gt;'+ '&lt;input type=\"file\" name=\"upload\" multiple=\"multiple\"&gt;&lt;br&gt;'+ '&lt;input type=\"submit\" value=\"Upload\"&gt;'+ '&lt;/form&gt;' );&#125;).listen(8888); 如果我们将上述代码，保存到一个文件中，并通过node来执行，就可以进行简单的表单提交了，包括文件上传。然后，可以看到通过调用form.parse传递给回调函数的files对象的内容，如下所示： received upload:&#123; fields: &#123; title: 'Hello World' &#125;, files: &#123; upload: &#123; size: 1558, path: '/tmp/1c747974a27a6292743669e91f29350b', name: 'us-flag.png', type: 'image/png', lastModifiedDate: Tue, 21 Jun 2011 07:02:41 GMT, _writeStream: [Object], length: [Getter], filename: [Getter], mime: [Getter] &#125; &#125; &#125; 为了实现我们的功能，我们需要将上述代码应用到我们的应用中，另外，我们还要考虑如何将上传文件的内容（保存在/tmp目录中）显示到浏览器中。 我们先来解决后面那个问题： 对于保存在本地硬盘中的文件，如何才能在浏览器中看到呢？ 显然，我们需要将该文件读取到我们的服务器中，使用一个叫fs的模块。 我们来添加/showURL的请求处理程序，该处理程序直接硬编码将文件/tmp/test.png内容展示到浏览器中。当然了，首先需要将该图片保存到这个位置才行。 将requestHandlers.js修改为如下形式： var querystring = require(\"querystring\"), fs = require(\"fs\");function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" '+ 'content=\"text/html; charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent the text: \"+ querystring.parse(postData).text); response.end();&#125;function show(response, postData) &#123; console.log(\"Request handler 'show' was called.\"); fs.readFile(\"/tmp/test.png\", \"binary\", function(error, file) &#123; if(error) &#123; response.writeHead(500, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(error + \"\\n\"); response.end(); &#125; else &#123; response.writeHead(200, &#123;\"Content-Type\": \"image/png\"&#125;); response.write(file, \"binary\"); response.end(); &#125; &#125;);&#125;exports.start = start;exports.upload = upload;exports.show = show; 我们还需要将这新的请求处理程序，添加到index.js中的路由映射表中： var server = require(\"./server\");var router = require(\"./router\");var requestHandlers = require(\"./requestHandlers\");var handle = &#123;&#125;handle[\"/\"] = requestHandlers.start;handle[\"/start\"] = requestHandlers.start;handle[\"/upload\"] = requestHandlers.upload;handle[\"/show\"] = requestHandlers.show;server.start(router.route, handle); 重启服务器之后，通过访问http://localhost:8888/show，就可以看到保存在/tmp/test.png的图片了。 好，最后我们要的就是： 在/start表单中添加一个文件上传元素 将node-formidable整合到我们的upload请求处理程序中，用于将上传的图片保存到/tmp/test.png 将上传的图片内嵌到/uploadURL输出的HTML中 第一项很简单。只需要在HTML表单中，添加一个multipart/form-data的编码类型，移除此前的文本区，添加一个文件上传组件，并将提交按钮的文案改为“Upload file”即可。 如下requestHandler.js所示： var querystring = require(\"querystring\"), fs = require(\"fs\");function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" '+ 'content=\"text/html; charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" enctype=\"multipart/form-data\" '+ 'method=\"post\"&gt;'+ '&lt;input type=\"file\" name=\"upload\"&gt;'+ '&lt;input type=\"submit\" value=\"Upload file\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent the text: \"+ querystring.parse(postData).text); response.end();&#125;function show(response, postData) &#123; console.log(\"Request handler 'show' was called.\"); fs.readFile(\"/tmp/test.png\", \"binary\", function(error, file) &#123; if(error) &#123; response.writeHead(500, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(error + \"\\n\"); response.end(); &#125; else &#123; response.writeHead(200, &#123;\"Content-Type\": \"image/png\"&#125;); response.write(file, \"binary\"); response.end(); &#125; &#125;);&#125;exports.start = start;exports.upload = upload;exports.show = show; 很好。下一步相对比较复杂。这里有这样一个问题： 我们需要在upload处理程序中对上传的文件进行处理，这样的话，我们就需要将request对象传递给node-formidable的form.parse函数。 但是，我们有的只是response对象和postData数组。看样子，我们只能不得不将request对象从服务器开始一路通过请求路由，再传递给请求处理程序。 或许还有更好的方案，但是，不管怎么说，目前这样做可以满足我们的需求。 到这里，我们可以将postData从服务器以及请求处理程序中移除了 —— 一方面，对于我们处理文件上传来说已经不需要了，另外一方面，它甚至可能会引发这样一个问题： 我们已经“消耗”了request对象中的数据，这意味着，对于form.parse来说，当它想要获取数据的时候就什么也获取不到了。（因为Node.js不会对数据做缓存） 我们从server.js开始 —— 移除对postData的处理以及request.setEncoding （这部分node-formidable自身会处理），转而采用将request对象传递给请求路由的方式： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(handle, pathname, response, request); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 接下来是 router.js —— 我们不再需要传递postData了，这次要传递request对象： function route(handle, pathname, response, request) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](response, request); &#125; else &#123; console.log(\"No request handler found for \" + pathname); response.writeHead(404, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(\"404 Not found\"); response.end(); &#125;&#125;exports.route = route; 现在，request对象就可以在我们的upload请求处理程序中使用了。node-formidable会处理将上传的文件保存到本地/tmp目录中，而我们需要做的是确保该文件保存成/tmp/test.png。 没错，我们保持简单，并假设只允许上传PNG图片。 这里采用fs.renameSync(path1,path2)来实现。要注意的是，正如其名，该方法是同步执行的， 也就是说，如果该重命名的操作很耗时的话会阻塞。 这块我们先不考虑。 接下来，我们把处理文件上传以及重命名的操作放到一起，如下requestHandlers.js所示： var querystring = require(\"querystring\"), fs = require(\"fs\"), formidable = require(\"formidable\");function start(response) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" enctype=\"multipart/form-data\" '+ 'method=\"post\"&gt;'+ '&lt;input type=\"file\" name=\"upload\" multiple=\"multiple\"&gt;'+ '&lt;input type=\"submit\" value=\"Upload file\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, request) &#123; console.log(\"Request handler 'upload' was called.\"); var form = new formidable.IncomingForm(); console.log(\"about to parse\"); form.parse(request, function(error, fields, files) &#123; console.log(\"parsing done\"); fs.renameSync(files.upload.path, \"/tmp/test.png\"); response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(\"received image:&lt;br/&gt;\"); response.write(\"&lt;img src='/show' /&gt;\"); response.end(); &#125;);&#125;function show(response) &#123; console.log(\"Request handler 'show' was called.\"); fs.readFile(\"/tmp/test.png\", \"binary\", function(error, file) &#123; if(error) &#123; response.writeHead(500, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(error + \"\\n\"); response.end(); &#125; else &#123; response.writeHead(200, &#123;\"Content-Type\": \"image/png\"&#125;); response.write(file, \"binary\"); response.end(); &#125; &#125;);&#125;exports.start = start;exports.upload = upload;exports.show = show; 好了，重启服务器，我们应用所有的功能就可以用了。选择一张本地图片，将其上传到服务器，然后浏览器就会显示该图片。 总结与展望恭喜，我们的任务已经完成了！我们开发完了一个Node.js的web应用，应用虽小，但却“五脏俱全”。 期间，我们介绍了很多技术点：服务端JavaScript、函数式编程、阻塞与非阻塞、回调、事件、内部和外部模块等等。 当然了，还有许多本书没有介绍到的： 如何操作数据库、如何进行单元测试、如何开发Node.js的外部模块以及一些简单的诸如如何获取GET请求之类的方法。 但本书毕竟只是一本给初学者的教程 —— 不可能覆盖到所有的内容。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/","raw":null,"content":null,"categories":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/categories/read/"}],"tags":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/tags/read/"},{"name":"nodejs","slug":"nodejs","permalink":"http://agehua.github.io/tags/nodejs/"}]},{"title":"JAVA泛型通配符T，E，K，V区别，T以及Class<T>，Class<?>的区别","slug":"Difference_between-T-E-K-V","date":"2016-11-20T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/11/21/Difference_between-T-E-K-V/","link":"","permalink":"http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/","excerpt":"\n文章转载自《JAVA泛型通配符T，E，K，V区别，T以及Class，Class&lt;?&gt;的区别》\n\n1. 先解释下泛型概念泛型是Java SE 1.5的新特性，泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口、泛型方法。Java语言引入泛型的好处是安全简单。\n在Java SE 1.5之前，没有泛型的情况的下，通过对类型Object的引用来实现参数的“任意化”，“任意化”带来的缺点是要做显式的强制类型转换，而这种转换是要求开发者对实际参数类型可以预知的情况下进行的。对于强制类型转换错误的情况，编译器可能不提示错误，在运行的时候才出现异常，这是一个安全隐患。","text":"文章转载自《JAVA泛型通配符T，E，K，V区别，T以及Class，Class&lt;?&gt;的区别》 1. 先解释下泛型概念泛型是Java SE 1.5的新特性，泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口、泛型方法。Java语言引入泛型的好处是安全简单。 在Java SE 1.5之前，没有泛型的情况的下，通过对类型Object的引用来实现参数的“任意化”，“任意化”带来的缺点是要做显式的强制类型转换，而这种转换是要求开发者对实际参数类型可以预知的情况下进行的。对于强制类型转换错误的情况，编译器可能不提示错误，在运行的时候才出现异常，这是一个安全隐患。 泛型的好处是在编译的时候检查类型安全，并且所有的强制转换都是自动和隐式的，以提高代码的重用率。 以上内容摘自百度百科 举个栗子:Box类定义为一个泛型类public class Box&lt;T&gt; &#123; private T object; public void set(T object) &#123; this.object = object; &#125; public T get() &#123; return object; &#125;&#125; 创建一个Box对象，不带泛型参数，发现获取对象的时候需要强制转换 Box box2 = new Box();box2.set(new Apple());Apple apple = (Apple) box2.get(); 创建一个Box对象，带泛型参数，获取对象的时候就不需要强制转换 Box&lt;Apple&gt; box = new Box&lt;Apple&gt;();box.set(new Apple());Apple apple = box.get(); 总结下泛型的好处就是： 省去了强制转换，可以在编译时候检查类型安全，可以用在类，方法，接口上 但是我们定义泛型类，泛型方法，泛型接口的时候经常会碰见很多不同的通配符T，E，K，V等等，这些通配符又都是什么意思呢？继续往下看 2. 下来说说泛型通配符T，E，K，V区别这些全都属于java泛型的通配符，刚开始我看到这么多通配符，一下晕了，这几个其实没什么区别，只不过是一个约定好的代码，也就是说使用大写字母A,B,C,D……X,Y,Z定义的，就都是泛型，把T换成A也一样，这里T只是名字上的意义而已 ？ 表示不确定的java类型 T (type) 表示具体的一个java类型 K V (key value) 分别代表java键值中的Key Value E (element) 代表Element 举个栗子：public class Test&lt;T&gt; &#123; public List&lt;T&gt; list = new ArrayList&lt;T&gt;(); public static void main(String[] args) &#123; Test&lt;String&gt; test = new Test&lt;String&gt;(); test.list.add(\"hello\"); System.out.println(test.list);&#125;&#125; 和public class Test&lt;A&gt; &#123; public List&lt;A&gt; list = new ArrayList&lt;A&gt;(); public static void main(String[] args) &#123; Test&lt;String&gt; test = new Test&lt;String&gt;(); test.list.add(\"hello\"); System.out.println(test.list);&#125;&#125; 将T换成了A，在执行效果上是没有任何区别的，只不过我们约定好了T代表type，所以还是按照约定规范来比较好，增加了代码的可读性。 如果要定义多个泛型参数，比如说两个泛型参数，很典型的一个栗子是Map的key,value泛型，我们也可以定义一个这样的public interface Mymap&lt;K, V&gt; &#123; public K getKey(); public V getValue();&#125;public class MymapImpl&lt;K, V&gt; implements Mymap&lt;K, V&gt; &#123; private K key; private V value; public MymapImpl(K key, V value) &#123; this.key = key; this.value = value; &#125; public K getKey() &#123; return key; &#125; public V getValue() &#123; return value; &#125;&#125; 下来就可以传入任意类型，创建实例了，不用转化类型Mymap&lt;String, Integer&gt; mp1= new MymapImpl&lt;String, Integer&gt;(\"Even\", 8);Mymap&lt;String, String&gt; mp2= new MymapImpl&lt;String, String&gt;(\"hello\", \"world\");Mymap&lt;Integer, Integer&gt; mp3= new MymapImpl&lt;Integer, Integer&gt;(888, 888); 如果要定义超过两个，三个或三个以上的泛型参数可以使用T1, T2, …, Tn，像这样子public class Test&lt;T1,T2,T3&gt; &#123; public void print(T1 t1,T2 t2,T3 t3)&#123; System.out.println(t1.getClass()); System.out.println(t2.getClass()); System.out.println(t3.getClass()); &#125;&#125; 3. 下来说说T，Class，Class&lt;?&gt;区别T是一种具体的类，例如String,List,Map……等等，这些都是属于具体的类，这个比较好理解 Class是什么呢，Class也是一个类，但Class是存放上面String,List,Map……类信息的一个类，有点抽象，我们一步一步来看 。 如何获取到Class类呢，有三种方式： 调用Object类的getClass()方法来得到Class对象，这也是最常见的产生Class对象的方法。例如：List list = null;Class clazz = list.getClass(); 使用Class类的中静态forName()方法获得与字符串对应的Class对象。例如： Class clazz = Class.forName(\"com.lyang.demo.fanxing.People\"); 3.获取Class类型对象的第三个方法非常简单。如果T是一个Java类型，那么T.class就代表了匹配的类对象。Class clazz = List.class; 那么问题来了？Class类是创建出来了，但是Class和Class&lt;?&gt;适用于什么时候呢？？？ 使用Class和Class&lt;?&gt;多发生在反射场景下，先看看如果我们不使用泛型，反射创建一个类是什么样的。People people = (People) Class.forName(\"com.lyang.demo.fanxing.People\").newInstance(); 看到了么，需要强转，如果反射的类型不是People类，就会报java.lang.ClassCastException错误。 使用Class泛型后，不用强转了public class Test &#123; public static &lt;T&gt; T createInstance(Class&lt;T&gt; clazz) throws IllegalAccessException, InstantiationException &#123; return clazz.newInstance(); &#125; public static void main(String[] args) throws IllegalAccessException, InstantiationException &#123; Fruit fruit= createInstance(Fruit .class); People people= createInstance(People.class); &#125;&#125; 那Class和Class&lt;?&gt;有什么区别呢？ Class在实例化的时候，T要替换成具体类 Class&lt;?&gt;它是个通配泛型，?可以代表任何类型，主要用于声明时的限制情况 例如可以声明一个public Class&lt;?&gt; clazz; 但是你不能声明一个public Class&lt;T&gt; clazz; 因为T需要指定类型 所以当不知道定声明什么类型的Class的时候可以定义一个Class&lt;?&gt;,Class&lt;?&gt;可以用于参数类型定义，方法返回值定义等。 也可以参考：https://juejin.cn/post/6844903917835419661 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"genericity","slug":"genericity","permalink":"http://agehua.github.io/tags/genericity/"}]},{"title":"Hexo 出错情况收集","slug":"hexo-mac-module-not-found","date":"2016-11-02T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/11/03/hexo-mac-module-not-found/","link":"","permalink":"http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/","excerpt":"Error: Cannot find module ‘./build/Release/DTraceProviderBindings’我在更新hexo，准备安装别的module时，不小心按到了 ctrl+c，结果发现使用hexo命令会报如下错误：&#123; [Error: Cannot find module './build/Release/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;    &#123; [Error: Cannot find module './build/default/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;&#123; [Error: Cannot find module './build/Debug/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;","text":"Error: Cannot find module ‘./build/Release/DTraceProviderBindings’我在更新hexo，准备安装别的module时，不小心按到了 ctrl+c，结果发现使用hexo命令会报如下错误：&#123; [Error: Cannot find module './build/Release/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125; &#123; [Error: Cannot find module './build/default/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;&#123; [Error: Cannot find module './build/Debug/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125; 网上一大堆的解决办法都不好用，这里特别记录下我找到的一个解决办法，亲测可用 1. 重新安装Hexo，需要手动删除隐藏的hexo文件 需要删除 /usr/local/lib/node_modules/ 目录下的hexo文件夹 /usr/local/bin/ 下的hexo文件. 直接删掉就好了. 注意这两个都是隐藏文件，要想在finder中显示隐藏文件，需要在Terminal中执行：defaults write com.apple.finder AppleShowAllFiles -bool true 2. 重新执行命令：npm install -g hexo –save 这样就可以了 :) 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Hexo","slug":"hexo","permalink":"http://agehua.github.io/tags/hexo/"}]},{"title":"gradle 学习2——生成指定文件名的apk","slug":"gradle-learning2","date":"2016-10-12T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2016/10/13/gradle-learning2/","link":"","permalink":"http://agehua.github.io/2016/10/13/gradle-learning2/","excerpt":"上一篇Gradle学习了解了Gradle的基本结构和依赖关系，这篇文章介绍下怎么在Android上使用Gradle生成指定包名的APK\n需求场景在我们Android开发基本进入测试阶段后，会根据后台的不同环境，打包出对应不同环境（如SIT、UAT、PRD等）的APK安装包。\n每次去手动修改Java类改变后台环境太麻烦还容易忘记修改。打包成功后，还需要手动将默认的包名app-release.apk改成我们需要的包名，也是非常麻烦，有没有直接指定环境，生成指定文件名的安装包呢？\n方法是有的，就是利用gradle的分渠道打包特性，下面上代码分别解释。\n\n主要在这两个个地方修改：\n\nbuildType（构建类型）\nproductFlavors （不同定制的产品）\n\n","text":"上一篇Gradle学习了解了Gradle的基本结构和依赖关系，这篇文章介绍下怎么在Android上使用Gradle生成指定包名的APK 需求场景在我们Android开发基本进入测试阶段后，会根据后台的不同环境，打包出对应不同环境（如SIT、UAT、PRD等）的APK安装包。 每次去手动修改Java类改变后台环境太麻烦还容易忘记修改。打包成功后，还需要手动将默认的包名app-release.apk改成我们需要的包名，也是非常麻烦，有没有直接指定环境，生成指定文件名的安装包呢？ 方法是有的，就是利用gradle的分渠道打包特性，下面上代码分别解释。 主要在这两个个地方修改： buildType（构建类型） productFlavors （不同定制的产品） buildType（构建类型）介绍默认情况下，Android Plugin会自动给项目设置同时构建应用程序的debug和release版本。 两个版本之间的不同主要围绕着能否在一个安全设备上调试，以及APK如何签名。 可以创建一个新的构建类型就是简单的在buildType标签下添加一个新的元素，并且可以使用initWith()或者直接使用闭包来配置它。 以下是一些可能使用到的属性和默认值： Property name Default values for debug Default values for release / other debuggable true false jniDebugBuild false false renderscriptDebugBuild false false renderscriptOptimLevel 3 3 applicationIdSuffix null null versionNameSuffix null null signingConfig android.signingConfigs.debug null zipAlign false true runProguard false false proguardFile N/A (set only) N/A (set only) proguardFiles N/A (set only) N/A (set only) 上面介绍摘选自Gralde plugin User Guide 中文版 Product flavors（不同定制的产品）介绍一个product flavor定义了从项目中构建了一个应用的自定义版本。一个单一的项目可以同时定义多个不同的flavor来改变应用的输出。 这个新的设计概念是为了解决不同的版本之间的差异非常小的情况。虽然最项目终生成了多个定制的版本，但是它们本质上都是同一个应用，那么这种做法可能是比使用库项目更好的实现方式。 Product flavor需要在productFlavors这个DSL容器中声明： android &#123; .... productFlavors &#123; flavor1 &#123; ... &#125; flavor2 &#123; ... &#125; &#125;&#125; 这里创建了两个flavor，名为flavor1和flavor2。 注意：flavor的命名不能与已存在的Build Type或者androidTest这个sourceSet有冲突。 Build Type + Product Flavor = Build Variant（构建类型+定制产品=构建变种版本）正如前面章节所提到的，每一个Build Type都会生成一个新的APK。 Product Flavor同样也会做这些事情：项目的输出将会拼接所有可能的Build Type和Product Flavor（如果有Flavor定义存在的话）的组合。 每一种组合（包含Build Type和Product Flavor）就是一个Build Variant（构建变种版本）。 例如，在上面的Flavor声明例子中与默认的debug和release两个Build Type将会生成4个Build Variant： Flavor1 - debug Flavor1 - release Flavor2 - debug Flavor2 - release 项目中如果没有定义flavor同样也会有Build Variant，只是使用的是默认的flavor和配置。default(默认)的flavor/config是没有名字的，所以生成的Build Variant列表看起来就跟Build Type列表一样。 具体使用我们的需求就要用到Build Type和Product Flavor我在项目中Build Type的使用，先看代码： buildTypes &#123; release &#123; buildConfigField \"boolean\", \"LEO_DEBUG\", \"false\" minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt' debuggable false jniDebuggable false &#125; debug &#123; buildConfigField \"int\", \"buildType\", \"2\" buildConfigField \"boolean\", \"LEO_DEBUG\", \"true\" &#125; &#125; 和Product Flavor的使用 productFlavors&#123; kaifa&#123; buildConfigField \"int\", \"buildType\", \"1\" &#125; ceshi &#123; buildConfigField \"int\", \"buildType\", \"2\" &#125; SIT &#123; buildConfigField \"int\", \"buildType\", \"3\" &#125; UAT &#123; buildConfigField \"int\", \"buildType\", \"4\" &#125; PRD &#123; buildConfigField \"int\", \"buildType\", \"5\" &#125;&#125; 每一个构建过的productFlavors都会在app-&gt;build-&gt;generated-&gt;source-&gt;buildConfig目录下创建自己对应的一个flavor目录，如下图： 而，buildConfigField会在指定的目录，flavor-&gt;release/debug-&gt;包名，下生成一个BuildConfig.java文件，我的代码在BuildConfig.java中定义了一个int类型的buildType和boolean类型的LEO_DEBUG。要使用这两个字段只需要: if (BuildConfig.LEO_DEBUG)&#123; //用来控制本地Log日志&#125;if (Environment ==BuildConfig.buildType)&#123; //用来控制开发环境&#125; gradle中修改apk生成名字的方法这个方法是定义在productFlavors同一层级的 android.applicationVariants.all &#123; variant -&gt; variant.outputs.each &#123; output -&gt; def outputFile = output.outputFile if (outputFile != null &amp;&amp; outputFile.name.endsWith('.apk')) &#123; //这里修改apk文件名 def flavorname =variant.productFlavors[0].name if (flavorname.equals('kaifa')) flavorname = 'debug' else if (flavorname.equals('ceshi')) flavorname = 'release' def fileName = \"app-$&#123;flavorname&#125;-$&#123;defaultConfig.versionName&#125;-$&#123;releaseTime() &#125;.apk\" output.outputFile = new File(outputFile.parent, fileName) &#125; &#125; &#125; 这个方法要定义在最外层def releaseTime() &#123; return new Date().format(\"MMdd\", TimeZone.getTimeZone(\"UTC\"))&#125; 最后生成的apk名字 Mac下Android Studio中获取SHA1和MD5打开Android Studio中的Terminal，也可以直接打开系统的终端 获取debug.keystore的SHA1和MD5输入: keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android 获取其他keystore的，如正式签名文件的，keytool -list -v -keystore ~/User/你的用户名/debug.keystore -alias androiddebugkey -storepass android -keypass android 需要把路径和密码改成相应的就可以了 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/10/13/gradle-learning2/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gradle","slug":"gradle","permalink":"http://agehua.github.io/tags/gradle/"}]},{"title":"gradle 学习","slug":"gradle-learning","date":"2016-10-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/10/12/gradle-learning/","link":"","permalink":"http://agehua.github.io/2016/10/12/gradle-learning/","excerpt":"Gradle是一种依赖管理工具，基于Groovy语言，面向Java应用为主，它抛弃了基于XML的各种繁琐配置，取而代之的是一种基于Groovy的内部领域特定（DSL）语言。它提供灵活的通用构建工具，就像ant。同时完美兼容Maven或Ivy仓库\nGradle的基本组成\n项目(Project) 和 任务(tasks)，Gradle 里的任何东西都是基于这两个基础概念。\n","text":"Gradle是一种依赖管理工具，基于Groovy语言，面向Java应用为主，它抛弃了基于XML的各种繁琐配置，取而代之的是一种基于Groovy的内部领域特定（DSL）语言。它提供灵活的通用构建工具，就像ant。同时完美兼容Maven或Ivy仓库 Gradle的基本组成 项目(Project) 和 任务(tasks)，Gradle 里的任何东西都是基于这两个基础概念。 项目是指我们的构建产物（比如Jar包）或实施产物（将应用程序部署到生产环境）。 任务是指不可分的最小工作单元，执行构建工作（比如编译项目或执行测试）。 每一个构建都是由一个或多个 projects 构成的，每一个 project 是由一个或多个 tasks 构成的，一个 task是指不可分的最小工作单元，执行构建工作（比如编译项目或执行测试） 一个工程的Build，是由多个Project组成，而一个Project又是由task组成的 任何一个构建系统都是由多个构建文件组成，如Ant是由build.xml组成，Maven是由pom.xml组成，Make是由makefile组成。这些构建脚本定义了一系列的规则来指定项目编译流程。 Gradle构建系统的组成Gradle的构建系统是由以下几个文件组成 build.gradle 我们称这个文件为一个构建脚本，这个脚本定义了一个模块和编译用的tasks，它一般是放在项目的模块中，也可以放在项目的根目录用来作为编译结构全局设置，它是必须的 settings.gradle 它描述了哪一个模块需要参与构建。每一个多模块的构建都必须在项目结构的根目录中加入这个设置文件，它也是必须的 gradle.properties 用来配置构建属性，这个不是必须的 Gradle插件Gradle的设计理念是，所有有用的特性都由Gradle插件提供，例如编写一个Java项目时，需要使用到 Java 插件， 它会将许多任务自动的加入到你项目里。Gradle本身提供了一系列的标准插件，无需多余配置只需要在你的build.gradle文件中加入 apply plugin: ‘java’ 这样就可以引入许多task，只需要使用相应的task命令就可以进行项目构建。例如下列一些task: 1.gradle build：编译整个项目，它会执行代码编译、代码检测和单元测试等 2.gradle assemble：编译并打包你的代码, 但是并不运行代码检测和单元测试 3.gradle clean：删除 build 生成的目录和所有生成的文件 4.gradle check：编译并测试你的代码。其它的插件会加入更多的检查步骤，如使用 checkstyle、pmd、findbugs Gradle各个task的关系图： 从上图可以看出，我们通常在执行一个build命令时其实是将一些零散的命令批量执行了，我们也可以根据自己的需求执行其中某一个命令。 外部依赖通常, 一个 Java 项目将有许多外部的依赖, 既指向外部的 JAR 文件. 为了在项目里引用这些 JAR 文件, 你需要告诉 Gradle 去哪里找它们. 在 Gradle 中, JAR 文件位于一个仓库中，这里的仓库类似于 maven 的仓库。 首先，指定maven的仓库地址： repositories &#123; mavenCentral()&#125; mavenCentral() 是Gradle内置的一个maven仓库地址，加入maven仓库后，就可以直接加入maven仓库中的外部依赖，如果这个外部依赖不存在，gradle会联网去maven仓库中自动下载它，并将它缓存到本地，下次再使用时会优先从本地缓存中查找该依赖。 dependencies &#123; compile group: 'commons-collections', name: 'commons-collections', version: '3.2' // 简化写法 // compile 'commons-collections:commons-collections:3.2'&#125; 引用一个外部依赖需要指定使用的group, name 和 version 属性，三者缺一不可。那从哪里得知JAR包的这三个属性呢？我们可以从mvnrepository中搜索到。 本地依赖Gradle也可以从本地目录中引入JAR包依赖，可以单一引入指定的某一JAR包，也可以引入某目录下所有的JAR包 dependencies &#123; compile files('dir/file.jar') compile fileTree(dir: 'libs', include: '*.jar')&#125; 项目依赖往往一个完整的项目由多个子项目构成。在Gradle中，使用文件settings.gradle定义当前项目的子项目。默认情况下，每个子项目的名称对应着当前操作系统目录下的一个子目录。 include 'sub-project1', 'sub-project2', 'sub-project3' 如sub-project1依赖sub-project2，则在sub-project1的build.gradle中加入以下配置即可： dependencies &#123; compile project(':sub-project2')&#125; 依赖关系管理从宏观上说，依赖关系管理分为两个方面。首先，gradle需要知道你要构建或者运行的项目，以便找到它们。我们将这些导入的文件视为项目的依赖。第二，gradle需要构建或者打包你的项目产品。我们将这些导出的文件视为项目的发布。 例如在编译源码时项目需要Hibernate的某些jar包被加入到工程中，而在进行单元测试时还另需要Junit的某些jar被加入。这些被引入的jar包就是项目的依赖。Gradle允许对依赖进行相应的配置，通过不同的配置可以形成不同的依赖效果。例如： apply plugin: 'java'repositories &#123; mavenCentral()&#125;dependencies &#123; compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final' testCompile group: 'junit', name: 'junit', version: '4.+'&#125; 在项目编译时期，junit的jar包不会被引入，只有在单元测试时才会被引入。这样，就可以在不同的场景下加入相应的依赖关系，非常的灵活 Java 插件中定义了许多标准的配置，例如如下： compile 用来编译项目源代码的 runtime 在运行时被生成的类使用的依赖。 默认的, 也包含了compile时的依赖。 testCompile 编译测试代码的依赖。 默认的, 包含runtime时的依赖和compile时的依赖。 testRuntime 运行测试所需要的依赖。 默认的, 包含上面三个依赖。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/10/12/gradle-learning/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gradle","slug":"gradle","permalink":"http://agehua.github.io/tags/gradle/"}]},{"title":"Android面试知识点整理","slug":"Android-interview-questions","date":"2016-09-27T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/09/28/Android-interview-questions/","link":"","permalink":"http://agehua.github.io/2016/09/28/Android-interview-questions/","excerpt":"只整理android面试中涉及到的知识点。不断补充中。。。\n1.Android事件传递机制下面内容摘选自《Android开发艺术探索》\n\n(1) 当一个点击事件发生之后，传递过程遵循如下顺序：Activity -&gt; Window -&gt; View。如果一个view的onTouchEvent方法返回false，那么它的父容器的onTouchEvent方法将会被调用，依此类推，如果所有的元素都不处理这个事件，那么这个事件将会最终传递给Activity处理(调用Activity的onTouchEvent方法)。\n","text":"只整理android面试中涉及到的知识点。不断补充中。。。 1.Android事件传递机制下面内容摘选自《Android开发艺术探索》 (1) 当一个点击事件发生之后，传递过程遵循如下顺序：Activity -&gt; Window -&gt; View。如果一个view的onTouchEvent方法返回false，那么它的父容器的onTouchEvent方法将会被调用，依此类推，如果所有的元素都不处理这个事件，那么这个事件将会最终传递给Activity处理(调用Activity的onTouchEvent方法)。 (2) 正常情况下，一个事件序列只能被一个view拦截并消耗，因为一旦某个元素拦截了某个事件，那么同一个事件序列内的所有事件都会直接交给它处理，并且该元素的onInterceptTouchEvent方法不会再被调用了。 (3) 某个view一旦开始处理事件，如果它不消耗ACTION_DOWN事件，那么同一事件序列的其他事件都不会再交给它来处理，并且事件将重新交给它的父容器去处理(调用父容器的onTouchEvent方法)；如果它消耗ACTION_DOWN事件，但是不消耗其他类型事件，那么这个点击事件会消失，父容器的onTouchEvent方法不会被调用，当前view依然可以收到后续的事件，但是这些事件最后都会传递给Activity处理。 (4) ViewGroup默认不拦截任何事件，因为它的onInterceptTouchEvent方法默认返回false。view没有onInterceptTouchEvent方法，一旦有点击事件传递给它，那么它的onTouchEvent方法就会被调用。 (5) View的onTouchEvent默认都会消耗事件(返回true)，除非它是不可点击的(clickable和longClickable都为false)。view的longClickable默认是false的，clickable则不一定，Button默认是true，而TextView默认是false。 (6) View的enable属性不影响onTouchEvent的默认返回值。哪怕一个view是disable状态，只要它的clickable或者longClickable有一个是true，那么它的onTouchEvent就会返回true。 (7) 事件传递过程总是先传递给父元素，然后再由父元素分发给子view，通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外，即当面对ACTION_DOWN事件时，ViewGroup总是会调用自己的onInterceptTouchEvent方法来询问自己是否要拦截事件。ViewGroup的dispatchTouchEvent方法中有一个标志位FLAG_DISALLOW_INTERCEPT，这个标志位就是通过子view调用requestDisallowInterceptTouchEvent方法来设置的，一旦设置为true，那么ViewGroup不会拦截该事件。 (8) 以上结论均可以在书中的源码解析部分得到解释。Window的实现类为PhoneWindow，获取Activity的contentView的方法 dispatchTouchEvent()返回true，后续事件（ACTION_MOVE、ACTION_UP）会再传递，如果返回false，dispatchTouchEvent()就接收不到ACTION_UP、ACTION_MOVE。 ((ViewGroup)getWindow().getDecorView().findViewById(android.R.id.content)).getChildAt(0); 2.OnTouchListener、onTouchEvent、OnClickListener优先级顺序如果给一个view设置了OnTouchListener，那么OnTouchListener中的onTouch方法会被回调。这时事件如何处理还要看onTouch的返回值，如果返回false，那么当前view的onTouchEvent方法会被调用；如果返回true，那么onTouchEvent方法将不会被调用。在onTouchEvent方法中，如果当前view设置了OnClickListener，那么它的onClick方法会被调用，所以OnClickListener的优先级最低。 自定义View事件拦截1.重写onInterceptTouchEvent()这种是常规写法@Overridepublic boolean onInterceptTouchEvent(MotionEvent ev) &#123; switch (ev.getAction()) &#123; case MotionEvent.ACTION_DOWN: // 为了子view能够响应事件，当前view ACTION_DOWN一般不拦截 break; // .. 满足条件拦截其他事件 &#125;&#125;// 配合 onTouchEvent@Overridepublic boolean onTouchEvent(MotionEvent e) &#123; case MotionEvent.ACTION_MOVE: // 当前view 拦截了ACTION_MOVE，并作出响应处理 break; return true;&#125; 2.重写dispatchTouchEvent这种写法相对少见@Overridepublic boolean dispatchTouchEvent(MotionEvent ev) &#123; // 在super之前处理某些事件，可以阻止事件传递到当前view的onTouchEvent if (statified) &#123; // 比如原有onTouchEvent逻辑复杂，又加了一个单独的view，可以优先让这个view触发事件 return true; &#125; return super.dispatchTouchEvent(ev);&#125; 3.AsyncTask的方法介绍 onPreExecute()这个方法会在后台任务开始执行之间调用，用于进行一些界面上的初始化操作，比如显示一个进度条对话框等。 doInBackground(Params…)这个方法中的所有代码都会在子线程中运行，我们应该在这里去处理所有的耗时任务。任务一旦完成就可以通过return语句来将任务的执行结果进行返回，如果AsyncTask的第三个泛型参数指定的是Void，就可以不返回任务执行结果。注意，在这个方法中是不可以进行UI操作的，如果需要更新UI元素，比如说反馈当前任务的执行进度，可以调用publishProgress(Progress…)方法来完成。 onProgressUpdate(Progress…)当在后台任务中调用了publishProgress(Progress…)方法后，这个方法就很快会被调用，方法中携带的参数就是在后台任务中传递过来的。在这个方法中可以对UI进行操作，利用参数中的数值就可以对界面元素进行相应的更新。 onPostExecute(Result)当后台任务执行完毕并通过return语句进行返回时，这个方法就很快会被调用。返回的数据会作为参数传递到此方法中，可以利用返回的数据来进行一些UI操作，比如说提醒任务执行的结果，以及关闭掉进度条对话框等。 4.项目中Handler怎么使用？5.项目中图片的适配问题怎么解决？ dpi每英寸点数，全称dots per inch。用来表示屏幕密度，即屏幕物理区域中的像素量。高密度屏幕比低密度屏幕在给定物理区域的像素要多。 dp即dip，全称device independent pixel。设备独立像素，是一种虚拟像素单位，用于以密度无关方式表示布局维度或位置，以确保在不同密度的屏幕上正常显示UI。在160dpi的设备上，1dp=1px。 density设备的逻辑密度，是dip的缩放因子。以160dpi的屏幕为基线，density=dpi/160。 getResources().getDisplayMetrics().density sp缩放独立像素，全称scale independent pixel。类似于dp，一般用于设置字体大小，可以根据用户设置的字体大小偏好来缩放。 总结一下图片查找过程：优先匹配最适合的图片→查找密度高的目录（升序）→查找密度低的目录（降序) 也可以使用.9图片 6.Android存储敏感信息的方式有？使用SharedPreferences, getSharedPreferences 指定为 MODE_PRIVATE运用SQLite数据库保存到 SDCard: FileOutputStream fos = this.openFileOutput(“oauth_1.out”,Context.MODE_WORLD_READABLE);Keystore 也可以保存密钥写入SO 文件结合 ContentProvider 来保存信息上传到服务器由服务器保存采用多进程，放在单独的进程中保存 7.自定义广播 继承自BroadcastReceiver 重写onReceive(Context,Intent)Intent.getAction 动态注册（Context.registerReceiver()），静态注册（使用IntentFilter指定action） 8.加分项 JNI开发 性能优化 优秀作品 9.Sqlite数据库更新并保留升级前的数据我们知道在SQLiteOpenHelper的构造方法: super(Context context, String name, SQLiteDatabase.CursorFactory factory, int version) 中最后一个参数表示数据库的版本号.当新的版本号大于当前的version时会调用方法: onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) 所以我们的重点是在该方法中实现SQLite数据库版本升级的管理 对于保留升级前的数据，有两种解决办法： SQLite提供了ALTER TABLE命令，允许用户重命名或添加新的字段到已有表中，但是不能从表中删除字段。并且只能在表的末尾添加字段，比如，为Subscription添加两个字段： ALTER TABLE Subscription ADD COLUMN Activation BLOB; ALTER TABLE Subscription ADD COLUMN Key BLOB; 注释：Sqlite支持BLOB(二进制大对象)数据类型 保留数据删除原表创建新表，具体思路是： 1：将表A重新命名：例如重新命名为：temp_A 2：创建新表A 3：将temp_A中的数据【也就是更新前的数据】插入到新表A 具体操作如下： //重命名原来的数据表public static final String TEMP_SQL_CREATE_TABLE_SUBSCRIBE = \"alter table \" + A + \" rename to temp_A\";//然后把备份表temp_A中的数据copy到新创建的数据库表A中，这个表A没发生结构上的变化public static final String INSERT_SUBSCRIBE = \"select 'insert into A (code,name,username,tablename) values (\"code\",\"name\",\"cnki\",\"tablename\")' as insertSQL from temp_A\";//删除备份表public static final String DELETE_TEMP_SUBSCRIBE = \"delete from temp_A \";public static final String DROP_TEMP_SUBSCRIBE = \"drop table if exists temp_A\";@Overridepublic void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) &#123; for (int j = oldVersion; j &lt;= newVersion; j++) &#123; switch (j) &#123; case 2: //创建临时表 db.execSQL(TEMP_SQL_CREATE_TABLE_SUBSCRIBE); //执行OnCreate方法，这个方法中放的是表的初始化操作工作，比如创建新表之类的 onCreate(db); //删除之前的表里面的默认数据 for (int i = 0; i &lt; arrWhereAct.length; i++) &#123; db.execSQL(DELETE_TEMP_SUBSCRIBE + arrWhereAct[i]); &#125; //将临时表中的数据放入表A Cursor cursor = db.rawQuery(INSERT_SUBSCRIBE, null); if (cursor.moveToFirst()) &#123; do &#123; db.execSQL(cursor.getString(cursor .getColumnIndex(\"insertSQL\"))); &#125; while (cursor.moveToNext()); &#125; cursor.close(); //将临时表删除掉 db.execSQL(DROP_TEMP_SUBSCRIBE); break; default: break; &#125; &#125;&#125; 注意，为什么要在方法里写for循环，主要是考虑到跨版本升级，比如有的用户一直不升级版本，数据库版本号一直是1，而客户端最新版本其实对应的数据库版本已经是4了，那么我中途可能对数据库做了很多修改，通过这个for循环，可以迭代升级，不会发生错误。 10.AIDL支持的数据类型其实AIDL这门语言非常的简单，基本上它的语法和 Java 是一样的，只是在一些细微处有些许差别——毕竟它只是被创造出来简化Android程序员工作的，太复杂不好——所以在这里我就着重的说一下它和 Java 不一样的地方。主要有下面这些点： 文件类型：用AIDL书写的文件的后缀是 .aidl，而不是 .java。 数据类型：AIDL默认支持一些数据类型，在使用这些数据类型的时候是不需要导包的，但是除了这些类型之外的数据类型，在使用之前必须导包，就算目标文件与当前正在编写的 .aidl 文件在同一个包下——在 Java 中，这种情况是不需要导包的。比如，现在我们编写了两个文件，一个叫做Book.java ，另一个叫做 BookManager.aidl，它们都在 com.lypeer.aidldemo 包下 ，现在我们需要在 .aidl 文件里使用 Book 对象，那么我们就必须在 .aidl 文件里面写上 import com.lypeer.aidldemo.Book; 哪怕 .java 文件和 .aidl 文件就在一个包下。 默认支持的数据类型包括： Java中的八种基本数据类型，包括 byte，short，int，long，float，double，boolean，char。 String 类型。 CharSequence类型。 List类型：List中的所有元素必须是AIDL支持的类型之一，或者是一个其他AIDL生成的接口，或者是定义的parcelable（下文关于这个会有详解）。List可以使用泛型。 Map类型：Map中的所有元素必须是AIDL支持的类型之一，或者是一个其他AIDL生成的接口，或者是定义的parcelable。Map是不支持泛型的。 定向tag：这是一个极易被忽略的点——这里的“被忽略”指的不是大家都不知道，而是很少人会正确的使用它。在我的理解里，定向tag是这样的：AIDL中的定向tag表示了在跨进程通信中数据的流向，其中in表示数据只能由客户端流向服务端，out表示数据只能由服务端流向客户端，而inout则表示数据可在服务端与客户端之间双向流通。其中，数据流向是针对在客户端中的那个传入方法的对象而言的。in为定向tag的话表现为服务端将会接收到一个那个对象的完整数据，但是客户端的那个对象不会因为服务端对传参的修改而发生变动；out的话表现为服务端将会接收到那个对象的的空对象，但是在服务端对接收到的空对象有任何修改之后客户端将会同步变动；inout为定向tag的情况下，服务端将会接收到客户端传来对象的完整信息，并且客户端将会同步服务端对该对象的任何变动。 另外，Java 中的基本类型和String，CharSequence的定向tag默认且只能是in。还有，请注意，请不要滥用定向tag，而是要根据需要选取合适的——要是不管三七二十一，全都一上来就用inout，等工程大了系统的开销就会大很多——因为排列整理参数的开销是很昂贵的。 两种AIDL文件：在我的理解里，所有的AIDL文件大致可以分为两类。一类是用来定义parcelable对象，以供其他AIDL文件使用AIDL中非默认支持的数据类型的。一类是用来定义方法接口，以供系统使用来完成跨进程通信的。可以看到，两类文件都是在“定义”些什么，而不涉及具体的实现，这就是为什么它叫做“Android接口定义语言”。注：所有的非默认支持数据类型必须通过第一类AIDL文件定义才能被使用。 下面是两个例子，对于常见的AIDL文件都有所涉及： // Book.aidl//第一类AIDL文件的例子//这个文件的作用是引入了一个序列化对象 Book 供其他的AIDL文件使用//注意：Book.aidl与Book.java的包名应当是一样的package com.lypeer.ipcclient;//注意parcelable是小写parcelable Book;// BookManager.aidl//第二类AIDL文件的例子package com.lypeer.ipcclient;//导入所需要使用的非默认支持数据类型的包import com.lypeer.ipcclient.Book;interface BookManager &#123; //所有的返回值前都不需要加任何东西，不管是什么数据类型 List&lt;Book&gt; getBooks(); Book getBook(); int getBookCount(); //传参时除了Java基本类型以及String，CharSequence之外的类型 //都需要在前面加上定向tag，具体加什么量需而定 void setBookPrice(in Book book , int price) void setBookName(in Book book , String name) void addBookIn(in Book book); void addBookOut(out Book book); void addBookInout(inout Book book);&#125; 11.Android布局的优化方案 层级观察器(Hierarchy Viewer)： 使用layoutopt工具输出 重用布局文件： 使用&lt; merge /&gt;标签减少布局的嵌套层次； 仅在需要时才加载布局，ViewStub 12.Android性能调优 UI卡顿 ANR异常 内存性能优化 Android API使用：StringBuffer/String、HashMap/ArrayMap/SparseArray 性能调优参考这篇博客Andoid应用开发性能优化完全分析 使用 DialogFragment 创建对话框使用DialogFragment至少需要实现onCreateView或者onCreateDIalog方法。onCreateView即使用定义的xml布局文件展示Dialog。onCreateDialog即利用AlertDialog或者Dialog创建出Dialog。 注：官方不推荐直接使用Dialog创建对话框。 没有布局的Fragment的作用没有布局文件Fragment实际上是为了保存，当Activity重启时，保存大量数据准备的 在运行时配置发生变化时，在Fragment中保存有状态的对象a) 继承Fragment，声明引用指向你的有状态的对象b) 当Fragment创建时调用setRetainInstance(boolean)c) 把Fragment实例添加到Activity中d) 当Activity重新启动后，使用FragmentManager对Fragment进行恢复 import android.app.Fragment;import android.os.Bundle;/** * 保存对象的Fragment * * @author zhy * */ public class OtherRetainedFragment extends Fragment &#123; // data object we want to retain // 保存一个异步的任务 private MyAsyncTask data; // this method is only called once for this fragment @Override public void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); // retain this fragment setRetainInstance(true); &#125; public void setData(MyAsyncTask data) &#123; this.data = data; &#125; public MyAsyncTask getData() &#123; return data; &#125;&#125; 具体参考：Android 屏幕旋转 处理 AsyncTask 和 ProgressDialog 的最佳方案 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/28/Android-interview-questions/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"Android 退出整个应用程序解决方案","slug":"quit-whole-application","date":"2016-09-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/09/22/quit-whole-application/","link":"","permalink":"http://agehua.github.io/2016/09/22/quit-whole-application/","excerpt":"关于这个功能，每个公司项目都有自己的解决方案\n搜索了一下，网上大概有以下几种方法解决这个问题：\n\n(1)System.exit(0);\n\n(2)Process.killProcess(Process.myPid());\n\n(3)ActivityManager activityManager = (ActivityManager) this.getSystemService(Context.ACTIVITY_SERVICE);\n  activityManager.restartPackage(“packagename”);\n\n\n但这些貌似不是万能的，有的说在2.2版本后就失效了，那我们怎么办呢？","text":"关于这个功能，每个公司项目都有自己的解决方案 搜索了一下，网上大概有以下几种方法解决这个问题： (1)System.exit(0); (2)Process.killProcess(Process.myPid()); (3)ActivityManager activityManager = (ActivityManager) this.getSystemService(Context.ACTIVITY_SERVICE); activityManager.restartPackage(“packagename”); 但这些貌似不是万能的，有的说在2.2版本后就失效了，那我们怎么办呢？ 1、通过广播在起初的一个项目里我用了一个比较笨的方法，我用一个类来专门管理所有的Activity。这个类里有一个List，每打开一个Activity我就把这个Activity放到这个List中，当退出时再将List中所有的Activity一个一个的关闭。 在后来的项目中发现了一个更好地方法，就是通过广播来完成退出功能，具体实现过程是这样的：在每个Activity创建时（onCreate时）给Activity注册一个广播接收器，当退出时发送该广播即可。大概的代码如下： @Overrideprotected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); IntentFilter filter = new IntentFilter(); filter.addAction(\"finish\"); registerReceiver(mFinishReceiver, filter); ……&#125;private BroadcastReceiver mFinishReceiver = new BroadcastReceiver() &#123; @Override public void onReceive(Context context, Intent intent) &#123; if(\"finish\".equals(intent.getAction())) &#123; Log.e(\"#########\", \"I am \" + getLocalClassName() + \",now finishing myself...\"); finish(); &#125; &#125;&#125;; 相信聪明的大家会把上面的代码写在一个基类里面，因为如果你的项目中Activity很多的话，写起来很麻烦，而且也不符合代码规范。 在退出时执行以下代码即可关闭所有界面完全退出程序： getApplicationContext().sendBroadcast(new Intent(“finish”)); 转载：http://www.cnblogs.com/wader2011/archive/2011/10/10/2205161.html 2、使用退出类public class CloseActivity&#123; private static LinkedList&lt;Activity&gt; acys = new LinkedList&lt;Activity&gt;(); public static Activity curActivity; public static void add(Activity acy) &#123; acys.add(acy); &#125; public static void remove(Activity acy) &#123; acys.remove(acy); &#125; public static void close() &#123; Activity acy; while (acys.size() != 0) &#123; acy = acys.poll(); if (!acy.isFinishing()) &#123; acy.finish(); &#125; &#125;// android.os.Process.killProcess(android.os.Process.myPid()); &#125;&#125; 3.利用activity stack的原理我们知道Android的窗口类提供了历史栈，我们可以通过stack的原理来巧妙的实现，这里我们在D窗口打开A窗口时在Intent中直接加入标志Intent.FLAG_ACTIVITY_CLEAR_TOP，再次开启A时将会清除该进程空间的所有Activity。 在D中使用下面的代码: Intent intent = new Intent();intent.setClass(D.this, A.class);intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP); //注意本行的FLAG设置startActivity(intent);finish(); 关掉自己，在A中加入代码： @Overrideprotected void onNewIntent(Intent intent) &#123; // TODO Auto-generated method stub super.onNewIntent(intent); //退出 if ((Intent.FLAG_ACTIVITY_CLEAR_TOP &amp; intent.getFlags()) != 0) &#123; finish(); &#125;&#125; A的Manifest.xml配置成android:launchMode=&quot;singleTop&quot; 原理总结： 一般A是程序的入口点，从D起一个A的activity，加入标识Intent.FLAG_ACTIVITY_CLEAR_TOP这个过程中会把栈中B，C，都清理掉。因为A是android:launchMode=”singleTop” 不会调用oncreate(),而是响应onNewIntent（）这时候判断Intent.FLAG_ACTIVITY_CLEAR_TOP，然后把A finish（）掉。 栈中A,B,C,D全部被清理。所以整个程序退出了。 4.JNI实现守护进程请看这篇博客Android 通过JNI实现守护进程 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/22/quit-whole-application/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"exitApplication","slug":"exitapplication","permalink":"http://agehua.github.io/tags/exitapplication/"}]},{"title":"使用JNI获取publickey实现","slug":"JNI-get-publickey","date":"2016-09-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/09/22/JNI-get-publickey/","link":"","permalink":"http://agehua.github.io/2016/09/22/JNI-get-publickey/","excerpt":"1.前言之前写过一篇文件是关于JNI学习和积累的文章。这篇文章主要讲在使用JNI取得Publickey过程中遇到的问题和一些总结。\n2.JNI获取Publickey实现在上篇文章中，最终采用的加密方法来自github项目。\n但该项目中在4.0.4版本的手机上，取得publickey遇到兼容性问题。","text":"1.前言之前写过一篇文件是关于JNI学习和积累的文章。这篇文章主要讲在使用JNI取得Publickey过程中遇到的问题和一些总结。 2.JNI获取Publickey实现在上篇文章中，最终采用的加密方法来自github项目。 但该项目中在4.0.4版本的手机上，取得publickey遇到兼容性问题。 正常的Publickey字段样式是这样的： OpenSSLRSAPublicKey&#123;modulus=a0d169cedabdaac3527c2099eeac4cbd74bb9b14c2571bcf6755f49e1d8c8439a37e009b0cb1b1ae9bf164dc976ddc4ee050621c746610d995185accbe8b3c09cc4f8c7afd990db47be814f7f45ec9c489be5b0933e89ff58070c29c98199331160bdb3a19e0687d36e850ee686c565737be4f61328264a58792e198d873b023ec11cb26a73305eea631ab18ec3ce746eb253e47c145503e933ee5da892326ecbb29b5a005aacef2d30d720611f7014aa3f2e40954b9e4deeaca1823dd2f7b2230670acabda70d2f14b1adc9480cf0a48d47866a1aa745ae97d0ab906cd76e5ab76916d03ef153b35edc2ae7284a613b3a3a312c73cf0b98e0ce9a8cf6a682fa,publicExponent=10001&#125; 但是某些低版本手机上（我遇到的是三星GT-S7568 Android版本4.0.4）的Publickey字段样式是： RSA Public Key modulus: a0d169cedabdaac3527c2099eeaca0d169cedabdaac3527c2099eeac4cbd74bb9b14c2571bcf6755f49e1d8c8439a37e009b0cb1b1ae9bf164dc976ddc4ee050621c746610d995185accbe8b3c09cc4f8c7afd990db47be814f7f45ec9c489be5b0933e89ff58070c29c98199331160bdb3a19e0687d36e850ee686c565737be4f61328264a58792e198d873b023ec11cb6a73305eea631ab18ec3ce746eb23e47c145503e933ee5da892326ecbb29b5a005aacef2d30d720611f7014aa3f2e40954b9e4deeaca1823dd2f7b2230670acabda70d2f14b1adc9410cf0a48d47866a1aa745ae97d0ab906cd76e5ab76916d03ef153b35edc2ae7284a613b3a3a313c73cf0b98e0ce9a8cf6a682aff0b98e0ce9a8cf6a682fa public exponent: 10001 第一个字段modulus是一致的，第二个字段一个是“publicExponent”，另一个是“public exponent”。 所以我在代码中的处理是这样的 jmethodID substring_mid = env-&gt;GetMethodID(string_cls,\"substring\", \"(II)Ljava/lang/String;\");jmethodID indexOf_mid = env-&gt;GetMethodID(string_cls,\"indexOf\", \"(Ljava/lang/String;)I\");jint bb = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param2);jstring publicKey2_str =NULL;if (bb ==-1)&#123; jstring param3 = env-&gt;NewStringUTF(\"public exponent\"); jint cc = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param3); __android_log_print(ANDROID_LOG_ERROR, TAG, \"CC value is %d\", cc); publicKey2_str= static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,cc-1));&#125;else &#123; publicKey2_str = static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,bb-1));&#125; 2.1 在JNI native代码中打印日志上面提供的JNI方法中涉及到了JNI日志打印（“__android_log_print”） __android_log_print(ANDROID_LOG_ERROR, TAG, \"PublicKey value is %s\", jstringTostring(env,publicKey2_str)); 该方法第一个参数以日志级别，有：ANDROID_LOG_INFO，ANDROID_LOG_DEBUG和ANDROID_LOG_ERROR 第二个参数设置过滤的标签，可以在LogCat视图中过滤。 后面参数是具体的日志内容 jstringTostring是将jstring转换成char*的方法： char* jstringTostring(JNIEnv* env, jstring jstr)&#123; char* rtn = NULL; jclass clsstring = env-&gt;FindClass(\"java/lang/String\"); jstring strencode = env-&gt;NewStringUTF(\"utf-8\"); jmethodID mid = env-&gt;GetMethodID(clsstring, \"getBytes\", \"(Ljava/lang/String;)[B\"); jbyteArray barr= (jbyteArray)env-&gt;CallObjectMethod(jstr, mid, strencode); jsize alen = env-&gt;GetArrayLength(barr); jbyte* ba = env-&gt;GetByteArrayElements(barr, JNI_FALSE); if (alen &gt; 0) &#123; rtn = (char*)malloc(alen + 1); memcpy(rtn, ba, alen); rtn[alen] = 0; &#125; env-&gt;ReleaseByteArrayElements(barr, ba, 0); return rtn;&#125; jstring是Java提供的一个本地类型（Native Type），对应Java语言中的string类型 想了解JNI其他数据类型的，请看这里JNI学习积累之二 —- 数据类型映射、域描述符说明 要使用JNI日志打印还需要： 1.导入.h文件及定义宏在输出日志的.c文件中加入: #include &lt;android/log.h&gt;#define LOG_TAG \"From JNI ===&gt;&gt;\" 2.在Android.mk中引用日志库加入下面这行代码: LOCAL_LDLIBS := -lm -llog -ljnigraphics 具体学习可以移步这两篇文章： JNI的native代码中打印日志到eclipse的logcat中 JNI中使用LOGCAT 进行Debug 2.2 完整代码下面是我修改后的完整代码 jstring getPublicKey(JNIEnv* env, jobject thiz,jobject context) &#123; jclass context_cls = env-&gt;GetObjectClass(context); jmethodID get_package_manager_mid = env-&gt;GetMethodID(context_cls, \"getPackageManager\", \"()Landroid/content/pm/PackageManager;\"); jmethodID get_package_name_mid = env-&gt;GetMethodID(context_cls, \"getPackageName\", \"()Ljava/lang/String;\"); env-&gt;DeleteLocalRef(context_cls); jobject pm_obj = env-&gt;CallObjectMethod(context, get_package_manager_mid); jclass pm_cls = env-&gt;FindClass(\"android/content/pm/PackageManager\"); jmethodID get_package_info_mid = env-&gt;GetMethodID(pm_cls, \"getPackageInfo\", \"(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;\"); jstring package_name = reinterpret_cast&lt;jstring&gt;(env-&gt;CallObjectMethod( context, get_package_name_mid)); jfieldID flag_fid = env-&gt;GetStaticFieldID(pm_cls, \"GET_SIGNATURES\", \"I\"); jint flag = env-&gt;GetStaticIntField(pm_cls, flag_fid); env-&gt;DeleteLocalRef(pm_cls); jobject pi_obj = env-&gt;CallObjectMethod(pm_obj, get_package_info_mid, package_name, flag); env-&gt;DeleteLocalRef(package_name); jclass pi_cls = env-&gt;FindClass(\"android/content/pm/PackageInfo\"); jfieldID signatures_fid = env-&gt;GetFieldID(pi_cls, \"signatures\", \"[Landroid/content/pm/Signature;\"); env-&gt;DeleteLocalRef(pi_cls); jobject sig_obj = env-&gt;GetObjectField(pi_obj, signatures_fid); env-&gt;DeleteLocalRef(pi_obj); jobjectArray sigs = reinterpret_cast&lt;jobjectArray&gt;(sig_obj); jclass signature_cls = env-&gt;FindClass(\"android/content/pm/Signature\"); jmethodID to_byte_array_mid = env-&gt;GetMethodID(signature_cls, \"toByteArray\", \"()[B\"); jbyteArray sig_bytes = reinterpret_cast&lt;jbyteArray&gt;(env-&gt;CallObjectMethod( env-&gt;GetObjectArrayElement(sigs, 0), to_byte_array_mid)); jclass certificate_factory_cls = env-&gt;FindClass( \"java/security/cert/CertificateFactory\"); jmethodID get_certificate_instance_mid = env-&gt;GetStaticMethodID( certificate_factory_cls, \"getInstance\", \"(Ljava/lang/String;)Ljava/security/cert/CertificateFactory;\"); jobject certificate_factory_obj = env-&gt;CallStaticObjectMethod( certificate_factory_cls, get_certificate_instance_mid, env-&gt;NewStringUTF(\"X509\")); jmethodID generate_certificate_mid = env-&gt;GetMethodID( certificate_factory_cls, \"generateCertificate\", \"(Ljava/io/InputStream;)Ljava/security/cert/Certificate;\"); env-&gt;DeleteLocalRef(certificate_factory_cls); jclass certificate_cls = env-&gt;FindClass(\"java/security/cert/Certificate\"); jclass byte_input_stream_cls = env-&gt;FindClass( \"java/io/ByteArrayInputStream\"); jmethodID new_sig_bytes_is_mid = env-&gt;GetMethodID(byte_input_stream_cls, \"&lt;init&gt;\", \"([B)V\"); jobject sig_bytes_is = env-&gt;NewObject(byte_input_stream_cls, new_sig_bytes_is_mid, sig_bytes); env-&gt;DeleteLocalRef(sig_bytes); env-&gt;DeleteLocalRef(byte_input_stream_cls); jobject cert = env-&gt;CallObjectMethod(certificate_factory_obj, generate_certificate_mid, sig_bytes_is); env-&gt;DeleteLocalRef(sig_bytes_is); env-&gt;DeleteLocalRef(certificate_factory_obj); jmethodID get_pubic_key_mid = env-&gt;GetMethodID(certificate_cls, \"getPublicKey\", \"()Ljava/security/PublicKey;\"); env-&gt;DeleteLocalRef(certificate_cls); jobject publicKey = env-&gt;CallObjectMethod(cert, get_pubic_key_mid); jclass publicKey_cls = env-&gt;GetObjectClass(publicKey); jmethodID toString_mid = env-&gt;GetMethodID(publicKey_cls,\"toString\", \"()Ljava/lang/String;\"); jstring publicKey_str = static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey,toString_mid)); env-&gt;DeleteLocalRef(cert); env-&gt;DeleteLocalRef(publicKey_cls); env-&gt;DeleteLocalRef(publicKey); jclass string_cls = env-&gt;GetObjectClass(publicKey_str); jmethodID indexOf_mid = env-&gt;GetMethodID(string_cls,\"indexOf\", \"(Ljava/lang/String;)I\"); jstring param = env-&gt;NewStringUTF(\"modulus\"); jint aa = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param); jstring param2 = env-&gt;NewStringUTF(\"publicExponent\"); jmethodID substring_mid = env-&gt;GetMethodID(string_cls,\"substring\", \"(II)Ljava/lang/String;\"); __android_log_print(ANDROID_LOG_ERROR, TAG, \"PublicKey String is %s\", jstringTostring(env,publicKey_str)); jint bb = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param2); jstring publicKey2_str =NULL; if (bb ==-1)&#123; jstring param3 = env-&gt;NewStringUTF(\"public exponent\"); jint cc = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param3); __android_log_print(ANDROID_LOG_ERROR, TAG, \"CC value is %d\", cc); publicKey2_str= static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,cc-1)); &#125;else &#123; publicKey2_str = static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,bb-1)); &#125; __android_log_print(ANDROID_LOG_ERROR, TAG, \"PublicKey value is %s\", jstringTostring(env,publicKey2_str)); return publicKey2_str;&#125; 3.附赠版本兼容的方法问题（随时更新）低于Jellybean版本报如下错误： 01-20 08:53:00.141: E/AndroidRuntime(24005): java.lang.NoSuchMethodError: android.view.ViewTreeObserver.removeOnGlobalLayoutListener 正确调用方式应该是： if (Build.VERSION.SDK_INT &lt; Build.VERSION_CODES.JELLY_BEAN) &#123; ViewTreeObserver.removeGlobalOnLayoutListener(this);&#125;else ViewTreeObserver.removeOnGlobalLayoutListener(this); 还有一个setBackground方法： if(Build.VERSION.SzDK_INT &gt;= Build.VERSION_CODES.JELLY_BEAN) &#123; View.setBackground(new ColorDrawable(Color.parseColor(\"#CCCCCC\")));&#125; else &#123; View.setBackgroundColor(Color.parseColor(\"#CCCCCC\"));&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/22/JNI-get-publickey/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"JNI","slug":"jni","permalink":"http://agehua.github.io/tags/jni/"},{"name":"publickey","slug":"publickey","permalink":"http://agehua.github.io/tags/publickey/"}]},{"title":"apk中含有admob广告插件","slug":"AVG-unwanted-software","date":"2016-09-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/09/20/AVG-unwanted-software/","link":"","permalink":"http://agehua.github.io/2016/09/20/AVG-unwanted-software/","excerpt":"问题出现使用这个杀毒软件antivirus-for-android，检测我们团队的apk后，AVG提示警告unwanted software。\n生成的报告说是：Beware of Adware! 1 Types of Adware DetectedLast reported adware activity:    Sep 16Days with adware in last 30:    1 days\n见下图：","text":"问题出现使用这个杀毒软件antivirus-for-android，检测我们团队的apk后，AVG提示警告unwanted software。 生成的报告说是：Beware of Adware! 1 Types of Adware DetectedLast reported adware activity: Sep 16Days with adware in last 30: 1 days 见下图： 排查使用这个广告插件检测工具全能工具箱，检测后，确实提示我们的apk含有广告“admob” 但是这个apk是我们团队自己开发的，有项目源码，AndroidManifest文件中没有网络上说的Google AdMob注册，更没有com.google.ads.AdView这个布局文件 代码中没有，可能在第三方库中？ 结果就是在排查第三方库的过程中，发现google service的jar包中有名字是ads的文件夹。如下图： 删除后上图中的两个ads文件夹，再打包apk后，用软件检测，果然没有admob插件了。哈哈，恼人的问题解决了。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/20/AVG-unwanted-software/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"remove admob","slug":"remove-admob","permalink":"http://agehua.github.io/tags/remove-admob/"}]},{"title":"ANDROID设计模式之单例模式","slug":"android-design-pattern-singleton","date":"2016-09-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/09/20/android-design-pattern-singleton/","link":"","permalink":"http://agehua.github.io/2016/09/20/android-design-pattern-singleton/","excerpt":"本文转载自stormzhang ANDROID设计模式之单例模式 ，内容稍有补充\n常用单例模式什么是设计模式？其实简单的理解就是前人留下来的一些经验总结而已，然后把这些经验起了个名字叫Design Pattern，翻译过来就是设计模式的意思，通过使用设计模式可以让我们的代码复用性更高，可维护性更高，让你的代码写的更优雅。设计模式理论上有23种，但是我只会针对Android平台上常用的一些设计模式做分享，今天就先来分享下最常用的单例模式。","text":"本文转载自stormzhang ANDROID设计模式之单例模式 ，内容稍有补充 常用单例模式什么是设计模式？其实简单的理解就是前人留下来的一些经验总结而已，然后把这些经验起了个名字叫Design Pattern，翻译过来就是设计模式的意思，通过使用设计模式可以让我们的代码复用性更高，可维护性更高，让你的代码写的更优雅。设计模式理论上有23种，但是我只会针对Android平台上常用的一些设计模式做分享，今天就先来分享下最常用的单例模式。 饿汉式public class Singleton&#123; private static Singleton instance = new Singleton(); private Singleton()&#123;&#125; public static Singleton newInstance()&#123; return instance; &#125;&#125; 饿汉式 是最简单的实现方式，这种实现方式适合那些在初始化时就要用到单例的情况，这种方式简单粗暴，如果单例对象初始化非常快，而且占用内存非常小的时候这种方式是比较合适的，可以直接在应用启动时加载并初始化。 但是，如果单例初始化的操作耗时比较长而应用对于启动速度又有要求，或者单例的占用内存比较大，再或者单例只是在某个特定场景的情况下才会被使用，而一般情况下是不会使用时，使用饿汉式的单例模式就是不合适的，这时候就需要用到懒汉式的方式去按需延迟加载单例。 懒汉式public class Singleton&#123; private static Singleton instance = null; private Singleton()&#123;&#125; public static Singleton newInstance()&#123; if(null == instance)&#123; instance = new Singleton(); &#125; return instance; &#125;&#125; 懒汉式与饿汉式的最大区别就是将单例的初始化操作，延迟到需要的时候才进行，这样做在某些场合中有很大用处。比如某个单例用的次数不是很多，但是这个单例提供的功能又非常复杂，而且加载和初始化要消耗大量的资源，这个时候使用懒汉式就是非常不错的选择。 多线程下的单例模式上面介绍了一些单例模式的基本应用方法，但是上面所说的那些使用方式都是有一个隐含的前提，那就是他们都是应用在单线程条件下，一旦换成了多线程就有出错的风险。 如果在多线程的情况下，饿汉式不会出现问题，因为JVM只会加载一次单例类，但是懒汉式可能就会出现重复创建单例对象的问题。为什么会有这样的问题呢？因为懒汉式在创建单例时是 线程不安全的，多个线程可能会并发调用他的newInstance方法导致多个线程可能会创建多份相同的单例出来。 那有没有办法，使懒汉式的单利模式也是线程安全的呢？答案肯定是有的，就是使用加同步锁的方式去实现。 懒汉式同步锁public class Singleton &#123; private static Singleton instance = null; private Singleton()&#123; &#125; public static Singleton getInstance() &#123; synchronized (Singleton.class) &#123; if (instance == null) &#123; instance = new Singleton(); &#125; &#125; return instance; &#125;&#125; 这种是最常见的解决同步问题的一种方式，使用同步锁synchronized (Singleton.class)防止多线程同时进入造成instance被多次实例化。举个在Android使用这种方式的例子： InputMethodManager示例public final class InputMethodManager &#123; //内部全局唯一实例 static InputMethodManager sInstance; //对外api public static InputMethodManager getInstance() &#123; synchronized (InputMethodManager.class) &#123; if (sInstance == null) &#123; IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE); IInputMethodManager service = IInputMethodManager.Stub.asInterface(b); sInstance = new InputMethodManager(service, Looper.getMainLooper()); &#125; return sInstance; &#125; &#125;&#125; 以上是Android源码中输入法类相关的单例使用方式。 加锁的懒汉模式看起来即解决了线程并发问题，又实现了延迟加载，然而它存在着性能问题，依然不够完美。 synchronized修饰的同步方法比一般方法要慢很多，如果多次调用getInstance()，累积的性能损耗就比较大了。 因此就有了双重校验锁，先看下它的实现代码。 双重校验锁public class Singleton &#123; private static volatile Singleton instance = null; private Singleton()&#123; &#125; public static Singleton getInstance() &#123; // if already inited, no need to get lock everytime if (instance == null) &#123; synchronized (Singleton.class) &#123; if (instance == null) &#123; instance = new Singleton(); &#125; &#125; &#125; return instance; &#125;&#125; 可以看到上面在synchronized (Singleton.class)外又添加了一层if，这是为了在instance已经实例化后下次进入不必执行synchronized (Singleton.class)获取对象锁，从而提高性能。 我们看到双重校验锁即实现了延迟加载，又解决了线程并发问题，同时还解决了执行效率问题，是否真的就万无一失了呢？ 这里要提到Java中的指令重排优化。所谓指令重排优化是指在不改变原语义的情况下，通过调整指令的执行顺序让程序运行的更快。 JVM中并没有规定编译器优化相关的内容，也就是说JVM可以自由的进行指令重排序的优化。 这个问题的关键就在于由于指令重排优化的存在，导致初始化Singleton和将对象地址赋给instance字段的顺序是不确定的。 在某个线程创建单例对象时，在构造方法被调用之前，就为该对象分配了内存空间并将对象的字段设置为默认值。 此时就可以将分配的内存地址赋值给instance字段了，然而该对象可能还没有初始化。若紧接着另外一个线程来调用getInstance，取到的就是状态不正确的对象，程序就会出错。 volatile关键字JDK5的修正：以上就是双重校验锁会失效的原因，不过还好在JDK1.5及之后版本增加了volatile关键字。 volatile的一个语义是禁止指令重排序优化，也就保证了instance变量被赋值的时候对象已经是初始化过的，从而避免了上面说到的问题。Java中的volatile 变量是什么？理解volatile关键字的作用的前提是要理解Java内存模型，volatile关键字的作用主要有两个： 多线程主要围绕可见性和原子性两个特性而展开，使用volatile关键字修饰的变量，保证了其在多线程之间的可见性，即每次读取到volatile变量，一定是最新的数据 代码底层执行不像我们看到的高级语言—-Java程序这么简单， 它的执行是Java代码–&gt;字节码–&gt;根据字节码执行对应的C/C++代码–&gt;C/C++代码被编译成汇编语言–&gt;和硬件电路交互， 现实中，为了获取更好的性能JVM可能会对指令进行重排序，多线程下可能会出现一些意想不到的问题。 使用volatile则会对禁止语义重排序，当然这也一定程度上降低了代码执行效率 从实践角度而言，volatile的一个重要作用就是和CAS结合，保证了原子性， 详细的可以参见java.util.concurrent.atomic包下的类，比如AtomicInteger。 CAS（Compare and swap）比较和替换是设计并发算法时用到的一种技术。 简单来说，比较和替换是使用一个期望值和一个变量的当前值进行比较，如果当前变量的值与我们期望的值相等，就使用一个新值替换当前变量的值。 volatile是一个特殊的修饰符，只有成员变量才能使用它。 在Java并发程序缺少同步类的情况下，多线程对成员变量的操作对其它线程是透明的。 volatile变量可以保证下一个读取操作会在前一个写操作之后发生。 来源： http://blog.csdn.net/fly910905/article/details/79283557 代码如下：public class Singleton &#123; private static volatile Singleton instance = null; private Singleton()&#123;&#125; public static Singleton getInstance() &#123; if (instance == null) &#123; // Single Checked synchronized (Singleton.class) &#123; if (instance == null) &#123; // Double checked instance = new Singleton(); &#125; &#125; &#125; return instance; &#125;&#125; 以上三种方式还是挺麻烦的，我们不禁要问，有没有更好的实现方式呢？答案是肯定的。 我们可以利用JVM的类加载机制去实现。在很多情况下JVM已经为我们提供了同步控制，比如： 在static{}区块中初始化的数据访问final字段时等等因为在JVM进行类加载的时候他会保证数据是同步的，我们可以这样实现： 采用内部类，在这个内部类里面去创建对象实例。这样的话，只要应用中不使用内部类 JVM 就不会去加载这个单例类，也就不会创建单例对象，从而实现懒汉式的延迟加载和线程安全。 实现代码如下： 静态内部类public class Singleton&#123; //内部类，在装载该内部类时才会去创建单利对象 private static class SingletonHolder&#123; public static Singleton instance = new Singleton(); &#125; private Singleton()&#123;&#125; public static Singleton newInstance()&#123; return SingletonHolder.instance; &#125; public void doSomething()&#123; //do something &#125;&#125; 这样实现出来的单例类就是线程安全的，而且使用起来很简洁，麻麻再也不用担心我的单例不是单例了。 然而这还不是最简单的方式，Effective Java中推荐了一种更简洁方便的使用方式，就是使用枚举。 枚举类型单例模式public enum Singleton&#123; //定义一个枚举的元素，它就是Singleton的一个实例 instance; public void doSomething()&#123; // do something ... &#125; &#125; 使用方法如下： public static void main(String[] args)&#123; Singleton singleton = Singleton.instance; singleton.doSomething();&#125; 默认枚举实例的创建是线程安全的(创建枚举类的单例在JVM层面也是能保证线程安全的), 所以不需要担心线程安全的问题，所以理论上枚举类来实现单例模式是最简单的方式。 总结一般单例模式包含了5种写法，分别是饿汉、懒汉、双重校验锁、静态内部类和枚举。相信看完之后你对单例模式有了充分的理解了，根据不同的场景选择最你最喜欢的一种单例模式吧！ 关于synchronized关键字，推荐学习这篇文章：Java基础笔记 – 线程同步问题 解决同步问题的方法 synchronized方法 同步代码块 使用synchronized关键字，该关键字修饰的方法叫做同步方法。 Java中每个对象都有一个锁或者称为监视器，当访问某个对象的synchronized方法时，表示将该对象上锁，而不仅仅是为该方法上锁。 这样如果一个对象的synchronized方法被某个线程执行时，其他线程无法访问该对象的任何synchronized方法（但是可以调用其他非synchronized的方法）。直至该synchronized方法执行完。 静态的synchronized方法调用情况：当调用一个对象的静态synchronized方法时，它锁定的并不是synchronized方法所在的对象，而是synchronized方法所在对象对应的Class对象。这样，其他线程就不能调用该类的其他静态synchronized方法了，但是可以调用非静态的synchronized方法。 结论：执行静态synchronized方法锁方法所在对象，执行非静态synchronized方法锁方法所在对象对应的Class对象。 使用synchronized创建同步代码块：通过使用synchronized同步代码块，锁定一个对象，该对象作为可执行的标志从而达到同步的效果。 synchronized方法和synchronized同步代码块的区别：synchronized同步代码块只是锁定了该代码块，代码块外面的代码还是可以被访问的。synchronized方法是粗粒度的并发控制，某一个时刻只能有一个线程执行该synchronized方法。synchronized同步代码块是细粒度的并发控制，只会将块中的代码同步，代码块之外的代码可以被其他线程同时访问。 参考： Java单例模式的不同写法（懒汉式、饿汉式、双检锁、静态内部类、枚举）关于设计模式，CSDN上也有一个总结: Android源码设计模式分析一期发布 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/20/android-design-pattern-singleton/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Singleton","slug":"singleton","permalink":"http://agehua.github.io/tags/singleton/"}]},{"title":"ThreadLocal、HandlerThread、Looper区别","slug":"ThreadLocal-HandlerThread-Looper","date":"2016-09-04T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/09/05/ThreadLocal-HandlerThread-Looper/","link":"","permalink":"http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/","excerpt":"1.前言Android中非UI线程（WorkThread）不能操作UI线程（MainThread）\nhandler 发送Message 给MessageQueue，Looper 来轮询消息，如果有Message，然后再发送给Handler，Handler 拿到消息就可以所在的线程执行了。\n2.ThreadLocalThread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals ，这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。","text":"1.前言Android中非UI线程（WorkThread）不能操作UI线程（MainThread） handler 发送Message 给MessageQueue，Looper 来轮询消息，如果有Message，然后再发送给Handler，Handler 拿到消息就可以所在的线程执行了。 2.ThreadLocalThread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals ，这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。 简单理解就是每个线程维护一个map，然后可以用一定的关键字取出这个map里的目标类（比如一个bean），这个“一定的关键字”说的就是这个ThreadLocal 。 ThreadLocal隔离了各个线程，让各线程之间没有什么共享的问题。 参考：Android 中 Handler，Looper，HandlerThread 的使用 3.LooperLooper是Android handler机制的重要组成部分，Looper这个名字起的很形象，翻译过来是：打环的人，就是维护一个循环的人。Looper里有一个静态变量：private static final ThreadLocal sThreadLocal = new ThreadLocal();这是典型的Android里用到ThreadLocal的一个情况，调用Looper.prepare的时候，唯一做的事情就是把sThreadLocal作为key，把一个new出来的looper对象作为value put到相应线程的map里。然后以后用到Looper.loop的时候，就从这个sThreadLocal里取出这个Looper，然后死循环（阻塞循环）MessageQueue，取出Message并执行message指向的Handler。 4.HandlerSDK中关于Handler的说明如下： A Handler allows you to sendand process Messageand Runnable objects associated with a thread’s MessageQueue.Each Handler instance is associated with a single thread and that thread’smessage queue. When you create a new Handler, it is bound to the thread /message queue of the thread that is creating it – from that point on, it willdeliver messages and runnables to that message queue and execute them as theycome out of the message queue. 4.1 Handler的作用 There are two main uses for aHandler: (1) to schedule messages and runnables to be executed as some point inthe future; and (2) to enqueue an action to be performed on a different thread than your own. 在线程中实例化Handler需要保证线程当中包含Looper(注意：UI-Thread默认包含Looper)。 4.2 不是所有的Handler都能更新UIHandler处理消息总是在创建Handler的线程里运行。而我们的消息处理中，不乏更新UI的操作，不正确的线程直接更新UI将引发异常。因此，需要时刻关心Handler在哪个线程里创建的。如何更新UI才能不出异常呢？SDK告诉我们，有以下4种方式可以从其它线程访问UI线程(也即线程间通信)： Activity.runOnUiThread(Runnable) View.post(Runnable) View.postDelayed(Runnable, long) 在UI线程中创建的Handler 几点小结 Handler的处理过程运行在创建Handler的线程里 一个Looper对应一个MessageQueue，一个线程对应一个Looper，一个Looper可以对应多个Handler 不确定当前线程时，更新UI时尽量调用View.post方法 handler应该由处理消息的线程创建。 handler与创建它的线程相关联，而且也只与创建它的线程相关联。handler运行在创建它的线程中，所以，如果在handler中进行耗时的操作，会阻塞创建它的线程。 Android的线程分为有消息循环的线程和没有消息循环的线程，有消息循环的线程一般都会有一个Looper。主线程（UI线程）就是一个消息循环的线程。 Looper.myLooper(); //获得当前的LooperLooper.getMainLooper() //获得UI线程的Looper Handle的初始化函数（构造函数），如果没有参数，那么他就默认使用的是当前的Looper，如果有Looper参数，就是用对应的线程的Looper。 如果一个线程中调用Looper.prepare()，那么系统就会自动的为该线程建立一个消息队列，然后调用Looper.loop();之后就进入了消息循环，这个之后就可以发消息、取消息、和处理消息。 5.消息的发送与处理我们简单地看一下消息的循环过程： 5.1 消息的生成Message msg =mHandler.obtainMessage();msg.what = what;msg.sendToTarget(); 5.2 消息的发送MessageQueue queue= mQueue; if (queue != null)&#123; msg.target =this; sent =queue.enqueueMessage(msg, uptimeMillis);&#125; 在Handler.java的sendMessageAtTime(Messagemsg, long uptimeMillis)方法中，我们看到，它找到它所引用的MessageQueue，然后将Message的target设定成自己（目的是为了在处理消息环节，Message能找到正确的Handler），再将这个Message纳入到消息队列中。 5.3 消息的抽取Looper me =myLooper();MessageQueue queue= me.mQueue;while (true) &#123; Message msg =queue.next(); // might block if (msg !=null) &#123; if(msg.target == null) &#123; // Notarget is a magic identifier for the quit message. return; &#125; msg.target.dispatchMessage(msg); msg.recycle(); &#125;&#125; 在Looper.java的loop()函数里，我们看到，这里有一个死循环，不断地从MessageQueue中获取下一个（next方法）Message，然后通过Message中携带的target信息，交由正确的Handler处理（dispatchMessage方法）。 5.4 消息的处理if (msg.callback!= null) &#123; handleCallback(msg);&#125; else &#123; if (mCallback!= null) &#123; if(mCallback.handleMessage(msg)) &#123; return; &#125; &#125; handleMessage(msg);&#125; 在Handler.java的dispatchMessage(Messagemsg)方法里，其中的一个分支就是调用handleMessage方法来处理这条Message，而这也正是我们在职责处描述使用Handler时需要实现handleMessage(Messagemsg)的原因。至于dispatchMessage方法中的另外一个分支，我将会在后面的内容中说明。至此，我们看到，一个Message经由Handler的发送，MessageQueue的入队，Looper的抽取，又再一次地回到Handler的怀抱。而绕的这一圈，也正好帮助我们将同步操作变成了异步操作。 参考上面的消息的发送与处理，这里再解释一下View.post(Runnable)方法。 在post(Runnableaction)方法里，View获得当前线程（即UI线程）的Handler，然后将action对象post到Handler里。 在Handler里，它将传递过来的action对象包装成一个Message（Message的callback为action），然后将其投入UI线程的消息循环中。 在 Handler再次处理该Message时，有一条分支就是为它所设，直接调用mCallback.handleMessage的方法，返回到runnable的run方法。 而此时，已经路由到UI线程里，因此，我们可以毫无顾虑的来更新UI。 5.HandlerThreadHandlerThread就是在普通的Thread基础上加上了Looper的支持，让用户不必自己去创建Looper了，同时方便了Handler的使用。 创建HandlerThread时需要把它启动了，即调用start()方法。然后创建Handler时将HandlerThread中的looper对象传入。 HandlerThread thread = new HandlerThread(\"MyHandlerThread\");thread.start();mHandler = new Handler(thread.getLooper());mHandler.post(new Runnable()&#123;...&#125;); 那么这个Handler对象就是与HandlerThread这个线程绑定了（这时就不再是与UI线程绑定了，这样在Handler中处理耗时操作将不会阻塞UI）。 如果想让HandlerThread退出，则需要调用handlerThread.quit()。 具体可以看下面代码： public class HandlerThreadActivity extends Activity &#123; private static final String TAG = \"HandlerThreadActivity\"; private HandlerThreadmHandlerThread; private MyHandler mMyHandler; @Override protected void onCreate(Bundle savedInstanceState) &#123; // TODO Auto-generatedmethod stub super.onCreate(savedInstanceState); TextView text = new TextView(this); text.setText(\"HandlerThreadActivity\"); setContentView(text); Log.d(TAG, \"The mainthread id = \" + Thread.currentThread().getId()); //生成一个HandlerThread对象，实现了使用Looper来处理消息队列的功能， //这个类由Android应用程序框架提供 mHandlerThread = new HandlerThread(\"handler_thread\"); //在使用HandlerThread的getLooper()方法之前，必须先调用该类的start(); mHandlerThread.start(); //即这个Handler是运行在mHandlerThread这个线程中 mMyHandler = new MyHandler(mHandlerThread.getLooper()); mMyHandler.sendEmptyMessage(1); &#125; private class MyHandler extends Handler &#123; public MyHandler(Looper looper) &#123; super(looper); &#125; @Override public void handleMessage(Message msg) &#123; Log.d(TAG, \"MyHandler--&gt;handleMessage--&gt;threadid = \" + Thread.currentThread().getId()); super.handleMessage(msg); &#125; &#125;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ThreadLocal","slug":"threadlocal","permalink":"http://agehua.github.io/tags/threadlocal/"},{"name":"HandlerThread","slug":"handlerthread","permalink":"http://agehua.github.io/tags/handlerthread/"},{"name":"Looper","slug":"looper","permalink":"http://agehua.github.io/tags/looper/"}]},{"title":"RxJava 学习","slug":"RxAndroid-Learning","date":"2016-08-15T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/08/16/RxAndroid-Learning/","link":"","permalink":"http://agehua.github.io/2016/08/16/RxAndroid-Learning/","excerpt":"1.向前辈致敬给Android开发者的RxJava详解，这篇文章讲解详细，如果耐心看完，相信肯定收获不小\n本篇博文用作学习RxJava过程中，记录知识和心得，如有冒犯还请见谅！\n2.简单介绍RxJava是通过一种扩展的观察者模式来实现的。RxJava有四个基本概念：Observable(可观察者，即被观察者)、 Observer (观察者)、 subscribe (订阅)、事件。Observable和Observer通过subscribe()方法实现订阅关系，从而Observable可以在需要的时候发出事件来通知Observer。","text":"1.向前辈致敬给Android开发者的RxJava详解，这篇文章讲解详细，如果耐心看完，相信肯定收获不小 本篇博文用作学习RxJava过程中，记录知识和心得，如有冒犯还请见谅！ 2.简单介绍RxJava是通过一种扩展的观察者模式来实现的。RxJava有四个基本概念：Observable(可观察者，即被观察者)、 Observer (观察者)、 subscribe (订阅)、事件。Observable和Observer通过subscribe()方法实现订阅关系，从而Observable可以在需要的时候发出事件来通知Observer。 与传统观察者模式不同， RxJava 的事件回调方法除了普通事件onNext()（相当于onClick()/onEvent()）之外，还定义了两个特殊的事件：onCompleted()和onError()。 RxJava的基本实现主要有三点：Observer的创建、Observable的创建、Scheduler线程控制 3.Observer的创建方法Observer 即观察者，它决定事件触发的时候将有怎样的行为。 RxJava 中的 Observer 接口的实现方式： Observer&lt;String&gt; observer = new Observer&lt;String&gt;() &#123; @Override public void onNext(String s) &#123; Log.d(tag, \"Item: \" + s); &#125; @Override public void onCompleted() &#123; Log.d(tag, \"Completed!\"); &#125; @Override public void onError(Throwable e) &#123; Log.d(tag, \"Error!\"); &#125;&#125;; 除了 Observer 接口之外，RxJava还内置了一个实现了Observer的抽象类：Subscriber。 Subscriber对Observer接口进行了一些扩展，但他们的基本使用方式是完全一样的： Subscriber&lt;String&gt; subscriber = new Subscriber&lt;String&gt;() &#123; @Override public void onNext(String s) &#123; Log.d(tag, \"Item: \" + s); &#125; @Override public void onCompleted() &#123; Log.d(tag, \"Completed!\"); &#125; @Override public void onError(Throwable e) &#123; Log.d(tag, \"Error!\"); &#125;&#125;; Observer和Subscriber区别对于使用者来说主要有两点： onStart(): 这是Subscriber增加的方法。 它会在subscribe刚开始，而事件还未发送之前被调用，可以用于做一些准备工作，例如数据的清零或重置。这是一个可选方法，默认情况下它的实现为空。 需要注意的是，如果对准备工作的线程有要求（例如弹出一个显示进度的对话框，这必须在主线程执行）， onStart()就不适用了，因为它总是在subscribe 所发生的线程被调用，而不能指定线程。要在指定的线程来做准备工作，可以使用 doOnSubscribe() 方法。 unsubscribe(): 这是Subscriber所实现的另一个接口Subscription的方法，用于取消订阅。 在这个方法被调用后，Subscriber将不再接收事件。一般在这个方法调用前，可以使用isUnsubscribed()先判断一下状态。 unsubscribe()这个方法很重要，因为在subscribe()之后，Observable会持有 Subscriber 的引用，这个引用如果不能及时被释放，将有内存泄露的风险。所以最好保持一个原则：要在不再使用的时候尽快在合适的地方（例如 onPause() onStop() 等方法中）调用 unsubscribe() 来解除引用关系，以避免内存泄露的发生。 4.Observable的几种创建方法：1.Observable.just(T…)和from(T[])/from(Iterable&lt;? extends T&gt;) 1). just(T…): 将传入的参数依次发送出来 2). from(T[])/from(Iterable&lt;? extends T&gt;): 将传入的数组或 Iterable 拆分成具体对象后，依次发送出来。 3). 由这两个方法创建的Observable对象的特点是：所有Observer一旦订阅这个Observable就会立即调用onNext()方法并传入Observable.just()/from()的参数，而后因为Observable没有数据可以发送了，onComplete()方法会被调用。 Observable&lt;List&lt;String&gt;&gt; listObservable = Observable.just(getColorList()); 注意，如果just()中传入的是耗时方法，该方法会被立即执行并阻塞UI线程。这里的getColorList()是一个不耗时的方法. 下一步，我们写一个Observer来观察Observable。 listObservable.subscribe(new Observer&lt;List&lt;String&gt;&gt;() &#123; @Override public void onCompleted() &#123; &#125; @Override public void onError(Throwable e) &#123; &#125; @Override public void onNext(List&lt;String&gt; colors) &#123; mSimpleStringAdapter.setStrings(colors); &#125;&#125;); 在这个例子中我们不关心Observable何时完成数据的传输，所以我们不用在onComplete()方法里写代码。而且在这里不会有异常抛出，所以我们也不用管onError()方法 2.Observable.fromCallable() 先看代码： Observable&lt;List&lt;String&gt;&gt; tvShowObservable = Observable.fromCallable(new Callable&lt;List&lt;String&gt;&gt;() &#123; @Override public List&lt;String&gt; call() &#123; return mRestClient.getFavoriteTvShows(); &#125;&#125;); 使用Observable.fromCallable()方法有两点好处： 1).获取要发送的数据的代码只会在有Observer订阅之后执行。 2).获取数据的代码（指的是call()方法）可以在子线程中执行。对比just()中传入的方法只能运行在主线程。 这两点好处有时可能非常重要。 现在让我们订阅这个Observable。 mTvShowSubscription = tvShowObservable .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new Observer&lt;List&lt;String&gt;&gt;() &#123; @Override public void onCompleted() &#123; &#125; @Override public void onError(Throwable e) &#123; &#125; @Override public void onNext(List&lt;String&gt; tvShows)&#123; displayTvShows(tvShows); &#125;&#125;); 上面代码逐一介绍： 1).subscribeOn() 指定事件发生的线程 在默认情况下Observable的所有代码，都会在执行subscribe()方法的线程中运行。而通过subscribeOn()方法，这些代码可以在其他线程中执行。在上面的例子中，我们让代码在”IO Scheduler”中执行（Schedulers.io()）。现在我们可以只把Scheduler当做一个可以工作的子线程。 2).observeOn() 会指定onNext()方法发生的线程 通过在observeOn()方法中指定另一个Scheduler来完成onNext()的内容，在这里也就是AndroidSchedules.mainThread()所返回的Scheduler(UI线程的Scheduler)。 3).subscribe() Callable只会在有在Observable调用subscribe()后执行。 Observable.subscribe(Subscriber) 的内部实现是这样的（仅核心代码）： // 注意：这不是 subscribe() 的源码，而是将源码中与性能、兼容性、扩展性有关的代码剔除后的核心代码。// 如果需要看源码，可以去 RxJava 的 GitHub 仓库下载。public Subscription subscribe(Subscriber subscriber) &#123; subscriber.onStart(); onSubscribe.call(subscriber); return subscriber;&#125; 可以看到，subscriber()做了3件事： ①.调用Subscriber.onStart()。这个方法在前面已经介绍过，是一个可选的准备方法。 ②.调用Observable中的OnSubscribe.call(Subscriber)。在这里，事件发送的逻辑开始运行。从这也可以看出，在RxJava中， Observable并不是在创建的时候就立即开始发送事件，而是在它被订阅的时候，即当 subscribe()方法执行的时候。 ③.将传入的Subscriber作为Subscription返回。这是为了方便unsubscribe(). 4).mTvShowSubscription 每当Observer订阅Observable时就会生成一个Subscription对象。一个Subscription代表了一个Observer与Observable之间的连接。有时我们需要操作这个连接，这里拿在Activity的onDestroy()方法中的代码举个例子： if (mTvShowSubscription != null &amp;&amp; !mTvShowSubscription.isUnsubscribed()) &#123; mTvShowSubscription.unsubscribe(); //取消订阅&#125; unsubscribe()方法告诉Observable它所发送的数据不再被Observer所接收。在调用unsubscribe()方法后，我们创建的Observer就不再会收到数据了，以免Observable异步加载数据时发生意外。 3.使用SingleSingle是Observable的精简版，一种特殊的只发射单个值的Observable，几乎和Observable一模一样，但其回调方法不是onComplete()/onNext()/onError()，而是onSuccess()/onError()。 我们现在把刚才写过的Observable用Single重写一遍。首先我们要创建一个Single: Single&lt;List&lt;String&gt;&gt; tvShowSingle = Single.fromCallable(new Callable&lt;List&lt;String&gt;&gt;() &#123; @Override public List&lt;String&gt; call() throws Exception &#123; mRestClient.getFavoriteTvShows(); &#125;&#125;); 然后订阅一下 mTvShowSubscription = tvShowSingle .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new SingleSubscriber&lt;List&lt;String&gt;&gt;() &#123; @Override public void onSuccess(List&lt;String&gt; tvShows) &#123; displayTvShows(tvShows); &#125; @Override public void onError(Throwable error) &#123; displayErrorMessage(); &#125;&#125;); 但这次我们不再使用Observer，而是使用一个叫SingleSubscriber的类。这个类和Observer非常像，只不过它只有上述两个方法：onSuccess()和onError()。SingleSubscriber之于Single就如Observer之于Observable。 订阅一个Single的同时也会自动创建一个Subscription对象。这里的Subscription和上面的例子没有区别，一定要在onDestroy()中解除订阅。 5.线程控制——Scheduler RxJava已经内置了几个 Scheduler ，它们已经适合大多数的使用场景： 1.Schedulers.immediate(): 直接在当前线程运行，相当于不指定线程。这是默认的 Scheduler。 2.Schedulers.newThread(): 总是启用新线程，并在新线程执行操作。 3.Schedulers.io(): I/O 操作（读写文件、读写数据库、网络信息交互等）所使用的 Scheduler。行为模式和 newThread() 差不多，区别在于 io() 的内部实现是是用一个无数量上限的线程池，可以重用空闲的线程，因此多数情况下 io() 比 newThread() 更有效率。不要把计算工作放在 io() 中，可以避免创建不必要的线程。 4.Schedulers.computation(): 计算所使用的 Scheduler。这个计算指的是 CPU 密集型计算，即不会被 I/O 等操作限制性能的操作，例如图形的计算。这个 Scheduler 使用的固定的线程池，大小为 CPU 核数。不要把 I/O 操作放在 computation() 中，否则 I/O 操作的等待时间会浪费 CPU。 5.另外， Android 还有一个专用的 AndroidSchedulers.mainThread()，它指定的操作将在 Android 主线程运行。 6.特殊的情况1.Subject Observable和Observer的复合体，也是二者的桥梁 Subjects = Observable + Observer，Subject继承自Observable实现了Observer Rxjava提供的四种Subject: ①PublishSubject ： subject的基础子类。 ②BehaviorSubject : 会首先向它的订阅者发送截止订阅前最新的一个数据，然后正常发送订阅后的数据流。 ③ReplaySubject ： 会缓存它所订阅的所有数据，向所有订阅它的观察者重发。 ④AsyncSubject ： 只会发布最后一个数据给已经订阅的每一个观察者。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/08/16/RxAndroid-Learning/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"RxJava","slug":"rxjava","permalink":"http://agehua.github.io/tags/rxjava/"},{"name":"RxAndroid","slug":"rxandroid","permalink":"http://agehua.github.io/tags/rxandroid/"}]},{"title":"Android手机定位服务","slug":"android-LocationListener","date":"2016-08-02T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/08/03/android-LocationListener/","link":"","permalink":"http://agehua.github.io/2016/08/03/android-LocationListener/","excerpt":"1.LocationListener使用优先使用网络定位服务，当GPS服务不可用则跳转到手机位置服务设置页面","text":"1.LocationListener使用优先使用网络定位服务，当GPS服务不可用则跳转到手机位置服务设置页面 代码收集： /** * 使用手机定位服务 */private void startLocationService()&#123; locationListener = new LocationListener() &#123; @Override public void onStatusChanged(String provider, int status, Bundle extras) &#123; &#125; @Override public void onProviderEnabled(String provider) &#123; // 当GPS LocationProvider可用时，更新位置 location = locManager.getLastKnownLocation(provider); &#125; @Override public void onProviderDisabled(String provider) &#123; isLocatedSuccess = false; if (provider.equals(\"network\")) &#123; locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 3 * 1000, 8,locationListener); &#125;else if(provider.equals(\"gps\"))&#123;//GPS服务不可用，跳到位置服务设置页面 startActivity(new Intent(android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS)); &#125;else &#123; updateToNewLocation(null); &#125; &#125; @Override public void onLocationChanged(Location location) &#123; // 当定位信息发生改变时，更新位置 isLocatedSuccess = true; updateToNewLocation(location); locManager.removeUpdates(this); &#125; &#125;; if (locManager.getProvider(LocationManager.NETWORK_PROVIDER) != null) locManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 3 * 1000, 8,locationListener); else if (locManager.getProvider(LocationManager.GPS_PROVIDER) != null) locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 3 * 1000, 8,locationListener); else Toast.makeText(mActivity(), \"获取手机位置信息错误\", Toast.LENGTH_SHORT).show();&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/08/03/android-LocationListener/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"LocationListener","slug":"locationlistener","permalink":"http://agehua.github.io/tags/locationlistener/"}]},{"title":"Android Webview总结，不断更新中 :(","slug":"android-webview-summary","date":"2016-07-24T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/07/25/android-webview-summary/","link":"","permalink":"http://agehua.github.io/2016/07/25/android-webview-summary/","excerpt":"1.Android Webview的坑\n1.webview再次加载页面空白\n\n1.可以关闭掉硬件加速\n\n2.不关闭硬件加速的情况下：在关闭Acivity之前手动调用下面方法，\n\n","text":"1.Android Webview的坑 1.webview再次加载页面空白 1.可以关闭掉硬件加速 2.不关闭硬件加速的情况下：在关闭Acivity之前手动调用下面方法， public void goFinish()&#123; isLoadWithError =false; if (null!=jsCallBack) mWebView.removeJavascriptInterface(\"XXX\"); mWebView.setFocusable(true); mWebView.removeAllViews(); try &#123; mWebView.clearHistory(); //webview没有历史记录，这里会抛出异常 &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; mWebView.destroy(); try &#123; //mWebView为WebView所在类的全局变量名，不可以混淆 Field fieldWebView = this.getClass().getDeclaredField(\"mWebView\"); fieldWebView.setAccessible(true); WebView webView = (WebView) fieldWebView.get(this); webView.removeAllViews(); webView.destroy(); &#125;catch (NoSuchFieldException e) &#123; e.printStackTrace(); &#125;catch (IllegalArgumentException e) &#123; e.printStackTrace(); &#125;catch (IllegalAccessException e) &#123; e.printStackTrace(); &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; this.finish(); &#125; 注意：因为用到了反射去清理webview，所以混淆时，这个方法所在的类不能混淆 2.部分手机h5 game屏幕闪烁 在小米的某些手机上，会出现这种情况。抱歉，还没有好的解决办法。谁有好的解决办法可以邮件告知，多谢 :) 3.android Webview替代品Crosswalk Crosswalk解决4,2以下的手机浏览器的兼容性问题。对html5的支持更好 Crosswalk官网 但Crosswalk也有缺点，将Crosswalk嵌入App中，会使APK增加大约20M。具体可以看这个知乎提问 4.腾讯浏览服务 官网地址 2.WebView防止远程代码攻击 1.使用Android4.2以上的系统，通过在Java的远程方法上面声明一个@JavascriptInterface，可以预防改安全漏洞 2.低于Android4.2的系统，如果系统自己添加了一个叫searchBoxJavaBridge_的Js接口，则需要把这个接口删除 详情参见这篇文章：Android WebView的Js对象注入漏洞解决方案 这里贴一个自己整理的webview类：BaseWebView 3.Android中WebView的JavaScript代码和本地代码交互的三种方式来自姜维的博客:Android中WebView的JavaScript代码和本地代码交互的三种方式 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/07/25/android-webview-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"webview","slug":"webview","permalink":"http://agehua.github.io/tags/webview/"}]},{"title":"Gson解析使用总结","slug":"gson-summary","date":"2016-06-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2016/06/08/gson-summary/","link":"","permalink":"http://agehua.github.io/2016/06/08/gson-summary/","excerpt":"1.Gson解析总结，就两种情况Gson 是Google提供的用来在Java对象和JSON数据之间进行映射的Java类库。可以将一个JSON字符串转成一个Java对象，或者将Java对象转成一个JSON字符串。使用Gson来解析时，总结一下，就两句话：\n\n1.遇到“{”字符，表示单个对象，直接用XXXBean.class类去映射\n2.遇到“[”字符，表示对象数组，要用XXXBean[].class或list去映射\n","text":"1.Gson解析总结，就两种情况Gson 是Google提供的用来在Java对象和JSON数据之间进行映射的Java类库。可以将一个JSON字符串转成一个Java对象，或者将Java对象转成一个JSON字符串。使用Gson来解析时，总结一下，就两句话： 1.遇到“{”字符，表示单个对象，直接用XXXBean.class类去映射 2.遇到“[”字符，表示对象数组，要用XXXBean[].class或list去映射 2.第一种情况，举例 json字符串是： &#123; \"items\": [ &#123; \"key\": \"H60-L12__1464938219953__346589_483\", \"hash\": \"Fip_In4BhB5syoZ28W3l_eb6rBDU\", \"fsize\": 348120, \"mimeType\": \"image/jpeg\", \"putTime\": 14649382507765902 &#125;, &#123; \"key\": \"H60-L12__1465352164202__397253_2946\", \"hash\": \"Fs-UwiosdckN9kVY01GrOYC-b7a9\", \"fsize\": 938413, \"mimeType\": \"image/jpeg\", \"putTime\": 14653521712332144 &#125;, &#123; \"key\": \"H60-L12__1465352548728__322577_4114\", \"hash\": \"Frga_QiMJVb9caiuwMlJABCsu1rc\", \"fsize\": 506921, \"mimeType\": \"image/jpeg\", \"putTime\": 14653525989907168 &#125; ]&#125; 分析 最开始是一个“{”字符，所以需要用gson.fromJson(jsonstring, XXXBean.class)来解析。同时，XXXBean中只有一个字段items。items里面是一个“[”字符，表示items里面是数组，可以用list去映射。 解析时， 最后对应的Gson对象就是： public class XXXBean &#123; public List&lt;XXXItem&gt; items; public List&lt;XXXItem&gt; getItems() &#123; return items; &#125; public void setItems(List&lt;XXXItem&gt; items) &#123; this.items = items; &#125; public static class XXXItem &#123; private String key; private String hash; private String fsize; private String mimeType; private String putTime; ... &#125;&#125;Gson gson = new Gson();List&lt;XXXBean.XXXItem&gt; list = gson.fromJson(jsonstring,XXXBean.class).getItems(); 3.第二种情况，举例json字符串以“[”开头。 例如，json==[{“id”:1,”name”:”李坤”,”birthDay”:”Jun 22, 2012 8:28:52 AM”},{“id”:2,”name”:”曹贵生”,”birthDay”:”Jun 22, 2012 8:28:52 AM”},{“id”:3,”name”:”柳波”,”birthDay”:”Jun 22, 2012 8:28:52 AM”}] 解析时，需要使用list来接收。 List&lt;Student&gt; retList = gson.fromJson(jsonstring2, new TypeToken&lt;List&lt;Student&gt;&gt;()&#123;&#125;.getType()); 也可以这样 Student[] students= gson.fromJson(jsonstring2,new Student[].class); 对应list为什么要使用TypeToken？ TypeToken是Gson提供的，来实现对泛型的支持 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/06/08/gson-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gson","slug":"gson","permalink":"http://agehua.github.io/tags/gson/"}]},{"title":"七牛android使用总结","slug":"qiniu-android-summary","date":"2016-05-27T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/05/28/qiniu-android-summary/","link":"","permalink":"http://agehua.github.io/2016/05/28/qiniu-android-summary/","excerpt":"1.在android上实现对七牛空间操作  在android上实现对七牛空间的各种操作，包括list，delete，upload，download。支持私有空间\n  注意：官方不建议开发者把AccessKey和SecretKey放在前端的java文件里，最好还是有一台应用服务器\n  如果只是想尝试一下，好吧:)  代码中都有说明，直接上代码","text":"1.在android上实现对七牛空间操作 在android上实现对七牛空间的各种操作，包括list，delete，upload，download。支持私有空间 注意：官方不建议开发者把AccessKey和SecretKey放在前端的java文件里，最好还是有一台应用服务器 如果只是想尝试一下，好吧:) 代码中都有说明，直接上代码 2.代码一共有三个类： 工具类： package com.qiniu.ui.utils;import android.graphics.Bitmap;import android.graphics.Bitmap.CompressFormat;import android.os.Environment;import android.util.Log;import com.loopj.android.http.AsyncHttpClient;import com.loopj.android.http.AsyncHttpResponseHandler;import com.loopj.android.http.RequestParams;import com.qiniu.android.storage.UpProgressHandler;import com.qiniu.android.storage.UploadManager;import com.qiniu.android.storage.UploadOptions;import com.qiniu.android.utils.UrlSafeBase64;import com.qiniu.api.auth.AuthException;import com.qiniu.api.auth.digest.Mac;import com.qiniu.api.rs.PutPolicy;import com.qiniu.ui.SHA;import com.qiniu.ui.contains.QiNiuConfig;import org.apache.http.Header;import org.json.JSONException;import java.io.BufferedOutputStream;import java.io.FileOutputStream;import java.util.Random;import static com.qiniu.ui.SHA.hMacSHA1Encrypt;/** * @date 2016年5月26日 上午11:00:43 * @author lijixin * @web https://agehua.github.io * @Description: 七牛云图片操作 */public class QiniuUitls &#123; private static final String fileName = \"temp.jpg\"; private static final String tempJpeg = Environment.getExternalStorageDirectory().getPath() + \"/\" + fileName; private static int maxWidth = 720; private static int maxHeight = 1080; public interface QiniuUploadUitlsListener &#123; void onSucess(String fileUrl); void onError(int errorCode, String msg); void onProgress(int progress); &#125; public interface QiniuRequestListener &#123; void onSucceed(byte[] bytes); void onFailed(byte[] bytes); &#125; /** * 将bitmap转换成jpeg，控制图片大小不大于720*1080，可以指定图片压缩质量 * @param bitmap * @param filePath * @param quality * @return */ public static boolean saveBitmapToJpegFile(Bitmap bitmap, String filePath, int quality) &#123; try &#123; FileOutputStream fileOutStr = new FileOutputStream(filePath); BufferedOutputStream bufOutStr = new BufferedOutputStream(fileOutStr); resizeBitmap(bitmap).compress(CompressFormat.JPEG, quality, bufOutStr); bufOutStr.flush(); bufOutStr.close(); &#125; catch (Exception exception) &#123; return false; &#125; return true; &#125; /** * 缩小图片 * * @param bitmap * @return */ public static Bitmap resizeBitmap(Bitmap bitmap) &#123; if (bitmap != null) &#123; int width = bitmap.getWidth(); int height = bitmap.getHeight(); //宽度大于720 if (width &gt; maxWidth) &#123; //按宽度等比例压缩图片 int pWidth = maxWidth; int pHeight = maxWidth * height / width; Bitmap result = Bitmap.createScaledBitmap(bitmap, pWidth, pHeight, false); bitmap.recycle(); return result; &#125; if (height &gt; maxHeight) &#123; //按高度等比例缩小图片 int pHeight = maxHeight; int pWidth = maxHeight * width / height; Bitmap result = Bitmap.createScaledBitmap(bitmap, pWidth, pHeight, false); bitmap.recycle(); return result; &#125; &#125; return bitmap; &#125; public static void uploadImage(Bitmap bitmap, QiniuUploadUitlsListener listener) &#123; saveBitmapToJpegFile(bitmap, tempJpeg,100); uploadImage(tempJpeg, listener); &#125; /** * 上传图片选择jpg格式，七牛图片api目前支持对jpg格式进行指定图片质量请求 * @param filePath * @param listener */ public static void uploadImage(String filePath, final QiniuUploadUitlsListener listener) &#123; final String fileUrlUUID = getFileUrlUUID(); String token = getToken(); if (token == null) &#123; if (listener != null) &#123; listener.onError(-1, \"token is null\"); &#125; return; &#125; UploadManager uploadManager = new UploadManager(); uploadManager.put(filePath, fileUrlUUID, token, (key, info, response) -&gt; &#123; System.out.println(\"debug:info = \" + info + \",response = \" + response); if (info != null &amp;&amp; info.statusCode == 200) &#123;// 上传成功 String fileRealUrl = getRealUrl(fileUrlUUID); System.out.println(\"debug:fileRealUrl = \" + fileRealUrl); if (listener != null) &#123; listener.onSucess(fileRealUrl); &#125; &#125; else &#123; if (listener != null) &#123; listener.onError(info.statusCode, info.error); &#125; &#125; &#125;, new UploadOptions(null, null, false, new UpProgressHandler() &#123; public void progress(String key, double percent) &#123; if (listener != null) &#123; listener.onProgress((int) (percent * 100)); &#125; &#125; &#125;, null)); &#125; /** * 生成远程文件路径（全局唯一） * &lt;p&gt;格式类似： H60-L12__1464851303930__156750_1884&lt;/p&gt; * @return */ private static String getFileUrlUUID() &#123; String filePath = android.os.Build.MODEL + \"__\" + System.currentTimeMillis() + \"__\" + (new Random().nextInt(500000)) + \"_\" + (new Random().nextInt(10000)); return filePath.replace(\".\", \"0\"); &#125; private static String getRealUrl(String fileUrlUUID) &#123; String filePath = \"http://\" + QiNiuConfig.QINIU_BUCKNAME + \".qiniudn.com/\" + fileUrlUUID; return filePath; &#125; /** * 获取token 本地生成 * * @return */ private static String getToken() &#123; Mac mac = new Mac(QiNiuConfig.QINIU_AK, QiNiuConfig.QINIU_SK); PutPolicy putPolicy = new PutPolicy(QiNiuConfig.QINIU_BUCKNAME); putPolicy.returnBody = \"&#123;\\\"name\\\": $(fname),\\\"size\\\": \\\"$(fsize)\\\",\\\"w\\\": \\\"$(imageInfo.width)\\\",\\\"h\\\": \\\"$(imageInfo.height)\\\",\\\"key\\\":$(etag)&#125;\"; try &#123; String uptoken = putPolicy.token(mac); System.out.println(\"debug:uptoken = \" + uptoken); return uptoken; &#125; catch (AuthException e) &#123; e.printStackTrace(); &#125; catch (JSONException e) &#123; e.printStackTrace(); &#125; return null; &#125; /** * 根据host和文件名，生成file的url下载地址，支持私有空间 * @param domain host：七牛的私有空间域名 * @param imgKey file key：空间里的文件名 * @return url下载地址 */ public static String downloadFile(String domain,String imgKey)&#123; //密钥配置 //构造私有空间的需要生成的下载的链接// String domain =\"http://example.xxx.clouddn.com/\";// String path =\"H60-L12__1464917382714__36888_5255\"; StringBuilder sb =new StringBuilder(); //加上过期时间戳字段 String url = sb.append(domain).append(imgKey).append(\"?e=1478365261\").toString(); Log.e(\"encodedEntryURI\",url); byte[] sign =null; try &#123; sign = SHA.hMacSHA1Encrypt(url,QiNiuConfig.QINIU_SK); &#125; catch (Exception e) &#123; e.printStackTrace(); &#125; String encodedSign = UrlSafeBase64.encodeToString(sign); sb.append(\"&amp;token=\").append(QiNiuConfig.QINIU_AK).append(\":\").append(encodedSign); Log.e(\"download token\",sb.toString()); return sb.toString(); &#125; /** * 列出空间中指定格式的文件 * @param bucket 空间名 * @param prefix 要指定的格式（前缀） * @param listener * @return */ public static void listFile(String bucket, String prefix,final QiniuRequestListener listener)&#123; try&#123; StringBuilder sb = new StringBuilder(); String entryUrl = sb.append(\"bucket=\").append(bucket) .append(\"&amp;prefix=\").append(prefix).toString(); String host = \"http://rsf.qbox.me\"; String path = \"/list?\" +entryUrl; String url = host+path; Log.e(\"AAAAAAA\", url); byte[] sign = SHA.hMacSHA1Encrypt(path+\"\\n\", QiNiuConfig.QINIU_SK); String encodedSign = UrlSafeBase64.encodeToString(sign); String authorization = QiNiuConfig.QINIU_AK + ':' + encodedSign; AsyncHttpClient client = new AsyncHttpClient(); client.addHeader(\"Content-Type\",\"application/x-www-form-urlencoded\"); client.addHeader(\"Authorization\", \"QBox \"+authorization); RequestParams params = new RequestParams(); client.post(url, params, new AsyncHttpResponseHandler() &#123; @Override public void onSuccess(int i, Header[] headers, byte[] bytes) &#123; if (null!=listener) listener.onSucceed(bytes); &#125; @Override public void onFailure(int i, Header[] headers, byte[] bytes, Throwable throwable) &#123; if (null!=listener) listener.onFailed(bytes); &#125; &#125;); &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; return ; &#125; /** * 删除空间中的文件 * @param bucket 删除文件的空间 * @param fileName 删除的文件 * */ public static boolean deleteFile(String bucket,String fileName,final QiniuRequestListener listener)&#123; try&#123; String entryUrl = bucket+\":\"+fileName; String encodedEntryURI = UrlSafeBase64.encodeToString(entryUrl.getBytes()); String host = \"http://rs.qiniu.com\"; String path = \"/delete/\"+encodedEntryURI; String url = host+path; Log.e(\"AAAAAAA\", url); byte[] sign = hMacSHA1Encrypt(path+\"\\n\", QiNiuConfig.QINIU_SK); String encodedSign = UrlSafeBase64.encodeToString(sign); String authorization = QiNiuConfig.QINIU_AK + ':' + encodedSign; AsyncHttpClient client = new AsyncHttpClient(); client.addHeader(\"Content-Type\",\"application/x-www-form-urlencoded\"); client.addHeader(\"Authorization\", \"QBox \"+authorization); RequestParams params = new RequestParams(); client.post(url, params, new AsyncHttpResponseHandler() &#123; @Override public void onSuccess(int i, Header[] headers, byte[] bytes) &#123; if (null!=listener) listener.onSucceed(bytes); &#125; @Override public void onFailure(int i, Header[] headers, byte[] bytes, Throwable throwable) &#123; if (null!=listener) listener.onFailed(bytes); if (null!=bytes) &#123; String s = new String(bytes); &#125; &#125; &#125;); &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; return false; &#125;&#125; HMAC-SHA1签名加密类 使用下面方法生成对应七牛资源管理里用到的管理凭证 /** * 对外提供HMAC-SHA1签名方法 * @author agehua * */public class SHA &#123; private static final String MAC_NAME = \"HmacSHA1\"; private static final String ENCODING = \"UTF-8\"; /** * * 使用 HMAC-SHA1 签名方法对对encryptText进行签名 * @param encryptText 被签名的字符串 * @param encryptKey 密钥 * @return * @throws Exception */ public static byte[] hMacSHA1Encrypt(String encryptText, String encryptKey) throws Exception &#123; byte[] data = encryptKey.getBytes(ENCODING); // 根据给定的字节数组构造一个密钥,第二参数指定一个密钥算法的名称 SecretKey secretKey = new SecretKeySpec(data, MAC_NAME); // 生成一个指定 Mac 算法 的 Mac 对象 Mac mac = Mac.getInstance(MAC_NAME); // 用给定密钥初始化 Mac 对象 mac.init(secretKey); byte[] text = encryptText.getBytes(ENCODING); // 完成 Mac 操作 return mac.doFinal(text); &#125;&#125; ~~~ - 还有一个Config文件~~~ Javapublic final class QiNiuConfig &#123; public static final String token = getToken(); public static final String QINIU_AK = \"Your_AccessKey\"; public static final String QINIU_SK = \"Your_SecretKey\"; public static final String QINIU_BUCKNAME = \"你的私有空间\"; public static String getToken() &#123; Mac mac = new Mac(QiNiuConfig.QINIU_AK, QiNiuConfig.QINIU_SK); PutPolicy putPolicy = new PutPolicy(QiNiuConfig.QINIU_BUCKNAME); putPolicy.returnBody = \"&#123;\\\"name\\\": $(fname),\\\"size\\\": \\\"$(fsize)\\\",\\\"w\\\": \\\"$(imageInfo.width)\\\",\\\"h\\\": \\\"$(imageInfo.height)\\\",\\\"key\\\":$(etag)&#125;\"; try &#123; String uptoken = putPolicy.token(mac); System.out.println(\"debug:uptoken = \" + uptoken); return uptoken; &#125; catch (AuthException e) &#123; e.printStackTrace(); &#125; catch (JSONException e) &#123; e.printStackTrace(); &#125; return null; &#125;&#125; 点击在Gist上查看上面这些代码 最后，如果有问题欢迎讨论，我的邮箱简介里有 :) 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/28/qiniu-android-summary/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"qiniu","slug":"qiniu","permalink":"http://agehua.github.io/tags/qiniu/"}]},{"title":"android JNI学习① 基础知识","slug":"JNI-Learning","date":"2016-05-23T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/05/24/JNI-Learning/","link":"","permalink":"http://agehua.github.io/2016/05/24/JNI-Learning/","excerpt":"本文只是用来记录，写的不好还请见谅。\n1.JNI介绍JNI概念 : Java本地接口,Java Native Interface, 它是一个协议, 该协议用来沟通Java代码和外部的本地C/C++代码, 通过该协议 Java代码可以调用外部的本地代码, 外部的C/C++ 代码可以调用Java代码;\nC和Java的侧重 :\n\nC语言 : C语言中最重要的是 函数 function;\nJava语言 : Java中最重要的是 JVM, class类, 以及class中的方法;\n\nC与Java如何交流 :\n\nJNI规范 : C语言与Java语言交流需要一个适配器, 中间件, 即 JNI, JNI提供了一种规范;\nC语言中调用Java方法 : 可以让我们在C代码中找到Java代码class中的方法, 并且调用该方法;\nJava语言中调用C语言方法 : 同时也可以在Java代码中, 将一个C语言的方法映射到Java的某个方法上;\nJNI桥梁作用 : JNI提供了一个桥梁, 打通了C语言和Java语言之间的障碍;\n","text":"本文只是用来记录，写的不好还请见谅。 1.JNI介绍JNI概念 : Java本地接口,Java Native Interface, 它是一个协议, 该协议用来沟通Java代码和外部的本地C/C++代码, 通过该协议 Java代码可以调用外部的本地代码, 外部的C/C++ 代码可以调用Java代码; C和Java的侧重 : C语言 : C语言中最重要的是 函数 function; Java语言 : Java中最重要的是 JVM, class类, 以及class中的方法; C与Java如何交流 : JNI规范 : C语言与Java语言交流需要一个适配器, 中间件, 即 JNI, JNI提供了一种规范; C语言中调用Java方法 : 可以让我们在C代码中找到Java代码class中的方法, 并且调用该方法; Java语言中调用C语言方法 : 同时也可以在Java代码中, 将一个C语言的方法映射到Java的某个方法上; JNI桥梁作用 : JNI提供了一个桥梁, 打通了C语言和Java语言之间的障碍; JNI中的一些概念 : native : Java语言中修饰本地方法的修饰符, 被该修饰符修饰的方法没有方法体; Native方法 : 在Java语言中被native关键字修饰的方法是Native方法; JNI层 : Java声明Native方法的部分; JNI函数 : JNIEnv提供的函数, 这些函数在jni.h中进行定义; JNI方法 : Native方法对应的JNI层实现的 C/C++方法, 即在jni目录中实现的那些C语言代码; 2.NDK简单介绍C代码执行 : C代码被编译成库文件之后, 才能执行, 库文件分为动态库 和静态库 两种; 动态库 : unix环境下.so后缀的是动态库, windows环境下.dll 后缀的是动态库; 动态库可以依赖静态库加载一些可执行的C代码; 静态库 :.a后缀是静态库的扩展名; 库文件来源 : C代码 进行 编译 链接操作之后, 才会生成库文件, 不同类型的CPU 操作系统 生成的库文件是不一样; CPU分类 : arm结构, 嵌入式设备处理器; x86结构, pc服务器处理器; 不同的CPU指令集不同; 交叉编译 :windows x86编译出来的库文件可以在arm平台运行的代码; 交叉编译工具链 : Google提供的 NDK 就是交叉编译工具链, 可以在linux环境下编译出在arn平台下执行的二进制库文件; NDK作用 : 是Google提供了交叉编译工具链, 能够在linux平台编译出在arm平台下执行的二进制库文件; NDK版本介绍 : android-ndk-windows 是在windows系统中的cygwin使用的, android-ndk-linux 是在linux下使用的; 想深入了解NDK开发的同学，可以去安装一下cygwin，本文只涉及简单的C语言代码，不需要使用cygwin。 3.环境准备，使用android studio还是Eclipse推荐使用Eclipse，这篇文章讲了使用Eclipse生成.h文件和生成so文件的配置过程。配置成功后可以远离命令行Eclipse ADT插件生成.h/.so文件 3.1 Java调用C流程 a. 定义 Native 方法 : 比如在com.packagename.jni.JNITest.java 类中定义 Native 方法 public native int add(int x, int y); b. 生成方法签名 : 进入 AndroidProject/bin/classes 目录, 使用 javah com.packagename.jni.JNITest 命令, 便生成了头文件, 该头文件引用了 jni.h, 以及定义好了对应的 Native 方法, 生成 JNIEXPORT jint JNICALL Java_com_packagename_jni_JNITest_add (JNIEnv *, jobject, jint, jint); Java中定义的方法 : //将Java中的两个int值 传给C语言, 进行相加后, 返回java语言 shuliang.han.ndkparameterpassing.DataProvider public native int add(int x, int y); 对应C语言中定义的方法 : #include &lt;jni.h&gt; //方法签名, Java环境和调用native方法的类必不可少, 后面的参数就是native方法的参数 jint Java_com_packagename_jni_JNITest_add(JNIEnv * env, jobject obj, jint x, jint y) &#123; return x + y; &#125; 3.2 生成.so文件Android.mk 文件： LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := hello-jni LOCAL_SRC_FILES := hello-jni.c include $(BUILD_SHARED_LIBRARY) 文件内容解释： 获取当前文件内容 : $(call my-dir) 是编译器中的宏方法, 调用该宏方法, 就会返回前的目录路径; 赋值符号 : “ := “ 是赋值符号, 第一句话 是 返回当前文件所在的当前目录, 并将这个目录路径赋值给 LOCAL_PATH; 初始化编译模块参数 : $(CLEAR_VARS) 作用是将编译模块的参数初始化, LOCAL_MODULE LOCAL_SRC_FILES 也是这样的参数; 指定编译模块 : LOCAL_MODULE := hello-jni , 指定编译后的 so 文件名称, 编译好之后系统会在该名称前面加上 “lib”, 后缀加上 “.so”; 指定编译源文件 : LOCAL_SRC_FILES := hello-jni.c 告诉编译系统源文件, 如果有多个文件那么就依次写在后面即可; 编译成静态库 : include $(BUILD_SHARED_LIBRARY), 作用是告诉系统, 将编译的结果编译成.so后缀的静态库; 静态库引入 : NDK的platform中有很多 “.a” 结尾的动态库, 我们编译动态库的时候, 可以将一些静态库引入进来; 生成 动态库 so 文件 : 进入 Android.mk 所在目录, 在该目录执行ndk下的ndk-build命令; Java代码加载动态库 : 在 Java 代码中调用该类的类前面, 在类的一开始, 不在方法中, 加入 static&#123; System.loadLibrary(\"hello\"); &#125; ; Application.mk 文件内容为（不写这个文件也可以）: APP_STL := stlport_staticAPP_ABI := all 这篇文章是使用javah导出头文件过程中，常见错误和解决办法，这里做一个记录。 4.字符串的处理 Java中的String转为C语言中的char字符串下面的工具方法可以在C程序中解决这个问题： // java中的jstring, 转化为c的一个字符数组 char* Jstring2CStr(JNIEnv* env, jstring jstr) &#123; //声明了一个字符串变量 rtn char* rtn = NULL; //找到Java中的String的Class对象 jclass clsstring = (*env)-&gt;FindClass(env, \"java/lang/String\"); //创建一个Java中的字符串 \"GB2312\" jstring strencode = (*env)-&gt;NewStringUTF(env, \"GB2312\"); /* * 获取String中定义的方法 getBytes(), 该方法的参数是 String类型的, 返回值是 byte[]数组 * \"(Ljava/lang/String;)[B\" 方法前面解析 : * -- Ljava/lang/String; 表示参数是String字符串 * -- [B : 中括号表示这是一个数组, B代表byte类型, 返回值是一个byte数组 */ jmethodID mid = (*env)-&gt;GetMethodID(env, clsstring, \"getBytes\", \"(Ljava/lang/String;)[B\"); //调用Java中的getBytes方法, 传入参数介绍 参数②表示调用该方法的对象, 参数③表示方法id , 参数④表示方法参数 jbyteArray barr = (jbyteArray)(*env)-&gt;CallObjectMethod(env, jstr, mid, strencode); // String .getByte(\"GB2312\"); //获取数组的长度 jsize alen = (*env)-&gt;GetArrayLength(env, barr); //获取数组中的所有的元素 , 存放在 jbyte*数组中 jbyte* ba = (*env)-&gt;GetByteArrayElements(env, barr, JNI_FALSE); //将Java数组中所有元素拷贝到C的char*数组中, 注意C语言数组结尾要加一个 '\\0' if (alen &gt; 0) &#123; rtn = (char*) malloc(alen + 1); //new char[alen+1]; \"\\0\" memcpy(rtn, ba, alen); rtn[alen] = 0; &#125; (*env)-&gt;ReleaseByteArrayElements(env, barr, ba, 0); //释放内存 return rtn; &#125; Jstring2CStr方法讲解 : a. 获取Java中String类型的class对象 : 参数 : 上下文环境 env, String类完整路径 ; jclass clsstring = (*env)-&gt;FindClass(env, \"java/lang/String\"); b.创建Java字符串 : 使用 NewStringUTF 方法; jstring strencode = (*env)-&gt;NewStringUTF(env, \"GB2312\"); ~~~ - c.获取String中的getBytes()方法 : 参数介绍 ① env 上下文环境 ② 完整的类路径 ③ 方法名 ④ 方法签名, 方法签名 Ljava/lang/String; 代表参数是String字符串, [B 中括号表示这是一个数组, B代表byte类型, 返回值是一个byte数组;~~~ JavascriptjmethodID mid = (*env)-&gt;GetMethodID(env, clsstring, \"getBytes\", \"(Ljava/lang/String;)[B\"); ~~~ - d. 获取数组的长度 :~~~ Javascriptjsize alen = (*env)-&gt;GetArrayLength(env, barr); e. 获取数组元素 : 获取数组中的所有的元素 , 存放在 jbyte*数组中; jbyte* ba = (*env)-&gt;GetByteArrayElements(env, barr, JNI_FALSE); f.数组拷贝: 将Java数组中所有元素拷贝到C的char*数组中, 注意C语言数组结尾要加一个 ‘\\0’; if (alen &gt; 0) &#123; rtn = (char*) malloc(alen + 1); //new char[alen+1]; \"\\0\" memcpy(rtn, ba, alen); rtn[alen] = 0; &#125; g.释放内存 : (*env)-&gt;ReleaseByteArrayElements(env, barr, ba, 0); //释放内存 5.JNI方法命名规则(标准JNI规范) JNI实现的方法与Java中Native方法的映射关系 : 使用方法名进行映射, 可以使用javah工具进入bin/classes目录下执行命令, 即可生成头文件; JNI方法参数介绍: 参数① : 第一个参数是JNI接口指针JNIEnv; 参数② : 如果Native方法是非静态的, 那么第二个参数就是对Java对象的引用, 如果Native方法是静态的, 那么第二个参数就是对Java类的Class对象的引用; JNI方法名规范: 返回值+Java前缀+全路径类名+方法名+参数① JNIEnv+参数② jobject+其它参数; 注意分隔符 : Java前缀 与 类名 以及类名之间的包名 和 方法名之间 使用 “_“ 进行分割; 声明 非静态 方法: Native方法 : public int hello (String str, int i); JNI方法: jint Java_shuliang_han_Hello_hello(JNIEnv * env, jobject obj, jstring str, jint i); 声明 静态 方法 : Native方法 : public static int hello (String str, int i); JNI方法 : jint Java_shuliang_han_Hello_hello(JNIEnv * env, jobject clazz, jstring str, jint i); 两种规范 : 以上是Java的标准JNI规范, 在Android中还有一套自定义的规范, 该规范是Android应用框架层 和 框架层交互使用的JNI规范, 依靠方法注册 映射 Native方法 和 JNI方法; JNIEnv作用 : JNIEnv 是一个指针,指向了一组JNI函数, 这些函数可以在jni.h中查询到,通过这些函数可以实现 Java层 与 JNI层的交互 , 通过JNIEnv 调用JNI函数 可以访问java虚拟机, 操作java对象; JNI线程相关性 : JNIEnv只在当前的线程有效,JNIEnv不能跨线程传递, 相同的Java线程调用本地方法, 所使用的JNIEnv是相同的, 一个Native方法不能被不同的Java线程调用; JNIEnv结构体系 : JNIEnv指针指向一个线程相关的结构,线程相关结构指向一个指针数组,指针数组中的每个元素最终指向一个JNI函数. 6.AES加密实现网上有几种AES实现的方式： 1.这个是我现在项目中使用的方法，在Github上有这个工程，这种方式是使用JNI生成一个与设备相关的密码，可以将该密码作为AES的密钥。链接地址 2.网上还有一种方式是由JNI生成keyValue和iv，Java层使用：链接地址 主要代码： static &#123; System.loadLibrary(\"cwtlib\"); keyValue = getKeyValue(); iv = getIv(); if(null != keyValue &amp;&amp; null != iv) &#123; KeyGenerator kgen; try &#123; kgen = KeyGenerator.getInstance(\"AES\"); kgen.init(128, new SecureRandom(keyValue)); key = kgen.generateKey(); paramSpec = new IvParameterSpec(iv); ecipher = Cipher.getInstance(\"AES/CBC/PKCS5Padding\"); &#125; catch (NoSuchAlgorithmException e) &#123; &#125; catch (NoSuchPaddingException e) &#123; &#125; &#125;&#125; public static native byte[] getKeyValue();public static native byte[] getIv(); 这种方式，在android app程序完全退出后，再进入该app时，之前加密好的字符串无法解密。 3.还有一种是直接由C或C++实现AES整个算法，直接使用网上代码并不知道靠不靠谱 所以，我们项目最终使用了第一种方法 7.JNI混淆问题 检查下 C/C++代码中没有直接访问Java代码的类或者类的成员变量、类的成员函数。 如果有的话，这些就不能混淆 //保留jni的回调类-keep class com.your.jnicallback.class &#123; *; &#125;//这个不用更改，直接复制就可以-keepclasseswithmembernames class * &#123; native &lt;methods&gt;;&#125; 8.总结android 实现JNI入门并不难，笔者也刚刚入门，但要深入了解还是需要很长的路要走。 8.1 更新内容，JNI获取publickey实现在本文中最终使用第6点中的第一种方式，但原方法在4.0.4手机上遇到兼容性问题，详情请看我的这篇博客使用JNI获取publickey实现 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/24/JNI-Learning/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"JNI","slug":"jni","permalink":"http://agehua.github.io/tags/jni/"},{"name":"AES","slug":"aes","permalink":"http://agehua.github.io/tags/aes/"}]},{"title":"android JNI学习② JNI调用过程","slug":"JNI-Learning0","date":"2016-05-23T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/05/24/JNI-Learning0/","link":"","permalink":"http://agehua.github.io/2016/05/24/JNI-Learning0/","excerpt":"1.Android JNI调用过程1.1 由Android系统加载的JNIAndroid系统在启动启动过程中，先启动Kernel创建init进程，紧接着由init进程fork第一个横穿Java和C/C++的进程，即Zygote进程。Zygote启动过程中会AndroidRuntime.cpp中的startVm创建虚拟机，VM创建完成后，紧接着调用startReg完成虚拟机中的JNI方法注册。","text":"1.Android JNI调用过程1.1 由Android系统加载的JNIAndroid系统在启动启动过程中，先启动Kernel创建init进程，紧接着由init进程fork第一个横穿Java和C/C++的进程，即Zygote进程。Zygote启动过程中会AndroidRuntime.cpp中的startVm创建虚拟机，VM创建完成后，紧接着调用startReg完成虚拟机中的JNI方法注册。 在AndroidRuntime.cpp中： int AndroidRuntime::startReg(JNIEnv* env)&#123; //设置线程创建方法为javaCreateThreadEtc androidSetCreateThreadFunc((android_create_thread_fn) javaCreateThreadEtc); env-&gt;PushLocalFrame(200); //进程NI方法的注册 if (register_jni_procs(gRegJNI, NELEM(gRegJNI), env) &lt; 0) &#123; env-&gt;PopLocalFrame(NULL); return -1; &#125; env-&gt;PopLocalFrame(NULL); return 0;&#125; register_jni_procs(gRegJNI, NELEM(gRegJNI), env)这行代码的作用就是就是循环调用gRegJNI数组成员所对应的方法。 static int register_jni_procs(const RegJNIRec array[], size_t count, JNIEnv* env)&#123; for (size_t i = 0; i &lt; count; i++) &#123; if (array[i].mProc(env) &lt; 0) &#123; return -1; &#125; &#125; return 0;&#125; gRegJNI数组，有100多个成员变量，定义在AndroidRuntime.cpp： static const RegJNIRec gRegJNI[] = &#123; REG_JNI(register_android_os_MessageQueue), REG_JNI(register_android_os_Binder), ...&#125;; 该数组的每个成员都代表一个类文件的jni映射，其中REG_JNI是一个宏定义，该宏的作用就是调用相应的方法。 比如MessageQueue和Binder方法都是Android系统启动时就已经注册，所以在AndroidRuntime.cpp中可以找到相应的native方法，见AndroidRuntime.cpp的gRegJNI数组。这些注册方法命令格式为： register_[包名]_[类名] 示例一：以MessageQueue.java中的nativePollOnce方法为例，private native void nativePollOnce(long ptr, int timeoutMillis); 方法名：android.os.MessageQueue.nativePollOnce()，而相对应的native层方法名只是将点号替换为下划线，可得android_os_MessageQueue_nativePollOnce()。 前面说MessageQueue.java所定义的jni注册方法名应该是register_android_os_MessageQueue，的确存在于gRegJNI数组，说明这次JNI注册过程是有开机过程完成的。该方法在AndroidRuntime.cpp申明为extern方法： extern int register_android_os_MessageQueue(JNIEnv* env); 这些extern方法绝大多数位于/framework/base/core/jni/目录，大多数情况下native文件命名方式： [包名]_[类名].cpp[包名]_[类名].h Tips： MessageQueue.java ==&gt; android_os_MessageQueue.cpp 打开android_os_MessageQueue.cpp文件，搜索android_os_MessageQueue_nativePollOnce方法，这便找到了目标方法： static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj, jlong ptr, jint timeoutMillis) &#123; NativeMessageQueue* nativeMessageQueue = reinterpret_cast&lt;NativeMessageQueue*&gt;(ptr); nativeMessageQueue-&gt;pollOnce(env, obj, timeoutMillis);&#125; 示例二：对于native文件命名方式，有时并非[包名]_[类名].cpp，比如Binder.javaBinder.java所对应的native文件：android_util_Binder.cpp public static final native int getCallingPid(); 根据示例一方式，找到getCallingPid ==&gt; android_os_Binder_getCallingPid()，并且在AndroidRuntime.cpp中的gRegJNI数组中找到register_android_os_Binder。 按实例(一)方式则native文名应该为android_os_Binder.cpp，可是在/framework/base/core/jni/目录下找不到该文件，这是例外的情况。其实真正的文件名为android_util_Binder.cpp，这就是例外，这一点有些费劲，不明白为何google要如此打破规律的命名。 static jint android_os_Binder_getCallingPid(JNIEnv* env, jobject clazz)&#123; return IPCThreadState::self()-&gt;getCallingPid();&#125; 有人可能好奇，既然如何遇到打破常规的文件命令，怎么办？这个并不难，首先，可以尝试在/framework/base/core/jni/中搜索，对于binder.java，可以直接搜索binder关键字，其他也类似。如果这里也找不到，可以通过grep全局搜索android_os_Binder_getCallingPid这个方法在哪个文件。 jni存在的常见目录： /framework/base/core/jni/ /framework/base/services/core/jni/ /framework/base/media/jni/ 1.2 加载自定义的JNI方法前面两种都是在Android系统启动之初，便已经注册过JNI所对应的方法。 那么如果程序自己定义的jni方法，该如何查看jni方法所在位置呢？下面以MediaPlayer.java为例，其包名为android.media： public class MediaPlayer&#123; static &#123; System.loadLibrary(\"media_jni\"); native_init(); &#125; private static native final void native_init(); ...&#125; 通过static静态代码块中System.loadLibrary方法来加载动态库，库名为media_jni, Android平台则会自动扩展成所对应的libmedia_jni.so库 接下来便要查看libmedia_jni.so库定义所在文件，一般都是通过Android.mk文件定义LOCAL_MODULE:= libmedia_jni，可以采用grep或者mgrep来搜索包含libmedia_jni字段的Android.mk所在路径。 搜索可知，libmedia_jni.so位于/frameworks/base/media/jni/Android.mk。用前面实例(一)中的知识来查看相应的文件和方法名分别为： android_media_MediaPlayer.cppandroid_media_MediaPlayer_native_init() 再然后，你会发现果然在该Android.mk所在目录/frameworks/base/media/jni/中找到android_media_MediaPlayer.cpp文件，并在文件中存在相应的方法： static voidandroid_media_MediaPlayer_native_init(JNIEnv *env)&#123; jclass clazz; clazz = env-&gt;FindClass(\"android/media/MediaPlayer\"); fields.context = env-&gt;GetFieldID(clazz, \"mNativeContext\", \"J\"); ...&#125; Tips：MediaPlayer.java中的native_init方法所对应的native方法位于/frameworks/base/media/jni/目录下的android_media_MediaPlayer.cpp文件中的android_media_MediaPlayer_native_init方法。 总结：System.loadLibrary()的作用就是调用相应库中的JNI_OnLoad()方法。 1.3 说说JNI_OnLoad()过程。[-&gt; android_media_MediaPlayer.cpp] jint JNI_OnLoad(JavaVM* vm, void* reserved)&#123; JNIEnv* env = NULL; if (register_android_media_MediaPlayer(env) &lt; 0) &#123; goto bail; &#125; ...&#125; 详细说一下register_android_media_MediaPlayer [-&gt; android_media_MediaPlayer.cpp] static int register_android_media_MediaPlayer(JNIEnv *env)&#123; //【见3.4】 return AndroidRuntime::registerNativeMethods(env, \"android/media/MediaPlayer\", gMethods, NELEM(gMethods));&#125; 虚拟机相关的变量中有两个非常重要的量JavaVM和JNIEnv: 1.JavaVM：是指进程虚拟机环境，每个进程有且只有一个JavaVM实例 2.JNIEnv：是指线程上下文环境，每个线程有且只有一个JNIEnv实例 其中gMethods，记录java层和C/C++层方法的一一映射关系。 static JNINativeMethod gMethods[] = &#123; &#123;\"prepare\", \"()V\", (void *)android_media_MediaPlayer_prepare&#125;, &#123;\"_start\", \"()V\", (void *)android_media_MediaPlayer_start&#125;, &#123;\"_stop\", \"()V\", (void *)android_media_MediaPlayer_stop&#125;, &#123;\"seekTo\", \"(I)V\", (void *)android_media_MediaPlayer_seekTo&#125;, &#123;\"_release\", \"()V\", (void *)android_media_MediaPlayer_release&#125;, &#123;\"native_init\", \"()V\", (void *)android_media_MediaPlayer_native_init&#125;, ...&#125;; 这里涉及到结构体JNINativeMethod，其定义在jni.h文件： typedef struct &#123; const char* name; //Java层native函数名 const char* signature; //Java函数签名，记录参数类型和个数，以及返回值类型 void* fnPtr; //Native层对应的函数指针&#125; JNINativeMethod; 2.JNI资源JNINativeMethod结构体中有一个字段为signature(签名)，再介绍signature格式之前需要掌握各种数据类型在Java层、Native层以及签名所采用的签名格式。 2.1 数据类型 基本数据类型 Signature格式 Java Native B byte jbyte C char jchar D double jdouble F float jfloat I int jint S short jshort J long jlong Z boolean jboolean V void void 数组数据类型 数组简称则是在前面添加[： Signature格式 Java Native [B byte[] jbyteArray [C char[] jcharArray [D double[] jdoubleArray [F float[] jfloatArray [I int[] jintArray [S short[] jshortArray [J long[] jlongArray [Z boolean[] jbooleanArray 复杂数据类型 对象类型简称：L+classname +; Signature格式 Java Native Ljava/lang/String; String jstring L+classname +; 所有对象 jobject [L+classname +; Object[] jobjectArray Ljava.lang.Class; Class jclass Ljava.lang.Throwable; Throwable jthrowable Signature 有了前面的铺垫，那么再来通过实例说说函数签名： (输入参数…)返回值参数，这里用到的便是前面介绍的Signature格式。 Java函数 对应的签名 void foo() ()V float foo(int i) (I)F long foo(int[] i) ([I)J double foo(Class c) (Ljava/lang/Class;)D boolean foo(int[] i,String s) ([ILjava/lang/String;)Z String foo(int i) (I)Ljava/lang/String; 2.2 其他 (一)垃圾回收对于Java开发人员来说无需关系垃圾回收，完全由虚拟机GC来负责垃圾回收，而对于JNI开发人员，对于内存释放需要谨慎处理，需要的时候申请，使用完记得释放内容，以免发生内存泄露。在JNI提供了三种Reference类型，Local Reference(本地引用)， Global Reference（全局引用）， Weak Global Reference(全局弱引用)。其中Global Reference如果不主动释放，则一直不会释放；对于其他两个类型的引用都是释放的可能性，那是不是意味着不需要手动释放呢？答案是否定的，不管是这三种类型的那种引用，都尽可能在某个内存不再需要时，立即释放，这对系统更为安全可靠，以减少不可预知的性能与稳定性问题。 另外，ART虚拟机在GC算法有所优化，为了减少内存碎片化问题，在GC之后有可能会移动对象内存的位置，对于Java层程序并没有影响，但是对于JNI程序可要小心了，对于通过指针来直接访问内存对象是，Dalvik能正确运行的程序，ART下未必能正常运行。 (二)异常处理Java层出现异常，虚拟机会直接抛出异常，这是需要try..catch或者继续往外throw。但是对于JNI出现异常时，即执行到JNIEnv中某个函数异常时，并不会立即抛出异常来中断程序的执行，还可以继续执行内存之类的清理工作，直到返回到Java层时才会抛出相应的异常。 另外，Dalvik虚拟机有些情况下JNI函数出错可能返回NULL，但ART虚拟机在出错时更多的是抛出异常。这样导致的问题就可能是在Dalvik版本能正常运行的程序，在ART虚拟机上由于没有正确处理异常而崩溃。 3.JNI知识积累JNI学习积累之一 —- 常用函数大全http://blog.csdn.net/qinjuning/article/details/7595104 JNI学习积累之二 —- 数据类型映射、域描述符说明http://blog.csdn.net/qinjuning/article/details/7599796 JNI学习积累之三 —- 操作JNI函数以及复杂对象传递http://blog.csdn.net/qinjuning/article/details/7607214 JNI 实战全面解析http://blog.csdn.net/banketree/article/details/40535325 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/24/JNI-Learning0/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"JNI","slug":"jni","permalink":"http://agehua.github.io/tags/jni/"},{"name":"android source code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"Java String与C/C++中byte[]","slug":"javaString-and-bytes","date":"2016-05-17T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/05/18/javaString-and-bytes/","link":"","permalink":"http://agehua.github.io/2016/05/18/javaString-and-bytes/","excerpt":"   做JAVA经常会碰到中文乱码问题，还有各种编码的问题，特别是String类的内容需要重新编码的问题。要解决这些问题，必须了解清楚JAVA对于字符串是怎么处理的。\n1，“字符”是由数字来表示的   先来重新了解一下计算机是如何处理“字符”的，这个原理是大家必须记住的，特别是在用JAVA写程序的时候，万万不可模糊。我们知道，计算机把任何东西都用数字来表示，“字符”也不例外。比如我们要显示一个阿拉伯数字“3”，在我们的PC里，其实并不是仅仅用一个数字3来代表我们要写的“3”，而是以十六进制的0x33来代表，包括放在内存或者是写到文件里，其实都是写着0x33的，不信你可以编辑一个文本文件，写一个“3”，然后用ultraEdit看他的原始码。","text":"做JAVA经常会碰到中文乱码问题，还有各种编码的问题，特别是String类的内容需要重新编码的问题。要解决这些问题，必须了解清楚JAVA对于字符串是怎么处理的。 1，“字符”是由数字来表示的 先来重新了解一下计算机是如何处理“字符”的，这个原理是大家必须记住的，特别是在用JAVA写程序的时候，万万不可模糊。我们知道，计算机把任何东西都用数字来表示，“字符”也不例外。比如我们要显示一个阿拉伯数字“3”，在我们的PC里，其实并不是仅仅用一个数字3来代表我们要写的“3”，而是以十六进制的0x33来代表，包括放在内存或者是写到文件里，其实都是写着0x33的，不信你可以编辑一个文本文件，写一个“3”，然后用ultraEdit看他的原始码。 2，一切“字符”都必定用数字+编码表表示。 这时候，有一个问题：为什么一定要用0x33来代表“3”呢？而不用0x43来代表呢？或者是直接用0x03来代替？其实用什么来代表都可以，只不过大家都习惯了用ASCII编码表（是美国国家信息交换表）来确定各字符应该是用什么数字代表的。同样，为了表示中国字，我国也指定了中文的编码表，其中最广泛使用的是GB2312。比如中文的“当”字，就是用0xB5, 0xB1这两个八位的数字来表示的。所以 如果显示字符的程序不知道一列数字到底是按什么编码表编码的，他也无法去判断到底这些是什么文字。如果随便用一个不对的编码表来处理这些数字，处理出来的字符很可能完全是错的。比如在英文系统上，没有GB2312编码表，送给他一个0xB5,0xB1，他就傻傻的当作ASCII来处理（操作系统通常都有自己默认的编码表），结果显示出来就是两个奇怪的符号，因为这两个字在ASCII表里就是那两个符号。同样在繁体中文系统里，他的编码表是BIG5，显示出来也是一个奇怪的中文，不是“当”字。 3，UNICODE让全世界都说一种语言 看完上面的文字，是否觉得，世界有那么多语言，每个都有自己的一套编码表，很麻烦呢？就算是中文，也有两套流行的编码表，一个是GB2312，一个是BIG5。要使用不同中文的编码的字符时，还要转来转去，的确很麻烦。不光这个，如果想要写一篇包含很多过国文字的文章，就麻烦了，必须要让处理这个文章的程序知道，哪个字是什么编码标准的。如果你想要在文章里找一个字，也必须指定你要找的是哪种编码的哪个字。否则，你要找一个0xB5,0xB1的中文“当”字，很可能把同样数字表示的日文、波兰文这些不相干的字一起给你找出来，够麻烦的吧！ 所以人们想，不如大家都用同一个编码标准吧，各种文字都在编码表里有一席之地，处理文字的程序只需要都按这个编码表来处理就可以了。不过要一个编码表里包含所有的文字，这张表就大了，本来英文字+数字一共只有128个以内。但加上中文后，忽然就多了数万个，所以存放一个字符需要的大小也大了很多。现在 UNICODE规定了一个字符必须由2个8位数字来表示，想想，8x8x8x8x = 65536，是多大的一个数字啊！所以全世界的文字才能都包含进去。当然拉，也有人说中国字可能都不止6万个拉，还要包括别的文字，但人家外国人觉得你们中国人常用的也没那么多，所以就这么定了，我们也没办法。需要注意的是GB2312和UNICODE虽然都是用两个8位数来代表一个中文字，但具体的规格可不一样，比如0xB5,0xB1在UNICODE里面可不是“当”字，而是另外一国的文字来的。 4，C是如何简洁的处理字符的 我们来谈谈C的字符串。C语言诞生在JAVA之前，C语言的基本数据类型是没有字符串这个类型的，它只有char[]。也就是C把字符顺序放入一个字节数组就完了。而且C也不管放在数组里的是什么文字，也不管那些字是按什么编码标准的。而且他的char的大小也不一定是8位数字，有时候是16位也可能，这要看具体的机器和操作系统。所以写程序的人必须要知道正在处理的char[]的内容到底是按什么编码表表示的字符串，要知道如果比较两国文字是否相同，可是没任何意义的哦！ 5，JAVA是是如何处理字符的。 世界总会进步的，JAVA就是一个例子。JAVA终于有了String类了，它是解决字符问题的最好工具。在JAVA里，一个基本的要点是：String类对象是不需要指定编码表的！ 为什么它会自己知道一堆数字各代表什么字符呢？就是因为 String里的字符信息是用UNICODE编码存放的。而JAVA为了表示字符（注意是单个字符），也有char这个数据类型，而且他的大小是固定2个8位16进制数字长度，也就是0~65535罗。为的就是对应UNICODE里面的一个字符。大家如果想取一个String里的按UNICODE数字，可以用getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) 方法取得一个char[]，这个char[]里就是表示String字符的，按UNICODE编码表编码的数字。 可惜现在绝大多数的系统和程序都不是按UNICODE来处理字符，而JAVA程序总是要和别的程序和系统交换数据的，所以在接收一个字符，或者是发送一个字符的时候，就必须要留意当前系统和UNICODE的关系了。比如你从网络或者文件接受到一数字：0xB5,0xB1，JAVA程序并不知道这两个字到底是中文呢？还是日文，或者英文。你如果不指明这个两个数字的编码表，JAVA就会按当前系统默认的编码表来处理。如果这两个数字是从中文WIN98发出去的，JAVA程序又是在英文LINUX上运行的，那就出现了所谓的乱码问题了。也就是JAVA按英文的编码表ASCII来处理这两个数字，当通过new String({0xB5,0xB1})得到的String的时候，这个String代表的已经不是中文的“当”字，而是两个英文的奇怪字符了。不过如果你知道这两个数字一定是中文的话，就可以指定用new String({0xB5,0xB1},”GB2312”)来处理，这时候新建立的String才真的是一个“当”字。当然拉，如果你要把一个“当”字的JAVA的String显示在中文WIN98上，必须把这个字输出成两个8位数字：0xB5,0xB1，不管是写成文件还是输出到浏览器上，都必须是0xB5,0xB1。如何把“当”字用GB2312输出？String.getBytes(“GB2312”) 就可以拉！所以有一点要记住：和外界交换任何信息都是以byte[]来进行的！。你可以留意一下JAVA大多数的I/O类，都有以byte[]作为参数和返回值的方法。不过，也有很多写的比较糊涂的程序，没有提供byte[]交换信息的方法，害的不同文字平台的程序员很头疼。Servlet的HttpRequest.getParameter()就是这样。好在有的JSP/SERVLET容易还提供先指定编码表的方法，才能比较简单的解决这个问题。 6，网上关于JAVA中文问题的一些错误处理方法。 一个是最常见的，不管什么内容，都用new String(…,”ISO-8859-1”)来建立字符串，然后使用的时候按默认的编码格式（通常在服务器上都是英文系统）输出字符串。这样其实你使用的String并不是按UNICODE来代表真正的字符，而是强行把BYTE数组复制到String的char[]里，一旦你的运行环境改变，你就被迫要修改一大堆的代码。而且也无法在同一个字符串里处理几种不同编码的文字。 另一个是把一种编码格式的字符串，比如是GB2312，转换成另一种格式的字符串，比如UTF-8，然后不指明是UTF-8编码，而直接用new String(…)来建立String，这样放在String里面的字符也是无法确定的，它在不同的系统上代表不同的字符。如果要求别人用“UTF-8格式”的String来交换信息的时候，其实已经破坏了JAVA为了兼容各种语言所做的规定。这种错误的本质思想是还按写C语言的方式，把字符串纯粹当作可以自己自由编码的存储器使用，而忽略了JAVA字符串只有一种编码格式。如果真的想自由编码，用byte[]或者char[]就完全了解决问题的了。 7，其他资料字符，字节和编码 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/18/javaString-and-bytes/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"byte[]","slug":"byte","permalink":"http://agehua.github.io/tags/byte/"}]},{"title":"google cloud message（GCM）和Azure实现Notification总结","slug":"GCM-Azure_summary","date":"2016-05-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/05/12/GCM-Azure_summary/","link":"","permalink":"http://agehua.github.io/2016/05/12/GCM-Azure_summary/","excerpt":"1.相关资料我也是一知半解，基本上就是根据官方教程来实现，但microsoft的azure文档我找了好久，英文不好，汗。。。\ngcm start: https://developers.google.com/cloud-messaging/android/start\nazure start: https://azure.microsoft.com/zh-cn/documentation/articles/notification-hubs-android-get-started/\ngcm official demo: https://github.com/google/gcm\ngcm personal demo: https://github.com/iammert/FastGCM","text":"1.相关资料我也是一知半解，基本上就是根据官方教程来实现，但microsoft的azure文档我找了好久，英文不好，汗。。。 gcm start: https://developers.google.com/cloud-messaging/android/start azure start: https://azure.microsoft.com/zh-cn/documentation/articles/notification-hubs-android-get-started/ gcm official demo: https://github.com/google/gcm gcm personal demo: https://github.com/iammert/FastGCM 2.遇到的问题 1.手机运行官方demo时，发送消息，消息收不到必须切换一下网络才可以 stackoverflow上有人问过这个问题：http://stackoverflow.com/questions/13835676/google-cloud-messaging-messages-sometimes-not-received-until-network-state-cha 3.onActivityResult()和onResume()调用顺序API中这样描述：当你一个Activity是以请求码开始，结束时返回给前页面结果码，页面根据结果码进行相应的信息处理。我们会在返回的页面先接受结果码，然后才调用onResume()。 通常我们还会遇到这样一个问题：在处理返回页面的数据问题1.需要从服务器上刷新数据时我们会在onResume()方法里处理2.而刷新从结束界面返回的数据我们会在onAcitviyResult()方法里面处理 为了避免二者在同一块控件上对数据处理，我们只需加个标识符，在两个方法里进行判断，要用哪个方法进行刷新 4.Android4.4以上系统根据Uri正确获取文件路径的方法public static String getPhotoPathFromContentUri(Context context, Uri uri) &#123; String photoPath = \"\"; if(context == null || uri == null) &#123; return photoPath; &#125; if(Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.KITKAT &amp;&amp; DocumentsContract.isDocumentUri(context, uri)) &#123; String docId = DocumentsContract.getDocumentId(uri); if(isExternalStorageDocument(uri)) &#123; String [] split = docId.split(\":\"); if(split.length &gt;= 2) &#123; String type = split[0]; if(\"primary\".equalsIgnoreCase(type)) &#123; photoPath = Environment.getExternalStorageDirectory() + \"/\" + split[1]; &#125; &#125; &#125; else if(isDownloadsDocument(uri)) &#123; Uri contentUri = ContentUris.withAppendedId(Uri.parse(\"content://downloads/public_downloads\"), Long.valueOf(docId)); photoPath = getDataColumn(context, contentUri, null, null); &#125; else if(isMediaDocument(uri)) &#123; String[] split = docId.split(\":\"); if(split.length &gt;= 2) &#123; String type = split[0]; Uri contentUris = null; if(\"image\".equals(type)) &#123; contentUris = MediaStore.Images.Media.EXTERNAL_CONTENT_URI; &#125; else if(\"video\".equals(type)) &#123; contentUris = MediaStore.Video.Media.EXTERNAL_CONTENT_URI; &#125; else if(\"audio\".equals(type)) &#123; contentUris = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI; &#125; String selection = MediaStore.Images.Media._ID + \"=?\"; String[] selectionArgs = new String[] &#123; split[1] &#125;; photoPath = getDataColumn(context, contentUris, selection, selectionArgs); &#125; &#125; &#125; else if(\"file\".equalsIgnoreCase(uri.getScheme())) &#123; photoPath = uri.getPath(); &#125; else &#123; photoPath = getDataColumn(context, uri, null, null); &#125; return photoPath;&#125;private static boolean isExternalStorageDocument(Uri uri) &#123; return \"com.android.externalstorage.documents\".equals(uri.getAuthority());&#125;private static boolean isDownloadsDocument(Uri uri) &#123; return \"com.android.providers.downloads.documents\".equals(uri.getAuthority());&#125;private static boolean isMediaDocument(Uri uri) &#123; return \"com.android.providers.media.documents\".equals(uri.getAuthority());&#125;private static String getDataColumn(Context context, Uri uri, String selection, String[] selectionArgs) &#123; Cursor cursor = null; String column = MediaStore.Images.Media.DATA; String[] projection = &#123; column &#125;; try &#123; cursor = context.getContentResolver().query(uri, projection, selection, selectionArgs, null); if (cursor != null &amp;&amp; cursor.moveToFirst()) &#123; int index = cursor.getColumnIndexOrThrow(column); return cursor.getString(index); &#125; &#125; finally &#123; if (cursor != null &amp;&amp; !cursor.isClosed()) cursor.close(); &#125; return null;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/12/GCM-Azure_summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"GCM","slug":"gcm","permalink":"http://agehua.github.io/tags/gcm/"},{"name":"azure","slug":"azure","permalink":"http://agehua.github.io/tags/azure/"},{"name":"notification","slug":"notification","permalink":"http://agehua.github.io/tags/notification/"}]},{"title":"《android开发艺术探索》读书笔记","slug":"android-books-reading-","date":"2016-03-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/03/20/android-books-reading-/","link":"","permalink":"http://agehua.github.io/2016/03/20/android-books-reading-/","excerpt":"第1章 Activity的生命周期和启动模式本节和《Android群英传》中的第8章Activity和Activity调用栈分析有关系，建议先阅读该章的总结\n第1章 Activity的生命周期和启动模式\n1.1 Activity生命周期全面分析1.1.1 典型情况下生命周期分析\n(1)一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart方法就会被调用。\n\n(2)当用户打开新的Activity或者切换到桌面的时候，回调如下：onPause -&gt; onStop，但是如果新Activity采用了透明主题，那么onStop方法不会被回调。当用户再次回到原来的Activity时，回调如下：onRestart -&gt; onStart -&gt; onResume。\n\n","text":"第1章 Activity的生命周期和启动模式本节和《Android群英传》中的第8章Activity和Activity调用栈分析有关系，建议先阅读该章的总结 第1章 Activity的生命周期和启动模式 1.1 Activity生命周期全面分析1.1.1 典型情况下生命周期分析 (1)一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart方法就会被调用。 (2)当用户打开新的Activity或者切换到桌面的时候，回调如下：onPause -&gt; onStop，但是如果新Activity采用了透明主题，那么onStop方法不会被回调。当用户再次回到原来的Activity时，回调如下：onRestart -&gt; onStart -&gt; onResume。 (3)onStart和onStop对应，它们是从Activity是否可见这个角度来回调的；onPause和onResume方法对应，它们是从Activity是否位于前台这个角度来回调的。 (4)从Activity A进入到Activity B，回调顺序是onPause(A) -&gt; onCreate(B) -&gt; onStart(B) -&gt; onResume(B) -&gt; onStop(A)，所以不能在onPause方法中做重量级的操作。 1.1.2 异常情况下生命周期分析 (1)onSaveInstanceState方法只会出现在Activity被异常终止的情况下，它的调用时机是在onStop之前，它和onPause方法没有既定的时序关系，可能在它之前，也可能在它之后。 当Activity被重新创建的时候，onRestoreInstanceState会被回调，它的调用时机是onStart之后。 系统只会在Activity即将被销毁并且有机会重新显示的情况下才会去调用onSaveInstanceState方法。 当Activity在异常情况下需要重新创建时，系统会默认为我们保存当前Activity的视图结构，并且在Activity重启后为我们恢复这些数据，比如文本框中用户输入的数据、listview滚动的位置等，这些view相关的状态系统都会默认为我们恢复。具体针对某一个view系统能为我们恢复哪些数据可以查看view的源码中的onSaveInstanceState和onRestoreInstanceState方法。 (2)Activity按优先级的分类 前台Activity；可见但非前台Activity；后台Activity (3)android:configChanges=”xxx”属性，常用的主要有下面三个选项： local：设备的本地位置发生了变化，一般指切换了系统语言； keyboardHidden：键盘的可访问性发生了变化，比如用户调出了键盘； orientation：屏幕方向发生了变化，比如旋转了手机屏幕。 配置了android:configChanges=”xxx”属性之后，Activity就不会在对应变化发生时重新创建，而是调用Activity的onConfigurationChanged方法。 1.2 Activity的启动模式1.2.1 启动模式 (1)当任务栈中没有任何Activity的时候，系统就会回收这个任务栈。 (2)从非Activity类型的Context(例如ApplicationContext、Service等)中以standard模式启动新的Activity是不行的，因为这类context并没有任务栈，所以需要为待启动Activity指定FLAG_ACTIVITY_NEW_TASK标志位。 (3)任务栈分为前台任务栈和后台任务栈，后台任务栈中的Activity位于暂停状态，用户可以通过切换将后台任务栈再次调到前台。 (4)参数TaskAffinity用来指定Activity所需要的任务栈，意为任务相关性。 默认情况下，所有Activity所需的任务栈的名字为应用的包名。TaskAffinity属性主要和singleTask启动模式或者allowTaskReparenting属性配对使用，在其他情况下没有意义。 当TaskAffinity和singleTask启动模式配对使用的时候，它是具有该模式的Activity的目前任务栈的名字，待启动的Activity会运行在名字和TaskAffinity相同的任务栈中； 当TaskAffinity和allowTaskReparenting结合的时候，当一个应用A启动了应用B的某个Activity C后，如果Activity C的allowTaskReparenting属性设置为true的话，那么当应用B被启动后，系统会发现Activity C所需的任务栈存在了，就将Activity C从A的任务栈中转移到B的任务栈中。 (5)singleTask模式的具体分析： 当一个具有singleTask启动模式的Activity请求启动之后，系统首先会寻找是否存在A想要的任务栈， 如果不存在，就重新创建一个任务栈，然后创建Activity的实例把它放到栈中；如果存在Activity所需的任务栈，这时候要看栈中是否有Activity实例存在. 如果有，那么系统就会把该Activity实例调到栈顶，并调用它的onNewIntent方法(它之上的Activity会被迫出栈，所以singleTask模式具有FLAG_ACTIVITY_CLEAR_TOP效果)；如果Activity实例不存在，那么就创建Activity实例并把它压入栈中。 (6)设置启动模式既可以使用xml属性android:launchMode，也可以使用代码intent.addFlags()。区别在于限定范围不同，前者无法直接为Activity设置FLAG_ACTIVITY_CLEAR_TOP标识，而后者无法为Activity指定singleInstance模式。 1.2.2 Activity的FlagsFLAG_ACTIVITY_NEW_TASK,FLAG_ACTIVITY_SINGLE_TOP,FLAG_ACTIVITY_CLEAR_TOP FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS：具有这个标记的Activity不会出现在历史Activity列表中，当某些情况下我们不希望用户通过历史列表回到我们的Activity的时候这个标记比较有用，它等同于属性设置android:excludeFromRecents=”true”。 1.3 IntentFilter的匹配规则 (1)IntentFilter中的过滤信息有action、category、data，为了匹配过滤列表，需要同时匹配过滤列表中的action、category、data信息，否则匹配失败。 一个过滤列表中的action、category、data可以有多个，所有的action、category、data分别构成不同类别，同一类别的信息共同约束当前类别的匹配过程。只有一个Intent同时匹配action类别、category类别和data类别才算完全匹配，只有完全匹配才能成功启动目标Activity。此外，一个Activity中可以有多个intent-filter，一个Intent只要能匹配任何一组intenf-filter即可成功启动对应的Activity。 &lt;intent-filter&gt; &lt;action android:name=\"com.ryg.charpter_1.c\" /&gt; &lt;action android:name=\"com.ryg.charpter_1.d\" /&gt; &lt;category android:name=\"com.ryg.category.c\" /&gt; &lt;category android:name=\"com.ryg.category.d\" /&gt; &lt;category android:name=\"android.intent.category.DEFAULT\" /&gt; &lt;data android:mimeType=\"text/plain\" /&gt;&lt;/intent-filter&gt;~~~ - (2)action匹配规则 只要Intent中的action能够和过滤规则中的任何一个action相同即可匹配成功，action匹配区分大小写。- (3)category匹配规则 Intent中如果有category那么所有的category都必须和过滤规则中的其中一个category相同，如果没有category的话那么就是默认的category，即android.intent.category.DEFAULT，所以为了Activity能够接收隐式调用，配置多个category的时候必须加上默认的category。- (4)data匹配规则 data的结构很复杂，语法大致如下：~~~ Javascript&lt;data android:scheme=\"string\" android:host=\"string\" android:port=\"string\" android:path=\"string\"` android:pathPattern=\"string\" android:pathPrefix=\"string\" android:mimeType=\"string\" /&gt; 主要由mimeType和URI组成，其中mimeType代表媒体类型，而URI的结构也复杂，大致如下： &lt;scheme&gt;://&lt;host&gt;:&lt;port&gt;/[&lt;path&gt;]|[&lt;pathPrefix&gt;]|[pathPattern] 例如content://com.example.project:200/folder/subfolder/etc scheme、host、port分别表示URI的模式、主机名和端口号，其中如果scheme或者host未指定那么URI就无效。 path、pathPattern、pathPrefix都是表示路径信息，其中path表示完整的路径信息，pathPrefix表示路径的前缀信息；pathPattern表示完整的路径，但是它里面包含了通配符(*)。 data匹配规则：Intent中必须含有data数据，并且data数据能够完全匹配过滤规则中的某一个data。 URI有默认的scheme！ 如果过滤规则中的mimeType指定为image/*或者text/*等这种类型的话，那么即使过滤规则中没有指定URI，URI有默认的scheme是content和file！如果过滤规则中指定了scheme的话那就不是默认的scheme了。 //URI有默认值&lt;intent-filter&gt; &lt;data android:mimeType=\"image/*\"/&gt; ...&lt;/intent-filter&gt; //URI默认值被覆盖&lt;intent-filter&gt; &lt;data android:mimeType=\"image/*\" android:scheme=\"http\" .../&gt; ...&lt;/intent-filter&gt; 如果要为Intent指定完整的data，必须要调用setDataAndType方法！ 不能先调用setData然后调用setType，因为这两个方法会彼此清除对方的值。intent.setDataAndType(Uri.parse(\"file://abc\"), \"image/png\"); data的下面两种写法作用是一样的： &lt;intent-filter&gt; &lt;data android:scheme=\"file\" android:host=\"www.github.com\"/&gt;&lt;/intent-filter&gt;&lt;intent-filter&gt; &lt;data android:scheme=\"file\"/&gt; &lt;data android:host=\"www.github.com\"/&gt;&lt;/intent-filter&gt; 如何判断是否有Activity能够匹配我们的隐式Intent？ (1)PackageManager的resolveActivity方法或者Intent的resolveActivity方法：如果找不到就会返回null (2)PackageManager的queryIntentActivities方法：它返回所有成功匹配的Activity信息针对Service和BroadcastReceiver等组件，PackageManager同样提供了类似的方法去获取成功匹配的组件信息，例如queryIntentServices、queryBroadcastReceivers等方法 有一类action和category比较重要，它们在一起用来标明这是一个入口Activity，并且会出现在系统的应用列表中。 &lt;intent-filter&gt; &lt;action android:name=\"android.intent.action.MAIN\" /&gt; &lt;category android:name=\"android.intent.category.LAUNCHER\" /&gt;&lt;/intent-filter&gt; 第2章 IPC机制2.1 Android IPC简介(1)任何一个操作系统都需要有相应的IPC机制，Linux上可以通过命名通道、共享内存、信号量等来进行进程间通信。Android系统不仅可以使用了Binder机制来实现IPC，还可以使用Socket实现任意两个终端之间的通信。 2.2 Android中的多进程模式 (1)通过给四大组件指定android:process属性就可以开启多进程模式. 默认进程的进程名是包名packageName，进程名以:开头的进程属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中，而进程名不以:开头的进程属于全局进程，其他应用通过ShareUID方法可以和它跑在同一个进程中。 android:process=”:xyz” //进程名是 packageName:xyz android:process=”aaa.bbb.ccc” //进程名是 aaa.bbb.ccc (2)Android系统会为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。 两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。 在这种情况下，它们可以相互访问对方的私有数据，比如data目录、组件信息等，不管它们是否跑在同一个进程中。如果它们跑在同一个进程中，还可以共享内存数据，它们看起来就像是一个应用的两个部分。 (3)android系统会为每个进程分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，所以不同的虚拟机中访问同一个类的对象会产生多个副本。 (4)使用多进程容易造成以下几个问题： 1.静态成员和单例模式完全失效； 2.线程同步机制完全失效：无论锁对象还是锁全局对象都无法保证线程同步； 3.SharedPreferences的可靠性下降：SharedPreferences不支持并发读写； 4.Application会多次创建：当一个组件跑在一个新的进程的时候，系统要在创建新的进程的同时分配独立的虚拟机，应用会重新启动一次，也就会创建新的Application。运行在同一个进程中的组件是属于同一个虚拟机和同一个Application。 同一个应用的不同组件，如果它们运行在不同进程中，那么和它们分别属于两个应用没有本质区别。 2.3 IPC基础概念介绍 (1)Serializable接口是Java中为对象提供标准的序列化和反序列化操作的接口，而Parcelable接口是Android提供的序列化方式的接口。 (2)serialVersionUId是一串long型数字，主要是用来辅助序列化和反序列化的，原则上序列化后的数据中的serialVersionUId只有和当前类的serialVersionUId相同才能够正常地被反序列化。 serialVersionUId的详细工作机制：序列化的时候系统会把当前类的serialVersionUId写入序列化的文件中，当反序列化的时候系统会去检测文件中的serialVersionUId，看它是否和当前类的serialVersionUId一致，如果一致就说明序列化的类的版本和当前类的版本是相同的，这个时候可以成功反序列化；否则说明版本不一致无法正常反序列化。一般来说，我们应该手动指定serialVersionUId的值。 1.静态成员变量属于类不属于对象，所以不参与序列化过程； 2.声明为transient的成员变量不参与序列化过程。 (3)Parcelable接口内部包装了可序列化的数据，可以在Binder中自由传输，Parcelable主要用在内存序列化上，可以直接序列化的有Intent、Bundle、Bitmap以及List和Map等等，下面是一个实现了Parcelable接口的示例 public class Book implements Parcelable &#123; public int bookId; public String bookName; public Book() &#123; &#125; public Book(int bookId, String bookName) &#123; this.bookId = bookId; this.bookName = bookName; &#125; //“内容描述”，如果含有文件描述符返回1，否则返回0，几乎所有情况下都是返回0 public int describeContents() &#123; return 0; &#125; //实现序列化操作，flags标识只有0和1，1表示标识当前对象需要作为返回值返回，不能立即释放资源，几乎所有情况都为0 public void writeToParcel(Parcel out, int flags) &#123; out.writeInt(bookId); out.writeString(bookName); &#125; //实现反序列化操作 public static final Parcelable.Creator&lt;Book&gt; CREATOR = new Parcelable.Creator&lt;Book&gt;() &#123; //从序列化后的对象中创建原始对象 public Book createFromParcel(Parcel in) &#123; return new Book(in); &#125; public Book[] newArray(int size) &#123;//创建指定长度的原始对象数组 return new Book[size]; &#125; &#125;; private Book(Parcel in) &#123; bookId = in.readInt(); bookName = in.readString(); &#125;&#125; (4)Binder是Android中的一个类，它实现了IBinder接口。 从IPC角度看，Binder是Android中一种跨进程通信的方式；Binder还可以理解为虚拟的物理设备，它的设备驱动是/dev/binder； 从Framework层角度看，Binder是ServiceManager连接各种Manager和相应的ManagerService的桥梁； 从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。 在Android开发中，Binder主要用在Service中，包括AIDL和Messenger，其中普通Service中的Binder不涉及进程间通信，较为简单；而Messenger的底层其实是AIDL，正是Binder的核心工作机制。 (5)aidl工具根据aidl文件自动生成的java接口的解析： 首先，它声明了几个接口方法，同时还声明了几个整型的id用于标识这些方法，id用于标识在transact过程中客户端所请求的到底是哪个方法； 接着，它声明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务端都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub内部的代理类Proxy来完成。 所以，这个接口的核心就是它的内部类Stub和Stub内部的代理类Proxy。 下面分析其中的方法： 1.asInterface(android.os.IBinder obj)：用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的，如果客户端和服务端是在同一个进程中，那么这个方法返回的是服务端的Stub对象本身，否则返回的是系统封装的Stub.Proxy对象。 2.asBinder：返回当前Binder对象。 3.onTransact：这个方法运行在服务端中的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。 这个方法的原型是public Boolean onTransact(int code, Parcelable data, Parcelable reply, int flags) 服务端通过code可以知道客户端请求的目标方法，接着从data中取出所需的参数，然后执行目标方法，执行完毕之后，将结果写入到reply中。如果此方法返回false，说明客户端的请求失败，利用这个特性可以做权限验证(即验证是否有权限调用该服务)。 4.Proxy#[Method]：代理类中的接口方法，这些方法运行在客户端，当客户端远程调用此方法时，它的内部实现是： 首先创建该方法所需要的参数，然后把方法的参数信息写入到_data中，接着调用transact方法来发起RPC请求，同时当前线程挂起；然后服务端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据。 如果搞清楚了自动生成的接口文件的结构和作用之后，其实是可以不用通过AIDL而直接实现Binder的，主席写的示例代码 (6)Binder的两个重要方法linkToDeath和unlinkToDeath Binder运行在服务端，如果由于某种原因服务端异常终止了的话会导致客户端的远程调用失败，所以Binder提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath方法可以给Binder设置一个死亡代理，当Binder死亡的时候客户端就会收到通知，然后就可以重新发起连接请求从而恢复连接了。 如何给Binder设置死亡代理呢？ 1.声明一个DeathRecipient对象，DeathRecipient是一个接口，其内部只有一个方法bindeDied，实现这个方法就可以在Binder死亡的时候收到通知了。 private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() &#123; @Override public void binderDied() &#123; if (mRemoteBookManager == null) return; mRemoteBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0); mRemoteBookManager = null; // TODO:这里重新绑定远程Service &#125;&#125;; 2.在客户端绑定远程服务成功之后，给binder设置死亡代理 mRemoteBookManager.asBinder().linkToDeath(mDeathRecipient, 0); 2.4 Android中的IPC方式 (1)使用Bundle：Bundle实现了Parcelable接口，Activity、Service和Receiver都支持在Intent中传递Bundle数据。 (2)使用文件共享：这种方式简单，适合在对数据同步要求不高的进程之间进行通信，并且要妥善处理并发读写的问题。 SharedPreferences是一个特例，虽然它也是文件的一种，但是由于系统对它的读写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对它的读写就变得不可靠，当面对高并发读写访问的时候，有很大几率会丢失数据，因此，不建议在进程间通信中使用SharedPreferences。 (3)使用Messenger：Messenger是一种轻量级的IPC方案，它的底层实现就是AIDL。Messenger是以串行的方式处理请求的，即服务端只能一个个处理，不存在并发执行的情形，详细的示例见原书。 (4)使用AIDL 大致流程：首先建一个Service和一个AIDL接口，接着创建一个类继承自AIDL接口中的Stub类并实现Stub类中的抽象方法，在Service的onBind方法中返回这个类的对象，然后客户端就可以绑定服务端Service，建立连接后就可以访问远程服务端的方法了。 1.AIDL支持的数据类型：基本数据类型、String和CharSequence、ArrayList、HashMap、Parcelable以及AIDL； 2.某些类即使和AIDL文件在同一个包中也要显式import进来； 3.AIDL中除了基本数据类，其他类型的参数都要标上方向：in、out或者inout； 4.AIDL接口中支持方法，不支持声明静态变量； 5.为了方便AIDL的开发，建议把所有和AIDL相关的类和文件全部放入同一个包中，这样做的好处是，当客户端是另一个应用的时候，可以直接把整个包复制到客户端工程中。 6.RemoteCallbackList是系统专门提供的用于删除跨进程Listener的接口。RemoteCallbackList是一个泛型，支持管理任意的AIDL接口，因为所有的AIDL接口都继承自IInterface接口。 (5)使用ContentProvider 1.ContentProvider主要以表格的形式来组织数据，并且可以包含多个表； 2.ContentProvider还支持文件数据，比如图片、视频等，系统提供的MediaStore就是文件类型的ContentProvider； 3.ContentProvider对底层的数据存储方式没有任何要求，可以是SQLite、文件，甚至是内存中的一个对象都行； 4.要观察ContentProvider中的数据变化情况，可以通过ContentResolver的registerContentObserver方法来注册观察者； (6)使用Socket Socket是网络通信中“套接字”的概念，分为流式套接字和用户数据包套接字两种，分别对应网络的传输控制层的TCP和UDP协议。 2.5 Binder连接池 (1)当项目规模很大的时候，创建很多个Service是不对的做法，因为service是系统资源，太多的service会使得应用看起来很重，所以最好是将所有的AIDL放在同一个Service中去管理。 整个工作机制是：每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同业务模块之间是不能有耦合的，所有实现细节我们要单独开来，然后向服务端提供自己的唯一标识和其对应的Binder对象；对于服务端来说，只需要一个Service，服务端提供一个queryBinder接口，这个接口能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法调用了。 Binder连接池的主要作用就是将每个业务模块的Binder请求统一转发到远程Service去执行，从而避免了重复创建Service的过程。 (2)作者实现的Binder连接池BinderPool的实现源码，建议在AIDL开发工作中引入BinderPool机制。 2.6 选用合适的IPC方式 第9章 四大组件的工作过程本篇摘选自amurocrash的专栏 9.1 四大组件的运行状态 (1)四大组件中只有BroadcastReceiver既可以在AndroidManifest文件中注册，也可以在代码中注册，其他三个组件都必须在AndroidManifest文件中注册；ContentProvider的调用不需要借助Intent，其他三个组件都需要借助Intent。 (2)Activity是一种展示型组件，用于向用户展示界面，可由显式或者隐式Intent来启动。 (3)Service是一种计算型组件，用于在后台执行计算任务。尽管service是用于后台执行计算的，但是它本身是运行在主线程中的，因此耗时的后台计算仍然需要在单独的线程中去完成。Service组件有两种状态：启动状态和绑定状态。当service处于绑定状态时，外界可以很方便的和service进行通信，而在启动状态中是不可与外界通信的。 (4)BroadcastReceiver是一种消息型组件，用于在不同的组件乃至不同的应用之间传递消息，它工作在系统内部。广播有两种注册方式：静态注册和动态注册。静态注册是在AndroidManifest中注册，在应用安装的时候会被系统解析，这种广播不需要应用启动就可以收到相应的广播。动态注册需要通过Context.registerReceiver()来注册，这种广播需要应用启动才能注册并接收广播。BroadcastReceiver组件一般来说不需要停止，它也没有停止的概念。 (5)ContentProvider是一种数据共享型组件，用于向其他组件乃至其他应用共享数据。ContentProvider中的insert、delete、update、query方法需要处理好线程同步，因为这几个方法是在Binder线程池中被调用的，另外ContentProvider组件也不需要手动停止。 9.2 Activity的工作过程(1)Activity启动的大致流程 (2)ApplicationThread是ActivityThread的一个内部类，它继承自ApplicationThreadNative，而ApplicationThreadNative继承自Binder并实现了IApplicationThread接口，ApplicationThreadNative的作用其实就和系统为AIDL文件生成的类是一样的。(3)ActivityManagerService(AMS)继承自ActivityManagerNative，而ActivityManagerNative继承自Binder并实现了IActivityManager这个Binder接口，因此AMS也是一个Binder。(4)一个应用只有一个Application对象，它的创建也是通过Instrumentation来完成的，这个过程和Activity对象的创建过程一样，都是通过类加载器来实现的。(5)ContextImpl是Context的具体实现，ContextImpl是通过Activity的attach方法来和Activity建立关联的，在attach方法中Activity还会完成Window的创建并建立自己和Window的关联，这样当window接收到外部输入事件后就可以将事件传递给Activity。 [这里可能有误，应该是Activity将事件传递给window] 9.3 Service的工作过程(1)Service有两种状态：启动状态和绑定状态，两种状态是可以共存的。启动过程： 绑定过程： 9.4 BroadcastReceiver的工作过程(1)BroadcastReceiver的工作过程包括广播注册过程、广播发送和接收过程。注册过程：静态注册的时候是由PackageManagerService来完成整个注册过程，下面是动态注册的过程发送和接收： (2)广播的发送有几种类型：普通广播、有序广播和粘性广播，有序广播和粘性广播与普通广播相比具有不同的特性，但是发送和接收过程是类似的。 (3)一个应用处于停止状态分为两种情况：一是应用安装后未运行；二是应用被手动或者其他应用强停了。从Android 3.1开始，处于停止状态的应用无法接受到开机广播。 9.5 ContentProvider的工作过程(1)当ContentProvider所在的进程启动的时候，它会同时被启动并被发布到AMS中，这个时候它的onCreate要先去Application的onCreate执行。(2)ContentProvider的启动过程： 1.当一个应用启动时，入口方法是ActivityThread的main方法，其中创建ActivityThread的实例并创建主线程的消息队列； 2.ActivityThread的attach方法中会远程调用ActivityManagerService的attachApplication，并将ApplicationThread提供给AMS，ApplicationThread主要用于ActivityThread和AMS之间的通信； 3.ActivityManagerService的attachApplication会调用ApplicationThread的bindApplication方法，这个方法会通过H切换到ActivityThread中去执行，即调用handleBindApplication方法； 4.handleBindApplication方法会创建Application对象并加载ContentProvider，注意是先加载ContentProvider，然后调用Application的onCreate方法。 (3)ContentProvider的android:multiprocess属性决定它是否是单实例，默认值是false，也就是默认是单实例。当设置为true时，每个调用者的进程中都存在一个ContentProvider对象。(4)当调用ContentProvider的insert、delete、update、query方法中的任何一个时，如果ContentProvider所在的进程没有启动的话，那么就会触发ContentProvider的创建，并伴随着ContentProvider所在进程的启动。下图是ContentProvider的query操作的大致过程： 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/20/android-books-reading-/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"reading","slug":"reading","permalink":"http://agehua.github.io/tags/reading/"}]},{"title":"android新特性新知识点总结","slug":"android-new-knowledge-summary","date":"2016-03-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/03/20/android-new-knowledge-summary/","link":"","permalink":"http://agehua.github.io/2016/03/20/android-new-knowledge-summary/","excerpt":"一、mipmap 目录和drawable 目录有什么区别Nexus 6 有 493 ppi，它刚好在 xxhdpi和xxxhdpi之间，所以显示的时候需要对xxxhdpi的资源进行缩小，如果你用了mipmap-xxxhdpi,那么这里会对sclae有一个优化，性能更好，占用内存更少。所以现在官方推荐使用mipmap：\n二、setTranslucentStatus()方法在Android4.4之后使用沉浸式状态栏，需要用到这个方法","text":"一、mipmap 目录和drawable 目录有什么区别Nexus 6 有 493 ppi，它刚好在 xxhdpi和xxxhdpi之间，所以显示的时候需要对xxxhdpi的资源进行缩小，如果你用了mipmap-xxxhdpi,那么这里会对sclae有一个优化，性能更好，占用内存更少。所以现在官方推荐使用mipmap： 二、setTranslucentStatus()方法在Android4.4之后使用沉浸式状态栏，需要用到这个方法 public class MainActivity extends Activity&#123; @Override protected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); //首先检测当前的版本是否是api&gt;=19的 if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.KITKAT) &#123; setTranslucentStatus(true); &#125; SystemBarTintManager tintManager = new SystemBarTintManager(this); tintManager.setStatusBarTintEnabled(true); tintManager.setStatusBarTintColor(Color.parseColor(\"#FFC1E0\")); &#125; @TargetApi(19) private void setTranslucentStatus(boolean on) &#123; Window win = getWindow(); WindowManager.LayoutParams winParams = win.getAttributes(); final int bits = WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS; if (on) &#123; winParams.flags |= bits; &#125; else &#123; winParams.flags &amp;= ~bits; &#125; win.setAttributes(winParams); &#125;&#125; 布局设置 &lt;LinearLayout xmlns:android=&quot;http://schemas.android.com/apk/res/android&quot; android:layout_width=&quot;match_parent&quot; android:layout_height=&quot;match_parent&quot; &lt;!--这两行是必须设置的--&gt; android:fitsSystemWindows=&quot;true&quot; android:clipToPadding=&quot;true&quot; android:orientation=&quot;vertical&quot; android:background=&quot;#FFD9EC&quot; &gt; &lt;TextView android:text=&quot;沉浸式状态栏&quot; android:layout_width=&quot;match_parent&quot; android:layout_height=&quot;50dp&quot; android:textSize=&quot;23dp&quot; android:layout_gravity=&quot;center_horizontal&quot; android:gravity=&quot;center&quot; android:background=&quot;#FFD9EC&quot; /&gt; &lt;TextView android:layout_width=&quot;match_parent&quot; android:layout_height=&quot;match_parent&quot; android:background=&quot;@android:color/darker_gray&quot;/&gt;&lt;/LinearLayout&gt; 三、获取Bitmap图片大小的代码public int getBitmapSize(Bitmap bitmap)&#123; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.KITKAT)&#123; //API 19 return bitmap.getAllocationByteCount(); &#125; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.HONEYCOMB_MR1)&#123;//API 12 return bitmap.getByteCount(); &#125; return bitmap.getRowBytes() * bitmap.getHeight(); //earlier version&#125; 四、Activity横竖屏切换生命周期总结： 1、不设置Activity的android:configChanges时，切屏会重新调用各个生命周期，切横屏时会执行一次，切竖屏时会执行两次 2、设置Activity的android:configChanges=”orientation”时，切屏还是会重新调用各个生命周期，切横、竖屏时只会执行一次 3、设置Activity的android:configChanges=”orientation|keyboardHidden”时，切屏不会重新调用各个生命周期，只会执行onConfigurationChanged方法 验证： 1、新建一个Activity，并把各个生命周期打印出来 2、运行Activity，得到如下信息 onCreate--&gt;onStart--&gt;onResume--&gt; 3、按crtl+f12切换成横屏时 onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt; 4、再按crtl+f12切换成竖屏时，发现打印了两次相同的log onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt;onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt; 5、修改AndroidManifest.xml，把该Activity添加 android:configChanges=”orientation”，执行步骤3 onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt; 6、再执行步骤4，发现不会再打印相同信息，但多打印了一行onConfigChanged onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt;onConfigurationChanged--&gt; 7、把步骤5的android:configChanges=”orientation” 改成android:configChanges=”orientation|keyboardHidden”，执行步骤3，就只打印onConfigChanged onConfigurationChanged--&gt; 8、执行步骤4 onConfigurationChanged--&gt;onConfigurationChanged--&gt; 总结一下整个Activity的生命周期 1.补充一点，当前Activity产生事件弹出Toast和AlertDialog的时候Activity的生命周期不会有改变 2.Activity运行时按下HOME键(跟被完全覆盖是一样的)：onSaveInstanceState –&gt; onPause –&gt; onStop onRestart –&gt;onStart—&gt;onResume 3.Activity未被完全覆盖只是失去焦点：onPause—&gt;onResume 五.setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION)的限制在stackoverflow 上有一个提问：onTouchEvent() will not be triggered if setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION) is invoked Android 4.4 (API Level 19) introduces a new SYSTEM_UI_FLAG_IMMERSIVE flag for setSystemUiVisibility() that lets your app go truly “full screen.” This flag, when combined with the SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_FULLSCREEN flags, hides the navigation and status bars and lets your app capture all touch events on the screen. 正确用法应该是：int uiOptions = View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE;getWindow().getDecorView().setSystemUiVisibility(uiOptions); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/20/android-new-knowledge-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"new features","slug":"new-features","permalink":"http://agehua.github.io/tags/new-features/"},{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"}]},{"title":"近期总结facebook google+ Twitter sign-in fragment使用","slug":"facebook-google+signin","date":"2016-03-14T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/03/15/facebook-google+signin/","link":"","permalink":"http://agehua.github.io/2016/03/15/facebook-google+signin/","excerpt":"1.相关资料blog: 关于Google+以及Facebook第三方登录实现的一点总结\ng+官方教程: G+ start\nfacebook官方教程: Facebook start\niCCP: Not recognizing known sRGB profile","text":"1.相关资料blog: 关于Google+以及Facebook第三方登录实现的一点总结 g+官方教程: G+ start facebook官方教程: Facebook start iCCP: Not recognizing known sRGB profile 今天做分享的时候遇到了这个问题： [2016-04-01 11:24:04 - Dex Loader] Unable to execute dex: method ID not in [0, 0xffff]: 65536 [2016-04-01 11:24:04 - VIVAT_SHARESDK] Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536 大项目中遇到的问题看这个博客 iCCP: Not recognizing known sRGB profile 删除png图片内嵌的iCCP profile sRGB报错 今天有碰见一个坑，改其他代码，然后在编译的时候就出现这个问题，对就是这个问题。网上查了资料，也就这个资料最全面，大家可以去看见http://my.oschina.net/1pei/blog/479162?fromerr=ARrUPlGS 处理这个问题我使用了一种方法，记录下来以便以后使用 步骤1:下载Image Magick http://www.imagemagick.com.cn/download.html.如果是windows的，请下载含dll的 步骤2： 在要处理的文件夹使用如下命令 ，一定要在要处理的文件夹使用 //WINDOWS使用set fn=E:\\Program Files\\ImageMagick-6.9.0-Q16\\convert.exe for /f \"tokens=*\" %i in ('dir/s/b *.png') do \"%fn%\" \"%i\" -strip \"%i\"（因为是window的，所以把%%i改为%i） //LINUX使用 set fn=E:\\Program Files\\ImageMagick-6.9.0-Q16\\convert.exe for /f \"tokens=*\" %%i in ('dir/s/b *.png') do \"%fn%\" \"%%i\" -strip \"%%i\" 2.遇到问题 1.“This client application’s callback url has been locked”. 使用Twitter signin时遇到了这个问题，这个错误信息是在logcat中找到的，原因是在Twitter的Settings里勾选了“Enable Callback Locking (It is recommended to enable callback locking to ensure apps cannot overwrite the callback url)”选项，这个选项表示不允许app本地更改callback url。也可看这个页面 3.add() vs. replace() 只有在Fragment数量大于等于2的时候，调用add()还是replace()的区别才能体现出来。 当通过add()连续两次添加Fragment的时候，每个Fragment生命周期中的onAttach()-onResume()都会被各调用一次，而且两个Fragment的View会被同时attach到containerView。 同样，退出Activty时，每个Fragment生命周期中的onPause()-onDetach()也会被各调用一次。 但当使用replace()来添加Fragment的时候，第二次添加会导致第一个Fragment被销毁，即执行第二个Fragment的onAttach()方法之前会先执行第一个Fragment的onPause()-onDetach()方法，同时containerView会detach第一个Fragment的View。 调用show() &amp; hide()方法时. Fragment的生命周期方法并不会被执行，仅仅是Fragment的View被显示或者​隐藏。而且，尽管Fragment的View被隐藏，但它在父布局中并未被detach，仍然是作为containerView的childView存在着。相比较下，attach() &amp; detach()做的就更彻底一些。一旦一个Fragment被detach()，它的onPause()-onDestroyView()周期都会被执行。 同时Fragment的View也会被detach。在重新调用attach()后，onCreateView()-onResume()周期也会被再次执行。 remove() 其实看完上面的分析，remove()方法基本也就明白了。相对应add()方法执行onAttach()-onResume()的生命周期，remove()就是完成剩下的onPause()-onDetach()周期。 4.FragmentTransaction add 和 replace 区别使用 FragmentTransaction 的时候，它提供了这样两个方法，一个 add ， 一个 replace .add 和 replace 影响的只是界面，而控制回退的，是事务。 add 是把一个fragment添加到一个容器 container 里。 Add a fragment to the activity state. This fragment may optionally also have its view (if Fragment.onCreateView returns non-null) into a container view of the activity. public abstract FragmentTransaction add (int containerViewId, Fragment fragment, String tag) replace 是先remove掉相同id的所有fragment，然后在add当前的这个fragment。 Replace an existing fragment that was added to a container. This is essentially the same as calling remove(Fragment) for all currently added fragments that were added with the same containerViewId and then add(int, Fragment, String) with the same arguments given here. public abstract FragmentTransaction replace (int containerViewId, Fragment fragment, String tag) 在大部分情况下，这两个的表现基本相同。因为，一般，咱们会使用一个FrameLayout来当容器，而每个Fragment被add 或者 replace 到这个FrameLayout的时候，都是显示在最上层的。所以你看到的界面都是一样的。但是，使用add的情况下，这个FrameLayout其实有2层，多层肯定要比一层的来得浪费，所以还是推荐使用replace。当然有时候还是需要使用add的。比如要实现轮播图的效果，每个轮播图都是一个独立的Fragment，而他的容器FrameLayout需要add多个Fragment，这样他就可以根据提供的逻辑进行轮播了。 而至于返回键的时候，这个跟事务有关，跟使用add还是replace没有任何关系。 5.要想fragment完整地执行生命周期fragment跳转是要使用replace()方法，并一定要指定tag，否则有些方法不会执行（比如onResume），例如： getFragmentManager() .beginTransaction() .replace(R.id.base_container, inputVerifyCodeFragment,\"tag_code\") .addToBackStack(null).commit(); 6.fragment事件穿透如果发现fragment2的点击事件可以被fragment栈下一层的fragment1获取到，可以在fragment2布局的根部加上：android:clickable=”true”。问题解决 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/15/facebook-google+signin/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"third-party signin","slug":"third-party-signin","permalink":"http://agehua.github.io/tags/third-party-signin/"}]},{"title":"android Google map使用总结","slug":"android-googlemap-summary","date":"2016-02-29T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/03/01/android-googlemap-summary/","link":"","permalink":"http://agehua.github.io/2016/03/01/android-googlemap-summary/","excerpt":"1.在代码中编译google map要想编译编译google map必须使用Google map api。并在自己的工程中引入google-play-services_lib。两个都需要在SDK Manager中下载。前者要在对应android api中勾选，后者要勾选在Extras下的Google Play Service。\n要注意的是map2.0要使用com.google.android.gms包名下的类\nGoogle Maps Android API 使用OpenGL ES第2版来渲染地图。如果未安装OpenGL ES第2版，地图将不会出现。可以在 AndroidManifest.xml 中添加以下元素作为元素的子元素来过滤不能支持的手机：\n&lt;uses-feature        android:glEsVersion=\"0x00020000\"        android:required=\"true\"/&gt;","text":"1.在代码中编译google map要想编译编译google map必须使用Google map api。并在自己的工程中引入google-play-services_lib。两个都需要在SDK Manager中下载。前者要在对应android api中勾选，后者要勾选在Extras下的Google Play Service。 要注意的是map2.0要使用com.google.android.gms包名下的类 Google Maps Android API 使用OpenGL ES第2版来渲染地图。如果未安装OpenGL ES第2版，地图将不会出现。可以在 AndroidManifest.xml 中添加以下元素作为元素的子元素来过滤不能支持的手机： &lt;uses-feature android:glEsVersion=\"0x00020000\" android:required=\"true\"/&gt; 2.在编码中遇到的问题1.可以实现OnCameraChangeListener接口，来实现对相机状态的监听，比如我就记录下了地图缩放的大小 @Overridepublic void onCameraChange(CameraPosition arg0) &#123; // TODO Auto-generated method stub zoom = arg0.zoom;&#125; 2.向将处理地图的 Activity 添加 Fragment 对象。 最简单的实现方式是，向Activity 的布局文件添加 元素。 3.实现 OnMapReadyCallback 接口，并使用onMapReady(GoogleMap)回调方法获取GoogleMap对象的句柄。GoogleMap对象是对地图本身的内部表示。如需设置地图的视图选项，可以使用UiSettings设置地图的样式。 4.调用Fragment上的getMapAsync()以注册回调。 5.使用手机定位，定位成功后再map上显示标记： MarkerOptions markerOpt = new MarkerOptions(); markerOpt.position(new LatLng(geoLat, geoLng)); markerOpt.draggable(false); markerOpt.visible(true); markerOpt.anchor(0.5f, 0.5f);//设为图片中心 markerOpt.icon(BitmapDescriptorFactory .fromResource(R.drawable.sos_location_38x53)); mMap.addMarker(markerOpt); //将摄影机移动到指定的地理位置 cameraPosition = new CameraPosition.Builder() .target(new LatLng(geoLat, geoLng)) // Sets the center of the map to ZINTUN .zoom(zoom) // 缩放比例 .bearing(0) // Sets the orientation of the camera to east .build(); // Creates a CameraPosition from the builder mMap.animateCamera(CameraUpdateFactory.newCameraPosition(cameraPosition));~~~ 6.实现地图圆角效果：使用圆角.9图片，中间透明，圆角四周不透明&lt;br&gt;详细可以看这个提问：[Is there a way to implement rounded corners to a Mapfragment?](http://stackoverflow.com/questions/14469208/is-there-a-way-to-implement-rounded-corners-to-a-mapfragment)7.去掉google地图自带的蓝色圆点GoogleMap.setMyLocationEnabled(false);8.解决mapview与scrollview嵌套滑动的问题：思路就是使用getParent().requestDisallowInterceptTouchEvent(true);方法，让子类接收到touch事件~~~ Javapublic class MyMapView extends MapView &#123; private ViewParent mViewParent; public MyMapView(Context context) &#123; super(context); &#125; public MyMapView(Context context, AttributeSet attrs) &#123; super(context, attrs); &#125; public MyMapView(Context context, AttributeSet attrs, int defStyle) &#123; super(context, attrs, defStyle); &#125; public MyMapView(Context context, GoogleMapOptions options) &#123; super(context, options); &#125; public void setViewParent(@Nullable final ViewParent viewParent) &#123; //any ViewGroup mViewParent = viewParent; &#125; @Override public boolean onInterceptTouchEvent(final MotionEvent event) &#123; switch (event.getAction()) &#123; case MotionEvent.ACTION_DOWN: if (null == mViewParent) &#123; //设置父类不拦截touch事件，子view可以接收到touch事件 getParent().requestDisallowInterceptTouchEvent(true); &#125; else &#123; mViewParent.requestDisallowInterceptTouchEvent(true); &#125; break; case MotionEvent.ACTION_UP: if (null == mViewParent) &#123; //让父类拦截touch事件 getParent().requestDisallowInterceptTouchEvent(false); &#125; else &#123; mViewParent.requestDisallowInterceptTouchEvent(false); &#125; break; default: break; &#125; return super.onInterceptTouchEvent(event); &#125;&#125; 9.LocationListener，一直回调到onProviderDisabled 有可能是因为手机没有开启定位服务，解决办法是： @Overridepublic void onProviderDisabled(String provider) &#123; isLocatedSuccess = false; if (provider.equals(\"network\")) //跳到位置服务设置页面 startActivity(new Intent(android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS));&#125; 3.在真机上测试效果需要在真机上安装这两个包：com.android.vending.apk（Google play store）和com.google.android.gms.apk（Google play services）可以在国内应用市场上去搜索最新版本，也可以使用我上传的文件： 链接：http://pan.baidu.com/s/1i5q8jo5 密码：solm 安装成功以后，再运行自己的程序，查看效果了 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/01/android-googlemap-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"google map","slug":"google-map","permalink":"http://agehua.github.io/tags/google-map/"}]},{"title":"2015阅读书单","slug":"book-list-of-2015","date":"2015-11-05T16:00:00.000Z","updated":"2023-11-16T03:42:40.825Z","comments":true,"path":"2015/11/06/book-list-of-2015/","link":"","permalink":"http://agehua.github.io/2015/11/06/book-list-of-2015/","excerpt":"","text":"本文链接：http://agehua.github.io/2015/11/06/book-list-of-2015/","raw":null,"content":null,"categories":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/categories/read/"}],"tags":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/tags/read/"}]},{"title":"java多线程和并发面试问答","slug":"java-multithreading-concurrent","date":"2015-03-15T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2015/03/16/java-multithreading-concurrent/","link":"","permalink":"http://agehua.github.io/2015/03/16/java-multithreading-concurrent/","excerpt":"本文基于酷勤网关于java多线程和并发面试题的文章，进行了少量的整理和补充。原文在这。\n\n以下是正文：\n多线程和并发问题是Java技术面试中面试官比较喜欢问的问题之一。在这里，从面试的角度列出了大部分重要的问题，但是你仍然应该牢固的掌握Java多线程基础知识来对应日后碰到的问题。","text":"本文基于酷勤网关于java多线程和并发面试题的文章，进行了少量的整理和补充。原文在这。 以下是正文： 多线程和并发问题是Java技术面试中面试官比较喜欢问的问题之一。在这里，从面试的角度列出了大部分重要的问题，但是你仍然应该牢固的掌握Java多线程基础知识来对应日后碰到的问题。 Java多线程面试问题1. 什么是进程和线程？进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动，进程是系统进行资源分配和调度的一个独立单位。线程是进程的一个实体，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。 线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源（如程序计数器，一组寄存器和栈），但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。一个线程可以创建和撤销另一个线程；同一个进程中的多个线程之间可以并发执行。相对进程而言，线程是一个更加接近于执行体的概念，它可以与同进程中的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。在串行程序基础上引入线程和进程是为了提高程序的并发度，从而提高程序运行效率和响应时间。 2. 进程和线程之间有什么不同？一个进程是一个独立(self contained)的运行环境，它可以被看作一个程序或者一个应用。而线程是在进程中执行的一个任务。 简而言之,一个程序至少有一个进程,一个进程至少有一个线程。 线程的划分尺度小于进程，使得多线程程序的并发性高。 进程在执行过程中拥有独立的内存单元，而多个线程共享内存，极大地提高了程序的运行效率。 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。 从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。 形象的讲，进程就是一个项目组，每个程序员就是里面的线程呀！当然一个程序员也可以叫做一个项目组，对应的就是一个进程只有一个线程。公司里面的任务是分配给项目组级别的，干活的就是其中的程序员。总的意思就是，进程和线程没有什么区别。吐槽的话：我的意思就是进程干不过来了，那就多开几个线程呀！from JacobK 3. 多线程编程的好处是什么？ 在进程内创建、终止线程比创建、终止进程要快； 同一进程内的线程间切换比进程间的切换要快,尤其是用户级线程间的切换。 在多线程程序中，多个线程被并发的执行以提高程序的效率，CPU不会因为某个线程需要等待资源而进入空闲状态。多个线程共享堆内存(heap memory)，因此创建多个线程去执行一些任务会比创建多个进程更好。举个例子，Servlets比CGI更好，是因为Servlets支持多线程而CGI不支持。 4. 用户线程和守护线程有什么区别？当我们在Java程序中创建一个线程，它就被称为用户线程。一个守护线程是在后台执行并且不会阻止JVM终止的线程。当没有用户线程在运行的时候，JVM关闭程序并且退出（与守护线程是否在运行没有关系）。一个守护线程创建的子线程依然是守护线程。守护线程应用背景：后台线程，比如可以收集某些系统状态的线程，发送email的线程，等不希望影响JVM的事情。 5. 我们如何创建一个线程？有两种创建线程的方法：一是实现Runnable接口，然后将它传递给Thread的构造函数，创建一个Thread对象；二是直接继承Thread类。Read more… 6. 有哪些不同的线程生命周期？当我们在Java程序中新建一个线程时，它的状态是New。当我们调用线程的start()方法时，状态被改变为Runnable。线程调度器会为Runnable线程池中的线程分配CPU时间并且讲它们的状态改变为Running。其他的线程状态还有Waiting，Blocked和Dead。Read more… Java中线程的状态分为6种。 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。 阻塞(BLOCKED)：表示线程阻塞于锁。阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。 终止(TERMINATED)：表示该线程已经执行完毕。这6种状态定义在Thread类的State枚举中，可查看源码进行一一对应 https://segmentfault.com/a/1190000038392244 7. 可以直接调用Thread类的run()方法么？可以，但是如果我们调用了Thread的run()方法，它的行为就会和普通的方法一样，为了在新的线程中执行我们的代码，必须使用Thread。start()方法。 8. 如何让正在运行的线程暂停一段时间？我们可以使用Thread类的Sleep()方法让线程暂停一段时间。需要注意的是，这并不会让线程终止，一旦从休眠中唤醒线程，线程的状态将会被改变为Runnable，并且根据线程调度，它将得到执行。 9. 你对线程优先级的理解是什么？线程的优先级越高，那么就可以分占相对多的CPU时间片。每个进程都有相应的优先级，线程优先级决定它何时运行和占用CPU时间。最终的优先级共分32级。是从0到31的数值，称为 基本优先级别。OS调度的是线程，真正具有优先级的是线程，而进程优先级是作为一个优先级Class存在。一个线程创建的时候，会继承进程的优先级。 外线程优先级可以用SetThreadPriority来进行微调。常用的桌面系统，都是分时操调度，根据线程的优先级来分配调度时间。我们可以定义线程的优先级，但是这并不能保证高优先级的线程会在低优先级的线程前执行。 10. 什么是线程调度器(Thread Scheduler)和时间分片(Time Slicing)？线程调度器是一个操作系统服务，它负责为Runnable状态的线程分配CPU时间。一旦我们创建一个线程并启动它，它的执行便依赖于线程调度器的实现。时间分片是指将可用的CPU时间分配给可用的Runnable线程的过程。分配CPU时间可以基于线程优先级或者线程等待的时间。线程调度并不受到Java虚拟机控制，所以由应用程序来控制它是更好的选择（也就是说不要让你的程序依赖于线程的优先级）。 11. 在多线程中，什么是上下文切换(context-switching)？上下文切换是存储和恢复CPU状态的过程，它使得线程执行能够从中断点恢复执行。上下文切换是多任务操作系统和多线程环境的基本特征。 12. 你如何确保main()方法所在的线程是Java程序最后结束的线程？我们可以使用Thread类的joint()方法来确保所有程序创建的线程在main()方法退出前结束。Read more… 线程实例的方法join()方法可以使得一个线程在另一个线程结束后再执行。如果join()方法在一个线程实例上调用，当前运行着的线程将阻塞直到这个线程实例完成了执行。在join()方法内设定超时，使得join()方法的影响在特定超时后无效。当超时时，主方法和任务线程申请运行的时候是平等的。然而，当涉及sleep时，join()方法依靠操作系统计时，所以你不应该假定join()方法将会等待你指定的时间。 13.线程之间是如何通信的？线程间通信有三种方式： a. 使用全局变量。进程中的线程间内存共享，这是比较常用的通信方式和交互方式。主要由于多个线程可能更改全局变量，因此全局变量最好声明为violate b. 使用消息实现通信。在Windows程序设计中，每一个线程都可以拥有自己的消息队列（UI线程默认自带消息队列和消息循环，工作线程需要手动实现消息循环），因此可以采用消息进行线程间通信sendMessage,postMessage。 1)定义消息#define WM_THREAD_SENDMSG=WM_USER+20; 2)添加消息函数声明afx_msg int OnTSendmsg();3)添加消息映射ON_MESSAGE(WM_THREAD_SENDMSG,OnTSM)4)添加OnTSM()的实现函数；5)在线程函数中添加PostMessage消息Post函数 c. 使用事件CEvent类实现线程间通信。Event对象有两种状态：有信号和无信号，线程可以监视处于有信号状态的事件，以便在适当的时候执行对事件的操作。 1)创建一个CEvent类的对象：CEvent threadStart;它默认处在未通信状态；2)threadStart.SetEvent();使其处于通信状态；3)调用WaitForSingleObject()来监视CEvent对象 当线程间是可以共享资源时，线程间通信是协调它们的重要的手段。Object类中wait()notify()notifyAll()方法可以用于线程间通信关于资源的锁的状态。Read more 14. 进程间通信方式及特点？进程是转入内存并准备执行的程序，每个程序都有私有的虚拟地址空间，由代码，数据以及它可利用的系统资源(如文件，管道)组成。多进程/多线程是windows操作系统的一个基本特征。Linux系统一般都统称为进程。 由于不同的进程运行在各自不同的内存空间中，其中一个进程对于变量的修改另一方是无法感知的，因此，进程之间的消息传递不能通过变量或其他数据结构直接进行，只能通过进程间通信来完成。进程间通信是指不同进程间进行数据共享和数据交换。 进程间通信方式：文件和记录锁定，管道，有名管道，FIFO，信号量，信号，消息队列，共享内存，套接字。[^14] Read Read Read… 15. 为什么线程通信的方法wait(), notify()和notifyAll()被定义在Object类里？Java的每个对象中都有一个锁(monitor，也可以成为监视器) 并且wait()，notify()等方法用于等待对象的锁或者通知其他线程对象的监视器可用。在Java的线程中并没有可供任何对象使用的锁和同步器。这就是为什么这些方法是Object类的一部分，这样Java的每一个类都有用于线程间通信的基本方法 16. 为什么wait(), notify()和notifyAll()必须在同步方法或者同步块中被调用？当一个线程需要调用对象的wait()方法的时候，这个线程必须拥有该对象的锁，接着它就会释放这个对象锁并进入等待状态直到其他线程调用这个对象上的notify()方法。同样的，当一个线程需要调用对象的notify()方法时，它会释放这个对象的锁，以便其他在等待的线程就可以得到这个对象锁。由于所有的这些方法都需要线程持有对象的锁，这样就只能通过同步来实现，所以他们只能在同步方法或者同步块中被调用。 17. 为什么Thread类的sleep()和yield()方法是静态的？Thread类的sleep()和yield()方法将在当前正在执行的线程上运行。所以在其他处于等待状态的线程上调用这些方法是没有意义的。这就是为什么这些方法是静态的。它们可以在当前正在执行的线程中工作，并避免程序员错误的认为可以在其他非运行线程调用这些方法。 18. 如何确保线程安全？在Java中可以有很多方法来保证线程安全——同步，使用原子类(atomic concurrent classes)，实现并发锁，使用volatile关键字，使用不变类和线程安全类。Read more 19. volatile关键字在Java中有什么作用？当我们使用volatile关键字去修饰变量的时候，所以线程都会直接读取该变量并且不缓存它。这就确保了线程读取到的变量是同内存中是一致的。 20. 同步方法和同步块，哪个是更好的选择？同步块是更好的选择，因为它不会锁住整个对象（当然你也可以让它锁住整个对象）。同步方法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们停止执行并需要等待获得这个对象上的锁。 21. 如何创建守护线程？使用Thread类的setDaemon(true)方法可以将线程设置为守护线程，需要注意的是，需要在调用start()方法前调用这个方法，否则会抛出IllegalThreadStateException异常。 22. 什么是ThreadLocal?ThreadLocal用于创建线程的本地变量，我们知道一个对象的所有线程会共享它的全局变量，所以这些变量不是线程安全的，我们可以使用同步技术。但是当我们不想使用同步的时候，我们可以选择ThreadLocal变量。 每个线程都会拥有他们自己的Thread变量，它们可以使用get()set()方法去获取他们的默认值或者在线程内部改变他们的值。ThreadLocal实例通常是希望它们同线程状态关联起来是private static属性。Read more。 23. 什么是死锁(Deadlock)？如何避免死锁？死锁是指两个以上的线程永远阻塞的情况，这种情况产生至少需要两个以上的线程和两个以上的资源。死锁的四个必要条件： 互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用； 持有（Hold and wait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源； 不可剥夺（No preemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源； 环形等待（Circular wait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。 在系统中已经出现死锁后，应该及时检测到死锁的发生，并采取适当的措施来解除死锁。目前处理死锁的方法可归结为四种 24. 什么是线程池？如何创建一个Java线程池？一个线程池管理了一组工作线程，同时它还包括了一个用于放置等待执行的任务的队列。 java.util.concurrent.Executors提供了一个java.util.concurrent.Executor接口的实现用于创建线程池。如何创建和使用线程池 Java并发面试问题1. 什么是原子操作？在Java Concurrency API中有哪些原子类(atomic classes)？原子操作是指一个不受其他操作影响的操作任务单元。原子操作是在多线程环境下避免数据不一致必须的手段。 int++并不是一个原子操作，所以当一个线程读取它的值并加1时，另外一个线程有可能会读到之前的值，这就会引发错误。 为了解决这个问题，必须保证增加操作是原子的，在JDK1.5之前我们可以使用同步技术来做到这一点。到JDK1.5，java.util.concurrent.atomic包提供了int和long类型的装类，它们可以自动的保证对于他们的操作是原子的并且不需要使用同步。Read more。 2. Java Concurrency API中的Lock接口(Lock interface)是什么？对比同步它有什么优势？Lock接口比同步方法和同步块提供了更具扩展性的锁操作。他们允许更灵活的结构，可以具有完全不同的性质，并且可以支持多个相关类的条件对象。它的优势有： 可以使锁更公平 可以使线程在等待锁的时候响应中断 可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间 可以在不同的范围，以不同的顺序获取和释放锁 3. 什么是Executors框架？Executor框架同java.util.concurrent.Executor 接口在Java5中被引入。Executor框架是一个根据一组执行策略调用，调度，执行和控制的异步任务的框架。 无限制的创建线程会引起应用程序内存溢出。所以创建一个线程池是个更好的的解决方案，因为可以限制线程的数量并且可以回收再利用这些线程。利用Executors框架可以非常方便的创建一个线程池。Read more 4. 什么是阻塞队列？如何使用阻塞队列来实现生产者-消费者模型？java.util.concurrent.BlockingQueue的特性是：当队列是空的时，从队列中获取或删除元素的操作将会被阻塞，或者当队列是满时，往队列里添加元素的操作会被阻塞。 阻塞队列不接受空值，当你尝试向队列中添加空值的时候，它会抛出NullPointerException。 阻塞队列的实现都是线程安全的，所有的查询方法都是原子的并且使用了内部锁或者其他形式的并发控制。 BlockingQueue接口是java collections框架的一部分，它主要用于实现生产者-消费者问题。使用阻塞队列实现生产者-消费者问题。 5. 什么是并发容器的实现？Java集合类都是快速失败的，这就意味着当集合被改变且一个线程在使用迭代器遍历集合的时候，迭代器的next()方法将抛出ConcurrentModificationException异常。 并发容器支持并发的遍历和并发的更新。 主要的类有ConcurrentHashMap, CopyOnWriteArrayList 和CopyOnWriteArraySet。 如何在for循环中移除某些元素呢？，可以使用倒序遍历或者正序遍历移除同时修改i的值，或者使用Iterator的remove()方法。具体可以看这篇文章：https://www.cnblogs.com/zwwhnly/p/12530819.html 6. Executors类是什么？Executors为Executor，ExecutorService，ScheduledExecutorService，ThreadFactory和Callable类提供了一些工具方法。 Executors可以用于方便的创建线程池。 好文推荐秒杀多线程面试题系列进程通信方式及特点 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2015/03/16/java-multithreading-concurrent/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"multi-thread","slug":"multi-thread","permalink":"http://agehua.github.io/tags/multi-thread/"},{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"Android优秀开源项目【持续更新】","slug":"android-open-sources","date":"2015-01-26T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2015/01/27/android-open-sources/","link":"","permalink":"http://agehua.github.io/2015/01/27/android-open-sources/","excerpt":"一直想找些Android经典的开源项目学习一下，大健发现了这么一篇帖子，不少好东西，分享在此。希望能够对Android开发的同学有所帮助。感谢作者的整理和分享。tisa007原帖在这里。\n项目篇：\nApollo音乐播放器：就一个播放器，但是实现的很好\noschina客户端：oschina网站的客户端哦，wp版，iOS版都有开源\nxabber实时聊天工具（基于xmpp协议）：不评价了，反正算是同类中比较好的了\n四次元新浪微博客户端：今天才知道是开源的，赶紧收藏\nGoogle IO：谷歌开发者大会应用，虽然有点难懂，还是很有参考价值（比如其中的图片加载）\neoe客户端：eoe网站Android客户端也开源咯，嘿嘿\n","text":"一直想找些Android经典的开源项目学习一下，大健发现了这么一篇帖子，不少好东西，分享在此。希望能够对Android开发的同学有所帮助。感谢作者的整理和分享。tisa007原帖在这里。 项目篇： Apollo音乐播放器：就一个播放器，但是实现的很好 oschina客户端：oschina网站的客户端哦，wp版，iOS版都有开源 xabber实时聊天工具（基于xmpp协议）：不评价了，反正算是同类中比较好的了 四次元新浪微博客户端：今天才知道是开源的，赶紧收藏 Google IO：谷歌开发者大会应用，虽然有点难懂，还是很有参考价值（比如其中的图片加载） eoe客户端：eoe网站Android客户端也开源咯，嘿嘿 软件篇： Android-Flip：可以实现类似FlipBoard那种华丽丽的翻页 Drag-Sort-Listview：可以拖动item重新排序的listview，效果非常赞 HoloEveryWhere：咳咳，有些同学非常喜欢Android的holo风格，这个项目绝对让你happy Universal-ImageLoader：这个经典的异步图片加载，不多说了 JazzyViewPager：这玩意可以让ViewPager翻起来更酷，谁用谁知道~~ SlidingMenu：这个是抽屉界面（就是facebook那种）的各种实现版本中，最好的，木有之一！ StickyListHeaders：iPhone上经常有这个，就是listview的……不知道怎么解释，自己下载看看吧 Android-PullToRefresh：下拉刷新，挺常用的一个组件 StaggeredGridView：这是一个瀑布流布局的实现，还不是很完善，但作为学习的案例或者在其基础上扩展还是不错的 android-async-http：android的异步请求组件，我个人习惯使用asynctask，不过这个实现还是很优秀的，也推荐给大家 ActionBarSherlock：大家熟知的ActionBar在2.x上的兼容性方案；类似的兼容性组件还有许多，有时间为大家一一列出； facebook-android-sdk：不止是一个SDK那么简单哦，比某浪和某人的SDK强几个数量级； NineOldAndroids：想在2.xSDK上使用Android 3.0新增的动画API，那就是它了；没用过的同学一定要试试哦，非常方便~ android-swipelistview：让listview的item可以向右滑动，新版Gmail和Pocket里面有用到哦~ DataDroid：Android的RESTful封装，没听过RESTful？你去死吧 EventBus：和上面的DataDroid同样属于美化底层代码的，这个lib简化了不同组件之间的事件传递 android-switch-backport：Android3.0以上才有的switch，有好心人给迁移到2.x上了，哈 PagerSlidingTabStrip：最新版的GooglePlay的那个tab效果，可炫可炫了 chromeview：我们都知道webview，也知道Android的chrome又自己的内核，这个项目就是把chrome的内核给导出来做成一个chromeview了，大家可以在自己的项目里用，有兴趣的可以玩玩 picasso：来自square的图片异步加载，好像是最近才开源的，API风格很独特，哥很喜欢~ 顺便推荐大家几个网站： github：各种项目很多，就是不容易挖掘，但是开发者必备 oschina：曾经一般，现在越做越好了，很多开源项目； eoeandroid：经过一番整理，现在非常强大；小作品居多； AndroidViews：我曾经想做这么一个网站来着，很多开源组件的集合，嘿嘿 vogella:国外的一个教程网站，不是逗小孩玩的那种哦~ 大家都说github上面的项目不容易发现，但其实还是有办法的，比如：关注java项目排名：大家戳 这个网址搜索“Android”，并按star排序：戳 这里 直达最后，还有一招，就是关注些牛人，他们通常会关注或fork一些很有水平的项目。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2015/01/27/android-open-sources/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Open souces","slug":"open-souces","permalink":"http://agehua.github.io/tags/open-souces/"}]},{"title":"Hello World","slug":"hello-world","date":"2014-12-22T16:00:00.000Z","updated":"2023-11-16T03:42:40.823Z","comments":true,"path":"2014/12/23/hello-world/","link":"","permalink":"http://agehua.github.io/2014/12/23/hello-world/","excerpt":"Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.\nQuick StartCreate a new post$ hexo new \"My New Post\"\nMore info: Writing\nRun server$ hexo server","text":"Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post$ hexo new \"My New Post\" More info: Writing Run server$ hexo server More info: Server Generate static files$ hexo generate More info: Generating Deploy to remote sites$ hexo deploy More info: Deployment 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2014/12/23/hello-world/","raw":null,"content":null,"categories":[],"tags":[]}]}
\ No newline at end of file
+{"meta":{"title":"Agehua","subtitle":null,"description":"","author":"ConorLee","url":"http://agehua.github.io"},"pages":[{"title":"Categories","date":"2023-11-16T03:42:40.872Z","updated":"2023-11-16T03:42:40.872Z","comments":true,"path":"categories/index.html","permalink":"http://agehua.github.io/categories/index.html","excerpt":"","text":"本文链接：http://agehua.github.io/categories/index.html","raw":null,"content":null},{"title":"人不逍遥，名逍遥","date":"2023-11-16T03:42:40.871Z","updated":"2023-11-16T03:42:40.871Z","comments":true,"path":"about/index.html","permalink":"http://agehua.github.io/about/index.html","excerpt":"","text":"本文链接：http://agehua.github.io/about/index.html","raw":null,"content":null},{"title":"Tags","date":"2023-11-16T03:42:41.107Z","updated":"2023-11-16T03:42:41.107Z","comments":true,"path":"tags/index.html","permalink":"http://agehua.github.io/tags/index.html","excerpt":"","text":"本文链接：http://agehua.github.io/tags/index.html","raw":null,"content":null}],"posts":[{"title":"Matrix Battery 介绍和使用","slug":"matrix-battery-canary-introducation","date":"2024-12-03T16:00:00.000Z","updated":"2024-12-06T10:06:32.072Z","comments":true,"path":"2024/12/04/matrix-battery-canary-introducation/","link":"","permalink":"http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/","excerpt":"App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。\n本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位","text":"App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。 本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位 Android 系统电量统计服务Android 系统的电量统计工作，是由一个叫 BatteryStatsService 的系统服务完成的。 先了解一下其中四个比较关键的角色： 功率：power_profile.xml，Android 系统使用此文件来描述设备各个硬件模块的额定功率，包括上面提到的多档位功率和 CPU 电量算需要到的各种参数值。 时长：StopWatch &amp; SamplingCounter，其中 StopWatch ⏱ 是用来计算 App 各种硬件模块的使用时长，而 SamplingCounter 则是用来采样统计 App 在不同 CPU Core 和不同 CpuFreq 下的工作时长。 计算：PowerCalculators，每个硬件模块都有一个相应命名的 PowerCalculator 实现，主要是用来完成具体的电量统计算法。 存储：batterystats.bin，电量统计服务相关数据的持久化文件。 BatteryStatsService 时长统计流程BatteryStatsService 框架的核心是 ta 持有的一个叫 BatteryStats 的类，BatteryStats 又持有一个 Uid [] 数组，每一个 Uid 实例实际上对应一个 App，当我们安装或者卸载 App 的时候，BatteryStats 就会更新相应的 Uid 元素以保持最新的映射关系。同时 BatteryStats 持有一系列的 StopWatch 和 SamplingCounter，当 App 开始使用某些硬件模块的功能时，BatteryStats 就会调用相应 Uid 的 StopWatch 或 SamplingCounter 来统计其硬件使用时长。 这里以 Wifi 模块来举例：当 App 通过 WifiManager 系统服务调用 Wifi 模块开始扫描的时候，实际上会通过 WifiManager#startScan() --&gt; WifiScanningServiceImp --&gt; BatteryStatsService#noteWifiScanStartedFromSource() --&gt; BatteryStats#noteWifiScanStartedLocked(uid)等一连串的调用，通知 BatteryStats 开启 App 相应 Uid 的 Wifi 模块的 StopWatch 开始计时。当 App 通过 WifiManager 停止 Wifi 扫描的时候又会通过类似的流程调用 BatteryStats#noteWifiScanStoppedLocked (uid) 结束 StopWatch 的计时，这样一来就通过 StopWatch 完成 App 对 Wifi 模块使用时长的统计。 BatteryStatsService 功耗计算流程具体电量计算方面，BatteryStats 是通过 ta 依赖的一个 BatteryStatsHelper 的辅助类来完成的。BatteryStatsHelper 通过组合使用 Uid 里的时长数据、PoweProfile 里的功率数据（power_profile.xml 的解析实例）以及具体各个模块的 PowerCalculator 算法，计算出每一个 App 的综合电量消耗，并把计算结果保存在 BatterySipper [] 数组里（按计算值从大到小排序）。 还是以 Wifi 模块来举例：当需要计算 App 电量消耗的时候，BatteryStats 会通过调用 BtteryStatsHelper#refreshStats() --&gt; #processAppUsage() 来刷新 BatterySipper [] 数组以计算最新的 App 电量消耗数据。而其中 Wifi 模块单独的电量统计就是在 processAppUsage 方法中通过 WifiPowerCalculator 来完成的：Wifi 模块电量 = PowerProfile 预置的 Idle 功率 + Uid 统计的 Wifi Idle 时间 + 上行功率 × 上行时间 + 下行功率 × 下行时间。 Android 系统 App 耗电排行通过以上分析，我们其实已经知道 Android 系统 App 耗电排行是通过读取 BatteryStatsHelper 里的 BatterySipper [] 数据来实现排行的。一般情况下，BatteryStats 的统计口径是 STATS_SINCE_CHARGED, 也就距离上次设备充满电到现在的状态。不过个别 OEM 系统上这里的统计细节有所不同，有的 Android 设备系统可以显示最近数天甚至一周以上的 App 的电量统计数据，具体实现细节不得而知，姑且推断是根据 BatteryStatsHelper 自行定制的服务。 线程监控实际上，我们除了通过 SystemClock.currentThreadTimeMillis () 来获取当前 Java 线程的工作时间此外，并没有直接的办法能够直接获取 App 所有线程的工作时长和状态，幸运的是 Linux 的 proc 命令可以给我们提供一些帮助。 Linux 命令 proc/[pid]/stat 和 proc/[pid]/task/[tid]/stat 可以 Dump 当前 App 进程和线程的统计信息。 &gt; cat /proc/&lt;mypid&gt;/task/&lt;tid&gt;/stat10966 (terycanary.test) S 699 699 0 0 -1 1077952832 6187 0 0 0 22 2 0 0 20 0 17 0 9087400 5414273024 24109 18446744073709551615 421814448128 421814472944 549131058960 0 0 0 4612 1 1073775864 1 0 0 17 7 0 0 0 0 0 421814476800 421814478232 422247952384 549131060923 549131061022 549131061022 549131063262 0 这里比较关键的数据是 进程 / 线程名、进程 / 线程状态，以及第 13 - 16 位的 utime、stime、cutime 和 **cstime。utime 和 stime 分别是进程 / 线程的用户时间和系统时间，而 cutime/cstime 是当前进程等在子进程的时间（在 Android 进程上大都是 0）。实际上我们对这些数据内容也不完全是陌生的，Logcat 里一些线程相关的 syslog 也有类似的输出。 在这里有一点需要单独拎出来讲：utime 和 stime 具体代表什么意义呢？ 我们已经知道它们是表示线程的工作时长，但实际上其单位 jiffy 并不是一个时间的单位，而是一个频率的单位！ Android Linux 上，100 Jiffies ≈ 1 Second 所以我们可以记住一个比较重要的结论：在 Android 系统上，Jiffy 和 Millis 的换算关系大概是 1 比 10。（100 Hz 是一个 Linux 系统的编译参数，在不同的 Linux 版本上这个值可能是不同的。） BatteryCanary使用BatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等. 通过BatteryCanaryInitHelper这个类，sBatteryConfig = new BatteryMonitorConfig.Builder() // Thread Activities Monitor .enable(JiffiesMonitorFeature.class) .enableStatPidProc(true) .greyJiffiesTime(3 * 1000L) .enableBackgroundMode(false) .backgroundLoopCheckTime(30 * 60 * 1000L) .enableForegroundMode(true) .foregroundLoopCheckTime(20 * 60 * 1000L) .setBgThreadWatchingLimit(5000) .setBgThreadWatchingLimit(8000) // CPU Stats .enable(CpuStatFeature.class) // App &amp; Device Status Monitor For Better Invalid Battery Activities Configure .setOverHeatCount(1024) .enable(DeviceStatMonitorFeature.class) .enable(AppStatMonitorFeature.class) .setSceneSupplier(new Callable&lt;String&gt;() &#123; @Override public String call() &#123; return \"Current AppScene\"; &#125; &#125;) // AMS Activities Monitor: // alarm/wakelock watch .enableAmsHook(true) .enable(AlarmMonitorFeature.class) .enable(WakeLockMonitorFeature.class) .wakelockTimeout(2 * 60 * 1000L) .wakelockWarnCount(3) .addWakeLockWhiteList(\"Ignore WakeLock TAG1\") .addWakeLockWhiteList(\"Ignore WakeLock TAG2\") // scanning watch (wifi/gps/bluetooth) .enable(WifiMonitorFeature.class) .enable(LocationMonitorFeature.class) .enable(BlueToothMonitorFeature.class) .enable(NotificationMonitorFeature.class) // BatteryStats .enable(BatteryStatsFeature.class) .setRecorder(new BatteryRecorder.MMKVRecorder(mmkv)) .setStats(new BatteryStats.BatteryStatsImpl()) .enable(HealthStatsFeature.class) // Lab Feature: // network monitor // looper task monitor .enable(TrafficMonitorFeature.class) .enable(LooperTaskMonitorFeature.class) .addLooperWatchList(\"main\") .useThreadClock(false) .enableAggressive(true) .enable(TopThreadFeature.class) // Monitor Callback .setCallback(new BatteryStatsListener()) .build(); 总结下BatteryCanary 的功能有： 监控现场CPU使用情况，使用Jiffies 衡量 CPU状态监控 设备状态监控 App状态监控 Alarm、WakeLock监控 Wifi使用监控 Location使用监控 Bluetooth使用监控 Notification使用监控 电池状态监控 使用mmkv记录电池状态 电池健康状态，包括温度 实验功能 流量使用监控 looper任务监控（主线程） Top线程监控 初次运行Demo可能会有疑惑，不知道都有哪些功能，简单介绍下： 第一个按钮：Dump BatteryStats Report 对应 BatteryStatsFeature，使用compositeMonitors dump数据，在log里打印，并写入BatteryStatsFeature 的BatteryRecords 里// 将数据打印到日志 final Printer printer = new Printer(); printer.writeTitle(); new BatteryMonitorCallback.BatteryPrinter.Dumper().dump(compositeMonitors, printer); printer.writeEnding(); // 将数据写入 BatteryStatsFeature 的 BatteryRecorder里 BatteryStatsFeature statsFeat = BatteryCanary.getMonitorFeature(BatteryStatsFeature.class); if (statsFeat != null) &#123; statsFeat.statsMonitors(compositeMonitors); &#125; 第二个：Checkout BatteryStats Report 同样 BatteryStatsFeature，获取当前进程的 BatteryRecordsBatteryCanary.getMonitorFeature(BatteryStatsFeature.class, new Consumer&lt;BatteryStatsFeature&gt;() &#123; @Override public void accept(BatteryStatsFeature batteryStatsFeature) &#123; List&lt;BatteryRecord&gt; records = batteryStatsFeature.readRecords(dayOffset, mProc); if (mFilter != null) &#123; records = mFilter.filtering(records); &#125; BatteryRecords batteryRecords = new BatteryRecords(); batteryRecords.date = BatteryStatsFeature.getDateString(dayOffset); batteryRecords.records = records; add(batteryRecords); &#125; &#125;); 第三个：Checkout BatteryStats Report 同第二个，只是展示不同进程的数据 第四个、第五个：Show/Close TOP indicator 展示或取消 top indicator 对应 TopThreadFeature，获取下面各个feature的数据并展示BatteryCanary.getMonitorFeature(TopThreadFeature.class, new Consumer&lt;TopThreadFeature&gt;() &#123; @Override public void accept(TopThreadFeature topThreadFeat) &#123; topThreadFeat.top(seconds, new Supplier&lt;CompositeMonitors&gt;() &#123; @Override public CompositeMonitors get() &#123; CompositeMonitors monitors = new CompositeMonitors(mCore, CompositeMonitors.SCOPE_TOP_INDICATOR); monitors.metric(JiffiesMonitorFeature.UidJiffiesSnapshot.class); monitors.metric(CpuStatFeature.CpuStateSnapshot.class); monitors.metric(CpuStatFeature.UidCpuStateSnapshot.class); monitors.metric(HealthStatsFeature.HealthStatsSnapshot.class); monitors.metric(TrafficMonitorFeature.RadioStatSnapshot.class); monitors.sample(DeviceStatMonitorFeature.CpuFreqSnapshot.class, 500L); monitors.sample(DeviceStatMonitorFeature.BatteryCurrentSnapshot.class, 500L); monitors.sample(TrafficMonitorFeature.RadioBpsSnapshot.class, 500L); return monitors; &#125; &#125;, new ContinuousCallback() &#123; @Override public boolean onGetDeltas(final CompositeMonitors monitors, long windowMillis) &#123; refresh(monitors); if (mRootView == null || !mRunningRef.get(hashcode, false)) &#123; return true; &#125; return false; &#125; &#125;); &#125;&#125;); 综上是 BatteryCanary 的主要功能，后续有时间再开一篇介绍下其中原理 参考https://cloud.tencent.com/developer/article/1855937 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Matrix","slug":"matrix","permalink":"http://agehua.github.io/tags/matrix/"}]},{"title":"Matrix io 介绍和使用","slug":"matrix-io-canary-introducation","date":"2024-11-21T16:00:00.000Z","updated":"2024-12-05T09:48:36.850Z","comments":true,"path":"2024/11/22/matrix-io-canary-introducation/","link":"","permalink":"http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/","excerpt":"IO-Canary参考 Matrix IO-Canary 功能，实现对主线程操作io、重复读相同文件、读写文件buffer过小的代码动态检测","text":"IO-Canary参考 Matrix IO-Canary 功能，实现对主线程操作io、重复读相同文件、读写文件buffer过小的代码动态检测 主要类IOIssue在 Java 层实体类是：public final class IOIssue &#123; public final int type; public final String path; public final long fileSize; public final int opCnt; public final long bufferSize; public final long opCostTime; public final int opType; public final long opSize; public final String threadName; public final String stack; public final int repeatReadCnt; public IOIssue(int type, String path, long fileSize, int opCnt, long bufferSize, long opCostTime, int opType, long opSize, String threadName, String stack, int repeatReadCnt) &#123; this.type = type; this.path = path; this.fileSize = fileSize; this.opCnt = opCnt; this.bufferSize = bufferSize; this.opCostTime = opCostTime; this.opType = opType; this.opSize = opSize; this.threadName = threadName; this.stack = stack; this.repeatReadCnt = repeatReadCnt; &#125;&#125; detector.h功能实现是在Native层，可以先看 detector.h 这个类 #ifndef MATRIX_IO_CANARY_DETECTOR_H#define MATRIX_IO_CANARY_DETECTOR_H#include &lt;vector&gt;#include &lt;set&gt;#include \"core/io_info_collector.h\"#include \"core/io_canary_env.h\"namespace iocanary &#123; typedef enum &#123; kDetectorMainThreadIO = 0, kDetectorSmallBuffer, kDetectorRepeatRead &#125; DetectorType; typedef enum &#123; kIssueMainThreadIO = 1, kIssueSmallBuffer, kIssueRepeatRead &#125; IssueType ; class Issue &#123; public: Issue(IssueType type, IOInfo file_io_info); const IssueType type_; const IOInfo file_io_info_; const std::string key_; int repeat_read_cnt_; std::string stack; private: static std::string GenKey(const IOInfo&amp; file_io_info); &#125;; class FileIODetector &#123; public: virtual ~FileIODetector(); virtual void Detect(const IOCanaryEnv&amp; env, const IOInfo&amp; file_io_info, std::vector&lt;Issue&gt;&amp; issues) = 0; protected: void PublishIssue(const Issue&amp; target, std::vector&lt;Issue&gt;&amp; issues); private: void MarkIssuePublished(const std::string&amp; key); bool IsIssuePublished(const std::string&amp; key); std::set&lt;std::string&gt; published_issue_set_; &#125;;&#125;#endif //MATRIX_IO_CANARY_DETECTOR_H 重点看 Detect 方法的实现，有三个类，分别是：main_thread_detector.cc 、repeat_read_detector.cc、small_buffer_detector.cc 每个类对应一个功能，触发场景分别如下： 检测场景main_thread_detector触发条件： 1.必须是主线程 2.单次文件读写超过时间限制（kPossibleNegativeThreshold），type = 1，位置见下面 3.整体连续读写超时（kDefaultMainThreadTriggerThreshold）,type = 2，位置见下面 4.两种情况可以同时命中，type = 3 5.type不等于1，则上报 同时，用repeat_read_cnt 来记录type 值。 repeat_read_detector触发条件比较复杂： 1.用map记录文件被读取次数，文件path作为key。如果最大读取时间小于 kPossibleNegativeThreshold，则不会向map里记录。否则会计入map 2.如果文件被写过，从map中拿到repeat信息，清空该repeat信息，否则记录然后+1 3.如果repeat count 大于等于 kDefaultRepeatReadThreshold 次数，则上报 small_buffer_detector这个比较简单： 1.buffer 操作次数 大于 kSmallBufferOpTimesThreshold 2.buffer 的空间大小 小于 kDefaultBufferSmallThreshold （4096KB） 3.最大读写时间 大于等于 kPossibleNegativeThreshold 4.三种条件需要同时满足，就会上报 #### 预定义的限制数据，都是定义在 io_canary_env.h 文件中：#ifndef MATRIX_IO_CANARY_IO_CANARY_ENV_H#define MATRIX_IO_CANARY_IO_CANARY_ENV_Hnamespace iocanary &#123; enum IOCanaryConfigKey &#123; kMainThreadThreshold = 0, kSmallBufferThreshold, kRepeatReadThreshold, //!!kConfigKeysLen always the last one!! kConfigKeysLen &#125;; class IOCanaryEnv &#123; public: IOCanaryEnv(); void SetConfig(IOCanaryConfigKey key, long val); long GetJavaMainThreadID() const; long GetMainThreadThreshold() const; long GetSmallBufferThreshold() const; long GetRepeatReadThreshold() const; //in μs. //it may be negative if the io-cost more than POSSIBLE_NEGATIVE_THRESHOLD //else it can be negligible //80% of the well-known 16ms constexpr static const int kPossibleNegativeThreshold = 13*1000; constexpr static const int kSmallBufferOpTimesThreshold = 20; private: long GetConfig(IOCanaryConfigKey key) const; //in μs constexpr static const int kDefaultMainThreadTriggerThreshold = 500*1000; // 500毫秒 //We take 4096B(4KB) as a small size of the buffer constexpr static const int kDefaultBufferSmallThreshold = 4096; constexpr static const int kDefaultRepeatReadThreshold = 5; long configs_[IOCanaryConfigKey::kConfigKeysLen]; &#125;;&#125;#endif //MATRIX_IO_CANARY_IO_CANARY_ENV_H Matrix 向后兼容Matrix 目前只兼容到了Android P，也就是 Android 9。 下面对 Android 9 以上版本的适配，做了一定的兼容，当然下面的代码仅仅说明了适配的方向，可能还有一些其他问题需要处理。 对于 Closeable 泄露监控来说，在 Android 10 及上无法兼容的原因是 CloseGuard#getReporter 无法直接通过反射获取， reporter 字段也是无法直接通过反射获取。如果无法获取到原始的 reporter，那么原始的 reporter 在我们 hook 之后就会失效。如果我们狠下决心，这也是可以接受的，但是对于这种情况我们应该尽量避免。 那么我们现在的问题就是如何在高版本上获取到原始的 reporter，那么有办法吗？有的，因为我们前面说到了无法直接通过反射获取，但是可以间接获取到。这里我们可以通过 反射的反射 来获取。实例如下： private static void doHook() throws Exception &#123; Class&lt;?&gt; clazz = Class.forName(\"dalvik.system.CloseGuard\"); Class&lt;?&gt; reporterClass = Class.forName(\"dalvik.system.CloseGuard$Reporter\"); Method setEnabledMethod = clazz.getDeclaredMethod(\"setEnabled\", boolean.class); setEnabledMethod.invoke(null, true); // 直接反射获取reporter// Method getReporterMethod = clazz.getDeclaredMethod(\"getReporter\");// final Object originalReporter = getReporterMethod.invoke(null); // 反射的反射获取 Method getDeclaredMethodMethod = Class.class.getDeclaredMethod(\"getDeclaredMethod\", String.class, Class[].class); Method getReporterMethod = (Method) getDeclaredMethodMethod.invoke(clazz, \"getReporter\", null); final Object originalReporter = getReporterMethod.invoke(null); Method setReporterMethod = clazz.getDeclaredMethod(\"setReporter\", reporterClass); Object proxy = Proxy.newProxyInstance( reporterClass.getClassLoader(), new Class&lt;?&gt;[]&#123;reporterClass&#125;, new InvocationHandler() &#123; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable &#123; return method.invoke(originalReporter, args); &#125; &#125; ); setReporterMethod.invoke(null, proxy);&#125; 对于 native hook 的三种场景来说，Android 9 版本以上无法适配的原因应该是 hook 失效导致的。可以使用字节的 bytehook 替换老旧的 xhook 来达到同样的效果。 同时对于 9 以后的版本需要 hook “libc.so” 的write和 read 方法：// ...bool is_libjavacore = (strstr(so_name, \"libc.so\") != nullptr || strstr(so_name, \"libjavacore.so\") != nullptr);if (is_libjavacore) &#123; bytehook_stub_t stub2 = bytehook_hook_single(so_name, NULL, \"read\", (void *) ProxyRead, hacker_bytehook_hooked_callback, NULL); if (stub2 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook read failed, try __read_chk\"); bytehook_stub_t stub3 =bytehook_hook_single(so_name, NULL, \"__read_chk\", (void *) ProxyReadChk,hacker_bytehook_hooked_callback, NULL); if (stub3 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook failed: __read_chk\"); return JNI_FALSE; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook __read_chk success\"); anrHookStubs.push_back(stub3); &#125; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook read success\"); anrHookStubs.push_back(stub2); &#125; bytehook_stub_t stub4 = bytehook_hook_single(so_name,NULL, \"write\", (void*)ProxyWrite, hacker_bytehook_hooked_callback, NULL); if (stub4 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook write failed, try __write_chk\"); bytehook_stub_t stub5 = bytehook_hook_single(so_name, NULL,\"__write_chk\", (void*)ProxyWriteChk, hacker_bytehook_hooked_callback, NULL); if (stub5 == nullptr) &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook failed: __write_chk\"); return JNI_FALSE; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook __write_chk success\"); anrHookStubs.push_back(stub5); &#125; &#125; else &#123; __android_log_print(ANDROID_LOG_WARN, kTag, \"doHook hook write success\"); anrHookStubs.push_back(stub4); &#125;&#125;// ... 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Matrix","slug":"matrix","permalink":"http://agehua.github.io/tags/matrix/"}]},{"title":"代码覆盖率统计——集成Jacoco","slug":"jacoco-test-coverage","date":"2024-04-23T16:00:00.000Z","updated":"2024-12-05T09:41:25.295Z","comments":true,"path":"2024/04/24/jacoco-test-coverage/","link":"","permalink":"http://agehua.github.io/2024/04/24/jacoco-test-coverage/","excerpt":"代码覆盖率代码覆盖率是软件测试中一个重要的评价指标。主要是指程序运行过程中，被执行到的代码在总代码中的占比程度，现在有很多插件可以实现这个功能，应用比较广的就是jacoco。\n代码覆盖率从测试方式上有两个方向可以进行：\n\n单元测试（白盒测试）\n功能测试（黑盒测试）\n\n下面在Android工程中，分别用Jacoco来实现这两个方向的代码覆盖率统计：","text":"代码覆盖率代码覆盖率是软件测试中一个重要的评价指标。主要是指程序运行过程中，被执行到的代码在总代码中的占比程度，现在有很多插件可以实现这个功能，应用比较广的就是jacoco。 代码覆盖率从测试方式上有两个方向可以进行： 单元测试（白盒测试） 功能测试（黑盒测试） 下面在Android工程中，分别用Jacoco来实现这两个方向的代码覆盖率统计： 单元测试单元测试代码覆盖率对于单元测试（白盒测试），gradle编译工具已经集成了JaCoCo插件，只需要添加这个插件，然后在工具栏 Run “YourUnitTestCase” with Coverage 即可，执行完用例之后，在IDE右侧会自动显示覆盖率报告，也可以单独建一个gradle task来生成jacoco覆盖率报告。 需要编写单元测试代码 使用下面的gradle task来生成单元测试的报告// 源代码路径def coverageSourceDirs = [ '../app/src/main/java']task jacocoTestReport(type: JacocoReport) &#123; group = \"Reporting\" description = \"Generate Jacoco coverage reports after running tests.\" reports &#123; xml.enabled = true html.enabled = true &#125; // 字节码路径 classDirectories.from = fileTree( dir: './build/intermediates/javac/debug', excludes: ['**/R*.class', '**/*$InjectAdapter.class', '**/*$ModuleAdapter.class', '**/*$ViewInjector*.class' ]) sourceDirectories.from = files(coverageSourceDirs) // 覆盖率数据路径，这个数据是执行单测时自动生成的 executionData.from = files(\"$buildDir/outputs/unit_test_code_coverage/debugUnitTest/testDebugUnitTest.exec\") doFirst &#123; new File(\"$buildDir/intermediates/javac/\").eachFileRecurse &#123; file -&gt; if (file.name.contains('$$')) &#123; file.renameTo(file.path.replace('$$', '$')) &#125; &#125; &#125;&#125; 黑盒测试代码覆盖率黑盒测试，也叫功能测试，也就是把app装在手机上，人工（或自动化）去操作UI界面。这种测试的代码覆盖率，用JaCoCo也可以统计到。 常见获取覆盖率的方法分两种，一种是在源码中，以打桩的形式，收集覆盖率数据，针对性较强，但是需要深入源码，另一种是改写应用入口，通过instrument启动应用，记录应用执行期间全局的代码覆盖率。 大致分为三个步骤： 使用gradle编译apk、aar、jar时，添加jacoco插件（记得只在buildType为debug时开启），完成插桩。apk/aar/jar运行期间，在指定时机（比如OnDestroy时或者用户点击按钮）利用反射机制调用 jacoco api 拿到覆盖率统计数据，然后保存到手机，如果做了覆盖率平台，可以上传到平台。把覆盖率数据从手机pull下来，在gradle里面添加一个生成报告的任务（参考上面单元测试代码覆盖率报告生成）。如果是做成了平台，也可以调用 jacoco api 根据覆盖率数据、源码、字节码生成报告并展示。下面请看例子： 调用下面代码来生成对应报告fun generateEcFile(isNew: Boolean, generateCallback: ((Boolean) -&gt; Unit)? = null) &#123; var out: OutputStream? = null val dir = FacadeHelper.getApplicationContext().getExternalFilesDir(null).toString() + \"/shareData/\" val target = dir + File.separator + \"coverage.ec\" val mCoverageFilePath = File(target) try &#123; val targetDir = File(dir) if (!targetDir.exists()) &#123; targetDir.mkdirs() &#125; if (isNew &amp;&amp; mCoverageFilePath.exists()) &#123; JaLog.d(TAG, \"清除旧的ec文件\") mCoverageFilePath.delete() &#125; if (!mCoverageFilePath.exists()) &#123; mCoverageFilePath.createNewFile() &#125; out = FileOutputStream(mCoverageFilePath.path, true) val agent = Class.forName(\"org.jacoco.agent.rt.RT\") .getMethod(\"getAgent\") .invoke(null) if (agent != null) &#123; out.write( agent.javaClass.getMethod(\"getExecutionData\", Boolean::class.javaPrimitiveType) .invoke(agent, false) as ByteArray ) &#125; generateCallback?.invoke(true) &#125; catch (e: Exception) &#123; JaLog.d(TAG, e.toString()) generateCallback?.invoke(false) &#125; finally &#123; try &#123; out?.close() &#125; catch (e: IOException) &#123; JaLog.d(TAG, e.toString()) generateCallback?.invoke(false) &#125; &#125; &#125; 支持多Module源码在下面，主要实现步骤： 1.在App module中定义一个jacoco.gradle，引入jacoco插件 2.定义一个 copyTask，将class文件和source code文件复制到指定目录（这里复制到了 /build/custom下） 3.在 copyTask中遍历项目所有的 project，对每个 project执行复制操作 复制文件方法参考： Gradle Copy Task 4.copyTask每次在 package${buildType} 任务后执行，这样打好包后，文件也已复制完毕 这里支持多种buildType构建，比如debug、staging等。但不支持release 5.从App拿到覆盖率数据，放到指定目录后，执行 jacocoTestReport，将在 build/reports/ 目录下生成Html报告 6.最后，在app.gradle中定义开关，根据开关状态判断是否引入 jacoco.gradle 如果是由服务端生成最终报告，需要上传覆盖率数据和class文件。因为所有class文件都在一个目录，可以轻易将class文件打包为一个jar，将jar包传给服务端 // jacoco.gradle文件apply plugin: 'jacoco'//Jacoco 版本，本篇创建时最新版本jacoco &#123; toolVersion = \"0.8.11\"&#125;//源代码存放路径def sourceCodeDirs = \"$buildDir/customJavaSources\"def javaClassDirs = \"$buildDir/customJavaClasses\"def currentBuildType = nulltasks.register('copyTask') &#123; group = \"JacocoReport\" def originalSourceDir = &#123; Set&lt;Project&gt; projects = project.rootProject.subprojects List&lt;String&gt; tmpDir = new ArrayList&lt;&gt;(projects.size()) projects.forEach &#123;// println(\"当前project is $&#123;it.name&#125;\") tmpDir.add(\"$it.projectDir/src/main/java\") &#125; tmpDir &#125; def originalJavaClassDir = &#123; Set&lt;Project&gt; projects = project.rootProject.subprojects List&lt;String&gt; tmpDir = new ArrayList&lt;&gt;(projects.size()) projects.forEach &#123; def subBuildType = currentBuildType.toLowerCase() if (it.name != \"app\") &#123; try &#123; def androidConfig = it.extensions.getByName('android') def buildTypeExists = androidConfig.buildTypes.any &#123; it.name.equalsIgnoreCase(subBuildType) &#125; if (!buildTypeExists) &#123; subBuildType = 'debug' &#125;// println(\"当前 project($&#123;it.name&#125;) 的config $&#123;androidConfig&#125;，buildtype 是$&#123;subBuildType&#125;\") &#125; catch (Exception e) &#123; subBuildType = 'debug'// println(\"当前 project($&#123;it.name&#125;) 没有 'android' 扩展名: $&#123;e.message&#125;\") &#125; &#125; tmpDir.add(\"$it.projectDir/build/intermediates/javac/$&#123;subBuildType&#125;/classes\") &#125; tmpDir &#125; def originalKotlinClassDir = &#123; Set&lt;Project&gt; projects = project.rootProject.subprojects List&lt;String&gt; tmpDir = new ArrayList&lt;&gt;(projects.size()) projects.forEach &#123; def subBuildType = currentBuildType.toLowerCase() if (it.name != \"app\") &#123; try &#123; def androidConfig = it.extensions.getByName('android') def buildTypeExists = androidConfig.buildTypes.any &#123; it.name.equalsIgnoreCase(subBuildType) &#125; if (!buildTypeExists) &#123; subBuildType = 'debug' &#125;// println(\"当前 project($&#123;it.name&#125;) 的config $&#123;androidConfig&#125;，buildtype 是$&#123;subBuildType&#125;\") &#125; catch (Exception e) &#123; subBuildType = 'debug'// println(\"当前 project($&#123;it.name&#125;) 没有 'android' 扩展名: $&#123;e.message&#125;\") &#125; &#125;// tmpDir.add(\"$it.projectDir/build/tmp/kotlin-classes/debug\") // https://issuetracker.google.com/issues/161300933#comment13 tmpDir.add(\"$it.projectDir/build/intermediates/asm_instrumented_project_classes/$&#123;subBuildType&#125;\") &#125; tmpDir &#125; doLast &#123; if (!Boolean.parseBoolean(enableJacoco)) &#123; println(\"开关未打开，不复制文件\") return &#125; println(\"开始删除文件\") delete sourceCodeDirs delete javaClassDirs println(\"开始复制文件\") // https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Copy.html copy &#123; from originalSourceDir // 目标目录 into sourceCodeDirs duplicatesStrategy = DuplicatesStrategy.INCLUDE exclude '**/com/blelib/**', \"**/com/alibaba/**\", \"**/com/bumptech/**\", \"**/com/chad/**\", '**/*_HiltComponents**' println(\"复制java源文件开始\") &#125; copy &#123; from originalJavaClassDir // 目标目录 into javaClassDirs duplicatesStrategy = DuplicatesStrategy.INCLUDE exclude '**/com/blelib/**', \"**/com/alibaba/**\", \"**/com/bumptech/**\", \"**/com/chad/**\", '**/*_HiltComponents**' println(\"复制java class开始\") &#125; copy &#123; from originalKotlinClassDir // 目标目录 into javaClassDirs duplicatesStrategy = DuplicatesStrategy.INCLUDE exclude '**/com/blelib/**', \"**/com/alibaba/**\", \"**/com/bumptech/**\", \"**/com/chad/**\", '**/*_HiltComponents**' println(\"复制Kotlin class开始\") &#125; println(\"复制文件完成\") &#125;&#125;//初始化Jacoco Tasktasks.register('jacocoInit') &#123; group = \"JacocoReport\" File file = new File(\"$buildDir/outputs/code-coverage/\") if (!file.exists()) &#123; file.mkdir() &#125;&#125;/** * 单元测试，生成报告task */tasks.register('jacocoTestReport', JacocoReport) &#123; group = \"JacocoReport\" description = \"Generate Jacoco coverage reports after running tests.\" reports &#123; xml.enabled = true html.enabled = true &#125; def excludes = [ '**_HiltComponents_**', '**/*databinding*/**', '**/*BindingImpl*', '**/*hilt_aggregated_deps*/**' ] classDirectories.from = files([fileTree(dir: javaClassDirs, excludes: excludes)]) sourceDirectories.from = files([sourceCodeDirs])// sourceDirectories.from = files([fileTree(dir: sourceCodeDirs, excludes: excludes)]) // 这行报错 // 将 coverage.ec文件提前复制到这里：adb pull /storage/emulated/0/Android/data/com.xxx.xxx/files/shareData/coverage.ec executionData.from = files(\"$buildDir/outputs/code-coverage/coverage.ec\")&#125;afterEvaluate &#123; def taskNames = gradle.startParameter.taskNames taskNames.each &#123; taskName -&gt; println \"Current taskName: $taskName\" if (taskName.toLowerCase().contains(\"debug\")) &#123; currentBuildType = \"Debug\" &#125; else if (taskName.toLowerCase().contains(\"staging\")) &#123; currentBuildType = \"Staging\" &#125; &#125; if (currentBuildType != null) &#123; println \"Current Build Type: $currentBuildType\" &#125; else &#123; println \"Could not determine current build type.\" return &#125; def jacocoTestReport = tasks.findByName('copyTask') def merge = tasks.findByName(\"package$&#123;currentBuildType&#125;\") if (null != merge) &#123; merge.finalizedBy(jacocoTestReport)// jacocoTestReport.dependsOn(merge) &#125; else &#123; println(\"任务未找到\") &#125;&#125; // app.gradle，省略其他代码// 是否开启代码分析if (Boolean.parseBoolean(enableJacoco)) &#123; apply from: 'jacoco.gradle'&#125; Hilt支持正常的kotlin生成的class文件路径：build/tmp/kotlin-classes/debug，如果使用这个路径，@AndroidEntryPoint 修饰的类的覆盖率测试一直是0。需要替换为 build/intermediates/asm_instrumented_project_classes/debug 这个路径，参考：https://issuetracker.google.com/issues/161300933#comment13 Failed resolution of: Lorg/jacoco/agent/rt/internal_/Offline官方FAQ有解释： If you use offline instrumentation the instrumented classes get a direct dependency on the JaCoCo runtime. Therefore jacocoagent.jar of the same JaCoCo version must be on the classpath and accessible from by the instrumented classes. 但是出现这个问题有两种情况： 第一种情况是确实缺少 jacocoagent.jar，那需要下载和gradle里一致的版本，不要下错。 1.下载地址：https://repo1.maven.org/maven2/org/jacoco/jacoco/ 2.改为使用统一版本。在项目级的build.gradle里加入下面代码：subprojects &#123; configurations.all &#123; resolutionStrategy &#123; eachDependency &#123; details -&gt; if ('org.jacoco' == details.requested.group) &#123; details.useVersion \"0.8.11\" &#125; &#125; &#125; &#125;&#125; 第二种情况是使用了混淆，导致找不到class，需要在混淆文件中添加下面的规则：-keep class org.jacoco.**&#123;*;&#125;-keep class com.vladium.emma.**&#123;*;&#125; 拿到手机上的测试覆盖数据执行adb命令就可以：adb pull /storage/emulated/0/Android/data/com.xxx.xxx/files/shareData/coverage.ec 关于混淆尽量使用同一种，否则在合并测试报告时会出问题：https://stackoverflow.com/questions/54629643/merge-jacoco-results-obfuscated-and-not-obfuscated-runs 增量代码覆盖率 计算增量的最小单位是 方法，即使方法中有一行变更，那也算作方法变更 配合git，拿到相关变更方法 需要修改Jacoco的代码，因为Jacoco的方法注入为全量注入。 大概架构图 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2024/04/24/jacoco-test-coverage/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Jacoco","slug":"jacoco","permalink":"http://agehua.github.io/tags/jacoco/"}]},{"title":"Native Crash日志分析","slug":"native-crash-anr-log-analysis","date":"2023-11-12T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2023/11/13/native-crash-anr-log-analysis/","link":"","permalink":"http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/","excerpt":"本文是上一篇《Native Crash 捕获原理》的姊妹篇，主要介绍如何分析Native Crash日志，以及常见的Native Crash类型","text":"本文是上一篇《Native Crash 捕获原理》的姊妹篇，主要介绍如何分析Native Crash日志，以及常见的Native Crash类型 NA Crash日志对比Logcat中抓到的日志：A Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 14206 (conorlee.test), pid 14206 (conorlee.test)Cmdline: com.conorlee.testpid: 14206, tid: 14206, name: conorlee.test &gt;&gt;&gt; com.conorlee.test &lt;&lt;&lt; #00 pc 000000000000f6d0 /data/app/~~thPbPJ0ZokAxuuRZPsdShQ==/com.conorlee.test-_xwNfmDQiQWDDcg5TlCGqA==/lib/arm64/libcrash-lib.so (Crash()+20) (BuildId: ad36e849968841628dab3afed7e6010c4c500b02) #01 pc 000000000000f774 /data/app/~~thPbPJ0ZokAxuuRZPsdShQ==/com.conorlee.test-_xwNfmDQiQWDDcg5TlCGqA==/lib/arm64/libcrash-lib.so (Java_com_dodola_breakpad_MainActivity_crash+20) (BuildId: ad36e849968841628dab3afed7e6010c4c500b02) #04 pc 000000000031cad4 /data/data/com.conorlee.test/code_cache/.overlay/base.apk/classes.dex (com.conorlee.test.MainActivity$1$1.run+8) #08 pc 000000000031cb1c /data/data/com.conorlee.test/code_cache/.overlay/base.apk/classes.dex (com.conorlee.test.MainActivity$1.onClick+20) APM SDK抓到的日志（理想状态）：Native Crash, signal: 11, tname: conorlee.test, pid: 13283, tid: 13283, code: 1, error: 0Stack trace is #0, pc 61075, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so, (sname: Java_com_dodola_breakpad_MainActivity_stringFromJNI, saddr: 55) #1, pc 61019, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so, (sname: Java_com_dodola_breakpad_MainActivity_crash, saddr: 15) #2, pc 61003, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so, (sname: _Z5Crashv, saddr: 15) #3, pc 60987, fname: /data/app/~~kP4phbJym0CIi4w4vSCamQ==/com.conorlee.test-qFT3bN7o6AtUgPbpqY5P0Q==/lib/arm64/libcrash-lib.so Java thread(main), stack is : com.conorlee.test.MainActivity.crash() -2 com.conorlee.test.MainActivity$1$1.run() 63 java.lang.Thread.run() 1,015 com.conorlee.test.MainActivity$1.onClick() 65 android.view.View.performClick() 7,614 android.view.View.performClickInternal() 7,591 android.view.View.-$$Nest$mperformClickInternal() 0 android.view.View$PerformClick.run() 29,809 android.os.Handler.handleCallback() 942 android.os.Handler.dispatchMessage() 99 android.os.Looper.loopOnce() 223 android.os.Looper.loop() 324 android.app.ActivityThread.main() 8,546 java.lang.reflect.Method.invoke() -2 com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run() 582 com.android.internal.os.ZygoteInit.main() 1,061 上面的关键信息有： NA Crash，Signal 11 -&gt; SIGSEGV -&gt; 非法内存操作，空指针操作 进程名，包名只展示后15个字符 pid 进程id；tid 线程id code 1，代表 SEGV_MAPERR Native调用堆栈（backtrace）。具体数据都来自Dl_info结构体 行号计数（#0） pc（加载模块的句柄） dli_fname（一个指针，指向包含address的加载模块的文件名） dli_sname（一个指针，指向与指定address最接近的符号的名称） saddr（地址的偏移量，即与代码段函数地址的偏移量） Java调用堆栈（根据线程名匹配） 根据日志堆栈定位到代码使用addr2line和objdump命令这两个命令行工具已在NDK中集成，在我的mac上地址如下：/Users/xxx/Library/Android/sdk/ndk/21.4.7075529/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin addr2line 工具可以帮助定位到代码行号执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可：./aarch64-linux-android-addr2line -e /Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/build/intermediates/cmake/normDebug/obj/arm64-v8a/libcrash-lib.so 000000000000f6d0 000000000000f774 结果如下：/Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/.cxx/Debug/2b1z3a2r/arm64-v8a/../../../../src/main/cpp/crash.cpp:13/Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/.cxx/Debug/2b1z3a2r/arm64-v8a/../../../../src/main/cpp/crash.cpp:29 从addr2line的结果就能看到，我们拿到了错误代码的调用行数（其实也可以分析出调用关系，本例体现不出来），在crash.cpp的13行和29行 addr2line 命令使用介绍：https://cloud.tencent.com/developer/article/2019609 objdump命令获取函数信息通过addr2line命令，其实我们已经找到了我们代码中出错的位置，已经可以帮助程序员定位问题所在了。但是，这个方法只能获取代码行数，并没有显示函数信息，下面就用objdump命令来获取函数信息. /Users/xxx/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump -S /Users/xxx/StudioProjects/NativeCrash1/NativeCrashCatcher/app/build/intermediates/cmake/normDebug/obj/arm64-v8a/libcrash-lib.so &gt; testcrash.asm 在生成的asm文件中查找刚刚我们定位的关键指针000000000000f6d0，如下图 从上图可以看出，这个指针所在的方法名。结合前面的行号，可以进一步确定发生异常的位置（要注意的是，在不同的NDK版本和不同的操作系统中，asm文件的格式不是完全相同，但都大同小异，请大家仔细比对）。 objdump命令详细介绍：https://cloud.tencent.com/developer/article/1494510 实时解析crash日志使用 ndk-stack工具，在我的电脑上，位置是：/Users/xxx/Library/Android/sdk/ndk/21.4.7075529/ndk-stack 使用方法如下：adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi-v7a 参考链接：https://developer.android.com/ndk/guides/ndk-stack?hl=zh-cn 进程名展示不全原因Tips: 为什么进程名对比包名，有时候展示不全？ 简单来说，这是因为Linux内核的一个特性：一个进程有两个不同的名称。 其中一个是可执行文件路径的最后一个组件。例如，如果您的应用程序位于/data/app/com.example.hello/native_executable，则为native_eexecute。这是出现在/proc/PID/status的“名称”字段中的名称。内核将其截断为15个字符，因此在本例中它包含native_executob。 另一个名称由调用应用程序的程序传递，作为其命令行参数。这是出现在/proc/PID/cmdline开头的名称，ps显示该名称。 可执行文件的路径也是符号链接/proc/PID/exe的目标。按照惯例，当一个程序启动另一个程序时，它应该使用可执行文件的名称作为命令行参数0，但它可以选择其他方式。/proc/PID/status的Name字段始终设置为内核可执行文件的（截断的）名称。 来自：https://stackoverflow.com/questions/14176058/why-is-the-name-of-a-process-in-proc-pid-status-not-matching-package-name-or-ps 线上崩溃堆栈还原 1.模拟示例源码： int add()&#123; int a = 1; a ++; int b = a+3; return b;&#125;int div()&#123; int a = 1; a ++; int b = a/0; //这里除0会引发崩溃 return b;&#125;int _tmain(int argc, _TCHAR* argv[])&#123; add(); sub(); return 0;&#125; 2.对应符号表，这里简化了符号表，没带行号信息 0x00F913B0 ~ 0x00F913F0 add()0x00F91410 ~ 0x00F91450 div()0x00F91A90 ~ 0x00F91ACD _tmain() 3.现有一崩溃堆栈 0x00F9143A0x00F91AB0 4.进行符号化 0x00F9143A div() //查找符号表，地址0x00F9143A的符号名，在0x00F91410 ~ 0x00F91450范围内0x00F91AB0 _tmain() //查找符号表，地址0x00F91AB0的符号名，在0x00F91A90 ~ 0x00F91ACD范围内 这里的符号化最终也是用到addr2line工具 更详细信息参考：客户端堆栈还原原理及实现 常见的NA Crash类型1. SIGILLSIG是信号名的通用前缀，ILL是 illegal instruction（ 非法指令 ） 的缩写。 对应的数值为 4。 SIGILL 是当一个进程尝试执行一个非法指令时发送给它的信号。 常见原因有: CPU架构不匹配 .so 文件被破坏，或者代码段被破坏导致； 主动崩溃，如 _builtintrap() 也会使用非法指令来实现。 si_addr 为出错的指令。 该信号量中常见的错误码说明： Code 说明 ILL_ILLOPC 非法的操作码(opcode) ILL_ILLOPN 非法的操作数(operand) ILL_ILLADR 非法的寻址模式 ILL_ILLTRP 非法的trap ILL_PRVOPC 特权操作码(Privileged opcode) ILL_PRVREG 特权寄存器(Privileged register) ILL_COPROC 协处理器错误 ILL_BADSTK 内部堆栈错误 2. SIGBUSSIG是信号名的通用前缀，BUS是bus error (总线错误) ，意味着系统检测到硬件问题后发送给进程的信号。 对应的数值为7。 通常该信号的产生不是因为硬件有物理上的损坏，而是代码实现有 bug 导致 ，如地址不对齐，或者不存在的物理地址等。 si_addr 为所访问的非法地址。 该信号量中常见的错误码说明： Code 说明 BUS_ADRALN 访问的地址不对齐。32位处理器一般要求指针是4字节对齐的 BUS_ADRERR 访问不存在的物理地址。一般是由于 mmap 的文件发生 truncated 导致。常见于文件访问过程中，被删除或者替换；或 mmap 到内存后，继续向文件写入且导致文件 truncated，再读取时就会出现该错误；另外， mmap 且访问超过文件实际大小的空间时，也可能会出现该错误 BUS_OBJERR 特定对象的硬件错误 BUS_MCEERR_AR BUS_MCEERR_AR BUS_MCEERR_AQ BUS_MCEERR_AQ 3. SIGSEGVSIG 是信号名的通用前缀, SEGV 是 segmentation violation 的缩写。 对应的数值为 11。 该信号意味着一个进程执行了一个无效的内存引用，或发生段错误。 si_addr 为所访问的无效地址。 该信号量中常见的错误码说明： Code 说明 SEGV_MAPERR 地址不在 /proc/self/map 映射中 SEGV_ACCERR 没有访问权限 4. SIGFPESIG是信号名的通用前缀。FPE是floating-point exception（浮点异常）的首字母缩写拼接而成。 对应的数值为 8。 该信号一般是算术运算相关问题导致的。 si_addr 为失败的指令。 该信号量中常见的错误码说明： Code 说明 FPE_INTDIV 整数除以 0 FPE_INTOVF 整数溢出 FPE_FLTDIV 浮点数除以 0 FPE_FLTOVF 浮点数向下溢出 FPE_FLTRES 浮点数结果不精确 FPE_FLTINV 无效的浮点运算 FPE_FLTSUB 下标超出范围 5. SIGABRTSIG是信号名的通用前缀。ABRT是abort program的缩写。 对应的数值为 6。 该信号意味着异常退出；通常是调用 abort(), raise(), kill(), pthread_kill() 或者被系统进程杀死时出现。 当错误码为 SI_USER 时表示是被其它程序杀死，一般情况是由于ANR被 system_server 杀死； 其他错误码一般是业务自己调用 abort() 等函数退出，此时错误码一般认为无效。 6. SIGSTKFLTSIG是信号名的通用前缀，STKFLT是stack fault 的缩写。 对应的数值为 16。 按照官方文档说明，该信号量意味着协处理器栈故障。 根据网上的部分问题结论说明，在内存耗尽时，一般 malloc 返回 NULL 且设置 errno 为 ENOMEM，但有些系统可能会使用 SIGSTKFLT 信号代替。 7. SIGPIPE该信号对应的数值为 13。 该信号意味着管道错误，通常在进程间通信产生，比如采用FIFO(管道)通信的两个进程，读管道没打开或者意外终止仍继续往管道写，写进程就会收到 SIGPIPE 信号。 8. SIGUSR2为 12。用户自定义信号2。 9. SIGTERMSIG是信号名的通用前缀，TERM 是 Termination 的缩写。该信号对应的数值为 15。 与 SIGKILL (signal 9) 类似，不过 SIGKILL 不可捕获，而 SIGTERM 可被捕获。一般常见于 APP 处于后台时，被系统 vold 进程使用 SIGTERM 杀死，该情形基本没有意义，可忽略。 另外，chromium 多进程架构中，经常也会使用 SIGTERM 杀死出现了异常的子进程。 10. SIGSYS该信号对应的数值为 31，通常是因为无效的 linux 内核系统调用而产生。 在 android O (android 8.0) 中，部分不安全的系统调用被移除，若代码中仍然使用它们，则会出现 SIGSYS。 11. SIGTRAP该信号对应的数值为 5。gdb 调试设置断点等操作使用的信号。 Code 说明 TRAP_BRKPT TRAP_BRKPT TRAP_TRACE TRAP_TRACE TRAP_BRANCH TRAP_BRANCH TRAP_HWBKPT TRAP_HWBKPT 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Native Crash","slug":"native-crash","permalink":"http://agehua.github.io/tags/native-crash/"}]},{"title":"Native Crash捕获原理","slug":"native-crash-principle","date":"2023-11-01T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2023/11/02/native-crash-principle/","link":"","permalink":"http://agehua.github.io/2023/11/02/native-crash-principle/","excerpt":"本文主要介绍Native Crash捕获原理","text":"本文主要介绍Native Crash捕获原理 目前流行的Native Crash捕获方案 方案 优点 缺点 Google Breakpad 官方出品，多平台支持，文档全面 代码体量大，crash信息保存在mini_dump文件中，拿到dump文件后，需要再次解析才能获取crash堆栈 利用Logcat日志 利用Android系统实现 需要再Crash时启动新进程过滤logcat日志，不可靠 unwind库 实现简单，改动容易。很多三方库也是基于该方案 需要了解信号机制，自行实现获取Crash堆栈方式 本次实践采用方案三（unwind） 使用 信号量+&lt;unwind.h&gt;库。 崩溃信息写入文件，通过 log 上传到日志平台（Elastic） 下次启动后读取文件内容上报，然后删除文件 对java层的崩溃捕获不会有任何影响，Native层Crash bugly不再能够捕获异常 实现方案细节要实现 Native Crash 的收集，主要有四个重点： 知道 Crash 的发生； 捕获到 Crash 的位置； 获取 Crash 发生位置的函数调用栈； 数据能回传到服务器。 一、知道 Crash 的发生与 Java 平台不同，C/C++ 没有一个通用的异常处理接口，在 C 层，CPU 通过异常中断的方式，触发异常处理流程。不同的处理器，有不同的异常中断类型和中断处理方式，linux 把这些中断处理，统一为信号量，每一种异常都有一个对应的信号，可以注册回调函数进行处理需要关注的信号量。 信号量定义在 signal.h 中，常见的信号量有：#define SIGHUP 1 // 终端连接结束时发出(不管正常或非正常)#define SIGINT 2 // 程序终止(例如Ctrl-C)#define SIGQUIT 3 // 程序退出(Ctrl-\\)#define SIGILL 4 // 执行了非法指令，或者试图执行数据段，堆栈溢出#define SIGTRAP 5 // 断点时产生，由debugger使用#define SIGABRT 6 // 调用abort函数生成的信号，表示程序异常#define SIGIOT 6 // 同上，更全，IO异常也会发出#define SIGBUS 7 // 非法地址，包括内存地址对齐出错，比如访问一个4字节的整数, 但其地址不是4的倍数#define SIGFPE 8 // 计算错误，比如除0、溢出#define SIGKILL 9 // 强制结束程序，具有最高优先级，本信号不能被阻塞、处理和忽略#define SIGUSR1 10 // 未使用，保留#define SIGSEGV 11 // 非法内存操作，与SIGBUS不同，他是对合法地址的非法访问，比如访问没有读权限的内存，向没有写权限的地址写数据#define SIGUSR2 12 // 未使用，保留#define SIGPIPE 13 // 管道破裂，通常在进程间通信产生#define SIGALRM 14 // 定时信号,#define SIGTERM 15 // 结束程序，类似温和的SIGKILL，可被阻塞和处理。通常程序如果终止不了，才会尝试SIGKILL#define SIGSTKFLT 16 // 协处理器堆栈错误#define SIGCHLD 17 // 子进程结束时, 父进程会收到这个信号。#define SIGCONT 18 // 让一个停止的进程继续执行#define SIGSTOP 19 // 停止进程,本信号不能被阻塞,处理或忽略#define SIGTSTP 20 // 停止进程,但该信号可以被处理和忽略#define SIGTTIN 21 // 当后台作业要从用户终端读数据时, 该作业中的所有进程会收到SIGTTIN信号#define SIGTTOU 22 // 类似于SIGTTIN, 但在写终端时收到#define SIGURG 23 // 有紧急数据或out-of-band数据到达socket时产生#define SIGXCPU 24 // 超过CPU时间资源限制时发出#define SIGXFSZ 25 // 当进程企图扩大文件以至于超过文件大小资源限制#define SIGVTALRM 26 // 虚拟时钟信号. 类似于SIGALRM, 但是计算的是该进程占用的CPU时间.#define SIGPROF 27 // 类似于SIGALRM/SIGVTALRM, 但包括该进程用的CPU时间以及系统调用的时间#define SIGWINCH 28 // 窗口大小改变时发出#define SIGIO 29 // 文件描述符准备就绪, 可以开始进行输入/输出操作#define SIGPOLL SIGIO // 同上，别称#define SIGPWR 30 // 电源异常#define SIGSYS 31 // 非法的系统调用 注册信号处理函数，也是在 signal.h 中：int sigaction(int __signal, const struct sigaction* __new_action, struct sigaction* __old_action); 第一个参数 int 类型，表示需要关注的信号量 第二个参数 sigaction 结构体指针，用于声明当某个特定信号发生的时候，应该如何处理 第三个参数也是 sigaction 结构体指针，他表示的是默认处理方式，当我们自定义了新的信号量处理的时候，用他来存储之前默认的处理方式。这也是指针与引用的区别，指针操作操作的都是变量本身，所以给新指针赋值了以后，需要另一个指针来记录封装了默认处理方式的变量在内存中的位置。 sigaction 内容结构体如下：struct sigaction &#123; union &#123; sighandler_t sa_handler; void (*sa_sigaction)(int, struct siginfo*, void*); &#125;; sigset_t sa_mask; int sa_flags; void (*sa_restorer)(void);&#125;; sa_sigaction就是信号处理函数的指针，这个指针指向的是一个拥有三个参数的函数，结构体中定义的函数指针为： void (*sa_sigaction)(int, struct siginfo_t *,void *) 1.第一个参数为信号值 2.第二个参数为信号的一些具体信息 3.第三个参数为一些上下文信息, 包括崩溃时的 pc 值 siginfo_t 结构体siginfo_t &#123; int si_signo; /* 信号数值 */ int si_errno; /* 错误值 */ int si_code; /* 信号代码 */ int si_trapno; /*导致硬件生成信号的陷阱号，在大多数体系结构中未使用*/ pid_t si_pid; /* 发送信号的进程ID */ uid_t si_uid; /*发送信号的真实用户ID */ int si_status; /* 退出值或信号状态*/ clock_t si_utime; /*消耗的用户时间*/ clock_t si_stime; /*消耗的系统时间*/ sigval_t si_value; /*信号值*/ int si_int; /* POSIX.1b 信号*/ void *si_ptr; int si_overrun; /*计时器溢出计数*/ int si_timerid; /* 计时器ID */ void *si_addr; /*导致故障的内存位置 */ long si_band; int si_fd; /* 文件描述符*/ short si_addr_lsb; /*地址的最低有效位 (从Linux 2.6.32开始存在) */ void *si_lower; /*地址冲突时的下限*/ void *si_upper; /*地址冲突时的上限 (从Linux 3.19开始存在) */ int si_pkey; /*导致的PTE上的保护密钥*/ void *si_call_addr; /*系统调用指令的地址*/ int si_syscall; /*尝试的系统调用次数*/ unsigned int si_arch; /* 尝试的系统调用的体系结构*/ &#125; 结构体内包含了我们常见的si_signo、si_code、si_errno等。类似：Native Crash, signal: 11, tname: conorlee.test, pid: 13283, tid: 13283, code: 1, error: 0 所以，要订阅异常发生的信号，最简单的做法就是直接用一个循环遍历所有要订阅的信号，对每个信号调用sigaction()，如下示例： void init() &#123; struct sigaction handler; struct sigaction old_signal_handlers[SIGNALS_LEN]; for (int i = 0; i &lt; SIGNALS_LEN; ++i) &#123; sigaction(signal_array[i], &amp;handler, &amp; old_signal_handlers[i]); &#125;&#125; 二、捕获到Crash的位置然后，我们仿照上面的信号处理函数定义，可以声明一个函数，直接将函数的地址赋值给sa_sigaction // 我们声明的函数void signal_handle(int code, siginfo_t *si, void *context) &#123;&#125;void init() &#123; struct sigaction old_signal_handlers[SIGNALS_LEN]; struct sigaction handler; // 赋值给该指针 handler.sa_sigaction = signal_handle; handler.sa_flags = SA_SIGINFO; for (int i = 0; i &lt; SIGNALS_LEN; ++i) &#123; sigaction(signal_array[i], &amp;handler, &amp; old_signal_handlers[i]); &#125;&#125; 这样当发生 Crash 的时候就会回调我们传入的signal_handle()函数了。在signal_handle()函数中，通过siginfo_t 结构体，我们就能拿到当前执行的代码信息。 设置紧急栈空间如果当前函数发生了无限递归造成堆栈溢出，在统计的时候需要考虑到这种情况来新开堆栈，否则本来就满了的堆栈又在当前堆栈处理溢出信号，处理肯定是会失败的。所以我们需要设置一个用于紧急处理的新栈，可以使用 sigaltstack() 在任意线程注册一个可选的栈，保留一下在紧急情况下使用的空间。（系统会在危险情况下把栈指针指向这个地方，使得可以在一个新的栈上运行信号处理函数） void signal_handle_test(int sig) &#123; write(2, \"stack overflow\\n\", 15); _exit(1);&#125;unsigned infinite_recursion(unsigned x) &#123; return infinite_recursion(x)+1;&#125;int main() &#123; static char stack[SIGSTKSZ]; stack_t ss = &#123; .ss_size = SIGSTKSZ, .ss_sp = stack, &#125;; struct sigaction sa = &#123; .sa_handler = signal_handle_test, .sa_flags = SA_ONSTACK &#125;; sigaltstack(&amp;ss, 0); sigfillset(&amp;sa.sa_mask); sigaction(SIGSEGV, &amp;sa, 0); infinite_recursion(0);&#125; 三、捕获出问题的代码signal_handle() 函数中的第三个参数 context 是uc_mcontext的结构体指针，它封装了 cpu 相关的上下文，包括当前线程的寄存器信息和奔溃时的 pc 值，能够知道崩溃时的pc，就能知道崩溃时执行的是那条指令。 不过uc_mcontext结构体的定义是平台相关的，比如我们熟知的arm、x86这种都不是同一个结构体定义，要兼容其他架构的 cpu 在处理的时候，就得要寄出宏编译大法，不同的架构使用不同的定义，如下展示了不同架构获取pc值（绝对内存地址）的不同方式： uintptr_t pc_from_ucontext(const ucontext_t *uc) &#123;#if (defined(__arm__)) return uc-&gt;uc_mcontext.arm_pc;#elif defined(__aarch64__) return uc-&gt;uc_mcontext.pc;#elif (defined(__x86_64__)) return uc-&gt;uc_mcontext.gregs[REG_RIP];#elif (defined(__i386)) return uc-&gt;uc_mcontext.gregs[REG_EIP];#elif (defined (__ppc__)) || (defined (__powerpc__)) return uc-&gt;uc_mcontext.regs-&gt;nip;#elif (defined(__hppa__)) return uc-&gt;uc_mcontext.sc_iaoq[0] &amp; ~0x3UL;#elif (defined(__sparc__) &amp;&amp; defined (__arch64__)) return uc-&gt;uc_mcontext.mc_gregs[MC_PC];#elif (defined(__sparc__) &amp;&amp; !defined (__arch64__)) return uc-&gt;uc_mcontext.gregs[REG_PC];#else#error \"Architecture is unknown, please report me!\"#endif&#125; pc值转内存地址pc值是程序加载到内存中的绝对地址，绝对地址不能直接使用，因为每次程序运行创建的内存肯定都不是固定区域的内存，所以绝对地址肯定每次运行都不一致。我们需要拿到崩溃代码相对于当前库的相对偏移地址，这样才能使用 addr2line 分析出是哪一行代码。 通过 dladdr() 可以获得共享库加载到内存的起始地址，和pc值相减就可以获得相对偏移地址，并且可以获得共享库的名字。 Dl_info info; if (dladdr(addr, &amp;info) &amp;&amp; info.dli_fname) &#123; void * const nearest = info.dli_saddr; uintptr_t addr_relative = addr - info.dli_fbase; &#125; 获取 Crash 发生时的函数调用栈获取函数调用栈是最麻烦的，至今没有一个好用的，全都要做一些大改动。常见的做法有四种： 第一种：直接使用系统的&lt;unwind.h&gt;库，可以获取到出错文件与函数名。只不过需要自己解析函数符号，同时经常会捕获到系统错误，需要手动过滤。 第二种：在4.1.1以上，5.0以下，使用系统自带的 libcorkscrew.so，5.0开始，系统中没有了libcorkscrew.so，可以自己编译系统源码中的libunwind。libunwind是一个开源库，事实上高版本的安卓源码中就使用了他的优化版替换 libcorkscrew。 第三种：使用开源库coffeecatch，但是这种方案也不能百分之百兼容所有机型。 第四种：使用 Google 的breakpad，这是所有 C/C++堆栈获取的权威方案，基本上业界都是基于这个库来做的。只不过这个库是全平台的 android、iOS、Windows、Linux、MacOS 全都有，所以非常大，在使用的时候得把无关的平台剥离掉减小体积。 下面以第一种为例讲一下实现： 核心方法是使用&lt;unwind.h&gt;库提供的一个方法_Unwind_Backtrace()这个函数可以传入一个函数指针作为回调，指针指向的函数有一个重要的参数是_Unwind_Context类型的结构体指针。可以使用_Unwind_GetIP()函数将当前函数调用栈中每个函数的绝对内存地址（也就是上文中提到的 pc 值），写入到_Unwind_Context结构体中，最终返回的是当前调用栈的全部函数地址了，_Unwind_Word实际上就是一个unsigned int。而capture_backtrace()返回的就是当前我们获取到调用栈中内容的数量。 /** * callback used when using &lt;unwind.h&gt; to get the trace for the current context */_Unwind_Reason_Code unwind_callback(struct _Unwind_Context *context, void *arg) &#123; backtrace_state_t *state = (backtrace_state_t *) arg; _Unwind_Word pc = _Unwind_GetIP(context); if (pc) &#123; if (state-&gt;current == state-&gt;end) &#123; return _URC_END_OF_STACK; &#125; else &#123; *state-&gt;current++ = (void *) pc; &#125; &#125; return _URC_NO_REASON;&#125;/** * uses built in &lt;unwind.h&gt; to get the trace for the current context */size_t capture_backtrace(void **buffer, size_t max) &#123; backtrace_state_t state = &#123;buffer, buffer + max&#125;; _Unwind_Backtrace(unwind_callback, &amp;state); return state.current - buffer;&#125; 当所有的函数的绝对内存地址(pc 值)都获取到了，就可以用上文讲的办法将 pc 值转换为相对偏移量，获取到真正的函数信息和相对内存地址了。void *buffer[max_line];int frames_size = capture_backtrace(buffer, max_line);for (int i = 0; i &lt; frames_size; i++) &#123; Dl_info info; const void *addr = buffer[i]; if (dladdr(addr, &amp;info) &amp;&amp; info.dli_fname) &#123; void * const nearest = info.dli_saddr; uintptr_t addr_relative = addr - info.dli_fbase; &#125; Dl_info是一个结构体，内部封装了函数所在文件、函数名、当前库的基地址等信息 具体结构体如下：typedef struct &#123; /* Pathname of shared object that contains address. */ const char* dli_fname; /* Address at which shared object is loaded. */ void* dli_fbase; /* Name of nearest symbol with address lower than addr. */ const char* dli_sname; /* Exact address of symbol named in dli_sname. */ void* dli_saddr;&#125; Dl_info; 有了这个对象，我们就能获取到全部想要的信息了。虽然获取到全部想要的信息，但&lt;unwind.h&gt;有个麻烦的就是不想要的信息也给你了，所以需要手动过滤掉各种系统错误，最终得到的数据，就可以上报到自己的服务器了。 如何分析上面抓到各种信息，可以看我的下一篇文章：《Native Crash日志分析》 四、数据传回到服务器数据回传有两种方式，一种是直接将信息写入文件，下次启动的时候直接由 Java 上报；另一种就是回调 Java 代码，让 Java 去处理。用 Java 处理的好处是 Java 层可以继续在当前上下文上加上 Java 层的各种状态信息，写入到同一个文件中，使得开发在解决 bug 的时候能更方便。 目前遗留的问题 64位so在部分设备（比如我自己的 IQOO）上无法获取到崩溃堆栈，只能捕获到信号，但是32位的so没有这个问题 数据可以上传到java层，但是日志上报是在java层的子线程，native无法等待子线程执行完成 堆栈信息在java层上传的时候未格式化 部分backtrace没有关键信息，比如一些SIGSEGV RefAndroid Native Crash 收集 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/11/02/native-crash-principle/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Native Crash","slug":"native-crash","permalink":"http://agehua.github.io/tags/native-crash/"}]},{"title":"跨进程通信Bridge建立","slug":"cross-process-bridge","date":"2023-10-25T16:00:00.000Z","updated":"2024-12-05T09:41:25.330Z","comments":true,"path":"2023/10/26/cross-process-bridge/","link":"","permalink":"http://agehua.github.io/2023/10/26/cross-process-bridge/","excerpt":"本文介绍了Android跨进程通信的原理，并对Hermes的源码进行分析。\n先简单总结下：Hermes也是通过AIDL的方式来最终实现跨进程通信，通信的内容是Gson。其中用到的了动态代理技术。后面再详细分析下为什么要用到动态代理","text":"本文介绍了Android跨进程通信的原理，并对Hermes的源码进行分析。 先简单总结下：Hermes也是通过AIDL的方式来最终实现跨进程通信，通信的内容是Gson。其中用到的了动态代理技术。后面再详细分析下为什么要用到动态代理 手动创建IInterface类如何创建AIDL文件本文就不在讲了，感兴趣的可以看我之前的文章：Android Binder 机制分析（一） 代理什么是代理代理就是客户类不再直接和委托类打交道, 而是通过一个中间层来访问, 这个中间层就是代理。为啥要这样呢, 是因为使用代理有两个优势： 1.可以隐藏委托类的实现 2.可以实现客户与委托类之间的解耦, 在不修改委托类代码的情况下能够做一些额外的处理 静态代理接口：public interface HelloService &#123; String sayHello(String content);&#125; 接口实现类 public class HelloServiceImpl implements HelloService &#123; @Override public String sayHello(String content) &#123; return \"hello \" + content; &#125;&#125; 代理类 public class HelloServiceProxy implements HelloService &#123; private HelloService helloService; public HelloServiceProxy(HelloService helloService) &#123; this.helloService = helloService; &#125; @Override public String sayHello(String content) &#123; System.out.println(\"before invoke\"); String result = helloService.sayHello(content); System.out.println(\"after invoke\"); return result; &#125;&#125; 这里的代理类其实也满足了一个面向对象的设计原则，即组合优先于集成。 动态代理Java动态代理是一种在运行时创建代理类的方法。它可以在不修改源代码的情况下，在程序运行期间为接口创建代理类。它基于 Java 反射机制实现。 动态代理是一种很有用的工具，可以帮助您在不更改目标对象代码的情况下对其进行包装。 动态代理是为接口创建代理类，所以要提前定义一个接口：public interface HelloService &#123; String sayHello(String content);&#125; HelloServiceImpl实现类public class HelloServiceImpl implements HelloService &#123; @Override public String sayHello(String content) &#123; return \"hello \" + content; &#125;&#125; 使用InvocationHandler，实现动态代理public class MyInvocationHandler implements InvocationHandler &#123; // 真实对象 private Object obj; public MyInvocationHandler(Object obj) &#123; this.obj = obj; &#125; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable &#123; System.out.println(\"before invoke......\"); // 此处通过反射，调用真实对象的相关方法 Object result = method.invoke(obj, args); System.out.println(\"after invoke......\"); return result; &#125;&#125; 如何使用：public class DynamicProxyTest &#123; public static void main(String[] args) &#123; String content = \"dynamic proxy\"; // 创建真实实现对象 HelloService helloService = new HelloServiceImpl(); // 创建调用器 InvocationHandler handler = new MyInvocationHandler(helloService); // 创建代理实例 Object proxy = Proxy.newProxyInstance(helloService.getClass().getClassLoader(), helloService.getClass() .getInterfaces(), handler); System.out.println(\"代理类名称:\" + proxy.getClass().getName()); System.out.println(\"代理类接口:\" + proxy.getClass().getInterfaces()[0].getName()); // 类型转换 HelloService proxyService = (HelloService) proxy; // 执行代理逻辑 System.out.println(proxyService.sayHello(content)); &#125;&#125; 输出：代理类名称:com.sun.proxy.$Proxy0代理类接口:com.sankuai.meituan.zcm.depot.proxy.HelloServicebefore invoke......after invoke......hello dynamic proxy 动态代理分析public final class $Proxy0 extends Proxy implements HelloService &#123; private static Method m1; private static Method m3; private static Method m2; private static Method m0; public $Proxy0(InvocationHandler var1) throws &#123; super(var1); &#125; public final boolean equals(Object var1) throws &#123; try &#123; return (Boolean)super.h.invoke(this, m1, new Object[]&#123;var1&#125;); &#125; catch (RuntimeException | Error var3) &#123; throw var3; &#125; catch (Throwable var4) &#123; throw new UndeclaredThrowableException(var4); &#125; &#125; // 对外的代理方法，下面的h是上面传入的handler public final String sayHello(String var1) throws &#123; try &#123; return (String)super.h.invoke(this, m3, new Object[]&#123;var1&#125;); &#125; catch (RuntimeException | Error var3) &#123; throw var3; &#125; catch (Throwable var4) &#123; throw new UndeclaredThrowableException(var4); &#125; &#125; public final String toString() throws &#123; try &#123; return (String)super.h.invoke(this, m2, (Object[])null); &#125; catch (RuntimeException | Error var2) &#123; throw var2; &#125; catch (Throwable var3) &#123; throw new UndeclaredThrowableException(var3); &#125; &#125; public final int hashCode() throws &#123; try &#123; return (Integer)super.h.invoke(this, m0, (Object[])null); &#125; catch (RuntimeException | Error var2) &#123; throw var2; &#125; catch (Throwable var3) &#123; throw new UndeclaredThrowableException(var3); &#125; &#125; static &#123; try &#123; m1 = Class.forName(\"java.lang.Object\").getMethod(\"equals\", Class.forName(\"java.lang.Object\")); m3 = Class.forName(\"com.sankuai.meituan.zcm.depot.proxy.HelloService\").getMethod(\"sayHello\", Class.forName(\"java.lang.String\")); m2 = Class.forName(\"java.lang.Object\").getMethod(\"toString\"); m0 = Class.forName(\"java.lang.Object\").getMethod(\"hashCode\"); &#125; catch (NoSuchMethodException var2) &#123; throw new NoSuchMethodError(var2.getMessage()); &#125; catch (ClassNotFoundException var3) &#123; throw new NoClassDefFoundError(var3.getMessage()); &#125; &#125;&#125; 怎么拿到动态生成的代理classimport sun.misc.ProxyGenerator;import java.io.FileOutputStream;import java.io.IOException;public class ProxyUtils &#123; /** * 将根据类信息动态生成的二进制字节码保存到硬盘中，默认的是clazz目录下 * params: clazz 需要生成动态代理类的类 * proxyName: 为动态生成的代理类的名称 */ public static void generateClassFile(Class clazz, String proxyName) &#123; // 根据类信息和提供的代理类名称，生成字节码 byte[] classFile = ProxyGenerator.generateProxyClass(proxyName, clazz.getInterfaces()); String paths = clazz.getResource(\".\").getPath(); System.out.println(paths); FileOutputStream out = null; try &#123; //保留到硬盘中 out = new FileOutputStream(paths + proxyName + \".class\"); out.write(classFile); out.flush(); &#125; catch (Exception e) &#123; e.printStackTrace(); &#125; finally &#123; try &#123; out.close(); &#125; catch (IOException e) &#123; e.printStackTrace(); &#125; &#125; &#125;&#125; 然后运行下面的代码就可以：// 保存JDK动态代理生成的代理类，类名保存为 UserServiceProxyProxyUtils.generateClassFile(userServiceImpl.getClass(), \"UserServiceProxy\"); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/10/26/cross-process-bridge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"multi-process","slug":"multi-process","permalink":"http://agehua.github.io/tags/multi-process/"}]},{"title":"Matrix TraceCanary源码分析","slug":"matrix-trace-canary","date":"2023-09-25T16:00:00.000Z","updated":"2024-12-05T09:41:25.309Z","comments":true,"path":"2023/09/26/matrix-trace-canary/","link":"","permalink":"http://agehua.github.io/2023/09/26/matrix-trace-canary/","excerpt":"本文主要介绍Matrix的Trace部分，主要涉及帧率、ANR、慢函数、启动耗时的检测逻辑。","text":"本文主要介绍Matrix的Trace部分，主要涉及帧率、ANR、慢函数、启动耗时的检测逻辑。 Trace Canary主要特性 编译期动态修改字节码, 高性能记录执行耗时与调用堆栈 准确的定位到发生卡顿的函数，提供执行堆栈、执行耗时、执行次数等信息，帮助快速解决卡顿问题 自动涵盖卡顿、启动耗时、页面切换、慢函数检测等多个流畅性指标 Tracer模块主要结构： 其中： FrameTracer负责帧率检测 AnrTracer负责ANR问题检测 EvilMethodTracer负责检测慢函数 StartupTracer负责应用启动耗时检测 帧率检测FrameTracer部分主要做帧率、掉帧、帧耗时等检测，具体实现逻辑在FrameTracer和UIThreadMonitor。 Demo中的入口在TestFpsActivity，onCreate()中通过FrameTracer.onStartTrace()开启检测，页面退出时通过FrameTracer.onCloseTrace()结束检测，并移除监控回调。 从使用侧开始，看看帧率的计算逻辑。 TestFpsActivity：sample.tencent.matrix.trace.TestFpsActivityprotected void onCreate(@Nullable Bundle savedInstanceState) &#123; // 启动帧率检测，使用FrameTrace计算FPS Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().onStartTrace(); // 添加帧率回调 Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().addListener(mDoFrameListener);&#125;protected void onDestroy() &#123; super.onDestroy(); // 移除帧率回调 Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().removeListener(mDoFrameListener); // 关闭帧率检测 Matrix.with().getPluginByClass(TracePlugin.class).getFrameTracer().onCloseTrace();&#125; 看下TestFpsActivity的FPS监控回调部分：sample.tencent.matrix.trace.TestFpsActivity// 异步线程private static HandlerThread sHandlerThread = new HandlerThread(\"test\");// 帧率检测回调private IDoFrameListener mDoFrameListener = new IDoFrameListener(new Executor() &#123; Handler handler = new Handler(sHandlerThread.getLooper()); @Override public void execute(Runnable command) &#123; //将回调方法放到异步线程执行 handler.post(command); &#125; &#125;) &#123; @Override public void doFrameAsync(String visibleScene, long taskCost, long frameCostMs, int droppedFrames, boolean isContainsFrame) &#123; super.doFrameAsync(visibleScene, taskCost, frameCostMs, droppedFrames, isContainsFrame); // 计算总的掉帧数 count += droppedFrames; &#125; &#125;; 回调接口IDoFrameListener支持将同步和异步回调方法：doFrameSync()和doFrameAsync，需要使用侧传入一个Executor。 解释下IDoFrameListener.doFrameAsync()的参数含义： visibleScene：场景名称，默认是Activity的类名 taskCost：主线程每一帧耗时 frameCostMs：帧率检测时用不到 droppedFrames：掉帧数 isContainsFrame：是否包含一帧 这里提一下visibleScene的获取逻辑：Matrix初始化时，AppActiveMatrixDelegate.controller()内部通过Application. registerActivityLifecycleCallbacks()监听Activity生命周期。当Activity start时，将activity.getClass().getName()做为visibleScene。FrameTracer再通过AppMethodBeat.getVisibleScene()获取visibleScene。 继续看下回调方法doFrameAsync()的上游逻辑。FrameTracer.notifyListener()：IDoFrameListener.doFrameAsync()是在FrameTracer.notifyListener()中调用的：com.tencent.matrix.trace.tracer.FrameTracer private void notifyListener(final String visibleScene, final long taskCostMs, final long frameCostMs, final boolean isContainsFrame) &#123; long start = System.currentTimeMillis(); try &#123; synchronized (listeners) &#123; for (final IDoFrameListener listener : listeners) &#123; if (config.isDevEnv()) &#123; listener.time = SystemClock.uptimeMillis(); &#125; // 计算掉帧数 final int dropFrame = (int) (taskCostMs / frameIntervalMs); listener.doFrameSync(visibleScene, taskCostMs, frameCostMs, dropFrame, isContainsFrame); if (null != listener.getExecutor()) &#123; //通过TestFpsActivity传入的Executor，将回调放到异步 listener.getExecutor().execute(new Runnable() &#123; @Override public void run() &#123; // 回调给TestFpsActivity listener.doFrameAsync(visibleScene, taskCostMs, frameCostMs, dropFrame, isContainsFrame); &#125; &#125;); &#125; &#125; &#125; &#125; finally &#123; long cost = System.currentTimeMillis() - start; // debug模式下，回调doFrameAsync中执行超过17ms，log警告 if (config.isDebug() &amp;&amp; cost &gt; frameIntervalMs) &#123; MatrixLog.w(TAG, \"[notifyListener] warm! maybe do heavy work in doFrameSync! size:%s cost:%sms\", listeners.size(), cost); &#125; &#125; &#125; 从上面代码可以看出掉帧数dropFrame就是taskCostMs/frameIntervalMs。 taskCostMs：一帧的执行耗时 frameIntervalMs：默认是17ms，计算逻辑是Choreographer.mFrameIntervalNanos+1。其中，Choreographer.mFrameIntervalNanos是屏幕刷新时间间隔，默认16ms。计算代码如下：com.tencent.matrix.trace.tracer.FrameTracerthis.frameIntervalMs = TimeUnit.MILLISECONDS.convert(UIThreadMonitor.getMonitor().getFrameIntervalNanos(), TimeUnit.NANOSECONDS) + 1;com.tencent.matrix.trace.core.UIThreadMonitorchoreographer = Choreographer.getInstance();// 通过反射获取Choreographer的mFrameIntervalNanos字段，默认是16msframeIntervalNanos = reflectObject(choreographer, \"mFrameIntervalNanos\"); 上面计算掉帧的方式：taskCostMs/17，其实并不是非常严谨，比如taskCostMs=33时，应该丢了两帧，但是计算结果是1。 上面提到的FrameTracer.notifyListener()由FrameTracer.doFrame()触发，看下FrameTracer.doFrame()： FrameTracer.doFrame():com.tencent.matrix.trace.tracer.FrameTracer@Override public void doFrame(String focusedActivityName, long start, long end, long frameCostMs, long inputCostNs, long animationCostNs, long traversalCostNs) &#123; if (isForeground()) &#123; // IDoFrameListener.doFrameAsync()中的参数taskCostMs即为end - start。 notifyListener(focusedActivityName, end - start, frameCostMs, frameCostMs &gt;= 0); &#125; &#125; 这个方法没有做太多事情，主要是计算掉帧数用的taskCostMs是end - start的结果。 FrameTracer.doFrame()由UIThreadMonitor.dispatchEnd()触发，看下后者的实现。 UIThreadMonitor.dispatchEnd()com.tencent.matrix.trace.core.UIThreadMonitor private void dispatchEnd() &#123; if (isBelongFrame) &#123; doFrameEnd(token); &#125; // 对应每一帧的开始时间，在dispatchBegin()中赋值 long start = token; // 对应每一帧的结束时间 long end = SystemClock.uptimeMillis(); synchronized (observers) &#123; for (LooperObserver observer : observers) &#123; if (observer.isDispatchBegin()) &#123; // isBelongFrame ? end - start : 0 - frameCost, 如果是帧耗时计算，则frameCost为0，否则和taskCost一样 // queueCost数组，存储对应Choreographer中三类task(input/animation/traversal)的耗时 observer.doFrame(AppMethodBeat.getVisibleScene(), token, SystemClock.uptimeMillis(), isBelongFrame ? end - start : 0, queueCost[CALLBACK_INPUT], queueCost[CALLBACK_ANIMATION], queueCost[CALLBACK_TRAVERSAL]); &#125; &#125; &#125; // 计算结束时间 dispatchTimeMs[3] = SystemClock.currentThreadTimeMillis(); dispatchTimeMs[1] = SystemClock.uptimeMillis(); AppMethodBeat.o(AppMethodBeat.METHOD_ID_DISPATCH); synchronized (observers) &#123; for (LooperObserver observer : observers) &#123; if (observer.isDispatchBegin()) &#123; observer.dispatchEnd(dispatchTimeMs[0], dispatchTimeMs[2], dispatchTimeMs[1], dispatchTimeMs[3], token, isBelongFrame); &#125; &#125; &#125; &#125; 这部分内容主要做了这几件事情： 获取每一帧耗时的开始、结束时间戳，即start、end，将差值通过observer.doFrame()传给消费方执行observer.doFrame()，该方法主要消费方是AnrTracer、EvilMethodTracer、FrameTracer赋值dispatchTimeMs[1]，dispatchTimeMs[3]，其中dispatchTimeMs数组含义后面会提到执行observer.dispatchEnd()，该方法主要消费方是AnrTracer、EvilMethodTracer看完了UIThreadMonitor.dispatchEnd()，再看下UIThreadMonitor.dispatchBegin()： com.tencent.matrix.trace.core.UIThreadMonitorprivate void dispatchBegin() &#123; // 对dispatchTimeMs[0]、dispatchTimeMs[2]赋值 token = dispatchTimeMs[0] = SystemClock.uptimeMillis(); dispatchTimeMs[2] = SystemClock.currentThreadTimeMillis(); AppMethodBeat.i(AppMethodBeat.METHOD_ID_DISPATCH); //每一帧开始执行时的回调 synchronized (observers) &#123; for (LooperObserver observer : observers) &#123; if (!observer.isDispatchBegin()) &#123; observer.dispatchBegin(dispatchTimeMs[0], dispatchTimeMs[2], token); &#125; &#125; &#125; &#125; 这里简单说下SystemClock.uptimeMillis()和SystemClock.currentThreadTimeMillis()的区别，详细内容可以看官方文档： SystemClock.uptimeMillis()：记录从开机到现在的时长，系统深睡眠（CPU睡眠、黑屏、系统等待外部输入对其唤醒）的时间不算在内，且不受系统设置时间调整的影响。是大多数时间间隔计算方法的基础，比如Thread.sleep(long)、Object.wait(long)、System.nanoTime() SystemClock.currentThreadTimeMillis()：这个比较容易理解，当前线程的活动时长（线程处于running状态） LooperObserver.dispatchEnd()解释下LooperObserver.dispatchEnd()的参数含义，后续对理解AnrTracer、EvilMethodTracer的实现有帮助：com.tencent.matrix.trace.listeners.LooperObserverpublic void dispatchEnd(long beginMs, long cpuBeginMs, long endMs, long cpuEndMs, long token, boolean isBelongFrame) beginMs：主线程一帧任务的开始时间点，对应dispatchTimeMs[0]，在UIThreadMonitor.dispatchBegin()中赋值 cpuBeginMs：当前线程活动期间，方法开始执行时间点，对应dispatchTimeMs[2] endMs：主线程一帧方法结束执行时间点，对应dispatchTimeMs[1]，在UIThreadMonitor.dispatchEnd()中赋值。所以，一帧耗时就是endMs-beginMs。 cpuEndMs：当前线程活动期间，方法解释执行时间点，对应dispatchTimeMs[3] token：等同于beginMs isBelongFrame：可简单理解为是否属于主线程任务。在Choreographer处理input任务时执行UIThreadMonitor.run()，内部将- - isBelongFrame置为true，这块逻辑可以看下UIThreadMonitor.onStart() 上面提到，一帧任务执行结束时会执行UIThreadMonitor.dispatchEnd()，该方法在LooperMonitor注册的监听器中执行的。看下这块逻辑： com.tencent.matrix.trace.core.UIThreadMonitorLooperMonitor.register(new LooperMonitor.LooperDispatchListener() &#123; @Override public boolean isValid() &#123; return isAlive; &#125; @Override public void dispatchStart() &#123; super.dispatchStart(); UIThreadMonitor.this.dispatchBegin(); &#125; @Override public void dispatchEnd() &#123; super.dispatchEnd(); UIThreadMonitor.this.dispatchEnd(); &#125; &#125;); UIThreadMonitor向LooperMonitor注册了监听器，用于监听每一帧的开始和结束。 其中，LooperDispatchListener的dispatchStart()和dispatchEnd()都是LooperMonitor.dispatch()执行的。由isBegin决定执行dispatchStart()还是dispatchEnd()。看下LooperMonitor.dispatch()：LooperMonitor.dispatch():com.tencent.matrix.trace.core.LooperMonitorprivate void dispatch(boolean isBegin, String log) &#123; for (LooperDispatchListener listener : listeners) &#123; if (listener.isValid()) &#123; if (isBegin) &#123; if (!listener.isHasDispatchStart) &#123; // 内部回调dispatchStart() listener.onDispatchStart(log); &#125; &#125; else &#123; if (listener.isHasDispatchStart) &#123; // 内部回调dispatchEnd() listener.onDispatchEnd(log); &#125; &#125; &#125; else if (!isBegin &amp;&amp; listener.isHasDispatchStart) &#123; listener.dispatchEnd(); &#125; &#125; &#125; isBegin的逻辑看下面代码：LooperMonitor.LooperPrinter:com.tencent.matrix.trace.core.LooperMonitorclass LooperPrinter implements Printer &#123; @Override public void println(String x) &#123; ... if (!isHasChecked) &#123; // 根据参数x内容，判断是开始还是结束，即isBegin isValid = x.charAt(0) == '&gt;' || x.charAt(0) == '&lt;'; isHasChecked = true; if (!isValid) &#123; MatrixLog.e(TAG, \"[println] Printer is inValid! x:%s\", x); &#125; &#125; if (isValid) &#123; // x.charAt(0) == '&gt;'时，isBegin为true dispatch(x.charAt(0) == '&gt;', x); &#125; &#125; &#125; 即，入参字符串x以&gt;开头时，isBegin为true。 上面逻辑是自定义LooperPrinter的实现方法。在LooperMonitor初始化时，会向main looper注册一个LooperPrinter：com.tencent.matrix.trace.core.LooperMonitorpublic class LooperMonitor &#123; private LooperPrinter printer; //主线程looper looper = Looper.getMainLooper() // 将前面提到的自定义LooperPrinter塞给主线程looper looper.setMessageLogging(printer = new LooperPrinter(originPrinter));&#125; 上面代码主要是把自定义LooperPrinter塞给主线程looper。对Looper比较熟悉的同学其实已经有眉目了，我们回顾下looper的逻辑：Looper.loop()android.os.Looper.javapublic static void loop() &#123; final Looper me = myLooper(); if (me == null) &#123; throw new RuntimeException(\"No Looper; Looper.prepare() wasn't called on this thread.\"); &#125; final MessageQueue queue = me.mQueue; ... for (;;) &#123; Message msg = queue.next(); // might block if (msg == null) &#123; // No message indicates that the message queue is quitting. return; &#125; // This must be in a local variable, in case a UI event sets the logger // logging对象外部自定义，传入一个自定义Printer实现每一帧的监听计算 final Printer logging = me.mLogging; if (logging != null) &#123; // 每一帧开始时打印的log logging.println(\"&gt;&gt;&gt;&gt;&gt; Dispatching to \" + msg.target + \" \" + msg.callback + \": \" + msg.what); &#125; ... try &#123; // 消息执行 msg.target.dispatchMessage(msg); dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0; &#125; finally &#123; if (traceTag != 0) &#123; Trace.traceEnd(traceTag); &#125; &#125; ... if (logging != null) &#123; // 每一帧结束时打印的log logging.println(\"&lt;&lt;&lt;&lt;&lt; Finished to \" + msg.target + \" \" + msg.callback); &#125; ... &#125; &#125; 很多APM计算帧率都采用了这个逻辑，我在Android图形渲染之Choreographer原理 最后也提到使用“Looper &amp; Printer”计算帧率。 Looper在每个消息消费前后msg.target.dispatchMessage(msg)，会通过一个Printer对象分别打印&gt;&gt;&gt;&gt;&gt; Dispatching to和&lt;&lt;&lt;&lt;&lt; Finished to两个日志。通过Looper.setMessageLogging()可以设置我们自定义的Printer，通过监听主线程方法执行前后的两个日志字符串，就可以计算一帧的耗时。 前面LooperMonitor中就通过Looper.setMessageLogging()将自定义的Printer传给了Looper，所以可以拦截每个消息执行前后的日志。 到这里，每一帧的监听、掉帧逻辑及帧率计算方式就讲完了。 总结：回顾下整体代码的执行过程： Looper.loop() //主线程消息执行也是looper机制 LooperMonitor.LooperPrinter.println() //消息执行前后会打印两个日志 LooperMonitor.dispatch() //拦截到两个日志后进行分发 UIThreadMonitor.dispatchBegin()/dispatchEnd() //记录相关时间节点，分发每一帧执行前后的回调方法 FrameTracer.doFrame() FrameTracer.notifyListener() TestFpsActivity.IDoFrameListener.doFrameSync()/doFrameAsync() //业务侧获取帧率回调总体来说，帧率检测使用了“Looper &amp; Printer”方式。Printer的日志字符串对应主线程每一帧方法执行的开始和结束，通过给主线程Looper设置自定义Printer，即可拦截日志。根据日志内容即可得知每一帧执行的前后节点，进而记录每一帧的开始、结束时间戳，从而可以计算每一帧的耗时、帧率、掉帧等核心指标。 ANR检测ANR检测的主要实现在AnrTracer。 demo中，将TestTraceMainActivity.testANR()内部执行耗时改大一点（大于5000ms），比如改到7800，就能看到AS中输出如下ANR警告log： 看下AnrTracer如何统计ANR，收集上述log信息：AnrTracer：com.tencent.matrix.trace.tracer.AnrTracer@Override public void dispatchBegin(long beginMs, long cpuBeginMs, long token) &#123; super.dispatchBegin(beginMs, cpuBeginMs, token); // 构造AnrTask anrTask = new AnrHandleTask(AppMethodBeat.getInstance().maskIndex(\"AnrTracer#dispatchBegin\"), token); // 延迟5s发消息，Constants.DEFAULT_ANR = 5 * 1000 // token是方法开始执行的时间 // (SystemClock.uptimeMillis() - token)：校正方法的开始时间 anrHandler.postDelayed(anrTask, Constants.DEFAULT_ANR - (SystemClock.uptimeMillis() - token)); &#125; @Override public void dispatchEnd(long beginMs, long cpuBeginMs, long endMs, long cpuEndMs, long token, boolean isBelongFrame) &#123; super.dispatchEnd(beginMs, cpuBeginMs, endMs, cpuEndMs, token, isBelongFrame); // 移除anrTask if (null != anrTask) &#123; anrTask.getBeginRecord().release(); anrHandler.removeCallbacks(anrTask); &#125; &#125; 前面讲FrameTracer时提到过，每一帧执行前后分别回调Tracer.dispatchBegin()和Tracer.dispatchEnd()。 上面代码在dispatchBegin()内部发送了一个延迟消息执行AnrTask，延迟时间约为5s（Constants.DEFAULT_ANR = 5 * 1000），在dispatchEnd()移除对应的任务。所以，如果主线程一帧执行任务超过5s，AnrTask就会执行。 要注意的一点是，ANR log中，may be happen ANR(5007ms)!，这里的5007ms时间并不是一帧任务的耗时（因为我们把测试方法耗时改成了7800ms），而是AnrTracer中AnrTask的消息延迟时间。 AnrTask：看下AnrTask的逻辑：com.tencent.matrix.trace.tracer.AnrTracer.AnrHandleTask@Overridepublic void run() &#123; long curTime = SystemClock.uptimeMillis(); boolean isForeground = isForeground(); // process 进程信息 int[] processStat = Utils.getProcessPriority(Process.myPid()); long[] data = AppMethodBeat.getInstance().copyData(beginRecord); beginRecord.release(); // 业务场景，FrameTracer中提到过 String scene = AppMethodBeat.getVisibleScene(); // memory 内存信息，其中VmSize从“/proc/&#123;PID&#125;/status”文件中获取 long[] memoryInfo = dumpMemory(); // Thread state Thread.State status = Looper.getMainLooper().getThread().getState(); // 线程调用堆栈 StackTraceElement[] stackTrace = Looper.getMainLooper().getThread().getStackTrace(); // 堆栈裁剪 String dumpStack = Utils.getStack(stackTrace, \"|*\\t\\t\", 12); // frame UIThreadMonitor monitor = UIThreadMonitor.getMonitor(); // 获取input/animation/traversal三类任务耗时 long inputCost = monitor.getQueueCost(UIThreadMonitor.CALLBACK_INPUT, token); long animationCost = monitor.getQueueCost(UIThreadMonitor.CALLBACK_ANIMATION, token); long traversalCost = monitor.getQueueCost(UIThreadMonitor.CALLBACK_TRAVERSAL, token); // trace ... StringBuilder reportBuilder = new StringBuilder(); StringBuilder logcatBuilder = new StringBuilder(); // 获取ANR时长 long stackCost = Math.max(Constants.DEFAULT_ANR, TraceDataUtils.stackToString(stack, reportBuilder, logcatBuilder)); // stackKey String stackKey = TraceDataUtils.getTreeKey(stack, stackCost); // 打印ANR日志 MatrixLog.w(TAG, \"%s \\npostTime:%s curTime:%s\", printAnr(scene, processStat, memoryInfo, status, logcatBuilder, isForeground, stack.size(), stackKey, dumpStack, inputCost, animationCost, traversalCost, stackCost), token, curTime); // for logcat if (stackCost &gt;= Constants.DEFAULT_ANR_INVALID) &#123; MatrixLog.w(TAG, \"The checked anr task was not executed on time. \" + \"The possible reason is that the current process has a low priority. just pass this report\"); return; &#125; // report 启动IssuesListActivity页面，展示ANR信息 ...&#125; 主要内容都加了注释，可以参考下。 总结：ANR的检测逻辑：在主线程一帧任务开始前发送（5s）的延迟消息，任务结束时移除该消息。如果主线程一帧任务执行时间超过了消息的延迟时间（认为这一帧导致了ANR），延迟消息将会执行，触发ANR信息收集任务 延迟消息（AnrTask）在异步线程执行，收集进程、调用堆栈、内存使用、trace信息，后续将信息log出来，并启动IssuesListActivity展示ANR结果。 慢函数检测将TestTraceMainActivity.testANR()实现耗时改成7800ms，AS会输出如下慢函数log。从log中可以看出发生了Jankiness，方法耗时7804ms，和我们的修改基本吻合。 下面看下慢函数的实现逻辑，主要代码在EvilMethodTracer。EvilMethodTracer：com.tencent.matrix.trace.tracer.EvilMethodTracer@Override public void dispatchEnd(long beginMs, long cpuBeginMs, long endMs, long cpuEndMs, long token, boolean isBelongFrame) &#123; super.dispatchEnd(beginMs, cpuBeginMs, endMs, cpuEndMs, token, isBelongFrame); long start = config.isDevEnv() ? System.currentTimeMillis() : 0; try &#123; long dispatchCost = endMs - beginMs; // 一帧耗时超过evilThresholdMs（默认700ms），执行慢函数计算逻辑 if (dispatchCost &gt;= evilThresholdMs) &#123; long[] data = AppMethodBeat.getInstance().copyData(indexRecord); long[] queueCosts = new long[3]; System.arraycopy(queueTypeCosts, 0, queueCosts, 0, 3); String scene = AppMethodBeat.getVisibleScene(); // 异步线程执行AnalyseTask MatrixHandlerThread.getDefaultHandler().post(new AnalyseTask(isForeground(), scene, data, queueCosts, cpuEndMs - cpuBeginMs, endMs - beginMs, endMs)); &#125; &#125; finally &#123; ... &#125; &#125; 主要逻辑在dispatchEnd()里面。从上面代码可以看出，当主线程一帧内耗时超过evilThresholdMs（默认700ms，可以通过TraceConfig配置），执行慢函数的警告，打印上面提到的log。 其中，慢函数的耗时，就是上面代码中的endMs - beginMs，这个逻辑在“帧率检测 - UIThreadMonitor.dispatchEnd()”中有具体讲到。 具体慢函数打印的log逻辑如下：AnalyseTask:com.tencent.matrix.trace.tracer.EvilMethodTracer.AnalyseTaskprivate class AnalyseTask implements Runnable &#123; ... void analyse() &#123; // process 进程信息 int[] processStat = Utils.getProcessPriority(Process.myPid()); String usage = Utils.calculateCpuUsage(cpuCost, cost); LinkedList&lt;MethodItem&gt; stack = new LinkedList(); ... StringBuilder reportBuilder = new StringBuilder(); StringBuilder logcatBuilder = new StringBuilder(); long stackCost = Math.max(cost, TraceDataUtils.stackToString(stack, reportBuilder, logcatBuilder)); String stackKey = TraceDataUtils.getTreeKey(stack, stackCost); // 和AnrTracer一样，打印log，启动IssuesListActivity页面，展示EvilMethod信息 MatrixLog.w(TAG, \"%s\", printEvil(scene, processStat, isForeground, logcatBuilder, stack.size(), stackKey, usage, queueCost[0], queueCost[1], queueCost[2], cost)); // for logcat ... &#125; &#125; 其中，AnalyseTask的逻辑和AnrTask类似，只是log中的部分内容不一样，就不具体展开了。 总结：慢函数的检测逻辑比较简单，在主线程一帧执行结束时，判断帧耗时是否大于预先设置的慢函数阈值，超过该阈值，即认为慢函数发生。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/09/26/matrix-trace-canary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ConstraintLayout","slug":"constraintlayout","permalink":"http://agehua.github.io/tags/constraintlayout/"}]},{"title":"ConstraintLayout 高级用法介绍","slug":"constraintlayout-intro","date":"2023-02-09T16:00:00.000Z","updated":"2024-12-05T09:41:25.286Z","comments":true,"path":"2023/02/10/constraintlayout-intro/","link":"","permalink":"http://agehua.github.io/2023/02/10/constraintlayout-intro/","excerpt":"本文介绍了部分ConstraintLayout 2.0新增的api，同时介绍了一下ConstraintLayout中不太常用的方法，方便以后查阅。","text":"本文介绍了部分ConstraintLayout 2.0新增的api，同时介绍了一下ConstraintLayout中不太常用的方法，方便以后查阅。 边距边距与平常使用并无太大区别，但需要先确定view的位置，边距才会生效。如： GONE MarginConstraintLayout提供了特殊的goneMargin属性，在目标View隐藏时，属性生效。有如下属性： layout_goneMarginStart layout_goneMarginEnd layout_goneMarginLeft layout_goneMarginTop layout_goneMarginRight layout_goneMarginBottom 居中在RelativeLayout居中，通常是使用以下三个属性： layout_centerInParent 中间居中 layout_centerHorizontal 水平居中 layout_centerVertical 垂直居中 而在ConstraintLayout居中则采用左右上下边来约束居中。 水平居中 layout_constraintLeft_toLeftOf &amp; layout_constraintRight_toRightOf 垂直居中 layout_constraintTop_toTopOf &amp; layout_constraintBottom_toBottomOf 中间居中 水平居中 &amp; 垂直居中 偏移 layout_constraintHorizontal_bias 水平偏移 layout_constraintVertical_bias 垂直偏移 两个属性的取值范围在0-1。在水平偏移中，0表示最左，1表示最右；在垂直偏移，0表示最上，1表示最下；0.5表示中间 角度定位（圆形定位）角度定位指的是可以用一个角度和一个距离来约束两个空间的中心。举个例子：&lt;TextView android:id=\"@+id/TextView1\" android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" /&gt;&lt;TextView android:id=\"@+id/TextView2\" android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" app:layout_constraintCircle=\"@+id/TextView1\" app:layout_constraintCircleAngle=\"120\" app:layout_constraintCircleRadius=\"150dp\" /&gt; 上面例子中的TextView2用到了3个属性： app:layout_constraintCircle=&quot;@+id/TextView1&quot; app:layout_constraintCircleAngle=&quot;120&quot;（角度） app:layout_constraintCircleRadius=&quot;150dp&quot;（距离） 指的是TextView2的中心在TextView1的中心的120度，距离为150dp 有ConstraintLayout实践经验的朋友应该知道margin设置负值在ConstraintLayout是没有效果的.可以通过Space来间接实现view重叠效果。 /** * Space is a lightweight View subclass that may be used to create gaps between components * in general purpose layouts. */public final class Space extends View &#123; ConstraintLayout中的控件尺寸约束在ConstraintLayout中控件可以三种方式来设置其尺寸约束。 指定具体的值。如123dp 使用值 WRAP_CONTENT,内容自适配。 设为 0dp ,即 MATCH_CONSTRAINT，扩充可用空间。 这种情况会根据约束情况重新计算控件大小，一般会测量2次 在ConstraintLayout中，不推荐使用MATCH_PARENT，而是推荐使用MATCH_CONSTRAINT(0dp),它们的行为是类似的 控件设为MATCH_CONSTRAINT时，控件的大小会扩展所有可用空间，可以通过以下属性改变控件的行为。 layout_constraintWidth_min 最小宽度 layout_constraintHeight_min 最小高度 layout_constraintWidth_max 最大宽度 layout_constraintHeight_max 最大高度 layout_constraintWidth_percent 宽度占parent的百分比 layout_constraintHeight_percent 高度占parent的百分比 比例约束控件的宽高比，要求是宽或高至少一个设为0dp，然后设置属性layout_constraintDimensionRatio即可。&lt;TextView android:text=\"Hello\" app:layout_constraintDimensionRatio=\"3:1\" android:layout_width=\"0dp\" android:layout_height=\"100dp\" /&gt; 这里设置宽高比为3:1,高度为100dp,那么宽度将为300dp。 也可以在比例前加W,H表示是宽高比还是高宽比，比如：app:layout_constraintDimensionRatio=\"H,16:9\" // 高宽比16:9 链链在水平或者垂直方向提供一组类似行为，多个元素在水平或垂直方向想相互约束，并且最终与parent约束，才能形成一条链。 横向链最左边第一个控件，垂直链最顶边第一个控件称为链头，可以通过下面两个属性链头统一定制链的样式。layout_constraintHorizontal_chainStyle //水平方向链式layout_constraintVertical_chainStyle //垂直方向链式 它两的值可以是 CHAIN_SPREAD 展开样式（默认） Weighted chain 在CHAIN_SPREAD样式，部分控件设置了MATCH_CONSTRAINT，那他们将扩展可用空间。 配合 layout_constraintHorizontal_weight=”1” 使用 CHAIN_SPREAD_INSIDE 展开样式，但两端不展开 CHAIN_PACKED 抱团(打包)样式，控件抱团一起。通过偏移bias，可以改变packed元素的位置。 工具类Guideline（参考线）参考线实际上不会在界面进行显示，只是方便在ConstraintLayout布局view时候做一个参考。通过设置Guideline的属性orientation来表示是水平方向还是垂直方向的参考线，对应值为vertical和horizontal。可以通过三种方式来定位Guideline位置。 layout_constraintGuide_begin 从左边或顶部指定具体的距离 layout_constraintGuide_end 从右边或底部指定具体的距离 layout_constraintGuide_percent 从宽度或高度的百分比来指定具体距离 Barrier（栅栏）Barrier有点类似Guideline，但Barrier会根据所有引用的控件尺寸的变化重新定位。例如经典的登录界面，右边的EditText总是希望与左右所有TextView的最长边缘靠齐。如果两个TextView其中一个变得更长，EditText的位置都会跟这变化，这比使用RelativeLayout灵活很多。 &lt;android.support.constraint.ConstraintLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" xmlns:app=\"http://schemas.android.com/apk/res-auto\" android:layout_width=\"match_parent\" android:layout_height=\"match_parent\"&gt; &lt;android.support.constraint.Barrier android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" app:barrierDirection=\"right\" android:id=\"@+id/barrier\" app:constraint_referenced_ids=\"tvPhone,tvPassword\" /&gt; &lt;TextView android:layout_width=\"wrap_content\" android:text=\"手机号码\" android:id=\"@+id/tvPhone\" android:gravity=\"center_vertical|left\" android:padding=\"10dp\" android:layout_height=\"50dp\"/&gt; &lt;TextView android:layout_width=\"wrap_content\" android:text=\"密码\" android:padding=\"10dp\" android:gravity=\"center_vertical|left\" android:id=\"@+id/tvPassword\" app:layout_constraintTop_toBottomOf=\"@id/tvPhone\" android:layout_height=\"wrap_content\"/&gt; &lt;EditText android:layout_width=\"wrap_content\" android:hint=\"输入手机号码\" android:id=\"@+id/etPassword\" app:layout_constraintLeft_toLeftOf=\"@id/barrier\" android:layout_height=\"wrap_content\"/&gt; &lt;EditText android:layout_width=\"wrap_content\" android:hint=\"输入密码\" app:layout_constraintTop_toBottomOf=\"@id/etPassword\" app:layout_constraintLeft_toLeftOf=\"@id/barrier\" android:layout_height=\"wrap_content\"/&gt;&lt;/android.support.constraint.ConstraintLayout&gt; app:barrierDirection所引用控件对齐的位置，可设置的值有：bottom、end、left、right、start、top.constraint_referenced_ids为所引用的控件，例如这里的tvPhone,tvPasswrod。 Group（组）用来控制一组view的可见性，如果view被多个Group控制，则以最后的Group定义的可见性为主。 &lt;androidx.constraintlayout.widget.Group android:layout_height=\"wrap_content\" android:layout_width=\"wrap_content\" android:visibility=\"visible\" app:constraint_referenced_ids=\"textView3,textView2,textView1\" /&gt; Placeholder（占位符）一个view占位的占位符，当指定Placeholder的content属性为另一个view的id时，该view会移动到Placeholder的位置。&lt;androidx.constraintlayout.widget.Placeholder android:id=\"@+id/place_holder\" android:layout_height=\"60dp\" android:layout_width=\"100dp\" app:layout_constraintEnd_toEndOf=\"parent\" app:layout_constraintTop_toTopOf=\"@+id/guideline2\" app:content=\"@id/textView3\"/&gt; 也可以通过代码调用的方式移动view到PlaceHolder，如下：placeholder.setContentId(R.id.textView3); Optimizer当我们使用 MATCH_CONSTRAINT 时，ConstraintLayout 将对控件进行 2 次测量，ConstraintLayout在1.1中可以通过设置 layout_optimizationLevel 进行优化，可设置的值有： none：无优化 standard：仅优化直接约束和屏障约束（默认） direct：优化直接约束 barrier：优化屏障约束 chain：优化链约束 dimensions：优化尺寸测量 Layer把一些控件组合在一起，当作一个图层，该图层自动计算边界，也是View的子类，但是功能不是完整的，Layer并不会增加 view 的层级。 支持的操作： 设置背景色 支持elevation属性 设置可见性 支持补间动画（alpha 是layer动，scale,rotation,transaction是其中的每个控件同时动） 多个图层同时包含同一个控件 图层本身支持事 支持padding、不支持margin、不支持大小 自定义 Helper为什么需要自定义? 保持 view 的层级不变，不像 ViewGroup 会增加 view 的层级 封装一些特定的行为，方便复用 一个 View 可以被多个 Helper引用，可以很方便组合出一些复杂的效果出来 如何自定义? public abstract class ConstraintHelper extends View public abstract class VirtualLayout extends ConstraintHelper public class Flow extends VirtualLayout Helper持有 view 的引用，所以可以获取 view (getViews)然后操作 view。 提供了 onLayout 前后的 callback（updatePreLayout/updatePreLayout） Helper 继承了 view，所以Helper本身也是 view Constraintlayout 2.0新增/少见的用法Flow 流式布局&lt;androidx.constraintlayout.helper.widget.Flow android:id=\"@+id/flow_test\" android:layout_height=\"wrap_content\" android:layout_width=\"wrap_content\" app:constraint_referenced_ids=\"tvA,tvB,tvC,tvD,tvE,tvF,tvG\" app:flow_firstHorizontalStyle=\"spread\" app:flow_horizontalGap=\"30dp\" app:flow_lastHorizontalStyle=\"packed\" app:flow_maxElementsWrap=\"4\" app:flow_verticalGap=\"30dp\" app:flow_wrapMode=\"chain\" app:layout_constraintEnd_toEndOf=\"parent\" app:layout_constraintStart_toStartOf=\"parent\" ... flow_wrapMode属性一共有四种值： none: 所有引用的view形成一条链，水平居中，超出屏幕两侧的view不可见. chain: 所引用的View形成一条链，超出部分会自动换行，同行的View会平分宽度，中间排列。 aligned: 所引用的View形成一条链，超出部分会自动换行，同行的View会优先左侧排列。 chain2: 所引用的View形成一条链，超出部分会自动换行，同行的View会平分宽度。但会导致app:flow_maxElementsWrap 属性失效 其他属性： app:flow_maxElementsWrap=&quot;4&quot; 一行几个元素 app:flow_verticalGap=&quot;10dp&quot; 竖直间距 app:flow_horizontalGap=&quot;10dp&quot; 横向间距 android:orientation=&quot;horizontal&quot;水平方向的流式还是竖直方向的流式 app:flow_verticalAlign =&quot;top&quot; 值有top，bottom，center，baseline。每一行元素的对齐方式 app:flow_horizontalStyle = &quot;spread | spread_inside | packed&quot; 当wrapMode为chain或ALIGNED时生效 app:flow_horizontalBias = &quot;float&quot; low的bias偏移，只在style为packed时生效 ImageFilterViewImageFilterView继承自ImageView，可以轻松实现圆角、图片色彩调节等&lt;androidx.constraintlayout.utils.widget.ImageFilterView android:id=\"@+id/imageFilterView\" android:layout_height=\"50dp\" android:layout_width=\"50dp\" app:altSrc=\"@mipmap/ic_launcher\" app:brightness=\"1\" app:contrast=\"4\" app:crossfade=\"0.5\" app:round=\"20dp\" app:roundPercent=\"1\" app:srcCompat=\"@drawable/test_logo\" app:warmth=\"1\" /&gt; roundPercent取值在0-1，由正方形向圆形过渡。 但是以下情况可能圆角会失效： layout_width或layout_height为wrapcontent时，圆角失效。或者设置了layout_constraintHorizontal_weight，且layout_width为0dp时，圆角失效 其他属性： app:altSrc=&quot;@mipmap/ic_launcher&quot; altSrc和src属性是一样的概念，altSrc提供的资源将会和src提供的资源通过crossfade属性形成交叉淡化效果。默认情况下,crossfade=0，altSrc所引用的资源不可见,取值在0-1 warmth 色温：1=neutral自然, 2=warm暖色, 0.5=cold冷色 brightness 亮度：0 = black暗色, 1 = original原始, 2 = twice as bright两倍亮度； saturation 饱和度：0 = grayscale灰色, 1 = original原始, 2 = hyper saturated超饱和； contrast 对比度：1 = unchanged原始, 0 = gray暗淡, 2 = high contrast高对比; ImageFilterButtonImageFilterView与ImageFilterButton的属性一模一样，只是它两继承的父类不一样，一些操作也就不一样。ImageFilterButton继承自AppCompatImageButton, 也就是ImageButtion。而ImageFilterView继承自ImageView。 public class ImageFilterButton extends androidx.appcompat.widget.AppCompatImageButton &#123; //...public class ImageFilterView extends androidx.appcompat.widget.AppCompatImageView &#123; //... MockViewMockView能简单的帮助构建UI界面，通过对角线形成的矩形+标签。例如：&lt;androidx.constraintlayout.utils.widget.MockView android:id=\"@+id/first\" android:layout_width=\"100dp\" android:layout_height=\"100dp\" app:layout_constraintLeft_toLeftOf=\"parent\" app:layout_constraintTop_toTopOf=\"parent\" /&gt; 关键帧动画在 ConstraintLayout 中，可以使用 ConstraintSet 和 TransitionManager 为尺寸和位置元素的变化添加动画效果。 重要提示：ConstraintSet 动画仅为子元素的尺寸和位置添加动画效果。它们不会为其他属性（例如颜色）添加动画效果。 最后，ConstraintLayout 2.0还增加了ConstraintProperties类用于通过api(代码)更新ConstraintLayout子视图，ConstraintsChangedListener监听，具体可以参考Api。 参考https://juejin.cn/post/6949186887609221133 https://juejin.cn/post/7071165641973530638 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2023/02/10/constraintlayout-intro/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ConstraintLayout","slug":"constraintlayout","permalink":"http://agehua.github.io/tags/constraintlayout/"}]},{"title":"ANR 触发原理","slug":"anr-trigger-principle","date":"2022-08-07T16:00:00.000Z","updated":"2024-12-05T09:41:25.320Z","comments":true,"path":"2022/08/08/anr-trigger-principle/","link":"","permalink":"http://agehua.github.io/2022/08/08/anr-trigger-principle/","excerpt":"Input超时机制input的超时检测机制跟service、broadcast、provider截然不同，为了更好的理解input过程先来介绍两个重要线程的相关工作：","text":"Input超时机制input的超时检测机制跟service、broadcast、provider截然不同，为了更好的理解input过程先来介绍两个重要线程的相关工作： InputReader线程负责通过EventHub(监听目录/dev/input)读取输入事件，一旦监听到输入事件则放入到InputDispatcher的mInBoundQueue队列，并通知其处理该事件； InputDispatcher线程负责将接收到的输入事件分发给目标应用窗口，分发过程使用到3个事件队列： mInBoundQueue用于记录InputReader发送过来的输入事件； outBoundQueue用于记录即将分发给目标应用窗口的输入事件； waitQueue用于记录已分发给目标应用，且应用尚未处理完成的输入事件； input的超时机制并非时间到了一定就会爆炸，而是处理后续上报事件的过程才会去检测是否该爆炸，所以更像是扫雷的过程，具体如下图所示: 1.InputReader线程通过EventHub监听底层上报的输入事件，一旦收到输入事件则将其放至mInBoundQueue队列，并唤醒InputDispatcher线程 2.InputDispatcher开始分发输入事件，设置埋雷的起点时间。先检测是否有正在处理的事件(mPendingEvent)，如果没有则取出mInBoundQueue队头的事件，并将其赋值给mPendingEvent，且重置ANR的timeout；否则不会从mInBoundQueue中取出事件，也不会重置timeout。然后检查窗口是否就绪(checkWindowReadyForMoreInputLocked)，满足以下任一情况，则会进入扫雷状态(检测前一个正在处理的事件是否超时)，终止本轮事件分发，否则继续执行步骤3。当应用窗口准备就绪，则将mPendingEvent转移到outBoundQueue队列 对于按键类型的输入事件，则outboundQueue或者waitQueue不为空， 对于非按键的输入事件，则waitQueue不为空，且等待队头时间超时500ms 3.当outBoundQueue不为空，且应用管道对端连接状态正常，则将数据从outboundQueue中取出事件，放入waitQueue队列 4.InputDispatcher通过socket告知目标应用所在进程可以准备开始干活 5.App在初始化时默认已创建跟中控系统双向通信的socketpair，此时App的包工头(main线程)收到输入事件后，会层层转发到目标窗口来处理 6.包工头完成工作后，会通过socket向中控系统汇报工作完成，则中控系统会将该事件从waitQueue队列中移除。 input超时机制为什么是扫雷，而非定时爆炸呢？是由于对于input来说即便某次事件执行时间超过timeout时长，只要用户后续在没有再生成输入事件，则不会触发ANR。 这里的扫雷是指当前输入系统中正在处理着某个耗时事件的前提下，后续的每一次input事件都会检测前一个正在处理的事件是否超时（进入扫雷状态），检测当前的时间距离上次输入事件分发时间点是否超过timeout时长。如果前一个输入事件，则会重置ANR的timeout，从而不会爆炸。 ANR处理流程不管是啥 anr ，最终都会调用到 ProcessRecord 的 appNotResponding 方法，下面来看看这个方法里面具体都做了啥： 当发生ANR时, 会按顺序依次执行: 输出ANR Reason信息到EventLog. 也就是说ANR触发的时间点最接近的就是EventLog中输出的am_anr信息; 收集并输出重要进程列表中的各个线程的traces信息，该方法较耗时; 【见小节2】 输出当前各个进程的CPU使用情况以及CPU负载情况; 将traces文件和 CPU使用情况信息保存到dropbox，即data/system/dropbox目录 根据进程类型,来决定直接后台杀掉,还是弹框告知用户. ANR输出重要进程的traces信息，这些进程包含: firstPids队列：第一个是ANR进程，第二个是system_server，剩余是所有persistent进程； Native队列：是指/system/bin/目录的mediaserver,sdcard 以及surfaceflinger进程； lastPids队列: 是指mLruProcesses中的不属于firstPids的所有进程。 Ref深入理解 Android ANR 触发原理以及信息收集过程 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/08/08/anr-trigger-principle/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANR","slug":"anr","permalink":"http://agehua.github.io/tags/anr/"}]},{"title":"RecyclerView inflate优化","slug":"async-inflate-strategy","date":"2022-07-20T16:00:00.000Z","updated":"2024-12-05T09:41:25.316Z","comments":true,"path":"2022/07/21/async-inflate-strategy/","link":"","permalink":"http://agehua.github.io/2022/07/21/async-inflate-strategy/","excerpt":"背景本文是在工作中对App启动耗时中页面展现耗时的一个优化，特意记录优化方案和遇到的问题。主要是针对首页Recyclerview itemview的一个优化，减少itemview inflate耗时，从而减少onCreateViewHolder耗时，最终减少页面展现的耗时","text":"背景本文是在工作中对App启动耗时中页面展现耗时的一个优化，特意记录优化方案和遇到的问题。主要是针对首页Recyclerview itemview的一个优化，减少itemview inflate耗时，从而减少onCreateViewHolder耗时，最终减少页面展现的耗时 思路关于view的异步inflate，官方给出了一个方案：AsyncLayoutInflater。对其原理感兴趣的朋友可以看下这篇文章：https://juejin.cn/post/6844904170508681224 关于如何减少ViewHolder的inflate时间，基于官方的方法，我做了两套方案： 1.异步初始化viewholder和 2.提前初始化viewholderprivate var sUseAsyncInflate = falseprivate var sUseAheadInflate = falsefun init(application: Application?) &#123; if (Build.VERSION.SDK_INT &lt; Build.VERSION_CODES.Q) &#123; // android 10 // 低端设备使用提前初始化viewholder aheadInflateView(application, sFirstScreenTypes) sUseAheadInflate = true// sUseAsyncInflate = true // 可以都开启，但是低端设备也异步会导致主线程事务增多 &#125; else &#123; // 高端设备异步初始化viewholder// aheadInflateView(application, sFirstScreenTypes) // 提前初始化多个，可能未初始化完首页就已经展示了 sUseAsyncInflate = true &#125;&#125; 一、提前初始化viewholder提前初始化比较简单，只需要在首页展示之前初始化好对应的viewholder，我的方案细节如下： 在Application里仅异步初始化首屏viewholder AsyncLayoutInflater异步初始化需要指定一个ViewParent，这种场景是Recyclerview Recyclerview必须指定一个LayoutManager，这里和首页一样，使用的LinearLayoutManager 异步初始化完成后，需要移除itemview的parent private var sFirstScreenTypes: IntArray = intArrayOf( // 首屏对应的viewholder的type CommonConstants.card_show_subtype_13, CommonConstants.card_show_subtype_551, CommonConstants.card_show_subtype_14)/*** 提前初始化首屏 view*/private fun aheadInflateView(application: Context?, viewTypes: IntArray) &#123; sFirstScreenTypes = viewTypes sAsyncLayoutInflater = MyAsyncLayoutInflater(application!!) sFakeParent = RecyclerView(application) sFakeParent!!.layoutManager = LinearLayoutManager(application) for (viewType in viewTypes) &#123; val model = ViewHolderTypeManager.transformViewHolder(viewType) // model是一个自定义类，绑定了viewtype和layoutid var resid = model.layoutId if (resid &lt; 0) &#123; resid = CommonGlobalContext.getAppContext().resources.getIdentifier( model.layout, \"layout\", CommonGlobalContext.getAppContext().packageName ) &#125; sAsyncLayoutInflater!!.inflate( resid, sFakeParent, viewType, null ) &#123; view, resid, parent, viewType, fakeViewHolder -&gt; if (null != view.parent) &#123; // 移除itemview的parent (view.parent as ViewGroup).removeView(view) &#125; DebugLog.d(TAG, \"aheadInflateView 完成 $viewType\") saveAsyncInflateView(application, viewType, view) // 保存初始化好的viewholder，方便首页使用 &#125; &#125;&#125;/** * 根据type，提前异步初始化一个view*/private fun saveAsyncInflateView(context: Context, type: Int, view: View?): Int &#123; if (!typeToContainer.containsKey(type)) &#123; val container = ViewHolderContainer(context, type, mReferenceQueue) container.position = -1 container.isFake = false container.view = view typeToContainer[type] = container &#125; else &#123; // TODO 后续处理提前初始化一个type多个view的情况 &#125; return -1&#125; ViewHolderContainer 是一个链表类，内部有一个next指针，所以typeToContainer其实是一个type对应一个链表private val typeToContainer: MutableMap&lt;Int, ViewHolderContainer?&gt; = HashMap() // map(viewtype, container)作为存储容器 使用的时候直接在onCreateViewHolder中判断即可 二、异步初始化viewholder异步初始化稍微复杂一点，思路是需要先绑定一个fake viewholder，等 real viewholder infalte完成在替换为real viewholder 基本原理如下： 1.区分占位viewholer和原viewholder因为是异步的，在real view没有inflate完成时，需要展示一个占位的view。占位view的viewtype = 原viewtype * (-1) 2.原viewholder inflate完成后，替换掉占位viewholer占位view在原本view inflate完成后，需要被替换，需要保存占位view的位置，然后更新为 real view 实现方案： 1.不缓存占位（fake）viewholder // 此处 type 为负数mRecyclerView.getRecycledViewPool().setMaxRecycledViews(type, 0); // RecycledViewPool不缓存 负数类型的viewholder 2.因为不缓存，所以在调用 notifyItemChanged(int position) 时会重新走到 onCreateViewHolder 简单说下 Recyclerview 分为四级缓存，1.mChangedScrap 2.mAttachedScrap、mCachedViews 3.mViewCacheExtension 4.mRecyclerPool 更多Recyclerview缓存相关的细节分析，请看我的这篇文章：RecyclerView 缓存机制 下面贴一下大概的实现方案： @Overridepublic int getItemViewType(int position) &#123; int type = ViewHolderTypeManager.transformViewHolder((Card) mDataList.get(position)).getType(); // 先拿到正确的type，判断该type是否有开启了异步初始化，然后判断是否是fake if (mUseAsyncInflate &amp;&amp; AsyncInflateHelper.INSTANCE.isFake(mContext, type, originPos, false)) &#123;// 这里并未绑定type和position type *=-1; mRecyclerView.getRecycledViewPool().setMaxRecycledViews(type, 0); // recycledPool 不缓存 fake的 &#125;&#125;// public RecyclerView.ViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) &#123; boolean useFake = mUseAsyncInflate; if(useFake) &#123; View view = AsyncInflateHelper.INSTANCE.getContainerForType(viewType); if (!isFake) &#123; if (null != view) &#123; DebugLog.d(\"ConorLee\", \"use async inflate viewtype is \" + viewType); tmpViewHolder = (BaseNewViewHolder) getViewHolder(view, model.getClassName()); &#125; else &#123; useFake = false; &#125; &#125; else &#123; View viewGroup = LayoutInflater.from(mContext).inflate(R.layout.common_album_item_default, parent, false); tmpViewHolder = new EmptyViewHolder(mContext, viewGroup); DebugLog.d(\"ConorLee\", \"fake onCreate is \"+ viewType); int layoutId = model.getLayoutId(); if (layoutId &lt; 0) &#123; layoutId = CommonGlobalContext.getAppContext().getResources().getIdentifier(model.getLayout(), \"layout\", CommonGlobalContext.getAppContext().getPackageName()); &#125; MyAsyncLayoutInflater asyncLayoutInflater = new MyAsyncLayoutInflater(mContext); asyncLayoutInflater.inflate(layoutId, parent, viewType, tmpViewHolder, new MyAsyncLayoutInflater.OnInflateFinishedListener() &#123; @Override public void onInflateFinished(@NonNull View view, int resid, @Nullable ViewGroup parent, int viewType, BaseNewViewHolder fakeViewHolder) &#123; DebugLog.d(\"ConorLee\", \"async inflate complete \"+ viewType); // inflate完成 int pos = AsyncInflateHelper.INSTANCE.updatePosAndView(viewType, view); notifyItemChanged(pos); // 这里pos是在onBindViewHolder()方法里绑定好了 if (pos == -1) &#123; DebugLog.d(\"ConorLee\", \"async inflate error \"+ viewType); &#125; &#125; &#125;); &#125; &#125;&#125; 在onBindViewHolder()方法中如果发现holder是fake，那么可以直接return，显著减少onBind时间public void onBindViewHolder(@NonNull RecyclerView.ViewHolder holder, int position, @NonNull List&lt;Object&gt; payloads) &#123; int viewHolderType = holder.getItemViewType(); if (mUseAsyncInflate &amp;&amp; viewHolderType &lt; 0) &#123; AsyncInflateHelper.INSTANCE.isFake(mContext, viewHolderType, position, true); // 这里绑定绑定type和position return; &#125; // ...&#125; 这里再说明一下： fakeviewholder是在onCreateViewHolder中创建，并且在onBindViewHolder和position绑定，绑定之后由前面的typeToContainer类保存。 异步初始化完成后，根据type在typeToContainer中找到第一个fakeviewholder，拿到位置并更新 跨页面缓存相同type的ViewHolder，如何回收？可以参考LeakCanary检测Activity是否泄漏的方法，检测viewholder的View或Context是否被回收。基本原理如下： 用弱引用（WeakReference）包裹实体类ViewHolderContainer，然后给这个弱引用绑定一个引用队列。 如果弱引用的内容被回收，该弱引用会被加入到引用队列。然后某个时间点遍历引用队列，回收ViewHolderContainer 因为Activity生命周期的原因，如果在onDestroy里立刻去遍历引用队列，可能还未回收，所以onDestroy方法不是一个完美的时间点 建议可以在上一个页面的onResume方法中延迟去做 清除的方法大概如下： fun clearViewContainer() &#123; var needLoop = true while (needLoop) &#123; val ref = mReferenceQueue.poll() as KeyedWeakReference&lt;*&gt;? ref?.let &#123; var head = typeToContainer[ref.viewHolderType] var prev: ViewHolderContainer? = null while (head != null) &#123; if (head.mKeyedWeakReference.get() == null) &#123; DebugLog.d(TAG, \"页面退出，回收container type is \" + ref.viewHolderType + \" pos is \" + ref.viewHolderPos) // 移除head节点 if (null == prev) &#123; head = head.next typeToContainer[ref.viewHolderType] = head &#125; else &#123; prev.next = head.next &#125; break &#125; prev = head head = head.next &#125; &#125; ?: let&#123; needLoop = false&#125; &#125;&#125; 结论采用这两种方式，可以显著减少viewholder的onCreateViewHolder和onBindViewHolder这两个方法的耗时，从而页面整体展现可以较以前提高100~200ms 不足： 1.异步初始化完成后，其实应该根据当前列表的firstvisiblepos和lastvisiblepos找到对应的fakeviewholder，这样效率更高。目前为了实现简单，每次异步完成都是遍历列表，拿第一个fakeviewholder，儿没有判断是否可见 2.不支持在viewholder中new Handler(), 因为底层用的官方AsyncLayoutInflater，初始化view在子线程，此时new Handler()会抛出异常 RefView 的异步 Inflate+ 全局缓存：加速你的页面 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/07/21/async-inflate-strategy/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView optimization","slug":"recyclerview-optimization","permalink":"http://agehua.github.io/tags/recyclerview-optimization/"},{"name":"AsyncInflate","slug":"asyncinflate","permalink":"http://agehua.github.io/tags/asyncinflate/"}]},{"title":"SP源码阅读和其导致ANR原因分析","slug":"sp-source-code-analysis","date":"2022-03-27T16:00:00.000Z","updated":"2024-12-05T09:41:25.311Z","comments":true,"path":"2022/03/28/sp-source-code-analysis/","link":"","permalink":"http://agehua.github.io/2022/03/28/sp-source-code-analysis/","excerpt":"背景本文是在看了字节的这篇文章: 剖析 SharedPreference apply 引起的 ANR 问题，发现很多原理不太清楚，特意根据源码总结一下，避免网上的人云亦云","text":"背景本文是在看了字节的这篇文章: 剖析 SharedPreference apply 引起的 ANR 问题，发现很多原理不太清楚，特意根据源码总结一下，避免网上的人云亦云 从如何使用开始我们使用SP，都是通过Context，直接看ContextImpl的具体实现：class ContextImpl extends Context &#123; //静态存储类，缓存所有应用的SP容器,该容器key对应应用名称，value则为每个应用存储所有sp的容器 private static ArrayMap&lt;String, ArrayMap&lt;File, SharedPreferencesImpl&gt;&gt; sSharedPrefsCache; @Override public SharedPreferences getSharedPreferences(String name, int mode) &#123; ...... File file; synchronized (ContextImpl.class) &#123; // 获取锁，然后根据name获取相对应的文件 if (mSharedPrefsPaths == null) &#123; mSharedPrefsPaths = new ArrayMap&lt;&gt;(); &#125; file = mSharedPrefsPaths.get(name); if (file == null) &#123; file = getSharedPreferencesPath(name); mSharedPrefsPaths.put(name, file); &#125; &#125; return getSharedPreferences(file, mode); &#125; @Override public SharedPreferences getSharedPreferences(File file, int mode) &#123; SharedPreferencesImpl sp; synchronized (ContextImpl.class) &#123; // 获取类锁 // 根据packagename从 sSharedPrefsCache 中拿到当前包名的cache final ArrayMap&lt;File, SharedPreferencesImpl&gt; cache = getSharedPreferencesCacheLocked(); sp = cache.get(file); // 得到一个 SharedPreferencesImpl 实例 if (sp == null) &#123; // cache中没有就创建一个 checkMode(mode); if (getApplicationInfo().targetSdkVersion &gt;= android.os.Build.VERSION_CODES.O) &#123; if (isCredentialProtectedStorage() &amp;&amp; !getSystemService(UserManager.class) .isUserUnlockingOrUnlocked(UserHandle.myUserId())) &#123; throw new IllegalStateException(\"SharedPreferences in credential encrypted \" + \"storage are not available until after user is unlocked\"); &#125; &#125; sp = new SharedPreferencesImpl(file, mode); cache.put(file, sp); return sp; &#125; &#125; if ((mode &amp; Context.MODE_MULTI_PROCESS) != 0 || getApplicationInfo().targetSdkVersion &lt; android.os.Build.VERSION_CODES.HONEYCOMB) &#123; // If somebody else (some other process) changed the prefs // file behind our back, we reload it. This has been the // historical (if undocumented) behavior. sp.startReloadIfChangedUnexpectedly(); &#125; return sp; &#125; &#125; ArrayMap 是android framework 中非常常见的容器类，比如 Bundle 中传递的 Key和 Value 都是用ArrayMap来存储的 继续看 SharedPreferencesImpl 是怎么实现保存的 找到具体实现类 SharedPreferencesImplSharedPreferencesImpl 实现了SharedPreferences 接口，其内部类 EditorImpl 也实现 Editor 接口 我们随便找一个EditorImpl类的 putXXX的方法，比如 putBoolean ：// EditorImpl @Override public Editor putBoolean(String key, boolean value) &#123; synchronized (mEditorLock) &#123; // mEditorLock是一个Object对象锁 mModified.put(key, value); // mModified是一个 HashMap，保存暂时修改的值 return this; &#125; &#125; // 为什么要多贴一个 remove方法，继续看下面的commit方法 @Override public Editor remove(String key) &#123; synchronized (mEditorLock) &#123; mModified.put(key, this); return this; &#125; &#125; 从这里也能看到SP的整个实现，各种地方都加了synchronized实现线程安全，应该是线程安全的 Editor调用完putXXX()后，需要调用 commit() 或 apply()来保存提交，我们先看下commit() : // EditorImpl @Override public boolean commit() &#123; long startTime = 0; if (DEBUG) &#123; startTime = System.currentTimeMillis(); &#125; // 将提交的数据保存到内存中 MemoryCommitResult mcr = commitToMemory(); SharedPreferencesImpl.this.enqueueDiskWrite( mcr, null /* sync write on this thread okay */); try &#123; // 调用了CountDownLatch的 await 方法，等待写入文件完成，会阻塞当前线程 mcr.writtenToDiskLatch.await(); &#125; catch (InterruptedException e) &#123; return false; &#125; finally &#123; if (DEBUG) &#123; Log.d(TAG, mFile.getName() + \":\" + mcr.memoryStateGeneration + \" committed after \" + (System.currentTimeMillis() - startTime) + \" ms\"); &#125; &#125; notifyListeners(mcr); return mcr.writeToDiskResult; &#125; 上面的await()，如果SP内容过多，会阻塞主线程导致ANR，但这种情况并不常见 继续看上面提到的 commitToMemory()// EditorImpl private MemoryCommitResult commitToMemory() &#123; // Returns true if any changes were made long memoryStateGeneration; boolean keysCleared = false; List&lt;String&gt; keysModified = null; Set&lt;OnSharedPreferenceChangeListener&gt; listeners = null; Map&lt;String, Object&gt; mapToWriteToDisk; synchronized (SharedPreferencesImpl.this.mLock) &#123; // We optimistically don't make a deep copy until // a memory commit comes in when we're already // writing to disk. if (mDiskWritesInFlight &gt; 0) &#123; // 有未同步到本地的数据 mMap = new HashMap&lt;String, Object&gt;(mMap); &#125; mapToWriteToDisk = mMap; // mDiskWritesInFlight 代表的是“此时需要将数据写入磁盘，但还未处理或未处理完成的次数” // 将 mDiskWritesInFlight 自增1（这里是唯一会增加 mDiskWritesInFlight 的地方） mDiskWritesInFlight++; // 省略 OnSharedPreferenceChangeListener 通知 synchronized (mEditorLock) &#123; boolean changesMade = false; if (mClear) &#123; // 只有调用了 Editor.clear() ，mClear才为true if (!mapToWriteToDisk.isEmpty()) &#123; changesMade = true; mapToWriteToDisk.clear(); &#125; keysCleared = true; mClear = false; &#125; // mModified是上面调用 putXXX方法来保存对应key和value的容器 for (Map.Entry&lt;String, Object&gt; e : mModified.entrySet()) &#123; String k = e.getKey(); Object v = e.getValue(); // 当v 为 this或 v为null时移除对应的key if (v == this || v == null) &#123; // 什么情况下v为this？再看下上面的remove(key)方法 if (!mapToWriteToDisk.containsKey(k)) &#123; continue; &#125; mapToWriteToDisk.remove(k); &#125; else &#123; if (mapToWriteToDisk.containsKey(k)) &#123;// 相同key的value是否相等，相等则跳过 Object existingValue = mapToWriteToDisk.get(k); if (existingValue != null &amp;&amp; existingValue.equals(v)) &#123; continue; &#125; &#125; mapToWriteToDisk.put(k, v); &#125; changesMade = true; &#125; mModified.clear(); // 清空 mModified 历史记录 if (changesMade) &#123; mCurrentMemoryStateGeneration++; &#125; memoryStateGeneration = mCurrentMemoryStateGeneration; &#125; &#125; // memoryStateGeneration 包含了所有的数据，所以每次commit都会把所有数据都写入磁盘一遍 return new MemoryCommitResult(memoryStateGeneration, keysCleared, keysModified, listeners, mapToWriteToDisk); &#125; 总结一下，commitToMemory()方法会将 Editor 中的提交和现有内存中的数据（mMap）合并，保存到 mapToWriteToDisk （其实也是mMap）中。 需要注意的是，在commitToMemory()方法中，当mClear为true，会清空mMap，但不会清空mModified，所以依然会遍历mModified，将其中保存的写记录同步到mMap中，所以下面这种写法是错误的： sharedPreferences.edit() .putString(\"key1\", \"value1\") // key1 不会被 clear 掉，commit 之后依旧会被写入磁盘中 .clear() .commit(); 此外，为什么Editor.remove(Key)时为什么不直接在map中移除对应key呢？这是为了在多线程场景下保证数据一致 看下 MemoryCommitResult 都有什么内容：// SharedPreferencesImpl 的内部类 MemoryCommitResult private static class MemoryCommitResult &#123; final long memoryStateGeneration; final boolean keysCleared; @Nullable final List&lt;String&gt; keysModified; @Nullable final Set&lt;OnSharedPreferenceChangeListener&gt; listeners; final Map&lt;String, Object&gt; mapToWriteToDisk; final CountDownLatch writtenToDiskLatch = new CountDownLatch(1); //... // 这个方法在写入文件后会被调用 void setDiskWriteResult(boolean wasWritten, boolean result) &#123; this.wasWritten = wasWritten; writeToDiskResult = result; writtenToDiskLatch.countDown(); // CountDownLatch 减一 &#125; &#125; commitToMemory() 之后会调用下面的方法将数据写入文件中private void enqueueDiskWrite(final MemoryCommitResult mcr, final Runnable postWriteRunnable) &#123; final boolean isFromSyncCommit = (postWriteRunnable == null); // 创建一个 Runnable 对象，该对象负责写磁盘操作 final Runnable writeToDiskRunnable = new Runnable() &#123; @Override public void run() &#123; synchronized (mWritingToDiskLock) &#123; // 顾名思义了，这就是最终通过文件操作将数据写入磁盘的方法了 writeToFile(mcr, isFromSyncCommit); &#125; synchronized (mLock) &#123; // 写入磁盘后，将 mDiskWritesInFlight 自减1，代表写磁盘的需求减少一个 mDiskWritesInFlight--; &#125; if (postWriteRunnable != null) &#123; // 执行 postWriteRunnable（提示，在 apply 中，postWriteRunnable 才不为 null） postWriteRunnable.run(); &#125; &#125; &#125;; // Typical #commit() path with fewer allocations, doing a write on // the current thread. if (isFromSyncCommit) &#123; // 由commit调用时，这里是true boolean wasEmpty = false; synchronized (mLock) &#123; // 如果此时只有一个 commit 请求（注意，是 commit 请求，而不是 apply ）未处理，那么 wasEmpty 为 true wasEmpty = mDiskWritesInFlight == 1; &#125; if (wasEmpty) &#123; // 当只有一个 commit 请求未处理，那么无需开启线程进行处理，直接在本线程执行 writeToDiskRunnable 即可 writeToDiskRunnable.run(); return; &#125; &#125; // 将 writeToDiskRunnable 方法线程池中执行（非主线程） // 程序执行到这里，有两种可能： // 1. 调用的是 commit() 方法，并且当前只有一个 commit 请求未处理 // 2. 调用的是 apply() 方法，第二个参数为true QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);&#125; apply()和commit()到底有什么区别再来看下apply()和commit()有什么不同。@Overridepublic void apply() &#123; final long startTime = System.currentTimeMillis(); // commitToMemory方法前面已经分析过，这里和commit方法相同 final MemoryCommitResult mcr = commitToMemory(); final Runnable awaitCommit = new Runnable() &#123; @Override public void run() &#123; try &#123; mcr.writtenToDiskLatch.await(); // commit方法中也提到了这里会等待写入文件完成 &#125; catch (InterruptedException ignored) &#123; &#125; // 省略log信息 &#125; &#125;; // 由一个LinkedList 保存 QueuedWork.addFinisher(awaitCommit); Runnable postWriteRunnable = new Runnable() &#123; @Override public void run() &#123; // 在 enqueueDiskWrite 中调用了 run() 方法 awaitCommit.run(); QueuedWork.removeFinisher(awaitCommit); // 移除掉对应的awaitCommit &#125; &#125;; // 比commit方法多了一个 runnable SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);&#125; 对比apply和commit可以发现。commitToMemory()是一样的，不同点如下： commit()只有一个待处理的（mDiskWritesInFlight == 1）则不会进入到 QueuedWork ，直接由writeToDiskRunnable处理 commit()有多个待处理，和apply()一样都会进入到 QueuedWork，区别是第二个参数分别是 false和true 下面在看 QueuedWork.queue方法：// QueuedWork.java public static void queue(Runnable work, boolean shouldDelay) &#123; Handler handler = getHandler(); synchronized (sLock) &#123; sWork.add(work); // LinkedList 保存每个 work if (shouldDelay &amp;&amp; sCanDelay) &#123; // apply会延迟 100 handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY); &#125; else &#123; handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN); &#125; &#125; &#125; handler 对象是在子线程中创建的：// QueuedWork.java private static Handler getHandler() &#123; synchronized (sLock) &#123; if (sHandler == null) &#123; HandlerThread handlerThread = new HandlerThread(\"queued-work-looper\", Process.THREAD_PRIORITY_FOREGROUND); handlerThread.start(); // 创建了一个子线程handler sHandler = new QueuedWorkHandler(handlerThread.getLooper()); &#125; return sHandler; &#125; &#125; 由handler处理 MSG_RUN 消息，最终会调用到下面的方法： // QueuedWork.java private static void processPendingWork() &#123; // 执行在子线程 long startTime = 0; if (DEBUG) &#123; startTime = System.currentTimeMillis(); &#125; synchronized (sProcessingWork) &#123; LinkedList&lt;Runnable&gt; work; synchronized (sLock) &#123; work = (LinkedList&lt;Runnable&gt;) sWork.clone(); sWork.clear(); getHandler().removeMessages(QueuedWorkHandler.MSG_RUN); &#125; // 遍历处理 LinkedList 中的消息 if (work.size() &gt; 0) &#123; for (Runnable w : work) &#123; // 这里的work是 enqueueDiskWrite() 方法中的 writeToDiskRunnable w.run(); &#125; if (DEBUG) &#123; Log.d(LOG_TAG, \"processing \" + work.size() + \" items took \" + +(System.currentTimeMillis() - startTime) + \" ms\"); &#125; &#125; &#125; &#125; 可以看到 apply() 和 commit() 方法都是提交runnable给 QueuedWork，由 QueuedWork保存在一个LinkedList中，然后由Handler切换到子线程去遍历 LinkedList 挨个执行。只不过 apply() 比 commit() 多了100毫秒延迟。 为什么SP会导致很多ANR既然是在子线程中执行，为什么网上都说 apply和commit会导致ANR呢？ 那就是下面这个关键方法，注意看官方的注释：// QueuedWork.java /** * Trigger queued work to be processed immediately. The queued work is processed on a separate * thread asynchronous. While doing that run and process all finishers on this thread. The * finishers can be implemented in a way to check weather the queued work is finished. * * Is called from the Activity base class's onPause(), after BroadcastReceiver's onReceive, * after Service command handling, etc. (so async work is never lost) */ public static void waitToFinish() &#123; long startTime = System.currentTimeMillis(); boolean hadMessages = false; Handler handler = getHandler(); synchronized (sLock) &#123; // 拿到锁之后移除handler中消息，前面 queue()方法也是用这个锁 if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) &#123; // Delayed work will be processed at processPendingWork() below handler.removeMessages(QueuedWorkHandler.MSG_RUN); &#125; // We should not delay any work as this might delay the finishers sCanDelay = false; &#125; StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();// 允许 disk reads &amp; writes try &#123; processPendingWork(); // 这里会耗时 &#125; finally &#123; StrictMode.setThreadPolicy(oldPolicy); // 回退 StrictMode &#125; try &#123; while (true) &#123; // 遍历通知各个finisher Runnable finisher; synchronized (sLock) &#123; finisher = sFinishers.poll(); &#125; if (finisher == null) &#123; break; &#125; finisher.run(); &#125; &#125; finally &#123; sCanDelay = true; &#125; // 删除耗时统计 &#125; 简单翻译一下：waitToFinish() 会立即触发队列的处理。队列中的work是在单独的线程中异步处理的，同时所有的finishers也是在这个线程中处理。finishers是用来实现一种检查队列中的work是否完成的方式。 waitToFinish() 会在一些地方被调用，比如：Activity的onPause()中，BroadcastReceiver’s onReceive之后，Service command handling之后等等（其实这些都是在**主线程）。 在 ActivityThread的搜索waitToFinish()这个方法，可以看到有好几处，比如 handleStopService()中，如下：private void handleStopService(IBinder token) &#123; Service s = mServices.remove(token); if (s != null) &#123; try &#123; s.onDestroy(); s.detachAndCleanUp(); //.. QueuedWork.waitToFinish(); //...&#125; ActivityThread 是主线程，所以当SP中提交的修改比较多时，因为 QueuedWork.waitToFinish() 有可能会导致主线程 ANR 比如下面这个ANR日志：java.lang.Object.wait(Native Method)java.lang.Thread.parkFor(Thread.java:1220)sun.misc.Unsafe.park(Unsafe.java:299)java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:813)java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:973)java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)java.util.concurrent.CountDownLatch.await(CountDownLatch.java:202)android.app.SharedPreferencesImpl$EditorImpl$1.run(SharedPreferencesImpl.java:363)android.app.QueuedWork.waitToFinish(QueuedWork.java:88)android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3336)android.app.ActivityThread.access$2300(ActivityThread.java:197)android.app.ActivityThread$H.handleMessage(ActivityThread.java:1709)android.os.Handler.dispatchMessage(Handler.java:111)android.os.Looper.loop(Looper.java:224)android.app.ActivityThread.main(ActivityThread.java:5958)java.lang.reflect.Method.invoke(Native Method)java.lang.reflect.Method.invoke(Method.java:372)com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1113) 总结 SharedPreferences肯定是线程安全的，它的内部实现使用了大量synchronized关键字，但不是进程安全的 SharedPreferences 不要存放特别大的数据 第一次加载时，需要将整个SP加载到内存当中，如果过于大，会导致阻塞，甚至会导致 ANR 每次apply或者commit，都会把全部的数据一次性写入磁盘, 所以 SP 文件不应该过大, 影响整体性能 SharedPreference的文件存储性能与文件大小相关，我们不要将毫无关联的配置项保存在同一个文件中，同时考虑将频繁修改的条目单独隔离出来 apply()同步回写（commitToMemory()）内存SharedPreferences.mMap，然后把异步回写磁盘的任务放到一个子线程中等待处理。apply()不需要等待写入磁盘完成，而是马上返回 commit()同步回写（commitToMemory()）内存SharedPreferences.mMap，然后如果mDiskWritesInFlight（此时需要将数据写入磁盘，但还未处理或未处理完成的次数）的值等于1，那么直接在调用 commit()的线程（一般是主线程）执行回写磁盘的操作，否则把异步回写磁盘的任务放到一个子线程中等待执行。commit()会阻塞调用线程，直到写入磁盘完成才返回 SP 操作仅仅把 commit() 替换为 apply() 不是万能的，如果 commit() 过于频繁也会和apply一样，在 ActivityThread 中导致ANR Ref面试高频题：一眼看穿 SharedPreferences 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/03/28/sp-source-code-analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"ANR","slug":"anr","permalink":"http://agehua.github.io/tags/anr/"}]},{"title":"Java内存分配策略","slug":"Java-summary","date":"2022-02-12T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2022/02/13/Java-summary/","link":"","permalink":"http://agehua.github.io/2022/02/13/Java-summary/","excerpt":"java的内存分配策略1、Java 程序运行时的内存分配策略有三种：\n(1) 静态分配\n(2) 栈式分配\n(3) 堆式分配\n","text":"java的内存分配策略1、Java 程序运行时的内存分配策略有三种： (1) 静态分配 (2) 栈式分配 (3) 堆式分配 2、对应的三种存储策略使用的内存空间如下： (1) 静态存储区(也称方法区) 主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好， 并且在程序整个运行期间都存在。 (2) 栈区 当方法被执行时，方法体内的局部变量都在栈上创建，并在方法执行结束时这些局部变量 所持有的内存将会自动被释放。因为栈内存分配运算内置于处理器的指令集中，效率很高， 但是分配的内存容量有限。 (3) 堆区 又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存。这部分内存在不使 用时将会由 Java 垃圾回收器来负责回收。 (4) 栈与堆的区别： 在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存 中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过 该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被 重新使用。 堆内存用来存放所有由 new 创建的对象（包括该对象其中的所有成员变量）和数组。在堆中分 配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还可以在栈 中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变 量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。 (5) 结论： 局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。—— 因为它们属于方法中的变量，生命周期随方法而结束。 成员变量全部存储与堆中（包括基本数据类型，引用和引用的对象实体）—— 因为它们属于类，类对象终究是要被 new 出来使用的。 3、垃圾回收的算法有哪些? ① 引用计数法:原理是在此对象有个引用,即增加一个计数,删除一个引用则减少一个计数.垃圾回收时,只收集计数为0的对象.此算法的最致命的无法处理循环引用的问题 ②: 标记-清除 :此算法分两个阶段,第一阶段从引用的根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除,此算法需要暂停应用,同时产生内存碎片 ③: 复制算法 此算法把内存划分为两个相等的区域,每次只使用一个区域,垃圾回收时,遍历当前使用的区域,把正在使用的对象复制到另一个区域中每次算法每次只处理正在使用的对象,因此复制的成本比较小,同时复制过去以后还能进行相应的内存整理,不会出现”碎片问题”,此算法的缺点也很明显,需要两倍的内存空间 ④: 标记-整理:此算法结合了”标记-清除”和:复制算法的两个的优点,也是分两个阶段,第一个阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,清除未标记的对象并且把存活的对象”压缩”到堆的其中一块,按顺序排放,,此算法避免”标记-清除”的碎片问题,同时也避免”复制”的空间问题 4。root搜索算法中,哪些可以作为root? 被启动类(bootstrap加载器)加载的类和创建的对象 JavaStack中引用的对象(栈内存中引用的对象) 方法区中静态引用 （1.jvm栈的栈帧中的本地变量表的引用 2.方法区静态属性引用 3.方法区中的常量引用 4.本地方法引用） 5、Java 是如何管理内存 Java 的内存管理就是对象的分配和释放问题。在 Java 中，程序员需要通过关键字 new 为 每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的 释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。 这也是 Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控 每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。监视 对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。 6、什么是 Java 中的内存泄露 在 Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是 可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再 使用这些对象。如果对象满足这两个条件，这些对象就可以判定为 Java 中的内存泄漏，这些对象 不会被 GC 所回收，然而它却占用内存。 对象被回收的条件 可达性分析，该对象没有与GC Roots相连接的引用链，将进行如下操作 如果对象还没有执行finalize()方法，就会被放入F-Queue中 当GC触发时，Finalizer线程会F-Queue中的对象的finalize()方法 执行完finalize()方法后，会再次判断对象是否可达，如果不可达，才会被回收（所以对象可以通过在finalize()中将自己连接上某个GC Root链的方式来拯救自己） java集合 1.List：ArrayList、LinkedList、Vector、CopyOnWriteArrayList 2.Set：HashSet、TreeSet、LinkedHashSet、CopyOnWriteArraySet、EnumSet 3.Map：HashMap、TreeMap、LinkedHashMap、HashTable、ConcurrentHashMap、WeakHashMap、EnumMap 4.Queue：ArrayBlockingQueue、LinkedBlockingQueue、DelayQueue、PriorityBlockingQueue、PriorityQueue。 栈：Stack&lt;E&gt; extends Vector&lt;E&gt; // 或者Deque&lt;Integer&gt; stack = new ArrayDeque&lt;Integer&gt;();// 入栈stack.push(E item)// 出栈stack.pop()// 查看栈顶元素stack.peek() ArrayList/** * ArrayList底层的容器 */transient Object[] elementData; // non-private to simplify nested class access transient解释：其实是ArrayList在序列化的时候会调用writeObject()，直接将size和element写入ObjectOutputStream；反序列化时调用readObject()，从ObjectInputStream获取size和element，再恢复到elementData。原因在于elementData是一个缓存数组，它通常会预留一些容量，等容量不足时再扩充容量，那么有些空间可能就没有实际存储元素，采用上诉的方式来实现序列化时，就可以保证只序列化实际存储的那些元素，而不是整个数组，从而节省空间和时间。 扩容为原来的1.5倍 CopyOnWriteArrayListCopyOnWriteArrayList有点像线程安全的ArrayList. 其实它的原理简单概括起来就是读写分离.写操作是在一个复制的数组上进行的,读操作在原始数组中进行,读写是分离的.写操作的时候是加锁了的,写操作完成了之后将原来的数组指向新的数组. 下面我们简单看下add和get方法是如何实现写读操作的. /** * Appends the specified element to the end of this list. * * @param e element to be appended to this list * @return &#123;@code true&#125; (as specified by &#123;@link Collection#add&#125;) */public boolean add(E e) &#123; final ReentrantLock lock = this.lock; lock.lock(); try &#123; Object[] elements = getArray(); int len = elements.length; Object[] newElements = Arrays.copyOf(elements, len + 1); newElements[len] = e; setArray(newElements); return true; &#125; finally &#123; lock.unlock(); &#125;&#125;@SuppressWarnings(\"unchecked\")private E get(Object[] a, int index) &#123; return (E) a[index];&#125;/** * &#123;@inheritDoc&#125; * * @throws IndexOutOfBoundsException &#123;@inheritDoc&#125; */public E get(int index) &#123; return get(getArray(), index);&#125; 适用场景因为每次写数据的时候都会开辟一个新的数组,这样就会耗费内存,而且加锁了,写的性能不是很好.而读操作是非常迅速的,并且还支持在写的同时可以读. 所以就非常适合读多写少的场景. 缺点内存消耗大: 每次写操作都需要复制一个新的数组,所以内存占用是非常大的数据不一致: 读数据的时候可能读取到的不是最新的数据,因为可能部分写入的数据还未同步到读的数组中.对内存敏感和实时性要求很高的场景都不适合. CopyOnWriteArrayList为啥比Vector性能好?在Vector内部,增删改查都进行了synchronized修饰,每个方法都要去锁,性能会大大降低.而CopyOnWriteArrayList只是把增删改加锁了,所以CopyOnWriteArrayList在读方面明显好于Vector.所以CopyOnWriteArrayList最好是在读多写少的场景下使用. LinkedListpublic class LinkedList&lt;E&gt; extends AbstractSequentialList&lt;E&gt; implements List&lt;E&gt;, Deque&lt;E&gt;, Cloneable, java.io.Serializable AbstractSequentialList这个类提供了List的一个骨架实现接口，以尽量减少实现此接口所需的工作量由“顺序访问”数据存储（如链接列表）支持。对于随机访问数据（如数组），应使用AbstractList优先于此类。 实现了List接口,意味着LinkedList元素是有序的,可以重复的,可以有null元素的集合. Deque是Queue的子接口,Queue是一种队列形式,而Deque是双向队列,它支持从两个端点方向检索和插入元素. 实现了Cloneable接口,标识着可以它可以被复制.注意,ArrayList里面的clone()复制其实是浅复制(不知道此概念的赶快去查资料,这知识点非常重要). 实现了Serializable 标识着集合可被序列化。 LinkedList底层是链表结构: 插入和删除比较快（O(1)），查询则相对慢一些（O(n)） 因为是链表结构，所以分配的空间不要求是连续的 private static class Node&lt;E&gt; &#123; E item; //该节点的数据 Node&lt;E&gt; next; //指向下一个节点的指针 Node&lt;E&gt; prev; //指向上一个节点的指针 Node(Node&lt;E&gt; prev, E element, Node&lt;E&gt; next) &#123; this.item = element; this.next = next; this.prev = prev; &#125;&#125; // LinkedList 当做队列使用Queue&lt;Integer&gt; queue = new LinkedList&lt;&gt;();queue.peek(); // 得到队列头元素，不出队queue.poll(); // 取出队列头元素，出队queue.offer();// 入队，队列容量不够时，不会抛出异常，这点跟 queue.add() 相反~ HashMap 存储结构JDK 1.7内部是以数组的形式存储了Entry对象,而每个Entry对象里面有key和value用来存值.它里面包含了key、value、next、hash四个字段,其中next字段是用来引用下一个Entry的(相同的hash值会被放入同一个链表中).数组中的每个位置都是一条单链表(也可以称之为桶),数组中的元素的表头.解决冲突的方式是拉链法,同一条单链表中的Entry的hash值是相同的. transient Entry&lt;K,V&gt;[] table;static class Entry&lt;K,V&gt; implements Map.Entry&lt;K,V&gt; &#123; final K key; V value; Entry&lt;K,V&gt; next; int hash;&#125; JDK 1.8存储结构也是数组,只不过将Entry换了个名字叫Node.1.7中hash值相同的是放单链表中,1.8也是,当这个单链表的长度超过8时,会转换成红黑树,增加查找效率. 负载因子和阈值 /** * The default initial capacity - MUST be a power of two. */static final int DEFAULT_INITIAL_CAPACITY = 1 &lt;&lt; 4; // aka 16/** * The load factor used when none specified in constructor. */static final float DEFAULT_LOAD_FACTOR = 0.75f; HashMap的默认大小是16,默认负载因子是0.75,意思是当存的元素个数超过16*0.75时就要对数组扩容,这里的阈值就是16*0.75=12.负载因子就是用来控制什么时候进行扩容的. 阈值 = 当前数组长度*负载因子 每次扩容之后都得重新计算阈值.默认的数组长度是16,默认的负载因子是0.75这些都是有讲究的.在元素个数达到数组的75%时进行扩容是一个比较折中的临界点,如果定高了的话hash冲突就很严重,桶就会很深,查找起来比较慢,定低了又浪费空间.一般情况下,还是不会去定制这个负载因子. 拉链法工作原理每次新存入一个新的键值对时,首先计算Entry的hashCode,用hashCode%数组长度得到所在桶下标,然后在桶内依次查找是否已存在该元素,存在则更新,不存在则插入到桶的头部. HashMap 1.7和1.8区别 JDK1.7用的是头插法,JDK1.8及置换是尾插法. 且1.7插入时候顺序是与原来相反的,而1.8则还是原来的顺序 JDK1.7是数组+链表,JDK1.8是数组+链表+红黑树 JDK1.7在插入数据之前进行扩容,JDK1.8是插入数据之后才扩容 JDK1.7是Entry来表示节点,而JDK1.8是Node JDK1.7扩容和后存储位置是用hash &amp; (length-1)计算来的,而JDK1.8只需要判断hash值新增参与运算的位是0还是1就能快速计算出扩容后该放在原位置,还是需要放在 原位置+扩容的大小值 . 计算hash值的时候,JDK1.7用了9次扰动处理,而JDK1.8是2次ps: 红黑树查找元素,需要O（logn）的开销 下面来介绍下HashMap与Hashtable的区别： 1.实现：HashMap继承的类是AbstractMap类，而Hashtable继承的是Dictionary类，而Dictionary是一个过时的类，因此通常情况下建议使用HashMap而不是使用Hashtable 2.内部结构：其实HashMap与Hashtable内部基本都是使用数组-链表的结构，但是HashMap引入了红黑树的实现，内部相对来说更加复杂而性能相对来说应该更好 3.NULL值控制：通过前面的介绍我们知道Hashtable是不允许key-value为null值的，Hashtable对于key-value为空的情况下将抛出NullPointerException，而HashMap则是允许key-value为null的，HashMap会将key=null方法index=0的位置。 4.线程安全：通过阅读源码可以发现Hashtable的方法中基本上都是有synchronized关键字修饰的，但是HashMap是线程不安全的，故对于单线程的情况下来说HashMap的性能更优于Hashtable，单线程场景下建议使用HashMap. HashMap是绝大部分利用键值对存取场景的首选.多线程环境下,推荐使用ConcurrentHashMap. 数组+链表+红黑树 ConcurrentHashMap ConcurrentHashMap存在的意义?有了HashMap和Hashtable为啥还需要ConcurrentHashMap? HashMap本身不是线程安全的,不应该在多线程情况下使用!!!. Hashtable是使用synchronized保证线程安全,当一个线程访问其中一个同步方法时,另外的线程是不能访问其同步方法的(竞争的是同一把锁).这样就会导致在put数据的时候,其他线程也不能get数据之类的操作.在线程竞争激烈的条件下,并发效率非常低. 既要多线程环境下使用,也要效率高? 选ConcurrentHashMap没错了. ConcurrentHashMap使用的是分段锁(Segment)技术,将数组分成很多段,每个分段锁维护着几个桶(HashEntry),然后修改数据的时候将这一段锁起来,其他线程这个时候要操作其他分段的数据也互不干扰.如果操作的不是同一分段,则线程间不存在竞争关系,大大提高了并发效率. 当然,有的朋友可能也想到了,有些时候可能需要跨段,比如调用size()方法,这个时候可能会锁整个表. 而在JDK1.8中抛弃了Segment分段锁机制,利用CAS+synchronized来保证并发更新的安全. 乐观锁是一种思想，CAS是这种思想的其中一种实现方式.当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新变量的值,而其他线程都失败,失败的线程并不会挂起,而是被告知这次竞争失败,并可以再次尝试. CAS操作中包含3个操作数: 需要读写的位置(V)、进行比较的预期原值(A)和拟写入的新值(B).如果内存位置V的值与预期原值A相匹配,那么处理器会自动将该位置值更新为新值B.否则处理器不做任何操作. TreeMap和LinkedHashMap TreeMap整体结构TreeMap底层的数据结构是红黑树,和HashMap的红黑树结构是一样的. TreeMap利用红黑树左节点小,右节点大的性质,根据key进行排序,使每个元素能够插入到红黑树中大小适当的位置,维护了key的大小关系,适用于key需要排序的场景. 因为底层使用的是平衡二叉树的结构,所以containsKey,get,put,put,remove等方法的时间复杂度都是log(n). LinkedHashMap的使用HashMap是无序的,TreeMap可以根据key进行排序,LinkedHashMap可以维护插入的顺序.LinkedHashMap是HashMap的子类,它内部有一个双向链表维护着键值对的顺序.每个键值对即是位于哈希表中,也是位于双向链表中.LinkedHashMap支持两种顺序: 插入顺序: 先添加的在前面,后添加的在后面.修改操作是不影响顺序的 访问顺序: 在get/put操作之后,其对应的键值对会移动到链表末尾,表示最近使用到的.而链表的头部就是最久没有被访问到的. HashSet和TreeSet HashSetHashSet里面维护了一个不含重复元素的集合,实现比较简单,就是通过HashMap来实现的. TreeSetTreeSet大致的结构是和HashSet相似,底层的数据结构是TreeMap,所以继承了TreeMap key能够排序的功能,迭代的时候也可以按照key的顺序排序进行迭代. HashSet和TreeSet的区别 HashSet保存的数据是无序的,TreeSet保存的数据是有序的. TreeSet保存自定义类对象的时候,必须实现Comparable接口,不实现就无法区分大小关系,无法排序.HashSet存对象的时候,判断其元素是否重复的依据是hashCode()和equals(). Android中的Bundle,SparseArray和ArrayMap Bundle Android为什么要设计Bundle而不是直接使用HashMap来直接进行数据传递? Bundle内部是由ArrayMap实现的,ArrayMap在设计上比传统的HashMap更多考虑的是内存优化Bundle使用的是Parcelable序列化,而HashMap使用Serializable序列化 SparseArray SparseArray是用来存储key-value组合的,类似HashMap.但是它只能存储key为int类型的,也就避免了key的装箱操作和分配空间.建议使用SparseArray&lt;V&gt;替换HashMap&lt;Integer,V&gt;. 还有就是SparseArray是专门设计来节省空间的,所以它里面的数据存储得非常紧凑.key和value都是单独用一个数组来存储的,并且数组是按大小排好序了的,每次增删改查等操作都是用二分查找来进行定位位置的. 可以看到SparseArray比HashMap少了基本数据的自动装箱操作,而且不需要额外的结构体,单个元素存储成本低,在数据量小的情况下,随机访问的效率很高.但是缺点也显而易见,就是增删的效率比较低,在数据量比较大的时候,调用gc拷贝数组成本巨大. 除了SparseArray,Android还提供了SparseIntArray(int:int),SparseBooleanArray(int:boolean),SparseLongArray(int:long)等,其实就是把对应的value换成基本数据类型. ArrayMap ArrayMap是一种通用的key-value映射的数据结构,和SparseArray类似.但是SparseArray只能存储int类型的key,而ArrayMap可以存储其他类型的key.如果你没有见过它也没关系,你肯定用过它.Bundle底层就是用的这玩意儿存储的数据.它底层不使用SparseArray可能就是因为它的key只能是int类型. ArrayMap与传统的HashMap不同,它的数据结构是两个数组,一个数组(mHashes)用来存放key的hashcode,一个数组(mArray)用来存放key和value.你没看错,mArray数组里面即存放了key,也存放了value ArrayMap在put/remove时,和SparseArray基本是一致的,也是通过二分查找求数组索引,然后再执行相应的操作.不同的是ArrayMap的扩容机制和缩容机制. 在put需要扩容时,如果容量小于4就给4,小于8就给8,其次就是扩容1.5倍.之所以给4或8是因为可以利用缓存的ArrayMap对象;在remove时,如果数组长度大于8但是存储的数据不足数据大小的1/3时,就会缩容,mSize小于等于8则设置新大小为8,否就设置为mSize的1.5倍,也就是说在内存使用量不足1/3时,内存数据收紧50%. 除了 put 方法，ArrayMap 和 SparseArray 都有一个 append 方法，它和 put 很相似，append 的差异在于该方法不会去做扩容操作，是一个轻量级的插入方法。在明确知道肯定会插入队尾的情况下使用 append 性更好，因为 put 一上来就做二分查找，时间复杂度 O(logn)，而 append 时间复杂度为 O(1)。 ArraySet 也是 Android 特有的数据结构，用来替代 HashSet 的，和 ArrayMap 几乎一致，包含了缓存机制、扩容机制等。 ArrayList和LinkedList区别我们知道，通常情况下，ArrayList和LinkedList的区别有以下几点： ArrayList是实现了基于动态数组的数据结构，而LinkedList是基于链表的数据结构； 对于随机访问get和set，ArrayList要优于LinkedList，因为LinkedList要移动指针； 对于添加和删除操作add和remove，一般大家都会说LinkedList要比ArrayList快，因为ArrayList要移动数据。但是实际情况并非这样，对于添加或删除，LinkedList和ArrayList并不能明确说明谁快谁慢 针对for循环，ArrayList比LinkedList速度快，因为LinkedList没有实现RandomAccess接口，需要从头或者从尾开始遍历到指定位置。如果都使用迭代器遍历的话，双方时间差不多。 关于第三条：ArrayList在添加和删除，如果未出现扩容的情况下，ArrayList快，这是因为：当 ArrayList 在添加元素到数组中间时，有一部分数据需要复制重排，效率就不是很高，那为啥 LinkedList 比它还要低呢？这是因为 LinkedList 把元素添加到中间位置的时候，需要在添加之前先遍历查找，这个查找的时间比较耗时。更多详细区别可以看这篇文章 https://blog.csdn.net/javageektech/article/details/108162342 // 使用Iterator遍历没有实现 RandomAccess的数据结构if (!(list instanceof RandomAccess)) &#123; Iterator it = list.iterator(); while(it.hasNext()) &#123; Println(it.next()); &#125;&#125; HashMap、concurrentHashMap、HashTable的区别HashMap是基于哈希表实现的，每一个元素都是一个key-value对，其内部通过单链表解决冲突问题，容量不足（超过了阈值）时，同样会自动增长。 HashMap是非线程安全的，只是用于单线程环境下，多线程环境下可以采用concurrent并发包下的concurrentHashMap。 HashMap实现了Serializable接口，因此它支持序列化，实现了Cloneable接口，能被克隆。 HashMap、HashTable区别1、HashMap是非线程安全的，HashTable是线程安全的。 2、HashMap的键和值都允许有null值存在，而HashTable则不行。 3、因为线程安全的问题，HashMap效率比HashTable的要高。 ConcurrentHashMap是线程安全的HashMap的实现。同样是线程安全的类，它与HashTable在同步方面有什么不同呢？ ConcurrentHashMap与HashTable的区别ConcurrentHashMap基于concurrentLevel划分出了多个Segment来对key-value进行存储，从而避免每次锁定整个数组，在默认的情况下，允许16个线程并发无阻塞的操作集合对象，尽可能地减少并发时的阻塞现象。 ConcurrentHashMap使用Lock锁住部分数组，而HashTable则是锁住整个数组，所以在多线程的环境中，相对于HashTable，ConcurrentHashMap会带来很大的性能提升！ 而在JDK1.8中抛弃了Segment分段锁机制,利用CAS+synchronized来保证并发更新的安全. Java中Vector和ArrayList的区别首先看这两类都实现List接口，而List接口一共有三个实现类，分别是ArrayList、Vector和LinkedList。List用于存放多个元素，能够维护元素的次序，并且允许元素的重复。3个具体实现类的相关区别如下： ArrayList是最常用的List实现类，内部是通过数组实现的，它允许对元素进行快速随机访问。数组的缺点是每个元素之间不能有间隔，当数组大小不满足时需要增加存储能力，就要讲已经有数组的数据复制到新的存储空间中。当从ArrayList的中间位置插入或者删除元素时，需要对数组进行复制、移动、代价比较高。因此，它适合随机查找和遍历，不适合插入和删除。 Vector与ArrayList一样，也是通过数组实现的，不同的是它支持线程的同步，即某一时刻只有一个线程能够写Vector，避免多线程同时写而引起的不一致性，但实现同步需要很高的花费，因此，访问它比访问ArrayList慢。 LinkedList是用链表结构存储数据的，很适合数据的动态插入和删除，随机访问和遍历速度比较慢。另外，他还提供了List接口中没有定义的方法，专门用于操作表头和表尾元素，可以当作堆栈、队列和双向队列使用。 关于ArrayList和Vector区别如下： ArrayList在内存不够时默认是扩展50% + 1个，Vector是默认扩展1倍。 Vector提供indexOf(obj, start)接口，ArrayList没有。 Vector属于线程安全级别的，但是大多数情况下不使用Vector，因为线程安全需要更大的系统开销。 深拷贝or浅拷贝在java语言中，有几种方式可以创建对象呢？ 1 使用new操作符创建一个对象 2 使用clone方法复制一个对象 那么这两种方式有什么相同和不同呢？ new操作符的本意是分配内存。程序执行到new操作符时， 首先去看new操作符后面的类型，因为知道了类型，才能知道要分配多大的内存空间。分配完内存之后，再调用构造函数，填充对象的各个域，这一步叫做对象的初始化，构造方法返回后，一个对象创建完毕，可以把他的引用（地址）发布到外部，在外部就可以使用这个引用操纵这个对象。 而clone在第一步是和new相似的，都是分配内存，调用clone方法时，分配的内存和源对象（即调用clone方法的对象）相同，然后再使用原对象中对应的各个域，填充新对象的域， 填充完成之后，clone方法返回，一个新的相同的对象被创建，同样可以把这个新对象的引用发布到外部。 Person p = new Person(23, \"zhang\"); Person p1 = p; System.out.println(p); System.out.println(p1); 这种是复制引用 如果两个Person对象的name的地址值相同， 说明两个对象的name都指向同一个String对象， 也就是浅拷贝， 而如果两个对象的name的地址值不同， 那么就说明指向不同的String对象， 也就是在拷贝Person对象的时候， 同时拷贝了name引用的String对象， 也就是深拷贝。验证代码如下： Person p = new Person(23, \"zhang\"); Person p1 = (Person) p.clone(); String result = p.getName() == p1.getName() ? \"clone是浅拷贝的\" : \"clone是深拷贝的\"; System.out.println(result); clone是浅拷贝的 序列化属于深拷贝 更多关于java拷贝知识参考这篇文章： https://juejin.cn/post/6844903806577164302 java引用类型 引用类型 被垃圾回收时间 用途 生存时间 强引用 从来不会 对象的一般状态 JVM停止运行时终止 软引用 在内存不足时 对象缓存 内存不足时终止 弱引用 在垃圾回收时 对象缓存 gc运行后终止 虚引用 Unknown Unknown Unknown 强引用是使用最普遍的引用：Object o=new Object(); 特点：不会被GC将对象的引用显示地置为null：o=null; // 帮助垃圾收集器回收此对象 软引用用来描述一些还有用但是并非必须的对象，在Java中用java.lang.ref.SoftReference类来表示。对于软引用关联着的对象，只有在内存不足的时候JVM才会回收该对象。因此，这一点可以很好地用来解决OOM的问题，并且这个特性很适合用来实现缓存：比如网页缓存、图片缓存等 弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象 虚引用也称为幻影引用：一个对象是都有虚引用的存在都不会对生存时间都构成影响，也无法通过虚引用来获取对一个对象的真实引用。唯一的用处：能在对象被GC时收到系统通知，JAVA中用PhantomReference来实现虚引用。 android中的位运算https://juejin.im/post/5c51f308e51d45141a1f2f2c Java 内存模型（Java Memory Model ,JMM）Java内存模型规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。 而JMM就作用于工作内存和主存之间数据同步过程。他规定了如何做数据同步以及什么时候做数据同步。 主内存和工作内存与JVM内存结构中的Java堆、栈、方法区等并不是同一个层次的内存划分，无法直接类比。《深入理解Java虚拟机》中认为，如果一定要勉强对应起来的话，从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分。工作内存则对应于虚拟机栈中的部分区域 总结下，JMM是一种规范，目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。目的是保证并发编程场景中的原子性、可见性和有序性。 Java内存模型的实现了解Java多线程的朋友都知道，在Java中提供了一系列和并发处理相关的关键字，比如volatile、synchronized、final、concurren包等。其实这些就是Java内存模型封装了底层的实现后提供给程序员使用的一些关键字。 其实，原子性问题，可见性问题和有序性问题。是人们抽象定义出来的。而这个抽象的底层问题就是前面提到的缓存一致性问题、处理器优化问题和指令重排问题等 原子性是指在一个操作中就是cpu不可以在中途暂停然后再调度，既不被中断操作，要不执行完成，要不就不执行。 可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。 有序性即程序执行的顺序按照代码的先后顺序执行。 原子性在Java中，为了保证原子性，提供了两个高级的字节码指令monitorenter和monitorexit。在synchronized的实现原理文章中，介绍过，这两个字节码，在Java中对应的关键字就是synchronized。 因此，在Java中可以使用synchronized来保证方法和代码块内的操作是原子性的。 可见性Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值的这种依赖主内存作为传递媒介的方式来实现的。 Java中的volatile关键字提供了一个功能，那就是被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次是用之前都从主内存刷新。因此，可以使用volatile来保证多线程操作时变量的可见性。 除了volatile，Java中的synchronized和final两个关键字也可以实现可见性。只不过实现方式不同，这里不再展开了。 有序性 在Java中，可以使用synchronized和volatile来保证多线程之间操作的有序性。实现方式有所区别： volatile关键字会禁止指令重排。synchronized关键字保证同一时刻只允许一条线程操作。 好了，这里简单的介绍完了Java并发编程中解决原子性、可见性以及有序性可以使用的关键字。读者可能发现了，好像synchronized关键字是万能的，他可以同时满足以上三种特性，这其实也是很多人滥用synchronized的原因。 但是synchronized是比较影响性能的，虽然编译器提供了很多锁优化技术，但是也不建议过度使用。 ReentrantLock与synchronized对比 SynchronizedSynchronized是通过同步互斥来实现线程安全的；即同一时间只能有一个线程访问synchronized修饰的代码块或方法。其特性与功能如下： synchronized是java的关键字，由jvm支持。 支持重入，即一个线程在获取对象的锁以后可以再次对此对象上锁。 修饰普通方法，锁是当前实例对象；修饰静态方法，锁是当前类的class对象；包裹代码块，锁是括号中的对象。 不支持等待中断。 synchronized是非公平的。 ReentrantLockReentrantLock是一种非常常见的临界区处理手段，通过在执行代码前上锁保证同一时间只有一个线程能执行指定的代码块。ReentrantLock的特性与功能如下： ReentrantLock是java api层面的实现，有Unsafe支持。 支持重入。 支持公平锁、非公平锁，默认是非公平锁。公平锁指：多个线程在等待同一个线程的锁时，必须按照申请所得时间顺序来获取锁。非公平锁指：在锁被释放时，任何一个等待锁的线程都有机会获取锁。 支持等待中断。例如：A线程获取对象O的锁， B线程等待获取O的锁，当B长时间无法获取锁时，B可以放弃获取锁。 锁可以绑定多个条件。线程进入临界区，却发现在某一条件满足之后才能执行，条件对象就是用来管理那些已经获得了锁，但是却不能做有用工作的线程。一个ReentrantLock对象可以同时绑定多个Condition对象。 ReentrantLock本质上是通过一个队列来完成同步的。因为每个Node与一个线程关联，只需要做好对队列节点的同步处理，既可以完成多线程的同步处理。 public class Test &#123; ReentrantLock lock = new ReentrantLock(); public static void main(String[] args) &#123; Test tt = new Test(); Thread t1 = new Thread(new Runnable() &#123; @Override public void run() &#123; tt.add(); &#125; &#125;); Thread t2 = new Thread(new Runnable() &#123; @Override public void run() &#123; tt.add(); &#125; &#125;); t1.start(); t2.start(); &#125; public void add()&#123; try&#123; lock.lock(); for (int i = 0; i &lt;10; i++) &#123; System.out.println(\"测试\"+i); &#125; &#125;catch (Exception e)&#123;&#125; finally &#123; lock.unlock(); &#125; &#125;&#125; 通过以上代码我们可以发现，不同于synchronized，ReentrantLock需要开发手动在代码中加锁和解锁。 公平锁与非公平锁 公平锁：通过同步队列来实现多个线程按照申请锁的顺序获取锁。 默认情况下，synchronized和ReentrantLock都是非公平锁。但是ReentrantLock可以通过构造函数传参true,来创建公平锁，可以通过以下的部分源码。 synchronized是JVM虚拟机的实现， 而ReentrantLock是JDK实现的，是java.util.concurrent包中的锁。 单例的双重校验锁实现(面试必备) public class Singleton &#123; private Singleton() &#123;&#125; // 使用volatile修饰变量可以禁止JVM的指令重排，保证多线程下获取实例的唯一。 private volatile static Singleton instance; public static Singleton getInstance()&#123; if(instance == null)&#123; synchronized (Singleton.class)&#123; if(instance == null)&#123; instance = new Singleton(); &#125; &#125; &#125; return instance; &#125;&#125; 深入理解 AQS 和 CAS 原理AQS 全称是 Abstract Queued Synchronizer，即抽象队列同步器，AQS内部基于CAS、LockSupport、自旋和双端等待队列实现的多线程同步工具，AQS它是一套实现多线程同步功能的框架。AQS 在JDK源码中被大量使用到，尤其是在 JUC（Java Util Concurrent）中，比如ReentrantLock、CountDownLatch、ThreadPoolExecutor。理解 AQS 对我们理解 JUC 中其他组件至关重要，并且在实际开发中也可以通过自定义 AQS 来实现各种需求场景。 链接：https://www.jianshu.com/p/5ff4bfe546f3 https://juejin.cn/post/6844904167044038663 注解原理继承 AbstractProcessor ，根据注解构建对象，将对象存入map。然后使用javapoet 遍历map输出到一个类中。这个类就保存了所有的注解对象的键值对 应用APP启动过程应用app具体会运行到哪个进程，我们从一个app的启动入手分析。app的启动一般从该应用的桌面图标点击开始，调用startActivity(Intent), 再通过Binder IPC机制, 最终调用到AMS。AMS会执行如下操作: 1.通过PackageManager的resolveIntent()收集这个intent对象的指向信息. 2.通过grantUriPermissionLocked()方法来验证用户是否有足够的权限去调用该intent对象指向的Activity. 3.如果有权限, AMS会检查并在新的task中启动目标activity. 4.如果ProcessRecord是null, AMS调用startProcessLocked()方法来创建新的进程. android崩溃当应用崩溃时，默认会调用Thread类中设置的一个 UncaughtExceptionHandler 中的 uncaughtException方法，所以我们只要实现一个UncaughtExceptionHandler对象，在其对应方法中实现对崩溃信息的保存或者上传即可。 异常分类Throwable是Java语言中所有错误或异常的超类。下一层分为Error和Exception Error类是指Java运行时系统的内部错误和资源耗尽错误。应用程序不会抛出该类对象。如果出现了这样的错误，除了告知用户，剩下的就是尽力使程序安全的终止。 Exception又有两个分支， 一个是运行时异常RuntimeException，如：NullPointerException、ClassCastException； 一个是检查异常CheckedException，如I/O错误导致的IOException、SQLException。 RuntimeException是那些可能在 Java 虚拟机正常运行期间抛出的异常的超类。派生RuntimeException的异常一般包含几个方面： 1、错误的类型转换 2、数组访问越界 3、访问空指针 如果出现RuntimeException，那么一定是程序员的错误 检查异常CheckedException一般是外部错误，这种异常都发生在编译阶段，Java编译器会强制程序去捕获此类异常，即会出现要求你把这段可能出现异常的程序进行try catch，该类异常一般包括几个方面：1、试图在文件尾部读取数据2、试图打开一个错误格式的URL3、试图根据给定的字符串查找class对象，而这个字符串表示的类并不存在 RuntimeException：在定义方法时不需要声明会抛出RuntimeException， 在调用这个方法时不需要捕获这个RuntimeException；总之，未检查异常不需要try…catch…或throws 机制去处理CheckedException：定义方法时必须声明所有可能会抛出的exception； 在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去总之，一个方法必须声明所有的可能抛出的受检异常；未检查异常要么不可控制（Error），要么应该避免（RuntimeException）。如果方法没有声明所有的可能发生的受检异常，编译器就会给出错误信息 Exception 和 Error 区别Exception和Error都是继承了Throwable类,在Java中只有Throwable类型的实例才可以被抛出(throw)或者捕获,它是异常处理机制的基本组成类型. Exception和Error体现了Java平台设计者对不同异常情况的分类,Exception是程序正常运行中,可以预料的意外情况,可能并且应该捕获,进行相应的处理. Error是指正常情况下,不大可能出现的情况,绝大部分的Error都会导致程序处于非正常状态,不可恢复状态.既然是非正常情况,所以不便于也不需要捕获,常见的如OutOfMemoryError之类的都是Error的子类. Exception又分为可检查(checked)异常和不检查(unchecked)异常,可检查异常在源码里必须显式地进行捕获处理,这里是编译期检查的一部分.不检查异常就是所谓的运行时异常,类似NullPointerException,ArrayIndexOutOfBoundsExceptin之类的,通常是可以编码避免的逻辑错误,具体根据需要来判断是否需要捕获,并不会在编译期强制要求. ClassNotFoundException 和 NoClassDefFoundError 区别需要注意到的是一个是Exception一个是Error. Java支持使用Class.forName方法来动态加载类,任意一个类的类名如果被作为参数传递给这个方法都将导致该类被加载到JVM内存中,如果这个类在类路径中没有被找到,那么此时就会在运行时抛出ClassNotFountException异常. 如果JVM或者ClassLoader实例尝试加载(可能通过正常的方法调用,也可能是使用new来创建新的对象)类的时候找不到类的定义.要查找的类在编译的时候是存在的,运行的时候却找不到类,这个时候就会导致NoClassDefFoundError.造成该问题的原因可能是打包过程中漏掉了部分类,或者jar包出现了损毁或者篡改.解决这个问题的方法是查找那些在开发期间存在于类路径但运行期间却不在类路径下的类. Java多线程sleep和wait的区别 使用方面：从使用的角度来看sleep方法是Thread线程类的方法，而wait是Object顶级类的方法。sleep可以在任何地方使用，而wait只能在同步方法和同步块中使用。 CPU及锁资源释放:sleep、wait调用后都会暂停当前线程并让出CPU的执行时间，但不同的是sleep不会释放当前持有对象的锁资源，到时间后会继续执行，而wait会释放所有的锁并需要notify/notifyAll后重新获取到对象资源后才能继续执行。 异常捕获方面：sleep需要捕获或者抛出异常，而notify/notifyAll则不需要，但是wait方法需要捕获 InterruptedException。 简述jvm中默认的classLoader与功能 1.Bootstrap ClassLoader：负责加载java基础类，主要是 %JRE_HOME/lib/ 目录下的rt.jar、resources.jar、charsets.jar和class等 2.Extension ClassLoader：负责加载java扩展类，主要是 %JRE_HOME/lib/ext 目录下的jar和class 3.App ClassLoader：负责加载当前java应用的classpath中的所有类。 4.classloader 加载类用的是全盘负责双亲委托机制。 1.所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有 Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入。所以，当我们自定义的classloader加载成功了 com.company.MyClass以后，MyClass里所有依赖的class都由这个classLoader来加载完成。 2.双亲委托，是指子类加载器如果没有加载过该目标类，就先委托父类加载器加载该目标类，只有在父类加载器找不到字节码文件的情况下才从自己的类路径中查找并装载目标类。 重写的特性 1.方法名相同，参数类型和顺序相同 2.子类返回类型小于等于父类方法返回类型。即：子类返回的类型要为父类的子类 3.子类抛出异常小于等于父类方法抛出异常。即：子类抛出的异常类型要为父类的子类 4.子类访问权限大于等于父类方法访问权限。 理解Serializable和Parcelable我们日常用到的有二种场景。 1.数据的持久化保存，这里主要是指保存到文件 2.Android页面间数据的传递 第一种情况两者耗时差不多 第二种情况intent putExtra中添加实现了Serializable接口的对象时。Parcel会将Serializable先序列化为字节数组，然后写入，所以这中间就进行了二次序列化，性能肯定比Parcelable要低很多。所以如果我们的场景是界间传值的话，Parcelable是首选。 自行决定哪些需要字段需要序列化 1.继承Parcelable的类，在writeToParcel 方法中由开发者自己决定哪些字段参与初始化 2.Serializable可以使用transient关键字来忽略一些不需要参与序列化的字段，也可以重写writeObject和readObject二个方法来替代默认的序列化调用。JDK中有很多这样的类，比如ArrayList，HashMap，都是重写了writeObject方法。 为什么HashMap要自定义序列化逻辑呢？我想可能的原因是，存储数据的数组table，一般都是不满的（因为HashMap的负载因子默认0.75，超过就会扩容），里面肯定会有很多null，如果是默认的序列化，这些null也会被被序列化，显然这些null是没有必要的做序列化的 Activity 中的 onAttachedToWindow，View 的 onAttachedToWindow和 RecyclerView.Adapter 的 onViewAttachedToWindow Activity 中的 onAttachedToWindow 就是在 View 附加到 window 上的时候进行回调，而 onDetachedFromWindow() 就刚好相反。是在OnResume之后回调，但是在 onAttachedToWindow() 回调的时候，不能拿到 View 的宽高 View 的 onAttachedToWindow 的调用时机会发生在 onMeasure() 之前。我们在自定义 View 的时候，某些比较重量级的资源，而且不能与其他 View 通用的时候，就可以重写这两个方法，并在 onAttachedToWindow() 中进行初始化，onDetachedFromWindow() 方法里释放掉。 RecyclerView.Adapter 的 onViewAttachedToWindow 和onViewDetachedToWindow。这两个方法在列表布局的时候，用作曝光埋点非常好用，当 Adapter 创建的 View 被窗口分离（即滑动离开了当前窗口界面的）的时候，onViewDetachedToWindow() 会被直接回调，反之，在列表项 View 在被滑动进屏幕的时候，onViewAttachedToWindow() 会立马被调用。 RecyclerView.Adapter 的onBindViewHolder和onViewRecycled(RecyclerView.ViewHolder holder)可以成对使用，表示ViewHolder绑定和解绑，但是这两个方法不适合用来做曝光埋点。因为RecyclerView的一二级缓存的重复使用不会回调onBindViewHolder。 RecyclerView.Adapter 咋还有一个 onAttachedToRecyclerView。根据源码我们可以发现，onAttachedToRecyclerView() 是在 setAdapter() 的时候触发。 我的 RecyclerView.Adapter 的 onViewAttachedToWindow 为啥没起作用？可能会有小伙伴会遇到这个问题，在遇到这个问题前，先检查一下你这个 RecyclerView 是否是一个正常滚动的 View，你如果是被别人嵌套滚动，把自己设置了 isNestedScrollingEnabled 为 false 的话，那你都失去了 Recyclerview 的功用了，那自然是不行的。可能又有小伙伴说了，由于需求历史原因，我就是用了 NestedScrollView 嵌套了 Recyclerview，并禁掉了 Recyclerview 的滑动功能，但又想做上面的曝光埋点功能，那如何是好？如果是这样的话，大概你就只能通过类似 View 的 getGlobalVisibleRect() 这样的方法来判断 View 的可见性来处理了。关于 View 的可见性分析，这里就点到为止，大家就自行 Google 吧。 LiveData为何能感知生命周期LiveData是一个数据持有类，它可以通过添加观察者被其他组件观察其变更 LiveData的特点： 1）采用观察者模式，数据发生改变，可以自动回调（比如更新UI）。 2）不需要手动处理生命周期，不会因为Activity的销毁重建而丢失数据。 3）不会出现内存泄漏。 4）不需要手动取消订阅，Activity在非活跃状态下（pause、stop、destroy之后）不会收到数据更新信息。 LiveData 的生命周期感知是由Lifecycle来实现的。ComponentActivity 实现了LifecycleOwner，并添加了一个ReportFragment，通过fragment的生命周期回调来完成生命周期的状态切换，并通知给注册的 LifecycleObserver接口 自定义的Activity都继承自AppCompatActivity ，AppCompatActivity 实现了LifecycleOwner接口，同时持有实现了Lifecycle的LifecycleRegistry对象，这个对象就可以将其理解为观察者模式中的Subject，LifecycleRegistr聚合多个LifecycleObserver，生命周期改变时通知LifecycleObserver进行相应的方法调用。 ViewModelViewModel旨在以注重生命周期的方式存储和管理界面相关的数据(配合它里面的livedata)。 1.1 将Activity的UI处理和数据处理分离，分开管理，解耦且高效。 1.2 ViewModel在屏幕旋转等系统配置更改后被继续保留，避免再次请求数据，浪费网络资源。重建该 Activity时，它接收的ViewModel实例与之前的Activity持有的ViewModel相同。只有当Activity真正销毁时，框架才会调用getViewModelStore().clear()清除所有的ViewModel。 1.3 避免页面销毁后，数据返回后刷新界面导致crash，例如页面发起请求后，数据还没返回就关闭activity，数据返回后，刷新界面，因view不存在而crash。 1.4 两个Fragment可以使用其Activity的ViewModel来处理通信。 1.5 和onSaveInstanceState()对比，onSaveInstanceState()仅适合可以序列化再反序列化的少量数据，而不适合数量可能较大的数据，如用户列表或位图。 1.6 ViewModelScope，为应用中的每个ViewModel定义了ViewModelScope。如果ViewModel已清除，则在此范围内启动的协程都会自动取消。 原理ViewModelProviderViewModelStoreOwner：是一个接口，只定义了一个方法：getViewModelStore()。同样ComponentActivity和Fragment实现了这个接口，所以我们在Activity或者Fragment中使用ViewModelProvider传入的this就可以了。 ViewModelStore：ViewModelStore主要是用来存储ViewModel对象的，内部有一个HashMap集合（HashMap&lt;String, ViewModel&gt; mMap）用来存储ViewModel对象。 ComponentActivity持有一个ViewModelStore，可以通过ViewModelStoreOwner中的getViewModelStore()方法获取。（为啥不直接在Activity获取ViewModelStore，再获取ViewModel呢？因为ViewModel要通过ViewModelProvider.Factory创建） Factory：是一个接口，用来创建ViewModel的 Activity 可以调用ViewMode的方法，同时ViewModel通过LiveData变化的监听改变view Kotlin单例使用 object 关键字object SomeSingleton&#123; fun sayHi()&#123;&#125;&#125; 转成java代码之后是： public final class SomeSingleton &#123; public static final SomeSingleton INSTANCE; public final void sayHi() &#123; &#125; static &#123; SomeSingleton var0 = new SomeSingleton(); INSTANCE = var0; &#125;&#125; 有对比就清晰了，Kotlin 的 object 关键字，在 Java 表现的特点如下： 类用 final 标记，标识不可变性。 内部声明一个 static final 的当前类的对象 INSATNCE。 在静态代码块中，进行 INSTANCE 对象的初始化。 可以看到，在 Kotlin 的 object 中，是使用类的初始化锁来保证线程安全的。 那什么是类的初始化锁？简单来说， JVM 在类的初始化阶段（即在 Class 被加载后，且被线程使用之前），会执行类的初始化，在初始化期间，JVM 会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化，避免多线程调用时，引发线程安全的问题。 怎样保证任务顺序执行 观察者模式，使用队列保存注册的观察者，按队列顺序依次执行 责任链模式，参考view的事件分发、有序广播、Okhttp拦截器 怎么统计app启动过程中的方法AMS 方法进入的时候埋点，方法退出的时候埋点 Fragment栈原理fragment的切换切换都是通过getFragmentManager()，以beginTransaction()开始，commit() / commitNow() / commitAllowingStateLoss() 结束。getFragmentManager().beginTransaction().setCustomAnimations(R.anim.active_right_in, 0, 0, R.anim.active_right_out).add(android.R.id.content, fragment, \"DebugConfigFragment\").addToBackStack(getClass().getSimpleName()).commitAllowingStateLoss(); beginTransaction() 会返回一个FragmentTransaction的实现 -》 BackStackRecord@NonNullpublic FragmentTransaction beginTransaction() &#123; return new BackStackRecord(this);&#125; FragmentTransaction 是一个抽象类，内部定义了操作fragment栈的各种方法 BackStackRecord是FragmentTransaction的实现类 内部定义了一些常量int值，用作操作指令 同时内部有一个实体类 Op，Op类的实例会存储 fragment引用，对应的指令。 在 BackStackRecord 类中，我们以show和hide为例，每次show或hide都会创建一个对应的Op类，并持有了对应的fragment和指令：@NonNullpublic FragmentTransaction hide(@NonNull Fragment fragment) &#123; addOp(new Op(OP_HIDE, fragment)); // OP_HIDE 就定义在FragmentTransaction类中 return this;&#125;@NonNullpublic FragmentTransaction show(@NonNull Fragment fragment) &#123; addOp(new Op(OP_SHOW, fragment)); return this;&#125; addOp()方法将新创建的指令加入到了 mOps（ArrayList）中： ArrayList&lt;Op&gt; mOps = new ArrayList&lt;&gt;();void addOp(Op op) &#123; mOps.add(op); op.mEnterAnim = mEnterAnim; op.mExitAnim = mExitAnim; op.mPopEnterAnim = mPopEnterAnim; op.mPopExitAnim = mPopExitAnim;&#125; 从FragmentTransaction 继承来的方法，比如show和hide这种只会向 mOps 中添加数据，真正消耗 mOps 操作的是 executeOps() 和 executePopOps() 方法： void executeOps() &#123; final int numOps = mOps.size(); for (int opNum = 0; opNum &lt; numOps; opNum++) &#123; // 从前向后遍历 final Op op = mOps.get(opNum); final Fragment f = op.mFragment; if (f != null) &#123; f.setNextTransition(mTransition); &#125; switch (op.mCmd) &#123; case OP_HIDE: f.setNextAnim(op.mExitAnim); mManager.hideFragment(f); break; case OP_SHOW: f.setNextAnim(op.mEnterAnim); mManager.setExitAnimationOrder(f, false); mManager.showFragment(f); break; //... void executePopOps(boolean moveToState) &#123; for (int opNum = mOps.size() - 1; opNum &gt;= 0; opNum--) &#123; // 从后向前遍历 final Op op = mOps.get(opNum); Fragment f = op.mFragment; if (f != null) &#123; f.setNextTransition(FragmentManager.reverseTransit(mTransition)); &#125; switch (op.mCmd) &#123; case OP_HIDE: f.setNextAnim(op.mPopEnterAnim); mManager.showFragment(f); break; case OP_SHOW: f.setNextAnim(op.mPopExitAnim); mManager.setExitAnimationOrder(f, true); mManager.hideFragment(f); break; //... executeOps() 方法和 executePopOps() 方法遍历正好相反、相同指令对应的操作也正好相反。同时这两个方法都是在FragmentManager的commit() / commitNow() / commitAllowingStateLoss()这几个方法中触发的，篇幅有限，本文就不具体展开了。 32位和64位的区别64位可以使用的虚拟内存空间更大，64位意味着操作系统和CPU将使用64位的指令集 虚拟内存（VSS OOM）当前绝大部分系统已经是 64 位系统，无论是服务器、个人 PC、亦或是终端手机。64 位系统的进程地址空间分布中，如果是 3 级页表，内核栈和用户栈分别有 512G 的地址空间，如果是 4 级页表，内核栈和用户栈分别有 256TB 的地址空间，这个值远大于实际物理内存，使用耗尽的可能性也非常小。 而我们的问题，发生在 64 位的 Android 系统中，但却是 32 位的应用。 32 位应用的可用虚拟内存只有 4G。物理内存我们有非常多的机制去管理和控制它的使用量，但虚拟内存其实只是一个空头支票，所以可以理解说，在设计时，能申请的虚拟内存范围是很大的，一般远大于一个进程实际会用的物理内存，所以它不需要复杂的管理机制，从可用的资源中找一块空虚的即可。然而当下系统和应用附加的东西越来越多，手机上可用的物理内存也越来越多，甚至有十几 G 内存的手机，仅仅 4G 的地址空间，些许错误或者资源申请较多，便很容易出现 OOM。 所以总结起来有两个问题导致： 32 位系统的 4G 虚拟内存在当下资源消耗较多的情况下，已捉襟见肘。 虚拟内存没有防止碎片化等复杂的管理机制，出现碎片化等问题。 在32位的应用上，内存使用不合理时，会比较容易引发因虚拟内存不足而导致的白屏或OOM等问题。参考：https://cloud.tencent.com/developer/article/1797705 虚拟内存浅析在多任务操作系统中，每个进程都拥有独立的虚拟地址空间，通过虚拟地址进行内存访问主要具备以下几点优势： 进程可使用连续的地址空间来访问不连续的物理内存，内存管理方面得到了简化。 实现进程与物理内存的隔离，对各个进程的内存数据起到了保护的作用。 程序可使用远大于可用物理内存的地址空间，虚拟地址在读写前不占用实际的物理内存，并为内存与磁盘的交换提供了便利。 重载和重写的区别https://zhuanlan.zhihu.com/p/288278829 区别点 重载方法 重写方法 参数列表 必须修改 一定不能修改 返回类型 可以修改 一定不能修改 异常 可以修改 可以减少或删除，一定不能抛出新的或者更广的异常 访问 可以修改 一定不能做更严格的限制（可以降低限制） 重载方法之间的方法名是相同的，但方法签名不同 一定要注意的是方法重载时，方法返回值没有什么意义，是由方法名和参数列表决定的 方法名和形参数据类型列表可以唯一的确定一个方法，与方法的返回值一点关系都没有，这是判断重载重要依据，所以，以下的代码是不允许的 public long aaaa()&#123; &#125; public int aaaa()&#123; &#125; 类型签名又是另一种了，参考： https://cloud.tencent.com/developer/article/1870340?from=article.detail.1787542 再看一下类型签名：public void test1()&#123;&#125; test1()V public void test2(String str) test2(Ljava/lang/String;)V public int test3()&#123;&#125; test3()I 从以上三个例子，我们就可以很简单的看出一些小小的规律： JVM为我们提供的类型签名实际上是由 方法名(上文的例子为了简单没有写出全类名)、形参列表、返回值三部分构成的，基本形式就是： 全类名.方法名(形参数据类型列表)返回值数据类型 Java方法类型签名中特殊字符/字母含义| 特殊字符 | 数组类型 | 特殊说明 ||:——–:|:——-:|:——–:||V| void| 一般用于表示方法的返回值||Z |boolean|||B| byte|||C| char|||S |short|||I| int|||J|long|||F|float|||D|double|||[|数组| 以[开头，配合其他的特殊字符，表示对应数据类型的数组，几个[表示几维数组||L|全类名|引用类型 以 L 开头 ; 结尾，中间是引用类型的全类名| android 中系统时间参考： https://www.jianshu.com/p/dfa184764daa System.currentTimeMillis()我们一般通过它来获取手机系统的当前时间。事实上，它返回的值是系统时刻距离标准时刻(1970.01.01 00:00:00)的毫秒数。它相当于家里的“挂钟”一样，并不是十分精准，而且可以随意修改。所以它可能经常被网络或者用户校准。正是由于这个原因，这个方法获取的值不适合用来做时间间隔的统计。但是它适合用来获取当前日期，时刻等时间点相关的逻辑。 SystemClock.upTimeMillis()这个值记录了系统启动到当前时刻经过的时间。但是系统深度睡眠(CPU睡眠，黑屏，系统等待唤醒)之中的时间不算在内。这个值不受系统时间设置，电源策略等因素的影响，因此它是大多数时间间隔统计的基础，例如Thread.sleep(long millis),Object.wait(long millis),System.nanoTime()等。系统保证了这个值只增长不下降，所以它适合所有的不包括系统睡眠时间的时间间隔统计。 SystemClock.elapsedRealtime() &amp; SystemClock.elapsedRealtimeNanos这个值与SystemClock.upTimeMillis()类似。它是系统启动到当前时刻经过的时间，包括了系统睡眠经过的时间。在CPU休眠之后，它依然保持增长。所以它适合做更加广泛通用的时间间隔的统计。 综上，如果想要避免用户修改时间，网络校准时间对时间间隔统计的影响，使用SystemClock类相关的方法就可以了，至于选择upTimeMillis()还是elapsedRealtime()就要根据自己的需求确定了。 系统还提供了几个时间控制相关的工具： 标准方法Thread.sleep(long millis) 和 Object.wait(long millis)是基于SystemClock.upTimeMillis()的。所以在系统休眠之后它们的回调也会延期，直到系统被唤醒才继续计时。并且这两个同步方法会响应InterruptException，所以在使用它们的时候必须要处理InterruptException异常。 SystemClock.sleep(long millis) 与 Thread.sleep(long millis) 方法是类似的，只不过SystemClock.sleep(long millis) 不响应InterruptException异常。Handler类的 postDelay()方法也是基于SystemClock.upTimeMillis()方法的。 AlarmManager可以定时发送消息，即使在系统睡眠、应用停止的状态下也可以发送。我们在创建定时事件的时候有两个参数可以选择RTC和ELAPSED_REALTIME，它们对应的方法就是System.currentTimeMillis() ~ RTC，SystemClock.elapsedRealtime() ~ ELAPSED_REALTIME。这样一对应，它们的区别也就非常明显了。 子线程更新UI下次如果有人问你 Android 中子线程真的不能更新 UI 吗？ 你可以这么回答：任何线程都可以更新自己创建的 UI。只要保证满足下面几个条件就好了 在 ViewRootImpl 还没创建出来之前 UI 修改的操作没有线程限制。 在 ViewRootImpl 创建完成之后 1.保证「创建 ViewRootImpl 的操作」和「执行修改 UI 的操作」在同一个线程即可。也就是说，要在同一个线程调用 ViewManager#addView 和 ViewManager#updateViewLayout 的方法。 注：ViewManager 是一个接口，WindowManger 接口继承了这个接口，我们通常都是通过 WindowManger（具体实现为 WindowMangerImpl） 进行 view 的 add remove update 操作的。 2.对应的线程需要创建 Looper 并且调用 Looper#loop 方法，开启消息循环。 有同学可能会问，保证上述条件 1 成立，不就可以避免 checkThread 时候抛出异常了吗？为什么还需要开启消息循坏？ 条件 1 可以避免检查异常，但是无法保证 UI 可以被绘制出来。 条件 2 可以让更新的 UI 效果呈现出来 WindowManger#addView 最终会调用 WindowManageGlobal#addView 方法，进而触发ViewRootImpl#setView 方法，该方法内部会调用 ViewRootImpl#requestLayout 方法。 了解过 UI 绘制原理的同学应该知道 下一步就是 scheduleTraversals 了，该方法会往消息队列中插入一条消息屏障，然后调用 Choreographer#postCallback 方法，往 looper 中插入一条异步的 MSG_DO_SCHEDULE_CALLBACK 消息。等待垂直同步信号回来之后执行。 注：ViewRootImpl 有一个 Choreographer 成员变量，ViewRootImpl 的构造函数中会调用 Choreographer#getInstance(); 方法，获取一个当前线程的 Choreographer 局部实例。 使用子线程更新 UI 有实际应用场景吗？ Android 中的 SurfaceView 通常会通过一个子线程来进行页面的刷新。如果我们的自定义 View 需要频繁刷新，或者刷新时数据处理量比较大，那么可以考虑使用 SurfaceView 来取代 View。 java线程状态 初始状态(NEW)实现Runnable接口和继承Thread可以得到一个线程类，new一个实例出来，线程就进入了初始状态。 就绪状态(RUNNABLE之READY)就绪状态只是说你资格运行，调度程序(Cpu)没有挑选到你，你就永远是就绪状态。调用线程的start()方法，此线程进入就绪状态。当前线程sleep()方法结束，其他线程join()结束，等待用户输入完毕，某个线程拿到对象锁，这些线程也将进入就绪状态。当前线程时间片用完了，调用当前线程的yield()方法，当前线程进入就绪状态。锁池里的线程拿到对象锁后，进入就绪状态。进入：调用Thread.start() 运行中状态(RUNNABLE之RUNNING)线程调度程序从可运行池中选择一个线程作为当前线程时线程所处的状态。这也是线程进入运行状态的唯一的一种方式。 阻塞状态(BLOCKED)阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。进入：等待进入synchronized方法、等待进入synchronized块退出：获取到锁 等待(WAITING)处于这种状态的线程不会被分配CPU执行时间，它们要等待被显式地唤醒，否则会处于无限期等待的状态。进入：Object.wait() Thread.join() LockSupport.park()退出：Object.notify() Object.notifyAll() LockSupport.unpark(Thread) 超时等待(TIMED_WAITING)处于这种状态的线程不会被分配CPU执行时间，不过无须无限期等待被其他线程显示地唤醒，在达到一定时间后它们会自动唤醒。进入：Thread.sleep(long) Object.wait(long) Thread.join(long) LockSupport.parkNanos() LockSupport.parkUnit()退出：Object.notify() Object.notifyAll() LockSupport.unpark(Thread) 终止状态(TERMINATED)当线程的run()方法完成时，或者主线程的main()方法完成时，我们就认为它终止了。这个线程对象也许是活的，但是它已经不是一个单独执行的线程。线程一旦终止了，就不能复生。在一个终止的线程上调用start()方法，会抛出java.lang.IllegalThreadStateException异常。进入：执行完成 同步队列与等待队列Wait()与Notify()方法wait(): 持有锁的线程调用wait()方法后，会一直阻塞，直到有别的线程调用notify()将其唤醒notify(): 只能通知一个等待线程，唤醒任意一个处于wait线程notifyall()：将等待队列中的所有线程唤醒，并加入同步队列 任意一个object以及其子类对象都有两个队列 同步队列：所有尝试获取该对象Monitor失败的线程，都加入同步队列排队获取锁 等待队列：已经拿到锁的线程在等待其他资源时，主动释放锁，置入该对象等待队列中，等待被唤醒，当调用notify()会在等待队列中任意唤醒一个线程，将其置入同步队列的尾部，排队获取锁 同步队列状态当前线程想调用对象A的同步方法时，发现对象A的锁被别的线程占有，此时当前线程进入同步队列。简言之，同步队列里面放的都是想争夺对象锁的线程。当一个线程1被另外一个线程2唤醒时，1线程进入同步队列，去争夺对象锁。同步队列是在同步的环境下才有的概念，一个对象对应一个同步队列。线程等待时间到了或被notify/notifyAll唤醒后，会进入同步队列竞争锁，如果获得锁，进入RUNNABLE状态，否则进入BLOCKED状态等待获取锁。 参考：https://segmentfault.com/a/1190000038392244 静态方法传递Context会导致内存泄漏吗？不会，解释如下： Passing a context or any argument for that matter, to a method, whether it is static or not, will put that argument on the function stack. For the scope of that function the context will be kept on the stack. As soon as the function ends, the function stack is cleared, i.e. the context won’t leak! No exceptions to this! This is the whole pure synchronous function thing discussed previously. If you pass a context to a method (static or not) and in that method you decide to run some background stuff you might leak. This is not a pure function. You would leak if you are holding onto the context longer than it takes to finish executing the original method. Using anonymous inner classes for callbacks when doing background work is typically a culprit here because that callback is invoked after the original function ends. You should ask yourself how the callback can fire and access the context argument if the original function has concluded. Well a copy is created so you now are holding onto a context that outlives the scope of the original function and tada leak! 参考：https://www.reddit.com/r/androiddev/comments/d9khex/can_passing_context_to_static_method_cause_a/ Https 单向认证和双向认证贴张https讲解比较全面的图：还可以参考下面的链接：https://cloud.tencent.com/developer/article/1420302 除了tcp三次握手，还有ssl四次握手https://www.cnblogs.com/wangwenhui/p/14870881.html https://segmentfault.com/a/1190000025126670 Activity启动流程主要包含几步？我们以点击Launcher的一个icon为开始，整体扯一下Activity的启动过程，桌面其实就是LauncherApp的一个Activity 当点击Launcher的icon开始，Launcher进程会像AMS发送点击icon的启动信息（这些信息就是在AndroidMainifest.xml中&lt;intent-filter&gt;标签定义的启动信息，数据由PackageManagerService解析出来） AMS收到信息后会先后经过ActivityTaskManagerService-&gt;ActivityStartController-&gt;ActivityStarter内部类Request，然后把信息存到Request中，并通知Launcher进程让Activity休眠（补充个小知识点，这个过程会检测Activity在AndroidMainifest.xml的注册，如果没有注册就报错了） Launcher进程的ApplicationThread对象收到消息后调用handlePauseActivity()进行暂停，并通知AMS已经暂停。实现细节：ActivityThread.sendMessage()通过ActivityThread的H类发送Handler消息，然后触发 mTransactionExecutor.execute(transaction)，执行过程中依赖ActivityClientRecord.mLifecycleState数值并通过ClientTransactionHandler抽象类的实现（ActivityThread）进行分发。注 ：ActivityClientRecord.mLifecycleState（-1 ~ 7分别代表 UNDEFINED, PRE_ON_CREATE, ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_RESTART） AMS收到Launcher的已暂停消息后，会检查要启动的Activity所在的进程是否已经启动了，如果已经启动了就打开，如果未启动则通过Process.start(android.app.ActivityThread)来启动一个新的进程。 进程创建好以后，会调用ActivityThread.main(),初始化MainLooper，并创建Application对象。然后Instrumentation.newApplication()反射创建Application，创建ContextImpl通过Application的attach方法与Application进行绑定，最终会调用Instrumentation.callApplicationOnCreate执行Application的onCreate函数进行一些初始化的工作。完成后会通知AMS进程已经启动好了。通知过程：通过IActivityManager.attachApplication（IApplicationThread thread, long startSeq），将Application对象传入AMS AMS收到app进程启动成功的消息后，从ActivityTaskManagerService中取出对应的Activity启动信息， 并通过ApplicationThreadProxy对象，调用其scheduleTransaction(ClientTransaction transaction)方法，具体要启动的Activity都在ClientTransaction对象中。 app进程的ApplicationThread收到消息后会调用ActiivtyThread.sendMessage()，通过H发送Handler消息，在handleMessage方法的内部又会调用 mTransactionExecutor.execute(transaction);具体参考第3步最终调用performLaunchActivity方法创建activity和context并将其做关联，然后通过mInstrumentation.callActivityOnCreate()-&gt;Activity.performCreate()-&gt;Activity.onCreate()回调到了Activity的生命周期。 activity向Instrumentation请求创建 Instrumentation通过AMS在本地进程的IBinder接口，访问AMS，这里采用的跨进程技术是AIDL。 然后AMS进程一系列的工作，如判断该activity是否存在，启动模式是什么，有没有进行注册等等。 通过ClientLifeCycleManager，利用本地进程在系统服务进程的IBinder接口直接访问本地ActivityThread。 ApplicationThread是ActivityThread的内部类，IApplicationThread是在远程服务端的Binder接口 ApplicationThread接收到服务端的事务后，把事务直接转交给ActivityThread处理。 ActivityThread通过Instrumentation利用类加载器进行创建实例，同时利用Instrumentation回调activity的生命中周期 阻止activity重建时出现多个fragment正常activity重建后，fragment系统会帮你重建一个，执行到onCreate 自己又会重建一个，所以会出现多个protected void onCreate(@Nullable Bundle savedInstanceState) &#123; if (savedInstanceState != null) &#123; savedInstanceState.putParcelable(\"android:support:fragments\", (Parcelable)null); &#125;&#125; intent传输数据大小限制通过 intent 的 bundle 的源码可以看到它们都是实现了 Parcelable ，其实就是通过序列化来实现通信的。Parcelable 的底层使用了 Parcel 机制。传递实际上是使用了 binder 机制，binder 机制会将 Parcel序列化的数据写入到一个共享内存中，读取时也是 binder 从共享内存中读出字节流，然后 Parcel 反序列化后使用。这就是 Intent 或 Bundle 能够在 activity或者跨进程通信的原理。 这个共享内存就叫 Binder transaction buffer，这块内存有一个大小限制，目前是 1MB，而且共用的，当超过了这个大小就会报错（TransactionTooLargeException）。 HandlerHandler 构造方法：// Handler.javapublic Handler(@Nullable Callback callback, boolean async) &#123; mLooper = Looper.myLooper(); if (mLooper == null) &#123; throw new RuntimeException( \"Can't create handler inside thread \" + Thread.currentThread() + \" that has not called Looper.prepare()\"); &#125; mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async;&#125;// Looper.java public static @Nullable Looper myLooper() &#123; return sThreadLocal.get();&#125;// Looper.java private static void prepare(boolean quitAllowed) &#123; if (sThreadLocal.get() != null) &#123; throw new RuntimeException(\"Only one Looper may be created per thread\"); &#125; sThreadLocal.set(new Looper(quitAllowed)); // 创建mQueue&#125;// Looper.java private Looper(boolean quitAllowed) &#123; mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread();&#125; 一个线程可以创建多个handler，但只会有一个Looper，因此也只会有一个MessageQueue。 如果子线程创建handler的时候没有调用 Looper.prepare() 那么会抛出运行时异常 //MessageQueue.javaMessageQueue(boolean quitAllowed) &#123; mQuitAllowed = quitAllowed; mPtr = nativeInit();&#125; 在java层中，mPtr保存了nativeInit()返回的值，Looper和MessageQueue在java层和native层都有，但它们的功能并不是一一对应，此处native层的Looper与Java层的Looper没有任何的关系，只是在native层重实现了一套类似功能的逻辑。通过管道与epoll机制建立一套消息机制在java层，没有消息时，会调用nativePollOnce方法进入阻塞。进入阻塞后可以通过超时唤起，也可以调用 natvieWake 主动唤起 //frameworks/base/core/jni/android_os_MessageQueue.cppstatic void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj, jlong ptr, jint timeoutMillis) &#123; //把ptr强转为NativeMessageQueue NativeMessageQueue* nativeMessageQueue = reinterpret_cast&lt;NativeMessageQueue*&gt;(ptr); nativeMessageQueue-&gt;pollOnce(env, obj, timeoutMillis);&#125; 总结一下： 因为java层的消息机制是依赖native层的消息机制来实现的，而native层的消息机制是通过Linux的管道和epoll机制实现的，epoll机制是一种高效的IO多路复用机制， 它使用一个文件描述符管理多个描述符，java层通过mPtr指针也就共享了native层的epoll机制的高效性，当loop方法中取不到消息时，便阻塞在MessageQueue的next方法，而next方法阻塞在nativePollOnce方法，nativePollOnce方法通过JNI调用进入到native层中去，最终nativePollOnce方法阻塞在epoll_wait方法中，epoll_wait方法会让当前线程释放CPU资源进入休眠状态，等到下一个消息到达(mWakeEventFd会往管道写入字符)或监听的其他事件发生时就会唤醒线程，然后处理消息，所以就算loop方法是死循环，当线程空闲时，它会进入休眠状态，不会消耗大量的CPU资源。 Native层参考这两篇文章： https://www.jianshu.com/p/57a426b8f145 https://www.jianshu.com/p/c4e34c16aa45 为什么List&lt;String&gt;不能赋值给List&lt;Object&gt;java在1.5的时候引入了泛型，虽然String是Object的子类，但是List&lt;String&gt; 并不是List&lt;Object&gt;的子类型，这叫做不支持协变（也有说型变）。 如何让java支持协变，List&lt;String&gt; 可以赋值给 List&lt;Object&gt;呢，下面这样写就可以List&lt;? extends Object&gt; list = new ArrayList&lt;String&gt;();list.add(\"kotlin\"); // 编译报错，不允许 在kotlin写法如下：val list: List&lt;Any?&gt; = ArrayList&lt;String?&gt;()// 这里的List是一个接口类public interface List&lt;out E&gt; : Collection&lt;E&gt; &#123; //... // 没有add方法&#125; add方法不能使用的原因就是将泛型声明为协变所需要付出的代价。 跟协变对立的是逆变，关键字是super或in（kotlin 这里再延伸一下，java中数组不支持泛型是协变的，kotlin中数组是支持泛型的，也就不再协变 更多的关于协变和逆变的介绍可以看我的这篇文章：Kotlin 与 Java 语言比较 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/02/13/Java-summary/","raw":null,"content":null,"categories":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/categories/java/"}],"tags":[{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"Android Binder机制分析（三）","slug":"android-binder-principle3","date":"2022-02-09T16:00:00.000Z","updated":"2024-12-05T09:41:25.309Z","comments":true,"path":"2022/02/10/android-binder-principle3/","link":"","permalink":"http://agehua.github.io/2022/02/10/android-binder-principle3/","excerpt":"背景上篇文章分析到了Binder机制，同时介绍了Android Framework层系统服务的binder使用。本篇文章分析下Binder的底层实现，以及为什么Binder只需要一次内存拷贝。","text":"背景上篇文章分析到了Binder机制，同时介绍了Android Framework层系统服务的binder使用。本篇文章分析下Binder的底层实现，以及为什么Binder只需要一次内存拷贝。 Binder到底是什么？Android系统内核是Linux，每个进程有自己的虚拟地址空间，在32位系统下最大是4GB，其中3GB为用户空间，1GB为内核空间；每个进程用户空间相对独立，而内核空间是一样的，可以共享，如下图 Linux驱动运行在内核空间，狭义上讲是系统用于控制硬件的中间程序，但是归根结底它只是一个程序一段代码，所以具体实现并不一定要和硬件有关。Binder就是将自己注册为一个misc类型的驱动，不涉及硬件操作，同时自身运行于内核中，所以可以当作不同进程间的桥梁实现IPC功能。 Linux最大的特点就是一切皆文件，驱动也不例外，所有驱动都会被挂载在文件系统dev目录下，Binder对应的目录是/dev/binder，注册驱动时将open release mmap等系统调用注册到Binder自己的函数，这样的话在用户空间就可以通过系统调用以访问文件的方式使用Binder。 进一步关于内核空间和用户空间的区别，可以看这篇文章：https://zhuanlan.zhihu.com/p/343597285 Binder的简略通讯过程一个进程如何通过binder和另一个进程通讯？最简单的流程如下 接收端进程开启一个专门的线程，通过系统调用在binder驱动（内核）中先注册此进程（创建保存一个bidner_proc），驱动为接收端进程创建一个任务队列（biner_proc.todo）接收端线程开始无限循环，通过系统调用不停访问binder驱动，如果该进程对应的任务队列有任务则返回处理，否则阻塞该线程直到有新任务入队发送端也通过系统调用访问，找到目标进程，将任务丢到目标进程的队列中，然后唤醒目标进程中休眠的线程处理该任务，即完成通讯 Binder的一次拷贝众所周知Binder的优势在于一次拷贝效率高，众多博客已经说烂了，那么什么是一次拷贝，如何实现，发生在哪里，这里尽量简单地解释一下。 上面已经说过，不同进程通过在内核中的Binder驱动来进行通讯，但是用户空间和内核空间是隔离开的，无法互相访问，他们之间传递数据需要借助copy_from_user和copy_to_user两个系统调用，把用户/内核空间内存中的数据拷贝到内核/用户空间的内存中，这样的话，如果两个进程需要进行一次单向通信则需要进行两次拷贝，如下图。 Binder单次通信只需要进行一次拷贝，因为它使用了内存映射，将一块物理内存（若干个物理页）分别映射到接收端用户空间和内核空间，达到用户空间和内核空间共享数据的目的。 发送端要向接收端发送数据时，内核直接通过copy_from_user将数据拷贝到内核空间映射区，此时由于共享物理内存，接收进程的内存映射区也就能拿到该数据了，如下图: 用户空间通过mmap系统调用，调用到Binder驱动中binder_mmap函数进行内存映射 Binder套件架构内核层的Binder驱动已经提供了IPC功能，不过还需要在framework native层提供一些对于驱动层的调用封装，使framework开发者更易于使用，由此封装出了native Binder；同时，由于framework native层是c/c++语言实现，对于应用开发者，需要更加方便的Java层的封装，衍生出Java Binder；最后在此之上，为了减少重复代码的编写和规范接口，在Java Binder的基础上又封装出了AIDL。经过层层封装，在使用者使用AIDL时对于Binder基本上是无感知的。 这里贴一张架构图。 Native层：BpBinder代表服务端Binder的一个代理，内部有一个成员mHandle就是服务端Binder在驱动层的句柄，客户端通过调用BpBinder::transact传入该句柄，经过驱动层和服务端BBinder产生会话，最后服务端会调用到BBinder::onTransact。在这里两者之间通过约定好的code来标识会话内容。 Java层：Java层是对native层的封装，本质没有什么区别，。 AIDL：AIDL生成的代码对于Binder进行了进一步封装，&lt;接口&gt;.Stub对应服务端Binder，&lt;接口&gt;.Stub.Proxy标识客户端，内部持有一个mRemote实例（BinderProxy），aidl根据定义的接口方法生成若干个TRANSACTION_&lt;函数名&gt; code常量，两端Binder通过这些code标识解析参数，调用相应接口方法。换言之AIDL就是对BinderProxy.transact和Binder.onTransact进行了封装，使用者不必再自己定义每次通讯的code以及参数解析。 RefBinder概述，快速了解Binder体系 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2022/02/10/android-binder-principle3/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AIDL","slug":"aidl","permalink":"http://agehua.github.io/tags/aidl/"},{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"}]},{"title":"android场景实现AOP编程","slug":"AOP-android","date":"2021-12-13T16:00:00.000Z","updated":"2024-12-05T09:41:25.311Z","comments":true,"path":"2021/12/14/AOP-android/","link":"","permalink":"http://agehua.github.io/2021/12/14/AOP-android/","excerpt":"我在很早之前就了解过面向切面（AOP）的编程思想，比如AspectJ 实现简单的切面编程，不过都快忘了 :(。本文是想探究AOP在Android环境中的使用，补全Android开发者的技能树。\n常见的AOP编程框架有AspectJ、 Cglib，Hibernate 和 Spring 等等，而这些目前流行的AOP框架绝大多数底层实现都是直接或间接地通过 ASM 来实现字节码操作，本文重点就来介绍一下ASM。","text":"我在很早之前就了解过面向切面（AOP）的编程思想，比如AspectJ 实现简单的切面编程，不过都快忘了 :(。本文是想探究AOP在Android环境中的使用，补全Android开发者的技能树。 常见的AOP编程框架有AspectJ、 Cglib，Hibernate 和 Spring 等等，而这些目前流行的AOP框架绝大多数底层实现都是直接或间接地通过 ASM 来实现字节码操作，本文重点就来介绍一下ASM。 ASM简介ASM是一个通用的Java字节码操作和分析框架，它可以用来修改现有的类或直接以二进制形式动态生成类。官网地址是：https://asm.ow2.io/ java字节码简单介绍由于 ASM 是直接对class文件的字节码进行操作，因此，要修改class文件内容时，也要注入相应的java字节码。 所以，在注入字节码之前，我们还需要了解下class文件的结构，JVM指令等知识。 1.class文件结构Java源文件经过javac编译器编译之后，将会生成对应的二进制.class文件 Java类文件是 8 位字节的二进制流。数据项按顺序存储在class文件中，相邻的项之间没有间隔，这使得class文件变得紧凑，减少存储空间。在Java类文件中包含了许多大小不同的项，由于每一项的结构都有严格规定，这使得 class 文件能够从头到尾被顺利地解析。 类结构体中所有的修饰符、字符常量和其他常量都被存储在class文件开始的一个常量堆栈(Constant Stack)中，其他结构体通过索引引用。 每个类必须包含headers（包括：class name, super class, interface, etc.）和常量堆栈（Constant Stack）其他元素，例如：字段（fields）、方法（methods）和全部属性（attributes）可以选择显示或者不显示。 每个字段块（Field section）包括名称、修饰符（public, private, etc.）、描述符号(descriptor)和字段属性。 每个方法区域（Method section）里面的信息与header部分的信息类似，信息关于最大堆栈（max stack）和最大本地变量数量（max local variable numbers）被用于修改字节码。对于非abstract和非native的方法有一个方法指令表，exceptions表和代码属性表。除此之外，还可以有其他方法属性。 每个类、字段、方法和方法代码的属性有属于自己的名称记录在类文件格式的JVM规范的部分，这些属性展示了字节码多方面的信息，例如源文件名、内部类、签名、代码行数、本地变量表和注释。JVM规范允许定义自定义属性，这些属性会被标准的VM（虚拟机）忽略，但是可以包含附件信息。 方法代码表包含一系列对java虚拟机的指令。有些指令在代码中使用偏移量，当指令从方法代码被插入或者移除时，全部偏移量的值可能需要调整。 2.Java类型与class文件内部类型对应关系Java类型分为基本类型和引用类型，在 JVM 中对每一种类型都有与之相对应的类型描述，如下表： Java type JVM Type descriptor boolean Z char C byte B short S int I float F long J double D Object Ljava/lang/Object; int[] [I Object[][] [[Ljava/lang/Object; 在 ASM 中要获得一个类的 JVM 内部描述，可以使用org.objectweb.asm.Type类中的getDescriptor(final Class c)方法，如下：public class TypeDescriptors &#123; public static void main(String[] args) &#123; System.out.println(Type.getDescriptor(TypeDescriptors.class)); System.out.println(Type.getDescriptor(String.class)); &#125; &#125; 运行结果：Lorg/victorzhzh/core/structure/TypeDescriptors; Ljava/lang/String; 3.Java方法声明与class文件内部声明的对应关系在Java的二进制文件中，方法的方法名和方法的描述都是存储在Constant pool 中的，且在两个不同的单元里。因此，方法描述中不含有方法名，只含有参数类型和返回类型。格式：(参数描述符)返回值描述符 Method declaration in source file Method descriptor void m(int i, float f) (IF)V int m(Object o) (Ljava/lang/Object;)I int[] m(int i, String s) (ILjava/lang/String;)[I Object m(int[] i) ([I]Ljava/lang/Object; String m() ()Ljava/lang/String; 上面3点，如果不熟悉字节码操作集合的话，写起来会很费劲，所以ASM为主流的IDE专门提供了开发插件BytecodeOutline： IDEA：ASM Bytecode Outline Eclipse：BytecodeOutline 以IDEA为例，只需要对应的类中右击-&gt;Show Bytecode outline即可 ASM 框架执行流程ASM对字节码的操作和分析都是基于访问者模式来实现，而访问者模式有两个核心类分别是：独立的访问者、接收访问者事件产生器对应的ASM里面就是两个核心类：ClassVisitor和ClassReader，下面分别进行介绍； 关于访问者模式的介绍，可以看这篇文章：访问者模式 ClassVisitorASM 内部采用 访问者模式 将 .class 类文件的内容从头到尾扫描一遍，每次扫描到类文件相应的内容时，都会调用ClassVisitor内部相应的方法。比如： 扫描到类文件时，会回调ClassVisitor的visit()方法； 扫描到类注解时，会回调ClassVisitor的visitAnnotation()方法； 扫描到类成员时，会回调ClassVisitor的visitField()方法； 扫描到类方法时，会回调ClassVisitor的visitMethod()方法；······扫描到相应结构内容时，会回调相应方法，该方法会返回一个对应的字节码操作对象（比如，visitMethod()返回MethodVisitor实例），通过修改这个对象，就可以修改class文件相应结构部分内容，最后将这个ClassVisitor字节码内容覆盖原来.class文件就实现了类文件的代码切入。 具体关系如下： 树形关系 使用的接口 Class ClassVisitor Field FieldVisitor Method MethodVisitor Annotation AnnotationVisitor 整个具体的执行时序如下图所示： 根据时序，上面所有方法都会被事件产生器ClassReader调用，所有方法中的参数都是ClassReader提供的 ClassReader此类主要功能就是读取字节码文件，然后把读取的数据通知ClassVisitor，字节码文件可以多种方式传入：public ClassReader(final InputStream inputStream)：字节流的方式；public ClassReader(final String className)：文件全路径；public ClassReader(final byte[] classFile)：二进制文件； 常见使用方式如下所示：ClassReader classReader = new ClassReader(\"com/zh/asm/TestService\");ClassWriter classVisitor = new ClassWriter(ClassWriter.COMPUTE_MAXS);classReader.accept(classVisitor, 0); ClassReader的accept方法处理接收一个访问者，还包括另外一个parsingOptions参数，选项包括： SKIP_CODE：跳过已编译代码的访问（如果您只需要类结构，这可能很有用）； SKIP_DEBUG：不访问调试信息，也不为其创建人工标签； SKIP_FRAMES：跳过堆栈映射帧； EXPAND_FRAMES：解压缩这些帧； ClassWriter以上实例中使用了ClassWriter，其继承于ClassVisitor，主要用来生成类，可以单独使用，如下所示：ClassWriter cw = new ClassWriter(0);cw.visit(V1_5, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE,\"pkg/Comparable\", null, \"java/lang/Object\",new String[]&#123;\"pkg/Mesurable\"&#125;);cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, \"LESS\",\"I\", null, new Integer(-1)).visitEnd();cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, \"EQUAL\",\"I\", null, new Integer(0)).visitEnd();cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, \"GREATER\",\"I\", null, new Integer(1)).visitEnd();cw.visitMethod(ACC_PUBLIC + ACC_ABSTRACT, \"compareTo\",\"(Ljava/lang/Object;)I\", null, null).visitEnd();cw.visitEnd();byte[] b = cw.toByteArray();//输出FileOutputStream fileOutputStream = new FileOutputStream(new File(\"F:/asm/Comparable.class\"));fileOutputStream.write(b);fileOutputStream.close(); 以上通过ClassWriter生成一个字节码文件，然后转换成字节数组，最后通过FileOutputStream输出到文件中，反编译结果如下：package pkg;public interface Comparable extends Mesurable &#123; int LESS = -1; int EQUAL = 0; int GREATER = 1; int compareTo(Object var1);&#125; 在实例化ClassWriter需要提供一个参数flags，选项包括： COMPUTE_MAXS：将为你计算局部变量与操作数栈部分的大小；还是必须调用 visitMaxs，但可以使用任何参数：它们将被忽略并重新计算；使用这一选项时，仍然必须自行计算这些帧； COMPUTE_FRAMES：一切都是自动计算；不再需要调用 visitFrame，但仍然必须调用 visitMaxs（参数将被忽略并重新计算）； 0：不会自动计算任何东西；必须自行计算帧、局部变量与操作数栈的大小； 以上只是对ClassWriter的单独使用，但更有意义的其实是把以上三个核心类整合起来使用，下面重点看看转换操作；转换操作在类读取器和类写入器之间引入一个 ClassVisitor，把三者整合起来，大致代码结构如下所示：ClassReader classReader = new ClassReader(\"com/zh/asm/TestService\");ClassWriter classWriter = new ClassWriter(ClassWriter.COMPUTE_MAXS);//处理ClassVisitor classVisitor = new AddFieldAdapter(classWriter...);classReader.accept(classVisitor, 0); 这里提供了一个添加属性的适配器，可以重写visitEnd方法，然后写入新的属性，代码如下：public class AddFieldAdapter extends ClassVisitor &#123; private int fAcc; private String fName; private String fDesc; //是否已经有相同名称的属性 private boolean isFieldPresent; public AddFieldAdapter(ClassVisitor cv, int fAcc, String fName, String fDesc) &#123; super(ASM4, cv); this.fAcc = fAcc; this.fName = fName; this.fDesc = fDesc; &#125; @Override public FieldVisitor visitField(int access, String name, String desc, String signature, Object value) &#123; //判断是否有相同名称的字段，不存在才会在visitEnd中添加 if (name.equals(fName)) &#123; isFieldPresent = true; &#125; return cv.visitField(access, name, desc, signature, value); &#125; @Override public void visitEnd() &#123; if (!isFieldPresent) &#123; FieldVisitor fv = cv.visitField(fAcc, fName, fDesc, null, null); if (fv != null) &#123; fv.visitEnd(); &#125; &#125; cv.visitEnd(); &#125;&#125; 根据ClassVisitor的每个方法被调用的顺序，如果类中有多个属性，那么visitField会被调用多次，每次都会检查要添加的字段是否已经有了，然后保存在isFieldPresent标识中，这样在访问最后的visitEnd中判断是否需要添加新属性；ClassVisitor classVisitor = new AddFieldAdapter(classWriter,ACC_PUBLIC + ACC_FINAL + ACC_STATIC,\"id\",\"I\"); 这里添加了一个public static final int id；可以把字节数组写入class类文件中，然后反编译查看：public class TestService &#123; public static final int id; ......&#125; visitField()方法返回了一个 FieldVisitor，它是一个抽象类，所以可以在 visitField() 方法中返回我们自己定义的 FieldVisitor 的实现类，去处理对应的逻辑；同理还有 MethodVisitor 几个常见的工具类介绍 TypeType对象表示一种 Java类型，既可以由类型描述符构造，也可以由Class对象构建；Type类还包含表示基元类型的静态变量； TraceClassVisitor扩展了ClassVisitor类，并构建了所访问类的文本表示；使用TraceClassVisitor以便获得实际生成内容的可读跟踪； CheckClassAdapterClassWriter 类并不会核实对其方法的调用顺序是否恰当，以及参数是否有效；因此有可能会生成一些被 Java 虚拟机验证器拒绝的无效类。为了尽可能提前检测出部分此类错误，可以使用CheckClassAdapter类 ； ASMifier这个类为TraceClassVisitor工具提供了一个可选的后端（默认情况下，它使用一个Textifier后端，产生上面显示的输出类型）。这个后端使TraceClassVisitor类的每个方法打印用于调用它的Java代码 LocalVariablesSorter继承自MethodVisitor，将一个方法中使用的局部变量按照它们在这个方法中的出现顺序重新进行编号，同时可以使用 newLocal 方法创建一个新的局部变量； AdviceAdapter继承自LocalVariablesSorter，此适配器是一个抽象类，可用于在方法的开头以及任何RETURN或ATHROW指令之前插入代码；其主要优点是它也适用于构造函数，其中代码不能仅插入构造函数的开头，而是在调用超级构造函数之后插入。 处理字节码的工具介绍完了，那android的插件如何将操作后的字节码打包的apk中呢？官方提供了一份在打包 dex 文件之前的编译过程中操作 .class 文件的api，那就是 AGP AGP(Android Gradle Plugin) 很早之前郭霖大神就写过一篇文章：Android Gradle高级用法，动态编译技术:Plugin Transform Javassist操作Class文件 文章中提到：gradle 从1.5开始，gradle 插件包含了一个叫 Transform 的 API，这个 API 允许第三方插件在 class 文件转为为 dex 文件前操作编译好的 class 文件，这个 API 的目标是简化自定义类操作，而不必处理 Task，并且在操作上提供更大的灵活性。 他文章里的transform依赖是这样compile 'com.android.tools.build:transform-api:1.5.0' 但是现在是这样//从2.0.0版本开始就是在gradle-api中了implementation 'com.android.tools.build:gradle-api:3.1.4' 关于Gradle版本和Gradle Plugin的版本，参考官方的介绍：gradle plugin版本说明，这里简单列出常见的几个版本： Gradle版本 Gradle Plugin版本 4.1+ 3.0.0+ 4.4+ 3.1.0+ 5.4.1+ 3.5.0 - 3.5.4 6.5+ 4.1.0+ 7.0+ 7.0 AGP 4.1 中移除了构建缓存，本文使用的AGP版本为 3.5.4 Gradle的架构 在最下层的是底层Gradle框架，它主要提供一些基础服务，如task的依赖，有向无环图的构建等 上面的则是Google编译工具团队的Android Gradle plugin框架，它主要是在Gradle框架的基础上，创建了很多与Android项目打包有关的task及artifacts 最上面的则是开发者自定义的Plugin，一般是在Android Gradle plugin提供的task的基础上，插入一些自定义的task，或者是增加Transform进行编译时代码注入 android plugin层语言选择：Google编译工具组从3.2.0开始，新增的插件全部都是用Kotlin编写的。 怎么查看官方的plugin都有哪些呢，在android studio Project视图 &gt; External libraries &gt; com.android.tools.build:gradle:x.x.x里，如下图： 如何创建Plugin我们后面再说，可以提前了解一点的是：官方和我们自己实现的plugin都是基于 org.gradle.api.Plugin 实现的，都需要提供一个类似 META-INF.gradle-plugins/xxx.properties 这样的配置文件，文件内容是需要指定 “implementation-class”的实现类是什么。 打开上图里的任意一个.properties文件，里面就是对应plugin实现类的地址 自定义Gradle PluginGradle支持通过插件的方式来扩展功能，已保证开发者可以按照自己的需求来完成自动化构建。而且Gradle插件允许已任何可以被编译成字节码的语言编写Gradle提供如下几个插件编写方式： Build Script我们可以在build脚本中直接完成插件代码的编写，这种方式缺点是只能在一个脚本中使用，优点是开发编译都很方便 buildSrc 工程除了应用程序工程，Gradle脚本同样也可以作为工程进行管理。默认情况下，Gradle会自动处理如下路径的插件源码，并添加到编译流程中：[Project_root]/buildSrc/src/main/groovy 这种方式整个app所有build脚本中都可以使用，但也仅限于本应用程序范畴 Standalone Project以独立工程实现，在这种情况下，插件JAR包存在，并支持在一个包中包含多个插件 根据Gradle规定，用户自定义的插件需要实现Plugin接口。当我们在build脚本中使用插件时，可以通过apply plugin:[PLUG_ID]来指明。然后Gradle会调用该插件中的apply方法：apply plugin: GreetingPluginclass GreetingPlugin implements Plugin&lt;Project&gt; &#123; void apply(Project project) &#123; project.task('hello') &lt;&lt; &#123; println \"Hello from the GreetingPlugin\" &#125; &#125;&#125; 这段代码用于添加一个名为”hello“的task，它的代码虽然简单，但是apply方法中传递了一个重要的类 org.gradle.api.Project，其他复杂的插件都是通过Project类来操作编译过程，达到对应的效果。下面是 Project 类的一些重要方法：// 根据name创建一个task，就是上面例子里的写法，还有好多同名方法，这里不一一列举了Task task(String name) throws InvalidUserDataException;// 根据一个工程路径，获得一个File对象，省略同名方法File file(Object path);// Adds a closure to be called immediately after this project has been evaluated.afterEvaluate​(Closure closure)//Returns the properties of this project.getProperties()// ... 其他方法的介绍可以看gradle 文档：https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html 如果我们不单只是创建一个Task去执行，还想在android编译过程中进行处理，则需要使用到Transform Api，像下面这种方式：AppExtension appExtension = (AppExtension)project.getProperties().get(\"android\");// 或者// AppExtension appExtension = project.extensions.getByType(AppExtension)//将自定义Transform添加到编译流程中appExtension.registerTransform(new MethodTimeTransform(project)); Transform ApiTransform 是专门处理构建过程中的中间产物，Transform 可以被看作是 Gradle 在编译项目时的一个 task，在 .class 文件转换成 .dex 的流程中会执行这些 task，对所有的 .class 文件（可包括第三方库的 .class）进行转换，转换的逻辑定义在 Transform 的 transform 方法中。实际上平时我们在 build.gradle 中常用的功能都是通过 Transform 实现的，比如混淆（proguard）、dexBuilder等。 篇幅有限，本文关于当前android上实现AOP编程就介绍到这里。关于Transform api的语法和具体例子可以看这篇文章：手把手教大家用Transform API和ASM实现一个防快速点击案例 Ref字节码增强技术探索 ASM教程：https://github.com/dengshiwei/asm-module ASM入门篇：https://segmentfault.com/a/1190000040160637 参考：https://juejin.cn/post/6844903616487096333 Android 进阶之路：ASM 修改字节码，这样学就对了！ 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/12/14/AOP-android/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AGP","slug":"agp","permalink":"http://agehua.github.io/tags/agp/"},{"name":"ASM","slug":"asm","permalink":"http://agehua.github.io/tags/asm/"},{"name":"Transform","slug":"transform","permalink":"http://agehua.github.io/tags/transform/"},{"name":"AOP","slug":"aop","permalink":"http://agehua.github.io/tags/aop/"}]},{"title":"移动view的几种方式总结","slug":"view-scroll-apis","date":"2021-08-06T16:00:00.000Z","updated":"2024-12-05T09:41:25.325Z","comments":true,"path":"2021/08/07/view-scroll-apis/","link":"","permalink":"http://agehua.github.io/2021/08/07/view-scroll-apis/","excerpt":"移动view的几种方式使用View.layout(l, t, r, b)方法\nAssign a size and position to a view and all of its descendants这个方法是用来指定一个view和它所有的子view的尺寸和位置","text":"移动view的几种方式使用View.layout(l, t, r, b)方法 Assign a size and position to a view and all of its descendants这个方法是用来指定一个view和它所有的子view的尺寸和位置This is the second phase of the layout mechanism. (The first is measuring). In this phase, each parent calls layout on all of its children to position them. This is typically done using the child measurements that were stored in the measure pass()这个是布局的第二阶段，第一阶段是 measure。这个阶段由父view调用每个子view的layout方法来定位子view。Derived classes should not override this method. Derived classes with children should override onLayout. In that method, they should call layout on each of their children.实现类不应该重写这个方法，而是应该重写 onLayout 方法，在onLayout方法中会调用实现类的各个子view的layout方法 这四个参数也都是相对于父视图来说的，layout的过程就是确定View在屏幕上显示的具体位置，在代码中就是设置其成员变量mLeft，mTop，mRight，mBottom的值，这几个值构成的矩形区域就是该View显示的位置，不过这里的具体位置都是相对于父视图的位置。 其中，mRight所指的是当前view的右边缘离父视图左边缘的距离（mLeft+自己的宽度），mBottom也是指当前view的下边缘离父视图的上边缘的距离 这种方式可以刷新页面，但是一旦调用requestLayout，会导致view回到最开始的位置，因为mTop、mLeft被重置了 使用View.setX()在 getX() 方法的注释上是这样说的： The visual x position of this view, in pixels. This is equivalent to the setTranslationX(float) translationX property plus the current getLeft() left property. 意思就是说获取到实际的View的x y 值，该值 getX = getLeft + getTraslationX，并且最后得出的值也是相对父视图来说的。 使用setTranslationX(float translationX) Sets the horizontal location of this view relative to its {@link #getLeft() left} position. This effectively positions the object post-layout, in addition to wherever the object’s layout placed it. param translationX: The horizontal position of this view relative to its left position, in pixels. translateX是相对于自身left属性来进行的平移，比如 left=20，此时调用setTranslationX(30)后，就是相对于left（而不是它上一次的translationX后的位置）往右平移30px，若此时再调用调用setTranslationX(40)，之前的30px值就被覆盖，改为相对于left右移40px。 这里水平方向上的X也是相对于父容器的当前View的位置，就像前面的等式所说，x = left + translationX；所以每一次setTranslationX都会导致getX值的变化，而left的值并不会改变，requestLayout也不会让view发生任何改变 使用View的offsetLeftAndRight(offset) Offset this view’s horizontal location by the specified amount of pixels. 垂直方向上使用 offsetTopAndBottom()。RecyclerView移动子view就是使用这两个方法，具体原理可以看我的这篇文章Recyclerview 滑动相关功能总结。本质上也是改变mTop、mLeft的值，但是要注意这个方法不能用在onTouch的MotionEvent.ACTION_MOVE事件上，会导致滑动距离加倍 改变LayoutParams的marginLayoutParams是相对于父布局而言，所以这种方式只能在父布局范围内移动view，如果父View内只有一个子view，推荐使用这种方式移动子viewsetmargins 相对父视图来实现移动，前提是不能跟其他子view发生关系需要手动调用 requestLayout 通知重绘 使用 setPadding(l, t, r, b)设置该view的内部缩进值(自己内部)，相对于Margin(相对于其他view或ViewGroup). 不推荐使用这种方式移动view，因为可能会造成View内部内容展示不全 利用View的scrollTo(x, y), scrollBy(x, y) Set the scrolled position of your view. This will cause a call to {@link #onScrollChanged(int, int, int, int)} and the view will be invalidated.这个方法修改的是View的两个成员变量mScrollX、mScrollY，然后触发了 invalidate，在View的onDraw()方法中会使用这两个成员变量来确定view的位置 注意这个方法的滑动方向与正常方向不同 比如如果从左向右滑动100px 那么 是scrollBy(-100,0)这两个方法有个致命的缺陷：它们滑动的是View里面的内容而不是View自身 也就是说如果用于ViewGroup中内容的滑动是可以的 但是如果用于让自身控件移动是不可以的 总结 建议优先使用LayoutParams的方式，前提是父View中只有这一个子View，否则会因margin属性的改变，导致其他子view无法正常显示 其次如果onTouch事件中实现view的移动，可以使用view.layout(l, t, r, b)方法 不是在onTouch事件中，可以使用属性动画setTranslationX 拓展贴一个跟随手指移动view的实现 1.使用layoutparams.setMargin方式（Kotlin） override fun onTouchEvent(event: MotionEvent): Boolean &#123; when (event.action) &#123; MotionEvent.ACTION_DOWN -&gt; &#123; if (null != mDragAnimSet &amp;&amp; mDragAnimSet!!.isRunning) &#123; mDragAnimSet!!.cancel() &#125; isPressed = true isDrag = false inputStartX = event.rawX.toInt() inputStartY = event.rawY.toInt() viewStartLeft = mFloatBallParams.leftMargin viewStartBottom = mFloatBallParams.bottomMargin &#125; MotionEvent.ACTION_MOVE -&gt; run &#123; val moveX: Int = event.rawX.toInt() - inputStartX val moveY: Int = event.rawY.toInt() - inputStartY if (mScreenWidth &lt; 0 || mScreenHeight &lt; 0) &#123; isDrag = false return@run &#125; if (abs(moveX) &gt; slop &amp;&amp; abs(moveY) &gt; slop) &#123; isDrag = true mFloatBallParams.leftMargin = viewStartLeft + moveX mFloatBallParams.bottomMargin = viewStartBottom - moveY layoutParams = mFloatBallParams &#125; else &#123; isDrag = false &#125; &#125; MotionEvent.ACTION_UP -&gt; &#123; if (isDrag) &#123; //恢复按压效果 isPressed = false &#125; //吸附贴边计算和动画 welt() &#125; else -&gt; &#123; &#125; &#125; return isDrag || super.onTouchEvent(event)&#125; 2.使用view.layout()方式 @Overridepublic boolean onTouch(View view, MotionEvent event) &#123; float dx, dy; switch (event.getAction()) &#123; case MotionEvent.ACTION_DOWN: startTouchX = event.getX(); startTouchY = event.getY(); circleImageLeft = circleImage.getLeft(); circleImageRight = circleImage.getRight(); break; case MotionEvent.ACTION_MOVE: dx = event.getX() - startTouchX; dy = event.getY() - startTouchY;/* 注意： 1. 这里不要用 (circleImage.getLeft() + dx)，因为每次layout之后已经改变了left的值，因此getLeft是已经更新后的值，这样将会导致dx全部累计，滑动使得view滑动的更快。 2. 一定要记得right也要跟着变，否则right不变的话，view将会被压缩或者拉伸。*/ circleImage.layout((int) (circleImageLeft + dx), circleImage.getTop(), (int) (circleImageRight + dx), circleImage.getBottom()); break; case MotionEvent.ACTION_UP: AppLog.e(\"ACTION_UP\"); break; case MotionEvent.ACTION_CANCEL: AppLog.e(\"ACTION_CANCEL\"); break; &#125; return true;&#125; MotionEvent.getX()、MotionEvent.getRawX()的区别MotionEvent的getX(),getY()是当前触摸点相对于设置此监听触摸事件的view的左边和顶部的距离。只有MotionEvent的getRawX(),getRawY()是绝对坐标。 getGlobalVisibleRect() 与 getLocalVisibleRect() 方法介绍getGlobalVisibleRect() 是view可见区域相对与屏幕来说的坐标位置.getLocalVisibleRect() 是view可见区域相对于自己坐标的位置. 一定要记清楚是可见区域. 详情查阅这篇文章 ：https://www.jianshu.com/p/2aa908f6a2e6 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/08/07/view-scroll-apis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"view scroll","slug":"view-scroll","permalink":"http://agehua.github.io/tags/view-scroll/"}]},{"title":"自定义gradle插件","slug":"gradle-plugin","date":"2021-07-17T16:00:00.000Z","updated":"2024-12-05T09:41:25.325Z","comments":true,"path":"2021/07/18/gradle-plugin/","link":"","permalink":"http://agehua.github.io/2021/07/18/gradle-plugin/","excerpt":"gradle和gradlew的区别如果配置好了 gradle 环境变量后,就可以在cmd中使用gradle命令了在cmd中输入： gradle -v","text":"gradle和gradlew的区别如果配置好了 gradle 环境变量后,就可以在cmd中使用gradle命令了在cmd中输入： gradle -v输出如下:------------------------------------------------------------Gradle 5.6.4------------------------------------------------------------ 但是有时候没有配置环境变量，却在Android项目根目录使用 gradlew 命令./gradlew -v 输出的版本和gradle-wrapper.properties文件中的版本一致 其实 gradlew是 gradle wrapper 的简写。Gradle wrapper 是Gradle的核心特性，能够让机器在没有安装Gradle运行时的情况下运行Gradle构建，也可以让构建脚本运行在一个指定的Gradle版本上。使用Wrapper被认为是最佳实践，这样在不同的机器上面，构建的版本就能够保证统一。使用了包装器的Gradle脚本非常适合作为自动化发布的一部分，比如持续集成。 我们每个Android项目的根目录下都有一个 gradlew的可执行文件，./gradlew 正是访问的这个文件 Gradle构建块每个Gradle构建都包含三个基本构建块：project、task、property。每个构建至少包含一个project，进而包含一个或者多个task。project和task暴露的属性可以用来控制构建。 Gradle使用的是领域驱动设计（DDD）的原理为其自己的领域构建软件建模。因此，在Gradle API中有相应的类来表示project和task。 Gradle API中有相应的类来表示project和task。这一点是要明确的，Gradle中的脚本实际上是转为代码来执行的。 项目Project在Gradle术语中，一个项目（project）代表一个正在构建的组件，比如一个JAR文件，或一个想要完成的目标，如部署应用程序。当构建进程启动后，Gradle基于build.gradle中的配置实例化org.gradle.api.Project接口，并且能够通过project变量使其隐式可用。 关于 Project 的介绍可以看这里: https://www.jianshu.com/p/434eba22561e 任务Task任务动作 task action，定义了一个当任务执行时最小的工作单元。任务依赖 task dependency，很多时候运行一个task之前需要运行另一个task。Gradle task对应的API是org.gradle.api.Task 接口。 关于 task更多的介绍可以看这里 https://www.jianshu.com/p/60bf794cdf91 属性 Property每个Project和Task实例都提供了可以通过getter和setter方法访问的属性。一个属性可能是一个任务的描述或者项目的版本。你也可以定义自己的属性。Gradle允许用户通过扩展属性自定义一些标量 Gradle 插件分类Gradle插件分为两类： 脚本插件，是一个普通的Gradle构建脚本，它可以被导入到其它的构建脚本中。对象插件，需要实现org.gradle.api.Plugin接口。1 使用脚本插件假设我们有一个脚本名为 sayhello.gradle ，它里面有一个task：task sayHello &lt;&lt; &#123; println 'hello world'&#125; 然后我们在build.gradle 中依赖这个外部脚本，调用Project的apply方法，apply方法调用时传入from属性，它的值可以是任何类型的URL，比如HTTP地址。apply from: 'sayhello.gradle' 此时我们运行gradle sayHello 命令，可以看到sayHello 这个task执行了：:sayHellohello world 通过apply from的方式引入脚本插件，就好像那个脚本插件中的内容是写在当前的build.gradle中一样。它是使用比较简单，这里就不多做介绍了。 对象插件我们之前讲了自定义的task，它的实现逻辑是一种可维护、可测试的解决方案。通过打包成jar文件，task可以在独立的项目中被重用。然而，该方式仍有一些限制。优点： 定制逻辑在类中是自包含的，并且可以通过增强型task配置 通过将task属性用注解标志可以支持声明式增量构建 自定义的task可以测试缺点： 自定义的task仅仅暴露独立的工作单元。所提供的额外的公式化代码、约定和生命周期的整合并不是很直接 自定义的task仅仅能通过增强型task来配置。通过自定义的DSL，缺乏有表达性的扩展机制 其他插件的功能不容易使用或扩展 而使用对象插件的方式，可以给你最大的灵活性去封装高复杂度的逻辑，并且提供一种强大的扩展机制可以在构建脚本中定制它的行为。比如编译Java代码，我们会通过一句话来引入Java插件：apply plugin :&apos;java&apos; 然后我们还可以配置很多属性来控制编译逻辑。这个Java插件就是一个对象插件。 对象插件的实现方式对于实现一个对象插件，有4个基本元素是非常重要的。 在放置插件实现的位置方面Gradle给你完全的灵活性。代码可以放在构建脚本中或者buildSrc目录下，也可以作为一个独立的工程被开发并且以jar文件方式发布。 每个插件都需要提供一个实现类，它代表着插件的入口点。插件可以用任何JVM语言编写并编译成字节码。 应用到项目中的插件可以通过暴露出来的扩展对象进行定制。如果用户想要在构建脚本中覆盖插件的默认配置时，这一点特别有用。 插件描述符是一个属性文件，它包含了关于插件的元信息。通常，它包含有插件的简短名字和插件实现类的映射。 编写插件编写一个插件最低的要求是提供org.gradle.api.Plugin&lt;T&gt;接口的一个实现类。该接口仅仅定义了一个简单的方法：apply(T target)。 现在我们来演示自定义一个插件，这个插件的作用是提供一个task来打印用户凭证。我们前面已经提到，自定义对象插件和自定义task方式类似，代码可以放在构建脚本中或者buildSrc目录下，也可以作为一个独立的工程被开发并且以JAR文件方式发布，下面我们根据这三种方式来分别演示如何自定义和使用插件。 放在构建脚本中在build.gradle中，代码如下：apply plugin:CredentialPluginuserCredential&#123; username='admin' password='000000'&#125;class CredentialPlugin implements Plugin&lt;Project&gt;&#123; @Override void apply(Project project)&#123; project.extensions.create('userCredential',CredentialExtension) project.tasks.create('printUserCredential') &lt;&lt; &#123; println \"username is: \" + project.userCredential.username println \"password is: \" + project.userCredential.password &#125; &#125;&#125;//扩展模型class CredentialExtension &#123; String username String password&#125; Gradle将语言结构化模型作为扩展，扩展可以被添加到许多Gradle对象中，如果一个类实现了org.gradle.api.plugins.ExtensionAware接口，比如Project或者Task，就认为它是扩展可知的。每个扩展都是一个数据模型，它是扩展的基础。这个模型可以是一个POJO或者Groovy Bean。 在上面的代码中，userCredential闭包中的内容，可以从构建脚本中给task提供所需要的属性值，这个userCredential就是我们暴露的一个DSL。ExtensionAware对象有一个方法getExtensions()，该方法返回一个ExtensionContainer对象，ExtensionContainer对象可以通过create()方法来注册我们的扩展，也就是把我们配置的DSL和具体的类关联起来。在本例中就是把userCredential这个闭包和CredentialExtension这个类关联起来，这就是插件的扩展机制。 扩展对象vs额外属性 被用来扩展一个对象的DSL的扩展是扩展可知的，一个已注册的扩展模型会暴露一些属性和方法，用来给构建脚本建立新的构建语言结构，这些属性名和方法在创建的时候已经定好。扩展模型的典型用例是插件。额外属性，是一些通过ext命名空间创建的简单变量，它们一般提供给用户空间也就是构建脚本使用，额外属性的属性名是可以任意指定的。请尽量避免在插件实现中使用额外属性。 放在buildSrc目录下与自定义task一样，Groovy代码放在buildSrc/src/main/groovy 目录下，package com.sososeen.credentialimport org.gradle.api.Pluginimport org.gradle.api.Projectclass CredentialPlugin implements Plugin&lt;Project&gt;&#123; @Override void apply(Project project)&#123; ... &#125;&#125;package com.sososeen.credentialclass CredentialExtension &#123; ...&#125; 在与buildSrc同级的目录下，创建build.gradle脚本，引入这个plugin：apply plugin:com.sososeen.credential.CredentialPluginuserCredential&#123; username='admin' password='000000'&#125; 然后执行 gradle printUserCredential 命令，可以看到打印结果：:printUserCredentialusername is: adminpassword is: 000000 可以看到，我们引入这个插件的时候是把它的包名带类名写上了，这显得太长了，不好写。我们可以给这个插件一个有意义且精简的名字。在src/main/resources/META-INF/gradle-plugins目录下，我们可以创建一个属性文件来配置。比如创建一个credentials.properties，它就是一个插件描述符，暴露了插件名字是credentials。在这个文件中，将该插件类的全局类名赋值给键implemention-class，如下：implementation-class = com.sososeen.credential.CredentialPlugin 然后应用插件就可以这样子：apply plugin : 'credentials' 执行 gradle printUserCredential 命令，可以看到打印结果与之前一样。 以jar文件形式提供插件这个步骤与自定义task打包为jar文件一样，新建一个项目，把buildSrc目录下的文件复制过来，同时，在该项目下创建一个build.gradle文件。apply plugin: 'groovy' //应用这个插件来编译Groovy代码apply plugin: 'maven'version = '1.0'group = 'com.sososeen09'archivesBaseName = 'credential'repositories &#123; mavenCentral()&#125;dependencies &#123; // 使用Gradle中的API需要这个 compile gradleApi()&#125;uploadArchives &#123; repositories &#123; mavenDeployer &#123; repository(url: \"file:../lib\") &#125; &#125;&#125; 执行gradle uploadArchives命令后就可以看到，在与当前项目同级的lib文件目录中生成了我们期望的jar文件。 我们再新建一个工程，这个工程中有一个脚本文件build.gradle:apply plugin : 'credentials'buildscript &#123; repositories &#123; maven &#123; url 'file:../lib' &#125; &#125; dependencies &#123; classpath 'com.sososeen09:credential:1.0' &#125;&#125;userCredential&#123; username='admin' password='000000'&#125; 执行 gradle printUserCredential 命令，可以看到打印结果与之前一样。 REFhttps://www.jianshu.com/p/158851436e82 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/07/18/gradle-plugin/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gradle","slug":"gradle","permalink":"http://agehua.github.io/tags/gradle/"},{"name":"AGP","slug":"agp","permalink":"http://agehua.github.io/tags/agp/"}]},{"title":"RecyclerView 缓存机制","slug":"recyclerview-cache","date":"2021-07-17T16:00:00.000Z","updated":"2024-12-05T09:41:25.323Z","comments":true,"path":"2021/07/18/recyclerview-cache/","link":"","permalink":"http://agehua.github.io/2021/07/18/recyclerview-cache/","excerpt":"RecyclerView 内存性能优越，这得益于它独特的缓存机制\n由问题引入\n回收的是什么？复用什么？\n回收到哪里去？从哪里获得复用？\n什么时候回收？什么时候复用？","text":"RecyclerView 内存性能优越，这得益于它独特的缓存机制 由问题引入 回收的是什么？复用什么？ 回收到哪里去？从哪里获得复用？ 什么时候回收？什么时候复用？ 从addView()开始RecyclerView继承自 ViewGroup，遂以RecyclerView.addView()为切入点向上搜寻复用的代码。在RecyclerView.java中全局搜索“addView”，发现RecyclerView()并没有对addView()函数重载，但找到一处addView()的调用： //RecyclerView是ViewGroup的子类public class RecyclerView extends ViewGroup implements ScrollingView, NestedScrollingChild2 &#123; ... private void initChildrenHelper() &#123; mChildHelper = new ChildHelper(new ChildHelper.Callback() &#123; ... @Override public void addView(View child, int index) &#123; if (VERBOSE_TRACING) &#123; TraceCompat.beginSection(\"RV addView\"); &#125; //直接调用ViewGroup.addView() RecyclerView.this.addView(child, index); if (VERBOSE_TRACING) &#123; TraceCompat.endSection(); &#125; dispatchChildAttached(child); &#125; &#125; &#125; ...&#125; 以ChildHelper.Callback.addView()为起点沿着调用链继续向上搜寻，经历了如下方法调用： ChildHelper.addView() LayoutManager.addViewInt() LayoutManager.addView() LinearLayoutManager.layoutChunk()： void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) &#123; //获得下一个表项 View view = layoutState.next(recycler); ... LayoutParams params = (LayoutParams) view.getLayoutParams(); if (layoutState.mScrapList == null) &#123; //将表项插入到列表中 if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) &#123; addView(view); &#125; else &#123; addView(view, 0); &#125; &#125; ...&#125; addView(view)中传入的view是函数layoutState.next()的返回值。猜测该函数是用来获得下一个表项的。表项不止一个，应该有一个循环不断的获得下一个表项才对。果然layoutChunk在 fill() 方法的 while 循环中被调用 public class LinearLayoutManager extends RecyclerView.LayoutManager implements ItemTouchHelper.ViewDropHandler, RecyclerView.SmoothScroller.ScrollVectorProvider &#123; ... int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) &#123; ... //recyclerview 剩余空间 int remainingSpace = layoutState.mAvailable + layoutState.mExtra; LayoutChunkResult layoutChunkResult = mLayoutChunkResult; //不断填充，直到空间消耗完毕 while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; layoutChunkResult.resetInternal(); if (VERBOSE_TRACING) &#123; TraceCompat.beginSection(\"LLM LayoutChunk\"); &#125; //填充一个表项 layoutChunk(recycler, state, layoutState, layoutChunkResult); ... &#125; ... &#125;&#125; 而fill()是在onLayoutChildren()中被调用：/** * Lay out all relevant child views from the given adapter. * 布局所有给定adapter中相关孩子视图 */public void onLayoutChildren(Recycler recycler, State state) &#123; Log.e(TAG, \"You must override onLayoutChildren(Recycler recycler, State state) \");&#125; 看完注释，感觉前面猜测应该是正确的。onLayoutChildren()是用来布局RecyclerView中所有的表项的。 回头去看一下layoutState.next()，表项复用逻辑应该就在其中.public class LinearLayoutManager &#123; static class LayoutState &#123; /** * Gets the view for the next element that we should layout. * 获得下一个元素的视图用于布局 */ View next(RecyclerView.Recycler recycler) &#123; if (mScrapList != null) &#123; return nextViewFromScrapList(); &#125; //调用了Recycler.getViewForPosition() final View view = recycler.getViewForPosition(mCurrentPosition); mCurrentPosition += mItemDirection; return view; &#125; &#125;&#125; 最终调用了Recycler.getViewForPosition()，Recycler是回收器的意思，感觉离想要找的“复用”逻辑越来越近了。 Recycler到底是做什么用的？public class RecyclerView &#123; /** * A Recycler is responsible for managing scrapped or detached item views for reuse. * Recycler负责管理scrapped和detached表项的复用 */ public final class Recycler &#123; ... &#125;&#125; 终于找到你~~ ，Recycler用于表项的复用！沿着Recycler.getViewForPosition()的调用链继续向下搜寻，找到了一个关键函数（函数太长了，为了防止头晕，只列出了关键节点）public class RecyclerView &#123; public final class Recycler &#123; /** * Attempts to get the ViewHolder for the given position, either from the Recycler scrap, * cache, the RecycledViewPool, or creating it directly. * 尝试获得指定位置的ViewHolder，要么从scrap，cache，RecycledViewPool中获取，要么直接重新创建 */ @Nullable ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... boolean fromScrapOrHiddenOrCache = false; ViewHolder holder = null; //0 从changed scrap集合中获取ViewHolder if (mState.isPreLayout()) &#123; holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; &#125; //1. 通过position从attach scrap或一级回收缓存中获取ViewHolder if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); ... &#125; if (holder == null) &#123; ... final int type = mAdapter.getItemViewType(offsetPosition); //2. 通过id在attach scrap集合和一级回收缓存中查找viewHolder if (mAdapter.hasStableIds()) &#123; holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition), type, dryRun); ... &#125; //3. 从自定义缓存中获取ViewHolder if (holder == null &amp;&amp; mViewCacheExtension != null) &#123; // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension .getViewForPositionAndType(this, position, type); ... &#125; //4.从缓存池中拿ViewHolder if (holder == null) &#123; // fallback to pool ... holder = getRecycledViewPool().getRecycledView(type); ... &#125; //所有缓存都没有命中，只能创建ViewHolder if (holder == null) &#123; ... holder = mAdapter.createViewHolder(RecyclerView.this, type); ... &#125; &#125; boolean bound = false; if (mState.isPreLayout() &amp;&amp; holder.isBound()) &#123; // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; &#125; //只有invalid的viewHolder才能绑定视图数据 else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; final int offsetPosition = mAdapterHelper.findPositionOffset(position); //获得ViewHolder后，绑定视图数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125; ... return holder; &#125; &#125;&#125; 函数的名字以“tryGet”开头，“尝试获得”表示可能获得失败，再结合注释中说的：“尝试获得指定位置的ViewHolder，要么从scrap，cache，RecycledViewPool中，要么直接重新创建。”猜测scrap，cache，RecycledViewPool是回收表项的容器，相当于表项缓存，如果缓存未命中则只能重新创建。 函数的返回值是ViewHolder，难道回收和复用的是ViewHolder? 函数开头声明了局部变量ViewHolder holder = null;最终返回的也是这个局部变量，并且有4处holder == null的判断，这样的代码结构是不是有点像缓存？每次判空意味着上一级缓存未命中并继续尝试新的获取方法？缓存是不是有不止一种存储形式？ 让我们一次一次地看： 第一次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (mState.isPreLayout()) &#123; holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; &#125; ...&#125; 只有在mState.isPreLayout()为true时才会做这次尝试，这应该是一种特殊情况，先忽略。 第二次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); //下面一段代码蕴含着一个线索，买个伏笔，先把他略去 ... &#125; ...&#125; 当第一次尝试失败后，尝试通过getScrapOrHiddenOrCachedHolderForPosition()获得ViewHolder。这里故意省略了一段代码，先埋个伏笔，待会分析。先沿着获取ViewHolder的调用链继续往下：//省略非关键代码 /** * Returns a view for the position either from attach scrap, hidden children, or cache. * 从attach scrap，hidden children或者cache中获得指定位置上的一个ViewHolder */ ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) &#123; final int scrapCount = mAttachedScrap.size(); // Try first for an exact, non-invalid match from scrap. //1.在attached scrap中搜索ViewHolder for (int i = 0; i &lt; scrapCount; i++) &#123; final ViewHolder holder = mAttachedScrap.get(i); if (!holder.wasReturnedFromScrap() &amp;&amp; holder.getLayoutPosition() == position &amp;&amp; !holder.isInvalid() &amp;&amp; (mState.mInPreLayout || !holder.isRemoved())) &#123; holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP); return holder; &#125; &#125; //2.从移除屏幕的视图中搜索ViewHolder，找到了之后将他存入scrap回收集合中 if (!dryRun) &#123; View view = mChildHelper.findHiddenNonRemovedView(position); if (view != null) &#123; final ViewHolder vh = getChildViewHolderInt(view); mChildHelper.unhide(view); int layoutIndex = mChildHelper.indexOfChild(view); ... mChildHelper.detachViewFromParent(layoutIndex); scrapView(view); vh.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP | ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST); return vh; &#125; &#125; // Search in our first-level recycled view cache. //3.在缓存中搜索ViewHolder final int cacheSize = mCachedViews.size(); for (int i = 0; i &lt; cacheSize; i++) &#123; final ViewHolder holder = mCachedViews.get(i); //若找到ViewHolder，还需要对ViewHolder的索引进行匹配判断 if (!holder.isInvalid() &amp;&amp; holder.getLayoutPosition() == position) &#123; ... return holder; &#125; &#125; return null; &#125; 依次从三个地方搜索ViewHolder：1. mAttachedScrap 2. 隐藏表项 3. mCachedViews，找到立即返回。其中mAttachedScrap和mCachedViews作为Recycler的成员变量，用来存储一组ViewHolder：public final class Recycler &#123; final ArrayList&lt;ViewHolder&gt; mAttachedScrap = new ArrayList&lt;&gt;(); ... final ArrayList&lt;ViewHolder&gt; mCachedViews = new ArrayList&lt;ViewHolder&gt;(); ... RecycledViewPool mRecyclerPool;&#125; 看到这里应该可以初步得出结论：RecyclerView回收机制中，回收复用的对象是ViewHolder，且以ArrayList为结构存储在Recycler对象中。 RecycledViewPool mRecyclerPool; 看着也像是回收容器，那待会是不是也会到这里拿 ViewHolder? 值得注意的是，当成功从mCachedViews中获取ViewHolder对象后，还需要对其索引进行判断，这就意味着 mCachedViews中缓存的ViewHolder只能复用于指定位置 ，打个比方：手指向上滑动，列表向下滚动，第2个表项移出屏幕，第4个表项移入屏幕，此时再滑回去，第2个表项再次出现，这个过程中第4个表项不能复用被回收的第2个表项的ViewHolder，因为他们的位置不同，而再次进入屏幕的第2个表项就可以成功复用。 待会可以对比一下其他复用是否也需要索引判断 回到刚才埋下的伏笔，把第二次尝试获取ViewHolder的代码补全：ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); //下面一段代码蕴含这一个线索，买个伏笔，先把他略去 if (holder != null) &#123; //检验ViewHolder有效性 if (!validateViewHolderForOffsetPosition(holder)) &#123; // recycle holder (and unscrap if relevant) since it can not be used if (!dryRun) &#123; // we would like to recycle this but need to make sure it is not used by // animation logic etc. holder.addFlags(ViewHolder.FLAG_INVALID); if (holder.isScrap()) &#123; removeDetachedView(holder.itemView, false); holder.unScrap(); &#125; else if (holder.wasReturnedFromScrap()) &#123; holder.clearReturnedFromScrapFlag(); &#125; //若不满足有效性检验，则回收ViewHolder recycleViewHolderInternal(holder); &#125; holder = null; &#125; else &#123; fromScrapOrHiddenOrCache = true; &#125; &#125; &#125; ...&#125; 如果成功获得ViewHolder则检验其有效性，若检验失败则将其回收。好不容易获取了ViewHoler对象，一言不合就把他回收？难道对所有复用的 ViewHolder 都有这么严格的检验吗？ 暂时无法回答这些疑问，还是先把复用逻辑看完吧： 第三次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... //只有当Adapter设置了id，才会进行这次查找 if (mAdapter.hasStableIds()) &#123; holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),type, dryRun); if (holder != null) &#123; // update position holder.mPosition = offsetPosition; fromScrapOrHiddenOrCache = true; &#125; &#125; ...&#125; 这一次尝试调用的函数名（“byId”）和上一次（“byPosition”）只是后缀不一样。上一次是通过表项位置，这一次是通过表项id。内部实现也几乎一样，判断的依据从表项位置变成表项id。为表项设置id属于特殊情况，先忽略。 第四次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null &amp;&amp; mViewCacheExtension != null) &#123; // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension.getViewForPositionAndType(this, position, type); if (view != null) &#123; //获得view对应的ViewHolder holder = getChildViewHolder(view); if (holder == null) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view which does not have a ViewHolder\" + exceptionLabel()); &#125; else if (holder.shouldIgnore()) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view that is ignored. You must call stopIgnoring before\" + \" returning this view.\" + exceptionLabel()); &#125; &#125; &#125; ...&#125; 经过从mAttachedScrap和mCachedViews获取ViewHolder未果后，继续尝试通过ViewCacheExtension 获取：/** * ViewCacheExtension is a helper class to provide an additional layer of view caching that can * be controlled by the developer. * ViewCacheExtension提供了额外的表项缓存层，用户帮助开发者自己控制表项缓存 * &lt;p&gt; * When &#123;@link Recycler#getViewForPosition(int)&#125; is called, Recycler checks attached scrap and * first level cache to find a matching View. If it cannot find a suitable View, Recycler will * call the &#123;@link #getViewForPositionAndType(Recycler, int, int)&#125; before checking * &#123;@link RecycledViewPool&#125;. * 当Recycler从attached scrap和first level cache中未能找到匹配的表项时，它会在去RecycledViewPool中查找之前，先尝试从自定义缓存中查找 * &lt;p&gt; */public abstract static class ViewCacheExtension &#123; /** * Returns a View that can be binded to the given Adapter position. * &lt;p&gt; * This method should &lt;b&gt;not&lt;/b&gt; create a new View. Instead, it is expected to return * an already created View that can be re-used for the given type and position. * If the View is marked as ignored, it should first call * &#123;@link LayoutManager#stopIgnoringView(View)&#125; before returning the View. * &lt;p&gt; * RecyclerView will re-bind the returned View to the position if necessary. */ public abstract View getViewForPositionAndType(Recycler recycler, int position, int type);&#125; 注释揭露了很多信息：ViewCacheExtension用于开发者自定义表项缓存，且这层缓存的访问顺序位于mAttachedScrap和mCachedViews之后，RecycledViewPool 之前。这和Recycler.tryGetViewHolderForPositionByDeadline()中的代码逻辑一致，那接下来的第五次尝试，应该是从 RecycledViewPool 中获取 ViewHolder 第五次尝试ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; ... //从回收池中获取ViewHolder对象 holder = getRecycledViewPool().getRecycledView(type); if (holder != null) &#123; holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) &#123; invalidateDisplayListInt(holder); &#125; &#125; &#125; ...&#125; 前四次尝试都未果，最后从RecycledViewPool 中获取ViewHolder。稍等片刻！相对于从mAttachedScrap 和 mCachedViews 中获取 ViewHolder，此处并没有严格的检验逻辑。为啥要区别对待不同的缓存？ 大大的问号悬在头顶，但现在暂时无法解答，还是接着看RecycledViewPool 的结构吧~public final class Recycler &#123; ... RecycledViewPool mRecyclerPool; //获得RecycledViewPool实例 RecycledViewPool getRecycledViewPool() &#123; if (mRecyclerPool == null) &#123; mRecyclerPool = new RecycledViewPool(); &#125; return mRecyclerPool; &#125; ...&#125;public static class RecycledViewPool &#123; ... //从回收池中获取ViewHolder对象 public ViewHolder getRecycledView(int viewType) &#123; final ScrapData scrapData = mScrap.get(viewType); if (scrapData != null &amp;&amp; !scrapData.mScrapHeap.isEmpty()) &#123; final ArrayList&lt;ViewHolder&gt; scrapHeap = scrapData.mScrapHeap; return scrapHeap.remove(scrapHeap.size() - 1); &#125; return null; &#125; ...&#125; 函数中只要访问了类成员变量，它的复杂度就提高了，因为类成员变量的作用于超出了函数体，使得函数就和类中其他函数耦合，所以不得不进行阅读更多以帮助理解该函数： public static class RecycledViewPool &#123; //同类ViewHolder缓存个数上限 private static final int DEFAULT_MAX_SCRAP = 5; /** * Tracks both pooled holders, as well as create/bind timing metadata for the given type. * 回收池中存放单个类型ViewHolder的容器 */ static class ScrapData &#123; //同类ViewHolder存储在ArrayList中 ArrayList&lt;ViewHolder&gt; mScrapHeap = new ArrayList&lt;&gt;(); //每种类型的ViewHolder最多存5个 int mMaxScrap = DEFAULT_MAX_SCRAP; &#125; //回收池中存放所有类型ViewHolder的容器 SparseArray&lt;ScrapData&gt; mScrap = new SparseArray&lt;&gt;(); ... //ViewHolder入池 按viewType分类入池，一个类型的ViewType存放在一个ScrapData中 public void putRecycledView(ViewHolder scrap) &#123; final int viewType = scrap.getItemViewType(); final ArrayList&lt;ViewHolder&gt; scrapHeap = getScrapDataForType(viewType).mScrapHeap; //如果超限了，则放弃入池 if (mScrap.get(viewType).mMaxScrap &lt;= scrapHeap.size()) &#123; return; &#125; if (DEBUG &amp;&amp; scrapHeap.contains(scrap)) &#123; throw new IllegalArgumentException(\"this scrap item already exists\"); &#125; scrap.resetInternal(); //回收时，ViewHolder从列表尾部插入 scrapHeap.add(scrap); &#125; //从回收池中获取ViewHolder对象 public ViewHolder getRecycledView(int viewType) &#123; final ScrapData scrapData = mScrap.get(viewType); if (scrapData != null &amp;&amp; !scrapData.mScrapHeap.isEmpty()) &#123; final ArrayList&lt;ViewHolder&gt; scrapHeap = scrapData.mScrapHeap; //复用时，从列表尾部获取ViewHolder（优先复用刚入池的ViewHoler） return scrapHeap.remove(scrapHeap.size() - 1); &#125; return null; &#125;&#125; 上述代码列出了RecycledViewPool 中最关键的一个成员变量和两个函数。至此可以得出结论：RecycledViewPool中的ViewHolder存储在SparseArray中，并且按viewType分类存储（即是Adapter.getItemViewType()的返回值），同一类型的ViewHolder存放在ArrayList 中，且默认最多存储5个。 相比较于mCachedViews，从mRecyclerPool中成功获取ViewHolder对象后并没有做合法性和表项位置校验，只检验viewType是否一致。所以从mRecyclerPool中取出的ViewHolder只能复用于相同viewType的表项。 创建ViewHolder并绑定数据ViewHolder tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) &#123; ... //所有缓存都没有命中，只能创建ViewHolder if (holder == null) &#123; ... holder = mAdapter.createViewHolder(RecyclerView.this, type); ... &#125; ... boolean bound = false; if (mState.isPreLayout() &amp;&amp; holder.isBound()) &#123; // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; &#125; //如果表项没有绑定过数据 或 表项需要更新 或 表项无效 且表项没有被移除时绑定表项数据 else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; if (DEBUG &amp;&amp; holder.isRemoved()) &#123; throw new IllegalStateException(\"Removed holder should be bound and it should\" + \" come here only in pre-layout. Holder: \" + holder + exceptionLabel()); &#125; final int offsetPosition = mAdapterHelper.findPositionOffset(position); //为表项绑定数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125;&#125; 再进行了上述所有尝试后，如果依然没有获得ViewHolder，只能重新创建并绑定数据。沿着调用链往下，就会找到熟悉的onCreateViewHolder()和onBindViewHolder()。 绑定数据的逻辑嵌套在一个大大的if中（原来并不是每次都要绑定数据，只有满足特定条件时才需要绑定） 那什么情况下需要绑定，什么情况下不需要呢？这就要引出“缓存优先级”这个概念。 缓存优先级缓存有优先级一说，在使用图片二级缓存（内存+磁盘）时，会先尝试去优先级高的内存中获取，若未命中再去磁盘中获取。优先级越高意味着性能越好。RecyclerView的缓存机制中是否也能套用“缓存优先级”这一逻辑？ 虽然为了获取ViewHolder做了5次尝试（共从6个地方获取），先排除3种特殊情况，即从mChangedScrap获取、通过id获取、从自定义缓存获取，正常流程中只剩下3种获取方式，优先级从高到低依次是： 1.从mAttachedScrap获取 2.从mCachedViews获取 3.从mRecyclerPool 获取 这样的缓存优先级是不是意味着，对应的复用性能也是从高到低？（复用性能越好意味着所做的昂贵操作越少） 最坏情况：重新创建ViewHodler并重新绑定数据 次好情况：复用ViewHolder但重新绑定数据 最好情况：复用ViewHolder且不重新绑定数据 毫无疑问，所有缓存都未命中的情况下会发生最坏情况。剩下的两种情况应该由3种获取方式来分摊，猜测优先级最低的 mRecyclerPool 方式应该命中次好情况，而优先级最高的 mAttachedScrap 应该命中最好情况，去源码中验证一下： ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position, boolean dryRun) &#123; final int scrapCount = mAttachedScrap.size(); // Try first for an exact, non-invalid match from scrap. //1.从attached scrap回收集合中 for (int i = 0; i &lt; scrapCount; i++) &#123; final ViewHolder holder = mAttachedScrap.get(i); //只有当holder是有效时才返回 if (!holder.wasReturnedFromScrap() &amp;&amp; holder.getLayoutPosition() == position &amp;&amp; !holder.isInvalid() &amp;&amp; (mState.mInPreLayout || !holder.isRemoved())) &#123; holder.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP); return holder; &#125; &#125;&#125;ViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; ... if (holder == null) &#123; ... //从回收池中获取ViewHolder对象 holder = getRecycledViewPool().getRecycledView(type); if (holder != null) &#123; //重置ViewHolder holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) &#123; invalidateDisplayListInt(holder); &#125; &#125; &#125; ... //如果表项没有绑定过数据 或 表项需要更新 或 表项无效 且表项没有被移除时绑定表项数据 else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; if (DEBUG &amp;&amp; holder.isRemoved()) &#123; throw new IllegalStateException(\"Removed holder should be bound and it should\" + \" come here only in pre-layout. Holder: \" + holder + exceptionLabel()); &#125; final int offsetPosition = mAdapterHelper.findPositionOffset(position); //为表项绑定数据 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125; ...&#125;public abstract static class ViewHolder &#123; /** * This ViewHolder has been bound to a position; mPosition, mItemId and mItemViewType * are all valid. * 绑定标志位 */ static final int FLAG_BOUND = 1 &lt;&lt; 0; /** * This ViewHolder’s data is invalid. The identity implied by mPosition and mItemId * are not to be trusted and may no longer match the item view type. * This ViewHolder must be fully rebound to different data. * 无效标志位 */ static final int FLAG_INVALID = 1 &lt;&lt; 2; //判断ViewHolder是否无效 boolean isInvalid() &#123; //将当前ViewHolder对象的flag和无效标志位做位与操作 return (mFlags &amp; FLAG_INVALID) != 0; &#125; //判断ViewHolder是否被绑定 boolean isBound() &#123; //将当前ViewHolder对象的flag和绑定标志位做位与操作 return (mFlags &amp; FLAG_BOUND) != 0; &#125; /** * 将ViewHolder重置 */ void resetInternal() &#123; //将ViewHolder的flag置0 mFlags = 0; mPosition = NO_POSITION; mOldPosition = NO_POSITION; mItemId = NO_ID; mPreLayoutPosition = NO_POSITION; mIsRecyclableCount = 0; mShadowedHolder = null; mShadowingHolder = null; clearPayload(); mWasImportantForAccessibilityBeforeHidden = ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_AUTO; mPendingAccessibilityState = PENDING_ACCESSIBILITY_STATE_NOT_SET; clearNestedRecyclerViewIfNotNested(this); &#125;&#125; 温故知新，回看 mRecyclerPool 复用逻辑时，发现在成功获得ViewHolder对象后，立即对其重置（将flag置0）。这样就满足了绑定数据的判断条件（因为0和非0位与之后必然为0）。 同样的，在才mAttachedScrap中获取ViewHolder时，只有当其是有效的才会返回。所以猜测成立：从mRecyclerPool中复用的ViewHolder需要重新绑定数据，从mAttachedScrap 中复用的ViewHolder不要重新出创建也不需要重新绑定数据。 总结 在 RecyclerView 中，并不是每次绘制表项，都会重新创建 ViewHolder 对象，也不是每次都会重新绑定 ViewHolder 数据。 RecyclerView 通过Recycler获得下一个待绘制表项。 Recycler有4个层次用于缓存 ViewHolder 对象，优先级从高到底依次为 ArrayList&lt;ViewHolder&gt; mAttachedScrap、 ArrayList&lt;ViewHolder&gt; mCachedViews、 ViewCacheExtension mViewCacheExtension、 RecycledViewPool mRecyclerPool。 如果四层缓存都未命中，则重新创建并绑定 ViewHolder 对象。 RecycledViewPool 对 ViewHolder 按viewType分类存储（通过SparseArray），同类 ViewHolder 存储在默认大小为5的ArrayList中。 从mRecyclerPool中复用的 ViewHolder 需要重新绑定数据，从mAttachedScrap 中复用的 ViewHolder 不需要重新创建也不需要重新绑定数据。 从mRecyclerPool中复用的ViewHolder ，只能复用于viewType相同的表项，从mCachedViews中复用的 ViewHolder ，只能复用于指定位置的表项。 mCachedViews是离屏缓存，用于缓存指定位置的 ViewHolder ，只有“列表回滚”这一种场景（刚滚出屏幕的表项再次进入屏幕），才有可能命中该缓存。该缓存存放在默认大小为 2 的ArrayList中。 这篇文章粗略的回答了关于“复用”的4个问题，即“复用什么？”、“从哪里获得复用？”、“什么时候复用？”、“复用优先级”。读到这里，可能会有很多疑问： 预布局、预测动画是什么？关于预测动画和预布局的介绍，可以看这篇文章：深入理解 RecyclerView 的缓存机制 RecyclerView的滚动和回收机制：RecyclerView之所以能滚动，就是因为它在监听到手指滑动之后，不断地更新Item的位置，也就是反复layout子View了，这部分工作由LayoutManager负责。 LayoutManager在layout子View之前，会先把RecyclerView的每个子View所对应的ViewHolder都放到mAttachedScrap中，然后根据当前滑动距离，筛选出哪些Item需要layout。获取子View对象，会通过getViewForPosition方法来获取。这个方法就是题目中说的那样：先从mAttachedScrap中找，再…… Item布局完成之后，会对刚刚没有再次布局的Item进行缓存（回收），这个缓存分两种： 取出（即将重用）时无须重新绑定数据（即不用执行onBindViewHolder方法）。这种缓存只适用于特定position的Item（名花有主）； 取出后会回调onBindViewHolder方法，好让对应Item的内容能正确显示。这种缓存适用所有同类型的Item（云英未嫁）；第一种缓存，由Recycler.mCachedViews来保管，第二种放在RecycledViewPool中。 如果回收的Item它的状态（包括：INVALID、REMOVED、UPDATE、POSITION_UNKNOWN）没有变更，就会放到mCachedViews中，否则扔RecycledViewPool里。 emmmm，除了滚动过程中，会对Item进行回收和重新布局，还有一种就是，当Adapter数据有更新时： Inserted：如果刚好插入在屏幕可见范围内，会从RecycledViewPool中找一个相同类型的ViewHolder（找不到就create）来重新绑定数据并layout； Removed：会把对应ViewHolder扔到mAttachedScrap中并播放动画，动画播放完毕后移到RecycledViewPool里； Changed：这种情况并不是大家所认为的：直接将这个ViewHolder传到Adapter的onBindViewHolder中重新绑定数据。而是先把旧的ViewHolder扔mChangedScrap中，然后像Inserted那样从RecycledViewPool中找一个相同类型的ViewHolder来重新绑定数据。旧ViewHolder对象用来播放动画，动画播完，同样会移到RecycledViewPool里； 注意：如果是使用notifyDataSetChanged方法来通知更新的话，那么所有Item都会直接扔RecycledViewPool中，然后逐个重新绑定数据的。 这几个存放缓存的集合，各自的作用以及使用场景？ mAttachedScrap：LayoutManager每次layout子View之前，那些已经添加到RecyclerView中的Item以及被删除的Item的临时存放地。使用场景就是RecyclerView滚动时、还有在可见范围内删除Item后用notifyItemRemoved方法通知更新时； mChangedScrap：作用：存放可见范围内有更新的Item。使用场景：可见范围内的Item有更新，并且使用notifyItemChanged方法通知更新时； mCachedViews：作用：存放滚动过程中没有被重新使用且状态无变化的那些旧Item。场景：滚动，prefetch； RecycledViewPool：作用：缓存Item的最终站，用于保存那些Removed、Changed、以及mCachedViews满了之后更旧的Item。场景：Item被移除、Item有更新、滚动过程； 写到这里发现漏讲了一个prefetch，好吧，这个prefetch机制就是RecyclerView在滚动和惯性滚动的时候，借助Handler来事先从RecycledViewPool中取出即将要显示的Item，随即扔到mCachedViews中，这样的话，当layout到这个Item时，就能直接拿来用而不用绑定数据了。 Ref深入理解 RecyclerView 的缓存机制 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/07/18/recyclerview-cache/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"},{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"ANR 总结与分析","slug":"ANR-summary","date":"2021-06-06T16:00:00.000Z","updated":"2024-12-05T09:41:25.323Z","comments":true,"path":"2021/06/07/ANR-summary/","link":"","permalink":"http://agehua.github.io/2021/06/07/ANR-summary/","excerpt":"ANR 分类Android ANR问题分为三类：Input，Receiver，Service\n在我们常见的APP开发中，主要遇到的都是Input超时问题，本文就详细分析下Input超时是如何产生以及如何排查","text":"ANR 分类Android ANR问题分为三类：Input，Receiver，Service 在我们常见的APP开发中，主要遇到的都是Input超时问题，本文就详细分析下Input超时是如何产生以及如何排查在分析Input超时之前，我们先来简单的介绍一下Android的Input系统。Android Input体系中，大致有两种类型的事件，实体按键key事件，屏幕点击触摸事件，当然如果根据事件类型的不同我们还能细分为基础实体按键的key(power，volume up/down，recents，back，home)，实体键盘按键，屏幕点击(多点，单点)，屏幕滑动等等的事件。在Android整个Input体系中有三个格外重要的成员：Eventhub，InputReader，InputDispatcher。它们分别担负着各自不同的职责，Eventhub负责监听/dev/input产生Input事件，InputReader负责从Eventhub读取事件，并将读取的事件发给InputDispatcher，InputDispatcher则根据实际的需要具体分发给当前手机获得焦点实际的Window。当然它们三者之间有工作远比我介绍的要复杂的很多。 详细源码可以参考：Input系统—ANR原理分析 要产生 ANR，至少得有两个输入事件，场景如下： 第一个输入事件产生，系统将其发送给用户当前操作的 App； 系统收到第二个事件，发现当前距第一个输入事件发送时间超过 0.5s 仍未处理完毕，则设置一个定时器，5s 后触发； 5s 之后，若系统发现第一个输入事件仍然没有回应时，则触发 ANR，激活 App 中的 Signal Cather 线程生成 traces.txt，然后弹出 ANR 对话框，告知用户 App 无响应。 也就是说，要产生 ANR，第一个输入事件必需在 5.5s 以上没有被处理完成并反馈回系统；并且要有第二个输入事件产生。如果没有第二个输入事件，即便第一个输入事件执行了 60s 或更长时间，也是不会产生 ANR 的。 ANR 产生原因Input ANR reason主要有以下几类： 无窗口, 有应用：Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up. 窗口暂停: Waiting because the [targetType] window is paused. 窗口未连接: Waiting because the [targetType] window’s input channel is not registered with the input dispatcher. The window may be in the process of being removed. 窗口连接已死亡：Waiting because the [targetType] window’s input connection is [Connection.Status]. The window may be in the process of being removed. 窗口连接已满：Waiting because the [targetType] window’s input channel is full. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度]. 按键事件，输出队列或事件等待队列不为空：Waiting to send key event because the [targetType] window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度]. 非按键事件，事件等待队列不为空且头事件分发超时500ms：Waiting to send non-key event because the [targetType] window has not finished processing certain input events that were delivered to it over 500ms ago. Wait queue length: [waitQueue长度]. Wait queue head age: [等待时长]. 其中 targetType: 取值为”focused”或者”touched” Connection.Status: 取值为”NORMAL”，”BROKEN”，”ZOMBIE” 实例分析，Reason: Waiting because the focused window is paused.最近遇到这个问题，但是没有trace文件可以分析，只有logcat和dumpsys文件。下面利用这两个文件尝试分析下如何定位这类ANR先看下logcat内容 step1, 在logcat中搜索 Application is not responding，并确认这条日志的时间点：06-01 04:38:39.160 // 第一步搜索 Application is not responding06-01 04:38:39.160 1457 1669 I InputDispatcher: Application is not responding: AppWindowToken&#123;b7d5d7c token=Token&#123;5a5c6f ActivityRecord&#123;12f034e u0 com.xxx/.MainActivity t4569&#125;&#125;&#125; - Window&#123;703780b u0 cxxx/xxx.xActivity&#125;. It has been 5008.2ms since event, 5003.2ms since wait started. Reason: Waiting because the focused window is paused. step2, ANR属于InputDispatcher类型，向前选5s，大概在 06-01 04:38:34的时间点 step3, 在上一步的时间点，看看有没有到对应的input事件，找到了： 06-01 04:38:34.151 23143 23143 D AndroidRuntime: Calling main entry com.android.commands.input.Input06-01 04:38:34.152 23143 23143 I Input : injectKeyEvent: KeyEvent &#123; action=ACTION_DOWN, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=2108288622, downTime=2108288622, deviceId=-1, source=0x101 &#125; step4, 根据事件，猜测是点击返回时发生了ANR， step5, 搜索关键字 ANR in，查看CPU占用，发现CPU占用过高 06-01 04:38:49.302 1457 23156 E ActivityManager: ANR in xxx (xxx/.x,xActivity)06-01 04:38:49.302 1457 23156 E ActivityManager: PID: 1883306-01 04:38:49.302 1457 23156 E ActivityManager: Reason: Input dispatching timed out (Waiting because the focused window is paused.), happend at time = 2108297657@#@1883306-01 04:38:49.302 1457 23156 E ActivityManager: Load: 0.0 / 0.0 / 0.006-01 04:38:49.302 1457 23156 E ActivityManager: CPU usage from 105ms to -6001ms ago:06-01 04:38:49.302 1457 23156 E ActivityManager: 131% 18833/xxx: 30% user + 100% kernel / faults: 19725 minor 18 major06-01 04:38:49.302 1457 23156 E ActivityManager: 33% 19724/com.android.commands.monkey: 29% user + 3.6% kernel / faults: 5507 minor 1 major06-01 04:38:49.302 1457 23156 E ActivityManager: 20% 1457/system_server: 12% user + 8.3% kernel / faults: 1084 minor 7 major06-01 04:38:49.302 1457 23156 E ActivityManager: 10% 452/surfaceflinger: 3.9% user + 6% kernel / faults: 45 minor 虽然现在手机基本都是多核CPU，比如4核的话，CPU上线是 400%。但App正常使用时，单个CPU占用应该不超过100%。到这里猜测，在点击按钮返回时，页面刷新App CPU占用过高，导致ANR，此时对应Activity的onPause和onResume两个生命周期， 在分析一下为什么ANR 原因是 Input dispatching timed out (Waiting because the focused window is paused.) 查看 dumpsys 文件在 dumpsys 文件中搜索 Input Dispatcher，找到下面的内容，注释内容是我自己添加的，便于理解Input Dispatcher State at time of last ANR: ANR: Time: 2021-06-01 04:38:39 // 这里时间跟 step1 的时间一致 Window: AppWindowToken&#123;b7d5d7c token=Token&#123;5a5c6f ActivityRecord&#123;12f034e u0 xxx/.xxxActivity t4569&#125;&#125;&#125; - Window&#123;703780b u0 xxx/xxx.xActivity&#125; // 注意上面的 Window&#123;703780b ... DispatchLatency: 5008.2ms WaitDuration: 5003.2ms Reason: Waiting because the focused window is paused. DispatchEnabled: 1 DispatchFrozen: 0 FocusedApplication: name='AppWindowToken&#123;b7d5d7c token=Token&#123;5a5c6f ActivityRecord&#123;12f034e u0 xxx/.xxxActivity t4569&#125;&#125;&#125;', dispatchingTimeout=5000.000ms FocusedWindow: name='Window&#123;703780b u0 xxx/xxx.xActivity&#125;' TouchStates: &lt;no displays touched&gt; Windows: //.... 省略 // 根据 703780b 找到对应的window，同时发现有两个window状态是 paused，但Window&#123;6dfcc50 hasFocus=false 暂不考虑 8: name='Window&#123;6dfcc50 u0 PopupWindow:408c8f7&#125;', displayId=0, paused=true, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x41800008, type=0x000003e8, layer=21020, frame=[223,149][474,208], scale=1.000000, touchableRegion=[223,149][474,208], inputFeatures=0x00000000, ownerPid=18833, ownerUid=13560, dispatchingTimeout=5000.000ms // Window&#123;703780b paused=true 9: name='Window&#123;703780b u0 xxx/xxx.xActivity&#125;', displayId=0, paused=true, hasFocus=true, hasWallpaper=false, visible=true, canReceiveKeys=true, flags=0x81810520, type=0x00000001, layer=21015, frame=[0,0][1280,720], scale=1.000000, touchableRegion=[0,0][1280,720], inputFeatures=0x00000000, ownerPid=18833, ownerUid=13560, dispatchingTimeout=5000.000ms 在 dumpsys 文件中 继续搜索 WINDOW MANAGER LAST ANR，找到 Window{703780b-------------------------------------------------------------------------------WINDOW MANAGER LAST ANR (dumpsys window lastanr)//.... 省略Window #3 Window&#123;703780b u0 xxx/xxx.xActivity&#125;: mDisplayId=0 stackId=156 mSession=Session&#123;eaba5cd 18833:u0a13560&#125; mClient=android.os.BinderProxy@9fb1bda mOwnerUid=13560 mShowToOwnerOnly=true package=com.xxx appop=NONE mAttrs=WM.LayoutParams&#123;(0,0)(fillxfill) sim=#20 ty=1 fl=#81810500 wanim=0x103045b vsysui=0x1606 sysuil=true needsMenuKey=2&#125; Requested w=1280 h=720 mLayoutSeq=311401 mBaseLayer=21000 mSubLayer=0 mAnimLayer=21015+0=21015 mLastLayer=21015 mToken=AppWindowToken&#123;31531d3 token=Token&#123;40bffc2 ActivityRecord&#123;82ca40d u0 xxx/xxx.xActivity t4569&#125;&#125;&#125; mRootToken=AppWindowToken&#123;31531d3 token=Token&#123;40bffc2 ActivityRecord&#123;82ca40d u0 xxx/xxx.xActivity t4569&#125;&#125;&#125; mAppToken=AppWindowToken&#123;31531d3 token=Token&#123;40bffc2 ActivityRecord&#123;82ca40d u0 xxx/xxx.xActivity t4569&#125;&#125;&#125; mViewVisibility=0x0 mHaveFrame=true mObscured=false mSeq=2 mSystemUiVisibility=0x1606 mGivenContentInsets=[0,0][0,0] mGivenVisibleInsets=[0,0][0,0] mConfiguration=&#123;1.12 ?mcc?mnc zh_CN ldltr sw360dp w640dp h342dp 320dpi nrml long land finger -keyb/v/h -nav/h s.339mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0&#125; mHasSurface=true mShownFrame=[0.0,0.0][1280.0,720.0] isReadyForDisplay()=true mFrame=[0,0][1280,720] last=[0,0][1280,720] mSystemDecorRect=[0,0][1280,720] last=[0,0][0,0] Frames: containing=[0,0][1280,720] parent=[0,0][1280,720] display=[0,0][1280,720] overscan=[0,0][1280,720] content=[0,0][1280,720] visible=[0,0][1280,720] decor=[0,0][1280,720] outset=[0,0][1280,720] Cur insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] outsets=[0,0][0,0] Lst insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] physical=[0,0][0,0] outset=[0,0][0,0] WindowStateAnimator&#123;63d5e15 xxx/xxx.xActivity&#125;: mSurface=Surface(name=xxx/xxx.xActivity) mDrawState=HAS_DRAWN mLastHidden=false Surface: shown=true layer=21015 alpha=1.0 rect=(0.0,0.0) 1280.0 x 720.0 mGlobalScale=1.0 mDsDx=1.0 mDtDx=0.0 mDsDy=0.0 mDtDy=1.0 从上面日志可以发现这个window，属于是AppWindowToken，说明这个window就是一个Activity。 如果对AppWindowToken和ActivityRecord感兴趣的，可以看下罗老师的这篇文章：https://blog.csdn.net/luoshengyang/article/details/8498908 这里列一下返回时，两个Activity的生命周期交互 onBackPressed() 流程：SecondActivity - onPause() — MainActivity - onRestart() — MainActivity - onStart() — MainActivity - onResume() — SecondActivity - onStop() — SecondActivity - onDestroy() 综合上面的分析和猜测 :) , 需要着重看下xxActivity的onPause和下层Activity的onResume方法。 OK，到这里我们就知道了该如何分析 Waiting because the focused window is paused 对应的ANR了。 Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up在dumpsys文件中：Input Dispatcher State at time of last ANR: ANR: Time: 2021-05-31 23:33:18 // 跟上面分析过的 dumpsys文件对比，发现这里没有 - Window&#123;id u0 xxx/xxx.xActivity&#125; Window: AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; DispatchLatency: 5003.8ms WaitDuration: 5000.7ms Reason: Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up. DispatchEnabled: 1 DispatchFrozen: 0 FocusedApplication: name='AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125;', dispatchingTimeout=5000.000ms FocusedWindow: name='&lt;null&gt;' TouchStates: &lt;no displays touched&gt; Windows: // 这里有一个对应包名的window Window #8 Window&#123;7e932b5 u0 Starting com.xxx&#125;: mDisplayId=0 stackId=156 mSession=Session&#123;86d25c5 1457:1000&#125; mClient=android.view.ColorViewRootImplHooks$ColorW@7d1ceec mOwnerUid=1000 mShowToOwnerOnly=false package=com.xxx appop=NONE mAttrs=WM.LayoutParams&#123;(0,0)(fillxfill) sim=#20 ty=3 fl=#81830518 pfl=0x11 wanim=0x103045b vsysui=0x600 needsMenuKey=2&#125; Requested w=1280 h=720 mLayoutSeq=292571 mBaseLayer=21000 mSubLayer=0 mAnimLayer=21040+0=21040 mLastLayer=21040 mToken=AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; mRootToken=AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; mAppToken=AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125; mViewVisibility=0x0 mHaveFrame=true mObscured=false mSeq=0 mSystemUiVisibility=0x600 mGivenContentInsets=[0,0][0,0] mGivenVisibleInsets=[0,0][0,0] mConfiguration=&#123;1.12 ?mcc?mnc zh_CN ldltr sw360dp w640dp h342dp 320dpi nrml long land finger -keyb/v/h -nav/h s.119mThemeChanged = 0mThemeChangedFlags = 0mFlipFont = 0&#125; mHasSurface=true mShownFrame=[0.0,0.0][1280.0,720.0] isReadyForDisplay()=true mFrame=[0,0][1280,720] last=[0,0][1280,720] mSystemDecorRect=[0,0][1280,720] last=[0,0][0,0] Frames: containing=[0,0][1280,720] parent=[0,0][1280,720] display=[0,0][1280,720] overscan=[0,0][1280,720] content=[0,0][1280,720] visible=[0,0][1280,720] decor=[0,0][1280,720] outset=[0,0][1280,720] Cur insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] outsets=[0,0][0,0] Lst insets: overscan=[0,0][0,0] content=[0,0][0,0] visible=[0,0][0,0] stable=[0,36][0,0] physical=[0,0][0,0] outset=[0,0][0,0] WindowStateAnimator&#123;b277152 Starting com.xxx&#125;: mSurface=Surface(name=Starting com.xxx) mDrawState=HAS_DRAWN mLastHidden=false Surface: shown=true layer=21040 alpha=1.0 rect=(0.0,0.0) 1280.0 x 720.0 mGlobalScale=1.0 mDsDx=1.0 mDtDx=0.0 mDsDy=0.0 mDtDy=1.0 在logcat文件中：// input事件发生的时间点05-31 23:33:18.336 1457 1669 I WindowManager: Input event dispatching timed out sending to application AppWindowToken&#123;9a5328e token=Token&#123;caaf289 ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;&#125;&#125;. Reason: Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.05-31 23:33:18.341 28229 28258 I chatty : uid=13560(com.xxx) expire 2 lines05-31 23:33:18.344 1457 1669 D ActivityManager: ANR post Runnable for ProcessRecord&#123;772ec6 28229:com.xxx/u0a3560&#125; to deal with anr happend at 2089972814@#@2822905-31 23:33:18.344 1457 1669 D ActivityManager: ANR caller(2) = com.android.server.am.ActivityRecord$Token.keyDispatchingTimedOut:388 com.android.server.wm.InputMonitor.notifyANR:134 com.android.server.input.InputManagerService.notifyANR:1625 &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; &lt;bottom of call stack&gt; 05-31 23:33:18.347 1457 1527 W InputManager: Input event injection from pid 28213 timed out.05-31 23:33:18.348 1457 28282 D ActivityManager: inputDispatchingTimedOut appNotResponding: proc ProcessRecord&#123;772ec6 28229:com.xxx/u0a3560&#125;05-31 23:33:18.349 1457 28282 D ActivityManager: appNotResponding: activity ActivityRecord&#123;b8e1990 u0 com.xxx/oxxx.PlayerActivity t4506&#125;05-31 23:33:18.350 28213 28213 I Input : injectKeyEvent: KeyEvent &#123; action=ACTION_UP, keyCode=KEYCODE_BACK, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=2089967799, downTime=2089967799, deviceId=-1, source=0x101 &#125;05-31 23:33:18.353 1457 28284 D ActivityManager: ANR deal 3 appNotResponding for ProcessRecord&#123;772ec6 28229:com.xxx/u0a3560&#125;, pid = 28229, annotation = Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.), happend at time = 2089972814@#@28229// ANR 收集到的时间点05-31 23:33:24.416 1457 28284 E ActivityManager: ANR in com.xxx (com.xxx/oxxx.PlayerActivity)05-31 23:33:24.416 1457 28284 E ActivityManager: PID: 2822905-31 23:33:24.416 1457 28284 E ActivityManager: Reason: Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.), happend at time = 2089972814@#@2822905-31 23:33:24.416 1457 28284 E ActivityManager: Load: 0.0 / 0.0 / 0.005-31 23:33:24.416 1457 28284 E ActivityManager: CPU usage from 955ms to -6002ms ago:05-31 23:33:24.416 1457 28284 E ActivityManager: 61% 26158/com.android.commands.monkey: 22% user + 39% kernel / faults: 3743 minor 26 major05-31 23:33:24.416 1457 28284 E ActivityManager: 20% 1457/system_server: 12% user + 7.8% kernel / faults: 16282 minor 21 major05-31 23:33:24.416 1457 28284 E ActivityManager: 9.6% 6732/VosTXThread: 0% user + 9.6% kernel05-31 23:33:24.416 1457 28284 E ActivityManager: +0% 28229/com.xxx: 0% user + 0% kernel 发现我们app的CPU 占用是0%，说明可能是我们的应用还没有启动起来，就发生了ANR。此时CPU占用最高的是monkey线程。 幸运的是这次抓到trace文件 关键：traces.txt 日志分析关于traces文件分析，我参考的是这篇文章：Android ANR日志分析指南 当APP不响应、响应慢了、或者WatchDog的监视没有得到回应时，系统就会dump出一个traces.txt文件，存放在文件目录: /data/anr/traces.txt，通过traces文件,我们可以拿到线程名、堆栈信息、线程当前状态、binder call等信息。 通过adb命令拿到该文件：adb pull /data/anr/traces.txt 我详细解析一下traces.txt里面的一些字段，看看它到底能给我们提供什么信息.main：main标识是主线程，如果是线程，那么命名成“Thread-X”的格式,x表示线程id,逐步递增。prio：线程优先级,默认是5tid：tid不是线程的id，是线程唯一标识IDgroup：是线程组名称sCount：该线程被挂起的次数dsCount：是线程被调试器挂起的次数obj：对象地址self：该线程Native的地址sysTid：是线程号(主线程的线程号和进程号相同)nice：是线程的调度优先级sched：分别标志了线程的调度策略和优先级cgrp：调度归属组handle：线程处理函数的地址。state：是调度状态schedstat：从 /proc/[pid]/task/[tid]/schedstat读出，三个值分别表示线程在cpu上执行的时间、线程的等待时间和线程执行的时间片长度，不支持这项信息的三个值都是0；utm：是线程用户态下使用的时间值(单位是jiffies）stm：是内核态下的调度时间值core：是最后执行这个线程的cpu核的序号。 main的堆栈信息是我们最关心的，它能够定位到具体位置。从上面的traces,我们可以判断java.io.File.isAbsolute 导致发生了ANR。这时候可以对着源码查看，找到出问题，并且解决它。 这里就主要看 mian线程// ... 省略suspend all histogram: Sum: 29.777ms 99% C.I. 4us-17039.359us Avg: 465.265us Max: 20121usDALVIK THREADS (36):\"Signal Catcher\" daemon prio=5 tid=2 Runnable | group=\"system\" sCount=0 dsCount=0 obj=0x12d0a0a0 self=0xed7b8600 | sysTid=28234 nice=0 cgrp=default sched=0/0 handle=0xf497f930 | state=R schedstat=( 5272239 1424062 9 ) utm=0 stm=0 core=6 HZ=100 | stack=0xf4883000-0xf4885000 stackSize=1014KB | held mutexes= \"mutator lock\"(shared held) native: #00 pc 0035e8cd /system/lib/libart.so (_ZN3art15DumpNativeStackERNSt3__113basic_ostreamIcNS0_11char_traitsIcEEEEiPKcPNS_9ArtMethodEPv+116) native: #01 pc 0033ed6b /system/lib/libart.so (_ZNK3art6Thread4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+138) native: #02 pc 00348ce5 /system/lib/libart.so (_ZN3art14DumpCheckpoint3RunEPNS_6ThreadE+420) native: #03 pc 00349841 /system/lib/libart.so (_ZN3art10ThreadList13RunCheckpointEPNS_7ClosureE+192) native: #04 pc 00349d41 /system/lib/libart.so (_ZN3art10ThreadList4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+124) native: #05 pc 0034a429 /system/lib/libart.so (_ZN3art10ThreadList14DumpForSigQuitERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+312) native: #06 pc 0031f8e3 /system/lib/libart.so (_ZN3art7Runtime14DumpForSigQuitERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+66) native: #07 pc 0032a007 /system/lib/libart.so (_ZN3art13SignalCatcher13HandleSigQuitEv+910) native: #08 pc 0032aa2d /system/lib/libart.so (_ZN3art13SignalCatcher3RunEPv+668) native: #09 pc 0003fc7b /system/lib/libc.so (_ZL15__pthread_startPv+30) native: #10 pc 00019fc5 /system/lib/libc.so (__start_thread+6) (no managed stack frames)\"main\" prio=5 tid=1 Suspended // 状态是暂停 | group=\"main\" sCount=1 dsCount=0 obj=0x740c1360 self=0xf5402500 | sysTid=28229 nice=0 cgrp=default sched=0/0 handle=0xf76e5b34 | state=S schedstat=( 489913748 62354685 405 ) utm=38 stm=10 core=7 HZ=100 | stack=0xff78b000-0xff78d000 stackSize=8MB | held mutexes= at java.io.File.isAbsolute(File.java:510) at java.io.File.getAbsolutePath(File.java:373) at com.tencent.tinker.lib.tinker.Tinker$Builder.&lt;init&gt;(Proguard:359) at com.tencent.tinker.lib.tinker.con.a(Proguard:63) at com.xxx.hotfix.con.a(Proguard:127) at com.xxx.hotfix.con.a(Proguard:46) at com.xxx.hotfix.c.con.b(Proguard:198) at com.xxx.ApplicationDelegate.initTinker(Proguard:208) at com.xxx.ApplicationDelegate.onCreate(Proguard:152) at com.tencent.tinker.entry.TinkerApplicationInlineFence.onCreateImpl_$noinline$(Proguard:99) at com.tencent.tinker.entry.TinkerApplicationInlineFence.onCreate(Proguard:110) at com.tencent.tinker.loader.app.TinkerApplication.onCreate(Proguard:153) at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1014) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4995) at android.app.ActivityThread.access$1800(ActivityThread.java:170) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1555) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:179) at android.app.ActivityThread.main(ActivityThread.java:5769) at java.lang.reflect.Method.invoke!(Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:674)\"ReferenceQueueDaemon\" daemon prio=5 tid=4 Waiting | group=\"system\" sCount=1 dsCount=0 obj=0x12d04be0 self=0xf5402a00 | sysTid=28235 nice=0 cgrp=default sched=0/0 handle=0xf4880930 | state=S schedstat=( 947291 9095001 12 ) utm=0 stm=0 core=7 HZ=100 | stack=0xf477e000-0xf4780000 stackSize=1038KB | held mutexes= at java.lang.Object.wait!(Native method) - waiting on &lt;0x09e82a5a&gt; (a java.lang.Class&lt;java.lang.ref.ReferenceQueue&gt;) at java.lang.Daemons$ReferenceQueueDaemon.run(Daemons.java:152) - locked &lt;0x09e82a5a&gt; (a java.lang.Class&lt;java.lang.ref.ReferenceQueue&gt;) at java.lang.Thread.run(Thread.java:818)\"FinalizerDaemon\" daemon prio=5 tid=5 Waiting | group=\"system\" sCount=1 dsCount=0 obj=0x12d04c40 self=0xf5402f00 | sysTid=28236 nice=0 cgrp=default sched=0/0 handle=0xf477b930 | state=S schedstat=( 899169 4021874 6 ) utm=0 stm=0 core=5 HZ=100 | stack=0xf4679000-0xf467b000 stackSize=1038KB | held mutexes= at java.lang.Object.wait!(Native method) - waiting on &lt;0x005da48b&gt; (a java.lang.ref.ReferenceQueue) at java.lang.Object.wait(Object.java:423) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:101) - locked &lt;0x005da48b&gt; (a java.lang.ref.ReferenceQueue) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:72) at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:193) at java.lang.Thread.run(Thread.java:818)\"FinalizerWatchdogDaemon\" daemon prio=5 tid=6 Waiting | group=\"system\" sCount=1 dsCount=0 obj=0x12d04ca0 self=0xf5403400 | sysTid=28237 nice=0 cgrp=default sched=0/0 handle=0xf4676930 | state=S schedstat=( 899684 3116201 10 ) utm=0 stm=0 core=7 HZ=100 | stack=0xf4574000-0xf4576000 stackSize=1038KB | held mutexes= at java.lang.Object.wait!(Native method) - waiting on &lt;0x0e839968&gt; (a java.lang.Daemons$FinalizerWatchdogDaemon) at java.lang.Daemons$FinalizerWatchdogDaemon.waitForObject(Daemons.java:275) - locked &lt;0x0e839968&gt; (a java.lang.Daemons$FinalizerWatchdogDaemon) at java.lang.Daemons$FinalizerWatchdogDaemon.run(Daemons.java:244) at java.lang.Thread.run(Thread.java:818) 看trace文件，应该是其他线程占用了资源，导致main线程暂停 最后，结合上面CPU占用分析，应该是monkey线程占用了资源，导致main线程挂起 拓展Service，Reason: executing service xxx/xxx.Service在logcat中遇到一个Service ANR Service Timeout是位于”ActivityManager”线程中的AMS.MainHandler收到SERVICE_TIMEOUT_MSG消息时触发。 对于Service有两类: 对于前台服务，则超时为SERVICE_TIMEOUT = 20s； 对于后台服务，则超时为SERVICE_BACKGROUND_TIMEOUT = 200s 由变量ProcessRecord.execServicesFg来决定是否前台启动先看logcat日志，有如下内容，以时间先后排列：// 系统进程都已经挂掉了06-01 04:54:26.174 1457 1807 I ActivityManager: Process com.android.browser (pid 27980) has died06-01 04:54:26.174 1457 1807 D ActivityManager: cleanUpApplicationRecord -- 2798006-01 04:54:26.975 1457 1807 I ActivityManager: Start proc 28150:com.oppo.usercenter/u0a59 for content provider com.oppo.usercenter/com.platform.usercenter.newcommon.db.UserCenterContentProvider06-01 04:54:27.011 1457 1471 I ActivityManager: Process com.oppo.market (pid 28086) has died06-01 04:54:27.011 1457 1471 D ActivityManager: cleanUpApplicationRecord -- 2808606-01 04:54:28.093 1457 2688 I ActivityManager: Process com.tencent.mm:push (pid 12440) has died06-01 04:54:28.093 1457 2688 D ActivityManager: cleanUpApplicationRecord -- 12440// 应用被force-stop, 发送广播ACTION_PACKAGE_RESTARTED，用于停止已注册的alarm,notification.06-01 04:54:40.840 1457 1457 D JobSchedulerService: Receieved: android.intent.action.PACKAGE_RESTARTED06-01 04:54:40.841 1457 1457 D JobSchedulerService: Stop app Removing jobs for uid: 13560 pkg = xxx06-01 04:54:40.883 1457 1522 W WindowManager: Attempted to add application window with unknown token Token&#123;6f25abd ActivityRecord&#123;bf5f214 u0 xxx/oxxx.PlayerActivity t4576 f&#125;&#125;. Aborting.// 在一个Activity启动前，系统会先创建一个启动窗口作为过渡，这里starting window就代表启动窗口，启动窗口也添加失败06-01 04:54:40.902 1457 1522 W WindowManager: Exception when adding starting window 06-01 04:54:40.902 1457 1522 W WindowManager: java.lang.IllegalArgumentException: View=com.android.internal.policy.PhoneWindow$DecorView&#123;7d429de V.E...... R.....ID 0,0-0,0&#125; not attached to window manager06-01 04:54:40.902 1457 1522 W WindowManager: at android.view.WindowManagerGlobal.findViewLocked(WindowManagerGlobal.java:424)06-01 04:54:40.902 1457 1522 W WindowManager: at android.view.WindowManagerGlobal.removeView(WindowManagerGlobal.java:350)06-01 04:54:40.902 1457 1522 W WindowManager: at android.view.WindowManagerImpl.removeViewImmediate(WindowManagerImpl.java:118)06-01 04:54:40.902 1457 1522 W WindowManager: at com.android.server.policy.PhoneWindowManager.addStartingWindow(PhoneWindowManager.java:2811)06-01 04:54:40.902 1457 1522 W WindowManager: at com.android.server.wm.WindowManagerService$H.handleMessage(WindowManagerService.java:8406)06-01 04:54:40.902 1457 1522 W WindowManager: at android.os.Handler.dispatchMessage(Handler.java:102)06-01 04:54:40.902 1457 1522 W WindowManager: at android.os.Looper.loop(Looper.java:179)06-01 04:54:40.902 1457 1522 W WindowManager: at android.os.HandlerThread.run(HandlerThread.java:61)06-01 04:54:40.902 1457 1522 W WindowManager: at com.android.server.ServiceThread.run(ServiceThread.java:46)// 杀掉应用进程06-01 05:26:03.900 1457 2476 I ActivityManager: Force stopping xxx appid=13560 user=0: from pid 2418506-01 05:26:03.901 1457 2476 I ActivityManager: Killing 7767:xxx/u0a3560 (adj 0): stop xxx06-01 05:26:03.902 1457 2476 D ActivityManager: cleanUpApplicationRecord -- 7767// 重启应用进程06-01 05:26:25.005 1457 2643 I ActivityManager: Start proc 7916:xxx/u0a3560 for activity xxx/.WelcomeActivity06-01 05:26:25.020 14580 14580 I MediaScannerReceiver: onReceive, intent=Intent &#123; act=android.intent.action.MEDIA_SCANNER_SCAN_FILE dat=file:///sdcard/monkey_screenshot/122_2021-06-01_05-26-09.png flg=0x10 cmp=com.android.providers.media/.MediaScannerReceiver &#125;// window freeze timeout App freeze timeout 网上说这里是屏幕方向改变时，清理旧配置信息超时06-01 05:26:27.071 1457 1522 W WindowManager: Window freeze timeout expired.06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;9ec2733 u0 Starting xxx&#125;06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;38b9629 u0 xxx/xxx.WelcomeActivity&#125;06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;863574f u0 xxx/xxx.WelcomeActivity&#125;06-01 05:26:27.071 1457 1522 W WindowManager: Force clearing orientation change: Window&#123;4bf40a2 u0 com.android.systemui.ImageWallpaper&#125;06-01 05:26:27.075 1457 1522 V WindowManager: set sys.app_freeze_timeout: pkg=xxx06-01 05:26:27.084 1457 1522 W WindowManager: App freeze timeout expired.06-01 05:26:27.085 1457 1522 W WindowManager: Force clearing freeze: AppWindowToken&#123;e409897 token=Token&#123;68b58d8 ActivityRecord&#123;17fbbb u0 xxx/.WelcomeActivity t4595&#125;&#125;&#125;06-01 05:26:27.145 1457 1522 I WindowManager: Screen frozen for +2s74ms due to Window&#123;9ec2733 u0 Starting xxx&#125;06-01 05:26:27.156 1457 1522 I WindowManager: finishPostLayoutPolicyLw (statusbar != null ) true topIsFullscreen true top = Window&#123;9ec2733 u0 Starting xxx&#125;06-01 05:26:27.156 1457 1522 I StatusBarManagerService: topIsFullscreen fullscreen true06-01 05:26:27.174 1457 1471 I WindowManager: Switching to real app window: Window&#123;863574f u0 xxx/xxx.WelcomeActivity&#125;// launch timeout 可以看下这篇文章： https://blog.csdn.net/bruk_spp/article/details/9776937606-01 05:26:47.226 1457 1497 W ActivityManager: Launch timeout has expired, giving up wake lock!06-01 05:26:47.230 21977 21995 I Launcher.LauncherTraceUtil: writeLauncherStateToFile. The mStateTrace is null!06-01 05:26:47.232 7916 7953 I chatty : uid=13560(xxx) expire 2 lines06-01 05:26:47.332 1457 8210 I Process : Sending signal. PID: 7916 SIG: 3// ANR 发生的地方06-01 05:26:47.234 1457 1497 W ActivityManager: Timeout executing service: ServiceRecord&#123;d006edc u0 xxx/xxxService&#125;06-01 05:26:47.235 1457 1500 V OppoAppStartupManager: intent == null || callerApp == null06-01 05:26:47.239 1457 1863 D BluetoothManagerService: checkIfCallerIsForegroundUser: valid=true callingUser=0 parentUser=-10000 foregroundUser=006-01 05:26:47.242 2646 2646 E ANR_LOG : &gt;&gt;&gt; msg's executing time is too long06-01 05:26:47.242 2646 2646 E ANR_LOG : Blocked msg = &#123; when=-2s244ms what=3 target=com.qti.internal.telephony.gsm.QtiGsmServiceStateTracker obj=android.os.AsyncResult@f88f23e &#125; , cost = 2243 ms06-01 05:26:47.242 2646 2646 E ANR_LOG : &gt;&gt;&gt;Current msg List is:06-01 05:26:47.242 2646 2646 E ANR_LOG : Current msg &lt;1&gt; = &#123; when=+20s0ms what=10 target=com.qti.internal.telephony.gsm.QtiGsmServiceStateTracker &#125;06-01 05:26:47.242 2646 2646 E ANR_LOG : &gt;&gt;&gt;CURRENT MSG DUMP OVER&lt;&lt;&lt;06-01 05:26:47.243 14580 14580 I MediaScannerReceiver: onReceive, intent=Intent &#123; act=android.intent.action.MEDIA_SCANNER_SCAN_FILE dat=file:///sdcard/monkey_screenshot/123_2021-06-01_05-26-49.png flg=0x10 cmp=com.android.providers.media/.MediaScannerReceiver &#125;06-01 05:26:47.245 1457 1457 E ANR_LOG : &gt;&gt;&gt; msg's executing time is too long06-01 05:26:47.245 1457 1457 E ANR_LOG : Blocked msg = &#123; when=-5s541ms what=0 target=android.os.Handler callback=com.android.server.BatteryService$12 &#125; , cost = 5541 ms06-01 05:26:47.245 1457 8210 D ActivityManager: ANR deal 3 appNotResponding for ProcessRecord&#123;7d985f 7916:xxx/u0a3560&#125;, pid = 7916, annotation = executing service xxx/xxx.Service// 捕获到ANR的地方06-01 05:26:53.364 1457 8210 E ActivityManager: ANR in xxx06-01 05:26:53.364 1457 8210 E ActivityManager: PID: 791606-01 05:26:53.364 1457 8210 E ActivityManager: Reason: executing service xxx/xxx.Service06-01 05:26:53.364 1457 8210 E ActivityManager: Load: 0.0 / 0.0 / 0.006-01 05:26:53.364 1457 8210 E ActivityManager: CPU usage from 0ms to 6087ms later:06-01 05:26:53.364 1457 8210 E ActivityManager: 108% 7916/xxx: 21% user + 86% kernel / faults: 15083 minor 47 major06-01 05:26:53.364 1457 8210 E ActivityManager: 9.2% 1457/system_server: 4.9% user + 4.2% kernel / faults: 958 minor ANR发生的过程怀疑是，应用被杀死，但没有杀死Service，然后重启应用，启动过程中CPU占用过高，而出现的ANR 哪些场景会出现ANR 场景1：低内存anr：查看CPU，手机内存低导致anr时，一般以下两个进程CPU使用率高，手机会出现大量应用anr： 35% 90/mmcqd/0: 0% user + 35% kernel18% 49/kswapd0: 0% user + 18% kernel 场景2： 某一个进程的cpu使用率高，导致当前进程无法获取资源，可以根据trace查看是哪个进程在工作； 场景3：主线程卡死： 1）主线程等待其他线程锁waiting to lock； 2） 主线程繁忙；3）主线程对应的native调用栈卡住； 场景4：Activity resume、restart或pause太慢，导致无焦点窗口问题，通常会有黑屏白屏等现象； 场景5：省电精灵智能省电模式冻结后台进程，resume activity时，没有及时解冻，产生无焦点窗口anr； 场景6：其它进程Binder线程耗尽（ProcessState.cpp中指定最大binder线程数，如maxThreads:32），导致当前进程卡在IPCThreadState::talkWithDriver； 场景7：Input dispatching timed out：接收输入事件的窗口出现异常，丢失焦点，伴随冻屏现象 场景8：monkey启动大量对象GC耗时久导致anr。从dumpsys中可以看到启动很多window，从log中看GC耗时很久； 场景9：抓取整机log导致anr。此类问题中，adbd、bugreport、chargelogcat等进程CPU使用率高； 场景10：Framework缺陷导致无焦点窗口问题，activity已经正常resume了（am_on_resume_called），dumpsys中mFocusedWindow为null。 ANR一定会发生吗？不会 可以参考这篇文章：https://juejin.cn/post/6890758574364950541 和 http://gityuan.com/2019/04/06/android-anr/ 比如 input事件： input超时机制为什么是扫雷，而非定时爆炸呢？是由于对于input来说即便某次事件执行时间超过timeout时长，只要用户后续在没有再生成输入事件，则不会触发ANR。 这里的扫雷是指当前输入系统中正在处理着某个耗时事件的前提下，后续的每一次input事件都会检测前一个正在处理的事件是否超时（进入扫雷状态），检测当前的时间距离上次输入事件分发时间点是否超过timeout时长。如果前一个输入事件，则会重置ANR的timeout，从而不会爆炸。 更多细节详见Input系统-ANR原理分析，http://gityuan.com/2017/01/01/input-anr ANR日志生成原理网上大概有这么几种方式： 系统的 system_server 进程在检测到 App 出现 ANR 后，会向出现 ANR 的进程发送 SIGQUIT (signal 3)信号。正常情况下，系统的 libart.so 会收到该信号，并调用 Java 虚拟机的 dump 方法生成 traces。以友盟+的 U-APM 应用性能监控平台为例，集成SDK 后，SDK 会拦截 SIGQUIT。在出现 ANR 时，libcrashsdk.so 会优先收到信号，并生成 traces 和 ANR 日志。在 SDK 处理完信号后，会将信号继续传递给系统的 libart.so，让系统生成 ANR traces.txt。 监控ANR异常，通过反编译Bugly jar包，发现ANR异常捕获是通过FileObserver实现的。当ANR发生的时候，通过监听文件文件夹“data/anr/”的写入情况, 来判断是否发生了ANR，如果监听到data/anr/traces.txt文件写入。说明有此时有ANR异常发生。 FileObserver捕获ANR异常,缺点是Android5.0低权限应用不能监听变化“、data/anr/traces.txt”，只能在root之后才可以 ANR-WatchDog是参考Android WatchDog机制（com.android.server.WatchDog.java）起个单独线程向主线程发送一个变量+1操作，自我休眠自定义ANR的阈值，休眠过后判断变量是否+1完成，如果未完成则告警。但是无法保证能捕捉所有ANR，对阈值的设置直接影响捕获概率。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/06/07/ANR-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANR","slug":"anr","permalink":"http://agehua.github.io/tags/anr/"}]},{"title":"android 画中画功能总结","slug":"Android-PIP-Hack-summary","date":"2021-04-18T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2021/04/19/Android-PIP-Hack-summary/","link":"","permalink":"http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/","excerpt":"首先，Google官方给的画中画api比较简单，想要实现一个画中画需要很多其他交互，本文就以画中画涉及到的具体操作来总结如何实现画中画","text":"首先，Google官方给的画中画api比较简单，想要实现一个画中画需要很多其他交互，本文就以画中画涉及到的具体操作来总结如何实现画中画官方文档： https://developer.android.google.cn/guide/topics/ui/picture-in-picture 简单实现修改清单文件，让activity支持画中画&lt;activity android:name=\"xxx.VideoActivity\" android:configChanges=\"orientation|keyboardHidden|screenSize|keyboard|screenLayout|smallestScreenSize\" android:launchMode=\"singleTop\" android:taskAffinity=\".VideoActivity\" android:supportsPictureInPicture=\"true\" android:stateNotNeeded=\"false\" android:autoRemoveFromRecents=\"true\" android:excludeFromRecents=\"true\" /&gt; 1.设置 android:supportsPictureInPicture 属性为 true 2.configChanges 添加 smallestScreenSize，避免进入画中画导致Activity重建 3.指定新的taskAffinity，可以在小窗模式下打开新的页面，而不是在小窗中打开新页面 4.可以添加stateNotNeeded、autoRemoveFromRecents、excludeFromRecents等，使画中画页面不显示在最近的应用列表中 taskAffinity 需要配合singleTask或singleInstance使用。这里指定为singleTop是有一个小技巧，即可以通过是否添加 intent.addFlags(FLAG_ACTIVITY_NEW_TASK) 标记动态控制是否在新任务栈中打开VideoActivity 注意：如果VideoActivity不添加taskAffinity属性，开启画中画的情况下，那么新启动的Activity有 singleTask或FLAG_ACTIVITY_NEW_TASK标记，新的Activity会展示在画中画中 进入画中画 1.主动触发 getActivity().enterPictureInPictureMode(); 2.离开页面 @Overridepublic void onUserLeaveHint () &#123; if (iWantToBeInPipModeNow()) &#123; enterPictureInPictureMode(); &#125;&#125; 官方只有这两步，但是使用中还会有其他要求，继续往下看： 其他交互操作进入画中画的同时，打开另一个页面// 需要延时，因为画中画只能打开在前台的Activity，不加延时则画中画最上层页面是 VideoDescActivity new Handler().postDelayed(new Runnable() &#123; @Override public void run() &#123; if (null == mActivity) &#123; return; &#125; Intent intent = new Intent(mActivity, VideoDescActivity.class); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); mActivity.startActivity(intent); &#125;&#125;, 300); 点击画中画回到VideoActivity：不用特别处理点击VideoDescActivity上元素，回到VideoActivity重新启动VideoActivity即可Intent intent = new Intent(mActivity, VideoActivity.class);intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TOP);mActivity.startActivity(intent); 点击VideoDescActivity上元素，关闭画中画// 使用本地广播，通知 VideoActivity 收到广播后直接 finishIntent intent = new Intent();intent.setAction(PIP_ACTION_FILTER_ENTER); // 需要 VideoActivity 注册这个actionintent.putExtra(\"closeOrReopen\", true);LocalBroadcastManager.getInstance(CartoonGlobalContext.getAppContext()).sendBroadcast(intent); 监听系统关闭画中画重写Activity onPictureInPictureModeChanged：onPictureInPictureModeChanged(boolean isInPictureInPictureMode, Configuration newConfig) &#123; if (!isInPictureInPictureMode) &#123; // 这里是关闭 &#125;&#125; VideoActivity打开新的页面，比如TimerActivityIntent intent = new Intent(mActivity, TimerActivity.class);mActivity.startActivity(intent); 这里必须使用mActivity，不能是Application，否则 TimerActivity 会显示在默认taskAffinity属性的 activity 上。 关闭TimerActivity后，回到VideoActivity// 重新启动 VideoActivity，并且设置 intent 属性如下：Intent intent1 = new Intent(this, VideoActivity.class);intent1.setAction(Intent.ACTION_MAIN);intent1.addCategory(Intent.CATEGORY_LAUNCHER);startActivity(intent1); VideoActivity关闭后，切回到默认task画中画切到手机桌面上后，将画中画切换为全屏，这时候退出VideoActivity会回到手机桌面，如果需要返回到App的默认activity栈，则需要添加下面的代码： public static void navToLauncherTask(Context appContext) &#123; if (null == appContext || Build.VERSION.SDK_INT &lt; Build.VERSION_CODES.LOLLIPOP) &#123; return; &#125; ActivityManager activityManager = (ActivityManager) appContext.getSystemService(Context.ACTIVITY_SERVICE); // iterate app tasks available and navigate to launcher task (browse task) final List&lt;ActivityManager.AppTask&gt; appTasks = activityManager.getAppTasks(); for (ActivityManager.AppTask task : appTasks) &#123; final Intent baseIntent = task.getTaskInfo().baseIntent; final Set&lt;String&gt; categories = baseIntent.getCategories(); if (categories != null &amp;&amp; categories.contains(Intent.CATEGORY_LAUNCHER)) &#123; task.moveToFront(); return; &#125; &#125;&#125; task 也有 startActivity的方法，感兴趣的可以看一下 注意问题 在支持画中画的activity中，并且开启过画中画，getContext()方法返回值是ContextThemeWrapper，用这个跳转页面（getContext().startActivity），会有栈reparent问题，可以使用XXXActivity.this 或者 view.getContext()代替 REFhttps://developer.android.google.cn/guide/topics/ui/picture-in-picture https://proandroiddev.com/task-management-for-picture-in-picture-mode-on-android-o-882103271cad 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"picture-in-picture","slug":"picture-in-picture","permalink":"http://agehua.github.io/tags/picture-in-picture/"}]},{"title":"Recyclerview 滑动相关功能总结","slug":"RecyclerView_scroll_relatedapi","date":"2020-12-03T16:00:00.000Z","updated":"2024-12-05T09:41:25.324Z","comments":true,"path":"2020/12/04/RecyclerView_scroll_relatedapi/","link":"","permalink":"http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/","excerpt":"本文总结一下RecyclerView提供的滑动相关的api，并探究一下为什么有的滑动方法不会回调监听 onScrollStateChanged(int state)","text":"本文总结一下RecyclerView提供的滑动相关的api，并探究一下为什么有的滑动方法不会回调监听 onScrollStateChanged(int state)RecyclerView scroll 相关API有： scrollTo(int x, int y) scrollBy(int x, int y) scrollToPosition(int position) smoothScrollBy(@Px int dx, @Px int dy) 及其重载方法 smoothScrollToPosition(int position) 当然，还有手势滑动 RecyclerView 通过 addOnScrollListener(OnScrollListener)监听滑动事件 RecyclerView 调用这个方法通知layoutmanager，scroll状态已经改变@Overridepublic void onScrollStateChanged(int state) &#123; super.onScrollStateChanged(recyclerView, newState); if (state == SCROLL_STATE_IDLE) &#123; //滑动停止 &#125;&#125;@Overridepublic void onScrolled(RecyclerView recyclerView, int dx, int dy) &#123; super.onScrolled(recyclerView, dx, dy); //...&#125; 但是并不是所有的滑动行为都会回调到 onScrollStateChanged ,下面来一一分析下每个滑动场景 scrollTo 和 scrollByscrollTo 和 scrollBy 是 View 相关方法，实现的是 View 内容的滑动，效果是 View 控件本身并没有滑动，而是控件上绘制的内容在控件范围内发生滑动。看下在 RecyclerView 里面的实现：// RecyclerView@Overridepublic void scrollTo(int x, int y) &#123; // RecyclerView 不支持滚动到绝对位置，尝试使用 scrollToPosition 替换 Log.w(TAG, \"RecyclerView does not support scrolling to an absolute position. \" + \"Use scrollToPosition instead\");&#125;@Overridepublic void scrollBy(int x, int y) &#123; // 这个方法可以配合实现 NestedScrollingChild 的控件联动 if (mLayout == null) &#123; Log.e(TAG, \"Cannot scroll without a LayoutManager set. \" + \"Call setLayoutManager with a non-null argument.\"); return; &#125; if (mLayoutSuppressed) &#123; return; &#125; final boolean canScrollHorizontal = mLayout.canScrollHorizontally(); final boolean canScrollVertical = mLayout.canScrollVertically(); if (canScrollHorizontal || canScrollVertical) &#123; scrollByInternal(canScrollHorizontal ? x : 0, canScrollVertical ? y : 0, null); &#125;&#125; scrollByInternal 介绍scrollByInternal后面在处理手势拖动的时候也会用到，继续往下看：// RecyclerViewboolean scrollByInternal(int x, int y, MotionEvent ev) &#123; int unconsumedX = 0; int unconsumedY = 0; int consumedX = 0; int consumedY = 0; consumePendingUpdateOperations(); if (mAdapter != null) &#123; mReusableIntPair[0] = 0; mReusableIntPair[1] = 0; // 这里处理滑动 scrollStep(x, y, mReusableIntPair); consumedX = mReusableIntPair[0]; consumedY = mReusableIntPair[1]; unconsumedX = x - consumedX; unconsumedY = y - consumedY; &#125; // ... 分发 nestedscroll 结果 dispatchNestedScroll(consumedX, consumedY, unconsumedX, unconsumedY, mScrollOffset, TYPE_TOUCH, mReusableIntPair); // ... 通知 onScrolled 事件 if (consumedX != 0 || consumedY != 0) &#123; dispatchOnScrolled(consumedX, consumedY); &#125; // ...&#125; dispatchOnScrolled 会通知 onScrolled 的监听者 scrollStep方法，如下：// RecyclerViewvoid scrollStep(int dx, int dy, @Nullable int[] consumed) &#123; // ... int consumedX = 0; int consumedY = 0; if (dx != 0) &#123; // 调用LayoutManager处理滑动 consumedX = mLayout.scrollHorizontallyBy(dx, mRecycler, mState); &#125; if (dy != 0) &#123; consumedY = mLayout.scrollVerticallyBy(dy, mRecycler, mState); &#125; // ...&#125; LayoutManager.scrollHorizontallyBy 介绍本文以下都以 LinearLayoutManager 为例，继续看scrollHorizontallyBy 方法： // LinearLayoutManagerint scrollBy(int delta, RecyclerView.Recycler recycler, RecyclerView.State state) &#123; if (getChildCount() == 0 || delta == 0) &#123; return 0; &#125; ensureLayoutState(); mLayoutState.mRecycle = true; final int layoutDirection = delta &gt; 0 ? LayoutState.LAYOUT_END : LayoutState.LAYOUT_START; final int absDelta = Math.abs(delta); updateLayoutState(layoutDirection, absDelta, true, state); final int consumed = mLayoutState.mScrollingOffset + fill(recycler, mLayoutState, state, false); // ... final int scrolled = absDelta &gt; consumed ? layoutDirection * consumed : delta; mOrientationHelper.offsetChildren(-scrolled); mLayoutState.mLastScrollDelta = scrolled; return scrolled;&#125; mOrientationHelper是LinearLayoutManager 类的一个全局变量，初始化是在：// LinearLayoutManagerpublic void setOrientation(@RecyclerView.Orientation int orientation) &#123; if (orientation != HORIZONTAL &amp;&amp; orientation != VERTICAL) &#123; throw new IllegalArgumentException(\"invalid orientation:\" + orientation); &#125; assertNotInLayoutOrScroll(null); if (orientation != mOrientation || mOrientationHelper == null) &#123; mOrientationHelper = OrientationHelper.createOrientationHelper(this, orientation); mAnchorInfo.mOrientationHelper = mOrientationHelper; mOrientation = orientation; requestLayout(); &#125;&#125; 继续往下看：// abstract class OrientationHelperpublic static OrientationHelper createOrientationHelper( RecyclerView.LayoutManager layoutManager, @RecyclerView.Orientation int orientation) &#123; switch (orientation) &#123; case HORIZONTAL: return createHorizontalHelper(layoutManager); case VERTICAL: return createVerticalHelper(layoutManager); &#125; throw new IllegalArgumentException(\"invalid orientation\");&#125; 以HORIZONTAL 方向为例：public static OrientationHelper createHorizontalHelper( RecyclerView.LayoutManager layoutManager) &#123; return new OrientationHelper(layoutManager) &#123; @Override public int getEndAfterPadding() &#123; return mLayoutManager.getWidth() - mLayoutManager.getPaddingRight(); &#125; @Override public int getEnd() &#123; return mLayoutManager.getWidth(); &#125; @Override public void offsetChildren(int amount) &#123; // 最终还是调用的全局变量 mLayoutManager 的 offsetChildrenHorizontal 方法 mLayoutManager.offsetChildrenHorizontal(amount); // 垂直方向调用的就是下面的方法： // mLayoutManager.offsetChildrenVertical(amount); &#125; //... &#125;&#125;private OrientationHelper(RecyclerView.LayoutManager layoutManager) &#123; mLayoutManager = layoutManager;&#125; mLayoutManager 作为 OrientationHelper 构造方法的唯一参数。点击mLayoutManager.offsetChildrenHorizontal(amount) 方法，跳转到的是RecyclerView.LayoutManger的方法：// RecyclerView.LayoutManger public void offsetChildrenHorizontal(@Px int dx) &#123; if (mRecyclerView != null) &#123; mRecyclerView.offsetChildrenHorizontal(dx); &#125;&#125; 回到RecyclerView的这个方法：public void offsetChildrenHorizontal(@Px int dx) &#123; final int childCount = mChildHelper.getChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; // getChildAt返回的是每个child view mChildHelper.getChildAt(i).offsetLeftAndRight(dx); &#125;&#125; View.offsetLeftAndRight 介绍经过上面的跳转步骤，最终发现会调用到列表里每个View的 offsetLeftAndRight 方法：// Viewpublic void offsetLeftAndRight(int offset) &#123; if (offset != 0) &#123; final boolean matrixIsIdentity = hasIdentityMatrix(); if (matrixIsIdentity) &#123; if (isHardwareAccelerated()) &#123; invalidateViewProperty(false, false); &#125; else &#123; final ViewParent p = mParent; if (p != null &amp;&amp; mAttachInfo != null) &#123; final Rect r = mAttachInfo.mTmpInvalRect; int minLeft; int maxRight; if (offset &lt; 0) &#123; minLeft = mLeft + offset; maxRight = mRight; &#125; else &#123; minLeft = mLeft; maxRight = mRight + offset; &#125; r.set(0, 0, maxRight - minLeft, mBottom - mTop); p.invalidateChild(this, r); &#125; &#125; &#125; else &#123; invalidateViewProperty(false, false); &#125; mLeft += offset; mRight += offset; mRenderNode.offsetLeftAndRight(offset); if (isHardwareAccelerated()) &#123; invalidateViewProperty(false, false); invalidateParentIfNeededAndWasQuickRejected(); &#125; else &#123; if (!matrixIsIdentity) &#123; invalidateViewProperty(false, true); &#125; invalidateParentIfNeeded(); &#125; notifySubtreeAccessibilityStateChangedIfNeeded(); &#125;&#125; 这里RecyclerView的每个子View都是通过改变子 View 的 mLeft、mTop 等坐标，将初始位置值及偏移量传入，即需要滑动到的位置的坐标完成滑动。这里的 mLeft、mTop是指基于父控件的视图坐标系中的坐标 Android 中有两种坐标系： 一种是视图坐标系，以当前控件左上角为坐标原点，向右为 X 轴正方向，向下为 Y 轴正方向，MotionEvent 的 getX()、getY() 方法获取的是点击位置在视图坐标系中的坐标。 另一种是 Android 坐标系，以屏幕左上角为坐标原点，向右为 X 轴正方向，向下为 Y 轴正方向，MotionEvent 的 getRawX()、getRawY() 方法获取的是点击位置在 Android 坐标系中的坐标 小结小结一下，scorllBy 方法通知了onScrolled 回调，但是没有通知 onScrollStateChanged 回调 额外补充一点RecyclerView的布局过程，看上面scrollBy 里调用的 fill 方法// LinearLayoutManager// fill填充方法， 返回的是填充ItemView需要的像素，以便拿去做滚动int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) &#123; // 填充起始位置 final int start = layoutState.mAvailable; if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) &#123; //如果有滚动就执行一次回收 recycleByLayoutState(recycler, layoutState); &#125; // 计算剩余可用的填充空间 int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace; // 用于记录每一次while循环的填充结果 LayoutChunkResult layoutChunkResult = mLayoutChunkResult; // ================== 核心while循环 ==================== while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; // ====== 填充itemView核心填充方法 ====== 屏幕还有剩余可用空间并且还有数据就继续执行 layoutChunk(recycler, state, layoutState, layoutChunkResult); // ... &#125; // 填充完成后修改起始位置 return start - layoutState.mAvailable;&#125; 这个方法是用来填充内容的，更多布局过程可以参考这篇文章：《图文详解LinearLayoutManager填充、测量、布局过程》 scrollToPosition再来看下 scrollToPosition，这个方法会使 RecyclerView 滚动最小的距离，以使目标位置可见，如果目标位置的view没有创建，则滑动不会发生 // RecyclerView.javapublic void scrollToPosition(int position) &#123; if (mLayoutSuppressed) &#123; return; &#125; stopScroll(); if (mLayout == null) &#123; Log.e(TAG, \"Cannot scroll to position a LayoutManager set. \" + \"Call setLayoutManager with a non-null argument.\"); return; &#125; mLayout.scrollToPosition(position); // 实际调用的是LayoutManager的对应方法 awakenScrollBars();&#125; 这个方法调用了LayoutManager的同名方法： // LinearLayoutManager.java@Overridepublic void scrollToPosition(int position) &#123; // 用 mPendingScrollPosition 变量保存方法传入的位置 mPendingScrollPosition = position; mPendingScrollPositionOffset = INVALID_OFFSET; if (mPendingSavedState != null) &#123; mPendingSavedState.invalidateAnchor(); &#125; requestLayout(); // 请求刷新布局&#125; requestLayout()，会重走onMeasure, onLayout过程，在 RecyclerView 的 dispatchLayoutStep1() 中 会调用onLayoutChildren()方法。同时 LinearLayoutManager 重写了onLayoutChildren方法// LinearLayoutManager.java@Overridepublic void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) &#123; // layout algorithm: 布局算法 // 1) by checking children and other variables, find an anchor coordinate and an anchor item position. // 通过检查孩子和其他变量，找到锚坐标和锚点项目位置 mAnchor为布局锚点 理解为不具有的起点. // mAnchor包含了子控件在Y轴上起始绘制偏移量（coordinate）,ItemView在Adapter中的索引位置(position)和布局方向(mLayoutFromEnd) // 2) fill towards start, stacking from bottom 开始填充, 从底部堆叠 // 3) fill towards end, stacking from top 结束填充,从顶部堆叠 // 4) scroll to fulfill requirements like stack from bottom. 滚动以满足堆栈从底部的要求 // resolve layout direction 设置布局方向(VERTICAL/HORIZONTAL) resolveShouldLayoutReverse(); // ... final View focused = getFocusedChild(); if (!mAnchorInfo.mValid || mPendingScrollPosition != RecyclerView.NO_POSITION || mPendingSavedState != null) &#123; // mPendingScrollPosition 值已更新，会进到这里 mAnchorInfo.reset(); // mStackFromEnd需要我们开发者主动调用，不然一直未false // VERTICAL方向为mLayoutFromEnd为false HORIZONTAL方向是为true mAnchorInfo.mLayoutFromEnd = mShouldReverseLayout ^ mStackFromEnd; // 计算更新保存绘制锚点信息 updateAnchorInfoForLayout(recycler, state, mAnchorInfo); mAnchorInfo.mValid = true; &#125; else if (focused != null &amp;&amp; (mOrientationHelper.getDecoratedStart(focused) &gt;= mOrientationHelper.getEndAfterPadding() || mOrientationHelper.getDecoratedEnd(focused) &lt;= mOrientationHelper.getStartAfterPadding())) &#123; mAnchorInfo.assignFromViewAndKeepVisibleRect(focused, getPosition(focused)); &#125; // ... 如果 mPendingScrollPosition 有效，则会在 prelayout 阶段在用到这个值 if (state.isPreLayout() &amp;&amp; mPendingScrollPosition != RecyclerView.NO_POSITION &amp;&amp; mPendingScrollPositionOffset != INVALID_OFFSET) &#123; final View existing = findViewByPosition(mPendingScrollPosition); if (existing != null) &#123; final int current; final int upcomingOffset; if (mShouldReverseLayout) &#123; current = mOrientationHelper.getEndAfterPadding() - mOrientationHelper.getDecoratedEnd(existing); upcomingOffset = current - mPendingScrollPositionOffset; &#125; else &#123; current = mOrientationHelper.getDecoratedStart(existing) - mOrientationHelper.getStartAfterPadding(); upcomingOffset = mPendingScrollPositionOffset - current; &#125; if (upcomingOffset &gt; 0) &#123; extraForStart += upcomingOffset; &#125; else &#123; extraForEnd -= upcomingOffset; &#125; &#125; &#125; // ...省略根据布局方向调用 fill 方法填充&#125;// 更新 anchorInfoprivate boolean updateAnchorFromPendingData(RecyclerView.State state, AnchorInfo anchorInfo) &#123; //... // 简单理解，如果位置大于itemCount，不会更新 anchorInfo，并且清除 mPendingScrollPosition 的值 if (mPendingScrollPosition &lt; 0 || mPendingScrollPosition &gt;= state.getItemCount()) &#123; mPendingScrollPosition = RecyclerView.NO_POSITION; mPendingScrollPositionOffset = INVALID_OFFSET; if (DEBUG) &#123; Log.e(TAG, \"ignoring invalid scroll position \" + mPendingScrollPosition); &#125; return false; &#125; // ...&#125; 小结上面代码可以看出，如果scrollToPosition(position) 的参数 position 所在位置还没有view被layout，则滑动不会被处理。 同时也可以看出 scrollToPosition 是 LayoutManager 通过 requestLayout 方式来刷新 ReycclerView，所以并不会通知 onScrollStateChanged 这里额外介绍一下根据 mAnchor 和布局方向填充view的逻辑 圆形红点就是我们布局算法在第一步updateAnchorInfoForLayout方法中计算出来的填充锚点位置。 第一种情况是屏幕显示的位置在RecyclerView的最底部，那么就只有一种填充方向为formEnd 第二种情况是屏幕显示的位置在RecyclerView的顶部，那么也只有一种填充方向为formStart 第三种情况应该是最常见的，屏幕显示的位置在RecyclerView的中间，那么填充方向就有formEnd和formStart两种情况，这就是 fill 方法调用两次的原因。 上面是RecyclerView的方向为VERTICAL的情况，当为HORIZONTAL方向的时候填充算法是不变的。 smoothScrollBysmoothScrollBy有很多重载方法，直接看最终的： // RecyclerView.javavoid smoothScrollBy(@Px int dx, @Px int dy, @Nullable Interpolator interpolator, int duration, boolean withNestedScrolling) &#123; // ... 前面都是是否能滑动判断 if (dx != 0 || dy != 0) &#123; boolean durationSuggestsAnimation = duration == UNDEFINED_DURATION || duration &gt; 0; if (durationSuggestsAnimation) &#123; if (withNestedScrolling) &#123; int nestedScrollAxis = ViewCompat.SCROLL_AXIS_NONE; if (dx != 0) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_HORIZONTAL; &#125; if (dy != 0) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_VERTICAL; &#125; startNestedScroll(nestedScrollAxis, TYPE_NON_TOUCH); &#125; mViewFlinger.smoothScrollBy(dx, dy, duration, interpolator); &#125; else &#123; scrollBy(dx, dy); &#125; &#125;&#125; 最终调用了mViewFlinger.smoothScrollBy 方法：// ViewFlinger.smoothScrollBypublic void smoothScrollBy(int dx, int dy, int duration, @Nullable Interpolator interpolator) &#123; // Handle cases where parameter values aren't defined. if (duration == UNDEFINED_DURATION) &#123; duration = computeScrollDuration(dx, dy, 0, 0); &#125; if (interpolator == null) &#123; interpolator = sQuinticInterpolator; &#125; // If the Interpolator has changed, create a new OverScroller with the new // interpolator. if (mInterpolator != interpolator) &#123; mInterpolator = interpolator; mOverScroller = new OverScroller(getContext(), interpolator); &#125; // Reset the last fling information. mLastFlingX = mLastFlingY = 0; // 调用RecyclerView的setScrollState方法，通知滑动事件开始 setScrollState(SCROLL_STATE_SETTLING); mOverScroller.startScroll(0, 0, dx, dy, duration); if (Build.VERSION.SDK_INT &lt; 23) &#123; mOverScroller.computeScrollOffset(); &#125; postOnAnimation();&#125; 小结smoothScrollBy 调用了 RecyclerView.setScrollState方法，最终会通知 onScrollStateChanged 的监听 smoothScrollToPosition再来看下 smoothScrollToPosition// RecyclerView.javapublic void smoothScrollToPosition(int position) &#123; if (mLayoutSuppressed) &#123; return; &#125; if (mLayout == null) &#123; Log.e(TAG, \"Cannot smooth scroll without a LayoutManager set. \" + \"Call setLayoutManager with a non-null argument.\"); return; &#125; mLayout.smoothScrollToPosition(this, mState, position);&#125; 上面直接调用了LayoutManager的同名方法// LinearLayoutManager.java@Overridepublic void smoothScrollToPosition(RecyclerView recyclerView, RecyclerView.State state, int position) &#123; LinearSmoothScroller linearSmoothScroller = new LinearSmoothScroller(recyclerView.getContext()); linearSmoothScroller.setTargetPosition(position); startSmoothScroll(linearSmoothScroller);&#125; 可以看到每次调用方法，都会创建一个LinearSmoothScroller，LinearSmoothScroller的父类是RecyclerView.SmoothScroller 最终调用的是 mRecyclerView.mViewFlinger.postOnAnimation();ViewFlinger其实一个Runnable,在postOnAnimation()内部又将该Runnable发送出去了那么我们在看下ViewFlinger的run()方法就行了。// RecyclerView.ViewFlinger@Overridepublic void run() &#123; // ... final OverScroller scroller = mScroller; //获得layoutManger中的SmoothScroller final SmoothScroller smoothScroller = mLayout.mSmoothScroller; if (scroller.computeScrollOffset()) &#123;//如果是第一次走，会返回false // ...省略部分代码 if (mAdapter != null) &#123; mReusableIntPair[0] = 0; mReusableIntPair[1] = 0; scrollStep(unconsumedX, unconsumedY, mReusableIntPair); consumedX = mReusableIntPair[0]; consumedY = mReusableIntPair[1]; // ... &#125; if (consumedX != 0 || consumedY != 0) &#123; dispatchOnScrolled(consumedX, consumedY); &#125; &#125; if (smoothScroller != null) &#123; if (smoothScroller.isPendingInitialRun()) &#123; smoothScroller.onAnimation(0, 0); &#125; if (!mReSchedulePostAnimationCallback) &#123; smoothScroller.stop(); //stop if it does not trigger any scroll &#125; &#125; // ...&#125; 小结可以看出在ViewFlinger 的 run()方法中，调用了dispatchOnScrolled(consumedX, consumedY)，通知了onScrolled() 真正产生滑动距离consumedX、consumedY 的方法是 scrollStep() 。这个方法前面分析 scrollBy()方法的时候已经分析过了，最终会调用到每个view的offsetLeftAndRight()方法。 补充滚到到一个屏幕外的位置scrollToPosition 和 smoothScrollToPosition 只能保证指定位置的item滑动到屏幕可见，如果指定的item本来就已在屏幕可见范围，则不会滑动，并且屏幕外的item滑到可见范围后，还需手动置顶，手动置顶可以调用 LinearLayoutManager.scrollToPositionWithOffset(position, 0)recyclerView.scrollToPosition(pos);linearLayoutManager.scrollToPositionWithOffset(pos, 0) 还可以使用另一种方式：可以继承 LinearSmoothScroller，重写getVerticalSnapPreference()或getHorizontalSnapPreference()getVerticalSnapPreference()// LinearSmoothScrollerprotected int getHorizontalSnapPreference() &#123; return mTargetVector == null || mTargetVector.x == 0 ? SNAP_TO_ANY : mTargetVector.x &gt; 0 ? SNAP_TO_END : SNAP_TO_START;&#125;@Overrideprotected int getVerticalSnapPreference() &#123; // 子view与RecyclerView垂直方向顶部对齐 return SNAP_TO_START; &#125; 之后这样调用就可以：final TopSmoothScroller mTopScroller = new TopSmoothScroller(this);mTopScroller.setTargetPosition(position);mRecyclerView.getLayoutManager.startSmoothScroll(mTopScroller); 补充 scrollToPositionWithOffset这个方式是LinearLayoutManager才有的方法，RecyclerView没有。RecyclerView可以调用的是LinearLayoutManger.scrollToPosition(position) 这两个方法区别是区别是RecyclerView.scrollToPosition(position) 的 mPendingScrollPositionOffset 值为 INVALID_OFFSET = Integer.MIN_VALUEpublic void scrollToPositionWithOffset(int position, int offset) &#123; mPendingScrollPosition = position; mPendingScrollPositionOffset = offset; if (mPendingSavedState != null) &#123; mPendingSavedState.invalidateAnchor(); &#125; requestLayout();&#125; 前面也提到过了，这个方法第二个参数传0，可以让 position 位置对应的view置顶 同样这个方法是 LayoutManager 通过 requestLayout 方式来刷新 ReycclerView，所以并不会通知 onScrollStateChanged。 手势滑动手势处理肯定是在RecyclerView的onTouchEvent方法中了： @Overridepublic boolean onTouchEvent(MotionEvent e) &#123; switch (action) &#123; case MotionEvent.ACTION_MOVE: &#123; // ...判断手势索引，避免多指引起冲突 final int index = e.findPointerIndex(mScrollPointerId); final int x = (int) (e.getX(index) + 0.5f); final int y = (int) (e.getY(index) + 0.5f); int dx = mLastTouchX - x; int dy = mLastTouchY - y; if (mScrollState != SCROLL_STATE_DRAGGING) &#123; boolean startScroll = false; if (canScrollHorizontally) &#123; if (dx &gt; 0) &#123; dx = Math.max(0, dx - mTouchSlop); &#125; else &#123; dx = Math.min(0, dx + mTouchSlop); &#125; if (dx != 0) &#123; startScroll = true; &#125; &#125; if (canScrollVertically) &#123; if (dy &gt; 0) &#123; dy = Math.max(0, dy - mTouchSlop); &#125; else &#123; dy = Math.min(0, dy + mTouchSlop); &#125; if (dy != 0) &#123; startScroll = true; &#125; &#125; if (startScroll) &#123; // 可以滑动。设置状态 setScrollState(SCROLL_STATE_DRAGGING); &#125; &#125; if (mScrollState == SCROLL_STATE_DRAGGING) &#123; mReusableIntPair[0] = 0; mReusableIntPair[1] = 0; if (dispatchNestedPreScroll( // 处理 nested 联动 canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, mReusableIntPair, mScrollOffset, TYPE_TOUCH )) &#123; dx -= mReusableIntPair[0]; dy -= mReusableIntPair[1]; // Updated the nested offsets mNestedOffsets[0] += mScrollOffset[0]; mNestedOffsets[1] += mScrollOffset[1]; // Scroll has initiated, prevent parents from intercepting getParent().requestDisallowInterceptTouchEvent(true); &#125; mLastTouchX = x - mScrollOffset[0]; mLastTouchY = y - mScrollOffset[1]; if (scrollByInternal( // 调用 scrollByInternal() 让每个view自己滑动 canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, e)) &#123; getParent().requestDisallowInterceptTouchEvent(true); &#125; &#125; &#125; break; case MotionEvent.ACTION_UP: &#123; mVelocityTracker.addMovement(vtev); eventAddedToVelocityTracker = true; mVelocityTracker.computeCurrentVelocity(1000, mMaxFlingVelocity); final float xvel = canScrollHorizontally ? -mVelocityTracker.getXVelocity(mScrollPointerId) : 0; final float yvel = canScrollVertically ? -mVelocityTracker.getYVelocity(mScrollPointerId) : 0; // 跟踪滑动速度，是否采取 fling 操作 if (!((xvel != 0 || yvel != 0) &amp;&amp; fling((int) xvel, (int) yvel))) &#123; setScrollState(SCROLL_STATE_IDLE); &#125; resetScroll(); &#125; break; &#125;&#125; 小结这里分两种情况： 没有触发fling操作，直接调用scrollByInternal()方法，最终调用View的offsetLeftAndRight(offset)方法。 触发fling操作，由mViewFlinger.fling(velocityX, velocityY)处理，最终在 mViewFlinger的run()方法中，调用View的offsetLeftAndRight(offset)方法。 总结看到这里不知道大家有没有被绕晕，其实不管方法是哪个，都是调用每个子View的offsetLeftAndRight(offset)来实现列表的滑动 scrollTo &emsp; scrollBy scrollToPosition smoothScrollBy smoothScrollToPosition onScrolled 无反应 触发 位置可见无反应，否则触发 触发 位置可见无反应，否则触发 onScrollStateChanged 无反应 无反应 无反应 触发 位置可见无反应，否则触发 手势滑动两者都会触发，只不过因为放不下了，没有在表格里展示 :) REF图文详解LinearLayoutManager填充、测量、布局过程: https://www.jianshu.com/p/e9752f8890c8 View 的滑动原理和实现方式 : https://www.jianshu.com/p/a177869b0382 用SmoothScroller实现RecyclerView滚动到指定位置并置顶: https://blog.csdn.net/weixin_39428125/article/details/89032646 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"},{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"Kotlin 与 Java 语言比较","slug":"Diffrence-between-kotlin&Java","date":"2020-10-25T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2020/10/26/Diffrence-between-kotlin&Java/","link":"","permalink":"http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&Java/","excerpt":"本文整理了一些 Kotlin 与 Java 语言的区别，方便从Java转型学习Kotlin的同学。\nKotlin 解决了一些 Java 中的问题Kotlin 通过以下措施修复了 Java 中一系列长期困扰我们的问题：","text":"本文整理了一些 Kotlin 与 Java 语言的区别，方便从Java转型学习Kotlin的同学。 Kotlin 解决了一些 Java 中的问题Kotlin 通过以下措施修复了 Java 中一系列长期困扰我们的问题：+代表理解难度 空引用由类型系统控制（可空类型与非空类型）(+) 无原始类型(+) Kotlin 中数组是不型变的(++) 相对于 Java 的 SAM(Single Abstract Method)-转换，Kotlin 有更合适的函数类型(++) 没有通配符的使用处型变(+++) Kotlin 没有受检异常(+)Java 有而 Kotlin 没有的东西 受检异常 原始类型 —— 字节码会尽可能试用原生类型，但不是显式可用的。 静态成员 —— 以 伴生对象、 顶层函数、 扩展函数 或者 @JvmStatic 取代。 通配符类型 —— 以 声明处协变 与 类型投影 取代。 三目操作符 a ? b : c —— 以 if 表达式取代Kotlin 有而 Java 没有的东西 Lambda 表达式 + 内联函数 = 高性能自定义控制结构(++) 扩展函数 空安全 智能类型转换 字符串模板 类的属性 主构造函数 委托 变量与属性类型的类型推断 单例 声明处型变 &amp; 类型投影 区间表达式 in a...b step 2 操作符重载 operator关键字 伴生对象 companion 数据类 data class A 密封类 sealed class A 分离用于只读与可变集合的接口 MutableList, MutableSet, MutableMap 协程 数组支持泛型，不会协变 空安全var a: String = \"abc\" // 默认情况下，常规初始化意味着非空a = null // 编译错误var b: String? = \"abc\" // 可以设置为空b = null // okprint(b)val l = b.length // 错误：变量“b”可能为空 但是我们还是需要访问该属性，对吧？有几种方式可以做到 在条件中检测 null首先，可以显式检测 b 是否为 null，并分别处理两种可能：val l = if (b != null) b.length else -1 安全的调用第二个选择是安全调用操作符，写作 ?.val a = \"Kotlin\"val b: String? = nullprintln(b?.length)println(a?.length) // 无需安全调用 如果 b 非空，就返回 b.length，否则返回 null，这个表达式的类型是 Int?。 对集合，如果要只对非空值执行某个操作，安全调用操作符可以与 let 一起使用：val listWithNulls: List&lt;String?&gt; = listOf(\"Kotlin\", null)for (item in listWithNulls) &#123; item?.let &#123; println(it) &#125; // 输出 Kotlin 并忽略 null&#125; 安全调用也可以出现在赋值的左侧。这样，如果调用链中的任何一个接收者为空都会跳过赋值，而右侧的表达式根本不会求值：// 如果 `person` 或者 `person.department` 其中之一为空，都不会调用该函数：person?.department?.head = managersPool.getManager() Elvis 操作符当我们有一个可空的引用 b 时，我们可以说“如果 b 非空，我使用它；否则使用某个非空的值”：val l: Int = if (b != null) b.length else -1 除了完整的 if-表达式，这还可以通过 Elvis 操作符表达，写作 ?:：val l = b?.length ?: -1 如果 ?: 左侧表达式非空，elvis 操作符就返回其左侧表达式，否则返回右侧表达式。 请注意，当且仅当左侧为空时，才会对右侧表达式求值。 !! 操作符第三种选择是为 NPE 爱好者准备的：非空断言运算符（!!）将任何值转换为非空类型，若该值为空则抛出异常。我们可以写 b!! ，这会返回一个非空的 b 值 （例如：在我们例子中的 String）或者如果 b 为空，就会抛出一个 NPE 异常：val l = b!!.length 安全的类型转换如果对象不是目标类型，那么常规类型转换可能会导致 ClassCastException。 另一个选择是使用安全的类型转换，如果尝试转换不成功则返回 null：val aInt: Int? = a as? Int 可空类型的集合如果你有一个可空类型元素的集合，并且想要过滤非空元素，你可以使用 filterNotNull 来实现：val nullableList: List&lt;Int?&gt; = listOf(1, 2, null, 4)val intList: List&lt;Int&gt; = nullableList.filterNotNull() kotlin无原始类型在 Kotlin 中，所有东西都是对象，在这个意义上讲我们可以在任何变量上调用成员函数与属性。 一些类型可以有特殊的内部表示——例如，数字、字符以及布尔值可以在运行时表示为原生类型值，但是对于用户来说，它们看起来就像普通的类val b: Byte = 1val c:Double = b.toDouble() 型变Java 类型系统中最棘手的部分之一是通配符类型（T，E，K，V，？）。 而 Kotlin 中没有。 相反，它有两个其他的东西：型变（variance）与类型投影（type projections），型变包括声明处型变和使用处型变。 首先，让我们思考为什么 Java 需要那些神秘的通配符。在 《Effective Java》第三版 解释了该问题——第 31 条：利用有限制通配符来提升 API 的灵活性。首先，Java 中的泛型是不型变的，这意味着 List&lt;String&gt; 并不是 List&lt;Object&gt;的子类型。为什么这样？ 如果 List 不是不型变的，它就没比 Java 的数组好到哪去，因为如下代码会通过编译然后导致运行时异常：// JavaList&lt;String&gt; strs = new ArrayList&lt;String&gt;();List&lt;Object&gt; objs = strs; // ！！！此处的编译器错误让我们避免了之后的运行时异常objs.add(1); // 这里我们把一个整数放入一个字符串列表String s = strs.get(0); // ！！！ ClassCastException：无法将整数转换为字符串 因此，Java 禁止这样的事情以保证运行时的安全。但这样会有一些影响。例如，考虑 Collection 接口中的 addAll() 方法。该方法的签名应该是什么？直觉上，我们会这样：// Javainterface Collection&lt;E&gt; …… &#123; void addAll(Collection&lt;E&gt; items);&#125; 但随后，我们就无法做到以下简单的事情（这是完全安全）// Javavoid copyAll(Collection&lt;Object&gt; to, Collection&lt;String&gt; from) &#123; to.addAll(from); // ！！！对于这种简单声明的 addAll 将不能编译： // Collection&lt;String&gt; 不是 Collection&lt;Object&gt; 的子类型&#125; （在 Java 中，我们艰难地学到了这个教训，参见《Effective Java》第三版，第 28 条：列表优先于数组） 这就是为什么 addAll() 的实际签名是以下这样：// Javainterface Collection&lt;E&gt; …… &#123; void addAll(Collection&lt;? extends E&gt; items);&#125; 通配符类型参数 ? extends E 表示此方法接受 E 或者 E 的 一些子类型对象的集合，而不只是 E 自身。 这意味着我们可以安全地从其中（该集合中的元素是 E 的子类的实例）读取 E，但不能写入， 因为我们不知道什么对象符合那个未知的 E 的子类型。 反过来，该限制可以让Collection&lt;String&gt;表示为Collection&lt;? extends Object&gt;的子类型。 简而言之，带 extends 限定（上界）的通配符类型使得类型是协变的（covariant）。 理解为什么这个技巧能够工作的关键相当简单：如果只能从集合中获取元素，那么使用 String 的集合， 并且从其中读取 Object 也没问题 。反过来，如果只能向集合中 放入 元素，就可以用 Object 集合并向其中放入 String：在 Java 中有 List&lt;? super String&gt; 是 List&lt;Object&gt; 的一个超类。 后者称为 逆变性（contravariance），并且对于 List &lt;? super String&gt; 你只能调用接受 String 作为参数的方法 （例如，你可以调用 add(String) 或者 set(int, String)），当然如果调用函数返回 List&lt;T&gt; 中的 T，你得到的并非一个 String 而是一个 Object。 看一个关于java通配符集合的经典图： Joshua Bloch 称那些你只能从中读取的对象为生产者，并称那些你只能写入的对象为消费者。他建议：“为了灵活性最大化，在表示生产者或消费者的输入参数上使用通配符类型”，并提出了以下助记符： PECS 代表生产者-Extends、消费者-Super（Producer-Extends, Consumer-Super）。 注意：如果你使用一个生产者对象，如 List&lt;? extends Foo&gt;，在该对象上不允许调用 add() 或 set()。但这并不意味着该对象是不可变的：例如，没有什么阻止你调用 clear()从列表中删除所有元素，因为 clear() 根本无需任何参数。通配符（或其他类型的型变）保证的唯一的事情是类型安全。不可变性完全是另一回事。 Kotlin 中的 Java 泛型Kotlin 的泛型与 Java 有点不同。当将 Java 类型导入 Kotlin 时，我们会执行一些转换： 消费者 in, 生产者 out! :-) Java 的通配符转换成类型投影 Foo&lt;? extends Bar&gt; 转换成 Foo&lt;out Bar!&gt;! Foo&lt;? super Bar&gt; 转换成 Foo&lt;in Bar!&gt;! Java的原始类型转换成星投影 List 转换成 List&lt;*&gt;!，即 List&lt;out Any?&gt;! 如果泛型类型具有多个类型参数，则每个类型参数都可以单独投影。 例如，如果类型被声明为 interface Function &lt;in T, out U&gt;，我们可以想象以下星投影： Function&lt;*, String&gt; 表示 Function&lt;in Nothing, String&gt;； Function&lt;Int, *&gt; 表示 Function&lt;Int, out Any?&gt;； Function&lt;*, *&gt; 表示 Function&lt;in Nothing, out Any?&gt;。 注意：星投影非常像 Java 的原始类型，但是安全。 和 Java 一样，Kotlin 在运行时不保留泛型，即对象不携带传递到他们构造器中的那些类型参数的实际类型。 即 ArrayList&lt;Integer&gt;() 和 ArrayList&lt;Character&gt;() 是不能区分的。 这使得执行 is-检测不可能照顾到泛型。 Kotlin 只允许 is-检测星投影的泛型类型：if (a is List&lt;Int&gt;) // 错误：无法检测它是否真的是一个 Int 列表// butif (a is List&lt;*&gt;) // OK：不保证列表的内容 类型投影的使用处型变fun copy(from: Array&lt;out Any&gt;, to: Array&lt;Any&gt;) &#123; …… &#125; 简单介绍下，这里 out 修饰的数组只能调用 get()，对应于 Java 的 Array&lt;? extends Object&gt;。fun fill(dest: Array&lt;in String&gt;, value: String) &#123; …… &#125; Array&lt;in String&gt; 对应于 Java 的 Array&lt;? super String&gt;，也就是说，你可以传递一个 CharSequence 数组或一个 Object 数组给 fill() 函数。 Kotlin 中数组是不型变的Kotlin 中数组是不型变的（invariant）。这意味着 Kotlin 不让我们把 Array&lt;String&gt;赋值给 Array&lt;Any&gt;，以防止可能的运行时失败。 但是你可以使用 Array&lt;out Any&gt; 创建数组 arrayOf() 函数我们可以使用库函数 arrayOf() 来创建一个数组并传递元素值给它，这样 arrayOf(1, 2, 3) 创建了 array [1, 2, 3]。 val a = arrayOf(\"Hello\", \"world\")// 这里，arrayOf() 函数创建了一个 Array&lt;String&gt; 对象val arr = arrayOf(\"aaa\", \"bbb\", 123, true) // Array&lt;Any&gt;println(arr[2]) emptyArray() 函数 // emptyArray() 函数是创建一个长度为 0 的 null 数组，然后将它强制转换为指定类型的数组。// 所以我们可以用 arrayOfNulls&lt;T&gt;(0) 替代 emptyArray() 函数// 因为 emptyArray() 函数需要转换为特定的数组类型，所以定义变量需要指定数组类型，否则出现编译错误val emptyArray1: Array&lt;String?&gt; = emptyArray()// 也可以写成 val emptyArray2: Array&lt;String?&gt; = arrayOfNulls(0)，这里是类型推断val emptyArray2 = arrayOfNulls&lt;String?&gt;(0)println(Arrays.equals(emptyArray1, emptyArray2)) // 输出 true arrayOfNulls() 函数 val fixedSizeArray = arrayOfNulls&lt;Int&gt;(5)// 直接指定长度，返回一个长度指定、所有值都是 null 的数组。 不使用 Array 类, 使用装箱操作比如, 对于 Int 类型数组, 使用 IntArray 类替代 Array 类： val arr = arrayOf(1, 2, 3)val intArr = intArrayOf(1, 2, 3) //同理还有 booleanArrayOf() 等 声明处型变假设有一个泛型接口 Source&lt;T&gt;，该接口中不存在任何以 T 作为参数的方法，只是方法返回 T 类型值：// Javainterface Source&lt;T&gt; &#123; T nextT();&#125; 那么，在 Source &lt;Object&gt; 类型的变量中存储 Source &lt;String&gt;实例的引用是极为安全的——没有消费者-方法可以调用。但是 Java 并不知道这一点，并且仍然禁止这样操作：// Javavoid demo(Source&lt;String&gt; strs) &#123; Source&lt;Object&gt; objects = strs; // ！！！在 Java 中不允许 // ……&#125; 为了修正这一点，我们必须声明对象的类型为 Source&lt;? extends Object&gt;，这是毫无意义的，因为我们可以像以前一样在该对象上调用所有相同的方法，所以更复杂的类型并没有带来价值。但编译器并不知道。 在 Kotlin 中，有一种方法向编译器解释这种情况。这称为声明处型变：我们可以标注 Source 的类型参数 T 来确保它仅从 Source&lt;T&gt; 成员中返回（生产），并从不被消费。 为此，我们提供 out 修饰符：interface Source&lt;out T&gt; &#123; fun nextT(): T&#125;​fun demo(strs: Source&lt;String&gt;) &#123; val objects: Source&lt;Any&gt; = strs // 这个没问题，因为 T 是一个 out-参数 // ……&#125; 一般原则是：当一个类 C 的类型参数 T 被声明为 out 时，它就只能出现在 C 的成员的输出-位置，但回报是 C&lt;Base&gt; 可以安全地作为 C&lt;Derived&gt;的超类。 简而言之，他们说类 C 是在参数 T 上是协变的，或者说 T 是一个协变的类型参数。 你可以认为 C 是 T 的生产者，而不是 T 的消费者。 这里，out 由于它在类型参数声明处提供，所以我们称之为声明处型变. 泛型函数不仅类可以有类型参数。函数也可以有。类型参数要放在函数名称之前fun &lt;T&gt; singletonList(item: T): List&lt;T&gt; &#123; // ……&#125;fun &lt;T&gt; T.basicToString(): String &#123; // 扩展函数 // ……&#125; 要调用泛型函数，在调用处函数名之后指定类型参数即可：val l = singletonList&lt;Int&gt;(1) 可以省略能够从上下文中推断出来的类型参数，所以以下示例同样适用：val l = singletonList(1) 泛型函数约束的上界 最常见的约束类型是与 Java 的 extends 关键字对应的 上界： fun &lt;T : Comparable&lt;T&gt;&gt; sort(list: List&lt;T&gt;) &#123; …… &#125; 冒号之后指定的类型是上界：只有 Comparable 的子类型可以替代 T。 例如： sort(listOf(1, 2, 3)) // OK。Int 是 Comparable&lt;Int&gt; 的子类型sort(listOf(HashMap&lt;Int, String&gt;())) // 错误：HashMap&lt;Int, String&gt; 不是sort(listOf(1, 2, 3)) // OK。Int 是 Comparable&lt;Int&gt; 的子类型sort(listOf(HashMap&lt;Int, String&gt;())) // 错误：HashMap&lt;Int, String&gt; 不是 Comparable&lt;HashMap&lt;Int, String&gt;&gt; 的子类型 默认的上界（如果没有声明）是 Any?。在尖括号中只能指定一个上界。 如果同一类型参数需要多个上界，我们需要一个单独的 where-子句： fun &lt;T&gt; copyWhenGreater(list: List&lt;T&gt;, threshold: T): List&lt;String&gt; where T : CharSequence, T : Comparable&lt;T&gt; &#123; return list.filter &#123; it &gt; threshold &#125;.map &#123; it.toString() &#125;&#125; 所传递的类型必须同时满足 where 子句的所有条件。在上述示例中，类型 T 必须既实现了 CharSequence 也实现了 Comparable。 Kotlin与java8的 SAM 转换对比只有一个抽象方法的接口称为函数式接口或 SAM（Single Abstract Method 单一抽象方法）接口。函数式接口可以有多个非抽象成员，但只能有一个抽象成员。SAM 实际上这是java8中提出的概念，你就把他理解为是只有一个抽象方法的接口的就可以了 可以用 fun 修饰符在 Kotlin 中声明一个函数式接口。fun interface KRunnable &#123; fun invoke()&#125; SAM 转换对于函数式接口，可以通过 lambda 表达式实现 SAM 转换，从而使代码更简洁、更有可读性。 使用 lambda 表达式可以替代手动创建实现函数式接口的类。 通过 SAM 转换， Kotlin 可以将其签名与接口的单个抽象方法的签名匹配的任何 lambda 表达式转换为实现该接口的类的实例。例如，有这样一个 Kotlin 函数式接口：fun interface IntPredicate &#123; fun accept(i: Int): Boolean&#125; 如果不使用 SAM 转换，那么你需要像这样编写代码：// 创建一个类的实例val isEven = object : IntPredicate &#123; override fun accept(i: Int): Boolean &#123; return i % 2 == 0 &#125;&#125; 通过利用 Kotlin 的 SAM 转换，可以改为以下等效代码：// 通过 lambda 表达式创建一个实例val isEven = IntPredicate &#123; it % 2 == 0 &#125; 可以通过更短的 lambda 表达式替换所有不必要的代码。 fun interface IntPredicate &#123; fun accept(i: Int): Boolean&#125;​val isEven = IntPredicate &#123; it % 2 == 0 &#125;​fun main() &#123; println(\"Is 7 even? - $&#123;isEven.accept(7)&#125;\")&#125; 再看一个开发中用到的代码：ExecutorService executorService= Executors.newScheduledThreadPool(3); executorService.execute(new Runnable() &#123; @Override public void run() &#123; System.out.println(\"hello world\"); &#125; &#125;); 用下面的java8中的lambda 来写 也是可以的。executorService.execute(()-&gt;System.out.println(\"hello world\")); kotlin中的lambda 这里可以这么写val executorService: ExecutorService = Executors.newScheduledThreadPool(3)//kotlin中的 匿名内部类的标准写法executorService.submit(object :Runnable&#123; // object 作为关键字，这里代表对象表示 override fun run() &#123; System.out.println(\"hello world\") &#125;&#125;)// 使用lambda表达式的精简写法executorService.submit &#123; System.out.println(\"hello world\") &#125; 这个kotlin的lambda的类型就是 ()-&gt;Unit 是一个没有参数也没有返回值的类型 kotlin编译器遇到上面的代码，实际上是帮我们生成了一个函数：fun Runnable(block:() -&gt; Unit):Runnable &#123; return object: Runnable &#123; override fun run() &#123; block() &#125; &#125;&#125; 这个Runnable函数的意思是接收一个方法，别名是 block，返回一个Runnable对象，并在Runnable对象的run方法中，调用 block 方法。这里的 ()-&gt;Unit 是一个kotlin函数类型 函数类型Kotlin 使用类似 (Int) -&gt; String 的一系列函数类型来处理函数的声明. 这些类型具有与函数签名相对应的特殊表示法，即它们的参数和返回值： 所有函数类型都有一个圆括号括起来的参数类型列表以及一个返回类型：(A, B) -&gt; C表示接受类型分别为 A 与 B 两个参数并返回一个 C 类型值的函数类型。 参数类型列表可以为空，如 () -&gt; A。Unit 返回类型不可省略。 函数类型可以有一个额外的接收者类型，它在表示法中的点之前指定： 类型 A.(B) -&gt; C 表示可以在 A 的接收者对象上以一个 B 类型参数来调用并返回一个 C 类型值的函数。 带有接收者的函数字面值通常与这些类型一起使用。 挂起函数属于特殊种类的函数类型，它的表示法中有一个 suspend 修饰符 ，例如 suspend () -&gt; Unit或者 suspend A.(B) -&gt; C。 函数类型表示法可以选择性地包含函数的参数名：(x: Int, y: Int) -&gt; Point。 这些名称可用于表明参数的含义。 如需将函数类型指定为可空，请使用圆括号：((Int, Int) -&gt; Int)?。 函数类型可以使用圆括号进行接合：(Int) -&gt; ((Int) -&gt; Unit) 箭头表示法是右结合的，(Int) -&gt; (Int) -&gt; Unit 与前述示例等价，但不等于 ((Int) -&gt; (Int)) -&gt; Unit。 还可以通过使用类型别名给函数类型起一个别称： typealias ClickHandler = (Button, ClickEvent) -&gt; Unit 函数类型实例化及调用 使用 lambda 表达式或匿名函数进行实例化 var onItemClick:(Int, String) -&gt; Unit = &#123; a:Int, b:String -&gt; Log.e(\"AAA\", \"aaa$a$b\") // 配合lambda表达式&#125;onItemClick.invoke(1, \"2\")onItemClick(1, \"2\") // 这两种方式都可以val f:(Int, String) -&gt; String = fun(a:Int, b:String):String &#123; return \"aaa$a$b\" // 使用匿名函数进行实例化&#125;f.invoke(1, \"2\") 使用实现函数类型接口的自定义类的实例。下例中可直接使用 Test()(111) private class Test:(Int)-&gt;String&#123; override fun invoke(p1: Int): String = \"$p1 xxxx\"&#125; 函数引用及属性引用 val intPlus: Int.(Int) -&gt; Int = Int::plus// 下面三种方式都可以使用intPlus.invoke(1, 1)intPlus(1, 2)2.intPlus(3) :: 表示创建一个函数成员引用或者一个类引用 函数引用fun isOdd(x: Int) = x % 2 != 0 我们可以很容易地直接调用它（isOdd(5)），但是我们也可以将其作为一个函数类型的值，例如将其传给另一个函数。为此，我们使用 :: 操作符：val numbers = listOf(1, 2, 3)println(numbers.filter(::isOdd)) 这里 ::isOdd 是函数类型 (Int) -&gt; Boolean 的一个值。 等同于下面使用形参odd的方式val odd:(x: Int) -&gt; Boolean = &#123;x:Int -&gt; x % 2 != 0&#125;val numbers = listOf(1, 2, 3)println(numbers.filter(odd)) 类引用最基本的反射功能是获取 Kotlin 类的运行时引用。要获取对静态已知的 Kotlin 类的引用，可以使用 类字面值 语法：val c = MyClass::class 该引用是 KClass 类型的值。 请注意，Kotlin 类引用与 Java 类引用不同。要获得 Java 类引用， 请在 KClass 实例上使用 .java 属性val d = MyClass::class.java Kotlin中的异常Kotlin 中所有异常类都是 Throwable 类的子孙类。 每个异常都有消息、堆栈回溯信息以及可选的原因 try 是一个表达式，即它可以有一个返回值：val a: Int? = try &#123; parseInt(input) &#125; catch (e: NumberFormatException) &#123; null &#125; try-表达式的返回值是 try 块中的最后一个表达式或者是（所有）catch 块中的最后一个表达式。 finally 块中的内容不会影响表达式的结果 受检的异常受检查异常要用 try-catch 捕获，要么抛出，否则会发生编译错误。而 kotlin 中没有受检查异常，所有异常都是运行时异常，即便是原本在 Java 中的受检查异常，在 kotlin 中也是运行时异常，例如：IOException 在 Java 中是受检查异常，在 kotlin 中是运行时异常。 以下是 JDK 中 StringBuilder 类实现的一个示例接口：public int readNumber(BufferedReader reader) throws IOException &#123; int result = 0; String line = reader.readLine(); // 这里要么在方法声明上抛出，要么在内部捕获处理，否则无法编译通过 result = Integer.parseInt(line); reader.close(); return result;&#125; 这并不好，参见《Effective Java》第三版 第 77 条：不要忽略异常。 通过一些小程序测试得出的结论是异常规范会同时提高开发者的生产力与代码质量，但是大型软件项目的经验表明一个不同的结论——生产力降低、代码质量很少或没有提高。 kotlin实现静态成员的方式在 kotin 语言中其实没有 java static 的这个概念，基本都是用一个静态对象来模拟 class 的静态属性和方法，目前有4种实现方式： 伴生对象——声明单例的方式类内部的对象声明可以用 companion 关键字标记，这样它就与外部类关联在一起，我们就可以直接通过外部类访问到对象的内部元素。即可以声明属性，也可以声明方法，kotlin 中的调用方式感觉和 java 的 static 一样class BookKotlin &#123; var name: String = \"AA\" fun speak() &#123;&#125; companion object instance &#123; var nameStatic: String = \"BB\" fun speakStatic() &#123;&#125; &#125;&#125; 调用方式为：BookKotlin.nameStaticBookKotlin.speakStatic() 将kotlin代码转为java代码后，调用方式如下：BookKotlin.instance.getNameStatic()BookKotlin.instance.setNameStatic(String s)BookKotlin.instance.speakStatic() 注意：一个类里面只能声明一个内部关联对象，即关键字 companion 只能使用一次。 kotlin 中所有的成员变量，不管是不是 static 的都有 get/set 方法，另外 kotlin 并没有把我们声明的静态参数和方法声明成 static 的，而是通过 instance 这个静态对象中转使用的 @JvmField + @JvmStatic 注解声明成员和方法使用 JVM 提供的特性 @JvmField - 修饰静态变量 @JvmStatic - 修饰静态方法 @JvmField 和 @JvmStatic 只能写在 object 修饰的类或者 companion object 里，写法虽然有些别扭，但是效果是真的是按 static 来实现的 修改一下上面代码：class BookKotlin &#123; companion object &#123; @JvmField var nameStatic: String = \"BB\" @JvmStatic fun speakStatic() &#123; &#125; &#125; var name: String = \"AA\" fun speak() &#123;&#125;&#125; object 单例kotlin 自身提供了一种单例实现方式：object ，直接用来修饰 class ，用 object 修饰的类不能 new 对象，只能使用 object 提供的单例object BookKotlin &#123; var name: String = \"AA\" fun speak() &#123;&#125;&#125; Kotlin中使用如下：BookKotlin.nameBookKotlin.speak() constconst 写在 class 外面，效果 = @JvmField，但是不能修饰方法，也不能和 @JvmField 混用，一般就是用来声明常用值的，用处不多，而且只能用 val ，var 不行，想要修饰方法的话，不写 const 就行const val name: String = \"AA\"fun adk()&#123;&#125;class BookKotlin &#123; fun speak() &#123;&#125;&#125; kotlin没有三目运算符用表达式if() ... else ... 或 if () ... else if () ... else ... 代替 var number = if(n&gt;0) \"Positive\" else if(n&lt;0) \"Negative\" else \"Zero\"// 这一行比三元运算符简单得多，可读性也更强 Kotlin内联函数Java 方法执行的内存模型是基于 Java 虚拟机栈的：每个方法被执行的时候都会创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧入栈、出栈的过程。也就是说每调用一个方法，都会对应一个栈帧的入栈出栈过程，如果你有一个工具类方法，在某个循环里调用很多次，那就会对应很多次的栈帧入栈、出栈过程。这里首先要记住的一点是，栈帧的创建及入栈、出栈都是有性能损耗的。下面以一个例子来说明，看段代码片段：fun test() &#123; //多次调用 sum() 方法进行求和运算 println(sum(1, 2, 3)) println(sum(100, 200, 300)) println(sum(12, 34)) //....可能还有若干次&#125;fun sum(vararg ints: Int): Int &#123; var sum = 0 for (i in ints) &#123; sum += i &#125; return sum&#125; 在测试方法 test() 里，我们多次调用了 sum() 方法。为了避免多次调用 sum() 方法带来的性能损耗，我们期望的代码类似这样子的：fun test() &#123; var sum = 0 for (i in arrayOf(1, 2, 3)) &#123; sum += i &#125; println(sum) sum = 0 for (i in arrayOf(100, 200, 300)) &#123; sum += i &#125; println(sum) sum = 0 for (i in arrayOf(12, 34)) &#123; sum += i &#125; println(sum)&#125; 3次数据求和操作，都是在 test() 方法里执行的，没有之前的 sum() 方法调用，最后的结果依然是一样的，但是由于减少了方法调用，虽然代码量增加了，但是性能确提升了。那么怎么实现这种情况呢，一般工具类有很多公共方法，我总不能在需要调用这些公共方法的地方，把代码复制一遍吧，内联就是为了解决这一问题。 定义内联函数：inline fun sum(vararg ints: Int): Int &#123; var sum = 0 for (i in ints) &#123; sum += i &#125; return sum&#125; 如上所示，用关键字 inline 标记函数，该函数就是一个内联函数。还是原来的 test() 方法，编译器在编译的时候，会自动把内联函数 sum() 方法体内的代码，替换到调用该方法的地方。查看编译后的字节码，会发现 test() 方法里已经没了对 sum() 方法的调用，凡是原来代码里出现 sum() 方法调用的地方，出现的都是 sum() 方法体内的字节码了。 注意，内联可能导致生成的代码增加；不过如果我们使用得当（即避免内联过大函数），性能上会有所提升，尤其是在循环中的“超多态（megamorphic）”调用处。 禁用内联如果一个内联函数的参数里包含 lambda表达式，也就是函数参数，那么该形参也是 inline 的，举个例子：inline fun test(inlined: () -&gt; Unit) &#123;...&#125; 这里有个问题需要注意，如果在内联函数的内部，函数参数被其他非内联函数调用，就会报错，如下所示：//内联函数inline fun test(inlined: () -&gt; Unit) &#123; //这里会报错 otherNoinlineMethod(inlined) &#125;//非内联函数fun otherNoinlineMethod(oninline: () -&gt; Unit) &#123; &#125; 要解决这个问题，必须为内联函数的参数加上 noinline 修饰，表示禁止内联，保留原有函数的特性，所以 test() 方法正确的写法应该是：inline fun test(noinline inlined: () -&gt; Unit) &#123; otherNoinlineMethod(inlined)&#125; 注意，如果一个内联函数没有可内联的函数参数并且没有具体化的类型参数，编译器会产生一个警告，因为内联这样的函数很可能并无益处（如果你确认需要内联，则可以用 @Suppress(“NOTHING_TO_INLINE”) 注解关掉该警告 非局部返回在 Kotlin 中，我们只能对具名或匿名函数使用正常的、非限定的 return 来退出。 这意味着要退出一个 lambda 表达式，我们必须使用一个标签，并且在 lambda 表达式内部禁止使用裸 return，因为 lambda 表达式不能使包含它的函数返回：fun test() &#123; innerFun &#123; //return 会报错，非局部返回，直接退出 test() 函数。 return@innerFun //局部返回，只退出 innerFun() 函数 &#125; //以下代码依旧会执行 println(\"test...\")&#125;fun innerFun(a: () -&gt; Unit) &#123; a()&#125; 非局部返回我的理解就是返回到顶层函数，如上面代码中所示，默认情况下是不能直接 return 的，但是内联函数确是可以的。所以改成下面这个样子fun test() &#123; innerFun &#123; return //非局部返回，直接退出 test() 函数。 &#125; //以下代码不会执行 println(\"test...\")&#125;inline fun innerFun(a: () -&gt; Unit) &#123; a()&#125; 也就是说内联函数的函数参数在调用时，可以非局部返回，如上所示。那么 crossinline 修饰的 lambda 参数，可以禁止内联函数调用时非局部返回。fun test() &#123; innerFun &#123; return //这里这样会报错，只能 return@innerFun &#125; //以下代码不会执行 println(\"test...\")&#125;inline fun innerFun(crossinline a: () -&gt; Unit) &#123; a()&#125; 具体化的类型参数有时候我们需要访问一个作为参数传给我们的一个类型：fun &lt;T&gt; TreeNode.findParentOfType(clazz: Class&lt;T&gt;): T? &#123; var p = parent while (p != null &amp;&amp; !clazz.isInstance(p)) &#123; p = p.parent &#125; @Suppress(\"UNCHECKED_CAST\") return p as T?&#125; 在这里我们向上遍历一棵树并且检测每个节点是不是特定的类型。 这都没有问题，但是调用处不是很优雅：treeNode.findParentOfType(MyTreeNode::class.java) 我们真正想要的只是传一个类型给该函数，即像这样调用它：treeNode.findParentOfType&lt;MyTreeNode&gt;() 为能够这么做，内联函数支持具体化的类型参数，于是我们可以这样写：inline fun &lt;reified T&gt; TreeNode.findParentOfType(): T? &#123; var p = parent while (p != null &amp;&amp; p !is T) &#123; p = p.parent &#125; return p as T?&#125; 我们使用 reified 修饰符来限定类型参数，现在可以在函数内部访问它了， 几乎就像是一个普通的类一样。由于函数是内联的，不需要反射，正常的操作符如 !is 和 as 现在都能用了。此外，我们还可以按照上面提到的方式调用它：myTree.findParentOfType&lt;MyTreeNodeType&gt;()。 再举个栗子：inline fun &lt;reified T: Activity&gt; startActivity() &#123; startActivity(Intent(this, T::class.java))&#125; 使用时直接传入泛型即可，代码简洁明了：startActivity&lt;MainActivity&gt;() 扩展函数扩展函数可以在已有类中添加新的方法，不会对原类做修改，扩展函数定义形式：fun receiverType.functionName(params)&#123; body&#125; receiverType：表示函数的接收者，也就是函数扩展的对象functionName：扩展函数的名称params：扩展函数的参数，可以为NULL 以下实例扩展 User 类 ：class User(var name:String)/**扩展函数**/fun User.Print()&#123; print(\"用户名 $name\")&#125;fun main(arg:Array&lt;String&gt;)&#123; var user = User(\"Runoob\") user.Print()&#125; 类的属性Kotlin 类的属性可以声明为可变的（var）或者是只读的（val），声明一个属性的完整语法如下：var &lt;propertyName&gt;[: &lt;PropertyType&gt;] [= &lt;property_initializer&gt;] [&lt;getter&gt;] [&lt;setter&gt;]val &lt;propertyName&gt;[: &lt;PropertyType&gt;] [= &lt;property_initializer&gt;] [&lt;getter&gt;] 以一个简单的 Student 类为例：class Student(_name: String, _age: Int) &#123; val name: String = _name var age: Int = _age val isAdult: Boolean get() = this.age &gt;= 18&#125; 这里声明 name 和 age 时确实是有 getter 和 setter 方法的，只是被省略了而已，我们以为的不省略写法如下（错误的）：class Student(_name: String, _age: Int) &#123; val name = _name // Initializer is not allowed here because this property has no backing field get() = this.name // Recursive call var age = _age // Initializer is not allowed here because this property has no backing field get() = this.age // Recursive call set(value) &#123; this.age = value // Recursive call &#125;&#125; this.name 会造成 Recursive call（递归调用）。我们看一下是怎么回事： 第一步，调用 student.name； 第二步，调用 get() 方法； 第三步，在 get() 方法里，调用 this.name； 第一步，调用 student.name； 第二步，调用 get() 方法； … 这样就形成了递归调用了 get() 方法，并且没有终止条件，所以是有问题的。 另一条错误信息提示没有backing field，也叫幕后字段 backing fieldKotlin 类中不能直接声明 Fields。然而，当一个属性需要一个 backing field 时，Kotlin 会自动地提供它。在访问器中使用 field 标识符就可以引用到 backing field 看下官方文档里的例子：var counter = 0 // Note: the initializer assigns the backing field directly set(value) &#123; if (value &gt;= 0) field = value &#125; 改写一下刚才的Student类：class Student(_name: String, _age: Int) &#123; val name = _name get() = field // redundant var age = _age get() = field // redundant set(value) &#123; // redundant field = value &#125; val isAdult: Boolean get() = this.age &gt;= 18&#125; Backing Properties如果上面的方案都不符合你的需求，那么可以试试“后端属性”(backing property)的方法，它实际上也是隐含试的对属性值的初始化声明，避免了空指针。class Student(_name: String, _age: Int) &#123; val name = _name var age = _age private var _grades: Map&lt;String, Int&gt;? = null // 私有属性，后端属性 val grades: Map&lt;String, Int&gt; get() &#123; if (_grades == null) &#123; // 只有在首次访问时才加载成绩信息，并只执行一次 _grades = loadGrades() &#125; return _grades!! &#125; private fun loadGrades(): MutableMap&lt;String, Int&gt; &#123; println(\"loadGrades() called\") val result = mutableMapOf&lt;String, Int&gt;() result.put(\"Chinese\", 100) result.put(\"Math\", 99) result.put(\"English\", 100) return result &#125;&#125; Kotlin 独有的一些细节主构造函数在Kotlin类中只有一个主构造函数(主构造器)，而辅助构造函数（次级构造器）可以是一个或者多个。主构造函数用于初始化类，它在类标题中声明。标准写法：class 类名 construction(参数1，参数2….)&#123;&#125; 当constructor关键字没有注解和可见性修饰符作用于它时，constructor关键字可以省略 class Person &#123; private val name:String private val age:Int constructor(name:String,age:Int)&#123; // 次级构造函数 this.name = name this.age = age &#125;&#125; 数据类Kotlin 可以创建一个只包含数据的类，关键字为 data：data class User(val name: String, val age: Int) 编译器会自动的从主构造函数中根据所有声明的属性提取以下函数： equals() / hashCode() toString() 格式如 “User(name=John, age=42)” componentN() functions 对应于属性，按声明顺序排列 copy() 函数 为了保证生成代码的一致性以及有意义，数据类需要满足以下条件： 主构造函数至少包含一个参数 所有的主构造函数的参数必须标识为val 或者 var 数据类不可以声明为 abstract, open, sealed 或者 inner 数据类不能继承其他类 (但是可以实现接口) 复制复制使用 copy() 函数，我们可以使用该函数复制对象并修改部分属性, 对于上文的 User 类，其实现会类似下面这样：fun copy(name: String = this.name, age: Int = this.age) = User(name, age) 实例使用 copy 类复制 User 数据类，并修改 age 属性:data class User(val name: String, val age: Int)fun main(args: Array&lt;String&gt;) &#123; val jack = User(name = \"Jack\", age = 1) val olderJack = jack.copy(age = 2) println(jack) println(olderJack)&#125;// 输出结果为：// User(name=Jack, age=1)// User(name=Jack, age=2) 密封类密封类用来表示受限的类继承结构：当一个值为有限几种的类型, 而不能有任何其他类型时。在某种意义上，他们是枚举类的扩展：枚举类型的值集合 也是受限的，但每个枚举常量只存在一个实例，而密封类 的一个子类可以有可包含状态的多个实例。 声明一个密封类，使用 sealed 修饰类，密封类可以有子类，但是所有的子类都必须要内嵌在密封类中。 sealed 不能修饰 interface ,abstract class(会报 warning,但是不会出现编译错误) 密封类就是一种专门用来配合 when 语句使用的类，举个例子，假如在 Android 中我们有一个 view，我们现在想通过 when 语句设置针对 view 进行两种操作：显示和隐藏，那么就可以这样做：sealed class UiOp &#123; object Show: UiOp() object Hide: UiOp()&#125;fun execute(view: View, op: UiOp) = when (op) &#123; UiOp.Show -&gt; view.visibility = View.VISIBLE UiOp.Hide -&gt; view.visibility = View.GONE&#125; 以上功能其实完全可以用枚举实现，但是如果我们现在想加两个操作：水平平移和纵向平移，并且还要携带一些数据，比如平移了多少距离，平移过程的动画类型等数据，用枚举显然就不太好办了，这时密封类的优势就可以发挥了，例如：sealed class UiOp &#123; object Show: UiOp() object Hide: UiOp() class TranslateX(val px: Float): UiOp() class TranslateY(val px: Float): UiOp()&#125;fun execute(view: View, op: UiOp) = when (op) &#123; UiOp.Show -&gt; view.visibility = View.VISIBLE UiOp.Hide -&gt; view.visibility = View.GONE is UiOp.TranslateX -&gt; view.translationX = op.px // 这个 when 语句分支不仅告诉 view 要水平移动，还告诉 view 需要移动多少距离，这是枚举等 Java 传统思想不容易实现的 is UiOp.TranslateY -&gt; view.translationY = op.px // 不再需要 `else` 子句，因为我们已经覆盖了所有的情况&#125; 以上代码中，TranslateX 是一个类，它可以携带多于一个的信息，比如除了告诉 view 需要水平平移之外，还可以告诉 view 平移多少像素，甚至还可以告诉 view 平移的动画类型等信息，我想这大概就是密封类出现的意义吧。 除此之外，如果 when 语句的分支不需要携带除“显示或隐藏view之外的其它信息”时（即只需要表明 when 语句分支，不需要携带额外数据时），用 object 关键字创建单例就可以了，并且此时 when 子句不需要使用 is 关键字。只有需要携带额外信息时才定义密封类的子类，而且使用了密封类就不需要使用 else 子句，每当我们多增加一个密封类的子类或单例，编译器就会在 when 语句中给出提示，可以在编译阶段就及时发现错误，这也是以往 switch-case 语句和枚举不具备的功能。 最后，我们甚至可以把这一组操作封装成一个函数，以便日后调用，如下：// 先封装一个UI操作列表class Ui(val uiOps: List = emptyList()) &#123; operator fun plus(uiOp: UiOp) = Ui(uiOps + uiOp)&#125;// 定义一组操作val ui = Ui() + UiOp.Show + UiOp.TranslateX(20f) + UiOp.TranslateY(40f) + UiOp.Hide// 定义调用的函数fun run(view: View, ui: Ui) &#123; ui.uiOps.forEach &#123; execute(view, it) &#125;&#125;run(view, ui) // 最终调用 Break 和 Continue 标签在 Kotlin 中任何表达式都可以用标签（label）来标记。 标签的格式为标识符后跟 @ 符号，例如：abc@、fooBar@都是有效的标签。 要为一个表达式加标签，我们只要在其前加标签即可。loop@ for (i in 1..100) &#123; for (j in 1..100) &#123; if (……) break@loop &#125;&#125; 标签限制的 break 跳转到刚好位于该标签指定的循环后面的执行点。 continue 继续标签指定的循环的下一次迭代。 标签处返回(待补充)Kotlin 有函数字面量、局部函数和对象表达式。因此 Kotlin 的函数可以被嵌套。 标签限制的 return 允许我们从外层函数返回。 最重要的一个用途就是从 lambda 表达式中返回。回想一下我们这么写的时候：fun foo() &#123; ints.forEach &#123; if (it == 0) return print(it) &#125;&#125; 这个 return 表达式从最直接包围它的函数即 foo 中返回。 （注意，这种非局部的返回只支持传给内联函数的 lambda 表达式。） 如果我们需要从 lambda 表达式中返回，我们必须给它加标签并用以限制 return。 fun foo() &#123; ints.forEach lit@ &#123; if (it == 0) return@lit print(it) &#125;&#125; 现在，它只会从 lambda 表达式中返回。通常情况下使用隐式标签更方便。 该标签与接受该 lambda 的函数同名。 fun foo() &#123; ints.forEach &#123; if (it == 0) return@forEach print(it) &#125;&#125; object 关键字object 是Kotlin中的一个重要的关键字，也是Java中没有的。object 主要有以下三种使用场景： 对象声明（Object Declaration），前面提到了，用于创建类的单例 伴生对象（Companion Object），类似java中 static 关键字 对象表达式（Object Expression），替换java的匿名内部类 分离用于只读与可变集合的接口委托参考 一文彻底搞懂 Kotlin 中的委托 协程（coroutines）参考谷歌官方文档：Android 上的 Kotlin 协程 RefKotlin 语言中文站Kotlin内联函数:使用 Kotlin 进行 Android 开发Kotlin 的 Backing Fields 和 Backing Properties 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&amp;Java/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Kotlin","slug":"kotlin","permalink":"http://agehua.github.io/tags/kotlin/"}]},{"title":"Kotlin DSL 语法糖","slug":"Kotlin-DSL","date":"2020-09-06T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2020/09/07/Kotlin-DSL/","link":"","permalink":"http://agehua.github.io/2020/09/07/Kotlin-DSL/","excerpt":"Kotlin 中使用 DSL最近发现一个使用Kotlin DSL技术来代替XML生成UI布局的工程，类似 Anko，觉得很有意思，特意复制过来，研究一下实现原理，源码在这里 layout_dsl\n所谓DSL领域专用语言(Domain Specified Language)，其基本思想是“求专不求全”：为专门解决某一特定问题的计算机语言，比如大家耳熟能详的 SQL 和正则表达式。\nKotlin DSL 所体现的代码结构有如下特点：链式调用，大括号嵌套，并且可以近似于英语句子。","text":"Kotlin 中使用 DSL最近发现一个使用Kotlin DSL技术来代替XML生成UI布局的工程，类似 Anko，觉得很有意思，特意复制过来，研究一下实现原理，源码在这里 layout_dsl 所谓DSL领域专用语言(Domain Specified Language)，其基本思想是“求专不求全”：为专门解决某一特定问题的计算机语言，比如大家耳熟能详的 SQL 和正则表达式。 Kotlin DSL 所体现的代码结构有如下特点：链式调用，大括号嵌套，并且可以近似于英语句子。 实现原理看了那么多 Kotlin DSL 的风格和使用场景，相较于刻板的、传统的 Java 而言，更加神奇和富有想象力。要理解 Kotlin DSL 这场魔术盛宴，就必须了解其背后用到的魔术道具——扩展函数、lambda、中缀调用和 invoke 约定。 扩展函数（扩展属性）对于同样作为静态语言的 Kotlin 来说，扩展函数（扩展属性）是让他拥有类似于动态语言能力的法宝，即我们可以为任意对象动态的增加函数或属性。 比如，为 String 扩展一个函数： lastChar():package stringsfun String.lastChar(): Char = this.get(this.length - 1) 与 JavaScript 这类动态语言不一样，Kotlin 实现原理是： 提供静态工具类，将接收对象(此例为 String )做为参数传递进来,以下为该扩展函数编译成 Java 的代码 /* Java */char c = StringUtilKt.lastChar(\"Java\"); lambda介绍lambda 为 Java 8 提供的新特性，于2014年3月18日发布。在2018年的今天我们依然无法使用或者要花很大的代价才能在 Android 编程中使用，而 Kotlin 则帮助我们解决了这一瓶颈，这也是我们拥抱 Kotlin 的原因之一。 lambda 是构建整洁代码的一大利器。 lambda 表达式下图是 lambda 表达式，他总是用一对大括号包装起来，可以作为值传递给下节要提到的高阶函数。 lambda 表达式总是括在花括号中， 完整语法形式的参数声明放在花括号内，并有可选的类型标注， 函数体跟在一个 -&gt; 符号之后。如果推断出的该 lambda 的返回类型不是 Unit，那么该 lambda 主体中的最后一个（或可能是单个） 表达式会视为返回值。 高阶函数关于高阶函数的定义，参考《Kotlin 实战》： 高阶函数就是以另一个函数作为参数或返回值的函数 如果用 lamba 来作为高价函数的参数（此时为形参），就必须先了解如何声明一个函数的形参类型，如下： // printSum 为高阶函数，定义了 lambda 形参fun printSum(sum:(Int,Int)-&gt;Int)&#123; // sum作为传入的函数的形参，然后可以通过sum 调用方法 val result = sum(1, 2) println(result)&#125;// 以下 lambda 为实参，传递给高阶函数 printSumval sum = &#123;x:Int,y:Int-&gt;x+y&#125;printSum(sum) 有了高阶函数，我们可以很轻易地做到一个 lambda 嵌套另一个 lambda 的代码结构。 大括号放在最后Kotlin 的 lambda 有个规约：如果 lambda 表达式是函数的最后一个实参，则可以放在括号外面。如果该 lambda 表达式是调用时唯一的参数，那么圆括号可以完全省略：person.maxBy(&#123; p:Person -&gt; p.age &#125;)// 可以写成，放在括号外面person.maxBy()&#123; p:Person -&gt; p.age&#125;// 更简洁的风格，可以省略括号：person.maxBy&#123; p:Person -&gt; p.age&#125; 再举一个例子： // &#123; acc, e -&gt; acc * e &#125; 作为函数最后一个实参，放在了括号外面val product = items.fold(1) &#123; acc, e -&gt; acc * e &#125; // 省略圆括号run &#123; println(\"...\") &#125; 这种语法也称为拖尾 lambda 表达式。 这个规约是 Kotlin DSL 实现嵌套结构的本质原因，比如很多博客提到的 anko Layout： // 省略圆括号verticalLayout &#123; val name = editText() button(\"Say Hello\") &#123; onClick &#123; toast(\"Hello, $&#123;name.text&#125;!\") &#125; &#125;&#125; 这里 verticalLayout 中 嵌套了 button，想必该库定义了如下函数：fun verticalLayout( ()-&gt;Unit )&#123; &#125;fun button( text:String,()-&gt;Unit )&#123; &#125; verticalLayout 和 button 均是高阶函数，结合大括号放在最后的规约，就形成了 lambda 嵌套的语法结构。 注意，允许将函数留在圆括号外的简写语法仅适用于 lambda 表达式。 带接收者的 lambda函数类型可以有一个额外的接收者类型，它在表示法中的点之前指定： 类型 A.(B) -&gt; C 表示可以在 A 的接收者对象上以一个 B 类型参数来调用并返回一个 C 类型值的函数。 带有接收者的函数字面值通常与这些类型一起使用。如下图： Kotlin 提供了使用指定的接收者对象调用函数字面值的功能。 在函数字面值的函数体中，可以调用该接收者对象上的方法而无需任何额外的限定符。 函数字面值，有的也叫函数字面量，（英文：function literal）。函数字面值（量）即一段函数文本，说白了就是一段代码，可以当作参数来传递。 val sum: Int.(Int) -&gt; Int = &#123; other -&gt; plus(other) &#125;// 相当于: val sum: Int.(Int) -&gt; Int = &#123; other -&gt; this.plus(other) &#125; // plus是Int的一个方法 在使用的时候，需要指定接收者。 //类似扩展函数的用法，用实例对象来调用 println( 1.sum(2) )//输出 3 1即这里的接收者，定义的函数字面值里的this就是指向了它 匿名函数语法允许你直接指定函数字面值的接收者类型。 如果你需要使用带接收者的函数类型声明一个变量，并在之后使用它，这将非常有用。 val sum = fun Int.(other: Int): Int = this + other// 下面写法是错误的，不能既用 = ，又用&#123;&#125;val sum = fun Int.(other: Int): Int = &#123;this + other&#125; 此外，带有接收者类型的函数的非字面值可以作为参数进行传递，前提是所需要接收函数的地方应该有一个接收者类型的参数，反之依然，比如说：String.(Int) -&gt; Boolean 与（String, Int）-&gt; Boolean是等价的，下面用代码进行说明： val myEquals: String.(Int) -&gt; Boolean = &#123;param -&gt; this.toIntOrNull() == param&#125;println(\"11\".myEquals(11))println(\"11\".myEquals(12))// 结果 true false 为了说明”String.(Int) -&gt; Boolean与（String, Int）-&gt; Boolean是等价的”，下面用代码来论证下： fun myTest(op:(String, Int) -&gt; Boolean, a: String, b:Int, c:Boolean) = println(op(a, b) == c)// 这里可以传入 myEquals 函数，并且能成功执行，说明两者是等价的myTest(myEquals, \"200\", 200, true) 带接收者的 lambda 丰富了函数声明的信息，当传递该 lambda值时，将携带该接收者，比如： // 声明接收者fun kotlinDSL(block: StringBuilder.()-&gt;Unit)&#123; block(StringBuilder(\"Kotlin\"))&#125;// 调用高阶函数kotlinDSL &#123; // 这个 lambda 的接收者类型为StringBuilder append(\" DSL\") println(this)&#125;&gt;&gt;&gt; 输出 Kotlin DSL 简单介绍一下上面代码的意思：kotlinDSL是一个函数，接收一个名为block的参数，该参数本身就是一个函数。block函数的类型是 StringBuilder.()-&gt;Unit，它是一个带接受者的函数类型。这意味着我们需要向block函数传递一个StringBuilder类型的实例（接收者），并且我们可以在kotlinDSL 函数内部调用该实例的成员。该接收者可以通过this关键字访问 可以再看下面这个例子：class HTML &#123; fun body() &#123; println(\"HTML BODY\") &#125;&#125;fun html(init: HTML.() -&gt; Unit): HTML &#123; val html = HTML() // 创建接收者对象 html.init() // 将该接收者对象传给该 lambda return html&#125;html &#123; // 带接收者的 lambda 由此开始 body() // 调用该接收者对象的一个方法&#125; 总而言之，lambda 在 Kotlin 和 Kotlin DSL 中扮演着很重要的角色，是实现整洁代码的必备语法糖。 中缀调用Kotlin 中有种特殊的函数可以使用中缀调用，代码风格如下：\"key\" to \"value\"// 等价于\"key.to(\"value\") 而 to() 的实现源码如下：infix fun Any.to(that:Any) = Pair(this,that) 这段源码理解起来不难，infix 修饰符代表该函数支持中缀调用，然后为任意对象提供扩展函数 to，接受任意对象作为参数，最终返回键值对。 中缀调用是实现类似英语句子结构 DSL 的核心。 invoke 约定Kotlin 提供了 invoke 约定，可以让对象向函数一样直接调用，比如：class Person(val name:String)&#123; operator fun invoke()&#123; println(\"my name is $name\") &#125;&#125;&gt;&gt;&gt;val person = Person(\"geniusmart\")&gt;&gt;&gt; person()my name is geniusmart 看下网上提到的 Gradle Kotlin DSL：dependencies &#123; compile(\"com.android.support:appcompat-v7:27.0.1\") compile(\"com.android.support.constraint:constraint-layout:1.0.2\")&#125; // 等价于：dependencies.compile(\"com.android.support:appcompat-v7:27.0.1\")dependencies.compile(\"com.android.support.constraint:constraint-layout:1.0.2\") 这里，dependencies 是一个实例，既可以调用成员函数 compile，同时也可以直接传递 lambda 参数，后者便是采用了 invoke 约定，实现原理简化如下：class Dependencies&#123; fun compile(coordinate:String)&#123; println(\"add $coordinate\") &#125; operator fun invoke(block:Dependencies.()-&gt;Unit)&#123; block() &#125;&#125;&gt;&gt;&gt;val dependencies = Dependencies()&gt;&gt;&gt;// 以两种方式分别调用 compile() invoke 约定让对象调用函数的语法结构更加简洁。 总结Kotlin 本身语法就非常整洁，使用DSL则是对 Kotlin 所有语法糖的一个融合，相信以后Kotlin DSL技术应用的地方会越来越多。 参考：《Kotlin 之美—DSL篇》，部分内容有增加带接收者的函数字面值与解构声明详解 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/09/07/Kotlin-DSL/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Kotlin","slug":"kotlin","permalink":"http://agehua.github.io/tags/kotlin/"}]},{"title":"JVM 堆和栈知识点积累","slug":"JVM-stack-and_heap","date":"2020-08-30T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2020/08/31/JVM-stack-and_heap/","link":"","permalink":"http://agehua.github.io/2020/08/31/JVM-stack-and_heap/","excerpt":"最近在看《深入理解Java虚拟机》，在此记录一下书中的重点，方便以后查阅。部分介绍内容来自网络。\n线程独占区","text":"最近在看《深入理解Java虚拟机》，在此记录一下书中的重点，方便以后查阅。部分介绍内容来自网络。 线程独占区 虚拟机栈虚拟机栈属于线程独占区，具体指虚拟机栈中的局部变量表。虚拟机栈描述的是Java方法执行的动态内存模型。每个方法执行都会创建一个栈帧，伴随着方法从创建到执行完成。用于存储局部变量表，操作数栈，动态链接，方法出口等。 局部变量表的内存空间，在编译期完成分配，当进入一个方法时，这个方法需要帧中分配多少内存是固定的，在方法运行期间不会改变局部变量表大小 局部变量表保存的是对象的引用，对象是分配在堆内存中 虚拟机栈已满，但仍有方法需要进栈，则会抛出 StackOverflowError，栈未满；但内存不够了，则会抛出OutOfMemory异常 栈有一个很重要的特殊性，就是存在栈中的数据可以共享。假设我们同时定义：int a = 3;int b = 3; 编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。 这时，如果再令 a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并令a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响 到b的值。 要注意这种数据的共享与两个对象的引用同时指向一个对象的这种共享是不同的，因为这种情况a的修改并不会影响到b, 它是由编译器完成的，它有利于节省空间。而一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。 Java中方法参数是值传递，在方法中如果对参数进行修改，将不会影响到实际参数。但可以通过对象引用变量，改变对象的内部状态。更多形参和实参，值传递和引用传递介绍，可以看这篇文章: 深入理解Java中方法的参数传递机制 对于成员变量和局部变量：成员变量就是方法外部，类的内部定义的变量；局部变量就是方法或语句块内部定义的变量。局部变量必须初始化。 方法的形式参数是局部变量，局部变量的数据存在于栈内存中。栈内存中的局部变量随着方法的消失而消失。 成员变量存储在堆中的对象里面，由垃圾回收器负责回收。 本地方法栈本地方法栈为虚拟机执行native方法服务 程序计数器线程共享区Java堆 新生代 Eden Survivor 存活区 Tenured Gen 老年代 存放对象实例垃圾收集器管理的主要区域分新生代，老年代，Eden空间OutOfMemory 方法区方法区系统分配的一个内存逻辑区域，是一块所有线程共享的内存区域，用来存储类信息(类型信息可以理解为类的描述信息（类的全限定名，访问修饰符，字段，方法等）)、常量和静态变量 存储运行时常量池，已被虚拟机加载类信息，常量，静态变量，即时编译器编译后的代码等数据 类信息： 类的版本 字段 方法 接口 方法区和永久代：有的虚拟机（HotSpot），使用永久代实现的方法区，但两者并不等价 垃圾回收在方法区中的行为：常量池的回收，类型的卸载 异常：OutOfMemory 运行时常量池常量池即文件常量池，主要用来保存字面量和符号引用 1）JVM为每个已加载的类型维护一个常量池，常量池就是这个类型用到的常量的一个有序集合。包括直接常量(基本类型，String)和对其他类型、方法、字段的符号引用。池中的数据和数组一样通过索引访问。 2）java中的常量池技术，是为了方便快捷地创建某些对象而出现的，当需要一个对象时，就可以从池中取一个出来（如果池中没有则创建一个），则在需要重复创建相等变量时节省了很多时间。常量池其实也就是一块内存空间，不同于使用new关键字创建的对象所在的堆空间。 java中的基本类型有：byte、short、char、int、long、boolean。其对应的包装类分别是：Byte、Short、Character、Integer、Long、Boolean。上边提到的这些包装类都实现了常量池技术，而两种浮点数类型的包装类则没有实现。另外，String类型也实现了常量池技术。 字符串对象的创建，s1 = new String(“a”)内容存放在堆内存，而s1 = “a”则存放在方法区的常量池中 String s1 = \"abc\";String s2 = \"abc\"; // s1 == s2 true，地址相同， 字节码常量String s3 = new String(\"abc\"); // s3在堆内存，s1 == s3 false 地址不同System.out.println(s1 == s3.intern()); // true，s3.intern()则会将内容搬到方法区的常量池中去，地址相同// s3.intern()叫运行时常量 直接内存堆内存之外分配的内存，NIO可以直接分配堆外内存 对象的创建指针碰撞空闲列表 线程安全问题 线程同步 本地线程分配缓冲 对象的结构Header 对象头 自身运行时数据 (Mark Word)： 哈希值 GC分代年龄 锁状态标志 线程持有的锁 偏向线程ID 偏向时间戳 64bit 类型指针 对象指向它类的元数据的指针 InstanceDataPadding填充内存，保证8bit的整数倍 对象的访问定位 使用句柄 指向堆中，句柄池，通过句柄池找到对象内存地址 直接指针 指向内存区域 GCRoot对象 执行上下文 虚拟机栈(栈帧中的本地变量表) 全局性的引用 方法区类属性所引用的对象 方法区中常量所引用的对象 本地方法栈中引用的对象 内存分配策略-verbose:gc 控制台打印gc日志-XX:+PrintGCDetails-XX:+UseSerialGC 启动serialgc回收器，默认使用parallel回收器-Xms20M -Xmx20M 堆内存大小20M，不可扩展-Xmn10M 指定新生代内存为10M-XX:SurvivorRatio =8 Eden 区域为80% ??? 对象优先在Eden上分配 大对象直接进入老年代-XX:PretenureSizeThreshold : 指定老年代阈值，超过这个阈值大小的对象会直接放入老年代 长期存活对象将进入到老年代-XX:MaxTenuringThreshold: 指定老年代任期阈值 空间分配担保（Eden区域不够用，已分配对象会被移到老年代）-XX:+HandlerPromotionFailure: 是否禁用空间分配担保（+开启，默认，-禁用） 动态对象年龄判断 JVM 参数样式： -XX:+&lt;option&gt;, 表示开启option选项 -XX:-&lt;option&gt;, 表示关闭option选项 -XX:&lt;option&gt;=&lt;value&gt;, 表示将option选项的值设置为value 逃逸分析与栈上分配逃逸分析：分析对象的作用域，栈上分配：方法体内没有逃逸的对象，会分配在栈上 Jconsole死锁检测 Davilk 字节码指令，基于寄存器架构Java 虚拟机的指令集，基于栈架构 类的初始化1.遇到new，getstatic, putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化常见的场景有：new关键字实例化对象，读取或设置一个类的静态字段（没有被final修饰），调用一个类的静态方法时。 被final修饰的叫静态字段，会被放入常量池（方法区）中。所以引用类中的常量字段，是不会触发类的初始化的 2.当初始化一个类的时候，如果发现其父类还没有进行初始化，则需要先触发其父类的初始化3.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有初始化，则需要先触发其初始化 不会初始化类的场景通过子类引用父类的静态字段，子类不会被初始化通过数组定义来引用类，类不会被初始化，实例化的是数组类型A[] a = new A[10];// A对象不会初始化 调用类的常量（final），类不会初始化 助记符： anewarray: 表示创建一个引用类型（如类，接口，数组）的数组，并将其压入栈顶 newarray: 表示创建一个指定的原始类型（如int、float、char等）的数组，并将其压入栈顶 加载通过一个类的全限定类名来获取定义此类的二进制流 可以从文件加载 Class文件 Jar 包 网络 applet 计算生成一个二进制流 $Proxy(反射包中) 由其他文件生成 JSP 数据库 验证验证是连接的第一步，这一阶段目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全 准备准备阶段正式为类变量分配内存，并设置变量的初始值，这些变量使用的内存都将在方法区中进行分配。这里的初始值并非我们指定的值，而是默认值。但是如果被final修饰，初始化值为常量值 解析解析阶段是虚拟机将常量池中的符号引用替换为直接引用的过程 关于符号引用和直接引用，可以看这篇文章: https://www.zhihu.com/question/30300585 对符号引用进行解析： 类或接口解析字段解析类方法解析 上面三个都会对扶摇引用进行权限验证，不具备访问权限，抛出java.lang.illegalAccessError异常接口方法解析 接口所有方法都是public，所以不存在权限验证 初始化初始化时类加载的最后一步初始化是执行&lt;clinit&gt;()方法的过程 public class Demo &#123; static &#123; i = 0; System.out.println(i); // i可以赋值，但不能访问 &#125; static int i = 1;&#125; &lt;clinit&gt;()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问定义在静态语句块之前的变量，定义在它之后的变量，在前面的语句块中可以赋值，但是不能访问。 public class Parent &#123; public static int A =1; static &#123; A = 2; &#125; static class Sub extends Parent &#123; public static int B = A; &#125; public static void main(String[] args) &#123; System.out.println(Sub.B); &#125;&#125; 子类的&lt;clinit&gt;()在执行之前，虚拟机保证父类的先执行完毕，因此在赋值前父类static已经执行，因此结果为2. 接口中也有变量要赋值，也会生成&lt;clinit&gt;()，但不需要先执行父类的&lt;clinit&gt;()方法。只有父接口中定义的变量使用时才会初始化。 如果多个线程同时初始化一个类，只有一个线程会执行这个类的&lt;clinit&gt;()，其他线程等待执行完毕。如果方法执行时间过长，则会造成多个线程阻塞。 类的初始化步骤： 假如这个类还没有被加载和连接，那就先进行加载和连接 假如类存在直接父类，并且这个父类还没有被初始化，那就先初始化直接父类 假如类中存在初始化语句，那就依次执行这些初始化语句 类的初始化时机： 主动使用 创建类的实例 访问某个类或接口的静态变量，或者对该静态变量赋值 调用类的静态方法 反射（如Class.forName(“com.test.XXXX”)） 初始化一个类的子类 Java虚拟机启动时被标明为启动类的类（Java Test） JDK1.7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic, REF_putStatic, REF_invokeStatic句柄对应的类没有初始化则初始化 除了上述7中情形，其他使用Java类的方式都被看作是被动使用，不会导致类的初始化 当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则不适用于接口 - 在初始化一个类时，并不会先初始化它所实现的接口 - 在初始化一个接口时，并不会初始化它的父接口 只有当程序访问的静态变量或静态方法确实在当前类或当前接口中定义时，才可以认为是对类或接口的主动使用 来看一个父类子类和成员变量初始化顺序的问题：public class Base &#123; private String baseName = \"base\"; public Base() &#123; callName(); &#125; public void callName() &#123; System.out.println(baseName); &#125; static class Sub extends Base &#123; private String baseName = \"sub\"; public void callName() &#123; // 子类重写了父类的方法 System.out.println(baseName) ; &#125; &#125; public static void main(String[] args) &#123; Base b = new Sub(); &#125; /** * 链接：https://www.nowcoder.com/questionTerminal/c2bfb1512dfa4a7eab773a5871a52402 * 来源：牛客网 * * 初始化的过程：1、初始化父类中的静态成员变量和静态代码块。2、初始化子类中的静态成员变量和静态代码块。3、初始化父类的普通成员变量和代码块，再执行父类的构造方法。4、初始化子类的普通成员变量和代码块，再执行子类的构造方法。 * 题目中new Sub()会先初始化父类中的baseName变量，再调用父类的构造函数，调用子类重写的callName()方法，打印出子类中的baseName，接下来才初始化子类中变量，调用子类构造函数，所以打印null。 * 可以单步调试看下代码的执行过程。 */&#125; 答案是只有 ”null“ 类的实例化为新的对象分配内存，为实例变量赋初始值，为实例变量赋默认值。java编译器为它编译的每一个类都至少生成一个实例初始化方法，在java的class文件中，这个实例初始化方法被称为&lt;init&gt;。针对源代码中每一个类的构造方法，java编译器都产生一个&lt;init&gt;方法。类变量是在准备阶段就已经分配内存 类加载器 Java虚拟机自带的加载器 根类加载器（Bootstrap） 扩展类加载器（Extension） 系统（应用）类加载器（System） 用户自己定义的加载器 java.lang.ClassLoader的子类 用户可以定制类的加载方式 类加载器并不需要等到某个类被”首次主动使用“时再加载它。 如果在预先加载的过程中遇到.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类是才报告错误(LinkageError错误)，如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。 双亲委派模型 启动类加载器 由C++实现，是虚拟机的一部分，用于加载javahome下的lib目录下的类(rt.jar， java.lang.Object) 扩展类加载器 加载javahome下的 /lib/ext/目录中的类 应用程序类加载器 加载用户类路径上所指定的类库 自定义类加载器 class MyParent &#123; public static String str = \"Hello world\": static &#123; System.out.println(\"Parent static block\"); &#125;&#125;class MyChild extends MyParent &#123; public static String str2 = \"Welcome\": static &#123; System.out.println(\"Child static block\"); &#125;&#125;class Test &#123; public static void main(String[] args) &#123; System.out.println(MyChild.str2); // 打印 Parent static block Child static block Hello world // System.out.println(MyChild.str); // 打印 Parent static block Hello world &#125;&#125; 对于打印str2，主动使用了MyChild类，MyChild会初始化，子类如果被初始化，所有父类必须先行初始化，所以 MyParent会初始化对于打印str，对于静态字段，只有直接定义了该字段的类才会被初始化，所以不会初始化MyChild类 -XX:+TraceClassLoading，用于追踪类的加载信息并打印出来。对于打印str，虽然没有打印 “Child static block”，说明没有初始化MyChild，但是也完成了MyChild类的加载 class MyParent &#123; public static final String str = \"Hello world\": static &#123; System.out.println(\"Parent static block\"); &#125;&#125;class Test2 &#123; public static void main(String[] args) &#123; System.out.println(MyParent.str); // 只打印 ”Hello world“ &#125;&#125; 加上final，表示常量在编译阶段，常量会被存入调用这个常量的方法(main方法)所在的类(Test2)的常量池中。甚至，可以把编译后的MyParent类删除，程序可以正常执行。 本质上，调用类并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化 反编译Test2.class后查看类源码，发现一个助记符：ldc ldc表示将int，float或是String类型的常量值从常量池中推送至栈顶 助记符 bipush，表示是将单字节（-128 - 127）的常量值推送至栈顶 助记符 sipush，表示是将短整形（-32768 - 32767）的常量值推送至栈顶 助记符 iconst_1，表示将int类型1推送至栈顶（iconst_m1 - iconst_5）(-1 - 5) 再看下一例子class MyParent &#123; public static final String str = UUID.randomUUID().toString(): static &#123; System.out.println(\"Parent static block\"); &#125;&#125;public class Test3 &#123; public static void main(String[] args) &#123; System.out.println(MyParent.str); // 会打印静态代码块 &#125;&#125; 当一个常量的值并非编译期间可以确定，那么其值就不会放到调用类的常量池中。这里str在编译期间不能确定，所以需要加载定义常量的类。 当一个接口初始化时，并不要求父接口都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量时），才会初始化 类的加载的最终产品是位于内存中的Class对象，Class对象封装了类在方法区内的数据结构，并向Java程序员提供了访问方法区内的数据结构的接口 虚拟机字节码执行引擎运行时栈帧结构 局部变量表，编译期已经确定了大小。最小存储单元叫 slot。slot复用，全局变量，在加载中会被赋初始值，初始化阶段会被赋上用户定义的值。方法内的局部变量，没有机会赋值，因此使用局部变量必须赋值。 操作数栈，虚拟机指令执行方式 动态连接，符号引用 方法返回地址，附加信息 方法调用javap -verbose xxx.class 查看class文件的汇编指令 静态分派 编译期确定静态类型，针对方法的重载public void sayHello(Parent p) &#123; System.out.println(\"parent called\");&#125;public void sayHello(Child1 c) &#123; System.out.println(\"child1 called\");&#125;Parent c = new Child1(); // Parent是静态类型d.sayHello((Child2)c);// 静态类型改变 方法调用，多个匹配，会选择一个最比配的方法翻译为invokevirtual 动态分派，针对方法的重写，根据实际类型方法翻译为invokevirtual，是在invokevirtual里做了处理 动态类型语言支持静态类型语言在非运行阶段，变量的类型时可以确定的，也是变量是有类型的动态类型在非运行阶段，变量类型时无法确定的，也就是变量是没有类型的，但值是有类型的，也就是运行期间可以确定变量的值的类型 ####Java的内存模型禁止把final字段的写，重排序到构造方法以外。final 字段不能再静态代码块中赋值。必须在类初始化之后赋值，且只能初始化一次。 初始化顺序：静态代码块，main方法，构造器，代码块 面试题 i = i++和 i = ++i public static void main(String[] args) &#123; int i = 1; i = i++; int j = i++; int k = i + ++i * i++; System.out.println(\"i=\"+i); System.out.println(\"j=\"+j); System.out.println(\"k=\"+k);&#125; i = i++, i 变量先进入操作数栈，然后在局部变量表中进行自增，然后在把栈中的数据返回给我们的变量 i 反过来，i = ++i， i 变量先在局部变量表中进行自增，然后再将 i 进栈，然后再把栈中的数据返回给我们的变量 i 所以这题的答案是：i=4j=1k=11 2.类变量准备阶段和初始化阶段差别public class Test &#123; public static void main(String[] args) &#123; Singleton singleton = Singleton.getInstance(); System.out.println(\"counter1: \"+ Singleton.counter1); System.out.println(\"counter2: \"+ Singleton.counter2); // 输出接口 1 0 &#125;&#125;class Singleton &#123; public static int counter1; private static Singleton singleton = new Singleton(); private Singleton() &#123; counter1++; counter2++; // 这里时 counter1 和counter2 都是1 &#125; public static int counter2 = 0; // 这里对counter2重新赋值 public static Singleton getInstance() &#123; return singleton; &#125;&#125; Singleton类加载过程中，有两步都对counter2的值进行了修改： 在准备阶段，counter1 赋初值 0， singleton赋初值null， 构造方法没有执行，counter2 赋初值 0。 外部调用类的静态方法，类被调用，类从上到下进行初始化，singleton初始值为new Singleton()，构造方法被执行，counter2 值为2，然后对counter2初始化，值为0，所以最后打印出来counter2值为0。 把 public static int counter1; 改为 public static int counter1 = 1;，打印结果是2，0。 准备阶段赋初值，初始化阶段为类变量赋予正确默认值，且初始化赋值按照从上到下执行。具体解释可以看这篇文章：https://juejin.cn/post/6991736846204010533 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/08/31/JVM-stack-and_heap/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"JVM","slug":"jvm","permalink":"http://agehua.github.io/tags/jvm/"}]},{"title":"Android Studio CPU Profiler使用","slug":"profile_analysis","date":"2020-07-09T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2020/07/10/profile_analysis/","link":"","permalink":"http://agehua.github.io/2020/07/10/profile_analysis/","excerpt":"Android Studio CPU Profiler使用CPU Profiler谷歌的官方文档使用 CPU Profiler 检查 CPU 活动中，对CPU Profiler的功能描述是：","text":"Android Studio CPU Profiler使用CPU Profiler谷歌的官方文档使用 CPU Profiler 检查 CPU 活动中，对CPU Profiler的功能描述是： 系统跟踪数据：捕获精细的详细信息，以便您检查应用与系统资源的交互情况。 方法和函数跟踪数据：对于应用进程中的每个线程，您可以了解一段时间内执行了哪些方法 (Java) 或函数 (C/C++)，以及每个方法或函数在其执行期间消耗的 CPU 资源。您还可以使用方法和函数跟踪数据来识别调用方和被调用方。调用方是指调用其他方法或函数的方法或函数，而被调用方是指被其他方法或函数调用的方法或函数。您可以使用此信息来确定哪些方法或函数负责调用常常会消耗大量资源的特定任务，并优化应用的代码以避免不必要的工作。 本文是我想对App的启动过程进行优化，先总结对Profiler工具的使用。 如何获取 trace 数据CPU Profiler可以对trace文件进行分析，获取trace文件的方式，大概有3种： 1.启用调试设备，在Profiler面板左上角点击加号➕，第二项是已连接的可调试设备，点击设备，选择要调试应用的进程。 2.还是上面加号➕，点击选择第一项 load from file…，表示用本地的文件，关于文件的生成有两种方式： 1.在搭载 Android 9（API 级别 28）或更高版本的设备上，您可以使用一个名为“系统跟踪”的系统应用来记录设备上的系统跟踪数据，详细介绍在这里 2.在Android 8.0（API 级别 26）或更高版本的设备上，使用 Debug API，掉用startMethodTracing(String tracePath) 开始记录数据；调用 stopMethodTracing()停止记录数据。结束后会在tracePath（默认会在sd卡根目录创建&lt;trace-name&gt;.trace文件）。 注意Debug API 不要和其他两种方式同时使用 如何生成app启动过程中的 trace数据 1.依次选择 Run &gt; Edit Configurations。 2.在 Profiling 标签中，勾选 Start recording a method trace on startup 旁边的复选框。 3.从菜单中选择 CPU 记录配置。 4.点击 Apply。 5.依次选择 Run &gt; Profile，将您的应用部署到搭载 Android 8.0（API 级别 26）或更高版本的设备上。 如何使用CPU Profiler 进行分析成功导入或直接调试出数据后，Profiler面板会如下图所示(这里只截了一部分)： 图中最上面是整个trace文件记录的时间段，默认是选中了全部。下面是我们的应用里使用到CPU的各个线程，其中记录显示的颜色有三种： 1.橙色，是指对系统 API 的调用 2.绿色，对应用自有方法的调用 3.蓝色，为对第三方 API（包括 Java 语言 API）的调用 点击mian，对应应用的主线程，Profiler面板的右侧会展示这个线程的数据，分三个维度： Top Down 标签显示一个调用列表，在该列表中展开方法或函数节点会显示它的被调用方 Flame Chart 标签页提供一个倒置的调用图表，用来汇总完全相同的调用堆栈。也就是说，将具有相同调用方顺序的完全相同的方法或函数收集起来，并在火焰图中将它们表示为一个较长的横条。这样更方便您查看哪些方法或函数消耗的时间最多。不过，这也意味着，横轴不代表时间轴，而是表示执行每个方法或函数所需的相对时间。 Bottom Up 标签页显示一个调用列表，在该列表中展开函数或方法的节点会显示它的调用方。Bottom Up 标签页用于按照占用的 CPU 时间由多到少（或由少到多）的顺序对方法或函数排序 App启动流程分析在Top Down标签页下，有一个搜索框，可以输入想要重点关注的方法调用。对于App启动流程，我建议有几处可以关注： attach() (android.app.Application)，这里会回调application的attachBaseContext()方法。 callApplicationOnCreate() (android.app.Instrumentation)，这里会回调application的onCreate()方法，可以检查以上两处有无耗时操作，比如各种sdk的初始化。 搜索框输入第一个启动的activity，类似 WelcomeActivity 这种，查找关于这个activity的onCreate()和onResume()中的耗时方法。 暂时只想到这几点，如有遗漏，欢迎补充~ 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/07/10/profile_analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Profiler","slug":"profiler","permalink":"http://agehua.github.io/tags/profiler/"}]},{"title":"分析下载功能源码和实现","slug":"download-function-analysis","date":"2020-05-25T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2020/05/26/download-function-analysis/","link":"","permalink":"http://agehua.github.io/2020/05/26/download-function-analysis/","excerpt":"安卓下载功能分析最近看了一份实现下载功能的代码，为了方便学习和记忆，将下载功能拆分，根据功能模块分析源码逻辑，做了一份整理：\n目标\n\n1.支持多种下载api，如okhttp、HttpURLConnection\n2.多线程、断点续传下载，线程池支持\n3.下载管理：开始、暂停、继续、取消、重新开始","text":"安卓下载功能分析最近看了一份实现下载功能的代码，为了方便学习和记忆，将下载功能拆分，根据功能模块分析源码逻辑，做了一份整理： 目标 1.支持多种下载api，如okhttp、HttpURLConnection 2.多线程、断点续传下载，线程池支持 3.下载管理：开始、暂停、继续、取消、重新开始 最基础功能下载需要创建一个代理类，FileDownloadProxy 来判断需要使用哪种方式下载以使用HttpURLConnection方式为例下载文件，创建一个 UrlConnectionFileDownload 类HttpURLConnection connection = null;File downloadingFile = new File(bean.getDownloadingPath());long downloadSize = downloadingFile.length();try &#123; connection = (HttpURLConnection) url.openConnection(); connection.setRequestMethod(\"GET\"); connection.addRequestProperty(\"Connection\", \"Keep-Alive\"); connection.setConnectTimeout(30000); connection.setReadTimeout(30000); connection.setInstanceFollowRedirects(false); int responseCode = connection.getResponseCode(); // 这里先忽略其他请求状态码，比如重定向302等 switch (responseCode) &#123; case HttpURLConnection.HTTP_OK: inputStream = urlConn.getInputStream(); //... &#125;&#125; catch (Exception e) &#123; return FileDownloadConstant.DOWNLOAD_ERROR;&#125; 然后根据输入流去下载文件，后面在分析如何断点下载 下载线程管理下载放在一个单独的线程里，最好线程池管理线程.线程池采用ThreadPoolExecutor，第六个参数可以指定一个ThreadFactory，创建指定的Runnable对象 public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue&lt;Runnable&gt; workQueue, ThreadFactory threadFactory) &#123; this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, defaultHandler);&#125; 实现一个Runnable类，XInfiniteRetryRunnable支持重试，并且能够通知前台线程执行状态 伪代码实现如下：int retryCount;boolean isRunning;int times = 5;@Overridepublic final void run() &#123; // 准备活动 if (!onPreExecute(bean)) &#123; if (!isRunning) &#123; onCancelled(bean); &#125; else &#123; onPreExecuteError(bean); &#125; return; &#125; while (isRunning) &#123; if (onExecute() || !isRunning) &#123; // 执行成功，或外部中断，退出循环 break; &#125; // 添加重试 while (isRunning &amp;&amp; retryCount &lt; times) &#123; Thread.sleep(100 * retryCount); retryCount++; &#125; &#125; // 执行结束 if (isRunning) &#123; // 正常结束情况下，调用onPostExecute onExecuteFinish(bean); &#125; else &#123; // 被中断情况下，调用onCancelled onCancelled(bean); &#125;&#125;// 通知外界，用于执行耗时任务boolean onExecute(T bean);// 通知外界，正常执行成功boolean onExecuteFinish(T bean);// 在这里执行下载前数据的初始化操作boolean onPreExecute(T bean)void onCancelled(T bean);void onPreExecuteError(T bean); 最后调用ExecutorService.submit() 提交下载线程 下载状态管理前端需要知道下载中的状态，并作出相应的处理定义一个下载类对象，总结一下，大概有五个状态TODO,DOING,DONE,ERROR,DEFAULT（未初始化状态）public interface TaskBean extends Cloneable &#123; public static final int STATUS_DEFAULT = -1;// 默认状态(未进执行队列) public static final int STATUS_TODO = 0;// 未执行状态 public static final int STATUS_DOING = 1;// 正在执行状态 public static final int STATUS_DONE = 2;// 已完成状态 public static final int STATUS_ERROR = 3;// 错误状态 // 定义一些属性方法 String getId(); int getStatus(); void setStatus(int status); public long getCompleteSize(); public void setCompleteSize(long completeSize);&#125; 使用状态机处理状态转换状态机有五个行为start,pause,abort,endSuccess,endError子类继承时，重写五个行为的回调方法即可：onStart(),onPause(),onAbort(),onEndSuccess(),onEndError() start = {@link TaskBean#STATUS_TODO} / {@link TaskBean#STATUS_ERROR} to {@link TaskBean#STATUS_DOING} pause = {@link TaskBean#STATUS_DOING} to {@link TaskBean#STATUS_TODO} or {@link TaskBean#STATUS_DEFAULT} abort = all status to {@link TaskBean#STATUS_DONE} endSuccess ={@link TaskBean#STATUS_DOING} to {@link TaskBean#STATUS_DONE} endError = {@link TaskBean#STATUS_DOING} to {@link TaskBean#STATUS_ERROR} 先定义一个接口，大概方法如下：public interface ITaskExecutor&lt;B extends TaskBean&gt; &#123; // 这里的参数采用数据，而不是int值的方式，可以避免必须传入一个int值，preStatus可以为空 int start(int... preStatus); int pause(int... postStatus); boolean abort(); B getBean(); String getId(); void setStatus(int status); int getStatus(); void setListener(ITaskListener&lt;B&gt; listener); ITaskListener&lt;B&gt; getListener(); // 通过一个listener将状态机状态通知出去&#125; 定义一个抽象类实现状态的检查和切换，下面代码以start状态为例：public abstract class StateMachineExecutor&lt;B extends TaskBean&gt; implements ITaskExecutor&lt;B&gt; &#123; private volatile int mStatus; // 状态 private B mBean; // 任务数据 @Override public int start(int... preStatus) &#123; // 检查任务状态 int oldStatus = getStatus(); if (oldStatus == TaskBean.STATUS_STARTING || oldStatus == TaskBean.STATUS_DOING) &#123; return StateMachineStatus.TASK_START_DOING_OR_STARTING; &#125; if (getStatus() != TaskBean.STATUS_TODO &amp;&amp; getStatus() != TaskBean.STATUS_ERROR) &#123; //在三种情况下可以启动下载任务：STATUS_TODO,STATUS_ERROR,preStatus[0]指定状态才能启动 return StateMachineStatus.TASK_INVALIDATED_STATUS; &#125; //将当前任务标记为正在启动状态 setStatus(TaskBean.STATUS_STARTING); if (!onStart()) &#123; // 子类要实现onStart()方法 // 任务启动失败 setStatus(oldStatus); return StateMachineStatus.TASK_START_FAIL; &#125; // 任务启动完成，设置状态为进行中 setStatus(TaskBean.STATUS_DOING); if (mListener != null) &#123; mListener.onStart(getBean()); &#125; return StateMachineStatus.TASK_START_SUCCESS; &#125; @Override public int pause(int... postStatus) &#123; &#125; @Override public boolean abort() &#123; &#125; @Override public void setStatus(int status) &#123; mStatus = status; mBean.setStatus(status); &#125; @Override public int getStatus() &#123; return mStatus; &#125; // 子类通过实现抽象方法，获取执行中的状态回调 protected abstract boolean onStart(); protected abstract boolean onPause(); protected abstract boolean onAbort(); protected abstract boolean onEndSuccess(); protected abstract boolean onEndError(String errorCode, boolean retry);&#125; 在这个抽象类里，定义了listener，子类可以自己判断是否需要监听状态事件，定义抽象方法，子类必须在特定状态实现特定方法。setStatus()和getStatus()是操作任务对象（B）的状态，而start()方法的返回值是状态机的状态，这样的好处是状态机调度任务执行状态（这是使用状态的目的）和状态机本身的状态相互分离。 状态机与下载任务结合public class DownloadFileTask extends StateMachineExecutor&lt;FileDownloadObject&gt; &#123; /** * 负责启动和轮询的异步线程 */ private volatile FileDownloadRunnable mRunnable; @Override protected boolean onStart() &#123; // 在开始状态中创建runnable，并提交给线程池 mRunnable = new FileDownloadRunnable(mContext, this); FileDownloadExecutors.UNIVERSAL_DOWNLOAD_POOL.submit(mRunnable); &#125; @Override protected boolean onPause() &#123; exitRunnable(); return true; &#125; @Override protected boolean onAbort() &#123; exitRunnable(); return true; &#125; @Override protected boolean onEndSuccess() &#123; mRunnable = null; return true; &#125; @Override protected boolean onEndError(String errorCode, boolean retry) &#123; mRunnable = null; return true; &#125; private void exitRunnable() &#123; if (mRunnable != null) &#123; mRunnable.cancel(); mRunnable = null; &#125; &#125; public void notifyDoing(long completeSize) &#123; if (mListener != null) &#123; if (this.getStatus() != this.getBean().getStatus()) &#123; //保持下载任务和下载对象的状态统一 this.getBean().setStatus(this.getStatus()); &#125; mListener.onDoing(getBean(), completeSize); &#125; &#125;&#125; 这里的FileDownloadRunnable就是继承了XInfiniteRetryRunnable类，实现了onExecute()、onExecuteFinish()、onPreExecute()方法FileDownloadObject是实现了TaskBean接口，拓展一些TaskBean没有的属性class FileDownloadRunnable extends XInfiniteRetryRunnable&lt;FileDownloadObject&gt; &#123; private XBaseTaskExecutor&lt;FileDownloadObject&gt; mHost; protected FileDownloadRunnable(Context context, XBaseTaskExecutor&lt;FileDownloadObject&gt; host) &#123; mHost = host; &#125; @Override public boolean onPreExecute(FileDownloadObject bean) &#123; //检查url，filePath是否正确 if (TextUtils.isEmpty(bean.getId())) &#123; getBean().errorCode = FileDownloadConstant.FILE_DOWNLOAD_URL_NULL; // 校验失败返回false，线程不在继续执行 return false; &#125; if (TextUtils.isEmpty(bean.getDownloadPath())) &#123; getBean().errorCode = FileDownloadConstant.FILE_DOWNLOAD_PATH_NULL; return false; &#125; &#125; @Override public boolean onExecute(FileDownloadObject bean) &#123; int result = -1; //标记下载开始时间 bean.setDownloadStartTime(System.currentTimeMillis()); // 封装了HttpUrlConnection，下载文件，并监听下载进度 result = httpAdapter.downloadFile(bean, bean.getCallbackInterval(), new DownloadProgressCallback&lt;FileDownloadObject&gt;() &#123; @Override public void onDataChanged(FileDownloadObject bean) &#123; // 下载进度保存在了bean中 if (bean.verifyContentLength() &amp;&amp; bean.getFileSzie() == -1) &#123; bean.setFileSize(bean.getContentLength()); &#125; // 通过DownloadFileTask的listener将进度通知出去 mHost.notifyDoing(-1); &#125; &#125;); &#125; @Override public void onExecuteFinish(FileDownloadObject bean) &#123; if (isDownloadSuccess) &#123; mHost.endSuccess(); &#125; else &#123; deleteFileIfError(bean); mHost.endError(getBean().errorCode, true); &#125; &#125; //... &#125; 到这里就将下载线程和状态机联系了起来，外面只需要接触DownloadFileTask这一个类，就可以监听执行下载的状态 HttpUrlConnection断点下载再说下HttpUrlConnection实现断点下载，补充文章开头的部分int responseCode = connection.getResponseCode();switch (responseCode) &#123; case HttpURLConnection.HTTP_OK: case HttpURLConnection.HTTP_PARTIAL: // 关键在处理206状态码 bean.setFileSize(connection.getContentLength()); return downloadFileByUrlConnection(connection, bean, callbackInterval, callback); //...&#125; 下载涉及到BufferedInputStream的使用，具体可以看下这篇博文：JavaIO之BufferedInputStream详解private static final int DOWNLOAD_BUFFER_SIZE = 16 * 1024;private int downloadFileByUrlConnection(HttpURLConnection connection, B bean, long callbackInterval, DownloadProgressCallback&lt;B&gt; callback) &#123; FileOutputStream fos = null; BufferedInputStream bis = null; InputStream inputStream = null; File downloadingFile = null; long contentLength = -1; long completeSize = 0; byte[] mBuffer; bean.setErrorCode(\"\"); try &#123; if (connection.getURL() != null) &#123; bean.setDownloadUrl(connection.getURL().toString()); &#125; inputStream = connection.getInputStream(); if (inputStream == null) &#123; bean.setErrorCode(FileDownloadConstant.FILE_DOWNLOAD_INPUTSTREAM_IS_NULL); return FileDownloadConstant.DOWNLOAD_INTERVAL_RETRY; &#125; mBuffer = new byte[DOWNLOAD_BUFFER_SIZE]; //从contentLength获取，若返回时200，则contentLength等于整个文件大小 //若返回206，则contentLength表示这个文件剩余下载的大小，需要更新整个文件大小 contentLength = bean.getFileSzie(); completeSize = bean.getCompleteSize(); downloadingFile = new File(bean.getDownloadingPath()); //contentLength对于下载没有帮助，仅用于计算下载进度 if (contentLength &lt;= 0) &#123; deliverException(bean); &#125; else &#123; //修正completeSize大小 if (completeSize &lt; 0) &#123; completeSize = 0; &#125; //更新总大小 long realSize = completeSize + contentLength; if (realSize &gt; 0 &amp;&amp; realSize != bean.getFileSzie()) &#123; bean.setFileSize(realSize); &#125; &#125; bis = new BufferedInputStream(inputStream); fos = new FileOutputStream(downloadingFile, true); // 之前read读取的数据量 int bufferStart = 0; // 一次read读取的数据量 int numRead = 0; // 用于控制刷新进度的变量 long curUpdateTime = 0; long lastUpdateTime = System.currentTimeMillis(); long lastCompleteSize = completeSize; while (true) &#123; // 如果被中断，则整体退出 if (!isRunning()) &#123; bean.setErrorCode(FileDownloadConstant.FILE_DOWNLOAD_ABORT); return FileDownloadConstant.DOWNLOAD_ERROR; &#125; curUpdateTime = System.currentTimeMillis(); numRead = bis.read(mBuffer, bufferStart, DOWNLOAD_BUFFER_SIZE - bufferStart); // 已经没有数据了，退出循环 if (numRead == -1) &#123; if (bufferStart &gt; 0) &#123; // buffer未填充满，但已经没数据了，则写入文件 fos.write(mBuffer, 0, bufferStart); &#125; break; &#125; // 递增已下载大小 completeSize = completeSize + numRead; // 第一次刷新UI，同时为了防止频繁刷新界面，第二次刷新UI间隔大于1秒 if (curUpdateTime - lastUpdateTime &gt;= callbackInterval || isFirstCallback) &#123; //计算速度 long increaseCompleteSize = completeSize - lastCompleteSize; long gapTime = curUpdateTime - lastUpdateTime; long speed = 0; if (gapTime != 0) &#123; speed = increaseCompleteSize / gapTime * 1000; &#125; bean.setSpeed(speed); bean.setCompleteSize(completeSize); lastUpdateTime = curUpdateTime; lastCompleteSize = completeSize; if (callback != null) &#123; callback.onDataChanged(bean); &#125; &#125; if (numRead + bufferStart &lt; DOWNLOAD_BUFFER_SIZE) &#123; // buffer未填满 bufferStart = numRead + bufferStart; &#125; else &#123; // buffer已填满，则写入文件 fos.write(mBuffer, 0, DOWNLOAD_BUFFER_SIZE); // buffer重新开始填充 bufferStart = 0; &#125; &#125; //下载完成 if (callback != null) &#123; bean.setCompleteSize(completeSize); callback.onDataChanged(bean); &#125; return FileDownloadConstant.DOWNLOAD_SUCCESS; &#125; catch (SocketTimeoutException e) &#123; return FileDownloadConstant.DOWNLOAD_SOCKET_RETRY; &#125; catch (SocketException e) &#123; return FileDownloadConstant.DOWNLOAD_SOCKET_RETRY; &#125; catch (IOException e) &#123; bean.setErrorCode(FileDownloadConstant.FILE_DOWNLOAD_IO_EXCEPTION); bean.setErrorInfo(e.getMessage()); return FileDownloadConstant.DOWNLOAD_INTERVAL_RETRY; &#125; finally &#123; FileUtils.silentlyCloseCloseable(bis); FileUtils.silentlyCloseCloseable(inputStream); FileUtils.silentlyCloseCloseable(fos); &#125;&#125; 文章就到这里了，后面也可以把 DownloadFileTask 这个类加到一个单独的进程，采用aidl的方式跨进程调用，这里就不详说了。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2020/05/26/download-function-analysis/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"download","slug":"download","permalink":"http://agehua.github.io/tags/download/"}]},{"title":"从FrameLayout分析View测量原理","slug":"Android-Measure","date":"2019-12-08T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/12/09/Android-Measure/","link":"","permalink":"http://agehua.github.io/2019/12/09/Android-Measure/","excerpt":"Android View测量原理public class DecorView extends FrameLayout implements RootViewSurfaceTaker, WindowCallbacks &#123;    //...&#125;\n我们知道DecorView是继承自FrameLayout，而且FrameLayout本身也比较简单，所以本文打算从FrameLayout的角度来分析view的measure过程。","text":"Android View测量原理public class DecorView extends FrameLayout implements RootViewSurfaceTaker, WindowCallbacks &#123; //...&#125; 我们知道DecorView是继承自FrameLayout，而且FrameLayout本身也比较简单，所以本文打算从FrameLayout的角度来分析view的measure过程。 View的根布局每个Activity都要重写onCreate方法，通常是调用setContentView来设置当前Activity的布局。那么每个Activity布局是放在了哪里呢？传说中的根布局到底是什么呢？一起往下看吧。@Override public void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); &#125; 进入setContentView的方法里面： public void setContentView(int layoutResID) &#123; getWindow().setContentView(layoutResID); initActionBar(); &#125; getWindow()会返回一个继承Window的PhoneWindow(TV的话，会是TVWindow)，然后执行它的setContentView()，而如下所示，PhoneWindow是在Activity的attach()中通过makeNewWindow生成的 final void attach(Context context, ActivityThread aThread, // 此处省去一些代码…… mWindow = PolicyManager.makeNewWindow(this); mWindow.setCallback(this); mWindow.getLayoutInflater().setPrivateFactory(this); if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) &#123; mWindow.setSoftInputMode(info.softInputMode); &#125; if (info.uiOptions != 0) &#123; mWindow.setUiOptions(info.uiOptions); &#125; // 此处省去巨量代码…… &#125; PolicyManager通过反射得到了Policy，如下 public final class PolicyManager &#123; private static final String POLICY_IMPL_CLASS_NAME = \"com.android.internal.policy.impl.Policy\"; private static final IPolicy sPolicy; static &#123; try &#123; Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME); sPolicy = (IPolicy)policyClass.newInstance(); &#125; catch (ClassNotFoundException ex) &#123; throw new RuntimeException( POLICY_IMPL_CLASS_NAME + \" could not be loaded\", ex); &#125; catch (InstantiationException ex) &#123; throw new RuntimeException( POLICY_IMPL_CLASS_NAME + \" could not be instantiated\", ex); &#125; catch (IllegalAccessException ex) &#123; throw new RuntimeException( POLICY_IMPL_CLASS_NAME + \" could not be instantiated\", ex); &#125; &#125; // 省去构造方法…… public static Window makeNewWindow(Context context) &#123; return sPolicy.makeNewWindow(context); &#125; // 省去无关代码…… &#125; 在Policy中的makeNewWindow()直接返回了一个PhoneWindow public Window makeNewWindow(Context context) &#123; return new PhoneWindow(context); &#125; 下面就说到了，上面提的setContentView() public class PhoneWindow extends Window implements MenuBuilder.Callback &#123; // 省去代码…… @Override public void setContentView(int layoutResID) &#123; if (mContentParent == null) &#123; installDecor(); &#125; else &#123; mContentParent.removeAllViews(); &#125; mLayoutInflater.inflate(layoutResID, mContentParent); final Callback cb = getCallback(); if (cb != null &amp;&amp; !isDestroyed()) &#123; cb.onContentChanged(); &#125; &#125; // 省去代码…… &#125; 到这里我们可以看出，就是将我们自己传进来的layoutId，添加到mContentParent下面，而这个mContentParent是在installDecor()里面赋值的，首先会初始化成员变量DecorView类的mDecor，然后调用generateLayout()，传入DecorView，来得到mContentParent。private void installDecor() &#123; if (mDecor == null) &#123; mDecor = generateDecor(); // 省省省…… &#125; if (mContentParent == null) &#123; mContentParent = generateLayout(mDecor); // 省省省…… &#125; // 省省省…… &#125;protected DecorView generateDecor(int featureId) &#123; // 省略context创建过程，主要是避免依赖到activity的context return new DecorView(context, featureId, this, getAttributes());&#125;protected ViewGroup generateLayout(DecorView decor) &#123; // 省去巨量代码…… ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT); // 省去一些代码…… &#125; 在generateLayout()中，会根据不同的Style类型来选择不同的布局文件，然后会add进DecorView中，然后调用findViewById()从DecorView里面得到mContentParent，这个才是真正的根布局，一般情况下，根布局都是FrameLayout来担任，我们可以用xml的最顶层viewGroup调用getParent()，返回的就是FrameLayout对象，其id是android:id=”@android:id/content”。 所以，一个Activity，里面是PhoneWindow，然后是DecorView，这个DecorView继承自FrameLayout，最后，才是我们自己setContentView的布局 VSYNC接下来，View就显示出来了么？我们熟知的 onMeasure、onLayout 和 onDraw都还没有调用呢？看起来，我们需要一个时机来触发 View 的操作。这个就得说下垂直同步机制(VSYNC)： VSYNC 就是一种同步机制，以某种固定的频率进行同步，当其他组件收到这个同步信号时，就执行相应的操作。设想一下，如果没有这个同步机制，各个模块又怎能知道在哪个时候去执行自己的工作了？ 这里可以初步地将 VSYNC 当做闹钟，每间隔固定时间，就响一次，其他组件听到闹铃后，就开始干活了。这个间隔的时间，与屏幕刷新频率有关，例如大多数 Android 设备的刷新频率是 60 FPS(Frame per second)，一秒钟刷新60次，因而间隔时间就是 1000 / 60 = 16.667 ms。这个时间，大家是不是很熟悉了？看过太多性能优化的文章，都说每一帧的绘制时间不要超过 16 ms，其背后的原因就是这个。绘制每一帧对应的 View，这个步骤发生在 UI 线程上，所以也不要在 UI 线程上进行耗时的操作，否则就可能在 16 ms内，无法完成界面更新操作了。 长话短说，总结一下，当 Choreographer 接收到 VSYNC 信号后，ViewRootImpl 调用 scheduleTraversals 方法，通知 View 进行相应的渲染，其后 ViewRootImpl 将 View 添加或更新到 Window 上去，并会执行TraversalRunnable 的doTraversal()，会调用到 performTraversals()，这是一个非常长的方法，里面就会提到我们熟悉的Measure、Layout 和 Draw。 measure()和onMeasure()performTraversals() 会调用到 performMeasure()方法：// ViewRootImpl中：private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) &#123; Trace.traceBegin(Trace.TRACE_TAG_VIEW, \"measure\"); try &#123; mView.measure(childWidthMeasureSpec, childHeightMeasureSpec); &#125; finally &#123; Trace.traceEnd(Trace.TRACE_TAG_VIEW); &#125;&#125; 这里的mView就是DecorView，但measure()方法View的，并且有final修饰，不能复写，在这个方法中调用了onMeasure()。在View中有默认的onMeasure实现： protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) &#123; setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec), getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));&#125;protected int getSuggestedMinimumWidth() &#123; return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth()); &#125;public static int getDefaultSize(int size, int measureSpec) &#123; int result = size; int specMode = MeasureSpec.getMode(measureSpec); int specSize = MeasureSpec.getSize(measureSpec); switch (specMode) &#123; case MeasureSpec.UNSPECIFIED: result = size; break; case MeasureSpec.AT_MOST: case MeasureSpec.EXACTLY: result = specSize; break; &#125; return result;&#125; getSuggestedMinimumWidth()，如果背景为空，那么我们直接返回mMinWidth最小宽度，否则，就在mMinWidth和背景最小宽度之间取一个最大值，getSuggestedMinimumHeight类同，mMinWidth和mMinHeight默认都是0。 getDefaultSize()中，当模式为AT_MOST和EXACTLY时均会返回解算出的测量尺寸，这里的specSize是。 FrameLayout的onMeasure方法@Overrideprotected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) &#123; int count = getChildCount(); // 父View传过来的layoutparams包含wrap_content属性 final boolean measureMatchParentChildren = MeasureSpec.getMode(widthMeasureSpec) != MeasureSpec.EXACTLY || MeasureSpec.getMode(heightMeasureSpec) != MeasureSpec.EXACTLY; mMatchParentChildren.clear(); int maxHeight = 0; int maxWidth = 0; int childState = 0; for (int i = 0; i &lt; count; i++) &#123; final View child = getChildAt(i); if (mMeasureAllChildren || child.getVisibility() != GONE) &#123; // 设置子View的宽度和高度，这里widthUsed 和 heightUsed都是0，说明子view想要多大就是多大 measureChildWithMargins(child, widthMeasureSpec, 0, heightMeasureSpec, 0); final LayoutParams lp = (LayoutParams) child.getLayoutParams(); // 累加子View的宽高和上下左右margin，统计所有子view中的最大宽度和高度，作为父view自己的宽高 maxWidth = Math.max(maxWidth, child.getMeasuredWidth() + lp.leftMargin + lp.rightMargin); maxHeight = Math.max(maxHeight, child.getMeasuredHeight() + lp.topMargin + lp.bottomMargin); childState = combineMeasuredStates(childState, child.getMeasuredState()); if (measureMatchParentChildren) &#123; if (lp.width == LayoutParams.MATCH_PARENT || lp.height == LayoutParams.MATCH_PARENT) &#123; // 子View指定了match_parent属性，需要在测量一次，先加到数组里 mMatchParentChildren.add(child); &#125; &#125; &#125; &#125; // 省略Foreground计算代码，非本文重点 // 第一次测量完成，让每个view按照自己想要的大小，同时FrameLayout自己的getMeasuredWidth() / // getMeasureHeight() 已经有值了 setMeasuredDimension(resolveSizeAndState(maxWidth, widthMeasureSpec, childState), resolveSizeAndState(maxHeight, heightMeasureSpec, childState &lt;&lt; MEASURED_HEIGHT_STATE_SHIFT)); count = mMatchParentChildren.size(); if (count &gt; 1) &#123; // 有超过1个子View设置了match_parent属性，需要重新测量FrameLayout的宽高 for (int i = 0; i &lt; count; i++) &#123; final View child = mMatchParentChildren.get(i); final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams(); final int childWidthMeasureSpec; if (lp.width == LayoutParams.MATCH_PARENT) &#123; // 设置子view的宽度为当前FrameLayout测量后的宽度（这里getMeasuredWidth 就是上面setMeasuredDimension 后的宽度） final int width = Math.max(0, getMeasuredWidth() - getPaddingLeftWithForeground() - getPaddingRightWithForeground() - lp.leftMargin - lp.rightMargin); childWidthMeasureSpec = MeasureSpec.makeMeasureSpec( width, MeasureSpec.EXACTLY); &#125; else &#123; // 非match_parent: 将子view margin算入子view的宽度中 childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec, getPaddingLeftWithForeground() + getPaddingRightWithForeground() + lp.leftMargin + lp.rightMargin, lp.width); &#125; final int childHeightMeasureSpec; if (lp.height == LayoutParams.MATCH_PARENT) &#123; // 高度与宽度同理，都是设置子view的宽或高为FrameLayout的宽或高 final int height = Math.max(0, getMeasuredHeight() - getPaddingTopWithForeground() - getPaddingBottomWithForeground() - lp.topMargin - lp.bottomMargin); childHeightMeasureSpec = MeasureSpec.makeMeasureSpec( height, MeasureSpec.EXACTLY); &#125; else &#123; childHeightMeasureSpec = getChildMeasureSpec(heightMeasureSpec, getPaddingTopWithForeground() + getPaddingBottomWithForeground() + lp.topMargin + lp.bottomMargin, lp.height); &#125; // 更新child的宽度 child.measure(childWidthMeasureSpec, childHeightMeasureSpec); &#125; &#125;&#125; measureChildWithMargins是ViewGroup的方法，并且调用了child.measure方法。FrameLayout继承子ViewGroupprotected void measureChildWithMargins(View child, int parentWidthMeasureSpec, int widthUsed, int parentHeightMeasureSpec, int heightUsed) &#123; final MarginLayoutParams lp = (MarginLayoutParams) child.getLayoutParams(); final int childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec, mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin + widthUsed, lp.width); final int childHeightMeasureSpec = getChildMeasureSpec(parentHeightMeasureSpec, mPaddingTop + mPaddingBottom + lp.topMargin + lp.bottomMargin + heightUsed, lp.height); child.measure(childWidthMeasureSpec, childHeightMeasureSpec);&#125; 总结：当FrameLayout的宽或高属性为Wrap_content属性时，同时有两个及以上的子view属性为match_parent时，则所有子view会measure两次 FrameLayout什么情况下子view会measure两次？需要满足两个条件：1.FrameLayout自身的MeasureSpec.Mode 不等于 MeasureSpec.EXACTLY。2.有两个或以上子view设置了match_parent 为什么这种情况FrameLayout会测量两次呢？我们先看下面这个问题： 获取ChildMeasureSpec时，FrameLayout 与 RelativeLayout 区别这里还有一个问题：getChildMeasureSpec是ViewGroup的静态方法，但是getChildMeasureSpec方法会改变子view的 MeasureSpec.Mode。 如果FrameLayout的SpecMode是AT_MOST或UNSPECIFIED，而子view的layout属性时MATCH_PARENT或WRAP_CONTENT，则子view的SpecMode会变成和父view一样 注意看下面代码的注释1和注释2public static int getChildMeasureSpec(int spec, int padding, int childDimension) &#123; // 获取父容器（这里指的是FrameLayout）的测量模式和尺寸大小 int specMode = MeasureSpec.getMode(spec); int specSize = MeasureSpec.getSize(spec); // 这个尺寸应该减去内边距的值 int size = Math.max(0, specSize - padding); // 声明临时变量存值 int resultSize = 0; int resultMode = 0; switch (specMode) &#123; case MeasureSpec.EXACTLY: // 父容器尺寸大小是一个确定的值 if (childDimension &gt;= 0) &#123; //如果childDimension是一个具体的值 那么就将该值作为结果 resultSize = childDimension; // 而这个值也是被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.MATCH_PARENT) &#123; //如果子元素的布局参数为MATCH_PARENT // 那么就将父容器的大小作为结果 resultSize = size; // 因为父容器的大小是被确定的所以子元素大小也是可以被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.WRAP_CONTENT) &#123; //如果子元素的布局参数为WRAP_CONTENT // 那么就将父容器的大小作为结果 resultSize = size; // 但是子元素的大小包裹了其内容后不能超过父容器 resultMode = MeasureSpec.AT_MOST; &#125; break; case MeasureSpec.AT_MOST: // 父容器尺寸大小拥有一个限制值 if (childDimension &gt;= 0) &#123; //如果childDimension是一个具体的值 // 那么就将该值作为结果 resultSize = childDimension; // 而这个值也是被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.MATCH_PARENT) &#123; //如果子元素的布局参数为MATCH_PARENT，那么就将父容器的大小作为结果 resultSize = size; // 注释1：因为父容器的大小是受到限制值的限制所以子元素的大小也应该受到父容器的限制 resultMode = MeasureSpec.AT_MOST; &#125; else if (childDimension == LayoutParams.WRAP_CONTENT) &#123; //如果子元素的布局参数为WRAP_CONTENT // 那么就将父容器的大小作为结果 resultSize = size; // 但是子元素的大小包裹了其内容后不能超过父容器 resultMode = MeasureSpec.AT_MOST; &#125; break; case MeasureSpec.UNSPECIFIED: // 父容器尺寸大小未受限制 if (childDimension &gt;= 0) &#123; //如果childDimension是一个具体的值，那么就将该值作为结果 resultSize = childDimension; // 而这个值也是被确定的 resultMode = MeasureSpec.EXACTLY; &#125; else if (childDimension == LayoutParams.MATCH_PARENT) &#123; //如果子元素的布局参数为MATCH_PARENT // 注释2：因为父容器的大小不受限制而对子元素来说也可以是任意大小所以不指定也不限制子元素的大小 resultSize = 0; resultMode = MeasureSpec.UNSPECIFIED; &#125; else if (childDimension == LayoutParams.WRAP_CONTENT) &#123; //如果子元素的布局参数为WRAP_CONTENT // 因为父容器的大小不受限制而对子元素来说也可以是任意大小所以不指定也不限制子元素的大小 resultSize = 0; resultMode = MeasureSpec.UNSPECIFIED; &#125; break; &#125; // 返回封装后的测量规格 return MeasureSpec.makeMeasureSpec(resultSize, resultMode); 回答上面问题，为什么这种情况FrameLayout的子view会测量两次？先看下图：以宽度为例说明，因为FrameLayout可能包含多个子view，第一次测量后，设置了match_parent的view1和view2变为wrap_content，child.getMeasuredWidth为wrap_content的宽度，即子view自己的宽度。由于有多个match_parent的子view，父view需要重新调整自己的宽度为最大的子view的宽度，所以所有的子view需要在根据父view的宽度重新调整一下自己的宽度，最终导致子view measure两次。 多说一句，RelativeLayout并没有用这个方法，而是自定义了一个getChildMeasureSpec()方法，所以RelativeLayout与FrameLayout表现上是不一样的。感兴趣的可以在Android Studio里修改一下下面布局，替换RelativeLayout和FrameLayout，试一下看下效果： &lt;RelativeLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\"&gt; &lt;TextView android:layout_width=\"match_parent\" android:layout_height=\"match_parent\" android:background=\"@android:color/holo_red_light\" android:gravity=\"center\" android:text=\"text\" /&gt; &lt;TextView android:layout_width=\"wrap_content\" android:layout_height=\"wrap_content\" android:gravity=\"center\" android:text=\"2222222222\" /&gt;&lt;/RelativeLayout&gt; Ref测量（Measure） 自定义View —— onMeasure、 onLayout 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/12/09/Android-Measure/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"FrameLayout","slug":"framelayout","permalink":"http://agehua.github.io/tags/framelayout/"},{"name":"RelativeLayout","slug":"relativelayout","permalink":"http://agehua.github.io/tags/relativelayout/"},{"name":"Measure","slug":"measure","permalink":"http://agehua.github.io/tags/measure/"}]},{"title":"弄懂Android 源码中那些巧妙位运算","slug":"Android-bits-operation","date":"2019-12-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2019/12/08/Android-bits-operation/","link":"","permalink":"http://agehua.github.io/2019/12/08/Android-bits-operation/","excerpt":"本文部分内容节选自星星笑语的文章\n原码反码补码的概念在介绍位运算符之前，我们先来看看关于反码补码等的相关知识。\n\n正数的原码反码补码相同，都是将数字转换为二进制形式，然后将高位补0。比如说对于8位来说：\n10所对应的原码反码补码都是 0000 1010\n30所对应的原码反码补码都是 0001 1110","text":"本文部分内容节选自星星笑语的文章 原码反码补码的概念在介绍位运算符之前，我们先来看看关于反码补码等的相关知识。 正数的原码反码补码相同，都是将数字转换为二进制形式，然后将高位补0。比如说对于8位来说： 10所对应的原码反码补码都是 0000 1010 30所对应的原码反码补码都是 0001 1110 而对于负数，负数的原码是它的绝对值对应的二进制，而最高位是1。所以： -10所对应的原码是 1000 1010 -30所对应的原码是 1001 1110 负数的反码是它原码最高位除外的其余所有位取反，所以： -10所对应的反码是 1111 0101 -30所对应的反码是 1110 0001 而负数的补码是将其反码的数值+1，所以： -10所对应的补码是 1111 0110 -30所对应的补码是 1110 0010 是不是感觉负数的三种很杂乱？没关系，马上让你觉得不过如此～ 我们对于刚才计算出来的负数的三种码，我们抛开符号为的概念，把三种码作为单存的二进制数来看。首先对于原码，原码是在最高位写上1得到的，而对于8位二进制，最高位的1是128，所以： -10所对应的原码是 1000 1010，而这个二进制数是128+10； -30所对应的原码是 1001 1110，而这个二进制数是128+30； 然后对于反码，在原码的基础上，最高位不变，其余各位取反，也就是说抛开最高位，其余各位变化前后的和是111 1111，所以： -10所对应的反码是 1111 0101，其值为127-10+128 -30所对应的反码是 1110 0001，其值为127-30+128 其余各位变化前后的和是111 1111，意思是 原码 + 反码 = 127 至于补码，就是反码加上1，所以： -10所对应的补码是 1111 0110，其值为256-10 -30所对应的补码是 1110 0010，其值为256-30 所以一个负数就可以看成是一个正数 256-x 计算机为什么要引入补码的概念呢？主要是补码能够简化计算，例如对于8位的二进制数，从0000 0000一直到1111 1111，如果看作补码，所表示的数依次为0，1，…，127，-128，-127，…，-2，-1。对于两个正数的加法，正数的补码就是它本身，所以直接相加就能得到结果（注意，如果和超过了127，结果会错误）； -128 对应的补码是 1000 0000，对应原码是 1 1000 0000 对于两个负数的加法，我们仍然可以将他们的补码直接相加，而得到结果～比如对于两个负数-a和-b，他们的补码分别是256-a和256-b，相加后是512-（a+b），当a+b小于128时（a+b&gt;128时这两个数相加超过了范围，得不到正确的结果），在计算机的表示是1 xxxx xxxx由于最高位的1超过了8位的范围所以舍去，所以相加结果是128-（a+b）而这就是-a-b的补码。 对于正数a和负数-b之间的加法，我们将其补码相加后得到256+a-b，而这就是a-b的补码（不管ab谁大都成立）。 由于减法可以对被减数取反，所以我们只用考虑加法运算。所以说如果使用补码，可以很好的将加减法运算转换成两个正数（负数的补码可以看成是一个正数256-x）的加法运算。如果计算机保存补码，在做数之间的加减法运算的时候能够直接将补码相加而得到正确的结果（没超过范围的情况下）。 我们也能够直接相加得到正确的结果。由于减法可以对被减数取反，所以我们只用考虑加法运算 实际上，考虑将所以有理数按256取模得到的数相等来分成256组，在做加减乘运算的时候，用同组的任意两个数运算得到的结果均是相同的，而负数和其补码是位于同一个组的，所以在做四则运算的时候，加减乘运算完全可以使用其的补码。 整型在 Java的内存形式学习完补码之后，我们认识到如果使用补码，其在做运算时的方便之处。而Java的整形就是保存的各个数的补码，我们也可以在 Java上验证： System.out.println(Integer.toHexString(-1));System.out.println(Integer.toHexString(-10));System.out.println(Integer.toHexString(Integer.MAX_VALUE));System.out.println(Integer.toHexString(Integer.MAX_VALUE));System.out.println(Long.toHexString(-1));System.out.println(Long.toHexString(Long.MAX_VALUE));fffffffffffffff67fffffff7fffffffffffffffffffffff7fffffffffffffff Java中的位运算要使用位运算之前，肯定是要了解下面的这些运算符号以及作用的。 与运算（and）&amp;表示，当两个相同位对应的数都是1的时候，该位获得的结果才是1，否则为0例如说6 &amp; 11，转换为二进制就是0110 &amp; 1011，结果为0010 或运算（or）|表示，当两个相同位对应的数只要有一个数1的时候，该位获得的结果为1，否则为0还是用6和11这两个数做例子，就是0110 | 1011 = 1111 非运算（not）~表示，这个运算只针对一个数字，将数字全部取反（原来是0结果就是1，原来是1结果就是0）。例如说：~110 = 001注意，这里的取反是对二进制数进行取反，如果对非二进制数取反，可能有意想不到的结果：System.out.println(\"～1 = \" + ~(1));System.out.println(\"～0 = \" + ~(0)); 这个例子是对整数int进行取反，结果是：~1 = -2 ~0 = -1，详细回答可以看这里 异或运算（xor）^表示，当两个相同位对应的数字不同的时候为1，否则为0例如说：0110 ^ 1011 = 1101 左移（shl）&lt;&lt;表示，a &lt;&lt; b表示a左移b位，由于移位在末位多出来的未知数字补零。在这里面可以等价为a * 2^b这个运算（针对十进制）。 右移（shr）&gt;&gt;表示，a &gt;&gt; b表示将a右移b位，原本的末位进行右移后会被舍弃，左边的用原有标志位补充。同样的，右移在十进制里面也可以近似为a / (2^b)的形式，不过要对结果取整，也不一定准确，只能够说意思大概如此。 无符号右移&gt;&gt;&gt;表示，不管正负标志位为0还是1，将该数的二进制码整体右移，左边部分总是以0填充，右边部分舍弃。 1 &lt;&lt; 1 = 2(对于int数的计算) 4 &gt;&gt; 1 = 2(对于int数的计算) 4 &gt;&gt;&gt; 1 = 2(对于int数的计算) System.out.println(Integer.toHexString(0x7fffffff &gt;&gt; 4));System.out.println(Integer.toHexString(0x8fffffff &gt;&gt; 4));System.out.println(Integer.toHexString(0xffffffff &gt;&gt; 4));System.out.println(Integer.toHexString(0x0fffffff &gt;&gt; 4));System.out.println();System.out.println(Integer.toHexString(0x7fffffff &lt;&lt; 4));System.out.println(Integer.toHexString(0x8fffffff &lt;&lt; 4));System.out.println(Integer.toHexString(0xffffffff &lt;&lt; 4));System.out.println(Integer.toHexString(0x0fffffff &lt;&lt; 4));System.out.println();System.out.println(Integer.toHexString(0x7fffffff &gt;&gt;&gt; 4));System.out.println(Integer.toHexString(0x8fffffff &gt;&gt;&gt; 4));System.out.println(Integer.toHexString(0xffffffff &gt;&gt;&gt; 4));System.out.println(Integer.toHexString(0x0fffffff &gt;&gt;&gt; 4)); 7ffffff f8ffffff ffffffff ffffff fffffff0 fffffff0 fffffff0 fffffff0 7ffffff 8ffffff fffffff ffffff 总结来说： 右移：整体向右移，原来的最高位是0，就补0，原来的最高位是1，就补1； 左移：整体左移，在最低位补0； 无符号右移：最高位补0。 位运算符的使用又如下几点需要注意： 位运算符都是在整型保存在内存地址上的每一位进行运算的，所以有些会看起来超出我们的常识； 左移右移并不能简单的看作是在数的基础上乘以2或者除以2，而要结合它的内存形式来具体分析。 例如：System.out.println(~1);结果是-2而不是0这是因为1在内存上是000....001,~1就是111...1110,而这是-2的补码，所以结果是-1；System.out.println(-1 &gt;&gt; 1);结果还是-1而不是0这是因为-1在内存上是111...1，它的符号位是1，所以右移的时候高位补1，结果不变；System.out.println(Integer.MAX_VALUE &lt;&lt; 1);结果是-2，正数左移移成了负数。。。System.out.println(0xBFFFFFFF);System.out.println(0xBFFFFFFF &lt;&lt; 1);-10737418252147483646负数左移成了正数。。。System.out.println(-1 &gt;&gt;&gt; 1);2147483647-1左移成了int的最大值。。。 Android中的应用 A | B 添加标志B，可以添加多个（只要不冲突）例如： mViewFlags = SOUND_EFFECTS_ENABLED | HAPTIC_FEEDBACK_ENABLED | FOCUSABLE_AUTO;// 或者mPrivateFlags |= PFLAG_FORCE_LAYOUT;mPrivateFlags |= PFLAG_INVALIDATED; A &amp; B 判断A中是否有标志B原理就是与运算之中的1 &amp; 1 = 1, 0 &amp; 1 = 0，以此来判断flag对应位是否存在该flag以(mViewFlags &amp; FOCUSABLE_AUTO) != 0这个判断语句为例：若为真，则与的结果不等于0，表示flag之中有该标志 (mPrivateFlags &amp; PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT A &amp; ~B 去除标志B（上者的逆运算）例如：mViewFlags = (mViewFlags &amp; ~FOCUSABLE) | newFocus用于去除原有的标志位并附上新的标志位（相当于更新） mPrivateFlags3 &amp;= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT; A ^ B 取出A与B不同的部分，一般用于判断A是否发生改变 int changed = mViewFlags ^ old;if (changed == 0) &#123; return;&#125; MeasureSpec许最早在Android源码里面接触位运算的话就是在自定义View部分的时候，当书里面提及MeasureSpec这个变量的时候采用如下描述： MeasureSpec代表一个32位int值，高2位代表SpecMode，低30位代表SpecSize，SpecMode是指测量模式，而SpecSize是指在某种测量模式下的规格大小。 这里面就是典型的位运算的运用，不论是这个变量需要分别拆分获得SpecMode和SpecSize，还是其他的一些相关的操作，都需要位运算。首先是SpecMode，在描述之中是高2位的部分，那么在处理之中一定会运用到左移或者右移来完成需求。 在这个类里面，一开始就声明了两个基本变量以及不同测量模式的值，已经用到了位运算中的左移// 声明位移量private static final int MODE_SHIFT = 30;// 后期截取SpecMode或SpecSize时使用的变量// 3对应的二进制是11，左移30位后，int值的前2位就都是1，后30位为0，二进制是：11000000000000000000000000000000private static final int MODE_MASK = 0x3 &lt;&lt; MODE_SHIFT;// 三种测量模式对应的值public static final int UNSPECIFIED = 0 &lt;&lt; MODE_SHIFT;public static final int EXACTLY = 1 &lt;&lt; MODE_SHIFT;public static final int AT_MOST = 2 &lt;&lt; MODE_SHIFT; 先看看是如何通过位运算来获取SpecMode和SpecSize：@MeasureSpecMode// 等价于@IntDef(value=&#123;...&#125;)。一种枚举类注释public static int getMode(int measureSpec) &#123; return (measureSpec &amp; MODE_MASK); // 让低30位的值变为0，只保留高2位的值&#125;public static int getSize(int measureSpec) &#123; return (measureSpec &amp; ~MODE_MASK); // 非运算直接让MASK值变成int值高2位为0，低30位为1 // 进行与运算，直接将高2位的值变为0&#125; 这里就是典型的通过位运算来截取对应值，利用的是x &amp; 1 = x, x &amp; 0 = 0，其中x代表0与1两种值。 这种方式让一个变量能够存储多个内容方式实现，甚至也可以使用这样的方式将合成的值作为特定的key来做匹配或者相似需求。接下来是如何获得MeasureSpec值：public static int makeMeasureSpec( @IntRange(from = 0, to = (1 &lt;&lt; MeasureSpec.MODE_SHIFT) - 1) int size, // 要求传入的size值在指定范围内 @MeasureSpecMode int mode) &#123; if (sUseBrokenMakeMeasureSpec) &#123;// 是否用原来的方法对MeasureSpec进行构建 return size + mode; &#125; else &#123; return (size &amp; ~MODE_MASK) | (mode &amp; MODE_MASK); &#125;&#125; 在API17及其以下的时候，是按照size + mode的方式进行构建，一个是只有int前2位有值，一个是只有int后30位有值，这么思考处理也情有可原。但假若两个值有溢出情况就会严重影响MeasureSpec的结果。故Google官方在API17之后就对该方法进行了修正，也是采用的位运算的形式：(size &amp; ~MODE_MASK) | (mode &amp; MODE_MASK)。相当于就是分别获得了SpecSize和SpecMode后通过或运算获得结果。 位运算应用口诀清零取反要用与，某位置一可用或若要取反和交换，轻轻松松用异或 Java中整形就是保存的各个数的补码。关于浮点型或原码、反码与补码的概念，请看这篇文章：Java基础补完之数值与位运算符 补充1、判断两个数是否异号int x = -1, y = 2;bool f = ((x ^ y) &lt; 0); // trueint x = 3, y = 2;bool f = ((x ^ y) &lt; 0); // false 这个技巧还是很实用的，利用的是补码编码的符号位。如果不用位运算来判断是否异号，需要使用if else分支，还挺麻烦的。有人可能想到利用乘积或者商来判断，但是这种方式可能造成溢出，从而出现错误。 Ref谈谈位运算和在Android中的运用 弄懂Android 源码中那些巧妙位运算 Android中巧妙的位运算 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/12/08/Android-bits-operation/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"bits operation","slug":"bits-operation","permalink":"http://agehua.github.io/tags/bits-operation/"}]},{"title":"CoordinatorLayout源码解读","slug":"Horizontal-Coordinator","date":"2019-09-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2019/09/12/Horizontal-Coordinator/","link":"","permalink":"http://agehua.github.io/2019/09/12/Horizontal-Coordinator/","excerpt":"CoordinatorLayout本文源码基于 27.1.1AppBarLayout 和 CoordinatorLayout是 2015年就已经推出的Material Design控件，一直以来也是只知其一这次通过阅读源码参考实现一个水平方向的 CoordinatorLayout和AppBarLayout组合。","text":"CoordinatorLayout本文源码基于 27.1.1AppBarLayout 和 CoordinatorLayout是 2015年就已经推出的Material Design控件，一直以来也是只知其一这次通过阅读源码参考实现一个水平方向的 CoordinatorLayout和AppBarLayout组合。CoordinatorLayout是一个增强型的FrameLayout。CoordinatorLayout#LayoutParams是用在子view上，对应在xml里子view的”app:layout_xxx“属性。通常的一个包含CoordinatorLayout的布局文件，大概是这样：&lt;android.support.design.widget.CoordinatorLayout xmlns:android=\"http://schemas.android.com/apk/res/android\" xmlns:app=\"http://schemas.android.com/apk/res-auto\" xmlns:tools=\"http://schemas.android.com/tools\" android:layout_width=\"match_parent\" android:layout_height=\"match_parent\" android:id=\"@+id/coordinator\"&gt; &lt;android.support.design.widget.AppBarLayout android:layout_width=\"match_parent\" android:id=\"@+id/appbar\" android:layout_height=\"220dp\" android:background=\"#ffffff\"&gt; .... &lt;/android.support.design.widget.AppBarLayout&gt; &lt;android.support.v7.widget.RecyclerView android:layout_width=\"match_parent\" android:layout_height=\"500dp\" android:background=\"#1d9d29\" app:layout_behavior=\"@string/appbar_scrolling_view_behavior\"&gt; .... &lt;/android.support.v7.widget.RecyclerView&gt;&lt;/android.support.design.widget.CoordinatorLayout&gt; 来看一下CoordinatorLayout#LayoutParams的解析// CoordinatorLayout#LayoutParamsLayoutParams(Context context, AttributeSet attrs) &#123; super(context, attrs); final TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.CoordinatorLayout_Layout); // ... mBehaviorResolved = a.hasValue( R.styleable.CoordinatorLayout_Layout_layout_behavior); if (mBehaviorResolved) &#123; // 这里通过反射获得对应的Behavior对象 mBehavior = parseBehavior(context, attrs, a.getString( R.styleable.CoordinatorLayout_Layout_layout_behavior)); &#125; a.recycle(); if (mBehavior != null) &#123; // If we have a Behavior, dispatch that it has been attached mBehavior.onAttachedToLayoutParams(this); &#125;&#125; 感兴趣的可以继续点到CoordinatorLayout_Layoutstyle里面看看。 这里简单介绍几个属性： app:layout_anchor app:layout_anchorGravity这两个一般配合FloatingActionButton使用，用来指定位置 app:layout_behavior是本文的重点，为子View指定一个Behavider，是一个字符串，这是使用反射方式取得Behavior类。具体解析方式去看上面的parseBehavior()方法，这里不介绍了 Bahavior介绍在上面的布局文件里，RecyclerView指定了一个 appbar_scrolling_view_behavior，对应的类为： android.support.design.widget.AppBarLayout$ScrollingViewBehavior。这个Behavior也可以配合其他view使用，比如ViewPager、ListView、ScrollView。 AppBarLayout为什么没有指定layout_behavior呢？因为CoordinatorLayout提供了一个注解：@Deprecated@Retention(RetentionPolicy.RUNTIME)public @interface DefaultBehavior &#123; Class&lt;? extends Behavior&gt; value();&#125; 而AppBarLayout正是通过注解的方式添加的：@CoordinatorLayout.DefaultBehavior(AppBarLayout.Behavior.class)public class AppBarLayout extends LinearLayout &#123; //...&#125; 关于这个注解的解析在getResolvedLayoutParams(View child)这个方法里，感兴趣的可以去看一下。Behavior解析出来后，调用child.layoutParams.setBehavior()，保存在了child的LayoutParams的成员变量里。 CoordinatorLayout.Behavior是一个抽象类，总共有9个子类，直接子类有4个，如下： AppBarLayout.ScrollingViewBehavior 继承自 HeaderScrollingViewBehavior AppBarLayout.Behavior 继承自 HeaderBehavior BaseTransientBottomBar.Behavior 继承自 SwipeDismissBehavior BottomSheetBehavior FloatingActionButton.Behavior HeaderBehavior 继承自 ViewOffsetBehavior HeaderScrollingViewBehavior 继承自 ViewOffsetBehavior SwipeDismissBehavior ViewOffsetBehavior 下面以CoordinatorLayout + AppBarLayout + Recyclerview为例，分析用到的Behavior类结构如下： 现在CoordinatorLayout的子view都有了Behavior类，那么它们之间怎么和CoordinatorLayout交互并联动呢？ 以AppBarLayout + Recyclerview为例分析子View之间联动CoordinatorLayout是通过CoordinatorLayout.Behavior来控制子view的连动，这里涉及到触摸事件的处理。 @Overridepublic boolean onTouchEvent(MotionEvent ev) &#123; boolean handled = false; boolean cancelSuper = false; MotionEvent cancelEvent = null; final int action = ev.getActionMasked(); // 这里mBehaviorTouchView 会在 performIntercept()方法返回true时被赋值，表示将事件交给CoordinatorLayout处理 if (mBehaviorTouchView != null || (cancelSuper = performIntercept(ev, TYPE_ON_TOUCH))) &#123; // Safe since performIntercept guarantees that // mBehaviorTouchView != null if it returns true final LayoutParams lp = (LayoutParams) mBehaviorTouchView.getLayoutParams(); final Behavior b = lp.getBehavior(); // 通过mBehaviorTouchView的layoutParams来获取Behavior对象，交由mBehaviorTouchView的Behavior对象来处理事件 if (b != null) &#123; handled = b.onTouchEvent(this, mBehaviorTouchView, ev); &#125; &#125; // Keep the super implementation correct if (mBehaviorTouchView == null) &#123; // 如果mBehaviorTouchView 为空，则还是交由父类去处理touch事件 handled |= super.onTouchEvent(ev); &#125; //...&#125; 从上面分析可以看出，CoordinatorLayout本身并没有处理touch事件，而是哪个子view确定拦截事件后，交给这个子view的Behavior对象来处理这个事件。 我们以AppBarLayout + Recyclerview这两个比较常见的子View形式来分析。首先有两种滑动逻辑： 当手指触摸AppBarLayout时候的滑动逻辑为弄清手指触摸AppBarLayout时候的滑动逻辑，我们先看一下AppBarLayout.Behavior这个类。关于这个类的继承关系可以看上面的类图，这里先总结一下两个类的作用，需要详细的实现的请自行阅读源码吧： ViewOffsetBehavior：该Behavior主要运用于View的移动，从名字就可以看出来，该类中提供了上下移动，左右移动的方法。HeaderBehavior：该类主要用于View处理触摸事件以及触摸后的fling事件，AppBarLayout.Behavior的onTouchEvent和onInterceptTouchEvent处理逻辑都是在这里 HeaderBehavior的滑动都是通过setHeaderTopBottomOffset()方法处理的，这个方法在AppBarLayout.Behavior中进行了重写。 我们直接看AppBarLayout.Behavior中的源码：@Override//newOffeset传入了dy，也就是我们手指移动距离上一次移动的距离，//minOffset等于AppBarLayout的负的height，maxOffset等于0。int setHeaderTopBottomOffset(CoordinatorLayout coordinatorLayout, AppBarLayout appBarLayout, int newOffset, int minOffset, int maxOffset) &#123; final int curOffset = getTopBottomOffsetForScrollingSibling();//获取当前的滑动Offset int consumed = 0; //AppBarLayout滑动的距离如果超出了minOffset或者maxOffset，则直接返回0 if (minOffset != 0 &amp;&amp; curOffset &gt;= minOffset &amp;&amp; curOffset &lt;= maxOffset) &#123; //矫正newOffset，使其minOffset&lt;=newOffset&lt;=maxOffset newOffset = MathUtils.clamp(newOffset, minOffset, maxOffset); //由于默认没设置Interpolator，所以interpolatedOffset=newOffset; if (curOffset != newOffset) &#123; final int interpolatedOffset = appBarLayout.hasChildWithInterpolator() ? interpolateOffset(appBarLayout, newOffset) : newOffset; //调用ViewOffsetBehvaior的方法setTopAndBottomOffset(...)，最终通过 //ViewCompat.offsetTopAndBottom()移动AppBarLayout final boolean offsetChanged = setTopAndBottomOffset(interpolatedOffset); //记录下消费了多少的dy。 consumed = curOffset - newOffset; //没设置Interpolator的情况， mOffsetDelta永远=0 mOffsetDelta = newOffset - interpolatedOffset; //.... //分发回调OnOffsetChangedListener.onOffsetChanged(...) appBarLayout.dispatchOffsetUpdates(getTopAndBottomOffset()); updateAppBarLayoutDrawableState(coordinatorLayout, appBarLayout, newOffset, newOffset &lt; curOffset ? -1 : 1, false); &#125; //... return consumed;&#125; 上面注释也解释的比较清楚了，通过setTopAndBottomOffset()来计算AppBarLayout滑动多少距离，达到移动AppBarLayout的目的，那么这里AppBarLayout就可以跟着手上下移动了.但是，RecyclerView是如何跟随滑动的呢？在上面的布局文件里，我们给RecyclerView指定了一个layout_behavior，前面也说了这个Behavior是通过反射获取的，点击去可以找到这个类，它是：android.support.design.widget.AppBarLayout$ScrollingViewBehavior 注意区分，这个类不是我们上面提到的AppBarLayout.Behavior，两者并不相同 AppBarLayout$ScrollingViewBehavior重写了下面两个方法，并通过这两个方法将AppBarLayout和Recyclerview关联了起来@Overridepublic boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) &#123; // We depend on any AppBarLayouts return dependency instanceof AppBarLayout;&#125;@Overridepublic boolean onDependentViewChanged(CoordinatorLayout parent, View child, View dependency) &#123; offsetChildAsNeeded(parent, child, dependency); return false;&#125; Recyclerview依赖于AppBarLayout，在AppBarLayout移动的过程中，Recyclerview会随着AppBarLayout的移动回调onDependentViewChanged()方法，进而调用 offsetChildAsNeeded(parent, child, dependency) private void offsetChildAsNeeded(CoordinatorLayout parent, View child, View dependency) &#123; final CoordinatorLayout.Behavior behavior = ((CoordinatorLayout.LayoutParams) dependency.getLayoutParams()).getBehavior(); if (behavior instanceof Behavior) &#123; // Offset the child, pinning it to the bottom the header-dependency, maintaining // any vertical gap and overlap final Behavior ablBehavior = (Behavior) behavior; ViewCompat.offsetTopAndBottom(child, (dependency.getBottom() - child.getTop()) + ablBehavior.mOffsetDelta + getVerticalLayoutGap() - getOverlapPixelsForOffset(dependency)); &#125;&#125; 这样我们就知道了当手指移动AppBarLayout时候的过程，下面整理一下： 首先通过Behavior.onTouchEvent(…)收到滑动距离，进而通知AppBarLayout.Behavior调用ViewCompat.offsetTopAndBottom()进行滑动；在AppBarLayout滑动的过程中，由于Recyclerview中的ScrollingViewBehavior会依赖于AppBarLayout，所以在AppBarLayout滑动时候，Recyclerview也会随着滑动，调用的方法也是ViewCompat.offsetTopAndBottom()。 当手指触摸Recyclerview时的滑动逻辑在Touch触发的时候，先走到CoordinatorLayout的onInterceptTouchEvent()方法，然后走到performIntercept()，调用Behavior的onInterceptTouchEvent()方法，最终Recyclerview绑定的ScrollingViewBehavior并没有重写onInterceptTouchEvent()，所以父viewCoordinatorLayout并不会拦截这个Touch事件，所以会在Recyclerview的onInterceptTouchEvent进行处理。@Override public boolean onInterceptTouchEvent(MotionEvent e) &#123; //... final int action = e.getActionMasked(); final int actionIndex = e.getActionIndex(); switch (action) &#123; case MotionEvent.ACTION_DOWN: if (mIgnoreMotionEventTillDown) &#123; mIgnoreMotionEventTillDown = false; &#125; mScrollPointerId = e.getPointerId(0); mInitialTouchX = mLastTouchX = (int) (e.getX() + 0.5f); mInitialTouchY = mLastTouchY = (int) (e.getY() + 0.5f); if (mScrollState == SCROLL_STATE_SETTLING) &#123; getParent().requestDisallowInterceptTouchEvent(true); setScrollState(SCROLL_STATE_DRAGGING); &#125; // Clear the nested offsets mNestedOffsets[0] = mNestedOffsets[1] = 0; int nestedScrollAxis = ViewCompat.SCROLL_AXIS_NONE; if (canScrollHorizontally) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_HORIZONTAL; &#125; if (canScrollVertically) &#123; nestedScrollAxis |= ViewCompat.SCROLL_AXIS_VERTICAL; &#125; // 在这里触发nestedscroll startNestedScroll(nestedScrollAxis, TYPE_TOUCH); break; //... &#125; return mScrollState == SCROLL_STATE_DRAGGING; &#125; Recyclerview实现了NestedScrollingChild2接口，但是具体实现都在NestedScrollingChildHelper类中public boolean startNestedScroll(@ScrollAxis int axes, @NestedScrollType int type) &#123; if (hasNestedScrollingParent(type)) &#123; // Already in progress return true; &#125; if (isNestedScrollingEnabled()) &#123; //是否支持嵌套滑动 ViewParent p = mView.getParent(); View child = mView; // mView就是当前的Recyclerview //从子View向外查询第一个接收滑动的父View，当前p就是CoordinatorLayout while (p != null) &#123; if (ViewParentCompat.onStartNestedScroll(p, child, mView, axes, type)) &#123; setNestedScrollingParentForType(type, p); //调用父view的onNestedScrollAccepted() ViewParentCompat.onNestedScrollAccepted(p, child, mView, axes, type); return true; &#125; if (p instanceof View) &#123; child = (View) p; &#125; p = p.getParent(); &#125; &#125; return false;&#125; 下面是ViewParentCompat.onStartNestedScroll()的处理代码：public static boolean onStartNestedScroll(ViewParent parent, View child, View target, int nestedScrollAxes, int type) &#123; if (parent instanceof NestedScrollingParent2) &#123; // First try the NestedScrollingParent2 API return ((NestedScrollingParent2) parent).onStartNestedScroll(child, target, nestedScrollAxes, type); &#125; else if (type == ViewCompat.TYPE_TOUCH) &#123; // Else if the type is the default (touch), try the NestedScrollingParent API return IMPL.onStartNestedScroll(parent, child, target, nestedScrollAxes); &#125; return false;&#125; CoordinatorLayout正好实现了NestedScrollingParent2接口，所以由CoordinatorLayout来处理onStartNestedScroll()方法@Overridepublic boolean onStartNestedScroll(View child, View target, int axes, int type) &#123; boolean handled = false; final int childCount = getChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; final View view = getChildAt(i); if (view.getVisibility() == View.GONE) &#123; // If it's GONE, don't dispatch continue; &#125; final LayoutParams lp = (LayoutParams) view.getLayoutParams(); final Behavior viewBehavior = lp.getBehavior(); // 由CoordinatorLayout转发给各个Behavior if (viewBehavior != null) &#123; final boolean accepted = viewBehavior.onStartNestedScroll(this, view, child, target, axes, type); handled |= accepted; lp.setNestedScrollAccepted(type, accepted); &#125; else &#123; lp.setNestedScrollAccepted(type, false); &#125; &#125; return handled;&#125; 上面代码可以看出，由CoordinatorLayout转发给各个Behavior，根据其返回值作进一步处理 下面是Behavior的onStartNestedScroll()方法的注释：/** * Called when a descendant of the CoordinatorLayout attempts to initiate a nested scroll. * * &lt;p&gt;Any Behavior associated with any direct child of the CoordinatorLayout may respond * to this event and return true to indicate that the CoordinatorLayout should act as * a nested scrolling parent for this scroll. Only Behaviors that return true from * this method will receive subsequent nested scroll events.&lt;/p&gt; //... * @see NestedScrollingParent2#onStartNestedScroll(View, View, int, int) */ 当CoordinatorLayout的子类想要启动一个nested scroll（嵌套滑动）时需要重写这个方法。CoordinatorLayout的子类可以响应这个事件，返回true表示CoordinatorLayout应该扮演一个嵌套滑动的父类。只有返回true的Behavior才会收到后续的嵌套滑动事件。 在这个例子中（AppBarLayout+ Recyclerview），只有AppBarLayout.Behavior重写了这个方法，并返回了true。但是这里并没有移动view的方法。 简单总结一下：Recyclerview作为子View滑动时候会首先调用startNestedScroll(…)方法来询问父View即CoordinatorLayout是否需要消费事件，CoordinatorLayout作为代理做发给对应Behavior，这里就分发给了AppBarLayout.Behavior，并返回true，说明AppBarLayout需要进行消费事件的处理.而ScrollingViewBehavior作为事件的触发者，并没有重写startNestedScroll()方法，所以返回false，表示不需要对事件进行消费。 前面分析了Recyclerview的onInterceptTouchEvent()的处理流程，父类并没有拦截Touch事件。所以，Touch事件肯定是在Recyclerview的 onTouchEvent()里进行了处理。最终，在Recyclerview的onTouchEvent对ACTION_MOVE的处理中看到了下面的代码：case MotionEvent.ACTION_MOVE: &#123; final int index = e.findPointerIndex(mScrollPointerId); if (index &lt; 0) &#123; Log.e(TAG, \"Error processing scroll; pointer index for id \" + mScrollPointerId + \" not found. Did any MotionEvents get skipped?\"); return false; &#125; final int x = (int) (e.getX(index) + 0.5f); final int y = (int) (e.getY(index) + 0.5f); int dx = mLastTouchX - x; int dy = mLastTouchY - y; // 1.这里向父view（CoordinatorLayout）分发了滑动处理 if (dispatchNestedPreScroll(dx, dy, mScrollConsumed, mScrollOffset, TYPE_TOUCH)) &#123; // 剪掉被AppBarLayout消耗的距离，剩下距离作为Recyclerview的滑动距离 dx -= mScrollConsumed[0]; dy -= mScrollConsumed[1]; vtev.offsetLocation(mScrollOffset[0], mScrollOffset[1]); // Updated the nested offsets mNestedOffsets[0] += mScrollOffset[0]; mNestedOffsets[1] += mScrollOffset[1]; &#125; //... if (mScrollState == SCROLL_STATE_DRAGGING) &#123; mLastTouchX = x - mScrollOffset[0]; mLastTouchY = y - mScrollOffset[1]; // 2.这里向父view（CoordinatorLayout）分发了滑动处理 if (scrollByInternal( canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, vtev)) &#123; getParent().requestDisallowInterceptTouchEvent(true); &#125; if (mGapWorker != null &amp;&amp; (dx != 0 || dy != 0)) &#123; mGapWorker.postFromTraversal(this, dx, dy); &#125; &#125;&#125; 进入上面注释2处：boolean scrollByInternal(int x, int y, MotionEvent ev) &#123; int unconsumedX = 0, unconsumedY = 0; int consumedX = 0, consumedY = 0; consumePendingUpdateOperations(); if (mAdapter != null) &#123; startInterceptRequestLayout(); onEnterLayoutOrScroll(); TraceCompat.beginSection(TRACE_SCROLL_TAG); fillRemainingScrollValues(mState); if (x != 0) &#123; consumedX = mLayout.scrollHorizontallyBy(x, mRecycler, mState); unconsumedX = x - consumedX; &#125; //... &#125; // dispatchNestedScroll也向CoordinatorLayout转发了处理 if (dispatchNestedScroll(consumedX, consumedY, unconsumedX, unconsumedY, mScrollOffset, TYPE_TOUCH)) &#123; // Update the last touch co-ords, taking any scroll offset into account mLastTouchX -= mScrollOffset[0]; mLastTouchY -= mScrollOffset[1]; if (ev != null) &#123; ev.offsetLocation(mScrollOffset[0], mScrollOffset[1]); &#125; mNestedOffsets[0] += mScrollOffset[0]; mNestedOffsets[1] += mScrollOffset[1]; &#125; else if (getOverScrollMode() != View.OVER_SCROLL_NEVER) &#123; if (ev != null &amp;&amp; !MotionEventCompat.isFromSource(ev, InputDevice.SOURCE_MOUSE)) &#123; pullGlows(ev.getX(), unconsumedX, ev.getY(), unconsumedY); &#125; considerReleasingGlowsOnScroll(x, y); &#125; if (consumedX != 0 || consumedY != 0) &#123; dispatchOnScrolled(consumedX, consumedY); &#125; if (!awakenScrollBars()) &#123; invalidate(); &#125; return consumedX != 0 || consumedY != 0;&#125; 从上面两段代码可以发现在Recyclerview的onTouch事件中，有两处将事件分发了出去，先简单说一下两个分发的流程顺序：1.dispatchNestedPreScroll流程是: Recyclerview.dispatchNestedPreScroll(…) -&gt; NestedScrollingChildHelper.dispatchNestedPreScroll(…)-&gt;ViewParentCompat.onNestedPreScroll()-&gt;NestedScrollingParent2.onNestedPreScroll()-&gt;CoordinatorLayout.onNestedPreScroll(…) 2.dispatchNestedScroll流程是: Recyclerview.dispatchNestedScroll(…) -&gt; NestedScrollingChildHelper.dispatchNestedScroll(…)-&gt;ViewParentCompat.onNestedScroll()-&gt;NestedScrollingParent2.onNestedScroll()-&gt;CoordinatorLayout.onNestedScroll(…) onNestedPreScroll和onNestedScroll区别关于这两者的区别，看一下谷歌给出的介绍： onNestedPreScroll is called each time the nested scroll is updated by the nested scrolling child, before the nested scrolling child has consumed the scroll distance itself. Each Behavior responding to the nested scroll will receive the same values. The CoordinatorLayout will report as consumed the maximum number of pixels in either direction that any Behavior responding to the nested scroll reported as consumed. 这里的the nested scrolling child指的是实现了NestedScrollingChild2或NestedScrollingChild接口的view。 onNestedPreScroll由the nested scrolling child发起，在the nested scrolling child消费滑动距离之前调用这个方法。任何响应嵌套滑动的Behavior消耗的像素数都是由CoordinatorLayout来转发。 onNestedScroll is called each time the nested scroll is updated by the nested scrolling child, with both consumed and unconsumed components of the scroll supplied in pixels. Each Behavior responding to the nested scroll will receive the same values. onNestedScroll也是由the nested scrolling child发起，并且每个响应嵌套滑动的Behavior都会收到相同的消耗和未消耗的像素数。 总结一下就是： onNestedPreScroll : 接收滑动控件处理滑动前的滑动距离信息，所有Behavior控件并且Behavior的isNestedScrollAccepted()返回true，都可以优先响应滑动操作。消耗部分或者全部滑动距离. onNestedScroll : 接收子控件处理完滑动后的滑动距离信息, 在这里外控件可以选择是否处理剩余的滑动距离. onNestedPreScroll流程分析下面先以onNestedPreScroll为例，分析滑动处理流程。在CoordinatorLayout的onNestedPreScroll()方法中@Overridepublic void onNestedPreScroll(View target, int dx, int dy, int[] consumed, int type) &#123; int xConsumed = 0; int yConsumed = 0; boolean accepted = false; final int childCount = getChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; final View view = getChildAt(i); if (view.getVisibility() == GONE) &#123; // If the child is GONE, skip... continue; &#125; final LayoutParams lp = (LayoutParams) view.getLayoutParams(); if (!lp.isNestedScrollAccepted(type)) &#123; // 没有接受事件，这里直接返回 continue; &#125; // 将事件转发给各个Behavior final Behavior viewBehavior = lp.getBehavior(); if (viewBehavior != null) &#123; mTempIntPair[0] = mTempIntPair[1] = 0; viewBehavior.onNestedPreScroll(this, view, target, dx, dy, mTempIntPair, type); xConsumed = dx &gt; 0 ? Math.max(xConsumed, mTempIntPair[0]) : Math.min(xConsumed, mTempIntPair[0]); yConsumed = dy &gt; 0 ? Math.max(yConsumed, mTempIntPair[1]) : Math.min(yConsumed, mTempIntPair[1]); accepted = true; &#125; &#125; consumed[0] = xConsumed; consumed[1] = yConsumed; if (accepted) &#123; onChildViewsChanged(EVENT_NESTED_SCROLL); &#125;&#125; 看到这里CoordinatorLayout遍历子view的Behavior，大家应该比较熟悉了。前面代码\bCoordinatorLayout的onStartNestedScroll()里有lp.setNestedScrollAccepted(type, accepted);这样一句话，由于Recyclerview的Behavior没有重写这个方法，所以accepted的值是false，导致这里lp.isNestedScrollAccepted(type)得到的值也是false，所以Recyclerview并不会执行onNestedPreScroll()方法。只有另一个子View(AppBarLayout) 会触发这个方法：AppBarLayout.Behavior的onNestedPreScroll()@Overridepublic void onNestedPreScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child, View target, int dx, int dy, int[] consumed, int type) &#123; if (dy != 0) &#123; int min, max; if (dy &lt; 0) &#123; // We're scrolling down min = -child.getTotalScrollRange(); max = min + child.getDownNestedPreScrollRange(); &#125; else &#123; // We're scrolling up min = -child.getUpNestedPreScrollRange(); max = 0; &#125; if (min != max) &#123; // AppBarLayout只支持垂直方向，这里只需要更新Y方向值就可以 consumed[1] = scroll(coordinatorLayout, child, dy, min, max); &#125; &#125;&#125; scroll()会调用setHeaderTopBottomOffset()方法，这个方法在前面介绍手指触摸AppBarLayout时已经贴过，这里就不贴了，需要注意的是AppBarLayout.Behavior对setHeaderTopBottomOffset()方法进行了重写。 consumed的值有两种情况： 当滑动的距离在minOffset和maxOffset区间之内，则consume!=0，也就说明需要AppBarLayout进行消费，这里对应着AppBarLayout还没移出我们的视线时候的消费情况。 当滑动的距离超出了minOffset或者maxOffset后，则consume==0，也就说明需要AppBarLayout不进行消费了，这里对应着AppBarLayout移出我们的视线时候的消费情况。 再看一下刚才CoordinatorLayout.onNestedPreScroll()方法中最后一句onChildViewsChanged(EVENT_NESTED_SCROLL); final void onChildViewsChanged(@DispatchChangeEvent final int type) &#123; //... for (int i = 0; i &lt; childCount; i++) &#123; //... // Get the current draw rect of the view getChildRect(child, true, drawRect); //... if (type != EVENT_VIEW_REMOVED) &#123; // Did it change? if not continue getLastChildRect(child, lastDrawRect); if (lastDrawRect.equals(drawRect)) &#123; //当前view的宽高没有发生变化 continue; &#125; recordLastChildRect(child, drawRect); &#125; // Update any behavior-dependent views for the change for (int j = i + 1; j &lt; childCount; j++) &#123; // j 从1开始，checkChild就是Recyclerview final View checkChild = mDependencySortedChildren.get(j); final LayoutParams checkLp = (LayoutParams) checkChild.getLayoutParams(); final Behavior b = checkLp.getBehavior(); // 这里b是AppBarLayout.ScrollingViewBehavior，layoutDependsOn()返回true if (b != null &amp;&amp; b.layoutDependsOn(this, checkChild, child)) &#123; if (type == EVENT_PRE_DRAW &amp;&amp; checkLp.getChangedAfterNestedScroll()) &#123; // If this is from a pre-draw and we have already been changed // from a nested scroll, skip the dispatch and reset the flag checkLp.resetChangedAfterNestedScroll(); continue; &#125; final boolean handled; switch (type) &#123; case EVENT_VIEW_REMOVED: // EVENT_VIEW_REMOVED means that we need to dispatch // onDependentViewRemoved() instead b.onDependentViewRemoved(this, checkChild, child); handled = true; break; default: // Otherwise we dispatch onDependentViewChanged() // 传进来的type = EVENT_NESTED_SCROLL handled = b.onDependentViewChanged(this, checkChild, child); break; &#125; if (type == EVENT_NESTED_SCROLL) &#123; // If this is from a nested scroll, set the flag so that we may skip // any resulting onPreDraw dispatch (if needed) checkLp.setChangedAfterNestedScroll(handled); &#125; &#125; &#125; &#125; &#125; 在AppBarLayout.ScrollingViewBehavior的onDependentViewChanged()方法中，会调用其offsetChildAsNeeded()方法private void offsetChildAsNeeded(CoordinatorLayout parent, View child, View dependency) &#123; final CoordinatorLayout.Behavior behavior = ((CoordinatorLayout.LayoutParams) dependency.getLayoutParams()).getBehavior(); if (behavior instanceof Behavior) &#123; // Offset the child, pinning it to the bottom the header-dependency, maintaining // any vertical gap and overlap final Behavior ablBehavior = (Behavior) behavior; ViewCompat.offsetTopAndBottom(child, (dependency.getBottom() - child.getTop()) + ablBehavior.mOffsetDelta + getVerticalLayoutGap() - getOverlapPixelsForOffset(dependency)); &#125;&#125; dependency这里就是AppBarLayout，child就是Recyclerview，而parent当然就是CoordinatorLayout了。这个方法就是根据AppBarLayout的位置，来调整Recyclerview的位置。如果注释掉这个代码，滑动过程中，Recyclerview左边距位置不会调整，会和AppBarLayout之间出现空白。 onNestedScroll流程分析与上面类似，来看CoordinatorLayout的onNestedScroll()方法：@Overridepublic void onNestedScroll(View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed, int type) &#123; final int childCount = getChildCount(); boolean accepted = false; for (int i = 0; i &lt; childCount; i++) &#123; final View view = getChildAt(i); if (view.getVisibility() == GONE) &#123; // If the child is GONE, skip... continue; &#125; //这里也是先判断是否接受嵌套滑动 final LayoutParams lp = (LayoutParams) view.getLayoutParams(); if (!lp.isNestedScrollAccepted(type)) &#123; continue; &#125; // 分发给每个Behavior final Behavior viewBehavior = lp.getBehavior(); if (viewBehavior != null) &#123; viewBehavior.onNestedScroll(this, view, target, dxConsumed, dyConsumed, dxUnconsumed, dyUnconsumed, type); accepted = true; &#125; &#125; if (accepted) &#123; onChildViewsChanged(EVENT_NESTED_SCROLL); &#125;&#125; 同样，在我们例子中，Recyclerview的isNestedScrollAccepted返回的是false，所以也不会处理onNestedScroll()逻辑。因为当前是拖动Recyclerview来移动AppBarLayout，所以Recyclerview没必要处理onNestedScroll()方法. 找到AppBarLayout#Behavior类的onNestedScroll()方法中：@Overridepublic void onNestedScroll(CoordinatorLayout coordinatorLayout, AppBarLayout child, View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed, int type) &#123; if (dyUnconsumed &lt; 0) &#123; // 小于0表示view要向下滑动 // If the scrolling view is scrolling down but not consuming, it's probably be at // the top of it's content scroll(coordinatorLayout, child, dyUnconsumed, -child.getDownNestedScrollRange(), 0); &#125;&#125; 可以看到这里AppBarLayout处理了垂直方向向下的滑动。 水平方向联动系统的AppBarLayout只支持垂直方向：@Overridepublic void setOrientation(int orientation) &#123; if (orientation != VERTICAL) &#123; throw new IllegalArgumentException(\"AppBarLayout is always vertical and does\" + \" not support horizontal orientation\"); &#125; super.setOrientation(orientation);&#125; 要实现水平方向的AppBarLayout，只需要按照上面的分析，重写对应的方法，具体代码放在了这里Github agehua/HorizontalCoordinatorDemo RefCoordinatorLayout三部曲学习之三：AppBarLayout联动源码学习 安卓自定义View进阶-多点触控详解 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/09/12/Horizontal-Coordinator/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"CoordinatorLayout","slug":"coordinatorlayout","permalink":"http://agehua.github.io/tags/coordinatorlayout/"}]},{"title":"LeakCanary源码分析及借鉴","slug":"LeakCanary_source_code","date":"2019-07-29T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2019/07/30/LeakCanary_source_code/","link":"","permalink":"http://agehua.github.io/2019/07/30/LeakCanary_source_code/","excerpt":"煤矿中的金丝雀LeakCanary是一个帮我们在Android或Java项目开发时检测内存泄漏的库。\n本文以LeakCanary-1.5.1版本为例，分析LeakCanary原理，以及借鉴其中的方法。","text":"煤矿中的金丝雀LeakCanary是一个帮我们在Android或Java项目开发时检测内存泄漏的库。 本文以LeakCanary-1.5.1版本为例，分析LeakCanary原理，以及借鉴其中的方法。关于它的图标有一个故事： 17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。 内存泄漏检测的基本原理给弱引用关联一个引用队列，当弱引用持有内容被gc回收后，该弱引用会被添加到关联的引用队列中。 试试下面的代码，注释掉user=null;和不注释掉，看看有什么不同public class RefTest &#123; public static void main(String[] args) &#123; //user为强引用 User user = new User(\"张三\", 18); //创建弱引用并关联引用队列 ReferenceQueue&lt;User&gt; queue = new ReferenceQueue&lt;&gt;(); WeakReference&lt;User&gt; weakReference = new WeakReference&lt;User&gt;(user,queue); //置空强引用，触发GC user=null; Runtime.getRuntime().gc(); try &#123; Thread.sleep(100); &#125; catch (InterruptedException e) &#123; e.printStackTrace(); &#125; //强制系统回收已经没有强引用的对象 System.runFinalization(); WeakReference pollRef=null; //弹出对列的引弱用 while ((pollRef = (WeakReference) queue.poll()) != null) &#123; System.out.println(\"pollRef的内存地址:\"+pollRef.toString()); System.out.println(\"pollRef等于weakReference？:\"+weakReference.equals(pollRef)); &#125; &#125;&#125; Java垃圾回收(GC) 在Java中垃圾判断方法是 可达性分析算法，这个算法的基本思路是通过一系列的”GC Root”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC Root没有任何引用链相连时，则证明此对象是不可用的。 GC Root的对象包括以下几种： 1、虚拟机栈中引用的对象。 2、方法区中类静态属性引用的对象。 3、方法区中常量引用的对象。 4、本地方法栈中JNI引用的对象。 就算一个对象，通过可达性分析算法分析后，发现其是『不可达』的，也并不是非回收不可的。一般情况下，要宣告一个对象死亡，至少要经过两次标记过程： 1、经过可达性分析后，一个对象并没有与GC Root关联的引用链，将会被第一次标记和筛选。筛选条件是此对象有没有必要执行finalize()方法。如果对象没有覆盖finalize()方法，或者已经执行过了。那就认为他可以回收了。如果有必要执行finalize()方法，那么将会把这个对象放置到F-Queue的队列中，等待执行。 2、虚拟机会建立一个低优先级的Finalizer线程执行F-Queue里面的对象的finalize()方法。如果对象在finalize()方法中可以『拯救』自己，那么将不会被回收，否则，他将被移入一个即将被回收的ReferenceQueue。 LeakCanary使用LeakCanary在Application初始化，代码如下: public class BaseApplication extends Application &#123; @Override public void onCreate() &#123; super.onCreate(); //检查当前进程是否在HeapAnalyzerService所属进程 if (LeakCanary.isInAnalyzerProcess(this)) &#123; return; &#125; //安装泄露检测 LeakCanary.install(this); &#125; &#125; 编译成功后，可以在debug状态下的AndroidManifest.xml文件中，看到LeakCanary注册的组件。&lt;!-- 这个是LeakCanary分析泄露的Service --&gt; &lt;service android:name=\"com.squareup.leakcanary.internal.HeapAnalyzerService\" android:enabled=\"false\" android:process=\":leakcanary\" /&gt; &lt;!-- 这个是LeakCanary展示泄露的Service --&gt; &lt;service android:name=\"com.squareup.leakcanary.DisplayLeakService\" android:enabled=\"false\"/&gt; &lt;activity android:name=\"com.squareup.leakcanary.internal.DisplayLeakActivity\" android:enabled=\"false\" android:icon=\"@mipmap/leak_canary_icon\" android:label=\"@string/leak_canary_display_activity_label\" android:taskAffinity=\"com.squareup.leakcanary.com.pengguanming.studydemo\" android:theme=\"@style/leak_canary_LeakCanary.Base\" &gt; &lt;intent-filter&gt; &lt;action android:name=\"android.intent.action.MAIN\" /&gt; &lt;category android:name=\"android.intent.category.LAUNCHER\" /&gt; &lt;/intent-filter&gt; &lt;/activity&gt; 其中DisplayLeakActivity被设置为Launcher，并设置了金丝雀的icon，这也就是为什么使用LeakCanary会在桌面上生成icon入口的原因。但是，这里要注意DisplayLeakActivity的enable属性被设置为false了，默认在桌面上是不会显示入口的。 监听Activity销毁的方法返回来看 LeakCanary.install(this)方法/** * Creates a &#123;@link RefWatcher&#125; that works out of the box, and starts watching activity * references (on ICS+). */public static RefWatcher install(Application application) &#123; return refWatcher(application).listenerServiceClass(DisplayLeakService.class) .excludedRefs(AndroidExcludedRefs.createAppDefaults().build()) .buildAndInstall();&#125;/** Builder to create a customized &#123;@link RefWatcher&#125; with appropriate Android defaults. */public static AndroidRefWatcherBuilder refWatcher(Context context) &#123; return new AndroidRefWatcherBuilder(context);&#125; install方法通过AndroidRefWatcherBuilder，构造了一个RefWatcher对象，再看buildAndInstall()方法：public RefWatcher buildAndInstall() &#123; RefWatcher refWatcher = build(); if (refWatcher != DISABLED) &#123; LeakCanary.enableDisplayLeakActivity(context); ActivityRefWatcher.install((Application) context, refWatcher); &#125; return refWatcher;&#125; ActivityRefWatcher.install()调用了watchActivities()方法。public static void install(Application application, RefWatcher refWatcher) &#123; new ActivityRefWatcher(application, refWatcher).watchActivities();&#125; watchActivities()通过传过来的application对象注册了一个registerActivityLifecycleCallbacks。public void watchActivities() &#123; // Make sure you don't get installed twice. stopWatchingActivities(); application.registerActivityLifecycleCallbacks(lifecycleCallbacks);&#125; 这个监听只监听了onActivityDestroyed()方法private final Application.ActivityLifecycleCallbacks lifecycleCallbacks = new ActivityLifecycleCallbacksAdapter() &#123; @Override public void onActivityDestroyed(Activity activity) &#123; refWatcher.watch(activity); &#125;&#125;; 上面就是LeakCanary注册监听Activity onDestroy()生命周期的过程 检测对象弱引用关联引用队列前面提到，弱引用关联一个引用队列，当弱引用保存的引用被释放掉后，弱引用就会进入到引用队列中，LeakCanary当然也是用这种方式，不过它更聪明。 进入到refWatcher.watch()方法中： public void watch(Object watchedReference, String referenceName) &#123; if (this == DISABLED) &#123; return; &#125; // 这里的 watchedReference 就是一个 Activity checkNotNull(watchedReference, \"watchedReference\"); checkNotNull(referenceName, \"referenceName\"); final long watchStartNanoTime = System.nanoTime(); String key = UUID.randomUUID().toString(); // 为每个 watchedReference 生成一个随机key，将key添加到retainedKeys中 retainedKeys.add(key); // 每次创建一个弱引用，并关联一个引用队列 final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue); ensureGoneAsync(watchStartNanoTime, reference);&#125; 上面的retainedKeys是一个支持并发访问的 CopyOnWriteArraySet 对象。这个 KeyedWeakReference 里的key值就是LeakCanary聪明的地方了final class KeyedWeakReference extends WeakReference&lt;Object&gt; &#123; public final String key; public final String name; KeyedWeakReference(Object referent, String key, String name, ReferenceQueue&lt;Object&gt; referenceQueue) &#123; super(checkNotNull(referent, \"referent\"), checkNotNull(referenceQueue, \"referenceQueue\")); // 比普通 WeakReference 多了两个参数，其中的 key 最为关键 this.key = checkNotNull(key, \"key\"); this.name = checkNotNull(name, \"name\"); &#125;&#125; 为什么要多保存一个key值呢？它在哪里用到了呢？继续往下看：private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) &#123; // 这里逻辑先不考虑，直接看 ensureGone() watchExecutor.execute(new Retryable() &#123; @Override public Retryable.Result run() &#123; return ensureGone(reference, watchStartNanoTime); &#125; &#125;);&#125; @SuppressWarnings(\"ReferenceEquality\") // Explicitly checking for named null.Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) &#123; // 计算watch方法到gc垃圾回收的时长 long gcStartNanoTime = System.nanoTime(); long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime); // 尝试移除已经到达引用队列的弱引用 removeWeaklyReachableReferences(); if (debuggerControl.isDebuggerAttached()) &#123; // The debugger can create false leaks. return RETRY; &#125; if (gone(reference)) &#123; return DONE; &#125; // 手动gc gcTrigger.runGc(); // gc后，再次移除引用队列中的弱引用 removeWeaklyReachableReferences(); if (!gone(reference)) &#123; // 弱引用没有被移除，说明内存泄漏了 long startDumpHeap = System.nanoTime(); long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime); // 确定泄漏后，生成prof文件 File heapDumpFile = heapDumper.dumpHeap(); if (heapDumpFile == RETRY_LATER) &#123; // Could not dump the heap. return RETRY; &#125; long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap); heapdumpListener.analyze( new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs, gcDurationMs, heapDumpDurationMs)); &#125; return DONE;&#125;private boolean gone(KeyedWeakReference reference) &#123; return !retainedKeys.contains(reference.key);&#125;private void removeWeaklyReachableReferences() &#123; // WeakReferences are enqueued as soon as the object to which they point to becomes weakly // reachable. This is before finalization or garbage collection has actually happened. KeyedWeakReference ref; while ((ref = (KeyedWeakReference) queue.poll()) != null) &#123; retainedKeys.remove(ref.key); &#125;&#125; 在removeWeaklyReachableReferences()方法中，将queue队列里所有弱引用弹栈。如果出栈了，就移除掉retainedKeys中保存的key。 在gone()方法判断，如果retainedKeys依然包含reference的key，说明该reference没有进入queue队列，也就是没有释放掉对象的引用，所以很可能是发生了内存泄漏。 所以KeyedWeakReference中保存的key值，就是为了方便判断当前的弱引用是否发生了内存泄漏。 LeakCanary的线程调度刚才再看刚才忽略的 watchExecutor.execute()方法，watchExecutor是一个接口，它的实现类是AndroidWatchExecutor。public final class AndroidWatchExecutor implements WatchExecutor &#123; static final String LEAK_CANARY_THREAD_NAME = \"LeakCanary-Heap-Dump\"; private final Handler mainHandler; private final Handler backgroundHandler; private final long initialDelayMillis; private final long maxBackoffFactor; public AndroidWatchExecutor(long initialDelayMillis) &#123; mainHandler = new Handler(Looper.getMainLooper()); HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME); handlerThread.start(); backgroundHandler = new Handler(handlerThread.getLooper()); this.initialDelayMillis = initialDelayMillis; maxBackoffFactor = Long.MAX_VALUE / initialDelayMillis; &#125; @Override public void execute(Retryable retryable) &#123; // 最终都会切换到主线程，调用waitForIdle()方法 if (Looper.getMainLooper().getThread() == Thread.currentThread()) &#123; waitForIdle(retryable, 0); &#125; else &#123; postWaitForIdle(retryable, 0); &#125; &#125; void postWaitForIdle(final Retryable retryable, final int failedAttempts) &#123; // 切换到主线程 mainHandler.post(new Runnable() &#123; @Override public void run() &#123; waitForIdle(retryable, failedAttempts); &#125; &#125;); &#125; void waitForIdle(final Retryable retryable, final int failedAttempts) &#123; // This needs to be called from the main thread. // 在主线程执行下面代码 Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() &#123; @Override public boolean queueIdle() &#123; postToBackgroundWithDelay(retryable, failedAttempts); // 方法如果返回 false，这个 IdleHandler 只会执行一次 return false; &#125; &#125;); &#125; void postToBackgroundWithDelay(final Retryable retryable, final int failedAttempts) &#123; // 设置延迟发送时间 long exponentialBackoffFactor = (long) Math.min(Math.pow(2, failedAttempts), maxBackoffFactor); long delayMillis = initialDelayMillis * exponentialBackoffFactor; // 子线程运行一个runnable backgroundHandler.postDelayed(new Runnable() &#123; @Override public void run() &#123; Retryable.Result result = retryable.run(); if (result == RETRY) &#123; postWaitForIdle(retryable, failedAttempts + 1); &#125; &#125; &#125;, delayMillis); &#125;&#125; AndroidWatchExecutor类中，有两个handler，一个在main thread，一个在HandlerThread的子线程中。外部调用execute()方法，最终都会在主线程调用waitForIdle()方法。 waitForIdle()运行在主线程，会在主线程添加一个IdleHandler。 IdleHandler的妙用 IdleHandler，这是一种在只有当消息队列没有消息时或者是队列中的消息还没有到执行时间时才会执行的 IdleHandler，它存放在 mPendingIdleHandlers 队列中。 关于IdleHandler如何使用，这篇文章提供了一个非常好的方法：你知道android的MessageQueue.IdleHandler吗？ 简单总结下这篇文章： 1.使用HandlerThread，利用HandlerThread绑定的子线程Handler，实现单线程队列处理数据+异步线程接收数据更新 2.反射HandlerThread，得到MessageQueue对象，调用MessageQueue.addIdleHandler() 3.在IdleHandler的queueIdle()回调方法里通知数据改变 这样做有两个好处： 1.HanlderThread按加入顺序操作数据，不需要对数据加锁 2.对HandlerThread的MessageQueue调用addIdleHandler()，不管操作了多少遍数据，只会在所有操作完成后（idle），通知数据的监听者，避免频繁更新UI AndroidWatchExecutor的作用就是，在主线程空闲的时候才会调用，并且是延迟调用子线程的retryable.run()方法。这样可以保证不影响主线程的流畅度。 手动触发GC上面的retryable.run()运行在子线程，说明ensureGone()就是在子线程。在看一下LeakCanary是如何调用GC的：public interface GcTrigger &#123; GcTrigger DEFAULT = new GcTrigger() &#123; @Override public void runGc() &#123; // Code taken from AOSP FinalizationTest: // https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/ // java/lang/ref/FinalizationTester.java // System.gc() does not garbage collect every time. Runtime.gc() is // more likely to perfom a gc. Runtime.getRuntime().gc(); enqueueReferences(); System.runFinalization(); &#125; private void enqueueReferences() &#123; // Hack. We don't have a programmatic way to wait for the reference queue daemon to move // references to the appropriate queues. try &#123; Thread.sleep(100); &#125; catch (InterruptedException e) &#123; throw new AssertionError(); &#125; &#125; &#125;; void runGc();&#125; gcTrigger.runGc() 先会调用 Runtime.getRuntime().gc() 以触发系统gc操作，然后当前后台子线程sleep 100毫秒，最后调用System.runFinalization()强制系统回收没有引用的队列，这样确保引用对象是否真的被回收了。 泄露信息分析上面 heapDumper.dumpHeap() 方法的具体实现是在AndroidHeapDumper类中：@SuppressWarnings(\"ReferenceEquality\") // Explicitly checking for named null.@Override public File dumpHeap() &#123; // 创建一个XXX_pending.hprof文件，这种文件最多7个 // 文件存储路径为 /storage/emulated/0/Download/leakcanary-xxx(package-name)/ File heapDumpFile = leakDirectoryProvider.newHeapDumpFile(); if (heapDumpFile == RETRY_LATER) &#123; // 文件创建失败 return RETRY_LATER; &#125; FutureResult&lt;Toast&gt; waitingForToast = new FutureResult&lt;&gt;(); showToast(waitingForToast); if (!waitingForToast.wait(5, SECONDS)) &#123; CanaryLog.d(\"Did not dump heap, too much time waiting for Toast.\"); return RETRY_LATER; &#125; Toast toast = waitingForToast.get(); try &#123; // 向文件写入内容 Debug.dumpHprofData(heapDumpFile.getAbsolutePath()); cancelToast(toast); return heapDumpFile; &#125; catch (Exception e) &#123; CanaryLog.d(e, \"Could not dump heap\"); // Abort heap dump return RETRY_LATER; &#125; &#125;private void showToast(final FutureResult&lt;Toast&gt; waitingForToast) &#123; mainHandler.post(new Runnable() &#123; @Override public void run() &#123; final Toast toast = new Toast(context); toast.setGravity(Gravity.CENTER_VERTICAL, 0, 0); toast.setDuration(Toast.LENGTH_LONG); LayoutInflater inflater = LayoutInflater.from(context); toast.setView(inflater.inflate(R.layout.leak_canary_heap_dump_toast, null)); toast.show(); // Waiting for Idle to make sure Toast gets rendered. Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() &#123; @Override public boolean queueIdle() &#123; waitingForToast.set(toast); return false; &#125; &#125;); &#125; &#125;); &#125;private void cancelToast(final Toast toast) &#123; mainHandler.post(new Runnable() &#123; @Override public void run() &#123; toast.cancel(); &#125; &#125;); &#125; 这里的FutureResult，会阻塞当前后台子线程，并监听主线程是否空闲，若5秒内不空闲，则返回RETRY_LATER。若主线程空闲则会调用waitingForToast.set(toast)，不在阻塞后台子线程，调用android.os.Debug.dumpHprofData()生成.prof文件。 Debug.dumpHprofData 会导致线程阻塞。因为dumpheap的操作是在应用进程的主线程中进行操作，本质上是在该应用进程的虚拟机中进行，dumpheap时应用进程会block住，如过heap文件过大很容易导致应用进程操作界面卡住，如果此时再进行点击或滑动等操作极易再抛出anr等弹窗，用户体验极差。 这里介绍下 FutureResult 的实现：public final class FutureResult&lt;T&gt; &#123; // AtomicReference实现对象引用的原子更新 private final AtomicReference&lt;T&gt; resultHolder; // 同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待 private final CountDownLatch latch; public FutureResult() &#123; resultHolder = new AtomicReference&lt;&gt;(); latch = new CountDownLatch(1); &#125; public boolean wait(long timeout, TimeUnit unit) &#123; try &#123; return latch.await(timeout, unit); &#125; catch (InterruptedException e) &#123; throw new RuntimeException(\"Did not expect thread to be interrupted\", e); &#125; &#125; public T get() &#123; if (latch.getCount() &gt; 0) &#123; throw new IllegalStateException(\"Call wait() and check its result\"); &#125; return resultHolder.get(); &#125; public void set(T result) &#123; resultHolder.set(result); latch.countDown(); &#125;&#125; 关于CountDownLatch的介绍参考：Java并发学习之CountDownLatch实现原理及使用姿势 prof文件分析关于prof文件的分析，还要回到RefWatch.ensureGone()方法中：heapdumpListener.analyze( new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs, gcDurationMs, heapDumpDurationMs)); 最终会调用到HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);// 在HeapAnalyzerService 中public static void runAnalysis(Context context, HeapDump heapDump, Class&lt;? extends AbstractAnalysisResultService&gt; listenerServiceClass) &#123; Intent intent = new Intent(context, HeapAnalyzerService.class); intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName()); intent.putExtra(HEAPDUMP_EXTRA, heapDump); context.startService(intent);&#125; HeapAnalyzerService继承自IntentService。在前面的AndroidManifest中可以看到，HeapAnalyzerService是运行在单独的进程中。 在HeapAnalyzerService的onHandleIntent方法中接收和处理传递过来的dump文件。@Override protected void onHandleIntent(Intent intent) &#123; if (intent == null) &#123; CanaryLog.d(\"HeapAnalyzerService received a null intent, ignoring.\"); return; &#125; String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA); HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA); HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs); AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey); // 调用另一个AbstractAnalysisResultService的静态方法，将结果返回 AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);&#125; 再看下在heapAnalyzer.checkForLeak()方法：public AnalysisResult checkForLeak(File heapDumpFile, String referenceKey) &#123; long analysisStartNanoTime = System.nanoTime(); if (!heapDumpFile.exists()) &#123; Exception exception = new IllegalArgumentException(\"File does not exist: \" + heapDumpFile); return failure(exception, since(analysisStartNanoTime)); &#125; try &#123; // 使用HAHA库 HprofBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile); HprofParser parser = new HprofParser(buffer); Snapshot snapshot = parser.parse(); // 这里使用了THashMap，去掉重复路径 deduplicateGcRoots(snapshot); // 根据引用key找到泄漏对象 Instance leakingRef = findLeakingReference(referenceKey, snapshot); // False alarm, weak reference was cleared in between key check and heap dump. if (leakingRef == null) &#123; return noLeak(since(analysisStartNanoTime)); &#125; // 返回一个AnalysisResult对象 return findLeakTrace(analysisStartNanoTime, snapshot, leakingRef); &#125; catch (Throwable e) &#123; return failure(e, since(analysisStartNanoTime)); &#125;&#125; 在heapAnalyzer.checkForLeak()方法中引入HAHA库(一个heap prof堆文件分析库)，将hprof文件解析成内存快照Snapshot对象进行分析。还使用jetBrains的THashMap(THashMap的内存占用量比HashMap小)做中转，去掉snapshot中GCRoot的重复路径，以减少内存压力。 返回分析结果在HeapAnalyzerService的onHandleIntent方法中，调用了AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);// 在AbstractAnalysisResultService 中public static void sendResultToListener(Context context, String listenerServiceClassName, HeapDump heapDump, AnalysisResult result) &#123; Class&lt;?&gt; listenerServiceClass; try &#123; listenerServiceClass = Class.forName(listenerServiceClassName); &#125; catch (ClassNotFoundException e) &#123; throw new RuntimeException(e); &#125; Intent intent = new Intent(context, listenerServiceClass); intent.putExtra(HEAP_DUMP_EXTRA, heapDump); intent.putExtra(RESULT_EXTRA, result); context.startService(intent);&#125; 启动DisplayLeakService，并将结果返回。DisplayLeakService运行在主线程，继承自AbstractAnalysisResultService，也是一个IntentService。在AbstractAnalysisResultService的onHandleIntent()接收结果，并回调onHeapAnalyzed()方法，创建并显示一个通知。 具体的结果分析和处理，可以看这篇文章：LeakCanary源码分析第三讲－HeapAnalyzerService详解 内存泄漏信息保存和分析的大概流程是： 通过Debug.dumpHprofData()，生成一个xxx_pending.hprof文件 使用HAHA库（github.com/square/haha），将hprof文件解析成内存快照Snapshot对象进行分析 使用jetBrains的THashMap做中转，去掉snapshot中GCRoot的重复路径，以减少内存压力。 找出泄露对象并找出泄露对象的最短路径 得到结果后，重命名xxx_pending.hprof 文件为yyyy-MM-dd_HH-mm-ss_SSS.hprof 将hprof文件内容和分析结果都保存到yyyy-MM-dd_HH-mm-ss_SSS.hprof.result文件中 以上就是整个LeakCanary捕获内存泄漏，并展示出来的整体流程。 学习借鉴 使用FutureResult同步主线程和子线程 使用CopyOnWriteArraySet解决并发读写问题 构建者模式，代码简洁、清新，链式调用创建对象，参考RefWatcherBuilder对象 MessageQueue.addIdleHandler(IdleHandler handler)，监听线程空闲 手动GC，参考GCTrigger.runGc()。 IntentService跨进程 Refhttps://www.jianshu.com/p/49239eac7a76 https://juejin.im/post/5d09fb7e5188252af2012e73 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/07/30/LeakCanary_source_code/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"LeakCanary","slug":"leakcanary","permalink":"http://agehua.github.io/tags/leakcanary/"},{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"RecyclerView预加载机制源码分析","slug":"RecyclerView-pre-initiate","date":"2019-07-16T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2019/07/17/RecyclerView-pre-initiate/","link":"","permalink":"http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/","excerpt":"RecyclerView四级缓存再次总结一下 RecyclerView 的四级缓存\n\nScrap\nCache\nViewCacheExtension\nRecycledViewPool","text":"RecyclerView四级缓存再次总结一下 RecyclerView 的四级缓存 Scrap Cache ViewCacheExtension RecycledViewPool Scrap: 对应ListView 的Active View，就是屏幕内的缓存数据，就是相当于换了个名字，可以直接拿来复用。 Cache: 刚刚移出屏幕的缓存数据，默认大小是2个，当其容量被充满同时又有新的数据添加的时候，会根据FIFO原则，把优先进入的缓存数据移出并放到下一级缓存中，然后再把新的数据添加进来。Cache里面的数据是干净的，也就是携带了原来的ViewHolder的所有数据信息，数据可以直接来拿来复用。需要注意的是，cache是根据position来寻找数据的，这个postion是根据第一个或者最后一个可见的item的position以及用户操作行为（上拉还是下拉）。举个栗子：当前屏幕内第一个可见的item的position是1，用户进行了一个下拉操作，那么当前预测的position就相当于（1-1=0），也就是position=0的那个item要被拉回到屏幕，此时RecyclerView就从Cache里面找position=0的数据，如果找到了就直接拿来复用。 ViewCacheExtension: 是google留给开发者自己来自定义缓存的，这个ViewCacheExtension我个人建议还是要慎用，因为我扒拉扒拉网上其他的博客，没有找到对应的使用场景，而且这个类的api设计的也有些奇怪，只有一个public abstract View getViewForPositionAndType(@NonNull Recycler recycler, int position, int type);让开发者重写通过position和type拿到ViewHolder的方法，却没有提供如何产生ViewHolder或者管理ViewHolder的方法，给人一种只出不进的赶脚，还是那句话慎用。 RecycledViewPool: 刚才说了Cache默认的缓存数量是2个，当Cache缓存满了以后会根据FIFO（先进先出）的规则把Cache先缓存进去的ViewHolder移出并缓存到RecycledViewPool中，RecycledViewPool默认的缓存数量是5个。RecycledViewPool与Cache相比不同的是，从Cache里面移出的ViewHolder再存入RecycledViewPool之前ViewHolder的数据会被全部重置，相当于一个新的ViewHolder，而且Cache是根据position来获取ViewHolder，而RecycledViewPool是根据itemType获取的，如果没有重写getItemType()方法，itemType就是默认的。因为RecycledViewPool缓存的ViewHolder是全新的，所以取出来的时候需要走onBindViewHolder()方法。 ref让你彻底掌握RecyclerView的缓存机制 Prefetch功能的使用google官方在 Support Library v25 版本中，为RecyclerView增加了Prefetch。 并且在 v25.1.0 以及25.3.0版本中进行了完善。在最新的稳定版本25.3.1中已经基本稳定。Prefetch 默认就是处理开启的状态，通过LinearLayoutManager的setItemPrefetchEnabled()我们可以手动控制该功能的开启关闭。 我们都知道android是通过每16ms刷新一次页面来保证ui的流畅程度，现在android系统中刷新ui会通过cpu产生数据，然后交给gpu渲染的形式来完成，从上图可以看出当cpu完成数据处理交给gpu后就一直处于空闲状态，需要等待下一帧才会进行数据处理，而这空闲时间就被白白浪费了，如何才能压榨cpu的性能，让它一直处于忙碌状态，这就是rv的预取功能(Prefetch)要做的事情，rv会预取接下来可能要显示的item，在下一帧到来之前提前处理完数据，然后将得到的itemholder缓存起来，等到真正要使用的时候直接从缓存取出来即可。 预取代码理解虽说预取是默认开启不需要我们开发者操心的事情，但是明白原理还是能加深该功能的理解。下面就说下自己在看预取源码时的一点理解。实现预取功能的一个关键类就是gapworker，可以直接在rv源码中找到该类GapWorker mGapWorker; rv通过在ontouchevent中触发预取的判断逻辑，在手指执行move操作的代码末尾有这么段代码case MotionEvent.ACTION_MOVE: &#123; ...... if (mGapWorker != null &amp;&amp; (dx != 0 || dy != 0)) &#123; mGapWorker.postFromTraversal(this, dx, dy); &#125; &#125; &#125; break; 通过每次move操作来判断是否预取下一个可能要显示的item数据，判断的依据就是通过传入的dx和dy得到手指接下来可能要移动的方向，如果dx或者dy的偏移量会导致下一个item要被显示出来则预取出来，但是并不是说预取下一个可能要显示的item一定都是成功的，其实每次rv取出要显示的一个item本质上就是取出一个viewholder，根据viewholder上关联的itemview来展示这个item。而取出viewholder最核心的方法就是tryGetViewHolderForPositionByDeadline(int position,boolean dryRun, long deadlineNs) 名字是不是有点长，在rv源码中你会时不时见到这种巨长的方法名，看方法的参数也能找到和预取有关的信息,deadlineNs的一般取值有两种，一种是为了兼容版本25之前没有预取机制的情况，兼容25之前的参数为static final long FOREVER_NS = Long.MAX_VALUE; ，另一种就是实际的deadline数值，超过这个deadline则表示预取失败，这个其实也好理解，预取机制的主要目的就是提高rv整体滑动的流畅性，如果要预取的viewholder会造成下一帧显示卡顿强行预取的话那就有点本末倒置了。关于预取成功的条件通过调用boolean willCreateInTime(int viewType, long approxCurrentNs, long deadlineNs) &#123; long expectedDurationNs = getScrapDataForType(viewType).mCreateRunningAverageNs; return expectedDurationNs == 0 || (approxCurrentNs + expectedDurationNs &lt; deadlineNs);&#125; 来进行判断，approxCurrentNs的值为long start = getNanoTime();if (deadlineNs != FOREVER_NS &amp;&amp; !mRecyclerPool.willCreateInTime(type, start, deadlineNs)) &#123; // abort - we have a deadline we can't meet return null;&#125; 而mCreateRunningAverageNs就是创建同type的holder的平均时间，感兴趣的可以去看下这个值如何得到，不难理解就不贴代码了。关于预取就说到这里，感兴趣的可以自己去看下其余代码的实现方式，可以说google对于rv还是相当重视的，煞费苦心提高rv的各种性能，据说最近推出的viewpager2控件就是通过rv来实现的，大有rv控件一统天下的感觉。 预取功能的应用预取功能是默认开启的，在对应的RecyclerView.LayoutManager中提供了一个setInitialPrefetchItemCount(int itemCount)来设置预取个数。有一种场景，比如你在垂直列表里面有一个水平滚动列表的时候，竖屏每一行都是展示三个半item，可以调用内部（横向）Recyclerview的 innerLLM.setInitialItemsPrefetchCount(4)，这样当水平列表将要展示在屏幕上的时候，如果UI线程有空闲时间，RecyclerView会尝试在内部预先把这几个item取出来。 RefRecyclerView预加载机制源码分析 :https://blog.csdn.net/weishenhong/article/details/81150172 https://www.jianshu.com/p/1d2213f303fc 延伸阅读Recyclerview缓存RecyclerView 源码分析(三) - RecyclerView的缓存机制【进阶】RecyclerView源码解析(三)——深度解析缓存机制 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"RecyclerView 源码分析","slug":"RecyclerView-source-code","date":"2019-05-30T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/05/31/RecyclerView-source-code/","link":"","permalink":"http://agehua.github.io/2019/05/31/RecyclerView-source-code/","excerpt":"\n本文承接上文《RecyclerView 中的设计模式》，结合源码分析Recyclerview绘制、滑动、和缓存等逻辑\n","text":"本文承接上文《RecyclerView 中的设计模式》，结合源码分析Recyclerview绘制、滑动、和缓存等逻辑 RecyclerView的代码设计结构，如下面两张图： RecyclerViewDataObserver 数据观察器 Recycler View循环复用系统，核心部件 SavedState RecyclerView状态 AdapterHelper 适配器更新 ChildHelper 管理子View ViewInfoStore 存储子VIEW的动画信息 Adapter 数据适配器 LayoutManager 负责子VIEW的布局，核心部件 ItemAnimator Item动画 ViewFlinger 快速滑动管理 NestedScrollingChildHelper 管理子VIEW嵌套滑动 绘制详情可见RecyclerView涉及的类相当多，所以看代码的时候很容易迷失。因此我们需要抽丝剥茧，按照主线来进行分析。一般我们使用的时候是这样的 recyclerView = (RecyclerView) findViewById(R.id.recyclerView); LinearLayoutManager layoutManager = new LinearLayoutManager(this); //设置布局管理器 recyclerView.setLayoutManager(layoutManager); //设置为垂直布局，这也是默认的 layoutManager.setOrientation(OrientationHelper. VERTICAL); //设置Adapter recyclerView.setAdapter( recycleAdapter); //设置分隔线 recyclerView.addItemDecoration( new DividerGridItemDecoration(this )); //设置增加或删除条目的动画 recyclerView.setItemAnimator( new DefaultItemAnimator()); 首先recyclerView = (RecyclerView) findViewById(R.id.recyclerView);会执行其构造方法,我们看一下干了些什么事: public RecyclerView(Context context, @Nullable AttributeSet attrs, int defStyle) &#123; super(context, attrs, defStyle); setScrollContainer(true); setFocusableInTouchMode(true); final int version = Build.VERSION.SDK_INT; mPostUpdatesOnAnimation = version &gt;= 16; final ViewConfiguration vc = ViewConfiguration.get(context); mTouchSlop = vc.getScaledTouchSlop(); mMinFlingVelocity = vc.getScaledMinimumFlingVelocity(); mMaxFlingVelocity = vc.getScaledMaximumFlingVelocity(); setWillNotDraw(ViewCompat.getOverScrollMode(this) == ViewCompat.OVER_SCROLL_NEVER); mItemAnimator.setListener(mItemAnimatorListener); initAdapterManager(); initChildrenHelper(); // If not explicitly specified this view is important for accessibility. if (ViewCompat.getImportantForAccessibility(this) == ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_AUTO) &#123; ViewCompat.setImportantForAccessibility(this, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_YES); &#125; mAccessibilityManager = (AccessibilityManager) getContext() .getSystemService(Context.ACCESSIBILITY_SERVICE); setAccessibilityDelegateCompat(new RecyclerViewAccessibilityDelegate(this)); // Create the layoutManager if specified. boolean nestedScrollingEnabled = true; if (attrs != null) &#123; int defStyleRes = 0; //获取布局属性值 TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.RecyclerView, defStyle, defStyleRes); String layoutManagerName = a.getString(R.styleable.RecyclerView_layoutManager); a.recycle(); createLayoutManager(context, layoutManagerName, attrs, defStyle, defStyleRes); if (Build.VERSION.SDK_INT &gt;= 21) &#123; a = context.obtainStyledAttributes(attrs, NESTED_SCROLLING_ATTRS, defStyle, defStyleRes); nestedScrollingEnabled = a.getBoolean(0, true); a.recycle(); &#125; &#125; // Re-set whether nested scrolling is enabled so that it is set on all API levels setNestedScrollingEnabled(nestedScrollingEnabled);&#125; 代码进行了一系列的初始化工作,关键是createLayoutManager,创建了一个布局管理器 private void createLayoutManager(Context context, String className, AttributeSet attrs, int defStyleAttr, int defStyleRes) &#123; //如果布局属性存在 if (className != null) &#123; className = className.trim(); if (className.length() != 0) &#123; // Can't use isEmpty since it was added in API 9. className = getFullClassName(context, className); try &#123; ClassLoader classLoader; if (isInEditMode()) &#123; // Stupid layoutlib cannot handle simple class loaders. classLoader = this.getClass().getClassLoader(); &#125; else &#123; classLoader = context.getClassLoader(); &#125; //根据布局属性值设置的layoutManager通过反射实例化layoutManager Class layoutManagerClass = classLoader.loadClass(className).asSubclass(LayoutManager.class); Constructor constructor; Object[] constructorArgs = null; try &#123; constructor = layoutManagerClass .getConstructor(LAYOUT_MANAGER_CONSTRUCTOR_SIGNATURE); constructorArgs = new Object[]&#123;context, attrs, defStyleAttr, defStyleRes&#125;; &#125; catch (NoSuchMethodException e) &#123; try &#123; constructor = layoutManagerClass.getConstructor(); &#125; catch (NoSuchMethodException e1) &#123; e1.initCause(e); throw new IllegalStateException(attrs.getPositionDescription() + \": Error creating LayoutManager \" + className, e1); &#125; &#125; constructor.setAccessible(true); setLayoutManager(constructor.newInstance(constructorArgs)); &#125; catch (ClassNotFoundException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Unable to find LayoutManager \" + className, e); &#125; catch (InvocationTargetException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Could not instantiate the LayoutManager: \" + className, e); &#125; catch (InstantiationException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Could not instantiate the LayoutManager: \" + className, e); &#125; catch (IllegalAccessException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Cannot access non-public constructor \" + className, e); &#125; catch (ClassCastException e) &#123; throw new IllegalStateException(attrs.getPositionDescription() + \": Class is not a LayoutManager \" + className, e); &#125; &#125; &#125;&#125; 如果在布局文件里面设置了布局管理器的类型，那么这里会通过反射的方式实例化出对应的布局管理器。最后将实例化出的布局管理器设置到当前的RecyclerView,参考文章在创建实例时候public void setLayoutManager(LayoutManager layout) &#123; if (layout == mLayout) &#123; return; &#125; stopScroll(); // TODO We should do this switch a dispachLayout pass and animate children. There is a good // chance that LayoutManagers will re-use views. if (mLayout != null) &#123; if (mIsAttached) &#123; mLayout.dispatchDetachedFromWindow(this, mRecycler); &#125; mLayout.setRecyclerView(null); &#125; mRecycler.clear(); mChildHelper.removeAllViewsUnfiltered(); mLayout = layout; if (layout != null) &#123; if (layout.mRecyclerView != null) &#123; throw new IllegalArgumentException(\"LayoutManager \" + layout + \" is already attached to a RecyclerView: \" + layout.mRecyclerView); &#125; mLayout.setRecyclerView(this); if (mIsAttached) &#123; mLayout.dispatchAttachedToWindow(this); &#125; &#125; requestLayout();&#125; 设置布局管理器之前会先清空所有之前的缓存VIEW。最后通知VIEW刷新,requestLayout可见要绘制了public void requestLayout() &#123; if (mMeasureCache != null) mMeasureCache.clear(); if (mAttachInfo != null &amp;&amp; mAttachInfo.mViewRequestingLayout == null) &#123; // Only trigger request-during-layout logic if this is the view requesting it, // not the views in its parent hierarchy ViewRootImpl viewRoot = getViewRootImpl(); if (viewRoot != null &amp;&amp; viewRoot.isInLayout()) &#123; if (!viewRoot.requestLayoutDuringLayout(this)) &#123; return; &#125; &#125; mAttachInfo.mViewRequestingLayout = this; &#125; //为当前view设置标记位 PFLAG_FORCE_LAYOUT mPrivateFlags |= PFLAG_FORCE_LAYOUT; mPrivateFlags |= PFLAG_INVALIDATED; if (mParent != null &amp;&amp; !mParent.isLayoutRequested()) &#123; //向父容器请求布局 mParent.requestLayout(); &#125; if (mAttachInfo != null &amp;&amp; mAttachInfo.mViewRequestingLayout == this) &#123; mAttachInfo.mViewRequestingLayout = null; &#125;&#125; 在requestLayout方法中，首先先判断当前View树是否正在布局流程，接着为当前子View设置标记位，该标记位的作用就是标记了当前的View是需要进行重新布局的，接着调用mParent.requestLayout方法，这个十分重要，因为这里是向父容器请求布局，即调用父容器的requestLayout方法，为父容器添加PFLAG_FORCE_LAYOUT标记位，而父容器又会调用它的父容器的requestLayout方法，即requestLayout事件层层向上传递，直到DecorView，即根View，而根View又会传递给ViewRootImpl，也即是说子View的requestLayout事件，最终会被ViewRootImpl接收并得到处理。纵观这个向上传递的流程，其实是采用了责任链模式，即不断向上传递该事件，直到找到能处理该事件的上级，在这里，只有ViewRootImpl能够处理requestLayout事件。 @Overridepublic void requestLayout() &#123; if (!mHandlingLayoutInLayoutRequest) &#123; checkThread(); mLayoutRequested = true; scheduleTraversals(); &#125;&#125;void scheduleTraversals() &#123; if (!mTraversalScheduled) &#123; mTraversalScheduled = true; mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); if (!mUnbufferedInputDispatch) &#123; scheduleConsumeBatchedInput(); &#125; notifyRendererOfFramePending(); pokeDrawLockIfNeeded(); &#125;&#125;final class TraversalRunnable implements Runnable &#123; @Override public void run() &#123; doTraversal(); &#125;&#125;void doTraversal() &#123; if (mTraversalScheduled) &#123; mTraversalScheduled = false; mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier); if (mProfile) &#123; Debug.startMethodTracing(\"ViewAncestor\"); &#125; performTraversals(); if (mProfile) &#123; Debug.stopMethodTracing(); mProfile = false; &#125; &#125;&#125; 在这里，调用了scheduleTraversals方法，这个方法是一个异步方法，最终会调用到ViewRootImpl#performTraversals方法，这也是View工作流程的核心方法，在这个方法内部，分别调用measure、layout、draw方法来进行View的三大工作流程private void performTraversals() &#123; ... if (!mStopped) &#123; int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width); // 1 int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height); performMeasure(childWidthMeasureSpec, childHeightMeasureSpec); &#125; &#125; if (didLayout) &#123; performLayout(lp, desiredWindowWidth, desiredWindowHeight); ... &#125; if (!cancelDraw &amp;&amp; !newSurface) &#123; if (!skipDraw || mReportNextDraw) &#123; if (mPendingTransitions != null &amp;&amp; mPendingTransitions.size() &gt; 0) &#123; for (int i = 0; i &lt; mPendingTransitions.size(); ++i) &#123; mPendingTransitions.get(i).startChangingAnimations(); &#125; mPendingTransitions.clear(); &#125; performDraw(); &#125; &#125; ...&#125; 这里很熟悉了吧,view,viewgroup的绘制,如果这里有问题的,自己百度吧,所以会最终调用到recyclerview的onMeature recyclerView.setLayoutManager(layoutManager)就是桥接模式的体现，因为layoutManager的实现可以有多种,即桥接模式具体实现化逻辑ConcreteImplementor ListView功能 recyclerView.setLayoutManager(new LinearLayoutManager(this)); GridView功能 recyclerView.setLayoutManager(new GridLayoutManager(this,3)); 瀑布流形式功能 recyclerView.setLayoutManager(new StaggeredGridLayoutManager(2,StaggeredGridLayoutManager.VERTICAL)); 横向ListView的功能 recyclerView.setLayoutManager(new LinearLayoutManager(this)); layoutManager.setOrientation(…); public LinearLayoutManager(Context context, int orientation, boolean reverseLayout) &#123; setOrientation(orientation); setReverseLayout(reverseLayout); setAutoMeasureEnabled(true);&#125;public StaggeredGridLayoutManager(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) &#123; Properties properties = getProperties(context, attrs, defStyleAttr, defStyleRes); setOrientation(properties.orientation); setSpanCount(properties.spanCount); setReverseLayout(properties.reverseLayout); setAutoMeasureEnabled(mGapStrategy != GAP_HANDLING_NONE); mLayoutState = new LayoutState(); createOrientationHelpers();&#125; GridLayoutManager继承LinearLayoutManager 可见其初始化时候会设置AutoMeasurEnabled,前面说过，RecyclerView会将测量与布局交给LayoutManager来做，并且LayoutManager有一个叫做mAutoMeasure的属性，这个属性用来控制LayoutManager是否开启自动测量，开启自动测量的话布局就交由RecyclerView使用一套默认的测量机制，否则，自定义的LayoutManager需要重写onMeasure来处理自身的测量工作。RecyclerView目前提供的几种LayoutManager都开启了自动测量，所以这里我们关注一下自动测量部分的逻辑： protected void onMeasure(int widthSpec, int heightSpec) &#123; ... if (mLayout.mAutoMeasure) &#123; final int widthMode = MeasureSpec.getMode(widthSpec); final int heightMode = MeasureSpec.getMode(heightSpec); final boolean skipMeasure = widthMode == MeasureSpec.EXACTLY &amp;&amp; heightMode == MeasureSpec.EXACTLY; mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec); if (skipMeasure || mAdapter == null) &#123; return; &#125; if (mState.mLayoutStep == State.STEP_START) &#123; dispatchLayoutStep1(); &#125; mLayout.setMeasureSpecs(widthSpec, heightSpec); mState.mIsMeasuring = true; dispatchLayoutStep2(); mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec); if (mLayout.shouldMeasureTwice()) &#123; mLayout.setMeasureSpecs( MeasureSpec.makeMeasureSpec(getMeasuredWidth(), MeasureSpec.EXACTLY), MeasureSpec.makeMeasureSpec(getMeasuredHeight(), MeasureSpec.EXACTLY)); mState.mIsMeasuring = true; dispatchLayoutStep2(); mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec); &#125; &#125; ...&#125; 自动测量的原理如下:当RecyclerView的宽高都为EXACTLY时，可以直接设置对应的宽高，然后返回，结束测量。 补充MeasureSpect三种模式三种模式是EXACTLY,UNSPECIFIED,AT_MOST,分别代表精确大小,不精确大小,最大值;通过MeasureSpect.getMode就可以获得该值,那么MeasureSpect到底是由什么决定的呢?MeasureSpect是由LayoutParameter通过父容器的施加的规则产生的下面我们来看一看三种模式产生的情况. MeasureSpec.EXACTLY父容器已经精确的检测出了子View的大小,子view的大小就是MeasureSpect.getSize()的值.适用情况: a.子View的LayoutParameter使用具体的值(如:宽高为100dp),不管父容器的spectMode为什么,系统返回给子View的mode为EXACTLY,系统返回给子View的大小为子V诶额外自己指定的大小(100dp) b.子View的LayoutParams采用match_parent并且父容器的mode为EXACTLY,那么子View的mode即为EXACTLY,子View大小为父容器剩余的大小 MeasureSpec.AT_MOST父容器期望对子View的最大值做了限定适用情况: c.子View的LayoutParams采用match_parent并且父容器的mode为AT_MOST,那么子View的mode即为AT_MOST,子View大小为父容器剩余的大小 d.当子View的LayoutParams采用wrap_content时并且父容器的mode为EXACTLY或者AT_MOST时,子View的Mode就为AT_MOST，子View的specSize就为该父容器剩余的大小 MeasureSpec.UNSPECIFIED父容器不限定大小,子View想多大就多大适应情况: e.当子View的LayoutParams采用wrap_content时并且父容器的mode为UNSPECIFIED时,子View的Mode就为UNSPECIFIED，子View的大小不做限制 如果宽高的测量规则不是EXACTLY的,则会在onMeasure()中开始布局的处理，这里首先要介绍一个很重要的类： RecyclerView.State ，这个类封装了当前RecyclerView的有用信息。State的一个变量mLayoutStep表示了RecyclerView当前的布局状态，包括STEP_START、STEP_LAYOUT 、 STEP_ANIMATIONS三个，而RecyclerView的布局过程也分为三步，其中，STEP_START表示即将开始布局，需要调用dispatchLayoutStep1来执行第一步布局，接下来，布局状态变为STEP_LAYOUT，表示接下来需要调用dispatchLayoutStep2里进行第二步布局，同理，第二步布局后状态变为STEP_ANIMATIONS，需要执行第三步布局dispatchLayoutStep3。 这三个步骤的工作也各不相同，step1负责记录状态，step2负责布局，step3则与step1进行比较，根据变化来触发动画。 RecyclerView将布局划分的如此细致必然是有其原因的，在开启自动测量模式的情况，RecyclerView是支持WRAP_CONTENT属性的，比如我们可以很容易的在RecyclerView的下面放置其它的View，RecyclerView会根据子View所占大小动态调整自己的大小，这时候，RecyclerView就会将子控件的measure与layout提前到Recycler的onMeasure中，因为它需要确定子空间的大小与位置后，再来设置自己的大小。所以这时候就会在onMeasure中完成step1与step2。否则，就需要在onLayout中去完成整个布局过程。 综上，整个mLayout.mAutoMeasure就是在做前两步的布局，可见RecylerView的measure与layout是紧密相关的，所以我们来赶快瞧一瞧RecyclerView是如何layout的。 我们直接看下onLayout的代码：protected void onLayout(boolean changed, int l, int t, int r, int b) &#123; TraceCompat.beginSection(TRACE_ON_LAYOUT_TAG); dispatchLayout(); TraceCompat.endSection(); mFirstLayoutComplete = true;&#125; 直接追进dispatchLayout：void dispatchLayout() &#123; ... mState.mIsMeasuring = false; if (mState.mLayoutStep == State.STEP_START) &#123; dispatchLayoutStep1(); mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2(); &#125; else if (mAdapterHelper.hasUpdates() || mLayout.getWidth() != getWidth() ||mLayout.getHeight() != getHeight()) &#123; // First 2 steps are done in onMeasure but looks like we have to run again due to // changed size. mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2(); &#125; else &#123; // always make sure we sync them (to ensure mode is exact) mLayout.setExactMeasureSpecsFrom(this); &#125; dispatchLayoutStep3();&#125; 通过查看dispatchLayout的代码正好验证了我们前文关于RecyclerView的layout三步走原则，如果在onMeasure中已经完成了step1与step2，则只会执行step3，否则三步会依次触发。接下来我们一步一步的进行分析 dispatchLayoutStep1private void dispatchLayoutStep1()&#123; ... if (mState.mRunSimpleAnimations) &#123; int count = mChildHelper.getChildCount(); for (int i = 0; i &lt; count; ++i) &#123; final ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i)); final ItemHolderInfo animationInfo = mItemAnimator .recordPreLayoutInformation(mState, holder, ItemAnimator.buildAdapterChangeFlagsForAnimations(holder), holder.getUnmodifiedPayloads()); mViewInfoStore.addToPreLayout(holder, animationInfo); ... &#125; &#125; ... mState.mLayoutStep = State.STEP_LAYOUT;&#125;class ViewInfoStore &#123; private static final boolean DEBUG = false; @VisibleForTesting final ArrayMap mLayoutHolderMap = new ArrayMap&lt;&gt;(); @VisibleForTesting final LongSparseArray mOldChangedHolders = new LongSparseArray&lt;&gt;(); void clear() &#123; mLayoutHolderMap.clear(); mOldChangedHolders.clear(); &#125;&#125;public static class ItemHolderInfo &#123; public int left; public int top; public int right; public int bottom; @AdapterChanges public int changeFlags; public ItemHolderInfo() &#123; &#125;&#125; step的第一步目的就是在记录View的状态，首先遍历当前所有的View依次进行处理，mItemAnimator会根据每个View的信息封装成一个ItemHolderInfo，这个ItemHolderInfo中主要包含的就是当前View的位置状态等。然后ItemHolderInfo 就被存入mViewInfoStore中,由代码可见被存在ArrayMap和LongSparseArray中,其是对HashMap的android优化,是用两个数组来完成存储,arraymap的key可以是任意值,SparseArray的key只能为int,其核心是折半查找 注意这里调用的是mViewInfoStore的addToPreLayout方法，我们追进：void addToPreLayout(ViewHolder holder, ItemHolderInfo info) &#123; InfoRecord record = mLayoutHolderMap.get(holder); if (record == null) &#123; record = InfoRecord.obtain(); mLayoutHolderMap.put(holder, record); &#125; record.preInfo = info; record.flags |= FLAG_PRE;&#125; addToPreLayout方法中会根据holder来查询InfoRecord信息，如果没有，则生成，然后将info信息赋值给InfoRecord的preInfo变量。最后标记FLAG_PRE信息，如此，完成函数。所以纵观整个layout的第一步，就是在记录当前的View信息，因为进入第二步后，View的信息就将被改变了。我们来看第二步： dispatchLayoutStep2private void dispatchLayoutStep2() &#123; ... mLayout.onLayoutChildren(mRecycler, mState); ... mState.mLayoutStep = State.STEP_ANIMATIONS;&#125; layout的第二步主要就是真正的去布局View了，前面也说过，RecyclerView的布局是由LayoutManager负责的，所以第二步的主要工作也都在LayoutManager中，由于每种布局的方式不一样，这里我们以常见的LinearLayoutManager为例。我们看其onLayoutChildren方法： public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) &#123; ... if (!mAnchorInfo.mValid || mPendingScrollPosition != NO_POSITION || mPendingSavedState != null) &#123; updateAnchorInfoForLayout(recycler, state, mAnchorInfo); &#125; ... if (mAnchorInfo.mLayoutFromEnd) &#123; firstLayoutDirection = mShouldReverseLayout ? LayoutState.ITEM_DIRECTION_TAIL : LayoutState.ITEM_DIRECTION_HEAD; &#125; else &#123; firstLayoutDirection = mShouldReverseLayout ? LayoutState.ITEM_DIRECTION_HEAD : LayoutState.ITEM_DIRECTION_TAIL; &#125; ... onAnchorReady(recycler, state, mAnchorInfo, firstLayoutDirection); ... if (mAnchorInfo.mLayoutFromEnd) &#123; ... &#125; else &#123; // fill towards end updateLayoutStateToFillEnd(mAnchorInfo); fill(recycler, mLayoutState, state, false); ... // fill towards start updateLayoutStateToFillStart(mAnchorInfo); ... fill(recycler, mLayoutState, state, false); ... &#125; ...&#125; 整个onLayoutChildren过程还是很复杂的，这里我尽量省略了一些与流程关系不大的细节处理代码。整个onLayoutChildren过程可以大致整理如下： 找到anchor点 根据anchor一直向前布局，直至填充满anchor点前面的所有区域 根据anchor一直向后布局，直至填充满anchor点后面的所有区域这里我以垂直布局来说明，mAnchorInfo为布局锚点信息，包含了子控件在Y轴上起始绘制偏移量（coordinate），ItemView在Adapter中的索引位置（position）和布局方向（mLayoutFromEnd）——这里是指start、end方向。 这部分代码的功能就是：确定布局锚点，以此为起点向开始和结束方向填充ItemView，如图所示： anchor点的寻找是由updateAnchorInfoForLayout函数负责的：private void updateAnchorInfoForLayout(RecyclerView.Recycler recycler, RecyclerView.State state, AnchorInfo anchorInfo) &#123; ... if (updateAnchorFromChildren(recycler, state, anchorInfo)) &#123; return; &#125; ... anchorInfo.assignCoordinateFromPadding(); anchorInfo.mPosition = mStackFromEnd ? state.getItemCount() - 1 : 0;&#125; 函数内首先通过子view来获取anchor，如果没有获取到，就根据就取头/尾点来作为anchor。所以这里我们主要关注updateAnchorFromChildren函数： private boolean updateAnchorFromChildren(RecyclerView.Recycler recycler, RecyclerView.State state, AnchorInfo anchorInfo) &#123; if (getChildCount() == 0) &#123; return false; &#125; final View focused = getFocusedChild(); if (focused != null &amp;&amp; anchorInfo.isViewValidAsAnchor(focused, state)) &#123; anchorInfo.assignFromViewAndKeepVisibleRect(focused); return true; &#125; if (mLastStackFromEnd != mStackFromEnd) &#123; return false; &#125; View referenceChild = anchorInfo.mLayoutFromEnd ? findReferenceChildClosestToEnd(recycler, state) : findReferenceChildClosestToStart(recycler, state); if (referenceChild != null) &#123; anchorInfo.assignFromView(referenceChild); ... return true; &#125; return false;&#125; updateAnchorFromChildren内部做的事情也很容易理解，首先寻找被focus的child，找到的话以此child作为anchor，否则根据布局的方向寻找最合适的child来作为anchor，如果找到则将child的信息赋值给anchorInfo，其实anchorInfo主要记录的信息就是view的物理位置与在adapter中的位置。找到后返回true，否则返回false则交由上一步的函数做处理。 综上，刚刚的所追踪的代码都是在寻找anchor点。在我们寻找后，LinearLayoutManager还给了我们更改anchor的时机，就是 onAnchorReady 函数，我们可以继承LinearLayoutManager 来重写onAnchorReady方法，就可以实现某些特定的功能，比如进入RecyclerView时定位在某一项等等。 总之，我们现在找到了anchor信息，接下来就是根据anchor来布局了。无论从上到下还是从下到上布局，都调用的是fill方法，我们进入fill方法来查看一番：int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) &#123; final int start = layoutState.mAvailable; if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) &#123; recycleByLayoutState(recycler, layoutState); &#125; int remainingSpace = layoutState.mAvailable + layoutState.mExtra; LayoutChunkResult layoutChunkResult = mLayoutChunkResult; while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; layoutChunk(recycler, state, layoutState, layoutChunkResult); ... &#125; return start - layoutState.mAvailable;&#125; 这里同样省略了很多代码，我们关注重点： 首先比较重要的函数是recycleByLayoutState，这个函数就厉害了，它会根据当前信息对不需要的View进行回收： private void recycleByLayoutState(RecyclerView.Recycler recycler, LayoutState layoutState) &#123; if (layoutState.mLayoutDirection == LayoutState.LAYOUT_START) &#123; ... &#125; else &#123; recycleViewsFromStart(recycler, layoutState.mScrollingOffset); &#125;&#125; 我们继续追进recycleViewsFromStart：private void recycleViewsFromStart(RecyclerView.Recycler recycler, int dt) &#123; final int limit = dt; final int childCount = getChildCount(); if (mShouldReverseLayout) &#123; ... &#125; else &#123; for (int i = 0; i &lt; childCount; i++) &#123; View child = getChildAt(i); if (mOrientationHelper.getDecoratedEnd(child) &gt; limit || mOrientationHelper.getTransformedEndWithDecoration(child) &gt; limit) &#123; recycleChildren(recycler, 0, i); return; &#125; &#125; &#125;&#125; 这个函数的作用就是遍历所有的子View，找出逃离边界的View进行回收，回收函数我们锁定在recycleChildren里，而这个函数最后又会调到removeAndRecycleViewAt：public void removeAndRecycleViewAt(int index, Recycler recycler) &#123; final View view = getChildAt(index); removeViewAt(index); recycler.recycleView(view);&#125; 这个函数首先调用removeViewAt函数，这个函数的作用是将View从RecyclerView中移除， 紧接着我们看到，是recycler执行了view的回收逻辑。这里我们暂且打住，关于recycler我们会单独进行说明，这里我们只需要理解，在fill函数的一开始会去回收逃离出屏幕的view。我们再次回到fill函数，关注这里： while ((layoutState.mInfinite || remainingSpace &gt; 0) &amp;&amp; layoutState.hasMore(state)) &#123; layoutChunk(recycler, state, layoutState, layoutChunkResult); ...&#125; 这段代码很容易理解，只要还有剩余空间，就会执行layoutChunk方法：void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state, LayoutState layoutState, LayoutChunkResult result) &#123; View view = layoutState.next(recycler); ... LayoutParams params = (LayoutParams) view.getLayoutParams(); if (layoutState.mScrapList == null) &#123; if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) &#123; addView(view); &#125; else &#123; addView(view, 0); &#125; &#125; else &#123; ... &#125; ... layoutDecoratedWithMargins(view, left, top, right, bottom); ...&#125; 我们首先看到，layoutState的next方法返回了一个View，凭空变出一个View，好神奇，追进去看一下：View next(RecyclerView.Recycler recycler) &#123; ... final View view = recycler.getViewForPosition(mCurrentPosition); return view;&#125; 可见，view的获取逻辑也由recycler来负责，所以，这里我们同样打住，只需要清楚recycler可以根据位置返回一个view即可。 再回到layoutChunk看一下对刚刚生成的view作何处理：if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) &#123; addView(view); &#125; else &#123; addView(view, 0);&#125; 很明显调用了addView方法，虽然这个方法是LayoutManager的，但这个方法最终会多次辗转调用到RecyclerView的addView方法，将view添加在RecyclerView中。综上，我们就梳理了整个第二步布局的过程，此过程完成了子View的测量与布局，任务还是相当繁重。 多说一点，这里的addView()，中间会调用的下面这个方法，这个方法会调用到 RecyclerView的onChildAttachedToWindow 和 mAdapter.onViewAttachedToWindow。通过这两个方法可以监听view或者viewholder显示的时机// RecyclerViewvoid dispatchChildAttached(View child) &#123; final ViewHolder viewHolder = getChildViewHolderInt(child); onChildAttachedToWindow(child); if (mAdapter != null &amp;&amp; viewHolder != null) &#123; mAdapter.onViewAttachedToWindow(viewHolder); &#125; if (mOnChildAttachStateListeners != null) &#123; final int cnt = mOnChildAttachStateListeners.size(); for (int i = cnt - 1; i &gt;= 0; i--) &#123; mOnChildAttachStateListeners.get(i).onChildViewAttachedToWindow(child); &#125; &#125; &#125; dispatchLayoutStep3接下来，就到了布局的最后一步了，我们直接看下dispatchLayoutStep3方法：private void dispatchLayoutStep3() &#123; mState.mLayoutStep = State.STEP_START; if (mState.mRunSimpleAnimations) &#123; for (int i = mChildHelper.getChildCount() - 1; i &gt;= 0; i--) &#123; ... final ItemHolderInfo animationInfo = mItemAnimator .recordPostLayoutInformation(mState, holder); mViewInfoStore.addToPostLayout(holder, animationInfo); &#125; mViewInfoStore.process(mViewInfoProcessCallback); &#125; ...&#125; 这一步是与第一步呼应的的，此时由于子View都已完成布局，所以子View的信息都发生了变化。我们会看到第一步出现的mViewInfoStore和mItemAnimator再次登场，这次mItemAnimator调用的是recordPostLayoutInformation方法，而mViewInfoStore调用的是addToPostLayout方法，还记得刚刚我强调的吗，之前是pre，也就是真正布局之前的状态，而现在要记录布局之后的状态，我们追进addToPostLayout：void addToPostLayout(ViewHolder holder, ItemHolderInfo info) &#123; InfoRecord record = mLayoutHolderMap.get(holder); if (record == null) &#123; record = InfoRecord.obtain(); mLayoutHolderMap.put(holder, record); &#125; record.postInfo = info; record.flags |= FLAG_POST;&#125; 和第一步的addToPreLayout类似，不过这次info信息被赋值给了record的postInfo变量，这样，一个record中就包含了布局前后view的状态。 最后，mViewInfoStore调用了process方法，这个方法就是根据mViewInfoStore中的View信息，来执行动画逻辑，这又是一个可以展看很多的点，这里不做探讨，感兴趣的可以深入的看一下，会对动画流程有更直观的体会。 接下来就是onDraw,RecyclerView的draw过程可以分为２部分来看：RecyclerView负责绘制所有decoration；ItemView的绘制由ViewGroup处理，这里的绘制是android常规绘制逻辑，本文就不再阐述了。下面来看看RecyclerView的draw()和onDraw()方法：@Overridepublic void draw(Canvas c) &#123; super.draw(c); final int count = mItemDecorations.size(); for (int i = 0; i &lt; count; i++) &#123; mItemDecorations.get(i).onDrawOver(c, this, mState); &#125; ...&#125;@Overridepublic void onDraw(Canvas c) &#123; super.onDraw(c); final int count = mItemDecorations.size(); for (int i = 0; i &lt; count; i++) &#123; mItemDecorations.get(i).onDraw(c, this, mState); &#125;&#125; 好了,测量,布局,绘制都大体讲了一下,回到我们开头,setLayoutManager已经完成。接下来是setAdapter(适配器模式),我们一起结合动画的实现(观察者模式)来解读,先看一下adapter类 setAdapter(适配器模式)public static abstract class Adapter &#123; private final AdapterDataObservable mObservable = new AdapterDataObservable(); public void registerAdapterDataObserver(AdapterDataObserver observer) &#123; mObservable.registerObserver(observer); &#125; public void unregisterAdapterDataObserver(AdapterDataObserver observer) &#123; mObservable.unregisterObserver(observer); &#125; public final void notifyItemInserted(int position) &#123; mObservable.notifyItemRangeInserted(position, 1); &#125;&#125; RecyclerView的Adapter，这个控件需要的是View(dst),而我们有的一般是datas(src),所以适配器Adapter就是完成了数据源datas 转化成 ItemView的工作。带入src-&gt;Adapter-&gt;dst中，即datas-&gt;Adapter-&gt;View. 通过public abstract void onBindViewHolder(VH holder, int position);将datas绑定到view然后返回ViewHolder我们可以看到Adapter中包含一个AdapterDataObservable的对象mObservable，这个是一个可观察者，在可观察者中可以注册一系列的观察者AdapterDataObserver。在我们调用的notify函数的时候，就是可观察者发出通知，这时已经注册的观察者都可以收到这个通知，然后依次进行处理。哈哈,是不是我们前面的Subject…那么我们看一下注册观察者的地方。 注册观察者的地方就是在RecyclerView的这个函数中。这个是setAdapter方法最终调用的地方。它主要做了： 如果之前存在Adapter，先移除原来的，注销观察者，和从RecyclerView Detached。然后根据参数，决定是否清除原来的ViewHolder然后重置AdapterHelper，并更新Adapter，注册观察者。public void setAdapter(Adapter adapter) &#123; // bail out if layout is frozen setLayoutFrozen(false); setAdapterInternal(adapter, false, true); requestLayout();&#125; 看一看setAdapterInternalprivate void setAdapterInternal(Adapter adapter, boolean compatibleWithPrevious, boolean removeAndRecycleViews) &#123; if (mAdapter != null) &#123; mAdapter.unregisterAdapterDataObserver(mObserver); mAdapter.onDetachedFromRecyclerView(this); &#125; if (!compatibleWithPrevious || removeAndRecycleViews) &#123; // end all running animations if (mItemAnimator != null) &#123; mItemAnimator.endAnimations(); &#125; // Since animations are ended, mLayout.children should be equal to // recyclerView.children. This may not be true if item animator's end does not work as // expected. (e.g. not release children instantly). It is safer to use mLayout's child // count. if (mLayout != null) &#123; mLayout.removeAndRecycleAllViews(mRecycler); mLayout.removeAndRecycleScrapInt(mRecycler); &#125; // we should clear it here before adapters are swapped to ensure correct callbacks. mRecycler.clear(); &#125; mAdapterHelper.reset(); final Adapter oldAdapter = mAdapter; mAdapter = adapter; if (adapter != null) &#123; adapter.registerAdapterDataObserver(mObserver); adapter.onAttachedToRecyclerView(this); &#125; if (mLayout != null) &#123; mLayout.onAdapterChanged(oldAdapter, mAdapter); &#125; mRecycler.onAdapterChanged(oldAdapter, mAdapter, compatibleWithPrevious); mState.mStructureChanged = true; markKnownViewsInvalid();&#125; 从这里我们可以看出，mObserver这个成员变量就是注册的观察者，那么我们去看看这个成员变量的内容。 该成员变量是一个RecyclerViewDataObserver的实例，那么RecyclerViewDataObserver实现了AdapterDataObserver中的方法。其中onItemRangeInserted(int positionStart, int itemCount)就是观察者接受到有数据插入通知的方法。那么我们来分析这个方法。看注释。private final RecyclerViewDataObserver mObserver = new RecyclerViewDataObserver();private class RecyclerViewDataObserver extends AdapterDataObserver &#123; ... mPostUpdatesOnAnimation = version &gt;= 16; @Override public void onItemRangeInserted(int positionStart, int itemCount) &#123; // 1) 断言不在布局或者滚动过程中，其实就是如果在布局或者滚动过程中，则不会执 // 行下面的内容 assertNotInLayoutOrScroll(null); // 2) 这里小型，不要小看if括号中的内容，这是关键。我们去看看这个方法的实现。 // 见下面注释 3)，在 3) 返回true之后执行triggerUpdateProcessor方法， // triggerUpdateProcessor方法分析请看注释 4)。 if (mAdapterHelper.onItemRangeInserted(positionStart, itemCount)) &#123; triggerUpdateProcessor(); &#125; &#125;&#125; AdapterHelper中onItemRangeInserted函数即相关内容，请看注释 3)。class AdapterHelper implements OpReorderer.Callback &#123; // 一个待处理更新操作的列表，该列表中存放所有等待处理的操作信息。 final ArrayList mPendingUpdates = new ArrayList(); // 3) 该方法将插入操作的信息存储到一个UpdateOp中，并添加到待处理更新操作列表中， // 如果操作列表中的值是1，就返回真表示需要处理操作，等于1的判断避免重复触发处理操作。 // obtainUpdateOp内部是通过池来得到一个UpdateOp对象。那么下面回去看我们注释 4)。 boolean onItemRangeInserted(int positionStart, int itemCount) &#123; if (itemCount &lt; 1) &#123; return false; &#125; mPendingUpdates.add(obtainUpdateOp(UpdateOp.ADD, positionStart, itemCount, null)); mExistingUpdateTypes |= UpdateOp.ADD; return mPendingUpdates.size() == 1; &#125;&#125;// 4) 触发更新处理操作，分为两种情况，在 版本大于16 且 已经Attach 并且 设置了大小固定 的情况下，// 进行mUpdateChildViewsRunnable中的操作。否则请求布局。void triggerUpdateProcessor() &#123; if (mPostUpdatesOnAnimation &amp;&amp; mHasFixedSize &amp;&amp; mIsAttached) &#123; ViewCompat.postOnAnimation(RecyclerView.this, mUpdateChildViewsRunnable); &#125; else &#123; mAdapterUpdateDuringMeasure = true; requestLayout(); &#125;&#125;// 5) 其中核心代码是consumePendingUpdateOperations()那么继续往下看。private final Runnable mUpdateChildViewsRunnable = new Runnable() &#123; public void run() &#123; ... consumePendingUpdateOperations(); &#125;&#125;;private void consumePendingUpdateOperations() &#123; ... if (mAdapterHelper.hasAnyUpdateTypes(UpdateOp.UPDATE) &amp;&amp; !mAdapterHelper .hasAnyUpdateTypes(UpdateOp.ADD | UpdateOp.REMOVE | UpdateOp.MOVE)) &#123; // 6) 如果只有更新类型的操作(这里指内容的更新，不影响View位置的改变)的情况下， // 先进行预处理，然后在没有View更新的情况下消耗延迟的更新操作，否则调用 // dispatchLayout方法对RecyclerView中的View重新布局。那么接下来分析 // preProcess()方法。 mAdapterHelper.preProcess(); if (!mLayoutRequestEaten) &#123; if (hasUpdatedView()) &#123; dispatchLayout(); &#125; else &#123; mAdapterHelper.consumePostponedUpdates(); &#125; &#125; resumeRequestLayout(true); &#125; else if (mAdapterHelper.hasPendingUpdates()) &#123; // 7) 在既有更新操作又有添加或者删除或者移动中任意一个的情况下，调用 // dispatchLayout方法对RecyclerView中的View重新布局 dispatchLayout(); &#125;&#125;// 8) 预处理做了以下几件事情，&lt;1&gt; 先将待处理操作重排。&lt;2&gt; 应用所有操作 &lt;3&gt; 清空待处理操作列表，// 以ADD为例分析流程。void preProcess() &#123; mOpReorderer.reorderOps(mPendingUpdates); final int count = mPendingUpdates.size(); for (int i = 0; i &lt; count; i++) &#123; UpdateOp op = mPendingUpdates.get(i); switch (op.cmd) &#123; case UpdateOp.ADD: applyAdd(op); break; case UpdateOp.REMOVE: applyRemove(op); break; case UpdateOp.UPDATE: applyUpdate(op); break; case UpdateOp.MOVE: applyMove(op); break; &#125; if (mOnItemProcessedCallback != null) &#123; mOnItemProcessedCallback.run(); &#125; &#125; mPendingUpdates.clear();&#125;// 9) 直接看postponeAndUpdateViewHoldersprivate void applyAdd(UpdateOp op) &#123; postponeAndUpdateViewHolders(op);&#125;// 10) 先将操作添加到推迟的操作列表中。然后将操作的内容交给回调处理。private void postponeAndUpdateViewHolders(UpdateOp op) &#123; mPostponedList.add(op); switch (op.cmd) &#123; case UpdateOp.ADD: mCallback.offsetPositionsForAdd(op.positionStart, op.itemCount); break; case UpdateOp.MOVE: mCallback.offsetPositionsForMove(op.positionStart, op.itemCount); break; case UpdateOp.REMOVE: mCallback.offsetPositionsForRemovingLaidOutOrNewView(op.positionStart, op.itemCount); break; case UpdateOp.UPDATE: mCallback.markViewHoldersUpdated(op.positionStart, op.itemCount, op.payload); break; default: throw new IllegalArgumentException(\"Unknown update op type for \" + op); &#125;&#125;// 11) 直接看offsetPositionRecordsForInsert@Overridepublic void offsetPositionsForAdd(int positionStart, int itemCount) &#123; offsetPositionRecordsForInsert(positionStart, itemCount); mItemsAddedOrRemoved = true;&#125;// 12) 该方法主要是便利所有的ViewHolder，然后把在插入位置之后的ViewHolder的位置// 向后移动插入的个数，最后在对Recycler中缓存的ViewHolder做同样的操作，最后申请重新布局。void offsetPositionRecordsForInsert(int positionStart, int itemCount) &#123; final int childCount = mChildHelper.getUnfilteredChildCount(); for (int i = 0; i &lt; childCount; i++) &#123; final ViewHolder holder = getChildViewHolderInt(mChildHelper.getUnfilteredChildAt(i)); if (holder != null &amp;&amp; !holder.shouldIgnore() &amp;&amp; holder.mPosition &gt;= positionStart) &#123; holder.offsetPosition(itemCount, false); mState.mStructureChanged = true; &#125; &#125; mRecycler.offsetPositionRecordsForInsert(positionStart, itemCount); requestLayout();&#125; 前面讲过ViewInfoStore这个类是用来追踪View所要做的动画的。其中有一个内部类InfoRecord，该类用来存储ViewHolder前后的信息，以及ViewHolder状态的flag。其中还有一个非常重要的方法，process，该方法会处理所有的mLayoutHolderMap中的值，并根据其flag和前后的信息来判断ViewHolder的动作，并将这个动作反应给ProcessCallback。分别有4种行为：消失，出现，一直存在，为使用。然后交给外面去处理。 前面说过 dispatchLayoutStep3mViewInfoStore.process(mViewInfoProcessCallback);,之后我们看一下mViewInfoStore的ProcessCallback的实现mViewInfoProcessCallback，这里只拿processAppeared做分析：private final ViewInfoStore.ProcessCallback mViewInfoProcessCallback = new ViewInfoStore.ProcessCallback() &#123; ... @Override public void processAppeared(ViewHolder viewHolder, ItemHolderInfo preInfo, ItemHolderInfo info) &#123; animateAppearance(viewHolder, preInfo, info); &#125; ...&#125;; 然后看一下animateAppearance方法：private void animateAppearance(@NonNull ViewHolder itemHolder, @Nullable ItemHolderInfo preLayoutInfo, @NonNull ItemHolderInfo postLayoutInfo) &#123; itemHolder.setIsRecyclable(false); if (mItemAnimator.animateAppearance(itemHolder, preLayoutInfo, postLayoutInfo)) &#123; postAnimationRunner(); &#125;&#125; 该方法中不要忽略if中的内容：mItemAnimator.animateAppearance(itemHolder, preLayoutInfo, postLayoutInfo)那么进入该方法：看注释。@Overridepublic boolean animateAppearance(@NonNull ViewHolder viewHolder, @Nullable ItemHolderInfo preLayoutInfo, @NonNull ItemHolderInfo postLayoutInfo) &#123; // 该方法通过前后的布局信息来判断是移动还是添加。下面我们以添加为例分析 if (preLayoutInfo != null &amp;&amp; (preLayoutInfo.left != postLayoutInfo.left || preLayoutInfo.top != postLayoutInfo.top)) &#123; return animateMove(viewHolder, preLayoutInfo.left, preLayoutInfo.top, postLayoutInfo.left, postLayoutInfo.top); &#125; else &#123; return animateAdd(viewHolder); &#125;&#125; 真正实现是在DefaultItenAnimator中：这里做了三件事情，重置holder的动画，设置显示属性，然后添加到mPendingAdditions中，mPendingAdditions是一个存储添加ViewHolder的List，表示待处理的添加动画的ViewHolder。同样在DefaultItenAnimator总也有，移动的，移除的列表。@Overridepublic boolean animateAdd(final ViewHolder holder) &#123; resetAnimation(holder); ViewCompat.setAlpha(holder.itemView, 0); mPendingAdditions.add(holder); return true;&#125; 最后返回true，进入if，执行postAnimationRunner方法。private void postAnimationRunner() &#123; if (!mPostedAnimatorRunner &amp;&amp; mIsAttached) &#123; ViewCompat.postOnAnimation(this, mItemAnimatorRunner); mPostedAnimatorRunner = true; &#125;&#125; 去看mItemAnimatorRunner，其中调用的ItemAnimator的runPendingAnimations方法。private Runnable mItemAnimatorRunner = new Runnable() &#123; @Override public void run() &#123; if (mItemAnimator != null) &#123; mItemAnimator.runPendingAnimations(); &#125; mPostedAnimatorRunner = false; &#125;&#125;; 然后分析runPendingAnimations方法：该方法并不难，按照移除，移动，改变，添加，依次处理之前的待处理列表中的内容。这里还是以添加的做为例子来分析，看注释。public void runPendingAnimations() &#123; boolean removalsPending = !mPendingRemovals.isEmpty(); boolean movesPending = !mPendingMoves.isEmpty(); boolean changesPending = !mPendingChanges.isEmpty(); boolean additionsPending = !mPendingAdditions.isEmpty(); if (!removalsPending &amp;&amp; !movesPending &amp;&amp; !additionsPending &amp;&amp; !changesPending) &#123; return; &#125; for (ViewHolder holder : mPendingRemovals) &#123; ... &#125; mPendingRemovals.clear(); if (movesPending) &#123; ... &#125; if (changesPending) &#123; ... &#125; if (additionsPending) &#123; final ArrayList additions = new ArrayList&lt;&gt;(); additions.addAll(mPendingAdditions); mAdditionsList.add(additions); mPendingAdditions.clear(); // 重要的是这个adder。其中重要的是 animateAddImpl(holder) 方法。那么来分析这个方法。 Runnable adder = new Runnable() &#123; public void run() &#123; for (ViewHolder holder : additions) &#123; animateAddImpl(holder); &#125; additions.clear(); mAdditionsList.remove(additions); &#125; &#125;; if (removalsPending || movesPending || changesPending) &#123; long removeDuration = removalsPending ? getRemoveDuration() : 0; long moveDuration = movesPending ? getMoveDuration() : 0; long changeDuration = changesPending ? getChangeDuration() : 0; long totalDelay = removeDuration + Math.max(moveDuration, changeDuration); View view = additions.get(0).itemView; ViewCompat.postOnAnimationDelayed(view, adder, totalDelay); &#125; else &#123; adder.run(); &#125; &#125;&#125; 这个方法其实就是通过属性动画对ViewHolder中的View做渐变动画。private void animateAddImpl(final ViewHolder holder) &#123; final View view = holder.itemView; final ViewPropertyAnimatorCompat animation = ViewCompat.animate(view); mAddAnimations.add(holder); animation.alpha(1).setDuration(getAddDuration()). setListener(new VpaListenerAdapter() &#123; @Override public void onAnimationStart(View view) &#123; dispatchAddStarting(holder); &#125; @Override public void onAnimationCancel(View view) &#123; ViewCompat.setAlpha(view, 1); &#125; @Override public void onAnimationEnd(View view) &#123; animation.setListener(null); dispatchAddFinished(holder); mAddAnimations.remove(holder); dispatchFinishedWhenDone(); &#125; &#125;).start();&#125; 到这里，终于是触发了我们的动画。其它的动作，流程类似，细节不同而已。那么通过流程我们可以深入理解以下2点： 如果我们的RecyclerView的高度和宽度不变，那么通过手动执行setHasFixedSize(true)，可以在一定程度上减少计算，提高性能。可以在 4) 步的时候绕过requestLayout，只走自身的布局流程。而requestLayout是申请父控件重新布局流程，两者的计算量是不一样的。自定义ItemAnimator的时候，如果在animateAppearance，animateDisappearance……方法中直接运行了动画，就返回false，如果是暂存起来，就返回true，然后将真正执行动画的操作放在runPendingAnimations方法中。 滑动RecyclerView的滑动过程可以分为2个阶段：手指在屏幕上移动，使RecyclerView滑动的过程，可以称为scroll；手指离开屏幕，RecyclerView继续滑动一段距离的过程，可以称为fling。现在先看看RecyclerView的触屏事件处理onTouchEvent()方法：public boolean onTouchEvent(MotionEvent e) &#123; ... if (mVelocityTracker == null) &#123; mVelocityTracker = VelocityTracker.obtain(); &#125; ... switch (action) &#123; ... case MotionEvent.ACTION_MOVE: &#123; ... final int x = (int) (MotionEventCompat.getX(e, index) + 0.5f); final int y = (int) (MotionEventCompat.getY(e, index) + 0.5f); int dx = mLastTouchX - x; int dy = mLastTouchY - y; ... if (mScrollState != SCROLL_STATE_DRAGGING) &#123; ... if (canScrollVertically &amp;&amp; Math.abs(dy) &gt; mTouchSlop) &#123; if (dy &gt; 0) &#123; dy -= mTouchSlop; &#125; else &#123; dy += mTouchSlop; &#125; startScroll = true; &#125; if (startScroll) &#123; setScrollState(SCROLL_STATE_DRAGGING); &#125; &#125; if (mScrollState == SCROLL_STATE_DRAGGING) &#123; mLastTouchX = x - mScrollOffset[0]; mLastTouchY = y - mScrollOffset[1]; if (scrollByInternal( canScrollHorizontally ? dx : 0, canScrollVertically ? dy : 0, vtev)) &#123; getParent().requestDisallowInterceptTouchEvent(true); &#125; &#125; &#125; break; ... case MotionEvent.ACTION_UP: &#123; ... final float yvel = canScrollVertically ? -VelocityTrackerCompat.getYVelocity(mVelocityTracker, mScrollPointerId) : 0; if (!((xvel != 0 || yvel != 0) &amp;&amp; fling((int) xvel, (int) yvel))) &#123; setScrollState(SCROLL_STATE_IDLE); &#125; resetTouch(); &#125; break; ... &#125; ...&#125; 这里我以垂直方向的滑动来说明。当RecyclerView接收到ACTION_MOVE事件后，会先计算出手指移动距离（dy），并与滑动阀值（mTouchSlop）比较，当大于此阀值时将滑动状态设置为SCROLL_STATE_DRAGGING，而后调用scrollByInternal()方法，使RecyclerView滑动，这样RecyclerView的滑动的第一阶段scroll就完成了；当接收到ACTION_UP事件时，会根据之前的滑动距离与时间计算出一个初速度yvel，这步计算是由VelocityTracker实现的，然后再以此初速度，调用方法fling()，完成RecyclerView滑动的第二阶段fling。显然滑动过程中关键的方法就2个：scrollByInternal()与fling()。接下来同样以垂直线性布局来说明。先来说明scrollByInternal()，跟踪进入后，会发现它最终会调用到LinearLayoutManager.scrollBy()方法，这个过程很简单，我就不列出源码了，但是分析到这里先暂停下，去看看fling()方法：public boolean fling(int velocityX, int velocityY) &#123; ... mViewFlinger.fling(velocityX, velocityY); ...&#125; 有用的就这一行，其它乱七八糟的不看也罢。mViewFlinger是一个Runnable的实现ViewFlinger的对象，就是它来控件着ReyclerView的fling过程的算法的。下面来看下类ViewFlinger的一段代码：void postOnAnimation() &#123; if (mEatRunOnAnimationRequest) &#123; mReSchedulePostAnimationCallback = true; &#125; else &#123; removeCallbacks(this); ViewCompat.postOnAnimation(RecyclerView.this, this); &#125;&#125;public void fling(int velocityX, int velocityY) &#123; setScrollState(SCROLL_STATE_SETTLING); mLastFlingX = mLastFlingY = 0; mScroller.fling(0, 0, velocityX, velocityY, Integer.MIN_VALUE, Integer.MAX_VALUE, Integer.MIN_VALUE, Integer.MAX_VALUE); postOnAnimation();&#125; 可以看到，其实RecyclerView的fling是借助Scroller实现的；然后postOnAnimation()方法的作用就是在将来的某个时刻会执行我们给定的一个Runnable对象，在这里就是这个mViewFlinger对象，这部分原理我就不再深入分析了，它已经不属于本文的范围了。并且，关于Scroller的作用及原理，本文也不会作过多解释。对于这两点各位可以自行查阅，有很多文章对于作过详细阐述的。接下来看看ViewFlinger.run()方法：public void run() &#123; ... if (scroller.computeScrollOffset()) &#123; final int x = scroller.getCurrX(); final int y = scroller.getCurrY(); final int dx = x - mLastFlingX; final int dy = y - mLastFlingY; ... if (mAdapter != null) &#123; ... if (dy != 0) &#123; vresult = mLayout.scrollVerticallyBy(dy, mRecycler, mState); overscrollY = dy - vresult; &#125; ... &#125; ... if (!awakenScrollBars()) &#123; invalidate();//刷新界面 &#125; ... if (scroller.isFinished() || !fullyConsumedAny) &#123; setScrollState(SCROLL_STATE_IDLE); &#125; else &#123; postOnAnimation(); &#125; &#125; ...&#125; 本段代码中有个方法mLayout.scrollVerticallyBy()，跟踪进入你会发现它最终也会走到LinearLayoutManager.scrollBy()，这样虽说RecyclerView的滑动可以分为两阶段，但是它们的实现最终其实是一样的。这里我先解释下上段代码。第一，dy表示滑动偏移量，它是由Scroller根据时间偏移量（Scroller.fling()开始时间到当前时刻）计算出的，当然如果是RecyclerView的scroll阶段，这个偏移量也就是手指滑动距离。第二，上段代码会多次执行，至到Scroller判断滑动结束或已经滑动到边界。再多说一下，postOnAnimation()保证了RecyclerView的滑动是流畅，这里涉及到著名的“android 16ms”机制，简单来说理想状态下，上段代码会以16毫秒一次的速度执行，这样其实，Scroller每次计算的滑动偏移量是很小的一部分，而RecyclerView就会根据这个偏移量，确定是平移ItemView，还是除了平移还需要再创建新ItemView。 现在就来看看LinearLayoutManager.scrollBy()方法：int scrollBy(int dy, RecyclerView.Recycler recycler, RecyclerView.State state) &#123; ... final int absDy = Math.abs(dy); updateLayoutState(layoutDirection, absDy, true, state); final int consumed = mLayoutState.mScrollingOffset + fill(recycler, mLayoutState, state, false); ... final int scrolled = absDy &gt; consumed ? layoutDirection * consumed : dy; mOrientationHelper.offsetChildren(-scrolled); ...&#125; 如上文所讲到的fill()方法，作用就是向可绘制区间填充ItemView，那么在这里，可绘制区间就是滑动偏移量！再看方法mOrientationHelper.offsetChildren()作用就是平移ItemView。好了整个滑动过程就分析完成了，当然RecyclerView的滑动还有个特性叫平滑滑动（smooth scroll），其实它的实现就是一个fling滑动，所以就不再赘述了。 缓存逻辑前面的章节对于Recycler这个类相关的操作我们都直接进行了忽略，这里我们好好的来看下RecylerView是如何工作的。 与ListView不同，RecyclerView的缓存是分为多级的，但其实整个的缓存逻辑还是很容易理解的，Recycler的作用就是重用ItemView。在填充ItemView的时候，ItemView是从它获取的；滑出屏幕的ItemView是由它回收的。对于不同状态的ItemView存储在了不同的集合中，比如有scrapped、cached、exCached、recycled，当然这些集合并不是都定义在同一个类里。 public final class Recycler &#123; // 一级缓存 final ArrayList&lt;ViewHolder&gt; mAttachedScrap = new ArrayList&lt;&gt;(); ArrayList&lt;ViewHolder&gt; mChangedScrap = null; // 二级缓存 final ArrayList&lt;ViewHolder&gt; mCachedViews = new ArrayList&lt;ViewHolder&gt;(); // 三级缓存 private ViewCacheExtension mViewCacheExtension; // 四级缓存 RecycledViewPool mRecyclerPool;&#125; 回到之前的layoutChunk方法中，有行代码layoutState.next(recycler)，它的作用自然就是获取ItemView，我们进入这个方法查看，最终它会调用到RecyclerView.Recycler.getViewForPosition()方法： View getViewForPosition(int position, boolean dryRun) &#123; return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView;&#125; getViewForPosition 可以看到其实每次 rv 取出要显示的一个item本质上就是取出一个viewholder，根据viewholder上关联的itemview来展示这个item。而取出viewholder最核心的方法就是 tryGetViewHolderForPositionByDeadlineViewHolder tryGetViewHolderForPositionByDeadline(int position, boolean dryRun, long deadlineNs) &#123; // ... boolean fromScrapOrHiddenOrCache = false; ViewHolder holder = null; // 0) 先从 mChangedScrap 取viewholder（一级缓存） if (mState.isPreLayout()) &#123; holder = getChangedScrapViewForPosition(position); fromScrapOrHiddenOrCache = holder != null; &#125; // 1) 从mAttachedScrap(一级缓存) 或 mCachedViews（二级缓存）中取viewholder if (holder == null) &#123; holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun); if (holder != null) &#123; if (!validateViewHolderForOffsetPosition(holder)) &#123; // recycle holder (and unscrap if relevant) since it can't be used if (!dryRun) &#123; // we would like to recycle this but need to make sure it is not used by // animation logic etc. holder.addFlags(ViewHolder.FLAG_INVALID); if (holder.isScrap()) &#123; removeDetachedView(holder.itemView, false); holder.unScrap(); &#125; else if (holder.wasReturnedFromScrap()) &#123; holder.clearReturnedFromScrapFlag(); &#125; recycleViewHolderInternal(holder); &#125; holder = null; &#125; else &#123; fromScrapOrHiddenOrCache = true; &#125; &#125; &#125; if (holder == null) &#123; // ... stable ids的逻辑 // 3) 三级缓存 if (holder == null &amp;&amp; mViewCacheExtension != null) &#123; // We are NOT sending the offsetPosition because LayoutManager does not // know it. final View view = mViewCacheExtension .getViewForPositionAndType(this, position, type); if (view != null) &#123; holder = getChildViewHolder(view); if (holder == null) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view which does not have a ViewHolder\" + exceptionLabel()); &#125; else if (holder.shouldIgnore()) &#123; throw new IllegalArgumentException(\"getViewForPositionAndType returned\" + \" a view that is ignored. You must call stopIgnoring before\" + \" returning this view.\" + exceptionLabel()); &#125; &#125; &#125; if (holder == null) &#123; // fallback to pool // 4) 四级缓存 holder = getRecycledViewPool().getRecycledView(type); if (holder != null) &#123; holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) &#123; invalidateDisplayListInt(holder); &#125; &#125; &#125; if (holder == null) &#123; // ... // 这里会回调到 adapter的 onCreateViewHolder()方法 holder = mAdapter.createViewHolder(RecyclerView.this, type); // ... &#125; &#125; // 拿到holder之后会调用 tryBindViewHolderByDeadline 进行绑定 boolean bound = false; if (mState.isPreLayout() &amp;&amp; holder.isBound()) &#123; // do not update unless we absolutely have to. holder.mPreLayoutPosition = position; &#125; else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) &#123; if (DEBUG &amp;&amp; holder.isRemoved()) &#123; throw new IllegalStateException(\"Removed holder should be bound and it should\" + \" come here only in pre-layout. Holder: \" + holder + exceptionLabel()); &#125; final int offsetPosition = mAdapterHelper.findPositionOffset(position); // 下面方法会回调adapter的onBindViewHolder()方法 bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); &#125; //生成LayoutParams的代码 ... return holder.itemView;&#125; 获取View的逻辑可以整理成如下：根据列表位置获取ItemView，先后从scrapped、cached、exCached、recycled集合中查找相应的ItemView，如果没有找到，就创建（ Adapter.createViewHolder() ），最后与数据集绑定。 其中scrapped、cached和exCached集合定义在RecyclerView.Recycler中，分别表示将要在RecyclerView中删除的ItemView、一级缓存ItemView和二级缓存ItemView，cached集合的大小默认为２，exCached是需要我们通过RecyclerView.ViewCacheExtension自己实现的，默认没有； recycled集合其实是一个Map,private SparseArray&gt; mScrap = new SparseArray&gt;();，定义在RecyclerView.RecycledViewPool中，将ItemView以ItemType分类保存了下来，这里算是RecyclerView设计上的亮点，通过RecyclerView.RecycledViewPool可以实现在不同的RecyclerView之间共享ItemView，只要为这些不同RecyclerView设置同一个RecyclerView.RecycledViewPool就可以了。 上面解释了ItemView从不同集合中获取的方式，那么RecyclerView又是在什么时候向这些集合中添加ItemView的呢？下面我逐个介绍下。scrapped集合中存储的其实是正在执行REMOVE操作的ItemView，这部分会在后文进一步描述。在fill()方法的循环体中有行代码recycleByLayoutState(recycler, layoutState);，最终这个方法会执行到RecyclerView.Recycler.recycleViewHolderInternal()方法：void recycleViewHolderInternal(ViewHolder holder) &#123; ... if (holder.isRecyclable()) &#123; if (!holder.hasAnyOfTheFlags(ViewHolder.FLAG_INVALID | ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_UPDATE)) &#123; int cachedViewSize = mCachedViews.size(); if (cachedViewSize &gt;= mViewCacheMax &amp;&amp; cachedViewSize &gt; 0) &#123; recycleCachedViewAt(0); cachedViewSize --; &#125; if (cachedViewSize &lt; mViewCacheMax) &#123; mCachedViews.add(holder); cached = true; &#125; &#125; if (!cached) &#123; addViewHolderToRecycledViewPool(holder); recycled = true; &#125; &#125; ...&#125; View的回收并不像View的创建那么复杂，这里只涉及了两层缓存mCachedViews与mRecyclerPool，mCachedViews相当于一个先进先出的数据结构，每当有新的View需要缓存时都会将新的View存入mCachedViews，而mCachedViews则会移除头元素，并将头元素放入mRecyclerPool，所以mCachedViews相当于一级缓存，mRecyclerPool则相当于二级缓存，并且mRecyclerPool是可以多个RecyclerView共享的，这在类似于多Tab的新闻类应用会有很大的用处，因为多个Tab下的多个RecyclerView可以共用一个二级缓存。减少内存开销。 RecyclerView定义了4种针对数据集的操作，分别是ADD、REMOVE、UPDATE、MOVE，封装在了AdapterHelper.UpdateOp类中，并且所有操作由一个大小为30的对象池管理着。当我们要对数据集作任何操作时，都会从这个对象池中取出一个UpdateOp对象，放入一个等待队列中，最后调用RecyclerView.RecyclerViewDataObserver.triggerUpdateProcessor()方法，根据这个等待队列中的信息，对所有子控件重新测量、布局并绘制且执行动画。以上就是我们调用Adapter.notifyItemXXX()系列方法后发生的事。显然当我们对某个ItemView做操作时，它很有可以会影响到其它ItemView。下面我以REMOVE为例来梳理下这个流程。 首先调用Adapter.notifyItemRemove()，追溯到方法RecyclerView.RecyclerViewDataObserver.onItemRangeRemoved()：public void onItemRangeRemoved(int positionStart, int itemCount) &#123; assertNotInLayoutOrScroll(null); if (mAdapterHelper.onItemRangeRemoved(positionStart, itemCount)) &#123; triggerUpdateProcessor(); &#125;&#125; 这里的mAdapterHelper.onItemRangeRemoved()就是向之前提及的等待队列添加一个类型为REMOVE的UpdateOp对象， triggerUpdateProcessor()方法就是调用View.requestLayout()方法，这会导致界面重新布局，也就是说方法RecyclerView.onLayout()会随后调用，这之后的流程就和在绘制流程一节中所描述的一致了。 与AdapterView比较谈到RecyclerView，总避免不了与它的前辈AdapterView家族进行一撕，这里我整理了一下RecylerView与AdapterView的各自特点： 前面四点两位都提供了各自的实现，但也各有各自的特点： 点击事件ListView原生提供Item单击、长按的事件, 而RecyclerView则需要使用onTouchListener，相对自己实现会比较复杂。 分割线ListView可以很轻松的设置divider属性来显示Item之间的分割线，RecyclerView需要我们自己实现ItemDecoration，前者使用简单，后者可定制性强。 布局类型AdapterView提供了ListView与GridView两种类型，分别对应流式布局与网格式布局。RecyclerView提供了LinearLayoutManager、GridLayoutManager与之抗衡，相对而言，使用RecyclerView来进行更换布局方式更为轻松。只需要更换一个变量即可，而对于AdapterView而言则是需要更换一个View了。 缓存方式ListView使用了一个名为RecyclerBin的类负责试图的缓存，而Recycler则使用Recycler来进行缓存，原理上两者基本一致。RecyclerView：里面存储的不是View，而是ViewHolder 局部刷新这是一个很有用的功能，在ListView中我们想局部刷新某个Item需要自己来编写刷新逻辑，而在RecyclerView中我们可以通过 notifyItemChanged(position) 来刷新单个Item，甚至可以通过 notifyItemChanged(position, payload) 来传入一个payload信息来刷新单个Item中的特定内容。 动画作为视觉动物，我相信很多人喜欢RecylerView都和它简单的动画API有关，因为之前对ListView做动画比较困难，并且不舒服。 嵌套布局嵌套布局也是最近比较火的一个概念，RecyclerView实现了 NestedScrollingChild 接口，使得它可以和一些嵌套组件很好的工作。我们再来看ListView原生独有的几个特点： 头部与尾部的支持ListView原生支持添加头部与尾部，虽然RecyclerView可以通过定义不同的Type来做支持，但实际应用中，如果封装的不好，是很容易出问题的，因为Adapter中的数据位置与物理数据位置发生了偏移。 多选支持多选、单选也是ListView的一大长处，其实如果要我们自己在RecyclerView中去做支持还是需要不少代码量的。多数据源的支持ListView提供了CursorAdapter、ArrayAdapter，可以让我们很方便的从数据库或者数组中获取数据，这在测试的时候很有用。 总结综上，我们会发现RecycerView的最大特点就是灵活，正因为这种灵活，因此会牺牲了某些便利性。而AdapterView相对来讲就比较刻板，但它原生为我们提供了很多有用的方法来便于我们快速开发。ListView并不像当年的ActivityGroup，在Fragment出来后就被标记为Deprecated。两者目前还是一种互补的关系，起码在短时间内RecyclerView还并不能完全替代AdapterView，个人感觉原因有两个，一是目前太多的应用使用了ListView，并且ListView向RecyclerView转变也没有无损的方法。第二点，比如我就是想添加个头部，每个item带个点击事件这类简单的需求，ListView完全可以很轻松的胜任，没必要舍近求远来使用RecyclerView。因此，在实际应用中选择更适合自己的就好。 当然，从Google最近几次的更新来看，RecyclerView的进化还是很迅速的，而ListView则几乎没什么变动，所以RecyclerView绝对是大大的潜力股呀。 设计精巧的类在翻看RecycleView源码的过程中也遇见了许多之前没有注意过的类，这些类都可以复用在我们的日常工作当中。这里列举出其中具有代表性的几位。 Bucket如果一个对象有大量的是与非的状态需要表示，通常我们会使用BitMask 技术来节省内存，在 Java 中，一个 byte 类型，有 8 位（bit），可以表达 8 个不同的状态，而 int 类型，则有 32 位，可以表达 32 种状态。再比如Long类型，有64位，则可以表达64中状态。一般情况下使用一个Long已经足够我们使用了。但如果有不设上限的状态需要我们表示呢？在ChildHelper里有一个静态内部类Bucket，基本源码如下：static class Bucket &#123; final static int BITS_PER_WORD = Long.SIZE; final static long LAST_BIT = 1L &lt;&lt; (Long.SIZE - 1); long mData = 0; Bucket next; void set(int index) &#123; if (index &gt;= BITS_PER_WORD) &#123; ensureNext(); next.set(index - BITS_PER_WORD); &#125; else &#123; mData |= 1L &lt;&lt; index; &#125; &#125; ...&#125; 可以看到，Bucket是一个链表结构，当index大于64的时候，它便会去下一个Bucket去寻找，所以，Bucket可以不设上限的表示状态。 Pools熟悉Message回收机制的朋友可能了解，在使用Message对象时最好通过 Message.obtain() 方法来获取，这样可以在很多情况下避免创建新对象。在使用完之后调用 message.recycle() 来回收消息。谷歌为这种机制也提供了抽象的实现,就是位于v4包下Pools类, 内部接口Pool提供了 acquire 与 release 两个方法,不过需要注意的是这个 acquire 方法可能返回空,毕竟Pools不是业务类,它不应该清楚对象的具体创建逻辑.还有一点是Pools与Message类的实现机制不同,每个Message对象内部都持有一个引用下一个message的指针,相当于一个链表结构,而Pool的实现类 SimplePool 中使用的是数组.Pool机制在 RecycleView 中有如下几处应用： RecycleView将item的增删改封装为 UpdateOp 类。ViewInfoStore 类中静态内部类 InfoRecord 。 总结RecyclerView也不是万能的，它的灵活性也是有一定限制的，比如我就遇到了一不是很好解决的问题：Recyler的缓存级别是一个Item的整个View，而我们没办法自定义缓存级别，这样说比较抽象，举个例子，我的某些Item的某个子View加载很耗时，所以我希望我在上下滑动的时候，Item的其它View是可以被回收利用的，但这个加载很耗时的View是不要重复使用的。即我希望用空间换取时间来获取滑动的流畅性。当然，这样的需求不常见，RecyclerView也不能很好的满足这一点。 RecyclerView也应该算作一个明星控件了，自从其诞生开始就备受欢迎，仔细的学习也能让我们在工作中更容易的、更恰当的使用。本文也只是分析了RecyclerView的一部分，关于动画、滑动、嵌套滑动等等还需要大家自行去研究。有兴趣的可以看看RecyclerView 和 ListView 使用对比分析 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/05/31/RecyclerView-source-code/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"},{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"RecyclerView 中的设计模式","slug":"RecyclerView-Design-Pattern","date":"2019-05-29T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/05/30/RecyclerView-Design-Pattern/","link":"","permalink":"http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/","excerpt":"本篇文章是在掘金上偶然看到，介绍的比较全面，收藏到本博客\nRecyclerview 在 Android 应用开发中使用非常频繁，但一般人只知道onCreateViewHolder、onBindViewHolder等简单使用。了解这篇文章无论是对项目中实际开发还是Android源码设计，都会有借鉴和帮助\nRecyclerview 源码中用到的设计模式本文通过桥接,组合,适配器,观察者模式四种设计模式来解读RecyclerView。","text":"本篇文章是在掘金上偶然看到，介绍的比较全面，收藏到本博客 Recyclerview 在 Android 应用开发中使用非常频繁，但一般人只知道onCreateViewHolder、onBindViewHolder等简单使用。了解这篇文章无论是对项目中实际开发还是Android源码设计，都会有借鉴和帮助 Recyclerview 源码中用到的设计模式本文通过桥接,组合,适配器,观察者模式四种设计模式来解读RecyclerView。 通过桥接模式，使RecyclerView 将布局方式独立成LayoutManager，实现对布局的定制化。 通过组合模式，使RecycleView通过dispatchLayout对Item View进行布局绘制的。 通过适配器模式，ViewHolder将RecycleView与ItemView联系起来，使得RecycleView方便操作ItemView。 通过观察者模式，给ViewHolder注册观察者，当调用notifyDataSetChanged时，就能重新绘制。 设计思路RecyclerView官网给出的定义是: A flexible view for providing a limited window into a large data set. ，也就是在限定的视图内展示大量的数据，来一张通俗明了的图： RecyclerView的职责就是将Datas中的数据以一定的规则展示在它的上面，但说破天RecyclerView只是一个ViewGroup，它只认识View，不清楚Data数据的具体结构，所以两个陌生人之间想构建通话，我们很容易想到适配器模式,因此，RecyclerView需要一个Adapter(适配器模式)来与Datas进行交流： 如上如所示，RecyclerView表示只会和ViewHolder进行接触，而Adapter的工作就是将Data转换为RecyclerView认识的ViewHolder，因此RecyclerView就间接地认识了Datas。 事情虽然进展愉快，但RecyclerView是个很懒惰的人，尽管Adapter已经将Datas转换为RecyclerView所熟知的View，但RecyclerView并不想自己管理些子View，因此，它雇佣了一个叫做LayoutManager的大祭司来帮其完成布局(桥接模式)，现在，图示变成下面这样： 如上图所示，LayoutManager协助RecyclerView来完成布局。但LayoutManager这个大祭司也有弱点，就是它只知道如何将一个一个的View布局在RecyclerView上，但它并不懂得如何管理这些View，如果大祭司肆无忌惮的玩弄View的话肯定会出事情，所以，必须有个管理View的护法，它就是Recycler，LayoutManager在需要View的时候回向护法进行索取，当LayoutManager不需要View(试图滑出)的时候，就直接将废弃的View丢给Recycler，图示如下： 到了这里，有负责翻译数据的Adapter，有负责布局的LayoutManager，有负责管理View的Recycler，一切都很完美，但RecyclerView乃何等神也，它下令说当子View变动的时候姿态要优雅(动画)，所以用雇佣了一个舞者ItemAnimator(观察者模式)，因此，舞者也进入了这个图示: 如上，我们就是从宏观层面来对RecylerView有个大致的了解，可以看到，RecyclerView作为一个View，它只负责接受用户的各种讯息，然后将信息各司其职的分发出去。接下来我们将深入源码，详细讲解用到的设计模式，看看RecyclerView都是怎么来操作各个组件工作的。 桥接模式详解模式的定义将抽象部分与实现部分分离，使它们都可以独立的变化。 模式的使用场景如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性，避免在两个层次之间建立静态的联系。设计要求实现化角色的任何改变不应当影响客户端，或者实现化角色的改变对客户端是完全透明的。需要跨越多个平台的图形和窗口系统上。一个类存在两个独立变化的维度，且两个维度都需要进行扩展。 UML类图 角色介绍抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。 修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接 口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。具体实现化(ConcreteImplementor)角色：这个角色给出实现化角色接口的具体实现。 模式的简单实现其实Java的虚拟机就是一个很好的例子，在不同平台平台上，用不同的虚拟机进行实现，这样只需把Java程序编译成符合虚拟机规范的文件，且只用编译一次，便在不同平台上都能工作。 但是这样说比较抽象，用一个简单的例子来实现bridge模式。 编写一个程序，使用两个绘图的程序的其中一个来绘制矩形或者原型，同时，在实例化矩形的时候，它要知道使用绘图程序1（DP1）还是绘图程序2（DP2）。 (ps:假设dp1和dp2的绘制方式不一样，它们是用不同方式进行绘制，示例代码，不讨论过多细节) 实现源码首先是两个绘图程序dp1,dp2//具体的绘图程序类dp1public class DP1 &#123; public void draw_1_Rantanle()&#123; System.out.println(\"使用DP1的程序画矩形\"); &#125; public void draw_1_Circle()&#123; System.out.println(\"使用DP1的程序画圆形\"); &#125;&#125;//具体的绘图程序类dp2public class DP2 &#123; public void drawRantanle()&#123; System.out.println(\"使用DP2的程序画矩形\"); &#125; public void drawCircle()&#123; System.out.println(\"使用DP2的程序画圆形\"); &#125;&#125; 接着​抽象的形状Shape和两个派生类：矩形Rantanle和圆形Circle//抽象化角色Abstractionabstract class Shape &#123; //持有实现的角色Implementor(作图类) protected Drawing myDrawing; public Shape(Drawing drawing) &#123; this.myDrawing = drawing; &#125; abstract public void draw(); //保护方法drawRectangle protected void drawRectangle()&#123; //this.impl.implmentation() myDrawing.drawRantangle(); &#125; //保护方法drawCircle protected void drawCircle()&#123; //this.impl.implmentation() myDrawing.drawCircle(); &#125;&#125;//修正抽象化角色Refined Abstraction(矩形)public class Rantangle extends Shape&#123; public Rantangle(Drawing drawing) &#123; super(drawing); &#125; @Override public void draw() &#123; drawRectangle(); &#125;&#125;//修正抽象化角色Refined Abstraction(圆形)public class Circle extends Shape &#123; public Circle(Drawing drawing) &#123; super(drawing); &#125; @Override public void draw() &#123; drawCircle(); &#125;&#125; 最后，我们的实现绘图的Drawing和分别实现dp1的V1Drawing和dp2的V2Drawing//实现化角色Implementor//implmentation两个方法，画圆和画矩形public interface Drawing &#123; public void drawRantangle(); public void drawCircle();&#125;//具体实现化逻辑ConcreteImplementor//实现了接口方法，使用DP1进行绘图public class V1Drawing implements Drawing&#123; DP1 dp1; public V1Drawing() &#123; dp1 = new DP1(); &#125; @Override public void drawRantangle() &#123; dp1.draw_1_Rantanle(); &#125; @Override public void drawCircle() &#123; dp1.draw_1_Circle(); &#125; &#125;//具体实现化逻辑ConcreteImplementor//实现了接口方法，使用DP2进行绘图public class V2Drawing implements Drawing&#123; DP2 dp2; public V2Drawing() &#123; dp2 = new DP2(); &#125; @Override public void drawRantangle() &#123; dp2.drawRantanle(); &#125; @Override public void drawCircle() &#123; dp2.drawCircle(); &#125;&#125; 在这个示例中，图形Shape类有两种类型，圆形和矩形，为了使用不同的绘图程序绘制图形，把实现的部分进行了分离，构成了Drawing类层次结构，包括V1Drawing和V2Drawing。在具体实现类中，V1Drawing控制着DP1程序进行绘图，V2Drawing控制着DP2程序进行绘图，以及保护的方法drawRantangle,drawCircle(Shape类中) 。 组合模式详解模式的定义组合模式(Composite Pattern)又叫作部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。 GoF在《设计模式》一书中这样定义组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。 模式的使用场景表示对象的部分-整体层次结构。从一个整体中能够独立出部分模块或功能的场景。 UML类图 角色分析Component抽象构件角色 ：定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性。Leaf叶子构件 : 叶子对象，其下再也没有其他的分支。Composite树枝构件 ：树枝对象，它的作用是组合树枝节点和叶子节点形成一个树形结构。 该模式的实现实例抽象构件 Component.java：public abstract class Component &#123; //个体和整体都具有的共享 public void doSomething()&#123; //业务逻辑 &#125;&#125; 树枝构件 Composite.javapublic class Composite extends Component &#123; //构件容器 private ArrayList componentArrayList = new ArrayList(); //增加一个叶子构件或树枝构件 public void add(Component component)&#123; this.componentArrayList.add(component); &#125; //删除一个叶子构件或树枝构件 public void remove(Component component)&#123; this.componentArrayList.remove(component); &#125; //获得分支下的所有叶子构件和树枝构件 public ArrayList getChildren()&#123; return this.componentArrayList; &#125; &#125; 树叶构件 Leaf.javapublic class Leaf extends Component &#123; //可以覆写父类方法 public void doSomething()&#123; &#125;&#125; 场景类 Client.javapublic class Client &#123; public static void main(String[] args) &#123; //创建一个根节点 Composite root = new Composite(); root.doSomething(); //创建一个树枝构件 Composite branch = new Composite(); //创建一个叶子节点 Leaf leaf = new Leaf(); //建立整体 root.add(branch); branch.add(leaf); &#125; //通过递归遍历树 public static void display(Composite root)&#123; for(Component c:root.getChildren())&#123; if(c instanceof Leaf)&#123; //叶子节点 c.doSomething(); &#125;else&#123; //树枝节点 display((Composite)c); &#125; &#125; &#125;&#125; 适配器模式详解7种结构型模式：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。其中对象的适配器模式是各种模式的起源，我们看下面的图： 适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。首先，我们来看看类的适配器模式，先看类图： 类的适配器模式 核心思想就是：有一个Source类，拥有一个方法，待适配，目标接口时Targetable，通过Adapter类，将Source的功能扩展到Targetable里，看代码：public class Source &#123; public void method1() &#123; System.out.println(\"this is original method!\"); &#125; &#125; public interface Targetable &#123; /* 与原类中的方法相同 */ public void method1(); /* 新类的方法 */ public void method2(); &#125; public class Adapter extends Source implements Targetable &#123; @Override public void method2() &#123; System.out.println(\"this is the targetable method!\"); &#125; &#125; Adapter类继承Source类，实现Targetable接口，下面是测试类：public class AdapterTest &#123; public static void main(String[] args) &#123; Targetable target = new Adapter(); target.method1(); target.method2(); &#125; &#125; 对象的适配器模式基本思路和类的适配器模式相同，只是将Adapter类作修改，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。看图： 只需要修改Adapter类的源码即可：public class Wrapper implements Targetable &#123; private Source source; public Wrapper(Source source)&#123; super(); this.source = source; &#125; @Override public void method2() &#123; System.out.println(\"this is the targetable method!\"); &#125; @Override public void method1() &#123; source.method1(); &#125; &#125; 测试类：public class AdapterTest &#123; public static void main(String[] args) &#123; Source source = new Source(); Targetable target = new Wrapper(source); target.method1(); target.method2(); &#125; &#125; 接口的适配器模式接口的适配器是这样的：有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的所有方法，这明显有时比较浪费，因为并不是所有的方法都是我们需要的，有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们需要的方法就行。看一下类图： 这个很好理解，在实际开发中，我们也常会遇到这种接口中定义了太多的方法，以致于有时我们在一些实现类中并不是都需要。看代码：public interface Sourceable &#123; public void method1(); public void method2(); &#125; 抽象类Wrapper2：public abstract class Wrapper2 implements Sourceable&#123; public void method1()&#123;&#125; public void method2()&#123;&#125; &#125; public class SourceSub1 extends Wrapper2 &#123; public void method1()&#123; System.out.println(\"the sourceable interface's first Sub1!\"); &#125; &#125; public class SourceSub2 extends Wrapper2 &#123; public void method2()&#123; System.out.println(\"the sourceable interface's second Sub2!\"); &#125; &#125; public class WrapperTest &#123; public static void main(String[] args) &#123; Sourceable source1 = new SourceSub1(); Sourceable source2 = new SourceSub2(); source1.method1(); source1.method2(); source2.method1(); source2.method2(); &#125; &#125; 讲了这么多，总结一下三种适配器模式的应用场景： 类的适配器模式：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。 对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。 接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。 观察者模式详解观察者模式（Observer）是类和类之间的关系，不涉及到继承，学的时候应该记得归纳。观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。先来看看关系图： 我解释下这些类的作用：MySubject类就是我们的主对象，Observer1和Observer2是依赖于MySubject的对象，当MySubject变化时，Observer1和Observer2必然变化。AbstractSubject类中定义着需要监控的对象列表，可以对其进行修改：增加或删除被监控对象，且当MySubject变化时，负责通知在列表内存在的对象。我们看实现代码： 一个Observer接口：public interface Observer &#123; public void update(); &#125; 两个实现类：public class Observer1 implements Observer &#123; @Override public void update() &#123; System.out.println(\"observer1 has received!\"); &#125; &#125; public class Observer2 implements Observer &#123; @Override public void update() &#123; System.out.println(\"observer2 has received!\"); &#125; &#125; Subject接口及实现类：public interface Subject &#123; /*增加观察者*/ public void add(Observer observer); /*删除观察者*/ public void del(Observer observer); /*通知所有的观察者*/ public void notifyObservers(); /*自身的操作*/ public void operation(); &#125; public abstract class AbstractSubject implements Subject &#123; private Vector vector = new Vector(); @Override public void add(Observer observer) &#123; vector.add(observer); &#125; @Override public void del(Observer observer) &#123; vector.remove(observer); &#125; @Override public void notifyObservers() &#123; Enumeration enumo = vector.elements(); while(enumo.hasMoreElements())&#123; enumo.nextElement().update(); &#125; &#125; &#125; public class MySubject extends AbstractSubject &#123; @Override public void operation() &#123; System.out.println(\"update self!\"); notifyObservers(); &#125; &#125; 测试类：public class ObserverTest &#123; public static void main(String[] args) &#123; Subject sub = new MySubject(); sub.add(new Observer1()); sub.add(new Observer2()); sub.operation(); &#125; &#125; 这些东西，其实不难，只是有些抽象，不太容易整体理解，还有就是门面模式，适配器模式，桥接模式有些同学觉得都差不多，其实大不一样，但都是结构型模式。 Facade（门面模式）出现较多是这样的情况,你有一个复杂的系统,对应了各种情况,客户看了说功能不错,但是使用太麻烦.你说没问题,我给你提供一个统一的门面.所以Facade使用的场合多是对系统的”优化”. Adapter出现是这样的情况,你有一个类提供接口A,但是你的客户需要一个实现接口B的类,这个时候你可以写一个Adapter让把A接口变成B接口,所以Adapter使用的场合是指鹿为马.就是你受夹板气的时候,一边告诉你我只能提供给你A(鹿),一边告诉你说我只要B(马),他长了四条腿,你没办法了,把鹿牵过去说,这是马,你看他有四条腿.(当然实现指鹿为马也有两种方法,一个方法是你只露出鹿的四条腿,说你看这是马,这种方式就是封装方式的Adapter实现,另一种方式是你把鹿牵过去,但是首先介绍给他说这是马,因为他长了四条腿这种是继承的方式.) Bridge在一般的开发中出现的情况并不多,AWT是一个,SWT也算部分是,如果你的客户要求你开发一个系统,这个系统在Windows下运行界面的样子是Windows的样子.在Linux下运行是Linux下的样子.在Macintosh下运行要是Mac Os的样子.怎么办? 定义一系列的控件Button,Text,radio,checkBox等等.供上层开发者使用,他们使用这些控件的方法,利用这些控件构造一个系统的GUI,然后你为这些控件写好Linux的实现,让它在Linux上调用Linux本地的对应控件,在Windows上调用Windows本地的对应控件,在Macintosh上调用Macintosh本地的对应控件ok,你的任务完成了. 篇幅有限本文只介绍了Recyclerview源码中应用到的几种设计模式，下一篇文章会继续介绍Recyclerview源码 Ref 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"RecyclerView","slug":"recyclerview","permalink":"http://agehua.github.io/tags/recyclerview/"}]},{"title":"TCP三次握手解读","slug":"TCP-Three-way-Handshake","date":"2019-05-26T16:00:00.000Z","updated":"2024-12-05T09:41:56.283Z","comments":true,"path":"2019/05/27/TCP-Three-way-Handshake/","link":"","permalink":"http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/","excerpt":"本篇文章节选自知乎问答，部分图片来自网络，文末已给出链接\n网络上\b有很多关于TCP三次握手的解读和类比，这些都是不全面的，如下：\n\n三次握手：“喂，你听得到吗？”“我听得到呀，你听得到我吗？”“我能听到你，今天 balabala……”","text":"本篇文章节选自知乎问答，部分图片来自网络，文末已给出链接 网络上\b有很多关于TCP三次握手的解读和类比，这些都是不全面的，如下： 三次握手：“喂，你听得到吗？”“我听得到呀，你听得到我吗？”“我能听到你，今天 balabala……” SYN、ACT是TCP封包中的控制单元，但其实过程中省略了其他封包内容，例如： 上面的例子错误，就是因为忽略了SEQ内容。看完下面内容，你就会明白为什么了。 三次握手的误解与错误类比(RFC解读)如果你细读RFC793，也就是 TCP 的协议 RFC，你就会发现里面就讲到了为什么三次握手是必须的——TCP 需要 seq 序列号来做可靠重传或接收，而避免连接复用时无法分辨出 seq 是延迟或者是旧链接的 seq，因此需要三次握手来约定确定双方的 ISN（初始 seq 序列号）。 下面给出详细的 RFC 解读说明：（数据分组称为分段（Segment），国内通常用包来称呼） 我们首先要知道到一点就是， TCP 的可靠连接是靠 seq（ sequence numbers 序列号）来达成的。 A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. TCP 设计中一个基本设定就是，通过TCP 连接发送的每一个包，都有一个sequence number。而因为每个包都是有序列号的，所以都能被确认收到这些包。确认机制是累计的，所以一个对sequence number X 的确认，意味着 X 序列号之前(不包括 X) 包都是被确认接收到的。 The protocol places no restriction on a particular connection being used over and over again. The problem that arises from this is – “how does the TCP identify duplicate segments from previous incarnations of the connection?” This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished. TCP 协议是不限制一个特定的连接（两端 socket 一样）被重复使用的。所以这样就有一个问题：这条连接突然断开重连后，TCP 怎么样识别之前旧链接重发的包？——这就需要独一无二的 ISN（初始序列号） 机制。 When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN’s will be unique. 当一个新连接建立时，初始序列号（ initial sequence number ISN）生成器会生成一个新的32位的 ISN。 这个生成器会用一个32位长的时钟，差不多4µs 增长一次，因此 ISN 会在大约 4.55 小时循环一次（2^32位的计数器，需要2^324 µs才能自增完，除以1小时共有多少µs便可算出2^324 /(1606010001000)=4.772185884 ） 而一个段在网络中并不会比最大分段寿命（Maximum Segment Lifetime (MSL) ，默认使用2分钟）长，MSL 比4.55小时要短，所以我们可以认为 ISN 会是唯一的。 发送方与接收方都会有自己的 ISN （下面的例子中就是 X 与 Y）来做双方互发通信，具体的描述如下： 1 A –&gt; B SYN my sequence number is X2 A &lt;– B ACK your sequence number is X3 A &lt;– B SYN my sequence number is Y4 A –&gt; B ACK your sequence number is Y 2与3都是 B 发送给 A，因此可以合并在一起，因此成为three way (or three message) handshake（其实翻译为三步握手，或者是三次通信握手更为准确） 因此最终可以得出，三次握手是必须的： A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN’s. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3]. 三次握手（A three way handshake）是必须的， 因为 sequence numbers（序列号）没有绑定到整个网络的全局时钟（全部统一使用一个时钟，就可以确定这个包是不是延迟到的）以及 TCPs 可能有不同的机制来选择 ISN（初始序列号）。 接收方接收到第一个 SYN 时，没有办法知道这个 SYN 是是否延迟了很久了，除非他有办法记住在这条连接中，最后接收到的那个sequence numbers（然而这不总是可行的）。 这句话的意思是：一个 seq 过来了，跟现在记住的 seq 不一样，我怎么知道他是上条延迟的，还是上上条延迟的呢？ 所以，接收方一定需要跟发送方确认 SYN。 假设不确认 SYN 中的 SEQ，那么就只有： 1 A –&gt; B SYN my sequence number is X2 A &lt;– B ACK your sequence number is X SYN my sequence number is Y 只有B确认了收到了 A 的 SEQ， A 无法确认收到 B 的。也就是说，只有 A 发送给 B 的包都是可靠的， 而 B 发送给 A 的则不是，所以这不是可靠的连接。这种情况如果只需要 A 发送给 B ，B 无需回应，则可以不做三次握手。 所以，正确的类比应该是这样的： TCP 传递信息可以理解为美国与中国用货船来传货物，但因为一首轮船穿放不下，货物要分开一只只轮船来发货。所以需要一个序列号来识别该货物是第几个，以便到达后将其拼接回原来的货物。因为同一条航道（也就是 tcp连接）上，可能会有多批货物发送（复用 tcp 连接）。发货时，双方需要通知对方这个序列号是从哪里开始（init seq）的，这样才能辨识过来的是不是一个对的货物，以及能拼接成完整的货物。 货物运输拼接（tcp）最重要的是可靠性，如果没有用三次握手来确认双方都可以获得对方的 序列号（seq）的话，就无法知道当前航班（连接）中，对的货物序号是怎么样的了。 三次握手详细过程 TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT –&gt; &lt;SEQ=100&gt;&lt;CTL=SYN&gt; –&gt; SYN-RECEIVED 3. ESTABLISHED &lt;– &lt;SEQ=300&gt;&lt;ACK=101&gt;&lt;CTL=SYN,ACK&gt; &lt;– SYN-RECEIVED 4. ESTABLISHED –&gt; &lt;SEQ=101&gt;&lt;ACK=301&gt;&lt;CTL=ACK&gt; –&gt; ESTABLISHED 5. ESTABLISHED –&gt; &lt;SEQ=101&gt;&lt;ACK=301&gt;&lt;CTL=ACK&gt;&lt;DATA&gt; –&gt; ESTABLISHED Basic 3-Way Handshake for Connection SynchronizationFigure 7. 在上图 第二行中， A 发送了 SEQ 100，标志位是 SYN. 第三行，B 发回了 ACK 101 与 SEQ 300，标志位是 SYN 与 ACK（两个过程合并了）。注意，ACK 是101意味着，B 希望接收到 101序列号开始的数据段。 第四行，A 返回了空的数据，SEQ 101， ACK 301，标志位为 ACK。至此，双方的开始 SEQ （也就是 ISN）号100与300都被确认接收到了。 第五行，开始正式发送数据包，注意的是 ACK 依旧是第四行的301，因为没有需要 ACK 的 SYN 了（第四行已经 ACK 完）。 以上，4 最后这个确认的过程，是可以带上数据的。 The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.To deal with this, a special control message, reset, has been devised.If the receiving TCP is in a non-synchronized state (i.e., SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user. We discuss this latter case under “half-open” connections below. 三次握手的原则设计是防止旧复用链接的初始化导致问题，为了解决此问题，我们设计了reset这个特别的控制信号来处理。 如果接收中的 TCP 在一个未同步状态如 SYN-SENT, SYN-RECEIVED，它会返回 reset 给对方。 如果 TCP 是同步状态中如(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT)，他会终止此连接并通知用户。 看起来有点绕，我们举个图例看看： TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT –&gt; &lt;SEQ=100&gt;&lt;CTL=SYN&gt; … 3. (duplicate) … &lt;SEQ=90&gt;&lt;CTL=SYN&gt; –&gt; SYN-RECEIVED 4. SYN-SENT &lt;– &lt;SEQ=300&gt;&lt;ACK=91&gt;&lt;CTL=SYN,ACK&gt; &lt;– SYN-RECEIVED 5. SYN-SENT –&gt; &lt;SEQ=91&gt;&lt;CTL=RST&gt; –&gt; LISTEN 6. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&emsp;&emsp;&emsp;&emsp; … &lt;SEQ=100&gt;&lt;CTL=SYN&gt; –&gt; SYN-RECEIVED 7. SYN-SENT &lt;– &lt;SEQ=400&gt;&lt;ACK=101&gt;&lt;CTL=SYN,ACK&gt; &lt;– SYN-RECEIVED 8. ESTABLISHED –&gt; &lt;SEQ=101&gt;&lt;ACK=401&gt;&lt;CTL=ACK&gt; –&gt; ESTABLISHED Recovery from Old Duplicate SYN 这是 复用连接时，旧在途包发往新连接中的例子。 3中，一个旧的重复的 SYN到达 B。 4中， B分别不出是否旧的，照样子正常回包。 5中，A检测到 B 返回的ACK不正确，所以返回 RST(reset) 6中，B接收到 RST(reset)信号，于是变成 LISTEN 状态。 7中，新连接正常的 SYN终于到达了，三次握手正常进行。 这种是简化的情况，但是可以看出 TCP 是如何处理复用旧链接的包到达的。 RefTCP 为什么是三次握手，而不是两次或四次？ TCP 三向交握 (Three-way Handshake) 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"TCP","slug":"tcp","permalink":"http://agehua.github.io/tags/tcp/"}]},{"title":"Android App Bundle(AAB) 文件介绍","slug":"Android-APP-Bundles-Introduction","date":"2019-03-26T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/03/27/Android-APP-Bundles-Introduction/","link":"","permalink":"http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/","excerpt":"在2018年的Google I/O大会上，Google向 Android 引入了新 App 动态化框架（即Android App Bundle，缩写为AAB）","text":"在2018年的Google I/O大会上，Google向 Android 引入了新 App 动态化框架（即Android App Bundle，缩写为AAB） 关于Android App BundlesAndroid App Bundle 是一种包含编译后代码和资源文件的新的上传格式（.aab），它推迟了APK的生成和签名，由google play来完成 Google Play推出新app交付模式，叫做动态交付 (Dynamic Delivery)，它根据每个用户的设备信息，使用开发者上传的app bundle来生成对应的apk文件使用aab文件会将apk的大小限制增加到500MB，这个限制不是指aab文件的大小，而是下载apk时的大小此外，也可以在app bundle中添加dynamic feature modules。这些模块可以包含新的功能和资源。开发者可以决定用户第一次安装时需不需要下载这些资源构建一个Android App Bundle，只需要几次点击，但是添加dynamic feature模块，可能需要重构整个项目 Android App Bundle != APKApp Bundle 纯粹是为了上传设计的文件，用户无法直接安装和使用它。它是一个 zip 文件，Google Play 从中生成优化的 APK 并将其提供给设备进行安装从 APK 切换到App Bundle是一个无缝过程 Get started构建 app bundles和支持动态交付，需要下面几步： 1.Android Studio 3.2 or higher 2.支持动态交付，需要包含一个base module，重新组织代码和资源，生成configuration APKs，此外可以添加 dynamic feature模块 3.生成 aab 文件（使用 AS 或 命令行工具） 4.使用 bundletool 来测试aab生成apk或发布到测试机上 5.使用 Google Play 应用签名要使用推荐的应用发布格式 Android App Bundle，您需要先注册 Google Play 应用签名，然后才能在 Play Console上传您的 app bundle 文件。 6.上传Play Console Split APKsSplit APKs是Android 5.0开始提供多apk构建机制，是 Dynamic Delivery 功能的最基本组件。 Split APKs将原来一个APK中多个模块共享同一份资源的模型，分离成多个APK使用各自的资源，并且可以继承Base APK中的资源，多个APK有相同的data，cache目录，多个dex文件，相同的进程，在Settings.apk中只显示一个APK，并且使用相同的包名。 Split APK可以将一个庞大的APK，按屏幕密度，ABI等形式拆分成多个独立的APK，在应用程序更新时，不必下载整个APK，只需单独下载某个模块即可安装更新。 Base apks: 包含了一些基本功能，和其他split apks公用的资源和代码。Google play从你的项目的 app module来生成base apk。当用户请求下载完整apk时，base apk是第一个被下载和安装的。 如果你想减少初始下载的大小，那就需要减少你的 app module 的代码 Configuration apks: 包括不同的 native 代码，特定屏幕尺寸，CPU架构或者多语言。每当用户要下载这个应用的时候，只会下载真正对应其设备信息的apk。配置apk不用单独的新建 module，google play会自动生成对应apk Dynamic feature apks: 每个apk包含一个特性，对应一个module。Play Core Library负责为用户按需安装这些特性。这个 Dynamic feature 不是第一次安装需要的，Google play 从Dynamic feature module来生成动态特性apk文件 下图描述了为了提供一个完整app体验，Split Apks产生的依赖结构，并可能会在同一个设备上安装多个apk文件。 Devices running Android 4.4 (API level 19) and lowerAndroid 4.4 及以下设备并不支持下载和安装Split APKs。 Google Play提供一个根据设备信息优化后的apk文件，叫做multi-APK对于多语言，multi-APK会包含所有支持的语音，避免切换手机语言后还要下载对应语言的apk问题multi-APK不支持按需下载动态特性（dynamic features），所以在创建dynamic features模块的时候，需要考虑是否禁用按需下载或打开Fusing The Android App Bundle formatAndroid App Bundle 是一种发布格式 —— 精确地说，是一个带有 .aab 扩展名的 zip 文件。它包含应用支持的所有设备的代码和资源，例如 DEX 文件、本地代码库、清单文件、各种资源文件等 注意：每个APP bundle对应一个独立的app或applicationID。因此，如果你使用了product flavors来创建不同版本的app，并且每个版本app都对应一个不同的applicationID，那你就需要为每个app构建一个app bundle 蓝色方框区域就是configuration apks支持的配置项 Play Core LibraryPlay Core Library是AAB提供的核心库，用于下载、安装dynamic feature模块。Android studio3.3 开始也支持为 Instant apps 按需下载模块 在Android Studio上选择 New -&gt; Module -&gt; 选择 Instant Dynamic Feature Module，会自动创建一个 Instant Module，对应的 AndroidManifest.xml 文件内容如下：&lt;manifest xmlns:android=\"http://schemas.android.com/apk/res/android\" xmlns:dist=\"http://schemas.android.com/apk/distribution\" package=\"com.google.android.samples.instantdynamicfeatures\"&gt; &lt;!-- The dist:instant=\"true\" makes this module instant enabled. Assuming the \"app\" module is also instant enabled, when this bundle is uploaded to the instant track on the Google Play Developer Console, this module will be included in the instant app. Any non instant enabled modules will be excluded --&gt; &lt;dist:module dist:instant=\"true\" dist:onDemand=\"false\" dist:title=\"@string/module_instant_feature_split_install\"&gt; &lt;dist:fusing dist:include=\"true\" /&gt; &lt;/dist:module&gt; &lt;application&gt; &lt;activity android:name=\"com.google.android.samples.instantdynamicfeatures.SplitInstallInstantActivity\"&gt;&lt;/activity&gt; &lt;/application&gt;&lt;/manifest&gt; Bundletool 介绍Bundletool 是一个用于处理 Android App Bundle 的命令行工具。使用 bundletool，您可以构建 AAB，提取连接的设备配置，生成 APK Set 文件 (.apks)，从 APK Set 文件中提取或安装 APK，以及验证App Bundle。由于 AAB 仅是一种发布格式，因此 bundletool 用于生成和测试 APK。 用Bundletool工具测试AAB 1.安装bundletool： brew install bundletool 2.切换到aab所在文件夹，生成 apks 文件bundletool build-apks --bunlde=&lt;bundle_name&gt;.aab --output=./&lt;bundle_name&gt;.apks 3.如果要build签名的apks文件，则需要加上keystore设置bundletool build-apks --bundle=&lt;bundle_name&gt;.aab --output=&lt;bundle_name&gt;.apks --ks=&lt;your_keystorename&gt;.jks/.keystore --ks-pass=pass:&lt;your_keystore_pass&gt; --ks-key-alias=&lt;your_keystore_alias&gt; --key-pass=pass:&lt;your_keystore_pass&gt; 4.将apks安装在设备上bundletool install-apks --apks=&lt;bundle_name&gt;.apks 另外介绍两个有用的功能： 输出当前设备对应的设备信息bundletool get-device-spec --output=tcl.json --adb=/Library/Android_sdk/platform-tools/adb 生成当前设备对应的apksbundletool build-apks --connected-device --bundle=app.aab --output=./app1.apks --adb=/Library/Android_sdk/platform-tools/adb Compressed download size restriction App首次下载安装，整个app（比如 base.apk+configuration.apk）大小不能超过 150MB 后续按需下载，每次也不能超过150MB Android App Bundles不支持apk扩展文件（*.obb） OBB（Opaque Binary Blob）文件格式，是安卓游戏通用数据包。在一些大型游戏上较为常见，同时还附以Data文件，亦或是md5.dat文件出现。通常在游戏开始前，程序会自动将obb解包/sdcard/Android/obb 目录下。但也有游戏不会解包，直接读取。 Merits and demeritsBenifit of App Bundle Size更小（最高可以减少50%应用体积） 安装更快 （ base.apk + split apks） Android App Bundle 是单一工件，因此无需构建、签名或管理多个 APK 支持动态发布(为特定用户添加动态功能，而无需增加安装时的应用体积) 官方提供的系统级插件化方案 Limitations and costs 仅限于通过 Google Play 发布的应用，（Google进一步巩固自身生态） 需要加入到 Google 的 beta program 最低支持版本Android 5.0 (API level 21) 低于Android 5.0 (API level 21) 的版本GooglePlay会优化Size，但不支持动态交付。 需要升级到Android Studio 3.2以上，修改工程结构以便支持App Bundle格式 集成Play Core Library Known issues 不支持动态修改resource tables 在dynamic feature 模块的清单文件里，不能引用不在base模块里的资源 在AS中，更改base模块的 build variant，并不会自动更改依赖base的其他模块，所以构建时可能会报错 不同模块 build configuration 不同，可能会有冲突，导致构建或运行时出错，比如 buildTypes.release.debuggable = true 由于AAB可能包含多个apk文件，所以在把apk发送到设备时可能会因找不到资源，导致运行时异常，比如 adb刷机（ sideloading ） 动态下载模块需要安装最新的Play Store app，所以有很小概率下载app时会回滚为下载一个multi-APK（为 Android 4.4以下设备提供） RefBundleTool Github地址 简书-Android动态化框架App Bundles 爱奇艺组件化探索之原理篇 【Android】函数插桩（Gradle + ASM） 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android APP Bundles","slug":"android-app-bundles","permalink":"http://agehua.github.io/tags/android-app-bundles/"}]},{"title":"Android避免网络请求造成内存泄漏","slug":"Android-request-memory-leaks","date":"2019-01-25T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2019/01/26/Android-request-memory-leaks/","link":"","permalink":"http://agehua.github.io/2019/01/26/Android-request-memory-leaks/","excerpt":"现在的网络请求框架很多也很完善，但是使用中不注意还是会有内存泄漏的现象。为了避免内存泄漏，大概有两种方式：\n\n1.在Activity结束时取消请求\n2.在异步回调的时候，通过Activity.isFinishing()方法判断Activity是否已经被销毁\n\n但是最近在工作中，发现一个问题：同一个请求，会在多个页面被调用到，这就导致相同的代码包括发送请求，成功或失败回调，数据解析等会出现好几处。如果我想把这个网络请求单独抽离出来，放到一个类里，不依赖具体的Activity，现在的网络框架回调一般都会运行在主线程，如果未及时释放资源，很容易造成内存泄漏。","text":"现在的网络请求框架很多也很完善，但是使用中不注意还是会有内存泄漏的现象。为了避免内存泄漏，大概有两种方式： 1.在Activity结束时取消请求 2.在异步回调的时候，通过Activity.isFinishing()方法判断Activity是否已经被销毁 但是最近在工作中，发现一个问题：同一个请求，会在多个页面被调用到，这就导致相同的代码包括发送请求，成功或失败回调，数据解析等会出现好几处。如果我想把这个网络请求单独抽离出来，放到一个类里，不依赖具体的Activity，现在的网络框架回调一般都会运行在主线程，如果未及时释放资源，很容易造成内存泄漏。 针对这种方式，可以采用EventBus，来发送包含解析后的数据到对应的Activity，在Activity onDestroy里取消EventBus监听。但是如果使用postSticky发送事件，会导致事件接收混乱。 为了真的实现这种需求，参考网上的一篇文章：如何在Activity/Fragment结束时处理异步回调？ 基于Lifeful接口的异步回调框架Lifeful接口设计我们定义Lifeful，一个不依赖于Context、也不依赖于PATH的接口。 /** * 判断生命周期是否已经结束的一个接口。 */public interface Lifeful &#123; /** * 判断某一个组件生命周期是否已经走到最后。一般用于异步回调时判断Activity或Fragment生命周期是否已经结束。 * * @return */ boolean isAlive();&#125; 实际上，我们只需要让具有生命周期的类(一般是Activity或Fragment)实现这个接口，然后再通过这个接口来判断这个实现类是否还存在，就可以与Context解耦了。 接下来定义一个接口生成器，通过弱引用包装Lifeful接口的实现类，并返回所需要的相关信息。/** * 生命周期具体对象生成器。 */public interface LifefulGenerator&lt;Callback&gt; &#123; Callback getCallback(); WeakReference&lt;Lifeful&gt; getLifefulWeakReference(); boolean isLifefulNull();&#125; 提供一个该接口的默认实现：/** * 默认生命周期管理包装生成器。 */public class DefaultLifefulGenerator&lt;Callback&gt; implements LifefulGenerator&lt;Callback&gt; &#123; private WeakReference&lt;Lifeful&gt; mLifefulWeakReference; private boolean mLifefulIsNull; private Callback mCallback; public DefaultLifefulGenerator(Callback callback, Lifeful lifeful) &#123; mCallback = callback; mLifefulWeakReference = new WeakReference&lt;&gt;(lifeful); mLifefulIsNull = lifeful == null; &#125; @Override public Callback getCallback() &#123; return mCallback; &#125; public WeakReference&lt;Lifeful&gt; getLifefulWeakReference() &#123; return mLifefulWeakReference; &#125; @Override public boolean isLifefulNull() &#123; return mLifefulIsNull; &#125;&#125; 接着通过一个静态方法判断是否对象的生命周期：/** * 生命周期相关帮助类。 */public class LifefulUtils &#123; private static final String TAG = LifefulUtils.class.getSimpleName(); public static &lt;T&gt; boolean shouldGoHome(LifefulGenerator&lt;T&gt; lifefulGenerator, boolean objectIsNull) &#123; WeakReference&lt;Lifeful&gt; lifefulWeakReference = lifefulGenerator.getLifefulWeakReference(); if (lifefulWeakReference == null) &#123; Log.e(TAG, \"Go home, lifefulWeakReference == null\"); return true; &#125; Lifeful lifeful = lifefulWeakReference.get(); if (null == lifeful &amp;&amp; !objectIsNull) &#123; return true; &#125; if (null != lifeful &amp;&amp; !lifeful.isAlive()) &#123; lifefulGenerator.setCallback(null); // 取消持有的callback return true; &#125; return false; &#125; public static &lt;T&gt; boolean shouldGoHome(LifefulGenerator&lt;T&gt; lifefulGenerator) &#123; if (null == lifefulGenerator) &#123; Log.e(TAG, \"Go home, null == lifefulGenerator\"); return true; &#125; if (null == lifefulGenerator.getCallback()) &#123; Log.e(TAG, \"Go home, null == lifefulGenerator.getCallback()\"); return true; &#125; return shouldGoHome(lifefulGenerator, lifefulGenerator.isLifefulNull()); &#125;&#125; 具有生命周期的Runnable具体到跟线程打交道的异步类，只有Runnable(Thread也是其子类)，因此只需要处理Runnable就可以了。我们可以通过Wrapper包装器模式，在处理真正的Runnable类之前，先通过Lifeful接口判断对象是否还存在，如果不存在则直接返回。对于Runnable：/** * 与周期相关的异步线程回调类。 */public class LifefulRunnable implements Runnable &#123; private LifefulGenerator&lt;Runnable&gt; mLifefulGenerator; public LifefulRunnable(Runnable runnable, Lifeful lifeful) &#123; mLifefulGenerator = new DefaultLifefulGenerator&lt;&gt;(runnable, lifeful); &#125; @Override public void run() &#123; if (LifefulUtils.shouldGoHome(mLifefulGenerator)) &#123; return; &#125; mLifefulGenerator.getCallback().run(); &#125;&#125; Lifeful的实现类最后说一下Lifeful类的实现类，主要包括Activity和Fragment，public class BaseActivity extends Activity implements Lifeful &#123; @Override public boolean isAlive() &#123; return activityIsAlive(); &#125; public boolean activityIsAlive() &#123; if (currentActivity == null) return false; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.JELLY_BEAN_MR1) &#123; return !(currentActivity.isDestroyed() || currentActivity.isFinishing()); &#125; else &#123; return !currentActivity.isFinishing(); &#125; &#125;&#125;public class BaseFragment extends Fragment implements Lifeful &#123; @Override public boolean isAlive() &#123; return activityIsAlive(); &#125; public boolean activityIsAlive() &#123; Activity currentActivity = getActivity(); if (currentActivity == null) return false; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.JELLY_BEAN_MR1) &#123; return !(currentActivity.isDestroyed() || currentActivity.isFinishing()); &#125; else &#123; return !currentActivity.isFinishing(); &#125; &#125;&#125; 除了这两个类以外，别的类如果有生命周期，或者包含生命周期的引用，也可以实现Lifeful接口(如View，可以通过onAttachedToWindow()和onDetachedToWindow())。 包含生命周期的异步调用对于需要用到异步的地方，调用也很方便。 // ThreadCore是一个用于线程调度的ThreadPoolExecutor封装类，也用于主线程和工作线程之间的切换ThreadCore.getInstance().postOnMainLooper(new LifefulRunnable(new Runnable() &#123; @Override public void run() &#123; // 实现真正的逻辑。 &#125;&#125;, this)); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2019/01/26/Android-request-memory-leaks/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Memory leaks","slug":"memory-leaks","permalink":"http://agehua.github.io/tags/memory-leaks/"},{"name":"net request","slug":"net-request","permalink":"http://agehua.github.io/tags/net-request/"}]},{"title":"Android录音相关方法介绍","slug":"Android-audio-introduction","date":"2018-12-05T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2018/12/06/Android-audio-introduction/","link":"","permalink":"http://agehua.github.io/2018/12/06/Android-audio-introduction/","excerpt":"本文介绍Android开发录音功能中用到的相关API和音频数据编码解码的处理\n录音基础知识常用音频格式：\n\nWAV 格式：音质高 无损格式 体积较大\nAAC（Advanced Audio Coding） 格式：相对于 mp3，AAC 格式的音质更佳，文件更小，有损压缩，一般苹果或者Android SDK4.1.2（API 16）及以上版本支持播放,性价比高\nAMR 格式：压缩比比较大，但相对其他的压缩格式质量比较差，多用于人声，通话录音\nAMR分类:  AMR(AMR-NB): 语音带宽范围：300－3400Hz，8KHz抽样\n\n\nmp3 格式：特点 使用广泛， 有损压缩，牺牲了12KHz到16KHz高音频的音质","text":"本文介绍Android开发录音功能中用到的相关API和音频数据编码解码的处理 录音基础知识常用音频格式： WAV 格式：音质高 无损格式 体积较大 AAC（Advanced Audio Coding） 格式：相对于 mp3，AAC 格式的音质更佳，文件更小，有损压缩，一般苹果或者Android SDK4.1.2（API 16）及以上版本支持播放,性价比高 AMR 格式：压缩比比较大，但相对其他的压缩格式质量比较差，多用于人声，通话录音 AMR分类: AMR(AMR-NB): 语音带宽范围：300－3400Hz，8KHz抽样 mp3 格式：特点 使用广泛， 有损压缩，牺牲了12KHz到16KHz高音频的音质 音频开发的具体内容 音频采集/播放 音频算法处理（去噪、静音检测、回声消除、音效处理、功放/增强、混音/分离，等等） 音频的编解码和格式转换 音频传输协议的开发（SIP，A2DP、AVRCP，等等） 录音API: AudioRecordAudioRecord是相对MediaRecord更为底层的API，使用AudioRecord也可以很方便的完成录音功能。AudioRecord录音录制的是原始的PCM音频数据，可以使用AudioTrack来播放PCM音频文件。 先看下AudioRecord的构造函数，/** * @param audioSource ：录音源 * 这里选择使用麦克风：MediaRecorder.AudioSource.MIC * @param sampleRateInHz： 采样率 * @param channelConfig：声道数 * @param audioFormat： 采样位数. * See &#123;@link AudioFormat#ENCODING_PCM_8BIT&#125;, &#123;@link AudioFormat#ENCODING_PCM_16BIT&#125;, * and &#123;@link AudioFormat#ENCODING_PCM_FLOAT&#125;. * @param bufferSizeInBytes： 音频录制的缓冲区大小 * See &#123;@link #getMinBufferSize(int, int, int)&#125;*/AudioRecord(int audioSource, int sampleRateInHz, int channelConfig, int audioFormat, int bufferSizeInBytes) \b可以看到构造函数需要 5 个参数，最后一个参数bufferSizeInBytes，获取方式为：private int channelCount=2; //音频采样通道，默认2通道bufferSize = AudioRecord.getMinBufferSize(sampleRate, channelConfig, audioFormat)*2; // 5.录音过程中音频缓冲空间大小 (码率) 初始化完成后，就可以开始录制：//实例化AudioRecordmRecorder=new AudioRecord(MediaRecorder.AudioSource.MIC,sampleRate,channelConfig, audioFormat,bufferSize);private FileOutputStream fos; //用于保存录音文件//开始录制mRecorder.startRecording();byte[] byteBuffer = new byte[bufferSize];while (state == RecordState.RECORDING) &#123; // //循环读取数据到buffer中，并保存buffer中的数据到文件中 int end = audioRecord.read(byteBuffer, 0, byteBuffer.length); notifyData(byteBuffer); fos.write(byteBuffer, 0, end); fos.flush();&#125;mRecorder.stop();//暂停录制 更新 RecordState 状态就可以退出 while循环，结束录制 /** * 表示当前状态 */public enum RecordState &#123; /** * 空闲状态 */ IDLE, /** * 录音中 */ RECORDING, /** * 暂停中 */ PAUSE, /** * 正在停止 */ STOP, /** * 录音流程结束（转换结束） */ FINISH&#125; 计算合适码率不同的设备可以支持的采样率不同，根据采样率从大到小计算 bufferSizepublic void getValidBufferSize() &#123; for (int rate : new int[]&#123;44100, 22050, 11025, 16000, 8000&#125;) &#123; // add the rates you wish to check against int bufferSize = AudioRecord.getMinBufferSize(rate, AudioFormat.CHANNEL_CONFIGURATION_DEFAULT, AudioFormat.ENCODING_PCM_16BIT); if (bufferSize &gt; 0) &#123; audioRecord = new AudioRecord(MediaRecorder.AudioSource.VOICE_COMMUNICATION, currentConfig.getSampleRate(), currentConfig.getChannelConfig(), currentConfig.getEncodingConfig(), bufferSize); return; &#125; &#125;&#125; 根据码率计算已录制时间Stack Overflow上有回答：Calculate elapsed time from AudioRecord上面提到 AudioRecord的最后一个参数就是码率： 码率 = 采样频率 采样位数 声道个数； 例：采样频率44.1KHz，量化位数16bit，立体声(双声道)，未压缩时的码率 = 44.1KHz 16 2 = 1411.2Kbps = 176.4KBps，即每秒要录制的资源大小, 理论上码率和质量成正比对应时间的计算方式应该是：已录制时长(单位是秒) = dataSize/(getEncoding()*getChannelCount()*44100) /** * 获取当前录音的采样位宽 单位bit * * @return 采样位宽 0: error */public int getEncoding() &#123; if (encodingConfig == AudioFormat.ENCODING_PCM_8BIT) &#123; return 8; &#125; else if (encodingConfig == AudioFormat.ENCODING_PCM_16BIT) &#123; return 16; &#125; else &#123; return 0; &#125;&#125;/** * 当前的声道数 * * @return 声道数： 0：error */public int getChannelCount() &#123; if (channelConfig == AudioFormat.CHANNEL_IN_MONO) &#123; return 1; &#125; else if (channelConfig == AudioFormat.CHANNEL_IN_STEREO) &#123; return 2; &#125; else &#123; return 0; &#125;&#125; 按照上面的步骤，我们就能成功的录制PCM音频文件了，但是处于传输和存储方面的考虑，一般来说，我们是不会直接录制PCM音频文件的。而是在录制过程中就对音频数据进行编码为aac、mp3、wav等其他格式的音频文件 关于录制pcm，mp3格式，详细可以看这篇文章：Android音频开发（1）：音频基础知识 AAC格式介绍AAC（高级音频编码技术 Advanced Audio Coding)，出现于1997年，是基于MPEG-2的音频编码技术。由Fraunhofer IIS、杜比、苹果、AT&amp;T、索尼等公司共同开发，以取代mp3格式。2000年，MPEG-4标准出台，AAC从新整合了其特性，故现又称MPEG-4 AAC，即m4a。 作为一种高压缩比的音频压缩算法，AAC通常压缩比为18：1，也有资料说为20：1，远胜mp3，而音质由于采用多声道，和使用低复杂性的描述方式，使其比几乎所有的传统编码方式在同规格的情况下更胜一筹。不过直到2006年，使用这一格式储存音频的并不多，可以播放该格式的mp3播放器更是少之又少，目前所知仅有苹果iPod，而手机支持AAC的相对要多一些，此外电脑上很多音频播放软件都支持AAC格式，如苹果iTunes。AAC所采用的运算法则 AAC所采用的运算法则与MP3的运算法则有所不同，AAC通过结合其他的功能来提高编码效率。AAC的音频算法在压缩能力上远远超过了以前的一些压缩算法（比如MP3等）。它还同时支持多达48个音轨、15个低频音轨、更多种采样率和比特率、多种语言的兼容能力、更高的解码效率。号称「最大能容纳48通道的音轨，采样率达96 KHz，并且在320Kbps的数据速率下能为5.1声道音乐节目提供相当于ITU-R广播的品质」。 总之，AAC可以在比MP3文件节省大约30%的储存空间与带宽的前提下提供更好的音质。但是在空间上和结构上AAC和mp3编码出来后的风格不太一样，喜欢与否属于仁者见仁智者见智的事情。 硬件编解码API: MediaCodecMediaCodec 是 Android 提供的可以访问底层解码和编码Media的组件，它是 Android 底层多媒体支持框架的一部分 下图是Android官方提供的MediaCodec工作流程： 针对于上图，我们可以把InputBuffers和OutputBuffers简单的理解为它们共同组成了一个环形的传送带，传送带上铺满了空盒子。编解码开始后，我们需要得到一个空盒子（dequeueInputBuffer），然后往空盒子中填充原料（需要被编/解码的音/视频数据），并且放回到传送带你取出时候的那个位置上面（queueInputBuffer）。传送带经过处理器（Codec）后，盒子里面的原料被加工成了你所期望的东西（编解码后的数据），你就可以按照你放入原料时候的顺序，连带着盒子一起取出加工好的东西（dequeueOutputBuffer），并将取出来的东西贴标签（加数据头之类的非必须）和装箱（组合编码后的帧数据）操作，同样之后也要把盒子放回到原来的位置（releaseOutputBuffer） 初始化编码器实例public void initAudioEncoder(RecordConfig recordConfig)&#123; aBufferInfo = new MediaCodec.BufferInfo(); audioQueue = new LinkedBlockingQueue&lt;&gt;(); audioCodecInfo = selectCodec(AUDIO_MIME_TYPE); if (audioCodecInfo == null) &#123; return; &#125; // 取到前面录音时的相关配置 int sampleRate = recordConfig.getSampleRate(); int pcmFormat = recordConfig.getEncoding(); int chanelCount = recordConfig.getChannelCount(); audioFormat = MediaFormat.createAudioFormat(AUDIO_MIME_TYPE, sampleRate, chanelCount); audioFormat.setInteger(MediaFormat.KEY_AAC_PROFILE, MediaCodecInfo.CodecProfileLevel.AACObjectLC); audioFormat.setInteger(MediaFormat.KEY_CHANNEL_MASK, AudioFormat.CHANNEL_IN_STEREO);//CHANNEL_IN_STEREO 立体声 int bitRate = sampleRate * pcmFormat * chanelCount; audioFormat.setInteger(MediaFormat.KEY_BIT_RATE, bitRate); audioFormat.setInteger(MediaFormat.KEY_CHANNEL_COUNT, chanelCount); audioFormat.setInteger(MediaFormat.KEY_SAMPLE_RATE, sampleRate); if (aEncoder != null) &#123; return; &#125; try &#123; // 创建音频编码器 aEncoder = MediaCodec.createEncoderByType(AUDIO_MIME_TYPE); &#125; catch (IOException e) &#123; e.printStackTrace(); throw new RuntimeException(\"初始化音频编码器失败\", e); &#125;&#125;private MediaCodecInfo selectCodec(String mimeType) &#123; int numCodecs = MediaCodecList.getCodecCount(); for (int i = 0; i &lt; numCodecs; i++) &#123; MediaCodecInfo codecInfo = MediaCodecList.getCodecInfoAt(i); if (!codecInfo.isEncoder()) &#123; continue; &#125; String[] types = codecInfo.getSupportedTypes(); for (int j = 0; j &lt; types.length; j++) &#123; if (types[j].equalsIgnoreCase(mimeType)) &#123; return codecInfo; &#125; &#125; &#125; return null;&#125; 解码器开始工作//之前的音频录制是直接循环读取，然后写入文件，这里需要做编码处理再写入文件//这里的处理就是和之前传送带取盒子放原料的流程一样private void startAudioEncode() &#123; audioEncoderThread = new Thread() &#123; // 注意一般在子线程中循环处理 @Override public void run() &#123; Log.d(TAG, \" 编码线程 启动...\"); presentationTimeUs = System.currentTimeMillis() * 1000; aEncoderEnd = false; aEncoder.configure(audioFormat, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); aEncoder.start(); while (audioEncoderLoop &amp;&amp; !Thread.interrupted()) &#123; try &#123; byte[] data = audioQueue.take(); // 从队列中取得数据，这个队列在下面有解释 encodeAudioData(data); &#125; catch (InterruptedException e) &#123; e.printStackTrace(); break; &#125; &#125; if (aEncoder != null) &#123; //停止音频编码器 aEncoder.stop(); //释放音频编码器 aEncoder.release(); aEncoder = null; &#125; audioQueue.clear(); Log.d(TAG, \"= =lgd= ==Audio 编码线程 退出...\"); &#125; &#125;; audioEncoderLoop = true; audioEncoderThread.start();&#125;/*** 从队列中取得数据，并编码为 AAC 格式* @param input*/private void encodeAudioData(byte[] input)&#123; try &#123; //拿到输入缓冲区,用于传送数据进行编码 ByteBuffer[] inputBuffers = aEncoder.getInputBuffers(); //首先通过dequeueInputBuffer(long timeoutUs)请求一个输入缓存，timeoutUs代表等待时间，设置为-1代表无限等待 int inputBufferIndex = aEncoder.dequeueInputBuffer(-1); if (inputBufferIndex &gt;= 0) &#123; ByteBuffer inputBuffer = inputBuffers[inputBufferIndex]; //使用之前要clear一下，避免之前的缓存数据影响当前数据 inputBuffer.clear(); //把数据添加到输入缓存中， inputBuffer.put(input); //并调用queueInputBuffer()把缓存数据入队 aEncoder.queueInputBuffer(inputBufferIndex, 0, input.length, 0, 0); &#125; //拿到输出缓冲区,用于取到编码后的数据 ByteBuffer[] outputBuffers = aEncoder.getOutputBuffers(); //拿到输出缓冲区的索引 int outputBufferIndex = aEncoder.dequeueOutputBuffer(aBufferInfo, TIMEOUT_USEC); ByteBuffer outputBuffer; int outBitSize; int outPacketSize; byte[] chunkAudio; while (outputBufferIndex &gt;= 0) &#123; outBitSize = aBufferInfo.size; //添加ADTS头,ADTS头包含了AAC文件的采样率、通道数、帧数据长度等信息。 outPacketSize = outBitSize + 7;//7为ADTS头部的大小 outputBuffer = outputBuffers[outputBufferIndex];//拿到输出Buffer outputBuffer.position(aBufferInfo.offset); outputBuffer.limit(aBufferInfo.offset + outBitSize); chunkAudio = new byte[outPacketSize]; addADTStoPacket(chunkAudio, outPacketSize); // 给编码出的aac裸流添加adts头字段 outputBuffer.get(chunkAudio, 7, outBitSize);//将编码得到的AAC数据 取出到byte[]中偏移量offset=7 outputBuffer.position(aBufferInfo.offset); if (null != mCallback) &#123; mCallback.outputAudioData(chunkAudio, chunkAudio.length, (int) aBufferInfo.presentationTimeUs / 1000); &#125; //releaseOutputBuffer方法必须调用 aEncoder.releaseOutputBuffer(outputBufferIndex, false); outputBufferIndex = aEncoder.dequeueOutputBuffer(aBufferInfo, 10000); &#125; &#125; catch (Exception t) &#123; Log.e(TAG, \" =encodeAudioData=====error: \" + t.toString()); &#125;&#125; 上面的audioQueue 是一个链表 LinkedBlockingQueue&lt;byte[]&gt;。它的作用是由 audioRecord.read(byteBuffer, 0, byteBuffer.length) 获取录音数据，放入队列/** * 放入音频数据 * @param data */public void putAudioData(byte[] data) &#123; try &#123; audioQueue.put(data); &#125; catch (InterruptedException e) &#123; e.printStackTrace(); &#125;&#125; 给编码出的aac裸流添加adts头字段/** * 添加ADTS头 * * @param packet 要空出前7个字节，否则会搞乱数据 * @param packetLen */private void addADTStoPacket(byte[] packet, int packetLen) &#123; int profile = 2; // AAC LC int freqIdx = 8; // 44.1KHz int chanCfg = 1; // CPE // fill in ADTS data packet[0] = (byte) 0xFF; packet[1] = (byte) 0xF9; packet[2] = (byte) (((profile - 1) &lt;&lt; 6) + (freqIdx &lt;&lt; 2) + (chanCfg &gt;&gt; 2)); packet[3] = (byte) (((chanCfg &amp; 3) &lt;&lt; 6) + (packetLen &gt;&gt; 11)); packet[4] = (byte) ((packetLen &amp; 0x7FF) &gt;&gt; 3); packet[5] = (byte) (((packetLen &amp; 7) &lt;&lt; 5) + 0x1F); packet[6] = (byte) 0xFC;&#125; 音视频混合API: 音视频混合APIMediaMuxer的使用很简单，在Android Developer官网上MediaMuxer的API说明中，也有其简单的使用示例代码，这里就不列了。 参照官方的说明和代码示例，我们可以知道，音视频混合（也可以音频和音频混合），只需要将编码器的MediaFormat加入到MediaMuxer中，得到一个音轨视频轨的索引，然后每次从编码器中取出来的ByteBuffer，写入（writeSampleData）到编码器所在的轨道中就ok了。这里需要注意的是，一定要等编码器设置编码格式完成后，再将它加入到混合器中，编码器编码格式设置完成的标志是dequeueOutputBuffer得到返回值为MediaCodec.INFO_OUTPUT_FORMAT_CHANGED。 源码文章内用到的源码，在agehua/ZlwAudioRecorder，这个是forked from zhaolewei/ZlwAudioRecorder。在原来项目上加入了 AAC 格式支持 参考文章Android硬编码——音频编码、视频编码及音视频混合 Android音频开发（1）：音频基础知识 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/12/06/Android-audio-introduction/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AudioRecord","slug":"audiorecord","permalink":"http://agehua.github.io/tags/audiorecord/"},{"name":"AAC","slug":"aac","permalink":"http://agehua.github.io/tags/aac/"}]},{"title":"Handler、Looper与MessageQueue分析","slug":"Handler-Looper-MessageQueue","date":"2018-08-21T16:00:00.000Z","updated":"2022-03-28T09:32:40.000Z","comments":true,"path":"2018/08/22/Handler-Looper-MessageQueue/","link":"","permalink":"http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/","excerpt":"本文内容节选自《Android从小工到专家——第三章：App流畅度——多线程》，内容稍有修改\n我们知道在Android应用启动时，会默认有一个主线程（UI线程），在这个线程中会关联一个消息队列，所有的操作都会被封装成消息然后交给主线程来处理。为了保证主线程不会主动退出，会将获取消息的操作放在一个死循环中，这样，程序就不会退出.","text":"本文内容节选自《Android从小工到专家——第三章：App流畅度——多线程》，内容稍有修改 我们知道在Android应用启动时，会默认有一个主线程（UI线程），在这个线程中会关联一个消息队列，所有的操作都会被封装成消息然后交给主线程来处理。为了保证主线程不会主动退出，会将获取消息的操作放在一个死循环中，这样，程序就不会退出. Handler、Looper、Message有啥关系？在子线程中完成耗时操作，很多情况下需要更新UI，最常用的就是通过Handler将一个消息Post到UI线程中，然后再在Handler的handlerMessage方法中进行处理。而每个Handler都会关联一个消息队列（MessageQueue），Looper负责的就是创建一个MessageQueue，而每个Looper又会关联一个线程（Looper通过ThreadLocal封装）。默认情况下，MessageQueue只有一个，即主线程的消息队列。 源码解读ActivityThread主线程中启动启动消息循环Looper在ActivityThread的main方法中：public static void main(String[] args) &#123; // 代码省略 Process.setArgV0(\"&lt;pre-initialized&gt;\"); Looper.prepareMainLooper(); //1.创建消息\b循环Looper ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) &#123; sMainThreadHandler = thread.getHandler(); // UI线程的Handler &#125; if (false) &#123; Looper.myLooper().setMessageLogging(new LogPrinter(Log.DEBUG, \"ActivityThread\")); &#125; Looper.loop(); // 2.执行消息循环 throw new RuntimeException(\"Main thread loop unexpectedly exited\"); &#125; ActivityThread通过Looper.prepareMainLooper()创建主线程的消息队列，最后执行Looper.loop()来启动消息队列。Handler关联消息队列和线程。 在 API 22 之后，Google 删除了 AsyncTask.init() 方法，main 函数中也不再调用它。 具体可以看这篇文章：AsyncTask 解析 执行ActivityThread.main方法后，应用程序就启动了，并且会一直从消息队列中取消息，然后处理消息，使得系统运转起来。那么系统是如何将消息投递到消息队列，\b又是如何从消息中获取消息并处理的呢？答案就是Handler Handler关联消息队列和线程消息队列被封装在Looper中，而每个Looper又会关联一个线程（\bLooper通过ThreadLocal封装），最终就等于每个消息队列会关联一个线程。 \b那Handler是如何关联到消息队列以及线程的呢？请看下面的源代码： public Handler() &#123; //代码省略 mLooper = Looper.myLooper(); //获取Looper if (mLooper == null) &#123; throw new RuntimeException( \"Can't create handler inside thread that has not called Looper.prepare()\"); &#125; mQueue = mLooper.mQueue; //获取消息队列 mCallback = null;&#125; Handler会在内部通过Looper.getLooper()方法来获取Looper对象，并且与之关联，并获取消息队列。那么Looper.getLooper()如何工作的呢？ public static @Nullable Looper myLooper() &#123; return sThreadLocal.get();&#125;public static @NonNull MessageQueue myQueue() &#123; return myLooper().mQueue;&#125;public static void prepare() &#123; prepare(true);&#125;//为当前线程设置一个Looperprivate static void prepare(boolean quitAllowed) &#123; if (sThreadLocal.get() != null) &#123; throw new RuntimeException(\"Only one Looper may be created per thread\"); &#125; sThreadLocal.set(new Looper(quitAllowed));&#125;//设置UI线程的Looperpublic static void prepareMainLooper() &#123; prepare(false); synchronized (Looper.class) &#123; if (sMainLooper != null) &#123; throw new IllegalStateException(\"The main Looper has already been prepared.\"); &#125; sMainLooper = myLooper(); &#125;&#125;// Looper的私有构造方法private Looper(boolean quitAllowed) &#123; mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread();&#125; 在Looper类中，myLooper()方法，通过sThreadLocal.get()来获取的，在prepareMainLooper()中调用prepare()方法，在这个方法中创建了一个Looper对象，并将对象设置了sThreadLocal()。这样队列就和线程关联起来了。通过sThreadLocal.get()方法，保证不同的线程不能访问对方的消息队列。 再回到Handler，消息队列通过Looper与线程关联上，而Handler又与Looper关联，因此，Handler最终就和线程、线程的消息队列关联上了。 为什么要更新UI的Handler必须在主线程中创建？因为Handler要与主线程的消息队列关联上，这样handlerMessage才会执行在UI线程，此时UI线程才是安全的。 消息循环，消息处理消息循环的建立就是通过Looper.loop()方法。源代码如下： /** * Run the message queue in this thread. Be sure to call * &#123;@link #quit()&#125; to end the loop. */public static void loop() &#123; final Looper me = myLooper(); if (me == null) &#123; throw new RuntimeException(\"No Looper; Looper.prepare() wasn't called on this thread.\"); &#125; final MessageQueue queue = me.mQueue; //1.获取消息队列 // 代码省略 for (;;) &#123; //2.死循环，即消息循环 //3.获取消息，可能阻塞 Message msg = queue.next(); // might block if (msg == null) &#123; // No message indicates that the message queue is quitting. return; &#125; // 代码省略 try &#123; msg.target.dispatchMessage(msg); //4.处理消息 end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis(); &#125; finally &#123; if (traceTag != 0) &#123; Trace.traceEnd(traceTag); &#125; &#125; // 代码省略 msg.recycleUnchecked(); //回收消息 &#125;&#125; 从上述程序我们可以看出，loop()方法的实质上是建立一个死循环，然后通过从消息队列中逐个取出消息，最后处理消息。对于Looper：通过Looper.prepare()来创建Looper对象（消息队列封装在Looper对象中），并且保存在sThreadLocal中，然后通过通过Looper.loop()进行消息循环，这两步通常成对出现。 消息处理机制在上面代码中通过 msg.target.dispatchMessage(msg) 来处理消息，其中msg是Message类型，源码如下： public final class Message implements Parcelable &#123; //target处理 Handler target; //Runnable类型的callback Runnable callback; //下一条消息，消息队列是链式存储的 Message next; //代码省略&#125; 从源码中可以看出，target是Handler类型。实际上就是转了一圈，通过Handler发送消息给消息队列，消息队列又将消息分发给Handler处理。在Handler类中： //消息处理函数，子类覆写public void handleMessage(Message msg) &#123;&#125;private static void handleCallback(Message message) &#123; message.callback.run();&#125;//分发消息public void dispatchMessage(Message msg) &#123; if (msg.callback != null) &#123; handleCallback(msg); &#125; else &#123; if (mCallback != null) &#123; if (mCallback.handleMessage(msg)) &#123; return; &#125; &#125; handleMessage(msg); &#125;&#125; 从上述程序可以看出，dispatchMessage只是一个分发的方法，如果Run nable类型的callback为空，则执行handleMessage来处理消息，该方法为空，我们会将更新UI的代码写在该函数中；如果callback不为空，则执行handleCallback来处理，该方法会调用callback (Runnable对象) 的run方法。 其实这是Handler分发的两种类型，比如post(Runnable callback)则callback就不为空，当我们使用Handler来sendMessage时通常不设置callback，因此，执行handlerMessage。 我们看看这两种实现： public final boolean post(Runnable r)&#123; return sendMessageDelayed(getPostMessage(r), 0);&#125;private static Message getPostMessage(Runnable r) &#123; Message m = Message.obtain(); m.callback = r; return m;&#125;public final boolean sendMessageDelayed(Message msg, long delayMillis)&#123; if (delayMillis &lt; 0) &#123; delayMillis = 0; &#125; return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);&#125;public boolean sendMessageAtTime(Message msg, long uptimeMillis) &#123; MessageQueue queue = mQueue; if (queue == null) &#123; RuntimeException e = new RuntimeException( this + \" sendMessageAtTime() called with no mQueue\"); Log.w(\"Looper\", e.getMessage(), e); return false; &#125; return enqueueMessage(queue, msg, uptimeMillis); // 将消息插入到消息队列&#125;private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) &#123; msg.target = this; // Message的target就是该Handler本身 if (mAsynchronous) &#123; msg.setAsynchronous(true); &#125; return queue.enqueueMessage(msg, uptimeMillis);// 调用MessageQueue的加入消息方法&#125; 从上述程序可以看到，在post(Runnable r)时，会将Runnable包装成Message对象，并且将Runnable对象设置给Message对象的callback，最后会将该对象插入消息队列。sendMessage也是类似实现： public final boolean sendMessage(Message msg)&#123; return sendMessageDelayed(msg, 0);&#125; 不管是post一个Runnable还是Message，都会调用sendMessageDelayed(msg, time)方法。Handler最终将消息追加到MessageQueue中，而Looper不断地从MessageQueue中读取消息，并且调用Handler的dispatchMessage分发消息，这样消息就源源不断地被产生、添加到MessageQueue、被Handler处理，Android应用就运转起来了。 子线程正确创建Handler在上面Handler的构造方法中看到，如果mLooper = Looper.myLooper()，mLooper为空，则会抛出异常。正确使用方法应该是： new Thread()&#123; Handler handler = null; public void run () &#123; //为当前线程创建Looper，并且绑定到ThreadLocal中 Looper.prepare() handler = new Handler(); //启动消息循环 Looper.loop(); &#125;;&#125;.start(); 如果只创建Looper不启动消息循环，虽然不抛出异常，但是通过handler来post或者sendMessage()也不会有效。因为虽然消息会被追加到消息队列，但是并没有启动消息循环，也就不会从消息队列中获取消息并且执行了。 为什么说MessageQueue 和 Looper 是一对一关系，Handler 和 Looper 是多对一？首先，在上面Looper的私有构造方法，每一个Looper对象都会new MessageQueue()来创建一个MessageQueue，所以是一对一关系没错。为什么Handler和Looper可以是多对一呢？这是因为Handler的构造方法中，会获取当前线程的Looper对象（由ThreadLocal保存的），一个线程Looper对象只有一个，但是可以创建多个Handler对象，所以是多对一 Toast在子线程的用法Toast在子线程直接使用，会报错：java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare() at android.os.Handler.&lt;init&gt;(Handler.java:200) at android.os.Handler.&lt;init&gt;(Handler.java:114) at android.widget.Toast$TN$2.&lt;init&gt;(Toast.java:345) at android.widget.Toast$TN.&lt;init&gt;(Toast.java:345) at android.widget.Toast.&lt;init&gt;(Toast.java:103) at android.widget.Toast.makeText(Toast.java:262) at com.agehua.loveprints.view.main.MainActivity$ShowExceptionThread.run(MainActivity.java:127) 回到前面看下Handler的构造函数，可以发现报这个错误的原因是 mLooper 为null。所以正确的用法应该是： private class ShowExceptionThread extends Thread &#123; private String ex; ShowExceptionThread(String ex) &#123; this.ex = ex; &#125; @Override public void run() &#123; Looper.prepare(); Toast.makeText(AndroidApplication.getInstance().getApplicationContext(), \"Error Encountered: \" + ex, Toast.LENGTH_LONG).show(); Looper.loop(); &#125;&#125; 关于为什么Toast里面会需要Handler，可以看这篇博客：Android Toast源码分析 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Looper","slug":"looper","permalink":"http://agehua.github.io/tags/looper/"},{"name":"Android Source Code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"},{"name":"Handler","slug":"handler","permalink":"http://agehua.github.io/tags/handler/"},{"name":"MessageQueue","slug":"messagequeue","permalink":"http://agehua.github.io/tags/messagequeue/"}]},{"title":"投马-Markdown介绍","slug":"Toastmaster-md-introduction","date":"2018-06-25T16:00:00.000Z","updated":"2023-11-16T03:42:40.849Z","comments":true,"path":"2018/06/26/Toastmaster-md-introduction/","link":"","permalink":"http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/","excerpt":"                   .-&apos; _..`.                           /  .&apos;_.&apos;.&apos;                 | .&apos; (.)`.                 ;&apos;   ,_   `. .--.__________.&apos;    ;  `.;-&apos;|  ./               /|  |               / `..&apos;`-._  _____, ..&apos;     / | |     | |\\ \\    / /| |     | | \\ \\   / / | |     | |  \\ \\  /_/  |_|     |_|   \\_\\","text":".-&apos; _..`. / .&apos;_.&apos;.&apos; | .&apos; (.)`. ;&apos; ,_ `. .--.__________.&apos; ; `.;-&apos;| ./ /| | / `..&apos;`-._ _____, ..&apos; / | | | |\\ \\ / /| | | | \\ \\ / / | | | | \\ \\ /_/ |_| |_| \\_\\ Good afternoon, today I want to introduce a new file format. Before the introduction, I want to ask a question firest: do you have a habit of taking notes or writing blogs? You may heard of Evernote or Jianshu. They all suppost this format to publish arcitles or notes. This format called markdown The file name of this format end up with md or markdown extension. I write my blog use this format. And it is useful and convenient. First, what is the markdown?Markdown is a lightweight markup language with plain text formatting syntax.The motivation for inventing this language was to write content for the web and make the content easy-to-read and easy-to-write.Markdown’s syntax is comprised entirely of punctuation(标点符号) characters, which punctuation characters have been carefully chosen so as to look like what they mean. E.g., asterisks around a word actually look like emphasis. Markdown lists look like, well, lists. Even blockquotes look like quoted passages of text. Second, how does the markdown work?To write Markdown content, you only need a simple text eidtor which support txt extension. That is because it’s written in “plaintext”, which is exactly the sort of text you’re used to writing and seeing. Plaintext is just the regular alphabet, with a few familiar symbols, like pounds (#) and backticks (`). But if you want to see the formated content while you are writing, you need an editor which support markdown. But don’t worry, there are many recommendations on the Internet. Third, why markdown is popular?Markdown is not a replacement for HTML, or even close to it. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.Text written in Markdown can be easily shared between computers, mobile phones, and people. It’s quickly becoming the writing standard for academics(学术), scientists, writers, and many more. Websites like GitHub and reddit use Markdown to style their comments. In china, there are some websites using markdown to write articles as well.Such as, jianshu, a blog community to share articles. Evernote，a famous tools to keep notes. And even more, we can use markdown to write subscription articles for wechat. Finally, Is it diffcult to learn the markdown syntax?No, not at all. Formatting text in Markdown has a very gentle learning curve, it is very easy to learn. It doesn’t do anything fancy like change the font size, color, or type. All you have control over is the display of the text—stuff. For example, surrounded with two asterisks will make the text bold, and starting with two pounds will create a level-two header, and starting with three pounds will create a H3 header, and so on. Now, if you are interested in markdown, I recommend you a website 马克飞象, you can take a look at the official introduction. 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/","raw":null,"content":null,"categories":[{"name":"english","slug":"english","permalink":"http://agehua.github.io/categories/english/"}],"tags":[{"name":"toastmaster","slug":"toastmaster","permalink":"http://agehua.github.io/tags/toastmaster/"}]},{"title":"Java的内存管理与垃圾回收","slug":"JVM-stack-heap-GC","date":"2018-06-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/06/08/JVM-stack-heap-GC/","link":"","permalink":"http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/","excerpt":"不知不觉已经6月8号了，回首一下5月，发现没有什么积累。给自己找个借口，是工作太忙，还是找工作太累？都不是，应该只是自己偷懒了。\n待着是一天，忙碌着也是一天。所以从这篇博文开始，\b为自己立下三个小目标，来督促自己：1.总结一个Java\b系列的文章（至少三篇）2.总结一个数据结构和算法相关的文章（至少三篇）3.学习Android Framework知识，总结出至少三篇\n本篇主要介绍《Java的内存管理与垃圾回收》","text":"不知不觉已经6月8号了，回首一下5月，发现没有什么积累。给自己找个借口，是工作太忙，还是找工作太累？都不是，应该只是自己偷懒了。 待着是一天，忙碌着也是一天。所以从这篇博文开始，\b为自己立下三个小目标，来督促自己：1.总结一个Java\b系列的文章（至少三篇）2.总结一个数据结构和算法相关的文章（至少三篇）3.学习Android Framework知识，总结出至少三篇 本篇主要介绍《Java的内存管理与垃圾回收》 作者：Vamei 出处：http://www.cnblogs.com/vamei/archive/2013/04/28/3048353.html Java是在JVM所虚拟出的内存环境中运行的。内存分为栈(stack)和堆(heap)两部分。我们将分别考察这两个区域。 栈栈是有序的元素集合。栈最显著的特征是LIFO (Last In, First Out, 后进先出)。 栈中的每个元素称为一个frame。而最上层元素称为top frame。栈只支持三个操作， pop, top, push。 栈最经典的计算机应用是函数调用。每个进程都会有一个栈，每个frame中记录了调用函数的参数，自动变量和返回地址。当该函数调用一个新的函数时，栈中会 push一个frame。当函数执行完毕返回时，该frame会pop，从而进入调用该函数的原函数，继续执行 许多语言利用栈数据结构来记录函数调用的次序和相关变量(参考Linux从程序到进程)。 在Java中，JVM中的栈记录了线程的方法调用。每个线程拥有一个栈。在某个线程的运行过程中，如果有新的方法调用，那么该线程对应的栈就会增加一个存储单元，即帧(frame)。在frame中，保存有该方法调用的参数、局部变量和返回地址。 Java的参数和局部变量只能是基本类型的变量(比如int)，或者对象的引用(reference)。因此，在栈中，只保存有基本类型的变量和对象引用。 引用所指向的对象保存在堆中。(引用可能为Null值，即不指向任何对象) 堆如上所述，栈(stack)可以自己照顾自己。但堆必须要小心对待。堆是JVM中一块可自由分配给对象的区域。当我们谈论垃圾回收(garbage collection)时，我们主要回收堆(heap)的空间。 Java的普通对象存活在堆中。与栈不同，堆的空间不会随着方法调用结束而清空。因此，在某个方法中创建的对象，可以在方法调用结束之后，继续存在于堆中。这带来的一个问题是，如果我们不断的创建新的对象，内存空间将最终消耗殆尽。 垃圾回收垃圾回收(garbage collection，简称GC)可以自动清空堆中不再使用的对象。垃圾回收机制最早出现于1959年，被用于解决Lisp语言中的问题。垃圾回收是Java的一大特征。并不是所有的语言都有垃圾回收功能。比如在C/C++中，并没有垃圾回收的机制。程序员需要手动释放堆中的内存。 由于不需要手动释放内存，程序员在编程中也可以减少犯错的机会。利用垃圾回收，程序员可以避免一些指针和内存泄露相关的bug(这一类bug通常很隐蔽)。但另一方面，垃圾回收需要耗费更多的计算时间。垃圾回收实际上是将原本属于程序员的责任转移给计算机。使用垃圾回收的程序需要更长的运行时间。 在Java中，对象的是通过引用使用的(把对象相像成致命的毒物，引用就像是用于提取毒物的镊子)。如果不再有引用指向对象，那么我们就再也无从调用或者处理该对象。这样的对象将不可到达(unreachable)。垃圾回收用于释放不可到达对象所占据的内存。这是垃圾回收的基本原则。 (不可到达对象是死对象，是垃圾回收所要回收的垃圾) 早期的垃圾回收采用引用计数(reference counting)的机制。每个对象包含一个计数器。当有新的指向该对象的引用时，计数器加1。当引用移除时，计数器减1。当计数器为0时，认为该对象可以进行垃圾回收。 然而，一个可能的问题是，如果有两个对象循环引用(cyclic reference)，比如两个对象互相引用，而且此时没有其它(指向A或者指向B)的引用，我们实际上根本无法通过引用到达这两个对象。 因此，我们以栈和static数据为根(root)，从根出发，跟随所有的引用，就可以找到所有的可到达对象。也就是说，一个可到达对象，一定被根引用，或者被其他可到达对象引用。 JVM实施JVM的垃圾回收是多种机制的混合。JVM会根据程序运行状况，自行决定采用哪种垃圾回收。 我们先来了解&quot;mark and sweep&quot;。这种机制下，每个对象将有标记信息，用于表示该对象是否可到达。当垃圾回收启动时，Java程序暂停运行。JVM从根出发，找到所有的可到达对象，并标记(mark)。随后，JVM需要扫描整个堆，找到剩余的对象，并清空这些对象所占据的内存。 另一种是&quot;copy and sweep&quot;。这种机制下，堆被分为两个区域。对象总存活于两个区域中的一个。当垃圾回收启动时，Java程序暂停运行。JVM从根出发，找到可到达对象，将可到达对象复制到空白区域中并紧密排列，修改由于对象移动所造成的引用地址的变化。最后，直接清空对象原先存活的整个区域，使其成为新的空白区域。 可以看到，”copy and sweep”需要更加复杂的操作，但也让对象可以紧密排列，避免”mark and sweep”中可能出现的空隙。在新建对象时，”copy and sweep”可以提供大块的连续空间。因此，如果对象都比较”长寿”，那么适用于”mark and sweep”。如果对象的”新陈代谢”比较活跃，那么适用于”copy and sweep”。 上面两种机制是通过分代回收(generational collection)混合在一起的。每个对象记录有它的世代(generation)信息。所谓的世代，是指该对象所经历的垃圾回收的次数。世代越久远的对象，在内存中存活的时间越久。 根据对Java程序的统计观察，世代越久的对象，越不可能被垃圾回收(富人越富，穷人越穷)。因此，当我们在垃圾回收时，要更多关注那些年轻的对象。 现在，具体看一下JVM中的堆: 我们看到，堆分为三代。其中的永久世代(permanent generation)中存活的是Class对象。这些对象不会被垃圾回收。我们在RTTI中已经了解到，每个Class对象代表一个类，包含有类相关的数据与方法，并提供类定义的代码。每个对象在创建时，都要参照相应的Class对象。每个对象都包含有指向其对应Class对象的引用。 年轻世代(young generation)和成熟世代(tenured generation)需要进行垃圾回收。年轻世代中的对象世代较近，而成熟世代中的对象世代较久。 年轻世代进一步分为三个区域 eden(伊甸): 新生对象存活于该区域。新生对象指从上次GC后新建的对象。 from, to: 这两个区域大小相等，相当于copy and sweep中的两个区域。 当新建对象无法放入eden区时，将出发minor collection。JVM采用copy and sweep的策略，将eden区与from区的可到达对象复制到to区。经过一次垃圾回收，eden区和from区清空，to区中则紧密的存放着存活对象。随后，from区成为新的to区， to区成为新的from区。 如果进行minor collection的时候，发现to区放不下，则将部分对象放入成熟世代。另一方面，即使to区没有满，JVM依然会移动世代足够久远的对象到成熟世代。 如果成熟世代放满对象，无法移入新的对象，那么将触发major collection。JVM采用mark and sweep的策略，对成熟世代进行垃圾回收。 总结以上是对JVM内存管理的一个概述。实际上，JVM拥有众多版本。不同版本实施的GC机制会有不小的差异。另一方面，Java本身并没有规定JVM的GC实施方式。GC依然是JVM发展的一个热点方向。我们可以预期JVM的GC机制在未来会发生许多变化。 另外，也可以参考这篇文章：一篇简单易懂的原理文章，让你把JVM玩弄与手掌之中 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/","raw":null,"content":null,"categories":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/categories/java/"}],"tags":[{"name":"GC","slug":"gc","permalink":"http://agehua.github.io/tags/gc/"},{"name":"JVM","slug":"jvm","permalink":"http://agehua.github.io/tags/jvm/"}]},{"title":"泛型的应用","slug":"Usage-of-genericity","date":"2018-04-22T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/04/23/Usage-of-genericity/","link":"","permalink":"http://agehua.github.io/2018/04/23/Usage-of-genericity/","excerpt":"我在之前转载过一篇Java泛型的介绍：JAVA 泛型通配符 T，E，K，V 区别，T 以及 Class，Class&lt;?&gt; 的区别\n最近在开发中遇到一个场景，想简化流程，突然发现可以使用泛型。这个场景就是，在手机上实现分页加载的功能时，把通用的数据映射成对象，然后使用泛型来替代具体业务类，从而封装出一个对应分页加载的类。","text":"我在之前转载过一篇Java泛型的介绍：JAVA 泛型通配符 T，E，K，V 区别，T 以及 Class，Class&lt;?&gt; 的区别 最近在开发中遇到一个场景，想简化流程，突然发现可以使用泛型。这个场景就是，在手机上实现分页加载的功能时，把通用的数据映射成对象，然后使用泛型来替代具体业务类，从而封装出一个对应分页加载的类。 有点绕，往下看： 泛型的应用在手机上实现分页加载功能，一般都会去服务器请求一个list，但除了list之外，可能还有其他通用的消息内容，比如下面的这个Json内容： &#123; \"list\": [&#123; \"description\": \"b\", \"editTime\": \"12/04/2018\", \"expireTime\": \"20/04/2018 16:30\", \"id\": 105, \"lang\": \"en\", \"sendTimeShort\": \"12/04/2018\", \"status\": \"3\", \"title\": \"a1\", \"unread\": \"1\" &#125;, ... &#123; \"description\": \"d20\", \"editTime\": \"10/04/2018\", \"expireTime\": \"11/04/2018 15:19\", \"id\": 78, \"lang\": \"en\", \"sendTimeShort\": \"10/04/2018\", \"status\": \"3\", \"title\": \"push notification\", \"unread\": \"1\" &#125;], \"pageNo\": 1, \"pageSize\": 10, \"totalCount\": 19, \"totalPages\": 2&#125; 可以发现上面的json串的末尾，是一些跟具体业务无关的固定格式的键值对，这些键值对可以是分页需要的信息，也可以是交易验等证信息。 上面除了通用信息，还有一个list，这个list就跟具体业务有关了，可以用泛型 &lt;T&gt;来代替。 针对上面的json，写出一个对象，代码如下： public class FCMModel&lt;T extends Parcelable&gt; implements Parcelable &#123; private int pageNo; //对应上面json里的键值对 private int totalPages; private int pageSize; private int totalCount; private ArrayList&lt;T&gt; list; private static String DATA_KEY = \"bean_key\";//这个值在序列化 ArrayList 的时候用到 //省略参数的 get 和 set 方法... public List&lt;T&gt; getList() &#123; return list; &#125; public void setList(ArrayList&lt;T&gt; list) &#123; this.list = list; &#125; //继承 Parcelable 必须的方法 public static final Creator&lt;FCMModel&gt; CREATOR = new Creator&lt;FCMModel&gt;() &#123; @Override public FCMModel createFromParcel(Parcel in) &#123; return new FCMModel(in); &#125; @Override public FCMModel[] newArray(int size) &#123; return new FCMModel[size]; &#125; &#125;; @Override public int describeContents() &#123; return 0; &#125; @Override public void writeToParcel(Parcel dest, int flags) &#123; dest.writeInt(this.pageNo); dest.writeInt(this.totalPages); dest.writeInt(this.pageSize); dest.writeInt(this.totalCount); Bundle bundle = new Bundle(); //注意ArrayList的序列化方法 bundle.putParcelableArrayList(DATA_KEY, list); dest.writeBundle(bundle); &#125; public FCMModel() &#123; &#125; protected FCMModel(Parcel in) &#123; this.pageNo = in.readInt(); this.totalPages = in.readInt(); this.pageSize = in.readInt(); this.totalCount = in.readInt(); this.list = in.readBundle().getParcelableArrayList(DATA_KEY); &#125; public static class NotificationListBean implements Parcelable &#123; //这个类只是一个业务类，除了实现Parcelable 接口外没有特殊方法，这里全部省略 ... &#125;&#125; 在上面的代码中，FCMModel就是抽象出来的类，它封装了分页功能中的通用数据，开发者可以只简单实现业务类就行了，是不是方便了一点点，哈哈。 fastjson 泛型转换 注意：在使用 fastjson 对有泛型存在的实体类做序列化时，必须要用到 com.alibaba.fastjson.TypeReference 类，否则会抛出 java.lang.ClassCastException 异常。 我是参考的这篇文章：fastJson泛型如何转换 针对本例子，应该这样使 fastjson 做转换： final static Type type = new TypeReference&lt;FCMModel&lt;FCMModel.NotificationListBean&gt;&gt;() &#123;&#125;.getType();List&lt;FCMModel.NotificationListBean&gt; mBeanList= new ArrayList&lt;&gt;();//...mFCMModel = JSON.parseObject(result.getDataStr(), type);mBeanList = mFCMModel.getList(); 这里的Type是 java.lang.reflect.Type 获取泛型的类型参数以kotlin语音为例，我们不能直接获取一个泛型的类型，比如：val listType = ArrayList&lt;String&gt;::class.java // 不被允许val mapType = Map&lt;String, String&gt;::class.java // 不被允许 如何获取一个泛型的具体类型呢，有两种方式： 使用匿名内部类先看下面的例子：val list1 = ArrayList&lt;String&gt;()val list2 = object: ArrayList&lt;String&gt;() &#123;&#125; // 使用object创建匿名内部类println(list1.javaClass.genericSuperclass)println(list2.javaClass.genericSuperclass) // 结果：java.util.AbstractList&lt;E&gt;java.util.ArrayList&lt;java.lang.String&gt; list2成功拿到了泛型的具体类型，这是因为 泛型类型擦除并不是真的将全部的类型信息都擦除，还是会将类型信息放在对应class的常量池中 匿名内部类在初始化的时候就会绑定父类或父接口的相应信息，这样就能通过获取父类或父接口的泛型信息来实现我们的需求。 我们来设计一个能获取所有类型的信息的泛型类： import java.lang.reflect.ParameterizedTypeimport java.lang.reflect.Typeopen class GenericsToken&lt;T&gt; &#123; var type : Type = Any::class.java init &#123; // 在初始化的时候就能拿到父类或父接口的类型信息 val superClass = this.javaClass.genericSuperclass type = (superClass as ParameterizedType).getActualTypeArguments()[0] &#125;&#125;// 使用：val gt = object: GenericsToken&lt;Map&lt;String, String&gt;&gt;() &#123;&#125; // 一个匿名内部类println(gt.type)// 结果：java.util.Map&lt;java.lang.String, ? extends java.lang.String&gt; 到这里再看下上面的fastjson是如何获取泛型类型的，是不是就可以为什么fastjson要这样写了？ 同理，Gson也是用的相同的设计 使用内联函数其实Kotlin中的内联函数在编译的时候，编译器也会将相应函数的字节码插入到调用的地方，参数类型也会插入到字节码中，这样我们就可以获取参数的类型了。inline fun &lt;reified T&gt; getType() &#123; // 关键字 reified return T::class.java&#125; 这里的意思相当于在编译的会将具体的类型插入响应的字节码中，那么我们就能在运行时获取到对应参数的类型了。所以可以在Kotlin中改进Gson的使用方式： inline fun &lt;reified T : Any&gt; Gson.fromJson(json: String) : T &#123; // 对 Gson.fromJson进行扩展 return Gson().fromJson(json, T::class.java)&#125;// 使用val json =\" ... \"val stringList = Gson().fromJson&lt;List&lt;String&gt;&gt;(json) // 只需传入json一个参数 reified 关键字带来的特性在Android开发中也格外有用，比如修改 startActivity 方法：inline fun &lt;reified T : Activity&gt; Activity.startActivity() &#123; startActivity(Intent(this, T::class.java))&#125;// 使用startActivity&lt;DetailActivity&gt;() 更多关于 reified 关键字的介绍可以看这篇文章：https://juejin.cn/post/6844903833596854279 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/04/23/Usage-of-genericity/","raw":null,"content":null,"categories":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/categories/java/"}],"tags":[{"name":"genericity","slug":"genericity","permalink":"http://agehua.github.io/tags/genericity/"}]},{"title":"投马-two drawbacks","slug":"Toastmaster-two-drawbacks","date":"2018-04-01T16:00:00.000Z","updated":"2023-11-16T03:42:40.848Z","comments":true,"path":"2018/04/02/Toastmaster-two-drawbacks/","link":"","permalink":"http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/","excerpt":"                   .-&apos; _..`.                           /  .&apos;_.&apos;.&apos;                 | .&apos; (.)`.                 ;&apos;   ,_   `. .--.__________.&apos;    ;  `.;-&apos;|  ./               /|  |               / `..&apos;`-._  _____, ..&apos;     / | |     | |\\ \\    / /| |     | | \\ \\   / / | |     | |  \\ \\  /_/  |_|     |_|   \\_\\","text":".-&apos; _..`. / .&apos;_.&apos;.&apos; | .&apos; (.)`. ;&apos; ,_ `. .--.__________.&apos; ; `.;-&apos;| ./ /| | / `..&apos;`-._ _____, ..&apos; / | | | |\\ \\ / /| | | | \\ \\ / / | | | | \\ \\ /_/ |_| |_| \\_\\ Good Afternoon, my dear colleagues. Today, I want to share my two drawbacks with you. Hope I can give you some inspirations or warnings. If you have the same feeling, you should also be aware of these two things.First I wanna tell is the smartphone. Second I wanna talk about the helloworld. Let me ask a question. What is the opposite word of work? You may say it is leisure, or vacation. Actually I don’t think so. Leisure is a busy thing. you need to plan what to do and where to go spend your leisure time. The opposite of work is idleness. We all spend much time on mobile phone, but I was worse. In my case, without smartphone, I can’t taste the flavor of the food. So What do I watch on the mobile phone? I usually watch fragmentation news and entertainment shows. When you watching these, You feel comfortable and joyful, but your brain doesn’t think deeply. And this is idleness. Every day, you feel no gains or no efficiency, that is because of idleness. When you get used to idleness, you will waste your concentration and lose your independent mind. In my opinion, concentration is more valuable than time. Because we all have the same 24 hours each day, but for concentration everyone and every day is different. So don’t waste your concentrations on your phone, or other fragmented information. And my solution is to put your phone far away from you, and spend at least 2 hours each day to stay alone. You can use this time to read a book, or to develop your own habit. And When you really concentrate on something, time flies. Now, back to the second part, the helloworld. I guess all programmers know helloworld means. It’s means a quick start of a programming language. As a software programmer, we need to learn different programming languages. We are very familiar with installing software, configuring development environment. Also, we know so many ways to say ‘Hello world’ using different languages. But we don’t know what to do next after those elementary courses. As far as I’m concerned, study is a lifelong work, we need to learn new knowledge to better ourselves. After coming through the quick start, we need use the new knowledge into practice. And don’t assume you can use it very well at the beginning. In this using process, we need to accept our clumsiness(笨拙), and keep using it even if the result is not good enough. For me, I found one way to use the new knowledge. I write blogs to keep notes. I hope this method can help you too. That’s all, thank you! 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/","raw":null,"content":null,"categories":[{"name":"english","slug":"english","permalink":"http://agehua.github.io/categories/english/"}],"tags":[{"name":"toastmaster","slug":"toastmaster","permalink":"http://agehua.github.io/tags/toastmaster/"}]},{"title":"IntentService和AsyncTask的区别","slug":"IntentService-AsyncTask","date":"2018-03-13T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/03/14/IntentService-AsyncTask/","link":"","permalink":"http://agehua.github.io/2018/03/14/IntentService-AsyncTask/","excerpt":"IntentService和AsyncTask的区别先说总结：Service：Service只适合处理长期后台执行的，这里的后台是指与前台Activity无关的东西，但跟Activity同样运行在UI线程。同时Service开销比Thread大，Service本身不能解决多线程问题。同一个Service多次启动，只会在第一次启动时回调onStart()或onBind()方法，并多次回调onStartCommand方法。","text":"IntentService和AsyncTask的区别先说总结：Service：Service只适合处理长期后台执行的，这里的后台是指与前台Activity无关的东西，但跟Activity同样运行在UI线程。同时Service开销比Thread大，Service本身不能解决多线程问题。同一个Service多次启动，只会在第一次启动时回调onStart()或onBind()方法，并多次回调onStartCommand方法。IntentService：IntentService，是一个抽象类。继承自Service，这使它的优先级比单纯的线程要高很多，同时内部封装了一个HandlerThread 和 Handler，导致它可以执行异步任务，所以它是比较适合一些高优先级的后台任务。HandlerThread是\b在子线程使用Handler的方式，内部实现了Loop循环 但是IntentService，内部队列是MessageQueue，多次调用同一个IntentService，只能是阻塞式执行任务，即当前个任务执行完才会取得下一个任务并执行。 IntentService 默认实现了 OnBind()，返回值为 null。在 onHandleIntent(Intent intent)回调中，处理耗时任务。 那么，用 IntentService 有什么好处呢？首先，可以省去了在 Service 中手动开线程的麻烦，第二，任务执行完后，IntentService 会自动停止，不用手动停止 Service。 AsyncTask也是一个抽象类，自定义一个类继承自AsyncTask。 AsyncTask内容节选自郭霖大神的这篇文章：Android AsyncTask完全解析，带你从源码的角度彻底理解 注意，AsyncTask有3个泛型参数： 1.Params: 在执行AsyncTask时需要传入的参数，可用于在后台任务中使用。 2.Progress: 后台任务执行时，如果需要在界面上显示当前的进度，则使用这里指定的泛型作为进度单位。 3.Result:当任务执行完毕后，如果需要对结果进行返回，则使用这里指定的泛型作为返回值类型。 一个最简单的自定义AsyncTask就可以写成如下方式：class DownloadTask extends AsyncTask&lt;Void, Integer, Boolean&gt; &#123; ……&#125; AsyncTask在Android 3.0之前同一时刻能够运行的线程数为5个，线程池总大小为128。也就是说当我们启动了10个任务时，只有5个任务能够立刻执行，另外的5个任务则需要等待，当有一个任务执行完毕后，第6个任务才会启动，以此类推。而线程池中最大能存放的线程数是128个，当我们尝试去添加第129个任务时，程序就会崩溃。 而3.0之后的AsyncTask同时只能有1个任务在执行。为什么升级之后可以同时执行的任务数反而变少了呢？这是因为更新后的AsyncTask已变得更加灵活，如果不想使用默认的线程池，还可以自由地进行配置。比如使用如下的代码来启动任务： Executor exec = new ThreadPoolExecutor(15, 200, 10, TimeUnit.SECONDS, new LinkedBlockingQueue&lt;Runnable&gt;()); new DownloadTask().executeOnExecutor(exec); 这样就可以使用我们自定义的一个Executor来执行任务，而不是使用SerialExecutor。上述代码的效果允许在同一时刻有15个任务正在执行，并且最多能够存储200个任务。 下面内容\b选自知乎里的\u001c一篇问答：《安卓中AsyncTask和thread以及Service和IntentService的关系和区别？》 什么是线程，同步和异步？ 1、同步：在一个线程执行，先执行完了前面的代码，才会执行后面的代码，是阻塞的。 2、异步：开启一个新的线程执行，不会等前面的代码执行完，就会执行后面的代码，是非阻塞的。 3、什么是main（UI）线程：android启动的第一个线程。主要负责处理ui和事件的工作。 【特别注意】 1)、更新ui只能在ui线程进行，不可以在其他线程更新ui，否则会崩溃。ActivityThread只是运行在UI线程，不等于UI线程。 2)、在ui线程不可以做耗时操作，比如网络请求等，如果做耗时操作，就会阻塞ui线程，就会导致界面卡顿。会出现ANR（application not response、应用无响应）。 4、异步通讯：那么我们要请求网络或者其他耗时操作的时候怎么办？这就涉及到异步通讯或者叫线程通讯。 先在子线程加载数据，做耗时操作，然后把取得的数据传递给ui线程，让ui线程来更新ui。 5、线程通讯的方式： 1)、Handler 在主线程中使用方法： (1)、在主线程实例化一个Hanlder，复写handleMessage()方法，在里面做更新ui的操作； (2)、让子线程持有handler的引用，使用handler来发送消息。 传递参数： 获取消息，请使用handler.obtainMessage(); what:用来区分消息的类型 obj：传递复杂参数 arg1:传递简单的int参数 arg2:传递简单的int参数 Handler的原理： (1)、在主线线程新建一个handler，在子线程中调用这个Handler发送消息到消息队列，在发送的时候，message.target会保存发送它的Handler； (2)、主线程只带一个looper循环，会不断的从消息队列中取出消息，如果没有消息，就阻塞，这里的阻塞并不会导致主线程，因为这里的阻塞底层采用的是Linux的pipe与epoll机制； (3)、在主线程中调用message.target（发送他的Handler）的DispatchMessage，间接调用handlerMeaage来处理消息。 在子线程中使用Handler： 因为使用Handler需要消息循环，子线程中没有消息循环，所以，这里有2中方法： (1)、使用主线程的loop（getMainLooper()），然后在创建Handler的时候，把这个获取的主线程的loop传进去；但是，这种方法，子线程中的Handler还是在主线程处理消息。因为用的主线程的循环。 (2)、给子线程建立消息循环：先调用 Looper.prepare();建立消息循环，消息队列等。在建立了Handler之后，调用Looper.loop()，开始loop循环，如果不掉用，循环就不会开始运行，就不会处理消息。 代码如下： new Thread(new Runnable() &#123; @Override public void run() &#123; Log.i(TAG, \"run: \"); //建立消息循环，建立消息队列 Looper.prepare(); han=new Handler()&#123; @Override public void handleMessage(Message msg) &#123; Log.i(TAG, \"handleMessage: \"+Thread.currentThread().getName()); &#125; &#125;; //开始loop循环 Looper.loop(); &#125;&#125;).start(); Handler的其他使用 (1)、hander.post()方法可以直接把一个代码post到主线程执行； handler.post(new Runnable() &#123; @Override public void run() &#123; //这里在主线程执行 &#125; &#125;); (2)、activity的runOnUITHread（）； runOnUiThread(new Runnable() &#123; @Override public void run() &#123; //这里在主线程执行 &#125;&#125;); (3)、任何控件的Post方法（）； tv.post(new Runnable() &#123; @Override public void run() &#123; //这里在主线程执行 &#125;&#125;); (4)、延时执行： handler.postDelayed(new Runnable() &#123; @Override public void run() &#123; //需要延时执行的代码 &#125; &#125;,1000); 2)、HandlerThread: 支持Handler的线程，内部实现了Loop循环 使用方法： //新建一个代loop的子线程final HandlerThread handlerThread=new HandlerThread(\"zixiancheng\");//让子线程开始执行handlerThread.start();//把线程的looper传给Hander运行，这样，这个Hander就在zixiancheng中执行了。handler=new Handler(handlerThread.getLooper()) 【 注意！！】 使用了这个HandlerThread，他会开启一个循环一直跑，所以，在退出程序的时候，一定要调用quit()，退出循环。 @Overrideprotected void onDestroy() &#123; handlerThread.quit(); super.onDestroy();&#125; 3)、AsyncTask:异步任务继承自AsyncTask，写一个自己的异步任务，注意，AsyncTask有3个泛型。 从做到又分别是：参数的类型，进度的类型，返回结果的类型。 execute()：执行这个异步任务，必须在主线程中调用 onPreExecute()：在执行异步任务之前调用 doInBackground()：执行任务的函数，比如去请求网络 publishProgress()：在请求的过程中，更新一下进度，会调用onProgressUpdate onProgressUpdate()：更新进度，在主线程中运行 onPostExecute()：请求完了以后，可以保存结果 cancel()：取消任务的时候调用。 以上，是关于线程通讯。 Service介绍： 1、startService： 特点： 仅仅需要长时间运行,不需要和其数据交互 使用stopService/stopself()停止服务 多次调用，onCreate方法只执行一次,onStartCommand多次执行 不与当前的Activity绑定，即使当前activity已经关闭了，服务也会继续运行 使用方法： 继承Service写一个类，实现自己的业务需要（onCreate、onStartCommand）； 然后在清单文件中申明； 在activity里面通过startService来启动这个服务； 2、bindService： 特点： 需要和其进行数据交互,使用Binder类 使用unbindService停止服务 当activity销毁之后对应绑定的service自动停止、销毁 不能跨进程通信绑定 不能在广播中调用 使用方式： 继承Service写一个类，实现自己的业务需要（onCreate、onBind）； 然后在清单文件中申明； 在activity里面通过bindService来启动这个服务，这里还需要一个参数，就是serviceConnection对象，通过这个对象来处理activity和Service绑定的事件； 如果要\bActivity和Service相互通讯，还需要使用Binder： 继承自Binder来实现一个自己的Binder，在service的onBind里面返回一个自己的Binder实例； public class MsgService extends Service &#123; //..... /** * 返回一个Binder对象 */ @Override public IBinder onBind(Intent intent) &#123; return new MsgBinder(); &#125; public class MsgBinder extends Binder&#123; /** * 获取当前Service的实例 * @return */ public MsgService getService()&#123; return MsgService.this; &#125; &#125;&#125; 在activity的ServiceConnection里面的onServiceConnected会把service里面的Binder的对象传递回来；我们可以在Binder里面，得到目标service的实例，这样，就可以和Service交互了。 这里的Activity和Service相互通讯，有三种方式： 1.得到Service引用后，直接调用\bMyService的\b具体方法。 2.使用接口，在Service内定义接口类，在Activity内得到MyService引用后，\b注册接口监听。 3.可以使用广播，当然Activity要注册相应的接收器。比如Service要向多个Activity发送同样的消息的话，用这种方法就更好 3、IntentService： 特点： 会自动开启一个子线程，子线程任务结束以后，会自动stop，不需要手动去stopService或者stopself()； 如果多次启动，会在一个队列中，依次的运行; 使用方法： 继承IntentService，实现自己的服务，然后重写onHandleIntent(),在里面做耗时操作； intentService在启动的时候，需要一个默认的构造函数； Service实现IPCService可以结合Messenger实现IPC，当然也可以使用AIDL的方式实现进程间通信。以Messenger为例，实现IPC分以下几个步骤： 1.service 内部需要有一个 Handler 的实现，它被用来处理从每一个 client 发送过的来请求 //MyService类内class ServiceHandler extends Handler &#123; @Override public void handleMessage(Message msg) &#123; switch (msg.what) &#123; default: super.handleMessage(msg); &#125; &#125;&#125; 2.通过这个 Handler ，来生成一个 Messenger //MyService类内final Messenger mMessenger = new Messenger(new ServiceHandler()); 3.在 service 的onBind() 方法中，需要向 client 返回由该 Messenger 生成的一个 IBinder 实例 @Overridepublic IBinder onBind(Intent intent) &#123; //返回给客户端一个IBinder实例 return mMessenger.getBinder();&#125; 4.client 使用从 service 返回的 IBinder 实例来初始化一个 Messenger， 然后使用该 Messenger 与 service 进行通信 //Activity类内部private ServiceConnection mConnection = new ServiceConnection() &#123; public void onServiceConnected(ComponentName className, IBinder service) &#123; //接收onBind()传回来的IBinder，并用它构造Messenger mService = new Messenger(service); mBound = true; &#125; public void onServiceDisconnected(ComponentName className) &#123; mService = null; mBound = false; &#125;&#125;; 5.service 通过它自身内部的 Handler 实现（ServiceHandler 的 handleMessage() 方法中）来处理从 client 发送过来的请求 //发送消息Message msg = Message.obtain();//fill your info into msgmessenger.send(msg); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/03/14/IntentService-AsyncTask/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"IntentService","slug":"intentservice","permalink":"http://agehua.github.io/tags/intentservice/"},{"name":"AsyncTask","slug":"asynctask","permalink":"http://agehua.github.io/tags/asynctask/"}]},{"title":"Android面试题积累(高阶)","slug":"IntervieweeQuestions-senior","date":"2018-02-28T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2018/03/01/IntervieweeQuestions-senior/","link":"","permalink":"http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/","excerpt":"\n转载自简书Android大厂面试题锦集(BAT TMD JD 小米)\n\n1.android事件分发机制，请详细说下整个流程","text":"转载自简书Android大厂面试题锦集(BAT TMD JD 小米) 1.android事件分发机制，请详细说下整个流程 2.android view绘制机制和加载过程，请详细说下整个流程 1.ViewRootImpl会调用performTraversals(),其内部会调用performMeasure()、performLayout、performDraw()。 2.performMeasure()会调用最外层的ViewGroup的measure()–&gt;onMeasure()。ViewGroup的onMeasure()是抽象方法，但其提供了measureChildren()，这之中会遍历子View然后循环调用measureChild()这之中会用getChildMeasureSpec()+父View的MeasureSpec+子View的LayoutParam一起获取本View的MeasureSpec，然后调用子View的measure()到View的onMeasure()–&gt;setMeasureDimension(getDefaultSize(),getDefaultSize()),getDefaultSize()默认返回measureSpec的测量数值，所以继承View进行自定义的wrap_content需要重写。 3.performLayout()会调用最外层的ViewGroup的layout(l,t,r,b),本View在其中使用setFrame()设置本View的四个顶点位置。在onLayout(抽象方法)中确定子View的位置，如LinearLayout会遍历子View，循环调用setChildFrame()–&gt;子View.layout()。 4.performDraw()会调用最外层ViewGroup的draw():其中会先后调用background.draw()(绘制背景)、onDraw()(绘制自己)、dispatchDraw()(绘制子View)、onDrawScrollBars()(绘制装饰)。 5.MeasureSpec由2位SpecMode(UNSPECIFIED、EXACTLY(对应精确值和match_parent)、AT_MOST(对应warp_content))和30位SpecSize组成一个int,DecorView的MeasureSpec由窗口大小和其LayoutParams决定，其他View由父View的MeasureSpec和本View的LayoutParams决定。ViewGroup中有getChildMeasureSpec()来获取子View的MeasureSpec。 6.三种方式获取measure()后的宽高： 1.Activity#onWindowFocusChange()中调用获取 2.view.post(Runnable)将获取的代码投递到消息队列的尾部。 3.ViewTreeObservable. 3.android四大组件的加载过程，请详细介绍下1.android四大组件的加载过程:请看这篇博客 4.Activity的启动模式1.standard:默认标准模式，每启动一个都会创建一个实例，2.singleTop：栈顶复用，如果在栈顶就调用onNewIntent复用，从onResume()开始3.singleTask：栈内复用，本栈内只要用该类型Activity就会将其顶部的activity出栈4.singleInstance：单例模式，除了3中特性，系统会单独给该Activity创建一个栈。 5.A、B、C、D分别是四种Activity的启动模式，那么A-&gt;B-&gt;C-&gt;D-&gt;A-&gt;B-&gt;C-&gt;D分别启动，最后的activity栈是怎么样的1.这个题目需要深入了解activity的启动模式2.最后的答案是：两个栈，前台栈是只有D，后台栈从底至上是A、B、C分前台栈和后台栈 6.Activity缓存方法1.配置改变导致Activity被杀死，横屏变竖屏：在onStop之前会调用onSaveInstanceState()保存数据在重建Activity之后，会在onStart()之后调用onRestoreInstanceState(),并把保存下来的Bundle传给onCreate()和它会默认重建Activity当前的视图，我们可以在onCreate()中，回复自己的数据。2.内存不足杀掉Activity，优先级分别是：前台可见，可见非前台，后台。 7.Service的生命周期，两种启动方法，有什么区别 1.context.startService() -&gt;onCreate()- &gt;onStart()-&gt;Service running–&gt;(如果调用context.stopService() )-&gt;onDestroy() -&gt;Service shut down 1.如果Service还没有运行，则调用onCreate()然后调用onStart()； 2.如果Service已经运行，则只调用onStart()，所以一个Service的onStart方法可能会重复调用多次。 3.调用stopService的时候直接onDestroy， 4.如果是调用者自己直接退出而没有调用stopService的话，Service会一直在后台运行。该Service的调用者再启动起来后可以通过stopService关闭Service。 2.context.bindService()-&gt;onCreate()-&gt;onBind()-&gt;Service running–&gt;onUnbind() -&gt; onDestroy() -&gt;Service stop 1.onBind将返回给客户端一个IBind接口实例，IBind允许客户端回调服务的方法，比如得到Service运行的状态或其他操作。 2.这个时候会把调用者和Service绑定在一起，Context退出了,Service就会调用onUnbind-&gt;onDestroy相应退出。 3.所以调用bindService的生命周期为：onCreate –&gt; onBind(只一次，不可多次绑定) –&gt; onUnbind –&gt; onDestory。 8.怎么保证service不被杀死1.提升service优先级2.提升service进程优先级3.onDestroy方法里重启service 9.静态的Broadcast 和动态的有什么区别1.动态的比静态的安全2.静态在app启动的时候就初始化了 动态使用代码初始化3.静态需要配置 动态不需要4.生存期，静态广播的生存期可以比动态广播的长很多5.优先级动态广播的优先级比静态广播高 10.Intent可以传递哪些数据类型1.Serializable2.charsequence: 主要用来传递String，char等3.parcelable4.Bundle 11.Json有什么优劣势、解析的原理1.JSON的速度要远远快于XML2.JSON相对于XML来讲，数据的体积小3.JSON对数据的描述性比XML较差4.解析的基本原理是：词法分析 12.一个语言的编译过程1.词法分析：将一串文本按规则分割成最小的结构，关键字、标识符、运算符、界符和常量等。一般实现方法是自动机和正则表达式2.语法分析：将一系列单词组合成语法树。一般实现方法有自顶向下和自底向上3.语义分析：对结构上正确的源程序进行上下文有关性质的审查4.目标代码生成5.代码优化：优化生成的目标代码， 13.动画有哪几类，各有什么特点 1.动画的基本原理：其实就是利用插值器和估值器，来计算出各个时刻View的属性，然后通过改变View的属性来，实现View的动画效果。 2.View动画: 只是影像变化，view的实际位置还在原来的地方。 3.帧动画是在xml中定义好一系列图片之后，使用AnimationDrawable来播放的动画。 4.View的属性动画： 1.插值器（Interpolator）：作用是根据时间的流逝的百分比来计算属性改变的百分比 2.估值器（TypeEvaluator）：在1的基础上由这个东西来计算出属性到底变化了多少数值的类 14.Handler、Looper消息队列模型，各部分的作用 1.MessageQueue：读取会自动删除消息，单链表维护，在插入和删除上有优势。在其next()中会无限循环，不断判断是否有消息，有就返回这条消息并移除。 2.Looper：Looper创建的时候会创建一个MessageQueue，调用loop()方法的时候消息循环开始，loop()也是一个死循环，会不断调用messageQueue的next()，当有消息就处理，否则阻塞在messageQueue的next()中。当Looper的quit()被调用的时候会调用messageQueue的quit(),此时next()会返回null，然后loop()方法也跟着退出。 3.Handler：在主线程构造一个Handler，然后在其他线程调用sendMessage(),此时主线程的MessageQueue中会插入一条message，然后被Looper使用。 4.系统的主线程在ActivityThread的main()为入口开启主线程，其中定义了内部类Activity.H定义了一系列消息类型，包含四大组件的启动停止。 5.MessageQueue和Looper是一对一关系，Handler和Looper是多对一 15.怎样退出终止App1.自己设置一个Activity的栈，然后一个个finish() 16.Android IPC:Binder原理 1.在Activity和Service进行通讯的时候，用到了Binder。 1.当属于同个进程我们可以继承Binder然后在Activity中对Service进行操作 2.当不属于同个进程，那么要用到AIDL让系统给我们创建一个Binder，然后在Activity中对远端的Service进行操作。 2.系统给我们生成的Binder： 1.Stub类中有:接口方法的id，有该Binder的标识，有asInterface(IBinder)(让我们在Activity中获取实现了Binder的接口，接口的实现在Service里，同进程时候返回Stub，\b不同进程则返回Proxy)，有onTransact() 这个方法是在不同进程的情况下，Proxy通过这个方法，在Activity进行远端调用实现Activity操作Service 2.Proxy类是代理，在Activity端，其中有:IBinder mRemote(这就是远端的Binder)，两个接口的实现方法不过是代理最终还是要在远端的onTransact()中进行实际操作。 3.哪一端的Binder是副本，该端就可以被另一端进行操作，因为Binder本体在定义的时候可以操作本端的东西。所以可以在Activity端传入本端的Binder，让Service端对其进行操作称为Listener，可以用RemoteCallbackList这个容器来装Listener，防止Listener因为经历过序列化而产生的问题。 4.当Activity端向远端进行调用的时候，当前线程会挂起，当方法处理完毕才会唤醒。 5.如果一个AIDL就用一个Service太奢侈，所以可以使用Binder池的方式，建立一个AIDL其中的方法是返回IBinder，然后根据方法中传入的参数返回具体的AIDL。 6.IPC的方式有：Bundle（在Intent启动的时候传入，不过是一次性的），文件共享(对于SharedPreference是特例，因为其在内存中会有缓存)，使用Messenger(其底层用的也是AIDL，同理要操作哪端，就在哪端定义Messenger)，AIDL，ContentProvider(在本进程中继承实现一个ContentProvider，在增删改查方法中调用本进程的SQLite，在其他进程中查询)，Socket17.描述一次跨进程通讯 1.client、proxy、serviceManager、BinderDriver、impl、service 2.client发起一个请求service信息的Binder请求到BinderDriver中，serviceManager发现BinderDiriver中有自己的请求 然后将clinet请求的service的数据返回给client这样完成了一次Binder通讯 3.clinet获取的service信息就是该service的proxy，此时调用proxy的方法，proxy将请求发送到BinderDriver中，此时service的 Binder线程池循环发现有自己的请求，然后用impl就处理这个请求最后返回，这样完成了第二次Binder通讯 4.中间client可挂起，也可以不挂起，有一个关键字oneway可以解决这个18.android重要术语解释 1.ActivityManagerServices，简称AMS，服务端对象，负责系统中所有Activity的生命周期 2.ActivityThread，App的真正入口。当开启App之后，会调用main()开始运行，开启消息循环队列，这就是传说中的UI线程或者叫主线程。与ActivityManagerServices配合，一起完成Activity的管理工作 3.ApplicationThread，用来实现ActivityManagerService与ActivityThread之间的交互。在ActivityManagerService需要管理相关Application中的Activity的生命周期时，通过ApplicationThread的代理对象与ActivityThread通讯。 4.ApplicationThreadProxy，是ApplicationThread在服务器端的代理，负责和客户端的ApplicationThread通讯。AMS就是通过该代理与ActivityThread进行通信的。 5.Instrumentation，每一个应用程序只有一个Instrumentation对象，每个Activity内都有一个对该对象的引用。Instrumentation可以理解为应用进程的管家，ActivityThread要创建或暂停某个Activity时，都需要通过Instrumentation来进行具体的操作。 6.ActivityStack，Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。 7.ActivityRecord，ActivityStack的管理对象，每个Activity在AMS对应一个ActivityRecord，来记录Activity的状态以及其他的管理信息。其实就是服务器端的Activity对象的映像。 8.TaskRecord，AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。如果你清楚Activity的4种launchMode，那么对这个概念应该不陌生。 19.理解Window和WindowManager 1.Window用于显示View和接收各种事件，Window有三种类型：应用Window(每个Activity对应一个Window)、子Window(不能单独存在，附属于特定Window)、系统window(Toast和状态栏) 2.Window分层级，应用Window在1-99、子Window在1000-1999、系统Window在2000-2999.WindowManager提供了增删改View三个功能。 3.Window是个抽象概念：每一个Window对应着一个View和ViewRootImpl，Window通过ViewRootImpl来和View建立联系，View是Window存在的实体，只能通过WindowManager来访问Window。 4.WindowManager的实现是WindowManagerImpl其再委托给WindowManagerGlobal来对Window进行操作，其中有四个List分别储存对应的View、ViewRootImpl、WindowManger.LayoutParams和正在被删除的View 5.Window的实体是存在于远端的WindowMangerService中，所以增删改Window在本端是修改上面的几个List然后通过ViewRootImpl重绘View，通过WindowSession(每个应用一个)在远端修改Window。 6.Activity创建Window：Activity会在attach()中创建Window并设置其回调(onAttachedToWindow()、dispatchTouchEvent()),Activity的Window是由Policy类创建PhoneWindow实现的。然后通过Activity#setContentView()调用PhoneWindow的setContentView。 20.Bitmap的处理 1.当使用ImageView的时候，可能图片的像素大于ImageView，此时就可以通过BitmapFactory.Option来对图片进行压缩，inSampleSize表示缩小2^(inSampleSize-1)倍。 2.BitMap的缓存： 1.使用LruCache进行内存缓存。 2.使用DiskLruCache进行硬盘缓存。 3.实现一个ImageLoader的流程：同步异步加载、图片压缩、内存硬盘缓存、网络拉取 1.同步加载只创建一个线程然后按照顺序进行图片加载 2.异步加载使用线程池，让存在的加载任务都处于不同线程 3.为了不开启过多的异步任务，只在列表静止的时候开启图片加载 21.如何实现一个网络框架(参考Volley) 1.缓存队列,以url为key缓存内容可以参考Bitmap的处理方式，这里单独开启一个线程。 2.网络请求队列，使用线程池进行请求。 3.提供各种不同类型的返回值的解析如String，Json，图片等等。 22.ClassLoader的基础知识 1.双亲委托：一个ClassLoader类负责加载这个类所涉及的所有类，在加载的时候会判断该类是否已经被加载过，然后会递归去他父ClassLoader中找。 2.可以动态加载Jar通过URLClassLoader 3.ClassLoader 隔离问题 JVM识别一个类是由：ClassLoader id+PackageName+ClassName。 4.加载不同Jar包中的公共类： 1.让父ClassLoader加载公共的Jar，子ClassLoader加载包含公共Jar的Jar，此时子ClassLoader在加载公共Jar的时候会先去父ClassLoader中找。(只适用Java) 2.重写加载包含公共Jar的Jar的ClassLoader，在loadClass中找到已经加载过公共Jar的ClassLoader，也就是把父ClassLoader替换掉。(只适用Java) 3.在生成包含公共Jar的Jar时候把公共Jar去掉。 23.插件化框架描述：dynamicLoadApk为例子 1.可以通过DexClassLoader来对apk中的dex包进行加载访问 2.如何加载资源是个很大的问题，因为宿主程序中并没有apk中的资源，所以调用R资源会报错，所以这里使用了Activity中的实现ContextImpl的getAssets()和getResources()再加上反射来实现。 3.由于系统启动Activity有很多初始化动作要做，而我们手动反射很难完成，所以可以采用接口机制，将Activity的大部分生命周期提取成接口，然后通过代理Activity去调用插件Activity的生命周期。同时如果想增加一个新生命周期方法的时候，只需要在接口中和代理中声明一下就行。 4.缺点： 1.慎用this，因为在apk中使用this并不代表宿主中的activity，当然如果this只是表示自己的接口还是可以的。除此之外可以使用that代替this。 2.不支持Service和静态注册的Broadcast 3.不支持LaunchMode和Apk中Activity的隐式调用。 24.热修复：Andfix为例子 1.大致原理：apkpatch（阿里Andfix提供的工具包）将两个apk做一次对比，然后找出不同的部分。可以看到生成的apatch了文件，后缀改成zip再解压开，里面有一个dex文件。通过jadx查看一下源码，里面就是被修复的代码所在的类文件,这些更改过的类都加上了一个_CF的后缀，并且变动的方法都被加上了一个叫@MethodReplace的annotation，通过clazz和method指定了需要替换的方法。然后客户端sdk得到补丁文件后就会根据annotation来寻找需要替换的方法。最后由JNI层完成方法的替换。 2.无法添加新类和新的字段、补丁文件很容易被反编译、加固平台可能会使热补丁功能失效 25.线程同步的问题，常用的线程同步 1.sycn：保证了原子性、可见性、有序性 2.锁：保证了原子性、可见性、有序性 1.自旋锁:可以使线程在没有取得锁的时候，不被挂起，而转去执行一个空循环。 1.优点:线程被挂起的几率减少，线程执行的连贯性加强。用于对于锁竞争不是很激烈，锁占用时间很短的并发线程。 2.缺点:过多浪费CPU时间，有一个线程连续两次试图获得自旋锁引起死锁 2.阻塞锁:没得到锁的线程等待或者挂起，Sycn、Lock 3.可重入锁:一个线程可多次获取该锁，Sycn、Lock 4.悲观锁:每次去拿数据的时候都认为别人会修改，所以会阻塞全部其他线程 Sycn、Lock 5.乐观锁:每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。cas 6.显示锁和内置锁:显示锁用Lock来定义、内置锁用synchronized。 7.读-写锁:为了提高性能，Java提供了读 3.volatile 1.只能保证可见性，不能保证原子性 2.自增操作有三步，此时多线程写会出现问题 4.CAS (Compare and swap) 1.操作:内存值V、旧的预期值A、要修改的值B，当且仅当预期值A和内存值V相同时，将内存值修改为B并返回true，否则什么都不做并返回false。 2.解释:本地副本为A，共享内存为V，线程A要把V修改成B。某个时刻线程A要把V修改成B，如果A和V不同那么就表示有其他线程在修改V，此时就表示修改失败，否则表示没有其他线程修改，那么把V改成B。 3.局限:如果V被修改成V1然后又被改成V，此时cas识别不出变化，还是认为没有其他线程在修改V，此时就会有问题 4.局限解决:将V带上版本。 5.线程不安全到底是怎么回事： 1.一个线程写，多个线程读的时候，会造成写了一半就去读 2.多线程写，会造成脏数据 26.Asynctask和线程池，GC相关（怎么判断哪些内存该GC，GC算法） 1.Asynctask：异步任务类，单线程线程池+Handler 2.线程池： 1.ThreadPoolExecutor：通过Executors可以构造单线程池、固定数目线程池、不固定数目线程池。 2.ScheduledThreadPoolExecutor：可以延时调用线程或者延时重复调度线程。 3.GC相关：重要 1.搜索算法： 1.引用计数 2.图搜索，可达性分析 2.回收算法： 1.标记清除复制：用于青年代 2.标记整理：用于老年代 3.堆分区： 1.青年区eden 80%、survivor1 10%、survivor2 10% 2.老年区 4.虚拟机栈分区： 1.局部变量表 2.操作数栈 3.动态链接 4.方法返回地址 5.GC Roots: 1.虚拟机栈(栈桢中的本地变量表)中的引用的对象 2.方法区中的类静态属性引用的对象 3.方法区中的常量引用的对象 4.本地方法栈中JNI的引用的对象 27.网络 1.ARP协议:在IP以太网中，当一个上层协议要发包时，有了该节点的IP地址，ARP就能提供该节点的MAC地址。 2.HTTP HTTPS的区别: 1.HTTPS使用TLS(SSL)进行加密 2.HTTPS缺省工作在TCP协议443端口 3.它的工作流程一般如以下方式: 1.完成TCP三次同步握手 2.客户端验证服务器数字证书，通过，进入步骤3 3.DH算法协商对称加密算法的密钥、hash算法的密钥 4.SSL安全加密隧道协商完成 5.网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改 3.http请求包结构，http返回码的分类，400和500的区别 1.包结构： 1.请求：请求行、头部、数据 2.返回：状态行、头部、数据 2.http返回码分类：1到5分别是，消息、成功、重定向、客户端错误、服务端错误 4.Tcp 1.可靠连接，三次握手，四次挥手 1.三次握手：防止了服务器端的一直等待而浪费资源，例如只是两次握手，如果s确认之后c就掉线了，那么s就会浪费资源 1.syn-c = x，表示这消息是x序号 2.ack-s = x + 1，表示syn-c这个消息接收成功。syn-s = y，表示这消息是y序号。 3.ack-c = y + 1，表示syn-s这条消息接收成功 2.四次挥手：TCP是全双工模式 1.fin-c = x , 表示现在需要关闭c到s了。ack-c = y,表示上一条s的消息已经接收完毕 2.ack-s = x + 1，表示需要关闭的fin-c消息已经接收到了，同意关闭 3.fin-s = y + 1，表示s已经准备好关闭了，就等c的最后一条命令 4.ack-c = y + 1，表示c已经关闭，让s也关闭 3.滑动窗口，停止等待、后退N、选择重传 4.拥塞控制，慢启动、拥塞避免、加速递减、快重传快恢复 28.数据库性能优化：索引和事务，需要找本专门的书大概了解一下29.APK打包流程和其内容1.流程 1.aapt生成R文件 2.aidl生成java文件 3.将全部java文件编译成class文件 4.将全部class文件和第三方包合并成dex文件 5.将资源、so文件、dex文件整合成apk 6.apk签名 7.apk字节对齐 2.内容：so、dex、asset、资源文件 30.网络劫持的类型原理：可以百度一下了解一下具体概念 1.DNS劫持、欺骗、污染 2.http劫持：重定向、注入js，http注入、报文扩展 1.java类加载过程： 1.加载时机：创建实例、访问静态变量或方法、反射、加载子类之前 2.验证：验证文件格式、元数据、字节码、符号引用的正确性 3.加载：根据全类名获取文件字节流、将字节流转化为静态储存结构放入方法区、生成class对象 4.准备：在堆上为静态变量划分内存 5.解析：将常量池中的符号引用转换为直接引用 6.初始化：初始化静态变量 7.书籍推荐：深入理解java虚拟机，博客推荐：Java/Android阿里面试JVM部分理解32.retrofit的了解 1.动态代理创建一个接口的代理类 2.通过反射解析每个接口的注解、入参构造http请求 3.获取到返回的http请求，使用Adapter解析成需要的返回值。 33.bundle的数据结构，如何存储 1.键值对储存 2.传递的数据可以是boolean、byte、int、long、float、double、string等基本类型或它们对应的数组，也可以是对象或对象数组。 3.当Bundle传递的是对象或对象数组时，必须实现Serializable 或Parcelable接口 34.listview内点击buttom并移动的事件流完整拦截过程：1.点下按钮的时候： 1.产生了一个down事件，activity–&gt;phoneWindow–&gt;ViewGroup–&gt;ListView–&gt;botton,中间如果有重写了拦截方法，则事件被该view拦截可能消耗。 2.没拦截，事件到达了button，这个过程中建立了一条事件传递的view链表 3.到button的dispatch方法–&gt;onTouch–&gt;view是否可用–&gt;Touch代理 2.移动点击按钮的时候: 1.产生move事件，listView中会对move事件做拦截 2.此时listView会将该滑动事件消费掉 3.后续的滑动事件都会被listView消费掉 3.手指抬起来时候：前面建立了一个view链表，listView的父view在获取事件的时候，会直接取链表中的listView让其进行事件消耗。 35.service的意义：不需要界面，在后台执行的程序36.android的IPC通信方式，线程（进程间）通信机制有哪些 1.ipc通信方式：binder、contentprovider、socket 2.操作系统进程通讯方式：共享内存、socket、管道 37.操作系统进程和线程的区别 1.简而言之,一个程序至少有一个进程,一个进程至少有一个线程. 2.线程的划分尺度小于进程，使得多线程程序的并发性高。 3.另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。 4.多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配 38.HashMap的实现过程：Capacity就是buckets的数目，Load factor就是buckets填满程度的最大比例。如果对迭代性能要求很高的话不要把capacity设置过大，也不要把load factor设置过小。 1.简单来说HashMap就是一个会自动扩容的数组链表 2.put过程 1.对key的hashCode()做hash，然后再计算index; 2.如果没碰撞直接放到bucket里； 3.如果碰撞了，以链表的形式存在buckets后； 4.如果碰撞导致链表过长(大于等于TREEIFY_THRESHOLD)，就把链表转换成红黑树； 5.如果节点已经存在就替换old value(保证key的唯一性) 6.如果bucket满了(超过load factor*current capacity)，就要resize。 3.resize：当put时，如果发现目前的bucket占用程度已经超过了Load Factor所希望的比例，那么就会发生resize。在resize的过程，简单的说就是把bucket扩充为2倍，之后重新计算index，把节点再放到新的bucket中 4.get过程 1.根据key的hash算出数组下表 2.使用equals遍历链表进行比较39.mvc、mvp、mvvm： 1.mvc:数据、View、Activity，View将操作反馈给Activity，Activitiy去获取数据，数据通过观察者模式刷新给View。循环依赖 1.Activity重，很难单元测试 2.View和Model耦合严重 2.mvp:数据、View、Presenter，View将操作给Presenter，Presenter去获取数据，数据获取好了返回给Presenter，Presenter去刷新View。PV，PM双向依赖 1.接口爆炸 2.Presenter很重 3.mvvm:数据、View、ViewModel，View将操作给ViewModel，ViewModel去获取数据，数据和界面绑定了，数据更新界面更新。 1.viewModel的业务逻辑可以单独拿来测试 2.一个view 对应一个 viewModel 业务逻辑可以分离，不会出现全能类 3.数据和界面绑定了，不用写垃圾代码，但是复用起来不舒服 40.java的线程如何实现 1.Thread继承 2.Runnale 3.Future 4.线程池41.ArrayList 如何删除重复的元素或者指定的元素； 1.删除重复：Set 2.删除指定：迭代器42.如何设计在 UDP 上层保证 UDP 的可靠性传输； 1.简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的超时重传，有序接受，应答确认，滑动窗口流量控制等机制,等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制。 2.比如使用UDP数据包+序列号，UDP数据包+时间戳等方法，在服务器端进行应答确认机制，这样就会保证不可靠的UDP协议进行可靠的数据传输。 3.基于udp的可靠传输协议有：RUDP、RTP、UDT 43.Java 中内部类为什么可以访问外部类1.因为内部类创建的时候，需要外部类的对象，在内部类对象创建的时候会把外部类的引用传递进去 44.设计移动端的联系人存储与查询的功能，要求快速搜索联系人，可以用到哪些数据结构？数据库索引，平衡二叉树(B树、红黑树) 45.红黑树特点 1.root节点和叶子节点是黑色 2.红色节点后必须为黑色节点 3.从root到叶子每条路径的黑节点数量相同46.linux异步和同步i/o: 1.同步：对于client，client一直等待，但是client不挂起：主线程调用 2.异步：对于client，client发起请求，service好了再回调client：其他线程调用，调用完成之后进行回调 3.阻塞：对于service，在准备io的时候会将service端挂起，直至准备完成然后唤醒service：bio 3.非阻塞：对于service，在准备io的时候不会将service端挂起，而是service一直去轮询判断io是否准备完成，准备完成了就进行操作：nio、linux的select、poll、epoll 4.多路复用io：非阻塞io的一种优化，java nio，用一个线程去轮询多个 io端口是否可用，如果一个可用就通知对应的io请求，这使用一个线程轮询可以大大增强性能。 1.我可以采用 多线程+ 阻塞IO 达到类似的效果，但是由于在多线程 + 阻塞IO 中，每个socket对应一个线程，这样会造成很大的资源占用。 2.而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。 5.异步io：aio，用户线程完全不感知io的进行，所有操作都交给内核，io完成之后内核通知用户线程。 1.这种io才是异步的，2、3、4都是同步io，因为内核进行数据拷贝的过程都会让用户线程阻塞。 2.异步IO是需要操作系统的底层支持，也就是内核支持，Java 7中，提供了Asynchronous IO 47.ConcurrentHashMap内部实现，HashTable的实现被废弃的原因: 1.HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。 2.ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock，在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构， 一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护者一个HashEntry数组里的元素,当对HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁。 48.HandlerThread是什么1.MessageQueue + Looper + Handler 49.IntentService是什么1.含有HandlerThread的Service，可以多次startService()来多次在子线程中进行 onHandlerIntent()的调用。 50.class和dex 1.dvm执行的是dex格式文件，jvm执行的是class文件，android程序编译完之后生产class文件。然后dex工具会把class文件处理成dex文件，然后把资源文件和.dex文件等打包成apk文件。 2.dvm是基于寄存器的虚拟机，而jvm执行是基于虚拟栈的虚拟机。寄存器存取速度比栈快的多，dvm可以根据硬件实现最大的优化，比较适合移动设备。 3.class文件存在很多的冗余信息，dex工具会去除冗余信息，并把所有的class文件整合到dex文件中。减少了I/O操作，提高了类的查找速度51.内存泄漏 1.其他线程持有一个Listener，Listener操作activity。那么在线程么有完毕的时候，activity关闭了，原本是要被回收的但是，不能被回收。 2.例如Handler导致的内存泄漏，Handler就相当于Listener。 3.在activity关闭的时候注意停止线程，或者将Listener的注册取消 3.使用弱引用，这样即使Listener持有了activity，在GC的时候还是会被回收 4.工具:LeakCanary 52.过度绘制、卡顿优化: 1.过度绘制： 1.移除Window默认的Background：getWidow.setBackgroundDrawable(null); 2.移除XML布局文件中非必需的Background 3.减少布局嵌套(扁平化的一个体现，减少View数的深度，也就减少了View树的遍历时间，渲染的时候，前后期的工作，总是按View树结点来) 4.在引入布局文件里面，最外层可以用merge替代LinearLayout,RelativeLayout，这样把子UI元素直接衔接在include位置 5.工具：HierarchyViewer 查看视图层级 2.卡顿优化：16ms数据更新 53.apk瘦身: 1.classes.dex：通过代码混淆，删掉不必要的jar包和代码实现该文件的优化 2.资源文件：通过Lint工具扫描代码中没有使用到的静态资源 3.图片资源：使用tinypng和webP，下面详细介绍图片资源优化的方案,矢量图 4.SO文件将不用的去掉，目前主流app一般只放一个arm的so包 54.ANR的形成，各个组件上出现ARN的时间限制是多少 1.只要是主线程耗时的操作就会ARN 如io 2.broadcast超时时间为10秒 按键无响应的超时时间为5秒 前台service无响应的超时时间为20秒，后台service为200秒 55.Serializable和Parcelable 的区别 1.P 消耗内存小 2.网络传输用S 程序内使用P 3.S将数据持久化方便 4.S使用了反射 容易触发垃圾回收 比较慢 56.Sharedpreferences源码简述 1.储存于硬盘上的xml键值对，数据多了会有性能问题 2.ContextImpl记录着SharedPreferences的重要数据，文件路径和实例的键值对 3.在xml文件全部内加载到内存中之前，读取操作是阻塞的，在xml文件全部内加载到内存中之后，是直接读取内存中的数据 4.apply因为是异步的没有返回值, commit是同步的有返回值能知道修改是否提交成功 5.多并发的提交commit时，需等待正在处理的commit数据更新到磁盘文件后才会继续往下执行，从而降低效率; 而apply只是原子更新到内存，后调用apply函数会直接覆盖前面内存数据，从一定程度上提高很多效率。 3.edit()每次都是创建新的EditorImpl对象. 6.博客推荐：全面剖析SharedPreferences 57.操作系统如何管理内存的： 1.使用寄存器进行将进程地址和物理内存进行映射 2.虚拟内存进行内存映射到硬盘上增大内存 3.虚拟内存是进行内存分页管理 4.页表实现分页，就是 页+地址偏移。 5.如果程序的内存在硬盘上，那么就需要用页置换算法来将其调入内存中：先进先出、最近未使用最少等等 6.博客推荐：现代操作系统部分章节笔记 58.浏览器输入地址到返回结果发生了什么 1.DNS解析 2.TCP连接 3.发送HTTP请求 4.服务器处理请求并返回HTTP报文 5.浏览器解析渲染页面 6.连接结束59.java泛型类型擦除发生在什么时候，通配符有什么需要注意的。 1.发生在编译的时候 2.PECS，extends善于提供精确的对象 A是B的子集，Super善于插入精确的对象 A是B的超集 3.博客推荐：Effective Java笔记（不含反序列化、并发、注解和枚举）、android阿里面试java基础锦集 60.activity的生命周期 1.a启动b，后退键再到a的生命周期流程：a.create–&gt;a.start–&gt;a.resume–&gt;a.pause–&gt;b.create–&gt;b.start–&gt;b.resume–&gt;b界面绘制–&gt;a.stop–&gt;b.pause–&gt;a.restart–&gt;a.start–&gt;a.resume–&gt;b.stop–&gt;b.destroy 2.意外销毁会调用saveInstance，重新恢复的时候回调用restoreInstance。储存数据的时候使用了委托机制，从activity–&gt;window–&gt;viewGroup–&gt;view 会递归调用save来保持本view的数据，restore则是递归恢复本view数据。我们可以在里面做一些自己需要的数据操作。 从图中可以得出两点总结： 当跳转到另一个Activity时，总是要等到另一个Activity的onResume方法执行完才会返回当前Activity的生命周期继续执行 当跳转到另一个Activity时，总是要等到当前的Activity的onPause方法执行完才会执行另一个Activity的生命周期（onCreate或onRestart） 61.面试常考的算法 1.快排、堆排序为首的各种排序算法 2.链表的各种操作：判断成环、判断相交、合并链表、倒数K个节点、寻找成环节点 3.二叉树、红黑树、B树定义以及时间复杂度计算方式 4.动态规划、贪心算法、简单的图论 5.推荐书籍：算法导论，将图论之前的例子写一遍62.Launcher进程启动另外一个进程的过程：启动一个app63.开源框架源码 1.Fresco 1.mvc框架： 1.Controller控制数据显示在Hierarchy中的Drawable的显隐 2.ImagePipeline在Controller中负责进行数据获取，返回的数据是CloseableImage 3.Drawee把除了初始化之外的操作全部交给Holder去做，Holder持有Controller和Hierarchy 2.Drawable层次以及绘制： 1.如果要绘制一次Drawable就调用invalidateSelf()来触发onDraw() 2.Drawable分为：容器类(保存一些Drawable)、自我绘制类(进度条)、图形变换类(scale、rotate、矩阵变换)、动画类(内部不断刷新，进行webp和gif的帧绘制) 3.ImagePipeline返回的CloseableImage是由一个个DrawableFactory解析成Drawable的 4.webp和gif动画是由jni代码解析的，然后其他静态图片是根据不同的android平台使用BitmapFactory来解析的 3.职责链模式：producer不做操作标n，表示只是提供一个consumer。获取图片–》解码图片缓存Producer–》后台线程Producer–》client图片处理producer(n)–》解码producer(n)–》旋转或剪裁producer(n)–》编码图片内存缓存producer–》读硬盘缓存producer–》写硬盘缓存producer(n)–》网络producer提供CloseableImage《–解码图片缓存consumer《–client图片处理consumer《–解码consumer《–旋转或剪裁consumer《–编码图片内存缓存consumer《–写硬盘缓存consumer《–图片数据 4.内存缓存： 1.一个CountingLruMap保存已经没有被引用的缓存条目，一个CountingLruMap保存所有的条目包括没有引用的条目。每当缓存策略改变和一定时间缓存配置的更新的时候，就会将 待销毁条目Map中的条目一个个移除，直到缓存大小符合配置。 2.这里的引用计数是用Fresco组件实现的引用计数器。 3.缓存有一个代理类，用来追踪缓存的存取。 4.CountingLruMap是使用LinkedHashMap来储存数据的。 5.硬盘缓存： 1.DefaultDiskStorage使用Lru策略。 2.为了不让所有的文件集中在一个文件中，创建很多命名不同的文件夹，然后使用hash算法把缓存文件分散 3.DiskStorageCache封装了DefaultDiskStorage，不仅进行缓存存取追踪，并且其在内存里面维持着一个 的键值对，因为文件修改频繁，所有只是定时刷新，因此如果在内存中找不到，还要去硬盘中找一次。 4.删除硬盘的缓存只出现在硬盘数据大小超限的时候，此时同时也会删除缓存中的key，所以不会出现内存中有key，但是硬盘上没有的情况。 5.在插入硬盘数据的时候，采用的是插入器的形式。返回一个Inserter，在Inserter.writeData()中传入一个CallBack(里面封装了客户端插入数据的逻辑和文件引用)，让内部实现调用CallBack的逻辑来插入文件数据，前面写的文件后缀是.temp,只有调用commit()之后才会修改后缀，让文件对客户端可见。 6.使用了java提供的FileTreeVisitor来遍历文件 6.对象池： 1.使用数组来存储一个桶，桶内部是一个Queue。数组下标是数据申请内存的byte大小，桶内部的Queue存的是内存块的。所以数组使用的是稀疏数组 2.申请内存的方式有两种 1.java堆上开辟的内存 2.ashme 的本地内存中开辟的内存 7.设计模式：Builder、职责链、观察者、代理、组合、享元、适配器、装饰者、策略、生产者消费者、提供者 8.自定义计数引用：类似c++智能指针 1.使用一个静态IdentityHashMap &lt;储存需要被计数引用的对象,其被引用的次数&gt; 2.用SharedReference分装需要被计数引用的对象，提供一个销毁资源的销毁器，提供一个静态工厂方法来复制自己，复制一个引用计数加一。提供一个方法销毁自己，表示自己需要变成无人引用的对象了，此时引用计数减一。 3.引用计数归零，销毁器将销毁资源，如bitmap的recycle或者是jni内存调用jni方法归还内存。 9.博客推荐：Android Fresco源码文档翻译、从零开始撸一个Fresco之硬盘缓存 2.oKhttp： 1.同步和异步： 1.异步使用了Dispatcher来将存储在 Deque 中的请求分派给线程池中各个线程执行。 2.当任务执行完成后，无论是否有异常，finally代码段总会被执行，也就是会调用Dispatcher的finished函数，它将正在运行的任务Call从队列runningAsyncCalls中移除后，主动的把缓存队列向前走了一步。 2.连接池： 1.一个Connection封装了一个socket，ConnectionPool中储存s着所有的Connection，StreamAllocation是引用计数的一个单位 2.当一个请求获取一个Connection的时候要传入一个StreamAllocation，Connection中存着一个弱引用的StreamAllocation列表，每当上层应用引用一次Connection，StreamAllocation就会加一个。反之如果上层应用不使用了，就会删除一个。 .ConnectionPool中会有一个后台任务定时清理StreamAllocation列表为空的Connection。5分钟时间，维持5个socket 3.选择路线与建立连接 1.选择路线有两种方式： 1.无代理，那么在本地使用DNS查找到ip，注意结果是数组，即一个域名有多个IP，这就是自动重连的来源 2.有代理HTTP：设置socket的ip为代理地址的ip，设置socket的端口为代理地址的端口 3.代理好处：HTTP代理会帮你在远程服务器进行DNS查询，可以减少DNS劫持。 2.建立连接 1.连接池中已经存在连接，就从中取出(get)RealConnection，如果没有命中就进入下一步 2.根据选择的路线(Route)，调用Platform.get().connectSocket选择当前平台Runtime下最好的socket库进行握手 3.将建立成功的RealConnection放入(put)连接池缓存 4.如果存在TLS，就根据SSL版本与证书进行安全握手 5.构造HttpStream并维护刚刚的socket连接，管道建立完成 4.职责链模式：缓存、重试、建立连接等功能存在于拦截器中网络请求相关，主要是网络请求优化。网络请求的时候遇到的问题 5.博客推荐：Android数据层架构的实现 上篇、Android数据层架构的实现 下篇 3.okio 1.简介； 1.sink：自己–》别人 2.source：别人–》自己 3.BufferSink：有缓存区域的sink 4.BufferSource：有缓存区域的source 5.Buffer：实现了3、4的缓存区域，内部有Segment的双向链表，在在转移数据的时候，只需要将指针转移指向就行 2.比java io的好处： 1.减少内存申请和数据拷贝 2.类少，功能齐全，开发效率高 3.内部实现： 1.Buffer的Segment双向链表，减少数据拷贝 2.Segment的内部byte数组的共享，减少数据拷贝 3.SegmentPool的共享和回收Segment 4.sink和source中被实际操作的其实是Buffer，Buffer可以充当sink和source 5.最终okio只是对java io的封装，所有操作都是基于java io 的 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"},{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"}]},{"title":"mac终端命令大全介绍","slug":"Mac-terminal-command","date":"2018-02-23T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2018/02/24/Mac-terminal-command/","link":"","permalink":"http://agehua.github.io/2018/02/24/Mac-terminal-command/","excerpt":"OSX 的文件系统\n转载自：https://www.douban.com/note/75797151/\n\nOSX 采用的Unix文件系统，所有文件都挂在跟目录 /下面，所以不在要有Windows 下的盘符概念。你在桌面上看到的硬盘都挂在 /Volumes 下。","text":"OSX 的文件系统 转载自：https://www.douban.com/note/75797151/ OSX 采用的Unix文件系统，所有文件都挂在跟目录 /下面，所以不在要有Windows 下的盘符概念。你在桌面上看到的硬盘都挂在 /Volumes 下。 比如接上个叫做 USBHD的移动硬盘，桌面上会显示出一个硬盘图标，它实际在哪里呢？在终端里执行 ls /Volumes/USBHD, 看看显示出的是不是这个移动硬盘的内容。 根目录位置是 /, 核心 Mach_kernel 就在这里，驱动所在位置 /Systme/Library/Extensions用户文件夹位置 /User/用户名桌面的位置 /User/用户名/Desktop文件通配符为星号 * 注意：在 Unix系统中是区别大小写字符的，A.txt 不等于 a.txt。 根目录标志 / 不是可有可无，cd /System 表示转到跟目录下的System中，而cd System 表示转到当前目录下的 System中 如何进入命令行操作模式再图形界面下，用finder 打开 应用程序 –&gt;实用程序–&gt;终端如果连图形界面都进不去了（比如安错了显示驱动），开机时按 F8，用－s参数启动，然后输入命令 mount -uw / 获得权限为了防止误操作破坏系统，再用户状态下时没有权限操作系统重要文件的，所以先要取得root权限sudo －s 然后输入密码，输入密码时没有任何回显，连星号都没有，只管输完回车就行了。 基本命令 列出文件ls 参数 目录名例: 想看看跟目录下有什么，ls /想看看驱动目录下有什么，ls /System/Library/Extensions参数 -w 显示中文，-l 详细信息， -a 包括隐藏文件 转换目录cd例：想到驱动目录下溜达一圈cd /System/Library/Extensions 建立新目录mkdir 目录名例：在驱动目录下建一个备份目录 backupmkdir /System/Library/Extensions/backup在桌面上建一个备份目录 backupmkdir /User/用户名/Desktop/backup 拷贝文件cp 参数 源文件 目标文件例：想把桌面的Natit.kext 拷贝到驱动目录中cp -R /User/用户名/Desktop/Natit.kext /System/Library/Extensions参数R表示对目录进行递归操作，kext在图形界面下看起来是个文件，实际上是个文件夹。把驱动目录下的所有文件备份到桌面backupcp -R /System/Library/Extensions/* /User/用户名/Desktop/backup 删除文件rm 参数 文件例：想删除驱动的缓存rm -rf /System/Library/Extensions.kextcacherm -rf /System/Library/Extensions.mkext参数－rf 表示递归和强制，千万要小心使用，如果执行了 rm -rf / 你的系统就全没了 移动文件mv 文件例：想把AppleHDA.Kext 移到桌面mv /System/Library/Extensions/AppleHDA.kext /User/用户名/Desktop想把AppleHDA.Kext 移到备份目录中mv /System/Library/Extensions/AppleHDA.kext /System/Library/Extensions/backup 更改文件权限chmod 参数 权限 文件例：把驱动目录下所有文件设定到root读写，其他用户只读chmod -R 755 /System/Library/Extensions参数R 表示递归，755表示各用户的权限 更改文件属主chown 参数 用户:组 文件例：把驱动目录下的所有文件属主改成根用户chown -R root:wheel /System/Library/Extensions参数R 表示递归操作 修复整个系统中文件的权限diskutil repairpermissions /严格的说这不是一个unix 命令，而是osx一个软件，记得修改或添加的驱动就执行一次。 文本编辑nano 文件名例：编辑natit Info.plistnano /System/Library/Extensions/Natit.kext/Info.plist编辑完成后 用 Ctrl ＋O 存盘，Ctrl＋X 退出另一个文本编辑软件是 vi，操作有些古怪，熟了是非常好用的，而且在所有类Unix系统中都它，走遍天下都不怕了。 补充一个vi的命令： 在默认的”指令模式”下按 i 进入编辑模式 在非指令模式下按 ESC 返回指令模式 在”指令模式”下输入::w 保存当前文件:q 退出编辑,如果文件为保存需要用强制模式:q! 强制退出不保存修改:wq 组合指令, 保存并退出 在”指令模式”下移动:h 左j 下k 上l 右 翻页control + f(front) 下一页control + b(back) 上一页 运行脚本命令sh 脚本文件名例 修改驱动后所有需要的操作存成一个脚本，以后修改了驱动后只要运行一次这个脚本就可以了，方便吧 终端中运行nano /clean 把下列代码粘贴到 nano 中 rm -rf /System/Library/Extensions.kextcache rm -rf /System/Library/Extensions.mkext chown -R root:wheel /System/Library/Extensions chmod -R 755 /System/Library/Extensions diskutil repairpermissions / kextcache -k /System/Library/Extensions/ Ctrl ＋O 存盘，Ctrl＋X 退出 以后只要动了驱动，就在终端中运行一次 sh /clean ———————————————————————————————————— 小技巧 用 Tab 键自动补齐命令比如想到 /System 目录中去，输入 cd /Sy 然后按一下Tab 键，命令就会自动补齐成 cd /System操作带名字中带有空格的文件和目录空格在命令中写成 空格， 比如要进入 My Documents，命令为 cd My Documents 查看命令的详细帮助man 命令名比如要看看 ls 命令的详细用法，执行 man ls 典型操作流程(假设已经制作好清理脚本，记得每次操作前 sudo -s 获得系统权限)假设下载了一个显卡驱动 Natit.zip，在桌面解压得到了一个Natit.kext，该怎么做呢？ 为了保险起见，先把所有驱动备份了再说mkdir /User/用户名/Desktop/backup 在桌面上建立备份文件夹cp -R /System/Library/Extensions/* /User/用户名/Desktop/backup 备份驱动文件 现在可以安心安装了cp -R /User/用户名/Desktop/Natit.kext /System/Library/Extensions 把它 拷贝到系统驱动目录位置sh /clean 执行清理脚本，操作完成 重新开机失败，进不去桌面了，发现不应该安这个驱动，怎么恢复呢？开机按F8，用 -s 参数启动执行 mount -uw /rm -rf /User/用户名/Desktop/Natit.kext 删除这个驱动sh /clean 执行清理脚本，操作完成 重启，回到原先状态了，不死心啊，没有特效怎么行呢，又听说需要修改 Natit的 Info. plist 文件才行，好，再来cp -R /User/用户名/Desktop/Natit.kext /System/Library/Extensions 把它 拷贝到系统驱动目录位置nano /System/Library/Extensions/Natit.kext/Info.plist编辑完成后 用 Ctrl ＋O 存盘，Ctrl＋X 退出sh /clean 执行清理脚本，操作完成 重启，这回对了，显卡特效都有了，该弄声卡了，天知道会出什么事，得把现有成果保护好。mkdir /User/用户名/Desktop/gooddrivers 专为有效驱动建个目录cp -R /System/Library/Extensions/Natit.kext /User/用户名/Desktop/gooddrivers 备份这个声卡要求把 AppleHDA.kext 删除和编辑 AppleAzaliaAudio.kext中的Info.plist 文件，谁知道以后会不会还用AppleHDA呢，不如暂时禁用吧。mkdir /System/Library/Extensions/disabled 建立个禁用目录mv /System/Library/Extensions/AppleHDA.kext /System/Library/Extensions/disabled 移动过去nano /System/Library/Extensions/Natit.kext/AppleAzaliaAudio.kext/Info.plist编辑完成后 用 Ctrl ＋O 存盘，Ctrl＋X 退出sh /clean 执行清理脚本，操作完成成功了，也把修改好的驱动备份一下把 unix的命令以下是unix的命令行,供参考: 目录操作 命令名 功能描述 使用举例 mkdir 创建一个目录 mkdir dirname rmdir 删除一个目录 rmdir dirname mvdir 移动或重命名一个目录 mvdir dir1 dir2 cd 改变当前目录 cd dirname pwd 显示当前目录的路径名 pwd ls 显示当前目录的内容 ls -la dircmp 比较两个目录的内容 dircmp dir1 dir2 文件操作 命令名 功能描述 使用举例 cat 显示或连接文件 cat filename pg 分页格式化显示文件内容 pg filename more 分屏显示文件内容 more filename od 显示非文本文件的内容 od -c filename cp 复制文件或目录 cp file1 file2 rm 删除文件或目录 rm filename mv 改变文件名或所在目录 mv file1 file2 ln 联接文件 ln -s file1 file2 find 使用匹配表达式查找文件 find . -name “*.c” -print file 显示文件类型 file filename 选择操作 命令名 功能描述 使用举例 head 显示文件的最初几行 head -20 filename tail 显示文件的最后几行 tail -15 filename cut 显示文件每行中的某些域 cut -f1,7 -d: /etc/passwd colrm 从标准输入中删除若干列 colrm 8 20 file2 paste 横向连接文件 paste file1 file2 diff 比较并显示两个文件的差异 diff file1 file2 sed 非交互方式流编辑器 sed “s/red/green/g” filename grep 在文件中按模式查找 grep “\\^[a-zA-Z]” filename awk 在文件中查找并处理模式 awk ‘{print $1 $1}’ filename sort 排序或归并文件 sort -d -f -u file1 uniq 去掉文件中的重复行 uniq file1 file2 comm 显示两有序文件的公共和非公共行 comm file1 file2 wc 统计文件的字符数、词数和行数 wc filename nl 给文件加上行号 nl file1 &gt;file2 安全操作 命令名 功能描述 使用举例 passwd 修改用户密码 passwd chmod 改变文件或目录的权限 chmod ug+x filename umask 定义创建文件的权限掩码 umask 027 chown 改变文件或目录的属主 chown newowner filename chgrp 改变文件或目录的所属组 chgrp staff filename xlock 给终端上锁 xlock -remote 编程操作 命令名 功能描述 使用举例 make 维护可执行程序的最新版本 make touch 更新文件的访问和修改时间 touch -m 05202400 filename dbx 命令行界面调试工具 dbx a.out xde 图形用户界面调试工具 xde a.out 进程操作 命令名 功能描述 使用举例 ps 显示进程当前状态 ps u kill 终止进程 kill -9 30142 nice 改变待执行命令的优先级 nice cc -c *.c renice 改变已运行进程的优先级 renice +20 32768 时间操作 命令名 功能描述 使用举例 date 显示系统的当前日期和时间 date cal 显示日历 cal 8 1996 time 统计程序的执行时间 time a.out 网络与通信操作 命令名 功能描述 使用举例 telnet 远程登录 telnet hpc.sp.net.edu.cn rlogin 远程登录 rlogin hostname -l username rsh 在远程主机执行指定命令 rsh f01n03 date ftp 在本地主机与远程主机之间传输文件 ftp ftp.sp.net.edu.cn rcp 在本地主机与远程主机 之间复制文件 rcp file1 host1:file2 ping 给一个网络主机发送 回应请求 ping hpc.sp.net.edu.cn mail 阅读和发送电子邮件 mail write 给另一用户发送报文 write username pts/1 mesg 允许或拒绝接收报文 mesg n Korn Shell 命令 命令名 功能描述 使用举例 history 列出最近执行过的 几条命令及编号 history r 重复执行最近执行过的 某条命令 r -2 alias 给某个命令定义别名 alias del=rm -i unalias 取消对某个别名的定义 unalias del 其它命令 命令名 功能描述 使用举例 uname 显示操作系统的有关信息 uname -a clear 清除屏幕或窗口内容 clear env 显示当前所有设置过的环境变量 env who 列出当前登录的所有用户 who whoami 显示当前正进行操作的用户名 whoami tty 显示终端或伪终端的名称 tty stty 显示或重置控制键定义 stty -a du 查询磁盘使用情况 du -k subdir df 显示文件系统的总空间和可用空间 df /tmp w 显示当前系统活动的总信息 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/02/24/Mac-terminal-command/","raw":null,"content":null,"categories":[{"name":"Mac","slug":"mac","permalink":"http://agehua.github.io/categories/mac/"}],"tags":[{"name":"CMD","slug":"cmd","permalink":"http://agehua.github.io/tags/cmd/"}]},{"title":"投马-自我介绍","slug":"Toastmaster-self-introduction","date":"2018-01-07T16:00:00.000Z","updated":"2023-11-16T03:42:40.846Z","comments":true,"path":"2018/01/08/Toastmaster-self-introduction/","link":"","permalink":"http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/","excerpt":"                   .-&apos; _..`.                  /  .&apos;_.&apos;.&apos;                 | .&apos; (.)`.                 ;&apos;   ,_   `. .--.__________.&apos;    ;  `.;-&apos;|  ./               /|  |               / `..&apos;`-._  _____, ..&apos;     / | |     | |\\ \\    / /| |     | | \\ \\   / / | |     | |  \\ \\  /_/  |_|     |_|   \\_\\","text":".-&apos; _..`. / .&apos;_.&apos;.&apos; | .&apos; (.)`. ;&apos; ,_ `. .--.__________.&apos; ; `.;-&apos;| ./ /| | / `..&apos;`-._ _____, ..&apos; / | | | |\\ \\ / /| | | | \\ \\ / / | | | | \\ \\ /_/ |_| |_| \\_\\ Good afternoon, my dear colleagues.Here is my self-introduction, if you heard something wrong, or you don’t agree with, my apology! My name is Conor. I choose Conor as my English name is because I have an idol who is a professional mixed martial artist and boxer named Conor McGregor. He is the only fighter to be champion in two Ultimate Fighting Championship (UFC) divisions simultaneously. I come from Tangshan city in Hebei province which is not far away from Beijing. I like doing exercise, like running, Skating and swimming. When it comes to the family life, I got married in October 7th last year. What is different between being married and single? My opinion is You have to do cleaning more often, and you have to say I love you ever day. In a word，you have to performance much better than you did when the time you pursuing her. If you don’t ,she will say you have changed since we married. You don’t love me anymore. Come on, I am a good guy, I love her, but I don’t want to say it everyday. As a software engineer, I like coding, I built my own blog on the github. And I wrote an Electronic wedding invitation based on a source code. I konw a joke, let’s see can you all understand this: what is the difference between Java and JavaScript? The answer is Java and Javascript are similar like Car and Carpet are similar. I also like traveling and I prefer to go to historic places. That is because you can enjoy the beautiful scenery and feel the history simultaneously. I have been to the city of Jincheng in Shanxi province. There is a temple called Qinglian temple which was built in Sui and Tang Dynasties. It was situated at the foot of a hill and beside a stream. The temple has a lot of Buddha, but most of them are damaged. The staff there told me,the buddhas’ hands and feet were cut off during the Revolution. When I went there, a big Buddha was being repaired, but many small Buddha statues were put aside, and nobody took care of them. The most impressive one was a small Thousands Hands Guanyin statue. It was badly destroyed and her right half of the body were disappered. Although her body was incomplete, the Buddha‘s face is still smiling. What I want to say is althrough we have a long history and a rich culture in China which we are proud of. But we don’t cherish them. We prefer to Glamorous things, but ignore the old-fashioned things. I hope every one can make an effort to protect our culture. At last, I’d like to recommend a book called 《The path of beauty》(美的历程) in which you can have a Further understanding of our culture by the history timeline. 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/","raw":null,"content":null,"categories":[{"name":"english","slug":"english","permalink":"http://agehua.github.io/categories/english/"}],"tags":[{"name":"toastmaster","slug":"toastmaster","permalink":"http://agehua.github.io/tags/toastmaster/"},{"name":"self-introduction","slug":"self-introduction","permalink":"http://agehua.github.io/tags/self-introduction/"}]},{"title":"Python知识积累","slug":"Python-knowledge","date":"2017-12-01T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/12/02/Python-knowledge/","link":"","permalink":"http://agehua.github.io/2017/12/02/Python-knowledge/","excerpt":"python re 模块 findall 函数用法简述本段转载自：CSDN-python re 模块 findall 函数用法简述\n&gt;&gt;&gt; import re  &gt;&gt;&gt; s = \"adfad asdfasdf asdfas asdfawef asd adsfas \"    &gt;&gt;&gt; reObj1 = re.compile('((\\w+)\\s+\\w+)')  &gt;&gt;&gt; reObj1.findall(s)  [('adfad asdfasdf', 'adfad'), ('asdfas asdfawef', 'asdfas'), ('asd adsfas', 'asd')]    &gt;&gt;&gt; reObj2 = re.compile('(\\w+)\\s+\\w+')  &gt;&gt;&gt; reObj2.findall(s)  ['adfad', 'asdfas', 'asd']    &gt;&gt;&gt; reObj3 = re.compile('\\w+\\s+\\w+')  &gt;&gt;&gt; reObj3.findall(s)  ['adfad asdfasdf', 'asdfas asdfawef', 'asd adsfas']","text":"python re 模块 findall 函数用法简述本段转载自：CSDN-python re 模块 findall 函数用法简述 &gt;&gt;&gt; import re &gt;&gt;&gt; s = \"adfad asdfasdf asdfas asdfawef asd adsfas \" &gt;&gt;&gt; reObj1 = re.compile('((\\w+)\\s+\\w+)') &gt;&gt;&gt; reObj1.findall(s) [('adfad asdfasdf', 'adfad'), ('asdfas asdfawef', 'asdfas'), ('asd adsfas', 'asd')] &gt;&gt;&gt; reObj2 = re.compile('(\\w+)\\s+\\w+') &gt;&gt;&gt; reObj2.findall(s) ['adfad', 'asdfas', 'asd'] &gt;&gt;&gt; reObj3 = re.compile('\\w+\\s+\\w+') &gt;&gt;&gt; reObj3.findall(s) ['adfad asdfasdf', 'asdfas asdfawef', 'asd adsfas'] 按以上代码例子讲解： findall函数返回的总是正则表达式在字符串中所有匹配结果的列表，此处主要讨论列表中“结果”的展现方式，即findall中返回列表中每个元素包含的信息。 @1.当给出的正则表达式中带有多个括号时，列表的元素为多个字符串组成的tuple，tuple中字符串个数与括号对数相同这里是指正则表达式中的括号对数，字符串内容与每个括号内的正则表达式相对应，并且排放顺序是按括号出现的顺序。 @2.当给出的正则表达式中带有一个括号时，列表的元素为字符串，此字符串的内容与括号中的正则表达式相对应（不是整个正则表达式的匹配内容）。 @3.当给出的正则表达式中不带括号时，列表的元素为字符串，此字符串为整个正则表达式匹配的内容。 其实正则表达式常用的就那几种，熟悉了就很强大了： [ ] 表示都可以匹配，比如[abc]匹配a或b或c {1,3}表示重复1-3次 [^abc]表示非abc 一些常用的匹配比如.*?表示非贪婪地匹配任何东西 Python函数的参数Python的函数定义非常简单，但灵活度却非常大。除了正常定义的必选参数外，还可以使用默认参数、可变参数和关键字参数，使得函数定义出来的接口，不但能处理复杂的参数，还可以简化调用者的代码。 位置参数我们先写一个计算x2的函数： def power(x): return x * x 对于power(x)函数，参数x就是一个位置参数。 当我们调用power函数时，必须传入有且仅有的一个参数x：&gt;&gt;&gt; power(5)25&gt;&gt;&gt; power(15)225 现在，如果我们要计算x3怎么办？可以再定义一个power3函数，但是如果要计算x4、x5……怎么办？我们不可能定义无限多个函数。 你也许想到了，可以把power(x)修改为power(x, n)，用来计算xn，说干就干：def power(x, n): s = 1 while n &gt; 0: n = n - 1 s = s * x return s 对于这个修改后的power(x, n)函数，可以计算任意n次方：&gt;&gt;&gt; power(5, 2)25&gt;&gt;&gt; power(5, 3)125 修改后的power(x, n)函数有两个参数：x和n，这两个参数都是位置参数，调用函数时，传入的两个值按照位置顺序依次赋给参数x和n。 默认参数新的power(x, n)函数定义没有问题，但是，旧的调用代码失败了，原因是我们增加了一个参数，导致旧的代码因为缺少一个参数而无法正常调用： &gt;&gt;&gt; power(5)Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt;TypeError: power() missing 1 required positional argument: 'n' Python的错误信息很明确：调用函数power()缺少了一个位置参数n。 这个时候，默认参数就排上用场了。由于我们经常计算x2，所以，完全可以把第二个参数n的默认值设定为2：def power(x, n=2): s = 1 while n &gt; 0: n = n - 1 s = s * x return s 这样，当我们调用power(5)时，相当于调用power(5, 2)：&gt;&gt;&gt; power(5)25&gt;&gt;&gt; power(5, 2)25 而对于n &gt; 2的其他情况，就必须明确地传入n，比如power(5, 3)。 从上面的例子可以看出，默认参数可以简化函数的调用。设置默认参数时，有几点要注意： 一是必选参数在前，默认参数在后，否则Python的解释器会报错（思考一下为什么默认参数不能放在必选参数前面）； 二是如何设置默认参数。 当函数有多个参数时，把变化大的参数放前面，变化小的参数放后面。变化小的参数就可以作为默认参数。 使用默认参数有什么好处？最大的好处是能降低调用函数的难度。 举个例子，我们写个一年级小学生注册的函数，需要传入name和gender两个参数： def enroll(name, gender): print('name:', name) print('gender:', gender) 这样，调用enroll()函数只需要传入两个参数： &gt;&gt;&gt; enroll('Sarah', 'F')name: Sarahgender: F 如果要继续传入年龄、城市等信息怎么办？这样会使得调用函数的复杂度大大增加。 我们可以把年龄和城市设为默认参数： def enroll(name, gender, age=6, city='Beijing'): print('name:', name) print('gender:', gender) print('age:', age) print('city:', city) 这样，大多数学生注册时不需要提供年龄和城市，只提供必须的两个参数： &gt;&gt;&gt; enroll('Sarah', 'F')name: Sarahgender: Fage: 6city: Beijing 只有与默认参数不符的学生才需要提供额外的信息： enroll('Bob', 'M', 7)enroll('Adam', 'M', city='Tianjin') 可见，默认参数降低了函数调用的难度，而一旦需要更复杂的调用时，又可以传递更多的参数来实现。无论是简单调用还是复杂调用，函数只需要定义一个。 有多个默认参数时，调用的时候，既可以按顺序提供默认参数，比如调用enroll(‘Bob’, ‘M’, 7)，意思是，除了name，gender这两个参数外，最后1个参数应用在参数age上，city参数由于没有提供，仍然使用默认值。 也可以不按顺序提供部分默认参数。当不按顺序提供部分默认参数时，需要把参数名写上。比如调用enroll(‘Adam’, ‘M’, city=’Tianjin’)，意思是，city参数用传进去的值，其他默认参数继续使用默认值。 默认参数很有用，但使用不当，也会掉坑里。默认参数有个最大的坑，演示如下： 先定义一个函数，传入一个list，添加一个END再返回： def add_end(L=[]): L.append('END') return L 当你正常调用时，结果似乎不错： &gt;&gt;&gt; add_end([1, 2, 3])[1, 2, 3, 'END']&gt;&gt;&gt; add_end(['x', 'y', 'z'])['x', 'y', 'z', 'END'] 当你使用默认参数调用时，一开始结果也是对的： &gt;&gt;&gt; add_end()['END'] 但是，再次调用add_end()时，结果就不对了： &gt;&gt;&gt; add_end()['END', 'END']&gt;&gt;&gt; add_end()['END', 'END', 'END'] 很多初学者很疑惑，默认参数是[]，但是函数似乎每次都“记住了”上次添加了’END’后的list。 原因解释如下： Python函数在定义的时候，默认参数L的值就被计算出来了，即[]，因为默认参数L也是一个变量，它指向对象[]，每次调用该函数，如果改变了L的内容，则下次调用时，默认参数的内容就变了，不再是函数定义时的[]了。 定义默认参数要牢记一点：默认参数必须指向不变对象！要修改上面的例子，我们可以用None这个不变对象来实现： def add_end(L=None): if L is None: L = [] L.append('END') return L 现在，无论调用多少次，都不会有问题： &gt;&gt;&gt; add_end()['END']&gt;&gt;&gt; add_end()['END'] 为什么要设计str、None这样的不变对象呢？因为不变对象一旦创建，对象内部的数据就不能修改，这样就减少了由于修改数据导致的错误。此外，由于对象不变，多任务环境下同时读取对象不需要加锁，同时读一点问题都没有。我们在编写程序时，如果可以设计一个不变对象，那就尽量设计成不变对象。 可变参数在Python函数中，还可以定义可变参数。顾名思义，可变参数就是传入的参数个数是可变的，可以是1个、2个到任意个，还可以是0个。 我们以数学题为例子，给定一组数字a，b，c……，请计算a2 + b2 + c2 + ……。 要定义出这个函数，我们必须确定输入的参数。由于参数个数不确定，我们首先想到可以把a，b，c……作为一个list或tuple传进来，这样，函数可以定义如下： def calc(numbers): sum = 0 for n in numbers: sum = sum + n * n return sum 但是调用的时候，需要先组装出一个list或tuple： &gt;&gt;&gt; calc([1, 2, 3])14&gt;&gt;&gt; calc((1, 3, 5, 7))84 如果利用可变参数，调用函数的方式可以简化成这样： &gt;&gt;&gt; calc(1, 2, 3)14&gt;&gt;&gt; calc(1, 3, 5, 7)84 所以，我们把函数的参数改为可变参数： def calc(*numbers): sum = 0 for n in numbers: sum = sum + n * n return sum 定义可变参数和定义一个list或tuple参数相比，仅仅在参数前面加了一个*号。在函数内部，参数numbers接收到的是一个tuple，因此，函数代码完全不变。但是，调用该函数时，可以传入任意个参数，包括0个参数： &gt;&gt;&gt; calc(1, 2)5&gt;&gt;&gt; calc()0 如果已经有一个list或者tuple，要调用一个可变参数怎么办？可以这样做： &gt;&gt;&gt; nums = [1, 2, 3]&gt;&gt;&gt; calc(nums[0], nums[1], nums[2])14 这种写法当然是可行的，问题是太繁琐，所以Python允许你在list或tuple前面加一个*号，把list或tuple的元素变成可变参数传进去： &gt;&gt;&gt; nums = [1, 2, 3]&gt;&gt;&gt; calc(*nums)14 *nums表示把nums这个list的所有元素作为可变参数传进去。这种写法相当有用，而且很常见。 关键字参数可变参数允许你传入0个或任意个参数，这些可变参数在函数调用时自动组装为一个tuple。而关键字参数允许你传入0个或任意个含参数名的参数，这些关键字参数在函数内部自动组装为一个dict。请看示例： def person(name, age, **kw): print('name:', name, 'age:', age, 'other:', kw) 函数person除了必选参数name和age外，还接受关键字参数kw。在调用该函数时，可以只传入必选参数： &gt;&gt;&gt; person('Michael', 30)name: Michael age: 30 other: &#123;&#125; 也可以传入任意个数的关键字参数： &gt;&gt;&gt; person('Bob', 35, city='Beijing')name: Bob age: 35 other: &#123;'city': 'Beijing'&#125;&gt;&gt;&gt; person('Adam', 45, gender='M', job='Engineer')name: Adam age: 45 other: &#123;'gender': 'M', 'job': 'Engineer'&#125; 关键字参数有什么用？它可以扩展函数的功能。比如，在person函数里，我们保证能接收到name和age这两个参数，但是，如果调用者愿意提供更多的参数，我们也能收到。试想你正在做一个用户注册的功能，除了用户名和年龄是必填项外，其他都是可选项，利用关键字参数来定义这个函数就能满足注册的需求。 和可变参数类似，也可以先组装出一个dict，然后，把该dict转换为关键字参数传进去： &gt;&gt;&gt; extra = &#123;'city': 'Beijing', 'job': 'Engineer'&#125;&gt;&gt;&gt; person('Jack', 24, city=extra['city'], job=extra['job'])name: Jack age: 24 other: &#123;'city': 'Beijing', 'job': 'Engineer'&#125; 当然，上面复杂的调用可以用简化的写法： &gt;&gt;&gt; extra = &#123;'city': 'Beijing', 'job': 'Engineer'&#125;&gt;&gt;&gt; person('Jack', 24, **extra)name: Jack age: 24 other: &#123;'city': 'Beijing', 'job': 'Engineer'&#125; extra表示把extra这个dict的所有key-value用关键字参数传入到函数的kw参数，kw将获得一个dict，注意kw获得的dict是extra的一份拷贝，对kw的改动不会影响到函数外的extra。 命名关键字参数对于关键字参数，函数的调用者可以传入任意不受限制的关键字参数。至于到底传入了哪些，就需要在函数内部通过kw检查。 仍以person()函数为例，我们希望检查是否有city和job参数： def person(name, age, **kw): if 'city' in kw: # 有city参数 pass if 'job' in kw: # 有job参数 pass print('name:', name, 'age:', age, 'other:', kw) 但是调用者仍可以传入不受限制的关键字参数： &gt;&gt;&gt; person('Jack', 24, city='Beijing', addr='Chaoyang', zipcode=123456) 如果要限制关键字参数的名字，就可以用命名关键字参数，例如，只接收city和job作为关键字参数。这种方式定义的函数如下： def person(name, age, *, city, job): print(name, age, city, job) 和关键字参数**kw不同，命名关键字参数需要一个特殊分隔符*，*后面的参数被视为命名关键字参数。 调用方式如下： &gt;&gt;&gt; person('Jack', 24, city='Beijing', job='Engineer')Jack 24 Beijing Engineer 如果函数定义中已经有了一个可变参数，后面跟着的命名关键字参数就不再需要一个特殊分隔符*了： def person(name, age, *args, city, job): print(name, age, args, city, job) 命名关键字参数必须传入参数名，这和位置参数不同。如果没有传入参数名，调用将报错： &gt;&gt;&gt; person('Jack', 24, 'Beijing', 'Engineer')Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt;TypeError: person() takes 2 positional arguments but 4 were given 由于调用时缺少参数名city和job，Python解释器把这4个参数均视为位置参数，但person()函数仅接受2个位置参数。 命名关键字参数可以有缺省值，从而简化调用：def person(name, age, *, city='Beijing', job): print(name, age, city, job) 由于命名关键字参数city具有默认值，调用时，可不传入city参数： &gt;&gt;&gt; person('Jack', 24, job='Engineer')Jack 24 Beijing Engineer 使用命名关键字参数时，要特别注意，如果没有可变参数，就必须加一个*作为特殊分隔符。如果缺少*，Python解释器将无法识别位置参数和命名关键字参数： def person(name, age, city, job): # 缺少 *，city和job被视为位置参数 pass 参数组合在Python中定义函数，可以用必选参数、默认参数、可变参数、关键字参数和命名关键字参数，这5种参数都可以组合使用。但是请注意，参数定义的顺序必须是：必选参数、默认参数、可变参数、命名关键字参数和关键字参数。 比如定义一个函数，包含上述若干种参数： def f1(a, b, c=0, *args, **kw): print('a =', a, 'b =', b, 'c =', c, 'args =', args, 'kw =', kw)def f2(a, b, c=0, *, d, **kw): print('a =', a, 'b =', b, 'c =', c, 'd =', d, 'kw =', kw) 在函数调用的时候，Python解释器自动按照参数位置和参数名把对应的参数传进去。 &gt;&gt;&gt; f1(1, 2)a = 1 b = 2 c = 0 args = () kw = &#123;&#125;&gt;&gt;&gt; f1(1, 2, c=3)a = 1 b = 2 c = 3 args = () kw = &#123;&#125;&gt;&gt;&gt; f1(1, 2, 3, 'a', 'b')a = 1 b = 2 c = 3 args = ('a', 'b') kw = &#123;&#125;&gt;&gt;&gt; f1(1, 2, 3, 'a', 'b', x=99)a = 1 b = 2 c = 3 args = ('a', 'b') kw = &#123;'x': 99&#125;&gt;&gt;&gt; f2(1, 2, d=99, ext=None)a = 1 b = 2 c = 0 d = 99 kw = &#123;'ext': None&#125; 最神奇的是通过一个tuple和dict，你也可以调用上述函数：&gt;&gt;&gt; args = (1, 2, 3, 4)&gt;&gt;&gt; kw = &#123;'d': 99, 'x': '#'&#125;&gt;&gt;&gt; f1(*args, **kw)a = 1 b = 2 c = 3 args = (4,) kw = &#123;'d': 99, 'x': '#'&#125;&gt;&gt;&gt; args = (1, 2, 3)&gt;&gt;&gt; kw = &#123;'d': 88, 'x': '#'&#125;&gt;&gt;&gt; f2(*args, **kw)a = 1 b = 2 c = 3 d = 88 kw = &#123;'x': '#'&#125; 对上面代码的结果做一个说明：*args是可变参数，接收list或tuple，然后自动组装成tuple。而一个单独的*，表示命名关键字参数，它和关键字参数一样，都必须接收带参数名的参数。对于f2函数而言，它只接受3个位置参数，一个或一个以上的带参数名的参数（这里的一个的参数名必须是d，因为命名关键字参数没有缺省值的话，不能为空，而关键字参数可以为空），args是一个tuple参数，最多只能传3个值，而kw作为一个dict，必须包含一个d参数名的参数。 所以，对于任意函数，都可以通过类似func(*args, **kw)的形式调用它，无论它的参数是如何定义的。 虽然可以组合多达5种参数，但不要同时使用太多的组合，否则函数接口的可理解性很差 小结Python的函数具有非常灵活的参数形态，既可以实现简单的调用，又可以传入非常复杂的参数。 默认参数一定要用不可变对象，如果是可变对象，程序运行时会有逻辑错误！ 要注意定义可变参数和关键字参数的语法： *args是可变参数，args接收的是一个tuple； **kw是关键字参数，kw接收的是一个dict。 以及调用函数时如何传入可变参数和关键字参数的语法： 可变参数既可以直接传入：func(1, 2, 3)，又可以先组装list或tuple，再通过*args传入：func(*(1, 2, 3))； 关键字参数既可以直接传入：func(a=1, b=2)，又可以先组装dict，再通过**kw传入：func(**{&#39;a&#39;: 1, &#39;b&#39;: 2})。 使用*args和**kw是Python的习惯写法，当然也可以用其他参数名，但最好使用习惯用法。 命名的关键字参数是为了限制调用者可以传入的参数名，同时可以提供默认值。 定义命名的关键字参数在没有可变参数的情况下不要忘了写分隔符*，否则定义的将是位置参数。 Python语法回顾看这篇文章：分分钟学会一门语言之Python篇 Python之禅(Zen Of Python)Python 输入 import this 就会显示 Tim Peters 的 The Zen of Python，原文和翻译请看：《Python之禅》的翻译和解释 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/12/02/Python-knowledge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"Python","slug":"python","permalink":"http://agehua.github.io/tags/python/"}]},{"title":"跨平台桌面程序开发","slug":"Buildcross-platform-desktop-apps","date":"2017-10-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.314Z","comments":true,"path":"2017/10/22/Buildcross-platform-desktop-apps/","link":"","permalink":"http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/","excerpt":"跨平台桌面程序开发今天搜索Alfred 英文词典应用时发现了这个工具：Youdao Alfred Workflow\n\u001d作者在这篇文章：学英语和写工具，里面介绍了Alfred插件开发，同时也介绍了一下跨平台插件开发的方式：","text":"跨平台桌面程序开发今天搜索Alfred 英文词典应用时发现了这个工具：Youdao Alfred Workflow \u001d作者在这篇文章：学英语和写工具，里面介绍了Alfred插件开发，同时也介绍了一下跨平台插件开发的方式： 下面这段摘自这篇文章： 从趋势上来看，基于 HTML5 API 和 Node.js 的跨平台插件开发是未来的主流方向。 Chrome App 。从 Github 上下载一些 chrome app sample 示例，简单浏览一下教程（墙内的、墙外的）和官方 API 文档 ，不出半天时间就能开发出一款插件。 npm 命令行工具。npm 模块除了在 node 环境下作为依赖模块被引用以外，还可以直接作为命令行工具使用。通过 package.json bin 字段定义，在全局安装时即可自动注册为全局命令行。例如，这款用于生成字体的 makefont 命令行模块。 NW.js 。将 webkit 和 node 集成打包使用的跨平台方案。当前 Mac 版的「夺命追魂钉」用的就是这个方案。node + webkit 方案最终将会取代 Adobe AIR ，这是 HTML5 对 Flash 的胜利。 Electron 。微软新出的 Visual Studio Code 编辑器和 Github 的 Atom 编辑器使用的内核引擎，与 NW.js 的区别参看这里 。 对于程序员来说，这是一个非常好的全栈实践之路。 Visual Studio Code 配置指南 Visual Studio Code和Atom竟然是用Electron开发出来的，顿时觉得这种技术好强大，下决心要学习一下这个技术。 关于 ElectronElectron的官方网址是：https://electronjs.org/ 如果你可以建一个网站，你就可以建一个桌面应用程序。 Electron 是一个使用 JavaScript, HTML 和 CSS 等 Web 技术创建原生程序的框架，它负责比较难搞的部分，你只需把精力放在你的应用的核心上即可。 Electron（最初名为Atom Shell[3]）是GitHub开发的一个开源框架。它允许使用Node.js（作为后端）和Chromium（作为前端）完成桌面GUI应用程序的开发。Electron现已被多个开源Web应用程序用于前端与后端的开发，著名项目包括GitHub的Atom和微软的Visual Studio Code。 入门教程有：Electron W3C中文文档Github: electron-cn-docs 由于Electron基于Node.js，所以入门第一关应当稍微熟悉Node.js的文档. Electron主进程 在 Electron 里，运行 package.json 里 main 脚本的进程被称为主进程。在主进程运行的脚本可以以创建 web 页面的形式展示 GUI。渲染进程 由于 Electron 使用 Chromium 来展示页面，所以 Chromium 的多进程结构也被充分利用。每个 Electron 的页面都在运行着自己的进程，这样的进程我们称之为渲染进程。在一般浏览器中，网页通常会在沙盒环境下运行，并且不允许访问原生资源。然而，Electron 用户拥有在网页中调用 io.js 的 APIs 的能力，可以与底层操作系统直接交互。 主进程与渲染进程的区别 主进程使用 BrowserWindow 实例创建网页。每个 BrowserWindow 实例都在自己的渲染进程里运行着一个网页。当一个 BrowserWindow 实例被销毁后，相应的渲染进程也会被终止。主进程管理所有页面和与之对应的渲染进程。每个渲染进程都是相互独立的，并且只关心他们自己的网页。由于在网页里管理原生 GUI 资源是非常危险而且容易造成资源泄露，所以在网页面调用 GUI 相关的 APIs 是不被允许的。如果你想在网页里使用 GUI 操作，其对应的渲染进程必须与主进程进行通讯，请求主进程进行相关的 GUI 操作。在 Electron，我们提供用于在主进程与渲染进程之间通讯的 ipc 模块。并且也有一个远程进程调用风格的通讯模块 remote。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Alfred Workflow","slug":"alfred-workflow","permalink":"http://agehua.github.io/tags/alfred-workflow/"},{"name":"Electron","slug":"electron","permalink":"http://agehua.github.io/tags/electron/"},{"name":"JavaScript","slug":"javascript","permalink":"http://agehua.github.io/tags/javascript/"}]},{"title":"JavaScript知识点积累","slug":"JavaScript-knowledge","date":"2017-10-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/10/22/JavaScript-knowledge/","link":"","permalink":"http://agehua.github.io/2017/10/22/JavaScript-knowledge/","excerpt":"JavaScript积累\n‘Java and JavaScript are similar like Car and Carpet are similar’ - Greg Hewgill\n\n本文大部分内容来自: 廖雪峰–JavaScript教程\nfor … of循环介绍ES6引入了for … of循环遍历集合，你可能会有疑问，for … of循环和for … in循环有何区别？\nfor … in循环由于历史遗留问题，它遍历的实际上是对象的属性名称。一个Array数组实际上也是一个对象，它的每个元素的索引被视为一个属性。","text":"JavaScript积累 ‘Java and JavaScript are similar like Car and Carpet are similar’ - Greg Hewgill 本文大部分内容来自: 廖雪峰–JavaScript教程 for … of循环介绍ES6引入了for … of循环遍历集合，你可能会有疑问，for … of循环和for … in循环有何区别？ for … in循环由于历史遗留问题，它遍历的实际上是对象的属性名称。一个Array数组实际上也是一个对象，它的每个元素的索引被视为一个属性。 当我们手动给Array对象添加了额外的属性后，for … in循环将带来意想不到的意外效果：var a = ['A', 'B', 'C'];a.name = 'Hello';for (var x in a) &#123; console.log(x); // '0', '1', '2', 'name'&#125; for … in循环将把name包括在内，但Array的length属性却不包括在内。 for … of循环则完全修复了这些问题，它只循环集合本身的元素：var a = ['A', 'B', 'C'];a.name = 'Hello';for (var x of a) &#123; console.log(x); // 'A', 'B', 'C'&#125; 这就是为什么要引入新的for … of循环。 然而，更好的方式是直接使用iterable内置的forEach方法，它接收一个函数，每次迭代就自动回调该函数。以Array为例： 'use strict';var a = ['A', 'B', 'C'];a.forEach(function (element, index, array) &#123; // element: 指向当前元素的值 // index: 指向当前索引 // array: 指向Array对象本身 console.log(element + ', index = ' + index);&#125;); 注意，forEach()方法是ES5.1标准引入的，你需要测试浏览器是否支持。 Set与Array类似，但Set没有索引，因此回调函数的前两个参数都是元素本身：var s = new Set(['A', 'B', 'C']);s.forEach(function (element, sameElement, set) &#123; console.log(element);&#125;); Map的回调函数参数依次为value、key和map本身：var m = new Map([[1, 'x'], [2, 'y'], [3, 'z']]);m.forEach(function (value, key, map) &#123; console.log(value);&#125;); 如果对某些参数不感兴趣，由于JavaScript的函数调用不要求参数必须一致，因此可以忽略它们。例如，只需要获得Array的element：var a = ['A', 'B', 'C'];a.forEach(function (element) &#123; console.log(element);&#125;); rest参数JavaScript还有一个免费赠送的关键字arguments，它只在函数内部起作用，并且永远指向当前函数的调用者传入的所有参数。arguments类似Array但它不是一个Array.由于JavaScript函数允许接收任意个参数，于是我们就不得不用arguments来获取所有参数：function foo(a, b) &#123; var i, rest = []; if (arguments.length &gt; 2) &#123; for (i = 2; i&lt;arguments.length; i++) &#123; rest.push(arguments[i]); &#125; &#125; console.log('a = ' + a); console.log('b = ' + b); console.log(rest);&#125; 为了获取除了已定义参数a、b之外的参数，我们不得不用arguments，并且循环要从索引2开始以便排除前两个参数，这种写法很别扭，只是为了获得额外的rest参数，有没有更好的方法？ ES6标准引入了rest参数，上面的函数可以改写为：function foo(a, b, ...rest) &#123; console.log('a = ' + a); console.log('b = ' + b); console.log(rest);&#125;foo(1, 2, 3, 4, 5);// 结果:// a = 1// b = 2// Array [ 3, 4, 5 ]foo(1);// 结果:// a = 1// b = undefined// Array [] rest参数只能写在最后，前面用…标识，从运行结果可知，传入的参数先绑定a、b，多余的参数以数组形式交给变量rest，所以，不再需要arguments我们就获取了全部参数。 如果传入的参数连正常定义的参数都没填满，也不要紧，rest参数会接收一个空数组（注意不是undefined）。 全局作用域不在任何函数内定义的变量就具有全局作用域。实际上，JavaScript默认有一个全局对象window，全局作用域的变量实际上被绑定到window的一个属性 你可能猜到了，由于函数定义有两种方式，以变量方式var foo = function () {}定义的函数实际上也是一个全局变量，因此，顶层函数的定义也被视为一个全局变量，并绑定到window对象：'use strict';function foo() &#123; alert('foo');&#125;foo(); // 直接调用foo()window.foo(); // 通过window.foo()调用 名字空间全局变量会绑定到window上，不同的JavaScript文件如果使用了相同的全局变量，或者定义了相同名字的顶层函数，都会造成命名冲突，并且很难被发现。 减少冲突的一个方法是把自己的所有变量和函数全部绑定到一个全局变量中。例如：// 唯一的全局变量MYAPP:var MYAPP = &#123;&#125;;// 其他变量:MYAPP.name = 'myapp';MYAPP.version = 1.0;// 其他函数:MYAPP.foo = function () &#123; return 'foo';&#125;; 把自己的代码全部放入唯一的名字空间MYAPP中，会大大减少全局变量冲突的可能。 许多著名的JavaScript库都是这么干的：jQuery，YUI，underscore等等。 局部作用域由于JavaScript的变量作用域实际上是函数内部，我们在for循环等语句块中是无法定义具有局部作用域的变量的：'use strict';function foo() &#123; for (var i=0; i&lt;100; i++) &#123; // &#125; i += 100; // 仍然可以引用变量i&#125; 为了解决块级作用域，ES6引入了新的关键字let，用let替代var可以申明一个块级作用域的变量：'use strict';function foo() &#123; var sum = 0; for (let i=0; i&lt;100; i++) &#123; sum += i; &#125; // SyntaxError: i += 1;&#125; ES6标准引入了新的关键字const来定义常量，const与let都具有块级作用域. 解构赋值从ES6开始，JavaScript引入了解构赋值，可以同时对一组变量进行赋值如果数组本身还有嵌套，也可以通过下面的形式进行解构赋值，注意嵌套层次和位置要保持一致：let [x, [y, z]] = ['hello', ['JavaScript', 'ES6']];x; // 'hello'y; // 'JavaScript'z; // 'ES6' 解构赋值还可以忽略某些元素：let [, , z] = ['hello', 'JavaScript', 'ES6']; // 忽略前两个元素，只对z赋值第三个元素z; // 'ES6' 对一个对象进行解构赋值时，同样可以直接对嵌套的对象属性进行赋值，只要保证对应的层次是一致的：var person = &#123; name: '小明', age: 20, gender: 'male', passport: 'G-12345678', school: 'No.4 middle school', address: &#123; city: 'Beijing', street: 'No.1 Road', zipcode: '100001' &#125;&#125;;var &#123;name, address: &#123;city, zip&#125;&#125; = person;name; // '小明'city; // 'Beijing'zip; // undefined, 因为属性名是zipcode而不是zip// 注意: address不是变量，而是为了让city和zip获得嵌套的address对象的属性:address; // Uncaught ReferenceError: address is not defined 使用解构赋值对对象属性进行赋值时，如果对应的属性不存在，变量将被赋值为undefined，这和引用一个不存在的属性获得undefined是一致的。如果要使用的变量名和属性名不一致，可以用下面的语法获取：var person = &#123; name: '小明', age: 20, gender: 'male', passport: 'G-12345678', school: 'No.4 middle school'&#125;;// 把passport属性赋值给变量id:let &#123;name, passport:id&#125; = person;name; // '小明'id; // 'G-12345678'// 注意: passport不是变量，而是为了让变量id获得passport属性:passport; // Uncaught ReferenceError: passport is not defined 解构赋值还可以使用默认值，这样就避免了不存在的属性返回undefined的问题：var person = &#123; name: '小明', age: 20, gender: 'male', passport: 'G-12345678'&#125;; // 如果person对象没有single属性，默认赋值为true:var &#123;name, single=true&#125; = person;name; // '小明'single; // true 有些时候，如果变量已经被声明了，再次赋值的时候，正确的写法也会报语法错误：// 声明变量:var x, y;// 解构赋值:&#123;x, y&#125; = &#123; name: '小明', x: 100, y: 200&#125;;// 语法错误: Uncaught SyntaxError: Unexpected token = 这是因为JavaScript引擎把{开头的语句当作了块处理，于是=不再合法。解决方法是用小括号括起来：(&#123;x, y&#125; = &#123; name: '小明', x: 100, y: 200&#125;); 使用场景 解构赋值在很多时候可以大大简化代码。例如，交换两个变量x和y的值，可以这么写，不再需要临时变量：var x=1, y=2;[x, y] = [y, x] 快速获取当前页面的域名和路径：var &#123;hostname:domain, pathname:path&#125; = location; 如果一个函数接收一个对象作为参数，那么，可以使用解构直接把对象的属性绑定到变量中。例如，下面的函数可以快速创建一个Date对象：function buildDate(&#123;year, month, day, hour=0, minute=0, second=0&#125;) &#123; return new Date(year + '-' + month + '-' + day + ' ' + hour + ':' + minute + ':' + second);&#125; 它的方便之处在于传入的对象只需要year、month和day这三个属性：buildDate(&#123; year: 2017, month: 1, day: 1 &#125;);// Sun Jan 01 2017 00:00:00 GMT+0800 (CST) 也可以传入hour、minute和second属性：buildDate(&#123; year: 2017, month: 1, day: 1, hour: 20, minute: 15 &#125;);// Sun Jan 01 2017 20:15:00 GMT+0800 (CST) 使用解构赋值可以减少代码量，但是，需要在支持ES6解构赋值特性的现代浏览器中才能正常运行。目前支持解构赋值的浏览器包括Chrome，Firefox，Edge等。 方法this、apply和call在一个方法内部，this是一个特殊变量，它始终指向当前对象'use strict';var xiaoming = &#123; name: '小明', birth: 1990, age: function () &#123; var y = new Date().getFullYear(); return y - this.birth; &#125;&#125;;var fn = xiaoming.age;fn(); // Uncaught TypeError: Cannot read property 'birth' of undefined this指针只在age方法的函数内指向xiaoming，在函数内部定义的函数，this又指向undefined了！（在非strict模式下，它重新指向全局对象window！） 'use strict';var xiaoming = &#123; name: '小明', birth: 1990, age: function () &#123; var that = this; // 在方法内部一开始就捕获this function getAgeFromBirth() &#123; var y = new Date().getFullYear(); return y - that.birth; // 用that而不是this &#125; return getAgeFromBirth(); &#125;&#125;;xiaoming.age(); // 25 用var that = this;，你就可以放心地在方法内部定义其他函数，而不是把所有语句都堆到一个方法中。 虽然在一个独立的函数调用中，根据是否是strict模式，this指向undefined或window，不过，我们还是可以控制this的指向的！ 要指定函数的this指向哪个对象，可以用函数本身的apply方法，它接收两个参数，第一个参数就是需要绑定的this变量，第二个参数是Array，表示函数本身的参数。 用apply修复getAge()调用：function getAge() &#123; var y = new Date().getFullYear(); return y - this.birth;&#125;var xiaoming = &#123; name: '小明', birth: 1990, age: getAge&#125;;xiaoming.age(); // 25getAge.apply(xiaoming, []); // 25, this指向xiaoming, 参数为空 另一个与apply()类似的方法是call()，唯一区别是： apply()把参数打包成Array再传入； call()把参数按顺序传入。 比如调用Math.max(3, 5, 4)，分别用apply()和call()实现如下：Math.max.apply(null, [3, 5, 4]); // 5Math.max.call(null, 3, 5, 4); // 5 对普通函数调用，我们通常把this绑定为null。 装饰器利用apply()，我们还可以动态改变函数的行为。 JavaScript的所有对象都是动态的，即使内置的函数，我们也可以重新指向新的函数。 现在假定我们想统计一下代码一共调用了多少次parseInt()，可以把所有的调用都找出来，然后手动加上count += 1，不过这样做太傻了。最佳方案是用我们自己的函数替换掉默认的parseInt()：'use strict';var count = 0;var oldParseInt = parseInt; // 保存原函数window.parseInt = function () &#123; count += 1; return oldParseInt.apply(null, arguments); // 调用原函数&#125;; 高阶函数JavaScript的函数其实都指向某个变量。既然变量可以指向函数，函数的参数能接收变量，那么一个函数就可以接收另一个函数作为参数，这种函数就称之为高阶函数。 mapmap()方法定义在JavaScript的Array中，我们调用Array的map()方法，传入我们自己的函数，就得到了一个新的Array作为结果'use strict';function pow(x) &#123; return x * x;&#125;var arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];var results = arr.map(pow); // [1, 4, 9, 16, 25, 36, 49, 64, 81]console.log(results); 注意：map()传入的参数是pow，即函数对象本身。 把Array的所有数字转为字符串：var arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];arr.map(String); // ['1', '2', '3', '4', '5', '6', '7', '8', '9'] 只需要一行代码。 reduceArray的reduce()把一个函数作用在这个Array的[x1, x2, x3…]上，这个函数必须接收两个参数，reduce()把结果继续和序列的下一个元素做累积计算，其效果就是：[x1, x2, x3, x4].reduce(f) = f(f(f(x1, x2), x3), x4) 要把[1, 3, 5, 7, 9]变换成整数13579，reduce()也能派上用场：var arr = [1, 3, 5, 7, 9];arr.reduce(function (x, y) &#123; return x * 10 + y;&#125;); // 13579 filterfilter也是一个常用的操作，它用于把Array的某些元素过滤掉，然后返回剩下的元素。 和map()类似，Array的filter()也接收一个函数。和map()不同的是，filter()把传入的函数依次作用于每个元素，然后根据返回值是true还是false决定保留还是丢弃该元素。 把一个Array中的空字符串删掉，可以这么写：var arr = ['A', '', 'B', null, undefined, 'C', ' '];var r = arr.filter(function (s) &#123; return s &amp;&amp; s.trim(); // 注意：IE9以下的版本没有trim()方法&#125;);r; // ['A', 'B', 'C'] filter()接收的回调函数，其实可以有多个参数。通常我们仅使用第一个参数，表示Array的某个元素。回调函数还可以接收另外两个参数，表示元素的位置和数组本身：var arr = ['A', 'B', 'C'];var r = arr.filter(function (element, index, self) &#123; console.log(element); // 依次打印'A', 'B', 'C' console.log(index); // 依次打印0, 1, 2 console.log(self); // self就是变量arr return true;&#125;); 利用filter，可以巧妙地去除Array的重复元素：'use strict';var r, arr = ['apple', 'strawberry', 'banana', 'pear', 'apple', 'orange', 'orange', 'strawberry'];r = arr.filter(function (element, index, self) &#123; return self.indexOf(element) === index;&#125;);console.log(r.toString()); 去除重复元素依靠的是indexOf总是返回第一个元素的位置，后续的重复元素位置与indexOf返回的位置不相等，因此被filter滤掉了。 sort()sort()方法会直接对Array进行修改，它返回的结果仍是当前Array：var a1 = ['B', 'A', 'C'];var a2 = a1.sort();a1; // ['A', 'B', 'C']a2; // ['A', 'B', 'C']a1 === a2; // true, a1和a2是同一对象 闭包高阶函数除了可以接受函数作为参数外，还可以把函数作为结果值返回。 返回闭包时牢记的一点就是：返回函数不要引用任何循环变量，或者后续会发生变化的变量如果一定要引用循环变量怎么办？方法是再创建一个函数，用该函数的参数绑定循环变量当前的值，无论该循环变量后续如何更改，已绑定到函数参数的值不变：function count() &#123; var arr = []; for (var i=1; i&lt;=3; i++) &#123; arr.push((function (n) &#123; return function () &#123; return n * n; &#125; &#125;)(i)); &#125; return arr;&#125;var results = count();var f1 = results[0];var f2 = results[1];var f3 = results[2];f1(); // 1f2(); // 4f3(); // 9 注意这里用了一个“创建一个匿名函数并立刻执行”的语法：(function (x) &#123; return x * x;&#125;)(3); // 9 理论上讲，创建一个匿名函数并立刻执行可以这么写：function (x) &#123; return x * x &#125; (3); 但是由于JavaScript语法解析的问题，会报SyntaxError错误，因此需要用括号把整个函数定义括起来：(function (x) &#123; return x * x &#125;) (3); 通常，一个立即执行的匿名函数可以把函数体拆开，一般这么写：(function (x) &#123; return x * x;&#125;)(3) 闭包有非常强大的功能。举个栗子： 在面向对象的程序设计语言里，比如Java和C++，要在对象内部封装一个私有变量，可以用private修饰一个成员变量。 在没有class机制，只有函数的语言里，借助闭包，同样可以封装一个私有变量。我们用JavaScript创建一个计数器：'use strict';function create_counter(initial) &#123; var x = initial || 0; return &#123; inc: function () &#123; x += 1; return x; &#125; &#125;&#125; 它用起来像这样：var c1 = create_counter();c1.inc(); // 1c1.inc(); // 2c1.inc(); // 3var c2 = create_counter(10);c2.inc(); // 11c2.inc(); // 12c2.inc(); // 13 在返回的对象中，实现了一个闭包，该闭包携带了局部变量x，并且，从外部代码根本无法访问到变量x。换句话说，闭包就是携带状态的函数，并且它的状态可以完全对外隐藏起来。 闭包还可以把多参数的函数变成单参数的函数。例如，要计算xy可以用Math.pow(x, y)函数，不过考虑到经常计算x2或x3，我们可以利用闭包创建新的函数pow2和pow3：'use strict';function make_pow(n) &#123; return function (x) &#123; return Math.pow(x, n); &#125;&#125;// 创建两个新函数:var pow2 = make_pow(2);var pow3 = make_pow(3);console.log(pow2(5)); // 25console.log(pow3(7)); // 343 使用闭包的注意点： 1）由于闭包会使得函数中的变量都被保存在内存中，内存消耗很大，所以不能滥用闭包，否则会造成网页的性能问题，在IE中可能导致内存泄露。解决方法是，在退出函数之前，将不使用的局部变量全部删除。 2）闭包会在父函数外部，改变父函数内部变量的值。所以，如果你把父函数当作对象（object）使用，把闭包当作它的公用方法（Public Method），把内部变量当作它的私有属性（private value），这时一定要小心，不要随便改变父函数内部变量的值。 闭包的思考关于闭包的总结也可以再看下这篇文章：学习Javascript闭包（Closure） 上面提到的这篇文章的最后，列出了一道思考题：如果你能理解下面两段代码的运行结果，应该就算理解闭包的运行机制了。代码片段一。var name = \"The Window\";var object = &#123; name : \"My Object\", getNameFunc : function()&#123; return function()&#123; return this.name; &#125;; &#125;&#125;;alert(object.getNameFunc()()); 代码片段二。var name = \"The Window\";var object = &#123; name : \"My Object\", getNameFunc : function()&#123; var that = this; return function()&#123; return that.name; &#125;; &#125;&#125;;alert(object.getNameFunc()()); 我先说结果，代码段一的结果是：The Window；而代码段二的结果是：My Object。 关于this关键字，前面已经介绍过了，它代表的实例会根据环境不同而变化的. In JavaScript this always refers to the “owner” of the function we’re executing, or rather, to the object that a function is a method of. 上面这段话，摘自：The this keyword。 我理解的意思是，this永远指向我们要执行的方法的“owner”，或者更确切的说，是指向function作为某个object的一个方法（method）的那个object。 在代码片段一里，object.getNameFunc()返回的是function，假设是f，那么:alert(object.getNameFunc()()); 等价于===》 alert(f());f()的执行已经和object没有关系了，this这里应该指向的是window对象，所以name值应该是：”The Window”。 在代码片段二里，在object.getNameFunc()执行的时候，this代表object对象，用that变量（that不是关键字）保存了起来，而最里面的这个function是可以访问that变量的，那么alert(object.getNameFunc()()); 应该等价于===》 alert(f(that));所以name的值应该是：“My Object”。 箭头函数ES6标准新增了一种新的函数：Arrow Function（箭头函数）。箭头函数有两种格式，一种像上面的，只包含一个表达式，连{ … }和return都省略掉了。还有一种可以包含多条语句，这时候就不能省略{ … }和return：。如果参数不是一个，就需要用括号()括起来：// 两个参数:(x, y) =&gt; x * x + y * y// 无参数:() =&gt; 3.14// 可变参数:(x, y, ...rest) =&gt; &#123; var i, sum = x + y; for (i=0; i&lt;rest.length; i++) &#123; sum += rest[i]; &#125; return sum;&#125; 如果要返回一个对象，就要注意，如果是单表达式，这么写的话会报错：// SyntaxError:x =&gt; &#123; foo: x &#125; 因为和函数体的{ … }有语法冲突，所以要改为：// ok:x =&gt; (&#123; foo: x &#125;) this 箭头函数看上去是匿名函数的一种简写，但实际上，箭头函数和匿名函数有个明显的区别：箭头函数内部的this是词法作用域，由上下文确定。 回顾前面的例子，由于JavaScript函数对this绑定的错误处理，下面的例子无法得到预期结果：var obj = &#123; birth: 1990, getAge: function () &#123; var b = this.birth; // 1990 var fn = function () &#123; return new Date().getFullYear() - this.birth; // this指向window或undefined &#125;; return fn(); &#125;&#125;; 现在，箭头函数完全修复了this的指向，this总是指向词法作用域，也就是外层调用者obj：var obj = &#123; birth: 1990, getAge: function () &#123; var b = this.birth; // 1990 var fn = () =&gt; new Date().getFullYear() - this.birth; // this指向obj对象 return fn(); &#125;&#125;;obj.getAge(); // 25 如果使用箭头函数，以前的那种hack写法：var that = this; 就不再需要了。由于this在箭头函数中已经按照词法作用域绑定了，所以，用call()或者apply()调用箭头函数时，无法对this进行绑定，即传入的第一个参数被忽略：var obj = &#123; birth: 1990, getAge: function (year) &#123; var b = this.birth; // 1990 var fn = (y) =&gt; y - this.birth; // this.birth仍是1990 return fn.call(&#123;birth:2000&#125;, year); &#125;&#125;;obj.getAge(2015); // 25 关于箭头函数中this的解释，可以看这篇文章：箭头函数中this的用法和深入浅出ES6（七）：箭头函数 Arrow Functions这篇 标准对象总结一下，有这么几条规则需要遵守： 不要使用new Number()、new Boolean()、new String()创建包装对象； 用parseInt()或parseFloat()来转换任意类型到number； 用String()来转换任意类型到string，或者直接调用某个对象的toString()方法； 通常不必把任意类型转换为boolean再判断，因为可以直接写if (myVar) {…}； typeof操作符可以判断出number、boolean、string、function和undefined； 判断Array要使用Array.isArray(arr)； 判断null请使用myVar === null； 判断某个全局变量是否存在用typeof window.myVar === ‘undefined’； 函数内部判断某个变量是否存在用typeof myVar === ‘undefined’。 任何对象都有toString()方法吗？null和undefined就没有！确实如此，这两个特殊值要除外，虽然null还伪装成了object类型。 更细心的同学指出，number对象调用toString()报SyntaxError：123.toString(); // SyntaxError 遇到这种情况，要特殊处理一下：123..toString(); // '123', 注意是两个点！(123).toString(); // '123' Date对象 如果要创建一个指定日期和时间的Date对象，可以用：var d = new Date(2015, 5, 19, 20, 15, 30, 123); JavaScript的Date对象月份值从0开始，牢记0=1月，1=2月，2=3月，……，11=12月。 var d = Date.parse('2015-06-24T19:49:22.875+08:00');d; // 1435146562875 var d = new Date(1435146562875);d; // Wed Jun 24 2015 19:49:22 GMT+0800 (CST)d.getMonth(); // 5 使用Date.parse()时传入的字符串使用实际月份01~12，转换为Date对象后getMonth()获取的月份值为0~11。 要获取当前时间戳，可以用：'use strict';if (Date.now) &#123; console.log(Date.now()); // 老版本IE没有now()方法&#125; else &#123; console.log(new Date().getTime());&#125; RegExp， 正则表达式的内容参考：标准对象-RegExp 构造函数除了直接用{ … }创建一个对象外，JavaScript还可以用一种构造函数的方法来创建对象。它的用法是，先定义一个构造函数：function Student(name) &#123; this.name = name; this.hello = function () &#123; alert('Hello, ' + this.name + '!'); &#125;&#125; 你会问，咦，这不是一个普通函数吗？ 这确实是一个普通函数，但是在JavaScript中，可以用关键字new来调用这个函数，并返回一个对象：var xiaoming = new Student('小明');xiaoming.name; // '小明'xiaoming.hello(); // Hello, 小明! 注意，如果不写new，这就是一个普通函数，它返回undefined。但是，如果写了new，它就变成了一个构造函数，它绑定的this指向新创建的对象，并默认返回this，也就是说，不需要在最后写return this;。 新创建的xiaoming的原型链是：xiaoming ----&gt; Student.prototype ----&gt; Object.prototype ----&gt; null xiaoming的原型指向函数Student的原型。如果你又创建了xiaohong、xiaojun，那么这些对象的原型与xiaoming是一样的：xiaoming ↘xiaohong -→ Student.prototype ----&gt; Object.prototype ----&gt; nullxiaojun ↗ 用new Student()创建的对象还从原型上获得了一个constructor属性，它指向函数Student本身：xiaoming.constructor === Student.prototype.constructor; // trueStudent.prototype.constructor === Student; // trueObject.getPrototypeOf(xiaoming) === Student.prototype; // truexiaoming instanceof Student; // true 看晕了吧？用一张图来表示这些乱七八糟的关系就是： 不过还有一个小问题，注意观察：xiaoming.name; // '小明'xiaohong.name; // '小红'xiaoming.hello; // function: Student.hello()xiaohong.hello; // function: Student.hello()xiaoming.hello === xiaohong.hello; // false xiaoming和xiaohong各自的name不同，这是对的，否则我们无法区分谁是谁了。 xiaoming和xiaohong各自的hello是一个函数，但它们是两个不同的函数，虽然函数名称和代码都是相同的！ 如果我们通过new Student()创建了很多对象，这些对象的hello函数实际上只需要共享同一个函数就可以了，这样可以节省很多内存。 要让创建的对象共享一个hello函数，根据对象的属性查找原则，我们只要把hello函数移动到xiaoming、xiaohong这些对象共同的原型上就可以了，也就是Student.prototype： 修改代码如下：function Student(name) &#123; this.name = name;&#125;Student.prototype.hello = function () &#123; alert('Hello, ' + this.name + '!');&#125;; 忘记写new怎么办 如果一个函数被定义为用于创建对象的构造函数，但是调用时忘记了写new怎么办？ 在strict模式下，this.name = name将报错，因为this绑定为undefined，在非strict模式下，this.name = name不报错，因为this绑定为window，于是无意间创建了全局变量name，并且返回undefined，这个结果更糟糕。 所以，调用构造函数千万不要忘记写new。为了区分普通函数和构造函数，按照约定，构造函数首字母应当大写，而普通函数首字母应当小写，这样，一些语法检查工具如jslint将可以帮你检测到漏写的new。 最后，我们还可以编写一个createStudent()函数，在内部封装所有的new操作。一个常用的编程模式像这样：function Student(props) &#123; this.name = props.name || '匿名'; // 默认值为'匿名' this.grade = props.grade || 1; // 默认值为1&#125;Student.prototype.hello = function () &#123; alert('Hello, ' + this.name + '!');&#125;;function createStudent(props) &#123; return new Student(props || &#123;&#125;)&#125; 这个createStudent()函数有几个巨大的优点：一是不需要new来调用，二是参数非常灵活，可以不传，也可以这么传：var xiaoming = createStudent(&#123; name: '小明'&#125;);xiaoming.grade; // 1 如果创建的对象有很多属性，我们只需要传递需要的某些属性，剩下的属性可以用默认值。由于参数是一个Object，我们无需记忆参数的顺序。如果恰好从JSON拿到了一个对象，就可以直接创建出xiaoming。 原型继承在传统的基于Class的语言如Java、C++中，继承的本质是扩展一个已有的Class，并生成新的Subclass。JavaScript由于采用原型继承，我们无法直接扩展一个Class，因为根本不存在Class这种类型。但是办法还是有的。 我们还是用上面的Student函数，现在，我们要基于Student扩展出PrimaryStudent，可以先定义出PrimaryStudent：function PrimaryStudent(props) &#123; // 调用Student构造函数，绑定this变量: Student.call(this, props); this.grade = props.grade || 1;&#125; 但是，调用了Student构造函数不等于继承了Student，PrimaryStudent创建的对象的原型是：new PrimaryStudent() ----&gt; PrimaryStudent.prototype ----&gt; Object.prototype ----&gt; null 必须想办法把原型链修改为：new PrimaryStudent() ----&gt; PrimaryStudent.prototype ----&gt; Student.prototype ----&gt; Object.prototype ----&gt; null 我们必须借助一个中间对象来实现正确的原型链，这个中间对象的原型要指向Student.prototype。为了实现这一点，参考道爷（就是发明JSON的那个道格拉斯）的代码，中间对象可以用一个空函数F来实现：// PrimaryStudent构造函数:function PrimaryStudent(props) &#123; Student.call(this, props); this.grade = props.grade || 1;&#125;// 空函数F:function F() &#123;&#125;// 把F的原型指向Student.prototype:F.prototype = Student.prototype;// 把PrimaryStudent的原型指向一个新的F对象，F对象的原型正好指向Student.prototype:PrimaryStudent.prototype = new F();// 把PrimaryStudent原型的构造函数修复为PrimaryStudent:PrimaryStudent.prototype.constructor = PrimaryStudent;// 继续在PrimaryStudent原型（就是new F()对象）上定义方法：PrimaryStudent.prototype.getGrade = function () &#123; return this.grade;&#125;;// 创建xiaoming:var xiaoming = new PrimaryStudent(&#123; name: '小明', grade: 2&#125;);xiaoming.name; // '小明'xiaoming.grade; // 2// 验证原型:xiaoming.__proto__ === PrimaryStudent.prototype; // truexiaoming.__proto__.__proto__ === Student.prototype; // true// 验证继承关系:xiaoming instanceof PrimaryStudent; // truexiaoming instanceof Student; // true 用一张图来表示新的原型链： 注意，函数F仅用于桥接，我们仅创建了一个new F()实例，而且，没有改变原有的Student定义的原型链。 如果把继承这个动作用一个inherits()函数封装起来，还可以隐藏F的定义，并简化代码：function inherits(Child, Parent) &#123; var F = function () &#123;&#125;; F.prototype = Parent.prototype; Child.prototype = new F(); Child.prototype.constructor = Child;&#125; 这个inherits()函数可以复用：function Student(props) &#123; this.name = props.name || 'Unnamed';&#125;Student.prototype.hello = function () &#123; alert('Hello, ' + this.name + '!');&#125;function PrimaryStudent(props) &#123; Student.call(this, props); this.grade = props.grade || 1;&#125;// 实现原型继承链:inherits(PrimaryStudent, Student);// 绑定其他方法到PrimaryStudent原型:PrimaryStudent.prototype.getGrade = function () &#123; return this.grade;&#125;; 总结JavaScript的原型继承实现方式就是： 定义新的构造函数，并在内部用call()调用希望“继承”的构造函数，并绑定this； 借助中间函数F实现原型链继承，最好通过封装的inherits函数完成； 继续在新的构造函数的原型上定义新方法。 class继承上面的我们看到了JavaScript的对象模型是基于原型实现的，特点是简单，缺点是理解起来比传统的类－实例模型要困难，最大的缺点是继承的实现需要编写大量代码，并且需要正确实现原型链。 新的关键字class从ES6开始正式被引入到JavaScript中。class的目的就是让定义类更简单。 如果用新的class关键字来编写Student，可以这样写：class Student &#123; constructor(name) &#123; this.name = name; &#125; hello() &#123; alert('Hello, ' + this.name + '!'); &#125;&#125; 比较一下就可以发现，class的定义包含了构造函数constructor和定义在原型对象上的函数hello()（注意没有function关键字），这样就避免了Student.prototype.hello = function () {…}这样分散的代码。 最后，创建一个Student对象代码和前面章节完全一样：var xiaoming = new Student('小明');xiaoming.hello(); class继承原型继承的中间对象，原型对象的构造函数等等都不需要考虑了，直接通过extends来实现：class PrimaryStudent extends Student &#123; constructor(name, grade) &#123; super(name); // 记得用super调用父类的构造方法! this.grade = grade; &#125; myGrade() &#123; alert('I am at grade ' + this.grade); &#125;&#125; 注意PrimaryStudent的定义也是class关键字实现的，而extends则表示原型链对象来自Student。子类的构造函数可能会与父类不太相同，例如，PrimaryStudent需要name和grade两个参数，并且需要通过super(name)来调用父类的构造函数，否则父类的name属性无法正常初始化。 PrimaryStudent已经自动获得了父类Student的hello方法，我们又在子类中定义了新的myGrade方法。 ES6引入的class和原有的JavaScript原型继承有什么区别呢？实际上它们没有任何区别，class的作用就是让JavaScript引擎去实现原来需要我们自己编写的原型链代码。简而言之，用class的好处就是极大地简化了原型链代码。 你一定会问，class这么好用，能不能现在就用上？ 现在用还早了点，因为不是所有的主流浏览器都支持ES6的class。如果一定要现在就用上，就需要一个工具把class代码转换为传统的prototype代码，可以试试Babel这个工具。 操作DOM由于HTML文档被浏览器解析后就是一棵DOM树，要改变HTML的结构，就需要通过JavaScript来操作DOM。 始终记住DOM是一个树形结构。操作一个DOM节点实际上就是这么几个操作： 更新：更新该DOM节点的内容，相当于更新了该DOM节点表示的HTML的内容； 遍历：遍历该DOM节点下的子节点，以便进行进一步操作； 添加：在该DOM节点下新增一个子节点，相当于动态增加了一个HTML节点； 删除：将该节点从HTML中删除，相当于删掉了该DOM节点的内容以及它包含的所有子节点。 在操作一个DOM节点前，我们需要通过各种方式先拿到这个DOM节点。最常用的方法是document.getElementById()和document.getElementsByTagName()，以及CSS选择器document.getElementsByClassName()。 由于ID在HTML文档中是唯一的，所以document.getElementById()可以直接定位唯一的一个DOM节点。document.getElementsByTagName()和document.getElementsByClassName()总是返回一组DOM节点。要精确地选择DOM，可以先定位父节点，再从父节点开始选择，以缩小范围。 例如：// 返回ID为'test'的节点：var test = document.getElementById('test');// 先定位ID为'test-table'的节点，再返回其内部所有tr节点：var trs = document.getElementById('test-table').getElementsByTagName('tr');// 先定位ID为'test-div'的节点，再返回其内部所有class包含red的节点：var reds = document.getElementById('test-div').getElementsByClassName('red');// 获取节点test下的所有直属子节点:var cs = test.children;// 获取节点test下第一个、最后一个子节点：var first = test.firstElementChild;var last = test.lastElementChild; 第二种方法是使用querySelector()和querySelectorAll()，需要了解selector语法，然后使用条件来获取节点，更加方便：// 通过querySelector获取ID为q1的节点：var q1 = document.querySelector('#q1');// 通过querySelectorAll获取q1节点内的符合条件的所有节点：var ps = q1.querySelectorAll('div.highlighted &gt; p'); 注意：低版本的IE&lt;8不支持querySelector和querySelectorAll。IE8仅有限支持 严格地讲，我们这里的DOM节点是指Element，但是DOM节点实际上是Node，在HTML中，Node包括Element、Comment、CDATA_SECTION等很多种，以及根节点Document类型，但是，绝大多数时候我们只关心Element，也就是实际控制页面结构的Node，其他类型的Node忽略即可。根节点Document已经自动绑定为全局变量document。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/10/22/JavaScript-knowledge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"JavaScript","slug":"javascript","permalink":"http://agehua.github.io/tags/javascript/"}]},{"title":"PBOC知识收集（干货）","slug":"PBOCKonwledgeCode","date":"2017-09-20T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/09/21/PBOCKonwledgeCode/","link":"","permalink":"http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/","excerpt":"PBOC规范基础知识（干货）摘自：《中国集成电路（IC）卡规范第2部分：电子钱包电子存折应用规范》\n消费交易消费交易允许持卡人使用电子存折或电子钱包的余额进行购物或获取服务。此交易可以在销售点终端(POS)上脱机进行。使用电子存折进行的消费交易必须提交个人识别码(PIN)，使用电子钱包则不需要。\n发出初始化消费(INITIALIZE FOR PURCHASE)命令指令字节：","text":"PBOC规范基础知识（干货）摘自：《中国集成电路（IC）卡规范第2部分：电子钱包电子存折应用规范》 消费交易消费交易允许持卡人使用电子存折或电子钱包的余额进行购物或获取服务。此交易可以在销售点终端(POS)上脱机进行。使用电子存折进行的消费交易必须提交个人识别码(PIN)，使用电子钱包则不需要。 发出初始化消费(INITIALIZE FOR PURCHASE)命令指令字节： 命令 CLA INS P1 P2消费初始化(INITIALIZE FOR PURCHASE) ‘80’ ‘50’ ‘01’ ‘0X’ 上面的指令字节，其实就是APDU（Application Protocol data unit), 是智能卡与智能卡读卡器之间传送的信息单元 APDU的格式为：CLA INS P1 P2 Lc Data Le其中CLA为指令类别；INS为指令码；P1、P2为参数；Lc为Data的长度；Le为希望响应时回答的数据字节数，0表最大可能长度。 COS命令由具体应用分为4种命令报文结构如下：① 情形1：CLA INS P1 P2 00② 情形2：CLA INS P1 P2 Le③ 情形3：CLA INS P1 P2 Lc Data④ 情形4：CLA INS P1 P2 Lc Data Le 而消费交易初始化的具体命令如下： 响应报文结构：响应数据 响应状态码Data SW1 SW1 DATA： 返回给用户的数据，即命令的执行结果。SW1、SW2： 返回命令处理的状态。 如果命令执行不成功，则只在响应报文中回送SW1和SW2。命令执行成功的状态字一般是“9000”，但个别卡商在执行成功后，返回61 xx，这里表示还有xx字节需要返回，需要再使用卡商提供的GET REPONSE命令接收从IC卡中传递向读卡设备的数据。 消费交易初始化执行成功，返回的响应报文，总长度是（Le 0F）15个字节： 一个字节是8bit，4个bit用一个16进制表示（0-9 A-F）。所以一个字节可以由两个16进制表示 VERIFY 命令定义和范围VERIFY命令用于校验命令数据域中的个人识别码的正确性。如PIN文件位于某一应用下，当此应用被锁定时，禁止校验PIN;如PIN文件位于MF下，当应用被锁 定后可以执行校验PIN命令。 命令报文 代码 值 CLA ‘00’ INS ‘20’ P1 ‘00’ P2 ‘00’ Lc 可变 Data 外部输入的个人识别码 Le 不存在 P2=’00’表示无特殊限定符被使用。在IC卡上，VERIFY命令在处理过程中应明确知道如何去寻找个人识别码。 这里外部输入的PIN码长度是，4到12位（2-6字节），响应报文数据域不存在。 此命令执行成功的状态字是“9000”。当前的应用选择中，命令数据域中外部输入的个人识别码与卡中存放的个人识别码校验失败时，IC 卡将回送SW2=’Cx’，其中’x’表示个人识别码允许重试的次数;当卡回送’C0’时，表示不能重试个人识别 码。此时再使用VERIFY命令时，将回送失败状态字SW1 SW2=“6983”。 IC卡可能回送的警告状态字见表48。 工具代码下面贴一些转换工具代码：/** * 把16进制字符串转换成字节数组 * * @param hex * @return */public static byte[] hexStringToByte(String hex) &#123; int len = (hex.length() / 2); byte[] result = new byte[len]; char[] achar = hex.toCharArray(); for (int i = 0; i &lt; len; i++) &#123; int pos = i * 2; result[i] = (byte) (toByte(achar[pos]) &lt;&lt; 4 | toByte(achar[pos + 1])); &#125; return result;&#125;private static byte toByte(char c) &#123; byte b = (byte) \"0123456789ABCDEF\".indexOf(c); return b;&#125;/** * 把字节数组转换成16进制字符串 * * @param bArray * @return */public static final String bytesToHexString(byte[] bArray) &#123; if(bArray == null ) &#123; return \"\"; &#125; StringBuffer sb = new StringBuffer(bArray.length); String sTemp; for (int i = 0; i &lt; bArray.length; i++) &#123; sTemp = Integer.toHexString(0xFF &amp; bArray[i]); if (sTemp.length() &lt; 2) sb.append(0); sb.append(sTemp.toUpperCase()); &#125; return sb.toString();&#125; IC卡交易金额转换（以分为单位，输出byte[]）public static String IntToHex(int n)&#123; char[] ch = new char[20]; int nIndex = 0; while ( true )&#123; int m = n/16; int k = n%16; if ( k == 15 ) ch[nIndex] = 'F'; else if ( k == 14 ) ch[nIndex] = 'E'; else if ( k == 13 ) ch[nIndex] = 'D'; else if ( k == 12 ) ch[nIndex] = 'C'; else if ( k == 11 ) ch[nIndex] = 'B'; else if ( k == 10 ) ch[nIndex] = 'A'; else ch[nIndex] = (char)('0' + k); nIndex++; if ( m == 0 ) break; n = m; &#125; StringBuffer sb = new StringBuffer(); sb.append(ch, 0, nIndex); sb.reverse(); String strHex = new String(\"\"); strHex += sb.toString(); return strHex;&#125;public static byte[] hexStringToByteArray(String s) &#123; if (TextUtils.isEmpty(s)) return null; int len = s.length(); String append= \"\"; switch (len)&#123; case 1: s = \"0000000\"+s; break; case 2: s = \"000000\"+s; break; case 3: s = \"00000\"+s; break; case 4: s = \"0000\"+s; break; case 5: s = \"000\"+s; break; case 6: s = \"00\"+s; break; case 7: s = \"0\"+s; break; case 8: break; &#125; len = s.length(); byte[] b = new byte[len / 2]; for (int i = 0; i &lt; len; i += 2) &#123; // 两位一组，表示一个字节,把这样表示的16进制字符串，还原成一个字节 b[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) &lt;&lt; 4) + Character .digit(s.charAt(i + 1), 16)); &#125; return b;&#125;/** * 交易金额转换 */public static byte[] intTo4HexByte(int num)&#123; return hexStringToByteArray(IntToHex(num));&#125; Hex字符串转换为GBKpublic static String decode(String hexStr) throws UnsupportedEncodingException &#123; if (null == hexStr || \"\".equals(hexStr) || (hexStr.length()) % 2 != 0) &#123; return null; &#125; int byteLength = hexStr.length() / 2; byte[] bytes = new byte[byteLength]; int temp = 0; for (int i = 0; i &lt; byteLength; i++) &#123; temp = hex2Dec(hexStr.charAt(2 * i)) * 16 + hex2Dec(hexStr.charAt(2 * i + 1)); bytes[i] = (byte) (temp &lt; 128 ? temp : temp - 256); &#125; return new String(bytes,\"GBK\");&#125;private static int hex2Dec(char ch) &#123; if (ch == '0') return 0; if (ch == '1') return 1; if (ch == '2') return 2; if (ch == '3') return 3; if (ch == '4') return 4; if (ch == '5') return 5; if (ch == '6') return 6; if (ch == '7') return 7; if (ch == '8') return 8; if (ch == '9') return 9; if (ch == 'a') return 10; if (ch == 'A') return 10; if (ch == 'B') return 11; if (ch == 'b') return 11; if (ch == 'C') return 12; if (ch == 'c') return 12; if (ch == 'D') return 13; if (ch == 'd') return 13; if (ch == 'E') return 14; if (ch == 'e') return 14; if (ch == 'F') return 15; if (ch == 'f') return 15; else return -1;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"PBOC","slug":"pboc","permalink":"http://agehua.github.io/tags/pboc/"},{"name":"PBOC 2.0","slug":"pboc-2-0","permalink":"http://agehua.github.io/tags/pboc-2-0/"}]},{"title":"PBOC知识收集","slug":"PBOCKonwledge","date":"2017-09-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/09/12/PBOCKonwledge/","link":"","permalink":"http://agehua.github.io/2017/09/12/PBOCKonwledge/","excerpt":"PBOC规范基础知识术语和定义\n集成电路 integrated circuit (IC) 具有处理和/或存储功能的电子器件。\n集成电路卡(IC 卡) integrated circuit(s) card (ICC) 内部封装一个或多个集成电路用于执行处理和存储功能的卡片。\n电子存折 electronic deposit 一种为持卡人进行消费、取现等交易而设计的支持个人识别码(PIN)保护的金融IC卡应用。它支持圈存、圈提、消费和取现等交易。\n电子钱包 electronic purse 一种为方便持卡人小额消费而设计的金融IC卡应用。它支持圈存、消费等交易。消费不支持个人识别码(PIN)保护。","text":"PBOC规范基础知识术语和定义 集成电路 integrated circuit (IC) 具有处理和/或存储功能的电子器件。 集成电路卡(IC 卡) integrated circuit(s) card (ICC) 内部封装一个或多个集成电路用于执行处理和存储功能的卡片。 电子存折 electronic deposit 一种为持卡人进行消费、取现等交易而设计的支持个人识别码(PIN)保护的金融IC卡应用。它支持圈存、圈提、消费和取现等交易。 电子钱包 electronic purse 一种为方便持卡人小额消费而设计的金融IC卡应用。它支持圈存、消费等交易。消费不支持个人识别码(PIN)保护。 圈存 load持卡人将其在银行相应账户上的资金划转到电子存折或电子钱包中。圈存交易必须在金融终端上联机进行。一般情况下，圈存到电子存折中的资金仍计付活期利息，圈存到电子钱包中的资金不计付利息。但 具体作法由发卡方自行决定。 圈提 unload持卡人将电子存折中的部分或全部资金划回到其在银行的相应账户上。圈提交易必须在金融终端上 联机进行2。 符号和缩略语下列符号和缩略语适用于 JR/T 0025 的本部分。 AID 应用标识符(Application Identifier) an 字母数字型(Alphanumeric) ans 字母数字及特殊字符型(Alphanumeric Special) ATI 应用类型标识(Application Type Identifier)，卡上有两种应用时，用来区分是电子存折和电子钱包 b 二进制(Binary) CLA 命令报文的类别字节(Class Byte of the Command Message) cn 压缩数字型(Compressed Numeric) DEA 数据加密算法(Data Encryption Algorithm) DF 专用文件(Dedicated File) ED 电子存折(Electronic Deposit) EF 基本文件(Elementary File) EP 电子钱包(Electronic Purse) FCI 文件控制信息(File Control Information) INS 命令报文的指令字节(Instruction Byte of Command Message) ISO 国际标准化组织(International Organization for Standardization) Lc 终端发出的命令数据的实际长度(Exact Length of Data Sent) Le 响应数据中的最大期望长度(Maximum Length of Data Expected) MAC 报文鉴别码(Message Authentication Code) MF 主文件(Master File) n 数字型(Numeric) P1 参数 1(Parameter 1) P2 参数 2(Parameter 2) PIN 个人识别码(Personal Identification Number) POS 销售点终端(Point of Service) PSAM 销售点终端安全存取模块(Purchase Secure Access Module) PSE 支付系统环境(Payment System Environment) PVN PIN 校验值(PIN Verification Number) SFI 短文件标识符(Short File Identifier) SW1 状态字 1(Status Word One) SW2 状态字 2(Status Word Two) TAC 交易验证码(Transaction Authorization Crypogram) TTI 交易类型标识(Transaction Type Identifier) YYYYMMDD 年、月、日(Year, Month, Day) 智能卡又称为IC卡(Integrated circuit Card),即集成电路卡。根据卡中使用的集成电路的不同可以分为存储器卡、逻辑加密卡和CPU卡。由于CPU卡中集成了中央处理器CPU、存储器和芯片操作系统(Chip Operating System, COS) ,构成一个完整的计算机系统, 具有独立的数据处理能力, 因此安全性大大增强,从而得到了广泛的应用,成为IC卡中的主流产品。 文件操作2.1 基本文件结构文件系统是COS的基础模块,它负责组织、管理、维护IC卡内存储的所有数据。根据ISO7816-4,COS 支持的文件类型为: 主文件(Master File, MF) 、目录文件(Dedicated File, DF)和基本文件(Elementary File,EF) 。主文件MF为文件系统的根，下面可以有多个目录文件DF和基本文件EF。目录文件DF分为DDF和ADF两种。DDF可以含有下级目录ADF, 而ADF不能含有下级目录文件。 主文件MF在IC卡中唯一且必须存在。DDF是指包含多个应用的DF, 一个ADF则代表一个应用, 任何一个DF在物理上和逻辑上都保持独立。基本文件EF用于存放密钥或用户数据, 分为密钥文件和工作基本文件。 三种专用文件(DF)类型:MF: 根目录，是整个文件系统的根，同属应用环境类。MF 下可以有 EF(基本文件)、SF (安全文件)、DDF(目录文件)、ADF(应用文件);DDF: 目录文件，用于定义一个应用环境，它是应用的集合。DDF下可以有ADF、子DDF、 EF和SF等结构。ADF: 应用文件，用于定义具体应用。ADF下可以有EF和SF。 2.2 文件的访问控制文件的访问控制可采取鉴别寄存器方式和状态机方式,这里以鉴别寄存器方式为例。用两个四位寄存器来表示安全状态: 一个寄存器称为MF的安全状态寄存器,另一个寄存器为当前DF的安全状态寄存器。每个寄存器的初始值是0,取值安全状态员安全状态圆执行命令符合命令要求的安全属性钥命令拒绝安全机制再晕图员智能卡安全体系范围是0～F之间的某一个值。文件有两种不同的访问控制权限AC0,AC1。AC0 是使用权限,AC1 是修改权限,分别用一个字节表示。当前安全状态寄存器的值大于AC字节的低半字节小于其高半字节时, 该文件的相应读、写权限在该安全状态下被满足,则能进行相关操作。COS在建立文件时指定其AC0和AC1的值来对文件的访问权限进行设定,通过口令校验和外部认证两条命令可以改变安全状态寄存器的值,从而利用安全机制实现对文件的访问控制。 命令的类别字节和指令字节 命令 CLA INS P1 P2 修改个人识别码(CHANGE PIN) ‘80’ ‘5E’ ‘01’ ‘00’ 圈存(CREDIT FOR LOAD) ‘80’ ‘52’ ‘00’ ‘00’ 消费/取现(DEBIT FOR PURCHASE/CASH WITHDRAW) ‘80’ ‘54’ ‘01’ ‘00’ 圈提(DEBIT FOR UNLOAD) ‘80’ ‘54’ ‘03’ ‘00’ 读余额(GET BALANCE) ‘80’ ‘5C’ ‘00’ ‘0X’ 取交易认证(GET TRANSACTION PROVE) ‘80’ ‘5A’ ‘00’ ‘XX’ 取现初始化(INITIALIZE FOR CASH WITHDRAW) ‘80’ ‘50’ ‘02’ ‘01’ 圈存初始化(INITIALIZE FOR LOAD) ‘80 ‘50’ ‘00’ ‘0X’ 消费初始化(INITIALIZE FOR PURCHASE) ‘80’ ‘50’ ‘01’ ‘0X’ 圈提初始化(INITIALIZE FOR UNLOAD) ‘80’ ‘50’ ‘05’ ‘01’ 修改初始化(INITIALIZE FOR UPDATE) ‘80’ ‘50’ ‘04’ ‘01’ 重装个人识别码(RELOAD PIN) ‘80’ ‘5E’ ‘00’ ‘00’ 修改透支限额(UPDATE OVERDRAW LIMIT) ‘80’ ‘58’ ‘00’ ‘00’ IC卡、M1卡、CPU卡、SAM卡、PSAM卡的联系与区别 一、 技术方面（非接触式IC卡） 1、 逻辑加密卡又叫存储卡，卡内的集成电路具有加密逻辑和EEPROM（电可擦除可编程只读存储器）。 2、 CPU卡又叫智能卡，卡内的集成电路包括中央处理器（CPU）、EEPROM、随机存储器(ROM)、以及固化在只读存储器（ROM）中的片内操作系统(COS)，有的卡内芯片还集成了加密运算协处理器以提高安全性和工作速度，使其技术指标远远高于逻辑加密卡。 3、 CPU卡由于具有微处理功能，使得在交易速度以及数据干扰方面远远高于逻辑加密卡，且允许多张卡片同时操作，具有防冲突机制。 4、 两者在技术方面的最大区别在于：CPU卡是一种具有微处理芯片的IC卡，可执行加密运算和其它操作，存储容量较大，能应用于不同的系统；逻辑加密卡是一种单一的存储卡，主要特点是内部有只读存储器，但存储容量较CPU卡小，使其在用途方面没有扩展性。 二、 保密方面（非接触式IC卡） 1、 逻辑加密卡具有防止对卡中信息随意改写功能的存储IC卡，当对加密卡进行操作时必须首先核对卡中密码，只有核对正确，卡中送出一串正确的应答信号时，才能对卡进行正确的操作，但由于只进行一次认证，且无其它的安全保护措施，容易导致密码的泄露和伪卡的产生，其安全性能很低。 2、 由于CPU卡中有微处理机和IC卡操作系统（COS），当CPU卡进行操作时，可进行加密和解密算法（算法和密码都不易破解），用户和IC卡系统之间需要进行多次的相互密码认证（且速度极快），提高了系统的安全性能，对于防止伪卡的产生有很好的效果。 综上所述，对于逻辑加密卡和CPU卡来说，CPU卡不仅具有逻辑加密卡的所有功能，更具有逻辑加密卡所不具备的高安全性、灵活性以及支持与应用扩展等优良性能，也是今后IC卡发展的主要趋势和方向。 CPU卡安全系统与逻辑加密系统的比较 众所周知，密钥管理系统（Key Management System），也简称KMS，是IC项目安全的核心。如何进行密钥的安全管理，贯穿着IC卡应用的整个生命周期。 1、 非接触逻辑加密卡的安全认证，依赖于每个扇区独立的KEYA和KEYB的校验，可以通过扇区控制字对KEYA和KEYB的不同安全组合，实现扇区数据的读写安全控制。非接触逻辑加密卡的个人化也比较简单，主要包括数据和各扇区KEYA、KEYB的更新，在期间所有敏感数据包括KEYA和KEYB都是直接以明文的形式更新。由于KEYA和KEYB的校验机制，只能解决卡片对终端的认证，而无法解决终端对卡片的认证，即我们俗称的“伪卡”的风险。接触逻辑加密卡，即密钥就是一个预先设定的确定数，无论用什么方法计算密钥，最后就一定要和原先写入的数一致，就可以对被保护的数据进行读写操作。因此无论是一卡一密的系统还是统一密码的系统，经过破解就可以实现对非接触逻辑加密卡的解密。很多人认为只要是采用了一卡一密、实时在线系统或非接触逻辑加密卡的ID号就能避免密钥被解密，其实，非接触逻辑加密卡被解密就意味着M1卡可以被复制，使用在线系统尽可以避免被非法充值，但是不能保证非法消费，即复制一张一样ID号的M1卡，就可以进行非法消费。现在的技术使用FPGA就可以完全复制。基于这个原理，M1的门禁卡也是不安全的。目前国内80%的门禁产品均是采用原始IC卡的ID号或ID卡的ID号去做门禁卡，根本没有去进行加密认证或开发专用的密钥，其安全隐患远远比Mifare卡的破解更危险，非法破解的人士只需采用的是专业的技术手段就可以完成破解过程，导致目前国内大多数门禁产品都不具备安全性原因之一，是因为早期门禁产品的设计理论是从国外引进过来的，国内大部分厂家长期以来延用国外做法，采用ID和IC卡的只读特性进行身份识别使用，很少关注卡与机具间的加密认证，缺少钥匙体系的设计；而ID卡是很容易可复制的载体，导致所有的门禁很容易几乎可以在瞬间被破解复制；这才是我们国内安防市场最大的灾难。 2、 非接触CPU卡智能卡与非接触逻辑加密卡相比，拥有独立的CPU处理器和芯片操作系统，所以可以更灵活的支持各种不同的应用需求，更安全的设计交易流程。但同时，与非接触逻辑加密卡系统相比，非接触CPU卡智能卡的系统显得更为复杂，需要进行更多的系统改造，比如密钥管理、交易流程、PSAM卡以及卡片个人化等。密钥通常分为充值密钥（ISAM卡），减值密钥（PSAM卡），外部认证密钥（SAM卡）和全能密钥（ASAM卡）。非接触CPU卡智能卡可以通过内外部认证的机制，例如像建设部定义的电子钱包的交易流程，高可靠的满足不同的业务流程对安全和密钥管理的需求。对电子钱包圈存可以使用圈存密钥，消费可以使用消费密钥，清算可以使用TAC密钥，更新数据可以使用卡片应用维护密钥，卡片个人化过程中可以使用卡片传输密钥、卡片主控密钥、应用主控密钥等，真正做到一钥一用。 SAM(Secure Access Module)安全存取模块介绍为什么要用SAM？究竟谁最开始使用SAM这个词，已经无从考证，能够确认的是：这个世界上先有了PSAM，然后才有了SAM。由于网络状况的原因，或者是应用环境的要求，使用IC卡作为支付介质的系统里面，消费环境不能在每次交易的时候，都做到实时与后台相连接认证IC卡的合法性以及交易完全性。因此，一种我们目前已经认可的交易模式——“电子钱包脱机消费”产生了。即便目前通讯技术发展到已经不存在技术障碍，在权衡风险、代价、方便性等等，我们还是要继续使用并发扬光大脱机消费这样一个模式。由此，就需要对发生交易的终端有所要求，一是能够鉴别IC卡的真伪，再者需要能够保证交易的合法性与安全性，本着不把终端制造商拉下水的目的，于是，坚持一个原则：终端设备与系统安全机制分离，即所有有关安全性的因素，都放置到一个叫PSAM卡里面，由系统发行方来发行管理。没有 PSAM卡的消费终端，相当于没有SIM卡的手机，安装PSAM卡以后，该消费终端就获得了系统运营商的许可，有权鉴别卡片的真伪，有权从卡上的钱包扣款。因此，PSAM的解释为：销售点终端安全存取模块（Purchase Secure Access Module）。 上述最初起源自金融领域 IC卡电子钱包支付系统中的消费应用。在迅猛发展，并极具想象力的IC卡行业，PSAM的应用模式很快得到了延伸，去掉了P（Purchase）的限制之后的SAM（Secure Access Module），被用于很多模式中，变成了“各种终端内嵌入的、认证及存储所有安全数据与敏感信息的设备”。SAM是一个统称，SAM可以是一张标准尺寸的IC卡大小，更多的时候还是符合ISO/IEC 7810里面ID-000标准的小卡形状，也可以是一个DIP8或者SOP8/16封装的IC集成电路形状。如同印章一样，放一个SAM到一个通用的设备里面，表明运营商获得这个设备的控制权和所有权，才能完成该终端赋予的各种功能。 CPU卡加密算法和随机数发生器与安装在读写设备中的密钥认证卡(SAM卡)相互发送认证的随机数，可以实现以下功能： 1）通过终端设备上SAM卡实现对卡的认证 2）CPU卡与终端设备上的SAM卡的相互认证，实现对卡终端的认证 3）通过ISAM卡对CPU卡进行充值操作，实现安全的储值 4）通过PSAM卡对CPU卡进行减值操作，实现安全的扣款 5）在终端设备与CPU卡中传输的数据是加密传输 6）通过对CPU卡发送给SAM卡的MAC1，SAM卡发送给CPU的MAC2和由CPU卡返回的TAC，可以实现数据传输验证的计算。而MAC1、MAC2和TAC就是同一张CPU卡每次传输的过程中都是不同的，因此无法使用空中接收的办法来破解CPU卡的密钥。 有几种SAM？ PSAM：放在脱机消费终端内，用来控制电子钱包脱机消费交易的SAM卡，通常是铳成ID-000的小卡形状，存放消费主密钥，能够验证用户卡上消费子密钥是否符合约定的对应关系，并且保证扣款过程的安全性。 ISAM：ISAM的出现并不具有典型意义，其中的I，可解释为Input，也可解释为Increase，放置在充值终端设备内，脱机充值交易中控制充值交易安全。说它不具有典型意义的原因是，脱机充值的模式是小额支付系统早期的模式，基于安全、风险、政策、技术发展等考虑，脱机充值应用在未来不会有生命力，因此， ISAM作为一个过渡产品，慢慢会成为历史。 ESAM，ESAM属于企业创造的新名词，其中的“E”代表一种形态，特指采用SOP或者DIP封装形式的SAM，作为设备原始设计的一部分，生产的时候焊接在设备的电路板上，不像是其他的SAM是在卡座内，可以灵活拆卸。ESAM的名字与功能无关，比如ESAM形式的PSAM或者ISAM，比如ESAM形式的电子钱包应用。都是符合逻辑的说法。ESAM有几种典型的应用：作为电子计数文件，在预付费表具内控制表具的运行。作为安全数据的存储与认证，实现硬件设备的版权保护与安全使用。 USAM： 是一个新产品，是基于已有SAM概念的基础上，进行的10%左右的创新而来，其中的“U”，大家一定比较容易猜到，即“USB”，是一个采用USB接口和通讯方式的SAM，在这里补充一下，前面所说的各种SAM的通讯方式都是符合ISO/IEC 7816中规定的接口和通讯协议。USAM是两种成熟技术结合，一种全新形态的产品。能大幅度提高SAM的效率与性能，减少设备开发工作量，使SAM的应用趋于标准化、开放性，也扩展了SAM的应用领域。 SAM的技术要求SAM是与终端设备配套使用的安全设备，它具备这样的几个基本要求： 1、是带有COS的CPU卡（模块）； 2、密钥安全的存储在卡内，在某种认可的权限下，能被用于运算，但是不能被直接读出； 3、高安全等级芯片，低功耗、宽电压、宽温度范围； 4、SAM最核心的要求是安全性； 5、SAM最重要的两个参数是运算速度和通讯速率； 对IC卡操作时，耗费时间最多的环节是通讯所占用的时间，而在IC卡应用系统中，尤其是非接触式的应用中，每一个毫秒的时间都是非常宝贵的，都会极大地影响用户感受，在高速公路不停车收费系统中，每增加一个毫秒，都意味着通行速度的大幅降低。 而采用USAM的最大特点在于：1、减少数据流通环节；2、提高数据通讯速度。 USAM直接插入标准USB接口即可使用，不用外接IC卡读写器或者需要SAM卡座；便于安装、使用； USAM比较适合用于：城市通卡、高速公路收费、金融领域、加油领域、预付费水电气表。 参考资料PSAM SAM：https://www.bbsmax.com/A/lk5aGpwPz1/ IC卡、M1卡、CPU卡、SAM卡、PSAM卡的联系与区别:https://www.bbsmax.com/A/8Bz8BRpx5x/ 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/09/12/PBOCKonwledge/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"},{"name":"PBOC","slug":"pboc","permalink":"http://agehua.github.io/tags/pboc/"},{"name":"PBOC 2.0","slug":"pboc-2-0","permalink":"http://agehua.github.io/tags/pboc-2-0/"}]},{"title":"Android面试题积累","slug":"IntervieweeQuestions","date":"2017-08-16T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/08/17/IntervieweeQuestions/","link":"","permalink":"http://agehua.github.io/2017/08/17/IntervieweeQuestions/","excerpt":"1、Activity面试题1、Activity是什么Activity是四大组件之一，它提供一个界面让用户点击和各种滑动操作，这就是Activity\n2、Activity四种状态runingpausedstoppedkilled\n3、Activity生命周期onCreate()onStart()","text":"1、Activity面试题1、Activity是什么Activity是四大组件之一，它提供一个界面让用户点击和各种滑动操作，这就是Activity 2、Activity四种状态runingpausedstoppedkilled 3、Activity生命周期onCreate()onStart()onResume()onPause()onStop()onDestroy()onRestart() 4、进程的优先级空进程后台进程服务进程可见进程前台进程 5、Activity任务栈先进后出 6、Activity启动模式standardsingletopsingletask: 能够保证Activity A在栈中只有一个实例，这个栈也允许存在其他的实例. 特别需要注意的是使用startActivityForResult方法的时候，根据startActivityForResult的api说明: if the activity you are launching uses the singleTask launch mode, it will not run in your task and thus you will immediately receive a cancel result意思就是使用startActivityForResult方法启动一个singleTask模式的Activity，该Activity不会在原来的任务栈中启动，因此会立即收到一个RESULT_CANCELED结果 singleinstance: singleInstance要求activity的实例不仅只有一个，并且整个task中只有一个activity实例，而singleTask所在的栈中允许存在其他activity的实例。 singleInstance的activity也具有上面的特性，此外，activity设置了singleInstance，那么无论被启动的activity有没有设置singleInstance，都无法获取返回值 7、scheme跳转协议Android中的scheme是一种页面内跳转协议，通过定义自己的scheme协议，可以跳转到app中的各个页面服务器可以定制化告诉app跳转哪个页面App可以通过跳转到另一个App页面可以通过H5页面跳转页面（DeepLink）：&lt;a href=&quot;[scheme]://[host]/[path]?[query]&quot;&gt;启动应用程序&lt;/a&gt; &lt;intent-filter&gt; &lt;data android:scheme=\"http\" /&gt; &lt;!-- or you can use deep linking like --&gt; &lt;data android:scheme=\"http\" android:host=\"xyz.abc.com\"/&gt; &lt;action android:name=\"android.intent.action.VIEW\"/&gt; &lt;category android:name=\"android.intent.category.BROWSABLE\"/&gt; &lt;category android:name=\"android.intent.category.DEFAULT\"/&gt;&lt;/intent-filter&gt; 2、Fragment面试题1、Fragment为什么被称为第五大组件Fragment比Activity更节省内存，其切换模式也更加舒适，使用频率不低于四大组件，且有自己的生命周期，而且必须依附于Activity 2、Activity创建Fragment的方式静态创建：在activity布局文件里声明fragment，activity_main.xml中声明： 动态创建：通过java代码将fragment添加到已存的ViewGroup中fragment = new MyFragment();fragmentStack.push(fragment);transaction = manager.beginTransaction();transaction.add(R.id.fragments, fragment);transaction.commit(); 3、FragmentPageAdapter和FragmentStatePagerAdapter的区别FragmentPageAdapter在每次切换页面的的时候，是将Fragment进行分离，适合页面较少的Fragment使用以保存一些内存，对系统内存不会多大影响FragmentPagerAdapter 中所有创建过的Fragment都缓存在FragmentManager中；页面切换，只是调用detach，而不是remove，所以只执行onDestroyView，而不是onDestroy。 destroyItem的时候，调用detach从页面上移除fragment，内存中还有当前实例 FragmentStatePagerAdapter，使用 mFragments 在每次切换页面的时候，是将Fragment进行回收，适合页面较多的Fragment使用，这样就不会消耗更多的内存FragmentStatePagerAdapter缓存的个数是(mOffscreenPageLimit * 2 + 1)，而不是全部；页面切换，调用remove删除，且要缓存State。 destroyItem的时候，将当前fragment = null，直接销毁fragment 4、Fragment生命周期onAttach()onCreate()onCreateView()onActivityCreated()onStart()onResume()onPause()onStop()onDestroyView()onDestroy()onDetach() 5、Fragment的通信Fragment调用Activity中的方法：getActivityActivity调用Fragment中的方法：接口回调Fragment调用Fragment中的方法：FragmentManager.findFragmentById 6、Fragment的replace、add、remove方法replace：替代Fragment的栈顶页面add：添加Fragment到栈顶页面remove：移除Fragment栈顶页面 3、Service面试题1、Service是什么Service是四大组件之一，它可以在后台执行长时间运行操作而没有用户界面的应用组件 2、Service和Thread的区别Service是安卓中系统的组件，它运行在独立进程的主线程中，不可以执行耗时操作，超时会有ANR异常。Thread是程序执行的最小单元，分配CPU的基本单位，可以开启子线程执行耗时操作Service在不同Activity中可以获取自身实例，可以方便的对Service进行操作。Thread在不同的Activity中难以获取自身实例，如果Activity被销毁，Thread实例就很难再获取得到 3、Service启动方式startServicebindService 4、Service生命周期startService：onCreate()onStartCommand(Intent intent, int flags, int startId)onDestroy() 重点介绍下，onStartCommand()方法，先看下官方doc里的介绍：Added in API level 5Called by the system every time a client explicitly starts the service by calling startService(Intent), providing the arguments it supplied and a unique integer token representing the start request. Do not call this method directly.参数：intent: The Intent supplied to startService(Intent), as given. This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except START_STICKY_COMPATIBILITY.flags: Additional data about this start request. Currently either 0, START_FLAG_REDELIVERY, or START_FLAG_RETRY.startId: A unique integer representing this specific request to start. Use with stopSelfResult(int).返回值：The return value indicates what semantics the system should use for the service’s current started state. It may be one of the constants associated with the START_CONTINUATION_MASK bits.总结如下，onStartCommand()是当一个service调用startService()之后由系统调用的，开发者不用直接调用这个方法，但是可以重写这个方法。方法的返回值有四个int值，分别是：START_STICKY, START_NOT_STICKY, START_REDELIVER_INTENT, or START_STICKY_COMPATIBILITY. bindService：onCreate()onBind()onUnbind()onDestroy() 4、Broadcast Receiver面试题1、Broadcast Receiver是什么Broadcast是四大组件之一，是一种广泛运用在应用程序之间传输信息的机制，通过发送Intent来传送我们的数据 2、Broadcast Receiver的使用场景同一App具有多个进程的不同组件之间的消息通信不同App之间的组件之间的消息通信 3、Broadcast Receiver的种类普通广播有序广播 Context.sendOrderedBroadcast本地广播 LocalBroadcastManager.getInstance(context).sendBroadcast(intent) 除了能解决BroadcastReceiver进程间安全性问题外，相对Context操作的BroadcastReceiver而言还具有更高的运行效率。Sticky广播 的sendStickyBroadcast(Intent)接口发送，需要添加权限也可以通过Context的removeStickyBroadcast(Intent intent)接口移除缓存的粘性广播。sticky有序广播 StickyOrderedBroadcast 4、Broadcast Receiver的实现静态注册：注册后一直运行，尽管Activity、进程、App被杀死还是可以接收到广播动态注册：跟随Activity的生命周期 5、Broadcast Receiver实现机制自定义广播类继承BroadcastReceiver，复写onReceiver()通过Binder机制向AMS进行注册广播广播发送者通过Binder机制向AMS发送广播AMS查找符合相应条件的广播发送到BroadcastReceiver相应的循环队列中消息队列执行拿到广播，回调BroadcastReceiver的onReceiver() 6、LocalBroadcastManager特点本地广播只能在自身App内传播，不必担心泄漏隐私数据本地广播不允许其他App对你的App发送该广播，不必担心安全漏洞被利用本地广播比全局广播更高效以上三点都是源于其内部是用Handler实现的 5、WebView面试题1、WebView安全漏洞API16之前存在远程代码执行安全漏洞，该漏洞源于程序没有正确限制使用WebView.addJavascriptInterface方法，远程攻击者可通过使用Java反射机制利用该漏洞执行任意Java对象的方法 2、WebView销毁步骤WebView在其他容器上时（如：LinearLayout），当销毁Activity时，需要在onDestroy()中先移除容器上的WebView，然后再将WebView.destroy()，这样就不会导致内存泄漏 3、WebView的jsbridge客户端和服务端之间可以通过Javascript来互相调用各自的方法 4、WebViewClient的onPageFinishedWebViewClient的onPageFinished在每次完成页面的时候调用，但是遇到未加载完成的页面跳转其他页面时，就会一直调用，使用WebChromeClient.onProgressChanged可以替代 5、WebView后台耗电在WebView加载页面的时候，会自动开启线程去加载，如果不很好的关闭这些线程，就会导致电量消耗加大，可以采用暴力的方法，直接在onDestroy方法中System.exit(0)结束当前正在运行中的java虚拟机 6、WebView硬件加速Android3.0引入硬件加速，默认会开启，WebView在硬件加速的情况下滑动更加平滑，性能更加好，但是会出现白块或者页面闪烁的副作用，建议WebView暂时关闭硬件加速 7、WebView内存泄漏由于WebView是依附于Activity的，Activity的生命周期和WebView启动的线程的生命周期是不一致的，这会导致WebView一直持有对这个Activity的引用而无法释放，解决方案如下独立进程，简单暴力，不过可能涉及到进程间通信（推荐）动态添加WebView，对传入WebView中使用的Context使用弱引用 6、Binder面试题1、Linux内核的基本知识 进程隔离/虚拟地址空间：进程间是不可以共享数据的，相当于被隔离，每个进程被分配到不同的虚拟地址中系统调用：Linux内核对应用有访问权限，用户只能在应用层通过系统调用，调用内核的某些程序binder驱动：它负责各个用户的进程，通过binder通信内核来进行交互的模块 而Binder，就是充当 连接 两个进程（内核空间）的通道。 2、为什么使用Binder性能上，相比传统的Socket更加高效安全性高，支持协议双方互相校验 3、Binder通信模型 虚线表示并非直接交互 说明1：Client进程、Server进程 &amp; Service Manager 进程之间的交互都必须通过Binder驱动（使用 open 和 ioctl文件操作函数），而非直接交互 原因： Client进程、Server进程 &amp; Service Manager进程属于进程空间的用户空间，不可进行进程间交互 Binder驱动 属于 进程空间的 内核空间，可进行进程间 &amp; 进程内交互 说明2： Binder驱动 &amp; Service Manager进程 属于 Android基础架构（即系统已经实现好了）；而Client 进程 和 Server 进程 属于Android应用层（需要开发者自己实现） 所以，在进行跨进程通信时，开发者只需自定义Client &amp; Server 进程 并 显式使用上述3个步骤，最终借助 Android的基本架构功能就可完成进程间通信 详细参考这篇博客：图文详解 Android Binder 跨进程通信机制原理 对比 Linux （Android基于linux）上的其他进程通信方式（管道/消息队列/共享内存/信号量/Socket），Binder 机制的优点有： 高效Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次通过驱动在内核空间拷贝数据，不需要额外的同步处理 安全性高Binder 机制为每个进程分配了 UID/PID 来作为鉴别身份的标示，并且在 Binder 通信时会根据 UID/PID 进行有效性检测传统的进程通信方式对于通信双方的身份并没有做出严格的验证如，Socket通信 ip地址是客户端手动填入，容易出现伪造 使用简单采用Client/Server 架构实现 面向对象 的调用方式，即在使用Binder时就和调用一个本地对象实例一样 4、AIDL客户端通过aidl文件的Stub.asInterface()方法，拿到Proxy代理类通过调用Proxy代理类的方法，将参数进行封包后，调用底层的transact()方法transact()方法会回调onTransact()方法，进行参数的解封在onTransact()方法中调用服务端对应的方法，并将结果返回 7、Handler面试题1、Handler是什么Handler通过发送和处理Message和Runnable对象来关联相对应线程的MessageQueue 2、Handler使用方法post(runnable)sendMessage(message) 3、Handler工作原理Android进阶——Android消息机制之Looper、Handler、MessageQueen 4、Handler引起的内存泄漏原因：非静态内部类持有外部类的匿名引用，导致Activity无法释放解决：Handler内部持有外部Activity的弱引用Handler改为静态内部类Handler.removeCallback() 8、AsyncTask面试题1、AsyncTask是什么它本质上就是一个封装了线程池和Handler的异步框架 2、AsyncTask使用方法三个参数Params：表示后台任务执行时的参数类型，该参数会传给AysncTask的 doInBackground() 方法Progress：表示后台任务的执行进度的参数类型，该参数会作为 onProgressUpdate() 方法的参数Result：表示后台任务的返回结果的参数类型，该参数会作为 onPostExecute() 方法的参数五个方法onPreExecute()：异步任务开启之前回调，在主线程中执行doInBackground()：执行异步任务，在线程池中执行onProgressUpdate()：当doInBackground中调用publishProgress时回调，在主线程中执行onPostExecute()：在异步任务执行之后回调，在主线程中执行onCancelled()：在异步任务被取消时回调 3、AsyncTask工作原理Android进阶——多线程系列之异步任务AsyncTask的使用与源码分析http://blog.csdn.net/qq_30379689/article/details/53203556 4、AsyncTask引起的内存泄漏原因：非静态内部类持有外部类的匿名引用，导致Activity无法释放解决：AsyncTask内部持有外部Activity的弱引用AsyncTask改为静态内部类AsyncTask.cancel() 5、AsyncTask生命周期在Activity销毁之前，取消AsyncTask的运行，以此来保证程序的稳定 6、AsyncTask结果丢失由于屏幕旋转、Activity在内存紧张时被回收等情况下，Activity会被重新创建，此时，旧的AsyncTask持有旧的Activity引用，这个时候会导致AsyncTask的 onPostExecute()对UI更新无效 7、AsyncTask并行or串行AsyncTask在Android 2.3之前默认采用并行执行任务，AsyncTask在Android 2.3之后默认采用串行执行任务如果需要在Android 2.3之后采用并行执行任务，可以调用AsyncTask的executeOnExecutor() 8、一个AsyncTask对象只能被执行一次，即只能调用一次execute，多次执行就报错。同一个进程里所有用到 AsyncTask 的地方都是同一个线程池，导致任务缓存队列就容易满.同一个进程里面所有AsyncTask对象都共享同一个SerialExecutor对象。 参考：https://blog.csdn.net/zhaoyangfang/article/details/76100607 在Android2.3中AsyncTask的调用可以并发执行.在一个线程池中被调用. 该线程池有5个核心线程.即一次可以并发执行5个任务在Android3.0及其以后AsyncTask的调用在默认情况同时只能有1个任务在执行.在AsyncTask中采用了SerialExecutor,线程池中只有一个线程的线程池但我们可以调用方法asyncTask.executeOnExecutor(executor, params);来设置自己的线程池实现并发。 9、HandlerThread面试题1、HandlerThread产生背景当系统有多个耗时任务需要执行时，每个任务都会开启一个新线程去执行耗时任务，这样会导致系统多次创建和销毁线程，从而影响性能。为了解决这一问题，Google提供了HandlerThread，HandlerThread是在线程中创建一个Looper循环器，让Looper轮询消息队列，当有耗时任务进入队列时，则不需要开启新线程，在原有的线程中执行耗时任务即可，否则线程阻塞 2、HanlderThread的特点、HandlerThread本质上是一个线程，继承自ThreadHandlerThread有自己的Looper对象，可以进行Looper循环，可以创建HandlerHandlerThread可以在Handler的handlerMessage中执行异步方法HandlerThread优点是异步不会堵塞，减少对性能的消耗HandlerThread缺点是不能同时继续进行多任务处理，需要等待进行处理，处理效率较低HandlerThread与线程池不同，HandlerThread是一个串行队列，背后只有一个线程。 Looper、Handler、Message三者关系转载自Android 异步消息处理机制 让你深入理解 Looper、Handler、Message三者关系 1、首先Looper.prepare()在本线程中保存一个Looper实例，然后该实例中保存一个MessageQueue对象；因为Looper.prepare()在一个线程中只能调用一次，所以MessageQueue在一个线程中只会存在一个。 2、Looper.loop()会让当前线程进入一个无限循环，不端从MessageQueue的实例中读取消息，然后回调msg.target.dispatchMessage(msg)方法。 3、Handler的构造方法，会首先得到当前线程中保存的Looper实例，进而与Looper实例中的MessageQueue想关联。 4、Handler的sendMessage方法，会给msg的target赋值为handler自身，然后加入MessageQueue中。 5、在构造Handler实例时，我们会重写handleMessage方法，也就是msg.target.dispatchMessage(msg)最终调用的方法。 好了，总结完成，大家可能还会问，那么在Activity中，我们并没有显示的调用Looper.prepare()和Looper.loop()方法，为啥Handler可以成功创建呢，这是因为在Activity的启动代码中，已经在当前UI线程调用了Looper.prepare()和Looper.loop()方法。 10、IntentService面试题1、IntentService是什么IntentService是继承自Service并处理异步请求的一个类，其内部采用HandlerThread和Handler实现的，在IntentService内有一个工作线程来处理耗时操作，其优先级比普通Service高。当任务完成后，IntentService会自动停止，而不需要手动调用stopSelf()。另外，可以多次启动IntentService，每个耗时操作都会以工作队列的方式在IntentService中 onHandlerIntent() 回调方法中执行，并且每次只会执行一个工作线程 2、IntentService使用方法创建Service继承自IntentService覆写构造方法和onHandlerIntent()方法在onHandlerIntent()中执行耗时操作 11、视图工作机制面试题Android进阶——Android视图工作机制之measure、layout、draw Android事件分发机制之dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent 12、ListView面试题1、ListView是什么ListView是能将一个数据集合以动态滚动的方式展示到用户界面上的View 2、ListView的RecycleBin机制 3、ListView的优化重用convertView使用ViewHolder图片三级缓存监听滑动事件少用透明View开启硬件加速 13、Android项目构建面试题1、android构建流程 2、jenkins持续集成构建这里可参考蒲公英文档 3、Git常用命令git init：仓库的初始化git status：查看当前仓库的状态git diff：查看仓库与上次修改的内容git add：将文件放进暂存区git commit：提交代码git clone：克隆代码git bransh：查看当前分支git checkout：切换当前分支 4、git工作流fork/clone（主流）fork：将别人的仓库代码fork到自己的仓库上clone：克隆下自己仓库的代码update、commit：修改代码并提交到自己的仓库push：提交到自己的仓库pull request：请求添加到别人的仓库clone 5、proguard是什么ProGuard工具是用于压缩、优化和混淆我们的代码，其主作用是移除或混淆代码中无用类、字段、方法和属性 6、proguard技术功能压缩优化混淆预检测 7、proguard工作原理将无用的字段或方法存入到EntryPoint中，将非EntryPoint的字段和方法进行替换 8、为什么要混淆由于Java是一门跨平台的解释性语言，其源代码被编译成class字节码来适应其他平台，而class文件包含了Java源代码信息，很容易被反编译 14、ANR面试题1、什么是ANRApplication Not Responding，页面无响应的对话框 2、发生ANR的条件应用程序的响应性是由ActivityManager和WindowManager系统服务监视的，当ANR发生条件满足时，就会弹出ANR的对话框Activity超过5秒无响应BroadcastReceiver超过10秒无响应Service超过20秒无响应 3、造成ANR的主要原因主线程被IO操作阻塞Activity的所有生命周期回调都是执行在主线程的Service默认执行在主线程中BoardcastReceiver的回调onReceive()执行在主线程中AsyncTask的回调除了doInBackground，其他都是在主线程中没有使用子线程Looper的Handler的handlerMessage，post(Runnable)都是执行在主线程中 4、如何解决ANR使用AsyncTask处理耗时IO操作使用Thread或HandlerThread提供优先级使用Handler处理工作线程的耗时操作Activity的onCreate和onResume回调尽量避免耗时操作 15、OOM面试题1、什么是OOMOOM指Out of memory（内存溢出），当前占用内存加上我们申请的内存资源超过了Dalvik虚拟机的最大内存限制就会抛出Out of memory异常 2、OOM相关概念内存溢出：指程序在申请内存时，没有足够的空间供其使用内存泄漏：指程序分配出去的内存不再使用，无法进行回收内存抖动：指程序短时间内大量创建对象，然后回收的现象 3、解决OOMBitmap相关图片压缩加载缩略图在滚动时不加载图片回收Bitmap使用inBitmap属性捕获异常其他相关listview重用convertView、使用LruCache避免onDraw方法执行对象的创建谨慎使用多进程 16、Bitmap面试题1、recycle在安卓3.0以前Bitmap是存放在堆中的，我们只要回收堆内存即可在安卓3.0以后Bitmap是存放在内存中的，我们需要回收native层和Java层的内存官方建议我们3.0以后使用recycle方法进行回收，该方法也可以不主动调用，因为垃圾回收器会自动收集不可用的Bitmap对象进行回收recycle方法会判断Bitmap在不可用的情况下，将发送指令到垃圾回收器，让其回收native层和Java层的内存，则Bitmap进入dead状态recycle方法是不可逆的，如果再次调用getPixels()等方法，则获取不到想要的结果 2、LruCache原理LruCache是个泛型类，内部采用LinkedHashMap来实现缓存机制，它提供get方法和put方法来获取缓存和添加缓存，其最重要的方法trimToSize是用来移除最少使用的缓存和使用最久的缓存，并添加最新的缓存到队列中 3、计算inSampleSizepublic static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) &#123; final int height = options.outHeight; final int width = options.outWidth; int inSampleSize = 1; if (height &gt; reqHeight || width &gt; reqWidth) &#123; if (width &gt; height) &#123; inSampleSize = Math.round((float)height / (float)reqHeight); &#125; else &#123; inSampleSize = Math.round((float)width / (float)reqWidth); &#125; &#125; return inSampleSize;&#125; 4、缩略图public static Bitmap thumbnail(String path,int maxWidth, int maxHeight, boolean autoRotate) &#123; BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; Bitmap bitmap = BitmapFactory.decodeFile(path, options); options.inJustDecodeBounds = false; int sampleSize = calculateInSampleSize(options, maxWidth, maxHeight); options.inSampleSize = sampleSize; options.inPreferredConfig = Bitmap.Config.RGB_565; options.inPurgeable = true; options.inInputShareable = true; if (bitmap != null &amp;&amp; !bitmap.isRecycled()) &#123; bitmap.recycle(); &#125; bitmap = BitmapFactory.decodeFile(path, options); return bitmap;&#125; 5、保存Bitmappublic static String save(Bitmap bitmap,Bitmap.CompressFormat format, int quality, File destFile) &#123; try &#123; FileOutputStream out = new FileOutputStream(destFile); if (bitmap.compress(format, quality, out)) &#123; out.flush(); out.close(); &#125; if (bitmap != null &amp;&amp; !bitmap.isRecycled()) &#123; bitmap.recycle(); &#125; return destFile.getAbsolutePath(); &#125; catch (FileNotFoundException e) &#123; e.printStackTrace(); &#125; catch (IOException e) &#123; e.printStackTrace(); &#125; return null;&#125; 6、保存到SD卡 public static String save(Bitmap bitmap,Bitmap.CompressFormat format, int quality, Context context) &#123; if (!Environment.getExternalStorageState() .equals(Environment.MEDIA_MOUNTED)) &#123; return null; &#125; File dir = new File(Environment.getExternalStorageDirectory() + \"/\" + context.getPackageName() + \"/save/\"); if (!dir.exists()) &#123; dir.mkdirs(); &#125; File destFile = new File(dir, UUID.randomUUID().toString()); return save(bitmap, format, quality, destFile);&#125; 7、三级缓存网络缓存本地缓存内存缓存 下面介绍了 Android 位图内存管理的演变过程： 在 Android Android 2.2（API 级别 8）及更低版本上，当发生垃圾回收时，应用的线程会停止。这会导致延迟，从而降低性能。Android 2.3 添加了并发垃圾回收功能，这意味着系统不再引用位图后，很快就会回收内存。 在 Android 2.3.3（API 级别 10）及更低版本上，位图的后备像素数据存储在本地内存中。它与存储在 Dalvik 堆中的位图本身是分开的。本地内存中的像素数据并不以可预测的方式释放，可能会导致应用短暂超出其内存限制并崩溃。 从 Android 3.0（API 级别 11）到 Android 7.1（API 级别 25），像素数据会与关联的位图一起存储在 Dalvik 堆上。 在 Android 8.0（API 级别 26）及更高版本中，位图像素数据存储在原生堆中。 更多关于bitmap位图数据存储的介绍，可以看下官方的介绍：https://developer.android.com/topic/performance/graphics/manage-memory 17、UI卡顿面试题1、UI卡顿原理View的绘制帧数保持60fps是最佳，这要求每帧的绘制时间不超过16ms（1000/60），如果安卓不能在16ms内完成界面的渲染，那么就会出现卡顿现象 2、UI卡顿的原因分析在UI线程中做轻微的耗时操作，导致UI线程卡顿布局Layout过于复杂，无法在16ms内完成渲染同一时间动画执行的次数过多，导致CPU和GPU负载过重overDraw，导致像素在同一帧的时间内被绘制多次，使CPU和GPU负载过重View频繁的触发measure、layout，导致measure、layout累计耗时过多和整个View频繁的重新渲染频繁的触发GC操作导致线程暂停，会使得安卓系统在16ms内无法完成绘制冗余资源及逻辑等导致加载和执行缓慢ANR 3、UI卡顿的优化布局优化使用include、ViewStub、merge不要出现过于嵌套和冗余的布局使用自定义View取代复杂的ViewListView优化复用convertView滑动不加载背景和图片优化缩略图图片压缩避免ANR不要在UI线程中做耗时操作 18、内存泄漏面试题1、Java内存泄漏引起的主要原因长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏 2、Java内存分配策略静态存储区：又称方法区，主要存储全局变量和静态变量，在整个程序运行期间都存在栈区：方法体的局部变量会在栈区创建空间，并在方法执行结束后会自动释放变量的空间和内存堆区：保存动态产生的数据，如：new出来的对象和数组，在不使用的时候由Java回收器自动回收 3、Android解决内存泄漏的例子单例造成的内存泄漏：在单例中，使用context.getApplicationContext()作为单例的context匿名内部类造成的内存泄漏：由于非静态内部类持有匿名外部类的引用，必须将内部类设置为staticHandler造成的内存泄漏：使用static的Handler内部类，同时在实现内部类中持有Context的弱引用避免使用static变量：由于static变量会跟Activity生命周期一致，当Activity退出后台被后台回收时，static变量是不安全，所以也要管理好static变量的生命周期资源未关闭造成的内存泄漏：比如Socket、Broadcast、Cursor、Bitmap、ListView等，使用完后要关闭AsyncTask造成的内存泄漏：由于非静态内部类持有匿名内部类的引用而造成内存泄漏，可以通过AsyncTask内部持有外部Activity的弱引用同时改为静态内部类或在onDestroy()中执行AsyncTask.cancel()进行修复 非静态内部类和非静态匿名内部类中确实都持有外部类的引用， 静态内部类中未持有外部类的引用 19、内存管理面试题1、Android内存管理机制分配机制管理机制 2、内存管理机制的特点更少的占用内存在合适的时候，合理的释放系统资源在系统内存紧张的时候，能释放掉大部分不重要的资源能合理的在特殊生命周期中，保存或还原重要数据 3、内存优化方法Service完成任务后应停止它，或用IntentService（因为可以自动停止服务）代替Service在UI不可见的时候，释放其UI资源在系统内存紧张的时候，尽可能多的释放非重要资源避免滥用Bitmap导致内存浪费避免使用依赖注入框架使用针对内存优化过的数据容器使用ZIP对齐的APK使用多进程 20、冷启动和热启动面试题1、什么是冷启动和热启动冷启动：在启动应用前，系统中没有该应用的任何进程信息热启动：在启动应用时，在已有的进程上启动应用（用户使用返回键退出应用，然后马上又重新启动应用） 2、冷启动和热启动的区别冷启动：创建Application后再创建和初始化MainActivity热启动：创建和初始化MainActivity即可 3、冷启动时间的计算这个时间值从应用启动（创建进程）开始计算，到完成视图的第一次绘制为止 4、冷启动流程Zygote进程中fork创建出一个新的进程创建和初始化Application类、创建MainActivityinflate布局、当onCreate/onStart/onResume方法都走完contentView的measure/layout/draw显示在界面上总结：Application构造方法-&gt;attachBaseContext()-&gt;onCreate()-&gt;Activity构造方法-&gt;onCreate()-&gt;配置主题中背景等属性-&gt;onStart()-&gt;onResume()-&gt;测量布局绘制显示在界面上 5、冷启动优化减少第一个界面onCreate()方法的工作量不要让Application参与业务的操作不要在Application进行耗时操作不要以静态变量的方式在Application中保存数据减少布局的复杂性和深度不要在mainThread中加载资源通过懒加载方式初始化第三方SDK 21、其他优化面试题1、Android不用静态变量存储数据静态变量等数据由于进程已经被杀死而被初始化使用其他数据传输方式：文件/sp/contentProvider 2、SharePreference安全问题不能跨进程同步文件不宜过大 3、内存对象序列化Serializeble：是java的序列化方式，Serializeble在序列化的时候会产生大量的临时对象，从而引起频繁的GCParcelable：是Android的序列化方式，且性能比Serializeble高，Parcelable不能使用在要将数据存储在硬盘上的情况 4、避免在UI线程中做繁重的操作 22、架构模式面试题Android基础——框架模式MVC在安卓中的实践http://blog.csdn.net/qq_30379689/article/details/52909656Android基础——框架模式MVP在安卓中的实践http://blog.csdn.net/qq_30379689/article/details/52910567Android基础——框架模式MVVM之DataBinding的实践http://blog.csdn.net/qq_30379689/article/details/53037430 Android App的设计架构：MVC,MVP,MVVM与架构经验谈https://www.tianmaying.com/tutorial/AndroidMVC 23、插件化面试题1、插件化解决的问题动态加载APK（反射、类加载器）资源加载（反射、AssetManager、独立资源、分段资源）代码加载（反射获取生命周期） 2、类加载器（Java中字节码添加到虚拟机中）DexClassLoader：能够加载未安装的jar/apk/dex，主要用于动态加载和代码热更新PathClassLoader：只能加载系统中已经安装过的apk 24、热更新面试题1、热更新主要流程线上检查到Crash拉出Bugfix分支修复Crash问题jenkins构建和补丁生成app通过推送或主动拉取补丁文件将Bugfix代码合到master上 2、热更新主流框架DexposedAndFixNuwaTinker 3、热更新的原理在ClassLoader创建一个dexElements数组将修复好的dex文件存放在dexElements数组的最前面ClassLoader会遍历dexElements数组，找到最前面的dex文件优先加载 25、进程保活面试题1、进程的优先级空进程后台进程服务进程可见进程前台进程 2、Android进程回收策略Low memory Killer（定时执行）：通过一些比较复杂的评分机制，对进程进行打分，然后将分数高的进程判定为bad进程，杀死并释放内存OOM_ODJ：判别进程的优先级 3、Android保活方案利用系统广播拉活利用系统Service机制拉活利用Native进程拉活利用JobScheduler机制拉活利用账号同步机制拉活 26、Lint面试题1、什么是Android LintAndroid Lint是一个静态代码分析工具，它能够对你的Android项目中潜在的Bug、可优化的代码、安全性、性能、可用性、可访问性、国际化等进行检查 2、Lint工作流程 3、配置Lint创建Lint.xml到根目录下，自定义Lint安全等级等在Java文件中可以使用@suppressLint(“NewApi”)来忽视Lint的报错在xml文件中可以使用tool:ignore(“UnusedResources”)来忽视Lint的报错自定义Lint检查，可以创建类，继承Detector和实现JavaPsiScanner 27、Kotlin面试题1、什么是KotlinKotlin是一种基于JVM的编程语言对Java的一种拓展，比Java更简洁Kotlin支持函数式编程Kotlin类和Java类可以相互调用 2、Kotlin环境搭建直接在Plugin中下载Kotlin插件即可系统会自动配置到Kotlin环境 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/08/17/IntervieweeQuestions/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"},{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"}]},{"title":"Activity启动流程分析","slug":"activity-start-process","date":"2017-08-01T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/08/02/activity-start-process/","link":"","permalink":"http://agehua.github.io/2017/08/02/activity-start-process/","excerpt":"Activity启动流程分析本文主要介绍Activity的启动过程和过程中主要涉及的类。如果你跟随上一篇文章，成功编译了Android源码，可以动手跟本篇文章一步一步调试分析整个启动过程。没有编译源码，也可以看看android.googlesource，这里也有源码。\n主要对象功能介绍zygote进程和SystemServer进程android是基于Linux系统的，而在linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote 进程也不例外。\n\n每一个App其实都是\n\n一个单独的dalvik虚拟机\n一个单独的进程\n\n\nAndroid系统开启新进程的方式，是通过fork第一个zygote 进程实现的。所以说，除了第一个zygote进程，其他应用所在的进程都是zygote的子进程。","text":"Activity启动流程分析本文主要介绍Activity的启动过程和过程中主要涉及的类。如果你跟随上一篇文章，成功编译了Android源码，可以动手跟本篇文章一步一步调试分析整个启动过程。没有编译源码，也可以看看android.googlesource，这里也有源码。 主要对象功能介绍zygote进程和SystemServer进程android是基于Linux系统的，而在linux中，所有的进程都是由init进程直接或者是间接fork出来的，zygote 进程也不例外。 每一个App其实都是 一个单独的dalvik虚拟机 一个单独的进程 Android系统开启新进程的方式，是通过fork第一个zygote 进程实现的。所以说，除了第一个zygote进程，其他应用所在的进程都是zygote的子进程。 SystemServer 也是一个进程，而且是由zygote进程fork出来的。为什么说SystemServer非常重要呢？因为系统里面重要的服务都是在这个进程里面开启的，比如ActivityManagerService、PackageManagerService、WindowManagerService等等。 我们的App和AMS(SystemServer进程)还有zygote进程分属于三个独立的进程，他们之间如何通信呢？App与AMS通过Binder进行IPC通信，AMS(SystemServer进程)与zygote通过Socket进行IPC通信。 与Activity启动有关的类我们下面的文章将围绕着这几个类进行介绍。可能你第一次看的时候，印象不深，不过没关系，当你跟随者我读完这篇文章的时候，相信那时候你会对这些类更加的熟悉和深刻。 ActivityManagerServices，简称AMS，服务端对象，负责系统中所有Activity的生命周期，查看源码，点击这里 ActivityThread，App的真正入口。当开启App之后，会调用main()开始运行，开启消息循环队列，这就是传说中的UI线程或者叫主线程。与ActivityManagerServices配合，一起完成Activity的管理工作 ApplicationThread，用来实现ActivityManagerService与ActivityThread之间的交互。在ActivityManagerService需要管理相关Application中的Activity的生命周期时，通过ApplicationThread的代理对象与ActivityThread通讯。 ApplicationThreadProxy，是ApplicationThread在服务器端的代理，负责和客户端的ApplicationThread通讯。AMS就是通过该代理与ActivityThread进行通信的。 Instrumentation，每一个应用程序只有一个Instrumentation对象，每个Activity内都有一个对该对象的引用。Instrumentation可以理解为应用进程的管家，ActivityThread要创建或暂停某个Activity时，都需要通过Instrumentation来进行具体的操作。 ActivityStack，Activity在AMS的栈管理，用来记录已经启动的Activity的先后关系，状态信息等。通过ActivityStack决定是否需要启动新的进程。 ActivityRecord，ActivityStack的管理对象，每个Activity在AMS对应一个ActivityRecord，来记录Activity的状态以及其他的管理信息，比如在哪进程中ProcessState，当前的状态CurentState等。其实就是服务器端的Activity对象的映像。 TaskRecord，AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。如果你清楚Activity的4种launchMode，那么对这个概念应该不陌生。 ProcessRecord，这个类记录的是一个进程中的信息，因为一个应用中可能会包含多个进程。 App程序的入口我们一般在启动Activity的时候都是使用系统提供的方法Activity.startActivity()操作的，本文就在此方法上分析整个过程: 这里我的app进程是：foo.bar.multi，后面深入源码后会在系统进程system_process和app进程之间切换。 @Overridepublic void startActivity(Intent intent) &#123; this.startActivity(intent, null);&#125;@Overridepublic void startActivity(Intent intent, @Nullable Bundle options) &#123; if (options != null) &#123; //options这里为null startActivityForResult(intent, -1, options); &#125; else &#123; // Note we want to go through this call for compatibility with // applications that may have overridden the method. startActivityForResult(intent, -1); &#125;&#125;public void startActivityForResult(@RequiresPermission Intent intent, int requestCode, @Nullable Bundle options) &#123; if (mParent == null) &#123; //这里mParent不为空 options = transferSpringboardActivityOptions(options); Instrumentation.ActivityResult ar = mInstrumentation.execStartActivity( this, mMainThread.getApplicationThread(), mToken, this, intent, requestCode, options); if (ar != null) &#123; mMainThread.sendActivityResult( mToken, mEmbeddedID, requestCode, ar.getResultCode(), ar.getResultData()); &#125; // 代码省略.... &#125; else &#123; // 代码省略.... &#125;&#125; 上面代码可以看到，这里用到了mMainThread变量去执行的操作，再看看这个变量，它是ActivityThread的一个实例。ActivityThread是一个应用非常关键的一个类，首先它是一个应用的主线程，其次就是他才是一个程序的入口（main方法）的地方： public static void main(String[] args) &#123; //...代码省略&#125; 没有Android源码的，可以看这里：android.googlesource。后面介绍这个入口main方法什么时候执行。 上面的mInstrumentation对象，是在Activity的attach()方法中被赋值的 Instrumentation是什么？和ActivityThread是什么关系？接着说上面的mInstrumentation.execStartActivity()方法，有三个同名的重载方法：public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options)public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, String target, Intent intent, int requestCode, Bundle options)public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options, UserHandle user) 考验眼力的时候到了，仔细看下，上面的mInstrumentation.execStartActivity()调用的其实是第一个重载方法：public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) &#123; IApplicationThread whoThread = (IApplicationThread) contextThread; //...ignore some code... try &#123; intent.migrateExtraStreamToClipData(); intent.prepareToLeaveProcess(); int result = ActivityManagerNative.getDefault() .startActivity(whoThread, who.getBasePackageName(), intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null ? target.mEmbeddedID : null, requestCode, 0, null, options); checkStartActivityResult(result, intent); &#125; catch (RemoteException e) &#123; &#125; return null;&#125; 可以看到execStartActivity()方法，调用了ActivityManagerNative的startActivity()方法，看到这个ActivityManagerNative类有没有感觉和之前一篇文章，Android Binder机制分析（二）里的ServiceManagerNative有点类似，这里涉及到的是系统服务间的Binder机制，不了解的同学可以看看这篇文章。 稍后分析ActivityManagerNative，这里简单介绍下Instrumentation类。 Instrumentation意为“仪器”。每个Activity都持有Instrumentation对象的一个引用，但是整个进程只会存在一个Instrumentation对象。 Instrumentation这个类里面的方法大多数和Application和Activity有关，可以说是对Application和Activity初始化和生命周期的工具类。 举个例子，callActivityOnCreate()public void callActivityOnCreate(Activity activity, Bundle icicle) &#123; prePerformCreate(activity); activity.performCreate(icicle); postPerformCreate(activity);&#125; 对activity.performCreate(icicle);这一行代码熟悉吗？这一行里面就调用了传说中的Activity的入口函数onCreate()，不信？接着往下看Activity.performCreate()final void performCreate(Bundle icicle) &#123; onCreate(icicle); mActivityTransitionState.readState(icicle); performCreateCommon();&#125; 确实，onCreate在这里调用了。但是有一件事情必须说清楚，那就是这个Instrumentation类这么重要，为啥我在开发的过程中，没有发现他的踪迹呢？ 是的，Instrumentation这个类很重要，对Activity生命周期方法的调用根本就离不开他，但他只负责Activity的内部管理。外部想调整Activity的状态，必须通过ActivityThread。 ActivityThread你都没听说过？那你肯定听说过传说中的UI线程吧？是的，这就是UI线程。我们前面说过，App和AMS是通过Binder传递信息的，那么ActivityThread就是专门与AMS的外交工作的。Instrumentation相当于老板娘，处理家务，很少露面。ActivityThread是老板，处理对外事务。 所以说，AMS是董事会，负责指挥和调度的，ActivityThread是老板，虽然说家里的事自己说了算，但是需要听从AMS的指挥，而Instrumentation则是老板娘，负责家里的大事小事，但是一般不抛头露面，听一家之主ActivityThread的安排。 简介AMS和ActivityThread之间的Binder通信前面的两篇文章：Android Binder机制分析（一）和Android Binder机制分析（二）。已经介绍了Android都是通过Binder机制调用远程的系统服务。这里在介绍下ActivityThread（App进程）是如何调用AMS服务的。 前面我们说到，在调用Activity.startActivity()的时候，实际上调用的是：mInstrumentation.execStartActivity()这个方法里面调用的是：ActivityManagerNative.getDefault().startActivity() 用鼠标定位一下，上面的startActivity()方法，会发现这个方法是IActivityManager接口里的方法。注意IActivityManager继承了IInterface接口，而这个接口就是AIDL接口类必须实现的接口。 再看，ActivityManagerNative.getDefault()返回的就是ActivityManagerService的远程接口的本地代理，即ActivityManagerProxy。public abstract class ActivityManagerNative extends Binder implements IActivityManager&#123; //从类声明上，我们可以看到ActivityManagerNative是Binder的一个子类，而且实现了IActivityManager接口 static public IActivityManager getDefault() &#123; return gDefault.get(); &#125;//最终返回的还是一个ActivityManagerProxy对象static public IActivityManager asInterface(IBinder obj) &#123; if (obj == null) &#123; return null; &#125; IActivityManager in = (IActivityManager)obj.queryLocalInterface(descriptor); if (in != null) &#123; return in; &#125; //这里面的Binder类型的obj参数会作为ActivityManagerProxy的成员变量保存为mRemote成员变量，负责进行IPC通信 return new ActivityManagerProxy(obj); &#125;&#125; 其实ActivityManagerNative类就是远端服务的中间者Stub类，其实名字不叫Stub罢了，以后其实只要看到是继承了Binder类和实现了AIDL接口类型的就是Stub类，不要关心类名了。看到他的asInterface方法的时候也是和之前的其他系统服务都是类似的。//通过单例模式获取一个IActivityManager对象，这个对象通过asInterface(b)获得private static final Singleton&lt;IActivityManager&gt; gDefault = new Singleton&lt;IActivityManager&gt;() &#123; protected IActivityManager create() &#123; IBinder b = ServiceManager.getService(\"activity\"); if (false) &#123; Log.v(\"ActivityManager\", \"default service binder = \" + b); &#125; IActivityManager am = asInterface(b); if (false) &#123; Log.v(\"ActivityManager\", \"default service = \" + am); &#125; return am; &#125; &#125;;&#125; 在这里可以看到了，其实gDefalut借助Singleton实现的单例模式，而在内部可以看到先从ServiceManager中获取到AMS远端服务的Binder对象，然后使用asInterface方法转化成本地化对象（其实就是ActivityManagerProxy对象，这个对象是ActivityManagerNative的内部类）。然后我们在看看上面调用了startActivity方法，其实就是调用了ActivityManagerProxy对象的这个方法。 在这里面做的事情就是IPC通信，利用Binder对象，调用transact()，把所有需要的参数封装成Parcel对象，向AMS发送数据进行通信。 这个方法中添加一个断点，注意这里startActivity()是ActivityManagerProxy类的方法，这里的进程应该还是App进程：foo.bar.multi public int startActivity(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle options) throws RemoteException &#123; Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IActivityManager.descriptor); data.writeStrongBinder(caller != null ? caller.asBinder() : null); data.writeString(callingPackage); intent.writeToParcel(data, 0); //...省略部分代码 mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0); reply.readException(); int result = reply.readInt(); reply.recycle(); data.recycle(); return result;&#125; 注意，这里先别放开断点 Binder本质上只是一种底层通信方式，和具体服务没有关系。为了提供具体服务，Server必须提供一套接口函数以便Client通过远程访问使用各种服务。这时通常采用Proxy设计模式：将接口函数定义在一个抽象类中，Server和Client都会以该抽象类为基类实现所有接口函数，所不同的是Server端是真正的功能实现，而Client端是对这些函数远程调用请求的包装。 客户端：ActivityManagerProxy =====&gt;Binder驱动=====&gt; ActivityManagerService：服务器 Binder只能传递数据，并不知道是要调用ActivityManagerServices的哪个方法，所以在数据中会添加方法的唯一标识码，比如前面的startActivity()方法中的标识：START_ACTIVITY_TRANSACTION。 在远端服务调用了transact()方法后，即mRemote.transact()，会转接到远端服务中间者ActivityManagerNative的onTransact方法中，找到对应的标识码： 注意这里的接收者ActivityManagerNative的onTransact方法是在system_process进程中，想要继续debug调试的的话，需要在monitor中选中这个进程，然后再在下面的方法中添加断点。最后放开上面添加的断点。 @Overridepublic boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException &#123; switch (code) &#123; case START_ACTIVITY_TRANSACTION: &#123; //最好在case方法里面添加断点，避免受其他系统发送的消息影响 data.enforceInterface(IActivityManager.descriptor); IBinder b = data.readStrongBinder(); IApplicationThread app = ApplicationThreadNative.asInterface(b); String callingPackage = data.readString(); Intent intent = Intent.CREATOR.createFromParcel(data); String resolvedType = data.readString(); IBinder resultTo = data.readStrongBinder(); String resultWho = data.readString(); int requestCode = data.readInt(); int startFlags = data.readInt(); ProfilerInfo profilerInfo = data.readInt() != 0 ? ProfilerInfo.CREATOR.createFromParcel(data) : null; Bundle options = data.readInt() != 0 ? Bundle.CREATOR.createFromParcel(data) : null; int result = startActivity(app, callingPackage, intent, resolvedType, resultTo, resultWho, requestCode, startFlags, profilerInfo, options); reply.writeNoException(); reply.writeInt(result); return true; &#125; //...省略&#125; 这里的startActivity方法，是在IActivityManager接口中定义的，跟ActivityManagerProxy没有关系了，是由远端服务来实现的，这里我们可以猜想应该是叫做ActivityManagerService中，这个类的源代码可以在android.googlesource里找到： 这个类里有三个重载的startActivity()方法，仔细看，对应的应该是第三个方法：final int startActivity(Intent intent, ActivityStackSupervisor.ActivityContainer container)@Overridepublic int startActivity(IBinder whoThread, String callingPackage, Intent intent, String resolvedType, Bundle bOptions)@Overridepublic final int startActivity(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) 这个方法直接调用了startActivityAsUser()方法@Overridepublic final int startActivityAsUser(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) &#123; enforceNotIsolatedCaller(\"startActivity\"); userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(), userId, false, ALLOW_FULL_ONLY, \"startActivity\", null); // TODO: Switch to user app stacks here. return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent, resolvedType, null, null, resultTo, resultWho, requestCode, startFlags, profilerInfo, null, null, bOptions, false, userId, null, null);&#125; 这里的mActivityStarter是在ActivityManagerService创建的时候初始化的。public ActivityManagerService(Context systemContext) &#123; //...省略代码 mStackSupervisor = new ActivityStackSupervisor(this); mActivityStarter = new ActivityStarter(this, mStackSupervisor); //...省略代码&#125; 下面就是ActiviStarter、ActivityStack和ActivityStackSupervisor三个类之间方法调来调去了，这里为了节省篇幅就不再贴代码了，有毅力的同学可以每个方法都打上一个断点，走一遍： ActivityStarter.startActivityMayWait()-&gt; ActivityStarter.startActivityLocked()-&gt; ActivityStarter.startActivityUnchecked()-&gt; ActivityStackSupervisor.resumeFocusedStackTopActivityLocked() 再往后都是ActivityStackSupervisor类的方法，调用： 从resumeFocusedStackTopActivityLocked()-&gt; resumeFocusedStackTopActivityLocked()-&gt; resumeTopActivityUncheckedLocked()-&gt; resumeTopActivityInnerLocked()-&gt; startSpecificActivityLocked()-&gt; realStartActivityLocked() IApplicationThread接口简介重点在最后的方法里realStartActivityLocked()调用了，app.thread.scheduleLaunchActivity()方法final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app, boolean andResume, boolean checkConfig) throws RemoteException &#123; //...代码省略 final ActivityStack stack = task.stack; try &#123; //...代码省略 app.forceProcessStateUpTo(mService.mTopProcessState); app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken, System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration), new Configuration(task.mOverrideConfig), r.compat, r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle, r.persistentState, results, newIntents, !andResume, mService.isNextTransitionForward(), profilerInfo); //...代码省略 &#125; catch (RemoteException e) &#123; &#125; return true;&#125; scheduleLaunchActivity()方法是IApplicationThread接口里面的方法，但是是由那个类实现的呢，这里就需要猜了，哈哈 下面几个类都实现了相同的接口IApplicationThread：private class ApplicationThread extends ApplicationThreadNative &#123;&#125;public abstract class ApplicationThreadNative extends Binder implements IApplicationThread&#123;&#125;class ApplicationThreadProxy implements IApplicationThread &#123;&#125;public interface IApplicationThread extends IInterface &#123;&#125; IApplicationThread的源码在这里：android.googlesource IApplicationThread是实现了IInterface接口的，说明也是用的Binder远程通讯，这里的当前进程是system_process，本地代理类应该是ApplicationThreadProxy类，而这个类是内部类，在ApplicationThreadNative类中 来看ApplicationThreadProxy类的scheduleLaunchActivity()方法：public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident, ActivityInfo info, Configuration curConfig, Configuration overrideConfig, CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor, int procState, Bundle state, PersistableBundle persistentState, List&lt;ResultInfo&gt; pendingResults, List&lt;ReferrerIntent&gt; pendingNewIntents, boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) throws RemoteException &#123; Parcel data = Parcel.obtain(); data.writeInterfaceToken(IApplicationThread.descriptor); //....写入数据 mRemote.transact(SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION, data, null, IBinder.FLAG_ONEWAY); data.recycle();&#125; 记住这个标识，SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION，在ApplicationThreadNative类的onTransact()方法里找： 这里注意，调用完mRemote.transact()方法，回调的onTransact()方法已经不再system_process进程中了，而是到了App进程：foo.bar.multi //onTransact()方法里：case SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION: &#123; data.enforceInterface(IApplicationThread.descriptor); // 取出数据 scheduleLaunchActivity(intent, b, ident, info, curConfig, overrideConfig, compatInfo, referrer, voiceInteractor, procState, state, persistentState, ri, pi, notResumed, isForward, profilerInfo); return true; &#125; 取出各种数据，在调用scheduleLaunchActivity()方法。 这里的cheduleLaunchActivity()在哪里实现？感觉应该在ApplicationThreadService类里。但是并没有这个类。其实应该是ApplicationThread类，不叫XXXService了，这个类实现了ApplicationThreadNative接口，同时它是ActivityThread的内部类 到这里总结下IApplicationThread接口的Binder机制： 客户端：ApplicationThread &lt;=====Binder驱动&lt;===== ApplicationThreadProxy：服务器对比之前的IActivityManager：客户端：ActivityManagerProxy =====&gt;Binder驱动=====&gt; ActivityManagerService：服务器有没有发现Binder只能单向传递。 这两次的Binder通信如下图所示： 再来看ApplicationThread类的scheduleLaunchActivity()方法// we use token to identify this activity without having to send the// activity itself back to the activity manager. (matters more with ipc)@Overridepublic final void scheduleLaunchActivity(Intent intent, IBinder token, int ident, ActivityInfo info, Configuration curConfig, Configuration overrideConfig, CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor, int procState, Bundle state, PersistableBundle persistentState, List&lt;ResultInfo&gt; pendingResults, List&lt;ReferrerIntent&gt; pendingNewIntents, boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) &#123; updateProcessState(procState, false); ActivityClientRecord r = new ActivityClientRecord(); r.token = token; r.ident = ident; r.intent = intent; r.referrer = referrer; r.voiceInteractor = voiceInteractor; r.activityInfo = info; r.compatInfo = compatInfo; r.state = state; r.persistentState = persistentState; r.pendingResults = pendingResults; r.pendingIntents = pendingNewIntents; r.startsNotResumed = notResumed; r.isForward = isForward; r.profilerInfo = profilerInfo; r.overrideConfig = overrideConfig; updatePendingConfiguration(curConfig); sendMessage(H.LAUNCH_ACTIVITY, r);&#125; 在继续看接收消息的地方，在H类里（H类继承了Handler），public void handleMessage(Message msg) &#123; if (DEBUG_MESSAGES) Slog.v(TAG, \"&gt;&gt;&gt; handling: \" + codeToString(msg.what)); switch (msg.what) &#123; case LAUNCH_ACTIVITY: &#123; Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, \"activityStart\"); final ActivityClientRecord r = (ActivityClientRecord) msg.obj; r.packageInfo = getPackageInfoNoCheck( r.activityInfo.applicationInfo, r.compatInfo); handleLaunchActivity(r, null, \"LAUNCH_ACTIVITY\"); Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); &#125; break; //.... handleLaunchActivity()-&gt;performLaunchActivity()。 performLaunchActivity()通过ClassLoader导入相应的Activity类，然后把它启动起来，注意看代码里的注释。Activity activity = null;try &#123; //通过ClassLoader将foo.bar.multi.XXXActivity类加载进来： java.lang.ClassLoader cl = r.packageInfo.getClassLoader(); activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); StrictMode.incrementExpectedActivityCount(activity.getClass()); r.intent.setExtrasClassLoader(cl); r.intent.prepareToEnterProcess(); if (r.state != null) &#123; r.state.setClassLoader(cl); &#125;&#125; catch (Exception e) &#123; if (!mInstrumentation.onException(activity, e)) &#123; throw new RuntimeException( \"Unable to instantiate activity \" + component + \": \" + e.toString(), e);try &#123; //创建Application对象，这是根据AndroidManifest.xml配置文件中的Application标签的信息来创建的 Application app = r.packageInfo.makeApplication(false, mInstrumentation); //代码主要创建Activity的上下文信息，并通过attach方法将这些上下文信息设置到XXXActivity中去： if (activity != null) &#123; activity.attach(appContext, this, getInstrumentation(), r.token, r.ident, app, r.intent, r.activityInfo, title, r.parent, r.embeddedID, r.lastNonConfigurationInstances, config, r.referrer, r.voiceInteractor, window); //调用activity的onCreate函数，上面提到过这个方法： mInstrumentation.callActivityOnCreate(activity, r.state); 无论是通过点击应用程序图标来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都要借助于应用程序框架层的ActivityManagerService服务进程。在Android应用程序框架层中，ActivityManagerService是一个非常重要的接口，它不但负责启动Activity和Service，还负责管理Activity和Service。 Android应用程序框架层中的ActivityManagerService启动Activity的过程大致如下图所示： 在这个图中，ActivityManagerService和ActivityStack位于同一个进程中，而ApplicationThread和ActivityThread位于另一个进程中。其中，ActivityManagerService是负责管理Activity的生命周期的，ActivityManagerService还借助ActivityStack是来把所有的Activity按照后进先出的顺序放在一个堆栈中；对于每一个应用程序来说，都有一个ActivityThread来表示应用程序的主进程，而每一个ActivityThread都包含有一个ApplicationThread实例，它是一个Binder对象，负责和其它进程进行通信。 下面简要总结一下启动的过程： Step 1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口； Step 2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息； Step 3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了； Step 4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity； Step 5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动； Step 6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作； Step 7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。 补充，通过Launcher启动ActivityAndroid的Launcher本身也是一个应用程序，点击应用图标，调用的方法还是Activity.startActivity()。与之前分析的不同之处是在ActivityStackSupervisor.startSpecificActivityLocked()方法中：void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) &#123; // Is this activity's application already running? ProcessRecord app = mService.getProcessRecordLocked(r.processName, r.info.applicationInfo.uid, true); r.task.stack.setLaunchTime(r); //区别在这里，Launcher启动方式，app为null，应用内启动app不为null if (app != null &amp;&amp; app.thread != null) &#123; try &#123; if ((r.info.flags&amp;ActivityInfo.FLAG_MULTIPROCESS) == 0 || !\"android\".equals(r.info.packageName)) &#123; // Don't add this if it is a platform component that is marked // to run in multiple processes, because this is actually // part of the framework so doesn't make sense to track as a // separate apk in the process. app.addPackage(r.info.packageName, r.info.applicationInfo.versionCode, mService.mProcessStats); &#125; realStartActivityLocked(r, app, andResume, checkConfig); return; &#125; catch (RemoteException e) &#123; Slog.w(TAG, \"Exception when starting activity \" + r.intent.getComponent().flattenToShortString(), e); &#125; // If a dead object exception was thrown -- fall through to // restart the application. &#125; //所以要执行ActivityServiceManager的去开启一个新的进程 mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0, \"activity\", r.intent.getComponent(), false, false, true);&#125; 每一个应用程序都有自己的uid，uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。当然，我们可以配置两个应用程序具有相同的uid和package，或者在AndroidManifest.xml 配置文件的application标签或者activity标签中显式指定相同的process属性值，这样，不同的Activity可以运行在不同的进程中。 mService.startProcessLocked()方法最终会调用到下面的代码去开启新的进程Process.ProcessStartResult startResult = Process.start(entryPoint, app.processName, uid, uid, gids, debugFlags, mountExternal, app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet, app.info.dataDir, entryPointArgs); 新的进程会导入android.app.ActivityThread 类，并且执行它的main方法，这个main方法其实就是一个应用进程的入口方法。这就是为什么我们前面说每一个应用程序都有一个ActivityThread实例来对应的原因。 在main方法中，调用了自身的attach方法，在attach方法中：private void attach(boolean system) &#123; //... final IActivityManager mgr = ActivityManagerNative.getDefault(); try &#123; mgr.attachApplication(mAppThread); &#125; catch (RemoteException ex) &#123; throw ex.rethrowFromSystemServer(); &#125; //...&#125; 在ActivityManagerService的attachApplication()方法中又调用了ttachApplicationLocked()方法：private final boolean attachApplicationLocked(IApplicationThread thread, int pid) &#123; //...代码省略 // See if the top visible activity is waiting to run in this process... if (normalMode) &#123; try &#123; if (mStackSupervisor.attachApplicationLocked(app)) &#123; didSomething = true; &#125; &#125; catch (Exception e) &#123; Slog.wtf(TAG, \"Exception thrown launching activities in \" + app, e); badApp = true; &#125; &#125; // Find any services that should be running in this process... if (!badApp) &#123; try &#123; didSomething |= mServices.attachApplicationLocked(app, processName); &#125; catch (Exception e) &#123; Slog.wtf(TAG, \"Exception thrown starting services in \" + app, e); badApp = true; &#125; &#125; // Check if a next-broadcast receiver is in this process... if (!badApp &amp;&amp; isPendingBroadcastProcessLocked(pid)) &#123; try &#123; didSomething |= sendPendingBroadcastsLocked(app); &#125; catch (Exception e) &#123; // If the app died trying to launch the receiver we declare it 'bad' Slog.wtf(TAG, \"Exception thrown dispatching broadcasts in \" + app, e); badApp = true; &#125; &#125; //...代码省略 这个方法中最终调用了ActivityStackSupervisor类的attachApplicationLocked()方法，而attachApplicationLocked()方法又调用了realStartActivityLocked()方法。 后面的过程就基本与普通Activity启动模式一样了。 参考资料Android源码分析-Activity的启动过程 罗老师的，Android应用程序的Activity启动过程简要介绍和学习计划和 Android应用程序启动过程源代码分析 【凯子哥带你学Framework】Activity启动过程全解析 Android系统篇之—-解读AMS远端服务调用机制以及Activity的启动流程 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/08/02/activity-start-process/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"},{"name":"AOSP","slug":"aosp","permalink":"http://agehua.github.io/tags/aosp/"},{"name":"AMS","slug":"ams","permalink":"http://agehua.github.io/tags/ams/"}]},{"title":"Mac下Android源码编译（AOSP）","slug":"aosp-compile","date":"2017-07-31T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/08/01/aosp-compile/","link":"","permalink":"http://agehua.github.io/2017/08/01/aosp-compile/","excerpt":"Mac下源码编译作为一名安卓开发人员，有能力阅读Android源码，是向高手进阶的重要一步。本文介绍在Mac系统下，进行Android源码编译需要的操作。\n编译需要的步骤android源码编译的四个流程: 1.搭建编译环境; 2.源码下载; 3.编译源码; 4运行.下文也将按照该流程讲述.\n搭建编译环境使用本地工作环境来编译 Android 源文件，需要使用 Linux 或 Mac OS。目前不支持在 Windows 环境下进行编译。","text":"Mac下源码编译作为一名安卓开发人员，有能力阅读Android源码，是向高手进阶的重要一步。本文介绍在Mac系统下，进行Android源码编译需要的操作。 编译需要的步骤android源码编译的四个流程: 1.搭建编译环境; 2.源码下载; 3.编译源码; 4运行.下文也将按照该流程讲述. 搭建编译环境使用本地工作环境来编译 Android 源文件，需要使用 Linux 或 Mac OS。目前不支持在 Windows 环境下进行编译。 系统要求和JDK要求等，参考Google源码编译要求 设置Mac OS编译环境在默认安装过程中，Mac OS 会在一个保留大小写但不区分大小写的文件系统中运行。Git 并不支持此类文件系统。因此，我们建议您始终在区分大小写的文件系统中对 AOSP 源文件进行操作。使用下文中介绍的磁盘映像可以非常轻松地做到这一点。 创建区分大小写的磁盘映像通过 shell 使用以下命令创建磁盘映像：hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg 如果您以后需要更大的存储卷，还可以使用以下命令来调整稀疏映像的大小：hdiutil resize -size 100g ~/android.dmg.sparseimage 我编译的是7.1.1版本的系统源码，狠心之下给了100G空间 对于存储在主目录下的名为 android.dmg 的磁盘映像，您可以向 ~/.bash_profile 中添加辅助函数： # mount the android file imagefunction mountAndroid &#123; hdiutil attach ~/android.dmg -mountpoint /Volumes/android; &#125;# unmount the android file imagefunction umountAndroid() &#123; hdiutil detach /Volumes/android; &#125; 1.要在执行 mountAndroid 时装载磁盘映像 2.要在执行 umountAndroid 时卸载磁盘映像 注意：如果系统创建的是 .dmg.sparseimage 文件，请将 ~/android.dmg 替换成 ~/android.dmg.sparseimage。 装载 android 存储卷后，您将在其中开展所有工作。您可以像对待外接式存储盘一样将其弹出（卸载）。 Android源码下载Android源码的下载要使用到repo工具，这部分主要参考了下面两篇文章：CSDN——自己动手编译最新Android源码及SDKSource-Android——谷歌下载源代码 repo工具下载及安装repo工具负责下载AOSP源码，总结来说，repo就是这么一种工具，由一系列python脚本组成，通过调用Git命令实现对AOSP项目的管理. 在命令行工具里，依次执行下面的命令，实现repo工具的下载和安装mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo &gt; ~/bin/repochmod a+x ~/bin/repo 关于repo工具和AOSP项目的组织方式，感兴趣的看上面的那篇CSDN博客 curl是一个利用URL规则在命令行下工作的文件传输工具，可以说是一款很强大的http命令行工具。它支持文件的上传和下载，是综合传输工具，但按传统，习惯称curl为下载工具。 创建源码目录在上面创建好的磁盘映像里，创建一个目录，用来存放repo工具下载下来的代码。后面编译出的产物也都放在这里。mkdir sourcecd source 初始化仓库我们将上面的source文件夹作为仓库，现在需要来初始化这个仓库了。通过执行初始化仓库命令可以获取AOSP项目master上最新的代码并初始化该仓库，命令如下（需要特殊的翻墙技巧）: repo init -u https://android.googlesource.com/platform/manifest 如果执行上面的命令，提示无法连接到 gerrit.googlesource.com，Operation timed out。那么我们需要编辑 ~/bin/repo文件，找到REPO_URL这一行,然后将其内容修改为:REPO_URL = 'https://gerrit-google.tuna.tsinghua.edu.cn/git-repo' 注意: 上面的地址已经不能用了，要使用下面的地址，具体详情参看：Git Repo 镜像使用帮助REPO_URL = 'https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/' 然后在使用下面的命令初始化仓库：repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest 注意，上面不带参数的manifest命令用于获取master上最新的代码。 可以通过-b参数指定获取某个特定的android版本repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest -b android-4.0.1_r1 AOSP项目当前所有的分支列表参看：https://source.android.com/source/build-numbers#source-code-tags-and-builds 同步源码到本地初始化仓库之后,就可以开始正式同步代码到本地了,命令如下:repo sync 以后如果需要同步最新的远程代码到本地，也只需要执行该命令即可。在同步过程中,如果因为网络原因中断,使用该命令继续同步即可。 同步过程大概需要5个小时，看你的网速了 :) Android Build系统代码下载完成以后，不着急编译，先了解下Android Build系统。 Android Build 系统用来编译 Android 系统，Android SDK 以及相关文档。该系统主要由 Make 文件，Shell 脚本以及 Python 脚本组成，其中最主要的是 Make 文件。Build 系统中最主要的处理逻辑都在 Make 文件中，而其他的脚本文件只是起到一些辅助作用。整个 Build 系统中的 Make 文件可以分为三类： 第一类是 Build 系统核心文件，此类文件定义了整个 Build 系统的框架，而其他所有 Make 文件都是在这个框架的基础上编写出来的。 第二类是针对某个产品（一个产品可能是某个型号的手机或者平板电脑）的 Make 文件，这些文件通常位于 device 目录下，该目录下又以公司名以及产品名分为两级目录。对于一个产品的定义通常需要一组文件，这些文件共同构成了对于这个产品的定义。例如，/device/sony/it26 目录下的文件共同构成了对于 Sony LT26 型号手机的定义。 第三类是针对某个模块的 Make 文件。整个系统中，包含了大量的模块，每个模块都有一个专门的 Make 文件，这类文件的名称统一为“Android.mk”，该文件中定义了如何编译当前模块。Build 系统会在整个源码树中扫描名称为“Android.mk”的文件并根据其中的内容执行模块的编译。 更多编译系统的内容，请看IBM的这篇文章：Android Build系统 编译 Android 系统初始化编译环境执行：source build/envsetup.sh 这句话的意思是引入build/envsetup.sh脚本。该脚本的作用是初始化编译环境，并引入一些辅助的 Shell 函数，这其中就包括下面使用 lunch 函数。 选择编译目标执行：lunch 执行完lunch函数，可以看到下面的结果：You're building on DarwinLunch menu... pick a combo: 1. aosp_arm-eng 2. aosp_arm64-eng 3. aosp_mips-eng 4. aosp_mips64-eng 5. aosp_x86-eng 6. aosp_x86_64-eng 7. full_fugu-userdebug 8. aosp_fugu-userdebug 9. mini_emulator_arm64-userdebug 10. m_e_arm-userdebug 11. m_e_mips-userdebug 12. m_e_mips64-eng 13. mini_emulator_x86-userdebug 14. mini_emulator_x86_64-userdebug 15. aosp_dragon-userdebug 16. aosp_dragon-eng 17. aosp_marlin-userdebug 18. aosp_sailfish-userdebug 19. aosp_flounder-userdebug 20. aosp_angler-userdebug 21. aosp_bullhead-userdebug 22. hikey-userdebug 23. aosp_shamu-userdebugWhich would you like? [aosp_arm-eng] 这里的lunch是选择编译目标，直接输入数字就代表选中 编译目标格式说明: 编译目标的格式:BUILD-BUILDTYPE,比如上面的第一个，aosp_arm-eng的BUILD是aosp_arm，BUILDTYPE是eng. 编译目标的选择，决定了模拟器的响应速度，那么选择哪个编译目标呢？这里StackOverflow上有提问，建议编译aosp_x86-userdebug with HAXM installed 但是我的lunch并没有列出这个编译目标： 所以这里可以使用choosecombo命令,记住也要先执行envsetup.sh脚本哟： choosecomboBuild type choices are: 1. release 2. debugWhich would you like? [1]//这里直接输入2，选择第二个Which product would you like? [aosp_arm]//这里并没有对应的BUILD，所以直接自己输入：aosp_x86Variant choices are: 1. user 2. userdebug 3. eng//这里选择第二个，直接输入2 这样就选择好了编译目标，对应的Terminal的顶部标题也已经改变 编译选择好编译目标后，调用“make -j*”进行编译就可以了. 可以看到线程数为8. make 的参数“-j”指定了同时编译的 Job 数量，这是个整数，该值通常是编译主机 CPU 支持的并发线程总数的 1 倍或 2 倍（例如：在一个 4 核，每个核支持两个线程的 CPU 上，可以使用 make -j8 或 make -j16） 可以使用下面的命令查看本机CPU的内核数与线程数： $ sysctl machdep.cpumachdep.cpu.core_count: 2machdep.cpu.thread_count: 4machdep.cpu.tsc_ccc.numerator: 242machdep.cpu.tsc_ccc.denominator: 2 可以看到我的电脑线程数为4，所以我采用 make -8 编译成功后，使用 emulator 命令就可以运行编译出来的模拟器啦。 下面介绍几个常用到的命令： 如果make失败，或是想换一个BUILD类型，使用下面的命令：make clobber //清理out目录下的文件 ncdu，当电脑磁盘空间不够用时，用下面的命令，遍历大文件 sudo ncdu //查看硬盘中的大文件 安装方式： brew install ncdu 调试Android源码：参考这篇文章：自己动手调试Android源码 将Android源码导入Android Studio：source build/envsetup.shmmm development/tools/idegen/sudo ./development/tools/idegen/idegen.sh 上面代码执行完后，会在源码目录下生成IEDA工程配置文件: android.ipr,android.iml及android.iws.可以发现android.ipr文件的应用图标应该改成了Android Studio样式。 但这里不用Android Studio来打开工程，而是使用IntelliJ来查看和DebugAndroid源码，具体参考这篇文章使用 IntelliJ 查看 Android 源码 单独编译Android源代码工程的模块在Android源码找到目录/packages/experimental，在这个目录下有Google提供基于前面提到的Android BUILD模式构建的apk工程。如下图： 我们选择一个工程：MultiPackageApk，要把它安装到模拟器上需要执行下面的命令：source build/envsetup.shmmm packages/experimental/MultiPackageApk make snod 重启下模拟器，刚才安装的应用就会出现了 单独编译源代码工程出错： ninja: error: 'out/target/common/obj/JAVA_LIBRARIES/core-junit_intermediates/classes.dex.toc', needed by 'out/target/common/obj/APPS/MultiPackageApk_intermediates/with-local/classes.dex', missing and no known rule to make itmake: *** [ninja_wrapper] Error 1 解决方案：应该选择好编译环境后（用lunch或choosecombo命令），再执行单独编译源码工作，最后别忘了执行make snod 使用 IntelliJ Debug Android 源码参考这篇文章：使用 IntelliJ Debug Android 源码 文中，有一个地方跟我的电脑上不太一样： 打开 monitor 选择 debug 进程我电脑上的monitor不是用命令行打开，而是有monitor.app。位置在：/Library/Android_sdk/tools/lib/monitor-x86_64/monitor.app如下图： 到这里Android源码部分的内容就整理完了，下篇文章利用Android源码分析下Activity的启动流程。 ccache造成硬盘空间不足ccache 是一个是适用于 C 和 C++ 的编译器缓存，有助于提高编译速度。但是它本身是采用牺牲空间换取编译速度的方式。如果你设置了 ccache，而且经常使用 make clean，或者经常在不同的编译产品之间切换（比如choosecombo 或 lunch命令），会导致大量的硬盘存储空间被占用。 默认情况下，ccache 的缓存将存储在 ~/.ccache 下。如果你用的是MAC 电脑编译的 AOSP，可以看下这个目录有多大 :( 要想清理空间，直接删除 ~/.ccache 下的内容即可。 具体介绍参考google：设置 ccache 错误收集1.Try increasing heap size with java option ‘-Xmx‘ 这个是说明需要增加Java heap size，具体参见stackoverflow 解决方法是： export JACK_SERVER_VM_ARGUMENTS=\"-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g\"./prebuilts/sdk/tools/jack-admin kill-server./prebuilts/sdk/tools/jack-admin start-server 2.failed to build aosp. says subcommand failedMAC系统升级到high sierra，在用make指令编译源码的时候报错，没有更多提示，只有下面的日志：... system/tools/aidl/aidl_language_y.yy... aidl_language_l.cppninja: build stopped: subcommand failed.15:57:14 ninja failed with: exit status 1 #### failed to build some targets (05:20 (mm:ss)) #### 关键错误信息是aidl_language_y.yy和aidl_language_l.cpp 解决方案： Step1. Patch bison fix for High Sierra and build bison: 1. cd /Volumes/AOSP/external/bison2. git cherry-pick c0c852bd6fe462b148475476d9124fd740eba1603. mm Step2. Replace prebuilt bison binary with patched binary 1. cp /Volumes/AOSP/out/host/darwin-x86/bin/bison /Volumes/AOSP/prebuilts/misc/darwin-x86/bison/ Step3. Build 1. make -j4 如果mm命令无法执行，需要回去执行以下命令:source build/envsetup.shlunch #之后回到external/bison目录mm 参考自：http://www.jianshu.com/p/35f840dd7869 和https://groups.google.com/forum/#!topic/android-building/D1-c5lZ9Oco 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/08/01/aosp-compile/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AOSP","slug":"aosp","permalink":"http://agehua.github.io/tags/aosp/"},{"name":"sdk compile","slug":"sdk-compile","permalink":"http://agehua.github.io/tags/sdk-compile/"}]},{"title":"Android免root实现hook系统服务拦截方法","slug":"android-noroot-hook","date":"2017-07-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.326Z","comments":true,"path":"2017/07/12/android-noroot-hook/","link":"","permalink":"http://agehua.github.io/2017/07/12/android-noroot-hook/","excerpt":"本文转载自博文：Android系统篇之—-免root实现Hook系统服务拦截方法，结合最新开源的滴滴插件化方案 VirtualApk 对hook系统服务进行分析。\n360之前开源了一款插件框架 Droid Plugin。与滴滴同一天，360又开源了一款插件框架 RePlugin。\n有关新闻介绍在这里：https://www.itcodemonkey.com/article/278.html                https://www.itcodemonkey.com/article/277.html\n关于360两款插件框架有什么不同，可以查看RePlugin里的readme\n本文简单结合VirtualApk源码来记录实现hook系统服务方法。\nAndroid免root实现hook系统服务拦截方法Binder机制回顾","text":"本文转载自博文：Android系统篇之—-免root实现Hook系统服务拦截方法，结合最新开源的滴滴插件化方案 VirtualApk 对hook系统服务进行分析。 360之前开源了一款插件框架 Droid Plugin。与滴滴同一天，360又开源了一款插件框架 RePlugin。 有关新闻介绍在这里：https://www.itcodemonkey.com/article/278.html https://www.itcodemonkey.com/article/277.html 关于360两款插件框架有什么不同，可以查看RePlugin里的readme 本文简单结合VirtualApk源码来记录实现hook系统服务方法。 Android免root实现hook系统服务拦截方法Binder机制回顾 在之前一篇文章中介绍了 Android中的Binder机制和系统远程服务调用机制，本文将继续借助上一篇的内容来实现Hook系统服务拦截指定方法的逻辑，了解了上一篇文章之后，知道系统的服务其实都是一个远程Binder对象，而这个对象都是由ServiceManager大管家管理的，用户在使用系统服务的时候，会通过指定服务的Stub方法的asInterface把远程的Binder对象转化成本地化对象即可使用，而在这个过程中，我们也知道因为系统服务是在system_server进程中的，所以这个系统服务使用过程中属于跨进程调用，那么返回的对象其实就是Proxy代理对象。 系统中服务使用流程本文主要就是借助这个知识点，通过Hook系统的服务来拦截服务方法，下面我们就通过系统剪切板服务案例作为分析//获取剪切板服务ClipboardManager cm =(ClipboardManager)getSystemService(Context.CLIPBOARD_SERVICE);//设置剪切板内容cm.setPrimaryClip(ClipData.newPlainText(\"data\",\"jack\"));//获取剪切板数据对象ClipData cd = cm.getPrimaryClip();String msg = cd.getItemAt(0).getText().toString();Log.d(\"jw\", \"msg:\"+ msg); 这里看到了，使用系统服务的时候都是用了getSystemService方法，通过定义在Context中的服务描述符常量来获取服务对象，而getSystemService方法定义在ComtextImpl.java类中：@Overridepublic Object getSystemService(String name) &#123; ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); return fetcher == null ? null : fetcher.getService(this);&#125; 这里维护了一个ServiceFetcher的Map结构，看看这个结构在哪里填充数据的：private static void registerService(String serviceName, ServiceFetcher fetcher) &#123; if (!(fetcher instanceof StaticServiceFetcher)) &#123; fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++; &#125; SYSTEM_SERVICE_MAP.put(serviceName, fetcher);&#125; 在registerService方法中添加一个服务名称和一个ServiceFetcher对象，而这个方法在静态代码块中进行调用的:static &#123; registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() &#123; public Object getService(ContextImpl ctx) &#123; return AccessibilityManager.getInstance(ctx); &#125;&#125;); //... registerService(CLIPBOARD_SERVICE, new ServiceFetcher() &#123; public Object createService(ContextImpl ctx) &#123; return new ClipboardManager(ctx.getOuterContext(), ctx.mMainThread.getHandler()); &#125;&#125;); //.... registerService(CONNECTIVITY_SERVICE, new ServiceFetcher() &#123; public Object createService(ContextImpl ctx) &#123; IBinder b = ServiceManager.getService(CONNECTIVITY_SERVICE); return new ConnectivityManager(IConnectivityManager.Stub.asInterface(b)); &#125;&#125;); //....&#125; ClipboardManager这个服务也在这个代码块中注册了 这里其实是一个ClipboardManager对象，其实这个对象是内部封装了IClipboard.Stub功能，可以看看其他的服务，比如上面的联网服务，直接调用了IConnectivityManager.Stub类的asInterface方法获取Proxy对象。 下面就进去ClipboardManager.java中看看究竟：public void setPrimaryClip(ClipData clip) &#123; try &#123; if (clip != null) &#123; clip.prepareToLeaveProcess(); &#125; getService().setPrimaryClip(clip, mContext.getOpPackageName()); &#125; catch (RemoteException e) &#123; &#125;&#125; 看到这里的设置剪切板内容的方法，其实内部是调用了getService方法获取对象然后在调用指定方法，那么可以大概知道了这个getService方法返回的应该就是IClipboard.Stub通过asInterface方法返回的Proxy对象：static private IClipboard getService() &#123; synchronized (sStaticLock) &#123; if (sService != null) &#123; return sService; &#125; IBinder b = ServiceManager.getService(\"clipboard\"); sService = IClipboard.Stub.asInterface(b); return sService; &#125;&#125; 吧，果然是这样，这里通过ServiceManager获取到Clipboard的远端IBinder对象，然后通过asInterface方法返回一个Proxy对象即可。 到这里我们就简单的分析完了系统中的获取剪切板的服务，其实系统中的服务都是这么个逻辑，只是有的可能会在外面包装一层罢了，下面总结一下流程： 现在只要记住一点：每次获取系统服务的流程都是一样的，先通过ServiceManager的getService方法获取远端服务的IBinder对象，然后在通过指定服务的Stub类的asInterface方法转化成本地可使用对象，而这个对象其实就是一个Proxy对象，在这个过程中，Stub类继承了Binder对象和实现了AIDL接口类型，Proxy对象实现了AIDL接口类型，而AIDL接口类型实现了IInterface接口类型。 Hook系统服务上面分析完了Android中系统服务的使用流程以及原理解析，下面在来看一下android中实现Hook机制的方法和原理解析，我们知道其实在很多系统中都存在这样一个Hook技术，有的也叫作钩子，但是不管任何系统，Hook技术的核心点都是一样的，只有两点即可完成Hook技术： 1、找到Hook点，即你想Hook哪个对象，那么得先找到这个对象定义的地方，然后使用反射获取到这个对象实例。所以这里可以看到，一般Hook点都是一个类的单例方法或者是静态变量，因为这样的话Hook起来就非常方便，都是static类型，反射调用都比较方便无需具体的实例对象即可。而关于这个点也是整个Hook过程中最难的点，因为很难找到这个点。Android中主要是依靠分析系统源码类来做到的。 2、构造一个Hook原始对象的代理类，关于这个代理其实在Java中有两种方式，一种是静态代理，一种是动态代理。 静态代理：代理类中维护一个原始对象的成员变量，每个方法调用之前调用原始对象的方法即可。无需任何条件限制 动态代理：比静态代理复杂点就是有一个规则：就是原始对象必须要实现接口才可以操作，原理是因为动态代理其实是自动生成一个代理类的字节码，类名一般都是Proxy$0啥的，这个类会自动实现原始类实现的接口方法，然后在使用反射机制调用接口中的所有方法。 下面结合VirtualApk源码，分析这个原理： 这里的代码与原博文里的代码有所不同，原博文是结合DroidPlugin进行分析 在VirtualApk的源码com/didi/virtualapk/delegate/目录下，有两个Proxy结尾的类，这两个类动态代理模式相同，我们只看一个。在IContentProviderProxy.java文件中public class IContentProviderProxy implements InvocationHandler &#123; //.....代码省略 public static IContentProvider newInstance(Context context, IContentProvider iContentProvider) &#123; return (IContentProvider) Proxy.newProxyInstance(iContentProvider.getClass().getClassLoader(), new Class[] &#123; IContentProvider.class &#125;, new IContentProviderProxy(context, iContentProvider)); &#125; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable &#123; Log.v(TAG, method.toGenericString() + \" : \" + Arrays.toString(args)); wrapperUri(method, args); try &#123; return method.invoke(mBase, args); &#125; catch (InvocationTargetException e) &#123; throw e.getTargetException(); &#125; &#125; //...代码省略&#125; 看到这里，了解java AOP技术的已经知道IContentProviderProxy这个类使用了java.lang.ref.proxy方案来实现动态生成代理类。 不了解ASM和InvocationHandler的同学可以看IBM的这篇文章：AOP 的利器：ASM 3.0 介绍 简单介绍下java本身的动态代理机制在java的动态代理机制中，有两个重要的类或接口，一个是InvocationHandler(Interface)、另一个则是Proxy(Class)，这一个类和接口是实现我们动态代理所必须用到的。 这里借用上面IBM的文章中的例子：Account类是一个接口，具体操作由AccountImpl类实现public interface Account &#123; void operation();&#125; public class AccountImpl extends Account&#123; public void operation() &#123; System.out.println(\"operation...\"); //TODO real operation &#125;&#125; 现在的要求是在Account的operation()方法执行前加入一个checkSecurity()检查。 那么使用InvocationHandler和Proxy的实现方式就是：class SecurityProxyInvocationHandler implements InvocationHandler &#123; private Object proxyedObject; public SecurityProxyInvocationHandler(Object o) &#123; proxyedObject = o; &#125; @Override public Object invoke(Object object, Method method, Object[] arguments) throws Throwable &#123; if (object instanceof Account &amp;&amp; method.getName().equals(\"opertaion\")) &#123; SecurityChecker.checkSecurity(); &#125; return method.invoke(proxyedObject, arguments); &#125;&#125; public static void main(String[] args) &#123; Account account = (Account) Proxy.newProxyInstance( Account.class.getClassLoader(), new Class[] &#123; Account.class &#125;, new SecurityProxyInvocationHandler(new AccountImpl()) ); account.function();&#125; 总结如下： InvocationHandler这个接口只有一个方法invoke()： Object invoke(Object proxy, Method method, Object[] args) throws Throwable proxy: 指代我们所代理的那个真实对象 method: 指代的是我们所要调用真实对象的某个方法的Method对象 args: 指代的是调用真实对象某个方法时接受的参数 每一个动态代理类都必须要实现InvocationHandler这个接口，当我们通过代理对象（这里就是account对象）调用一个方法的时候，这个方法的调用就会被转发为由InvocationHandler这个接口的invoke方法来进行调用 Proxy类使用的最多的就是newProxyInstance这个方法： public static Object newProxyInstance(ClassLoader loader, Class&lt;?&gt;[] interfaces, InvocationHandler h) throws IllegalArgumentException loader: 一个ClassLoader对象，定义了由哪个ClassLoader对象来对生成的代理对象进行加载 interfaces: 一个Interface对象的数组，表示的是我将要给我需要代理的对象提供一组什么接口，如果我提供了一组接口给它，那么这个代理对象就宣称实现了该接口(多态)，这样我就能调用这组接口中的方法了 h: 一个InvocationHandler对象，表示的是当我这个动态代理对象在调用方法的时候，会关联到哪一个InvocationHandler对象上 Proxy类并不负责实例化对象，newProxyInstance()方法的作用是动态创建一个代理对象的类。 Proxy动态生成代理的不足之处在于： Proxy 是面向接口的，所有使用 Proxy 的对象都必须定义一个接口，而且用这些对象的代码也必须是对接口编程的：Proxy 生成的对象是接口一致的而不是对象一致的：例子中 Proxy.newProxyInstance 生成的是实现 Account接口的对象而不是 AccountImpl 的子类。这对于软件架构设计，尤其对于既有软件系统是有一定掣肘的。 Proxy 毕竟是通过反射实现的，必须在效率上付出代价：有实验数据表明，调用反射比一般的函数开销至少要大10倍。而且，从程序实现上可以看出，对 proxy class 的所有方法调用都要通过使用反射的 invoke 方法。因此，对于性能关键的应用，使用 proxy class 是需要精心考虑的，以避免反射成为整个应用的瓶颈。 对比VirtualApk框架中的 IContentProviderProxy 类，和上面Account例子里的 SecurityProxyInvocationHandler 类，可以发现，IContentProviderProxy 使用了 InvocationHandler 的动态代理机制，而代理的具体内容就在invoke()回调里。 好的，现在在回到VirtualApk的IContentProviderProxy源码的invoke()方法里。invoke() 方法中调用了wrapperUri()，来看下这个方法：private void wrapperUri(Method method, Object[] args) &#123; Uri uri = null; int index = 0; if (args != null) &#123; for (int i = 0; i &lt; args.length; i++) &#123; if (args[i] instanceof Uri) &#123; uri = (Uri) args[i]; index = i; break; &#125; &#125; &#125; //如果挂钩的是call方法 Bundle bundleInCallMethod = null; if (method.getName().equals(\"call\")) &#123; bundleInCallMethod = getBundleParameter(args); if (bundleInCallMethod != null) &#123; String uriString = bundleInCallMethod.getString(KEY_WRAPPER_URI); if (uriString != null) &#123; uri = Uri.parse(uriString); &#125; &#125; &#125; //... PluginManager pluginManager = PluginManager.getInstance(mContext); //这里根据uri找到对应的ContentProvider ProviderInfo info = pluginManager.resolveContentProvider(uri.getAuthority(), 0); if (info != null) &#123; String pkg = info.packageName; LoadedPlugin plugin = pluginManager.getLoadedPlugin(pkg); String pluginUri = Uri.encode(uri.toString()); StringBuilder builder = new StringBuilder(PluginContentResolver.getUri(mContext)); builder.append(\"/?plugin=\" + plugin.getLocation()); builder.append(\"&amp;pkg=\" + pkg); builder.append(\"&amp;uri=\" + pluginUri); Uri wrapperUri = Uri.parse(builder.toString()); if (method.getName().equals(\"call\")) &#123; bundleInCallMethod.putString(KEY_WRAPPER_URI, wrapperUri.toString()); &#125; else &#123; args[index] = wrapperUri; &#125; &#125;&#125; 1.从wrapperUri()的第二个参数找到Uri 2.调用resolveContentProvider()方法，根据uri找到占坑的ContentProvider public ProviderInfo resolveContentProvider(String name, int flags) &#123; return this.mProviders.get(name);&#125; ProviderInfo对象的解释就是：Holds information about a specific content provider 3.使用StringBuilder对，将uri，pkg，plugin等参数等拼接上去，替换到args中的uri，然后继续走原本的流程。 假设是调用了query方法，应该就可以到达占坑的provider的query方法了。这就是插件框架里传说中的占坑，即不用注册就可以启动插件里的组件啦 剪切板实例到此我们了解了Java中的Hook技术的核心知识点了，下面就用开始的剪切板服务来做实验，我们Hook系统的剪切板服务功能，拦截其方法，上面也说道了，既然要Hook服务，首先得找到Hook点，通过开始对Android中系统服务的调用流程分析知道，其实这些服务都是一些保存在ServiceManager中的远端IBinder对象，这其实是一个Hook点： public static IBinder getService(String name) &#123; try &#123; IBinder service = sCache.get(name); if (service != null) &#123; return service; &#125; else &#123; return getIServiceManager().getService(name); &#125; &#125; catch (RemoteException e) &#123; Log.e(TAG, \"error in getService\", e); &#125; return null;&#125; 其实ServiceManager中每次在获取服务的时候，其实是先从一个缓存池中查找，如果有就直接返回了：private static HashMap&lt;String, IBinder&gt; sCache = new HashMap&lt;String, IBinder&gt;(); 这个缓存池正好是全局的static类型，所以就可以很好的使用反射机制获取到它了，然后进行操作了 接下来，我们就需要构造一个剪切板的服务IBinder对象了，然后在把这个对象放到上面得到的池子中即可。 那么按照上面的动态代理的流程（使用Proxy Java原生动态代理） 第一、原始对象必须实现一个接口，这里也正好符合这个规则，每个远程服务其实是实现了IBinder接口的。 第二、其次是要有原始对象，这个也可以，通过上面的缓存池即可获取。 有了这两个条件那么接下来就可以使用动态代理构造一个代理类了：try &#123; //下面这一段的意思其实就是ServiceManager.getService(\"clipboard\") //只不过ServiceManager这个类是@hide的 Class&lt;?&gt; serviceManager = Class.forName(\"android.os.ServiceManager\"); Method getService = serviceManager.getDeclaredMethod(\"getService\", String.class); //取得ServiceManager里的原始的clipboard binder对象 //一般来说这是一个Binder代理对象 IBinder rawBinder =(IBinder) getService.invoke(null, Context.CLIPBOARD_SERVICE); //Hook掉这个Binder代理的queryLocalInterface 方法 //然后在queryLocalInterface返回一个IInterface对象，hook掉我们感兴趣的方法即可 IBinder hookedBinder =(IBinder) Proxy.newProxyInstance( serviceManager.getClassLoader, new Class&lt;?&gt;[](IBinder.class), new IClipboardHookBinderHandler(rawBinder) ); //放回ServiceManager中，替换掉原有的 Field cacheField = serviceManager.getDeclaredField(\"sCache\"); cacheField.setAccessible(true); @SuppressWarnings(&#123;\"unchecked\"&#125;) Map&lt;String, IBinder&gt; cache = (Map&lt;String,IBinder&gt;) cacheField.get(null); cache.put(Context.CLIPBOARD_SERVICE, hookedBinder);&#125;catch (Exception e)&#123;&#125; Field.get()可以返回一个Object，字段不是静态字段的话，要传入反射类的对象。如果传null是会报 java.lang.NullPointerException。但是如果字段是静态字段的话,传入任何对象都是可以的,包括null 这里是通过反射去获取ServiceManager中的缓存池Binder对象。我们先获取到缓存池，然后得到剪切板服务Binder对象，构造一个代理类，最后在设置回去即可。 下面主要来看一下构造了代理类之后，如何拦截哪些方法？@Overridepublic Object invoke(Object object, Method method, Object[] args) throws Throwable &#123; if (method.getName().equals(\"queryLocalInterface\")) &#123; Log.d(TAG, \"hook queryLocalInterface\"); //这里直接返回真正被hook掉的Service接口 //这个代理类必须实现IInterface接口 return Proxy.newProxyInstance( base.getClassLoader, new Class&lt;?&gt;[](this.iinterface), new HookBinderInvocationHander(base,stub) ); &#125; return method.invoke(base, args);&#125; 因为拦截的是queryLocalInterface()方法，这个方法返回的是一个远端的服务，还没有转化为本地对象，所以不能去拦截具体的服务方法 这里一定要注意了，有的同学可能想直接在这里拦截setPrimaryClip这样的剪切板方法不就可以了吗？想想是肯定不可以的，为什么呢？因为我们现在代理的是远端服务的Binder对象，他还没有转化成本地对象呢？如何会有这些方法呢，而我们真正要拦截的方法是IClipboardManager，其实就是Proxy类，而这个对象也是Stub类的asInterface方法得到的，所以我们现在的思路是有了远端服务的代理对象，拦截肯定是拦截这个代理对象Binder的一些方法，那么这个远端服务有哪些方法会在这个过程中被调用呢？我们再看看之前的一个简单AIDL的例子：public static com.agehua.aidldemo.Demo asInterface(android.os.IBinder obj) &#123; if ((obj == null)) &#123; return null; &#125; //这里的obj就是远端对象，它通过queryLocalInterface()方法获取本进程中的服务，这里就是hook点 android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) &amp;&amp; (iin instanceof com.agehua.aidldemo.Demo))) &#123; return ((com.agehua.aidldemo.Demo) iin); &#125; return new com.agehua.aidldemo.Demo.Stub.Proxy(obj);&#125; 然后在想，我们如果想拦截IClipboardManager的setPrimaryClip方法，其实就是要拦截ClipboardManager$Proxy的这些方法，那么还需要做一次代理，代理ClipboardManager$Proxy类对象 第一、ClipboardManager$Proxy类实现了AIDL接口类型，符合规则。 第二、我们可以直接使用反射获取到IClipboardManager$Stub类，然后反射调用它的asInterface方法就可以得到了IClipboardManager$Proxy对象了，符合规则。 public IClipboardHookBinderHandler(IBinder base) &#123; this.base = base; try &#123; this.stub =Class.forName(\"android.content.IClipboard$Stub\"); this.iinterface = Class.forName(\"android.content.IClipboard\"); &#125;catch (ClassNotFoundException e)&#123; &#125;&#125; 到这里，看来这个对象也符合了代理的条件，那么就简单了，继续使用动态代理机制产生一个代理类即可：public IClipboardHookBinderHandler(IBinder base, Class&lt;?&gt; stubClass) &#123; try &#123; Method asInterfaceMethod = stubClass.getDeclaredMethod(\"asInterface\", IBinder.class); this.base = asInterfaceMethod.invoke(null, base); &#125;catch (Exception e)&#123; throw new RuntimeException(\"hooked failed\") &#125;&#125; 这个代理类的InvocationHandler中，先需要通过反射获取到Proxy原始对象：@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable&#123; if (\"getPrimaryClip\".equals(method.getName())) &#123; return ClipData.newPlainText(null, \"you are hooked\"); &#125; //欺骗系统，使之认为剪切板上一直有内容 if (\"hasPrimaryClip\".equals(method.getName())) &#123; return true; &#125; //千万不要忘了调用原始对象的方法 return method.invoke(base, args);&#125; 到这里就已经完成了hook剪切板服务的整个步骤，再看一下流程图： 1、我们的目的就是拦截系统的服务功能，那么最开始的入口就是服务大管家ServiceManager对象，而在他内部也正好有一个远端服务对象的IBinder缓存池，那么这个变量就是我们操作的对象了，可以先使用反射机制去获取到他，然后在获取到指定的剪切板服务IBinder对象实例。 2、下一步肯定是Hook这个剪切板服务的Binder对象，这里采用动态代理方式产生一个Binder对象代理类，符合两个规则： 1) 这个Binder对象实现了IBinder接口类型 2) 我们已经得到了原始的Binder对象实例构造完代理类之后，我们拦截的方法是queryLocalInterface方法，为什么是这个方法呢？因为在整个服务使用过程中之后在Stub类中使用到了这个方法，很多同学会认为为什么不在这里直接拦截系统方法呢？这是一个误区，要想清楚，这里的代理对象是远程服务的Binder，还不是本地化对象，不能会有哪些系统方法的，所以得再做一次Hook，去Hook住系统的本地化对象。 3、在拦截了Binder对象的queryLocalInterface方法之后，再一次做一下本地化服务对象的代理生成操作，而这个本地化对象一般都是IClipboard$Proxy，那么动态代理的规则： 1) 本地化服务对象都会实现AIDL接口类型(这里才有哪些我们想拦截的系统方法) 2) 通过反射调用IClipboard$Stub类的asInterface方法得到IClipboard$Proxy类对象实例符合这两个规则那么就可以产生代理对象了，然后开始拦截服务的指定方法即可。 这个Hook系统服务只对本应用有效。真正能够拦截系统并对所有应用有效的，需要hook进system_server进程中，所以就需要root权限 总结到这里我们就介绍完了Android中Hook系统服务的流程，本文中主要介绍了Hook系统剪切板服务，拦截指定方法。同时，对VirtualApk插件框架感兴趣的同学也可以看看张鸿洋的这篇文章： 滴滴插件化方案 VirtualApk 源码解析 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/07/12/android-noroot-hook/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"},{"name":"HOOK","slug":"hook","permalink":"http://agehua.github.io/tags/hook/"},{"name":"Android system service","slug":"android-system-service","permalink":"http://agehua.github.io/tags/android-system-service/"}]},{"title":"Android Binder机制分析（二）","slug":"android-binder-principle2","date":"2017-07-09T16:00:00.000Z","updated":"2024-12-05T09:41:56.322Z","comments":true,"path":"2017/07/10/android-binder-principle2/","link":"","permalink":"http://agehua.github.io/2017/07/10/android-binder-principle2/","excerpt":"背景上篇文章分析到了Binder机制，分别介绍了自定义AIDL服务和调用系统的远程服务和他们之间的区别。本文承接上篇文章，继续介绍ServiceManager和系统服务的注册流程，最后对Binder机制进行分析。\n\n关于系统服务的注册流程，大都转载自这篇文章\n\n服务大管家ServiceManager\nServiceManager.java的源码可以在谷歌源码中看到，点击这里\n\n上篇文章末尾提到，系统服务的IBinder对象都是由ServiceManager统一管理的。为什么这么说呢，先看下ServiceManager.getService方法:","text":"背景上篇文章分析到了Binder机制，分别介绍了自定义AIDL服务和调用系统的远程服务和他们之间的区别。本文承接上篇文章，继续介绍ServiceManager和系统服务的注册流程，最后对Binder机制进行分析。 关于系统服务的注册流程，大都转载自这篇文章 服务大管家ServiceManager ServiceManager.java的源码可以在谷歌源码中看到，点击这里 上篇文章末尾提到，系统服务的IBinder对象都是由ServiceManager统一管理的。为什么这么说呢，先看下ServiceManager.getService方法:/** * Returns a reference to a service with the given name. * * @param name the name of the service to get * @return a reference to the service, or &lt;code&gt;null&lt;/code&gt; if the service doesn't exist */public static IBinder getService(String name) &#123; try &#123; IBinder service = sCache.get(name); if (service != null) &#123; return service; &#125; else &#123; return getIServiceManager().getService(name); &#125; &#125; catch (RemoteException e) &#123; Log.e(TAG, \"error in getService\", e); &#125; return null;&#125; sCache是一个本地静态Map对象，作为缓存池：private static HashMap&lt;String, IBinder&gt; sCache = new HashMap&lt;String, IBinder&gt;(); ServiceManager本身会维护一个IBinder缓存池，也是为了效率高考虑，对于一个应用频繁的使用一些服务的话效率就会高很多。 然后最核心的获取服务的方法是getIServiceManager方法：private static IServiceManager getIServiceManager() &#123; if (sServiceManager != null) &#123; return sServiceManager; &#125; // Find the service manager sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject()); return sServiceManager;&#125; 在上面的代码中，调用了ServiceManagerNative.asInterface()方法，是不是说明ServiceManager也通过远端服务来取得对应的服务呢？ 具体在看一下ServiceManagerNative.java方法：public abstract class ServiceManagerNative extends Binder implements IServiceManager&#123; /** * Cast a Binder object into a service manager interface, generating * a proxy if needed. */ static public IServiceManager asInterface(IBinder obj) &#123; if (obj == null) &#123; return null; &#125; IServiceManager in = (IServiceManager)obj.queryLocalInterface(descriptor); if (in != null) &#123; return in; &#125; return new ServiceManagerProxy(obj); &#125; //....&#125; 看到上面的代码，基本可以确认，在获取ServiceManager对象也是通过了远程调用。只是名字改成了ServiceManagerNative，本应该叫ServiceManagerService的。 看到这里的ServiceManager也是通过远端服务获取到他的IBinder对象，然后在转化成本地对象进行使用的。那么刚刚看到系统的服务都是通过ServiceManager管理获取的，而现在ServiceManager本身是怎么获取到的IBinder对象的呢？这个就要从系统启动的时机看了，众所周知系统启动的时候是根据init.rc文件进行操作的： service servicemanager /system/bin/servicemanager class core user system group system critical onrestart restart healthd onrestart restart zygote onrestart restart media onrestart restart surfaceflinger onrestart restart drm 这里会启动一个servicemanager服务，那么就要去service_manager.c程序中的入口程序看了： 这个入口其实包含了Binder机制的重要信息，而主要就是三件事： 1、打开底层的Binder驱动程序，这个后面介绍Binder机制在介绍 2、通过向binder程序发送命令：BINDER_SET_CONTEXT_MGR，告诉binder程序，我要成为大管家 3、进入循环监听上层应用的服务请求处理，所以这里可以看到其实ServiceManager是一个守护进程在后台默默监听 在第二步中成为大管家的代码深入看一看： 其实这里的逻辑也是比较简单的，首先创建一个属于servicemanager的binder节点，然后在创建一个binder链表，而这个链表的作用就是存放上层中需要系统服务的所有binder对象的节点，这样ServiceManager就可以实现了服务的增加和查询操作了。 再来看看ServiceManager的添加服务操作： 添加服务比较复杂，首先查看这个服务有没有注册权限限制，不是所有的服务都能注册的，然后在查看这个服务是不是已经被注册过了，最后在通知binder驱动程序注册一个服务即可。 然后在来看看ServiceManager的查找服务功能： 查找服务就比较简单了，直接通过服务的描述符名称遍历binder链表节点即可。 1、Service Manager能集中管理系统内的所有服务，它能被施加权限控制，并不是任何进程都能注册服务的。 2、Service Manager支持通过字符串名称来查找对应的Service。 3、由于各种原因的影响，Server进程可能生死无常。如果有了Service Manager做统一的管理，那么Client只要向Service Manager做查询，就能得到Server的最新信息。 系统服务注册流程分析这部分内容也可以参考博客：Android深入浅出之Binder机制 下面来看一下一些系统服务是如何进程注册的，这里用MediaService来进行查看吧。 系统中的MediaService服务的启动也是在init.rc中的service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ioprio rt 4 查看Main_mediaserver.cpp源码的main函数：int main(int argc, char** argv)&#123; //获得一个ProcessState实例 sp&lt;ProcessState&gt; proc(ProcessState::self()); //得到一个ServiceManager对象 sp&lt;IServiceManager&gt; sm = defaultServiceManager(); MediaPlayerService::instantiate();//初始化MediaPlayerService服务 ProcessState::self()-&gt;startThreadPool(); IPCThreadState::self()-&gt;joinThreadPool();&#125; sp是google搞出来的为了方便C/C++程序员管理指针的分配和释放的一套方法，就把它当做一个普通的指针看待，sp&lt;XXX&gt;就看成是XXX*就可以了 这里用MediaPlayerService来看看注册操作：void MediaPlayerService::instantiate() &#123; defaultServiceManager()-&gt;addService( String16(\"media.player\"), new MediaPlayerService()); )&#125; 看到熟悉的代码了把，这里通过ServiceManager来进行服务注册了，那么这里是如何获取到ServiceManager的？sp&lt;IServiceManager&gt; defaultServiceManager() &#123; if (gDefaultServiceManager != NULL) return gDefaultServiceManager; &#123; AutoMutex _l(gDefaultServiceManagerLock); //---&gt;锁保护 while (gDefaultServiceManager == NULL) &#123; gDefaultServiceManager = interface_cast&lt;IServiceManager&gt; ( ProcessState::self()-&gt;getContextObject(NULL)); if (gDefaultServiceManager == NULL) sleep(1); &#125; &#125; return gDefaultServiceManager;&#125; 看看ProcessState.cpp的源码：sp&lt;IBinder&gt; ProcessState::getContextObject(const sp&lt;IBinder&gt;&amp; caller) &#123; return getStrongProxyForHandle(0);&#125; 看看getStrongProxyForHandle方法实现： 这里看到了，会使用IPCThreadState的transact方法和底层的Binder进行通信的，然后使用一个句柄handle构造一个BpBinder对象，而BpBinder对象其实就是native层实现的Binder对象，以后只要看到Bp开头的就是代理对象对应Java层的Proxy对象，Bn开头的就是native对象对应Java层的Stub对象。 在上面分析servicemanager的时候知道会维护一个binder节点链表，那里其实就有一个每个binder对应句柄handle，而后续进行通信的话都是通过这个句柄来标识是哪个服务的binder对象了，这样也就在通信的时候不会发生紊乱了，而servicemanager的句柄handle就是0。还有一个知识点就是可以看到IPC通信的时候传输数据使用的就是Parcel类，这个类就是为了跨进程通信产生的，他有一个方法readStrongBinder，就是可以从Parcel的数据中获取到Binder对象，这个也是在跨进程中传递Binder对象的核心地方。public final IBinder readStrongBinder() &#123; return nativeReadStronBinder(mNativePtr);&#125; 好了，上面就通过系统的mediaserver服务来讲解了系统服务的注册流程： 到这里就分析完了Android中的远程服务调用机制逻辑以及ServiceManager这个服务大管家的作用: 1、首先跨进程通信的话，肯定会有两个对象：一个是本地端的中间者Proxy对象，一个是远程端的中间者Stub对象 2、Proxy对象通过静态代理模式维持一个远端传递过来的Binder对象，而Stub对象可以把远端传递过来的Binder对象转化成一个实际服务对象给应用使用 3、Android中在使用系统服务的时候通过getSystemService方法获取到的其实都是Stub把远端的Binder转化的对象，因为系统服务都是在system_server进程中，所以肯定是跨进程获取对象的，那么这个Binder对象其实就是上面的Proxy对象 4、系统的服务都是在一个指定的系统进程中system_server 5、服务大管家ServiceManager在系统启动的时候也是先获取自生的Binder对象，然后转化成实际操作对象，然后才可以操作系统服务的注册和查询功能 下面是系统一些服务的注册流程： 上面已经介绍了远程服务调用机制以及ServiceManager的实现原理，下面就要看看另外一个重点，也是上面提到的一个重要对象Binder，准确来说这个是Binder机制，在Android中Binder机制最复杂的一个架构系统了，它的设计很复杂，所以有很多同学在了解Binder机制的时候，总是看着看着就晕了，今天我们就直说重点，而且说得要相对明了简单。 Binder机制解析第一、Android中的IPC为何要采用Binder机制Binder是Android系统进程间通信(IPC)方式之一。Linux已经拥有的进程间通信IPC手段包括(Internet Process Connection)：管道(Pipe)、信号(Signal)和跟踪(Trace)、插口(Socket)、报文队列(Message)、共享内存(Share Memory)和信号量(Semaphore)。 Binder基于Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID,PID身份，既支持实名Binder也支持匿名Binder，安全性高。对Binder而言，Binder可以看成Server提供的实现某个特定服务的访问接入点， Client通过这个‘地址’向Server发送请求来使用该服务；对Client而言，Binder可以看成是通向Server的管道入口，要想和某个Server通信首先必须建立这个管道并获得管道入口。 第二、Android中的Binder实现原理其实Android中的Binder通信都是通过虚拟驱动设备程序/dev/binder来实现的，我们知道一些硬件都会对应一个驱动程序，而binder驱动程序没有对应的硬件，所以叫做虚拟驱动设备程序，其实他就是一个字符驱动设备，或者叫做miscdevice混杂设备驱动。 其实混杂驱动设备是字符设备的一种，它们共享一个主设备号(10)，但次设备号不同，所有的混杂设备形成一个链表，对设备访问时内核根据次设备号查找到相应的miscdevice设备。例如:触摸屏，LED，按键，串口。即：为了节约主设备号，将某些设备用链表的形式连接在一起，最后通过查找次设备区分。这里用主设备无法匹配出设备驱动，只能找到链表，再通过次设备号，才能找到设备驱动。而之前所学的，一般字符设备，通过主设备号，就能找到设备驱动了。我们可以通过命令查看/dev/binder驱动的主设备号： 第三、Android中Binder通信机制先来看一张图，我们可以大体的了解到了客户端和服务端通过Binder驱动进行通信 首先不管是客户端进程还是服务端进程都是在用户空间的，而binder驱动是在内核空间的，通信的数据是有规定格式也叫作IPC数据，既然是一种通信机制，肯定是需要协议，数据格式等基础结构信息的： 上面在分析了ServiceManager的启动的时候说到了，第一步是打开驱动程序，具体打开函数在binder.c中： 在使用一个驱动之前，肯定要先打开驱动，然后把驱动程序映射到内存中，接着借助IPCTreadState.cpp和binder驱动进行通信了： 所以看到这里IPCThreadState也是需要进入后台进行监听的，处理来自客户端和服务端的数据传输消息 最后再来看一下通信时序图。 到这里我们就介绍完了Binder机制了，关于Binder机制最好不要看太深，因为越深你觉得越复杂越难理解，其实你只要了解到他是一个通信工具，通信采用的是驱动操作，通过传输IPC数据来进行通信即可。其他的关于他的详细数据格式和通信协议，感兴趣的同学可以了解一下，但是太过复杂而且在实际中也没多大用途，所以这里就不介绍了。 技术点概要理解远程服务通信机制通过案例先了解到本地端和服务端跨进程通信，主要就是借助Binder进行功能调用，而在这里主要有两个核心类，一个是Stub类，这个类是继承了Binder类具备了将远程传递的Binder对象转化成本地实际对象asInterface方法即可，同时实现了IXXX接口，需要实现AIDL中的功能方法，还有一个类就是Proxy类，实现了IXXX接口，同时内部保留着远端传递的Binder对象，然后通过这个对象调用远端方法。这里Stub类就是服务端的中间者，而Proxy就是本地端的中间者。 系统服务调用流程通过分析了跨进程通信机制原理之后，再去看看Android系统中在使用一些服务的时候，通过getSystemService方法获取服务对象，其实这内部就是通过跨进程获取到了远端服务的Binder对象，然后转化成系统服务对象给应用调用，而这些系统服务的Binder对象在系统启动的时候服务会自动注册到ServiceManager中。 服务大管家ServiceManager在整个远程服务调用过程中两个重要对象，一个是Binder对象，一个就是ServiceManager类，这个类是管理系统服务的类，他可以注册服务，查询服务，系统服务在系统启动的时候会通过addService进行服务注册，然后应用就可以通过getService进行服务查询，而在这个过程中，底层会维护一个这些服务的binder链表结构，同时每个服务的binder对象都一个句柄handle，通过这个句柄来表示通信标识，这样通信才不会紊乱。 底层通信核心Binder最后分析了底层真正实现跨进程通信的机制Binder，其实是通过虚拟驱动程序/dev/binder进行通信的。一个通信机制肯定有通信协议，传输的数据结构，但是这里并没有介绍这些知识，原因是我们后面的需求并不会用到这些，其次是这些知识点太详细介绍也不好，因为会越看越乱。 总结本文介绍的东东有点多，但是如果掌握了Android中的Binder机制和远程服务调用机制对后面拦截系统api做了铺垫，说到结束了才告诉大家为什么要介绍这个知识点，是因为最近在研究如何拦截系统启动Activity的事，那么就必须了解Activity的启动流程，但是在这个过程中有一个对象就是ActivityManagerService，而他就和Binder以及远程服务调用机制紧密联系了，如果不了解Binder机制，后面工作是没办法进行的，好了，说到最后再来一张神图算是总结了本文内容： 这张图非常好的表达了Android中应用使用系统服务的一个流程，也是最好的最全的解释了。看懂这张图之后，那么对Android中的binder机制和远程服务调用机制就可以掌握了，可以进行后续的拦截操作了。 参考文献：Android系统篇之—-Binder机制和远程服务调用机制分析 进击的Android注入术《五》 Android深入浅出之Binder机制 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/07/10/android-binder-principle2/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AIDL","slug":"aidl","permalink":"http://agehua.github.io/tags/aidl/"},{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"}]},{"title":"Android Binder机制分析（一）","slug":"android-binder-principle","date":"2017-07-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/07/08/android-binder-principle/","link":"","permalink":"http://agehua.github.io/2017/07/08/android-binder-principle/","excerpt":"背景分析最近在学习Android非侵入Hook机制，\n6月30日，360开源RePlugin，安卓进入“全面插件化”时代：https://www.itcodemonkey.com/article/278.html\n同一天，滴滴开源Android端插件化框架VirtualAPK：https://www.itcodemonkey.com/article/277.html\n然后本人发现竟然可以不在清单文件中注册就可以启动Activity，还有这种操作？哈哈。后面会有单独的文章介绍这种骚操作。\n在搜索中发现了这篇博客，Android系统篇之—-Binder机制和远程服务调用机制分析。本文大部分转载自原来博客，结合自己的分析，是研究Hook机制前的知识储备。\nAndroid中远程服务调用分析简单介绍，跨进程调用一个远程服务需要下面这几步：","text":"背景分析最近在学习Android非侵入Hook机制， 6月30日，360开源RePlugin，安卓进入“全面插件化”时代：https://www.itcodemonkey.com/article/278.html 同一天，滴滴开源Android端插件化框架VirtualAPK：https://www.itcodemonkey.com/article/277.html 然后本人发现竟然可以不在清单文件中注册就可以启动Activity，还有这种操作？哈哈。后面会有单独的文章介绍这种骚操作。 在搜索中发现了这篇博客，Android系统篇之—-Binder机制和远程服务调用机制分析。本文大部分转载自原来博客，结合自己的分析，是研究Hook机制前的知识储备。 Android中远程服务调用分析简单介绍，跨进程调用一个远程服务需要下面这几步： 1.定义一个AIDL文件：Demo.aidl 类似于定义接口类型，这个AIDL文件将在本地和远端都要使用到 package com.agehua.aidldemo;interface Demo &#123; int sendData(String data); String getData();&#125; 2.定义远程服务在远程服务中的onBind方法，实现AIDL接口的具体方法，并且返回Binder对象//远程服务，应该定义在另个一进程中public class DemoService extends Service &#123; @Override public IBinder onBind(Intent intent) &#123; //返回远程的Binder对象，并且实现类 return new Demo.Stub() &#123; @Override public int sendData(String data) throws RemoteException &#123; return 0; &#125; @Override public String getData() throws RemoteException &#123; return \"\"; &#125; &#125; &#125;&#125; 接口方法的具体传递实现都是在远端服务中。 3.本地创建连接对象本地创建一个服务连接对象，实现ServiceConnection接口，在连接成功之后，会得到一个远端传递过来的Binder对象，就是上面的远端服务onBind方法返回的，得到Binder对象之后在进行转化就可以得到AIDL对象，然后即可调用方法。 //连接远程服务的回调public class DemoConnection implements ServiceConnection &#123; @Override public void onServiceConnected(Component name, IBinder service) &#123; //连接成功后，会传递远端的Binder对象 Demo demo =Demo.Stub.asInterface(service); try &#123; demo.setData(\" \"); demo.getData(); &#125;catch (RemoteException e) &#123; e.printStackTrace(); &#125; &#125; @Override public void onServiceDisconnected(Component name) &#123; //断开连接 &#125;&#125; 连接成功后，从远端服务中获取到了Binder对象，然后在转化成本地接口对象，即可调用方法。 4、连接服务连接服务也是比较简单的，这时候把上面的连接对象传递进去即可 Intent intent = new Intent(this, DemoService.class);bindService(intent, new DemoConnection(), Context.BIND_AUTO_CREATE); AIDL实现机制分析上面的步骤就可以实现一个远程服务调用了。但是有一个核心的地方就是Demo.Stub类，这个类起着重要的作用，下面来分析一下它的实现： 每次定义了AIDL接口文件之后，编译一下就会在build/generated/source/目录中产生对应的java文件了： package com.agehua.aidldemo;//IInterface接口由AIDL类去实现。IInterface接口包含一个方法asBinder()public interface Demo extends android.os.IInterface &#123; /** * Local-side IPC implementation stub class. * 由Stub类实现Binder类和AIDL接口 */ public static abstract class Stub extends android.os.Binder implements com.agehua.aidldemo.Demo &#123; private static final java.lang.String DESCRIPTOR = \"com.agehua.aidldemo.Demo\"; public Stub() &#123; this.attachInterface(this, DESCRIPTOR); &#125; /** * Cast an IBinder object into an com.agehua.aidldemo.Demo interface, * generating a proxy if needed. * 将远端传过来的Binder对象转化成本地对象 */ public static com.agehua.aidldemo.Demo asInterface(android.os.IBinder obj) &#123; if ((obj == null)) &#123; return null; &#125; //如果本地进程和服务端都在一个进程中，那么直接返回当前类的IInterface android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) &amp;&amp; (iin instanceof com.agehua.aidldemo.Demo))) &#123; return ((com.agehua.aidldemo.Demo) iin); &#125; //如果本地进程和服务端不在一个进程中，则返回一个代理对象给客户端 return new com.agehua.aidldemo.Demo.Stub.Proxy(obj); &#125; @Override public android.os.IBinder asBinder() &#123; return this; &#125; //处理客户端发过来的请求方法，这里不详细展开了 @Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException &#123; switch (code) &#123; case INTERFACE_TRANSACTION: &#123; reply.writeString(DESCRIPTOR); return true; &#125; case TRANSACTION_sendData: &#123; data.enforceInterface(DESCRIPTOR); java.lang.String _arg0; _arg0 = data.readString(); int _result = this.sendData(_arg0); reply.writeNoException(); reply.writeInt(_result); return true; &#125; case TRANSACTION_getData: &#123; data.enforceInterface(DESCRIPTOR); java.lang.String _result = this.getData(); reply.writeNoException(); reply.writeString(_result); return true; &#125; &#125; return super.onTransact(code, data, reply, flags); &#125; //稍后分析这个类 private static class Proxy implements android.app.IServiceConnection &#123; /** ... **/ &#125; &#125; //Demo.aidl提供的方法，由Proxy类去实现，这里不用实现 public int sendData(java.lang.String data) throws android.os.RemoteException; //Demo.aidl提供的方法，由Proxy类去实现，这里不用实现 public java.lang.String getData() throws android.os.RemoteException;&#125; 1、AIDL接口必须实现IInterface接口IInterface接口包含一个asBinder()方法，由这个方法进行转化对象功能，把当前的AIDL对象转化成一个IBinder对象。package android.os;public interface IInterface&#123; /** * Retrieve the Binder object associated with this interface. * You must use this instead of a plain cast, so that proxy objects * can return the correct result. */ public IBinder asBinder();&#125; 2、AIDL接口中肯定有一个静态实现类Stub这个类必须实现Binder类，以及本身的AIDL接口类型。那么这个类就具备了Binder类中的四个功能： 1.可以将Binder对象转化成AIDL对象，调用asInterface方法，可以看到这个方法其实和上面的asBinder方法对立的 2.通信方法onTransact实现，这个方法是最核心的用于通信之间的逻辑实现 3.通过queryLocalInterface方法可以根据类的描述符(字符串可以唯一标识这个远端服务的名称即可)获取到对应的AIDL对象(其实是IInterface类型的) 4.在构造方法中必须调用Binder中的attachInterface方法把当前服务对象和描述符进行关联 3、Stub类只是中间者，由Proxy类生成服务端的代理 为什么说是由Proxy类生成服务端的代理的呢？ 因为在上面的DemoConnection类中，生成本地Demo对象，是调用了Demo.Stub.asInterface(IBinder)这个方法。前面提到，服务端和客户端不在同一个进程的时候，asInterface()方法实际上调用了Demo.Stub.Proxy(IBinder)这个方法。 而且Demo.aidl中定义的抽象方法，具体都是由Proxy类去实现的。 Stub类，其实只是远端服务Binder对象的一个中间者，下面看代码： //实现了aidl接口类。private static class Proxy implements com.agehua.aidldemo.Demo &#123; //保存了一个mRemote变量，这个变量就是由服务端传递过来的IBinder对象 private android.os.IBinder mRemote; Proxy(android.os.IBinder remote) &#123; mRemote = remote; &#125; @Override public android.os.IBinder asBinder() &#123; return mRemote; &#125; public java.lang.String getInterfaceDescriptor() &#123; return DESCRIPTOR; &#125; @Override public int sendData(java.lang.String data) throws android.os.RemoteException &#123; android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); int _result; try &#123; _data.writeInterfaceToken(DESCRIPTOR); _data.writeString(data); //调用Binder的transact()方法，会调用上面Stub类中的onTransact方法进一步处理 mRemote.transact(Stub.TRANSACTION_sendData, _data, _reply, 0); _reply.readException(); _result = _reply.readInt(); &#125; finally &#123; _reply.recycle(); _data.recycle(); &#125; return _result; &#125; @Override public java.lang.String getData() throws android.os.RemoteException &#123; android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); java.lang.String _result; try &#123; _data.writeInterfaceToken(DESCRIPTOR); //调用Binder的transact()方法，会调用上面Stub类中的onTransact方法进一步处理 mRemote.transact(Stub.TRANSACTION_getData, _data, _reply, 0); _reply.readException(); _result = _reply.readString(); &#125; finally &#123; _reply.recycle(); _data.recycle(); &#125; return _result; &#125;&#125; Proxy是Stub类中的一个静态类，Proxy对象就是远端传递过来的Binder对象在本地的代理。这里用到的是静态代理模式。 在服务连接成功后，在onServiceConnected()方法中，返回一个服务端Binder对象，本地通过asInterface()方法生成的一个代理；Demo demo = Demo.Stub.asInterface(IBinder); 这个demo对象，就是客户端这边用户和服务端交互的中间者。我们在前面的Stub类的asInterface()方法实现中可以看到： 借助queryLocalInterface()方法根据服务描述符来获取对象，会把远端传递过来的Binder对象转化成一个本地对象：public IInterface queryLocalInterface(String descriptor) &#123; if (mDescriptor.equals(descriptor)) &#123; return mOwner; &#125; return null;&#125; 而这个mOwner和mDescriptor之间的对应关系就在attachInterface方法中进行初始化的，也就是在Stub类的构造方法中public void attachInterface(IInterface owner, String descriptor) &#123; mOwner = owner; mDescriptor = descriptor;&#125; 那么现在就清楚了，如果客户端和服务端是在一个进程中，那么其实queryLocalInterface获取的就是Stub对象，如果不在一个进程queryLocalInterface查询的对象肯定为null，因为new Demo.Stub()和Demo.Stub.asInterface(IBinder)方法分别是在远端进程和本地进程中调用的，在不同进程有不同虚拟机，肯定查不到mOwner对象的，所以这时候其实是返回的Proxy对象了。 通过上面的讲解之后，发现多进程服务通信基准就是借助Binder对象，先传递Binder对象，然后在把Binder转成可以使用的原生对象即可调用了，而对于Stub类和Proxy类其实就是相当于是服务端和客户端的中间者，把一些逻辑封装起来，这种设计也会显得不是那么凌乱： 分析系统服务调用流程其实系统中的一些服务使用的时候其实也是跨进程使用，比如下面来看一下著名的PackageManager，IPackageManager，PackageManagerService体系： PackageManagerService是Android系统中最常用的服务之一。它负责系统中Package的管理，应用程序的安装、卸载、信息查询等。PackageManager获取的信息即来自AndroidManifest.XML interface IPackageManager &#123; boolean isPackageAvailable(String packageName, int userId); PackageInfo getPackageInfo(String packageName, int flags, int userId); int getPackageUid(String packageName, int userId); int[] getPackageGids(String packageName); String[] currentToCanonicalPackageNames(String[] names); String[] canonicalToCurrentPackageNames(String[] names); PermissionInfo getPermissionInfo(String name, int flags) ParceledListSlice&lt;PermissionInfo&gt; queryPermissionsByGroup(String group, int flags) //...&#125; 上面代码在谷歌的源码中查到，详情点击链接 因为我们还没有编译源码，所以看不到IPackageManager.java，这里可能需要AIDL工具单独编译才能看到了：public interface IPackageManager extends android.os.IInterface &#123; //定义内部类Stub，派生自Binder，实现IPackageManager接口 public static abstract class Stub extends android.os.Binder implements android.content.pm.IPackageManager &#123; private static final java.lang.String DESCRIPTOR = \"android.content.pm.IPackageManager\"; publicStub() &#123; this.attachInterface(this,DESCRIPTOR); &#125; //...... //定义Stub的内部类Proxy，实现IPackageManager接口 private static class Proxy implements android.content.pm.IPackageManager&#123; //通过mRemote变量和服务端交互 private android.os.IBinder mRemote; Proxy(android.os.IBinderremote) &#123; mRemote = remote; &#125; //...... &#125; //......&#125; 这里看到了熟悉的远端服务中间者Stub和本地端的中间者Proxy类了，而这两个类的规则都和上面一样的。 下面来看一下远端服务实现代码PackageManagerService.java，(这个类就可以在IDE中看到了)：public class PackageManagerService extends IPackageManager.Stub &#123; static final String TAG = \"PackageManager\"; static final boolean DEBUG_SETTINGS = false; static final boolean DEBUG_PREFERRED = false; static final boolean DEBUG_UPGRADE = false; static final boolean DEBUG_DOMAIN_VERIFICATION = false; //...&#125; 实现了上面的的Stub类功能。 下面我们再走一遍获取PackageManager的流程：PackageManager pm = getPackageManager(); 而这个getPackageManager方法是在ContextImpl.java中实现的： @Overridepublic PackageManager getPackageManager() &#123; if (mPackageManager != null) &#123; return mPackageManager; &#125; IPackageManager pm = ActivityThread.getPackageManager(); if (pm != null) &#123; // Doesn't matter if we make more than one instance. return (mPackageManager = new ApplicationPackageManager(this, pm)); &#125; return null;&#125; 具体内容实现是在ActivityThread.getPackageManager()方法中：public static IPackageManager getPackageManager() &#123; if (sPackageManager != null) &#123; //Slog.v(\"PackageManager\", \"returning cur default = \" + sPackageManager); return sPackageManager; &#125; IBinder b = ServiceManager.getService(\"package\"); //Slog.v(\"PackageManager\", \"default service binder = \" + b); sPackageManager = IPackageManager.Stub.asInterface(b); //Slog.v(\"PackageManager\", \"default service = \" + sPackageManager); return sPackageManager;&#125; 看到了吧，IPackageManager.Stub.asInterface(b)中的参数b由ServiceManager.getService方法获取到。然后在使用Stub的asInterface方法进行转化成本地的PackageManager对象，其实就是那个Proxy对象。然后就可以通过PackageManager来调用方法和远端的PackageManagerService服务进行通信了。 而DemoService是在DemoConnection（继承自ServiceConnection）的onServiceConnected回调中得到远端的IBinder对象，然后获得Proxy对象。 这里与自定义远程服务然后调用的区别就是，系统的远程服务都是由ServiceManager保存的，也就是由系统去创建和管理；而自定义的远程服务由开发者去创建、维护和销毁 通过上面的PackageManager案例可以分析，我们在使用系统中的服务的时候的流程都是如此： 总结一下，每个应用在使用系统服务的时候，都会走这么几步： 1、调用getService(String serviceName)方法获取服务对象 2、而getSystemService一般都是在ContextImpl类中实现的，其实是调用了ServiceManager的getService方法 3、调用ServiceManager的getService方法获取远端服务的IBinder对象 4、有了远端服务的IBinder对象之后，在使用远端服务的中间者类Stub进行转化对象asInterface方法 5、因为系统中的服务获取都是肯定是跨进程的，远端服务都是在system_server进程中的，所以asInterface方法中返回的是Proxy代理对象，也就是本地端的中间者。 6、最后返回的对象其实就是这个Proxy对象，而这个对象内部使用了静态代理方式，内部有一个来自远端的mRemote变量即IBinder对象。然后直接调用方法其实就是调用mRemote的transact方法进行通信了。 所以在这个过程中可以看到有两个对象很重要，一个是ServiceManager，一个是IBinder对象。下篇文章再来一一介绍 参考文献： Android系统篇之—-Binder机制和远程服务调用机制分析 《Android上玩玩Hook？》: http://blog.csdn.net/yzzst/article/details/47318751 《进击的Android注入术&lt;一&gt;》:http://blog.csdn.net/l173864930/article/details/38455951 极客学院——深入理解Android卷②：http://wiki.jikexueyuan.com/project/deep-android-v2/powermanagerservice.html 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/07/08/android-binder-principle/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"AIDL","slug":"aidl","permalink":"http://agehua.github.io/tags/aidl/"},{"name":"Binder","slug":"binder","permalink":"http://agehua.github.io/tags/binder/"}]},{"title":"Handler替代TimerTask","slug":"handler-replace-timertask","date":"2017-05-17T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/05/18/handler-replace-timertask/","link":"","permalink":"http://agehua.github.io/2017/05/18/handler-replace-timertask/","excerpt":"Handler替代TimerTask原文来自：http://www.mopri.de/2010/timertask-bad-do-it-the-android-way-use-a-handler/\n作者文中提到，使用TimerTask更新GUI，debug看起来可以，但实际上根本不起作用。同时作者发现，使用handler可以得到更好的表现。\n下面是一个例子，使用handler在100ms后启动一个Runnable:private Handler handler = new Handler();handler.postDelayed(runnable, 100);\n下面代码里有一个小技巧，实现每隔100ms运行一次Runnable，就像TimerTask的scheduleAtFixedRate()方法:","text":"Handler替代TimerTask原文来自：http://www.mopri.de/2010/timertask-bad-do-it-the-android-way-use-a-handler/ 作者文中提到，使用TimerTask更新GUI，debug看起来可以，但实际上根本不起作用。同时作者发现，使用handler可以得到更好的表现。 下面是一个例子，使用handler在100ms后启动一个Runnable:private Handler handler = new Handler();handler.postDelayed(runnable, 100); 下面代码里有一个小技巧，实现每隔100ms运行一次Runnable，就像TimerTask的scheduleAtFixedRate()方法: private Runnable runnable = new Runnable() &#123; @Override public void run() &#123; /* do what you need to do */ foobar(); /* and here comes the \"trick\" */ handler.postDelayed(this, 100); &#125;&#125;; 如何取消运行Runnable呢？只需要调用handler.removeCallback(runnable)就可以了。 这样做还有另一个有点，就是不用总是new Timer(Task)了，可以重复使用上面代码中的handler和runnable。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/05/18/handler-replace-timertask/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"TimerTask","slug":"timertask","permalink":"http://agehua.github.io/tags/timertask/"},{"name":"handler","slug":"handler","permalink":"http://agehua.github.io/tags/handler/"}]},{"title":"Android架构师积累","slug":"Object-Oriented","date":"2017-05-10T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/05/11/Object-Oriented/","link":"","permalink":"http://agehua.github.io/2017/05/11/Object-Oriented/","excerpt":"Android架构师积累 ——By 高焕堂“-Oriented”的涵意◎ ”-Oriented”意味着一种信仰 。◎ ”Object-oriented”相信任何软件都是由对象所构成的，而且Nothing else 。\n”-Driven”的涵意; 例如:Model-driven、Use Case-driven– 其实”-driven”是”引导”，而不是大家常说的”驱动”。– 就向北极星引导我们，指出方向而已。也像汽车司机(Driver)只是引导汽车方向，并没有去驱动汽车;而是引擎才是驱动汽车。\n“-Centered”的涵意; 例如:Architecture-centered、 Architecture-centeric–一切软件开发的活动都围绕着架构，就像盛诞节的糖果和礼物都挂在圣诞树上一样。\n卡榫函数• 所谓「卡榫(Hook)」，就是用来接合两个东西的接口。如果两个东西于不同时间出现，则一方会预留虚空，给予另一边于未来时刻能以实体来填补该空间，两者虚实相依，就密合起来了。设计优良的卡榫，可以让实体易于新陈代谢、抽换自如(Plug and Play, 俗称PnP)。","text":"Android架构师积累 ——By 高焕堂“-Oriented”的涵意◎ ”-Oriented”意味着一种信仰 。◎ ”Object-oriented”相信任何软件都是由对象所构成的，而且Nothing else 。 ”-Driven”的涵意; 例如:Model-driven、Use Case-driven– 其实”-driven”是”引导”，而不是大家常说的”驱动”。– 就向北极星引导我们，指出方向而已。也像汽车司机(Driver)只是引导汽车方向，并没有去驱动汽车;而是引擎才是驱动汽车。 “-Centered”的涵意; 例如:Architecture-centered、 Architecture-centeric–一切软件开发的活动都围绕着架构，就像盛诞节的糖果和礼物都挂在圣诞树上一样。 卡榫函数• 所谓「卡榫(Hook)」，就是用来接合两个东西的接口。如果两个东西于不同时间出现，则一方会预留虚空，给予另一边于未来时刻能以实体来填补该空间，两者虚实相依，就密合起来了。设计优良的卡榫，可以让实体易于新陈代谢、抽换自如(Plug and Play, 俗称PnP)。 • 变与不变的分离(Separate code that changes from the code that doesn’t)是设计卡榫(Hook)函数及应用框架之基本原则和手艺。• 分离出变(Variant)与不变(Invariant)部份之后，就可以将不变部份写在父类别(Super- class)里，而变的部份就写在子类别 (Subclass)里。 在Java里，使用抽象(abstract)函数或可覆写(overridable)函数来实现卡榫函数。 IoC机制与Default函数卡榫函数实现IoC机制• 控制反转(IoC: Inversion of Control)• IoC机制源自于OO语言(如C++等)的类别 继承体系，例如C++语言中，基类的函数可以主动调用子类的函数，这就是典型的IoC机制• 基类与子类之间，主控权是在基类手上， 透过Hook函数来调用子类• 通常基类是撰写在先，而子类则撰写在后， 这种前辈拥有主导权，进而「控制」后辈 之情形，就通称为「控制反转」。 默认(Default)行为• 基类的重要功能:提供默认(预设)行为• 基类可事先定义许多「默认」(Default)函数。这些默认函数可让子类来继承(或调用)之。 interface IShape &#123; void template_paint(Graphics gr);&#125; // 一般接口 // Shape.javaimport java.awt.*;public abstract class Shape implements IShape &#123; public void template_paint(Graphics gr)&#123; //默认行为 invariant_paint(gr); //画背景 hook_paint(gr); //画前景 &#125; private void invariant_paint(Graphics gr)&#123; gr.setColor(Color.black); gr.fillRect(10,30, 200,100); &#125; abstract protected void hook_paint(Graphics gr);&#125; // Bird.javaimport java.awt.*;public class Bird extends Shape &#123; private void hook_paint(Graphics gr)&#123; //控制反转 gr.setColor(Color.cyan); gr.drawArc(30,80,90,110,40,100); gr.drawArc(88,93,90,100,40,80); gr.setColor(Color.white); gr.drawArc(30,55,90,150,35,75); gr.drawArc(90,80,90,90,40,80); &#125;&#125; 在Android中，子类Activity继承父类Activity，需要重写onCreate()方法，onCreate()方法就是基类主动调用，这也是IOC机制 认识EIT造形 有了架构设计造形的&lt;简单性&gt;，人们就很容易理解软件的复杂关系，进而提升了掌握软件系统复杂多变的能力，唯有熟谙此道，才能创造架构和产品的&lt;未来性&gt;。 高焕堂老师提出简单的EIT软件造形；则让人们能理解Android多层框架体系里的复杂关系 EIT造形是一种基本的结构(Structure)，一种概念(Concept)；我们称它为”EIT造形(Form)”。 强龙做&lt;E&amp;I&gt;，将&lt;T&gt;外包给地头蛇。 强龙掌控&lt;E&amp;I&gt;，外包就不会失控。 所以EIT造形支持当今主流的外包模式。 题目演练：由提供一个值N，由&lt;T&gt;通过不同的算法，如1+2+3+ … + N或1+2^2+ … + N^2进行计算，最后将计算结果传递给&lt;E&gt;。 现在可以试试先想想接口&lt;I&gt;设计:1.&lt;T&gt;必须有个抽象函数，被&lt;T&gt;反向调用(IoC)到&lt;T&gt;。在调用该函数时，顺便把&lt;E&gt;里的N值传递下去给&lt;T&gt;。2.由&lt;T&gt;进行计算工作，然后将计算结果传回给&lt;E&gt;。3.不同的算法就对应不同的&lt;T&gt;类 代码实现如下：//Counter.java，这就对应接口&lt;I&gt;public abstract class Counter &#123; public int run()&#123; int N = getCount(); return onCal(N); &#125; public int getCount() &#123; return 6; &#125; protected abstract int onCal(int n);&#125; //myCounter.java，是&lt;T&gt;类的一种算法public class myCounter extends Counter&#123; @Override protected int onCal(int n) &#123; int sum = 0; for(int i=1; i&lt;=n; i++) &#123; sum += i; &#125; return sum; &#125;&#125; //在&lt;E&gt;类中，调用方式如下counter = new myCounter();int sum = counter.run(); 框架(或架构)设计的关键任务就是接口(Interface)设计，这项接口是框架&lt;E&gt;与插件&lt;T&gt;之间的接口，这就是所谓的：框架API。 IPCIPC(Inter-Process Communication)通信， 是跨越两个不同进程(Process)之通信 IPC通信的效率 当我们启动某一支应用程序(App)时， Android系统里的Zygote服务孵化(Fork)一个新进程(Process)给它，然后将它(该App)加载到这个新诞生的进程里。 基于Linux的安全限制，以及进程的基本特性(例如，不同进程的地址空间是独立的)，如果两个类(或其对象)在同一个进程里执行时，两者沟通方便也快速 。 但是，当它们分别在不同的进程里执行时，两者沟通就属于IPC跨进程沟通了，不如前者方便，也慢些 一个进程是一个独立的执行空间，不会被正在其它进程里的程序所侵犯。这种保护方法是Android的重要安全机制。于是，得先认识进程的内涵，才能进一步了解跨进 程IPC机制。 在Android的进程里，有一个虚拟机(Virtual Machine，简称VM)的对象，可执行Java代码，也引导JNI本地程序的执行，实现Java与C/C++之间的沟通。如下图: 不同进程的地址空间是独立的 每一个进程在诞生时，都会诞生一个主线程(Main Thread)，以及诞生一个Looper类的对象和一个MQ(Message Queue)数据结构。每当主线程作完事情，就会去执行Looper类。 主线程最主要的工作就是处理UI画面的事件(Event)，每当UI事件发生时，Android框架会丢信息(Message)到MQ里。主线程看到MQ有新的信息时，就取出信息，然后依据信息内容而去执行特定的函数。执行完毕，就再继续执行Looper类，不断地观察MQ的动态。 IPC的IBinder接口 – 定义与实现大家都知道，当两个类都在同一个进程里执行时，两者之间的沟通，只要采取一般的函数调用(Function Call)就行了，既快速又方便。一旦两个类分别在不同的进程里执行时，两者之间的沟通，就不能采取一般的函数调用途径了。只好采取IPC沟通途径。 Android框架的IPC沟通仰赖单一的IBinder接口。此时Client端调用IBinder接口的transact()函数，透过IPC机制而调用到远方(Remote)的onTransact()函数。 Java层的IBinder 接口是定义于IBinder.java代码文档里// IBinder.java// .......public interface IBinder &#123;// ........public boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException; // ...........&#125; IBinder接口定义了一些函数，可以让Client程序可以进行跨进程的调用(当然也能支持同进程的短程调用)。其中，最主要的一个函数就是: transact()函数 在Android的框架里，由Binder基类实现IBinder接口。 Binder基类的很重要目的是支持跨进程调 用Service，也就是让远程的Client可以跨 进程调用某个Service。Binder基类定义于Binder.java文件里:// Binder.java// .......public class Binder implements IBinder &#123; // .......... private int mObject; public Binder() &#123; init(); // ........... &#125; //用来实现IBinder的transact()函数接口 public final boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException &#123; // ................ boolean r = onTransact(code, data, reply, flags); return r; &#125; //其角色与transact()函数是相同的，只是这是用来让C/C++本地程序来调用的。 private boolean execTransact(int code, int dataObj, int replyObj, int flags) &#123; Parcel data = Parcel.obtain(dataObj); Parcel reply = Parcel.obtain(replyObj); boolean res; res = onTransact(code, data, reply, flags); // ............ return res; &#125; //这是一个抽象函数，让应用子类来覆写(Override)的. //上述的transact()和 execTransact()两者都是调用onTransact()函数来实现反向调用(IoC, Inversion of Control)的。 protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException &#123; &#125; //这是一个本地(Native)函数，让JNI模块来实现这个函数. //Binder()构造函数会调用这个init()本地函数 private native final void init();&#125; Binder就是EIT造形里的&lt;E&gt; 这个IBinder接口是Binder(即&lt;E&gt;)提供给Client的接口，简称为&lt;CI&gt; onTransact()就是EIT造形里的&lt;I&gt;，是支持&lt;基类/子类&gt;之间IoC调用的接口 示例：有一个Activity类别，它想跨进程去调用MediaPlayer播放引擎，以便播放MP3音乐. 类结构图如下： 在上图里，从myActivity到IBinder接口，画上了虚线箭头，表示那是抽象概念的。实际上，myActivity并没有直接调用Java层的IBinder接口，而是绕到底层C/C++和Binder驱动而间接调用到Binder基类的execTransact()函数，转而调用myBinder的onTransact()函数。如下图: IPC通信的三步骤还是用上面的MediaPlayer例子，其IPC通信的三个步骤是: Step-1. Activity使用startService()函數來启动Service。 Step-2. Activity调用bindService()来绑定Service。亦即，Activity建立与Service之间的连结(Connection)。 Step-3. Activity调用IBinder接口的transact() 函数，透过底层Binder Driver驱动而间接调用到Binder基类的execTransact()函数， 转而调用 myBinder的onTransact()函数。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/05/11/Object-Oriented/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Android Framework","slug":"android-framework","permalink":"http://agehua.github.io/tags/android-framework/"},{"name":"EIT","slug":"eit","permalink":"http://agehua.github.io/tags/eit/"},{"name":"Object-oriented","slug":"object-oriented","permalink":"http://agehua.github.io/tags/object-oriented/"}]},{"title":"注解在Android中的应用","slug":"Annotation-Android-usage","date":"2017-04-09T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/04/10/Annotation-Android-usage/","link":"","permalink":"http://agehua.github.io/2017/04/10/Annotation-Android-usage/","excerpt":"注解是Java语言的特性之一，它是在源代码中插入标签，这些标签在后面的编译或者运行过程中起到某种作用，每个注解都必须通过注解接口 @Interface 进行声明，接口的方法对应着注解的元素。\n在上一篇文章JSR-330和assertion(断言)介绍中介绍了Java中的JSR-330 规范，这个规范就是使用注解的方式。\n这篇文章主要介绍注解在Android中的应用。\nAndorid中的应用JSR-330规范只发布了规范 API 源码，主要是面向依赖注入使用者，而对注入器实现、配置并未作详细要求。该规范主要配合依赖注入框架来使用。在Android中的依赖注入框架有 ButterKnife 和 Dagger2。下面简单分析 ButterKnife 的应用。","text":"注解是Java语言的特性之一，它是在源代码中插入标签，这些标签在后面的编译或者运行过程中起到某种作用，每个注解都必须通过注解接口 @Interface 进行声明，接口的方法对应着注解的元素。 在上一篇文章JSR-330和assertion(断言)介绍中介绍了Java中的JSR-330 规范，这个规范就是使用注解的方式。 这篇文章主要介绍注解在Android中的应用。 Andorid中的应用JSR-330规范只发布了规范 API 源码，主要是面向依赖注入使用者，而对注入器实现、配置并未作详细要求。该规范主要配合依赖注入框架来使用。在Android中的依赖注入框架有 ButterKnife 和 Dagger2。下面简单分析 ButterKnife 的应用。 关于依赖注入框架的好处，我理解 1.可以减少样板类代码，比如 Setter 方法。2.程序运行期间，可以将某种依赖关系动态注入到对象中，实现懒加载（需要的时候才会去加载）。 ButterKnifeButterKnife从严格意义上讲不算是依赖注入框架，它只是专注于Android 系统的VIew注入框架，并不支持其他方面的注入。它可以减少大量 findViewById 以及 setOnClickListener 代码。 ButterKnife用到了编译时注解，因为它需要依赖 android-apt 插件//project 的 build.gradle dependencies &#123; ... classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'&#125;//Module:app 的 build.gradledependencies &#123; ... compile 'com.jakewharton:butterknife:8.4.0' apt 'com.jakewharton:butterknife-compiler:8.4.0'&#125; 关于 android-apt 插件后面会介绍。 ButterKnife提供的注解有： 绑定控件：@BindView 绑定资源：@BindString、@BindArray、@BindBool、@BindColor、@BindDimen、@BindDrawable、@BindBitmap。 绑定监听：@OnClick、@OnLongClick、@OnTextChanged、@OnTouch 可选绑定：@Nullable @Nullable用于@BindView或其他的注解操作符，如果找不到目标时，避免引发异常，例如：@Nullable@BindView(R.id.tv_title)TextView tvTitle; ButterKnife原理解析前面提到ButterKnife使用的是编译时注解，先看看最常用的@BindView注解的源码： @Retention (RetentionPolicy.Class)@Target (ElementType.FIELD)public @interface BindView &#123; int value();&#125; @interface 声明会创建一个实际的Java接口，与其他任何接口一样，注解也会编译成.class文件。@Retention 和@Target 下面会介绍到。 关于ButterKnife更多源码分析，请看这篇文：butterknife 源码分析 Java注解的分类Java API中默认定义的注解叫做标准注解。它们定义在java.lang、java.lang.annotation和javax.annotation包中。按照使用场景不同，可以分为如下三类： 编译相关注解编译相关的注解是给编译器使用的，有以下几种： @Override：编译器检查被注解的方法是否真的重载了一个来自父类的方法，如果没有，编译器会给出错误提示。 @Deprecated：可以用来修饰任何不再鼓励使用或已被弃用的属性、方法等。 @SuppressWarnings：可用于除了包之外的其他声明项中，用来抑制某种类型的警告。 @SafeVarargs：用于方法和构造函数，用来断言不定长参数可以安全使用 @Generated：一般是给代码生成工具使用，用来表示这段代码不是开发者手动编写的，而是工具生成的。被@Generated修饰的代码一般不建议手动修改它。 @FunctionalInterface：用来修饰接口，表示对应得接口是带单个方法的函数式接口 资源相关注解一共有四个，一帮用在JavaEE领域，Android开发中应该不会用到，就不在详细介绍\b了。分别是： @PostConstruct @PreDestroy @Resource @Resources 元注解Butterknife的Bind注解用到的就是元注解。 元注解，顾名思义，就是用来定义和实现注解的注解，总共有如下五种： @Retention, 用来指明注解的访问范围，也就是在什么级别保留注解，有三种选择： 源码级注解：使用@Retention(RetentionPolicy.SOURCE)修饰的注解，该类型修饰的注解信息只会保留在 .java源码里，源码经过编译后，注解信息会被丢弃，不会保留在编译好的 .class文件中。 编译时注解：使用@Retention(RetentionPolicy.CLASS)修饰的注解，该类型的注解信息会保留在 .java源码里和 .class文件里，在执行的时候会被Java虚拟机丢弃，不会加载到虚拟机中。 运行时注解：使用@Retention(RetentionPolicy.RUNTIME)修饰的注解，Java虚拟机在运行期间也保留注解信息，可以通过反射机制读取注解的信息未指定类型时，默认是CLASS类型。 @Target, 这个注解的取值是一个ElementType类型的数组，用来指定注解所使用的对象范围，共有十种不同的类型，如下表所示，同时支持多种类型共存，可以进行灵活的组合。 元素类型 适用于 ANNOTATION_TYPE 注解类型声明 CONSTRUCTOR 构造函数 FIELD 实例变量 LOCAL_VARIABLE 局部变量 METHOD 方法 PACKAGE 包 PARAMETER 方法参数或者构造函数的参数 TYPE 类（包含enum）和接口（包含注解类型） TYPE_PARAMETER 类型参数 TYPE_USE 类型的用途 如果一个注解的定义没有使用@Target修饰，那么它可以用在除了TYPE_USE和TYPE_PARAMETER之外的其他类型声明中 @Inherited, 表示该注解可以被子类继承的。 @Documented, 表示被修饰的注解应该被包含在被注解项的文档中（例如用JavaDoc生成的文档） @Repeatable, 表示这个注解可以在同一个项上面应用多次。不过这个注解是在Java 8中才引入的，前面四个元注解都是在Java 5中就已经引入。 运行时注解前面说过，要定义运行时注解只需要在声明注解时指定 @Retention(RetentionPolicy.RUNTIME)即可，运行时注解一般和反射机制配合使用。 熟悉java反射机制的同学一定对java.lang.reflect包非常熟悉，该包中的所有api都支持读取运行时Annotation的能力。相比编译时注解性能比较低，但灵活性好，实现起来比较简单。 Butterknife在较低版本依然是通过运行时反射实现View的注入，性能较低下，不过在8.0.0版本以后使用编译时注解来提升性能。 运行时注解的简单使用下面展示一个Demo。其功能是通过注解实现布局文件的设置。 之前我们是这样设置布局文件的： @Overrideprotected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); setContentView(R.layout.activity_home);&#125; 如果使用注解，我们就可以这样设置布局了 @ContentView(R.layout.activity_home)public class HomeActivity extends BaseActivity &#123; ...&#125; 我们先不讲这两种方式哪个好哪个坏，我们只谈技术不谈需求。 那么这样的注解是怎么实现的呢？很简单，往下看。 创建一个注解@Retention(RetentionPolicy.RUNTIME)@Target(&#123;ElementType.TYPE&#125;)public @interface ContentView &#123; int value();&#125; 前面已经讲过元注解，这不不再介绍。 对于：public @interface ContentView 这里的interface并不是说ContentView是一个接口。就像申明类用关键字class。申明枚举用enum。申明注解用的就是@interface。 （值得注意的是：在ElementType的分类中，class、interface、Annotation、enum同属一类为ElementType.Type，并且从官方注解来看，interface是包含@interface的） /** Class, interface (including annotation type), or enum declaration */TYPE, 对于：int value(); 返回值表示这个注解里可以存放什么类型值。比如我们是这样使用的@ContentView(R.layout.activity_home) R.layout.activity_home 实质是一个int型id，如果这样用就会报错： @ContentView(“string”) 关于注解的具体语法，可以看这篇文章Android编译时注解框架-语法讲解 注解解析注解申明好了，但具体是怎么识别这个注解并使用的呢？@ContentView(R.layout.activity_home)public class HomeActivity extends BaseActivity &#123; ...&#125; 注解的解析就在BaseActivity中。我们看一下BaseActivity代码public class BaseActivity extends AppCompatActivity &#123; @Override protected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); //注解解析 for (Class c = this.getClass(); c != Context.class; c = c.getSuperclass()) &#123; ContentView annotation = (ContentView) c.getAnnotation(ContentView.class); if (annotation != null) &#123; try &#123; this.setContentView(annotation.value()); &#125; catch (RuntimeException e) &#123; e.printStackTrace(); &#125; return; &#125; &#125;&#125; 解释下上面的代码： 第一步：遍历所有的子类 第二步：找到修饰了注解ContentView的类 第三步：获取ContentView的属性值。 第四步：为Activity设置布局。 总结：要定义运行时注解，只需要在声明注解时指定@Retention(RetentionPolicy.RUNTIME)即可，运行时注解一般和反射机制配合使用，相比编译时注解性能比较低，但实现比较简单，会提高一定的开发效率。 编译时注解编译时注解能够自动处理Java源文件并生成更多的源码、配置文件、脚本或其他可能想要生成的东西。这些操作是通过注解处理器（Annotation Processor Tool）完成的。Java通过在编译期间调用 javac -processor命令可以调起注解处理器，它能够实现编译时注解的功能。 注解处理器其实是在javac开始编译之前，以java源码文件或编译后的class文件作为输入，然后输出另一些文件，可以是.java文件，也可以是.class文件，但通常我们输出的是.java文件，这些.java文件回合其他源码文件一起被javac编译，从而提高函数库的性能。 定义注解处理器自定义编译时注解后，需要编写Processor类实现注解处理器，处理自定义注解。Processor继承自AbstractProcessor类并实现process方法，同时需要指定注解处理器能够处理的注解类型以及支持的Java版本，语句如下： public class JsonAnnotationProcessor extends AbstractProcessor &#123; @Override public synchronized void init(ProcessingEnvironment env)&#123; super.init(env); //初始化方法，会被注解处理工具调用，并传入ProcessingEnvironment类型参数， //这个参数包含了很多工具类，如Elements、Types、Filer等 elementUtils = env.getElementUtils(); typeUtils = env.getTypeUtils(); filer = env.getFiler(); &#125; @Override public Set&lt;String&gt; getSupportedAnnotationTypes() &#123; //指定这个注解处理器能够处理的注解类型，返回一个支持的类型字符串合集 return super.getSupportedAnnotationTypes(); &#125; @Override public SourceVersion getSupportedSourceVersion() &#123; //指定注解处理器使用的Java版本 return SourceVersion.latestSupported(); &#125; @Override public boolean process(Set&lt;? extends TypeElement&gt; annotations, RoundEnvironment roundEnv) &#123; //在这个方法中实现注解处理器的具体业务逻辑，根据输入参数roundEnv可以得到包含特定注解的被注解元素 //下面代码是Butterknife中这个方法的源码 Map&lt;TypeElement, BindingClass&gt; targetClassMap = findAndParseTargets(env); for (Map.Entry&lt;TypeElement, BindingClass&gt; entry : targetClassMap.entrySet()) &#123; TypeElement typeElement = entry.getKey(); BindingClass bindingClass = entry.getValue(); try &#123; JavaFileObject jfo = filer.createSourceFile(bindingClass.getFqcn(), typeElement); Writer writer = jfo.openWriter(); writer.write(bindingClass.brewJava()); writer.flush(); writer.close(); &#125; catch (IOException e) &#123; error(typeElement, \"Unable to write view binder for type %s: %s\", typeElement, e.getMessage()); &#125; &#125; //返回值 表示这组 annotations 是否被这个 Processor 接受， //如果接受（true）后续子的 pocessor 不会再对这个 Annotations 进行处理 return true; &#125; //Butterknife源码：RoundEnvironment表示当前或是之前的运行环境，可以通过该对象查找找到相应的注解。 private Map&lt;TypeElement, BindingClass&gt; findAndParseTargets(RoundEnvironment env) &#123; Map&lt;TypeElement, BindingClass&gt; targetClassMap = new LinkedHashMap&lt;TypeElement, BindingClass&gt;(); Set&lt;String&gt; erasedTargetNames = new LinkedHashSet&lt;String&gt;(); // Process each @Bind element. for (Element element : env.getElementsAnnotatedWith(Bind.class)) &#123; //所有被使用的@Bind注解 try &#123; parseBind(element, targetClassMap, erasedTargetNames); &#125; catch (Exception e) &#123; logParsingError(element, Bind.class, e); &#125; &#125; ...... &#125; &#125; 一个注解处理器，只能产生新的源文件，它不能够修改一个已经存在的源文件。当没有属于该Process处理的注解被使用时，process不会执行。 从Java7 开始，我们也可以使用注解来代替上面的getSupportedAnnotationTypes()和getSupportedSourceVersion()方法，代码如下：@SupportedAnnotationTypes(&#123; //该注解处理器支持的所有注解全名&#125;)@SupportedSourceVersion(SourceVersion.RELEASE_7)public class ContentViewProcessor extends AbstractProcessor &#123; ...&#125; Element类型所有通过注解取得元素都将以Element类型等待处理，也可以理解为Element的子类类型与自定义注解时用到的@Target是有对应关系的。 Element的官方注释：Represents a program element such as a package, class, or method.Each element represents a static, language-level construct (and not, for example, a runtime construct of the virtual machine). 表示一个程序元素，比如包、类或者方法。 Element的子类有： ExecutableElement表示某个类或接口的方法、构造方法或初始化程序（静态或实例），包括注释类型元素。对应@Target(ElementType.METHOD) @Target(ElementType.CONSTRUCTOR) PackageElement表示一个包程序元素。提供对有关包极其成员的信息访问。对应@Target(ElementType.PACKAGE) TypeElement表示一个类或接口程序元素。提供对有关类型极其成员的信息访问。对应@Target(ElementType.TYPE) 注意：枚举类型是一种类，而注解类型是一种接口。 TypeParameterElement表示一般类、接口、方法或构造方法元素的类型参数。对应@Target(ElementType.PARAMETER) VariableElement表示一个字段、enum常量、方法或构造方法参数、局部变量或异常参数。对应@Target(ElementType.LOCAL_VARIABLE) Processor输出日志虽然是编译时执行Processor,但也是可以输入日志信息用于调试的。Processor日志输出的位置在编译器下方的Messages窗口中。Processor支持最基础的System.out方法。 同样Processor也有自己的Log输出工具: Messager。//同样是Butterknife源码private void error(Element element, String message, Object... args) &#123; if (args.length &gt; 0) &#123; message = String.format(message, args); &#125; processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR, message, element);&#125; 注册注解处理器为了让javac -processor能够对定义好的注解处理进行处理，我们需要将注解处理器打包到一个jar文件中，同时，需要在jar文件中增加一个名为javax.annotation.processing.processor的文件来指明jar文件中有哪些注解处理器，这个文件最终目录在jar文件根目录的META-INF/service目录中，jar文件解压后的目录结构如下图： javax.annotation.processing.Processor文件的内容是注解处理器全路径名，如果存在多个注解处理器，以换行进行分隔，代码看图片 源文件的目录是，我们需要在src/main/java同级目录中新建一个名为resources的目录，将META-INF/services/javax.annotation.processing.Processor文件放进去就行 注意，注解处理器所在的Android Studio工程必须是Java Library类型，而不应该是Android Library类型。因为Android Library的JDK中不包含某些javax包里面的类。 手动实现上面注册过程很繁琐，因此Google开源了一个名为AutoService的函数库，使用这个库后，只需在自定义Processor时使用@AutoService注解标记即可完成上面注册步骤。 @AutoService(Processor.class)@SupportedAnnotationTypes(&#123; //该注解处理器支持的所有注解全名&#125;)@SupportedSourceVersion(SourceVersion.RELEASE_7)public class ContentViewProcessor extends AbstractProcessor &#123; ...&#125; android-apt插件注解处理器所在的jar文件只能在编译期间起作用，到应用运行时不会用到，因此，在build.gradle中引入依赖时应该以provided方式，而不是compile方式引入。 当然，我们可以使用android-apt插件的方式。 android-apt是由一位开发者自己开发的apt框架，源代码托管在这里，随着Android Gradle 插件 2.2 版本的发布，Android Gradle 插件提供了名为 annotationProcessor 的功能来完全代替 android-apt ，自此android-apt 作者在官网发表声明最新的Android Gradle插件现在已经支持annotationProcessor，并警告和或阻止android-apt ，并推荐大家使用 Android 官方插件annotationProcessor。 但是很多项目目前还是使用android-apt，如果想替换为annotationProcessor，那就要知道android-apt是如何使用的。 它的作用主要如下： 只在编译期间引入注解处理器所在的函数库作为依赖，不会打包到最终生成的APK中。 为注解处理器生成的源码设置好正确的路径，以便Android Studio能够正常找到，避免报错。 Project项目中使用android-apt插件 1.使用该插件，添加如下到你的构建脚本中： //配置在Project下的build.gradle中buildscript &#123; repositories &#123; mavenCentral() &#125; dependencies &#123; ... //替换成最新android-apt版本 classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8' &#125;&#125;apply plugin: 'com.neenbedankt.android-apt' 2.接着以apt的方式引入注解处理器函数库作为依赖 dependencies &#123; apt'com.bluelinelabs:logansquare-compiler:1.3.6' compile 'com.bluelinelabs:logansquare:1.3.6'&#125; LoganSquare是一个实现了编译时注解以提高性能的JSON解析函数库。 通常在使用的时候，项目依赖可能分为多个部分。上面的compiler库就有两个组件loganSquare-compiler和loganSquare。loganSquare-commpiler仅用于编译时，是loganSquare的注解处理器，运行时必需使用loganSquare。 基本使用就是上面这两点，想用annotationProcessor替代android-apt。删除和替换相应部分即可 Provided 和apt/annotationProcessor区别provided vs apt使用注解处理器的不同？ provided 将会导入注解处理器的classes和它的依赖到IDE的类路径下。这意味着你可以附带的引入并使用这些classes。例如，当注解处理器使用Guava，你可能错误的import其相关代码到你的Android 代码中。当运行时将导致crash。 provided也可以用在重复引用的库上，避免依赖重复的资源。 使用apt，注解处理器的classes将不会添加到你当前的类路径下，仅仅用于注解处理过程。并且会把所有注解处理器生成的source放在IDE的类路径下，方便Android Studio引用。 具体可以参考：深入理解编译注解（三）依赖关系 apt/annotationProcessor与Provided的区别 APT处理annotation的流程越来越多第三方库使用apt技术，如DBflow、Dagger2、ButterKnife、ActivityRouter、AptPreferences。在编译时根据Annotation生成了相关的代码，非常高大上但是也非常简单的技术，可以给开发带来了很大的便利。 注解处理器（AbstractProcess）+代码处理（javaPoet）+处理器注册（AutoService）+apt 具体流程： 1.定义注解（如@inject） 2.定义注解处理器 3.在处理器里面完成处理方式，通常是生成Java代码。 4.注册处理器 5.利用APT完成如下图的工作内容。 annotationProcessor介绍annotationProcessor是APT工具中的一种，他是google开发的内置框架，不需要引入，可以直接在build.gradle文件中使用，ButterKnife就是使用annotationProcessor处理注解，如下： dependencies &#123; annotationProcessor project(':xx') annotationProcessor 'com.jakewharton:butterknife-compiler:8.5.1'&#125; apt vs annotationProcessor两者有何不同？ android-apt是由一位开发者自己开发的apt框架，源代码托管在这里，随着Android Gradle 插件 2.2 版本的发布，Android Gradle 插件提供了名为 annotationProcessor 的功能来完全代替 android-apt ，自此android-apt 作者在官网发表声明最新的Android Gradle插件现在已经支持annotationProcessor，并警告和或阻止android-apt ，并推荐大家使用 Android 官方插件annotationProcessor。 最近Android N的发布，android 迎来了Java 8，要想使用Java 8的话必须使用Jack编译，android-apt只支持javac编译而annotationProcessor既支持javac同时也支持jack编译。 想用annotationProcessor替代android-apt。删除和替换相应部分即可，具体可以参考这篇文章 文章参考： Android 打造编译时注解解析框架 这只是一个开始Android APT（编译时代码生成）最佳实践Android编译时注解框架系列1-什么是编译时注解你必须知道的APT、annotationProcessor、android-apt、Provided、自定义注解《Android高级进阶》一书——注解在Android中的应用 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/04/10/Annotation-Android-usage/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Annotation","slug":"annotation","permalink":"http://agehua.github.io/tags/annotation/"}]},{"title":"linux(centos) 搭建SVN服务器","slug":"SVN-server-linux","date":"2017-03-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/03/20/SVN-server-linux/","link":"","permalink":"http://agehua.github.io/2017/03/20/SVN-server-linux/","excerpt":"linux(centos) 搭建SVN服务器安装步骤如下：\n第一步：安装SVNyum install subversion\n第二步：创建SVN版本库目录mkdir -p /var/svn/svnrepos\n第三步：创建版本库","text":"linux(centos) 搭建SVN服务器安装步骤如下： 第一步：安装SVNyum install subversion 第二步：创建SVN版本库目录mkdir -p /var/svn/svnrepos 第三步：创建版本库 svnadmin create /var/svn/svnrepos 第四步：进入conf目录（该SVN版本库配置文件）authz文件是权限控制文件passwd是帐号密码文件svnserve.confSVN服务配置文件 第五步：修改svnserve.conf文件vi svnserve.conf打开下面的几个注释： anon-access = read #匿名用户可读auth-access = write #授权用户可写password-db = passwd #使用哪个文件作为账号文件authz-db = authz #使用哪个文件作为权限文件realm = /var/svn/svnrepos # 认证空间名，版本库所在目录 svnserve.conf、passwd、authz文件中各配置项前不要有空格 第六步：设置帐号密码vi passwd 在[users]块中添加用户和密码，格式：帐号=密码，如binjoo = 123456。 [users]binjoo = 123456 第七步：设置权限vi authz 在末尾添加如下代码： [groups][/]binjoo=rw 意思是版本库的根目录binjoo对其有读写权限。 第八步：启动svn版本库svnserve -d -r /var/svn/svnrepos 链接方式svn://127.0.0.1 遇到问题在客户端试图 svn merge 总是报svn: E220001: 遇到不可读的路径；拒绝访问。这个错误 提示 : SVN 遇到不可读的路径；拒绝访问。 英文是: Unreadable path encountered; access denied; 既然看不到日志又无法merge等操作. GOOGLE了一下，下面的方法解决了问题。 后面才发现是配置问题. 在项目的conf/svnserve.conf 中, 设置 anon-access = none 即可. 然后重启Subversion服务. 如果本地SVN客户端查看过日志会有缓存, 需要在 设置-&gt;日志缓存-&gt;缓存的版本库 中删除有问题的版本缓存 再重新查看日志就好了. linux svn启动和关闭 1，启动SVNsudo svnserve -d -r /var/svn/svnrepos 其中 -d 表示守护进程， -r 表示在后台执行/var/svn/svnrepos 为svn的安装目录 2，关闭SVN这里采取linux杀死进程的方式处理的ps -ef|grep svnserveroot 4967 1 0 Aug23 ? 00:00:00 svnserve -d -r repository/ 这里 kill -9 4967杀死进程， 此4967为进程号 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/03/20/SVN-server-linux/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"svn server","slug":"svn-server","permalink":"http://agehua.github.io/tags/svn-server/"},{"name":"linux","slug":"linux","permalink":"http://agehua.github.io/tags/linux/"}]},{"title":"JSR-330和assertion(断言)介绍","slug":"JAVA-JSR-330-Assertion","date":"2017-03-13T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/03/14/JAVA-JSR-330-Assertion/","link":"","permalink":"http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/","excerpt":"@Inject注解和Android中的依赖注入框架怎么让代码显得高大上呢，当然是多使用注解，那Android Support Annotation没新意了，有没有更高端的呢？\n当然有了。Java 依赖注入标准（JSR-330）规范，主要应用在JavaEE中。在 javax.inject 包中提供了一个接口 Provider，和几个注解类型 @Scope、@Inject、@Named、@Qualifier\n关于JSR-330标准可以看这篇文章：Java 依赖注入标准（JSR-330）\n下面简单介绍下 javax.inject 中提供的注解类型。","text":"@Inject注解和Android中的依赖注入框架怎么让代码显得高大上呢，当然是多使用注解，那Android Support Annotation没新意了，有没有更高端的呢？ 当然有了。Java 依赖注入标准（JSR-330）规范，主要应用在JavaEE中。在 javax.inject 包中提供了一个接口 Provider，和几个注解类型 @Scope、@Inject、@Named、@Qualifier 关于JSR-330标准可以看这篇文章：Java 依赖注入标准（JSR-330） 下面简单介绍下 javax.inject 中提供的注解类型。 @Inject@Inject是javax.inject中提供的一个注解，可以不使用new关键字直接创建对象，怎么样，是不是很高端 :) 在字段注解：用@Inject注解，字段不能是final的。可以拥有一个合法的名称 doc文档原文： Injectable fields: - are annotated with @Inject. - are not final. - may have any otherwise valid name.@Inject FieldModifiers(opt) Type VariableDeclarators; (opt)这里表示可选 在方法上注解：用@Inject注解，不能是抽象方法，不能声明自身参数类型。可以有返回结果。拥有一个合法的名称。可以有0个或多个参数 doc文档原文： Injectable methods:- are annotated with @Inject.- are not abstract.- do not declare type parameters of their own.- may return a result- may have any otherwise valid name.- accept zero or more dependencies as arguments.@Inject MethodModifiers(opt) ResultType Identifier(FormalParameterList(opt)) Throws(opt) MethodBody (opt)这里表示可选 代码示例： @InjectWeatherDao weatherDao; @InjectWeatherDao(Context context) &#123; this.context = context;&#125; @Inject支持构造函数、方法和字段注解，也可能使用于静态实例成员。可注解成员可以是任意修饰符（private,package-private,protected,public）。注入顺序：构造函数、字段，然后是方法。父类的字段和方法注入优先于子类的字段和方法，同一类中的字段和方法是没有顺序的。 @Inject注解的构造函数可以是无参或多个参数的构造函数。@Inject每个类中最多注解一个构造函数。 除了@Inject注解，还有@Named、@Qualifier和@Provider，下面简单介绍一下。 @Named@Named，一般和@Inject一起使用，如果没有值生成的Bean名称默认和类名相同。 如果指定名称，那么就生成一个指定名称的Bean。public class Car &#123; @Inject @Named(\"driver\") Seat driverSeat; @Inject @Named(\"passenger\") Seat passengerSeat; ...&#125; @Qualifier自定义一个新的修饰语（注解），一个qualifier注解应该满足如下条件： 定义的注解类有@Qualifier，@Retention(RUNTIME)和@Documented。 可以有属性 可以是公共API的一部分 可以用@Target注解限定使用范围 doc文档原文是：Identifies qualifier annotations. Anyone can define a new qualifier. A qualifier annotation:- is annotated with @Qualifier, @Retention(RUNTIME), and typically @Documented.- can have attributes.- may be part of the public API, much like the dependency type, but unlike implementation types which needn't be part of the public API.- may have restricted usage if annotated with @Target. While this specification covers applying qualifiers to fields and parameters only, some injector configurations might use qualifier annotations in other places (on methods or classes for example). 下面是java doc文档@Named注解的生成代码@Qualifier@Documented@Retention(value=RUNTIME)public @interface Named @Documented @Retention(RetentionPolicy.RUNTIME) @Qualifier @Target(value = &#123;ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE&#125;) public @interface Genre &#123; User user() default User.STUDENT; public enum User &#123;STUDENT, TEACHER&#125; &#125; @Named @Genre(user = User.STUDENT) public class StudentDAO implements IUserDAO&#123; @Override public int count() &#123; System.out.println(\"----StudentDAO----\"); return 0; &#125;&#125; @Provider@Provider注解，可以实现任意类型的对象的注入。相对于直接注入T对象，@Provider提供了一个T.get()方法来获取注入的对象 doc文档原文:Provides instances of T. Typically implemented by an injector. For any type T that can be injected, you can also inject Provider&lt;T&gt;. Compared to injecting T directly, injecting Provider&lt;T&gt; enables:- retrieving multiple instances.- lazy or optional retrieval of an instance.- breaking circular dependencies.- abstracting scope so you can look up an instance in a smaller scope from an instance in a containing scope. For example:class Car &#123;@Inject Car(Provider&lt;Seat&gt; seatProvider) &#123; Seat driver = seatProvider.get(); Seat passenger = seatProvider.get(); ... &#125;&#125; get方法解释T get() Provides a fully-constructed and injected instance of T. @Singleton使用该注解标记该类只创建一次，不能被继承。一般在类上用该注解。 doc原文:@Scope@Documented@Retention(value=RUNTIME)public @interface SingletonIdentifies a type that the injector only instantiates once. Not inherited. @Scope注解 @Scope 用于标识作用域注解。一个作用域注解是被标识在包含一个可注入构造器的类上的，用于控制该类型的实例如何被注入器重用。缺省情况下，如果没有标识作用域注解，注入器将为每一次注入都创建（通过注入类型的构造器）新实例，并不重用已有实例。如果多个线程都能够访问一个作用域内的实例，该实例实现应该是线程安全的。作用域实现由注入器完成。 在下面的例子中，作用域注解 @Singleton 确保我们始终只有一个 Log 实例： @Singletonclass Log &#123; void log(String message) &#123; ... &#125;&#125; 当多于一个作用域注解或不被注入器支持的作用域注解被使用在同一个类上时，注入器将生成一个错误。 一个作用域注解： 被标注了 @Scope、@Retention(RUNTIME) 标注的，通常也被 @Documented 标注。 不应该含有属性。 不应该被 @Inherited 标注，因此作用域与继承实现（正交）无关。 如果标注了 @Target 可能会有一些用法限制。 使用 @Scope 来标识一个作用域注解有助于注入器探测程序员使用了作用域注解但却忘了去配置作用域的情况。一个保守的注入器应该生成一个错误而不是去适用该作用域。 doc原文请点击 assertion(断言)在实现中，assertion就是在程序中的一条语句，它对一个boolean表达式进行检查，一个正确程序必须保证这个boolean表达式的值为true；如果该值为false，说明程序已经处于不正确的状态下，系统将给出警告并且退出。 在语法上，为了支持assertion，Java增加了一个关键字assert。它包括两种表达式，分别如下： 1.assert expression1;2.assert expression1: expression2; expression1表示一个boolean表达式，expression2表示一个基本类型、表达式或者是一个Object，用于在失败时输出错误信息。 在运行时，如果关闭了assertion功能，这些语句将不起任何作用。 如果打开了assertion功能，那么expression1的值将被计算。 如果它的值为false，该语句强抛出一个AssertionError对象。 如果expression1值为true，expression2将不被计算。 如何关闭和开启assertion功能，请看这篇文章 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Annotation","slug":"annotation","permalink":"http://agehua.github.io/tags/annotation/"},{"name":"assertion","slug":"assertion","permalink":"http://agehua.github.io/tags/assertion/"}]},{"title":"“HTTPS”安全在哪里？","slug":"Https-Questions","date":"2017-03-08T16:00:00.000Z","updated":"2024-12-05T09:41:56.319Z","comments":true,"path":"2017/03/09/Https-Questions/","link":"","permalink":"http://agehua.github.io/2017/03/09/Https-Questions/","excerpt":"\n文章转载自：“HTTPS”安全在哪里？ (出处: Bugly)\n\n\n背景最近基于兴趣学学习了下 HTTPS 相关的知识，在此记录下学习心得。\n在上网获取信息的过程中，我们接触最多的信息加密传输方式也莫过于HTTPS了。每当访问一个站点，浏览器的地址栏中出现绿色图标时，意味着该站点支持HTTPS信息传输方式。我们知道HTTPS是我们常见的HTTP协议与某个加密协议的混合体，也就是 HTTP+S。这个 S 可以是 TLS（安全传输层协议）、也可以是 SSL（安全套接层），不过我更认可另一个抽象概括的说法，HTTP+Security。不过要谈论 HTTPS 为何安全，还得从 HTTP 为何不安全说起。","text":"文章转载自：“HTTPS”安全在哪里？ (出处: Bugly) 背景最近基于兴趣学学习了下 HTTPS 相关的知识，在此记录下学习心得。 在上网获取信息的过程中，我们接触最多的信息加密传输方式也莫过于HTTPS了。每当访问一个站点，浏览器的地址栏中出现绿色图标时，意味着该站点支持HTTPS信息传输方式。我们知道HTTPS是我们常见的HTTP协议与某个加密协议的混合体，也就是 HTTP+S。这个 S 可以是 TLS（安全传输层协议）、也可以是 SSL（安全套接层），不过我更认可另一个抽象概括的说法，HTTP+Security。不过要谈论 HTTPS 为何安全，还得从 HTTP 为何不安全说起。 假设你现在正坐在教室里上课，现在你非常想和走道旁的迷人的 TA 说一些话，一般这个时候你会用“传纸条”的方式来交流。而这个方式和 TCP/IP 协议基本的工作模式十分相像： 通过小动作引起对方注意； 对方以多种可能的方式（注视、肢体语言等）回应于你； 你确认对方感知到你后，将纸条传给对方； 对方阅读纸条； 对方给予你阅读后的反应； 怎么样，这个流程是不是很熟悉？ 如果你要传递纸条的 TA 距离你很远怎么办？HTTP 协议就是指你在纸条上写明你要传给的 TA 是谁，或者 TA 的座位在哪，接着只需要途径的同学拿到纸条后根据纸条上的指示依次将纸条传过去就 OK 了。 这个时候问题来了：途径的同学完全可以观看并知道你在纸条上写了什么。 这就是 HTTP 传输所面临的问题之一：中间人攻击，指消息传递的过程中，处在传递路径上的攻击者可以嗅探或者窃听传输数据的内容。 加密HTTPS 针对这个问题，采用了“加密”的方式来解决。最著名原始的加密方法就是对称加密算法了，就是双方约定一个暗号，用什么字母替换什么字母之类的。现在一般采用一种叫 AES（高级加密算法）的对称算法。 对称加密算法既指加密和解密需要使用的密钥 key 是一样的。 AES 在数学上保证了，只要你使用的 key 足够长，破解几乎是不可能的（除非光子计算机造出来了）我们先假设在没有密钥 key 的情况下，密文是无法被破解的，然后再回到这个教室。你将用 AES 加密后的内容噌噌噌地写在了纸条上，正要传出去的时候你突然想到，TA 没有 key 怎么解密内容呀，或者说，应该怎么把 key 给TA？ 如果把 key 也写在纸条上，那么中间人照样可以破解窃听纸条内容。也许在现实环境中你有其他办法可以把 key 通过某种安全的渠道送到 TA 的手里，但是互联网上的实现难度就比较大了，毕竟不管怎样，数据都要经过那些路由。 于是聪明的人类发明了另一种加密算法——非对称加密算法。这种加密算法会生成两个密钥（key1 和 key2）。凡是 key1 加密的数据，key1 自身不能解密，需要 key2 才能解密；凡事 key2 加密的数据，key2 自身不能解密，只有 key1 才能解密。 目前这种算法有很多中，最常用的是RSA。其基于的数学原理是： 两个大素数的乘积很容易算，但是用这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因确实比较困难，尤其是当这个大数足够大的时候（通常使用2的10次方个二进制位那么大），就算是超级计算机，解密也需要非常长的时间。现在就把这种非对称加密的方法应用在我们教室传纸条的场景里。 你在写纸条内容之前先用 RSA 技术生成了一对密钥 k1 和 k2。 你把 k1 用明文传了出去，路经也许有人会截取，但是没有用，k1 加密的数据需要 k2 才可以破解，而 k2 在你自己手中。 k1 传到了目的人，目的人会去准备一个接下来准备用于对称加密（AES）的传输密钥 key，然后用收到的 k1 把 key 加密，传给你。 你用手上的 k2 解出 key 后，全教室只有你和你的目的人拥有这个对称加密的 key，你们俩就可以尽情聊天不怕窃听啦~ 这里也许你会有问题，为什么不直接用非对称加密来加密信息，而是加密 AES 的 key 呢？ 因为非对称加密和解密的平均消耗时间比较长，为了节省时间提高效率，我们通常只是用它来交换密钥，而非直接传输数据。然而使用非对称加密真的可以防范中间人攻击吗？虽然看上去很安全，但是实际上却挡不住可恶的中间人攻击。 假设你是 A，你的目的地是 B，现在要途径一个恶意同学M。 中间人的恶意之处在于它会伪装成你的目标。当你要和 B 完成第一次密钥交换的时候，M 把纸条扣了下来，假装自己是B并伪造了一个 key，然后用你发来的 k1 加密了 key 发还给你。你以为你和 B 完成了密钥交换，实际上你是和 M 完成了密钥交换。同事M 和 B 完成一次密钥交换，让 B 以为和 A 你完成了密钥交换。现在整体的加密流程变成了A（加密链接1）-&gt;M(明文)-&gt;B(加密链接2)的情况了，这时候 M 依然可以知道A和B传输的全部消息。 这个时候就是体现 HTTPS 和传纸条的区别了。在教室里，你是和一位与你身份几乎对等的的对象来通信；而在访问网站时，对方往往是一个比较大（或者知名）的服务者，他们有充沛的资源，或许他们可以向你证明他们的合法性。此时我们需要引入一个非常权威的第三方，一个专门用来认证网站合法性的组织，可以叫做 CA（Certificate Authority）。各个网站服务商可以向CA申请证书，使得他们在建立安全连接时可以带上CA的签名。而CA得安全性是由操作系统或者浏览器来认证的。 你的Windows、Mac、Linux、Chrome、Safari等会在安装的时候带上一个他们认为安全的 CA 证书列表，只有和你建立安全连接的网站带有这些CA的签名，操作系统和浏览器才会认为这个链接是安全的，否则就有可能遭到中间人攻击。一旦某个CA颁发的证书被用于的非法途径，那么这个CA之前颁发过的所有证书都将被视为不安全的，这让所有CA在颁发证书时都十分小心，所以CA证书在通常情况下是值得信任的。 总结使 HTTP 后面增加一个S（Security）的技术，正是 对称加密 + 非对称加密 + CA认证 这三种技术的混合体。当然这个主要是 HTTPS 的基本原理，真正实际中的 HTTPS 的协议是比以上的描述更为复杂一些的，并且其中任何一步稍有闪失，整个流程都将不再安全。这也是为什么 HTTPS 协议从 SSL 1.0升级到 SSL 3.0，再被 TLS 1.0 现在被 TLS 1.3取代，其背后都是一个个细节上的优化，以防有任何闪失。TLS 协议相比 SSL 协议增加了传输层的安全保证。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/03/09/Https-Questions/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"HTTPS","slug":"https","permalink":"http://agehua.github.io/tags/https/"}]},{"title":"解决Android多进程导致Application重复创建问题","slug":"Multi-Process-Dispatch","date":"2017-02-20T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2017/02/21/Multi-Process-Dispatch/","link":"","permalink":"http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/","excerpt":"\n本编文章是在阅读：Android架构思考(模块化、多进程)过程中，结合自己的理解，对Android开启多进程，会导致Application重复创建问题进行一个总结。\n\n\nAndroid开启多进程一般情况下，一个应用程序就一个进程，这个进程的名称就是应用程序包名。Android的四大组件在AndroidManifest文件中注册的时候，有个属性是android:process，这里可以指定组件的所处的进程。\n一个进程情况下，Application的onCreate方法只会执行一次，但如果应用中采用多进程方式，onCreate方法会执行多次。\n解决Application的onCreate方法多次调用总结了两种实现方式：","text":"本编文章是在阅读：Android架构思考(模块化、多进程)过程中，结合自己的理解，对Android开启多进程，会导致Application重复创建问题进行一个总结。 Android开启多进程一般情况下，一个应用程序就一个进程，这个进程的名称就是应用程序包名。Android的四大组件在AndroidManifest文件中注册的时候，有个属性是android:process，这里可以指定组件的所处的进程。 一个进程情况下，Application的onCreate方法只会执行一次，但如果应用中采用多进程方式，onCreate方法会执行多次。 解决Application的onCreate方法多次调用总结了两种实现方式： 一、根据不同的进程名字进行不同数据的初始化。这是现在网络上通用的方法，在自定义的Application的onCreate方法中控制不同进程的初始化 代码如下： @Overridepublic void onCreate() &#123; super.onCreate(); String processName = getProcessName(this, android.os.Process.myPid()); if (processName != null) &#123; boolean defaultProcess = processName.equals(Constants.REAL_PACKAGE_NAME); // 默认的主进程启动时初始化应用 if (defaultProcess) &#123; initAppForMainProcess(); &#125; // 其他进程启动时初始化对应内容 else if (processName.contains(\":webbrowser\")) &#123; &#125; else if (processName.contains(\":bgmusic\")) &#123; &#125; &#125; 获取当前进程名的方法如下： /** * @return null may be returned if the specified process not found */public static String getProcessName(Context cxt, int pid) &#123; ActivityManager am = (ActivityManager) cxt.getSystemService(Context.ACTIVITY_SERVICE); List&lt;RunningAppP.rocessInfo&gt; runningApps = am.getRunningAppProcesses(); if (runningApps == null) &#123; return null; &#125; for (RunningAppProcessInfo procInfo : runningApps) &#123; if (procInfo.pid == pid) &#123; return procInfo.processName; &#125; &#125; return null;&#125; 二、剥离出一个类，具有同Application相同的生命周期方法，每个进程拥有一个该类实例这就是文章开头提到的博客中使用的方式Android架构思考(模块化、多进程) 实现这种方式，一共有涉及到3个类， 一个是MaApplication继承了Application，是程序的入口，这是一个抽象类，需要子类去实现一些方法 一个是BaseApplicationLogic，这也是基类，由这个类来实现每个进程单独管理Application的生命周期，每个进程实现一个该类的子类 还有一个类是PriorityLogicWrapper，它是一个封装类，继承了Comparable接口，实现了对BaseApplicationLogic按照指定顺序排序（也就是可以按照优先级顺序初始化BaseApplicationLogic） 首先，我们先把所有ApplicationLogic注册到MaApplication中；然后，MaApplication会根据注册时的进程名信息进行筛选，选择相同进程名的ApplicationLogic，保存到本进程中；其次，对这些本进程的ApplicationLogic进行实例化；最后，调用ApplicationLogic的onCreate方法，实现ApplicationLogic与Application生命周期同步，同时还有onTerminate、onLowMemory、onTrimMemory、onConfigurationChanged等方法，与onCreate一致。 流程图如下所示： 代码实现，先看基类BaseApplicationLogic，每个进程都要实现一个该类的子类： public class BaseApplicationLogic &#123; protected MaApplication mApplication; public BaseApplicationLogic() &#123; &#125; public void setApplication(@NonNull MaApplication application) &#123; mApplication = application; &#125; public void onCreate() &#123; &#125; public void onTerminate() &#123; &#125; public void onLowMemory() &#123; &#125; public void onTrimMemory(int level) &#123; &#125; public void onConfigurationChanged(Configuration newConfig) &#123; &#125;&#125; 其次PriorityLogicWrapper，这是一个封装类，实现了BaseApplicationLogic的按优先级排列：public class PriorityLogicWrapper implements Comparable&lt;PriorityLogicWrapper&gt; &#123; public int priority = 0; public Class&lt;? extends BaseApplicationLogic&gt; logicClass = null; public BaseApplicationLogic instance; public PriorityLogicWrapper(int priority, Class&lt;? extends BaseApplicationLogic&gt; logicClass) &#123; this.priority = priority; this.logicClass = logicClass; &#125; @Override public int compareTo(PriorityLogicWrapper o) &#123; return o.priority - this.priority; &#125;&#125; 在MaApplication中直接对PriorityLogicWrapper进行操作，无需操作BaseApplicationLogic对象public abstract class MaApplication extends Application &#123; //mLogicList只持有当前进程的PriorityLogicWrapper对象 private ArrayList&lt;PriorityLogicWrapper&gt; mLogicList; //mLogicClassMap持有所有进程的PriorityLogicWrapper数组对象 private HashMap&lt;String, ArrayList&lt;PriorityLogicWrapper&gt;&gt; mLogicClassMap; @Override public void onCreate() &#123; super.onCreate(); init(); initializeLogic(); dispatchLogic(); instantiateLogic(); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; //找到当前进程的BaseApplicationLogic实例后，执行其onCreate()方法 priorityLogicWrapper.instance.onCreate(); &#125; &#125; &#125; &#125; private void init() &#123; mLogicClassMap = new HashMap&lt;&gt;(); &#125; public abstract boolean needMultipleProcess(); //由MaApplication的实现类，去实现这个方法，调用registerApplicationLogic() //注册所有进程的BaseApplicationLogic对象 protected abstract void initializeLogic(); /** * 添加所有来自不同进程的，不同的BaseApplicationLogic对象到HashMap中 * @param processName 进程名 * @param priority 优先级 * @param logicClass 继承BaseApplicationLogic的对象 * @return */ protected boolean registerApplicationLogic(String processName, int priority, @NonNull Class&lt;? extends BaseApplicationLogic&gt; logicClass) &#123; boolean result = false; if (null != mLogicClassMap) &#123; ArrayList&lt;PriorityLogicWrapper&gt; tempList = mLogicClassMap.get(processName); if (null == tempList) &#123; tempList = new ArrayList&lt;&gt;(); mLogicClassMap.put(processName, tempList); &#125; if (tempList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : tempList) &#123; if (logicClass.getName().equals(priorityLogicWrapper.logicClass.getName())) &#123; throw new RuntimeException(logicClass.getName() + \" has registered.\"); &#125; &#125; &#125; PriorityLogicWrapper priorityLogicWrapper = new PriorityLogicWrapper(priority, logicClass); tempList.add(priorityLogicWrapper); //tempList更新，则mLogicClassMap中的value也跟着更新了，不用再调用mLogicClassMap.put方法 &#125; return result; &#125; /** * 得到一个属于本进程的ArrayList对象，里面保存着封装类PriorityLogicWrapper */ private void dispatchLogic() &#123; if (null != mLogicClassMap) &#123; //根据进程名，得到该进程名对应的ArrayList&lt;PriorityLogicWrapper&gt; mLogicList = mLogicClassMap.get(ProcessUtil.getProcessName(this, ProcessUtil.getMyProcessId())); &#125; &#125; /** * 取得mLogicList中的PriorityLogicWrapper对象，并按优先级顺序初始化BaseApplicationLogic对象 */ private void instantiateLogic() &#123; if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; Collections.sort(mLogicList); //根据进程优先级，按顺序初始化 for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper) &#123; try &#123; /** * 调用Class.newInstance()，会创建这个Class的实例，但是不会执行Android中这个类相关的生命周期 * **/ priorityLogicWrapper.instance = priorityLogicWrapper.logicClass.newInstance(); &#125; catch (InstantiationException e) &#123; e.printStackTrace(); &#125; catch (IllegalAccessException e) &#123; e.printStackTrace(); &#125; if (null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.setApplication(this); &#125; &#125; &#125; &#125; &#125; &#125; //Application生命周期的处理，下面方法都类似 @Override public void onTerminate() &#123; super.onTerminate(); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onTerminate(); &#125; &#125; &#125; &#125; @Override public void onLowMemory() &#123; super.onLowMemory(); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onLowMemory(); &#125; &#125; &#125; &#125; @Override public void onTrimMemory(int level) &#123; super.onTrimMemory(level); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onTrimMemory(level); &#125; &#125; &#125; &#125; @Override public void onConfigurationChanged(Configuration newConfig) &#123; super.onConfigurationChanged(newConfig); if (null != mLogicList &amp;&amp; mLogicList.size() &gt; 0) &#123; for (PriorityLogicWrapper priorityLogicWrapper : mLogicList) &#123; if (null != priorityLogicWrapper &amp;&amp; null != priorityLogicWrapper.instance) &#123; priorityLogicWrapper.instance.onConfigurationChanged(newConfig); &#125; &#125; &#125; &#125;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"multi-process","slug":"multi-process","permalink":"http://agehua.github.io/tags/multi-process/"}]},{"title":"MAC下用iTerm2连接远程主机","slug":"iterm2-to-linux","date":"2017-02-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2017/02/12/iterm2-to-linux/","link":"","permalink":"http://agehua.github.io/2017/02/12/iterm2-to-linux/","excerpt":"MAC下用iTerm2连接远程主机iTerm2是MAC的一个终端工具。简单介绍一个小功能，使用iTerm2连接远程主机：\n\n1.先打开一个iTerm2窗口，选择菜单profiles中的Open Profiles，然后选择Edit Profiles中创建一个新的Profile，随便命名成容易记的。\n2.选择command，输入ssh -A -p xxx root@输入远程计算机的IP地址（xxx表示端口）。\n3.然后选择这个新的profile，New一个window就可以连接远程服务器了。\n\nSCP命令使用说明","text":"MAC下用iTerm2连接远程主机iTerm2是MAC的一个终端工具。简单介绍一个小功能，使用iTerm2连接远程主机： 1.先打开一个iTerm2窗口，选择菜单profiles中的Open Profiles，然后选择Edit Profiles中创建一个新的Profile，随便命名成容易记的。 2.选择command，输入ssh -A -p xxx root@输入远程计算机的IP地址（xxx表示端口）。 3.然后选择这个新的profile，New一个window就可以连接远程服务器了。 SCP命令使用说明 scp用来在网络上不同的主机之间复制文件，它使用ssh安全协议传输数据，具有和ssh一样的验证机制，从而安全的远程拷贝文件。 下面是一个简单例子： 首先创建一个本地文件echo hello, world &gt; a-file.txt copy本地文件到服务器的命令如下：scp &lt;local file&gt; &lt;remote user&gt;@&lt;remote machine&gt;:&lt;remote path&gt; 如果想Copy远程文件到本地，则是：scp &lt;remote user&gt;@&lt;remote machine&gt;:&lt;remote path&gt; &lt;local file&gt; 如果想复制目录也是可以的：scp -r local_folder remote_username@remote_ip:remote_folder 比如下面命令：scp -r /home/space/jdk-8u121-linux-x64.tar.gz root@107.182.178.94:/home/root/others/ 参数说明： [root@tank test]# scp –helpusage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 […] [[user@]host2:]file2 -1 强制scp命令使用协议ssh1-2 强制scp命令使用协议ssh2-4 强制scp命令只使用IPv4寻址-6 强制scp命令只使用IPv6寻址-B 使用批处理模式（传输过程中不询问传输口令或短语）-C 允许压缩。（将-C标志传递给ssh，从而打开压缩功能）-p 保留原文件的修改时间，访问时间和访问权限。-q 不显示传输进度条。-r 递归复制整个目录。-v 详细方式显示输出。scp和ssh(1)会显示出整个过程的调试信息。这些信息用于调试连接，验证和配置问题。-c cipher 以cipher将数据传输进行加密，这个选项将直接传递给ssh。-F ssh_config 指定一个替代的ssh配置文件，此参数直接传递给ssh。-i identity_file 从指定文件中读取传输时使用的密钥文件，此参数直接传递给ssh。-l limit 限定用户所能使用的带宽，以Kbit/s为单位。-o ssh_option 如果习惯于使用ssh_config(5)中的参数传递方式，-P port 注意是大写的P, port是指定数据传输用到的端口号-S program 指定加密传输时所使用的程序。此程序必须能够理解ssh(1)的选项。 转载自：http://blog.51yip.com/linux/1027.html iTerm从mac传文件到linuxsudo scp -P 28547 ~/Downloads/nexus-3.2.1-01-unix.tar.gz root@107.182.178.94:/usr/local -P 指定linux服务器的端口号，必须是大写 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/02/12/iterm2-to-linux/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"linux","slug":"linux","permalink":"http://agehua.github.io/tags/linux/"},{"name":"iterm","slug":"iterm","permalink":"http://agehua.github.io/tags/iterm/"},{"name":"scp","slug":"scp","permalink":"http://agehua.github.io/tags/scp/"}]},{"title":"IM 国外公司，服务费，方案","slug":"abroad-IM-service-company","date":"2017-01-12T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2017/01/13/abroad-IM-service-company/","link":"","permalink":"http://agehua.github.io/2017/01/13/abroad-IM-service-company/","excerpt":"一、海外提供IM服务的公司1.1 Sinch官网： https://www.sinch.com/products/instant-messaging/收费介绍","text":"一、海外提供IM服务的公司1.1 Sinch官网： https://www.sinch.com/products/instant-messaging/收费介绍 1.2 quickblox官网：https://quickblox.com/收费介绍 1.3 Layerhttps://layer.com/use-cases 具体价格需要注册，然后注册的邮箱里会收到一封邮件： 1.4sendbirdhttps://sendbird.com 收费介绍 1.5 applozichttps://www.applozic.com/收费介绍 二、各家IM服务公司比较 图片来源：Which Chat SDK is better for user experience? Applozic, Sendbird, Layer or Quickblox! 2.1 QuickBlox vs Applozic这部分内容转载自stackoverflow I have recently just tested two of the solutions you have cited. QuickBlox: protocol xmpp open source documentated less clearly than applozic easy set up Applozic: protocol mqtt open source easy set up, if a bit laborious well documented, and very easy API to use. Very customizable. Both programs: have video call/audio call/groups have code bases that are constantly being updated, and from their Github pages new version have been released in the past few months I preferred Applozic as the user interface was nicer and easier to use, and the features and pricing clearer. I also preferred the API and the setup code was easier. 2.2 Quickblox vs SendBird vs Layer本部分内容转载自Do I need to have my own backend? My research on Quickblox vs SendBird vs Layer.com is: 1.Backend-as-a-Service (BaaS) or Chat-as-a-Service (CaaS): Quickblox: Both, BaaS and CaaS SendBird (aka JIVER): CaaS (BaaS for Enterprise-only) Layer.com: CaaS only 2.WebSocket-based: Quickblox: No (XMPP) SendBird: Yes Layer.com: Yes 3.Voice and Video: Quickblox: Yes SendBird: No Layer.com: No 4.Chat UI Kit: Quickblox: QMChatViewController SendBird: Open-source Sample UIs for iOS, Android, JavaScript (Web &amp; React Native), Xamarin, Unity (You can use their Sample UI or 3rd party UI Kit like JSQMessagesViewController) Layer.com: Atlas 5.Number of Members in a Group: Quickblox: Thousands (you may need to host Quickblox BaaS at a dedicated AWS infrastructure for better performance) SendBird: Thousands (no need for an extra infrastructure) Layer.com: limited to 25 per group 6.The ability to host the BaaS/CaaS at your own IaaS: Quickblox: Yes (setup cost starts from $599) SendBird: Yes (limited to Enterprise plans only) Layer.com: No 7.Custom Objects Backend (the need for extra infrastructure): Quickblox: Included in Quickblox BaaS SendBird: Partial support (Key/value custom object stores for channels to be released in March) Layer.com: No 8.BaaS/CaaS Admin Panel/Dashboard: Quickblox: Basic with Custom Dashboard when subscribed to the enterprise plan, starts from $599/month (Classic UI) SendBird: Advanced (Modern UI) Layer.com: Basic (Modern UI) 9.Attachment max file size: Quickblox: Unknown SendBird: 25MB per file (custom limit for Enterprise plans) Layer.com: 2GB (be aware that their pricing is based on the data transfer) 10.Availability SLA: Quickblox: Based on AWS EC2 SLA (99.95%) SendBird: 99.9% Layer.com: 99.9% 11.Pricing (per month): Quickblox: Mainly based on the number of messengers per second (/s) and monthly active users: Free-$49-$214-$599-$1,199-$2,399 (Plans) SendBird: Mainly based on the number of monthly active users (MAU): Free-$59-$179-$599-Custom (https://sendbird.com/pricing) Layer.com: Mainly based on the monthly data transfer and monthly users: Free-$599 per month-Custom (https://layer.com/plans) 12.Number of freelancers at UpWork.com who have this Baas/CaaS as one of their skill set: Quickblox: 547 (keyword: “Quickblox”) SendBird: 0 (keyword: “SendBird” or “JIVER”) « new to the market Layer: 13 (keyword: “Layer.com” not Layer) 2.3 更多比较：https://www.quora.com/Quickblox-vs-SendBird-vs-Layer-com-Do-I-need-to-have-my-own-backend http://stackoverflow.com/questions/37678528/comparing-layer-applozic-quickblox-sendbird-for-quick-whatsapp-like-messagin https://www.applozic.com/blog/applozic-vs-sendbird-vs-layer-vs-quickblox-alternatives/ https://siftery.com/product-comparison/sendbird-vs-quickblox-vs-layer https://stackshare.io/stackups/sendbird-vs-sinch-vs-layer https://www.quora.com/What-SDKs-APIs-are-viable-for-implementing-instant-messaging-between-clients-Android-iOS-and-web 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2017/01/13/abroad-IM-service-company/","raw":null,"content":null,"categories":[{"name":"Investigation","slug":"investigation","permalink":"http://agehua.github.io/categories/investigation/"}],"tags":[{"name":"IM Company","slug":"im-company","permalink":"http://agehua.github.io/tags/im-company/"}]},{"title":"Android 增量更新整理","slug":"Android-patch-update","date":"2016-12-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/12/20/Android-patch-update/","link":"","permalink":"http://agehua.github.io/2016/12/20/Android-patch-update/","excerpt":"背景在前几年，整体移动网络环境相比现在差很多，加之流量费用又相对较高，因此每当我们发布新版本的时候，一些用户升级并不是很积极，这就造成了新版本的升级率并不高。而google为了解决了这个问题，提出了Smart App Update，即增量更新（也叫做差分升级）。\n增量更新与热修复完全不是一个东西。增量更新需要重新安装apk，而热修复不需要。热修复也能完成部分增量更新的功能。\n增量更新的流程增量更新的具体流程是：用户手机上安装着某个应用，下载了增量包，手机上的apk和增量包合并形成新的包，然后再次安装（注意这个过程是要重新安装的，当然部分应用市场有root权限你可能感知不到）。","text":"背景在前几年，整体移动网络环境相比现在差很多，加之流量费用又相对较高，因此每当我们发布新版本的时候，一些用户升级并不是很积极，这就造成了新版本的升级率并不高。而google为了解决了这个问题，提出了Smart App Update，即增量更新（也叫做差分升级）。 增量更新与热修复完全不是一个东西。增量更新需要重新安装apk，而热修复不需要。热修复也能完成部分增量更新的功能。 增量更新的流程增量更新的具体流程是：用户手机上安装着某个应用，下载了增量包，手机上的apk和增量包合并形成新的包，然后再次安装（注意这个过程是要重新安装的，当然部分应用市场有root权限你可能感知不到）。 增量更新的原理增量更新的原理也很简单，就是将手机上已安装的旧版本apk与服务器端新版本apk进行二进制对比，并得到差分包（patch），用户在升级更新应用时，只需要下载差分包，然后在本地使用差分包与旧版的apk合成新版apk，然后进行安装。差分包文件的大小，那就远比APK小得多了，这样也便于用户进行应用升级。 那么增量更新的流程可以细化为几个关键点： 1.用户手机上提取当前安装应用的apk 2.如何利用old.apk和new.apk生成增量文件（差分包） 3.增加文件与1.中的old.apk合并，然后安装 旧版的APK可以在/data/app/%packagename%/下找到。 也可以参考下面的代码： public class ApkExtract &#123; public static String extract(Context context) &#123; context = context.getApplicationContext(); ApplicationInfo applicationInfo = context.getApplicationInfo(); String apkPath = applicationInfo.sourceDir; Log.d(\"hongyang\", apkPath); return apkPath; &#125;&#125; 这部分可以参考张鸿洋的博客 关于生成差分包制作差分包的工具为bsdiff， 网址： http://www.daemonology.net/bsdiff/ 下载地址： http://www.daemonology.net/bsdiff/bsdiff-4.3.tar.gz 这是一个非常牛的二进制查分工具，bsdiff源代码在Android的源码目录下 ”\\external\\bsdiff“”这边也可以找到。另外还需要依赖bzlib来进行打包。在安全性方面，补丁和新旧版APK最好都要进行MD5验证，以免被篡改。 关于这个工具可以使用别人编译好的so库，这里；熟悉NDK开发的也可以自己编译，请看这里。这里就不在考虑这个工具问题了。 生成增量文件./bsdiff old.apk new.apk old-to-new.patch 这样就生成了一个增量文件old-to-new.patch 关于合并差分包生成差分包肯定是在服务端，合并差分包才是Android客户端需要做的： 增量文件和old.apk合并成新的apk./bspatch old.apk new2.apk old-to-new.patch 这样就生成一个new2.apk 生成后，要查看下两个文件的md5值。如果两个文件md5值一致，那么几乎可以肯定两个文件时一模一样的。 增量更新存在的不足 1、增量升级是以两个应用版本之间的差异来生成补丁的，但是我们无法保证用户每次的及时升级到最新，也就是在更新前，新版和旧版只差一个版本，所以必须对你所发布的每一个版本都和最新的版本作差分，以便使所有版本的用户都可以差分升级，这样相对就比较繁琐了。解决方法也有，可以通过Shell脚本来实现批量生成。 2.增量升级能成功的前提是，从手机端能够获得旧版APK，并且与服务端的APK签名是一样的，所以像那些破解的APP就无法实现更新。前面也提到了，为了安全性，防止补丁合成错误，最好在补丁合成前对旧版本的apk进行sha1或者MD5校验，保证基础包的一致性，这样才能顺利的实现增量升级。 想要封装一套增量更新的工具，请看这篇文章：打造Android万能的软件更新库，修改只要一点点 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/20/Android-patch-update/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Patch Update","slug":"patch-update","permalink":"http://agehua.github.io/tags/patch-update/"}]},{"title":"ThreadLocal一个使用——SimpleDateFormat","slug":"ThreadLocal-usage","date":"2016-12-10T16:00:00.000Z","updated":"2024-12-05T09:41:56.414Z","comments":true,"path":"2016/12/11/ThreadLocal-usage/","link":"","permalink":"http://agehua.github.io/2016/12/11/ThreadLocal-usage/","excerpt":"背景之前写过一篇文章：《ThreadLocal、HandlerThread、Lopper区别》，其中简单提及了ThreadLocal的解释。本篇文章主要结合具体应用场景——SimpleDateFormat，和大家来一起学习ThreadLocal的原理，并对ThreadLocal进行一个详细的介绍。\n下面是本文的参考资料：\njava学习记录–ThreadLocal使用案例——SimpleDateFormat：http://blog.csdn.net/u012706811/article/details/53231598\nSimpleDateFormat的线程安全问题与解决方案：http://www.cnblogs.com/zemliu/archive/2013/08/29/3290585.html\n前言Thread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals。\n这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。\n我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（ThreadLocal用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。\nThreadLocal为变量在每个线程中都创建了一个副本，所以每个线程可以访问自己内部的副本变量，不同线程之间不会互相干扰。\n本篇文章结合具体应用场景，来分析ThreadLocal为什么可以实现不同线程之间不会互相干扰。","text":"背景之前写过一篇文章：《ThreadLocal、HandlerThread、Lopper区别》，其中简单提及了ThreadLocal的解释。本篇文章主要结合具体应用场景——SimpleDateFormat，和大家来一起学习ThreadLocal的原理，并对ThreadLocal进行一个详细的介绍。 下面是本文的参考资料： java学习记录–ThreadLocal使用案例——SimpleDateFormat：http://blog.csdn.net/u012706811/article/details/53231598 SimpleDateFormat的线程安全问题与解决方案：http://www.cnblogs.com/zemliu/archive/2013/08/29/3290585.html 前言Thread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals。 这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。 我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（ThreadLocal用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。 ThreadLocal为变量在每个线程中都创建了一个副本，所以每个线程可以访问自己内部的副本变量，不同线程之间不会互相干扰。 本篇文章结合具体应用场景，来分析ThreadLocal为什么可以实现不同线程之间不会互相干扰。 应用场景那么，在什么场景下比较适合使用ThreadLocal呢？ stackoverflow上有人给出了还不错的回答： When and how should I use a ThreadLocal variable?One possible (and common) use is when you have some object that is not thread-safe, but you want to avoid synchronizing access to that object (I’m looking at you, SimpleDateFormat). Instead, give each thread its own instance of the object. SimpleDateFormat为什么线程不安全SimpleDateFormat类内部持有一个Calendar对象引用， 如果你的工具类里，SimpleDateFormat是个static的，那么多个thread之间就会共享这个SimpleDateFormat，同时也会共享这个Calendar引用。 查看下源码中的SimpleDateFormat.parse()方法，你会发现有如下的调用: protected Calendar calendar;Date parse() &#123; calendar.clear(); // 清理calendar ... // 执行一些操作, 设置 calendar 的日期什么的 calendar.getTime(); // 获取calendar的时间&#125; 这里calendar.clear()方法是线程不安全的，不同thread调用parse()方法，会导致结果不可预期 问题重现可以看：这篇博客 解决方案最简单的解决方案我们可以把static去掉，这样每个新的线程都会有一个自己的SimpleDateFormat实例，从而避免线程安全的问题 但是，使用这种方法，在高并发的情况下会大量的new SimpleDateFormat以及销毁SimpleDateFormat，这样是非常耗费资源的 下面是一个从网上找的使用ThreadLocal解决SimpleDateFormat线程不安全问题的例子： import java.text.ParseException;import java.text.SimpleDateFormat;import java.util.Date;import java.util.HashMap;import java.util.Map;public class DateUtil &#123; /** 锁对象 */ private static final Object lockObj = new Object(); /** 存放不同的日期模板格式的SimpleDateFormat的Map */ private static Map&lt;String, ThreadLocal&lt;SimpleDateFormat&gt;&gt; sdfMap = new HashMap&lt;String, ThreadLocal&lt;SimpleDateFormat&gt;&gt;(); /** * 返回一个ThreadLocal的SimpleDateFormat,每个线程只会new一次SimpleDateFormat * * @param pattern * @return */ private static SimpleDateFormat getSdf(final String pattern) &#123; ThreadLocal&lt;SimpleDateFormat&gt; tl = sdfMap.get(pattern); // 此处的双重判断和同步是为了防止sdfMap这个单例被多次put重复的sdf if (tl == null) &#123; synchronized (lockObj) &#123; tl = sdfMap.get(pattern); if (tl == null) &#123; // 只有Map中还没有这个pattern的sdf才会生成新的sdf并放入map System.out.println(\"put new sdf of pattern \" + pattern + \" to map\"); // 这里是关键,使用ThreadLocal&lt;SimpleDateFormat&gt;替代原来直接new SimpleDateFormat tl = new ThreadLocal&lt;SimpleDateFormat&gt;() &#123; @Override protected SimpleDateFormat initialValue() &#123; System.out.println(\"thread: \" + Thread.currentThread() + \" init pattern: \" + pattern); return new SimpleDateFormat(pattern); &#125; &#125;; sdfMap.put(pattern, tl); &#125; &#125; &#125; return tl.get(); &#125; /** * 是用ThreadLocal&lt;SimpleDateFormat&gt;来获取SimpleDateFormat,这样每个线程只会有一个SimpleDateFormat * * @param date * @param pattern * @return */ public static String format(Date date, String pattern) &#123; return getSdf(pattern).format(date); &#125; public static Date parse(String dateStr, String pattern) throws ParseException &#123; return getSdf(pattern).parse(dateStr); &#125;&#125; 实现原理那为什么ThreadLocal为变量在每个线程都保存了一个副本呢？ 下面部分内容来自博文，http://www.jianshu.com/p/33c5579ef44f (深入浅出ThreadLocal) 先看一下Thread和ThreadLocal两个类的具体结构，如下： 从线程Thread的角度来看，每个线程内部都会持有一个对ThreadLocalMap实例的引用（也就是threadLocals变量），ThreadLocalMap是TThreadLocal的静态内部类。而Entry则是ThreadLocalMap的静态内部类。ThreadLocalMap实例相当于线程的局部变量空间，由Entry[] table存储着线程的私有数据。 EntryEntry继承自WeakReference类，是存储线程私有变量的数据结构。ThreadLocal实例作为引用，意味着如果ThreadLocal实例为null，就可以从table中删除对应的Entry。 class Entry extends WeakReference&lt;ThreadLocal&lt;?&gt;&gt; &#123; Object value; Entry(ThreadLocal&lt;?&gt; k, Object v) &#123; super(k); value = v; &#125;&#125; ThreadLocalMap内部使用table数组存储Entry，默认大小INITIAL_CAPACITY(16)，先介绍几个参数： size：table中元素的数量。 threshold：table大小的2/3，当size &gt;= threshold时，遍历table并删除key为null的元素，如果删除后size &gt;= threshold*3/4时，需要对table进行扩容。 ThreadLocal.set()实现/** * ThreadLocal.set() */public void set(T value) &#123; Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value);&#125;ThreadLocalMap getMap(Thread t) &#123; return t.threadLocals;&#125; 从上面代码中看出来： 1.从当前线程Thread中获取ThreadLocalMap实例。 2.ThreadLocal实例和value封装成Entry。 ThreadLocal.get() 实现public T get() &#123; Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) &#123; ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) &#123; @SuppressWarnings(\"unchecked\") T result = (T)e.value; return result; &#125; &#125; return setInitialValue();&#125;private T setInitialValue() &#123; T value = initialValue(); Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); return value;&#125;ThreadLocalMap getMap(Thread t) &#123; return t.threadLocals;&#125; 从上面代码中可以看出， ThreadLocal.get()方法，如果是不同线程ThreadLocalMap为null，最终会调用initialValue()方法，这个方法也是我们给出的解决方案中重载的方法。最后得到的结果是，不同线程ThreadLocal只有一个，而SimpleDateFormat则每个线程都有一个。 但当同一线程有了一个SimpleDateFormat了，会是什么情况呢？看下面代码： //同一线程中再次执行ThreadLocal.get()public T get() &#123; Thread t = Thread.currentThread();//得到当前子线程 ThreadLocalMap map = getMap(t); //同一个线程，map不为空 if (map != null) &#123; ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) &#123; @SuppressWarnings(\"unchecked\") T result = (T)e.value; return result; &#125; &#125; return setInitialValue();&#125;ThreadLocalMap getMap(Thread t) &#123; //同一线程Thread，变量threadLocals经过初始化了，则不为空 return t.threadLocals;&#125; ThreadLocalMap.getEntry()是如何实现的呢？先看下Entry是如何存入table数组的 Entry存入table数组如何实现的：/** * static class ThreadLocalMap.set()方法 */private void set(ThreadLocal&lt;?&gt; key, Object value) &#123; Entry[] tab = table; int len = tab.length; int i = key.threadLocalHashCode &amp; (len-1); for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) &#123; ThreadLocal&lt;?&gt; k = e.get(); if (k == key) &#123; e.value = value; return; &#125; if (k == null) &#123; replaceStaleEntry(key, value, i); return; &#125; &#125; tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) &amp;&amp; sz &gt;= threshold) rehash();&#125; 1.通过ThreadLocal的nextHashCode方法生成hash值。 threadLocalHashCode，由nextHashCode()方法得到/** * 对应上面代码的key.threadLocalHashCode * 在ThreadLocal 类中 */private final int threadLocalHashCode = nextHashCode(); 2.通过 key.threadLocalHashCode &amp; (len -1) 定位到table的位置i，假设table中i位置的元素为f。 3.如果f != null，假设f中的引用为k： 如果k和当前ThreadLocal实例一致，则修改value值，返回。 如果k为null，说明这个f已经是stale(陈旧的)的元素。调用replaceStaleEntry方法删除table中所有陈旧的元素（即entry的引用为null）并插入新元素，返回。 否则通过nextIndex方法找到下一个元素f，继续进行步骤3。 4.如果f == null，则把Entry加入到table的i位置中。 5.通过cleanSomeSlots删除陈旧的元素，如果table中没有元素删除，需判断当前情况下是否要进行扩容。 /** * ThreadLocal 类中 */private static AtomicInteger nextHashCode = new AtomicInteger();private static int nextHashCode() &#123; return nextHashCode.getAndAdd(HASH_INCREMENT);&#125; 从nextHashCode方法可以看出，ThreadLocal每实例化一次，其hash值就原子增加HASH_INCREMENT。 Entry从table数组中取出在回看getEntry()方法，就简单多了：/** * ThreadLocalMap的getEntry()方法 */private Entry getEntry(ThreadLocal&lt;?&gt; key) &#123; int i = key.threadLocalHashCode &amp; (table.length - 1); Entry e = table[i]; if (e != null &amp;&amp; e.get() == key) return e; else return getEntryAfterMiss(key, i, e);&#125; 1.通过key.threadLocalHashCode &amp; (len -1)定位到table的位置i，假设table中i位置的元素为g。 2.如果g不为null，且和当前ThreadLocal实例一致，则返回这个Entry。 在看一遍ThreadLocal.get()的代码：//同一线程中再次执行ThreadLocal.get()public T get() &#123; Thread t = Thread.currentThread();//得到当前子线程 ThreadLocalMap map = getMap(t); //同一个线程，map不为空 if (map != null) &#123; //当前ThreadLocal实例一致，则Entry不为null ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) &#123; @SuppressWarnings(\"unchecked\") T result = (T)e.value; return result; &#125; &#125; return setInitialValue();&#125; 所以，同一个线程，ThreadLocalMap不为空，Entry不为null，则返回table中保存的result。不会执行到setInitialValue()。所以，而SimpleDateFormat则会每一个线程只有一个。 由此，就可以得出结论了，确实可以使用ThreadLocal解决SimpleDateFormat的线程安全问题。 p.s. 感兴趣的可以结合ThreadLocal源码继续研究下面的内容： 获取当前的线程的threadLocals。 如果threadLocals不为null，则通过ThreadLocalMap.getEntry方法找到对应的entry，如果其引用和当前key一致，则直接返回，否则在table剩下的元素中继续匹配。 如果threadLocals为null，则通过setInitialValue方法初始化，并返回。private Entry getEntryAfterMiss(ThreadLocal&lt;?&gt; key, int i, Entry e) &#123; Entry[] tab = table; int len = tab.length; while (e != null) &#123; ThreadLocal&lt;?&gt; k = e.get(); if (k == key) return e; if (k == null) expungeStaleEntry(i); else i = nextIndex(i, len); e = tab[i]; &#125; return null;&#125; table扩容如果table中的元素数量达到阈值threshold的3/4，会进行扩容操作，过程很简单： /** * 在ThreadLocalMap类中 */private void resize() &#123; Entry[] oldTab = table; int oldLen = oldTab.length; int newLen = oldLen * 2; Entry[] newTab = new Entry[newLen]; int count = 0; for (int j = 0; j &lt; oldLen; ++j) &#123; Entry e = oldTab[j]; if (e != null) &#123; ThreadLocal&lt;?&gt; k = e.get(); if (k == null) &#123; e.value = null; // Help the GC &#125; else &#123; int h = k.threadLocalHashCode &amp; (newLen - 1); while (newTab[h] != null) h = nextIndex(h, newLen); newTab[h] = e; count++; &#125; &#125; &#125; setThreshold(newLen); size = count; table = newTab;&#125; 新建新的数组newTab，大小为原来的2倍。 复制table的元素到newTab，忽略陈旧的元素，假设table中的元素e需要复制到newTab的i位置，如果i位置存在元素，则找下一个空位置进行插入。 文章到这里就结束了，没有更多了:） 文章内容部分来自互联网，部分为自己整理，最后感谢耐心看到这里的人， 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/11/ThreadLocal-usage/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"ThreadLocal","slug":"threadlocal","permalink":"http://agehua.github.io/tags/threadlocal/"}]},{"title":"Hexo 模板学习——Hexo 结构","slug":"hexo-learning1","date":"2016-12-05T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2016/12/06/hexo-learning1/","link":"","permalink":"http://agehua.github.io/2016/12/06/hexo-learning1/","excerpt":"起步Hexo会读取根目录下的_config.yml里面的theme属性, 从而采用对应的主题。而主题都是放在themes/目录下面的，然后你会发现他里面有个landscape的目录，这个就是默认主题啦。\n接着，我们查看themes/landscape/目录，以及根据文档docs-themes，我们很容易得出：一个主题其实由4部分组成。\n\n_config.yml: 主题的配置文件\nsource/: 放我们的CSS文件以及图片\nlayout/: 模板文件\nscripts: 放JavaScript文件，他们会自动加载\n\n根据文档docs-templates，下面表格中每个页面都有一个可用的模板，可以没有这些模板，但至少要有一个index模板。","text":"起步Hexo会读取根目录下的_config.yml里面的theme属性, 从而采用对应的主题。而主题都是放在themes/目录下面的，然后你会发现他里面有个landscape的目录，这个就是默认主题啦。 接着，我们查看themes/landscape/目录，以及根据文档docs-themes，我们很容易得出：一个主题其实由4部分组成。 _config.yml: 主题的配置文件 source/: 放我们的CSS文件以及图片 layout/: 模板文件 scripts: 放JavaScript文件，他们会自动加载 根据文档docs-templates，下面表格中每个页面都有一个可用的模板，可以没有这些模板，但至少要有一个index模板。 Template Page Fallback index Home page post Posts index page Pages index archive Archives index category Category archives archive tag Tag archives archive 每次当我们在浏览器访问时，Hexo都会去解析sources目录下对应的模板文件。不同的URL对应不同的文件，所以才有了不同的页面。那么，我们怎么知道哪个URL对应哪个页面呢？(下面我们以EJS为例) 无论URL是什么，Hexo先读取layout.ejs，然后里面的body变量会替换成上面表格里的模板：(Fallback的意思是如果访问/archives时，我们的archives.ejs不存在的话，就会返回index.ejs) 布局编写布局文件(layout.ejs)模板文件在layout文件夹下，文件名对应Hexo中的模板名，有index,post,page,archive,category,tag几种，对于普通的header + content + footer的页面结构，header和footer往往是可以复用的，因此我们可以使用layout.ejs进行布局，动态的内容使用body变量去动态渲染，所以我的layout.ejs大概长这样: &lt;!doctype html&gt;&lt;html lang=\"en\"&gt;&lt;head&gt; &lt;meta charset=\"UTF-8\"&gt; &lt;meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0, user-scalable=no\"/&gt; &lt;title&gt;&lt;%= config.title %&gt;&lt;/title&gt; &lt;%- css('css/style') %&gt;&lt;/head&gt;&lt;body&gt; &lt;%- partial('_partial/header') %&gt; &lt;div class=\"main\"&gt; &lt;%- body %&gt; &lt;/div&gt; &lt;%- partial('_partial/footer') %&gt; &lt;%- js('js/index.js') %&gt;&lt;/body&gt;&lt;/html&gt; partial,js和css是Hexo提供的辅助函数，后面再说。 其他模板文件每一个模板文件对应的是一种布局，当你使用hexo new 的时候，其实忽略了一个参数，完整的命令是hexo new [layout] ，这个layout就决定了文章使用何种方式布局，比如创建一个自己简介的About页面，hexo new page “about”其实就是使用了page布局。每种布局对应到我们的模板文件上就是index.ejs(首页),post.ejs(文章),archive.ejs(归档),tag.ejs(标签归档),page.ejs(分页)。 index.ejs首页一般是一些博文的摘要和一个分页器，通过Hexo的page变量拿到页面的数据渲染即可，这里我们不直接在index.ejs中写HTML结构，新建一个_partial/article.ejs，将文章数据传给子模板渲染，然后再额外传入一个参数{index: true}，对后面的post.ejs和page.ejs加以区分，让子模板能正确渲染。最后，index.ejs大致是这样的: //index.ejs&lt;% page.posts.each(function(post, index)&#123; %&gt; &lt;%- partial('_partial/article', &#123;index: true, post: post&#125;) %&gt;&lt;% &#125;) %&gt;&lt;div class=\"pagination\"&gt; &lt;%- paginator(&#123; total: Math.ceil(site.posts.length / config.per_page)&#125;) %&gt;&lt;/div&gt; post.ejs文章模板和首页差不多，只是对应的是一篇具体的文章，所以就把文章传入，再额外传入{index: false}告诉子模板不要按首页的方式去渲染就好了。就一行代码(因为都在子模板里 XD //post.ejs&lt;%- partial('_partial/article', &#123;index: false, post: page&#125;) %&gt; page.ejs我个人对Page模板其实是有点懵逼的，在我自己的实践中是添加about(hexo new page “about”)页面后，访问/about会走分页布局，实际上这个页面对应的内容是/source/about里的index.md，也相当于对文章的渲染，因此我把Page模板也写成了和文章模板一样: //page.ejs&lt;%- partial('_partial/article', &#123;index: false, post: page&#125;) %&gt;_partial/article.ejs 前面一共有三处共用了article模板，另外page和post的一样的，所以实际上只有两种情况:主页(index: true)和非主页(index: false)。对应的_partial/article.ejs里只要判断这个值就可以正确渲染了，基本结构如下： //_partial/article.ejs&lt;% if(index)&#123; %&gt; //index logic...&lt;% &#125;else&#123; %&gt; //post or page logic...&lt;% &#125; %&gt; tag.ejs标签归档页内容很少，直接用Hexo的辅助函数list_tags生成一个标签的列表就ok了: //tag.ejs&lt;%- list_tags() %&gt; 归档页模板和首页差不多，归档页只需要展示文章标题和最后的分页器就好: //archive.ejs&lt;div class=\"archive\"&gt; &lt;% var lastyear; %&gt; &lt;% page.posts.each(function(post)&#123; %&gt; &lt;% var year = post.date.year() %&gt; &lt;% if(lastyear !== year)&#123; %&gt; &lt;h4 class=\"year\"&gt;&lt;%= year %&gt;&lt;/h4&gt; &lt;% lastyear = year %&gt; &lt;% &#125; %&gt; &lt;div class=\"archive_item\"&gt; &lt;a class=\"title\" href=\"&lt;%- url_for(post.path) %&gt;\"&gt;&lt;%= post.title %&gt;&lt;/a&gt; &lt;span class=\"date\"&gt;&lt;%= post.date.format('YYYY-MM-DD') %&gt;&lt;/span&gt; &lt;/div&gt; &lt;% &#125;) %&gt; &lt;div class=\"pagination\"&gt; &lt;%- paginator(&#123; total: Math.ceil(site.posts.length / config.per_page)&#125;) %&gt; &lt;/div&gt;&lt;/div&gt; 至此，模板文件就写好了，对于category模板就放弃了，感觉比较鸡肋。。。 变量其实在模板文件中我们已经看到了page.post,site.posts.length,config.per_page等等，页面的内容就是根据这些变量获取的，由Hexo提供，拿来直接用，Hexo提供了很多变量，但不是都很常用，一般就用到以下变量: site: 对应整个网站的变量，一般会用到site.posts.length制作分页器 page: 对应当前页面的信息，例如我在index.ejs中使用page.posts获取了当前页面的所有文章而不是使用site.posts。 config: 博客的配置信息，博客根目录下的_config.yml。 theme: 主题的配置信息，对于主题根目录下的_config.yml。 辅助函数(Helper)制作一个分页器，我们需要知道文章的总数和每页展示的文章数，然后通过循环生成每个link标签，还要根据当前页面判断link标签的active状态，但是在Hexo中这些都不用我们自己来做了!Hexo提供了paginator这一辅助函数帮助我们生成分页器，只需要将文章总数site.posts.length和每页文章数config.per_page传入就可以生成了。 其他的Helper: list_tags([options]): 快速生成标签列表 js(path/to/js), css(path/to/css) 用来载入静态资源，path可以是字符串或数组(载入多个资源)，默认会去source文件夹下去找。 partial(path/to/partial) 引用字模板，默认会去layout文件夹下找。 样式知道了Hexo的渲染方式，我们就可以使用HTML标签+CSS样式个性化我们的主题了，推荐大家使用CSS预处理语言的一种来写样式，这样就可以通过预处理语言自身的特点让样式更灵活。 其他添加对多说和Disqus的支持评论是很常用的功能，不如就直接在我们的主题里支持了，然后通过配置变量决定是否开启，评论区跟在文章内容下面，对于这种三方的代码块，最好也以partial的方式提取出来，方便移除或是替换。 //_partial/article.ejs&lt;section class='post-content'&gt; &lt;%- post.content %&gt;&lt;/section&gt;//评论部分，post.comments判断是否开启评论，config.duoshuo_shortname和config.disqus_shortname来判断启用那种评论插件，这里优先判断了多说&lt;% if(post.comments)&#123; %&gt; &lt;section id=\"comments\"&gt; &lt;% if (config.duoshuo_shortname)&#123; %&gt; &lt;%- partial('_partial/duoshuo') %&gt; &lt;% &#125;else if(config.disqus_shortname)&#123; %&gt; &lt;%- partial('_partial/disqus') %&gt; &lt;% &#125; %&gt; &lt;/section&gt;&lt;% &#125; %&gt; 再将多说和Disqus提供的js脚本代码放在_partial/duoshuo.ejs和_partial/disqus.ejs下就ok了~ 使用highlight.js提供代码高亮highlight.js提供了多种语言的支持和多种皮肤，用法也很简单，载入文件后调用初始化方法，一切都帮你搞定，对于使用那种皮肤，喜好因人而异，我们干脆在主题的配置文件中做成配置项让用户自己选择: //showonne/_config.yml...other configs# highlight.jshighlight_theme: zenburn 对应的layout.ejs中: &lt;link rel=\"stylesheet\" href=\"//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.4.0/styles/&lt;%= theme.highlight_theme %&gt;.min.css\"&gt; 样式文件通过CDN引入，因为不同皮肤对应不同的文件名，所以十分灵活。 最后当初是对应着landscape照葫芦画瓢写的，最近回头来发现一些不合理的地方，所以就又改了改，也对应着写了这么一篇总结，接下来准备再把样式划分一下，对于颜色这类样式通过变量的方式提取出来，也变得可配置，能让主题更灵活一些。 参考资源 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/06/hexo-learning1/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Hexo","slug":"hexo","permalink":"http://agehua.github.io/tags/hexo/"},{"name":"Hexo structure","slug":"hexo-structure","permalink":"http://agehua.github.io/tags/hexo-structure/"}]},{"title":"Hexo 模板学习——EJS介绍","slug":"hexo-learning0","date":"2016-12-03T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/12/04/hexo-learning0/","link":"","permalink":"http://agehua.github.io/2016/12/04/hexo-learning0/","excerpt":"什么是EJS？EJS是JavaScript模板库，用来从JSON数据中生成HTML字符串\nEJS的语法和功能：1、缓存功能，能够缓存已经解析好的html模版2、&lt;% code %&gt;用于执行其中javascript代码。&lt;% alert('hello world') %&gt;\n3、&lt;%= code =%&gt;会对code进行html转义；","text":"什么是EJS？EJS是JavaScript模板库，用来从JSON数据中生成HTML字符串 EJS的语法和功能：1、缓存功能，能够缓存已经解析好的html模版2、&lt;% code %&gt;用于执行其中javascript代码。&lt;% alert('hello world') %&gt; 3、&lt;%= code =%&gt;会对code进行html转义； &lt;h1&gt;&lt;%=title %&gt;&lt;/h1&gt; 注：会把title里面存的值给显示出来在h1中。&lt;p&gt;&lt;%= 'hello world' %&gt;&lt;/p&gt; 注：会把hello world显示在h1中。&lt;h1&gt;&lt;%= '&lt;b&gt;hello world&lt;/b&gt;' %&gt;&lt;/h1&gt; 注：会把hello world变粗，然后显示在h1中。 4、&lt;%- code %&gt;将不会进行转义；，这一行代码不会执行，像是被注释了一样，然后显示原来的html。也不会影响整个页面的执行。&lt;h1&gt;&lt;%-title %&gt;asd&lt;/h1&gt; 最后显示asd，及显示原网页&lt;p&gt;&lt;%# 'hello world' %&gt;asd&lt;/p&gt; 最后显示asd，及显示原网页 5、支持自定义标签，比如’&lt;%’可以使用’NaN‘代替；ejs 里，默认的闭合标记是 &lt;% .. %&gt;，我们也可以定义自己的标签。例如： app.set(\"view options\",&#123; \"open\":\"&#123;&#123;\", \"close\":\"&#125;&#125;\"&#125;); 6、提供一些辅助函数，用于模版中使用 1)、first，返回数组的第一个元素； 2)、last，返回数组的最后一个元素； 3)、capitalize，返回首字母大写的字符串； 4)、downcase，返回字符串的小写； 5)、upcase，返回字符串的大写； 6)、sort，排序（Object.create(obj).sort()？）； 7)、sort_by:’prop’，按照指定的prop属性进行升序排序； 8)、size，返回长度，即length属性，不一定非是数组才行； 9)、plus:n，加上n，将转化为Number进行运算； 10)、minus:n，减去n，将转化为Number进行运算； 11)、times:n，乘以n，将转化为Number进行运算； 12)、divided_by:n，除以n，将转化为Number进行运算； 13)、join:’val’，将数组用’val’最为分隔符，进行合并成一个字符串； 14)、truncate:n，截取前n个字符，超过长度时，将返回一个副本 15)、truncate_words:n，取得字符串中的前n个word，word以空格进行分割； 16)、replace:pattern,substitution，字符串替换，substitution不提供将删除匹配的子串； 17)、prepend:val，如果操作数为数组，则进行合并；为字符串则添加val在前面； 18)、append:val，如果操作数为数组，则进行合并；为字符串则添加val在后面； 19)、map:’prop’，返回对象数组中属性为prop的值组成的数组； 20)、reverse，翻转数组或字符串； 21)、get:’prop’，取得属性为’prop’的值； 22)、json，转化为json格式字符串 利用&lt;%- include filename %&gt;加载其他页面模版； ejs我的总结：ejs 写法： 1.普通传入并使用变量： &lt;%= title %&gt; 2.普通for执行js代码（for中间的代码一定可以执行到）： &lt;% for(var i=0; i&lt;headerNavbar.length; i++) &#123;%&gt; &lt;li&gt;&lt;a href=\"/reg\"&gt;&lt;%= headerNavbar[i].name %&gt;&lt;/a&gt;&lt;/li&gt;&lt;% &#125; %&gt; 3.特殊if语句的js代码（if中间的额代码不一定可以执行到）： &lt;% if(active=='index')&#123;%&gt;class=\"active\" &lt;% &#125;%&gt; stylus介绍部分内容转载自：stylus入门使用方法 stylus项目地址：http://stylus-lang.com/ Stylus 是一个CSS的预处理框架，2010年产生，来自Node.js社区，主要用来给Node项目进行CSS预处理支持，所以 Stylus 是一种新型语言，可以创建健壮的、动态的、富有表现力的CSS。比较年轻，其本质上做的事情与 SASS/LESS 等类似，应该是有很多借鉴，所以近似脚本的方式去写CSS代码。 Stylus功能上更为强壮，和js联系更加紧密（EXPRESSIVE, DYNAMIC, ROBUST CSS） Stylus安装使用node包管理器，全局安装$ npm install stylus -g 生成CSS建立一个stylusExample/，再在里面建立 src 目录专门存放 stylus 文件，在里面建立 example.styl 文件。然后在 stylusExample 目录下面执行下面命令$ stylus --compress src/ 输出compiled src/example.css ，这个时候表示你生成成功了，带上–compress参数表示你生成压缩的CSS文件。$ stylus --css css/example.css css/out.styl CSS转换成styl$ stylus help box-shadow CSS属性的帮助$ stylus --css test.css 输出基本名一致的.styl文件 具体语法和应用可以参考: Stylus中文参考文档 CSS3 column多列布局介绍CSS3提供了个新属性columns用于多列布局。在这之前，有些大家习以为常的排版，要用CSS动态实现其实是比较困难的。如竖版报纸 Columns属性最大的问题还是浏览器兼容性问题摘选自：CSS3 column多列布局介绍 栅格与响应式设计栅格样式库一般是这样做的：将页面划分为若干等宽的列（column），然后推荐你通过等宽列来创建响应式的页面区块。 虽然看起来都是这样的思路，但不同的栅格样式库，在做法上却是各有各的点子。下面，本文将介绍几个比较有代表性的栅格样式库，讲述它们的简要原理和用法 Bootstrap中的栅格:Bootstrap把它的栅格放在CSS这个分类下，并称它为Gird system。默认分为12列。 要理解Bootstrap中的栅格，最好从掌握正确的使用方法开始。这其中有2个要点。 第1个要点是容器（container），行（row）和列（column）之间的层级关系。一个正确的写法示例如下： &lt;div class=\"container\"&gt; &lt;div class=\"row\"&gt; &lt;div class=\"col-md-6\"&gt;&lt;/div&gt; &lt;div class=\"col-md-6\"&gt;&lt;/div&gt; &lt;/div&gt;&lt;/div&gt; 第2个要点，是不同的断点类型的意义及其搭配。 Bootstrap栅格的column对应的类名形如.col-xx-y。y是数字，表示该元素的宽度占据12列中的多少列。而xx只有特定的几个值可供选择，分别是xs、sm、md、lg，它们就是断点类型。 在Bootstrap栅格的设计中，断点的意义是，当视口（viewport）宽度小于断点时，column将竖直堆叠（display: block的默认表现），而当视口宽度大于或等于断点时，column将水平排列（float的效果）。按照xs、sm、md、lg的顺序，断点像素值依次增大，其中xs表示极小，即认为视口宽度永远不小于xs断点，column将始终水平浮动。 Foundation中的栅格Foundation栅格叫做Grid，它和Bootstrap栅格的设计十分近似，只是在类名和结构上有所差异。Foundation栅格同样默认12列。 行与列类比之前Bootstrap栅格的例子，Foundation栅格的一个正确的写法示例如下：&lt;div class=\"row\"&gt; &lt;div class=\"medium-6 columns\"&gt;&lt;/div&gt; &lt;div class=\"medium-6 columns\"&gt;&lt;/div&gt;&lt;/div&gt; Foundation栅格的行用.row表示，而列由至少两个类名组成，一是.columns或.column（2种写法完全相同，单纯为了支持语法偏好）表明这是列元素，二是.medium-6这种用于表示断点类型和对应宽度。在默认情况下，Foundation栅格的断点类型从小到大依次是small、medium、large，其中small类似Bootstrap栅格的xs，也是指任意屏幕尺寸下都水平排列。 Foundation栅格没有container，只需要row和column，因此显得比Bootstrap栅格更简单一些。其中row定义了最大宽度（可以认为承担了container的部分功能），column定义了0.9375rem的水平内边距。如果要嵌套，仍然是column内续接row，再继续接column。 组合使用多个断点类型，其方法也和Bootstrap栅格相同。需要注意的是，Foundation栅格的断点值是用的em而不是px，对应的，它们转换后的像素值也有别于Bootstrap栅格。 Block Grid作为栅格系统的补充，Foundation还提供了另外一个叫做Block Grid的栅格。不过，它并不是一个超出传统栅格的新东西，而只是一个针对特定栅格应用场景的方法糖。 摘选自：有关css栅格系统的故事 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/04/hexo-learning0/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Hexo","slug":"hexo","permalink":"http://agehua.github.io/tags/hexo/"},{"name":"EJS","slug":"ejs","permalink":"http://agehua.github.io/tags/ejs/"}]},{"title":"nodejs入门","slug":"nodejs-learning-getting-started","date":"2016-12-02T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/12/03/nodejs-learning-getting-started/","link":"","permalink":"http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/","excerpt":"\n本文是我自己的学习笔记，整理自《Node入门》\n\nNode入门作者： Manuel Kiessling翻译： goddyzhao &amp; GrayZhang &amp; MondayChen\n本书致力于教会你如何用Node.js来开发应用，过程中会传授你所有所需的“高级”JavaScript知识。本书绝不是一本“Hello World”的教程。\n服务端JavaScriptJavaScript最早是运行在浏览器中，然而浏览器只是提供了一个上下文，它定义了使用JavaScript可以做什么，但并没有“说”太多关于JavaScript语言本身可以做什么。事实上，JavaScript是一门“完整”的语言： 它可以使用在不同的上下文中，其能力与其他同类语言相比有过之而无不及。\nNode.js事实上就是另外一种上下文，它允许在后端（脱离浏览器环境）运行JavaScript代码。","text":"本文是我自己的学习笔记，整理自《Node入门》 Node入门作者： Manuel Kiessling翻译： goddyzhao &amp; GrayZhang &amp; MondayChen 本书致力于教会你如何用Node.js来开发应用，过程中会传授你所有所需的“高级”JavaScript知识。本书绝不是一本“Hello World”的教程。 服务端JavaScriptJavaScript最早是运行在浏览器中，然而浏览器只是提供了一个上下文，它定义了使用JavaScript可以做什么，但并没有“说”太多关于JavaScript语言本身可以做什么。事实上，JavaScript是一门“完整”的语言： 它可以使用在不同的上下文中，其能力与其他同类语言相比有过之而无不及。 Node.js事实上就是另外一种上下文，它允许在后端（脱离浏览器环境）运行JavaScript代码。 要实现在后台运行JavaScript代码，代码需要先被解释然后正确的执行。Node.js的原理正是如此，它使用了Google的V8虚拟机（Google的Chrome浏览器使用的JavaScript执行环境），来解释和执行JavaScript代码。 除此之外，伴随着Node.js的还有许多有用的模块，它们可以简化很多重复的劳作，比如向终端输出字符串。 因此，Node.js事实上既是一个运行时环境，同时又是一个库。 要使用Node.js,首先需要进行安装。关于如何安装Node.js，这里就不赘述了，可以直接参考官方的安装指南。安装完成后，继续回来阅读本书下面的内容。 “Hello World”好了，“废话”不多说了，马上开始我们第一个Node.js应用：“Hello World”。 打开你最喜欢的编辑器，创建一个helloworld.js文件。我们要做就是向STDOUT输出“Hello World”，如下是实现该功能的代码： console.log(\"Hello World\"); 保存该文件，并通过Node.js来执行：node helloworld.js 正常的话，就会在终端输出Hello World 。 好吧，我承认这个应用是有点无趣，那么下面我们就来点“干货”。 一个完整的基于Node.js的web应用用例我们来把目标设定得简单点，不过也要够实际才行： 用户可以通过浏览器使用我们的应用。当用户请求http://domain/start 时，可以看到一个欢迎页面，页面上有一个文件上传的表单。用户可以选择一个图片并提交表单，随后文件将被上传到http://domain/upload ，该页面完成上传后会把图片显示在页面上。差不多了，你现在也可以去Google一下，找点东西乱搞一下来完成功能。但是我们现在先不做这个。 更进一步地说，在完成这一目标的过程中，我们不仅仅需要基础的代码而不管代码是否优雅。我们还要对此进行抽象，来寻找一种适合构建更为复杂的Node.js应用的方式。 应用不同模块分析我们来分解一下这个应用，为了实现上文的用例，我们需要实现哪些部分呢？ 我们需要提供Web页面，因此需要一个HTTP服务器对于不同的请求，根据请求的URL，我们的服务器需要给予不同的响应，因此我们需要一个路由，用于把请求对应到请求处理程序（request handler）当请求被服务器接收并通过路由传递之后，需要可以对其进行处理，因此我们需要最终的请求处理程序路由还应该能处理POST数据，并且把数据封装成更友好的格式传递给请求处理入程序，因此需要请求数据处理功能我们不仅仅要处理URL对应的请求，还要把内容显示出来，这意味着我们需要一些视图逻辑供请求处理程序使用，以便将内容发送给用户的浏览器最后，用户需要上传图片，所以我们需要上传处理功能来处理这方面的细节我们先来想想，使用PHP的话我们会怎么构建这个结构。一般来说我们会用一个Apache HTTP服务器并配上mod_php5模块。从这个角度看，整个“接收HTTP请求并提供Web页面”的需求根本不需要PHP来处理。 不过对Node.js来说，概念完全不一样了。使用Node.js时，我们不仅仅在实现一个应用，同时还实现了整个HTTP服务器。事实上，我们的Web应用以及对应的Web服务器基本上是一样的。 听起来好像有一大堆活要做，但随后我们会逐渐意识到，对Node.js来说这并不是什么麻烦的事。 现在我们就来开始实现之路，先从第一个部分–HTTP服务器着手。 构建应用的模块一个基础的HTTP服务器当我准备开始写我的第一个“真正的”Node.js应用的时候，我不但不知道怎么写Node.js代码，也不知道怎么组织这些代码。我应该把所有东西都放进一个文件里吗？网上有很多教程都会教你把所有的逻辑都放进一个用Node.js写的基础HTTP服务器里。但是如果我想加入更多的内容，同时还想保持代码的可读性呢？ 实际上，只要把不同功能的代码放入不同的模块中，保持代码分离还是相当简单的。 这种方法允许你拥有一个干净的主文件（main file），你可以用Node.js执行它；同时你可以拥有干净的模块，它们可以被主文件和其他的模块调用。 那么，现在我们来创建一个用于启动我们的应用的主文件，和一个保存着我们的HTTP服务器代码的模块。 在我的印象里，把主文件叫做index.js或多或少是个标准格式。把服务器模块放进叫server.js的文件里则很好理解。 让我们先从服务器模块开始。在你的项目的根目录下创建一个叫server.js的文件，并写入以下代码： var http = require(\"http\");http.createServer(function(request, response) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;).listen(8888); 搞定！你刚刚完成了一个可以工作的HTTP服务器。为了证明这一点，我们来运行并且测试这段代码。首先，用Node.js执行你的脚本： node server.js 接下来，打开浏览器访问http://localhost:8888/ ，你会看到一个写着“Hello World”的网页。 这很有趣，不是吗？让我们先来谈谈HTTP服务器的问题，把如何组织项目的事情先放一边吧，你觉得如何？我保证之后我们会解决那个问题的。 分析HTTP服务器那么接下来，让我们分析一下这个HTTP服务器的构成。 第一行请求（require）Node.js自带的 http 模块，并且把它赋值给 http 变量。 接下来我们调用http模块提供的函数： createServer 。这个函数会返回一个对象，这个对象有一个叫做 listen 的方法，这个方法有一个数值参数，指定这个HTTP服务器监听的端口号。 咱们暂时先不管 http.createServer 的括号里的那个函数定义。 我们本来可以用这样的代码来启动服务器并侦听8888端口：var http = require(\"http\");var server = http.createServer();server.listen(8888); 这段代码只会启动一个侦听8888端口的服务器，它不做任何别的事情，甚至连请求都不会应答。 最有趣（而且，如果你之前习惯使用一个更加保守的语言，比如PHP，它还很奇怪）的部分是 createServer() 的第一个参数，一个函数定义。 实际上，这个函数定义是 createServer() 的第一个也是唯一一个参数。因为在JavaScript中，函数和其他变量一样都是可以被传递的。 进行函数传递举例来说，你可以这样做： function say(word) &#123; console.log(word);&#125;function execute(someFunction, value) &#123; someFunction(value);&#125;execute(say, \"Hello\"); 请仔细阅读这段代码！在这里，我们把 say 函数作为execute函数的第一个变量进行了传递。这里传递的不是 say 的返回值，而是 say 本身！ 这样一来， say 就变成了execute 中的本地变量 someFunction ，execute可以通过调用 someFunction() （带括号的形式）来使用 say 函数。 当然，因为 say 有一个变量， execute 在调用 someFunction 时可以传递这样一个变量。 我们可以，就像刚才那样，用它的名字把一个函数作为变量传递。但是我们不一定要绕这个“先定义，再传递”的圈子，我们可以直接在另一个函数的括号中定义和传递这个函数： function execute(someFunction, value) &#123; someFunction(value);&#125;execute(function(word)&#123; console.log(word) &#125;, \"Hello\"); 我们在 execute 接受第一个参数的地方直接定义了我们准备传递给 execute 的函数。 用这种方式，我们甚至不用给这个函数起名字，这也是为什么它被叫做 匿名函数 。 这是我们和我所认为的“进阶”JavaScript的第一次亲密接触，不过我们还是得循序渐进。现在，我们先接受这一点：在JavaScript中，一个函数可以作为另一个函数接收一个参数。我们可以先定义一个函数，然后传递，也可以在传递参数的地方直接定义函数。 函数传递是如何让HTTP服务器工作的带着这些知识，我们再来看看我们简约而不简单的HTTP服务器： var http = require(\"http\");http.createServer(function(request, response) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;).listen(8888); 现在它看上去应该清晰了很多：我们向 createServer 函数传递了一个匿名函数。 用这样的代码也可以达到同样的目的： var http = require(\"http\");function onRequest(request, response) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;http.createServer(onRequest).listen(8888); 也许现在我们该问这个问题了：我们为什么要用这种方式呢？ 基于事件驱动的回调这个问题可不好回答（至少对我来说），不过这是Node.js原生的工作方式。它是事件驱动的，这也是它为什么这么快的原因。 你也许会想花点时间读一下Felix Geisendörfer的大作Understanding node.js，它介绍了一些背景知识。 这一切都归结于“Node.js是事件驱动的”这一事实。好吧，其实我也不是特别确切的了解这句话的意思。不过我会试着解释，为什么它对我们用Node.js写网络应用（Web based application）是有意义的。 当我们使用 http.createServer 方法的时候，我们当然不只是想要一个侦听某个端口的服务器，我们还想要它在服务器收到一个HTTP请求的时候做点什么。 问题是，这是异步的：请求任何时候都可能到达，但是我们的服务器却跑在一个单进程中。 写PHP应用的时候，我们一点也不为此担心：任何时候当有请求进入的时候，网页服务器（通常是Apache）就为这一请求新建一个进程，并且开始从头到尾执行相应的PHP脚本。 那么在我们的Node.js程序中，当一个新的请求到达8888端口的时候，我们怎么控制流程呢？ 嗯，这就是Node.js/JavaScript的事件驱动设计能够真正帮上忙的地方了——虽然我们还得学一些新概念才能掌握它。让我们来看看这些概念是怎么应用在我们的服务器代码里的。 我们创建了服务器，并且向创建它的方法传递了一个函数。无论何时我们的服务器收到一个请求，这个函数就会被调用。 我们不知道这件事情什么时候会发生，但是我们现在有了一个处理请求的地方：它就是我们传递过去的那个函数。至于它是被预先定义的函数还是匿名函数，就无关紧要了。 这个就是传说中的 回调 。我们给某个方法传递了一个函数，这个方法在有相应事件发生时调用这个函数来进行 回调 。 至少对我来说，需要一些功夫才能弄懂它。你如果还是不太确定的话就再去读读Felix的博客文章。 让我们再来琢磨琢磨这个新概念。我们怎么证明，在创建完服务器之后，即使没有HTTP请求进来、我们的回调函数也没有被调用的情况下，我们的代码还继续有效呢？我们试试这个： var http = require(\"http\");function onRequest(request, response) &#123; console.log(\"Request received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end();&#125;http.createServer(onRequest).listen(8888);console.log(\"Server has started.\"); 注意：在 onRequest （我们的回调函数）触发的地方，我用 console.log 输出了一段文本。在HTTP服务器开始工作之后，也输出一段文本。 当我们与往常一样，运行它node server.js时，它会马上在命令行上输出“Server has started.”。当我们向服务器发出请求（在浏览器访问http://localhost:8888/ ），“Request received.”这条消息就会在命令行中出现。 这就是事件驱动的异步服务器端JavaScript和它的回调啦！ （请注意，当我们在服务器访问网页时，我们的服务器可能会输出两次“Request received.”。那是因为大部分浏览器都会在你访问 http://localhost:8888/ 时尝试读取 http://localhost:8888/favicon.ico ) 服务器是如何处理请求的好的，接下来我们简单分析一下我们服务器代码中剩下的部分，也就是我们的回调函数 onRequest() 的主体部分。 当回调启动，我们的 onRequest() 函数被触发的时候，有两个参数被传入： request 和 response 。 它们是对象，你可以使用它们的方法来处理HTTP请求的细节，并且响应请求（比如向发出请求的浏览器发回一些东西）。 所以我们的代码就是：当收到请求时，使用 response.writeHead() 函数发送一个HTTP状态200和HTTP头的内容类型（content-type），使用 response.write() 函数在HTTP相应主体中发送文本“Hello World”。 最后，我们调用 response.end() 完成响应。 目前来说，我们对请求的细节并不在意，所以我们没有使用 request 对象。 服务端的模块放在哪里 OK，就像我保证过的那样，我们现在可以回到我们如何组织应用这个问题上了。我们现在在 server.js 文件中有一个非常基础的HTTP服务器代码，而且我提到通常我们会有一个叫 index.js 的文件去调用应用的其他模块（比如 server.js 中的HTTP服务器模块）来引导和启动应用。 我们现在就来谈谈怎么把server.js变成一个真正的Node.js模块，使它可以被我们（还没动工）的 index.js 主文件使用。 也许你已经注意到，我们已经在代码中使用了模块了。像这样： var http = require(\"http\");...http.createServer(...); Node.js中自带了一个叫做“http”的模块，我们在我们的代码中请求它并把返回值赋给一个本地变量。 这把我们的本地变量变成了一个拥有所有 http 模块所提供的公共方法的对象。 给这种本地变量起一个和模块名称一样的名字是一种惯例，但是你也可以按照自己的喜好来： var foo = require(\"http\");...foo.createServer(...); 很好，怎么使用Node.js内部模块已经很清楚了。我们怎么创建自己的模块，又怎么使用它呢？ 等我们把 server.js 变成一个真正的模块，你就能搞明白了。 事实上，我们不用做太多的修改。把某段代码变成模块意味着我们需要把我们希望提供其功能的部分 导出 到请求这个模块的脚本。 目前，我们的HTTP服务器需要导出的功能非常简单，因为请求服务器模块的脚本仅仅是需要启动服务器而已。 我们把我们的服务器脚本放到一个叫做 start 的函数里，然后我们会导出这个函数。 var http = require(\"http\");function start() &#123; function onRequest(request, response) &#123; console.log(\"Request received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 这样，我们现在就可以创建我们的主文件 index.js 并在其中启动我们的HTTP了，虽然服务器的代码还在 server.js 中。 创建 index.js 文件并写入以下内容： var server = require(\"./server\");server.start(); 正如你所看到的，我们可以像使用任何其他的内置模块一样使用server模块：请求这个文件并把它指向一个变量，其中已导出的函数就可以被我们使用了。 好了。我们现在就可以从我们的主要脚本启动我们的的应用了，而它还是老样子： node index.js 非常好，我们现在可以把我们的应用的不同部分放入不同的文件里，并且通过生成模块的方式把它们连接到一起了。 我们仍然只拥有整个应用的最初部分：我们可以接收HTTP请求。但是我们得做点什么——对于不同的URL请求，服务器应该有不同的反应。 对于一个非常简单的应用来说，你可以直接在回调函数 onRequest() 中做这件事情。不过就像我说过的，我们应该加入一些抽象的元素，让我们的例子变得更有趣一点儿。 处理不同的HTTP请求在我们的代码中是一个不同的部分，叫做“路由选择”——那么，我们接下来就创造一个叫做路由的模块吧。 如何来进行请求的“路由”我们要为路由提供请求的URL和其他需要的GET及POST参数，随后路由需要根据这些数据来执行相应的代码（这里“代码”对应整个应用的第三部分：一系列在接收到请求时真正工作的处理程序）。 因此，我们需要查看HTTP请求，从中提取出请求的URL以及GET/POST参数。这一功能应当属于路由还是服务器（甚至作为一个模块自身的功能）确实值得探讨，但这里暂定其为我们的HTTP服务器的功能。 我们需要的所有数据都会包含在request对象中，该对象作为onRequest()回调函数的第一个参数传递。但是为了解析这些数据，我们需要额外的Node.JS模块，它们分别是url和querystring模块。 url.parse(string).query | url.parse(string).pathname | | | | | ------ -------------------http://localhost:8888/start?foo=bar&amp;hello=world --- ----- | | | | querystring(string)[\"foo\"] | | querystring(string)[\"hello\"] 当然我们也可以用querystring模块来解析POST请求体中的参数，稍后会有演示。 现在我们来给onRequest()函数加上一些逻辑，用来找出浏览器请求的URL路径： var http = require(\"http\");var url = require(\"url\");function start() &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 好了，我们的应用现在可以通过请求的URL路径来区别不同请求了–这使我们得以使用路由（还未完成）来将请求以URL路径为基准映射到处理程序上。 在我们所要构建的应用中，这意味着来自/start和/upload的请求可以使用不同的代码来处理。稍后我们将看到这些内容是如何整合到一起的。 现在我们可以来编写路由了，建立一个名为router.js的文件，添加以下内容： function route(pathname) &#123; console.log(\"About to route a request for \" + pathname);&#125;exports.route = route; 如你所见，这段代码什么也没干，不过对于现在来说这是应该的。在添加更多的逻辑以前，我们先来看看如何把路由和服务器整合起来。 我们的服务器应当知道路由的存在并加以有效利用。我们当然可以通过硬编码的方式将这一依赖项绑定到服务器上，但是其它语言的编程经验告诉我们这会是一件非常痛苦的事，因此我们将使用依赖注入的方式较松散地添加路由模块（你可以读读Martin Fowlers关于依赖注入的大作来作为背景知识）。 首先，我们来扩展一下服务器的start()函数，以便将路由函数作为参数传递过去： var http = require(\"http\");var url = require(\"url\");function start(route) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(pathname); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 同时，我们会相应扩展index.js，使得路由函数可以被注入到服务器中：var server = require(\"./server\");var router = require(\"./router\");server.start(router.route); 在这里，我们传递的函数依旧什么也没做。 如果现在启动应用（node index.js，始终记得这个命令行），随后请求一个URL，你将会看到应用输出相应的信息，这表明我们的HTTP服务器已经在使用路由模块了，并会将请求的路径传递给路由： bash$ node index.jsRequest for /foo received.About to route a request for /foo （以上输出已经去掉了比较烦人的/favicon.ico请求相关的部分）。 行为驱动执行请允许我再次脱离主题，在这里谈一谈函数式编程。 将函数作为参数传递并不仅仅出于技术上的考量。对软件设计来说，这其实是个哲学问题。想想这样的场景：在index文件中，我们可以将router对象传递进去，服务器随后可以调用这个对象的route函数。 就像这样，我们传递一个东西，然后服务器利用这个东西来完成一些事。 嗨那个叫路由的东西，能帮我把这个路由一下吗？ 但是服务器其实不需要这样的东西。它只需要把事情做完就行，其实为了把事情做完，你根本不需要东西，你需要的是动作。也就是说，你不需要名词，你需要动词。 理解了这个概念里最核心、最基本的思想转换后，我自然而然地理解了函数编程。 我是在读了Steve Yegge的大作名词王国中的死刑之后理解函数编程。你也去读一读这本书吧，真的。这是曾给予我阅读的快乐的关于软件的书籍之一。 路由给真正的请求处理程序回到正题，现在我们的HTTP服务器和请求路由模块已经如我们的期望，可以相互交流了，就像一对亲密无间的兄弟。 当然这还远远不够，路由，顾名思义，是指我们要针对不同的URL有不同的处理方式。例如处理/start的“业务逻辑”就应该和处理/upload的不同。 在现在的实现下，路由过程会在路由模块中“结束”，并且路由模块并不是真正针对请求“采取行动”的模块，否则当我们的应用程序变得更为复杂时，将无法很好地扩展。 我们暂时把作为路由目标的函数称为请求处理程序。现在我们不要急着来开发路由模块，因为如果请求处理程序没有就绪的话，再怎么完善路由模块也没有多大意义。 应用程序需要新的部件，因此加入新的模块 – 已经无需为此感到新奇了。我们来创建一个叫做requestHandlers的模块，并对于每一个请求处理程序，添加一个占位用函数，随后将这些函数作为模块的方法导出： function start() &#123; console.log(\"Request handler 'start' was called.\");&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\");&#125;exports.start = start;exports.upload = upload; 这样我们就可以把请求处理程序和路由模块连接起来，让路由“有路可寻”。 在这里我们得做个决定：是将requestHandlers模块硬编码到路由里来使用，还是再添加一点依赖注入？虽然和其他模式一样，依赖注入不应该仅仅为使用而使用，但在现在这个情况下，使用依赖注入可以让路由和请求处理程序之间的耦合更加松散，也因此能让路由的重用性更高。 这意味着我们得将请求处理程序从服务器传递到路由中，但感觉上这么做更离谱了，我们得一路把这堆请求处理程序从我们的主文件传递到服务器中，再将之从服务器传递到路由。 那么我们要怎么传递这些请求处理程序呢？别看现在我们只有2个处理程序，在一个真实的应用中，请求处理程序的数量会不断增加，我们当然不想每次有一个新的URL或请求处理程序时，都要为了在路由里完成请求到处理程序的映射而反复折腾。除此之外，在路由里有一大堆if request == x then call handler y也使得系统丑陋不堪。 仔细想想，有一大堆东西，每个都要映射到一个字符串（就是请求的URL）上？似乎关联数组（associative array） 能完美胜任。 不过结果有点令人失望，JavaScript没提供关联数组 – 也可以说它提供了？事实上，在JavaScript中，真正能提供此类功能的是它的对象。 在这方面，http://msdn.microsoft.com/en-us/magazine/cc163419.aspx 有一个不错的介绍，我在此摘录一段： 在C++或C#中，当我们谈到对象，指的是类或者结构体的实例。对象根据他们实例化的模板（就是所谓的类），会拥有不同的属性和方法。但在JavaScript里对象不是这个概念。在JavaScript中，对象就是一个键/值对的集合 – 你可以把JavaScript的对象想象成一个键为字符串类型的字典。 但如果JavaScript的对象仅仅是键/值对的集合，它又怎么会拥有方法呢？好吧，这里的值可以是字符串、数字或者……函数！ 好了，最后再回到代码上来。现在我们已经确定将一系列请求处理程序通过一个对象来传递，并且需要使用松耦合的方式将这个对象注入到route()函数中。 我们先将这个对象引入到主文件index.js中： var server = require(\"./server\");var router = require(\"./router\");var requestHandlers = require(\"./requestHandlers\");var handle = &#123;&#125;handle[\"/\"] = requestHandlers.start;handle[\"/start\"] = requestHandlers.start;handle[\"/upload\"] = requestHandlers.upload;server.start(router.route, handle); 虽然handle并不仅仅是一个“东西”（一些请求处理程序的集合），我还是建议以一个动词作为其命名，这样做可以让我们在路由中使用更流畅的表达式，稍后会有说明。 正如所见，将不同的URL映射到相同的请求处理程序上是很容易的：只要在对象中添加一个键为”/“的属性，对应requestHandlers.start即可，这样我们就可以干净简洁地配置/start和/的请求都交由start这一处理程序处理。 在完成了对象的定义后，我们把它作为额外的参数传递给服务器，为此将server.js修改如下： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(handle, pathname); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello World\"); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 这样我们就在start()函数里添加了handle参数，并且把handle对象作为第一个参数传递给了route()回调函数。 然后我们相应地在route.js文件中修改route()函数： function route(handle, pathname) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](); &#125; else &#123; console.log(\"No request handler found for \" + pathname); &#125;&#125;exports.route = route; 通过以上代码，我们首先检查给定的路径对应的请求处理程序是否存在，如果存在的话直接调用相应的函数。我们可以用从关联数组中获取元素一样的方式从传递的对象中获取请求处理函数，因此就有了简洁流畅的形如handlepathname;的表达式，这个感觉就像在前方中提到的那样：“嗨，请帮我处理了这个路径”。 有了这些，我们就把服务器、路由和请求处理程序在一起了。现在我们启动应用程序并在浏览器中访问http://localhost:8888/start，以下日志可以说明系统调用了正确的请求处理程序： Server has started.Request for /start received.About to route a request for /startRequest handler 'start' was called. 并且在浏览器中打开http://localhost:8888/可以看到这个请求同样被start请求处理程序处理了： Request for / received.About to route a request for /Request handler 'start' was called. 让请求处理程序作出响应很好。不过现在要是请求处理程序能够向浏览器返回一些有意义的信息而并非全是“Hello World”，那就更好了。 这里要记住的是，浏览器发出请求后获得并显示的“Hello World”信息仍是来自于我们server.js文件中的onRequest函数。 其实“处理请求”说白了就是“对请求作出响应”，因此，我们需要让请求处理程序能够像onRequest函数那样可以和浏览器进行“对话”。 不好的实现方式对于我们这样拥有PHP或者Ruby技术背景的开发者来说，最直截了当的实现方式事实上并不是非常靠谱： 看似有效，实则未必如此。 这里我指的“直截了当的实现方式”意思是：让请求处理程序通过onRequest函数直接返回（return()）他们要展示给用户的信息。 我们先就这样去实现，然后再来看为什么这不是一种很好的实现方式。 让我们从让请求处理程序返回需要在浏览器中显示的信息开始。我们需要将requestHandler.js修改为如下形式： function start() &#123; console.log(\"Request handler 'start' was called.\"); return \"Hello Start\";&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\"); return \"Hello Upload\";&#125;exports.start = start;exports.upload = upload; 好的。同样的，请求路由需要将请求处理程序返回给它的信息返回给服务器。因此，我们需要将router.js修改为如下形式： function route(handle, pathname) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; return handle[pathname](); &#125; else &#123; console.log(\"No request handler found for \" + pathname); return \"404 Not found\"; &#125;&#125;exports.route = route; 正如上述代码所示，当请求无法路由的时候，我们也返回了一些相关的错误信息。 最后，我们需要对我们的server.js进行重构以使得它能够将请求处理程序通过请求路由返回的内容响应给浏览器，如下所示： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); var content = route(handle, pathname) response.write(content); response.end(); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 如果我们运行重构后的应用，一切都会工作的很好：请求http://localhost:8888/start, 浏览器会输出“Hello Start”，请求http://localhost:8888/upload 会输出“Hello Upload”,而请求http://localhost:8888/foo 会输出“404 Not found”。 好，那么问题在哪里呢？简单的说就是： 当未来有请求处理程序需要进行非阻塞的操作的时候，我们的应用就“挂”了。 没理解？没关系，下面就来详细解释下。 阻塞与非阻塞正如此前所提到的，当在请求处理程序中包括非阻塞操作时就会出问题。但是，在说这之前，我们先来看看什么是阻塞操作。 我不想去解释“阻塞”和“非阻塞”的具体含义，我们直接来看，当在请求处理程序中加入阻塞操作时会发生什么。 这里，我们来修改下start请求处理程序，我们让它等待10秒以后再返回“Hello Start”。因为，JavaScript中没有类似sleep()这样的操作，所以这里只能够来点小Hack来模拟实现。 让我们将requestHandlers.js修改成如下形式： function start() &#123; console.log(\"Request handler 'start' was called.\"); function sleep(milliSeconds) &#123; var startTime = new Date().getTime(); while (new Date().getTime() &lt; startTime + milliSeconds); &#125; sleep(10000); return \"Hello Start\";&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\"); return \"Hello Upload\";&#125;exports.start = start;exports.upload = upload; 上述代码中，当函数start()被调用的时候，Node.js会先等待10秒，之后才会返回“Hello Start”。当调用upload()的时候，会和此前一样立即返回。 （当然了，这里只是模拟休眠10秒，实际场景中，这样的阻塞操作有很多，比方说一些长时间的计算操作等。） 接下来就让我们来看看，我们的改动带来了哪些变化。 如往常一样，我们先要重启下服务器。为了看到效果，我们要进行一些相对复杂的操作（跟着我一起做）： 首先，打开两个浏览器窗口或者标签页。在第一个浏览器窗口的地址栏中输入http://localhost:8888/start， 但是先不要打开它！ 在第二个浏览器窗口的地址栏中输入http://localhost:8888/upload， 同样的，先不要打开它！ 接下来，做如下操作：在第一个窗口中（“/start”）按下回车，然后快速切换到第二个窗口中（“/upload”）按下回车。 注意，发生了什么： /start URL加载花了10秒，这和我们预期的一样。但是，/upload URL居然也花了10秒，而它在对应的请求处理程序中并没有类似于sleep()这样的操作！ 这到底是为什么呢？原因就是start()包含了阻塞操作。形象的说就是“它阻塞了所有其他的处理工作”。 这显然是个问题，因为Node一向是这样来标榜自己的：“在node中除了代码，所有一切都是并行执行的”。 这句话的意思是说，Node.js可以在不新增额外线程的情况下，依然可以对任务进行并行处理 —— Node.js是单线程的。它通过事件轮询（event loop）来实现并行操作，对此，我们应该要充分利用这一点 —— 尽可能的避免阻塞操作，取而代之，多使用非阻塞操作。 然而，要用非阻塞操作，我们需要使用回调，通过将函数作为参数传递给其他需要花时间做处理的函数（比方说，休眠10秒，或者查询数据库，又或者是进行大量的计算）。 对于Node.js来说，它是这样处理的：“嘿，probablyExpensiveFunction()（译者注：这里指的就是需要花时间处理的函数），你继续处理你的事情，我（Node.js线程）先不等你了，我继续去处理你后面的代码，请你提供一个callbackFunction()，等你处理完之后我会去调用该回调函数的，谢谢！” （如果想要了解更多关于事件轮询细节，可以阅读Mixu的博文——理解node.js的事件轮询。） 接下来，我们会介绍一种错误的使用非阻塞操作的方式。 和上次一样，我们通过修改我们的应用来暴露问题。 这次我们还是拿start请求处理程序来“开刀”。将其修改成如下形式： var exec = require(\"child_process\").exec;function start() &#123; console.log(\"Request handler 'start' was called.\"); var content = \"empty\"; exec(\"ls -lah\", function (error, stdout, stderr) &#123; content = stdout; &#125;); return content;&#125;function upload() &#123; console.log(\"Request handler 'upload' was called.\"); return \"Hello Upload\";&#125;exports.start = start;exports.upload = upload; 上述代码中，我们引入了一个新的Node.js模块，child_process。之所以用它，是为了实现一个既简单又实用的非阻塞操作：exec()。 exec()做了什么呢？它从Node.js来执行一个shell命令。在上述例子中，我们用它来获取当前目录下所有的文件（“ls -lah”）,然后，当/startURL请求的时候将文件信息输出到浏览器中。 上述代码是非常直观的： 创建了一个新的变量content（初始值为“empty”），执行“ls -lah”命令，将结果赋值给content，最后将content返回。 和往常一样，我们启动服务器，然后访问“http://localhost:8888/start” 。 之后会载入一个漂亮的web页面，其内容为“empty”。怎么回事？ 这个时候，你可能大致已经猜到了，exec()在非阻塞这块发挥了神奇的功效。它其实是个很好的东西，有了它，我们可以执行非常耗时的shell操作而无需迫使我们的应用停下来等待该操作。 （如果想要证明这一点，可以将“ls -lah”换成比如“find /”这样更耗时的操作来效果）。 然而，针对浏览器显示的结果来看，我们并不满意我们的非阻塞操作，对吧？ 好，接下来，我们来修正这个问题。在这过程中，让我们先来看看为什么当前的这种方式不起作用。 问题就在于，为了进行非阻塞工作，exec()使用了回调函数。 在我们的例子中，该回调函数就是作为第二个参数传递给exec()的匿名函数： function (error, stdout, stderr) &#123; content = stdout;&#125; 现在就到了问题根源所在了：我们的代码是同步执行的，这就意味着在调用exec()之后，Node.js会立即执行 return content ；在这个时候，content仍然是“empty”，因为传递给exec()的回调函数还未执行到——因为exec()的操作是异步的。 我们这里“ls -lah”的操作其实是非常快的（除非当前目录下有上百万个文件）。这也是为什么回调函数也会很快的执行到 —— 不过，不管怎么说它还是异步的。 为了让效果更加明显，我们想象一个更耗时的命令： “find /”，它在我机器上需要执行1分钟左右的时间，然而，尽管在请求处理程序中，我把“ls -lah”换成“find /”，当打开/start URL的时候，依然能够立即获得HTTP响应 —— 很明显，当exec()在后台执行的时候，Node.js自身会继续执行后面的代码。并且我们这里假设传递给exec()的回调函数，只会在“find /”命令执行完成之后才会被调用。 那究竟我们要如何才能实现将当前目录下的文件列表显示给用户呢？ 好，了解了这种不好的实现方式之后，我们接下来来介绍如何以正确的方式让请求处理程序对浏览器请求作出响应。 以非阻塞操作进行请求响应我刚刚提到了这样一个短语 —— “正确的方式”。而事实上通常“正确的方式”一般都不简单。 不过，用Node.js就有这样一种实现方案： 函数传递。下面就让我们来具体看看如何实现。 到目前为止，我们的应用已经可以通过应用各层之间传递值的方式（请求处理程序 -&gt; 请求路由 -&gt; 服务器）将请求处理程序返回的内容（请求处理程序最终要显示给用户的内容）传递给HTTP服务器。 现在我们采用如下这种新的实现方式：相对采用将内容传递给服务器的方式，我们这次采用将服务器“传递”给内容的方式。 从实践角度来说，就是将response对象（从服务器的回调函数onRequest()获取）通过请求路由传递给请求处理程序。 随后，处理程序就可以采用该对象上的函数来对请求作出响应。 原理就是如此，接下来让我们来一步步实现这种方案。 先从server.js开始： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(handle, pathname, response); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 相对此前从route()函数获取返回值的做法，这次我们将response对象作为第三个参数传递给route()函数，并且，我们将onRequest()处理程序中所有有关response的函数调都移除，因为我们希望这部分工作让route()函数来完成。 下面就来看看我们的router.js: function route(handle, pathname, response) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](response); &#125; else &#123; console.log(\"No request handler found for \" + pathname); response.writeHead(404, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"404 Not found\"); response.end(); &#125;&#125;exports.route = route; 同样的模式：相对此前从请求处理程序中获取返回值，这次取而代之的是直接传递response对象。 如果没有对应的请求处理器处理，我们就直接返回“404”错误。 最后，我们将requestHandler.js修改为如下形式： var exec = require(\"child_process\").exec;function start(response) &#123; console.log(\"Request handler 'start' was called.\"); exec(\"ls -lah\", function (error, stdout, stderr) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(stdout); response.end(); &#125;);&#125;function upload(response) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello Upload\"); response.end();&#125;exports.start = start;exports.upload = upload; 我们的处理程序函数需要接收response参数，为了对请求作出直接的响应。 start处理程序在exec()的匿名回调函数中做请求响应的操作，而upload处理程序仍然是简单的回复“Hello World”，只是这次是使用response对象而已。 这时再次我们启动应用（node index.js），一切都会工作的很好。 如果想要证明/start处理程序中耗时的操作不会阻塞对/upload请求作出立即响应的话，可以将requestHandlers.js修改为如下形式： var exec = require(\"child_process\").exec;function start(response) &#123; console.log(\"Request handler 'start' was called.\"); exec(\"find /\", &#123; timeout: 10000, maxBuffer: 20000*1024 &#125;, function (error, stdout, stderr) &#123; response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(stdout); response.end(); &#125;);&#125;function upload(response) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello Upload\"); response.end();&#125;exports.start = start;exports.upload = upload; 这样一来，当请求http://localhost:8888/start 的时候，会花10秒钟的时间才载入，而当请求http://localhost:8888/upload 的时候，会立即响应，纵然这个时候/start响应还在处理中。 更有用的场景到目前为止，我们做的已经很好了，但是，我们的应用没有实际用途。 服务器，请求路由以及请求处理程序都已经完成了，下面让我们按照此前的用例给网站添加交互：用户选择一个文件，上传该文件，然后在浏览器中看到上传的文件。 为了保持简单，我们假设用户只会上传图片，然后我们应用将该图片显示到浏览器中。 好，下面就一步步来实现，鉴于此前已经对JavaScript原理性技术性的内容做过大量介绍了，这次我们加快点速度。 要实现该功能，分为如下两步： 首先，让我们来看看如何处理POST请求（非文件上传），之后，我们使用Node.js的一个用于文件上传的外部模块。之所以采用这种实现方式有两个理由。 第一，尽管在Node.js中处理基础的POST请求相对比较简单，但在这过程中还是能学到很多。第二，用Node.js来处理文件上传（multipart POST请求）是比较复杂的，它不在本书的范畴，但，如何使用外部模块却是在本书涉猎内容之内。 处理POST请求考虑这样一个简单的例子：我们显示一个文本区（textarea）供用户输入内容，然后通过POST请求提交给服务器。最后，服务器接受到请求，通过处理程序将输入的内容展示到浏览器中。 /start请求处理程序用于生成带文本区的表单，因此，我们将requestHandlers.js修改为如下形式： function start(response) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"Hello Upload\"); response.end();&#125;exports.start = start;exports.upload = upload; 好了，现在我们的应用已经很完善了，都可以获得威比奖（Webby Awards）了，哈哈。（译者注：威比奖是由国际数字艺术与科学学院主办的评选全球最佳网站的奖项，具体参见详细说明）通过在浏览器中访问http://localhost:8888/start 就可以看到简单的表单了，要记得重启服务器哦！ 你可能会说：这种直接将视觉元素放在请求处理程序中的方式太丑陋了。说的没错，但是，我并不想在本书中介绍诸如MVC之类的模式，因为这对于你了解JavaScript或者Node.js环境来说没多大关系。 余下的篇幅，我们来探讨一个更有趣的问题： 当用户提交表单时，触发/upload请求处理程序处理POST请求的问题。 现在，我们已经是新手中的专家了，很自然会想到采用异步回调来实现非阻塞地处理POST请求的数据。 这里采用非阻塞方式处理是明智的，因为POST请求一般都比较“重” —— 用户可能会输入大量的内容。用阻塞的方式处理大数据量的请求必然会导致用户操作的阻塞。 为了使整个过程非阻塞，Node.js会将POST数据拆分成很多小的数据块，然后通过触发特定的事件，将这些小数据块传递给回调函数。这里的特定的事件有data事件（表示新的小数据块到达了）以及end事件（表示所有的数据都已经接收完毕）。 我们需要告诉Node.js当这些事件触发的时候，回调哪些函数。怎么告诉呢？ 我们通过在request对象上注册监听器（listener） 来实现。这里的request对象是每次接收到HTTP请求时候，都会把该对象传递给onRequest回调函数。 如下所示： request.addListener(\"data\", function(chunk) &#123; // called when a new chunk of data was received&#125;);request.addListener(\"end\", function() &#123; // called when all chunks of data have been received&#125;); 问题来了，这部分逻辑写在哪里呢？ 我们现在只是在服务器中获取到了request对象 —— 我们并没有像之前response对象那样，把 request 对象传递给请求路由和请求处理程序。 在我看来，获取所有来自请求的数据，然后将这些数据给应用层处理，应该是HTTP服务器要做的事情。因此，我建议，我们直接在服务器中处理POST数据，然后将最终的数据传递给请求路由和请求处理器，让他们来进行进一步的处理。 因此，实现思路就是： 将data和end事件的回调函数直接放在服务器中，在data事件回调中收集所有的POST数据，当接收到所有数据，触发end事件后，其回调函数调用请求路由，并将数据传递给它，然后，请求路由再将该数据传递给请求处理程序。 还等什么，马上来实现。先从server.js开始： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var postData = \"\"; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); request.setEncoding(\"utf8\"); request.addListener(\"data\", function(postDataChunk) &#123; postData += postDataChunk; console.log(\"Received POST data chunk '\"+ postDataChunk + \"'.\"); &#125;); request.addListener(\"end\", function() &#123; route(handle, pathname, response, postData); &#125;); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 上述代码做了三件事情： 首先，我们设置了接收数据的编码格式为UTF-8，然后注册了“data”事件的监听器，用于收集每次接收到的新数据块，并将其赋值给postData 变量，最后，我们将请求路由的调用移到end事件处理程序中，以确保它只会当所有数据接收完毕后才触发，并且只触发一次。我们同时还把POST数据传递给请求路由，因为这些数据，请求处理程序会用到。 上述代码在每个数据块到达的时候输出了日志，这对于最终生产环境来说，是很不好的（数据量可能会很大，还记得吧？），但是，在开发阶段是很有用的，有助于让我们看到发生了什么。 我建议可以尝试下，尝试着去输入一小段文本，以及大段内容，当大段内容的时候，就会发现data事件会触发多次。 再来点酷的。我们接下来在/upload页面，展示用户输入的内容。要实现该功能，我们需要将postData传递给请求处理程序，修改router.js为如下形式： function route(handle, pathname, response, postData) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](response, postData); &#125; else &#123; console.log(\"No request handler found for \" + pathname); response.writeHead(404, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"404 Not found\"); response.end(); &#125;&#125;exports.route = route; 然后，在requestHandlers.js中，我们将数据包含在对upload请求的响应中： function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent: \" + postData); response.end();&#125;exports.start = start;exports.upload = upload; 好了，我们现在可以接收POST数据并在请求处理程序中处理该数据了。 我们最后要做的是： 当前我们是把请求的整个消息体传递给了请求路由和请求处理程序。我们应该只把POST数据中，我们感兴趣的部分传递给请求路由和请求处理程序。在我们这个例子中，我们感兴趣的其实只是text字段。 我们可以使用此前介绍过的querystring模块来实现： var querystring = require(\"querystring\");function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent the text: \"+ querystring.parse(postData).text); response.end();&#125;exports.start = start;exports.upload = upload; 好了，以上就是关于处理POST数据的全部内容。 处理文件上传最后，我们来实现我们最终的用例：允许用户上传图片，并将该图片在浏览器中显示出来。 回到90年代，这个用例完全可以满足用于IPO的商业模型了，如今，我们通过它能学到这样两件事情： 如何安装外部Node.js模块，以及如何将它们应用到我们的应用中。 这里我们要用到的外部模块是Felix Geisendörfer开发的node-formidable模块。它对解析上传的文件数据做了很好的抽象。 其实说白了，处理文件上传“就是”处理POST数据 —— 但是，麻烦的是在具体的处理细节，所以，这里采用现成的方案更合适点。 使用该模块，首先需要安装该模块。Node.js有它自己的包管理器，叫NPM。它可以让安装Node.js的外部模块变得非常方便。通过如下一条命令就可以完成该模块的安装： npm install formidable 如果终端输出如下内容： npm info build Success: formidable@1.0.9npm ok 就说明模块已经安装成功了。 现在我们就可以用formidable模块了——使用外部模块与内部模块类似，用require语句将其引入即可： var formidable = require(\"formidable\"); 这里该模块做的就是将通过HTTP POST请求提交的表单，在Node.js中可以被解析。我们要做的就是创建一个新的IncomingForm，它是对提交表单的抽象表示，之后，就可以用它解析request对象，获取表单中需要的数据字段。 node-formidable官方的例子展示了这两部分是如何融合在一起工作的： var formidable = require('formidable'), http = require('http'), util = require('util');http.createServer(function(req, res) &#123; if (req.url == '/upload' &amp;&amp; req.method.toLowerCase() == 'post') &#123; // parse a file upload var form = new formidable.IncomingForm(); form.parse(req, function(err, fields, files) &#123; res.writeHead(200, &#123;'content-type': 'text/plain'&#125;); res.write('received upload:\\n\\n'); res.end(util.inspect(&#123;fields: fields, files: files&#125;)); &#125;); return; &#125; // show a file upload form res.writeHead(200, &#123;'content-type': 'text/html'&#125;); res.end( '&lt;form action=\"/upload\" enctype=\"multipart/form-data\" '+ 'method=\"post\"&gt;'+ '&lt;input type=\"text\" name=\"title\"&gt;&lt;br&gt;'+ '&lt;input type=\"file\" name=\"upload\" multiple=\"multiple\"&gt;&lt;br&gt;'+ '&lt;input type=\"submit\" value=\"Upload\"&gt;'+ '&lt;/form&gt;' );&#125;).listen(8888); 如果我们将上述代码，保存到一个文件中，并通过node来执行，就可以进行简单的表单提交了，包括文件上传。然后，可以看到通过调用form.parse传递给回调函数的files对象的内容，如下所示： received upload:&#123; fields: &#123; title: 'Hello World' &#125;, files: &#123; upload: &#123; size: 1558, path: '/tmp/1c747974a27a6292743669e91f29350b', name: 'us-flag.png', type: 'image/png', lastModifiedDate: Tue, 21 Jun 2011 07:02:41 GMT, _writeStream: [Object], length: [Getter], filename: [Getter], mime: [Getter] &#125; &#125; &#125; 为了实现我们的功能，我们需要将上述代码应用到我们的应用中，另外，我们还要考虑如何将上传文件的内容（保存在/tmp目录中）显示到浏览器中。 我们先来解决后面那个问题： 对于保存在本地硬盘中的文件，如何才能在浏览器中看到呢？ 显然，我们需要将该文件读取到我们的服务器中，使用一个叫fs的模块。 我们来添加/showURL的请求处理程序，该处理程序直接硬编码将文件/tmp/test.png内容展示到浏览器中。当然了，首先需要将该图片保存到这个位置才行。 将requestHandlers.js修改为如下形式： var querystring = require(\"querystring\"), fs = require(\"fs\");function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" '+ 'content=\"text/html; charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" method=\"post\"&gt;'+ '&lt;textarea name=\"text\" rows=\"20\" cols=\"60\"&gt;&lt;/textarea&gt;'+ '&lt;input type=\"submit\" value=\"Submit text\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent the text: \"+ querystring.parse(postData).text); response.end();&#125;function show(response, postData) &#123; console.log(\"Request handler 'show' was called.\"); fs.readFile(\"/tmp/test.png\", \"binary\", function(error, file) &#123; if(error) &#123; response.writeHead(500, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(error + \"\\n\"); response.end(); &#125; else &#123; response.writeHead(200, &#123;\"Content-Type\": \"image/png\"&#125;); response.write(file, \"binary\"); response.end(); &#125; &#125;);&#125;exports.start = start;exports.upload = upload;exports.show = show; 我们还需要将这新的请求处理程序，添加到index.js中的路由映射表中： var server = require(\"./server\");var router = require(\"./router\");var requestHandlers = require(\"./requestHandlers\");var handle = &#123;&#125;handle[\"/\"] = requestHandlers.start;handle[\"/start\"] = requestHandlers.start;handle[\"/upload\"] = requestHandlers.upload;handle[\"/show\"] = requestHandlers.show;server.start(router.route, handle); 重启服务器之后，通过访问http://localhost:8888/show，就可以看到保存在/tmp/test.png的图片了。 好，最后我们要的就是： 在/start表单中添加一个文件上传元素 将node-formidable整合到我们的upload请求处理程序中，用于将上传的图片保存到/tmp/test.png 将上传的图片内嵌到/uploadURL输出的HTML中 第一项很简单。只需要在HTML表单中，添加一个multipart/form-data的编码类型，移除此前的文本区，添加一个文件上传组件，并将提交按钮的文案改为“Upload file”即可。 如下requestHandler.js所示： var querystring = require(\"querystring\"), fs = require(\"fs\");function start(response, postData) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" '+ 'content=\"text/html; charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" enctype=\"multipart/form-data\" '+ 'method=\"post\"&gt;'+ '&lt;input type=\"file\" name=\"upload\"&gt;'+ '&lt;input type=\"submit\" value=\"Upload file\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, postData) &#123; console.log(\"Request handler 'upload' was called.\"); response.writeHead(200, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(\"You've sent the text: \"+ querystring.parse(postData).text); response.end();&#125;function show(response, postData) &#123; console.log(\"Request handler 'show' was called.\"); fs.readFile(\"/tmp/test.png\", \"binary\", function(error, file) &#123; if(error) &#123; response.writeHead(500, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(error + \"\\n\"); response.end(); &#125; else &#123; response.writeHead(200, &#123;\"Content-Type\": \"image/png\"&#125;); response.write(file, \"binary\"); response.end(); &#125; &#125;);&#125;exports.start = start;exports.upload = upload;exports.show = show; 很好。下一步相对比较复杂。这里有这样一个问题： 我们需要在upload处理程序中对上传的文件进行处理，这样的话，我们就需要将request对象传递给node-formidable的form.parse函数。 但是，我们有的只是response对象和postData数组。看样子，我们只能不得不将request对象从服务器开始一路通过请求路由，再传递给请求处理程序。 或许还有更好的方案，但是，不管怎么说，目前这样做可以满足我们的需求。 到这里，我们可以将postData从服务器以及请求处理程序中移除了 —— 一方面，对于我们处理文件上传来说已经不需要了，另外一方面，它甚至可能会引发这样一个问题： 我们已经“消耗”了request对象中的数据，这意味着，对于form.parse来说，当它想要获取数据的时候就什么也获取不到了。（因为Node.js不会对数据做缓存） 我们从server.js开始 —— 移除对postData的处理以及request.setEncoding （这部分node-formidable自身会处理），转而采用将request对象传递给请求路由的方式： var http = require(\"http\");var url = require(\"url\");function start(route, handle) &#123; function onRequest(request, response) &#123; var pathname = url.parse(request.url).pathname; console.log(\"Request for \" + pathname + \" received.\"); route(handle, pathname, response, request); &#125; http.createServer(onRequest).listen(8888); console.log(\"Server has started.\");&#125;exports.start = start; 接下来是 router.js —— 我们不再需要传递postData了，这次要传递request对象： function route(handle, pathname, response, request) &#123; console.log(\"About to route a request for \" + pathname); if (typeof handle[pathname] === 'function') &#123; handle[pathname](response, request); &#125; else &#123; console.log(\"No request handler found for \" + pathname); response.writeHead(404, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(\"404 Not found\"); response.end(); &#125;&#125;exports.route = route; 现在，request对象就可以在我们的upload请求处理程序中使用了。node-formidable会处理将上传的文件保存到本地/tmp目录中，而我们需要做的是确保该文件保存成/tmp/test.png。 没错，我们保持简单，并假设只允许上传PNG图片。 这里采用fs.renameSync(path1,path2)来实现。要注意的是，正如其名，该方法是同步执行的， 也就是说，如果该重命名的操作很耗时的话会阻塞。 这块我们先不考虑。 接下来，我们把处理文件上传以及重命名的操作放到一起，如下requestHandlers.js所示： var querystring = require(\"querystring\"), fs = require(\"fs\"), formidable = require(\"formidable\");function start(response) &#123; console.log(\"Request handler 'start' was called.\"); var body = '&lt;html&gt;'+ '&lt;head&gt;'+ '&lt;meta http-equiv=\"Content-Type\" content=\"text/html; '+ 'charset=UTF-8\" /&gt;'+ '&lt;/head&gt;'+ '&lt;body&gt;'+ '&lt;form action=\"/upload\" enctype=\"multipart/form-data\" '+ 'method=\"post\"&gt;'+ '&lt;input type=\"file\" name=\"upload\" multiple=\"multiple\"&gt;'+ '&lt;input type=\"submit\" value=\"Upload file\" /&gt;'+ '&lt;/form&gt;'+ '&lt;/body&gt;'+ '&lt;/html&gt;'; response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(body); response.end();&#125;function upload(response, request) &#123; console.log(\"Request handler 'upload' was called.\"); var form = new formidable.IncomingForm(); console.log(\"about to parse\"); form.parse(request, function(error, fields, files) &#123; console.log(\"parsing done\"); fs.renameSync(files.upload.path, \"/tmp/test.png\"); response.writeHead(200, &#123;\"Content-Type\": \"text/html\"&#125;); response.write(\"received image:&lt;br/&gt;\"); response.write(\"&lt;img src='/show' /&gt;\"); response.end(); &#125;);&#125;function show(response) &#123; console.log(\"Request handler 'show' was called.\"); fs.readFile(\"/tmp/test.png\", \"binary\", function(error, file) &#123; if(error) &#123; response.writeHead(500, &#123;\"Content-Type\": \"text/plain\"&#125;); response.write(error + \"\\n\"); response.end(); &#125; else &#123; response.writeHead(200, &#123;\"Content-Type\": \"image/png\"&#125;); response.write(file, \"binary\"); response.end(); &#125; &#125;);&#125;exports.start = start;exports.upload = upload;exports.show = show; 好了，重启服务器，我们应用所有的功能就可以用了。选择一张本地图片，将其上传到服务器，然后浏览器就会显示该图片。 总结与展望恭喜，我们的任务已经完成了！我们开发完了一个Node.js的web应用，应用虽小，但却“五脏俱全”。 期间，我们介绍了很多技术点：服务端JavaScript、函数式编程、阻塞与非阻塞、回调、事件、内部和外部模块等等。 当然了，还有许多本书没有介绍到的： 如何操作数据库、如何进行单元测试、如何开发Node.js的外部模块以及一些简单的诸如如何获取GET请求之类的方法。 但本书毕竟只是一本给初学者的教程 —— 不可能覆盖到所有的内容。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/","raw":null,"content":null,"categories":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/categories/read/"}],"tags":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/tags/read/"},{"name":"nodejs","slug":"nodejs","permalink":"http://agehua.github.io/tags/nodejs/"}]},{"title":"JAVA泛型通配符T，E，K，V区别，T以及Class<T>，Class<?>的区别","slug":"Difference_between-T-E-K-V","date":"2016-11-20T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/11/21/Difference_between-T-E-K-V/","link":"","permalink":"http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/","excerpt":"\n文章转载自《JAVA泛型通配符T，E，K，V区别，T以及Class，Class&lt;?&gt;的区别》\n\n1. 先解释下泛型概念泛型是Java SE 1.5的新特性，泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口、泛型方法。Java语言引入泛型的好处是安全简单。\n在Java SE 1.5之前，没有泛型的情况的下，通过对类型Object的引用来实现参数的“任意化”，“任意化”带来的缺点是要做显式的强制类型转换，而这种转换是要求开发者对实际参数类型可以预知的情况下进行的。对于强制类型转换错误的情况，编译器可能不提示错误，在运行的时候才出现异常，这是一个安全隐患。","text":"文章转载自《JAVA泛型通配符T，E，K，V区别，T以及Class，Class&lt;?&gt;的区别》 1. 先解释下泛型概念泛型是Java SE 1.5的新特性，泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口、泛型方法。Java语言引入泛型的好处是安全简单。 在Java SE 1.5之前，没有泛型的情况的下，通过对类型Object的引用来实现参数的“任意化”，“任意化”带来的缺点是要做显式的强制类型转换，而这种转换是要求开发者对实际参数类型可以预知的情况下进行的。对于强制类型转换错误的情况，编译器可能不提示错误，在运行的时候才出现异常，这是一个安全隐患。 泛型的好处是在编译的时候检查类型安全，并且所有的强制转换都是自动和隐式的，以提高代码的重用率。 以上内容摘自百度百科 举个栗子:Box类定义为一个泛型类public class Box&lt;T&gt; &#123; private T object; public void set(T object) &#123; this.object = object; &#125; public T get() &#123; return object; &#125;&#125; 创建一个Box对象，不带泛型参数，发现获取对象的时候需要强制转换 Box box2 = new Box();box2.set(new Apple());Apple apple = (Apple) box2.get(); 创建一个Box对象，带泛型参数，获取对象的时候就不需要强制转换 Box&lt;Apple&gt; box = new Box&lt;Apple&gt;();box.set(new Apple());Apple apple = box.get(); 总结下泛型的好处就是： 省去了强制转换，可以在编译时候检查类型安全，可以用在类，方法，接口上 但是我们定义泛型类，泛型方法，泛型接口的时候经常会碰见很多不同的通配符T，E，K，V等等，这些通配符又都是什么意思呢？继续往下看 2. 下来说说泛型通配符T，E，K，V区别这些全都属于java泛型的通配符，刚开始我看到这么多通配符，一下晕了，这几个其实没什么区别，只不过是一个约定好的代码，也就是说使用大写字母A,B,C,D……X,Y,Z定义的，就都是泛型，把T换成A也一样，这里T只是名字上的意义而已 ？ 表示不确定的java类型 T (type) 表示具体的一个java类型 K V (key value) 分别代表java键值中的Key Value E (element) 代表Element 举个栗子：public class Test&lt;T&gt; &#123; public List&lt;T&gt; list = new ArrayList&lt;T&gt;(); public static void main(String[] args) &#123; Test&lt;String&gt; test = new Test&lt;String&gt;(); test.list.add(\"hello\"); System.out.println(test.list);&#125;&#125; 和public class Test&lt;A&gt; &#123; public List&lt;A&gt; list = new ArrayList&lt;A&gt;(); public static void main(String[] args) &#123; Test&lt;String&gt; test = new Test&lt;String&gt;(); test.list.add(\"hello\"); System.out.println(test.list);&#125;&#125; 将T换成了A，在执行效果上是没有任何区别的，只不过我们约定好了T代表type，所以还是按照约定规范来比较好，增加了代码的可读性。 如果要定义多个泛型参数，比如说两个泛型参数，很典型的一个栗子是Map的key,value泛型，我们也可以定义一个这样的public interface Mymap&lt;K, V&gt; &#123; public K getKey(); public V getValue();&#125;public class MymapImpl&lt;K, V&gt; implements Mymap&lt;K, V&gt; &#123; private K key; private V value; public MymapImpl(K key, V value) &#123; this.key = key; this.value = value; &#125; public K getKey() &#123; return key; &#125; public V getValue() &#123; return value; &#125;&#125; 下来就可以传入任意类型，创建实例了，不用转化类型Mymap&lt;String, Integer&gt; mp1= new MymapImpl&lt;String, Integer&gt;(\"Even\", 8);Mymap&lt;String, String&gt; mp2= new MymapImpl&lt;String, String&gt;(\"hello\", \"world\");Mymap&lt;Integer, Integer&gt; mp3= new MymapImpl&lt;Integer, Integer&gt;(888, 888); 如果要定义超过两个，三个或三个以上的泛型参数可以使用T1, T2, …, Tn，像这样子public class Test&lt;T1,T2,T3&gt; &#123; public void print(T1 t1,T2 t2,T3 t3)&#123; System.out.println(t1.getClass()); System.out.println(t2.getClass()); System.out.println(t3.getClass()); &#125;&#125; 3. 下来说说T，Class，Class&lt;?&gt;区别T是一种具体的类，例如String,List,Map……等等，这些都是属于具体的类，这个比较好理解 Class是什么呢，Class也是一个类，但Class是存放上面String,List,Map……类信息的一个类，有点抽象，我们一步一步来看 。 如何获取到Class类呢，有三种方式： 调用Object类的getClass()方法来得到Class对象，这也是最常见的产生Class对象的方法。例如：List list = null;Class clazz = list.getClass(); 使用Class类的中静态forName()方法获得与字符串对应的Class对象。例如： Class clazz = Class.forName(\"com.lyang.demo.fanxing.People\"); 3.获取Class类型对象的第三个方法非常简单。如果T是一个Java类型，那么T.class就代表了匹配的类对象。Class clazz = List.class; 那么问题来了？Class类是创建出来了，但是Class和Class&lt;?&gt;适用于什么时候呢？？？ 使用Class和Class&lt;?&gt;多发生在反射场景下，先看看如果我们不使用泛型，反射创建一个类是什么样的。People people = (People) Class.forName(\"com.lyang.demo.fanxing.People\").newInstance(); 看到了么，需要强转，如果反射的类型不是People类，就会报java.lang.ClassCastException错误。 使用Class泛型后，不用强转了public class Test &#123; public static &lt;T&gt; T createInstance(Class&lt;T&gt; clazz) throws IllegalAccessException, InstantiationException &#123; return clazz.newInstance(); &#125; public static void main(String[] args) throws IllegalAccessException, InstantiationException &#123; Fruit fruit= createInstance(Fruit .class); People people= createInstance(People.class); &#125;&#125; 那Class和Class&lt;?&gt;有什么区别呢？ Class在实例化的时候，T要替换成具体类 Class&lt;?&gt;它是个通配泛型，?可以代表任何类型，主要用于声明时的限制情况 例如可以声明一个public Class&lt;?&gt; clazz; 但是你不能声明一个public Class&lt;T&gt; clazz; 因为T需要指定类型 所以当不知道定声明什么类型的Class的时候可以定义一个Class&lt;?&gt;,Class&lt;?&gt;可以用于参数类型定义，方法返回值定义等。 也可以参考：https://juejin.cn/post/6844903917835419661 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"genericity","slug":"genericity","permalink":"http://agehua.github.io/tags/genericity/"}]},{"title":"Hexo 出错情况收集","slug":"hexo-mac-module-not-found","date":"2016-11-02T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/11/03/hexo-mac-module-not-found/","link":"","permalink":"http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/","excerpt":"Error: Cannot find module ‘./build/Release/DTraceProviderBindings’我在更新hexo，准备安装别的module时，不小心按到了 ctrl+c，结果发现使用hexo命令会报如下错误：&#123; [Error: Cannot find module './build/Release/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;    &#123; [Error: Cannot find module './build/default/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;&#123; [Error: Cannot find module './build/Debug/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;","text":"Error: Cannot find module ‘./build/Release/DTraceProviderBindings’我在更新hexo，准备安装别的module时，不小心按到了 ctrl+c，结果发现使用hexo命令会报如下错误：&#123; [Error: Cannot find module './build/Release/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125; &#123; [Error: Cannot find module './build/default/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125;&#123; [Error: Cannot find module './build/Debug/DTraceProviderBindings'] code: 'MODULE_NOT_FOUND' &#125; 网上一大堆的解决办法都不好用，这里特别记录下我找到的一个解决办法，亲测可用 1. 重新安装Hexo，需要手动删除隐藏的hexo文件 需要删除 /usr/local/lib/node_modules/ 目录下的hexo文件夹 /usr/local/bin/ 下的hexo文件. 直接删掉就好了. 注意这两个都是隐藏文件，要想在finder中显示隐藏文件，需要在Terminal中执行：defaults write com.apple.finder AppleShowAllFiles -bool true 2. 重新执行命令：npm install -g hexo –save 这样就可以了 :) 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Hexo","slug":"hexo","permalink":"http://agehua.github.io/tags/hexo/"}]},{"title":"gradle 学习2——生成指定文件名的apk","slug":"gradle-learning2","date":"2016-10-12T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2016/10/13/gradle-learning2/","link":"","permalink":"http://agehua.github.io/2016/10/13/gradle-learning2/","excerpt":"上一篇Gradle学习了解了Gradle的基本结构和依赖关系，这篇文章介绍下怎么在Android上使用Gradle生成指定包名的APK\n需求场景在我们Android开发基本进入测试阶段后，会根据后台的不同环境，打包出对应不同环境（如SIT、UAT、PRD等）的APK安装包。\n每次去手动修改Java类改变后台环境太麻烦还容易忘记修改。打包成功后，还需要手动将默认的包名app-release.apk改成我们需要的包名，也是非常麻烦，有没有直接指定环境，生成指定文件名的安装包呢？\n方法是有的，就是利用gradle的分渠道打包特性，下面上代码分别解释。\n\n主要在这两个个地方修改：\n\nbuildType（构建类型）\nproductFlavors （不同定制的产品）\n\n","text":"上一篇Gradle学习了解了Gradle的基本结构和依赖关系，这篇文章介绍下怎么在Android上使用Gradle生成指定包名的APK 需求场景在我们Android开发基本进入测试阶段后，会根据后台的不同环境，打包出对应不同环境（如SIT、UAT、PRD等）的APK安装包。 每次去手动修改Java类改变后台环境太麻烦还容易忘记修改。打包成功后，还需要手动将默认的包名app-release.apk改成我们需要的包名，也是非常麻烦，有没有直接指定环境，生成指定文件名的安装包呢？ 方法是有的，就是利用gradle的分渠道打包特性，下面上代码分别解释。 主要在这两个个地方修改： buildType（构建类型） productFlavors （不同定制的产品） buildType（构建类型）介绍默认情况下，Android Plugin会自动给项目设置同时构建应用程序的debug和release版本。 两个版本之间的不同主要围绕着能否在一个安全设备上调试，以及APK如何签名。 可以创建一个新的构建类型就是简单的在buildType标签下添加一个新的元素，并且可以使用initWith()或者直接使用闭包来配置它。 以下是一些可能使用到的属性和默认值： Property name Default values for debug Default values for release / other debuggable true false jniDebugBuild false false renderscriptDebugBuild false false renderscriptOptimLevel 3 3 applicationIdSuffix null null versionNameSuffix null null signingConfig android.signingConfigs.debug null zipAlign false true runProguard false false proguardFile N/A (set only) N/A (set only) proguardFiles N/A (set only) N/A (set only) 上面介绍摘选自Gralde plugin User Guide 中文版 Product flavors（不同定制的产品）介绍一个product flavor定义了从项目中构建了一个应用的自定义版本。一个单一的项目可以同时定义多个不同的flavor来改变应用的输出。 这个新的设计概念是为了解决不同的版本之间的差异非常小的情况。虽然最项目终生成了多个定制的版本，但是它们本质上都是同一个应用，那么这种做法可能是比使用库项目更好的实现方式。 Product flavor需要在productFlavors这个DSL容器中声明： android &#123; .... productFlavors &#123; flavor1 &#123; ... &#125; flavor2 &#123; ... &#125; &#125;&#125; 这里创建了两个flavor，名为flavor1和flavor2。 注意：flavor的命名不能与已存在的Build Type或者androidTest这个sourceSet有冲突。 Build Type + Product Flavor = Build Variant（构建类型+定制产品=构建变种版本）正如前面章节所提到的，每一个Build Type都会生成一个新的APK。 Product Flavor同样也会做这些事情：项目的输出将会拼接所有可能的Build Type和Product Flavor（如果有Flavor定义存在的话）的组合。 每一种组合（包含Build Type和Product Flavor）就是一个Build Variant（构建变种版本）。 例如，在上面的Flavor声明例子中与默认的debug和release两个Build Type将会生成4个Build Variant： Flavor1 - debug Flavor1 - release Flavor2 - debug Flavor2 - release 项目中如果没有定义flavor同样也会有Build Variant，只是使用的是默认的flavor和配置。default(默认)的flavor/config是没有名字的，所以生成的Build Variant列表看起来就跟Build Type列表一样。 具体使用我们的需求就要用到Build Type和Product Flavor我在项目中Build Type的使用，先看代码： buildTypes &#123; release &#123; buildConfigField \"boolean\", \"LEO_DEBUG\", \"false\" minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt' debuggable false jniDebuggable false &#125; debug &#123; buildConfigField \"int\", \"buildType\", \"2\" buildConfigField \"boolean\", \"LEO_DEBUG\", \"true\" &#125; &#125; 和Product Flavor的使用 productFlavors&#123; kaifa&#123; buildConfigField \"int\", \"buildType\", \"1\" &#125; ceshi &#123; buildConfigField \"int\", \"buildType\", \"2\" &#125; SIT &#123; buildConfigField \"int\", \"buildType\", \"3\" &#125; UAT &#123; buildConfigField \"int\", \"buildType\", \"4\" &#125; PRD &#123; buildConfigField \"int\", \"buildType\", \"5\" &#125;&#125; 每一个构建过的productFlavors都会在app-&gt;build-&gt;generated-&gt;source-&gt;buildConfig目录下创建自己对应的一个flavor目录，如下图： 而，buildConfigField会在指定的目录，flavor-&gt;release/debug-&gt;包名，下生成一个BuildConfig.java文件，我的代码在BuildConfig.java中定义了一个int类型的buildType和boolean类型的LEO_DEBUG。要使用这两个字段只需要: if (BuildConfig.LEO_DEBUG)&#123; //用来控制本地Log日志&#125;if (Environment ==BuildConfig.buildType)&#123; //用来控制开发环境&#125; gradle中修改apk生成名字的方法这个方法是定义在productFlavors同一层级的 android.applicationVariants.all &#123; variant -&gt; variant.outputs.each &#123; output -&gt; def outputFile = output.outputFile if (outputFile != null &amp;&amp; outputFile.name.endsWith('.apk')) &#123; //这里修改apk文件名 def flavorname =variant.productFlavors[0].name if (flavorname.equals('kaifa')) flavorname = 'debug' else if (flavorname.equals('ceshi')) flavorname = 'release' def fileName = \"app-$&#123;flavorname&#125;-$&#123;defaultConfig.versionName&#125;-$&#123;releaseTime() &#125;.apk\" output.outputFile = new File(outputFile.parent, fileName) &#125; &#125; &#125; 这个方法要定义在最外层def releaseTime() &#123; return new Date().format(\"MMdd\", TimeZone.getTimeZone(\"UTC\"))&#125; 最后生成的apk名字 Mac下Android Studio中获取SHA1和MD5打开Android Studio中的Terminal，也可以直接打开系统的终端 获取debug.keystore的SHA1和MD5输入: keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android 获取其他keystore的，如正式签名文件的，keytool -list -v -keystore ~/User/你的用户名/debug.keystore -alias androiddebugkey -storepass android -keypass android 需要把路径和密码改成相应的就可以了 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/10/13/gradle-learning2/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gradle","slug":"gradle","permalink":"http://agehua.github.io/tags/gradle/"}]},{"title":"gradle 学习","slug":"gradle-learning","date":"2016-10-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/10/12/gradle-learning/","link":"","permalink":"http://agehua.github.io/2016/10/12/gradle-learning/","excerpt":"Gradle是一种依赖管理工具，基于Groovy语言，面向Java应用为主，它抛弃了基于XML的各种繁琐配置，取而代之的是一种基于Groovy的内部领域特定（DSL）语言。它提供灵活的通用构建工具，就像ant。同时完美兼容Maven或Ivy仓库\nGradle的基本组成\n项目(Project) 和 任务(tasks)，Gradle 里的任何东西都是基于这两个基础概念。\n","text":"Gradle是一种依赖管理工具，基于Groovy语言，面向Java应用为主，它抛弃了基于XML的各种繁琐配置，取而代之的是一种基于Groovy的内部领域特定（DSL）语言。它提供灵活的通用构建工具，就像ant。同时完美兼容Maven或Ivy仓库 Gradle的基本组成 项目(Project) 和 任务(tasks)，Gradle 里的任何东西都是基于这两个基础概念。 项目是指我们的构建产物（比如Jar包）或实施产物（将应用程序部署到生产环境）。 任务是指不可分的最小工作单元，执行构建工作（比如编译项目或执行测试）。 每一个构建都是由一个或多个 projects 构成的，每一个 project 是由一个或多个 tasks 构成的，一个 task是指不可分的最小工作单元，执行构建工作（比如编译项目或执行测试） 一个工程的Build，是由多个Project组成，而一个Project又是由task组成的 任何一个构建系统都是由多个构建文件组成，如Ant是由build.xml组成，Maven是由pom.xml组成，Make是由makefile组成。这些构建脚本定义了一系列的规则来指定项目编译流程。 Gradle构建系统的组成Gradle的构建系统是由以下几个文件组成 build.gradle 我们称这个文件为一个构建脚本，这个脚本定义了一个模块和编译用的tasks，它一般是放在项目的模块中，也可以放在项目的根目录用来作为编译结构全局设置，它是必须的 settings.gradle 它描述了哪一个模块需要参与构建。每一个多模块的构建都必须在项目结构的根目录中加入这个设置文件，它也是必须的 gradle.properties 用来配置构建属性，这个不是必须的 Gradle插件Gradle的设计理念是，所有有用的特性都由Gradle插件提供，例如编写一个Java项目时，需要使用到 Java 插件， 它会将许多任务自动的加入到你项目里。Gradle本身提供了一系列的标准插件，无需多余配置只需要在你的build.gradle文件中加入 apply plugin: ‘java’ 这样就可以引入许多task，只需要使用相应的task命令就可以进行项目构建。例如下列一些task: 1.gradle build：编译整个项目，它会执行代码编译、代码检测和单元测试等 2.gradle assemble：编译并打包你的代码, 但是并不运行代码检测和单元测试 3.gradle clean：删除 build 生成的目录和所有生成的文件 4.gradle check：编译并测试你的代码。其它的插件会加入更多的检查步骤，如使用 checkstyle、pmd、findbugs Gradle各个task的关系图： 从上图可以看出，我们通常在执行一个build命令时其实是将一些零散的命令批量执行了，我们也可以根据自己的需求执行其中某一个命令。 外部依赖通常, 一个 Java 项目将有许多外部的依赖, 既指向外部的 JAR 文件. 为了在项目里引用这些 JAR 文件, 你需要告诉 Gradle 去哪里找它们. 在 Gradle 中, JAR 文件位于一个仓库中，这里的仓库类似于 maven 的仓库。 首先，指定maven的仓库地址： repositories &#123; mavenCentral()&#125; mavenCentral() 是Gradle内置的一个maven仓库地址，加入maven仓库后，就可以直接加入maven仓库中的外部依赖，如果这个外部依赖不存在，gradle会联网去maven仓库中自动下载它，并将它缓存到本地，下次再使用时会优先从本地缓存中查找该依赖。 dependencies &#123; compile group: 'commons-collections', name: 'commons-collections', version: '3.2' // 简化写法 // compile 'commons-collections:commons-collections:3.2'&#125; 引用一个外部依赖需要指定使用的group, name 和 version 属性，三者缺一不可。那从哪里得知JAR包的这三个属性呢？我们可以从mvnrepository中搜索到。 本地依赖Gradle也可以从本地目录中引入JAR包依赖，可以单一引入指定的某一JAR包，也可以引入某目录下所有的JAR包 dependencies &#123; compile files('dir/file.jar') compile fileTree(dir: 'libs', include: '*.jar')&#125; 项目依赖往往一个完整的项目由多个子项目构成。在Gradle中，使用文件settings.gradle定义当前项目的子项目。默认情况下，每个子项目的名称对应着当前操作系统目录下的一个子目录。 include 'sub-project1', 'sub-project2', 'sub-project3' 如sub-project1依赖sub-project2，则在sub-project1的build.gradle中加入以下配置即可： dependencies &#123; compile project(':sub-project2')&#125; 依赖关系管理从宏观上说，依赖关系管理分为两个方面。首先，gradle需要知道你要构建或者运行的项目，以便找到它们。我们将这些导入的文件视为项目的依赖。第二，gradle需要构建或者打包你的项目产品。我们将这些导出的文件视为项目的发布。 例如在编译源码时项目需要Hibernate的某些jar包被加入到工程中，而在进行单元测试时还另需要Junit的某些jar被加入。这些被引入的jar包就是项目的依赖。Gradle允许对依赖进行相应的配置，通过不同的配置可以形成不同的依赖效果。例如： apply plugin: 'java'repositories &#123; mavenCentral()&#125;dependencies &#123; compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final' testCompile group: 'junit', name: 'junit', version: '4.+'&#125; 在项目编译时期，junit的jar包不会被引入，只有在单元测试时才会被引入。这样，就可以在不同的场景下加入相应的依赖关系，非常的灵活 Java 插件中定义了许多标准的配置，例如如下： compile 用来编译项目源代码的 runtime 在运行时被生成的类使用的依赖。 默认的, 也包含了compile时的依赖。 testCompile 编译测试代码的依赖。 默认的, 包含runtime时的依赖和compile时的依赖。 testRuntime 运行测试所需要的依赖。 默认的, 包含上面三个依赖。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/10/12/gradle-learning/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gradle","slug":"gradle","permalink":"http://agehua.github.io/tags/gradle/"}]},{"title":"Android面试知识点整理","slug":"Android-interview-questions","date":"2016-09-27T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/09/28/Android-interview-questions/","link":"","permalink":"http://agehua.github.io/2016/09/28/Android-interview-questions/","excerpt":"只整理android面试中涉及到的知识点。不断补充中。。。\n1.Android事件传递机制下面内容摘选自《Android开发艺术探索》\n\n(1) 当一个点击事件发生之后，传递过程遵循如下顺序：Activity -&gt; Window -&gt; View。如果一个view的onTouchEvent方法返回false，那么它的父容器的onTouchEvent方法将会被调用，依此类推，如果所有的元素都不处理这个事件，那么这个事件将会最终传递给Activity处理(调用Activity的onTouchEvent方法)。\n","text":"只整理android面试中涉及到的知识点。不断补充中。。。 1.Android事件传递机制下面内容摘选自《Android开发艺术探索》 (1) 当一个点击事件发生之后，传递过程遵循如下顺序：Activity -&gt; Window -&gt; View。如果一个view的onTouchEvent方法返回false，那么它的父容器的onTouchEvent方法将会被调用，依此类推，如果所有的元素都不处理这个事件，那么这个事件将会最终传递给Activity处理(调用Activity的onTouchEvent方法)。 (2) 正常情况下，一个事件序列只能被一个view拦截并消耗，因为一旦某个元素拦截了某个事件，那么同一个事件序列内的所有事件都会直接交给它处理，并且该元素的onInterceptTouchEvent方法不会再被调用了。 (3) 某个view一旦开始处理事件，如果它不消耗ACTION_DOWN事件，那么同一事件序列的其他事件都不会再交给它来处理，并且事件将重新交给它的父容器去处理(调用父容器的onTouchEvent方法)；如果它消耗ACTION_DOWN事件，但是不消耗其他类型事件，那么这个点击事件会消失，父容器的onTouchEvent方法不会被调用，当前view依然可以收到后续的事件，但是这些事件最后都会传递给Activity处理。 (4) ViewGroup默认不拦截任何事件，因为它的onInterceptTouchEvent方法默认返回false。view没有onInterceptTouchEvent方法，一旦有点击事件传递给它，那么它的onTouchEvent方法就会被调用。 (5) View的onTouchEvent默认都会消耗事件(返回true)，除非它是不可点击的(clickable和longClickable都为false)。view的longClickable默认是false的，clickable则不一定，Button默认是true，而TextView默认是false。 (6) View的enable属性不影响onTouchEvent的默认返回值。哪怕一个view是disable状态，只要它的clickable或者longClickable有一个是true，那么它的onTouchEvent就会返回true。 (7) 事件传递过程总是先传递给父元素，然后再由父元素分发给子view，通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外，即当面对ACTION_DOWN事件时，ViewGroup总是会调用自己的onInterceptTouchEvent方法来询问自己是否要拦截事件。ViewGroup的dispatchTouchEvent方法中有一个标志位FLAG_DISALLOW_INTERCEPT，这个标志位就是通过子view调用requestDisallowInterceptTouchEvent方法来设置的，一旦设置为true，那么ViewGroup不会拦截该事件。 (8) 以上结论均可以在书中的源码解析部分得到解释。Window的实现类为PhoneWindow，获取Activity的contentView的方法 dispatchTouchEvent()返回true，后续事件（ACTION_MOVE、ACTION_UP）会再传递，如果返回false，dispatchTouchEvent()就接收不到ACTION_UP、ACTION_MOVE。 ((ViewGroup)getWindow().getDecorView().findViewById(android.R.id.content)).getChildAt(0); 2.OnTouchListener、onTouchEvent、OnClickListener优先级顺序如果给一个view设置了OnTouchListener，那么OnTouchListener中的onTouch方法会被回调。这时事件如何处理还要看onTouch的返回值，如果返回false，那么当前view的onTouchEvent方法会被调用；如果返回true，那么onTouchEvent方法将不会被调用。在onTouchEvent方法中，如果当前view设置了OnClickListener，那么它的onClick方法会被调用，所以OnClickListener的优先级最低。 自定义View事件拦截1.重写onInterceptTouchEvent()这种是常规写法@Overridepublic boolean onInterceptTouchEvent(MotionEvent ev) &#123; switch (ev.getAction()) &#123; case MotionEvent.ACTION_DOWN: // 为了子view能够响应事件，当前view ACTION_DOWN一般不拦截 break; // .. 满足条件拦截其他事件 &#125;&#125;// 配合 onTouchEvent@Overridepublic boolean onTouchEvent(MotionEvent e) &#123; case MotionEvent.ACTION_MOVE: // 当前view 拦截了ACTION_MOVE，并作出响应处理 break; return true;&#125; 2.重写dispatchTouchEvent这种写法相对少见@Overridepublic boolean dispatchTouchEvent(MotionEvent ev) &#123; // 在super之前处理某些事件，可以阻止事件传递到当前view的onTouchEvent if (statified) &#123; // 比如原有onTouchEvent逻辑复杂，又加了一个单独的view，可以优先让这个view触发事件 return true; &#125; return super.dispatchTouchEvent(ev);&#125; 3.AsyncTask的方法介绍 onPreExecute()这个方法会在后台任务开始执行之间调用，用于进行一些界面上的初始化操作，比如显示一个进度条对话框等。 doInBackground(Params…)这个方法中的所有代码都会在子线程中运行，我们应该在这里去处理所有的耗时任务。任务一旦完成就可以通过return语句来将任务的执行结果进行返回，如果AsyncTask的第三个泛型参数指定的是Void，就可以不返回任务执行结果。注意，在这个方法中是不可以进行UI操作的，如果需要更新UI元素，比如说反馈当前任务的执行进度，可以调用publishProgress(Progress…)方法来完成。 onProgressUpdate(Progress…)当在后台任务中调用了publishProgress(Progress…)方法后，这个方法就很快会被调用，方法中携带的参数就是在后台任务中传递过来的。在这个方法中可以对UI进行操作，利用参数中的数值就可以对界面元素进行相应的更新。 onPostExecute(Result)当后台任务执行完毕并通过return语句进行返回时，这个方法就很快会被调用。返回的数据会作为参数传递到此方法中，可以利用返回的数据来进行一些UI操作，比如说提醒任务执行的结果，以及关闭掉进度条对话框等。 4.项目中Handler怎么使用？5.项目中图片的适配问题怎么解决？ dpi每英寸点数，全称dots per inch。用来表示屏幕密度，即屏幕物理区域中的像素量。高密度屏幕比低密度屏幕在给定物理区域的像素要多。 dp即dip，全称device independent pixel。设备独立像素，是一种虚拟像素单位，用于以密度无关方式表示布局维度或位置，以确保在不同密度的屏幕上正常显示UI。在160dpi的设备上，1dp=1px。 density设备的逻辑密度，是dip的缩放因子。以160dpi的屏幕为基线，density=dpi/160。 getResources().getDisplayMetrics().density sp缩放独立像素，全称scale independent pixel。类似于dp，一般用于设置字体大小，可以根据用户设置的字体大小偏好来缩放。 总结一下图片查找过程：优先匹配最适合的图片→查找密度高的目录（升序）→查找密度低的目录（降序) 也可以使用.9图片 6.Android存储敏感信息的方式有？使用SharedPreferences, getSharedPreferences 指定为 MODE_PRIVATE运用SQLite数据库保存到 SDCard: FileOutputStream fos = this.openFileOutput(“oauth_1.out”,Context.MODE_WORLD_READABLE);Keystore 也可以保存密钥写入SO 文件结合 ContentProvider 来保存信息上传到服务器由服务器保存采用多进程，放在单独的进程中保存 7.自定义广播 继承自BroadcastReceiver 重写onReceive(Context,Intent)Intent.getAction 动态注册（Context.registerReceiver()），静态注册（使用IntentFilter指定action） 8.加分项 JNI开发 性能优化 优秀作品 9.Sqlite数据库更新并保留升级前的数据我们知道在SQLiteOpenHelper的构造方法: super(Context context, String name, SQLiteDatabase.CursorFactory factory, int version) 中最后一个参数表示数据库的版本号.当新的版本号大于当前的version时会调用方法: onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) 所以我们的重点是在该方法中实现SQLite数据库版本升级的管理 对于保留升级前的数据，有两种解决办法： SQLite提供了ALTER TABLE命令，允许用户重命名或添加新的字段到已有表中，但是不能从表中删除字段。并且只能在表的末尾添加字段，比如，为Subscription添加两个字段： ALTER TABLE Subscription ADD COLUMN Activation BLOB; ALTER TABLE Subscription ADD COLUMN Key BLOB; 注释：Sqlite支持BLOB(二进制大对象)数据类型 保留数据删除原表创建新表，具体思路是： 1：将表A重新命名：例如重新命名为：temp_A 2：创建新表A 3：将temp_A中的数据【也就是更新前的数据】插入到新表A 具体操作如下： //重命名原来的数据表public static final String TEMP_SQL_CREATE_TABLE_SUBSCRIBE = \"alter table \" + A + \" rename to temp_A\";//然后把备份表temp_A中的数据copy到新创建的数据库表A中，这个表A没发生结构上的变化public static final String INSERT_SUBSCRIBE = \"select 'insert into A (code,name,username,tablename) values (\"code\",\"name\",\"cnki\",\"tablename\")' as insertSQL from temp_A\";//删除备份表public static final String DELETE_TEMP_SUBSCRIBE = \"delete from temp_A \";public static final String DROP_TEMP_SUBSCRIBE = \"drop table if exists temp_A\";@Overridepublic void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) &#123; for (int j = oldVersion; j &lt;= newVersion; j++) &#123; switch (j) &#123; case 2: //创建临时表 db.execSQL(TEMP_SQL_CREATE_TABLE_SUBSCRIBE); //执行OnCreate方法，这个方法中放的是表的初始化操作工作，比如创建新表之类的 onCreate(db); //删除之前的表里面的默认数据 for (int i = 0; i &lt; arrWhereAct.length; i++) &#123; db.execSQL(DELETE_TEMP_SUBSCRIBE + arrWhereAct[i]); &#125; //将临时表中的数据放入表A Cursor cursor = db.rawQuery(INSERT_SUBSCRIBE, null); if (cursor.moveToFirst()) &#123; do &#123; db.execSQL(cursor.getString(cursor .getColumnIndex(\"insertSQL\"))); &#125; while (cursor.moveToNext()); &#125; cursor.close(); //将临时表删除掉 db.execSQL(DROP_TEMP_SUBSCRIBE); break; default: break; &#125; &#125;&#125; 注意，为什么要在方法里写for循环，主要是考虑到跨版本升级，比如有的用户一直不升级版本，数据库版本号一直是1，而客户端最新版本其实对应的数据库版本已经是4了，那么我中途可能对数据库做了很多修改，通过这个for循环，可以迭代升级，不会发生错误。 10.AIDL支持的数据类型其实AIDL这门语言非常的简单，基本上它的语法和 Java 是一样的，只是在一些细微处有些许差别——毕竟它只是被创造出来简化Android程序员工作的，太复杂不好——所以在这里我就着重的说一下它和 Java 不一样的地方。主要有下面这些点： 文件类型：用AIDL书写的文件的后缀是 .aidl，而不是 .java。 数据类型：AIDL默认支持一些数据类型，在使用这些数据类型的时候是不需要导包的，但是除了这些类型之外的数据类型，在使用之前必须导包，就算目标文件与当前正在编写的 .aidl 文件在同一个包下——在 Java 中，这种情况是不需要导包的。比如，现在我们编写了两个文件，一个叫做Book.java ，另一个叫做 BookManager.aidl，它们都在 com.lypeer.aidldemo 包下 ，现在我们需要在 .aidl 文件里使用 Book 对象，那么我们就必须在 .aidl 文件里面写上 import com.lypeer.aidldemo.Book; 哪怕 .java 文件和 .aidl 文件就在一个包下。 默认支持的数据类型包括： Java中的八种基本数据类型，包括 byte，short，int，long，float，double，boolean，char。 String 类型。 CharSequence类型。 List类型：List中的所有元素必须是AIDL支持的类型之一，或者是一个其他AIDL生成的接口，或者是定义的parcelable（下文关于这个会有详解）。List可以使用泛型。 Map类型：Map中的所有元素必须是AIDL支持的类型之一，或者是一个其他AIDL生成的接口，或者是定义的parcelable。Map是不支持泛型的。 定向tag：这是一个极易被忽略的点——这里的“被忽略”指的不是大家都不知道，而是很少人会正确的使用它。在我的理解里，定向tag是这样的：AIDL中的定向tag表示了在跨进程通信中数据的流向，其中in表示数据只能由客户端流向服务端，out表示数据只能由服务端流向客户端，而inout则表示数据可在服务端与客户端之间双向流通。其中，数据流向是针对在客户端中的那个传入方法的对象而言的。in为定向tag的话表现为服务端将会接收到一个那个对象的完整数据，但是客户端的那个对象不会因为服务端对传参的修改而发生变动；out的话表现为服务端将会接收到那个对象的的空对象，但是在服务端对接收到的空对象有任何修改之后客户端将会同步变动；inout为定向tag的情况下，服务端将会接收到客户端传来对象的完整信息，并且客户端将会同步服务端对该对象的任何变动。 另外，Java 中的基本类型和String，CharSequence的定向tag默认且只能是in。还有，请注意，请不要滥用定向tag，而是要根据需要选取合适的——要是不管三七二十一，全都一上来就用inout，等工程大了系统的开销就会大很多——因为排列整理参数的开销是很昂贵的。 两种AIDL文件：在我的理解里，所有的AIDL文件大致可以分为两类。一类是用来定义parcelable对象，以供其他AIDL文件使用AIDL中非默认支持的数据类型的。一类是用来定义方法接口，以供系统使用来完成跨进程通信的。可以看到，两类文件都是在“定义”些什么，而不涉及具体的实现，这就是为什么它叫做“Android接口定义语言”。注：所有的非默认支持数据类型必须通过第一类AIDL文件定义才能被使用。 下面是两个例子，对于常见的AIDL文件都有所涉及： // Book.aidl//第一类AIDL文件的例子//这个文件的作用是引入了一个序列化对象 Book 供其他的AIDL文件使用//注意：Book.aidl与Book.java的包名应当是一样的package com.lypeer.ipcclient;//注意parcelable是小写parcelable Book;// BookManager.aidl//第二类AIDL文件的例子package com.lypeer.ipcclient;//导入所需要使用的非默认支持数据类型的包import com.lypeer.ipcclient.Book;interface BookManager &#123; //所有的返回值前都不需要加任何东西，不管是什么数据类型 List&lt;Book&gt; getBooks(); Book getBook(); int getBookCount(); //传参时除了Java基本类型以及String，CharSequence之外的类型 //都需要在前面加上定向tag，具体加什么量需而定 void setBookPrice(in Book book , int price) void setBookName(in Book book , String name) void addBookIn(in Book book); void addBookOut(out Book book); void addBookInout(inout Book book);&#125; 11.Android布局的优化方案 层级观察器(Hierarchy Viewer)： 使用layoutopt工具输出 重用布局文件： 使用&lt; merge /&gt;标签减少布局的嵌套层次； 仅在需要时才加载布局，ViewStub 12.Android性能调优 UI卡顿 ANR异常 内存性能优化 Android API使用：StringBuffer/String、HashMap/ArrayMap/SparseArray 性能调优参考这篇博客Andoid应用开发性能优化完全分析 使用 DialogFragment 创建对话框使用DialogFragment至少需要实现onCreateView或者onCreateDIalog方法。onCreateView即使用定义的xml布局文件展示Dialog。onCreateDialog即利用AlertDialog或者Dialog创建出Dialog。 注：官方不推荐直接使用Dialog创建对话框。 没有布局的Fragment的作用没有布局文件Fragment实际上是为了保存，当Activity重启时，保存大量数据准备的 在运行时配置发生变化时，在Fragment中保存有状态的对象a) 继承Fragment，声明引用指向你的有状态的对象b) 当Fragment创建时调用setRetainInstance(boolean)c) 把Fragment实例添加到Activity中d) 当Activity重新启动后，使用FragmentManager对Fragment进行恢复 import android.app.Fragment;import android.os.Bundle;/** * 保存对象的Fragment * * @author zhy * */ public class OtherRetainedFragment extends Fragment &#123; // data object we want to retain // 保存一个异步的任务 private MyAsyncTask data; // this method is only called once for this fragment @Override public void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); // retain this fragment setRetainInstance(true); &#125; public void setData(MyAsyncTask data) &#123; this.data = data; &#125; public MyAsyncTask getData() &#123; return data; &#125;&#125; 具体参考：Android 屏幕旋转 处理 AsyncTask 和 ProgressDialog 的最佳方案 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/28/Android-interview-questions/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"},{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"}]},{"title":"Android 退出整个应用程序解决方案","slug":"quit-whole-application","date":"2016-09-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/09/22/quit-whole-application/","link":"","permalink":"http://agehua.github.io/2016/09/22/quit-whole-application/","excerpt":"关于这个功能，每个公司项目都有自己的解决方案\n搜索了一下，网上大概有以下几种方法解决这个问题：\n\n(1)System.exit(0);\n\n(2)Process.killProcess(Process.myPid());\n\n(3)ActivityManager activityManager = (ActivityManager) this.getSystemService(Context.ACTIVITY_SERVICE);\n  activityManager.restartPackage(“packagename”);\n\n\n但这些貌似不是万能的，有的说在2.2版本后就失效了，那我们怎么办呢？","text":"关于这个功能，每个公司项目都有自己的解决方案 搜索了一下，网上大概有以下几种方法解决这个问题： (1)System.exit(0); (2)Process.killProcess(Process.myPid()); (3)ActivityManager activityManager = (ActivityManager) this.getSystemService(Context.ACTIVITY_SERVICE); activityManager.restartPackage(“packagename”); 但这些貌似不是万能的，有的说在2.2版本后就失效了，那我们怎么办呢？ 1、通过广播在起初的一个项目里我用了一个比较笨的方法，我用一个类来专门管理所有的Activity。这个类里有一个List，每打开一个Activity我就把这个Activity放到这个List中，当退出时再将List中所有的Activity一个一个的关闭。 在后来的项目中发现了一个更好地方法，就是通过广播来完成退出功能，具体实现过程是这样的：在每个Activity创建时（onCreate时）给Activity注册一个广播接收器，当退出时发送该广播即可。大概的代码如下： @Overrideprotected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); IntentFilter filter = new IntentFilter(); filter.addAction(\"finish\"); registerReceiver(mFinishReceiver, filter); ……&#125;private BroadcastReceiver mFinishReceiver = new BroadcastReceiver() &#123; @Override public void onReceive(Context context, Intent intent) &#123; if(\"finish\".equals(intent.getAction())) &#123; Log.e(\"#########\", \"I am \" + getLocalClassName() + \",now finishing myself...\"); finish(); &#125; &#125;&#125;; 相信聪明的大家会把上面的代码写在一个基类里面，因为如果你的项目中Activity很多的话，写起来很麻烦，而且也不符合代码规范。 在退出时执行以下代码即可关闭所有界面完全退出程序： getApplicationContext().sendBroadcast(new Intent(“finish”)); 转载：http://www.cnblogs.com/wader2011/archive/2011/10/10/2205161.html 2、使用退出类public class CloseActivity&#123; private static LinkedList&lt;Activity&gt; acys = new LinkedList&lt;Activity&gt;(); public static Activity curActivity; public static void add(Activity acy) &#123; acys.add(acy); &#125; public static void remove(Activity acy) &#123; acys.remove(acy); &#125; public static void close() &#123; Activity acy; while (acys.size() != 0) &#123; acy = acys.poll(); if (!acy.isFinishing()) &#123; acy.finish(); &#125; &#125;// android.os.Process.killProcess(android.os.Process.myPid()); &#125;&#125; 3.利用activity stack的原理我们知道Android的窗口类提供了历史栈，我们可以通过stack的原理来巧妙的实现，这里我们在D窗口打开A窗口时在Intent中直接加入标志Intent.FLAG_ACTIVITY_CLEAR_TOP，再次开启A时将会清除该进程空间的所有Activity。 在D中使用下面的代码: Intent intent = new Intent();intent.setClass(D.this, A.class);intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP); //注意本行的FLAG设置startActivity(intent);finish(); 关掉自己，在A中加入代码： @Overrideprotected void onNewIntent(Intent intent) &#123; // TODO Auto-generated method stub super.onNewIntent(intent); //退出 if ((Intent.FLAG_ACTIVITY_CLEAR_TOP &amp; intent.getFlags()) != 0) &#123; finish(); &#125;&#125; A的Manifest.xml配置成android:launchMode=&quot;singleTop&quot; 原理总结： 一般A是程序的入口点，从D起一个A的activity，加入标识Intent.FLAG_ACTIVITY_CLEAR_TOP这个过程中会把栈中B，C，都清理掉。因为A是android:launchMode=”singleTop” 不会调用oncreate(),而是响应onNewIntent（）这时候判断Intent.FLAG_ACTIVITY_CLEAR_TOP，然后把A finish（）掉。 栈中A,B,C,D全部被清理。所以整个程序退出了。 4.JNI实现守护进程请看这篇博客Android 通过JNI实现守护进程 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/22/quit-whole-application/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"exitApplication","slug":"exitapplication","permalink":"http://agehua.github.io/tags/exitapplication/"}]},{"title":"使用JNI获取publickey实现","slug":"JNI-get-publickey","date":"2016-09-21T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/09/22/JNI-get-publickey/","link":"","permalink":"http://agehua.github.io/2016/09/22/JNI-get-publickey/","excerpt":"1.前言之前写过一篇文件是关于JNI学习和积累的文章。这篇文章主要讲在使用JNI取得Publickey过程中遇到的问题和一些总结。\n2.JNI获取Publickey实现在上篇文章中，最终采用的加密方法来自github项目。\n但该项目中在4.0.4版本的手机上，取得publickey遇到兼容性问题。","text":"1.前言之前写过一篇文件是关于JNI学习和积累的文章。这篇文章主要讲在使用JNI取得Publickey过程中遇到的问题和一些总结。 2.JNI获取Publickey实现在上篇文章中，最终采用的加密方法来自github项目。 但该项目中在4.0.4版本的手机上，取得publickey遇到兼容性问题。 正常的Publickey字段样式是这样的： OpenSSLRSAPublicKey&#123;modulus=a0d169cedabdaac3527c2099eeac4cbd74bb9b14c2571bcf6755f49e1d8c8439a37e009b0cb1b1ae9bf164dc976ddc4ee050621c746610d995185accbe8b3c09cc4f8c7afd990db47be814f7f45ec9c489be5b0933e89ff58070c29c98199331160bdb3a19e0687d36e850ee686c565737be4f61328264a58792e198d873b023ec11cb26a73305eea631ab18ec3ce746eb253e47c145503e933ee5da892326ecbb29b5a005aacef2d30d720611f7014aa3f2e40954b9e4deeaca1823dd2f7b2230670acabda70d2f14b1adc9480cf0a48d47866a1aa745ae97d0ab906cd76e5ab76916d03ef153b35edc2ae7284a613b3a3a312c73cf0b98e0ce9a8cf6a682fa,publicExponent=10001&#125; 但是某些低版本手机上（我遇到的是三星GT-S7568 Android版本4.0.4）的Publickey字段样式是： RSA Public Key modulus: a0d169cedabdaac3527c2099eeaca0d169cedabdaac3527c2099eeac4cbd74bb9b14c2571bcf6755f49e1d8c8439a37e009b0cb1b1ae9bf164dc976ddc4ee050621c746610d995185accbe8b3c09cc4f8c7afd990db47be814f7f45ec9c489be5b0933e89ff58070c29c98199331160bdb3a19e0687d36e850ee686c565737be4f61328264a58792e198d873b023ec11cb6a73305eea631ab18ec3ce746eb23e47c145503e933ee5da892326ecbb29b5a005aacef2d30d720611f7014aa3f2e40954b9e4deeaca1823dd2f7b2230670acabda70d2f14b1adc9410cf0a48d47866a1aa745ae97d0ab906cd76e5ab76916d03ef153b35edc2ae7284a613b3a3a313c73cf0b98e0ce9a8cf6a682aff0b98e0ce9a8cf6a682fa public exponent: 10001 第一个字段modulus是一致的，第二个字段一个是“publicExponent”，另一个是“public exponent”。 所以我在代码中的处理是这样的 jmethodID substring_mid = env-&gt;GetMethodID(string_cls,\"substring\", \"(II)Ljava/lang/String;\");jmethodID indexOf_mid = env-&gt;GetMethodID(string_cls,\"indexOf\", \"(Ljava/lang/String;)I\");jint bb = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param2);jstring publicKey2_str =NULL;if (bb ==-1)&#123; jstring param3 = env-&gt;NewStringUTF(\"public exponent\"); jint cc = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param3); __android_log_print(ANDROID_LOG_ERROR, TAG, \"CC value is %d\", cc); publicKey2_str= static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,cc-1));&#125;else &#123; publicKey2_str = static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,bb-1));&#125; 2.1 在JNI native代码中打印日志上面提供的JNI方法中涉及到了JNI日志打印（“__android_log_print”） __android_log_print(ANDROID_LOG_ERROR, TAG, \"PublicKey value is %s\", jstringTostring(env,publicKey2_str)); 该方法第一个参数以日志级别，有：ANDROID_LOG_INFO，ANDROID_LOG_DEBUG和ANDROID_LOG_ERROR 第二个参数设置过滤的标签，可以在LogCat视图中过滤。 后面参数是具体的日志内容 jstringTostring是将jstring转换成char*的方法： char* jstringTostring(JNIEnv* env, jstring jstr)&#123; char* rtn = NULL; jclass clsstring = env-&gt;FindClass(\"java/lang/String\"); jstring strencode = env-&gt;NewStringUTF(\"utf-8\"); jmethodID mid = env-&gt;GetMethodID(clsstring, \"getBytes\", \"(Ljava/lang/String;)[B\"); jbyteArray barr= (jbyteArray)env-&gt;CallObjectMethod(jstr, mid, strencode); jsize alen = env-&gt;GetArrayLength(barr); jbyte* ba = env-&gt;GetByteArrayElements(barr, JNI_FALSE); if (alen &gt; 0) &#123; rtn = (char*)malloc(alen + 1); memcpy(rtn, ba, alen); rtn[alen] = 0; &#125; env-&gt;ReleaseByteArrayElements(barr, ba, 0); return rtn;&#125; jstring是Java提供的一个本地类型（Native Type），对应Java语言中的string类型 想了解JNI其他数据类型的，请看这里JNI学习积累之二 —- 数据类型映射、域描述符说明 要使用JNI日志打印还需要： 1.导入.h文件及定义宏在输出日志的.c文件中加入: #include &lt;android/log.h&gt;#define LOG_TAG \"From JNI ===&gt;&gt;\" 2.在Android.mk中引用日志库加入下面这行代码: LOCAL_LDLIBS := -lm -llog -ljnigraphics 具体学习可以移步这两篇文章： JNI的native代码中打印日志到eclipse的logcat中 JNI中使用LOGCAT 进行Debug 2.2 完整代码下面是我修改后的完整代码 jstring getPublicKey(JNIEnv* env, jobject thiz,jobject context) &#123; jclass context_cls = env-&gt;GetObjectClass(context); jmethodID get_package_manager_mid = env-&gt;GetMethodID(context_cls, \"getPackageManager\", \"()Landroid/content/pm/PackageManager;\"); jmethodID get_package_name_mid = env-&gt;GetMethodID(context_cls, \"getPackageName\", \"()Ljava/lang/String;\"); env-&gt;DeleteLocalRef(context_cls); jobject pm_obj = env-&gt;CallObjectMethod(context, get_package_manager_mid); jclass pm_cls = env-&gt;FindClass(\"android/content/pm/PackageManager\"); jmethodID get_package_info_mid = env-&gt;GetMethodID(pm_cls, \"getPackageInfo\", \"(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;\"); jstring package_name = reinterpret_cast&lt;jstring&gt;(env-&gt;CallObjectMethod( context, get_package_name_mid)); jfieldID flag_fid = env-&gt;GetStaticFieldID(pm_cls, \"GET_SIGNATURES\", \"I\"); jint flag = env-&gt;GetStaticIntField(pm_cls, flag_fid); env-&gt;DeleteLocalRef(pm_cls); jobject pi_obj = env-&gt;CallObjectMethod(pm_obj, get_package_info_mid, package_name, flag); env-&gt;DeleteLocalRef(package_name); jclass pi_cls = env-&gt;FindClass(\"android/content/pm/PackageInfo\"); jfieldID signatures_fid = env-&gt;GetFieldID(pi_cls, \"signatures\", \"[Landroid/content/pm/Signature;\"); env-&gt;DeleteLocalRef(pi_cls); jobject sig_obj = env-&gt;GetObjectField(pi_obj, signatures_fid); env-&gt;DeleteLocalRef(pi_obj); jobjectArray sigs = reinterpret_cast&lt;jobjectArray&gt;(sig_obj); jclass signature_cls = env-&gt;FindClass(\"android/content/pm/Signature\"); jmethodID to_byte_array_mid = env-&gt;GetMethodID(signature_cls, \"toByteArray\", \"()[B\"); jbyteArray sig_bytes = reinterpret_cast&lt;jbyteArray&gt;(env-&gt;CallObjectMethod( env-&gt;GetObjectArrayElement(sigs, 0), to_byte_array_mid)); jclass certificate_factory_cls = env-&gt;FindClass( \"java/security/cert/CertificateFactory\"); jmethodID get_certificate_instance_mid = env-&gt;GetStaticMethodID( certificate_factory_cls, \"getInstance\", \"(Ljava/lang/String;)Ljava/security/cert/CertificateFactory;\"); jobject certificate_factory_obj = env-&gt;CallStaticObjectMethod( certificate_factory_cls, get_certificate_instance_mid, env-&gt;NewStringUTF(\"X509\")); jmethodID generate_certificate_mid = env-&gt;GetMethodID( certificate_factory_cls, \"generateCertificate\", \"(Ljava/io/InputStream;)Ljava/security/cert/Certificate;\"); env-&gt;DeleteLocalRef(certificate_factory_cls); jclass certificate_cls = env-&gt;FindClass(\"java/security/cert/Certificate\"); jclass byte_input_stream_cls = env-&gt;FindClass( \"java/io/ByteArrayInputStream\"); jmethodID new_sig_bytes_is_mid = env-&gt;GetMethodID(byte_input_stream_cls, \"&lt;init&gt;\", \"([B)V\"); jobject sig_bytes_is = env-&gt;NewObject(byte_input_stream_cls, new_sig_bytes_is_mid, sig_bytes); env-&gt;DeleteLocalRef(sig_bytes); env-&gt;DeleteLocalRef(byte_input_stream_cls); jobject cert = env-&gt;CallObjectMethod(certificate_factory_obj, generate_certificate_mid, sig_bytes_is); env-&gt;DeleteLocalRef(sig_bytes_is); env-&gt;DeleteLocalRef(certificate_factory_obj); jmethodID get_pubic_key_mid = env-&gt;GetMethodID(certificate_cls, \"getPublicKey\", \"()Ljava/security/PublicKey;\"); env-&gt;DeleteLocalRef(certificate_cls); jobject publicKey = env-&gt;CallObjectMethod(cert, get_pubic_key_mid); jclass publicKey_cls = env-&gt;GetObjectClass(publicKey); jmethodID toString_mid = env-&gt;GetMethodID(publicKey_cls,\"toString\", \"()Ljava/lang/String;\"); jstring publicKey_str = static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey,toString_mid)); env-&gt;DeleteLocalRef(cert); env-&gt;DeleteLocalRef(publicKey_cls); env-&gt;DeleteLocalRef(publicKey); jclass string_cls = env-&gt;GetObjectClass(publicKey_str); jmethodID indexOf_mid = env-&gt;GetMethodID(string_cls,\"indexOf\", \"(Ljava/lang/String;)I\"); jstring param = env-&gt;NewStringUTF(\"modulus\"); jint aa = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param); jstring param2 = env-&gt;NewStringUTF(\"publicExponent\"); jmethodID substring_mid = env-&gt;GetMethodID(string_cls,\"substring\", \"(II)Ljava/lang/String;\"); __android_log_print(ANDROID_LOG_ERROR, TAG, \"PublicKey String is %s\", jstringTostring(env,publicKey_str)); jint bb = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param2); jstring publicKey2_str =NULL; if (bb ==-1)&#123; jstring param3 = env-&gt;NewStringUTF(\"public exponent\"); jint cc = env-&gt;CallIntMethod(publicKey_str,indexOf_mid,param3); __android_log_print(ANDROID_LOG_ERROR, TAG, \"CC value is %d\", cc); publicKey2_str= static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,cc-1)); &#125;else &#123; publicKey2_str = static_cast&lt;jstring&gt;(env-&gt;CallObjectMethod(publicKey_str,substring_mid,aa+8,bb-1)); &#125; __android_log_print(ANDROID_LOG_ERROR, TAG, \"PublicKey value is %s\", jstringTostring(env,publicKey2_str)); return publicKey2_str;&#125; 3.附赠版本兼容的方法问题（随时更新）低于Jellybean版本报如下错误： 01-20 08:53:00.141: E/AndroidRuntime(24005): java.lang.NoSuchMethodError: android.view.ViewTreeObserver.removeOnGlobalLayoutListener 正确调用方式应该是： if (Build.VERSION.SDK_INT &lt; Build.VERSION_CODES.JELLY_BEAN) &#123; ViewTreeObserver.removeGlobalOnLayoutListener(this);&#125;else ViewTreeObserver.removeOnGlobalLayoutListener(this); 还有一个setBackground方法： if(Build.VERSION.SzDK_INT &gt;= Build.VERSION_CODES.JELLY_BEAN) &#123; View.setBackground(new ColorDrawable(Color.parseColor(\"#CCCCCC\")));&#125; else &#123; View.setBackgroundColor(Color.parseColor(\"#CCCCCC\"));&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/22/JNI-get-publickey/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"JNI","slug":"jni","permalink":"http://agehua.github.io/tags/jni/"},{"name":"publickey","slug":"publickey","permalink":"http://agehua.github.io/tags/publickey/"}]},{"title":"apk中含有admob广告插件","slug":"AVG-unwanted-software","date":"2016-09-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/09/20/AVG-unwanted-software/","link":"","permalink":"http://agehua.github.io/2016/09/20/AVG-unwanted-software/","excerpt":"问题出现使用这个杀毒软件antivirus-for-android，检测我们团队的apk后，AVG提示警告unwanted software。\n生成的报告说是：Beware of Adware! 1 Types of Adware DetectedLast reported adware activity:    Sep 16Days with adware in last 30:    1 days\n见下图：","text":"问题出现使用这个杀毒软件antivirus-for-android，检测我们团队的apk后，AVG提示警告unwanted software。 生成的报告说是：Beware of Adware! 1 Types of Adware DetectedLast reported adware activity: Sep 16Days with adware in last 30: 1 days 见下图： 排查使用这个广告插件检测工具全能工具箱，检测后，确实提示我们的apk含有广告“admob” 但是这个apk是我们团队自己开发的，有项目源码，AndroidManifest文件中没有网络上说的Google AdMob注册，更没有com.google.ads.AdView这个布局文件 代码中没有，可能在第三方库中？ 结果就是在排查第三方库的过程中，发现google service的jar包中有名字是ads的文件夹。如下图： 删除后上图中的两个ads文件夹，再打包apk后，用软件检测，果然没有admob插件了。哈哈，恼人的问题解决了。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/20/AVG-unwanted-software/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"remove admob","slug":"remove-admob","permalink":"http://agehua.github.io/tags/remove-admob/"}]},{"title":"ANDROID设计模式之单例模式","slug":"android-design-pattern-singleton","date":"2016-09-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/09/20/android-design-pattern-singleton/","link":"","permalink":"http://agehua.github.io/2016/09/20/android-design-pattern-singleton/","excerpt":"本文转载自stormzhang ANDROID设计模式之单例模式 ，内容稍有补充\n常用单例模式什么是设计模式？其实简单的理解就是前人留下来的一些经验总结而已，然后把这些经验起了个名字叫Design Pattern，翻译过来就是设计模式的意思，通过使用设计模式可以让我们的代码复用性更高，可维护性更高，让你的代码写的更优雅。设计模式理论上有23种，但是我只会针对Android平台上常用的一些设计模式做分享，今天就先来分享下最常用的单例模式。","text":"本文转载自stormzhang ANDROID设计模式之单例模式 ，内容稍有补充 常用单例模式什么是设计模式？其实简单的理解就是前人留下来的一些经验总结而已，然后把这些经验起了个名字叫Design Pattern，翻译过来就是设计模式的意思，通过使用设计模式可以让我们的代码复用性更高，可维护性更高，让你的代码写的更优雅。设计模式理论上有23种，但是我只会针对Android平台上常用的一些设计模式做分享，今天就先来分享下最常用的单例模式。 饿汉式public class Singleton&#123; private static Singleton instance = new Singleton(); private Singleton()&#123;&#125; public static Singleton newInstance()&#123; return instance; &#125;&#125; 饿汉式 是最简单的实现方式，这种实现方式适合那些在初始化时就要用到单例的情况，这种方式简单粗暴，如果单例对象初始化非常快，而且占用内存非常小的时候这种方式是比较合适的，可以直接在应用启动时加载并初始化。 但是，如果单例初始化的操作耗时比较长而应用对于启动速度又有要求，或者单例的占用内存比较大，再或者单例只是在某个特定场景的情况下才会被使用，而一般情况下是不会使用时，使用饿汉式的单例模式就是不合适的，这时候就需要用到懒汉式的方式去按需延迟加载单例。 懒汉式public class Singleton&#123; private static Singleton instance = null; private Singleton()&#123;&#125; public static Singleton newInstance()&#123; if(null == instance)&#123; instance = new Singleton(); &#125; return instance; &#125;&#125; 懒汉式与饿汉式的最大区别就是将单例的初始化操作，延迟到需要的时候才进行，这样做在某些场合中有很大用处。比如某个单例用的次数不是很多，但是这个单例提供的功能又非常复杂，而且加载和初始化要消耗大量的资源，这个时候使用懒汉式就是非常不错的选择。 多线程下的单例模式上面介绍了一些单例模式的基本应用方法，但是上面所说的那些使用方式都是有一个隐含的前提，那就是他们都是应用在单线程条件下，一旦换成了多线程就有出错的风险。 如果在多线程的情况下，饿汉式不会出现问题，因为JVM只会加载一次单例类，但是懒汉式可能就会出现重复创建单例对象的问题。为什么会有这样的问题呢？因为懒汉式在创建单例时是 线程不安全的，多个线程可能会并发调用他的newInstance方法导致多个线程可能会创建多份相同的单例出来。 那有没有办法，使懒汉式的单利模式也是线程安全的呢？答案肯定是有的，就是使用加同步锁的方式去实现。 懒汉式同步锁public class Singleton &#123; private static Singleton instance = null; private Singleton()&#123; &#125; public static Singleton getInstance() &#123; synchronized (Singleton.class) &#123; if (instance == null) &#123; instance = new Singleton(); &#125; &#125; return instance; &#125;&#125; 这种是最常见的解决同步问题的一种方式，使用同步锁synchronized (Singleton.class)防止多线程同时进入造成instance被多次实例化。举个在Android使用这种方式的例子： InputMethodManager示例public final class InputMethodManager &#123; //内部全局唯一实例 static InputMethodManager sInstance; //对外api public static InputMethodManager getInstance() &#123; synchronized (InputMethodManager.class) &#123; if (sInstance == null) &#123; IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE); IInputMethodManager service = IInputMethodManager.Stub.asInterface(b); sInstance = new InputMethodManager(service, Looper.getMainLooper()); &#125; return sInstance; &#125; &#125;&#125; 以上是Android源码中输入法类相关的单例使用方式。 加锁的懒汉模式看起来即解决了线程并发问题，又实现了延迟加载，然而它存在着性能问题，依然不够完美。 synchronized修饰的同步方法比一般方法要慢很多，如果多次调用getInstance()，累积的性能损耗就比较大了。 因此就有了双重校验锁，先看下它的实现代码。 双重校验锁public class Singleton &#123; private static volatile Singleton instance = null; private Singleton()&#123; &#125; public static Singleton getInstance() &#123; // if already inited, no need to get lock everytime if (instance == null) &#123; synchronized (Singleton.class) &#123; if (instance == null) &#123; instance = new Singleton(); &#125; &#125; &#125; return instance; &#125;&#125; 可以看到上面在synchronized (Singleton.class)外又添加了一层if，这是为了在instance已经实例化后下次进入不必执行synchronized (Singleton.class)获取对象锁，从而提高性能。 我们看到双重校验锁即实现了延迟加载，又解决了线程并发问题，同时还解决了执行效率问题，是否真的就万无一失了呢？ 这里要提到Java中的指令重排优化。所谓指令重排优化是指在不改变原语义的情况下，通过调整指令的执行顺序让程序运行的更快。 JVM中并没有规定编译器优化相关的内容，也就是说JVM可以自由的进行指令重排序的优化。 这个问题的关键就在于由于指令重排优化的存在，导致初始化Singleton和将对象地址赋给instance字段的顺序是不确定的。 在某个线程创建单例对象时，在构造方法被调用之前，就为该对象分配了内存空间并将对象的字段设置为默认值。 此时就可以将分配的内存地址赋值给instance字段了，然而该对象可能还没有初始化。若紧接着另外一个线程来调用getInstance，取到的就是状态不正确的对象，程序就会出错。 volatile关键字JDK5的修正：以上就是双重校验锁会失效的原因，不过还好在JDK1.5及之后版本增加了volatile关键字。 volatile的一个语义是禁止指令重排序优化，也就保证了instance变量被赋值的时候对象已经是初始化过的，从而避免了上面说到的问题。Java中的volatile 变量是什么？理解volatile关键字的作用的前提是要理解Java内存模型，volatile关键字的作用主要有两个： 多线程主要围绕可见性和原子性两个特性而展开，使用volatile关键字修饰的变量，保证了其在多线程之间的可见性，即每次读取到volatile变量，一定是最新的数据 代码底层执行不像我们看到的高级语言—-Java程序这么简单， 它的执行是Java代码–&gt;字节码–&gt;根据字节码执行对应的C/C++代码–&gt;C/C++代码被编译成汇编语言–&gt;和硬件电路交互， 现实中，为了获取更好的性能JVM可能会对指令进行重排序，多线程下可能会出现一些意想不到的问题。 使用volatile则会对禁止语义重排序，当然这也一定程度上降低了代码执行效率 从实践角度而言，volatile的一个重要作用就是和CAS结合，保证了原子性， 详细的可以参见java.util.concurrent.atomic包下的类，比如AtomicInteger。 CAS（Compare and swap）比较和替换是设计并发算法时用到的一种技术。 简单来说，比较和替换是使用一个期望值和一个变量的当前值进行比较，如果当前变量的值与我们期望的值相等，就使用一个新值替换当前变量的值。 volatile是一个特殊的修饰符，只有成员变量才能使用它。 在Java并发程序缺少同步类的情况下，多线程对成员变量的操作对其它线程是透明的。 volatile变量可以保证下一个读取操作会在前一个写操作之后发生。 来源： http://blog.csdn.net/fly910905/article/details/79283557 代码如下：public class Singleton &#123; private static volatile Singleton instance = null; private Singleton()&#123;&#125; public static Singleton getInstance() &#123; if (instance == null) &#123; // Single Checked synchronized (Singleton.class) &#123; if (instance == null) &#123; // Double checked instance = new Singleton(); &#125; &#125; &#125; return instance; &#125;&#125; 以上三种方式还是挺麻烦的，我们不禁要问，有没有更好的实现方式呢？答案是肯定的。 我们可以利用JVM的类加载机制去实现。在很多情况下JVM已经为我们提供了同步控制，比如： 在static{}区块中初始化的数据访问final字段时等等因为在JVM进行类加载的时候他会保证数据是同步的，我们可以这样实现： 采用内部类，在这个内部类里面去创建对象实例。这样的话，只要应用中不使用内部类 JVM 就不会去加载这个单例类，也就不会创建单例对象，从而实现懒汉式的延迟加载和线程安全。 实现代码如下： 静态内部类public class Singleton&#123; //内部类，在装载该内部类时才会去创建单利对象 private static class SingletonHolder&#123; public static Singleton instance = new Singleton(); &#125; private Singleton()&#123;&#125; public static Singleton newInstance()&#123; return SingletonHolder.instance; &#125; public void doSomething()&#123; //do something &#125;&#125; 这样实现出来的单例类就是线程安全的，而且使用起来很简洁，麻麻再也不用担心我的单例不是单例了。 然而这还不是最简单的方式，Effective Java中推荐了一种更简洁方便的使用方式，就是使用枚举。 枚举类型单例模式public enum Singleton&#123; //定义一个枚举的元素，它就是Singleton的一个实例 instance; public void doSomething()&#123; // do something ... &#125; &#125; 使用方法如下： public static void main(String[] args)&#123; Singleton singleton = Singleton.instance; singleton.doSomething();&#125; 默认枚举实例的创建是线程安全的(创建枚举类的单例在JVM层面也是能保证线程安全的), 所以不需要担心线程安全的问题，所以理论上枚举类来实现单例模式是最简单的方式。 总结一般单例模式包含了5种写法，分别是饿汉、懒汉、双重校验锁、静态内部类和枚举。相信看完之后你对单例模式有了充分的理解了，根据不同的场景选择最你最喜欢的一种单例模式吧！ 关于synchronized关键字，推荐学习这篇文章：Java基础笔记 – 线程同步问题 解决同步问题的方法 synchronized方法 同步代码块 使用synchronized关键字，该关键字修饰的方法叫做同步方法。 Java中每个对象都有一个锁或者称为监视器，当访问某个对象的synchronized方法时，表示将该对象上锁，而不仅仅是为该方法上锁。 这样如果一个对象的synchronized方法被某个线程执行时，其他线程无法访问该对象的任何synchronized方法（但是可以调用其他非synchronized的方法）。直至该synchronized方法执行完。 静态的synchronized方法调用情况：当调用一个对象的静态synchronized方法时，它锁定的并不是synchronized方法所在的对象，而是synchronized方法所在对象对应的Class对象。这样，其他线程就不能调用该类的其他静态synchronized方法了，但是可以调用非静态的synchronized方法。 结论：执行静态synchronized方法锁方法所在对象，执行非静态synchronized方法锁方法所在对象对应的Class对象。 使用synchronized创建同步代码块：通过使用synchronized同步代码块，锁定一个对象，该对象作为可执行的标志从而达到同步的效果。 synchronized方法和synchronized同步代码块的区别：synchronized同步代码块只是锁定了该代码块，代码块外面的代码还是可以被访问的。synchronized方法是粗粒度的并发控制，某一个时刻只能有一个线程执行该synchronized方法。synchronized同步代码块是细粒度的并发控制，只会将块中的代码同步，代码块之外的代码可以被其他线程同时访问。 参考： Java单例模式的不同写法（懒汉式、饿汉式、双检锁、静态内部类、枚举）关于设计模式，CSDN上也有一个总结: Android源码设计模式分析一期发布 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/20/android-design-pattern-singleton/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Singleton","slug":"singleton","permalink":"http://agehua.github.io/tags/singleton/"}]},{"title":"ThreadLocal、HandlerThread、Looper区别","slug":"ThreadLocal-HandlerThread-Looper","date":"2016-09-04T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/09/05/ThreadLocal-HandlerThread-Looper/","link":"","permalink":"http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/","excerpt":"1.前言Android中非UI线程（WorkThread）不能操作UI线程（MainThread）\nhandler 发送Message 给MessageQueue，Looper 来轮询消息，如果有Message，然后再发送给Handler，Handler 拿到消息就可以所在的线程执行了。\n2.ThreadLocalThread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals ，这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。","text":"1.前言Android中非UI线程（WorkThread）不能操作UI线程（MainThread） handler 发送Message 给MessageQueue，Looper 来轮询消息，如果有Message，然后再发送给Handler，Handler 拿到消息就可以所在的线程执行了。 2.ThreadLocalThread这个类有一个变量：ThreadLocal.ThreadLocalMap threadLocals ，这是一个map的数据结构，里面的元素的key就是ThreadLocal，value就是我们自定义的一些目标类。我们可以在自己的多线程类中定义好几个ThreadLocal，然后每一个ThreadLocal put一个特定的目标类，然后以后可以用ThreadLocal get到目标类（用自己作为Thread里map的key），因为每个Thread有自己独自的map，所以这样可以实现每个线程有自己的LocalThread，并且一个Thread里可以有多个LocalThread。 简单理解就是每个线程维护一个map，然后可以用一定的关键字取出这个map里的目标类（比如一个bean），这个“一定的关键字”说的就是这个ThreadLocal 。 ThreadLocal隔离了各个线程，让各线程之间没有什么共享的问题。 参考：Android 中 Handler，Looper，HandlerThread 的使用 3.LooperLooper是Android handler机制的重要组成部分，Looper这个名字起的很形象，翻译过来是：打环的人，就是维护一个循环的人。Looper里有一个静态变量：private static final ThreadLocal sThreadLocal = new ThreadLocal();这是典型的Android里用到ThreadLocal的一个情况，调用Looper.prepare的时候，唯一做的事情就是把sThreadLocal作为key，把一个new出来的looper对象作为value put到相应线程的map里。然后以后用到Looper.loop的时候，就从这个sThreadLocal里取出这个Looper，然后死循环（阻塞循环）MessageQueue，取出Message并执行message指向的Handler。 4.HandlerSDK中关于Handler的说明如下： A Handler allows you to sendand process Messageand Runnable objects associated with a thread’s MessageQueue.Each Handler instance is associated with a single thread and that thread’smessage queue. When you create a new Handler, it is bound to the thread /message queue of the thread that is creating it – from that point on, it willdeliver messages and runnables to that message queue and execute them as theycome out of the message queue. 4.1 Handler的作用 There are two main uses for aHandler: (1) to schedule messages and runnables to be executed as some point inthe future; and (2) to enqueue an action to be performed on a different thread than your own. 在线程中实例化Handler需要保证线程当中包含Looper(注意：UI-Thread默认包含Looper)。 4.2 不是所有的Handler都能更新UIHandler处理消息总是在创建Handler的线程里运行。而我们的消息处理中，不乏更新UI的操作，不正确的线程直接更新UI将引发异常。因此，需要时刻关心Handler在哪个线程里创建的。如何更新UI才能不出异常呢？SDK告诉我们，有以下4种方式可以从其它线程访问UI线程(也即线程间通信)： Activity.runOnUiThread(Runnable) View.post(Runnable) View.postDelayed(Runnable, long) 在UI线程中创建的Handler 几点小结 Handler的处理过程运行在创建Handler的线程里 一个Looper对应一个MessageQueue，一个线程对应一个Looper，一个Looper可以对应多个Handler 不确定当前线程时，更新UI时尽量调用View.post方法 handler应该由处理消息的线程创建。 handler与创建它的线程相关联，而且也只与创建它的线程相关联。handler运行在创建它的线程中，所以，如果在handler中进行耗时的操作，会阻塞创建它的线程。 Android的线程分为有消息循环的线程和没有消息循环的线程，有消息循环的线程一般都会有一个Looper。主线程（UI线程）就是一个消息循环的线程。 Looper.myLooper(); //获得当前的LooperLooper.getMainLooper() //获得UI线程的Looper Handle的初始化函数（构造函数），如果没有参数，那么他就默认使用的是当前的Looper，如果有Looper参数，就是用对应的线程的Looper。 如果一个线程中调用Looper.prepare()，那么系统就会自动的为该线程建立一个消息队列，然后调用Looper.loop();之后就进入了消息循环，这个之后就可以发消息、取消息、和处理消息。 5.消息的发送与处理我们简单地看一下消息的循环过程： 5.1 消息的生成Message msg =mHandler.obtainMessage();msg.what = what;msg.sendToTarget(); 5.2 消息的发送MessageQueue queue= mQueue; if (queue != null)&#123; msg.target =this; sent =queue.enqueueMessage(msg, uptimeMillis);&#125; 在Handler.java的sendMessageAtTime(Messagemsg, long uptimeMillis)方法中，我们看到，它找到它所引用的MessageQueue，然后将Message的target设定成自己（目的是为了在处理消息环节，Message能找到正确的Handler），再将这个Message纳入到消息队列中。 5.3 消息的抽取Looper me =myLooper();MessageQueue queue= me.mQueue;while (true) &#123; Message msg =queue.next(); // might block if (msg !=null) &#123; if(msg.target == null) &#123; // Notarget is a magic identifier for the quit message. return; &#125; msg.target.dispatchMessage(msg); msg.recycle(); &#125;&#125; 在Looper.java的loop()函数里，我们看到，这里有一个死循环，不断地从MessageQueue中获取下一个（next方法）Message，然后通过Message中携带的target信息，交由正确的Handler处理（dispatchMessage方法）。 5.4 消息的处理if (msg.callback!= null) &#123; handleCallback(msg);&#125; else &#123; if (mCallback!= null) &#123; if(mCallback.handleMessage(msg)) &#123; return; &#125; &#125; handleMessage(msg);&#125; 在Handler.java的dispatchMessage(Messagemsg)方法里，其中的一个分支就是调用handleMessage方法来处理这条Message，而这也正是我们在职责处描述使用Handler时需要实现handleMessage(Messagemsg)的原因。至于dispatchMessage方法中的另外一个分支，我将会在后面的内容中说明。至此，我们看到，一个Message经由Handler的发送，MessageQueue的入队，Looper的抽取，又再一次地回到Handler的怀抱。而绕的这一圈，也正好帮助我们将同步操作变成了异步操作。 参考上面的消息的发送与处理，这里再解释一下View.post(Runnable)方法。 在post(Runnableaction)方法里，View获得当前线程（即UI线程）的Handler，然后将action对象post到Handler里。 在Handler里，它将传递过来的action对象包装成一个Message（Message的callback为action），然后将其投入UI线程的消息循环中。 在 Handler再次处理该Message时，有一条分支就是为它所设，直接调用mCallback.handleMessage的方法，返回到runnable的run方法。 而此时，已经路由到UI线程里，因此，我们可以毫无顾虑的来更新UI。 5.HandlerThreadHandlerThread就是在普通的Thread基础上加上了Looper的支持，让用户不必自己去创建Looper了，同时方便了Handler的使用。 创建HandlerThread时需要把它启动了，即调用start()方法。然后创建Handler时将HandlerThread中的looper对象传入。 HandlerThread thread = new HandlerThread(\"MyHandlerThread\");thread.start();mHandler = new Handler(thread.getLooper());mHandler.post(new Runnable()&#123;...&#125;); 那么这个Handler对象就是与HandlerThread这个线程绑定了（这时就不再是与UI线程绑定了，这样在Handler中处理耗时操作将不会阻塞UI）。 如果想让HandlerThread退出，则需要调用handlerThread.quit()。 具体可以看下面代码： public class HandlerThreadActivity extends Activity &#123; private static final String TAG = \"HandlerThreadActivity\"; private HandlerThreadmHandlerThread; private MyHandler mMyHandler; @Override protected void onCreate(Bundle savedInstanceState) &#123; // TODO Auto-generatedmethod stub super.onCreate(savedInstanceState); TextView text = new TextView(this); text.setText(\"HandlerThreadActivity\"); setContentView(text); Log.d(TAG, \"The mainthread id = \" + Thread.currentThread().getId()); //生成一个HandlerThread对象，实现了使用Looper来处理消息队列的功能， //这个类由Android应用程序框架提供 mHandlerThread = new HandlerThread(\"handler_thread\"); //在使用HandlerThread的getLooper()方法之前，必须先调用该类的start(); mHandlerThread.start(); //即这个Handler是运行在mHandlerThread这个线程中 mMyHandler = new MyHandler(mHandlerThread.getLooper()); mMyHandler.sendEmptyMessage(1); &#125; private class MyHandler extends Handler &#123; public MyHandler(Looper looper) &#123; super(looper); &#125; @Override public void handleMessage(Message msg) &#123; Log.d(TAG, \"MyHandler--&gt;handleMessage--&gt;threadid = \" + Thread.currentThread().getId()); super.handleMessage(msg); &#125; &#125;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ThreadLocal","slug":"threadlocal","permalink":"http://agehua.github.io/tags/threadlocal/"},{"name":"HandlerThread","slug":"handlerthread","permalink":"http://agehua.github.io/tags/handlerthread/"},{"name":"Looper","slug":"looper","permalink":"http://agehua.github.io/tags/looper/"}]},{"title":"RxJava 学习","slug":"RxAndroid-Learning","date":"2016-08-15T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/08/16/RxAndroid-Learning/","link":"","permalink":"http://agehua.github.io/2016/08/16/RxAndroid-Learning/","excerpt":"1.向前辈致敬给Android开发者的RxJava详解，这篇文章讲解详细，如果耐心看完，相信肯定收获不小\n本篇博文用作学习RxJava过程中，记录知识和心得，如有冒犯还请见谅！\n2.简单介绍RxJava是通过一种扩展的观察者模式来实现的。RxJava有四个基本概念：Observable(可观察者，即被观察者)、 Observer (观察者)、 subscribe (订阅)、事件。Observable和Observer通过subscribe()方法实现订阅关系，从而Observable可以在需要的时候发出事件来通知Observer。","text":"1.向前辈致敬给Android开发者的RxJava详解，这篇文章讲解详细，如果耐心看完，相信肯定收获不小 本篇博文用作学习RxJava过程中，记录知识和心得，如有冒犯还请见谅！ 2.简单介绍RxJava是通过一种扩展的观察者模式来实现的。RxJava有四个基本概念：Observable(可观察者，即被观察者)、 Observer (观察者)、 subscribe (订阅)、事件。Observable和Observer通过subscribe()方法实现订阅关系，从而Observable可以在需要的时候发出事件来通知Observer。 与传统观察者模式不同， RxJava 的事件回调方法除了普通事件onNext()（相当于onClick()/onEvent()）之外，还定义了两个特殊的事件：onCompleted()和onError()。 RxJava的基本实现主要有三点：Observer的创建、Observable的创建、Scheduler线程控制 3.Observer的创建方法Observer 即观察者，它决定事件触发的时候将有怎样的行为。 RxJava 中的 Observer 接口的实现方式： Observer&lt;String&gt; observer = new Observer&lt;String&gt;() &#123; @Override public void onNext(String s) &#123; Log.d(tag, \"Item: \" + s); &#125; @Override public void onCompleted() &#123; Log.d(tag, \"Completed!\"); &#125; @Override public void onError(Throwable e) &#123; Log.d(tag, \"Error!\"); &#125;&#125;; 除了 Observer 接口之外，RxJava还内置了一个实现了Observer的抽象类：Subscriber。 Subscriber对Observer接口进行了一些扩展，但他们的基本使用方式是完全一样的： Subscriber&lt;String&gt; subscriber = new Subscriber&lt;String&gt;() &#123; @Override public void onNext(String s) &#123; Log.d(tag, \"Item: \" + s); &#125; @Override public void onCompleted() &#123; Log.d(tag, \"Completed!\"); &#125; @Override public void onError(Throwable e) &#123; Log.d(tag, \"Error!\"); &#125;&#125;; Observer和Subscriber区别对于使用者来说主要有两点： onStart(): 这是Subscriber增加的方法。 它会在subscribe刚开始，而事件还未发送之前被调用，可以用于做一些准备工作，例如数据的清零或重置。这是一个可选方法，默认情况下它的实现为空。 需要注意的是，如果对准备工作的线程有要求（例如弹出一个显示进度的对话框，这必须在主线程执行）， onStart()就不适用了，因为它总是在subscribe 所发生的线程被调用，而不能指定线程。要在指定的线程来做准备工作，可以使用 doOnSubscribe() 方法。 unsubscribe(): 这是Subscriber所实现的另一个接口Subscription的方法，用于取消订阅。 在这个方法被调用后，Subscriber将不再接收事件。一般在这个方法调用前，可以使用isUnsubscribed()先判断一下状态。 unsubscribe()这个方法很重要，因为在subscribe()之后，Observable会持有 Subscriber 的引用，这个引用如果不能及时被释放，将有内存泄露的风险。所以最好保持一个原则：要在不再使用的时候尽快在合适的地方（例如 onPause() onStop() 等方法中）调用 unsubscribe() 来解除引用关系，以避免内存泄露的发生。 4.Observable的几种创建方法：1.Observable.just(T…)和from(T[])/from(Iterable&lt;? extends T&gt;) 1). just(T…): 将传入的参数依次发送出来 2). from(T[])/from(Iterable&lt;? extends T&gt;): 将传入的数组或 Iterable 拆分成具体对象后，依次发送出来。 3). 由这两个方法创建的Observable对象的特点是：所有Observer一旦订阅这个Observable就会立即调用onNext()方法并传入Observable.just()/from()的参数，而后因为Observable没有数据可以发送了，onComplete()方法会被调用。 Observable&lt;List&lt;String&gt;&gt; listObservable = Observable.just(getColorList()); 注意，如果just()中传入的是耗时方法，该方法会被立即执行并阻塞UI线程。这里的getColorList()是一个不耗时的方法. 下一步，我们写一个Observer来观察Observable。 listObservable.subscribe(new Observer&lt;List&lt;String&gt;&gt;() &#123; @Override public void onCompleted() &#123; &#125; @Override public void onError(Throwable e) &#123; &#125; @Override public void onNext(List&lt;String&gt; colors) &#123; mSimpleStringAdapter.setStrings(colors); &#125;&#125;); 在这个例子中我们不关心Observable何时完成数据的传输，所以我们不用在onComplete()方法里写代码。而且在这里不会有异常抛出，所以我们也不用管onError()方法 2.Observable.fromCallable() 先看代码： Observable&lt;List&lt;String&gt;&gt; tvShowObservable = Observable.fromCallable(new Callable&lt;List&lt;String&gt;&gt;() &#123; @Override public List&lt;String&gt; call() &#123; return mRestClient.getFavoriteTvShows(); &#125;&#125;); 使用Observable.fromCallable()方法有两点好处： 1).获取要发送的数据的代码只会在有Observer订阅之后执行。 2).获取数据的代码（指的是call()方法）可以在子线程中执行。对比just()中传入的方法只能运行在主线程。 这两点好处有时可能非常重要。 现在让我们订阅这个Observable。 mTvShowSubscription = tvShowObservable .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new Observer&lt;List&lt;String&gt;&gt;() &#123; @Override public void onCompleted() &#123; &#125; @Override public void onError(Throwable e) &#123; &#125; @Override public void onNext(List&lt;String&gt; tvShows)&#123; displayTvShows(tvShows); &#125;&#125;); 上面代码逐一介绍： 1).subscribeOn() 指定事件发生的线程 在默认情况下Observable的所有代码，都会在执行subscribe()方法的线程中运行。而通过subscribeOn()方法，这些代码可以在其他线程中执行。在上面的例子中，我们让代码在”IO Scheduler”中执行（Schedulers.io()）。现在我们可以只把Scheduler当做一个可以工作的子线程。 2).observeOn() 会指定onNext()方法发生的线程 通过在observeOn()方法中指定另一个Scheduler来完成onNext()的内容，在这里也就是AndroidSchedules.mainThread()所返回的Scheduler(UI线程的Scheduler)。 3).subscribe() Callable只会在有在Observable调用subscribe()后执行。 Observable.subscribe(Subscriber) 的内部实现是这样的（仅核心代码）： // 注意：这不是 subscribe() 的源码，而是将源码中与性能、兼容性、扩展性有关的代码剔除后的核心代码。// 如果需要看源码，可以去 RxJava 的 GitHub 仓库下载。public Subscription subscribe(Subscriber subscriber) &#123; subscriber.onStart(); onSubscribe.call(subscriber); return subscriber;&#125; 可以看到，subscriber()做了3件事： ①.调用Subscriber.onStart()。这个方法在前面已经介绍过，是一个可选的准备方法。 ②.调用Observable中的OnSubscribe.call(Subscriber)。在这里，事件发送的逻辑开始运行。从这也可以看出，在RxJava中， Observable并不是在创建的时候就立即开始发送事件，而是在它被订阅的时候，即当 subscribe()方法执行的时候。 ③.将传入的Subscriber作为Subscription返回。这是为了方便unsubscribe(). 4).mTvShowSubscription 每当Observer订阅Observable时就会生成一个Subscription对象。一个Subscription代表了一个Observer与Observable之间的连接。有时我们需要操作这个连接，这里拿在Activity的onDestroy()方法中的代码举个例子： if (mTvShowSubscription != null &amp;&amp; !mTvShowSubscription.isUnsubscribed()) &#123; mTvShowSubscription.unsubscribe(); //取消订阅&#125; unsubscribe()方法告诉Observable它所发送的数据不再被Observer所接收。在调用unsubscribe()方法后，我们创建的Observer就不再会收到数据了，以免Observable异步加载数据时发生意外。 3.使用SingleSingle是Observable的精简版，一种特殊的只发射单个值的Observable，几乎和Observable一模一样，但其回调方法不是onComplete()/onNext()/onError()，而是onSuccess()/onError()。 我们现在把刚才写过的Observable用Single重写一遍。首先我们要创建一个Single: Single&lt;List&lt;String&gt;&gt; tvShowSingle = Single.fromCallable(new Callable&lt;List&lt;String&gt;&gt;() &#123; @Override public List&lt;String&gt; call() throws Exception &#123; mRestClient.getFavoriteTvShows(); &#125;&#125;); 然后订阅一下 mTvShowSubscription = tvShowSingle .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new SingleSubscriber&lt;List&lt;String&gt;&gt;() &#123; @Override public void onSuccess(List&lt;String&gt; tvShows) &#123; displayTvShows(tvShows); &#125; @Override public void onError(Throwable error) &#123; displayErrorMessage(); &#125;&#125;); 但这次我们不再使用Observer，而是使用一个叫SingleSubscriber的类。这个类和Observer非常像，只不过它只有上述两个方法：onSuccess()和onError()。SingleSubscriber之于Single就如Observer之于Observable。 订阅一个Single的同时也会自动创建一个Subscription对象。这里的Subscription和上面的例子没有区别，一定要在onDestroy()中解除订阅。 5.线程控制——Scheduler RxJava已经内置了几个 Scheduler ，它们已经适合大多数的使用场景： 1.Schedulers.immediate(): 直接在当前线程运行，相当于不指定线程。这是默认的 Scheduler。 2.Schedulers.newThread(): 总是启用新线程，并在新线程执行操作。 3.Schedulers.io(): I/O 操作（读写文件、读写数据库、网络信息交互等）所使用的 Scheduler。行为模式和 newThread() 差不多，区别在于 io() 的内部实现是是用一个无数量上限的线程池，可以重用空闲的线程，因此多数情况下 io() 比 newThread() 更有效率。不要把计算工作放在 io() 中，可以避免创建不必要的线程。 4.Schedulers.computation(): 计算所使用的 Scheduler。这个计算指的是 CPU 密集型计算，即不会被 I/O 等操作限制性能的操作，例如图形的计算。这个 Scheduler 使用的固定的线程池，大小为 CPU 核数。不要把 I/O 操作放在 computation() 中，否则 I/O 操作的等待时间会浪费 CPU。 5.另外， Android 还有一个专用的 AndroidSchedulers.mainThread()，它指定的操作将在 Android 主线程运行。 6.特殊的情况1.Subject Observable和Observer的复合体，也是二者的桥梁 Subjects = Observable + Observer，Subject继承自Observable实现了Observer Rxjava提供的四种Subject: ①PublishSubject ： subject的基础子类。 ②BehaviorSubject : 会首先向它的订阅者发送截止订阅前最新的一个数据，然后正常发送订阅后的数据流。 ③ReplaySubject ： 会缓存它所订阅的所有数据，向所有订阅它的观察者重发。 ④AsyncSubject ： 只会发布最后一个数据给已经订阅的每一个观察者。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/08/16/RxAndroid-Learning/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"RxJava","slug":"rxjava","permalink":"http://agehua.github.io/tags/rxjava/"},{"name":"RxAndroid","slug":"rxandroid","permalink":"http://agehua.github.io/tags/rxandroid/"}]},{"title":"Android手机定位服务","slug":"android-LocationListener","date":"2016-08-02T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/08/03/android-LocationListener/","link":"","permalink":"http://agehua.github.io/2016/08/03/android-LocationListener/","excerpt":"1.LocationListener使用优先使用网络定位服务，当GPS服务不可用则跳转到手机位置服务设置页面","text":"1.LocationListener使用优先使用网络定位服务，当GPS服务不可用则跳转到手机位置服务设置页面 代码收集： /** * 使用手机定位服务 */private void startLocationService()&#123; locationListener = new LocationListener() &#123; @Override public void onStatusChanged(String provider, int status, Bundle extras) &#123; &#125; @Override public void onProviderEnabled(String provider) &#123; // 当GPS LocationProvider可用时，更新位置 location = locManager.getLastKnownLocation(provider); &#125; @Override public void onProviderDisabled(String provider) &#123; isLocatedSuccess = false; if (provider.equals(\"network\")) &#123; locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 3 * 1000, 8,locationListener); &#125;else if(provider.equals(\"gps\"))&#123;//GPS服务不可用，跳到位置服务设置页面 startActivity(new Intent(android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS)); &#125;else &#123; updateToNewLocation(null); &#125; &#125; @Override public void onLocationChanged(Location location) &#123; // 当定位信息发生改变时，更新位置 isLocatedSuccess = true; updateToNewLocation(location); locManager.removeUpdates(this); &#125; &#125;; if (locManager.getProvider(LocationManager.NETWORK_PROVIDER) != null) locManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 3 * 1000, 8,locationListener); else if (locManager.getProvider(LocationManager.GPS_PROVIDER) != null) locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 3 * 1000, 8,locationListener); else Toast.makeText(mActivity(), \"获取手机位置信息错误\", Toast.LENGTH_SHORT).show();&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/08/03/android-LocationListener/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"LocationListener","slug":"locationlistener","permalink":"http://agehua.github.io/tags/locationlistener/"}]},{"title":"Android Webview总结，不断更新中 :(","slug":"android-webview-summary","date":"2016-07-24T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/07/25/android-webview-summary/","link":"","permalink":"http://agehua.github.io/2016/07/25/android-webview-summary/","excerpt":"1.Android Webview的坑\n1.webview再次加载页面空白\n\n1.可以关闭掉硬件加速\n\n2.不关闭硬件加速的情况下：在关闭Acivity之前手动调用下面方法，\n\n","text":"1.Android Webview的坑 1.webview再次加载页面空白 1.可以关闭掉硬件加速 2.不关闭硬件加速的情况下：在关闭Acivity之前手动调用下面方法， public void goFinish()&#123; isLoadWithError =false; if (null!=jsCallBack) mWebView.removeJavascriptInterface(\"XXX\"); mWebView.setFocusable(true); mWebView.removeAllViews(); try &#123; mWebView.clearHistory(); //webview没有历史记录，这里会抛出异常 &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; mWebView.destroy(); try &#123; //mWebView为WebView所在类的全局变量名，不可以混淆 Field fieldWebView = this.getClass().getDeclaredField(\"mWebView\"); fieldWebView.setAccessible(true); WebView webView = (WebView) fieldWebView.get(this); webView.removeAllViews(); webView.destroy(); &#125;catch (NoSuchFieldException e) &#123; e.printStackTrace(); &#125;catch (IllegalArgumentException e) &#123; e.printStackTrace(); &#125;catch (IllegalAccessException e) &#123; e.printStackTrace(); &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; this.finish(); &#125; 注意：因为用到了反射去清理webview，所以混淆时，这个方法所在的类不能混淆 2.部分手机h5 game屏幕闪烁 在小米的某些手机上，会出现这种情况。抱歉，还没有好的解决办法。谁有好的解决办法可以邮件告知，多谢 :) 3.android Webview替代品Crosswalk Crosswalk解决4,2以下的手机浏览器的兼容性问题。对html5的支持更好 Crosswalk官网 但Crosswalk也有缺点，将Crosswalk嵌入App中，会使APK增加大约20M。具体可以看这个知乎提问 4.腾讯浏览服务 官网地址 2.WebView防止远程代码攻击 1.使用Android4.2以上的系统，通过在Java的远程方法上面声明一个@JavascriptInterface，可以预防改安全漏洞 2.低于Android4.2的系统，如果系统自己添加了一个叫searchBoxJavaBridge_的Js接口，则需要把这个接口删除 详情参见这篇文章：Android WebView的Js对象注入漏洞解决方案 这里贴一个自己整理的webview类：BaseWebView 3.Android中WebView的JavaScript代码和本地代码交互的三种方式来自姜维的博客:Android中WebView的JavaScript代码和本地代码交互的三种方式 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/07/25/android-webview-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"webview","slug":"webview","permalink":"http://agehua.github.io/tags/webview/"}]},{"title":"Gson解析使用总结","slug":"gson-summary","date":"2016-06-07T16:00:00.000Z","updated":"2024-12-05T09:41:56.282Z","comments":true,"path":"2016/06/08/gson-summary/","link":"","permalink":"http://agehua.github.io/2016/06/08/gson-summary/","excerpt":"1.Gson解析总结，就两种情况Gson 是Google提供的用来在Java对象和JSON数据之间进行映射的Java类库。可以将一个JSON字符串转成一个Java对象，或者将Java对象转成一个JSON字符串。使用Gson来解析时，总结一下，就两句话：\n\n1.遇到“{”字符，表示单个对象，直接用XXXBean.class类去映射\n2.遇到“[”字符，表示对象数组，要用XXXBean[].class或list去映射\n","text":"1.Gson解析总结，就两种情况Gson 是Google提供的用来在Java对象和JSON数据之间进行映射的Java类库。可以将一个JSON字符串转成一个Java对象，或者将Java对象转成一个JSON字符串。使用Gson来解析时，总结一下，就两句话： 1.遇到“{”字符，表示单个对象，直接用XXXBean.class类去映射 2.遇到“[”字符，表示对象数组，要用XXXBean[].class或list去映射 2.第一种情况，举例 json字符串是： &#123; \"items\": [ &#123; \"key\": \"H60-L12__1464938219953__346589_483\", \"hash\": \"Fip_In4BhB5syoZ28W3l_eb6rBDU\", \"fsize\": 348120, \"mimeType\": \"image/jpeg\", \"putTime\": 14649382507765902 &#125;, &#123; \"key\": \"H60-L12__1465352164202__397253_2946\", \"hash\": \"Fs-UwiosdckN9kVY01GrOYC-b7a9\", \"fsize\": 938413, \"mimeType\": \"image/jpeg\", \"putTime\": 14653521712332144 &#125;, &#123; \"key\": \"H60-L12__1465352548728__322577_4114\", \"hash\": \"Frga_QiMJVb9caiuwMlJABCsu1rc\", \"fsize\": 506921, \"mimeType\": \"image/jpeg\", \"putTime\": 14653525989907168 &#125; ]&#125; 分析 最开始是一个“{”字符，所以需要用gson.fromJson(jsonstring, XXXBean.class)来解析。同时，XXXBean中只有一个字段items。items里面是一个“[”字符，表示items里面是数组，可以用list去映射。 解析时， 最后对应的Gson对象就是： public class XXXBean &#123; public List&lt;XXXItem&gt; items; public List&lt;XXXItem&gt; getItems() &#123; return items; &#125; public void setItems(List&lt;XXXItem&gt; items) &#123; this.items = items; &#125; public static class XXXItem &#123; private String key; private String hash; private String fsize; private String mimeType; private String putTime; ... &#125;&#125;Gson gson = new Gson();List&lt;XXXBean.XXXItem&gt; list = gson.fromJson(jsonstring,XXXBean.class).getItems(); 3.第二种情况，举例json字符串以“[”开头。 例如，json==[{“id”:1,”name”:”李坤”,”birthDay”:”Jun 22, 2012 8:28:52 AM”},{“id”:2,”name”:”曹贵生”,”birthDay”:”Jun 22, 2012 8:28:52 AM”},{“id”:3,”name”:”柳波”,”birthDay”:”Jun 22, 2012 8:28:52 AM”}] 解析时，需要使用list来接收。 List&lt;Student&gt; retList = gson.fromJson(jsonstring2, new TypeToken&lt;List&lt;Student&gt;&gt;()&#123;&#125;.getType()); 也可以这样 Student[] students= gson.fromJson(jsonstring2,new Student[].class); 对应list为什么要使用TypeToken？ TypeToken是Gson提供的，来实现对泛型的支持 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/06/08/gson-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"gson","slug":"gson","permalink":"http://agehua.github.io/tags/gson/"}]},{"title":"七牛android使用总结","slug":"qiniu-android-summary","date":"2016-05-27T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/05/28/qiniu-android-summary/","link":"","permalink":"http://agehua.github.io/2016/05/28/qiniu-android-summary/","excerpt":"1.在android上实现对七牛空间操作  在android上实现对七牛空间的各种操作，包括list，delete，upload，download。支持私有空间\n  注意：官方不建议开发者把AccessKey和SecretKey放在前端的java文件里，最好还是有一台应用服务器\n  如果只是想尝试一下，好吧:)  代码中都有说明，直接上代码","text":"1.在android上实现对七牛空间操作 在android上实现对七牛空间的各种操作，包括list，delete，upload，download。支持私有空间 注意：官方不建议开发者把AccessKey和SecretKey放在前端的java文件里，最好还是有一台应用服务器 如果只是想尝试一下，好吧:) 代码中都有说明，直接上代码 2.代码一共有三个类： 工具类： package com.qiniu.ui.utils;import android.graphics.Bitmap;import android.graphics.Bitmap.CompressFormat;import android.os.Environment;import android.util.Log;import com.loopj.android.http.AsyncHttpClient;import com.loopj.android.http.AsyncHttpResponseHandler;import com.loopj.android.http.RequestParams;import com.qiniu.android.storage.UpProgressHandler;import com.qiniu.android.storage.UploadManager;import com.qiniu.android.storage.UploadOptions;import com.qiniu.android.utils.UrlSafeBase64;import com.qiniu.api.auth.AuthException;import com.qiniu.api.auth.digest.Mac;import com.qiniu.api.rs.PutPolicy;import com.qiniu.ui.SHA;import com.qiniu.ui.contains.QiNiuConfig;import org.apache.http.Header;import org.json.JSONException;import java.io.BufferedOutputStream;import java.io.FileOutputStream;import java.util.Random;import static com.qiniu.ui.SHA.hMacSHA1Encrypt;/** * @date 2016年5月26日 上午11:00:43 * @author lijixin * @web https://agehua.github.io * @Description: 七牛云图片操作 */public class QiniuUitls &#123; private static final String fileName = \"temp.jpg\"; private static final String tempJpeg = Environment.getExternalStorageDirectory().getPath() + \"/\" + fileName; private static int maxWidth = 720; private static int maxHeight = 1080; public interface QiniuUploadUitlsListener &#123; void onSucess(String fileUrl); void onError(int errorCode, String msg); void onProgress(int progress); &#125; public interface QiniuRequestListener &#123; void onSucceed(byte[] bytes); void onFailed(byte[] bytes); &#125; /** * 将bitmap转换成jpeg，控制图片大小不大于720*1080，可以指定图片压缩质量 * @param bitmap * @param filePath * @param quality * @return */ public static boolean saveBitmapToJpegFile(Bitmap bitmap, String filePath, int quality) &#123; try &#123; FileOutputStream fileOutStr = new FileOutputStream(filePath); BufferedOutputStream bufOutStr = new BufferedOutputStream(fileOutStr); resizeBitmap(bitmap).compress(CompressFormat.JPEG, quality, bufOutStr); bufOutStr.flush(); bufOutStr.close(); &#125; catch (Exception exception) &#123; return false; &#125; return true; &#125; /** * 缩小图片 * * @param bitmap * @return */ public static Bitmap resizeBitmap(Bitmap bitmap) &#123; if (bitmap != null) &#123; int width = bitmap.getWidth(); int height = bitmap.getHeight(); //宽度大于720 if (width &gt; maxWidth) &#123; //按宽度等比例压缩图片 int pWidth = maxWidth; int pHeight = maxWidth * height / width; Bitmap result = Bitmap.createScaledBitmap(bitmap, pWidth, pHeight, false); bitmap.recycle(); return result; &#125; if (height &gt; maxHeight) &#123; //按高度等比例缩小图片 int pHeight = maxHeight; int pWidth = maxHeight * width / height; Bitmap result = Bitmap.createScaledBitmap(bitmap, pWidth, pHeight, false); bitmap.recycle(); return result; &#125; &#125; return bitmap; &#125; public static void uploadImage(Bitmap bitmap, QiniuUploadUitlsListener listener) &#123; saveBitmapToJpegFile(bitmap, tempJpeg,100); uploadImage(tempJpeg, listener); &#125; /** * 上传图片选择jpg格式，七牛图片api目前支持对jpg格式进行指定图片质量请求 * @param filePath * @param listener */ public static void uploadImage(String filePath, final QiniuUploadUitlsListener listener) &#123; final String fileUrlUUID = getFileUrlUUID(); String token = getToken(); if (token == null) &#123; if (listener != null) &#123; listener.onError(-1, \"token is null\"); &#125; return; &#125; UploadManager uploadManager = new UploadManager(); uploadManager.put(filePath, fileUrlUUID, token, (key, info, response) -&gt; &#123; System.out.println(\"debug:info = \" + info + \",response = \" + response); if (info != null &amp;&amp; info.statusCode == 200) &#123;// 上传成功 String fileRealUrl = getRealUrl(fileUrlUUID); System.out.println(\"debug:fileRealUrl = \" + fileRealUrl); if (listener != null) &#123; listener.onSucess(fileRealUrl); &#125; &#125; else &#123; if (listener != null) &#123; listener.onError(info.statusCode, info.error); &#125; &#125; &#125;, new UploadOptions(null, null, false, new UpProgressHandler() &#123; public void progress(String key, double percent) &#123; if (listener != null) &#123; listener.onProgress((int) (percent * 100)); &#125; &#125; &#125;, null)); &#125; /** * 生成远程文件路径（全局唯一） * &lt;p&gt;格式类似： H60-L12__1464851303930__156750_1884&lt;/p&gt; * @return */ private static String getFileUrlUUID() &#123; String filePath = android.os.Build.MODEL + \"__\" + System.currentTimeMillis() + \"__\" + (new Random().nextInt(500000)) + \"_\" + (new Random().nextInt(10000)); return filePath.replace(\".\", \"0\"); &#125; private static String getRealUrl(String fileUrlUUID) &#123; String filePath = \"http://\" + QiNiuConfig.QINIU_BUCKNAME + \".qiniudn.com/\" + fileUrlUUID; return filePath; &#125; /** * 获取token 本地生成 * * @return */ private static String getToken() &#123; Mac mac = new Mac(QiNiuConfig.QINIU_AK, QiNiuConfig.QINIU_SK); PutPolicy putPolicy = new PutPolicy(QiNiuConfig.QINIU_BUCKNAME); putPolicy.returnBody = \"&#123;\\\"name\\\": $(fname),\\\"size\\\": \\\"$(fsize)\\\",\\\"w\\\": \\\"$(imageInfo.width)\\\",\\\"h\\\": \\\"$(imageInfo.height)\\\",\\\"key\\\":$(etag)&#125;\"; try &#123; String uptoken = putPolicy.token(mac); System.out.println(\"debug:uptoken = \" + uptoken); return uptoken; &#125; catch (AuthException e) &#123; e.printStackTrace(); &#125; catch (JSONException e) &#123; e.printStackTrace(); &#125; return null; &#125; /** * 根据host和文件名，生成file的url下载地址，支持私有空间 * @param domain host：七牛的私有空间域名 * @param imgKey file key：空间里的文件名 * @return url下载地址 */ public static String downloadFile(String domain,String imgKey)&#123; //密钥配置 //构造私有空间的需要生成的下载的链接// String domain =\"http://example.xxx.clouddn.com/\";// String path =\"H60-L12__1464917382714__36888_5255\"; StringBuilder sb =new StringBuilder(); //加上过期时间戳字段 String url = sb.append(domain).append(imgKey).append(\"?e=1478365261\").toString(); Log.e(\"encodedEntryURI\",url); byte[] sign =null; try &#123; sign = SHA.hMacSHA1Encrypt(url,QiNiuConfig.QINIU_SK); &#125; catch (Exception e) &#123; e.printStackTrace(); &#125; String encodedSign = UrlSafeBase64.encodeToString(sign); sb.append(\"&amp;token=\").append(QiNiuConfig.QINIU_AK).append(\":\").append(encodedSign); Log.e(\"download token\",sb.toString()); return sb.toString(); &#125; /** * 列出空间中指定格式的文件 * @param bucket 空间名 * @param prefix 要指定的格式（前缀） * @param listener * @return */ public static void listFile(String bucket, String prefix,final QiniuRequestListener listener)&#123; try&#123; StringBuilder sb = new StringBuilder(); String entryUrl = sb.append(\"bucket=\").append(bucket) .append(\"&amp;prefix=\").append(prefix).toString(); String host = \"http://rsf.qbox.me\"; String path = \"/list?\" +entryUrl; String url = host+path; Log.e(\"AAAAAAA\", url); byte[] sign = SHA.hMacSHA1Encrypt(path+\"\\n\", QiNiuConfig.QINIU_SK); String encodedSign = UrlSafeBase64.encodeToString(sign); String authorization = QiNiuConfig.QINIU_AK + ':' + encodedSign; AsyncHttpClient client = new AsyncHttpClient(); client.addHeader(\"Content-Type\",\"application/x-www-form-urlencoded\"); client.addHeader(\"Authorization\", \"QBox \"+authorization); RequestParams params = new RequestParams(); client.post(url, params, new AsyncHttpResponseHandler() &#123; @Override public void onSuccess(int i, Header[] headers, byte[] bytes) &#123; if (null!=listener) listener.onSucceed(bytes); &#125; @Override public void onFailure(int i, Header[] headers, byte[] bytes, Throwable throwable) &#123; if (null!=listener) listener.onFailed(bytes); &#125; &#125;); &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; return ; &#125; /** * 删除空间中的文件 * @param bucket 删除文件的空间 * @param fileName 删除的文件 * */ public static boolean deleteFile(String bucket,String fileName,final QiniuRequestListener listener)&#123; try&#123; String entryUrl = bucket+\":\"+fileName; String encodedEntryURI = UrlSafeBase64.encodeToString(entryUrl.getBytes()); String host = \"http://rs.qiniu.com\"; String path = \"/delete/\"+encodedEntryURI; String url = host+path; Log.e(\"AAAAAAA\", url); byte[] sign = hMacSHA1Encrypt(path+\"\\n\", QiNiuConfig.QINIU_SK); String encodedSign = UrlSafeBase64.encodeToString(sign); String authorization = QiNiuConfig.QINIU_AK + ':' + encodedSign; AsyncHttpClient client = new AsyncHttpClient(); client.addHeader(\"Content-Type\",\"application/x-www-form-urlencoded\"); client.addHeader(\"Authorization\", \"QBox \"+authorization); RequestParams params = new RequestParams(); client.post(url, params, new AsyncHttpResponseHandler() &#123; @Override public void onSuccess(int i, Header[] headers, byte[] bytes) &#123; if (null!=listener) listener.onSucceed(bytes); &#125; @Override public void onFailure(int i, Header[] headers, byte[] bytes, Throwable throwable) &#123; if (null!=listener) listener.onFailed(bytes); if (null!=bytes) &#123; String s = new String(bytes); &#125; &#125; &#125;); &#125;catch(Exception e)&#123; e.printStackTrace(); &#125; return false; &#125;&#125; HMAC-SHA1签名加密类 使用下面方法生成对应七牛资源管理里用到的管理凭证 /** * 对外提供HMAC-SHA1签名方法 * @author agehua * */public class SHA &#123; private static final String MAC_NAME = \"HmacSHA1\"; private static final String ENCODING = \"UTF-8\"; /** * * 使用 HMAC-SHA1 签名方法对对encryptText进行签名 * @param encryptText 被签名的字符串 * @param encryptKey 密钥 * @return * @throws Exception */ public static byte[] hMacSHA1Encrypt(String encryptText, String encryptKey) throws Exception &#123; byte[] data = encryptKey.getBytes(ENCODING); // 根据给定的字节数组构造一个密钥,第二参数指定一个密钥算法的名称 SecretKey secretKey = new SecretKeySpec(data, MAC_NAME); // 生成一个指定 Mac 算法 的 Mac 对象 Mac mac = Mac.getInstance(MAC_NAME); // 用给定密钥初始化 Mac 对象 mac.init(secretKey); byte[] text = encryptText.getBytes(ENCODING); // 完成 Mac 操作 return mac.doFinal(text); &#125;&#125; ~~~ - 还有一个Config文件~~~ Javapublic final class QiNiuConfig &#123; public static final String token = getToken(); public static final String QINIU_AK = \"Your_AccessKey\"; public static final String QINIU_SK = \"Your_SecretKey\"; public static final String QINIU_BUCKNAME = \"你的私有空间\"; public static String getToken() &#123; Mac mac = new Mac(QiNiuConfig.QINIU_AK, QiNiuConfig.QINIU_SK); PutPolicy putPolicy = new PutPolicy(QiNiuConfig.QINIU_BUCKNAME); putPolicy.returnBody = \"&#123;\\\"name\\\": $(fname),\\\"size\\\": \\\"$(fsize)\\\",\\\"w\\\": \\\"$(imageInfo.width)\\\",\\\"h\\\": \\\"$(imageInfo.height)\\\",\\\"key\\\":$(etag)&#125;\"; try &#123; String uptoken = putPolicy.token(mac); System.out.println(\"debug:uptoken = \" + uptoken); return uptoken; &#125; catch (AuthException e) &#123; e.printStackTrace(); &#125; catch (JSONException e) &#123; e.printStackTrace(); &#125; return null; &#125;&#125; 点击在Gist上查看上面这些代码 最后，如果有问题欢迎讨论，我的邮箱简介里有 :) 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/28/qiniu-android-summary/","raw":null,"content":null,"categories":[{"name":"technology","slug":"technology","permalink":"http://agehua.github.io/categories/technology/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"qiniu","slug":"qiniu","permalink":"http://agehua.github.io/tags/qiniu/"}]},{"title":"android JNI学习① 基础知识","slug":"JNI-Learning","date":"2016-05-23T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/05/24/JNI-Learning/","link":"","permalink":"http://agehua.github.io/2016/05/24/JNI-Learning/","excerpt":"本文只是用来记录，写的不好还请见谅。\n1.JNI介绍JNI概念 : Java本地接口,Java Native Interface, 它是一个协议, 该协议用来沟通Java代码和外部的本地C/C++代码, 通过该协议 Java代码可以调用外部的本地代码, 外部的C/C++ 代码可以调用Java代码;\nC和Java的侧重 :\n\nC语言 : C语言中最重要的是 函数 function;\nJava语言 : Java中最重要的是 JVM, class类, 以及class中的方法;\n\nC与Java如何交流 :\n\nJNI规范 : C语言与Java语言交流需要一个适配器, 中间件, 即 JNI, JNI提供了一种规范;\nC语言中调用Java方法 : 可以让我们在C代码中找到Java代码class中的方法, 并且调用该方法;\nJava语言中调用C语言方法 : 同时也可以在Java代码中, 将一个C语言的方法映射到Java的某个方法上;\nJNI桥梁作用 : JNI提供了一个桥梁, 打通了C语言和Java语言之间的障碍;\n","text":"本文只是用来记录，写的不好还请见谅。 1.JNI介绍JNI概念 : Java本地接口,Java Native Interface, 它是一个协议, 该协议用来沟通Java代码和外部的本地C/C++代码, 通过该协议 Java代码可以调用外部的本地代码, 外部的C/C++ 代码可以调用Java代码; C和Java的侧重 : C语言 : C语言中最重要的是 函数 function; Java语言 : Java中最重要的是 JVM, class类, 以及class中的方法; C与Java如何交流 : JNI规范 : C语言与Java语言交流需要一个适配器, 中间件, 即 JNI, JNI提供了一种规范; C语言中调用Java方法 : 可以让我们在C代码中找到Java代码class中的方法, 并且调用该方法; Java语言中调用C语言方法 : 同时也可以在Java代码中, 将一个C语言的方法映射到Java的某个方法上; JNI桥梁作用 : JNI提供了一个桥梁, 打通了C语言和Java语言之间的障碍; JNI中的一些概念 : native : Java语言中修饰本地方法的修饰符, 被该修饰符修饰的方法没有方法体; Native方法 : 在Java语言中被native关键字修饰的方法是Native方法; JNI层 : Java声明Native方法的部分; JNI函数 : JNIEnv提供的函数, 这些函数在jni.h中进行定义; JNI方法 : Native方法对应的JNI层实现的 C/C++方法, 即在jni目录中实现的那些C语言代码; 2.NDK简单介绍C代码执行 : C代码被编译成库文件之后, 才能执行, 库文件分为动态库 和静态库 两种; 动态库 : unix环境下.so后缀的是动态库, windows环境下.dll 后缀的是动态库; 动态库可以依赖静态库加载一些可执行的C代码; 静态库 :.a后缀是静态库的扩展名; 库文件来源 : C代码 进行 编译 链接操作之后, 才会生成库文件, 不同类型的CPU 操作系统 生成的库文件是不一样; CPU分类 : arm结构, 嵌入式设备处理器; x86结构, pc服务器处理器; 不同的CPU指令集不同; 交叉编译 :windows x86编译出来的库文件可以在arm平台运行的代码; 交叉编译工具链 : Google提供的 NDK 就是交叉编译工具链, 可以在linux环境下编译出在arn平台下执行的二进制库文件; NDK作用 : 是Google提供了交叉编译工具链, 能够在linux平台编译出在arm平台下执行的二进制库文件; NDK版本介绍 : android-ndk-windows 是在windows系统中的cygwin使用的, android-ndk-linux 是在linux下使用的; 想深入了解NDK开发的同学，可以去安装一下cygwin，本文只涉及简单的C语言代码，不需要使用cygwin。 3.环境准备，使用android studio还是Eclipse推荐使用Eclipse，这篇文章讲了使用Eclipse生成.h文件和生成so文件的配置过程。配置成功后可以远离命令行Eclipse ADT插件生成.h/.so文件 3.1 Java调用C流程 a. 定义 Native 方法 : 比如在com.packagename.jni.JNITest.java 类中定义 Native 方法 public native int add(int x, int y); b. 生成方法签名 : 进入 AndroidProject/bin/classes 目录, 使用 javah com.packagename.jni.JNITest 命令, 便生成了头文件, 该头文件引用了 jni.h, 以及定义好了对应的 Native 方法, 生成 JNIEXPORT jint JNICALL Java_com_packagename_jni_JNITest_add (JNIEnv *, jobject, jint, jint); Java中定义的方法 : //将Java中的两个int值 传给C语言, 进行相加后, 返回java语言 shuliang.han.ndkparameterpassing.DataProvider public native int add(int x, int y); 对应C语言中定义的方法 : #include &lt;jni.h&gt; //方法签名, Java环境和调用native方法的类必不可少, 后面的参数就是native方法的参数 jint Java_com_packagename_jni_JNITest_add(JNIEnv * env, jobject obj, jint x, jint y) &#123; return x + y; &#125; 3.2 生成.so文件Android.mk 文件： LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := hello-jni LOCAL_SRC_FILES := hello-jni.c include $(BUILD_SHARED_LIBRARY) 文件内容解释： 获取当前文件内容 : $(call my-dir) 是编译器中的宏方法, 调用该宏方法, 就会返回前的目录路径; 赋值符号 : “ := “ 是赋值符号, 第一句话 是 返回当前文件所在的当前目录, 并将这个目录路径赋值给 LOCAL_PATH; 初始化编译模块参数 : $(CLEAR_VARS) 作用是将编译模块的参数初始化, LOCAL_MODULE LOCAL_SRC_FILES 也是这样的参数; 指定编译模块 : LOCAL_MODULE := hello-jni , 指定编译后的 so 文件名称, 编译好之后系统会在该名称前面加上 “lib”, 后缀加上 “.so”; 指定编译源文件 : LOCAL_SRC_FILES := hello-jni.c 告诉编译系统源文件, 如果有多个文件那么就依次写在后面即可; 编译成静态库 : include $(BUILD_SHARED_LIBRARY), 作用是告诉系统, 将编译的结果编译成.so后缀的静态库; 静态库引入 : NDK的platform中有很多 “.a” 结尾的动态库, 我们编译动态库的时候, 可以将一些静态库引入进来; 生成 动态库 so 文件 : 进入 Android.mk 所在目录, 在该目录执行ndk下的ndk-build命令; Java代码加载动态库 : 在 Java 代码中调用该类的类前面, 在类的一开始, 不在方法中, 加入 static&#123; System.loadLibrary(\"hello\"); &#125; ; Application.mk 文件内容为（不写这个文件也可以）: APP_STL := stlport_staticAPP_ABI := all 这篇文章是使用javah导出头文件过程中，常见错误和解决办法，这里做一个记录。 4.字符串的处理 Java中的String转为C语言中的char字符串下面的工具方法可以在C程序中解决这个问题： // java中的jstring, 转化为c的一个字符数组 char* Jstring2CStr(JNIEnv* env, jstring jstr) &#123; //声明了一个字符串变量 rtn char* rtn = NULL; //找到Java中的String的Class对象 jclass clsstring = (*env)-&gt;FindClass(env, \"java/lang/String\"); //创建一个Java中的字符串 \"GB2312\" jstring strencode = (*env)-&gt;NewStringUTF(env, \"GB2312\"); /* * 获取String中定义的方法 getBytes(), 该方法的参数是 String类型的, 返回值是 byte[]数组 * \"(Ljava/lang/String;)[B\" 方法前面解析 : * -- Ljava/lang/String; 表示参数是String字符串 * -- [B : 中括号表示这是一个数组, B代表byte类型, 返回值是一个byte数组 */ jmethodID mid = (*env)-&gt;GetMethodID(env, clsstring, \"getBytes\", \"(Ljava/lang/String;)[B\"); //调用Java中的getBytes方法, 传入参数介绍 参数②表示调用该方法的对象, 参数③表示方法id , 参数④表示方法参数 jbyteArray barr = (jbyteArray)(*env)-&gt;CallObjectMethod(env, jstr, mid, strencode); // String .getByte(\"GB2312\"); //获取数组的长度 jsize alen = (*env)-&gt;GetArrayLength(env, barr); //获取数组中的所有的元素 , 存放在 jbyte*数组中 jbyte* ba = (*env)-&gt;GetByteArrayElements(env, barr, JNI_FALSE); //将Java数组中所有元素拷贝到C的char*数组中, 注意C语言数组结尾要加一个 '\\0' if (alen &gt; 0) &#123; rtn = (char*) malloc(alen + 1); //new char[alen+1]; \"\\0\" memcpy(rtn, ba, alen); rtn[alen] = 0; &#125; (*env)-&gt;ReleaseByteArrayElements(env, barr, ba, 0); //释放内存 return rtn; &#125; Jstring2CStr方法讲解 : a. 获取Java中String类型的class对象 : 参数 : 上下文环境 env, String类完整路径 ; jclass clsstring = (*env)-&gt;FindClass(env, \"java/lang/String\"); b.创建Java字符串 : 使用 NewStringUTF 方法; jstring strencode = (*env)-&gt;NewStringUTF(env, \"GB2312\"); ~~~ - c.获取String中的getBytes()方法 : 参数介绍 ① env 上下文环境 ② 完整的类路径 ③ 方法名 ④ 方法签名, 方法签名 Ljava/lang/String; 代表参数是String字符串, [B 中括号表示这是一个数组, B代表byte类型, 返回值是一个byte数组;~~~ JavascriptjmethodID mid = (*env)-&gt;GetMethodID(env, clsstring, \"getBytes\", \"(Ljava/lang/String;)[B\"); ~~~ - d. 获取数组的长度 :~~~ Javascriptjsize alen = (*env)-&gt;GetArrayLength(env, barr); e. 获取数组元素 : 获取数组中的所有的元素 , 存放在 jbyte*数组中; jbyte* ba = (*env)-&gt;GetByteArrayElements(env, barr, JNI_FALSE); f.数组拷贝: 将Java数组中所有元素拷贝到C的char*数组中, 注意C语言数组结尾要加一个 ‘\\0’; if (alen &gt; 0) &#123; rtn = (char*) malloc(alen + 1); //new char[alen+1]; \"\\0\" memcpy(rtn, ba, alen); rtn[alen] = 0; &#125; g.释放内存 : (*env)-&gt;ReleaseByteArrayElements(env, barr, ba, 0); //释放内存 5.JNI方法命名规则(标准JNI规范) JNI实现的方法与Java中Native方法的映射关系 : 使用方法名进行映射, 可以使用javah工具进入bin/classes目录下执行命令, 即可生成头文件; JNI方法参数介绍: 参数① : 第一个参数是JNI接口指针JNIEnv; 参数② : 如果Native方法是非静态的, 那么第二个参数就是对Java对象的引用, 如果Native方法是静态的, 那么第二个参数就是对Java类的Class对象的引用; JNI方法名规范: 返回值+Java前缀+全路径类名+方法名+参数① JNIEnv+参数② jobject+其它参数; 注意分隔符 : Java前缀 与 类名 以及类名之间的包名 和 方法名之间 使用 “_“ 进行分割; 声明 非静态 方法: Native方法 : public int hello (String str, int i); JNI方法: jint Java_shuliang_han_Hello_hello(JNIEnv * env, jobject obj, jstring str, jint i); 声明 静态 方法 : Native方法 : public static int hello (String str, int i); JNI方法 : jint Java_shuliang_han_Hello_hello(JNIEnv * env, jobject clazz, jstring str, jint i); 两种规范 : 以上是Java的标准JNI规范, 在Android中还有一套自定义的规范, 该规范是Android应用框架层 和 框架层交互使用的JNI规范, 依靠方法注册 映射 Native方法 和 JNI方法; JNIEnv作用 : JNIEnv 是一个指针,指向了一组JNI函数, 这些函数可以在jni.h中查询到,通过这些函数可以实现 Java层 与 JNI层的交互 , 通过JNIEnv 调用JNI函数 可以访问java虚拟机, 操作java对象; JNI线程相关性 : JNIEnv只在当前的线程有效,JNIEnv不能跨线程传递, 相同的Java线程调用本地方法, 所使用的JNIEnv是相同的, 一个Native方法不能被不同的Java线程调用; JNIEnv结构体系 : JNIEnv指针指向一个线程相关的结构,线程相关结构指向一个指针数组,指针数组中的每个元素最终指向一个JNI函数. 6.AES加密实现网上有几种AES实现的方式： 1.这个是我现在项目中使用的方法，在Github上有这个工程，这种方式是使用JNI生成一个与设备相关的密码，可以将该密码作为AES的密钥。链接地址 2.网上还有一种方式是由JNI生成keyValue和iv，Java层使用：链接地址 主要代码： static &#123; System.loadLibrary(\"cwtlib\"); keyValue = getKeyValue(); iv = getIv(); if(null != keyValue &amp;&amp; null != iv) &#123; KeyGenerator kgen; try &#123; kgen = KeyGenerator.getInstance(\"AES\"); kgen.init(128, new SecureRandom(keyValue)); key = kgen.generateKey(); paramSpec = new IvParameterSpec(iv); ecipher = Cipher.getInstance(\"AES/CBC/PKCS5Padding\"); &#125; catch (NoSuchAlgorithmException e) &#123; &#125; catch (NoSuchPaddingException e) &#123; &#125; &#125;&#125; public static native byte[] getKeyValue();public static native byte[] getIv(); 这种方式，在android app程序完全退出后，再进入该app时，之前加密好的字符串无法解密。 3.还有一种是直接由C或C++实现AES整个算法，直接使用网上代码并不知道靠不靠谱 所以，我们项目最终使用了第一种方法 7.JNI混淆问题 检查下 C/C++代码中没有直接访问Java代码的类或者类的成员变量、类的成员函数。 如果有的话，这些就不能混淆 //保留jni的回调类-keep class com.your.jnicallback.class &#123; *; &#125;//这个不用更改，直接复制就可以-keepclasseswithmembernames class * &#123; native &lt;methods&gt;;&#125; 8.总结android 实现JNI入门并不难，笔者也刚刚入门，但要深入了解还是需要很长的路要走。 8.1 更新内容，JNI获取publickey实现在本文中最终使用第6点中的第一种方式，但原方法在4.0.4手机上遇到兼容性问题，详情请看我的这篇博客使用JNI获取publickey实现 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/24/JNI-Learning/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"JNI","slug":"jni","permalink":"http://agehua.github.io/tags/jni/"},{"name":"AES","slug":"aes","permalink":"http://agehua.github.io/tags/aes/"}]},{"title":"android JNI学习② JNI调用过程","slug":"JNI-Learning0","date":"2016-05-23T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/05/24/JNI-Learning0/","link":"","permalink":"http://agehua.github.io/2016/05/24/JNI-Learning0/","excerpt":"1.Android JNI调用过程1.1 由Android系统加载的JNIAndroid系统在启动启动过程中，先启动Kernel创建init进程，紧接着由init进程fork第一个横穿Java和C/C++的进程，即Zygote进程。Zygote启动过程中会AndroidRuntime.cpp中的startVm创建虚拟机，VM创建完成后，紧接着调用startReg完成虚拟机中的JNI方法注册。","text":"1.Android JNI调用过程1.1 由Android系统加载的JNIAndroid系统在启动启动过程中，先启动Kernel创建init进程，紧接着由init进程fork第一个横穿Java和C/C++的进程，即Zygote进程。Zygote启动过程中会AndroidRuntime.cpp中的startVm创建虚拟机，VM创建完成后，紧接着调用startReg完成虚拟机中的JNI方法注册。 在AndroidRuntime.cpp中： int AndroidRuntime::startReg(JNIEnv* env)&#123; //设置线程创建方法为javaCreateThreadEtc androidSetCreateThreadFunc((android_create_thread_fn) javaCreateThreadEtc); env-&gt;PushLocalFrame(200); //进程NI方法的注册 if (register_jni_procs(gRegJNI, NELEM(gRegJNI), env) &lt; 0) &#123; env-&gt;PopLocalFrame(NULL); return -1; &#125; env-&gt;PopLocalFrame(NULL); return 0;&#125; register_jni_procs(gRegJNI, NELEM(gRegJNI), env)这行代码的作用就是就是循环调用gRegJNI数组成员所对应的方法。 static int register_jni_procs(const RegJNIRec array[], size_t count, JNIEnv* env)&#123; for (size_t i = 0; i &lt; count; i++) &#123; if (array[i].mProc(env) &lt; 0) &#123; return -1; &#125; &#125; return 0;&#125; gRegJNI数组，有100多个成员变量，定义在AndroidRuntime.cpp： static const RegJNIRec gRegJNI[] = &#123; REG_JNI(register_android_os_MessageQueue), REG_JNI(register_android_os_Binder), ...&#125;; 该数组的每个成员都代表一个类文件的jni映射，其中REG_JNI是一个宏定义，该宏的作用就是调用相应的方法。 比如MessageQueue和Binder方法都是Android系统启动时就已经注册，所以在AndroidRuntime.cpp中可以找到相应的native方法，见AndroidRuntime.cpp的gRegJNI数组。这些注册方法命令格式为： register_[包名]_[类名] 示例一：以MessageQueue.java中的nativePollOnce方法为例，private native void nativePollOnce(long ptr, int timeoutMillis); 方法名：android.os.MessageQueue.nativePollOnce()，而相对应的native层方法名只是将点号替换为下划线，可得android_os_MessageQueue_nativePollOnce()。 前面说MessageQueue.java所定义的jni注册方法名应该是register_android_os_MessageQueue，的确存在于gRegJNI数组，说明这次JNI注册过程是有开机过程完成的。该方法在AndroidRuntime.cpp申明为extern方法： extern int register_android_os_MessageQueue(JNIEnv* env); 这些extern方法绝大多数位于/framework/base/core/jni/目录，大多数情况下native文件命名方式： [包名]_[类名].cpp[包名]_[类名].h Tips： MessageQueue.java ==&gt; android_os_MessageQueue.cpp 打开android_os_MessageQueue.cpp文件，搜索android_os_MessageQueue_nativePollOnce方法，这便找到了目标方法： static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj, jlong ptr, jint timeoutMillis) &#123; NativeMessageQueue* nativeMessageQueue = reinterpret_cast&lt;NativeMessageQueue*&gt;(ptr); nativeMessageQueue-&gt;pollOnce(env, obj, timeoutMillis);&#125; 示例二：对于native文件命名方式，有时并非[包名]_[类名].cpp，比如Binder.javaBinder.java所对应的native文件：android_util_Binder.cpp public static final native int getCallingPid(); 根据示例一方式，找到getCallingPid ==&gt; android_os_Binder_getCallingPid()，并且在AndroidRuntime.cpp中的gRegJNI数组中找到register_android_os_Binder。 按实例(一)方式则native文名应该为android_os_Binder.cpp，可是在/framework/base/core/jni/目录下找不到该文件，这是例外的情况。其实真正的文件名为android_util_Binder.cpp，这就是例外，这一点有些费劲，不明白为何google要如此打破规律的命名。 static jint android_os_Binder_getCallingPid(JNIEnv* env, jobject clazz)&#123; return IPCThreadState::self()-&gt;getCallingPid();&#125; 有人可能好奇，既然如何遇到打破常规的文件命令，怎么办？这个并不难，首先，可以尝试在/framework/base/core/jni/中搜索，对于binder.java，可以直接搜索binder关键字，其他也类似。如果这里也找不到，可以通过grep全局搜索android_os_Binder_getCallingPid这个方法在哪个文件。 jni存在的常见目录： /framework/base/core/jni/ /framework/base/services/core/jni/ /framework/base/media/jni/ 1.2 加载自定义的JNI方法前面两种都是在Android系统启动之初，便已经注册过JNI所对应的方法。 那么如果程序自己定义的jni方法，该如何查看jni方法所在位置呢？下面以MediaPlayer.java为例，其包名为android.media： public class MediaPlayer&#123; static &#123; System.loadLibrary(\"media_jni\"); native_init(); &#125; private static native final void native_init(); ...&#125; 通过static静态代码块中System.loadLibrary方法来加载动态库，库名为media_jni, Android平台则会自动扩展成所对应的libmedia_jni.so库 接下来便要查看libmedia_jni.so库定义所在文件，一般都是通过Android.mk文件定义LOCAL_MODULE:= libmedia_jni，可以采用grep或者mgrep来搜索包含libmedia_jni字段的Android.mk所在路径。 搜索可知，libmedia_jni.so位于/frameworks/base/media/jni/Android.mk。用前面实例(一)中的知识来查看相应的文件和方法名分别为： android_media_MediaPlayer.cppandroid_media_MediaPlayer_native_init() 再然后，你会发现果然在该Android.mk所在目录/frameworks/base/media/jni/中找到android_media_MediaPlayer.cpp文件，并在文件中存在相应的方法： static voidandroid_media_MediaPlayer_native_init(JNIEnv *env)&#123; jclass clazz; clazz = env-&gt;FindClass(\"android/media/MediaPlayer\"); fields.context = env-&gt;GetFieldID(clazz, \"mNativeContext\", \"J\"); ...&#125; Tips：MediaPlayer.java中的native_init方法所对应的native方法位于/frameworks/base/media/jni/目录下的android_media_MediaPlayer.cpp文件中的android_media_MediaPlayer_native_init方法。 总结：System.loadLibrary()的作用就是调用相应库中的JNI_OnLoad()方法。 1.3 说说JNI_OnLoad()过程。[-&gt; android_media_MediaPlayer.cpp] jint JNI_OnLoad(JavaVM* vm, void* reserved)&#123; JNIEnv* env = NULL; if (register_android_media_MediaPlayer(env) &lt; 0) &#123; goto bail; &#125; ...&#125; 详细说一下register_android_media_MediaPlayer [-&gt; android_media_MediaPlayer.cpp] static int register_android_media_MediaPlayer(JNIEnv *env)&#123; //【见3.4】 return AndroidRuntime::registerNativeMethods(env, \"android/media/MediaPlayer\", gMethods, NELEM(gMethods));&#125; 虚拟机相关的变量中有两个非常重要的量JavaVM和JNIEnv: 1.JavaVM：是指进程虚拟机环境，每个进程有且只有一个JavaVM实例 2.JNIEnv：是指线程上下文环境，每个线程有且只有一个JNIEnv实例 其中gMethods，记录java层和C/C++层方法的一一映射关系。 static JNINativeMethod gMethods[] = &#123; &#123;\"prepare\", \"()V\", (void *)android_media_MediaPlayer_prepare&#125;, &#123;\"_start\", \"()V\", (void *)android_media_MediaPlayer_start&#125;, &#123;\"_stop\", \"()V\", (void *)android_media_MediaPlayer_stop&#125;, &#123;\"seekTo\", \"(I)V\", (void *)android_media_MediaPlayer_seekTo&#125;, &#123;\"_release\", \"()V\", (void *)android_media_MediaPlayer_release&#125;, &#123;\"native_init\", \"()V\", (void *)android_media_MediaPlayer_native_init&#125;, ...&#125;; 这里涉及到结构体JNINativeMethod，其定义在jni.h文件： typedef struct &#123; const char* name; //Java层native函数名 const char* signature; //Java函数签名，记录参数类型和个数，以及返回值类型 void* fnPtr; //Native层对应的函数指针&#125; JNINativeMethod; 2.JNI资源JNINativeMethod结构体中有一个字段为signature(签名)，再介绍signature格式之前需要掌握各种数据类型在Java层、Native层以及签名所采用的签名格式。 2.1 数据类型 基本数据类型 Signature格式 Java Native B byte jbyte C char jchar D double jdouble F float jfloat I int jint S short jshort J long jlong Z boolean jboolean V void void 数组数据类型 数组简称则是在前面添加[： Signature格式 Java Native [B byte[] jbyteArray [C char[] jcharArray [D double[] jdoubleArray [F float[] jfloatArray [I int[] jintArray [S short[] jshortArray [J long[] jlongArray [Z boolean[] jbooleanArray 复杂数据类型 对象类型简称：L+classname +; Signature格式 Java Native Ljava/lang/String; String jstring L+classname +; 所有对象 jobject [L+classname +; Object[] jobjectArray Ljava.lang.Class; Class jclass Ljava.lang.Throwable; Throwable jthrowable Signature 有了前面的铺垫，那么再来通过实例说说函数签名： (输入参数…)返回值参数，这里用到的便是前面介绍的Signature格式。 Java函数 对应的签名 void foo() ()V float foo(int i) (I)F long foo(int[] i) ([I)J double foo(Class c) (Ljava/lang/Class;)D boolean foo(int[] i,String s) ([ILjava/lang/String;)Z String foo(int i) (I)Ljava/lang/String; 2.2 其他 (一)垃圾回收对于Java开发人员来说无需关系垃圾回收，完全由虚拟机GC来负责垃圾回收，而对于JNI开发人员，对于内存释放需要谨慎处理，需要的时候申请，使用完记得释放内容，以免发生内存泄露。在JNI提供了三种Reference类型，Local Reference(本地引用)， Global Reference（全局引用）， Weak Global Reference(全局弱引用)。其中Global Reference如果不主动释放，则一直不会释放；对于其他两个类型的引用都是释放的可能性，那是不是意味着不需要手动释放呢？答案是否定的，不管是这三种类型的那种引用，都尽可能在某个内存不再需要时，立即释放，这对系统更为安全可靠，以减少不可预知的性能与稳定性问题。 另外，ART虚拟机在GC算法有所优化，为了减少内存碎片化问题，在GC之后有可能会移动对象内存的位置，对于Java层程序并没有影响，但是对于JNI程序可要小心了，对于通过指针来直接访问内存对象是，Dalvik能正确运行的程序，ART下未必能正常运行。 (二)异常处理Java层出现异常，虚拟机会直接抛出异常，这是需要try..catch或者继续往外throw。但是对于JNI出现异常时，即执行到JNIEnv中某个函数异常时，并不会立即抛出异常来中断程序的执行，还可以继续执行内存之类的清理工作，直到返回到Java层时才会抛出相应的异常。 另外，Dalvik虚拟机有些情况下JNI函数出错可能返回NULL，但ART虚拟机在出错时更多的是抛出异常。这样导致的问题就可能是在Dalvik版本能正常运行的程序，在ART虚拟机上由于没有正确处理异常而崩溃。 3.JNI知识积累JNI学习积累之一 —- 常用函数大全http://blog.csdn.net/qinjuning/article/details/7595104 JNI学习积累之二 —- 数据类型映射、域描述符说明http://blog.csdn.net/qinjuning/article/details/7599796 JNI学习积累之三 —- 操作JNI函数以及复杂对象传递http://blog.csdn.net/qinjuning/article/details/7607214 JNI 实战全面解析http://blog.csdn.net/banketree/article/details/40535325 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/24/JNI-Learning0/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"JNI","slug":"jni","permalink":"http://agehua.github.io/tags/jni/"},{"name":"android source code","slug":"android-source-code","permalink":"http://agehua.github.io/tags/android-source-code/"}]},{"title":"Java String与C/C++中byte[]","slug":"javaString-and-bytes","date":"2016-05-17T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2016/05/18/javaString-and-bytes/","link":"","permalink":"http://agehua.github.io/2016/05/18/javaString-and-bytes/","excerpt":"   做JAVA经常会碰到中文乱码问题，还有各种编码的问题，特别是String类的内容需要重新编码的问题。要解决这些问题，必须了解清楚JAVA对于字符串是怎么处理的。\n1，“字符”是由数字来表示的   先来重新了解一下计算机是如何处理“字符”的，这个原理是大家必须记住的，特别是在用JAVA写程序的时候，万万不可模糊。我们知道，计算机把任何东西都用数字来表示，“字符”也不例外。比如我们要显示一个阿拉伯数字“3”，在我们的PC里，其实并不是仅仅用一个数字3来代表我们要写的“3”，而是以十六进制的0x33来代表，包括放在内存或者是写到文件里，其实都是写着0x33的，不信你可以编辑一个文本文件，写一个“3”，然后用ultraEdit看他的原始码。","text":"做JAVA经常会碰到中文乱码问题，还有各种编码的问题，特别是String类的内容需要重新编码的问题。要解决这些问题，必须了解清楚JAVA对于字符串是怎么处理的。 1，“字符”是由数字来表示的 先来重新了解一下计算机是如何处理“字符”的，这个原理是大家必须记住的，特别是在用JAVA写程序的时候，万万不可模糊。我们知道，计算机把任何东西都用数字来表示，“字符”也不例外。比如我们要显示一个阿拉伯数字“3”，在我们的PC里，其实并不是仅仅用一个数字3来代表我们要写的“3”，而是以十六进制的0x33来代表，包括放在内存或者是写到文件里，其实都是写着0x33的，不信你可以编辑一个文本文件，写一个“3”，然后用ultraEdit看他的原始码。 2，一切“字符”都必定用数字+编码表表示。 这时候，有一个问题：为什么一定要用0x33来代表“3”呢？而不用0x43来代表呢？或者是直接用0x03来代替？其实用什么来代表都可以，只不过大家都习惯了用ASCII编码表（是美国国家信息交换表）来确定各字符应该是用什么数字代表的。同样，为了表示中国字，我国也指定了中文的编码表，其中最广泛使用的是GB2312。比如中文的“当”字，就是用0xB5, 0xB1这两个八位的数字来表示的。所以 如果显示字符的程序不知道一列数字到底是按什么编码表编码的，他也无法去判断到底这些是什么文字。如果随便用一个不对的编码表来处理这些数字，处理出来的字符很可能完全是错的。比如在英文系统上，没有GB2312编码表，送给他一个0xB5,0xB1，他就傻傻的当作ASCII来处理（操作系统通常都有自己默认的编码表），结果显示出来就是两个奇怪的符号，因为这两个字在ASCII表里就是那两个符号。同样在繁体中文系统里，他的编码表是BIG5，显示出来也是一个奇怪的中文，不是“当”字。 3，UNICODE让全世界都说一种语言 看完上面的文字，是否觉得，世界有那么多语言，每个都有自己的一套编码表，很麻烦呢？就算是中文，也有两套流行的编码表，一个是GB2312，一个是BIG5。要使用不同中文的编码的字符时，还要转来转去，的确很麻烦。不光这个，如果想要写一篇包含很多过国文字的文章，就麻烦了，必须要让处理这个文章的程序知道，哪个字是什么编码标准的。如果你想要在文章里找一个字，也必须指定你要找的是哪种编码的哪个字。否则，你要找一个0xB5,0xB1的中文“当”字，很可能把同样数字表示的日文、波兰文这些不相干的字一起给你找出来，够麻烦的吧！ 所以人们想，不如大家都用同一个编码标准吧，各种文字都在编码表里有一席之地，处理文字的程序只需要都按这个编码表来处理就可以了。不过要一个编码表里包含所有的文字，这张表就大了，本来英文字+数字一共只有128个以内。但加上中文后，忽然就多了数万个，所以存放一个字符需要的大小也大了很多。现在 UNICODE规定了一个字符必须由2个8位数字来表示，想想，8x8x8x8x = 65536，是多大的一个数字啊！所以全世界的文字才能都包含进去。当然拉，也有人说中国字可能都不止6万个拉，还要包括别的文字，但人家外国人觉得你们中国人常用的也没那么多，所以就这么定了，我们也没办法。需要注意的是GB2312和UNICODE虽然都是用两个8位数来代表一个中文字，但具体的规格可不一样，比如0xB5,0xB1在UNICODE里面可不是“当”字，而是另外一国的文字来的。 4，C是如何简洁的处理字符的 我们来谈谈C的字符串。C语言诞生在JAVA之前，C语言的基本数据类型是没有字符串这个类型的，它只有char[]。也就是C把字符顺序放入一个字节数组就完了。而且C也不管放在数组里的是什么文字，也不管那些字是按什么编码标准的。而且他的char的大小也不一定是8位数字，有时候是16位也可能，这要看具体的机器和操作系统。所以写程序的人必须要知道正在处理的char[]的内容到底是按什么编码表表示的字符串，要知道如果比较两国文字是否相同，可是没任何意义的哦！ 5，JAVA是是如何处理字符的。 世界总会进步的，JAVA就是一个例子。JAVA终于有了String类了，它是解决字符问题的最好工具。在JAVA里，一个基本的要点是：String类对象是不需要指定编码表的！ 为什么它会自己知道一堆数字各代表什么字符呢？就是因为 String里的字符信息是用UNICODE编码存放的。而JAVA为了表示字符（注意是单个字符），也有char这个数据类型，而且他的大小是固定2个8位16进制数字长度，也就是0~65535罗。为的就是对应UNICODE里面的一个字符。大家如果想取一个String里的按UNICODE数字，可以用getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) 方法取得一个char[]，这个char[]里就是表示String字符的，按UNICODE编码表编码的数字。 可惜现在绝大多数的系统和程序都不是按UNICODE来处理字符，而JAVA程序总是要和别的程序和系统交换数据的，所以在接收一个字符，或者是发送一个字符的时候，就必须要留意当前系统和UNICODE的关系了。比如你从网络或者文件接受到一数字：0xB5,0xB1，JAVA程序并不知道这两个字到底是中文呢？还是日文，或者英文。你如果不指明这个两个数字的编码表，JAVA就会按当前系统默认的编码表来处理。如果这两个数字是从中文WIN98发出去的，JAVA程序又是在英文LINUX上运行的，那就出现了所谓的乱码问题了。也就是JAVA按英文的编码表ASCII来处理这两个数字，当通过new String({0xB5,0xB1})得到的String的时候，这个String代表的已经不是中文的“当”字，而是两个英文的奇怪字符了。不过如果你知道这两个数字一定是中文的话，就可以指定用new String({0xB5,0xB1},”GB2312”)来处理，这时候新建立的String才真的是一个“当”字。当然拉，如果你要把一个“当”字的JAVA的String显示在中文WIN98上，必须把这个字输出成两个8位数字：0xB5,0xB1，不管是写成文件还是输出到浏览器上，都必须是0xB5,0xB1。如何把“当”字用GB2312输出？String.getBytes(“GB2312”) 就可以拉！所以有一点要记住：和外界交换任何信息都是以byte[]来进行的！。你可以留意一下JAVA大多数的I/O类，都有以byte[]作为参数和返回值的方法。不过，也有很多写的比较糊涂的程序，没有提供byte[]交换信息的方法，害的不同文字平台的程序员很头疼。Servlet的HttpRequest.getParameter()就是这样。好在有的JSP/SERVLET容易还提供先指定编码表的方法，才能比较简单的解决这个问题。 6，网上关于JAVA中文问题的一些错误处理方法。 一个是最常见的，不管什么内容，都用new String(…,”ISO-8859-1”)来建立字符串，然后使用的时候按默认的编码格式（通常在服务器上都是英文系统）输出字符串。这样其实你使用的String并不是按UNICODE来代表真正的字符，而是强行把BYTE数组复制到String的char[]里，一旦你的运行环境改变，你就被迫要修改一大堆的代码。而且也无法在同一个字符串里处理几种不同编码的文字。 另一个是把一种编码格式的字符串，比如是GB2312，转换成另一种格式的字符串，比如UTF-8，然后不指明是UTF-8编码，而直接用new String(…)来建立String，这样放在String里面的字符也是无法确定的，它在不同的系统上代表不同的字符。如果要求别人用“UTF-8格式”的String来交换信息的时候，其实已经破坏了JAVA为了兼容各种语言所做的规定。这种错误的本质思想是还按写C语言的方式，把字符串纯粹当作可以自己自由编码的存储器使用，而忽略了JAVA字符串只有一种编码格式。如果真的想自由编码，用byte[]或者char[]就完全了解决问题的了。 7，其他资料字符，字节和编码 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/18/javaString-and-bytes/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"byte[]","slug":"byte","permalink":"http://agehua.github.io/tags/byte/"}]},{"title":"google cloud message（GCM）和Azure实现Notification总结","slug":"GCM-Azure_summary","date":"2016-05-11T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/05/12/GCM-Azure_summary/","link":"","permalink":"http://agehua.github.io/2016/05/12/GCM-Azure_summary/","excerpt":"1.相关资料我也是一知半解，基本上就是根据官方教程来实现，但microsoft的azure文档我找了好久，英文不好，汗。。。\ngcm start: https://developers.google.com/cloud-messaging/android/start\nazure start: https://azure.microsoft.com/zh-cn/documentation/articles/notification-hubs-android-get-started/\ngcm official demo: https://github.com/google/gcm\ngcm personal demo: https://github.com/iammert/FastGCM","text":"1.相关资料我也是一知半解，基本上就是根据官方教程来实现，但microsoft的azure文档我找了好久，英文不好，汗。。。 gcm start: https://developers.google.com/cloud-messaging/android/start azure start: https://azure.microsoft.com/zh-cn/documentation/articles/notification-hubs-android-get-started/ gcm official demo: https://github.com/google/gcm gcm personal demo: https://github.com/iammert/FastGCM 2.遇到的问题 1.手机运行官方demo时，发送消息，消息收不到必须切换一下网络才可以 stackoverflow上有人问过这个问题：http://stackoverflow.com/questions/13835676/google-cloud-messaging-messages-sometimes-not-received-until-network-state-cha 3.onActivityResult()和onResume()调用顺序API中这样描述：当你一个Activity是以请求码开始，结束时返回给前页面结果码，页面根据结果码进行相应的信息处理。我们会在返回的页面先接受结果码，然后才调用onResume()。 通常我们还会遇到这样一个问题：在处理返回页面的数据问题1.需要从服务器上刷新数据时我们会在onResume()方法里处理2.而刷新从结束界面返回的数据我们会在onAcitviyResult()方法里面处理 为了避免二者在同一块控件上对数据处理，我们只需加个标识符，在两个方法里进行判断，要用哪个方法进行刷新 4.Android4.4以上系统根据Uri正确获取文件路径的方法public static String getPhotoPathFromContentUri(Context context, Uri uri) &#123; String photoPath = \"\"; if(context == null || uri == null) &#123; return photoPath; &#125; if(Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.KITKAT &amp;&amp; DocumentsContract.isDocumentUri(context, uri)) &#123; String docId = DocumentsContract.getDocumentId(uri); if(isExternalStorageDocument(uri)) &#123; String [] split = docId.split(\":\"); if(split.length &gt;= 2) &#123; String type = split[0]; if(\"primary\".equalsIgnoreCase(type)) &#123; photoPath = Environment.getExternalStorageDirectory() + \"/\" + split[1]; &#125; &#125; &#125; else if(isDownloadsDocument(uri)) &#123; Uri contentUri = ContentUris.withAppendedId(Uri.parse(\"content://downloads/public_downloads\"), Long.valueOf(docId)); photoPath = getDataColumn(context, contentUri, null, null); &#125; else if(isMediaDocument(uri)) &#123; String[] split = docId.split(\":\"); if(split.length &gt;= 2) &#123; String type = split[0]; Uri contentUris = null; if(\"image\".equals(type)) &#123; contentUris = MediaStore.Images.Media.EXTERNAL_CONTENT_URI; &#125; else if(\"video\".equals(type)) &#123; contentUris = MediaStore.Video.Media.EXTERNAL_CONTENT_URI; &#125; else if(\"audio\".equals(type)) &#123; contentUris = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI; &#125; String selection = MediaStore.Images.Media._ID + \"=?\"; String[] selectionArgs = new String[] &#123; split[1] &#125;; photoPath = getDataColumn(context, contentUris, selection, selectionArgs); &#125; &#125; &#125; else if(\"file\".equalsIgnoreCase(uri.getScheme())) &#123; photoPath = uri.getPath(); &#125; else &#123; photoPath = getDataColumn(context, uri, null, null); &#125; return photoPath;&#125;private static boolean isExternalStorageDocument(Uri uri) &#123; return \"com.android.externalstorage.documents\".equals(uri.getAuthority());&#125;private static boolean isDownloadsDocument(Uri uri) &#123; return \"com.android.providers.downloads.documents\".equals(uri.getAuthority());&#125;private static boolean isMediaDocument(Uri uri) &#123; return \"com.android.providers.media.documents\".equals(uri.getAuthority());&#125;private static String getDataColumn(Context context, Uri uri, String selection, String[] selectionArgs) &#123; Cursor cursor = null; String column = MediaStore.Images.Media.DATA; String[] projection = &#123; column &#125;; try &#123; cursor = context.getContentResolver().query(uri, projection, selection, selectionArgs, null); if (cursor != null &amp;&amp; cursor.moveToFirst()) &#123; int index = cursor.getColumnIndexOrThrow(column); return cursor.getString(index); &#125; &#125; finally &#123; if (cursor != null &amp;&amp; !cursor.isClosed()) cursor.close(); &#125; return null;&#125; 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/05/12/GCM-Azure_summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"GCM","slug":"gcm","permalink":"http://agehua.github.io/tags/gcm/"},{"name":"azure","slug":"azure","permalink":"http://agehua.github.io/tags/azure/"},{"name":"notification","slug":"notification","permalink":"http://agehua.github.io/tags/notification/"}]},{"title":"《android开发艺术探索》读书笔记","slug":"android-books-reading-","date":"2016-03-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/03/20/android-books-reading-/","link":"","permalink":"http://agehua.github.io/2016/03/20/android-books-reading-/","excerpt":"第1章 Activity的生命周期和启动模式本节和《Android群英传》中的第8章Activity和Activity调用栈分析有关系，建议先阅读该章的总结\n第1章 Activity的生命周期和启动模式\n1.1 Activity生命周期全面分析1.1.1 典型情况下生命周期分析\n(1)一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart方法就会被调用。\n\n(2)当用户打开新的Activity或者切换到桌面的时候，回调如下：onPause -&gt; onStop，但是如果新Activity采用了透明主题，那么onStop方法不会被回调。当用户再次回到原来的Activity时，回调如下：onRestart -&gt; onStart -&gt; onResume。\n\n","text":"第1章 Activity的生命周期和启动模式本节和《Android群英传》中的第8章Activity和Activity调用栈分析有关系，建议先阅读该章的总结 第1章 Activity的生命周期和启动模式 1.1 Activity生命周期全面分析1.1.1 典型情况下生命周期分析 (1)一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart方法就会被调用。 (2)当用户打开新的Activity或者切换到桌面的时候，回调如下：onPause -&gt; onStop，但是如果新Activity采用了透明主题，那么onStop方法不会被回调。当用户再次回到原来的Activity时，回调如下：onRestart -&gt; onStart -&gt; onResume。 (3)onStart和onStop对应，它们是从Activity是否可见这个角度来回调的；onPause和onResume方法对应，它们是从Activity是否位于前台这个角度来回调的。 (4)从Activity A进入到Activity B，回调顺序是onPause(A) -&gt; onCreate(B) -&gt; onStart(B) -&gt; onResume(B) -&gt; onStop(A)，所以不能在onPause方法中做重量级的操作。 1.1.2 异常情况下生命周期分析 (1)onSaveInstanceState方法只会出现在Activity被异常终止的情况下，它的调用时机是在onStop之前，它和onPause方法没有既定的时序关系，可能在它之前，也可能在它之后。 当Activity被重新创建的时候，onRestoreInstanceState会被回调，它的调用时机是onStart之后。 系统只会在Activity即将被销毁并且有机会重新显示的情况下才会去调用onSaveInstanceState方法。 当Activity在异常情况下需要重新创建时，系统会默认为我们保存当前Activity的视图结构，并且在Activity重启后为我们恢复这些数据，比如文本框中用户输入的数据、listview滚动的位置等，这些view相关的状态系统都会默认为我们恢复。具体针对某一个view系统能为我们恢复哪些数据可以查看view的源码中的onSaveInstanceState和onRestoreInstanceState方法。 (2)Activity按优先级的分类 前台Activity；可见但非前台Activity；后台Activity (3)android:configChanges=”xxx”属性，常用的主要有下面三个选项： local：设备的本地位置发生了变化，一般指切换了系统语言； keyboardHidden：键盘的可访问性发生了变化，比如用户调出了键盘； orientation：屏幕方向发生了变化，比如旋转了手机屏幕。 配置了android:configChanges=”xxx”属性之后，Activity就不会在对应变化发生时重新创建，而是调用Activity的onConfigurationChanged方法。 1.2 Activity的启动模式1.2.1 启动模式 (1)当任务栈中没有任何Activity的时候，系统就会回收这个任务栈。 (2)从非Activity类型的Context(例如ApplicationContext、Service等)中以standard模式启动新的Activity是不行的，因为这类context并没有任务栈，所以需要为待启动Activity指定FLAG_ACTIVITY_NEW_TASK标志位。 (3)任务栈分为前台任务栈和后台任务栈，后台任务栈中的Activity位于暂停状态，用户可以通过切换将后台任务栈再次调到前台。 (4)参数TaskAffinity用来指定Activity所需要的任务栈，意为任务相关性。 默认情况下，所有Activity所需的任务栈的名字为应用的包名。TaskAffinity属性主要和singleTask启动模式或者allowTaskReparenting属性配对使用，在其他情况下没有意义。 当TaskAffinity和singleTask启动模式配对使用的时候，它是具有该模式的Activity的目前任务栈的名字，待启动的Activity会运行在名字和TaskAffinity相同的任务栈中； 当TaskAffinity和allowTaskReparenting结合的时候，当一个应用A启动了应用B的某个Activity C后，如果Activity C的allowTaskReparenting属性设置为true的话，那么当应用B被启动后，系统会发现Activity C所需的任务栈存在了，就将Activity C从A的任务栈中转移到B的任务栈中。 (5)singleTask模式的具体分析： 当一个具有singleTask启动模式的Activity请求启动之后，系统首先会寻找是否存在A想要的任务栈， 如果不存在，就重新创建一个任务栈，然后创建Activity的实例把它放到栈中；如果存在Activity所需的任务栈，这时候要看栈中是否有Activity实例存在. 如果有，那么系统就会把该Activity实例调到栈顶，并调用它的onNewIntent方法(它之上的Activity会被迫出栈，所以singleTask模式具有FLAG_ACTIVITY_CLEAR_TOP效果)；如果Activity实例不存在，那么就创建Activity实例并把它压入栈中。 (6)设置启动模式既可以使用xml属性android:launchMode，也可以使用代码intent.addFlags()。区别在于限定范围不同，前者无法直接为Activity设置FLAG_ACTIVITY_CLEAR_TOP标识，而后者无法为Activity指定singleInstance模式。 1.2.2 Activity的FlagsFLAG_ACTIVITY_NEW_TASK,FLAG_ACTIVITY_SINGLE_TOP,FLAG_ACTIVITY_CLEAR_TOP FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS：具有这个标记的Activity不会出现在历史Activity列表中，当某些情况下我们不希望用户通过历史列表回到我们的Activity的时候这个标记比较有用，它等同于属性设置android:excludeFromRecents=”true”。 1.3 IntentFilter的匹配规则 (1)IntentFilter中的过滤信息有action、category、data，为了匹配过滤列表，需要同时匹配过滤列表中的action、category、data信息，否则匹配失败。 一个过滤列表中的action、category、data可以有多个，所有的action、category、data分别构成不同类别，同一类别的信息共同约束当前类别的匹配过程。只有一个Intent同时匹配action类别、category类别和data类别才算完全匹配，只有完全匹配才能成功启动目标Activity。此外，一个Activity中可以有多个intent-filter，一个Intent只要能匹配任何一组intenf-filter即可成功启动对应的Activity。 &lt;intent-filter&gt; &lt;action android:name=\"com.ryg.charpter_1.c\" /&gt; &lt;action android:name=\"com.ryg.charpter_1.d\" /&gt; &lt;category android:name=\"com.ryg.category.c\" /&gt; &lt;category android:name=\"com.ryg.category.d\" /&gt; &lt;category android:name=\"android.intent.category.DEFAULT\" /&gt; &lt;data android:mimeType=\"text/plain\" /&gt;&lt;/intent-filter&gt;~~~ - (2)action匹配规则 只要Intent中的action能够和过滤规则中的任何一个action相同即可匹配成功，action匹配区分大小写。- (3)category匹配规则 Intent中如果有category那么所有的category都必须和过滤规则中的其中一个category相同，如果没有category的话那么就是默认的category，即android.intent.category.DEFAULT，所以为了Activity能够接收隐式调用，配置多个category的时候必须加上默认的category。- (4)data匹配规则 data的结构很复杂，语法大致如下：~~~ Javascript&lt;data android:scheme=\"string\" android:host=\"string\" android:port=\"string\" android:path=\"string\"` android:pathPattern=\"string\" android:pathPrefix=\"string\" android:mimeType=\"string\" /&gt; 主要由mimeType和URI组成，其中mimeType代表媒体类型，而URI的结构也复杂，大致如下： &lt;scheme&gt;://&lt;host&gt;:&lt;port&gt;/[&lt;path&gt;]|[&lt;pathPrefix&gt;]|[pathPattern] 例如content://com.example.project:200/folder/subfolder/etc scheme、host、port分别表示URI的模式、主机名和端口号，其中如果scheme或者host未指定那么URI就无效。 path、pathPattern、pathPrefix都是表示路径信息，其中path表示完整的路径信息，pathPrefix表示路径的前缀信息；pathPattern表示完整的路径，但是它里面包含了通配符(*)。 data匹配规则：Intent中必须含有data数据，并且data数据能够完全匹配过滤规则中的某一个data。 URI有默认的scheme！ 如果过滤规则中的mimeType指定为image/*或者text/*等这种类型的话，那么即使过滤规则中没有指定URI，URI有默认的scheme是content和file！如果过滤规则中指定了scheme的话那就不是默认的scheme了。 //URI有默认值&lt;intent-filter&gt; &lt;data android:mimeType=\"image/*\"/&gt; ...&lt;/intent-filter&gt; //URI默认值被覆盖&lt;intent-filter&gt; &lt;data android:mimeType=\"image/*\" android:scheme=\"http\" .../&gt; ...&lt;/intent-filter&gt; 如果要为Intent指定完整的data，必须要调用setDataAndType方法！ 不能先调用setData然后调用setType，因为这两个方法会彼此清除对方的值。intent.setDataAndType(Uri.parse(\"file://abc\"), \"image/png\"); data的下面两种写法作用是一样的： &lt;intent-filter&gt; &lt;data android:scheme=\"file\" android:host=\"www.github.com\"/&gt;&lt;/intent-filter&gt;&lt;intent-filter&gt; &lt;data android:scheme=\"file\"/&gt; &lt;data android:host=\"www.github.com\"/&gt;&lt;/intent-filter&gt; 如何判断是否有Activity能够匹配我们的隐式Intent？ (1)PackageManager的resolveActivity方法或者Intent的resolveActivity方法：如果找不到就会返回null (2)PackageManager的queryIntentActivities方法：它返回所有成功匹配的Activity信息针对Service和BroadcastReceiver等组件，PackageManager同样提供了类似的方法去获取成功匹配的组件信息，例如queryIntentServices、queryBroadcastReceivers等方法 有一类action和category比较重要，它们在一起用来标明这是一个入口Activity，并且会出现在系统的应用列表中。 &lt;intent-filter&gt; &lt;action android:name=\"android.intent.action.MAIN\" /&gt; &lt;category android:name=\"android.intent.category.LAUNCHER\" /&gt;&lt;/intent-filter&gt; 第2章 IPC机制2.1 Android IPC简介(1)任何一个操作系统都需要有相应的IPC机制，Linux上可以通过命名通道、共享内存、信号量等来进行进程间通信。Android系统不仅可以使用了Binder机制来实现IPC，还可以使用Socket实现任意两个终端之间的通信。 2.2 Android中的多进程模式 (1)通过给四大组件指定android:process属性就可以开启多进程模式. 默认进程的进程名是包名packageName，进程名以:开头的进程属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中，而进程名不以:开头的进程属于全局进程，其他应用通过ShareUID方法可以和它跑在同一个进程中。 android:process=”:xyz” //进程名是 packageName:xyz android:process=”aaa.bbb.ccc” //进程名是 aaa.bbb.ccc (2)Android系统会为每个应用分配一个唯一的UID，具有相同UID的应用才能共享数据。 两个应用通过ShareUID跑在同一个进程中是有要求的，需要这两个应用有相同的ShareUID并且签名相同才可以。 在这种情况下，它们可以相互访问对方的私有数据，比如data目录、组件信息等，不管它们是否跑在同一个进程中。如果它们跑在同一个进程中，还可以共享内存数据，它们看起来就像是一个应用的两个部分。 (3)android系统会为每个进程分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，所以不同的虚拟机中访问同一个类的对象会产生多个副本。 (4)使用多进程容易造成以下几个问题： 1.静态成员和单例模式完全失效； 2.线程同步机制完全失效：无论锁对象还是锁全局对象都无法保证线程同步； 3.SharedPreferences的可靠性下降：SharedPreferences不支持并发读写； 4.Application会多次创建：当一个组件跑在一个新的进程的时候，系统要在创建新的进程的同时分配独立的虚拟机，应用会重新启动一次，也就会创建新的Application。运行在同一个进程中的组件是属于同一个虚拟机和同一个Application。 同一个应用的不同组件，如果它们运行在不同进程中，那么和它们分别属于两个应用没有本质区别。 2.3 IPC基础概念介绍 (1)Serializable接口是Java中为对象提供标准的序列化和反序列化操作的接口，而Parcelable接口是Android提供的序列化方式的接口。 (2)serialVersionUId是一串long型数字，主要是用来辅助序列化和反序列化的，原则上序列化后的数据中的serialVersionUId只有和当前类的serialVersionUId相同才能够正常地被反序列化。 serialVersionUId的详细工作机制：序列化的时候系统会把当前类的serialVersionUId写入序列化的文件中，当反序列化的时候系统会去检测文件中的serialVersionUId，看它是否和当前类的serialVersionUId一致，如果一致就说明序列化的类的版本和当前类的版本是相同的，这个时候可以成功反序列化；否则说明版本不一致无法正常反序列化。一般来说，我们应该手动指定serialVersionUId的值。 1.静态成员变量属于类不属于对象，所以不参与序列化过程； 2.声明为transient的成员变量不参与序列化过程。 (3)Parcelable接口内部包装了可序列化的数据，可以在Binder中自由传输，Parcelable主要用在内存序列化上，可以直接序列化的有Intent、Bundle、Bitmap以及List和Map等等，下面是一个实现了Parcelable接口的示例 public class Book implements Parcelable &#123; public int bookId; public String bookName; public Book() &#123; &#125; public Book(int bookId, String bookName) &#123; this.bookId = bookId; this.bookName = bookName; &#125; //“内容描述”，如果含有文件描述符返回1，否则返回0，几乎所有情况下都是返回0 public int describeContents() &#123; return 0; &#125; //实现序列化操作，flags标识只有0和1，1表示标识当前对象需要作为返回值返回，不能立即释放资源，几乎所有情况都为0 public void writeToParcel(Parcel out, int flags) &#123; out.writeInt(bookId); out.writeString(bookName); &#125; //实现反序列化操作 public static final Parcelable.Creator&lt;Book&gt; CREATOR = new Parcelable.Creator&lt;Book&gt;() &#123; //从序列化后的对象中创建原始对象 public Book createFromParcel(Parcel in) &#123; return new Book(in); &#125; public Book[] newArray(int size) &#123;//创建指定长度的原始对象数组 return new Book[size]; &#125; &#125;; private Book(Parcel in) &#123; bookId = in.readInt(); bookName = in.readString(); &#125;&#125; (4)Binder是Android中的一个类，它实现了IBinder接口。 从IPC角度看，Binder是Android中一种跨进程通信的方式；Binder还可以理解为虚拟的物理设备，它的设备驱动是/dev/binder； 从Framework层角度看，Binder是ServiceManager连接各种Manager和相应的ManagerService的桥梁； 从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。 在Android开发中，Binder主要用在Service中，包括AIDL和Messenger，其中普通Service中的Binder不涉及进程间通信，较为简单；而Messenger的底层其实是AIDL，正是Binder的核心工作机制。 (5)aidl工具根据aidl文件自动生成的java接口的解析： 首先，它声明了几个接口方法，同时还声明了几个整型的id用于标识这些方法，id用于标识在transact过程中客户端所请求的到底是哪个方法； 接着，它声明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务端都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub内部的代理类Proxy来完成。 所以，这个接口的核心就是它的内部类Stub和Stub内部的代理类Proxy。 下面分析其中的方法： 1.asInterface(android.os.IBinder obj)：用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的，如果客户端和服务端是在同一个进程中，那么这个方法返回的是服务端的Stub对象本身，否则返回的是系统封装的Stub.Proxy对象。 2.asBinder：返回当前Binder对象。 3.onTransact：这个方法运行在服务端中的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。 这个方法的原型是public Boolean onTransact(int code, Parcelable data, Parcelable reply, int flags) 服务端通过code可以知道客户端请求的目标方法，接着从data中取出所需的参数，然后执行目标方法，执行完毕之后，将结果写入到reply中。如果此方法返回false，说明客户端的请求失败，利用这个特性可以做权限验证(即验证是否有权限调用该服务)。 4.Proxy#[Method]：代理类中的接口方法，这些方法运行在客户端，当客户端远程调用此方法时，它的内部实现是： 首先创建该方法所需要的参数，然后把方法的参数信息写入到_data中，接着调用transact方法来发起RPC请求，同时当前线程挂起；然后服务端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据。 如果搞清楚了自动生成的接口文件的结构和作用之后，其实是可以不用通过AIDL而直接实现Binder的，主席写的示例代码 (6)Binder的两个重要方法linkToDeath和unlinkToDeath Binder运行在服务端，如果由于某种原因服务端异常终止了的话会导致客户端的远程调用失败，所以Binder提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath方法可以给Binder设置一个死亡代理，当Binder死亡的时候客户端就会收到通知，然后就可以重新发起连接请求从而恢复连接了。 如何给Binder设置死亡代理呢？ 1.声明一个DeathRecipient对象，DeathRecipient是一个接口，其内部只有一个方法bindeDied，实现这个方法就可以在Binder死亡的时候收到通知了。 private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() &#123; @Override public void binderDied() &#123; if (mRemoteBookManager == null) return; mRemoteBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0); mRemoteBookManager = null; // TODO:这里重新绑定远程Service &#125;&#125;; 2.在客户端绑定远程服务成功之后，给binder设置死亡代理 mRemoteBookManager.asBinder().linkToDeath(mDeathRecipient, 0); 2.4 Android中的IPC方式 (1)使用Bundle：Bundle实现了Parcelable接口，Activity、Service和Receiver都支持在Intent中传递Bundle数据。 (2)使用文件共享：这种方式简单，适合在对数据同步要求不高的进程之间进行通信，并且要妥善处理并发读写的问题。 SharedPreferences是一个特例，虽然它也是文件的一种，但是由于系统对它的读写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对它的读写就变得不可靠，当面对高并发读写访问的时候，有很大几率会丢失数据，因此，不建议在进程间通信中使用SharedPreferences。 (3)使用Messenger：Messenger是一种轻量级的IPC方案，它的底层实现就是AIDL。Messenger是以串行的方式处理请求的，即服务端只能一个个处理，不存在并发执行的情形，详细的示例见原书。 (4)使用AIDL 大致流程：首先建一个Service和一个AIDL接口，接着创建一个类继承自AIDL接口中的Stub类并实现Stub类中的抽象方法，在Service的onBind方法中返回这个类的对象，然后客户端就可以绑定服务端Service，建立连接后就可以访问远程服务端的方法了。 1.AIDL支持的数据类型：基本数据类型、String和CharSequence、ArrayList、HashMap、Parcelable以及AIDL； 2.某些类即使和AIDL文件在同一个包中也要显式import进来； 3.AIDL中除了基本数据类，其他类型的参数都要标上方向：in、out或者inout； 4.AIDL接口中支持方法，不支持声明静态变量； 5.为了方便AIDL的开发，建议把所有和AIDL相关的类和文件全部放入同一个包中，这样做的好处是，当客户端是另一个应用的时候，可以直接把整个包复制到客户端工程中。 6.RemoteCallbackList是系统专门提供的用于删除跨进程Listener的接口。RemoteCallbackList是一个泛型，支持管理任意的AIDL接口，因为所有的AIDL接口都继承自IInterface接口。 (5)使用ContentProvider 1.ContentProvider主要以表格的形式来组织数据，并且可以包含多个表； 2.ContentProvider还支持文件数据，比如图片、视频等，系统提供的MediaStore就是文件类型的ContentProvider； 3.ContentProvider对底层的数据存储方式没有任何要求，可以是SQLite、文件，甚至是内存中的一个对象都行； 4.要观察ContentProvider中的数据变化情况，可以通过ContentResolver的registerContentObserver方法来注册观察者； (6)使用Socket Socket是网络通信中“套接字”的概念，分为流式套接字和用户数据包套接字两种，分别对应网络的传输控制层的TCP和UDP协议。 2.5 Binder连接池 (1)当项目规模很大的时候，创建很多个Service是不对的做法，因为service是系统资源，太多的service会使得应用看起来很重，所以最好是将所有的AIDL放在同一个Service中去管理。 整个工作机制是：每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同业务模块之间是不能有耦合的，所有实现细节我们要单独开来，然后向服务端提供自己的唯一标识和其对应的Binder对象；对于服务端来说，只需要一个Service，服务端提供一个queryBinder接口，这个接口能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法调用了。 Binder连接池的主要作用就是将每个业务模块的Binder请求统一转发到远程Service去执行，从而避免了重复创建Service的过程。 (2)作者实现的Binder连接池BinderPool的实现源码，建议在AIDL开发工作中引入BinderPool机制。 2.6 选用合适的IPC方式 第9章 四大组件的工作过程本篇摘选自amurocrash的专栏 9.1 四大组件的运行状态 (1)四大组件中只有BroadcastReceiver既可以在AndroidManifest文件中注册，也可以在代码中注册，其他三个组件都必须在AndroidManifest文件中注册；ContentProvider的调用不需要借助Intent，其他三个组件都需要借助Intent。 (2)Activity是一种展示型组件，用于向用户展示界面，可由显式或者隐式Intent来启动。 (3)Service是一种计算型组件，用于在后台执行计算任务。尽管service是用于后台执行计算的，但是它本身是运行在主线程中的，因此耗时的后台计算仍然需要在单独的线程中去完成。Service组件有两种状态：启动状态和绑定状态。当service处于绑定状态时，外界可以很方便的和service进行通信，而在启动状态中是不可与外界通信的。 (4)BroadcastReceiver是一种消息型组件，用于在不同的组件乃至不同的应用之间传递消息，它工作在系统内部。广播有两种注册方式：静态注册和动态注册。静态注册是在AndroidManifest中注册，在应用安装的时候会被系统解析，这种广播不需要应用启动就可以收到相应的广播。动态注册需要通过Context.registerReceiver()来注册，这种广播需要应用启动才能注册并接收广播。BroadcastReceiver组件一般来说不需要停止，它也没有停止的概念。 (5)ContentProvider是一种数据共享型组件，用于向其他组件乃至其他应用共享数据。ContentProvider中的insert、delete、update、query方法需要处理好线程同步，因为这几个方法是在Binder线程池中被调用的，另外ContentProvider组件也不需要手动停止。 9.2 Activity的工作过程(1)Activity启动的大致流程 (2)ApplicationThread是ActivityThread的一个内部类，它继承自ApplicationThreadNative，而ApplicationThreadNative继承自Binder并实现了IApplicationThread接口，ApplicationThreadNative的作用其实就和系统为AIDL文件生成的类是一样的。(3)ActivityManagerService(AMS)继承自ActivityManagerNative，而ActivityManagerNative继承自Binder并实现了IActivityManager这个Binder接口，因此AMS也是一个Binder。(4)一个应用只有一个Application对象，它的创建也是通过Instrumentation来完成的，这个过程和Activity对象的创建过程一样，都是通过类加载器来实现的。(5)ContextImpl是Context的具体实现，ContextImpl是通过Activity的attach方法来和Activity建立关联的，在attach方法中Activity还会完成Window的创建并建立自己和Window的关联，这样当window接收到外部输入事件后就可以将事件传递给Activity。 [这里可能有误，应该是Activity将事件传递给window] 9.3 Service的工作过程(1)Service有两种状态：启动状态和绑定状态，两种状态是可以共存的。启动过程： 绑定过程： 9.4 BroadcastReceiver的工作过程(1)BroadcastReceiver的工作过程包括广播注册过程、广播发送和接收过程。注册过程：静态注册的时候是由PackageManagerService来完成整个注册过程，下面是动态注册的过程发送和接收： (2)广播的发送有几种类型：普通广播、有序广播和粘性广播，有序广播和粘性广播与普通广播相比具有不同的特性，但是发送和接收过程是类似的。 (3)一个应用处于停止状态分为两种情况：一是应用安装后未运行；二是应用被手动或者其他应用强停了。从Android 3.1开始，处于停止状态的应用无法接受到开机广播。 9.5 ContentProvider的工作过程(1)当ContentProvider所在的进程启动的时候，它会同时被启动并被发布到AMS中，这个时候它的onCreate要先去Application的onCreate执行。(2)ContentProvider的启动过程： 1.当一个应用启动时，入口方法是ActivityThread的main方法，其中创建ActivityThread的实例并创建主线程的消息队列； 2.ActivityThread的attach方法中会远程调用ActivityManagerService的attachApplication，并将ApplicationThread提供给AMS，ApplicationThread主要用于ActivityThread和AMS之间的通信； 3.ActivityManagerService的attachApplication会调用ApplicationThread的bindApplication方法，这个方法会通过H切换到ActivityThread中去执行，即调用handleBindApplication方法； 4.handleBindApplication方法会创建Application对象并加载ContentProvider，注意是先加载ContentProvider，然后调用Application的onCreate方法。 (3)ContentProvider的android:multiprocess属性决定它是否是单实例，默认值是false，也就是默认是单实例。当设置为true时，每个调用者的进程中都存在一个ContentProvider对象。(4)当调用ContentProvider的insert、delete、update、query方法中的任何一个时，如果ContentProvider所在的进程没有启动的话，那么就会触发ContentProvider的创建，并伴随着ContentProvider所在进程的启动。下图是ContentProvider的query操作的大致过程： 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/20/android-books-reading-/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"reading","slug":"reading","permalink":"http://agehua.github.io/tags/reading/"}]},{"title":"android新特性新知识点总结","slug":"android-new-knowledge-summary","date":"2016-03-19T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/03/20/android-new-knowledge-summary/","link":"","permalink":"http://agehua.github.io/2016/03/20/android-new-knowledge-summary/","excerpt":"一、mipmap 目录和drawable 目录有什么区别Nexus 6 有 493 ppi，它刚好在 xxhdpi和xxxhdpi之间，所以显示的时候需要对xxxhdpi的资源进行缩小，如果你用了mipmap-xxxhdpi,那么这里会对sclae有一个优化，性能更好，占用内存更少。所以现在官方推荐使用mipmap：\n二、setTranslucentStatus()方法在Android4.4之后使用沉浸式状态栏，需要用到这个方法","text":"一、mipmap 目录和drawable 目录有什么区别Nexus 6 有 493 ppi，它刚好在 xxhdpi和xxxhdpi之间，所以显示的时候需要对xxxhdpi的资源进行缩小，如果你用了mipmap-xxxhdpi,那么这里会对sclae有一个优化，性能更好，占用内存更少。所以现在官方推荐使用mipmap： 二、setTranslucentStatus()方法在Android4.4之后使用沉浸式状态栏，需要用到这个方法 public class MainActivity extends Activity&#123; @Override protected void onCreate(Bundle savedInstanceState) &#123; super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); //首先检测当前的版本是否是api&gt;=19的 if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.KITKAT) &#123; setTranslucentStatus(true); &#125; SystemBarTintManager tintManager = new SystemBarTintManager(this); tintManager.setStatusBarTintEnabled(true); tintManager.setStatusBarTintColor(Color.parseColor(\"#FFC1E0\")); &#125; @TargetApi(19) private void setTranslucentStatus(boolean on) &#123; Window win = getWindow(); WindowManager.LayoutParams winParams = win.getAttributes(); final int bits = WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS; if (on) &#123; winParams.flags |= bits; &#125; else &#123; winParams.flags &amp;= ~bits; &#125; win.setAttributes(winParams); &#125;&#125; 布局设置 &lt;LinearLayout xmlns:android=&quot;http://schemas.android.com/apk/res/android&quot; android:layout_width=&quot;match_parent&quot; android:layout_height=&quot;match_parent&quot; &lt;!--这两行是必须设置的--&gt; android:fitsSystemWindows=&quot;true&quot; android:clipToPadding=&quot;true&quot; android:orientation=&quot;vertical&quot; android:background=&quot;#FFD9EC&quot; &gt; &lt;TextView android:text=&quot;沉浸式状态栏&quot; android:layout_width=&quot;match_parent&quot; android:layout_height=&quot;50dp&quot; android:textSize=&quot;23dp&quot; android:layout_gravity=&quot;center_horizontal&quot; android:gravity=&quot;center&quot; android:background=&quot;#FFD9EC&quot; /&gt; &lt;TextView android:layout_width=&quot;match_parent&quot; android:layout_height=&quot;match_parent&quot; android:background=&quot;@android:color/darker_gray&quot;/&gt;&lt;/LinearLayout&gt; 三、获取Bitmap图片大小的代码public int getBitmapSize(Bitmap bitmap)&#123; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.KITKAT)&#123; //API 19 return bitmap.getAllocationByteCount(); &#125; if (Build.VERSION.SDK_INT &gt;= Build.VERSION_CODES.HONEYCOMB_MR1)&#123;//API 12 return bitmap.getByteCount(); &#125; return bitmap.getRowBytes() * bitmap.getHeight(); //earlier version&#125; 四、Activity横竖屏切换生命周期总结： 1、不设置Activity的android:configChanges时，切屏会重新调用各个生命周期，切横屏时会执行一次，切竖屏时会执行两次 2、设置Activity的android:configChanges=”orientation”时，切屏还是会重新调用各个生命周期，切横、竖屏时只会执行一次 3、设置Activity的android:configChanges=”orientation|keyboardHidden”时，切屏不会重新调用各个生命周期，只会执行onConfigurationChanged方法 验证： 1、新建一个Activity，并把各个生命周期打印出来 2、运行Activity，得到如下信息 onCreate--&gt;onStart--&gt;onResume--&gt; 3、按crtl+f12切换成横屏时 onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt; 4、再按crtl+f12切换成竖屏时，发现打印了两次相同的log onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt;onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt; 5、修改AndroidManifest.xml，把该Activity添加 android:configChanges=”orientation”，执行步骤3 onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt; 6、再执行步骤4，发现不会再打印相同信息，但多打印了一行onConfigChanged onSaveInstanceState--&gt;onPause--&gt;onStop--&gt;onDestroy--&gt;onCreate--&gt;onStart--&gt;onRestoreInstanceState--&gt;onResume--&gt;onConfigurationChanged--&gt; 7、把步骤5的android:configChanges=”orientation” 改成android:configChanges=”orientation|keyboardHidden”，执行步骤3，就只打印onConfigChanged onConfigurationChanged--&gt; 8、执行步骤4 onConfigurationChanged--&gt;onConfigurationChanged--&gt; 总结一下整个Activity的生命周期 1.补充一点，当前Activity产生事件弹出Toast和AlertDialog的时候Activity的生命周期不会有改变 2.Activity运行时按下HOME键(跟被完全覆盖是一样的)：onSaveInstanceState –&gt; onPause –&gt; onStop onRestart –&gt;onStart—&gt;onResume 3.Activity未被完全覆盖只是失去焦点：onPause—&gt;onResume 五.setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION)的限制在stackoverflow 上有一个提问：onTouchEvent() will not be triggered if setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION) is invoked Android 4.4 (API Level 19) introduces a new SYSTEM_UI_FLAG_IMMERSIVE flag for setSystemUiVisibility() that lets your app go truly “full screen.” This flag, when combined with the SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_FULLSCREEN flags, hides the navigation and status bars and lets your app capture all touch events on the screen. 正确用法应该是：int uiOptions = View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE;getWindow().getDecorView().setSystemUiVisibility(uiOptions); 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/20/android-new-knowledge-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"new features","slug":"new-features","permalink":"http://agehua.github.io/tags/new-features/"},{"name":"Basic Knowledge","slug":"basic-knowledge","permalink":"http://agehua.github.io/tags/basic-knowledge/"}]},{"title":"近期总结facebook google+ Twitter sign-in fragment使用","slug":"facebook-google+signin","date":"2016-03-14T16:00:00.000Z","updated":"2024-12-05T09:41:56.278Z","comments":true,"path":"2016/03/15/facebook-google+signin/","link":"","permalink":"http://agehua.github.io/2016/03/15/facebook-google+signin/","excerpt":"1.相关资料blog: 关于Google+以及Facebook第三方登录实现的一点总结\ng+官方教程: G+ start\nfacebook官方教程: Facebook start\niCCP: Not recognizing known sRGB profile","text":"1.相关资料blog: 关于Google+以及Facebook第三方登录实现的一点总结 g+官方教程: G+ start facebook官方教程: Facebook start iCCP: Not recognizing known sRGB profile 今天做分享的时候遇到了这个问题： [2016-04-01 11:24:04 - Dex Loader] Unable to execute dex: method ID not in [0, 0xffff]: 65536 [2016-04-01 11:24:04 - VIVAT_SHARESDK] Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536 大项目中遇到的问题看这个博客 iCCP: Not recognizing known sRGB profile 删除png图片内嵌的iCCP profile sRGB报错 今天有碰见一个坑，改其他代码，然后在编译的时候就出现这个问题，对就是这个问题。网上查了资料，也就这个资料最全面，大家可以去看见http://my.oschina.net/1pei/blog/479162?fromerr=ARrUPlGS 处理这个问题我使用了一种方法，记录下来以便以后使用 步骤1:下载Image Magick http://www.imagemagick.com.cn/download.html.如果是windows的，请下载含dll的 步骤2： 在要处理的文件夹使用如下命令 ，一定要在要处理的文件夹使用 //WINDOWS使用set fn=E:\\Program Files\\ImageMagick-6.9.0-Q16\\convert.exe for /f \"tokens=*\" %i in ('dir/s/b *.png') do \"%fn%\" \"%i\" -strip \"%i\"（因为是window的，所以把%%i改为%i） //LINUX使用 set fn=E:\\Program Files\\ImageMagick-6.9.0-Q16\\convert.exe for /f \"tokens=*\" %%i in ('dir/s/b *.png') do \"%fn%\" \"%%i\" -strip \"%%i\" 2.遇到问题 1.“This client application’s callback url has been locked”. 使用Twitter signin时遇到了这个问题，这个错误信息是在logcat中找到的，原因是在Twitter的Settings里勾选了“Enable Callback Locking (It is recommended to enable callback locking to ensure apps cannot overwrite the callback url)”选项，这个选项表示不允许app本地更改callback url。也可看这个页面 3.add() vs. replace() 只有在Fragment数量大于等于2的时候，调用add()还是replace()的区别才能体现出来。 当通过add()连续两次添加Fragment的时候，每个Fragment生命周期中的onAttach()-onResume()都会被各调用一次，而且两个Fragment的View会被同时attach到containerView。 同样，退出Activty时，每个Fragment生命周期中的onPause()-onDetach()也会被各调用一次。 但当使用replace()来添加Fragment的时候，第二次添加会导致第一个Fragment被销毁，即执行第二个Fragment的onAttach()方法之前会先执行第一个Fragment的onPause()-onDetach()方法，同时containerView会detach第一个Fragment的View。 调用show() &amp; hide()方法时. Fragment的生命周期方法并不会被执行，仅仅是Fragment的View被显示或者​隐藏。而且，尽管Fragment的View被隐藏，但它在父布局中并未被detach，仍然是作为containerView的childView存在着。相比较下，attach() &amp; detach()做的就更彻底一些。一旦一个Fragment被detach()，它的onPause()-onDestroyView()周期都会被执行。 同时Fragment的View也会被detach。在重新调用attach()后，onCreateView()-onResume()周期也会被再次执行。 remove() 其实看完上面的分析，remove()方法基本也就明白了。相对应add()方法执行onAttach()-onResume()的生命周期，remove()就是完成剩下的onPause()-onDetach()周期。 4.FragmentTransaction add 和 replace 区别使用 FragmentTransaction 的时候，它提供了这样两个方法，一个 add ， 一个 replace .add 和 replace 影响的只是界面，而控制回退的，是事务。 add 是把一个fragment添加到一个容器 container 里。 Add a fragment to the activity state. This fragment may optionally also have its view (if Fragment.onCreateView returns non-null) into a container view of the activity. public abstract FragmentTransaction add (int containerViewId, Fragment fragment, String tag) replace 是先remove掉相同id的所有fragment，然后在add当前的这个fragment。 Replace an existing fragment that was added to a container. This is essentially the same as calling remove(Fragment) for all currently added fragments that were added with the same containerViewId and then add(int, Fragment, String) with the same arguments given here. public abstract FragmentTransaction replace (int containerViewId, Fragment fragment, String tag) 在大部分情况下，这两个的表现基本相同。因为，一般，咱们会使用一个FrameLayout来当容器，而每个Fragment被add 或者 replace 到这个FrameLayout的时候，都是显示在最上层的。所以你看到的界面都是一样的。但是，使用add的情况下，这个FrameLayout其实有2层，多层肯定要比一层的来得浪费，所以还是推荐使用replace。当然有时候还是需要使用add的。比如要实现轮播图的效果，每个轮播图都是一个独立的Fragment，而他的容器FrameLayout需要add多个Fragment，这样他就可以根据提供的逻辑进行轮播了。 而至于返回键的时候，这个跟事务有关，跟使用add还是replace没有任何关系。 5.要想fragment完整地执行生命周期fragment跳转是要使用replace()方法，并一定要指定tag，否则有些方法不会执行（比如onResume），例如： getFragmentManager() .beginTransaction() .replace(R.id.base_container, inputVerifyCodeFragment,\"tag_code\") .addToBackStack(null).commit(); 6.fragment事件穿透如果发现fragment2的点击事件可以被fragment栈下一层的fragment1获取到，可以在fragment2布局的根部加上：android:clickable=”true”。问题解决 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/15/facebook-google+signin/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"third-party signin","slug":"third-party-signin","permalink":"http://agehua.github.io/tags/third-party-signin/"}]},{"title":"android Google map使用总结","slug":"android-googlemap-summary","date":"2016-02-29T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2016/03/01/android-googlemap-summary/","link":"","permalink":"http://agehua.github.io/2016/03/01/android-googlemap-summary/","excerpt":"1.在代码中编译google map要想编译编译google map必须使用Google map api。并在自己的工程中引入google-play-services_lib。两个都需要在SDK Manager中下载。前者要在对应android api中勾选，后者要勾选在Extras下的Google Play Service。\n要注意的是map2.0要使用com.google.android.gms包名下的类\nGoogle Maps Android API 使用OpenGL ES第2版来渲染地图。如果未安装OpenGL ES第2版，地图将不会出现。可以在 AndroidManifest.xml 中添加以下元素作为元素的子元素来过滤不能支持的手机：\n&lt;uses-feature        android:glEsVersion=\"0x00020000\"        android:required=\"true\"/&gt;","text":"1.在代码中编译google map要想编译编译google map必须使用Google map api。并在自己的工程中引入google-play-services_lib。两个都需要在SDK Manager中下载。前者要在对应android api中勾选，后者要勾选在Extras下的Google Play Service。 要注意的是map2.0要使用com.google.android.gms包名下的类 Google Maps Android API 使用OpenGL ES第2版来渲染地图。如果未安装OpenGL ES第2版，地图将不会出现。可以在 AndroidManifest.xml 中添加以下元素作为元素的子元素来过滤不能支持的手机： &lt;uses-feature android:glEsVersion=\"0x00020000\" android:required=\"true\"/&gt; 2.在编码中遇到的问题1.可以实现OnCameraChangeListener接口，来实现对相机状态的监听，比如我就记录下了地图缩放的大小 @Overridepublic void onCameraChange(CameraPosition arg0) &#123; // TODO Auto-generated method stub zoom = arg0.zoom;&#125; 2.向将处理地图的 Activity 添加 Fragment 对象。 最简单的实现方式是，向Activity 的布局文件添加 元素。 3.实现 OnMapReadyCallback 接口，并使用onMapReady(GoogleMap)回调方法获取GoogleMap对象的句柄。GoogleMap对象是对地图本身的内部表示。如需设置地图的视图选项，可以使用UiSettings设置地图的样式。 4.调用Fragment上的getMapAsync()以注册回调。 5.使用手机定位，定位成功后再map上显示标记： MarkerOptions markerOpt = new MarkerOptions(); markerOpt.position(new LatLng(geoLat, geoLng)); markerOpt.draggable(false); markerOpt.visible(true); markerOpt.anchor(0.5f, 0.5f);//设为图片中心 markerOpt.icon(BitmapDescriptorFactory .fromResource(R.drawable.sos_location_38x53)); mMap.addMarker(markerOpt); //将摄影机移动到指定的地理位置 cameraPosition = new CameraPosition.Builder() .target(new LatLng(geoLat, geoLng)) // Sets the center of the map to ZINTUN .zoom(zoom) // 缩放比例 .bearing(0) // Sets the orientation of the camera to east .build(); // Creates a CameraPosition from the builder mMap.animateCamera(CameraUpdateFactory.newCameraPosition(cameraPosition));~~~ 6.实现地图圆角效果：使用圆角.9图片，中间透明，圆角四周不透明&lt;br&gt;详细可以看这个提问：[Is there a way to implement rounded corners to a Mapfragment?](http://stackoverflow.com/questions/14469208/is-there-a-way-to-implement-rounded-corners-to-a-mapfragment)7.去掉google地图自带的蓝色圆点GoogleMap.setMyLocationEnabled(false);8.解决mapview与scrollview嵌套滑动的问题：思路就是使用getParent().requestDisallowInterceptTouchEvent(true);方法，让子类接收到touch事件~~~ Javapublic class MyMapView extends MapView &#123; private ViewParent mViewParent; public MyMapView(Context context) &#123; super(context); &#125; public MyMapView(Context context, AttributeSet attrs) &#123; super(context, attrs); &#125; public MyMapView(Context context, AttributeSet attrs, int defStyle) &#123; super(context, attrs, defStyle); &#125; public MyMapView(Context context, GoogleMapOptions options) &#123; super(context, options); &#125; public void setViewParent(@Nullable final ViewParent viewParent) &#123; //any ViewGroup mViewParent = viewParent; &#125; @Override public boolean onInterceptTouchEvent(final MotionEvent event) &#123; switch (event.getAction()) &#123; case MotionEvent.ACTION_DOWN: if (null == mViewParent) &#123; //设置父类不拦截touch事件，子view可以接收到touch事件 getParent().requestDisallowInterceptTouchEvent(true); &#125; else &#123; mViewParent.requestDisallowInterceptTouchEvent(true); &#125; break; case MotionEvent.ACTION_UP: if (null == mViewParent) &#123; //让父类拦截touch事件 getParent().requestDisallowInterceptTouchEvent(false); &#125; else &#123; mViewParent.requestDisallowInterceptTouchEvent(false); &#125; break; default: break; &#125; return super.onInterceptTouchEvent(event); &#125;&#125; 9.LocationListener，一直回调到onProviderDisabled 有可能是因为手机没有开启定位服务，解决办法是： @Overridepublic void onProviderDisabled(String provider) &#123; isLocatedSuccess = false; if (provider.equals(\"network\")) //跳到位置服务设置页面 startActivity(new Intent(android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS));&#125; 3.在真机上测试效果需要在真机上安装这两个包：com.android.vending.apk（Google play store）和com.google.android.gms.apk（Google play services）可以在国内应用市场上去搜索最新版本，也可以使用我上传的文件： 链接：http://pan.baidu.com/s/1i5q8jo5 密码：solm 安装成功以后，再运行自己的程序，查看效果了 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2016/03/01/android-googlemap-summary/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"google map","slug":"google-map","permalink":"http://agehua.github.io/tags/google-map/"}]},{"title":"2015阅读书单","slug":"book-list-of-2015","date":"2015-11-05T16:00:00.000Z","updated":"2023-11-16T03:42:40.825Z","comments":true,"path":"2015/11/06/book-list-of-2015/","link":"","permalink":"http://agehua.github.io/2015/11/06/book-list-of-2015/","excerpt":"","text":"本文链接：http://agehua.github.io/2015/11/06/book-list-of-2015/","raw":null,"content":null,"categories":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/categories/read/"}],"tags":[{"name":"read","slug":"read","permalink":"http://agehua.github.io/tags/read/"}]},{"title":"java多线程和并发面试问答","slug":"java-multithreading-concurrent","date":"2015-03-15T16:00:00.000Z","updated":"2024-12-05T09:41:56.277Z","comments":true,"path":"2015/03/16/java-multithreading-concurrent/","link":"","permalink":"http://agehua.github.io/2015/03/16/java-multithreading-concurrent/","excerpt":"本文基于酷勤网关于java多线程和并发面试题的文章，进行了少量的整理和补充。原文在这。\n\n以下是正文：\n多线程和并发问题是Java技术面试中面试官比较喜欢问的问题之一。在这里，从面试的角度列出了大部分重要的问题，但是你仍然应该牢固的掌握Java多线程基础知识来对应日后碰到的问题。","text":"本文基于酷勤网关于java多线程和并发面试题的文章，进行了少量的整理和补充。原文在这。 以下是正文： 多线程和并发问题是Java技术面试中面试官比较喜欢问的问题之一。在这里，从面试的角度列出了大部分重要的问题，但是你仍然应该牢固的掌握Java多线程基础知识来对应日后碰到的问题。 Java多线程面试问题1. 什么是进程和线程？进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动，进程是系统进行资源分配和调度的一个独立单位。线程是进程的一个实体，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。 线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源（如程序计数器，一组寄存器和栈），但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。一个线程可以创建和撤销另一个线程；同一个进程中的多个线程之间可以并发执行。相对进程而言，线程是一个更加接近于执行体的概念，它可以与同进程中的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。在串行程序基础上引入线程和进程是为了提高程序的并发度，从而提高程序运行效率和响应时间。 2. 进程和线程之间有什么不同？一个进程是一个独立(self contained)的运行环境，它可以被看作一个程序或者一个应用。而线程是在进程中执行的一个任务。 简而言之,一个程序至少有一个进程,一个进程至少有一个线程。 线程的划分尺度小于进程，使得多线程程序的并发性高。 进程在执行过程中拥有独立的内存单元，而多个线程共享内存，极大地提高了程序的运行效率。 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。 从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。 形象的讲，进程就是一个项目组，每个程序员就是里面的线程呀！当然一个程序员也可以叫做一个项目组，对应的就是一个进程只有一个线程。公司里面的任务是分配给项目组级别的，干活的就是其中的程序员。总的意思就是，进程和线程没有什么区别。吐槽的话：我的意思就是进程干不过来了，那就多开几个线程呀！from JacobK 3. 多线程编程的好处是什么？ 在进程内创建、终止线程比创建、终止进程要快； 同一进程内的线程间切换比进程间的切换要快,尤其是用户级线程间的切换。 在多线程程序中，多个线程被并发的执行以提高程序的效率，CPU不会因为某个线程需要等待资源而进入空闲状态。多个线程共享堆内存(heap memory)，因此创建多个线程去执行一些任务会比创建多个进程更好。举个例子，Servlets比CGI更好，是因为Servlets支持多线程而CGI不支持。 4. 用户线程和守护线程有什么区别？当我们在Java程序中创建一个线程，它就被称为用户线程。一个守护线程是在后台执行并且不会阻止JVM终止的线程。当没有用户线程在运行的时候，JVM关闭程序并且退出（与守护线程是否在运行没有关系）。一个守护线程创建的子线程依然是守护线程。守护线程应用背景：后台线程，比如可以收集某些系统状态的线程，发送email的线程，等不希望影响JVM的事情。 5. 我们如何创建一个线程？有两种创建线程的方法：一是实现Runnable接口，然后将它传递给Thread的构造函数，创建一个Thread对象；二是直接继承Thread类。Read more… 6. 有哪些不同的线程生命周期？当我们在Java程序中新建一个线程时，它的状态是New。当我们调用线程的start()方法时，状态被改变为Runnable。线程调度器会为Runnable线程池中的线程分配CPU时间并且讲它们的状态改变为Running。其他的线程状态还有Waiting，Blocked和Dead。Read more… Java中线程的状态分为6种。 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。 阻塞(BLOCKED)：表示线程阻塞于锁。阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。 终止(TERMINATED)：表示该线程已经执行完毕。这6种状态定义在Thread类的State枚举中，可查看源码进行一一对应 https://segmentfault.com/a/1190000038392244 7. 可以直接调用Thread类的run()方法么？可以，但是如果我们调用了Thread的run()方法，它的行为就会和普通的方法一样，为了在新的线程中执行我们的代码，必须使用Thread。start()方法。 8. 如何让正在运行的线程暂停一段时间？我们可以使用Thread类的Sleep()方法让线程暂停一段时间。需要注意的是，这并不会让线程终止，一旦从休眠中唤醒线程，线程的状态将会被改变为Runnable，并且根据线程调度，它将得到执行。 9. 你对线程优先级的理解是什么？线程的优先级越高，那么就可以分占相对多的CPU时间片。每个进程都有相应的优先级，线程优先级决定它何时运行和占用CPU时间。最终的优先级共分32级。是从0到31的数值，称为 基本优先级别。OS调度的是线程，真正具有优先级的是线程，而进程优先级是作为一个优先级Class存在。一个线程创建的时候，会继承进程的优先级。 外线程优先级可以用SetThreadPriority来进行微调。常用的桌面系统，都是分时操调度，根据线程的优先级来分配调度时间。我们可以定义线程的优先级，但是这并不能保证高优先级的线程会在低优先级的线程前执行。 10. 什么是线程调度器(Thread Scheduler)和时间分片(Time Slicing)？线程调度器是一个操作系统服务，它负责为Runnable状态的线程分配CPU时间。一旦我们创建一个线程并启动它，它的执行便依赖于线程调度器的实现。时间分片是指将可用的CPU时间分配给可用的Runnable线程的过程。分配CPU时间可以基于线程优先级或者线程等待的时间。线程调度并不受到Java虚拟机控制，所以由应用程序来控制它是更好的选择（也就是说不要让你的程序依赖于线程的优先级）。 11. 在多线程中，什么是上下文切换(context-switching)？上下文切换是存储和恢复CPU状态的过程，它使得线程执行能够从中断点恢复执行。上下文切换是多任务操作系统和多线程环境的基本特征。 12. 你如何确保main()方法所在的线程是Java程序最后结束的线程？我们可以使用Thread类的joint()方法来确保所有程序创建的线程在main()方法退出前结束。Read more… 线程实例的方法join()方法可以使得一个线程在另一个线程结束后再执行。如果join()方法在一个线程实例上调用，当前运行着的线程将阻塞直到这个线程实例完成了执行。在join()方法内设定超时，使得join()方法的影响在特定超时后无效。当超时时，主方法和任务线程申请运行的时候是平等的。然而，当涉及sleep时，join()方法依靠操作系统计时，所以你不应该假定join()方法将会等待你指定的时间。 13.线程之间是如何通信的？线程间通信有三种方式： a. 使用全局变量。进程中的线程间内存共享，这是比较常用的通信方式和交互方式。主要由于多个线程可能更改全局变量，因此全局变量最好声明为violate b. 使用消息实现通信。在Windows程序设计中，每一个线程都可以拥有自己的消息队列（UI线程默认自带消息队列和消息循环，工作线程需要手动实现消息循环），因此可以采用消息进行线程间通信sendMessage,postMessage。 1)定义消息#define WM_THREAD_SENDMSG=WM_USER+20; 2)添加消息函数声明afx_msg int OnTSendmsg();3)添加消息映射ON_MESSAGE(WM_THREAD_SENDMSG,OnTSM)4)添加OnTSM()的实现函数；5)在线程函数中添加PostMessage消息Post函数 c. 使用事件CEvent类实现线程间通信。Event对象有两种状态：有信号和无信号，线程可以监视处于有信号状态的事件，以便在适当的时候执行对事件的操作。 1)创建一个CEvent类的对象：CEvent threadStart;它默认处在未通信状态；2)threadStart.SetEvent();使其处于通信状态；3)调用WaitForSingleObject()来监视CEvent对象 当线程间是可以共享资源时，线程间通信是协调它们的重要的手段。Object类中wait()notify()notifyAll()方法可以用于线程间通信关于资源的锁的状态。Read more 14. 进程间通信方式及特点？进程是转入内存并准备执行的程序，每个程序都有私有的虚拟地址空间，由代码，数据以及它可利用的系统资源(如文件，管道)组成。多进程/多线程是windows操作系统的一个基本特征。Linux系统一般都统称为进程。 由于不同的进程运行在各自不同的内存空间中，其中一个进程对于变量的修改另一方是无法感知的，因此，进程之间的消息传递不能通过变量或其他数据结构直接进行，只能通过进程间通信来完成。进程间通信是指不同进程间进行数据共享和数据交换。 进程间通信方式：文件和记录锁定，管道，有名管道，FIFO，信号量，信号，消息队列，共享内存，套接字。[^14] Read Read Read… 15. 为什么线程通信的方法wait(), notify()和notifyAll()被定义在Object类里？Java的每个对象中都有一个锁(monitor，也可以成为监视器) 并且wait()，notify()等方法用于等待对象的锁或者通知其他线程对象的监视器可用。在Java的线程中并没有可供任何对象使用的锁和同步器。这就是为什么这些方法是Object类的一部分，这样Java的每一个类都有用于线程间通信的基本方法 16. 为什么wait(), notify()和notifyAll()必须在同步方法或者同步块中被调用？当一个线程需要调用对象的wait()方法的时候，这个线程必须拥有该对象的锁，接着它就会释放这个对象锁并进入等待状态直到其他线程调用这个对象上的notify()方法。同样的，当一个线程需要调用对象的notify()方法时，它会释放这个对象的锁，以便其他在等待的线程就可以得到这个对象锁。由于所有的这些方法都需要线程持有对象的锁，这样就只能通过同步来实现，所以他们只能在同步方法或者同步块中被调用。 17. 为什么Thread类的sleep()和yield()方法是静态的？Thread类的sleep()和yield()方法将在当前正在执行的线程上运行。所以在其他处于等待状态的线程上调用这些方法是没有意义的。这就是为什么这些方法是静态的。它们可以在当前正在执行的线程中工作，并避免程序员错误的认为可以在其他非运行线程调用这些方法。 18. 如何确保线程安全？在Java中可以有很多方法来保证线程安全——同步，使用原子类(atomic concurrent classes)，实现并发锁，使用volatile关键字，使用不变类和线程安全类。Read more 19. volatile关键字在Java中有什么作用？当我们使用volatile关键字去修饰变量的时候，所以线程都会直接读取该变量并且不缓存它。这就确保了线程读取到的变量是同内存中是一致的。 20. 同步方法和同步块，哪个是更好的选择？同步块是更好的选择，因为它不会锁住整个对象（当然你也可以让它锁住整个对象）。同步方法会锁住整个对象，哪怕这个类中有多个不相关联的同步块，这通常会导致他们停止执行并需要等待获得这个对象上的锁。 21. 如何创建守护线程？使用Thread类的setDaemon(true)方法可以将线程设置为守护线程，需要注意的是，需要在调用start()方法前调用这个方法，否则会抛出IllegalThreadStateException异常。 22. 什么是ThreadLocal?ThreadLocal用于创建线程的本地变量，我们知道一个对象的所有线程会共享它的全局变量，所以这些变量不是线程安全的，我们可以使用同步技术。但是当我们不想使用同步的时候，我们可以选择ThreadLocal变量。 每个线程都会拥有他们自己的Thread变量，它们可以使用get()set()方法去获取他们的默认值或者在线程内部改变他们的值。ThreadLocal实例通常是希望它们同线程状态关联起来是private static属性。Read more。 23. 什么是死锁(Deadlock)？如何避免死锁？死锁是指两个以上的线程永远阻塞的情况，这种情况产生至少需要两个以上的线程和两个以上的资源。死锁的四个必要条件： 互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用； 持有（Hold and wait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源； 不可剥夺（No preemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源； 环形等待（Circular wait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。 在系统中已经出现死锁后，应该及时检测到死锁的发生，并采取适当的措施来解除死锁。目前处理死锁的方法可归结为四种 24. 什么是线程池？如何创建一个Java线程池？一个线程池管理了一组工作线程，同时它还包括了一个用于放置等待执行的任务的队列。 java.util.concurrent.Executors提供了一个java.util.concurrent.Executor接口的实现用于创建线程池。如何创建和使用线程池 Java并发面试问题1. 什么是原子操作？在Java Concurrency API中有哪些原子类(atomic classes)？原子操作是指一个不受其他操作影响的操作任务单元。原子操作是在多线程环境下避免数据不一致必须的手段。 int++并不是一个原子操作，所以当一个线程读取它的值并加1时，另外一个线程有可能会读到之前的值，这就会引发错误。 为了解决这个问题，必须保证增加操作是原子的，在JDK1.5之前我们可以使用同步技术来做到这一点。到JDK1.5，java.util.concurrent.atomic包提供了int和long类型的装类，它们可以自动的保证对于他们的操作是原子的并且不需要使用同步。Read more。 2. Java Concurrency API中的Lock接口(Lock interface)是什么？对比同步它有什么优势？Lock接口比同步方法和同步块提供了更具扩展性的锁操作。他们允许更灵活的结构，可以具有完全不同的性质，并且可以支持多个相关类的条件对象。它的优势有： 可以使锁更公平 可以使线程在等待锁的时候响应中断 可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间 可以在不同的范围，以不同的顺序获取和释放锁 3. 什么是Executors框架？Executor框架同java.util.concurrent.Executor 接口在Java5中被引入。Executor框架是一个根据一组执行策略调用，调度，执行和控制的异步任务的框架。 无限制的创建线程会引起应用程序内存溢出。所以创建一个线程池是个更好的的解决方案，因为可以限制线程的数量并且可以回收再利用这些线程。利用Executors框架可以非常方便的创建一个线程池。Read more 4. 什么是阻塞队列？如何使用阻塞队列来实现生产者-消费者模型？java.util.concurrent.BlockingQueue的特性是：当队列是空的时，从队列中获取或删除元素的操作将会被阻塞，或者当队列是满时，往队列里添加元素的操作会被阻塞。 阻塞队列不接受空值，当你尝试向队列中添加空值的时候，它会抛出NullPointerException。 阻塞队列的实现都是线程安全的，所有的查询方法都是原子的并且使用了内部锁或者其他形式的并发控制。 BlockingQueue接口是java collections框架的一部分，它主要用于实现生产者-消费者问题。使用阻塞队列实现生产者-消费者问题。 5. 什么是并发容器的实现？Java集合类都是快速失败的，这就意味着当集合被改变且一个线程在使用迭代器遍历集合的时候，迭代器的next()方法将抛出ConcurrentModificationException异常。 并发容器支持并发的遍历和并发的更新。 主要的类有ConcurrentHashMap, CopyOnWriteArrayList 和CopyOnWriteArraySet。 如何在for循环中移除某些元素呢？，可以使用倒序遍历或者正序遍历移除同时修改i的值，或者使用Iterator的remove()方法。具体可以看这篇文章：https://www.cnblogs.com/zwwhnly/p/12530819.html 6. Executors类是什么？Executors为Executor，ExecutorService，ScheduledExecutorService，ThreadFactory和Callable类提供了一些工具方法。 Executors可以用于方便的创建线程池。 好文推荐秒杀多线程面试题系列进程通信方式及特点 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2015/03/16/java-multithreading-concurrent/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"Java","slug":"java","permalink":"http://agehua.github.io/tags/java/"},{"name":"multi-thread","slug":"multi-thread","permalink":"http://agehua.github.io/tags/multi-thread/"},{"name":"Interview","slug":"interview","permalink":"http://agehua.github.io/tags/interview/"}]},{"title":"Android优秀开源项目【持续更新】","slug":"android-open-sources","date":"2015-01-26T16:00:00.000Z","updated":"2024-12-05T09:41:56.279Z","comments":true,"path":"2015/01/27/android-open-sources/","link":"","permalink":"http://agehua.github.io/2015/01/27/android-open-sources/","excerpt":"一直想找些Android经典的开源项目学习一下，大健发现了这么一篇帖子，不少好东西，分享在此。希望能够对Android开发的同学有所帮助。感谢作者的整理和分享。tisa007原帖在这里。\n项目篇：\nApollo音乐播放器：就一个播放器，但是实现的很好\noschina客户端：oschina网站的客户端哦，wp版，iOS版都有开源\nxabber实时聊天工具（基于xmpp协议）：不评价了，反正算是同类中比较好的了\n四次元新浪微博客户端：今天才知道是开源的，赶紧收藏\nGoogle IO：谷歌开发者大会应用，虽然有点难懂，还是很有参考价值（比如其中的图片加载）\neoe客户端：eoe网站Android客户端也开源咯，嘿嘿\n","text":"一直想找些Android经典的开源项目学习一下，大健发现了这么一篇帖子，不少好东西，分享在此。希望能够对Android开发的同学有所帮助。感谢作者的整理和分享。tisa007原帖在这里。 项目篇： Apollo音乐播放器：就一个播放器，但是实现的很好 oschina客户端：oschina网站的客户端哦，wp版，iOS版都有开源 xabber实时聊天工具（基于xmpp协议）：不评价了，反正算是同类中比较好的了 四次元新浪微博客户端：今天才知道是开源的，赶紧收藏 Google IO：谷歌开发者大会应用，虽然有点难懂，还是很有参考价值（比如其中的图片加载） eoe客户端：eoe网站Android客户端也开源咯，嘿嘿 软件篇： Android-Flip：可以实现类似FlipBoard那种华丽丽的翻页 Drag-Sort-Listview：可以拖动item重新排序的listview，效果非常赞 HoloEveryWhere：咳咳，有些同学非常喜欢Android的holo风格，这个项目绝对让你happy Universal-ImageLoader：这个经典的异步图片加载，不多说了 JazzyViewPager：这玩意可以让ViewPager翻起来更酷，谁用谁知道~~ SlidingMenu：这个是抽屉界面（就是facebook那种）的各种实现版本中，最好的，木有之一！ StickyListHeaders：iPhone上经常有这个，就是listview的……不知道怎么解释，自己下载看看吧 Android-PullToRefresh：下拉刷新，挺常用的一个组件 StaggeredGridView：这是一个瀑布流布局的实现，还不是很完善，但作为学习的案例或者在其基础上扩展还是不错的 android-async-http：android的异步请求组件，我个人习惯使用asynctask，不过这个实现还是很优秀的，也推荐给大家 ActionBarSherlock：大家熟知的ActionBar在2.x上的兼容性方案；类似的兼容性组件还有许多，有时间为大家一一列出； facebook-android-sdk：不止是一个SDK那么简单哦，比某浪和某人的SDK强几个数量级； NineOldAndroids：想在2.xSDK上使用Android 3.0新增的动画API，那就是它了；没用过的同学一定要试试哦，非常方便~ android-swipelistview：让listview的item可以向右滑动，新版Gmail和Pocket里面有用到哦~ DataDroid：Android的RESTful封装，没听过RESTful？你去死吧 EventBus：和上面的DataDroid同样属于美化底层代码的，这个lib简化了不同组件之间的事件传递 android-switch-backport：Android3.0以上才有的switch，有好心人给迁移到2.x上了，哈 PagerSlidingTabStrip：最新版的GooglePlay的那个tab效果，可炫可炫了 chromeview：我们都知道webview，也知道Android的chrome又自己的内核，这个项目就是把chrome的内核给导出来做成一个chromeview了，大家可以在自己的项目里用，有兴趣的可以玩玩 picasso：来自square的图片异步加载，好像是最近才开源的，API风格很独特，哥很喜欢~ 顺便推荐大家几个网站： github：各种项目很多，就是不容易挖掘，但是开发者必备 oschina：曾经一般，现在越做越好了，很多开源项目； eoeandroid：经过一番整理，现在非常强大；小作品居多； AndroidViews：我曾经想做这么一个网站来着，很多开源组件的集合，嘿嘿 vogella:国外的一个教程网站，不是逗小孩玩的那种哦~ 大家都说github上面的项目不容易发现，但其实还是有办法的，比如：关注java项目排名：大家戳 这个网址搜索“Android”，并按star排序：戳 这里 直达最后，还有一招，就是关注些牛人，他们通常会关注或fork一些很有水平的项目。 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2015/01/27/android-open-sources/","raw":null,"content":null,"categories":[{"name":"accumulation","slug":"accumulation","permalink":"http://agehua.github.io/categories/accumulation/"}],"tags":[{"name":"ANDROID","slug":"android","permalink":"http://agehua.github.io/tags/android/"},{"name":"Open souces","slug":"open-souces","permalink":"http://agehua.github.io/tags/open-souces/"}]},{"title":"Hello World","slug":"hello-world","date":"2014-12-22T16:00:00.000Z","updated":"2023-11-16T03:42:40.823Z","comments":true,"path":"2014/12/23/hello-world/","link":"","permalink":"http://agehua.github.io/2014/12/23/hello-world/","excerpt":"Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.\nQuick StartCreate a new post$ hexo new \"My New Post\"\nMore info: Writing\nRun server$ hexo server","text":"Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post$ hexo new \"My New Post\" More info: Writing Run server$ hexo server More info: Server Generate static files$ hexo generate More info: Generating Deploy to remote sites$ hexo deploy More info: Deployment 本文采用知识共享署名 2.5 中国大陆许可协议进行许可，欢迎转载，但转载请注明来自Agehua’s Blog，并保持转载后文章内容的完整。本人保留所有版权相关权利。 本文链接：http://agehua.github.io/2014/12/23/hello-world/","raw":null,"content":null,"categories":[],"tags":[]}]}
\ No newline at end of file
diff --git a/index.html b/index.html
index 5d8b493ce..b658ff649 100644
--- a/index.html
+++ b/index.html
@@ -537,14 +537,15 @@ <h1 itemprop="name">
     </div>
 
 
-                        <div style="color:#cba11f;float:right">2 min read , Words: 352</div>                    </div>
+                        <div style="color:#cba11f;float:right">5 min read , Words: 909</div>                    </div>
                 
             </header>
         
         
         <div class="article-entry" itemprop="articleBody">
         
-            <p><h2 id="Battery-Canary"><a href="#Battery-Canary" class="headerlink" title="Battery-Canary"></a>Battery-Canary</h2><p>BatteryCanary 最核心的功能是通过监控线程异常来定位 App 的耗电 Bug，主要包括线程电量统计、堆栈信息和线程池问题细分等.</p></p>
+            <p><p>App耗电问题是一个影响用户体验，甚至影响app使用率的一个重要的性能问题。相比Crash、Anr，耗电排查是一个需要综合各种因素来最终确定问题所在的复杂流程。同时又因为耗电受影响的范围大、不同手机衡量标准又不太统一导致该问题一直是一个令人头痛的疑难杂症。</p>
+<p>本文通过介绍耗电基本知识和 Matrix Battery的基本使用，来总结下面对耗电问题应该如何排查和定位</p></p>
             <p class="article-more-link">
                 <a href="/2024/12/04/matrix-battery-canary-introducation/#more">Read More</a>
             </p>
@@ -560,7 +561,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/" data-id="cm4b8fqms0083d54734ob7sn8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/" data-id="cm4cl3h8w007ssl47gys04u9n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -716,7 +717,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/" data-id="cm4b8fqms0080d54794sbeejo" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/" data-id="cm4cl3h8x007wsl47qxxewlq6" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -878,7 +879,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2024/04/24/jacoco-test-coverage/" data-id="cm4b8fqmr007xd5479k6grv2n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2024/04/24/jacoco-test-coverage/" data-id="cm4cl3h8v007nsl4709bmc3vo" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1034,7 +1035,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/" data-id="cm4b8fqmk007kd547seqc7rbd" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/" data-id="cm4cl3h8w007qsl47ppmitgct" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1190,7 +1191,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/11/02/native-crash-principle/" data-id="cm4b8fqmn007ud547hy079ciz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/11/02/native-crash-principle/" data-id="cm4cl3h8v007gsl47pzdaouge" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1347,7 +1348,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/10/26/cross-process-bridge/" data-id="cm4b8fqml007nd5476h7lldrt" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/10/26/cross-process-bridge/" data-id="cm4cl3h8u007dsl47ap7qxf0o" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1503,7 +1504,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/09/26/matrix-trace-canary/" data-id="cm4b8fqml007rd547k48ny3y3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/09/26/matrix-trace-canary/" data-id="cm4cl3h8v007jsl47ev4v7e30" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1659,7 +1660,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2023/02/10/constraintlayout-intro/" data-id="cm4b8fqmk007hd547f6jz7u8l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2023/02/10/constraintlayout-intro/" data-id="cm4cl3h8t0078sl47s7quwybz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/10/index.html b/page/10/index.html
index b7fe3a554..50b47cb94 100644
--- a/page/10/index.html
+++ b/page/10/index.html
@@ -570,7 +570,7 @@ <h3 id="需求场景"><a href="#需求场景" class="headerlink" title="需求
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/10/13/gradle-learning2/" data-id="cm4b8fqk40026d547r09s4v0g" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/10/13/gradle-learning2/" data-id="cm4cl3h5z001osl47uxpi6omg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -729,7 +729,7 @@ <h3 id="Gradle的基本组成"><a href="#Gradle的基本组成" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/10/12/gradle-learning/" data-id="cm4b8fqk1001sd547rfckzlay" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/10/12/gradle-learning/" data-id="cm4cl3h5y001ksl473i9m18zl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -889,7 +889,7 @@ <h4 id="1-Android事件传递机制"><a href="#1-Android事件传递机制" clas
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/28/Android-interview-questions/" data-id="cm4b8fqk2001wd547iigxoyto" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/28/Android-interview-questions/" data-id="cm4cl3h61001wsl47w1qu5q7n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1056,7 +1056,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/22/quit-whole-application/" data-id="cm4b8fqjr001cd547fsfs3xgl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/22/quit-whole-application/" data-id="cm4cl3h5u0018sl47psa8r85n" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1214,7 +1214,7 @@ <h3 id="2-JNI获取Publickey实现"><a href="#2-JNI获取Publickey实现" class=
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/22/JNI-get-publickey/" data-id="cm4b8fqjs001fd547zyfvtvnb" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/22/JNI-get-publickey/" data-id="cm4cl3h5z001rsl47ksfo851y" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1372,7 +1372,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/20/AVG-unwanted-software/" data-id="cm4b8fqjp0012d547grsro2xc" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/20/AVG-unwanted-software/" data-id="cm4cl3h5t0015sl47w8g73c8l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1529,7 +1529,7 @@ <h3 id="常用单例模式"><a href="#常用单例模式" class="headerlink" tit
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/20/android-design-pattern-singleton/" data-id="cm4b8fqjr0019d547sdq9ph8p" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/20/android-design-pattern-singleton/" data-id="cm4cl3h5x001esl47yomn6qzh" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1687,7 +1687,7 @@ <h3 id="2-ThreadLocal"><a href="#2-ThreadLocal" class="headerlink" title="2.Thre
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/" data-id="cm4b8fqjq0015d5471epragt4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/" data-id="cm4cl3h5y001hsl47ks1qnwln" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/11/index.html b/page/11/index.html
index 9e46a084b..83e8d2d0e 100644
--- a/page/11/index.html
+++ b/page/11/index.html
@@ -562,7 +562,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/08/16/RxAndroid-Learning/" data-id="cm4b8fqju001id547j37ee0m8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/08/16/RxAndroid-Learning/" data-id="cm4cl3h5w001csl47l87a7m0y" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -718,7 +718,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/08/03/android-LocationListener/" data-id="cm4b8fqjo000vd547ow5yrm1x" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/08/03/android-LocationListener/" data-id="cm4cl3h5s000ysl4714gvwiac" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -881,7 +881,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/07/25/android-webview-summary/" data-id="cm4b8fqjo000xd547wbfvahp2" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/07/25/android-webview-summary/" data-id="cm4cl3h5t0011sl47wzibx7v3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1041,7 +1041,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/06/08/gson-summary/" data-id="cm4b8fqjn000td547l819prag" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/06/08/gson-summary/" data-id="cm4cl3h5r000rsl47gskjvvmq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1199,7 +1199,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/28/qiniu-android-summary/" data-id="cm4b8fqjw001pd5473h58m9yy" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/28/qiniu-android-summary/" data-id="cm4cl3h5r000vsl4743q1wqeu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1368,7 +1368,7 @@ <h3 id="1-JNI介绍"><a href="#1-JNI介绍" class="headerlink" title="1.JNI介
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning/" data-id="cm4b8fqjl000kd547ba7whzux" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning/" data-id="cm4cl3h5p000ksl4770975p17" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1524,7 +1524,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning0/" data-id="cm4b8fqjv001md547ogp7tlc1" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/24/JNI-Learning0/" data-id="cm4cl3h5q000osl47u2tvsy2y" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1681,7 +1681,7 @@ <h3 id="1，“字符”是由数字来表示的"><a href="#1，“字符”是
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/18/javaString-and-bytes/" data-id="cm4b8fqjl000hd547tup28n1z" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/18/javaString-and-bytes/" data-id="cm4cl3h5o000isl472gxizxpw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/12/index.html b/page/12/index.html
index 5767c08c9..df051fc99 100644
--- a/page/12/index.html
+++ b/page/12/index.html
@@ -564,7 +564,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/05/12/GCM-Azure_summary/" data-id="cm4b8fqjn000qd547q24lluw5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/05/12/GCM-Azure_summary/" data-id="cm4cl3h5h000dsl4796rdo9bf" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -727,7 +727,7 @@ <h4 id="1-1-Activity生命周期全面分析"><a href="#1-1-Activity生命周期
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/20/android-books-reading-/" data-id="cm4b8fqjj000dd547h1edrzk9" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/20/android-books-reading-/" data-id="cm4cl3h5d000asl4752zsri1l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -884,7 +884,7 @@ <h3 id="二、setTranslucentStatus-方法"><a href="#二、setTranslucentStatus-
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/20/android-new-knowledge-summary/" data-id="cm4b8fqjm000od5470r3xyolq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/20/android-new-knowledge-summary/" data-id="cm4cl3h5k000esl47vcwzks80" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1043,7 +1043,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/15/facebook-google+signin/" data-id="cm4b8fqjc0009d547t8w3y3me" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/15/facebook-google+signin/" data-id="cm4cl3h5c0008sl478q4jr9sw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1202,7 +1202,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/03/01/android-googlemap-summary/" data-id="cm4b8fqjg000cd547ayhuj658" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/03/01/android-googlemap-summary/" data-id="cm4cl3h8x007zsl47mwtwixh0" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1448,7 +1448,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2015/11/06/book-list-of-2015/" data-id="cm4b8fqj70006d547ues8fxny" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2015/11/06/book-list-of-2015/" data-id="cm4cl3h5c0009sl47bsjk75mr" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1607,7 +1607,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2015/03/16/java-multithreading-concurrent/" data-id="cm4b8fqj30002d547niqaox8t" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2015/03/16/java-multithreading-concurrent/" data-id="cm4cl3h560002sl470grxrzp7" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1771,7 +1771,7 @@ <h3 id="项目篇："><a href="#项目篇：" class="headerlink" title="项目
 
 </div>
 
-    <a data-url="http://agehua.github.io/2015/01/27/android-open-sources/" data-id="cm4b8fqiw0000d547wkbe3kyh" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2015/01/27/android-open-sources/" data-id="cm4cl3h590004sl47wc24ubi3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/13/index.html b/page/13/index.html
index f5f48c573..5204a50ae 100644
--- a/page/13/index.html
+++ b/page/13/index.html
@@ -543,7 +543,7 @@ <h3 id="Run-server"><a href="#Run-server" class="headerlink" title="Run server">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2014/12/23/hello-world/" data-id="cm4b8fqj90008d547ilryjv84" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2014/12/23/hello-world/" data-id="cm4cl3h4z0000sl47vk8znx1u" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/2/index.html b/page/2/index.html
index 93471aa96..ec610ab8d 100644
--- a/page/2/index.html
+++ b/page/2/index.html
@@ -560,7 +560,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/08/08/anr-trigger-principle/" data-id="cm4b8fqmh0073d547w0yycmcp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/08/08/anr-trigger-principle/" data-id="cm4cl3h8i006zsl470vu1l6vu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -716,7 +716,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/07/21/async-inflate-strategy/" data-id="cm4b8fqmj007fd547dptgc4yk" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/07/21/async-inflate-strategy/" data-id="cm4cl3h8t0075sl471m6iawy6" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -872,7 +872,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/03/28/sp-source-code-analysis/" data-id="cm4b8fqmi0078d5473p6k9es8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/03/28/sp-source-code-analysis/" data-id="cm4cl3h8t007bsl47o4etqsnv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1032,7 +1032,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/02/13/Java-summary/" data-id="cm4b8fqq800e6d547upzci25b" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/02/13/Java-summary/" data-id="cm4cl3hc100ecsl47uf1q4ncl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1188,7 +1188,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2022/02/10/android-binder-principle3/" data-id="cm4b8fqmd006od547owl17836" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2022/02/10/android-binder-principle3/" data-id="cm4cl3h7z006hsl47l8hmljpl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1345,7 +1345,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/12/14/AOP-android/" data-id="cm4b8fqmh0070d547mk53moai" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/12/14/AOP-android/" data-id="cm4cl3h8a006ssl4715x5740z" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1502,7 +1502,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/08/07/view-scroll-apis/" data-id="cm4b8fqme006rd5473fyzazcz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/08/07/view-scroll-apis/" data-id="cm4cl3h7z006msl47tcb5bgob" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1658,7 +1658,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/07/18/gradle-plugin/" data-id="cm4b8fqmg006yd5476nqy64sq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/07/18/gradle-plugin/" data-id="cm4cl3h7x006bsl47s4smrsxa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/3/index.html b/page/3/index.html
index 8d2d3936b..957064e62 100644
--- a/page/3/index.html
+++ b/page/3/index.html
@@ -564,7 +564,7 @@ <h3 id="由问题引入"><a href="#由问题引入" class="headerlink" title="
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/07/18/recyclerview-cache/" data-id="cm4b8fqmi0075d547rsf6a0yq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/07/18/recyclerview-cache/" data-id="cm4cl3h8g006vsl47ruksg52t" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -721,7 +721,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/06/07/ANR-summary/" data-id="cm4b8fqmj007bd547kdwof81l" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/06/07/ANR-summary/" data-id="cm4cl3h8q0072sl47hbtnvvl8" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -877,7 +877,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/" data-id="cm4b8fqmb006cd5473rfg8aej" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2021/04/19/Android-PIP-Hack-summary/" data-id="cm4cl3h7q0065sl47f5lgmxku" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1033,7 +1033,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/" data-id="cm4b8fqmb006ed547wdo788py" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/12/04/RecyclerView_scroll_relatedapi/" data-id="cm4cl3h80006osl47m733ac0c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1190,7 +1190,7 @@ <h3 id="Kotlin-解决了一些-Java-中的问题"><a href="#Kotlin-解决了一
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&Java/" data-id="cm4b8fqmc006hd547dtzcc4zs" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/10/26/Diffrence-between-kotlin&Java/" data-id="cm4cl3h7z006ksl4758xrov3x" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1348,7 +1348,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/09/07/Kotlin-DSL/" data-id="cm4b8fqmc006kd5479r3qfssp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/09/07/Kotlin-DSL/" data-id="cm4cl3h7n0062sl47y1s21u4d" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1505,7 +1505,7 @@ <h3 id="线程独占区"><a href="#线程独占区" class="headerlink" title="
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/08/31/JVM-stack-and_heap/" data-id="cm4b8fqmg006vd547q8g2w7nl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/08/31/JVM-stack-and_heap/" data-id="cm4cl3h7t0068sl470nhdd8sa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1661,7 +1661,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/07/10/profile_analysis/" data-id="cm4b8fqlv005yd5473bt3h7u2" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/07/10/profile_analysis/" data-id="cm4cl3h7h005tsl478pozkokm" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/4/index.html b/page/4/index.html
index 619966f2a..3d3cb56bc 100644
--- a/page/4/index.html
+++ b/page/4/index.html
@@ -565,7 +565,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2020/05/26/download-function-analysis/" data-id="cm4b8fqm60069d547xzz1vqql" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2020/05/26/download-function-analysis/" data-id="cm4cl3h7h005wsl474u5k1lzg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -722,7 +722,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/12/09/Android-Measure/" data-id="cm4b8fqlv0060d547nehrtrym" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/12/09/Android-Measure/" data-id="cm4cl3h7g005msl47qcu1v6yn" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -883,7 +883,7 @@ <h3 id="原码反码补码的概念"><a href="#原码反码补码的概念" clas
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/12/08/Android-bits-operation/" data-id="cm4b8fqlu005ud5475vvms6jg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/12/08/Android-bits-operation/" data-id="cm4cl3h7e005fsl47c2wj8c8u" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1039,7 +1039,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/09/12/Horizontal-Coordinator/" data-id="cm4b8fqlw0066d5476rl7kfd5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/09/12/Horizontal-Coordinator/" data-id="cm4cl3h7g005psl47qbq9jy9f" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1196,7 +1196,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/07/30/LeakCanary_source_code/" data-id="cm4b8fqlw0062d547rqhgfkls" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/07/30/LeakCanary_source_code/" data-id="cm4cl3h7f005isl47ft6mqb6b" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1357,7 +1357,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/" data-id="cm4b8fqlu005rd547e10qaqnz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/07/17/RecyclerView-pre-initiate/" data-id="cm4cl3h780051sl47fpdoywfu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1515,7 +1515,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/05/31/RecyclerView-source-code/" data-id="cm4b8fqq400e3d547u9bgjv7g" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/05/31/RecyclerView-source-code/" data-id="cm4cl3hc300eesl47458hzreu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1673,7 +1673,7 @@ <h3 id="Recyclerview-源码中用到的设计模式"><a href="#Recyclerview-源
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/" data-id="cm4b8fqlp005ed547xep7ru8m" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/" data-id="cm4cl3h7i005ysl47uz7lkny4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/5/index.html b/page/5/index.html
index 7d6bf51bf..f2e6c73fa 100644
--- a/page/5/index.html
+++ b/page/5/index.html
@@ -563,7 +563,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/" data-id="cm4b8fqlq005hd547rgztc9gx" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/05/27/TCP-Three-way-Handshake/" data-id="cm4cl3h7e005bsl472gvpk7so" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -719,7 +719,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/" data-id="cm4b8fqlt005od54790k5liim" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/" data-id="cm4cl3h790058sl47htcpro7f" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -880,7 +880,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2019/01/26/Android-request-memory-leaks/" data-id="cm4b8fql3004sd547mpub5nps" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2019/01/26/Android-request-memory-leaks/" data-id="cm4cl3h77004rsl47y4q0pyxa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1045,7 +1045,7 @@ <h3 id="录音基础知识"><a href="#录音基础知识" class="headerlink" tit
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/12/06/Android-audio-introduction/" data-id="cm4b8fqls005ld547183zaeoq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/12/06/Android-audio-introduction/" data-id="cm4cl3h77004usl47s069zfzl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1202,7 +1202,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/" data-id="cm4b8fqll005ad547r633j2gh" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/08/22/Handler-Looper-MessageQueue/" data-id="cm4cl3h7y006fsl47z74wuww3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1348,7 +1348,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/" data-id="cm4b8fqlk0057d547twbogql5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/06/26/Toastmaster-md-introduction/" data-id="cm4cl3h76004osl470o4mw3fl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1506,7 +1506,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/" data-id="cm4b8fqld0052d5471i12pkfu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/" data-id="cm4cl3h78004ysl473fg2rmzv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1663,7 +1663,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/04/23/Usage-of-genericity/" data-id="cm4b8fqks004jd54752zv31dz" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/04/23/Usage-of-genericity/" data-id="cm4cl3h700049sl47zf2qqg96" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/6/index.html b/page/6/index.html
index 738152640..e07b39a54 100644
--- a/page/6/index.html
+++ b/page/6/index.html
@@ -550,7 +550,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/" data-id="cm4b8fqkr004cd5475aimkp41" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/04/02/Toastmaster-two-drawbacks/" data-id="cm4cl3h74004hsl47au425tey" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -706,7 +706,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/03/14/IntentService-AsyncTask/" data-id="cm4b8fql5004wd547e88ygujp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/03/14/IntentService-AsyncTask/" data-id="cm4cl3h75004ksl47vcbq9q3r" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -865,7 +865,7 @@ <h3 id="1-android事件分发机制，请详细说下整个流程"><a href="#1-a
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/" data-id="cm4b8fqkx004qd547c5ixnu8e" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/" data-id="cm4cl3h790054sl47thozusaw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1024,7 +1024,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/02/24/Mac-terminal-command/" data-id="cm4b8fql9004zd547mrzm3uph" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/02/24/Mac-terminal-command/" data-id="cm4cl3h700046sl47bgqluczw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1170,7 +1170,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/" data-id="cm4b8fqkp0041d547wdmftbuv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2018/01/08/Toastmaster-self-introduction/" data-id="cm4cl3h6y003ysl47hlsdugkq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1327,7 +1327,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/12/02/Python-knowledge/" data-id="cm4b8fqkv004md5473dydpmyg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/12/02/Python-knowledge/" data-id="cm4cl3h6z0042sl47cg7n1u7c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1484,7 +1484,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/" data-id="cm4b8fqkp0044d547a43w7wbg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/10/22/Buildcross-platform-desktop-apps/" data-id="cm4cl3h6r003msl47m2u7gh0w" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1645,7 +1645,7 @@ <h3 id="for-…-of循环介绍"><a href="#for-…-of循环介绍" class="headerl
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/10/22/JavaScript-knowledge/" data-id="cm4b8fqkq0048d547hbovp8th" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/10/22/JavaScript-knowledge/" data-id="cm4cl3h71004dsl47qd1r04a4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/7/index.html b/page/7/index.html
index 2129d346d..164ce6f88 100644
--- a/page/7/index.html
+++ b/page/7/index.html
@@ -562,7 +562,7 @@ <h4 id="发出初始化消费-INITIALIZE-FOR-PURCHASE-命令"><a href="#发出
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/" data-id="cm4b8fqkl003qd5477wsac0s0" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/09/21/PBOCKonwledgeCode/" data-id="cm4cl3h6s003qsl47256r7kwa" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -722,7 +722,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/09/12/PBOCKonwledge/" data-id="cm4b8fqko003xd547h2upkgg4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/09/12/PBOCKonwledge/" data-id="cm4cl3h6n003jsl47xj8jsmcw" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -880,7 +880,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/08/17/IntervieweeQuestions/" data-id="cm4b8fqkf003cd547uwo69ur6" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/08/17/IntervieweeQuestions/" data-id="cm4cl3h6u003vsl47wjle5046" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1045,7 +1045,7 @@ <h3 id="主要对象功能介绍"><a href="#主要对象功能介绍" class="hea
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/08/02/activity-start-process/" data-id="cm4b8fqkg003gd547wjyeqaum" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/08/02/activity-start-process/" data-id="cm4cl3h6t003ssl47o3nz12fd" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1203,7 +1203,7 @@ <h3 id="搭建编译环境"><a href="#搭建编译环境" class="headerlink" tit
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/08/01/aosp-compile/" data-id="cm4b8fqkh003jd547ixh9mqum" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/08/01/aosp-compile/" data-id="cm4cl3h6k003csl472n3lqte0" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1364,7 +1364,7 @@ <h3 id="Android免root实现hook系统服务拦截方法"><a href="#Android免ro
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/07/12/android-noroot-hook/" data-id="cm4b8fqkr004fd547tg27dybu" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/07/12/android-noroot-hook/" data-id="cm4cl3h6j0036sl47uysijtd1" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1527,7 +1527,7 @@ <h3 id="服务大管家ServiceManager"><a href="#服务大管家ServiceManager"
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/07/10/android-binder-principle2/" data-id="cm4b8fqki003nd547jhxjwh09" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/07/10/android-binder-principle2/" data-id="cm4cl3h6k003fsl475v2rli94" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1688,7 +1688,7 @@ <h3 id="Android中远程服务调用分析"><a href="#Android中远程服务调
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/07/08/android-binder-principle/" data-id="cm4b8fqke0038d547lvbc9hrv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/07/08/android-binder-principle/" data-id="cm4cl3h6h0034sl47dvwqzkae" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/8/index.html b/page/8/index.html
index d4ee2def2..b2674bc10 100644
--- a/page/8/index.html
+++ b/page/8/index.html
@@ -563,7 +563,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/05/18/handler-replace-timertask/" data-id="cm4b8fqkc002yd54792km399j" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/05/18/handler-replace-timertask/" data-id="cm4cl3h6c002qsl47ru8dgp6c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -722,7 +722,7 @@ <h3 id="卡榫函数"><a href="#卡榫函数" class="headerlink" title="卡榫
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/05/11/Object-Oriented/" data-id="cm4b8fqkd0035d547gu9bd9xm" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/05/11/Object-Oriented/" data-id="cm4cl3h6j0038sl473j5x058p" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -881,7 +881,7 @@ <h3 id="Andorid中的应用"><a href="#Andorid中的应用" class="headerlink" t
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/04/10/Annotation-Android-usage/" data-id="cm4b8fqkm003ud5478fo522a5" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/04/10/Annotation-Android-usage/" data-id="cm4cl3h6e0030sl47uix94j01" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1040,7 +1040,7 @@ <h4 id="第三步：创建版本库"><a href="#第三步：创建版本库" clas
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/03/20/SVN-server-linux/" data-id="cm4b8fqk9002jd54729ll958c" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/03/20/SVN-server-linux/" data-id="cm4cl3h6a002lsl4723jke4ln" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1199,7 +1199,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/" data-id="cm4b8fqkf003ad547wznvr6lj" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/" data-id="cm4cl3h6b002nsl47hj7p1c4d" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1360,7 +1360,7 @@ <h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/03/09/Https-Questions/" data-id="cm4b8fqkb002vd54784imqowl" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/03/09/Https-Questions/" data-id="cm4cl3h6a002isl47ham6tkpq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1522,7 +1522,7 @@ <h3 id="解决Application的onCreate方法多次调用"><a href="#解决Applicat
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/" data-id="cm4b8fqkd0032d5473wwgg3xv" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/02/21/Multi-Process-Dispatch/" data-id="cm4cl3h6d002tsl478a65864o" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1684,7 +1684,7 @@ <h3 id="SCP命令使用说明"><a href="#SCP命令使用说明" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/02/12/iterm2-to-linux/" data-id="cm4b8fqkb002rd547j09y5zg7" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/02/12/iterm2-to-linux/" data-id="cm4cl3h6e002xsl47h75jnala" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/page/9/index.html b/page/9/index.html
index 3006ecc5f..f732254a7 100644
--- a/page/9/index.html
+++ b/page/9/index.html
@@ -560,7 +560,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2017/01/13/abroad-IM-service-company/" data-id="cm4b8fqka002pd547nyk673jp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2017/01/13/abroad-IM-service-company/" data-id="cm4cl3h660029sl470xncvxof" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -718,7 +718,7 @@ <h3 id="增量更新的流程"><a href="#增量更新的流程" class="headerlin
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/20/Android-patch-update/" data-id="cm4b8fqka002md547pylpxkxt" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/20/Android-patch-update/" data-id="cm4cl3h650026sl47i9kdq5q4" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -882,7 +882,7 @@ <h3 id="前言"><a href="#前言" class="headerlink" title="前言"></a>前言</
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/11/ThreadLocal-usage/" data-id="cm4b8fqk8002dd547ef878n0g" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/11/ThreadLocal-usage/" data-id="cm4cl3h69002gsl47tql5sneg" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1046,7 +1046,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/06/hexo-learning1/" data-id="cm4b8fqk2001zd547ltiu62gp" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/06/hexo-learning1/" data-id="cm4cl3h630022sl47dxgtx3vn" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1204,7 +1204,7 @@ <h4 id="3、-lt-code-gt-会对code进行html转义；"><a href="#3、-lt-code-gt
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/04/hexo-learning0/" data-id="cm4b8fqk30023d547899vm599" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/04/hexo-learning0/" data-id="cm4cl3h66002csl47ziowaiwf" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1366,7 +1366,7 @@ <h3 id="服务端JavaScript"><a href="#服务端JavaScript" class="headerlink" t
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/" data-id="cm4b8fqq700e4d5474n9nqyfq" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/" data-id="cm4cl3hbw00ebsl47ls5zd8ri" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1526,7 +1526,7 @@ <h3 id="1-先解释下泛型概念"><a href="#1-先解释下泛型概念" class=
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/" data-id="cm4b8fqk8002gd54752pxmjc1" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/11/21/Difference_between-T-E-K-V/" data-id="cm4cl3h61001zsl47r5pkt0hn" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
@@ -1682,7 +1682,7 @@ <h1 itemprop="name">
 
 </div>
 
-    <a data-url="http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/" data-id="cm4b8fqk6002ad547vj33spfj" class="article-share-link"><i class="fa fa-share"></i>Share</a>
+    <a data-url="http://agehua.github.io/2016/11/03/hexo-mac-module-not-found/" data-id="cm4cl3h60001usl47my906ls3" class="article-share-link"><i class="fa fa-share"></i>Share</a>
 <script>
     (function ($) {
         // Prevent duplicate binding
diff --git a/sitemap.xml b/sitemap.xml
index 7b185bb3c..f88b24da5 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,16 +2,16 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   
   <url>
-    <loc>http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/</loc>
+    <loc>http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/</loc>
     
-    <lastmod>2024-12-05T09:48:36.850Z</lastmod>
+    <lastmod>2024-12-06T10:06:32.072Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2024/12/04/matrix-battery-canary-introducation/</loc>
+    <loc>http://agehua.github.io/2024/11/22/matrix-io-canary-introducation/</loc>
     
-    <lastmod>2024-12-05T09:46:33.303Z</lastmod>
+    <lastmod>2024-12-05T09:48:36.850Z</lastmod>
     
   </url>
   
@@ -65,14 +65,14 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/12/06/hexo-learning1/</loc>
+    <loc>http://agehua.github.io/2016/10/13/gradle-learning2/</loc>
     
     <lastmod>2024-12-05T09:41:56.282Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/10/13/gradle-learning2/</loc>
+    <loc>http://agehua.github.io/2016/12/06/hexo-learning1/</loc>
     
     <lastmod>2024-12-05T09:41:56.282Z</lastmod>
     
@@ -114,35 +114,35 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/09/20/AVG-unwanted-software/</loc>
+    <loc>http://agehua.github.io/2016/05/28/qiniu-android-summary/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/09/22/quit-whole-application/</loc>
+    <loc>http://agehua.github.io/2016/09/20/AVG-unwanted-software/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/05/28/qiniu-android-summary/</loc>
+    <loc>http://agehua.github.io/2016/09/22/quit-whole-application/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/12/04/hexo-learning0/</loc>
+    <loc>http://agehua.github.io/2016/12/20/Android-patch-update/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/12/20/Android-patch-update/</loc>
+    <loc>http://agehua.github.io/2016/12/04/hexo-learning0/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
@@ -163,7 +163,7 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/08/17/IntervieweeQuestions/</loc>
+    <loc>http://agehua.github.io/2017/09/12/PBOCKonwledge/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
@@ -177,28 +177,28 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/09/12/PBOCKonwledge/</loc>
+    <loc>http://agehua.github.io/2017/08/17/IntervieweeQuestions/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/10/22/JavaScript-knowledge/</loc>
+    <loc>http://agehua.github.io/2018/04/23/Usage-of-genericity/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2018/04/23/Usage-of-genericity/</loc>
+    <loc>http://agehua.github.io/2017/10/22/JavaScript-knowledge/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/</loc>
+    <loc>http://agehua.github.io/2018/03/14/IntentService-AsyncTask/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
@@ -212,28 +212,28 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2018/03/14/IntentService-AsyncTask/</loc>
+    <loc>http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2018/06/08/JVM-stack-heap-GC/</loc>
+    <loc>http://agehua.github.io/2018/03/01/IntervieweeQuestions-senior/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/</loc>
+    <loc>http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2019/03/27/Android-APP-Bundles-Introduction/</loc>
+    <loc>http://agehua.github.io/2019/12/09/Android-Measure/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
@@ -247,7 +247,7 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2019/12/09/Android-Measure/</loc>
+    <loc>http://agehua.github.io/2019/05/30/RecyclerView-Design-Pattern/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
@@ -268,14 +268,14 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2019/05/31/RecyclerView-source-code/</loc>
+    <loc>http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/12/03/nodejs-learning-getting-started/</loc>
+    <loc>http://agehua.github.io/2019/05/31/RecyclerView-source-code/</loc>
     
     <lastmod>2024-12-05T09:41:56.279Z</lastmod>
     
@@ -303,35 +303,35 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/08/03/android-LocationListener/</loc>
+    <loc>http://agehua.github.io/2016/05/24/JNI-Learning0/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/</loc>
+    <loc>http://agehua.github.io/2016/08/03/android-LocationListener/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/09/20/android-design-pattern-singleton/</loc>
+    <loc>http://agehua.github.io/2016/08/16/RxAndroid-Learning/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/08/16/RxAndroid-Learning/</loc>
+    <loc>http://agehua.github.io/2016/09/20/android-design-pattern-singleton/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2016/05/24/JNI-Learning0/</loc>
+    <loc>http://agehua.github.io/2016/09/05/ThreadLocal-HandlerThread-Looper/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
@@ -352,42 +352,42 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/03/20/SVN-server-linux/</loc>
+    <loc>http://agehua.github.io/2017/01/13/abroad-IM-service-company/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/01/13/abroad-IM-service-company/</loc>
+    <loc>http://agehua.github.io/2017/03/20/SVN-server-linux/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/05/11/Object-Oriented/</loc>
+    <loc>http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/07/08/android-binder-principle/</loc>
+    <loc>http://agehua.github.io/2017/04/10/Annotation-Android-usage/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/03/14/JAVA-JSR-330-Assertion/</loc>
+    <loc>http://agehua.github.io/2017/07/08/android-binder-principle/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/08/02/activity-start-process/</loc>
+    <loc>http://agehua.github.io/2017/05/11/Object-Oriented/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
@@ -401,7 +401,7 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2017/04/10/Annotation-Android-usage/</loc>
+    <loc>http://agehua.github.io/2017/08/02/activity-start-process/</loc>
     
     <lastmod>2024-12-05T09:41:56.278Z</lastmod>
     
@@ -442,13 +442,6 @@
     
   </url>
   
-  <url>
-    <loc>http://agehua.github.io/2016/03/01/android-googlemap-summary/</loc>
-    
-    <lastmod>2024-12-05T09:41:56.277Z</lastmod>
-    
-  </url>
-  
   <url>
     <loc>http://agehua.github.io/2016/05/12/GCM-Azure_summary/</loc>
     
@@ -512,6 +505,13 @@
     
   </url>
   
+  <url>
+    <loc>http://agehua.github.io/2016/03/01/android-googlemap-summary/</loc>
+    
+    <lastmod>2024-12-05T09:41:56.277Z</lastmod>
+    
+  </url>
+  
   <url>
     <loc>http://agehua.github.io/2023/10/26/cross-process-bridge/</loc>
     
@@ -520,14 +520,14 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2021/08/07/view-scroll-apis/</loc>
+    <loc>http://agehua.github.io/2021/07/18/gradle-plugin/</loc>
     
     <lastmod>2024-12-05T09:41:25.325Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2021/07/18/gradle-plugin/</loc>
+    <loc>http://agehua.github.io/2021/08/07/view-scroll-apis/</loc>
     
     <lastmod>2024-12-05T09:41:25.325Z</lastmod>
     
@@ -548,14 +548,14 @@
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/</loc>
+    <loc>http://agehua.github.io/2023/11/02/native-crash-principle/</loc>
     
     <lastmod>2024-12-05T09:41:25.324Z</lastmod>
     
   </url>
   
   <url>
-    <loc>http://agehua.github.io/2023/11/02/native-crash-principle/</loc>
+    <loc>http://agehua.github.io/2023/11/13/native-crash-anr-log-analysis/</loc>
     
     <lastmod>2024-12-05T09:41:25.324Z</lastmod>