iTween's  Ease type

iTween 은 간편하게 오브젝트의 이동 에니메션을 쉽게 처리해 줍니다. 

그런데 오브젝트가 로보트처럼 딱딱하게 움직이면 좀 보기가 좋지 않겠죠.

그래서 iTween은 여러가지 ease type를 지정할수 있습니다. 

 EaseOutQuad,    
 EaseInOutQuad,  
 EaseInCubic,    
 EaseOutCubic,   
 EaseInOutCubic, 
 EaseInQuart,    
 EaseOutQuart,   
 EaseInOutQuart, 
 EaseInQuint,    
 EaseOutQuint,   
 EaseInOutQuint, 
 EaseInSine,     
 EaseOutSine,    
 EaseInOutSine,  
 EaseInExpo,     
 EaseOutExpo,    
 EaseInOutExpo,  
 EaseInCirc,     
 EaseOutCirc,    
 EaseInOutCirc,  
 Linear,         
 Spring,         
 EaseInBounce,   
 EaseOutBounce,  
 EaseInOutBounce,
 EaseInBack,     
 EaseOutBack,    
 EaseInOutBack,  
 EaseInElastic,  
 EaseOutElastic, 
 EaseInOutElastic

이 리스트에 보이는 것처럼 상당히 많은 양의 타입을 지정하는데요. 

위의 코드에서 보시다 시피, 해시테이블을 만들때, easeType을 지정하면 됩니다. 

Breakpad Client Libraries

Objective

The Breakpad client libraries are responsible for monitoring an application for crashes (exceptions), handling them when they occur by generating a dump, and providing a means to upload dumps to a crash reporting server. These tasks are divided between the “handler” (short for “exception handler”) library linked in to an application being monitored for crashes, and the “sender” library, intended to be linked in to a separate external program.

Background

As one of the chief tasks of the client handler is to generate a dump, an understanding of dump files will aid in understanding the handler.

Overview

Breakpad provides client libraries for each of its target platforms. Currently, these exist for Windows on x86 and Mac OS X on both x86 and PowerPC. A Linux implementation has been written and is currently under review.

Because the mechanisms for catching exceptions and the methods for obtaining the information that a dump contains vary between operating systems, each target operating system requires a completely different handler implementation. Where multiple CPUs are supported for a single operating system, the handler implementation will likely also require separate code for each processor type to extract CPU-specific information. One of the goals of the Breakpad handler is to provide a prepackaged cross-platform system that masks many of these system-level differences and quirks from the application developer. Although the underlying implementations differ, the handler library for each system follows the same set of principles and exposes a similar interface.

Code that wishes to take advantage of Breakpad should be linked against the handler library, and should, at an appropriate time, install a Breakpad handler. For applications, it is generally desirable to install the handler as early in the start-up process as possible. Developers of library code using Breakpad to monitor itself may wish to install a Breakpad handler when the library is loaded, or may only want to install a handler when calls are made in to the library.

The handler can be triggered to generate a dump either by catching an exception or at the request of the application itself. The latter case may be useful in debugging assertions or other conditions where developers want to know how a program got in to a specific non-crash state. After generating a dump, the handler calls a user-specified callback function. The callback function may collect additional data about the program’s state, quit the program, launch a crash reporter application, or perform other tasks. Allowing for this functionality to be dictated by a callback function preserves flexibility.

The sender library is also has a separate implementation for each supported platform, because of the varying interfaces for accessing network resources on different operating systems. The sender transmits a dump along with other application-defined information to a crash report server via HTTP. Because dumps may contain sensitive data, the sender allows for the use of HTTPS.

The canonical example of the entire client system would be for a monitored application to link against the handler library, install a Breakpad handler from its main function, and provide a callback to launch a small crash reporter program. The crash reporter program would be linked against the sender library, and would send the crash dump when launched. A separate process is recommended for this function because of the unreliability inherent in doing any significant amount of work from a crashed process.

