You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Analyzer is an API that can be used to analyze the content of Unity data files such as AssetBundles and SerializedFiles. It iterates through all the serialized objects and uses the TypeTree to extract useful information about these objects (e.g. name, size, etc.) The extracted information is stored in a SQLite database. It is possible to extract type-specific properties using specialized processors and some are included in this library.
3
+
The Analyzer is a class library that can be used to analyze the content of Unity data files such
4
+
as AssetBundles and SerializedFiles. It iterates through all the serialized objects and uses the
5
+
TypeTree to extract information about these objects (e.g. name, size, etc.)
6
+
7
+
The extracted information is forwarded to an object implementing the [IWriter](./IWriter.cs)
8
+
interface. The library provides the [SQLiteWriter](./SQLite/SQLiteWriter.cs) implementation that
9
+
writes the data into a SQLite database.
10
+
11
+
It is possible to extract type-specific properties using classes inheriting from the
12
+
[SerializedObject](./SerializedObjects/SerializedObject.cs) class. The project already provides
13
+
the most common SerializedObject implementations in the [SerializedObjects](./SerializedObjects)
14
+
folder.
4
15
5
16
# How to use the library
6
17
7
-
The AnalyzerTool class is the API entry point. The main method is called Analyze. It takes four parameters:
8
-
* path (string): path of the folder where the files to analyze are located. It will be searched recursively.
18
+
The [AnalyzerTool](./AnalyzerTool.cs) class is the API entry point. The main method is called
19
+
Analyze. It is currently hardcoded to write using the [SQLiteWriter](./SQLite/SQLiteWriter.cs),
20
+
but it can easily be adapter to use another writer type. It takes four parameters:
21
+
* path (string): path of the folder where the files to analyze are located. It will be searched
22
+
recursively.
9
23
* databaseName (string): database filename, it will be overwritten if it already exists.
* extractReferences (bool): determines if the references (PPtrs) must be extracted and saved in the 'refs' table.
12
-
Calling this method will create the SQLite output database and will recursively process the files matching the search pattern in the provided path. It will add a row in the 'objects' table for each serialized object. This table contain basic information such as the size and the name of the object (if it has one).
13
-
14
-
It is possible to extract more information from specific types of objects by adding processors using the AddProcessor method before calling Analyze. The processors must implement the IProcessor interface. Some processors are provided in the Processors folder:
15
-
* AnimationClipProcessor
16
-
* AssetBundleProcessor
17
-
* AudioClipProcessor
18
-
* MeshProcessor
19
-
* ShaderProcessor
20
-
* Texture2DProcessor
21
-
They are not added by default when creating a new instance of the AnalyzerTool class.
25
+
* extractReferences (bool): determines if the references (PPtrs) must be extracted and saved in
26
+
the 'refs' table. Calling this method will create the SQLite output database and will recursively
27
+
process the files matching the search pattern in the provided path. It will add a row in
28
+
the 'objects' table for each serialized object. This table contain basic information such as the
29
+
size and the name of the object (if it has one).
22
30
23
31
# How to use the database
24
32
25
-
A tool such as the [DB Browser for SQLite](https://sqlitebrowser.org/) is required to look at the content of the database. The database provides different views that can be used to easily find the information you might need.
33
+
A tool such as the [DB Browser for SQLite](https://sqlitebrowser.org/) is required to look at the
34
+
content of the database. The database provides different views that can be used to easily find the
35
+
information you might need.
26
36
27
37
## object_view
28
38
29
-
This is the main view where the information about all the objects in the AssetBundles is available. Its columns are:
39
+
This is the main view where the information about all the objects in the AssetBundles is available.
40
+
Its columns are:
30
41
* id: a unique id without any meaning outside of the database
31
-
* object_id: the Unity object id (unique inside its SerializedFile but not necessarily acros all AssetBundles)
32
-
* asset_bundle: the name of the AssetBundle containing the object (will be null if the source file was a SerializedFile and not an AssetBundle)
42
+
* object_id: the Unity object id (unique inside its SerializedFile but not necessarily acros all
43
+
AssetBundles)
44
+
* asset_bundle: the name of the AssetBundle containing the object (will be null if the source file
45
+
was a SerializedFile and not an AssetBundle)
33
46
* serialized_file: the name of the SerializedFile containing the object
34
47
* type: the type of the object
35
48
* name: the name of the object, if it had one
@@ -43,23 +56,35 @@ This view lists the total number and size of the objects, aggregated by type.
43
56
44
57
## view_potential_duplicates
45
58
46
-
This view lists the objects that are possibly included more than once in the AssetBundles. This can happen when an is referenced from multiple AssetBundles but not assigned to one. In this case, Unity will include the asset in all the AssetBundles with a reference to it. The view provides the number of instances and the total size of the potentially duplicated assets. It also lists all the AssetBundles where the asset was found.
59
+
This view lists the objects that are possibly included more than once in the AssetBundles. This can
60
+
happen when an asset is referenced from multiple AssetBundles but is not assigned to one. In this
61
+
case, Unity will include the asset in all the AssetBundles with a reference to it. The
62
+
view_potential_duplicates provides the number of instances and the total size of the potentially
63
+
duplicated assets. It also lists all the AssetBundles where the asset was found.
47
64
48
-
It is important to understand that there is a lot of false positives in that view. All the objects having an identical name, size and type are reported as potential duplicates. For example, if several animated characters have a bone GameObject named "Hand_L" they will all be reported as potential duplicates even if they are not part of the same object.
65
+
It is important to understand that there is a lot of false positives in that view. All the objects
66
+
having an identical name, size and type are reported as potential duplicates. For example, if
67
+
several animated characters have a bone GameObject named "Hand_L", they will all be reported as
68
+
potential duplicates even if they are not part of the same object.
49
69
50
70
## asset_view (AssetBundleProcessor)
51
71
52
-
This view lists all the assets that have been explicitely assigned to AssetBundles. The dependencies that were automatically added by Unity at build time won't appear in this view. The columns are the same as those in the *object_view* with the addition of the *asset_name* that contains the filename of the asset.
72
+
This view lists all the assets that have been explicitly assigned to AssetBundles. The dependencies
73
+
that were automatically added by Unity at build time won't appear in this view. The columns are the
74
+
same as those in the *object_view* with the addition of the *asset_name* that contains the filename
75
+
of the asset.
53
76
54
77
## animation_view (AnimationClipProcessor)
55
78
56
-
This provides additional information about AnimationClips. The columns are the same as those in the *object_view*, with the addition of:
79
+
This provides additional information about AnimationClips. The columns are the same as those in
80
+
the *object_view*, with the addition of:
57
81
* legacy: 1 if it's a legacy animation, 0 otherwise
58
82
* events: the number of events
59
83
60
84
## audio_clip_view (AudioClipProcessor)
61
85
62
-
This provides additional information about AudioClips. The columns are the same as those in the *object_view*, with the addition of:
86
+
This provides additional information about AudioClips. The columns are the same as those in
87
+
the *object_view*, with the addition of:
63
88
* bits_per_sample: number of bits per sample
64
89
* frequency: sampling frequency
65
90
* channels: number of channels
@@ -68,7 +93,8 @@ This provides additional information about AudioClips. The columns are the same
68
93
69
94
## mesh_view (MeshProcessor)
70
95
71
-
This provides additional information about Meshes. The columns are the same as those in the *object_view*, with the addition of:
96
+
This provides additional information about Meshes. The columns are the same as those in
97
+
the *object_view*, with the addition of:
72
98
* sub_meshes: the number of sub-meshes
73
99
* blend_shapes: the number of blend shapes
74
100
* bones: the number of bones
@@ -79,30 +105,68 @@ This provides additional information about Meshes. The columns are the same as t
79
105
80
106
## texture_view (Texture2DProcessor)
81
107
82
-
This provides additional information about Texture2Ds. The columns are the same as those in the *object_view*, with the addition of:
108
+
This provides additional information about Texture2Ds. The columns are the same as those in
109
+
the *object_view*, with the addition of:
83
110
* width/height: texture resolution
84
111
* format: compression format
85
112
* mip_count: number of mipmaps
86
113
* rw_enabled: 1 if the mesh has the *R/W Enabled* option, 0 otherwise
87
114
88
115
## shader_view (ShaderProcessor)
89
116
90
-
This provides additional information about Shaders. The columns are the same as those in the *object_view*, with the addition of:
91
-
* decompressed_size: the size in bytes that this shader will need at runtime when loaded
117
+
This provides additional information about Shaders. The columns are the same as those in
118
+
the *object_view*, with the addition of:
119
+
* decompressed_size: the approximate size in bytes that this shader will need at runtime when
120
+
loaded
92
121
* sub_shaders: the number of sub-shaders
93
122
* sub_programs: the number of sub-programs (usually one per shader variant, stage and pass)
94
-
* unique_programs: the number of unique program (variants with identical programs will share the same program in memory)
123
+
* unique_programs: the number of unique program (variants with identical programs will share the
124
+
same program in memory)
95
125
* keywords: list of all the keywords affecting the shader
96
126
97
127
## shader_subprogram_view (ShaderProcessor)
98
128
99
-
This view lists all the shader sub-programs and has the same columns as the *shader_view* with the addition of:
129
+
This view lists all the shader sub-programs and has the same columns as the *shader_view* with the
130
+
addition of:
100
131
* api: the API of the shader (e.g. DX11, Metal, GLES, etc.)
101
132
* pass: the pass number of the sub-program
133
+
* pass_name: the pass name, if available
134
+
* hw_tier: the hardware tier of the sub-program (as defined in the Graphics settings)
135
+
* shader_type: the type of shader (e.g. vertex, fragment, etc.)
136
+
* sub_program: the subprogram index for this pass and shader type
137
+
* keywords: the shader keywords specific to this sub-program
138
+
139
+
## shader_keyword_ratios
140
+
141
+
This view can help to determine which shader keywords are causing a large number of variants. To
142
+
understand how it works, let's define a "program" as a unique combination of shader, subshader,
143
+
hardware tier, pass number, API (DX, Metal, etc.), and shader type (vertex, fragment, etc).
144
+
145
+
Each row of the view corresponds to a combination of one program and one of its keywords. The
146
+
columns are:
147
+
148
+
* shader_id: the shader id
149
+
* name: the shader name
150
+
* sub_shader: the sub-shader number
102
151
* hw_tier: the hardware tier of the sub-program (as defined in the Graphics settings)
152
+
* pass: the pass number of the sub-program
153
+
* api: the API of the shader (e.g. DX11, Metal, GLES, etc.)
154
+
* pass_name: the pass name, if available
103
155
* shader_type: the type of shader (e.g. vertex, fragment, etc.)
104
-
* prog_keywords: the shader keywords specific to this sub-program
156
+
* total_variants: total number of variants for this program.
157
+
* keyword: one of the program's keywords
158
+
* variants: number of variants including this keyword.
159
+
* ratio: variants/total_variants
160
+
161
+
The ratio can be used to determine how a keyword affects the number of variants. When it is equal
162
+
to 0.5, it means that it is in half of the variants. Basically, that means that it is not stripped
163
+
at all because each of the program's variants has a version with and without that keyword.
164
+
Therefore, keywords with a ratio close to 0.5 are good targets for stripping. When the ratio is
165
+
close to 0 or 1, it means that the keyword is in almost none or almost all of the variants and
166
+
stripping it won't make a big difference.
105
167
106
168
## view_breakdowns_shaders (ShaderProcessor)
107
169
108
-
This view lists all the shaders aggregated by name. The *instances* column indicates how many time the shader was found in the data files. It also provides the total size per shader and the list of AssetBundles in which they were found.
170
+
This view lists all the shaders aggregated by name. The *instances* column indicates how many time
171
+
the shader was found in the data files. It also provides the total size per shader and the list of
0 commit comments