我们知道Apple设备可执行文件的存储格式是MachO，一个二进制文件。通常在做逆向或者静态分析的时候都会用到这个文件，分析MachO的常用工具是MachOView。今天借助于MachOView，主要分析Code Signature的存储规则。 本篇文章同时也是围绕这几个问题展开的： 1、MachOView是如何确认MachO内容的。 2、二进制数据是如何存储的，如何确认位置。 3、字节码含义如何解析。前置准备 1、二进制文件其实简单理解就是通过二进制形式进行存储内容的文件，它可以原封不动的读到内存中用于完成各种处理。比如数值3.1415927，文本文件需要9个字节进行存储：3 . 1 4 1 5 9 2 7 这 9 个 ASCII 值，而如果是二进制的话4个字节就够了：DB 0F 49 40。 2、二进制文件读到内存中通常是连续存储的，它不需要额外的处理，原本怎样，在内存里就是怎样的。 3、每个进程都会被分配一个虚拟地址空间，进程寻址的范围就是在这个虚拟地址空间进行的，虚拟地址到物理地址之间有一个映射表进行管理。 4、可以简单理解：虚拟地址 = 随机基址（ASLR）+ 逻辑地址（段内偏移）。 后面的内容也会出现很多偏移量（offset）的概念，它的含义很简单就是相对某一位置偏移多少字节。关键是需要确认它是相对哪个位置进行的偏移，在不同的数据段，这个相对的锚点是不一样的。但通常来说偏移量都是相对于当前的数据段来说的。 5、FAT格式的MachO可以理解为多个架构的顺序组合，所以分析某个架构时，还需要加上对应架构的偏移量。 6、uint32_t占4个字节，uint8_t占1个字节，char占一个字节。 Mach-O格式 格式分析 可以简单看下Mach-O的数据结构：Mach-O文件大致分为三部分： Header 表示当前的Mach-O文件整体信息，包含CPU架构、子版本、文件类型、加载命令数等内容。数字内容好表示，那CPU架构这样的类别是如何表示的呢？二进制数据说到底也是数字，这些类别信息也只能通过数字表示，但需要一个具有特殊含义的数字，这个数字通常叫magic（魔数）。比如0xCAFEBABE表示FAT，0xFEEDFACF表示ARM64。 Header的定义地址：https://opensource.apple.com/source/xnu/xnu-792/EXTERNAL_HEADERS/mach-o/loader.h.auto.html Load Commands 记录各个数据段的信息和位置，只是类别和标记的介绍，包含一些信息的偏移地址、文件大小等内容。 Data 记录具体的内容信息。不同类别的信息对应不同的数据含义。注意上图右侧由Load Commands到Data的箭头，Data的位置是由Load Commands指定的。 他们三者的关系如果用一本书表示的话就是：Header是封面，Load Commands是目录，Data是书的内容。 寻找Code Signature 本节的重点是找到Code Signature（代码签名）这部分内容，它没被MachOView解析，还是原始的数据形态，是一个比较好的分析案例。 分析文件是系统的ls，它的路径在/bin/ls，把它放到MachOView里。ls是一个FAT文件，它包含两个架构，Fat Header里记录了各个架构的类别、偏移量、大小等信息。我们只关注X86_64架构下的内容，展开这个架构下的Load Commands，找到代表代码签名的LC_CODE_SIGNATURE信息：右侧是真实的数据内容，MachOView已经帮我们对应好了字段描述： Data Offset：代表数据偏移 53808，换成16进制就是0xD230 Data Size：代表文件大小 5728，换成16进制就是0x1660 这俩16进制值其实就是Data对应的内容，Value是MachOView帮我们做的处理。 这里的偏移跟上面Fat Header的偏移含义已经不一样了，Fat Header说的是总文件偏移，这里的偏移则是针对X86文件的偏移。所以实际的偏移应该是：0xD230 + 0x4000 = 0x11230。 找到Data部分的Code Signature内容：这里pFile就是相对当前文件的偏移量（也可以理解为逻辑偏移量），它的起始位置正是上面计算得的：0x11230。由大小0x1660，我们还可以计算得出Code Signature最后一个字节所在位置是：0x11230 + 0x1660 - 0x1 = 0x1288F。 解析Code Signature CS_SuperBlob 我们已经找到了代码签名位置，现在开始解析它吧。解析的第一步就是需要找到数据定义，有了定义才能分析出数据含义。Code Signature相关内容的定义在这里：https://opensource.apple.com/source/xnu/xnu-3789.51.2/bsd/sys/codesign.h.auto.html 整个签名的头部是一个CS_SuperBlob结构体，它的定义如下： typedef struct __SC_SuperBlob { uint32_t magic; /* magic number */ uint32_t length; /* total length of SuperBlob */ uint32_t count; /* number of index entries following */ CS_BlobIndex index[]; /* (count) entries */ /* followed by Blobs in no particular order as indicated by offsets in index */ } CS_SuperBlob; 这个结构体第一个参数是magic，它的定义如下： /* * Magic numbers used by Code Signing */ enum { CSMAGIC_REQUIREMENT = 0xfade0c00, /* single Requirement blob */ CSMAGIC_REQUIREMENTS = 0xfade0c01, /* Requirements vector (internal requirements) */ CSMAGIC_CODEDIRECTORY = 0xfade0c02, /* CodeDirectory blob */ CSMAGIC_EMBEDDED_SIGNATURE = 0xfade0cc0, /* embedded form of signature data */ CSMAGIC_EMBEDDED_SIGNATURE_OLD = 0xfade0b02, /* XXX */ CSMAGIC_EMBEDDED_ENTITLEMENTS = 0xfade7171, /* embedded entitlements */ CSMAGIC_DETACHED_SIGNATURE = 0xfade0cc1, /* multi-arch collection of embedded signatures */ CSMAGIC_BLOBWRAPPER = 0xfade0b01, /* CMS Signature, among other things */ //... }第二个参数是length，表示整个SuperBlob的长度。 第三个参数是count，表示index实体条目的数量。 第四个参数是为CS_BlobIndex的一个结构体。 大端小端 1、这个是64位架构的二进制数据，其实有两种64位架构，他们分别表示为大端64位和小端64位，上面MachOView分析的X86 Header中的魔数是0xFEEDFACF，代表的就是当前二进制文件是小端64位格式。 2、比如0x1234这个数据，在小端情况下，12会存放在低字节处，34会放于高字节处，大端则相反。 数据解析 我们把Code Signature的第一个行数据拿出来分析：这里注意Data部分，有两个标签：Data LO和Data HI，是用于表示当前的字节序列，前面是低字节，后面是高字节。这样按照小端的规则，我们就可以按自然顺序取数据了，所以可以得出以下内容： magic 为0xFADE0CC0，对应CSMAGIC_EMBEDDED_SIGNATURE，代表嵌入的代码签名数据。 length 是0x1486，我们可以计算得出最后一个字节位置：0x11230 + 0x1486 - 0x1 = 0x126B5红色标记的字节就是Code Signature结束的地方，在这之后的内容全部由0x00填充，就非实体内容了。 count 是3，表示接下来有3个实体内容，这个实体对应的是结构体：CS_BlobIndex。 CS_BlobIndex 我们来看下CS_BlobIndex这个结构体： /* * Structure of an embedded-signature SuperBlob */typedef struct __BlobIndex { uint32_t type; /* type of entry */ uint32_t offset; /* offset of entry */ } CS_BlobIndex;它有两个成员变量，type表示实体类型，offset表示实体偏移量。 一般表示类型的肯定有特殊数字对应的含义，这里的type也是一样的，这个type在上面的magic在一个enum里定义。 CSSLOT_CODEDIRECTORY = 0, /* slot index for CodeDirectory */ CSSLOT_INFOSLOT = 1, CSSLOT_REQUIREMENTS = 2, CSSLOT_RESOURCEDIR = 3, CSSLOT_APPLICATION = 4, CSSLOT_ENTITLEMENTS = 5,CSSLOT_ALTERNATE_CODEDIRECTORIES = 0x1000, /* first alternate CodeDirectory, if any */ CSSLOT_ALTERNATE_CODEDIRECTORY_MAX = 5, /* max number of alternate CD slots */ CSSLOT_ALTERNATE_CODEDIRECTORY_LIMIT = CSSLOT_ALTERNATE_CODEDIRECTORIES + CSSLOT_ALTERNATE_CODEDIRECTORY_MAX, /* one past the last */CSSLOT_SIGNATURESLOT = 0x10000, /* CMS Signature */数据解析 我们再回到数据部分，根据上面结构体进行分析：能够解析出三条CS_BlobIndex数据：type type含义 offset0x00 CSSLOT_CODEDIRECTORY 0x240x02 CSSLOT_REQUIREMENTS 0x2610x10000 CSSLOT_SIGNATURESLOT 0x29D这里又出现了一个offset，这个offset存在于Code Signature的最外部，所以它表示的就是相对Code Signature的偏移量。 这个表相当于又提供了一个目录，它告诉我们，之后的内容有三部分（三个结构体）组成，各个部分的页码是什么。 CS_CodeDirectory 我们先分析CSSLOT_CODEDIRECTORY，它对应的是CS_CodeDirectory结构体： /* * C form of a CodeDirectory. */ typedef struct __CodeDirectory { uint32_t magic; /* magic number (CSMAGIC_CODEDIRECTORY) */ uint32_t length; /* total length of CodeDirectory blob */ uint32_t version; /* compatibility version */ uint32_t flags; /* setup and mode flags */ uint32_t hashOffset; /* offset of hash slot element at index zero */ uint32_t identOffset; /* offset of identifier string */ uint32_t nSpecialSlots; /* number of special hash slots */ uint32_t nCodeSlots; /* number of ordinary (code) hash slots */ uint32_t codeLimit; /* limit to main image signature range */ uint8_t hashSize; /* size of each hash in bytes */ uint8_t hashType; /* type of hash (cdHashType* constants) */ uint8_t platform; /* platform identifier; zero if not platform binary */ uint8_t pageSize; /* log2(page size in bytes); 0 => infinite */ uint32_t spare2; /* unused (must be zero) */ /* Version 0x20100 */ uint32_t scatterOffset; /* offset of optional scatter vector */ /* Version 0x20200 */ uint32_t teamOffset; /* offset of optional team identifier */ /* followed by dynamic content as located by offset fields above */ } CS_CodeDirectory;数据解析 我们先把这段数据拿出来，然后根据结构体进行分析：这里仅挑一些重要的内容进行分析。 magic是0xFADE0C02，作为标记存在，代表CodeDirectory length是0x23D，表示数据段长度 identoffset是0x30，表示identifier字符串的偏移量，这里的identifier对应的就是我们的bundleId 需要提醒的是当前的CodeDirectory是数据SuperBlob的内部结构体，所以这里的offset就变成了结构体内部偏移了，这里的起始位置也即是0xFADE0C02所在的位置是0x11254，所以可以算出indentoffset的文件偏移量是： identoffset地址为：0x11254 + 0x30 = 0x11284 这里你可能会疑惑，只有偏移量怎么确认从哪结束呢，这里并没有提供数据大小。其实字符串是不需要知道大小也可以确认它到哪结束的，字符里面有结束位\0啊，在ASCII码里结束位就是0x00。可以解析得出ls的bundleId是com.apple.ls。 这里再补充一点：MachO里字符串的编码不是通过ASCII，而是使用UTF-8进行编码的，只不过UTF-8兼容了ASCII，所以我们当做ASCII也能解析出正确的内容。 CS_GenericBlob 我们现在来看下证书的解析，查上面记录的偏移表，CSSLOT_SIGNATURESLOT对应的结构体是CS_Generic_Blob： typedef struct __SC_GenericBlob { uint32_t magic; /* magic number */ uint32_t length; /* total length of blob */ char data[]; } CS_GenericBlob;上个表格我们记录了它的offset是0x29D位置，所以它的起始位置就是：0x11230 + 0x29D = 0x114CD，找到这个位置，带入结构体进行解析：magic是0xFADE0B01，对应了CSSLOT_SIGNATURESLOT值。 数据长度是0x11E9（4585字节），这表示的CS_GenericBlob的大小，而在这之后的内容都是data，表示的就是证书部分。 我们可以计算出证书data结束的最后一个字节位置：0x114CD + 0x11E9 - 0x8 - 0x1 = 0x126AD。 说明：根据《iOS应用逆向与安全》一书说明，借助于010 Editor等二进制工具，我们把data部分的数据复制出来（需要借助于Hooper这类工具），保存为cer格式，就能获取到一个证书文件。但对ls的测试并不能成功，推测这里的data可能还有其余内容，需要拆分。 Jtool 只要有了对应数据结构，签名部分的所有信息我们都是可以解析出来的。但每次都逐字节分析，显然很费事，能不能写个程序，用于上述内容解析呢？当然是可以的，已经有这样的工具了，就是Jtool。jtool比otool功能更强大，解析的数据也更详细。可以通过homebrew进行安装： $ brew install jtool如果通过jtool查看上面x86_64架构的签名信息，可以这样： $ jtool -arch x86_64 --sig /bin/ls输出结果为： Blob at offset: 53808 (5728 bytes) is an embedded signature Code Directory (573 bytes) Version: 20100 Flags: none Platform Binary CodeLimit: 0xd230 Identifier: com.apple.ls (0x30) CDHash: 46cc1da7c874a5853984a286ffecb48daf2f65f023d10258a31118acfc8a3697 (computed) # of Hashes: 14 code + 2 special Hashes @125 size: 32 Type: SHA-256 Requirement Set (60 bytes) with 1 requirement: 0: Designated Requirement (@20, 28 bytes): SIZE: 28 Ident: (com.apple.ls) AND Apple Anchor Blob Wrapper (4585 bytes) (0x10000 is CMS (RFC3852) signature) CA: Apple Certification Authority CN: Apple Root CA CA: Apple Certification Authority CN: Apple Code Signing Certification Authority CA: Apple Certification Authority CN: Apple Root CA CA: Apple Certification Authority CN: Apple Root CA CA: Apple Certification Authority CN: Apple Code Signing Certification Authority CA: Apple Software CN: Software Signing Time: 201222002625Zi第一行里的offset 53808 对应16进制是0xD230，就是LC_CODE_SIGNATURE里记录的偏移量。 根据输出信息也能得出code signature由三部分内容组成：Code Diretory、Requeirement Set、Blob Wrapper。证书部分解析出了6个证书，说明这里应该还有别的结构体可以拆分。 回顾 如果你看到这里，可以回顾下开始讲到的三个问题，用于检验你的理解程度。 1、MachOView是如何确认MachO内容的。 2、二进制数据是如何存储的，如何确认位置。 3、字节码含义如何解析。