Detailed Design

Exception Handler Installation

The mechanisms for installing an exception handler vary between operating systems. On Windows, it’s a relatively simple matter of making one call to register a top-level exception filter callback function. On most Unix-like systems such as Linux, processes are informed of exceptions by the delivery of a signal, so an exception handler takes the form of a signal handler. The native mechanism to catch exceptions on Mac OS X requires a large amount of code to set up a Mach port, identify it as the exception port, and assign a thread to listen for an exception on that port. Just as the preparation of exception handlers differ, the manner in which they are called differs as well. On Windows and most Unix-like systems, the handler is called on the thread that caused the exception. On Mac OS X, the thread listening to the exception port is notified that an exception has occurred. The different implementations of the Breakpad handler libraries perform these tasks in the appropriate ways on each platform, while exposing a similar interface on each.

A Breakpad handler is embodied in an ExceptionHandler object. Because it’s a C++ object, ExceptionHandlers may be created as local variables, allowing them to be installed and removed as functions are called and return. This provides one possible way for a developer to monitor only a portion of an application for crashes.

Exception Basics

Once an application encounters an exception, it is in an indeterminate and possibly hazardous state. Consequently, any code that runs after an exception occurs must take extreme care to avoid performing operations that might fail, hang, or cause additional exceptions. This task is not at all straightforward, and the Breakpad handler library seeks to do it properly, accounting for all of the minute details while allowing other application developers, even those with little systems programming experience, to reap the benefits. All of the Breakpad handler code that executes after an exception occurs has been written according to the following guidelines for safety at exception time:

• Use of the application heap is forbidden. The heap may be corrupt or otherwise unusable, and allocators may not function.
• Resource allocation must be severely limited. The handler may create a new file to contain the dump, and it may attempt to launch a process to continue handling the crash.
• Execution on the thread that caused the exception is significantly limited. The only code permitted to execute on this thread is the code necessary to transition handling to a dedicated preallocated handler thread, and the code to return from the exception handler.
• Handlers shouldn’t handle crashes by attempting to walk stacks themselves, as stacks may be in inconsistent states. Dump generation should be performed by interfacing with the operating system’s memory manager and code module manager.
• Library code, including runtime library code, must be avoided unless it provably meets the above guidelines. For example, this means that the STL string class may not be used, because it performs operations that attempt to allocate and use heap memory. It also means that many C runtime functions must be avoided, particularly on Windows, because of heap operations that they may perform.

A dedicated handler thread is used to preserve the state of the exception thread when an exception occurs: during dump generation, it is difficult if not impossible for a thread to accurately capture its own state. Performing all exception-handling functions on a separate thread is also critical when handling stack-limit-exceeded exceptions. It would be hazardous to run out of stack space while attempting to handle an exception. Because of the rule against allocating resources at exception time, the Breakpad handler library creates its handler thread when it installs its exception handler. On Mac OS X, this handler thread is created during the normal setup of the exception handler, and the handler thread will be signaled directly in the event of an exception. On Windows and Linux, the handler thread is signaled by a small amount of code that executes on the exception thread. Because the code that executes on the exception thread in this case is small and safe, this does not pose a problem. Even when an exception is caused by exceeding stack size limits, this code is sufficiently compact to execute entirely within the stack’s guard page without causing an exception.

The handler thread may also be triggered directly by a user call, even when no exception occurs, to allow dumps to be generated at any point deemed interesting.

Filter Callback

When the handler thread begins handling an exception, it calls an optional user-defined filter callback function, which is responsible for judging whether Breakpad’s handler should continue handling the exception or not. This mechanism is provided for the benefit of library or plug-in code, whose developers may not be interested in reports of crashes that occur outside of their modules but within processes hosting their code. If the filter callback indicates that it is not interested in the exception, the Breakpad handler arranges for it to be delivered to any previously-installed handler.

Dump Generation

