掌握UITextView定制：自定义选中文本菜单和文字选择功能

技术文档

本文还有配套的精品资源，点击获取

简介：在iOS应用开发中， UITextView 用于显示和编辑多行文本。本示例将介绍如何深度定制 UITextView ，包括如何自定义选中文字后的弹出菜单以及定制文字选择功能。开发者可以重写 canPerformAction(_:withSender:) 和 performAction(_:for:with:) 方法来自定义动作，监听 selectionDidChange 通知来响应用户的选择变化，并通过 UIMenu 和 UIMenuItem 设置自定义菜单项。同时，要考虑不同设备、屏幕方向和iOS版本的兼容性问题，并可能需要集成 UIUndoManager 处理撤销和重做操作。
UITextView

1. UITextView在iOS应用中的重要性与应用

1.1 探索UITextView的角色

UITextView在iOS应用中承担着用户输入和显示大量文本信息的职责。它不仅提供了文本编辑的界面，还可以通过编程方式控制文本的属性，如字体、颜色等。尽管看似简单，UITextView却是开发者构建复杂交互式文本界面不可或缺的组件。

1.2 应用实例

在许多应用中，如日志查看器、邮件客户端以及笔记应用中，UITextView提供了基础功能来增强用户体验。例如，在笔记应用中，用户可以通过UITextView输入和编辑笔记内容，开发者则可以利用其内置的文本处理功能来实现格式化、高亮、查找和替换文本等操作。

1.3 优化UITextView

为了提升用户体验，开发者可以对UITextView进行优化，比如添加滚动条、行数显示、文本高亮等功能。要实现这些特性，需要深入了解UITextView的工作机制，并结合其提供的各种回调和属性进行扩展。通过这种方式，可以使UITextView在保持简洁性的同时，增加额外的交互价值。

2. 自定义选中文字菜单的方法

2.1 探索UITextView的默认菜单行为

2.1.1 默认行为的限制与不足

UITextView是iOS开发中常用的文本编辑视图，它提供了一系列默认的行为，例如文本选择、复制和粘贴等。然而，随着应用需求的日益增长，开发者们往往会发现这些默认行为在某些情况下可能无法完全满足特定的应用场景。比如默认菜单中的选项可能过多或不必要，或者开发者希望在菜单中添加一些应用特有的操作等。

默认菜单还可能会带来UI上的一致性问题。当使用多个UITextView时，如果每个都使用默认菜单，会导致用户在应用中遇到不同的菜单样式，这可能会影响用户体验。此外，一些默认行为可能与应用的安全策略相冲突，需要进行定制化修改。

2.1.2 如何识别默认菜单与自定义需求

识别是否需要自定义选中文字菜单，需要从应用的实际需求出发。例如，应用是否需要提供与内容相关的特定操作？是否需要将某些操作简化或移除以提升操作的简洁性？识别这些需求通常需要对应用的功能逻辑和用户交互流程有一个深入的理解。

一旦确定需要自定义菜单，接下来需要分析现有的UITextView的默认菜单行为。可以通过在Interface Builder中设置UITextView的属性，或者在代码中使用相关API来了解和尝试控制其行为。通过这一过程，可以明确哪些行为是可定制的，哪些是系统保留的，为自定义菜单的实现做准备。

2.2 实现自定义选中文字菜单的步骤

2.2.1 创建自定义菜单的思路

创建自定义菜单首先需要定义菜单项，包括它们的标题、图标以及对应的动作。这通常涉及到创建一个UITableView或者UIMenuController来展示菜单项。然后，需要监听UITextView的文本选择变化，当用户选中文字时，触发菜单的显示，并且将菜单项与对应的动作关联起来。

考虑到用户体验，自定义菜单还需要有良好的交互设计，包括动画效果、操作反馈等。同时，开发者需要处理好不同iOS版本的兼容性问题，确保自定义菜单在旧系统版本中也能正常工作。

2.2.2 实际操作中的关键代码实现

以下是一个简化版的示例代码，展示如何创建一个简单的自定义菜单并将其与UITextView关联。