《学习之道》的作者是芭芭拉·奥克利，她是美国奥克兰大学的工程学教授。她在Coursera上开设了一门课程叫“Learning How to Learn”，即讲如何学习的，该课程非常受欢迎，有200多万人注册学习。该课程地址在这里：https://www.coursera.org/learn/ruhe-xuexi。这门课跟这本《学习之道》内容重合度很高，毕竟都出自同一人，可以作为配套视频来看。如果不想看书又想详细学习课程精髓的话，只看视频也是完全可以的。这本书讲了什么 我感觉可以用Coursera课程上的中文翻译来概括：学习困难科目的实用思维方法。这里突出困难科目其实是指常让人感觉难学的突出逻辑性的理工科，但我认为不仅是「困难科目」，任何新的概念都可以借鉴书中提到的方法进行学习。 本书引用了很多脑科学和心理学的最新研究，很多方法都是有实验依据的，以下是我认为比较有益的内容。 核心概念 专注思维 vs 发散思维 理论知识 我们的大脑有两种截然不同的思维模式 --- 专注模式和发散模式。专注模式是利用理性分析，按照特定步骤解决问题的模式。 发散模式没有特定的步骤，它是弥散在大脑中的，我们常说的灵感一般都来源于发散模式。应用 1、通常情况我们的大脑会在这两种模式之间来回切换。利用这一点我们在学习数学或者计算机等知识时，可以先用专注模式打头阵，掌握特定的概念和原理。对于一些更复杂的问题，不要急于解决，做点别的事情，让这个问题由大脑带入潜意识，虽然我们不在关注它了，但其实大脑还在后台「消化」这个知识。 2、学好数学和计算机科学最好的方法是“每天进步一点点”，不要担心学的慢，细嚼慢咽反而会让你比那些脑子快的同学学习得更加深入。 3、紧凑的专注模式之后，发散模式就是一种对大脑的奖励。通常有以下激发发散模式的方法：去健身房 慢跑、散步 淋个浴或者泡个澡 听音乐，尤其是纯音乐 睡觉 冥想记忆组块 大脑能够记忆独立内容是有限的，为了让它更高效的工作，我们需要将发散的信息碎片组合起来，这个就叫做记忆组块。构建组块的步骤如下，比如我们想学习一本教材： 1、浏览目录，了解这本教材大致有哪些内容。 2、按顺序，深入了解各个章节的内容。在学习新知识的时候有一个重要的方法可以应用：每完成一个章节，试着回想学习材料，即提取练习，这种效果比单纯阅读材料好得多。再强调一遍，看完内容，一定要自己回想这个章节讲了什么东西，最好用自己的话把内容复述一下。 3、章节结束之后做测试，测试是一种高效的巩固学习的方法。 4、了解知识背后的背景知识。 5、再看目录，将这些内容串联起来，形成具有联系的组块。 改变拖延症 预防和改变拖延的方式就是：养成良好的习惯，用好习惯去对抗拖延。 对于习惯有深刻见解的一本书是《习惯的力量》，这里介绍习惯分为四个部分：信号、反应程序、奖励机制、信念。我们可以从这四个阶段入手解决拖延问题。 信号 找到让自己陷入拖延，大脑出窍的信号。比如我们在学习中，因为想看下手机时间，结果拿起手机就玩了几个小时。找到这个信号，下次学习时我们就把手机放到远离自己的地方。 反应程序 反应程序是身体的一项习惯机能，比如看到床就想躺下，踩着橡胶跑道就想跑步，坐到图书馆就想看书一样。我们需要找到把自己代入拖延的反应程序，用更好的程序去替换它。 奖励机制 习惯的强大之处在于它能造成精神层面的欲望，要想克服之前的欲望，就需要用一个新的奖励覆盖之前的欲望，而不是意味的强迫自己戒掉欲望。 信念 相信自己一定可以克服拖延养成好的习惯，可以利用“心理对照”，想象你达成好习惯所获得的成就来为自己增加信心。 还有一些改变拖延的方法和工具值得尝试： 1、任务清单，把当天或者一个阶段重要的事情用清单列出来，每解决一项就划掉一项，用于提醒自己哪些还没有完成。 2、利用番茄工作法，通过集中注意力学习，然后适当休息，之后再来几个循环，以提高自己的效率。 3、对于复杂的工作可以拆分为几个微小任务，确保自己及时得到反馈，享受完成一项任务的愉悦感。 增强记忆力 记忆是学习中非常重要的一种手段，不要认为那些记忆力强的人天生记忆力就好，每个人的记忆能力相差都是不大的。很多记忆高手在训练之前也跟普通人差不多，所以我们也可以通过训练提升自己的记忆力。 视觉图像 图像对记忆很重要，部分原因在于图像与右脑的视觉中枢直接相连。我们把一个或者几个有联系的内容，通过与一些图像建立联系，会有助于提高我们对这类内容的记忆。 记忆宫殿法 这需要我们对需要记忆的内容，编造出一个“宫殿”来，也可以说是一个你熟悉的场景，将这些内容一点一点串起来。 打造生动形象的比喻或类比 把学习概念有趣化，拟人化也有助于我们记忆内容。 间隔重复 需要记忆的内容不会一直留存在大脑中，需要我们间隔性的重复，以加深印象。这个就是艾宾浩斯记忆法，在事物被遗忘前需要复习巩固它。 肌肉记忆 这里的肌肉说的是写和说带动的手部和嘴部肌肉，我们调动越多的身体器官去参与记忆，越有助于我们加深对内容的记忆。 体育锻炼 最近几项动物和人类的实验发现，规律的锻炼可以让记忆力和学习能力得到实质性的提升。锻炼是有助于促进记忆力相关脑区中新神经元的形成，有氧运动和阻力训练都会对学习和记忆发挥强大的效果。 塑造大脑 塑造大脑有以下方法： 1、在科学、数学、技术领域取得成功的专业人士，逐渐习得的一个特质就是学会如何组块，即：提炼关键思想。 2、对于复杂的知识进行简化，并给这些抽象概念赋予生命。一位获得金苹果奖的化学高级讲师说：学习有机化学的难度和去认识一些新人物比起来没什么两样。每一个元素都有自己独特的个性。你越了解它们的性格，就越能读懂它们的处境，并能预知他们在相互作用中会产生的结果3、把所学的知识迁移到新背景中。数学能应用到物理，那能否应用化学或者别的学科，工作中的一些方法能否应用到生活中去。 4、自主学习是一种最深入、最有效的学习方式。能通过自己努力解答的问题就尽量不要向外界寻求答案。 5、锻炼自己去接触那些你敬仰的人，往往他们一句话就会改变你的未来。但要记住好的导师通常都是大忙人，请爱惜他们的时间。 6、考试本身就是一种很好的学习经历。即使没有考试，我们也可以创造一些考试场景用于更好的学习。这里引申一个由难入简做题法。 该方法建议：对于一场考试，我们应该从最难的题目做起，通常从后往前的顺序就是先难后易。对于难题如果我们一两分钟仍没有一丝头绪，就跳过去做下一题，没有思路再跳一题，如果中间突然想到了某道难题的解决思路就赶紧记下来，做完简单题之后再回去处理。 这个方法的核心思想就是把难题的内容让大脑先有个印象，后面做更简单题时，大脑潜意识还留存着难题的内容，说不定这时就灵光乍现，想出了难题的解决思路。相对而言这样可以对大脑利用最大化。 十个学习法则 这是本书最后一章的内容，是对以上内容的总结提炼。 1、运用回想。读完一篇文章，回想一下它讲的到底是什么。 2、自我测试。通过测试检验自己的学习成果。 3、对问题进行组块。搭建组块的过程就是理解问题、练习解题方法的过程。 4、间隔开重复动作。不要过多重复一件事情。 5、在练习中交替使用不同解题技巧。换不同思路去解决问题。 6、注意休息。学习累了就休息，善用大脑潜意识。 7、使用解释性的提问和简单类比。对于难懂的概念先类比一个熟悉的类似的概念，这有助于理解。 8、专注。每个人的时间是平等的，但注意力可不平等，有注意力的时间才是更有价值的，我们需要想办法让自己更专注。番茄工作法就是一种很好的帮助我们专注的方法。 9、困难的事情最先做。最清醒的时候，要去做一天中最困难的事情。 10、心理对照。想象过去的你，对比通过学习能够成就的那个自己。

