首页 文章 精选 留言 我的

精选列表

搜索[混元翻译]，共10000篇文章
优秀的个人博客,低调大师

【翻译】2018年，20大Python数据科学库都做了哪些更新？

Python今年依旧保持着数据科学领域的领先地位。去年，我们在博客上列出了15个顶级Python数据科学库的榜单，当时大家都觉得非常好。这次，介绍一下这些顶级数据科学Python库今年有哪些更新，同时，我们还为这个榜单添加了一些新库。 实际上，这次的榜单不止20个库，主要是因为现在某些领域里有多个库都能解决相同的问题，而且暂时也不好说哪个库能成为领头羊，因此，我们将这些库分为一组，供大家选择。 核心库与统计库 1. NumPy (提交修改: 17911, 贡献者: 641) 按惯例，本榜单首先列出科学应用库，Numpy是这一类的首选，它是处理大型多维数组、矩阵及高级数学函数的工具集合，提供了多种数据操作方法。 今年，Numpy进行了很多改进。除了修复Bug和加强兼容性外，关键的改进是增加了可选样式，即Numpy对象的打印格式。此外，还增加了
2018-08-20
优秀的个人博客,低调大师

【翻译】Sklearn与TensorFlow机器学习实用指南 —— 附录 C、SVM 对偶问题

为了理解对偶性，你首先得理解拉格朗日乘子法。它基本思想是将一个有约束优化问题转化为一个无约束优化问题，其方法是将约束条件移动到目标函数中去。让我们看一个简单的例子，例如要找到合适的 x 和 y 使得函数 最小化，且其约束条件是一个等式约束。使用拉格朗日乘子法，我们首先定义一个函数，称为拉格朗日函数。每个约束条件（在这个例子中只有一个）与新的变量（称为拉格朗日乘数）相乘，作为原目标函数的减数。Joseph-Louis Lagrange 大牛证明了如果是原约束优化问题的解，那么一定存在一个，使得是拉格朗日函数的驻点（驻点指的是，在该点处，该函数所有的偏导数均为 0）。换句话说，我们可以计算拉格朗日函数关于以及的偏导数；然后我们可以找到那些偏导数均为 0 的驻点；最后原约束优化问题的解（如果存在）一定在这些驻点里面。 原文发布时间为：20
2018-07-11
优秀的个人博客,低调大师

[Android]Android内存泄漏你所要知道的一切（翻译）

