关于git的几个问题

git merge和git rebase区别：

这个文件写的很清楚
http://git-scm.com/book/zh/v1/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88

git fetch和git pull区别：

其实git pull相当于：git fetch , git merge
http://stackoverflow.com/questions/292357/what-are-the-differences-between-git-pull-and-git-fetch

到底是应该使用git pull 还是 git pull —rebase ?

我个人赞同使用git pull —rebase,因为如果多个人开发并且经常pull的话，就会出现很多：Merge branch 'aaa' of git.xxx.xxx/xxx/xxx into aaa这样的commit。
就像这里的讨论：https://ruby-china.org/topics/112

我们使用的工作流【集中式工作流】：

http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E5%88%86%E5%B8%83%E5%BC%8F%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B
通常，集中式工作流程使用的都是单点协作模型。一个存放代码仓库的中心服务器，可以接受所有开发者提交的代码。所有的开发者都是普通的节点，作为中心集线器的消费者，平时的工作就是和中心仓库同步数据（见图 5-1）。

workflow.png

如果两个开发者从中心仓库克隆代码下来，同时作了一些修订，那么只有第一个开发者可以顺利地把数据推送到共享服务器。第二个开发者在提交他的修订之前，必须先下载合并服务器上的数据，解决冲突之后才能推送数据到共享服务器上。在 Git 中这么用也决无问题，这就好比是在用 Subversion（或其他 CVCS）一样，可以很好地工作。
如果你的团队不是很大，或者大家都已经习惯了使用集中式工作流程，完全可以采用这种简单的模式。只需要配置好一台中心服务器，并给每个人推送数据的权限，就可以开展工作了。但如果提交代码时有冲突， Git 根本就不会让用户覆盖他人代码，它直接驳回第二个人的提交操作。这就等于告诉提交者，你所作的修订无法通过快进（fast-forward）来合并，你必须先拉取最新数据下来，手工解决冲突合并后，才能继续推送新的提交。 绝大多数人都熟悉和了解这种模式的工作方式，所以使用也非常广泛。

使用monkey对app进行压力测试

其实monkey压力测试也不需要怎么去配置，只是有一些参数。

  • 使用adb shell来连接一个模拟器或者真机。
    直接adb shell

  • 使用monkey -p packagename -v times 随机生成times个event来测试packagename的default界面。

    比如：monkey -p com.tencent.mobileqq -v 5000
    对qq来进行压力测试。

    或者monkey -p packagename —pct-touch 100 -v times。-v times是一定要带上的。

这些命令都简单，但是我现在想要获取到qq的包名。

使用命令pm list packages -f就可以获取到设备上所有已经安装的包名。
这样就获取到qq的包名为：com.tencent.mobileqq
这样我就可以使用monkey来玩qq了。

本来想用这种方式来测试一下是否可以用monkey来抢微信红包，
然后我就运行了monkey -p com.tencent.mm --pct-touch 100 -v 2000结果加了好多好友而且还没有发送成功。。。

关于如何解决一个问题

一定要在搜索列表页面去筛选！包括看那些小的字。

在网页列表里去筛选比进入网页内容然后发现他不是这个东西花的时间要少得多。
比如需要搜索windows下管理多个git ssh的问题，那么一定要注意关键字多个账号，无关的网页不要进，不然可能浪费大多数时间。

进入网页之后要学会使用查找来找到自己想要的东西。

可能打开的网页很长，这个时候用ctr + f 比自己的肉眼看要快很多。

一定要有一个自己处理这个事情的解决方案、步骤。

解决一个问题不是看谁会搜索，在任何想到准确的解决方案之前的搜索都是浪费时间。

解决一个问题一定要一针见血。请直面问题！！！

我发现我有一个毛病，解决一个问题总是喜欢围绕着问题去转。比如需要写一markdown格式的博客，然后我就找了整个markdown语法的文章来读，但是我要知道我想要做的是写博客啊，不是学习markdown语法。
可能这个是很轻的问题，但是有很多时候确实我围绕问题转的毛病太多，需要解决的问题是这个，但是我总是在研究一些相关的东西。
而不是去直面那个问题。

在Android中使用unittest

在Android中使用unittest，不用再运行整个工程，只是测试某一些类是否正确运行。