2020年是很特别的一年，经历了记忆以来最严重的一场疫情，而且完全可以预见的是它还将继续祸害着2021年的我们。不管这一年多艰难吧，都走过来了，在2020的最后一天，在新年即将到来之际，简单总结下自己这一年的经历。生活 疫情开局 春节回老家，正赶上疫情影响，因为担心遭遇封城，我跟媳妇就早早返回了北京，那是正月初二的晚上。赶上北京这边戒严，春节假期的几天及之后的两个月我俩都被迫窝在了霍营的小出租屋里。一周出去买一次东西，囤土豆，囤白菜，面粉和米都买的大袋的。这期间尝试了油条、包子、饺子的做法。喜欢吃手抓饼，就在网上买冷冻的饼，自己摊着吃，到后来我们清理手抓饼的箱子，发现足足吃了6箱。。。 疫情生存指南除了自给自足，还需要学会抢购口罩。当时普通医用口罩被炒到4-5块一个，还很不容易买到，因为大量口罩都被优先征用到抗疫一线了。我拖朋友在外地买回来100个，当我用塑料袋拎着100个口罩回家时，路上有个老人拦手问我，你这口罩哪买的？我没敢说买的，只说：朋友送的。坐公交的路上，总感觉有人盯着我装口罩的袋子看。我当时就有种感觉，自己拎着的不是口罩而是现金。 因疫情关系，在家远程办公了将近两个月。没有扩展显示器和升降椅，正常的午休也很难保持到固定时间，这让我很是怀念公司办公的感觉。好在混乱的生活工作节奏没有持续太久，就基本上恢复正常了。 离职 6月份开始准备换工作，7月份离职，离开待了两年多的乐信圣文。临走那天，看了一眼身后的熟悉的楼层，既有对这段工作经历深深的感激之情，也有摆脱焦虑的如释重负。在乐信这两年是我职业发展非常关键的两年，学会了独立思考，形成了一些属于自己开发原则： 1、文档是第一手资料 遇到问题，不要上来就打开搜索引擎，那很可能会浪费时间且养成惰性。很多问题，很多偶发现象，文档里都是有写的，多翻翻文档很可能就会发现惊喜。 2、刨根问底研究明白 这来源于我看的一篇博客，它的故事是：作者在开发中有时会用到lamda，第一次时它利用搜索引擎，找到了处理方案，第二次再遇到还是不能自己解决仍需要借助于搜索。等第三次第四次时他反应过来，为什么不一次研究明白呢？于是花了将近两天时间，把这一概念的种种用法，相关知识点研究的明明白白，之后再有类似问题都可以完全自己解决了。 我深受启发，很多时候我也是一直在做重复工作，知道这里重要，但懒得去深入了解，总想省事，但结果是如果第一次我们就把那个东西弄透彻才是最省事的方案。 3、阅读计算机经典著作 知乎上有个挺火的问题：你的编程能力从什么时候开始突飞猛进？，很多回答都是在阅读了一些经典计算机著作或编写了大量代码之后发生了这种变化。不得不说，阅读那些经典著作真的很重要，我看完《重构：改善既有代码设计》这本书之后，慢慢建立了评判代码好坏的标准，以及看到坏味道的代码就想去改改的冲动👀 之后又看了《程序员修炼之道》《设计模式》，我感觉自己变的更强了。 4、学习榜样 从身边找到一个优秀的人，并向他学习也是很好的一种进步方式。我是先找到的学习对象，后来才意识到这真的有助于我进步。当时同组的超哥，编程水平一流，各个编程技巧熟练应用，思考问题井井有条，还有投入工作那种忘我的状态，直到现在他都是我遇到过的最优秀的开发者。像现在的坚持命令行git，读文档，学习后端知识都是受他影响。 5、拓宽知识边界 试着学一些其他编程语言，了解他们的语言特性，脚本语言里的Python、Ruby，编译语言的Java都是比较适合作为iOS开发的扩展编程语言。 新工作 7月份来到爱奇艺，开始了另一段职业生涯。目前虽待的时间还不算长，对于这里的工作节奏还是很喜欢的。有相对合理的版本节奏和工作弹性，有一定的自由空间可以发挥自己的想法。同事也很nice，富有热情，热爱工作，这是我很喜欢的工作氛围。更重要的是leader能给我职业发展的指导，告诉我认知层次的缺失，从哪些方面可以提升自己，这对现阶段的我来说尤为重要。 总之，在这里还有很大的进步空间，2021年加油吧。 人生大事 今年完成了人生中的两件大事，领证和买房。跟媳妇认识七年，相恋三年，我们选在今年的七夕领结婚证。后来在B站看到很多up主在今年领证结婚并且拍了视频记录，感觉很浪漫，有些后悔我们领证的经历没有记录下来。这让我萌生了另一个想法：如果现在记录下我们日常的生活，5年、10年之后再看应该也会很不一样吧。所以最近的一段时间，早起之后，我俩都会一起录段视频，讲一讲最近的感受，以及当天的计划，到第二天时回顾前一天，再录当天内容。已经坚持了半个月，希望这能够成为我俩的浪漫之事。 9月份，我俩靠自己能力在天津买了属于我们的第一套房子，非常开心，期待搬进新家的那一天。 10月份拍了婚纱照，计划春节前举办婚礼，看现在的疫情，真不确定那时会变成什么样，祈祷一切顺利吧。 一些有意思的事情 公众号和博客 在年中换工作期间，重新拾起了公众号，将名称改为：iOS成长之路，定位于iOS技术文章。当时公众号只有8个粉丝，我还定了一个大目标：年底公众号粉丝达到500个。前期粉丝真是涨的很慢，我一度认为这个目标可能要凉凉了，直到后来发了那篇面试总结，被很多技术号转载，很快就涨到了500+，原来面试文章就是爆款！弄明白了这个，但我也并没有再发面试相关的内容，一是不再面试了，很难找到真实的素材，二是面试属于热点，但那不属于技术层面的东西，定位于技术，还是要回归技术话题的。 今年公众号发了19篇原创文章，博客保持同步，勉强及格吧。随着公众号人数增多，组建了微信群，我每天在群里给大家分享开发概念讲解和英语翻译技巧（转载）。这也反向督促了我不断学习，成为了一件小有仪式感的事情，即使当天工作任务很重，我也会抽出时间整理学习资料。 个人博客 进行了界面优化，尝试了多套主题之后，最终选择了这个Icarus的主题。为了提高国内的访问速度，购买了腾讯云服务器，并做了域名备案。一番折腾之后，一个小站该有的东西基本齐全了，看着还像那么回事。 时间管理 去年有个目标是提高时间管理能力，因为总有很多想法，又总是无法抽出足够的时间去实施。今年也没有太琢磨时间管理的事，但却做了一件事使得时间富足起来，那就是：戒掉游戏，准确的说是戒掉王者荣耀。 作为王者荣耀16年年初入坑的老玩家，我曾把大量的时间都耗费在了这个游戏里面。我自控力有时真的很差，本来应该适当游戏娱乐一下，但总是控制不住输了想赢回来，赢了想趁手感好再来一局，好几次直接玩到天亮，被放防沉迷限制才放下游戏休息。还容易情绪化，我自认为游戏理解还可以，遇到那种素质和操作差的队友经常互喷起来，然后连着很长一段时间情绪都受游戏影响，因为游戏也被媳妇说过很多次。这种状态肯定是不好的，于是在某天跟队友峡谷对喷过后，我决心退游，到现在应该已经快半年没玩了。没有了王者荣耀，发现自己腰也不疼了，腿也不酸了，一口气可以爬。。。哦，我是住一楼。总之空闲时间被释放了一大部分，这段时间就用来看看书，追追《神盾局特工》，写写博客，很舒服的且可以被自己控制的节奏。 阅读 今年阅读量确有提升，我的阅读主要是从手机和纸质书两方面来。 手机上看了： 《如何成为一个有趣的人》：中心思想是不要努力求”认同“，而要打造完全属于自己的稳固的世界，并敞开欢迎别人来游走参观，而构建自己世界的过程就会产生一些有趣的事情。这本书对我之后决定继续维护公众号也有一定的推动作用。 《从0到1》《算法图解》《我不》《微习惯》《编写可读代码的艺术》《微习惯》 《图说世界格局》：很有意思的一本书，可以了解各个大国的产业结构，发展历史，最主要的是对中东局势有了个大概了解，那里为什么持续的动荡，处理地里位置的特殊，还有很大一部分原因是各个大国之间的博弈，互相牵制。 《RxSwift-Reactive Programming with Swift》：看过的第一本纯英文技术书，也有点像文档。RxSwift相关资料真不多，这是可以作为官方教材的高质量文档，如果想学好RxSwift，可以列为必读。 《SwiftUI 与 Combine编程》：喵神这个pdf小书，把我对响应式的理解完全串起来了。我虽然一行Combine代码都没写过，但我感觉已经对它很了解了。 相比来说，纸质书还是更让人记忆深刻一些，看的有这几本： 《送你一颗子弹》：刘瑜的散文随笔集。这是我媳妇的阅读书目，有那么一段时间，每天早起读十几页，很轻松，很有趣的感觉。 《代码的未来》：前半部分看的很认真，后面因为很多知识基础跟不上，没有读太细。但这本书还是挺推荐的，可以用于扩展知识面，了解多种语言的特性及特征性问题不同语言的处理方式。 《C++程序设计》：是谭浩强那本，在整理杂物时发现了它，突然有股冲突要再看一看当年的教材。重读一遍确实获取到了一些不一样的感受，有些内容依然受用。另外对于网上对谭浩强的质疑，我部分认同，这本书拔高了新手入门计算机的门槛，特别是对指针的讲解和习题的设置，现在的我看来有时也会懵懵的。 《程序是怎样跑起来的》：可以补充一些基础知识，但没感觉有太多收获。姊妹篇的《计算机是怎么跑起来的》和《网络是怎么连接的》还在看，暂不评价。 《跟戴铭学iOS编程》：不推荐 《九阴真经-iOS黑客攻防秘籍》：这本书是掘金征文比赛时送的。这里有一点感受，阅读纸质书的时候，其排版和印刷质量真的影响一个人的阅读体验。在这之前已经买了一本逆向书籍《iOS应用逆向与安全》，当时这本书有点没看进去，但是翻《九阴真经》却能激起我阅读的欲望，后来我总结，应该是这本《九阴真经》印刷质量更好（两本都是正版），纸张更好，更白，确实是这样的0。0 《月亮与六便士》：买的是一本盗版书，印刷质量很差，也导致自己阅读兴趣不高，但还是逼迫着自己看完了，当然是没有太多感触，好吧，我浪费了一本好书。 《QBQ问题背后的问题》：公司领导要求看的，个人感觉还不错，还写了一篇总结性的书评，如果我当了领导我也要求下属看这本书😂 计划回顾与总结 回顾下2020年年初制定的OKR： O1：精进技术栈KR 完成进度 总结刷20道经典LeetCode题目，输出2篇解题思路的文章 50% 刷了一部分题，也达到了20题，但是没有输出文章学习前端知识，优化博客小站 50% 前端只学了很少一部分，博客尝试了三套主题，目前这个是最满意的，中间还升级过两次输出5篇对计算机知识总结的文章 100% 纯技术类文章是超过5篇的维护一个Swift库，用于筛选项目中不用的文件 10% 年初的计划，调研了一段时间时间之后又放弃了O2：个人成长KR 完成进度 总结公众号粉丝达到500 200% 达到1000+学习基金知识，分析对比10种基金的数据表现 10% 对理财还是没提起兴趣0。0全年跑步里程400公里 50% 咕咚记录的有200公里，年中一段时间跑步还是规律，去到爱奇艺就没了跑步氛围阅读15本书 100% 正常完成培养时间规划能力，总结并践行一份时间规划清单 60% 这个目标不可衡量，但是相对于去年时间规划能力还是有不少提升的2021年OKR O1：个人成长 KR1：时间规划能力再提升，完整记录20天以上的时间开销 KR2：阅读20本书，选择其中5本写出读后感 KR3：全年跑步里程400公里 KR4：研究3只头部基金，自己做一次有计划的尝试，最终收益能高于市场平均线 KR5：提升代码阅读量，阅读3个苹果底层库，并写总结分享 KR6：提升代码书写量，非工作内项目达到20万行。有一个长期维护的开源库，对2-3个经典计算机问题，手写代码实现 O2：输出更多优质内容 KR1：公众号粉丝达到5000 KR2：公众号收入能抵消博客服务器及域名的支出 KR3：输出30+篇博客 KR4：摸鱼周报出15+期 注：OKR不一定是固定不变的，我现在的计划也不应该决定之后一年的规划。理想情况应该是每隔一段时间去审视一次计划完成情况，如果发现有另外的计划，或者某项计划不好，都是可以调整的。

