Есть у меня довольно простой автомобильный сценарий. Я сажусь в машину, телефон автоматически соединяется по Bluetooth с магнитолой, а самой магнитоле для навигации, пробок и прочих радостей нужен интернет через Wi‑Fi. Каждый раз доставать телефон, открывать шторку и вручную включать точку доступа мне в какой-то момент окончательно надоело.

Казалось бы, задача на пять минут: поймали подключение нужного Bluetooth-устройства и вызвали системную функцию включения hotspot. Но с недавних пор эту лавочку в Android прикрыли. Обычному стороннему приложению прямого доступа к управлению tethering уже не дают, даже если пользователь сам этого хочет.

В итоге получилось небольшое приложение BlueSpot на C#/.NET, которое делает ровно одну вещь: при подключении к выбранному Bluetooth-устройству включает системную Wi‑Fi-точку и присылает уведомление. Root не требуется, но без небольшого легального извращения в виде Shizuku не обошлось.

В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.

Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?

После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.