引言

SwiftUI 于 2019 年度 WWDC 全球开发者大会上发布，它是基于 Swift 建立的声明式框架。该框架可以用于 watchOS、tvOS、macOS、iOS 等平台的应用开发，等于说统一了苹果生态圈的开发工具。

本人最早开始 iOS 开发时选择了 OC（Objective-C，一种编程语言），当时 OC 不但拥有各种知名的第三方库和完善的社区支持，同时 Swift 语言本身都还在不断颠覆性改进中。但当我看了 2020 年 WWDC 关于 SwiftUI 一系列课程之后，便从 Swift 语言的学习开始，逐步了解并掌握 SwiftUI，并果断抛弃了OC，将新项目全部迁移到了 SwiftUI 框架。

SwiftUI 到底有没有苹果宣传的那么理想化？资深的 iOS 开发者是否有必要转型，以及如何转型？SwiftUI 在实际使用的过程中真实体验如何？这些问题就是这篇文章希望探讨的话题。

在最后，我会分享一些自己的学习心得和材料顺序，借开源的精神与大家共同进步。

什么是 SwiftUI

对于 Swift UI，官方的定义很好找到，也写得非常明确：

SwiftUI is a user interface toolkit that lets us design apps in a declarative way.

可以理解为 SwiftUI 就是⼀种描述式的构建 UI 的⽅式。

单单通过描述，大部分人其实很难对抽象的编程方法，和其中的改进有直观的认识。这篇文章也希望通过尽量口语化的叙述，减少专业词汇和代码的出现来降低阅读门槛，让更多人了解计算机科学，了解程序的世界。

下面是我手头正在做的一个项目，定位是一个原生全平台的电子阅读应用，正在使用 SwiftUI 构建用户界面。

为什么苹果要推出 SwiftUI

SwiftUI 的两个组成部分，Swift + UI，即是这个问题的答案。

Swift：编程语言和体验的一致性

Swift 代表苹果推出的一种现代编程语言

很多苹果用户之所以喜欢苹果的产品，其中一个原因，是不同产品之间由内而外的统一感和协调感。这一点在硬件层面的感知是最明显的，从早期开始苹果出的硬件就是「果味十足」的。即使是新品迭代或者是开发全新的品类，也一定会带有烙印很深的「果味」工业设计。

仅仅外观的统一还不够，苹果真正追求的是内外一致，也就是体验的统一。

然而工业设计可以交给自家精英团队，系统可以相互借鉴，但用户使用的软件是由广大的开发者自由创造的。让人意外的是，这一点苹果做的也很不错，与别家相比，质量精良是很多人对苹果系统上软件的印象。

为了实现这一目标苹果做了大量不为普通消费者所感知的工作。

在设计上，苹果提供了一整套不断在更新的 Human Interface Guidelines，详细规定了与视觉相关的各个方面。在完成开发，准备上架分发之前，苹果的审核团队会对每一款应用进行审核，根据 App Store Review Guidelines 的条款判断应用是否允许上架 App Store，即使是知名的应用违反规定也是说下架就下架，绝不含糊。对于不越狱的移动设备而言，App Store 是唯一可以安装应用的途径，控制了其中的准入也就等于替整个平台做了筛选。

除了控制终端以外，苹果也在想方设法增加开发者的数量，提升单个应用质量。方式也非常符合第一性思维原则——降低开发的难度。所以先有了Swift，紧接着又推出了 SwiftUI。苹果希望直接优化语言本身，并统一所有设备的开发体验，让开发者更容易上手，也更容易将心里的想法转化为运行的程序。

虽说在 2015 年推出 Swift2.0 的时候就进行了开源。但这些年 Swift 在后端或是跨平台的发展上并不是非常顺利。提起 Swift，圈内还是会被默认为特指苹果平台内使用的编程语言，地位有些类似 OC 的接班者。其实为了推广这门语言，苹果本身也做了非常多的工作，像是推出SwiftUI，基本就可以看做苹果在推广新语言的过程中一个里程碑式的节点。

SwiftUI 使用了大量 Swift 的语言特性，特别是 5.0 之后新增的特性。Swift 5.1 的很多特性几乎可以说都是为了 SwiftUI 量身定制的，比如 Opaque return types、Property Delegate 和 Function builder 等。

UI：开发的困局

在 SwiftUI 出现之前，苹果不同的设备之前的开发框架并不互通，移动端的⼯程师和桌⾯端的⼯程师需要掌握的知识，有很⼤⼀部分是差异化的。

从 iOS SDK2.0 开始，移动端的开发者⼀直使⽤ UIKit 进⾏⻚⾯部分的开发。UIKit 的思想继承了成熟的 AppKit 和MVC（Model-View-Controller）模式，作出了⼀些改进，但本质上改动不⼤。UI 包括了⽤⼾能看到的⼀切，包括静⽌的显⽰和动态的动画。

再到后来苹果推出了Apple Watch，在这块狭小屏幕上，又引入了一种新的布局方式。这种类似堆叠的逻辑，在某种程度上可以看做 SwiftUI 的未完全体。

截止此时，macOS 的开发需要使用 AppKit，iOS 的开发需要使用 UIKit，WatchOS 的开发需要使用堆叠，这种碎片化的开发体验无疑会大大增加开发者所需消耗的时间精力，也不利于构建跨平台的软件体验。

即使单看 iOS 平台，UIKit 也不是完美的开发⽅案。

UIKit 的基本思想要求 ViewController 承担绝⼤部分职责，它需要协调 model，view 以及⽤⼾交互。这带来了巨⼤的 sideeffect 以及⼤量的状态，如果没有妥善安置，它们将在 ViewController 中混杂在⼀起，同时作⽤于 view 或者逻辑，从⽽使状态管理愈发复杂，最后甚⾄不可维护⽽导致项⽬崩溃。换句话说，在不断增加新的功能和⻚⾯后，同⼀个ViewControlle r会越来越庞杂，很容易在意想不到的地⽅产⽣ bug。⽽且代码纠缠在⼀起后也会⼤⼤降低可读性，伤害到维护和协作的效率。

SwiftUI的特点

在很多地方都能看到 SwiftUI 针对现有问题的一些解决思路，而且现在的编程思想经过不断以来的演化，也一直就软件工程在开发过程中的各种问题在寻找答案。

近年来，随着编程技术和思想的进步，使用声明式或者函数式的方式来进行界面开发，已经越来越被接受并逐渐成为主流。SwiftUI 不是第一个，也不会是最后一个使用声明式界面开发的框架。

声明式的界面开发方式

在计算机科学的世界内，抽象是一个很重要的概念。从底层的二进制逻辑门，到人类可以阅读和理解的编程语言之间，是由很多层的抽象将它们关联起来的。所谓抽象，简单解释就是通过封装组件，将底层细节打包并隐藏起来，从而明确逻辑降低复杂度。就像把晶体管打包成逻辑门，以及软件工程中的函数对象。在软件开发的过程中，工程师只需负责某个具体功能的实现，而其他人则通过开放的 api 使用该功能。

与曾经的布局方式相比，声明式的页面开发无疑又加了一层抽象。

在 UIKit 框架中，界面上的每一个元素都需要开发者进行布置，期间有不少计算工作，例如长宽的改变或是屏幕可视面积的变化等。这种线性的方式被称为指令式 (imperative) 编程。以一行文字为例，放置在哪个坐标、宽度多少、在哪里换行、怎么断句、字形字号是多少、最终高度多少、是否需要缩小字号来完全显示等，这些都是开发者在制作界面时要考虑和计算妥当的问题。到了第二年，用户可能会换更大屏幕的手机，系统支持动态字体调节等新功能，此时原先的程序不进行适配就可能出现显示问题，开发者就需要回头进行程序的重新调试。

换做 SwiftUI 之后，上述的很多变量就被系统接管了。开发者要做的就是直观的告诉系统放置一个图像，上面加一行文字，右边加一个按钮。系统会根据屏幕大小、方向等自动渲染这个界面，开发者也不再需要像素级的进行计算。这被称为声明式 (declarative) 编程。

对比同一个场景界面的实现

作为常用的列表视图，在UIKit中被称为 TableView，而在 SwiftUI 中被叫做 List 或 Form。同样是实现一个列表，在 SwiftUI 仅需要声明这里有一个 List 以及每个单元的内容即可。而在UIKit 中，需要使用委托代理的方式定制每个单元的内容，还需要事无巨细的设置行和组的数量、对触摸的反应、点击过程等各方面。

在我的另一个早期项目 Amos 时间志中就可以看到，为了绘制主页就需要几千行代码。

智能适配不同尺寸的屏幕

除了不同尺寸的屏幕，SwiftUI 还能根据运行平台的区别，将按钮、对话框、设置项等渲染成匹配的样式。由于声明的留白是很大的，当开发者不需要事无巨细的安排好每一个细节时，系统可操作的空间也会变大。

可以想象，假如苹果推出新品例如眼镜，或许同样的界面代码会被展示成与 iPhone 中完全不同的样式。

提高了解决问题时所需要着手的层级，这可以让开发者可以将更多的注意力集中到更重要的创意方面。

链式调用修改属性

链式调用是 Swift 语言的一种特性，就是用来使用函数方法的一种方式。可以像链条那样不断地调用函数，中间不需要断开。使用这种方式开发者可以给界面元素添加各种属性，只要愿意，同样能够事无巨细的安排页面元素的各种细节。

除了系统预制的属性可以调节外，开发者也可以进行自定义。例如将不同字体、字号、行间距、颜色等属性统合起来，可以组合成为一个叫「标题」的文字属性。之后凡是需要将某一行文字设置成标题，直接添加这个自定义的属性即可。

使用这种方式进行开发无疑能够极大的避免无意义的重复工作，更快的搭建应用界面框架。

界面元素组件化

理论上来讲，每一个复杂的视图，都是由大量简单的单元视图构成。但是函数方法可以包装起来，做到仅在有需要的时候进行调取使用。在 UIKit 框架下的页面元素解耦却不太容易，一般都是针对某种特定情境，很难进行移植。有时候可能手机横屏就会让页面元素混乱，就更别论页面元素的组件化了。

不过 SwiftUI 在布局上的特点，却可以便捷的拆分复杂的视图组件。单一的组件不仅可以自由组合，而且在苹果的任意平台上都可以使用该组件，达到跨平台的实现。

一般我个人会将视图组件区分为基础组件、布局组件和功能组件。因为 SwiftUI 的界面不再像 UIKit 那样，用 ViewController 承载各种 UIVew 控件，而是一切都是视图。这种视图的拼装方式提高了界面开发的灵活性和复用性。

响应式编程框架 Combine

在构建复杂界面的过程中，数据的流通一直是指令式编程中相当让人头疼的部分。

在 UIKit 框架下时，会配合 Target-Action 或者 protocol-delegate 模式来交换信息，使用 Key-Value Observing (KVO) 或者 Key-Value Coding (KVC) 来监测变化和读写属性。但即便开发者熟练地使用这些工具，面对日益增长的应用复杂性，掉坑里的可能性还是非常大。因为有太多需要开发者妥善处理的数据流动，例如数据改动后需要通知相关的页面进行刷新，或是让关联数据重新计算等。

像是 React Native 和 Flutter 这样的移动端跨平台方案，由于采用了声明式 UI 的编写方式和严格的数据流动方向，就能够大幅减轻开发者的思考负担。

SwiftUI 很明显也吸收了这些现代的编程思想，在另一个重量级系统框架 Combine 的协助下，实现了单一数据源的管理。

响应式编程的核心是将所有事件转化成为异步的数据流，这刚好就是 Combine 的主要功能。Combine 采用观察者模式，对应多个观察者，可以分别订阅感兴趣的内容。在 SwiftUI 的界面布局过程中，不同的 View 就是观察者，分别订阅了相关联的属性，并在数据发生变化之后就能够自动的重新渲染。

单一数据源

在 WWDC 的介绍视频中，「Source of truth」这个词反复出现，中文可以将这个词理解为单一数据源。

一直以来复杂的UI结构都会创造更为复杂的数据和逻辑管理需求，每次在用户交互，或是数据来源发生变化的时候，能否及时更新相关界面组件，不然就会引起显示问题。

但是在 SwiftUI 中，只要在属性声明时加上 @State 等关键词，就可以将该属性和界面元素联系起来，在每次数据改动后，都有机会决定是否更新视图。这样就可以将所有的属性都集中到一起进行管理和计算，也不再需要手写刷新的逻辑。因为在 SwiftUI 中，页面渲染前会将开发者描述的界面状态储存为结构体，更新界面就是将之前状态的结构体销毁，然后生成新的状态。而在绘制界面的过程中，会自动比较视图中各个属性是否有变化，如果发生变化，便会更新对应的视图，避免全局绘制和资源浪费。

使用这种方式，读和写都集中在一处，开发者就能够更好地设计数据结构，比较方便的增减类型和排查问题。而不用再考虑线程、原子状态、寻找最新数据等各种细节，再决定通知相关的界面进行刷新

与UIKit彼此相容

一般开发者学习新技术有一个最大的障碍就是原先的项目怎么办。但 SwiftUI 在这一点上做的相当不错。由于是一个新发布的框架，UI 组件并不齐全，当 SwiftUI 中并没有提供类似的功能时，就可以把 UIKit 中已有的部分进行封装，提供给 SwiftUI 使用。需要做的仅仅是遵循UIViewRepresentable协议即可。相反，在已有的项目中，也可以仅用 SwiftUI 制作一部分的 UI 界面。

当然两种代码的风格是截然不同的，但在使用上却基本没有性能的损失。到最终成品时，用户也无法分辨出两种界面框架的不同。

从开发者的⻆度看 SwiftUI

回到开头的问题：SwiftUI 到底有没有苹果宣传的那么理想化？

在 WWDC 发布 SwiftUI 时，有一句话让我印象深刻：「不论多复杂，原先布局的 99% 现在都可以使用 SwiftUI 进行构建」。当我查询 SwiftUI 是否可以承担大型项目开发时，又一次从资深开发者那里看到了这句话。

在我实际体验一段时间，并最终将一款全 SwiftUI 开发的应用上架后，认为这句话并没有什么问题，但前提是对编程这件事需要有比较基础且深入的理解。

