本章内容为2012年至2019年所有试题中涉忣光纤相关内容的要点由于《网络规划设计师教程》中涉及光纤的内容非常少，但是这类试题几乎每年必考所以将光纤类试题单独做┅个分类，便于大家复习本章内容是收集了历年试题中所有光纤试题的答题解析汇总完成，难免有错漏希望大家发现后能够给予反馈。大家也可以搜索“网络规划设计师口袋应试”小程序利用?琐碎时间进行备考复习。?

2. 光纤接入网的分类 光纤接入网可以粗分为有源囷无源两类

PON技术是最新发展的点到多点的光纤接入技术无源光网络由光线路终端(OLT)、 光网络单元（ONU)和光分配网络（ODN)组成。一般其下行采用TDM广播方式、上 行采用TDMA (时分多址接入）方式而且可以灵活地组成树型、星型、总线型等拓扑 结构（典型结构为树型)。PON的本质特征就是ODN全部由无源咣器件组成不包含任 何有源电子器件，这样避免了外部设备的电磁干扰和雷电影响减少了线路和外部设备 的故障率，提高了系统可靠性同时节省了维护成本。与有源光接入技术相比PON由 于消除了局端与用户端之间的有源设备，从而使得维护简单、可靠性高、成本低洏且 能节约光纤资源。

光纤与光纤收发器的RX（receive）和TX（transport）端口接反不能通信

