There is no really settled consensus about what the precedence of these operation symbols ought to be. Mostly that is considered to be not a methematical question, but purely one of presentation -- how many parentheses can you omit and still have a reasonable expectation that your reader will understand the same formula you thought you were writing?
When one uses multiplicative notation for conjunction (that is, just writing the conjuncts next to each other with no punctuation) it is natural to treat is as binding stronger than the operations that are written with symbols -- including $\neg$, so $\neg ab$ almost always means $\neg(a\land b)$. (When negation is written with an overline, its scope is of course unambiguous).
It is not unusual to extend this to conjunction written with an explicit $\land$ at least as far as the interaction between $\land$ and other binary operations go (but $\neg a \land b$ always means $(\neg a)\land b$). However there are also many authors who don't want to depend on such conventions and insist on disambiguating parentheses whenever $\land$ and $\lor$ are used together).
Since $\to$ is not associative, it presents special problems. In computer science and fields influenced by it, $a\to b\to c$ almost always meas $a\to (b\to c)$, but there are also logicians who write $a\to b\to c$ for $(a\to b)\to c$ -- perhaps reasoning that $a\to(b\to c)$ could equivalently be written as $a\land b \to c$ -- and yet others who prefer all nested implications to be fully parenthesized.
I wouldn't depend on any particular conventions for $\sim$, $\oplus$, $|$ or $\downarrow$, or among these and $\to$ or $\lor$. Err in the direction of too many parentheses. If is uncommon to have see formulas that contain more than one of these anyway, so it's no great burden to always parenthesize them.
Biimplication, when written $\leftrightarrow$, usually has the lowest precedence of all. I assume that what you write $\sim$ is the same operator, but I wouldn't bet on the convention extending to there.
Programming languages and other pieces of software that have to make some sense of formulas typed by a user (such as Wolfram Alpha) will usually have some particular rules that they use to unravel unparenthesized expressions, but it is not usually worth the trouble trying to memorize them -- they might well be different in the next programming language over anyway.