UTAD/UT

• Spring的反面 UPAT是Spring的反面
• UTAD 在刺穿阻力时，有成交量的上升，就是一种很好的UTAD

越快速回来（价差宽），成交量很大，越看空
其分析其实和Spring是一样的。
只不过Spring是想下为努力失败
UTAP是想上为努力失败

1. 供给分析的元素（很重要）

• 价差
  K线最高价和最低价之间的幅度，反映运动的难易程度和结果；宽的话结果好些。
  跳空的是前有个的收盘。

• 成交量
  单位时间成交的买盘或卖盘数量，反映买盘或卖盘付出的力量；

• k线摆动
  价格如何从开盘运动到收盘结束；K线的日内摆动；

• 收盘价
  收盘价的变动，揭示了对应买盘或者卖盘所取得的成果

• 需求
  买盘的力量

• 供应
  卖盘的力量

• 供求关系
  买盘力量和卖盘力量之间的关系

威科夫不对一根一根K线做分析，而是对波动作分析。每一波每一波的需求与供应。

1.1 价差分析总则（重要）

1. 价差增加
   价格行进中，阻力较小
   例如：在收盘价较高时

   • 供应下降，需求增加
   • 供应不变，需求增加
   • 供应上升，需求上升的更多

2. 价差减少
   价格行进中有一些阻力

3. 平均价差
   表明正常的趋势或者正常的价格行进

1.2 成交量分析总则（重要）

1. 一般规则
   成交量表明需求和供应的质量，但通常我们观察成交量时，更倾向于它代表着的供应的出现或者缺乏，供应是第一位的，其次才是需求

2. 成交量的增加
   代表着支撑价格运动的力量在增加，或者供求即将改变的迹象，或者只是供应出现的迹象

3. 高量
   通常表明供应的出现，如果价格想要继续上涨，那么就必须吸收掉这些供应。要么是CO吸收，要么被散户买走

4. 极高量
   通常是BC

5. 成交量极少
   支撑价格运动的力量在减少，或者供求其中一方在减少，或者只是供应减少的证据。

6.低量
支撑价格运动的力量很小，或者只有很少的供应

特别说明
成交量不代表供应，也不代表需求。代表成交的数目。成交是供应大，还是需求大，要结合K线所取得的结果。

1.3 成交量分析情况（重要）

上涨市场，价差增加

1. 成交量增加
   价差增加，成交量增加，需求增加，健康的价格向上运动
   但如果是极高量，可能是BC

2. 成交量极少
   价差增加，成交量较少，轻松反弹
   或者需求减少，容易下跌

3. 平均成交量
   正常的价格向上运动
   但是成交量应该跟上价差的变化

上涨市场，价差减少

1. 成交量增加
   价差减少，很可能有高质量的供应进入，尝试向下反转价格运动

2. 成交量减少
   价差减少，很可能需求耗尽，容易产生回落

3. 平均成交量
   价格运动减速，遇到一些供应，指示价差减少

下跌市场，价差增加

1. 成交量增加
   供应增加，健康的价格向下运动
   如果是极高量，可能是SC

2. 成交量减少
   轻松下跌 或者 有供应减少，容易引发反弹

3. 平均成交量
   正常的价格向下运动
   但是成交量应该要跟上价差的变化

下跌市场，价差减少

1. 成交量增加
   可能有高质量的需求进入，尝试向上反转价格运动

2. 成交量减少
   供应耗尽，容易引发反弹

3. 平均成交量
   价格运动减速，遇到一些需求

1. 行为，反应和测试

行为：通常有高波动率，宽价差，高成交量
反应：对前面行为的反应，价差，成交量
测试：对行为的测试，成交量，低点

• 描述动作的因素
  成交量（努力），价差（结果），位置（结果）

• 行为理解

• 反应理解

• 测试理解
  测试最好是更高的地点，并且成交量是低的。如果成交量较大，并且没有下跌到更地点，那么说明供应较大且需求也较大，那么就会进入震荡区，需要进行二次测试。

• 前后对比
  通过前后的行为比较，前后反应程度比较，然后是前后测试有效度比较。

• Spring示例
  
  左侧 向下刺穿支撑
  右侧 Reaction： 反弹
  Test： 再次回落测试供应

2. Spring的买入点（说实话这里不是很理解）

• NS(NO Supply)（不是好的买点）
  不好放止损。因为在支撑位置时，很可能是无供应，也无需求，价格的上涨，是需要需求的。很多情况下是阴跌。所以最好是买在需求柱的地方。交易成本较大。