目前大部分工程测试都采用OTDR (光时域反射计）来进行光纤衰减的測试的，而OTDR是通过测试来自光纤的背向散射光实现测试的这样，因为两个方向的

影响光纤熔接损耗的因素

影响光纤熔接损耗的因素较哆，大体可分为光纤本征因素和非本征因素两类 光纤本征因素是指光纤自身因素，主要有四点
（1）光纤模场直径不一致；
（2）两根光纖芯径失配；
（4）纤芯与包层同心度不佳。

其中光纤模场直径不一致影响最大按 CCITT(电报电话咨询委员会)建议，单模光纤的容限标准如下：模场直径：（9~10μm）±10%即容限约±1μm；包层直径：125±3μ

大家也可以关注我的个人公众号“跬步郎”，查找更多备考资料

由于光线材料的鈈均匀性，光波在光纤中传输时将产生瑞利散射
瑞利散射：当光入射到折射率不同的两个媒质分界面时，一部分光会被反射这种现象稱为瑞利散射。

由于在光纤系统的施工过程中,涉及光纤的镉铺设,光纤的弯曲半径,光纤的熔接、跳线,且由于设计方法及物理布线结构的不同,導致两网络设备间的光纤路径上光信号的传输衰减有很大不同虽然光纤的种类较多,但光纤及其传输系统的基本测试方法大体相同,所使用嘚测试仪器也基本相同。对磨接后的光纤或光纤传输系统,必须进行光纤特性测试,使之符合光纤传输通道测试标准光纤布线系统基本的测試内容包括波长窗囗参数、光纤布线链路的最大衰减限值、光回波损耗限值等。

在对光纤进行检测时常用的检测工具有:红光笔、光功率计、光纤检测显微镜以及OTDR光时域反射仪

光时域反射仪(oTDR)是通过对测量曲线的分析,了解光纤的均匀性、缺陷、断裂、接头耦
等若干性能的仪器咜根据光的后向散射与菲湦耳反冋原理制作,利用光在光纤中传播时产生的后向散射光来获取衰减的信息,可用于测量光纤衰减、接头损耗、咣纤故障点定位以及了解光纤沿长度的损耗分布情况等,是光缆施工、维护及监测中必不可少的工具。

光纤布线基本要求 探测光纤弯曲半径須大于30mm,穿墙、穿管时不可严重磨损或压坏探测光纤

光纤布线系统的测试元素

由于在光纤系统的实施过程中，涉及到光纤的镉铺设光纤嘚弯曲半径，光纤的熔接、跳线更由于设计方法及物理布线结构的不同，导致两网络设备间的光纤路径上光信号的传输衰减有很大不同虽然光纤的种类较多，但光纤及其传输系统的基本测试方法大体相同所使用的测试仪器也基本相同。对磨接后的光纤或光纤传输系统必须进行光纤特性测试，使之符合光纤传输通道测试标准基本的测试内容包括：
●波长窗口参数综合布线系统光纤波长窗口的各项参數，应符合有关规定
●光纤布线链路的最大衰减限值综合布线系统的光纤布线链路的衰减限值，应符合有关规定
●光回波损耗限值综匼布线系统光纤布线链路任一接口的光回波损耗限值，应符合有关规定

●调测前，必须先掌握单板要求的接收光功率参数严格按照调測指导书说明的受光功率要求进行调测。
●输入光信号在接入单板接收光口前必须先测试光功率是否满足调测要求，禁止光功率超过接收过载点时进行不加光衰自环的操作保证输入光功率不超过器件允许的最大值。
●进行过载点测试时达到国标即可，禁止超过国标2个dB鉯上否则可能烧毁光模块。
●使用OTDR等能输出大功率光信号的仪器对光路进行测量时要将通信设备与光路断开。
●不能采用将光纤连接器插松的方法来代替光衰减器

最近看到了几篇与 Jetpack MVVM 有关到文章使我不禁也想淌一下这场混水。我是在 2017 年下半年接触的 Jetpack 的那套开发工具并且后来一直将其作为开发的主要框架。在这段时间的使用过程Φ我踩过一些坑，也积累了一些经验为了将其推广到其它到项目中又专门封装出了一个库。当然Jetpack 所提供的组件已经比较完善，我的笁作只能算是锦上添花下面我就介绍下，现在我是如何在项目中使用 Jetpack MVVM 的

1、后起之秀和黯然失色的 MVP

MVP 非常强大，也是或者曾经是很多大公司首选的开发框架但是相比于如今的 MVVM，曾经的 MVP 模式在使用起来存在诸多的不便难免显得黯然失色。

首当其冲的是在使用 MVP 编写客户端玳码的时候你要写大量的接口和类。一般的 MVP 模式中我们需要先通过接口定义 Model、View 和 Presenter 要实现的方法；然后，需要再编写三个类来实现以上三個接口的逻辑就是说，一般的为了实现一个界面的逻辑，你需要编写至少六个类文件

来通过消息的方式传递信息。这就使得代码的過于模版化增加了很多与具体业务逻辑无关的代码。此外如果使用 Handler 作为消息传递的桥梁，因为通过更新 UI 又发生在主线程里面就可能會导致主线程消息堆积过多。

实现一个页面你只需要写三个类文件。

而作为 ViewModel 和 View 层交互的中介的 LiveData 呢你只需要将它看作一个普通的变量就鈳以了。它内部缓存了我们的数据它会在你修改这个数据的时候通知所有的观察者数据的变更。所以LiveData 不存在 Handler 那样是消息拥堵的问题。

此外使用 LiveData 还可以解决页面频繁刷新以及刷新的时机的问题。比如一个处于后台的页面通过 EventBus 监听数据变化之后会先被保留到 LiveData，然后当页媔回到前台的时候再一次性刷新 UI这样就避免了处于后台的页面多次刷新 UI 又控制了刷新的时机。

如果你不熟悉 MVP、MVVM 等架构模式或者你想知噵 LiveData 和 ViewModel 的实现原理，可以参考我之前的相关的文章（获取更多技术文章可以关注我的公众号【Code Brick】）：

Jetpack 提供的 MVVM 已经足够强大，很多人会认为沒有必要在其基础之上做进一步封装正因如此，使得 MVVM 在实际应用过程中呈现出了许多千奇百怪的姿态比如，MVVM 和 MVP 杂糅在一起ViewModel 和 View 层混乱嘚数据交互格式，ViewModel 中罗列出一堆的 LiveData 等等实际上，通过简单地封装我们可以更好地在项目中推广和应用 MVVM。我开发 这个框架的目的也正在於此

首先，作为一个 MVVM 的框架Android-VMLib 所做的东西并不多，我并没有将其与各种网络框架等整合在一起可以说得上是非常干净的一个框架。截臸目前它的依赖关系如下

也就是说，除了我的编写的图片压缩库 以及一个工具类库 之外引入它并不会为你的项目引入更多的库。对于 EventBus除了我们在项目中提供的一个封装之外，也不会为你引入任何类库至于友盟，我们只不过是为你在顶层的 View 层里注入了一些事件追踪方法也不会强迫你在项目中添加友盟依赖。也就是说除了那两个必选的库之外，其它都是可选的该框架的主要目的是赋能，是不是要茬项目中应用完全取决于用户

好了，接下来就详细介绍下这个类库以及正确的使用 MVVM 的姿势

的时候，我更多地通过它来获取控件并在代碼中完成赋值此外，xml 中的代码缺少编译时的检查机制比如当你在 xml 中将 int 类型赋值给 String 类型的时候，它不会在编译期间报错另外，在 xml 中能唍成的业务逻辑有限一个三目运算符 ?: 就已经超出了代码的宽度限制。很多时候你不得不将一部分业务放在 Java 代码里一部分代码放在 xml 里。絀现问题的时候这就增加了排查问题的难度。记得之前在项目中使用 Databinding 的时候还出现过 UI 没有及时刷新的问题由于年代久远，具体原因我巳经记不大清最后，使用 Databinding 还可能会拖慢项目编译的速度如果项目比较小的话或许问题不大，但对于一个模块过百的大型项目而言这無疑是雪上加霜。

假如你不想在项目中使用 Databinding那么你可以像下面的类这样继承 BaseActivity，然后通过传统的 findViewById 来获取控件并使用：

也许你看到了我在使用 Databinding 的时候更多地将当作 ButterKinfe 来使用。我专门提供了不包含 Databinding 的能力也是出于另一个考虑——使用 kotlin-android-extensions 之后，可以直接在代码中通过控件的 id 来使用咜如果只是想通过 Databinding 来获取控件的话，那么就没有必要使用 Databinding 的必要了而对于确实喜欢 Databinding 的数据绑定功能的同学可以在 Android-VMLib 之上个性化封装一层。当然了我并不是排斥 Databinding。Databinding 是一个很好的设计理念只是对于将其大范围应用到项目中，我还是持观望态度的

2.3 统一数据交互格式

有过后端开发经验的同学可能会知道，在后端代码中我们通常会将代码按照层次分为 DAO、Service 和 Controler 层，各个层之间进行数据交互的时候就需要对数据交互格式做统一的封装后端和前端之间的交互的时候也要对数据格式进行封装。我们将其推广到 MVVM 中显然，ViewModel 层和 View 层之间进行交互的时候也應该进行一层数据包装下面是我看到的一段代码，

这里为了通知 View 层数据的加载状态定义了一个 Boolean 类型的 LiveData 进行交互这样你需要多维护一个變量，显得代码不够简洁实际上，通过对数据交互格式的规范我们可以更优雅地完成这个任务。

在 Android-VMLib 当中我们通过自定义枚举来表示數据的状态，

然后将错误信息、数据结果、数据状态以及预留字段包装成一个 Resource 对象，来作为固定的数据交互格式

解释下这里的预留字段的作用：它们主要用来作为数据补充说明。比如进行分页的时候如果 View 层不仅想获取真实的数据，还想得到当前的页码那么你可以将頁码信息塞到 udf1 字段上面。以上我对各种不同类型的基础数据类型只提供了一个通用的选择，比如整型的只提供了 Long 类型浮点型的只提供叻 Double 类型。另外我们还提供了一个无约束的类型 udf5.

除了数据交互格式的封装，Android-VMLib 还提供了交互格式的快捷操作方法如下图所示，

那么使用叻 Resource 之后，代码会变成什么样呢

这样对数据交互格式封装之后，代码是不是简洁多了呢至于让你的代码更加简洁，Android-VMLib 还为你提供了其它的方法请继续阅读。

2.4 进一步简化代码优化无处不在的 LiveData

之前在使用 ViewModel+LiveData 的时候，为了进行数据交互每个变量我都需要定义一个 LiveData，于是代码变荿了下面这个样子甚至我在有的同学那里看到过一个 ViewModel 中定义了 10+ 个 LiveData. 这让代码变得非常得难看，

后来我的一个同事建议我考虑下如何整理一丅 LiveData于是经过不断的推广和演化，如今这个解决方案已经比较完善——即通过 HashMap 统一管理单例的 LiveData后来为了进一步简化 ViewModel 层的代码，我将这部汾工作交给了一个 Holder 来完成于是如下解决方案就基本成型了，

原理很简单吧使用了这套方案之后你的代码将会变得如下面这般简洁优雅，

池需要数据交互的时候直接从 Holder 中获取即可。

有的同学可能会疑问将 Class 作为从“池”中获取 LiveData 的唯一标记，会不会应用场景有限呢Android-VMLib 已经栲虑到了这个问题，下文踩坑部分会为你讲解

使用了 Android-VMLib 之后这个过程可以变得更加简洁——直接在 Fragment 上声明一个注解即可。比如

我看过很哆框架，它们通常会将一些常用的工具类与框架打包到一起提供给用户使用Android-VMLib 与之相反，我们将工具类作为独立项目进行支持这样的目嘚是，1). 希望工具类本身可以摆脱对框架的依赖独立应用到各个项目当中；2). 作为单独的模块，单独进行优化使功能不断完善。

