Update articles

Author: Tan Minghui

Android 博客汇总.md

@@ -0,0 +1,2 @@
+[]: http://gityuan.com/2019/01/13/arraymap/	"gityuan"
+

Java/动态代理.md

@@ -4,3 +4,7 @@
 
 
 
+------
+
+[]: https://www.jianshu.com/p/23d3f1a2b3c7	"Java动态代理实现及原理分析"
+

android/Android IPC.md

@@ -0,0 +1,32 @@
+# Android 多进程
+
+## 背景
+
+### 进程模型
+
+安装Android应用程序的时候，Android会为每个程序分配一个Linux用户ID，并设置相应的权限，这样其它应用程序就不能访问此应用程序所拥有的数据和资源了。
+
+在 Linux 中，一个用户ID 识别一个给定用户；在 Android 上，一个用户ID 识别一个应用程序。应用程序在安装时被分配用户 ID，应用程序在设备上的存续期间内，用户ID 保持不变。
+
+![image](https://images.cnblogs.com/cnblogs_com/ghj1976/201104/201104281216437986.png)
+
+## 影响
+
+两个进程对应的是不同的内存区域，所有会有以下影响：
+
+- **1.Application对象会创建多次**
+- **2.静态成员不共用**
+- **3.同步锁失效**
+- **4.单例模式失效**
+- **5.数据传递的对象必须可序列化**
+
+## IPC 方法
+
+- Messenger(基于AIDL的上层封装)
+- AIDL
+
+### Messenger
+
+- Handler 每次只会处理一个message
+- 无法考虑并发的情况
+

android/Android 性能优化工具.md

@@ -0,0 +1,54 @@
+# Android 性能优化工具
+
+## 内存
+
+- MAT: 
+- Android Memory Profiler: [Android Profiler](https://developer.android.com/studio/preview/features/android-profiler.html?hl=zh-cn) 中的一个组件，可帮助您识别导致应用卡顿、冻结甚至崩溃的内存泄漏和流失。 它显示一个应用内存使用量的实时图表，让您可以捕获堆转储、强制执行垃圾回收以及跟踪内存分配。
+
+### Android Memory Profiler
+
+内存计数中的类别如下所示：
+
+- **Java**：从 Java 或 Kotlin 代码分配的对象内存。
+
+- **Native**：从 C 或 C++ 代码分配的对象内存。
+
+  即使您的应用中不使用 C++，您也可能会看到此处使用的一些原生内存，因为 Android 框架使用原生内存代表您处理各种任务，如处理图像资源和其他图形时，即使您编写的代码采用 Java 或 Kotlin 语言。
+
+- **Graphics**：图形缓冲区队列向屏幕显示像素（包括 GL 表面、GL 纹理等等）所使用的内存。 （请注意，这是与 CPU 共享的内存，不是 GPU 专用内存。）
+
+- **Stack**： 您的应用中的原生堆栈和 Java 堆栈使用的内存。 这通常与您的应用运行多少线程有关。
+
+- **Code**：您的应用用于处理代码和资源（如 dex 字节码、已优化或已编译的 dex 码、.so 库和字体）的内存。
+
+- **Other**：您的应用使用的系统不确定如何分类的内存。
+
+- **Allocated**：您的应用分配的 Java/Kotlin 对象数。 它没有计入 C 或 C++ 中分配的对象。
+
+#### 查看内存分配
+
+- **Arrange by class**：基于类名称对所有分配进行分组。
+- **Arrange by package**：基于软件包名称对所有分配进行分组。
+- **Arrange by callstack**：将所有分配分组到其对应的调用堆栈。
+
+#### 捕获堆转储
+
+在类列表中，您可以查看以下信息：
+
+- **Heap Count**：堆中的实例数。
+- **Shallow Size**：此堆中所有实例的总大小（以字节为单位）。
+- **Retained Size**：为此类的所有实例而保留的内存总大小（以字节为单位）。
+
+在类列表顶部，您可以使用左侧下拉列表在以下堆转储之间进行切换：
+
+- **Default heap**：系统未指定堆时。
+- **App heap**：您的应用在其中分配内存的主堆。
+- **Image heap**：系统启动映像，包含启动期间预加载的类。 此处的分配保证绝不会移动或消失。
+- **Zygote heap**：写时复制堆，其中的应用进程是从 Android 系统中派生的。
+
+在 **Instance View** 中，每个实例都包含以下信息：
+
+- **Depth**：从任意 GC 根到所选实例的最短 hop 数。
+- **Shallow Size**：此实例的大小。
+- **Retained Size**：此实例支配的内存大小（根据 [dominator 树](https://en.wikipedia.org/wiki/Dominator_(graph_theory))）。
+

android/Android 性能优化汇总.md

@@ -0,0 +1,119 @@
+# 性能优化
+
+
+
+## 优化指标
+
+1. 渲染
+
+- 滑动流畅度：FPS，即Frame per Second，一秒内的刷新帧数，越接近60帧越好；
+- 过度绘制：单页面的3X（粉红色区域） Overdraw小于25%
+- 启动时间：这里主要说的是Activity界面启动时间，一般低于300ms，需要用高频摄像机计算时间。
+
+2. 内存
+
+- 内存大小：峰值越低越好，需要优化前后做对比
+- 内存泄漏：需要用工具检查对比优化前后
+
+3. 功耗
+
+- 单位时间内的掉电量，掉电量越少越好，业内没有固定标准。华为有专门测试功耗的机器，以及自己的标准。
+
+
+
+## 问题分类
+
+1. 渲染问题： 过度绘制、布局冗杂
+2. 内存问题： 内存浪费（内存管理）、内存泄漏
+3. 功耗问题： 耗电
+
+
+
+## 渲染问题
+
+### 常见原因
+
+1. 人为在UI线程中做轻微耗时操作，导致UI线程卡顿；
+2. 布局Layout过于复杂，无法在16ms内完成渲染；
+3. 同一时间动画执行的次数过多，导致CPU或GPU负载过重；
+4. View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；
+5. View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；
+6. 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；
+7. 冗余资源及逻辑等导致加载和执行缓慢；
+8. 臭名昭著的ANR；
+
+
+
+### 过度绘制
+
+1. 移除或修改Window默认的Background
+2. **移除XML布局文件中非必需的Background**
+3. 按需显示占位背景图片
+4. 控制绘制区域（自定义View中通过clipRect() 控制每次刷新的区域）
+
+
+
+### 布局优化
+
+- 可以使用相对布局减少层级的就使用相对布局，否则使用线性布局。Android中RelativeLayout和LinearLayout性能分析，参考：www.jianshu.com/p/8a7d059da…
+- 用merge标签来合并布局，这可以减少布局层次。
+- 用include标签来重用布局，抽取通用的布局可以让布局的逻辑更清晰明了，但要避免include乱用。
+- **避免创建不必要的布局层级。（最容易发生的！）**
+- 使用惰性控件ViewStub实现布局动态加载
+
+
+
+## 内存问题
+
+### 内存浪费
+
+- ArrayMap
+- 避免 AutoBoxing
+- SparseArray
+- 避免使用 Enum
+
+### 内存泄露
+
+- 单例（主要原因还是因为一般情况下单例都是全局的，有时候会引用一些实际生命周期比较短的变量，导致其无法释放）
+- 静态变量（同样也是因为生命周期比较长）
+- Handler内存泄露
+- 匿名内部类（匿名内部类会引用外部类，导致无法释放，比如各种回调）
+- 资源使用完未关闭（BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap）
+
+### 图片资源分辨率
+
+举个例子，对于一张1280×720的图片，如果放在xhdpi，那么xhdpi的设备拿到的大小还是1280×720而xxhpi的设备拿到的可能是1920×1080，这两种情况在内存里的大小分别为：3.68M和8.29M，相差4.61M，在移动设备来说这几M的差距还是很大的。
+
+### 图片压缩
+
+BitmapFactory.Options
+
+### 缓存池大小
+
+默认缓存池设置太大了会导致浪费内存，设置小了又会导致图片经常被回收，所以需要根据每个App的情况，以及设备的分辨率，内存计算出一个比较合理的初始值，可以参考Glide的做法。
+
+### 内存抖动
+
+一个很经典的案例是string拼接创建大量小的对象(比如在一些频繁调用的地方打字符串拼接的log的时候)
+
+### 其他
+
+- **数据结构优化**。ArrayMap及SparseArray是android的系统API，是专门为移动设备而定制的。用于在一定情况下取代HashMap而达到节省内存的目的,具体性能见HashMap，ArrayMap，SparseArray源码分析及性能对比[10]，对于key为int的HashMap尽量使用SparceArray替代，大概可以省30%的内存，而对于其他类型，ArrayMap对内存的节省实际并不明显，10%左右，但是数据量在1000以上时，查找速度可能会变慢。
+- **枚举**，Android平台上枚举是比较争议的，在较早的Android版本，使用枚举会导致包过大，在个例子里面，使用枚举甚至比直接使用int包的size大了10多倍 在stackoverflow上也有很多的讨论, 大致意思是随着虚拟机的优化，目前枚举变量在Android平台性能问题已经不大，而目前Android官方建议，使用枚举变量还是需要谨慎，因为枚举变量可能比直接用int多使用2倍的内存。
+- **ListView复用**，这个大家都知道，getView里尽量复用conertView,同时因为getView会频繁调用，要避免频繁地生成对象
+- **谨慎使用多进程**，现在很多App都不是单进程，为了保活，或者提高稳定性都会进行一些进程拆分，而实际上即使是空进程也会占用内存(1M左右)，对于使用完的进程，服务都要及时进行回收。
+- **尽量使用系统资源**，系统组件，图片甚至控件的id
+- **减少view的层级**，对于可以 延迟初始化的页面，使用viewstub
+- **数据相关**：序列化数据使用protobuf可以比xml省30%内存，慎用shareprefercnce，因为对于同一个sp，会将整个xml文件载入内存，有时候为了读一个配置，就会将几百k的数据读进内存，[数据库](http://lib.csdn.net/base/14)字段尽量精简，只读取所需字段。
+- **dex优化**，代码优化，谨慎使用外部库， 有人觉得代码多少于内存没有关系，实际会有那么点关系，现在稍微大一点的项目动辄就是百万行代码以上，多dex也是常态，不仅占用rom空间，实际上运行的时候需要加载dex也是会占用内存的(几M)，有时候为了使用一些库里的某个功能函数就引入了整个庞大的库，此时可以考虑抽取必要部分，开启proguard优化代码，使用Facebook redex使用优化dex(好像有不少坑)
+
+
+
+
+
+------
+
+[]: http://www.androidchina.net/8612.html	"几乎是史上最全最实用的Android性能全面分析与优化方案研究"
+
+
+

android/ArrayMap 和 SparseArray.md

@@ -0,0 +1,23 @@
+# ArrayMap 和 SparseArray
+
+## 原理
+
+### ArrayMap对象存储格式
+
+- mHashes是一个记录所有key的hashcode值组成的数组，是从小到大的排序方式；
+- mArray是一个记录着key-value键值对所组成的数组，是mHashes大小的2倍；
+
+![arrayMap](http://gityuan.com/images/arraymap/arrayMap.jpg)
+
+### 如何解决 hash 冲突
+
+![ArrayMap memeory.jpg](https://user-gold-cdn.xitu.io/2019/1/17/1685788f707aaf51?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)
+
+
+
+
+
+------
+
+[]: http://gityuan.com/2019/01/13/arraymap/	"深度解读ArrayMap优势与缺陷"
+

Untitled.md renamed to git/Git 和 SVN.md

@@ -0,0 +1,49 @@
+# HTTP 原理
+
+## 模型
+
+四层模型
+
+- 应用层（HTTP）
+- 传输层（TCP）
+- 网络层（IP）
+- 链路层
+
+
+
+## HTTP 协议
+
+### 请求报文
+
+由请求方法、请求 URI、协议版本、可选的请求首部字段和内容实体构成的。
+
+
+
+### 响应报文
+
+响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。
+
+```
+HTTP/1.1 200 OK
+Date: Tue, 10 Jul 2012 06:50:15 GMT
+Content-Length: 362
+Content-Type: text/html
+```
+
+
+
+
+
+## TCP 协议
+
+- 将消息分割为不同报文段
+- 三次握手
+
+
+
+## IP 协议
+
+- 路由寻址
+
+
+

other/HTTP 原理.md

@@ -6,9 +6,9 @@
 
 **HTTP 的不足之处**
 
-- 通信内容使用明文——内容可能被窃听
-- 不验证通信方的身份——可能遭遇伪装
-- 无法验证报文的完整性——报文有可能已遭篡改
+- 通信内容使用明文——**内容可能被窃听**
+- 不验证通信方的身份——**可能遭遇伪装**
+- 无法验证报文的完整性——**报文有可能已遭篡改**
 
 ## 怎样解决 HTTP 的不足之处？