CocoaPods是iOS开发中经常被用到的第三方库管理工具，我们有必要深入了解一下它对项目产生了什么影响，以及它是如何管理这些库的。使用pod安装三方库 我们新建一个不带测试模块的名为FFDemo的Swift项目，它的目录结构是这样的 ├── FFDemo │   ├── AppDelegate.swift │   ├── Assets.xcassets │   ├── Base.lproj │   ├── Info.plist │   ├── SceneDelegate.swift │   └── ViewController.swift └── FFDemo.xcodeproj ├── project.pbxproj ├── project.xcworkspace └── xcuserdata然后我们执行pod init创建一个Podfile模板，在里面引入这两个三方库： target 'FFDemo' do # Comment the next line if you don't want to use dynamic frameworks use_frameworks! # Pods for FFDemo pod 'MJRefresh', '~> 3.5.0' pod 'Moya'end成功执行pod install之后我们就将这两个库引入到了项目，这时项目目录变成了这样： ├── FFDemo │   ├── AppDelegate.swift │   ├── Assets.xcassets │   ├── Base.lproj │   ├── Info.plist │   ├── SceneDelegate.swift │   └── ViewController.swift ├── FFDemo.xcodeproj │   ├── project.pbxproj │   ├── project.xcworkspace │   └── xcuserdata ├── FFDemo.xcworkspace │   └── contents.xcworkspacedata ├── Podfile ├── Podfile.lock └── Pods ├── Alamofire ├── Headers ├── Local\ Podspecs ├── MJRefresh ├── Manifest.lock ├── Moya ├── Pods.xcodeproj └── Target\ Support\ Files从目录看，除了pod init引入了Podfile，其余三部分内容：FFDemo.xcworkspace、Podfile.lock、Pods目录都是由pod install之后生成的。我们下面重点讲下这三部分内容。 CocoaPods安装的内容 xcworkspace文件 该文件下包含一个叫contents.xcworkspacedata的文件，它的内容是这样的： <?xml version="1.0" encoding="UTF-8"?> <Workspace version = "1.0"> <FileRef location = "group:FFDemo.xcodeproj"> </FileRef> <FileRef location = "group:Pods/Pods.xcodeproj"> </FileRef> </Workspace>使用xml格式将依赖包含在标签内。 xcworkspace是一个项目容器，当有多个project需要相互依赖时可以用xcworkspace将它们组织起来。pod在首次安装三方库时会生成一个叫Pods.xcodeproj的project管理三方库，然后将该project和主项目的project通过workspace进行关联。这样我们就可以在主工程里引入三方库了，而且三方库由Pods.xcodeproj统一管理，不会对我们原项目产生任何干扰。 Podfile.lock Podfile.lock文件的内容是这样的： PODS: - Alamofire (5.3.0) - MJRefresh (3.5.0) - Moya (14.0.0): - Moya/Core (= 14.0.0) - Moya/Core (14.0.0): - Alamofire (~> 5.0)DEPENDENCIES: - MJRefresh (~> 3.5.0) - MoyaSPEC REPOS: trunk: - Alamofire - MJRefresh - MoyaSPEC CHECKSUMS: Alamofire: 2c792affbdc2f18016e08fdbcacd60aebe1ba593 MJRefresh: 6afc955813966afb08305477dd7a0d9ad5e79a16 Moya: 5b45dacb75adb009f97fde91c204c1e565d31916PODFILE CHECKSUM: 073f3d6d9f03e6a76838ca3719df48ae6cc01450COCOAPODS: 1.9.3因为Podfile文件里可以不指定版本号，而版本信息又很重要，于是就有了Podfile.lock，它里面记录完整的版本信息和依赖关系。它的内容包含以下几大块 PODS PODS是指当前引用库的具体版本号，可以发现我们并没有引入Alamofire，但在PODS里确有它。这是因为Moya中依赖了它，Moya里定义了一个subspec叫Core，这是Moya/Core写法的由来。pod是通过各个库的podspec文件找到对应依赖的，这里可以简单看下Moya的部分podspeec文件内容Moya.podspec： Pod::Spec.new do |s| s.default_subspecs = "Core" s.subspec "Core" do |ss| ss.source_files = "Sources/Moya/", "Sources/Moya/Plugins/" ss.dependency "Alamofire", "~> 5.0" ss.framework = "Foundation" end endDEPENDENCIES DEPENDENCIES为pod库的描述信息，这里内容是同Podfile里的写法。因为我们指定了MJRefresh的版本号，并没有指定Moya的版本号，所以这里内容也是一样的。 SPEC REPOS 这里描述的是仓库信息，即安装了哪些三方库，他们来自于哪个仓库。 trunk是共有仓库的名称，它的地址是https://github.com/CocoaPods/Specs.git，外部使用的三方库大都来自于这里。通常我们还会依赖一些公司内部的私有库，私有库的信息也会显示在这里。 SPEC CHECKSUM 这里描述的是各个三方库的校验和，校验和的算法是对当前安装版本的三方库的podspec文件求SHA1。比如MJRefresh的校验和：6afc955813966afb08305477dd7a0d9ad5e79a16。我们安装的MJRefresh的版本为3.5.0，它在本地的podspec文件路径为：~/.cocoapods/repos/trunk/Specs/0/f/b/MJRefresh/3.5.0/MJRefresh.podspec.json。 这个路径可以通过在安装库时增加 --verbose参数在输出日志里查看。我们对该文件内容通过openssl求sha1摘要： $ pod ipc spec ~/.cocoapods/repos/trunk/Specs/0/f/b/MJRefresh/3.5.0/MJRefresh.podspec.json | openssl sha1 $ 6afc955813966afb08305477dd7a0d9ad5e79a16因为是对podspec.json内容求sha1，所以只要内容发生一点变化，得出的校验和就将大不相同，而这也是校验和设计的目的：podspec文件发生变化意味着版本信息发生了变化，就需要重新同步代码。 大家可能注意到了，我们通常制作私有pod，控制配置信息的文件是podspec格式的，为什么本地文件变成了json格式？ 这是因为json格式兼容性更高也更容易批量处理，官方Spec仓库的所有库配置文件都是被转成json格式的。在我们制作私有库的时候是可以直接以podspec的格式推到远程仓库的，但后续解析文件时pod内部检索还是会把它转成json格式。上面的命令是包含了podsepc转json的命令的，转json命令如下： $ pod ipc spec ModuleName.podspecPODFILE CHECKSUM 这个校验和是针对Podfile内容的校验和，如果Podfile内容改变了，该值也会跟着改变。计算方法为： $ openssl sha1 filePath/PodfileCOCOAPODS: 1.9.3 这个代表当前使用的CocoaPod版本号，远程版本管理应该要保证大家使用的pod版本号一致。 Pods Manifest.lock Manifest.lock是Podfile.lock的副本，它是在Pods目录里面。它的作用是这样的，我们通常是不把Pods文件放到版本管理里面，而把Podfile.lock放到版本管理里面。这时对于拉取代码之后是否需要更新pod，就可以通过对比本地的Manifest.lock和远程Podfile.lock是否相同即可。 Targets Support Files Pods安装的依赖是这样的组织形式一个Pods的Project下面有三个Targets，其中三个是安装的依赖库，最后一个Pods-FFDemo是关联三个库的Framework，也即是Pods这个Project的Targets。 Pods-Demo Framework 先看这个Demo的Framework，它会被用于工程项目的引用依赖这个库不会被打进包里，因为Do Not Embed代表并不是包含的关系。 这个工程下的配置文件有这些：许可协议文件 两个以acknowledgements命名的文件是用于管理pod库的许可协议，即三方库必须带有的LICENSE文件，这也是为什么我们在制作pod时会要求我们指定软件协议。 Framework文件 这里还包含了用于管理Module的modulemap和umbrella.h文件。modulemap是对Module的声明文件，制作Framework我们总是需要该文件，它的内容如下： framework module Pods_FFDemo { umbrella header "Pods-FFDemo-umbrella.h" export * module * { export * } }其指向了一个umbrella的头文件，这是制作Framework必须的头文件，modulemap和umbrella.h会在创建Module时自动生成，不建议手动修改其关系。 dummy.m文件 这其实是一个空的.m文件 #import <Foundation/Foundation.h> @interface PodsDummy_Pods_FFDemo : NSObject @end @implementation PodsDummy_Pods_FFDemo @end那为什么要有这个东西呢，包括所有的三方库的包里也会包含一个dummy文件。我在stackoverflow找到了一个解释：Xcode的编译是依赖.m文件的，如果一个库里没有.m文件，将不会被编译，为了防止这种情况就会在每个库里增加一个空的.m文件。 xcconfig文件 xcconfig文件是Build Setting配置项的文件形式，它的优先级大于Xcode内的Build Setting。看一个pod生成的debug模式下的xcconfig文件。 ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/Alamofire" "${PODS_CONFIGURATION_BUILD_DIR}/MJRefresh" "${PODS_CONFIGURATION_BUILD_DIR}/Moya" GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1 HEADER_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/Alamofire/Alamofire.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/MJRefresh/MJRefresh.framework/Headers" "${PODS_CONFIGURATION_BUILD_DIR}/Moya/Moya.framework/Headers" LD_RUNPATH_SEARCH_PATHS = $(inherited) '@executable_path/Frameworks' '@loader_path/Frameworks' OTHER_LDFLAGS = $(inherited) -framework "Alamofire" -framework "CFNetwork" -framework "Foundation" -framework "MJRefresh" -framework "Moya" OTHER_SWIFT_FLAGS = $(inherited) -D COCOAPODS PODS_BUILD_DIR = ${BUILD_DIR} PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) PODS_PODFILE_DIR_PATH = ${SRCROOT}/. PODS_ROOT = ${SRCROOT}/Pods USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES = YESxcconfig还有个作用是设置参数，比如我们比较熟悉的PODS_ROOT=${SRCROOT}/PODS，它代表项目根目录下的PODS文件目录。另外两项用于帮助我们在项目中查找三方库的FRAMEWORK_SEARCH_PATHS和HEADER_SEARCH_PATHS也是在该文件内部定义的，这些配置会体现到Build Settings里面：三方库的Framework 各个三方库也都有一些配置文件，他们文件格式基本一致，文件作用跟上面介绍的类似，下图是Moya的配置文件，Xcode中Pods > Pods > Moya > Support Files对应的文件就是该内容。我们可以想一个问题，当安装的第三方库需要依赖于别的库时它是如何去找这个库的呢？Moya是需要使用Alamofire的API的，会有import Alamofire的操作。凭借上面的内容，可以得知Framework的引用是需要在Build Setting里提前该Target，有哪些引用项的。所以这也是Framework里xcconfig文件的作用，可以在Moya的xcconfig文件里找到这个： FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/Alamofire"而且引用的是跟主项目同一个Alamofire的路径。 Build Phases这里是设置编译阶段配置的地方，当首次pod install成功之后，这里会多几个[CP]开头的配置项（CP即CocoaPods缩写），它们都是由CocoPods添加的脚本内容，执行顺序从上到下。 New System Build 在讲编译脚本之前简单说下New Build System。 New Build System是Xcode10之后苹果推出的新的构建系统，新的构建系统对编译流程的优化做了很多工作，虽然到Xcode12仍兼容旧版的Legacy Build System，但其已经被标记为移除，我们的项目和库都应该使用新版的构建系统进行构建。和新的构建系统随之而来的是在运行脚本时增加的输入输出列表。这是为了控制是否每次编译都需要执行对应脚本，input和output文件可以是单个文件形式，如果文件过多可以放到格式为xcfilelist的文件列表里。 如果没有提供input和output，则每次构建都会运行该脚本。如果提供了，则会在以前从未运行过、某个输入文件被更改或某个输出文件丢失的情况下再次运行。 注意这些是构建脚本的默认逻辑，Xcode还提供了Run Scripts的自定义行为，默认勾选项：Based on dependency analysis，即代表上述逻辑。如果提供了输入输出还需要每次运行，关闭该选项即可。 [CP] Check Pods Manifest.lock 该脚本位于较上方，如果没有Dependencies，开始编译就会执行该脚本，它的内容如下： diff "${PODS_PODFILE_DIR_PATH}/Podfile.lock" "${PODS_ROOT}/Manifest.lock" > /dev/null if [ $? != 0 ] ; then # print error to STDERR echo "error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation." >&2 exit 1 fi # This output is used by Xcode 'outputs' to avoid re-running this script phase. echo "SUCCESS" > "${SCRIPT_OUTPUT_FILE_0}"作用是比较Podfile.lock和Manifest.lock文件是否相同，如果不同就输出错误信息：error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.，并执行退出，这会导致后续项目报错，无法继续编译。 该错误较常见，出现于拉取远端代码，远端pod依赖于本地不一致的情况。这时我们可以根据提示，执行pod install命令，根据Podfile及远端Podfile.lock生成新的Manifest.lock文件。 [CP] Copy Pods Resources 这个一般在以静态库引入的三方库切里面包含资源的话会添加该脚本，其作用是将三方库的资源文件拷贝至项目中。 它的完成是通过运行以下脚本进行的： "${PODS_ROOT}/Target Support Files/Pods-FFDemo/Pods-FFDemo-resources.sh"Pods-FFDemo-resources.sh文件在Pods目录内，该脚本内有个关键函数install_resource： install_resource() { if [[ "$1" = /* ]] ; then RESOURCE_PATH="$1" else RESOURCE_PATH="${PODS_ROOT}/$1" fi if [[ ! -e "$RESOURCE_PATH" ]] ; then cat << EOM error: Resource "$RESOURCE_PATH" not found. Run 'pod install' to update the copy resources script. EOM exit 1 fi case $RESOURCE_PATH in *.storyboard) ibtool --reference-external-strings-file --errors --warnings --notices --minimum-deployment-target ${!DEPLOYMENT_TARGET_SETTING_NAME} --output-format human-readable-text --compile "${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/`basename \"$RESOURCE_PATH\" .storyboard`.storyboardc" "$RESOURCE_PATH" --sdk "${SDKROOT}" ${TARGET_DEVICE_ARGS} ;; *.xib) ibtool --reference-external-strings-file --errors --warnings --notices --minimum-deployment-target ${!DEPLOYMENT_TARGET_SETTING_NAME} --output-format human-readable-text --compile "${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/`basename \"$RESOURCE_PATH\" .xib`.nib" "$RESOURCE_PATH" --sdk "${SDKROOT}" ${TARGET_DEVICE_ARGS} ;; *.framework) echo "mkdir -p ${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}" || true mkdir -p "${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}" echo "rsync --delete -av "${RSYNC_PROTECT_TMP_FILES[@]}" $RESOURCE_PATH ${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}" || true rsync --delete -av "${RSYNC_PROTECT_TMP_FILES[@]}" "$RESOURCE_PATH" "${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}" ;; *.xcassets) ABSOLUTE_XCASSET_FILE="$RESOURCE_PATH" XCASSET_FILES+=("$ABSOLUTE_XCASSET_FILE") ;; *) echo "$RESOURCE_PATH" || true echo "$RESOURCE_PATH" >> "$RESOURCES_TO_COPY" ;; esac }删除了一部分日志内容，其内部主要是一个switch语句，根据资源文件的类型进行不同的同步操作。这里重点说下几种重要格式文件的处理方式。 storyboard和xib格式 这两项资源文件是需要编译处理的，利用ibtool命令分别转成sotryboardc和nib格式。 xcassets格式 这里的图片最终会被打包到Assets.car供程序使用，需要使用actool。 Bundle、plist、png等资源 其他类的资源是会走到switch语句最后出口，进行资源路径赋值给$RESOURCES_TO_COPY，在后面的代码中通过rsync命令，将资源同步到构建包的目录。 该脚本会打印很多日志，在使用CocoaPods时如果遇到资源相关的问题都可以遵循错误日志来这里推测定位错误原因。 [CP] Embed Pods Frameworks 该处脚本是直接运行Pods-FFDemo-frameworks.sh。 "${PODS_ROOT}/Target Support Files/Pods-FFDemo/Pods-FFDemo-frameworks.sh"可能你还记得上面说的pod会把多个库的依赖做成一个合并的库，但该库是以依赖的形式引入主工程，但是程序的运行时需要这些库，我们打包时就需要将各个库Embed到项目里，而做这个工作的就是该脚本。 # Copies and strips a vendored framework install_framework() { rsync --delete -av "${RSYNC_PROTECT_TMP_FILES[@]}" --links --filter "- CVS/" --filter "- .svn/" --filter "- .git/" --filter "- .hg/" --filter "- Headers" --filter "- PrivateHeaders" --filter "- Modules" "${source}" "${destination}" # other code... # Strip invalid architectures so "fat" simulator / device frameworks work on device if [[ "$(file "$binary")" == *"dynamically linked shared library"* ]]; then strip_invalid_archs "$binary" fi # Resign the code if required by the build settings to avoid unstable apps code_sign_if_enabled "${destination}/$(basename "$1")" }脚本内容主要是调用install_framework函数，将framework内容同步到构建包里。在该函数里还有几个关键方法，strip_invalid_archs用于去除无用架构，code_sign_if_enabled用于framwork签名。

