RyuukuSpace

       动态库（Dynamic Framework），使用它的优点之一就是避免冲突（还有其他优点，如共享）。Xcode 的项目如果出现同名的文件和类在编译的时候就会报错。开发SDK 就需要非常注意引入第三方库等可能给其他团队出现同名的冲突情况。除了改名的方案之外，动态库也是一个好方案。本篇就将对最近应用动态库的过程进行记录 & 供参考。

       想写篇 Git 来让产品和设计使用 git 管理他们的产品文档与设计图。然后将想法说出来，有人觉得没必要。产品和设计其实只需要类似 SVN 这种以文件来同步即可，而 Git 的操作会比较复杂。

       可是回想之前使用 SVN 其实也是很难用，多人提交时出现的等待，切分支，上传文件的各种慢。那回到该篇博文，将青铜部分就算入门，以单个人的维护的操作为主（这样可以避免一些比较复杂的情况）进行演示，并结合操作的截图进行说明。

       智能弹幕不挡脸效果就是使刷屏弹幕无法遮挡想看的内容。目前很多视频网站 & App 都已经实现，且还运用到直播上，提高了观看的体验。具体效果可以看看斗鱼等直播平台（记得确认该直播间是否有此功能）。接下来从客户端角度探讨如何实现智能弹幕，下面的效果的代码实现都在 – 新弹幕系统 chenqihui/QHDanmu2Demo，请同步工程了解。

• 虎牙推出弹幕黑科技：AI智能弹幕功能不挡脸

       谈谈 Socket 的大纲

• 概念
• 基本操作 Socket、CFSocket、GCDCocoaAysnSocket
• 第三方封装 SocketRocket、Pemolo、SocketIO
• 简单功能：测试 & 域名访问 SimplePing
• 服务端（Mac）
• 数据格式：使用 二进制 或者 protocolbuffer
• 模拟 HTTP 和 HTTPS（顺序学习 HTTP 协议头）
• 抓包 基本协议、了解下 TCP、UDP
• WebSocket 协议（WebRTC）

       QHGiftAnimationMan 这个项目看看时间是16年2月，快三年前的工程了。最近重新 checkout 下来，将 Swift2.0 的语法根据提示修改为 Swift4.2。不得不说 Swift 每个版本的变化还是蛮多的，也增加了新功能。而该项目是作为 iOS 动图播放 & 制作合集 的续篇二，也是介绍直播间的礼物动图特效 —— 组合礼物特效。

       新弹幕系统 chenqihui/QHDanmu2Demo，它在 iOS 飞屏的实现之路 | RyuukuSpace 里面的也提到过，与飞屏在展示与运动逻辑的实现上基本相似，区别可能在于弹幕系统会更加注重弹幕在轨道的选择，因此本次也着重介绍下弹幕系统的轨道选择部分。

       对于接收其他团队的 App 项目的时候，需要了解其中一项内容就是它的多环境，如测试、开发、发布等不同环境的逻辑。

       对于多环境的使用，之前本人使用较多的是配置多个 target，然后在 不同target 里面配置不同的条件宏。targets 可以是 duplicate target，也可以是新建 Application、Extension 或者 Framework 等等，常用的 通知扩展、手表扩展等

       而此次接手的项目使用的是 .xcconfig 文件。那么就来大概了解下它的文件、配置 & 使用。

       移动端大部分页面是由列表、表单、对话框展示，它们也是开发中最频繁开发的部分。说说表单，它是提供用户输入数据后提交的页面，常用于注册、登录、购物、评论等等。将表单抛开复杂控件和动画等元素，其主要由输入框、选择框、按钮构成，逻辑也就是输入、选择要提交的内容，点击提交即完成，这只是简化的逻辑。而完整的表单，其实可能根据业务不同，会有不同的细节处理，如加密，数据校验，UI 联调，状态提醒等等。那接下来介绍几个比较常见的表单设置与开发。

       我们已经了解到 m3u8 其实是一个文件，是 HLS 协议实现点播 & 直播的，还有 TS 文件。这里还有一篇讲解 AVPlayer 的，等编辑完再更新地址。

理论

HTTP Live Streaming (HLS) sends audio and video over HTTP from an ordinary web server for playback on iOS-based devices—including iPhone, iPad, iPod touch, and Apple TV—and on desktop computers (macOS). Using the same protocol that powers the web, HLS deploys content using ordinary web servers and content delivery networks. HLS is designed for reliability and dynamically adapts to network conditions by optimizing playback for the available speed of wired and wireless connections.

