আমরা কি সুইফটে বন্ধের ভিতরে সর্বদা [অবিকৃত স্ব] ব্যবহার করব?

Question

ডাব্লুডাব্লুডিসি 2014 সেশনে 403 ইন্টারমিডিয়েট সুইফ্ট এবং ট্রান্সক্রিপ্ট , নিম্নলিখিত স্লাইড ছিল

সেক্ষেত্রে স্পিকার বলেছিলেন, আমরা যদি [unowned self]সেখানে ব্যবহার না করি তবে এটি একটি স্মৃতি ফাঁস হবে। এর অর্থ কি আমাদের সর্বদা [unowned self]বন্ধের ভিতরে ব্যবহার করা উচিত ?

উপর সুইফট আবহাওয়ার অ্যাপের ViewController.swift লাইন 64 , আমি ব্যবহার করি না [unowned self]। তবে আমি কিছু @IBOutletসের মত self.temperatureএবং ব্যবহার করে ইউআই আপডেট করি self.loadingIndicator। এটি ঠিক হতে পারে কারণ @IBOutletআমি সংজ্ঞায়িত সমস্ত গুলি weak। তবে সুরক্ষার জন্য, আমাদের কি সর্বদা ব্যবহার করা উচিত [unowned self]?

class TempNotifier {
  var onChange: (Int) -> Void = {_ in }
  var currentTemp = 72
  init() {
    onChange = { [unowned self] temp in
      self.currentTemp = temp
    }
  }
}

Comments

চিত্রটির লিঙ্কটি নষ্ট হয়েছে

— ড্যানিয়েল গোমেজ রিকো

@ DanielG.R। ধন্যবাদ, আমি এটি দেখতে পারি। i.stack.imgur.com/Jd9Co.png

— জেক লিন

যদি আমি ভুল না করি তবে স্লাইডে দেওয়া উদাহরণটি ভুল — এটি একটি জনসাধারণের (অভ্যন্তরীণ, তবে এখনও) সম্পত্তি হওয়ায় onChangeএকটি [weak self]ক্লোজার হওয়া উচিত , সুতরাং অন্য কোনও বস্তু টেম্পন্টিফায়ার অবজেক্টটিকে চারপাশে রেখে (অনির্দিষ্টকালের জন্য যদি) অবজেক্ট ব্যবহার ভেতরে যেতে দেয়নি যেতে onChangeনা হওয়া পর্যন্ত উদ্ধার অবসান TempNotifierচলে গেছে, নিজস্ব দুর্বল সুত্র মাধ্যমে TempNotifier) । যদি var onChange …হয় private var onChange …তবে [unowned self]সঠিক হবে। আমি যদিও এর 100% নিশ্চিত নই; আমি ভুল হলে কেউ দয়া করে আমাকে সংশোধন করুন।

— স্লিপ ডি থম্পসন

@ জ্যাক লিন `var অন চেঞ্জ করুন: (আন্তঃ) -> শূন্য = {}` কোঁকড়া ধনুর্বন্ধনী একটি ফাঁকা বন্ধকে উপস্থাপন করে? এটির সাথে খালি অ্যারে সংজ্ঞা দেওয়ার মতোই []? আমি অ্যাপল ডক্সে ব্যাখ্যাটি খুঁজে পাচ্ছি না।

— বাইবেস

@ বিবিসি হ্যাঁ, {}খালি ক্লোজার (বন্ধের উদাহরণ) ডিফল্ট হিসাবে (কোনও কিছু করে না), (Int) -> Voidএটি ক্লোজার সংজ্ঞা।

— জ্যাক লিন

Answer 1

না, এমন সময় আছে যখন আপনি ব্যবহার করতে চাইবেন না [unowned self]। কখনও কখনও আপনি ক্লোজারটি আহ্বান করার সময়কালে এটি এখনও রয়েছে কিনা তা নিশ্চিত করার জন্য ক্লোজারটি নিজেকে ক্যাপচার করতে চায়।

উদাহরণ: অ্যাসিক্রোনাস নেটওয়ার্ক অনুরোধ করা

আপনি তৈরি করছেন যদি একটি অ্যাসিঙ্ক্রোনাস নেটওয়ার্ক অনুরোধের আপনি কি অবসান বজায় রাখতে চান selfযখন অনুরোধ শেষ জন্য। এই অবজেক্টটি অন্যথায় বিলোপযুক্ত হয়ে থাকতে পারে তবে আপনি এখনও অনুরোধ শেষ করে পরিচালনা করতে সক্ষম হতে চান।