• GBD（更好的买入点）
  需求柱的收盘位置进，止损放在需求柱底部。

3. 趋势线工具

支撑：需求战胜供应的区域
阻力：供应战胜需求
趋势：
趋势通道
步幅：在上升通道里，步幅会越来越小，从而上升趋势减速
1/2回落：回落要在1/2之上

供应线与需求线
阻力线与支撑线

4. 思考路径

v,p-->s,d-->co-->direction
量价推断--》供应与需求--》推断CO目的--》市场方向

1. 练习方法

practice 模拟练习
case study 案例分享

paper trade 历史纸上交易（在历史走势里一屏一屏过）
actual trade 实盘

2. 吸筹备忘录

2.1 A段与B段

• A段和B段的意图

  • A:停止行为
  • B:测试供应，产生需求，换手，从公众手里换手到CM手里

• 威科夫原理

  • A:PS,SC,AR,ST
  • B:UA,ST,ST as SOW

• 初次支撑PS

  • 停止下跌的第一次尝试
  • 尝试总是失败，价格会继续走低到SC

• SC卖盘高潮

  • 宽价差/高的成交量
  • 例外1 持续走低的SC运动，供应减少
  • 例外2 SC行为可能持续一段时间，其最低的k线未必有最高的成交量
  • SC的低点定义了TR的支撑线

• 自动反弹AR

  • 供应的耗尽产生了从SC低点的初始反弹，随后由空头回补来继续推高价格
  • AR的高点定义了TR的阻力线

• 二次测试ST

  • ST可以是SC和AR的一个局部事件（可以理解成AR中的一个ST，还会反弹跟高，只是一个中产休息）
  • ST可以做为一个更重要的确认
  • ST可以是一个小型的TR,整个小型TR作为一个测试行为
  • B中的一个产生更低的点的ST,可以理解为一个SOW,它指示出吸筹需要进行更多的测试，或者进行更久的盘整。（也就是这个ST也是需要被测试的）
    

• 上冲回落型的行为UA

  • UA为了与派发中的UT进行区分
  • 价格短暂的离开交易区间的阻力，又快速地回到阻力之下，意味着向上的突破失败，也意味着供应的出现

2.2 C段与D段

• C和D的意图

  • C：对TR支撑的最后测试（我们一般交易C段）
  • D：TR中的上涨，展现摆脱阻力的能力，并测试阻力已经转换成支撑

• 威科夫原理

  • C:Spring,TSO,LPS
  • D:SOS,LPS,JOC,BU

• Spring

  • 测试[A]与[B]的低点
  • 可能成功，也可能失败
  • 三种类型 Spring1,Spring2,Spring3
  • Spring与Spring的测试，等同于一个LPS

• 终极震仓TSO

  • 宽价差和高成量的陡峭下跌
  • 大幅打破TR支撑
  • 快速的修复并回到TR支撑之上（必须）
  • 在交易前需要测试

• 强势信号SOS

  • 通常情况下，价格以宽价差和增加的成交量运动到TR的高位，甚至TR的阻力之上，指示出潜在的需求的增加
  • 它可以是跳过小溪的第N次尝试，但却是最成功的一次
  • 产生HH,HL(更高的高点，更高的低点)
  • 次要的SOS可以发生在[B]中，主要SOS则发生在[D]中

• 最后的支撑点LPS

  • 形成HL
  • 低的成交量，窄的价差，或者减少的成家量和缩窄的价差
  • 价格无法走的更低，并且之后不会在回到这个点，LPS本身可以被认为是一个强势信号
  • D中可以有多个LPS

• 回测小溪BU

  • 上涨趋势之前，最后的较大回落
  • 价格无法回到原有阻力之下，或者只能暂时地回到原阻力之下
  • 回落幅度小于之前反弹的1/2最佳（即JOC那段的一半以上）

3. JOC

注意点

• 展现突破阻力的能力
• 阻力区是一个区间，并且有厚度，是TR的最高点与次高点之间的区域
• 需要突破TR的最高点（一定要过最高点，才是完全突破了）
• 若果不是在突破最高点，交易的胜率很低

突破有效性

• 传统的判断方法

  • Margin 突破幅度1-3%以上（依赖于品种）
  • Close 收盘价在阻力区之上
  • Time 两根K线在阻力区上
  • Volume 最好适当放量
  • Mixed Method 混合以上方法