前置说明 一直以来都是用GithubPage搭建的博客，因为服务器在国外，访问速度一直比较慢，再后来有一批服务器被墙掉了导致国内网络环境直接无法访问。这里可以多说一句，GithubPage跟Github用的可以不是同一IP地址服务器，被墙很多是通过锁定IP进行的，GithubPage搭建博客有些可以访问有些不可以，就是因为某些IP被封了，如果更换IP也是可以解决的，但访问速度还是不够快。前段时间看到腾讯云服务器打折，就考虑如果想保证国内的访问速度还是要将服务器迁移到国内来。 这篇文章的作用是对搭建博客做一个整体介绍，对博客中用到的方案进行一些比较，有些会写的比较简略还需要再转到别文章去看，另外重点会写一下迁移腾讯云及域名备案需要做的具体操作。 博客的搭建一般需要关注这五个部分：博客框架、域名、服务器、图床、Markdown工具。各个环节都有免费和付费版本的选择，一般来说免费能满足基本需求，付费则能提供更优质的体验，如何选择就看大家的需求了。这五部分的对比如下：付费版本 免费版本博客框架 Wordpress（部分内容付费） Hexo/Jekyll域名 万网/腾讯云 freenom/dot.tk内容托管平台 阿里云/腾讯云 GithubPage/GiteePage图床 七牛/又拍 Github/GiteeMarkdown工具 MWeb Typora接下来会围绕这五部分展开说明。博客框架 当前热门的方案是Hexo和Jekyll，Hexo是基于Node.js开发的，Jekyll是基于Ruby开发的，他们的作用都是将Markdown语法的内容转译成HTML，并根据配置的主题进行显示。 Wordpress 功能更强大，且相比前两个方案更简单，它可以不依赖Markdown语法，直接选用模板进行线上编辑即可。我对Wordpress摸索的较少，它的优缺点不便于多说，但还是推荐大家拿来试试。 这里介绍几个使用上述方案搭架的博客，大家可以参考看下： Jekyll：https://onevcat.com/，https://draveness.me/ Hexo：http://blog.sunnyxx.com/，https://zhangferry.com/ Wordpress：http://blog.cnbang.net/ 网站样式的差别不是由框架决定的，而是主题，以上三者都有大量的主题可供选择。我使用的是Hexo，使用方法可以参考这篇：基于Hexo搭建自己的博客小屋。 域名 域名选择 免费版本 免费版本域名，像freenom和dot.tk，一般都有固定的使用时间，一般为一年左右，超过一年还想使用就需要付费了。 如果依赖GithubPage 或者 GiteePage 这样的托管服务，我们是可以设置像username.github.io或username.gitee.io这样的域名。 如果想尝试GithubPage的话，也可以参考这篇基于Hexo搭建自己的博客小屋 付费版本付费版本的域名可以是我们常见的.com、.cn、.net等，可以到万网或者腾讯云进行购买，一般可选1-10年使用期限。 域名备案 不是所有域名都需要备案的，如果网站服务器在国外是不需要备案的，在国内是需要备案的。GithubPage服务器在国外，使用域名不需要备案；如果要使用国内服务器，腾讯云或者阿里云等则需要备案。 以下是腾讯云的域名备案流程：主要步骤都可以通过备案小程序进行。 备案申请条件首先会提交到腾讯云后台，由他们进行一个初审，如果没有通过他们会联系你，并告知你哪里需要修改，修改之后可以再次提交。 我在初审时遇到了两个问题： 1、域名备案时需要是不可访问状态，如果当前正在使用，需要停止解析。 2、网站描述不能包含博客字样，可以用学习笔记代替。 腾讯云的初审通过之后，他们会将备案信息提交至管局。管局的审核会久一些，一般是20个工作日之内，我的审核时间用了16天。 备案号 审核通过之后会获得一个备案号，我们需要在网站底部加上这个备案号并附带链接到域名信息备案管理系统，备案号可以在腾讯云的备案管理界面查看。这里会会有两个地方显示备案号：主体信息和已备案网站。主体信息是自然人或单位的意思，已备案网站是针对网站的，因为一个主体可能会用到多个网站，所以网站备案号是以主体备案号为基础加上自然序号。如果再次备案域名，新的备案号会是主体备案号-2的形式。我们网站中出现的备案号应该是网站备案号，即京ICP备2020035857号-1。 接下来需要在网站中添加备案号，如果你使用的是Hexo或者Jeklly框架，可以在主题文件目录下搜索Powered by，找到对应的底栏配置文件。我使用的Icarus主题，其底部文件为footer.jsx，找到对应位置添加： <a href="https://beian.miit.gov.cn/" target="_blank" rel="noopener">&nbsp;京ICP备2020035857号-1</a>效果如下：公安备案 在网站开通后的30日之内还需要进行公安备案，登录网站全国互联网安全管理服务平台，填写信息。因为是政府网站，开代理一般无法访问，需要关闭代理，如果仍无法访问，可能是DNS污染了，可以将DNS服务器设置成114.114.114.114再次刷新网站。登录之后注册、登录并填写开办者信息：这里会有很多坑，我尝试了很多次均已失败告终，直到现在也没成功，如果有知道怎么搞定的小伙伴可以告诉我，以下记录一些解决的坑：图片选择时需要开启Adobe Flash 对身份证的识别好像是通过图片比例进行的，拍出来的身份证照片需要把多余的内容剪裁掉，只保留身份证主体内容 手持身份证照片如果不能验证通过可以按照实例图片剪裁成一定比例或者换个白色背景拍照 常住地址第二和第三个选项框有时无法弹出，这个只能不断刷新尝试，我隔几天再试地区弹框才能展开 填完之后点提交审核一直加载，1分钟之后还是卡着不动，试了几次都是同样的问题，这一步一直没成功公安备案我看很多网站也没有写，所以暂时也不打算管了。这里可以告诉大家公安备案是指什么，以掘金为例：上面箭头指向的津ICP备是网站备案号，京公网安备指的是公安备案，下面这个即是公安的备案号，很多博客网站都没有写好像重要性不是很大。 域名解析 域名解析可以使用腾讯的DNSPod，因为我之前做过从GithubPage服务器的域名解析，这里只需将原来指向GithubPage的服务器IP地址该为自己的服务器地址即可。 关于域名的配置可以参考我之前的一篇博客：为博客设一个自定义域名 以下是我的域名解析配置，被擦掉的内容为服务器IP地址：全球递归DNS服务器的刷新不超过72小时，我们验证解析是否生效可以通过 ping zhangferry.com命令进行，如果展示的ip地址是我们修改后的ip地址，就证明域名解析已经生效。 服务器 云服务器选择 分为免费和付费版本，其实免费版不属于服务器，只不过起到一个服务器托管的作用。 免费版本 Github的GithubPage和码云的GiteePage是两个比较常见的静态网页托管服务。这里简单总结下两者的特点：对比项 GithubPage GiteePage默认域名 username.github.io username.gitee.io自定义域名 支持 免费版不支持，付费版支持访问速度 国内无法访问，翻墙之后访问速度也较慢 国内可访问，但访问速度较慢热度 较高，有很多开发者使用这个方案 较低，使用者较少如果你刚打算写博客，想尝尝鲜，我的建议是先从这俩平台中选一个，玩一玩。如果有长期维护的打算，并期望保证一定的用户体验，还是得购买服务器的。 付费版本 可供选择的阿里云和腾讯云，我选的是腾讯云，阿里云也是同理。 购买时我们需要指定操作系统，服务器的话一般都是Linux。有两种比较流行的Linux发行版：Ubuntu和CentOS，这两者在包管理工具上是不一样，在后面的安装工具过程中需要注意这一点。Ubuntu上用的包管理工具是apt-get，CentOS用的包管理工具是yum。 我选择的是CentOS，服务器创建完之后就可以登录了。腾讯云有两种登录方式 1、通过腾讯云网页端SSH登录，首次登录需设置密码，登录成功之后会进入一个远程终端页面，这里的登录时通过root用户登录的。 2、本机SSH登录，通过ssh root@host-ip的形式进行登录，之后需要输入首次登录创建的root用户密码。本机SSH可选择其他用户登录。 服务器配置 之后的配置和命令设置有些是在远程服务器操作的，有些是本地操作，下面会以remote$和local$开头进行区分，ip地址以host-ip的形式展示，用户名以zhangferry的形式展示。 安装依赖与Git 首先登录服务器，安装一些依赖工具。 1、安装依赖库 remote$ yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel2、安装编译工具 remote$ yum install gcc perl-ExtUtils-MakeMaker package3、安装Git 虽然Linux发行版一般都装有Git，但是很多版本都比较旧，我们需要一个相对新的Git版本，所以需要安装最新版本的Git。 查看Git版本 remote$ git --version如果看到的版本是2.0之前的，那就升下级吧。 删除旧版Git remote$ yum remove git由于yum跟git版本更新不一致，可以选择源码编译升级，如果嫌麻烦也可以选择yum升级。当前最新版本是2.28.0。如果选择yum升级可以使用yum install git，逃过源码升级这一步即可。 源码升级 选择一个目录来存放下载下来的 git 安装包。这里选择了/usr/local/src 目录，我们进入到这个目录 remote$ cd usr/local/src下载Git压缩包至这个目录 remote$ wget http://ftp.ntu.edu.tw/software/scm/git/git-2.28.0.tar.gz解压到当前目录 remote$ tar -zvxf git-2.28.0.tar.gz进入解压的目录，并编译 remote$ cd git-2.28.0 remote$ make prefix=/usr/local/git all安装 git 到 /usr/local/git 目录下 remote$ make prefix=/usr/local/git install设置Git环境变量，即可以在命令行找到Git命令，你可以试下 remote$ git --version如果看到的版本号是我们安装的2.28.0，即证明当前环境变量设置正确，如果现实comond not found，我们需要修改环境变量使终端能够找到git命令。 使用vim打开 remote$ vi /etc/profile按i进入编辑模式，在文件末尾增加下面内容 PATH=$PATH:/usr/local/git/bin # git 的目录 export PATH保存退出再次查看git版本号，应该就变成我们安装的版本了。 创建新用户 创建用户的目的是为了便于分配权限，该用户用于远程登录，并推送网站内容。我们也可以直接用root用于进行直接登录，如果嫌创建用户麻烦，可以跳过这一步。 创建用户zhangferry，并设置连接密码： remote$ adduser zhangferry remote$ passwd zhangferry #该命令回车输入密码，有二次确认获取sudoers文件的编辑权限 remote$ chmod 740 /etc/sudoers remote$ vim /etc/sudoers按 i 键进入文件的编辑模式，按向下键找到如下字段： root ALL=(ALL) ALL在其后面增加一句： zhangferry ALL=(ALL) ALL即我们新建的用户拥有了超级用户的权限，之后退回sudoers文件的编辑权限： remote$ chmod 400 /etc/sudoers切换用户的命令是： remote$ su zhangferry #su root切换root用户这时我们可以在本机使用ssh命令，试下是否可以通过zhangferry用户成功登录，需要我们输入刚才为zhangferry用户设置的密码： local$ ssh zhangferry@host-ip每次输入密码很麻烦，可以通过秘钥，进行免密登录。 SSH登录 这一步是非必须的，但推荐这样做，这会省去我们后面输入密码的操作。 1、本地生成秘钥，一般指定RSA加密算法，会生成一对公钥私钥。 local$ ssh-keygen -t rsa -C "zhangferry11@gmail.com" #这里邮箱需要换成自己的如果已经生成过，不要再次生成了，因为它会覆盖我们原有的秘钥，导致之前的秘钥配置失效。检验方式是： local$ cat ~/.ssh/id_rsa.pub秘钥的位置是在.ssh文件夹内，如果有输出内容说明我们已经生成过。 2、复制ssh公钥至远程主机的~/ .ssh/authorized_key文件里 local$ ssh-copy-id root@host-ip如果提示失败或者无文件，需要手动生成同名文件，将内容复制进去即可。 3、测试连接 local$ ssh zhangferry@host-ip如果命令行左侧内容显示为带有[centos]或者标记我们远程服务器的字样即代表登录成功。创建git仓库和网站目录 1、这一步的目的是创建git仓库，本地博客内容需要推送至这里。 remote$ su root #在root权限里操作 remote$ mkdir /home/zhangferry remote$ mkdir /home/hexo #网站目录 remote$ cd /home/zhangferry remote$ git init --bare blog.git #创建git裸仓库裸仓库的意思就是只保留git提交记录，不保留文件内容。 2、创建一个git的post hook，用于自动部署。这一步的作用是在我们往服务器推送仓库时，将内容转移到网站目录，因为裸仓库是不包含内容的。 remote$ vi blog.git/hooks/post-receivehooks文件是git自动生成的目录，里面有很多用于编辑hook的示例，其中post-receive用于在push操作的hook。它的内容如下： #!/bin/sh git --work-tree=/home/hexo --git-dir=/home/zhangferry/blog.git checkout -f这里需要注意，work-tree对应工作区的目录即网站目录，git-dir对应git仓库位置，如果你有自定义的命名，记得修改这两处地方。 这里大家可以想一下为什么要将git目录和网站目录分开处理，如果不分开也是可以的。我的理解是分开是为了便于权限管理，git的操作一般会是一个单独的用户权限，很多人都可以操作git，它对网站的影响是间接的，而网站内容的权限应该更高一些，只有root才可以直接操作。所以就将两者分开了。 3、修改git仓库权限 只需要将git仓库放权给zhangferry用户，网站目录的更新由post hook完成。 remote$ cd /home/zhangferry remote$ chown zhangferry:zhangferry -R blog.git # blog.git的拥有者为zhangferry remote$ chmod +x blog.git/hooks/post-receive # 修改post-receive为可执行安装Nginx Nginx是一个高性能的HTTP和反向代理web服务器，这里我们只将其作为HTTP web服务器使用。 1、安装nginx remote$ yum install -y nginx2、修改配置文件 remote$ vi /etc/nginx/nginx.conf修改内容如下： server { listen 80 default_server; listen [::]:80 default_server; server_name zhangferry.com; #博客域名 root /home/hexo; #网站目录 # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }我们只需要修改server里的server_name和root选项，他们分别代表博客域名和网站目录。 listen代表监听端口，http默认监听的是80端口。error_page代表出错之后的展示页面，无数据的40x.html和服务器错误的50x.html都可以在这里指定。 3、nginx的几个命令 remote$ start nginx #启动nginx remote$ nginx -t #检测配置文件是否有语法错误 remote$ nginx -s reopen #重启nginx remote$ nginx -s stop #退出nginx正常的流程应该是当我们修改完nginx的配置文件，先用nginx -t检测下是否有错误的配置，它还会检测一些待修复但不影响运行的警告信息，如果有错误需要修改再次检测。当配置没有问题了需要启动nginx：start nginx，之后的配置修改需要重启nginx：nginx -s reopen。 4、启动检测 nginx启动之后我们就可以在本地浏览器输入http://host-ip:80 进行访问，这时我们看到的应该是一个nginx的缺省页，因为/home/hexo目录并没有任何内容。 上传Hexo博客内容至腾讯云 修改博客根目录里_config.yml文件的deploy配置： deploy: type: git repo: zhangferry@host-ip:/home/zhangferry/blog.git #上面配置的裸git目录 branch: master部署hexo，并推送： local$ hexo g local$ hexo d #发布hexo会触发push操作，将repo推送至我们配置的git路径有可能你会出现bash: git-receive-pack: command not found这样的错误，command not found是一种常见的问题，上面的意思是在服务器方git-receive-pack命令无法找到。简单扩展下，git push内部分为两步，本地运行send-pack，它会判断哪些提交记录是它有但服务器没有的，然后它告知服务器端的receive-pack本次更新内容，receive-pack接收推送来的数据。网上对这一问题的解决方式是通过ln关联git-receive-pack： remote$ sudo ln -s /usr/local/git/bin/git-receive-pack /usr/bin/git-receive-pack/usr/local/git/bin/git-receive-pack为实际的命令路径，/usr/bin/git-receive-pack为创建的快捷路径，但我并不能通过这个方法解决。 但从错误本身出发，命令安装了却找不到一般都是环境变量的问题，我直接修改环境变量： remote$ su zhangferry #如果使用子用户推送的，需要切换至该用户 remote$ vi ~/.bashrc在.bashrc底部增加export PATH=$PATH:/usr/local/git/bin，然后更新环境变量： remote$ source ~/.bashrc再次部署hexo，应该就会成功了。 local$ hexo d我一开始想到了修改环境变量，但是在root下修改的，而root和zhangferry是两个隔离的环境变量配置！ 关于环境变量文件之间的关系有一张图可供参考：/etc/bashrc目录下的配置是全局的，~/.bashrc 下的配置只针对当前登录的用户。所以对于上面环境变量的修改，我们在全局或者zhangferry用户下修改都是可以的。 推送成功之后再次浏览器访问http://host-ip:80，如果我们域名DNS解析生效，直接访问http://zhangferry.com也一样，如果能正常显示博客首页即证明我们迁移成功了。 HTTPS支持 这一步是非必须的，如果你不打算使网站支持https到这里就可以结束了。支持HTTPS需要三步： 1、申请SSL证书 2、将证书上传至服务器 3、配置Nginx关联SSL证书 以下是对这三步的详细说明。 申请SSL证书 腾讯云有免费的https证书可以申请，有效期只有一年，过期需要再申请。这个申请流程很快，一般1个小时左右，如果时间过长，比如超过了一天，可以再次申请，这样他们会很快通过你的申请，并打回最早那次申请（我就是遇到了这种情况0。0）。 上传证书至服务器 证书通过之后有一个下载按钮，下载下来是一个包含多种服务器类型的证书文件。我是使用Nginx搭建的服务器，所以找到Nginx目录里的证书文件，它有两个：.crt后缀和.key后缀。 1、我们还需要在Nginx目录创建一个文件夹，用于存放这些证书： remote$ cd /etc/nginx/ remote$ mkdir ssl2、使用scp命令上传本地证书文件至服务器： local$ scp /path/filename zhangferry@host-ip:/etc/nginx/ssl/修改Nginx配置 网上相关教程很多，都是上来就告诉你怎么改，并没有说明其中的关系和原因，这样很容易因为一些配置环境不同导致错误。 我简单总结下：nginx有一个默认配置是通过nginx.conf控制，我们可以将证书配置写到这里面。但一个服务器允许配置多个域名，只有一个配置文件是不够的，解决方案是在conf.d目录下建一个以域名命令的.conf配置文件，它可以用来管理单独的域名，这两个配置文件是同级别的会一起生效。 我是移除了原有nginx.conf的配置项内容，将端口和证书的配置都写到了conf.d下的zhangferry.conf里。 nginx.conf内容： server { listen 81 default_server; listen [::]:81 default_server; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }这里移除了server_name和root，因为我们要在zhangferry.conf里配置监听，所以这里的配置项都去掉；将监听端口改成了81，是为了避免两处配置一样的端口引起警告。 zhangferry.conf内容： server { listen 80; server_name zhangferry.com; root /home/hexo; #重定向设置，如果使用http访问会重定向至同路径的https链接 rewrite ^(.*)$ https://$host$1 permanent; }server { listen 443 ssl; #证书位置，需跟自己证书位置对应 ssl_certificate /etc/nginx/ssl/1_host.com_bundle.crt; ssl_certificate_key /etc/nginx/ssl/2_host.com.key; #绑定域名 server_name zhangferry.com; root /home/hexo; #ssl配置，以下几项必须要有 ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { } }分别为80和443接口进行配置，配置完之后通过以下命令验证配置是否有问题： remote$ nginx -t -c /etc/nginx/nginx.conf如果出现test is successful字样即是没问题。 重启nginx服务器： remote$ nginx -s reopen访问https://zhangferry.com和http://zhangferry.com验证是否生效，如果出现加锁即证明配置成功了：图床 图床选择 图床一定要考虑持久性，像是免费的临时方案和存到一些非图床的网站上都是不靠谱的。我们访问某些博客时应该遇到过图片开裂无法查看的情况，这些都是因为之前使用的图片存储被删除或者被更改了位置导致的。我的博客之前是用的简书的图床，现在很多也都无法查看了。所以下面介绍的方案会优先考虑存储的稳定性和持久性。 免费版本 免费版有Github和Gitee可供选择，即把git仓库当做图片存储。 Github做图床时加载速度会比较慢，这个可以通过 jsDeliver 这个CDN服务进行解决，我之前很多github的图片链接都换成了通过jsDeliver的CDN链接。 另外一个方案是Gitee，这个正常使用就可以了，因为服务器在国内，访问速度还是比较快的。但Gitee有一个限制，图片超过1M就无法显示了，所以对于一些特定图片我们需要做好剪裁和缩放。 Github+jsDeliver和Gitee都是比较推荐的图床方案。 付费版本 有七牛云，又拍云，腾讯云可供选择，付费版能提供更快的访问速度和更高的稳定性，但因为上面的免费方案已经满足我的需求了，所以就没做这些尝试，不同图床方案使用起来基本一致。 图床工具 图床的使用最好搭配一些趁手的工具，使我们可以通过截屏，拖动等操作轻易的上传指定图片至图床，这个工具就是PicGo。有一个配置教程可以参考：一次艰难的图床选择经历(MWeb+PicGo+Github)。 这个是一年前的文章，现在我使用的方案Typora+PicGo+Gitee，他们之间并没有太大的变化。 Markdown工具我之前使用的是MWeb，但MWeb功能有点太多了，直到发现Typora，我一眼就相中了这个界面简洁的Markdown编辑工具，关键还是免费的，爱了爱了。别看Typora界面简洁其实功能不少，它可以搭配PicGo插件一起使用，使图片的管理更加简便。因为是工具型东西，就不写教程了，大家多多摸索应该就会了。