步骤：

  1. 设置Android studio，

Enable the unit testing feature in Settings > Gradle > Experimental.

  1. 在Android studio左下角，有一个Build Variantes, 最上方选择Unit Tests.


选择Unit Tests

  1. 愉快的写test就可以了

hashmap的几个点

总结：

  • 解决碰撞是使用拉链法

  • 为什么数组大小最好是2的整数次方，因为hashmap的hash函数并不是对数组大小取余，因为取余比较耗时，而是使用数组大小减1和hash值做与运算，如果数组大小不是2的整数次方，那么数组大小减1的二进制的最后一位就是0了，和key的hash值取与运算最后一位一直是0，所以有很大的空间浪费。

  • 由于hashmap扩容需要重新计算所有元素的位置所以非常耗时，所以我们在知道hashmap大小的时候可以指定其大小，但是由于factory的存在，我们虽然知道指定2的整数次方，factory * 设定的数组大小 = 需要的数组大小，比如我们需要1000，不是设置为1024就好了，由于factory = 0.75，所以我们需要把数组大小设为 1000 / 0.75 然后再是2的整数次方，就是2048

Activity的几种启动方式

总结

standard：

如果需要启动一个Activity，则会重新生成一个activity实例

sigleTop:

如果需要启动的Activity刚刚好在栈顶，则不会再去创建Activity的实例,否则，创建Activity实例

sigleTask

如果在同一个应用中启动Activity，如果栈中没有，则创建新实例；如果有则直接杀死之上的所有activity使需要启动的activity成为栈顶
如果是在别的应用中启动该activity则会重新创建一个栈

sigleInstance:

只有一个实例并且单独运行在一个task中，这个task只有这个实例，不允许有别的activity存在。

参考资料：

http://blog.csdn.net/shinay/article/details/7898492

行为型模式

策略模式（Strategy Pattern)

  1. 实现原理：其用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替
  2. 优点：将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。

迭代器模式（Iterator Pattern)

  1. 实现原理：提供一种方法访问一个容器（container）对象中的各个元素，而又不暴露该对象的内部细节。
  2. 优点：它可以让使用者透过特定的接口巡访容器中的每一个元素而不用了解底层的实现。

模板方法模式（Template Method Pattern)

  1. 实现原理：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。这里的算法的结构，可以理解为你根据需求设计出来的业务流程。特定的步骤就是指那些可能在内容上存在变数的环节。
  2. 优点：模板方法模式也是为了巧妙解决变化对系统带来的影响而设计的。使用模板方法使系统扩展性增强，最小化了变化对系统的影响。

中介者模式（Mediator Pattern)

  1. 实现原理：用一个中介者对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立的改变他们之间的交互。
  2. 优点：它将各Colleague解耦。Mediator有利于各Colleague间的松耦合，你可以独立的改变和复用各Colleague类和Mediator类。 它简化了对象协议用Mediator和各Colleague间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。

访问者模式（Visitor Pattern)

  1. 实现原理：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。（gof）
    每一个元素实现visitable接口的accept方法接受一个visitor的实例对象，并且使用这个实例对象的visit方法来把自己的引用传递过去，

    而真正调用时在concreteVisitor里面
  2. 优点：
    类图

职责链模式（Chain of Responsibility)

  1. 实现原理：通过给一个以上对象处理请求的机会来避免请求的发送者和接收者的耦合。链接接收对象并在链中传递请求直到有对象处理它。

    我的理解：在每一个concreteHandler里面加入另外一个concreteHandler的对象的引用，从而实现处理的传递。
  2. 优点：避免请求的发送者和接收者之间的耦合关系。

状态模式（State Pattern)

  1. 实现原理：状态模式的意图是，允许一个对象在其内部状改变时改变它的行为。看起来就像是改变了它的类一样

    个人理解：这个跟职责链模式有很大的相似之处，职责链模式是他的处理的对象是排成一个链子，并且对象必须要把这个链子走完；但是状态模式的下一个引用就可能没有排成一个链子状，而且很多时候也不需要走完所有的状态，他指示把if else变成类之间的转换。
  2. 优点：主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同的一系列类当中，可以把复杂的逻辑判断简单化。

