[TOC]

# 前言

本文參考版本為 `2022.3.16f1`

# Import Package 的類型

總而言之，把別人的任何 code 或 assets 放進自己的專案有很多種方式：

1. **簡單暴力**: 總之它在你電腦的某個地方，然後直接複製貼上進你的專案裡 (`ProjectName/Assets/`)。
2. **Unity Asset Store**: 在 [Unity Asset Store](https://assetstore.unity.com/) 選擇了 Add to My Assets，並在專案中 Import。
3. **Unity Registry/Built-in**: 基本上就是選擇 Enable/Disable 和 Install/Remove 即可
4. **從本地 - From disk**: 本地的 Package 裡應有 `package.json` 檔案，選取即可 Import。
5. **從本地 - Import Package**: 選取任何附檔名為 `.unitypackage` 的檔案來 Import 
6. **從 Git URL**: 輸入 GitHub/GitLab 提供的網址就會直接 Import 進來。

# 檔案存取方式的分類

> 平平是 Import，讓專案能使用 Package 的方式卻大不相同

1. **粗暴型**: 把 Package 的內容幾乎或完全照搬進 `ProjectName/Assets/`。
2. **管理型**: 把 Package 的基本資訊記錄在 `ProjectName/Packages/` 的文檔中，同時把部分實質內容放在 `ProjectName/Library/PackageCache/` 裡。
3. **我不管型**: Package 的實質內容存在你電腦的某個位置，`ProjectName/Packages` 只存放該位置的路徑。

以下為各 Import 類型的對應存取方式：

| | 粗暴型 | 管理型 | 我不管型 |
| -------- | -------- | -------- | -------- |
| **簡單暴力** | :heavy_check_mark: |||
| **Unity Asset Store** |:heavy_check_mark:|||
| **Unity Registry/Built-in** ||:heavy_check_mark:||
| **從本地 - From disk** |||:heavy_check_mark:|
| **從本地 - Import Package** |:heavy_check_mark:|||
| **從 Git URL** ||:heavy_check_mark:||

## 三種方式的優缺點

需要考慮的因素可能有以下幾點：

- 專案大小是否受較大影響？例如我十個專案都用到同一個套件，可能就不希望有十份一樣的檔案分散在十個專案中。其中又分
- 本地專案大小
- Github/Gitlab 等等的版本控制專案大小
- 套件有新版本時是否能方便的更新套件
- 是否方便版本控制？若版本控制專案不完全包含套件內容，方便在 clone 後加入嗎？
- 在 Unity editor 中是否好檢索？專案列在 `/Packages/` 裡會比直接塞在 `/Assets/` 舒服。
- 想修改 Package 內的內容是否簡單？

| | 粗暴型 | 管理型 | 我不管型 |
| -------- | -------- | -------- | -------- |
| 本地專案小 | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_check_mark: |
| 版本控制專案小 |:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|
| 方便更新套件 |:heavy_check_mark:|:heavy_check_mark:|:heavy_multiplication_x:|
| 方便版本控制 |:heavy_check_mark:|:heavy_check_mark:|:heavy_multiplication_x:|
| 好檢索 |:heavy_multiplication_x:|:heavy_check_mark:|:heavy_check_mark:|
| 容易修改 |:heavy_check_mark:|:heavy_multiplication_x:|:heavy_multiplication_x:|

# 所以我該用哪種啦

1. 需要版本控制嗎？
- 需要。前往問題 2.
- 不需要。使用 **從本地 - From disk**，所有檔案都不會被無意義的複製而浪費空間，你將會是空間管理大師。
- 若為 **Unity Asset Store** 的資源，可 Import 後 選擇 **Aseets > Export Package** 把該內容包成本地套件，再使用 **從本地 - From disk** 引入
- 若為 **Git URL** 的資源，可先 clone 到本地再使用 **從本地 - From disk** 引入
2. 套件多/大嗎？
- 是。前往問題 3.
- 否。那保持該套件應有的引入方式吧，**粗暴型**就讓它是**粗暴型**就好。
3. 套件是自己的或 Git URL 的嗎？
- 是。那自己的內容可以考慮 Push 上 GitHub 再用 **從 Git URL** 引入。
- 否。不外乎是**粗暴型**吧，那至少*小心的維護它們*。

## 小心的維護粗暴型套件

當 `Assets/` 裡越塞越多套件時，可能會有以下問題：

- 當初自己的資料夾 `Scripts` 等等很難找
- 外部套件的不良習慣使你編譯更久或 Console 被寫一些你不在意的東西
- 注意大型的多媒體資源(texture, audio, image, video, mesh)，不該直接受 git 管理
- **Unity Asset Store** 引入及更新時總是放到 `Assets/` 這個根目錄，因此把粗暴型套件丟進另開的資料夾 (例如 `Assets/ExternalAssets/`) 其實不太方便
- 但也確實有人是這樣選擇的，tradeoff 的問題，很看人

解決方法：

- 把自己的東西放在 `Assets/_project/` 底下
- 底線是讓該資料夾被排序在最頂部
- 總是只引入套件中真正需要的部分
- 注意要用 [Git LFS](https://git-lfs.com/) 來追蹤多媒體資源
- 注意 C# script 多的套件是否有自己的 [assembly definition](https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html)

# 其它注意事項

## Unity 偷塞一堆你用不到的套件

若選擇 Unity 內建的專案模板，可以看到 Built-in 已經有一堆套件，而若你確定遊戲定位，很多其實用不到

- 編譯時間更長！
- 專案更大！

因此，試著了解各個 module 的用途，該砍的砍一砍，幫專案瘦身，甚至建立自己的專案模板吧。

## 一個專案很久不開了考慮把 cache 刪了吧

把 `ProjectName/Library` 整個資料夾砍了，Unity 有能力在打開專案時檢查並完全復原必要的資訊

# 結語

- 筆者上一個協作專案的套件被引入的亂七八糟，想找個 script 都要在資料夾翻半天，因此憤而查清楚而有了這篇文。
- 這篇又和一些 Unity 專案管理或 Git 專案管理有關，有空來補充