I.安装

下载地址

下载点我

安装过程一路默认即可

II.配置

找到Privoxy的配置文件位置，默认是在C:\Program Files (x86)\Privoxy\config.txt

然后使用编辑器来编辑它，底部加入一行forward-socks5 / 127.0.0.1:1080 .

注意：这里的1080是指本机的Shadowsocks所在的端口号，默认为1080

III.测试

配置完毕后保存后，启动Privoxy。

接下来就是测试是否配置成功了

在各个软件中配置Http代理

Android Studio

在设置中找到HTTP Proxy选择Manual Proxy configuration进行手动配置代理，
这里选择HTTP,主机名和端口号配置如下图所示：

然后点击 输入测试网址测试是否配置成功，如下图所示为配置成功：

Git

在Git bash下进行如下操作即可：

设置git全局代理

git config --global http.proxy http://127.0.0.1:8118

git config --global https.proxy https://127.0.0.1:8118

取消代理设置

git config --global --unset http.proxy

git config --global --unset https.proxy

Chrome浏览器

打开浏览器设置点击 并参照下面图片步骤所示：

保存确定后重启浏览器，打开地址栏输入http://p.p/访问，出现以下页面表示配置成功

注意：这里所有的8118是指本机的Privoxy软件所在的端口号，默认为8118

感谢阅读这份帮助教程。

adb

1. 通过adb保持屏幕常亮(当USB连接时)

   svc power stayon usb

2. 查看应用列表

   格式：

   adb shell pm list packages [-f] [-d] [-e] [-s] [-3] [-i] [-u] [--user USER_ID] [FILTER]

   | 参数 | 显示列表 |
   |————|—————————-|
   | 无 | 所有应用 |
   | -f | 显示应用关联的 apk 文件 |
   | -d | 只显示 disabled 的应用 |
   | -e | 只显示 enabled 的应用 |
   | -s | 只显示系统应用 |
   | -3 | 只显示第三方应用 |
   | -i | 显示应用的 installer |
   | -u | 包含已卸载应用 |
   | <FILTER> | 包名包含 <FILTER> 字符串 |

关于Activity的Task和Back Stack，一直比较困惑，这里做一些笔记，大多摘自官网API指南。

概念

Task是指在执行特定工作时与用户交互的一系列Activity。这些Activity按照各自打开的顺序排列在堆栈(即“返回栈”)中。

工作流程

设备主屏幕是大多数Task的起点。当用户触摸应用启动器中的图标（或主屏幕上的快捷键）时，该应用的Task将出现在前台。 如果应用不存在Task（应用最近未曾使用），则会创建一个新Task，并且该应用的“主”Activity 将作为堆栈中的根 Activity 打开。

当前 Activity 启动另一个 Activity 时，该新 Activity 会被推送到堆栈顶部，成为焦点所在。 前一个 Activity 仍保留在堆栈中，但是处于停止状态。Activity 停止时，系统会保持其用户界面的当前状态。 用户按“返回”按钮时，当前 Activity 会从堆栈顶部弹出（Activity 被销毁），而前一个 Activity 恢复执行（恢复其 UI 的前一状态）。 堆栈中的 Activity 永远不会重新排列，仅推入和弹出堆栈：由当前 Activity 启动时推入堆栈；用户使用“返回”按钮退出时弹出堆栈。 因此，返回栈以“后进先出”对象结构运行。 图 1 通过时间线显示 Activity 之间的进度以及每个时间点的当前返回栈，直观呈现了这种行为。

图 1. 显示Task中的每个新 Activity 如何向返回栈添加项目。 用户按“返回”按钮时，当前 Activity 随即被销毁，而前一个 Activity 恢复执行。

如果用户继续按“返回”，堆栈中的相应 Activity 就会弹出，以显示前一个 Activity，直到用户返回主屏幕为止（或者，返回Task开始时正在运行的任意 Activity）。 当所有 Activity 均从堆栈中删除后，Task即不复存在。

