크로스 플랫폼이란 무엇인가요?
크로스 플랫폼은 일반적으로 여러 운영 체제 또는 다양한 하드웨어 아키텍처가 있는 컴퓨터에서 프로그래밍 언어, 소프트웨어 또는 하드웨어 장치를 실행할 수 있는 기능을 의미합니다.
넓은 의미에서 일반 컴퓨팅 언어는 크로스 플랫폼이 가능하며 개발자는 다양한 플랫폼에 대한 런타임/미들웨어 환경만 제공하면 됩니다. 엄밀히 말하면, 특정 컴퓨터 언어로 컴파일된 프로그램은 약간의 수정만 하면 되고, 컴파일 후에는 다른 플랫폼에서 실행될 수 있다는 의미입니다. 이때 런타임/미들웨어 환경은 제공되지 않습니다. 예를 들어, Java는 런타임 환경을 제공하는 크로스 플랫폼 솔루션인 반면, C는 표준적이고 엄격한 크로스 플랫폼 언어입니다.
크로스 플랫폼 개념은 운영체제나 하드웨어 환경에 구애받지 않는 소프트웨어 개발에 있어 중요한 개념이다. 한 운영 체제에서 개발된 응용 프로그램은 다른 운영 체제에서도 계속 실행될 수 있습니다. 상대적으로 말하자면, 특정 컴퓨터 언어가 코드를 수정하지 않고도 고도로 크로스 플랫폼이 될 수 있다면 언어는 더욱 추상화되고 하드웨어 제어 수준은 낮아질 것이며 고도로 추상적인 모델 시스템을 개발하는 데에만 적합할 것입니다. Java, Delphi 및 쉬운 언어와 같은 크로스 플랫폼을 구현했습니다. 다양한 시스템 하에서 개발, 실행 및 유지 관리가 가능합니다.
대부분의 컴퓨터 언어는 절대적인 의미에서 크로스 플랫폼입니다. 사람이 읽을 수 있는 높은 수준의 방식으로 CPU에 명령을 내리기 때문에 운영 체제에 의존할 필요가 없습니다. 그러나 시스템의 구성 요소 도구 상자를 사용하여 새로운 그래픽 사용자 인터페이스(GUI)를 생성하려는 경우 개발자의 특정 시스템에서 API 함수나 라이브러리 클래스를 사용할 수 있습니다. C는 크로스 플랫폼이지만 Windows에서 Win32 API를 사용하는 C 프로그램은 일반적으로 Unix 시스템에서 컴파일할 수 없습니다. 또한 컴파일러마다 언어 사양을 다르게 해석합니다. 이 경우 다른 시스템을 구축하기 전에 프로그램을 고려해야 합니다.
Java 등 일부 언어는 처음부터 다양한 플랫폼에서 실행되어야 한다는 점을 인식하여 해당 플랫폼의 로컬 언어 환경에서 크로스 플랫폼을 구현했습니다. 예를 들어 Java는 Swing 라이브러리가 여러 플랫폼에서 구현되기 때문에 크로스 플랫폼에서 사용할 수 있습니다. 마찬가지로, 각 플랫폼별로 파일 접근을 위한 라이브러리가 있기 때문에 크로스 플랫폼 파일 접근이 가능합니다. 비유하자면, 다양한 크로스 플랫폼 문제를 해결하려면 자체 로컬 라이브러리가 필요합니다. wxWidgets 프레임워크는 다양한 크로스 플랫폼 문제에 따라 다양한 솔루션을 제공하는 크로스 플랫폼 라이브러리입니다. 유사한 라이브러리가 많이 있으며 해당 라이브러리는 다양한 언어의 크로스 플랫폼 개발에 따라 사용될 수 있습니다.
각 운영 체제와 CPU에 대해 컴파일된 버전을 제공하고 테스트할 가능성은 거의 없습니다. 오픈 소스 소프트웨어를 사용하면 사용자가 직접 개체 코드를 컴파일할 수 있으므로 크로스 플랫폼이 더 좋습니다. 마찬가지로, 해석된 언어 또는 가상 머신이 필요한 언어는 사용자가 직접 컴파일해야 하기 때문에 크로스 플랫폼 요구 사항에 더 부합합니다. Sun의 Java 가상 머신 Hotspot은 모든 플랫폼이 아닌 일부 플랫폼에 대해서만 컴파일된 바이너리 파일을 제공합니다. 예를 들어 Sun은 GNU/Linux용 i386 플랫폼만 지원하지만 PowerPC 또는 SPARC 컴퓨터에서 Linux를 실행하는 경우 로컬 기계어 코드를 직접 컴파일하거나 타사 소프트웨어를 사용하여 Java 프로그램을 실행해야 합니다.
많은 API(애플리케이션 프로그래밍 인터페이스)는 플랫폼에 따라 다릅니다. OpenGL은 특정 운영 체제, CPU 아키텍처 또는 그래픽 장치 브랜드에 의존하지 않기 때문에 크로스 플랫폼으로 간주될 수 있습니다. 플랫폼별 API는 WINE 라이브러리와 같은 다른 시스템에서 호환성 계층으로 생성될 수 있으므로 Windows 프로그램이 UNIX 시스템에서 실행될 수 있습니다.
또한 많은 프로그래밍 언어에는 크로스 플랫폼 확장과 미들웨어가 있으므로 프로그래머는 Qt와 같이 동일한 소스 코드에 대해 몇 가지 사소한 수정만으로 다른 플랫폼에서 컴파일/실행할 수 있습니다. 그리고 wxWidget.
여러 운영 체제를 지원하는 소프트웨어
1. 데이터베이스 관리 시스템(DBMS):
MySQL: Solaris, Linux, Windows, FreeBSD
Oracle: Solaris, Linux, Windows
2. 웹사이트 서버, 애플리케이션 서버:
Apache: Solaris, Linux, Windows, FreeBSD
Tomcat: Linux , Windows, FreeBSD
3. 인터넷 브라우저:
Mozilla Firefox: Linux, FreeBSD, Solaris, AIX, Windows,
가능한 프로그래밍 언어 다양한 운영 체제에서의 소프트웨어 개발에 사용
C 언어, C, Java
Perl, Tcl, Erlang
Python, Delphi Kylix, REALbasic
교차 플랫폼 Java 애플리케이션 개발에는 다음과 같은 5가지 측면이 포함됩니다.
1. 교차 애플리케이션 서버
2 교차 운영. 시스템
4. 크로스 브라우저
5. 다중 언어 지원
각각 따로 이야기해 보겠습니다.
■교차 애플리케이션 서버
이 점은 약간 중복되는 것 같습니다. Java의 슬로건 중 하나가 "한 번 컴파일하고 외부에서 실행"하는 것이 아닌가? 단지 슬로건일 뿐이다. 실제로는 "한 번 컴파일하고 모든 곳에서 디버그"하는 것입니다. 왜 이런 일이 발생합니까? 애플리케이션 서버의 경우 각 제품은 표준 Java 사양에 따라 다소 확장됩니다. 소규모 애플리케이션 개발은 대부분 Tomcat을 기반으로 하며, 대규모 애플리케이션은 대부분 WebLogic/WebSphere를 기반으로 합니다.
개발한 애플리케이션을 모든 애플리케이션 서버에 정상적으로 배포할 수 있나요? 대답은 '아니요'입니다. tomcat5에는 문제가 없지만 tomcat4에는 문제가 있을 수 있습니다. tomcat5/4에는 문제가 없지만 resin/jetty/weblogic/websphere에는 문제가 있을 수 있습니다. 내 경험상 레진/제티/웹로직을 벤치마크로 사용하여 개발된 애플리케이션은 tomcat에 배포할 때 기본적으로 문제가 없습니다. 그러나 Tomcat 기반의 애플리케이션이 다른 애플리케이션 서버에 배포되면 다양한 문제가 발생할 수 있다. 이는 Tomcat 자체의 포지셔닝 및 개발 방법과 관련이 있습니다. 상용 제품이라기보다는 학문적인 제품에 가깝습니다.
작은 용도로는 레진을 선호하는데 속도, 안정성, 호환성, 중국산 가공 모두 매우 좋습니다. 이에 비해 "순수한 자바와 빠른 속도"로 알려진 부두는 그다지 만족스럽지 않습니다. 다양한 버전의 jetty 4/5/6에는 세션, web.xml 표준, Struts 플러그인 지원 및 log4j 처리를 위한 저장 위치가 다릅니다. 최신 jetty6에는 끔찍한 "session.validate()" 메서드가 있습니다. 이 메서드를 사용하면 더 이상 set/getAttribute를 사용할 수 없습니다.
나도 websphere5로 애플리케이션을 옮기는 데 어려움을 겪었다. 이 애플리케이션은 다른 애플리케이션 서버에서는 잘 실행되지만 일단 ws5에 배포되면 Struts 구성 파일을 정상적으로 로드할 수 없습니다. Struts 구성 파일에 문제가 있는 줄 알았는데, Action/Form 구성을 모두 제거하고 빈 구성 파일만 남더라도 정상적으로 시작되지 않더군요.
결국, struts의 여러 jar 패키지 버전에 문제가 있는지 생각해 볼 수밖에 없었습니다. 확인 결과 struts1.2의 jar 패키지가 응용 프로그램에서 사용되는 것을 발견했습니다. struts1.1의 jar 패키지로 이동한 후 다시 시작했습니다. 그런 질문은 정말 고통스럽습니다.
그래서 크로스 애플리케이션 서버가 매우 중요하다고 생각합니다. 우리 시스템이 tomcat에서만 실행될 수 있다고 고객에게 말할 수는 없습니다. 많은 돈을 들여 구매한 weblogic/websphere에 대해서는 죄송합니다. 아직 지원하지 않습니다. 고객은 피를 토할 것입니다.
■교차 데이터베이스
Oracle이나 SQL Server 데이터베이스를 사용해야 하는 대기업 제품을 자주 봅니다. 배포를 위해 데이터베이스를 변경하시겠습니까? 설마, 우리 제품은 이런 종류의 데이터베이스만 지원한다고 사람들이 말하더군요. 그러니 그냥 정직하게 사용하세요. 하지만 고객의 입장에서는 투자를 줄이고 내부 시스템이 가능한 한 동일한 데이터베이스를 사용하여 유지 관리 비용을 줄이려면(Oracle DBA를 고용한 다음 SQLserver DBA를 고용할 수는 없겠죠?) 새 시스템에서 사용하는 데이터베이스입니다. 이전에 사용된 적이 있어야 합니다.
이제 hibernate가 가능해졌으므로 이를 기반으로 개발된 애플리케이션은 기본적으로 데이터베이스 간 요구 사항을 충족할 수 있다는 것이 개인적으로 hibernate의 가장 큰 특징이라고 생각합니다. 하지만 개발 시에는 다양한 데이터베이스의 특성을 최대한 고려해야 한다는 점에도 유의해야 합니다. 예를 들어 sqlserver의 text/image 필드에서는 고유한 항목을 검색할 수 없으며 Oracle의 다양한 개체 이름의 길이는 30을 초과할 수 없습니다. 데이터베이스의 내부 기능(예: 저장 프로시저, 뷰, 등)
■교차 운영 시스템
이에 대해서는 말할 것도 없을 것 같습니다. 하나의 운영 체제에만 배포할 수 있는 개발된 시스템은 거의 없습니다. 그러나 시스템의 일부 기능이 인쇄, 워드/엑셀 작업, Windows에서만 실행할 수 있는 보고 구성 요소(예: 국내 디지털 보고서) 등 JNI를 통한 Windows 로컬 구성 요소 호출에 의존하는 경우 Ruyi는 보고서)가 통합되었습니다.
■크로스브라우저
그냥 국내 어플리케이션이라면 이런 것도 중요하지 않고, IE를 표준으로 삼아 개발하는 것도 나쁘지 않다고 생각합니다. .
PS: IE5/6 자체를 완전히 지원하는 것은 쉽지 않습니다.
그러나 제품 자체가 세계에서 발판을 마련하고 외국 제품과 경쟁하려면 브라우저에 대한 전폭적인 지원도 필수적이다. 최소한 IE와 Firefox를 모두 지원해야 합니다. 엄격한 요구사항이 있는 경우 Opera의 HTML/CSS/Javascript 표준이 구현하고 지원하기에 가장 좋은 브라우저라고 생각합니다.
■다국어 지원
귀하의 제품이 중국에서만 판매되기를 원하고 세계 시장을 전혀 고려하지 않는다면 이것은 좋은 통과입니다.
플랫폼에 관계없이 Java 프로그램을 사용할 때 주의해야 할 사항은 무엇입니까?
Java 언어를 사용하여 애플리케이션을 작성하는 가장 큰 장점은 "한 번 컴파일하면 어디서나 실행 가능"하다는 것입니다. 모든 Java 프로그램에 크로스 플랫폼 기능이 있다는 의미는 아닙니다. 실제로 Java 프로그램의 상당 부분이 다른 운영 체제에서 올바르게 실행될 수 없습니다. 그렇다면 진정한 크로스 플랫폼 Java 프로그램을 작성하려면 다음이 필요합니다. 크로스 플랫폼 Java 프로그램 주의할 사항:
1. Java 크로스 플랫폼 애플리케이션을 작성할 때 이를 지원하는 JDK1.0, 1.1, 1.2 또는 다음과 같은 GUI 개발 도구를 선택할 수 있습니다. , VisualAgeforJava 등이 있지만 주의해야 합니다. Java 프로그램은 Java 코어 API 패키지만 사용할 수 있습니다. 타사 클래스 라이브러리 패키지를 사용하려면 클래스 라이브러리 패키지도 Java 코어 패키지로 개발해야 합니다. 그렇지 않으면 프로그램을 게시할 때 Java를 지원해야 합니다. 클래스 라이브러리 패키지의 JVM이 릴리스됩니다.
즉, 귀하의 프로그램은 100 순수 Java여야 합니다. 예를 들어 VisualJ는 순수 Java가 아니며 VisualJ로 작성된 프로그램은 플랫폼 독립적이지 않습니다.
2. JDK를 사용하든 다른 개발 도구를 사용하든 컴파일 시 모든 경고 옵션을 켜야 컴파일러가 가능한 한 많은 플랫폼 관련 문을 발견하고 경고를 표시할 수 있습니다. 컴파일 타임 경고 오류가 없는 프로그램이 크로스 플랫폼이라는 보장은 없지만, 경고 오류가 있는 프로그램은 플랫폼에 독립적일 가능성이 매우 높습니다.
3. 프로그램에서 어떤 메소드를 사용하든, 사용하는 메소드가 문서에 폐기된 메소드(Deprecated 메소드)로 선언된 메소드가 아닌지, 문서를 자세히 확인하세요. 문서에 표시되지 않은 방법입니다.
4. Java 프로그램을 종료할 때 java.lang.System의 종료 메소드를 사용하지 마십시오. Exit 메소드는 JVM을 종료하여 프로그램을 종료할 수 있지만, 다른 Java 프로그램이 동시에 실행 중인 경우 종료 메소드를 사용하면 프로그램도 닫히게 되는데 이는 분명히 우리가 보고 싶은 결과가 아닙니다. 실제로 Java 프로그램을 종료하려면 destroy()를 사용하여 독립적으로 실행 중인 프로세스를 종료할 수 있습니다. 다중 스레드 프로그램의 경우 데몬이 아닌 스레드는 각각 닫혀야 합니다. 프로그램이 비정상적으로 종료된 경우에만 종료 메소드를 사용하여 프로그램을 종료하십시오.
5. 로컬 메소드와 로컬 코드를 사용하지 말고, 해당 기능을 최대한 활용하여 자체 Java 클래스를 작성하고 메소드를 다시 작성하세요. 꼭 이 로컬 메소드를 사용해야 한다면 서버 프로그램을 작성하여 이 메소드를 호출한 후 지금 작성 중인 프로그램을 서버 프로그램의 클라이언트 프로그램으로 사용하거나 CORBA(Common Object Request Agent) 프로그램 구조를 고려해 볼 수 있습니다.
6. Java에는 Delphi의 winexec과 유사한 메소드가 있는데, java.lang.runtime 클래스의 exec 메소드입니다. 메소드 자체는 플랫폼 독립적이지만, 메소드 및 명령 매개변수는 플랫폼과 관련되어 있으므로 프로그램 작성 시에는 사용하지 마십시오. 다른 프로그램을 호출해야 하는 경우에는 사용자가 명령과 해당 매개변수를 설정하도록 해야 합니다. 예를 들어 Windows에서는 notepad.exe 프로그램을 호출할 수 있지만 Linux에서는 vi 프로그램을 호출해야 합니다.
7. 모든 운영 체제가 크로스 플랫폼 Java 중국어 소프트웨어 프로그램에 대해 언급해야 하는 유니코드 문자 세트를 지원하는 것은 아니기 때문에 프로그래밍의 모든 정보는 ASCII 문자 세트를 사용해야 합니다.
8. 줄 구분 기호, 파일 구분 기호, 경로 구분 기호 등과 같은 플랫폼 관련 상수를 프로그램에 하드 코딩하지 마십시오. 이러한 상수는 파일과 같은 플랫폼에 따라 다릅니다. UNIX 및 MAC에서는 "/", Windows에서는 "\" 이러한 상수를 사용하려면 java.util.Properties.getProperty("와 같은 jdava.util.Properties 클래스의 getProperty 메소드를 사용해야 합니다. file .separator")는 파일 구분 기호를 가져올 수 있고, getProperty("line.separator")는 줄 구분 기호를 반환하고, getProperty("path.separator")는 경로 구분 기호를 반환합니다.
9. 크로스 플랫폼 네트워크 프로그램을 작성할 때 호스트 이름을 얻기 위해 java.net.InetAddress 클래스의 getHostName 메소드를 사용하지 마십시오. 플랫폼마다 호스트 이름 형식이 다르기 때문입니다. 동일한 형식의 IP 주소를 얻으려면 getAddress를 사용하는 것이 가장 좋습니다. 또한 프로그램의 모든 호스트 이름을 IP 주소로 바꿔야 합니다. 예를 들어 www.263.net은 해당 IP 주소로 바꿔야 합니다. .
10. 파일 작업과 관련된 프로그램은 주의가 필요합니다. 프로그램에서 파일 경로를 하드 코딩하지 마십시오. 이유는 8과 동일하지만 이 점이 특히 중요하므로 언급합니다. 갈라져. 또한 플랫폼마다 파일 이름에 사용되는 문자 및 최대 파일 이름 길이에 대한 요구 사항이 다릅니다. 프로그램을 작성할 때 파일 이름으로 일반 ASCII 문자를 사용해야 하며 기존 프로그램과 동일한 이름을 가질 수 없습니다. 플랫폼에서 그렇지 않으면 충돌이 발생합니다.
11. 작성하는 프로그램이 GUI 프로그램인 경우 AWT 컴포넌트를 사용할 때 컴포넌트의 크기와 위치를 엄격하게 설정할 수 없으며 대신 Java의 레이아웃 관리자(layoutmanager)를 사용하여 설정하고 설정해야 합니다. 시각적 구성 요소의 크기와 위치를 관리하지 않으면 레이아웃 혼란이 발생할 수 있습니다.
12. 서로 다른 운영 체제와 시스템이 서로 다른 색상, 화면 크기 및 해상도를 지원하므로 이러한 속성을 얻는 방법은 java.awt.Systemcolor 클래스를 사용하여 필요한 색상을 가져오는 것입니다. class는 창 테두리에 있는 활성 제목의 배경색이고, menu는 메뉴의 배경색입니다. java.awt.Toolkit의 getScreenResolution을 사용하여 화면 해상도를 "인치당 픽셀 수"로 표시합니다. 이 클래스의 GetScreenSize는 화면 크기(인치)를 가져올 수 있고, loadSystemColors는 모든 시스템 색상을 나열할 수 있습니다.