背景 MP4是我们常见的视频格式，往往我们在播放服务器视频时直接就是请求的MP4视频源。但其实这样并不好，MP4头文件[ftyp+moov]较大，初始化的播放需要下载完整的头文件并进行解析，之后再下载一定长度的可播视频片段才能进行播放。另外随着视频尺寸的增大头文件也会不断变大，这个初始播放时间也会更长。针对这种情况需要一种能加快视频初始解析的方法，HLS就是苹果提出的用于解决这种问题的方案。HLS HLS为HTTP Live Streaming的缩写，是由苹果公司提出的基于HTTP的流媒体网络传输协议，它可以同时支持直播和点播，还支持多清晰度、音视频双轨、字幕等功能。它的原理是将一整条视频分成多段小的视频，完整的播放是由这一个个片段拼接而成的。 HLS在移动端使用很广泛，当前支持HLS协议的客户端有：iOS 3.0及以上，AVPlayer原生支持HLS Android 3.0及以上 Adobe Flash Player 11.0及以上它的大致原理是这样的：1、采集音视频 2、在服务器编码音视频 3、编码后以MPEG-2的传输串流形式交由切片器（Stream Segmenter） 4、切片器创建索引文件和ts播放列表，索引文件用于指示音视频位置，ts为真实的多媒体片段 5、将上一步资源放到HTTP服务器上 6、客户端请求该索引文件进行播放，可以通过索引文件找到播放内容 参考资料：HTTP Live Streaming Document M3U8 实现HLS的一个关键步骤是上面的第四步，即索引文件和ts播放列表的组织。这里用到的就是M3U8格式。M3U8是Unicode版本的M3U，8代表使用的是UTF-8编码，M3U和M3U8都是多媒体列表的文件格式。 接下来我们以一条WWDC里的视频为例，看下M3U8格式是什么样子的，下文展示的并非M3U8格式所有字段，但会包含常用的字段，也足以帮助我们理解M3U8这一格式。 播放页面为：https://developer.apple.com/videos/play/wwdc2019/507 ，通过Charles进行抓包，我们可以得到视频播放过程中的M3U8文件。在分析这个路径格式前，我们需要知道 M3U8 是有两种格式的，一种是作为主播放列表（Master Playlist）存在，它里面包含了音视频、字幕的一些说明和路径，主列表指示的路径是另一个M3U8文件，即另一个格式，作为播放存在的，它里面也有路径，指示的是片段（ts）文件，片段文件是真正的多媒体内容。 看抓包内容，hls_vod_mvp.m3u8为主列表文件，上面的0640.m3u8为视频列表文件。 M3U8格式说明 有时做测试，或者一些特殊情况时我们可能需要手动修改M3U8文件内容，所以需要对它的格式有一定的了解。该格式的定义写在RFC 8216号文件里，以下是一些注意事项：M3U8文件必须以UTF-8进行编码，不能使用 Byte Order Mark（BOM）字节序， 不能包含 utf-8 控制字符（U+0000 ~ U_001F 和 U+007F ~ u+009F） M3U8文件内容的每一行要么是空行，要么是一个URI，要么是以#开头的字符串，不能出现空白字符。 内置标签都是#EXT开头的字符串，大小写敏感。 URI为内容路径，可以是相对路径也可以是绝对路径Master M3U8 列表文件主M3U8索引文件，一般用于指定多个索引源。我们先分析下该主m3u8文件hls_vod_mvp.m3u8的内容，它的头部是这样的 头部格式 #EXTM3U #EXT-X-VERSION:7 #EXT-X-INDEPENDENT-SEGMENTS#EXTM3U表明该文件是一个M3U格式，所有的M3U格式文件都应该把该内容放置到第一行。 #EXT-X-VERSIOn指示播放列表的兼容版本，当前为7。 #EXT-X-INDEPENDENT-SEGMENTS该标签表明对于一个媒体片段中的所有媒体样本均可独立进行解码，而无须依赖其他媒体片段信息。 字幕格式 再往下的内容是一些字幕说明，字幕内容不是必须的。 #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="eng",URI="subtitles/eng/prog_index.m3u8" #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subsC",NAME="English",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="eng",URI="subtitles/engc/prog_index.m3u8"#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Japanese",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="jpn",URI="subtitles/jpn/prog_index.m3u8" #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subsC",NAME="Japanese",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="jpn",URI="subtitles/jpnc/prog_index.m3u8"#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="Chinese",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="zho",URI="subtitles/zho/prog_index.m3u8" #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subsC",NAME="Chinese",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="zho",URI="subtitles/zhoc/prog_index.m3u8"#EXT-X-MEDIA用于指定相同内容的多语言媒体列表资源。 TYPE为资源类型，可选内容有：AUDIO、VIDEO、SUBTITLES、CLOSED-CAPTIONS。 上面内容设置的是TYPE=SUBTITLES，即为字幕类型。 GROUP-ID为多语言翻译所属组，为必选参数 NAME为翻译流可读的描述信息，该值对应AVMediaSelectionOption的displayName。 DEFAULT，AUTOSELECT，FORCED为三个BOOL值分别对应如果缺少必要信息时是否默认选中该翻译流，用户没有显示设置时播放该播放流，FORCED只针对字幕类型有效，用于标记当前自动选择该翻译流。 LANGUAGE用于指定语言类型，它是根据[ISO 639 语言码](https://www.w3.org/WAI/ER/WD-AERT/iso639.htm “ISO 639 语言码”)标准设置的。系统默认的播放器在选择字幕时，展示的字幕列表名称是根据这个值设定的。 URI为该资源的定位信息，在这里其对应的是一条字幕的M3U8文件。subtitles/eng/prog_index.m3u8是一个相对路径， 通过以上信息，我们可以分析出上面内容的含义为：当前视频支持三种字幕：英文，日文，中文。但每种语言都有两条EXT-X-MEDIA信息，他们的区别是分组不同，一个在subs分组，一个在subsC分组。为啥有两个分组，这个后面再说。 视频格式 再往下看，为视频内容的索引： #EXT-X-STREAM-INF:BANDWIDTH=827299,AVERAGE-BANDWIDTH=747464,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=29.970,AUDIO="program_audio",SUBTITLES="subs" 0640/0640.m3u8 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=360849,AVERAGE-BANDWIDTH=320932,CODECS="avc1.64001f",RESOLUTION=640x360,URI="0640/0640_I-Frame.m3u8"EXT-X-STREAM-INF：该属性指定了一个备份源，即视频播放路径和一些视频的信息，以下是对应内容的配置： BANDWIDTH为峰值比特率， 827299，为827299bit/s，即最高峰值时每秒消耗流量101KB。 AVERAGE-BANDWIDTH为平均比特率，747464 CODECS为编码信息，avc1.64001f,mp4a.40.2，avc代表的是h264编码格式，后面的64001f，是由16进制表示的编码参数，64，00，1f分别代表三个不同的参数值。mp4a是一种音频编码格式，后面的40.2代表音频的编码参数。 RESOLUTION为视频分辨率，当前一条视频源分辨率为640x360。 FRAME-RATE为最大帧率，29.970 代表当前播放的最大帧率为每秒29.970帧。 AUDIO是音频所在组，program_audio为对应音频组的名称。 SUBTITLES指示对应的字幕分组，subs为对应字幕组的名称。上面的字幕信息有个GROUP-ID，该值与之对应。 URI为内容路径，0640/0640.m3u8对应的就是该视频源的m3u8文件路径。这个可以在抓包信息里看到。 在EXT-X-STREAM-INF下面是EXT-X-I-FRAME-STREAM-INF，表示播放列表文件中包含的多媒体资源的I帧（关键帧）。因为I帧只是一个画面，所以它不包含音频内容，其余参数跟视频内容格式一致。 在之后就是对应不同分别率的视频源，1920x1080、1280x720、960x540、480x270，因为HLS会根据网络情况自行切换清晰度，所以一般会准备多个清晰度以供选择。根据抓包数据分析，播放的第一个片段是640清晰度的，之后的第2-8个片段为480清晰度，再之后又切换到了640清晰度。 音频格式 再往下看是对应音频的索引 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="program_audio",LANGUAGE="eng",NAME="Alternate Audio",AUTOSELECT=YES,DEFAULT=YES,URI="audio1/audio1.m3u8"#EXT-X-MEDIA上面出现过，为多语言没提列表。 TYPE=AUDIO，这次类型为音频。 GROUP-ID为分组ID，对应EXT-X-STREAM-INF里的AUDIO内容。 URI=audio1/audio1.m3u8对应音频路径。 不同编码格式的备用源 在该主M3U8文件中我们还能看到一条640分辨率的视频源，它与上面的640分辨率还不一样，它的内容是这样的： #EXT-X-STREAM-INF:BANDWIDTH=1922391,AVERAGE-BANDWIDTH=1276855,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.H150.B0,mp4a.40.2",RESOLUTION=640x360,FRAME-RATE=29.970,AUDIO="program_audio_0",SUBTITLES="subsC" 0640c/prog_index.m3u8 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=1922391,AVERAGE-BANDWIDTH=1276855,CODECS="hvc1.2.4.H150.B0",RESOLUTION=640x360,URI="0640c/iframe_index.m3u8"#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="program_audio_0",LANGUAGE="eng",NAME="Alternate Audio",AUTOSELECT=YES,DEFAULT=YES,URI="audioc/prog_index.m3u8"CODECS编码格式为hvc1.2.4.H150.B0,mp4a.40.2，音频编码格式没变，但视频编码格式变了。hvc1是HEVC（H265）编码格式里的一种，它是由苹果推出的新一代视频编码格式，因为兼容性问题很多客户端还无法解析该格式，所以并不是很普及，该格式的视频源出现在这里应该是一种备用。对比相同分辨率的两条内容，还能发现hvc1格式会比avc1格式比特率更高，这说明相同分辨率下hvc1的内容更大，avc1的压缩比更高。 对应hvc1格式的视频源，它的字幕内容分组和音频内容分组也都变了，这也是为什么上面的字幕同一语种会有两份，他们分别对应avc1和hvc1格式的视频源。 M3U8的主列表就这些内容了，该条内容的音视频是分开处理的，其实也可以合在一起。 包含媒体资料的m3u8文件 以0640.m3u8这个文件为例 #EXTM3U #EXT-X-VERSION:4 #EXT-X-TARGETDURATION:7 #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:6.006, 0640_00001.ts #EXTINF:6.006, 0640_00002.ts #EXTINF:6.006, 0640_00003.ts .... #EXT-X-ENDLIST#EXTM3U，#EXT-X-VERSION，分别为M3U文件头和兼容版本号，这种格式是早期的所以版本号比主文件低一些。 EXT-X-TARGETDURATION代表每个播放片段的最大时长，7，代表7秒，该目录下的片段不能超过7s。 EXT-X-MEDIA-SEQUENCE代表播放列表的第一个片段序号，1，代表播放片段是从1开始的。 #EXTINF代表片段的时长，6.006表示当前片段为6.006s。视频总时长的信息是通过该值累加获取的。 0640_00001.ts为片段的相对路径，ts文件代表一段视频或者音频，它可以是ts，mp4，aac等格式。因为前面已经指定了从1开始，所以这里序号是0640_00001。 #EXT-X-ENDLIST为媒体内容的结束标识，因为m3u8即可以表示点播也可以表示直播，区分点播还是直播就看文件末尾是否有这个标识符。如果没有的话就代表直播，播放会一直持续下去。 音频文件audio1.m3u8，字幕文件pro_index.m3u8的内容也是类似的，区别在于他们的切片内容一个是acc的音频文件，一个是webvtt的字幕文件。 包含切片内容的M3U8也可以作为独立的视频链接存在，这时切片内容就需要同时包含音视频内容了。 文件加密 HLS协议支持加密，如果索引文件中包含了一个密钥文件的信息，那接下来的媒体文件就必须使用密钥解密后才能解密打开了。当前的 HLS 支持使用16-octet 类型密钥的 AES-128 加密。这个密钥格式是一个由这在二进制格式中的16个八进制组的数组打包而成的。 加密的配置模式通常包含三种： 模式一：允许你在磁盘上制定一个密钥文件路径，切片器会在索引文件中插入存在的密钥文件的 URL。所有的媒体文件都使用该密钥进行加密。 模式二：切片器会生成一个随机密钥文件，将它保存在指定的路径，并在索引文件中引用它。所有的媒体文件都会使用这个随机密钥进行加密。 模式三：每 n 个片段生成一个随机密钥文件，并保存到指定的位置，在索引中引用它。这个模式的密钥处于轮流加密状态。每一组 n 个片段文件会使用不同的密钥加密。 参考：HLS-iOS视频播放服务架构深入探究（一）