Hatena::ブログ(Diary)

ザリガニが見ていた...。 このページをアンテナに追加 RSSフィード

2014-06-26

ドキュメントカメラの撮影台作り

Evernoteのドキュメントカメラは、素晴らしい使い勝手である。

  • ドキュメント部分のみに自動的にトリミングしてくれる。(ドキュメント外側の余分な画像を削除)
  • 斜め方向から撮影しても、正面から撮影した状態に補正してくれる。
  • 多少影が映り込んでも、影のない画像に補正してくれる。

ドキュメントカメラの性能が素晴らしいだけでなく、取り込んだ後の画像データの活用まで考えられている。

  • Evernoteに取り込んでおけば、どの端末からも自由に閲覧できる。
  • Evernoteに取り込んでおけば、画像でありながら、テキスト検索できる。(かなり信頼している)

「とりあえずEvernoteに保存しておけば、きっと何かの役に立つ」と想像してしまうのだ。(そう思わせたEvernoteは偉い)また、iPhoneなどの既存のハードウェアを利用して、その他すべてをEvernoteというソフトウェア環境のみで解決してしまうところにも惚れ惚れする。余分なハードを作らずに、知力のみで勝負しているところが好き。


そうは言っても、iPhoneを手持ちで撮影すると、時には手振れすることもある。斜め補正してくれるけど、斜め過ぎると画質も悪くなる...。もし、iPhoneを台の上に置いてドキュメントを真正面から撮影できるなら、手振れも排除されるし、余分な補正も最小限で済むはず。幸いなことに、自分の身の回りには段ボール箱が溢れている。それらを使って、実験的に撮影台を作ってみようと思い立った。(ライト付きのスナップ台にはならないけど、0円工作の始まり、始まり)

ドキュメントカメラ台

  • Amazonの「JA3」というサイズの箱を使った。
    • A4サイズのちょっと深さがある箱

  • 箱の側面を2cm(1円玉の直径)残して切り抜いた。
  • A4を撮影するためには、高さが足りないので、上蓋の折り返し部分を立てた。

f:id:zariganitosh:20140625111058j:image:w450


  • 上蓋を立てると、ちょっとした拍子に内側に折れてしまうので、
  • 側面を切り抜いた段ボールをL字フックにしてホチキス止めした。

f:id:zariganitosh:20140625111236j:image:w450


  • 段ボールの板に撮影用の穴の空けて、その上にiPhoneを載せて撮影してみた。

f:id:zariganitosh:20140625111324j:image:h300 f:id:zariganitosh:20140625111500j:image:h300


  • 台から撮影したドキュメントカメラの画像
    • このガイドマップの文字はかなり小さいのだけど、ほとんどの文字は判読可能なレベルだった。

f:id:zariganitosh:20140626092543j:image:h500


おんぼろの段ボール箱台だけど、これで用が足りる。

名刺カメラ台

  • Amazonの「XM03」というサイズの箱を使った。
    • A4サイズのiPhoneくらいの深さの箱
    • 商品を取り出す時には、側面の折り返し部分を丁寧に剥がして開封した。

f:id:zariganitosh:20140626080616j:image:w300

    • OPENのミシン目からは開封しないこと。

  • ドキュメントカメラ台と同じように、側面を切り抜いた。
  • 天井に撮影用の穴もあけた。

f:id:zariganitosh:20140626082755j:image:w300


  • iPhoneを載せて、撮影してみる。

f:id:zariganitosh:20140626082637j:image:w300


  • 名刺カメラは、名刺を認識すると、自動撮影してくれる。

f:id:zariganitosh:20140626082459j:image:w300

  • 水平・垂直が多少ズレても、良きに計らい補正してくれる。

f:id:zariganitosh:20140626082531j:image:w300


名刺を撮影台に置くだけで、正確に取り込まれる!快適である。

撮影のコツ

  • フラッシュはオフにしておいた方がいい。
    • フラッシュがオンだと、明る過ぎて白飛びしてしまうことが多いので。
    • ちなみにドキュメント・名刺カメラの場合、フラッシュをオフにしても撮影前のライトは点灯する。

f:id:zariganitosh:20140626090636j:image:h300


  • ノート >> 新規ノート >> カメラマーク >> ドキュメント で撮影することで、iOSのカメラロールにも保存される。
    • Evernoteの撮影画像を削除した場合でも、カメラロールには画像が残る。

f:id:zariganitosh:20140626090751j:image:h300f:id:zariganitosh:20140626090750j:image:h300f:id:zariganitosh:20140626090749j:image:h300

2014-06-23

みまもりケータイとは何か?

みまもりケータイ3を使い始めた。1週間ほど使ってみて、ようやく、みまもりケータイが何であるのか実感できるようになった。

環境

  • みまもりケータイ3(202Z)
  • オーナー iPhone4S iOS7
  • SoftBankショップで以下の作業は完了している。
    • オーナー設定済み
    • 位置ナビのオプション契約済み

みまもりケータイ側の設定でやったこと

  • My Softbank >> 新規会員登録
    • 携帯電話番号
    • 暗証番号(契約書に記載あり)
  • みまもりケータイにパスワードが届く
    • 管理設定 >> おしらせ に届く。(メール ではない)
  • My Softbank >> ログイン
    • 携帯電話番号
    • 上記パスワード
    • 図形のドラッグ
  • My Softbank >> パスワードの変更
  • My Softbank >> メールアドレスの変更(SMS/MMS)
  • My Softbank >> オプションサービスの変更
    • あんしん保証パックライトR(解除)
  • My Softbank >> みまもりケータイの設定
    • My Softbankから、みまもりケータイのすべての設定をコントロールできる。
    • 速度検知 ON
    • 緊急速報メール OFF
    • 省電力モード ON

iPhone側の設定でやったこと

  • My Softbank >> みまもりケータイの設定
    • オーナー側のMy Softbankからも、みまもりケータイのすべての設定をコントロールできる。
  • My Softbank >> 位置ナビ
    • みまもりケータイの位置情報を検索して、地図に示す。
    • 月額216円、1検索5円の費用がかかる。
  • MMSを有効にする。
    • 設定 >> メッセージ >> MMSメッセージ=オン
    • みまもりケータイはMMSで通知してくるため。
  • MMSを受信する時には...
    • 設定 >> モバイルデータ通信 >> モバイルデータ通信=オン
    • 設定 >> モバイルデータ通信 >> モバイルデータ通信を使用:すべてオフ

通知(取扱説明書4−22)

みまもりケータイとは何か?ひと言で言えば...

  • MMSでイベントの発生を通知する端末である。
    • 通知には位置情報が含まれる。
    • オーナーあるいはメンバー宛に送信される。

みまもりケータイの利便性は、この通知にあり!


  • 通知されるイベントは8種類。
種類内容
ブザー連動通知緊急ブザーが鳴らされたこと・位置情報
充電推奨通知バッテリー残量が少なくなったこと・位置情報
電源OFF通知電源オフになったこと・位置情報
位置情報通知電話を発信したこと・位置情報
速度検知指定速度以上で移動したこと・位置情報
生活みまもりみまもりケータイの動きを検知した・しない
開封確認通知メールを開封したこと
ソフトウェア更新通知ソフトウェア更新があること

機能(取扱説明書1-2)

みまもりケータイとは何か?機能的な視点からも見てみる。

  • 電話(事前に登録した発信先3件・着信許可した20件のみと通話する)
  • メール(定型文・あるいは録音した音声をMMSで送受信する)
  • 緊急ブザー(ストラップを引っぱるとブザーが鳴る、位置情報も通知する)
  • 生活みまもり(みまもりケータイの動きの有無を監視する)
  • 速度検知(10分ごとに位置情報を確認して速度を監視する、位置情報も通知する)
  • 歩数計(歩数をカウントする)
  • 緊急速報(緊急地震速報・津波警報・災害避難情報を受信する)
  • 位置ナビ(みまもりケータイの現在地を地図に表示する)
  • SMSで遠隔操作(ビープ音を鳴らす・バッテリー残量を取得)
  • My SoftBankからすべての設定が可能
  • 防水(IPX5)防塵

以下、できること・できないことを検証してみた。

SMSを利用した遠隔操作(取扱説明書5-7)

  • 命令文をSMSで送信して、みまもりケータイを遠隔操作できる。(遠隔操作できたかどうかをMMSで返信する)
    • 返信を受けるには、モバイルデータ通信をオンにしておく必要あり。
    • 命令文のSMSは、みまもりケータイのメールには表示されない。
    • 命令文でないSMSは、みまもりケータイのメールとして表示される。
  • MMSで送信してしまうと、遠隔操作できない。かならずSMSで送信すること。
    • 確実にSMS送信するには、メッセージの宛先に電話番号を指定する。
ビープ音を鳴らす
  • 数値=音量であり、0-4を指定できる。(0=最小、4=最大)
BEEP,4
バッテリー残量を取得する
GETBATTERY

サイレント自動着信はできない

手動着信○ボタンを押して着信を受ける
自動着信5秒後に自動的に着信を受ける
通常モード通知音ON振動ON
マナーモード通知音OFF振動ON
サイレントモード通知音OFF振動OFF
  • 但し、自動着信の場合は、サイレントモードであっても振動する。
  • これは、みまもりケータイ3の仕様である。(157サポートで確認)

位置ナビでiPhoneの自分検索はできない

  • iPhoneは、検索する側の端末として利用できるが、
  • 検索される側の端末としては利用できない。
  • よって、iPhoneでは自分検索もできない。
  • 但しiPhoneは、Appleが提供する「iPhoneを探す」で検索できる。
    • iPhoneがネットワーク(モバイルデータ通信かWiFi)に接続している必要あり。

その他

  • 自動着信にすると、スピーカーフォンになる。
  • 自動着信にすると、みまもりケータイ3からは通話を切れない。
  • MMSは送受信ができる。
  • SMSは受信のみできる。
  • 電源は専用工具で2秒以上押し続ける。
  • 管理設定の暗証番号は、初期値「9999」である。
    • 直ちに変更しておくべき。

以下、SMSとMMSに関することを調べてみた。

メールアドレス=未設定(未入力)がお勧め

  • My SoftBank >> みまもりケータイの設定 >> メンバー設定 >> メールアドレス=未設定(未入力)がお勧め
    • 未設定の場合は、そのメンバーの電話番号宛にMMS送信される。
    • SMSで遠隔操作する時、送信と返信が一つの電話番号にまとまるので見やすい。
    • メールアドレスを設定してしまうと、送信は電話番号、返信はメールアドレス、と二つに分かれてしまう...。

iPhoneでSMSとMMSの見分け方

  • 設定 >> メッセージ >> 件名欄を表示=オン
  • 設定 >> メッセージ >> 文字数=オン
  • メッセージ入力時に...
    • 文字数がカウントされればSMS。
    • 文字数がカウントされなければMMS。

iPhoneのSMS/MMS料金

  • ホワイトプランに加入している場合、ソフトバンク携帯宛のSMS/MMS送受信は無料(1通50KBまで)である。
    • 但し、大容量ファイル(1通50KB以上?)添付は有料
  • 他社宛MMSは、1パケット=0.08円
  • 他社宛SMSは、1通送信=3円(受信は無料)

SMSとMMSの違い

  • SMSは、音声回線を使った宛先電話番号直通のデータ送信。
    • 相手が圏外であると、送信できない。
  • MMSは、モバイルデータ通信を使ったサーバー経由のデータ通信。
    • 相手が圏外であっても、一旦サーバーに保管される。
    • 相手のモバイルデータ通信が復旧した時に、サーバーから送信される。

2014-02-08

iOS7のユーザ辞書をリセットするスクリプト

前回までに自分のiPhoneMacBookのユーザ辞書は同期するようになったのだけど、その手順はちょっと複雑だった。再び同期できなくなった時のことを考えて、素早く、安全に、iPhoneのユーザ辞書をリセットするスクリプトにしておこうと、思い立った。

開発&実行環境

  • MacBook OSX 10.9.1
  • iPhone iOS7

mbdbを編集するRubyコード(reset_keyboard.rb)

  • いちいちテキストに書き出さずとも、mbdbの内容を取捨選択できるように改良した。
  • 「mbdb.reject!(/HomeDomain::Library\/Keyboard/)」によって、キーボードに関連する設定ファイルを一括削除している。
# encoding: ASCII-8BIT

class Mbdb
  def initialize(mbdb_filename, verbose = false)
    @verbose = verbose
    process_mbdb_file(mbdb_filename)
  end

  def to_text_file(filename)
    File.open(filename, 'w') do |f|
      @mbdb.each do |r|
        f.puts r.values.inspect
      end
    end
  end

  def to_mbdb_file(filename)
    File.open(filename, 'wb') do |f|
      f.write(binary_data)
    end
  end

  def reject!(regexp)
    @mbdb.reject! {|r| "#{r[:domain]}::#{r[:filename]}" =~ regexp}
  end

  def fill!(regexp)
    @mbdb.reject! {|r| !("#{r[:domain]}::#{r[:filename]}" =~ regexp)}
  end