这有点像我们学习一些优秀的第三方库时候的感受，同样是用 Xcode 写代码，有些人写出来就是白开水，而另一些人就是黑魔法。学习同样的语言特性，但由于理解的深刻程度不同，在使用时也会大不一样。仅仅依靠一些标准的自带组件无法做出一款出色的应用，即使如 UIKit 那样拥有如此丰富的组件也不行。很多时候还是要根据业务需要，或者是一些独特的脑洞做出最合适的界面。

对于个⼈开发者而言，意味着什么？

SwiftUI 的上限有多高，还要看未来一年一度的更新。但与之前的 UIKit 相比，下限被大大拉低已是不争的事实。这里的所谓下限，指的是学习的难度。由于描述性的布局方式与我们平时的阅读习惯非常接近，告诉系统在页面中间放一个图片就像告诉别人在桌子中间放一个苹果那么直观。我认识的好多 UI 设计师就通过短时间的自学掌握了 SwiftUI，并且搭建起可以直接在真机上使用的 Demo。

降低学习成本这件事是非常有意义的，不仅可以增加开发者数量，降低学习门槛，而且就学习本身而言，让初学者感受到成就感和明确学习方向，长久而言是比短时间的学习效率更重要的事情。只有开始的时候培养足够的兴趣，在后期才可能自主自发的研究更深入更困难的问题。

SwiftUI 和 Combine 大量借助了 Swift 的语法特性，尤其是 5.0 之后的几个更新，新特性就仿佛是为了这两个系统及框架量身定做的一般。虽然将 Swift 开源，但苹果无疑还是牢牢地把握着这门语言的发展。这两个框架和编程语言之间的配合默契，也仿佛让开发者体会到了软硬件一体带来的发展潜力。无论 Swift 出圈后的成果能有多少，在苹果的体系内，无疑是能够将各种消费层面的软件体验整合统一。

只要使用 SwiftUI，系统会默认支持白天和黑夜模式的自动切换；在各种尺寸的屏幕间自动适配；为任意控件添加 Haptic Touch 或是动画；在 Apple Watch 上带来独立而完整的体验；将iOS 的应用转换为 macOS 的原生应用，会以最快的速度支持第一方的各种新特性。这种对苹果硬件的深入支持是那些跨平台方案无论如何无法实现的。可以看一些采用第三方框架的知名应用，像是横屏、黑夜模式、小组件等基础的特性，到现在都迟迟没有适配。

所以 SwiftUI 对小工作室或是独立开发者来说是件好事，可以让新的想法快速落地并且接受市场验证，真正的做到敏捷开发。以这种方式在市场中的细分领域获得一席之地，也能让更多人体会到编写程序的感受，甚至是创造财富。

开源我的学习心得

在最后的部分我会分享一些自己学习 SwiftUI 的过程和介绍相关的资源，给一些也对开发感兴趣的小伙伴们做个参考。

首先要学习的是 Swift 编程语言，它与 OC 之间的差别还是挺大的，学习也没有什么捷径，直接阅读官方教程，对照着实例自己写一遍就行。国内有几个非常好的汉化网站，可以一起对照学习。基本上没有必要特意买书，反而不如直接电脑上看了就敲来的方便。

1. 官网


2. SwiftGG


3. GitHub 汉化库

对语言有了大概的了解后，就可以开始对 SwiftUI 的学习，假如遇到问题可以反复回去查看之前的资料。很多被忽略的细节，或是当时初看没概念的部分，结合具体的案例就能够有比较透彻的理解。

1. 斯坦福公开课 CS193P·2020 年春：该课程强推，我当年学习 OC 看的就是它，现在到SwiftUI了还是先看这个，系统且细致，结合案例和编程过程中的小技巧介绍，是很好的入门课程。


2. 苹果官方 SwiftUI 课程：打开Xcode，照着官方的教学，从头到尾学着做一遍应用。


3. Hacking with swift：这是国外一个程序员用业余时间搭建的分享网站，有大量的文章可以阅读，还有推荐初学者跟着做的「100 Days of SwiftUI」课程。


4. 苹果官方文档：文档是必读的，虽然很多文档缺乏工程细节，但是文档涉及很多概念性的内容，你可以知道官方是怎么思考的，并且有很多具体的机制参数。我本人有一个习惯，要是工程涉及某个框架，会把相关的文档都翻译一遍。


5. Stack Overflow：有问题查询专用，在谷歌中搜索错误代码或者关键词基本都会由该网站给答案。


6. 阅读 SwiftUI 库的源代码。

基本到此假如能够顺利完成下来，就可以开启自己的项目。开发想要提高的关键就是亲自写代码和不断地阅读学习。初期学习的关键能力就是英语，而到后期需要的就是真正的兴趣和一些数学能力。

这是我参与更文挑战的第4天，活动详情查看： 更文挑战

何为基石库？

做一个App无外乎两大要素：

• 获取数据

• 通过数据驱动页面

也许你的App没有网络请求或者网络请求少，你可以不需要Alamofire。

也许你的App的UI不是特别复杂，简单的xib和storyboard就可以胜任。

但是在当下一个App中，图片资源、字符串资源等，作为一个App开发者，你是不得不用的。

举个栗子，传统的获取一个image资源我们都是这么写：

let image = UImage(named: "saber")

这么写的最大弊端就是saber这是一个字符串硬编码，靠的的是纯手工敲打，一旦出错，界面就会出现异常。

在开发中，需要尽量避免这种硬编码，如何高效将这种硬编码的表达方式更换为高效安全的方式，就由本次的主角出场了--R.swift。

统和所有的资源，以现代化的方式引用资源，项目中使用它，虽然不会让你的App上升一个层次，不过却给你的编码极度舒适。

let image = R.image.saber()

同样是Ex咖喱棒，味道却完全不同，哈哈。

基石库就是那些你无法避免不得不用的库，而R.swift恰恰就是。

R.swift

何为R，即Resource的缩写，我们先看看官方给出的一些例子：

使用R.swift函数前：

let icon = UIImage(named: "settings-icon")

let font = UIFont(name: "San Francisco", size: 42)

let color = UIColor(named: "indicator highlight")

let viewController = CustomViewController(nibName: "CustomView", bundle: nil)

let string = String(format: NSLocalizedString("welcome.withName", comment: ""), locale: NSLocale.current, "Arthur Dent")

使用R.swift函数后：

let icon = R.image.settingsIcon()

let font = R.font.sanFrancisco(size: 42)

let color = R.color.indicatorHighlight()

let viewController = CustomViewController(nib: R.nib.customView)

let string = R.string.localizable.welcomeWithName("Arthur Dent")

所有的资源都函数化后，编写过程想出错都难，特别需要注意的是最后一个涉及国际化的函数R.string.localizable.welcomeWithName("Arthur Dent")，Arthur Dent这个字符串需要自己具体制定，可以通过在做国际化时，通过info.strings进行处理。

R.swift目前支持下面这些资源文件管理：

• Images
• Fonts
• Resource files
• Colors
• Localized strings
• Storyboards
• Segues
• Nibs
• Reusable cells

基本上覆盖了绝大多数的App中的资源管理。

安装和使用

安装

R.swift使用其他特别舒服，不过它的安装确实比其他的第三方库稍微麻烦一点，正所谓工欲善其事必先利其器，这一点麻烦是值得的。

1.添加'R.swift' 在工程的Podfile文件中，并运行pod install。 2.如下图所示。添加脚本：

3.如下图所示，移动脚本的位置，让它在Compile Sources phase和Check Pods Manifest.lock之间：

4.添加脚本：

在shell，下面这一栏添加"$PODS_ROOT/R.swift/rswift" generate "$SRCROOT/R.generated.swift"

在input Files通过+号添加$TEMP_DIR/rswift-lastrun

在Output Files通过+号添加$SRCROOT/R.generated.swift

5.运行添加R.generated.swift：

完成第4步后，进行command + B编译，然后在工程的根目录下面会找到R.generated.swift文件： 

将这个文件拖入到工程中，并且不要勾选Copy items if needed

这样，R.swift就安装完成啦。

使用

每一次添加了新的资源文件，就运行一次command + B一次，这样R.generated.swift文件就将新加入的资源文件更新，使用使用的时候只用通过R.来进行引用了。

更多用法，参考上面写的例子，以及官方文档

明天周末怎么破？

最怕周末更文，因为作为一个奶爸，休息都不是自己的，我争取做到不水文，至少讲一些知识点，明日继续，大家加油。

本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！

RxSwift编写wanandroid客户端现已开源

目前RxSwift编写wanandroid客户端已经开源了——项目链接。记得给个star喔！

附上一张效果图片：

本篇文章是从6月更文中热心网友的留言中进行的开发与探索：

6月确实因为日更的原因，这个功能没有实现，趁着7月的时候，解决了。

废话了这么多，那么我们进入主题吧。

什么是无感知上拉加载更多

什么是无感知，这个这样理解：在网络情况正常的情况下，用户对列表进行连续的上拉时，该列表可以无卡顿不停出现新的数据。

如果要体验话，Web端很多已经做到了，比如掘金的首页，还有比如掘金iOS的App，列表都是无感知上拉加载更多。

说来惭愧，写了这久的代码，还真的没有认真思考这个功能怎么实现。

如何实现无感知上拉加载更多

我在看见这位网友留言的时候，就开始思考了。

在我看来，有下面几个着手点：

• 列表滑动时候的是如何知道具体滑动的位置以触发接口请求，添加更多数据？

• 从UIScrollView的代理回调中去找和scrollView的位置（contentOffset）大小（contentSize）关系密切的回调。

• 网络上有没有比较成熟的思路？

顺着这条线，我先跑去看了UIScrollViewDelegate的源码：

public protocol UIScrollViewDelegate : NSObjectProtocol {



    

    @available(iOS 2.0, *)

    optional func scrollViewDidScroll(_ scrollView: UIScrollView) // any offset changes



    @available(iOS 3.2, *)

    optional func scrollViewDidZoom(_ scrollView: UIScrollView) // any zoom scale changes



    .

    .

    .

    .

    .

    .

    /// 代码很多，这里就不放上来，给大家压力了。

}

直接上结论吧：看了一圈，反正没有和contentSize或者位置相关的回调代理。scrollViewDidScroll这个回调里面虽然可以回参scrollView，但是对于我们需要的信息还不够具体。

思考：既然UIScrollViewDelegate的代理没有现成的代理回调，自己使用KVO去监听试试？

网上的思路（一）

就在我思考的同时，我也在网络上需求实现这个功能的答案，让后看到这样一个思路：

实现方法很简单，需要用到tableView的一个代理方法，就可轻松实现。- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath就是这个方法，自定义显示cell。这个方法不太常用。但是这个方法可在每个cell将要第一次出现的时候触发。然后我们可设置当前页面第几个cell将要出现时，触发请求加载更多数据。

我看了之后，心想着，多写一个TableView的代理，总比写KVO的代码少，先试试再说，于是代码撸起：

extension SwiftCoinRankListController: UITableViewDelegate {

    

    func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) {

        let row = indexPath.row

        let distance = dataSource.count - 25

        print("row: \(row), distance:\(distance)  ")

        if row == distance {

            loadMore()

        }

    }

}

本代码可以在开源项目中的SwiftCoinRankListController.swift文件查看具体的逻辑，其主要就是通过cell显示的个数去提前请求加载数据，然后我们看看效果：

Gif可能看起来还好，我说我调试的感受：

虽然做到了上拉无感知，但是当手滑的速度比较快的时候，到底了新的数据没有回来，就会在底部等一段时间。

功能达到了，但是感受却不理想，果然还是监听的细腻程度不够。

网上的思路（二）

然后在继续的搜索中，我看到了另外一个方案：

很多时候我们上拉刷新需要提前加载新数据，这时候利用MJRefreshAutoFooter的属性triggerAutomaticallyRefreshPercent就可以实现，该属性triggerAutomaticallyRefreshPercent默认值为1，然后改成0的话划到底部就会自动刷新，改成-1的话，在快划到底部44px的时候就会自动刷新。

MJRefresh？使用MJRefreshAutoFooter，这个简单，我直接把基类的footer给替换掉就可以了，本代码可以在开源项目中的BaseTableViewController.swift文件查看：

/// 设置尾部刷新控件,更新为无感知加载更多

let footer = MJRefreshAutoFooter()

footer.triggerAutomaticallyRefreshPercent = -1

tableView.mj_footer = footer

再来看看效果：

直接说感受：

代码改动性少，编写简单，达到预期效果，爽歪歪。比方案一更丝滑，体验好。

到此，功能就实现，难道就完了？

当然，不会，我们去看看源码吧。

MJRefresh代码的追根朔源

首先我们看看MJRefreshAutoFooter.h文件：

这里有个专门的属性triggerAutomaticallyRefreshPercent去做自动刷新，那么我们去MJRefreshAutoFooter.m中去看看吧：

注意看喔，这个.m文件有一个- (void)scrollViewContentOffsetDidChange:(NSDictionary *)change方法，并且还调用了super，从这个方法名中我们可以明显的得到当scrollView的contentOffset变化的时候进行回调的监听。，我们顺藤摸瓜，看看super是什么，会不会有新的发现：

稍微跟着一下源代码，MJRefreshAutoFooter的继承关系如下：

MJRefreshAutoFooter => MJRefreshFooter => MJRefreshComponent

所以这个super的调用我们就去MJRefreshComponent.m里面去看看吧：

通过上面的截图我们可以得到下面的一些信息与结论：

• MJRefreshComponent是通过KVO去监听scrollView的contentOffset变化，思路上我们对齐一致了。

• 该类并没有实现其具体方法，而是将其交由其子类去实现，这一点通过看MJRefreshComponent.h的注释可以得到：

• MJRefreshComponent从本质上更像虚基类。

总结

如果不是掘友提出这个问题，我可能都不会太仔细的去研究这个功能，也许继续普普通通的使用一般的上拉加载更多就够了。

这次的实践，其实是从思路到寻找方法，最后再到源码阅读。

思路也许不困难，但是真正一点点实现并完善功能，每一步都并不容易，这次我也仅仅是继续使用了MJRefresh这个轮子。

想起有一天，在群里吹水看见的一张图：

灵魂拷问，直击人心，大部分时间我们不也是云程序员呢？

知行合一方能开拓新的天地。

写在前面： iOS底层原理探究是本人在平时的开发和学习中不断积累的一段进阶之

路的。 记录我的不断探索之旅，希望能有帮助到各位读者朋友。

内容的总结专栏

• iOS 底层原理探索 之 阶段总结

序

作为一名iOS开发人员，在平时开发工作中，所有的对象我们使用最多的是alloc来创建。那么alloc底层做了哪些操作呢？接下来我会一步一步探究alloc方法的底层实现。