Task是作为一个整体，当用户开启新的Task或者返回Home界面时，该Task会移动到”后台“。尽管在后台时，该Task中的所有Activity全部为停止状态，但是该Task的返回栈仍旧不变，也就是说当另一个Task启动之后，该Task仅失去焦点而已。
然而，Task可以返回到“前台”，用户就能回到离开时的状态。

示例1. 两个Task：Task B 在前台接收用户交互，而Task A 则在后台等待恢复。

注意： 后台可以同时运行多个Task。但是，如果用户同时运行多个后台Task，则系统可能会开始销毁后台 Activity，以回收内存资源，从而导致 Activity 状态丢失。

由于返回栈中的 Activity 永远不会重新排列，因此如果应用允许用户从多个 Activity 中启动特定 Activity，则会创建该 Activity 的新实例并推入堆栈中（而不是将 Activity 的任一先前实例置于顶部）。 因此，应用中的一个 Activity 可能会多次实例化（即使 Activity 来自不同的任务）。

示例2. 一个 Activity 将多次实例化。

Activity 和任务的默认行为总结如下

• 当 Activity A 启动 Activity B 时，Activity A 将会停止，但系统会保留其状态（例如，滚动位置和已输入表单中的文本）。如果用户在处于 Activity B 时按“返回”按钮，则 Activity A 将恢复其状态，继续执行。
• 用户通过按“主页”按钮离开任务时，当前 Activity 将停止且其任务会进入后台。 系统将保留任务中每个 Activity 的状态。如果用户稍后通过选择开始任务的启动器图标来恢复任务，则任务将出现在前台并恢复执行堆栈顶部的 Activity。
• 如果用户按“返回”按钮，则当前 Activity 会从堆栈弹出并被销毁。 堆栈中的前一个 Activity 恢复执行。销毁 Activity 时，系统绝对不会保留该 Activity 的状态。
• 即使来自其他Task，Activity 也可以多次实例化。

最近在看关于git方面的博客文章和书籍，在这里顺便做些笔记，正所谓温故而知新嘛！

Git基本原理

1.直接记录快照，而非差异比较

git和其他版本控制系统的主要差别在于，git只关心文件数据的整体是否发生变化，而大多数其他版本控制系统只关心文件内容的具体差异。
git更像是把变化的文件做快照，记录在一个微型的文件系统中。每次提交更新时，扫描一遍所有文件的指纹信息(SHA-1哈希值)并对文件做一快照，让后保存指向这次快照的索引。若文件没有变化，git不会再次保存，而只对上次保存的快照做一链接。

工作方式如图所示：

2. 近乎所有操作都是本地执行

在git中的绝大多数操作都只需要访问本地文件和资源，不需要连接网络。

3. 时刻保持数据完整性

在保存到git之前，所有的数据都要进行内容的校验和(checksum)计算，并将此结果作为数据的唯一标识和索引。
git使用SHA-1算法计算数据的校验和，通过对文件的内容和目录的结构计算出一个SHA-1哈希值，作为指纹字符串。
该字符串由40个十六进制字符(0-9及a~f)组成。

4. 多数操作仅添加数据

常用的git操作大多仅仅是把数据添加到数据库(.git目录)。

5. 文件的三种状态

对于任何一个文件，在git中都只有3种状态：

1. 已提交(committed) 表示该文件已被安全地保存在本地数据库，即执行了git commit命令
2. 已修改(modified) 表示修改了某个文件，但是还没有提交保存
3. 已暂存(staged) 表示把已修改的文件放在下次提交时要保存的清单中，也就是执行了git add命令

git管理项目时，文件流转的3个工作区域：

示意图：

1. 工作目录 git对某个目录进行版本控制，那么这个目录就叫做工作目录
2. 暂存区域 一般存放在.git目录中
3. 本地仓库 一般就是执行了git init所在的目录

基本的git工作流程如下：

1. 在工作目录修改某些文件
2. 对修改的文件进行快照，然后保存在暂存区域
3. 提交更新，讲保存在暂存区域的文件快照永久转储到.git目录中

常用命令

Github协作流程

