1.ios ?视视频?ƵԴ??
2.深入剖析-ijkplayer框架音视频开发
3.iOS多模式&富交互视频播放器TTAVPlayer(附源码)
4.成品短视频源码入口在哪
5.WebRTC入门：iOS工程
6.iOS本地缓存方案之YYCache源码解析
ios ??ƵԴ??
自动修改/翻新/混淆/OC/iOS代码，自动替换类名，频源方法名
由来
网上有很多关于如何混淆iOS源码的码苹方法，但是源码都不够智能，生成的视视频方法类名要么千奇百怪，要么aaaabbbxxx这种完全毫无意义的频源数钱h5页面源码名称，要么只能修改单个文件，码苹多个文件根本无法关联，源码我就想有什么方法可以像真人一样去修改源码，视视频符合语义，频源不是码苹胡编烂造的方法名，还可以自动修改相关联的源码文件, 还能自己自定义单词库，于是视视频就有了这个工具。
演示视频
划重点
1. 该工具可以让你一键翻新代码，频源但是码苹不是生成完整的xcode项目，需要你自己新建一个xcode项目，然后把翻新的文件拖入到新的项目中。
2. 该工具只要是ipa都可以，不限制OC，Swift，Flutter，React Native，H5类app。
3.目前免费使用，免费使用，免费使用，重要的事情说三遍
几个效果展示
使用说明
下载项目，官网下载：IpaGuard官网--IOS 应用程序ipa文件混淆加密保护工具注意：说明中提到的路径均为绝对路径，提到的逗号,都为英文逗号。使用工具运行成功后，需要自己新建OC项目再将修改后的代码与资源文件拖入新建的工程。功能说明：
未来可能添加的功能：说明文档会不定期更新，如遇到问题先检查是否依照说明文档的定义进行配置。
1. 源文件路径/import_path（必选）
OC项目文件路径包含代码文件与资源文件
如下图
2. 导出路径/export_path（必选）
OC项目导出路径。
注意，本工具并不能帮你生成完整的OC项目，只会生成OC代码文件和复制修改项目内部的网站整站源码偷资源
3. 直接复制的路径/copy_only_pathes（可选）
直接复制，忽略的文件名，多个路径以,逗号隔开
4. 直接复制的文件名(不包含后缀)/copy_only_names（可选）
直接复制，忽略的文件名，不包含后缀
例：UISheetView.h 只需要输入UISheetView，多个文件用, 逗号隔开（注意全半角，逗号为英文逗号）
5. 不进行修改的文件或文件夹/no_change_pathes（可选）
深度读取，但是不会进行更改，如果引入了其他修改了的类，会相应的修改深度读取（说明）：会读取文件内部的类比与项目内其他类进行关联例：xxxx/Classes/Models 不想修改，则输入这个文件夹的绝对路径, 如只输入Models,则所有包含名为Models的文件或文件夹都会标记为只读取不修改，多个文件和类用, 逗号隔开（注意全半角，逗号为英文逗号）
6. 不修改的文件或类的前缀名(区分大小写)/no_change_class_prefix_names（可选）
例：不想所有以MJ开头的类或文件，则输入MJ, 多个文件和类用,逗号隔开（注意全半角，逗号为英文逗号）
7. 不修改的文件后缀名(区分大小写)/no_change_class_prefix_names（可选）
如第六条。Model,Info -->不修改以Model,Info为结尾的文件或类
8. 只修改类名的文件名或类名/only_change_clsname_names（可选）
深度读取，只修改类名，不修改内部属性与方法，这个优先级最低，如果之前的条件包含了本参数中的路径，则不生效
9. 只修改类名的文件夹/文件路径/only_change_clsname_pathes（可选）
深度读取，只修改类名，不修改内部属性与方法的文件名，这个优先级最低，如果之前的条件包含了本参数中的路径 则不生效
. 动词词库路径/verbwords_path（可选）
提供单词数组json文件路径 修改的命名逻辑为ABAB型，A为动词，B为名词，例：getMessage
. 名词词库路径/nounwords_path（可选）
提供单词数组json文件路径 修改的命名逻辑为ABAB型，A为动词，B为名词，例：getMessage
. 类名前缀/class_prefix（可选）
给每个类添加的前缀例：MJExtension-> MJ 为前缀， SD_ScrollView-> SD_ 为前缀
. 属性名前缀/property_prefix（可选）
给每个属性添加的前缀例：property(nonatomic, strong) UIViewMJView-> MJ 为前缀， property(nonatomic, strong) UIView SD_View-> SD_ 为前缀
. 需要过滤的方法路径/filter_methods_path（可选）
把你需要过滤的方法写入一个文本文件，然后将该文本路径填入到此项输入框注意事项:其他说明：本工具已经过滤了大多数常用系统方法，大部分情况下不需要配置此项。
. 类名和属性名后缀路径/property_subfix_path（可选）
给每个属性添加的后缀，需要一个配置json文件路径json格式：注意：key一定要与上面一直，大长腿源码否则系统无法读取，工具会遍历数组，为对应的类匹配后缀，在配置改文件时，包含相同字符串的类，需要将类名更长的类放在前面，不然匹配结果会达不到预期。例如：UITableView与UIView，配置时需要将UITableView放在View之前，如上面的例子。
. 为方法名添加介词/add_preposition（可选）
工具内置了所有介词，可选择性添加例：getMessage添加介词后-> getAMessage or getTheMessage具体介词完全随机添加
. 修改分类/change_category（可选）
工具会自动识别分类，可选择是否修改
. 将原代码行作为注释写入/add_original_comments（可选）
由于本工具不保证修改后百分百不报错，将修改过原属性声明和方法名作为注释写入，方便在重建工程后报错与原工程进行对照，建议设置
. 修改方法内部局部变量名/change_local_property（可选）
定义在方法内部的局部变量，可选择是否修改
. 综合配置路径（可选）
json配置文件路径，内部必须为字典，key为说明条目标题后面的英文请注意：配置文件优先级高于输入框输入的规则，配置文件存在时, 输入框输入的配置不生效例：(可直接复制修改)
关于bug
虽然工具本身经过了完整的商业项目的考验，但由于每个人的代码风格不一样，工具不可避免会出现解析不了的情况，开发者建议过滤C语言的文件，与第三方库，减少出错的可能性，还是无法运行成功，你可以发isssue至客服邮箱或根据报错Log自行删减项目文件，其中利弊，自行斟酌。
深入剖析-ijkplayer框架音视频开发
随着互联网技术的迅猛发展，移动设备上的视频播放需求日益增长，催生了一系列开源和闭源播放器。这些播放器的功能虽然强大，兼容性也颇优，但其基本模块通常包括事务处理、数据接收和解复用、流量交易论坛源码音视频解码以及渲染。以下是一个简化的基本框架图。
在众多播放器项目中，我们选择了ijkplayer进行源码分析。ijkplayer是一款基于FFPlay的轻量级Android/iOS视频播放器，支持跨平台，API易于集成，编译配置可裁剪，方便控制安装包大小。本文基于ijkplayer的k0.7.6版本，重点分析其C语言实现的核心代码，以iOS平台为例，Android平台实现类似，具体请读者自行研究。
ijkplayer的主要目录结构如下：tool（初始化项目工程脚本）、config（编译ffmpeg使用的配置文件）、extra（存放编译ijkplayer所需的依赖源文件，如ffmpeg、openssl等）、ijkmedia（核心代码）、ijkplayer（播放器数据下载及解码相关）、ijksdl（音视频数据渲染相关）、ios（iOS平台上的上层接口封装以及平台相关方法）、android（android平台上的上层接口封装以及平台相关方法）。iOS和Android平台在功能实现上的主要差异在于视频硬件解码和音视频渲染。
ijkplayer的初始化流程包括创建播放器对象，打开ijkplayer/ios/IJKMediaDemo/IJKMediaDemo.xcodeproj工程，在IJKMoviePlayerViewController类中viewDidLoad方法中创建了IJKFFMoviePlayerController对象，即iOS平台上的播放器对象。
ijkplayer的初始化方法具体实现如下：创建了IjkMediaPlayer结构体实例_mediaPlayer，主要完成了以下三个动作：创建平台相关的IJKFF_Pipeline对象，包括视频解码以及音频输出部分；至此，ijkplayer播放器初始化的相关流程已经完成。
ijkplayer实际上是基于ffplay.c实现的，本章节将以该文件为主线，从数据接收、网页源码太乱音视频解码、音视频渲染及同步这三大方面进行讲解，要求读者具备基本的ffmpeg知识。
当外部调用prepareToPlay启动播放后，ijkplayer内部最终会调用到ffplay.c中的stream_open方法，该方法是启动播放器的入口函数，在此会设置player选项，打开audio output，最重要的是调用stream_open方法。
从代码中可以看出，stream_open主要做了以下几件事情：创建上下文结构体，设置中断函数，打开文件，探测媒体类型，打开视频、音频解码器，读取媒体数据，将音视频数据分别送入相应的queue中，重复读取和送入数据步骤。
ijkplayer在视频解码上支持软解和硬解两种方式，可在播放前配置优先使用的解码方式，播放过程中不可切换。iOS平台上硬解使用VideoToolbox，Android平台上使用MediaCodec。ijkplayer中的音频解码只支持软解，暂不支持硬解。
ijkplayer中Android平台使用OpenSL ES或AudioTrack输出音频，iOS平台使用AudioQueue输出音频。audio output节点在ffp_prepare_async_l方法中被创建。
iOS平台上采用OpenGL渲染解码后的YUV图像，渲染线程为video_refresh_thread，最后渲染图像的方法为video_image_display2。
对于播放器来说，音视频同步是一个关键点，同时也是一个难点。通常音视频同步的解决方案就是选择一个参考时钟，播放时读取音视频帧上的时间戳，同时参考当前时钟参考时钟上的时间来安排播放。
ijkplayer支持的事件比较多，具体定义在ijkplayer/ijkmedia/ijkplayer/ff_ffmsg.h中。在播放器底层上报事件时，实际上就是将待发送的消息放入消息队列，另外有一个线程会不断从队列中取出消息，上报给外部。
本文只是粗略的分析了ijkplayer的关键代码部分，平台相关的解码、渲染以及用户事务处理部分，都没有具体分析到，大家可以参考代码自行分析。
iOS多模式&富交互视频播放器TTAVPlayer(附源码)
iOS端沉浸式体验的多模式视频播放器：TTAVPlayer 在追求极致用户体验的道路上，视频播放器的交互性和适应性显得尤为重要。TTAVPlayer的诞生，旨在解决这一痛点，提供多种模式以满足不同业务场景的需求，包括普通模式、竖屏模式、横屏模式和静音模式。 模式解析 首先，普通模式适用于嵌入商品内容和文章，H5桥接播放，以及与网页的无缝对接。竖屏模式则在浸入式体验中大显身手，如微博、手淘微淘的详情查看，静音模式则适合列表自动播放时的隐私保护。而横屏模式则是播放体验的巅峰，配备丰富的手势操作，如音量调节、进度控制和屏幕亮度调整。 设计理念 设计之初，我们秉持“最小接入成本与最大扩展性并重”的原则，力求简洁易用的同时，提供足够的自定义空间。TTAVPlayer内置四种预设模式，降低接入复杂度，通过分层设计，基础功能与UI界面分离，仅提供基础控制接口，如播放、暂停和进度调整，其余UI定制则完全交由用户自定义。 技术实现 TTAVPlayer基于Apple的AVPlayer构建，它负责视频解码、播放和基本操作。我们在此基础上，扩展出TTAVPlayerView，作为用户可见的部分，它负责展示视频并提供交互。TTAVPlayerView与业务逻辑解耦，仅关注视频播放，为自定义模式的扩展提供了强大支持。 卓越特性 为了提升用户体验，TTAVPlayer提供了丰富的特性：横屏模式支持手势控制，自动切换屏幕方向；容错提示页面，温馨关怀用户；网络切换检测，流畅切换网络；静音模式，保护隐私；还有更多实用功能等待探索。 后续支持 对于任何技术问题、bug报告或新功能需求，欢迎在GitHub上提出，我们会及时处理。同时，真机运行Demo效果最佳，如有需要深入交流，可通过以下方式联系我：知乎：[点击获取链接]
GitHub：[点击获取链接]
简书：[点击获取链接]
在TTAVPlayer的世界里，我们致力于提供一个高效、灵活且友好的视频播放解决方案，让你的项目更加出色。成品短视频源码入口在哪
成品短视频源码的入口通常位于开发者提供的下载链接或官方文档中。这些源码可能通过开发者的官方网站、第三方源码分享平台（如GitHub）或专门的源码交易网站获得。
要找到成品短视频源码的入口，可以首先访问开发者的官方网站，在“资源中心”或“开发者专区”等栏目中查找源码下载链接或相关信息。如果官方渠道没有提供源码，可以尝试在GitHub等第三方开发者平台上搜索相关的源码项目。
在下载源码后，需要解压并查看源码的结构。通常，源码的入口文件（如`main.py`、`app.js`、`MainActivity.java`（Android）或`AppDelegate.swift/AppDelegate.m`（iOS）等）会位于源码的根目录或特定的子目录中。通过查看这些入口文件，可以了解应用程序的启动和运行过程，进而进行后续的定制和开发工作。
请注意，在下载和使用成品短视频源码时，务必注意版权和授权问题，确保遵守相关的法律法规和使用条款。同时，也需要注意源码的版本和兼容性，以确保其能在自己的开发环境中正常运行。
WebRTC入门：iOS工程
刚进入项目组，接手WebRTC相关任务。项目需求基于最新WebRTC版本进行二次开发，但其工程使用gn和ninja编译，每次修改需编译成lib或framework，过程繁琐。本文记录WebRTC OC工程分离过程中的经验与教训。
WebRTC，全称为Web Real-Time Communication，是实现实时语音与视频通话的技术，由谷歌于年通过收购Global IP Solutions公司获得。自年5月开源以来，得到广泛支持与应用，成为下一代视频通话的标准。
要获取WebRTC iOS版本源码，首先需设置git代理。由于不可抗力，需自行配置。
编译WebRTC库时，使用GN生成ninja工程文件。了解GN与ninja基本使用，可以借助官方教程，直接编译出WebRTC.framework。官方提供编译脚本，可方便编译静态库或Framework版本，并支持指定编译条件，如debug版本或是否开启bitcode。
目标是将WebRTC.framework集成至Xcode工程，仅关注OC部分的二次开发，减少对C++代码的关注。分离工程需在现有基础上进行，尽量减少源码修改。
生成libjingle_peerconnection_all库，需在/webrtc/BUILD.gn文件中添加新目标，并在build/ios/build_ios_libs.sh脚本中增加编译选项。此过程需按照官方教程进行。
创建WebRTC_OC工程，在webrtc/sdk/objc目录下，参照rtc_sdk_common_objc和rtc_sdk_framework_objc配置，选择性添加所需Framework文件夹代码文件。
分离工程过程中，需关注现有代码库依赖。完全分离需对头文件引用进行大量修改。分离工程旨在最小化修改，进行优化。
总结接触WebRTC代码的经验，分离OC工程虽有助于专注二次开发，但需谨慎处理现有代码库依赖问题。若需完全分离，需对源码进行大量修改。了解更多细节请参阅原文链接。
iOS本地缓存方案之YYCache源码解析
简单列举一下，iOS的本地缓存方案有挺多，各有各的适用场景：
本文主要聊聊YYCache的优秀设计。高性能的线程安全方案是YYCache比较核心的一个设计目标，很多代码逻辑都是围绕性能这个点来做的。与TMMemoryCache方案相比，YYCache在同步接口的设计上采用了自旋锁来保证线程安全，但仍然在当前线程去执行读操作，这样就可以节省线程切换带来的开销。而TMCache在同步接口里面通过信号量来阻塞当前线程，然后切换到其他线程去执行读取操作，主要的性能损耗在这个线程切换操作上，同步接口没必要去切换线程执行。此外，使用dispatch_sync实现同步的方案也可以做到节省线程切换的开销，与加锁串行的方案相比，性能如何还需要进一步测试验证。除了高性能的本地存储方案，YYCache在本地持久化提高性能方面采取了策略，对于大于k的数据采取直接存储文件，然后在sqlite中存元信息；对于小于k的数据则直接存储在sqlite中。数据完整性保障方面，YYCache在存储文件时，存在数据库的元信息和实际文件的存储必须保障原子性。此外，YYCache还新增了实用功能，比如LRU算法，基于存储时长、数量、大小的缓存控制策略等。这些设计和功能使得YYCache在iOS本地缓存方案中具有较高的竞争力和实用性。