初探

我们先来看下面的代码

    SMPerson *p1 = [SMPerson alloc];

    SMPerson *p2 = [p1 init];

    SMPerson *p3 = [p1 init];

    

    NSLog(@"%@-%p-%p", p1, p1, &p1);

    NSLog(@"%@-%p-%p", p2, p2, &p2);

    NSLog(@"%@-%p-%p", p3, p3, &p3);

打印内容：

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15088

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15080

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15078

可见，在 SMPerson 使用 alloc 方法从系统中申请开辟内存空间后 init方法并没有对内存空间做任何的处理，地址指针的创建来自于 alloc方法。如下所示：

注：细心的你一定注意到了，p1、p2、p3都是相差了8个字节。 这是因为，指针占内存空间大小为8字节，p1、p2、p3 都是从栈内存空间上申请的，且栈内存空间是连续的。同时，他们都指向了同一个内存地址。

那么， alloc 是如何开辟内存空间的呢？

首先，第一反应是，我们要Jump to Definition，

结果，Xcode中并不能直接跳转后显示其底层实现，所以 并不是我们想要的。

中探

接下来，我们通过三种方法来一探究竟：

方法1

既然不可以直接跳转到API文档来查看alloc的内部实现，那么我们还可以通过下 符号断点 来探寻 其实现原理。

接下来我们就来到此处

一个名为 libobjc.A.dylib 的库，至此，我们就应该要去找苹果开源的库，以寻找我们想要的答案。

点击查看苹果开源源码汇总

方法2

我们也可以直接在alloc那一行打一个断点，代码运行到此处后，按住control键 点击 step into， 接下来，就来到里这里

 我们可以看到一个 objc_alloc 的函数方法到调用，此时，我们再下一个符号断点，同样的，我们还是找到了 libobjc.A.dylib 这个库。

方法3

此外，我们还是可以通过汇编来调试和查找相应的实现内容，断点依然是在alloc那一行。

Debug > Debug Workflow > Always Show Disassembly

找到 callq 方法调用那一行， 

接着， step into 进去， 我们找到了 objc_alloc 的调用， 之后的操作和 方法2的后续步骤一样，最终，可以找到 libobjc.A.dylib 这个库。 

深探

下载源码 objc4-818.2

接下来对源码进行分析，

alloc方法会调用到此处

接着是 调用 _objc_rootAlloc

之后调用 到 callAlloc

跟着断点会来到 _objc_rootAllocWithZone

之后是 _class_createInstanceFromZone

此方法是重点

_class_createInstanceFromZone 方法中，该方法就是一个类初始化所走的流程，重点的地方有三处

第一处是：

    // 计算出开辟内存空间大小

    size = cls->instanceSize(extraBytes);

内部实现如下：  其中在计算内存空间大小时，会调用 cache.fastInstanceSize(extraBytes) 方法，

最终会调用 align16(size + extra - FAST_CACHE_ALLOC_DELTA16) 方法。 align16 的实现如下：

static inline size_t align16(size_t x) {

    return (x + size_t(15)) & ~size_t(15);

}

可见, 系统会进行 16字节 的对齐操作,也就是说，一个对象所占用的内存大小至少是16字节。

在这里 我们举个例子： size_t x = 8； 那么 align16操作后的大小计算过程如下：

    (8 + 15) & ~15;

    

    0000 0000 0000 1000     8

    0000 0000 0000 1111     15  

    

=   0000 0000 0001 0111     23

    1111 1111 1111 0000     ~15

    

=   0000 0000 0001 0000     16

第二处是：

    ///向系统申请开辟内存空间，返回地址指针；

    obj = (id)calloc(1, size);

第三处是：

    /// 将类和指针做绑定

    obj->initInstanceIsa(cls, hasCxxDtor);

总结：

所以，最后我们总结一下， alloc的底层调用流程如下：

就是这样一个流程，系统就帮我们创建出来一个类对象。

补充

• lldb 如何打印实力对象中成员为 double 类型的数值： e -f f -- <值>

这是我参与8月更文挑战的第7天，活动详情查看：8月更文挑战

我的专栏

1. iOS 底层原理探索
2. iOS 底层原理探索 之 阶段总结

意识到我的问题

平时使用手机的时间不算少，每天阅读新闻的时候会感觉到新闻类的app优化的还是很好的，TableView的Cell滚动的时候不会去加载显示图片内容，当一次滑动结束之后，Cell上的新闻图片便开始逐个的加载显示出来，所以整个滑动的过程是很流畅的。这中体验也是相当nice的。

我最开始的做法

开发中TableView的使用是非常值频繁的，当TableViewCell上需要加载图片的时候，是一件比较头疼的事。因为，用户一边滑动TableView，TableView需要一边从网络获取图片。之前的操作都是放在 cellForRowAtIndexPath 中来处理，这就导致用户在滑动TableView的时候，会特别的卡（尤其是滑动特别快时），而且，手机的CPU使用率也会飙的非常的高。对于用户来说，这显然是一个十分糟糕的体验。

糟糕的图片显示 代码

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    

    ImageTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cell"];

    cell.index = indexPath;

    

    NSMutableDictionary *info = [self.dataSource objectAtIndex:cell.index.row];



    NSString *url = [info objectForKey: @"img" ];

    NSData *iData = [NSData dataWithContentsOfURL:[NSURL URLWithString: url ]];

    cell.img.image = [UIImage imageWithData:iData];

    cell.typeL.text = [NSString stringWithFormat:@"%ld-%ld", cell.index.section, cell.index.row];



    return cell;

}

糟糕的手机CPU飙升率

糟糕的用户滑动体验

不只是用户，对于开发这来讲，这也是不可以接受的体验。

平时接触并使用的app也非常的多，发现他们多处理方式就是，当用户滑动列表的时候，不再加载图片，等用户的滑动结束之后，会开始逐一的加载图片。这是非常好的优化思路，减轻了CPU的负担，也不会基本不会让用户感觉到页面滚动时候的卡顿。这也就是最开始我描述的我看新闻app的使用体验。

收到这个思路的启发，我们开始着手将上面糟糕的体验作一下优化吧。

总结思路开启优化之路

那么，带着这个优化思路，我开始了对于这个TableView 的优化。

• 首先，我们只加载当前用户可以看到的cell上的图片。
• 其次，我们一次只加载一张图片。

要完成以上两点，图片的加载显示就不能在cellForRowAtIndexPath中完成，我们要定义并实现一个图片的加载显示方法，以便在合适的时机，调用刷新内容显示。

loadSeeImage 加载图片的优化

#pragma mark load Images

- (void)loadSeeImage {



    //记录本次加载的几张图片

    NSInteger loadC = 0;

    

    // 用户可以看见的cells

    NSArray *cells = [self.imageTableView visibleCells];

    

    // 调度组

    dispatch_group_t group = dispatch_group_create();

    

    for (int i = 0; i < cells.count; i++) {

        

        ImageTableViewCell *cell = [cells objectAtIndex:i];

        

        NSMutableDictionary *info = [self.dataSource objectAtIndex:cell.index.row];

        NSString *url = [info objectForKey: @"img" ];

        

        NSString *data = [info objectForKey:@"data"];

        

        if ([data isKindOfClass:[NSData class]]) {

            

            

        }else {

            

            // 添加调度则到我们的串行队列中去

            dispatch_group_async(group, self.loadQueue, ^{

                

                NSData *iData = [NSData dataWithContentsOfURL:[NSURL URLWithString: url ]];

                NSLog(@" load image %ld-%ld ", cell.index.section, cell.index.row);

                if (iData) {

                // 缓存

                    [info setValue:@"1" forKey:@"isload"];

                    [info setValue:iData forKey:@"data"];

                }

                NSString *isload = [info objectForKey:@"isload"];

                

                if ([isload isEqualToString:@"0"]) {

                    

                    dispatch_async(dispatch_get_main_queue(), ^{



                        cell.img.image = [UIImage imageNamed:@""];

                    });                }else {

                    

                    if (iData) {

                      

                        dispatch_async(dispatch_get_main_queue(), ^{

                     //显示加载后的图片       

                            cell.img.image = [UIImage imageWithData:iData];

                        });

                    }

                }

                

            });

 

            if (i == cells.count - 1) {



                dispatch_group_notify(group, dispatch_get_main_queue(), ^{

                    // 全部加载完毕的通知

                    NSLog(@"load finished");

                });

            }

            

            loadC += 1;

        }

    }

  

    NSLog(@"本次加载了 %ld 张图片", loadC);

}

其次就是 loadSeeImage 调用时机的处理，我们要做到用户在滑动列表之后加载，就是在下面两处加载：

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView   {  

    

    [self loadSeeImage];

}



- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {

    

    if (scrollView.isDragging || scrollView.isDecelerating || scrollView.isTracking) {

        return;

    }

    [self loadSeeImage];

}

当然，首次进入页面，列表数据加载完毕后，我们也要加载一次图片的哦。 好的下面看下优化后的结果：

CPU占用率比之前最高的时候降低了一半多，app在滑动的时候也没有明显卡顿的地方。 完美。

前言

开发规范的目的是保证统一项目成员的编码风格，并使代码美观，每个公司对于代码的规范也不尽相同，希望该份规范能给大家起到借鉴作用。本文为原创，如需转载请说明原文地址链接。

命名规约

• 代码中的命名严禁使用拼音及英文混合的方式，更不允许直接出现中文的方式，最好也不要使用下划线或者美元符号开头；
• 文件名、class、struct、enum、protocol 命名统一使用 UpperCamelCase 风格；
• 方法名、参数名、成员变量、局部变量、枚举成员统一使用 lowerCamelCase 风格
• 全局常量命名使用 k 前缀 + UpperCamelCase 命名；
• 扩展文件，用“原始类型名＋扩展名”作为扩展文件名，其中原始类型名及扩展名也使用 UpperCamelCase 风格，如UIView+Frame.swift；
• 工程中文件夹或者 Group 统一使用 UpperCamelCase 风格，一律使用单数形式；
• 命名中出现缩略词时，缩略词要么全部大写，要么全部小写，以首字母大小写为准，通用缩略词包括 JSON、URL 等；如class IDUtil {}、func idToString() { }
• 不要使用不规范的缩写，如 AbstractClass“缩写”命名成 AbsClass 等，不怕名称长，就怕名称不明确。
• 文件名如果有复数含义，文件名应使用复数形式，如一些工具类；

修饰规约

• 能用 let 修饰的时候，不要使用 var；
• 修饰符顺序按照 注解、访问限制、static、final 顺序；
• 尽可能利用访问限制修饰符控制类、方法等的访问限制；
• 写方法时，要考虑这个方法是否会被重载。如果不会，标记为 final，final 会缩短编译时间；
• 在编写库的时候需要注意修饰符的选用，遵循开闭原则；

格式规约

• 类、函数左大括号不另起一行，与名称之间留有空格
• 禁止使用无用分号
• 代码中的空格出现地点
  • 注释符号与注释内容之间有空格
  • 类继承, 参数名和类型之间等, 冒号前面不加空格, 但后面跟空格
  • 任何运算符前后有空格
  • 表示返回值的 -> 两边
  • 参数列表、数组、tuple、字典里的逗号后面有一个空格
• 方法之间空一行
• 重载的声明放在一起，按照参数的多少从少到多向下排列
• 每一行只声明一个变量
• 如果是一个很长的数字时，建议使用下划线按照语言习惯三位或者四位一组分割连接。
• 表示单例的静态属性，一般命名为 shared 或者 default
• 如果是空的 block，直接声明{ }，括号之间不需换行
• 解包时推荐使用原有名字，前提是解包后的名字与解包前的名字在作用域上不会形成冲突
• if 后面的 else\else if, 跟着上一个 if\else if 的右括号
• switch 中, case 跟 switch 左对齐
• 每行代码长度应小于 100 个字符，或者阅读时候不应该需要滚动屏幕，在正常范围内可以看到完整代码
• 实现每个协议时, 在单独的 extension 里来实现

简略规约

• Swift 会被结构体按照自身的成员自动生成一个非 public 的初始化方法，如果这个初始化方法刚好适合，不要自己再声明
• 类及结构体初始化方法不要直接调用.init，直接直接省略，使用()
• 如果只有一个 get 的计算属性，忽略 get
• 数据定义时，尽量使用字面量形式进行自动推断，如果上下文不足以推断字面量类型时，需要声明赋值类型
• 省略默认的访问权限（internal）
• 过滤, 转换等, 优先使用 filter, map 等高阶函数简化代码，并尽量使用最简写
• 使用闭包时，尽量使用最简写
• 使用枚举属性时尽量使用自动推断，进行缩写
• 无用的代码及时删除
• 尽量使用各种语法糖
• 访问实例成员或方法时尽量不要使用 self.，特殊场景除外，如构造函数时
• 当方法无返回值时，不需添加 void

注释规约

• 文档注释使用单行注释，即///，不使用多行注释，即/***/。 多行注释用于对某一代码段或者设计进行描述
• 对于公开的类、方法以及属性等必须加上文档注释，方法需要加上对应的Parameter（s）、Returns、Throws 标签，强烈建议使用⌥ ⌘ /自动生成文档模板
• 在代码中灵活的使用一些地标注释，如MARK、FIXME、TODO，当同一文件中存在多种类型定义或者多种逻辑时，可以使用Mark进行分组注释
• 尽量将注释另起一行，而不是放在代码后

其他

• 不要使用魔法值(即未经定义的常量)；
• 函数参数最多不得超过 8 个；寄存器数目问题，超过 8 个会影响效率；
• 图形化的字面量，#colorLiteral(...), #imageLiteral(...)只能用在 playground 当做自我练习使用，禁止在项目工程中使用
• 避免强制解包以及强制类型映射，尽量使用if let 或 guard let进行解包，禁止try！形式处理异常，避免使用隐式解包
• 避免判断语句嵌套层次太深，使用 guard 提前返回
• 如果 for 循环在函数体中只有一个 if 判断，使用 for where 进行替换
• 实现每个协议时, 尽量在单独的 extension 里来实现；但需要考虑到协议的方法是否有 override 的可能，定义在 extension 的方法无法被 override，除非加上@objc 方法修改其派发方式
• 优先创建函数而不是自定义操作符
• 尽可能少的使用全局命名空间，如常量、变量、方法等
• 赋值数组、字典时每个元素分别占用一行时，最后一个选项后面也添加逗号；这样未来如果有元素加入会更加方便
• 布尔类型属性使用 is 作为属性名前缀，返回值为布尔型类型的方法名使用 is 作为方法名作为前缀
• 类似注解的修饰词单独占一行，如@objc，@discardableResult 等
• extension 上不用加任何修饰符，修饰符加在 extension 内的变量或方法上
• 使用 guard 来提前结束条件，避免形成判断嵌套；
• 善用字典去减少判断，可将条件与结果分别当做 key 及 value 存入字典中；
• 封装时善用 assert，方便问题排查；
• 在闭包中使用 self 时使用捕获列表[weak self]避免循环引用，闭包开始判断 self 的有效性
• 使用委托和协议时，避免循环引用，定义属性的时候使用 weak 修饰