কখন ব্যবহার করবেন unowned selfবাweak self

শুধুমাত্র সময় যেখানে আপনি সত্যিই ব্যবহার করতে চান [unowned self]বা [weak self]যখন আপনি একটি তৈরি হবে শক্তিশালী রেফারেন্স চক্র । একটি শক্তিশালী রেফারেন্স চক্র হয় যখন মালিকানার একটি লুপ থাকে যেখানে অবজেক্টগুলি একে অপরের মালিকানাধীন থাকে (সম্ভবত কোনও তৃতীয় পক্ষের মাধ্যমে) এবং সুতরাং সেগুলি কখনই বিলোপযুক্ত হবে না কারণ তারা উভয়ই একে অপরের চারপাশে থাকা নিশ্চিত করছে।

একটি বন্ধের নির্দিষ্ট ক্ষেত্রে, আপনাকে কেবল বুঝতে হবে যে কোনও ভেরিয়েবল যা এর অভ্যন্তরে উল্লেখ করা হয়, বন্ধ হয়ে "মালিকানাধীন" হয়। যতক্ষণ বন্ধের চারপাশ থাকবে ততক্ষণ those অবজেক্টগুলি আশেপাশে থাকার নিশ্চয়তা রয়েছে। এই মালিকানা বন্ধ করার একমাত্র উপায়, [unowned self]বা করা [weak self]। সুতরাং যদি কোনও শ্রেণীর কোনও ক্লোজারের মালিক হয় এবং সেই ক্লোজারটি সেই শ্রেণীর একটি শক্তিশালী রেফারেন্স ধারণ করে, তবে আপনার ক্লোজার এবং ক্লাসের মধ্যে একটি শক্তিশালী রেফারেন্স চক্র রয়েছে। ক্লাসটি ক্লোসের মালিকানাধীন এমন কোনও কিছুর মালিক হলে এটিও অন্তর্ভুক্ত।

বিশেষত ভিডিও থেকে উদাহরণে

স্লাইডের উদাহরণে, সদস্য ভেরিয়েবলের TempNotifierমাধ্যমে ক্লোজারটির মালিক onChange। যদি তারা এই selfহিসাবে ঘোষণা না করে unownedতবে বন্ধটি selfএকটি শক্তিশালী রেফারেন্স চক্র তৈরির মালিক হবে ।

unownedএবং মধ্যে পার্থক্যweak

মধ্যে পার্থক্য unownedএবং weakযে weakহিসাবে একটি ঐচ্ছিক যখন ঘোষিত হয় unownedনয়। এটি ঘোষণার মাধ্যমে weakআপনি কেসটি পরিচালনা করতে পারেন যে এটি কোনও কোনও সময় বন্ধের ভিতরে শূন্য হতে পারে। আপনি যদি unownedএমন কোনও ভেরিয়েবল অ্যাক্সেস করার চেষ্টা করে যা শূন্য হয়ে যায়, এটি পুরো প্রোগ্রামটি ক্রাশ করবে। সুতরাং unownedআপনি যখন ইতিবাচক হন কেবল তখনই ব্যবহার করুন যখন বন্ধের চারপাশে চলকটি সর্বদা কাছাকাছি থাকবে

Comments

ওহে. দুর্দান্ত উত্তর। আমি অজানা স্ব বোঝার জন্য সংগ্রাম করছি। কেবল 'স্ব-anচ্ছিক হয়ে ওঠে' বলে দুর্বল নিজেকে ব্যবহার করার কারণটি আমার পক্ষে যথেষ্ট নয়। আমি কেন বিশেষভাবে 'অপরিশোধিত স্ব' ব্যবহার করতে

@ অরবদাশনাশ, অচেতন স্ব ব্যবহারের সুবিধা হ'ল আপনাকে এমন একটি বিকল্প w শেষ পর্যন্ত, অজানা নিজেরাই বংশবৃদ্ধির জন্য এবং সম্ভবত ভবিষ্যতের বিকাশকারীদের জন্য একটি ইঙ্গিত হিসাবে ব্যবহৃত হয় যা আপনি কখনই শূন্যতার প্রত্যাশা করেন না।

— ড্র্যাগ করুন

