這個md文檔一月份就創建了，一直沒填坑。
雖然應用本身不是什麼成功的應用，但是自己感覺在做的過程中還是有挺多收穫的。
注意： 本文不會非常詳細的說明具體類的使用方法，代碼具體怎麼寫，這些官方文檔比任何人都說的清楚。
目的在於對於個人開發者提供一個思路。
大多個人開發者，比如我自己，資源時間精力有限，但是想法很多。
而iCloud是我遇到最合適用來構建起用戶體系，以及拓展功能需求的工具了。
自己已經獨立做了兩款應用，都是基於iCloud建立起來的，歡迎體驗反饋，要是再來個五星好評是對我最大的鼓勵~
記帳：夢見帳本（長按識別）
遊戲：掃雷Elic-無盡天梯（長按識別）
哎，沒有設計師自己整UI終究還是不太好看啊~TAT~
下面會以掃雷項目中的例子來做一些說明
二、獨立項目用戶體系技術方案選型2.1 自己開發也不是沒考慮過，但不是自己所擅長的。而且需要考慮的問題太多，技術、運維、安全都是需要考慮的。
當然如果有大佬這些都能搞定的話，這是最好的方案了。
2.2 LeanCloud早期有用這家的服務寫過Demo，所以選型的時候也有考慮他家的服務，畢竟後期拓展到不同的平臺沒有障礙。
但是收費限制多，具體可以自行去查看。Pass
2.3 GameCenter很早以前有研究過一下，就如其名蘋果系統內部的一套遊戲用戶體系。
包含了用戶、排行榜、成就點之類的比較基礎的功能。
雖然很多遊戲都有接入，但是存在感實在不高。
就我對GameCenter淺薄的了解來說，要拓展功能業務的話，只依靠CameCenter的話是很難支撐起來的，依舊需要另一套東西來承載。
所以Pass掉了。
2.4 iCloud大家初步對iCloud的認識可能停留在可以備份同步照片文件的基礎上。
這裡建立用戶體系依靠的是CloudKit，建議直接閱讀官方文檔，想知道的都有。
官方文檔：CloudKit: https://developer.apple.com/documentation/cloudkit
三、什麼是CloudKitStore structured app and user data in iCloud containers that all users of your app can share.
The CloudKit framework provides interfaces for moving data between your app and your iCloud containers. You use CloudKit to store your app’s existing data in the cloud so that the user can access it on multiple devices. You can also store data in a public area where all users can access it.
上面是官方文檔中對CloudKit的說明，比較重要的一句 You can also store data in a public area where all users can access it.。
數據可共享是建立起用戶體系的核心。
推薦蘋果的官方文章，根據自身場景，選擇合適的接入方案「Determining If CloudKit Is Right for Your App」: https://developer.apple.com/documentation/cloudkit/determining_if_cloudkit_is_right_for_your_app
四、CloudKit存儲數據的方式CloudKit控制面板: https://icloud.developer.apple.com/dashboard/
進入DataBase，對核心的幾塊內容做一下說明：
4.1 基礎數據單元：CKRecord所有數據都是由CKRecord承載，存儲在容器中的。
值得注意的是，只要用戶開啟啦iCloud及iCloudDrive服務。
支持的數據類型如下，這是官方注釋裡面的：
/// Acceptable value object classes are:
/// - `String`
/// - `Date`
/// - `Data`
/// - `Bool`
/// - `Int`
/// - `UInt`
/// - `Float`
/// - `Double`
/// - `[U]Int8 et al`
/// - `CKReference / CKRecord.Reference`
/// - `CKAsset`
/// - `CLLocation`
/// - `NSData`
/// - `NSDate`
/// - `NSNumber`
/// - `NSString`
/// - `Array` and/or `NSArray` containing objects of any of the types above
///
/// Any other classes will result in an exception with name `NSInvalidArgumentException`.
///
/// Field keys starting with `_` are reserved. Attempting to set a key prefixed with a `_` will result in an error.
///
/// Key names roughly match C variable name restrictions. They must begin with an ASCII letter and can contain ASCII letters and numbers and the underscore character.
/// The maximum key length is 255 characters.
CKRecord本身包含了一些基礎欄位比如創建者id、創建時間、修改時間、記錄id等。
當然我們也可以自定義欄位，讀寫起來就和使用字典類似。具體可以點進CKRecord文件查看，這裡就不再多說了。
4.2 數據存儲空間：Zone這裡就是三個不同訪問權限的資料庫，通過CKContainer訪問。
a.Public掃雷用的是這個資料庫，因為包含了排行榜，需要所有用戶都可以訪問。
下面是相關的兩段官方說明：
* Records in a public database
* - By default are world readable, owner writable.
* - Can be locked down by Roles, a process done in the Developer Portal, a web interface. Roles are not present in the client API.
* - Are visible to the application developer via the Developer Portal.
* - Do not contribute to the owner's iCloud account storage quota.
This database is available regardless of whether the user’s device has an iCloud account. The contents of the public database are readable by all users of the app, and users have write access to the records, and other objects, they create. The public database’s contents are visible in the developer portal, where you can assign roles to users and restrict access as necessary.
Data in the public database counts toward your app’s iCloud storage quota.
默認只有所有者可讀寫
開發者在後臺也無法訪問
佔用所有者的iCloud存儲空間
這個適合做一些私密性較強的應用，比如密碼管理應用。
* Records in a private database
* - By default are only owner readable and owner writable.
* - Are not visible to the application developer via the Developer Portal.
* - Are counted towards the owner's iCloud account storage quota.
只對通過CKShare授權的合作者可見
開發者在後臺也無法訪問
佔用組織者的iCloud儲存空間
這個沒具體用過，先不深入探討。
* Records in a shared database
* - Are available to share participants based on the permissions of the enclosing CKShare
* - Are not visible to the application developer via the Developer Portal.
* - Are counted towards the originating owner's iCloud account storage quota.
User是默認就存在的一張表，無須自己創建。如果用戶安裝了你的應用，你去獲取用戶對象的時候CloudKit後臺會自動生成一條記錄。是不是很方便？
根據掃雷Elic的需求場景，我創建了這些表
User(default)：用戶
AvatarSpace：頭像
EndLessRank：無盡模式排行榜
GameHistory：遊戲記錄
AppConfig：應用配置
ZenRank：「禪」模式排行榜
添加自定義欄位點進對應Type後就可以看到表結構了，上面一半是默認的數據結構。在下方點+可以添加自定義的欄位，並選擇數據類型。
需要注意的是：在測試環境下，新增的欄位可以刪除掉。一旦發布線上後，就不能刪除了。只能新增。
4.4 數據索引：IndexsQUERYABLE
SORTABLE
SEARCHABLE
根據需求進行設置，不設置的話會讀不到數據的。
效果：
雖然沒有絕對的安全，但對比市面上的雲存儲服務。蘋果的還是相對讓我放心的。
關鍵是便宜啊！
5.2 要是用戶抓包改數據呢？我試過抓包，直接連不上容器了。感興趣的可以嘗試一下。
5.3 破解？寫到這裡了我掏出了我的越獄機。。。說幹就幹，砸一個出來重籤。
好傢夥，直接崩了，挺安全的了吧？
當然我並沒有深究能不能跳過系統這一步的驗證，等薩爾有下了再來研究下。
我也還沒做防Hook，有興趣破解一下的也可以找我交流哈，十分歡迎。
5.4 訪問速度說不上非常快，但是夠用。主要還是要合理設計表結構，要是在列表的數據結構裡直接包含資源文件的話，那請求速度和用戶體驗就慘不忍睹了。
5.5 運維成本幾乎談不上運維，咱也做不了什麼。作為開發者能做的就是把應用邏輯和數據結構設計得合理一些。
一些基礎的運維數據在後臺也是可以看到的。
5.6 跨平臺只做iOS平臺還好，要是以後想拓展到不同平臺的話，是不是就用不成了？難道還要單獨搞一套，甚至遷移用戶？
放心，蘋果貼心的提供了APICloudKit JS(https://developer.apple.com/documentation/cloudkitjs)
具體沒研究，看起來是可以做跨平臺的。
5.7 容量1PB夠用不？
抱歉，我剛看到這個單位的第一時間沒反應過來。
就是1024TB，真沒想到。
不是一下子就有1P，隨著你用戶的量級來的。
開發者需要關心的只有Public database所佔用的大小。
Build Apps Using CloudKit https://developer.apple.com/icloud/cloudkit/
5.8 資源存儲 CKAssetCloudKit提供了CKAsset這個數據類型用來保存一些資源文件，可以放在CKRecord中進行保存。
看起來挺方便。
問題如掃雷的排行榜功能，是需要顯示頭像的。
這裡如果將頭像直接添加為User表中，那麼實際拉取用戶的時候會很慢，因為這裡會把圖片資源一起帶下來。而不是我們平時的Url的形式。
如果將圖片傳到圖床上然後添加圖片Url的欄位也是ok的，但近年來感覺圖床限制越來越多了，不方便使用。
這裡我後面單獨鍵了張表用來存頭像資源，然後封裝了一個加載、緩存CKAsset圖片資源的工具，方便在排行版中使用。
七、總結iCloud對於個人開發者來說是個好東西，可以低成本的構建用戶體系。
只要發揮想像力，很多功能都是可以可以做的。
這裡我用到的只是CloudKit的一部分，還有很多沒用過。也許還存在很多的發掘空間。
八、參考CloudKit: https://developer.apple.com/documentation/cloudkit
Designing apps using CloudKit.: https://developer.apple.com/icloud/cloudkit/designing/
Build Apps Using CloudKit: https://developer.apple.com/icloud/cloudkit/
CloudKit JS
Determining If CloudKit Is Right for Your App: https://developer.apple.com/documentation/cloudkit/determining_if_cloudkit_is_right_for_your_app