工具

SwiftLint 工具 提示格式错误

SwiftFormat 工具 提示并修复格式错误

两者大部分格式规范都是一致的，少许规范不一致，两个工具之间使用不冲突，可以在项目中共存。我们通过配置文件可以控制启用或者关闭相应的规则，具体使用规则参照对应仓库的 REAMME.md 文件。

相关规范

Swift 官方 API 设计指南

google 发布的 Swift 编码规范

有一个技术的圈子与一群同道众人非常重要，来我的技术公众号及博客，这里只聊技术干货。

• 微信公众号：CoderStar
• 博客：CoderStar's Blog

链接：https://juejin.cn/post/6976282985695969294

我是独立开发者熊大，最近一年尝试了独立开发的滋味，也想和大家聊一聊独立开发的心历路程。 如果你也有开发一款app的想法，那你可以看一看我的独立开发的故事。

• 我做过直播、相机、社交类APP。
• 个人独立app 《imi》《今日计划》
• 2020年，我想要尝试一下独立开发的方向。

第一款app的开发周期

做第一款软件《今日计划》时，周一到周六工作，大小周，晚上会有一些开发时间。

总体如下：

• 每天1小时写app代码 * 60 = 60小时
• 每周周日有4个小时 * 8 = 32小时
• 清明节三天 （按照8小时/天tian计算）：3*8 = 24小时

一共约120个小时：完成了设计到上线。

我也买了阿里云的ECS，用vapor搭建了后台，维护成本有点高，果断放弃了。

当我开心的把它分享给朋友时，朋友们都说他很丑，于是被贴上一系列标签『丑』、『直男审美』、『搭配有问题』、『太简单了吧』····，总而言之，没什么好的形容词。

(PS:T M D 我自己都感觉有点坑)

 报着期望，又紧急改版一次，更换了icon，改了一些设计。也就是现在的这一版。我在圈子里又推广了一波，登顶效率榜Top20（其实是各位兄弟给面子）。

后来陆陆续续也有一些下载，但由于工作紧张，没能持续更新迭代。

离职风波

《水印相机》这款app目前，摄影榜Top20，很荣幸是我从零带到百万日活的，深知好产品的指数爆发增长。我内心真的想去外边看看，想见识更多优秀的、有趣的人，于是世界那么大，我想出去看看，真的成为了我离职的最主要理由。

从上家公司收获的最大的便是经验，一份让我受用很多年的经验。

离职后，并不缺少内推的机会，但我还没想好该怎么走接下来的路，我在思考，是去大厂深造，还是开启自由职业呢？自己一直是个骄傲的人，毕业时我的薪资就是 xx k，不能为五斗米而折腰，干脆做个自由职业好了。于是把想法讲给周围的人，最后还是找了份工作，公司就在我家的旁边，上下班5分钟。

于是从7月份开始，我就几乎每天晚上有两个小时的时间为开启我的自由职业之路做准备，只要副业收入过万，就开始全职独立开发。

新app上线

2020.08 一个小伙伴，会飞的猪，加入了开发阵营。

2020.10 小满 加了开发阵营。

（由于特殊原因，名字保密）

2021年1月上线了新的免费App《imi-成就最好的自己》，这次的app，至少在UI上取得了程序员的好评，我们还没有正式推广，只是在小圈子里发了一下动态试试水。

我们小团队也开了个新的公·众·号：《独立开发者基地》，感兴趣额可以关注。

惭愧的是，由于新公司较忙，进行了几次通宵加班后，我严重的拖累了小团队的开发进度，本来应该是2020年底就应该上线的。

《imi》

这是一款风格可爱简单的规划、计划类软件，致敬自己，致敬青春。

imi寓意：我就是我，我们一定是不完美的，也许不成功，也许不漂亮，但这就是我，与众不同。

给张图看看：

这个idea是我想的，简单说就是一个计划类软件，里边有

• 人生节点
• 座右铭
• 成就
• 笔记
• 喜欢的人
• 倒计时
• 指纹解锁
• 云同步。

设计这款软件希望能让大家觉得有用，不知道软件的初衷是不是个伪命题。让时间见证吧。

独立开发者应该都知道霸榜很久的《时间规划局》，这次《imi》就是冲着它去的，她将作为我们的竞品之一，我想我们这么有情怀的app对标这样的工具类软件，是有点希望的（怕怕）。

希望大家下载： imi-成就 给予我们支持 ^_^

给独立开发者的福利

这个应该算是福利吧，我们小团队，整理出了app的加速库，《今日计划》《imi-成就》两款app都是基于这个加速库开发的。接下来的其他app也会基于这个加速库开发，意味着我们会持续完善、维护这个加速库。里边有很多实用的功能，欢迎star🌟。

加速库SpeedySwift仓库：https://github.com/Tliens/SpeedySwift

imi 中用到的第三方库：

  # Pods for App1125

  pod 'HWPanModal', '~> 0.8.1'

  pod 'RealmSwift', '~> 10.5.0'   

  pod 'ZLPhotoBrowser', '~> 4.1.2'

  pod 'SwiftDate', '~> 6.3.1'

  pod 'IceCream',:path =>'Dev-pods/IceCream'                  # 数据同步icloud

  # pod 'FSPagerView'               # 轮播图

  # pod 'SwiftyStoreKit'            # 内购组件

  pod 'Schedule', '~> 2.1.0'

  pod 'Hero', '~> 1.5.0'

  pod 'BiometricAuthentication'

  #依赖库

  pod 'UMCCommon', '~> 2.1.4'

  #统计 SDK

  pod 'UMCAnalytics', '~> 6.1.0'

回顾2020

get的技能：

• 有幸能主导组件化开发
• 函数响应式编程
• go服务端

展望2021

希望大家健康、开心

我们会继续维护，维护今日计划、imi。也会有新的app出现。

最后

天行健君子以自强不息，地势坤君子以厚德载物。

虽大部分努力都没有收获，但热爱诞生创造的婴孩。

与君共勉！！！

写于 2021.01.13 北京·安贞门

链接：https://juejin.cn/post/6917058456184684557

先看看这个路由的使用吧

1. 如果是网络地址，会直接自动跳转到 OtherWKWebViewController
2. 如果是应用内部的手动调用跳转

• 直接跳转视图控制器
  • EPRouter.pushViewController(EPSMSLoginViewController())
• 先在 RouteDict 注册映射关系再跳转
  • EPRouter.pushAppURLPath("goods/detail?spellId=xxx&productId=xxx")

3. 又服务器来控制跳转 也得在 RouteDict 注册映射关系，只不过多加了一个 scheme
   • EPRouter.pushURLPath("applicationScheme://goods/detail?spellId=xxx&productId=xxx")

**！！！支持Swift、OC、Storyboard的跳转方式，可以在 loadViewController 看到实现方式 **

EPRouter的全部代码

class EPRouter: NSObject {



    private static let RouteDict:[String:String] = [

        "order/list"            :"OrderListPageViewController",   // 订单列表 segmentIndex

        "order/detail"          :"OrderDetailViewController",     // 订单详情 orderId

        "goods/detail"          :"GoodsDetailViewController",     // 商品详情productId

        "goods/list"            :"GoodsCategoryViewController",   // type brandId 跳转到某个分类；跳转到某个品牌

        "goods/search"          :"SearchListViewController",      // 搜索商品 text

        "coupon/list"           :"CouponListViewController",      // 优惠券列表

        "cart/list"             :"CartViewController",            // 购物车列表

        "address/list"          :"AddressListViewController",     // 收货地址列表

    ]

    

    

// 返回首页，然后指定选中模块

public static func backToTabBarController(index: NSInteger, completion:(()->())?=nil) {



    guard let vc = EPCtrlManager.getTopVC(), let nav = vc.navigationController, let tabBarCtrl = nav.tabBarController  else {

        return

    }



    nav.popToRootViewController(animated: false)

    DispatchQueue.main.asyncAfter(deadline: DispatchTime.now()+0.1) {

        tabBarCtrl.selectedIndex = index

        completion?()

    }

}





// 销毁n个界面 不建议使用这个方法 可以在pushAppURLPath方法中设置destroyTime达到一样的效果，又可以避免用户侧滑返回

public static func popViewController(animated: Bool, time:NSInteger=1) {



    guard let nav = EPCtrlManager.getTopVC()?.navigationController else {

        return

    }

    let vcs = nav.viewControllers

    let count = vcs.count

    let index = (count - 1) - time

    if index >= 0 {

        let vc = vcs[index]

        nav.popToViewController(vc, animated: true)

    } else {

        nav.popViewController(animated: true)

    }

}





    /// 回到目标控制器

    public static func popViewController(targetVC: UIViewController.Type, animated: Bool, toRootVC: Bool=true) {



        popViewController(targetVCs: [targetVC], animated: animated, toRootVC: toRootVC)

    }



    



    /// 回到目标控制器[vc],从前到后 没有目标控制器是否回到根视图

    public static func popViewController(targetVCs: [UIViewController.Type], animated: Bool, toRootVC: Bool=true) {



        guard let nav = EPCtrlManager.getTopVC()?.navigationController else {

            return

        }

        let vcs = nav.viewControllers

        var canPop = false

        for vc in vcs {

            for tvc in targetVCs {

                if vc.isMember(of: tvc) {

                    canPop = true

                    nav.popToViewController(vc, animated: animated)

                    break

                }

            }

        }

        if !canPop && toRootVC {

            nav.popToRootViewController(animated: animated)

        }

    }



    /// push 一个vc --- destroyTime: push之前要销毁的几个压栈vc

    @objc public static func pushAppURLPath(_ path: String, query: [AnyHashable: Any]=[:], animated: Bool=true, destroyTime:NSInteger=0) {



        var urlString = "applicationScheme://"+path

        if path.contains("http://") || path.contains("https://") {

            urlString = path

        }

        pushURLString(urlString, query: query, animated: animated, destroyTime: destroyTime)

    }





    @objc public static func pushURLString(_ urlString: String, query: [AnyHashable: Any]=[:], animated: Bool=true, destroyTime:NSInteger=0) {



        guard let tvc = loadViewControllerWitURI(urlString, query: query) else {

            return

        }

        pushViewController(tvc, animated: animated, destroyTime: destroyTime)

    }





    @objc public static func pushViewController(_ tvc: UIViewController, query: [AnyHashable: Any]=[:], animated: Bool=true, destroyTime:NSInteger=0) {



        guard let vc = EPCtrlManager.getTopVC() else {

            return

        }



        if let _ = tvc.pushInfo {

            tvc.pushInfo?.merge(query, uniquingKeysWith: { (_, new) in new })

        }else {

            tvc.pushInfo = query

        }

        guard let nav = vc.navigationController else {

            vc.present(tvc, animated: true, completion: nil)

            return

        }

        tvc.hidesBottomBarWhenPushed = true



        if destroyTime > 0 {

            let vcs = nav.viewControllers

            let count = vcs.count

            var index = (count - 1) - destroyTime

            if index < 0 { // destroyTime 很多时，直接从根视图push

                index = 0

            }



            var reVCS = [UIViewController]()

            for vc in nav.viewControllers[0...index] {

                reVCS.append(vc)

            }

            reVCS.append(tvc)

            nav.setViewControllers(reVCS, animated: animated)

        }else {

            nav.pushViewController(tvc, animated: animated)

        }

    }



    public static func loadViewController(_ className: String, parameters: [AnyHashable: Any]? = nil) -> UIViewController? {



        var desVC: UIViewController?

        let spaceName = (Bundle.main.infoDictionary?["CFBundleExecutable"] as? String) ?? "ApplicationName"



        if let vc = storyboardClass(className) { // storyboard

            desVC = vc

        }else if let aClass = NSClassFromString("\(spaceName).\(className)") { // Swift

            if aClass is UIViewController.Type {

                let type = aClass as! UIViewController.Type

                desVC = type.init()

            }

        }else if let aClass = NSClassFromString("\(className)") { // OC

            if aClass is UIViewController.Type {

                let type = aClass as! UIViewController.Type

                desVC = type.init()

            }

        }



        desVC?.pushInfo = parameters

        return desVC

    }





    public static func loadViewController(_ viewController: UIViewController, parameters: [AnyHashable: Any]? = nil) -> UIViewController {



        viewController.pushInfo = parameters

        return viewController



    }



    public static func loadViewControllerWitURI(_ urlString: String, query: [AnyHashable: Any]? = nil) -> UIViewController? {



        



        // 先进行编码，防止有中文的带入, 不行进行二次编码

        var urlString = urlString

        if (URLComponents(string: urlString) == nil) {

            urlString = urlString.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) ?? urlString

        }



        guard let url = URLComponents(string: urlString), let scheme = url.scheme else {

            HGLog("无效的地址:\(urlString)")

            return nil

        }



        if scheme == "http" || scheme == "https" {



            let webVC = OtherWKWebViewController()

            webVC._urlStr = urlString

            return webVC



        } else if String(format: "%@://", scheme) == "appcationScheme://" {

            let path = (url.host ?? "") + url.path

            guard  var vcClassName = RouteDict[path] else {

                HGLog("没有配置视图控制器呢。。。:\(urlString)")

                return nil

            }



            var info: [AnyHashable: Any]?

            if query?.count ?? 0 > 0 {

                info = [AnyHashable: Any]()

                for (key, value) in query! {

                    info![key] = value

                }

            }



            if let queryItems = url.queryItems {

                if info == nil {

                    info = [AnyHashable: Any]()

                }

                for item in queryItems {

                    if let value = item.value {

                        info![item.name] = value

                    }

                }

            }

            return loadViewController(vcClassName, parameters: info)

        }



        HGLog("未知scheme:\(urlString)")

