사람들은 특히 앱 속도가 몇 초 동안 느려지거나 정지되는 경우 앱 충돌을 싫어합니다. Dimensional Research의 조사에 따르면 사용자의 61%는 프로그램이 4초 이내에 시작될 것으로 예상하고, 49%는 입력이 2초 이내에 응답할 것으로 기대합니다. 앱이 충돌하거나 정지되거나 오류가 보고되면 사용자의 53%가 앱을 제거합니다.
소비자를 대상으로 하든 기업을 대상으로 하든 충돌 문제는 그들을 완전히 실망시킬 수 있습니다. 일부 모바일 개발자와 이야기를 나누고 그들이 직면한 가장 일반적인 충돌 문제가 무엇인지 물었고 그들은 6가지 일반적인 원인을 찾아냈습니다.
1. 메모리 관리
제가 질문한 모든 사람이 메모리 관리에 관해서라면 대부분의 앱은 시스템 메모리를 차지하기 위해 많은 스레드를 시작합니다. OpsClarity의 마케팅 부사장인 Sachin Agarwal은 프로그래머가 자신이 작성하는 앱이 앱에 있는 유일한 앱인 것처럼 코드를 작성할 수 있다고 말했습니다. 동시에 프로그램을 작성할 때 "좋은 시민"이 되는 것을 고려해야 한다고 제안했습니다. 애플리케이션 생태계에서." .
메모리 문제는 모든 개발자에게 동일하지 않습니다. Solstice Mobile의 비즈니스 개발 부사장인 Andrew Whiting은 "iOS에서는 Objective-C를 활용하여 대용량 메모리 문제를 처리할 수 있습니다."라고 말했습니다. 하지만 장점과 단점을 따져볼 필요가 있습니다. "Android에서는 [메모리]에 대한 더 깊은 제어가 필요하며 원하는 대로 정확하게 수행할 수 있지만 이로 인해 복잡성이 추가됩니다."
"Java에서 메모리 부족을 경험하는 것은 일반적으로 다음과 같은 것과 관련이 있다는 것을 알았습니다. New Relic의 수석 소프트웨어 엔지니어링 관리자인 Jonathan Karon은 이렇게 말했습니다. 문제의 일반적인 원인은 Mobile SDK 기술 성능 보고서에 정리되어 있습니다. "실제로 Android에는 클래스를 찾을 수 없거나 분류되지 않은 링크라는 예외가 있는 링커 문제처럼 보이는 것이 놀라울 정도로 많습니다." 반면에 iOS 앱은 NSInternalInconsistency 예외의 영향을 받는 경우가 많습니다. 개발자가 한 곳에서 데이터 배열이나 컬렉션을 변경하는 동안 다른 곳에서 해당 항목의 목록을 읽고 있기 때문입니다.
2. 소프트웨어 수명 주기
반복적인 애플리케이션 개발 프로세스와 빈번한 버전 출시는 최소한의 실행 가능한 제품이 시장에 진입한 다음 시간이 지남에 따라 개선될 수 있는 기회를 열어줍니다. 이는 오늘날 매우 인기가 있습니다. 그러나 기존 소프트웨어 수명주기는 운영 체제 및 타사 API에 대한 의존성으로 인해 더욱 복잡해졌습니다.
“최신 Android 업데이트를 보면 앱 충돌이 많이 발생합니다.”라고 Agarwal이 말했습니다. "운영 체제 자체가 불안정하거나 운영 체제가 업데이트되었지만 애플리케이션이 업데이트되지 않았습니다." 또는 사용자가 새 버전을 다운로드하지 않습니다. "이를 제어할 수 없습니다. 이는 핵심 개발 프로세스를 보여줍니다." 모바일 및 클라우드 컴퓨팅 개발 타사 서비스 및 관련 API의 사용이 증가하면 시간이 절약되고 애플리케이션을 더 빠르게 시장에 출시하는 데 도움이 되지만 고유한 문제가 발생합니다.
"많은 도서관에는 공통된 문제가 있습니다"라고 Whiting은 말했습니다. "그들은 누구에게나 최상의 솔루션을 제공하기보다는 모든 사람의 문제를 해결하려고 노력합니다." 예를 들어 특정 API는 특정 애플리케이션에 대한 성능 제한을 가질 수 있습니다.
API는 iOS 메서드 조정과 같은 까다로운 기술을 사용할 수도 있습니다. 원본 코드(예: Apple API)를 사용할 수 없는 경우 개발자는 원본 코드(예: Apple API)를 기반으로 수정합니다. 온라인 여행사인 Fareportal의 모바일 책임자인 Raman Bhatia는 "이것은 iOS 앱 개발의 '암흑술' 중 하나라고 할 수 있습니다."라고 말했습니다. "[그러나] 애플리케이션 코드가 특정 방식으로 작성되면 충돌이 발생할 수 있습니다.
API는 다른 문제도 일으킬 수 있습니다." Agarwal은 "API 대기 시간, 오류율, 데이터 대역폭, API 버전 및 API 요청 수는 모두 작은 문제로 인해 큰 문제로 이어질 수 있습니다."라고 말했습니다. 그런 다음 모든 것을 추적하기 위해 특수 도구가 필요한 API 자체가 있습니다.
API는 메모리 오류와 같은 다른 문제를 일으킬 수도 있습니다. "다른 개체를 만들기 전에 메모리에서 제거된 개체를 만드는 경우 일반적으로 문제가 되지 않지만, 후속 개체가 삭제된 개체를 참조해야 하는지 여부는 알 수 없다는 점에 유의하세요." 타사 프레임워크를 사용하면 문제가 발생합니다. 공동 창립자이자 개발자인 Long Le는 "무엇을 정리하고 있는지, 무엇을 만들고 있는지 결코 확신할 수 없습니다."라고 말했습니다.
3. 불충분한 테스트
테스트 필요성은 분명하지만 점점 더 늘어나고 있습니다. 특히 다수의 Android 버전과 기기의 경우 적절한 적용 범위를 확보하는 것이 어려울 수 있습니다. 에뮬레이터가 있더라도 서버에서 실행되는 소프트웨어의 성능 제한은 실제 시스템의 성능 제한과 다를 수 있습니다.
예를 들어, 애플리케이션의 한 스레드가 데이터베이스를 읽는 동안 두 번째 스레드가 동일한 데이터베이스를 수정하려고 시도하는 경우 Couchbase의 모바일 수석 설계자 Wayne Carter는 "타이밍의 문제입니다"라고 말했습니다. "동시에 충돌하지 않으면 이 문제는 발생하지 않으며 로그 설명으로 덮을 수 있습니다." 시뮬레이터는 종종 실제와 동일하게 작동하지 않습니다.
다양한 기기에서 다양한 시스템을 실행하는 것이 가능한 솔루션이지만 이 방법은 에뮬레이터보다 비용이 더 많이 듭니다. 이를 위해서는 예산과 요구 사항 간의 균형이 필요합니다
테스트에는 개발자와 사용자가 콘텐츠를 수용할 수 있도록 업계 표준과 사용자 기대치에 대한 벤치마크가 통합되어야 합니다. 테스트도 계속 진행되어야 합니다. 성능을 모니터링하고 사용자 피드백을 찾은 다음 가능한 한 빨리 문제를 해결하십시오.
4. 네트워크 관리
데이터든 타사 서비스든 애플리케이션이 네트워크에 점점 더 의존하게 되면서 네트워크 관리가 문제의 원인이 되었습니다.
충돌이 발생하는 주된 이유는 데이터를 얻고, 무언가를 제출하고, 복구를 기다리는데 앱이 응답하거나 중단될 때입니다. 운영 부사장인 Pravin Vazirani는 개발자가 Wi-Fi 연결을 매우 기능적으로 만들었을 수도 있지만 사용자가 네트워크 상태가 좋지 않은 지역에 있으면 문제가 발생할 수 있다고 말했습니다.
네트워크 문제를 해결하는 좋은 방법은 사용자에게 연결을 알리는 것입니다. 중단하고 가능하다면 관심을 가질 수 있는 다른 작업을 수행할 수 있는 기회를 제공합니다. 사람들이 응용 프로그램의 통제를 벗어난 일시적인 상태의 원인을 이해한다면 침착함을 유지하고 소프트웨어에 짜증을 내지 않을 가능성이 더 높습니다.
5. 오류 조건 및 예외 처리
모바일 개발의 복잡성으로 인해 예기치 않은 API 변경, 이전에 감지된 메모리 문제 방지, 네트워크 연결 조건 또는 대용량 파일 전송(예: 이미지 또는 동영상으로)
이 경우 가장 좋은 방법은 오류 및 예외 처리를 잘하는 것입니다. 예를 들어, 사용자가 잘못된 데이터를 입력하거나 값을 제공해야 할 때 텍스트 상자에 텍스트를 제공하면 응용 프로그램이 실수로 시도되지 않고 오류를 보고합니다.
이러한 상황에서 올바르게 코딩된 애플리케이션은 예상치 못한 상황을 감지하고 사용자에게 오류를 알리는 동시에 프로세스나 활동을 정상적으로 종료합니다. 커뮤니케이션 라인을 열어두면 사용자를 유지할 가능성이 더 높아집니다.
6. 코드가 너무 많습니다.
가장 좋은 조언은 애플리케이션을 단순하게 유지하는 것입니다. 특정 목적에 맞는 플러그인을 찾아 플러그인을 사용하고 필요한 코드를 작성하세요. 엔터프라이즈 모바일 개발 회사인 Lextech Global Services의 수석 시스템 엔지니어인 Felipe Laso-Marsetti는 "가장 버그가 없는 최고의 코드는 직접 작성하지 않는 코드입니다."라고 말합니다.
위 내용은 앱이 충돌하는 6가지 일반적인 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!