|
難度：高級(jí) This section of the Optimizing Unity UIguide focuses on issues specific to certain types of UI controls. While most UIcontrols are relatively similar in terms of performance, two stand out as beingthe causes of many of the performance issues encountered in games close to ashippable state. Unity UI優(yōu)化指南的這部分關(guān)注與特定的一些UI控件。雖然大部分的UI控件在性能上都比較相似，下面這兩個(gè)控件在游戲中導(dǎo)致很多性能問題。 UI TEXT UI文本 Unity’s built-in Text component is aconvenient way of displaying rasterized text glyphs within a UI. However, thereare a number of behaviors that are not commonly known, yet frequently appear asperformance hotspots. When adding text to a UI, always remember that the textglyphs are actually rendered as individual quads, one per character. Thesequads tend to have a significant amount of empty space surrounding the glyph,depending on its shape, and it is very easy to position text in such a way thatit unintentionally breaks the batching of other UI elements. Unity內(nèi)置的文本組件是一個(gè)在UI中顯示光柵化文本，很方便的方法。然而，也有一些通常不知道的行為，經(jīng)常出現(xiàn)性能熱點(diǎn)的行為。當(dāng)給一個(gè)UI添加文本時(shí)，永遠(yuǎn)記住，每個(gè)字符實(shí)際上會(huì)被渲染成一個(gè)看不見的多邊形?；诙噙呅蔚男螤睿鼤?huì)有在多邊形周圍有個(gè)空的空間，很簡(jiǎn)單地設(shè)置文本的位置，這樣會(huì)無(wú)意的打破UI元素的batching。 Text meshrebuilds 文本網(wǎng)格重建 One major issue is the rebuilding of UItext meshes. Whenever a UI Text component is changed, the text component mustrecalculate the polygons used to display the actual text. This recalculationalso occurs if a text component, or any of its parent GameObjects, is simplydisabled & re-enabled without changes to the text. 一個(gè)主要的問題是UI文本網(wǎng)格的重建。每當(dāng)UI文本組件改變時(shí)，文本組件必須重新計(jì)算用來(lái)顯示文本的的多邊形。如果一個(gè)文本組件或者任何它的父物體沒有改變?nèi)魏挝谋荆皇呛?jiǎn)單的禁用和重新啟動(dòng)時(shí)，重新計(jì)算也會(huì)發(fā)生。 This behavior is problematic for any UIthat displays large numbers of textual labels, with the most common beingleaderboards or statistics screens. As the most common way to hide and show aUnity UI is to enable/disable a GameObject containing the UI, UIs with largenumbers of text components will often cause undesirable frame-rate hiccupswhenever they are displayed. 這個(gè)行為是任何用來(lái)顯示大量文本Label 的UI，最常見的問題。作為最常見的隱藏和顯示Unity UI的方法，是啟動(dòng)和禁用一個(gè)包含UI的物體。當(dāng)顯示一個(gè)帶有大量文本組件的UI時(shí)，會(huì)經(jīng)常導(dǎo)致不希望的卡幀。 For a potential workaround to this issue,see the Disabling Canvas Renderers section in the next chapter. 對(duì)于這個(gè)問題的解決方案，請(qǐng)查看下一節(jié)的Disabling Canvas Renderers部分。 Dynamic fontsand font atlases 動(dòng)態(tài)字體和字體圖集 Dynamic fonts are a convenient way todisplay text when the full displayable character set is either very large, ornot known prior to runtime. In Unity’s implementation, these fonts build aglyph atlas at runtime based on the characters encountered within UI Textcomponents. 當(dāng)字符很大或則運(yùn)行前不確定時(shí)，動(dòng)態(tài)字體是顯示字體很方便的方法。在Unity的實(shí)現(xiàn)中，這些字體在運(yùn)行時(shí)基于文本UI組件遇到的字符，創(chuàng)建一個(gè)圖形集。 Each distinct Font object loaded willmaintain its own texture atlas, even if it is in the same font family asanother font. For example, using Arial with bolded text on one control whileusing Arial Bold on another control will produce identical output but Unitywill maintain two distinct texture atlases — one for Arial and one for ArialBold. 每個(gè)加載的不同的文字對(duì)象都會(huì)保持它自己的紋理圖集，即使它是同一種字體。例如，在一個(gè)控件上使用Arial和加粗文字，而在另一個(gè)控件上使用Arial加粗文字，都會(huì)產(chǎn)生相同的輸出，但是Unity會(huì)保持兩個(gè)不同的紋理圖集—一個(gè)個(gè)Arial，一個(gè)給Arial Bold。 From a performance perspective, the mostimportant thing to understand is that Unity UI’s dynamic fonts maintain oneglyph in the font’s texture atlas for each distinct combination of size, style& character. That is, if a UI contains two text components, both displayingthe letter ‘A’, then: 從性能角度，最重要的事是，Unity UI的動(dòng)態(tài)字體給每個(gè)大小，風(fēng)格和字符不同組合，在字體紋理圖集中保持了一個(gè)圖形。也就是說，如果一個(gè)UI包含兩個(gè)文本組件，兩個(gè)都顯示“A”，那么： If the two Text components share the same size, the fontatlas will have one glyph in it. 如果兩個(gè)組件共享相同的大小，那么字體圖集將只有一個(gè)圖形。 If the two Text components do not share the same size(e.g. one is 16-point, the other 24-point), then the font atlas will containtwo copies of the letter ‘A’ at different sizes. 如果兩個(gè)組件不共享一樣的大?。ū热缫粋€(gè)是16，一個(gè)是24），那么文字圖集將有兩個(gè)不同大小的“A”的副本。 If one Text component is bold and the other is not, thenthe font atlas will contain a bold 'A' and a regular 'A'. 如果一個(gè)文本組件是粗體，一個(gè)不是，那么字體圖集將包含一個(gè)粗體的“A”，一個(gè)常規(guī)的“A”。 Whenever a UI Text object with a dynamicfont encounters a glyph that has not yet been rasterized into the font’stexture atlas, the font’s texture atlas must be rebuilt. If the new glyph fitsinto the current atlas, it is added and the atlas re-uploaded to the graphicsdevice. However, if the current atlas is too small, then the system attempts torebuild the atlas. It does this in two stages. 每當(dāng)使用動(dòng)態(tài)字體的UI文本對(duì)象，遇到?jīng)]有光柵化到文本紋理圖集的圖形時(shí)，文本紋理圖集必須要重建。如果新的圖形適合現(xiàn)在的圖集，它被添加，圖集重新上傳到圖形設(shè)備。但是，如果當(dāng)前的圖集太小，系統(tǒng)會(huì)嘗試重建圖集。它會(huì)用兩階段做這件事。 First, the atlas is rebuilt at the samesize, using only the glyphs currently being shown by active UIText(1) components. If the system succeeds infitting all currently-in-use glyphs into a new atlas, it rasterizes that atlasand does not continue to the second step. 首先，圖集重建相同大小的圖集，僅適用通過UI文本組件目前正在顯示的圖形。如果系統(tǒng)成功將所有現(xiàn)在正在使用的圖形加入一個(gè)新的圖集，它柵格化圖集，并不會(huì)繼續(xù)第二步。 Second, if the set of currently-in-useglyphs cannot be fit into an atlas of the same size as the current atlas, alarger atlas is created by doubling the atlas’ shorter dimension. For example,a 512x512 atlas expands into 512x1024 atlas. 其次，如果現(xiàn)在使用的圖形不能放入一個(gè)和現(xiàn)在圖形大小一樣的圖集，通過加倍當(dāng)前圖集大小，一個(gè)更大的圖集被創(chuàng)建。例如，一個(gè)512*512的圖集，會(huì)擴(kuò)展為512*1024的圖集。 Due to the above algorithm, a dynamicfont’s atlas will only grow in size once created. Given the cost of rebuildingthe texture atlases, it is imperative to minimize during rebuilds. This can bedone in two ways. 由于上述的算法，一個(gè)動(dòng)態(tài)的文字圖集創(chuàng)建的時(shí)候，只會(huì)增加一次大小。鑒于重建紋理圖集的成本，就必須在重建過程中盡量減少重建紋理圖集。這可以通過兩種方式來(lái)完成。 Whenever possible, use non-dynamic fontsand preconfigure support for the desired glyph set. This generally works wellfor UIs using a well-constrained character set, such as only the Latin/ASCIIcharacters, and with a small range of sizes. 盡可能使用非動(dòng)態(tài)字體和預(yù)配置所需字形。這通?？梢院芎弥С质褂靡粋€(gè)完全約束字符集的UI，例如僅Latin/ ASCII字符，并在小范圍。 If an extremely large range ofcharacters must be supported, such as the entire Unicode set, then the fontmust be set to Dynamic. To avoid predictable performance problems, prime thefont’s glyph atlas at startup time with a set of appropriate charactersvia Font.RequestCharactersInTexture. 如果需要支持一個(gè)非常大的范圍，如整個(gè)Unicode集，那么字體必須設(shè)置為動(dòng)態(tài)。以避免性能問題，在啟動(dòng)時(shí)通過一組適當(dāng)?shù)淖址鸉ont.RequestCharactersInTexture事先準(zhǔn)備圖形圖集。 Note that font atlas rebuilds aretriggered individually for each UI Text component that is changed. Whenpopulating an extremely large number of Text components, it may be advantageousto collect all unique characters in the Text components’ content and prime thefont atlas. This will ensure that the glyph atlas need only be rebuilt onceinstead of being rebuilt once each time a new glyph is encountered. 注意文字圖集重建會(huì)在UI文本組件被修改時(shí)被單獨(dú)觸發(fā)。當(dāng)填充一個(gè)非常大的文本組件，它可能收集所有文本組件中不同的字符，加入文字圖集。這會(huì)確保圖形圖集只被重建一次，而不是每遇到新的圖形就重建。 Also note that, when a font atlasrebuild is triggered, any characters that are not presently containedin an active UI Text component will not be present in the new atlas, even ifthey were originally added to the atlas as a result of a call to Font.RequestCharactersInTexture. To workaround this limitation, subscribe to the Font.textureRebuilt delegateand query Font.characterInfo to ensure that alldesired characters remain primed. 還需要注意的是，當(dāng)一個(gè)文字圖集重建被觸發(fā)，調(diào)用 Font.RequestCharactersInTexture，所有沒有在當(dāng)前UI文本組件中顯示的文字都不會(huì)在新的圖集中，即使他們最初已經(jīng)添加在圖集中了。要解決這個(gè)限制，使用Font.textureRebuilt 委托和查詢Font.characterInfo來(lái)確保所有需要的字符保持初始狀態(tài)。 The Font.textureRebuilt delegateis currently undocumented. It is a single-argument Unity Event. The argument is the font whose texturewas rebuilt. Subscribers to this event should follow the following signature: Font.textureRebuilt委托目前沒有記錄在文檔。它是single-argument Unity事件。它主要是為了紋理重建。使用該事件，需要遵循以下要求： public void TextureRebuiltCallback(Font rebuiltFont){/*...*/} Specializedglyph renderers 專業(yè)的字形渲染器 For situations where the glyphs are well-known,with relatively fixed positions between each glyph, it is significantly moreadvantageous to write a custom component to display sprites displaying thoseglyphs. An example of this might be a score display. 總所周知，對(duì)于圖形和每個(gè)固定位置相關(guān)情況，編寫一個(gè)自定義的組件來(lái)顯示精靈顯示這些圖形是很重要的。這樣的一個(gè)例子可能是一個(gè)得分顯示。 For scores, the displayable charactersare drawn from a well-known glyph set (the digits 0-9), do not change acrosslocalities, and appear at fixed distances from one another. It is relativelytrivial to decompose an integer into its digits and display appropriate digitsprites. This sort of specialized digit-display system can be built in a mannerthat is both allocationless and considerably faster to calculate, animate anddisplay than the Canvas-driven UI Text component. 對(duì)于成績(jī)，顯示的字符是從數(shù)字0-9的圖形集，不用跨位置顯示，并在固定位置出現(xiàn)。分解一個(gè)整數(shù)成一個(gè)數(shù)字和恰當(dāng)顯示數(shù)字的精靈，比較繁瑣。這種專業(yè)的數(shù)字顯示系統(tǒng)可以被創(chuàng)建，不需要分配，并且計(jì)算、動(dòng)畫和顯示都比畫布驅(qū)動(dòng)的UI文本組件快。 Fallback fontsand memory usage 后備字體和內(nèi)存使用 For applications that must support a largecharacter-set, it is tempting to list a large number of fonts in the “FontNames” field of a font importer. Any fonts listed in the “Font Names” fieldwill be used as fallbacks if a glyph cannot be located within the primary font.The fallback order is determined by the order in which the fonts are listed inthe “Font Names” field. 對(duì)于必須支持大量字符集的應(yīng)用程序，它會(huì)嘗試將大量的字體列入“Font Names”中。如果一個(gè)圖形不能被位于之前字體內(nèi)，任何列入“Font Names”的字體都會(huì)被作為后備使用。后備順序由“Font Names”中文字的順序決定。 However, in order to support thisbehavior, Unity will keep all fonts listed in the “Font Names” field loadedinto memory. If a font’s character set is very large, then the amount of memoryconsumed by fallback fonts can become excessive. This is most often seen whenincluding pictographic fonts, such as Japanese Kanji or Chinese characters. 但是，為了支持這種行為，Unity會(huì)保持加載內(nèi)存時(shí)，所有的字體都列入“Font Names”中。如果一個(gè)字體的字符集很大，那后備字體的內(nèi)存消費(fèi)會(huì)過大。這中情況在使用象形字體，如日語(yǔ)字體和中文字體時(shí)經(jīng)常遇到。 Best Fit and performance 最佳匹配和性能 In general, the UI Textcomponent's Best Fit setting should never be used. 一般情況下，UI文本組件的最佳匹配設(shè)置不應(yīng)該被使用。 “Best Fit” dynamically adjusts the sizeof a font to the largest integer point size which can be displayed within aText component’s bounding box without overflow, clamped to a configurableminimum/maximum point size. However, because Unity renders a distinct glyphinto the font atlas for each distinct size of character being displayed, use ofBest Fit will rapidly overwhelm the atlas with many different glyph sizes. “Best Fit”動(dòng)態(tài)的調(diào)整字體大小到最大整數(shù)點(diǎn)大小，在文本組件內(nèi)顯示而不出現(xiàn)overflow,介于最小/最大點(diǎn)之間的大小。然而，因?yàn)閁nity會(huì)為顯示的每個(gè)不同大小的字符渲染一個(gè)不同的圖形到字體圖集，使用Best Fit將會(huì)用很多不同大小的圖形，快速填充圖集。 As of Unity 5.3, the size detection usedby Best Fit is nonoptimal. It generates glyphs in the font atlas for each sizeincrement tested, which further increases the amount of time required togenerate font atlases. It also tends to cause atlas overflows, which causes oldglyphs to be kicked out of the atlas. Due to the large number of tests requiredfor a Best Fit calculation, this will often evict glyphs in use by other Textcomponents, and force the font atlas to be rebuilt at least once more after theappropriate font size has been calculated. This specific issue has been correctedin Unity 5.4, and Best Fit will not unnecessarily expand the font's textureatlas, but is still considerably slower than statically-sized text. .3，使用Best Fit來(lái)改變大小不是最佳選擇。它會(huì)給每個(gè)不同大小的文字生成圖形，進(jìn)一步增加生成文字圖集的時(shí)間。由于舊的圖形在圖集中被移除，這也會(huì)導(dǎo)致溢出。由于Best Fit計(jì)算需要大量的測(cè)試，這會(huì)經(jīng)常移除其他文本組件在使用的圖形，并強(qiáng)制圖集在計(jì)算出合適大小字體后，至少被多重建一次 。這種特殊的問題在Unity5.4中已經(jīng)被解決了，Best Fit不必?cái)U(kuò)展字體的紋理圖集，但仍然比靜態(tài)大小的文本慢。 Frequent font atlas rebuilds willrapidly degrade runtime performance as well as cause memory fragmentation. Thegreater the quantity of text components set to Best Fit, the worse this problembecomes. 頻繁的字體圖集重建將迅速降低運(yùn)行效率，也會(huì)導(dǎo)致內(nèi)存碎片。文本組件設(shè)置的Best Fit質(zhì)量越高，問題越嚴(yán)重。 SCROLL VIEWS 滾動(dòng)視圖 After fill-rate problems, Unity UI’sScroll Views are the second most common source of runtime performance issuesseen. Scroll Views generally require a significant number of UI elements torepresent their content. There are two basic approaches to populating a scrollview: 填充率問題后，Unity UI的滾動(dòng)視圖是常見地引起運(yùn)行效率問題的原因。滾動(dòng)視圖需要一些UI元素在它的內(nèi)容顯示。有兩種方法填充一個(gè)滾動(dòng)視圖： · Fill it with all of the elements necessary to representall of the scroll view’s content 用所有需要出現(xiàn)在滾動(dòng)視圖的元素填充滾動(dòng)視圖 · Pool the elements, repositioning them as needed torepresent visible content. 用池處理這些元素，根據(jù)需要重新放置它們的位置 Both of these solutions have issues. 這兩種解決方法都有問題 The first solution requires anincreasing amount of time to instantiate all of the UI elements as the numberof items to be represented increases, and also increases the time required torebuild the Scroll View. If there are only a small number of elements requiredwithin a Scroll View, such as in a Scroll View that only needs to display ahandful of Text components, then this method is favored for its simplicity. 第一個(gè)解決方法，由于被顯示的實(shí)例UI元素增加，需要的時(shí)間會(huì)增加，也增加了重建滾動(dòng)視圖需要的時(shí)間，例如在一個(gè)只需要顯示一些文本組件的滾動(dòng)視圖中，那么這個(gè)方法僅僅因?yàn)樗芎?jiǎn)單而受青睞。 The second solution requires significantamounts of code to implement correctly under the current UI and layout system.Two possible methods will be discussed in further detail below. For anysignificantly complex scrolling UI, some sort of pooling approach is generallyneeded to avoid performance problems. 第二個(gè)解決方法，需要一定的代碼，基于當(dāng)前的UI和布局系統(tǒng)，正確的執(zhí)行。兩種可能的方法將在下面詳細(xì)地討論。對(duì)于任何相對(duì)復(fù)雜的滾動(dòng)界面，需要一些池方法來(lái)避免性能問題。 Despite these issues, all approaches canbe improved by adding a RectMask2D component to the Scroll View. This component ensures that ScrollView elements that are outside of the Scroll View’s viewport are not includedin the list of drawable elements that must have their geometry generated,sorted and analyzed when rebuilding a Canvas. 盡管存在這些問題，所有的方法可以通過給滾動(dòng)視圖添加一個(gè)RectMask2D組件來(lái)提高。該組件確保在滾動(dòng)視圖窗口外面的滾動(dòng)視圖元素不會(huì)出現(xiàn)在可畫的元素列表中，當(dāng)重建一個(gè)畫布時(shí)，該列表的幾何體必須已經(jīng)生成，排序和分析。 Simple ScrollView element pooling 簡(jiǎn)單滾動(dòng)視圖元素集池 The simplest way to implement objectpooling with a Scroll View while also preserving as much of the nativeconvenience of using Unity’s built-in Scroll View component is to take a hybridapproach: 滾動(dòng)視圖實(shí)現(xiàn)對(duì)象池最簡(jiǎn)單的，同時(shí)盡量保留Unity內(nèi)置滾動(dòng)視圖組件便利的方法，是采用混合的方法。 To lay out the elements in the UI, whichwill allow the layout system to properly calculate the size of the ScrollView’s content and allows scrollbars to function properly, use GameObjectswith Layout Element components as “placeholders” forthe visible UI elements. 在UI中布局元素，將允許布局系統(tǒng)合適地使用對(duì)象Layout Element組件，作為看得見的UI元素的“placeholders”。 Then, instantiate a pool of visible UIelements sufficient to fill the visible portion of the Scroll View's visiblearea, and parent these to the positioning placeholders. As the Scroll Viewscrolls, reuse the UI elements to display content that has scrolled into view. 然后，給可見UI元素實(shí)例一個(gè)池，來(lái)填充滾動(dòng)視圖看可見區(qū)域的課件部分，作為父物體來(lái)定位placeholders。由于滾動(dòng)視圖，重用UI元素來(lái)顯示可以滾動(dòng)顯示的內(nèi)容。 This will substantially cut down on thenumber of UI elements that must be batched, as the cost of batching onlyincreases based on the number of Canvas Renderers within a Canvas, not thenumber of Rect Transforms. 這會(huì)減少需要批次的UI元素?cái)?shù)量，由于批次的花費(fèi)只會(huì)隨著一個(gè)畫布類畫布渲染器的數(shù)量，而增加，而不是Rect Transforms的數(shù)量。 Problems withthe simple approach 簡(jiǎn)單的解決問題的方法 Currently, whenever any UI element isreparented or has its sibling order changed, that element and all of itssub-elements are marked as “dirty” and force a rebuild of their Canvas. 目前，每當(dāng)任何UI元素重新設(shè)置父類，或它們同級(jí)順序改變了，該元素及其所有的子元素會(huì)被標(biāo)記“dirty”，強(qiáng)制它的畫布重建。 The reason for this is that Unity hasnot separated the callbacks for reparenting a transform and altering itssibling order. Both of these events will fire an OnTransformParentChanged callback. In thesource of Unity UI’s Graphic class (see Graphic.cs in thesource), that callback is implemented and invokes the method SetAllDirty. By dirtying the Graphic, thesystem ensures that the Graphic will rebuild its layout and vertices before thenext frame is rendered. 這樣做的原因是，Unity 還沒有將重新設(shè)置父類Transform和改變同級(jí)順序分離開。兩種事件將回調(diào)OnTransformParentChanged 。在Unity UI的圖形類（看代碼這種Graphic.cs），這個(gè)回調(diào)會(huì)實(shí)現(xiàn)并調(diào)用方法SetAllDirty。通過標(biāo)志圖形dirty，系統(tǒng)確保圖形重建它的布局和在下一幀前，所有的頂點(diǎn)被渲染。 It is possible to assign canvases to theroot RectTransform of each element within the Scroll View, which will thenconfine the rebuild to only the reparented elements and not the entire contentsof the Scroll View. However, this tends to increase the number of draw callsneeded to render the Scroll View. Further, if the individual elements withinthe Scroll View are complex and consist of more than a dozen Graphiccomponents, and particularly if there are significant number of Layoutcomponents on each element, then the cost of rebuilding them is often highenough to noticeably reduce the frame rate on lower-end devices. 可以將畫布分配給在滾動(dòng)視圖內(nèi)的每個(gè)元素根RectTransform，這會(huì)限制僅僅重新設(shè)置的父類元素重建，而不是滾動(dòng)視圖所有的內(nèi)容。然而，這會(huì)導(dǎo)致滾動(dòng)視圖需要的draw calls數(shù)量增加。此外，如果視圖窗口內(nèi)不可見的元素很復(fù)雜，并帶有十幾個(gè)圖形組件，特別是如果每個(gè)元素都帶有布局組件，那么在低端設(shè)備，重建的開銷會(huì)高到明顯減少幀率。 如果一個(gè)滾動(dòng)查看UI元素不具有可變大小，然后布局和頂點(diǎn)的這個(gè)完整計(jì)算是不必要的。然而，避免這種行為，需要基于位置的對(duì)象池解決方案的改變，而不是父母或兄弟姐妹，為了改變的執(zhí)行。 If a Scroll View UI element does nothave a variable size, then this full recalculation of layout and vertices isunnecessary. However, avoiding this behavior requires the implementation anobject pooling solution based on position changes instead of parent orsibling-order changes. 如果滾動(dòng)視圖UI元素沒有可變大小，那么完全重新計(jì)算布局和頂點(diǎn)，不是必須的。然而，避免這種行為，需要啟用基于位置改變而不是同級(jí)順序改變的對(duì)象池解決方法。 Position-basedScroll View pools 基于位置的滾動(dòng)視圖池 In order to avoid the problems describedabove, it is possible to create a Scroll View that pools its objects by simplymoving the RectTransforms of its contained UI elements. This avoids the need torebuild the contents of the moved RectTransforms if their dimensions are notaltered, significantly improving the performance of the Scroll View. 為了避免上述提到的問題，可能創(chuàng)建一個(gè)滾動(dòng)視圖，通過簡(jiǎn)單地移動(dòng)它包含的UI元素的Transforms，池管理物體。這避免了需要重建移動(dòng)RectTransform，大小沒有改變的元素，顯著提高了滾動(dòng)視圖的性能。 To accomplish this, it is generally bestto either write a custom subclass of Scroll View or to write a custom LayoutGroup component. The latter is generally the simpler solution, and can beaccomplished by implementing a subclass of Unity UI’sLayoutGroup abstract base class. 要做到這點(diǎn)，通常最好是要么寫一個(gè)自定義的滾動(dòng)視圖的子類或者寫一個(gè)自定義布局組的組件?；蛘咄ǔＪ窍鄬?duì)簡(jiǎn)單的方法，可以通過繼承Unity UI的LayoutGroup抽象基類的子類來(lái)實(shí)現(xiàn)。 The custom Layout Group can analyze theunderlying source data to examine how many data elements must be displayed andcan resize the Scroll View’s Content RectTransform appropriately. It can thensubscribe to Scroll View change eventsand use these to reposition its visibleelements accordingly. 自定義布局組可以分享源數(shù)據(jù)，檢查多數(shù)數(shù)據(jù)元素需要顯示，并可以適當(dāng)調(diào)整滾動(dòng)視圖內(nèi)容的RectTransform?？梢圆榭碨croll View change event，使用它來(lái)重新定位可見元素。 FOOTNOTES 附注 1. This includes UI Text components whoseparent Canvases are enabled, but that have disabled Canvas Renderers. ? 這包括父類畫布啟動(dòng)但是畫布渲染器被禁用的UI文本組件。
|
|
|
來(lái)自： kiki的號(hào) > 《性能優(yōu)化》
