Optimised connection params building

[pulakdp]

I noticed creation of wsUrlString takes over 100ms, sometimes taking close to 150ms on my test device(Oneplus Nord CE 2 Lite). The function just builds a string of query parameters but does it inefficiently by using string concatenation. I replaced it with StringBuilder and prepared the string as we go. This brought down the execution time down to ~5ms or lesser.

Summary by CodeRabbit

• Refactor

  • Optimized how connection query parameters are assembled and formatted; no changes to public APIs or user-visible behavior.
  • Internal construction and ordering of parameters updated to consistently render values as strings and standardized flag encoding.

• Chores

  • Added a changeset entry preparing a patch release documenting the connection-params optimization.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[changeset-bot]

🦋 Changeset detected

Latest commit: cb29c3c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
client-sdk-android	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

📝 Walkthrough

Walkthrough

Refactors connection query parameter assembly in SignalClient: replaces list-based building with a StringBuilder and helper addParam, changes connect() and createConnectionParams() internals; adds a changeset entry documenting the optimization. Public APIs and method signatures remain unchanged. (≤50 words)

Changes

Cohort / File(s)	Summary
Signal client query builder livekit-android-sdk/src/main/java/io/livekit/android/room/SignalClient.kt	Replaces list-based query construction with a StringBuilder and helper addParam; updates connect() and createConnectionParams() to produce a single formatted query string; coerces values to strings (booleans as "1" where applicable).
Release changeset .changeset/chubby-ideas-bow.md	Adds a changeset note documenting the optimized connection params building for a patch release.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 I nibble each key and tuck it tight,
I stitch the query through the night,
With tiny paws I join the thread,
A tidy string—now off we thread! 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and concisely captures the main optimization: replacing string concatenation with StringBuilder for building connection parameters.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

🧹 Recent nitpick comments

livekit-android-sdk/src/main/java/io/livekit/android/room/SignalClient.kt (1)

202-206: Missing explicit URL encoding for query parameter values (though auto-handled by OkHttp).

The addParam helper appends values directly without manual URL encoding. While OkHttp 4.x automatically encodes special characters when parsing the raw URL string, explicit encoding is a defensive best practice. Values like clientInfo.deviceModel can contain spaces (e.g., "OnePlus Nord CE 2 Lite" per ClientInfo.kt), which should be explicitly encoded rather than relying on implicit OkHttp behavior.

Consider using java.net.URLEncoder.encode():

🛠️ Suggested fix

 fun addParam(key: String, value: String) {
     queryBuilder.append(if (first) "?" else "&")
-        .append(key).append("=").append(value)
+        .append(key).append("=").append(java.net.URLEncoder.encode(value, "UTF-8"))
     first = false
 }

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 99335f6 and 5a8d8a0.

📒 Files selected for processing (1)

• livekit-android-sdk/src/main/java/io/livekit/android/room/SignalClient.kt

🧰 Additional context used

🧬 Code graph analysis (1)

livekit-android-sdk/src/main/java/io/livekit/android/room/SignalClient.kt (1)

livekit-android-sdk/src/main/java/io/livekit/android/stats/ClientInfo.kt (1)

• getClientInfo (24-34)

🔇 Additional comments (2)

livekit-android-sdk/src/main/java/io/livekit/android/room/SignalClient.kt (2)

172-172: LGTM!

The URL construction using string template with createConnectionParams is correct and cleaner than the previous approach.

---

208-231: StringBuilder optimization looks good.

The refactored implementation correctly builds the query string with proper delimiter handling. The measured performance improvement (150ms → 5ms) is significant and aligns with expectations when replacing repeated string concatenation with StringBuilder in a loop-like pattern.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[davidliu]

Hmm, it doesn't really make sense that the string concatenation here would account for such large slowdown; 150ms is a very long time for just adding 10 or so strings together. There's probably a separate underlying issue here.

Nonetheless, it's still a good optimization to have here though. Thanks for the PR!

[pulakdp]

I was benchmarking in the sample app in a debug environment so that could add to the reason of slow execution but as you said, nevertheless it's a good optimisation because for each query param we are concating twice so for about 10 parameters that's 20 concatenations plus variable assignments due to the nature of foldIndexed