Add

Author: faterap

Android 博客汇总.md

@@ -0,0 +1,42 @@
+# Ability
+
+
+
+## 1. 概念
+
+### 1.1 Feature Ability
+
+ **Ability** 是应用所具备能力的抽象，也是应用程序的重要组成部分。一个应用可以具备多种能力（即可以包含多个 Ability），HarmonyOS 支持应用以 Ability 为单位进行部署。Ability 可以分为 FA（Feature Ability）和 PA（Particle Ability）两种类型，每种类型为开发者提供了不同的模板，以便实现不同的业务功能。
+  从上面一段文字，去其糟粕，取其精华之后就是两点。**FA（Feature Ability）**和**PA（Particle Ability）**
+
+  **FA（Feature Ability）** ，中文意思是功能能力，它支持**Page Ability** 页面能力用于提供与用户交互的能力。一个Page 可以由一个或多个 AbilitySlice 构成，AbilitySlice 是指应用的单个页面及其控制逻辑的总和。
+
+
+
+### 1.2 Page Ability
+
+现在我们知道这个Page Ability是主要负责页面交互的，那么就可以理解为Android 的Activity。那么都知道Activity有生命周期，同样的Page Ability也是的。
+
+![在这里插入图片描述](https://img-blog.csdnimg.cn/20200923100950751.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDM2MjE0,size_16,color_FFFFFF,t_70#pic_center)
+
+### 1.3 Service Ability
+
+先来看一下Service Ability的官方解释基于 Service 模板的 Ability（以下简称“Service”）主要用于后台运行任务（如执行音乐播放、文件下载等），但不提供用户交互界面。Service 可由其他应用或 Ability 启动，即使用户切换到其他应用，Service 仍将在后台继续运行。
+  Service 是单实例的。在一个设备上，相同的 Service 只会存在一个实例。如果多个 Ability 共用这个实例，只有当与 Service 绑定的所有 Ability 都退出后，Service 才能够退出。由于Service 是在主线程里执行的，因此，如果在 Service 里面的操作时间过长，开发者必须在Service 里创建新的线程来处理，防止造成主线程阻塞，应用程序无响应。其实和Android的Service有点像。
+
+### 1.4 Data Ability
+
+使用 Data 模板的 Ability（以下简称“Data”）有助于应用管理其自身和其他应用存储数据的访问，并提供与其他应用共享数据的方法。Data 既可用于同设备不同应用的数据共享，也支持跨设备不同应用的数据共享。
+
+  数据的存放形式多样，可以是数据库，也可以是磁盘上的文件。Data 对外提供对数据的增、删、改、查，以及打开文件等接口，这些接口的具体实现由开发者提供。说起来和Android的ContentProvider有些像。
+
+
+
+
+
+
+
+
+
+https://aijishu.com/a/1060000000139663#item-1-3
+

HarmonyOS/Ability.md

@@ -0,0 +1,39 @@
+# FA卡片
+
+## 1. 基本概念
+
+- 卡片使用方
+
+  显示卡片内容的宿主应用，控制卡片在宿主中展示的位置。
+
+- 卡片管理服务
+
+  用于管理系统中所添加卡片的常驻代理服务，包括卡片对象的管理与使用，以及卡片周期性刷新等。
+
+- 卡片提供方
+
+  提供卡片显示内容的HarmonyOS应用或原子化服务，控制卡片的显示内容、控件布局以及控件点击事件。
+
+  > 卡片使用方和提供方不要求常驻运行，在需要添加/删除/请求更新卡片时，卡片管理服务会拉起卡片提供方获取卡片信息。
+
+## 2. 服务卡片运作机制
+
+![点击放大](https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtyPub/011/111/111/0000000000011111111.20210702111859.85076227145362969263053337109121:50520704022932:2800:CB9F3AEB0D938C6E50C1FCAF50E1ECE66A6B8AF7843C598B4D7F65F2C2CB127F.png?needInitFileName=true?needInitFileName=true)
+
+- - **卡片管理服务包含以下模块：**
+
+    - 周期性刷新：在卡片添加后，根据卡片的刷新策略启动定时任务周期性触发卡片的刷新。
+    - 卡片缓存管理：在卡片添加到卡片管理服务后，对卡片的视图信息进行缓存，以便下次获取卡片时可以直接返回缓存数据，降低时延。
+    - 卡片生命周期管理：对于卡片切换到后台或者被遮挡时，暂停卡片的刷新；以及卡片的升级/卸载场景下对卡片数据的更新和清理。
+    - 卡片使用方对象管理：对卡片使用方的RPC对象进行管理，用于使用方请求进行校验以及对卡片更新后的回调处理。
+    - 通信适配层：负责与卡片使用方和提供方进行RPC通信。
+
+    **卡片提供方包含以下模块：**
+
+    - 卡片服务：由卡片提供方开发者实现，开发者实现onCreateForm、onUpdateForm和onDeleteForm处理创建卡片、更新卡片以及删除卡片等请求，提供相应的卡片服务。
+    - 卡片提供方实例管理模块：由卡片提供方开发者实现，负责对卡片管理服务分配的卡片实例进行持久化管理。
+    - 通信适配层：由HarmonyOS SDK提供，负责与卡片管理服务通信，用于将卡片的更新数据主动推送到卡片管理服务。
+
+## 3. 接口说明
+
+![点击放大](https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtyPub/011/111/111/0000000000011111111.20210702111859.92582264611953438954536903230711:50520704022932:2800:50753D57716EF9EA207328DFC2A555B426888E44696BB82812C927802114E23D.png?needInitFileName=true?needInitFileName=true)

HarmonyOS/FA卡片.md

@@ -0,0 +1,5 @@
+协助检查以下内容
+
+1、hilog服务有没有开启，若没有开启请开启，检查路径：在拨号界面 输入 *#*#2846579#*#* ->后台设置->APLOG设置；
+
+2、是不是有启动其他的IDE，如果有请关闭；

HarmonyOS/Tips.md

@@ -0,0 +1,7 @@
+# Android编译流程
+
+
+
+![img](https://user-gold-cdn.xitu.io/2019/1/31/168a324533855b27?imageslim)
+
+https://juejin.im/post/6844903773144350734

JVM/Android编译流程.md

@@ -1,17 +1,40 @@
-# GC 算法
 
-## 介绍
 
-- 标记回收算法（Mark and Sweep GC）
-  从"GC Roots"集合开始，将内存整个遍历一次，保留所有可以被GC Roots直接或间接引用到的对象，而剩下的对象都当作垃圾对待并回收，这个算法需要中断进程内其它组件的执行并且可能产生内存碎片
-- 复制算法 (Copying）
-  将现有的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的**内存中的存活对象复制到未被使用的内存块**中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
-- 标记-压缩算法 (Mark-Compact)
-  先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。
-- 分代算法
-  将所有的新建对象都放入称为年轻代的内存区域，年轻代的特点是对象会很快回收，因此，在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老生代的内存空间。对于新生代适用于复制算法，而对于老年代则采取标记-压缩算法。
+# cGC 算法
 
-## 区别
+### 1. 垃圾回收算法介绍
+
+1. 标记回收算法（Mark and Sweep GC）从”`GC Roots`”集合开始，将内存整个遍历一次，保留所有可以被 `GC Roots` 直接或间接引用到的对象，而剩下的对象都当作垃圾对待并回收，过程分两步。
+   1. Mark 标记阶段：找到内存中的所有 GC Root 对象，只要是和 GC Root 对象直接或者间接相连则标记为灰色（也就是存活对象），否则标记为黑色（也就是垃圾对象）。
+   2. Sweep 清除阶段：当遍历完所有的 GC Root 之后，则将标记为垃圾的对象直接清除。
+
+
+
+![标记清除算法](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/debab099380c4ee3b911a8f9b0af2adc~tplv-k3u1fbpfcp-watermark.image)
+
+
+
+- 优点：实现简单，不需要将对象进行移动。
+- 缺点：这个算法需要中断进程内其他组件的执行（stop the world），并且可能产生内存碎片，提高了垃圾回收的频率。
+
+
+
+2. 复制算法 (Copying）
+   将现有的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的**内存中的存活对象复制到未被使用的内存块**中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
+
+
+
+3. 标记-压缩算法 (Mark-Compact)
+   先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。
+
+
+
+4. 分代算法
+   将所有的新建对象都放入称为年轻代的内存区域，年轻代的特点是对象会很快回收，因此，在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老生代的内存空间。对于新生代适用于复制算法，而对于老年代则采取标记-压缩算法。
+
+
+
+#### 区别
 
 乍一看这两个算法似乎并没有多大的区别，都是标记了然后挪到另外的内存地址进行回收，那为什么不同的分代要使用不同的回收算法呢？
 
@@ -21,4 +44,30 @@
 
 后者在工作的时候则需要分别的mark与compact阶段，mark阶段用来发现并标记所有活的对象，然后compact阶段才移动对象来达到compact的目的。如果compact方式是sliding compaction，则在mark之后就可以按顺序一个个对象“滑动”到空间的某一侧。因为已经先遍历了整个空间里的对象图，知道所有的活对象了，所以移动的时候就可以在同一个空间内而不需要多一份空间。
 
-所以新生代的回收会更快一点，老年代的回收则会需要更长时间，同时压缩阶段是会暂停应用的，所以给我们应该尽量避免对象出现在老年代。
+所以新生代的回收会更快一点，老年代的回收则会需要更长时间，同时压缩阶段是会暂停应用的，所以给我们应该尽量避免对象出现在老年代。
+
+### 
+
+### 2. 垃圾检出算法
+
+
+
+### 1.引用计数法：
+
+给一个对象添加引用计数器，每当有一个地方引用它，计数器就加一，引用失效就减一。好了，问题来了，如果我有两个对象互相引用，除此之外没有其他任何对象引用他们，实际上这两个对象已经无法访问，即我们说的垃圾对象。但他们互相引用，计数不为0，所以无法回收。这就是引用计数法的缺陷。
+
+### 2.可达性分析算法（也叫根搜索算法）：
+
+以根集对象为起始点进行搜索，如果有对象不可达的话，即为垃圾对象。
+
+那些点可以作为GC Roots呢？一般来说，如下情况的对象可以作为GC Roots：
+
+1. 虚拟机栈(栈桢中的本地变量表)中的引用的对象
+2. 方法区中的类静态属性引用的对象
+3. 方法区中的常量引用的对象
+4. 本地方法栈中JNI（Native方法）的引用的对象 
+
+总之，JVM在做垃圾回收的时候，会检查堆中的所有对象是否被这些根集中的对象所引用，不能够被引用的对象就会被垃圾回收器回收。
+
+
+

JVM/GC算法.md

@@ -2,7 +2,7 @@
 
 java是在java虚拟机上运行，一般地大家讲到的Java运行时内存结构其实就是Jvm内存
 
-## 运行时内存结构
+### 1. 运行时内存结构
 
 Java代码是运行在Java虚拟机之上的，由Java虚拟机通过解释执行(解释器)或编译执行(即时编译器)来完成，故Java运行时内存结构，也就是指Java虚拟机的运行时内存结构。
 
@@ -21,23 +21,23 @@ Java代码是运行在Java虚拟机之上的，由Java虚拟机通过解释执
 - 方法区：存放类信息、常量、静态变量、编译器编译后的代码等数据；
 - 常量池：存放编译器生成的各种字面量和符号引用，是方法区的一部分。
 
-## 结构详解
+### 2. 结构详解
 
 运行时内存分为五大块区域（常量池属于方法区，算作一块区域），前面简要介绍了每个区域的功能，那接下来再详细说明每个区域的内容，Java内存总体结构图如下：
 
 ![stack_heap_info](http://gityuan.com/images/jvm/stack_heap_info.png)
 
-### 程序计数器PC
+#### 2.1.程序计数器PC
 
 程序计数器PC，当前线程所执行的字节码行号指示器。每个线程都有自己计数器，是私有内存空间，该区域是整个内存中较小的一块。
 
 当线程正在执行一个Java方法时，PC计数器记录的是正在执行的虚拟机字节码的地址；当线程正在执行的一个Native方法时，PC计数器则为空（Undefined）。
 
-### 虚拟机栈
+#### 2.2.虚拟机栈
 
 虚拟机栈，生命周期与线程相同，是Java方法执行的内存模型。每个方法(不包含native方法)执行的同时都会创建一个栈帧结构，方法执行过程，对应着虚拟机栈的入栈到出栈的过程。
 
-### 栈帧(Stack Frame)结构
+#### 2.3.栈帧(Stack Frame)结构
 
 栈帧是用于支持虚拟机进行方法执行的数据结构，是属性运行时数据区的虚拟机栈的栈元素。见上图， 栈帧包括：
 
@@ -55,22 +55,22 @@ Java代码是运行在Java虚拟机之上的，由Java虚拟机通过解释执
 
 - 额外附加信息，虚拟机规范没有明确规定，由具体虚拟机实现。
 
-### 异常(Exception)
+#### 2.4.异常(Exception)
 
 Java虚拟机规范规定该区域有两种异常：
 
 StackOverFlowError：当线程请求栈深度超出虚拟机栈所允许的深度时抛出
 OutOfMemoryError：当Java虚拟机动态扩展到无法申请足够内存时抛出
 
-## 本地方法栈
+#### 2.5.本地方法栈
 
 本地方法栈则为虚拟机使用到的Native方法提供内存空间，而前面讲的虚拟机栈式为Java方法提供内存空间。有些虚拟机的实现直接把本地方法栈和虚拟机栈合二为一，比如非常典型的Sun HotSpot虚拟机。
 
 异常(Exception)：
 
 Java虚拟机规范规定该区域可抛出StackOverFlowError和OutOfMemoryError。
 
-## Java 堆
+### 3. Java 堆
 
 **Java堆，是Java虚拟机管理的最大的一块内存，也是GC的主战场**，里面存放的是几乎所有的对象实例和数组数据。JIT编译器有栈上分配、标量替换等优化技术的实现导致部分对象实例数据不存在Java堆，而是栈内存。
 
@@ -87,13 +87,13 @@ Java虚拟机规范规定该区域可抛出StackOverFlowError和OutOfMemoryError
 
 异常(Exception)：Java虚拟机规范规定该区域可抛出OutOfMemoryError。
 
-## 方法区
+#### 3.1 方法区
 
 方法区主要存放的是已被虚拟机加载的类信息、常量、静态变量、编译器编译后的代码等数据。GC在该区域出现的比较少。
 
 异常(Exception)：Java虚拟机规范规定该区域可抛出OutOfMemoryError。
 
-## 运行时常量池
+#### 3.2 运行时常量池
 
 **运行时常量池也是方法区的一部分**，用于存放编译器生成的各种字面量和符号引用。运行时常量池除了编译期产生的Class文件的常量池，还可以在运行期间，将新的常量加入常量池，比较常见的是String类的intern()方法。
 

JVM/JVM 内存模型.md

@@ -0,0 +1,49 @@
+# 虚拟机概念
+
+### 1. Dex
+
+在`Android`端，`Android`上的`Davlik`虚拟机是运行`.dex`。所以还得将`.class`转成`dex`文件，即`dex`文件就是`Android Dalvik`虚拟机运行的程序。
+
+### 2. odex
+
+
+
+### 3. Oat
+
+ART虚拟机使用的是oat文件，oat文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。APK在安装的过程中，会通过dex2oat工具生成一个OAT文件。对于APK来说，oat文件实际上就是对odex文件的包装，即oat=odex，而对于一些framework中的一些jar包，会生成相应的oat尾缀的文件，如system@framework@boot-telephony-common.oat。
+
+### 4. Dalvik虚拟机
+
+Dalvik是Google公司自己设计用于Android平台的虚拟机，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
+很长时间以来，Dalvik虚拟机一直被用户指责为拖慢安卓系统运行速度不如IOS的根源。
+2014年6月25日，Android L 正式亮相于召开的谷歌I/O大会，Android L 改动幅度较大，谷歌将直接删除Dalvik，代替它的是传闻已久的ART。
+
+### 5. Art虚拟机
+
+Dalvik 使用 JIT（Just in time）编译，而 ART 使用 AOT（Ahead of time）编译。Android 7.0 向 ART 中添加了一个 just-in-time（JIT）编译器，这样就可以在应用运行时持续的提高其性能。
+ART 和 Dalvik 一样使用的是相同的 DEX 字节码。编译好的应用如果使用 ART 在安装时需要额外的时间用于编译，同时还需要更多的空间用于存储编译后的代码。
+由于 ART 直接运行的是应用的机器码（native execution），它所占用的 CPU 资源要少于 使用 JIT 编译的 Dalvik。由于占用较少的 CPU 资源也就消耗更少的电池资源。
+
+Dalvik虚拟机可以看做是一个Java虚拟机。在 Android系统初期，每次运行程序的时候，Dalvik负责将dex翻译为机器码交由系统调用。这样有一个**缺陷**：**每次执行代码，都需要Dalvik将操作码代码翻译为机器对应的微处理器指令，然后交给底层系统处理，运行效率很低**。
+
+为了提升效率Android在2.2版本中添加了**JIT编译器**，当App运行时，每当遇到一个新类，JIT编译器就会对这个类进行即时编译，经过编译后的代码，会被优化成相当精简的原生型指令码（即native code），这样在下次执行到相同逻辑的时候，速度就会更快。JIT 编译器可以对执行次数频繁的 dex/odex 代码进行编译与优化，将 dex/odex 中的 Dalvik Code（Smali 指令集）翻译成相当精简的 Native Code 去执行，JIT 的引入使得 Dalvik 的性能提升了 3~6 倍。
+
+### 6. JIT
+
+　JIT，即Just-in-time,动态(即时)编译，边运行边编译
+
+使用 Dalvik JIT 编译器，每次应用在运行时，它实时的将一部分 Dalvik 字节码翻译成机器码。在程序的执行过程中，更多的代码被被编译并缓存。由于 JIT 只翻译一部分代码，它消耗的更少的内存，占用的更少的物理存储空间。
+
+### 7. AOT
+
+AOT，Ahead Of Time，指运行前编译，是两种程序的编译方式
+
+ART 内置了一个 Ahead-of-Time 编译器。在应用的安装期间，他就将 DEX 字节码翻译成机器码并存储在设备的存储器上。这个过程只在将应用安装到设备上时发生。由于不再需要 JIT 编译，代码的执行速度要快得多。
+
+### 8. JIT和AOT共存
+
+Android 7.0上，JIT 编译器被再次使用，采用AOT/JIT 混合编译的策略，特点是：
+
+1. 应用在安装的时候dex不会再被编译
+2. App运行时,dex文件先通过解析器被直接执行，热点函数会被识别并被JIT编译后存储在 `jit code cache` 中并生成profile文件以记录热点函数的信息。
+3. 手机进入 IDLE（空闲） 或者 Charging（充电） 状态的时候，系统会扫描 App 目录下的 profile 文件并执行 AOT 过程进行编译。