解释器模式（Interpreter Pattern)

  1. 实现原理：定义语言的文法，并且建立一个解释器来解释该语言中的句子。它属于类的行为模式。这里的语言意思是使用规定格式和语法的代码。
    • 抽象表达式角色(AbstractExpression): 声明一个抽象的解释操作,这个接口为所有具体表达式角色都要实现的.
    • 终结符表达式角色(TerminalExpression): 实现与文法中的元素相关联的解释操作,通常一个解释器模式中只有一个终结符表达式,但有多个实例对应不同的终结符.
      终结符就是语言中用到的基本元素,一般不能再被分解,如: x -> xa, 这里a是终结符，因为没有别的规则可以把a变成别的符号，不过x可以变成别的符号，所以x是非终结符.
    • 非终结符表达式角色(NonterminalExpression): 文法中的每条规则对应于一个非终结表达式, 非终结表达式根据逻辑的复杂程度而增加,原则上每个文法规则都对应一个非终结符表达式.
    • 环境角色(Context): 包含解释器之外的一些全局信息.
  2. 应用环境：
    如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。而且当文法简单、效率不是关键问题的时候效果最好。

观察者模式（Observer Pattern）

  1. 实现原理：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。也可以只通知部分。（gof）
    • 抽象主题(Subject)角色：抽象主题角色把所有对观察者对象的引用保存在一个聚集（比如ArrayList对象）里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，抽象主题角色又叫做抽象被观察者(Observable)角色.
    • 具体主题(ConcreteSubject)角色：将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色.
    • 抽象观察者(Observer)角色：为所有的具体观察者定义一个接口，在得到主题的通知时更新自己，这个接口叫做更新接口.
    • 具体观察者(ConcreteObserver)角色：存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态 像协调。如果需要，具体观察者角色可以保持一个指向具体主题对象的引用.
      在观察者模式中，又分为推模型和拉模型两种方式。
    • 推模型:主题对象向观察者推送主题的详细信息，不管观察者是否需要，推送的信息通常是主题对象的全部或部分数据.
    • 拉模型:主题对象在通知观察者的时候，只传递少量信息。如果观察者需要更具体的信息，由观察者主动到主题对象中获取，相当于是观察者从主题对象中拉数据。一般这种模型的实现中，会把主题对象自身通过update()方法传递给观察者，这样在观察者需要获取数据的时候，就可以通过这个引用来获取了。
  2. 优点：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

命令模式（Command Pattern)

  1. 实现原理：

    命令模式涉及到五个角色，它们分别是：
    • 客户端(Client)角色：创建一个具体命令(ConcreteCommand)对象并确定其接收者。
    • 命令(Command)角色：声明了一个给所有具体命令类的抽象接口。
    • 具体命令(ConcreteCommand)角色：定义一个接收者和行为之间的弱耦合；实现execute()方法，负责调用接收者的相应操作。execute()方法通常叫做执行方法。
    • 请求者(Invoker)角色：负责调用命令对象执行请求，相关的方法叫做行动方法。
    • 接收者(Receiver)角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。
  2. 优点：用于“行为请求者”与“行为实现者”解耦，可实现二者之间的松耦合，以便适应变化。分离变化与不变的因素。

结构型模式

适配器模式（Adapter Pattern)：

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

适配器模式有类适配器和对象适配器两种不同的类型：

  • 类适配器：通过继承的方式来调用已有的接口来实现转换接口。

  • 对象适配器：通过对象引用的方式来调用已有的接口来实现接口的转换

门面模式（Facade Pattern)：

  1. 实现原理：它为子系统中的一组接口提供一个统一的高层接口，使得子系统更容易使用。也就是将众多的子接口或者子模 块包装一下，让客户更方便地调用。

  2. 优点：

    • 松散耦合：门面模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。
    • 简单易用：门面模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟门面类交互就可以了.

    • 更好的划分访问层次：通过合理使用Facade，可以帮助我们更好地划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中，这样既方便客户端使用，也很好地隐藏了内部的细节。

    • Facade:这个外观类为子系统中Packages 1、2、3提供一个共同的对外接口

    • Clients:客户对象通过一个外观接口读写子系统中各接口的数据资源。
    • Packages:客户可以通过外观接口读取的内部库。

描述门面模式的例子：

