Open14

アプリ関係の知識的な　あいうえお

よよよよよよ

【コールドブートとは】
電源が完全に落ちた状態から起動することを意味する用語で、
PCやサーバー、仮想マシン、スマホ、家電など、幅広い分野で使われ

「完全再起動」や「初期状態からの起動」というニュアンス

対義語は「ウォームブート（Warm Boot）」で、これはOSやシステムを再起動するけど電源は切らないようなソフトウェア的リスタートを指す

【Androidエミュレーターにおけるコールドブート】
Androidエミュレーターでは
　👉 「前回の状態（スナップショット）を引き継がず、まっさらな状態から起動」
　という意味で「コールドブート」が使われています。

エミュレータは通常、スナップショットから高速起動しますが、これがうまくいかない時や、
キャッシュをクリアしたい時などに「Cold Boot」を選んで、クリーンな起動状態にします。

よよよよよよ

【Quick Boot】
Android Studio のエミュレーター機能に搭載されている機能の一つで、一度エミュレーターを起動した後の状態をスナップショットとして保存し、次回起動時にOSのブートプロセスをスキップして高速起動する仕組み

通常の「Cold Boot」（完全な起動）と比べて大幅に高速

開発やテストを効率化することができる

  1. PCやBIOS設定での「Quick Boot」
    パソコンやマザーボードのBIOS設定内にある項目で、起動時のメモリテストやハードウェアチェックを簡略化・スキップし、OS起動を早める機能です。

フルチェックを行う「Full Boot」より速い

再起動時や頻繁な起動テスト時に有効

よよよよよよ

【メモリヒープ】
プログラムが「自由に使えるメモリ領域」のこと
動的に（実行時に）メモリを確保して使う場所
「ヒープ領域」と呼ばれることもある

↓
プログラムが動くと、メモリ上に「スタック」と「ヒープ」というエリアが用意される

スタック
-一時的なデータ置き場（関数呼び出し時の引数、ローカル変数など）
-使い終わったら自動的に消える
-LIFO（後入れ先出し）で管理される箱

▶ ヒープ
-new や malloc などで自分で「ここにスペースください」とお願いして確保する場所
-自分で解放（消す）しないと残り続ける（Garbage Collection で自動回収してくれる言語もある）
-大きいデータやオブジェクトはここに置かれる

メモリ
├─ スタック領域
│ ├─ 関数Aのローカル変数
│ ├─ 関数Bのローカル変数
│ └─ 呼び出しが終わると順に消える
│
└─ ヒープ領域
├─ new で確保したオブジェクト
├─ 配列・リストなど大きい動的データ
└─ 自動では消えない（GCがあれば自動回収）

例
「Dartでのヒープ使用のイメージ」

var list = List.generate(1000, (index) => index);
//長さ1000のリストを作成し、各要素には0から999までの数値を順番に代入している
//(index)=>index という無名関数が0から999まで呼ばれその戻り値をリストに格納する。

https://api.flutter.dev/flutter/dart-core/List/List.generate.html　これのbool省略版

この list は大きなデータなのでヒープ領域に確保される。
プログラムが終わったり、GC（ガベージコレクション）が実行されるまでメモリに残り続ける。

よよよよよよ

LIFO

LIFO = Last In, First Out（ラスト・イン・ファースト・アウト）
-「最後に入れたものが最初に出てくる」というデータ構造のルール
【例えると】
イメージは 「積み重ねた魂のカード(デッキ)」
カードを一枚置く
もう一枚カードを置く
一番最後においたカードから先にドローする
つまり、
最後に入れたもの（Last In）が
最初に出てくる（First Out）

【LIFO の代表的な例】
スタック（Stack）
Dart やプログラミング言語のスタック領域は、このルールで管理されている。

スタックに入れる順番：
  1 → 2 → 3  （3が一番上に積まれる）

取り出す時は：
  3 → 2 → 1 （最後に入れた3から順番に出てくる）

LIFO の逆：FIFO

FIFO = First In, First Out
「最初に入れたものが最初に出てくる」
これは行列（キュー）みたいな仕組み

スタック」や「キュー」の実装例
//あとでやる

よよよよよよ

malloc

「memory allocate（メモリを割り当てる）」の略で、ヒープ領域にメモリを確保する関数」

【役割】
-実行時に「これくらいのサイズのメモリが欲しい！」と要求して
-その領域をヒープに確保して
-そのメモリの先頭アドレス（ポインタ）が返ってきます

flutterでは基本手動でメモリ確保することはない
↓
ガベージコレクション（GC）付きのメモリ管理言語 だから
↓つまり
必要になった時に自動でヒープ領域にオブジェクトを確保し、使わなくなったら自動的に解放してくれる