[weak self]একটি অ্যাসিক্রোনাস নেটওয়ার্ক অনুরোধে ব্যবহারের জন্য একটি কেস একটি ভিউ কন্ট্রোলারে রয়েছে যেখানে সেই অনুরোধটি ভিউ পপুলেট করার জন্য ব্যবহৃত হয়। যদি ব্যবহারকারী ব্যাক আউট করে ফেলে তবে আমাদের আর ভিউটি পপুলেট করার দরকার নেই, না আমাদের ভিউ কন্ট্রোলারের কোনও রেফারেন্সের দরকার নেই।

— ডেভিড জেমস

weakরেফারেন্সগুলি সেট করা হয় nilযখন অবজেক্টটি হ্রাস করা হয়। unownedউল্লেখ নেই।

— বার্গকুইস্টার

আমি একটু বিভ্রান্ত। unownedজন্য ব্যবহার করা হয় non-Optionalযখন weakজন্য ব্যবহার করা হয় Optional, যাতে আমাদের selfহয় Optionalবা non-optional?

— মুহাম্মদ নায়ব

Answer 2

আপডেট 11/2016

আমি এই উত্তরটি প্রসারিত করার বিষয়ে একটি নিবন্ধ লিখেছি (এআরসি কী করে তা বোঝার জন্য এসআইএল অনুসন্ধান করছে), এটি এখানে দেখুন ।

আসল উত্তর

পূর্ববর্তী উত্তরগুলি কখন অন্যটির ওপরে কীভাবে ব্যবহার করা উচিত এবং কেন সে সম্পর্কে সহজ সরল নিয়ম দেয় না, তাই আমাকে কয়েকটি জিনিস যুক্ত করা যাক।

অজানা বা দুর্বল আলোচনাটি ভেরিয়েবলের আজীবন এবং সমাপ্তির উল্লেখ করে যা এটি উল্লেখ করে।

প্রেক্ষাপটে

আপনার দুটি সম্ভাব্য পরিস্থিতি থাকতে পারে:

1. বন্ধটির ভেরিয়েবলের একই জীবনকাল থাকে, সুতরাং ভেরিয়েবলটি পৌঁছনীয় না হওয়া পর্যন্ত বন্ধটি কেবলমাত্র পৌঁছনীয় । পরিবর্তনশীল এবং বন্ধের একই জীবনকাল রয়েছে lifetime এই ক্ষেত্রে আপনার রেফারেন্সটি অজানা হিসাবে ঘোষণা করা উচিত । একটি সাধারণ উদাহরণ হ'ল [unowned self]ছোট বন্ধের অনেক উদাহরণে ব্যবহৃত হয় যা তাদের পিতামাতার প্রসঙ্গে কিছু করে এবং অন্য কোথাও রেফারেন্স না দেওয়া তাদের পিতামাতাকে ছাড়িয়ে যায় না।

2. বন্ধের আজীবন ভেরিয়েবলের মধ্যে একটি থেকে পৃথক, চলকটি আর পৌঁছনীয় না হলে বন্ধের বিষয়টি এখনও উল্লেখ করা যেতে পারে। এই ক্ষেত্রে আপনার রেফারেন্সটিকে দুর্বল হিসাবে ঘোষণা করা উচিত এবং এটি ব্যবহারের আগে এটি শূন্য করা উচিত তা যাচাই করা উচিত (জোর করে মোড়ানো হবে না)। এর একটি সাধারণ উদাহরণ হ'ল [weak delegate]আপনি সম্পূর্ণরূপে সম্পর্কযুক্ত (আজীবন বুদ্ধিমান) ডেলিগেট অবজেক্টকে উল্লেখ করে ক্লোজারের কয়েকটি উদাহরণে দেখতে পাচ্ছেন।

আসল ব্যবহার

সুতরাং, আপনি / বেশিরভাগ সময় ব্যবহার করা উচিত?

টুইটার থেকে জো গ্রাফের উদ্ধৃতি :

অজ্ঞাতসই দ্রুত এবং এটি অপরিবর্তনীয়তা এবং অমূলককরণের অনুমতি দেয়।

আপনার যদি দুর্বল প্রয়োজন না হয় তবে এটি ব্যবহার করবেন না।

আপনি এখানে অনাবৃত *অভ্যন্তরীণ কর্ম সম্পর্কে আরও সন্ধান করতে পারেন ।

* অনাবৃত রেফারেন্স অ্যাক্সেস করার আগে রানটাইম চেকগুলি (যা অবৈধ রেফারেন্সগুলির জন্য ক্র্যাশের দিকে পরিচালিত করে) সঞ্চালিত হয় তা নির্দেশ করতে সাধারণত অজানা (নিরাপদ) হিসাবেও উল্লেখ করা হয়।

Comments

