NSString *urlString = [NSString stringWithFormat:
@"%@?origin=%f,%f&destination=%f,%f&sensor=true&key=%@",
@"https://maps.googleapis.com/maps/api/directions/json",
mapView.myLocation.coordinate.latitude,
mapView.myLocation.coordinate.longitude,
destLatitude,
destLongitude,
@"Your Google Api Key String"];
NSURL *directionsURL = [NSURL URLWithString:urlString];
ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:directionsURL];
[request startSynchronous];
NSError *error = [request error];
if (!error) {
NSString *response = [request responseString];
NSLog(@"%@",response);
NSDictionary *json =[NSJSONSerialization JSONObjectWithData:[request responseData] options:NSJSONReadingMutableContainers error:&error];
GMSPath *path =[GMSPath pathFromEncodedPath:json[@"routes"][0][@"overview_polyline"][@"points"]];
GMSPolyline *singleLine = [GMSPolyline polylineWithPath:path];
singleLine.strokeWidth = 7;
singleLine.strokeColor = [UIColor greenColor];
singleLine.map = self.mapView;
}
else NSLog(@"%@",[request error]);
Примечание. Убедитесь, что Sdk API направления Google включен в вашей консоли разработчика Google.
Я не так хорошо знаком с тем, как это делается с помощью CLR, но, вероятно, это очень похоже на то, как это делается с собственным кодом. Когда компилятор генерирует машинные инструкции, он добавляет записи в pdb, которые в основном говорят, что «инструкция по текущему адресу X пришла из строки 25 в foo.cpp».
Отладчик знает, какой адрес программы в настоящее время выполняется. Итак, он ищет какой-то адрес X в pdb и видит, что он пришел из строки 25 в foo.cpp. Используя это, он может «пошагово» проходить через ваш исходный код.
Этот процесс одинаков вне зависимости от режима отладки или выпуска (при условии, что pdb вообще создается в режиме выпуска). Однако вы правы, что часто в режиме выпуска из-за оптимизаций отладчик не выполняет «линейный» шаг по коду. Он может неожиданно переключаться между строками. Это происходит из-за того, что оптимизатор изменяет порядок инструкций, но не меняет отображение адреса в строку источника, поэтому отладчик все еще может следовать ему.
См. Следующий вопрос SO:
Отображение количества строк в трассировке стека для сборки .NET в режиме выпуска
[@ Not Sure] почти прав. Компилятор делает все возможное для определения подходящего номера строки, который близко соответствует текущей инструкции машинного кода.
PDB и отладчик ничего не знают об оптимизации; файл PDB по существу сопоставляет адреса в машинном коде номерам строк исходного кода. В оптимизированном коде не всегда возможно точно сопоставить инструкцию сборки с определенной строкой исходного кода, поэтому компилятор запишет в PDB самое близкое, что у него есть под рукой. Это может быть «строка исходного кода перед», или «строка исходного кода включающего контекста (цикла и т. Д.)» Или что-то еще.
Тем не менее, отладчик по существу находит ближайшую запись в карте PDB (как в "раньше или равно"
Отладчик делает лучшее - попытаться угадать, где возникла проблема. Его точность не гарантируется на 100%, а с полностью оптимизированным кодом он часто будет неточным - я обнаружил неточности в диапазоне от нескольких строк до совершенно неправильного стека вызовов.
Насколько точен отладчик с оптимизированным кодом действительно зависит от самого кода и от того, какие оптимизации вы делаете.