1. Fork主仓库得到派生项目
2. 通过 git clone或者git pull将派生项目的代码拉取到本地
3. 本地修改代码实现功能
4. 通过git add与git commit命令提交代码到本地
5. 通过git pull命令从主仓库对应的分支更新代码，如有冲突则解决冲突
6. 将本地代码提交到派生项目对应的分支中
7. 向主仓库发送Pull request请求
8. 主仓库管理员合并Pull request
9. 完成一轮协作

定义

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

使用场景

避免产生多个对象消耗过多的资源，或者某种类型的对象有且只有一个 (例如：访问IO和数据库资源。)

关键点

1. 私有化构造函数。
2. 通过一个静态方法或者枚举返回单例类对象。
3. 确保单例类对象有且只有一个，尤其是在多线程环境下。
4. 确保单例类对象在反序列化时不会重新构建对象。

饿汉式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
 * 单例 饿汉式
 * Created by hp1 on 2016/3/4.
 */
public class Singleton {
    private static Singleton instance = new Singleton();
    //函数私有化
    private Singleton() {	
    }
    public static Singleton getInstance() {
        return instance;
    }
}

懒汉式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

/**
 * 单例 懒汉式
 * Created by hp1 on 2016/3/4.
 */
public class Singleton {
    private static Singleton instance;
    private Singleton() {	
    }	
    /*
     * 获取实例
     * @return
     */
    public static synchronized Singleton getInstance(){
        if (instance == null) {
            instance=new Singleton();
        }
        return instance;
    }
}

懒汉式缺点

• 第一次加载需要及时进行实例化，反应稍慢
  每次调用getInstance都会进行同步，造成不必要的同步开销

Double Check Lock(双检锁)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/**
 * 单例 Double Check Lock
 * Created by hp1 on 2016/3/4.
 */
public class Singleton {
    private static Singleton instance = null;
    
    private Singleton() {
    
    }
    
    /*
     *获取实例
     */
    public static Singleton getsInstance() {
        if (instance == null) {//为了避免不必要的同步
            synchronized (Singleton.class) {
                if (instance == null) {//为了在null的情况下创建实例
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

DCL缺点

• 第一次加载时反应慢，也由于java内存模型的原因偶尔会失败(高并发或JDK6以下版本)

静态内部类单例模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/**
 * 静态内部类单例模式
 * Created by hp1 on 2016/3/4.
 */
public class Singleton {
    private Singleton() {
    }
    /**
     * 获取实例
     * @return
     */
    public static Singleton getInstance() {
        return SingletonHolder.instance;
    }
    /**
     * 静态内部类
     */
    private static class SingletonHolder {
        private static final Singleton instance=new Singleton();
    }
}

优点

• 第一次加载Singleton类并不会初始化instance，只有在第一次调用getInstance
  方法时才会导致instance被初始化(延迟加载)。这种方式不仅能够确保线程安全，也能够保证单例对象的唯一性(利用Classloader的特性)，同时也延迟了单例的实例化，所以这是推荐使用的单例模式实现方式。

枚举式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/**
 * 枚举单例
 * Created by hp1 on 2016/3/4.
 */
public enum SingletonEnum {
    /**
     * 实例
     */
    INSTANCE;
    public void doSomething() {
        System.out.println("do sth...");
    }
    
}

枚举单例的优点

• 枚举在java中与普通的类是一样的，不仅能够拥有字段，还能够
  有自己的方法。最重要的是默认枚举实例的创建时线程安全的，并且在任何
  情况下它都是一个单例。

个人理解

• 由于Android官方在关于管理应用内存方面给出的建议
  

• 言外之意就是Enum在Android中内存占用比较高，所以不建议使用。

• 这里推荐使用静态内部类单例模式

总结

不管以哪种方式实现单例模式，它们的核心都是将构造函数私有化，并且通过静态方法获取一个唯一的实例，在这个获取的过程中必须保证线程安全、防止反序列化导致的重新生成实例对象等问题。选择哪种实现方式取决于项目本身，如是否复杂的并发环境，JDK版本是否过低、单例对象的资源消耗等。

——《Android源码设计模式解析与实战》