Mario0o · pull · Mar 14, 2023 · Mar 13, 2023
diff --git a/AdavancedPart/ApplicationId vs PackageName.md b/AdavancedPart/ApplicationId vs PackageName.md
@@ -7,7 +7,7 @@ ApplicationId vs PackageName
 
 在`Android`官方文档中有一句是这样描述`applicationId`的:`applicationId : the effective packageName`，真是言简意赅，那既然`applicationId`是有效的包明了，`packageName`算啥？     
 
-所有`Android`应用都有一个包名。包名在设备上能唯一的标示一个应用，它在`Google Play`应用商店中也是唯一的。这就意味着一旦你使用一个包名发布应用后，你就永 远不能改变它的包名；如果你改了包名就会导致你的应用被认为是一个新的应用，并且已经使用你之前应用的用户将不会看到作为更新的新应用包。          
+所有`Android`应用都有一个包名。包名在设备上能唯一的标识一个应用，它在`Google Play`应用商店中也是唯一的。这就意味着一旦你使用一个包名发布应用后，你就永 远不能改变它的包名；如果你改了包名就会导致你的应用被认为是一个新的应用，并且已经使用你之前应用的用户将不会看到作为更新的新应用包。          
 
 之前的`Android Gradle`构建系统中，应用的包名是由你的`manifest`文件中的根元素中的`package`属性定义的:       
 
