Android 또는 iOS 애플리케이션이 이전에 도메인 이름 A에 요청을 보냈고 이제는 도메인 이름 B를 변경해야 합니다. Android를 다시 패키징하는 것보다 더 나은 솔루션이 있습니까?

리패키징하면 사용자가 반드시 앱을 업데이트하지 않을 수 있으므로 이 솔루션은 별로 좋지 않습니다

물론, 디자인 초기부터 안드로이드 애플리케이션에서 요청한 도메인 이름을 설정하는 것이 가장 좋습니다. 그렇다면 이 문제를 어떻게 해결해야 할까요? 즉, 로컬 코드를 덮어쓰기 위해 코드 조각을 다운로드할 수 있습니까? 이것이 보안 문제입니까?

답글 내용:

리패키징하면 사용자가 반드시 앱을 업데이트하지 않을 수 있으므로 이 솔루션은 별로 좋지 않습니다

물론, 디자인 초기부터 안드로이드 애플리케이션에서 요청한 도메인 이름을 설정하는 것이 가장 좋습니다. 그렇다면 이 문제를 어떻게 해결해야 할까요? 즉, 로컬 코드를 덮어쓰기 위해 코드 조각을 다운로드할 수 있습니까? 이것이 보안 문제입니까?

그럼 인터페이스 작성자에게 도메인 이름 A에서 도메인 이름 B로 요청을 보내고 데이터를 돌려달라고 요청하면 됩니다. 하하, 다시 포장하는 것이 번거롭나요? 모바일 개발을 이해하지 못함

앱 시작 시 백그라운드 데이터를 한 번 요청할 수 있습니다. 레이블을 설정하고, 1이면 A 주소를 로드하고, 0이면 B 주소를 로드합니다.

이미 온라인 지원서를 제출한 경우에 해당됩니다. 따라서 기본적으로 해결책은 하나뿐입니다. 백엔드 개발자가 열심히 일하고 A 지점으로 전송된 모든 요청을 B 지점으로 리디렉션하고 응답 데이터를 반환하도록 하는 것입니다. 참고: 이러한 데이터 형식을 불필요하게 변경하지 않는 것이 가장 좋습니다. 그렇지 않고 내결함성이 충분하지 않으면 충돌이 발생합니다.

물론 애플리케이션 자체에는 이 문제를 해결할 수 있는 방법이 있지만 사전에 아키텍처적으로 설계되어야 합니다. 예를 들어 iOS와 Android 모두 핫 리페어를 위한 몇 가지 구현 기술을 보유하고 있습니다. 귀하의 앱에 이미 이러한 구조가 있는 경우 개발된 패치를 서버 측에 배치하고 앱이 포인트 B 데이터를 요청하도록 하면 앱이 자동으로 이러한 패치를 다운로드하여 앱 자체에 적용할 수 있습니다. 그러면 앱이 자동으로 B 지점 데이터를 요청할 수 있습니다.

두 가지 상황을 비교해 보면 B 지점이 전개된 것을 알 수 있습니다. 따라서 첫 번째 옵션이 가장 쉽고 빠릅니다.

1. 서버 관점에서 보면 서버에서 nginx를 구성하는 데 몇 분 밖에 걸리지 않습니다.
2. 앱 관점에서 보면 도메인 이름 변경은 자주 이루어져서는 안 된다고 생각합니다. 푸시로 배포한 후 앱을 클라이언트에 저장하거나 도메인 이름을 얻을 구실을 준비하세요.

서버측에서는 더 적은 노력으로 문제를 해결할 수 있을 것 같습니다

재패키지, 몇 분 안에 패키지를 만들 수 있으며 사용자 업데이트만 필요합니다