        return nil



    }



    



    private static func storyboardClass(_ className: String) -> UIViewController? {



        if className == "VIPWithdrawViewController" { // 提现

            let vc = UIStoryboard.init(name: "VIP", bundle: nil).instantiateViewController(withIdentifier: "withdrawTVC")

            return vc

        }else if className == "VIPRecordListViewController" { // 提现记录

            let vc = UIStoryboard.init(name: "VIP", bundle: nil).instantiateViewController(withIdentifier: "recordListVC")

            return vc

        }

        return nil

    }

}

用来跳转传递数据的扩展属性

extension UIViewController {



    private struct PushAssociatedKeys {

        static var pushInfo = "pushInfo"

    }



    @objc open var pushInfo: [AnyHashable: Any]? {

        get {

            return objc_getAssociatedObject(self, &PushAssociatedKeys.pushInfo) as? [AnyHashable : Any]

        }

        set(newValue) {

            objc_setAssociatedObject(self, &PushAssociatedKeys.pushInfo, newValue, .OBJC_ASSOCIATION_RETAIN_NONATOMIC)

        }

    }

}

可见视图控制器的获取

class EPCtrlManager: NSObject {



    public static let `default`: EPCtrlManager = {

        return EPCtrlManager()

    }()



    // MARK: **- 查找顶层控制器、**

    // 获取顶层控制器 根据window

    @objc public static func  getTopVC() -> UIViewController? {



        var window = UIApplication.shared.keyWindow

        //是否为当前显示的window

        if window?.windowLevel != UIWindow.Level.normal{

            let windows = UIApplication.shared.windows

            for  windowTemp in windows{

                if windowTemp.windowLevel == UIWindow.Level.normal{

                    window = windowTemp

                    break

                }

            }

        }

        let vc = window?.rootViewController

        return getTopVC(withCurrentVC: vc)

    }



    ///根据控制器获取 顶层控制器

    private static func  getTopVC(withCurrentVC VC :UIViewController?) -> UIViewController? {



        if VC == nil {

            print("🌶： 找不到顶层控制器")

            return nil

        }



        if let presentVC = VC?.presentedViewController {

            //modal出来的 控制器

            return getTopVC(withCurrentVC: presentVC)

        }else if let tabVC = VC as? UITabBarController {

            // tabBar 的跟控制器

            if let selectVC = tabVC.selectedViewController {

                return getTopVC(withCurrentVC: selectVC)

            }

            return nil

        } else if let naiVC = VC as? UINavigationController {

            // 控制器是 nav

            return getTopVC(withCurrentVC:naiVC.visibleViewController)

        } else {

            // 返回顶控制器

            return VC

        }

    }

}

这是我参与11月更文挑战的第8天，活动详情查看：2021最后一次更文挑战

引言

作为一名开发人员，当我们编写代码时，我们会更多地关注逻辑和算法，而不是拼写和语法。但它也是我们编码的一个重要部分，特别是当我们从注释生成文档的时候。

拼写检查帮助我们找出拼写错误，让我们有更多的时间关注代码逻辑。

拼写检查能识别什么

答案就是代码中与Spelling and Grammer相关的所有内容

• 变量名
• 方法
• 类
• 注释
• 字符串的字面量(包括本地化)

先来看一段代码：

在上面的代码中，包括类、方法、变量和注释，但没有启用Spelling and Grammer。猛一看去，好像没啥问题，但如果我们仔细检查，就会发现很多拼写错误。

现在让我们启用Spelling and Grammer，看看会发生什么-

在上面的代码中我们可以看到，当我们启用拼写检查时，它能检测到所有的拼写错误，并用红色高亮显示。现在我们就省去了找错误的时间，可以直接去修改了。

如何开启

Edit > Format > Spelling and Grammar

可以看到有三个可用的选项，我们依次来看下：

Check Spelling While Typing

启用后，会把项目中的所有输入错误一次性、全部以红色高亮显示，就像上面的例子一样。

另外，开启这个选项后，还可以选中要修改的单词，然后右键，菜单中会出现 Xcode 建议的单词。

Check Document Now

它将在当前文件中逐个显示输入错误。为了检查当前文件中的所有错误，可以重复这个命令
Edit > Format > Spelling and Grammar > Check Document Now

或者使用快捷键
command 和分号（;）的组合

Show Spelling and Grammar

它会打开所有建议的更改。我们可以单击其中任何一个进行替换。 使用命令
Edit > Format > Spelling and Grammar > Show Spelling and Grammar

或者使用快捷键
command 和冒号（:）的组合

Learn Spelling 和 Ignore Spelling

有时候我们需要使用一些在系统词典中没有定义的独特词汇，比如应用程序前缀、开发者名称、公司名称等。Xcode 也会检查这些单词的错误。

所以就用Learn Spelling或者Ignore Spelling处理这些特殊的单词。

通过菜单

右键选中要处理的单词

通过 command + ：

结语

快去探索一下 Edit > Format > Spelling and Grammar 下面的三个选项吧~

这是我参与11月更文挑战的第5天，活动详情查看：2021最后一次更文挑战

引言

Swift 有很多其他语言所没有的独特的结构和方法，因此很多刚开始接触 Swift 的开发者并没有发挥它本身的优势。

所以，我们就来看一看那些让你的 Swift 代码更 Swift 的写法吧~

有条件的 for 循环

现在，我们要对view.subviews中的UIButton做一些不可描述的事情，用 for 循环怎么来遍历呢？

在下面的写法中，更推荐后面两种写法：

❌

for subView in view.subviews {

    if let button = subView as? UIButton {

        //不可描述的事情

    }

}



✅

for case let button as UIButton in view.subviews {

    //不可描述的事情

}



✅

for button in view.subviews where button is UIButton {

    //不可描述的事情

}

enumerated()

在 Swift 中进行 for 循环，要拿到下标值，一般的写法要么定义局部变量记录下标值，要么遍历 0..<view.subviews.count。其实还有个更方便的写法：enumerated()，可以一次性拿到下标值和遍历的元素。

• ❌ 第一种肯定是不推荐的，因为还要定义额外的局部变量，容易出错，pass

• ✅ 第二种在只需要用到下标值的时候，是可以用的，但如果还要用到下标值对应的元素，就还得再取一次，麻烦，pass

• ✅ 第三种就比较完美，虽然一次性可以拿到下标值和元素，但其中一个用不到就可以用 _

❌

var index: Int = 0

for subView in view.subviews {

    //不可描述的事情

    index += 1

}



✅

for index in 0..<view.subviews.count {

    let subView = view.subviews[index]

    //不可描述的事情

}



✅

//index 和 subView 在循环体中都能使用到

for (index, subView) in view.subviews.enumerated() {

    //不可描述的事情

}



//只用到 index

for (index, _) in view.subviews.enumerated() {

    //不可描述的事情

}



//只用到 subView

for (_, subView) in view.subviews.enumerated() {

    //不可描述的事情

}

first(where: )

filter 是 Swift 中几个高级函数之一，过滤集合中的元素时非常的好用，不过在某些情况下，比如获取集合中满足条件的第一个元素时，有一个更好的选择first(where: )

let article1 = ArticleModel(title: "11", content: "内容1", articleID: "11111", comments: [])



let article2 = ArticleModel(title: "11", content: "内容2", articleID: "22222", comments: [])



let article3 = ArticleModel(title: "33", content: "内容3", articleID: "3333", comments: [])



let articles = [article1, article2, article3]



❌

if let article = articles.filter({ $0.articleID == "11111" }).first {

    print("\(article.title)-\(article.content)-\(article.articleID)")

}



✅

if let article = articles.first(where: {$0.articleID == "11111"}) {

    print("\(article.title)-\(article.content)-\(article.articleID)")    //11-内容1-11111

}

contains(where: )

这个和上面的first(where: )几乎一样，比如这里要判断文章列表里是否包含 articleID 为 11111 的文章：

❌

if !articles.filter({ $0.articleID == "11111" }).isEmpty {

    //不可描述的事情

}



✅

if articles.contains(where: { $0.articleID == "11111"}) {

    //不可描述的事情

}

forEach

当循环体内的逻辑比较简单时，forEach 往往比 for...in...来的更加简洁：

func removeArticleBy(ID: String) {

    //删库跑路

}



❌

for article in articles {

    removeArticleBy(ID: $0.articleID)

}



✅

articles.forEach { removeArticleBy(ID: $0.articleID) }

计算属性 vs 方法

我们知道计算属性本身不存储数据，而是在 get 中返回计算后的值，在 set 中设置其他属性的值，所以和方法很类似，但比方法更简洁。一起来看下面的示例：

❌

class YourManager {

    static func shared() -> YourManager {

        //不可描述的事情

    }

}



let manager = YourManager.shared()



❌

extension Date {

    func formattedString() -> String {

        //不可描述的事情

    }

}



let string = Date().formattedString()





✅

class YourManager {

    static var shared: YourManager {

        //不可描述的事情

    }

}



let manager = YourManager.shared



✅

extension Date {

    var formattedString: String {

        //不可描述的事情

    }

}



let string = Date().formattedString

协议 vs 子类化

尽量使用协议而不是继承。协议可以让代码更加灵活，因为类可同时遵守多个协议。

此外，结构和枚举不能子类化，但是它们可以遵守协议，这就更加放大了协议的好处

Struct vs Class

尽可能使用 Struct 而不是 Class。Struct 在多线程环境中更安全，更快。

它们最主要的区别， Struct 是值类型，而 Classe 是引用类型，这意味着 Struct 的每个实例都有它自己的唯一副本，而 Class 的每个实例都有对数据的单个副本的引用。

这个链接是苹果官方的文档，解释如何在 Struct 和 Class 之间做出选择。 developer.apple.com/documentati…

结语

让我们的 Swift 代码更 Swift 的方法远不止上面这些，这里要说的是，平时写代码时，要刻意的使用 Swift 强大的特性，才能发挥它本身的价值。

而这些特性就需要大家去多看看官网的例子，或者一些主流的 Swift 第三方库，看看他们是如何运用 Swift 的特性的。

截至 2021 年 8 月，Android 和 iOS 平台占据移动操作系统市场份额的 99.15%。这些平台多年来一直主导着移动应用市场。结果是各种移动开发技术的兴起，包括跨平台框架。  

React Native 是其中最受欢迎的一种。 

为什么？

React Native 允许开发人员跨平台共享多达 70% 的代码库。更快的开发、降低的成本和易于调试是该框架的一些好处。Facebook 的支持还确保 React Native 保持最佳运行状态。但是，就像其他所有框架一样，它也有其局限性。  

React Native 工程师经常面临兼容性问题和缺乏自定义模块。此外，使用此框架构建的应用程序因其近乎原生的功能而受到的性能影响较小。考虑到这一点，React Native 是一个不错的选择吗？这个问题的答案取决于您的产品要求。为了帮助您做出决定，我们编制了一份 React Native 替代方案列表，这些替代方案可为您的应用程序提供强大、便捷的功能。最后，您将能够知道要使用哪种技术。 

让我们开始吧！

需要考虑的 React Native 替代方案

原生平台：

本机应用程序编程语言是一些最流行的替代方案。它们是用于为操作系统开发移动应用程序的特定于平台的技术。此类操作系统的示例包括 Android、iOS 或 Windows。使用这些语言构建的本机应用程序往往会提供更好的性能和用户体验。开发人员对 Apple 应用程序使用 Swift 和 Objective-C，对原生 Android 应用程序使用 Java 和 Kotlin。

优点：

• 
  

  出色的性能

  
  

这些编程语言直接与平台的底层资源交互。有了这个，开发人员可以充分利用系统的图形元素、计算功能或其他组件来构建快速执行的应用程序。 

• 
  

  易于扩展  

  
  

在扩展应用程序的功能时，总会有遇到乏味问题的风险。本机代码减少了出现此问题的可能性。它们受 iOS 和 Android IDE 以及 SDK 工具包的支持。利用这一优势，您可以为每个平台实施基本、高级甚至最新的功能，而无需担心兼容性问题。  

• 
  

  更容易使用

  
  

根据2021 年 Stack Overflow 开发人员调查，Swift 在其他 38 种编程语言中排名第 8。在类似的列表中，React Native 是 13 个框架中的第 9 个选择。Java 在最常用的语言中排名第 5。React Native 在 13 个最常用的框架中排名第 6。这表明这两个原生代码更易于使用和学习。使用它们来构建应用程序可以减轻中级和有经验的开发人员可能遇到的复杂性。

缺点

• 
  

  开发成本高

  
  

Native 主要基于“一个产品，两个应用程序”的概念。因此，它可能会很昂贵，因为您需要两个对 iOS 和 Android 本机代码具有广泛知识的专业开发团队。

• 
  

  耗时

  
  

Android 和 iOS 应用程序需要不同的代码库，这使得跨平台重用代码变得不可能。相反，每个产品都需要单独构建、测试、更新和管理。对于时间敏感的项目，这种缓慢的开发和部署过程是一个主要缺点。 

• 
  

  稀缺人才库

  
  

尽管 Java 甚至在本机应用程序开发之外也被广泛采用，但该类别中的其他语言则相反。Stack Overflow 发现，Swift 和 Kotlin 分别被 5.1% 和 8.32% 的开发人员使用。或许，这可能归功于这些编程语言的年轻化。Objective-C 以 2.8% 位居榜首。但 React Native 遥遥领先，为 14.51%。因此，找到Swift 开发人员或其他对 Kotlin 和 Objective-C 具有广泛知识的编码人员可能会令人望而生畏。 

想阅读 React Native 和 Swift 之间的详细比较吗？阅读这篇文章。

可以使用 Native Tech Stack 构建哪些应用程序/产品？

本机技术非常适合游戏应用程序、特定于操作系统的媒体播放器或其他需要完全访问设备功能的应用程序。

Flutter

Flutter 是 Google 于 2018 年创建并正式推出的一项年轻的开源技术。与 React Native 类似，Flutter 支持使用一个代码库来构建跨平台的类原生应用程序。它是用 Dart 开发的，Dart 是一种同样由 Google 提供的面向对象语言。多年来，Flutter 的受欢迎程度稳步上升，超过了其主要竞争对手 React Native。

优点

• 
  

  更快的开发

  
  

与 React Native 一样，Flutter 允许更快的开发和部署时间。您可以从一个代码构建两个应用程序（iOS 和 Android）。它的小部件和交互式资产（例如，热重载）减轻了诸如测试和调试之类的繁琐任务。此外，Dart 是 Flutter 的编程语言。它快速、简洁，并且无需额外的抽象即可编译为本机代码。这总结了通过更短的上市时间实现快速开发和竞争优势。 