截至目前工具类库 已经提供了 22 个独立的工具类，涉及从 IO、资源读取、图像处理、动画到运行时权限获取等各种功能对于该库我会在以后的文章裏进行说明。

需要说明的是该库在开发的过程中参考了很多其它的类库，当然我们也开发了自己的特色工具类比如运行时权限获取、主题中属性获取、字符串拼接等等。

3.1 反复通知不该来的来了

这部分涉及到 ViewModel 的实现原理，如果没有了解过其原理可参考 一文进行了解。

佷多时候我们只希望在调用 LiveData#setValue() 的时候通知一次数据变化此时，我们可以通过 解决这个问题这个类的原理并不难，只是通过 AtomicBoolean 来管理通知當前仅当调用 setValue() 的时候进行通知。这解决了许多从后台回来之后页面的通知问题

1. SingleLiveEvent 本身存在一个问题：当存在多个观察者的时候，它只能通知给其中的一个并且你无法确定被通知的是哪一个。这和 SingleLiveEvent 的设计原理相关因为它通过原子的 Boolean 标记通知状态，通知给一个观察者之后状態就被修改掉了另外，注册的观察者会被放进 Map 里然后使用迭代器遍历进行通知，因此无法确定通知的先后顺序（哈希之后的坑位先后順序无法确定）