আমি তোতার ব্যাখ্যা শুনে ক্লান্ত হয়ে পড়েছি "যদি নিজেকে নিঃশব্দ করা যায় তবে সপ্তাহটি ব্যবহার করুন, যখন কখনই শূন্য না হতে পারে" ব্যবহার করবেন না। ঠিক আছে আমরা পেয়েছি - এটি এক মিলিয়ন বার শুনেছি! এই উত্তরটি আসলে আরও সহজভাবে গভীরভাবে খনন করে যে কখন স্পষ্ট ইংরেজিতে স্ব-স্বর থাকতে পারে, যা সরাসরি ওপি-র প্রশ্নের উত্তর দেয়। এই মহান ব্যাখ্যা জন্য ধন্যবাদ !!

— TruMan1

ধন্যবাদ @ ট্রুম্যান 1, আমি এটিতে আসলে একটি পোস্ট লিখছি যা শীঘ্রই আমার ব্লগে শেষ হবে, একটি লিঙ্কের সাথে উত্তরটি আপডেট করবে।

— উম্বের্তো রায়মন্ডি

সুন্দর উত্তর, খুব ব্যবহারিক। আমি আমার অভিনয়ের সংবেদনশীল কিছু দুর্বল ভার এখন অনাবৃতকে স্যুইচ করতে অনুপ্রাণিত।

— original_username

"ক্লোজারের আজীবন পরিবর্তনশীলগুলির মধ্যে একটি থেকে স্বতন্ত্র" আপনার এখানে কি টাইপ আছে?

— মধু

যদি কোনও বন্ধন সর্বদা পিতামাতার মতো একই জীবনকাল থাকে তবে অবজেক্টটি ধ্বংস হয়ে যাওয়ার পরেও কি রেফারেন্স গণনাটি যত্ন নেওয়া হবে না? অজানা বা দুর্বলদের বিরক্ত করার পরিবর্তে আপনি কেন এই পরিস্থিতিতে 'স্ব' ব্যবহার করতে পারবেন না?

— কিংবদন্তি লেন্থথ

Answer 3

আমি ভেবেছিলাম আমি বিশেষভাবে একটি ভিউ কন্ট্রোলারের জন্য কিছু কংক্রিট উদাহরণ যুক্ত করব। কেবল এখানে স্ট্যাক ওভারফ্লোতে নয়, অনেক ব্যাখ্যা সত্যই ভাল, তবে আমি বাস্তব বিশ্বের উদাহরণগুলির সাথে আরও ভাল কাজ করি (@ ড্রায়াগের এটির একটি ভাল শুরু হয়েছিল):

• আপনার যদি কোনও নেটওয়ার্কের অনুরোধগুলি থেকে কোনও প্রতিক্রিয়া হ্যান্ডেল করতে বন্ধ হয় weakতবে এটি দীর্ঘকালীন। অনুরোধটি সম্পন্ন হওয়ার আগে ভিউ কন্ট্রোলারটি বন্ধ হয়ে যেতে পারে তাই বন্ধ হওয়ার পরে selfযখন কোনও বৈধ অবজেক্টের দিকে নির্দেশ না করে points

• যদি আপনার বন্ধ থাকে তবে এটি একটি বোতামে একটি ইভেন্ট পরিচালনা করে। এটি হতে পারে unownedকারণ ভিউ কন্ট্রোলারটি চলে যাওয়ার সাথে সাথেই বাটন এবং অন্য যে কোনও আইটেম থেকে এটি উল্লেখ করা যেতে পারে selfএকই সময়ে চলে যায়। ক্লোজার ব্লক একই সময়ে চলে যাবে।

  class MyViewController: UIViewController {
        @IBOutlet weak var myButton: UIButton!
        let networkManager = NetworkManager()
        let buttonPressClosure: () -> Void // closure must be held in this class. 
  
        override func viewDidLoad() {
            // use unowned here
            buttonPressClosure = { [unowned self] in
                self.changeDisplayViewMode() // won't happen after vc closes. 
            }
            // use weak here
            networkManager.fetch(query: query) { [weak self] (results, error) in
                self?.updateUI() // could be called any time after vc closes
            }
        }
        @IBAction func buttonPress(self: Any) {
           buttonPressClosure()
        }
  
        // rest of class below.
   }
  

Comments

