组件化-面向协议方案
1.前言URL和反射方案各有自己的局限性： URL路由方案支持的参数类型不够灵活； 反射方案的中间通信层使用明文类名和接口名，硬编码极容易出错； 两种方案中组件之间传值时需要引用对方的实体文件，这样就依然存在耦合问题； 本篇将要探讨的协议+服务注册+URL+反射方案，其中的协议就很好的解决了这些问题~ 2.思路 2.1.本地调用组件将自己对外提供的服务以协议的形式进行声明，对其他所有组件可见；
组件化-反射方案
1.前言上一篇文章中分析了组件化的目标和好处，同时梳理了基于URL+Block的路由组件化解决方案的原理、实践和优缺点。本文将继续介绍第二种解决方案：基于反射原理的组件化方案。 2.场景从主页跳转到详情，传入详情页所需的头像； 在详情中简单的修改信息之后，返回主页时更新主页的标题。 3.思路基于反射原理的组件化方案，其首要目标还是实现各组件之间的通信，同时减少组件间的耦合。其实现原理如下： 3.
组件化-URL路由方案
一、组件化1.目的为了解耦：把复杂系统拆分成多个组件，分离组件边界和责任，便于独立升级和维护。 2.好处 明确组件职责 按合理的粒度将系统拆分成多个组件，确保组件各司其职，以便于复用。 提升开发/编译/测试效率 开发人员只须关注自己的组件，不再需要导入或编译其他组件，从而提升开发和编译速度。 减少组件间的依赖 通信层实现了组件间的通信，而不用在组件间跳转、调用服务时引
常用架构模式
一.架构模式1.引言 架构模式，用于描述软件系统里的基本的结构组织或纲要。架构模式提供了一些定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。常见的架构模式有：分层模式、微核模式、管道与过滤器、MVC模式、REST模式、SOA模式。 2.起源软件开发中需求变动往往导致代码的修改，而一些代码尤其是大型系统的码理解起来并不容易，只有当时的开发者比较清楚，其他人很难接手。修改这种代码
搭建自己的Pod库
前言使用三方库时基本的语法是： 1pod 'pod-Name' 之后通过以下命令导入此库: 1pod install pod会从官方索引库中查找并导入此三方库。有时我们不希望自己的库对外公开，如只在公司范围内使用，这时就可以在代码托管平台发布一个私有库，导入库时通过:source =>指定私有库的远程索引库地址即可。 本篇文章将记录下从私有库到公开库的完整发布流程~
Github访问慢？
Github为国外网站，所以域名解析时速度慢的。。解决此问题有俩方法： 挂VPN 修改hosts配置 本文讲的是第二种，修改hosts文件，具体步骤如下： #1、打开host文件 直接通过Finder 快捷键 command + shift + G，输入“/etc”，回车即可进入etc文件夹，找到hosts文件，直接通过系统的“文本编辑”打开即可。 使用终端打开 1sudo v
分包配置
思维导图 Xcode 默认配置Xcode 在生成项目时已经帮我们配置好了两个环境，并且已经在同一个scheme下做好了配置： #Debug 测试环境，一般 Build、Run、Test 和 Analyze，都在这个环境中进行。 #Release 生产环境，Profile 和 Archive 打包上传商店时，使用这个环境。 查看Build Settings，你能看到每个设置下都分两种环境，可以做不
应用安全
这段时间 iOS12 越狱工具发布了，屁颠屁颠的去研究了一键砸壳，昨天忽然想起来之前公司的产品被人破解，拿到了关键信息进而薅羊毛的事。那时的解决方案是检测异常请求和独立出一个加密framework。现在想想，这些措施都太简单或者不够高效，还需要更进一步研究应用的安全问题。 1.被破解的危害 被人逆向分析通信协议、API、核心算法等； 篡改IPA、植入广告和木马； 重打包并发布盗版应用； 破解内购
