이번 작업 이후에는 전체 시스템을 새로 제작할것이고, 그 시스템은 내가 추구하는 이상적인 설계를 따라가도록 하기 위함이다.
일단 종래의 프로그램을 물려 테스트를 시도해보았으나 -_-
mysqli 클래스가 예상과는 빗나가게 conn handler가 앞에 붙는 문제가 발생 ;;
(쿼리를 우선시 하느냐, 커넥션을 우선시 하느냐의 경로에서 php개발자가 선택한것은 쿼리가 아니었는가 싶기도 하다. 이것은 물론 statical usage에 국한되지만. 기존 펑션과의 호환성을 일부러 배제하기 위함이었을까? 어쨋든 우리는 별도의 클래스를 만들어 쓰기때문에 관계없지만)
기타 deprecated 된 수많은 펑션들의 향연 -_- 이 펑션들은 6버전대부터 remove된다고 하므로 변경된 로직을 태우던가 방향우회를 해야한다.
여하튼 약 6시간가량의 과부하테스트를 진행해본결과 class 사용에 있어 5.1버전보다 약 40%이상 퍼포먼스적 우위에 있었다는 점은 마음에 든다. (테스트전에 rpm과 가장 비슷하게 빌드했다고 생각하고 있지만. 몇가지 빠진옵션이 있어 rpm과 다소 차이가 발생할수도 있다. 그리고 우리가 쓰는 cflags나 빌드옵션은 rpm과는 다소 차이가 있어 이부분에서 퍼포먼스가 다소 향상되었을수도 있다)
전반적인 평가는 good!
그러나 소스코드를 (어차피 새로 짜야하지만) 다시 갈아야한다는 문제앞에 정신이 아득해지기 시작한다.
수년전부터 PHP라는 언어에 손을 대기 시작하면서 겪었던 여러가지 문제점을 보완하며 현재의 제작방식의 기초가 되어온 룰들입니다. 국내의 일부 PHP 솔루션들은 이러한 룰의 기본조차 되어있지 않습니다. 높은 PHP 퍼포먼스를 추구하기 위한 코딩방식에 대한 설명입니다. 정말.. 동접 100명도 안됬는데 나가 떨어지는 코드들 질립니다.. 돈주고 산것들마저 한심하더군요.
1. 가장 중요한것은 기초 알고리즘과 로직들이다. 근본적인것이 서있지 않으면 그 위로 어떠한것을 짜더라도 또 이 밑의 어떠한것을 하더라도 소용없습니다 PHP는 코딩이 쉬운 반면 C처럼 메모리 리크를 뿜으며 죽는 경우도 있으며, (그러나 아파치의 프로세서가 죽어나갔다 다시 리스폰됩니다) 잘못짜면 정말 많은 부하를 불러오는 저질 언어가 될 수 있습니다. 그리고 PHP의 모든 펑션은 메모리 리크현상이 발생할 때 크게 오동작을 하는 경우가 많습니다. PHP의 메모리 리크는 실행즉시 발견되는것이 아니라 점점 서버에 누적이 되어가는 형식입니다. 한마디로 잘만 짜면 손쉽게 높은 퍼포먼스를 얻을수도있다는 점입니다. (안정성은 다소 떨어집니다만) 모토는 어떤 언어나 마찬가지로 로직, 알고리즘, 기본구조는 모두 부하와 동작전반을 감안하여 신중해야 한다는 점입니다.
잘 모르는 함수를 함부로 이용하지 않아야 합니다. eregi 와 ereg, preg의 차이를 모른채 불필요한 부분에 eregi를 남발하는것은 가장 극단적인 예중 하나입니다. eregi는 ereg보다 약 1.7배이상의 연산부하가 걸리게 됩니다. eregi는 ereg와 유사하나 case insensitive (대소문자 무시기능)이 포함되어있어 c로 치면 strcmp와 stricmp 와 유사한 예라고 볼수있습니다. 두개의 펑션이 어떻게 짜여졌고 어떻게 틀린지는 헤더를 참고해보세요
그러나 한글의 casecomp 에는 대소문자가 없으므로 eregi를 한글에다 쓰는건 비효율적입니다.
2. MVC는 가장 최악의 경우를 불러일으킨다.
1) 파일의 인클루드는 모든 1개의 클라이언트 프로세스당 최대 2회로 제한합니다. 파일을 자주 불러오는것은 이를테면 멍청한짓중 하나로 분류되죠. 가장 멍청한짓중 하나가 looping phase내부에 include를 삽입하는 행위입니다. 핵심 클래스 및 부가 클래스등의 인클루드 횟수를 2회 또한 최대한 적게 제한하는것이 좋습니다. 소스 정리를 위해 파일을 나누는 깔끔을 떨지 말아야 합니다. vi에는 폴딩기능이 있습니다.
2) 만약 서브모듈단위의 뷰를 형성해야할 때에는 초도(첫접근의) 뷰측의 로더는 PHP가 될수 없습니다. 웹서버등의 rewrite룰을 적당히 이용해야 합니다. PHP 는 만능이 아니라 단지 부하를 잡아먹는 소프트웨어일뿐입니다. 1개의 PHP에 파일별로 모듈을 인클루드 하는것보다 rewrite를 통해 적재모듈을 선언하는것을 권장합니다.
3) 실시간 스킨은 최악의 결과를 불러온다. 파일을 인클루드 하여 스킨으로 매핑하는 형식은 권장하지 않습니다. 파일,메모리,CPU 모두 활용하는 최악의 테크트리로 불리우는데 스키나이징을 하려면 포매터와 제네레이터로 나누어 3단계 절차를 거쳐 static php 를 생성하는것을 권장합니다.
3. 변수의 선언에는 신경을 써야한다. php 는 mixed variable을 사용합니다. 즉 변수 선언자체가 타 언어보다 많은 리소스를 할애하게됩니다. 불필요한 변수는 선언하지 않고, 선언된 변수는 모조리 unset해주어야 합니다. php는 메모리 리크가 심각한 언어라는것을 잊어서는 안됩니다. (그러나 global을 unset하여서는 안됩니다)
4. 네임 쿼테이션은 최대한 ' 로 통일 $hey["stupid"] 보다는 $hey['thisone'] 이 빠릅니다. 최대한의 연산부하를 줄이는 형식을 유지합니다 수백개의 디피니션을 올리고 테스트해본 결과 약 0.0001초 차이정도 발생합니다만, 별것 아닐것 같지만 동시접속자가 만명이면 1초가량의 차이가 납니다. flops test를 하는 툴까지 올리질 못해보았네요 (사실 많이 귀찮았습니다) 과부하율이 겹쳐지면 그 차이는 10초이상이 벌어지게되며, 프로세스 단위에서 10초가 벌어지면 서버는 무응답 상태로 셧다운조차 할수없도록 중단되는 경우가 발생할 수 있습니다. 통상적으로 프로세스당 연산시간이 3초를 넘어서는 시점에서 연산처리능력의 한계가 온것으로 판단합니다.
물론 의도적인 시간제한도 필요합니다. 사용자의 정적방문 (1~2초이내 이동등)으로 통계나 사이트순위에 신경을 쓴다면 적당히 핸들링을 하는것도 필요하지만 순처리속도가 떨어지는것은 치명적 문제를 일으키게됩니다.
5. 펑션도 메모리다. 불필요한 펑션을 한파일에 넣고 돌리는것은 메모리 관리측면에서 좋지 않습니다. 클래스를 적절히 사용해야 합니다. 잦은 빈도의 펑션은 코어클래스로 묶고 나머지는 extras로 분리하여 "선언하지만 않으면" 적재되지 않습니다. 클래스 파일 또한 용량이 커져서는 안됩니다. 따라서 각 펑션은 극도로 간결하게 작성되어야 합니다. 기본적으로 펑션이 variable 에 해당하는걸 인지해야겠지요. 이러한 형식을 유지하는것은 zend 혹은 액셀러레이터를 통해 극도의 퍼포먼스를 유지하기 위함입니다. 통합 클래스는 이부분에 있어 많은 이점을 주게됩니다.
6. DB의 Select또한 부하다. 불필요한 열을 가져오지말아야 합니다. 그또한 fetch 이전에 어떤 형식의 API던지 다운로드 받아 메모리에 가지고 있게됩니다. 그것을 fetch 할때 쓰거나 result 시 리턴하는 형식으로 구성되어있습니다. 따라서 10MB 분량의 데이터를 select 해왔다면, 그 텍스트 데이터는 메모리에 적재된 상태라는것입니다. 또 이것을 free하지 않을 경우 나중에 메모리 리크가 발생합니다.
7. PHP를 신뢰하지마라! 현재까지 크게 문제가 되었던 3가지가 있습니다. 다음의 부분은 주의를 기울여야 합니다. 아래에는 현재의 버전까지 존재하는 치명적 버그들이며, 해결의 기미가 보이지않는 것 들입니다.
1) mysql handling function php 자체에 메모리 리크여파가 잔존할 경우 높은 순위로 맛이가는 기능중 하나입니다. fetch 기능인지 query 후 데이터를 받아오는부분인지 아직 정확한 파악은 하지 못했습니다. (귀찮습니다) 그러나 mysql에서 오는 값은 모두 신뢰할 수 있는것이 아닙니다. 파괴되거나 오류가 있는 값이 전송되는 경우가 종종 있으며. 이것은 가끔 치명적인 문제를 일으킵니다.
2) serialize, unserialize function 이 또한 값을 왜곡시키는것이 증명되었습니다. int type의 287382 이란 값이 string으로 바뀌어 2라는 값만 덜렁 들어오는 경우가 있었습니다. (정확히는 2^제어문자382 형식) 지금도 존재합니다. 이것으로 인해 2년전 접속한 회원 모두가 운영자 관리권한을 획득하는등의 버그가 발생한적이 있습니다. 이문제로 인해 serialize handler가 wddx나 php등 여러가지 핸들링 타입이 존재합니다. 별도의 핸들러를 제작하여 운용하는것도 나쁘지 않을것 같습니다.
3) Exif 기능등.. 불안정한 기능이 다수 있습니다. PHP의 모든 펑션은 반푼어치로 보면됩니다. 어느 언어의 클래스처럼 반인분이 짜도 겉으로 티안나게 도는 언어가 있지만, PHP는 반인분짜리가 짜면 바로 티가 나는게 문제입니다. 또 티가 빨리 나는편이랄까요?. 그중 일부 기능이 exif 같은 펑션입니다. 지원되며, 데이터를 잘 가져오는것 같습니다.. 그러나 내부적으로는 많은 문제를 포함하고 있습니다. 일부 맥에서 편집된 프로그램중 바이트오더가 맞지 않는파일들 (인텔오더가 아닐경우) 또 특정 카메라 기종에 대해 인지하지 못하는 경우들 다양한 문제가 있는것이 밝혀졌습니다.
이제 iso와 친구가 될 시간이군요, 200장 정도의 단순노가다를 요하는 문서가 있습니다. 이 외에도 상당한 기능들이 생각보다 완성도가 매우 떨어지는 경우가 있습니다.
PHP가 가져오는, 동작하는 모든 펑션에 대해 신뢰를 하면안됩니다., 특별히 위처럼 문제 있는 펑션은 온값조차 재확인할 필요가 있습니다. (중요한 필드라면)
8. 캐시를 적당히 이용하라 xcache, eAccelerator, Zend Studio 등은 PHP를 캐시해주는 소프트웨어로 이외에도 몇가지가 있지만 안정성은 이 두가지가 압도적이라고 할수있습니다. 대응안으로는 APC가 있지만 현재로써는 메모리 리크점이 있다는것을 발견하였으며 (통상적 선언 재선언 해제구문으로 이루어진 로드테스트에서) 아직 이부분은 더 많은 테스트를 거듭하여야만 인정받을 수 있다고 보입니다.
위에도 설명했지만 캐시를 쓰면 파일i/o를 신경쓰지 않아도 되지 않느냐? 라고 생각할지 모르겠습니다만 캐시내에서도 include시 메모리i/o가 발생하는것은 사실입니다. 캐시는 파일을 옵티마이즈하여 메모리에 적재하므로 실행속도를 극도로 올려주는 기능입니다. (옵코드를 생성하여 이를 별도의 캐시로 shm메모리 영역등에 적재하는 타입)
9. 프로파일링을 위해 시간을 아끼지 말라 xdebug 등의 프로파일링 툴을 이용하여 각 클래스별 메모리, i/o, 부하, 처리시간 등의 리소스를 프로파일하여 최적화된 코드를 만들 수 있도록 옵티마이징 작업을 해야합니다.
9. 서버의 파인튠을 위해 많은 시간을 할당하라 file i/o, memory , cpu 연산등 대부분의 언어들은 서버의 퍼포먼스에 상당히 기대게 됩니다 아무리 잘짠 언어가 동작을 하더라도, 비싼 기름 넣는다고 해도 엔진이 경운기면 소용없습니다. 서버의 파인튠을 찾아낸다면 기존에 비해 배수 이상의 성능을 끌어올릴수 있게됩니다. 가급적 이상적인 성능향상을 위해서는 불필요한 설정과 소프트웨어, 커널코드등을 삭제하는것을 권장합니다. 기본적으로 드라이버, 불필요한 기능은 컨피그에서 제외하고 또 불필요한 i/o 함수들 또한 삭제합니다. 이작업은 가끔 극단적인 결과를 초래하기도 하므로 전문가가 아닐 경우 추천하지는 않습니다. 최신 커널에까지 일부 ext3 나 i/o 처리부에 신규구현된 기능으로 인해 병목이 걸리는 부분이 존재합니다. 과도한 io가 발생하면 메모리를 일부 io 순환처리용 버퍼로 대응하는 부분에서 발생하는 문제점입니다. disk io가 올라가는것이 아니라 메모리 io가 비정상적으로 상승하는데서 발생하는 문제입니다.
따라서 보통의 경우와 일반인은 절대 경험하기 힘들겠지만 미세하고도 자잘한 i/o로 극도의 퍼포먼스를 올리는 (PHP+캐시상태)에서는 이것은 가끔 치명적인 속도저하로 이어질 때가 있습니다.
윈도우 서버보다 리눅스 서버가 빠른점은 있습니다. 이와 마찬가지로 조금더 특화를 시킨다면 더 빠른 서버로 만들수가 있습니다. 서버는 잡다한 기능이 필요없습니다. 단지 서비스하는 한가지 기능에 특화된 시스템이 이상적입니다.
가장 간단히는 서버는 그래픽 편집을 할필요가 없습니다. 또 3d게임이 돌지 않아도 됩니다. 이러한 연계가 단하나라도 들어있는 윈도우와 리눅스는 퍼포먼스 면에서 차이가 발생하게됩니다. 또한 표준 리눅스에 비해 더 많은 기능을 삭제한 커스텀 리눅스는 대외적인 공격에서도 안정적이며, code exploit 도 통상적으로 적용되지 않습니다. 실제로 동일한 서버에서 이루어진 튜닝만으로 수배이상의 퍼포먼스를 보여준것도 사실입니다. 이부분은 엄격히 프로그래머가 아닌 SE에게 필요한 내용이 아닐까 싶습니다.
10. 이렇게 하면 안된다! 대표적인 배드코딩
1) 버전차이를 구분못하는 코딩 $HTTP_POST_VARS 등은 4.1대부터 deprecated 된 사전정의된 변수들입니다. $_POST, $_COOKIE 등으로 모두 대체되었으며 5버전대부터는 완전히 deprecated 된것으로 알고있습니다. 따라서 4.1(이 나온지 몇년이 되었는데) 아직도 php 를 두고 3.0때의 코딩을 유지하는 사람들이 있습니다. 그러나 3.x때 제가 짯던 코드를 보면 아직도 $_POST 이런것이 존재하는것으로 보면.. 메뉴얼은 오래전부터 업데이트되었던것으로 보입니다. PHP5 에서 종래 디파인을 삭제할 정도면 상당한 기간의 유예를 두었다고 보아야겠지요?
2) php에 퍼지 인공지능을 기대하는 프로그래머 $_POST[test] 형식으로 array를 사용하는 사람들이 일부 있습니다. 쿼테이션 미싱이라고 보아야겠지요. test란 env를 define 할 경우 php 는 저게 test인지 string의 test인지를 분간하기 위해 여러번 간을 봅니다. 저런게 소스상에 천개가 있다면.. 제대로 쿼테이션한 코드보다 2천번은 더 삽질한다는 이야기입니다. ' 등을 싸지 않으면 문맥간 . 등이 있는지를 재점검하는등의 불필요한 동작이 한번 더있습니다. 정말 별것 아닌것 같지만 동시에 천명이 접속한다 생각해보십시요. 효율적이다 아니다를 따질때가 됩니다. 여기다 registers globals를 키게되면 금상첨화로 해킹에 취약점이 드러나기도 합니다.
3) Register globals 를 쓰는 코딩 한번 쓰기 시작하면 밑도 끝도 없는 삽질로 이어지게 됩니다. 이로인해 발생하는 보안 리스크는 엄청납니다. 만약 소스가 공개된다면 다양한 헛점으로부터 공격을 피하기 어렵게됩니다. 다른 어떤 언어에서 모든변수를 광역으로 지정하고 쓰는것을 보신적이 있으십니까?
4) 업로드한 파일에 대한 퍼미션을 건드리는 코딩 통상적으로 업로드한 파일의 퍼미션은 조정할 필요가 없습니다. 구태여 조절한다면 644 정도가 적당하겠지요. 그러나 여기다 실행권한주는 경우 내 서버에 대한 모든 실행권한을 위임하는것과 마찬가지입니다.
5) 데이터베이스 쿼리의 examination이 없는 경우 2~30개의 열을 가져오는데 수만개의 레코드를 뒤적이는 쿼리가 날라다니는 경우가 자주 있습니다. 이게 참 아이러니하게도 상용으로 판매하는 쇼핑몰 소스들이 이꼬라지더군요 몇군데 본 결과 한두군데가 아니었습니다.
6) 관리권한 페이지의 액세스 오류 php의 내장 web auth등의 여러가지 method를 통해 인증을 요구하거나 세션체크를 할 수 있습니다. 그러나 일부 쇼핑몰 소스들은 관리자 주요 페이지들만 달랑 인증을 걸어놓은채 include되는 파일들은 전혀 인증이 되어있지 않아 로그인없이도 매출자료가 열람가능한 경우가 있었습니다. 상용으로 꽤나 많이 팔아먹은것 같은데.. 해당업체의 홍보자료에 의하면 쇼핑몰 솔루션을 구매한 약 300여개가 넘는 업체들은 지금 매출자료가 공개된거나 마찬가지인 상태가 되었습니다. 통합적인 파일을 인클루드하거나, 헤더에 넣거나, 체계적인 클래싱의 오토클래스 스타팅 선언등. 방법은 여러가지가 있었을텐데말입니다. 일부 쇼핑몰 소스는 관리자 페이지 뿐만아니라 주문/배송처리 쪽의 일부 페이지도 로그인없이 액세스가 되었습니다. 쇼핑몰에 있어서 파일이 업/다운로드 되는 유일한 페이지들인데 보안이 허술하면 서버가 뚤립니다. 저는 친절하게 버그 찾아다 밥떠먹여주는 사람이 아닙니다. 상용으로 파는건 파는사람들이 해결해야지요.. 단지 보안결함이 있다고 경고만 할뿐입니다.
7) 기타 쿼테이션 오류들 mysql에 집어넣을 데이터스트링에.. 사용자로부터 받은 변수에다가 stripslashes를 먹이는 막장코딩이 있습니다. 이건 서버단에서 차단해도 소용없습니다.. 직빵입니다.. sql injection으로 가는 지름길이라고 할수있습니다. 하는게 아니라당하는겁니다..
마무리 ... 이 문서를 지킨다면 노가다가 매우 심해질수 있음을 사전에 알립니다. 이 문서는 빙빙 둘러 말하고 있지만 이제 구현되어가고 있는 클래스 사용의 권고 메시지가 포함되어있습니다. 무단 펌질은 사양합니다. 트랙백, 퍼말링크등은 관계없습니다. (공지사항참고)
2년전 버그리포팅한 fts 의 문제에 대해 6.0 에 해결이 되었다는 메일을 40여통을 받았다 ㄱ- 그래.. 2년전엔 생까더니 보다보니 맞는거지.. case closed 까지 시켰다가 지금와서 reveal하는 이유는 뭘까 이제와서 패치한다고 메일질하면 기뻐할줄아는가 이미 mysql의 신뢰도는 개판으로 떨어진거다. 왜?
1. 개발자의 건의를 case closed 로 test result 조차 내지 않고 무시한다. 2. 기능에 이상이 있는걸 2년이나 지난 지금에서야 알아냈다. 3. 지금에서야 패치했다. 그렇다면 그 개발자들은 최하 2년이 넘는 기간동안 정말 단순한 오류하나를 못잡았다는 이야기가 아닌가? 4. 지금에라도 인정을 하니 다행이다 외국기업의 차이겠지만, 그 단순오류 하나때문에;; 시간적 기간적 손실은 크다. 이게 오라클이었으면 소송감이다. 5. 거기다 적용버전은 6.0이다 앞으로 3년은 지나야 이제좀 안정적이겠거니 할듯하다. 한마디로 떡밥이다. 6. 결정적으로 이거때매 검색시스템 새로 구축한다고 삽질한거 외주 인건비로만 쳐도 수천은 들어갔고 시스템 구축비까지 갔다치면 3억은 든다.
결국 bdb 가 윈이란 소리다.
그리고 그때 제기했던 mysql-cluster 에 대한 이슈는 아직도 해결되지 않았다. slrclub 규모를 mysql-cluster로 올리려면 300기가의 물리적 메모리가 필요하다. 메모리 장사할려고 작정헀나보다. 이게 웃긴게 -_- 1기가짜리 db가 utf-8 로 변환되서 메모리에 올라가면 몇배수로 용량을 잡아먹기 시작한다. 사실 답변은 받았다... "원래 시스템이 그렇다.. 그러니 다올리지 말고 쫌만 올려 써라" 였다. 클러스터링하나 똑바로 안되서 테이블을 쪼개갖고 그걸 프로그래밍으로 해결하라고??
그러니까 오라클이 팔리는거지 전화질이라고 할려다가 천년만년 mysql 쓸것도 아니고.. com이 아니라 ab다.. 두렵다 -_-;; 난 거기서 제일 궁금한게. 모 통신사가 클러스터링을 쓴다는거다. 양키들이라 영어만 쓰니 무관한건지는 모르겠으나 양이 상당할텐데 무슨 슈퍼돔에다 mysql돌리는게 아닐까 하는 생각이 든다. 메모리 20테라 쳐박고.
현재는 mysql 5.1 까지 테스트를 했고 실제서비스에서 동작한지가 어언 1년이 다되간다.. 이넘은 리플리케이션 티어로 돌던놈이다.. 별다른 문제가 없어보였으나 오늘 막상 안정버전인 5.0 버전을 적용하자마자 (주데이터베이스라) 기현상이 발생하기 시작했다 -_-;;
inner assoc type 의 select query 한방에 전체 데이터베이스가 락이 걸리는 현상이다. 서로다른 3개의 쿼리를 natural과 cross 조인으로 묶고 이를 그루빙한 subquery 를 associative 로 다시 매핑하는 형식의 쿼리다. 그렇다 -_- 통계용 쿼리다. reference rows도 몇천만개 안된다. 한번돌리고 정신이 멍해졌다...
이거 뭐 트랜잭션 건것도 아닌데 장난하나 -_- 기본으로 트랜잭션이 걸리게 바뀌었나? 건 짐부터 찾아봐야될 문제다.
critical changed issue 를 요약정리를 하는 센스가 없다. 세줄요약이 괜히나온말이 아니다 -_- 5.1 버전대의 큰 변동사항은 매뉴얼 하단에 몇줄 박혀있는걸 보았다. (통상 업그레이드 안내측에 위치한다) 그러나 이내용은 여기에 없다. release note, change history 를 당장급한데 수십페이지나되는걸 하나하나 정독하고 있어야할판이다. 혹시 누구 정리한사람있으면 링크하나 던져줬음좋겠다.
이틀 잠도 제대로 못자 정신이 멍하다 -_- 거기다 이놈이 막타를 치는구나.
5.0.45 (몇일전까지 GA 릴리즈였던) 버전에는 메모리 리크 결함이 있다. 지금 사이트에 가보면 5.0.5x 로 버전이 변경되었다. 이녀석이 불러일으킨 트러블이었다. 5.0.45 사용자는 즉시 버전업을 할것.
(private/public) function (펑션명) (데이터 입력부):데이터 반환형식 { 실행문 } 으로 펑션의 구조는 되어있다는것
예제 public function abc (A:String):String 은 A라는 내부변수로 String을 입력받고 String 으로 반환한다는 뜻이다.
QR01 을 마치면 이제 액션스크립트의 모든것을 핸들링할 수 있게 된다.
그러나 플래시 개발자들의 클래스는 언제나 모두 완벽하지 않다. 그렇기 때문에 새로 짜야하는 클래스나, 구조들이 매우 많다.
1. 무비클립도 Class 다.. 뭐 변수타입에 있다면 말다했듯이 마찬가지 이야기다. 그러나 MovieClip 또한 엄격히는 Class 이며, 별도로 이용시 해당 무비클립의 linkage가 활성화되는 순간 as 파일이 생성되도록 되어있다. (그러나 브릿지등에서는 이 기능이 동작하지 않아 잘 모르겠다 실제로 생기는지 어쩐지) 해당 무비클립의 AS 는 별도로 생성된 파일등에서 이용하는것이 올바르다.
이를 위해서는 flash 및 모든 프로그래밍에 호환되는 표준 펑션들을 미리 익힐 필요가 있다.
이러한 펑션들은 ActionScript 3.0 Language / Language Elements / Global Functions, Operators, Statements 등을 참조하라.
기본적인 함수와 변수를 핸들링 하는 함수들이 씌여있다.
2. Sprite 클래스에 대해 알아야 한다. 이녀석은 무비클립이나 기본적인 디스플레이를 핸들링 하기 위해 필요한 기초클래스가 되어있다. 이녀석을 통해 무비클립의 인스턴스들은 객체화하여 배열하거나, 배치순을 조정하거나, 인스턴스간의 상호연동을 꽤할수 있게 되는 부분이다. 따라서 클래스형식의 코딩에 있어 중요한 부분을 차지한다.
이 클래스는 Extends 를 선헌해 사용하면된다.
이 부분의 강의가 끝날 경우 이제 액션스크립트의 이해도는 중반부를 달리게 된다. 나머지는 도움말을 얼마나 많이 보고 익히는가가 전부다.
이 자료는 간단히 플래시 액션스크립트 3.0 에 적응하기 위해 만들어진 Quick Reference로써 이 자료를 이용한 간략한 강의를 목적으로 제작되었으며, 이 자료만으로는 이해가 잘 되지 않을 수 있다.
1. 변수 핸들링
변수 = Variable = 변동하는 수치 (정적이지 않고 변하는 수치)
변수명의 정의(선언)는 var 로 시작한다. 예제코드)
var i=10;
i라는 명칭의 변수에 10이라는 정수를 담는다
흔히 이렇게들 var i=10 이라고 as 2.0 때부터들 많이들 써왔다.
그러나 as 3.0 에서부터 혼동이 오기 시작하고 적응이 잘 안되는게 바로 이 변수선언이나 변수 및 펑션들에 대한 기초가 잡혀있지 않기 때문이다.
변수에는 여러가지 종류가 있다. 이 종류를 컨테이너 내지는 데이터타입, 자료형이라고 한다. 언어마다 조금씩 틀리게 부른다.
var i=10 이렇게 자료형이 없이 선언되는것을 mixed variable 이라고 표현한다. 자동감지식으로써 정수인가 문자열인가 데이터형인가, 어레이인가를 자동감지하여 선언시키는 시스템이다. PHP등지에서 쓰이며 이러한 자동감지식 변수는 감지처리 및 오버라이딩 (재설정행위)로 인한 연산부하가 따라서 걸리게 된다.
이제 어떠한 자료형이 존재하는지 간단히 본다. 아래의 자료형은 대부분의 언어 (php, c, vb, python) 등에서 공용적으로 쓰인다.
정수형 (int) = 숫자만 담는다. 32비트제로 -20억정도부터 20억정도의 수치를 담을 수 있다.
정수형 (Number) - int 와 같다. 그러나 64비트 연산을 제공한다 소수선언은 52비트까지만 연산이 가능한것으로 알고있다. 이녀석을 흔히들 쓰는데 정수형은 c로 치자면 double float이다. 따라서 더 많은 메모리를 사용한다. 흔히 웹디들이 작은 숫자단위에 Number형을 자주 쓰는데 이것은 매우 잘못된 경우다. int 를 써야한다.
정수형 (uint) - unsigned int 를 의미한다. -20억~20억까지의 수치가 아니라, 0부터 40억까지 표현하게 된다. 따라서 20억이상의 수치를 표현하기 위해서는 uint 를 쓰는것이 좋다.
불린형 (Boolean) - True ? False 혹은 1 ? 0 을 의미한다. 스위칭등의 변수로 사용할때 많이 쓴다.
문자형 (String) - UTF-16 캐릭터셋을 기본으로 하는 문자열이 저장된다. 문자형을 삽입할때는 "" 등의 쿼테이션이 필수다. 기본은 Null 이며, UTF-8 이나 euckr 등으로 캐릭터셋을 변경시킬수 있다. (시스템 함수를 통해)
void형 (void) - c에서와 유사한 형식으로 돌고있는데, void 는 특정한 값을 담고있지 않는다. 엄밀히는 펑션의 결과를 반환하거나, 펑션을 포인팅하는데 사용된다. 클래스 등지에서 이용되며, 이때 return 문이 삽입되어야 한다.
배열형 (Array) - 간단한 자료구조를 포함하는 형식이다. 이를 배열이라고 하며, 배열에 대해서는 별도의 강의가 필요하다. 기초적인것은 10명의 이름을 하나의 변수에 서로 구분되게 넣는 경우로 보자 var test:Array = new Array('홍길동','동길홍','가나다','마바사'); 이러한 형식으로 저장하고 호출할때는 test[0] 이나 test[숫자] 로 호출이 가능하다. 물론 숫자는 해당 레코드를 정확히 지칭하여야 한다.
또 간단히 설명하자면 액셀의 한 행과 같다. 액셀에서 1행의 A열, B열, C열을 이름, 전화번호, 주소 라고 설정했다치다. 그렇다면 이것은 어레이로
var test:Array = new Array(); test[0]['이름']='홍길동'; test[0]['주소']='뭐뭐뭐'; test[0]['전번']='뭐뭐뭐'; test[1]['이름']='음음음';
의 형식으로 표현이 가능하다. test[0]['이름'] 에서 앞의 0은 행번호다. 뒤에 이름은 열이름이라고 보면된다. 이를 적절히 매핑하는것을 더블포인팅 어레이 또는 어소시에이티브 어레이라고한다.
함수형 (Function) - 펑션타입의 변수다. 즉, 변하는 수가 아니라 실행되는 구문이 삽입되는것이다. {}로 실행구문을 인덴트하여야 한다. 흔히 말하는 프로그램이 이 펑션에 속한다.
오브젝트형 (Object) - 글로 설명하기가 복잡하지는 시점이다 오브젝트는 말그대로 위에 해당하는 모든것을 담게된다. Mixed var 형식인데, 흔히들 클래스를 오브젝트라고 표현한다. 이 변수는 하나의 명칭으로 다양한 기능을 포괄시킬수있다.
var A:Object = new Object(); A.i = 10; A.b = "스트링";
등으로 정의할수가 있을지는 모르겠다 --;; 이런식으론 사실 안해봤다.
그러나 위처럼 A라는 변수안에 i라는 추가 정수형 변수와 b 라는 문자형 변수가 혼재된다. 즉 말그대로 오브젝트를 포괄하는 형식이다. 이 형식을 대표적으로 이용하는것이 클래스라고 부른다.
클래스형 (Class) - 클래스는 기선언된 하나의 오브젝트 집합체다. 그 안에 다양한 변수와 다양한 함수를 프로그래밍하여 이를 이용할수가 있다. 위에 오브젝트에 대한 설명과 동일하다.
간단한 클래스를 예로든다.
class test { public var a:string = "문자열 테스팅 성공입니다"; function test() { trace("클래스가 시작되었습니다"); } function test_start() { trace(this.a); } }
이렇게 클래스를 선언한다.
클래스를 호출하는것은 간단하다. 향후 메모리관리자 쉬운 액세스를 위해 클래스는 변수형으로 주로 요청한다.
var gogogo:test = new test();
여기서 첫 :test 는 클래스명을 지칭한다. 그러나 복잡하게 갈수록.. 굳이 클래스명이 아니기도 한다는 사실;; 그 다음에 new test() 는 test 라는 클래스의 새로운 선언과 함수의 실행을 의미한다.
그렇다면 저렇게 선언을 하기만 하여도 test() 펑션이 구동한다. 따라서 바로 화면에 클래스가 시작되었습니다. 라는 문구가 표기된다.
그 다음 test_start 라는 펑션을 구동시켜보자
gogogo.test_start();
라고 실행을 하면 문자열 테스트 성공입니다 라고 출력된다.
즉 gogogo 라고 선언된 variable 이 object 타입으로써 하단부에 클래스가 돌고있는것이다. 변수가 꼭 변하는 수만이 아니라 이런형식으로 프로그래밍도 가능하다는 사실을 잊어서는 안된다 ;;
예를들어 a 라는 변수가 function 으로 +10 씩 가중시킨다고 할 경우
var a:Function = function(p:uint) { return p+10; };
1. 이것은 윈도우 비스타에서 Winamp 를 사용하는 사람중, Microsoft 의 내츄럴 어고노믹스 4000 내지는 이에 준하는 미디어 키를 가진 사용자를 위한 퀵 리퍼런스다.
This quick reference is refered to user what use Microsoft Windows VISTA, Winamp, Microsoft's keyboard which providing media play or play/pauseable key.
2. Winamp 의 Global HOT KEY 를 키면 에러로 인해 Play/Pause 기능을 등록할 수 없다는 메시지가 출력된다.
If can't register serveral hotkeys like~~ play/pause when enable global hot key on winamp, you can solve issue. read next
3. 이것은 Intellitype 의 프로세스가 후킹을 제어하고 있기 때문이다. the intellitype process(itype.exe) persist hooking the hotkey register.
TODO/해결법
1. 작업관리자를 실행한다 (CTRL+ALT+DEL -> ALT+T) / start taskmanager 2. itype.exe 프로세서를 찾아 프로세서 끝내기를 한다. / kill process which name itype.exe 3. Winamp 를 킨다 / Starting Winamp 4. CTRL+P 를 눌러 preference를 열고 global hotkey 를 enable 한다 / enable global hotkey on winamp preferences. 5. 에러메시지가 없이 모든 핫키가 등록된것을 볼수있다 / it will be enable hotkey clearly (nomesages) 6. itype.exe 를 다시 실행한다 / restarting itype.exe (if you don't know, just "RUN->itype.exe" on taskmanager 실행은 단축아이콘 혹은 태스크 매니저에서 실행 / itype.exe를 하면된다.
미해결 문제점 / Unresolved Issue Winamp is always try to re-registering global hot keys (reset to default keymaps on restarting vista). also you need to repeat those Todo process when you rebooting the system. It CANNOT fix to reordering Windows registry ( HKLM/windows/current~/run to HKSW ) winamp agent doesn't have function to registering hotkeys. so reoder is useless.
윈앰프는 재시작 할때마다 글로벌 핫키를 다시 재등록하는 과정을 걸치므로 리부팅을 한 뒤에는 위의 절차를 다시 반복해야 한다. 이는 레지스트리를 수정하여도 해결되지 않는다 (HLKM 의 winamp agent 시작프로그램을 HKSW의 상위쪽으로 이동하는 작업) winamp agent 는 글로벌 핫키를 재등록하는 펑션을 가지고 있지 않기 때문에 이 재배치 과정은 무의미하다.
Windows7-USB-DVD-tool.exe