@@ -86,4 +86,4 @@ buildTypes {
 ---
 
 - 邮箱 ：charon.chui@gmail.com  
-- Good Luck! 
+- Good Luck! 
diff --git a/AdavancedPart/BroadcastReceiver安全问题.md b/AdavancedPart/BroadcastReceiver安全问题.md
@@ -5,7 +5,7 @@ BroadcastReceiver安全问题
 - 保证发送的广播要发送给指定的对象      
     当应用程序发送某个广播时系统会将发送的`Intent`与系统中所有注册的`BroadcastReceiver`的`IntentFilter`进行匹配，若匹配成功则执行相应的`onReceive`函数。可以通过类似`sendBroadcast(Intent, String)`的接口在发送广播时指定接收者必须具备的`permission`或通过`Intent.setPackage`设置广播仅对某个程序有效。
 
-- 保证我接收到的广播室指定对象发送过来的    
+- 保证我接收到的广播是指定对象发送过来的    
     当应用程序注册了某个广播时，即便设置了`IntentFilter`还是会接收到来自其他应用程序的广播进行匹配判断。对于动态注册的广播可以通过类似`registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler)`的接口指定发送者必须具备的`permission`，对于静态注册的广播可以通过`android:exported="false"`属性表示接收者对外部应用程序不可用，即不接受来自外部的广播。
 
 `android.support.v4.content.LocalBroadcastManager`工具类，可以实现在自己的进程内进行局部广播发送与注册，使用它比直接通过sendBroadcast(Intent)发送系统全局广播有以下几个好处：
@@ -46,4 +46,4 @@ protected void onDestroy() {
 ---
 
 - 邮箱 ：charon.chui@gmail.com  
-- Good Luck! 
+- Good Luck! 
diff --git a/AdavancedPart/ConstraintLaayout简介.md b/AdavancedPart/ConstraintLaayout简介.md
@@ -224,15 +224,10 @@ implementation 'com.android.support.constraint:constraint-layout:1.1.0'
 它有点类似于`RelativeLayout`，但远比`RelativeLayout`要更强大。
 `ConstraintLayout`在测量/布局阶段的性能比 `RelativeLayout`大约高`40%`。      
 
-
-
-
-
-
 - [Build a Responsive UI with ConstraintLayout](https://developer.android.com/training/constraint-layout/index.html)
 - [ConstraintLayout文档](https://developer.android.com/reference/android/support/constraint/package-summary.html)
 
 ---
 
 - 邮箱 ：charon.chui@gmail.com  
-- Good Luck! 
+- Good Luck! 
diff --git a/AdavancedPart/Crash及ANR分析.md b/AdavancedPart/Crash及ANR分析.md
@@ -15,7 +15,7 @@
 6、再执行handleAppCrashLocked方法：
 
 当1分钟内同一进程连续crash两次时，且非persistent进程，则直接结束该应用所有activity，并杀死该进程以及同一个进程组下的所有进程。然后再恢复栈顶第一个非finishing状态的activity;
-当1分钟内同一进程连续crash两次时，且persistent进程，，则只执行恢复栈顶第一个非finishing状态的activity;
+当1分钟内同一进程连续crash两次时，且persistent进程，则只执行恢复栈顶第一个非finishing状态的activity;
 当1分钟内同一进程未发生连续crash两次时，则执行结束栈顶正在运行activity的流程。
 
 7、通过mUiHandler发送消息SHOW_ERROR_MSG，弹出crash对话框；
@@ -35,10 +35,6 @@
 
 
 
-
-
-
-
 Native Crash
 
     崩溃过程：native crash 时操作系统会向进程发送信号，崩溃信息会写入到 data/tombstones 下，并在 logcat 输出崩溃日志
@@ -70,10 +66,8 @@ ANR排查流程
 1、Log获取
 1、抓取bugreport
 adb shell bugreport > bugreport.txt
-复制代码
 2、直接导出/data/anr/traces.txt文件
 adb pull /data/anr/traces.txt trace.txt
-复制代码
 2、搜索“ANR in”处log关键点解读
 
 
@@ -102,15 +96,13 @@ CPU usage from 18101ms to 0ms ago
 如果CPU使用量很少，说明主线程可能阻塞。
 3、在bugreport.txt中根据pid和发生时间搜索到阻塞的log处
 ----- pid 10494 at 2019-11-18 15:28:29 -----
-复制代码
 4、往下翻找到“main”线程则可看到对应的阻塞log
 "main" prio=5 tid=1 Sleeping
 | group="main" sCount=1 dsCount=0 flags=1 obj=0x746bf7f0 self=0xe7c8f000
 | sysTid=10494 nice=-4 cgrp=default sched=0/0 handle=0xeb6784a4
 | state=S schedstat=( 5119636327 325064933 4204 ) utm=460 stm=51 core=4 HZ=100
 | stack=0xff575000-0xff577000 stackSize=8MB
 | held mutexes=
-复制代码
 上述关键字段的含义如下所示：
 
 tid：线程号
@@ -123,14 +115,3 @@ stm：该线程在内核态的执行时间(jiffies)
 sCount：该线程被挂起的次数
 dsCount：该线程被调试器挂起的次数
 self：线程本身的地址
-
-
-
-
-
-
-
-
-
-
-
diff --git a/AppPublish/Zipalign优化.md b/AppPublish/Zipalign优化.md
@@ -22,7 +22,7 @@ And any files added to an "aligned" archive will not be aligned.
 ```
 
 大意就是它提供了一个灰常重要滴功能来确保所有未压缩的数据都从文件的开始位置以指定的4字节对齐方式排列，例如图片或者
-`raw`文件。当然好处也是大大的，就是能够减少内存的资源消耗。最后他还特意提醒了你一下就是已经在对`apk`签完名之后再用`zipalign`
+`raw`文件。当然好处也是大大的，就是能够减少内存的资源消耗。最后他还特意提醒了你一下就是一定在对`apk`签完名之后再用`zipalign`
 优化，如果你在之前用，那无效。
 
 废多看用法:      

diff --git a/Gradle&Maven/Composing builds简介.md b/Gradle&Maven/Composing builds简介.md
@@ -293,7 +293,7 @@ gradlePlugin {
 
 3. 在versionPlugin/src/main/java/包名/目录下新建Deps.kt文件，添加你的依赖配置，如：
 
-```groovy
+```kotlin
 package com.xx.xx.versionplugin
 
 class Deps : Plugin<Project> {

diff --git a/SourceAnalysis/Activity启动过程.md b/SourceAnalysis/Activity启动过程.md
@@ -8,7 +8,7 @@ Activity启动过程
 
 今天就来分析一下，我们开启`Activity`主要有两种方式:    
 
-- 通过桌面图标启动，桌面就是`Launcher`其实他也是一个应用程序，他也是继承`Activity`。
+- 通过桌面图标启动，桌面就是`Launcher`,其实他也是一个应用程序，他也是继承`Activity`。
 - 在程序内部调用`startActivity()`开启。
 
 而`Launcher`点击图标其实也是调用了`Activity`的`startActivity()`方法，所以我们就从`startActivity()`方法入手了。     
@@ -141,9 +141,7 @@ public class Instrumentation {
 	...
 }
 ```
-放狗查了下`Instrumentation`的意思是仪器、工具、装置的意思。我就大体翻一下(英语不好- -~，可能不准确)该类是实现应用程序代码的基类，当该类在
-启动的状态下运行时，该类会在其他任何应用程序运行前进行初始化，允许你件事所有应用程序与系统的交互。一个`Instrumentation`实例会通过`Manifest`文件
-中的`<instrumenttation`标签描述给系统。        
+放狗查了下`Instrumentation`的意思是仪器、工具、装置的意思。我就大体翻一下:该类是实现应用程序代码的基类，当该在启动的状态下运行时，该类会在其他任何应用程序运行前进行初始化，允许你监视所有应用程序与系统的交互。一个`Instrumentation`实例会通过`Manifest`文件中的`<instrumenttation`标签描述给系统。        
 所以继续看一下`mInstrumentation.execStartActivity()`:       
 ```java
 /**