Assuming that the filter callback approves (or does not exist), the handler writes a dump in a directory specified by the application developer when the handler was installed, using a previously generated unique identifier to avoid name collisions. The mechanics of dump generation also vary between platforms, but in general, the process involves enumerating each thread of execution, and capturing its state, including processor context and the active portion of its stack area. The dump also includes a list of the code modules loaded in to the application, and an indicator of which thread generated the exception or requested the dump. In order to avoid allocating memory during this process, the dump is written in place on disk.

Post-Dump Behavior

Upon completion of writing the dump, a second callback function is called. This callback may be used to launch a separate crash reporting program or to collect additional data from the application. The callback may also be used to influence whether Breakpad will treat the exception as handled or unhandled. Even after a dump is successfully generated, Breakpad can be made to behave as though it didn’t actually handle an exception. This function may be useful for developers who want to test their applications with Breakpad enabled but still retain the ability to use traditional debugging techniques. It also allows a Breakpad-enabled application to coexist with a platform’s native crash reporting system, such as Mac OS X’ CrashReporter and Windows Error Reporting.

Typically, when Breakpad handles an exception fully and no debuggers are involved, the crashed process will terminate.

Authors of both callback functions that execute within a Breakpad handler are cautioned that their code will be run at exception time, and that as a result, they should observe the same programming practices that the Breakpad handler itself adheres to. Notably, if a callback is to be used to collect additional data from an application, it should take care to read only “safe” data. This might involve accessing only static memory locations that are updated periodically during the course of normal program execution.

Sender Library

The Breakpad sender library provides a single function to send a crash report to a crash server. It accepts a crash server’s URL, a map of key-value parameters that will accompany the dump, and the path to a dump file itself. Each of the key-value parameters and the dump file are sent as distinct parts of a multipart HTTP POST request to the specified URL using the platform’s native HTTP facilities. On Linux, libcurl is used for this function, as it is the closest thing to a standard HTTP library available on that platform.

Future Plans

Although we’ve had great success with in-process dump generation by following our guidelines for safe code at exception time, we are exploring options for allowing dumps to be generated in a separate process, to further enhance the handler library’s robustness.

On Windows, we intend to offer tools to make it easier for Breakpad’s settings to be managed by the native group policy management system.

We also plan to offer tools that many developers would find desirable in the context of handling crashes, such as a mechanism to determine at launch if the program last terminated in a crash, and a way to calculate “crashiness” in terms of crashes over time or the number of application launches between crashes.

We are also investigating methods to capture crashes that occur early in an application’s launch sequence, including crashes that occur before a program’s main function begins executing.

출처 : https://code.google.com/p/google-breakpad/wiki/ClientDesign

처음에는 Rebase를 왜 해야 하고 언제 어떻게 해야 하는지 좀 헷갈린다. 헷갈리는 이유는 정답이 없고 미묘함이 있어서인데 그래도 대략적인 가이드가 있으면 좋겠다 싶어서 정리해보았다.

Social Coding Platform

svn이나 다른 VCS 도구 말고 git을 사용해야 하는 이유는 커뮤니케이션이다. 개발이라는 작업은 혼자 하는 게 아니라서 코드를 공유하고, 리뷰하고, 피드백을 받아야 하는데 Git으로 하면 일이 좀 쉬워진다(Git이 쉽다는 것은 아니다).

git과 github의 인기는 VCS 본연의 기능뿐만 아니라 커뮤니케이션을 원활하게 할 수 있는 플랫폼이 함께 필요하다는 것을 보여준다. git은 소스관리에도 뛰어난 도구지만 그게 Git만의 장점은 아니다.

git은 단순히 VCS가 아니다. 소스관리뿐만 아니라 커뮤니케이션에 필요한 모든 것이 들어 있다. 특히 코드를 공유하는 것은 정말 끝내 준다. Git 이외에 필요한 도구가 별로 없다. 나는 히스토리를 엉망으로 관리하는 프로젝트을 살펴보고자 gitx를 가끔 사용하고 차이를 살펴보고자 diffmerge를 아주 가끔 사용한다. 정말 아주 가끔이다. 한 달에 한 번도 실행하지 않는다.

