Наследуемый класс компонента WinRT, написанный с использованием WRL

Да, наследуемый именно в кавычках. Потому что речь идёт о «наследовании» в терминах WinRT компонентов.
Данный класс при подключении библиотеки к .NET проекту, будет виден как незапечатанный. Но это только .NET реализация проекции WinRT.

Одно приложение для трех платформ

А почему бы не использовать SQLite и libcurl? Тогда ещё большую часть логики можно будет вынести в C++.

Shake Detector для Android на RxJava

Догадался, скорее всего из-за того, что в этом случае постоянно генерировались бы списки, а это лишние затраты.
Протестировал своё предположение на C#

 Observable.Never<Object>().Buffer(TimeSpan.FromSeconds(1)).Subscribe(list => Console.WriteLine(list.Count));

Shake Detector для Android на RxJava

А почему не стали использовать http://reactivex.io/RxJava/javadoc/rx/Observable.html#buffer(long,%20java.util.concurrent.TimeUnit) для получения трех взмахов?

Небольшое сравнение производительности UWP/WinRT API языковых проекций

Спасибо за замечание. Внёс изменения в текст статьи.

Небольшое сравнение производительности UWP/WinRT API языковых проекций

Нет. В проектах, полагающихся на работу UWP/WinRT API никакие массивы в замере времени исполнения не участвуют.

Небольшое сравнение производительности UWP/WinRT API языковых проекций

Если вы посмотрите проекты CPPWRL или CPPCX, то сможете заметить, что там работает аналогичный код:

input = hasher->HashData(input);
String^ base64String;
base64String = CryptographicBuffer::EncodeToBase64String(input);
input = CryptographicBuffer::ConvertStringToBinary(base64String, BinaryStringEncoding::Utf8);

Для удобства восприятия могу его записать так:

input = hasher->HashData(input);
input = CryptographicBuffer::ConvertStringToBinary(CryptographicBuffer::EncodeToBase64String(input), BinaryStringEncoding::Utf8);

Кроме того. Привёл к этому же виду код проекта CSWinRT:

input = hasher.HashData(input);
input = CryptographicBuffer.ConvertStringToBinary(CryptographicBuffer.EncodeToBase64String(input), BinaryStringEncoding.Utf8);

Результаты стали даже хуже:

• C# Native — ~195000 миллисекунд
• C# — ~80000 миллисекунд

Небольшое сравнение производительности UWP/WinRT API языковых проекций

Конечно, тестировалась релизная сборка. Настройки компиляции релизной сборки не менял, значения были по-умолчанию (ну кроме того, что полностью выключил генерацию отладочной информации.

Экзамен 70-485 Advanced Windows Store App Development Using C#

Мельком просмотрел статью. Следующее утверждение бросилось в глаза:

WinMD это библиотека классов Windows Runtime, которая создана специально и только для Windows Store приложений (в отличие от PCL). Если ее код написать на C++, то при обращении к ней из приложений на C#/JavaScript производительность возрастет по сравнение с тем же кодом на C#.

Хотелось бы немного дополнить.
Во-первых, WinMD — это файл метаданных для описания API, который предоставляется компонентом, а не библиотека. Наличие WinMD файла ещё не гарантирует корректную загрузку компонента(dll с кодом может вовсе отсутствовать).
Во-вторых, есть много нюансов работы WinRT компонентов. К примеру, если написать WinRT компонент на C# и вызывать методы из C# кода, то CLR не будет использовать WinRT ABI, а будет вызывать код напрямую. В случае же, если компонент написан на C++, то передача типов будет происходить через ABI, что медленнее прямого вызова C# — C#.

PS: поздравляю с получением сертификата!!!

Создания Windows Runtime компонента на Visual C++

Наверно, пропустили вот эту часть статьи

Внимательный читатель мог заметить странную деталь в конструкторах и деструкторах классов, а именно инкремент и декремент переменной m_objectsCount. Данную переменную я объявил сразу после директив using перед кодом классов. А используется она в экспортируемой библиотекой функции DllCanUnloadNow:

Подсчет объектов нужен, для того, чтобы исполняющая среда узнала может ли она выгрузить библиотеку.
А в коде определение переменной выглядит вот так

#include "pch.h"
#include "TestComponent.h"

//Импортируем пространство имён нашего компонента
using namespace ABI::NMSPC::TestComponent;
//Импортируем интерфейсы из пространства имён ABI::Windows::ApplicationModel::Background
using ABI::Windows::ApplicationModel::Background::IBackgroundTask;
using ABI::Windows::ApplicationModel::Background::IBackgroundTaskInstance;

//Переменная для хранения числа текущих экземпляров объектов библиотеки.
//Значение данной переменной будем изменять в конструкторах объектов реализации 
//фоновой задачи и фабрики.
ULONG m_objectsCount = 0;
..................................................................

Наследуемый класс компонента WinRT, написанный с использованием WRL

Небольшое добавление.
Для проверки HRESULT лучше использовать макросы

#define SUCCEEDED(hr)   (((HRESULT)(hr)) >= 0)
#define FAILED(hr)      (((HRESULT)(hr)) < 0)

Они уже определены в заголовочных файлах(в WRL это intsafe.h).