এই এক আরও upvotes প্রয়োজন। দুটি দৃ examples় উদাহরণ যা দেখায় যে কীভাবে একটি বাটন প্রেস ক্লোজারটি ভিউ কন্ট্রোলারের জীবদ্দশার বাইরে থাকবে না এবং তাই অজানা ব্যবহার করতে পারে, তবে বেশিরভাগ নেটওয়ার্ক কল যা আপডেট ইউআইকে দুর্বল করা দরকার।

— টিম ফুয়োয়া

সুতরাং কেবল স্পষ্ট করে বলতে গেলে, ক্লোজার ব্লকে নিজেকে কল করার সময় আমরা কি সর্বদা অজানা বা দুর্বল ব্যবহার করি? বা এমন কোনও সময় রয়েছে যেখানে আমরা দুর্বল / অচেতন কল করব না? যদি তা হয় তবে আপনি কি তার জন্য একটি উদাহরণ সরবরাহ করতে পারেন?

— লুক

তোমাকে অনেক ধন্যবাদ.

— শন বেক

এটি আমাকে [দুর্বল স্ব] এবং [অচেতন স্ব] সম্পর্কে আরও গভীর ধারণা দিয়েছে, ধন্যবাদ @ পসেনকে অনেক ধন্যবাদ!

— টমি

এটা অসাধারণ. আমার যদি এমন কোনও অ্যানিমেশন থাকে যা ব্যবহারকারীর মিথস্ক্রিয়ার ভিত্তিতে তৈরি হয় তবে শেষ করতে কিছুক্ষণ সময় নেয়। এবং তারপরে ব্যবহারকারী অন্য ভিউকন্ট্রোলারে চলে যান। আমি মনে করি সে ক্ষেত্রে আমার এখনও ডান weakপরিবর্তে ব্যবহার করা উচিত unowned?

— মধু

Answer 4

যদি স্ব অবসান ব্যবহারে শূন্য হতে পারে [দুর্বল স্ব] ।

যদি স্বাবলম্বন কখনই বন্ধের ব্যবহারে [অচেতন স্ব] নিরস্ত হয় না ।

অ্যাপল সুইফ্ট ডকুমেন্টেশনের একটি দুর্দান্ত বিভাগ রয়েছে যা দৃ strong ় , দুর্বল , এবং বন্ধে অবহেলিত ব্যবহারের মধ্যে পার্থক্য ব্যাখ্যা করে চিত্রগুলি সহ :

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html

Answer 5

অ্যাপল বিকাশকারী ফোরামের সুস্বাদু বিবরণ বর্ণিত উজ্জ্বল উক্তিগুলি এখানে :

unownedবনাম unowned(safe)বনামunowned(unsafe)

unowned(safe)অ-মালিকানাধীন রেফারেন্স যা অ্যাক্সেসের উপর দৃ .়তা দেয় যে বস্তুটি এখনও জীবিত। এটি এক ধরণের দুর্বল alচ্ছিক রেফারেন্সের মতো যা x!প্রতিবার অ্যাক্সেসের সাথে স্পষ্টভাবে আবদ্ধ হয় । এটিআরসি-র unowned(unsafe)মতো __unsafe_unretained— এটি একটি মালিকানা-বহির্ভুত রেফারেন্স, তবে কোনও রানটাইম চেক নেই যে বস্তুটি এখনও অ্যাক্সেসে বেঁচে আছে, তাই জটলা রেফারেন্সগুলি আবর্জনার স্মৃতিতে পৌঁছে যাবে। unownedবর্তমানে সর্বদা প্রতিশব্দ unowned(safe), তবে উদ্দেশ্যটি হ'ল রানটাইম চেকগুলি অক্ষম করা হলে unowned(unsafe)এটি -Ofastবিল্ডগুলিতে অনুকূলিত হবে ।

unowned বনাম weak

unownedআসলে তুলনায় অনেক সহজ বাস্তবায়ন ব্যবহার করে weak। নেটিভ সুইফট অবজেক্ট দুটি শক্তির রেফারেন্স গণনা বহন করে এবং unowned রেফারেন্সগুলি শক্তিশালী রেফারেন্স গণনার পরিবর্তে অবিকৃত রেফারেন্স গণনাটিকে ঘিরে ফেলে । বস্তুর deinitialized হয় যখন তার শক্তিশালী রেফারেন্স গণনা শূন্য ছুঁয়েছে, কিন্তু এটি আসলে deallocated নয় যতক্ষণ না মালিকহীন রেফারেন্স গণনা এছাড়াও শূন্য হিট। এটি অজানা রেফারেন্সগুলি থাকাকালীন মেমরিটিকে কিছুটা দীর্ঘায়িত করে তোলে, তবে এটি সাধারণত কোনও সমস্যা হয় নাunowned ব্যবহার করা হয় কারণ সম্পর্কিত অবজেক্টগুলির যেকোন উপায়ে প্রায় সমান লাইফটাইম থাকা উচিত এবং এটি দুর্বল রেফারেন্সগুলি শূন্য করার জন্য ব্যবহৃত সাইড-টেবিল ভিত্তিক প্রয়োগের তুলনায় অনেক সহজ এবং নিম্ন-ওভারহেড।