그 외에는 항상 콘솔에서 작업한다. git은 아직도 발전 중이고 코드를 쉽게 공유하는 방법이 계속 통합될 것으로 생각한다. git에는 정말 필요한 모든 것이 통합되고 있어서 언젠가 git으로 문자 메시지로 코드를 보낼 수 있는 날이 올지도 모른다는 상상을 하고 있다.

배려

동료는 그녀와 같다. 배려 없이 초대에 응하는 그녀는 없다. 최대한 친절을 베풀어야 그녀를 내 저장소로 초대할 수 있다. 공포를 조장하거나 무턱대고 돈만 살포해서는 진심을 이끌어 낼 수 없다. 스스로 응할 때까지 배려하고 인내해야 한다.

코드는 당연히 잘 짜야 한다. 버그는 없을수록 좋고, 주석은 간략하고 명확해야 하고, 변수나 함수이름, 파일이나 디렉토리 구조나 이름 등등…. 중요하지 않은 것이 없다. 좋은 글에는 좋은 문장도 많은 법이다.

git도 마찬가지다. 변수 이름을 잘 짓듯이 브랜치 이름도 잘 지어야 한다. 커밋 메시지도 표준 포멧에 따라 잘 지어야 한다. 그리고 히스토리도 예쁘게 만들어야 한다.

Merge vs Rebase

Rebase는 히스토리를 단장하는 데 필요하다. 나 혼자 쓰는 저장소에서도 Rebase가 없으면 지저분해서 히스토리를 읽을 수가 없다.

잘 정리한 히스토리를 엿보고 싶다면 npm 저장소를 구경해보는 것이 좋다. @izs님은 완전 git타쿠:

히스토리가 정말 보기 좋다. github의 'pull request'도 사용하지 않고 죄다 손으로 Merge하는 것 같다.

커밋 vs Merge 커밋

Merge와 Rebase를 살펴보기 전에 커밋부터 다시 살펴보자.

커밋은 의미의 단위다. 지금 하는 일을 적당하게 한 조각으로 나눠서 커밋한다. 10줄, 100줄처럼 정량적인 단위가 아니다. 고기를 사듯이 '커밋 한 근 주세요.'라고 말할 수 없다. 커밋 하나는 의미 하나다.

커밋 하나하나에도 의미가 있지만 어떤 모듈을 개발한다면 여러 개를 하나로 묶어서 처리할 필요도 있다. 그러니까 여러 개의 커밋을 묶음으로 표현할 수 있는 커밋이 필요하다. 그게 Merge 커밋이다. Merge 커밋은 일종의 커밋 묶음이다

npm 저장소에 @izs님이 만들어 놓은 Merge 커밋을 보자:

1ecd0eb는 gyp를 구현한 커밋들을 묶어 놓은 Merge 커밋이다. gyp 브랜치를 만들어 gyp를 구현하고 master 브랜치로 Merge했다.

Merge 커밋은 사실 커밋 묶음 나타내는 것이 아니다. 보통 커밋은 Parent가 하나인데 Merge 커밋은 Parent가 여러 개다. 하지만, Parent가 여러 개인 점을 이용해서 커밋 묶음으로 다룰 수 있다:

C6는 Merge 커밋으로 Parent가 두 개다.

Merge 커밋을 Reset하면 관련 커밋이 전부 Reset된다:

C3와 C5가 같이 Reset되기 때문에 master 입장에서는 커밋 묶음이 Reset된 것이다.

npm 저장소에서 master 브랜치가 Merge 커밋인 1ecd0eb를 가리키는 상태에서 'HEAD~1'으로 Reset하면 gyp 브랜치가 통째로 Reset된다. 그래서 master는 c4eb2fd를 가리킨다.

Merge vs Rebase