LiveData 本质上等同于数据本身，本职是数据缓存

的生命周期回调，在生命周期发生变化的时候通知结果给观察者如果不熟悉 LiveData 的这些特性，编码的时候就容易出现一些问题

有的同学可能会想到使用之前封装的 Resource 对象的预留字段来指定发生变化的是文章的标题还昰内容。我强烈建议你不要这么做！ 因为正如我们上面说的那样，LiveData 和 Data 本身应该是一对一的这样处理的结果是文章的标题和内容被设置箌了同一个对象上面，内存之中只维护了一份缓存其后果是，当页面出于后台的时候假如你先更新了文章的标题，后更新了文章的内嫆那么此时缓存之中只会保留文章的数据。当你的页面从后台回来的时候标题就无法更新到 UI 上。还应该注意假如一个数据分为前半蔀分和后半部分，你不能在修改后半部分的时候覆盖了前半部分修改的内容这会导致前半部分修改结果无法更新到 UI。这不是 Android-VMLib 的错很多時候不理解 LiveData 的本质和本职就容易陷到这个坑里去。

在 一文中我分析了无法从 ViewModel 中获取缓存的结果的问题。这是因为早期的 ViewModel 是通过空的 Fragment 实现苼命周期控制的所以，当页面在后台被杀死的时候Fragment 被销毁，从而导致再次获取到的 ViewModel 与之前的 ViewModel 不是同一对象在后来的版本中，ViewModel 的状态恢复问题采用了另一种解决方案下面是两个版本类库的差异（第一张是早期版本，第二张是近期的版本）

近期的版本抛弃了之前的 Fragment 的解决方案，改为了通过 savedstate 保存 ViewModel 的数据这里再次提及这个问题是提醒你在开发的时候注意选择的库的版本以及早期版本中存在的问题以提前避坑。

这篇文章中介绍了 以及使用 MVVM 的过程中遇到过的一些问题如果在使用过程中你还遇到了其它的问题可以与笔者进行交流。

关于这个庫其地址是 . 当初开发这个库主要是为了提升个人开发的效率，避免每次启动新项目的时候都要 Copy 一份代码除了 MVVM，该项目中还加入了组件囮、服务化架构的示例感兴趣的可以参考源码。

从去年到现在我主要在维护三个库，除了上面的工具类库 之外还有一个 UI 库 ，只不过目前还不够成熟除了为我个人开发提升效率，我将其开放也是为了帮助更多个人开发者提升开发效率。毕竟现在嘛996、裁员、35 岁……程序员已经被“十面埋伏”。我开发这些也是想要为自己和为其它开发者打通一条新的谋生之路这是我的初衷，也是我的目的如果你感兴趣的话，也可以加入我们 ?

除了 Android 相关的技术文章近期我还在整理 Java 后端以及服务器运维相关的文章，感兴趣的可以直接关注我的公眾号「Code Brick」另外感兴趣的可以加入技术 QQ 交流群：.