আপডেট: আধুনিক সুইফটে weakঅভ্যন্তরীণভাবে একই পদ্ধতি ব্যবহার unownedকরে । সুতরাং এই তুলনাটি ভুল কারণ এটি weakসুইফটের সাথে উদ্দেশ্য-সিটির তুলনা করে unonwed।

কারণ

রেফারেন্সগুলি 0 এ পৌঁছানোর পরে স্মৃতিটিকে বাঁচিয়ে রাখার উদ্দেশ্য কী? কোডটি ডিজিটালাইজ করার পরে অবাঞ্ছিত রেফারেন্স ব্যবহার করে অবজেক্টের সাথে কিছু করার চেষ্টা করলে কী হবে?

স্মৃতিটি জীবিত রাখা হয়েছে যাতে এটির ধরে রাখা গণনাগুলি এখনও উপলব্ধ। এইভাবে, যখন কেউ অজানা অবজেক্টের একটি শক্তিশালী রেফারেন্স ধরে রাখার চেষ্টা করে, রানটাইমটি পরীক্ষা করতে পারে যে শক্তিশালী রেফারেন্স গণনাটি শূন্যের চেয়ে বেশি হয় যাতে বিষয়টি নিশ্চিত রাখা যায় যে এটি অবজেক্টটি ধরে রাখা নিরাপদ।

অবজেক্টটির অধীনে থাকা মালিকানাধীন বা অজানা রেফারেন্সগুলি কী ঘটে? যখন তাদের ডিজাইনটাইয়ালাইজ করা হয় তখন তাদের জীবনকাল কি বস্তুটি থেকে অদৃশ্য হয়ে যায় বা সর্বশেষ অব্যক্ত রেফারেন্স প্রকাশের পরে অবজেক্টটি বিকল না হওয়া পর্যন্ত তাদের স্মৃতিশক্তিও বজায় থাকে?

অবজেক্টের মালিকানাধীন সমস্ত সংস্থানগুলি অবজেক্টের শেষ দৃ strong় রেফারেন্স প্রকাশের সাথে সাথেই প্রকাশিত হয় এবং এর ডিনিট চালানো হয়। অজানা রেফারেন্সগুলি কেবল স্মৃতিটিকে বাঁচিয়ে রাখে reference রেফারেন্স গণনা সহ শিরোনাম থেকে আলাদা করে, এর বিষয়বস্তু নষ্ট।

উত্তেজিত, হাহ?

Answer 6

এখানে কিছু দুর্দান্ত উত্তর আছে। তবে সাম্প্রতিক পরিবর্তনগুলি কীভাবে সুইফ্টকে দুর্বল রেফারেন্সগুলি প্রয়োগ করে তাতে প্রত্যেকের দুর্বল স্ব বনাম অজানা স্ব স্ব ব্যবহারের সিদ্ধান্তগুলি পরিবর্তন করা উচিত। পূর্বে, অজানা স্ব ব্যবহারের ক্ষেত্রে যদি আপনার সর্বোত্তম পারফরম্যান্সের প্রয়োজন হয় তবে দুর্বল স্বের চেয়েও উত্তম ছিল, যতক্ষণ না আপনি নিশ্চিত হতে পারেন যে স্ব কখনই শূন্য হয় না, কারণ অজানা স্ব অ্যাক্সেস করা দুর্বল স্বের অ্যাক্সেসের চেয়ে অনেক দ্রুত।

তবে মাইক অ্যাশ নথিভুক্ত করেছেন যে কীভাবে সুইফট সাইড-টেবিলগুলি ব্যবহার করতে দুর্বল ভারগুলির বাস্তবায়ন আপডেট করেছে এবং কীভাবে এটি দুর্বল স্ব-কর্মক্ষমতা যথেষ্ট পরিমাণে উন্নত করে।

https://mikeash.com/pyblog/friday-qa-2017-09-22-swift-4-weak-references.html