• 
  

  优质的跨平台体验

  
  

Flutter 的 Material 和 Cupertino 小部件与 Apple 和 Google 的设计指南兼容。开发人员可以利用这些现成的 UI 元素在两个平台上构建具有令人印象深刻的界面的应用程序。更重要的是，Flutter 的渲染引擎 Skia 允许对每个像素进行完整的管理。这反过来又确保了使用 Flutter 构建的 UI 在多个平台或操作系统版本上启动时保持一致。

• 
  

  轻松调试

  
  

使用热重载，无需重新启动整个应用程序即可查看更改。相反，Flutter 开发人员可以进行和查看实时更改，而无需在此之后重新编译代码。只需为两个平台构建一个应用程序这一事实确保检测到和修复的任何错误都将反映在两个版本中。

• 
  

  低成本

  
  

就像使用 React Native 一样，使用 Flutter 开发应用程序的成本低于使用原生应用程序。这是因为您可以使用小型开发团队在更短的时间内为 iOS 和 Android 构建一个应用程序。  

缺点

• 
  

  重量级应用

  
  

使用 Flutter 构建的应用程序文件很大。这些应用程序可能加载缓慢并占用空间和电池性能。为了扩大规模，开发人员可能经常使用较少的包和库，从而在某些功能上妥协。结果是质量低劣的产品。 

• 
  

  技术不成熟

  
  

作为一个年轻的框架，Flutter 还没有广泛的资源基础。这意味着您可能找不到开发所需的第三方库和包。Flutter 不成熟的另一个缺点是它的增长潜力。未来不太有利的变化可能会给框架带来一些复杂性，使其更难管理。鉴于谷歌终止项目的历史，Flutter 也有可能不会持续下去。  

• 
  

  对 iOS 功能的支持不佳

  
  

Flutter 允许快速、无缝地开发 Android 应用程序。但 iOS 的情况并非如此。访问平台的本机组件可能会出现问题。这使得几乎不可能实现特殊的 iOS 功能，例如引导访问或默认页面转换等简单功能。 

想阅读 React Native 和 Flutter 的详细比较吗？阅读这篇文章。

Flutter 可以构建哪些应用/产品？

您可以使用 Flutter 开发需要快速或实时访问的产品。它包括客户服务、金融服务提供商、电子商务公司或任何接受当面付款的商家的应用程序。

Xamarin

另一种常见的 React Native 替代方案是 Xamarin。它是微软提供的跨平台技术。它始于 2011 年的 MonoTouch 和 Mono for Android，直到微软于 2016 年收购它。 Xamarin 使用 C# 语言和 .NET 框架来开发 iOS、Android 和 Windows 移动应用程序。 

优点

• 
  

  快速发展

  
  

借助 Xamarin 的一种产品、一种技术堆栈方法，开发人员可以跨平台重用多达 90% 的代码。您无需在开发环境之间切换，因为您可以在 Visual Studio 中构建 Xamarin 应用程序。更重要的是，该框架允许访问所有支持平台上的公共资源。总而言之，开发时间更短，成本更低。 

• 
  

  灵活的

  
  

Xamarin 的组件存储使开发人员可以访问跨平台的标准化 UI 控件、集成的开源库和第三方服务。借助这些广泛的资源，您可以选择多个元素或在您的应用中实现所需的功能。 

• 
  

  出色的性能

  
  

Xamarin.Essentials 库提供对本机组件的访问。程序员可以使用 Xamarin.iOS 和 Xamarin.Android 分别构建 iOS 和 Android 应用程序。这些导致产品在性能上接近本机应用程序。React Native 在这方面并不接近。您还可以在运行时将应用程序的 UI 转换为原生元素，以确保接近原生的设计和性能。

• 
  

  易于扩展

  
  

调试和维护更容易，因为开发人员可以从一个源代码跨平台发现和更改。此外，Xamarin 与其支持平台的 SDK 和 API 集成。一旦更改可用，这使得在 iOS 和 Android 应用程序中更新或实施新功能变得容易。  

• 
  

  广泛的技术支持

  
  

Microsoft 提供学习资源和综合解决方案，使开发人员能够测试、监控和保护他们的应用程序。它包括 Azure 云、Xamarin Insights 和 Xamarin TestCloud。

缺点

• 
  

  不适合图形繁重的应用程序 

  
  

在 Xamarin 中，开发人员主要可以共享业务逻辑而不是 UI 代码。这只是意味着您需要为每个平台构建一个单独的 UI。考虑到这一点，构建需要复杂动画或大量交互 UI 的游戏应用程序或其他产品会更慢且乏味。 

• 
  

  有限的社区 

  
  

在最近的 Stack Overflow 开发人员调查中，只有 5.8% 的受访者使用 Xamarin。因此，可能很难聘请具有丰富经验和知识的Xamarin 开发人员。但是，随着框架的不断发展，这种劣势可能不会持续很长时间。如果您有紧急需求，请联系我们，让您与经过预先审查的 Xamarin 专家联系。 

• 
  

  昂贵的许可证

  
  

Xamarin 加快了开发时间，降低了成本。但是，考虑到其 IDE（Microsoft Visual Studio）的价格，这种优势可能不那么令人印象深刻。对于商业项目，Enterprise 和 Professional 许可证是理想的选择。Enterprise 第一年的年度定价为每位用户 5,999 美元，然后续订 2,569 美元。首次专业订阅者将在以后支付 1,999 美元和 799 美元。 

• 
  

  固有限制

  
  

尽管 Xamarin 是为原生应用开发量身定制的，但它并不是纯粹的原生应用。因此，它有几个限制。这包括对开源库的限制访问、更新或集成特定于平台的新 API 的延迟以及更大的应用程序大小。 

可以使用 Xamarin 构建哪些应用程序/产品？

Xamarin 在具有繁重逻辑或简单 UI 的应用程序上表现良好。它包括用于调查、项目管理、旅行、杂货或跟踪的应用程序。 

NativeScript

与 React Native 类似，该框架使用 JavaScript 为 iOS 和 Android 构建跨平台移动应用程序。它还支持 TypeScript、Angular 和相关框架。使用 NativeScript 构建的应用程序会生成完全原生的应用程序。 

优点

• 
  

  原生功能

  
  

NativeScript 将 iOS 和 Android API 注入到 JS 虚拟机中，以便更容易地与原生资源集成。这使开发人员可以快速访问插件、Android SDK、iOS 依赖项管理器——Cocoapods 和其他相关技术，以构建具有本机性能的应用程序。它还带来了直观的用户界面和更好的用户体验。

• 
  

  更广泛的开发人才

  
  

NativeScript 使用 JS 和 CSS 的一个子集，它们都是成熟的。对这些技术有一定了解的开发人员可以更快地构建本机应用程序。此外，这个 NativeScript 支持各种 JS 框架，例如 Angular、Vue.js 或 TypeScript。 

• 
  

  更少的开发时间

  
  

使用 NativeScript 构建时，开发人员可以在模拟器屏幕上实时查看代码更改。因此，此后您无需重新编译应用程序。再加上 NativeScript 中的单一代码库方法，这意味着每次修改都可以应用于其他平台。因此，该框架提高了开发速度。 

缺点

• 
  

  本土专业知识

  
  

根据您的项目范围，您可能需要实现高级本机功能。这需要在特定于平台的 UI 标记和元素方面具有专业知识的软件顾问。

• 
  

  插件质量不确定

  
  

虽然 NativeScript 上有几个免费插件，但并不是全部都经过验证。这使开发人员面临使用有问题的开源插件的风险，这些插件可能会导致严重的瓶颈或更糟糕的最终产品。

• 
  

  比本机更大的应用程序大小

  
  

无论 NativeScript 应用程序与真正的 Native 多么接近，它们的大小都相对较大。NativeScript 上空白 android 项目的默认大小为 12MB。但这仍然低于 React Native 的默认 APK 大小，它可以高达 23MB 

可以使用 NativeScript 构建哪些应用程序/产品？

NativeScript 最适合需要利用硬件组件功能的实时应用程序或产品。它包括用于流媒体、实时馈送和简单游戏的应用程序。 

Ionic

Ionic 是一种 React Native 替代方案，可让您构建跨平台应用程序。这个开源 SDK 最初是基于 Apache Cordova 和 AngularJS 构建的。但后来，它增加了对 React、Vue.js 和 Angular 等其他 JS 框架的支持。 

优点

• 
  

  原生功能

  
  

使用 Apache Cordova 和 Capacitor 插件，Ionic 可以访问移动操作系统的相机、蓝牙、麦克风、指纹扫描仪、GPS 等功能。此外，Ionic 的 UI 组件及其内置的自适应样式通过对设计进行轻微更改来确保应用程序保持原生的感觉。 

• 
  

  跨平台体验

  
  

Ionic 利用网络标准和通用 API 为任何平台构建应用程序。有了这个，开发人员可以构建一个应用程序，然后使用一个代码库将它定制到所有支持的平台。 

• 
  

  更短的开发时间

  
  

使用 Ionic 的预构建功能，无需为每个开发构建 UI 组件。相反，开发人员可以重用或自定义每个元素，在更短的时间内构建功能性应用程序。 

缺点

• 
  

  不适合游戏应用

  
  

与大多数跨平台框架一样，Ionic 可能不适合具有高级图形的应用程序。这是因为 Ionic 使用 CSS，这在开发 3D 游戏应用程序时受到限制。在这种情况下，本地化可能是最好的选择。 

• 
  

  兼容性问题

  
  

集成的本机插件可能会相互冲突，从而产生大大减慢开发过程的问题。 

• 
  

  安全问题

  
  

开发跨平台意味着您需要同时考虑 Web 和本机移动应用程序的安全性。尽管现有解决方案可以解决此问题，但对于需要高端安全性的应用程序而言，这可能既乏味又昂贵。 

想要阅读 React Native 和 Ionic 之间的详细比较吗？阅读这篇文章

可以使用 Ionic 构建哪些应用程序/产品？

Ionic 可用于需要即时信息或类似本机功能的应用程序。这包括用于新闻、生活方式、流媒体和金融服务的应用程序。 

Apache Cordova

Apache Cordova 由 Nitobi 创建，于 2011 年被 Adobe 收购，并更名为 PhoneGap。随后，它作为 PhoneGap 的开源版本发布。Apache Cordova 使开发人员能够使用 HTML、CSS 和 JavaScript 构建移动应用程序。可以通过命令行界面 (CLI) 使用此 React Native 替代方案开发跨平台应用程序。对于接近本机的应用程序，您可以使用 Cordova 以平台为中心的工作流程。 

优点

• 
  

  丰富的插件集

  
  

开发人员在使用 Apache Cordova 进行构建时有大量插件可供选择。这些插件提供对本机设备 API 的访问，从而更轻松地在应用程序中实现广泛的功能，以获得更好的性能和用户体验。 

• 
  

  无障碍技能集

  
  

Cordova 使用的标准技术 JS、CSS 和 HTML 已经成熟。具有这些技术编程背景的移动开发人员可以快速适应构建 Apache Cordova 应用程序。易于找到开发人员、温和的学习曲线和快速的上市时间潜力是直接的好处。

• 
  

  跨平台支持

  
  

本着“一次编写，随处运行”的原则，代码可以跨平台重用。这确保了应用程序可以适应任何平台的UI。此外，无需将特定于平台的编程语言作为一个代码库来学习可以胜任。

缺点

• 
  

  特定于平台的限制

  
  

因为 Apache Cordova 应用程序不是纯原生的，它们依赖插件来利用设备的功能。这些第三方自定义插件可能不容易获得、更新或跨平台兼容。 

• 
  

  可能需要本地开发人员

  
  

如前所述，使用 Cordova 构建的应用程序可能会遇到某些插件的兼容性问题。您可能需要可以从头开始编写自定义插件的专业本机开发人员。这转化为延长的开发时间和成本。 

• 
  

  潜在的性能问题

  
  

使用 Cordova 的默认功能构建高性能应用程序可能很困难。这是因为其技术中存在的限制会减慢应用程序的速度。此类缺点在于其 WebView 和移动浏览器组件以及 JavaScript 中缺乏多线程功能。

可以使用 Apache Cordova 构建哪些应用程序/产品？

您可以使用 Cordova 开发结合本机组件和 WebView 以访问设备 API 的应用程序。它包括用于健身、运动、跟踪和市场的应用程序。 

Framework 7

Framework 7 是您应该考虑的另一个 React Native 替代方案。它是一个开源 HTML 框架，用于构建具有近乎本机功能的混合 Web 和移动应用程序。Framework 7 兼容 Android 和 iOS 平台。

优点

• 
  

  反应灵敏

  
  

从基本元素到高级元素，Framework 7 具有广泛的 UI 组件。开发人员可以访问诸如延迟加载、无限滚动、复选框列表等控件。使用这些资源构建具有干净、本机界面的动态应用程序。

• 
  

  多框架支持

  
  

Framework 7 可以与 Angular、React 和 Vue.js 等 JS 框架一起使用。这些结构为开发过程贡献了它们的力量和简单性

• 
  

  对开发者友好

  
  

开发人员不仅限于自定义标签。在使用 Framework 7 时，他们可以轻松地使用由 JS 和 CSS 补充的纯 HTML 代码。这意味着至少具有这些语言甚至 jQuery 中级知识的程序员可以扩展。 

缺点

• 
  

  有限的平台支持

  
  

目前，Framework 7 仅支持 iOS 和 Android 平台。希望为其他平台开发应用程序的开发人员可能会评估其他框架。

• 
  

  iOS 专用

  
  

Framework 7 最初是为 Apple 环境开发的。这开辟了在为 Android 开发时遇到渲染问题的可能性。

• 
  

  最少的文档

  
  

用户可以轻松找到有关如何在此框架中实现任何元素集的资源。然而，大多数高级需求可能没有现成的答案，因为文档不像其他框架那样广泛。  

Framework 7 可以构建哪些应用程序/产品？

Framework 7 可用于构建依赖于设备硬件的渐进式 Web 应用程序或 iOS 和 Android 应用程序。 

jQuery Mobile

jQuery Mobile 是一个开源 JavaScript 库，用于开发跨平台移动应用程序和网站。它利用了 jQuery 的特性，jQuery 以实现动画、AJAX 和文档对象模型 (DOM) 操作的简便性和快速性而闻名。  

