近期团队开发的新产品的官网上线了，随之而来的问题就是如何让网站更快更好的传播出去。当然SEO就是最常见的手段之一，对官网的SEO工作有利于产品的网络传播和分享。

有的团队会有专人负责SEO的工作，那么作为离网站页面“最近”的前端工程师，可以为SEO做哪些工作呢？

为了更好的沉淀SEO相关内容，为后续web产品提供优化指南，本文就以前端工程师的角度，通过调研沉淀出了前端通用SEO技术优化指南。

最近团队有同学提议，想探讨如何才能写出一篇优秀的技术文章。所以尽管水平实在有限，还是按照自己的经验和理解写下了这篇文章，亚历山大之余，也很高兴和大家分享一下自己对技术写作的一些思考。

很多人每天上班都要刷卡进出地铁，我们就以有旋转栅门的地铁站闸机入口作为例子。

这个闸机口在开始的时候有一个“locked”的状态, 在这个状态下它并不会让乘客旋转栅栏通过进站口。当有人刷卡了，那么这个闸机口的状态就会变为“unlocked”，但是它并不会自己转动，必须得等到有人推动旋转栅栏通过闸机口，且在这之后闸机口的状态会再次变为“locked”。

关于符号化，我想iOS开发的相关人员并不陌生，也在日常的开发中也经常打交道，网上关于符号化的文章可以说是漫天飞舞，但并没有一篇文章可以说的很全面，于是便有了这篇文章的诞生。

当有新数据需要放到缓存时，Cache将需要淘汰的数据，通过TinyLFU来决定是否用新数据替代被淘汰的数据，来提升命中率。 TinyLFU本质是布隆过滤器的变种，其使用Count–Min Sketch算法，可以用极小的内存，来实现大量数据统计。

常用的播放文件，如 mp3、aac 都是已经封装的音频格式，将它们的文件提供到系统音频库或者第三方音频库，如 AVPlayer、IJKPlayer 等这些框架和播放器，然后声音就会由扬声器或耳机播放出来。如果读者对这些神奇的过程有兴趣，那就进入本次的了解旅程。

最近因为新项目想用到数据持久化，本来这是很简单的事情，复杂数据一般直接SQLite就可以解决了。

文本匹配在NLP的应用中属于比较常规常见的任务，但是在这个比赛中，主办方给的数据有很大的不同，它分类很多子类，包括长长匹配，短长匹配和短短匹配，而在每个子匹配任务中，又分为AB两类的匹配标准，A类匹配条件比较宽松，B类匹配条件比较严格。

了解MotionLayout的使用方法和常用的一些属性。

最近做包大小优化，在做项目代码优化时，其中有一个过程是分析Mach-O文件，看网上很多文章都说通过otool分析Mach-O，获取__objc_classrefs、__objc_classlist等，然后找出无用类和无用方法。

上面那些话看起来简简单单的，但是笔者操作起来确遇到了很多困难，首先otool是什么？然后__DATA.__objc_classlist是什么？哪里来的？怎么跟otool命令结合起来使用？怎么获取差值？怎么结合使用正则表达式，等等？

iPhone 添加日历提醒的实现很简单，难的地方还是在于国内法定节假日的判断，怎么能过滤掉法定节假日，实现真正纯工作日的时候提醒？

Jetpack Compose是Google近几年在Android的UI方面变化最大的一次改变，而且表示后续的UI工作重心会放在Compose上。前些日子推出了beta版本，API已经基本稳定，正是了解Compose的最佳时机。

从Xcode12.5开始，苹果要求所有的Extension Target必须设置APPLICATION_EXTENSION_API_ONLY为true，否则将会导致编译错误“Application extensions and any libraries they link to must be built with the APPLICATION_EXTENSION_API_ONLY build setting set to YES”；但是我们通常会在主工程和Extension之间使用Framework或其他方式共享代码，这些代码中使用了非extension-only API，所以导致问题出现，本篇文章将探讨如何解决这个问题。

YYModel是我们常用的一个解析JSON数据的高性能的框架，但是很多时候我们只停留在了使用层面，并没有对底层的原理进行深入的了解，所以笔者将对YYModel的源码进行细致的解读，带领大家共同学习通过Runtime实现JSON解析的过程。

包大小优化是项目开发中不可避免会遇到的，网上关于包大小优化的文章很多，每篇文章说的都不尽相同，笔者曾经根据网上的文章做过包大小优化，但效果不尽人意；因此笔者想根据已有的文章、知识结合自己的理解、实践，做一份总结梳理，整理自己的包大小优化逻辑，不光要知道怎么做可以让包大小变化，还要知道为什么这么做能产生效果，所以就有了这篇文章。

日志对于线上排查问题是非常重要的，很多问题其实是很偶现的，同样的系统版本，同样的设备，可能就是用户的复现，而开发通过相同的操作和设备就是不复现。但是这个问题也不能一直不解决，所以可以通过日志的方式排查问题。可能是后台导致的问题，也可能是客户端逻辑问题，在关键点记录日志可以快速定位问题。

假设我们的用户量是一百万日活，其中有1%的用户使用出现问题，即使这个问题并不是崩溃，就是业务上或播放出现问题。那这部分用户就是一万的用户，一万的用户数量是很庞大的。而且大多数用户在遇到问题后，并不会主动去联系客服，而是转到其他平台上。

虽然我们现在有Kibana网络监控，但是只能排查网络请求是否有问题，用户是否在某个时间请求了服务器，服务器下发的数据是否正确，但是如果定位业务逻辑的问题，还是要客户端记录日志。