private

  # Return an integer (big-endian) and new offset from the current offset
  def get_int(data, offset, intsize)
    value = 0
    while intsize > 0
      value = (value<<8) + data[offset].ord
      offset += 1
      intsize -= 1
    end
    return value, offset
  end

  # Return a string and new offset from the current offset into the data
  def get_string(data, offset)
    return 'ffff', offset + 2 if data[offset] == 0xFF.chr and data[offset + 1] == 0xFF.chr # Blank string
    length, offset = get_int(data, offset, 2) # 2-byte length
    value = data[offset...(offset + length)]
    value = '0000' if value == ""
    return value, (offset + length)
  end

  def put_int(data_10, intsize)
    data_16 = "%0#{intsize*2}x" % data_10
    [data_16].pack('H*')
  end

  def put_string(str)
    return "\xff\xff" if str == 'ffff'
    return "\x00\x00" if str == '0000'
    return [str.length].pack('n') + str
  end

  def process_mbdb_file(filename)
    @mbdb = Array.new
    data = File.open(filename, 'rb') { |f| f.read }
    puts "MBDB file read. Size: #{data.size}"
    raise 'This does not look like an MBDB file' if data[0...4] != 'mbdb'
    offset = 4
    offset += 2 # value x05 x00, not sure what this is
    while offset < data.size
      fileinfo = {}
      fileinfo[:domain], offset = get_string(data, offset)
      fileinfo[:filename], offset = get_string(data, offset)
      fileinfo[:linktarget], offset = get_string(data, offset)
      fileinfo[:datahash], offset = get_string(data, offset)
      fileinfo[:unknown1], offset = get_string(data, offset)
      fileinfo[:mode], offset = get_int(data, offset, 2)
      fileinfo[:unknown2], offset = get_int(data, offset, 4)
      fileinfo[:unknown3], offset = get_int(data, offset, 4)
      fileinfo[:userid], offset = get_int(data, offset, 4)
      fileinfo[:groupid], offset = get_int(data, offset, 4)
      fileinfo[:mtime], offset = get_int(data, offset, 4)
      fileinfo[:atime], offset = get_int(data, offset, 4)
      fileinfo[:ctime], offset = get_int(data, offset, 4)
      fileinfo[:filelen], offset = get_int(data, offset, 8)
      fileinfo[:flag], offset = get_int(data, offset, 1)
      fileinfo[:propertynum], offset = get_int(data, offset, 1)
      fileinfo[:properties] = {}
      (0...(fileinfo[:propertynum])).each do |i|
        propname, offset = get_string(data, offset)
        propval, offset = get_string(data, offset)
        fileinfo[:properties][propname] = propval
      end
      @mbdb << fileinfo
    end
    @mbdb
  end

  def binary_data
    bin = "mbdb\x05\x00"
    @mbdb.each do |h|
      bin << put_string(h[:domain])
      bin << put_string(h[:filename])
      bin << put_string(h[:linktarget])
      bin << put_string(h[:datahash])
      bin << put_string(h[:unknown1])
      bin << put_int(h[:mode], 2)
      bin << put_int(h[:unknown2], 4)
      bin << put_int(h[:unknown3], 4)
      bin << put_int(h[:userid], 4)
      bin << put_int(h[:groupid], 4)
      bin << put_int(h[:mtime], 4)
      bin << put_int(h[:atime], 4)
      bin << put_int(h[:ctime], 4)
      bin << put_int(h[:filelen], 8)
      bin << put_int(h[:flag], 1)
      bin << put_int(h[:propertynum], 1)
      h[:properties].each do |k, v|
        bin << put_string(k)
        bin << put_string(v)
      end
    end
    bin
  end

end

if RUBY_VERSION >= "1.9" then
  `mv '#{ARGV[0]}' '#{ARGV[0]}.back'`
  mbdb = Mbdb.new("#{ARGV[0]}.back", true)
  mbdb.reject!(/HomeDomain::Library\/Keyboard/) # Reset UserDictionary
  mbdb.to_text_file("#{ARGV[0]}.txt")
  mbdb.to_mbdb_file(ARGV[0])
else
  puts 'Needs Ruby version 1.9 or later'
end

バックアップを保護するシェルスクリプト(reset_keyboard.sh)

  • 上記Rubyコードがmbdbを修正する前に、バックアップをコピーして、安全に作業する環境を整える。
#!/bin/sh
current_dir=`dirname $0`
target_dir="$1"
reset_dir="${target_dir}-reset-user-dictionary"

rm -fr "$reset_dir";
cp -r "$target_dir" "$reset_dir"

display_name=`defaults read "${reset_dir}/Info.plist" "Display Name"`
defaults write "${reset_dir}/Info.plist" "Display Name" -string "${display_name}-reset-user-dictionary"

ruby "${current_dir}/reset_keyboard.rb" "${reset_dir}/Manifest.mbdb"

バックアップリストを返すシェルスクリプト(current_backup_list.sh)

  • iPhoneのバックアップは、端末固有のUniqueDeviceIDという英数字が羅列したフォルダに存在する。
  • リセットする端末を指定する時、英数字の羅列では扱いにくいので、端末名を関連づけたリストを返す。
#!/bin/sh
backup_folders=`find "$HOME/Library/Application Support/MobileSync/Backup" -name Info.plist -exec dirname {} \;`
IFS=$'\n'
for f in $backup_folders
do
  deviceID=`defaults read "$f/Manifest.plist" 'Lockdown'|grep UniqueDeviceID|awk '{print $3}'|tr -d ';'`
  folder_name=`basename "$f"`
  if [ "$deviceID" = "$folder_name" ]; then
    echo "`defaults read "$f/Info.plist" 'Display Name'` :: $folder_name"
  fi
done

AppleScriptアプリケーションによるGUI(reset_iOS7_UserDictionary.app)

  • 以上のスクリプトを、AppleScriptアプリケーションとしてまとめてみた。
  • iOS端末を指定すると、上記スクリプトが連携して、ユーザ辞書をリセットしたバックアップを生成するのだ。

 activate
 set current_backup_list_sh to (path to resource "current_backup_list.sh")'s POSIX path
 set reset_keyboard_sh to (path to resource "reset_keyboard.sh")'s POSIX path
 
 set device_list to (do shell script current_backup_list_sh)'s paragraphs
 set selected_item to choose from list device_list with prompt "ユーザ辞書をリセットする端末を選択してください。" with title my name
 if selected_item is false then error number -128 --キャンセル
 set selected_folder to split(selected_item as text, " :: ")'s item 2
 
 display notification "ユーザ辞書をリセット中です..."
 delay 1
 
 set mobilesync_backup to (((path to application support folder from user domain) as text) & "MobileSync:Backup:")'s POSIX path
 do shell script (reset_keyboard_sh & space & quoted form of (mobilesync_backup & selected_folder)) -- & " >& /dev/null &"
 
 display notification "リセットが完了しました。"
 delay 1
 
 
 
 
 on split(src_text, delimiter)
   set last_delimiter to AppleScript's text item delimiters
   set AppleScript's text item delimiters to delimiter
   set res to src_text's text items
   set AppleScript's text item delimiters to last_delimiter
   res
 end split

ダウンロードと使い方


例:MacBookとiPhoneのユーザ辞書をリセットする場合

  • すべての端末(MacBook、iPhone)で、iCloudの「書類とデータ」の同期をオフにする。
iCloudのユーザ辞書のリセット
  • WebブラウザでiCloudにアクセスして、「書類とデータのリセット」を実行する。
MacBookのユーザ辞書のリセット
  • MacBookで、~/Library/Mobile Documents/com~apple~TextInput/ を削除する。(Finderでゴミ箱へ)
iPhoneのユーザ辞書のリセット
  • iPhoneをMacBookに接続する。
  • iTunesを起動して「今すぐバックアップ」を実行する。
    • 事前に、写真や動画をiPhotoなどに取り込んで、カメラロールを空っぽにしておくと、バックアップが素早く完了する。

  • reset_iOS7_UserDictionary.appを実行する。
    • ユーザ辞書の設定がリセットされたバックアップを生成する。

f:id:zariganitosh:20140208141417p:image:w450


  • iTunesで、「バックアップを復元...」を実行する。
  • バックアップリストから「端末名-reset-user-dictionary」を選択して、復元ボタンを押す。

f:id:zariganitosh:20140208135627p:image:w450

  • 復元が成功すれば、iPhoneのユーザ辞書はリセットされているはず。

  • すべての端末(MacBook、iPhone)で、iCloudの「書類とデータ」の同期をオンに戻す。

待つこと暫し、ユーザ辞書の同期が始まるかもしれない。

  • 不要になった「端末名-reset-user-dictionary」は、iTunes >> 環境設定... >> デバイスから削除できる。

f:id:zariganitosh:20140208142910p:image:w450

2014-02-03

徹底的にユーザ辞書を同期してみる

MacBookで「まーゔぇりくす=Mavericks」と登録したはずなのに、iPhoneで「まーゔぇりくす」と入力しても期待する「Mavericks」が表示されない...。いつから同期していなかったのかは不明だが、iOS7とOSX 10.9 Mavericksの環境で、ユーザ辞書が同期していないことに気付いた。

またいつものバージョンアップに伴う不具合か...と思ってしばらく放っておいたのだけど、OSX 10.9.1になっても自分のユーザ辞書は一向に同期する気配がない。どうなっているのかと検索してみると、何と!ちゃんと同期している方もいるらしい。

本当に同期するのか?こうゆうことは自分で試してみなければ気が済まない。やってみた。


検証

  • iCloudに接続するすべての端末で、一旦「書類とデータ」の同期をオフにした。
  • その後、SafariからiCloudのWebページにログインして、
  • 右上の名前のリンクから、アカウント設定 >> 詳細設定 >> 書類とデータのリセットを実行した。
  • MacBookのユーザ辞書には「まーゔぇりくす=Mavericks」のみの状態にして、「書類とデータ」の同期をオン。
ゲストアカウントからiCloudに接続してみる
  • ゲストアカウントにログインして、そこからiCloudにサインインしてみた。
  • ユーザ辞書を確認すると、いつものアカウントで登録した「まーゔぇりくす=Mavericks」が表示されている。
  • 逆に、ゲストアカウントで「れてぃな=Retina」を登録すると、いつものアカウントでも同じ辞書が確認できた。

素晴らしい!OSX環境ではちゃんと同期しているのだ。

iPhoneを工場出荷状態に戻す
  • iTunesにiPhoneを接続して、今すぐ「バックアップ」を実行。
    • バックアップ容量を節約するため、iPhotoと同期して、カメラロールを空っぽにしておいた。
    • バックアップさえちゃんとしておけば、iPhoneは元どおりに復元できるはず。
    • 念には念を入れて、TimeMachineによるバックアップもしておいた。
    • その後、恐れずに「iPhoneを復元...」ボタンを押してみる。
  • 「iPhoneを復元...」処理が進むと、二つの選択を迫られた。
    • 新しいiPhoneとして設定するのか?
    • 既存のバックアップから復元するのか?
  • 工場出荷状態に戻したいので、新しいiPhoneとして設定してみた。
  • 処理が進んで、iCloudの設定をして、待つこと暫し...
  • 驚いたことに「まーゔぇりくす=Mavericks」と「れてぃな=Retina」が確認できる!

素晴らしい!工場出荷状態のiPhoneならちゃんと同期するのだ!

iPhoneを復元してみる
  • なんだ、iCloudはちゃんとできる子だったんだ!と気を良くして「バックアップを復元」を実行してみた。
  • するとiPhoneのユーザ辞書から「Mavericks」と「Retina」が消えた...。(ユーザ辞書には何も表示されない)

これで確信した。同期できないのは、iPhone中のファイルの問題であると。


  • iCloudの「書類とデータ」の同期をオフにすると、ユーザ辞書にかなりの数の単語が表示された。
  • ユーザ辞書が大き過ぎて、うまく同期できない原因になっているのかもしれない。
  • そう思って、1つの単語を削除しようとすると、完了するまでに30秒以上かかる。
  • ユーザ辞書の単語登録が多過ぎるためか、辞書の編集をすると、操作がやけに重い。

いつの間にか膨れ上がってしまったiPhoneのユーザ辞書が、かなり怪しい!

iPhoneのユーザ辞書はリセットできるのか?

  • 工場出荷状態にすると、iPhoneのユーザ辞書はリセットされているはず。
    • リセット=初期状態で何も登録がない状態。
  • しかし、工場出荷状態ではその他の設定もすべてリセットされており、使い慣れたiPhoneにはほど遠い状態である。
  • そこで、復元によって以前の状態に戻すのだけど、そのタイミングでユーザ辞書も多過ぎる単語で溢れてしまう...。
  • ユーザ辞書を1語ずつ削除しようとしてみたが、1件30秒以上かかると、すべて削除するのはいつになるか見当もつかない...。

ユーザ辞書だけ復元したくないのだけど、脱獄しない限り、そんなことはできそうにない?

iPhoneのバックアップの中身を覗く

1つだけ思い当たる方法があった。

  • iOS Filesを選択して、Extractボタンを押すと、iOS Filesのファイルとディレクトリ構造が書き出された。

f:id:zariganitosh:20140203090620p:image:w450

  • そしてiOS Files/Library/Keyboard/の奥深くに潜む、いくつかのCloudUserDictionary.sqliteがユーザ辞書の実体ではないかと予想した。
  • 当時プロファイルを削除した時の方法は、復元されたiOS Files中のCloudUserDictionary.sqliteのバイト数を調べて、
  • 同じサイズのファイルを~/Library/Application Support/MobileSync/Backup/の中から見つけ出し、削除していた。
  • 過去の成功体験から、今回も同じ方法でやってみと...