优点

• 
  

  较低的学习曲线

  
  

这项技术建立在 jQuery Core 之上，大多数程序员可能已经在过去使用过它。这使得它更容易学习和使用。

• 
  

  跨平台、跨浏览器兼容性

  
  

使用 jQuery Mobile 框架，您可以构建与流行的桌面浏览器和平台兼容的高度响应的应用程序和网站。其支持的平台包括 iOS、Android、Windows、WebOS 和 Blackberry。 

• 
  

  出色的动画页面过渡效果

  
  

基于渐进式增强原理，jQuery Mobile 导航系统允许页面通过 Ajax 加载到 DOM。这确保了页面得到改进，然后以高质量的过渡显示。

• 
  

  简单方便

  
  

开发人员只需几行代码即可处理 HTML 事件、AJAX 请求和 DOM 操作。这在 JavaScript 中需要更长的行。 

• 
  

  轻量级

  
  

由于其有限的图像依赖性，jQuery Mobile 的最小大小为 40 KB。这有助于它的速度。 

缺点

• 
  

  最小主题

  
  

jQuery 移动版中可用的 CSS 主题使自定义应用程序变得容易。然而，它们是有限的。开发人员可能会构建与使用此技术构建的其他产品不同的应用程序。

• 
  

  使用其他框架非常耗时

  
  

jQuery Mobile 与 PhoneGap 等其他移动应用程序框架相结合，以获得更好的性能。但这会减慢开发过程。 

• 
  

  移动设备运行速度较慢

  
  

即使在最新的 iOS 和 Android 平台上，这项技术也明显变慢。如果您希望开发一个快速的移动应用程序，您可能需要考虑其他替代方案。

可以使用 jQuery Mobile 构建哪些应用程序/产品？

jQuery Mobile 是针对旧浏览器、内容管理系统或其他需要一些动画和较少用户交互的产品的应用程序的理想选择。 

PhoneGap

渐进式 Web 应用程序 (PWA)

渐进式 Web 应用程序是应用程序软件，可以像常规网站一样在 Web 浏览器上加载和执行。它结合了 Web 功能和本机应用程序的功能（例如推送通知和对硬件功能的访问），以提供出色的用户体验。与传统应用程序不同，PWA 无法从应用程序商店安装到设备中。相反，它可以添加为用户的主屏幕。渐进式 Web 应用程序使用 HTML、JavaScript 和 CSS 等标准 Web 技术构建。 

优点：

• 
  

  反应灵敏

  
  

PWA 可以轻松适应多种设备的屏幕尺寸，无论是平板电脑、台式机、Android 和 iOS 移动设备，还是其他直接尺寸。 

• 
  

  安全的

  
  

利用 HTTPS，在 PWA 上广播的信息被加密。在大多数情况下，如果没有安全连接，用户将无法访问某些功能，例如地理定位。这提供了高端安全性和针对路径攻击或其他网络威胁的更多保护。 

• 
  

  极具吸引力的用户体验

  
  

PWA 是使用渐进改进原则构建的。这些应用程序在符合标准的浏览器上提供更好的用户体验，在不符合标准的浏览器上至少提供可接受的界面。此外，这些应用程序通过现代网络标准提供本机应用程序功能和感觉。这些功能进一步丰富了移动体验。 

• 
  

  减少对网络的依赖

  
  

构建渐进式 Web 应用程序的最大优势之一是它们能够在连接速度缓慢的情况下运行。如果用户访问过某个站点，即使没有网络，他们也可以访问该内容。这可以通过 Service Workers、缓存 API 和离线存储站点资产的客户端存储技术实现。也就是说，PWA 利用这一点来享受更快的加载速度。 

• 
  

  易于访问和维护

  
  

作为一个基于网络的应用程序，PWA 享有更高的知名度，因为它可以被搜索引擎发现和排名，给他们更多的知名度。此外，用户无需额外安装即可轻松进行测试和升级，因为这些应用程序可以在线访问。 

缺点

• 
  

  对硬件组件的访问受限

  
  

虽然它可以访问相当多的功能，但 PWA 无法完全使用设备的大量硬件组件。对高级相机控制、通话功能、蓝牙的支持，并且某些功能在某些设备中仍然不发达。

• 
  

  弱 iOS 支持

  
  

iOS 设备中 PWA 的一个常见缺点是缺乏推送通知支持。这使得无法通过新内容或更新重新吸引 iOS 用户，从而导致转化次数减少。 

• 
  

  没有可靠的第三方控制

  
  

因为 PWA 不能从应用商店下载，所以没有监管标准。因此，其大多数类本机应用程序的 UI 质量可能不一致。 

哪些应用程序/产品可以构建为渐进式 Web 应用程序？

PWA 最适用于由于网络缓慢而易于失败的软件、需要更高流量的应用程序或很少使用的应用程序。它包括为电子商务公司、叫车服务、市场代理等提供的产品。

Bootstrap

Bootstrap 是一个结合了 Javascript、CSS 和 HTML 的工具包。它广泛用于开发响应式、移动优先的网页和完全嵌入浏览器的渐进式 Web 应用程序 (PWA)。 

什么是 PWA？

渐进式 Web 应用程序是应用程序软件，可以像常规网站一样在 Web 浏览器上加载和执行。它结合了 Web 功能和本机应用程序的功能（例如推送通知和对硬件功能的访问），以提供出色的用户体验。与传统应用程序不同，PWA 无法从应用程序商店安装到设备中。相反，它可以添加为用户的主屏幕。 

优点

• 
  

  高度响应

  
  

Bootstrap 的流体网格系统是其主要优势之一。它具有定义明确的类和各种简单的布局。一旦实施，它将在所有平台上提供一致的外观。这些组件也可以定制以匹配每个项目的设计。 

• 
  

  广泛的文档

  
  

Bootstrap被称为“世界上最流行的 HTML、CSS 和 JS 库”，拥有丰富的文档。考虑到这一点，移动开发人员很可能会为此框架找到基本和高级问题的解决方案。 

• 
  

  对jQuery插件的内置支持

  
  

通过这些内置插件，Bootstrap 可以从 JS API 访问更多 UI 组件。工具提示和对话框等界面也可以提高预先存在的界面的性能。 

• 
  

  安稳

  
  

Bootstrap 的 PWA 通过 HTTPS 广播信息。在大多数情况下，如果没有安全连接，用户将无法访问某些功能，例如地理定位。这提供了针对大多数网络威胁的高端安全性和更多保护。

缺点

• 
  

  设备功能有限

  
  

在默认模式下使用 Bootstrap 可以将几个未使用的元素和代码加载到您的项目中。这会转化为较大的应用程序大小和缓慢的加载时间。

• 
  

  其他自定义设置

  
  

使用此框架构建需要智能手机广泛功能的 Web 应用程序并不是一个好的选择。原因是用 JS 和 Bootstrap 编写的 Web 应用程序无法完全访问设备的传感器和功能。

• 
  

  可能对开发人员不友好

  
  

使用 Bootstrap 默认组件开发的 Web 应用看起来很相似。要自定义应用程序，您需要手动覆盖样式表。这个额外的步骤通常会破坏使用这个框架的目的。 

• 
  

  可能对开发人员不友好

  
  

某些任务（例如访问预定义的类或自定义）可能需要更长的时间来学习。 

可以使用 Bootstrap 构建哪些应用程序/产品？

Bootstrap 主要用于设计响应式网页和网络应用程序。 

最后

在竞争激烈的移动应用程序开发世界中，错过跨多个平台构建应用程序是一个很大的风险。选择正确的替代方案可以帮助您在重要的平台上保持存在感，同时降低开发成本。

这是我参与11月更文挑战的第29天，活动详情查看：2021最后一次更文挑战。

引言

贴牌生产（英语：Original Equipment Manufacturer, OEM）

因采购方可提供品牌和授权，允许制造方生产贴有该品牌的产品，所以俗称“贴牌生产”。

需求背景： SAAS平台级应用系统为一个特大商户，提供专属OEM项目，在原有通用app的基础上进行定制化开发

例如去掉开屏广告，删除部分模块，保留核心模块。更换专属app icon以及主题色

I 上架资料

1. 用户协议及隐私政策
2. App版本、 审核测试账号信息
3. icon、名称、套装 ID（bundle identifier）
4. 关键词：
5. app描述：
6. 技术支持网址使用：

kunnan.blog.csdn.net/article/det…

II 开发小细节

1. 更换基础配置信息，比如消息推送证书、第三方SDK的ApiKey、启动图、用户协议及隐私政策。
2. 接口修改：比如登录接口新增SysId请求字段用于区分新旧版、修改域名（备案信息）
3. 废弃开屏广告pod 'GDTMobSDK' ,'4.13.26'

1.1 更换高德定位SDK的apiKey

    NSString *AMapKey = @"";

    [AMapServices sharedServices].apiKey = AMapKey;

1.2 更新消息推送证书和极光的appKey

1. Mac 上的“钥匙串访问”创建证书签名请求 (CSR)

a. 启动位于 /Applications/Utilities 中的“钥匙串访问”。

b. 选取“钥匙串访问”>“证书助理”>“从证书颁发机构请求证书”。

c. 在“证书助理”对话框中，在“用户电子邮件地址”栏位中输入电子邮件地址。

d. 在“常用名称”栏位中，输入密钥的名称 (例如，Gita Kumar Dev Key)。

e. 将“CA 电子邮件地址”栏位留空。

f. 选取“存储到磁盘”，然后点按“继续”。

help.apple.com/developer-a…

2. 从developer.apple.com 后台找到对应的Identifiers创建消息推送证书,并双击aps.cer安装到本地Mac，然后从钥匙串导出P12的正式上传到极光后台。

docs.jiguang.cn//jpush/clie…

3. 更换appKey（极光平台应用的唯一标识）

        [JPUSHService setupWithOption:launchOptions appKey:@""

                              channel:@"App Store"

                     apsForProduction:YES

                advertisingIdentifier:nil];

http://www.jiguang.cn/accounts/lo…

1.3 更换Bugly的APPId

    [Bugly startWithAppId:@""];//异常上报

1.4 app启动的新版本提示

更换appid

    [self checkTheVersionWithappid:@""];

检查版本

- (void)checkTheVersionWithappid:(NSString*)appid{





    [QCTNetworkHelper getWithUrl:[NSString stringWithFormat:@"http://itunes.apple.com/cn/lookup?id=%@",appid] params:nil successBlock:^(NSDictionary *result) {

        if ([[result objectForKey:@"results"] isKindOfClass:[NSArray class]]) {

            NSArray *tempArr = [result objectForKey:@"results"];

            if (tempArr.count) {

                

                

                NSString *versionStr =[[tempArr objectAtIndex:0] valueForKey:@"version"];

                NSString *appStoreVersion = [versionStr stringByReplacingOccurrencesOfString:@"." withString:@""] ;

                if (appStoreVersion.length==2) {

                    appStoreVersion  = [appStoreVersion stringByAppendingString:@"0"];

                }else if (appStoreVersion.length==1){

                    appStoreVersion  = [appStoreVersion stringByAppendingString:@"00"];

                }



                NSDictionary *infoDic=[[NSBundle mainBundle] infoDictionary];

                NSString* currentVersion = [[infoDic valueForKey:@"CFBundleShortVersionString"] stringByReplacingOccurrencesOfString:@"." withString:@""];

                

                currentVersion = [currentVersion stringByReplacingOccurrencesOfString:@"." withString:@""];

                if (currentVersion.length==2) {

                    currentVersion  = [currentVersion stringByAppendingString:@"0"];

                }else if (currentVersion.length==1){

                    currentVersion  = [currentVersion stringByAppendingString:@"00"];

                }







                NSLog(@"currentVersion: %@",currentVersion);

                

                

                if([self compareVesionWithServerVersion:versionStr]){



                

                    

                    UIAlertController *alertController = [UIAlertController alertControllerWithTitle:[NSString stringWithFormat:@"%@%@",QCTLocal(@"Discover_a_new_version"),versionStr] message:QCTLocal(@"Whethertoupdate") preferredStyle:UIAlertControllerStyleAlert];

                    //                "Illtalkaboutitlater"= "稍后再说";

                    //                "Update now" = "立即去更新";

                    //                "Unupdate"= "取消更新";



                    [alertController addAction:[UIAlertAction actionWithTitle:QCTLocal(@"Illtalkaboutitlater") style:UIAlertActionStyleCancel handler:^(UIAlertAction * _Nonnull action) {

                        NSLog(@"取消更新");

                    }]];

                    [alertController addAction:[UIAlertAction actionWithTitle:QCTLocal(@"Updatenow") style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {

                        NSURL *url = [NSURL URLWithString:[NSString stringWithFormat:@"itms-apps://itunes.apple.com/app/id%@",appid]];

                        if (@available(iOS 10.0, *)) {

                            [[UIApplication sharedApplication] openURL:url options:@{} completionHandler:^(BOOL success) {

                            }];

                        } else {

                            // Fallback on earlier vesions

                            [[UIApplication sharedApplication] openURL:url];

                        }

                    }]];

                    [[QCT_Common getCurrentVC] presentViewController:alertController animated:YES completion:nil];

                }

            }

        }

    } failureBlock:^(NSError *error) {

        NSLog(@"检查版本错误: %@",error);

    }];

}

see also

更多内容请关注 #小程序：iOS逆向,只为你呈现有价值的信息，专注于移动端技术研究领域；更多服务和咨询请关注#公众号：iOS逆向。

链接：https://juejin.cn/post/7035926626366029837

引入

在学习本文之前我们应该了解

• objc_msgsend消息快速查找（上） 
• objc_msgsend（中）消息慢速查找 

当快速消息查找和消息慢速查找都也找不到imp时，苹果系统后续是怎么处理的我们一起来学习！ 方法动态决议主要做了哪些事情？

准备工作

• objc4-818.2 源码

resolveMethod_locked动态方法决议

• 赋值imp = forward_imp

• 做了个单例判断动态控制执行流程根据behavior方法只执行一次。

对象方法的动态决议

类方法的动态决议

lookUpImpOrForwardTryCache

cache_getImp

• 苹果给与一次动态方法决议的机会来挽救APP
• 如果是类请用resolveInstanceMethod
• 如果是元类请用resolveClassMethod

如果都没有处理那么imp = forward_imp ，const IMP forward_imp = (IMP)_objc_msgForward_impcache;