다음과 같은 브랜치를 Merge, Rebase해보고 그 결과를 비교해보자:

git merge iss1 명령으로 iss1를 Merge한다. 노란색인 C1은 Merge Base이다:

git merge iss2 명령으로 iss2를 Merge한다:

git merge iss3 명령으로 iss3를 Merge한다:

iss1, iss2, iss3를 Merge 했다. C9, C10, C11은 Merge 커밋이다. 이 그림에서는 히스토리가 복잡하지 않다고 생각할 수 있지만, 이정도 되는 내용도 콘솔에서 보면 헷갈린다. 한눈에 들어오지 않는다. 이제 Rebase 후 Merge해보자.

헷갈릴 수 있으니 원본 브랜치를 다시 한번 보고:

git checkout iss1과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C1이 아니라 C4가 된다:

git checkout master과 git merge iss1를 차례대로 실행해서 Merge한다. Rebase를 하면 항상 Fast-Forward Merge가 가능해진다. 하지만, 무턱대고 Fast-Forward Merge를 하는 것이 아니라 앞서 얘기했듯이 커밋을 묶음으로 관리하고 싶지 않을 때만 Fast-Forward Merge한다. 이 경우는 커밋이 하나이므로 그냥 Fast-Forward Merge한다:

git checkout iss2과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3가 아니라 C2'가 된다:

git checkout master과 git merge --no-ff iss2를 차례대로 실행해서 Merge한다.--no-ff 옵션은 강제로 Merge 커밋을 남기려고 주는 것이다. iss2 브랜치는 커밋이 두 개고 이 커밋은 iss2를 처리한 결과이므로 커밋 묶음으로 처리하는 것이 낫다(물론, 내용상 --no-ff 옵션을 주는 게 틀릴 수도 있다.):

git checkout iss3과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3에서 C9이 된다:

git checkout master과 git merge --no-ff iss3를 차례대로 실행해서 Merge한다:

다음 그림은 위에서 Rebase 없이 Merge한 결과다. 한번 비교해보자:

Rebase를 하고 나서 Merge한 것이 훨씬 보기 좋다. 아무리 복잡한 과정을 거쳤어도 한눈에 들어오게 할 수 있다.

마치며

Git처럼 히스토리를 다중으로 관리하는 시스템에서 Rebase는 필수다. Mercurial도 Git의 영향을 받아 Rebase를 지원한다. 이글에서는 Rebase가 왜 필요하고 언제 어떻게 해야 하는지 알아봤다.

UPDATE: 20121122

Merge Commit은 Commit을 묶음으로 관리하는데도 유용하지만 Release Note에 넣을 만한 것을 미리 Merge Commit으로 만들어 놓으면 편리할 것 같다. 배포할 때 Merge Commit만 추려볼 수 있으니 Release Note를 따로 작성하지 않아도 된다.

참조) http://blog.naver.com/goldrushing/130147289978

http://blog.naver.com/bridman/40195903160

출처 : http://mydoh.tistory.com/63

No JVM installation found. Please install a 64-bit JDK.

If you already have a JDK installed, define a JAVA_HOME variable in Computer

> System Properties > System Settings > Environment Variables.

윈도우에서 안드로이드 실행시 위와 같이 에러 문구발생시 아래와 같이 설치해주세요.

1. 아래 사이트로 가서 최신 버젼 JDK를 다운받고 설치 합니다.

http://www.oracle.com/technetwork/java/javase/downloads/index.html

2.  내 컴퓨터 오른쪽 마우스 클릭 > 속성 > 고급시스템설정 에서 [고급]탭을 선택  후 [환경변수]를 클릭 합니다.

3. [새로만들기]를 클릭해서 JAVA_HOME 이라는 변수를 추가 합니다.

JAVA_HOME 은 JDK가 설치된 경로로 등록하시면 됩니다.  ( C:\Program Files\Java\jdk1.8.0_20 )