f:id:zariganitosh:20140203092050p:image:w450

  • ガーン、復元できないと警告された。
  • 以前も似たような警告をされたのだけど、その時は目指すファイルがちゃんと削除れた状態で復元され、目的は達成できた。
  • しかし、今回は本当に復元できていないようだ。ユーザ辞書の内容を確認してみると、以前と変わらず。同期もしない...。

iOSバージョンアップの過程で、1つでも復元できないファイルがあると、復元処理全体がキャンセルされることになってしまったのか?

バックアップの仕組みを探る

  • もはやこれまでか...と思いながら、バックアップファイルの中をブラウズしていると、1つの仕組みに気付いた。
  • バックアップファイルは、以下の構造になっている。
    • 多数のハッシュ値のファイル
    • Info.plist、Manifest.mbdb、Manifest.plist、Status.plist
  • ハッシュ値のファイルは、iOS中に存在するひとつ一つの、ファイルそのものである。
  • ファイル名がハッシュ値に変換されたファイルとして、バックアップされているのだ。
    • より正確には、"ドメイン名-ファイルパス"がSHA1ハッシュ値に変換されている。
$ ruby -r digest/sha1 -e 'puts Digest::SHA1.hexdigest("HomeDomain-Library/Keyboard/dynamic-text.dat")'
0b68edc697a550c9b977b77cd012fa9a0557dfcb
  • バックアップを暗号化していなければ、Quick Lookで見られるファイルも多い。
  • 一方、.plistや.mbdbファイルは、ハッシュ値のファイルを管理する情報である。
  • ハッシュ値のファイルに必要な付属情報紐づけて、管理しているのだ。
  • 中でもManifest.mbdbには、本の「目次」に相当する役割がありそう。
    • iOSの設定ファイルらしきディレクトリ情報は、このManifest.mbdbにしか存在しなかったので。
  • バイナリファイルなのだけど、hexdump -Cコマンドで確認してみると、ディレクトリ情報が確認できた。
$ hexdump -C ~/Library/Application\ Support/MobileSync/Backup/fc4dd318ecd23105d1fde5b5f6c782ec4c2504e2/Manifest.mbdb | less