দুর্বল স্বের জন্য এখন উল্লেখযোগ্য পারফরম্যান্সের জরিমানা নেই, আমি বিশ্বাস করি এটি এগিয়ে যাওয়ার জন্য আমাদের ডিফল্ট হওয়া উচিত। দুর্বল স্বের সুবিধা হ'ল এটি একটি alচ্ছিক, যা আরও সঠিক কোড লিখতে আরও সহজ করে তোলে, এটি মূলত সুইফট এমন দুর্দান্ত ভাষা বলে কারণ। আপনি হয়ত ভাবেন যে আপনি জানেন যে অজানা স্ব ব্যবহারের জন্য কোন পরিস্থিতি নিরাপদ, তবে আমার অন্যান্য প্রচুর বিকাশকারী কোডের পর্যালোচনা করার অভিজ্ঞতাটি সবচেয়ে বেশি তা নয়। আমি প্রচুর ক্র্যাশগুলি স্থির করেছি যেখানে অজানা স্ব-স্বল্প বিচ্ছিন্ন হয়ে পড়েছিল, সাধারণত এমন পরিস্থিতিতে যেখানে নিয়ামককে বিচ্ছিন্ন করার পরে কোনও পটভূমি থ্রেড সম্পূর্ণ হয়।

বাগ এবং ক্র্যাশগুলি প্রোগ্রামিংয়ের সর্বাধিক সময় ব্যয়কারী, বেদনাদায়ক এবং ব্যয়বহুল অংশ। সঠিক কোড লিখতে এবং এড়াতে যথাসাধ্য চেষ্টা করুন। আমি এটিকে নিয়ম করে আনার জন্য বিকল্পগুলি জোর করে না নেওয়ার এবং দুর্বল স্বের পরিবর্তে অকেহিত স্ব ব্যবহার করবেন না recommend আন-র্যাপিং ও অবৈজ্ঞানিক স্ব প্রকৃতপক্ষে নিরাপদ থাকা সময়কে হারিয়ে যাওয়া আপনি কোনওটিই হারাবেন না। তবে ক্রাশ এবং বাগগুলি খুঁজে পেতে এবং ডিবাগ করা কঠিন থেকে মুছে ফেলা থেকে আপনি প্রচুর উপকার পাবেন।

Comments

শেষ অনুচ্ছেদে আপডেট এবং আমেনের জন্য আপনাকে ধন্যবাদ।

— নীতিবাক্য

সুতরাং নতুন পরিবর্তনগুলির পরে কি এমন কোনও সময় আসে যেখানে weakকোনও জায়গায় ব্যবহার করা যায় না unowned?

— মধু 20

Answer 7

অ্যাপল-ডক অনুসারে

• দুর্বল রেফারেন্সগুলি সর্বদা একটি typeচ্ছিক প্রকারের হয় এবং যখন তারা উল্লেখ করে তা হ'ল স্বয়ংক্রিয়ভাবে নিঃশব্দ হয়ে যায়।

• যদি বন্দী রেফারেন্সটি কখনই শূন্য হয়ে না যায় তবে এটিকে সবসময় দুর্বল উল্লেখের পরিবর্তে অনাবৃত রেফারেন্স হিসাবে ধরা উচিত

উদাহরণ -

    // if my response can nil use  [weak self]
      resource.request().onComplete { [weak self] response in
      guard let strongSelf = self else {
        return
      }
      let model = strongSelf.updateModel(response)
      strongSelf.updateUI(model)
     }

    // Only use [unowned self] unowned if guarantees that response never nil  
      resource.request().onComplete { [unowned self] response in
      let model = self.updateModel(response)
      self.updateUI(model)
     }

Answer 8

উপরের কোনটি যদি বোঝায় না:

TL; ড

ঠিক যেমন implicitly unwrapped optional, আপনি যদি গ্যারান্টি দিতে পারেন যে উল্লেখটি তার ব্যবহারের বিন্দুতে শূন্য হবে না, অযৌক্তিক ব্যবহার করুন। যদি তা না হয় তবে আপনার দুর্বল ব্যবহার করা উচিত।

ব্যাখ্যা:

আমি নীচে নিম্নলিখিতগুলি পুনরুদ্ধার করেছি: দুর্বল অনাবৃত লিঙ্ক । আমি যা জড়ো করেছিলাম তা থেকে, অজানা নিজেরাই নিখুঁত হতে পারে না তবে দুর্বল স্ব হতে পারে এবং অজানা নিজেরাই ঝুঁকির দিকে ঝুঁকতে পারে ... উদ্দেশ্য-সিতে কুখ্যাত কিছু। আশা করি এটা সাহায্য করবে

