swift代码转oc代码_什么是不安全的Swift代码？

swift代码转oc代码

崩溃应用是安全的方法 (Crashing your app is the safe route)

强制展开可选的安全代码！ (Force-Unwrapping An Optional Is Safe Code!)

You may think there is no safety net when you force-unwrap an optional. You’re telling the compiler, “I know what I’m doing, this value isn’t nil. I guarantee it.” If it is nil, your app crashes. What you may not know is this is actually a safe way to unwrap optionals.

您可能认为强制拆开选件时没有安全网。 您告诉编译器：“我知道我在做什么，这个值不为零。 我保证。” 如果为零，则您的应用程序崩溃。 你可能不知道的是这其实是一种安全的方式来展开自选。

“But Kenny, if I force-unwrap an optional and it contains a nil value, my app will just crash. This means it’s unsafe!”

“但是肯尼，如果我强制拆开一个可选值并且它包含一个nil值，我的应用程序将崩溃。 这意味着不安全！”

Well, you’re right, but you’re also wrong

好吧，你是对的，但你也是错的

According to Swift Standard Librarian, Karoy Lorentey in his WWDC 2020 talk, Unsafe Swift, there’s no guarantee that your app will crash when unsafe code is executed and encounters an unexpected value (such as an unexpected nil value).

根据Swift标准库管理员Karoy Lorentey在WWDC 2020演讲Unsafe Swift中的说法，无法保证您的应用程序在执行不安全代码并遇到意外值(例如意外nil值)时会崩溃。

What happens at runtime with unsafe code is unpredictable. You may get a crash 99% of the time, but under certain circumstances, garbage may be interpreted instead, allowing your app to continue running, but doing who-knows-what behind your back. Garbled memory produces weird results.

使用不安全代码在运行时发生的事情是不可预测的。 您可能会在99％的时间内崩溃，但在某些情况下，可能会解释为乱码，从而允许您的应用继续运行，但是却知道谁在背后做什么。 内存乱码会产生奇怪的结果。

Conversely, Safe Code Doesn’t Mean Your App Won’t Crash

相反，安全代码并不意味着您的应用程序不会崩溃

Lorentey goes on to say, “The goal of safe APIs is not to prevent crashes — it’s kind of the opposite.” If a safe API receives instructions from outside of what it’s been designed to receive, then your app crashes.

Lorentey继续说：“安全API的目标不是防止崩溃-恰恰相反。” 如果安全的API从设计接收的外部接收指令， 则您的应用程序将崩溃。

This is because “our code broke a critical contract and we need to go and fix it. Proceeding with execution would be irresponsible.” — Lorentey

这是因为“我们的代码违反了关键合同，我们需要去修复它。 继续执行将是不负责任的。” —洛伦蒂

Why We Sometimes Have to Write Unsafe Code

为什么我们有时不得不编写不安全的代码

Unsafe code is often more performant due to the system not having to manage the memory space. Often times though, we just need to interoperate with a C or Objective-C API that uses a pointer.

由于系统不必管理内存空间，因此不安全的代码通常具有更高的性能。 但是通常，我们只需要与使用指针的C或Objective-C API进行互操作即可。

Performance

性能

There’s the odd time or two when performing a check on a nil value is too time-consuming for the operation we’re trying to perform, causing a slowdown in your UI’s responsiveness or other unintended behavior.

对nil值执行检查对于我们尝试执行的操作而言太耗时，可能会有一两个奇怪的时间，这会导致UI的响应速度或其他意外行为变慢。

In these cases, we might specify .unsafelyUnwrapped over carefully unwrapping (guard-let, if-let, != nil), or even force unwrapping. Force-unwrapping does provide a check to see if the value is nil. But it’s safe because it crashes your app when it is. This lets you know exactly at which point your app crashed rather than your app crashing later, or some unintended thing happening.

在这些情况下，我们可以指定.unsafelyUnwrapped来进行仔细的解包(guard-let，if-let，！= nil)，甚至强制解包。 强制展开确实可以检查该值是否为nil。 但这是安全的， 因为它会使您的应用程序崩溃。 这样一来，您就可以准确地知道应用崩溃的时间，而不是以后崩溃或发生意外情况的时间。

The ! operator isn’t just shorthand for .unsafelyUnwrapped.

! 运算符不仅仅是.unsafelyUnwrapped简写。

These two examples are nearly identical, but ! is the safe option. .unsafelyUnwrapped won’t necessarily cause a crash when running across an unexpected nil value.