以下内容为原创，欢迎转载，转载请注明 来自天天博客：http://www.cnblogs.com/tiantianbyconan/p/7235616.html Android内存泄漏你所要知道的一切 原文：https://blog.aritraroy.in/everything-you-need-to-know-about-memory-leaks-in-android-apps-655f191ca859 写一个Android app很简单，但是写一个超高品质的内存高效的Android app并不简单。从我的个人经验来说，我曾经比较关注和感兴趣构建我app的新特性，功能和UI组件。 我主要倾向于工作在具有更多视觉冲击力的东西，而不是花时间在没有人一眼会注意到的东西上面。我开始养成了避免或者给app优化等事情更低优先级的习惯（检测和修复内存泄漏就是其中的一个）。 这自然而然导致我承担起了技术负债，从长远来看，它开始影响我的应用的性能和质量。我满满地改变了我的心态，比起去年我更多地以“性能为重点”。 内存泄漏的概念对很多的开发者来说是非常艰巨的。他们觉得这是困难，耗时，无聊和不必要的，但幸运的是，这些都不是真的。一旦你开始深入，你将绝对会爱上它。 在本文中，我将尝试让这个话题尽可能地简单，这样即使是新的开发者也能从他们的职业生涯一开始就能构建高质量和高性能的Android apps。 垃圾收集器是你的朋友，但不一直是 Java是一个强大的语言。在Android中，我们不会（有时候我们会）像 C 或者 C++ 那样去写代码来让我们自己去管理整个内存分配和释放。 现在浮现在我脑中的第一个问题就是，既然Java有了一个内置专用的内存管理系统，它会在我们不需要时清理内存，那么为什么我们还需要关心这个呢。是垃圾收集器不够完善？ 不，当然不是。垃圾收集器的工作原理就是如此。但是我们自己编程错误有时就会阻止垃圾收集器收集大量不必要的内存。 所以基本上，都是我们自己的错误才导致了一切的混乱。垃圾收集器是Java最好的成就之一，它值得被尊重。 推荐阅读 垃圾收集器“更多的一点” 在进一步之前，你需要了解一点垃圾收集器的工作原理。它的原理非常简单，但是它的内部有时候非常复杂。但是不用担心，我们将主要关注简单的部分。 每一个Android（或者Java）应用程序都有一个从对象开始获取实例化、方法被调用的起点。所以我们可以认为这个起点是内存树的“root”。一些对象直接保持了一个对“root”的引用，并且从它们中实例化其它对象，保持这些对象的引用等等。 因而，形成了创建内存树的引用链。所以，垃圾收集器从GC roots开始，然后直接或间接遍历对象链接到根。在这个过程的最后，存在一些GC从来没有访问到的对象。 这些是你的垃圾（或者dead objects），这些对象就是我们所钟爱的垃圾收集器有资格去收集的。 到目前为止，这似乎是一个童话故事，但让我们深入了解一下开始真正的乐趣。 Bonus: 如果你希望学习更多关于垃圾收集器，我强烈推荐你看下 这里 和 这里 。 那么现在，什么是内存泄漏呢？ 知道现在，你有了一个简单想法的垃圾收集器，那么，在Android apps中内存管理师怎么工作的。现在，让我们关注于更详细的内存泄漏这个话题。 简单来说，内存泄漏发生在当你长时间持有一个已经达到目的的对象。实际的概念就这么简单。 每个对象都有它自己的生命，之后它需要说拜拜，然后释放内存。但是如果一些对象持有这个对象（直接或间接），那么垃圾收集器就无法收集它。这就是我们的朋友，内存泄漏。 但是有个好消息就是你不需要担心你app中的每一处的内存泄漏。并不是所有的内存泄漏都会伤害你的app。 有一些泄漏真的非常小（泄漏了几千字节的内存），有些存在于Android framework本身（是的，你没看错），这些你不能也不需要去修复。他们通常对于你的app影响很小并且你可以安全地忽略它们。 但是也存在其它的可以让你的应用程序崩溃，使它像地狱一样滞留，并将其逐字缩小。这些是你要关注的东西。 推荐阅读 为什么你真的需要解决内存泄漏？ 没有人希望使用一个缓慢的、迟钝的、吃很多内存、每用几分钟就会crash的app。对于用户长时间使用，它真的会创建一个糟糕的体验，然后你就有永远失去用户的可能性。 随着用户继续使用你的app，堆内存也不断地增长，如果你的app中有内存泄漏，那么GC就无法释放你无用的内存。所以你app的堆内存就会经常增长，直到达到一个死亡的点，这时将没有更多的内存分配给你的app，从而导致可怕的 OutOfMemoryError 并最终让你的应用程序崩溃。 你还要必须记住一件事情，垃圾收集器是一个繁重的过程，垃圾收集器跑得越少，对你的app就越好。 App正在被使用，对内存保持着增长状态，一个小的GC将启动并尝试清除刚刚死亡的对象。现在这些小的GC同时运行着（在单独的线程上），并且不会减缓你的app（2-5ms的暂停）。 但是如果你的app内部有严重的内存泄漏的问题，那么这些小的GC无法去回收这些内存，并且堆还在持续增长，从而迫使更大的GC被启动，这通常是一个"停止世界 的GC"，它会暂停整个app主线程（大约50-100ms），从而使你的app严重滞后，甚至有时几乎不可用。 所以现在你知道这些内存泄漏可能对你的应用程序产生的影响，以及为什么需要立即修复它们，为用户提供他们应得的最佳体验。 怎么去检测这些内存泄漏？ 目前为止，你应该相当信服你需要修复这些隐藏在你app中的内存泄漏。但是怎么去实际检测它们呢？ 不错的是，对于这点Android Studio提供了一个非常有用且强大的工具，Monitors。这个显示器不仅展示了内存使用，同样还有网络、CPU、GPU使用（更多信息查看这里）。 当你在使用和调试你的app时，应该密切关注这个内存监视器。内存泄漏的第一症状是当你持续使用你的app时内存使用图表经常增长，并且从不下降，甚至在你切换到后台后。 Allocation Tracker可以派上用场，你可以使用它来检查分配给应用程序中不同类型对象的内存百分比。 但是这本身还不够，因为你现在需要使用Dump Java Heap选项来创建一个实际表示给定时间内存快照的heap dump。看起来是一个无聊和重复性的工作，对吧？对，它确实是。 我们工程师往往是懒惰的，这点 LeakCanary 来救援了。这个库随着你的app一起运行。在需要时dump出内存，寻找潜在的内存泄漏并且通过一个清晰有用的stack trace来寻找泄漏的根源。 LeakCanary 让任何人在他们的app中检测泄漏变得超级简单。我不能再感谢 Py(来自 Square)写了如此惊人和拯救了生命的库了。奖励！ Bonus: 如果你想详细学习怎么充分使用这个库，看这里。 推荐阅读 一些实际常见的内存泄漏情况并怎么去解决它们 从我们经验来看，有几个最常见的可能会导致内存泄漏的场景，它们都非常相似，你会在日常的Android开发中遇到这些情况。 一旦你知道这些内存泄漏发生在什么时候，什么地方，怎么发生，你就可以更容易对此进行修复。 Unregistered Listeners 有很多场景，你在Activity（或者Fragment）中进行了一个监听器的注册，但是忘记把它反注册掉。如果运气不好，这个很容易导致一个巨大的内存泄漏。一般情况下，这些监听器是平衡的，所以如果你在某些地方注册了它，你也需要在那里反注册它。 现在我们来看一个简单的例子。假设你要在你的app中接收到位置的更新，你要做的事就是拿到一个 LocationManager 系统服务，然后为位置更新注册一个listener。 private void registerLocationUpdates(){ mManager = (LocationManager) getSystemService(LOCATION_SERVICE); mManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, TimeUnit.MINUTES.toMillis(1), 100, this); } 你在Activity本身实现了listener接口，因此 LocationManager 持有了一个它的引用。现在你的Activity是时候要销毁了，Android Framework将会调用它的 onDestroy() 方法，但是垃圾收集器将不能从内存中把这个实例删除，因为 LocationManager 仍然持有了它的强引用。 解决方案非常简单。仅仅在 onDestroy() 方法中反注册掉listener，这个很好实现。这是我们大多数人忘记甚至不知道的。 @Override public void onDestroy() { super.onDestroy(); if (mManager != null) { mManager.removeUpdates(this); } } 内部类 内部类在Java中非常常见，由于它的简洁性，Android开发者经常使用在各种任务中。但是由于不恰当的使用，这些内部类也导致了潜在的内存泄漏。 让我们再在一个简单例子的帮助下看看， public class BadActivity extends Activity { private TextView mMessageView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.layout_bad_activity); mMessageView = (TextView) findViewById(R.id.messageView); new LongRunningTask().execute(); } private class LongRunningTask extends AsyncTask<Void, Void, String> { @Override protected String doInBackground(Void... params) { return "Am finally done!"; } @Override protected void onPostExecute(String result) { mMessageView.setText(result); } } } 这是一个非常简单的Activity，它在后台（也许是复杂的数据库查询或者一个缓慢的网络请求）启动了一个耗时任务。在Task完成时，结果被展示在 TextView。看起来一切都很好？ 不，当然不是。问题在于非静态内部类持有一个外部类的隐式引用（也就是Activity本身）。现在如果我们旋转了屏幕或者如果这个耗时的任务比Activity生命长，那么它不会让垃圾收集器把整个Activity实例从内存回收。一个简单的错误导致了一个巨大的内存泄漏。 但是解决方案还是非常简单，看了你就明白了， public class GoodActivity extends Activity { private AsyncTask mLongRunningTask; private TextView mMessageView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.layout_good_activity); mMessageView = (TextView) findViewById(R.id.messageView); mLongRunningTask = new LongRunningTask(mMessageView).execute(); } @Override protected void onDestroy() { super.onDestroy(); mLongRunningTask.cancel(true); } private static class LongRunningTask extends AsyncTask<Void, Void, String> { private final WeakReference<TextView> messageViewReference; public LongRunningTask(TextView messageView) { this.messageViewReference = new WeakReference<>(messageView); } @Override protected String doInBackground(Void... params) { String message = null; if (!isCancelled()) { message = "I am finally done!"; } return message; } @Override protected void onPostExecute(String result) { TextView view = messageViewReference.get(); if (view != null) { view.setText(result); } } } } 如你所见，我把非静态内部类改成了静态内部类，这样静态内部类就不会持有任何外部类的隐式引用。但是我们不能通过静态上下文去访问外部类的非静态变量（比如 TextView），所以我们不得不通过构造方法传递我们需要的对象引用到内部类。 我强烈推荐使用 WeakReference 包装这个对象引用来防止进一步的内存泄漏。你需要开始学习关于在Java中各个可用的引用类型。 匿名类 匿名类是很多开发者最喜欢的，因为它们被定义的方式使得用它们编写代码非常容易和简洁。但是根据我的经验这些匿名类是内存泄漏最常见的原因。 匿名类没有什么，但是非静态内部类会由于前面我讲到过的同样的理由引发潜在的内存泄漏。你已经在app的一系列地方用到了它，但是你不知道如果错误的使用可能会对你app的性能有严重的影响。 public class MoviesActivity extends Activity { private TextView mNoOfMoviesThisWeek; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.layout_movies_activity); mNoOfMoviesThisWeek = (TextView) findViewById(R.id.no_of_movies_text_view); MoviesRepository repository = ((MoviesApp) getApplication()).getRepository(); repository.getMoviesThisWeek() .enqueue(new Callback<List<Movie>>() { @Override public void onResponse(Call<List<Movie>> call, Response<List<Movie>> response) { int numberOfMovies = response.body().size(); mNoOfMoviesThisWeek.setText("No of movies this week: " + String.valueOf(numberOfMovies)); } @Override public void onFailure(Call<List<Movie>> call, Throwable t) { // Oops. } }); } } 这里，我们使用了一个非常流行的库 Retrofit 来执行一个网络请求并把结果显示在 TextView 上。很明显，Callable 对象持有了一个外部Activity类的引用。 如果这个网络请求执行速度非常慢，并且在调用结束之前 Activity 因为某种情况被旋转了屏幕或者被销毁，那么整个Activity实例都会被泄漏。 不管是否必须，使用静态内部类来代替匿名内部类通常是明智之举。不是我突然告诉你完全停止使用匿名类，而是你必须要懂得判断什么时候能用什么时候不能用。 推荐阅读 Bitmaps 在你app中看到的所有图片都没关系，除了 Bitmap ，它包含了图像的整个像素数据。 这些 bitmaps 对象一般非常重，如果处理不当可能会引发明显的内存泄漏，并最终让你的app因为 OutOfMemoryError 而崩溃。你在app中使用的图片相关的 bitmap 内存 都会由Android Framework 自身自动管理，如果你手动处理 Bitmap，确保在使用后进行 recycle()。 你还必须学会怎么去正确地管理这些bitmaps，加载大的Bitmap时通过压缩，以及使用bitmap缓存池来尽可能减少内存的占用。这里 有一个理解 bitmap 处理的很好的资源。 Contexts 另一个相当常见的内存泄漏是滥用 context 实例。Context 只是一个抽象类，它有很多类（比如 Activity，Application，Service 等等）继承它并提供它们自己的功能。 如果你要在 Android 中完成任务，那么 Context 对象就是你的老板。 但是这些 contexts 有一些不同之处。非常重要的一点是理解 Activity级别的Context 和 Application级别的Context 之间的区别，分别用在什么情况下。 在错误的地方使用 Activity context 会持有整个 Activity 的引用并引发潜在的内存泄漏。这里有篇很好的文章作为开始。 总结 现在你肯定知道垃圾收集器是怎么工作的，什么是内存泄漏，它们如何对你的app产生重大的影响。你也学习了怎样检测和修复这些内存泄漏。 没有任何借口，从现在开始让我们开始构建一个高质量，高性能的 Android app。检测和修复内存泄漏不仅会让你的app的用户体验更好，而且会慢慢地让你成为一个更好的开发者。 本文最初发表于 TechBeacon.
2017-07-24
优秀的个人博客,低调大师