_objc_msgForward_impcache探究

• __objc_forward_handler主要看这个函数处理

__objc_forward_handler

代码案例分析

   int main(int argc, const char * argv[]) {

    @autoreleasepool {

        LGTeacher *p = [LGTeacher alloc];

        [t sayHappy];

        [LGTeacher saygood];

    }

    return 0;

}

   

崩溃信息

2021-11-28 22:36:39.223567+0800 KCObjcBuild[12626:762145] +[LGTeacher sayHappy]: unrecognized selector sent to class 0x100008310



2021-11-28 22:36:39.226012+0800 KCObjcBuild[12626:762145] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[LGTeacher sayHappy]: unrecognized selector sent to class 0x100008310'



复制代码

动态方法决议处理对象方法找不到

代码动态决议处理imp修复崩溃

@implementation LGTeacher



-(void)text{

    NSLog(@"%s", __func__ );

}



+(void)say777{



    NSLog(@"%s", __func__ );

}



// 对象方法动态决议



+(BOOL**)resolveInstanceMethod:(SEL)sel{



    if (sel == @selector(sayHappy)) {



        IMP imp =class_getMethodImplementation(self, @selector(text));

        Method m = class_getInstanceMethod(self, @selector(text));

        const char * type = method_getTypeEncoding(m);

        return** class_addMethod(self, sel, imp, type);

    }

    return [super resolveInstanceMethod:sel];



}



//类方法动态决议



+ (BOOL)resolveClassMethod:(SEL)sel{

    if (sel == @selector(saygood)) {

        IMP  imp7 = class_getMethodImplementation(objc_getMetaClass("LGTeacher"), @selector(say777));

        Method m  = class_getInstanceMethod(objc_getMetaClass("LGTeacher"), @selector(say777));

        const char type = method_getTypeEncoding(m);

        return class_addMethod(objc_getMetaClass("LGTeacher"), sel, imp7, type);

    }



    return [super resolveClassMethod:sel];



}



@end

运行打印信息

2021-11-29 16:30:46.403671+0800 KCObjcBuild[27071:213498] -[LGTeacher text]



2021-11-29 16:30:46.404186+0800 KCObjcBuild[27071:213498] +[LGTeacher say777]

• 找不到imp我们动态添加一个imp ，但这样处理太麻烦了。
• 实例方法方法查找流程 类->父类->NSObject->nil
• 类方法查找流程 元类->父类->根元类-NsObject->nil

最终都会找到NSobject.我们可以在NSObject统一处理 所以我们可以给NSObject创建个分类

@implementation NSObject (Xu)

+(BOOL)resolveInstanceMethod:(SEL)sel{

    if (@selector(sayHello) == sel) {

       NSLog(@"--进入%@--",NSStringFromSelector(sel));

       IMP imp = class_getMethodImplementation(self , @selector(sayHello2));

       Method meth = class_getInstanceMethod(self , @selector(sayHello2));

       const char * type = method_getTypeEncoding(meth);

       return  class_addMethod(self ,sel, imp, type);;

          

    }else if (@selector(test) == sel){

       NSLog(@"--进入%@--",NSStringFromSelector(sel));

       IMP imp = class_getMethodImplementation(object_getClass([self class]), @selector(newTest));

        Method meth = class_getClassMethod(object_getClass([self class]) , @selector(newTest));

       const char * type = method_getTypeEncoding(meth);

       return  class_addMethod(object_getClass([self class]) ,sel, imp, type);;

    }

    return NO;

}



- (void)sayHello2{

     NSLog(@"--%s---",__func__);

}



+(void)newTest{

    NSLog(@"--%s---",__func__);

}



@end

实例方法是类方法调用，系统都自动调用了resolveInstanceMethod方法，和上面探究的吻合。 动态方法决议优点

• 可以统一处理方法崩溃的问题，出现方法崩溃可以上报服务器，或者跳转到首页
• 如果项目中是不同的模块你可以根据命名不同，进行业务的区别
• 这种方式叫切面编程熟成AOP

方法动态决议流程图

问题

• resolveInstanceMethod为什么调用两次？
• 统一处理方案怎么处理判断问题，可能是对象方法崩溃也可能是类方法崩溃，怎么处理？
• 动态方法决议后苹果后续就没有处理了吗？

「这是我参与11月更文挑战的第28天，活动详情查看：2021最后一次更文挑战」

关于Storyboard

Storyboard 是最先在 iOS5 中引入的一项新特性，它的出现使得开发人员大幅缩减构建App用户界面所需的时间

关于Storyboard的加载方式

• 一般在新建工程后，我们便可以看到Xcode会默认加载 Storyboard，但是在实际开发中，我们更常用的是自己新建 Storyboard，所以，这里主要讲手动创建控制器时，加载 Storyboard 的方式

• 通常在新建的项目中，我们首先要将Xcode加载 Storyboard 去掉

  

• 关于 Storyboard 创建控制器

  第一种：

  

  self.window = [[UIWindow alloc]initWithFrame:[UIScreen mainScreen].bounds];
  
  UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
  
  UIViewController *vc = [sb instantiateInitialViewController];
  
  self.window.rootViewController = vc;
  
  [self.window makeKeyAndVisible];
  
  
  

  第二种：

  

  self.window = [[UIWindow alloc]initWithFrame:[UIScreen mainScreen].bounds];
  
  UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
  
  UIViewController *vc = [sb instantiateViewControllerWithIdentifier:@"WAKAKA"];
  
  self.window.rootViewController = vc;
  
  [self.window makeKeyAndVisible];
  
  
  

关于UIStoryboardSegue

在 Storyboard 中，用来描述界面跳转的线，都属于 UIStoryboardSegue 的对象（简称：Segue）

Segue的属性

• 唯一标识（identifier）
• 来源控制器（sourceViewController）
• 目标控制器（destinationViewController）

Segue的类型

• 自动型（点击某控件，不需要进行某些判断可直接跳转的）

  

• 手动型（点击某控件，需要进行某些判断才跳转的） 

• 手动设置 Segue 需要设置

  

  使用 perform 方法执行对应的 Segue

  //根据Identifier去storyboard中找到对应的线，之后建立一个storyboard的对象
  
              [self performSegueWithIdentifier:@"showinfo" sender:nil];
  
  
  

  如果需要做传值或跳转到不同的UI，需要在这个方法里代码实现

  - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender{
  
      //比较唯一标识
  
      if ([segue.identifier isEqualToString:@"showInfo"]) {
  
          //来源控制器
  
          UINavigationController *nvc = segue.sourceViewController;
  
          //目的控制器
  
          ListViewController *vc = segue.destinationViewController;
  
          vc.info = @"show";
  
      }
  
  }
  
  
  
  链接：https://juejin.cn/post/7035408728509644814

这是我参与11月更文挑战的第28天，活动详情查看：2021最后一次更文挑战。

引言

例子：按照比例显示图片全部内容，并自动适应高度

I 图片的平铺和拉伸

#import "UIImage+ResizableImage.h"



@implementation UIImage (ResizableImage)





+ (UIImage*)resizableImageWithName:(NSString *)name {

    NSLog(@"%s--%@",__func__,name);

    UIImage *image = [UIImage imageNamed:name];

    //裁剪图片方式一：

    //Creates and returns a new image object with the specified cap values.

    /*right cap is calculated as width - leftCapWidth - 1

     bottom cap is calculated as height - topCapWidth - 1

     */

    return [image stretchableImageWithLeftCapWidth:image.size.width*0.5 topCapHeight:image.size.height*0.5];

    //方式二：

    //    CGFloat top = image.size.width*0.5f-1;

    //    CGFloat left = image.size.height*0.5f-1;

    //    UIEdgeInsets insets = UIEdgeInsetsMake(top, left, top, left);

    //    UIImage *capImage = [image resizableImageWithCapInsets:insets resizingMode:UIImageResizingModeTile];

    //

}









/**

 CGFloat top = 0; // 顶端盖高度

 CGFloat bottom = 0 ; // 底端盖高度

 CGFloat left = 0; // 左端盖宽度

 CGFloat right = 0; // 右端盖宽度

 

 //    UIImageResizingModeStretch：拉伸模式，通过拉伸UIEdgeInsets指定的矩形区域来填充图片

 //    UIImageResizingModeTile：平铺模式，通过重复显示UIEdgeInsets指定的矩形区域来填充图片

 



 @param img <#img description#>

 @param top <#top description#>

 @param left <#left description#>

 @param bottom <#bottom description#>

 @param right <#right description#>

 @return <#return value description#>

 */

- (UIImage *) resizeImage:(UIImage *) img WithTop:(CGFloat) top WithLeft:(CGFloat) left WithBottom:(CGFloat) bottom WithRight:(CGFloat) right

{

    UIImage * resizeImg = [img resizableImageWithCapInsets:UIEdgeInsetsMake(self.size.height * top, self.size.width * left, self.size.height * bottom, self.size.width * right) resizingMode:UIImageResizingModeStretch];

    

    return resizeImg;

}







//返回一个可拉伸的图片

- (UIImage *)resizeWithImageName:(NSString *)name

{

    UIImage *normal = [UIImage imageNamed:name];

    

    //    CGFloat w = normal.size.width * 0.5f ;

    //    CGFloat h = normal.size.height *0.5f ;

    

    CGFloat w = normal.size.width*0.8;

    CGFloat h = normal.size.height*0.8;

    //传入上下左右不需要拉升的编剧，只拉伸中间部分

    return [normal resizableImageWithCapInsets:UIEdgeInsetsMake(h, w, h, w)];

    

    //    [normal resizableImageWithCapInsets:UIEdgeInsetsMake(<#CGFloat top#>, <#CGFloat left#>, <#CGFloat bottom#>, <#CGFloat right#>)]

    

    // 1 = width - leftCapWidth  - right

    // 1 = height - topCapHeight  - bottom

    

    //传入上下左右不需要拉升的编剧，只拉伸中间部分，并且传入模式（平铺/拉伸）

    //    [normal :<#(UIEdgeInsets)#> resizingMode:<#(UIImageResizingMode)#>]

    

    //只用传入左边和顶部不需要拉伸的位置，系统会算出右边和底部不需要拉升的位置。并且中间有1X1的点用于拉伸或者平铺

    // 1 = width - leftCapWidth  - right

    // 1 = height - topCapHeight  - bottom

    //    return [normal stretchableImageWithLeftCapWidth:w topCapHeight:h];

}









@end

II 图片的加载方式

优先选择3x图像，而不是2x图像时使用initWithContentsOfFile

 NSString *path = [[NSBundle mainBundle] pathForResource:@"smallcat" ofType:@"png"];

 UIImage *image = [[UIImage alloc]initWithContentsOfFile:path];

 // 在ipone5 s、iphone6和iphone6 plus都是优先加载@3x的图片，如果没有@3x的图片，就优先加载@2x的图片

• 优先加载@2x的图片
• [UIImage imageNamed:@"smallcat"]

iphone5s和iphone6优先加载@2x的图片，iphone6 plus是加载@3x的图片。

加载图片注意点：如果图片比较小，并且使用非常频繁，可以使用imageName:（eg icon），如果图片比较大，并且使用比较少，可以使用imageWithContentsOfFile:(eg 引导页 相册)。 imageName:

• 1、当对象销毁的时候，图片占用的内存不会随着一起销毁，内存由系统来管理，程序员不可控制
• 2、加载的图片，占用的内存非常大
• 3、相同的图片不会被重复加载到内存

imageWithContentsOfFile:

• 1、当对象销毁的时候，图片占用的内存会随着一起销毁
• 2、加载的图片占用的内存较小

3、相同的图片如果被多次加载就会占据多个内存空间

III 内容模式

首先了解下图片的内容模式

3.1 内容模式

• UIViewContentModeScaleToFill

拉伸图片至填充整个UIImageView，图片的显示尺寸会和imageVew的尺寸一样 。

This will scale the image inside the image view to fill the entire boundaries of the image view.

• UIViewContentModeScaleAspectFit

图片的显示尺寸不能超过imageView尺寸大小

This will make sure the image inside the image view will have the right aspect ratio and fits inside the image view’s boundaries.

• UIViewContentModeScaleAspectFill

按照图片的原来宽高比进行缩放（展示图片最中间的内容），配合使用 tmpView.layer.masksToBounds = YES;

This will makes sure the image inside the image view will have the right aspect ratio and fills the entire boundaries of the image view. For this value to work properly, make sure that you have set the clipsToBounds property of the image view to YES.

• UIViewContentModeScaleToFill : 直接拉伸图片至填充整个imageView

划重点：

1. UIViewContentModeScaleAspectFit : 按照图片的原来宽高比进行缩放(一定要看到整张图片)

使用场景：信用卡图片的展示

2. UIViewContentModeScaleAspectFill : 按照图片的原来宽高比进行缩放(只能图片最中间的内容)

引导页通常采用UIViewContentModeScaleAspectFill

 // 内容模式

 self.contentMode = UIViewContentModeScaleAspectFill;

 // 超出边框的内容都剪掉

 self.clipsToBounds = YES;

 

 

3.2 例子：商品详情页的实现

• [商品详情页（按照图片原宽高比例显示图片全部内容，并自动适应高度）

](kunnan.blog.csdn.net/article/det…)

• 背景图片的拉伸（中间空白的小矩形设置为可拉伸，保证有形状的地方不进行缩放）

- (void)awakeFromNib

 {

 [super awakeFromNib];

 // 拉伸

 //    self.backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"bg_dealcell"]];

 // 平铺

 //    self.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"bg_dealcell"]];

 

 

 [self setAutoresizingMask:UIViewAutoresizingNone];

 

 

 

 }

 

 

 

 

 - (void)drawRect:(CGRect)rect

 {

 // 平铺

 //    [[UIImage imageNamed:@"bg_dealcell"] drawAsPatternInRect:rect];

 // 拉伸

 [[UIImage imageNamed:@"bg_dealcell"] drawInRect:rect];

 }

 



 

 背景图片的拉伸（中间空白的小矩形设置为可拉伸，保证有形状的地方不进行缩放）

 UIImage *resizableImage = [image resizableImageWithCapInsets:UIEdgeInsetsMake(heightForLeftORRight, widthForTopORBottom, heightForLeftORRight, widthForTopORBottom)];

see also

只为你呈现有价值的信息，专注于移动端技术研究领域；更多服务和咨询请关注#公众号：iOS逆向。

链接：https://juejin.cn/post/7035421386168336398