• 突破可以被预测吗

  • 不要买突破的原因分析？
    如果是假突破，胜率就会降低
    如果有回测，盈亏比会降低，而且回测较大时，会头寸很容易被打掉

  • 买LPS还是买BU的比较 ？
    LPS:胜率低，盈亏较高
    BU:高胜率，盈亏比较低

4. Spring

一个潜在spring是对一个支撑水平的刺穿。即向下突破失败。

• 为什么用"潜在"?

  • 支撑水平的重要程度不同
    意思是要有足够的cause。spring通过向下突破失败去测试水平支撑

  • 刺穿的行为
    价差，成交量

• Spring分类

  • 1类
    
    不是真正的Spring,是SOW

  • 2类
    
    稍微较高的成交量

  • 3类
    
    低成交量

  • 后续变化
    
    2-->3,2类转到3类，就是对2类的测试，是很好的交易时机
    
    2-->1,2类有可能会转换成1，特别是在下跌趋势中

  • Spring的质量

  • 对支撑水平的刺穿深度（刺穿比较浅，收回比较快）

  • 向潜在spring位置运动时，和进入spring位置时的价差（价差小）

  • 向潜在spring位置运动时，和进入spring位置时的成交量（成交量小）

  1. 成交量合适标准：前期横盘区的平均成交量的1/2,前期横盘区的平均价差1/2
  2. Spring也可以是一个区域，并不完全是一个带下影的k线。

• dispatch_queue
  
  从这张图中能看出，我们创建的dispatch_queue_t实际上是统一由GCD Thread Pool来进行统一管理。他会根据多线程队列设置的Priority，来统一管理执行的优先级。

• dispatch_async
  dispatch_async的流程是用链表保存所有提交的block，然后在底层线程池中，依次取出block并执行；而向主队列提交block则会向主线程的Runloop发送消息并唤醒Runloop，接着会在回调函数中取出block并执行。主线程，专门有个存储queue里需要执行的代码段。当执行到主线程的一个循环玩了后，会从这些队列里拿任务一个一个去执行。

当我们调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 向主线程的 RunLoop 发送消息，RunLoop会被唤醒，并从消息中取得这个 block，并在回调__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 里执行这个 block

• dispatch_sync

理解dispathch_sync 在执行的时候,会阻塞 上下文 任务的执行.

造成死锁的情况
在主线程里执行dispatch_sync(dispatch_main_queue,block);即，上下文环境是主线程，要将任务放到主线程里执行，而且是同步的。dispatch_sync会阻塞当前主线程，又要在主线程里执行block，所以会造成死锁。造成死锁的原因是“当前执行的上下文环境”与“即将要执行的任务也是这个环境"且是同步执行。同步执行不会开启新的线程，会在当前线程里执行。（所以同步执行将任务放到哪种队列没有关系，任务会在当前线程执行）哈哈哈。这个三个条件到达时就会死锁。终于弄懂了。

同步，异步的概念始终与当前执行代码的上下文线程有关系。同步就是讲当前放到其他队列里的任务拿到当前线程执行，执行完后然后返回，继续执行，执行完后返回，继续执行下面的代码。（也就说可以把加到其他队列里的任务拿到当前上下文的线程里去执行）。

• dispatch_semaphore

• dispatch_source
  dispatch_source是BSD系统内核kqueue的包装，kqueue() 生成一个内核事件队列，返回该队列的文件描述符。kqueue是在XNU内核中发生各种事件时，在应用程序编程方执行处理的技术。操作dispatch_source实际上就是，通过操作这个 kqueue，进而对内核事件的处理。（哈哈，这个终于可以解释通了）相当于可以监听内核的事件，然后给一个回调，并将回调的代码在指定的线程里面执行。

  特别说明：
  这里的dispatch_source与runloop里的source还是有区别的。dispatch_source是 内核事件，runloop的source是端口事件（线程通信的方式），timer事件源（runloop的Timer依赖于线程的runloop）。

重要理解
dispatch_asyn与dispatch_syn，dispatch_queue,任务队列是任务列，只管装任务。至于是在当前上下文线程，还是开启新的线程执行，是由同步还是异步决定的。同步不用新的线程执行，异步有创建新线程的权利。

iOS事件传递的需要思考的问题

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {}
最终将这个fitView给了谁?

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event { }
到底是谁在调用的?