import UIKitclass CustomMenuTextView: UITextView { private var menuController: UIMenuController! override init(frame: CGRect, textContainer: NSTextContainer?) { super.init(frame: frame, textContainer: textContainer) setupMenu() } required init?(coder: NSCoder) { super.init(coder: coder) setupMenu() } private func setupMenu() { // 初始化UIMenuController menuController = UIMenuController.shared menuController.menuDidHide = { [weak self] in self?.menuController.dismiss(animated: true) } } override var canBecomeFirstResponder: Bool { return true } override func将成为第一响应者() { super.将成为第一响应者() // 显示菜单 menuController.setTargetRect(self.selectedTextRange!, in: self) menuController.setMenuVisible(true, animated: true) } // 其他方法...}

在上面的代码中，我们首先重写了 init 和 canBecomeFirstResponder 方法，为 CustomMenuTextView 类添加了菜单初始化和响应者功能。接着，实现了 setupMenu 方法来初始化 UIMenuController ，并设置其 menuDidHide 回调函数。最后，我们在 将成为第一响应者 方法中配置了菜单的位置并将其显示出来。

这段代码仅作为自定义菜单实现的基础，实际应用中可能需要进一步扩展菜单项，添加额外的交互逻辑，以及处理不同iOS版本下的兼容性问题。

3. canPerformAction:withSender:方法的重写与使用

3.1 了解canPerformAction:withSender:的作用

3.1.1 方法的定义与参数解析

在iOS应用开发中， canPerformAction:withSender: 是一个非常重要的代理方法，它属于 UITextView 类。此方法允许开发者自定义哪些动作对于 UITextView 是可行的，即可以动态地控制用户对选中文本所能执行的操作。下面是对这个方法参数的详细解析：

action : 表示 NSAction 类型的动作，通常与 UIResponder 中定义的一些标准动作相关联，如 copy: 、 paste: 等。
sender : 表示发送动作的对象，在这里是 UITextView 或其子类的实例。

通过重写此方法，开发者可以返回一个布尔值来决定 UITextView 是否应该响应这个动作。如果返回 YES ，则表示动作是可执行的；如果返回 NO ，则 UITextView 会忽略这个动作。

3.1.2 如何通过重写拦截动作

在实际开发中，根据应用的具体需求，有时候需要拦截一些默认的动作，以便执行自定义的行为。通过重写 canPerformAction:withSender: 方法，我们可以实现这一点。

例如，如果我们不希望用户能够复制选中的文本，可以简单地将 copy: 动作拦截，返回 NO 。这样的拦截机制可以广泛应用于防止敏感信息的复制、阻止内容被修改等场景中。

3.2 方法重写的具体实现

3.2.1 决定动作可执行性的逻辑

重写 canPerformAction:withSender: 方法的基本逻辑是，根据传入的动作类型（ action ）来决定是否允许该动作被执行。这通常涉及到一个或多个条件判断，以及相应的逻辑处理。

以下是一个简单的代码示例，演示如何根据动作类型决定其可执行性：

- (BOOL)textView:(UITextView *)textView canPerformAction:(SEL)action withSender:(id)sender { // 自定义逻辑判断，决定动作是否可执行 if (action == @selector(copy:)) { // 例如，如果动作是复制，则不允许执行 return NO; } // 如果是其他动作，则允许执行 return YES;}

在上述代码中，我们拦截了 copy: 动作，并返回 NO ，从而禁止了复制操作。其他未指定的动作则返回 YES ，允许执行。

3.2.2 实例演示重写过程

为了更深入地理解重写 canPerformAction:withSender: 方法的过程，我们来演示一个完整的实例。假设我们需要在应用中实现一个功能，允许用户复制文本，但不允许粘贴。

- (BOOL)textView:(UITextView *)textView canPerformAction:(SEL)action withSender:(id)sender { // 允许用户复制文本 if (action == @selector(copy:)) { return YES; } // 禁止用户粘贴文本 else if (action == @selector(paste:)) { return NO; } // 其他动作按默认行为处理 return NO;}

在这个示例中，通过返回 YES 或 NO ，我们自定义了哪些动作可以被执行，哪些不能。这种自定义对于保护应用内容的安全性，或是根据业务需求调整用户交互是十分有用的。

3.2.3 关键代码解析

以上方法重写的实现，允许我们控制不同动作的执行，并可以根据具体需求定制动作处理逻辑。重要的是，在实际操作中，需要根据不同的动作类型来编写相应的逻辑判断，并返回相应的布尔值。这样的控制能力对于提供安全、稳定和符合用户期望的应用界面十分关键。

3.2.4 代码逻辑的逐行解读

-(BOOL)textView:(UITextView *)textView canPerformAction:(SEL)action withSender:(id)sender ：这是 canPerformAction:withSender: 方法的声明，当 UITextView 尝试执行某个动作时，系统会调用该方法。
if (action == @selector(copy:)) ：这里使用 @selector(copy:) 来获取对应 copy: 动作的选择器，然后检查是否是这个动作。如果是，我们返回 YES 。
return YES; ：表示如果动作是复制，则允许执行该动作。
else if (action == @selector(paste:)) ：这行代码检查是否是粘贴动作。如果是，我们返回 NO 。
return NO; ：表示如果动作是粘贴，则不允许执行该动作。
return NO; ：对于未明确指定的动作，我们返回 NO ，这将导致 UITextView 不执行任何额外的动作。这样，我们为 UITextView 提供了一个限制性的动作响应集。

通过上述方法的重写，开发者可以根据应用的具体需求灵活地控制用户界面的动作响应，这是提升应用用户体验和安全性的一种重要手段。

4. performAction:for:with:方法的重写与实现

在iOS应用开发中， performAction:for:with: 方法是UITextView中用于响应动作的一个关键方法。本章节将深入探讨该方法的角色和功能，并提供实现自定义动作处理的详细步骤。

4.1 performAction:for:with:方法的角色和功能

4.1.1 方法的结构与参数详解

performAction:for:with: 方法是UITextView响应动作的核心，它在用户尝试执行一个动作时被调用。该方法的定义如下：

- (BOOL)performAction:(SEL)action forEvent:(UIEvent *)event withSender:(id)sender;

参数 action 代表要执行的动作选择器， event 是触发动作的事件对象， sender 是动作的发起者。

为了更好地理解如何使用这个方法，我们来分析一下它的参数：

action : 它是一个选择器（SEL类型），指向用户想要执行的动作。例如，选择器 @selector(copy:) 可以对应于“复制”动作。
event : 这个参数提供了与动作关联的事件信息，比如触摸事件或者长按事件。
sender : 这个参数指向发起动作的对象。在某些情况下，这可以是触发动作的UITextView实例本身，或者任何其他对象。

4.1.2 与canPerformAction:withSender:的关联

canPerformAction:withSender: 方法可以视为 performAction:for:with: 的前置步骤。 canPerformAction:withSender: 方法用来判断某个动作是否可执行，即提供了一个机会来决定 performAction:for:with: 是否应该被调用。

canPerformAction:withSender: 返回 YES 表示动作可以执行，返回 NO 则相反。当返回 YES 时，系统会随后调用 performAction:for:with: 来执行动作。

4.2 实现自定义动作处理

4.2.1 如何响应用户选中的动作

为了处理用户选中的动作，我们可以在 performAction:for:with: 方法中添加逻辑代码。以下是一个简单的例子：

- (BOOL)performAction:(SEL)action forEvent:(UIEvent *)event withSender:(id)sender { if (action == @selector(copy:)) { // 用户尝试执行复制动作 // 这里编写复制逻辑 return YES; } return [super performAction:action forEvent:event withSender:sender];}

在这个代码块中，我们检测了动作选择器是否为 copy: ，如果是，则执行复制动作的自定义逻辑。其他不相关的动作则交由 super 来处理。

4.2.2 动作与事件的对应处理

在实际应用中，可能需要根据不同的动作和事件类型做出不同的响应。例如，你可能想要区分是点击事件还是长按事件，或者根据不同的动作类型（如复制、剪切、粘贴等）来执行不同的操作。

下面的代码示例展示了如何根据动作类型来决定不同的处理逻辑：

- (BOOL)performAction:(SEL)action forEvent:(UIEvent *)event withSender:(id)sender { if (action == @selector(copy:)) { // 复制动作 // 执行复制文本的代码 return YES; } else if (action == @selector(cut:)) { // 剪切动作 // 执行剪切文本的代码 return YES; } else if (action == @selector(paste:)) { // 粘贴动作 // 执行粘贴文本的代码 return YES; } return [super performAction:action forEvent:event withSender:sender];}

在每个动作分支中，你可以添加具体的逻辑代码来实现相应的功能。记得对于不识别的动作，要返回 [super performAction:action forEvent:event withSender:sender] 以保证其他动作可以正常工作。

通过以上介绍和代码示例，我们可以看出 performAction:for:with: 方法在处理用户操作时的重要性。通过重写此方法，开发者可以为UITextView实现丰富的自定义动作响应，从而增强应用的用户体验。

5. 文字选择功能的定制

5.1 探索UITextView的文字选择机制

5.1.1 文字选择的默认行为

在iOS应用中， UITextView 提供了基本的文字输入和选择功能。默认情况下，当用户长按 UITextView 内的文字时，会弹出一个包含“拷贝”、“定义”、“选择”、“发音”等选项的标准菜单。这种默认行为极大地便利了用户对于文字内容的基本操作需求，使得应用能够快速响应用户的交互意图。

然而，对于某些特定的应用场景，开发者可能需要对这种默认选择菜单进行定制或提供更丰富的用户交互选项。例如，在阅读应用中，用户可能希望将选定的文字标记为“喜欢”或“引用”等自定义操作；在编辑器应用中，可能需要添加“插入图片”或“插入链接”等针对编辑功能的操作。因此，对 UITextView 的默认选择行为进行定制，成为满足特定应用需求的重要手段。

5.1.2 自定义选择功能的必要性

自定义选择功能的目的在于提供更加丰富的用户体验和满足特定应用需求。虽然系统提供了默认的文字选择菜单，但往往这些选项是固定的，无法随着应用的需求进行调整。例如，教育应用可能需要在选择菜单中加入“翻译”选项，而新闻阅读应用可能需要“分享到社交媒体”的功能。

通过自定义选择菜单，开发者能够添加、修改或删除原有菜单中的项，实现对菜单的完全控制。这不仅能提升应用的专业度和用户粘性，而且还可以在保持应用整体风格一致性的同时，提供更多实用功能。

5.2 实现文字选择的定制化处理

5.2.1 定制选择菜单的UI与交互

定制 UITextView 的选择菜单通常需要对UI进行改动，以便提供更符合应用设计风格和功能需求的菜单项。在iOS中，可以通过重写 UITextView 的代理方法 textView:shouldChangeTextInRange:replacementText: 来实现对选择菜单的自定义。

以下是一个自定义选择菜单UI与交互的基本代码示例：

class CustomTextView: UITextView { override func canBecomeFirstResponder() -> Bool { return true } override func canPerformAction(_ action: Selector, withSender sender: Any?) -> Bool { switch action { case #selector(copy), #selector(paste), #selector(cut), #selector(selectAll), #selector(delete): return true default: return false } } override func cut(_ sender: Any?) { // 执行剪切操作 } override func copy(_ sender: Any?) { // 执行复制操作 } override func paste(_ sender: Any?) { // 执行粘贴操作 } override func selectAll(_ sender: Any?) { // 执行全选操作 } override func delete(_ sender: Any?) { // 执行删除操作 }}

在上述代码中，我们通过重写 canPerformAction 方法来决定哪些动作是可执行的。这样，当用户尝试执行某个动作时，只有 copy 、 paste 、 cut 、 selectAll 和 delete 等动作能够被触发，其他自定义动作则需要另外实现。

5.2.2 代码实现中的注意事项

在实现自定义选择功能时，需要考虑到 UITextView 的几个重要代理方法。以下是几个关键的代理方法及其作用：

textViewShouldBeginEditing(_:) ：在 UITextView 开始编辑之前调用，可以在这里做一些预处理，比如显示自定义菜单。
textViewDidBeginEditing(_:) ：当 UITextView 开始编辑时调用，此时可以调整用户界面以适应编辑状态。
textView:shouldChangeTextInRange:replacementText: ：当文本变化时调用，可以用来处理文本的变更，也可以在这个方法中实现自定义动作的逻辑。
textViewShouldEndEditing(_:) ：在 UITextView 结束编辑之前调用，可以在这里做一些后处理，比如隐藏自定义菜单。
textViewDidEndEditing(_:) ：当 UITextView 结束编辑时调用，此时可以恢复用户界面到非编辑状态。

除了代理方法，还需要注意的是，如果要实现特定的用户交互效果，例如手势控制、动画效果等，可能还需要使用 UIResponder 的其他方法来捕捉用户输入。

自定义选择功能的实现涉及到对 UITextView 代理方法的深入理解，以及对iOS用户界面交互原理的掌握。开发者需要在代码逻辑和用户界面之间找到平衡，确保在提供定制功能的同时，不会破坏用户的基本交互体验。

6. 考虑多设备与系统版本的适配及兼容性

随着iOS设备的多样化，包括不同尺寸的屏幕、不同的硬件性能等，开发者在设计和实现功能时需要考虑到多设备的适配策略。同时，因为Apple会定期发布新的iOS系统版本，所以还需要确保应用在新版本上也能正常运行，这就涉及到系统版本的兼容性问题。

6.1 面对多设备的适配策略

6.1.1 设备差异对UI的影响

不同设备屏幕尺寸的差异，会导致同一UI在不同设备上的显示效果出现很大差异。特别是在iPhone和iPad之间，由于屏幕大小和分辨率的不同，相同的布局可能会在某些设备上看起来拥挤或者空旷。

为了适应这些差异，开发者需要使用Auto Layout来设计UI，这样可以根据不同设备的屏幕尺寸自动调整布局。此外，可以使用Size Class来提供不同尺寸下的界面布局，确保在所有设备上都有良好的用户体验。

6.1.2 兼容性问题的排查与解决

当应用在不同设备上测试时，可能会遇到兼容性问题。例如，某些视图在特定设备上可能无法正确显示，或者动画效果不流畅。

为了排查和解决这些问题，开发者需要在多种设备上进行测试，并且使用Xcode提供的各种工具来帮助发现和修复问题。可以使用Xcode的模拟器和真机测试来观察UI在不同设备上的表现，同时利用Instruments来检测性能问题。

6.2 系统版本兼容性的重要性与实现

6.2.1 不同iOS版本的特性差异

随着iOS的更新，Apple会引入新的API和特性。新的iOS设备自然会支持这些特性，但旧的iOS版本可能不支持。这就要求开发者在开发新特性时，同时考虑到对旧版本iOS的支持。

例如，在iOS 13中，引入了Dark Mode特性。开发者在使用这一特性时，应该确保应用能够在支持iOS 13及以上版本的设备上正常显示，并且在更低版本的iOS上能够优雅地降级处理。

6.2.2 适配策略与代码兼容性处理

为了确保应用在不同版本的iOS系统上均能运行良好，开发者应该使用条件编译指令来区分不同版本的系统，并对不同版本的系统提供相应的功能实现。

例如，可以使用 #if targetEnvironment(ipad) 来区分是否在iPad上运行，或者使用 #if __IPHONE_OS_VERSION_MAX_ALLOWED >= 130000 来判断当前是否是iOS 13或更高版本。根据不同的条件，开发者可以编写不同版本的代码来实现功能。

#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 130000 // iOS 13 及以上版本的代码#else // iOS 12 及以下版本的代码#endif

在适配不同iOS版本的过程中，要注意不要过分依赖于最新的API。对于应用来说，向后兼容是必要的，这样可以确保即使在较旧的iOS设备上，用户依然能够得到良好的体验。

总的来说，在开发过程中充分考虑到多设备和系统版本的兼容性，可以确保应用能够覆盖更广泛的用户群体，从而提升应用的市场表现和用户体验。