//深掘りあとで

よよよよよよ

【Garbage Collectionガベージコレクション（GC)】
使わなくなったメモリ（ゴミ＝Garbage）を自動的に回収してくれる仕組み

プログラムが動いているとき、

新しいデータ（オブジェクト）をメモリにどんどん作る
でもそのうち、もう参照しなくなる（どこからも使われていない）オブジェクトが出てくる
その「もう誰も使ってないメモリ」を残したままにしておくと、無駄にメモリを食ってしまう
↓
そこで GC（ガベージコレクター） が
「あ、これもう誰も使ってないな」
「これもどこからも参照されてないな」
と見つけて
自動的にメモリを解放してくれる
というもの。

//深掘りあとで

よよよよよよ

ブートストラップ

void main() {
 runApp(MyApp());
}

この main() 関数で runApp() を呼び出すところがFlutterアプリの「ブートストラップ」にあたる部分。
ここからアプリ全体の初期化や設定、ルーティング、状態管理が始まるから、「アプリ起動の土台」みたいな感じ。

よよよよよよ

ボイラープレートコード（boilerplate code）

決まりきった形式や構造のコードのことを指し多くの場合、プログラミングで何かを始めるときに毎回似たような形で書かれるコード

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(child: Text('Hello World')),
      ),
    );
  }
}

このコードの大部分は、毎回似たような構造になる。
この「アプリを起動するまでの枠組み」はまさにボイラープレート。

よよよよよよ

アーキテクチャ(設計パターン)

MVVM

-View ↔ ViewModel ↔ Modelで分離。Riverpod/ProviderでViewModelを表現。

Clean Architecture

-層ごとに責務を分けてドメインロジックを整理。テストしやすい。

Redux

-グローバルな状態管理に強いが、学習コストが高め。

Bloc Rx

-スタイルのアーキテクチャ。イベント駆動型でMVPに近い思想もあり。

「Riverpod + Freezed + GoRouter + Hooks」はアーキテクチャ？
No
設計思想そのものではない
'
じゃあ何？
モダンFlutterアーキテクチャを実現するための技術スタック（道具セット）

どんな設計思想と組み合わせる？
MVVMやクリーンアーキテクチャが人気

よよよよよよ

ユビキタス言語

https://qiita.com/moromi25/items/d993700b732a7baa1c57
「サービスのターゲット業務や開発に関わるすべての人が、見聞きして同じ意図を連想できる一意の言葉」で、「関係者全員が同じ土俵に立つための共通認識を作るツール」で、
その言葉を使って滞りなくターゲット業務に関する会話ができるし、その言葉を使って悩むことなくコードやドキュメントが書ける状態

よよよよよよ

設計思想マッピング

-システムやプロダクト、サービスを設計する際に、背後にある“設計思想（思想・価値観・目的）”を明確にし、それらを要素同士の関係性と共に“見える化”する手法

目的としては、

設計の背後にある意図・哲学を明らかにし、
関係者間で共通理解を持つことで、
ブレない設計・開発を実現する

具体的にどういうものか？

設計思想マッピングは以下のような観点

-ビジョン 何のためにこの設計を行うのか？最終的に実現したい理想像は？
-価値観 何を大切にした設計か？（例：効率よりも安全性、操作性よりも柔軟性など）
-コンセプト 製品やサービスの核となるアイデア・特徴は？
-設計原則 具体的な判断基準や優先順位（例：DRY原則、KISS原則など）
-要素間の関係 どの要素がどのように影響し合うか？優先度や依存関係の整理

よよよよよよ

設計原則（Design Principle）

凝集度

凝集度（ぎょうしゅうど、cohesion）」は、主にソフトウェア工学の文脈で使われる用語で、モジュール（クラスや関数など）内部の要素がどれだけ密接に関連しているかを示す指標です。

🔍 意味・解説
高凝集（High Cohesion）：
モジュール内のすべての要素が、同じ目的や機能に向かって協力している状態。
→ 保守性が高く、再利用しやすいコードになります。

低凝集（Low Cohesion）：
モジュール内で複数の異なる機能や責任を持ってしまっている状態。
→ 理解しづらく、バグが起きやすくなる傾向があります。

低凝集（Low Cohesion）：
モジュール内で複数の異なる機能や責任を持ってしまっている状態。
→ 理解しづらく、バグが起きやすくなる傾向があります。

深掘り↓
https://zenn.dev/portinc/articles/design-principle-cohesion

❶ 低凝集の例

class UserManager {
  void createUser() { ... }
  void deleteUser() { ... }
  void sendEmail() { ... } // ← メール送信は別の責務
}