HLS supports the following:

• Live broadcasts and prerecorded content (video on demand, or VOD)
• Multiple alternate streams at different bit rates
• Intelligent switching of streams in response to network bandwidth changes
• Media encryption and user authentication

       今天聊到动图，它们在 App 上都很常见，如聊天的表情，直播的送礼 & 座驾特效，H5 上的活动图，视频的录制等等。而动图有很多种格式，常用的 帧动画、Gif、WebP、Apng、Svga。由于最近项目加入 Svga，因此顺便学习下其他动图，也把之前记录的 LivePhoto 一起总结进来，做一次复习。

       本篇可以说是一篇播放 & 制作的合集。大家将会看到 YYImage，Svga-Player，iSparta 转换等开源库 & 工具。而主要说明的动图格式是 Gif、WebP、Svga、LivePhoto。除了 LivePhoto，其它动图的的播放在 iOS 端的大概流程都是通过 ImageIO 绘制出 UImage，再通过 CADisplayer 进行逐帧播放，只是解码库不同，如 WebP 是依靠 Google 提供的库（因为编码不一样）。也正由于他们是逐帧播放的，所以可以将每帧数据解码后再重新编码成其他格式的动态。最为关键的还是编码上，从而形成各自的优势，就目前项目的动图还是比较多使用 WebP，而 Svga 目前使用上似乎更好，特别是在直播的大礼物特效上。

       网络测速会在 App 性能里面经常提到。网络的好与坏影响了 App 的使用体验。因此监听网络状态，根据网络的状态来控制 App 的功能 或者 对应处理，能达到提升用户体验的目的，它也就成了 App 优化项的关键之一。当然性能还包括 App 体积，App 的热启动 & 冷启动 等等指标。

       先说下测速的需求，要在不增加额外的上传 & 下载的资源消耗，就能达到实时测速的目的。也就是得通过计算 App 现有业务的网络请求，获取的传输数据大小 & 请求时间，从而得出网速。

       如果阅读前面的文章 《iOS 自定义图形的实现 | RyuukuSpace》 和 《PDF 预览 & 解析 | RyuukuSpace》，会发现里面就使用了 CAShapeLayer 和 CATiledLayer。其实它们是苹果提供视图更底层的操作——图层，对于 UIView 大多数人都比较了解和常用，UIView 其实就是在 layer 的基础上加工，并提供更加高级的操作，而有些时候还是需要使用 layer 来进行更高效，更专有的使用。接下来就推荐下关于 layer 的一本翻译书籍。

       近期看了 《别乱说，算法才不是脑筋急转弯》 这篇推文里面最后一题让人好奇（其实其他的也还不错，有些就是脑筋急转弯呀，真能用算法来写就强了），它就是是传说中的爱因斯坦提出的思考题，他宣称世界上只有2％的人能解出这个题目，你肯定听说过不下一次这道题，但也肯定你始终连题目都没记清楚过。因此也就试试解答下，居然断断续续合计花了两天，泪崩，并且还不是完美的答案。

       简单讲就是它独立包含文档所有信息，如文本、字体、图形等等。并且当看到下面解析工具解析看到结构，每一页也都具有完整信息，这样就可以分开处理显示。可以通过 可移植文档格式 - 维基百科，自由的百科全书 & pdf_百度百科 来了解更多 PDF 信息。

       回到需求，产品上看可能 APP 只要能看，并在看到第几页的时候显示相应的提示或者其他动作。而对于开发者，如果使用自定义的话，会疑问如何显示？是列表呢、还是翻页，加载效果？加载方式？在线还是本地等等。并且自定义显示的效率如何？是否占内存，占CPU。是否需要编辑？再深入就是研究 PDF 结构。然后发现想多了，还是老老实实先实现产品需求。

       继 QHFlvParserMan 解析 FLV 之后，本次增加了对 MP4 视频格式的解析支持。而通过上一篇 《FLV 格式一谈》入门了音视频的知识后。可以通过对 MP4 了解，来更进一步学习音视频知识。

       MP4 多用于点播，它也是现在用的比较多的视频封装格式，它为了播放流式媒体的高质量视频而专门设计的，以求使用最少的数据获得最佳的图像质量。但是它的文件格式复杂，索引慢，时长较长的 MP4 视频在线播放时加载较慢。

       本次的话题应该算是老话题。在开发用户系统，用户昵称修改，聊天等功能的时候，会遇到用户输入 Emoji，特殊字符。甚至直接输入 Unicode 编码的时候。如果客户端提交给服务端，再从服务端获取，直接显示可能会出现乱码。甚至有时是服务端进行编码保存，然后给客户端，并没有协商谁来负责解码。这都只是一方面，因为特殊字符的存在还会影响数据上报。当服务端拿到这种特殊数据，会无法解析，导致请求失败等等。所以需要对字符进行 Encode & Decode。

       CocoaPods.org 的出现极大的方便了项目的集成，第三方库的发展，特别是开源，我们不单单可以使用 framework 和 a库。不过还是很怀念 Xcode 支持插件的时候，可视化的使用 CocoaPods 的时候，不仅仅是 iOS 第三方库，还会安装 Xcode 的插件等等，不得不给个赞，而现在虽然不能再使用类似插件（对于官方版本的Xcode），但是 CocoaPods 依然是一个很方便的利器。而对于通过 CocoaPods 的维护和管理的方式，也是加快了开发组件化，开源模块的进程。所以当开源自己的模块时，支持 CocoaPods 也相对重要了，所以需要熟悉它，和基本的操作使用。接下来就先从 CocoaPods 的基本操作开始。

       这篇之前是直接放在 Github 的 chenqihui/QHUMLModelDiagram: UML建模，因为那时还没使用博客，如今将它迁移过来。

       而为什么整理 UML 建模呢？里面很多内容是摘录《软件工程导论（第5版）》，是读书时候的课本，现在新教材不知有没有哪些变动了。所以有出入可以联系修改，感谢。说回为什么，其实很简单，就是由于画图时常常忘了或者把多种图，在使用不熟下，交叉的使用，从而导致画出来的 UML 变成了四不像。UML 其实对开发来说，提供简单的流程、结构说，对后续优化、再次开发都很有帮助，因此还是需要认真对待。把 UML 画得不仅是给自己看，也要拿得出手给其他人查看，并且是好了解的。接下来就介绍开发中常用 UML 建模的标准定义。

       自定义图形在产品的开发慢慢占据愈来愈多的时间，当然还有性能优化。这其实都是一般开发者特别想忽略或者很难长期坚持开发的内容。如这种自定义图形和动画，简单点不是又不耗性能，又方便开发，其实倒觉得是开发者都比较懒，能简单肯定更好。但懂的偷懒和不懂的偷懒天差地别了。动效这块还有很多知识点，特别是 FB 开源的 pop 库。

       回到本次的需求需求，**倒计时 & 水波纹**，用在产品的连麦申请和连麦成功的状态。它们的需求说明分别为：倒计时，是个圆圈弧形进度条，中间就是倒计时的时间数字表示向用户发起连麦的显示，倒计时用于计算用户是否接受连麦请求。而水波纹，即水面的波纹一样，一圈一圈的扩散，用来表示当前用户正在与主播进行语音连麦。接下来会将代码直接全部贴出，可能有点多，是将项目的这部分代码移到 Playground 实现，也就是只需将代码拷贝到 Playground 就可以看到效果。但是需要注意，只有第一个 UIView 的倒计时看到效果（记得点开右边的显示按钮喔），而其它无法看到效果，可能得复制到 Demo ，也是 OK 的。

       开发 飞屏 功能，跟我较早前的弹幕系统相似 QHDanumuDemo: 弹幕系统。不同之处在于，弹幕系统需要计算弹幕轨道的空闲与否，弹幕是否处在相互碰撞位置，时间校准等控制每条弹幕的出现，并且大多数弹幕系统是有多种位置（上中下），及不同出现方式，最近 bilibili 实现了弹幕绕开人脸的实现，cool。那么飞屏呢，它一般是固定规律显示的条数，并且动画较少，但是飞屏的样式比弹幕复杂（我目前的需求是这样，这个不是重点）。抛开样式，从逻辑来讲，飞屏其实就是简化版的弹幕系统。本次需求由于要集成 SDK，所以不打算在原有的弹幕系统增加支持。以重新开发，去掉复杂逻辑，也就抽出今天的内容。