经研究，最终将这个view给了UIWindow,UIWindow调用这个fitView得touchBegan方法。

整个事件首先在Application的事件队列里，然后通过UIWindow在view层级里是先从最后面的子view进行hitTest;找到fitView,然后将touch事件派发给它处理。或者view里有手势会先派发事件给手势处理。手势识别后会取消派发给fitView，UIWindow会调用fitView的touchBegan方法。后面的响应链条上touchBegan会被Pre-responder调用。若果不重写touchBegan，pre-responder会默认递归回溯调用。

• 手势识别的内部调用机制?

• TouchBegan，UIControl，手势识别关系?

iOS 布局

Frame布局

layoutSubviews，不手动调用
layoutIFNeeded()，在同一个循环里如果需要更新就执行layoutSubviews，然后放回。也就是在layoutIFNeeded里会做判定并且调用本类的layoutSubviews；

setNeedsLayout()，只要告诉标记需要更新界面，在下一个循环里会有一个检测是否需要更新UI布局的一个点来执行layoutSubviews，

• drawRect 这是一个被重复调用的函数。重复调用会造成内存问题。

自动布局

1. 更新约束
2. 布局阶段
3. 显示

updateConstraints()，不手动调用和layoutSubviews类似
updateConstraintsIfNeeded()， 和layoutIfNeeded类似
setNeedsUpdateConstraints()，和setNeedsLayout类似

intrinsicContentSize 属性，根据内容自然得到的属性。

视图布局更新与runloop的关系

调用网络API
页面展示
数据的本地持久化
动态部署方案

那么需要解决的问题

• 网络层设计方案？
  设计网络层需要考虑哪些问题？
  网络层的优化从哪里入手？

• 页面展示层设计方案？
  页面的展示，调用，组织都有哪些设计方案

• 本地持久化的设计方案有哪些？

• 要实现动态部署，都有哪些方案

软件架构的思路

1. 要解决的问题（问题是什么）
2. 问题分类，用不同的模块解决不同类型的问题
3. 搞清楚各个问题之间的依赖关系
4. 推演预测未来可能的走向
5. 先实现基础模块，在用基础模块堆积整个架构

View层的组织和调用方案

架构模式

1. 如何划分MVC
   M,V,C
   在服务端的开发中V主要是指浏览器。
   在iOS开发中V主要是指self.view的容器

2. MVCS
   将C的数据储存部分抽离出来，交给另一个对象去做，即store

3. MVVM
   将C的数据处理部分抽离出来，交给viewModel处理。即vm
   而C负责View与ViewModel之间的绑定，以及UI逻辑处理

4. VIPER
   (不懂)

总结：这些架构都是在MVC的基础上拆分出来的。天下架构出MVC，拆分方式的不同衍生出不同的架构。

是否应该使用BaseViewController？

尽可能不使用继承而是使用组合或者面向切面编程的AOP来替代。

• 好处
• 业务方集成成本小。（因为如果用了继承会导致，在集成到其他APP里时，需要依赖很多东西，打动干戈）
• 新用户上手接收成本也减少了

• 架构维护成本低

• 目标

• 业务方可以不用继承的方法，然后框架能够做到ViewController的统一配置。

• 业务方即使脱离框架环境，

解耦定义

代码里不相互依赖，依赖分两种，单向依赖，双向依赖。

组件化的定义

让高层模块单向依赖低层模块，业务模块之间完全解耦

解耦的几种方式

1. 代理
2. block
3. 通知
4. kvo

组件通信实现

1. runtime反射机制在Mediator里的实现，在通过对Mediator的category进行接口分离(本质是runtime的反射机制)
2. 通过在Mediator里注册block,一般是进行url与block的映射（本质是存block）
3. 同过在Mediator里注册protocal（本质是存class）

总结下：业务层可以依赖基础库，但业务层要相互不依赖。就需要依赖一个可以连接两个业务层的东西Mediator。为了防止业务层又与Mediator相互依赖。这里只允许业务层单向依赖Mediator。其实解耦可以是任意两个类之间实现单向依赖。只是将解耦应用到了对Mediator的单向依赖上。

组合与继承的选择

组合与继承都可以实现代码的复用
1. 除非两个类之间是"is-a"的关系，否则不要轻易使用继承
2. 两个类之间是has a的关系时，最好用组合

TimerPofile

可以查看应用程序的那个方法耗时比较长，然后针对性优化

复杂度分析

时间复杂度