❷ 高凝集の例

class UserManager {
  void createUser() { ... }
  void deleteUser() { ... }
}
class EmailService {
  void sendEmail() { ... }
}

→ クラスごとに**1つの責任（SRP：単一責任原則）**にすることで凝集度が上がります。

結合度（Coupling

モジュール同士の依存の強さを表す指標です。
つまり、「あるクラスや関数が、別のクラスや関数にどれだけ依存しているか？」を示します。

結合度が高い例（Bad）

class OrderService {
  final UserService userService = UserService(); // 直接インスタンス化

  void createOrder() {
    userService.getUserInfo(); // ← 直接呼び出し
  }
}

結合度が低い例（Good）

class OrderService {
  final IUserService userService;

  OrderService(this.userService); // ← インターフェース経由で依存注入

  void createOrder() {
    userService.getUserInfo();
  }
}

依存性の注入（DI） や インターフェースの使用によって、疎結合（Loose Coupling） を実現できる

まとめ：理想的な設計は？

凝集度は高く！
→ 各モジュール内は1つの目的に集中させる

結合度は低く！
→ モジュール同士は疎結合に保つ（インターフェース、DIなどを使う）

よよよよよよ

Clean Architecture

-Robert C. Martin（通称 Uncle Bob） が提唱したアーキテクチャパターンで、以下のようなレイヤー構造を中心に構成されています。

+-----------------------------+
| 外部の仕組み | ← UI / Framework / DBなど
+-----------------------------+
| インターフェース | ← WebAPIの入力/出力, Gateway, Presenter
+-----------------------------+
| アプリケーション層 | ← ユースケース / ビジネスロジックの制御
+-----------------------------+
| ドメイン層 | ← ビジネスルール / エンティティ
+-----------------------------+

🧠 レイヤーの説明

-Entities（エンティティ） アプリケーションのビジネスルール（不変のロジック） どこにも依存しない
-Use Cases（ユースケース） ユーザーの操作や処理フローを表現（アプリ固有のルール） Entitiesに依存
-Interface Adapters（インターフェース） プレゼンター、Controller、Gateway（データ変換） Use Casesに依存
-Frameworks & Drivers（外部層） DB、UI、Web、API、Flutterなど Interfaceに依存

依存性のルール（依存方向）

-内側のレイヤーは外側に依存しない
-ドメインロジックはフレームワークに依存しない
-WebやDBが変わっても、ビジネスロジックは変更不要にする

メリット

-保守性が高い：ビジネスロジックがUIやDBに依存しない
-テストしやすい：ユースケース単体でテスト可能
-技術選定が柔軟：フレームワークの入れ替えが可能（例：Flutter → React）
-変更に強い：外部の変更にアプリコアが影響されない

🛠️ 使われるケース（実例）

-Androidアプリ：Kotlin + MVVM + Clean Architecture
-Flutterアプリ：Riverpodなどで層分けして使う
-Webバックエンド：DjangoやRailsに独自で適用
-**DDD（ドメイン駆動設計）**と組み合わせて使うことも多い

ざっくり図式化（矢印は依存方向）
[ 外部UI/DB ] → [ Adapter ] → [ UseCase ] → [ Entity ]

よよよよよよ

Human Interface Guidelines（HIG）

「Human Interface Guidelines（HIG）」とは、Appleをはじめとするプラットフォーム提供者（GoogleやMicrosoftなど）が定めている、ユーザーインターフェース（UI）とユーザー体験（UX）に関する設計ガイドラインのことです。
簡単に言うと、「アプリやWebサービスの見た目や操作感を、ユーザーにとって一貫性があって使いやすいものにするためのルール集」です。

🎯 HIGの目的

直感的に操作できるUIを実現する
プラットフォーム全体で一貫した操作体験を提供する
ユーザーが「初めてのアプリでも迷わず使える」ようにする
開発者やデザイナーの意思決定をサポートする

よく知られているHIG例

AppleのHIG

iOS、macOS、watchOS、visionOS それぞれにガイドラインが用意されている
例: 「タップしやすいボタンサイズは最低44pt」「戻るボタンは左上に」など
Appleの公式ページ：Human Interface Guidelines - Apple Developer
GoogleのHIG（Material Design）
AndroidアプリやWebでも使えるガイドライン

色、レイアウト、アニメーション、タッチ領域など幅広くカバー
Googleの公式ページ：Material Design

どう活用するの？

UI/UXデザインをするときの判断基準にする

FlutterやReact Nativeなどでアプリを作るときにも参考にすることでネイティブっぽい操作感を再現できる

App StoreやGoogle Playでリジェクトされないための準拠ポイントにもなる