代理模式（Proxy pattern)：

  1. 实现原理：为其他对象提供一种代理以控制对这个对象的访问。
  2. 优点：可以在实际调用的对象和客户端之间添加一些额外的操作。

分为静态代理和动态代理：

  • 静态代理：

  • 动态代理：

合成模式（Composite Pattern)：

  1. 实现原理：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式可以使客户端将单纯元素与复合元素同等看待。合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式可以使客户端将单纯元素与复合元素同等看待。
  2. 优点：合成模式使得客户端把一个个单独的成分对象和由它们复合而成的合成对象同等看待。

享元模式（Flyweight Pattern)：

  1. 实现原理：
  2. 优点：享元模式以共享的方式高效地支持大量的细粒度对象。它适合用于当大量物件只是重复因而导致无法令人接受的使用大量内存。

装饰着模式（Decorator Pattern)：

  1. 实现原理：是面向对象编程领域中，一种动态地往一个类中添加新的行为的设计模式。
  2. 优点：就功能而言，修饰模式相比生成子类更为灵活，这样可以给某个对象而不是整个类添加一些功能。

7.桥模式（Bridge Pattern)：

  1. 实现原理：桥模式就是把抽象部分和它的实现部分分离开来，让两者可独立变化。(或者说：把事物对象和其具体行为、具体特征分离开来，使它们可以各自独立的变化。事物对象仅是一个抽象的概念。如“圆形”、“三角形”归于抽象的“形状”之下，而“画圆”、“画三角”归于实现行为的“画图”类之下，然后由“形状”调用“画图”)

    组成：
    • 抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
    • 修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
    • 实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。
    • 具体实现化(Concrete Implementor)角色：这个角色给出实现接口的具体实现。
  2. 优点：桥模式就是把抽象部分和它的实现部分分离开来，让两者可独立变化。分离就把实现部分从它要实现的抽象部分独立出来，自我封装成对象。

建造型设计模式

简单工厂：

它的实质是由一个工厂类根据传入的参 数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。将所有的类的创建放到一个类中。

工厂方法：

工厂方法模式是为了克服简单工厂模式的缺点（主要是为了满足OCP）而设计出来的。简单工厂模式的工厂类随着产品类的增加需要增加很多方法 （或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。工厂方法模式完全满足OCP，即它有非常良好的扩展性。

抽象工厂：

克服工厂方法增长速度太快的弊端。将同类产品抽象成一个工厂，从而减少工厂类的数量。

单例模式：

可以使创建的对象只有一个，从而实现线程安全或保证数据单一。但是实现线程安全的单例需要在创建对象的时候加上synchronized代码块。

原型模式：

原型模式被用在频繁调用且极其相似的对象上。原型模式会克隆对象并设置改变后的属性。原型模式消耗的资源较少。

创建者模式：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。为何使用建造者模式是为了将构建复杂对象的过程和它的部件解耦。注意：是解耦过程和部件。
因为一个复杂的对象，不但有很多大量组成部分，如汽车，有很多部件：车轮、方向盘、发动机，还有各种小零件等等，部件很多，但远不止这些，如何将这些部件装配成一辆汽车，这个装配过程也很复杂(需要很好的组装技术)，Builder模式就是为了将部件和组装过程分开。

design_pattern

设计模式的总结

设计模式的分类：

  • 结构型模式(Structural Patterns)

    1. 适配器模式（Adapter Pattern)
    2. 门面模式（Facade Pattern)
    3. 代理模式（Proxy pattern)
    4. 合成模式（Composite Pattern)
    5. 享元模式（Flyweight Pattern)
    6. 装饰着模式（Decorator Pattern)
    7. 桥模式（Bridge Pattern)

  • 行为型模式（Behavioral Patterns)

    1. 策略模式（Strategy Pattern)
    2. 迭代器模式（Iterator Pattern)
    3. 模板方法模式（Template Method Pattern)
    4. 中介者模式（Mediator Pattern)
    5. 访问者模式（Visitor Pattern)
    6. 职责链模式（Chain of Responsibility)
    7. 状态模式（State Pattern)
    8. 解释器模式（Interpreter Pattern)
    9. 观察者模式（Observer Pattern)
    10. 命令模式（Command Pattern)
    11. 备忘录模式（Memento Pattern)

design pattern


本站总访问量次,本站访客数人次,本文总阅读量次