自宅のサージプロテクタを更新するよ
別アカ操作の大半はブーストボタン列の長押しでも使えるから、アクション数はあまり増えてない筈なんだけどね
STでコンテキストメニューを折りたたんだの、最初から開いてるようにするオプション欲しい人いるかな？ #SubwayTooter
自宅鯖以外でも、オンラインストレージを別業者に切り替えてアップロードし直す時とかに怒られたりするよ。DropboxとかAmazon DriveとかGoogle Driveとかに1TB超を上げるのを年に数回やる。
プロバイダからの怒られ、下りではあまり発生しないしnuro光とかは規約に制限がないので怒られないよ。iijmioとかはかなり厳しい。
初期のmstdn.jp が一週間で自宅鯖からさくらに移動した理由はたぶん転送量だと思ってる。
自宅鯖の一番のリスクは転送量が多くてプロバイダに怒られることです。本当に困る
たとえばCrypkoやWaifuLabsみたいなGPUぶん回すサービスだと、画像生成部分はクラウドには置かれないですね
クラウドと同じスペックのサーバ、市場に出てるパーツの下限が高すぎるので自作ではもはや作りにくいよ。DDR4 RAMだと8GBx2が最低ラインでしょ。おさがりのPCで始められるのが利点なので、比べるもんじゃない
WLClient http://juggler.jp/WLClient/ の最新版ではアプリから作った画像もリンクできるようにしてるので、もし使ってる人がいたら試してみてね
#WaifuLabs で メールアドレスとリンクした画像を使えるゲーム https://play.google.com/store/apps/details?id=com.Sizigi.Concentration が日本でも使えるようになったらしいよ
Androidは作りが悪いからより多くのRAMが必要と言う人がいるんだけど、ローエンド端末への対応をしっかりやってるのはむしろAndroidの方だよねってオチ
@blank71 プロセスが個別に用意される訳ではありません。プロセスの下にActivity(画面)やService(UIなしで動く何か)などのコンポーネントがいくつかあります。コンポーネントのどれかが「フォアグラウンド状態」ならプロセスも「フォアグラウンド状態」です。例えば音楽プレイヤーは再生中はサービスをフォアグラウンド状態にするので、プロセスもフォアグラウンド状態です。
画面スタック(Activityのリスト)はプロセスが死んでも管理情報だけはOS側が維持してます。
状態の保存を行えるタイミングはいくつか用意されてます。
@rinsuki まあ当時はRAM1GBでしたからねー。4GBになれば少しはマシになったでしょうけど、りんすきさんの言い分に合わせるならそれはOSの改善とは言わないですね。
@blank71 Windows OSなどでタスクマネージャに出るアレがプロセス。 Androidではバックグラウンドに回ったタスクは管理情報は存在してるけど、プロセスは殺されることがあるのです。そしてタスクが再び必要になったときにプロセスは新しく作られて、状態を復元して何事もなかったかのようにふるまうというのが理想的な流れです。
@rinsuki バックグラウンドに落ちたアプリが殺されることをクラッシュとは、私は言ってませんね。 むしろバックグラウンドアプリが殺されないことでフォアグラウンドアプリのメモリが不足してクラッシュするのです。iOS9.xで大量に見ましたね。
@rinsuki ローエンドはAndroidの方が多いんで、Androidの方がしっかりやってますね。一方でiOSはハイエンドなのにRAMはケチってて、バックグラウンドプロセスの制御も雑ってことになるんだけど。
開発者オプションで「バックグラウンドプロセスの上限」を「使用しない」にする。
STを起動してTLが読み込まれるのを見る。
投稿画面を開いて何かテキストを入力。
ホーム画面に戻ってgmailか何か別のアプリを開く。
タスク切り替えでSTの投稿画面に戻る。入力したテキストが復元されてる。
戻るボタンでメイン画面に戻る。STはTLをディスクに保存しないので、再度TLの読み込みが行われる。
@blank71 いや、プロセスが殺されただけでタスク一覧には残ってて、タスク切り替えで戻ってきたなら、画面ごと復元されてユーザは何も意識せずに編集を再開できるはずだよ。開発者オプションで「バックグラウンドプロセスの上限」を変更すると体験できる。ほかのアプリでも真面目に作られてるならそうなる。しかしゲームアプリは保存するべき情報が多すぎるので保存せず、オープニングの権利者表示から見直すことになる場合が多い。
@rinsuki 仮想メモリに頼れないモバイルOSでメモリ確保の失敗を防止するには、OSが空きメモリの確保を周到に行う、つまりバックグラウンドプロセスをいかに適切なタイミングで殺すかという問題になる。常に一定量の空きを確保するようOSが動いてる
@rinsuki メモリ確保への失敗で落ちるのは大半のアプリで防げないのです
「バックグラウンドになった際にプロセスが殺されても大丈夫なように」を言い換えると「殺されるか殺されないかはわからないけどバックグラウンドになる際に状態の保存が必要」なので、デスクトップ用OSよりタスク切り替え時の負荷は高いのだ
通話着信への応答性が求められるモバイルOSでは、バックグラウンドになった際にプロセスが殺されても大丈夫なように設計する必要がある。これはデスクトップ用OSとの大きな違い
iOSはAndroidよりアプリがクラッシュしやすい？InstagramやFBなど https://iphone-mania.jp/news-145071/
あとアプリのクラッシュ率でいうとAndroidの方が圧倒的に低い。iOSはメジャーアップデートのたびにアプリのクラッシュ祭りやってる
iOSユーザの言う「Androidよりクオリティが高いアプリ」って訊いてみるとニッチなやつばかりだ
はてなブログに投稿しました
ハクキンカイロを買っていた - ejo090の日記 http://ejo090.hatenadiary.jp/entry/2019/10/10/151929
@deltelta 割と長期間繋がらないんですよ。負荷になるので他の繋がらないサーバと一緒のタイミングで整理してる
の投稿
kedama@foresdon.jp
このアカウントは、notestockで公開設定になっていません。
@mal The behavior is not intended, but if one is selected from the previous visible range, I don't think it's abnormal.
タブレットモードでのデフォルトアカウントは前からあったが、投稿画面を開く時だけ使われてた
「アプリ設定/タブレットモード/簡易投稿でも可能ならアカウント選択を省略する」を追加。
投稿画面を開く
- (1)デフォルトアカウントが指定されてればそれで投稿画面を開く
- (2)画面内のカラムに疑似アカウントがあればアカウント選択
- (3)画面内のカラムが同じアカウントならそれで投稿画面を開く
- (4)アカウント選択
簡易投稿
- (1)「簡易投稿でも可能ならアカウント選択を省略する」が無効ならアカウント選択
- (2)デフォルトアカウントが指定されてればそれで投稿する
- (3)画面内のカラムに疑似アカウントがあればアカウント選択
- (4)画面内のカラムが同じアカウントならそれで投稿する
- (5)アカウント選択
簡易投稿の方がチェックが多いのは、投稿画面を開くのと違って後からアカウントを切り替える機会がないからです