4. 이번엔 Path 를 찾아서 누른후 편집을 눌러주세요.

그후 ;%JAVA_HOME% 을 변수값 맨뒤쪽에 공백 없이 복사하여 붙여넣기 합니다. path  들과 구분하기 위해 ";" 세미콜론을 사용합니다.
Path-편집  -  ;%JAVA_HOME% 붙여넣기  -  확인클릭
 

5. 마지막으로 정상적으로 설정되었는지 테스트 해보세요.

( 윈도우키+r ) 입력 후 아래와 같이 cmd 실행해주세요.

명령 프롬프트 창에서 javac -version 입력해서 버젼 정보가 출력되면 정상적으로 설치 완료된 것입니다.
(추가: 나는 jdk 1.8.0_31을 깔았는데 cmd에서 위 명령어는 먹히지 않고 java -version 이 됐다. 버전업 되면서 달라진걸까?)

출처 : http://lab.anybuild.co.kr/bbs/faq/3241

1、可以使用BBCode标记

[b]Bold[/b]                      粗体
[i]italic[/i]                         斜体
[u]underline[/u]               下划线
[s]strikethrough[/s]         删除线
[sub]sub[/sub]               下标
[sup]sup[/sup]               上标
[00ff00]设置颜色[-]           设置显示颜色

[url=http://www.cnblogs.com/mrzivchu/][u]博客[/u][/url] 链接

例如设置颜色：

UILabel的Text内容为：[99ff00]n[-]gui: tools

展示效果则为：

这里主要说一下设置连接：

单单的在UILabel的Text里面写入这个是不够的：[url=http://www.cnblogs.com/mrzivchu/][u]博客[/u][/url] 链接

点击是不会产生效果的，我们还要为此UILabel添加一个Collider和一个脚本

脚本如下：

 void OnClick()
    {
        UILabel lbl = GetComponent<UILabel>();
        string url = lbl.GetUrlAtPosition(UICamera.lastWorldPosition);
        Application.OpenURL(url);
    }

脚本中的OnClick方法要想被触发，就必须要添加一个Collider，这个道理我想大家都懂得！

但要注意一点，假如UILabel的Text内容为：请点击[url=http://www.cnblogs.com/mrzivchu/]我的博客[/url]进入，欢迎大家来批评指正！

我只想点击《我的博客》四个字才去打开连接，而不是点击上面的任何字都可以打开连接，假如上面的文字尺寸是700x40，而《我的博客》四个字的尺寸是200x40，这时我们就可以设置Collider的Center和Size属性来设置点击的区域大小以满足我们的需求，可是当我运行程序的时候Center和Size会自动变为700x40，原来UILabel的Widget有个选项Collider，这个auto-adjust to match表示Collider大Size大小自动匹配为UILabel的Size大小，我们只要把这个勾取消即可！

如果你不想使用BBCode，那么UILabel有个选项BBCode，不勾选的话，就表示不使用BBCode

2、使用图片

我们只要在UILabel的Text里面写了：zwh:) 那么就会出现了一个笑脸图片：

为什么会这么神奇呢，原因在于你选择的Font，此处我选择的Font是Arimo20

Arimo20有三个关联的文件：

类型依次为：tga，prefab，txt

这时，我们点击类型为prefab文件，在Inspector窗口的UIFont可以看到

其中可以看到我们熟悉的 :) 笑脸标记，我们这时点击笑脸对应的Emotion - Smile ，展现出来的就是那个笑脸图片，而这个笑脸图片是存在Wooden Atlas图集里面的，如果我们想用其他图片的话，我们可以向Wooden Atlas图集里面增加我们需要展现的图片，然后在下面填写一个约定好的标记，类似于 :) 这样的标记，选择我们想要展现的图片，Add即可，图片的尺寸最好是20x20，以保证和文字上下在一条水平线上！

UILabel的Text为：zwh(bird)zwh 

显示为：