"অজানা দুর্বল এবং অজানা তথ্যগুলি একইরকম আচরণ করে তবে এক নয়" "

দুর্বল রেফারেন্সগুলির মতো অজানা রেফারেন্সগুলি উল্লেখ করা অবজেক্টের ধরে রাখার গণনা বাড়ায় না । যাইহোক, সুইফট, একটি মালিকহীন রেফারেন্স যুক্ত করে একটি ঐচ্ছিক হচ্ছে সুবিধার । এটি তাদের to চ্ছিক বাঁধাই ব্যবহার করার পরিবর্তে পরিচালনা করা সহজ করে তোলে । এটি সুস্পষ্টভাবে মোড়কযুক্ত বিকল্পগুলির মত নয়। তদতিরিক্ত, অজানা তথ্যসূত্রগুলি শূন্য নয় । এর অর্থ হ'ল যখন বস্তুটি বাতিল হয়ে যায়, তখন এটি পয়েন্টারটি শূন্য করে না। এর অর্থ হ'ল অযৌক্তিক রেফারেন্সগুলির ব্যবহার, কিছু ক্ষেত্রে ঝুঁকিপূর্ণ পয়েন্টারগুলির দিকে পরিচালিত করতে পারে। আপনারা সেখানে উদ্বিগ্ন যে আমার মতো অবজেক্টিভ-সি দিনগুলি মনে রাখবেন, অনাবৃত রেফারেন্স মানচিত্রটি অনিরাপদ_উন্নতিযুক্ত রেফারেন্সগুলিতে।

এখানেই এটি কিছুটা বিভ্রান্তি পায়।

দুর্বল এবং অজানা রেফারেন্স উভয়ই ধরে রাখার পরিমাণ বাড়ায় না।

এগুলি উভয়ই ধরে রাখা চক্র ভাঙ্গতে ব্যবহৃত হতে পারে। সুতরাং আমরা কখন তাদের ব্যবহার করব ?!

অ্যাপলের ডক্স অনুসারে :

“যখনই সেই রেফারেন্সটি তার জীবদ্দশায় কোনও সময় শূন্য হওয়ার জন্য বৈধ হয় তখনই দুর্বল রেফারেন্স ব্যবহার করুন । বিপরীতে, অযৌক্তিক রেফারেন্স ব্যবহার করুন যখন আপনি জানেন যে সূচনাটি আরম্ভের সময় সেট করা হয়ে গেলে এটি কখনই বাতিল হয় না ”"

Answer 9

import UIKit

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.

        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        let controller = storyboard.instantiateViewController(withIdentifier: "AnotherViewController")
        self.navigationController?.pushViewController(controller, animated: true)

    }

}



import UIKit
class AnotherViewController: UIViewController {

    var name : String!

    deinit {
        print("Deint AnotherViewController")
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        print(CFGetRetainCount(self))

        /*
            When you test please comment out or vice versa

         */

//        // Should not use unowned here. Because unowned is used where not deallocated. or gurranted object alive. If you immediate click back button app will crash here. Though there will no retain cycles
//        clouser(string: "") { [unowned self] (boolValue)  in
//            self.name = "some"
//        }
//


//
//        // There will be a retain cycle. because viewcontroller has a strong refference to this clouser and as well as clouser (self.name) has a strong refferennce to the viewcontroller. Deint AnotherViewController will not print
//        clouser(string: "") { (boolValue)  in
//            self.name = "some"
//        }
//
//


//        // no retain cycle here. because viewcontroller has a strong refference to this clouser. But clouser (self.name) has a weak refferennce to the viewcontroller. Deint AnotherViewController will  print. As we forcefully made viewcontroller weak so its now optional type. migh be nil. and we added a ? (self?)
//
//        clouser(string: "") { [weak self] (boolValue)  in
//            self?.name = "some"
//        }


        // no retain cycle here. because viewcontroller has a strong refference to this clouser. But clouser nos refference to the viewcontroller. Deint AnotherViewController will  print. As we forcefully made viewcontroller weak so its now optional type. migh be nil. and we added a ? (self?)

        clouser(string: "") {  (boolValue)  in
            print("some")
            print(CFGetRetainCount(self))

        }

    }


    func clouser(string: String, completion: @escaping (Bool) -> ()) {
        // some heavy task
        DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
            completion(true)
        }

    }

}

আপনি যদি নিশ্চিত না হন [unowned self] তবে ব্যবহার করুন [weak self]