这两个例子几乎相同，但是！ 是安全的选择。 当运行意外的nil值时，.unsafelyUnwrapped不一定会导致崩溃。

如何从不安全的API区分安全的API (How to tell safe APIs from unsafe APIs)

Unsafe APIs are unsafe because Swift doesn’t manage the memory space they’re in. Instead, we as the Developer must manually manage the memory. We’re given the tools we need by the API, but the trust is being left to us to do the right thing at any given time — this is inherently unsafe. But how do we identify this unsafe code?

不安全的API是不安全的，因为Swift不会管理它们所在的内存空间。相反，作为开发人员，我们必须手动管理内存。 API已为我们提供了所需的工具，但是在任何给定时间都让我们做正确的事留给了我们信任-这本质上是不安全的。 但是，我们如何识别这种不安全的代码？

Thankfully, Unsafe APIs are Clearly Marked As Such

值得庆幸的是，不安全的API已明确标记为

Swift doesn’t know ptr has been deallocated — it looks the same as a valid pointer

Swift不知道ptr已被释放-它看起来与有效指针相同

When you encounter an unsafe API “in the wild,” you’ll know because it will literally be marked Unsafe.

当您在野外遇到不安全的API时，您会知道，因为它实际上会被标记为Unsafe 。

In the above example, we’re allocating space in memory for an Integer, initializing it, deallocating it, and then attempting to set a new value. ptr is deallocated when we attempt to mutate it, but that doesn’t mean the app will crash. Once memory is deallocated, something else can use its space. So what you may be doing now is setting some space in memory to the value 23. What will that do to your app? Who knows. Maybe it’s a different integer and you just changed its value. Maybe its part of a complex operation and you just inserted some weird instruction that’s going to crop up some time later and appear to have been caused by something else.

在上面的示例中，我们在内存中为Integer分配空间，对其进行初始化，取消分配，然后尝试设置新值。 当我们尝试对其进行突变时，会将ptr释放，但这并不意味着该应用程序将崩溃。 释放内存后，其他空间便可以使用。 因此，您现在可能正在做的就是将内存中的一些空间设置为值23。这将对您的应用程序产生什么影响？ 谁知道。 也许它是一个不同的整数，而您只是更改了它的值。 也许这是复杂操作的一部分，您刚刚插入了一条奇怪的指令，该指令将在一段时间后出现，并且似乎是由其他原因引起的。

结语 (Wrap Up)

In conclusion, when we write code that crashes our app, we’re often writing safe code — we just need to fix it. When our app is doing things we just don’t understand or didn’t expect, we may have run across an unsafe API. This is why I only use unsafe APIs when I absolutely have to.

总之，当我们编写使应用程序崩溃的代码时，我们经常在编写安全的代码-我们只需要对其进行修复。 当我们的应用执行某些我们不了解或没想到的事情时，我们可能会遇到不安全的API。 这就是为什么我只在绝对必要时才使用不安全的API。

Many of us spend more time than we have to debugging our code already. I‘m always happy to let the memory be managed for me!

我们中许多人花费的时间比我们已经调试我们的代码要花费的时间更多。 我总是很乐意为我管理内存！

P.S.

聚苯乙烯

Don’t get me wrong — I’m not advocating force-unwrapping optionals all over your app. I rarely force-unwrap optionals in production code. That said, I do force unwrap optionals in development. I want the app to crash if I forgot to set a value so I know there’s something I need to fix.

不要误会我的意思-我不是在整个应用程序中倡导强制展开可选选项。 我很少在生产代码中强制打开可选选项。 就是说，我确实在开发中强制打开了可选的包装。 如果我忘记设置值，我希望该应用程序崩溃，因此我知道需要修复一些问题。

We can all agree that a crash isn’t a good User Experience. I think we’ll all also agree that not seeing anything, or some placeholder value in place of important data also isn’t a good user experience. Carefully unwrapping optionals shouldn’t be a placeholder for carefully making sure you’ve accounted for edge cases where a value may be nil. Nor should force-unwrapping necessarily be avoided in development.

我们都可以同意崩溃不是良好的用户体验。 我想我们都会同意，什么也没看到，或者用占位符代替重要数据也不是一种好的用户体验。 仔细展开可选内容不应该作为占位符，以确保您考虑了值可能为零的极端情况。 在开发中也不必避免强行展开。

翻译自: https://medium.com/dev-genius/what-is-unsafe-swift-code-aa7d1a94c57a

swift代码转oc代码