使用 Swift 构建一个 iOS 的邮件应用 【已翻译100%】

在前几个月内，我一直在做InboxKit的研究，它是关于Inbox平台的IOS SDK。Inbox为和邮件数据的交互提供高层API，使得你可以忽略IMAP,Exchange,MIME的解析以及thread探测(当然还有很多其他事情...)，并使你致力于完成富有创意的APP的创作上。我们的目标很简单:尽可能地打造一个优雅的，跨提供商的邮件应用。毕竟，它很难。 在Objective-C中，InboxKit使得创建邮件体验变得很轻松，那么，Swift又如何呢？Swift在WWDC后已正式被IOS社区所采纳，我认为以后的SDK设计肯定会包括既有Objective-C又有Swift写的样例。 我们的第一个Swift例子，我想写一个简单的app，它就像一个魔幻8球：1.显示Inbox中未读thread 2.当你摇动手机，标记thread为已读并显示新的thread (译者注：文中的thread并不是线程的意思，在论坛中的一个帖子叫thread，回复叫post.这里可理解为一封邮件)**在 Swift 中使用 Objective-C SDK** InboxKit有6000行Objective-C代码，我们还不打算把他们都转换成Swift。为了编译我们的Swift邮件应用，我更新了open-source SDK，包含了“Xcode 6 自定义框架“。自定义框架是Xcode6的新特色-支持第三方框架的创建和分发。当DEFINES_MODULE标志设置为可用时，自定义框架会自动为Swift准备Objective-C模块的头文件。在Swift编译时，它会读取这个模块头文件，把Objective-C的类和方法映射到Swift。 Cocoa Touch框架包含这个SDK之后，在Swift中使用很简单。比如我创建了一个新的Swift应用，只需要把这个SDK拖入工程中，然后在root view controller中添加import InboxKit。 Xcode 6 自定义框架非常棒, 可是目前只有Xcode 6和iOS 8支持. 如果你正在开发一款应用程序, 你仍然可以选择pod InboxKit。 查看邮件InboxKit 让我们从Inbox同步引擎获取邮件数据变得简单起来。我们实例化一个 INThreadProvider ，以此展示来自我们邮箱账号的线程，并且具象化需要的数据。供应者模型 是InboxKit的一个核心概念： 他们被用于获取线程，信息，联系人和更多东西的集合 。供应者有点类似于Core Data中的 NSManagedObjectContext 和 YapDatabase的视图——他们把复杂的东西封装在内部，只是暴露出一个结果集，这个结果集是基于你提供的配置。 在InboxKit，供应者从本地SQLite store拉取缓存数据,同时，让对于Inbox API 的询问变得透明。 我们的应用将展示来自Inbox的未读线程，每次一个，所以我们这样定义线程供应者： var provider:INThreadProvider! = namespace?.newThreadProvider(); provider.itemFilterPredicate = NSComparisonPredicate(format: "ANY tagIDs = %@", INTagIDInbox) provider.itemSortDescriptors = [NSSortDescriptor(key: "lastMessageDate", ascending: false)] provider.delegate = self self.threadProvider = provider 由于我们已经创建了一个线程供应者,我们就可以使用它的条目数组来存放我们的视图. 供应者不会同步获取结果集, 所以我们需要实现INModelProviderDelegate协议并监听更新. 当新的线程通过以下方式被创建的时候,供应者会调用-providerDataChanged 方法,这些创建新线程的方式包括:1.从缓存从获取 2.通过API加载 3.(某个时间)通过网络数据包被推送到应用. 实现协议确保了我们的应用总是显示最新的数据. 还有其他一些代理方法,比如 providerDataAltered:它让基于UICollection或者UITableView创建邮箱用户界面变得更简单,同时可以使用各种插入删除动画效果.但是目前,我们继续看一些基础的东西. func refreshInterface() { var items = self.threadProvider!.items if items.count == 0 { // display empty state self.subjectLabel.text = "No unread threads!" self.snippetLabel.text = "" self.participantsLabel.text = "" self.dateLabel.text = "" } if let thread = items[0] as? INThread { // display the thread self.subjectLabel.text = thread.subject self.snippetLabel.text = thread.snippet self.dateLabel.text = formatter.stringFromDate(thread.lastMessageDate); .... }}func providerDataChanged(provider: INModelProvider!) { self.refreshInterface()}func provider(provider: INModelProvider!, dataFetchFailed error: NSError!) { self.displayError(error);} 标记为已读在我们的 swift 示例程序中,我们要在用户摇动手机的时候，把当前线程标记为已读,并且显示一个新的线程。用InboxKit，标记为已读是非常简单的。 override func motionEnded(motion: UIEventSubtype, withEvent event: UIEvent!) { if (motion == UIEventSubtype.MotionShake) { var items = self.threadProvider!.items if let thread = items[0] as? INThread { thread.markAsRead() } }} 在后台,-markAsReadqueues这个方法使新的API动作进入队列，通过这种行为来从线程中移除未读标签。 INThread对象和本地存储的数据会被立刻更新,但是这个动作将会在手机上排队，直到可以建立连接。如果服务器拒绝这次的动作，那么本地的数据也会回滚。 我们不需要刷新我们的线程供应者-我们的工作已经完成！如果当前线程被标记为已读，那么它就不再需要满足我们线程供应者结果集的标准.供应者会自动匹配它的内容，并且调用providerDataChanged方法,我们实现的代理方法将会刷新我们显示，来展现新集合中的第一个线程。 接下来的步骤 好了! 只用了几十行代码,我们就创建了一个示例程序,它可以从我们的收件箱一条条的获取线程,并且让我们标记为已读.现在它仅仅需要点动画和润色.你可以从这里查看demo的源码:: SwiftEightBall Sample App 我们仅仅接触了InboxKit的一些浅显的东西.在IOS SDK的上层创建我们的swift应用,这意味着我们需要为模型获取本地类的支持,比如线程和通讯录,以及因为支持延时线程和消息动作的SQLite而变得更强大的离线缓存.看看iOS SDK documentation 学习一下更多关于在邮件上层创建美观大方应用的知识.
2017-06-01
优秀的个人博客,低调大师

Swift 在对 Objective-C 改进的 6 个方面 【已翻译100%】

在 Atomic Object 的安娜堡办公室，我们做了一个观看2014年的WWDC主题演讲，毫不夸张地说，当Swift宣布的时候，我们感到十分激动。Swift，苹果正在推进的一个更现代的编程语言。我很高兴能获得先机并开始用它开发。 在这篇博文中，我将重点介绍Swift的几个语言特性，这将使开发者的工作更加轻松。 Objective-C语言的问题 当一个开发者申请一个关于Atomic Object的新职位时，我们会给他填写一个（GTKY） Getting To Know You的表。这个表要求填写一些常见的问题，包括技术和其他方面，比如你最喜欢的语言是什么，你会做些什么来改进它？很多开发者的回答不能令人满意，即使开发人员选择objective-C作为他们最喜爱的语言时，也想不出如何改进它！这个回答产生了大量的讨论，让我想起一个Objective-C的问题。仅举几例： 弱类型 - 通常处理id或class，并且需要可怕的C static casts 。 欠佳的枚举语法 - for in已经很好了，但我经常想到一个更好的索引。 缺少操作符重载的类，例如NSNumber的。 所以，我很高兴苹果宣布swift并公开了其语言细节。在这里我会谈一些对Objective-C语言的批评。我强烈建议开发人员下载Swift的书，看一看在Xcode 6的测试版。 激动人心的Swift特性1. 类型推断对我来说这个很有用。无比烦恼的是你不得不将id类型的实例非安全的转化为实际类型，这很容易出错并且向一个实际对象并不相应的id发送信号。总是检查respondsToSelector太乏味了。Swift给我们提供了一个解决方案---var关键字： 1> var anInt = 0 anInt: Int = 0 2> var aDouble = 0.0 aDouble: Double = 0 3> var anotherDouble: Double = 0 anotherDouble: Double = 0 4> var aString = "some string" aString: String = "some string" 注意：就像anotherDouble那种情况，你也可以显示的设置类型。可以用var同样的方式使用let来推断常量的类型。 2. 改进枚举语法 Objective-C有不错的集合枚举语法：**for (SomeType someObject in array) NSLog(@"%@", someObject.whatever);** 这是个不错的语法糖，但是问题是现实编程中，我通常需要一个和集合中元素实例一起的索引变量。. Swift 给了我们许多有用的集合枚举器, 但是尤其令人高兴的是他们提供了一个全局的enumerate()方法，可以用来返回一个包含了数组中元素和索引的元组。 19> array $R2: String[] = size=4 { [0] = "one" [1] = "two" [2] = "three" [3] = "four" } 20> for (index, value) in enumerate(array) { 21. println("Item \(index): \(value)") 22. } Item 0: one Item 1: two Item 2: three Item 3: four 23> 3. Override关键字当在类中声明一个实例函数时，如果他们覆盖了一个基类函数，他们必须标记为override的。如果没有这么做则会得到一个编译时错误。类似的，如果一个标记为override的函数没有覆盖基类的相应函数，同样得到一个编译错误。这一行为将的类更加的清晰和降低运行时崩溃的可能性。 4. 多返回值在我加入Atomic之前的那份工作中，我主要开发C++，并且经常发现自己写一些输出多值的方法。我总是为决定使用引用，pair还是将返回值包装为struct或class来作为参数传递而挣扎不已。 在Swift中,有内置的机制来用一个由任意数量的带标记的数据成员的组成的元组作为多返回值。 46> func calculateStatisticsFromArray(data: Double[]) -> (mean: Double, median: Double, mode: Double) { 47. return (62, 44, 12) 48. } 49> var stats = calculateStatisticsFromArray([]) stats: (mean: Double, median: Double, mode: Double) = { mean = 62 median = 44 mode = 12 } 50> stats.mean $R10: Double = 62 51> stats.median $R11: Double = 44 52> stats.mode $R12: Double = 12 Swift同样支持声明多个变量来显示的获取多返回值： <51> var(mean, median, mode) = calculateStatisticsFromArray(data)** willSet, didSet**在 Swift中, 类具有属性（类似于Objective-C）。有一个声明setter和getter的机制，如果属性的类型是简单的并且需要计算的，但是你想观察他们的变化，两个内置的需要覆盖的方法-willSet和didSet将会有帮助。 1> class Container { 2. var someValue: Double = 0.0 { 3. willSet { 4. println("willSet! \(newValue)") 5. } 6. didSet { 7. println("didSet! \(someValue)") 8. } 9. } 10. } 11> var c = Container() c: Container = { someValue = 0 } 12> c.someValue = 100.0 willSet! 100.0 didSet! 100.0 6. REPL REPL表示“read-evaluate-print-loop”,我认为它是通过沙箱测试输出的代码.您可以输入代码到REPL,如果您在使用一个IDE或者喜爱的文本编辑器，它会被编译/解释和实时运行，并马上能让你看到输出结果。这是开发人员努力学习这门新语言时能看到的一个强大功能。我一直在使用它来学习swift。 使用SWIFT REPL： 1.下载Xcode 6 Beta版。 2.在终端中运行以下命令来切换路径xcrun： sudo xcode-select -switch /Applications/Xcode6-Beta.app/Contents/Developer. 注意：如果要重置，请在使用终端里键入 xcode-select -r 3.xcrun swift 谁将拥有未来?我坚信，在iOS 8和以后的版本中，Swift将成长成为iOS开发的主流语言。尽管如此，苹果已经向我们保证，在运行时将保持二者兼容：我们的Objective-C应用程序仍然可以继续工作。同样清楚的是Swift的语法和语义将改变后的iOS 8。苹果告诉我们，他们不能保证源代码的兼容性，但会提供代码转换器。使用代码转换器的想法让我害怕了一下，我认为迁移到Swift的时间会来得早（iOS的8-9的样子），而不是以后。
2017-06-01

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-10-18 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册