...(中略)...
0013f6b0  0a 48 6f 6d 65 44 6f 6d  61 69 6e 00 2f 4c 69 62  |.HomeDomain./Lib|
0013f6c0  72 61 72 79 2f 4b 65 79  62 6f 61 72 64 2f 50 68  |rary/Keyboard/Ph|
0013f6d0  72 61 73 65 4c 65 61 72  6e 69 6e 67 5f 6a 61 5f  |raseLearning_ja_|
0013f6e0  4a 50 2e 64 62 2e 62 75  6e 64 6c 65 ff ff ff ff  |JP.db.bundle....|
0013f6f0  ff ff 41 ed 00 00 00 00  00 00 0a 9f 00 00 01 f5  |..A.............|
0013f700  00 00 01 f5 52 e5 f6 bd  52 e5 f6 bd 52 de 02 60  |....R...R...R..`|
...(中略)...
  • 目次があるのに、ページだけ削除するから、バックアップが壊れていると警告されてしまうのだ。
  • 目次情報のCloudUserDictionary.sqliteを削除しておけば、警告されずに復元できるかもしれない!

しかし、Manifest.mbdbはバイナリファイルである。必要な部分だけ、1バイトも間違わずに削除するなんてことが、果たしてできるだろうか?

Manifest.mbdbを解析する

  • 解析するなんて書いたが、正直、自分にはさっぱり...。
  • テキスト部分はある程度予想できたが、テキストではないバイナリデータの部分は、訳が分からない。
  • しかし、世の中にはすごい達人がいた。自分が行うまでもなく、.mbdbはすでに解析されていたのだ。

  • つまり、バイナリデータを項目別に解析してみると、以下のように読み取れる。
0013f520  00 00 0a 48 6f 6d 65 44  6f 6d 61 69 6e 00 44 4c  |...HomeDomain.DL|
0013f530  69 62 72 61 72 79 2f 4b  65 79 62 6f 61 72 64 2f  |ibrary/Keyboard/|
0013f540  50 68 72 61 73 65 4c 65  61 72 6e 69 6e 67 5f 7a  |PhraseLearning_z|
0013f550  68 5f 48 61 6e 74 5f 70  69 6e 79 69 6e 2e 64 62  |h_Hant_pinyin.db|
0013f560  2e 62 75 6e 64 6c 65 2f  64 61 74 61 62 61 73 65  |.bundle/database|
0013f570  2e 64 62 ff ff 00 14 01  18 48 19 51 c6 53 36 01  |.db......H.Q.S6.|
0013f580  26 1d 9e 93 79 fa 7c de  e4 37 5e ff ff 81 a4 00  |&...y.|..7^.....|
0013f590  00 00 00 00 06 87 ab 00  00 01 f5 00 00 01 f5 52  |...............R|
0013f5a0  e5 f6 be 52 e5 f1 f5 52  e5 c1 bc 00 00 00 00 00  |...R...R........|
0013f5b0  00 50 00 04 00 00 0a 48  6f 6d 65 44 6f 6d 61 69  |.P.....HomeDomai|
0013f5c0  6e 00 31 4c 69 62 72 61  72 79 2f 4b 65 79 62 6f  |n.1Library/Keybo|
0013f5d0  61 72 64 2f 50 68 72 61  73 65 4c 65 61 72 6e 69  |ard/PhraseLearni|
0013f5e0  6e 67 5f 7a 68 5f 48 61  6e 73 2e 64 62 2e 62 75  |ng_zh_Hans.db.bu|
0013f5f0  6e 64 6c 65 ff ff ff ff  ff ff 41 ed 00 00 00 00  |ndle......A.....|

  • stringは、文字数とASCIIコードで構成される、可変長のデータ。
データ種項目名文字数ASCIIコードテキストの内容
stringドメイン00 0a48 6f 6d 65 44 6f 6d 61 69 6eHomeDomain
stringファイルパス00 444c 69 62 72 61 72 79 2f 4b 65 79 62 6f 61 72 64
2f 50 68 72 61 73 65 4c 65 61 72 6e 69 6e 67 5f
7a 68 5f 48 61 6e 74 5f 70 69 6e 79 69 6e 2e 64
62 2e 62 75 6e 64 6c 65 2f 64 61 74 61 62 61 73
65 2e 64 62
Library/Keyboard/PhraseLearning_zh_Hant_pinyin.db.bundle/database.db
stringシンボルのリンク先ff ff ff ff=nullの意味?
stringデータのハッシュ値00 1401 18 48 19 51 c6 53 36 01 26 1d 9e 93 79 fa 7c
de e4 37 5e
ファイル内容のSHA.1ハッシュ値
string不明ff ff ff ff=nullの意味?

  • unitはバイト数が決められた、固定長のデータ。
データ種項目名内容意味
unit16モード81 a40100644(8xxx=ファイル、4xxx=ディレクトリ、axxx=シンボリックリンク
unit32不明00 00 00 00
unit32不明00 06 87 ab
unit32ユーザーID00 00 01 f5501
unit32グループID00 00 01 f5501
unit32日時52 e5 f6 be2014/01/27 15:03:42(mtime)
unit32日時52 e5 f1 f52014/01/27 14:43:17(atime)
unit32日時52 e5 c1 bc2014/01/27 11:17:32(ctime)
unit64ファイルサイズ00 00 00 00 00 00 50 0020480
unit8フラッグ04
unit8プロパティの数00
$ ruby -e 'puts 0x81a4.to_s(8)'
100644

$ ruby -r time -e 'puts Time.at(0x52e5f6be).strftime("%Y/%m/%d %H:%M:%S")'
2014/01/27 15:03:42

$ ruby -r time -e 'puts Time.parse("2014/01/27 15:03:42").to_i.to_s(16)'
52e5f6be
  • もし、プロパティが存在すれば、以下の「キー」と「値」のペアが「プロパティの数」だけ続くはず。
データ種項目名バイト数ASCIIコード
stringキーキーのバイト数キーの名称
string値のバイト数値の内容

mbdbを解釈するコード

  • ところで、今回の目的はバックアップファイルから不要な設定ファイルを削除することである。
  • そこで、上記ページで紹介されているコードを元に、二つの変換コードを作ってみた。
    • mbdbを1レコード1行のテキストファイルに変換するコード。
    • 上記テキストファイルを元にmbdbに再変換するコード。
mbdb2text.rb(mbdbをテキストに変換)
# encoding: utf-8
require 'fileutils'

class ManifestParser
  def initialize(mbdb_filename, verbose = false)
    @verbose = verbose
    process_mbdb_file(mbdb_filename)
  end

  def to_file(filename)
    File.open(filename, 'w') do |f|
      @mbdb.each do |v|
        f.puts fileinfo_str(v)
      end
    end
  end

  private
  # Retrieve an integer (big-endian) and new offset from the current offset
  def getint(data, offset, intsize)
    value = 0
    while intsize > 0
      value = (value<<8) + data[offset].ord
      offset += 1
      intsize -= 1
    end
    return value, offset
  end

  # Retrieve a string and new offset from the current offset into the data
  def getstring(data, offset)
    return 'ffff', offset + 2 if data[offset] == 0xFF.chr and data[offset + 1] == 0xFF.chr # Blank string
    length, offset = getint(data, offset, 2) # 2-byte length
    value = data[offset...(offset + length)]
    value = '0000' if value == ""
    return value, (offset + length)
  end

  def process_mbdb_file(filename)
    @mbdb = Array.new
    data = File.open(filename, 'rb') { |f| f.read }
    puts "MBDB file read. Size: #{data.size}"
    raise 'This does not look like an MBDB file' if data[0...4] != 'mbdb'
    offset = 4
    offset += 2 # value x05 x00, not sure what this is
    while offset < data.size
      fileinfo = Hash.new
      fileinfo[:start_offset] = offset
      fileinfo[:domain], offset = getstring(data, offset)
      fileinfo[:filename], offset = getstring(data, offset)
      fileinfo[:linktarget], offset = getstring(data, offset)
      fileinfo[:datahash], offset = getstring(data, offset)
      #fileinfo[:datahash] = fileinfo[:datahash].each_codepoint.to_a.map{|i|i.to_s(16)}.join("") if fileinfo[:datahash] != "ffff"
      fileinfo[:unknown1], offset = getstring(data, offset)
      fileinfo[:mode], offset = getint(data, offset, 2)
      fileinfo[:unknown2], offset = getint(data, offset, 4)
      fileinfo[:unknown3], offset = getint(data, offset, 4)
      fileinfo[:userid], offset = getint(data, offset, 4)
      fileinfo[:groupid], offset = getint(data, offset, 4)
      fileinfo[:mtime], offset = getint(data, offset, 4)
      fileinfo[:atime], offset = getint(data, offset, 4)
      fileinfo[:ctime], offset = getint(data, offset, 4)
      fileinfo[:filelen], offset = getint(data, offset, 8)
      fileinfo[:flag], offset = getint(data, offset, 1)
      fileinfo[:propertynum], offset = getint(data, offset, 1)
      fileinfo[:properties] = Hash.new
      (0...(fileinfo[:propertynum])).each do |ii|
        propname, offset = getstring(data, offset)
        propval, offset = getstring(data, offset)
        #propval = propval.each_codepoint.to_a.map{|i|i.to_s(16)}.join("")
        fileinfo[:properties][propname] = propval
      end
      @mbdb << fileinfo
    end
    @mbdb
  end

  def fileinfo_str(f)
    return "(#{f[:fileID]})#{f[:domain]}::#{f[:filename]}" unless @verbose
    data = [ f[:domain], f[:filename], f[:linktarget], f[:datahash], f[:unknown1], f[:mode], f[:unknown2], f[:unknown3], f[:userid], f[:groupid], f[:mtime], f[:atime], f[:ctime], f[:filelen], f[:flag], f[:propertynum], f[:properties]]
    #info = "%s %s %s %s %s %04x %08x %08x %08x %08x %08x %08x %08x %016x %02x %02x" % data
    info = data.inspect
    info
  end
end

if __FILE__ == $0
  mp = ManifestParser.new('Manifest.mbdb', true)
  mp.to_file('Manifest.mbdb.txt')
end
text2mbdb.rb(テキストからmbdbに変換)
# encoding: ASCII-8BIT
require 'fileutils'

class ManifestParser
  def initialize(mbdb_filename, verbose = false)
    @verbose = verbose
    process_mbdb_file(mbdb_filename)
  end

  def to_file(filename)
    File.open(filename, 'wb') do |f|
      f.write(@mbdb)
    end
  end

  private
  # Retrieve an integer (big-endian) and new offset from the current offset
  def getint(data, intsize)
    data16 = "%0#{intsize*2}x" % data
    [data16].pack('H*')
  end

  # Retrieve a string and new offset from the current offset into the data
  def getstring(str)
    return "\xff\xff" if str == 'ffff'
    return "\x00\x00" if str == '0000'
    return [str.length].pack('n') + str
  end

  def process_mbdb_file(filename)
    @mbdb = "mbdb\x05\x00"
    data = File.open(filename, 'rb') { |f| f.read }
    puts "MBDB file read. Size: #{data.size}"
    data.each_line do |line|
      #a = line.chomp.split
      a = eval(line)
      @mbdb << getstring(a[0])
      @mbdb << getstring(a[1])
      @mbdb << getstring(a[2])
      @mbdb << getstring(a[3])
      @mbdb << getstring(a[4])
      @mbdb << getint(a[5], 2)
      @mbdb << getint(a[6], 4)
      @mbdb << getint(a[7], 4)
      @mbdb << getint(a[8], 4)
      @mbdb << getint(a[9], 4)
      @mbdb << getint(a[10], 4)
      @mbdb << getint(a[11], 4)
      @mbdb << getint(a[12], 4)
      @mbdb << getint(a[13], 8)
      @mbdb << getint(a[14], 1)
      @mbdb << getint(a[15], 1)
      a[16].each do |k, v|
        @mbdb << getstring(k)
        @mbdb << getstring(v)
      end
    end
    @mbdb
  end

  def fileinfo_str(f)
    return "(#{f[:fileID]})#{f[:domain]}::#{f[:filename]}" unless @verbose
    data = [ f[:domain], f[:filename], f[:linktarget], f[:datahash], f[:unknown1], f[:mode], f[:unknown2], f[:unknown3], f[:userid], f[:groupid], f[:mtime], f[:atime], f[:ctime], f[:filelen], f[:flag],f[:propertynum]]
    info = "%s %s %s %s %s %04x %08x %08x %08x %08x %08x %08x %08x %016x %02x %02x" % data
    f[:properties].each do |k, v|
      info += " #{k}=#{v.inspect}"
    end
    info
  end
end

if __FILE__ == $0
  mp = ManifestParser.new('Manifest.mbdb.txt', true)
  mp.to_file('Manifest.txt.mbdb')
end

実行

かなりやっつけなコードだけど、これで用が足りる。

  • デスクトップにmbdb2text.rb、text2mbdb.rb、Manifest.mbdbを置いて...
  • mbdb2text.rbを実行すると、テキストに変換されたManifest.mbdb.txtが生成される。
$ ruby mbdb2text.rb
  • Manifest.mbdb.txtを開いて、不要なファイル情報の行を削除する。
  • その後、text2mbdb.rbを実行すると、削除したファイル情報を含まないManifest.mbdb.txtが生成されるのだ。
$ ruby text2mbdb.rb
  • Manifest.mbdb.txtを~/Library/Application Support/MobileSync/Backup/XXXXXXXXXXXXXX/Manifest.mbdbに移動して、準備完了。
  • iTunesで「バックアップを復元...」してみる。
  • 今度はエラー警告されずに、復元が完了した!

  • 最初は、いくつか存在するCloudUserDictionary.sqliteファイルのみを削除しての試みだった。
  • ユーザ辞書は何も登録がない状態になるのだけど、iCloudとの同期はうまく機能していないようだ。
  • えーい、こうなったらLibrary/Keyboard/を含むすべてのパスを削除してしまえ!とヤケになった。
    • 大丈夫、元のManifest.mbdbはちゃんとバックアップしてあるのだ。
    • Manifest.mbdb.txtから、以下の行をゴソっと一気に削除してみた。
["HomeDomain", "Library/Keyboard", "ffff", "ffff", "ffff", 16832, 0, 49, 501, 501, 1390785465, 1390785465, 1390281141, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/dynamic-text.dat", "ffff", "\n\x1F[L\xB5$\r\x9Az\x02?\x9D\xC9ja\xEB\xC1\xA2\x05\xC2", "ffff", 33152, 0, 234135, 501, 0, 1390336046, 1390336046, 1390336046, 48, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_zh_Hant_zhuyin.db.bundle", "ffff", "ffff", "ffff", 16877, 0, 64154, 501, 501, 1390785301, 1390785301, 1390268470, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_zh_Hant_zhuyin.db.bundle/database.db", "ffff", "e&\xF0#3\xEA\x7F\xBDs\xD8\tn;\xBA\xE9`q\x96\x03\a", "ffff", 33188, 0, 64183, 501, 501, 1390288790, 1390284436, 1390268470, 20480, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_zh_Hant_pinyin.db.bundle", "ffff", "ffff", "ffff", 16877, 0, 64155, 501, 501, 1390785301, 1390785301, 1390268470, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_zh_Hant_pinyin.db.bundle/database.db", "ffff", "\x01\x18H\x19Q\xC6S6\x01&\x1D\x9E\x93y\xFA|\xDE\xE47^", "ffff", 33188, 0, 64188, 501, 501, 1390288789, 1390284436, 1390268470, 20480, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_zh_Hans.db.bundle", "ffff", "ffff", "ffff", 16877, 0, 64156, 501, 501, 1390785301, 1390785301, 1390268467, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_zh_Hans.db.bundle/database.db", "ffff", "\xD9\x19\xDA\xEA`\xFA\xD2)\xB8\x7Fj\n\xF9\xBF\xBDu\xA4{Hq", "ffff", 33188, 0, 64196, 501, 501, 1390288788, 1390284436, 1390268467, 20480, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_ja_JP.db.bundle", "ffff", "ffff", "ffff", 16877, 0, 2719, 501, 501, 1390785465, 1390785465, 1390281312, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/Lexierra_ja_JP-dynamic-text.dat", "ffff", "\xDA9\xA3\xEE^kK\r2U\xBF\xEF\x95`\x18\x90\xAF\xD8\a\t", "ffff", 33152, 0, 64197, 501, 501, 1379583290, 1390284436, 1379583290, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport", "ffff", "ffff", "ffff", 16877, 0, 399096, 501, 501, 1390785378, 1390785378, 1390785378, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E", "ffff", "ffff", "ffff", 16877, 0, 399097, 501, 501, 1390785378, 1390785378, 1390785378, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary", "ffff", "ffff", "ffff", 16877, 0, 399098, 501, 501, 1390785401, 1390785401, 1390785378, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary/local", "ffff", "ffff", "ffff", 16877, 0, 399099, 501, 501, 1390785378, 1390785378, 1390785378, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary/local/store", "ffff", "ffff", "ffff", 16877, 0, 399100, 501, 501, 1390785385, 1390785385, 1390785378, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary/079F2A5D-20CE-4391-9E46-BD3C829C98CC", "ffff", "ffff", "ffff", 16877, 0, 399294, 501, 501, 1390785401, 1390785401, 1390785401, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary/079F2A5D-20CE-4391-9E46-BD3C829C98CC/store", "ffff", "ffff", "ffff", 16877, 0, 399295, 501, 501, 1390785685, 1390785685, 1390785401, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/BigramLearning_ja_JP.db.bundle", "ffff", "ffff", "ffff", 16877, 0, 2729, 501, 501, 1390785465, 1390785465, 1390281312, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/.DictionaryMigrationLock.lock", "ffff", "\xDA9\xA3\xEE^kK\r2U\xBF\xEF\x95`\x18\x90\xAF\xD8\a\t", "ffff", 33188, 0, 399889, 501, 501, 1390785465, 1390785465, 1390785465, 0, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary/079F2A5D-20CE-4391-9E46-BD3C829C98CC/store/CloudUserDictionary.sqlite", "ffff", "\xBB>\x91\xBEF\x92B5\xD1\x0E\xDE\xF3\x90\xFF`B\x1A\xF3\x12\x89", "ffff", 33188, 0, 399297, 501, 501, 1390785685, 1390785685, 1390785401, 40960, 4, 0, {}]
["HomeDomain", "Library/Keyboard/BigramLearning_ja_JP.db.bundle/database.db", "ffff", "*\xE9k\xBB\x88\xD1\xF8\bo\xA4\x96b\xC0\xEC\x17Df\xB0\xCE\x8A", "ffff", 33188, 0, 397243, 501, 501, 1390785465, 1390785243, 1390779824, 20480, 4, 0, {}]
["HomeDomain", "Library/Keyboard/PhraseLearning_ja_JP.db.bundle/database.db", "ffff", ":\xC0\xD1\xDF\xC3/\x0FWl\xB2\x98\x04\xB9%\xB7\xF2\x1E\x96:\xBE", "ffff", 33188, 0, 397245, 501, 501, 1390785713, 1390785243, 1390782010, 20480, 4, 0, {}]
["HomeDomain", "Library/Keyboard/CoreDataUbiquitySupport/mobile~E88C661C-2206-5E67-AA19-66EC6D3EC50E/UserDictionary/local/store/CloudUserDictionary.sqlite", "ffff", "\xB8\x11F\x94k\xCC\xF6\xA4\xC7\x92\x86\xDA\xEB\xECB\x04<\xDA\xDC\x91", "ffff", 33188, 0, 399101, 501, 501, 1390785384, 1390785384, 1390785378, 49152, 4, 0, {}]

すると、iPhoneとMacBookのユーザ辞書が同期し始めた!

ユーザ辞書が同期するまでに試したこと

最終的にはiPhoneのLibrary/Keyboard/をリセットできたから、ユーザ辞書が正常に同期し始めたと思っているのだが、ここに辿り着くまでに、いくつもの手順を踏んでいる。それらの手順もユーザ辞書の同期を再開させるために重要かもしれないので、忘れないようにメモ。

すべての端末で、iCloudの「書類とデータ」の同期をオフ
  • MacBookとiPhoneをiCloud経由で同期する場合、3つの領域が同期に関与していると理解した。
    • iCloudサーバーとして、同期情報を保存しておく領域。
    • MacBookとして、同期情報を保存しておく領域。
    • iPhoneとして、同期情報を保存しておく領域。
  • iCloudを経由する同期のリセットの難しさは、どれか1つの領域をリセットしても、すぐまた別の領域の情報と同期してしまって、完全なリセットを実行しにくいこと。
  • すべての端末で、リセットしたい同期をオフにすることで、確実にリセットできる環境になる。
すべての同期領域を同じタイミングでリセット
  • 同期をオフにしたら、すべての同期領域を速やかにリセットするのだ。
    • iCloudサーバーの場合:https://www.icloud.com にアクセスして、アカウント設定 >> 詳細設定 >> 書類とデータのリセット。(Safariでアクセスした)
    • MacBookの場合:~/Library/Mobile Documents/com~apple~TextInput/ の削除。(Finderで削除した)
    • iPhoneの場合:Library/Keyboard/ の削除。(この日記の手順で削除した)
その他試行錯誤の中でやったこと
  • iCloudからのサインアウト
    • MacBookの場合:システム環境設定 >> iCloud からサインアウト
    • iPhoneの場合:設定 >> iCloud >> アカウントを削除
      • iCloudのアカウントが削除される訳ではなく、iPhone中の同期情報のみ削除される。
      • 再び同じアカウントでiCloudにサインインすれば、同期情報は復元されるのだ。
  • iCloudにサインインするアカウント名称を@以降まで統一。
    • 自分は現在、3つのアップルIDでサインインできてしまう。
      • ユーザー名@mac.com
      • ユーザー名@me.com
      • ユーザー名@icloud.com
  • どれを使っても同一のiCloudアカウントにサインインしていると思うのだが、
  • 念のため、すべての端末で「ユーザー名@icloud.com」に統一して、サインインしておいた。
  • iCloudにサインインする時、すべての情報が同期するまでには、かなりの時間がかかった。
    • 特にユーザ辞書のデータは、同期のタイミングが遅い気がした。
    • アクティビティモニタの受信パケット数を見ながら、気長に待った。(1時間くらい)

2013-11-13

バッテリー交換したiPhone4Sのタフな持続力

iPhone3GSのバッテリーを購入する時、ついでにiPhone4Sのバッテリーも欲しくなり、買ってしまった。

  • iPhone 4S 専用 交換用 バッテリー
  • ちなみにこの時、700円だった。
    • 注意:iPhone4とiPhone4Sは外見も中身もとても良く似ているが、バッテリーに互換性はない。
    • バッテリーの大きさと、接続端子の形状が違っている。

iPhone4Sは、裏蓋開けたらすぐにバッテリーにアクセスできるので、交換作業はものすごくお手軽である。

利用環境

  • iPhone4S(2年経過)
  • iOS 7.0.3

交換の要点

バッテリー端子の下に挟まっている金具が重要である。

裏蓋を外す
  • コネクタ両サイドのネジを外す。
  • 裏蓋をロックボタン側へスライドさせる。
  • スライドしたら、裏蓋を上に持ち上げる。
バッテリー端子
  • バッテリー端子の2つのネジを外す。
  • それぞれのネジは微妙に大きさが違うので、取り付ける時に間違わないように整理しておく。
  • バッテリー端子の下には金具が挟まっているので、この部品の取り付け方向を覚えておく。
  • この金具が正しい位置と方向で取り付けられていないとキャリアの電波を受信できなくなる。

f:id:zariganitosh:20131113083110p:image:w450

  • ご想像のとおり、一度失敗して、3Gの電波を拾えなくなった。
バッテリー取り外し
  • バッテリーは接着剤で固定されている。
  • 剥がしツールをバッテリーの隙間に差し込んで、粘着を弱めつつ、
  • バッテリ取り外し用のダグをつまんで、強く引き上げると外れた。

持続時間の検証

  • バッテリーを交換したら、iPhone4Sの動作を確認後、100%まで充電した。
  • その後、バッテリーが空になるまで使い切るため、自動ロックをなしに設定。
  • 電源を入れっぱなしにして、バッテリーが空になったら再び100%まで充電。
    • 新品バッテリーに交換した場合、バッテリーの性能を最大限引き出すため、充放電サイクルを数回繰り返すように推奨されていたので。
使用時間の検証
  • 電源を入れっぱなしで、どこまで持続できるか?
  • 「設定 >> 一般」を開いた状態で放置してみた。

f:id:zariganitosh:20131112144439p:image:h450

  • 途中、その他の操作も多少あったが、13時間以上も継続した。
通常利用の検証
  • 再び100%まで充電。自動ロックを1分に戻した。
  • 今度はなるべく無駄に使わない控えめな使用環境で、どこまで持続するか?

  • 7時間経っても100%
    • 焦った...。バッテリーが減らない!

f:id:zariganitosh:20131112144442p:image:h450


  • およそ1日経過(残80%)
    • とても優秀である。
    • このままのペースで本当に続くのか?

f:id:zariganitosh:20131112144441p:image:h450


  • およそ2日経過(残39%)
    • 2日目は順当に減少したが、まだ大丈夫。

f:id:zariganitosh:20131112144440p:image:h450


  • およそ2日と12時間経過(残17%)
    • かなり心細くなってきたけど、続けてみる。

f:id:zariganitosh:20131112144438p:image:h450


  • およそ3日と7時間経過(残2%)
    • 残り20%きってから、予想外に粘る。
    • 旧バッテリーだったら、とっくに0%になるタイミング。
    • 最後は記録を伸ばしたくて使用を極力控えてしまったが、
    • 最終的にはこの日の9時頃まで持続していたはず。(操作できた記憶がある)
    • スクリーンショットを撮ったのは、このタイミングまで。

f:id:zariganitosh:20131112144437p:image:h450

所感

  • バッテリーの持続時間に悩んでいたら、バッテリーを交換してみる価値はある。
  • この辺は、メモリ不足に悩んで様々な節約を試みるが、最終的にはメモリの増設が一番効果的な対策であるのと似ている。

  • 但し、失敗する可能性も0ではない。
  • At Your Own Riskでお願いします。

2013-11-12

iPhone3GSのバッテリー交換

少年曰く、最近、iPhone3GSの画面がめくれ上がってきたらしい。実物を見せてもらうと、なるほど、確かに画面のガラスの端が数ミリ浮き上がっている。(写真を撮るの忘れた)見るに耐えない状況である。さっそく分解してみると、バッテリーがパンパンである。はち切れんばかりに膨張している。これはもう、バッテリを交換するしかない。さっそく、取り寄せてみた。

新旧比較すると、そのパンパン度が凄まじい...。

新 | 旧
f:id:zariganitosh:20131112082703p:image:w450
f:id:zariganitosh:20131112082704p:image:w450

手順

以下、自分が行った手順と、忘れたくないこと。

開き方
  • コネクタ両サイドのネジをプライスドライバーで外す。
  • 今回は、画面が持ち上がっていたので、指で上に持ち上げてすんなり外せたが、
  • 画面がぴったり収まっている時は、吸盤を使って引っ張り上げる。
  • その際、引っ張り上げるのは、ホームボタン側の画面だ。
  • ロックボタン側にはコネクタが接続されているので、無理に引っ張り上げると配線を痛めてしまう。

f:id:zariganitosh:20131112104604p:image:w450

3番の外し方
  • iPhone3GSはとても親切である。
  • 誰が貼ったか、外すべきコネクタにオレンジ色のシールが1番から7番まで貼ってある。
  • 1番、2番を外すと、3番が見えるようになる。

f:id:zariganitosh:20131112104613p:image:w450


  • マイナスドライバーで、黒いフックを上に持ち上げると、配線プリントの帯が簡単に外れる。

f:id:zariganitosh:20131112110550p:image:w450

  • ↑水平だった3番のフックが、↓垂直に立ち上がればOK。これで抜ける。

f:id:zariganitosh:20131112110547p:image:w450

コネクタ
  • 画面ユニットが取り外せれば、このように作業しやすくなる。
  • 残りのコネクタ4番、5番、6番、7番を外しておく。

f:id:zariganitosh:20131112104603p:image:w450

Don't Removeのネジ1個とその他のネジ6個
  • 7番のコネクタを外すと、その下にDon't Removeのシールが見える。
  • 実はこのシールの下にもネジがある。
  • シールを剥がして、このネジも外しておく。
  • これはうまくシールが剥がれず、シールの上から回してしまった状態。

f:id:zariganitosh:20131112104608p:image:w450

  • それ以外に、マザーボードは左右3カ所ずつ、計6個のネジで止められている。
  • すべて外した。
SIMカード
  • SIMカードも抜いておかないと、マザーボードを外す時に引っかかってしまう。

f:id:zariganitosh:20131112104601p:image:w450

カメラ
  • カメラのネジも外しておいた。
  • それに付随する金具も重要だ。
  • 取り付け方法を覚えておき、無くさないように取り外した。

f:id:zariganitosh:20131112104600p:image:w450

マザーボードの外し方
  • すべての準備は整った。これからマザーボードを取り外す。
  • ホームボタン側から持ち上げてみると...

f:id:zariganitosh:20131112104605p:image:w450

  • ロックボタン側の下側には、カメラと接続するコネクタが繋がっているので、これも外す。
  • ちなみに、この写真は既にバッテリーを交換した後の状態である。

f:id:zariganitosh:20131112104606p:image:w450

バッテリー
  • マザーボードが外れれば、あとは接着されているバッテリーを取り外すのみ。

無事、バッテリーを交換した。

マザーボードの取り付け方
  • マザーボードを取り付ける前に、カメラを取り外して、マザーボードのコネクタに接続しておくのだ。
    • マザーボードを取り付けてから、カメラのコネクタと接続しようと思っても、接続できなかった...。
    • 接続できた気になって組み上げてしまっても、カメラが正常に作動しなかったのだ。

f:id:zariganitosh:20131112104609p:image:w450

  • このようにカメラを先にマザーボードに取り付けておく。これで確実に接続できるはず。

f:id:zariganitosh:20131112104610p:image:w450

  • マザーボードを取り付ける時のポイントは、カメラの左側にある、緩衝剤との隙間に基盤を差し込むのだ。
  • 緩衝剤を上に持ち上げて、その下側にマザーボードの基盤の端を差し込むように取り付けると収まりが良い。
  • マザーボードがうまくハマったら、すべてのネジを締めて、すべてのコネクタを接続して、元に戻すのだ。

f:id:zariganitosh:20131112104607p:image:w450

画面をはめ込む前の確認
  • Don't Removeのネジの締め付けが緩いと、電源が入らない。
  • 画面ユニット横にある接続端子が埃まみれになっていると、ホームボタンの反応が悪くなる。
  • カメラのコネクタがちゃんと接続できていないと、カメラアプリは起動するが、シャッターがいつまでたっても開かない。
  • 自分は以上の失敗をしているので、画面ユニットをはめ込む前に、電源を入れて動作を確認した方が良さそう。
    • ちなみに、画面ユニットをちゃんとはめ込むまでは、ホームボタンは機能しない。
    • 画面ユニットをはめ込むことで、端子が配線に接触し、正常に機能するようになる。

少年に再び笑顔が戻った。

2013-10-11

その設定でバッテリーは本当に節約されているのか?

前回、バッテリーを節約する設定を探ってみたが、それぞれの設定の数値的な根拠はまったくない。すべてが自分の体感に頼っている。そして、数々のバッテリー節約術でも「この設定で節約になる」ということは書かれているのだが、一体どれほどの効果があるのか?その部分がほとんど書かれていない。

具体的な数値で示されているのは、本家iPhoneの性能表ぐらい。バッテリーの節約と利便性のバランスする設定を見つけるためにも、具体的な節約効果を知りたいのだ!その情報がなければ、自分で計測してみるしかない。

しかし、どうやって?MacBookならスクリプト書いて自動計測できそうなんだけど、同じことをiPhoneでやる術を知らない...。こうなったら、地道に、泥臭く、手作業で計測してみるしかないかも。やってみた。

利用環境

  • ソフトバンク
  • iPhone 4S
  • iOS 7.0.2

計測方法

  • バッテリー残量を見て、パーセント表示が減少した瞬間から、次に減少する瞬間まで、1%減少する経過時間を計測する。
    • 一般 >> 使用状況 >> バッテリー残量(%)=オン
  • バッテリー残量のパーセント表示が変化する瞬間を目撃するのは大変である。
  • 常に目を凝らして、じっとパーセント表示を見つめるしかないのだ...。
  • 何度も繰り返していると、次に変化する時間を予想できるので、予想時間の前後1分くらいに集中して見つめる。
  • そうは言っても、条件を変えると予想外のタイミングでバッテリー残量が減少することもある。気を抜けない...。
  • ユニクロックなど、タイミングを計る曲をBGMに、iPhoneのバッテリー残量を頻繁にチェックするのだ。
    • ピッ、ピッ、ピッ、ポーンのタイミングとかで。
  • それでも変化する瞬間を見逃してしまうことはある。
  • その場合は、変化に気付いた時間を記録して、次の変化を予想して計測する。
  • そして、2%減少する経過時間を計測して、その平均を求めた。

 

計測時の注意点

とにかく、比較したい設定以外の条件は、完璧に同じ条件にしておく必要がある。

  • iPhoneに表示されている画面の違いで、バッテリー消費も変化することがある。
    • 画面にダイナミック壁紙が見えている状態と、見えていない状態。
    • 画面に秒針が動く時計アイコンが見えている状態と、見えていない状態。
    • 画面にコントロールセンター表示中と、非表示。
  • iPhoneが静止して置かれている状態と、手で持って動かされている状態でも条件は違う。
  • バックグラウンドでフォトストリームの同期が行われているかもしれない。
  • バッテリー充電直後は、最初の1%が減少してから計測を開始する。
    • なぜかバッテリーが最初に1%減少するまでは、異常に長持ちするので。
  • 明るさの自動調節はオフにしておく。
    • 壁紙/明るさ >> 明るさの自動調節=オフ

主要な条件

  • 明るさ=0%
  • Wi-Fi=オン
  • Bluetooth=オフ
  • モバイルデータ通信=オフ
  • キャリア >> 自動=オフ
  • 壁紙=静止画
  • 視差効果を減らす=オン
  • Appのバックグラウンド更新=オン、RunKeeperのみ=オン
  • iTunes&App Store >> 自動ダウンロード >> アップデートのみ=オフ

  • 一般 >> 自動ロック=しない 設定にして計測

明るさ

明るさ	1%減少するまでの経過時間
100%	4:00
100%	3:46
 50%	5:40
 50%	5:40
 25%	6:47
 25%	6:44
  0%	7:49
  0%	7:59(この計測のみ、明るさの自動調節=オン)
  0%	8:10(この計測のみ、明るさの自動調節=オン)
所感
  • 明るさが25%減少すると、およそ1分の節約効果がある。
  • 明るさ0%は、明るさ100%の2倍長持ち。
  • 同じ明るさが維持されるなら、自動調節のオン/オフの違いによる差は、ほとんどない。

Bluetooth

  • Bluetooth=onは、他のデバイスと接続していない待機状態で計測。
Bluetooth	1%減少するまでの経過時間
off		7:21
off		8:47
on		8:27
on		8:25
off		7:48
off		8:03
on		8:28
on		8:07

on		6:36
on		7:10
off		7:22
off		6:29
所感
  • Bluetoothのオン/オフの違いによる差は、ほとんどない。
  • これは、iPhone4S以降、Bluetooth 4.0+HS規格に対応したためと思われる。
  • bluetooth 4.0規格は、ボタン電池1つで数年間駆動可能な超省電力な設計。
  • さらに、+HS規格によって、近距離であれば24Mbpsという高速無線通信の性能も合わせ持つ。
  • さすがにBluetoothをペアリングして無線通信すると、それなりの電力消費は発生すると思われる。

バッテリー節約でBluetoothをオフにするのは、iPhone4までの古い情報。

iPhone5以降はAirDropにも対応しているので、もはやBluetoothは常時オンが基本の時代なのだ!

Wi-Fi

  • Wi-Fiのオンについては、意図的なアプリの操作はせず、余分なデータ通信が発生していない状態で計測。
    • 但し、バックグラウンドでは、多少のデータ通信が発生していると思う。
    • Wi-Fiネットワークへは、常に安定して接続した状態で計測している。
Wi-Fi		1%減少するまでの経過時間
on		7:56
on		7:30
on		7:24
off		8:07
on		6:54
off		8:09
on		7:10
所感
  • データ通信が発生していなければ、Wi-Fiがオンでも、バッテリーはそれほど消費されない。
  • iPhone4Sにとっては、3Gのモバイルデータ通信か、Wi-Fiへの接続は生命線である。
  • 自分の環境では、現在はWi-Fiをメインに使っているのでオフにすることはできない。
  • また、iPhone5以降でAirDropを利用するためには、Wi-FiとBluetoothがオンになっている必要がある。
  • 今回は未計測だが、Wi-Fiがオンの状態で、Wi-Fiの圏外、あるいはネットワークに接続しない状態でのバッテリー消費量も気になる。
    • おそらくWi-Fiネットワークをサーチし続けることで、スリープ中のバッテリー消費が大幅に増えると思う。

キャリア >> 自動

キャリア >> 自動	1%減少するまでの経過時間
on		6:39
on		6:52
off		7:25		
off		7:39
off		7:44
on		6:34
on		6:38
所感
  • キャリアの設定には今まで無頓着で、ずっと自動=オンにしたままだった。
  • 測定結果を見る限り、およそ1分の差が発生している。

スリープ中も含めて常に影響すると思われるので、キャリア >> 自動=オフにする効果は大きい!

日付と時刻と時間帯

測定環境:プライバシー >> 位置情報サービス >> システムサービス >> 時間帯の設定=常にoff
一般 >> 日付と時刻 >> 自動設定
on		7:05
off		7:06
on		7:23
on		7:00
on		6:31

測定環境:一般 >> 日付と時刻 >> 自動設定=常にon
プライバシー >> 位置情報サービス >> システムサービス >> 時間帯の設定
on		7:01
on		7:09
off		7:48

on		6:29
on		6:46
off		7:23
off		7:00
off		6:31

on		6:29
on		6:46
off		7:23
off		7:00
off		6:31
所感
  • 一般 >> 日付と時刻 >> 自動設定は、「時間帯」と「日付と時刻」を自動設定する項目である。
  • 日付と時刻の自動設定(NTPサーバーを使ってる?)だけなら、バッテリー消費にはほとんど影響しないと思われる。
  • 時間帯の設定で、位置情報サービスを利用すると、その分だけバッテリー消費が多くなるようだ。
  • 日付と時刻の解説曰く「位置情報サービスをオンにすると時間帯の自動設定の正確性が向上します」
  • よって、位置情報サービスを利用しなくても、時間帯の自動設定は可能なようだ。
  • 自分はほとんど日本国内でしか使わないので...
    • プライバシー >> 位置情報サービス >> システムサービス >> 時間帯の設定=オフ
  • 時刻は秒単位までぴったり合って欲しいので...
    • 一般 >> 日付と時刻 >> 自動設定=オン

  • どうも測定値がばらついているのは、測定中に位置情報サービスが利用されたかどうかの影響を受けている気がする。
  • プライバシー >> 位置情報サービス=オフ にして計測するべきかもしれない。

やってみた。

プライバシー >> 位置情報サービス

  • プライバシー >> 位置情報サービス >> システムサービス=すべてオン の状態で計測。
  • 計測中にアプリは起動していないので、これはつまり、システムサービス=すべてオン/すべてオフ のバッテリー消費の比較である。
位置情報サービス	1%減少するまでの経過時間
off		6:24	(1)システムサービスをオフにする余分な操作あり
off		7:08	(2)
on		6:05	(3)システムサービスをオンにする余分な操作あり
on		6:45	(4)
on		7:26	(5)
off		6:46	(6)システムサービスをオフにする余分な操作あり
off		7:05	(7)
所感
  • 位置情報サービスがオンであっても、アプリやシステムが位置情報サービスを利用しない限り、余分なバッテリー消費は発生しないと思われる。
  • 位置情報サービスはオン/オフの変わり目(1)(3)(6)にバッテリー消費が多くなるのは、オン/オフする操作のためと思われる。
  • システムサービスをオンにした直後(3)は、オンにする操作+位置情報サービスの初期動作か?
  • 計測結果を見る限り、位置情報サービス >> システムサービス=すべてオン にしたからと言って、バッテリー消費にはほとんど影響していない。
    • 強いて言えば、オン/オフ操作の後2番目の測定値で比較すれば、オン/オフには20秒の差があると読み取れるが、
    • (4)と(5)を平均するとおよそ7:05となって、オン/オフの差はほとんど発生していないことになってしまう...。

プライバシー >> 位置情報サービス >> システムサービス=すべてオン によるバッテリー消費は、ほとんど発生しないと思われる。

  • ちなみに、プライバシー >> 位置情報サービス >> システムサービス=すべてオフ にしてもデメリットはほとんど感じなかった。
  • システムサービスが位置情報を利用した時は、確実にバッテリーが消費されるはずなので、システムサービスのみすべてオフにしても良さそう。
    • その後、システムサービス >> コンパスの調整のみオンにしておいた。(コンパスは正確であって欲しいと思ったので)

コントロールセンター

コントロールセンター	1%減少するまでの経過時間
表示		5:02
非表示		8:07
非表示		7:56

表示		5:26
表示		5:03
非表示		7:01
表示		5:03
非表示		7:05
所感
  • コントロールセンターを表示し続けると、想像以上にバッテリーが消費される。
    • コントロールセンター下の画面がぼやけながら透けて見える効果を演出しているので、定期的に再描画が行われているのかもしれない。
    • 一般 >> アクセシビリティ >> コントラストを強くする=オン によって、バッテリー消費は抑えられるかも。(計測はしてないが)
  • しかし、ショートカット操作として短時間表示されるだけなので、その影響はごく僅かと思われる。

Siri

耳にあてて話す	1%減少するまでの経過時間
on		7:24
on		6:09
on		7:12
on		6:32
on		7:04
off		7:26
off		6:50
所感
  • Siri >> 耳にあてて話す オン/オフの違いによる差は、ほとんどない。

時計アプリのアイコン

時計アイコン	1%減少するまでの経過時間
表示		6:29
表示		6:39
非表示		7:28
所感
  • iOS7で時計アプリのアイコンの中で、リアルタイムに秒針まで動いているのを発見して感動したものだが、
  • やはり、常時画面の中で何かが動くということは、それなりのCPUパワーが必要で、それに伴う電力消費が発生するのだ。
  • しかし、iPhoneを使っていて、時計アプリのアイコンをじっと見つめていることは皆無である。
  • ほとんどの時間は、何らかのアプリを起動して、そのアプリの画面を見ている状態になるだろう。
  • 時計アプリのアイコンが見えていなければ、余分なバッテリーは消費されない。
  • 結局、通常の使用においては、時計アプリの秒針によるバッテリー消費なんて問題にならない。
    • 但し、今回のようにバッテリーの消費量を厳密に測定しようとした時は、時計アプリのアイコンの影響が気になってくる。



  • 以下の測定結果は、まだ測定方法が確立できずに、試行錯誤していた時のもの。
  • 減少率の確認を1分単位で行っていたので、測定誤差が1分前後あると思われる。
  • しかし、測定結果の辻褄は合っているので、測定結果としては活用できると思う。

視差効果

  • 視差効果なし = 一般 >> アクセシビリティ >> 視差効果を減らす=オン
  • 姿勢変化は、iPhoneを手で持って、およそ2秒ごとに水平と垂直に動かし続けた。
1時間当たりの減少率	条件					測定時間	減少率
10%		静止画、視差効果なし				 24分	4%
10%		静止画、視差効果あり、姿勢固定			 12分	2%
20%		静止画、視差効果あり、姿勢変化			  9分	3%
所感
  • 視差効果ありによるバッテリーの消費は大きい。その差2倍もあるが...
  • 視差効果ありでもiPhoneの姿勢が固定された状態なら、余分なバッテリー消費は発生しない。
  • iPhoneの姿勢が変化して、視差効果によって画面表示が変化するときに、バッテリー消費が発生する。
  • また、姿勢が変化しても、視差効果の演出がなければ、余分なバッテリー消費も発生しないはず。
    • 視差効果が確認できるのは、壁紙やSafariのタブ切替の画面だけ。
  • 今回の計測のように、激しくiPhoneの姿勢を変化させることも稀である。
  • よって、通常の使用においては、バッテリー節約効果はあまり期待できないと思っている。

ダイナミックと静止画

1時間当たりの減少率	条件					測定時間	減少率
10%		静止画、視差効果なし				 24分	4%
15.8%		ダイナミック、視差効果なし、壁紙が見える状態	 19分	5%
9.2%		ダイナミック、視差効果なし、壁紙が見えない状態	 13分	2%
所感
  • ダイナミック壁紙を設定することによるバッテリー消費も大きい。その差1.5倍程度あるが...
  • 視差効果と同様、壁紙が見えていなければ、無駄なバッテリー消費は発生しない。
  • よって、通常の使用においては、バッテリー節約効果はあまり期待できない、と思われるが、
  • 視差効果なし、静止画を設定など、小さな節約も積み重ねることで、大きな成果を生むかもしれない。
  • 結局、以下の設定で運用している。
    • 一般 >> アクセシビリティ >> 視差効果を減らす=オン
    • 壁紙/明るさ >> 壁紙を選択=静止画

プッシュとフェッチ

  • スリープ中のバッテリー消費を計測している。
  • 計測中は、メールをほとんど受信していない状態であった。
1時間当たりの減少率	条件					測定時間	減少率
1.3%		2プッシュ、スリープ				232分	5%
0.7%		4フェッチ手動、スリープ			440分	5%
2.7%		4フェッチ15分、スリープ			 67分	3%
1.3%		2フェッチ15分、スリープ			238分	5%
所感
  • バッテリー節約においては、よく悪者にされるプッシュ通知であるが、計測してみるとそれほどバッテリーを消費する訳ではない。
  • ほとんどメールを受信していないという条件なら、「プッシュ」と「15分ごとのフェッチ」のバッテリ消費量は、ほぼ同じなのだ。
    • でも、頻繁にメールが届く環境だと、プッシュもフェッチもバッテリー消費はもっと増えると思う。
    • 例えば、5分ごとに新着メールが届く環境でそれぞれのバッテリー消費を測定したいが、面倒くさくて未測定。
  • もちろん「手動のフェッチ」つまりメールを起動した時だけメールチェックするのが最も省電力なのだけど、
  • それではiPhoneの利便性が失われるし、時間差によってせっかくのチャンスを逃してしまうかもしれない。
    • アイデア:おやすみモードにした時は、すべてのメールチェックが「手動のフェッチ」になれば良いと思った。
    • アイデア:そして、おやすみモードを解除したら、一斉にメールチェックを始めるのだ。
  • やはり、時間差のない通知をくれるプッシュは魅力的だ。
  • プッシュ設定ができるメールはプッシュに、フェッチは重要度に応じて手動か、1時間ごとに設定した。
  • また、iPhoneで受信すべきメールアカウントを厳選して、無駄なメールチェックが発生しないようにした。

トリビア

  • iPhone4S以降なら、Bluetoothは常にオンにしても、バッテリー消費には影響しない。
  • キャリア >> 自動=オフ、によるバッテリー節約効果は意外に大きい。
  • 明るさ0%は、明るさ100%のおよそ2倍長持ち。
  • 時間差のないメールのプッシュ通知は魅力。プッシュが特別バッテリーを浪費する訳ではない。
  • 画面に変化が起こらなければ、バッテリー消費には影響しない。(視差効果あり、ダイナミック壁紙、時計アイコン等において)
  • 位置情報サービスがオンであっても、それが利用されない限り、バッテリー消費には影響しない。
  • 位置情報サービスのシステムサービスは、すべてオフにしてしまってもデメリットはほとんどない。

以上は、1個人の計測結果から導いた結論。どなたか追試して欲しい。

2013-10-09

iOS7のバッテリー長持ち大作戦

iOS7は、iOS6に比べると、バッテリーの持ちが悪くなったと感じる。バージョンアップしたのに利用可能時間が短くなると、何だか損したような気分。バッテリー切れのiPhoneなんて、役立たずの箱である。(文鎮ぐらいにはなるかもしれないが)そうならないために、バッテリーが少しでも長持ちするような設定をしたくなる。

利用環境

  • ソフトバンク
  • iPhone 4S
  • iOS 7.0.2

バックグラウンドの処理

  • iOS7では、バックグラウンドで様々な処理が実行される環境になった。
  • 利便性は高まるかもしれないが、バックグラウンド処理が実行されていると、バッテリー消費も激しい...。
  • そのバックグラウンド処理は本当に今必要なのか?タイミングを考えることで、バッテリー消費を抑える。
自動ダウンロード
  • 自動ダウンロードについては、夜間iPhoneを充電している間にアップデートされれば十分だったりする。
  • 昼間の活動時間帯に、App Storeでアップデートされたタイミングで、即ダウンロードする必要性はないのだ。
  • それに、アップデートが必ずしも素晴らしいものとは限らない。
  • しばし様子を見ていた方が、不具合情報を察知できたりするし。
  • アップデートするタイミングは自分で決めたいので、普段はオフ。機を見て充電する時にオン。
    • 電源接続中のみ自動ダウンロードを許可する設定があると、便利だと思う。
  • iTunes & App Store >> 自動ダウンロード >> アップデート=オフ
  • ミュージック、App、ブックの自動ダウンロードについては、他の端末やiTunesで購入したタイミングでダウンロードされる。
  • 購入のタイミングは自分の意志でコントロールできるので、これら3項目の自動ダウンロードはオンにしておいた。
Appのバックグラウンド更新
  • 同様に、利便性を考えればオンにしておきたいのだが、バッテリー消費とのトレードドフを考えてオフにした。
  • ほとんどのアプリはバックグラウンド更新をオフにしても、問題なく稼働した。
  • iOS6以前と同様に、アプリを起動している時だけ処理が行われる仕様になる。
  • 但し、唯一の例外はRunKeeperである。(自分の利用環境ではこれだけだが、他にもあると思う)
  • バックグラウンド更新をオフにしてしまうと、バックグラウンド中の時間の経過や軌跡の移動が停止してしまう。
  • すると、次にアクティブになった時に、前回の時間と場所からジャンプした直線的な軌跡が記録されてしまう...。
    • 例えば、直線距離5kmを3分で走ったとか、とんでもない新記録が残ってしまうのである。
  • RunKeeperを実行する時だけは、バックグラウンド更新をオンにする必要があるのだ。
  • 一般 >> Appのバックグラウンド更新=オン
  • 一般 >> Appのバックグラウンド更新 >> RunKeeperのみ=オン

メール/連絡先/カレンダーのプッシュとフェッチ

  • プッシュは、サーバーにメールが届くタイミングで、都度iPhoneに通知される。
  • 一方フェッチは、iPhoneが定期的にサーバーのメールをチェックして、通知を受信する。
  • メールが頻繁に届く状況では、プッシュ通知によってバッテリー消費が多くなる。
    • 適切な間隔のフェッチに設定した方がバッテリーを節約できると思う。
  • 逆にメールがあまり届かないのに、無駄なフェッチが多すぎても、バッテリー消費が多くなる。
    • 可能であればプッシュに設定した方がバッテリーを節約できると思う。
    • あるいはフェッチの間隔を1時間ごと、または手動にした方が良さそう。
  • 手動のフェッチ(つまりメールアプリを起動した時だけフェッチする)が最もバッテリー消費を抑えられそうだが、それではメールに気付くタイムラグに悩むことになる。
  • やはり可能であれば、タイムラグがほとんどないプッシュ通知にしておきたい。
  • ところで、i.softbank.jpメールはプッシュに対応していないのだけど、メールが届くとSMSのような仕組みを利用して「メールが届きましたメッセージ」を送信してくれる。
  • この「メールが届きましたメッセージ」は強力で、プッシュをオフにしても、手動のフェッチにしても、通知される。
    • おまけに、3Gさえ接続していれば、モバイルデータ通信=オフ、Wi-Fi=オフ、でさえ通知される。
    • ちなみに、MySoftbankのEメール(i)設定から「メールが届きましたメッセージ」をオフにできる。
  • 通知センターには残らない通知ながら、使い方によってはバッテリー消費を抑えながら、タイミングも逃さない設定ができそう。
    • 例:あまり届かないメールだけど、タイミングを逃したくないメールはi.softbank.jpに転送するようにしておくとか。

以上の思考過程から、以下のように設定した。

  • メール/連絡先/カレンダー >> データの取得方法 >> プッシュ=オン
  • メール/連絡先/カレンダー >> データの取得方法 >> XXXX@icloud.com=プッシュ
  • メール/連絡先/カレンダー >> データの取得方法 >> XXXX@yahoo.com=プッシュ
  • メール/連絡先/カレンダー >> データの取得方法 >> XXXX@gmail.com=フェッチ
  • メール/連絡先/カレンダー >> データの取得方法 >> XXXX@i.softbank.jp=手動
  • メール/連絡先/カレンダー >> データの取得方法 >> フェッチ=1時間(データの取得頻度)

i.softbank.jp通知が自動的に消灯しない不具合

  • 通常は、i.softbank.jpメールを受信すると、ダイアログメッセージが表示され、自動ロックの設定に従って消灯する。
  • よって、自動ロックの設定は、なるべく短くしておいた方がいい。
  • その後、i.softbank.jpメール以外の通知を受け取とっても、前回のダイアログメッセージが表示される。
  • そして、そのダイアログメッセージは消灯することなく、バッテリー切れまで永遠と表示されてしまうのだ。
    • メール受信後、iPhoneをまったく操作しないと、確実にこの現象が発生した。
    • スクリーンショットを撮影したり、ホームボタンや音量ボタンを一度でも押せば、自動ロックの設定に従って消灯した。
  • 数時間ぶりにiPhoneを確認して、i.softbank.jpメールの通知が表示され、バッテリー残量が残り僅かになっていた場合、この不具合が原因かもしれない。

  • この不具合を回避するには、3つの方法がある。(どれか一つを実践するだけで十分)
    • 1つ目は、MySoftbankのEメール(i)の設定で、通知しない設定にしてしまうこと。
    • 2つ目は、通知の設定でアプリすべての ロック画面に表示=オフ にしておくと、画面が点灯しない。
    • 3つ目は、おやすみモードにしておくと、通知が表示されないので、画面も点灯しない。
  • 自分の場合はi.softbank.jpメールがまったく通知されないのも不便。
  • すべての通知設定を ロック画面に表示=オフ にするは非現実的、かつ不便。
  • よって、長時間iPhoneを操作できない時は おやすみモード にしておくことにした。
  • 一般 >> 自動ロック=1分
  • 必要に応じて、コントロールセンター >> おやすみモード=オン
  • おやすみモード >> 時間指定 >> 開始=23:00、終了=5:00

メールアカウントの見直し

  • 多数のメールアカウントを登録しておくと、無駄にメールをチェックして、バッテリーが浪費される。
  • すべてのメールアカウントをiPhoneで受信する必要はなく、パソコンでメールチェックする頻度で十分だったりする。
  • iPhoneに登録しておくのは、受信のタイミングを逃したくないメールアカウントのみにしてみた。
  • メール/連絡先/カレンダーのアカウントでiPhoneで受信する必要がないと思われる項目を、すべてオフにしておいた。
  • メール/連絡先/カレンダー >> アカウント

Bluetooth

  • AirDropを利用するためには、Wi-Fi=オン、Bluetooth=オン、の環境が必要である。
  • でも、iPhone4SではAirDropがサポートされていないため、ほとんど使わないBluetoothはオフにしてしまう。
  • また、たとえサポートされていたとしても、利用したい時だけコントロールセンターから素早くオンにすればいい。
  • コントロールセンター >> Bluetooth=オフ

モバイルデータ通信とWi-Fi

  • iPhone4Sは、3Gのデータ通信しかサポートされていない。(4G LTEはiPhone5以降)
  • モバイルデータ通信よりも、Wi-Fiのデータ通信の方が、高速であり、かつバッテリーの節約になる。
  • 日常的にiPhone4Sを利用する環境は、幸運にもほぼWi-Fiに繋がる。よって、Wi-Fiを優先したい。
  • 一般 >> モバイルデータ通信=オフ
  • iTunes & App Store >> モバイルデータ通信=オフ

画面の明るさ

  • 明るさを抑えることで、バッテリーの消費も抑えられる。
  • 明るさの自動調節はオンにしておく。
  • 明るさの自動調整がオンの時に明るさを調整することで、自動調整の基準が変更される。
    • 例:明るい場所で必要最小限の明るさに設定すると、それを基準に薄暗い場所では減光してくれる。
    • 例:逆に、薄暗い場所で最大の明るさに設定すると、常に明るさ=最大となってしまい、自動調整の意味がなくなってしまう。
  • 明るさの自動調整を一旦オフにして、再びオンにすることで、デフォルトの基準にリセットされる。
  • 壁紙/明るさ >> 明るさの自動調整=オン
    • 但し、バッテリーをさらに節約したい時は、壁紙/明るさ >> 明るさの自動調整=オフ、明るさ=最小

通知の見直し

  • タイミングを逃さずに届くプッシュ通知は、とっても便利である。
  • でも、通知センターによってあらゆるアプリが簡単に通知をサポートできるようになると、通知で溢れ始める。
  • アプリ任せの設定のままでは、重要な通知も、無用の通知もある。
  • 通知の設定を見直して厳選することで、無駄な未読通知や未読バッジに惑わされず、重要な通知を判別し易くなる。
  • 不要な通知が減少することで、バッテリーの節約にもなるはず。
  • 通知センター >> 表示

位置情報サービスのオフ

  • 機内モードをオンにしても、GPSを利用した位置情報サービスは機能している。
  • 位置情報サービスをオフにすることで、GPSを利用する電力も節約できる。
  • 但し、常時オフにしていしまうと利便性が劣るので、もしもの時の節約方法として覚えておく。
  • 通常はオンにしておく。利用を許可するアプリを厳選して、無駄な位置情報の利用を控える。
  • プライバシー >> 位置情報サービス
  • プライバシー >> 位置情報サービス >> システムサービス

機内モードの活用(電波状況が悪い場合の対応)

  • 機内モードをオンにすることで、3G・4GLTE・Wi-Fi・Bluetooth通信がオフになる。
  • 携帯電話ネットワークの圏外、あるいは電波状況が悪い場所では、バッテリーが浪費されることがある。
    • 無駄なネットワークサーチが繰り返されるためである。
  • 機内モードをオンにすることで、この状況を改善できる。
    • 例:辺鄙な山奥で移動している状況などでは、この設定がバッテリーの浪費を抑えてくれることがある。
    • 例:更衣室のロッカーにiPhoneを保管しておく場合、そのロッカーの中は圏外かもしれない。
  • コントロールセンター >> 機内モード=オン
    • あるいは、モバイルデータ通信 >> 3Gをオンにする=オフ

Wi-Fiの未接続を避ける

  • 同様に、Wi-Fi=オンにしたまま、Wi-Fiの圏外、あるいは未接続な状態を続けても、バッテリーが浪費される。
  • よって、Wi-Fiに接続しない状態が長く続く場合は、こまめに Wi-Fi=オフ にしておく方がいい。
  • コントロールセンター >> Wi-Fi=オフ

多少のバッテリー節約効果を期待できる設定

  • 壁紙/明るさ >> 壁紙を選択 >> ダイナミックな壁紙を使用しない
  • 一般 >> アクセシビリティ >> 視差効果を減らす=オン
    • ダイナミックな壁紙は、背景が常に動き続けているので、表示されている時間はバッテリーが浪費されると思う。
    • 視差効果とは、iPhoneを傾けた時に、手前と奥の位置関係によって見え方を変化させ、奥行きを演出する効果である。
    • 但し、ダイナミックな壁紙や視差効果を演出している時間はそれほど長くないので、バッテリーの節約効果も数パーセントだと思う。
  • キャリア >> 自動=オフ
    • au iPhoneの海外パケット通信で請求76万円に陥ったワケ
    • 海外でローミングを利用する時は、絶対オフにしておいた方が良さそうだ。
    • 自動=オンでは、その場所で利用可能な携帯会社を常に検索し続けるのかもしれない。
    • 自動=オフの方がバッテリーの消費が若干遅い気がする。
    • 自分のiPhoneはSIMロックされているので、Softbankを選ぶしかない。
    • ならば常に、キャリア >> 自動=オフ にしていた方が良さそうだ。

節約効果への疑問やデメリットを感じる設定

  • マルチタスキング画面に残っているアプリをフリックで削除する。
    • 必ずしもバックグラウンドで稼働している訳ではないアプリを毎回フリックで削除するのは面倒だし、無意味な気がする。
    • iOS7以降では、一般 >> Appのバックグラウンド更新 で設定した方が、確実に無駄なアプリの稼働を抑えられるはず。
      • 但し、Appのバックグラウンド更新でコントロールできないアプリがバッテリーを浪費する可能性はあるかも。
  • 一般 >> 日付と時刻 >> 自動設定=オフ
    • 自動設定=オンで、時間帯と正確な日時を自動で設定してくれる。
    • その際、位置情報の取得や定期的なタイムサーバーへのアクセスをしていると思われるが、それがどれほどバッテリーに影響するのかは未知。
    • 自動設定=オフにすることで、iPhoneの時計がズレてもそのままになってしまうデメリットの方が大きいと感じる。オンにしておいた。
  • 一般 >> Spotlight検索 >> すべての項目をオフ
    • オフにすることで検索インデックスの作成処理は不要になるが、利便性を考えてオンにしている。
    • メモの検索、メールの検索、アドレス帳の検索などで意外と重宝している。
    • 確かに、iOSのメジャーアップデート時には、検索インデックスの作り直しで丸一日くらいバッテリーの消費が激しくなることもあるが、
    • 一旦、検索インデックスが完成してしまえば、その後は追加・変更されたファイルの差分のみ修正するだけなので、ほとんど負荷がないはず。
  • イコライザー=オフ
    • iPhoneの音楽の再生時間は、最大40時間となっている。
    • 1時間聴き続けたとしても、2.5%しか消費しないのだ。
    • イコライザーをオンにしたところで、その違いは僅かだと思う。
    • イコライザーの音が好みなら、その欲求を大切にした方がいい。
    • 音楽は楽しむために聴くはず。我慢してたら、その楽しさも半減する。
    • そもそもバッテリー残量が気になってきたら、音楽なんて聴いてる場合じゃない。
  • 一般 >> Siri >> 耳にあてて話す=オフ
    • Siriはほとんど使わないけど、たまに使えて嬉しい状況もある。だから、オンにしている。
    • Siri=オンであっても、Siriを起動しない限り、バッテリーには影響しないように思う。
    • ところで、Siriには「耳にあてて話す」という設定がある。
    • これをオンにしておくと、通話する時のようにiPhoneを耳にあてて構えるだけでSiriが起動する。
    • 耳にあてた状態かどうかは、iPhone上部のスピーカ横にある接近センサーが活用されていると思う。
      • ちなみに、かなり高度に耳にあてたかどうかを判定しているように思う。
      • 接近センサー部分を手で押さえたり、ポケットに入れただけでは、Siriは無駄に起動しない。
      • ちゃんと耳にあてた状況でしか、Siriは起動しなかった。誤魔化しは効かない...。
      • もしかしたら、カメラも活用して、耳の画像判定までしているのだろうか?
    • スリープ中以外、接近センサーは常に稼働状態になると思うのだが、バッテリー消費への影響はほとんどないと感じた。
  • 時計アイコンを非表示
    • iOS7から時計アプリのアイコンの針が秒針レベルまで、リアルタイムで変化するようになった。
    • 素晴らしいことなんだけど、秒針が常に動いているということは、その部分を常に描画し直しているはず。
    • その描画には多少なりともCPUパワーが必要になり、若干だけど、バッテリー消費が増えることになる。
    • 但し、iPhoneの画面に時計アイコンが見えていない時は、バッテリー消費には影響しないはず。
    • でも、ホーム画面の時計アイコンをずっと見つめていることはないので、結局バッテリー消費にはほとんど影響しない。

2013-09-23

iOS7の使い心地

フリックの達人

iOS7ではフリックが進化したと思う。

  • フリックする位置と方向によって、様々な便利機能に素早くアクセスできるようになった。
  • 画面外周からのフリックについては、画面表示エリアの外側から操作を開始するのがコツ。
縦方向のフリック
  • 縦方向にフリックには、iOSとしての機能が割り当てられている。
操作呼び出される機能操作環境
画面外周上端から下方向にフリック通知センターを表示ロック画面、ホーム画面
画面外周下端から上方向にフリックコントロールセンターを表示ロック画面、ホーム画面
画面内側を下方向にフリックSpotlight検索ホーム画面
横方向のフリック
  • 横方向のフリックには、アプリケーションに対する操作が割り当てられている。
操作呼び出される機能操作環境
画面外周左端から右方向にフリックリスト階層をルート方向に遡る電話、メッセージ、メール、メモ、リマインダー等
画面外周左端から右方向にフリック戻るSafari
画面外周右端から左方向にフリック進むSafari
リスト項目を左方向にフリック削除、その他様々な機能へアクセスメール、リマインダー等
リスト項目を左方向にフリック削除電話、メッセージ、メモ
画面内側を右方向にフリック(どの位置でフリックしてもOK)ロック解除ロック画面
画面内側を左右方向にフリック(どの位置でフリックしてもOK)ビデオ・写真・スクエア・パノラマのモード切替カメラ

Safari

  • Safariには、Webページの表示エリアを可能な限り最大化しようとする意図が感じられる。
URLバーとツールバーの表示モードフルスクリーンモード
f:id:zariganitosh:20130922170819p:image:h450f:id:zariganitosh:20130922170818p:image:h450
  • URL欄と検索欄も融合され、視認性の向上、入力操作のやり易さが感じられる。
  • ブックマークバー = お気に入り になった。
  • ステータスバーの1タップ = URLバーとツールバーの表示モード になった。
  • ステータスバーの2タップ = ページトップへ移動した。
  • 画面外周の下端を1タップ = URLバーとツールバーの表示モード になった。
  • ページ上端・下端での上下フリック = URLバーとツールバーの表示モード になった。
  • ページ途中での上方向へのフリック = フルスクリーンモード になった。
  • ページ途中での下方向へのフリック = URLバーとツールバーの表示モード になった。
  • ページ途中での下方向へのスワイプ = 直前の表示モード が維持された。
    • フリック = スクロール慣性を維持しながら、画面から指が離れる。
    • スワイプ = スクロールを一旦停止してから、画面から指が離れる。
  • タブ切替のページで左方向へフリック = タブを閉じる。

  • 上記以外にも、様々なアプリに、未知なる便利なフリック操作が隠されているはず。

地味に感動

  • なんと!時計アプリのアイコンは、秒針までリアルタイムに更新されている。(ステータスバーの17:22と一致)

f:id:zariganitosh:20130923144404p:image:w328

  • ちなみにiOS6以前から、カレンダーアプリのアイコンは、カレンダーと連動して、日付と曜日が更新されていた。

嬉しい機能

どの機能もよく使うので、じわっと嬉しい。痒い所に手が届く感じ。

コントロールセンターから懐中電灯
  • コントロールセンターから、カメラのフラッシュを懐中電灯として利用できるようになった。
    • 以前から、カメラのフラッシュとしてより、LEDライトとしてよく使っていた。
    • OS標準で懐中電灯がサポートされて嬉しい。
    • これで懐中電灯アプリは不要になってしまった。(これまでのサポートに感謝!)

f:id:zariganitosh:20130922170816p:image:h450

コンパス アプリの水準器
  • コンパス アプリに水準器の機能が追加された。
    • 左右のフリックで、コンパスと水準器を切り替えられる。
    • コンパス自体にも、中心部に水準器が組み込まれている。

f:id:zariganitosh:20130922170817p:image:h450

ロック画面のタイマー表示
  • 時計アプリのタイマーを使っている最中は、残り時間がロック画面にも表示されるようになった!

f:id:zariganitosh:20130922170813p:image:h450

通知センターの天気予報

  • 通知センターに天気予報が表示されるようになった、はずなのだが...自分のiPhone4Sには、なぜか表示されない。
  • なぜだー?と思って探しまくると、設定 >> プライバシー >> 位置情報サービス >> 天気=有効 で表示されたのだ。

f:id:zariganitosh:20130922170814p:image:h450 f:id:zariganitosh:20130922170815p:image:h450

  • 一旦、天気予報が表示されるようになると、設定 >> プライバシー >> 位置情報サービス >> 天気=無効にしても大丈夫。
  • ちなみに、天気以外の通知センターに表示する内容については、設定 >> 通知センター で表示・非表示を切り替えられるはず。

f:id:zariganitosh:20130922170822p:image:h450

マルチタスキング

  • 以前と同様に、ホームボタンの2度押しで、マルチタスキング画面(アプリ切替画面)になる。
  • マルチタスキング画面でアプリのページビューを上方向にフリック = バックグラウンド アプリの終了
  • ちなみに、2本指フリック、3本指フリックによって、同時に2アプリ、3アプリの終了が可能になった。
    • 但し、ページビューは削除されるのだけど、なぜかアイコンだけが残ってしまう場合があった...。
2本指で、2アプリ終了3本指で、3アプリ終了
f:id:zariganitosh:20130922170820p:image:w303:h450f:id:zariganitosh:20130922170821p:image:w303:h450

ところで、すべてのアプリを一気に終了する方法はないのだろうか?

  • 残念ながら、iOS7でも全アプリを一気に終了することはできないようだ。
  • 但し、DRMemoryのようなアプリを使ってメモリを解放することで、アプリを終了するのと同等の効果はあるはず。
  • アプリの履歴は残っているが、アプリは終了され、メモリを解放した状態になるのだ。
  • つまり、iPhoneを電源オフして、再起動した直後と似たような状態になると思われる。
  • しかし、何らかの問題がない限り、メモリ管理はiOS7に任せておいた方が無難かも。
    • 何らかの問題 = 例:特定のアプリがバックグラウンドで起動していると異常にバッテリーの消耗が早い、など。
    • ユーザー側のお節介なアプリ終了や、メモリ解放よりも、進化したUNIXのメモリ管理の方が優秀だったりする。

2013-09-11

diff iPhone5c iPhone5s

diff 5C 5S

# 容量
5C: 16GB、32GB
5S: 16GB、32GB、64GB

# 価格
5C: 99ドル、199ドル
5S: 199ドル、299ドル、399ドル

# 色
5C: ホワイト、ピンク、イエロー、ブルー、グリーン
5S: シルバー、スペースグレイ、ゴールド

# サイズ
5C: 124.4mm×59.2mm×8.97mm
5S: 123.8mm×58.6mm×7.60mm

# 重量
5C: 132g
5S: 112g

# チップ
5C: A6
5S: A7(64ビットメインCPU)、M7(加速度センサー、ジャイロスコープ、コンパスのモーションデータ処理用サブCPU)

# センサー
5S: 指紋センサー

# フラッシュ
5C: LEDフラッシュ
5S: TrueToneフラッシュ(白と琥珀色の2色の照射によってベストなホワイトバランスを目指したフラッシュ)

# レンズの明るさ
5C: f2.4
5S: f2.2

# イメージセンサー
5S: センサーエリア15%拡大

# 連写
5S: バーストモード(シャッターボタンを押し続けることで1秒間に10ショットの連写)

# 手ぶれ補正
5S: 手ぶれ補正(シャッターボタン1タップで4枚撮影し、ノイズ、被写体ぶれ、手ぶれが最も少ない部分を合成して1つの画像をつくる)

# ビデオ
5C: ビデオの手ぶれ補正
5S: 強化されたビデオの手ぶれ補正

# スローモーション
5S: スローモーションビデオ(120FPSでのビデオ撮影)

diff 4S 5 5C 5S

# 容量
4S: 8GB
5 : 16GB、32GB、64GB
5C: 16GB、32GB
5S: 16GB、32GB、64GB

# 価格
4S: 0ドル
5 : 
5C: 99ドル、199ドル
5S: 199ドル、299ドル、399ドル

# 色
4S: ブラック、ホワイト
5 : ブラック&スレート、ホワイト&シルバー
5C: ホワイト、ピンク、イエロー、ブルー、グリーン
5S: シルバー、スペースグレイ、ゴールド

# サイズ
4S: 115.2mm×58.6mm×9.30mm
5 : 123.8mm×58.6mm×7.60mm
5C: 124.4mm×59.2mm×8.97mm
5S: 123.8mm×58.6mm×7.60mm

# 重量
4S: 140g
5 : 112g
5C: 132g
5S: 112g

# チップ
4S: A5
5 : A6
5C: A6
5S: A7(64ビットメインCPU)、M7(加速度センサー、ジャイロスコープ、コンパスのモーションデータ処理用サブCPU)

# 携帯電話通信方式
4S: GSM/EDGE, UMTS/HSPA ,           CDMAモデル:CDMA EV-DO Rev.A
5 : GSM/EDGE, UMTS/HSPA+, DC-HSDPA, CDMAモデル:CDMA EV-DO Rev.AおよびRev.B, LTE
5C: GSM/EDGE, UMTS/HSPA+, DC-HSDPA, CDMAモデル:CDMA EV-DO Rev.AおよびRev.B, LTE(800MHz対応)
5S: GSM/EDGE, UMTS/HSPA+, DC-HSDPA, CDMAモデル:CDMA EV-DO Rev.AおよびRev.B, LTE(800MHz対応)

# WiFi通信方式
4S: 802.11  b/g/n(802.11nは2.4GHz)
5 : 802.11a/b/g/n(802.11nは2.4GHz/5GHz)
5C: 802.11a/b/g/n(802.11nは2.4GHz/5GHz)
5S: 802.11a/b/g/n(802.11nは2.4GHz/5GHz)

# センサー
5S: 指紋センサー

# ディスプレイ
4S: 3.5インチ(対角)、 960×640
5C: 4.0インチ(対角)、1136×640
5C: 4.0インチ(対角)、1136×640
5S: 4.0インチ(対角)、1136×640

# フラッシュ
4S: LEDフラッシュ
5 : LEDフラッシュ
5C: LEDフラッシュ
5S: TrueToneフラッシュ(白と琥珀色の2色の照射によってベストなホワイトバランスを目指したフラッシュ)

# レンズの明るさ
4S: f2.4
5 : f2.4
5C: f2.4
5S: f2.2

# レンズカバー
5C: サファイアクリスタル製レンズカバー
5S: サファイアクリスタル製レンズカバー

# イメージセンサー
5S: センサーエリア15%拡大

# 連写
5S: バーストモード(シャッターボタンを押し続けることで1秒間に10ショットの連写)

# 手ぶれ補正
5S: 手ぶれ補正(シャッターボタン1タップで4枚撮影し、ノイズ、被写体ぶれ、手ぶれが最も少ない部分を合成して1つの画像をつくる)

# ビデオ
4S: ビデオの手ぶれ補正
5 : ビデオの手ぶれ補正
5C: ビデオの手ぶれ補正
5S: 強化されたビデオの手ぶれ補正

5C: ビデオ撮影中に写真を撮影
5S: ビデオ撮影中に写真を撮影

5C: 3倍ズーム
5S: 3倍ズーム

5S: スローモーションビデオ(120FPSでのビデオ撮影)

# FaceTimeカメラ
4S:  640×480の写真,  640×480のビデオ撮影
5 : 1280×960の写真, 1280×720のビデオ撮影
5C: 1280×960の写真, 1280×720のビデオ撮影
5S: 1280×960の写真, 1280×720のビデオ撮影

# バッテリー(通話と待ち受け)
4S: 3G通話:最大 8時間, 連続待受時間:最大200時間
5 : 3G通話:最大 8時間, 連続待受時間:最大225時間
5C: 3G通話:最大10時間, 連続待受時間:最大250時間
5S: 3G通話:最大10時間, 連続待受時間:最大250時間

# バッテリー(インターネット利用)
4S: 3Gで最大6時間, WiFiで最大 9時間
5 : 3Gで最大8時間, WiFiで最大10時間, 4G LTEで最大 8時間
5C: 3Gで最大8時間, WiFiで最大10時間, 4G LTEで最大10時間
5S: 3Gで最大8時間, WiFiで最大10時間, 4G LTEで最大10時間

# SIM
4S: micro SIM
5 : nano SIM
5C: nano SIM
5S: nano SIM

# コネクタ
4S: 30ピン
5 : Lightning
5C: Lightning
5S: Lightning