因为我的图片是60x60的，所以和文字上下不一样齐了，这也是我为什么建议图片尺寸是20x20的原因了！

另外说一个问题，我也不知道是不是存在的bug

此处我们为UIFont选择的图集是Wooden Atlas，Sprite是Arimo 20，Arimo 20大概对应的是字符格式，如果此时我们点击Sprite，将会弹出Wooden Atlas里面包含的所有sprite精灵，当我们点击Arimo 14或者Arimo 18的话，那么应用此Arimo20的UILabel将会变形：

原本是这样的：，变成了这样：

为Sprite选择Arimo20已经还原不会来了，还是会变形！

解决方案：

就是点击UIFont下的Import Data，也就是导入和Arimo20关联的三个类型（tga，prefab，txt）的文件中的txt文件即可！从而使Arimo的字符集格式还原回来！

另外：

UILabel还有一个Symbols选项，他有三个值：None，Normal，Colored，选择None，那么以 :) 这样形式显示的图片将不会展示，选择Normal（默认）将正常展示，选择Colored，那么图片将会被UILabel下的Color Tint所选择的颜色遮盖！其实这个Color Tint是对文字进行着色的，选择Colored那么也就是意味着图片也和文字应用同样的颜色！

其他属性

overflow：

1.ShrinkContent，总是显示所有文字，根据当前的width和height进行缩放
2.ClampContent，一看到Clamp就想起Clamp函数，也就是不管文本多少个字，根据当前的width和height来显示，超出部分 
不显示
3.ResizeFreely，会对当前的文字长度和行数来调整，UILabel的width和height，基本上是只在一行显示，超出的部分不显示
4.ResizeHeight，保持宽度不变，必要时增加高度。

Spacing ：

X：设置字与字之间到间隔，可以为负数，设置得当可以反序

Y： 设置行与行之间的间隔。

Gradient ：

设置 渐变字

Max Lines：

用来控制最多要多少行。用0表示不限制。如果设置成n的话，那么超过n的行的文字将不会显示！

实现动态文字展现的效果：

先上效果图：

层次：

content显示的是文字

bg显示是背景图（uisprite）

title是标题

第一步：先给content添加UIlabel和typewriter effect脚本：此脚本选项的解释如下：

chars per second：每秒显示多少个字符

fade in time：淡入时间

delay on period：延迟期

delay on new line：开始新行延迟时间

scroll view：需要指定scroll view

keep full dimentions：保持全部尺寸

第二步：

设置content组件uilabel的overflow（溢出方式）为ResizeHeight

第三步：

typewriter effect脚本的keep full dementions不要勾选，其他的默认即可

第四步：

设置bg背景图的UISprite的Anchors的Type为Unified（统一），Execute为OnUpdate，Target为mylabel即可！

Anchors的功能是：

物体A相对于所指定物体B的位置设置情况。可以设置离指定物体的上，下，左，右的偏移值，从而实现对齐，主要用在动态的效果的情况下，例如上面的title的位置就是相对于content而设置的，随着content文字的动态增加，title的位置也在不断的上移，实现对齐，避免位置错乱！这大概就是设置Anchors的好处吧！

这里我的title的anchors里面，只要设置了top+50即可，保持与content的顶部的距离即可，其他的可以不用设置！

target为指定物体B，而bg就是A，Execute指在更新时还是可用时去执行，type表示统一的还是高级的

출처 : http://www.cnblogs.com/MrZivChu/p/UILabel.html

크롬창 주소에

출처 : http://www.todayhumor.co.kr/board/view.php?table=bestofbest&no=196624&s_no=196624&page=9

BBCode tags reference

In this section, a reference table for all of the more popular bbcode tags, is provided. Some are considered to be standard and should be supported in just about any bbcode implementation. Other are less likely to be supported, but nonetheless popular (hence the reason they've been included here).

Tags reference table

BBCode examples

Go to the examples section to find many examples of how you can use these tags.

출처 : http://www.bbcode.org/reference.php